To perform such a redesign, we pull together an improvement team from the operations for 2 to 6 weeks (depending on scope). The team members are the knowledge expert from the various aspects involved in the process, from mail room clerks to processing clerks to client-service reps to accountants. At the end of that time, the team has 1)mapped the AS IS; 2)identified problem areas and performed a root cause analysis; 3)defined principles for TO BE; 4)created the new process and documented it (including risk analysis, dependencies, benefits, change management strategy etc). Our output is a proposed new process, to be presented to senior management. The team disbands at that point, having accomplished its mandate.

We have been doing this type of work for over 8 years and found that merely subjecting this disparate team to the notions of process management can be a challenge. As we want them to “get it”, we decided to not impose the added challenge of learning to use a tool. We have found working with Post-it notes to be the most effective way to map out the AS IS and TO BE, given the team is together in one room for the duration of the project.

We do not use BPMN is our redesign projects. I have taken BPMN training to assess where it could fit and see a valuable use for this when we need to simulate a conceptual new process. I do not see a role for BPMN at the time the afore-mentioned team is convened. The team is not together long enough to be able to learn and apply effectively BPMN.

That being said, I do see a role further down the line: Upon senior management’s decision to move ahead with the recommendations, a new team is formed with the mandate to validate the (first team’s) concept and implement it. This second team can be together for a period of time extending from a few weeks to a few months, depending again on the scope of the process being implemented.

This second team would benefit from the simulation capability allowed by BPMN. Again, this is a disparate team, which very often does not include an IT member; hence it still would face a learning curve with BPMN and still be without assurance it could produce a effective BPMN model efficiently. We opted not to pursue that approach.

Instead we favor the development of BPMN expertise within the organisation. Such expertise would be brought into an improvement team from a central source. This would ensure standardized modelling and enable the central repository of processes. While working with the improvement team, the BPMN specialist should limit his models to Level 1. Further along in the implementation, when IT becomes involved to develop backend support solutions, the specialist could refine the model at the required level.

One area I still do not have clarity: Should this BPMN specialist be someone with an IT background, or someone with a statistical background? I have been going back and forth of this and currently tend to favor the latter…