User:Jan.pippal/sandbox

Methodology for Modeling and Analysis of Business Process
Methodology for Modeling and Analysis of Business Process (MMABP) - is a ‘language independent’ methodology based on the set of meta-models which define the basic concepts and express the basic principles of the methodology, and completed with the set of techniques, consistency rules and patterns. Methodology is used to analyze and design process system model. MMABP has been introduced at Department of Information Technologies at University of Economics in Prague (Faculty of Informatics and Statistics) and has been published and presented during numerous conferences (ISD98, BIS99, ISD2000, BIT2001). Process management specialist Prof. Ing. Václav Řepa, CSc. is the 'father' of this methodology. Methodology is frequently used as a basis for bachelor and diploma thesis focused on business process modeling.

Introduction
We understand business process as an equilibrium of intention and causality. This idea is based on the fact that business process always represents the way of following some intention. Every business process has the goal which represents the meaning of the process. Every action performed in the process than should be targeted to its goal.

== Three principles of information modeling == Methodology of process analysis follows three interconnected principles: Modeling - principle that comes from the idea that information system is a formal representation of real system (real world). Information is not created inside the information system it is just mediated. Data comming into the information system are informations about the events and actions from real world and not changed they are leaving the system in different structure with added value. Every organization is a model of elementary rules of given business segment together with organization goals and values. Modeling helps us understand the business. Abstraction - principle of abstraction helps us to split the modeled organization into mentally acceptable pieces to reduce its complexity and extensiveness. It causes the need for clustering processes and objects according to their common logical context or according to actions and processes they are part of. Three architectures - specifies three architectures of information system (processes). Conceptual architecture represents common, pure content system model without any technological or implementation specification (WHAT is the content of the system). Technological architecture puts technological restrictions on modeled system (HOW is the content of the system realized with selected technology). Implementation architecture consider specific implementation details like what database system is used, what development environment is used, what programming language is used (WHAT tools are used to implement technological design).

Meta-model
Meta-model defines essential concepts of this methodology - terms and terms context, principles and mutual relations of all concepts. We can understand meta-model as a conceptual model describing modeling of organization. It consists of two meta-models and conceptual model of mutual relations. The meta-model consists of three main packages which correspond to the main dimensions of the business system model: Business Substance Meta-model - specifies the basic concepts required for a model of a business substance and defines basic needs/possibilities of their mutual interconnections (how to model what the real world is) Business Process Meta-model - defines the essential concepts in the field of business processes and their relationships, and express the principles which the modeling of business processes should be based on (how to model how the real world behaves) Business Models Consistency - specifies basic rules required for models of both types to be mutually consistent. It uses basic concepts from both metamodels and extends them with new concepts and constructs required for the consistency specification.

== Business model == MMABP distinguishes between two main types of models:

Business Objects Model
Represents static model of real world. It describes what the real world (business) consists of and what are the elementary, essential objects, their attributes and relations between them. Appart from that object model can also contain methods and alghorithms that are part of the object in its life cycle. Basic representations of object modeling are State diagrams and Class diagrams from UML.

Business Process Model
Compared to object model process model is dynamic. It describes sequentiality of actions from initial to end process state according to predefined schema influenced by occuring events and their mutual combinations. Basic representations of process modeling are Process diagram (BPMN) and Eriksson-Penker diagram. There are two main kinds of Business Process Patterns in the MMABP: Basic Business Process Flow Pattern - according to the Basic Process Flow Pattern the business process should be described as a sequence of activity blocks interrupted by state blocks starting with just one event block (starting event) and resulting in one or more end states. BP patterns for particular situations

== Global and detailed view ==

Global view (system view)
The purpose of global view is to provide contextual view when we see all processes as a part of the system of processes. From the model the differentiation between key and support processes is clear and interactions between them are outlined. Key processes provide product which is the essence of the business whereas support processes provide services for other processes (both key and other support). Main goal of global view is especially model completeness. Level of detail is secondary objective.

Global object model MMABP uses Class diagram from UML to describe static structure as an existence of objects via classes and interactions/relations between them. Global object model can be used up to the level of source code of computer application. Every class in diagram is specified with its attributes and operations.

Global process model MMABP uses Eriksson-Penker notation (UML domain extension) for modeling system of processes. Global process model shows all key and support processes and because of the complexity of the modeled organization it can be splitted into multiple connected areas. It helps us to understand the internal and external dependency of processes and relations between them.

Detailed view
While global view describes the whole system of processes detailed view places its focus on one selected process. The purpose of detailed view is to catch the logical flow of content and time context (time context is not considered in global view). Every key process should be provided with detailed view up to the desired granularity of detail. We need to differentiate between process states (every process state represents waiting for event to occur) and map actors. BPMN is used to describe the process flow.

Detailed object model MMABP uses State Chart to describe life cycle of one object (class) in modeled system. All possible object states and possible transitions between them are specified. Each described life cycle has to correspond to the particular object class in the Class Diagram. Transitions always have to correspond with attributes and methods of the class.

