BUSINESS ARCHITECTURE

Transcription

1 TABLE OF CONTENTS BUSINESS ARCHITECTURE 1 Introduction Learning objectives An overview of Business Architecture Business model Business model definition Business model description Organization model Organization model definition Organization model description Business process definition Business process description The hierarchical model Decomposition versus specialization Hierarchy levels The hierarchy taxonomy of business processes Elementary activities The flow model Flow models The flow model adopted Business process and organization structure Organization Chart Organization Manual Organization structure versus Business Processes Functional BP Cross-functional BP Cross-organizational BP The BP map in organizations Porter s Value Chain The management perspective Management perspective and Anthony s pyramid The decision perspective The operational perspective: the AL (Activity Levels) model Planning Execution Monitoring... 33

2 7.5.4 Control Information management The AL grid The AL Method An overall enterprise framework (OFE) The map of support processes Accounting IT services IT planning Demand management Systems projects IT operations Performance management The ITIL framework The map of primary processes Early frameworks: Blumenthal Early frameworks: Nolan Industry frameworks The GEF framework The SCOR framework The structure of the SCOR framework The approach to the supply chain Functional domains of supply chain processes Analysis levels of the supply chain processes The SCOR method: a short case study Phase 1 (Top Level and Configuration Level) Phase 2 (Process Element level) Phase 3 (Implementation level) Phase 3 step 1 : model the hierarchy of the process element Phase 3 step 2 : model the flow of elementary activities Phase 3 step 3 : identify use cases Other industry frameworks: etom Further definitions Business Services and Business Processes Business Service: a definition Business to business and business to consumer services Business services versus IT services Business processes versus physical processes The knowledge perspective The Business Intelligence perspective... 61

3 14 Review questions Simple exercises Acknowledegments References... 63

4 FIGURE INDEX Figure 1 Domains of Enterprise Architecture... 7 Figure 2 Elements of business models... 8 Figure 3 Galbraith s star model for organization design (redrawn)... 9 Figure 4 A CRASO schema of an e-commerce sell and delivery BP Figure 5 CRASO meta-model: CRASO elements and related associations Figure 6 Hierarchical diagram of an e-commerce sales and delivery BP Figure 7 Level 1 breakdown of a BP Figure 8 Layered breakdown of a BP Figure 9 A four levels hierarchy of business processes: example Figure 10 UML diagrams Figure 11 Flow diagram a BP Figure 14 Organization chart: overall structure of a corporation (simplified) Figure 15 Organization chart: detail structure of a corporate unit (simplified) Figure 16 A CRASO schema of a functional process Figure 17 A CRASO schema of a cross-functional process Figure 18 Porter s Value Chain (redesigned from Porter 1986) Figure 25 Overall schema of management control sequence Figure 26 Anthony s pyramid and enterprise operations Figure 27 Phases and activities of a generic enterprise strategic planning process Figure 28 A schematic calendar of management control in a generic organization Figure 29 Grid of computerization in decision processes (redesigned from [Motta 2009]) Figure 30 Links between activity levels Figure 31 Assessment of Activity Levels of Sales BP Figure 19 Tree of aggregate BP classes in organizations Figure 20 An aggregate view of primary BP classes Figure 21 The T concept of business process in organizations Figure 22 Hierarchy of some support processes Figure 23 Steps of the Architecture Development Method of TOGAF framework Figure 24 Layers of information systems that support IT performance management Figure 30 Blumenthal s map of information systems Figure 31 Nolan s application portfolio Figure 32 SCOR levels: overview (adapted from SCOR 6.0 page 6) Figure 33 Description of a Process Element in SCOR Figure 34 SCOR Meta-model Figure 35 Selection of SCOR processes Figure 36 Customization of level 3 Make processes in the Turbo case study Figure 37 Level 3 SCOR... 53

5 Figure 38 SCOR level Figure 39 Assembly lines Figure 40 the etom grid - From 56 Figure 41 Passport Release Figure 42 Relationships between Services, Business Processes and IT Figure 43 The CIM framework (Wikipedia,) Figure 44 Nonaka s spiral(redrawn from Nonaka 1991)... 61

6 1 Introduction BUSINESS PROCESSES ARCHITECTURE This chapter intends to define the Business Architecture (BA) of an enterprise, i.e. the architecture through which an enterprise operates. BA includes several domains, as the organization structure and business process. We will concentrate on business processes. A Business Process (BP) is a sequence of activities, that are performed by a variable number of organizations, and deliver to customers an outcome, that include a set of products and / or services. This vision, that sees a BP as an end-to-end service chain, is called CRASO (Customer, Request, Activities, Service organizations, Output). Of course a BP does not run in the void, but in a given enterprise. A BA relates to other elements as the organization structure, the skills of the people who work in the enterprise, and, of course, the reward and control systems by which people rewarded and related objectives are defined and controlled. First, we illustrate the perspectives that the analyst uses to model a BP, namely structure and flow; also, we sketch out the modelling levels of BP, that range from the an aggregate view of the macro-processes down to elementary activities. Second, we illustrate the BP taxonomy, that includes primary BPs, support BPs and management BPs. Primary BPs reflect the missions of an organization (e.g. to manufacture and sell cars in an automotive company), while Support BPs cover administrative tasks. Finally, management BPs include activities by which an organization is governed. Of these BP classes we illustrate the main theoretical models and we introduce a general enterprise framework to map primary BPs. Third, we introduce some frameworks that support the analyst to map the BPs of an enterprise, namely SCOR (Supply Chain Operations Reference model) for manufacturing enterprises and GEF (General Enterprise Framework) that can be customized to any enterprise. Finally, we consider some characteristics of BPs versus (a) Business Services, (b) Information Technology Processes, and (c) Physical Processes. 2 Learning objectives 1. Definition of Business Architecture : to understand what is Business Architecture and what are their domains and reciprocal relations 2. Definition (BP): to have a clear understanding of the BP concept: a. what is a BP and which are its key conceptual elements defined by the CRASO paradigm (customer, activities, output, request, organizations) b. the conceptual relations between BP and organization structure 3. Modelling: to learn the fundamental approaches to describe a BP: Catalogue (list, indented list), Grid, Structure diagrams, Flow Diagrams 4. Taxonomy: to understand purpose, structure and flow typical of the main BP classes in organizations: support processes, primary processes, management processes 5. Mapping: to gain the ability to map processes of an organization 6. Theory: to be aware of foundations in BP theory, specifically of BP architecture 7. Industry frameworks: to understand the method and best practices in industries to map and assess the BP architecture. 3 An overview of Business Architecture The architecture of an enterprise is defined by many frameworks. Our architecture concept reflects The Open Group Architecture Framework (TOGAF) [The Open Group 2009], that is the result of best practice [Minoli 2008] and the most used second framework [Scheckmann 2005]. In TOGAF, the architecture of an enterprise includes three domains: Business, Information Systems, and Technology. Business Architecture defines the structure and flow of business processes an enterprise performs to manage and deliver its products and services and the structure of its organization; specifically it defines the approach an organization follows in doing its business Copyright 2011 [email protected] - Draft for internal use- do not quote - 6 of 65

7 (Business Model) and the way it is organized (Organizational Model). Information Systems Architecture defines the information that systems process and, also, the structure of the processes. Finally, Technology Architecture defines the building blocks and the layers on which information systems are deployed. Figure 1 offers an overview of the domains of the Enterprise Architecture, in the form of a tree. 3.1 Business model Figure 1 Domains of Enterprise Architecture Business model definition The Business Model, as Wikipedia (2012) states, describes the rationale of how an organization creates, delivers, and captures value (economic, social, or other forms of value). The process of business model construction is part of business strategy. For the sake of clarity, we underline that the analyst only describes business models but does not design them. Indeed the business model is a topic of business strategy, and, therefore, it is beyond the scope of enterprise architecture. In short, the analyst shall (a) understand the business models and (b) define their relations with other domains of Enterprise Architecture. Here below we give a brief on how the analyst can describe business models and map their main relations with other domains Business model description In order to understand business models, the analyst should describe them. Since no accepted modelling language exists for them, a description in plain English is normally the best way. So, a description of business models would be some form of narrative text. Here below we consider some simple cases. The business model of Google is an example of a pay-per-service business model. The core of Google s business is the search engine. Its business model is based on advertising, the so called ad-words [Vise 2008]. The engine displays on each word sought, e.g. hotel, two lists, that are, respectively, the most frequent searches that contain the string hotel and the adverts on the word hotel. So, the engine delivers value to two communities, i.e. web users and advertisers. The users receive free information; in turn the advertisers get in touch with millions of potential customers at the price that reflects the number of hits. Google makes profit from advertising while it gives a free and unbiased service to millions of users. Car makers are a typical manufacturing business model, where the value is primarily given by the good sold - i.e. the car. The cars are sold through a network of dealers. Typically customers walk into a dealer saloon, select the car model and optional features and make orders, that are entered into the system of the car maker. Cars are assembled to order, i.e. every car is made by assembling on a basic configuration the optional features requested by each customer. Copyright 2011 [email protected] - Draft for internal use- do not quote - 7 of 65

8 Mobile communications on smart phones are an example of collaborative business model. In many cases, telecommunications carriers sell the phone and bounded connection services. The user can use also optional apps, that are paid per service. Apps can be supplied by anybody. So the user receives a generic value given by voice and SMS and specific values given by the apps it uses. So income comes from several sources: product (smart phone) and services, that include connection and apps. A given business model may include a wide variety of elements. We here consider only the elements that are relevant for the business architecture. These include the outcomes in terms of products and services, the relations with partners, suppliers and customers. An overall diagram of the domains of a business model is in Figure 2. Figure 2 Elements of business models A business model includes a certain set of services and products. Since a corporation may have a wide variety of services and product sets, you may have multiple business model in the same corporation. For instance, Google sells software, with a business model that is different from that of the search engine. In turn, car makers sell spare parts for their own cars by a specific business model. A business models is related to elements of other domains. E.g. the business model of the Google uses a certain configuration of ICT (Information & Communications Technology) and a certain organization formula, that in turn can be detailed in terms of business processes, skills, reward and control system etc. These relations may be expressed by a double entry table, where applicable relations are described in plain English, or by ad hoc diagrams, as the notorious Entity Relationships diagrams, or by an abstract language. Table 1 displays a summarized description of these relations. The column Organization Model evokes the pattern that is typical to the business models; more detail can be found by entering each definition e.g. Multidivisional Form in a search engine. The column Information Systems quotes the overall classes of systems that support the business; in some cases, as Google, ITC is also a production technology (indeed the web based search engine is the capstone of Google outcome. In this case too, more detail can be obtained by entering a description e.g. CIM in a search engine. Finally, the Technology columns lists the technology used for systems that handle information flows i.e. the true information systems e.g. ERP- and physical flows i.e. production technology e.g. CIM. Business Organization Information Systems Technology Copyright 2011 [email protected] - Draft for internal use- do not quote - 8 of 65

9 Model Model BUSINESS PROCESSES ARCHITECTURE Google (Search engine) Hybrid Organizations (H- Form) Business Intelligence (it gathers data on hits by customer and therefore it prices adverts) Parallel computing & proprietary web based search engine Car Maker Multidivisional Form (Central Staff + Divisions) ERP (Enterprise Resource Planning) that processes business transactions CIM (Computer Integrated Manufacturing) that assists physical operations Classic ITC (server and fixed and mobile client) + ad hoc ITC for CIM Mobile Communications Multidivisional Form (Central Staff + Divisions) BSS (Business Support Systems) for customer transactions; OSS (Operations Support Systems) for service delivery & assurance Phone technology Classic ITC for BSS and OSS Table 1 Relations of business model with other domains of enterprise architecture 3.2 Organization model Organization model definition Figure 3 Galbraith s star model for organization design (redrawn) According to Wikipedia (2012) an organization is a social entity that has a collective goal and is linked to an external environment. An organizational model defines how to describe an organization. Organizational models are numberless. The organizational model of our interest focuses on organization architecture, i.e. focuses on the domains the analyst should consider when designing a new organization or undertaking a project on an existing one. Our organizational model is based Galbraith s Star Model [Galbraith 2007], that includes five main domains, as shown in Figure 3. The segments that connect each domain intend to suggest that each domain can influence any other domain, and, therefore, an effective design shall balance all the five domains. Copyright 2011 [email protected] - Draft for internal use- do not quote - 9 of 65

10 3.2.2 Organization model description In Table 2 we summarize the profile of each domain of the organizational model and the way it is modelled. The description column tells what is the role of the element. i.e. what is for, and informally sketches out what the typical enterprise architect will do. The third column pinpoints the language by which the element can be described. The organizational domains are modelled mainly informally, by a narrative description. However, business processes can be modelled by a variety of graphical languages, as UML, BPMN, EPC, IDEF and many other ones. Also, the macrostructure can be described by organization charts. Strategy Structure Process Element People (Skills) Reward Overall Macrostructure Microstructure Description It drives the overall course of an organization. It decides markets, products, technology, business models and key elements of organization, e.g. the organization form. It is not part of organization design, and it is where the designer should start. The architect shall map strategy implications on the domains of the organization architecture. Structure defines the location of decision making, and, also, the division of work. Organization structure classically includes two levels, macrostructure and microstructure. Macrostructure defines the overall organization form of an enterprise, and is often displayed in public reports and is described by organization charts. Changes in macrostructure are normally out of scope (while they are typical of strategic projects). Microstructure defines the jobs and the division of work in employees and blue collars; changes in microstructure are often a goal of architecture projects It defines the way an organization executes tasks and is the very core of any enterprise architecture project. While the structure of an organization states who is in power of what, the flow of processes defines how an organization runs. The design or redesign of business processes is and should be a key goal of enterprise architecture projects and is the core competence of an enterprise architect. It defines the profile in terms of skills and knowledge of the organization employees. The professional profile should be consistent not only with other elements of the business architecture but also with the architecture of information systems and the key feature of technology. It defines the reward of the employees, and therefore drives their actual performance. It defines also the systems by which performance is planned, monitored and controlled. The reward system should be consistent with the organization strategy and the performance control system should be feasible within the information system architecture. Table 2 Domains of Organizational Model Modelling language Narrative text Organization Chart Narrative text and ad hoc diagrams Standard graphical languages Narrative text or ad hoc models Narrative text or ad hoc models Enterprise projects imply some degree of change/innovation into the three architecture domains, namely business, information systems and technology. In general the more domains are changed, the more innovative is the project. Projects that are highly innovative in information systems and technology, often imply also a substantial change in organization model. Lombardy Region (Italy) launched SISS project on healthcare ( Healthcare is funded by the Government, that controls a network of hospitals, labs and family doctors. Family doctors are the frontend of the citizen; they visit the citizen, give them prescriptions, and authorize tests, cares and operations. Labs and hospitals, that are in competition, deliver healthcare services and are paid by Government on a given pricelist. Of course, every lab and hospital has its own system. The objective of the project is to integrate all this diverse and scattered information in one Patient Record and, at same time, to assure total privacy to the individual patient. To get this twofold result a complex Service Oriented Architecture has been developed. Such innovation in the domains of Technology and Information Systems also requires a new organizational model, as well the organizational model and the strategy would imply a new Technology and a new Information System. Table 3 roughly describes the profile of SISS and pinpoints the main innovations within each organizational domain. The innovation is low on the Copyright 2011 [email protected] - Draft for internal use- do not quote - 10 of 65

11 structure where each actor continues to play the same role but is high in the skills and the behaviour of the people involved. Strategy Element Degree of innovation High Description of innovation The innovation comes from a strategic statement as Universal health care service: citizens have the ability of booking health services and know their health information wherever it is generated and stored Unchanged structure with three main levels: Structure Macrostructure Almost nul Region that funds and controls health services, Family doctors that authorize services and cares, Hospitals and labs that deliver services Microstructure Low Minor changes Process People (Skills) Reward High High High Totally new computer supported process with a sanity card for each citizen and family doctors that authorize on line on computer Education of citizen to the use of their patient record (web system designed for citizens with help and avatars). Education of family doctors to the new process New framework where: family doctors are responsible of the health of their patient; the lower the expenditure the higher the reward to doctors; business intelligence software controls the service level and the quality of service Table 3 Organizational innovation in a health care system 4 Business process definition As we have stated in the previous section, Business Process (BP) is a capital element of business architecture. Indeed it defines how an organization works and produces its products and services. Of course, the first step is to define what a BP is. Specifically, we here define a paradigm for the BP, i.e. the set of elements that describe a BP. For the sake of an intuitive approach, we use examples. Purchasing a book on the web is a good example of BP. It includes several activities performed by different actors in different places, all with the common goal of delivering the books. Let us consider this BP in more detail and list its activities, with some obvious simplifications: The customer surfs the web site and selects books; at the end of selection, the customer buys the books and submits credit information; credit is authorized by a credit card company and the order is confirmed by . The customer order is split in picking orders, each of which specifies where to pick each book. Picking orders are forwarded to partner bookshops. Books are picked, grouped and packed. A courier receives shipping orders, loads the books in the appropriate warehouse and delivers them to the customer. During the execution of the customer s order, events are recorded on a database, that at any moment the customer can look at. Of course there are almost numberless definitions for BP. According to Wikipedia (2012) a business process is a collection of interrelated tasks, which accomplish a particular goal. The Wiki definition, even if nice, neglects the interaction between BP actors, and, also, that a process typically serves a request issued by a customer, as it happens in our example. In order to give a more comprehensive definition, we assume that a BP is a sequence of activities that are performed by one or more organizations to produce a result (or, equivalently, an output or outcome) for customers. Schematically, we can define a BP as: Definition 1 BP = (C, R, A, S, O) where: C = Customer = a process serves at least a customer which receives the result in response to his or her request; Copyright 2011 [email protected] - Draft for internal use- do not quote - 11 of 65

12 BUSINESS PROCESSES ARCHITECTURE R = Request = a process is started by at least one request issued by a customer; A = Activities = a process includes a sequence of activities (i.e. a series of activities connected each other) that are performed by one or more organizations; S = Organizations = organizations group the actors which are involved in the process because they perform one or more activities; O= Outcome = it is made of the results delivered to the customer; it may be material and/or immaterial and it can consist of products and/or services; generally, a BP may have multiple outcomes, that we classify into different types, namely (a) primary outputs, that are essential to the existence of a BP (in the Amazon case study, book delivery is a primary output) and (b) complementary outputs, that integrate primary outputs and / or are for (i) actors or (ii) stakeholders, which are external to the process. Information Book request Track Order Order Books Control Credit Pick Books Deliver Books Book delivery Frontend Credit Organization Bookshop Courier Figure 4 A CRASO schema of an e-commerce sell and delivery BP Figure 4 sketches a CRASO schema of a BP. On the top of the figure is the Customer, who issues the request and receives the output of the process. The request is processed within a sequence of activities A1, A2,.., An that are performed by the organizations S1, S2,, Sm. The Amazon case easily fits the CRASO schema, as we show in Table 4. Customer Request Activities Organizations involved Outcome Consumer Request of Select products (customer selects books) Front end (Product Delivery of books books Order (customer buys books and submits credit information; credit is authorized and selection, Ordering, Tracking ) + Information on the BP order is confirmed by mail) Courier (Delivery) Pick (books are picked and packed) Bookshops (Picking and Deliver (books are delivered to the customer) packing) Track (information on delivery is recorded and made available to the customer) Credit organization (payment) Table 4 The CRASO schema of an e-commerce sell and delivery BP The primary outcome of the Amazon process is the delivery of books, that fulfils the customer s request. However, the process has a set of complementary outcomes that are separated from the execution workflow. A typical outcome is the information on the request, that tracks its fulfilment. Copyright 2011 [email protected] - Draft for internal use- do not quote - 12 of 65

13 As Figure 4 suggests the customer can obtain tracking information at any time, during and/or after the execution of the BP. In some cases, based on this tracking information, the customer could intervene on the process, by changing the flow or modifying rules e.g. he can suspend or cancel an order because the delivery is too late. Therefore, a well-designed BP provides information to the customer on the status and/or outcome. Here below we list some cases of BP with their respective primary and complementary outcomes (Table 5). BP Activities Primary Outcome Complementary outcome Visit the patient Interpreted Information on the Book medical exam referral agenda of Execute medical exam laboratories Deliver referral to the patient Interpret referral Forecast tourist requests Travel and Information on Plan transportation and resort Stay resorts services Booking Information on Advertise on internet & other transports channels Hotel and/ or Resort Acquire and fulfil customer s Voucher requests Customer bills Monitor service level to Customer customers reservations Control results against plan Manage information for tourists Health Care / Lab test Vacation (activities performed by Tour Operators) Table 5 Primary and complementary outcomes 5 Business process description CUSTOMER Internal customer External customer Implicit request Explicit request REQUEST BP FLOW/ STRUCTURE Information output Physical output Composite output OUTPUT ACTIVITY Information processing activity Physical activity Composite activity ORGANIZATION Figure 5 CRASO meta-model: CRASO elements and related associations The CRASO diagram gives an intuitive description of a BP, that, however, cannot be considered as complete. Let us consider the elements needed to describe a BP. Figure 5 shows the elements involved in CRASO concept and their reciprocal associations. Specifically, a BP is a flow of Copyright 2011 [email protected] - Draft for internal use- do not quote - 13 of 65

14 activities that may be associated to multiple customers (and vice versa) and activities (and vice versa). Also a many to many relation of a BP occurs with the output/outcome and request types, since the same request or output/outcome may be associated to many BP and vice versa. Finally, a same organization, e.g. a department of a corporation, may be associated to multiple activities and vice versa. Generally, all CRASO elements have a many to many relation. A BP may be described by different notations. The simplest one contains only one element, i.e. is a list or catalogue, that enumerates the activities a BP is made of. In Table 6 shows a list of the activities of our BP example. Activities 1. Order (customer selects books) 2. Pay (customer buys books and submits credit information; credit is authorized and order is confirmed by mail) 3. Pick (books are picked and packed) 4. Deliver (books are delivered to the customer) 5. Track (information on delivery is recorded and made available to the customer) Table 6 Catalogue of BP activities (example on e-commerce sell and delivery BP) A richer notation is a table, that relates two vectors. A typical example in BP modelling is the table of activities and structures. The example in Table 7 represents the role of organizations in BP activities. The filled cells indicates that a given organization is involved (i.e. is related with) in a given activity. The relation label describes the nature of the relation trough labels, as I for Being Informed, E for Execute, A for Assist / Cooperate. Activities Organizations Customer Front-end Bookshop Courier 1. Order E E 2. Pay E I 3. Pick E A 4. Deliver I E 5. Track and monitor I/E I/E Table 7 A table notation of a BP (example on e-commerce sell and delivery BP) A richer notation are diagrams, that can represent and relate a higher number of elements. Of course, there is a multitude of diagram categories. For the sake of simplicity, we here consider only two diagram models: (a) the hierarchical diagram, that models the structure of a BP, and (b) the flow diagram, that models the dynamics of a BP. Both hierarchical and flow diagrams are included in standard modelling languages. UML (Unified Modelling Language), probably the most popular modelling language, can represent BP flows by Activity Diagrams. However, UML is oriented to software engineering more than to business processes (Fowler 2003). To specifically cover BP modelling, Penker & Eriksson developed a popular UML extension for BP, and added a set of stereotypes and diagrams useful to represent both hierarchy and flow of a BP (2000). Recently born and increasingly popular, BPMN (Business Process Management Notation) is a complete notation specifically conceived for BP modelling. The BPMN 2.0 version, issued in 2011, included in OMG, is published on the website Explanatory texts on BPMN, sometimes not yet completely aligned to BPMN 2.0, are numerous [Allweyer 2009, Debevoise et al. 2008, Grosskopf 2009, Ryan 2009, White 2008]. BPMN not only provides an user oriented notation, but enables model to model transformations, where BPMN is transformed in an executable language, named BPEL (Business Process Executive Language), whose specifications are published on the website In Table 8 we show the relative coverage of Hierarchical Diagram, Flow Diagram, and BPMN, and, also, we give an overall idea of their relative richness. In the subsequent sections we illustrate hierarchical and flow diagrams in more detail. TYPE HIERARCHY FLOW BPMN Flow/ structure Structure (specialization & decomposition) Flow (sequence & condition) Flow (sequence & condition) Request Yes (input message) Yes Output Yes Yes Activity Yes Yes Yes Organization Yes Yes Copyright 2011 [email protected] - Draft for internal use- do not quote - 14 of 65

15 TYPE HIERARCHY FLOW BPMN Customer Yes Table 8 How diagrams map BP elements. 5.1 The hierarchical model In the hierarchical diagram, a BP is represented as a tree. Hierarchical diagrams, since they show the structure of a process, are also called structure diagram. A generic example is in Figure 6. The diagram breaks down an aggregate BP into its first level components, and these in smaller ones, and so on until the desired level of detail has been reached. Bold bottom-up lines indicate specialization, i.e. a subtype of the hierarchically upper activity, while top-down slim arrows indicate composition, i.e. the upper type is made of the subtypes. In a complete and detailed analysis, the lowest level elements are elementary activities. Let us shortly comment some key characteristics of the hierarchical model. Figure 6 Hierarchical diagram of an e-commerce sales and delivery BP Decomposition versus specialization The hierarchical model is based on a twofold hierarchy, i.e. that is obtained by decomposition or specialization. Decomposition is the relation that occurs between a part and its whole (PART-OF): e.g. a car is made of an engine and a body, and, in our example, the aggregate activity picking includes a set of detail activities, i.e. plan, pick, pack. Specialization (IS-A) is the relation that occurs between a type and its super-type. E.g. a car may be two or four wheel drive or a payment may be made, as in our example, either by credit card or money order Hierarchy levels In a hierarchical diagram, a BP is broken down level by level. So, the diagram at level 1 shows the overall process and its immediate components. Specifically, the BP e-commerce sell & deliver is broken in its immediate components; in this case, all are all components are in a PART-OF relation as in Figure 7. At his point the decomposition proceeds until elementary components are identified. Level 2 diagrams shall have as many diagrams as the immediate components of Level 1. Level 3 shall have as many diagrams as the immediate components of Level 2, and so on. This roadmap Copyright 2011 [email protected] - Draft for internal use- do not quote - 15 of 65

16 produces a hierarchy of diagrams, as in Figure 8. Specifically, level 1 diagrams lists immediate components of the BP, that in turn will be detailed by level 2 diagrams. In our case, level 2 diagrams, with exception of the 2.2. Diagram Pay, identify elementary activities and are not further broken down. One component of the 2.2. Diagram Pay is further detailed on a lower level, specifically, 3.3 Diagram Execute payment, that contains elementary activities. This layered description is easier to make, and produces less crowded diagrams; however, the reader loses the global view; so, in order to see at once all elementary activities of a given BP, he has to browse all final diagrams - sometimes a high number. All in all, layered breakdown is prevailing in all complex BP. Sell & deliver Order Pay Pick Deliver Track Figure 7 Level 1 breakdown of a BP. Level 1 Diagram 1. Sell & deliver Level 2 diagram 2.1 Order Level 2 diagram 2.2 Pay Level 2 diagram 2.3 Pick Level 2 Diagram 2.4 Deliver Level 2 Diagram 2.5 Track Level 3 diagram 3.2 Execute payment Figure 8 Layered breakdown of a BP The hierarchy taxonomy of business processes In management culture, business processes are usually classified into series of aggregation levels. This classification, that goes from the highest aggregation process down to the finest detail, is only practical, and has no formal foundation. We list an example here below: Macro process (e.g. Human Resources): a first level that includes very aggregated processes, generally no more than 20 or 30 in a whole enterprise; Process: an aggregated level that may be either a specialization of level 1 (i.e. Executives, Employees) or a part of it (Management, Administration etc.); Copyright 2011 [email protected] - Draft for internal use- do not quote - 16 of 65

17 Sub-process / Phase: a part of a process (e.g. Management could be decomposed in Hiring/Selection, Development, Education & Training); Activity: a well identified action in a phase (e.g. Hiring and Selection can be further decomposed in Prepare interviews, Interview candidates, Screen candidates). A graphical view of such hierarchy, that illustrates a BP on human resources, is here below (Figure 9). The macro-process Human Resources is broken down in processes that reflect a division of the macro-process according to some paradigm. Processes are then split in phases, each one represents a self-contained step of the process. Finally, phase is split into activities. Activities usually represent tasks needed to accomplish the objective of the sub process. In our case, the output of Hiring & Selection are, intuitively, candidate selected; the activities listed in the figure reflect these tasks. Of course, activities may be not granular and should be further subdivided in order to identify elementary activities as described in the subsequent section. Macro-process Human Resources Process.. Human Resources Management.. Sub-Process / Phase.. Hiring & Selection.. Activity Prepare Interviews Interview Candidates Screen Candidates Figure 9 A four levels hierarchy of business processes: example Elementary activities In general we assume that lowest BP elements are elementary activities. Elementary activities are activities that cannot be further divided, i.e. they are atomic. However, how can we define when an activity is elementary? Certainly, a formal definition would be ideal, but, given the organizational and somewhat fuzzy nature of the BP concept, we have to rely on a qualitative definition. In general terms, an elementary activity: 1. is performed by one actor (department or individual); 2. follows the same rules; 3. has the same time frequency and / or is triggered by the same class of events; 4. uses the same technology; 5. is performed in the same location; 6. produces some form of identifiable output. Let us consider the picking activity of our previous example (Figure 6). Now, picking may be performed by a human being or by a computerized elevator. Therefore, picking is specialized into two elementary activities, that differ because of their respective technology and actor (Table 9). Pick books manually Pick books by elevator Actor A worker A computerized elevator (machine) Copyright 2011 [email protected] - Draft for internal use- do not quote - 17 of 65

18 Frequency On demand On demand Rules used FIFO (= pick the material that arrived FIFO (= pick the material that arrived first, with a first in first out policy) first, with a first in first out policy) Outcome produced Picked parts Picked parts Technology used Labour + computerized information Computer Integrated Manufacturing Table 9 Characteristics of elementary activities: example In Table 10 we illustrate a detailed analysis of the elementary activity materials picking in a warehouse. Property Example Comment 1. One actor A worker picks the material If picking was made either by a human being or by a automatic warehouse elementary activities would be at last two. 2. One rule The worker follows always the same rule and steps: search the item, pick the quantity assigned, carry the item picked on the assigned location, report errors 3. One frequency / one event Picking is on demand and is triggered by a picking request 4. One technology The technology combines physical operations made by a human being and computerized support The activity would be different and not elementary if it uses different rules If picking is batch and triggered by periodical deadlines (e.g. at the end of the day) it is a different activity A different activity would be an entirely manual picking with a subsequent batch record of operations 5. One location Picking always happens in a warehouse Picking in a shop is a different activity 6. One output The output is the material picked The sole step pick the quantity assigned has no real output Table 10 Properties of elementary activities (materials picking in a warehouse) An elementary activity may include sub-elementary steps, generally called task, that specify what the activity is made of. Tasks may be (a) actions performed by human beings, as the individual steps of manual picking, or (b) machine actions as the individual actions of elevators and computers in the automatic picking in our example. 5.2 The flow model Flow models The hierarchical model is useful to identify elementary activities, thanks to its very simple operations. However, to show BP dynamics a richer semantic is needed. From many decades, the flow diagram is the most popular model. Flow were born one hundred years ago, and became almost universally used in the early years of computers, namely around 1960, to define business procedures and related flow of computer processing. Currently, a flow can be designed by a wide and diverse family of notations. All represent a sequence of activities, but differ in their extension, i.e. details on flow (branch, merge etc.), events, input and output and other elements. The most popular flow diagrams are Activity Diagrams [Fowler 2003], one of the many models included in UML. By far the most popular modelling language, UML 2.2 includes 14 types of diagrams divided into two categories [Wiki, UML, as of July 5th, 2011]. Seven diagram types represent structural views, while the other seven ones represent general types of behaviour, including four that represent different aspects of interaction. The wide upward arrow indicates that the type below (i.e. a given diagram type) is a specializations of the super type above: e.g. the sequence diagram is a specialization of the interaction diagram. Flow diagrams, with different notations, are included in many graphical models, as IDEF0 [ BPMN [ EPC [Scheer 1999, 2002; Copyright 2011 [email protected] - Draft for internal use- do not quote - 18 of 65

19 Figure 10 UML diagrams The flow model adopted For our purposes, we use a notation, that includes flow alternatives, but, for the sake of simplicity, excludes initial inputs and final outputs; in short, it contains the following elements: 1. Activities, represented by a circle 2. Execution flow, represented by a solid line 3. Control flow, i.e. information that links activities executed by different organizations 4. Lane, represented by a box, that specifies the actor of a given activity sequence 5. Alternative, represented by a diamond, that indicates where the flow branches 6. Start and end of activities, indicated, respectively, by a blank and full circle In our approach, the flow diagram is the arrival point of an analysis. The analyst can break the BP top down. Hence, we will start with an overall diagram that represents the whole BP with aggregate activities. Aggregate activities will be broken down by a hierarchical diagram. Let us now consider our case study e-commerce sell & deliver. The corresponding flow (Figure 11) includes the elementary activities that have been identified in the parent hierarchical diagram. The flow is divided in lanes, each containing the activities performed by a given actor of the BP. It is evident that flow model is richer that the hierarchical one. In our case study, it adds many details, e.g. alternative paths of activities, links between organizations etc. Copyright 2011 [email protected] - Draft for internal use- do not quote - 19 of 65

20 Log Browse catalogue Fill order 1 Enter payment Pay by credit card Pay by money order Forward order Plan picking Pick manually Pick by elevator Pack books Load boooks Transport books Deliver books 1 1 Monitor status Report to customer Report to manager Figure 11 Flow diagram a BP. 6 Business process and organization structure A BP may cross multiple organizations, and, in turn, an organization may be involved in multiple processes. We here consider the organization element as much as it is related to the CRASO definition; general foundations on the organization concepts are illustrated by many texts on organization theory (e.g. Daft 2009). Organizations may be described from a static or dynamic perspective. We here consider the organization structure, that reflects the static aspect of an organization. This is described by the Organization Chart, that may be integrated by an Organization Manual 6.1 Organization Chart The organization structure describes the static aspect of an organization. A typical structure description is the organization chart. The example in Figure 12 gives an overview of the organization structure of a large fictitious company that is in the business of elevators, similar to Otis or Kone. This company is in a twofold business. On one side it produces elevators for new buildings, on the specs of a main construction contractor. On the other side, it maintains installed elevators. This latter business requires regional branches, where maintenance technicians and repair engineers provide service operations in a short time to local installations. Let us consider the structure chart of a large elevator company. The chart defines the responsibility of each organization unit. For instance, the President has the authority to decide the objectives of all Vice Presidents (VP). At a lower level, each VP plans and controls the objectives of organizational units that report to him or her. E.g. The VP of Sales plans and controls operations of the Regions that report to him, and each Region in turn plans and controls the actions of the operations and branches that report to the Region. Let us go to detail. To the Chairman report both some staff offices, which interact with the outside environment (Legal, Audit, Corporate Relations), and the President, who is the operational head of Copyright 2011 [email protected] - Draft for internal use- do not quote - 20 of 65

21 the company, and is also indicated as Chief Executive Officer (CEO). To the President report the heads of the first tier units, called Vice President (VP). These, in our case, include the VPs for Human Resources, Finance (also called Controller or Chief Financial Officer, CFO), IT (also called Chief Information Officer, CIO), Research & Development (this unit groups the engineers who design elevators), Production (it includes plant where elevators are manufactured), Purchasing (that buys parts and services), and, finally, Sales (that sells new elevators and services installed elevators). Each first tier unit is further divided in smaller units, and the breakdown may include up to 5 levels, depending on the size and complexity of the units. Figure 12 Organization chart: overall structure of a corporation (simplified). Figure 13 Organization chart: detail structure of a corporate unit (simplified). Copyright 2011 [email protected] - Draft for internal use- do not quote - 21 of 65

22 The breakdown of the Sales division is shown by the following Figure 13. Sales Division is divided in Regions, each in charge of a given geographical area of United States (e.g. New York City, East Coast, etc.). Each Region, in turn, includes support staff (Regional Accounting, Sales Support), a group of technicians and engineers which are in charge of installing, maintaining and repairing elevators, and, finally, a number of local branches, with a small team of salesmen, in charge, respectively, of selling installations or service to installed elevators. Assuming that to each region report an average of 8 branches, the total number of branches is around 50. The layering of the structure enables management to control an affordable number of units. A geographical a network of almost identical units geographically distributed, similar to the one we have exemplified, is typical to all operations where a geographical distribution or delivery are needed, as it happens with Banks, Post Office, Hotels, Food and Retail, Fashion Industry (with licensed shops), Logistics (with network of collection, dispatching and delivery centres) etc. A geographical network is required to manufacture or develop high technology products, as airplanes, software or automobiles. 6.2 Organization Manual Of course, an organization chart cannot describe everything. Therefore, a chart is often integrated by text comments, that state objectives, tasks, responsibility, authority of each organizational unit. Objectives define what the organizational unit (and its manager) should obtain. Tasks are the activities the unit should perform and ideally coincide with the activities of the business processes the unit is involved in. Responsibility is given by the results the unit is accountable for; e.g. a factory is responsible for the quality of products. Authority are the areas where the unit can decide. E.g. a factory manager is responsible for the quality but has no authority to decide on quality standards. The set of these descriptions make an organizational manual, that are also partially incorporated in ISO 9000 quality requirements. 6.3 Organization structure versus Business Processes As we have stated before, a many to many relation occurs between business processes and organizations. More specifically, a CRASO flow of a business process (BP) may be either segregated within the boundaries of an individual organization unit (it seldom happens) or cross multiple units of the same organization or, finally, multiple organizations. These three classes of BP are called, respectively, functional, cross-functional, cross-organizational. Let us consider their characteristics Functional BP In a functional BP, activities are performed by one department. This happens in many support processes. For instance, management reporting involves the Finance department, that collects, processes and delivers information to other departments. The departments that receive information are internal customers, while the Finance department is the only one supplier organization involved in the process. In turn, a supermarket is an example of functional BP with external customers. For, the request is made (implicitly) by the customer who picks and pays the merchandise. The same happens with a variety of front end interactions, such as operations on bank checking accounts and information requests. Functional services may be delivered on demand (e.g. supermarket shopping happens when customers enter supermarkets) or on schedule (e.g. corporate reports are issued on deadlines). Functional processes are typically well structured and, therefore, easy to design. Copyright 2011 [email protected] - Draft for internal use- do not quote - 22 of 65

23 Corporate Dpts BUSINESS PROCESSES ARCHITECTURE Finance Dpt Gather data Publish report Request Report Analyze data Cross-functional BP Figure 14 A CRASO schema of a functional process Corporate Dpts Production Planning Materials Mngt Plant Production request Gather data Expedite Produ -ction delive ry Execute Figure 15 A CRASO schema of a cross-functional process In cross-functional processes, BP actors belong to different departments of the same organization. E.g. production planning in a manufacturing organization involves Sales department, that issues planning request, Production Planning department, that assembles the plan, Materials Management department, that provides information on materials available and on supply orders, and the Factory, Copyright 2011 [email protected] - Draft for internal use- do not quote - 23 of 65

24 that executes the plan. Cross-functional processes may be complex and involve a considerable set of political and organizational issues Cross-organizational BP In cross-organizational processes, the departments that perform the process belong to different organizations. The customer, of course, is external. This is the case of many e-commerce operations: e.g. Amazon collects orders of books from customers but the activities of picking them are performed by bookshops and, finally, delivery operations are run by a courier. Also e-government and healthcare are based on cross-organizational processes. In healthcare, a check-up involves the family doctor, who prescribes the check-up, the lab which performs it, the healthcare authority which monitors the process, etc. In cross-organizational processes, the CRASO schema helps the designer to start with an end to end view of the process and to avoid the pitfalls of an island biased design (see Figure 4). 7 The BP map in organizations This section discusses the BP map of organizations. We call map the chart of the BP of an organization. Maps are described by a catalogue (i.e. a structured list of BP), a table (e.g. grids that cross BP and organization structure) or a series of diagrams. Mapping is the procedure by which the BP map of an organization is modelled. BP mapping techniques provide model the BP map of an organization and state the steps needed. For BP mapping, several frameworks have been developed, that reflect the different perspectives by which BP are classified and segmented. A first perspective views the enterprise as a transformation cycle as Porter s Value Chain [Porter 85]. Another perspective targets the management system, as Anthony s Triangle [Anthony 1965] or focuses the decisional content, as Gorry & Scott-Morton [Gorry 1971] and Simon [Simon]. A third group of frameworks pursue a practical purpose, namely to provide a reference BP architecture for a specific sector, as SCOR for the Supply Chain of manufacturing industries or etom for telecommunications.. We here illustrate: Porter s Value Chain, because it is the most classic and quoted framework; The management perspective, represented by Anthony s pryramid An overall enterprise framework, that we have developed from a set of management theories on Business Processes and Enterprise Information Systems. 7.1 Porter s Value Chain Tough cannot be considered a true BP mapping model, we start to consider the hyper classic Value Chain. In the heydays of management, Michael Porter defined the Value Chain concept, one of the most popular management framework of every time [Porter 85]. Value is the value of the product of the organizations, and it is measured by the price that a customer is willing to pay. Chain recalls that the value in an industrial organization is produced by the chain of activities by which the product is made. According to Porter, the value produced by an industrial organization is given by the sum of the values of the transformation cycle (= inbound+ production+ distribution) + the customer management cycle (= marketing + sales + after sales service). The two cycles make the value chain and are called primary activities. Higher value in primary activities generate higher value to the customer. E.g. the value of a top class Mercedes is higher, because the values of material used, inbound quality control, production, customized sales and, last not least, after sale customer care are higher. However, an organization does not perform only primary activities, but also activities that reflect legal obligations e.g. legal balance sheet or provide resources to the primary activities e.g. plant maintenance or human resource management. These activities, called support activities, add costs, tough they are needed as much as primary activities are. The original Porter s value chain is shown in Figure 16 as an arrow, with primary activities in a sequence of vertical boxes and support activities in horizontal layers, to mean that support activities Copyright 2011 [email protected] - Draft for internal use- do not quote - 24 of 65

25 Inbound Logistics Operations Outbound Logistics Marketing & Sales Service BUSINESS PROCESSES ARCHITECTURE cross all primary activities, and finally, with the margin area at the end of the arrow. Let us describe the value chain in more detail. Firm Infrastructure Human Resource Management Technology Development Procurement Margin Margin Figure 16 Porter s Value Chain (redesigned from Porter 1986) Within primary activities (below) Inbound Logistics include the activities by which raw materials are acquired, controlled and readied for Operations. Operations include all transformation activities through which raw materials are transformed into products. Outbound Logistics include all the activities by which products are stored, dispatched and delivered to the customer. Sales & Marketing include the activities of promoting products, contacting customers and selling products. Service include operations after sales, as repair, maintenance, customer care and alike activities. Support activities, include (a) firm infrastructure, that serves overall needs of a corporation as an organization, and includes accounting, legal staff, planning, public affairs, government relations, etc., (b) technological development to support all primary activities (e.g. manufacturing technology used in the factory), (c) procurement, that encompasses the acquisition of inputs, or resources, for the corporation, (d) human resource management. The taxonomy of support activities is much less intuitive than the on of primary activities, and, therefore, is much less popular. The margin (= profit) of a supply chain is given by the price paid by the customer minus costs of primary and support activities. While that higher costs primary activities may eventually generate higher value (e.g. a higher quality raw material will raise the perceived value of a product), higher costs in support activities (e.g., higher costs in administration) will not raise value to customer and, therefore, subtract margin1. In our perspective, Porter is important because he introduces the distinction between primary and support activities. Thanks to his popularity, the Value Chain concept is worldwide familiar to managers. However, his framework is not suitable to define a BP map, because: The framework is not particular and not universal: the primary activities reflect the sole case of industrial organizations and hardly, if ever, can apply to service and government organizations; The taxonomy of support activities is unpractical, since it does not reflect the classifications used in business; 1 Porter s value chain has been extended. An example is the Value Reference Model (VRM) developed by the trade consortium Value Chain Group. VRM should enable value modelling of all business processes and provide best practices for each of the six business functions in which the original value chain is divided: Research and Development, Design of Products, Services, or Processes, Production, Marketing & Sales, Distribution, Customer Service. Another example is SCOR, that uses a slightly different taxonomy, and, also, provides a reference framework of best practices. VRM and SCOR reference can easily found by any Internet search engine. Copyright 2011 [email protected] - Draft for internal use- do not quote - 25 of 65

26 BUSINESS PROCESSES ARCHITECTURE Finally, Porter does not model management activities, that are a key in the organizational life. 7.2 The management perspective We here illustrate the classic frameworks on management processes. These frameworks were born long time ago, when management theory came of age. From 1960 to 1980 management theory matured and developed sound frameworks on management systems, as the ones ] on decisionmaking by Anthony [Anthony 1965] and Gorry and Scott-Morton [Gorry Finally, in the1990s, the theory on strategic control produced the hyper popular Balanced Score Card (BSC) by Kaplan and Norton [Kaplan 1992, 1993,1996, 2001, 2004, 2008]. Before considering the taxonomy of management process, it is important to make clear what a management process is. Essentially, management processes are nothing else but an organizational form of a control feedback, i.e. a signal that is looped back to control a system. CONTROL Define (define objectives) Appraise (monitor performances; review & analyze results) Adjust (plan adjustments; execute adjustments) EXECUTION Interaction between control and execution flow (information or commands) Activity sequence Figure 17 Overall schema of management control sequence Typically, control includes various phases as (a) definition of objectives, (b) appraisal, (c) adjustment. These phases are in sequence, and interact with the executive activities they control, as shown in Figure 17. Specifically, the phase of Definition of objectives states the objectives the organization expects e.g. how many cars to sell. This phase is also often called Planning, because objectives are documented by a plan. The Appraisal phase requires to monitor execution, gathers information on actual results (e.g. monitors the sales process), and analyzes results (e.g. what is the gap between planned and actual sales in terms of units and prices?). This phase is often called as Control, since it checks results against objectives. Finally the Adjust phase includes the actions by which management either adjust objectives, because they are too high or low, or intervene on executive activities (e.g. lower the prices in order to counter low sales) or both. This phase is often called also Correction since the purpose of the adjustment is to correct execution in order to catch objectives. 7.3 Management perspective and Anthony s pyramid Robert Anthony is almost unanimously considered as the founder of management control, that is the core of the large enterprise, with thousand organizational departments worldwide. Of course, computers have been a critical success factor of management control, that broke the barrier of volumes and distances, a barrier that traditionally was thought as insurmountable, as it was argued by a paper with a caustic title Management Information System is a Mirage [Dearden 1972]. Copyright 2011 [email protected] - Draft for internal use- do not quote - 26 of 65

27 In short, Anthony divides the management process of an enterprise into three layers (1) strategic planning, (2) management control, (3) operational control. Anthony gives a holistic view of the management system/ process that can be seen as a three layers pyramid superimposed on the operational flow. Strategic planning sets overall objective of the enterprise and its related strategy. Strategic objectives concern markets to enter (or exit), products to develop (or drop), financial structure to adopt (or change), etc. Strategic objectives may result from an almost totally informal process, based on thoughts and casual interactions. The strategic plan not only describes strategic objectives (e.g. be number one in telecom services) but also identifies strategic projects, i.e. the initiatives to implement objectives (e.g. the launch of a new telecom service). The strategy of a company pervades functional involves the individual departments of an organization. E.g. the launch of a new service implies related in a telecom company implies strategic initiatives in the IT department, in Marketing department etc. The generic strategic process flow in Figure 19 identifies phases, that include, objectives definition, appraisal and adjustment. Adjustments involve strategic initiatives and not the regular operations of the company, that are ruled by management control and operations control layers. STRATEGIC PLANNING MANAGEMENT CONTROL OPERATIONS CONTROL EXECUTION Figure 18 Anthony s pyramid and enterprise operations Each layer of the management process handles different variable classes strategic decisions, resource allocation decisions and execution decisions. The Execution layer has been added by us to illustrate the interaction between management and execution processes. Copyright 2011 [email protected] - Draft for internal use- do not quote - 27 of 65

28 Decide overall objectives (market share, profit, other) Scan environment (inside & outside) Define strategy (products, markets, technology) Plan strategic initiatives (time, money, deadlines) Definition of objectives Appraisal Appraise initiatives (on deadlines) Adjustment Adjust initiatives Figure 19 Phases and activities of a generic enterprise strategic planning process. The dotted lines map the activities of strategic planning in the phases of definition of objectives, appraisal, adjustment Figure 20 A schematic calendar of management control in a generic organization. Budget is decided in the Fall of the previous year, based on evidence of results and on strategic actions, goes through a discussion among managers, and it is finally approved. This is the first part of the objective definition phase in management control. After the budget is approved in December, managers analyze monthly results against the budget. This gap analysis (in the centre of the figure) is the appraisal phase of the management control layer. Based on the gap analysis, appropriate actions may be planned, which are shown by dotted lines; December and January are skipped because they are, respectively, too early and too late. These actions are the adjustment phase of management control process. During the year, objectives may be redefined, as it is shown by the Revised Budget, processed in May, and the Final Budget, issued in August. So the objective definition phase includes the two moments of initial planning (Approved Budget) and re-planning (Revised Budget and Final Budget). Management control is, logically, the layer that follows strategy planning. Once the company has decided where to go, it has to detail cost and income objectives for each organization unit. Dollar objectives may be integrated by physical indicators: e.g. the dollar amount of car sales and related margin are integrated, as a physical indicator, by the number of cars sold; these objectives are stated in budget, i.e. a dollar statement of expected costs and income of a given organization unit. Typically, budgets are developed top down: the overall enterprise budget is split into division budgets, and these, in turn, in department budgets etc., until budgets of elementary units, called Copyright 2011 [email protected] - Draft for internal use- do not quote - 28 of 65

29 cost centers, are set. Cost centers roughly reflect the organization chart of an organization, and may be over in large multinational companies. The appraisal phase is a gap analysis of actual results against budget objectives and the consequent adjustment may result in adjustment actions. A schema of the management control cycle is given by Figure 20, that shows how objective definition, appraisal and adjustment phases are interleaved during the year of a generic organization. Finally, operational control is the final layer of the control and has the purpose to control the physical execution of operations. Of course, it typically deals with quantities. A good example is the control of a factory. In the planning phase, management decide the operational objectives e.g. how many cars to produce. In the control phase, management monitor in real time the actual production and spot exceptions (e.g. a delayed supply that may alter the program). Adjustment phase is a rather continuous activity, e.g. to change the production program in order to accommodate a delayed supply. Given its proximity to operations, the logic of operations planning vary depending on the industrial sector: an automotive factory is different from an oil refinery and both have little to share with a bank branch. Therefore, operations control is typically described within the industry frameworks of business processes: e.g. manufacturing planning is described within the overall business process framework on manufacturing, as it happens with SCOR (see in this chapter). Even it looks simple, Anthony s pyramid is a very solid concept on which generations of managers were and are educated worldwide. The three control levels correspond to the three main levels of managers. Strategic planning ranges from the Chief Executive Officer to the Vice Presidents (also called Top Management ), Management Control ranges from Vice President to the middle management, e.g. the responsible of a plant or a large branch. Finally, Operations Control, ranges from middle to operational management, e.g. the manager of a shop or of a factory. Finally, Anthony profiles the overall different information needs of each management layer. Operations control uses a very high quantity of granular information. E.g. production planning of an automotive factory shall process, frequently and possibly in real time, the production plan, by matching the specs of cars to be produced, the manufacturing cycle of each car model and the production capacity. Conversely, the management control process will process a much more limited quantity of information, that will consider dollar costs and dollar value of the outputs produced by the factory, thus periodically, say monthly, assessing its overall efficiency. Finally, strategic planning not only has a very variable frequency, but also uses a wide and variable span of internal and external information. In the case of an automotive industry, it shall include research studies, surveys on process technologies and a lot of miscellaneous information. In short, the more granular and internal the information, the higher the role of computers is. INFORMATION MANAGEMENT LAYERS PROFILE OPERATIONS MANAGEMENT STRATEGIC PLANNING CONTROL CONTROL Detail Granular data Summarized data Variable Structure Predefined Predefined Variable Frequency Continuous Periodical (e.g. monthly) Variable Source Internal Mainly Internal Mainly External 7.4 The decision perspective Table 11 Information profile of management processes Anthony s pyramid defines a framework of enterprise control from the view point of decision variables, but does not analyses the decision process, i.e. the approach by which management decide a given action. The decision perspective was born in the early stages of computers with Simon [Simon1958] who conceives the organization as a system on three levels, namely (a) physical processes of production and distribution (b) operational decisions that control concern physical processes, and (c) decisions that assess outcomes of operational decisions and set their rules. Decisions can be structured or unstructured. A decision is structured when it follows a predefined schema, and with a given input produces always the same output. A structured decision can be reproduced and easily automated by software. A decision is unstructured when it is taken on a undefined schema. Copyright 2011 [email protected] - Draft for internal use- do not quote - 29 of 65

30 I nformat ion st ruct ure Low High ITC development BUSINESS PROCESSES ARCHITECTURE Gorry & Scott Morton [Gorry 1971] merge Simon s decision theory with Anthony s framework and introduce a new decision type, called semi-structured decision, where output is defined but the decision process is not defined. The result is a taxonomy on nine quadrants, that we show in Table 12. Examples are intuitive and do not require further explanation. Operations Control Management Control Strategic Planning Structured Decision Stock replenishment Budget for customer care Plant localization Semi-structured Decision Securities trading Budget for sales Project financing Unstructured Decision Selection of heading in a newspaper Selection of managers Table 12 The grid of Gorry and Scott Morton: example Research and Development strategy The grid is important, because it focuses the target area of computerization. More precisely, the target area of computerization is management processes is shown by the grid here below, that crosses information and decision structure. An information structured is made by a ordered series of elements e1,e2,, en, where each ei is defined by a previously specified format Fi. An accounting record, e.g. an invoice, is the most typical case of structured information. A decision is structured if can be described by a rule. Business operations algorithms are typical cases of structured decisions, where the decision variable D is depending on a set of independent variables I, i.e. D = f (I1, I2,, In). Decision st ruct ure Low High Limited decision computerization (e.g.: ship building) Intensive decision computerization (e.g.: inventory replenishment) Marginal to null computerization (e.g. to style a product) Marginal information computerization (e.g. to hire a manager) Figure 21 Grid of computerization in decision processes (redesigned from [Motta 2009]) The key area of computerization is, of course, the one of structured information and structured decisions, as it happens in inventory replenishment. The computerization is so intensive that no manager or human being is normally in charge of actually making this decision. Also, computers play an important role to support complex decisions, as it happens in shipyards. The ship building manager does not use one global formula to define times and materials to be procured; nevertheless uses a lot of computerized information. The weight of computer information drops when a decision is emotional. E.g. the decision of hiring a manager is largely based on reciprocal empathy and trust, while structured information on manager resumes is useful only to start the process. Finally, computers play an almost negligible role when the decision argument is a matter of creativity, as it happens when the style of a new fashion product is decided. However, the development of information technology enables to retrieve and combine a variety of information kinds (sound, images, text), and increasingly shrinks areas of unstructured and not computerized decisions, as the bottom up arrows of the figure suggests. Copyright 2011 [email protected] - Draft for internal use- do not quote - 30 of 65

31 7.5 The operational perspective: the AL (Activity Levels) model AL (Activity Levels) maps the operations of enterprises. For, we can all notice that a BP contains activities of different kind (sometimes called sub-processes or process phases), that differ in their time horizon and decisional content. Based on our experience and on wide set of management research, we identify BP activity levels. Specifically we identify 5 main activity levels [Motta 2012]. In Table 13 we exemplify the activity levels of the Vacation case. Activities Forecast tourist requests Plan transportation and resort services Advertise on internet & other channels Acquire and fulfil customer s requests Monitor service level to customers Control results against plan Manage information for tourists Comment Activities as Forecast tourist requests and Plan transportation and resort services imply decisions, while activities as Acquire and fulfil customer s requests are mere execution. Moreover, activities as Control results against plan are certainly management activities, as well as the activity (typically computerized) Monitor service level to customers that continuously gathers data on the promise to the customer in terms of price, accommodation standard and alike service parameters, and compare it against the actual service performances. Finally, tour operators spend a lot of effort to collect, store and distribute information on travels, stays and other useful information for their tourist customers. Generally the viability of the BP main outcome, i.e. travel booking, strongly depends on the quality of the whole set of activities. Table 13 Activity levels in the Vacation case study Each activity level identifies a generic outcome of a generic BP. First, a BP includes planning activities, and planning implies in turn control: this is nothing else but the classic Anthony s model on management systems [Anthony 1965]. Second, a BP includes, of course, execution activities. This is common sense; additionally, the link between planning, control, and execution is defined in SCOR [Bolstorff 2007]. Third, because of computerization, information on execution is a critical need. This implies an additional set of activities that gather and distribute information to customers and other actors, as it happens with tracking systems. These monitoring activities are also called Business Activity Monitoring (BAM), a term coined by Gartner [Gartner 2002]. Finally, the mass of information required to run a process in the current hyper computerized world implies a specific level, that we call Information Management. This level is mentioned also by SCOR, where, however, it is classified as an enabling process. In short, a BP includes five activity levels, that we describe in Table 14. Activity Level Description Planning It includes all activities needed to define a plan A plan typically links objectives and resources needed to accomplish such objectives Plans may be of different kinds; i.e. they may focus on short or medium term, and they may be oriented to operations (e.g. the schedule of factory or the time table of trains) or to financial aspects (e.g. budget) Execution It includes the tasks by which the process is performed Execution activities may concern physical and/or immaterial objects, as information Monitoring It includes activities of data collection and distribution on the on-going process; It may include real time appraisal and adjustments (as in a plant control room); tracking of a shipment is the most classic example of monitoring Control It is a periodical activity It appraises results obtained and identifies appropriate adjustment actions, as needed (e.g. analysis of actual sales against planned sales defined in a budget) Information Management It includes all the activities required to generate and maintain parameters required to run the process (e.g. product catalogue, customers data, customer statistics). Table 14 Activity Levels of a BP The activity levels are linked. Planning defines the objectives for Execution, that in turn is supervised in real time by Monitoring, that collects information on events for the Control level, that Copyright 2011 [email protected] - Draft for internal use- do not quote - 31 of 65

32 feeds back to planning. Finally, the further level of Information Management provides services to all other levels (Figure 22). Levels look similar to PDCA [23] steps, but they do refer to the daily operation of a company, and not to the Deming s continuous improvement philosophy, that rather defines a management behaviour. In the following sections we describe activity levels.. Figure 22 Links between activity levels Planning Planning can be divided according to the time period and granularity (i.e. level of detail). In general terms, planning defines, for a given period, (a) the output to be produced (b) the resources to be deployed e.g. personnel, raw material, equipment and, sometimes, money (c) the tasks that should be accomplished in order to obtain the output. Sophisticated planning activities are typical of complex organizations. In capital intensive operations with multiple resource constrains, as manufacturing plants, steel mills and refineries, ad hoc algorithms are used to balance output and resources, and, then, to optimize efficiency. In these same organizations, plans may be layered as a Chinese box, e.g. with an annual plan that is detailed by a monthly plan that in turns is broken down into a weekly plan, wherefrom a shift schedule is developed. Of course, the longer the period the more aggregate the detail. Table 15 summarizes the case of operations planning in an automotive enterprise. An automotive company is mainly an assembler, that produces a car body where engines, tyres, injection pumps, brakes etc. are mounted. Therefore, it manages a complex supply chain with some hundreds of direct suppliers, that should be coordinated, with a three layers planning of production operations: Annual planning: it defines the monthly output of cars in terms of model/version/plant and is generally refreshed quarterly. Monthly Program: it defines the weekly output of cars with the same detail of customer order (i.e. model/version/optional) and its fed by customer orders and sales forecast; the program is refreshed monthly. Weekly Planning lists the customer orders to be produced shift by shift, and generates also the delivery orders to suppliers; the plan is refreshed weekly Other operational planning activities are linked to Production Planning. Specifically, Inbound Logistics Planning defines, with alike layers, the plans for each supplier. In turn, Outbound Logistics Planning defines the plan for distributions, in terms of shipments and transporters. Table 15 Operations planning: a short case study in automotive Execution Execution activities handle physical or virtual objects. Banking and insurance transactions are execution on virtual objects. By contrast, an assembly line in a factory and materials handing in a warehouse are good examples of execution on physical objects. Depending on the nature of the objects, computerization is, in the former case, a production technology, and, in the latter, a Copyright 2011 [email protected] - Draft for internal use- do not quote - 32 of 65

33 technology of coordination. This different role also influences process modelling. With virtual objects the analyst shall model only one flow, i.e. the flow of information objects; by contrast, with physical affects, the analyst shall model intertwined flows, i.e. the physical flows of things and the information flow of transactions that record the events of the physical flow. This distinction comes clearer in the very classic example, of materials handling in the warehouse (Table 16). Warehouse executive operations typically include two series of activity, say physical activities and administrative activities. Administrative activities record location and movements of materials picking, storing and alike activities. Physical activities include physical tasks as moving and transferring materials and may be accomplished by any combination of human beings and machines. With human beings, the worker reads instructions processed by an administrative activity and performs them. With a machine, instructions are transmitted by administrative activity to the device that shall implement them e.g. an Auto Guided Vehicle. Administrative and physical activities are interdependent. A physical activity executes orders processed by an administrative activity and an administrative activity receives execution information from a physical activity. Table 16 Operations execution: physical versus administrative activities: an example Monitoring The growing computerization and the ubiquity of internet access easies monitoring information. So monitoring is becoming more and more a structural level of an operational process. Let us give some examples (Table 17). The first column identifies the industry sector, the second an execution process, at a very aggregate level (macro-process) while the third column describes the related monitoring level. The column main stakeholder shows the typical consignee of the information gathered by monitoring. Finally, the last column contains some comments about the maturity of the monitoring. The table depicts a real situation based on common experience and it has only reference purposes. Industry Execution process Monitoring level Main stakeholder E-business Order fulfilling Steps of customer order fulfilling Customer Courier Shipment Tracking the physical flow of the parcel Customer Banking Mortgage loan Tracking the file and authorizations Credit manager Government Construction permit Tracking the file throughout government Case manager offices Health care Patient caring Patient monitoring Doctor Telecommunications ADSL connection Steps of customer order fulfilling Sales representative Car factory Assembly line operation Progress of the car on the line Suppliers and Factory Fashion Supply chain management Tracking work in progress by RFID Production manager Table 17 Monitoring and tracking: examples in various industries Control Example Information collected Decision maker Monitoring Shipment tracking Events (individual action e.g. None collect, deliver etc.) Control Factory operations Actual production on a week Factory planning against plan management Action implied Information to customer Appraisal & adjustment by management Table 18 Monitoring versus operations control: examples Control implies a periodical analysis cycle, typically based on a time series of data on actual performances. Let us point out some differences between monitoring and control. Control implies appraisal and adjustment, with a decision that is typically made by management. Monitoring has the Copyright 2011 [email protected] - Draft for internal use- do not quote - 33 of 65

34 primary purpose to gather information on the current behaviour of a given process, as it happens in shipment tracking (Table 18) Information management Information management includes all the activities required to generate and maintain parameters required to run the process (e.g. product catalogue, customers data, customer statistics). This information is not generated by the process, but it is used to perform the process. Let us consider the simple case of the warehouse as described in Table 16. Picking and stocking activities are recorded un the database. Now the database shall contain some master information about the warehouse location where to pick or stock material, and also some description of the material to be handled. This information exists before and after the execution of each individual picking and storing activity. Thus some activity should exist to create, update and delete such information. We call this information as master information. This is precisely the scope of information management activities. Information management is an important activity across organizations and business processes. Most organizations have large data bases that store information that is typical to the industry sector in to which the organization belongs and that is used by main primary processes. The large databases typically store data on products, processes, customers, suppliers. Management activities include the life cycle of information creation, updating, analysis/reading, disposal. Some examples are listed in Table 19. Industry Information Description Usages Structural data of private and Fiscal master data business tax payers (fiscal code, fiscal address, activity etc.) Revenue Service Municipality Bank Automotive Citizen Master Data Customer Master Data Bill of materials Routing Structural data of citizens (birth date, parents, spouse etc.) Structural data of customers (e.g. customer address, credit, relations with banks etc.) Structure of cars : relations between car components (which component is used on which car model and which components are contained in a car model) Sequence of the manufacturing operations in the factory: relations between car components and equipment Table 19 Examples of enterprise databases Taxation operational services Taxation planning Taxation analysis Services to citizens Banking services Marketing campaigns Customer profiling Car design Operations planning Inbound logistics planning Product cost analysis Production process design Operations planning 7.6 The AL grid Activity levels refer to a given BP. Now, an enterprise includes a great number of BP, each referring to a given domain of the enterprise business. A domain can be defined as the functional action scope of a process. Of course, domains are peculiar to each industry and, within each industry, to every organization. The AL grid crosses domains and levels in a given context, and, therefore, represents relations between the sets of Domains and the set of Levels. Each relation between a given domain D i and a given Level L j identifies a BP module, as exemplified in Table 20. Copyright 2011 [email protected] - Draft for internal use- do not quote - 34 of 65

35 Domain Level L1 Planning L2 Execution L3 Monitoring L4 Control L5 Info management D1 D1L1 D1L2 D1L3 D1L4 D1L5 Dn DnL1 DnL2 DnL3 DnL4 DnL5 Table 20 the AL grid In Table 21 we exemplify an AL grid in a generic automotive factory. Some levels have been subdivided. Planning has been subdivided in two sub levels (respectively, Long term and Short Term) and the same holds for Execution, that is split into physical and virtual flows. The domains are reflect classic functions of an automotive company. You can note that some the quadrants are empty because the relation is nota applicable (NA). E.g. the relation between the domain Research & Development and the sub-level Physical Flow is empty, because designers handle virtual and not material objects. Each quadrant identifies a potential process module. Of course, to identify elementary activity, a long sequence of specialization and decomposition had to be performed. Level Operations planning Execution Sub level Long term Short term Physical flow Virtual Flow Research & Development Research annual planning Project planning NA Product and process design and test (project execution) Inbound Logistics Operations Outbound Logistics Supply annual Operations annual Distribution annual planning operations planning planning Monthly / weekly/ daily supply supplier programming Raw materials handling and control Supply order management Warehouse management. Monitoring NA Raw materials tracking Information Design and Management Product Database Supplier database Raw materials database Monthly / weekly/ daily supply factory programming Monthly / weekly/ daily supply shipment programming Sales and Marketing Sales annual planning Marketing campaigns Sales monthly programming Factory operations Shipment of cars NA Production order management Customer Order Tracking Bill of materials Routing Table 21 AL grid : automotive industry Shipment and transportation orders Car tracking Dealer and transporters database Customer orders Customer billing Customer Order Tracking Product catalogue Customer database 7.7 The AL Method To build an AL grid of an organization, the analyst (a) breaks down the activity levels to the required detail by specialization and decomposition and (b) identifies domains by an appropriate combination of field analysis and industry reference frameworks. Let us consider the case of a company we call SUPER, that is a leading vendor of software for Human Resources (HR). The software is licensed to a wide variety of customers, which include (a) HR advisors servicing small companies, (b) large organizations running HR software on their premises (c) large and small organizations that buy the service from SUPER. The software is sold by a network of agents while a central department serves larger customers. Installations are made and cared by regional service centers, while a centralized customer care handles user claims and issues. Since information on customers and installations is decentralized, and headquarters have a limited control on customer management. So, management asked a common information base for marketing, document management, sales and control. In short, the enterprise architecture was to be re-designed. Typical steps of GEF method that are shown in Table 22. Copyright 2011 [email protected] - Draft for internal use- do not quote - 35 of 65

36 Step Tasks Output Identify Collect information on organization structure of the corporation List of BPs Interview departments on the activities they perform and analyse documentation Business Processes List candidate business processes CRASO To make sure that candidate business processes are real end to end business diagrams processes, sketch a CRASO diagram of the each BP process and model hierarchy diagrams of each BP as needed BP hierarchy as needed Allocate activities Distribute activities of each BP onto the appropriate levels; customize levels as needed GEF grid structure Assess Assess the maturity of activities and appraise the gap from the best practice GEF grid assessed Table 22 AL method steps An example of assessment is shown in Figure 23, where we use a color code: Blank: it indicates a missing activity. Yellow: it indicates a partially defined activity, that is actually performed, but without a defined procedure; so it is not sure that the activity is always performed in the same way. Green: it indicates a defined and documented activity, that may be computerized or manual or mixed, where tasks, outcome and rules are written in a document. In Figure 23, standard GEF levels have been customized; specifically, the level Planning has been specialized into Short term and Long term. Columns show sub processes of the overall Customer Management business process. Sell to Corporate Customers is a BP where application software is sold by headquarters sales office. Sell to Retail Customers is a BP where application software is sold by a network of agents to the smaller customers of a given region; e.g. agent A covers North Milan and agent B covers East Milan. Sell to Government Customers is a BP that covers the sales activity with the government, where sales are made through a tender, that implies a request for proposals and a specific procedure. Finally, Install & Customize Software is a BP that is common to all customers and includes the activities of installation and customization of the software application that was previously sold. Within each quadrant of the GEF grid are listed activities (not elementary). The activities in yellow and green quadrants are actually performed, while activities in the blank quadrants reflect a best practice. Activities are aggregated, and they had to be decomposed and specialized to get elementary activities and related used cases. If you look the grid of In Figure 23, it is clear that BPs are not complete (no analytic information and only partial information on events is provided). Such incompleteness implies, for instance, that field salesmen are not governed and the control of headquarters is loose. Even within the limits of an overview, the evidence is dramatic and rattles the message that business is not ruled. The wider the gap from the best practice the less mature the processes. Copyright 2011 [email protected] - Draft for internal use- do not quote - 36 of 65

37 Business Process : Manage Customers Level Sub level Sub Process: Sell to Corporate Customers Sub Process: Sell to Retail Customers Sub Process: Install & Customize Sw Sub Process: Sell to Government Customers Planning Long term Sales Forecasting Marketing Plan Customization Plan Tender Planning Execution Monitoring Sales Planning Sales Plan Short term Sales Agenda Sales Agenda Installation Scheduling Headquarter Sales Procedure Headquarter proposals and sales tracking Proposal management Field Engineering Field sales management Field proposals and sales tracking Sw configuration Management Proposal Scheduling Tender Management Tender tracking Control Sales analysis Sales analysis Installation analysis Tender analysis Information Management Product structural data Product structural data SW configuration Product structural data Customer structural data (Organization, Employees, Sales History) Customer structural data (Organization, Employees, Sales History) Installation configuration Customer structural data (Organization, Employees, Sales History) Figure 23 Assessment of Activity Levels of Sales BP 7.8 An overall enterprise framework (OFE) An ideal overall framework should be universal, modular, adaptable. Universal means that it can be used on whichever organizations, be it an industrial enterprise, a government body or a financial service. Modular means that the framework can cover form small to large organizations, regardless their respective size. Adaptable means that the taxonomy can be easily extended to include the properties of specific industrial sectors or companies. Universal, modular, adaptable are objective properties of the Overall Enterprise Framework (OFE) that we illustrate here. It includes three overall BP classes (a) management (b) support (c) primary. OFE results merges and integrates some overall frameworks developed by management theorists. The framework of management processes is based on the very classic authorities Robert Anthony [Anthony 1964] and Gorry & Scott Morton [Gorry 1971]. The distinction between support and primary processes incorporates Porter s Value Chain concept, Nolan s Application Portfolio [Nolan 1974] and Blumenthal s taxonomy on information systems [Blumenthal 1969]. Let us shortly comment each BP class. Management processes include the activities by which management plan and control an organization. They are almost identical in every kind of organization. Generally, the larger the organization the more sophisticated the management processes. A detailed illustration is given in the subsequent sections. Support processes include the executive activities by which an organization feeds itself. They cover Human Resources, Accounting, Public and International Relations, and ancillary services as Information Technology, Plant and Building Maintenance, Security and alike activities. These processes marginally reflect the industry sector, while they are impacted by the organization s size and legal regulations. E.g. Human Resource management is influenced by labour laws; therefore, the European approach to hire and fire employees completely differs from China or USA. Similarly, payroll in a multinational company implies multiple rules and it is much more complicated than the one of a small business running in one city. In this case too, a detailed illustration is given in the subsequent sections. Copyright 2011 [email protected] - Draft for internal use- do not quote - 37 of 65

38 Finally, primary processes include the activities that make the value chain of an organization. Since the value chain changes by industrial sector, business processes reflect the industry where an organization operates. In this case, the variation span is very wide. A specific section is devoted to illustrate them in general and, also, to present some industry BP reference models. Let us consider now the whole BP architecture of an organization. An aggregate BP tree of a generic industrial organizations is in Figure 24. Specifically, organizational processes are made of management, support, and primary processes. Support and management processes are almost identical in all organizations. However, organizational size and legal factors heavily impact their implementations. Conversely, primary process reflect the value chain specific to each industrial sector, and, therefore, change even their first level structure by industrial sector, as it indicated by the specialization arrow from the super type Primary Processes to the sub type Manufacturing Primary Processes. ORGANIZATIONAL BUSINESS PROCESSES MANAGEMENT BUSINESS PROCESSES PRIMARY BUSINESS PROCESSES SUPPORT BUSINESS PROCESSES STRATEGIC PLANNING MANAGEMENT CONTROL OPERATIONS CONTROL MANUFACTURING PRIMARY BUSINESS PROCESSES DEVELOP PRODUCTS SOURCE MATERIALS LEGAL & BUSINESS ACCOUNTING HUMAN RESOURCES MANAGEMENT IT SERVICES PLANT MAINTENANCE MAKE PRODUCTS SELL & DELIVER PRODUCTS SERVICE PRODUCTS AFTER SALE PUBLIC RELATIONS INTERNATIONAL RELATIONS Figure 24 Tree of aggregate BP classes in organizations. In an ideal organization, the quality of these three process classes is high and balanced. For, an ineffective management process prevents from controlling a multinational enterprise or government body and therefore its global performance would be poor. Poor primary processes simply do not create value to customer, and this mean no or less money for the company. Finally, poor support processes lead to a useless bureaucracy and high organization costs. Figure 25 puts side by side the structures of primary BP classes in manufacturing, that can be held as a reference case, Government and Telecommunications. This view clearly shows that the intersection of the respective primary process is almost null. The only one overlap is customer care, that is in both manufacturing and telecommunications, tough with much higher volumes in telecommunications. Such radical difference implies that the correspondent transactions processing software should be conceived and designed as self-contained. In a more comprehensive view, the overall schema of organizational BP can be represented as a T chart, where the arms of T represent, respectively, support processes and management processes, while the leg represents primary process. The horizontal and vertical orientations of the BP classes mean, respectively, that primary processes are specific to each industry (and therefore vertical ) while management and support processes are cross-industry (and, therefore, horizontal ). See Figure 26. The three BP families are influenced, as we have said, by organizational size, legal factors and industry profile. Let us comment one more time these drivers. Generally, organization size tends to complicate both business and management processes: e.g. a multinational company is more Copyright 2011 [email protected] - Draft for internal use- do not quote - 38 of 65

39 Primary processes BUSINESS PROCESSES ARCHITECTURE complex to manage and administrate than a small local factory. Legal regulations heavily impact administration processes, but marginally influence management and operations: e.g. EU rules condition Human Resource management but do not affect the production flow. Finally, the industrial sector shapes primary processes but marginally influences administration and management: e.g. the inbound logistics of a multinational Iron & Steel corporation is peculiar, while its management and administration do not differ very much from a multinational insurance company. The T-chart explains also BP computerization. Integrated software platforms for business process automation, e.g. ERP (Enterprise Resource Planning) and CRM (Customer Relationship Management), contain cross industry modules for management and support processes, and specific modules for each industry to be supported, often called industry solutions. PRIMARY BUSINESS PROCESSES GOVERNMENT PRIMARY BPs MANUFACTURING PRIMARY BPs TELECOMMUNICA- TIONS PRIMARY BPs SERVICES TO CITIZEN DEVELOP PRODUCTS DEVELOPMENT OF TELECOM SERVICES SERVICES TO BUSINESS SOURCE MATERIALS SALES AND CUSTOMER MANAGEMENT CROSS GOVERNMENT SERVICES MAKE PRODUCTS PROVISION OF SERVICES SELL & DELIVER PRODUCTS OPERATIONS SERVICE PRPDUCTS AFTER SALE BILLING CUSTOMER CARE Figure 25 An aggregate view of primary BP classes. Management processes Support processes Figure 26 The T concept of business process in organizations Copyright 2011 [email protected] - Draft for internal use- do not quote - 39 of 65

40 8 The map of support processes BUSINESS PROCESSES ARCHITECTURE Let us now consider the support processes in some more detail. An overall view of support processes is given by Figure 27. We here illustrate some key classes of them. First, we consider accounting processes, since they are the typical case of support. Second, we consider human resource management, that focus at enterprise resources. Finally we illustrate IT services, that is a process class grown with the advent of computers in organizations. Support processes Accounting Human Resources IT Services Other Support Processes Primary Ledgers Human Resources Planning IT Planning Management Accounting Human Resources Management Demand Management Legal Accounting Human Resources Administration Projects Industrial Relations Operations Other Services Performance Management Figure 27 Hierarchy of some support processes (Processes shown in the figure are still at an aggregate level; to identify elementary activities further levels are needed). 8.1 Accounting Accounting probably were the first processes that were modelled. A first general model was developed as early as in Renaissance by Luca Pacioli (Pacioli 1494), an Italian mathematician, who defined the chart of accounts. The rigid and formal schema of accounting records drove business to the precise procedure of double entry. The chart of account has evolved and nowadays are standardized by the International Accounting Standards (IAS) and the subsequent International Financial Reporting Standards (IFRS). Here, we illustrate only three main sub processes, namely Primary Accounting, Legal Accounting, Management Accounting. Generally, these processes are mostly paperwork and, therefore, are nowadays fully computerized Primary Accounting is made of Ledgers, that record detailed transactions with external entities. They include General Ledger, that record all transactions, and Receivables Ledger and Payables Ledger, that record individual transactions, respectively, of Customers and Suppliers. Other ledgers record transactions with banks, the Revenue Service, on corporate assets, inventory etc. By Legal Accounting we mean the procedures that produce public reports, as balance sheet and related information, for corporate stakeholders shareholders, Revenue Service, auditors, analysts etc. Generally, Legal Accounting summarizes and processes information from ledgers. Its complexity reflects organization complexity and multi-nationality. In large holding companies, that group many subsidiaries, it should handle both bookkeeping of the individual subsidiaries and consolidation at the holding level. Furthermore, in multinational companies it should comply with multiple legal requirements, that often imply expensive ad hoc reports. Copyright 2011 [email protected] - Draft for internal use- do not quote - 40 of 65

41 Finally, Management Accounting captures both external transactions (e.g. sales) and internal transactions between the departments of the company (e.g. production shipments from the factory to the sales department). The purpose of management accounting is, of course, to produce statements of income and cost for each organization unit (called also cost center or responsibility center ). This is a critical need for large and complex corporations. Thus, a corporation processes as many accounting statements as many organization units wants to control. E.g. the ledger of a Factory shall record under the cost side the value of raw materials while the value of production delivered shall be recorded under income side. In the statement of an IT department, the cost side records the value of resources used (e.g. computer lease), while the income side records the value of services provided to other departments. Since large multinational companies may account thousand and more organization units, management accounting often is more complex than Legal Accounting. Human Resources According to popular paradigms (e.g. Hathis & Jackson 2009), we break down the Human Resource management processes, according to the life cycle of personnel in the enterprise, into Planning, Management, Administration, Industrial Relations. Let us consider each sub process. Planning defines the quantitative and qualitative staffing requirements: how many people and which jobs for a given volume of operation. Best practices would consider the natural trend of employees (ageing, career, work experience) versus the requirements arising from the organization s strategy (e.g. new markets/ products, new technologies, new productivity standards etc.) and related operations. The planning process will identify the actions needed to fill the gap between natural trend and strategic requirements. Management is particularly sophisticated in knowledge intensive companies, and it includes a wide variety of processes: Hiring / Selection: it includes search, screening, recruiting of employees and managers - based on external information and also on external suppliers (hiring agencies); Development: it includes the analysis of performances and potential of individual employees and the planning of his/ her career; Education and training: it includes the whole cycle of planning, design and delivery of education / training initiatives. Administration is dependent on the legal context of each country, and it includes accounting processes as: Presences and absences data gathering (timesheet) Payroll and related procedures; Tax accounting for employees (typical of EU) Healthcare accounting, that interfaces health care government agencies (typical to EU) and/or health private insurance companies (typical of EU); Pension accounting, that interfaces government agencies (typical to EU) and/ or private pension funds. Industrial relations are a process, highly variable, by which the Human Resources function manages relations with Unions, in terms of negotiations, meetings, agreements and alike. Finally other processes include services to employees (also called Employee Relationship Management ) e.g.: Information to employees o general corporate information management o employee information management (employees can access their own records on vacations, time tables, allocations etc.) employee care (it answers the questions raised by employees) Management of social activities and services (clubs, associations, groups) Utility services to employees (transportation, cafeteria, nursery etc.) 8.2 IT services IT services are a peculiar BP class, that was born together with computer technology. A first simple taxonomy, that was already sketched in the Seventies [Norton 1973], classified IT services into the three classes of planning, development, operations. We here use a more detailed classification, that is based on a field research on IT management in large corporations [Motta 2006, 2010, 2011], that Copyright 2011 [email protected] - Draft for internal use- do not quote - 41 of 65

42 distinguishes IT services into Planning, Demand Management, Systems projects, Operations, Performance management. Let us comment it shortly IT planning IT planning is a planning process that follows the overall planning framework of defining objectives and related resources. Objectives mainly include system projects, that reflect (a) the alignment to business practice and technology (b) the needs emerging from business innovation. Resources are staff, equipment and funds allocated to support operations and projects. Projects and operations configuration depend on the Enterprise Architecture, that is given by the architecture of business processes, of the related computer applications and of technology uses to run applications. A popular framework for Enterprise Architecture is TOGAF (The Open Group Architecture Framework), that provides a specific method, called Architecture Development Method (ADM) [Barroero 2010, The Open Group 2009]. Figure 28 shows the eight main steps of ADM. Figure 28 Steps of the Architecture Development Method of TOGAF framework Demand management The purpose of Demand Management is to collect, structure, assess and implement user needs. In other terms, Demand Management bridges the executive activities of Systems Projects and Operations with the needs of users. Demand managers are people which combine the knowledge on a user domain (e.g. accounting) with the knowledge on related IT systems, and, therefore, can identify and filter both innovation and refitting needs. Copyright 2011 [email protected] - Draft for internal use- do not quote - 42 of 65

43 8.2.3 Systems projects By Systems projects (also called Development, Projects or alike terms) we mean the activities running during the life cycle of a project, from the analysis of user requirements to the release of the system. Of course, projects may be cover a new need or business, or may simply replace / refit existing systems IT operations IT operations are the activities that run data centers, geographic and local area networks, end user computing and help desk, application and data base administration Performance management REPORT TO MANAGEMENT CATALOGUE & SLA MANAGEMENT SYSTEM (list of services provided and related SLA) PROJECT CONTROL (cost, quality, time) REAL TIME PROBLEM MANAGEMENT (e.g. failures) REAL TIME MONITORING (e.g. control room) Figure 29 Layers of information systems that support IT performance management. Performance management defines the expected performances with each IT service in terms of availability, response time and alike performance indicators. The performance values are often written in a Service Level Agreement (SLA) that, in the case of a third party provider, states price and penalties to performance levels. Performance management and related SLA may be, in large IT intensive organizations, complex processes The ITIL framework Recently various reference frameworks have been developed for IT services. ITIL [Taylor 2007], one of the most popular collection of best practices on IT, defines IT processes based on the life cycle of an IT service. Therefore, it identifies Service Strategy, Service Design, Service Transition, Service Operations, Continuous Service Improvement. These processes are further detailed in sub processes or steps. Service Strategy Service design Service Transition Service Operation Continual Service Improvement 1. Strategy Generation 1. Service Catalog Management 1. Transition Planning & 1. Event Management Step 1: Define what needs to be measured 2. Service Portfolio Management 2. Service Level Management Support 2. Change 2. Incident Management Step 2: Define what can be measured 3. Demand Management 3. Capacity Management Management; 3. Service Asset & 3. Request fulfilment Step 3: Data collection 4. Financial Management 4. Availability Management Configuration Management 4. Problem Management Step 4: Formatting your data Copyright 2011 [email protected] - Draft for internal use- do not quote - 43 of 65

44 5. IT Service Continuity Management 6. Information Security Management 7. Supplier Management 4. Release & Deployment Management 5. Service Validation & Testing 6. Evaluation 7. Knowledge Management 5. Access Management 6. Service Desk 7. Technical Management; 8. IT Operations Management 9. Applications Management Table 23 Map of ITIL processes [Taylor 2007]. Step 5: Analysis of data Step 6: Presentation and use of information Step 7: Implementation of corrective action The ITIL sequence of processes reflects the life cycle of a service, that starts with strategy definition and ends with a phase of continuous improvement. In ITIL jargon, transition means the activities through which a given IT service e. g. a web system, is implemented and released. The service operation activities are broken down by expected result e.g. to manage a service denial of a system. Finally, continual service improvement is much more detailed than other processes and leaves are to be considered elementary activities. The high number of business processes reflects the growing maturity of IT services. However, the ITIL catalogue is limited: it contains management and not executive activities i.e. software development activities (design, coding etc.) and operations. 9 The map of primary processes To define a map of primary processes is a complex issue. For, as we have seen in the previous sections, the map of primary processes varies across the industrial sectors. Therefore, maps should be as many as industrial sectors. In order to better understand the roots of the underlying concepts, let us sketch a short history of the conceptual frameworks. Early frameworks were born in the Seventies and Eighties when the growing computerization of business operations attracted the attention of management theoreticians to operational processes. In order to define a strategy for computerization, it was (and is) necessary to map the functional areas that systems support, as it happens with [Blumenthal 1969] [Nolan 1973], that we shortly illustrate in subsequent sections. A second phase are industry frameworks. From 1990, the growing success of software platforms as MRP II (Manufacturing Resources Planning) in Manufacturing and alike common software solutions in other industries, led some industry consortia to define a common BP industry framework. These frameworks are very detailed, and provide a description of each individual process. So, each organization could have a reference manual to define the structure, flow and rules of its processes. 9.1 Early frameworks: Blumenthal In his work, Blumenthal (1969) sketched one of the first enterprise BP frameworks. His purpose was to define a taxonomy for information systems (at those time called Management Information Systems (MIS) The taxonomy was based on functional coverage, i.e. on the BP supported by MIS. Essentially, the framework identifies a set of information Processing Modules PM, each being described by the a relation between the types M, R where: M is an Anthony s management process layer, specifically, Operations Control or Management Control, R is one of the enterprise resource, according to Jay Forrester s (1959) taxonomy, i.e. Personnel, Money, Raw Materials, Products, Equipment, Therefore, each module of the information system, hence, processes at a certain level management or operations control- the information concerning a given resource domain. Each module is further subdivided by empirical criteria (Figure 30). Copyright 2011 [email protected] - Draft for internal use- do not quote - 44 of 65

45 9.2 Early frameworks: Nolan BUSINESS PROCESSES ARCHITECTURE Few years after, Nolan [Nolan 1974] proposes a BP map that represents the organization s portfolio of information systems, called applications portfolio. The map is layered in the three levels of Strategic planning, Management Control, Operations, that include both Operations Control (e.g. Distribution Planning) and Operations execution (e.g. Physical Distribution). The detail segmentation of each level is based on empirical evidence as we show in Figure 31. The portfolio of operational systems is segmented in columns, each one representing an organizational function, that in the example reflect a generic automotive industry. Columns are filled with a colour showing the degree of computerization, that may be planned or current, as judged by users or independent observers. Nolan s framework, theoretically not robust but easy to understand, has been and is largely used. Operations Control Raw Materials Finished Products Equipment Finance (Money) Personnel Procurement Sales Installation Payables/ Receivables Hiring Inbound Logistics Outbound Logistics Operation Legal Accounting Training and Education Production. Maintenance Management Accounting Figure 30 Blumenthal s map of information systems Blumenthal segments information systems based on a functional taxonomy of organization process. In the figure, the first level (solid lines) reflects Blumenthal s original segmentation, according which each information system covers a given flow of resources within a given management process; further detail (dotted lines) has been added by us by assuming a life cycle for each resource flow. It is clear that (a) the framework only applies to industrial organizations, specifically manufacturing; and (b) it lacks a specific approach to the transformation function. Copyright 2011 [email protected] - Draft for internal use- do not quote - 45 of 65

46 Payroll Human Resources Management Receivables Payables General Ledger Equipment Maintenance After Sales Service Distribution & Outbound Logistics Sales & Marketing Production Planning Materials Management Procurement & Purchasing Product Development BUSINESS PROCESSES ARCHITECTURE Strategic Planning Management Control Figure 31 Nolan s application portfolio. The graph shows planned and current computerization of business processes in a generic automotive industry. Processes at operational level are segmented according to their functional domain, that is identified by empirical evidence ( interviews, organizational manuals and alike). Management control is unique for the whole enterprise. The degree of planned and actual computerization is measured by the filled part of each silos and it is defined by a qualitative assessment, e.g. by interviewing managers and comparative analysis of best practices. The degree of computerization shown in the graph reflects a realistic early stage of IT. 9.3 Industry frameworks Many consortia have developed industry frameworks. Other developments in the Nineties concerned BP design methodologies more than new BP frameworks (2).The most successful example is probably SCOR (Supply Chain Organization Reference model) consortium, founded in 1996, and nowadays counting hundreds of member corporations ( Other frameworks include etom 10 The GEF framework 11 The SCOR framework 11.1 The structure of the SCOR framework SCOR (Supply Chain Operations Reference) is a reference framework that describes a supply chain of multiple organizations. It has been developed by the Supply Chain Council, a non-profit 2 In the period , the advent of integrated software platforms, as ERP (Enterprise Resources Planning) and CRM (Customer Relationship Management), pushed companies to redesign their own processes to fit software. On the other side, the overwhelmingly successful theory of BPR (Business Process Reengineering), heralded by Michael Hammer (1991), pushed managers to innovate processes to improve competitiveness. BPR and ERP/CRM mated very effectively: enterprises computerized their processes by ERP/CRM software, and redesigned process flows accordingly. Copyright 2011 [email protected] - Draft for internal use- do not quote - 46 of 65

47 consortium set in 1996 by Pittiglio, Rabin, Todd e McGrath (PRTM) and MR Research. In 1996 it gathered 69 organizations that, nowadays, are over one thousand (Bolstorff 2007, Unfortunately, because of its own success, SCOR became a business and is no more an open framework; so, we here illustrate the last open version, namely SCOR 6.0. Before illustrating SCOR structure, let us define what a supply chain is. A supply chain is a sequence of facilities linked by transportation flows, that may be railways, roads, ships or airfreight. E.g. an automotive supply chain includes, form the delivery to the customer up to the supply: The car dealers, that deliver the cars to the end customers; The car maker, that assembles the components and manufactures cars and supplies the delivery network; The suppliers of car components as tyres, gearboxes, brakes, seats etc.; The suppliers of the component suppliers, that provide raw materials or elementary components. SCOR models the supply chain by these complementary perspectives: Approach used to run the supply chain, Functional domains of supply chain processes, Levels of analysis The approach to the supply chain The flow of goods and services within a supply chain may operate according to different approaches : Make To Stock (MTS): it is the case of an enterprise that produces for the finished product stock, as it happens for fashion; the production is launched based on sales forecast not on the individual orders of individual customers Assemble To Order (ATO): the customer issues an order, that selects a combination among the options listed in the product catalogue; each individual product instance is composed according to the specification given by the customer, as it happens in automotive, where the customer defines optional, colour and other characteristics of the car; Make to Order (MTO): the product is manufactured on customer s order, as it happens with a luxury tailor who cuts and sews a dress only if a wealthy customer orders it; Purchase to Order (PTO)/ Engineer to Order (ETO): the product is designed (and made) on a specification issued by the customer, as it happens with elevators, that are designed, made and installed base on requirements of each individual building Functional domains of supply chain processes Let us now comment the schema of processes. SCOR identifies five process functional domains. The first domain is Plan the supply chain, that mostly coincides with our concept of operations planning. Executive domains include: Source, that is conceptually equivalent to the Inbound Logistics of Porter s value chain; Make, that is conceptually equivalent to the Operations of Porter s value chain, and includes the realization of products via blending, separation, mechanical work, chemical transformation; Deliver, that is conceptually equivalent to the Outbound Logistics and Sales of Porter s value chain; Return, a concept peculiar to SCOR, includes the return of materials by the customer to the supplier, e.g. because they have not been positively tested. Source, Make, Deliver and Return, as execution processes, are ruled by Plan process. SCOR describes also a wide class of processes, named enabling processes, that are intended to prepare, file, handle information needed to planning and execution processes Analysis levels of the supply chain processes SCOR is broken down is a series of detail levels (Figure 32): Level 1 (Top level) includes the process functional domains: Plan, Source, Make, Deliver, Source Return, Deliver Return; Copyright 2011 [email protected] - Draft for internal use- do not quote - 47 of 65

48 BUSINESS PROCESSES ARCHITECTURE Level 2 (Configuration level) splits domains according to the configuration of the supply flow and results in the following list of process modules: o Plan P1 Plan the whole Supply Chain P2 Plan Source P3 Plan Make P4 Plan deliver P5 Plan Return o Source S1 Source stocked product (MTS) S2 Source make to order (MTO) S3 Source engineer to order (ETO) o Make M1 Make to stock (MTS) M2 Make to order (MTO) M3 Engineer to order (ETO) o Deliver D1 Deliver stocked product (MTS) D2 Deliver make to order product (MTO) D3 Deliver engineer to order product (ETO) D4 Deliver retail product (this is an addition of SCOR 6.0) o Source Return SR1 Return defective product SR2 Return MRO (Maintenance, Repair and Operations) product (i.e. a supply that is not a raw material) SR3 Return Excess Product o Deliver Return DR1 Return defective product DR2 Return MRO (Maintenance, Repair and Operations) product (i.e. a supply that is not a raw material) o Deliver Return DR1 Return defective product DR2 Return MRO (Maintenance, Repair and Operations) product (i.e. a supply that is not a raw material) DR3 SR3 Return Excess Product Level 3 (Process Element Level) identifies the sub-processes or phases of modules identified in level 2. E.g. the process module P1 (Plan the supply chain) is decomposed into three process elements, named P1.1, P1.2, P1.3, P1.4; Level 4 (Implementation Level) describes how an individual organization performs a subprocess of level 3; this level is obtained by specialization and decomposition of process elements of level 3, and the analysis continues until a desired detail has been reached; level 4 is designed every time by the analyst, which develops the standard SCOR map by using appropriate modelling techniques. Copyright 2011 [email protected] - Draft for internal use- do not quote - 48 of 65

49 1 2 Level Schema Comments Plan Top Level Source Make Deliver Configuration Level Return Return Level 1 lists main process domains PLAN SOURCE MAKE DELIVER RETURN Level 2 splits domains according to the flow : MTS - Make to stock ATO - Assemble to order MTO - Make to order ETO - Engineer to order 3 Process Element Level P1.1 Identify, Prioritize, and Aggregate Supply-Chain Requirements P1.2 Identify, Assess, and Aggregate Supply-Chain Requirements P1.3 Balance Production Resources with Supply-Chain Requirements P1.4 Establish and Communicate Supply-Chain Plans Level 3 identifies process elements. Each process element is described by a card in terms of: I/O information performance metrics best practices, where applicable support tools 4 Implementation At this level organizations implement specific practices Level by customizing SCOR framework Figure 32 SCOR levels: overview (adapted from SCOR 6.0 page 6) SCOR process elements are described by a thick manual, that contains not only diagrams but also cards that list their properties (Figure 33) in terms of: A text description; The metrics by which business performances of the Process Element are measured in terms of reliability, responsiveness, flexibility, cost, asset; Best practices, that mention reference solutions to perform or computerize the process element considered, and, also, mention excellence criteria, e.g. planning is excellent if balances supply and demand. In short, SCOR is a catalogue of reference process elements, and provides an organization with a starting point to describe and improve its Process actual business processes. In Figure 34 we sketch out an informal meta-model of the SCOR framework. Each SCOR level is represented by a square while oriented arches represent functional dependencies between levels. Process Elements have a double key, made, respectively, by supply configuration (MTS, MTO, ) and process domain (P, M, ) Process Element: Identify, Prioritize and Process Element Number: P1.2 Aggregate Supply Chain Resources Process Category Definition The process of identifying, prioritizing, and aggregating, as a whole with constituent parts, all sources of supply that are required and add value in the supply chain of a product or service at the appropriate level, horizon and interval. Performance Attributes Metric Reliability None identified Responsiveness None identified Flexibility Cumulative Source/Make Cycle Times Intra-Manufacturing Replan Cycle Time Cost Planning Costs as a % of Total Supply Chain Costs Supply Chain Finance Costs Product Data (MIS) Management Costs Manage Finished Goods Data (MIS) Assets Inventory Days of Supply Inventory Turns Return On Assets Cash-to-Cash Cycle Time Copyright 2011 [email protected] - Draft for internal use- do not quote - 49 of 65

50 Best Practices Collaborative Planning, Forecasting and Replenishment (CPFR) Joint Service Agreements (JSA) Digital links (Internet, EDI. Etc.) among supply chain members. Lead times updated monthly. Categorize 100% of total inventory (active, usable, excess, obsolete) for appropriate action. Review product profitability. BUSINESS PROCESSES ARCHITECTURE Features Business process modeling Workflow systems Collaboration Tools Advanced Planning Optimization Constraint based planning Integrated resource and material plan B2B Integration and Application Server Systems Collaborative Planning Systems Real-time exchange of supply chain information between supply chain members Collaborative planning systems, Internet Trading Exchanges. None Identified None Identified ABC and cost modeling. Figure 33 Description of a Process Element in SCOR Level 1 Process Family Level 2 Flow Family Level 3 Process Element Level 4 Custom Process PLAN SOURCE MAKE DELIVER RETURN 1. MTS 2. ATO 3. MTO 4. ETO Description Specialization / Customization of Level 3 Figure 34 SCOR Meta-model 11.2 The SCOR method: a short case study In order to complete the illustration of SCOR, let us consider the customization of the reference framework. We exemplify it on Turbo, a fictitious enterprise that manufactures turbines in an Engineer to Order (ETO) configuration. For, turbines are made on customer s specifications. Customer typically is a power company or an oil extracting company; therefore turbines should be custom made to match very variable installation, operative and maintenance conditions of the oil field or of the power station location. So turbines are designed by customizing base models. For the sake of simplicity we will give a method summary, where we list the phases sections and the main outputs. Phase Purpose / step Activities Output 1 - Top & configuration Purpose : define the scope of the analysis List Organizations & Processes to be analyzed Classify Supply chains (MTS/MTO/ETO) SCOR processes to be applied Copyright 2011 [email protected] - Draft for internal use- do not quote - 50 of 65

51 Suppliers Customers 2 - Process Element (PE) BUSINESS PROCESSES ARCHITECTURE Purpose: customize PE List PE as stated in SCOR manual Erase non applicable and add applicable PE Check PE dependencies PE sequence map of all SCOR PE considered Updated/ customized SCOR cards Step 1 : Model the PE hierarchy Analyze each PE until elementary activities (ELA) are identified Hierarchical Diagram (HD) of each PE ELA card 3 - Implementation Level Step2 : Model the PE flow Develop a flow (Activity Diagram, BPMN etc.) of each BPE Check cross PE dependencies of elementary activities Update ELA and HD as needed Process flow Updated ELA Updated HD Step 3 : identify use cases Develop Assembly Lines for each PE Assembly Lines of each PE Table 24 Summafy of the analysis method Phase 1 (Top Level and Configuration Level) The analyst starts by defining the boundaries of the top level analysis, i.e. by listing the organizations to be nalyzed. In our case we suppose we want to limit the analysis to Turbo. Turbo includes classic functional domains, namely Research and Development, Inbound Logistics, Operations, Outbound Logistics, Sales, Service. Then the analyst decides which process domains wants to analyze, and selects SCOR processes as shown in Figure 35. PLAN S3 (Source ETO) M3 (Make ETO) D3 (Deliver ETO) Figure 35 Selection of SCOR processes In the Turbo case study the area analyzed (surrounded by a dotted line) includes only executive processes, within the configuration Engineer to Order. Copyright 2011 [email protected] - Draft for internal use- do not quote - 51 of 65

52 Phase 2 (Process Element level) At this point, the analyst identifies level 3 process elements that apply. For each process element, SCOR proposes a certain series of phases, as we show in Figure 36, where are indicated, for each process element, relations with other process elements. The horizontal arch represents the execution flow, while vertical arrows represent information input or output from or to other process elements M3: Make Engineer-to-Order (D3.3) Order Information (P3.4) Production Plan (M3.3, M3.4, M3.5, M3.6, M3.7) Information Feedback (S1.1,S2.1,S3.3) Scheduled Receipts (EM.5) Equipment & Facilities Schedules and Plans (S1.4,S2.4,S3.6) Inventory Available (EM.4) WIP Handling Rules, Move Info & Methods (EM.6) WIP Location Rules Shop Plans Factory doc Factory Doc Parts Factory Doc Product Release M3.1 M3.2 M3.3 M3.4* M3.4** M3.4*** M3.5 Finalize Engineering Schedule Production Activities Issue Product Foundry Mechani cal works Assembly & test Package Methods, Procedures, Processes (M3.2) Shop Doc Production Schedule (P3.2,S1.1, S2.1,S3.3,D3.3, D3.7) Shop doc Info Feedback (M3.2) Replenishment Signals (S1.1,S2.1,S3.1) Sourced Product Location Info (EM.6) Shop doc Shop Doc Shop Doc Info Feedback (M3.2) Product Release Info feedback (M3.2) Figure 36 Customization of level 3 Make processes in the Turbo case study Process element M3.1 Finalize Engineering, that has the purpose to set the design the turbine requested by the customer, inputs information on orders from Delivery 3.1 process element and, also, outputs a bill of fabrication procedures that inputs to the subsequent M3.2 Schedule Production Activities. In our case process element M3.4 has been split into M Foundry, M3.4.2 Mechanical Works, M3.4.3 Assembly & test that represent, in the Turbo case study, the phases of physical production of a turbine. Finally, the analyst has added some input and output elements (written in Italics) e.g. Shop documents Copyright 2011 [email protected] - Draft for internal use- do not quote - 52 of 65

53 S2.1 S S2.2 S2.3 M3.1 M3.2 M3.3 M M M M3.5 D3.1 D3.2 D3.3 D3.9 D3.9 D3.11 Figure 37 Level 3 SCOR Customization of the Turbo case study : flow of process elements The analyst continues in the description and customization of the SCOR map of selected processes as shown in Figure 37. Blank boxes indicate process elements introduced by the analyst to reflect peculiarities of the Turbo case study Phase 3 (Implementation level) In order to describe the elementary activities of processes and identify related use cases, a series of steps are needed, that reflect the method we have mentioned in the earlier sections of this chapter: 1. Break down the SCOR processes until elementary activities are identified, by using hierarchical modelling (decomposition and specialization operations) 2. Model the flows of elementary activities 3. Identify candidate use cases (we assume that candidate use cases are related to elementary activities) Phase 3 step 1 : model the hierarchy of the process element In Figure 38 we exemplify step1, that is performed by an UML business extension [Eriksson & Penker 2000]. Process elements M3.1, M3.2 etc. are specialized into the corresponding elementary processes of Turbo: process element M3.1 Finalize Engineering (Figure 36) is specialized into the corresponding Tune design, that in turn is broken down in activities, that the analyst has defined by interviewing users: Receive product specifications, that have been issue by the customer Design the size sketches in order to render outside volumes Design executive drawings and issue bill of materials Manage ongoing engineering changes Plan and manage meetings between Development, Sales, Production departments Copyright 2011 [email protected] - Draft for internal use- do not quote - 53 of 65

54 M3.1 - Finalize Engineering M - Make M3.5 - Package Con packaging si intendono le operazioni finali tramite le quali il gruppo di pompaggio completo si rende pronto per la consegna al cliente Collegamento motore di prova Ricezione specifiche prodotto Ultimare l ingegnerizzazione Realizzazione bozzetti d'ingombro Gestione modifiche in corso d'opera Organizzazione di incontri interfunzionali M3 - Make Engineer-to- Order Product Package Package Posizionamento tubi di aspirazione e mandata Bilanciatura girante Fase di pull-out M3.4*** - Assembly and test Ispezione finale Collaudo Verniciatura Montaggio componentistica Controllo gioco tra i componenti Rilevamento performance e certificazione Svuotamento olio di supporto Determinare quali parti fabbricare internamente Realizzazione disegni e distinta base M3.2 - Schedule Production Activities Definizione dei piani settimanali Allogiamento pompa su trolley Fissaggio pompa tramite bulloni Trasferimento complesso supporto-albero-girante sul trolley Assemblaggio e test Pulizia pompa e smontaggio tubazioni Alineamento e montaggio motore Ritocchi alla verniciatura Costruzione del modello in ceramica M3.4* - Fusion Saldatura tubi di flussaggio alla pompa Scollegamento motore Programmazione delle attività di produzione Posizionamento del modello nella staffa Unione del corpo pompa al complesso Applicazione delle protezione Definire i fabbisogni di produzione Scomposizione piani mensili in piani settimanali Pianificazione a ritroso e trasmissione programmi della produzione settimanali ai capisquadra Trasmissione mensile dei programmi di lavoro M3.3 - Issue Product Riempimento della staffa con terra da fonderia Compattazione della sabbia Fusione Verifica rispetto delle specifiche Finitura Sgrassaggio e asciugatura M3.4** - Produce Montaggio oliatori e riempimento del supporto con olio Raccolta materiali per la realizzazione del prodotto Divisione della staffa in 2 semistaffe Completamento della forma con canali di colata, canali di sfiato e montanti Sformatura Costruzione degli anelli di tenuta o usura Realizzazione degli alberi Produzione Movimentazione dei componenti da assemblare Raccolta materiali per la realizzazione del prodotto Trattandosi di Job-Shop, tale attività è importante poichè consente una facile gestione dei WIP Fase di Colata Indurimento sabbia e Estrazione modello Assemblaggio forma Costruzione dei rotori Costruzione dei corpi pompa Pressatura Realizzazione delle cassestoppe Figure 38 SCOR level 4 Modelling by an UML extension: hierarchy of processes and elementary activities Phase 3 step 2 : model the flow of elementary activities Step 2 models the flow of activities within each process element. The analyst starts by selecting elementary activities identified in Step 1 and models the sequence and other properties as input and output events, branching and merging of the flow etc. In modelling flow, the analyst may expand or cancel activities of the previous hierarchy. In the Turbo case study, the analyst has cancelled some activities (i.e. Receive product specifications, Plan and manage meetings) and added some other activities Phase 3 step 3 : identify use cases We exemplify the third step in Figure 39. The analyst considers the flow developed in Step 2, of a process element, e.g. M3.1 Finalize Engineering and aligns it against candidate entities, that are represented as UML package and are called Assembly Lines because of their similarity to the real assembly lines of car factories. These candidate entities are identified by the analyst from interviews and other knowledge sources, and are refined subsequently as entities and relationships in database modelling. E.g. the candidate entity Bill-of-Materials shall be refined into multiple conceptual entities as Material-master-data, Material-structure, Engineering Change, Customer-project. The analyst links candidate entities and activities of the flow he or she has put down. Specifically, he or she identifies read or write actions by activities on the candidate entities, and models them, respectively, by a blank or by a filled token. E.g. the activity Design executive drawings and issue bill of materials reads the information stored in the entities Technical-Specifications and Volume-Drawings and writes information into Bill-of-Materials and Drawings and corresponds to the use case Creation of the project bill of materials. Copyright 2011 [email protected] - Draft for internal use- do not quote - 54 of 65

55 Ultimare l ingegnerizzazione Ricezione conferma bozzetti d ingombro Ricezione specifiche prodotto Aggiornamento piano di produzione Ricezione specifiche prodotto Invio bozzetti d ingombro Inserimento specifiche nel sistema {AND} Realizzazione disegni e distinta base [ Modifiche ] [ NO Modifiche ] Immisione modifiche nel sistema Adeguamento del progetto alle modifiche Invio informazioni attori interessati tramite Workflow Salva specifiche nel sistema Creazione progetto e distinta base Aggiorna specifiche Crea progetti e distinte modificati Aggiorna bozzetti d ingombro Specifiche tecniche Bozzetti d ingombro Disegno Distinta base Figure 39 Assembly lines The flow of process element of the Turbo case study is superimposed to a series of candidate entities in order to identify candidate use cases. Copyright 2011 [email protected] - Draft for internal use- do not quote - 55 of 65

56 12 Other industry frameworks: etom Figure 40 the etom grid - From In early Nineties, a work team called SMART (Service Management Automation and Reengineering Team) within Tele-Management-Forum (TMF) defined a first reference framework for a telecommunication enterprise. This concept was subsequently developed into a Service Management Business Process Model that, in 1998, was eventually merged into the Telecom Operations Map 3 (TOM). Finally, in 2000, a further version, called etom (enhanced Telecom Operations Map) was released. etom ( models business processes of a telecom enterprise according to various perspectives that are crossed together in a table model: functional, horizontal, vertical (Figure 40). Let us consider each one. Functional areas are: Operations, that includes all processes to handle customer s requests, service operation, network operation, management of relations with suppliers and partners; Strategy, Infrastructure & Products, that includes all processes related to (a) definition and development of corporate strategies, (b) design, implementation and installation of networks (c) conception, prototyping and development of new products and services for the market; Enterprise Management, that includes the classic support processes (Human resources, Accounting, Security Management etc.) Each functional area is broken down by an horizontal perspective, in which processes are grouped according to their respective functional purpose (e.g. customer management) regardless the structural boundaries within the organization: e.g. managing customer relations involves marketing department, sales department, accounting department, customer care department. Each functional area is also segmented by a vertical perspective, that reflects the end to end business chains e.g. Order fulfilment, Assurance, Billing. etom has been successful, and it has been used as a reference by a number of telecom enterprises, e.g. Telstra (Australia), TeliaSonera (Scandinavia), NTT (Japan), Sprint PCS (USA), Teléfonica Copyright 2011 [email protected] - Draft for internal use- do not quote - 56 of 65

57 Movíles de España (Spain). Also many vendors and system integrators use etom (Amdocs, Lucent Technologies, NTT Comware, MetaSolv Software, QinetiQ, Infosys Technologies, Fujitsu etc). 13 Further definitions 13.1 Business Services and Business Processes A BP may produce material and/or immaterial output, that may consist of a product or of a service. Most business processes in manufacturing produce physical outputs, such as cars delivered to the customers. Conversely, most business processes in an university produce immaterial outputs, such as classes and workshops. Acute observers would underline that even a process with a material output, as to deliver a car, exists because it provides a car plus the service of delivering, and this is indeed is the key of the process. Therefore, we have to define what a service is Business Service: a definition In our view, service is the delivery of an outcome to a recipient, who may be an organization or a person. Differently from a physical output, a service cannot be stocked in a warehouse. Business Services are produced and delivered by Business Processes. In simple terms, a business service can be described as an action performed by one or more organizations for the benefit of a user class, who in turn, can consist of individual persons or organizations. The action incorporates the delivery of a material or immaterial object. Users can be individuals, class of individuals, organizations or class of organizations. A business service can be described by the generic tuple: where: Definition 2 S = (A, C, O) S = business service; A = the sequences of activities by which the service is requested and delivered - i.e. car delivery; C = the receiver of a service, e.g. the customer who purchased the car; O = the material or immaterial outcome associated to the service i.e. the car that is delivered. By our definition, a service is a threefold relation between Customer, Output and Action. So services change every time the Customer and/or the Output and/or the Action changes. Let us consider a simple example, namely passport release. This is a generic service class that in turn can have different actions. Copyright 2011 [email protected] - Draft for internal use- do not quote - 57 of 65

58 Figure 41 Passport Release The same happens also with a very material output, e.g. a car. Some manufacturers in UK and USA have differentiated delivery services. In some cases the car is delivered to the dealer and the customer goes to dealer to get the car; in other cases the car is delivered by a driver directly to the individual customer. Now, the customer class is always the same, the same is the output but the delivery actions change and therefore the service is different. Therefore, in large organizations, with a wide variety of customers and outputs, business processes may be a lot. Let us consider the simple case of an intuitive banking business, i.e. mortgage loans. Suppose bank ABC wants to offer many classes of mortgage loans to different classes of customers (the action is always the same. i.e. lending money). The result is shown in Table 25. Customer class Output class private customers small offices, craftsmen etc. small enterprises O1- under 100K X X X O2-100K to 300K X X X O3- over 100K X X X Table 25 An example of service / process matrix Business to business and business to consumer services Service customers may be individuals or organizations. An example of the former case is healthcare, where a network of organizations, that involves government, hospitals, labs and individual doctors, delivers a wide range of diagnostic, prognostic and emergency services to citizens. These services to individuals are also known as Business To Consumers, in short B2C. An example of the latter case is advertising, where an agency supplies to customer organizations a wide range of services, such as campaign planning, production of commercials, media planning etc. These services to organizations are known as Business To Business or B2B. Of course, several organizations provide both B2C and B2B services, as it happens with banks, insurance, government etc., that all have both private and corporate customers. Service class B2B B2C Plant Maintenance X Copyright 2011 [email protected] - Draft for internal use- do not quote - 58 of 65

59 Service class B2B B2C Engineering Services X IT operations X Travel & leisure X X Transportation Services X X Financial Services X X Healthcare X Welfare X Institutional education (Primary School, High School, University) X Table 26 Business to Business and Business to Consumer services: examples 13.2 Business services versus IT services A business service is a service delivered within the human mankind. Cash advance is a business service, and healthcare, consulting and alike cases are business services as well. An IT service is a service that a software delivers to another software. This is precisely the case of customer identification in the ATM case: the software of the bank that processes customer s requests uses an IT service of another bank that provides information on the balance of the customer s checking account. To explain the relations between Services, Business Processes and IT Processes let us consider a simple example. A service delivery, e.g. to install a LAN, includes several processes in a telecommunications enterprise, such as: Order Entry, that collects and accepts orders made by customers, Order Processing, that breaks down customer orders into executive orders, e.g. o to the teams that perform physical installation in customer premises, o to the network which has to enable connections, o to the accounting department which will modify the master data for billing, in service activation processes, which imply the actual release of the service. The IT systems provide the IT services needed to implement the business processes alike the organizational architecture will do for activities and tasks performed by human beings. As the example suggests, IT and business processes are in a many to many relationship. In many cases, a business process uses multiple applications. In turn, a same application (e.g. web site) is used by multiple business processes. Copyright 2011 [email protected] - Draft for internal use- do not quote - 59 of 65

60 Figure 42 Relationships between Services, Business Processes and IT 13.3 Business processes versus physical processes In industrial and primary sector, operations mainly consist of material actions on material objects e.g. fabricating and assembling in Production. To better understand the differences between business versus physical processes let us consider the Computer Integrated Manufacturing (CIM) framework. According CIM, the automation of factory is on five levels, each providing a specific support to the operation of the plant (Figure 43 ). Level 1 includes the computer interface of an individual machine, e.g. a robot, and level 2 includes the stations that control multiple machines. Stations are coordinated at the cell level, where for instance a computer controls a line of production. These lower automation levels operate on physical events, and they are not self contained. In fact they execute orders and work plans created by upper levels, namely the centre and plant levels, that process management decisions for the lower levels, wherefrom they gather the information on actual performance. These upper levels automate business processes. Business processes, therefore, are complementary to the physical processes. In more general terms, physical automation is filling the gap between physical processes and business processes. Business Processes Physical Processes 13.4 The knowledge perspective Figure 43 The CIM framework (Wikipedia,) Let us spend few words about knowledge management, a concept and a technology that has become fashionable in the last ten years, but also, may engender some confusion on BP concepts. Nowadays, information can be collected on every topic. So the amorphous information on Internet, in organization s data bases and office systems can be organized in a computerized system that delivers information to execute a certain BP. Generally, Knowledge Management Systems can be conceived as computerized repositories of information produced by an organization, that can be integrated by internet information. Despite this vague definition, those systems can be extremely effective. Let us consider the case of a consulting company where all studies, proposals, presentations are stored in central repository and retrieved them by appropriate research engines. So, a consultant who is making a proposal for a materials management system for a Chinese corporation could find out all studies made on this topic, related proposals, curricula of people involved in those projects Copyright 2011 [email protected] - Draft for internal use- do not quote - 60 of 65

61 Field (t eam Building) Linking ex plicit know ledge BUSINESS PROCESSES ARCHITECTURE etc. Let us consider also the case of an elevator company. The technician, called to repair or service an elevator installation, will be substantially helped if he or she has on hand a checklist of controls, the history of tests made and an explanation of the most frequent faults and solutions something similar to a FAQ. In other terms, knowledge management systems integrate and expand the support given to organizations by classic entries information systems. They can support effectively an information intensive but loosely structured BP. Since they are repository of information, they may be used in primary processes, as the cases described before, or in management processes, e.g. to provide evidence to define a strategy for the Chinese market. However, knowledge management theory looks to organizations from a perspective that is different from the BP concept. More precisely, this theory is epitomized by Nonaka s spiral [Nonaka 1991, 1995], that describes the cycle through which the knowledge is created in organizations. Therefore, Nonaka looks at organizations as knowledge processing organisms. Socialization Dialogue Externalization Internalization Combination Learning by doing Figure 44 Nonaka s spiral(redrawn from Nonaka 1991) 13.5 The Business Intelligence perspective Business Intelligence is a broad and rather vague term that embraces all systems that help management to better understand the business e.g. to profile customers in order to improve the service. Related technology was born in the Nineties and embraces a panoply of analysis oriented systems, as data warehouses and engines for reporting, data mining and statistical analysis. This technology computerize the data used by management need and has automated information intensive processes such as marketing. From our point of view, Business Intelligence is not a BP class, but a set of information tools that support management and operational processes. 14 Review questions Define the concepts of Business Architecture o Which are the domains of Enterprise Architecture o What is a Business Model o Define the main domains of Organization Model according to Galbraiths model Overall definition of Business Process o What is a business process (BP)? Copyright 2011 [email protected] - Draft for internal use- do not quote - 61 of 65

62 BUSINESS PROCESSES ARCHITECTURE o Identify the CRASO elements of a BP in your daily experience e.g. buying on internet, subscribing a magazine, enrolling to the university, asking a permit to a government office. Organization: o What is an organization structure? o What is an organization chart? What is an organization manual? o What is the relation between organization structure and business processes? o What is a functional BP? What is a intre- functional BP? What is an inter-organizational BP? BP modelling: o What is the purpose of BP modelling? How a BP can be modelled? o Hierarchical diagrams: what is their purpose? What are primitive operations of decomposition and specialization? What is an elementary activity? BP taxonomy and mapping: o What is the purpose of support, primary processes, and management BPs? o Explain the theoretical foundations of OFE (Overall Framework for the Enterprise) o Describe support BPs Describe HR management Explain IT services Business Processes o Describe management BPs Describe Anthony s map Describe the decision perspective o Describe primary BPs and Nolan s and Blumenthals frameworks GEF framework: o What are activity levels? Describe and exemplify the levels Planning, Control, Monitoring, Execution, Information Management o What a GEF grid represents? o Define and exemplify GEF steps SCOR framework: o Describe the structure of SCOR framework: Scope (which industrial sector is for, to which detail level does it go) How can a company use the SCOR framework? What MTS, MTO, ETO etc. means? Which are the functional domains of SCOR? Describe purpose and characteristics of SCOR analysis levels Top Configuration Process element Implementation o What best practice means? o Describe the SCOR analysis roadmap in terms of objectives and modeling approach typical to each analysis phase (Phase 1 to Phase 3) etom: Explain the architecture of etom framework: functional area, purpose, business chain Define and exemplify the following concepts o IT services o Relations between Business Services and IT Services o Physical Processes (CIM example) 15 Simple exercises Based on public information on Internet and other easy sources, model an end-to-end BP in these steps: 1. Sketch a CRASO diagram of the whole process Copyright 2011 [email protected] - Draft for internal use- do not quote - 62 of 65

63 BUSINESS PROCESSES ARCHITECTURE 2. Model the BP structure, by a hierarchical diagram, until you find elementary activities; for the sake of simplicity you can limit the decomposition by zooming only one second level process 3. Sketch the flow of the system, and show the lanes of actors; keep a lane for computerized activities; 4. Identify the activity levels of the BP by using the GEF taxonomy We suggest the following case studies: 1. Passport or Visa release (request to delivery) see Embassy or Immigration websites e.g. USA Visa Applications - Tourist, Business and Student Visas ( 2. Airline reservation (information to confirmation) see Airlines websites and aggregator websites e.g. edreams 3. Mobile phone subscription (request to activation): use your own experience or go to websites of telecommunication companies 4. Mortgage loans (request to delivery) see websites of banks e.g Healthcare (e.g. from application for a test to the interpretation of test results, or enrolment into the Healthcare system): use your experience, interview people and/or surf Government websites on healthcare e.g. Lombardia (Italy): Sweden: etc. 6. Enrolment in a school (application to confirmation): use your experience and / or visit University websites of Italy (e.g. Bocconi, Politecnico di Milano, Università di Pavia) Sweden (Upsala) USA (e.g. MIT, Harvard, Berkeley) China (e.g. Tongji, HIT, UESTC). 16 Acknowledegments Thanks to doctor Giovanni Pignatelli, who helped us in definitions and in the review of BP theory. 17 References [Allweyer 2009] Allweyer T., BPMN Introduction to the Standard for Business Process Modeling. BoD. ISBN [Anthony 1965] Anthony R.N., Planning and control systems: a framework for analysis, Boston, Division of Research, Harvard Graduate School of Business Administration, 1965 [Blumenthal 1969] Blumenthal S., Management Information Systems: a Framework for Analysis, Englewood Cliffs, New Jersey, 1969 [Bolstorff 2007] Bolstorff P., Rosenbaum R., Supply Chain Excellence: A Handbook for Dramatic Improvement Using the SCOR Model, 2nd edition, Amacom, 2007 [Briol 2009] Briol P., BPMN, the Business Process Modeling Notation Pocket Handbook. LuLu. ISBN [COBIT 2007] IT Governance Institute, COBIT 4.1. Framework, Control Objectives, Management Guidelines, Maturity Models. ISBN [Daft 2009] Daft R.L., Organization Theory and Design, Cengage Learning [Dearden 1972] Dearden J., MIS is a mirage, Harvard Business Review, January/February, [Debevoise 2008] Debevoise, Neilson T, et al. The MicroGuide to Process Modeling in BPMN. BookSurge Publishing. ISBN [Deming 1986 ] Deming W. E., Out of the Crisis, MIT Center for Advanced Engineering Study, 1986 [Eriksson & Penker 2000] Eriksson H.E., Penker M., Business Modeling With UML: Business Patterns at Work, Wiley, NY 2000 Copyright 2011 [email protected] - Draft for internal use- do not quote - 63 of 65

64 [Fowler, 2003] Fowler, Martin. UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd ed. ed.). Addison-Wesley. ISBN [Galbraith 2007] Kates, A., and Galbraith, J. R. (2007), Designing Your Organization: Using the Star Model to Solve Five Critical Design Challenges. San Francisco: Jossey-Bass, [Gartner 2002] McCoy D. W., Business Activity Monitoring: Calm Before the Storm, Gartner Research, April 2002 [Gorry & Scott-Morton 1971] Gorry G.A., Scott-Morton M.S., A framework for management information systems, Sloan Management Review, Vol.13, n.1,1971 [Grosskopf 2009] Grosskopf, Decker and Weske, The Process: Business Process Modeling using BPMN. Meghan Kiffer Press. ISBN [Hammer 1990] Hammer, M., "Reengineering Work: Don't Automate, Obliterate", Harvard Business Review, July/August, pp [Hathis & Jackson 2009] Mathis, Robert L., Jackson, John H., Human Resource Management, 13th edition, South-Western Cengage Learning [Herman 2003] Malone T.W., Crowston K., Herman G.A., Organizing Business Knowledge: The MIT Process Handbook, MIT Press, 2003 [Jacobson 1998] Jacobson, Ivar; Grady Booch; James Rumbaugh. The Unified Software Development Process. Addison Wesley Longman. ISBN [Kaplan 1992] Kaplan R. S., Norton D. P., The Balanced Scorecard Measures that Drive Performance, Harvard Business Review, n 1, January-February [Kaplan 1993] Kaplan R. S., Norton D. P., Putting the Balanced Scorecard to Work, Harvard Business Review, n 5, September-October [Kaplan 1996] Kaplan R. S., Norton D. P., Using the Balanced Scorecard as a Strategic Management System, Harvard Business Review, n1., January- February [Kaplan 2001] Kaplan R. S., Norton D. P., The Strategy-Focused Organization. How Balanced Scorecard companies thrive in the new business environment, Harvard Business School Press, Boston, 2001 [Kaplan 2004] Kaplan R. S., Norton D. P., Strategy Maps: Converting Intangible Assets into Tangible Outcomes, Harvard Business School Press, Boston 2004 [Kaplan 2008] Kaplan R. S., Norton D. P., The execution premium: linking strategy to operations for competitive advantage, Harvard Business School Press, Boston 2008 [Martin 2009] Martin, Robert Cecil (2003). UML for Java Programmers. Prentice Hall. ISBN [Minoli 2008] D Minoli. Enterprise Architecture A to Z. Frameworks, Business Process Modeling, SOA, and Infrastructure Technology. Auerbach Publications. Taylor & Francis Group. ISBN (Hardcover) [Motta 2006] Motta G., Capé C., Troiani F., Enabling IT-enabled business innovation: a new role for the Chief Information Officer, AICA 2006 and Advanced International Summer School on Innovation in the Extended Enterprise 5-8 July 2006 [Motta 2009] Bracchi G., Francalanci C. Motta G., Sistemi infornativi d impresa (= Enterprise Information Systems), McGrawHill, Milano, 2009 [Motta 2010] Motta G., Barroero T., Galvani F., Longo A., Managing the IT service level in large organizations: reference framework and a survey of actual practices, IBIMA 2011 [Motta 2011] Motta G., Barroero T., Galvani F., Longo A., IT Service Level Management: practices in large organizations, Communications of IBIMA [Motta 2012] The catchers in the rye: students model enterprise architectures, ItaiS 2012 [Nonaka 1995] Nonaka I., Takeuchi H., The Knowledge Creating Company, University Press, Oxford 1995 [Nonaka 1991] Nonaka I., The Knowledge Creating Company, Harvard Business Review, 69, Nov-Dec, pg [Nolan 1974] Nolan R.L., Gibson C., Managing the four stages of edp growth, Harvard Business Review, Vol.52, n.1, 1974 [Norton 1973] Norton D. Information Systems Centralization: the issues, in Mc Farlan W.F., Nolan R.L. ; Norton D. P. Information Systems Administration, Holt Rinehart & Winston, New York 1973 [Pacioli 1494] Pacioli L., Summa de arithmetica, geometria, proportioni, Venezia 1494 [Penker 2000] Penker, M. & Eriksson H. Business Modeling with UML. John Wiley & Sons. ISBN Copyright 2011 [email protected] - Draft for internal use- do not quote - 64 of 65

65 [Porter 1985] Porter M.E., Competitive advantage, Free Press, New York, NY 1985 [Ryan 2009] Ryan K. L. Ko, Stephen S. G. Lee, Eng Wah Lee, Business Process Management (BPM) Standards: A Survey. In: Business Process Management Journal, Emerald Group Publishing Limited. Volume 15 Issue 5. ISSN PDF [Schekkerman 2005 ] J. Schekkerman, Institute for Enterprise Architecture Developments (IFEAD). Trends in Enterprise Architecture. Reports of the Thirds Measurement, Edition 1.0, Suikerpeergaarde 4, 3824BC Amersfoort, The Netherlands. Dec 2005 [Scheer 2002] Scheer, A. W., ARIS. Vom Geschäftsprozeßzum Anwendungssystem. 4. Auflage, Springer, Berlin 2002, ISBN [Scheer 1999] Scheer, A. W.ARIS: Business Process Modeling, Springer Verlag, Berlin 1999 [Simon 1958] March, James G. and Simon, Herbert A. (1958), Organizations, John Wiley & Sons [Taylor 2007] M. Taylor, M. Iqbal, M. Nieves. ITIL v3. Service Strategy, Office of Government Commerce, 2007 [The Open Group 2009] The Open Group. TOGAF Version 9. The Open Group Architecture Framework. ISBN Document Number G091. Published by The Open Group, [Vise 2008] David A Vise, Mark Malseed, The Google Story: For Google's 10th Birthday, Bantam Doubleday Dell Publishing Group Inc, NY, NY, 2008 [White 2008] White, Stephen A, and Miers, Derek, BPMN Modeling and Reference Guide. Future Strategies Inc. ISBN Copyright 2011 [email protected] - Draft for internal use- do not quote - 65 of 65