1. Guest Spot: FOx in SOx
(by Keri White)

I have recently been a most fortunate participant in the Sarbanes-Oxley (SOx) adventure at my company. While the SOx effort brought to light areas that my department had not considered or where we are not up to snuff, it was hardly enjoyable.

Since SOx and Section 404 are brand new doctrines, we were subjected to multiple review points by different accounting firms. Our approach involved incomplete templates regarding risks and controls, which were being perpetually modified during the documentation effort. In a word: painful. My particular responsibility was the risks and controls surrounding the Lawson system: the application, the database, the operating system and the hardware.

The 404 mandate speaks specifically to management taking responsibility for the company?s systems and practices. My IT department is a very small shop and I am the only Lawson administrator. Implementing all of the formal management oversight and approval steps required by 404 seems to be overkill. It would equate to my running to my manager for his signature for most of my daily activities. This would slow down my productivity and frustrate end-users. While I understand the reasoning for the SEC wanting to hold management responsible, I'm not sure if the creators of this regulation took into consideration the smaller business's IT shops.

Fitting Lawson into the SOx risks and controls proved to be an interesting endeavor. User security was the most common control question I encountered. Lawson's built-in security was sufficient for most of the controls. However, since my company uses Lawson's XML web front-end instead of LID, there are areas where Lawson is lacking. No transaction or activity logs are available when users perform their tasks through the web front-end and this is a hot topic in the SOx security controls area. The logs monitoring users who enter the system through LID are very general, at best. A significant security concern is that only the appropriate users perform each transaction/activity. If this is not logged by the application, and the security class the user is in is not accurate, is there any feasible way to monitor this?

Another critical control is password creation, modification and reset. As it is now, users cannot modify their Lawson passwords through Lawson XML. We are using IOS Remote with Active Directory and if we set the account to ask for a new password on the initial log in, the user will never be able to successfully enter the system because they are not prompted with a change password screen. Our solution to this was to create a custom page that is hooked into Active Directory that will handle password changes. Since this is now a federally mandated requirement, I wonder if Lawson will modify its security to handle user password modification.

Given the range of controls that IT shops will now have to comply with, will Lawson make any modifications to either supplement or answer these controls? If not, Lawson customers will be forced to integrate with third party software or create custom solutions in order to be compliant.

2. This Time Lawson's Right

I broached this subject on one of the Topica message boards a few weeks ago, and generated some controversial replies. Which means it's a hot topic and worth sharing with the larger Lawson population.

By now, you've heard that Lawson is ending support of their 7.x Unix/Windows Environment and Application products. However, if you aren't yet ready to upgrade your applications, you can choose to pay Lawson a monthly fee, in addition to your regular maintenance, for post-decommission support. In order to qualify, however, you must be on 8.x Environment/Technology, and you must have committed to a firm date for your 8.x Application upgrade.

If you're a regular reader, you know I don't hesitate to criticize Lawson when I feel it's warranted. Well, you won't find me criticizing this decision. I agree 100% with what Lawson is doing. In fact, I think they're being rather accommodating. Lawson announced the 7.x product decommissions 2 years ago, and I think Lawson deserves a lot of credit for even offering post-decommission support at all. If you were around during the 7.0->7.2 upgrade cycles, you will remember that it was offered--for a fee--by a 3rd party, not by Lawson.

Sure, we all wish we didn't have to upgrade. But, a 5-year product cycle and a 2-year decommission notice is standard and perfectly acceptable for enterprise software. This upgrade deadline has been looming for two years, and everyone should have been planning for it. Lawson cannot continue to support 7.x forever. It just doesn't make good business sense.

If you don't want to upgrade, that's certainly your right. I probably won't agree that it's the right choice, but it's still your choice. I still support some 7.0 clients who haven't upgraded. Your organization is taking a calculated risk that puts itself in jeopardy, particularly if you're using Lawson for mission-critical applications.

Compare it to keeping a piece of outdated office equipment on a maintenance contract. It's two generations behind, and the service technician recommends replacement, telling you that replacement parts will probably cost more than replacement itself. But he offers you a deal that he'll cover the parts if you double the monthly contract price. You're basically buying a bigger insurance policy. What would you do?

More importantly, why are you in this situation to begin with? Your organization may have higher priorities than upgrading Lawson, but you've had plenty of time and opportunity to upgrade. For anyone who will not be upgraded in time, you don't have my sympathy. Lawson will support you, for an extra fee. But that doesn't give you the right to grumble and complain about paying more for support, either to Lawson or to a third-party. Lawson's upgrade and migration plans have been more than fair. Ignorance and/or poor planning are not excuses.

3. Reporting, Part 1: An Introduction

Lawson Reporting Services. You've been hearing about it from Lawson if you've been to any of the recent Lawson user group meetings. And, you'll no doubt be seeing it in action if you're going to CUE.

There are so many reporting options that it quickly gets overwhelming. So, over the next few months, we're going to take an in-depth look at reporting. The primary goal of this multi-part series is to help guide you through these options, and help you understand the various options for generating reports from your Lawson database.

This month, we'll start by looking at reporting in general. Next month, we'll explore what characteristics make up a successful reporting solution. In the following months, we'll examine some specific reporting products, like Lawson Reporting Services, Crystal Reports and Crystal Enterprise, and see how those can be used to achieve your Lawson reporting. We'll take a look at the new kid on the block from Microsoft, SQL Reporting Services, and its sibling, SQL Notification Services. We'll also explore some "roll-your-own" approaches and other ways to do "reporting on the cheap", without all the fancy (and yes--often expensive) bells-and-whistles.

