Difference between revisions of "Process mapping"
(25 intermediate revisions by 4 users not shown) | |||
Line 1: | Line 1: | ||
+ | <!-- | ||
{{Tellervo}} | {{Tellervo}} | ||
− | {{ | + | {{Tidy3}}, |
{{Consolidation stage}}, | {{Consolidation stage}}, | ||
− | + | --> | |
==Definition== | ==Definition== | ||
− | + | {{ {{PAGENAME}} }} | |
+ | |||
+ | ==Purpose and benefit== | ||
+ | |||
+ | The purpose of process mapping is to acquire, organize and visually present process knowledge acquired from experts or teams. | ||
+ | The main benefit of process mapping is that it facilitates the capture of process knowledge from experts in a visual way allowing ready transfer to others. Process maps created in this way are ideal for uploading into the Business Management System (BMS) for future retention and use throughout the organization. | ||
+ | Process mapping helps organizations in becoming more efficient [1] and it can be used as a tool for [[Continuous improvement|continuous improvement]] [3]: | ||
+ | |||
+ | * Documented processes should be a part of [[Management system|management system]] [2] | ||
+ | * A clear [[Process map|process map]] helps an organisation to understand its own work better | ||
+ | * Documented processes enable auditing processes e.g. by the regulatory body | ||
+ | * Process mapping helps to measure and compare the objective of a process alongside the entire organization's objectives to make sure that all processes are aligned [1]. | ||
+ | |||
+ | |||
+ | |||
+ | ==Description== | ||
+ | |||
+ | Documenting the main processes of an organisation is one of the requirements for a management system. Process mapping can be used as a tool to document these processes and the knowledge embedded in them in the form of a process map. | ||
+ | The description in this section applies to the process mapping process to be used to capture and map knowledge from technical experts. | ||
+ | # Pre-requisites | ||
+ | ## Confirm the expert has process knowledge (critical knowledge) of interest. A knowledge-loss risk assessment should have been carried out for the department or team under review. | ||
+ | ## Carry out a preliminary interview to determine the knowledge domains the expert is competent in. Use this to also explain the knowledge capture process that will be followed. | ||
+ | ## Carry out semi-structured interviews (see wiki for elicitation interviews) | ||
+ | ## Obtain a simple tool to model process knowledge. Microsoft Visio or PowerPoint are ideal for this purpose. | ||
+ | ## Produce a process modelling template using the tool showing task stages, inputs, outputs, etc. for each step in the process. | ||
+ | # The process mapping process | ||
+ | ## Use the interview transcript to identify processes for modelling. For example if the expert is knowledgeable in the process of “testing widget X”, highlight this for future action. Start modelling the process using the tool and template identified in 'Pre-requisites' above using the expert’s description. | ||
+ | ## Begin by providing a simple flow of activity from start to completion. Add inputs/outputs and those responsible for each process step if this information is specified in the transcript. | ||
+ | ## Continue modelling in this way until no further useful information is available from the transcript. Your process model should include the following components [1;2]: | ||
+ | ##* defining what an organization does, | ||
+ | ##* who is responsible, | ||
+ | ##* inputs and outputs, | ||
+ | ##* requirements for the process, | ||
+ | ##* the sequence and interactions of the processes, | ||
+ | ##* process measurements and | ||
+ | ##* a definition of a successful completion of the process. | ||
+ | ## Invite the expert to review the process map and update. By working directly with the expert it should be possible to add more detail to the model. For example who is responsible for each step, what are the inputs/outputs associated with each step, other guidance needed to understand the process. | ||
+ | ## Wherever possible, validate the knowledge captured with other experts or peers. | ||
+ | # Follow-up | ||
+ | ## Consider adding the process map produced in this way to the organization’s BMS. If the process is too specific for this, retain the process map with the expert’s concept knowledge. (see concept mapping). | ||
+ | ## Link the process map to other artefacts produced by the expert to allow easy access to this information. | ||
+ | ## Retain any recordings and transcripts for knowledge preservation. Usually a portal, wiki or equivalent is used for long term storage and search/retrieve activities. | ||
+ | |||
+ | ==Variations== | ||
+ | |||
+ | Simple “flow-charts” can be used to help capture this information but are less useful that process maps. | ||
+ | [[Process map|Process maps]] can be constructed directly with experts to help model process knowledge. As with [[Concept mapping|concept mapping]], the input for process models can be generated via interviews with experts. Alternatively group techniques can be used to help provide the basis for the process model. | ||
+ | |||
+ | Although the process works best with an available interview transcript, it is also possible to work with an expert directly to the derive process models without the need for an interview. | ||
+ | |||
+ | ==Implementation guidance== | ||
+ | |||
+ | # There are no specific rules on how process maps should be constructed. However, it is worthwhile noting: | ||
+ | #* It is important that process maps follow a standard symbol convention. | ||
+ | #* Avoid the use of yes/no gates wherever possible. This complicates the process and makes it difficult to communicate. | ||
+ | #* Don’t try to model complex Iterative loops in the process. | ||
+ | #* Consider breaking up complex processes into a number of separate and simpler modules | ||
+ | # It is always useful to record sessions with experts to help built the models. Recording also means that experts will take the sessions seriously and provide their best attention. | ||
+ | # Good facilitation is essential to ensure time with the expert is not wasted. | ||
− | == | + | ==Success factors== |
− | + | ||
− | + | * The production of a good process template prior to the modelling process. | |
− | + | * Having an interview transcript to work from is highly desirable. | |
− | + | * Modelled knowledge should be validated by other experts and peers if possible. | |
+ | * Ensure that the process maps are available (read-only) for others to view. A portal or intranet is usually needed for this. Some organizations will use specialist software packages to help create their BMS. | ||
− | + | ==Common pitfalls== | |
− | + | * Modelling readily known and understood process knowledge. | |
− | + | * Confusing “process maps” with “flowcharts”. A process map shows input/output information at each stage of a process - much more than a flowchart. | |
− | * | + | * Using too many gates in the model. If there are many iterative paths the process knowledge is difficult to understand and readily communicate. |
− | + | * Using different styles of process map. Agree a common template. | |
− | + | * Not sharing or transferring the knowledge. If an expert’s knowledge is modelled and never used then the whole process has little value. | |
− | * | + | |
− | * the | + | |
− | + | ||
− | * | + | |
− | |||
− | |||
− | |||
== References == | == References == | ||
Line 40: | Line 92: | ||
==Related articles== | ==Related articles== | ||
− | |||
[[Process map]] | [[Process map]] | ||
Line 48: | Line 99: | ||
[[Concept mapping]] | [[Concept mapping]] | ||
− | [[Category: | + | [[Category:Knowledge mapping]] |
− | + |
Latest revision as of 14:55, 15 February 2016
Contents
Definition
The process of organizing and representing knowledge using process maps.
Purpose and benefit
The purpose of process mapping is to acquire, organize and visually present process knowledge acquired from experts or teams. The main benefit of process mapping is that it facilitates the capture of process knowledge from experts in a visual way allowing ready transfer to others. Process maps created in this way are ideal for uploading into the Business Management System (BMS) for future retention and use throughout the organization. Process mapping helps organizations in becoming more efficient [1] and it can be used as a tool for continuous improvement [3]:
- Documented processes should be a part of management system [2]
- A clear process map helps an organisation to understand its own work better
- Documented processes enable auditing processes e.g. by the regulatory body
- Process mapping helps to measure and compare the objective of a process alongside the entire organization's objectives to make sure that all processes are aligned [1].
Description
Documenting the main processes of an organisation is one of the requirements for a management system. Process mapping can be used as a tool to document these processes and the knowledge embedded in them in the form of a process map. The description in this section applies to the process mapping process to be used to capture and map knowledge from technical experts.
- Pre-requisites
- Confirm the expert has process knowledge (critical knowledge) of interest. A knowledge-loss risk assessment should have been carried out for the department or team under review.
- Carry out a preliminary interview to determine the knowledge domains the expert is competent in. Use this to also explain the knowledge capture process that will be followed.
- Carry out semi-structured interviews (see wiki for elicitation interviews)
- Obtain a simple tool to model process knowledge. Microsoft Visio or PowerPoint are ideal for this purpose.
- Produce a process modelling template using the tool showing task stages, inputs, outputs, etc. for each step in the process.
- The process mapping process
- Use the interview transcript to identify processes for modelling. For example if the expert is knowledgeable in the process of “testing widget X”, highlight this for future action. Start modelling the process using the tool and template identified in 'Pre-requisites' above using the expert’s description.
- Begin by providing a simple flow of activity from start to completion. Add inputs/outputs and those responsible for each process step if this information is specified in the transcript.
- Continue modelling in this way until no further useful information is available from the transcript. Your process model should include the following components [1;2]:
- defining what an organization does,
- who is responsible,
- inputs and outputs,
- requirements for the process,
- the sequence and interactions of the processes,
- process measurements and
- a definition of a successful completion of the process.
- Invite the expert to review the process map and update. By working directly with the expert it should be possible to add more detail to the model. For example who is responsible for each step, what are the inputs/outputs associated with each step, other guidance needed to understand the process.
- Wherever possible, validate the knowledge captured with other experts or peers.
- Follow-up
- Consider adding the process map produced in this way to the organization’s BMS. If the process is too specific for this, retain the process map with the expert’s concept knowledge. (see concept mapping).
- Link the process map to other artefacts produced by the expert to allow easy access to this information.
- Retain any recordings and transcripts for knowledge preservation. Usually a portal, wiki or equivalent is used for long term storage and search/retrieve activities.
Variations
Simple “flow-charts” can be used to help capture this information but are less useful that process maps. Process maps can be constructed directly with experts to help model process knowledge. As with concept mapping, the input for process models can be generated via interviews with experts. Alternatively group techniques can be used to help provide the basis for the process model.
Although the process works best with an available interview transcript, it is also possible to work with an expert directly to the derive process models without the need for an interview.
Implementation guidance
- There are no specific rules on how process maps should be constructed. However, it is worthwhile noting:
- It is important that process maps follow a standard symbol convention.
- Avoid the use of yes/no gates wherever possible. This complicates the process and makes it difficult to communicate.
- Don’t try to model complex Iterative loops in the process.
- Consider breaking up complex processes into a number of separate and simpler modules
- It is always useful to record sessions with experts to help built the models. Recording also means that experts will take the sessions seriously and provide their best attention.
- Good facilitation is essential to ensure time with the expert is not wasted.
Success factors
- The production of a good process template prior to the modelling process.
- Having an interview transcript to work from is highly desirable.
- Modelled knowledge should be validated by other experts and peers if possible.
- Ensure that the process maps are available (read-only) for others to view. A portal or intranet is usually needed for this. Some organizations will use specialist software packages to help create their BMS.
Common pitfalls
- Modelling readily known and understood process knowledge.
- Confusing “process maps” with “flowcharts”. A process map shows input/output information at each stage of a process - much more than a flowchart.
- Using too many gates in the model. If there are many iterative paths the process knowledge is difficult to understand and readily communicate.
- Using different styles of process map. Agree a common template.
- Not sharing or transferring the knowledge. If an expert’s knowledge is modelled and never used then the whole process has little value.
References
[1] Wikipedia http://en.wikipedia.org/wiki/Business_process_mapping
[2] IAEA, Safety Requirements, GS-R-3, http://www-pub.iaea.org/MTCD/publications/PDF/Pub1252_web.pdf
[3] IAEA, Management of continual improvement for facilities and activities: A structured approach, http://www-pub.iaea.org/MTCD/publications/PDF/te_1491_web.pdf