ERP, BRP, CRM, VRM - knowing your OSS from your LBO

I just had to reply to this Nick Carr post...

accusing Krigsman of being the one who doesn't understand enterprise software, took a detour into Ross Mayfield talking about getting laid, and eventually ended up with all sorts of yo-mama-ing Enterprise Irregulars, Regulars, and Rubberneckers leaping gleefully onto the Techmeme pig pile. (Can pigs leap?) Bottom line: nobody understands nothing.

Well, yes........I guess we were earnestly yo-yo-mama-ing with Nick and the rest of the chorus (Isn't that the point of the blogosphere though), but as we've all been doing this stuff for 20 odd years (designing, building, implementing, running, fixing some serious-grade Enterprise systems) we thought we just may understand some of this stuff.

Anyway, Nick points to one of Sig's posts (I'm taking my laptop skiing over the break to see if E2.0 enlightenment hits me too ):

ERP actually stands for Easily Repeatable Process: "Processes that handle resources, from human (hiring, firing, payroll and more) to parts and products through supply chains, distribution and production. Known to be rigid, but handle events and transactions with precision and in volume. Systems deliver value through extensive reports and full control over resources. Resource oriented, transactional, event driven systems. Delivered by system vendors with roots in accounting using up to 25 year old technological solutions." But Sigurde is far more interested in the Barely Repeatable Process (BRP): "Typically exceptions to the ERPs, anything that involves people in non-rigid flows [like] the daily unplanned issues that happen in every organisation. The activities that employees spend most of their time on every day. Processes that often start with an e-mail or a call.

Precisely....any computer system is just a simulation of a real life ecosystem, and thus simplifies it - no simulation ever captures the full system. And sadly, often the more complex the simulation (and the more opaque it is) the harder it is to adapt it for the BRP

For example, take car manufacturing and supply - the western approach was to build increasingly complex MRP (later MRP 2.0, mutating into ERP) systems to control it. The Japanese just simplified it all with paper cards, lightbulbs and removing a lot of the supply chain complexity by removing the supply chain itself with JIT delivery.

The other thing about most (not all, but most) Enterprise systems today is they are based on systems that are 20 years old, and in fact many are just expansions of even older logic just coded into newer languages....and nearly all of this was built without the slightest consideration of a networked environment (this I know, my MSc was on networked enterprise software 20 years ago, it was radical then and remains unusual today in enterprise software - hence the market for EIN et al). The architecture is usually redolent of top down, mainframe based DNA - and this impacts the whole ethos of enterprise software.

The Baseband Internet shook up the supply chains first (EDI etc) as they were low bandwidth...but what has really changed in the last few years is that even the average dude at home now has the sort of bandwidth and computer power that is light years more than existed when most of today's Enterprise software was architected.

In other words, the LAMP based, Open Source sourced, distributed / widgetised / XML WebService coherent software which the broader "Web 2.0" community takes for almost a given is several generations ahead of most of the stuff sitting in the corporates today - and thus stuff that corporate systems find very hard (the "BRP" - as well as security etc) is in many cases easier - non trivial, sure, but easier - for this sort of software.

And its a hell of a lot cheaper to build and run - we are assembling software from open source components today that even a few years ago would have cost millions to develop, never mind maintain.

And this has only just started....with the emerging technology we will be breaking up enterprise applications into smaller modules and then using them interchangeably, and we will expect to be able to call on a many to many structure of databases, software modules and front end UI that we may assemple on the fly as we need it, and we will expect "the network" to manage complex messaging, identity and security.

...anyway, that all brings us to the same place as Nick:

That brings me, and Governor, to the present, and the impending web-spawned firestorm in business software.

You heard me: FIRESTORM!

And why do we think this?

(i) We're working on projects that are chipping away at it from a supply side via Open Source, XML etc (as I guess quite a lot of people debating Enterprise 2.0 are) and are starting to get a feel of the Art of the Possible

(ii) I can see that millions of consumers with big pipes and fast tins will change the dynamics of the supply side of enterprise software design structure...there is no hard and fast rule that says a lot of the functions in there have to be done there. I'm not advocating SETI 2.0, but it ain't going to be centralised like now. Also, it moves the poer - the thinking around VRM is one indication of this.

There is a view that it will be "Web 2.0" front ends and something akin to today's enterprise stuff in the back end. I don't think so....today's Enterprise stuff is largely obsolete, its a question of time and inertia (not budget - the business cases of new software are v good usually) as to how long it takes to get it out, but one of the traditional barriers - getting the data out - is much less of an issue with common network standards, and once the data is out then piping it between modular apps is far easier.