For each process, COBIT defines a list of inputs the process should receive from other processes and a list of possible outputs to send to other processes. For example process PO1—define a strategic IT plan (Figure 11), should receive a cost/benefits report from process PO5—manage the IT investment. The process PO1 itself should send strategic and tactical IT plans to several other processes.
RACI.Diagram
COBIT defines for each process a RACI diagram, where the role and re- sponsibilities related to important process activities are identified. RACI stands for:
• Responsible: Who is responsible for the activity
• Accountable: Who is accountable for the activity, meaning who provides
direction and authorises the activity (is typically hierarchically higher than responsible)
• Consulted: Who should be consulted for the activity
• Informed: Who must be informed about the activity
For the example process PO1—define a strategic IT plan, it seems that es- pecially the business executives together with the CIO are responsible for linking business goals to IT goals (Figure 12).
Goals.and.Metrics
For each of the 34 IT processes, COBIT defines goals on three levels (see Figure 13). IT goals are located at the level of the IT department, the highest level within COBIT for defining goals (the business goals are not retained because they are often very similar to the IT goals). On a second level, process goals are defined for the IT process itself and fall under the responsibilities of the process owner. And finally activity goals are identified on the level of activities defined within the process. Clearly, achieving activity goals must support the achievement of process goals, which in turn must support the achievement of IT goals.
In order to monitor all these goals, metrics are defined for each of them. It is important to note there are two distinct metrics: key goal indicators and key performance indicators.
Key goal indicators (outcome measures in balanced scorecard terminology) are known as lag indicators and they measure the achievement of the defined goals. Two levels of key goal indicators (KGIs) are known within COBIT:
Figure 12. Roles and responsibilities (RACI diagram) for PO1: Define a strategic IT plan (ITGI, 2005)
KGIs for measuring the IT goals and KGIs for measuring the IT process goals. As an example, for process DS5—ensure system security (see Figure 14) one of the IT process goals is defined as “permit access to critical and sensitive
data only to authorised users” and a possible KGI to measure this process
goal is “number and type of suspected and actual access violations.”
Figure 13. COBIT 4.0 goals and metrics overview
IT goals Process goals Activity goals Activity
KGI Process KGI IT KGI
Figure 14. Goals and metrics for the process DS5: Ensure system security (ITGI, 2005)
Key performance indicators (key performance drivers in the balanced scorecard terminology) are known as lead indicators, and they measure the effective- ness of the process execution. The key performance indictors (KPIs) define measures that determine how well the IT process is performing in enabling the goal to be reached. This means there is an important causal relationship between KGIs and KPIs. In previous example the KGI “number and type of
suspected and actual access violations” was identified on IT process level
for the IT process goal “permit access to critical and sensitive data only to
authorised users.” In order to reach this goal, several activity goals must be
executed, such as “managing user identities and authorisation in a stan-
dardised manner” (Figure 14). This goal can be measured by a KGI on activity
level, which also represents a KPI on IT process level, such as “number and
type of obsolete accounts.” It is assumed that a lower score for this metric
implicates a better indication for reaching the IT process goal.
Figure 15. Cascade of metrics
IT process level
IT / COBIT Process DS5: Ensure System Security
number of incidents damaging reputation
with the public
Index of reputation of the
organisation
KGI
number and type of suspected and actual
access violations
KPI
number and type of obsolete accounts. IT level Business level KPI KPI KGI KGI COBIT Beyond COBIT
It is important to note that a KGI on one level becomes a KPI on a higher level, as illustrated in Figure 15. For example, on IT process level number
and type of suspected and actual access violations was defined as KGI for
the IT process goal. This is an important activity in supporting the IT goal
ensure critical and confidential information is withheld from those who should not have access to it, which in turn is measured by the IT level KGI number of incidents damaging reputation with the public (Figures 14 and 15). This
means, on IT level that the IT process KGI number and type of suspected
and actual access violations now becomes a KPI, which is operating as a
lead indicator for the IT KGI number of incidents damaging reputation with
the public. Next, this KGI can become a KPI for a business level goal like
for example the organisation’s reputation, measured reputation index of the
organisation. In COBIT, metrics on business level are not included. The
COBIT management guidelines only deliver IT related goals and metrics, but as mentioned previously, guidance is provided on how IT processes and IT goals can support the business goals (Figures 2 and 3).
COBIT.Maturity.Models
A maturity model can be seen as a scoring technique for organisations to assess the maturity level of a specific process between 0 (not existent) and 5 (optimised). This instrument offers a comprehensible method for identifying the current (as-is) situation against the desirable (to-be) situation. Addition- ally, the organisation can compare its situation against industry specific best practices and standards. Gaps between the “as-is” and the “to-be” situation can be identified and specific actions to evolve towards the desirable situation can be set up. Whenever the maturity level of a process is being analysed, it is important to apply the base principles of a maturity measurement: an organisation can only evolve to a next maturity level, whenever all the criteria of that level are fulfilled.
The maturity levels of the process DS1—define and manage service levels, are listed in Figure 16. If an organisation reaches level 1 for this process, it is aware of the need to manage service levels, but the process is still informal. When the organisation reaches maturity level 5, all defined service levels are continuously monitored and reviewed in order to guarantee an optimal alignment between business and IT objectives.
Figure 16. Maturity model for the process DS1: Define and manage service levels (ITGI, 2005)
0.Non-existent.when
Management has not recognised the need for a process for defining service levels. Accountabilities and responsibilities for monitoring them are not assigned.
1.Initial/.Ad.Hoc.when
There is awareness of the need to manage service levels, but the process is informal and reactive. The responsibility and accountability for defining and managing services are not defined. If per- formance measurements exist, they are qualitative only with imprecisely defined goals. Reporting is informal, infrequent and inconsistent.
2.Repeatable.but.Intuitive.when
There are agreed-upon service levels, but they are informal and not reviewed. Service level re- porting is incomplete and may be irrelevant or misleading for customers. Service level reporting is dependent on the skills and initiative of individual managers. A service level co-ordinator is appointed with defined responsibilities, but limited authority. If a process for compliance to service level agreements exists, it is voluntary and not enforced.
3 Defined Process when
Responsibilities are well defined, but with discretionary authority. The service level agreement development process is in place with checkpoints for reassessing service levels and customer sat- isfaction. Services and service levels are defined, documented and agreed-upon using a standard process. Service level shortfalls are identified, but procedures on how to resolve shortfalls are informal. There is a clear linkage between expected service level achievement and the funding provided. Service levels are agreed to but they may not address business needs.
4.Managed.and.Measurable.when
Service levels are increasingly defined in the system requirements definition phase and incorpo- rated into the design of the application and operational environments. Customer satisfaction is routinely measured and assessed. Performance measures reflect customer needs, rather than IT goals. The measures for assessing service levels are becoming standardised and reflect industry norms. The criteria for defining service levels are based on business criticality and include avail- ability, reliability, performance, growth capacity, user support, continuity planning and security considerations. Root cause analysis is routinely performed when service levels are not met. The reporting process for monitoring service levels is becoming increasingly automated. Operational and financial risks associated with not meeting agreed-upon service levels are defined and clearly understood. A formal system of measurement of KPIs and KGIs is instituted and maintained.
5.Optimised.when
Service levels are continuously re-evaluated to ensure alignment of IT and business objectives, while taking advantage of technology including the cost-benefit ratio. All service level management processes are subject to continuous improvement. Customer satisfaction levels are continuously monitored and managed. Expected service levels reflect strategic goals of business units and are evaluated against industry norms. IT management has the resources and accountability needed to meet service level targets and compensation is structured to provide incentives for meeting these targets. Senior management monitors KPIs and KGIs as part of a continuous improvement process.
The results of a survey, conducted by ISACA in 2003, show that for a ma- jority of the organisations the maturity level of the process DS1—define
and manage service levels hovers between 2 and 2.5. When further analys-
ing these results, multinationals, organisations in the finance sector and IT service companies reached on average a higher score (between 2.5 and 3). These average numbers can help organisations in analysing their maturity level against industry best practices.
Within COBIT 4.0 the maturity models have been improved, starting from a new generic qualitative model based on following attributes:
• Awareness and communication • Policies, standards and procedures • Tools and automation
• Skills and expertise
• Responsibility and accountability • Goal setting and measurement
The characteristics for these attributes, already partially available in COBIT 3.0, are more systematically and consistently applied for each IT process in this edition.