ITIL Questions !!!

Lets share all your thoughts on the below.

1. Why do we have Change management in Service Transition and not in Service Operation
when we use change management process daily?
2.Difference between V2 and V3?
3.What are the KPI's of Change Management, Incident Management & Problem
Management(though differ wrt project/process/Clients)
4.How a Change, Incident & Problem interlinked? Give an example
5.Risk indicators of poor Change, Incident & Problem?
6.Do incident number mandatory in an Emergency Change if yes , why ?
&& if proactive there will not be an Incident number , so how to proceed in that case?
7.What is SLA , OLA & UC ?
8.How do you come to know that whether a change has been implemented without a change
record?
9. Do incident cause Problem ? or Problem cause Incident ?
10.What is the role of Change Manager/Change co-ordinator/Change analyst/Change consultant
in implementation plan/tasks though
its built/prepared/owned by implementer ?
Changing = Tranisitioning. Operations = Supporting(Restoring not Changing)
1. Because a change is by it's nature modifying that which the service is provided for / on. So
it can only be a transitional state, as it transitions the environment from one state of service to
another.
1. Too many, some I feel are wrong, but most are clarifications of points, or updates on the
ones in V2 where ambiguity lies. The following link however has a good summation:
http://wiki.en.it-processmaps.com/index.php/Comparison_between_ITIL_V3_and_ITIL_V2__The_Main_Changes
1. The KPIs are WHAT YOU SET. ITIL is a FRAMEWORK you build on to suit your client /
business needs. It is NOT an out of the box turn key solution. If you think it is you are doing it
wrong.
1. An incident may or may not be converted or linked to a problem depending upon the root
cause. if the root cause is known, then a change might be required to rectify the incident /
problem.
1. Risk indicators are continual problems after applications of fixes. But they are also
subjective and depend upon the incident . problem in question, and also what impact the
change has. Risk has to be accounted for WITH impact as well.

1. This question makes no sense to me. Are you asking does an emergency change need an
incident number? If so I would say not always but in best practice is should. You need to know
what triggered the emergency change. For a myriad of reasons. But it could also be done
under a request fulfillment to prevent something causing an incident.
As for proactive, you raise a service request instead of an incident. An incident is a break of
services, to prevent that from happening would require an emergency change under request
fulfillment.

SLA: Service Level Agreement - A fixed agreed level of service to the end user.
OLA: Operational Level Agreement - Peer to peer level agreement to support eachother to
achieve SLAs
UCL Underpinning Contract - an agreement in line with SLAs again, but with 3rd party /
external vendors.
1. Usually something else goes wrong, and you find out AFTER the fact.
1. Both / Neither. An incident may not CAUSE a problem, but it might highlight one. A problem
may cause an incident to occur, due to the underlying root cause.
10. To ensure that the risk and danger to the environment and balanced against the need for
the change to be implemented, and that the change is an improvement to the environment and
adds rather than subtracts from the environment.