Part 1 | Part 2
How Good is My Service?
Here is an interesting thing to try: Go the Web armed only with the name of your company. Now, login to your company's Web site and try and find out what your company actually does. Remember that you must not use any knowledge you already have; you must pretend to be an end user. Alternatively, ask your wife/mother/children to try this exercise, and watch what they do. You will be amazed at where they click on the screen, the paths they take, and the information they either find or fail to find.
I tried searching on my company's Web site a couple of years ago for a particular product. I searched by function, platform, database, and so on (I was looking for an online copy product), and found nothing. When I searched by product name (Extended Buffer Manager Snapshot Upgrade Facility), I found about 20 hits. How many customers are going to search on that name?
Who is using your IT systems? Why are they using them? What are you trying to sell them? Is it easy to contact you if they have problems? Is the data up-to-date? Are the systems available (and this includes performance)? What are the availability and performance requirements (some systems perform better than required, which is a waste of money)? Do you have Service Level Agreements (SLAs) in place, and are you measuring against them? Are you measuring from the end-user point of view, or from your own point of view?
I was visiting a major Australian university last year, and I was told that they were very happy that they had the local systems under control (which was good news as they are using my company's products). What they really wanted to know, however, was whether a potential student in South Africa was able to access their systems and apply for a place on next year's course, because this is what generated their revenue.
Service Measurement
Another area of concern is that of service measurement. The cornerstone of any managed services contract is the service-level agreement. This is meant to be the yardstick that measures the performance of the "service provider," but unless the agreement is written and reported with measurable and meaningful values, it can lead to very difficult situations.
The more vague the service-level agreement, the more chance of confusion on what should be, and has been, delivered as part of the contract. Service-level agreements need to be written with factual, measurable metrics included, and the service provider should regularly provide detailed reports based on these metrics.
The most common metrics tend to relate to issues such as call-response times and mean-time-to-repair faults. However, valuable as these are, they are measures after the fact. Never having to call in the first place because there are no problems is better than having a quick response rate to calls from irate users. Service-level agreements should be based on the availability and performance of the service -- not just its reaction to failure. In fact, SLAs should be based on what the business needs -- most of the time they are written from a purely technical point of view.
I was visiting a major customer last year, whose IT operations are outsourced to one of the major outsourcing companies. The contract is, of course, couched in terms of CPU used, number of housekeeping jobs run, number of tape mounts, and so on, and so on -- which was a totally and utterly incorrect approach, in my opinion. The bank wants a service -- how the outsourcer actually implements the service technically should be of no concern as long as it is safe, reliable, and conforms to the business SLAs. In this particular case, the bank wanted the outsourcer to install a product, which would save 20 percent CPU. The outsourcer, of course, refused, as they saw it as a means of losing money. If you stood back and looked at the bigger business picture, you'd realise that the outsourcer could provide a better service with less hardware expenditure (= no expensive upgrades, ability to handle more workload per customer, and more), and the bank would get a faster response time.
Reporting
Reporting is another critical area that can be overlooked. A good IT department will not only provide good service, but also prove it by providing meaningful reports. These reports should relate directly to the service being provided to the customer and should also show the value that the IT department is bringing to the equation. They should be couched in language that business people can understand -- Oracle availability is meaningless; ability to print invoices on time is significant.
Some More Examples
Here are a couple of examples of IT and business not coming together as well as they should:
Example 1
I went visited a major European bank that had come to my company with a requirement to run their systems 24x7. As they were a leading-edge IT user (sysplex, sharing, dual sites, and more) we had to write some extensions to our software to cater to their environment, but it these all worked fine. I was invited in to meet the DP Manager, whom I have known for years.
"Do the products work?"
"Yes, no problems."
"Are you happy with our support and assistance?"
"Yes, brilliant."
"Do the products do what you require?"
"Absolutely."
"Are you going to sign the contract?"
"Not my decision."
It transpired that the salesperson had never spoken to the business manager, who had raised the 24x7 requirement in the first place and had never established what the business benefits were to the bank of a 24x7 service. I unpacked my steel-capped boots and kicked the salesperson from here to eternity. We then worked on meeting the business manager, whom we discovered had been tasked to make the bank one of the five leading banks in the world, and could not see how they could do that on an international scale without offering 24x7 services.
Example 2
I worked with a large European insurance company that had the requirement to extend its online day by three hours, and hence squeeze the overnight batch processes by three hours. Working with the technical staff, we determined that we could achieve this easily. I was taken in to meet the DBA manager and to explain the brilliant internals of our products and how clever we were at doing things online, which previously had to be done offline. I asked the salesperson if he knew why they needed they hours and he said he did not, so when I met the manager I asked two questions:
- Why do you need three hours?
The DBA manager gave me six good business reasons.
- How much is it worth to your company?
He had no idea, but asked if he could go and ask his boss. He came back 15 minutes later, saying that his boss did not know either, so they were going to run an internal task force and could I come back next week. One week later, we discover that the three hours are going to be worth large quantities of money to them and the IT project immediately got the blessing to proceed.
The Missing Pieces
Business Service vs. IT Process
IT departments tend to think from the bottom up. In this diagram, they would be thinking about databases, networks, job schedules, and so on. The line of business manager, on the other hand, is thinking about whether the back-office functions are running, whether the customer-facing processes are operating efficiently, and what sort of service is being provided to the business partners.
A business service depends on a set of processes to ensure that it is executing and performing as expected. In not-yet-automated business services, the management is done primarily by business-side managers.; the IT organization exists to manage the infrastructure and software applications. In other words, some or all of the management of the business execution is transferred to the IT organization, and hence, businesses should understand that IT management is an integral success contributor.
Automated business services provide many benefits. However, they also bring with them considerable inherent risks. Computing infrastructures are extremely fragile and "dumb" by nature, and each different from the other. Due to the considerable inherent risks associated with IT-based business services, it is vitally important to the business that the environment in which the business service will execute is managed extremely well and cost effectively toward business needs and expectations. The most effective method to date to manage automated business processes is through a set of mature IT management disciplines like ITIL®.
IT Best Practice
No one runs technology for fun, so each component has to provide some degree of functionality to the business. Managing these components is just as critical as the components themselves, because a failure can affect the service that relies upon them. At a technical level the key issue is how the IT department actually proposes to manage the environment. The use of industry-leading solutions and best-practice methodologies should be common to all good "service providers," but they are surprisingly often absent.
Some IT departments see tools merely as a way of reducing their cost of operation by reducing the number of people required to manage the environment. However, the use of tools to manage technology can greatly increase the availability and performance of the infrastructure. By exploiting the functionality within the toolset and applying that functionality to best-practice standards such as ITIL, the business -- and ultimately the customer -- receives the benefits.
This means that not only must IT and business learn to talk to each other, but they also need new tools to make their life business-oriented. When a component fails or performs badly, you need to see the impact from a business point of view rather than a technology point of view. If you give an IT person 5 problems, they will typically work on them in a first-in-first-out order as they don't have any information to tell them not to. When you add in a business criticality view, the order of resolution of problems / performance tuning / infrastructure investment, and so on, becomes totally different and IT begins to build value for the company rather than act as a cost centre.
Through implementation of sensible IT processes, combined with business-related tools and methodologies, the advantage to the business is the true and correct exploitation of the IT investment. This is why the two parties need to learn to talk to one another.
--
Peter Armstrong joined IBM in 1976 and was the UK Country IMS specialist. He helped design parts of DBRC and wrote the Recovery/Restart procedures for IMS disk logging. He joined BMC Software in 1986; these days, he is a corporate strategist, responsible for the increasingly important domain of how business and information technology need to work together. Peter is also a prolific writer and has authored Database Recovery Control (DBRC) in Practice.
