- Why Business Process Management Is Different
- Implementation Guidelines
- Rule 1 - Keep It Simple
- Rule 2 - Deliver Quick Wins
- Rule 3 - Get It Wrong Quickly
- Rule 4 - Define The Scope
- Rule 5 - Define The Objectives
- Rule 6 - Define A Plan
- Rule 7 - Involve The Business - Appropriately
- Rule 8 - Measure The Results
- Rule 9 - Cultivate A Business Sponsor
- Rule 10 - Use Known And Proven Components
Implementing a Process Management system is a process, not a project.
- BPM is an enabling technology which can deliver benefit throughout an organization, it does not (only) provide a discrete solution to a discrete problem.
- This characteristic has significant implications for the way a project is scoped and phased.
Process Management is a new concept to many organizations
- it becomes particularly important to promote understanding of the technology and gain user involvement in developing a solution.
A Process Management system fundamentally affects the way people work
- a BPM project must be very sensitive to people issues, the need to promote awareness of objectives, to work in teams, to encourage feedback from users, and to manage change.
The objectives for implementing a Process Management solution are normally core to the operation of the business
- for example the objectives might be to bring new products to market more quickly, or to improve customer service levels and avoid performance penalties.
- There are often therefore big implications for getting it wrong (but also big implications for getting it right!).
A Process Management project is normally a collaborative development between IT and business
- this requires a degree of co-operation and mutual understanding that is unusual in traditional IT projects where the responsibility of the business is often restricted
- to signing off a specification of their requirements and then testing the finished system to confirm that it meets their requirements.
A Process Management solution normally incorporates a number of different technologies and tools
- with implications on the technical resources required, and complications in the configuration of suitable development and test environments, as well as in the technical design of the solution.
Given the above, there are some rules which will help guarantee success
The following guidelines constitute the condensed best practice in the implementation of a BPM system using TIBCO ActiveMatrix BPM. These guidelines draw on and consolidate the experience of TIBCO CTS Group in the implementation of a large number of BPM solutions. The guidelines will directly influence how a BPM project is planned. They are not in most cases unique to BPM projects but the characteristics of these projects, described in the previous section, make them particularly relevant.
Experience shows that the success of an IT project is inversely related to the complexity of the project. The greater the number of components in a project, the greater will be the amount of effort to complete the project and the greater will be the risk that the project will
a) go over budget b) fail to meet requirements.
This is the Golden Rule. It is particularly valid for BPM projects, because in most cases the organization deploying a BPM system has no prior experience of BPM technology (which directly contributes to risk).
This rule is another way of expressing the Golden Rule. A TIBCO ActiveMatrix BPM system is designed primarily to automate processes, not to manage documents or data. Unlike documents or data, an organization?s processes will change on a regular basis, according to the pace of change of the market in which the organization operates. TIBCO ActiveMatrix BPM makes the definition and change of business processes a relatively easy task. It is fruitless to spend many months analyzing, defining and implementing the perfect process, because a dynamic organization may have changed its processes (as a result of introducing new products or services) before its original (and now incorrect) processes have been automated. It is far better to define a narrow project scope and focus on key business problems in order to deliver short-term benefits. The Model-Driven Approch of TIBCO ActiveMatrix BPM could deliver here a lot benefits. (e.g. BOM, Forms, Pageflows, Service-Interfaces, etc.)
BPM is a unique technology in the way that it forces people to change the way they work. This change particularly affects those people who are responsible for managing work (identifying the types of work to be done, allocating the work to an appropriate work group, making sure the work gets done, monitoring productivity), because many of the management tasks will be performed automatically by the BPM system. To try and define a perfect automated business process based on the requirements of the people who operate the current manual process is like trying to draw a picture with a blindfold on. Only by implementing and using a BPM system will a business really understand how it wants to use a Business Process Management system.
The previous rules may seem to encourage a relaxed approach to scoping a BPM project. Far from it. A well-defined scope is as important for a BPM project as it is for any other IT project, and the previous rules are intended to assist in making the scope realistic and effective. A separate CTS Guideline suggests how to define the scope of a BPM system.
There is a tendency when implementing a BPM system to make the automation of an existing process a goal in its own right. This may be acceptable where the primary goal is to improve the efficiency of an existing process, and where efficiency gains are expected by virtue of replacing manual tasks (such as the allocation of work) with automatic processes. A business may however have many other reasons for implementing a BPM system, for example to make processes easier to change, to deskill processes so that resource costs are reduced, to reduce elapsed times from start to end of a process in order to improve customer service. If the goals are not defined, they are unlikely to be achieved.
Once you know the scope of a BPM project (rule 4) and you have defined the goal of the system to be implemented (rule 5), the task of defining a project plan is greatly simplified, but the importance of defining a project plan is by no means reduced. Because TIBCO ActiveMatrix BPM encourages an iterative, prototyping approach to development of automated business processes, and because many projects are set up as pilots, before attempting ?the real thing?, there is danger that project planning will be considered unnecessary. This is of course not the case. The well-known axiom applies to all types of BPM project, as much as it does to any other IT project: ?if you fail to plan, you plan to fail?.
This is another rule that is common to all IT projects, but which has particular relevance to BPM projects because of the profound impact that BPM will have on the way people work. If the people involved in current processes do not participate in the design of automated business processes, those processes are unlikely to support the day-to-day processing requirements, and when the system is implemented existing users may actively seek ways to make it fail. However if the goal of a BPM system is to radically change existing ways of working, which may also imply the need for fewer people with less skills, over-reliance on assistance from current users may be considered to be not only inappropriate but also unethical.
Even when rule 5 is remembered, and the goal of a BPM system is the pre-eminent factor in the design of the system, rule 8 is often forgotten. If the goal is to increase productivity by 50%, but the productivity before and after implementation of the system is not measured, the success of the system cannot be quantified. Consequently it is difficult to learn lessons which provide feedback and influence the implementation of the next automated business process.
A business sponsor, or perhaps a better name is a business champion, is essential to see through the implementation of a BPM system. During the course of this implementation job roles will be challenged, power bases will be threatened, substantial change will be introduced; in short many potentially fatal challenges will arise. Without an influential, committed business champion who keeps focused on the goals of the BPM system, the chance of failure is high.
It is wise to avoid building any reliance in a BPM system on a component which has never been used before, or never been used in the same way before. This applies as much to the TIBCO ActiveMatrix BPM toolkit itself, which offers increasing functionality over time, as it does to the middleware components with which TIBCO ActiveMatrix BPM will be integrated. In order to minimize the risk of unproven components, they should if possible be evaluated in a technical proving project before they become a critical component of a production system.