3. ISO 9000:2000 standard requirements for Business Process Modelling

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 requirements1 for a QMS

where an organisation needs to demonstrate the organisation its ability to provide products and services that

fulfil customer- and applicable regulatory requirements, to enhance the satisfaction os customers satisfaction

and other interested parties, and improve the performance of the organisation.

The ISO9001:2000 requirements can be interpreted in the context of enterprise modelling: this

standard may be understood as a policy / requirements level enterprise reference model applicable to all

types of enterprises2 . Consequently when enterprise models are developed (as may be captured as function

& process, information, organisation and resource modelling views) they must satisfy the required

ISO9001:2000 quality properties.

The ISO 9000:2000 standards put define requirements for business process performance monitoring,

identification of the organisation’s strengths and weaknesses, assessment of the QMS’s performance

maturity level, continuous improvement, complementing quality objectives with other objectives related to

growth, founding, profitability, etc. , what ISO9000:2000 makes thetherefore extends sion from the

traditional QMS to more a general management system of the organisation.

The ISO 9000:2000 family of standards is identified based on in 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. , etc.), where two

Two of these principles of them (process approach and system approach to management) could be

considered ascapture 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 type of 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,

1 The ISO9000:2000 series of standards consists of requirements (ISO9001:2000) and guidelines (ISO9000:2000 and ISO9004:2000)2 According to the GERA life-cycle phases.

How deep to describe processes, who should do it / have the right to access, modify;What are the criteria to determine the sufficiency of the level of detail (maturity, trust, skill,….)

organisations are many times left to one’s their own devices, in the selection of detailed design and invention

implementation of approaches to fulfil the standard’s requirements.

The introduction of the business process related requirements in theis new in ISO9000:2000, has put

for theand is the really first time that the demand for a wide scale deployment of BPM is required in from

enterprisesthe those who adopt a QMS. In many cases, where organisations As a response, organisations are

not familiar with the BPM often , they develop own 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 ly of

process descriptions. Non-systematic approach to business process description could lead to a limited

(re)usability of once 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 Section 2.2.2.1).

Aforementioned The aforementioned requirements of the new ISO9000:2000 standards and the

recognition of obstacles in to the implementation of BPM has lead the authors to provide develop some

general guidelines to that can be followed to improve the efficiency, and support the implementation

practical adoption, of BPM in industry, while consideringwith the aim of satisfying the business process

related standard requirements of ISO9000:2000.

3.1. The business Business process modelling related requirements of the ISO 9000:2000 standards

Between From the eight quality management principles in the ISO 9000:2000 standards, two of them

canmay be considered as process BPM related principles:

process approach which enables ensures that the desired result is achieved more efficiently when

activities and related resources are managed as a part of a process (where the management of activities

and related resources is not limited to, and 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 the a QMS, the ISO 9000:2000 family of standards requires from that the organisation must:

iIdentifyication of the processes needed for the QMS and ensure their application throughout the

organisation;

dDetermineation of the sequences and interactions of these processes;

dDetermineation of necessary criteria and methods, which needed to ensure that both the operation and

control of those processes are effective;

ensuring Ensure the availability of resources and of information necessary to support the operation and

monitoring of this processes;

monitoringMonitor, measure ing and analyse ing of these business processes.

1

1

2

Welding

Welding

CP_ACP_B

SP_1

WP1

WP2

QP1

Drawing1

3

Assembly

SP_2

ASS

CP_C

SP_3

Product

QP2

Event3Event3

VV

Activity2Activity2

Activity1Activity1

Event2Event2

Activity3Activity3

Event1Event1

Figure 6.: a/ Functional process model, b/ Decisional process model Behavioural process model

In Sthe sections 2.2.3.1 and 2.2.3.2, we have presenteddescribed the two types of process models

(functional 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 creates an assumptionexpectation and assumption, that all processes are

equally suitable for the a uniform description (modelling using a single process modelling language) and

therefore that they can always be described by procedural (behavioural) process models. Unfortunately

(what many times couldthis expectation is not uncommon in present-day be noticed in the practice).

Beside the description ofIn addition to structured processes (e.g. accounting proceduresss,

technology technological proceduresss, etc.), many unstructured (e.g. new product development process) and

ill-structured processes (e.g. innovative type of processes) exist in an organisation shall be described.

Considering a) business process properties (and consequently their suitability for modelling) and b) standard

