Service Portfolio and Catalog Language

Public review site for SPACL documents.

In the glossaries of ITIL V2 books, you'll find the definition:
"Service: One or my IT systems that enable a business process."
This suggests that a service is an IT system and viceversa which is hardly reasonable, in particular as it does not consider in any way the rather unruly and intricate service characteristics
s. http://en.wikipedia.org/wiki/Service_(economics)#Service_characteristics
s. http://www.learnmarketing.net/servicemarketing.htm
s. http://busfac32.cob.calpoly.edu/presentations/Sharon_Dobson/Ch08.ppt
In fact, a service is a set of singular and perishable benefits
- delivered from the accountable service provider, mostly in close coaction with his service suppliers,
- generated by functions of technical systems and/or by distinct activities of individuals, respectively,
- commissioned according to the needs of his service consumers by the service customer from the accountable service provider,
- rendered individually to an authorized service consumer at his/her dedicated trigger,
- and, finally, consumed and utilized by the triggering service consumer for executing and/or supporting his/her current day-to-day business task or private activity
http://en.wikipedia.org/wiki/Service_(economics)#Service_specification
Each service can be clearly, completely and concisely specified by means of the 12 standard service attributes and appropriate attribute values.
s. http://en.wikipedia.org/wiki/Service_(economics)#Service_specification

Views: 323

Reply to This

Replies to This Discussion

I agree with your understanding. A system may support the delivery of service to a customer, but isn't necessary to deliver. A system helps to automate and to drive efficiencies. A human or personal interaction with the customer may increase the perception of the quality and personality of the delivered service. So both may be necessary to deliver the service - but aren't the service.
Based on the service specification, it must be determined which systems will deliver which service contributions for the triggered service. Such service contributions are effectuated by executing particular functions of the service-relevant system. E.g. hitting the send button in an e-mail client software triggers (the delivery of) an e-mail service. An e-mail service is delivered when one copy of the original e-mail is delivered to the e-mailbox of each intended addressee. This means that there are particular service-relevant functions of the service-relevant systems which must be executed to trigger a service or to effectuate a service contribution. Neither the service-relevant function itself nor the service-relevant system itself is the service (contribution). The service (contribution) is a set of benefits which is effectuated by executing specific service-relevant functions.
Paul,
Again, my complete reply on your suggestion of twelve attributes is in this thread here.

Our job with SPACL is reduce ambiguity and the create data structures that can be interchanged between systems and parties. So my question is: does system need to be part of ServiceOffering or Requestable service?
If not, why not?
If yes, why yes and what data structure should be modeled.
Rodrigo Flores said:
Paul,
Again, my complete reply on your suggestion of twelve attributes is in this thread here.

Our job with SPACL is reduce ambiguity and the create data structures that can be interchanged between systems and parties. So my question is: does system need to be part of ServiceOffering or Requestable service?
If not, why not?
If yes, why yes and what data structure should be modeled.

Any service offering can be completely, consistently & concisely specified by means of the 12 standard service attributes which are explained in detail in the following Wikipedia entry
s. http://en.wikipedia.org/wiki/Service_(economics)#Service_specification
01 Service Consumer Benefits
02 Service-specific Functional Parameters
03 Service Delivery Point
04 Service Consumer Count
05 Service Readiness Times
06 Service Support Times
07 Service Support Languages
08 Service Fulfillment Target
09 Maximum Impairment Duration per Incident
10 Service Delivering Duration
11 Service Delivery Unit
12 Service Delivering Price
This specification allows for the rather fractious service characteristics and the gaps of service quality identified in the ServQual model
s. http://en.wikipedia.org/wiki/Service_(economics)#Service_characteristics
s. http://www.12manage.com/methods_zeithaml_servqual.html

If any ICT asset must be explicitly denominated, this can be done in standard service attribute 02 'Service-specific functional attributes' in a subparameter which names the required asset and its version, e.g. SAP/ECC V6.0. Furthermore, the service-relevant systems are integrated when the service concept is worked out which contains
- the specification of the offered ICT-based Business Support Service (ICTBSS)
- the service map with all the required service contributions
- the service screenplay listing the sequence of service contributions which are aggregated into the ICTBSS

Conclusion:
Mainly, the service-relevant ICT systems and/or assets are at most referred to in service attribute 02 'Service-specific functional parameters' and the systems and/or assets themselves are described and doucmented in the CMDB or CMS.
Just in case someone wants to doublecheck the referenced groundbreaking misconcepting in ITIL, please find attached the 'systemized' version of the ITIL V3 volume 'Service Design'. 'Systemized' means that in the original text of the volume, being on hand in Word format, only the term 'service' has been exchanged with the term 'system', which is still marked and trackable.
Looking forward to read your feedback and opinion about this.
Best regards and best terms.
Paul G. Huppertz
Attachments:

Reply to Discussion

RSS

© 2012   Created by Rodrigo Flores.   Powered by .

Badges  |  Report an Issue  |  Terms of Service