Just plain wrong

When does CSI begin? P.22

Submitted by tim.malone on Mon, 2009-08-17 23:54

In section 2.4.9, the first paragraph on page 22 states "An IT organization does need to wait until a service or service management process is transitioned into the operation area to begin identifying improvement opportunities".

Obviously plain wrong and contradicted by the rest of CSI and common sense.

SO 4.2 Incident Management process never determines the service

Submitted by skeptic on Mon, 2009-08-10 07:00

[corrected:] At no point in section 4.2, Incident Management, is determing the service ever mentioned. in fact services in general are hardly ever mentioned, other than refering to SLAs (for details see comment below).

Not even in incident categorisation or prioritisation or any activity. There is no mention of service impact analysis.

The CMS is only accessed to 'identify the CIs affected' and get 'relationships between CIs'. The Service Catalogue apparently doesn't exist.

ST p76 Table 4.7 Nonsense RACI chart

Submitted by avallesalas on Fri, 2009-03-13 09:31

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

Submitted by avallesalas on Fri, 2009-03-13 09:09

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

Problem management process graph is wrong

Submitted by mbuzina on Thu, 2009-03-05 12:57

Page 60 of SO shows the problem management process as a flow chart. The decision "Workaround" has one single exit, which is not labeled. It directly points to "Create Known Error Record". There is no prerequisite for a known error to have a workaround (known error means we know the cause!).

Additionally there is an arrow coming up from resolution back to "Investigation & Diagnosis" and "Workaround?" (it could be that it also points to "Create Known Error Record", since the graph is very ambigous).

SD p101: MTBF

Submitted by HAZET on Fri, 2008-07-25 14:54

Not considering that there is quite a lot of discussion about the usage of the acronyms MTBF, MTTF, MTRS and so on, this is simply wrong (or at least inconsistant):

MTBSI = Available time in hours / Number of breaks
MTBF = (Available time in hours - Total downtime in hours) / Number of breaks

Available time to my understanding is the time the service is up and running properly. Some people call it "uptime", though that is easily confused with the moment in time the service comes up. So it should be:

Available time in hours = uptime = Total time - downtime

Hence:

definition of incident

Submitted by aroos on Fri, 2008-03-14 06:53

SO book describes incident in a strange manner. The definition is incorrect and contains a short description of the process as well. The process description contain also events. It looks like the author did not know or understand what the V2 definition of incident is and forgot to edit the definition.

The box on page 46 states:

In ITIL terminology, an ‘incident’ is defined as:
An unplanned interruption to an IT service or
reduction in the quality of an IT service. Failure of a
configuration item that has not yet impacted service

SO p58, p61 ‘unknown’ deleted

Submitted by skeptic on Wed, 2008-03-12 10:32

58
In first sentence of section 4.4, ‘unknown’ deleted
61
In first bullet point of 4.4.5.1 ‘an unknown cause’ changed to ‘a cause’

SD p291 Glossary: Brainstorming

Submitted by skeptic on Wed, 2008-03-12 09:54

Under the glossaery definition for ‘Brainstorming’ change the words ‘Service Operation’ to ‘Service Design’

SD p214 ‘Service Transition Pack’ changed to ‘Service Design Pack’

Submitted by skeptic on Wed, 2008-03-12 09:50

214
8.5.1 Prerequisities for success
In left hand column, 4th line from bottom, ‘Service Transition Pack’ changed to ‘Service Design Pack’
214
8.5.2 Critical Success Factors…
In penultimate bullet point on page, ‘Service Transition Pack’ changed to ‘Service Design Pack’

Syndicate content