Information technology is playing a much larger role in the broadcast facility, and this series examines how to acknowledge and work with this change. In the June 8 issue we discussed a general sketch of IT Service Management. Let’s dig into the different areas of ITSM along with practical applications for the broadcast industry.
(click thumbnail)For broadcast engineers, the concept of process-based information management has a lot in common with black boxes and signal flow. Graphic is derived from ‘IT Service Management: An Introduction’ by Jan van Bon.
First, it should be noted that the term “information systems” includes not just the IT equipment, but also the personnel, support structures and users of these systems. Managing these systems in a controlled fashion is the goal. Integrating business concerns with this management is necessary in an industry focused on mergers, bottom-line margins and downsizing.
We noted previously that IT Service Management contains two major parts: service support and service delivery.
Service delivery involves higher-level planning and managing expectations; while support is more involved in the nuts and bolts of assuring those expectations are met. This part of our series will focus on the financial and service level agreement elements of service delivery, as they include the business considerations that should drive its implementation in the facility.
Frequently a disconnect exists between business and technical concerns in broadcasting. Budgets are held tight while everyone clamors to have the newest gadgets advertised. Pivotal technical decisions are often made by what an exec saw in a trade magazine, rather than a sober analysis of the facility needs or business plan.
Judging from exalted sources such as “Dilbert,” this phenomenon will not go away, but it can be managed better by having a business and technical context to place it in.
The definition of services is a complex task, but it need not be overly demanding at first. It is more important to develop the structures for service delivery than to pin down all details. IT Service Management is an evolving process in terms of new features and quality improvement, so all documents will continue to be revised over time.
A continuous cycle evaluates “Where do we want to be?” (vision and objectives), “Where are we now?” (baseline assessment), “How do we get there?” (process and resource improvement) and “How do we know we’ve arrived?” (metrics).
Primary in service delivery is the service level agreement or SLA, the basic understanding of the functions of the facility. This will include metrics on performance, response, capabilities, ability to expand, emergency measures, costs, et al.
While SLAs traditionally are thought of as documents for external providers, there is no good reason why SLAs cannot apply to in-house functions as well, especially as finance departments start looking at everything as “cost centers” with their own efficiencies and cash flows. SLAs do not arise out of themselves. They are a tradeoff of finances and the various measures that IS needs to provide Ñ such as how many workstations and studios, remote feeds and storage, automated delivery with easy scheduling.
The SLA itself is derived both from external requirements as expressed by the client or customer, evaluated business needs and internal technical specifications. A service catalog is an overall non-technical representation of the IT services and functions provided. The SLA is a less technical document that describes specific service levels for various services, intended for both end users of these services and management.
An operational level agreement (OLA) translates the SLA into detailed technical plans, processes and resources, while an underpinning contract is used for the portions of the service that are outsourced to an external provider.
A danger to be noted here is that technical performance is easier to evaluate in obvious quantitative ways, whereas other functions of the company (such as reporting quality, general administrative services, human resources) may not receive the benefits of this kind of strict definition. Some functions such as reporting and advertising are seen as the primary function of the business and therefore receive top priority.
A well-written SLA will address the relationship with other star functions, and it should be obvious how more reliance on technical systems improves the core business functions, and if not, the technical planning should be adjusted to make that happen. Naturally there are functions that are taken for granted until they fail, and these need to be addressed strongly enough to rise above the fray and to provide a well-rounded description of the technical needs and focuses. Above all, SLAs should be achievable and practical. Every consideration runs up against limits such as time, money, lack of technology or trained personnel. A technique called the “balanced scorecard” helps to clarify that these choices are tradeoffs, and to evaluate the proper balance.
As an example, having all staff on call 24×7 might guarantee uptime, but it will also cost money or generate resentment. A smaller percentage of staff availability may achieve near the same performance without many of the negative effects. Relating technical systems to estimated effect on journalist performance or advertising revenue or potential disaster can help reduce interdepartmental turf wars. As an example, not all data is equal, so expensive storage systems should be focused on mission-critical data, especially near-term on-air material. Each category should be graded on its importance.
Costs and benefits
While availability, capacity and continuity management are important parts of service delivery, financial management holds all the trump cards. Translating specific IT services into dollars and cents can be difficult, and determining the business value of a service may be as much marketing and psychology as it is economic analysis, but it is essential both for internal PR and for proper planning.
Management may like to brag about its “24×7 facility,” but a system that is “24×7 minus just a little” may be a lot cheaper to maintain. We tend to approach technology as looking for the best and the fastest, but ITSM is more about “right-sizing” Ñ finding the best fit of technology for an application, including future needs.
NASA uses old 286 computers on spaceships because they’re dependable, will run for years, don’t put out much heat and are sufficient for the task. Broadcast systems should be evaluated in much the same way, both for use and maintenance.
Systems usually benefit some more than others. Determining shared costs of services requires a bit of finesse.
Activity-based costing on a service desk may note 50 percent of time spent handling user requests, 30 percent installing new systems and 20 percent on maintenance. Yet help calls from the advertising department may be more frequent but less time-consuming than those from the finance department (such as converting a document vs. programming a new financial report). Last-minute requests from broadcasters may necessitate a higher level of support staff and more spare resources held in reserve. Late-night staff may not meet the same productivity as daytime staff, but is required in case of emergency. While it may be a change of behavior or process may save costs and improve service delivery, the first step is a dispassionate baseline evaluation of the services and their value. Perhaps the “flawed” version is the most practical system compromise.
The budgeting process itself is frequently arbitrary. Budgets based on previous years may have little to do with current needs. Unknown emergency spending may outweigh known expenditures, whereas areas such as security planning use a high degree of analysis and guesswork in assigning values. The timing of the budget may also have a great effect. Some non-profits receive all their funding once a year, whereas revenue-based organizations may have steady or cyclical flows of cash. Future funding may be predictable for some and not for others. Saving money on staff or spare parts in the short term may hurt operations later. SLAs and budgeting tend to provide tight limits to service planning. Next time we talk about the plans themselves.