Implementing Business Processes

[tweetmeme source=”gosub3000”]

Introduction to Business Process Engineering

Business Process Engineering (BPR) began life in the early 1990s. Barothy, Peterhans, & Bauknecht (1995) give a good introduction to the state of Business Process Reengineering at the time, stating:

Over the last few years we have observed the emergence of a new field or phenomenon in MIS practice and research: Business Process Reengineering (BPR). Since the publication of Michael Hammer’s article “Reengineering Works: Don’t Automate, Obliterate” in 1990, reengineering became a new and hot “buzzword” in management. Despite a lack of clear understanding organisations of today cling to it as the ultimate panacea in order to realise major improvements in productivity, quality, time and profitability. They also see reengineering as a way to adapt their business to faster changing environment and as a new paradigm in the deployment of information technology (IT). In order to sell services, consulting companies never tire of glorifying success stories like the reengineering of Ford’s accounts payable, or Mutual Benefit Life’s insurance applications process both resulting in “order of magnitude” improvements. But companies also learn the hard way that the radical redesign of business processes, by fundamentally rethinking the way business is done, bears major risks, is a highly complex change task, and may easily end in failure.

Hammer & Champy (1993) define business process reengineering as “the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical, contemporary measures of performance, such as cost, quality, service and speed”. Venkatraman (1991) shows how this relates to IT, saying “… business process redesign, involving the reconfiguration of the business using IT as a central lever. Instead of treating the existing business processes as a constraint in the design of an optimum IT infrastructure, the business process itself is redesigned to maximally exploit the available IT capabilities”.

In essence, business process reengineering has become the process by which business realign their processes to make best use of IT capabilities. This is more than taking existing processes and automating them, but takes a more holistic approach to the interaction between processes and information technology. Barothy, Peterhans, & Bauknecht (1995) show how BPR has four key concepts:

  • Change task: BPR is a complex, top-down driven and planned organisational change task during which one or several business processes are fundamentally changed. The change task can be decomposed into the following generic stages: identification and analysis of current business process(es); planning, implementation and controlling of new business process(es).
  • Performance improvements: BPR strives for radical performance improvements in business processes. Frequent improvement goals are cost or time reductions, quality or service enhancements in an “order of magnitude” range (e.g. 80% time reduction in an order fulfilment process).
  • Business process: the focus point of BPR is one or several cross-functional, inter- or intra-organisational business processes defined as a “collection of activities that takes one or more kinds of input and creates an output that is of value to the customer” (Hammer & Champy, 1993)
  • Information Technology: IT is the primary enabler of new business processes. BPR does not aim to automate an existing business process but to deploy IT to enable a new business process.

Since this was realised in 1995, IT capabilities have changed dramatically. Business processes have continually tried to keep pace with IT advances by evolving to make best competitive use of IT and the information it manages. When it comes to attempting business process change, Britton & Bye (2004) suggest an iterative approach, consisting of four steps, understanding, brainstorming, clarification and analysis. We now deal with each in turn.


Understanding, as defined by Britton & Bye (2004) is “understanding the existing or proposed business process”. Understanding is the process by which a new or improved business process can be analysed at a high level.

Teng & Kettinger (1995) writing on the nature of business processes note:

A business process, according to Davenport & Short (1990) is “a set of logically related tasks performed to achieve a defined business outcome.” As such, a process can be conceptualised as operating within a traditional function to achieve a narrowly “defined business outcome” or spanning across different, but “logically related” functions to achieve broad, strategically “defined business outcomes.”

The nature of business processes is that they tend to be integrated, and cross functional, as Britton & Bye (2004) note, “business processes are integrated in many ways. Business processes can be sub processes of larger business processes, they can initiate other business processes, and they tend to share information”.

By getting an understanding of how a business process works, and how it interacts with other business process, the fault lines, constraints for data distribution, requirements for performance and requirements for data resiliency should become apparent (Britton & Bye, 2004). These are necessary to know, in order to guide the design of the supporting IT infrastructure.

Jablonski notes how business processes can be mapped to work flows saying:

Basically, workflows can be characterised as executable images of business processes. Business processes describe and explain how a business is conducted; therefore, more business related terms are used in their definitions. Workflows are executable objects; therefore, exclusively technical terms must be used to define them. Such technical terms will never appear in a description of business processes. Nevertheless, business processes and specifically their process related parts form an appropriate skeleton for the definition of workflows.

By the end of the understanding phase of business process implementation, a good knowledge of the business process, it’s relationships, and data, performance and resiliency needs should be available. Once this is available, brainstorming can begin.


Brainstorming, in many ways is analogous to design. Britton & Bye (2004) define it as, “Brainstorming is about looking at different architectural patterns and seeing which one is most appropriate for the process. Patterns can be combined to use different patterns for different subprocesses”. They note four basic patterns for business process design. Those are, single centralised application, tracking multiple centralised application, pass through and copy out/ copy in.

