innovation, coordination and collaboration in service

117
Innovation, Coordination and Collaboration in Service Driven Manufacturing Supply Chains Innovation, Coordination and Collaboration in Service Driven Manufacturing Supply Chains Deliverable Nr. DL 2.3 “As Is” Business Use Cases & Requirement Specification in the Service- Supply Chain domain for all the 4 business cases

Upload: others

Post on 19-Feb-2022

1 views

Category:

Documents


0 download

TRANSCRIPT

Innovation, Coordination and Collaboration in Service Driven Manufacturing Supply Chains

Innovation, Coordination and Collaboration in Service Driven Manufacturing Supply Chains

Deliverable Nr. DL 2.3

“As Is” Business Use Cases & Requirement

Specification in the Service-Supply Chain domain for all

the 4 business cases

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 1

Project Number STRP-017192

Project Acronym InCoCo-S

Instrument STREP

Thematic Priority Priority NMP No. 3

Deliverable Nr. 2.3

Deliverable Name “As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain for all the 4 business cases

Responsible Organization POLIMI

Author(s) Marco Montorio

Contribution(s) POLIMI, COMAU, ETHZ, SIGPACK, FIR, SKF, VENTANA, UNITECH, TECHIND, ADIGE

Estimated person months 28

Actual Date of Delivery to EC PM10

Contractual Date of Delivery to EC PM10

Dissemination Level Public

Nature R

Type of Release Version Final

Peer Reviewers (Name and Affiliation) Reviewer’s name, INM Reviewer’s name, SKF Reviewer’s name, HSG

Peer Review Status ☺ Final Version Approved by WPL

Date of Final Approval by WPL 11-07-06

Version Comments, Changes, Status Contributions by

1.0 POLIMI, COMAU, ETHZ, SIGPACK, FIR, SKF, VENTANA, UNITECH, TECHIND

2.0 D2.3 Review Meeting (27 June 2006, in Milan)

POLIMI, ETHZ, SIGPACK, HSG, COMAU, SKF, ADIGE, TECHIND, INM

3.0 2nd Review POLIMI, INM, SKF, HSG, VENTANA, H2O

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 2

Table of Contents

1 Introduction........................................................................................................................7

1.1 Aim of the deliverable ...............................................................................................7

1.2 Scope of the analysis..................................................................................................8

1.3 Structure of the deliverable........................................................................................9

1.4 Connections with other InCoCo-S deliverables.........................................................9

2 Nomenclature...................................................................................................................10

3 Case Study 1: SIGPACK .................................................................................................10

3.1 Executive Summary .................................................................................................10

3.2 Starting position .......................................................................................................11

3.3 Description of the service ........................................................................................11

3.4 “Movie” of the typical situation...............................................................................12

3.5 Performance measured.............................................................................................14

3.6 Information required from the customer..................................................................15

3.7 Coordination need with customer / supplier's production activities ........................15

3.8 Coordination tools currently used............................................................................16

3.9 Criticalities perceived ..............................................................................................16

3.10 Link with the proposal business case.......................................................................16

3.11 Examples of problematic situations .........................................................................17

3.12 Currently unsatisfied customer requirements ..........................................................17

3.13 Definition of the requirements .................................................................................17

4 Business case 2: COMAU ...............................................................................................18

4.1 AS-IS situation.........................................................................................................18

4.1.1 Company portrait - Description of the typical customer .................................18

4.1.2 Description of the service ................................................................................20

4.1.3 “Movie” of the typical situation.......................................................................21

4.1.4 Performance measured.....................................................................................27

4.1.5 Information given to the customer...................................................................30

4.1.6 Information required from the customer..........................................................30

4.1.7 Coordination need with customer production activities ..................................31

4.1.8 Coordination tools presently used....................................................................31

4.1.9 Criticalities perceived ......................................................................................32

4.1.10 Link with the proposal business case...............................................................33

4.1.11 Examples of problematic situations .................................................................33

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 3

4.1.12 Currently unsatisfied customer requirements ..................................................33

4.1.13 Business processes description ........................................................................34

4.2 TO-BE situation .......................................................................................................37

4.2.1 Description of the typical customer .................................................................37

4.2.2 Description of the service ................................................................................38

4.2.3 “Movie” of the typical situation.......................................................................38

4.2.4 Performance measured.....................................................................................39

4.2.5 Information given to the customer...................................................................39

4.2.6 Information required from the customer..........................................................40

4.2.7 Coordination need with customer production activities ..................................40

4.2.8 Criticalities perceived ......................................................................................40

4.2.9 Currently unsatisfied customer requirements ..................................................40

4.2.10 Business processes description ........................................................................40

4.3 Definition of the requirements .................................................................................48

4.3.1 Business processes ...........................................................................................49

4.3.2 Measures of performance.................................................................................49

4.3.3 Coordination mechanism and Information system ..........................................49

4.3.4 Requirements summary ...................................................................................51

5 Business case 3: SKF.......................................................................................................52

5.1 AS-IS situation.........................................................................................................52

5.1.1 Company portrait - Description of the typical customer .................................52

5.1.2 Description of the service ................................................................................53

5.1.3 “Movie” of the typical situation.......................................................................53

5.1.4 Performance measured.....................................................................................57

5.1.5 Information given to the customer...................................................................58

5.1.6 Information required from the customer..........................................................58

5.1.7 Coordination need with customer production activities (how frequent, what for, how difficult, etc.) .....................................................................................................58

5.1.8 Coordination tools presently used....................................................................59

5.1.9 Criticalities perceived ......................................................................................59

5.1.10 Examples of problematic situations .................................................................59

5.1.11 Currently unsatisfied customer requirements ..................................................59

5.1.12 Business process description............................................................................60

5.2 TO-BE situation .......................................................................................................65

5.2.1 Description of the typical customer .................................................................65

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 4

5.2.2 Description of the service ................................................................................65

5.2.3 “Movie” of the typical situation.......................................................................65

5.2.4 Performance measured.....................................................................................66

5.2.5 Information given to the customer...................................................................66

5.2.6 Information required from the customer..........................................................66

5.2.7 Coordination need with customer production activities ..................................67

5.2.8 Coordination tools presently used....................................................................67

5.2.9 Criticalities perceived ......................................................................................67

5.2.10 Examples of problematic situations .................................................................68

5.2.11 Currently unsatisfied customer requirements ..................................................69

5.2.12 Business processes description ........................................................................69

5.3 Definition of the requirements .................................................................................69

5.3.1 Business Processes...........................................................................................70

5.3.2 Measures of Performance ................................................................................72

5.3.3 Coordination Mechanism and Information System .........................................72

5.3.4 Requirements Summary...................................................................................75

5.3.5 Conclusion .......................................................................................................76

6 Business case 4: SIGPACK .............................................................................................77

6.1 AS-IS situation.........................................................................................................77

6.1.1 Company Portrait - Description of the typical customer .................................77

6.1.2 Description of the service ................................................................................78

6.1.3 “Movie” of the typical situation.......................................................................80

6.1.4 Performance measured.....................................................................................82

6.1.5 Information given to the customer...................................................................85

6.1.6 Information required from the customer..........................................................86

6.1.7 Coordination need with customer production activities ..................................86

6.1.8 Coordination tools currently used....................................................................86

6.1.9 Criticalities perceived ......................................................................................87

6.1.10 Link with the proposal business case...............................................................87

6.1.11 Examples of problematic situations .................................................................87

6.1.12 Currently unsatisfied customer requirements ..................................................87

6.1.13 Business processes description ........................................................................88

6.2 TO-BE situation .......................................................................................................90

6.2.1 Description of the typical customer .................................................................90

6.2.2 Description of the service ................................................................................91

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 5

6.2.3 “Movie” of the typical situation.......................................................................91

6.2.4 Performance measured.....................................................................................93

6.2.5 Information given to the customer...................................................................93

6.2.6 Information required from the customer..........................................................94

6.2.7 Coordination need with customer production activities ..................................94

6.2.8 Coordination tools in future scenario used ......................................................94

6.2.9 Criticalities perceived ......................................................................................94

6.2.10 Link with the proposal business case...............................................................95

6.2.11 Examples of probable problematic situations ..................................................95

6.2.12 Unsatisfied customer requirements..................................................................95

6.2.13 Business processes description ........................................................................96

6.3 Definition of the requirements ...............................................................................105

6.3.1 Business Processes.........................................................................................106

6.3.2 Performance measures ...................................................................................106

6.3.3 Coordination mechanisms..............................................................................106

6.3.4 Information Systems ......................................................................................106

6.3.5 Requirements Summary.................................................................................108

7 Key requirements ...........................................................................................................108

7.1 Business processes .................................................................................................109

7.2 Measures of performance.......................................................................................110

7.3 Coordination mechanisms and information systems .............................................111

7.4 Summary of common key requirements from the InCoCo-S Business Cases.......112

7.5 Peculiar requirements from BC 4 ..........................................................................113

8 Common constraints ......................................................................................................113

9 Additional requirements from SMEs .............................................................................114

10 Requirements from the InCoCo-S Surveys................................................................115

Annex 1 – Acronyms .............................................................................................................116

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 6

List of Figures

FIGURE 1 SCOPE OF INCOCO-S ............................................................................................................................... 8 FIGURE 2 BUSINESS CASES OF INDUSTRIAL PARTNERS IN INCOCO-S....................................................................... 9 FIGURE 3 LEVEL 1 OF INCOCO-S MODEL .............................................................................................................. 10 FIGURE 4 EXAMPLE OF SIGPACK SUPPLY CHAIN AND THE COLLABORATION PLATFORM....................................... 12 FIGURE 5 QUALITY PERFORMANCE CHART OF SELECTED HUNGARIAN SUPPLIERS................................................. 15 FIGURE 6 COMAU GROUP ...................................................................................................................................... 19 FIGURE 7 ORDER ACQUISITION SPLIT IN SECTORS.................................................................................................. 19 FIGURE 8 COMAU GROUP ORGANIZATIONAL CHART ............................................................................................. 19 FIGURE 9 COMAU SERVICE PRODUCTS .................................................................................................................. 20 FIGURE 10 SERVICES SPLIT IN PERCENTAGE .......................................................................................................... 20 FIGURE 11 MAINTENANCE ENGINEERING ACTIVITIES ............................................................................................ 21 FIGURE 12 MOVIE OF THE TYPICAL SITUATION...................................................................................................... 26 FIGURE 13 BONUS-MALUS SYSTEM .................................................................................................................. 28 FIGURE 14 EXAMPLE OF CUSTOMER SATISFACTION SURVEY CARRIED ON BY COMAU (A)................................... 28 FIGURE 15 EXAMPLE OF CUSTOMER SATISFACTION SURVEY CARRIED ON BY COMAU (B)................................... 29 FIGURE 16 MANPOWER UTILIZATION ACCORDING TO TYPE OF MAINTENANCE ...................................................... 29 FIGURE 17 FEEDBACK OF INFORMATION TO THE CUSTOMER ................................................................................. 30 FIGURE 18 DESIRED FLOW OF INFORMATION AND DATA........................................................................................ 32 FIGURE 19 FROM THE AS-IS TO THE TO-BE SERVICE........................................................................................... 38 FIGURE 20 TECHNICAL DATA OF MACHINERIES ..................................................................................................... 50 FIGURE 21 YEARLY PLANNED MAINTENANCE PLAN .............................................................................................. 51 FIGURE 22 WEEKLY PLANNED MAINTENANCE ACTIVITIES .................................................................................... 51 FIGURE 23 FROM THE AS-IS TO THE TO-BE SERVICE........................................................................................... 65 FIGURE 24 FLEXIBLE SERVICE ORIENTED ARCHITECTURE ..................................................................................... 70 FIGURE 25 PLUGGABLE SOLUTION FOR SKF AND CUSTOMER IT SYSTEMS INTEGRATION...................................... 73 FIGURE 26 INTERFACE BETWEEN AND ERP AND A CRM APPLICATION ................................................................. 74 FIGURE 27: INFORMATION EXCHANGE BETWEEN SKF, ITS CLIENTS AND MAINTENANCE SERVICE PROVIDERS ...... 75 FIGURE 28 SKF SERVICE DIVISION – CUSTOMER INTERFACE................................................................................ 76 FIGURE 29 ORGANISATION OF SERVICE BUSINESS UNIT (SBCC).......................................................................... 77 FIGURE 30 SERVICE BUSINESS MODEL OF BOSCH PACKAGING SERVICES .............................................................. 78 FIGURE 31 COORDINATION OF SERVICES AT BOSCH PACKAGING SERVICES.......................................................... 79 FIGURE 32: SERVICES OFFERED BY SIGPACK SERVICES......................................................................................... 79 FIGURE 33 PRICING PROCESS FOR SERVICES AT SIGPACK SERVICES................................................................ 80 FIGURE 34 EXAMPLE OF LOGISTICAL COCKPITS..................................................................................................... 83 FIGURE 35 OVERVIEW OF KPIS MEASURED IN THE SPARE PARTS DELIVERY PROCESS ........................................... 85 FIGURE 36 INFORMATION GIVEN TO THE CUSTOMER VIA THE E-PORTAL............................................................... 85 FIGURE 37 GLOBAL STOCK AVAILABILITY IS SHOWN FOR ALL PARTS ON E-PORTAL ............................................. 86 FIGURE 38 AS-IS BUSINESS PROCESSES OPERATE WITH REGARDS TO SCOR..................................................... 90 FIGURE 39 FROM THE AS-IS TO THE TO-BE SERVICE........................................................................................... 91 FIGURE 40 EXAMPLE OF BUSINESS PROCESS ALIGNMENT EXTRACTED FROM THE SKF BUSINESS CASE ............... 109 FIGURE 41 EXAMPLE OF EARLY STAGE DEFINITION OF MAINTENANCE POLICIES AND PERFORMANCE MEASURES

EXTRACTED FROM COMAU BUSINESS CASE ............................................................................................. 110 FIGURE 42 EXAMPLES OF DIFFERENT KPIS EXTRACTED FROM THE INCOCO-S BUSINESS CASES......................... 111 FIGURE 43 EXAMPLE OF “PLUG AND OPERATE” SOLUTION EXTRACTED FROM THE SKF BUSINESS CASE ............. 112

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 7

1 Introduction Despite the strong dependence of European manufacturing industry on external services, service providers and customers are facing tremendous problems in integrating and synchronizing the business processes and facilitating collaboration. Proven concepts, tools and best practices to solve these problems yet are not available. The final goal of InCoCo-S is to develop a set of methods to improve the overall performance of production systems through synchronized and well coordinated integration of the different supporting services into supply chains. In particular InCoCo-S pursues its goal through enabling coordination by synchronisation of business processes and information, developing measures of performance addressing joint activities in a business service provision context, providing solutions for supporting decision making and, finally, developing standards for the service sector via a Service Oriented Reference Model. With these objectives in mind, two surveys initially were conducted in order to analyse the current status, trends and expectations concerning the coordination and integration between business related services and the manufacturing supply chain. The two surveys addressed both the service providers on the one hand and the manufacturing companies on the other.1 The surveys highlighted some key requirements which represent crucial inputs for InCoCo-S. In particular the respondents pointed out the importance of:

• The development of a service oriented reference model which will integrate and standardize new coordination procedures, performance metrics and decision support systems.

• The development of “coordination concepts” or “best practices” in order to integrate the planning of manufacturers and service providers.

• The development of standards in the following domains: Key Performance Indicators, Business Processes and Information Exchange in order to facilitate a close collaboration between manufacturers and service providers.

All these will support the synchronization, coordination and integration of the different business services into supply chains and tackle the issues and weaknesses pointed out by the manufacturing companies and service providers which took part in the surveys. In a second phase of the requirement analysis carried on within the framework of the InCoCo-S project, in order to investigate more in depth the AS-IS situation in service supply chain management, the desired TO-BE situation, and consequently the requirements and present deficiencies, a number of business cases have been designed in parallel, addressing different and complementary typologies of business services. The companies involved in the business cases are: COMAU (with its customer Adige), SKF and BOSCH (Sigpack). The present deliverable intends to summarise the results of the business cases developed.

1.1 Aim of the deliverable While the surveys represented a first step within the InCoCo-S work plan which intended to provide a holistic picture of the present integration level between service providers and manufacturing organisations, the business cases intend to further analyse the issue and to identify and define the key interaction processes between service providers and the supply chain under consideration.

1 For more information on the InCoCo-S Surveys please refer to Deliverable 2.1 – Consolidated Supply Chain & Service Providers Survey Results.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 8

Based on the AS-IS analysis and on the definition of TO-BE scenarios, key requirements of the different business cases are developed in three different dimensions and including service operating cost aspects for the different business cases:

• Coordination mechanisms in the relevant business domain; • Measures of Performance; • Information systems used by the different partners.

In the following stages of the InCoCo-S project, based on business use cases, realistic supply chain models incorporating service provider’s interfaces will be built, encompassing detailed processes across the organizations, suppliers & service partners. Moreover the information gathered in terms of the three dimensions listed above will represent the foundation for the development of the S-SCOR Framework.

1.2 Scope of the analysis The business cases developed in the framework of InCoCo-S focus on those services which are process dependent2 and are associated to the primary processes of a manufacturing supply chain: Source, Make and Deliver3. Each of these phases may indeed outsource some services which are necessary to facilitate the flow of material and production of products. Typical examples are:

• For the Source phase: quality control services, inbound logistics management, maintenance of the inbound logistics assets, etc.

• For the Make phase: maintenance of machines, in-process quality control, outsourcing of production phases, etc.

• For the Deliver phase: quality control of outgoing products, maintenance of the transportation systems from the warehouse to the various distribution centres, warehouse management, etc.

Figure 1 Scope of InCoCo-S

2 Process depend services (e.g.: logistics, maintenance, quality control…) assist in creating or offering the product or service, while on the contrary process independent services (e.g.: facility management, training, administrative services…) support the business functions but do not add any value to product or service. For a definition of service and for more information on service classification please refer to Deliverable 2.6 – Development of reference framework. 3 The Supply Chain Operational Reference (SCOR) identifies five primary management processes in the supply chain: Source, Make, Deliver, and Return, which are all coordinated by a Plan phase.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 9

In particular within the InCoCo-S project, one case study has been realized on inbound quality control and three business cases have been carried on covering different maintenance and outbound packaging service.

Figure 2 Business cases of industrial partners in InCoCo-S

The choice of the scope of analysis for the business cases is driven by the strategic importance of these processes for a company, as they have a direct impact on the value adding processes. Indeed, directly impacting on the value chain of the company these business related services contribute significantly to the overall performance of the company in a greater context.

1.3 Structure of the deliverable The deliverable is articulated in three main parts:

• An AS-IS analysis, which identifies the current practices in service supply chain management for each specific case, through analysing business processes, information exchanges and the measures of performance adopted.

• A TO-BE analysis, where a desired scenario is described following a structure similar

to that used for the AS-IS situation.

• A requirement analysis, where the requisites necessary to move from the AS-IS to the TO-BE scenario are identified and presented.

A final paragraph tries to identify common features and specifications in terms of identified requirements for each business case providing thus a holistic view which, together with the results coming from the surveys, will represent the starting point for the InCoCo-S project for the development of novel supply chain models integrating and synchronising services into the supply chain.

1.4 Connections with other InCoCo-S deliverables The results presented in Deliverable 2.3 must be considered in connection with the outputs described in Deliverable 2.1 - Consolidated Supply Chain & Service Providers Survey Results. While the latter present an overall view on state of the art and state of the practice, criticalities, trends and expectations in service – manufacturing supply chain integration and coordination, the first one presents an in-depth analysis of the issue through detailed business cases. Together D2.1 and D2.3 constitute the core of the requirements analysis-phase of InCoCo-S and represent, therefore, the basis for all the later work carried on within the project.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 10

2 Nomenclature

