IT service engineering – our term for the systematic approach to developing IT services – is fast becoming a core competence of IT service providers. The reason is simple enough: professionally engineered service products are the only ones which stand a chance on the market and can win the acceptance of consumers. The challenge of IT service engineering is to specify IT services such that consumers and providers all have a clear understanding of what the services actually comprise.
Repurposing LNG terminals for Hydrogen Ammonia: Feasibility and Cost Saving
2nd Generation I.T. Service Catalogues
1. Intention | Structure | Bundle | Model | Process | Application 2 nd Generation I.T. Service Catalogues Workshop September 9 th , 2005
2. The five stages of evolution in the Service Provider Maturity Model (SPMM) Intention | Structure | Bundle | Model | Process | Application
3. Service Catalogue in the customer relation: A sales tool Intention | Structure | Bundle | Model | Process | Application Service Value Chain Suppliers Service Provider Customers For internal use : The Service Catalogue is the service provider's product data management . Employees know how to provide a service , what is included and the quality thresholds . Processes can be automated and/ or monitored . Optimized resource utilization . In the supplier relationship : Well specified services allow the service provider to plan and calculate with the suppliers offerings and resources . In the customer relationship : The functionality , quality and provisioning times of services can be communicated . It is assured that services are deliverable in the specified way. Customers know how they can configure the services .
4. Service Catalogue for internal use: The Product Data Management (PDM) Intention | Structure | Bundle | Model | Process | Application
5. Key Finding 1: Product Data Management A second-generation service catalogue takes the description of services one step further, complementing the customer-centric presentation of services with an internal provider view. What the catalogue does is create a knowledge base about the service, and assemble the available information in a single source. The service catalogue is the IT service provider’s PDM – Product Data Management. Intention | Structure | Bundle | Model | Process | Application
9. Plattform Strategies have been implemented successfully in the automotive industry Intention | Structure | Bundle | Model | Process | Application
10. Key Finding 2: Products and components Component-based service architectures mandate a differentiation between service products and service components. Accordingly, there are two catalogues: a product catalogue and a component catalogue. Intention | Structure | Bundle | Model | Process | Application
11. Decomposing IT services is the equivalent of breaking down goods into constituent parts Intention | Structure | Bundle | Model | Process | Application
12. Example illustrating how the IT service “workspace” is decomposed Intention | Structure | Bundle | Model | Process | Application
13. Key Finding 3: Characteristics of service components Service components should have as limited a scope as possible to keep them easily manageable. They can be iteratively decomposed (broken down) or composed (built). Finer granularity increases the likelihood of component reusability. IT service providers typically have several hundred service components. Intention | Structure | Bundle | Model | Process | Application
14. Decompose existing products Intention | Structure | Bundle | Model | Process | Application Product 1 Component Candidate Product 2 Component Candidate Service Component 1
15. Eliminate doubles, define variants and associate components to precombined classes Intention | Structure | Bundle | Model | Process | Application Product 1 Component Candidate Product 2 Component Candidate Service Component 1 Service Component Service Component Service Component 2
16. Abstract superclasses to refine taxonomy Intention | Structure | Bundle | Model | Process | Application Product 1 Component Candidate Product 2 Component Candidate Service Component 1 Service Component Service Component Service Component 2 Service Component Service Component 3 Service Component Service Component Service Component Service Component Service Component
18. Key Finding 4: Service taxonomy Service components can be arranged in a hierarchy of classes, in accordance with the principles of object orientation. A service taxonomy of this nature promotes standardisation and simplifies modelling through its inheritance mechanisms. It also acts as vehicle for semantic knowledge. Intention | Structure | Bundle | Model | Process | Application
19. The iterative composition of the “Workspace” service product Intention | Structure | Bundle | Model | Process | Application
20. Key Finding 5: Characteristics of service products Service products are sold to clients; they are comprehensive, valuable service packages. The number of service products should be limited so as not to overburden the customer with choice. Service products should permit or comprise variations so as to address individual demand profiles. Service providers can also differentiate from other market players by their design of service products. Intention | Structure | Bundle | Model | Process | Application
21. Dimensions explored when modelling IT service components Intention | Structure | Bundle | Model | Process | Application
22. Service Engineering vs. Configuration Management Intention | Structure | Bundle | Model | Process | Application Service Engineering is the process by which the provider develops marketable services, thus defining his or her own potential. This data is also known as “potential data”. Configuration Management, on the other hand, is about managing the assets – inventory, or customer relationships – which currently exist and constitute a value. This data is termed the “asset data”.
23. IT service providers are only now beginning to specify their potential in service catalogues Intention | Structure | Bundle | Model | Process | Application
24. The two differentiations create a matrix that defines four object types Intention | Structure | Bundle | Model | Process | Application Service Product Service Component Specification Instance Service Product Specification Service Order Service Component Specification Service Instance
25. Key Finding 6: Specifications and instances It is necessary to differentiate between a specification and an instance of this specification on both the product and component levels. A single instance of the specification of a service product is an order (or rather service configuration); a single instance of the specification of a service component is known as a service instance. Intention | Structure | Bundle | Model | Process | Application
34. Specifications have these life cycle states Intention | Structure | Bundle | Model | Process | Application
35. State transitions of specifications Intention | Structure | Bundle | Model | Process | Application Life cycle Version 1.1.17 DV Version 1.2.3 AC Version 1.2.5 EL Version 2.0.8 AC Version 1.6.1 PO Version 1.5.5 DV Version 1.99.45 DV Version 1.2.4 PO Version 1.6.0 AC
36. State model of instances Intention | Structure | Bundle | Model | Process | Application
37. State model of instances Intention | Structure | Bundle | Model | Process | Application Initial Configured Ready Available Cancelled Degrading Degraded Unavailable Workspace Service Product Desktop Computer Office Communications User Support Email Telephone Network Email Telephone Network Work Order Desktop Computer Office Communications User Support Workspace Service Product
