Functional and Process Management: Tools Support
Tuesday, March 14, 2023 / Updated: April 11, 2024
Let’s start with the functional management. First, there are standalone applications – accounting, warehouse, product lifecycle management (PLM), advanced planning & scheduling (APS), etc. targeted to specific departments. Historically, these applications have appeared first as the earliest form of management was functional management.
Most organizations have a set of such applications. The IT management dislikes this “Applications Zoo”, but we must understand that it is not a disease but rather a symptom! The fragmentation of application is just a consequence of business units’ fragmentation, which is caused by the functional-hierarchical management model.
If employees and managers of different departments cannot align their efforts effectively for the benefit of the entire company and its customers, then it is clear that they will vote for the applications serving the needs of a single department. The application integration issues are also predictable because they reflect the cross-departmental integration issues.
The CIO’s are trying to deal with this issue, but it is a fight with symptoms rather than root causes. If feudal relations are prevalent in the company, the departmental managers will find a way to get the budget for local “optimization” of activities, and spend it on automation.
Alternative to standalone applications are the integrated or enterprise systems, first and foremost – ERP systems.
Historically, ERP systems have emerged as the evolution of resources and capacity planning applications (MRP – MRP II), when financial resources (i.e. accounting) and human resources were added to material resources. The big idea was to plan all resources of the enterprise, and that was encoded in the acronym ERP – Enterprise Resource Planning.
The ERP concept and software emerged in the early 90s. After a while, the concept gradually expanded to include customer relations (CRM), supply chain management (SCM), maintenance and repairs, etc.
In terms of technology, the progress of integrated applications was greatly facilitated by the emergence of commercial relational DBMS. The integration of corporate applications is primarily the integration of databases. Simply put a single database: single reference entities, no gap between material and financial transactions, etc. This was a huge step forward compared to the isolated applications, when each has “a truth of its own”, and data stored in different applications does match one another.
Yet common data is necessary but insufficient for effective cross-functional collaboration: what is crucial is end-to-end workflow. Such an attempt was made within ERP systems: according to the best practices, ERP implementation should include business processes analysis and optimization.
Unfortunately, at that time (early-mid 90’s) the understanding of how to manage end-to-end business processes was far behind the one of today. This was the era of reengineering – the period of “technocratic idealism”:
It took about 10 years, with many companies paying a high price to find out that this approach… let’s put it this way: is far from being perfect. A deep contradiction was found: ERP vendors considered the implementation as a one-time automation project while business processes are subject to frequent changes by nature.
This volatility is caused by many factors: changes in regulations, global and national business environment; ever-growing customers’ expectations; competitors challenge us with new technologies and practices etc. The companies have to respond to all this and many of them come to the conclusion that since the processes will inevitably change, strategically, it makes more sense to initiate changes in business processes to achieve a competitive advantage rather than to respond to challenges and be forced to change.
The ability to change business processes fast is a certain type of corporate culture, it requires mature process capabilities, and it supposes adequate tools support. Many companies have found that their ERP system is more a liability than an asset when it comes to the process management.
The vendors of current ERP systems followed the paradigm of reengineering that did not suppose that business processes and supporting applications will change frequently. Of course, all ERP systems are very flexible, but this is a flexibility of a concrete: when it is liquid, it can be cast into anything, but when it dries, only a hammer can help…
This became evident in the early 2000s, and as a response to this challenge BPM – Business Process Management emerged. This concept now has various interpretations, but we at Comindware follow the one laid out in the classic Smith and Fingar’s ”Business Process Management: The Third Wave”. This book positioned BPM as a holistic approach to the management of business processes in a closed loop modeling-execution-analysis and described a new class of software: BPMS. (Smith and Fingar treated BPMS acronym as “Business Process Management System”, since then it has evolved to “Business Process Management Suite”).
Any BPMS (be it SAP, Oracle or Comindware) allows you to define the processes, then add a data model, user and system interfaces, business rules, and load it all in a so-called ”Process engine” to obtain an executable system, which will assign tasks to performers (employees a.k.a. business users), call legacy applications, execute business rules, respond to events etc.
The value of BPMS is its compliance to the modern concept of business process management: they support a cycle of process design – execution – analysis, followed by a next cycle of re-design, execution, etc.
BPMS systems also comply with the principles of agile development: short iterations, reliance on live user experience, dynamic wish list of enhancements (backlog). To enable this BPMS has a strong emphasis on prototyping and graphic modeling of practically everything: processes, data, user interfaces, business rules, etc.
Thus, BPMS-based BPM provides perfect alignment of technologies, methodologies and implementation principles.
The following table compares ERP and BPM as management support tools:
Now, what prevents ERP vendors from implementing the latest achievements of business process management in their products?
Nothing, in theory. In fact, they do: modern ERP systems contain process modeling and process engines. Yet little effort has been made by ERP vendors to promote these ideas to customers. In fact, adding features to the software is lesser part of the job. Much of the problem lies in the minds of customers, developers and consultants. If you have been implementing a particular technology, methodology and an approach to project execution (see above) for two decades, it will not be easy to say “we are going to change the rules of the game!” Do you think your clients or your partners will be happy? After all, the current approach is replicated in millions of documents, in thousands of presentations, hundreds of training courses, project charter templates, etc. Why not leave it all as is as long as the sales aren’t falling?
Anyway, the fact is that advances in business process management technology did not lead to a transition of ERP-systems to a new, process-based, architecture, but rather to the development of new class of software – BPMS. From an architectural point of view, BPMS differs radically from ERP and other enterprise applications because it is not an application for the end user but a platform – the environment that makes it possible to define business processes and turn them into executable applications. From this perspective, BPMS is similar to DBMS, which is also a versatile tool for creating applications for any business area.
BPMS does not aim at replacing the ERP or any other enterprise application. The combination of both is optimal: ERP is responsible for functional management support, while BPMS supports process management. In the previous article, we noted that process management complements functional management by compensating its drawbacks. The same can be seen at the software level: BPMS is not a substitute, but rather a natural add-on to ERP and other applications.
This separation – ERP supporting functions, BPMS supporting end-to-end, cross-functional business processes – is beneficial for both sides.
The practice of ERP implementation projects show that they are predictable and not overly expensive as soon as dealing with business functions. However, the higher-level business processes are implemented, the greater the scope and coverage of the project (i.e., the more functional areas are involved), the more challenging the project. The volatility of business processes doesn’t match to the waterfall implementation methodology. It’s practically impossible to automate a business process as a one-time project: the process and therefore the software requirements change faster than consultants and programmers are able to implement them at a reasonable cost.
Installation, system configuration, initial data load are relatively easy and predictable part of ERP implementation projects. It becomes much worse when end-to-end processes are in scope. If this is the case then the implementation team should care about communication and collaboration across business unit boundaries, alignment of workflow within business units to the ultimate process goals and overall business strategy. This area is mined with conflicting interests and politics. At the end of the day, it’s not about replacing separate applications with the integrated suite – it’s about reshaping the organization culture and changing its values.
It can’t be done in a “command and conquer” style. On the other hand, it cannot last for too long either, because ERP implementation project has a schedule and deadline. The pace of business functions vs. business process automation differ too much to combine these activities in a single project and use a single tool for both tasks. The best way is to eliminate end-to-end business processes support from ERP and focus on business functions support. This is clear and predictable job and it must be done anyway as functional management is the foundation.
On the other hand, BPMS is ideal for the implementation of process management, but it’s too costly to implement standard business functions. As mentioned above, BPMS is not an “off-the-shelf” software, it implies custom design and development which a priory is more expensive. In the case of core business processes there is no real alternative because they are always company specific; in the case of the business functions standardization and ERP-based automation are justified from methodological, technical and economical standpoints.
Most organizations have a set of such applications. The IT management dislikes this “Applications Zoo”, but we must understand that it is not a disease but rather a symptom! The fragmentation of application is just a consequence of business units’ fragmentation, which is caused by the functional-hierarchical management model.
If employees and managers of different departments cannot align their efforts effectively for the benefit of the entire company and its customers, then it is clear that they will vote for the applications serving the needs of a single department. The application integration issues are also predictable because they reflect the cross-departmental integration issues.
The CIO’s are trying to deal with this issue, but it is a fight with symptoms rather than root causes. If feudal relations are prevalent in the company, the departmental managers will find a way to get the budget for local “optimization” of activities, and spend it on automation.
Alternative to standalone applications are the integrated or enterprise systems, first and foremost – ERP systems.
Historically, ERP systems have emerged as the evolution of resources and capacity planning applications (MRP – MRP II), when financial resources (i.e. accounting) and human resources were added to material resources. The big idea was to plan all resources of the enterprise, and that was encoded in the acronym ERP – Enterprise Resource Planning.
The ERP concept and software emerged in the early 90s. After a while, the concept gradually expanded to include customer relations (CRM), supply chain management (SCM), maintenance and repairs, etc.
In terms of technology, the progress of integrated applications was greatly facilitated by the emergence of commercial relational DBMS. The integration of corporate applications is primarily the integration of databases. Simply put a single database: single reference entities, no gap between material and financial transactions, etc. This was a huge step forward compared to the isolated applications, when each has “a truth of its own”, and data stored in different applications does match one another.
Yet common data is necessary but insufficient for effective cross-functional collaboration: what is crucial is end-to-end workflow. Such an attempt was made within ERP systems: according to the best practices, ERP implementation should include business processes analysis and optimization.
Unfortunately, at that time (early-mid 90’s) the understanding of how to manage end-to-end business processes was far behind the one of today. This was the era of reengineering – the period of “technocratic idealism”:
- Analyze current processes (“as-is”)
- Design the optimal business process (“to-be”)
- Develop a transition plan
- Implement new processes
- PROFIT!!!
It took about 10 years, with many companies paying a high price to find out that this approach… let’s put it this way: is far from being perfect. A deep contradiction was found: ERP vendors considered the implementation as a one-time automation project while business processes are subject to frequent changes by nature.
This volatility is caused by many factors: changes in regulations, global and national business environment; ever-growing customers’ expectations; competitors challenge us with new technologies and practices etc. The companies have to respond to all this and many of them come to the conclusion that since the processes will inevitably change, strategically, it makes more sense to initiate changes in business processes to achieve a competitive advantage rather than to respond to challenges and be forced to change.
The ability to change business processes fast is a certain type of corporate culture, it requires mature process capabilities, and it supposes adequate tools support. Many companies have found that their ERP system is more a liability than an asset when it comes to the process management.
The vendors of current ERP systems followed the paradigm of reengineering that did not suppose that business processes and supporting applications will change frequently. Of course, all ERP systems are very flexible, but this is a flexibility of a concrete: when it is liquid, it can be cast into anything, but when it dries, only a hammer can help…
This became evident in the early 2000s, and as a response to this challenge BPM – Business Process Management emerged. This concept now has various interpretations, but we at Comindware follow the one laid out in the classic Smith and Fingar’s ”Business Process Management: The Third Wave”. This book positioned BPM as a holistic approach to the management of business processes in a closed loop modeling-execution-analysis and described a new class of software: BPMS. (Smith and Fingar treated BPMS acronym as “Business Process Management System”, since then it has evolved to “Business Process Management Suite”).
Any BPMS (be it SAP, Oracle or Comindware) allows you to define the processes, then add a data model, user and system interfaces, business rules, and load it all in a so-called ”Process engine” to obtain an executable system, which will assign tasks to performers (employees a.k.a. business users), call legacy applications, execute business rules, respond to events etc.
The value of BPMS is its compliance to the modern concept of business process management: they support a cycle of process design – execution – analysis, followed by a next cycle of re-design, execution, etc.
BPMS systems also comply with the principles of agile development: short iterations, reliance on live user experience, dynamic wish list of enhancements (backlog). To enable this BPMS has a strong emphasis on prototyping and graphic modeling of practically everything: processes, data, user interfaces, business rules, etc.
Thus, BPMS-based BPM provides perfect alignment of technologies, methodologies and implementation principles.
The following table compares ERP and BPM as management support tools:
| ERP | BPM | |
| Methodology | Reengineering: as-is/to-be, transition plan from current to optimal process | Continuous improvement: processes change quickly in response to changing business needs |
| Technology | DBMS: data modeling, storage, retrieval, common database, user interfaces, queries and reports | BPMS: business process modeling, process engine, user interfaces, performance analysis and process execution monitoring |
| Implementation | Waterfall or Big Bang: one time project | Agile: program – a series of projects of different sizes, implementing radical transformations as well as evolutionary process improvements |
Nothing, in theory. In fact, they do: modern ERP systems contain process modeling and process engines. Yet little effort has been made by ERP vendors to promote these ideas to customers. In fact, adding features to the software is lesser part of the job. Much of the problem lies in the minds of customers, developers and consultants. If you have been implementing a particular technology, methodology and an approach to project execution (see above) for two decades, it will not be easy to say “we are going to change the rules of the game!” Do you think your clients or your partners will be happy? After all, the current approach is replicated in millions of documents, in thousands of presentations, hundreds of training courses, project charter templates, etc. Why not leave it all as is as long as the sales aren’t falling?
Anyway, the fact is that advances in business process management technology did not lead to a transition of ERP-systems to a new, process-based, architecture, but rather to the development of new class of software – BPMS. From an architectural point of view, BPMS differs radically from ERP and other enterprise applications because it is not an application for the end user but a platform – the environment that makes it possible to define business processes and turn them into executable applications. From this perspective, BPMS is similar to DBMS, which is also a versatile tool for creating applications for any business area.
BPMS does not aim at replacing the ERP or any other enterprise application. The combination of both is optimal: ERP is responsible for functional management support, while BPMS supports process management. In the previous article, we noted that process management complements functional management by compensating its drawbacks. The same can be seen at the software level: BPMS is not a substitute, but rather a natural add-on to ERP and other applications.
This separation – ERP supporting functions, BPMS supporting end-to-end, cross-functional business processes – is beneficial for both sides.
The practice of ERP implementation projects show that they are predictable and not overly expensive as soon as dealing with business functions. However, the higher-level business processes are implemented, the greater the scope and coverage of the project (i.e., the more functional areas are involved), the more challenging the project. The volatility of business processes doesn’t match to the waterfall implementation methodology. It’s practically impossible to automate a business process as a one-time project: the process and therefore the software requirements change faster than consultants and programmers are able to implement them at a reasonable cost.
Installation, system configuration, initial data load are relatively easy and predictable part of ERP implementation projects. It becomes much worse when end-to-end processes are in scope. If this is the case then the implementation team should care about communication and collaboration across business unit boundaries, alignment of workflow within business units to the ultimate process goals and overall business strategy. This area is mined with conflicting interests and politics. At the end of the day, it’s not about replacing separate applications with the integrated suite – it’s about reshaping the organization culture and changing its values.
It can’t be done in a “command and conquer” style. On the other hand, it cannot last for too long either, because ERP implementation project has a schedule and deadline. The pace of business functions vs. business process automation differ too much to combine these activities in a single project and use a single tool for both tasks. The best way is to eliminate end-to-end business processes support from ERP and focus on business functions support. This is clear and predictable job and it must be done anyway as functional management is the foundation.
On the other hand, BPMS is ideal for the implementation of process management, but it’s too costly to implement standard business functions. As mentioned above, BPMS is not an “off-the-shelf” software, it implies custom design and development which a priory is more expensive. In the case of core business processes there is no real alternative because they are always company specific; in the case of the business functions standardization and ERP-based automation are justified from methodological, technical and economical standpoints.
Posted on: in Old posts from bpm.com