Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Description: Process maps provide a shared high level understanding of end-to-end business processes in a business domain. The method focuses on what activities take place, rather than how, and helps identify all kinds of opportunities for improvement (not limited to technology changes).

Goals: Goals of this resource are:

  • Shared understanding of current and future state high level value streams of the end-to-end business processes in a domain

  • Defined and agreed upon scope for analysis of a problem space

  • Reaching a broader, domain level understanding of relationships between business processes, and opportunities for improvement at the domain level

  • The current-state process definition can potentially identify areas of waste and informs the design of the future state process

Often outcomes of a business process mapping exercise lead to business process redesign that will later support technology change/implementations.  BPM (Business Process Modeling) is a good method to get consensus on process and getting business owners to own business process change rather than demanding technology changes that likely will just support bad process.  BPMN (Business Process Model Notation), which is an extension, of UML, provides a standard set of symbols for describing the components of a process. 

Context: Some of the situations that can trigger the analysis are: 

  • A business unit may come to IT asking for a solution, and the method can be used to take a broader view of the domain and assess whether the proposed solution addresses the highest priority pain points

  • An architect may decide the analysis is needed in a business domain where major changes are expected

  • A Lean improvement project to remove waste from process area 

The process mapping exercise can require significant involvement by multiple subject matter experts, stakeholders, and management across the domain. 

The process mapping exercise provides a better understanding of a business domain to support: 

  • Planning of initiatives

  • Planning of services

  • Prioritization of projects

  • Process/service improvement efforts

  • Lean efforts

Source: The primary references on this page originated from Alec Sharp (Clariteq), but process analysis and process mapping in general are long-standing industry approaches. Process mapping developed out of understanding of the Toyota Production Systems (TPS) that seeks to continually remove waste from a system that results in a product or service. The basis of TPS refers to Deming’s view of the system view of the organization that produces a product or service.


  • A business unit may come to IT asking for a solution, and the method can be used to take a broader view of the domain and assess whether the proposed solution addresses the highest priority pain points

    • (expand on this as a scenario)

  • An architect may decide the analysis is needed in a business domain where major changes are expected

    • (expand on this as a scenario)

  • During strategic planning engagement with stakeholders, it may become evident that internal (e.g. self-service) or external (e.g. regulatory) factors imply changes to or improvement of an activity or process that must be understood before any meaningful dialog about a technology solution can take place.

  • A Lean project with process participants involved in current state mapping and future state design.



  • Business Analysis: requirements elicitation, discovery interviews, root cause analysis

  • Facilitation: Leading a group through the process modeling workshop

    • Should this be a capability in the EA Team?

  • Participants with subject matter expertise

  • Understanding of the different types of process waste


  • Work with business stakeholders to map out current state (as-is) of business process to have a shared understanding and vocabulary of major business process… we are talking about the what at this point.
  • After current state the team then looks at the pain points and attempts a root cause analysis of what is causing the pain points.  Initiatives are created in order to address the pain points.

Targeting systemic issues across the domain that are otherwise not visible.  While specific issues will also be discovered, focus needs to remain on the systemic.  Additional efforts can be launched to resolve the specific issues.

Potential pitfalls in applying the method include:

  • Many exception processes or steps will be raised that need to be tracked, but bracketed out of the main high level process

  • Finding ways to involve the “true” end customer perspective; finding good representatives for this can be difficult

  • Staying focused on the “what” instead of delving into the “how” of the process.


  • End-to-end business process - the full business process as it crosses multiple teams/organizations, not just as perceived within one organization

  • Business Owners - required to buy into value of process mapping and helping to define the scope of business process needs

  • Subject Matter Experts (SMEs) - business process owners or people that have specific knowledge of key capabilities and procedures within the business domain

  • Needs Assessment - Often business process mapping  can be a good method to use to help business owners understand their true business needs

Tools: Tools that create standard BPMN should be preferred.  This will promote consistency across teams and will help enable workflow automation.


Outcomes of the method provide a current state assessment of a business domain that can later be analyzed to:

  • achieve shared understanding among participants of exercise

  • collaboration amongst stakeholders to create and own the current state of business

  • produce technical gap/fit analysis

  • future state business re-design

Business process mapping is the first step in understanding a business domain with the expectations of gaining higher efficiencies post redesign and/or technological improvements.


Related Methods

The following methods could follow from this method:

  • More detailed/lower level: As-is and to-be workflow models (swimlane diagrams)

  • Same level, different perspective: Semantic Data Models

Before this method, other methods that it could be helpful to have completed are:



Architecture Methods > Process Maps



Want to help with this page? Please see the Method Contributor Guide.

Stewards for this page:

  • Dana Miller, Miami University

  • Piet Niederhausen, University of Washington

Other contributors:

  • Luke Tracy, University of Michigan

  • J.J. Du Chateau, University of Wisconsin-Madison

  • Jason Myers, University of Washington

  • Leo Fernig, University of British Columbia

  • Robert Dein, Miami University

  • Paul Schurr, University of Washington