SSE Poster at ASEC 2014

Introduction

Why Services? What Systems Engineering?

The Customer says:

• 'We keep buying products that are obsolete when they are delivered.’

• ‘We need suppliers to own the kit and we only pay when we use it. That way we save costs and put all the risk onto the supplier. ‘

• ‘Our systems engineers need to define the Services we need so we can contract our suppliers to provide them.'

The Supplier says:

• 'Our customers are changing from ‘procurement of equipment’ organisations to ‘procurement of services’ organisations.’

• ‘If we want to stay in business we need to change to an organisation that provides services, not just equipment; but we still need low risk and to make a profit.’

• ‘We need our Systems Engineers to sort out what we need for the bid and then deliver service contracts that are manageable and profitable.'

Overview

Forming

The initial meeting was held in May 2013. ‘Think Pieces’ were provided by experts in different domains. Breakout sessions and feedback were used to help determine the way ahead for the group members and activities.

Storming

The scope of Services to be addressed by the group has been an issue and has driven different views of the work to do. Various expectations of ‘Services’ of interest ranged from provision of Cloud applications on portable devices using Service Oriented Architectures, to ‘Power by the Hour’, to the work of ‘Customer Friends’ and many more.

The clever definition ‘A service is anything that doesn’t hurt when you drop it on your foot!’ proved less useful than telling a six-year-old ‘A sentence starts with a capital letter and ends with a full stop.’

An initial set of Use Cases were captured and presented at ASEC13 along with an exploration of what characteristics of services could group different services to find common issues and solutions. Feedback from the ASEC13 session was useful in identifying issues of interest to INCOSE members, providing a wider range of potential Use Cases, more characteristics of Services, and the need to re-think areas we just had wrong.

Norming

We are now working to a plan that captures the work done so far and the way forward. The activities have been defined together with their outputs and relationships.

A template for Use Cases has been developed that captures the key information needed.

The set of Characteristics of Services has been rationalised

Performing

On-going meetings are held bi-monthly in London or Bristol, with phone-in available. A core team of six has emerged who are doing most of the work, with others joining in occasional meetings and providing useful objective review and feedback.

Further Use Cases are being captured using the standard template and used to identify issues and solutions, which can then be generalised.

Core Objectives

The Core Objective of the Service Systems Engineering Working Group (SSE WG) is to determine whether Systems Engineering as applied to the provision of services substantively differs from Systems Engineering as applied to the provision of products.

In other words: how (if at all) is Service Systems Engineering (SSE) different from ‘Plain Old Systems Engineering’ (‘POSE’)?

If there is a distinct variant of SSE, what does it look like?

Consequently, the SSE Working Group’s focus is on the ‘deltas’ between POSE and SSE, rather than to re-invent SE-from-a-services-point-of-view from scratch*.

The key output of the SSE WG will be guidance to INCOSE members on the SSE approaches (lifecycle approaches, processes, tools and techniques) that when applied correctly could reduce risk in the design and delivery of services.

• If the SSE WG concludes that these deltas are zero or non-existent, so be it; in the WG’s eyes, that fact would still be a significant conclusion.

Activities & Outputs

The Modus Operandi of the SSE Working Group is to look at examples of service-orientated projects (Use Cases), characterise them, and derive key issues and lessons learned.

In parallel, a literature search is being used to:

• Review the applicability of existing Systems Engineering standards such as the Systems Engineering Book of Knowledge (SEBoK) and the INCOSE Systems Engineering Handbook.
• Evaluate existing service standards such as CMMI for Services and IT Service Management (ITIL)
• Analyse outputs of current research such as those from the Cambridge Services Alliance.
• Identify approaches and techniques that may be useful for SSE.

SSE approaches that would have been useful in the lifecycle of the service examples will be identified. These will be communicated to INCOSE members via standard methods such as Z- and ω-guides and influence of existing INCOSE publications.

Explore and capture characteristics of services

• Classification of service types using set of standard characteristics

Develop and analyse Use Cases

• Identification of service Use Cases relevant to UKAB and INCOSE members
• Standardisation of Use Cases using template
• Extraction of key issues and lessons learned

Review existing guidance and literature

• Identification of SSE approaches not covered by POSE

Develop and validate SSE approaches

• Apply guidance to Use Cases to validate

Produce guidance for INCOSE members

• Guidance on how to characterise the ‘service of interest’
• Guidance on which SSE approaches are applicable to which service type

How to get Involved

• Join the Group via the INCOSE UK Web Site – you then get notified of all activities

• Come to meetings - six times a year, alternating between Bristol and London

• Read the current state from notes of the meetings and links to background information on the Group’s Wiki Page and the Think Pieces via the web-site

• Contribute by providing your experiences, Use Cases and background information.