requirements about the determination of process sequences, we canit can be bring the following

concludedsions, that:

I nterpreted in a strict way, the requirement of the ISO standard, to determine the ‘process sequences’,

could can not always be met;

I nterpreted 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, tthe employment use of a combination of behavioural and functional process models

(modelling languages) is essential necessary to model all types of process in the organisationbusiness

processes.

2

In addition to the description of operational processes (processes from at the ‘physical’ level of in the

cybernetic model of artificial systemsmodel), a great deal of care must be taken in the identification and

definition of management processes., where Given that thethe majority of management processes of them

could be categorised asare either unstructured or ill-structured, processes. Therefore, in the selection of an

adequate model type the adoption to these process characteristics is must be taken into accountneeded.

As the a response on to the particular nature of management processes, the GRAI laboratory has

introduced the GRAI methodology for a management-oriented presentation description of an enterprise.

The GRAI methodology proposes to develop a high level model of management processes using a

GRAI-Grid, (as a graphical modelling formalismlanguage of that GRAI methodology) does not aim at the

detailed modelling of management processes but a) identifies points decision roles (also called decisional

centres) where decisions are made and communicated, and b) defines the decisional hierarchy through ,

mutual connections and interactions among these decisional centres (Dumeningts 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.

Any As a first step in developing this high level model of a management system the decisional

centrse (see the individual squares in of the GRID on in the figure 7.a.) are identified. As a second step, each

decision centre’scould be further described by a) its objectives, constraints, decisional variables, required

inputs and delivered outputs may be added; (which these together compose together aare called a decisional

frame for of any individual decision centre. ), and b)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 The detailed model of decision making processes can be developed – decisional centre or

decision making process respectively, depending on the nature of the process –, can usingbe described in

form of a functional (activity) model or , a behavioural model [12][13]. However, often only a detailed or as

a circumscription in natural language description is used. The description detailed model of the behavioural

aspect may of course be different in granularity from decision centres 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.

h=1yp=3m

h=1mp=1w

h=1wp=1d

realtime

horizonperiod

I/Omngm

co-ordination/planning

resourcemngm

Decision framework for DC1(OBJECTIVES, CONSTRAINTSAND DECISION VARIABLES)

Decision framework for otherDC ensured through DC1

Inputs

(Intra- and inter systemic)

Outputs

(Intra- and inter systemic)

DC1

Figure 7: a/ The GRAI-Grid concept, b/ Co-ordination links between DCs

3

WhenAssume, that , based on an objective, a decision has been made to carry out some activitiesachieve

some objectives during a subsequent 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 these activitiesthis plan need to be monitored. If the feedback (performance indicators (as the feedback

from the physical system) shows that there is a deviation (or likely deviation) from achieving the objective,

adjustments must be made either to the to decisions or to the objectives. Therefore, pPerformance indicators

must be developed and suited for the set of objectives at hand and represent are part of the information links

that flow between among decision centres, the physical system, and the external environment.

The structure of the this information flow between decision centres (especially if this information

needs to be stored in a database) may 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)

[14].

Financial transaction recordsMinutes of meetingsProject documents

Client requestsCustomer dataMarket investigation data

Customer confirmation of product

Allocate and adjust resourcesAllocate budgetAssign roles and responsibilities

Approve orders and payments, Control project operations

Internal resource availabilityAggregated financial records Weekly/monthly reports of project team

Distribute workloadsDevelop or acquire project resources, balance budget

Control delivered services and raw materials

Schedule project activities

Monitor project

Develop make or purchase policies, quality control plans, take make or purchase decisions

Develop detailed project plan

Verify and validate product (as project deliverable)

Financial and non-financial strategic performance indicators

Agree and decide on product requirements specification

Negotiate client requirementsDecide high level productspecsifications

Verify and validate projects (Steering Committees)

Determine activities needing project organisation

Develop projectproposal

Approve/revoke proj. proposals

Monitor strat performanceProposeresource dev.plan, budget, investment, resource allocation plansSelect plan options

Proposed sales, marketing and procurement plans

Determine company strategy:mission, vision, strategic objectives, policies, principles, performance indicatorsStrategic activities/programmes

Product & production historyResource and production cost statistics

Propose deployment and development strategy of resources and capabilities

Propose market strategy and propose product strategy

Market analysis reportsBenchmarking reportsBest practice information sourcesFundamental research reports

Develop projectmaster plan

