As a business owner, your processes are your children. You should get to know them intimately. Yes, you will occasionally need the advice of experts(and capital BPM can provide those experts ;), but you really should spend time with them and know them inside and out.
Diagramming your own processes is by itself an interesting question; it actually implies that the process has an owner... Which is then again a good thing :-).
I was diagramming processes in early 70s as auditor and found fraud inefficiencies etc; truly revealing! Now with next generation software which supports BPM the "diagram" is the application back to basics how business really works!
Of course it makes sense to know how your business actually works in a diagram that users and managers actually understand. Wow factor when it becomes the application at a click and easy change as no code generation so fear of change removed and that new journey begins....
If you see a reason to model your processes, you should always do it yourself.
But actually I am writing a boring story about this subject for Linkedin. It's too long to post here. Hopefeully will be ready this week.
In a nut shell; a process model is not 'a small version of reality' and it misses the dynamics of execution. A thing you definitely need, in my opinion, to understand wh y a process doesn't perform.
So, the main question still remains; why spend the time, money and effort on modeling your processes?
If you're not sure. Don't do it.
It's not a mistake because:
Of course you can ask for help from a consultant or other experienced employees. Be sure to use a diagramming language that is well known and facilitates the hard steps. The most common one is BPMN.
It's typically never a mistake, the resulting visibility, sharing of knowledge and revelations about, "do we really do that" are invaluable. However organisations must have a specific goal in mind, ideally a burning platform, time and budget. Process mapping just for the sake of it it can be a huge and costly effort and in the past these diagrams lived on a floppy disk or worse still in a paper file on a shelf, gathering dust and quickly forgotten. As Walter says with cloud based repositries there is at least the capability to share more widely, maintain and update maps more easily. BPMN also means that we have a shared language for defining and reading maps which makes them truly a global asset.
However going back to constraints unless an organisation has a specific business objective, it can be meaningless exercise, mapping the entire organisations proceses just for the sake of it can be career limiting. One organisation I've worked with recently is using Blueworks live as the enterprise tool, with BPMN the enterprise standard. The business objective is to create a library of processes to identify the low hanging fruit and move on to redesign onceall the processes are mapped This initiative has senior sponsorship but what it lacks, in my view, and therefore still likely to fail, are some early successes.
I would suggest breaking up any enterprise mapping initiatives into discrete projects, map an area and then move immediately to redesign / automation initiatives picking off the low hanging fruit. Ohterwise the endless mapping, showing no results quickly becomes a chore with little to show for your efforts. The question will soon be asked, what's the point and when the sponsor, moves on the intiative will most likely be axed. However,if you are able to show early and repeated successes, no matter how small, there is a much stronger case for the continued effort.
I am always diagramming my own processes, including operational ones - full BPMN 2.0 compliant, including boundary events, role modelling and data modelling. And then I deploy them, just for validation sake, onto my process engine. Those processes that can be contained only to my process engine domain (so excluding processes that span across systems - I am not ready for that) get to see the light of day on the company intranet as full-fledged web applications, accompanied by communication of new process and full verbatim description of objectives, roles, and process steps.
So yes, always. But then again - I'm not perfect.
No, it is not a mistake to model your own business processes. It never is, because:
Of course, this all is even more powerful if you use a BPM Suite providing automatic “model to implementation” capabilities. If it is the case, you can execute several improvement cycles (model, automate, measure, and start again) quickly.
And yet we've had so many here and elsewhere say it's a waste of time, don't do it. Including, I think (going to have to go rummage back through archives now) a couple of respondents to this thread who have poo-poo'ed it in the past. This should be fun.
In any event, as one of the presenters from #BPMCM15 correctly pointed out last week, they did it because they didn't know what they had and needed that insight before undertaking any initiative to make things better.
If it aids understanding, if it facilitates the BPM effort, "yes," documenting the "as-is" state in an understandable manner is a good thing.
Just my tuppence.
One would assume that the exercise was being done as part of a larger project to improve efficiency in the areas of interest. Given that assumption then a collaboration between the process users, management and process improvement experts to create a map between where you are and where you want to go has worked best for us.
Having the customer initially attempt to map their processes gives us a good starting point. This often allows the customer to see that many of the people involved have viewpoints that vary greatly as to how the process works. Having a process consultant help the team uncover exactly what is happening today also helps determine what changes need to be made to reach the desired process state.
Hi all !
I think is a mistake when You (when involved in the process management and execution) is not involved in the process mapping (diagram)....
This is an important step in the Business Process Management.... it brings acknoledgement about the execution of the process, it brings alignment of the people involved in the operation and clear meaning of why the process is executed... as stated by some of us here.... the diagram must be clear and must represent the reality of the things...moreover, the diagram modeling, must involve experts of the execution of process to increase the knowledge of some aspects that one can not understand alone and also to engage the team and make them feel as part of the BPM's effort.
Absolutely fascinating answers to another deceptively simple question.
1. Re "Diagram your own", I think it's now essential to consider process mining whenever we look at as-is. Reality is messy and Platonic or Soviet-style top down modelling can only take one so far.
2. Re "You", imagine the same question applied to accounting. Who is "you"? Should you or I do our own books? For sure all business people should understand accounting. But right now I'm with my accountant for year end; this is also a good thing. Lots of implications. BPM applies to "you" differently depending on your role as developer, process jockey, business analyst, business executive, C-level etc.
Everyone will eventually understand process modeling and process mining etc., just as everyone understands debits and credits and receivables and cash flow and days sales outstanding. But not everyone can design a chart of accounts appropriately or close the books or fix an accounting error.
A significant challenge addressed by both case management and (warning: shameless plug) Process Timeline is precisely that not all processes are diagram-friendly. Indeed, a key failure of BPMN and related standards is that they assume otherwise. Processes are often more easily modeled as checklists, or workback schedules, or Gantt-style project plans, or perhaps even in other ways we haven't really thought much about yet.
By the time you've decided to diagram your process, therefore, you should first have considered the question of whether a diagram makes sense in the first place.
This question is phrased in an interesting way--it's asking if an individual should diagram his/her own processes. The pitfalls of diagramming a process alone are numerous. You are in danger of getting lost in the weeds, becoming paralyzed by detail, or creating a hopeless spaghetti monster of a diagram that only you can decipher. You could also fall prey to skimming over necessary details, over-simplifying multi-step actions, forgetting possible alternatives, or just having limited knowledge of what "actually" happens each step of the way. Is it a mistake to undergo the exercise alone, regardless? Eh, probably not. Just thinking about what's going on and why is a valuable exercise.
Diagramming processes for the purpose of documenting what exists is best done by a group of SMEs who are intimately familiar with most, if not all of the steps. If nothing else, they can confirm with each other that the as-is process is truly understood and clearly identified so that more than one person can follow it. To identify improvements to the existing process or if the process can/should be removed/replaced/revamped, a group of people with varying ranges of knowledge (of an existing system) should participate in the process analysis that will likely generate a new diagram. Having non-SMEs participate in the analysis will provide fresh points of view that are not immersed in the current process. They will be able to ask questions that reveal options and possibilities for improvements that may not occur to someone "on the inside."
It IS a mistake to diagram your own processes if ANY of the following are true
- you are not clear why you are doing it
- you don't know the eventual audience of the process content
- you don't have experience of an approach which gets rapid results, and
- you cannot be impartial / avoid politics.
“If you can't describe what you are doing as a process, you don't know what you're doing.”
W. Edwards Deming
Everything you do more than once is a process.
Working it through - whether in a process diagram, decision tree or timeline - will help you see where you are doing it wrong. It is invaluable and anyone who doesn't have their own processes mapped is deluding themselves that they're in control of their business.
But we've been trained to see the diagram as the endgame, not the first iteration.
We draw our pretty diagram - perhaps even have a razzmatazz session onthe whiteboard - then the meeting finishes and everyone goes away thinking - "Done that, what's next?"
The result is that we fix the process in time and make it impossible to change. We've just left the future of our business, quite literally, on the table.
Why? Well we've only done a small bit of the job. We need to look at that process...
1. Set a vision - then see the gaps
What should the process be doing? What could it do? And why isn't it?
2. See where it fits in the bigger picture
Where has it been optimised to the detriment of other processes? Where has it accepted other processes compromising its speed or deliverables?
3. Understand the Constraints
Why are the compromises being made? And what can be done to remove them?
4. Get some more opinions on how well it works
We can get lost in our own metrics and think we're doing the right thing, while actually we are haemorrhaging customers, giving away profit or alienating users. We need a rounded 3D view, weighting soft factors as well as hard ones.
From this we can create a 4D model, not just a 2D diagram.
It can be seen from a host of different viewpoints. It has a timeline.
Now we can draw the real process diagram.
One which takes where we are and draws a line to where we want to be.
Which works out what metrics we need to measure and how those change over time.
Which allows us to constantly revisit and revise plans in the light of new stats.
A Dynamic Process to reflect a dynamic business.
“An organization's ability to learn, and translate that learning into action rapidly, is the ultimate competitive advantage.”Jack Welch
All depends, as usual.
In some enterprises everyone sees the same process differently and all departments understand an end-to-end process differently. In other (rare) enterprises the work is already properly planned and it is ready to be expressed as processes.
My general rules:
1) within a small group: processes may be done by process owners; inter-groups: processes must be done by an architect. See last three illustrations in REF1.
2) teach people to use process patterns – see REF2.
3) understanding of process “nature” of an enterprise or an organisational unit always helps: straight-through processes and ad-hoc work must be modelled differently.