Tip:
Highlight text to annotate it
X
Welcome Process Management experts to our Best Practice in Process video post
I'm Thomas
I'm Mirko
and we are working in the Best Practice in Process Management project
and in this video post we would like to show you the results
of part one of our first workshop in January 2012
the topic was Process Modeling
and the participants of the workshop were from various business fields
like: aviation, defense, production industry and even one service company
yes, a small one was participating in the workshop as well
with the results of the workshops we were able to answer some questions
like: which detail levels to choose for modeling?
and how and what information to link to processes?
when and where to define in and outputs?
what’s the right displaying complexity?
and the last one: how to describe responsibilities within processes?
and along that questions we will present our results
Right, so let’s have a look into the first one.
Before we start I have to say, and as you can see in the slide, we called it Common practice or Promising practices
I’m not sure if we are really talking about Best practices, for sure they are good practices
so that is important to know that we don’t want to say that this is Best practices at the moment
because we only discussed it with six different organizations, but it’s common practice
common practice, we could see at various companies in the workshops
and promising practice were nice ideas but no common practice and common use of that
At the moment, yes
Concerning the levels to choose from modeling we could identify that nearly every company used process maps
at the highest level of process description
and also the lowest level of detail, where processes were divided into management, core and support processes
Yes, that was quite common that everybody used these three different types of processes on the process maps
The number of levels was not specified so when you click on a process map
it could be that you get to another process map and so on
at last you will get to the next level (process descriptions) there was no really common practice
it seem to be that every company models their processes...
...in a very customized way that fits to the company
and requirements
that is true
we saw EPC for modeling
not always, most of the time used Top-Down
And BPMN. Some used swimming lanes, some didn’t
That’s true. So, somehow it was comparable, but different
But everybody had this level of detail. That they have process description in the end, activities and so on
At the end the highest level of detail were documents that could be linked to processes or task processes.
And then there was one thing that you indicated as promising practice
Yes, that was a nice idea. One company had the possibility: the software could deliver to have a choice between two different types of visualization
and one was the full view where you saw the whole picture
all the arrows between the activities and there was a slim view that shows the process in a way of tabular form without roles
Just a quick overview
Ok, so that was the first one. Let’s have a look into the second topic
And I really love this topic. We call it Process dashboard
so the question was what to integrate into the processes
and we saw several nice implementations of how to present this information
and to create a process dashboard in overview management capable easy to understand all the information
on the point in one picture where we have the input and output of the process and the goals as well as key performance indicators
on one picture also risks were integrated in two of this examples and you could see the resources and tools that were necessary to perform the process
and finally the roles involved into the process just in one picture
you can put it on to a slide or just print it out in A4 so an overview process dashboard
And it’s based on the turtle methodology
Known from ISO standards for example
Certification audits
That was something that I personally really liked
So, the next question: When and where to define In and Output?
We could identify that common practice is first to identify In and Output when process changes
At the boarders when you switch from one to another process
And within the processes, Input and Output was described whenever responsibilities change
so tasks are performed by different roles
There was even one example where you were not able to link two processes
as long as the input doesn’t match the output of the other process.
There was a nice idea of one company where within the process maps the processes are linked with arrows
and they used it, I guess to identify bottlenecks and critical paths.
Yes, that is also interesting or promising practice that we could go into more detail later on
Ok, so that is about our findings concerning input and output.
Then complexity, something I also very like to talk about
That’s an example from Lufthansa Technik actualy, the picture you see there
We are just using three kinds of objects.
And that is obviously common practice; all the companies reduced their numbers of objects
But let’s continue with our example
On the left side, the yellow ones are the roles that perform the tasks that are in the swimming lane
and decisions are some sort of diamonds and activities are just grey boxes
And we have some red boxes; they indicate that was an update in this activity during the last revision of the process
We could also see that most companies reduced the numbers of operators they use or even don’t use operators
Like AND and OR
But we could see that the reason wasn’t really necessary to understand the processes between operators
So just reduced complexity
It’s easy to understand even without
So that was about the way to describe the processes and reduce complexity
What about responsibilities? What common practices did we have?
Everyone seems to use roles to describe responsibilities
It doesn’t matter if they are using EPCs or BPMN, everybody used roles and assign this roles to activities.
And the roles are linked to qualifications or duties
There was also one example where they linked the process management system to the ASP
to automatically sign IT rights, for example to the employees:
So a connection between the two systems, so that was somehow promising for us.
And finally the last insight.
Who is modeling the processes? Who puts them into the systems?
It was common practice, or seem to be that the modeling is done in teams
you have a process modeler who is skilled in the tool and in the methodologies
Specially trained for moderating process modeling sessions, for example
The process owner who is responsible for the process
and finally the process experts who perform the process every day and know it very well.
So that was a common practice, that not one person is doing the whole job alone
they are doing that in teams together, all the knowledge into the process modeling, or into the processes in the end
Yeah that’s it or?
Yes
So this were the key findings of the Process Modeling Workshop that we had
For sure there were much more insights during the discussion, which we hadn’t put into the slides
but for sure that we are discussing them in more detail later on.
And there are other topics that we will discuss and we already discussed:
the integration of legislative and normative requirements into the process,
so this will be the next video post.
But more topics are coming up: Process Management Roles, is one of the next workshop topics
And was it organization-wide standardized Process Model?
Yes, how detailed the processes are described within an organization.
So, if you would like to receive the updates of the other post
then subscribe to our blog, you can find the link address down there
And see you next time, have a nice day
Bye bye and thanks for watching our video