Process map

From HandWiki
Short description: Business modeling concept

Process map is a global-system process model that is used to outline the processes that make up the business system and how they interact with each other. Process map shows the processes as objects, which means it is a static and non-algorithmic view of the processes. It should be differentiated from a detailed process model, which shows a dynamic and algorithmic view of the processes, usually known as a process flow diagram.[1] There are different notation standards that can be used for modelling process maps, but the most notable ones are TOGAF Event Diagram, Eriksson-Penker notation, and ARIS Value Added Chain.[2]

Global process models

Global characteristics of the business system are captured by global or system models. Global process models are presented using different methodologies and sometimes under different names. Most notably, they are named process map in Visual Paradigm[3] and MMABP,[2] value-added chain in ARIS,[4] and process diagram in Eriksson-Penker notation[5] – which can easily lead to the confusion with process flow (detailed process model).[1]

Global models are mainly object-oriented and present a static view of the business system; they do not describe dynamic aspects of processes. A process map shows the presence of processes and their mutual relationships. The requirement for the global perspective of the system as a supplementary to the internal process logic description results from the necessity of taking into consideration not only the internal process logic but also its significant surroundings. The algorithmic process model cannot take the place of this perspective since it represents the system model of the process. The detailed process model and the global process model represent different perspectives on the same business system, so these models must be mutually consistent.[2]

A macro process map represents the major processes required to deliver a product or service to the customer. These macro process maps can be further detailed in sub-diagrams. It is often the case that process maps cross different functional areas of the organization.[6]

Process maps are used by many companies to have a holistic view of all processes and the connections between them. Maps help in navigating the sub-processes and make understanding of the organization's operations easier. The process map shows relationships and dependencies between processes and its focus should be on core business processes of the organization.[7]

A process map can be seen as the most abstract level of the process architecture, and it acts as the introduction to the more detailed levels. A process map that is correctly designed is able to provide a general understanding of a company's operations. Designing the process map is an important and strategic step for the organization, and it is followed by further business process modelling implementation.[8]

Context

Methodology for Modelling and Analysis of Business Process (MMABP) is a business process modelling methodology developed at the Department of Information Technology, Faculty of Informatics and Statistics of the Prague University of Economics and Business. The methodology is defined as a “general methodology for modelling business systems using informatics methods and approaches”.[2]

Methodology is used to analyse business processes and to develop a comprehensive model of the system. The goal of developing a model is to be used for process optimization. The model should be created following the characteristics and specifics of the organization in question and following external influences that can affect the organization. The model should be optimal from an economic perspective, but it should also be optimal from a factual perspective, meaning that it should be as simple as possible while maintaining complete functionality.[1]

Business system modelling is based on a two-dimensional approach:[9]

  • Real World structure (substance) – set of objects and their relationships
  • Real World behaviour – set of mutually connected business processes

Additionally, there are also two views of the systems:[9]

  • Global view of the system
  • Detailed view of the system's parts

This results in the need to model the system from four different perspectives in order to achieve the complete and comprehensive view of the business system. MMABP also proposes which notation languages can be used for modelling each perspective, and it also suggests some improvements to the notation languages in order to fit the purpose.[1]

  • Global view of the objects – Conceptual model (Class diagram)
  • Detailed view of the objects – Object life cycle (State Chart)
  • Global view of the processes – Process map (Eriksson-Penker Diagram/TOGAF Event Diagram/ARIS VAC)
  • Detailed view of the processes – Model of the process flow (BPMN Diagram)
  • Data Flow Diagram (DFD) is additional diagram used for describing the required functionalities of the information system.

Notation standards

Eriksson-Penker Diagram

Eriksson-Penker diagram is a tool used in business model analysis and design. It is named after Hans-Erik Eriksson and Magnus Penker, who developed the concept in their book "Business modelling with UML: Business Patterns at Work”.[5]

Eriksson-Penker diagrams are used to map out the key components of a business model and how they interact with one another. The diagrams typically consist of a series of boxes and lines that represent the different elements of the business model, such as the value proposition, customer segments, channels, revenue streams, and key resources. The lines between the boxes represent the relationships and dependencies between the different elements of the business model. These diagrams are useful for visualizing and understanding the various components of a business model, and can help organizations identify potential areas for improvement or areas of risk. They can also be used as a communication tool to help stakeholders understand the business model and its underlying assumptions.[5]

These diagrams are useful for visualizing and understanding the various components of a business model, and can help organizations identify potential areas for improvement or areas of risk. They can also be used as a communication tool to help stakeholders understand the business model and its underlying assumptions. It is possible to use Eriksson-Penker diagrams to create a global process view of a business. In this case, a diagram would be used to map out the key processes and activities that are involved in the business, as well as the relationships and dependencies between these processes.[5] For example, an Eriksson-Penker diagram could be used to depict the various steps involved in the product development process, from concept development to market launch. It could also be used to show how different functions within the organization, such as marketing, sales, and production, interact and depend on one another to support the overall business.

Eriksson-Penker diagram is one of the most popular de facto standards that can be used for an object-oriented global view of business processes.[1] It is developed as an extension of the UML,[10] and it is often used together with the BPMN to compensate for the lack of possibility to model the global view with this widely accepted standard.[1]

TOGAF Event Diagram

TOGAF (The Open Group Architecture Framework) is a framework for enterprise architecture that provides a common language and set of standards for designing, planning, implementing, and governing an enterprise's IT architecture. TOGAF event diagrams are diagrams used in the TOGAF framework to represent the flow of events within a system or process.[11]

