Decision Analytics > LawsonGuru > LawsonGuru Letter > 2003

February 2003

The LawsonGuru Letter is a free periodic newsletter containing provocative commentary about issues important to the Lawson Software community.
The LawsonGuru Letter is published by-and is solely the opinion of-John Henley of Decision Analytics. Visit Decision Analytics at http://www.danalytics.com. For subscription information, see the bottom of this message.
The LawsonGuru Letter is not affiliated with Lawson Software.

In this issue:
1. Guest Spot: DVP - Right Approach, Wrong Reasons
2. Say Goodbye to your "Briefing Book"?
3. Under Lawson's Covers
4. Reader Feedback
5. Survey: CUE Predictions
6. Lawson Tips & Tricks
Before we start, two "housekeeping" items:
- Many thanks to Eddi Staffini for this month's guest column. I want this "Guest Spot" to become a regular feature of the LawsonGuru Letter--to survive, this newsletter needs more "reader-participation". I will continue to edit, write and manage the mailing of it only if I can count on you--the readers--to "step up", as Eddi has done. I invite anyone--whether a Lawson employee, client or partner--with an opinion or topic of interest. Simply send me an email at to get started.
- Still no correct response to my challenge in the last two issues to name the department store I described (which live animals they had on display). So, to eliminate any further agony, I'm going to give you the answer, and declare the contest over! The store was called "Kann's", and they had stores in DC and Virginia. At the VA store (which is now the site of the George Mason University Law School), they had live MONKEYS! I guess it was supposed to be for entertainment, but I always found it to be disgusting! (See answer #126 at http://www.arlingtonhistory.org/answers101-200.htm).
Several readers complained that the contest was unfair to those of you who are "geographically-challenged" (you didn't live in the DC area at the time) or "experience-challenged" (you're too young). Oh well, it's my contest. Let me know if you'd like me to have another "contest" in a future letter; I'll make it easier, I promise. Send your ideas to .

1. Guest Spot: DVP - Right Approach, Wrong Reasons

(by Eddi Staffini. Eddi is the Programming Manager at Sibley Memorial Hospital in Washington, DC, and is a member of the Lawson Mid-Atlantic User Group executive board. This editorial reflects his personal opinions only and not those of Sibley Hospital, the board or group members.)

DVP stands for Data Verification Process. Without going into details, it consists of a series of programs in the IC, PO, RQ and WH systems that identify and delete orphan records. Lawson mandates it as a required step prior to upgrading to their 8.x release. I agree with the step; I even agree, somewhat reluctantly, to the mandated part. What I strongly disagree with are the fact that Lawson charges for the process, forces clients to use Lawson consultants at a cost of $1,000/day plus T & E, and the reasons they use as justification.

Let me give a very brief history. The 7.2.x release was/is plagued with inconsistencies, especially between IC and WH. An item would be ordered, an allocation assigned and a demand created; the order would be filled but sometimes the allocation and/or the demand would not be resolved. We were one of the many companies that experienced this problem and solved it through a Lawson-provided set of update screens. The process was manual, but quick and relatively painless. When Lawson first asked me if I were interested in the DVP, I declined, as I knew we were resolving issues as we found them and I was confident that we were in rather good shape. I made sure I explained my reasoning and even received kudos from Lawson for being so thorough. I did not include it in my upgrade plans or budget since no one ever mentioned that it would be mandatory. I attended CUE and reviewed my upgrade plans with several Lawson personnel; I met with my Client Account Manager as well as an Upgrade Manager and while the DVP subject came up again, it was only in passing.

I did not learn that it was a showstopper until I ordered, or attempted to order, the upgrade CDs. I called my Account Manager and had a rather heated discussion on the legitimacy of charging clients for something the system caused, as well as forcing me to go through Lawson and therefore put my upgrade on hold until the few resources available at the time could be scheduled. The reasoning supplied by Lawson only added fuel to the fire; it basically consisted of an admission that they had no idea what had caused the problems and therefore that Lawson was assuming that it was user-generated through the improper use of screen paints and database manipulations. Never mind the fact that it affected a large number of clients, or the fact that it occurred only in a few systems, or that the Lawson-recommended solution was to screen paint! I escalated the issue to whoever would listen. I argued that the number of affected clients easily dismissed the claim it was user-generated; I argued that I, as a client, have the ability to do screen paints and/or database manipulations on every installed system--was Lawson now going to charge for every bug fix? I argued that the DVP was not a fix but simply a clean-up utility and therefore should be left up to the client to decide whether to run or not. I argued that I really felt more than capable of running a few update programs on my own without causing any damage. I argued that assuming the problems were user-caused was too simplistic and counter-productive. I argued that the relatively low revenue that Lawson would gain would be more than offset by the negative feelings left behind by a "take it or leave it" approach. All to no avail. I lost.