Detailed process model (process flow model) Detailed process model describes logic of process of every single action of the process. Every key process from global process model must be described up to the level of detail needed for that process. Process states must be distinguished and process actors must be mapped. MMABP uses BPMN (Business Process Modelling & Notation) for detailed process models.

Model consistency
There are two main general kinds of consistency: Correctness - means that nothing in the model is in contradiction with anything in this model as well as in other models of the same system Completeness - means that nothing essential is missing in the model

For each of four models (global object, global process, detailed object and detailed process) we keep track of completeness and correctness for each model and also for relation between models.

Model completeness criterias
Completeness of conceptual model Between every two classes there must be at least one connection through association. It means that sepearated classes and single classes are not allowed. Also we need to make sure that the content of model is relative to goal, purpose of modeling. Every object should have its identity, attributes, operations, relations.

Completeness of class object life cycle Model must cover the whole life cycle of the class object from its initiation up to every possible end state. Every important state transition must be specified. Every operation from object life cycle should have three main operation types - constructor, destructor, transformer.

Completeness of system of processes For every speficic business product there must be a key process identified. Every action relevant in business context must be a part of at least one described key or support process. There must be at least one connection between every two processes. The purpose is to assure that every action has traceable connection with primary organization function.

Completeness of business process Model must cover whole business process from its initial event up to every possible end state. Every event, action influencing business process flow must be specified. All necessary process states which are waiting for other events must be specified.

Model correctness criterias
Correctness of conceptual model Every identified class must represent existing object of the class (real or abstract). Every association must represent valid existing relation for every instance of that class. Every specified attribute must be an attribute of object of that class and all its instances. All specified class operations must be compliant with object life cycle.

Correctness of class object life cycle Must describe only valid combinations of actions and action results and is applicable for every instance of that class.

Correctness of system of processes Every business process must provide business products or services as an output to fulfill primary organization function or as a subdelivery for other process. Every relation between two processes reflects providing service output as subdelivery. Every business process represents alligned structure of main actions.

Correctness of business process Described business process actions and their combinations, inputs and outputs must be valid for every instance of that process. Every action must be elementary.

Other described criterias for model relations Correctness and completeness of process relations, object relations, process roles, object roles, actions, reasons.

Methodic procedure of construction of process managed organization
Main frame for process construction in organization and its allignment is a result of organization business process analysis. Organization process analysis takes first six steps of the procedure. The result of process analysis is complete objective business process model and its mutual relations.

Step 1 Clarifying the basic existence of the necessary activities and their organization in the context of key processes
The goal of this step is to map all meaningful and necessary actions in organization which correspond with its organization primary funciton and general rules of business. We explore how people works and what is the flow of their work. These are usually processes/procedures as the people know them - work procedures, administration procedures. This way we will discover the fundamentals of support processes which contains also parts of key processes. This step should be executed simultaneously with step 2 because in order to understand the relations between existing processes we need to take a look from different perspective - key process perspective.

Step 2 Identifying key processes
Simultaneously with step 1 we have to idenfity key processes in organization. Key processes provide added value. In order to identify key processes correctly we need to understand who is the customer/consumer and what does that mean. Every key process then corresponds with organization key products (what keeps the business on the market). At first key processes contains a lot of support and other processes and the purpose of step 3 is to reduce them. Every key process should be analysed in detail as a procedure. As a part of detailed analysis inputs, outputs, process states and actors can be found.

Step 3 Key process reduction
The goal of this step is to remove all actions and subprocesses with supporting characteristic. Every relatively single, continous, standalone, unitary section is removed from key process and formulated as a support process. Intuition, domain, standards and technology knowledge is used when identifying support parts of key processes. After removing there is interface created between key process and removed support process.

Step 4 Harmonizing system of processses
After key processes are refined of its support actions it is required to edit global system of processes. Every removal from key process introduces new support process. Not only new processes appear in the global model but also new associations with other processes can occur as well as new owner role assignment.

Step 5 Process interface description as a service
In this step a detailed description of process interface is done. Every process interface represents a service provided by one process to another. Every interface is described as SLA - service level agreement. SLA contains description of the product (provided service, its purpose), description of the main parameters of the product, metrics etc.. Important part is the cost of the service.

Step 6 Process revision
In this step all consequences of discovered facts in step 5 are considered. Revision of key processes flow, their managing events and reactions is performed and description is improved. The more deeper description of new discovered services in interfaces the more imcompleteness and errors pops up especially in global view. After the step 5 and 6 the whole designed system of key and support processes is completed and consistent.

Step 7 Infrastructure development
System of processes defined in previous steps is sufficient ground for establishment of infrastructure which is in allignment with organization primary function. In this step collaboration on support processes interfaces is done in order to create SLA on the supplier side. According to specification of SLAs it is easier for organization to determine competences according to defined process roles.