Process modeling: Difference between revisions

Content deleted Content added
m brackets fixed using AWB
See also: removed duplicate links and links that are already in article body, per WP:NOTSEEALSO; alphabetized
Line 26:
The activity of [[business model|modeling a business]] process usually predicates a need to change processes or identify issues to be corrected. This transformation may or may not require IT involvement, although that is a common driver for the need to model a business process. [[Change management]] programmes are desired to put the processes into practice. With advances in technology from larger platform vendors, the vision of business process models (BPM) becoming fully executable (and capable of round-trip engineering) is coming closer to reality every day. Supporting technologies include [[Unified Modeling Language]] (UML), [[model-driven architecture]], and [[service-oriented architecture]].
 
Process modeling addresses the process aspects of an enterprise [[Enterprise Businessbusiness Architecturearchitecture]], leading to an all encompassing [[Enterpriseenterprise Architecturearchitecture]]. The relationships of a business processes in the context of the rest of the enterprise systems, data, organizational structure, strategies, etc. create greater capabilities in analyzing and planning a change. One real-world example is in corporate [[mergers and acquisitions]]; understanding the processes in both companies in detail, allowing management to identify redundancies resulting in a smoother merger.
 
Process modeling has always been a key aspect of [[business process reengineering]], and continuous improvement approaches seen in [[Six Sigma]].
Line 59:
 
=== By alignment ===
Processes can be of different kinds.<ref name=Rolland1998/> These definitions “correspond"correspond to the various ways in which a process can be modelled”modelled".
 
* Strategic processes
Line 81:
[[Image:flexibility.png|thumb|right|300px|Flexibility of Method construction approaches <ref name="HBO">
A.F. Harmsen, [[Sjaak Brinkkemper]] and J.L.H. Oei (1994). ''Situational Method Engineering for information Systems Project Approaches''. North Holland</ref>]]
It was found that while process models were prescriptive, in actual practice departures from the prescription can occur.<ref name=Rolland1999/> Thus, frameworks for adopting methods evolved so that systems development methods match specific organizational situations and thereby improve their usefulness. The development of such frameworks is also called Situationalsituational Method[[method Engineeringengineering]].
 
Method construction approaches can be organized in a flexibility spectrum ranging from 'low' to 'high'.<ref name=HBO/>
 
Lying at the 'low' end of this spectrum are rigid methods, whereas at the 'high' end there are modular method construction. Rigid methods are completely pre-defined and leave little scope for adapting them to the situation at hand. On the other hand, modular methods can be modified and augmented to fit a given situation. Selecting a rigid methods allows each project to choose its method from a panel of rigid, pre-defined methods, whereas selecting a path within a method consists of choosing the appropriate path for the situation at hand. Finally, selecting and tuning a method allows each project to select methods from different approaches and tune them to the project's needs." <ref name="Rolland1997">[[Colette Rolland]] (1997). 'A Primer for Method Engineering. Proceedings of the INFORSID Conference''.</ref>
 
== Quality of methods ==
Line 94:
In short this can make assessment of both the product quality and the process quality of modeling techniques with regard to a set of properties that have been defined before.
 
Quality properties that relate to [[business process modeling]] techniques discussed in <ref name=hommes/> are:
 
* Expressiveness: the degree to which a given modeling technique is able to denote the models of any number and kinds of application domains.
Line 144:
Modeling Domain is the set of all statements that are relevant and correct for describing a problem ___domain, Language Extension is the set of all statements that are possible given the grammar and vocabulary of the modeling languages used. Model Externalization is the conceptual representation of the problem ___domain.
 
It is defined as the set of statements about the problem ___domain that are actually made. Social Actor Interpretation and Technical Actor Interpretation are the sets of statements that actors both human model users and the tools that interact with the model, respectively ‘think’'think' the conceptual representation of the problem ___domain contains.
 
Finally, Participant Knowledge is the set of statements that human actors, who are involved in the modeling process, believe should be made to represent the problem ___domain. These quality dimensions were later divided into two groups that deal with physical and social aspects of the model.
Line 151:
In particular, the framework is too static in its view upon semantic quality, mainly considering models, not modeling activities, and comparing these models to a static ___domain rather than seeing the model as a facilitator for changing the ___domain.
 
Also, the framework’sframework's definition of pragmatic quality is quite narrow, focusing on understanding, in line with the semiotics of Morris, while newer research in linguistics and semiotics has focused beyond mere understanding, on how the model is used and affects its interpreters.
 
The need for a more dynamic view in the semiotic quality framework is particularly evident when considering process models, which themselves often prescribe or even enact actions in the problem ___domain, hence a change to the model may also change the problem ___domain directly. This paper discusses the quality framework in relation to active process models and suggests a revised framework based on this.
Line 175:
Several empirical surveys carried out still do not give clear guidelines or ways of evaluating the quality of process models but it is necessary to have clear set of guidelines to guide modelers in this task. Pragmatic guidelines have been proposed by different practitioners even though it is difficult to provide an exhaustive account of such guidelines from practice.
In,<ref>B.Silver, Ten Tips for Effective Process Modeling,BPMInstitute.org, <http://www.bpminstitute.org/articles/article/article/bpms-watch-ten-tips-for-effective-process-modeling.html>, Wednesday January 30, 2008</ref> 10 tips for process modeling are summarized, many technical definitions and rules are provided, but it does not teach how to create process models that are effective in their primary mission - maximizing shared understanding of the as-is or to-be process.
Most of the guidelines are not easily put to practice but “label"label activities verb–noun”verb–noun" rule has been suggested by other practitioners before and analyzed empirically.
From the research.<ref>J. Mendling, H.A. Reijers, J. Recker, Activity Labeling in Process Modeling: Empirical Insights and Recommendations, Information Systems. URL: <http://eprints.qut.edu.au/19625/></ref> value of process models is not only dependent on the choice of graphical constructs but also on their annotation with textual labels which need to be analyzed. It was found that it results in better models in terms of understanding than alternative labelling styles.
 
Line 193:
The second limitation relates to the prioritizing guideline the derived ranking has a small empirical basis as it relies on the involvement of 21 process modelers only.
 
This could be seen on the one hand as a need for a wider involvement of process modelers’modelers' experience, but it also rises the question what alternative approaches may be available to arrive at a prioritizing guideline.<ref name=mendling19/>
 
== See also ==
* [[Business process modeling]]
* [[Model selection]]
* [[wiktionary:Process|Process (science)]]
* [[Process algebra]]
* [[Process architecture]]
* [[Process calculus]]
* [[Process flow diagram]]
* [[Process (science)]]
* [[Process Specification Language]]
* [[Process ontology]]
* [[Process Specification Language]]
 
== References ==