As early as the 1990s, business process design was discussed as a way to achieve radical improvements in companies. Does the current discussion involve a trend that – like business process reengineering – will soon be forgotten?
Allweyer: The foundational principles of business process reengineering were and remain correct: a consistent enterprise orientation to processes, the elimination of activities that do not add value, and the consistent use of IT to support processes comprehensively. What has proven impracticable is the rediscovery of an enterprise without considering its actual condition. The baby is often thrown out with the bathwater. And change management was also often insufficient. Without the cooperation of the affected employees, it’s impossible to run a successful change project.
Since then, it has become common knowledge that business processes – like those involved with the implementation of an ERP system – play an important role. Renewed interest in business process management has several causes. Certainly, one essential factor is technological development. Today we can thoroughly realize and control comprehensive processes across various systems and business partners. And we have learned that most failed IT projects paid too much attention to technology and too little to processes. And of course, many a company thins out its processes in light of high cost pressures as part of a search for savings. Finally, laws like Basle II or Sarbanes-Oxley force companies to deal with their processes.
All these are sound reasons for companies to study and get a better handle on their processes. That’s why it involves a long-lasting trend. The topic might disappear from the headlines after a while, but not because business process management no longer plays a role at companies. Rather, it will disappear because it has become a self-evident reality among successful enterprises.
Is there a generally accepted definition of business process management?
Allweyer: Unfortunately, no. Some speak of process management when they’re actually talking about modeling processes. Others – especially some technology manufacturers – understand business process management as the electronic execution of an automatic process by a workflow or business process management system. And still others think of the topic only through a specific lens, like quality management. The various points of view make it difficult to set up comprehensive business process management in a company. Everyone involved must understand that each point of view covers only part of the entire context.
Personally, I prefer to use a cycle to clarify the meaning of business process management. The cycle begins with strategic process management that defines the core processes and goals of the company. The next phase, process design, includes topics like modeling, simulation, and process cost accounting. The third phase, process implementation, covers implementation in an organizational sense and in the form of information systems. The fourth phase, process controlling, is often neglected. However, it’s necessary to measure key figures and to check to see if the stated goals have actually been met.
What role does technology play when setting up business process management?
Allweyer: Earlier IT system were usually not very flexible. The processes were just about cast in concrete and could be changed only with tremendous effort. Today, service-oriented architecture and business process platforms offer us very flexible systems. Such systems allow us to realize comprehensive flows across the heterogeneous systems of various manufacturers with relatively few manual interventions. Process logic is no longer hidden in the programs, so it’s much easier to use graphical process modeling to define and change it. It’s obvious that these kinds of technologies are important modules for seamless support of the cycle of business process management. Additional important modules include data warehouses, business rules engines, and portals.
Can tools comprehensively support the cycle you describe?
Allweyer: Today high-performance tools are available for all tasks of process management: customizing tools for process modeling, graphical workflow editors, and performance and balanced scorecard tools. Standard process descriptions, like those that conform to Business Process Execution Language (BPEL), can uniformly describe executable processes for business process platforms. A model-driven architecture is especially important. These approaches can realize process and data models in application software almost completely automatically.
Nonetheless, we’re still a good distance from complete support of the entire cycle with tools. First, the process descriptions used by departments and management differ a great deal from the models required for automatic processing in an information system. The difference is between intuitive, business-oriented models that appeal to human users and strongly formalized models that can be executed by a process engine or realized automatically in software. Discussions often neglect this difference.
Second, we have to distinguish between theory and practice. Theoretically, it would be good to hope for a single and central management of business processes that could control all processes. Centralized business process management would provide all the information about dealing with these processes. Companywide process monitoring and controlling can be built upon this foundation. But practice in the real world looks a lot different. The real world contains several legacy systems that can’t be replaced all at once. And in the real world, processes in many locations are not handled completely electronically. As a result, solutions for business process management make sense only in subareas. However, when the solutions are used in subareas, they don’t have the companywide information required for comprehensive process monitoring. That’s why companies need a process performance management system that covers and captures key figures on processes from various systems.
Plugging the gaps in support with tools and integrating heterogeneous systems still requires a great deal of effort. The setup and ongoing development of a companywide process management system doesn’t occur at the touch of a button.
How do the demands placed upon company departments and the IT department change with the implementation of service-oriented architectures?
Allweyer: In the future, an important core competency will be merging available services into functioning, process-oriented applications. That’s no trivial task. True, the technical connections have been standardized with Web services, but the contents of the various services must also be tuned to each other to produce a reasonable overall result.
Standard software used to be inflexible, but it did offer functionalities that were tuned to each other. The manufacturers took great care to ensure that the flows available functioned. Companies often did not model their IT-supported processes because the flows were hard-coded into the software.
If a company wants to provide a new and flexible software architecture to provide as seamless support as possible for its individual processes, it must deal with the aspects of integration that focus on content. Exact knowledge of the processes will thus become an indispensable precondition. It’s no longer nice to have process management: it’s an absolute must.
That requires new ways of thinking in many areas, especially in terms of collaboration between business departments and IT. Process orientation must be conveyed as the basic approach in all affected disciplines. Only that will enable companies to place individual considerations, such as quality management, cost management, or software development, into relation to each other within a meaningful overall context. Only a common way of thinking permits successful communication between business experts, IT personnel, engineers, and end users. And comprehensive process management is impossible without all these groups. The change from traditional, rigid systems to service-oriented architectures means that companies themselves now hold the steering wheel. If you grab the wheel, you’ve got to be able to drive!