To start - I am not a fan of "old school" ERP. The massive, late 90's, ERP implementations with dozens of eager Accenture consultants, and endless "customize or standardize" never impressed me much. And the control and agility promisses were highly overrated. So when anyone comes with a tool that can replace ERP, I am much interested.
However, if I read blogs stating that ERP is being replaced by BPM technology, I shiffer.
Don't get me wrong, I love BPM technology, and the changes that it's bringing in Business-IT alignment.
But a simple comparison of functional features of a BPMS versus an ERP shows that there are many ERP components that are not, or not well covered by BPMS. Of course, there as BPMS vendors that have BPMS solutions with larger featuresets and smaller. But on average, there is still a gap.
In that light we have been working at Capgemini at defining what could replace ERP. Our first focus was the services industry (and even more specific: Public administration). Based on our own experiences in platform renewals, and by studying many tenders, we were able to define a quite complete set of functionalities required to support public administrative service processes in a complete, yet agile way.
The combined set we call our "Model Service Delivery Platform". I can't go into all details at this stage, but here are a number of typical functionalities required in public service delivery:
- Customer portal - submitting requests, track & trace
- Customer contact center portal - answering questions, track & trace
- Knowledge worker portal - allow workers to access cases and perform tasks, manage performance
- Process engine - for straight through processing and human tasks coordination
- Decision management engine
- Case management - services for gathering and presenting case information, and coordinating processes and adhoc tasks
- Scan & indexing facility - for paperbased request
- Document management solution - for storing digital documents/cases, to support service delivery and comply with records regulations
- Document generation - to generate documents (and also technical messages)
- Value chain integration - to request information from other parties, or update other parties in the value chain
- Operational management information - for workers and supervisors to manage service delivery
- Improvement management information - for analysing and improving process performance
- Data storage, query and management services for storing customer, request/product data, decisions
- Identity & Access Management
Interesting to see is that there are quite a number of technical implementation scenario's possible to support these functionalities. And that's what we see and do for clients. Examples: CRM centric, ECM centric, BPMS centric, Bespoke parts.
But the key conclusion: we do not see any BPMS covering all these area's well.
It leads of course to a discussion: what is a BPMS? What are it's boundaries? My point: If I buy a BPMS, that also contains a well integrated Java development environment, and I implement the functionalities above with 10% process automation, and 90% Java, be honest: I can't say BPMS replaces ERP.
So for now, BPMS is not replacing ERP in my opinion. It's bringing very strong components that are very powerful and play a central role in our service delivery platforms. But most service delivery platforms are still a larger set of technical components, and BPMS is just one of them.
It's the reason why many isolated point solutions, based on BPMS centric implementations, stay small, or in the end get eaten by a larger architecture, with other technologies.
What the future will bring?
I see three directions:
- BPMS as platform for strong, but small point solutions (which needs integrations)
- BPMS vendors growing towards completer service delivery platforms (as we see in the Oracle Fusion approach)
- ERP vendors that innovate, and adopt these strong business technology components (ACM, BPM, BRM)
If scenario 2 and 3 do not happen, the larger IT-transformations/innovations at service organizations will stay complex programs with quite some integration work. This may seem of benefit for system integrators, but believe me, we rather see integrated platforms in which we can only focus on value for the business. Hence, our "model service delivery platform". (or in my language "Model Uitvoeringsplatform").