ApproveMasterPlans

Assess resources and capabilities to determine

project feasibility

Records of demonstratedcapabilitiesResource availability from ERP system

Project Enterprise Reference Models

Requirements analysis report

Regular checkpoints and milestone reports of projects

External resource availability

Technical management decisions Work allocation decisions

Supplier, service provide details

PARENT ENTERPRISE

PROJECT ENTERPRISE

External info. To manage products To plan To manage resources Internal info.

Figure 8: The 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

From presented, theA GRAI-Grid model could be considered asis a road map of key decisions (decision-

making processes), their interactions (presented shown as by decisional frameworks and information links)

and relations (presented byshown as a hierarchy of decisionan centresl system). Such A decisional grid

4

model could also be considered asis a valuable contribution infor the design of an efficient and effective

organisation.

No matter of all presented, the question which modelling language to take still remains. The answer

seems to be evident, that no single modelling language could meet all standard and modelling requirements;

consequently, a set of suitable modelling languages is needed.

For example,The the GRAI-Grid might can be used for the description of the functions of the

management and control system on the high level. Starting from this model. After producing the GRAI-Grid

model, we havethere is a choice to further describe model, on the detailed (‘micro’) level, the activities of

decision centres. The GRAI methodology proposes the use of activities with a GRAI Nets, but other

process modelling languages might also be used (IDEF0, or CIMOSA, Workflow modelling language, etc) –

whichever suits the given process category function view language.

There are always arguments why one language is more suitable then the other (however a modelling

methodology would make that choice). So theThe selection of an appropriate modelling language would be

based on a) what do we want to do with the model will be used for, b) what tools do we haveare available

which that can manage these models, and c) what languages are best fitted to my the personnelpeople who

will use the models.

To improve the efficiency of the business process modelling, the organisation should adopt an

enterprise integration methodology, and developdevelop or deploy the a business process (or rather

enterprise) modelling workbench that supports, composed of adequate modelling methodology, a set of well

formalised and interrelated modelling languages and tools. Such a workbench should be , and populated

with the partial 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, 20033 ).

3.2. Business process interactions

The ISO 9000:2000 standards refer to the process approach and processes interactions on as followsthe

following way: “For organisationsn 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 on in a very detailed and consistent way, by employment ofusing functional

(activity) or behavioural process models (modelling languages), the definition of process interactions usually

does not necessarily require more a fully detailed specification (description) of every processes in question.

TNamely, the focus of is on the definition of process interactions is inthrough the identification and

3 Hysom, R (2003) Enterprise Modelling – The readiness of the Organisation. In Handbook of Enterprise Architecture. P.Bernus, L.Nemes and G.Schmidt (Eds) Berlin : Springer. Pp373-416.

5

description of the exchanged objects (transformation – material and information and control). between

interacting processes. However,The development of a complete and consistent (functional or behavioural)

model of all interacting processes could be many timesvery difficult (or even not feasible) in practice. and

not contributing in observation of entity in question. ThereforeHowever, to fulfil the demands of the standard

the authors propose employment of some to define process interactions, a mixture of high-level and detailed

and abstract functional models may be satisfactory. to fulfil aforementioned modelling demands.

Why do some conventional functional or behavioural modelling languages not match

aforementioned modelling requirements? Behavioural modelling languages base on underlying assumption,

that the sequence of activities could be defined. But, this is not always feasible, particularly not on a high-

level definition and description of processes or process interaction respectively, because of their unstructured

system (process) nature.

Furthermore, functional modelling languages many times demand a detailed definition and

specification of modelled processes. Therefore, the designed system of interacting processes could be appear

very complex and do not emphasiswithout emphasising (allows) the description of observed property of

processes – their interactions.

P1

P2

P3

Envir-onment

I I

O

O

X1 X2

X3

transformation inputCONTROL

feedback

Figure 9: The process interaction matrix

To define emphasise process interactions, the authors propose the application of a simple matrix named

process interaction matrix (see the Figure 9). The A process interaction matrix is defined by basic syntacticx

and semantic rules:

individual Individual business processes (internal processes as well as interacting external ones) are

follow represented as boxes on in the matrix’s diagonal (P1 to Pnn) form and are numbered from the top

left to the lower right corner of the matrix; each process box is numbered sequentially beginning with 1;

the (the numbering sequence of processes in the matrix (from top left to lower right) does not facilitate

imply the expression of a sequence of execution and or timing); between activities;

