Together with a team, we recently completed the process analysis and redesign for a specific process area for large bank.
I wanted to share some of the experiences and a key lesson.
We took the following approach:
1. Understand current process (including visual model) , through workshops and document review
2. Deepen understanding, by finding process statistics
3. Design future state process, by using elements of Lean and common sense
Step 1 - requirements. Step 2. Activities. Step 3. Responsibilities. Step 4. KPI's
4. Analyse automation possibilities, and define use cases, non functionals and preliminary IT architecture (iterative)
5. Develop business case and different scenario's
We delivered the following, in a way a fairly complete business architecture
- A proces diagram (with annotations) current state
- A proces requirements document future state
- A proces design (logical level) future state, annotated, different levels of abstraction and use of swimlanes
- An organizational design (with FTE calculations)
- A use cases document and non-functionals document (together: software requirements)
- A preliminary IT architecture
- A cost/benefit analysis spreadsheet with different scenario's for implementation (including options such as BPO and offshoring the development of the proposed IT solutions).
All deliverables have cross-traceability (for instance a proces step links to a certain requirement, links to a certain use case and feature of the proposed IT solution). Handy for consistency checking..
Nice was the active application of Lean thoughts. For instance:
- An active focus on the customer requirements: what would a customer require in terms of proces, product and service? And what steps does a client need to take to go from need to solution- and are we able to help with these steps or simplify/reduce?
- A split of the basis flow (main proces, which can include detection of exceptions) and exception handling processen, to make sure that the main factory process continues.
- A clear split in plan-do-check-act cycle activities.
- Just In Time approach, with zero - to close to zero work-in-progress inventories
- The use of takt-time as a basis for "flow design" and calculation of effort.
Key Lesson - split requirements and design
When I was still on the techie-side of things, we had a rule "the sooner you start coding, the longer it's going to take", promoting the importance of clear requirements and a thought-through architecture. Well, I think the same is true with Future State business process modelling. In the beginning we brainstormed and modelled a bit on future state, only to realize that, together with our client, we needed to take a step back.
What we did, was the division of process abstractions in:
- A set of requirements
- A logical model (with no implementation decisions yet)
- A physical model (with implementation decisions, scenario's, such as BPO and IT)
This greatly improved and focused our effort. We were able to facilitate our client through process requirement sessions, where questions were asked such as:
- What are the goals?
- What should have been done, to consider a process instance to be done totally?
- What should be the result of the process execution? In what dimensions measured?
- What should be CSF's and KPI's?
- What stakeholders are involved? Why? In what responsibility/accountability and added value?
- What requirements will the main stakeholder, the CUSTOMER, have? (VOC).
The key strength was, that the customer started to see that certain requirements where not compatible and needed prioritization (sure, you want low cost, high quality, agility, speed, compliance all at the same time, but that's nirvana. What's most important?)
And that the procesmodelling effort for the future state was a simple exercise, using the requirements as a basis. The modelling refined some of the requirements (feedback learning), for which we used traceability and version control.
Note: in the logical procesmodel we identified different processes - from workfloor to management.
After the logical procesmodelling was done, the next step was to explore implementation choices in the steps of the process. Can we automate X, can we outsource Y? It lead to a number of scenario's and a proposed physical process design.
Although it sounds a bit top-down, through iterations we made sure that requirements, logical design and physical design were synced and improved where needed. The result - a happy client, with a sound plan for his business. Next step: getting it decided and live!
No comments:
Post a Comment