Another reason why enterprise software is generally so bad

One of the main reasons is that the individual buying the software is rarely the person using the software. The individual buying the software is doing so on behalf of one party (probably a CFO or similar) but then imposing it on some others (probably some junior staff). Two issues here: Number 1 – there are plenty of opportunities for misunderstanding what is genuinely needed and what really makes sense to use; Number 2 – this approach smacks of a planned economy in which a “ministry of enterprise software” decides what software works best for us, the users. We all know that planned economies tend to underperform market economies.

Another reason is because of the divergence between what Thingamy are calling “ERP” vs “BRP”, (also described well here) or “Easily Repeatable Processes” vs “Barely Repeatable Processes”.   The argument here being that enterprise software may be quite good at automating drudge tasks like accounts payable, but that it struggles with something more fluid like strategic sourcing.

But on reflection, postulating a fundamental difference between ERP and BRP is something of an assumption.

Take brewing a cup of tea. Is this an “easily repeatable process” or an “barely repeatable process”? You’d hope that it is easily repeatable. You’d be surprised. I certainly was. I was once using an auditorium that was also being used by some students to learn process mapping. They had put up posters of their process maps for making a cup of tea on the walls. Each process was completely different. And the lecturer told me that as part of the course the students then have to try to make a cup of tea in front of the whole class by following their process map. Needless to say, they usually fail.

If it’s so hard to even define the process for making a cup of tea clearly, it should come as little surprise that the extensive process definition exercises associated with major enterprise software implementations end up delivering something that the users find themselves struggling with.


