So i discussed this with a friend and this is what he had to say --
In Service Strategy, one defines the market, decides what service to provide, assign resources to build this service. This forms the initial documentation of a service in the service portfolio. And this is Service Portfolio Management.
And it is in Service Design, the service takes some shape, the Service Requirements are understood, Operational requirements are defined, etc.
So all these details are then updated in the Service Catalog in the Service Design phase
Now we argued, once, more details are known about a service (say for example in the Service Transition r Operations phase), the Service catalog should be updated, so why can't this update (to service catalog) happen in the Startegy Phase or in pther phases, we think, becasue Strategy deals with strategy and not tactical activities, and to ensure the Catalog is not updated without thorough analysis by the Catalog Manager, it is best to keep the review and update of Service Catalog in the Service Design phase
For example, a Service SIP introduces some changes to the Service and its offerings, then CSI phase naturally feeds data into Service Design (to make changes to Service), and in process Service catalog is updated in Svc Design
Kinda fuzzy i know...but kinda makes sense too.
what do you think?
Joined: Mar 04, 2008 Posts: 1884 Location: Newcastle-under-Lyme
Posted: Mon Mar 19, 2012 8:08 pm Post subject:
If I read my (free) Introductory Overview of ITIL V£ correctly, things will become much clearer when you stop thinking in terms of phases.
Service portfolio management, service catalogue management, along with other processes identified in the Service Strategy and Service Design volumes, are ongoing activities throughout the life of service provision. there inclusion in the particular volumes merely indicates that that is the strategic layer at which they have to be conceived and driven from.
I could be wrong in all this, and I am beginning to realize that I have seen several other threads, here and elsewhere, that suggest a cruder interpretation. Nevertheless it seems to me that the best way to understand these books is, as was intended at least with the original ITIL, to regard them as descriptive of what needs to be done and to be classifying the description rather than as a template of how to do it. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum