Difference between revisions of "SSE Meeting 5"

From Service Systems Engineering Group Wiki
Jump to: navigation, search
(Review of Cambridge Services Alliance Documents)
m
 
(4 intermediate revisions by one user not shown)
Line 23: Line 23:
 
Adaptability;  Availability;  Complexity of Service;  Complexity of the supply chain;  Constraints – legislation, regulatory, standards;  Contract Liability;  Contractual concepts;  Cost of disposal;  Cost of re-supply;  Costs of maintenance of the service;  Costs of usage of the service;  Critical resources;  Cultural Distances;  Culture of Service Provider (‘minimal’ to ‘Above and Beyond’);  Customer impact on performance;  Customer/User division;  Delays;  Disposability;  Distance from customer domain;  Environment;  Environmental performance;  Flexibility (of Scale);  Flexibility (of Scope);  Human Factors;  Maintainability;  Materials;  Obsolescence;  Political Factors;  Potential for intelligent procurement;  Preparedness;  Regulations;  Reliability ;  Risk (compliance, regulatory, market, intangibles);  Risk (of Regulatory Change);  Risk (of Supplier non-performance);  Risk Profile;  Security;  Service components;  Type of Customer;  Type of User;  Uncertainty in characterisation of desired outcome;  Usability/accessibility
 
Adaptability;  Availability;  Complexity of Service;  Complexity of the supply chain;  Constraints – legislation, regulatory, standards;  Contract Liability;  Contractual concepts;  Cost of disposal;  Cost of re-supply;  Costs of maintenance of the service;  Costs of usage of the service;  Critical resources;  Cultural Distances;  Culture of Service Provider (‘minimal’ to ‘Above and Beyond’);  Customer impact on performance;  Customer/User division;  Delays;  Disposability;  Distance from customer domain;  Environment;  Environmental performance;  Flexibility (of Scale);  Flexibility (of Scope);  Human Factors;  Maintainability;  Materials;  Obsolescence;  Political Factors;  Potential for intelligent procurement;  Preparedness;  Regulations;  Reliability ;  Risk (compliance, regulatory, market, intangibles);  Risk (of Regulatory Change);  Risk (of Supplier non-performance);  Risk Profile;  Security;  Service components;  Type of Customer;  Type of User;  Uncertainty in characterisation of desired outcome;  Usability/accessibility
  
=== Not Useful ===
+
=== Attributes for Services that are Not Useful ===
  
 
Basis of contract; Development Cost
 
Basis of contract; Development Cost
Line 31: Line 31:
 
Banking;  Builder;  Car Servicing;  Communications (including Broadband);  Consultancy;  Customer Friend (expert support to project office);  Facilities Management;  Health;  Information Services (to replace Web Service, Web Applications, etc.);  Police;  Power generation, distribution and provision;  Retail;   
 
Banking;  Builder;  Car Servicing;  Communications (including Broadband);  Consultancy;  Customer Friend (expert support to project office);  Facilities Management;  Health;  Information Services (to replace Web Service, Web Applications, etc.);  Police;  Power generation, distribution and provision;  Retail;   
  
=== Not Useful ===
+
=== Services that are Not Useful to consider ===
  
 
House;  Salt;  Necktie;  Dog food; Tailored Suit (examples of non-services from BAE Systems think piece)
 
House;  Salt;  Necktie;  Dog food; Tailored Suit (examples of non-services from BAE Systems think piece)
Line 60: Line 60:
 
* We should validate with stakeholders the check the direction we are going
 
* We should validate with stakeholders the check the direction we are going
 
* There are issues with defining common international terminology, but which then has National characteristics
 
* There are issues with defining common international terminology, but which then has National characteristics
* Service Oriented Architectures have standard defined terminology which has little 'Nationalisation' as its used for implementaion.  
+
* Service Oriented Architectures have standard defined terminology which has little 'Nationalisation' as its used for implementaion. * Contracts are a particular concern with the same contractual conditions having different implications in the UK, France, Germany, Italy, US, etc.  This has been overcome with Software SOAs - where contracts are fully defined and coded in XML or another language. (Similar to digital interfaces having to be fully defined with no 'room for adjustment' unlike physical interfaces which can be adjusted to fit with a hammer!)
 
* There are 'Silo' approaches to defining/using services - we need holistic approaches
 
* There are 'Silo' approaches to defining/using services - we need holistic approaches
 
* SEBoK has pages on Services and Services Systems Engineers - appears to be partly based on ITIL v3.  needs reviewing
 
* SEBoK has pages on Services and Services Systems Engineers - appears to be partly based on ITIL v3.  needs reviewing
* We could review ITIL v3 and identify what it covers for Systems Engineering that is useful and what needs adding
+
* We could also review ITIL v3 and identify what it covers for Systems Engineering that is useful and what needs adding
  
 
=== Way Forward ===
 
=== Way Forward ===
Line 71: Line 71:
 
* Need to review SEBoK for areas that apply to Services and what needs adjusting and adding
 
* Need to review SEBoK for areas that apply to Services and what needs adjusting and adding
  
== Produce-Service Systems ==
+
== Product-Service Systems ==
 
"Product Service Systems, put simply, are when a firm offers a mix of both products and services, in comparison to the traditional focus on products" (Wikipedia)
 
"Product Service Systems, put simply, are when a firm offers a mix of both products and services, in comparison to the traditional focus on products" (Wikipedia)
  
Line 92: Line 92:
 
Further work is needed to go through the Cambridge reports and identify which are of interest to this work.
 
Further work is needed to go through the Cambridge reports and identify which are of interest to this work.
  
== Work of core group members ==
+
== Work of Core Group members ==
  
 
For the next meeting following will be looked at:
 
For the next meeting following will be looked at:

Latest revision as of 09:04, 3 April 2014

Held on 27 November 2013 at UCL London

Contents

[edit] Attendees

Peter Mason, Andrew Farncombe, John Davies, Stephen Ashlin, Laura Mullin

[edit] New chairman

Tony Johnson has formally resigned due to work commitments. Following discussion it was agreed that Peter Mason be chairman and Iain Cardow will be Vice-chair or Co-chair. If Iain isn’t able to do this, Steve Ashlin will be Vice-chair or Co-chair.

[edit] Review of draft plan and work so far

A quick check against the draft plan identified a number of the activities have started, some have completed and some have been extended as the work has developed and the issues better identified. Steve A will review, revise and extend the plan to better capture our current thinking.

[edit] Washup on ASEC13 SSE Workshop and follow-on work

It was agreed that this went well with about 12 participants from outside the core group. There was very good participation which provided a lot of input to the work, which has been captured. It was agreed to try and keep these members involved in reviewing the work of the group by e-mail. JD to try to get the e-mails.

Outputs from the workshop from the participants were:

[edit] Potentially Useful Attributes for Services

Adaptability; Availability; Complexity of Service; Complexity of the supply chain; Constraints – legislation, regulatory, standards; Contract Liability; Contractual concepts; Cost of disposal; Cost of re-supply; Costs of maintenance of the service; Costs of usage of the service; Critical resources; Cultural Distances; Culture of Service Provider (‘minimal’ to ‘Above and Beyond’); Customer impact on performance; Customer/User division; Delays; Disposability; Distance from customer domain; Environment; Environmental performance; Flexibility (of Scale); Flexibility (of Scope); Human Factors; Maintainability; Materials; Obsolescence; Political Factors; Potential for intelligent procurement; Preparedness; Regulations; Reliability ; Risk (compliance, regulatory, market, intangibles); Risk (of Regulatory Change); Risk (of Supplier non-performance); Risk Profile; Security; Service components; Type of Customer; Type of User; Uncertainty in characterisation of desired outcome; Usability/accessibility

[edit] Attributes for Services that are Not Useful

Basis of contract; Development Cost

[edit] Useful Services to consider/study

Banking; Builder; Car Servicing; Communications (including Broadband); Consultancy; Customer Friend (expert support to project office); Facilities Management; Health; Information Services (to replace Web Service, Web Applications, etc.); Police; Power generation, distribution and provision; Retail;

[edit] Services that are Not Useful to consider

