LawsonGuru Blog

Last summer’s reading included a significant and highly-relevant book, “The Change Function: Why Some Technologies Take Off and Others Crash and Burn” (see http://www.amazon.com/Change-Function-Technologies-Others-Crash/dp/B000NA6U2O) by Pip Coburn.  As I was reading, I naturally started to draw some parallels to some Lawson initiatives.   The gist of the Change Function is expressed by Coburn’s functional notation:

The Change Function
f (perceived crisis vs. total perceived pain of adoption)

To state this as a narrative:

Users will change their habits when the pain of their current situation is greater than their perceived pain of adopting a possible solution—this is the crux of The Change Function.

To put this in terms of Lawson, the onus is on the supplier (Lawson) to convince the buyer (you, Lawson’s client) to adopt a new product because the pain associated with implementation of the new product is less than the pain of your current crisis (i.e. maintaining the status quo).  Pretty interesting so far, isn’t it?  Let’s look at this as it applies to two keys to Lawson’s future, Landmark and LSF9.

Crisis? What Crisis?

First, let’s examine Landmark.  Now, Lawson hasn’t yet announced Landmark replacements yet for their legacy S3 product suites.  But that time will come, and Lawson will do its best to convince you to switch.  Their pitch thus far has been that you will want to switch because the technology is so cool, how could you not?  But, to the non-technologist, Lawson’s current applications really aren’t a huge problem.  Sure, some folks may consider them archaic and it may require reams of paper if you wanted to print out the source code.  But, end users couldn’t care less whether the apps are written in Landmark-generated Java, in COBOL, or in Sanskrit.  As long as they work–and they do work pretty well for the most part—why switch?

Think about it this way.  If I’m the CIO or the CFO and we have an HR application that works just fine for my organization, why would I even consider swapping it out for the Landmark HR?  Even if the upgrade is free?  I don’t get any tangible, measurable, benefits from the upgrade.  If I don’t upgrade, my costs don’t change.  Why bother?

Now if you talk to Lawson about it, they really don’t portray it as a switch per se, but claim that—by maintaining backward compatibility (in other words, keeping current by upgrading to LSF9)—you will be able plug in new Landmark apps at will and not miss a beat.  But let’s not kid ourselves.  As Coburn points out, if the vast bulk of the conversation is from and about the purveyors of the new technology, watch out: “sometimes technologists forget just how vast the chasm is between them and ‘real people’”.

Is the Change Incremental?

Coburn differentiates incremental changes from total change:

Disruptive technologies are much more likely to be adopted if they offer incremental adjustments to new users and not complete deviations from life, as we know it.

So, is Landmark an incremental change, or is it a complete deviation?   No matter what Lawson comes out with as an upgrade path, to truly take advantage of a Landmark application you would want to re-implement—not just upgrade—an application.  As an analogy, you wouldn’t just translate your procedural COBOL code into procedural Java.  You would re-architect it to take advantage of unique features in Java that aren’t available in COBOL.  Same holds for implementing a new version of an application. 

To simply upgrade with the same setup and business processes is only half the upgrade equation.  The second (and much more difficult and costly) task is to figure out why, where, and how to use all the new functionality.  And, that’s where the pain is.  Landmark also requires a shift in mindset for your IT staff.  They do have to endure a significant change—in their training, toolsets, etc.  In other words, more pain.

To sum it up, consider the Machiavelli quote that Coburn uses to introduce Chapter One:

“Nothing is more difficult than to introduce a new order.”

Now, before I leave the subject of Landmark, let me make myself clear.  I’m not condemning Landmark as a product/technology.  Time will tell if Landmark successful or not. What I’m saying is this: Lawson will have a tough sell getting clients to “upgrade” to Landmark applications.  Unless they force decommission of the pre-Landmark offering.

To be fair, Lawson has been forthright in saying that the transition to Landmark applications will be a long process, “a journey” to quote Dean Hager.  But this does provide us with a perfect illustration of Coburn’s Change Function.

Does LSF9 Suffer from the Change Function?

Enough about Landmark; let us examine LSF9.  So, how great is your current crisis?  Are you enduring enough pain to warrant an LSF9 upgrade?  Consider a typical client’s need for the LSF9 upgrade.  There are certainly some very compelling arguments for upgrading to LSF9: greater stability via Websphere, the new Lawson Security model, and more robust add-ons, like ProcessFlow Integrator, which require LSF9. 

But for a fair percentage of Lawson clients, there just isn’t compelling reason to upgrade.  If you’re just running the core apps, don’t have RMI issues, and aren’t enticed by (or don’t have the resources to implement) Lawson Security, the only driver for the upgrade is to beat the decommission date.  In other words, clients are asking “what’s in it for me?” And, this is where the Change Function applies.   As Coburn succinctly points out, crisis must precede change because change is so difficult.

Now if you’ll excuse me, I need to go change.