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").
2 comments:
“…what is a BPMS? What are it's boundaries?”
Not sure that there’s any correct answer. (…and you are not the only one to ask it!)
Consider that one of the largest financial management firms in the world runs most all of their operations on a single leaders’ quadrant BPMS platform. This deployment is just one of many examples of how leaders’ quadrant BPMS can and is doing most anything that a business needs done. The counter to this example has been: “But $$$$ Co. is not running just a BPMS; they have legacy databases, reporting engines, and an arsenal of additional specialized resources also in their solution architecture.” That, of course, is true. Therein is lies the mandate for leaders’ quadrant BPMS’ to continuously identify and update integration widgets for all the popular interfaces and facilitate the unique requirements of their clients.
In this kind of context, I’m not sure it makes any difference whether someone wants to put the BPMS boundary one place or another.
A much more significant question to some might be, does the solution architectural approach best support the future state business architecture that includes continuous improvement?
“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.”
If you buy a leaders-quadrant enterprise BPMS that fosters business change (BPMS vendors litigate about this tagline), you will get a well integrated Java environment, but there also are built-in constraints to facilitate and encourage use off-the-shelf (business-useable) widgets for most everything (UI, integrations, transformations). Best-practice guard-rails exist to inhibit custom coding even though such can be done if necessary. This is now, not the future. And that’s being honest.
Since leaders’ quadrant enterprise BPMS’ already support the vast needs of business for functionalities, and since BPMS solutions are the very manifestations of business agility, I remain in the opinion camp that leaders’ quadrant BPMS’ not only can but should be replacing ERPs.
Frank Millar
Executive Director
Millar Consultants, LLC
frank.millar@millarconsultants.com
Good points. What are boundaries.
In my thinking I notice two things:
1) I have stopped talking about BPMS, but am talking about service delivery platforms, that contain various pieces of functionality, of which a number can be covered by the BPMS vendors. (And the number of pieces is growing)
2) The main issue I see is the datalayer. In the "bare bone" BPMS value proposition, the data layer is typically out of scope. That's my main point against BPMS as a ERP replacement.
However, I do see that many BPMS vendors are providing solution frameworks, consisting of prepackaged processes, screens, data definitions, rules, and.... data layers.
If BPMS vendors start delivering BPMS with a strong datamanagement solution (data modeling on conceptual, logical and implementation level) and functionality to generate and maintain database structures, we would be a step further. It would mean that I could start with a framework for a specific domain (say order 2 cash), and that I not only can adapt processes, screens, rules and dashboards, but also the databases needed to run my specific solutions.
Anyway, thanks for your comment!
Post a Comment