A point brought up at last week's [url="http://bpmandcasemanagement.com/"]BPM and Case Management Summit[/url]: Is it a mistake to try to diagram your own processes? What do you think?
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.
Yes and No...
[i]It's yes, a mistake when:[/i]
You map your own processes in a way only you understand (and -this does happen- eventually you also don't get it anymore :-) )
Funny enough, this happens all the time and manifests in zillions of Visio's, Powerpoints stored at local harddrives or burried in some Sharepoint sub-sub-sub-site. The fun part by the way, is when a specialist wants to share a A0 poster with an innocent business bystander...
[i]It's no, not a mistake when:[/i]
You have established some agreed common set of rules and a format / language anyone easily understand
You have a save and governed store location where the rest of your company can directly benefit from. This we call nowadays "the cloud"...
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.
Common Sensei at Procesje.nl
It's not a mistake because:
By diagramming your own processes, you have no other choice but to analyze them and really understand how they work, which individuals are involved, etc.
Translating a process into a diagram can be very hard because you have to see the main picture and simplify the whole process. Sure, it's easier if someone else does it but if you are able to achieve a good diagram, you will understand which aspects of the process are vital and which ones don't. Later one, if you have to explain the process to someone (a new employee, client, etc.) you will recognize what is the core of the process and which aspects you should emphasize on.
If you need someone else to explain your business to you, something isn't quite right.
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 [url="http://www.flokzu.com/en/documents-and-processes/bpmn/"]BPMN[/url].
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.
[b]always[/b]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.
[b]always[/b]. But then again - I'm not perfect.
Managing Founder, profluo.com
No, it is not a mistake to model your own business processes. It never is, because:
[list]Even if your modeling “language” is only readable by you, you always can specify them better after knowing your processes.
The exercise of conceptualizing and[quote][b] trying to formalize them is good per se.[/b]
If you are going to automate it with a BPM Suite, the best thing that could happen is to involve the process owner in the modeling stage, so, he/she will modeling their own business processes,
[b]reducing times and misunderstoods[/b].
After having modeled, when the “use” of the automated processes begin, you can
[b]evangelize the rest of the organization about “why” it has modeled in that way[/b], convincing (not forcing) people to use them.
And, if suggestions /
[b]critics arrive, you are in a much better position to understand them as improvement opportunities[/b](not threats), if you have modeled them at the first time.
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
[u]understandable[/u]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
[b]process mining[/b]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.
[b]Who is "you"?[/b]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.
As I understand the question, you are asking is it necessary to document the business processes as they exist today, not ideally how they should be. This takes us into the realm of capturing current systems, to wit:
There are some very legitimate reasons for documenting existing systems:
1. The documentation process will make development personnel more knowledgeable about the enterprise's business. Users often complain that the systems people are ignorant or naive about the business, and usually there is some justification in this complaint. The process of capturing current systems will educate Systems Engineers in the business of the company.
2. Documenting current systems will clearly show:
- What information is being produced.
- Who is using the information and how.
- What data resources are being used (data, records, files, inputs, outputs).
- What processing is being executed, and what is not.
Quite often, user personnel do not use existing systems simply because they do not understand the purpose of the system or how it is to be used. If a system has been properly documented, perhaps only a few modifications are required as opposed to a major new development effort. Unless we understand clearly what the old system is doing, how can we design a new system to replace the old? How can we plan the conversion from the old to the new? Most of the current system contains resources that will be reusable for the new system. Data, records, files, inputs, outputs - most, if not all of these can be reused in systems development.
Weaknesses and misusages of current systems will also be uncovered. Because of inadequate documentation, it is not unusual to see a good system be misinterpreted by users, including operations personnel. As a consequence, the system is only partially utilized and the benefits not fully realized.
3. Programs and files which only serve the purpose of unnecessarily occupying computer storage space can be identified and removed.
Capturing current systems can be a huge undertaking. A single company can have hundreds of systems and sub-systems, and thousands of procedures and programs, some of which are very old. It is important to remember that the intent here is to ONLY IDENTIFY AND DESCRIBE THE CURRENT SYSTEM, NOT TO CORRECT DEFICIENCIES. Quite often, there is a temptation to try to correct an obvious problem at this stage. As a consequence, the task of capturing current systems takes longer and longer. When errors or problems are spotted they should be documented as future Modification/Improvements and not corrected as part of this effort.
How much definition is enough? Ultimately it is based on the organization's needs. No two companies will approach the problem in the same way. Their requirements will vary. However, simplicity is recommended when describing the various information resources.
Capturing current systems is an exercise in reverse engineering. Whereas, system design is a top-down effort, current systems analysis begins with an examination of the procedural flow and works up and down the system hierarchy.
What systems or sub-systems do you begin with? Start with those that provide operational information - those that are at the heart of the business operations. Those parts of the systems that provide policy and control information can be delayed until the operational systems have been captured, since they will require the same data created in the operational systems.
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."
[u]IS[/u]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.
[i][quote][b]“If you can't describe what you are doing as a process, you don't know what you're doing.”[/b][/i][/quote]
[i]. Edwards Deming[/i]
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...
[b]1. Set a vision - then see the gaps[/b]
What should the process be doing? What could it do? And why isn't it?
[b]2. See where it fits in the bigger picture[/b]
Where has it been optimised to the detriment of other processes? Where has it accepted other processes compromising its speed or deliverables?
[b]3. Understand the Constraints[/b]
Why are the compromises being made? And what can be done to remove them?
[b]4. Get some more opinions on how well it works[/b]
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.
[i][quote][b]“An organization's ability to learn, and translate that learning into action rapidly, is the ultimate competitive advantage.”[/b][/i][/quote]
+44 (0) 1491 874368
+44 (0) 7590 677232
+44 (0) 1491 874368
+44 (0) 7590 677232
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.
- Page :
There are no replies made for this post yet.
However, you are not allowed to reply to this post.
However, you are not allowed to reply to this post.