Purpose of this page...
During my years as Local Process Leader and Business Process Manager, I have participated in a lot of process development projects,
system projects and also driven some process development projects/initiatives. The purpose of this page is to share my knowledge
in process management and of course show my knowledge in this area, worth hiring.
Definitions: Process, Project Models and Projects
Since I have met a lot of people having different definitions of process, project models and project I want to share my view first.
You can find more information about projects and project models in my dedicated page for it here.
- A process is a set of value adding activities which is supposed to be executed in a certain order, i.e. what you do within the company.
- A process shall always be repetetive. If not repetetive, i.e. only done one time, it's an exception from the normal process.
- Processes can be described differently, depending on what kind of methodology you use. SIPOC, Swimlane and other. (See more about SIPOC further down.)
- Processes can be described in different levels. Top level you have the Main or Mega processes, which then are broken down to get more detailed levels and down to intructions at the bottom.
- A process is NOT EQUAL TO A FUNCTION OR DEPARTMENT!!! This is often misused, when people say for example that
Product Development Process is only Development Departments. In a good development project all departments are involved. How could you otherwise
purchase the parts you need, get input from production how things need to be designed for them to be more efficient in production and Aftermarket
to give input regarding reducing parts and servicability, reparability etc?
- Project Model (read more here)
- Project model is a structure tool used in Projects.
- Project models are normally gate models with a number of Phases and Gates in between where Gate Deliverables should be accepted before opening the gate.
- Phases have a number of activities that should be performed within the phase with a certain goal or target of fulfillment.
Though activities can spread over more than one Phase, but shall be able to report fulfillment status at gate audit and/or Steering Committee Meeting (SC meetings).
- Gates should contain Gate Deliverables with measurements that can be audited by Gate Auditors before SC meetings.
- The project model is used for high level planning and in most cases above the level Project Managers use for actual planning.
Normally the Project Manager (Chief Project Manager) and if a big project Project Managers for systems have their own planning on a lower level than the Project Model provide.
- Project (read more here)
- A project is specific initiative to solve a problem or create something new.
- A project shall always have a BUDGET. Without budget and funding, there is no project!
- A project shall have dedicated resources for a certain time length within the project. This is different in different companies.
Some have project resources that are only working in Projects and don't belong to any Function, in the traditional hierarchical
functional way. Others have their resources belonging to functions but the resources must commit to the project, either by commit to
the deliverable (deliverable oriented) or the agreed estimated time that is required for executing the tasks/activity (time oriented).
^ top ^
Project Models / Initiative structure in Process Improvement work
When it comes to Process Improvement work it is quite common to think that process work can be done quite fast and that you don't
need any "Project Model" for the initiative or project.
From my experience, I have to say that every time I have been involved in a project where the Project Leader/Manager has not been
willing to use any existing project model or just create any good structure for planning and documentation structure, the
project/initiative has not been run well. This because even if it seems to be a job that can be done quick and with good results,
it often ends up in "quick and dirty" with poor quality.
Reasons for this are that poor planning and documentation of actions/tasks causes confusion of who is doing what and by when and
thereby more time is spent on discussing things that should have been clear if it was documented.
- A good structure, either using a well known project model within your company (so everybody are familiar with what to do when)
or creating a good structure that the team agree upon. That is crucial.
- Everybody should know what to do and by when.
- Everybody should know where to store documentation of different types or if you use
a non-folder structure, tag documents with correct labels to be able to find in correct structure.
^ top ^
Process Management Methodology
From my experience, there are a number of different methodolgies when it comes to Process Management, i.e. how you describe your processes.
There are SIPOC, Swimlanes, Fish diagrams...
I prefer the SIPOC methodology, i.e. Supplier, Input, Process, Output, Customer.
This means that you have to specify Supplier, Input, Output and Customer for every process activity. By defining that you automatically
define the scope of the process activity much sharper. You also mitigate the risk of not clear process activities or even forgetting any
process activity in between other. At the same time you also get it more visual of who is doing what since you describe the roles executing
the process activity by defining supplier and customer as the process A is the supplier of an output from process A which is input or partial
input to process B and thereby the role executing process B the Customer of process A.
- It doesn't matter which level you map. You can describe Output/Input between any process at any level.
- Remember that an output can be "bigger" than the customer want. The best is to describe it both ways, meaning both
from Process A creating the output and from each customer using the output as input. Is it a match?
- Example 1: If a department for example create an article in a system with all kinds of meta data, not all departments
downstream may need all meta data but they use different parts of it.
- Example 2: A report is created and stored for different users to go and get their part of the document they need for
There are a number of standards in process modelling. However, I have only seen a list of them but don't really know so far what they
consist of, if they really cover how processes should be described or if they only are focused on process automation from an IT point
of view. Will dig into that later.
^ top ^
Process Levels (SIPOC)
As I have more or less only worked with SIPOC methodology, I will describe how to handle levels with SIPOC methodology.
SIPOC is defined as the process flow going from left to right and the levels from top to bottom.
The top level is often called the Main Process Map which consist of a company's Main or Mega Processes. Typically for a producing company
with own development, the Main/Mega processes can be described as:
- Product Portfolio & Development process
- Sales process
- Production & Logistics process
- Customer Care for Repurchase process
For a service company it could be similar, where product portfolio is in form of services instead of hard products & services, the sales
process finding customers and negotiate assignment terms and then the Production is the execution of assignment. Customer Care can of course
be some "team building activities" with assignment owners, within fraud regulations of course.
It is often quite easy to define the Main process map, since you normally have clear break points between different processes.
Once you have the main process map each of the main/mega process shall be broken down into how you manage each process. These first break
down level maps are normally called Level 1 (and the main process map level 0), but can also be level 2 in some companies.
My experience is that these first level of break downs take a lot of time to define. However, a good enough feeling is always a good measure
in process mapping, because you always find something to change later when you do a breakdown of each process activities to the next level (level 2).
How small steps should you take for every breakdown? This is actually a hard questions, but the simple answer is that you have to trust your
gut feeling, which you develop when you have done it for a couple of years. It is recommended that you don't have too many levels. At least
too many levels of process maps. The best thing for a medium to large company is to try have maximum 4 levels of process maps.
And what then after process maps? Once you have a good, easy to follow structure of process maps, it is time to describe the flows more in
detail. That is done in Process Flowcharts. Process Maps are horisontal layout (landscape) while Process Flowcharts are portrait format. The
main reason for that is that you draw the flow from top to bottom in a flowchart (in opposite to process maps that are left to right). Another
reason is that flowcharts can be quite long when you break down a level 3 or 4 process activities into process flowcharts.
I have heard several times that it is recommended to only have the last level of processes as flowcharts and then link to the instructions
that match with the specific process activity.
I must say that I have several times had use of two levels of flowcharts as the bottom two levels. As long as it clearly describe the process
and everybody understand the process, you have succeded with the mapping.
If your company still has binders of instructions (probably not many have that anymore), now the tricky part comes, when you have to go from
instruction documents which can span over a number of processes and you have to create smaller documents that matches the process activities
at least on the lowest level.
- Good Enough is best to not take too much time.
- Maximum 4 levels of process maps and then flowcharts to describe the actual flow where people can recognize what they actually
do at work.
- Then flowcharts to describe the bottom level(s).
- Create instruction documents that describe the specific process acitivity, at least on the lowest level.
- Process description documents can be used to clarify the process maps (and if necessary also for process flowcharts).
Depending on what kind of Business Management System your company uses, you might need to change things in how you structure the processes.
It can be a lot of different factors that affect your choice of structure, whether it is "image based" with for example MS Visio documents
you save as images or if it is more sophisticated with object oriented and in that case which solution you use.
^ top ^
BELOW NEEDS REVISION - IGNORE FOR NOW PLEASE.
Business Process Management - the overview
June 2009 I became Business Process Manager and together with a colleague we had the responsibility to visualize the status of
all processes. This had never been done before, so I developed an excelsheet with rows for every process and created a structure
for all the subprocesses. What was important to show...?
Process status is needed for several reasons and different by stakeholders.
Using project models with phases, gates and having steering committee meetings are very important to have, to put pressure
on the project to deliver something in time. But even more important, the other direction, being able to describe for SC or
management why you need the specific time and resources for the project. To have a good structure, you need different levels.
I prefer the SIPOC methodology, i.e. Supplier, Input, Process, Output, Customer.
- High level - Project level, to be able to describe the project for management or any other that need the overview. This shall
include high level of figures and which project model you use and which phases you have and what, on a high level, should be finished
within which time limit.
- Medium level - This is where you write the "high level" tasks that need to be done within each phase, for planning, and
what the expected results should be for the gate passage. Even better if you have a check list of what steering committee members
need to review before the gate passage meeting (how long before) and what shall be reviewed at the meeting.
- Low level - As you have the medium level planning, you can break it down into more actionable tasks in the low/detailed
- Good overview of the project - for Project Manager/Leader, Project Team and of course when presenting high level to SC
(Steering Committee) or Management.
- If you take down actions according to the SMART method (see list below), the project will run smoother.
Also having a not too high level of task list.
Everyone should be able to understand what the task is about, what should be done ()
- Specific - What is the task, how are somebody (one responsible, even if require more than one) going to do it and why at this
point (timing). Must be clear and understandable for everyone. Even if you are away on vacation and come back after a few weeks, you should
be able to understand the action.
- Measurable - This is about setting goals. It depends on what level you are writing these actions, if it is a high level
that need to be broken down, then you probably should be able to measure the difference in any KPI or PI (Key Performance Indicator
or Performance Indicator). If it is on a medium or low level you should either investigate if you will affect KPI/PI or if you only
need to have some sort of fulfillment based measurement. NOTE! - Measurement doesn't always have to be generated in excel with figures.
It can be good enough with red, yellow and green or even happy and sad faces. Important for project members to be able to follow progress
and what has been done without asking around (in case somebody is sick or something). This also supports time efficiency.
- Appropriate/Attainable - The action must be something that can be done within the time limit and cost allowed. If you
set a goal which is too far away, you will not have commitment and then fail anyway.
- Realistic - depending on what shall be done and how many/much resources you have for it, is it realistic?
- Time based - When should the action be completed. Dependencies are very important to understand, if something has to be
executed before this action, or if other actions rely on this action result.
Structure and Planning
I have learned that, no matter how big or small an initiative or project is, it is very important to plan very good and get it down
in writing. Even if you think it is quite fast initiative and only a few included in the job, planning is crucial.
Why? Because there are always a lot of things that need to be taken care of and then followed up in reporting meetings.
By writing actions, who is doing what and by when, it is easy to go through the list and you also can I have worked with Business Processes between late 2002 and August 2010, where the mapping was quite new to Volvo (at least
within Volvo Construction Equipment) when we started started late 2002. I became Process Leader for main/mega process PPD (Product
Portfolio Development) at Customer Support since I worked as a Parts Planner/Engineer and we had a good view of many of the other
departments and of course my interest and putting my hand up.
Since then I got involved in Volvo CE business process mapping as Customer Support representative and we developed the first
process maps at Level 2. This because we got the Level 0, with Main/Mega processes, and the first version of the Level 1 PPD
process (breakdown of PPD Main/Mega process) from HQ.
My process journey then went from the Volvo CE maps to align Customer Supports processes into the Global high level processes as
much as possible and modify the rest we couldn't align 100% to.
A lot of work was also regarding setting up project model and have it aligned with the processes and the other way around. When
that was setup, I have then been involved in numerous Volvo CE process and system improvement projects.
The two biggest was one huge PDM Project where we defined Design Procedures which was going to align all different product lines
to one process and using same PDM system. This was a really good experience in a number of reasons for my part. Of course working
with the IS/IT project model and getting familiar with it and also better knowledge in PDM and CAD. The other big project was
still running when I started my study leave (August 17 2010). That was a very interesting project regarding project management
tools and connection with financial data. Cannot say anything more than that but very interesting and fun to work with.
^ top ^