I’ve written before about the elements involved in a process map. In this series of articles, I want to start at the basics and explain what a process map should contain. I’ve seen a fair few methodologies come and go. Fortunately, methodology seems to be settling down with a few interesting branches appearing. I’ve also seen and used a lot of different process mapping tools at different levels, some more like CASE tools, some more like business process management tools, some just diagramming tools.
The aims of this series
I want to work with better-written process descriptions. I want to pass on best-practice as I’ve seen it after working with a lot of process and business analysts. I’ll discuss why following the methodology is not enough on its own, nor is just creating process maps on their own.
I am not writing against any software lifecycle methodologies, any project frameworks nor am I saying one tool is better than another (although I may touch on that). What I will provide are tips for improving the process analyses that you create regardless of which tool, methodology or framework.
Why am I writing this series?
As part of my BPR activities, I’ve received a lot of process descriptions that are not detailed enough, not internally consistent, not wide enough in scope, have gaps in them…in short, not good enough. It doesn’t matter to me who did the analysis, what counts is that someone (maybe the same person) is going to have to do more work to get it up to scratch.
If the work isn’t improved, then it causes problems further down the line. Some examples of the problems caused:
- increase in customer complaints because agents can’t handle their questions
- having to hire in more people as process gaps are identified
- having longer queuing times because the the time taken to complete the process was underestimated, based on too simple a view of the process.
- delay to process implementation while the correct level of detail is captured
- stakeholder conflict as the invalid process maps highlight distrust between the operational teams and the process improvement teams
I’d prefer it if the process descriptions were defined properly in the first place. So please, distribute this.
All of the changes facing every organisation require skilled personnel, either increasing a team’s knowledge in the tools and techniques used for change or by mentoring analysts, providing guidance and supervision.
Training packages can be developed in the following:
- Service Redesign
- Business Process Reengineering
- Business Analysis
Each training package is bespoke, specifically tailored to the client’s needs.
Mentoring is a longer engagement than training, designed to offer support to your staff in their profession. For those involved in the change profession (change analysts, business analysts, business process analysts), we can provide a mentoring service; either with regular drop-ins or remote via email or onto your organisation’s existing discussion forums. This service should be considered as supplementary to the standard employee mentoring and welfare within your own organisation.
It is ideal for SME (Small-to-Medium Sized Enterprises) with one or two business analysts, but who do not have sufficient need or resources to accommodate a wider analysis function. This service provides mentoring by a senior analyst, reducing what could otherwise be an costly commitment for a small organisation and providing experience from a number of industry sectors.
Want to know more, then contact us.