With a glass of wine in my hand I was conversing an executive from one of the above biggies when he asked me what I was up to, what my product was.
"It's enterprise software" I said, adding that "I'm not about to compete with you guys, I'm just trying to make your products irrelevant!"
Much laughter, and a highly enjoyable discussion ensued. Hats off to such free thinking individuals who does not take themselves nor their company too serious!
The current discussions about the limits of legacy ERP systems partly spurred by Cynthia Rettig's article in the Sloane Review, the launch of Workday and followed up by my fellow Enterprise Irregulars Dennis, Phil, Dan, Michael and Andrew as well as Nick Carr argues back and forth about how vulnerable (or not) the legacy ERP systems could be from attacks by newcomers like Workday or technologies/architecture like SOA.
In that discussion I am squarely in the camp of the legacy systems, that is, as long as the discussion does not question the current ways business are modelled (that's what enterprise software do after all). As that modelling method stands today they're not vulnerable at all methinks.
(OK, Workday has done an honest job in tweaking some parts of the methods, but their core model thinking remains the same - see below.)
Ah, but what if "as things stands today" changed, not by a change of tools but by a change of modelling philosophy?
Let me explain:
Use the term "business process" and it inevitably invokes images of the easily repeatable, and rather linear, processes of production, HR and supply chain (some overlapping, but you get my drift).
And for that kind of processes the legacy systems do well, mostly very well indeed. And if I were producing two million candy bars a day or handling salaries for 355,000 employees monthly I would be squarely in the do.no.touch.the.system camp. Full stop.
The legacy ERP systems are very scalable, a small production line or 56 production sites world-wide, the good legacy systems do all well and all are happy.
The fly-in-the-ointment is that somebody at some point of time have forgotten something quite important:
Everything that happens in a business or any organisation for that matter is a process. Process as in a sequence of things-that-happens to real or virtual objects so as to add value to that. Problems, wrong colour widgets, broken arms, misplaced stuff, forgotten information, suppliers that do not turn up - all states that has to be addressed, on a daily basis. And damned important they are.
Don't even have to talk about Black Swans here, just Ugly Ducklings.
That e-mail you received the other day requesting some help started an important process flow; you gave it a thought, decided to forward it to a chap you think knows more about the issue with some notes added. He responded, pointing to some research papers. Reading those you found someone in another company who seemed to know much and contacted her. Sure enough, help was available and a mail to the initiator gave him the information he needed to solve the problem. A business process as important as any procurement process, albeit barely repeatable.
Why should such smallish ad-hoc business processes not be a natural part of any enterprise software system?
Of course they should, the stuff that happens everywhere, every day, taking up most of our time is as important as anything else. That is where much of the intellectual capital of the firm is created and used.
Intellectual Capital is the core of any business or organisation. Capital with capital C. And in these days of legacy hyper efficient core process systems I would argue that it will be with IC in hand that the real competitive battles will take place out there.
This is where the discussion participants seems to concur - the legacy systems can scale vertically (size) but not well horizontally (beyond core linear processes). And if you dig deep, you might find that the executives of the big ones agrees as well.
Why?
As argued earlier the legacy systems, even the way we handle information in general, is about story telling. The events and transactions are documented, stories told about what happened as we always did while being restricted to pen and paper.
That creates data objects like forms and documents that themselves are mashups of nuclear objects - each containing information about a multitude of real world objects from people to widgets to places, all mashed up in a form or "business object". Then the mashups, sorry, business objects, are handled by an ever increasing complex number of operators - just check out SAPs BAPI list to get an idea.
It's like chemistry (or indeed nuclear science) using only molecules to model the world. Take a few molecules, rip out some interesting properties, combine in an event to create a new molecule - then document the whole process in one-sheet-forms for each event or transaction.
That does not work beyond a certain level in chemistry, nor does it work for proper business modelling.
Chemical science went on from the limitless number of substances (molecules), disentangled them and built them all from 117 known atoms, creating a rather elegant mechanism for how different atoms may react with others so as to predict reality and enable building of chemical plants (sorry for the image here, but did a Master in chemical engineering once).
And that's what's required in business modelling as well. No data objects bigger than a real world object and let the objects react to other objects when the meet in an event - and let the objects tell the story themselves by capturing all and everything that happens to them. Object driven instead of event / transaction driven. Then all reports and accounts can be built in arrears from the captured knowledge "in" the "atomic" objects.
With that model in hand modelling the non-core processes becomes quite another cup of tea, something doable. In-run flexibility is now possible, complexity suddenly diminished radically, reports and accounts truly real-time and no more reconciliation needed. And with a model that close to reality, actually because the flow and it's events and transactions are instigated by the objects, the SOX and Basel IIs of this world are all covered by default.
That's why I said "I'm not going to compete with you guys" - I'll happily take on the non-core processes, the core can follow another day if the user find that useful.
For sure, being somewhat risk-aversive I would not let loose the thingamy to flawlessly produce two million candybars a day, yet, afraid I would not sleep well while counting wrong wrappers and salty chocolate bars jumping a fence.
But perhaps one day. In the meantime I'll happily cover the 90% of time spent in daily business practices and get that into some proper flow so stuff does not fall into cracks and the crucial intellectual capital of the user firm is not lost as it is today.
Then, only then, even if I'm only half right and we do a proper job in our development the next few years I could have a hope that my second sentence - "I'm just trying to make your products irrelevant!" - would stand a chance. Wish me luck ;)
In the meantime don't throw out your fine legacy ERP systems, and good luck goes out to Workday and others who have chosen to compete directly with such excellent and sturdy stuff!
Comments