What is reporting?

Today's business environment requires a responsiveness that can only be achieved with timely and accurate insight into business conditions. To be successful, businesses need rapid, easy access to information about their finances, customers, and external market conditions. Modern business applications, like Lawson, capture an overwhelming amount of detailed data. The ultimate goal of reporting is to provide that data, in a useful format and with meaningful context, to the right "consumer" (whether it's an internal end user, customer, partner, supplier, regulatory agency, etc.) at the appropriate time.

It's hard to believe, but in the not-so-distant past, reporting used to be owned by the "Data Processing" department. Requests for a new report usually meant you had to wait months, or even years, for a new program to be developed. Only then could the output be delivered--usually as a stack of green-bar paper--to the user. By the time it arrived, it's likely that the information on the report was outdated, and useless. In those days, the vast majority of reports were simply dumps of batch transactions, spewing out lines and lines of data with little context. It was the responsibility of the report consumer to put it all in perspective.

Reporting has moved downstream and become decentralized. Often, individual users are responsible for developing and generating their own reports. While this approach certainly has its advantages, it also has its drawbacks. For instance, without a centralized reporting infrastructure, you may end up with "multiple versions of the truth", where various reports don't agree since they are using disjointed, disconnected, or even perhaps outdated, data.

What types of reports should I be concerned with?

Traditional traditional reporting can be characterized in a pyramid, like this:

4. Worthwhile Reading

Bursting the CMM Hype
U.S. CIOs want to do business with offshore companies with high CMM ratings. But some outsourcers exaggerate and even lie about their Capability Maturity Model scores.
CIO, March 1, 2004
http://www.cio.com/archive/030104/cmm.html

2004 InfoWorld Research Report: ERP
Our survey shows readers may not be thrilled with their ERP systems, but they've learned to live with them as a modern business necessity -- and maybe even like them a little.
Infoworld, March 22, 2004
http://www.infoworld.com/reports/12SRrrerp.html

An Integration Primer: Part I
An overview of various types of integration problems companies face and options available to address them.
Business Integration Journal, February 2004
http://www.bijonline.com/Article.asp?ArticleID=850&DepartmentID=5

Offshoring Shakes Up Developer Landscape
Offshoring is changing the nature of what it is to be a developer today, much as HMOs have changed what it is to be a doctor. What does this mean to you?
Visual Studio Magazine, March 2004
http://www.ftponline.com/vsm/2004_04/magazine/departments/ednote/

The Discreet Charm of the SMB
Increasingly, enterprise software vendors are targeting small and midsize businesses.
CFO Magazine, March 2004
http://www.cfo.com/printarticle/0,5317,12322|M,00.html?f=options

Send your comments to mailto:letter-comments@lawsonguru.com.
Some comments on the March 2004 issue (see http://www.danalytics.com/guru/letter/archive/2004-03.htm):
Regarding Lawson's offshoring initiative:
	"Congrats on another great issue of the LawsonGuru Letter. I liked the article on off-shoring. I think this will be a big political issue this coming November. I recently turned down a job to help build an Indian off-shore's healthcare portfolio of engagements because I just didn't think it was good for our economy and my kid's future. "
Regarding the article on Lawson bar coding by Bill Ianni:
	"Aren't you glossing over quite a bit here, Bill? You say: [hand held computers are] "used to interpret bar codes and then format and store small data files that are later uploaded to Lawson through a standard (delivered) interface." "...the cost for the handheld devices is usually offset by a reduction in user licensing (and training) costs for the host system(s) because all of this information is interfaced through a standard delivered Lawson program (called an API)." You don't mention who delivers the interface or what it is... Are there ready-made interfaces available from Lawson Software? Does the customer really save any costs? Can the API really do the whole job, replacing a Lawson user session? I sense that more Lawson customers should be using barcode than are. But this seems to be part of the problem - it's not easy, or cheap. Also, from my experience in barcoding, fonts aren't always a good answer. In many cases, the printer won't reproduce the correct bar spacing, and the barcodes won't scan. The most reliable approach is either a printer designed to produce barcodes, or barcode generating software. For example, the software or printer can automatically compute the correct checksum digits, which are required in some symbologies, and would not be provided by a font. I enjoyed reading the newsletter, and will look forward to the next one." And Bill's response: "Every Lawson application has a delivered transaction interface to import records. For example, if I wanted to use palm pilots to go and count my inventory or to do inventory issues and receipts, I could very easily import those transactions thru the Lawson IC500 application (which uses a single license). And now, with the licensing of MS add-ins, I can interface my Lawson data directly with an Access or Excel template. It would only take a bar code font installed in these application to read or print a bar code format. The central point of my article is that the bar code capability is a function of the handheld rather than Lawson. I think the user community doesn't always understand where one technology ends and another begins. I agree that bar coding may not be cheap, but it is getting easier, and it is certainly less expensive than manual data entry."
Finally, regarding the survey question on whether or not you're making strategic use of Lawson ProcessFlow:
	"Not yet. Why? I am a one man shop who needs help."

• There will be plenty of talk about the impending upgrade.



• Lawson Reporting Services will be portrayed as the next nirvana.



• Dean Hager will finally take the wraps off the 8.1 Environment, including the new often-promised security model (code-named GUS). Everyone forgets their complaints about needing to upgrade, and jumps on the bandwagon.



• Speaking of bands, a new generation of Little River Band fans will be created.