15
3. What ISO 9000:2000 standard requirements must business process models satisfy?
The ISO 9000 family of standards has been developed to assists organisations to implement and operate effective quality management system (QMS). The ISO 9000 standards specify requirements[1] for a QMS where an organisation needs to demonstrate its ability to provide products and services that fulfil customer- and applicable regulatory requirements, to enhance the satisfaction of customers and other interested parties, and improve the performance of the organisation (ISO/TC 176, 2002).
The ISO9000:2000 requirements can be interpreted in the context of enterprise modelling: this standard may be understood as a policy / requirement level enterprise reference model applicable to all types of enterprises[2]. Consequently when enterprise models are developed (as may be captured as function & process, information, organisation and resource modelling views) they must satisfy the required ISO9000:2000 quality properties.
The ISO 9000:2000 standards define requirements for business process performance monitoring, identification of the organisation’s strengths and weaknesses, assessment of the QMS’s maturity level, continuous improvement, complementing quality objectives with other objectives related to growth, founding, profitability, etc. ISO9000:2000 therefore extends the traditional QMS to more general management system of the organisation.
The ISO 9000:2000 family of standards is based on eight quality management principles:
· customer focus
· leadership
· involvement of people
· use a process approach
· use a systems approach to management
· continual improvement
· factual approach to decision making
· mutually beneficial supplier relationships.
Two of these principles (process approach and system approach to management) capture general requirements directly related to the identification, definition and description of business processes.
The ISO 9000:2000 standards, as a requirement specification and policy level standards, do not provide more detail and elaborated guidelines and reference models how to fulfil these standard requirements (even though the ISO9000:2000 and ISO9004:2000 guidelines are a good start). Therefore, organisations are many times left to their own devices in the selection of detailed design and implementation approaches to fulfil the standard’s requirements.
The introduction of business process related requirements is new in ISO9000:2000, and is the first time that a wide scale deployment of BPM is required from the those who adopt a QMS. As a response, organisations not familiar with BPM often develop in-house business process modelling languages, methodologies and approaches. These languages are usually characterised by a weak definition of the modelling language’s syntax and semantics, and consequently by low uniformity and unequivocality of process descriptions. Non-systematic approach to business process description could lead to a limited (re)usability of the created business process models, and might not even satisfy the criterion to be called a model in the strict sense of the word (see the Section 2.2.2.1).
The aforementioned requirements of the new ISO9000:2000 standards and the recognition of obstacles to the implementation of BPM has lead the authors to develop general guidelines that can be followed to improve the efficiency, and support the practical adoption, of BPM in industry, with the aim of satisfying the business process related requirements of ISO9000:2000.
3.1. Business process modelling related requirements of the ISO 9000:2000 standards
From the eight quality management principles in ISO 9000:2000, two may be considered as BPM related principles (ISO/TC 176, 2002):
· process approach which ensures that the desired result is achieved more efficiently when activities and related resources are managed as part of a process (where the management of activities and related resources is not limited to, or constrained by, functional, divisional or unit borders), and
· system approach to management, which requires the identification, understanding and management of interrelated and interacting processes as a system.
To implement a QMS, the ISO 9000:2000 requires that the organisation must:
· Identify the processes needed for the QMS and ensure their application throughout the organisation;
· Determine the sequences and interactions of these processes;
· Determine necessary criteria and methods, which ensure that both the operation and control of those processes are effective;
· Ensure the availability of resources and of information necessary to support the operation and monitoring of processes;
· Monitor, measure and analyse business processes.
Figure 6.: a/ Activity process model, b/ Behavioural process model
In Sections 2.2.3.1 and 2.2.3.2, we described two types of process models (activity and behavioural), as well as three main process categories (structured, unstructured and ill-structured processes). The ISO9000:2000 standard requirement for the determination of the ‘sequence of processes’ could unintentionally create an expectation and assumption, that all processes are suitable for a uniform description (modelling using a single process modelling language) and that they can always be described by behavioural process models. Unfortunately, this expectation isn’t uncommon in present-day practice.
In addition to structured processes (e.g. accounting procedures, technological procedures, etc.), many unstructured (e.g. new product development process) and ill-structured processes (e.g. innovative processes) exist in an organisation. Considering a) business process properties (and consequently their suitability for modelling) and b) standard requirements about the determination of process sequences, it can be concluded that:
· Interpreted in a strict way, the requirement of the ISO standard to determine the ‘process sequences’ can not always be met;
· Interpreted in the spirit of the standard, ‘sequences of processes’ would better be understood as the modelling of the structure and relations of processes – where the structure is the composition of processes out of more elementary processes and activities, and the relations include information- and material exchange (interfaces), and/or succession sequences and events, and/or relations in time. The decision about which one of these relations to model depends on the process category, and thus appropriate process model types (and, accordingly, modelling languages) need to be used. Furthermore, the model(s) of business process structure and relations may have to capture additional characteristics that are essential for process design, prediction, analysis, planning, scheduling and control; and
· In general, the use of a combination of behavioural and activity process models (modelling languages) is necessary to model business processes.
In addition to the description of operational processes (processes at the ‘physical’ level in the cybernetic model of artificial systems), a great deal of care must be taken in the identification and definition of management processes. Given that the majority of management processes are either unstructured or ill-structured, in the selection of an adequate model type these process characteristics must be taken into account.
As a response to the particular nature of management processes, the GRAI laboratory has introduced the GRAI methodology for a management-oriented description of an enterprise.
The GRAI methodology proposes to develop a high level model of management processes using a GRAI-Grid, a graphical modelling language, that does not aim at the detailed modelling of management processes but a) identifies decision roles (also called decisional centres) where decisions are made and communicated, and b) defines the decisional hierarchy through connections and interactions among these decisional centres (Dumeingts et al, 1998). The processes of decision centres may then be further detailed as management processes, and modelled using a functional or a behavioural modelling language.
As a first step in developing this high level model of a management system the decisional centres (see the individual squares of the GRID in the figure 7.a.) are identified. As a second step, each decision centre’s objectives, constraints, decisional variables, required inputs and delivered outputs may be added; these together are called a decisional frame of any individual decision centre. As a third step the task to be performed to create a decision may be described (e.g. in natural language, as a list), which completes the high level decisional model.
The detailed model of decision making processes can be developed – depending on the nature of the process – using a functional (activity) model (KBSI, 2001a) or a behavioural model (KBSI, 2001b). However, often only a detailed natural language description is used. The detailed model may of course be different in granularity from decision centre to decision centre, depending 1) on the level of formalisability of the decision process in question, 2) on the intended skill levels of human resources to fill these management roles, 3) on the formalisation needs of the links among decision centres.
Figure 7: a/ The GRAI-Grid concept, b/ Co-ordination links between DCs
Assume, that a decision has been made to achieve some objectives by some time in the future (defined by a time horizon), and suitable activities are planned for this purpose. According to quality management principles the execution and results of this plan need to be monitored. If performance indicators (the feedback from the physical system) show that there is a deviation (or likely deviation) from achieving the objective, adjustments must be made either to the decisions or to the objectives. Performance indicators must be developed and suited for the set of objectives at hand and are part of the information links that flow among decision centres, the physical system, and the external environment.
The structure of this information flow (especially if this information needs to be stored in a database) has to be modelled using a language suitable for data modelling (e.g. using Entity Relationship modelling, the IDEF1X modelling language, Class diagrams/UML, or similar).
Figure 8: A GRAI-Grid model (high level model) of the decision centre of two enterprise entities: a parent enterprise and a project, showing decision centres and their relationships
A GRAI-Grid model is a road map of key decisions (decision-making processes), their interactions (shown as decisional frameworks and information links) and relations (shown as a hierarchy of decision centres). A decisional model is valuable for the design of an efficient and effective organisation.
The GRAI-Grid can be used for the description of the functions of the management and control system on the high level. Starting from this model there is a choice to further model, on the detailed (‘micro’) level, the activities of decision centres. The GRAI methodology proposes the use of GRAI Nets, but other process modelling languages might also be used (IDEF0, CIMOSA, Workflow modelling language, etc) – whichever suits the given process category.
The selection of an appropriate modelling language would be based on a) what the model will be used for, b) what tools are available that can manage these models, and c) what languages are best fitted to the people who will use the models.
To improve the efficiency of business process modelling, the organisation should adopt an enterprise integration methodology, and develop or deploy a business process (or rather enterprise) modelling workbench that supports a set of well-formalised and interrelated modelling languages and tools. Such a workbench should be populated with the reference models that were adopted by the enterprise, and with particular enterprise models: AS-IS models, and various versions of TO-BE models (for the discussion of the variety of TO-BE models see (Hysom, 2003).
3.2. Business process interactions
The ISO 9000:2000 standards refer to the process approach and processes interactions as follows (ISO/TC 176, 2002): “For organisations to function effectively, they have to identify and manage numerous interrelated and interacting processes. Often, the output from one process will directly form the input to the next process. The systematic identification and management of the processes employed within an organisation and particularly the interaction between such processes is referred to as the process approach.”
While in theory all business processes (their structure, interaction of process activities, object flows, etc.) could be described in a very detailed and consistent way using functional (activity) or behavioural process models, the definition of process interactions does not necessarily require a fully detailed specification (description) of every process in question. The focus is on the definition of process interactions through the identification and description of the exchanged objects. The development of a complete and consistent (functional or behavioural) model of all interacting processes could be very difficult (or even not feasible) in practice. However, to fulfil the demands of the standard to define process interactions, a mixture of high-level and detailed functional models may be satisfactory.
Furthermore, functional modelling languages many times demand a detailed definition and specification of modelled processes. Therefore, the designed system of interacting processes could appear very complex and without emphasising the description of process interactions.
Figure 9: The process interaction matrix
To emphasise process interactions, the authors propose the application of a simple process interaction matrix (see Figure 9). A process interaction matrix is defined by basic syntactic and semantic rules:
· Individual business processes (internal processes as well as interacting external ones) are represented as boxes in the matrix’s diagonal (P1 to Pn) and are numbered from the top left to the lower right corner (the numbering sequence does not imply a sequence of execution or timing);
· Any process may use certain inputs and creates outputs. Inputs of individual process are represented as boxes, situated in the same row where the process box is located (left and right form the process box); outputs of individual process are also represented as boxes, situated in the same column where the process box is located. The box at the intersection of P1’s column and the row of process P2 is an output of P1 used by P2 (output of process P1 as an input). Thus, the matrix represents the interaction of P1 and P2. Figure 9 shows the interaction of process P1 and P2 with process P3, where X1 represents the interaction between process P1 and P3 (the output of process P1 and input of process P3) while X2 represents the interaction between P2 and P3 (the output of process P2 and input of process P3). Figure 9 also represents the interaction between process P3 and some external process (that is part of the external environment). X3 is the object exchanged in this interaction (the output of process P3 is the input of an external process);
· Process interactions (or more precisely, interacting objects) may be a) transformation objects (material or information), or b) control objects (information entities, like laws, policies, standards, etc.) guiding or constraining a process. As a convention, the names of material objects are written in normal text style, information objects in bold and control objects in italic style;