|More George Spafford Articles on CIO Update|
For the Executive Geek On the Go Cost vs. Value Designing Controlled Processes The Hollowing Out of Destiny
A service is not just another name for an application or system. Instead, a service is recognized as an assembly of hardware, software, people, vendors, documents, contracts, other services, etc. that are supplied by IT to meet a business need. Each of these components is what ITIL terms a configuration item or CI.
In fact, the services mindset actually explicitly states something weve known in IT all along: In order to meet the needs of the business, IT must properly combine many component parts together with the proper levels of controls intended to safeguard confidentiality, integrity and availability. For example, its not just a warehouse management application that distribution uses. There are servers, operating systems, Windows clients, network segments, switches, barcode devices, IT staff, work instruction documentation and so on that all have a role to play in providing the service to the business.
ITIL recommends that organizations have a Service Catalog to identify the services that IT provides. To do this correctly requires some work. Typically, it is not as easy as sitting down and recording what IT does. In many organizations, IT managers have no idea all of the services they provide to the business!
In order to understand and define the services that IT provides, there are two primary layers to this: business needs and component configuration items. At the top level, from a business perspective, you must understand what business processes are enabled by IT. For each functional area and the processes therein, what is automated using IT?
This is best accomplished by interviewing IT analysts, operations and support staff first and then the business second. The intent is to unearth who is using what. For example, how does patient admissions record patient data? How does billing run invoices? How does group X accomplish function Y?
The answer to these types of questions will require talking to multiple groups because most of the time no one person or no one group initially knows all the answers. This benefits IT because as details are understood, IT can better articulate the value provided to the business.
Next, once you understand what the business is using in a broad sense, then the components assets that make up that service need to be identified. There are automated discovery/mapping tools that can sniff network traffic and generate dependency diagrams. These tools can get you part way, but the results need to be verified and determinations about the people, teams, roles, documentation, vendors, contracts and so forth still need to be made. For groups that dont have tools to assist them, start basic and focus on what information is the most valuable.
The desired outcome is to develop an understanding of the relationships between the various CIs that make up each service. In other words, what depends on what? Unearthing and documenting these relationships are key for the other process areas.