1. Guest Spot: Purging Lawson Financial Data
(by Andy Smith and Mo Collette, both of Novant Health. Andy is Director of Financial Systems Support; Mo is Applications Manager - Enterprise Business Systems)

Our environment. We are running Lawson apps 7.2.4/environment 7.3.3 on a UNIX/Oracle platform. In the financials area, we run GL, AM, AP, and AC. We also run PO, IC, web reqs and other modules in our Materials Management area. We do not run HR/Payroll from Lawson.

Why purging data is important. To improve overall system performance by keeping the database lean and efficient. It improves batch run times, reduces disk space requirements, and makes online queries run more efficiently. This leads to shorter outages for database backups and would make for faster database recoveries should that become necessary. And it reduces the time required during a system conversion or upgrade. Purging retains the most critical recent data in the online environment and our archiving strategy, described below, allows access to the historical data when in rare instance that is needed.

Archiving before purging. Purging data is actually deleting data from the database and online system. As part of the purge process, Lawson provides a copy of the purged data in multiple .csv files that could potentially be used by loading the data into another version of the database or some third party product such as Microsoft Access. At Novant we considered various options before choosing to archive the data in report form only. Our approach is simple. Before purging we run reports that list the data to be purged. Then we purge the data. Should anyone need to research this historical data it is available on the reports. We actually burn these reports to CD for permanent retention. In our experience, once the data has aged to the point where we no longer need it in the online system, the need for accessing this information is very, very infrequent. It is certainly more cumbersome to access the data in report form rather than via the online system, but we have decided that the tradeoff is more than worth it. An occasional inconvenience in accessing aged data is a very small price to pay for improved on-going system performance. We considered buying or building an "'archive" product line of the system to house the purged data, but felt that the ongoing overhead could not be justified for the occasional use of this historical information. To date our users have been satisfied with this configuration.

Testing before purging. Since purging obviously updates the database, we were very careful to thoroughly and methodically test these purge processes provided by Lawson before actually running a purge in our production environment. Each application system has it's own purge program; it is usually numbered xxx300, such as AM300 and GL300. Sometimes the program has multiple purge options. The AP300 program, for instance, allows you to purge during separate runs invoices, one-time vendors, and no-activity vendors. For each of the purge processes we studied the documentation and our IT group actually studied the Lawson code in order for us to get a clear understanding of the logic behind each of the purges. We then went about trying to identify the records in our system that should be purged, based on our understanding of their logic. Using our third party reporting tool Crystal as well as some in-house developed COBOL programs, we would produce a list of records that we thought would meet the purge criteria. Then we would run the purge program in our test environment and compare the actual results against our expectations. This allowed us to not only test the process to ensure that we understand what it is doing, but also to ensure that the purge program was impacting only the records that it should. For the most part, as we ran tests of this type against each one of the purges in the financial apps, we found that the Lawson-provided purge program worked satisfactorily.

We did find that in one instance we needed to add a modification to a purge program. Before we purged aged invoices, our Purchasing department requested that we not purge invoices that were associated with POs that are still open. That made sense, because if research on a PO is needed it would be helpful to have all of the invoices in the online system. So, we added that edit to the Novant-modified version of the AP300 program.

We also found one instance where the purge program did not work. We could not get the purge of vendors with no activity to work correctly. We notified Lawson of this problem. They have recently sent us a patch, which we will be testing in the near future. Otherwise, all of the purge programs that we tested and ran in AP, AM, and GL work correctly. We determined that at this time our somewhat minimal use of the Activities module does not warrant purging data in that system.

Our strategy. I already have described one component of our strategy, that is that we retain or archive the data in report form. Our online retention strategy is as follows. For the most part we want to keep at a minimum two years' worth of transaction-level data in the online system. This is true for our AP and AM systems. So, during our annual purge, we remove data that meets the purge criteria and is more than two years old. Then during the next twelve months we build up a third year's worth of data before purging the oldest year's data. That way, we always have at a minimum two full year's-worth of data in our online system that grows to become three years-worth before we run the purge. In GL, we have decided to retain five years of transaction-level data in the online system.

Hopefully this description of our strategy and the way that we have gone about this is helpful. We feel good about our data purging strategy. We are using our Lawson financial applications in a meaningful way without allowing them to become overloaded and burdened with infrequently used historical data. We have been very thorough in our testing of the purge processes. This also has had a nice, indirect benefit in that it has allowed us to become more knowledgeable about the size and makeup of the various tables in our financial systems. And we have good documentation of these processes, so we are well positioned to thoroughly test the purge processes in the 8.0 version when we complete that upgrade.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Percentage of IT Applications Budget spent on:

Source: Information Week Research survey of Information Week 500 IT executives
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

