Difference between revisions of "SSE Meeting 11"
(→ASEC14 Poster) |
|||
| Line 7: | Line 7: | ||
== Issues with Changes to Services == | == Issues with Changes to Services == | ||
| + | A wide ranging discussion came up with the following: | ||
| + | * 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: | ||
| + | * Technology changes quickly so an optimum solution for a service may change quickly | ||
| + | * Customer needs tend to change at a slower rate. | ||
| + | * Some procurement systems are lethargic and very slow. | ||
| + | |||
== Service Lifecycle Issues == | == Service Lifecycle Issues == | ||
| + | The following Lifecycle for Services was used as a basis for discussion: | ||
| + | |||
| + | * Setting up the Service | ||
| + | ** Understanding/Designing the business model | ||
| + | ** Designing the Service | ||
| + | ** Integrating the Service | ||
| + | |||
| + | * Framework for day-to-day operations | ||
| + | ** Running the service | ||
| + | ** Modifications and changes | ||
| + | ** Handling Obsolescence | ||
| + | ** Changes made day-to-day | ||
| + | |||
| + | 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: | ||
| + | *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 == | == Review of applicability of the INCOSE Systems Engineering Handbook to Services == | ||
| Line 20: | Line 51: | ||
=== Management of Test Ranges === | === Management of Test Ranges === | ||
| − | [http://www.qinetiq.com/services-products/weapons/Pages/test-and-evaluation.aspx] | + | [http://www.qinetiq.com/services-products/weapons/Pages/test-and-evaluation.aspx, QinetiQ Test and Evaluation Ranges] |
This has been moved to the agreed template with the MoD Lines of Development (TEPIDOIL) used to describe the Enterprise | This has been moved to the agreed template with the MoD Lines of Development (TEPIDOIL) used to describe the Enterprise | ||
| Line 26: | Line 57: | ||
=== Electric Car Rental === | === Electric Car Rental === | ||
| − | [http://www.cambridgeservicealliance.org/news/113/61/Electric-Vehicle-Rental-Services---Case-Study-Report.html] | + | [http://www.cambridgeservicealliance.org/news/113/61/Electric-Vehicle-Rental-Services---Case-Study-Report.html, Electric Vehicle Rental] |
=== Provision of Services for Film Post Production === | === Provision of Services for Film Post Production === | ||
| − | [http://www.zoodigital.com/] | + | [http://www.zoodigital.com/, ZOO Digital] |
=== UK Government 'Digital Market Place' === | === UK Government 'Digital Market Place' === | ||
| − | https://www.digitalmarketplace.service.gov.uk/ | + | [https://www.digitalmarketplace.service.gov.uk/, Digital Market Place] |
== ASEC14 Poster == | == ASEC14 Poster == | ||
Revision as of 11:05, 10 November 2014
INCOSE UK Service Systems Engineering Meeting 8 September 2014
Held at QinetiQ, London.
Contents |
Attendees
Steve Ashlin, Iain Cardlow (by phone), Andrew Farncombe, John Davies, Alan Crawford
Issues with Changes to Services
A wide ranging discussion came up with the following:
- 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:
- Technology changes quickly so an optimum solution for a service may change quickly
- Customer needs tend to change at a slower rate.
- Some procurement systems are lethargic and very slow.
Service Lifecycle Issues
The following Lifecycle for Services was used as a basis for discussion:
- Setting up the Service
- Understanding/Designing the business model
- Designing the Service
- Integrating the Service
- Framework for day-to-day operations
- Running the service
- Modifications and changes
- Handling Obsolescence
- Changes made day-to-day
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:
- 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
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
QinetiQ Test and Evaluation Ranges
This has been moved to the agreed template with the MoD Lines of Development (TEPIDOIL) used to describe the Enterprise
Electric Car Rental
Provision of Services for Film Post Production
UK Government '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:
- Steve A: Use Case for specific trails
- Peter M: Procurement use case
- Rachel F: Energy efficiency Use Case
- Iain C: Engine provision Use Case
- John D: Electric Car Rental Use Case
- Andrew F: Review INCOSE Handbook - distribute notes
- Alan C: Review existing material
Date for next meeting:
12 January 2015 – Bristol - University or Rolls-Royce
