SPACL Version 1.0 Documents Ready for Review

Replies to This Discussion

Permalink Reply by Rodrigo Flores on December 17, 2009 at 1:55pm

After you read them, please let us know your feedback on the object and attributes model, what you like, what could be better.

• ▶ Reply

Permalink Reply by Paul G. Huppertz on December 19, 2009 at 2:14am

SPACL_White_Paper_1.0.pdf, Extract:
"WHAT IS A SERVICE CATALOG? SERVICE PORTFOLIOS, CATALOGUE AND ITIL V3
The service catalogue is an expression of the operational capability of a service provider within the context of a customer or a market space."

From my perspective, the service catalogue expresses and repesents the service provider's capability to commit and to deliver the specified ICT-based Business Support Services (ICTBSS) to service consumers in the business unit of the enterprise, which is more precise than "operational capability". Accordingly, the service catalogue must only contain the service offerings of the accountable service provider, i.e. the clear, complete and concise specifications of the ICT-based Business Support Services (ICTBSS) whose delivery can be commissioned from this accountable service provider by service customers for a particular group of service consumers in his area. Each ICTBSS must be specified with its 12 service attributes and appropriate basic attribute values, usually with three different sets of basic attribute values which represent three different service levels.
s. http://en.wikipedia.org/wiki/Service_(economics)#Service_specification

• ▶ Reply

Permalink Reply by Paul G. Huppertz on December 19, 2009 at 2:58am

I'd like to introduce, propose and discuss a rather lean structure of the service catalogue based on the clear, complete and concise service specification with the 12 standard service attributes
s. http://en.wikipedia.org/wiki/Service_(economics)#Service_specification
This approach leads to the comments below marked with [PGH] .... [PGH/]

SPACL_White_Paper_1.0.pdf, Extract:
"The service catalogue:
• Acts as the ordering portal for customers, including pricing and service-level commitments, and
the terms and conditions for service provisioning. Users select service offerings from the service
catalogue and generate service requests to have instances of those offerings fulfilled."
[PGH]
Each service specification of an ICT-based Business Support Service with the 12 standard service attributes contains

- the service delivering price in attribute 12 which specifies the amount of money the service customer has to pay for the distinct service volumes his authorized service consumers have consumed. Normally, the service delivering price comprises two portions
1. a fixed basic price portion for basic efforts and resources which provide accessibility and usability of the service delivery functions, i.e. service access price
2. a price portion covering the service consumption based on
## either fixed flat rate price per authorized service consumer and delivery period without regard on the consumed service volumes,
## or staged prices depending on consumed service volumes,
## fixed price per particularly consumed service delivering unit.

- three different sets of the 12 attributes with distinct attribute values representing one service level (profile) each
[PGH/]

"• Consists of services presently active in the service operations phase and those approved to be
readily offered to current prospective IT Organizations."
[PGH]
The service catalogue should - as any other catalogue - only contain the service offerings, i.e. the specifications of the ICT-based Business Support Services which have been approved to be offered. The delivery of such services is committed separately in the signed Service Level Agreements and not in the service catalogue.
[PGH/]

"• Is useful in developing suitable solutions for customers from one or more services."
[PGH]
New(ly required) ICT-based Business Support Services must be worked out based on the service specification with the 12 standard service attributes in tight cooperation between the accountable service provider and the service consumers of the respective business unit, attended by the service customer who wants to commission the service for these customers. As soon as the specification is worked out and accepted by every party, it must be integrated into the service catalogue. Accordingly, new services must be developed outside of the service catalogue.
[PGH/]

"• Contains items that can be configured and suitably priced to fulfill a particular need."
[PGH]
Each service specification starts with the standard service attribute 01 'service consumer benefits' describing the (set of) benefits which are triggerable, receivable, consumable and effectively utilizable for any authorized service consumer and which are rendered to him as soon as he explicitly triggers a service. The description of these benefits must be phrased in the terms and wording of the intended service consumers. The attributes 02 to 11 specify all other qualities of the service and the service delivery so that in attribut 12 'service delivery price' the appropriate price can be and must be determined.
[PGH/]

"• Contains requestable services"
[PGH]
According to the comments above, the service catalogue only contains commitable ICT-based Business Support Services, i.e. clear, complete and concise service specifications with basic attribute values which are copied to the SLA template to be commissioned from the accountable service provider. As soon as the SLA is signed and in effect, the authorized service consumers namely listed in the appendix of the SLA are allowed to trigger such services which thereupon must be rendered explicitly to the respective triggering service consumer.
[PGH/]

• ▶ Reply

Permalink Reply by Paul G. Huppertz on December 19, 2009 at 5:11am

SPACL_White_Paper_1.0.pdf, Extract:
"Service providers may have many customers or serve many businesses and therefore there may be multiple service catalogues projected from a service portfolio."

In order to be clear with roles, liabilities and competencies in the service delivery (model): There must be only one accountalbe internal service provider in the enterprise, i.e. one organizational unit which is generally accountable for (make) delivering all required ICT-based Business Support Services (ICTBSS) to the service consumers, i.e. employees in the business units. This organizational unit may mandate other internal organizational units with delivering distinct service contributions for the required ICTBSS; the latter units are internal service suppliers, e.g. internal teams, groups or departments. It is paramount to keep with this pivotal role of the internal accountable service provider, because this organisational unit is the reference point for anything regarding service delivery, i.e.
- deducting the appropriate service delivering strategy from the business strategy
- deducting the appropriate ICT strategy from the determined service delivering strategy
- specifying and cataloguing the offered ICT-based Business Support Services
- committing the delivery of ICTBSS to authorized service consumers by means of SLAs
- working out service concepts with service map and service screenplays
- conceiving the necessary service supply chains based on the service concept
- commissioning internal & external service suppliers with delivering specific service contributions
- achieving and keeping service delivery readiness according to the closed SLAs
- assuring sufficient service delivery capacity matching the upcoming service demand
- orchestrating and conducting all internal & external service suppliers in the context of the service supply chains
- delivering each & every triggered ICTBSS explicitly to the triggering service consumer in the business unit
- billing the volumes of ICTBSS rendered to the triggering service consumers according to the service specifications in the respective SLAs

Conclusion:
There should be only one (Enterprise) Service Catalogue (ESC) containing the specifications of all ICT-based Business Support Services (ICTBSS) relevant to the service consumers in the business units. Each ICTBSS must be clearly, completely and consistently specified with its 12 specific service attributes and 3 sets of appropriate attribute values, i.e. three service levels, which can be completed on 2 pages. The different service customers commission the required ICTBSS for their service consumers by means of SLAs which contain as nucleus the specification of the required ICTBSS.
The service portfolio contains all ICTBSS offered in the current service catalogue plus some further drafted service specifications planned for future offerings.

• ▶ Reply

Permalink Reply by Carlos José Maia Teixeira on December 20, 2009 at 9:06pm

Dears Rajesh and Rodrigo,

This complementary view describing the Object Model, it´s very useful to clear the concepts around the IT services. It´s very commom to see and heard from consultants and vendors definitions very confused about LoS (Line of Services), Service Bundle, Business Services, Technical Services and Service Requests, and i expect and wish that SPACL can cover these issues, as well.

However, it would be better if the SPACL specification scope expands to all aspects related Service Life-cycle, wich reflects in to the Service Portfolio and Catalogue. By the way, follows some suggestions to the model:
- Connections with the models and attributes of CMDB DMTF;
- Involving more concepts related to Service Portfolio Management (I could not see the other concepts, except the Service Catalog), and
- Reinforce the concepts related to "Warranty", specially the others technical services dependency and OLA/contract targets and performance.

I´m aware that is the 1st SPACL Specification version and several others suggestions and changes will applied to this standard, but i feel that the current documents bring to the all Service Management Community a precious contribution.

Congratulations to all team!

Best Regards,

Carlos Teixeira

• ▶ Reply

Permalink Reply by Peter Brooks on January 5, 2010 at 11:16pm

I think this is excellent stuff!

I understand that request fulfilment is out of scope - that makes complete sense.

What I think it would be useful, though, to add would be a little workflow at the service request level. This could, of course, be part of the extensions, but I think it is pretty fundamental.

What I'd see as adding the most value to the service request at the moment would be:

Versions: Service Version, Service Request Version [to allow some options for negotiation, and keep a log]

Status: to track a service request and allow metrics. Sub-status can track it through implementation, but surely a service request should allow things like 'initial_request', 'receipt_confirmation','ordered','rejected','delivered','aborted','closed'?

More dates [to track status above] submissiondate and requesteddeliverdate are important, but, agreeddeliverydate, actualdeliverydate, servicestartdate, serviceenddate and servicreviewdate are dates that also seem fundamentally important to me.

Is it worth adopting, or adapting, some of the work done on EDI? X.12, EDIFACT, that sort of thing?

I'm just thinking that the ordering-invoicing-delivery cycle is pretty well explored and well known, to adopt a working standard to carry Service Requests, or produce a stripped-down one, would make sense - but why re-invent the wheel?

That would then leave SPACL to concentrate on the important things that differentiate a service from other products - which you have nicely defined, Warranty and so forth..

Just one question of detail. Is the 'urgencylevel' set by the customer or the provider? Should it be part of the service request itself, or is it actually part of the warranty?

• ▶ Reply

Permalink Reply by Rodrigo Flores on January 7, 2010 at 5:17pm

Thank you for the feedback thus far. The group will be meeting next week and we'll begin to respond faster.

• ▶ Reply

▶ Reply to Discussion