The DVP was scheduled, as Lawson recommends, for a week; it took less than 2 days. The programs discovered 87 orphan records; the consultant informed me that the average for a client our size was in the thousands. Was it worth it? For whom? I have data that is slightly cleaner but the root cause has yet to be discovered, and the problems are still occurring. Lawson gained a couple of thousands in the revenue, but lost in the long run, as I am re-examining my future relationship with them.

Gain a customer, keep them for life? Not this way.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
- QUOTE OF THE ISSUE -
"There is never enough time, unless you're serving it."
- Malcolm Forbes
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

2. Say Goodbye to your "Briefing Book?"
Part of the monthly close in your organization is probably the creation of a "briefing book", or some other type of report package. Over the next couple of years, as the new concept of Business Application Monitoring (or "BAM") takes over, this could change dramatically.
BAM is another term "invented" by the Gartner Group (they also coined the term "ERP"). Gartner defines BAM as "providing real-time access to critical business performance indicators to improve the speed and effectiveness of business operations."
Remember that Enterprise Application Integration (EAI) is the concept of tying your systems more closely together (most likely in a real-time manner). BAM takes this the next level, by increasing the efficiency and integration of your corporate systems. In addition, while EAI helped "glue it together", BAM provides the means to get the promised usefulness out of EAI.
BAM promises to provide better reporting, and notification, of critical business events, much like the "management by exception" concepts that revolutionized businesses in the 1980s. Instead of printing reams of copies of the "monthly reporting package" for distribution to the board and management, BAM will deliver targeted "actionable" information: what is important, when it is important, and to whom it is important.
You are probably asking yourself, "Gee, this sounds pretty interesting, but how does it affect me now"? Well, you need to start thinking "in BAM concepts". By 2004, Gartner predicts that BAM will be one of the top 4 IT investments. So, you--as the savvy professional--need to get it on your radar screen.
Getting BAM into your systems will require overcoming the usual obstacles. Scalability will be important, as will the optimization of your application platforms to support the increased use of ad hoc queries. Data marts and pluggable frameworks will be critical to achieving success with BAM. The more standardized and better defined your data is, the easier it will be to integrate your existing systems with a BAM methodology. "Activity Modeling" consulting (just think of it like Business Process Analysis) will help determine what information is delivered, to whom, in what manner, and when.
How to get there? There will likely be the usual "build vs. buy" decisions to make, given the product offerings from the usual "top-dollar" application vendors, like Tibco, WebMethods, etc. In addition, OutlookSoft's EAP product offering provides a lot of BAM-type functionality.
The "dark horse" is Microsoft, who will be rolling several of its "business intelligence" products and technologies into a framework (code-named "Jupiter") that will be available in phases during the next 18 months. See http://www.microsoft.com/presspass/press/2002/Oct02/10-08JupiterPR.asp.
It will be interesting to see how BAM plays as part of an overall Lawson strategy. My bet is that this is where Lawson is headed with their own Smart Notification product (mixed probably with ProcessFlow), although I don't believe that it's a complete solution yet.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Is Your Finance Department Second-Rate?
Not certain how your finance department stacks up?
Here are ten markers of mediocrity:
1. Slow Closes
2. Outrageous Audit Fees
3. High DSO (Days Sales Outstanding)
4. Multiple Payments (to Vendors)
5. Earnings Restatements
6. Manual Entries
7. Lack of Transparency
8. Dubious Structures
9. Overly Cozy with Sales
10. Staff Turnover
Source: CFO Magazine, December 2002
http://www.cfo.com/Article?article=8287
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

