Last thursday I visited a presentation about Process Acceleration (PA) [1]. PA is a Business Change method that also uses separation of concerns: it separates the end result from anything else in the business process. The end result of the process is the success state, i.e. all employees correctly submitted their billing forms and all team managers got a correct summary by mail. The emphasis lies primarely on getting the definition of the end result as accurate as possible.

I will try to give more insight into PA by using a more formal approach. In the section below I will use the definitions “success state” and “system” a lot. I will define these first:

Success state: P_1 and P_2 and … P_N

P_x (1 <= x <= N) is a predicate, for example: P_1 == (All timesheets employees are submitted), P_2 == (All submitted timesheets are correct).

System: S

S => P_i and P_i+1 and … P_i+m and Q_j and Q_j+1 and … Q_j+n

where P_i and P_i+1 and … P_i+m is a subset of our success state P_1 and P_2 and … P_N

Q_j and Q_j+1 and … Q_j+n are additional predicates, not in our success state.

Instead of system you can also read solution. A system can be an already existing system or something that can be built. To illustrate the difference between traditional strategies and the PA strategy, we will do a step by step construction towards an at first unknown success state T_success. We will start from an empty state T_empty.

Traditional strategy 1:
Step 1) Design new component C_1.
Step 2) Check new state T_1 with customer: is this state the success state? Yes: done, No: proceed.
Step 3) Design new component C_2, connect C_2 to C_1.
Step 4) Check new state T_2 with customer: is this state the success state? Yes: done, No: proceed.
Step 5) Design new component C_3, connect C_3 to C_2 and C_1.
Step 6) Check new state T_3 with customer: is this state the success state? Yes: done, No: proceed.
…

The first strategy starts building new components, one at a time. After each component is finished we check if success state is reached. This is not unlike many hobby projects where you start from scratch and build a component at a time. Once you are happy with result you have reached T_success.

Traditional strategy 2:
Step 1) Apply systems S_q, S_q+1, … , S_q+k (short: S_q’) to T_empty.
Step 2) Check new state T_k’ with customer: is this state the success state? Yes: done, No: proceed.
Step 3) Design new component C_1, add this component to S_q’.
Step 4) Check new state T_k1′ with customer: is this state the success state? Yes: done, No: proceed.
Step 5) Design new component C_2, add this component to S_q+1′.
Step 6) Check new state T_k2′ with customer: is this state the success state? Yes: done, No: proceed.
…

The second strategy starts from a combination of, most likely existing, systems. We then add components one at a time. After each component we check if we have reached the success state. This is a way of building systems which is used often when adding functionality to legacy systems.

Traditional strategy 3:
Step A.1) Apply a permutation of systems S_q, S_q+1, … , S_q+k (short: S_q’) to T_empty.
Step A.2) Check new state T_k’ with customer: is this state a good enough approximation of the success state? Yes: proceed to B.1), No: proceed.
Step A.3) Apply a different permutation of systems S_q, S_q+1, … , S_q+k (short: S_q1′) to T_empty.
Step A.4) Check new state T_k1′ with customer: is this state a good enough approximation of the success state? Yes: proceed to B.1), No: proceed.
Step A.5) Apply a different permutation of systems S_q, S_q+1, … , S_q+k (short: S_q2′) to T_empty.
…
Step B.1) Design new component C_1, add this component to previously found near success system permutation S_q”.
Step B.2) Check new state T_k1” with customer: is this state the success state? Yes: done, No: proceed.
Step B.3) Design new component C_2, add this component to previously found near success system permutation S_q”.
Step B.4) Check new state T_k1” with customer: is this state the success state? Yes: done, No: proceed.
…

The third, somewhat less traditional, starts by finding a good combination of systems. This combination should give a good approximation of the final state the customer wants to achieve. Only then you start adding new components.

Classic PA strategy:
Step A.1) Create a definition of T_success, called T_success’.
Step A.2) Check T_success’ with customer: is this state the success state? Yes: proceed to B.1), No: proceed.
Step A.3) Change the definition of T_success’ resulting in a new definition called T_success1′.
Step A.4) Check T_success1′ with customer: is this state the success state? Yes: proceed to B.1), No: proceed.
…
Step B.1) Directly derive definitions of components C_1, … C_u from best definition T_success”.
Note that C_1, …, C_u => P_1 and P_2 and … P_N must hold.
Step B.2) Match components C_1, … C_u with systems S_q, S_q+1, … , S_q+k.
Step B.3) Choose best matching(s). For these matchings T_success” must be a subset of resulting state T_matching.

PA first creates a state definition as close as possible to the success state. It then reviews and alters this state iteratively. Only when the definition is satisfactory the next phase starts. In this phase component definitions are derived from the success state definition. These component definitions are then matched with systems and the best matchings are chosen. Simplicity is important in PA: we always strive for a correct succes state with minimal size.

Note that the first two traditional strategies have no real focus on the final success state. This means that during development the chosen success state might actually be (a lot) different than the real success state. The biggest difference between the third strategy and the PA strategy is that in PA we disregard existing systems (read: solutions) until a really good success state definition has been found. Also, we extract as much information as we can from the success state definition. We then use this information to define components. Each component definition should represent a part of the success state. These component definitions should be mutually exclusive (i.e. no overlap) and all component definitions together should imply the success state. Next we match the component definitions with all known systems and come up with the best matchings. Classic PA is almost done here. We now compare the best matchings and present them, with cost figures, to the customer.

As mentioned earlier an important aspect of PA is the separation of the success state from any solution. This is important because of the reduced effort needed: anyone involved in the process can just think about the success state and can forget about (existing) systems. Depending on the number of systems this can be a serious advantage.

When there are only few solutions and the customer really doesn’t know what he or she wants, starting from an existing solution and building from that is the way to go. However, when there is one clear success state and many possible (existing) solutions PA will shine.

• [1]: http://www.procesacceleratie.nl/

Popularity: 1083 points