Wednesday, April 29, 2009
About Processes – Part Two
A process converts inputs into outputs. A process is a structured set of activities designed to accomplish a specific objective. A process takes one or more defined inputs and turns them into defined outputs. The outputs are driven by the objectives. The process owner assures that the objectives are met. The process is defined by activities and their procedures/work instructions, specific process roles, metrics (help determine if the controls are functioning appropriately) and any improvements to the process. Processes are examples of closed-loop systems because they provide change and transformation towards a goal. They utilize feedback for self-reinforcing and self-corrective action.
Processes have four basic characteristics.
Processes are measurable
• The process can be measured in a relevant manner
• It is performance driven
• Managers want to measure cost, quality and other variables while practitioners are concerned with duration and productivity
Processes deliver specific results
• The reason a process exists is to deliver a specific result. This result must be individually identifiable and countable
Processes are customers focused
• Every process delivers its primary results to a customer or stakeholder
• They may be internal or external to the organization, but the process must meet their expectations
Processes respond to a specific event
• While a process may be ongoing or iterative, it should be traceable to a specific trigger
Process Activities
A process activity is a set of actions that are designed to achieve a particular objective. The process activities are often represented in the form of a process flow. Each activity is often represented or defined by a procedure. A procedure is a document containing steps that specify how to achieve an activity. Steps in procedures can be further broken down in work instructions.
Process Work Instructions
Process Work Instructions are captured in a document that details out exactly what steps to carry out in order to complete an activity. Work instructions are much more granular then a procedure and are only created if detailed instructions are required. For example:
• Click in category field
• Select category
• Save record
Metrics, CSF and KPI
Metrics are a scale of measurement defined in terms of a standard or a well-defined unit. When we quantify an event or other measurable object, we rely on explicit or implicit metrics. Metrics define what is to be measured. In many cases, metrics are specialized to a particular subject area but there are generalized metrics which can be aggregated across subject areas, business units or the enterprise.
Process metrics – These metrics are captured in the form of CSFs, KPIs and activity metrics for the service management processes. These metrics can help determine the overall health of a process. Four key questions that KPIs can help answer are around quality, performance, value and compliance of following the process. CSI would use these metrics as input in identifying improvement opportunities for each process.
A Critical Success Factor (CSF) is the outcomes that must happen in order for the process objective to be achieved. Critical Success Factors are those elements of a process or service that are vital to delivering the expected outcome or creating value. The service or process should not have more than 3 to 5 CSF.
A Key Performance Indicators (KPI) is a metric that is used to help manage a process, IT service, or activity. A good KPI should provide some idea of whether the CSF or goal is being achieved; should be relatively easy to interpret; should be easily obtainable and thus measured; and should be easily changeable in the event the CSF or goal changes. A CSF should not have any more than 2 to 3 KPI.
There are two additional types of metrics that managers are interested in addition to processes metrics. They are
• Technology metrics – These metrics are often associated with component and application-based metrics such as performance, availability etc.
• Service metrics – These metrics are the results of the end-to-end service. Component metrics are used to compute the service metrics.
It is important that all three types of metrics are addressed. Focusing only on one type of metric will create challenges and not provide a true picture the current situation.
Metrics from a business perspective:
Often there is a disconnect between what IT reports and what is of interest
Now more than ever, IT must invest the time to understand specific business goals and translate IT metrics to reflect impact to these goals. Businesses invest in tools and services that affect productivity, and support should be one of those services. The major challenge, and one that can be met, is to effectively communicate the business benefits of a well run IT support group. The starting point is a new perspective on how IT actions affect business results.
Service and process reporting
Service and process reports are produced to meet identified needs and customer requirements. Service and process reporting usually include:
• Performance against service level targets
• Non-compliance and issues such as service level or security breaches
• Workload characteristics such as volume and resource utilization
• Performance reporting following major Incidents and Changes
• Trend information
• Satisfaction analysis
• Key process areas
There are six key process areas (KPA) within each of the process maturity levels. They are:
• The vision and strategy – the overall direction as it relates to the role and position of IT within the business
• The steering (or direction) – the objectives and goals of IT in relation to realizing the strategy
• The processes – the procedures needed to achieve the goals and objectives
• The people – the skills and abilities needed to perform the processes
• The technology – the supporting infrastructure to enable the processes to be carried out
• The culture – the behavior and attitude required in relation to the role of IT within the business
Reporting policy and rules
An ideal approach to building a business perspective service and process reporting framework is to take the time to define and agree the policy and rules with the business with regards to how reporting will be implemented and managed. This includes:
• targeted audience(s) and the related business views on what the service delivered is
• agreed definitions of all terms and boundaries
• basis of all calculations
• reporting schedules
• access to reports and medium to be used
• meetings scheduled to review and discuss reports
Process Roles
A role is a set of responsibilities, activities, and authorities granted to a person or a team. People or groups may be assigned multiple roles within a process Typical process roles include the Process Owner, the Process Manager and Process Agents. The first two roles are defined in the literature and are usually well understood. However, the role of process agent is not often used or even mentioned. A process agent is typically the person or group of people executing the activities, procedures, and work instructions. Tools can be included as process agents when automation is involved for specific tasks.
A critical success factor in Service and Process design is to define the roles and responsibilities within the organization for the various activities. A trademark of high-performing organizations is the ability to make the right decisions quickly and execute them effectively. The RACI is an authority matrix used to align roles and responsibilities with processes and activities. Such matrices are often used within organizations to indicate roles and responsibilities in relation to processes and activities. RACI stands for:
R Responsible The one responsible for getting the job done
A Accountable Only one person can be accountable for each task
C Consulted Involvement through input of knowledge and information
I Informed Receiving information about process execution and quality
Of course, where do we find the process agents? Process agents are found among the following four functions, explained in details in the Service Operation book. The are the Service Desk, Technical Management, Application Management and IT Operations Management. It is important to remember that external collaborates (partners, vendors, and suppliers) are also process agents when any form of outsourcing in involved.
Process Improvements
It is important to identify and to differentiate between two basic groupings of roles within process improvement. The first grouping, the production roles, is about process improvements as a way of life within an organization. These roles exist on a permanent basis and deal continuously with ongoing service improvement efforts.
This first grouping includes such roles as service manager, service owner, process owner, operations analyst, measurement analyst, and quality assurance analyst among many others. These roles are often associated with those responsible for the day-to-day operations of the IT Infrastructure, but will also include those who are working at all levels of the organization from defining strategies, designing and transitioning new or changed services to the production environment.
The second grouping, the project roles, reflects the more traditional approach to improvement efforts based on programs and projects. Taking a leadership position in the creation and adoption of processes and services this second group includes roles such as executive sponsor, process owners, process design/implementation/re-engineering team, process advisor and project manager as examples.
All processes have an activity focused on improving that process. The improvements should target one or more of the following areas:
• Real and perceived value to the customer
• Quality of the process activities and outputs
• Amount of throughput produced
• Internal or external compliance to the process
Monday, April 20, 2009
About technology architectures
The Service Design book, section 3.6.3 on page 35, provides a specific context for the terms architecture and system.
‘Architecture’ is a term used in many different contexts. In this context, it is defined as:
The fundamental organization of a system, embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution
‘System ‘in this definition is used in the most general, not necessarily IT, sense:
A collection of components organized to accomplish a specific function or set of functions
The section then defines ‘architectural design’ as
The development and maintenance of IT policies, strategies, architectures, designs, documents, plans and processes for the deployment and subsequent operation and improvement of appropriate IT services and solutions throughout an organization
Let us look at the above in more details.
IT policies and strategies
This is defined by senior management during the Service Strategy phase of the service lifecycle. Designers will need to consider the resources (financial capital, infrastructures, applications, information, and people) and capabilities (management, organization, processes, knowledge, and people) of the organization (See SS book, figure 3.8, on page 38). Of course, all of this must coordinated with the business requirements (see SS book, figure 3.9, on page 39).
Designs
Using inputs from the business and service strategy, the designs needs to take into considerations the four P’s of service design namely, people, processes, products, and partners. Looking back at the generic process model (figure 3.11 SD book, page 43) we find many of the required elements such as process policies, documenting and mapping roles, and responsibilities to procedures and work instructions. The process is in turn part of the monitor-control loop that is part of the management method used by the organization.
The designers must take into considerations, the vision, mission, goals, and objectives in order to translate them into critical success factors, key performance indicators, and metrics (see CSI book, Figure 4.8, on page 62).
Another key aspect to consider is the relationship with partners and suppliers. This is a significant constraints since most of the contracts are already signed and in place.
Documents
There is a wealth of data and information in various forms throughout the organization. There are plans, contracts, job descriptions, organizational structures, process workflows, procedures, instructions, configuration, lists, and databases among many other document types. One of the major difficulties for the designers will be to sort through this documentation and remove that which is obsolete, duplicate, incomplete, or erroneous.
Plans
Although plans should be considered as documents, it is important to identify and sift through the myriads of plans that are in use in the organization. Some of the difficulties will include gathering them, make sense of them and more importantly, make sure they align.
In an ideal situation, and we know nothing is ideal in the real world, an organization would have business plans, financial plans, contingency plans, continuity plans, and the plethora of IT plans mentioned in the ITIL literature.
Architectures
Now that we have covered the various aspects of architectural design, what are those architectures? As I read numerous articles, whitepapers, hardware and software vendor literature and books, I think I can summarize the list of architectures as follows:
• Data and information
• Database
• Hardware such as desktops, mobile devices, servers, and mainframes
• Software and applications
• Network and telephony
• Environment such as heat, ventilation, , air conditioning
• Physical workspace including safety
• Business, organization and enterprise
• And finally, service
Looking at any organization, we quickly realize that the above architectures are already in place. Of course, many components and their management may be outsourced. Of course, many people may not agree with business plans and decisions. These people would do things differently if they ran the show. These people knew ‘this’ would not work or that ‘it’ would happen. Of course, insight is 20/20. Let’s stop being cynical.
We have to deal with the cards we are dealt. This means that we have to sue what we have and through gathering information, processing it and analyzing it we can find ways to improve things.
There are many documented practices out there for designing, deploying, and operating the above architecture. I wish thee was an easy answer to all of the above but there isn’t.
So roll up your sleeves and have fun.