5 thoughts on “Another reason why enterprise software is generally so bad

  1. Hi Alan,

    as you note the difference between BRP and ERP is not always clear – but what I find to be the core difference is the “conditionality” of each task:

    An ERP, say a procurement process, might have simple conditions attached to single tasks like “if order is more than 10 k then send to supervisor for review first”. Pure production even less options.
    While BRP would have almost unlimited conditions for each task, meaning almost unlimited paths the flow would take after each task: A physician studying an X-ray would have many choices. And the tea brewing is similar – due to the unknown environment, is the sugar in place, what do I fancy today and so forth.

    If you want unlimited choices at each step you might as well use social software or make a meeting – or use the e-mail and work the phones as today. The trade-off is obvious as data capture relies on after-fact reports (and we all hate to write those) and little chance of learning and bettering as the process is unknown.

    Good thing though that in practical life there is no such thing as unlimited (which could allow real process structure/framework) – any business or organisation has a purpose and thus a framework that limits to a certain degree the number of choices. The physician finding you have a broken arm would not send you off playing golf in Ireland… 🙂

  2. Mike O.

    Sig is a thought leader – no question about that. I eagerly read new postings in his blog Forthcoming He certainly causes me to think. One criticism I have, however, is that the thought creates a wider gap between “what is” and “what is possible”. Moving to what is the practical application or where can I find software today that is structured to match the thought. This is the case with BPM, ERP, and BRP. What procurement tools have strong business process management and business rule utilities build into them? What are the standout examples of software that puts business processes front and center?

    There is one exception to my accord with Sig’s thoughts. It has to do with tagging . I still see tagging, specifically in relation to describing items or attribution as a key element in better managing information. Sig sees major shortcomings in the use of tags My thoughts are so ill formed that I have not been able to respond to the posting. I think that tags might help describe relationships as well. Maybe they are part of developing BPM that can account for BRPs and ERPs. I don’t know. David Weinberger has me convinced that everything is miscellaneous and that tagging brings order to disorder.

  3. Thanks Mike O!

    I certainly agree with your two criticisms – but there is still a reason behind why I’m pushing forward on these:

    1. Widening the gap between “ideas” and “reality” – agree completely that my take often cannot use current software or other technologies. That’s why I’m at it with the thingamy software,a direct result of telling myself many years ago “shut up and do something about it!’. Still doing something about it so I cheekily allow myself to keep on talking. New version for limited testing coming next week so we’re not that far from real life use.
    OK, not going to be quite perfect and all-encompassing in first iteration, but still a quantum leap methinks.

    2. Tags. I still think that tags are very useful – for the way/format we “keep” information today. But I’d rather have something that delivers more precise relationships – thus add the verbs to the sentence. Sig tagged with France can tell many stories, but add the predicator “lives in” and sense arrives.
    The problem with that is the way we keep information – in documents and forms (leftovers from the pen and paper only days) which in themselves are like “buckets of objects” and a precise relationship between a bucket-of-objects and a suitcase-of-objects makes no sense. Thus the tags being useful today.
    Better though if we could do something about the “information format” and then add more precise relationships (which equals knowledge). This we do in thingamy as well, information-holders first, then knowledge-enhancers..

  4. Hi Sig & Mike.

    Re “brewing a cup of tea”. The point of the exercise for the students is that even the most simple processes can be hard to express unambiguously. On the (admittedly rare) occasions that I make a cup of tea for my colleagues I get the different versions that they want correct whether it involves peppermint or yorkshire tea bags, milk etc. Which is why I would think this needs to be considered an easily repeatable process rather than a barely repeatable one.

    Re “a cup of tea vs a procurement process”. I recall many Ariba eProcurement implemtnations that had enormous difficulties working out what the approval rules should be. And then realising that they needed to be changed once the system had gone live. So it doesn’t fit well in my head to say that a procurement process is really that straightforward. (and this is without even taking into account the possible exceptions: what happens if the item is not in the catalogue etc).

    Perhaps a point is that at one level of abstraction, all processes are fairly straightforward. But then once you get into the details they can all get pretty complex? Just thinking out loud on this.

    On the subject of tagging. I like the way you take issue with storing information in boxes. Life is far more complex than that. This is something I wrestle with at work on quite a regular basis. The challenge is how to categorise different spend categories. Do you do it based on SIC code hierarchies? On UN/SPSC hierarchies? On ProClass hierarchies? etc. The more I use different category hierarchies the more it seems to me that they break down as often as they work well. So I love the idea of verbs with the tags. I can’t wait to see how you’ve implemented this in Thingamy.

  5. Hi Alan,

    I like to narrow down the “complexity” of a process to “what can happen after an event/task”. Tasks/events are by themselves simple, but the moment you cannot predict “what next” you’re buggered when using normal tools 🙂

    BRP is precisely that, every step is “free” within the limits of “purpose” for the organisation or flow and/or business practices. To have a system for that the flow have to allow change of path at every corner without braking the capture nor the flow, and that’s possible the moment your think “object driven” (as in beachball being thrown into a crowd…) instead of “transaction/event driven” where the transaction or event is the focus (that’s how we capture data, by creating after the fact narratives in documents and forms). Let the objects themselves (like the beachball) capture what happens to it. And voila, complexity is lowered down to life level from the model complexity level.

    Extending that thinking into accounting, which is the issue you mention: In classic double-entry accounting (since 1494) one records the transaction, slots it into a drawer, using GAAP rules and SIC codes and whatnot. A never ending source of income for accountants, reconciliation and errors. And zero possibility to flip from one GAAP to another or run more than one in parallel.

    So the question is: What is a transaction, like a sale?
    Transaction oriented: That’s when you slot a representative for the sale (say in invoice) into account #10023 (or whatever).
    Object oriented: That’s when all objects of type Widgets change owner (that’s a relationship and can be expressed with an N-triple) from us to whoever else, and if the GAAP so requires, and has left our premises. If the objects “knows’ that (from the flows) one could slap a template using queries on the back end and sum up value of say all Widgets not owned by us (and not residing at our premises) at year end minus all Widgets not owned by us (and…) at beginning of year, which in essence would give you sales according to those GAAP rules. Add another query with slightly different semantics matching another GAAP and presto two GAAP accounts in parallel without any effort.
    That way you’ll evade the issue about classification and such, simply use the actual reality facts as captured by the objects themselves.

    Sitting here building (a hospital system, shows both BRP and accounting so that’s my favourite) with new and shiny version now, kind-of-beta version (2.2. build 575) and ironing out quirks and bugs as we speak, so soon’ish… 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s