|
|||||||||||||||||||||
|
February 2003
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 mailto:letter-editor@lawsonguru.com 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 mailto:letter-comments@lawsonguru.com. 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.
2. Say Goodbye to your "Briefing Book?" +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
[Ed: Wow! Solving most of these DOESN'T COST A CENT!!!!] 4. Reader feedback Please let me know if you'd like your name withheld or not. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Designing the Financial Data Warehouse 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"! +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Source: 2003 survey of 252 executives conducted by CFO Magazine and
Morgan Stanley 6. Lawson Tips & Tricks |
|||||||||||||||||||||
The LawsonGuru Letter
|
|||||||||||
