October 2002

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. Are you ready for Smart Notification?
2. Focus: The P-Card Shuffle
3. Survey: Was Lawson better off as a private company?
4. Lawson tips & tricks
5. Reader feedback

Before we get started, I want to thank all of you for the enthusiastic
response to the inaugural issue. As I said in that issue, I'll
continue this newsletter as long as there is interest, and you
continue to subscribe. Comments and topic suggestions are always
welcome at mailto:letter@lawsonguru.com.

---

1. Are you ready for Smart Notification?
For several years, I've consulted for a CIO who's "tagline" is
"The right information for the right person at the right time".

That phrase came to mind as I watched one of the most compelling
product demos at CUE: Smart Notification. You may have seen the
demo or heard about this technology, which Lawson acquired from
Keyola (http://www.lawson.com/news/0417keyola.html) just days
before CUE 2002.

In fact, the Lawson "glossy" for this new product proclaims that
Smart Notification "automatically delivers actionable information
and insights to the right people at the right time, empowering
them to act quickly and intelligently." (See
http://www.lawson.com/elements/pdf/SEPM-SS971_0702.pdf)

Smart Notification looks to be one of the more intriguing product
technologies to be introduced into the Lawson architecture since
LOGAN, which made all of the Lawson web functionality possible.

I was so excited about it (visualize the proverbial "kid in the candy
store"!), and I couldn't wait to see it in action. I kept waiting
and waiting, and was just about to give up, thinking that it had
been relegated to the development scrap heap (in fact, I had planned
on writing a feature for this issue called "Whatever happened to
Smart Notification?!"!).

Then, lo and behold, as I write this, I hear that Smart Notification
is scheduled to become generally available in September 2002.

So, just what is Smart Notification? I'm not really sure whether to
categorize it as a "workflow" product or as a reporting product--but
maybe that's just the point. It's a mixture of both--a highly-targeted
reporting and information delivery tool. It is, quite simply, an event
monitoring and notification system that "lives" in Lawson. As events
are "triggered", notifications are sent to appropriate parties. The
"coolest" part is that the notifications are formatted as text, HTML,
and XML content, including report "nuggets", graphics and charts!

Notifications can be sent to emails, PDAs, cell phone and faxes, as
well as displayed as Lawson Portal content. You can even use a "voice
translator" to send notifications as phone calls! Content can include
links back to details, presumably DrillAround-enabled.

It comes "loaded" with pre-built notifications to get you started.
And, it can be used with non-Lawson data sources.

What types of notifications would you want to use this for?
- How about notifying customers when prices change (and including
product pictures in the notification?)
- Sending an email to an employee's supervisor 30 days before an
employee's annual review is due, along with a concise report about the
employee, including various facts like their salary history and past
performance reviews?
- Notifying a project manager when actuals reach 80% of budget?
- Sending a daily receivable summary to the CFO?

Think back to last month's issue in which I wrote about "process" and
how you should use every available tool to better streamline your
processes. We now have another gizmo to use!

In fact, that may be my biggest concern about this product--we now
have one MORE reporting and "notification" product available in the
Lawson arsenal:
- WorkFlow/ProcessFlow
- Enterprise Reporting
- Services Automation
- Smart Notification
- (and let's not forget Procurement's Buyer Messages!)

It will be interesting to see what the platform availability and
requirements will be, and if you will need the 8.0.2 Environment
and Logan/IOS to run this product.

If you're an early adopter of this new product, or have plans to
deploy it, I'd love to hear from you. Send me an email at
mailto:letter@lawsonguru.com.

---

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Average IT Budget as a % of Revenue

2000? 4.31%
2001? 3.88%
2002? 3.39%

How do you rate?

Source: Information Week, 09/20/02
http://informationweek.com/story/IWK20020920S0002/
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

---

2. Focus: The P-Card Shuffle
Is there a reasonable Lawson solution for purchasing cards
("p-cards")? After working through this with my "go-to"
procurement consultant, I just don't think there's a good way...

You probably know what I'm talking about. If you're not familiar
with p-cards, they're corporate credit cards that are issued to
specific users and/or "loaned out" on an as-needed basis--essentially
a discretionary spending account. There is literally no control, and
for this reason, p-cards are not a "best practice" recommendation.
Also, it's entirely offline so there's little actual Lawson-ese
involved with the implementation. It all comes down to internal
policy and procedures.

Some people will tell you (my procurement consultant included!)
that p-cards are a cop-out. You, as a client, go to all the trouble
and expense of setting up an ERP purchasing solution, and establishing
purchasing "best practices". Then you throw it all asunder by issuing
what amounts to a "system override". However, like anything in life,
there are exceptions. In particular, you can't issue a PO for every
purchase (travel in particular), and some vendors don't accept POs--
they want a credit card! Those "oh-so-savvy" employees who know how
to "work the system" (read: bypass the purchasing department!) buy
everything on a p-card, and then...why did you implement those best
practices anyway?

However, I digress....here's my theory in a nutshell on how p-cards
should work (obviously not based on Lawson functionality!):

You need to make a purchase from a company that only accepts credit
cards (i.e. a website vendor). You enter a requisition which gets
approved and then a PO gets issued. You then go to the vendor's
website, and enter your p-card (credit card) number. You might also
enter the PO#, if the vendor offers that option. As soon as you enter
that "charge" to the p-card, it should credit a liability (i.e. credit
card payable) rather than create an invoice. When AP receives the
invoice from the credit card company, you debit the credit card
payable/liability account and cut a check to the credit card company.
Sounds simple, right? Well, not so fast.

There are a couple of issues at purchase time that make this difficult:

- P-Cards are used both by purchasing "buyers" as well as regular
employees, particularly those on travel. The "buyer" POs are for
approved requisitions, and the buyer is just using it as a means of
payment. The document trail exists -- req to PO.

- However, the "non-buyer" (let's call them a "traveler") may not even
have a requisition. Instead, they have that "discretionary spending
account" bestowed to them by virtue of being allowed to use the card.
In other words, whoever authorized them to use the card gave them, in
reality, a "blanket requisition" to spend up to the limit (if any) on
the card.

So, for the sake of argument, let's assume we can figure out who's who,
and we can treat "traveler" reqs and "buyer" POs correctly.

What about Receiving? You can't match a PO that doesn't have a
receipt, and you can't close a PO that isn't matched. Are you going
to enter a receipt for every p-card purchase? Should you?

Now, on to the fun stuff--Invoicing--And, herein lies the rub, as they
say: You have two vendors: one for purchasing; one for payment! The
matching has to be done for the purchasing vendor, but the invoice
comes from the invoice vendor--the credit card company. How the heck
do you reconcile and match that? One client I worked with showed
me--literally--stacks of credit card invoices and reconciliations back
to the purchase receipts.

The "invoice" is the credit card statement, which should be "matched"
against the PO. And, of course, there will be the "traveler" credit
card purchases without a PO. It does seem like an impossible situation
without its own module. How come Lawson hasn't paid it any attention?

So, that's where it falls apart. The credit card statement is
essentially the invoice, yet it cannot be the invoice. It MUST be an
invoice from the PO Vendor in order to match and close the PO. Plus
all the distribution coding is contained on the RQ/PO.

The argument is that you need the PO to 1) generate a commitment and
2) to track vendor purchasing (i.e. for small business utilitization,
etc). Ultimately, the client's purchasing department cares about who
the vendor is--be it Staples, Decision Analytics, etc.--for purchasing
volume, small-business utilization/reporting, etc. Purchasing isn't
interested in how the bill gets paid.

The good news is that Lawson v8.03 contains functionality in the
XML/e-Reqs self service module to interface with certain vendors to
use p-cards And requisitions, and for the first time, system logic
and accounting flow that will marry the p-card transaction. However,
there are only 3 or 4 vendors that work today (one of them being Dell).

In the meantime, if anyone has any good suggestions, or workarounds, or
you think that this would benefit from a 3rd-party solution, send me
an email at mailto:letter@lawsonguru.com, and I'll be happy to report
back in a future issue.

Many thanks to Bill Ianni for his help on this article...you can reach
Bill at mailto:billianni@yahoo.com.

---

3. Survey: Was Lawson better off as a private company?
It was truly disheartening to learn this past week about more layoffs
at Lawson. (See http://www.informationweek.com/story/IWK20020926S0005).

Over the years, I've been employed by, and consulted to, organizations
where layoffs have occurred. They are very painful, and I empathize
with those who have been laid off, as well as those who remain. It
may seem hard to believe, but many who are let go are really getting
an opportunity for a "fresh start". Some of the best career moves
I've ever seen have been the result of a layoff. So, my best wishes
for those former employees.

It's also really tough on those who remain. They all fear the next
round of layoffs (after the requisite "this is all--for now--your
jobs are safe"). They also have to clean up (figuratively, I hope)
after, and take on the duties of, their former colleagues. One of
the most awkward positions I've ever been in as a consultant is to
continue to work with a company after a large layoff. It's a
saddening, and almost morbid feeling.

The irony with this latest round is that, just a couple of days
ago, I saw a "help wanted" ad in Information Week for Lawson!

I'm disappointed by management styles that foster a "layoff mentality".
Were the employees who were let go really so bad that they couldn't
have been trained to fill other advertised/open positions? Is
planning so bad that management can't figure out how to staff?
Was their focus so unfocused that they had to refocus? Isn't
there a management responsibility to "lay itself off"? Or, was
this just a periodic housecleaning? If they were just weeding
out bad employees, then let them go quietly; don't make a big
show of it.

All this from a company that often touts itself as a friendly place
to work!

Yes, the economy's in the toilet, but I can't help but think that
this layoff is just the typical knee-jerk reaction that a public
company makes when they have to announce poor results. This is
the second major layoff since Lawson became a public company.
Have they grown too fast? Did they really need to grow to
compete? Was it really necessary for them to go public? Does
Lawson really need to embrace every new-fangled piece of technology?
Isn't it better to be great at a few things, rather than just
mediocre at a lot of things?

Which brings us to the survey:
Was Lawson better off as a private company?

Send me your vote and any thoughts to mailto:survey@lawsonguru.com.
This obviously isn't a scientific study, but I'll try and
tabulate the results, and share any comments in the next issue.

---

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Interesting Reads:

A fascinating article on Google's business model.
Fortune Small Business, September 2002
http://www.fortune.com/indexw.jhtml?channel=artcol.jhtml&doc_id=209291

Working on the Chain: With profits down and perils up, companies are
focusing on supply-chain management.
CFO Magazine, September 2002
http://www.cfo.com/article/1,5309,7619||M|366,00.html

Real Time: Businesses aren't even close to harnessing all the benefits
of their lightning-speed systems.
Information Week, September 16, 2002
http://www.informationweek.com/story/IWK20020913S0011

Finance on the Front Line: Defense contractors are benefiting from new
controls their CFOs have installed.
CFO Magazine, September 2002
http://www.cfo.com/article/1,5309,7609||M|366,00.html
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

---

4. Lawson Tips & Tricks
One often-overlooked Lawson feature on Unix/NT is the use of CACHE
settings for batch programs. Lawson's caching allows a job to "stash"
recently-read records in memory, thereby eliminating redundant calls
to the database. Of course, it's important to balance the use of
caches-use them judiciously, but don't overuse them. For example,
it may be wise to cache 5 records for GLSYSTEM and 50 records for
GLCHARTDTL, but it would be counter-productive to
cache the entire GLCHARTDTL table.

Here are some tips on using caches to reduce the runtime of your
batch programs.

Caching *only* works when the Lawson program does a direct read (e.g.
840-FIND-xxxSETn) on a table. It does nothing for sequential reads.
It does nothing for range-based (i.e. "cursor") reads (e.g.
850-FIND-BEGRNG-xxxSETn/860-FIND-NXTRNG-xxxSETn).

To effectively use caching, you REALLY need to understand the ENTIRE
COBOL program, including tables referenced in library (pdlib) routines.
Do a 'bldsh' of the program and read through the entire .cbl program
to find the hot-spots.

You don't have to recompile; just put the <program>.cfg into the
appropriate xxsrc directory, e.g., PR560.cfg goes into the
$LAWDIR/<prodline>prsrc/ directory (or %LAWDIR%/<prodline>prsrc/
for NT/W2K systems).

Entering CACHE <filename> -1 caches the entire table.

When the job completes, check /tmp/xxxxx.stats and review
the statistics.

Here's a sample for PR560.cfg:
CACHE BANKFILE 100
CACHE DEDCODE 1000
CACHE DEPTCODE 100
CACHE EMPLOYEE 10
CACHE PAYCODE 100
CACHE PRSTATE 52
CACHE PSGRELATE 100
CACHE TAXGROUP 100
CACHESTATS TRUE
STATSFILE /tmp/PR560.stats

Here's a sample for GL165.cfg:
CACHE GLCHART 10
CACHE GLINTCO 30
CACHE GLSYSTEM 10
CACHESTATS TRUE
STATSFILE /tmp/gl165.stats

For additional details, see the "Performance Tuning" section
of the Lawson Administration Guide.

---

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
"If you don't like something, change it. If you can't
change it, change your attitude. Don't complain."
- Maya Angelou
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

---

5. Reader feedback
Got an email from a reader who asked: "Will there be any tips and
tricks about UNIX/COBOL shops?"

I spend a lot of my time working with UNIX/COBOL clients, and yes,
I will do my best to provide some tips for you (see this month's tip on
caching). Of course, it's tough to transfer a reasonable amount of that
knowledge in a monthly newsletter. If you want in-depth knowledge
transfer, technical mentoring and/or training (for instance, if you
want me to teach a class on how to use Lawson's COBOL/4GL), please
contact me at mailto:letter@lawsonguru.com.

---

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: mailto:letter-subscribe@lawsonguru.com

To be removed from the subscription list, send email to:

mailto:letter-unsubscribe@lawsonguru.com

---

© Copyright 2002, Decision Analytics. All rights reserved.

 

Please share The LawsonGuru Letter in whole or in part as long

as copyright and attribution are always included.

---

Decision Analytics is an independent consultancy, focusing on Lawson

technical projects, and specializing in customization/modification,

data conversion, and integration/interfaces (including BCI/Mercator).

Please visit http://www.danalytics.com for more information.

---

Decision Analytics. Integrating Lawson in the Real World.

---