any Any process may takes use certain inputs and creates outputs.; inputs Inputs of individual process

are represented by as boxes, situated which take the place in thein the same row where the process box is

6

located (left and right form the process box); outputs of individual process are also represented by as

boxes, situated which in the same take the place in the column of where the process box is located. (up

and down from the process box); therefore the The box at the intersection box of the P1’s column of the

process P1 (which creates output) and the row of the process P22 is an output of P1 used by P2. (which

takes the output of process P1 as an input),Thus the matrix represents the interaction of P1 and P2. -

interacting object(s) of these two processes. The Ffigure 9 presents shows the interaction of process P11

and P22 with the process P33, where the box X11 represents the interaction between process P11 and P33

(the output of process P11 and input of process P33) andwhile box X22 represents the interaction between

P22 and P33 (the output of process P22 and input of process P33). The figure Figure 9 also represents the

interaction between process P33 and some external process (form that is part of the external

environment), where the box: X33 represents is the object exchanged in this their interaction (the output

of process P33 is the and input of an external process);

process Process interactions (or more precisely, interacting objects) could may be categorised into two

broad categories: a) transformation objects (material or information), and or b) control objects (as

information entities, like laws, policies, standards, etc.), which can guideguding or constrainingt a

process to deliver desired deliverables). As a convention, the names of mMaterial transformation objects

are presentedwriten by in normal text style, information objects by in bold and control objects by in italic

style.

If necessary, each process box (e.g. P1) may be represented in more detail in a separate matrix.

The process interaction matrix is similar in expressive power to the IDEF0 modelling language, with the

exception that resource- (mechanism) inputs are not distinguished from ordinary- or control inputs, and

arrow bundling/branching is not supported within one matrix (however, the decomposition of interface

objects can be done on a detail-matrix). On the other hand the minor addition of a graphical notation to

distinguish material and information objects has been found useful in practice. The advantage of this matrix

variant of IDEF0 is its efficient use of space on a page, and the possibility to construct it using a simple text

editor or spreadsheet program.

The Note that the GRAI-Grid, presented in the previous sectionSection 3.1, could is alsobe also

considered as some a kind of process interaction matrix, which because it defines the interactions between

decisional centres or decisional process respectively (processes form on the management- and control level).

3.3. Product realisation and support processes

The ISO9000:2000 standards put the requirement for the identification of “the organisation’s product

realisation processes, as these are directly related to the success of the organisation. Top management

should also identify those support processes that affect either the effectiveness and efficiency of the

realisation processes or the needs and expectations of interested parties”.

Many organisations encounter difficulties The practice, in introduction of the new ISO9000:2000

process related standard requirements, has shown difficulties for many organisations in the attempt to

7

identification identify, and differentiation differentiate between, product realisation and support processes.

To define a line between aforementioned these two groups of processes, authors believe that employment of

knowledge from the field of some strategic management concepts may be used. could improve

understanding of their essence.

Namely, strategic Strategic management emphasises the importance of the identification,

development, accumulation and maintenance of the organisation’s core capabilities and competencies in

order to provide maintain a long-term source of organisational competitiveness or and competitive

advantage, and consequently, the a successful market position of the organisation.

The ISO standard’s definition of product realisation processes could many times lead to their a

‘narrow’ understanding and meaning. Namely, product Product realisation processes are usually associated

with the development, manufacturing, sales or distribution type of processes. However, the identification of a

company’s core capabilities or and competencies or (and their associated processes) respectively, according

to authors believe, could represent a may reveal a larger complementary set, that includes of both traditional

product realisation processes and other processes of the key importance. After all, (because thea core

product, or the end product, represent justare only the material manifestations of an organisation’s

capabilities).

To understand the relationships between product realisation processes and an organisation’s core

competencies, the definition of some basic notions, like such as capabilities and competences, should be

given first.

According to ISO 9000:2000, a capability is defined as the ability of an organisation, system or

process to realise a product that will fulfil the requirements for that product. By a generalising ation of

thethis presented definition, the a capability can be defined as a firm’s ability to execute business processes

and activities to produce and deliver a required product through the deployment of the firm’s resources.

Therefore, a capability is a permanent or temporary aggregation of non-specific and/or specific asset s needed

to execute certain business processes.

