In a previous post I discussed how BPM was “ERP 2.0” – I was alluding to the fact that the biggest problem with ERP in my view, is that it has become a monolithic, one-size-fits-none, nearly hard-coded vertical application.  Harsh judgment maybe, but after over 20 years in the ERP business I’ll give myself at least some right to criticize.

Countless failed ERP implementations, cost overruns, and infamous inflexibility – these problems either point to a badly flawed project management approach to ERP or (more likely) to a flawed attempt at developing and selling re-useable menu-driven functions. These functions have little else to support them, such as an awareness of where a function fits in to the organization based on standard operating procedures and strategic goals. I mean, can software or the people using it expect the ERP to know this? Yes, and I think that we should expect no less.

ERP is a loose collection of functions based on processes. Its strength – and its downfall – is how it focuses on very specific functions in the process, for example the order entry screen and how a user enters units and products and how these are validated against uncommitted inventory. This program will not likely adapt well to exceptions and it will not tell you how to report to your manager with your daily order status – if you’re lucky, this procedure will be documented somewhere in a binder somewhere. The order entry function on that screen seems to be but a small feature of the overall process of order entry.

But in a similar way that Marshall McLuhan said so famously in 1964 how “the medium is the message”, from the ERP function’s standpoint could we not go further and state how in fact the process is the function? The function that seems to be a part of a process is really one and the same, as the two become intertwined in the delivery of ultimate strategic goals.

By turning our heads sideways and viewing software development from this perspective we can move away from the constant focus on “vertical” functional requirements (those functions that on the surface appear to make our business unique) as compared to others and group us together with other organizations. Functions are the actual buttons and routines that make up applications – they tell us that what you are using is an order entry screen, or an MP3 player, or a document scanning program.

But these functions, as important as they are, are holistically part of an environment that requires organizational awareness, task awareness, collaboration, security, accountability and compliance, accessibility, performance, workflow, technological openness and, most especially, a focus on driving strategic results through a system’s built-in knowledge of organizational processes and standard operating procedures. For me, all these parts are 80% of the game in the delivery of a modern software system. Nevertheless this is exactly the 80% that ERP (and many smaller pre-package applications) fail at due to their insistence on focusing their efforts strictly on process-disconnected, menu-driven vertical functions that, in the end, organizations will wind up customizing anyway to really fit their needs. And be left without the 80% still.

In the end, functions are where the rubber meets the road but the best rubber on the hottest wheels doesn’t do much when your steering wheel is pointing you over the cliff.

If the process is the function, the “process-izing” of functions becomes the foundation upon which we can build systems which are process-aware in process-centric organizations.