« What is the Nature of the BPM/SOA Codependence? | Home | Process is Free »
What is the Difference between ERP and BPM?
By Jim Sinur | January 8, 2008
ERP literally means Enterprise Resource Planning and BPM means Business Process Management. These are two different overlapping concepts that point to a more general fogginess around applications versus process.
If you have an ERP vendor, it does not mean you have a good enough process capability. If you have a BPM vendor, it does not mean you want to build ERP functionality with it.
If you have a platform vendor, it does not mean you have good enough process management nor would you necessarily want to build ERP functionality with it. Organizations might want a core ERP application that you extend with excellent process function. Organizations might also want to build on a standard platform and live with its process deficiencies. Organizations might also want to blend the best of both worlds.
There is confusion about packaged applications and process management. Application vendors are now claiming that they are BPM players. Platform vendors claim that they have significant intellectual property built on their platforms, so they can support the sequencing of application components/services.
The independent BPMS vendors claim that they can easily cross platforms, provide a growing number of jump-start processes around vertical and/or horizontal processes, and support application services plus intense human process activities.
Long term, they are headed in a similar general direction, but there are important issues in the details around focus, timing, lock-in, and best practices that differentiate these three classes of vendors. In reality, most organizations need all three types even though their area of overlap will continue to grow, but not converge entirely.
The ERP/Packaged Application View: There is Process in my Application
Processes are the enablers of best practices embedded in applications and BPM is considered part of the middleware infrastructure. Let’s examine the level of process functionality in application packages. They are mostly focused on transactional sequencing and straight-through processes.
Most packaged vendors have little human process support and are not focused on human interaction management. Few are leveraging true agility. Yes, some can support Service Oriented Architecture (SOA), but SOA only brings a few facets of agility. On the other hand, they will be bringing solid service/component directories to the market, but most of their existing application functionality does not yet run optimally in their newly evolving platforms.
While there is still a strong binding of the rules and processes to the application transactions, most package vendors will employ their new process function to surround their existing core/standard functionality. This will allow for a modicum of differentiation and lock organizations into their standard functionality. This is good thing, but not sufficient unless organizations are in a commodity mode.
The BPM View: There are Application Service/Composites in my Process
Applications are transactions that can be embedded in differentiating and agile processes. Let’s examine the level of best practice here. Process vendors give a powerful process platform that affords great agility and functionality, particularly around case management, content management and collaboration, but organizations have little best practices out of the box.
The exception to the rule are BPMS vendors that provide jump start processes and/or can access the service directories of the application vendors and leverage a great deal of the standard transactions available from application vendors plus wrapped legacy. For organizations that believe that excellent processes out-deliver the best transactions, process vendors will be appealing.
BPM vendors will continue to out deliver application vendors in supporting the human intensive knowledge workers and the process workers and I do not expect to see this gap narrowed soon. The scramble will be to build intellectual property and/or attract enough partners who will build on the new process platforms.
Bottom Line:
The race is on to see which vendor class can be the best process platform with the largest inventory of best practice business functionality, polices/rules and content. Organizations can expect BPM vendors to link to multiple directories and leverage legacy from multiple platforms going forward.
The challenge for these vendors will be to build best practice process templates and patterns faster than application vendors can change their platform and convert/wrap their existing best practice transactions, components and composite applications.
Topics: BPM |
January 9th, 2008 at 11:01 am
Jim - Excellent post!
I think one of the issues that arises as a result of the Business Process vs ERP debate, is the fact that once you put in an ERP package with it’s predefined ‘best practice’ processes you, as a business are locked into working the way someone else has defined rather than the way your business wants to. In certain cases this can be a definite improvement, but in other way’s you are tying your hands when it comes to being agile and moving to take advantage of a potential changing marketplace. On the other hand with the number of businesses that have chosen not to work through their own organisation to define their key business processes it is sometimes a blessing for a large ERP vendor to come in a ‘lay down the law’ about what the business processes should be.
I have linked through to this on my blog at http://www.process-cafe.com
January 9th, 2008 at 11:02 am
Actually thats http://www.process-cafe.blogspot.com
January 9th, 2008 at 3:20 pm
[...] What is the Difference between ERP and BPM? (tags: erp bpm) [...]
January 13th, 2008 at 3:31 am
Here are my two cents:
ERPs are not enough - Part I
ERPs are not enough - Part II
March 28th, 2008 at 4:56 am
One of the things which is troubling large organisations running ERP is its inflexibility. AS rightly pointed out by Gary its working in a way someone else has defined for you and also for your comepetitors using the same ERP package. So where is the defferentiator coming in? This is where BPM fits in. It allows the business to design the process the way they think best fits their enterprise. I have many clients who have implemented ERP and are now looking at adopting BPM. Is there any approach paper on how this transition can be done ensuring that the investment in ERP doesnt go waste?
cheers
Amit
March 28th, 2008 at 8:59 am
I do not have any knoweldge of such a paper, but a number of our successful clients have leveraged BPM to surround the ERP packages. This approach has the processes as the differentiator and/or the buffer between the organization/people and the ERP packages. This is an upsurging area for BPM.