Capabilities may be (functional – (e.g. the ability to development of the new products), or cross

functional – (e.g. quality- or integrative capabilities –, such as the ability to e.g. management of a network

organisation). Capabilities which that directly contribute and improve the value perceived by the

market/customers are called the core competencies of the organisation (Prahalad and Hamel, 1990).

A core competence is a company-specific capability (capability of strategic importance), which

makes the company distinct from its competitors, and defines the essence of the company’s business.

Firm-specific (core) capabilities may also be considered through the perspective of the firm’s

competitive advantage. Namely, governance over core capabilities should result in competitive advantage for

the firm.

Companies could posses many competencies, some of them are core and some of them are non-core.

Irrespective of the strategic importance of core competencies, organisations management are could be

manyoften times not clear confused about what is and what is not a core competence. It is essential to be

able to make such a distinction, because any neglected core capability may result in the loss or weakening of

8

the company’s competitive position. However, how to make such a distinction? The first criterion is

whether the activities that are part of the competence really contribute to long-term corporate prosperity.

The second criterion of being a core-competence is that the competence must ‘pass’ the tests and meet the

criteria below:

customer value – a core competence must make a disproportionate contribution to customer-perceived

value,

competitor differentiation – the capability must be competitively unique,

extendibility – a core competence is not merely the ability to produce the current product configuration

(however excellent that product line may be), but it also must be able to be used as a basis of potential

new products.

For instanceexample, according to presented these criteria, a very efficient home-developed

accounting system, supported by a company-specific software, cannot be considered as a core-competence of

the a manufacturing company. Even though this is a specific asset of the organisation, because it does not

directly contribute to the value of products or services perceived by the customer, therefore these the

accounting capabilities cannot be considered as a core competence.

Authors believe thatAs a conclusion: the identification of an organisation’s core competencies and

associated processes is equally important as the identification and definition of processes, the (traditionally

perceived) as product realisation processes. Therefore, it is the core competencies and all associated

(support) processes that shall need to be identified, defined and managed through their entire life-cycle.

According to Hamel and Prahala (1994), core competencies are the soul of the company and as such, their

management must be an integral part of the management process of company executives.

3.4. From Business Process Modelling to Enterprise Modelling

The ISO 9000 family of standards, besides in addition to business process modelling, put requires ments for

the identification, definition and description of other enterprise entities as well. Standard requirements for

the definition of authorities and responsibilities, required and possessed categories of individual capabilities,

or process key-performance indicators represents is an extension that leads from business process modelling

to enterprise modelling.

For a systematic categorisation of modelling- related standard requirements, the GERA entity model

content views could be employedused. GERA defines four different model content views for the user

oriented process representation:

Function View (already has been presented in detail by representationin the discussion of functional,

behavioural and decisional types of process models).

Information View collects the knowledge about objects of the enterprise (material and information) as

they are used and produced in the course of the enterprise’s operations. The information to be modelled

9

is identified from the relevant activities and is structured into an enterprise information model in the

information view for information management and for the control of the material and information flow.

Resource View represents the resources (humans and technical agents as well as technological

components) of the enterprise as they are used in the course of the enterprise’s operations. Resources are

assigned to activities according to their capabilities and structured into resource models.

Organisation View represents the responsibilities and authorities on of all entities identified in the other

views (processes, information, resources). It This view caters foralso represents the structure of the

enterprise’s organisation by organising aggregating the identified organisational units into larger units

such as departments, divisions, sections, etc.

3.4.1. Organisational view related standard requirements

With the emergence of decentralised organisations, flat hierarchies, etc., the explicit knowledge about the

roles of individuals, and who is responsible for what,, becomes an invaluable asset is indispensable for any

enterprise, especially for those operating according to new management paradigms.

Typically, humans may assume different roles, as for example: chief executive, market & sales,

technical (R&D), finance, production planning, logistics, information system designers, quality inspectors,

etc.

Also alternative organisational structures may be deployed, for example elements of an organisation

may be linked hierarchically or heterarchically and demonstrate properties of holons, webs, nets, temples or

clusters. Further organisational structuring may occur on a functional, process or geographic basis.

Often humansIndividuals and groupings of humans individuals will be assigned a number of roles

and responsibilities. These assignments which need to be carried out concurrently and cohesively, where

each may involve different reporting lines and control procedures.

Due to complex and changing conditions in internal and external organisation environment and no

matter how sophisticated and integrated an enterprise can be, a) the role of humans in the enterprise remains