The TOGAF Event Diagram is a visual representation of the events within an organization or system. It can be used to show the sequence of events that occur in a particular process, as well as the relationships between the events and the stakeholders involved. TOGAF Event Diagrams can be useful in creating a global process view because they provide a visual representation of the events, which can be helpful in understanding how the process fits into the larger context of the organization.[11]

TOGAF Event Diagram is the most perspective standard for the system view of processes today. It is used to represent the system of processes as well as their connections to the functional organizational structure.[1]

ARIS Value Added Chain

ARIS (Architecture of Integrated Information Systems) is a methodology and a set of tools for designing and managing business processes. It is based on the idea that business processes are the core of an organization and that they can be modelled and optimized to improve efficiency and effectiveness. The ARIS methodology provides a framework for understanding and analysing business processes, as well as for designing and implementing improvements to those processes. It includes a set of graphical modelling languages and tools for creating process models, as well as a database for storing and managing process information.[4]

In the context of the ARIS methodology, a value added chain (VAC) diagram is a specific type of process model that is created using the ARIS modelling languages and tools.[4] The ARIS methodology recognizes the distinction between a global view of the system of processes and a detailed view of one process. VAC notation can be used in ARIS for modelling the global view.[1]

Model consistency

Business process models should be consistent, both within a single model and in terms of mutual consistency with other models. Consistency applies to both global (Process Map) and detailed (Process Diagram) views. In order to be considered consistent, models should satisfy two consistency criteria: completeness and correctness.[1]

In terms of a single model, business process models should be:[9]

  • Complete – A process must be defined for every product, and all relevant events must be used as action reasoning in at least one model.
  • Correct – Process aim must be met by the process. Process actions and their sequence, inputs, outputs, and all other process properties must be valid for all potential process instances.

In terms of mutual consistency with other models, business process models should be:[9]

  • Consistency between the class diagram and business process model relates to the correctness and completeness of object roles. All object classes have to be mentioned in business processes as some external factor, and the other way around too.
  • Consistency between the state chart and business process model relates to the correctness and completeness of actions. Every action from business process must have at least one equivalent state transition in state chart, and the other way around too.
  • Consistency between all diagrams (class diagram, state chart, and business process models) relates to the correctness and completeness of reasons. Every event that represents a reason for transitioning between states in the state chart should have an equivalent event that represents a reason for the process activity in the business process model, and the other way around too.

References

  1. ↑ 1.0 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 Řepa, Václav (2012). Information modeling of organizations (109 S ed.). Živonin: Tomas Bruckner. ISBN 978-80-904661-3-5. OCLC 951365196. https://www.worldcat.org/oclc/951365196. 
  2. ↑ 2.0 2.1 2.2 2.3 Řepa, Václav; Bruckner, Tomas (2015). "Methodology for Modeling and Analysis of Business Processes (MMABP)". Journal of Systems Integration 6: 17–28. doi:10.20470/jsi.v6i4.243. 
  3. ↑ "Ideal Modeling & Diagramming Tool for Agile Team Collaboration". https://www.visual-paradigm.com/. 
  4. ↑ 4.0 4.1 4.2 Scheer, August-Wilhelm (1992). Architecture of Integrated Information Systems : Foundations of Enterprise Modelling. Berlin, Heidelberg: Springer Berlin Heidelberg. ISBN 978-3-642-97389-5. OCLC 851369314. https://www.worldcat.org/oclc/851369314. 
  5. ↑ 5.0 5.1 5.2 5.3 Eriksson, Hans-Erik (2000). Business modeling with UML : business patterns at work. Magnus Penker. New York: John Wiley & Sons. ISBN 0-471-29551-5. OCLC 42892243. https://www.worldcat.org/oclc/42892243. 
  6. ↑ Sanders, Doug; Ross, Bill; Coleman, Jim (July 1999). "THE PROCESS MAP". Quality Engineering 11 (4): 555–561. doi:10.1080/08982119908919275. ISSN 0898-2112. http://dx.doi.org/10.1080/08982119908919275. 
  7. ↑ Malinova, Monika; Mendling, Jan (2013). "The Effect Of Process Map Design Quality On Process Management Success". European Conference on Information Systems. 
  8. ↑ Malinova, Monika; Leopold, Henrik; Mendling, Jan (2015). Nurcan, Selmin; Pimenidis, Elias. eds. "An Explorative Study for Process Map Design" (in en). Information Systems Engineering in Complex Environments. Lecture Notes in Business Information Processing (Cham: Springer International Publishing) 204: 36–51. doi:10.1007/978-3-319-19270-3_3. ISBN 978-3-319-19270-3. 
  9. ↑ 9.0 9.1 9.2 9.3 Řepa, Václav; Svatoš, Oleg (2019). "Model Consistency as a Tool for Digital Business Architecture Verification" (in en). Procedia Computer Science 159: 2144–2153. doi:10.1016/j.procs.2019.09.388. 
  10. ↑ "About the Unified Modeling Language Specification Version 2.5.1". https://www.omg.org/spec/UML/2.5.1/About-UML/. 
  11. ↑ 11.0 11.1 The TOGAF Standard, version 9.2. Open Group. Zaltbommel. 2018. ISBN 978-94-018-0283-3. OCLC 1041856595. https://www.worldcat.org/oclc/1041856595. 



Retrieved from "https://handwiki.org/wiki/index.php?title=Process_map&oldid=3378488"