The nomenclature introduced within InCoCo-S and used in this deliverable for the modelling and description of business processes reflects the one used in the SCOR model.

SCOR foresees the existence of five different management processes; PLAN, SOURCE, MAKE, DELIVER and RETURN, and three process types; PLANNING, EXECUTION and ENABLE.

In parallel the InCoCo-S model articulates the following business processes; ADAPT, BUILD, OPERATE; classified according to the following process types; PLAN, EXECUTE and SUPPORT.

• During the ADAPT phase the service provision solution, taken from an existing service portfolio, is customized by the service provider according to the customer needs.

• During the BUILD phase all the hardware, software and related structures are set-up in order to enable the service provision.

• During the OPERATE phase the service provision is practiced on a day-by-day basis.

The following picture represents the InCoCo-S model at level 1.

Figure 3 Level 1 of InCoCo-S model

3 Case Study 1: SIGPACK

3.1 Executive Summary Bosch Packaging Technologies is a division of the Robert Bosch GmbH group. It operates world wide, has more than 5000 employees, and develops packaging solutions for a wide spectra of products; food, health- and pharmaceutical products as well as non-food products. Today Bosch Packaging Technology group consists of 11 independent packaging machine producers, divided in the business units packaging systems and packaging machines. In addition they have one service business unit, Sigpack Services. Five of the 11 producing

Manufacturer

Build Operate

Plan Control

Plan Interact

Plan Outsource

Service Provider

Plan Operate

Plan Build

Plan Adapt

Outsource Interact Control 1 4 6

3 5 Adapt

2

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 11

companies formerly belonged to the Swiss company Sigpack AG, but were bought up by the Bosch Packaging Technology group in 2004.

Sigpack packaging machines have always been known for their high level of quality, superior operational safety and reliable service in continuous operations. With globalization, Sigpack set up spares suppliers in low cost countries thus creating requirements to integrate these companies in regards to Sigpack’s high level quality standards. Sigpack is providing inbound quality control services to various manufacturing organizations with greater focus on making these services available to the SMEs especially in the Eastern part of Europe.

The upcoming market trend shows that there are tremendous business opportunities to provide such inbound/ outbound services especially to SMEs. This requirement has spawned a demand for a quality control IT- platform which could be driven by Sigpack specialized on supply chain companies whose work is to untangle technical and logistical inconsistencies. Within the InCoCo-S project Sigpack could experiment on providing inbound quality services to the SMEs and discover the requirements to enable these services in an integrated manner.

Especially for smaller companies in Eastern Europe Sigpack would like to improve a framework with the proper matrix of performance standards, targets, monitoring mechanism and risk identifiers that result in an environment of true cooperation. In this environment an inbound service provider and Sigpack can better address all the important logistical improvement opportunities with tools that help both of them create, access and share critical performance information. The challenge of sourcing spare parts from Eastern Europe can be met by establishing a collaboration relationship where both partners can learn the business activities and be more sensitive to issues that will impact cost, service, quality and inventory accuracy.

In this Case study the inbound quality control system at Sigpack AG is described considering an example among Hungarian suppliers. The organizational structure is guaranteeing the high quality standards given by Sigpack AG.

This kind of organization with a collaboration platform is principally open for providing especially quality services for other companies interested in setting up or enhancing production networks in Eastern Europe.

3.2 Starting position The sourcing strategy of Sigpack is characterized by choosing suppliers on a long term basis where quality is sufficient, primarily according to the lowest prices. Low cost suppliers in the eastern part of Europe are , in the main, not certificated based on international standards. For this reason Sigpack has established a cooperation platform for the Hungarian market bridging the gap between Sigpack in Switzerland and, to date, 12 small and medium sized Hungarian suppliers. With the help of Sigpack representatives in Hungary, Sigpack is able to build trust and to establish principal legal relationships. Furthermore products and processes are introduced on a more technical level and order processing is done through the platform on the operational level.

3.3 Description of the service Especially for smaller companies in Eastern Europe Sigpack would like to improve a framework with the proper matrix of performance standards, targets, monitoring mechanism and risk identifiers that result in an environment of true cooperation. In this environment inbound service provider and Sigpack can better address all the important logistical improvement opportunities with tools that help both of them create, access and share critical

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 12

performance information. The challenge of sourcing spare parts from Eastern Europe can be met by establishing a collaboration platform where both partners can learn the business activities and be more sensitive to issues that will impact cost, service, quality and inventory accuracy.

Figure 4 shows an example of Sigpack's supply chain and illustrates the function of the collaboration platform as Sigpack's representation in Hungary.

SIG Pack Services, UK

SIG Pack Systems,Beringen

SIG Pack Services,Neuhausen

Kraft, UK

spare partorder

INMDebrecen

spare partraw material

Customer

Service Hub

SIG Pack Systems

1st Tier Supplier

Hungariancollaboration platform

Informationexchange channel

Figure 4 Example of Sigpack Supply Chain and the collaboration platform

3.4 “Movie” of the typical situation Principally Sigpack is interested in building up long-term relationships with their suppliers based on trust and reliability. The temporal stability of such relations is guaranteed if all of the partners perceive the situation as “win-win". Achieving this kind of win-win situation has been the guiding principle in designing and operating the collaboration platform in Hungary.

Nowadays 5 Sigpack representatives are working full time for this platform in Hungary always keeping in touch with 12 small and medium sized suppliers of Sigpack in Switzerland. Sigpack serves various information regarding technical and logistical issues through the collaboration platform, e.g. drawings for specialized parts, samples and detailed descriptions (material and production process) for the setup of tools. In connection with the preparation of a production order (customized parts, small batch sizes) mechanics from the service provider visit the supplier for the transfer of essential input. Especially so called “hidden standards” and company specific names can lead to crucial problems in regards to the product quality.

In general, the supplier is responsible for meeting the customer quality specification.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 13

Customer

(Sigpack)

Service Provider

(Operator Hungarian platform)

Suppliers

(Hungarian companies)

ADAPT PHASE

First contact between Customer and Service Provider.

Specification of general requirements (e.g. quality level) and business targets (savings) towards Service Provider.

Set up of contract between customer and service provider stating desired products, quantity and delivery due date.

BUILD PHASE

Based on technical product profiles identification, evaluation, selection and choice of potential low cost suppliers in specific market regions.

Negotiation and alignment of conditions of collaboration.

Set up of contracts and agreements between Service Provider and supplier with special focus on quality issues.

Transfer of customer requirements (parts specific) to supplier.

Set up measuring and test equipment based on customer requirements.

Service Provider certification programs (audits)

Supplier certification programs (sample production & quality check).

Action guidelines, structures and processes are developed jointly to set up coordinated network activities.

OPERATE PHASE

Take samples sporadically.

Quality audits on a regular basis, checking of various relevant KPIs.

Transfer and allocation of orders from Sigpack to Hungarian suppliers.

Alignment of desired and available capacity in the suppliers production lines.

In order to control the quality of the supplier, the Service provider has access to production facilities. Both parties mutually improve quality by sorting out problems corporately at the suppliers company.

Sharing mutual knowledge of problems concerning quality

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 14

Customer

(Sigpack)

Service Provider

(Operator Hungarian platform)

Suppliers

(Hungarian companies) defects, production processes, packing and shipping

Periodic meetings giving attention to introduction of new products (order profiles), modifications and continuous improvement.

Processing of defect parts: decision if corrections could be made by Sigpack in Switzerland or if the parts need to be sent back to the supplier. Report of relevant KPIs (scrap rate, complaint rate, service level, delivery reliability rate)

Product defects are marked in the mechanical drawings and sent back to supplier

Collecting and visualization of quality control reports. Reports are disseminated to suppliers and customer

Discussion and problem solving process at the suppliers production site (relationship management)

Supporting supplier in processes he has problems with (e.g. order processing, order of raw material).

Takeover of processes the supplier cannot fulfill.

Calibrating test equipment (every 2 years)

3.5 Performance measured The Service provider (platform) in Hungary is currently operating with the following set of performance measures to guarantee high quality products shipped to Sigpack in Switzerland.

Part not deburred Missing finishing

Part not numbered Part not according to drawing

Borehole not in tolerance Part bended

Outer diameter not in tolerance Part damaged during transport

Outer winding not correct Part without shipping documents

Inner winding not correct Shipping documents without parts

Admeasurements not in tolerance Shipping documents not correct

Missing treatment Incorrect amount of parts

Incorrect material Incorrect drawing

Incorrect order Part wrongly assembled

Table 1 Overview of Quality Performance Measures The measures in general are not taken as ratios, but only in numbers of incidents. The only ratio is the error rate, i.e. the total number of errors divided by the number of order positions.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 15

Figure 5 shows an overview of quality performance measures of some Hungarian suppliers as an example. INM, as a representative of small companies in Hungary (9 people engaged) in the InCoCo-S project is listed on 4th position.

0

10

20

30

40

50

60

70

80

# of errors

Supplier #1 Supplier #2 Supplier #3 INMSupplier

Part wrongly assembledIncorrect orderIncorrect drawingIncorrect materialIncorrect amount of partsShipping documents not correctShipping documents without partsPart without shipping documentsPart damaged during transportPart bendedPart not according to drawingMissing finishingMissing treatmentAdmeasurement not in toleranceInner winding not correctOuter winding not correctOuter diameter not in toleranceBorehole not in tolerancePart not numberedPart not deburred

Figure 5 Quality performance chart of selected Hungarian suppliers

3.6 Information required from the customer In order to provide the right quality to the customer, the service provider has to know what the right quality is. To achieve this goal, several measures are taken. The most important element is the technical drawing and specification. Comprehensive descriptions are collected from the customer, consisting of the drawing and a description of material and production process, as well as guides for the numbering. In most cases a sample is also collected from the customer. The specification not only contains the material and production process for the part, but also requirements on the quality, e.g. in terms of hardness and dimensions.

Other information required from the customer is an estimation of order quantities and requirements on the delivery process in terms of documentation and delivery dates.

3.7 Coordination need with customer / supplier's production activities The basic coordination need in the presented service setup is the need to align and coordinate capacities of the different suppliers. The service provider gets an order from his customer, filters them and forwards the orders to the appropriate supplier. For this purpose he has capacity and competence profiles of all the suppliers, supporting him in the decision of whom to forward which parts orders.

Another coordination need is the balance of quality requirements. The different Hungarian suppliers have different competences in terms of the potential quality level to be achieved. So the service provider needs to communicate and probably also negotiate the requested quality level from the customer. The normal way, however, is that the service provider supports the supplier in achieving the requested quality level in terms of production process and material handling.

For the support of the coordination of the suppliers basic conditions are agreed on, which have to be negotiated in advance. These conditions contain, ceteris paribus, delivery dates, long-term production quantities and quality levels.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 16

In the case of product modifications by the customer, the service provider needs to inform and probably train the particular suppliers about these modifications.

Last, but not least, there is the need to discuss and support the suppliers with regards to quality defects, meaning that the service provider provides detailed information about the error of the supplier. For example, the return of a part complete with a drawing in which the area where the error occurred is marked, and suggestions of what to change at the supplier's production process.

3.8 Coordination tools currently used Because in this scenario only small suppliers are involved, only traditional means of communication and coordination are used, meaning phone and fax, plus common Microsoft Office applications.

3.9 Criticalities perceived When dealing with the inbound quality control, the service provider, i.e. the Hungarian Collaboration Platform, faces criticalities in the following areas:

Business processes and coordination mechanisms

• Technical specifications of ordered products are not always followed correctly (hidden standards might be found in the drawings, or the wrong material is used).

• Lack of transparency of order transaction.

• Different understanding of capacity planning (different productivity levels!) and missing knowledge about work centre efficiency and capacity utilization.

• Differences regarding mentality between eastern and western part of Europe in terms of business behaviour (e.g. dealing with deadlines and "hit lists").

Information systems

• The suppliers usually are SMEs and therefore have limited budget for supporting IT infrastructure.

Performance measures

• In collaboration with small suppliers the KPIs need to be very low level, because the understanding of complex performance measures is not necessarily available.

3.10 Link with the proposal business case In the development of the “TO-BE” scenario this case study fully matches the description of the BC I from Annex 1. With globalization, Sigpack set up spares suppliers in low cost countries thus creating requirements to integrate these companies in regards to Sigpack’s high level quality standards. Sigpack is providing inbound quality control services to various manufacturing organizations with greater focus on making these services available to the SMEs. This requirement has spawned a demand for a quality control IT- platform which could be driven by Sigpack specialized on supply chain companies whose work is to untangle technical and logistical inconsistencies. Within the InCoCo-S project Sigpack could experiment on providing inbound quality services to the SMEs and discover the requirements to enable these services in an integrated manner.

In addition, inbound services (quality and internal logistics) metrics prevent a pure cost focus which can result in adverse effects on quality and customer satisfaction on the “deliver" side. In this manner Sigpack can focus on developing new collaboration methods to ensure that the

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 17

new business processes and information systems meet the requirements for enabling collaboration relationship in this intercultural domain.

3.11 Examples of problematic situations Referring to the criticalities perceived there are some example situations illustrating the presented problematic situations:

• It sometimes happens that the supplier delivers a part which is made from the wrong material. This is mainly due to the fact that some material is not easy to get, especially as a SME with small order quantities, and so the supplier supposes that a different material would serve as well as the specified material. In this case the service provider has to ask the supplier to produce the part again, probably with his support in terms of ordering the right material from his position as bigger company with higher order volumes.

• When a potential supplier is asked to produce a sample in order to check the quality of his produced parts, it already happened that the supplier provides a wrong part only because he misunderstood the requirements. Taking this into account, the service provider has to allow for a feedback phase after the sample delivery to check and probably align this understanding.

• Because the customer produced his part on his own behalf for decades, there is the danger of hidden standards and company specific names in the technical specification. In this case the supplier cannot understand the requirements correctly without the support of the service provider, sometimes even without the support of the customer himself.

3.12 Currently unsatisfied customer requirements In case the supplier has not achieved the quality level required by the customer, the service provider collects feedback from the customer whether he reworks the particular parts on his own behalf or whether it should be sent back to the customer. This is not the optimal setup and the goal should be that the suppliers meet the right quality level at the first instance.

3.13 Definition of the requirements Summarizing what needs to be done to facilitate a long-term cooperation with suppliers especially in regards to the quality assurance this section shows some basic requirements structured by General prerequisites, Business Processes, Measure of Performance, Coordination mechanisms and Information systems.

General prerequisites (not within the scope of the project, but critical success factors for such kind of setup)

• Building up the necessary mentality for a mutual “win-win” situation

• Openness to suggestions from external and internal network participants

• Orientation towards procedures and value-adding tasks

Business Processes

• Transparent and clearly structured processes between all three players (e.g. clear work flow and responsibility in case of incorrect order fulfilments or defect parts)

• Delivery procedures (normal and rush), batch size and packaging, responsibility and cost distribution for warehousing.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 18

Performance measures

• Performance indicators and improvement goals with regard to costs, delivery, and especially to quality

Coordination mechanisms

• Defined set of information relevant for parts supply in terms of character and quality, in order to support the integration of potential suppliers

• Easy and clear mechanism for the alignment and coordination of capacities between customer and supplier through service provider, using capacity and load profiles of suppliers

• Mechanism for the assignment of the customer's orders to (several) suppliers (set of rules and priorities)

Information Systems

• Basic IT-tool to control and coordinate target dates and capacities of several suppliers

4 Business case 2: COMAU

4.1 AS-IS situation

4.1.1 Company portrait - Description of the typical customer Comau is a global supplier of industrial automation systems for the automotive manufacturing sector and a global provider of full maintenance services. To the automotive customers worldwide, Comau offers its proficiency as System Integrator and its complete engineering solutions, from product development to manufacturing, from assistance to the production start-up phases, up to equipment and plant full maintenance activities. Comau product range comprises:

• Engineering • Injection Moulds • Dies • Body Welding, Assembly & Final Assembly Systems • Robotics • Powertrain Systems (Metal cutting & Mechanical Assembly) • Maintenance & Engineering Services

Comau Service, now part of the Business Unit Comau Robotics & Service of Comau S.p.A., is fully dedicated to industrial equipment maintenance.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 19

Figure 6 Comau Group

Figure 7 Order acquisition split in sectors

The following figure shows the organizational structure of the Service and Systems Business Units.

Figure 8 Comau Group organizational chart

Comau Systems: order acquisition 2005 = 1210 Mio €

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 20

4.1.2 Description of the service

Comau S.p.A. Comau Robotics and Service is a Business Unit of Comau S.p.A. with the mission of contributing to the production industry giving:

• Maintenance engineering. • Maintenance services. • Industrial facility management.

The services offered by Comau Service are part of the main aspects of the productive process of its customers because they impact on productivity, quality and safety.

Figure 9 Comau Service products The services offered by Comau can be briefly summarized in the following two pictures where the first one shows the different packages offered and the second one the related percentage.

Figure 10 Services split in percentage

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 21

The nature of the service Comau Service offers its services both as a global service and as special purpose activities. By the term “global service” is meant that the customer outsources all the activities signed in the contract including manpower and resources. Outsourcing is defined as the management and/or day-to-day execution of an entire business function by a third party service provider.

Figure 11 Maintenance engineering activities

• Improvement projects – with mutual share on economic results. • Maintenance data technical analysis: MTTR-MTBF; thermography analysis,

vibrational analysis, etc. • Materials management – Spare parts warehouse optimization (SAP system) and

bigger economy of scale due to Comau market recognition. • Maintenance Training. • Workforce increase availability on request of part time support manpower from other

CS sites. • Unique supplier for facility management problems.

4.1.3 “Movie” of the typical situation For a better understanding of Comau reality, it is possible to split the service in two different stages: one regards the approach with future customers, while the other concerns the daily running of the contract. A description of the movie of a typical difficult situation follows.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 22

Customer COMAU

ADAPT PHASE

COMAU, represented by Business Managers, approaches the manufacturers to present the maintenance services.

The service offer can vary according to the different typologies of maintenance services showed in figure n. 5. Anyway, the customer is often aware of the kind of service he is looking for, so the offer is usually customized according to the customer's requests.

COMAU's goal is to get a global service contract.

Customer provides key information – about the kind of the machines, number of machines, historical data of the machines (if available), number of breakdowns, maintenance activities undertaken, maintenance operators present in the company, warehouse value, shifts, spare parts management, economical maintenance data.

COMAU, after a “flash audit” in the plant, internally calculates the cost of offering the service based on the data presented by the customer.

Usually after one month a budgeted offer is ready to be presented to the customer.

COMAU's goal is to get as many realistic data as possible so that it is able to put as many details as possible first in the offer and later in the contract.

The target is clearly identify customer’s expectation on the base of data collected.

Customer analyses the offer received, if interested in the proposal, allows COMAU to go on with more investigations and to bid with other suppliers.

COMAU, through a team of technical experts, collects as much information as possible on both technical, economical and personnel data.

At the end of this period, COMAU presents a definitive offer to the customer

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 23

Customer COMAU

Customer accepts the offer and the service contract is signed. Service offer is the contract binding both the parties. Contract durations are minimum 5 years for a global service or 1 year for all the other services.

[The goal of COMAU is to have a long term relationship.]

BUILD PHASE

The customer starts the creation of the “branch business” where it defines people, activities, machineries, offices, perimeters of business and so on that will be in sourced by COMAU.

COMAU works together with the customer in the perimeters definition and starts allocating/defining COMAU structure.

Customer has to give access to the machines / plant facilities.

COMAU installs its own software systems (SAP, intranet) and integrate warehouse data management, maintenance purchasing data into its system. Installs other software like Electronic presence sensing system and so on.

Customer stop performing maintenance activities and all other related activities.

Once the outsourcing process is finished, COMAU starts performing maintenance activities by itself.

OPERATE PHASE In this phase COMAU has to ensure that the service is up and running according to the service contract.

Customer is constantly informed and involved by COMAU about all planned maintenance activities gives as many information as possible in relation to production volumes, stoppages and changing.

COMAU's goal is having a clear interface that collaborates and contribute to improve and check maintenance plan on a regularly daily base.

Maintenance operative structure (composed of: maintenance operators, maintenance engineers and service manager) performs maintenance activities –planned, preventive and breakdown maintenance- on daily base.

Customer checks COMAU's activities through the feedback coming from its production personnel and on regular meeting where all KPI are showed and discussed together

All activities are measured according to the technical performance indicators specified in the contract.

COMAU's goal is to reduce technical breakdowns showing production volume and efficiency improvements. By the time this correlation is almost difficult to be achieved.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 24

Other remarks According to the type of business and the dimension of the customer, usually there is an agreed time while it is possible to collect all data that allows the development of a clear contract easily manageable by both parties.

Identifying customer’s expectation

In every exchange of goods there are expectations that must be satisfied.

When speaking about a contract of service maybe the first question should be: What is the customer to satisfy?

Often the people involved in the “pre-sale” phase are different from the ones that will run the business on a daily base.

As a matter of fact, there are many aspects that are not considered as they should be, thus they can create future repetitive debates and dissatisfaction.

Data collection during the pre-sale approach

During the pre-sale step, Comau collects different typologies of data that are:

• Technical • Economic • Personnel management

Technical data, especially when the customer is a small-medium company, often are incomplete as they are almost never a collection of documents but they are part of the traditional history of the few that have always done that job for ages. As a matter of fact, it is a common rule to take original drawings of machines and components so as the maintenance plans in use even if these information will never take trace of the real state of machines and their actual performance.

Of course, this problem will then appear in the judgement of performance because it will be always subjective as there is no concrete term of comparison.

Economic data are precise and easy to collect as far as the customer uses an appropriate informative software system with the proper allocation of costs.

The economic data that should be collected regard: material consumption, external supplier manpower utilisation, extraordinary hours, specialised contracts and all the other ordinary and extraordinary costs linked to maintenance.

This stage represents the base for the contractual economic agreement but, if during this step most of the costs are hidden or not highlighted, the interpretation of the activities included in the contract will be increasingly difficult.

Personnel management data include all information related to manpower.

Normally when maintenance activities are part of the production process, the skills of people are registered. The reason is that the same people could perform both maintenance and productive activities. But, on the other hand, the trend is normally that if the skills of manpower are relevant (in most of the cases) customers tend to keep the best resources inside their structure.

Identification of longer term value added activities

Maintenance services are strictly linked with production targets. During a contract many variables can change for a better achievement of continuously changing market goals. For

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 25

example, machines defined of minor importance for the productive process later become the main priority.

That is to say that sometimes there is the need to have a production interface who can decide to invest and take decisions in a longer term view rather than in a short period of time.

The contract running There are two main aspects that constantly affect the maintenance service:

1. The goodness of the performance monitoring system

2. The instruments for coordination

Goodness of performance monitoring system

Comau customers operate in different sectors and environments. In all contracts there is a clear definition of a general set of key performance indicators that will be used to monitor service performance.

Despite this fact, it is difficult to find some key indicators, not customised according to the production sector where they are used, which could give both the customer and Comau structure a clear view of its business.

For example, some typical issues that are still very difficult to measure regard:

• Added value to production customer targets, in terms of cost reduction activities, focused activities to improve quality and safety, etc.

• Indicators for “intangible activities” like office and technical cleaning, warehouse management, etc.

• Comparable indicators between different realities of Comau, etc.

• Skill traceability methods to link capabilities of maintenance operators with training gap analysis.

• A method to monitor the performance of our suppliers.

• A way to collect best practices – “improvement book”.

Coordination instruments

Planning and coordination with the customer is the key aspect for the development of a successful maintenance plan. Main discussions often can come from:

A) Bad coordination, here some examples follow:

• No respect of maintenance plan or last minute plans can cause missing spare parts or unsuitable manpower.

• Delay in machine shutdown for planned maintenance.

• Change type not communicated.

• No production manpower when re-starting machines.

• Changes in tool that causes breakdowns.

• Data share (ex. Downtime).

• Unclear boundaries between maintenance and production (ex. TPM).

B) Clear definition between ordinary maintenance and extraordinary maintenance.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 26

Contract running: movie of a typical situation The following flow chart emphasises the kind of problems that can occur during the contract running.

Figure 12 Movie of the typical situation

The above picture summarises all the difficulties that may happen after the signature of the contract. Indeed, analysing it, it is easy to do the following considerations:

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 27

• Pre-sale team

They try to put some objective parameters to split actions that are within the tariff from those that must be considered extra-jobs.

• Customer technical and economic interface

They are able to give historical data but they cannot predict the future, hence they do not consider a way of measuring or judging something that has never happened in the past.

• Customer operators

They do not create the contract and are used to the routine activities done by the maintenance group. They therefore simply pretend that everything is fixed.

• Maintenance operators

They apply the rules of the contract, and are usually very frustrated since even the application of the proper methodologies is criticised.

• Maintenance production manager

They often want everything in the tariff and try to give a reading of the contract that maybe is not the same of the one of the pre-sale interface team. Moreover they tend to give blame for missing performance or bad quality of job performed by the supplier.

• Maintenance service manager

They often try to satisfy the customer but at the same time are not authorised to twist the contract. Their major problem is that they cannot reply neither showing clear objective measurement of the service performed nor a clear reference to the section of the contract which can be read and misinterpreted according to whom is reading it.

4.1.4 Performance measured The Comau performance monitoring systems can be split into :

• Key Performance Indicators contractually agreed with customers

o Downtime

o CSI (Customer Satisfaction Index)

• Internal KPIs

o MTTR (Mean Time to Repair)

o MTBF (Mean Time Between Failure)

o MDT (Mean Down Time)

o Manpower utilisation

Indicators contractually agreed with customers

Downtime is a rate expressed as a percentage of breakdown hours on production availability hours.

The lack of a common system often generates debates on :

• the correctness of figures;

• the way to calculate related losses (like quality scraps due to breakdowns);

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 28

• production losses related to delays or repetitive small problems: boundary between maintenance and production responsibilities.

BONUS-MALUS

It represents a development in the latest contracts. It is a boundary calculated on the downtime target according to which Comau will pay a malus on the tariff in case the target is not achieved or it takes a bonus if the final result of the downtime is below the target.

Figure 13 BONUS-MALUS system

CUSTOMER SATISFACTION SURVEY

This survey has been lately introduced to give the customers the possibility to express a judgement on the main issues linked to the maintenance service.

(Even if the technical downtime is respecting the target, customers can have a bad perception of the service.)

Figure 14 Example of customer satisfaction survey carried on by COMAU (a)

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 29

Customer satisfaction

8,0

7,0

6,0

6,5

6,5

6,5

8,0

7,0

0

2

4

6

8

10

Integration Comau Service-Customer plant

Reactivity on maintenanceproblem

Efficacy of maintenance

Technical efficienty ofplant/machineries

Implementation/extension ofpreventive maintenance

Purchasing/maintenance spareparts management

Propositivity towardsimprovements

Respect of procedure andagreement

Figure 15 Example of customer satisfaction survey carried on by COMAU (b)

Internal KPIs Maintenance performance is the result of the utilisation of resources in providing actions to restore an item to a condition in which it can perform the required function.

The maintenance performance is depending on influencing factors, internal and external, such as location, culture and service processes, and is carried out by implementing organisational methodologies and operating techniques.

Therefore Maintenance Performance is an outcome of complex activities which can be evaluated by appropriate indicators to measure the results: actual, expected and foreseen.

Comau internal KPIs mainly refer to manpower utilisation making a comparison between what was forecast and what has been done.

The next picture shows the division in percentage of the hours of manpower available in a period of time and their utilisation according to the type of maintenance done.

Figure 16 Manpower utilization according to type of maintenance

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 30

4.1.5 Information given to the customer Comau relationship with the customer is very close as it is based on a daily exchange of information. It is convenient to split the data given to the customer mainly in two broad categories:

• Operative information.

• Performance information on a longer term basis.

The first group concerns data related to:

• Breakdowns.

• Daily planned activities.

• Communication on extraordinary jobs.

• Weekly and monthly preventive maintenance plans.

Performance information, instead, concerns all those data exchanged at a higher hierarchical level where, usually in periodical meetings, top and middle management discuss results and future strategies.

Figure 17 Feedback of information to the customer

4.1.6 Information required from the customer

Outsourcing always involves a considerable degree of two-way information exchange, co-ordination, and trust.

As already noted in the previous paragraph, the customer should provide as much information as possible on the state of machines, any warning signals and especially should collaborate on providing information on time on production working shifts, changing product type, new installations and so on.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 31

4.1.7 Coordination need with customer production activities Coordination still constitutes to be a big problem in all Comau realities as it often depends on the behaviour of people, so it is really difficult to standardise it.

Moreover as the people employed by Comau come from the customers’ reality, coordination procedures and habits represent the most difficult issue to be changed.

Comau experience demonstrates that coordination involves technical and organisational aspects strictly fused together.

Coordination is necessary to give the right priorities to problems to be solved.

In particular it is fundamental to focus together on:

• Technical information on machinery.

• Machinery critical analysis.

• Identification of maintenance jobs.

• Yearly maintenance plan.

• Weekly plan.

4.1.8 Coordination tools presently used First of all, it is important to highlight that nowadays the coordination tools used differ from customer to customer.

Apart from all the common information technology devices (telephone, e-mail, fax), the software used by Comau both for economic and technical data management is SAP. Usually Comau suggests to the customers that already have SAP, to buy the interface for the web call of the maintenance service.

When this module is active, it is possible to collect data regarding:

• The time when the breakdown occurred

• The name of the person that called for the service

• The duration

• …

The disadvantages is that it is not so handy as the data input requests a lot of time and is not as easy as it should be.

When the web call is not activated, all data regarding breakdowns are input manually.

The modules included in the present software (SAP) are:

• Administrative

• Purchasing

• Finance

• Controlling

• Materials warehouse management

• Project Maintenance (working orders; data input for breakdowns)

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 32

The project maintenance module, anyway, is too much rigid and the data cannot generate any graph automatically.

The following picture shows the flow of information and data that would be useful to share through an informative system.

Figure 18 Desired flow of information and data

By the time, modules to be developed or improved are:

• Contract project planning development

• Economic and technical planning

• Technical and economic performance indicators

• Manpower utilisation registration

• Materials warehouse management traceability (RFID technology?)

• Project Maintenance: web page interface with customers

• Data sharing with other realities for: skills, improvements and breakdown data collection

4.1.9 Criticalities perceived CONTROL

• Difficulties of integration between Comau Service and the customer manpower.

• Data management not completely agreed in accordance with targets.

• Comau has no control on the consumption of material judged worn by production (for example rollers, belts and all the others where there is contact with the final product).

EXTRAORDINARY MAINTENANCE

• The tendency of customers is to have all activities included in the full tariff.

• Customers do not want to invest in old machinery with obsolete spare parts.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 33

• Customers tend to avoid extraordinary expenditure in all machinery not directly linked to production (piping, structures, roof..).

BEHAVIOUR

• Trust.

• Doors and floors are continuously damaged by production personnel (no sensitisation).

CUSTOMER EXPECTATIONS

• Customers ask for more integration of Comau on production results and quality.

4.1.10 Link with the proposal business case Everything that has been explained in the above paragraphs constitutes groundwork for the proposal business case in Annex 1 of the InCoCo-S contract.

4.1.11 Examples of problematic situations The following examples represent some typical issues at the centre of debate with customers:

• Technical cleanings

Most of problems come from:

1. How to judge the level of service.

2. Definition of responsibilities (TPM/maintenance)

3. How to consider the problems caused to the final product coming from an insufficient level of service (quality).

• Downtime calculation based on the same principles

Dt= ∑ Stop time/ Production time

1. How can losses caused by a breakdown (quality scratches) be considered?

2. When does a breakdown start: when the machine stops or when the machine is no more able to give an acceptable output?

3. Without an informative system, who registers the timing?

• Quality perception of the maintenance service

1. Who judges the service?

By experience it is possible to say that various responsibilities in the hierarchical scale could express completely different judgements of the same service, as it is influenced by different level of knowledge of the contract, different involvements or different information feedback received on a daily base. Often services performed as defined in the contract are judged poorly by the customer!!

2. How can it be evaluated in an objective way?

Example: Repair of equipment that should be replaced!!!

4.1.12 Currently unsatisfied customer requirements Maintenance does not only mean to repair something that has broken down but it means dedicating most of the time in analysing technical and human causes that can create

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 34

breakdowns in order to prevent them aiming to a global economical optimisation of the productive system.

The continuous technological evolution makes the maintenance a continuous improving discipline.

Often the frenetic research for target achievement and cost reduction generates a wall of incommunicability between the service supplier and its customer.

Too often, maintenance troubles become the excuse to hide bigger and more complex process and product problems.

As a matter of fact, customers declare themselves not completely satisfied with the service maybe because the ones that should collaborate together to solve both maintenance and productive problems often fight between themselves.

4.1.13 Business processes description The following pictures describe the development of AS-IS processes at level 2, in particular:

• The first picture represents the environment taken as an example to develop the “as is” scenario.

• The second one shows the geographic location of the suppliers, customer production site and Service division.

• The last one briefly describes the interconnection between the Customer supply and service chains.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 35

The Service Supply chain is hereafter detailed considering each step (inputs, processes and outputs) that constitute respectively the Adapt, Build and Operate phases.

The first input for the Adapt phase is the Customer request. The picture shows the processes that at second and third level are included in the Adapt phase.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 36

INCOCO Inhouse Workshop Fabiola Di Giampietro

ADAPT

PROCESS CUSTOMER REQUEST CONTRACT ACQUISITION

1-Definition. Team

3-Data collection

OFFER SET -UP OFFER DEVELOPMENT

4-Data analysis5-Offer

development7-Different

serviceevaluation

8-Presentat.

CONTRACT DEVELOPMENT

1-Legal aspects definition

2-Technical aspects definition

Service branch creation

Meeting withcustomer

Contractsigned

Comau team Customerrequirements

Customerspecificservice

parameters

Differentserviceoptions

Draft of the offer

Quotation

Offer to the customer

Legal documents forthe outsourcing

process

AS IS: ADAPT

CUSTOMER REQUEST

Positivefeedback from

customer

Activities developed with the customer

Offer to the customer

The Service set up that is part of the build process is developed through the data transfer of technical and HR information from the customer to the Service partner.

Often this data is then input into the Comau I.T. system with subsequent inability for the customer to access the data.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 37

After the termination of the Adapt and Build phases, the service is finally outsourced to Comau, so that the last phase, “Operate”, constitutes the moment when the Services are finally outsourced and completely performed by Comau.

Maintenance activities can be broadly split into two main categories: breakdown maintenance and planned maintenance.

For a good maintenance plan it is very important to have all information from breakdown maintenance, since if repetitive or critical breakdowns are foreseeable, they can be prevented by a detailed maintenance plan. But this is not enough.

What is often much more important is the coordination with the production plan. If, for example, a breakdown is caused by a particular occurrence of change types, the communication by the production of the production plan is crucial. This communication is not formalised and often is done by periodic meetings or by informal communications between maintenance and production.

4.2 TO-BE situation

4.2.1 Description of the typical customer The customers for the “TO-BE” scenario are the same as in the AS-IS.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 38

4.2.2 Description of the service

Figure 19 From the AS-IS to the TO-BE service

The main differences between the AS-IS and the TO-BE scenario can be briefly highlighted as in the following picture.

4.2.3 “Movie” of the typical situation

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 39

4.2.4 Performance measured

Performance measures are the same as in the AS-IS scenario, the only difference is in the way they are calculated. In the AS-IS all data had to be agreed, in the TO-BE scenario they are automatically shared with the customer.

4.2.5 Information given to the customer By the use of the structured database run jointly with the customer it is possible to know:

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 40

• Technical data on machines.

• Data on preventive maintenance cycles.

• Flexibility to implement focused actions on critical production processes.

• Show a correlation between the customer production uptime and maintenance service done.

4.2.6 Information required from the customer Using a common database the integration between the production and service reality will be strictly linked together (COLLABORATIVE SERVICE).

New plans or re-scheduling will be easily manageable, speeding up the service process reaction through a pro-active and preventive approach (MPMS= MASTER PRODUCTION & MAINTENANCE SCHEDULE) rather than a reactive approach.

The MPS concept will be the integration between the delivery of a service (maintenance) together with the realisation of a product. The customer and service supplier will act in a coordinated way avoiding difficulties in the service delivery.

In addition to this, the measuring process will be improved, in regular meetings the customer will be supplied with the number of times when the service was postponed, additional costs incurred by Comau in satisfying the customer need, actual response time to extraordinary customer requests and so on.

4.2.7 Coordination need with customer production activities For the TO-BE scenario, communication will mainly use only one interface: the common database. All data input to the database must be constantly updated by both parties.

4.2.8 Criticalities perceived The criticalities that have to be faced are mainly cultural or linked with I.T. technologies.

To implement a flexible service run together by both parties, the following rules must be applied:

• Short term thinking

• Quick way of acting

• Defining clear roles and responsibilities

• Ability to analyse data

• Respect for business secrecy

4.2.9 Currently unsatisfied customer requirements This issue is similar to the description of the AS-IS scenario.

4.2.10 Business processes description

Adapt Phase: differences with the AS-IS

In the TO-BE scenario, three new processes have been introduced:

• Maintenance performance definition

• Maintenance strategies definition (macro)

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 41

• Economic aspects.

The above items will guarantee a better link between the creation of the offer and the operative phase.

Defining previously maintenance performance measurements together with macro maintenance policies will fulfil the gap that exists between the contract definition and the maintenance activities implementation itself.

Indeed, as explained in the previous pages, one of the most common problems is that the customer recognises some of the service activities as part of the contract instead of extra ones. Defining during the contract preparation both economic and technical aspects linked together will set the boundaries of application of the contractual perimeter.

Build Phase: differences with the AS-IS

In the TO–BE scenario, the introduction of the process “Maintenance strategies definition” will guarantee the link between contractual specification and day-to-day activities.

Anyway the real difference is represented by the constitution of a common database where the customer will input all technical data regarding its machines.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 42

Operate Phase: differences with the AS-IS The operate phase will improve due to the utilisation of a common database by the customer and Comau. As it is showed in the following picture, the database implementation will give much more flexibility and reliability to the system due to:

• Faster accessibility of data.

• Easier possibility to update in real time maintenance data with production plan.

• Better link with performance results.

Indeed, comparing what was defined in the process “Maintenance strategies development” (Build phase) with the output of the process “Data Processing” in the operate phase, Comau will be able to communicate data to the customer in real time, giving the possibility to know the technical service that he is going to receive and at the same time to perceive the flexibility of the system (better data and more services).

Indeed, giving an example, if in the “Adapt phase” no maintenance service was agreed during the weekend, but during the operate phase the need for such an intervention arises, by the use of a common planning I.T. solution the customer will perceive the flexibility of the system and its economic value, so that he will be more pleased to recognised extra costs.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 43

COMAU Business Case Process Level 2 – ADAPT

1. OFFER SET-UP

Input: Customer request

Output: Customer requirements and specific service parameters

Measures of performance:

• Process’ duration

• Response time

• Dataset quality

• Coherence of input data

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 44

2. OFFER DEVELOPMENT

Input: Customer requirements and specific service parameters

Output: offer to the customer

Measure of performance:

• Offer completeness

• Response time

• Customer’s satisfaction

3. CONTRACT DEVELOPMENT

Input: Offer to the customer and positive customer feed-back

Output: contract signed

Measure of performance:

• Contract completeness

• Response time

• Customer’s satisfaction

• Legal aspects completeness

• Technical and performances definition completeness

• Cost definition

• Master plan and project’s timing - miles stones definition