fundamental and b) the ability to manage and deploy human resources effectively and collectively is key to

the competitive position of an enterprise.

Therefore, itIt is important to understand when, by whom and how decisions are made in the

enterprise as well as who can fulfil certain tasks in theor to replacement of others. The presented

requirements for tothe defineition and communicateion of responsibilities and authorities within the

organisation are is also put by included in the ISO 9000:2000 standards.

Responsibilities and authorities cannot be defined completely and consistently before processes are

described and the decisional system is designed, because responsibilities and authorities constitute only one

view of enterprise processes. Wide scale deploymentThe systematic use of functional, behavioural and

decisional process modelling provides a description of processes and activities form of the physical

(customer service & product) and management – and control levels as well as the relations between these

(according to the cybernetic model of an artificial system), and through this, the explicit . The identification

10

of activities and decision centres represents a allocation of fundamental precondition that responsibilities for

activity execution are allocated (definition of responsibility) and authorities over decision centres are

appointed (definition of authorities).

Therefore, responsibilities and authorities cannot be defined completely and consistently before

processes are described and the decisional system is designed. The definition of responsibilities and

authorities represent just a particular view on enterprise processes.

The description of responsibilities and authorities could be done by employment of different matrix.

Organisational matrix usually put on one -axise decisions or tasks to be carried out and on the other relevant

organisational rolesentities. By employment of acronyms (PR- proposal, R-Review, A-Approval, etc.) the

individual role regarding decisions or task is defined. The figure Figure 10 represents shows a simple

example of the matrix of authorities acronyms are used for shorthand (PR- proposal, R-Review, A-Approval,

etc.).

Matrix presentation of The organisational view could may be represented using traditional be

accomplished by employment of different organisation charts (a tree) – at least to describe the organisational

hierarchy structure. However, if the Organisational organisational chart is represented in a matrix (see Fig.

10) could it will assign management (decision) tasks to organisational units and thus may be also considered

as a kind of (simplified) functional model of an enterprise organisation.

Organisation The organisational chart, as the most visible end-result of organisational design,

structures divisions into departments, departments into sections, and so on, and allocates manager for each of

these.

Review of requirements related to the product (contract review) – type A

Strategic contracts

Customer complaint

Unsettled debts

500.000 EUR

500.000 to 1,000.000

EUR

over 1,000.000

EUR

BOARD President

A A A

Member A A

Marketing Marketing VP

C C C PR

Purchasing coordin. PR

Economics

R

AEO

FEO R R R R R

Legal affairs R R R R R

SBU President of SBU

A R R R E

Supply chain Mngr PR PR PR E PR

R&T Mngr

Production Mngr

11

Quality assurance

R R

LEGEND: Proposal – PR, Review – R, Approval – A, Execution – E, Control – C, Assessment – AS, Request – RQ

Figure 10: Authority matrix

3.4.2. Resource view related standard requirements

In addition to the explicit definition of the role of humans in the enterprise (the definition of the

organisation), the description of required capabilities (for any single position) and possessed capabilities (for

any individual) has have to be carried knownout as well.

The ISO9000:2000 standard requires that personnel shall be competent on the basis of appropriate

education, training, skills, experience, talents or, roots backgrounds, and intellectual, psychological or

physical capabilities, where. competence A competence is considered as a demonstrated capaability to apply

knowledge or skills and accomplish the task while and delivering planned appropriate results.

Therefore, the organisation shallmust:

determine Determine the necessary competence levels for personnel performing work that directly or

indirectly affects ing product quality. Note that this requirement is equally applicable to personnel

involved in production & service delivery and management & control;,

allocate Allocate competent personnel on to jobs to be competent for (matching the of personnel

competencies of the individual with the capabilities required by the job requested competences); and

provide Provide training or take other action to satisfy these needs (tofoster the continuous development

of employee competencies upgrade an individual competency up to the required level).

To identify, define, and actively manage the personnel capabilities and competencies of personnel, the

organisation shall can define main categories of capabilities and describe them by belonging relevant

attributes.

12

Figure 11: Professional development: attainment of human resource competencies

The standard also requires that the organisation should manages professional promotions for their

employees. Therefore, organisations have to design professional development plans (career planning) for any

individual and actively execute and manage those plans.

Career planning and execution of promotion plans could not be efficient if the enterprise has n’t no

been structured in the wayprocesses to achive this, e.g. through (the division of tasks and jobs in a way that

promotes) to allow gradual professional promotiondevelopment.

The Figure 11 represents shows an example of an R&D department’s by organisationalprofessional

development map structure allowingdecribing the focussed and gradual professional progress of any

individuals based on his/hertheir demonstrated capabilities (delivered and recognised results).

Any An employee in the R&D department may starts his/her career as at the assistant level to

acquire basic skills and concepts of product development. L; later on, he/shethe next typical transition would

be to continues on to the position (named also typical transitions) of constructor and developer. At that stage

the basic professional training and development is completed and the professional career starts branching as

where the individual may continue to become a) a the highly focused and competent professional (researcher

/ technical expert), b) manager (project manager) or c) marketing position manager (product manager).

An R&D department is may also be considered as the main “recruiting” department, which

represents is the source of professionals for different other departments, such as (for instance for sales or

marketing department, ) as well for different (senior) management positions (e.g. need for the new plant

manager).

13

In the definition of tTypical positions (transitions) and professional migration steps

(transitions)paths, presented shown in Figure 1211, one should represent aaim at a balance between the

scope of the given managerial-/leadership and professional scope role and consequently the required

managerial-, /leadership- and professional capabilities /– competencies.

Both the enterprise engineering process and the operational environment employ rely on a significant

amount of technology. Technology, which is either production oriented and therefore involved in producing

the enterprise products and customer services, or management and control oriented, providing the necessary

means for communication and in-formation processing and information sharing.

Therefore, besides modelling of human capabilities, at least two other fundamental types of

functional entities (resources), has have to be modelled: a) devices or machines (including IT, manufacturing

or other types of technological devices) and b) applications (i.e. software packages).

Both types of functional entities could be defined in terms of their technical characteristics and

constraints (e.g. data access time for database server, maximum feed range rate of the a machine, number of

units procssessed per unit of time, etc.), types of functional operations offered, the level of machine

autonomy, etc. and Aersource may be described by the using the following example set of characteristics:

its identification

its type

its nature (consumable or non-consumable)

its capacity

its availability

its roles

its functionality

its locations

its shareabiltiy

its mobility

its reliability estimates

its cost per unit

its analytical cost, etc.

Resources can bemay also be organised grouped into classes according to their nature. Generic classes can be

defined listing essential resource characteristics. Subclasses of these are more detailed and them more detail

classes, which inherit these characteristics from generic classes and as well as add future further specific

ones, . can be established to describe more specialised type of resources.

Furthermore, cCapability models would have to be developed for aggregate resources according to

the intended / existing resource structure resource models could be accomplished by resource organisation

14

models (e.g. shop floor models, system architectures, information models, infrastructure models),

communication models (e.g. network models), etc.

Despite the importance of resource management, few modelling methods applicable to enterprise

modelling offer resource constructs. Only the CIMOSA resource modelling view and IEM (Integrated

Enterprise Modelling) provide means to model in detail theed structure to modelof resources and their

related characteristics.

3.4.3. Information view related standard requirements

The In Ssection 2.1 presents thea simple model of an artificial system was discussed. This model defines the

following functions for where the Management Information System (MIS):

connects the physical system and the management and control system (or decision system),

exchangesing information with the external environment,

and deliversing feedback, and

aggregatesing information suitable for decision support.

The requirements for the application use of an MIS are is also put expressed inby the ISO9000:2000

standard: . Namely, the standard refers, that “the organisation shall apply suitable methods for monitoring

and, where applicable, measurement of the management system processes. These methods shall demonstrate

the ability of the processes to achieve planned results”.

In the definition or design of key performance indicators (KPI), organisations are many timesoften

too much focused on the development of a set of financial indicators, which show the growth of the revenue,

profit rate, market share, etc.

Traditional financial indicators reflect the result of the company’s previous activities and efforts –

(they can may also be called ‘lagging’ indicators). , therefore supplemental non-financial indicators have to

be developed and employed.

Non-financial indicators are useful to monitor characterise better the structural development of the

company, the organisation’s potential and its corporate health. Therefore, – those these indicators could

bemay be considered called ‘as leading’ indicators. Therefore in addition to financial indicators a set of non-

financial indicators have to be developed and used.

The importance of the application use of both categories types of performance indicators is also

recognised by the ISO9000:2000 standards. The standards require that beside in addition to financial

measurement metrics also the organisation should also the measurement of process performance, and other