Single centralised application, is where a single application is responsible for several business processes, or activities. An example of this would be, who’s website is responsible for the purchasing, payment, and shipping processes involved in web sales. Buying from amazon requires putting items in a shopping cart, checking that cart out by paying for it’s contents, and then paying for shipping of the contents to your location.

Tracking multiple centralised application is where each sub-process is maintained by it’s own application, though data is shared amongst the various databases where needed, for coordination of the high level process. Taking the web shopping process as mentioned before, would be an example of multiple centralised applications. Ebay hosts auctions, and when an item is won, i.e. bought, ebay’s involvement ends. Payment is handled by other applications, though ebay shares data with if necessary to complete payment from buyer to seller. Neither ebay, nor paypal take responsibility for shipping, which must be agreed between buyer and seller, external to either system.

Pass through, takes the output of one process or sub-process and passes it as the input to the next process or sub-process. Pass though has advantages in that the databases the processes rely on are simplified to contain only the data of interest to that particular process. The disadvantage of pass through is in meeting high performance requirements as messages are passed between processes.

Copy out/ copy in is a model where individual applications copy some data out of a central database, process it, and copy their result back to the centralised database. Copy out/ copy in has many of the advantages of pass through, though coordinating between several processes working on similar data concurrently can be an issue.

Given the initial analysis done during the ‘understanding’ phase, the brainstorming phase takes care of best matching the business process or sub-process to an appropriate design pattern. Ortiz-Hernandez, Nieto-Ariza, Estrada-Esquivel, Rodriguez-Ortiz,& Montes-Rendon (2007) recommends the use of models and meta-models at this stage to maintain the interactions between processes, and to understand the conversion of business process to workflows.


Clarification is where the work of understanding and brainstorming are brought together. The clarification process attempts to produce a process implementation diagram. This shows both the business processes and the high level application design choices made during brainstorming. This implementation diagram can be shown to management, in order to get their approval.

It is also at this stage that existing applications can be considered. It would be advantageous to a business to be able to leverage existing systems and investments. During the clarification phase, the implementation diagram can show where existing systems are to become part of the new business process, or where existing systems may need modification in order to be incorporated.

Clarification also seeks to validate that this is technically possible. For example if an existing application needs some modifications to become part of the new process level design, then these need to be discussed to an appropriate level of detail during this phase. It may be there are no issues in modifying an application, or it may mean that an existing application cannot support any changes. In this case, some compromise must be reached, by assessing the possibilities of replacing that application, or redesigning the process around the existing application.

Britton & Bye (2004) recommend that the implementation model be presented in business terms so as to avoid getting bogged down in the pros and cons of technology choices. While the clarification phase needs to be cognisant of technology issues, it remains a process level activity, and defers the majority of technology choices to system implementation.


The processes of understanding, brainstorming and clarification are generally constructive processes, but analysis tends to be a destructive process. During analysis the focus is on ‘picking holes’ in the process design. To aid in this, there are several areas which need to be considered (Britton & Bye, 2004), such as performance, resiliency, error handling, data accuracy, timing constraints, migration and flexibility. Aguilar, Rautert, & Pater (1999), show how simulation can help during this phase.

Since business processes affect more than departmental applications, but how those departments work, even down to the day to day activities of individual employees, analysing for flexibility is highly important. Flexibility in a business process sense, is the ability to design a business process flexible to the business as well as the employee’s needs. Once employees become familiar with the current process, they can become resistant to change when a new process is being discussed. Designing in flexibility means that the process can be more adaptive to this situation, should it arise.

Error handling is also important. If, for example, the application supporting a sub-process was to fail, what should happen? Should a manual process take the place of the automated process? How are the two processes resynchronised at a later time when the automated process has been repaired? These are the types of issues which need discussion during error handling.

A migration plan is also needed. This should take into consideration how the existing process is to be phased out, as the new business process is to be phased in. Potentially, new applications will be coming on-line, and old applications will be decommissioned. Employees will need training on the new processes and systems. The migration plan needs to plan how to proceed from the current process to the new process in the least disruptive way possible.


As the phases of understanding, brainstorming, clarification and analysis are iterative, it is highly likely that they will be revisited several times as a new business process is defined. At the end of the design phase, a complete description of the new business process should be available, clearly defining which parts of the process are handled by employees, machines or computers. A good idea of what applications are needed, and their characteristics should also be apparent. These can become the basis of requirements for system implementers when they come to commission new IT infrastructure.

