Background material on use cases
I4MS Mentoring material
Version 0.1
Background material on use cases
Mentoring materialDate: / Tuesday, 13 December 2016
Authors: / Lina Huertas, Junuz Jakupovic
Number of pages: / 8
Number of Annexes: / 0
Version / 1.0
Dissemination / Public
Contract / 678860
1 Introduction to use cases
1.1 Introduction to the Mentoring programme
During phase 2 of the I4MS a major new activity was launched: The Mentoring and sponsorship programme. This activity aims at extending and enhancing the I4MS ecosystem to mainly cover European regions which are not currently involved in I4MS. The objective is to assess the feasibility and prepare 29 Digital Innovation Hubs involving new and existing competence centres, manufacturing SMEs and mid-caps and other stakeholders such as regional bodies.
This Mentoring programme is set within the framework of the I4MS. The first phase of the I4MS 2013-2015 has resulted in seven integrated projects, more than 60 competence centres and about 150 experiments implemented in the I4MS community. However, when looking at the distribution of the activities it is clear that participation to the I4MS is mostly limited to the Member States that are strong in the technologies supported by I4MS. The I4MS Phase 2 aims to significantly expand the coverage of I4MS to include regions not presently participating in the I4MS initiative in order to achieve a more balanced coverage of EU regions. To create participation of new regions in I4MS, some will need support and mentorship. This is also of importance, as to the further developed the I4MS ecosystem, other sources of funding (regional, national, other) have to be linked up.
The I4MS Mentoring programme call addressed activities that extend the I4MS ecosystem to European regions where I4MS is not yet systematically addressed. Projects were selected that assess feasibility of new Digital Innovation Hubs to be established in an EU Member State. The projects selected proposed to assess and prepare an innovation ecosystem in their region which can benefit from the use of the technologies and competences available in I4MS network.
The main objective of these projects was to conduct a feasibility study to assess if establishing a DIH would be possible in their region. The overall work includes:
• Participate in a kick-off meeting that will inform the new hubs on the opportunities of digital industry for their regions and approaches to (further) develop an I4MS innovation network in their region. The multiple day meeting will be organised by the I4MS partners and inform the core project consortia partners on the I4MS context, but also educate them on specific topics to create their DIH (e.g. finding and financing hubs, creating networks, the I4MS technologies, etc.).
• Organise regional workshop(s) with potential interested partners and stakeholders such as SMEs, midcaps, investors, technology providers, education and R&D institutions to explore the possible development of a DIH. The workshop(s) are instrumental to creating commitment in the region to establish the DIH.
• Up to 3 use cases, experiments, including the innovation hub and SMEs (and possibly mid-caps) located in the region. This feasibility study must show the added value of the DIH towards the region in concrete case (added value of the RDMI-hub, costs, organisation of the experiment, possible regional funding sources, objectives, core technology, etc.)
• Prepare a business plan on how to develop innovation activities with local & regional administrations and industry and what are the possible funding mechanisms that can be used. This plan must at least include an analysis of the potential added value of the DIH (regionally, nationally and internationally), as well as a description of the business models (and services), estimation of costs, possible funding, and a description of the how the consortium will continue after the Mentoring and sponsoring project.
• The consortium must be represented during a one day meeting within the framework of the Mentoring and sponsoring programme, presenting their project to the European Commission (in Brussels).
This background document will provide background information on the development of the use cases.
1.2 Use cases are an important element to the DIH feasibility studies
The main remit of Digital Innovation Hubs is to provide innovation services to SMEs to accelerate and drive the digitisation of European industry from the bottom up. A key part of this is to have a formalised process to capture industry requirements and to provide a statement of the services that may be provided by the DIH to address those requirements. Use cases, are a way to support this process, by providing a template to formalise industrial challenges and objectives, proposed services (including deliverables, timescales and cost), expected benefits and impact. In this way, use cases are a communication tool to: 1) facilitate the dialogue between the DIH and an organisation during initial engagement, 2) support the definition of realistic and relevant projects and 3) negotiate scope, timescales and project price.
1.3 What to deliver: Overview of the use case deliverable elements
As the use cases are seen as mechanisms to ensure concrete experience with the services of the DIH, the following elements are to be addressed:
· A description of the service that is to be provided by the DIH and its direct link to the business case of the customer.
· General description of the use case and/or description of your use case in a non-technical, user-focused way.
· Short description of the technical objectives for the use case.
· The expected benefits the customer hopes to gain from the service.
· A list the solutions and capabilities provided by the DIH.
· A more detailed description of the possible project scope and price.
These use cases must be developed in close cooperation with a concrete customer to ensure practical hands-on experience. As many use cases as possible should be conducted to increase practical experience.
For the reporting of the use cases, a template is available.
2 How to conduct a use case assessment
2.1 Suggestions to the overall process to create a use case
Use cases should be captured with significant input from the customer and should be developed on the basis of an understanding of the customer requirements and the value proposition offered by the DIH. It is recommended that interactive sessions with the customer are held (e.g. calls, face to face meetings, workshops or site visits, depending on the scale of the project) to build an understanding of the context of the service request and what the customer is trying to achieve. This understanding should be portrayed in the first part of the use case template (sections 1 and 2).
The second part of the use case template (section 3, 4 and 5) should capture the solution to be provided by the DIH. This should be defined together with the technical experts in the topic within the DIH or in partner organisations. This entail the definition of a service that addresses the objectives outlined in the first part of the use case. This should include a definition of the service (including costs and preferably timescales), the expected benefits and the areas of risk in the project. These sections should provide the customer enough information for them to make a decision to contract the services and submit a Purchase Order.
This guide will walk you through the process of filling in a use case. What you need to take into consideration with example of what to write. The template is included in the following section.
2.2 Discussion on the reporting elements
2.2.1 Description of the organisation
When describing the organisation, particular emphasis should be put on the jobs they are trying to do and the outcomes they are trying to achieve in relation to the use case. It is also important to understand the specific business drivers of the organisation (e.g. quality, on-time delivery, safety), as this will be key to direct the use case later on.
Name of the organisation who the use case is for. E.g. if you are writing a use case about a problem MTC is having, then MTC is what you write.
What do the organisation do e.g. if they are an end user and manufacture goods, what is it that they manufacture?
1. Organisation InformationName of the organisation / Anonymous
Description of organisation.
2.2.2 Description of the use case
Description / User Story:
Leading on from the organisation description, this section should provide detail about what the end user or the organisation is trying to achieve in the use case, in terms of jobs or outcomes.
This section should provide details on the barriers and obstacles to achieving the outcomes or jobs described in the use case name. This is the main description of the problem.
Technical Objectives:
This section should define the key success factors of the use case and answer what does success looks like. A qualitative description of the objectives is necessary, but quantifiable targets are even better and would significantly strengthen the use case (e.g. 20% improvement in resource utilisation). Any additional information on specific requirements would strengthen the use case.
Example:
2. Use CaseThe name of the use case should express what happens when the use case is performed.
Quality traceability
Description/User story
General description of your use case and/or description of your use case in a non-technical, user-focused way. / Current processes for quality traceability are usually manual and paper-based i.e. when there is a problem with a product, paper documents have to be sourced to find out what the issues were. This is a time consuming, unreliable and error prone process. This in turn leads to losses in productivity and slow response times with customers.
The main issues are related to:
· Formalisation of information in paper based format as this is prone to human error resulting in the wrong information being captured and lack of longevity of the information as the data gets obsolete and the paper and ink age.
· Storage of information as there is not a rigorous process and protocol for information storage and therefore sometimes documents are lost.
· Document check in and check out as there are not formalised processes to remove or return documents to storage or any traceability on who has the documents at all times and a history of who have the documents when.
Technical Objectives
Short description of the technical objectives for this Use Case. / · Full digitisation of quality data management;
· Increasing accuracy and longevity of quality data;
· Ensuring complete traceability of quality data at all times;
· Reduction data retrieval time by at least 50%;
· Complete elimination of quality data loss.
2.2.3 Description of the services provided by the DIH
This section should provide a statement of work (i.e. a description of the work proposed to solve the use case). Ideally, the description of services should include the general description of the solution or service to be provided (e.g. technology benchmarking or FEA simulation for process calibration), deliverables, costs estimates and timescales. Providing a menu of different alternative project sizes might help a customer making a decision.
3. Description of Service, Cost estimate and Funding SourceList the services provided and the price estimate (the numbers provided are fictitious and only provided as examples)
There is a requirement to fully digitise and automate processes around quality data, including capture, storage and retrieval. The project will be delivered in three phases:
Phase 1: Implementation of tools for digitisation of legacy data (4 weeks)
Phase 2: Development of a data model, data repository and population with existing data (7 weeks)
Phase 3: Definition and implementation of digital quality data processes including capture, storage, queries and traceability (12 weeks)
Milestone 1: Paper based data assessment
Deliverable 1: Delivery of tested digitisation solution (£15,000)
Deliverable 2: Delivery of quality data repository populated with existing data and with an accompanying document describing the data model. (£30,000)
Deliverable 3: Delivery of tested and documented quality data management solutions (£40,000)
Funding mechanisms (e.g. European H2020, national, regional or direct funding)
Direct funding
For all deliverables 50% payment on receipt of order and 50% payment on delivery.
2.2.4 Expected benefits of the DIH service
Ideally, this section would address directly the statements in the user story description and the technical challenges. This section should describe how the project / solution / service is enabling the jobs and outcomes described in the user story and how is it achieving the technical objectives and to what extent). It is also very important to describe to your customer the implications of the results achieved in wider business drivers.
After indicating your objectives, now you have to write what you expect to achieve or how you expect to benefit. An example can be found below:
4. Expected benefits / ImpactWhat are the expected benefits you hope to gain from this?
The project is expected to streamline quality data management processes, including:
· Full digitisation of quality data management;
· Increasing accuracy and longevity of quality data;
· Ensuring complete traceability of quality data at all times;
· Reduction data retrieval time by at least 50%;
· Completely elimination of quality data loss.
As a result, the customer is expected to generate 15% savings on the cost of quality management. Additionally, employee time will be released to perform higher value added tasks such as problem solving and quality improvement. Finally, the organisation with increase value to customer by ensuring full traceability of all quality data and by reducing response times for quality issues, ultimately leading to significant improvements on customer service and customer relationship.
2.2.5 Issues and Challenges with the DIH service
This section acts as a technical risk register. It is important to highlight the areas that may be particularly challenging (for example, because the technology is not mature or because it is a critical application). The role of this section is to set the use case in a realistic context and to provide the user with an understanding of the potential challenges that may affect the scope of the project (with potential time and cost implications) or your ability to meet the objectives.