Your SlideShare is downloading. ×
2nd Generation I.T. Service Catalogues
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

2nd Generation I.T. Service Catalogues

901
views

Published on

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 …

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.

Published in: Technology, Business

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
901
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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
  • 6. Service Catalogue in the supplier relation: Enable for the service integrator model Intention | Structure | Bundle | Model | Process | Application IP VPN LAN Data Center LAN Branch Office Customer Desktop SP LAN SP WAN SP LAN SP Application SP Service Integrator Service Broker publish UDDI SOAP XML order query order service delivery Management Interface
  • 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
  • 17. Service taxonomy Intention | Structure | Bundle | Model | Process | Application
  • 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
  • 26. Key Finding 7: Specification details to map Service products and service components are described in detail in specifications. The specifications contain:
    • Product model: specification of functionality, quality, cost, etc.
    • 27. Process model: life cycle, states, workflows (the basis for automation)
    • 28. Resource model: required service components (build rules), personnel (roles), infrastructure
    • 29. Marketing: customer interaction model, presentation
    Intention | Structure | Bundle | Model | Process | Application
  • 30. Reasons for process definition and automation
    • Easing workload from routine tasks
    • 31. Speed-up processes e.g. in provisioning
    • 32. Eliminate error flashpoints
    • 33. Monitor Processes
    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
  • 38. Reference application architecture for IT service providers Intention | Structure | Bundle | Model | Process | Application