Business process implementation remains a high risk activity, as radical redesign of business processes is a “highly complex change task” (Barothy, Peterhans, & Bauknecht, 1995). Careful planning and roll-out at each stage is imperative, as the barriers to adoption of new business processes are not always technical in nature, as noted by Albers, Agarwal,& Tanniru (1994).


  1. Aguilar, M., Rautert, T., & Pater, A.J.G., (1999) Business Process Simulation: a Fundamental Step Supporting Process Centered Management. Proceedings of the 31st conference on Winter simulation. 1383 – 1392.
  2. Albers, M., Agarwal, R. & Tanniru, M. (1994) The Practice of Business Process Reengineering: Radical Planning and Incremental Implementation in an IS Organization. Proceedings of the 1994 Computer Personnel Research Conference on Reinventing IS : Managing Information Technology in Changing Organizations. 87 – 96.
  3. Barothy, T., Peterhans, M. & Bauknecht, K. (1995) Business Process Reengineering: Emergence of a New Research Field. SIGOIS Bulletin. Vol. 16, No. 1. 3 – 10.
  4. Britton, C. & Bye, P. (2004) IT Architectures and Middleware. Strategies for Building Large Integrated Systems., 2nd Edition. Boston, MA: Addison Wesley.
  5. Davenport, T.H. & Short, J.E. (1990) The New Industrial Engineering: Information Technology and Business Process Redesign. Sloan Management Review, Vol. 31, No. 4. 11 – 27
  6. Hammer, M. (1990) Reengineering Works: Don’t Automate, Obliterate. Harvard Business Review. Vol. 68, No. 4. 104 – 112.
  7. Hammer, M. & Champy, J.A. (1993) Reengineering the Corporation: a Manifesto for Business Revolution. New York, NY: Harper Collins.
  8. Jablonski, S. (1995) On the complementarity of work flow management and business process modelling. SIGOIS Bulletin. Vol. 16, No. 1. 33 – 38.
  9. Ortiz-Hernandez, J., Nieto-Ariza, E.M., Estrada-Esquivel, H., Rodriguez-Ortiz, G. & Montes-Rendon, A. (2007) A theoretical evaluation for assessing the relevance of modelling techniques in business process modelling. Proceedings of the Fourth international workshop on Software quality assurance. 102 – 107.
  10. Teng, J. & Kettinger, W.J. (1995) Business process redesign an information architecture: exploring the relationships. SIGMIS Database. Vol. 26, No. 1. 30 – 42.
  11. Venkatraman, N. (1991) IT-induced Business Reconfiguration. In Morton, S (Ed). The Corporation of the 1990s. New York, NY: Oxford University Press.

Tags: , ,

6 responses to “Implementing Business Processes”

  1. Neil Watson says :

    It seems to me that there are two bits missing here.

    First, ensuring that the objective of the business process is clear and is in line with the overall business strategy. Frequently, this is not true and ends up with a new process that is as bad as the one it replaces.

    Secondly, ensure that the old process is taken out completely when the new process is implemented. Again, it is not uncommon for the old process to run informally alongside the new process, creating waste and confusion. Example, a business that had a very good sales application for cars, but also filed 5 copies of the sales invoice, including two copies in the accounts department, one sorted by name, the other by number.

    These two are major reasons, in my experience, for BPR failing, not forgetting not getting staff buy in to the new process.

  2. ccollins says :

    Neil, it’s true, BPR is a high risk activity and ideally should only be considered when the cost to benefit ratio is high enough to justify the effort involved.

    That said, it’s understandable that businesses are risk averse, and often run the new and old processes in parallel. There needs to be a plan for phase out of the old process at some time. Otherwise you essentially fall between two stools, not getting the full benefit of either process.

    As you mentioned, getting buy in from staff is also a major component in BPR success. That said, I think a certain amount of dictation is required also. At a departmental level, staff can be reluctant to change even when the changes are for the greater good of the business.


  3. dana kayyali says :

    hello, i want to see businees process digram ebay because i have to do project for my university please help me :(

  4. ccollins says :

    By doing your project work, I would feel that I was depriving you of a learning experience.

    Use the Business Process Modelling Notation described here to begin. It is very similar to flowcharting. Just think of the typical steps a buyer or seller would make on ebay, and the processes will become apparent.


  5. dawit says :

    Can you give me some advice on how to prepare Implimentation plan after redesigning processes?

  6. ccollins says :

    Hi Dawit.

    Implementation plans come in three sizes, immediate, staged, and parallel.

    Immediate is when a day comes and you switch one system off, and the replacement system on. Everybody transitions to the new system immediately. This can only be achieved if the system data can be exported from the old system, and into the new. System users will also have to be trained on the use of the new system.

    Typically this is used for small, or less critical systems. For example if a business decides to stop using MS Office and start using OpenOffice, this could be an approach that’s workable.

    Staged is when part of an old system is decommissioned, and replaced by part of the new system. An example would be replacing sendmail with Exchange. You could replace the server, while the clients remained the same. Then once confidence is established on the server, you can begin to transition the clients to Outlook. The idea here is you replace part of the system at a time. while trying to minimise disruption to system users.

    Finally, parallel is where you run both old and new systems side by side. This is the least risky, from the business point of view. Typically this is used for the largest system changes.

    The difficulty with parallel, is ensuring that data is synchronised between the two systems, as presumably they will both be used for a common time during transition. You’ll need to define who uses which system and when, and how data is moved and maintained between them.

    Hopefully this helps in some small way. Deciding on which approach really depends on the size and business importance of the system you’re changing. Just make sure everybody that could conceivably be affected are aware, and agree to the planned changes before implementation begins.


%d bloggers like this: