Difference between revisions of "SSE Meeting 12"

From Service Systems Engineering Group Wiki
Jump to: navigation, search
(Created page with "INCOSE UK Service Systems Engineering Meeting 3 November 2014 Held at QinetiQ, London. == Attendees == Steve Ashlin, Iain Cardlow (by phone), Andrew Farncombe, John Davies, ...")
 
(Plan)
 
(6 intermediate revisions by one user not shown)
Line 1: Line 1:
INCOSE UK Service Systems Engineering Meeting 3 November 2014
+
INCOSE UK Service Systems Engineering Meeting 23 January 2015
  
Held at QinetiQ, London.
+
Held at Rolls-Royce, Filton, Bristol
  
 
== Attendees ==
 
== Attendees ==
Steve Ashlin, Iain Cardlow (by phone), Andrew Farncombe, John Davies, Alan Crawford
+
Steve Ashlin, Iain Cardlow, Peter Mason(by phone), Andrew Farncombe, John Davies, Alan Crawford
  
== Issues with Changes to Services ==
+
== Plan ==
A wide ranging discussion came up with the following:
+
Steve has updated the plan. Mostly to revise the timing to better fit with the effort/progress that is being achieved.
* Traditionally in Product-based systems, changes have been in two classes -
+
** Class 1: Requirements Change when the customer wants the system to do something different, or more general a change to the 'problem'.
+
** Class 2: When the suppler wants a change because of changes to the technology, or more generally the solution.
+
*With Services it may be necessary to handle continuous change, but also there can be 'disruptive change' where step changes are made.
+
*A Service contract is more likely to enable changes at delivery, for example, maintenance and re-fitting of ships depends on when they are available.  With a Product contract, the dates were set in the contract, with a Service contract the work gets done when it can.
+
* Changes can be related to Stakeholders : The Consumer, the Suppler and Legislation
+
* Changes to services can have incentives for both the Customer and the Supplier.  If a supplier is providing a service then for any improvement, the supplier is part of the change.  For a Product delivery the customer can decide the change and the supplier delivers it, but is not really part of the change.
+
* Environmental changes can be different for Services and Products.  Where 'evironment' are things outside the specific service contract. These could be changes in technology, competitor offerings, legislation.
+
  
Phil John has remarked in the past that different types of changes have different time-scales:
+
== ASEC14 ==
* Technology changes quickly so an optimum solution for a service may change quickly
+
=== Poster ===
* Customer needs tend to change at a slower rate.
+
The Working Group [http://www.incoseonline.org.uk/documents/Groups/SSE/ASEC2014_SSE_Poster_v3.pdf Poster] resulted in some interest and discussion, but has not resulted in extending the group membership.
* Some procurement systems are lethargic and very slow.
+
+
  
== Service Lifecycle Issues ==
+
=== Paper ===
The following Lifecycle for Services was used as a basis for discussion:
+
Dan Wilson from Fraser-Nash presented a [http://www.incoseonline.org.uk/Documents/Events/ASEC2014/Day1/Applying_Systems_Engineering_to_Service_Provision.pdf paper] 'Applying Systems Engineering to Service Provision'.  This takes a typical development project lifecycle process and adapts it for development of a service. It uses its own definition of 'Service' and hence area of interest, but is of some interest to this group.
  
* Setting up the Service
+
== Use Cases ==
** Understanding/Designing the business model
+
A number of areas were discussed.
** Designing the Service
+
=== Terminology ===
** Integrating the Service
+
We use the term 'Use Case' to mean a useful example described using a template.  In some areas of engineering 'use Case' has a fixed meaning and fixed template.  In our case we could use the term 'Case Study' or 'Real Example'.
 +
=== Template ===
 +
The current template is a list of areas of information to be covered.  There may be more areas to add or some could be removed if not found to be useful.  Currently most Use Cases use the template in MSPowerPoint, it may be better to have them in MSWord in the future.
 +
=== Stakeholders ===
 +
Stakeholder analysis and relationships are seen as important and should be covered within the template.  They may be related to WorldViews - see below.
  
* Framework for day-to-day operations
+
=== Rapid Acquisiton of Manufactured Services ===
** Running the service
+
Alan presenteed work he has been involved in over many years linked to the Royal Navy.  This has been work to replace stockpiles of hardware spares with a service that supplies spares when they are needed.  This has involved capturing and standardising engineering designs (CAD) and then going out to tender for manufacture (CAM) when the spare parts are needed.  it was agreed this would make a good Use Case in a different area of business of interest to UKAB member companies.
** Modifications and changes
+
== World Views ==
** Handling Obsolescence
+
This activity has not started, Alan volunteered to lead it.  This work is seen as important as similar activities have proved vry useful in the Architectures and Capability Working Groups.
** Changes made day-to-day
+
== Definitions ==
 +
Literature on Services has been reviewed to find useful definitions of services.  Five types of definition have been found, examples of these are:
 +
* Service: an intangible product: 'In economics, a service is an intangible commodity. That is, services are an example of intangible economic goods.' (Wikipedia)
 +
* Service use: A Service is a set of actions or solutions that are put in place or are performed to provide a repeatable and consistent set of outcomes, deliverables, and performance for people, organizations, and systems that represent consumers or beneficiaries of such results. (Wikipedia)
 +
* Service System: One or more  of… an integrated set of elements, subsystems, or assemblies that accomplish a defined objective.  (INCOSE Handbook v3.2)
 +
* Service Specification: Services are an implementation-independent specification of a packaged element of functionality.  (MoDAF)
 +
* Service Agreement. An activity required by one or more users who have agreed on the terms of outcomes and quality of service without details to how it is provided. (SeBOK)
 +
It is felt that these are all correct but are based on different aspects of a service.  To understand these view and their relationships a set of definitions for terms connected with services has been used and extended to form an Entity Relationship Diagram (ERD).
  
The Customer business process process supported by the system or service is traditionally determined by the customer, but with Services, the process may be better designed by the supplier:
+
Further work will look to extend this to an Ontolgy that can be used to better understand the different aspects of services used in literature and are needed in particular situations.
*For Product-based systems - the Customer decides the process
+
*For Service-based systems - the Supplier decides the process.
+
  
== Review of applicability of the INCOSE Systems Engineering Handbook to Services ==
+
== Work of Core Group members ==
Version 3.2 has been reviewed for its content with respect to Service Systems Engineering.  The term 'Service Systems Engineering' does not appear within the document, and there are no sections specifically dealing with Services. However the term 'products and services' appears in many places in particular as the outputs of the Systems Engineering process.
+
 
+
Version 4 is in preparation and planned to be released in May 2015.  It is understood that the main changes are to provide better alignment with ISO/IEC 15288.
+
== Work Plan ==
+
The current state of work against the plan was reviewed.  Steve A has updated the plan and supporting set of slides to cover the work being progressed.
+
 
+
== Development of Use Cases ==
+
=== Management of Test Ranges ===
+
This has been moved to the agreed template with the MoD Lines of Development (TEPIDOIL) used to describe the Enterprise.
+
[http://www.qinetiq.com/services-products/weapons/Pages/test-and-evaluation.aspx ,QinetiQ Test and Evaluation Ranges]
+
 
+
=== Electric Car Rental ===
+
This is a Cambridge Services Alliance Case Study of an Electrical Car Rental Scheme in Japan.
+
[http://www.cambridgeservicealliance.org/news/113/61/Electric-Vehicle-Rental-Services---Case-Study-Report.html ,Electric Vehicle Rental]
+
Although the rental business was well understood and the products worked correctly, the scheme was not a financial success due to an over-optimistic business plan and a lack of co-operation between stakeholders.
+
 
+
=== Provision of Services for Film Post Production ===
+
ZOO Digital provide post production services for the film, TV, games and other Media Industries.  The services are provided on Amazon Cloud via the Internet.  [http://www.zoodigital.com/ ,ZOO Digital]
+
 
+
=== UK Government 'Digital Market Place' ===
+
Thw UK Government are enabling departments to rent IT from service providers via the Digital Market Place'  The services are accessible via the Government Cloud (G-Cloud).  COntracts are direct between the Government Department and the provider and can go up to £100M and two years duration.
+
[https://www.digitalmarketplace.service.gov.uk/ ,Digital Market Place]
+
 
+
== ASEC14 Poster ==
+
Steve A and Andrew F are going to the conference and will field questions about the Working Group.
+
 
+
All Working Groups are producing a Poster to a fixed format.  Steve A, Andrew F and John D will produce the Poster by 7 November, based on existing work.
+
 
+
== Work of core group members ==
+
  
 
For the next meeting following will be looked at/developed:
 
For the next meeting following will be looked at/developed:
*Steve A: Use Case for specific trials
+
*Steve A: Updates for Use Cases
*Peter M: Procurement use case
+
*Peter M: Procurement Use Case
*Rachel F: Energy efficiency Use Case
+
 
*Iain C: Engine provision Use Case
 
*Iain C: Engine provision Use Case
*John D: Electric Car Rental Use Case  
+
*John D: Develop Definitions work, Update Use Cases  
*Andrew F: Review INCOSE Handbook - distribute notes
+
*Andrew F: INCOSE Handbook v4
*Alan C: Review existing material
+
*Alan C: Develop RAMP Use Case, Preparation for WorldView work.
  
 
== Date for next meeting: ==
 
== Date for next meeting: ==
  
23 January 2015 – Rolls-Royce, Filton, Bristol
+
23 March 2015 – QinetiQ, London.

Latest revision as of 18:06, 24 March 2015

INCOSE UK Service Systems Engineering Meeting 23 January 2015

Held at Rolls-Royce, Filton, Bristol

Contents

[edit] Attendees

Steve Ashlin, Iain Cardlow, Peter Mason(by phone), Andrew Farncombe, John Davies, Alan Crawford

[edit] Plan

Steve has updated the plan. Mostly to revise the timing to better fit with the effort/progress that is being achieved.

[edit] ASEC14

[edit] Poster

The Working Group Poster resulted in some interest and discussion, but has not resulted in extending the group membership.

[edit] Paper

Dan Wilson from Fraser-Nash presented a paper 'Applying Systems Engineering to Service Provision'. This takes a typical development project lifecycle process and adapts it for development of a service. It uses its own definition of 'Service' and hence area of interest, but is of some interest to this group.

[edit] Use Cases

A number of areas were discussed.

[edit] Terminology

We use the term 'Use Case' to mean a useful example described using a template. In some areas of engineering 'use Case' has a fixed meaning and fixed template. In our case we could use the term 'Case Study' or 'Real Example'.

[edit] Template

The current template is a list of areas of information to be covered. There may be more areas to add or some could be removed if not found to be useful. Currently most Use Cases use the template in MSPowerPoint, it may be better to have them in MSWord in the future.

[edit] Stakeholders

Stakeholder analysis and relationships are seen as important and should be covered within the template. They may be related to WorldViews - see below.

[edit] Rapid Acquisiton of Manufactured Services

Alan presenteed work he has been involved in over many years linked to the Royal Navy. This has been work to replace stockpiles of hardware spares with a service that supplies spares when they are needed. This has involved capturing and standardising engineering designs (CAD) and then going out to tender for manufacture (CAM) when the spare parts are needed. it was agreed this would make a good Use Case in a different area of business of interest to UKAB member companies.

[edit] World Views

This activity has not started, Alan volunteered to lead it. This work is seen as important as similar activities have proved vry useful in the Architectures and Capability Working Groups.

[edit] Definitions

Literature on Services has been reviewed to find useful definitions of services. Five types of definition have been found, examples of these are:

  • Service: an intangible product: 'In economics, a service is an intangible commodity. That is, services are an example of intangible economic goods.' (Wikipedia)
  • Service use: A Service is a set of actions or solutions that are put in place or are performed to provide a repeatable and consistent set of outcomes, deliverables, and performance for people, organizations, and systems that represent consumers or beneficiaries of such results. (Wikipedia)
  • Service System: One or more of… an integrated set of elements, subsystems, or assemblies that accomplish a defined objective. (INCOSE Handbook v3.2)
  • Service Specification: Services are an implementation-independent specification of a packaged element of functionality. (MoDAF)
  • Service Agreement. An activity required by one or more users who have agreed on the terms of outcomes and quality of service without details to how it is provided. (SeBOK)

It is felt that these are all correct but are based on different aspects of a service. To understand these view and their relationships a set of definitions for terms connected with services has been used and extended to form an Entity Relationship Diagram (ERD).

Further work will look to extend this to an Ontolgy that can be used to better understand the different aspects of services used in literature and are needed in particular situations.

[edit] Work of Core Group members

For the next meeting following will be looked at/developed:

  • Steve A: Updates for Use Cases
  • Peter M: Procurement Use Case
  • Iain C: Engine provision Use Case
  • John D: Develop Definitions work, Update Use Cases
  • Andrew F: INCOSE Handbook v4
  • Alan C: Develop RAMP Use Case, Preparation for WorldView work.

[edit] Date for next meeting:

23 March 2015 – QinetiQ, London.

Service Systems Engineering Group Wiki

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox