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.

• Process
• 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.

NOTE!

• 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.

NOTE!

• 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 different purposes.

Comment!
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.

NOTE!

• 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).

Comment!
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 ^

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 planning.