D6.1_v1.1_out

The PREMANUS project (285541) is co-funded by the European Union under the Information and Communication Technologies (ICT) theme of the

7th Framework Programme for R&D (FP7).

This document does not represent the opinion of the European Community, and the European Community is not responsible for any use that might be

made of its content.

Programme Factories of the Future PPP

Strategic Objective ICT-2011.7.3 Virtual Factories and Enterprises

Project Title Product Remanufacturing Service System

Acronym PREMANUS

Project # 285541

D6.1 - PILOT REQUIREMENTS

MANAGEMENT

Work Package WP6: PREMANUS Pilot

Lead Partner 7: EPL

Contributing Partner(s) SAP, SKF, CRF

Security Classification CO (Confidential)

Date 24 January 2013

Version 0.9

„COPYRIGHT

© Copyright 2013 by SAP AG, SKF GmbH, Centro Ricerche Fiat Scpa, Epler & Lorenz AS

Legal Disclaimer

The information in this document is provided ‘as is’, and no guarantee or warranty is given that the information is fit for any particular purpose. The above referenced consortium members

shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials subject to any

liability which is mandatory due to applicable law.

This document may not be copied, reproduced, or modified in whole or in part for any purpose without written permission from all of the Copyright owners. In addition to such written

permission to copy, reproduce, or modify this document in whole or part, an acknowledgement of the authors of the document and all applicable portions of the copyright notice must be

clearly referenced.

The circulation of this document is restricted to the staff of the PREMANUS partner organisations and the European Commission. All information contained in this document is strictly

confidential and may not be divulged to third parties without the express permission of all of the Copyright owners.

All rights reserved. This document may change without notice.”

Project –No Date

Classification

285541 30-Nov-12

CO

D6.1 - PILOT REQUIREMENTS MANAGEMENT

ii

Document history

Version Date Comments Author

0.1 01/10/12 Agreed Document Template Federico Magalini

0.2 26/10/12 SKF trial planning material added Stefan Schleyer

0.4 20/11/12 Further additions for SKF Stefan Schleyer

0.5 23/11/12 Added EPL part Jüri Epler

0.6 23/11/12 Template, Intro Nicolas Liebau

0.7 27/11/12 SKF Web Service description, project plan Stefan Schleyer

0.8 07/12/12 CRF Requirements, development and evaluation plan Julien Mascolo

0.9 10/12/12 Proof reading Emma Rosamond

The research leading to these results has received funding from the European Community’s Seventh Framework Programme

(FP7/2007-2013) under grant agreement no285541.

Project –No Date

Classification

285541 30-Nov-12

CO


iii

Table of contents

1 EXECUTIVE SUMMARY .......................................................................................................................... 4

2 INTRODUCTION ........................................................................................................................................ 5

2.1 PILOT OBJECTIVES ................................................................................................................................... 5 2.2 METHODOLOGY FOR PILOTS REQUIREMENTS COLLECTION AND PILOT PLANNING ................................. 5 2.3 PROJECT TIMELINE .................................................................................................................................. 7

3 TECHNICAL REQUIREMENTS (TABLE FROM D22) ........................................................................ 8

4 CRF .............................................................................................................................................................. 15

4.1 PILOT OBJECTIVES ................................................................................................................................. 15 4.2 EVALUATION PLAN ............................................................................................................................... 18 4.3 USE CASE REQUIREMENTS .................................................................................................................... 19

4.3.1 Business Requirements ................................................................................................................. 19 4.3.2 Business Requirements Details ..................................................................................................... 20 4.3.3 Technical Requirements ................................................................................................................ 26

4.4 TEST CASES AND PILOT EVALUATION ................................................................................................... 27 4.4.1 Idea testing.................................................................................................................................... 27 4.4.2 Simulation ..................................................................................................................................... 28 4.4.3 Bench tests .................................................................................................................................... 28 4.4.4 Live tests ....................................................................................................................................... 28

4.5 PROJECT PLAN FOR THE CRF PILOT ...................................................................................................... 29

5 SKF .............................................................................................................................................................. 30

5.1 PILOT OBJECTIVES ................................................................................................................................. 30 5.2 EVALUATION PLAN ............................................................................................................................... 31 5.3 USE CASE REQUIREMENTS .................................................................................................................... 31

5.3.1 Business Requirements ................................................................................................................. 31 5.3.2 Business Requirements Summary ................................................................................................. 31 5.3.3 Business Requirements Details ..................................................................................................... 32 5.3.4 Technical Requirements ................................................................................................................ 38 5.3.5 Stakeholder Requirements ............................................................................................................ 41

5.4 TEST CASES AND PILOT EVALUATION ................................................................................................... 41 5.5 PROJECT PLAN FOR THE SKF PILOT ...................................................................................................... 43

6 EPL .............................................................................................................................................................. 44

6.1 PILOT OBJECTIVES ................................................................................................................................. 44 6.2 EVALUATION PLAN OF EPLER AND LORENZ .......................................................................................... 45

6.2.1 Scenario Description .................................................................................................................... 45 6.3 PILOT EXECUTION ................................................................................................................................. 49 6.4 USE CASE REQUIREMENTS .................................................................................................................... 50

6.4.1 Business Requirements ................................................................................................................. 50 1.1.1 Technical Requirements ................................................................................................................ 51 6.4.2 Stakeholder Requirements ............................................................................................................ 52

6.5 TEST CASES AND PILOT EVALUATION ................................................................................................... 52 6.6 PROJECT PLAN FOR THE EPL PILOT ....................................................................................................... 52

7 CONCLUSIONS .......................................................................... ERROR! BOOKMARK NOT DEFINED.

Project –No

Date Classification

285541

24 January 2013 CO


4

1 Executive Summary

This deliverable describes the plan for the successful preparation and execution of the

PREMANUS pilots at SKF and CRF, both in interaction with EPL.

This deliverable describes the planning status of M15, where the pilot will be started earliest at

M30. Accordingly, with 15 months of work ahead until the pilots start, this is a living document

containing the actual status of the pilot preparation and the plan for pilot execution and

evaluation. Thus, this deliverable does not present the final detailed plan but rather shows the high

level plan and provides a checklist of items that need to be considered, tasks that need to be

executed before the pilot can be started, and a project plan per pilot for successful preparation.

The deliverable structures the planning for all three use cases into the following areas:

Pilot objectives that shall be achieved by the use case partners.

Evaluation plan, in order to evaluate the achievement of the pilot objectives. This includes

a pilot use case description.

Use case requirements, structured into

o Business requirements, stating the requirements from the use case partner in

general and the business unit responsible for the pilot in particular.

o Technical requirements with focus on the integration with other IT systems and

data to be provided by the use case partners.

o Stakeholder requirement, in order to ensure all stakeholders that need to be

involved in the pilot are considered and involved also during planning.

A description of the test cases that shall be executed during the pilot.

Project plan in form of a Gantt chart.

SKF will evaluate the PREMANUS system within the wind turbine gearbox remanufacturing

business unit. Based on historical data collected by SKF the pilot will compare the results with

PREMANUS against the results achieved without PREMANUS. EPL will be integrated into this

pilot by generating quotes for industrial waste management. These quotes will be considered

within the BDSS.

CRF will evaluate the usefulness of the PREMANUS system in context of a larger business case.

CRF will simulate adapted remanufacturing processes using the PREMANUS system in their

plant simulation tool using historical data. This is the company’s standard procedure for

evaluation changes in operational processes within plants. The focus of the adapted

remanufacturing processes is moving from a one-fits-all engine remanufacturing process to a

process with varieties based on the condition and the economic value of a specific

remanufacturing request. Also here, EPL will be integrated into this pilot by providing an

automatically generated quote for industrial waste handling.

EPL will build-up a new IT system for automatic quote generation for handling industrial waste.

EPL will evaluate the possibility for generation automatic quotes for waste handling and its

potentials for business process optimization for the administrative processes of waste handling.

Project –No

Date Classification

285541

24 January 2013 CO


5

2 Introduction

PREMANUS’ technical developments in WP3, WP4, and WP5 are tried and tested in WP6 via

pilot implementations of two industrial use cases by SKF and CRF. This deliverable is concerned

with the first stage of this work package; it is to collect pilot implementation requirements, which

are different from the functional and non-functional requirements collected in WP2. The industrial

SME EPL is leading this task. It will foster the understanding how small SMEs like EPL can

interact with large enterprises like SKF and Fiat regarding EoL product recovery processes. This

deliverable documents the plan for the following activities in WP6; these are the actual

implementations of the windmill and truck engine recovery tasks, the execution of the pilots, and

their evaluation. This will also form the basis of validating the reference architecture of

PREMANUS and the final iteration of the Living Architecture Document will incorporate the

feedback.

2.1 Pilot Objectives

The focus of the PREMANUS Pilots is to apply the tenets of the technological steps taken in

WP3, WP4, and WP5 for implementing the SKF wind turbine gearbox and the CRF engine

remanufacturing scenarios. One fundamental objective of the pilots is to provide feedback to the

reference architecture model developed in an iterative fashion in WP2 and hence improve it

through the lessons learned in the pilot implementations.

Both the pilots have similar phases - planning, implementation, and execution. In the planning

phase, the local environmental parameters will be taken into consideration and the prototype

PREMANUS middleware will be adjusted based on the differing environments. The

implementation phase will involve integration with the business and diagnostics systems at SKF

and CRF (including writing necessary services and business logic). The execution phase will

analyze the changes/effects of a switch from a demo environment to a productive environment.

Finally, the pilots will be evaluated in two dimensions. Firstly, the use case partners will evaluate

how well the PREMANUS system serves the business objectives of improving their

remanufacturing operations. Looking at two different industries will enable PREMANUS to draw

general conclusions on the benefits of PREMANUS results for this field. Secondly, the functional

and non-functional requirements identified in the reference architecture will be validated and

feedback will be given on possibilities for improvement.

Accordingly, the pilots’ objectives are:

O6.1: Understanding real-life requirements for productive deployment of the PREMANUS

middleware.

O6.2: Adaptation of the PREMANUS middleware for solving two industrial scenarios.

O6.3: Validation of the reference architecture model through piloting exercises.

2.2 Methodology for Pilots Requirements Collection and Pilot Planning

The pilot requirements are driven by the pilots’ objectives and the concrete pilot scenarios.

However, for successful pilot execution and evaluation, comprehensive planning is required. The

pilots will be executed in corporate environments, which requires compliance with the respective

regulations and processes of the use case partners. This deliverable uses a common structure for

the requirements collection and planning in order not to miss any important item or task, which

might hamper successful pilot execution.

Accordingly, for each pilot the following structure guides the requirements collection and

Project –No

Date Classification

285541

24 January 2013 CO


6

planning:

Pilot objectives that shall be achieved by the use case partners.

Evaluation plan, in order to evaluate the achievement of the pilot objectives. This includes

a pilot use case description.

Use case requirements, structured into

o Business requirements, stating the requirements from the use case partner in

general and the business unit responsible for the pilot in particular.

Type of Pilot (Operation environment: Lab exercise or real world pilot)

When (time window for pilot)?

Where?

Business unit / employees working with the system

Who is responsible manager?

Status & steps to get participation secured

Which functionality shall be included in trial

Which functionality shall PREMANUS provide, for which

actors/roles, how?

Technical skills for testers

Which additional functionality will used in the pilot?

o What is the status of this functionality?

o Technical requirements with focus on the integration with other IT systems and

data to be provided by the use case partners.

Information to used in pilot

Who provides the information?

Which systems?

Who grants access?

Status & steps to get access

HW availability for end-users

o Stakeholder requirement, in order to ensure all stakeholders that need to be

involved in the pilot are considered and involved also during planning.

Further requirements / resources required

Like available engines / windmill gearboxes / waste products

Who is responsible manager?

Status & steps to for securing these resources

A description of the test cases that shall be executed during the pilot. This includes

o Ideas for evaluating the pilot according to objectives: Define test cases,

procedures and metrics, roles of actors in the test, iterations needed to perform the

test.

Project –No

Date Classification

285541

24 January 2013 CO


7

o Evaluation process:

Who will design evaluation?

Who will execute evaluation at application partner?

Who will analyze and prepare results?

Project plan in form of a Gantt chart.

The PREMANUS consortium will use this deliverable as reference documentation and for

monitoring the process towards the pilot execution.

As this is an internal document, the consortium will focus on the content. Planning requires lists

of items that can be checked, not long text.

2.3 Project Timeline

Regarding the timeline, the pilot preparation has to integrate with the general RPEMANUS

project timeline depicted in Figure 1.

Figure 1: PREMANUS Project Timeline

Accordingly, approximately end of project month M28 the pilot applications should be available

and also the test systems, so that there are two months remaining for a “pilot readiness test”,

testing all processes that will be used during the pilot.

Project –No

Date Classification

285541

24 January 2013 CO


8

3 Technical Requirements (table from D22)

Apart from this partners view, the pilot shall also give insights how well the PREMANUS

middleware fulfils the functional and non-functional requirements collected in D2.2. In summary,

these are:

ID Name Category

GTR General Technical Requirements

The PREMANUS system should be modular

The interfaces should be based on open standards

The BDSS should be able to interact, through standardized interfaces, with

also other systems

The PREMANUS system should be cloud ready.

RIS Remanufacturing Information Service Functional

RIS.PIIN.0 Product Identification & Information Network

Structure

Functional

The Remanufacturing Information Service should be built in a hybrid

structure

o Content should be stored by each stakeholder locally

o A central node should realizes directory service with search, lookup,

ID resolution, mapping, and a retrieval service

o A directory service should store advertisements that describe

information available at the stakeholders

RIS.PIIN.1 ID Information Discovery Functional

PREMANUS should discover which information for a given ID is available

from which stakeholder

Information discovery should allow a stakeholder to gather all necessary

information for an ID to use for assessment or disassembly

The overall structure of search and lookup shall comply with the EPC

Global standard “Object Name Service” (ONS).

The information discovery is split into two phases

o The owner of product data what information about a product is

available to the remanufacturing ecosystem.

Advertisements/annotations are used to publish this information.

o Search within the advertisements for product information. The

search result details, which product data can be where and how

retrieved.

RIS.PIIN.2 Information Retrieval Functional

Once relevant information have been identified, annotations to this

information will provide the

o Location, where the product information can be accesses

o How the product information can be retrieved

Project –No

Date Classification

285541

24 January 2013 CO


9

o Which further services are available to other PREMANUS

stakeholders

An interface is required to retrieve/use the information/services.

RIS.PIIN.3 Information Transformation Functional

RIS should manage a canonical data structure to support import from

heterogeneous information sources into PREMANUS by a transformation

service.

The transformation service should enable simple information processing into

the BDSS.

RIS.PCIM.1 Unique IDs Functional

Each product instance represented in the PREMANUS system should be

uniquely identifiable across all stakeholders

Unique IDs should be used to share information between stakeholders

RIS.PCIM.2 ID Resolution & Mapping Functional

Each stakeholder should be able to retrieve a PREMANUS ID for a physical

product instance

ID retrieval should be possible with minimal information about the product

ID mappings shall be managed for all stakeholders in the remanufacturing

ecosystem at a central node

Product IDs shall consists of three components

o OEM

o Product type

o Unique product ID

The overall structure of search and lookup shall comply with the EPC

Global standard “Object Name Service” (ONS).

RIS.DPIS.1 Distributed Product Information Store Functional

The Distributed Product Information Store (DPIS) stores the information

that is published in first phase of the ID Information Discovery process,

according to the requirements RIS.PIIN.1.

The DPIS is operated on a central node where the distributed IT systems of

the stakeholder within the remanufacturing ecosystem publish the product

information to, according to the requirements of RIS.

RIS.DPIS.2 Support to structured data Functional

It is necessary to utilize (or develop) a storage capable of providing support

to structured data, like KPI data (properties and values).

RIS.DPIS.3 Support to semi-structured data Functional


to semi-structured data, like the XML files data containing the indexes of the

stored information.

RIS.DPIS.4 Support to unstructured data Functional


to unstructured data, like PDF, pictures or CAD files.

Project –No

Date Classification

285541

24 January 2013 CO


10

RIS.DPIS.5 Data stored should be easily accessible Functional

The data stored, independently of the storage used and its physical location,

should be easily accessible for local and remote nodes of PREMANUS

through the usage of Web Services.

RIS.DPIS.6 Big amount of data Functional

It is necessary to provide support to the big amount of data coming from the

two user industries. This requires a proper storage capable of both managing

the quantity of data, maintaining the capability of indexing and fast finding

and processing.

RIS.DPIS.7 Semantic storage Functional

It is necessary to semantically annotate the data stored to enable natural

search languages and to facilitate the indexing of the mainly unstructured

data.

RIS.RBAC.1 Authentication Functional

Authentication procedure should exist.

Authentication procedures should avoid access of confidential information

by non-authorized people.

The authentication mechanism should check for every single access to a

given data/document.

However, there should also exist an administrator role to grant access to the

different users.

RSG Remanufacturing Services Gateway

PREMANUS needs to have the different components connected in a

homogeny and transparent way to the user and to the other components.

RSG.SSB.1 Orchestration Functional

The usage of Business Workflow Models (BPML) is demanded by

PREMANUS final users, as they already use BPML based engines in their

current configurations. This feature will allow advanced service composition

that can be configured at each of the end users.

RSG.SSB.2 Integration of software components & data

sources

Functional

The integration of software components and other data sources is necessary for the

following reasons:

Allowing component deployment (desirable hot deployment) with

component versioning

Polyglot applications ( .net, java, php, ...)

Minimizing efforts for integration of 3rd

party components (with predefined

adaptors, e.g. XMPP)

In PREMANUS the following kinds of components are envisaged:

Distributed security & access control.

RSG.SSB.3 Message channels and routing Functional

Project –No

Date Classification

285541

24 January 2013 CO


11

It is necessary to add functionality regarding the processing of composed

messages. With respect to the messaging and routing it is necessary to take

into account the following points:

o Point-to-point messaging

o Publish-subscribe messaging

o Splitter

o Aggregator

o Content Based Router

o Message Filter

o Dynamic Router

o Recipient List.

RSG.SSB.4 Transport protocol Functional

The ESB must allow different transport protocols in the anchor points for the

applications, as well as transport protocol conversion.

RSG.SSB.5 Connectivity Functional

The ESB must allow different components to be connected e.g.:

o Different types of data stores (triple stores, relational, noSQL, XML,

etc.)

o 3rd

party applications (ERP, PLM,...)

o User interfaces

o Internal functional elements:

Business Decision Support System

Unique ID routing mechanism

Semantic gateway & query mechanism (query

decomposition and routing to specific data stores).

RSG.SSB.6 Execution Functional

A common component execution environment is necessary, that will

conform the PREMANUS node, containing the specific functional

components, and the way of communicating with the rest of components

along the PREMANUS environment.

RSG.SSB.7 Support of different topologies Functional

Due to the current status of the project, some generic and open support for

different topologies is needed. Some of the partners see the architecture as a

centralize (unique distributed over the cloud) infrastructure, while some

others see it as instances installed at the final user, and communicated with

the rest of instances using a central coordination point.

Flexibility is needed in order to afford both configurations, and to change

from one to another with no or minimal penalty.

RSG.SSB.8 Security Functional

Although the project is not focused on security, some basic authentication

and role based access control is requested. The distributed nature of the

architecture makes this feature implementation challenging and risky from a

technology point of view.

RSG.GS.1 Transformation services Functional

http://camel.apache.org/content-based-router.html

http://camel.apache.org/message-filter.html

http://camel.apache.org/dynamic-router.html

http://camel.apache.org/recipient-list.html

Project –No

Date Classification

285541

24 January 2013 CO


12

There must be a mechanism to allow the transformation of different data

formats e.g. XML files or Excel files, are used. This mechanism must be

implemented in the SSB.

RSG.GS.2 Mediation services Functional

There must be a mechanism to allow the RSG to select the appropriate

process or service to be executed. This mechanism must be implemented in

the SSB.

RSG.GS.3 Composition of services Functional

Composition of services is needed to improve the performance of the system

and to generate larger services by linking smaller services.

RSG.SS.1 Access to Semantic storages Functional

It is necessary to access the semantic storages which would have the

annotation of the information stored in other storages.

RSG.SS.2 Annotation Functional

In the case of unstructured content, it is necessary to semantically annotate

the data to be stored so it can be easily found and retrieved.

RSG.SS.3 Publishing Functional

As the PREMANUS middleware is dealing with content and also services

offered by the components, it is necessary to publish them so they can be

easily found and retrieved (content) or executed (services).

RSG.SS.4 Reaching information Functional

The information and the services belonging to different components must be

reachable by every component through the SSB.

RSG.GWS.1 DbaaS services Functional

The PREMANUS middleware needs to access to external DBs to retrieve

the data required by the BDSS to perform its calculations.

RSG.GWS.2 AaaS services Functional

The PREMANUS middleware needs to communicate and exchange

information with 3rd

party applications such as ERPs, PLMs, PCos (Plant

Connectivity) like e.g. the ones utilized by the users… and their associated

storages to get the requested information needed by the BDSS to perform its

calculations.

RSG.GWS.3 Connection to external unstructured storages Functional

As in RSG.GWS.1, the PREMANUS middleware needs to access external

unstructured storages to retrieve the data required by the BDSS.

BDSS Business Decision Support System Functional

PREMANUS BDSS should support domain experts who have open-ended,

unstructured and complex problems.

The PREMANUS system should be designed to reduce complexity of

Project –No

Date Classification

285541

24 January 2013 CO


13

human tasks by structuring, filtering and presenting relevant information in

appropriate ways to support processing of large volumes of data involved in

extensive and recursive decision-making.

BDSS.1 BDSS Data Storage Functional

PREMANUS should provide a local data store at the PREMANUS

Remanufacturing node to run the required analyses.

The BDSS Data Store should store all information needed to prepare a

remanufacturing decision; this information is above all product master data

and product lifecycle information such as usage data, service reports, and

sensor data.

The storage should use a sophisticated data structure, so the analyses

conducted by the BDSS can be performed efficiently and correctly. A

canonical PREMANUS data structure will be used as standard, adaptations

to it to specific use cases must be enabled.

BDSS.2 Data Structure Functional

The analysis of the PREMANUS system should run efficiently and correct

by using sophisticated data structures. A canonical PREMANUS data

structure should be used as standard; adaptations to it to specific use cases

must be enabled.

BDSS.3 Query Composition Functional

PREMANUS should provide a Query Composition user interface for

business users to specify which data is needed for the remanufacturing

decision to be taken.

A Query Composition should compose queries from the user input that the

PREMANUS system can correctly execute, search and retrieve the correct

data from the ecosystem.

BDSS.4 Access to Information and tracking activities Functional

PREMANUS system should track all activities at operational level during

the remanufacturing process. This includes input, output and specific

resources.

PLM data, warehouse component’s stock, customers’ demand and

expectations should be accessed by the BDSS.

BDSS.5 End-of-Life Product Recovery Process Eco-

Efficiency Evaluator

Functional

PREMANUS should provide evaluation results for:

o Economical evaluations

o Environmental evaluations, taking into account Life Cycle

Assessment (LCA) calculations

o Ecological eco-efficiency evaluation, based on

Generated hazardous/non-hazardous waste

Generated CO2 footprint

o Risk of deviation from the expected or benchmarked ecological

efficiency

BDSS.5 KPIs Calculator Functional

Project –No

Date Classification

285541

24 January 2013 CO


14

PREMANUS should provide different types of KPIs that can be configured

in a flexible manner.

KPIs for the different internal stakeholder to the remanufacturing operations

shall be supported.

KPIs, as business centered measures should benefit from implementation of

computerized calculations, given the access of PREMANUS to relevant

information storage databases.

BDSS.6 Information set Non-functional

The amount of data to be processed by a human should be minimized

without affecting the quality of decision making.

PREMANUS should reduce the amount of data processed in every single

step by first an overview shall be provided, then zooming and filtering,

showing details on demand.

BDSS.7 Data visualization Non-functional

PREMANUS should avoid cognitive load for processing information by

using graphical visualization of data, three-dimensional representations,

color-coding, animated diagrams, interactive graphics and other tools to

allow exploration of data.

BDSS.8 Learnability Non-functional

User Interfaces should allow for easy use and stick to common controls,

labels, wording and element’s placement as users of BDSS might not be

systems experts.

BDSS.9 Personalization Non-functional

The system should be adaptable to various styles, needs and roles because

users will have different roles and responsibilities.

Personalization of UI, configuration of menus and process for information

seeking should be allowed.

BDSS.10 Consistency Non-functional

PREMANUS UI design should allow users to find command and user

interface elements in the same place

Project –No

Date Classification

285541

24 January 2013 CO


15

4 CRF


The pilot objectives are to develop, test and integrate services for the optimisation of

Remanufacturing, an existing business with consolidated processes. The Business Decision

system will interact with the existing business decision tools and systems available for the

remanufacturing operations. These are detailed in the Error! Reference source not found.

below, which illustrates the many processes involved in the business; each of them is currently

monitored by many KPIs at the plant and company level.

Figure 2: Remanufacturing Business processes

In particular the pilot will:

Prove the technical feasibility

Integrate with existing systems

Support validation, using standard business decision tool (Plant Simulation, from the

Siemens PLM Suite) to assess the impact of PREMANUS

Support a business case for the introduction of PREMANUS solutions and its

prerequisite, in particular the on-demand storage and retrieval of PLM data.

The existing business has been operated for more than 20 years, involving 3 major companies

(FIAT, IVECO and CNH), spanning over all Europe. It is thus characterised by stable processes

and steps performed by well-defined actors, IT systems and facilities. The objective of the project

is to prove the potential for optimisation of these processes. The flow of operations is depicted in

the Error! Reference source not found. below, where PREMANUS can have an impact:

- Engine cores/ return: PREMANUS will support a remote quotation of the engine cores;

- Remanufacturing: PREMANUS will enable the optimisation of current remanufacturing

processes and in particular their adaption to the real or estimated status of an engine and

components;

- Part supplying: PREMANUS will contribute to reduce the new components sourcing

costs and increase the percentage of reuse (salvage).

Project –No

Date Classification

285541

24 January 2013 CO


16

Figure 3: Flow of remanufacturing of engines

As there is currently no information available on the engine status and residual life, all engines

entering the remanufacturing phase in the Garchizy plant follow the same processes. Figure 4

below shows some of the steps involved in this process.

Figure 4: Manufacturing steps for remanufacturing engines

To address these limitations, the FIAT pilot intends to develop, integrate and make available to

Project –No

Date Classification

285541

24 January 2013 CO


17

the staff involved in the business several services presented in the Error! Reference source not

found. below. The services will be described in the following sections.

Table 1: PREMANUS Services and business value

The pilot will enable the development of a business case for the introduction of new PLM data.

The business case will build on the data collected for PREMANUS. It will use the results of the

simulations of the As-Is and To-Be sourcing and plan manufacturing processes (see Error!

Reference source not found. below).

Figure 5: Simulation using data from the PREMANUS DB (Plant Simulation)

L: Logistics; M: Manufacturing; P: Purchasing; WA: Work Analysis; F: Finance; S: Sales

Project –No

Date Classification

285541

24 January 2013 CO


18

4.2 Evaluation Plan

The evaluation plan contains the following activities:

Define organization, responsibilities and interfaces

Define assumptions and constraints

Define workflows and activities

Define tools, environment and infrastructure

Technical development

Setup design and runtime test environment

Run pilot

Analyse and assess pilot results

Design time evaluation: the goal of the design time evaluation is to evaluate the effective

usability of each PREMANUS component in the FIAT context considering the future

industrialisation. In more details we will evaluate the integration of each PREMANUS

component in a qualitative way, keeping into account all the relevant aspects beyond the

effective functionality of the component ranging from usability to reliability, scalability etc.

Stakeholders will be asked to response to questions such as:

Why a specific component has been used (functionality)?

How has it been integrated?

What is the difficulty level in integration (usability)?

What is the level of utility for FIAT?

Is a suitable alternative solution available?

What is necessary to modify in order to use it for engineering the application?

Are there other open issues?

Runtime evaluation: the FIAT prototypes are implemented following a typical user-centred

design (UCD). Tests are conducted with different end users in each stage of the project. Such test

activities allow to continuously refine the user interfaces and interaction modality according with

user needs and suggestions.

Do you have difficulties in using the system (if so explain which ones)?

Is the response of the system what you would expect (if not, why)?

Is the management of planned events always correct?

Is the presentation of information effective (taking into account the possible limitations of

the user interface)?

Is the presented information always understandable and sufficiently self-explanatory?

Do you trust the information which was displayed?

Are the images adequate?

Is the number and sequence of steps in the procedures correct?

Does the execution time of procedures and the transition from one step to another seem

appropriate?

Do you see the updating procedure as suitable? Please explain why.

Do you think that this approach takes sufficiently into account your privacy? Please

detail.

Which kind of added information would you need?

Project –No

Date Classification

285541

24 January 2013 CO


19

Which functionality/ service/ product based on PLM data, and not considered in this

prototype, would you propose?

All responses and feedbacks collected during the design time evaluation will be analysed and

integrated. The results will be reported in D6.3 (M30).

4.3 Use Case Requirements

4.3.1 Business Requirements


o Real world pilot with data coming from real systems replicated in CRF

When (time window for pilot)

o Start: M24 (after D4.1. RSG Preliminary Prototype and D5.2. Product-centric

EoL Business Decision Support System)

o End: M34 (in order to prepare D6.4. Evaluation of reference architecture and

recommendations)

Where

o The test systems will be located at CRF


o Who is the responsible manager

Julien Mascolo

o Status & steps to get participation secured

Julien Mascolo will assign responsible staff people for the engine

remanufacturing business to oversee the pilot in collaboration with

CRF


o Which functionality shall PREMANUS provide, for which actors/roles, how

Pre-Quote on Engine (remote). Role involved: Business expert;

Technical expert.

Remanufacturing Strategy per Engine. Role involved: Process expert;

Technical expert.

Remanufacturing Strategy at component level. Role involved:

Process expert; Technical expert.

Monitoring of activities. Role involved: Process expert.

o Technical skills for testers

Basic IT skills

Experience in the roles mentioned above

Project –No

Date Classification

285541

24 January 2013 CO


20

4.3.2 Business Requirements Details

In the WP1, several aspects were covered, which are related to the pilot:

General use case (D1.1)

Description of processes and mock ups for the graphical user interface (GUI) and

Information systems description and major risks, including the technical and pilot risks

(D1.2)

Example of data collected from IT systems.

The following Error! Reference source not found. shows the overall process model.

Figure 6: Process model

This process model is translated into specific requirements, which are shown in Error! Reference

source not found..

Project –No

Date Classification

285541

24 January 2013 CO


21

Project –No

Date Classification

285541

24 January 2013 CO


22

Figure 7: Requirements for FIAT application

The following sections refine the aspects relevant to the development of the pilot:

The services which will be integrated:

o Pre-Quote on Engine (remote). The service is used remotely by the FIAT/ CNH/

IVACO dealers to get a purchase price from the remanufacturing process owner:

see Cores/ Return in Error! Reference source not found. and the green diamond

in the lower part of Error! Reference source not found. below.

o Remanufacturing Strategy per Engine. The service is used by a plant expert to

choose the strategy for the engine between the 3 different available ones, as

shown in the green diamond in the upper part of Error! Reference source not

found. below:

Remanufacturing 1-to-1, or without ID loss: the specific engine is

remanufactured

Project –No

Date Classification

285541

24 January 2013 CO


23

Remanufacturing 1-to-many, or with ID loss: the engine is dismantled to

components/ cpl (WIP)/ engine

Postpone Remanufacturing

o Remanufacturing Strategy at component level. The service is used by a plant

expert to decide the actions to be performed for the specific engine, as shown in

the green diamond in the left part of Error! Reference source not found. below.

o Monitoring of activities. The service is used by the plant technician to report the

effective operations performed. This feedback is used by the system to fine-tune

the decision algorithms.

The mock-ups.

Figure 8: Services for the FIAT application (1)

Figure 9: Services for the FIAT application (2)

The services will be implemented to support the following interfaces. In the Error! Reference

source not found. below, Alessandro is a FIAT dealer and asks for a quote of an engine in his

workshop, in order to evaluate the opportunity to send it to the remanufacturing plant in Garchizy.

Project –No

Date Classification

285541

24 January 2013 CO


24

Figure 10: Engine remote quotation

In the Error! Reference source not found. below, Roberto is a Garchizy technician: his role is to

receive the engine, verify the conditions, assign a quality index to the engine (A,B,C) based on its

real conditions and decide which action it should undergo.

Project –No

Date Classification

285541

24 January 2013 CO


25

Figure 11: Engine entrance, ABC and suggested remanufacturing path

In the Error! Reference source not found. below, Massimo is a Garchizy technician: his role,

once the path for remanufacturing has been chosen, is to dismantle the engine and report on

discrepancies between the expected and actual conditions of the engine.

Project –No

Date Classification

285541

24 January 2013 CO


26

Figure 12: Remanufacturing tasks

4.3.3 Technical Requirements

The piloting phase will address also technical requirements, described above. For each

PREMANUS service, the requirements are expressed in terms of quality of the integration

keeping into account the following aspects:

Usability: easy to use, effectiveness; the service should be easy to integrate, with adequate

documentation and examples;

Performance: response time, efficiency; the service should prove to provide good

performance, even before integration;

Reliability: Frequency/severity of failure, Recoverability; in particular a more than

sufficient level of reliability so that no error or problem occur during integration;

Supportability: the service should support ad-hoc queries to identify where errors

occurred and a set of debug tools (console, messages etc.);

Scalability/ Configurability/ Portability; the service should be able to adapt to the number

of engines (from several hundreds to tenths of thousands)

Project –No

Date Classification

285541

24 January 2013 CO


27

Adaptability and adequacy to Fiat context; the service should be able to reduce/ eliminate

changes needed to support specific FIAT constraints (or motivate why it had to be

designed differently).

4.4 Test Cases and Pilot Evaluation

The evaluation plan describes the motivation and strategy for involving end-users. The testing and

evaluation in the WP6 will follow a typical user-centred design (UCD).

“UCD is a design philosophy and a process in which the needs, wants, and limitations of end

users of an interface or document are given extensive attention at each stage of the design process.

User-centred design can be characterized as a multi-stage problem solving process that not only

requires designers to analyse and foresee how users are likely to use an interface, but also to test

the validity of their assumptions with regards to user behaviour in real world tests with actual

users. Such testing is necessary as it is often very difficult for the designers of an interface to

understand intuitively what a first-time user of their design experiences, and what each user's

learning curve may look like. The chief difference from other interface design philosophies is that

user-centred design tries to optimize the user interface around how people can, want, or need to

work, rather than forcing the users to change how they work to accommodate the software

developers' approach”. ([Wikipedia1]).

The goal of the evaluation is, on one side, to evaluate the feasibility of the described approach

and, on the other side, to test the usefulness and usability of the developed platform.

In PREMANUS, the following stakeholders will be involved:

Clients

FGA professionals

CRF staff

The User Centric Design in this case will mainly imply:

Idea testing (Design time evaluation)

Simulation (Design time evaluation)

Bench tests (Design time, Runtime)

Live tests (in plant/ laboratory) (Design time, Runtime)

4.4.1 Idea testing

The idea of Business Decision Support System for supporting some stakeholders of the engine

remanufacturing has been exposed during the first year of the project to a team of FGA staff,

including people from the departments Manufacturing, Logistics, Aftersales and Marketing. The

ideas behind the project have been shared with:

Clients: indirectly through FGA-Marketing and CRF staff;

FGA professionals: by defining the area of the project in the FGA Strategic Research

Agenda and; by providing feed-back on rough scenarios;

CRF staff: by designing the perimeter of the applications and building some rough

scenarios.

During these sessions a simple mockup (through slides) is shown to highlight the PREMANUS

Project –No

Date Classification

285541

24 January 2013 CO


28

ideas. At the stage, the principal innovative functionalities are presented, with the expected output

(a set of services; a business case for the introduction of new PLM data).

4.4.2 Simulation

Simulation tests are scheduled from the beginning of the project. CRF follows the approach to

develop step-by-step iterative prototypes. Beginning with purely “paper prototypes” and

following with prototypes mixing simulation and real components integrated, the stakeholders are

involved:


FGA professionals: by assessing the prototypes, from a client perspective:

o What are the potential clients’ expectations?

o How do potential users think the tool should work?

o What are the potential clients’ alternatives for the same experience?

o How do involve the potential clients in using the tool?

CRF staff: by sharing the prototypes with the other stakeholders to gain early feedback

and drive the development

4.4.3 Bench tests

Bench tests are scheduled as soon as possible in the WP6. As soon as the above-mentioned

components become available, CRF develops test benches to involve the user in trying out the

technology:


FGA professionals: by assessing the prototypes, from a client perspective:

o Is the tool working according to expectations?

o What are the potential clients’ alternatives for the same experience?

o How do increase the potential basis of customers for the tool?

CRF staff: by involving in the tests staff usually not aware of the technology/ not involved

in the project activities

Following the user centric design approach, users are involved as soon as the first prototypes are

available.

4.4.4 Live tests

Live tests are planned, from the second half of the WP6. They will be performed concurrently

with bench tests:

Clients: using CRF staff to assess through questionnaires and naturalistic studies, the

functionalities provided by the system:

o Is the tool useful, safe, and efficient?

o Are there alternatives for the same experience?

o What is the incentive for using the tool?

FGA professionals: same as above;

Project –No

Date Classification

285541

24 January 2013 CO


29

CRF staff: by involving in the tests staff usually not aware of the technology/ not involved

in the project activities.

4.5 Project Plan for the CRF Pilot

The realization of the pilot will follow the following project plan.

Operating procedures ,

comunication and training

Monitoring of results

Change Management Forms

M25Project stages M28 M29 M30 M31 M35 M36M32 M33 M34

GANTT

Integration of services

M24 M26 M27

Define tools and infrastructure

Define test environment

Figure 13. CRF Pilot Project Plan

Project –No

Date Classification

285541

24 January 2013 CO


30

5 SKF


Agility results from business and the related processes but not from the IT department. Therefore

the IT departments have to design agility into their solutions to follow changes in the processes.

The overall objective is to verify that the PREMANUS system, consisting of middleware and

BDSS apps, can follow the demands from the business.

The pilot’s objectives, which will be covered by setting up a pilot implementation for the SKF use

case, are:

Definition and testing of coordination strategies

o Definition of coordination strategies between PREMANUS and other

IT systems

o Create a seamless interconnect between IT and process architecture

Definition of provided data

o Definition of data to be provided by PREMANUS for information

exchange

o Define data structure for information exchange

Development of agile information systems

o Develop a model to share the business strategies with IT

o Develop agile solutions instead of isolated applications

Synchronization of technical terms

o Create a seamless interconnect between IT and process architecture

o Develop a single repository to fully align IT systems with business

needs

Figure 14: Development of Networked Services

Project –No

Date Classification

285541

24 January 2013 CO


31

Definition of performance measures

o Definition of the suitable KPIs, as currently no ones are existing

5.2 Evaluation Plan

The evaluation plan contains the following activities:

Create requirement definition

Define organization, responsibilities and interfaces

Define assumptions and constraints

Define workflows and activities

Define tools, environment and infrastructure

Development

Setup test environment

Run pilot

Analyze and assess pilot results



5.3.2 Business Requirements Summary


o Real world pilot with example data using test system


o Earliest start: M30

o Latest end: M35

Where

o The test systems will be located at the SKF cloud infrastructure


o Who is the responsible manager

Stefan Schleyer


Stefan Schleyer will assign the manager from the gearbox

remanufacturing team to oversee the pilot for up to 5-10

hours a week


Project –No

Date Classification

285541

24 January 2013 CO


32

o Which functionality shall PREMANUS provide, for which

actors/roles, how

Definition of a ball park quote to a potential customer for

gearbox remanufacturing (GRBQUOTE).

Role involved: Technical expert

Disassembly of gearbox and firm quote to a customer

(DISASSGRB). Role involved: Remanufacturing expert

Remanufacturing of gearbox (REMANU).

Role involved: Remanufacturing expert

Note: Although this is an important role within the

pilot, PREMANUS will not support this functionality

with specific software tools.


Basic IT skills


5.3.3 Business Requirements Details

As preparation for the pilot use case two aspects of the implementation have already been covered

during WP1:

For the processes to be implemented the process models have already been defined.

Various mock ups for the graphical user interface (GUI) have been created.

Within WP6 the following aspects which are relevant to develop a pilot implementation for the

use case have to be covered:

Definition of services which will be used from the PREMANUS eco system.

Development of the services which will be used to connect to the SKF WindCon system.

The pilot for the use case shall be implemented by the following software technologies:

ARIS MashZone for the Graphical User Interface (GUI)

ARIS for the implementation and integration of the business processes

Web services for accessing external partner systems e.g. PREMANUS

Microsoft SQL Server for storing information from the processes

Project –No

Date Classification

285541

24 January 2013 CO


33

Implementation of Processes:

Three main scenarios have been derived from the use case where PREMANUS will support the

business:

Definition of a ball park quote to a potential customer for gearbox remanufacturing

(GRBQUOTE).

Disassembly of gearbox and firm quote to a customer (DISASSGRB).


Figure 16: Example for Process from the Use Case

Figure 15: ARIS MashZone Architecture (Source: Software AG)

Project –No

Date Classification

285541

24 January 2013 CO


34

Implementation of Main Menu:

Figure 17: Mockup of Main Menu

The menu “Pipeline“ is for an overview on current gearboxes in the pipeline.

The menu “Information Center” gives access to all information available for a product.

This information can be displayed flexibly by adding/removing “widgets”.

The menu “Resources” lists internal (workforce/stock) & external resources.

The menu “Integration” is were costs (and time) are calculated based on the integrated

information

Implementation of Pipeline Screen:

Figure 18: Mockup of Pipeline Screen

The menu “Pipeline“ is for an overview on current gearboxes in the pipeline.

On the left side all gearboxes in the pipeline are listed by their ID.

Project –No

Date Classification

285541

24 January 2013 CO


35

Based on the selection of the ID of the gearbox all relevant detail information are shown

in the middle of the screen.

The detail information contains information such like order details or status information.

If their have been some tests conducted this is also listed here.

For the customer information a separate screen section is reserved. In this section all

details regarding the customer are shown.

Implementation of Information Center Screen:

Figure 19: Mockup of Information Center Screen

The screen “Information Center” gives access to all information available for a product.

On the left side all gearboxes in the pipeline are listed by their ID.

Based on the selection of the ID of the gearbox all assigned components of the bill of

material (BOM) are shown in the middle of the screen.

Depending on their role, uses can edit information in widgets.

Widgets are selected in the information screen on the left side, the displayed information

can adapt to the user role logged on to the system.

Widgets can be “exchanged” between the views “Information Center”, “Resources” and

“Cost Calculation”, so all information and all functionality can flexibly be combined.

Also further information regarding the recommended disassembly process can be

visualized.

Implementation of Resources Screen:

Project –No

Date Classification

285541

24 January 2013 CO


36

Figure 20: Mockup of Resources Screen

The screen “Resources” provides access to all resources relevant for a product.

In the middle of the screen the list of components for the selected gearbox is displayed

The screen section below covers the aspects of the workforce e.g. a list of employees,

skills and availability is shown.

In the lower section the connection to an ERP system can be provided to search for

specific components in stock.

If necessary also external resources can be integrated to support the process.

Implementation of Integration Screen:

Figure 21: Mockup of Integration Screen

The screen “Integration” collects information and displays them as an overview.

In the upper part of the screen various actions can be selected, all other widgets wild then

Project –No

Date Classification

285541

24 January 2013 CO


37

adapt to the selection made here.

The essential part is to decide for every component if it should be remanufactured or

replaced.

Besides the implementation of the different screens also the relevant web services to the SKF

application suite @ptitude shall be developed.

SKF will deploy web services to enable PREMANUS to:

Get a list of alarms

If a predefined threshold for an alarm is exceeded, the alarm is indicated for this

measurement point.

Get detailed information about a particular alarm

Once an alarm has been triggered, detailed information can be retrieved for this particular

alarm.

Get a list measurement points

For a specific machine all predefined measurement point are listed.

Get detailed information about a particular measurement

If more detailed information is required, further details can be retrieved for this particular

measurement.

Submit a Hierarchy Creation (HC)

The hierarchy in the @ptitude Suite visualizes the structure of the machine. So all major

components of a machine are created to define measurement points for the condition

monitoring.

Project –No

Date Classification

285541

24 January 2013 CO


38

These web services are needed to access the SKF software suite (e.g. @ptitude Analyst) and to

establish an integration to the PREMANUS infrastructure.

Figure 22: Connectivity between PREMANUS and @ptitude


In general the following aspects shall be validated:

Horizontal scalability of components to setup a distributed environment

Generality of interfaces to ensure reusability of components

Independent deployment of components to achieve loose coupling of components

Intermediary components to reduce latency, enforce security, and encapsulate legacy

systems

So the requirements from the Service Consumer perspective are:

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

Table 2: Service Consumer Objectives

Project –No

Date Classification

285541

24 January 2013 CO


39

The requirements from the Service Provider perspective can be formulated as follows:

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

context • Generalized services

Provide services to as broad a range of

consumers as possible • Coarse grained, and generalized

services

Table 3: Service Provider Objective

The web services being developed follow theses principles:

The data that a Web service returns should link to other data

The data are designed as a network of information

A resource for every service is created

Each resource is identified by using a URL

The web service development follows a common schema which is described in the following:

Project –No

Date Classification

285541

24 January 2013 CO


40

Figure 23: Web Service Archtecture for @ptitude Software Suite

If an adequate number of Web services are available also the orchestration of Web services to

provide new functionality should be tested.

If new services are derived from existing ones the managing of service dependencies is essential.

Therefore a strategy has to be developed how to maintain these dependencies.

Figure 24: Orchestration of Web Services

Project –No

Date Classification

285541

24 January 2013 CO


41

5.3.5 Stakeholder Requirements

Additional stakeholders/resources required for the pilot functionality

ERP system

o Based on the current implementation process of a new ERP system

the accessibility cannot be guaranteed by start of the test.

o The pilot will be prepared to use test and/or historical data.

CRM system

o Based on the current implementation process of a new ERP system

also the role of the current CRM is questionable; the accessibility

cannot be guaranteed by start of the test.

o The pilot will be prepared to use test and/or historical data.

WindCon system

o WindCon system are available at our testing center.

o The pilot will be prepared to secure access to a test system for the

duration of the pilot phase.


The test cases will follow the processes which have been defined.

Definition of a ball park quote to a potential customer for gearbox remanufacturing

(GRBQUOTE).

Disassembly of gearbox and firm quote to a customer (DISASSGRB).


„Create Quote“

Service

„Create Customer“

Service CRM

Service

„Other“

Service

„Quot

e“

Datat

ype

„Cust

omer“

Datat

ype

„Addr

ess“

Datat

ype

XSD

Schema

XSD Schema

XSD Schema

Directly dependent

Indirectly dependent

Figure 25: Managing of Service Dependencies

Project –No

Date Classification

285541

24 January 2013 CO


42

For testing various methods can be used:

Manual testing.

In Manual Testing, Testers manually execute test cases without using any automation

tools. Manual testing is the most primitive of all testing types and helps find bugs in the

software system. Any new application must be manually tested before its testing can be

automated. Manual testing requires more effort, but is necessary to check automation

feasibility. To ensure completeness of testing, the tester often follows a written test plan

that leads them through a set of important test cases. Manual Testing does not require

knowledge of any testing tool.

Automated testing

Automated testing can be described as automating a manual process already in place that

uses a formalized testing process. For automated testing the usage of special software

(separate from the software being tested) is required to control the execution of tests, the

comparison of the produced results with the predicted results, the setup of test

preconditions, and other test control and test reporting functions.

Explorative testing

Explorative testing is an approach to software testing that is concisely described as the

simultaneous process of test design and test execution. While the software is being tested,

the tester learns things that together with experience and creativity generates new good

tests to run.

For the pilot implementation explorative testing will be used, as the user shall follow the

processes which have been implemented and shouldn´t focus on specific test cases.

The testing will follow the following an iterative methodology. The iterative model does not

attempt to start with a set of requirements cast in stone.

Instead, development begins by specifying and implementing architecture from the product

vision. These requirements are collected in the Product Backlog. The software components are

created from the business needs identified, and then reviewed in order to identify further

requirements.

This process is then repeated, producing a new version of the software for each cycle of the

model. Any issues found in the testing period will be documented in the Testing Backlog. At the

beginning of each iteration cycle it is decided what will be covered both from the Product and the

Testing Backlog for the next cycle.

Project –No

Date Classification

285541

24 January 2013 CO


43

Figure 26: Iterative testing

5.5 Project Plan for the SKF Pilot


Figure 27: SKF Pilot Project Plan

Project –No

Date Classification

285541

24 January 2013 CO


44

6 EPL


The goal of the EPL part of the PREMANUS pilot is to include a quote for handling the waste created during remanufacturing of products into the PREMANUS BDSS. PREMANUS will focus on industrial waste.

The objectives for reaching the goals are

The PREMANUS BDSS shall have access to the quote via web service technology. There shall be no manual labour involved in entering the quote into the BDSS.

The quote shall consist of a cost part and an environmental impact part.

Epler & Lorenz currently communicate with customers mainly in person and via telephone for giving quotes.

In order to give a quote, a customer has to provide a set of information to EPL. This includes e.g.

o Name, registry code of the company/person delivering the waste

o Quantity of waste

o Type of waste (e.g. material)

o European Waste Code if known

o Is waste analysis required

o Point of origin (originator for end-to-end traceability)

o Location, if pickup by EPL is required

The use case partner SKF and CRF have to answer these questions within their use cases in order to request a quote from EPL.

EPL shall provide a Web Service that allows generating an automatic quote based on answering the required questions for determining the quote.

At EPL an IT system shall provide a REST-based Web Service or web page that allows entering the information required for calculating the quote and delivering it to the requestor.

The pilot shall proof technical and economic feasibility of a fully or partly automated quoting system based on the SKF and CRF use cases.

The pilot shall further establish systematic knowledge, which type of requests for waste handling can be calculated automatically and which types of requests require a waste expert to calculate it.

The quotation system shall be integrated with the EPL environmental reporting system, controlled by the environmental officer, in order to eliminate double data entry and improve business process effectiveness.

Project –No

Date Classification

285541

24 January 2013 CO


45

6.2 Evaluation Plan of Epler and Lorenz

As hazardous waste typically has no or only very low value, expensive transportation costs are not

economical. Therefore, waste handling is typically handled by smaller, distributed companies.

Therefore, as waste is such a low margin business, investment in IT systems is typically not

important for such small companies.

6.2.1 Scenario Description

Currently Epler and Lorenz take orders on the phone. On the phone customers talk to specialists

in waste handling that know which questions to ask in order to give a reliable quote to the

customer. In an integrated remanufacturing business process as envisioned by PREMANUS this

manual process is inefficient.

Accordingly:

Epler and Lorenz intend to pilot electronic order taking via a web service or web portal in

order to streamline their customer service

Making waste processing costs available, via the PREMANUS BDSS, directly to the

remanufacturing businesses, will better inform decision making in real-time

Epler and Lorenz also plan to use the eco-efficiency analyser to provide customers with

feedback on the eco-impacts of their waste creation and handling operations

6.2.1.1 Current Website (in Estonia only)

Figure 28: Current EPL's Web Site

Project –No

Date Classification

285541

24 January 2013 CO


46

Key functionalities of the future quoting service:

Provides cost on the following:

waste collection and transportation;

Burning of waste incineration plant;

environmental remediation work carried out;

waste composting and soil treatment;

Preparation of waste;

Product and document destruction;

Recycling

Key functionalities of the future new EPL public services:

Provides details on relevant legislations

Waste

Packaging Act

Ambient Air Protection Act

Chemicals Act

Integrated Pollution Prevention and Control Act

Provides a company news page

Key functionalities of the future new EPL internal services:

Provides an active job list (currently under construction)

Provides contract details of teams across Estonia

Integrate based on accepted quotes with the internal environmental reporting system

6.2.1.2 Acceptance of Orders

Registration of an order

Recording of the data necessary to execute an order:

name of the company

type of waste

amount of waste

waste packaging (type and amount)

demand for waste packaging

address of the point of origin of waste

contact person and phone

any other information necessary (office hours, necessity to phone in advance, etc.).

Formalisation of documents

In order to deliver and receive waste, it shall be necessary to prepare:

waste transport list-contract (EP51-V2)

in the case of hazardous waste, a consignment note for hazardous waste in the KLIS

system

and, as required:

instrument of the delivery and receipt of works

stickers for packaging.

6.2.1.3 Formalization of the Acceptance of Waste

Verification of a consignment note/Formalisation of a consignment note

Project –No

Date Classification

285541

24 January 2013 CO


47

Verification of the data of a consignment note after the acceptance of waste

It shall be verified whether:

the consignment note contains the amount of waste

the consignment note is accompanied by additional remarks which necessitate the

consignment note to be altered (e.g., the actual type of waste fails to be in accordance

with what is denoted in the consignment note)

more consignment notes need to be formalised (e.g., the client delivered waste that had no

consignment note annexed).

Approval of a consignment note

Approval of a verified consignment note for hazardous waste in the KLIS system (see Figure 31).

Recording of a consignment note in stock records

Recording of the data of a consignment note in the stock records of the current calendar year

The following shall be recorded in stock records:

date of the consignment note

number of the consignment note

waste code

amount of waste

name, registry code of the company/person delivering waste

point of origin of waste (city/rural municipality and county).

6.2.1.4 Layouts

Figure 29: Acceptance of orders

Order

Order recording Document

forming

Relay document

to process

manager

Project –No

Date Classification

285541

24 January 2013 CO


48

Figure 30: Formalisation of an order

6.2.1.5 Website Requirements

1. contain all costing data

2. allow inputs of

a. customer locations and full address

b. company details (e.g. Name, VAT number, company number etc.)

c. qualities of waste against a specific type of waste

d. customer email address

e. customer contract number

3. utilise goggle maps capabilities to calculate distances based on postcode or location

4. store customer details (e.g. location) under company name

5. link to current waste value websites for current market values

6. perform the algorithm for quote calculation (sun of transport, waste type, 20% VAT

etc…)

7. provide an electronic quote on the screen, and email to the customer (email address

input); whilst also populating a sales data base at EPL with the order, required date,

customer details, waste details etc.

8. provide a field to allow customer to request a personal phone call to discuss the quote, whist sending EPL an email with customer details etc. with a request for a follow up call

Get document

from the process

manager

Controll of the

documents /

forming the

acompanying

letter

Acompanying

letter approval

Acompanying

letter in the

storage system

Relay document

to book keeper

Project –No

Date Classification

285541

24 January 2013 CO


49

Figure 31: Example KLIS-System Document

6.3 Pilot Execution

For the pilot a system enabling the scenario described above shall be setup.

The system shall not interact with any productive IT systems.

The pilot shall be executed based on example data from SKF and CRF.

Waste

holder

Waste

originator

Waste

description

Remarks

Transport

company

Receiving

company

Project –No

Date Classification

285541

24 January 2013 CO


50

The pilot shall be evaluated by assessing

The accuracy of the generated quote compared to the current practice

The risk for data corruption and loss and determining risk mitigation strategies

The efficiency gains of the new overall end-to-end CRM business process compared to

current practice

The appropriateness to other companies within the ecosystem




o Real world pilot with example data using test system


o Earliest start: M30

o Latest end: M35

Where

o The test systems will be located at Epler & Lorenz in Tartu


o Who is responsible manager

Jüri Epler


Jüri Epler will assign a person to oversee the pilot for up to 5 hours a week


o Which functionality shall PREMANUS provide, for which actors/roles, how

Quote generation, to be validated by a Waste Specialist

Quote generation for logistics/scheduling, to be validated by a Waste Handling & Logistic Manager

Environmental audit reporting by the Environmental Manager


Basic IT skills


o Which additional functionality will used in the pilot

CRM system

Project –No

Date Classification

285541

24 January 2013 CO


51

Based on available open source software, selection process of the concrete product is ongoing.

Logistics optimization system

Based on available open source software, selection process of the concrete product is ongoing.


Technical Aspects of Pilot

o Information to used in pilot

Who provides the information

The customers, SKF and CRF

Waste quoting experts at EPL. Waste quoting includes

o Disposal of waste

o Recovery of valuable materials like metal

Logistic quoting experts at EPL

Which systems

Quoting system, to be developed

CRM system, to be implemented

Logistics optimization system, to be implemented

KLIS system from Estonian Environmental Ministry

o Manual integration of the system into the workflow

PREMANUS cannot interface with the productive KLIS system using APIs. PREMANUS cannot causing any problems with the operations of that system.

Who grants access

Jüri Epler

Status & steps to get access

Jüri Epler has already agreed with is co-CEO Janis Lorenz about the overall pilot plan.

o HW availability for end-users

Project –No

Date Classification

285541

24 January 2013 CO


52

End users have a PC available at their desk they will use

6.4.2 Stakeholder Requirements

Further requirements / resources required

o Detailed information on the waste to be handled (e.g. type, quantity) needs to be provided by the two use case partners SKF and CRF.


Concept for trial evaluation

Pilot Scenario

o Within the SKF and CRF pilots, per remanufactured product also the

generated waste is to be determined.

o PREMANUS defines the term “waste” in context of the two use cases

from SKF and CRF. Waste is refers to the different material that

result from a remanufacturing process and require external treating.

That includes e.g. hazardous waste or metal parts that can be

recycled.

Evaluation process:

o Who will design evaluation?

The system designer at EPL will also design the evaluation

procedure in close collaboration with Jüri Epler and the

PREMANUS team.

o Who will execute evaluation at application partner?

The system designer at EPL in cooperation with the end users

of the EPL system.

o Who will analyze and prepare results?

The system designer in close collaboration with the

PREMANUS team. Goal of this step is also a scientific

publication

6.6 Project Plan for the EPL Pilot


Project –No

Date Classification

285541

24 January 2013 CO


53

Figure 32: EPL Pilot Project Plan

Documents

D6.1_v1.1_out