Using analogy to communicate complexity

Glen Alleman posts here on the need to ensure that analogies fit the domain.  He notes a common problem with metaphors, especially those adapted from math or science.  They sound right to the layman, but are off-key to the expert.

This insight provoked a few thought on analogies in the ERP world.  We often use analogies to convey the complexity of ERP: changing the engines on an in-flight 747 is very popular.  It sure sounds tough, doesn’t it?  And the image is powerful and vivid, but does it have anything to do with how ERP really works with your business?  Also, who has ever done something like that?

I’ve found that it is much more effective to leverage metaphors that are a bit more concrete.  For example, I’ve found that a conversation about ERP as “a model of your business that operates in real time” gets me down a better path.  We can then move on to concrete visualizations that model — from Tinker Toys, to Lincoln Logs, to K-Nex, to Lego, to Erector Sets, to HeathKits — that come from the participants, not from me.

ERP isn’t still this scary

Glen Alleman passed along this link on the ERP paradox, which appears to be that:

the end result of ERP implementations is often the opposite: less control, and efficiency; and even though the number of applications may be reduced, this advantage is often offset by the cost and effort of maintaining ERP systems.

Unfortunately, the interesting commentary at the beginning of the post is compromised by a rotten foundation: much of the commentary relies upon a 10-year-old paper based on a SAP implementation that started in 1994.   A few comments:

  • Grafting process re-engineering on to a SAP implementation: Does anyone still buy that bill of goods?  Isn’t it the industry standard to assume that core SAP processes will be good-enough practice for processes that aren’t differentiating?
  • Homogeneity vs. heterogeneity:  Heterogeneous processes are valid when driven by hard factors (e.g., statutory, regulatory, compliance, logistical requirements ) and must be questioned when driven by soft factors (e.g., this is the way we’ve always done it).  There’s also an industry angle: for example, CPG go-to-market processes are hard to globalize because they vary based on market maturity and commercial customs.
  • 9-day Upgrade Downtime:  Wow, you’d have to work at that these days; perhaps if your upgrade strategy was to burn down the data center, restore from tapes, then upgrade, you might get there.

Pareto, Saas, and the “Real World” (Part 1)

All ERP customers lament the size and complexity of their implementations.  My experience has been that they just don’t get what they’re trying to do — create a real-time model of their businesses.  Most IT folks have been used to only automating bits and pieces, without looking at how they optimized the whole.

The seduction of SaaS is that you’ll be able to get “good enough” or “roughly similar” functionality as needed, at dramatically lower cost.  The core processes will work just fine for most everyone.  Per the consultant’s mantra to calm the customer: “We want the 80:20 solution, not the perfect one, right?”  Vinnie Mirchandani has hit this theme again and again (here, here, and here)

I don’t quite buy it.  Someone, somewhere is going to have to interface with the real world.  So many of the implementation cost drivers are that last 20% of customization — RICEF+Workflow objects — which provide the bridge from bits to bricks.

  • Reports for the pointy-haired among us and the authorities
  • Interfaces to other systems — e.g., barcode readers, handhelds, RFID, etc.
  • Conversions for systems that go away
  • Enhancements that add customer-specific logic
  • Forms for Customs, Shippers, IRS, Inland Revenue, Zoll, Douane, etc.
  • Workflow for approvals, alerts, etc.

This 20% that gets talked away during process design time gets talked right back in once the business gets its hands on the solution.

%d bloggers like this: