The IT Skeptic - Service Transition

ST p76 Table 4.7 Nonsense RACI chart

avallesalas — Fri, 13 Mar 2009 09:31:40 +0000

4.3.5.3 Table 4.7 in Service Transition shows a RACI chart.

Roles (columns) are the five stages of the lifecycle (hum... a stage can be a role? though that roles are owned by humans)

Activities (rows) are *again* lifecycle stages

So you can find easily that the Operations stage is responsible for the Design stage (second row) and that surprisingly, the Continual Improvement stage has... 4 accountables (breaking the sacred law)

The authors wanted to transmit a message here, but used the wrong tool.

ST p69 Wrong hierarchy in the CMS

avallesalas — Fri, 13 Mar 2009 09:09:31 +0000

4.3.4.3 The figure 4.8 shows an example of CMS structure.
In previous paragraph, it states that

"Figure 4.8 shows how the CMS covers the data and information layers of the knowledge/information/knowledge hierarchy explained in section 4.7, KnowledgeManagement."

But in fact the hierarchy shown is Knowledge/Information/Data

Release management also defines release policy

aroos — Sat, 15 Mar 2008 07:58:47 +0000

Transition planning defines release policy [ST 4.1.4.2 p 36], which makes sense. Release management [ST 4.4 p84] also defines release policy which makes less sense.

the new name for Configuration Management, SACM

aroos — Sat, 15 Mar 2008 07:56:13 +0000

the new name for Configuration Management, SACM appears only in the process itself. Not even the authors of other chapters in the same book are aware of the name change.

ST p90 Figure 4.20

skeptic — Wed, 12 Mar 2008 10:00:00 +0000

‘Assume deployment …’ changed to ‘Assure deployment …’

ST p223 CAB/EC to ECAB

vinodka — Tue, 20 Nov 2007 16:59:14 +0000

The 'not-so-obvious' V2 abbreviation of CAB/EC (CAB Emergency committee) for the subset of CAB taking decisions on emergency changes is changed to EmergencyCAB or ECAB. No objections to that.

Note: Even I saw a question on this in the foundation paper regarding who authorizes emergency changes - where both the options were given!! If you missed this change in V3, you (I mean V2 aware people) can rest assured that you lost one mark!

Now about the inconsistency:

ST p59 Renaming FSC to CS then referred to as SC

mbuzina — Thu, 30 Aug 2007 08:39:00 +0000

Page 58 (Change Management Process) tells us that Change Management is responsible for generating the change schedule, which is explained can be abbreviated CS (all of this sounds pretty logical. Why we had to rename FSC to CS though, I will leave to the SWAMI to predict).

But:

ST Service V-model figure 4.21 and 4.30 confusing

skeptic — Fri, 27 Jul 2007 01:41:59 +0000

ST Service V-model figure 4.21 p92 and 4.30 p124
"the confusion lies in the steps that have to be followed on the V model. My opinion is that it is down the left hand side and back up the right hand side. The confusion comes from the number on the picture. 1a on the left, 1b on the right, 2a on the left, 2b on the right... there is absoultely no text to explain the direction of travel and perhaps the authors assumed that everyone would automatically know.
However, by adding connecting arrows and the numbering system used all it has done has caused confusion and (sometimes heated) debate."

super pedantic: no "G" in green-field

skeptic — Wed, 11 Jul 2007 05:35:05 +0000

ST start of chapter 8, p 199.
Who is "Greenfield"? presumably this means "green field"

typo "form" for "from"

skeptic — Wed, 11 Jul 2007 05:30:03 +0000

ST 8.1.3 p201 There is a typo: for "form" read "from"

ST p200 SCM or CMS?

skeptic — Wed, 11 Jul 2007 05:27:28 +0000

ST 8.1.2.3 p200 Heading "SCM and Service Knowledge Management System". Is "SCM" referring to Capacity, or is it a typo which should be "CMS" configuration mgmt system which would make sense?

The purpose of SACM

skeptic — Mon, 09 Jul 2007 09:31:49 +0000

ST 4.3.1 p65
"The purpose of SACM is to: ..."

I must eb thick because I've read those four purposes over and over, and they sound like they are all the same one to me. I guess it is "purpose" singular but why the four bullets? Especially the last three would seem to be entirely redundant

automated change ?

skeptic — Tue, 26 Jun 2007 07:38:16 +0000

automated change gets no mention, yet in this era of Web Services, grid computing and so on, ITIL needs to be ready for dynamically self-healing and self-reconfiguring systems. the only human intervention will be after-the-fact approval so someone knows what happened.

ST Figure 4.20 typo "assume" means "assure"

skeptic — Mon, 25 Jun 2007 22:14:23 +0000

ST Figure 4.20 typo "assume deployment of service package or release" means "assure..."

[from http://www.best-management-practice.com/changeLog/maintainIssue.aspx?ID=4 ]

ST does not specify services in definition of CMS technical requirements

skeptic — Mon, 25 Jun 2007 22:02:03 +0000

Page 195, section 7.3 Technical COnsiderations for CMS:

Nowhere does this part of the book specify or remind us that a service or other logical entity is a CI and therefore has to be stored and mapped in order to support catalogue, incident impact, root cause, chage impact, SLA analysis and reporting or any of the other essential activiites of ITIL.

instead the descriptions are entirely technical which is going to allow the vendors to pass off network mapping tools and asset discoverers as CMS.

Event generating a change ?

pfranck — Mon, 25 Jun 2007 12:52:08 +0000

In Service Operation, page 38, figure 4.1 mentions an event can generate a change. Same is explained again in 4.1.5.7 where an event triggers a change. But there is no mention of a change triggered by an event in Service Transition.

paragraph 2.4.3 should be the value of the volume to the business

PELIJN — Mon, 25 Jun 2007 00:07:49 +0000

chapter 2 in each book should describe it from a volume perspective: Therefor paragraph 2.4.3 should be the value of the volume to the business... (see service design). In SO it is a generic value to the business. In SS it does not have the value to the business described. Better alignment between these values would be beneficial.

All books 2.2.1 repeats service definition

skeptic — Sun, 24 Jun 2007 21:41:03 +0000

pure pedantry:

Chapter 2 is in all books (though with very subtle editorial differences).

2.2.1 the text at the start in a box defining a service is almost identical with the following paragraph - should have been edited?

SO regards KEDB as distinct from CMS, ST does not

skeptic — Fri, 22 Jun 2007 02:16:49 +0000

SO p66 "the KEDB, like the CMS, forms part of a larger... SKMS" Clearly distinct.

ST p 68 "The CMS maintains... any related ... known errors". included.

NB there appears to be no mention of KEDB in ST?

Figure 4.8 in Service Transition and Figure 4.6 in Service Operation

pfranck — Thu, 21 Jun 2007 21:57:10 +0000

Figure 4.8 in Service Transition and Figure 4.6 in Service Operation are both exactly the same, but one is a representation of a CMS, the other a representation of a SKMS if you read the subtitles.