What is the process of process manufacturing

Navigation and service

Process models are simplified illustrations of processes in an organization. They represent the chronological and logical sequence of functions or activities. Depending on the objective, process models can be modeled in different degrees of detail and scope. Due to the complexity, not all processes to be considered can usually be represented in one process model. Therefore, different process models are mapped across different hierarchy or description levels. It starts with an overview at the level of the main tasks, which is then gradually refined by detailed models at the sub-task level. The number of description levels depends on the required level of detail. A different process model type can be used at each description level, depending on the objective. With the help of process models, existing processes can be clearly and clearly documented. They can be used for various purposes during an organizational project, but also during everyday work in an organization:

  • Process models as a standardized form of documentation for processes are a prerequisite for certification according to DINENISO 9001: 2008.
  • Process models can also serve to convey an understanding of activities, functions, roles and interfaces and thus contribute to increasing the transparency of processes inside and outside the organization. This increases procedural security, which in turn contributes to minimizing risk and preventing corruption.
  • The modeling of processes creates a basis for further actions such as weak point analyzes or optimization of organizational processes including risk minimization.
  • With the help of special software, process models are the basis for simulations of changes.
  • Process models serve as the basis for the development of applications, the introduction of workflow management systems or electronic process management systems.

They can be used for training users of new systems. In order to ensure the general comprehensibility and uniformity of the process models, a standardized description language in the form of symbols (notation) must be used for modeling. The following symbols are commonly used:

Process modeling icons

The symbols may vary depending on the software used. Depending on the modeling objective and the level of detail derived from it, one of the models described below should be used.

6.2.4.1 Process maps

In a process map, also called a process architecture model, all processes of an organization including their interfaces to the outside world are shown, delimited and the dependencies between the processes are shown at a high level of abstraction in an overall overview. The process map is thus a higher-level view (meta level) of the organization's processes. The process map is used when an overview of the process organization is to be drawn up and documented. On the basis of this process-related overview, the examination area of ​​an organizational examination can be better delimited, interfaces can be determined and connections and interactions between individual processes can be analyzed.
The creation of a process map requires an overview of all processes in the organization without analyzing them in detail. Required information can be obtained by means of document analysis (QM documentation, product catalog, business distribution plan, ...) or through interviews. When modeling a process map, either the notation shown above is used, or the process map is shown with the help of block arrows. Both display alternatives are common in practice:

Process map

When creating process maps, a few rules must be observed:

  • The passing information objects (paper application, data record, ...) must be displayed at the interface.
  • External process interfaces (suppliers, customers) must also be recorded.

up

6.2.4.2 Flow charts

The flow chart, also called a flow chart, depicts a single process. The focus is on the roles / organizational units involved. The flowchart is therefore used to provide an overview of individual processes comprising several organizational units. On the basis of the rather rough flowcharts, an organization-wide understanding of the course and participants in a process can be gained. The flowchart also serves as a basis for identifying and further analyzing sub-processes.

Application processing flowchart - example

When creating a flowchart, the symbols given above should be used and the following rules should be followed:

  • The organizational units involved are to be shown in appropriate columns (so-called swim lanes or swimlanes).
  • There must be an information object at the start of the process (input) and also at the end (output, result).
  • Each function / activity is followed by an information object that represents the result of the function.
  • A function can be replaced by a sub-process.
  • The connection of complex processes, which extend over several pages, takes place via jump labels.

up


6.2.4.3 Value chain diagrams (WKD)

A value chain diagram (WKD) is a model for representing business processes. It is mainly used - like the process map - at a high level of abstraction and basically serves to structure the essential functions, tasks and processes of an organization. It represents the entry level for business process modeling. On the top level, the processes are represented as the main processes. The main processes are divided into management, core and support processes.

up

6.2.4.4 Extended event-driven process chains (eEPK)

Extended event-driven process chains are a semi-formal modeling language[1]. It describes work processes as a sequence of functions and events. A relevant state that has occurred is referred to as an event. The extension is done by adding organizational units, information objects and other additional information.

Extended event-driven process chains are used when different views (data, organization, function and control view) of processes are to be shown in detail. They are well suited as a basis for creating software or introducing standard software. If eEPK are generated with the help of appropriate software, eEPK are well suited for simulation and thus for testing target concepts.

Extended event-driven process chain - example

When modeling extended event-driven process chains, the following modeling rules and conventions must be observed:

  • The representation of the process is divided into the three areas organizational units, events and functions, information objects (see example).
  • The process always begins and ends with an event.
  • Events and functions are in a strictly alternating sequence, that is, an event is always followed by a function and the function is in turn followed by an event.
  • Events and functions always have only one incoming and one outgoing edge (flow line).
  • A sub-process can also be used instead of a function.
  • Organizational units are always linked to functions, not to events.
  • If a branch is an alternative selection (or, exclusive-or), it must follow a function that makes the selection.
  • An and branch can also be preceded by an event. Since all branches have to be run through (parallel work), there can be no selection decision before an AND branch.
  • When merging branches, the same linking operator must be used as with the branch.
  • A function is designated by "noun + verb in the infinitive", for example "check completeness".
  • An event is designated by "noun + participle", for example "completeness checked".

up

6.2.4.4 Process tables

It is often not possible to map all relevant information about a process in a graphical process model. In addition to the model, the process can then be fully described with the help of a process table. A process table can contain the following information:

number Function / activityPerformer / roledescription Result annotation
1
2 Carrying mailMessengerSort mail on trolleys,
distribute incoming mail,
Collect outgoing mail
Incoming mail distributed,
Outgoing mail collected
three errands
per day
3

Example process table


Each line of a process table is led by a sequential number, which must correspond to the number of the function in the process model. The designations of the functions / activities must also be kept consistent with those in the process model.

Complete process documentation should contain the following information:

  • Purpose of the process, process owner, process boundaries, process owners and their responsibilities, customers of the process, description of the process, applicable regulations, specifications or procedural instructions, documentation information, information on change management, administrative information (file names, access authorization, change authorization).

up

footnote

[1] It was developed by Professor Dr. August Wilhelm Scheer at Saarland University.

up