success factors identified by management, such as the satisfaction of customers, of people in the organisation

and of other interested parties. There are a number of , etc. based on the employment of different methods

and techniques to achieve this, e.g. (like benchmarking, process assessments, etc.).

15

The definition and design of KPI could be supported by one of the contemporary methodologies

developed for this purpose, as for instancesuch as the EFQM model or Balanced Scorecard (BSC)

methodology.

Kaplan and Norton (1994) in their BSC methodology, identify four categories of performance

indicators (learning and growth, business processes, customer relationship and financial performance). ,

while theThe EFQM Excellence Model (1999) organises 32 sub-criteria into 9 major criterion groups. BSC

also allows the creation of a tangible link between the organisation’s vision and its translation into strategic

objectives, key success factors, key projects and performance indicators.

To provide the control of management with control over these key performance indicators the

support of a MIS by software application is essential. A major part of the MIS is a sSoftware application

should that provide facilitates the data collection and presentation (froman on-line connection of KPIs with

relevant databases and reports), and a highly automated automatic generation of their KPI values, as well the

distribution of relevant KPIs to individuals.

In the design of software application of MIS an adequate methodology could be employed. M*

methodology represents an efficient methodology for CIM information system design and analysis, which is

composed of four major phases: a) organisation analysis delivering information system requirements (in our

case the definition and design of KPIs), b) conceptual design delivering high-level data model, c) logical

design and d) physical design for the specific DBMS.

For modelling data and information aspect, many different modelling languages could be employed

as for instance: (extended) entity-relationship model, IDEF1X, EXPRESS, SQL or CIMOSA information

modelling language.

3.5. The ISO9000:2000 and business process reference models

The ISO9000 standard requires that the organisation shall plan, develop and control the processes needed for

product realisation.

Many product realisation processes can be categorised asare fairly a standard, structured and

repetitive type of processesin nature, which could beand can be described by behavioural or functional

process models (e.g. sales processes, order conformation, shipment processes, customer complaint resolving

process, etc). These processes are usually well defined, described and formalised by in so-called ‘quality

procedures’ (QP) of in the organisation’s QMS.

However, enterprises could incorporate in their repertoire of models other product realisation

processes, categorised aseven if they are unstructured or ill-structured (as for instance example, the product

design and development process). QPs of for those these processes many times do not describeare usually

not described, or if they are, not in sufficient processes very in detail and do not to provide detail guidelines

or procedures for their execution. For such processes QPs might would typically defineexist only as just

high-level requirements for review, verification, validation, monitoring, inspection, and test activities and

activities attached to determination of quality objectives.

16

Some of those these processes (e.g. product design and development processes) are performed and

managed in the a fashion of thesimilar to project management. To improve quality, reliability and efficiency,

as well as to provide a support of for the project design (project planning and scheduling), implementation

and operation (project execution and control) of these projects, the organisations should development of the

process reference models isfor these processes a crucial.

Project rReference models (of the project and including the processes performed in the project) do

not intend necessarily have to standardise on a single particular process but they rather they should provide

propose a process model, based on which each individual project may design its own, tailored process. The

existence (and adoption) of such a reference model promotes commonality without forcing uniformity on a

process that by its nature is expected to be different each time it is executed.

For instance example, the a reference model of fora product design and development processes may, shall

determine:

the design and development stages, and the (key activities in each stage,)

the review, verification and validation processes that are appropriate to each design and development

stage,

the responsibilities and authorities for design and development tasks,

inputs and the outputs of the design and development process.

howeverAn activity model may be able to capture the commonality in every such process, whereupon any

singlethe actual procedure (sequences of activities) and the life-history (development in time) of the every

single development project will isbe potentially unique.

Process Behavioural reference models, implemented can be developed for by individual projects, are

appropriate for projects that have a repetitive nature, i.e., where the product development is following a

relatively predominantly predictable path.

In the authors’ experience The rreusable process reference models provide benefit to the company though the

following gains:

supporting project planning, and scheduling of activities and resources, etc. - – therefore development

activities do not start from scratch;

improving the efficiency and quality of project planning and scheduling;

providing a repository of knowledge and experience for the project planning phase of projects (through

the formalisation and reuse of this knowledge);

providing the user / project manager with a checklist of important activities in during the project’s

development (bill of activities);

helping to create a common communication platform, and providing for the entire organisation a greater

chance of understanding what is represented in the project plan.

17

18