• Economic aspects and forecasted impacts on the project

• Risk/opportunities evaluation and forecasts

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 45

COMAU Business Case Process Level 2 – BUILD

1. SETUP OF HW & SW COMPONENTS

Input: contract signed

Output: instruments

Measure of performance:

Coherence with contractual technical specifications

Coherence with contractual allocated resources

Completeness of instrument’s list

Response time

2. DATA TRANSFER TO COMAU INF. SYSTEM

Input: customer’s purchasing technical data

Output: Comau Service I.T. updated

Measure of performance:

• Completeness of data

• Quality of data

• Optimization of resources

• Data availability and accessibility

• Response time

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 46

3. HR STRUCTURE DEFINITION

Input: people included in the branch definition

Output: Comau Service HR structure

Measure of performance:

• Coherence with planned resources

• Optimization of resources

• Coherence between HR structure and technical specifications

• Coherence with HR structure and economical targets

• Response time

4. MAINTENANCE STRATEGIES DEVELOPMENT

Input: technical data from customer – data of similar contract from data base

Output: yearly maintenance plan and related costs

Measure of performance:

• Coherence with planned resources

• Optimization of resources

• Target’s definition

• Plans and timing of strategies

• Response time

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 47

COMAU Business Case Process Level 2 – OPERATE

1. BREAKDOWN MAINTENANCE

Output: reparation and form filled with technical data

Input: maintenance call – maintenance form

Measure of performance:

Availability of spares

Availability of instruments

Availability of resources

Quality of collected data

Response time

2. PLANNED MAINTENACE

Input: initial data and agreed KPI indicators

Output: improvement of performances and KPI indicators

Measure of performance:

• Data analysis and trends

• KPI monitoring

• Targets adherence

• Improvement of plans and resources optimization

• New proposals for improvements

• Data base population and update

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 48

3. PRODUCTION AND MAINTENACE INTEGRATED SCHEDULING

Input: yearly maintenance plan – production plan

Output: master production and maintenance schedule

Measure of performance:

• Targets adherence and agreement

• Improvement of plans and resources optimization

• Proposals for improvements

• Plans and scheduling

4. DATA PROCESSING

Input: maintenance activities agreed – form filled with technical data

Output: performance evaluated with the customer

Measure of performance:

• Live reports

• Completeness of reports

• Data comparison

• Data trends

• Evaluation methods

• Protocol of agreed performances

4.3 Definition of the requirements What needs to be done to change from AS-IS to TO-BE, is summarised here in terms of business processes, measures of performance and, coordination mechanisms and information systems.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 49

4.3.1 Business processes As highlighted above, it is necessary to implement new processes in the Adapt, Build and Operate phases in order to decrease the gap between the contract specifications and day-to-day activities.

The introduction of the process “Maintenance performance definition” in the Adapt phase will guarantee the link between contractual specification and day-to-day activities. Indeed defining during the contractual phase “macro” maintenance strategies linked with the cost of the service will help in the definition of day-to-day activities, avoiding the gap between the main contents included in the contract and its application.

In addition to this, the involvement of the customer in defining the kind of service that he is going to receive is much more detailed. Having a maintenance plan linked together with the contract will help him in understanding future changing or different activities that are going to happen during the contractual running.

Introducing the macro plan decided in the Adapt phase in the database with all the other technical data collected during the Build phase and Operate one will mark the differences decided and the customer will be always updated with them.

4.3.2 Measures of performance The performance results will be guaranteed by the database that not only will be able to collect all information related to maintenance and production activities linked together, but also will become an instrument for continuous improvement.

By the fact that the database will be easily accessible by both parties, it will provide Comau with updated data so that maintenance activities will be much more focused and “agreed” with the customer.

As an impact, all discussions coming from uncertainty on the source of data will be avoided.

Performance indicators and definition will be agreed with the customer during the Build phase.

In particular, by the implementation in the Build phase of the new process “Maintenance strategies development” the five year plan decided in the Adapt phase will be analysed and decomposed in a yearly maintenance plan, that will be year-by-year readjusted and modified according to the results of the previous year. In this way the measure of performance will be much more objective and calculated in a flexible way.

4.3.3 Coordination mechanism and Information system If in the AS IS scenario the coordination between Comau and the customer is mainly done through formal meetings, the TO BE case involves the introduction of an informative tool that will be able to link together data and activities as represented in the following picture.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 50

The operate phase will improve thanks to the utilisation of the common database by the customer and Comau. The database will give much more flexibility and reliability to the system due to:

• Faster accessibility of data;

• Easier possibility to update in real time maintenance data with production plan;

• Better link with performance results

The database will contain the technical data of machinery, divided according to the criticalities for the process and the type of maintenance decided with the customer during the Adapt phase (see picture below).

Figure 20 Technical data of machineries

The informative system will also contain the yearly plan as decided in the Build phase as shown in the following picture.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 51

Figure 21 Yearly planned maintenance plan

Moreover it will integrate this information with the production plan and with the breakdown data from the machines. So that if the plan will be changed because of production or maintenance problems the system will give an alarm communicating the changes to both parties but at the same time this change will stay memorised in the system.

As a matter of fact, every week the maintenance plan will be automatically generated so that the customer will know the activities that are going to be performed by Comau, as shown in the next example.

Figure 22 Weekly planned maintenance activities

The initial connection between technical activities to be performed together with economical data can be compared at the end of the year so that the Customer will be able to perceive eventual changes to the Service (as agreed during the contract) and at the same time will recognise the added value given by the Service supplier.

4.3.4 Requirements summary

• Business process definition: relationship between contract definition (macro maintenance plan) and day-to-day maintenance plan.

• Measures of performance: definition of a system of measurements to link maintenance and production performances.

• Coordination mechanisms and information systems: develop specifications for the database structure to be used as an operative tool by both parties.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 52

5 Business case 3: SKF

5.1 AS-IS situation

5.1.1 Company portrait - Description of the typical customer The SKF Group is the leading global supplier of products, customer solutions, and services in the business of rolling bearings and seals. The Group's main competencies include technical support, maintenance services, condition monitoring and training. SKF also holds an increasingly important position in the market for linear motion products, as well as high precision bearings, spindles and spindle services for the machine tool industry and lubrication systems. The SKF business is organized into three divisions; Industrial, Automotive and Service. Each division serves a global market, focusing on its specific customer segments.

SKF has 100 manufacturing sites distributed all over the world. With its own sales companies in 70 countries, supported by some 15 000 distributors and dealers worldwide, its e-business marketplace and global distribution system, SKF is always close to its customers for the supply of both products and services.

SKF was founded in 1907 and from the very beginning focused intensively on quality, technical development and marketing. The results of the Group's efforts in the area of research and development have led to a growing number of innovations that has created new standards and new products in the bearing world.

SKF assists customers in various industries with knowledge-based service solutions that optimize plant asset efficiency. Our asset management services are developed to enhance plant reliability and help our customers to achieve their business goals. The SKF asset management services are designed to complement your existing reliability maintenance programme.

Our condition monitoring products provide value-added "smart" solutions to assist customers in operating the most effective reliability programmes possible. Our integrated systems of condition monitoring hard- and software components utilize the latest technology for accurate data collection and analysis. By utilizing advanced technology to develop products that are capable of performing increasingly complex analysis and diagnostics, our goal is to provide SKF customers with vital information to optimize and enhance decision-making, and to help identify and address the root cause of machine problems.

For the purpose of satisfying its customer requirements various hard- and software products have been developed:

• WindCon is a remote online condition monitoring solution for wind farms, which gives operators a complete overview of the mechanical condition of their wind turbines on a continuous basis.

• Machine Analyst is an advanced software solution for managing, manipulating and analysing machine condition monitoring data. This product is used for example in the manufacturing, paper and petrol-chemical industry to avoid costly breakdown of assets.

For small manufactures or customers who want to start with condition monitoring, the measurement service can be bought from SKF. This means that no pre-investments in hard- and software components are necessary and the customer can immediately benefit from condition monitoring.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 53

5.1.2 Description of the service In the following the different service levels regarding the condition monitoring offers of SKF are depicted:

1st Service Level

• Offline Monitoring of the assets & analysis done by SKF.

2nd Service Level

• Selling of hardware and software components.

• Implementation of an online condition monitoring system.

• Customer is doing the data collection and analysis by himself.

3rd Service Level

• Provide an online condition monitoring system as described in Service Level 2.

• SKF is doing the data collection and analysis and generates a database and reports with the analysis (normally in predefined time spans).

• The customer gets the reports and/or has a direct access to the database.

• The offer also includes the service for maintaining the measurement points and the IT infrastructure.

• The implementation focus is on rotating components like bearings and the related assets as gearboxes, electricity generators, etc. and is not limited to SKF products.

4th Service Level:

• Includes all services of level 3 but the whole measurement equipment remains SKF´s property.

• As an option SKF is generating recommendations for maintenance activities based on the online asset diagnosis, but is not responsible for the execution of the recommended maintenance activities.

5th Service Level:

• Includes all services of level 4.

• SKF guarantees a defined pre-warning time (e.g. 48 hours) before a potential system breakdown.

6th Service Level:

• Full service offer for SKF products: implementation, monitoring, analyzing, derivation and execution of the product related maintenance activities.

• SKF is responsible for the whole process and for the availability of the advised assets/components.

5.1.3 “Movie” of the typical situation In the following chapter a typical course of business of SKF is specified. The following table gives an account of the workflow regarding the designing, building and operating of an SKF service offer. The spreading into a customer and a SKF column applies to the responsibility

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 54

for the particular steps in the workflow. For this “movie” a 4th step offer was chosen and only the AS-IS situation is characterised.

According to the SCOR model source-make-deliver approach, here a service oriented attempt is proposed. For the different phases of the service offer and operation process three steps are specified: ADAPT PHASE, BUILD PHASE and OPERATE PHASE (which mirror the SCOR phases SOURCE, MAKE and DELIVER).

Customer SKF

ADAPT PHASE

SKF represented by Business Managers approach the manufacturers to present the innovative services

The service offers range from 1st to 6th step. A 4th step offer is normally through step 1 or 2. So the customer is still aware of the benefits of a condition monitoring and had some kind of experience with offline measurement.

[SKF provides access to more database information and analysis tools. The USP are on the one hand to reduce the number of breakdowns and on the other hand to reduce the maintenance cost. SKF offers product excellence with higher quality and features.]

Customer provides key information – about the kind of machines, number of machines, historical data of the machines (if available), number of breakdowns, maintenance activities undertaken, locations, number of measurement points (joint activity) – optimum number of measurement sensors & type of measurements – method of measurement (offline or online).

SKF internally calculates the cost of offering the service to the customer based on the data presented by the customer. Customer offer is calculated based on this calculation. Customer sees the price per measurement point. Price per measurement point includes implementation costs, costs of hardware & software, and all the personnel costs involved in the build phase.

[As a minimum 500 measurement points are required to make a SKF offer for measuring; based on the own experience SKF makes a proposal for the necessary number of measurement points]

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 55

Customer SKF

SKF checks the requirements of the customer with respect to additional interfaces with the in-house information & decision support systems (e.g. ERP systems etc.).

Query regarding the interfaces to the customers ERP system – where only the feedback is the analysis report & to use the report for historical analysis & to generate maintenance plans based on the suggestions made by SKF.

[Current interfaces have to be developed individually and manually for the customers. There are no standard interfaces between these systems.]

Customer accepts the offer and the service contract is signed. Service offer is the contract binding both the parties. Contract durations are minimum 3 years for any services (online and offline measurements).

[The goal of SKF is to have a long term relationship.]

BUILD PHASE

Customer has to provide the IT infrastructure (e.g. network connection like DSL etc.) primarily for communication with the SKF System.

Order the components from stock and also from 3rd party providers. Order of the required licenses from the SKF Software solutions provider.

Build the sensors on the components and install the iMU units & interfacing. This step is carried out by the (mechanical) domain experts of SKF.

[Client hardware is provided by SKF.]

Customer has to give access to the machines / plant facilities.

Integration of the different systems with the Software (Machine Analyst, ProCon etc.).

Provide SKF the structure for grouping the machines with the following underlying hierarchy of the SKF system: three levels for the asset description and the 4th level for the specific sensor. The specification of the assets has to be done by the customer.

[The hierarchy captures the interdependency of the machines – primarily the bottleneck. For e.g. paper manufacturing machines the different stages (dry component, several sub

Build the IT infrastructure – WAN / VPN This step is carried out by the IT infrastructure domain expert of SKF.

[The IT-system stays in the ownership of SKF (which means that SKF is also a IT service provider). The server and the database are located at SKF and at client (e.g. PC) on the customer’s side. A step 2 service is the exception. Here the customer is buying the equipment.]

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 56

Customer SKF components) in the manufacturing process can be modeled.

The hierarchy can be 3 different levels and the 4th level is the sensors. The hierarchy groups the various sensors into similar group. Furthermore the sensors for such bottlenecks could be integrated into the production planning of the whole production line.]

Testing environment – all the sensors and the related equipment are tested and then the protocol is signed by the customer that everything is working as expected.

OPERATE PHASE In this phase SKF has to ensure that the service is up and running according to the service contract. Reports have to be generated on a regular basis as defined in the contract. SKF has to schedule the onsite measurements again as per the contractual obligations and transfer the measurements into the database which is hosted at the SKF site. The interfaces have to be monitored – between SKF and other systems. Due to the fact that SKF generates recommendations for maintenance activities based on the online asset diagnosis only as an option and is not responsible for the execution of the recommended maintenance activities, there is only little interaction with the customer in this phase. The only interaction refers to the deliver of report from SKF side and the giving of feedback concerning performed maintenance activities from the customer’s side.

Measure of the sensor data – both offline and online.

[Customer has the possibility to do the following analysis by itself. Client PC can be connected to the central databases and can then perform the detailed analysis. SKF can also do the analysis for the customer.]

Check the consistency of data & health of sensors and related IT infrastructure. 1st root cause analysis which contains two steps for the consistency check: (1) Analysis of the IT infrastructure (because SKF is responsible for any failure in it) and (2) Analysis of the service oriented equipment (e.g. sensors) to check the reason for the alarm signal (is it a problem with the mounting of the sensors or is the alarm signal due to a problem with the asset or a component of it).

Analyze the information & root cause analysis 2nd step – for the specific machinery component.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 57

Customer SKF

Develop guidelines based on the information analysis

Communicate the reports & guidelines to the customer for their information & further actions

2 type of reports are generated by SKF:

1st – Report of Alarms – threshold exceeded on the following sensors (plan analysis / examination of the component), diagram of the signal, specific frequency of the bearing, various mathematical calculations are performed, envelope curve are generated, and an analysis of the peak / trends of the sensor data (ERP systems can generate a trigger for the quality management department to undertake 100% quality control and this could be even vice versa).

2nd – Enhanced report – give some recommendation based on the alarms generated by the sensor, e.g. check lubrication, replace bearing, etc. (requires an additional software component which means more costs for the customer).

[ERP / Maintenance system could be fed with this activity signal. The information from the SKF reports can be directly integrated into the maintenance plans.]

Deliver the reports to the customer as paper or electronic version.

[Reports can be delivered in a pre-defined template. Customer can than use the thin client to access the online database and see the reports; primarily used for documentation purposes this option is very useful for insurance claims as in the case of windmill condition monitoring.]

Customer should give feedback concerning performed maintenance activities.

5.1.4 Performance measured Presently there is no measurement of the performance on the basis of specific key performance indicators (KPI). In the context of the current service contracts SKF only contracts a 24/7 access to the database and provides the reliability of the data. Beyond this

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 58

SKF makes a verification of the sensor data by generating a self indicated alarm and a cross check with the sensor sensitivity for the respective alarm.

In general SKF provides its customers the following advantages, but without a specification and contractual agreement:

• the number of unplanned breakdowns during the manufacturing process will be reduced, and the availability of the manufacturer equipment will increase;

• the customer gets a better visibility on the current status of the equipment performance;

• on the second level the customer can generate a cost reduction for its maintenance effort.

5.1.5 Information given to the customer SKF provides its customers a variety of information. The type of data and information given to the customer is depending on the individual contract. Regarding a 4th step offer SKF generates two types of reports:

1. Report of Alarms – threshold exceeded on the following sensors (plan analysis / examination of the component), diagram of the signal, specific frequency of the bearing, various mathematical calculations are performed, envelope curve are generated, and an analysis of the peak / trends of the sensor data.

2. Enhanced report – recommendations based on the alarms generated by the sensor are generated (e.g. check lubrication, replace bearing, etc.). With the content of this report the ERP-/CMM-system could be fed and the information can be directly integrated into the maintenance/manufacturing planning.

Furthermore SKF provides its customers a direct access to the data and is able to build up an asset history of the customer’s equipment. The kind of analysis used to analyze the sensor data (e.g. FFT, envelope curve, etc.) is also made transparent for the customer.

5.1.6 Information required from the customer Regarding the service offer a provision of detailed customer key information is necessary for SKF. These include for example the kind of machines, number of machines, historical data of the machines, number of breakdown, maintenance activities undertaken, locations, number of measurement points and so on. Based on the data presented by the customer SKF calculate the cost of offering the service to the customer internally. This internal calculation represents the basis for the customer offer.

5.1.7 Coordination need with customer production activities (how frequent, what for, how difficult, etc.)

Presently most of the processes regarding communication of data / reports are done automatically without any direct coordination with customers. In exceptional triggers, the customer is contacted directly to be informed about an exceptional event. This is the only sort of coordination which is normally required during the runtime of the services. The main coordination effort lies in the adapt and build phase of the service offer. Because of the fact that the installation of the measurement equipment has to be done parallel to the running manufacturing process the activities have to be synchronized with customer plans / availability. The customer has to provide access to the equipment that SKF can perform the measurements. For facilitating the installation / maintenance of the IT infrastructure and the client system at the customer a coordination with IT department is necessary.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 59

If interfaces are customized according to customer needs, and if in-house ERP systems are upgraded, then adjustments to the SKF interfaces have to be carried out. Again coordination with appropriate IT solutions provider / department is required.

5.1.8 Coordination tools presently used Currently the following tools are used: phone, email, and fax. Furthermore a file transfer and export / import of data between SKF and customer systems (e.g. ERP systems) exists.

5.1.9 Criticalities perceived In the following a prioritization of perceived criticality areas is listed:

1. Information exchange

2. Standardization of information exchange / interfaces

3. Reference framework

4. Best practices

5. Business processes

In addition to this a problem in the communication is to define the exchange format and the means of exchanging the data. Tools / security issues are critical here as well. Another problem in the communication lies in the semantic, where a similar use of terms is needed in the future.

Currently the implementation of an interface in a suitable time framework is difficult. A reference framework could help to develop such interfaces which should be more configurable than to develop individually from scratch. The framework can be based on an Enterprise Service Bus (ESB) with pre-configured modules. Three aspects of a reference framework should be a reference models, a business and technology dictionary and implementation guidelines.

5.1.10 Examples of problematic situations In the following list of catchwords examples of typical problematic situations are outlined.

• IT Infrastructure failure

1. Development of the interface

2. Maintenance of the IT Systems

3. Bug Management

• Data analysis

• Lack of information on the actions taken by the customer based on the guidelines provided by SKF

• Sensor is sending fuzzy signals in the sense that it is not able to identify accurately which component is heading towards the breakdown

• Sensor / CMU (condition monitoring unit) failures or errors

5.1.11 Currently unsatisfied customer requirements In the following the unsatisfied requirements of SKF and its customers resulting from the problems in the current situation and the future market needs are outlined.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 60

1. Electronic interfaces (e.g. ESB)

2. Automated communication & integration

3. Maintenance portals for the customer (a portal where the health of different systems/assets is shown in an configurable way)

4. Exchange of additional information

5. Access to ERP / maintenance system information

6. Integrated planning of maintenance / production based on the guidelines from SKF

7. Integration of machine control systems

5.1.12 Business process description

Introduction: SKF processes Level 2

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 61

SKF Business Case Process Level 3 – ADAPT

Input: Customer request (e.g. phone call, contact on a fair)

Output: service offering

1. Process Customer request

Measure of Performance:response timesuccess rate

Input: key figures of the customer process/assets, service targets of the customer

Output: customer specific service parameters

2. Define customer specific requirements

Measure of Performance:time for definitionnumber of additional contacts to the customer

Input: customer specific service parameters, terms and conditions of service offerings, prices of the different internal and external suppliers, profit margin

Output: quotation, description of the service offering, offering alternatives

3. Evaluate different service scenarios

Measure of Performance: none

Input: quotation, description of the service offering, offering alternatives

Output: final offer

4. Negotiate the service offer

Measure of Performance:time between the negotiation and the finalising of the contract

Input: final offer

Output: signed contract

5. Finalise the contract

Measure of Performance:lead timesuccess rate

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 62

SKF Business Case Process Level 3 – BUILD

Input: signed contract, factory layout, machine list, indication of critical machines, machine data (e.g. bearing type, defect frequencies, machine history)

Output: virtual plant structure, number of sensors per machine

1. Define machine hierarchy (virtual plant structure)

Measure of Performance: none

Input: signed contract, specifications from the suppliers

Output: system specification

2. Set up of the specifications of the hardware and software components and related services

Measure of Performance:lead timesuccess rate

Input: system specification, prices and lead time for the supplier components

Output: order (build to order, build to stock) of components and related services

3. Order of hardware and software components and related services

Measure of Performance:difference between actual and calculated costs for the components and services

Input: system specification, tracing and testing tools, measuring parameters

Output: test report, approved components and services

4. Receive, configure, install and pretest of thecritical components at SKF

Measure of Performance:lead timequality (e.g. number of failures)

Input: test report, approved components and services

Output: delivery receipt

5. Deliver of system components to the customer

Measure of Performance: none

Input: signed contract

Output: start of operation

6. Installation and testing of whole system at customer

Measure of Performance:live report

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 63

SKF Business Case Process Level 3 – OPERATE

Input: start of operation, virtual plant structure, sensor signals

Output: data records

1. Measure and store of the data (online or offline)

Measure of Performance:quality of measuretime from measurement to storage

Input: data records, algorithms, thresholds, know-how of the SKF personnel

Output: analysis report, adapted thresholds

2. Analysing of the measurement data

Measure of Performance:quality of the analysis

Input: analysis report, adapted thresholds

Output: list of recommendations

3. Recommend maintenance activities

Measure of Performance:quality of the recommendation

SKF Business Case Process Level 3– SUPPORT

6

© In

CoC

o-S

2006

ww

w.in

coco

.net

SKF Business CaseSupport Activities – Level 3

Deliver up-to-date service portfolio

Maintain interface to Business Managers

Follow SKF business rules

Deliver up-to-date data sets (virtual machine containers)

Specify certified components

Deliver test equipment incl. test plans

Define backup strategy

Define maintenance windows

Define update strategy for infrastructure

Set-up of maintenance plans

Create disaster recovery plan

Define operation responsibilities

S-Ad

apt

S-B

uild

S-O

pera

te

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 64

SKF Business Case Process Level 3 – PLAN

7

© In

CoC

o-S

2006

ww

w.in

coco

.net

SKF Business CasePlan Activities – Level 3

Collect asset information Analyse asset information

Co-ordinate involved implementation partners

Co-ordinate set-up and solution implementation

Set-up customer installation

Receive Business Manager request

Analyze existing service offering

Compare (balance) customer request with service offering

Develop new service offering

Define operation strategies

Adapt operation strategies to new customer enhancements

P-Ad

apt

P-B

uild

P-O

pera

te

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 65

5.2 TO-BE situation

5.2.1 Description of the typical customer Due to the fact that the current SKF 4th Level Service Offer has been offered to the market for a short time, the TO-BE is defined similar to the basic principles of the AS-IS processes. The addressed customer target group has also been retained unchanged.

5.2.2 Description of the service For the description of the TO-BE service offer and its comparison the AS-IS situation please refer to the following picture.

InC

oCo-

S 2

005

ww

w.in

coco

.net

Vision

Asset Diagnostics(= Condition Monitoring)

Today

Asset Diagnostics(= Condition Monitoring)

As Is

Currently two (isolated) areas in the manufacturing process are existing: Process control to supervise the manufacturing process by measuring e.g. pressures, cutting speeds, temperatures etc., and maintenance management to check the health of the machines. At the moment no deep integration from CMMS systems to CM system is realized, which enables "Intellectual Asset Management".

To Be

Figure 23 From the AS-IS to the TO-BE service

5.2.3 “Movie” of the typical situation Unlike AS-IS the “Movie” of a typical TO-BE situation is represented according the following changes concerning the current AS-IS situation:

In step 6 (adapt phase) and steps 10, 12 and 14 (all of build phase) the interfaces between the SKF IT-infrastructure and the assets and ERP-system on customer side are linked by means of a reference framework based on an Enterprise Service Bus (ESB) with pre-configured modules. This reference framework contains three aspects: a reference model, a business and technology dictionary and implementation guidelines.

The rest of the description of the above modeled AS-IS scenario applies in the same matter for the TO-BE scenario.

In the following, additional phases of the TO-BE situation are explained. These phases complete the three basic process steps of ADAPT, BUILD and OPERATE.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 66

OPERATE PHASE (Service Provider Responsibility)

• Integrated maintenance plans should be provided to minimize the customer interactions. Based on the guidance from SKF, tasks should be generated automatically in the maintenance plans of the customer and be scheduled in the next few days.

• Also, if in the next maintenance should schedule it is not possible to make the suggested repairs, then the two systems should interact to find a feasible alternative (Human Systems integration, Negotiation Tool)

• In case of power plants, where the sensor data is only used if the performance is within a range, then this information could be used to make the decision on whether to analyze the sensor data or not.

• Merger of performance data from sensors with the output data from the machines to take it to next level of integrated decisions (as a important step towards an intellectual asset management)

CONTROL PHASE (Service Consumer Responsibility)

• Maintenance plans are not integrated with the measurement systems thus SKF does not exactly know what kind of maintenance activities have been undertaken on the specific machine components.

• Statistics on the accuracy of the forecasts is missing – causal loops are necessary (3 scenarios):

1. Customer is informed but no action is undertaken.

2. Customer has been informed and the sensor is still exceeding threshold. The customer undertakes the repair but if something wrong is done during the repairs then SKF knows that either there is something wrong with the system or the sensor is malfunctioning (health check).

3. Customer is doing the repairs using the right tools and techniques, but perhaps it has been the wrong equipment which has been diagnosed. In case, if SKF is using one sensor for two bearings in a gear house, then it could be that the sensors shows the failure of another bearing.

• Sensitivity analysis of threshold values to improve the analysis (so based on the feedback the threshold can be accordingly regulated).

5.2.4 Performance measured

In the future the following KPIs can be relevant for the contract agreements for SKF: MTBF, MDT, MTTR, OEE, …. (for further details see paragraph 4.3.2 Measures Of Performance).

5.2.5 Information given to the customer This issue is similar to the description of the AS-IS scenario.

5.2.6 Information required from the customer

For the TO-BE scenario explicit indicators of the desired service level from SKF are necessary. These indicators will lean against the KPI that will be relevant for the contract agreements for SKF in the future (e.g. max. nr. of breakdowns per year, OEE, MTBF, etc.).

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 67

5.2.7 Coordination need with customer production activities For the TO-BE communication of reports, three different interfaces and communication methods are planned.

Potential interface types are:

1. Electronic interfaces

2. Automated communication & integration

3. Maintenance Portals for the customer

Following communication methods can be used:

• Migration database if information is required from different systems. The data is collected from different systems and stored in one database for further processing.

• Create a separate database (e.g. information pool) to integrate the information from different systems – here the ERP system has access to sensor data, diagnosis systems. Then a decision has to be taken either at customer or SKF end.

• Enterprise Application Integration – Enterprise Service Bus ESB – Information Brokers – Intelligence is inbuilt into these systems. Applications communicate over the Enterprise Service Bus using web interfaces thus integrating different systems.

5.2.8 Coordination tools presently used For a further developed service (e.g. execution of the recommended maintenance activities) the integration of the customer planning into the SKF planning is necessary. It has to be clarified whether the SAP solution Advanced Planner and Optimizer (APO) in this field can support the planned Asset Management System.

Loose Coupling is one of the essential concepts in development of service oriented architectures and in this context a feasible tool to be used. The principle is to use a resource only via its published service and not by directly addressing the implementation behind it. Changes to the implementation by the service provider should not affect the service consumer. The service consumer could choose an alternative instance of the same service type (for example change service provider) without modifying their requesting application, apart from the address of the new instance. The service consumer and provider do not have to have the same technologies for the implementation, interface, or integration when Web services are used.

5.2.9 Criticalities perceived The criticalities which have to be faced are the same as in the AS-IS description. Hopefully the most critical and relevant ones are minimised or solved. Most critical for the TO-BE is the improvement of the information exchange by means of a standardisation of the information exchange (format) and the interfaces.

Furthermore the following obstacles need to be overcome to implement adaptable services and integrate concepts for the customer:

• Organizational culture and project orientation

The needs of the business as a whole will not be considered, and generalized services that may be applicable elsewhere will not be delivered.

• Short term thinking

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 68

The pressure to meet immediate requirements leaves no scope to discuss future needs. This might not in itself prevent IT from trying to introduce service oriented principles, but makes it difficult to discuss and agree them with the business.

• Business Secrecy

Whilst the business may desire agility, it may not necessarily want to share with IT the business strategies that might require agile solutions.

• Ability to abstract and generalize

The skills required are not always common in developers, particularly if it also requires sufficient familiarity with the business to be able to abstract and generalize the business concepts.

If businesses are to become more agile then they must address these issues. Business leaders cannot continue to complain about the IT department's apparent lack of responsiveness to change when its own practices can create the above obstacles. Similarly the IT department must also play its part in designing agility into their solutions.

5.2.10 Examples of problematic situations A typical problematic situation results from the different service provider and service consumer perspectives:

Service agility can be seen from both the perspective of the service provider and the service consumer. The service consumer's real objective is normally to receive maximum value at minimum cost and risk. For a service offered on a commercial basis, risk can be reduced by aligning the payment of services with the benefits received - this should be achieved by some form of pay-per-use but only if the service and its commercial terms are properly designed. Risk is also reduced by the ability to switch service provider to gain tactical or operational improvements in price or service level.

To clarify the background of and the motivation for the different perspectives the following table explains the respective objectives:

Service Consumer Objectives Design Principles

Reduce effort to use new services Precise specifications

Standardized services

Choose alternative instances of services type Services well abstracted from implementation

Standardized services

Service Provider Objectives Design Principles

Reduce demands from new consumers for additional features

Coarse grained, abstracted services that meet a wide range of service requests

Compose new services from existing ones Fine grained, generalized services that can be composed in a variety of ways

Reduce impact of changes to service implementations

Services well abstracted from implementation

Provide services in new and unforeseen Generalized services

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 69

context

Provide services to as broad a range of consumers as possible

Coarse grained, and generalized services

A typical problematic situation results from the different service provider and service consumer perspectives: Especially in the area of interface development the customer expects an implementation which is easy to modify. But the current programming model requires a new development from scratch for every customer.

The type of data once defined can be changed only by developing a new version of the interface.

Application Exchanged Information

Hierarchy Name

Set Name

Machine Name

Measurement Point

Time Stamp

Machine Analyst

Measurement Value

5.2.11 Currently unsatisfied customer requirements This issue is similar to the description of the AS-IS scenario.

5.2.12 Business processes description Please refer to the AS-IS situation.

5.3 Definition of the requirements The integration of business-management-process knowledge with the technical orchestration of enterprise services allows the implementation of a flexible service-oriented architecture based on the modelled business requirements. New processes can be developed simply and based completely on models, both according to business-management specifics and based on existing best practice applications and their functions, business objects and application logic.

This can be only achieved if interfaces from SKF applications to other systems e.g. ERP systems aren’t developed from scratch for each customer, but can be orchestrated out of already existing building blocks e.g. web services.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 70

Figure 24 Flexible service oriented architecture

5.3.1 Business Processes In the SKF Business Case we are dealing with business processes in two different aspects:

• The business processes which are used SKF internally to adapt, build and operate a new service.

Based on SCOR Model Version 7.0Copyright 2005 H2O Business Process Training Center EuropeINCOCO Inhouse Workshop Herb Heinzel December 2005

TO-BE SKF Processes Level 2

SKF Service Division

P2/7 P3/8

BxS3

Customers

Ox

P7 P8 P9

A2 O2B2

P2/7 P3/8 P4/9

Suppliers

S1 D1M1

S2 D2M2

P1 Plan Supply Chain

A2 O2B2S2

P4/9

DxMx

P6 Plan Service Supply Chain

Naiden

SAP

SUN Lang Papier(ASP, offline,

Terminalserver)

Steag(ASP, online,

Terminalserver)

A2 B2CC

B2

S1

D3

• The business processes which are existing on the customer site and to which the SKF services have to be integrated.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 71

Based on SCOR Model Version 7.0Copyright 2005 H2O Business Process Training Center EuropeINCOCO Inhouse Workshop Herb Heinzel December 2005

TO-BE SKF Processes Level 2

SKF Service Division

P2/7 P3/8

BxS3

Customers

Ox

P7 P8 P9

A2 O2B2

P2/7 P3/8 P4/9

Suppliers

S1 D1M1

S2 D2M2

P1 Plan Supply Chain

A2 O2B2S2

P4/9

DxMx

P6 Plan Service Supply Chain

Naiden

SAP

SUN Lang Papier(ASP, offline,

Terminalserver)

Steag(ASP, online,

Terminalserver)

A2 B2CC

B2

S1

D3

As one of the main objectives in the project is the connectivity of SKF applications to other (ERP-) systems, the focus should be on the interface to the business processes at the customer site.

The key function of information technology is to support and optimize corporate processes. Accordingly, IT strategy should reflect corporate strategy. IT architectures need to be documented, analyzed, and optimized from a business process perspective.

Detailed analysis requires knowledge of the exact nature of the processes in the different parts of the organization and recognition of the impact of implementing interfaces to systems

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 72

from other suppliers e.g. SKF. The importance of this work lies in the fact that harmonizing processes is the key to harmonizing systems.

IS functions (information system functions) form the link between business processes and IT systems by describing a system in terms of functionality.

This allows them to be reused in business processes to document the IT system functionality required by a specific business function.

5.3.2 Measures of Performance Key Performance Indicators (KPIs) provide vital information to the organisation for tracking and predicting business performance against strategic objectives in a way that compliments financial measures.

KPIs can be part of a corporate-wide Balance Scorecard implementation or can be used to monitor each individual business function. By measuring and monitoring operational efficiency, employee performance and innovation, customer satisfaction, as well as financial performance, long term strategies can be linked to short term actions.

As mentioned in the previous section the focus for the TO-BE situation should be on the interface definition, therefore KPIs for this individual business function have to be defined.

Possible KPIs for the service provider could be:

• Number of sold products (interfaces).

• Profit margins.

• Delivery performance.

Possible KPIs for the service consumer could be:

• Breakdowns (BU).

• Unscheduled Maintenance (UM).

• Scheduled Maintenance (SM).

The definition of suitable KPIs (both for the service provider and the service consumer) should be part of the TO-BE process definition.

5.3.3 Coordination Mechanism and Information System

One of the main requirements is to create a seamless interconnection between IT and process architecture in a single repository to fully align IT systems with business needs.

Benefits include being able to identify which critical business processes at which locations are affected and will therefore need to be part of the implementation project when installing an IT system for condition monitoring with interface to other enterprise systems.

Planners and IT managers can navigate the entire enterprise architecture, following object relationships, and take informed decisions based on a holistic view of the company and a shared methodology.

Users can compare the IT standards and target architectures defined in the repository with the actual situation and create together with SKF a roadmap for future development.

In addition to designing enterprise architectures, companies can use this functionality to set up process and IT portals.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 73

Bringing together business process design and IT architectures allows coordinated management of these two areas, enabling the kind of integrative approach that is particularly important for successful enterprise architecture management, given the interdependency of processes and IT structures.

By providing a framework (following industry standards) a pluggable solution can be realized which can be easily integrated into the customer IT landscape by use of e.g. BPEL for the orchestration of new and existing services.

Figure 25 Pluggable solution for SKF and customer IT systems integration

It is important to note that BPEL is based entirely on Web Services. Web Services provide a way to communicate over a network in an open and flexible way based on XML.

What BPEL does, is offer an open standard to make a flexible coupling between several systems. Because BPEL works with Web Services it is possible to connect systems that can be any where on the planet, as shown in the picture below for an interface between an ERP and a CRM application; a similar solution should be achieved for the interface between the SKF condition monitoring systems and the ERP application from SAP.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 74

Figure 26 Interface between and ERP and a CRM application

After having realized a seamless interconnection between the IT systems the challenge becomes the proper use of the measured data. A decision support system (DSS) for indicating optimal maintenance schedules already exists. These schedules, however, cannot always be realized directly because of restrictions imposed by the production schedules of the clients of SKF.

Hence, there is a need for a coordinated planning of the proposed maintenance activities of SKF and the production planning of a client. The figure below shows the information exchange between SKF, a client and the maintenance service providers.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 75

Figure 27: Information exchange between SKF, its clients and maintenance service providers

SKF is interested to learn whether the client will execute the maintenance activities according to the proposals made by the decision support system of SKF because threshold values for analysing sensor data may have to be adapted. This coordination can only be realized with a client using an APS, whose number is expected to increase in the future.

The coordination with a maintenance service provider is not part to the system to be studied.

5.3.4 Requirements Summary

• Focus should be on the interface to the business processes at the customer.

• Bringing together business process design and IT architectures allows coordinated management of these two areas.

• By providing a framework (following industry standards) a plug-able solution can be realized which can be easily integrated into the customer IT landscape.

• Derivation of a possible maintenance schedule with the help of the DSS and communication of this schedule to the client or even alternative schedules for certain maintenance activities with different risk levels for a premature breakdown.

• Evaluation of the maintenance schedule by incorporating and adapting it into the client’s production plan (for the flow-line).

Production plan including

maintenance service

Client

Analyse

Sensor data

SKF

Diagnosis & maintenance activities in certain time frame

Maintenance service providers

SKF

Invitation to offer Offer with price & time frame of activities

... ...

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 76

Figure 28 SKF Service Division – Customer interface

5.3.5 Conclusion For implementing adaptable services and integration concepts for the customer the following obstacles need to be overcome:

• Organizational culture and project orientation The needs of the business as a whole will not be considered, and generalized services that may be applicable elsewhere will not be delivered.

• Short term thinking The pressure to meet immediate requirements leaves no scope to discuss future needs. This might not in itself prevent IT from trying to introduce service oriented principles, but makes it difficult to discuss and agree them with the business.

• Business Secrecy Whilst the business may desire agility, it may not necessarily want to share with IT the business strategies that might require agile solutions.

• Ability to abstract and generalize The skills required are not always common in developers, particularly if it also requires sufficient familiarity with the business to be able to abstract and generalize the business concepts.

If businesses are to become more agile then they must address these issues. Business leaders cannot continue to complain about the IT department's apparent lack of responsiveness to change when its own practices can create the above obstacles. Similarly the IT department must also play its part in designing agility into their solutions.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 77

6 Business case 4: SIGPACK

6.1 AS-IS situation

6.1.1 Company Portrait - Description of the typical customer Bosch Sigpack Packaging Services consists of four service hubs and a central Service Business Competence Center (SBCC). SBCC is one division in Bosch Packaging Services, and is, just like the rest of the service organisation, kept like it was in the Sigpack Services organisation. SBCC is responsible for all migration processes of the new Centre of Competences (CoCs) in the service concept, which will say all CoCs which did not belong to Sigpack AG before the acquisition. The migration processes include all B2B processes (inter-company processes), logistic processes and pricing processes of spare parts and services. In addition it offers order process services and monitoring services to the CoCs and to the customers. The B2B processes, the processes between the service hubs and the CoCs, are supported by an SAP system, which the SBCC is responsible for and also operates.

The Bosch Packaging Services headquarter is in Neuhausen in Switzerland. Bosch Packaging Services is a business unit of the Bosch Packaging Group, which belongs to Robert Bosch GmbH. Bosch Packaging is an internationally operating company with the focus on packaging technologies. It employs a total of 5000 people, whereas about 200 people work within the services unit. In 2004 the sales amount was 893 Mio Euro in total, with an export share of 91%. The following figure shows the organizational structure of the services unit.

SBU Packaging Services (PA-CS) Status: 06.09.2005

SLU Ecublens

PartsFrank TarrPAGB/SPS

Finance / ControllingHelen Millington

PAGB/CTG

Finance / ControllingTodd TorreyPAUR/CTG

PartsJennifer Beushausen

PAUR/SPS

ModernizationMarcello Pezzotti

PACE/EMO

SalesRichard Ofield

PAGB/SAL

PartsSacha CeriniPACE/SPS

Field ServiceEugen SchiblPACE/EFS

SLU France / PAFS

Field ServiceMartin OrgillPAGB/EFS

ModernizationBruno Innocenti

PAUR/EMO

SalesJohn HrivnakPAUR/SAL

SLU Germany / PADS

Finance / ControllingDanilo RossiPACE/CTG

Field ServiceJames Ludwig

PAUR/EFS

SalesMarco KohlerPACE/SAL

Hub UK (PAGB)Gary Anderton

PAGB/GM

Hub USA (PAUR)Harold CarrPAUR/GM

Hub EURO (PACE)Fritz SchützPACE/GM

Bus. Competence CenterDr. Urs HafenPA-CS/SBC

SBU Management Team

Packaging Services (PA-CS)Dr. Roman Hänggi

PA-CS/GP

LogisticsKlaus RüttlerPA-CS/CLP

Logistics ControllingRoger Mächler

PA-CS/CLP

PricingMarkus Blessing

PA-CS/SCP

ProcessesMarcel Bischof

PA-CS/PJM

ProjectsMarcus Setterberg

PA-CS/PJM

Eng. OperationsDave Crossley

PAGB/EOP

OperationsMerle GreerPAUR/SOP

SLU Weert

SLU Ecublens

PartsFrank TarrPAGB/SPS

Finance / ControllingHelen Millington

PAGB/CTG

Finance / ControllingTodd TorreyPAUR/CTG

PartsJennifer Beushausen

PAUR/SPS

ModernizationMarcello Pezzotti

PACE/EMO

SalesRichard Ofield

PAGB/SAL

PartsSacha CeriniPACE/SPS

Field ServiceEugen SchiblPACE/EFS

SLU France / PAFS

Field ServiceMartin OrgillPAGB/EFS

ModernizationBruno Innocenti

PAUR/EMO

SalesJohn HrivnakPAUR/SAL

SLU Germany / PADS

Finance / ControllingDanilo RossiPACE/CTG

Field ServiceJames Ludwig

PAUR/EFS

SalesMarco KohlerPACE/SAL

Hub UK (PAGB)Gary Anderton

PAGB/GM

Hub USA (PAUR)Harold CarrPAUR/GM

Hub EURO (PACE)Fritz SchützPACE/GM

Bus. Competence CenterDr. Urs HafenPA-CS/SBC

Hub UK (PAGB)Gary Anderton

PAGB/GM

Hub USA (PAUR)Harold CarrPAUR/GM

Hub EURO (PACE)Fritz SchützPACE/GM

Bus. Competence CenterDr. Urs HafenPA-CS/SBC

SBU Management Team

Packaging Services (PA-CS)Dr. Roman Hänggi

PA-CS/GP

Packaging Services (PA-CS)Dr. Roman Hänggi

PA-CS/GP

LogisticsKlaus RüttlerPA-CS/CLP

Logistics ControllingRoger Mächler

PA-CS/CLP

PricingMarkus Blessing

PA-CS/SCP

ProcessesMarcel Bischof

PA-CS/PJM

ProjectsMarcus Setterberg

PA-CS/PJM

Eng. OperationsDave Crossley

PAGB/EOP

OperationsMerle GreerPAUR/SOP

SLU Weert Figure 29 Organisation of Service Business Unit (SBCC)

The machines and systems of the Bosch Packaging Group, together with related installations and trainings, are sold by the technology units themselves. The services unit, outsourced in 2001, is responsible for whole range of service-sales, i.e. spare parts and consumables supply, plus modernization and upgrade services. There are three so called "service hubs", which are single points of contact for the customers in Europe, the USA and the UK. A fourth hub in Japan is currently set up.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 78

Customers of the Bosch Packaging Group can be found in the food, pharmaceutical, chemical and cosmetics industries. The services unit offers a range of more than 100´000 spare parts, whereas most show a low or sporadic demand pattern. In 2004 the sales of the services unit amounted to a total of 47 Mio Euro.

6.1.2 Description of the service

The Sigpack Service Business Model The business model of Bosch Packaging Services builds on after after sales services; when the after sales guarantee has run out, the customer contacts one of the service hubs or one of the service centres belonging to the hub instead of the machine producer when they are in a need for some sort of service. Further, all services for the machine producers within the Bosch Packaging Technologies group are centralized to a few service centres, centres that have full competences for all technologies produced within the group. Still, this does not mean that all service technicians are physically centralized. Even though all administration and coordination of service is centralized to the five service hubs, regional, customer-close business is preserved through sub divisions working directly under the service hubs. For example the Euro hub today consist of 5 sub divisions; 2 in Switzerland, 2 in Germany and 1 in France.

Service Business ModelTechnology Service

• Business Set Up• Standard GlobalProcess

• Inter CompanyPolicy

Parts

Modernization

Field Service

Training

Parts

Modernization

Field Service

Training

Tevopharm in the US and UK Japan Hub without B2B

Euro Hub(today 5 locations)

UK Hub(today 1 location)

US Hub(today 3 locations)

Japan Hub(today 1 location)

Sigpack SystemsCenter ofCompetence

ServiceSupport

Sigpack SystemsCenter ofCompetence

ServiceSupport

SapalCenter ofCompetence

ServiceSupport

SapalCenter ofCompetence

ServiceSupport

DoboyCenter ofCompetence

ServiceSupport

DoboyCenter ofCompetence

ServiceSupport

TevopharmCenter ofCompetence

ServiceSupport

TevopharmCenter ofCompetence

ServiceSupport

Service Partner

Figure 30 Service business model of Bosch Packaging Services

Figure 30 again shows the service concept, with Sigpack Services acting as a broker for the customers and coordinating the services with the packaging plants.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 79

Bosch Packagingplants

Sigpack plants

Bosch Packagingplants

Sigpack plants

Bosch Packagingplants

Sigpack plants

SigpackServicesSigpackServicesSigpackServices

Complexity of a global service supply chain

Global Key accounts

Big plants

Small plants

Global Key accounts

Big plantsBig plants

Small plantsSmall plants

Figure 31 Coordination of services at Bosch Packaging Services

Range of Services Sigpack Services is responsible for the whole service-sales processes of the Bosch Packaging Group with its production facilities – the CoCs. The sales of the machines, together with the installation and related training, is conducted by the plants themselves. The range of service products, which Sigpack Services is responsible for, is shown in the forthcoming figure. In the special case of warranty situations, Sigpack Services is the point of contact for the customer, but they simply forward the incident to the responsible CoC, which then deals with it.

Wide Range of Service Products

PartsSpare PartsE-PortalSAP-SAP IntegrationAroma Protection Valves

ModernizationModernization KitsRebuild / RefurbishmentSize ChangeReconditionRental

Field ServiceRepairingPreventive MaintenanceTechnical AuditHelpdeskTele ServiceService Level AgreementEmbedded Engineer

TrainingClassroomBrush UpTrain the TrainerComputer based training

Figure 32: Services offered by Sigpack Services

In the followings the focus will be on the areas of spare parts delivery and field service.

Figure 32 provides an overview about the service business model of Sigpack Services. It shows the clear distinction between the technology area represented by the production plants of Bosch Packaging and the service area represented by Sigpack Services.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 80

The spare parts are sourced at the different production facilities within the whole packaging group. The service unit therefore appears as a reseller and pays a transfer price to the particular internal supplier, respectively the sales price to external suppliers. The selling price for the customer is calculated through a set of article, customer, country and quantity specific parameters. The transfer prices for internal suppliers are calculated following specific inter-company policies.

One big advantage of this service concept is, that the customer of Bosch packaging has one single contact for the service of his machine, namely his responsible service hub. These hubs can then conduct and plan the services more efficient, because they work as a broker or reseller and can better plan the capacities both of them and also of the internal suppliers.

6.1.3 “Movie” of the typical situation As already described in the previous chapter, Sigpack Services acts as a reseller for the spare parts of Bosch and Sigpack packaging machines. The parts themselves are often built in by mechanics from the customer himself, but he can also buy the field service from Sigpack Services. It is important to know, that there is a staff department called "Service Business Competence Center" (SBCC), which is responsible for the company wide logistics controlling, stock management and global pricing. The latter becomes important when pricing issues arise during quoting processes, e.g. when there is no price in the system or the actual price seems to have changed extraordinarily from an earlier quoted price. The SBCC then gets in contact with the responsible CoC and clarifies this issue, so that the service hub can continue with the quoting process.

In the normal case however, the SBCC plays no direct role in the service process, so that the following "movie" will not include this aspect. Before starting the description Figure 33 provides a first overview on the responsibilities of the actors in the AS-IS scenario.

customer

CoC /manufacturer

SBCC

parts /manpower

service hub

request for quote / order

offer / invoice

global pricinglogistics controllingstock management

request / order

manpower

price / delivery date“pro forma” invoice

price request price

SBCC – Service Business Competence CenterCoC – Center of Competence

quote offeridentify partsprice check

customer

CoC /manufacturer

SBCC

parts /manpower

service hub

request for quote / order

offer / invoice

global pricinglogistics controllingstock management

request / order

manpower

price / delivery date“pro forma” invoice

price request price

SBCC – Service Business Competence CenterCoC – Center of Competence

quote offeridentify partsprice check

Figure 33 Pricing process for services at SIGPACK SERVICES

The following table is giving a comprehensive description of interacting process between Sigpack Services and customers.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 81

Customer Sigpack Services

ADAPT PHASE

Because the spare parts delivery service is only reactive, there is not really an adaptation phase. This is because there usually is no outline agreement; contracts are the individual delivery orders.

BUILD PHASE

In order to efficiently obtain parts pricing data, Sigpack Services needs access to the relevant master data at the individual CoCs. For this purpose B2B interfaces are established between Sigpack Services' SAP and the CoCs' ERP systems.

For special customers an E-Portal is set up, which can be integrated in the customer's ERP system. In this portal information about the availability and the prices of the spare parts relevant for the customer is automatically provided in real-time. For this purpose the data interfaces need to be established.

CoCs have to be integrated into the performance measurement process. Currently only a measurement of one internal supplier (Sigpack Systems) is possible automatically.

OPERATE PHASE

When the customer identifies the need for a spare part, he calls his responsible service hub and inquires a quote for the requested spare parts.

If quote has to be created manually (without E-Portal), the service hub gathers the relevant information from the SAP system with the support of the B2B between Sigpack Services the CoCs. With this information the quote is created and sent to the customer.

In some cases there is the need to deal with pricing issues, what delays the quoting process. Then the SBCCC needs to clarify the price with the responsible CoC.

Having the offer of Sigpack Services (either a "manual" offer via fax or automatically through the E-Portal) the customer orders the desired parts (again, manually or via the E-Portal).

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 82

Customer Sigpack Services

The service hub receives the order. The responsible employee orders the individual parts at the particular CoCs and confirms the order to the customer with information about the scheduled delivery dates.

The customer receives the spare parts. When the particular CoCs have delivered the spare parts the service hub receives the inter-company invoices from the CoCs.

When all inter-company invoices for a customer order were received the customer invoice is created.

The customer invoice is received and paid by the customer.

The service hub receives the payment.

In regular intervals Sigpack Services proactively sends own logistical performance information to the customer in the form of so called "performance cockpits" (see specific chapter).

6.1.4 Performance measured The Performance measuring implies monitoring of Key Performance Indicators (KPIs) in the logistic processes between the customers, service hubs and CoCs. These performance measurements are part of a logistic controlling concept. It is so far only the spare parts and modernization services that are part of the performance measurement. Examples of KPIs measured are quotation lead time, delivery lead time, and sales statistic for the different service hubs. The aim of these performance measurements is to increase the performance- and process transparency and predictability, both for service hubs, CoCs and customers, to identify and create an understanding for areas of improvements, and for benchmarking between the different divisions within the Bosch Packaging group.

In order to improve the performance, SBCC is working with a “regulating circuit” for the processes between the service hubs and the CoCs goals are set and KPIs are defined. The monitoring, the logistic controlling, has the objective to identify areas of improvement in the B2B; processes are monitored and results are evaluated based on their variation to goal. And actions are defined in order to reach the target goals. This is a continuous process.

Why performance measurements in Bosch Packaging Services? Sigpack Services started with the logistic performance measurements in order

• to create a transparency in the processes between the service hubs and the CoCs, the B2B process, and

• to create transparency in the performance towards the customers.

A basic reason was that it was easy for the two parts, the service hubs and the CoCs, to blame each other for poor performance towards the customers as long as no one could see whether the process got stuck in the CoC or in the service hub. With the performance measurements Sigpack Services is creating transparency in the processes, to both identify the logistical

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 83

performance towards the customers and the performance of the different parts in the supply chain.

How and when are measurements done? The logistic performance measurements are done for the inter-company, B2B processes within the former Sigpack group. This means that processes between the service hubs, the suppliers – the CoCs, and the customers can be measured. The service hubs operate with a SAP business information system, while the CoCs operates different kinds of systems. Thanks to a B2B interface information still can be transferred between the different divisions; the interface works as a “data translator” and transforms the data from the CoC to fit the format of the service hub’s SAP system.

The measurements are based on data extracted from the service hub SAP system; when information comes into the SAP system from the CoC, when it goes from the SAP system to the CoC. Not having to get data from the CoC information systems or the customer’s information system is made possible through standardized reporting routines, which means that the CoC sends information when for example an order delivery is sent to a customer.

What is measured? Tracking of the processes between the CoCs, the service hubs and the customers are done in order to measure the logistical performance. These performance measurements are visualized in graphical charts, combined in different ways to create cockpits. Today three CoCs are measured: Sapal, Sigpack Systems (SPS) and Doboy. Also three hubs are part of the performance measuring system: Euro Hub, UK Hub and US Hub. This means that the hub sub divisions are not measured individually, but together, aggregated with the whole hub.

The logistic cockpits are the main measurements and are maintained for all service hubs and CoC’s, and measures logistic processes for spare part sales. As this is the main measurement, it will be described more in detail that the other. Some measurements in the logistic cockpit are made both from an external and internal point of view, i.e. either measurement of the time from an order or request for quotation comes to the service hub from the customer until the customer gets the delivery or quotation, or measurement of the time from that a request or order leaves the service hub for the CoC until the Service hub gets response. The external view can also be thought of as the customer view, as that is the performance the customer experience. All charts in the cockpit shows the measurements for the last 24 weeks. The following Figure 34 illustrates the design of the logistical cockpits.

Figure 34 Example of logistical cockpits

The logistic cockpits mainly measures:

• Quotation Backlog – How many request for quotations are in the pipeline, waiting for response? What is the estimated value of these quotations (the value of an eventual

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 84

order * estimated probability for an order). This is done from both an external and an internal view.

• Hit Rate – How many requests for quotations results in an order?

• Order Backlog – How many orders are in the pipeline? How many are overdue?

• Order Intake – The total value of the orders received per week.

• Quotation Lead Time – How many days, in average, goes from receive of a request for quotation until a quotation is sent back? Both from an internal and external view.

• Quotation Lead Time, detailed – The same as previous, but here with exact number of requests having a lead time bigger than x days.

• Delivery Order Lead Time – How many days it takes, in average, from an order is sent from the service hub to the CoC, until the service hub receives the delivery notification (which means that the delivery is on its way to the customer). From an internal point of view.

• Delivery Order Lead Time, detailed - The same as previous, but here with exact number of orders having a lead time bigger than x days. This chart is shown for the three previous weeks.

• On Time Delivery – How many orders have been delivered on time? 1 week too late? More than one week too late?

• On Time Delivery, detailed – The same as previous, but visualized in a way so that it is possible to see exactly when orders have been delivered, even how many that have been delivered too early. This chart is shown for the three previous weeks.

The customer cockpits are specifically made for three key customers. These measures:

• Quotation lead time.

• Order lead time – customer order date until the actual delivery date.

• Order process fulfilment – compares the time between receive of order with the, by the customer, requested date for delivery – i.e. customer’s expectations for delivery time.

• Order process fulfilment – customers requested delivery date compared to the actual delivery date – i.e. how the customers expectations can be met.

• Order process fulfilment – confirmed delivery date compared to the actual deliver date – i.e. Bosch Packaging capabilities to fulfil expectations set by themselves.

In addition to the cockpits, detailed lists, on which some of the measurements are based, are sent to the users. In this way they, to some degree, have the possibility to track, for example, exactly what quotations have not been followed up.

The following figure illustrates an overview set of KPIs measured in the spare parts delivery process.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 85

Figure 35 Overview of KPIs measured in the spare parts delivery process

6.1.5 Information given to the customer Sigpack Services is providing a comprehensive information E-Portal to the customer. All customers who have already a packaging machine in use are able to source relevant data for their order and information interests. Figure 36 shows the range of information served through the E-Portal. This E-Portal is not always used, but the information given "manually" via telephone and fax does not differ from the information given through the portal.

Figure 36 Information given to the customer via the E-Portal

The next figure is showing that Sigpack is providing more details for every part within their catalogue. On this deeper level the customer has the opportunity to ask for the global stock availability depending on the requested quantity of spare parts.

Purchasing status:

• Ready to order

• Blocked for purchasing

Demand characteristic:

• Wear and tear parts • Spare parts

Logistic status:

• Managed stock item

• Bulk stock item

Information availability:

• Price • Picture

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 86

Figure 37 Global stock availability is shown for all parts on E-Portal

Further on the customer has the opportunity to figure out which parts are installed in his individual machines. This gives him the chance to place correct spare parts offers.

6.1.6 Information required from the customer In order to process the inquiry and order appropriately, the customer has to provide information about the needed spare parts. This is the quantity and the part numbers needed. When the customer does not know this information ("unidentified parts"), he at least has to provide the machine type and number in which the needed part will be built in, and at best a picture of the part. With this information the service hub can identify the specific part, probably with the help of the CoC which delivered the machine.

Sometimes the specific part needed is not known ("The machine broke down, but we do not know what is wrong"); in this case the customer has to provide detailed information about the symptoms of the damage, so that the hub can clarify this issue with the responsible CoC.

6.1.7 Coordination need with customer production activities

In the AS-IS scenario there is no need to coordinate anything with the customer's production activities, because the service is reactive, and usually the customer installs the parts using his own mechanics.

6.1.8 Coordination tools currently used Towards the customer there is no real coordination tool being used. Inquiries and orders in most cases are processed using telephone, fax and email; the only exception is with customers having access to part price and availability information via the E-Portal. But this tool is one-way and no coordination tool in the definition of coordination.

Internally there is the B2B interface between Sigpack Services and the CoCs, which is used to get access to part price and availability information (including delivery lead times), as well as the placement of internal orders for relevant spare parts.

Global stock availability is shown

for all parts on E-portal

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 87

6.1.9 Criticalities perceived Because of the complex company structure with independent machine and respective spare part manufacturers (the CoCs), the main criticality is the transparency on prices of all parts and the logistical performance of every internal supplier. Following the defined structure for the task, criticalities in the AS-IS scenario are faced in the following areas:

Business processes and coordination mechanisms

• Parts pricing policies are not always followed correctly (wrongly priced parts, not-actual prices).

• Parts identification is not structured.

Information systems

• No transparency on prices including price history and structure from ALL CoCs.

• No transparency on logistical performance of ALL CoCs.

Performance measures

• Common set and understanding of KPIs for ALL CoCs.

• Common policy for utilization of performance information.

6.1.10 Link with the proposal business case In the development of the TO-BE scenario this business case matches fully the description of the BC IV from Annex 1. The desire for transparency on costs/prices and logistical performance is stressed.

6.1.11 Examples of problematic situations As indicated in previous chapters, there are examples of problematic situations in the following areas:

• Parts identification: sometimes the customer does not know the specific part needed. In this case the service hub has to identify the part together with the CoC from distance. This leads to a delay of the quoting process.

• Parts pricing issues: sometimes the customer complains about too expensive parts. If not decided to stick to the proposed price, the SBCC reviews and probably renegotiates the inter-company transfer price with the responsible CoC.

• Machine break downs: when the customer does not order spare parts for a scheduled replacement but because of a machine breakdown, the delivery time of the CoC becomes critical. There are situations where the CoC is not able to deliver the part as fast as desired by the customer.

6.1.12 Currently unsatisfied customer requirements

Since also for the presented basic service, customers more and more want information about the performance of their service providers, the earlier presented criticalities also apply for the topic of unsatisfied customer requirements. Especially main customers want to have this information, and Sigpack Services is not always in the position to provide it, in particular from an efficiency perspective. So, to repeat the unsatisfied customer requirements, these are:

• Transparency on prices of ALL parts.

• Transparency on performance of ALL suppliers (not only Sigpack Systems).

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 88

6.1.13 Business processes description In the following MS PowerPoint presentation the description of AS-IS processes is given.

1Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

200

6 w

ww

.inco

co.n

et

Man

ufac

ture

r Plan ControlPC

Plan ControlPC

Plan InteractPI

Plan InteractPI

Plan OutsourcePU

Plan OutsourcePU

Serv

ice

Prov

ider

Plan OperatePO

Plan OperatePO

Plan AdaptPA

Plan AdaptPA

Level 1 of InCoCo-S Model in Business Case IV „ASIS“

Plan BuildPB

Plan BuildPB

O 3.3O 3.3

O 3.2O 3.2

O 3.1O 3.1

No activities in the AS-IS situation belonging to InCoCo-S Model

2Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

200

6 w

ww

.inco

co.n

et

Cus

tom

erSi

gpac

k Se

rvic

e

S 1.1S 1.1

Business Case IV in chronological order „AS-IS“

O 3.3O 3.3O 3.2O 3.2O 3.1O 3.1

CoC

O 3.4O 3.4

D 1.3D 1.3 D 1.12D 1.12

S1.1 (Schedule product deliveries as in SCOR Model)

S 1.2S 1.2

S1.2 (Receive stocked product as in SCOR Model)

Physical flow of material

Information flowPerformanced measured: Order-lead-time

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 89

2Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

200

6 w

ww

.inco

co.n

et

Man

ufac

ture

r

B 3.3B 3.3 O 3.8O 3.8

Plan ControlPC 3.1+3.2

Plan ControlPC 3.1+3.2

Plan InteractPI 3.1+3.2

Plan InteractPI 3.1+3.2

Plan OutsourcePU

Plan OutsourcePU

Serv

ice

Prov

ider

Plan OperatePO 3.1+3.2

Plan OperatePO 3.1+3.2

Plan AdaptPA

Plan AdaptPA

U 3.1U 3.1 I 3.2I 3.2 C 3.2C 3.2

Level 1 of InCoCo-S Model in Business Case IV „TOBE“

A 3.2A 3.2A 3.1A 3.1 B 3.2B 3.2

B 3.1B 3.1

Plan BuildPB 3.1 +3.2Plan BuildPB 3.1 +3.2

I 3.1I 3.1

O 3.3…3.7O 3.3…3.7O 3.2O 3.2

O 3.1O 3.1

C 3.1C 3.1

An overview of the OPERATE process in regards to the classic SCOR model is also given in the following figure.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 90

Figure 38 AS-IS business processes OPERATE with regards to SCOR

6.2 TO-BE situation

6.2.1 Description of the typical customer The customers for the TO-BE service are the same as in the AS-IS scenario.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 91

6.2.2 Description of the service In the AS-IS scenario Sigpack Services provides only basic services, with the focus on spare parts supply. In the TO-BE scenario Sigpack Services wants to bundle services to full packages, resulting in a comprehensive management of machine maintenance. The vision is to finally be in the position to really operate the packaging machines for the customer. However, in InCoCo-S' Sigpack Services wants to establish the foundation to be in the position to first offer full maintenance services. This is visualized in the next figure.

„Manage Packaging Service“

Basic Service Productsfor Sigpack and BOSCHpackaging machines

• Spare parts supply• (Field Service)• (Modernization)

Bundled Services to full packages

• Service Level Agreements• Efficiency Programs• Embedded Engineer• Coordination Mngmt

PRICING

LOGISTICSCONTROLLING

AS-IS TO-BE

ENABLERS

Customer orders servicesService is re-active

Sigpack Services coordinates activitiesService is pro-active

„Basic Service Products“

PROCESSES

„Manage Packaging Service“

Basic Service Productsfor Sigpack and BOSCHpackaging machines

• Spare parts supply• (Field Service)• (Modernization)

Bundled Services to full packages

• Service Level Agreements• Efficiency Programs• Embedded Engineer• Coordination Mngmt

PRICING

LOGISTICSCONTROLLING

AS-IS TO-BE

ENABLERS

Customer orders servicesService is re-active

Sigpack Services coordinates activitiesService is pro-active

„Basic Service Products“

PROCESSES

Basic Service Productsfor Sigpack and BOSCHpackaging machines

• Spare parts supply• (Field Service)• (Modernization)

Bundled Services to full packages

• Service Level Agreements• Efficiency Programs• Embedded Engineer• Coordination Mngmt

PRICING

LOGISTICSCONTROLLING

AS-IS TO-BE

ENABLERS

Customer orders servicesService is re-active

Sigpack Services coordinates activitiesService is pro-active

„Basic Service Products“

PROCESSES

Figure 39 From the AS-IS to the TO-BE service

So in this scenario there is at least one service engineer from Sigpack Services at the customer's production site ("embedded engineer"), who is responsible for the supervision of the packaging machines and the planning, coordination and conduction of maintenance services, with the goal to increase the efficiency of the packaging process and to prevent the installed machine basis in terms of unforeseen breakdowns.

Under the responsibility of the embedded engineer falls the decision on maintenance activities. He does not decide on modernization of machines, but makes proposals to the customer, who then can decide whether machines should be modernized or not. Another activity still to be undertaken by the customer is the review of the service activity schedule, as proposed by the embedded engineer, with his production schedule. Everything else is the decision of the embedded engineer.

6.2.3 “Movie” of the typical situation The TO-BE interaction processes are illustrated again in the comprehensive table format. Because the TO-BE service is way more comprehensive than the AS-IS, there is, from the perspective of Sigpack Services, only one process comparable to the AS-IS (please see particular process in the OPERATE phase). However, Sigpack takes over several processes previously in the responsibility of the customer.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 92

Customer Sigpack Services

ADAPT PHASE

When the customer decides on an outsourcing of maintenance activities for his packaging line he contacts Sigpack Services to get an offer for this service.

Sigpack Services together with the customer defines the goals, scope, team and time for a technical audit of the customer's packaging line, in order to get familiar with the business setting and to derive the requirements for the future maintenance service.

With the results from the technical audit Sigpack Services creates an offer for the conditions of the future service. This includes a long-term efficiency increase plan.

Both parties negotiate and finally sign the contract.

BUILD PHASE

Sigpack Services and the customer align the business processes and train the responsible actors in order to familiarize them with the future setting of processes and responsibilities.

Sigpack Services establishes the needed information systems, to serve the embedded engineer with the needed information from the customer's production data and the internal transparency on prices and performances.

Sigpack Services develops a detailed schedule for upcoming maintenance activities, in order to provide the packaging machine availability and in the long run meet the agreed efficiency increase targets.

OPERATE PHASE

The embedded engineer monitors and regularly checks the packaging line, in order to always have a current status on wear and efficiency of machines.

(Process taken over from customer)

Having the real-time status of the machines, the engineer, schedules and rolling maintenance activities.

(Process taken over from customer)

The customer reviews the maintenance schedule in regular intervals and, if necessary, reschedules activities together with the engineer, taking into account his production schedule.

The engineer coordinates the conduction of the maintenance activities, i.e. sourcing of

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 93

Customer Sigpack Services spare parts and, if needed, engineers from suppliers. This can also include a sourcing of services like cleaning.

(This process is the only process similar to the AS-IS situation)

When the needed resources are available and the maintenance activity is due, the engineer carries out the service.

(Process taken over from customer)

In regular intervals the engineer reports to the customer about the performance of his maintenance activities and the packaging process.

6.2.4 Performance measured The internally measured logistical performance equals the ones in the AS-IS scenario. The only KPI not necessary anymore is the measurement of quotation lead time towards the customer. However, the internal quotation lead time, i.e. the time a (internal) supplier needs to quote towards the embedded engineer, will still be measured.

In addition to the earlier scenario there will be a measurement of technical performances regarding the efficiency of the packaging lines on the customer sides. These KPIs are representing possible new measures and will be developed and evaluated in WP4. The following technical KPIs could consider the following items:

• Downtimes of the packaging machines.

• Machine efficiency in terms of:

o output rate;

o waste rate;

o energy consumption;

• "Perfect order fulfilment" towards parts and required man power including external suppliers.

The scope of the measures will be also enlarged, considering that beside the internal CoCs of Bosch Packaging also external suppliers will be measured, e.g. providers of cleaning services. This results in a higher complexity of the performance measurement setting.

6.2.5 Information given to the customer Compared to the AS-IS situation there is a shift in the information given to the customer. The information is not the price and availability of parts anymore, but the following:

• maintenance activity schedule on different levels and timeframes;

• logistical performance reports on demand;

• packaging process performance reports on demand;

• individual machine performance reports on demand.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 94

6.2.6 Information required from the customer With new customers every installed packaging machine at the customers location will be evaluated before setting up the service contract based on machine data from recent years. Number of services undertaken, breakdown time and reasons, frequently used spare parts and repair kits are of special interest for a common understanding of the actual machine condition. In a next step after the contract has been setting up, to fully integrate the embedded engineer on the customer side there is a basic need to collaborate in terms of packaging machine utilization. The alignment of customer production schedules and packaging machines maintenance service schedule is one of the embedded engineers operating tasks. The required information will be mainly provided by the customers ERP- System. For packaging machine process re-engineering and improvement purposes relevant data should be exchanged with the customer to synchronize surrounding processes. Beside these basic information streams there will be several more fields of information exchange which will be elaborated in further research activities in InCoCo-S WP3 and WP6.

6.2.7 Coordination need with customer production activities The explained coordination and information exchange of production activities is crucial to guarantee high availability and efficiency of packaging machines. The customer’s production and machine utilization plans are essential to align necessary maintenance services with required availability.

6.2.8 Coordination tools in future scenario used At this stage it is not decided if Sigpack Services is aiming to provide the embedded engineer with an integrated tool to manage the extended packaging service as described in the TO-BE scenario. The common MS-office applications are offering most of the required features to coordinate and manage packaging service.

6.2.9 Criticalities perceived In the TO-BE situation some criticalities faced in the AS-IS situation will be solved. However, some will also remain critical aspects and should be considered well during the development of the aimed for standard repository. An overview is provided as followed:

Business processes and coordination mechanisms

• Thanks to the to be developed IT tool providing transparency on internal costs, which should cover all internal suppliers, pricing policies can be controlled more easily.

• Parts identification will be done by the embedded engineer at the location of the customer, so the problem of unidentified broken parts will be minimized.

Information systems

• No transparency on prices of the CoCs will be provided. Remaining aspect is the transparency on the prices of 3rd party service providers, which will be hard to achieve.

• Transparency on logistical performance of the CoCs will be provided. Remaining aspect is the transparency on the performance of 3rd party service providers.

Performance measures

• Common set and understanding of KPIs for ALL CoCs will be provided.

• Common policy for utilization of performance information will also be provided.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 95

6.2.10 Link with the proposal business case Sigpack Services AG (SIGPACK) offers a broad range of service products for spares, maintenance and repair service and has experience with proactive service offerings in the different market region (UK, USA, EUROPE). Different contract and business models have already been explored together with customers, for example:

• Embedded engineers: SIGPACK Service engineers as temporary part of the maintenance team of a customer. Performance based incentive system.

• Service Level Agreements: configurable, contract based service offering with guaranteed availability and response time (on site and remote service support).

• Planned revisions / inspections: single shot, fixed price interventions to optimize performance of a line.

• Productivity audits: efficiency consulting for a specific packaging system.

An increasing number of customers show interest in entering an outsourcing agreement. SIGPACK Service would have to take over the complete maintenance activities of a packaging system in cooperation with several service providers. For this reason SIGPACK Services would like to evaluate the current proactive service offerings to quantify the added value for their customer and identify possible other values which could provided to the market. SIGPACK wants to explore the business opportunities to establish synergies with its customers and other service providers (WP3). These coordinated mechanisms need to be validated in a test environment (WP6) before the actual implementation in SIGPACK business systems. In particular SIGPACK expressed the concern to further enrich the performance measures & develop coordinated incentive schemes (WP4) in order to provide the basis for new business models. The motivation to provide service solutions to the customer has driven SIGPACK to commit them in the InCoCo-S proposal.

6.2.11 Examples of probable problematic situations Because of the more comprehensive service scenario in the TO-BE problematic situations also applicable in the AS-IS will be stressed. This targets mainly delays of spare parts at the customer resulting in several problems. Planned services need to be postponed because of production priority. The rescheduling of maintenance services can have a strong impact on the packaging quality of the concerned machines. Furthermore, it is not clear who is responsible for the resulting costs of breakdown situations of overdue machines. The rescheduling of the service needs to be done in cooperation with the customer’s machine capacity planning schedule which is time and money consuming.

In case of a machine break down the customer will be confronted with lost machine running time with all resulting consequences such as delayed production of products. In any case the customer will be finally unsatisfied in terms of delayed or wrong parts. Sigpack Services has to take care of all customer complaints which are definitely resulting in higher administration and transaction costs per part.

6.2.12 Unsatisfied customer requirements As already mentioned Sigpack's customers expect highest availability and efficiency of packaging machines along the production line. In the TO-BE scenario Sigpack Services will take over the responsibility for the availability and efficiency of the packaging machines. Because this service needs production activities stopped, there will be the need for a trade-off between the customer's requirement of a running packaging process and Sigpack's requirement to maintain and upgrade packaging machines.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 96

6.2.13 Business processes description

2Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

200

6 w

ww

.inco

co.n

et

Cus

tom

er

B 3.3B 3.3

O 3.8O 3.8

Sigp

ack

Serv

ice

U 3.1U 3.1

I 3.2I 3.2C 3.2C 3.2

Business Case IV in chronological order „TOBE“

A 3.2A 3.2

A 3.1A 3.1

B 3.2B 3.2

B 3.1B 3.1

I 3.1I 3.1

O 3.3O 3.3

O 3.2O 3.2

O 3.1O 3.1

C 3.1C 3.1

CoC

O 3.4O 3.4

O 3.5O 3.5

O 3.6O 3.6

O 3.7O 3.7

D 1.3D 1.3 D 1.12D 1.12

1Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

200

6 w

ww

.inco

co.n

et

Plan Outsource (PU)

Input: Inquiry, cost & pricing data, performance cockpits, Spare Part availability

Output: Offer

Process Customer Inquiry

ManufacturerManufacturer

Decide about Making or Buying

Input: Service Operating Costs

Output: Requirements

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 97

1Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

200

6 w

ww

.inco

co.n

et

Outsource U3.1

Input: Customized Service Offer, Operating Costs + Pricing Data

Output: Packaging Service Contract for Maintenance Service

Negotiate Service Offer

1Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

200

6 w

ww

.inco

co.n

et

Adopt A3.1

Input: Data from the installed machine base and historic maintenance data at the customer, cost & price data

Output: Customized Service Offer for customer based on FACT SHEET

Technical Audit

KPI: Technical Audit Costs

1Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

200

6 w

ww

.inco

co.n

et

Adopt A3.2

Input: Customized Service Offer, cost & price data

Output: Contract between BOSCH Sigpack Services and customer

Negotiate Service Offer

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 98

1Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

2006

ww

w.in

coco

.net

Plan Adopt (PA)

Input: Inquiry, cost & pricing data, performance cockpits, Spare Part availability

Output: Offer

Process Customer Inquiry

Service ProviderService Provider

Decide about Making or Buying

Input: Requirements Customer

Output: Sigpack Services Audit Plan

1Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

2006

ww

w.in

coco

.net

Plan Interact (PI) PI3.1

Input: Inquiry, cost & pricing data, performance cockpits, Spare Part availability

Output: Offer

Process Customer Inquiry

ManufacturerManufacturer

Plan TO BE Maintenance

Input: Organization Structure, AS-IS Process, Contract

Output: Future Maintenance Process (Handbook, Checklist)

1Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

200

6 w

ww

.inco

co.n

et

Plan Interact (PI) PI3.2

Input: Inquiry, cost & pricing data, performance cockpits, Spare Part availability

Output: Offer

Process Customer Inquiry

ManufacturerManufacturer

Plan future Data Interfaces

Input: AS-IS IT Architecture, Future MaintenanceProcess

Output: Future Data Interfaces

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 99

1Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

2006

ww

w.in

coco

.net

Interact I3.1

Input: Future Maintenance Process, Contract

Output: Hand-over management report (process, information…)

Implement future (maintenance) process(integrate “embedded engineer”)

1Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

2006

ww

w.in

coco

.net

Interact I3.2

Input: Future Data Interfaces

Output: Hand-over management report (IT)

Setup Data Interfaces

1Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

200

6 w

ww

.inco

co.n

et

Build B3.1

Input: Future Maintenance Process, Contract

Output: Hand-over management report (processes, information…)

Implement future (maintenance) processes(integrate „embedded engineer“)

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 100

1Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

2006

ww

w.in

coco

.net

Build B3.2

Input: Future Data Interfaces

Output: Hand-over management report (IT)

Setup Data Interfaces

1Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

2006

ww

w.in

coco

.net

BUILD B3.3

Input: Packaging process efficiency data (technical audit)

Output: Concrete work plans for installed machine base

Create & Plan increasing of efficiencyof packaging process

1Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

200

6 w

ww

.inco

co.n

et

Plan Build (PB) PB3.1

Input: Inquiry, cost & pricing data, performance cockpits, Spare Part availability

Output: Offer

Process Customer Inquiry

Service ProviderService Provider

Input: Organization Structure, AS-IS Process,Contract

Output: Future Maintenance Process(Handbook, Checklist)

Plan TO-BE Maintenance Service processes

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 101

1Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

2006

ww

w.in

coco

.net

Plan Build (PB) PB3.2

Input: Inquiry, cost & pricing data, performance cockpits, Spare Part availability

Output: Offer

Process Customer Inquiry

Service ProviderService Provider

Input: AS-IS IT Architecture, Future MaintenanceProcess

Output: Future Data Interfaces

Plan future Data Interfaces

1Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

2006