3. Under Lawson's Covers
In the last issue, I reported on some of the enhancements that you would want if you could change any one feature in Lawson. One of these requests is to remove the "mainframe look-and-feel" of Lawson. Others have since agreed, and I have received numerous comments from you about how you'd like to see Lawson do away with some of this "clunky" behavior.
Wishful thinking-because Lawson is "to the core" COBOL (or RPG on the AS/400), and will remain that way until there's a compelling (in other words, financially lucrative!) reason to re-code it. By "re-code", I'm not talking about anything that's easy--I'm talking about a wholesale redesign.
Whatever "wrapper" you put around it--be it character-mode LID, GUI LID, JED, NED, COM+, XML UI, Portal, etc. -- (gosh, that list IS getting long)--you're still executing Lawson's "business logic" at the core. And, that core is written in COBOL (or RPG on the AS/400).
And, that core code is where the UI limitations exist. If you've ever looked at the code, you'll know what I'm talking about. To maintain a standard and consistent code base, every Lawson program looks and feels (and is written) the same way, and works on a "screen block" of data. This may-or may not-be a bad concept. Perhaps Lawson could write some middleware to fake out the underlying programs, but it would probably be too clumsy, and make matters that much worse.
Every time I hear someone telling me how Lawson is re-writing their code base to sync up with language "flavor of the week", and coming out with some new whiz-bang layer of technology, I feel like laughing and screaming: "HEY GUYS: IT'S STILL COBOL!!". A couple of years ago, I heard just that-a serious effort was underway at Lawson to re-write the Lawson applications in Java.
Rumor is that Lawson attempted to use some porting techniques to magically turn they COBOL code into Java. Problem is that both COBOL and RPG are procedural languages-Java is object-oriented. While, it's syntactically possible, and they did have some minor success, in reality it was a failure, and they group was quietly disbanded. A noble effort, I guess, but still a flawed approach.
In order to migrate from a procedural language, like COBOL, to an object-oriented language, like Java, you have to think, design, and code in a completely new way. For me, that "Aha!" moment came after working in COBOL for several years, and then learning C++ and SmallTalk. Suddenly, the world was much clearer, and computer programming actually made more sense!
Have you ever looked "under the covers" into a Lawson program? Any program can touch any table. While there is some encapsulation and modularity for convenience sake, it's nowhere close to what it would look like in a object-oriented language. Lawson's common procedure libraries are a (minor) step in the right direction.
But, procedure libraries are only a first step, and they're only as good as the programmers who write and use (or don't use) them. I remember a funny story (actually, it's a travesty) regarding some 8.x AC/BR code. Bugs kept surfacing in programs that used account category lookups. Two tables with similar prefixes (AAX and AXX) were referenced in the code. The second reference had a typo-therefore duplicating to the first lookup. And, that code kept being copied to new programs, replicating the same bug further.
As it turns out, simply using a common procedure would have eliminated them. But, wrapping up a bunch of common code into a procedure IS NOT the same as encapsulating that logic into an object.
How about inheritance? Shouldn't a sub-account inherit from an account? How about a process level inheriting from a company? Well, to Lawson's credit, there are some "inheritance" concepts (they call it "defaulting") used throughout Lawson, but it's accomplished by long blocks of procedural code. Certainly not as elegant as declaring a new object.
So, the next time you cringe at Lawson's "mainframe heritage", or hear about Lawson's new whiz-bang code "flavor of the month", take a deep breath, and remember that Lawson has a lot invested in this "legacy" code, and it won't go away anytime soon.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
What mistake do companies make the most in managing IT employees?

Lack of communication between staff and management
52%

Lack of recognition and praise
17%

Lack of flexibility in scheduling work hours
8%

Lack of authority given to employees
7%

Lack of training/development opportunities
3%

Other/don't know
13%

[Ed: Wow! Solving most of these DOESN'T COST A CENT!!!!]

Source: Robert Half Technology survey of 1,400 IT executives from U.S. companies with more than 100 employees
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

4. Reader feedback Send your comments to .

Please let me know if you'd like your name withheld or not.
- "Once again, a fabulous newsletter. I have known you for more than seven years and still really enjoy hearing what you have to say."
Some more for the "Wish List":
- "For the time accrual system to be brought into the 21st century. We have been promised a rewrite of the time accrual system since 1996 when we purchased Lawson 6.0."
- 'I agree with one of the comments in the last newsletter about eliminating the "look" of a mainframe with those "function codes." In fact, the whole software package of Portal looks like a mainframe environment. Here's a few points:
1. Need to be a more friendly approach to the type and number of screens used and the use of letters and numbers to identify pages where you make changes (i.e., PA02.1, HR06.1, etc) is mind-boggling.
2. Too much "white space" on the pages
3. Why aren't there "buttons" for ADD, CHANGE, DELETE, etc? Entering "A", "C", "D" is mainframe, not Windows.
4. When you TAB out of a field, clicking on inquiry should not be necessary. The TAB action should be loading that information automatically.
5. Should be able to toggle back and forth in panels without losing data you've entered, but not saved."

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Worthwhile Reading

Designing the Financial Data Warehouse
(Ed: For the IT pro who wonders what Finance does?)
Intelligent Enterprise, November 15, 2002
http://www.intelligententerprise.com/021115/518warehouse1_1.shtml
Incentive Confrontation
A bitter dispute over bonuses highlights the hazards of incentive pay
CFO Magazine, January 2003
http://www.cfo.com/article/1,5309,8519||M|466,00.html
Managing the Strategic IT Project
Intelligent Enterprise, November 15, 2002
http://www.intelligententerprise.com/021115/518feat3_1.shtml
Book Excerpt: Building best practices for IT
Application Development Trends, January 2003
http://www.adtmag.com/article.asp?id=7117
Unprepared for hidden costs
Packaged applications' ugly surprises include training time, integration woes
InfoWorld, January 17, 2003
http://www.infoworld.com/article/03/01/17/030120fepkgapp_1.html
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

5. Survey: CUE Predictions

Lawson's annual user conference (CUE 2003) is coming in April. Do you expect to see anything new (large or small!) unveiled at CUE this year? Whether you're going or not, I'd love to hear your ideas. But, please do not send me an answer like, "software that works"!
Here are my personal predictions:
- An early version of 9.x will be unveiled, and will have the audience moaning and groaning that they haven't even upgraded to 8.x yet!
- Much will be made of an 8.x release for the AS/400 (sorry, the iSeries!) The iSeries crowd will be dismayed that they have been relegated yet again to the back seat with the release of 9.x for everyone else!
- The often-promised and never-delivered new security model (code-named GUS) will still not be available.
Send me your predictions at

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Who is ultimately responsible for authorizing IT spending in your company?

CEO
48%

CFO
28%

CIO/CTO
15%

Business Unit Heads
9%

Source: 2003 survey of 252 executives conducted by CFO Magazine and Morgan Stanley
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

6. Lawson Tips & Tricks
Share your tips. Send them to .
a. Restrict posting on Inter-company & Inter-zone control accounts:
(Thanks to Alison Chiu at BearingPoint for this tip)
User-entered transactions should never be allowed for any system-control/clearing account, e.g. Asset Clearing. The same is true for the GL Intercompany and Zone Balancing accounts. AFTER you specify these accounts, on GL25 and GL30, respectively, you should go to the Chart of Accounts forms and restrict the usage of these accounts. A couple of notes:
1) You do not have to specify ANY systems as having detailed access to these accounts, since Lawson generates the intercompany/interzone transactions programmatically, and bypasses these edits on GL03.4/GL00.4.
2) If you need to modify the accounts (or add new relationships) on GL25/GL30, you will need to "unrestrict" these accounts temporarily while you make your changes.
3) As with all chart of accounts fields, the order of defaulting for the account restriction is 1) summary account (GL00.5), 2) detail account (GL00.4), and 3) accounting unit/detail account assignment (GL20.3).
b. Compile queue tricks:
When doing a "cobcmp" mass-compile, you probably know that you can control the number of simultaneously program compiles by using the qcontrol command, e.g. to compile 4 programs at a time:
$ qcontrol -jlocal,4
You can also set a default for this by creating/editing $LAWDIR/system/queue.cfg (%LAWDIR%/system/queue.cfg on W2K), and adding a single-line entry:
local 4
The next time the compile queue is started (stopqueue/startqueue on Unix; Stop/Start Lawson Services on W2K), this default will be used henceforth. A maximum of 50 programs may be compiled at a time.
To temporarily disable the compile queue, use (programs currently compiling will finish):
$ qcontrol -jlocal,0
To re-enable it, use:
$ qcontrol -jlocal,4

The LawsonGuru Letter is a free periodic newsletter containing provocative commentary about issues important to the Lawson Software community. The LawsonGuru Letter is published by--and is solely the opinion of--John Henley of Decision Analytics. Visit Decision Analytics at http://www.danalytics.com.To subscribe, send an email to: To be removed from the subscription list, send to:

Decision Analytics is an independent consultancy, focusing on Lawson technical projects, and specializing in customization/modification, data conversion, and integration/interfaces. Please visit http://www.danalytics.com for more information.

Decision Analytics. Integrating Lawson with the Real World.