Foundations - Business Process Modelling Introduction | Business Process Modelling with MEMO-OrgML | Further Business Modelling Concepts Introduction The analysis, representation, and management of knowledge about an organisation and its processes has always been very important [KoPl00]. A lot of work has been done on the development and evaluation of ontologies for process modelling, the specification of process modelling languages as well as on business process modelling methods and concepts (see e.g. [WaWe93], [Web97], [GrRo99], [EJLT99], [SuOs97], [Herb97], and [Öst95]). Business process models can be used for various purposes:
Depending on the analysis' purpose, a modelling language has to offer language features for modelling the facts which are in its scope. Analysis might for example support the detection of weaknesses in existing processes. Appropriate language features provided by a process modelling language support the identification of media clashes, unnecessary processes, or potentials for further optimisations. The potential for further optimisations relies on the degree of formal description of the business process model. Depending on identified weaknesses, business process re-engineering might be applicable. Business Process Modelling with MEMO-OrgML
An introductory example for a process that has been modelled using MEMO-OrgML is given in the figure below. An order is received by the distribution department and the data will be checked directly afterwards (process No. 1 called 'Check Data'). The order will be further processed if the given data is valid (event No. 4 called 'Valid Data') or aborted if the data seems to be invalid (event No. 3). Aborting an order results in sending a rejection message to the customer in process No. 9 ('Compose Rejection Message'). Further processing of the order comprises entering data into the order-management-system (process No. 2: 'Enter Order') followed by the parallel execution of the processes 6, 7 and 8. Process No. 6 is a composed process which consists of one or more sub processes. The process called 'Compose Acceptance Message' (No. 7) is a semi-automated process executed by the distribution department. Process No. 8 is a fully automated process sending a default email-message to the customer.
The following list gives a brief overview of language concepts and their notation in MEMO OrgML. Symbols depicting processes
Hierarchie of composed processes
Symbols depicting events
Control structures
Exceptions
Annotations (natural language)
Top Further Business Modelling Concepts In addition to the process-oriented concepts given above, there are two further concepts relevant for process-oriented modelling of organisations. Organisational units correspond to departments, divisions or roles assigned to a particular business process. Resources are actors or tools which are required for the execution of a business process. Organisation units
Resources Resources are essential for modelling processes [PSO99]. Processes and their relationships mainly describe dynamic aspects and the order of events. Resources assigned to processes additionally specify objects required or used by business processes. Resources are usually not available in an unlimited amount (see [Nübe01],[PSO99]). Hence, the usage of scarce resources has to be taken into account for the analysis or simulation of processes as well as for the development of a workflow application or an information system. As the resource-modelling-language for MEMO-OrgML is currently under development, no graphical notation will be given here but a short introduction into the underlying meta-model. An excerpt from this meta-model is shown in the figure below. The class AbstractResource is the root of the generalisation hierarchy on resources. Every resource has a name (name : String), a textual description (description : String) and a list of resource attributes (attributes[0..*]:ResourceAttribute). Every resource attribute is a name-type pair for the specification of user-defined attributes on resources. 
Human resources might be associated with concrete persons or employees of an organisation as well as abstract organisational units in an organisational chart. Hence, a human resource can be characterised by different aspects; it
Intangible resources are resources without a physical manifestation. Software in terms of a set of programs that run on a computer hardware is a key resource in the process of supporting workflows. The meta-type Software has two attributes: systemRequirements and scalability, both of type String. The system requirements are modelled as text and describe the environment for the execution of a software system (i.e. processor architecture, minimum main memory or operating system). Scalability corresponds to the ability of supporting growing numbers of clients. The meta-type Information was created to represent information or knowledge that is relevant within workflows. It has the attributes name (a symbolic reference to an information instance) and typeDefinition of type String which describes how the information is structured. Examples for information are certain customer data or enterprise knowledge of some kind.
- Documentation of processes of an organisation to foster communication
- Analysis of business processes
- Simulation of processes
- Support for business process re-engineering
- Software development of process-oriented applications
Depending on the analysis' purpose, a modelling language has to offer language features for modelling the facts which are in its scope. Analysis might for example support the detection of weaknesses in existing processes. Appropriate language features provided by a process modelling language support the identification of media clashes, unnecessary processes, or potentials for further optimisations. The potential for further optimisations relies on the degree of formal description of the business process model. Depending on identified weaknesses, business process re-engineering might be applicable. Business Process Modelling with MEMO-OrgML
Multi-Perspective Enterprise Modelling (MEMO) is a method for modelling organisations according to different views as well as different levels of abstraction. MEMO includes several languages for modelling static, functional, and dynamic aspects of an enterprise. One of these languages is MEMO-OrgML (Organisation Modelling Language), which supports modelling of organisational structures and processes. Resource modelling has not been subject of the first conceptualisation of MEMO-OrgML, but will be added shortly.
An introductory example for a process that has been modelled using MEMO-OrgML is given in the figure below. An order is received by the distribution department and the data will be checked directly afterwards (process No. 1 called 'Check Data'). The order will be further processed if the given data is valid (event No. 4 called 'Valid Data') or aborted if the data seems to be invalid (event No. 3). Aborting an order results in sending a rejection message to the customer in process No. 9 ('Compose Rejection Message'). Further processing of the order comprises entering data into the order-management-system (process No. 2: 'Enter Order') followed by the parallel execution of the processes 6, 7 and 8. Process No. 6 is a composed process which consists of one or more sub processes. The process called 'Compose Acceptance Message' (No. 7) is a semi-automated process executed by the distribution department. Process No. 8 is a fully automated process sending a default email-message to the customer.
The following list gives a brief overview of language concepts and their notation in MEMO OrgML. Symbols depicting processes | Abstract process |  | Aggregated process |  | Manual process | ||
 | Semi-automatic process |  | Automatic process |  | Continuing process | ||
 | Process performed by contractor |  | Process performed by an autonomous institution |  | Externally managed process('Black Box') | ||
 | Displays processes as components of abstract or aggregated processes. |
 | Start-Event |  | End-Event |  | Relevant change of information change (unspecified event) | ||
 | Message arrived |  | Temporal event - certain time interval has exceeded |  | Temporal event - certain point in time has been reached | ||
 | Process produces event |  | Event triggers process | |
 | Parallel execution |  | Synchronization after termination of one of the parallel processes | |
 | Synchronization after termination of all parallel processes | |||
 | Exceptions are defined for the entire system (e.g. collapse of communication channel, time out) |
 | Constraints |  | Other comments |
The static structure of organisations can be described by an organisational chart. Such a chart shows an organisation by its sub-units and their respective relationships. The meta-model for the modelling of organisational charts is given in part a) of the figure to your right. An abstract organisation unit might either be a position or an organisational unit. Every organisational unit is a composition of other abstract organisational units. A position is an elementary description of the responsibilities of an employee. An example for an organisational chart is given in part b) of the figure to your right: An imaginary company consists of three departments (procurement, production, and distribution). Organisational units and roles are elements assigned to business processes and refer to human actors which are responsible for the execution of a business process. Organisational units and positions as described here can be assigned to business processes. Roles are not necessarily defined in an organisational chart but can be assigned to business processes. |  |
Within the context of process modelling, we generally distinguish human, physical, and intangible resources. A human resource is an abstraction of different perspectives on staff. Examples for such perspectives are concrete employees, roles filled by employees or business-oriented functions. Physical resources comprise all tangible objects used within a business process. Examples for physical resources are production plants, raw material, or computer hardware. In contrast to this, intangible resources do not have a physical manifestation. Examples for intangible resources are data, information, software, or even knowledge.
Human resources might be associated with concrete persons or employees of an organisation as well as abstract organisational units in an organisational chart. Hence, a human resource can be characterised by different aspects; it
- can play an active role
- may be responsible for the execution of e-business processes
- needs some qualification and competences for its job
The type HumanResource is a subtype of AbstractResource and has the two attributes qualification and competenceProfile, both of type String. The qualification is an objectively describable criterion for the capabilities of a human resource. Usually, the qualification certificate is issued by an established educational body. The competence of a human resource reflects personal skills of human beings. Hence, a competence profile corresponds to a set of skills or competences of a particular role or person.
Physical resources comprise all tangible objects used within a business process and are neither human nor intangible. According to Heinen [Hei88, p. 242] - in the context of industrial production - it can be differentiated between non-consumable resources (Potentialfaktoren) and consumable resources (Repetierfaktoren). Non-consumable resources are not used up during a manufacturing process and are still available afterwards, whereas consumable resources either become a part of the resulting product or are used up and therefore not available anymore [SS01, pp. 89 f]. At this point we abstract from physical resources, because these are not relevant in our context of workflow applications and the perspectives we present on it.
Intangible resources are resources without a physical manifestation. Software in terms of a set of programs that run on a computer hardware is a key resource in the process of supporting workflows. The meta-type Software has two attributes: systemRequirements and scalability, both of type String. The system requirements are modelled as text and describe the environment for the execution of a software system (i.e. processor architecture, minimum main memory or operating system). Scalability corresponds to the ability of supporting growing numbers of clients. The meta-type Information was created to represent information or knowledge that is relevant within workflows. It has the attributes name (a symbolic reference to an information instance) and typeDefinition of type String which describes how the information is structured. Examples for information are certain customer data or enterprise knowledge of some kind.
Posts
1 comment:
Does your company's org chart reflect your team vision? I think that is the question that every company should be asking themselves. You need to make an organizational chart for your business, no matter what size your company is because it ensures your company can scale. You can easily create Organizational structures of your company with Organizational Chart Software like Creately. There are 1000s of templates and examples of org charts to get started for free
Post a Comment