Business process modeling: Difference between revisions

Revision as of 15:14, 6 April 2024

Revision as of 15:22, 6 April 2024

Line 149:

* determine the inputs required and the outputs expected

* determine the sequence and interaction

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

* determine the resources needed

* assign the responsibilities and authorities

Line 239:

* 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.

* ''Management processes'' govern the operation of a company. Typical management processes include corporate governance and [[strategic management]]. They define corporate objectives and monitor the achievement of objectives.

* ''Core processes'' constitute the [[core business]] and create the primary value stream. Typical operational processes are [[purchasing]], [[manufacturing]], [[marketing]], and [[sales]]. They generate visible, direct customer benefits.

Line 259:

* "Customers" describes the business processes that can be assigned to specific customer groups (e.g. private customer, business customer, investor, institutional customer)

* "Products" describes the business processes that are product-specific (e.g. current account, securities account, loan, issue)

* "Sales channels" describesdescribe the business processes that are typical for the type of customer acquisition and support (e.g. direct sales, partner sales, online).

The result of structuring a company's business processes is the ''process map'' (shown, for example, as a [[value chain diagram]]). ''Hermann J. Schmelzer and Wolfgang Sesselmann'' add: «There are connections and dependencies between the business processes. They are based on the transfer of services and information. It is important to know these interrelationships in order to understand, manage, and control the business processes.»<ref name="SCHMELZER" /> ^{(Chapter 2.4.3 Process map) ← automatic translation from German}

Line 280:

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.

In elucidating this point, Jörg Becker and Volker Meise elucidate that the communication strategy within an organizational design initiative should aim to garner support from members of the organization for the intended structural changes. It is worth noting that business process modeling typically precedes business process optimization, which entails a reconfiguration of process organization - a fact well understood by the involved parties. Therefore, the communication strategy must focus on persuading organizational members to endorse the planned structural adjustments.»<ref name="BECKER-MEISE" /> ^{(Chapter 4.15 Influencing the design of the regulatory framework) ← automatic translation from German} In the event of considerable resistance, however, external knowledge can also be used to define the business processes.

Line 373:

;Workflow

A [[workflow]] is a representation of a sequence of tasks, declared as work of a person, of a simple or complex mechanism, of a group of persons,<ref>[http://www.iso.org See e.g., ISO 12052:2006]</ref> of an organization of staff, or of machines (including IT-systems). A workflow is therefore always located at the elementary process level. The workflow may be seen as any abstraction of real work, segregated into workshare, work split, or other types of ordering. For control purposes, the workflow may be a view of real work under a chosen aspect.

==== Functions (''Tasks'') ====

Line 395:

For August W. Scheer in ARIS, this would be the basic information of the organization view, data view, function view and performance view.<ref name="SCHEER">August-W. Scheer: ''ARIS: Von der Vision zur praktischen Geschäftsprozesssteuerung'' in August-W. Scheer and Wolfram Jost (Hrsg.): ''ARIS in der Praxis: Gestaltung, Implementierung und Optimierung von Geschäftsprozessen'', Springer, Berlin/Heidelberg/New York 2002, ISBN 3-540-43029-6</ref> ^{(Chapter 1 The vision: A common language for IT and management) ← automatic translation from German}

For Andreas Gadatsch in GPM ('''G'''anzheitliche '''P'''rozess'''m'''odellierung (German), means holistic process modelling), this would be the basic information of the organizational structure view, activity structure view, data structure view, and application structure view.<ref name="GADATSCH"/> ^{(Chapter 3.2 GPM - Holistic process modelling) ← automatic translation from German}

For Otto K. Ferstl and Elmar J. Sinz in SOM ('''S'''emantic '''O'''bjekt'''m'''odell), this would be the basic information of the levels Business plan and Resourcen.

Line 424:

The integration of external [[document]]s and IT-systems can significantly increase the added value of a business process model.

For or example, direct access to objects in a [[knowledge database]] or documents in a [[Business rule|rule framework]] can significantly increase the benefits of the business process model in everyday life and thus the acceptance of business process modeling. All IT-systems involved can exploit their specific advantages and cross-fertilize each other (e.g. link to each other or standardize the filing structure):

* short response times of the knowledge database; characterized by a relatively high number of auditors, very fast adaptation of content, and low requirements for the publication of content - e.g. realized with a [[wiki]]

* Legally compliant documents of the rule framework; characterized by a very small number of specially trained auditors, validated adaptation of content, and high requirements for the release of content - e.g. implemented with a [[document management system]] system

* Integrating graphical representation of processes by a BPM system; characterized by a medium number of auditors, moderately fast adaptation of content, and modest requirements for the release of content

If all relevant objects of the ''knowledge database'' and / or documents of the ''rule framework'' are connected to the processes, the end users have context-related access to this information and do not need to be familiar with the respective filing structure of the connected systems.

Line 436:

=== Model consolidation ===

This is about checkschecking whether there are any redundancies. If so, the relevant sub-processes are combined. Or sub-processes that are used more than once are outsourced to support processes. For a successful model consolidation, it may be necessary to revise the original decomposition of the sub-processes.

''Ansgar Schwegmann and Michael Laske'' explain: «A consolidation of the models of different modeling complexes is necessary in order to obtain an integrated […]model.»<ref name="SCHWEGMANN-LASKE" /> ^{(Chapter 5.2.4 Model consolidation) ← automatic translation from German} They also list a number of aspects for which model consolidation is important:

Line 450:

The chaining of the sub-processes with each other and the chaining of the functions (''tasks'') in the sub-processes is modeled using Control Flow Patterns.

Material details of the chaining (What does the predecessor deliver to the successor?) are specified in the process interfaces, if intended.

=== Process interfaces ===

Line 485:

== Representation type and notation ==

In practice, combinations of ''informal'', ''semiformal'' and ''formal'' models are common: ''informal'' textual descriptions for explanation, ''semiformal'' graphical representation for [[Visualization (graphics)|visualization]], and ''formal language'' representation to support [[simulation]] and transfer into executable code.

=== Modelling techniques ===

Line 587:

=== Business reference model ===

[[File:Government Business Reference Model.svg|thumb|360px|Example of the US Federal Government Business Reference Model<ref>FEA (2005) [https://www.archives.gov/records-mgmt/pdf/rm-profile.pdf FEA Records Management Profile, Version 1.0]. December 15, 2005.</ref>]]

A [[business reference model]] is a reference model, concentrating on the functional and organizational aspects of an [[Business|enterprise]], [[Tertiary sector of the economy|service organization]], or [[government agency]]. In general, a [[reference model]] is a model of something that embodies the basic goal or idea of something and can then be looked at as a reference for various purposes. A business reference model is a means to describe the business operations of an organization, independent of the organizational structure that performperforms them. Other types of business reference model can also depict the relationship between the business processes, business functions, and the business area's business reference model. These reference models can be constructed in layers, and offer a foundation for the analysis of service components, technology, data, and performance.

The most familiar business reference model is the Business Reference Model of the US federal government. That model is a [[function model|function-driven]] framework for describing the business operations of the federal government independent of the agencies that perform them. The Business Reference Model provides an organized, hierarchical construct for describing the day-to-day business operations of the federal government. While many models exist for describing organizations – [[organizational chart]]s, ___location maps, etc. – this model presents the business using a functionally driven approach.<ref>[https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/fea_docs/FEA_CRM_v23_Final_Oct_2007_Revised.pdf FEA Consolidated Reference Model Document] {{Webarchive|url=https://web.archive.org/web/20101011082020/http://www.whitehouse.gov/sites/default/files/omb/assets/fea_docs/FEA_CRM_v23_Final_Oct_2007_Revised.pdf |date=2010-10-11 }}. Oct 2007.</ref>

Line 595:

A business model, which may be considered an elaboration of a business process model, typically shows business data and business organizations as well as business processes. By showing business processes and their information flows, a business model allows business stakeholders to define, understand, and validate their business enterprise. The [[data model]] part of the business model shows how business information is stored, which is useful for developing [[software code]]. See the figure on the right for an example of the interaction between business process models and data models.<ref name="SS93">Paul R. Smith & Richard Sarfaty (1993). [http://www.osti.gov/energycitations/servlets/purl/10160331-YhIRrY/ Creating a strategic plan for configuration management using Computer Aided Software Engineering (CASE) tools.] Paper For 1993 National DOE/Contractors and Facilities CAD/CAE User's Group.</ref>

Usually, a business model is created after conducting an interview, which is part of the [[business analysis]] process. The interview consists of a facilitator asking a series of questions to extract information about the subject business process. The interviewer is referred to as a facilitator to emphasize that it is the participants, not the facilitator, who provide the business process information. Although the facilitator should have some knowledge of the subject business process, but this is not as important as the mastery of a pragmatic and rigorous method interviewing business experts. The method is important because for most enterprises a team of facilitators is needed to collect information across the enterprise, and the findings of all the interviewers must be compiled and integrated once completed.<ref name="SS93"/>

Business models are developed as defining either the current state of the process, in which case the final product is called the "as is" snapshot model, or a concept of what the process should become, resulting in a "to be" model. By comparing and contrasting "as is" and "to be" models the business analysts can determine if the existing business processes and information systems are sound and only need minor modifications, or if reengineering is required to correct problems or improve efficiency. Consequently, business process modeling and subsequent analysis can be used to fundamentally reshape the way an enterprise conducts its operations.<ref name="SS93"/>