3. Are you Active about Upgrading?
This past month, I attended one of the numerous Lawson "Upgrade Road Shows" being presented to the various user groups. If you're a Unix or Windows NT/2000 client still running v7.2.x applications, you no doubt know by now that Lawson's support for these applications will end on May 31, 2004.

So, what does this upgrade entail? On the surface, it seems pretty simple. You upgrade your 7.3.x Environment to 8.0.2 Environment and your 7.2.x applications to 8.0.3 applications, mix in some web technologies, and have your users sign on to Portal instead of LID.

No problem, you say? Well, depending on your applications, it could mean total chaos. Have you spent any time looking at version differences for the various modules? Activity Management and Invoice Matching have both undergone major overhauls; they'll require some serious study and process analysis.

Who can help you with the upgrade of your applications? You'll likely want some consulting help to discern the impact on your organization, redesign your processes, and train you users. Here Lawson advises you to work with your certified partner of choice.

On the technology side, it's a different story altogether. If you thought LOGAN was a kludge, wait until you see the 'new-and-improved' IOS (the fancy new name for LOGAN). Want to install it yourself? Guess again. Lawson mandates that the new Environment and IOS be installed by Lawson or one of their certified partners, or risk Lawson yanking your support. How many partners? Two, with two more to be named shortly. Which means there are probably a dozen people 'authorized' to install this stuff, and keep you on a "supportable" status.

So, where does your organization fit in all of this? Haven't started yet? Well, you certainly do not have my sympathy. Lawson announced the 7.2.x decommission over a year ago, and upgrading was the primary focus at last year's CUE. If you still haven't started, good luck getting anyone's attention.

With over 1200 clients still to be upgraded over the next year, Lawson has its hands full. If that statement makes you woozy, it translates to more than 100 upgrades per month! They'll be lucky to get half of them completed before the deadline. Extend the support deadline? I doubt it. Most likely they'll choose to enlist the help of one or more of their partners to provide "sunset" support, as they did with Digiterra following the 7.0.x decommission.

Couple of interesting observations about the road shows:

- Nary a mention of "Upgrade While Active". If you attended CUE last year, you couldn't escape the hype surrounding UWA, which allows you to keep your users toiling away while the upgrade programs churn in the background. Now, not a peep about UWA.

- Very thin on the actual upgrade content--new features as well as the process itself. Mostly just sales pitch for post-upgrade bolt-on products, like Smart Notification, Office Add-ins, Enterprise Reporting, etc. Many of the attendees were very disappointed, having taken an entire day away from the office, hoping learn more about the upgrade process, and not learning much at all.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
- QUOTE OF THE ISSUE -

"The world revolves around Lawson."
- John Henley
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Couple of comments on some past issues:

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

Are You the Strong, Sensitive Type?
CIOs who cultivate a sensitivity to others' needs are better managers and lead more effective organizations. Take our quiz to see where you stand.
CIO Magazine, March 1, 2003
http://www.cio.com/archive/030103/type.html

Tying It All Together
Executives are charting broad integration strategies to drive real-time business change. But the process isn't easy.
Information Week, March 17, 2002
http://www.informationweek.com/story/IWK20030314S0004

The New Frontier
In an increasingly commoditized product landscape, customer satisfaction may be the only way to differentiate your company from its competitors.
Intelligent Enterprise, April 5, 2003
http://www.intelligententerprise.com/030405/606enterprise1_1.shtml

You're Not CFO Material
Ten signs you're never going to make it to the big chair.
CFO Magazine, March 2003
http://www.cfo.com/article/1,5309,8874,00.html?f=features

Goal Oriented
Companies are using software to help their employees set and meet individual and business goals.
Information Week, March 10, 2003
http://www.informationweek.com/story/IWK20030307S0008

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

6. Lawson Tips & Tricks
Share your tips. Send them to mailto:letter-tips@lawsonguru.com.

a.  This one threw me for a loop, so I wanted to share it with you:  On the Windows 2000 platform, you MUST be a member of the NT Administrator group that you specify in the Lawson Environment Configuration (laconfig) in order to run the "lawsec" utility (to turn Lawson security on/off).  Even if you're set up as a Security Officer in laua.  And, yes, it's in the documentation. 

b.  You use process level security to protect your employee HR data, and use separate process levels for corporate employees as well as each field office.  On HR11, field office employees can't inquire on home offices employees, etc.  However, drill-around is a different story--process level security is not applied.  You'll need to employ file security conditions, unique to the particular security class, in order to protect the data.  Even then, there will be cases where even that isn't possible, particularly when a table doesn't have ANY organization data (e.g., company/process level/department) in it (i.e. EMDEPEND, etc.).  The best may be able to do in that case is either to live with it, or remove it from drill-around altogether.

 

---