Decision Analytics > LawsonGuru > LawsonGuru Letter > 2004

April 2004

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 https://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: FOx in SOx
2. This Time Lawson's Right
3. Reporting, Part 1: An Introduction
4. Worthwhile Reading
5. Reader Feedback
6. Survey: It's CUE Time!
7. Lawson Tips & Tricks

This month, Keri White returns to the Guest Spot. I can now safely reveal that Keri is the true identity behind the VendorPoint pseudonym used for her previous Guest Spot: "Lawson's Excel Add-In, A Useful Data Conversion Tool?" (see https://www.danalytics.com/guru/letter/archive/2003-03.htm).

As always, if you want to take your turn in the Guest Spot--send me an email at letter-editor@lawsonguru.com.

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. [Read More]

- QUOTE OF THE ISSUE -
"Many decisions are ultimately made by the hydrostatic pressure in the boss's bladder."
- Peter Drucker

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:

- Batch/Transaction Edit Reports are still the day-to-day lifeblood of our systems. Many of these are provided and used "out-of-the-box" in the Lawson applications. However, there are some reports that are not provided, or that you want to enhance, which have to be generated by other means, be it custom Lawson programs or a 3rd-party reporting solution.

- Analysis reports are the next step up from basic transaction reports, and add value to the basic transaction reports. Perhaps they are roll-up summaries, or spreadsheets of quarterly and yearly totals.

- Scorecards and Dashboards are the tools used by the executives and directors to monitor "the pulse" of the organization. They contain very high-level figures as well as key performance indicators (KPIs), usually in a graphical format.

Proactive Notifications are not part of the traditional reporting needs pyramid. They would generally be used by the "knowledge workers and managers" layer of the pyramid, and are specialized reports containing targeted content. The intended purpose is to trigger, based on various business conditions, a response by the manager, who can quickly act on the content. Think of this as pro-active exception reporting.

Reporting Evolves into Business Intelligence

We're now evolving from simple reporting to "Business Intelligence", which focuses on adding the format and context (i.e. turning the "data" into intelligence?). While reporting may be akin to looking in the rear-view mirror, the goal of BI is to use that data to predict what's coming up in the future. Unlocking the hidden knowledge within the data allows you to gain insight into customers, markets, and even your own business performance.

Higher-performance reporting and business intelligence allow an organization to:

- Focus on the products and activities that bring the greatest ROI

- Analyze and react to sales trends and customer needs more quickly

- Ensure that financial and project performance remains aligned with strategic goals and initiatives

- Provide a focal point for collaboration with a custom portal

- Monitor critical business strategy-oriented metrics

The unified goal of reporting and business intelligence is to make all of this available to employees, vendors, and suppliers in a secure and accessible way so they can then analyze key information and drive smarter decisions via easy-to-use financial reporting, budgeting and analytical tools.

Keep in mind as you read this series of articles that this is my ideal for what is important in a reporting solution. It combines a lot of the best ideas and features that are available in the major products. No one product can "do it all" at a price you're willing to pay. So, you need to decide what characteristics are most valuable to your organization.

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

5. Reader Feedback

Send your comments to mailto:letter-comments@lawsonguru.com.

Some comments on the March 2004 issue (see https://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."

6. Survey: It's CUE Time!
It's that time of year again. Winter is fading, and the flowers are blooming...and it's time for the annual Lawson Conference and User Exchange (CUE).

Are you going? What do you expect to this year?

Here are my personal predictions:

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.

Whether you're going or not, I'd love to hear your ideas.
Send me your predictions: mailto:letter-survey@lawsonguru.com.

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

(This month's tip comes from Ian Wilson at TIAA-CREF.)

Turning on the Debug option in Lawson Portal (DEBUG=true)

We recently had serious problems when running header-detail queries in Portal in 8.0.3, and I definitely missed the .debug=true option in the older JavaScript utils. In the course of narrowing down the actual problem, I spent time searching through the supporting .js files and came across a little section invoking a debug option. I had never seen this logged or mentioned anywhere, so I'm betting there are several other people who don't know about it either, so here goes:

Depending on the version Portal, turning debug on is a simple as appending ?DEBUG=true to your Portal statement. For example:

http://<yourserver>/lawson/portal/index.htm?DEBUG=true

This pops up a debug window from where you can view AGS and DME calls, data returned from the calls, errors ... etc. It is a surprisingly comprehensive and a very useful addition to Portal. Excellent for debugging and for sniffing out some interesting AGS/DME calls.

The LawsonGuru Letter is a free periodic newsletter providing provocative commentary on 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 https://www.danalytics.com.

For subscription information, see the bottom of this message.

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

Decision Analytics. Integrating Lawson with the Real World.