House; Salt; Necktie; Dog food; Tailored Suit (examples of non-services from BAE Systems think piece)

Web Application; Web Services; Social Media – are similar and could all be covered by Information Services

[edit] Issues Identified at the Workshop

  • Availability/Reliability (ARM – only need two as A = 1 – (MTTR/MTBF))
  • Contractual concepts
  • Customer/User division
  • Distance from customer domain
  • Electricity Companies – some produce electricity, National Grid distributes it, some have retail customers
  • Financial arrangements
    • eg for TFL cycle scheme does the provide pay TfL or TfL pay the supplier?
    • Broad Band service – funded by consumer paying internet provider, but Infrastructure provided by BT.
  • Group Attributes by User, Customer, Supplier
  • How to create Requirements for Services
  • Integration of Services
  • Ownership of equipment used within the service
  • Potential for intelligent procurement
  • Procuring Services – currently using same processes as for procuring equipment


[edit] Comments resulting from review of Workshop Outputs

  • Procuring services needs a different language from procuring systems - currently a lot of focus is on making things leaner, rather than understanding what making them a service actually means.
  • Supply chain needs to be geared to service and use 'Principles of Services'
  • We should validate with stakeholders the check the direction we are going
  • There are issues with defining common international terminology, but which then has National characteristics
  • Service Oriented Architectures have standard defined terminology which has little 'Nationalisation' as its used for implementaion. * Contracts are a particular concern with the same contractual conditions having different implications in the UK, France, Germany, Italy, US, etc. This has been overcome with Software SOAs - where contracts are fully defined and coded in XML or another language. (Similar to digital interfaces having to be fully defined with no 'room for adjustment' unlike physical interfaces which can be adjusted to fit with a hammer!)
  • There are 'Silo' approaches to defining/using services - we need holistic approaches
  • SEBoK has pages on Services and Services Systems Engineers - appears to be partly based on ITIL v3. needs reviewing
  • We could also review ITIL v3 and identify what it covers for Systems Engineering that is useful and what needs adding

[edit] Way Forward

  • Need to feed these inputs into our plan for further work.
  • Need to review the list of potential attributes to see if a grouping of 'areas' of attributes can be found.
  • Need to repeat the services versus attributes scoring exercise to identify further commonality
  • Need to review SEBoK for areas that apply to Services and what needs adjusting and adding

[edit] Product-Service Systems

"Product Service Systems, put simply, are when a firm offers a mix of both products and services, in comparison to the traditional focus on products" (Wikipedia)

From a quick review it looks like these are on the continuum from pure System to pure Service, but towards the System end. ie selling a system with accompanying services as against selling a service and providing the necessary systems as needed to support it.

Further discussion is expected.

[edit] Review of Cambridge Services Alliance Documents

Cambridge Service Alliance have issued a number of study reports. One has identified 76 potential causes of complexity in services, these have been grouped into four groups, which John D has further worked on to produce four potential characteristics related to the source and nature of the complexity:

  • Source of complexity - is either in the needs or requirements - so every solution will be coplex because of this - or its in the solution being presented - in addition to the complxity in the needs.
  • Nature of complexity: this is either in Complicatedness - a large number of heterogenious components linked together; or it is in the Unknowns

This leads to four groups:

  • Complicatedness of the Requirements
  • Complicatedness of the Solution (in addition to that in the Requirements)
  • Unknowns in the Requirements
  • Risks in the Solution

Further work is needed to go through the Cambridge reports and identify which are of interest to this work.

[edit] Work of Core Group members

For the next meeting following will be looked at:

  • Steve A: Plan for the SSE work and what we are doing
  • Peter M: Risk and associated issues
  • Laura M: Review aspects of characterisation
  • Andrew F: Review SEBoK entries – what applies to Services, what needs changing, what is missing.
  • John D: Group characteristics, capture stuff in Wiki, review Cambridge Services Alliance papers for relevance.

[edit] Dates for future meetings:

  • Meeting 6: Phone in – 16 January. 13:00 to 15:00
  • Meeting 7: Face to Face – London. 17 March 2014

Service Systems Engineering Group Wiki

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox