Business process modeling: Difference between revisions

Revision as of 07:22, 4 September 2024

Revision as of 00:19, 8 September 2024

Line 60:

In detail, the objectives of business process modeling can include (compare: Association of Business Process Management Professionals (ABPMP)<ref name="EABPM"/> ^{(Chapter 3.1.2 Process characteristics and properties) ← automatic translation from German}):

* documentationDocumentation of the company's business processes

** to gain knowledge of the business processes

** to map business unit(s) with the applicable regulations

Line 74:

** to avoid loss of knowledge (e.g. due to staff leaving)

** to support quality and environmental management

* definitionDefinition of process performance indicators and monitoring of process performance

** to increase process speed

** to reduce cycle time

** to increase quality

** to reduce costs, such as labor, materials, scrap, or capital costs

* preparationPreparation/implementationImplementation of a ''business process optimization'' (which usually begins with an analysis of the current situation)

** to support the analysis of the current situation

** to develop alternative processes

Line 85:

** to outsource company tasks

** to redesign, streamline, or improve company processes (e.g. with the help of the [[Capability Maturity Model|CMM]])

* preparationPreparation of an [[information technology]] project

** to support a ''software evaluation'' / ''software selection''

** to support the customizing of [[commercial off-the-shelf]] software

** to introduce automation or IT support - with a [[workflow management]] system

* definitionDefinition of interfaces and [[Service-level agreement|SLAs]]

* [[Modularity|modularizationModularization]] of company processes

* [[benchmarkingBenchmarking]] between parts of the company, partners and competitors

* performPerforming [[activity-based costing]] and [[simulation|simulations]]

** to understand how the process reacts to different stress rituals or expected changes

** to evaluate the effectiveness of measures for ''business process optimization'' and compare alternatives

* findingFinding the [[best practice]]

* accompanyAccompaning organizational changes

** such as sale or partial sale

** such as the acquisition and integration of companies or parts of companies

** such as the introduction or change of IT systems or organizational structures

* participationParticipation in competitions (such as [[European Foundation for Quality Management|EFQM]]).

== Applications of business process modeling ==

Line 148:

In the definition of the standard requirements for the ''processes needed and their interactions'', ISO/IEC 9001 is more specific in clause 4.4.1 than any other ISO standard for management systems and defines that "the organization shall determine and apply the processes needed for"<ref name="ISO-9001"/> an appropriate management system throughout the organization and also lists detailed requirements with regard to processes:

* determineDetermine the inputs required and the outputs expected

* determineDetermine the sequence and interaction

* defineDefine and apply the criteria and methods (including monitoring, measurement, and related performance indicators) for effective operation and control

* determineDetermine the resources needed

* assignAssign the responsibilities and authorities

* addressAddress the risks and opportunities

* evaluateEvaluate these processes and implement any changes needed for effective operation and control

* improveImprove

In addition, clause 4.4.2 of the ISO/IEC 9001 lists some more

detailed requirements with regard to processes:

* maintainMaintain documented information

* retainRetain documented information for correct implementation

The implementation of the standard requirements for the ''processes needed and their interactions'' and, in particular, proof of the implementation of the standard requirements with adequate documentation (business process modelling) is common practice. This also means that the standard requirements for ''documented information'' are also relevant for business process modelling as part of an ISO management system.

Line 168:

The standard requirements of ISO/IEC 9001 used here as an example ''include'' in clause "7.5.1. General"

* documentedDocumented information by the standard requirements; and

* documentedDocumented information on the effectiveness of the management system must be included;

''demandDemand'' in clause "7.5.2. Creating and updating"

* labellingLabelling and description (e.g. with title, date, author or reference number);

* suitableSuitable format (e.g. language, software version, graphics) and medium (e.g. paper, electronic); and

* Review and approval

* Überprüfung und Genehmigung;

andAnd ''require'' in clause "7.5.3. Control of documented information"

* toTo ensure suitable and available at the place and time as required;

* toTo ensure protection (e.g. against loss of confidentiality, improper use or loss of integrity);

* toTo consider distribution, access, retrieval,and use;

* toTo consider filing/storage and preservation (including preservation of readability);

* toTo perform monitoring of changes (e.g. version control); and

* toTo consider storage and disposition of further whereabouts.

Based on the standard requirements,

#* toTo determine and continuously improve the ''required processes and their interactions''

#* toTo determine and maintain the content of the ''documented information'' deemed necessary and

#* toTo ensure the secure handling of ''documented information'' (protection, access, monitoring, and maintenance)

preparingPreparing for ISO certification of a management system is a very good opportunity to establish or promote business process modelling in the organisation.

=== Business process optimization ===

Line 234:

[[File:Process-map-for-a-market-driven-company.png|thumb|Example of a '''process map''' for a market-driven company]]

''Jörg Becker and Volker Meise'' provide the following list of activities for structuring business processes:

* "Enumeration of the main processes,

* Definition of the process boundaries,

* Determining the strategic relevance of each process,

* Analysis of the need for improvement of a process and

* Determining the political and cultural significance of the process"<ref name="BECKER-MEISE"/> ^{(Chapter 4.10 Defining the process structure) ← automatic translation from German}

The structuring of business processes generally begins with a distinction between management, core, and support processes.

Line 250:

As the ''core business processes'' clearly make up the majority of a company's identified business processes, it has become common practice to subdivide the core processes once again. There are different approaches to this depending on the type of company and business activity. These approaches are significantly influenced by the defined ''application'' of business process modeling and the ''strategy for the long-term success of business process modeling''.

In the case of a primarily market-based strategy, end-to-end core business processes are often defined from the customer or supplier to the retailer or customer (e.g. "Fromfrom offer to order", "Fromfrom order to invoice", "Fromfrom order to delivery", "Fromfrom idea to product", etc.). In the case of a strategy based on resources, the core business processes are often defined on the basis of the central corporate functions ("Gaininggaining orders", "Procuringprocuring and providing materials", "Developingdeveloping products", "Providingproviding services", etc.).

In a differentiated view without a clear focus on the market view or the resource view, the core business processes are typically divided into CRM, PLM and SCM.

Line 266:

[[File:VAC-production-company3.png|thumb|A definition of product development]]

The definition of business processes often begins with the company's core processes because they

* fulfillFulfill their own market requirements,

* operateOperate largely autonomously/independently and independently of other business areas and

* contributeOontribute to the [[contribution margin|business success]] of the company,

forFor the company

* haveHave a strong external impact,

* canCan be easily differentiated from other business processes and

* offerOffer the greatest potential for business process optimization, both by improving [[Business performance management|process performance]] or [[productivity]] and by reducing [[costs]].

[[File:VAC CRM Sales order-processing-and-project management.png|thumb|A definition of customer relationship management]]

Line 279:

Each business process should be independent - but the processes are interlinked.

The definition of a business process includes: What result should be achieved on completion? What activities are necessary to achieve this? Which objects should be processed (orders, raw materials, purchases, products, ...)? Define start and end point. Definition of operational goals.

Depending on the prevailing corporate culture, which may either be more inclined towards embracing change or protective of the status quo and the effectiveness of communication, defining business processes can prove to be either straightforward or challenging. This hinges on the willingness of key stakeholders within the organization, such as department heads, to lend their support to the endeavor. Within this context, effective communication plays a pivotal role.

Line 302:

A further decomposition of the sub-processes can then take place during [[#Modeling business process|business process modeling]] if necessary. If the business process can be represented as a sequence of phases, separated by [[Milestone (project management)|milestones]], the decomposition into phases is common. Where possible, the transfer of milestones to the next level of decomposition contributes to general understanding.

The result of the further structuring of business processes is usually a hierarchy of sub-processes, represented in value chain diagrams. It is common that not all business processes have the same depth of decomposition. In particular, business processes that are not safety-relevant, cost-intensive or contribute to the operating goal are broken down to a much lesser depth. Similarly, as a preliminary stage of a decomposition of a process planned for (much) later, a common understanding can first be developed using simpler / less complex means than ''value chain diagrams'' - e.g. with a textual description or with a [[turtle diagram]]<ref name="FUEERMANN" /> ^{(Chapter 3.1 Defining process details) ← automatic translation from German} (not to be confused with [[Turtle graphics|turtle graphic]]!).

=== Assigning the process responsibility ===

Line 322:

The following disadvantages speak against ''as is'' modeling:

* theThe creativity of those involved in the project to develop optimal target processes is stifled, as old structures and processes may be adopted without reflection in downstream target modeling and

* theThe creation of detailed ''as is'' models represents a considerable effort, also influenced by the effort required to reach a consensus between the project participants at interfaces and responsibility transitions

These arguments weigh particularly heavily if Business process re-engineering (BPR) is planned anyway.

Line 357:

[[File:VAC Process sales pipeline.png|thumb|Breakdown of the business process ''Process sales pipeline'' into sub-processes based on phases]]

August W. Scheer is said to have said in his lectures: ''A process is a process is a process.'' This is intended to express the [[recursion|recursiveness]] of the term, because almost every process can be broken down into smaller processes (sub-processes). In this respect, terms such as ''business process'', ''main process'', ''sub-process'' or ''elementary process'' are only a desperate attempt to name the level of process decomposition. As there is no universally valid agreement on the granularity of a ''business process'', ''main process'', ''sub-process'' or ''elementary process'', the terms are not universally defined, but can only be understood in the context of the respective business process model.

In addition, some German-speaking schools of business informatics do not use the terms ''process'' (in the sense of representing the sequence of [[Action (Philosophy)|actions (activities)]]) and ''function'' (in the sense of a delimited ''corporate function''/action (activity) area that is clearly assigned to a ''corporate function owner'').

[[File:FT-Excerpt-of-company-functions.png|thumb|Function tree with an excerpt of typical company actions, ''sales pipeline'' relevant functions marked]]

Line 401:

Master data can be, for example:

* theThe [[Organizational structure|business unit]] in whose area of responsibility a process takes place

* theThe business object whose information is required to execute the process

* theThe [[product (business)|product]] that is produced by the process

* theThe [[policy]] to be observed when executing the process

* theThe [[risk]] that occurs in a process

* theThe measure that is carried out to increase the process capability

* theThe [[Control (management)|control]] that is performed to ensure the governance of the process

* theThe IT-system that supports the execution of the business process

* theThe milestone that divides processes into process phases

* etc.

Line 455:

=== Process interfaces ===

Process interfaces are defined in order to

* showShow the relationships between the sub-processes after the decomposition of business processes or

* determineDetermine '''what''' the business processes or their sub-processes must 'pass on' to each other.

As a rule, this '''what''' and its structure is determined by the requirements in the subsequent process.

Line 463:

[[File:Process-flow-with-interface-to-service-process.png|thumb|A process flow with interface to a service process in EPC syntax (top) and BPMN syntax (bottom)]]

Process interfaces are therefore description elements for linking processes section by section. A process interface can

* representRepresent a business process model/sub-process model without the business process model referenced by it already being defined.

* representRepresent a business process model/sub-process model that is referenced from two/multiple superordinate or neighboring business process models.

* representRepresent two/multiple variants of the same business process model/sub-process model.

Process interfaces are agreed between the participants of superordinate/subordinate or neighboring business process models. They are defined and linked once and used as often as required in [[business process model|process model]]s.

Interfaces can be defined by:

* transferTransfer of responsibility/accountability from one business unit to another,

* transferTransfer of data from one IT-system to another,

* originalOriginal input (information / [[material]]s at the beginning of the business process),

* transferTransfer of intermediate results between sub-processes (output at the predecessor and input at the successor are usually identical) or

* finalFinal output (the actual result / goal of the business process).

In real terms, the transferred inputs/outputs are often data or information, but any other business objects are also conceivable (material, products in their final or semi-finished state, documents such as a delivery bill). They are provided via suitable transport media (e.g. data storage in the case of data).

Line 519:

In addition, representation types from [[software architecture]] can also be used:

* [[Flowchart]], standardized in DIN 66001 from September 1966 and last revised in December 1983 or standardized in [[ISO 5807]] from 1985

* [[Nassi-Shneiderman diagram]] or structure diagram, proposed in 1972/73 by [[Isaac Nassi]] and [[Ben Shneiderman]], standardized in DIN 66261.