ww

w.in

coco

.net

Control C3.1

Input: Service activities plan

Output: Alignments confirmed

Review Service Execution plan

1Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

200

6 w

ww

.inco

co.n

et

Control C3.2

Input: Service Performance Report, Contract

Output: Approval of Service Performance

Control Packaging Service Performance

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 102

1Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

2006

ww

w.in

coco

.net

Operate O3.1

Input: SLA, machine utilization plans

Output: Production resources status report

Monitor Production Resources

KPI: Machine efficiency, waste rate

1Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

2006

ww

w.in

coco

.net

Operate O3.2

Input: Service activity plan

Output: Resource assignment report

Reserve Resources

1Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

200

6 w

ww

.inco

co.n

et

Operate O3.3

Input: Service activity plan

Output: (Internal) order for service resource

Create (Internal) Order

KPI: reaction time

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 103

1Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

2006

ww

w.in

coco

.net

Operate O3.4

Input: Service resource

Output:

Receive Delivery

KPI: in time delivery, lead time,perfect order fulfillment

1Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

2006

ww

w.in

coco

.net

Operate O3.5

Input: Service resource

Output: Resource assignment report

Store Resource

1Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

200

6 w

ww

.inco

co.n

et

Operate O3.6

Input: Resource assignment report

Output: Consolidated service resource transportation

Transfer Resources to Customer at Planned Date

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 104

1Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

2006

ww

w.in

coco

.net

Operate O3.7

Input: Consolidated service resource transportation

Output: Service activity

Conduct Service Activity

KPI: machine downtimes, perfect order fulfillment(parts & man power)

1Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

2006

ww

w.in

coco

.net

Operate O3.8

Input: Production Resources Service Report

Output: Service Performance Report

Report Packaging Service Performance

KPI: machine downtimes, perfect order fulfillment(parts & man power)

1Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

200

6 w

ww

.inco

co.n

et

Plan Operate (PO) PO3.1

Input: Inquiry, cost & pricing data, performance cockpits, Spare Part availability

Output: Offer

Process Customer Inquiry

Service ProviderService Provider

Input: Service Logistics Controlling Data, spare part & field service availability

Output: Service resources availability report

Identify, Assess & Aggregate Service Resources

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 105

1Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

2006

ww

w.in

coco

.net

Plan Operate (PO) PO3.2

Input: Inquiry, cost & pricing data, performance cockpits, Spare Part availability

Output: Offer

Process Customer Inquiry

Service ProviderService Provider

Input: SLA, Production resources status report, Service resources availability report

Output: Service activity plan for “pro active”services

Schedule Service Activities

6.3 Definition of the requirements Summarizing what needs to be done to facilitate changes from AS-IS to TO-BE, this section is showing some basic requirements structured into Business Processes, Measure of Performance and Coordination mechanisms and Information systems.

In the previous slides the AS-IS situation and the TO-BE scenario are described in Level 1 (or even in more detail).

In the following slide the requirements to move from the AS-IS to the TO-BE situation is depicted.

2Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

200

6 w

ww

.inco

co.n

et

Man

ufac

ture

r

B 3.3B 3.3 O 3.8O 3.8

Plan ControlPC 3.1+3.2

Plan ControlPC 3.1+3.2

Plan InteractPI 3.1+3.2

Plan InteractPI 3.1+3.2

Plan OutsourcePU

Plan OutsourcePU

Serv

ice

Prov

ider

Plan OperatePO 3.1+3.2

Plan OperatePO 3.1+3.2

Plan AdaptPA

Plan AdaptPA

U 3.1U 3.1 I 3.2I 3.2 C 3.2C 3.2

Alignment of requirments in „TOBE“

A 3.2A 3.2A 3.1A 3.1 B 3.2B 3.2

B 3.1B 3.1

Plan BuildPB 3.1 +3.2Plan BuildPB 3.1 +3.2

I 3.1I 3.1

O 3.3…3.7O 3.3…3.7O 3.2O 3.2

O 3.1O 3.1

C 3.1C 3.1

IS1 IS2

CM

IS1 IS2

PM1 PM2

PM3

PM4

PM5

CM

D1D1

IS1 IS2

BPx

BPx

In order to understand the slide a glossary is shown below to understand the connection between the requirements and the activities in the TO-BE scenario.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 106

6.3.1 Business Processes

• Standard processes for future Maintenance Services as a basis for customizing collaboration process

• Standard process for the coordination of maintenance schedules in terms of time and capacities (BP1)

6.3.2 Performance measures

• Standard set of performance measures valid for all actors (PM1)

• Select relevant KPIs for full service efficiency (technical KPIs) (PM2)

• Definition of KPIs to communicate to customer in the sense of value-added (PM3)

• Cost and market pricing transparency (PM4)

• Ability to include contractual performance targets (PM5)

6.3.3 Coordination mechanisms

• Defined set of information relevant for service activity planning (service planning guide) (CM1)

• Standard scheme for the coordination of activities of several actors (i.e. 3rd party service providers) (CM2)

6.3.4 Information Systems

• IT-tool to provide transparency about performance of service operation / evaluate and visualize defined KPIs automatically (IS1)

• IT-tool to provide transparency about internal service operating costs and market pricing (IS2)

1Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

200

6 w

ww

.inco

co.n

et

Gap Description of TO-BE Scenario (I)

Step forward from classic spare part supplier to new real service provider:

Collaboration perspective:Joint, interdisciplinary technical audit teamsPackaging process re-engineering and modernization proposalsIncluding e.g. embedded engineers monitoring packaging processes and conducting service activitiesPermanent balancing of machine capacity utilization and maintenancerequirements in SLAReporting of increased machine efficiency to the customer (pay back reporting)

Process perspective:Remodeling of maintenance planning & coordination processesProbably integration of third-party service providersStrong need for monitoring of internal processes in regards to efficiency and costs (remember: SLAs!)

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 107

1Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

200

6 w

ww

.inco

co.n

et

Gap Description of TO-BE Scenario (II)

IT-Perspective:Access to customer’s ERP & PPS dataCoordination of several IT-tools

Spare part availability toolDecision Support Tool for PricingLogistical Performance measurement toolEfficiency analysis check

Additional element: value added at customer’s production siteTo be able to price service appropriately and fairlyUsed for communication to customer

The transparency about costs and logistical performance (incl. availability of resources) is the outstanding requirements enabling the move from AS-IS situation to the TO-BE scenario. There is an essential need for this transparency in order to make appropriate offers in TO-BE scenario and to decide properly on service activity schedules. The technical performance measures in regards to the increasing efficiency of packaging machines (value-added for the customer) are also of special interest.

Standard Data Interfaces which are not restricted to SAP will facilitate access to customer’s production & capacity planning data and will enable integration of 3rd-party service providers (SMEs).

Essentially defined processes are necessary between Sigpack Services and SME due to the fact that the TO-BE scenario is open for taking over MRO for SMEs.

The benefits for SMEs are reported in the following slide.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 108

3Business Case Sigpack Services, ETH Zurich, May 2006

©In

CoC

o-S

200

6 w

ww

.inco

co.n

et

SME Benefits

Opportunity of being integrated in global Service OrganizationMake use of implemented international Service Business Model Ability to enhance service portfolioOptimize service efforts (efficiency)Save costs for setting up similar organization

Investments in instruments and tools for proactive service checks technicalauditService personnel trainings (knowledge & know how)

– Intercultural skills, Language, country specific conditionsParticipate in Main Service Organization company‘s scale effects

6.3.5 Requirements Summary

Business Processes & Coordination mechanisms

• Defined process- and workflow for service activity planning

• Defined set of information relevant for service activity planning (service planning guide)

Performance measures

• Standard set of performance measures valid for all actors

• Select relevant KPIs – KPIs for full service efficiency

• Definition of KPIs to communicate to customer in the sense of value-added

• Cost and market pricing transparency

• Able to include contractual performance targets

Information Systems

• IT-tool to provide transparency about performance of service operation / evaluate and visualize defined KPIs automatically

• IT-tool to provide transparency about internal service operating costs and market pricing

7 Key requirements

InCoCo-S business cases have been carried out, each one focusing on a specific industrial service, ranging from the SOURCE to the MAKE and DELIVER phases of the supply chain.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 109

Inevitably different specificities have emerged and peculiar requirements have been identified.

Nevertheless, a deeper analysis of the business cases leads to the identification of some key common requirements. Below they are reported and summarised in terms of business processes, measures of performance, coordination mechanisms and information systems.

7.1 Business processes The business cases highlighted the need for business process oriented design of industrial services where great attention must be given to the interfaces of business processes of the service provider on one side and the manufacturing company on the other. The goal is to guarantee a presently missing total harmonisation of information and material flows.

This should be kept in mind from the early stages of service design (Adapt phase).

The alignment of the business processes must necessarily be supported by IT architectures which are as well optimised from a business process perspective.

Figure 40 Example of business process alignment extracted from the SKF business case There is moreover a strong need to monitor both intra and inter-enterprise processes in terms of both technical and financial performance efficiency. In this sense, starting from the early adapt phase specific processes should be foreseen for the definition of macro maintenance policies and, especially, measures of performance (both technical and especially financial) in order to decrease the gap between the contract specification and its applications in day-to-day maintenance activities.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 110

INCOCO Inhouse Workshop Fabiola Di Giampietro

ADAPT

TO BE: ADAPT

Activities developed with the customer

Maintenance performance definition

Maintenance strategies definition (macro)

•Quality service plan•Maintenance plan as a draft

Economical aspects

PROCESS CUSTOMER REQUEST

1-Definition. Team

3-Data collection

OFFER SET -UP OFFER DEVELOPMENT

4-Data analysis 5-Offer

development7-Different

service evaluation

8-Presentat.

Service branch creation

Meeting with customer

Comau team Customerrequirements

Customerspecificservice

parameters

Differentservice options

Draft of the offer

Quotation

Offer to the customer

Legal documents forthe outsourcing

process

CUSTOMER REQUEST Positive

feedback from customer CONTRACT ACQUISITION

CONTRACT DEVELOPMENT

1-Legal aspects definition

2-Technical aspects definition

Contractsigned

• Positivefeedback from

customer

• Offer to the customer

Figure 41 Example of early stage definition of maintenance policies and performance

measures extracted from COMAU business case Eventually in order to harmonise inter-enterprise business processes there is also a basic need for the creation of a common ontology and a common language or in other words, a common framework for the description of business services and their related processes.

7.2 Measures of performance InCoCo-S’ Business Cases have highlighted the need to develop Key Performance Indicators (KPIs) to measure not only intra-enterprise performances (both from the service provider and manufacturer side) but also (presently missing) inter-enterprise ones to evaluate the efficiency of coordination (and in case collaboration) mechanisms.

Moreover KPIs must be developed to measure not only operational efficiency but also financial performance, customer satisfaction, innovation ability and employee performance. In this way short term actions can be fully tracked and linked to long terms maintenance strategies.

The development of the KPIs should be intended to guarantee total transparency between service supplier and manufacturer. And this should be done directly from the early stages, that is, starting from the Adapt phase.

Moreover a system of performance measurement and KPIs should be exploited as an instrument for applying continuous improvement policies to services processes both on the service provider and manufacturer side, as well as to inter-enterprise processes.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 111

Figure 42 Examples of different KPIs extracted from the InCoCo-S business cases

7.3 Coordination mechanisms and information systems The InCoCo-S’s business cases pointed out the present lack of coordination mechanisms and enabling IT solutions to support collaborative practices. In this optic they moreover express the need to develop such solutions taking expressly into consideration trust and confidentiality issues. One of the primary aims would be the development of coordination processes and collaborative practices to integrate production and maintenance plans in a systematic way, overcoming, therefore, present practices still based on “informal” processes based on phone call and e-mail exchanges. Great attention has been given by the InCoCo-S business partners to the development of flexible web-based service-oriented architectures in order to easily model different business requirements and quickly interlink the service provider IT system with the one of the manufacturer (plug and operate principles).

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 112

Figure 43 Example of “plug and operate” solution extracted from the SKF business case In order to achieve these goals it is necessary beforehand to develop Standard Data Interfaces, which are widely accepted at industrial level, to enable flexible coupling between several systems. IT systems should moreover be developed in such a way to guarantee real-time total operational and cost performance transparency between the service provider and the manufacturer.

7.4 Summary of common key requirements from the InCoCo-S Business Cases

Business processes

• Business process oriented design of industrial services.

• Harmonisation of inter-enterprise service provision processes.

• Supporting IT architectures optimised from a business-process perspective.

• Introduction of specific processes in the Adapt phase to identify macro-maintenance and macro-performance measuring policies.

• Common framework (ontology, language) for process description among service providers and manufacturers.

Measures of performance

• KPIs to measure inter-enterprise processes and evaluate coordination / collaborations mechanisms.

• KPIs to measure not only operational efficiency but also financial performances, customer satisfaction, innovation ability and employee performance.

• KPIs to guarantee total transparency between service supplier and manufacturers.

• KPIs to be used as instruments to implement continuous improvement policies (both at intra- and inter-enterprise processes).

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 113

Coordination mechanisms and information systems

• Key importance of trust and confidentiality issues while developing IT solutions for inter-enterprise business process integration and coordination.

• Development of coordination processes and collaborative practices to integrate production and maintenance plans in a systematic way.

• Development of flexible web-based service-oriented architectures to model different business requirements and interlink IT systems among enterprises (plug and operate principles).

• Development of Standard Data Interfaces, which are widely accepted at industrial level.

• Development of IT solutions to guarantee real-time total operational and cost performance transparency.

7.5 Peculiar requirements from BC 4 The last business case presented in this deliverable is the only one addressing the DELIVER phase. This fact leads to the introduction of requirements which are peculiar to this phase. Indeed, although BC 4 is also targeting maintenance services, there can be some special issues identified, because of the character of the delivery / packaging process. In most cases the packaging of products is not a core element of the product (exception: some food and healthcare products), and therefore not a core competence of the manufacturer. This leads to the following peculiarities:

• Increased demand for proactivity of the service provider in terms of innovation of the packaging process, innovation in packaging machines (assets) and innovation of the package itself;

• Resulting from this a strong demand for transparency on the own performance in terms of costs and processes (any efficiency increase directly improves the delivery process at the customer), and;

• In addition the requirements on maintenance are strengthened in the packaging case (compared to maintenance in the MAKE phase), because in the DELIVER phase the quality of the packaging process must be such, that no rework is necessary anymore (the packaging process should not affect the quality of the product itself negatively).

8 Common constraints

Beside common key requirements the InCoCo-S business cases highlighted also the existence of common constraints. These can be synthesised in the following points:

• The necessity to coordinate (and possibly to collaborate) and therefore to exchange information between the service provider and the manufacturer quite often collides with trust and confidentiality issues.

• It is often hard to quantitatively and objectively evaluate the service level provided by the service provider to the customer and the perception that the customer has on the quality of the service received. In this optic it is necessary to find KPIs which can successfully translate the quality of a service into numbers.

• Following the previous point, it is possible to add also that it is usually problematic to quantify which is the real cost of a service provision and, more importantly, which is

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 114

the real value added that the service provider is giving to the manufacturer (How much is the manufacturer saving thanks to the externalisation of a specific function?).

• It is difficult (but at the same time necessary) to create Standard Data Interfaces which can be widely accepted by industries at all levels. This limits the possibility of integrating and coordinating activities, automating communication, integrating production and service provision, etc.

• It is hard (but at the same time vital) to develop a common framework for process description which is widely accepted, understood and adopted by service providers and manufacturers.

9 Additional requirements from SMEs

InCoCo-S SME partners analysed the requirement specifications identified through the business cases and expressed an overall agreement with them. Requirements may evolve, however, as the framework for cooperation and coordination is developed throughout the remainder of the project.

InCoCo-S SMEs pointed out nevertheless some specificities in their requirements.

It is envisaged, for example, that SMEs may face additional requirements as a result of their size and finances. It has been noted that any solution developed within the InCoCo-S project may need to be scaleable (downsized) to allow smaller organisations to use the approach (methodology / software) without undue cost overhead.

Costs are seen to be influenced by the level of complexity necessitating specialist training and, perhaps, additional dedicated staffing of the coordination function.

Any solution would need to allow SME organisations to be able to provide the necessary enhanced support to manufacturers without unnecessary additional burden.

Moreover SMEs require the adoption of business processes, service modelling tools, IT solutions and easy-to-use KPIs which can guarantee total cost transparency and can help them to evaluate if and how much the externalisation of a function to an external service provider can decrease total costs. Indeed SMEs use KPIs in order to control its core business activities but it is very difficult for them to create service provision models and measure improvements generated by well designed and performed maintenance operations.

Eventually it is necessary to point out that, since especially SMEs have no capacities and budget for the implementation of supporting IT infrastructure, which also supports the assurance of the compliance to defined workflows, they need to have a standardized and clear framework of relevant information and basic processes. This assures that they can react to requests of the coordinating service provider, e.g. in case spare parts or other BC related services are requested, and the SME understands which kind of information is needed by the requester and in which format.

This requirement targets mainly the areas of the ADAPT and the BUILD phase, because SMEs typically are integrated ad hoc, and no long-term contracts are realized. Contracts remain often on the level of individual delivery contracts. So when the basis for the service deliveries is set, in the OPERATE phase, from the perspective of the SME, there will be only the process of order and delivery, which needs to be as fast and flexible as possible.

In other words: a common language and terminology needs to be created, which provides the basis for the collaboration in the OPERATE phase. This language needs to be clear and simple.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 115

10 Requirements from the InCoCo-S Surveys As already stated Deliverable 2.3 must be considered in connection with the results already obtained through the two InCoCo-S surveys and presented in Deliverable 2.1 - Consolidated Supply Chain & Service Providers Survey Results. Indeed while the latter present an overall view on criticalities and expectations in business service – manufacturing supply chain integration and coordination, the first one presents an in-depth analysis of the issue. Additionally to the requirements identified through the business cases the following requirements coming from the surveys must therefore be considered. According to the survey results the InCoCo-S project should aim:

• To develop a service oriented reference model which will integrate and standardize new coordination procedures, performance metrics and decision support systems for enhancing the interactions between service providers and manufacturing supply chains.

• To develop “coordination concepts” or “best practices” in order to integrate the planning of manufacturers with the one of service provider. One can assume that the reason, why manufacturing companies and service providers don’t use “coordination concepts” or “best practices” in their relationship is because for the moment there are no such supporting tools suitable for the practice.

• To concentrate on all the issues and weaknesses pointed out by the manufacturing companies and service providers in this survey addressing synchronization, coordination and integration of the different supporting services into supply chains.

• To addresses standards in the following domains: Key Performance Indicators, Business Processes, Information Exchange in order to facilitate a close collaboration between manufacturers and service providers.

InCoCo-S Deliverable Nr. 2.3

“As Is” Business Use Cases & Requirement Specification in the Service-Supply Chain domain 116

Annex 1 – Acronyms

B2B: Business-to-Business

BC: Business Case

BP: Business Process

BPEL: Business Process Execution Language

BU: Breakdown

CM: Condition Monitoring, Coordination Mechanism

CMM: Computerized Maintenance Management

CoC: Centre of Competences

DSS: Decision Support System

ERP: Enterprise Resource Planning

ETM: Ersatz-Teil-Management

IT: Information Technology

IS: Information System

KPI: Key Performance Indicator

MD: Maintenance Department

MRO: Maintenance Repair Overhaul

OEM: Original Equipment Manufacturer

PM: Performance Measure

PPS: Production Planning and Control System

SCOR: Supply Chain Operations Reference

SAP: Systeme, Anwendungen und Produkte in der Datenverarbeitung

SBU: Service Business Unit

SBCC: Service Business Competence Centre

SME: Small and Medium sized Enterprises

SLA: Service Level Agreements

SM: Scheduled Maintenance

UM: Unscheduled Maintenance

XML: Extended Markup Language

WP: Work Package