Mop up data mess to bring order to your service delivery process

Proper categorization of data for use in service delivery lifecycles is critical to the effectiveness of IT organizations.

The service delivery process generates a ton of data -- about assets, incidents/resolutions, issues and service

histories -- that we store away in

Greg Lenox
Best Practices
Greg Lenox
categories. The ongoing collection process is a form of institutional learning, building that all-important knowledge base. But if we're not careful about how we put data away, the organization has a harder time finding what it needs in a timely fashion.

Instinct tells us more detail earlier is better. Unfortunately, when it comes to categorizing and relating data, this reasoning is dead wrong. Nearly all software solutions have a three-tier hierarchical categorization scheme, such as category, type and item (CTI). This three-tier CTI scheme drives us to get into very specific details about the manufacturer, model, error code, etc., very early in the categorization of the incident or request.

Regrettably, what we started out trying to accomplish with a three-tier categorization actually backfires on us because the data flattens into an unrelated, cumbersome mess. A big part of the problem is the lack of enough relationship tiers.

Drowning in data from your service delivery process

For a demonstration of my point, look no further than your old desktop friend "C:." What do you see when you open it? A bunch of subdirectories. Within those subdirectories are folders. Folders that hold files and more folders. Now, imagine if all the files sloshed around in the root directory instead. Quick, find that document from six months ago … what was it called? Sure, you could search with wildcards, but time would be ticking away. Also, what happens if the document has a name very close to the name of hundreds of other documents? Now you're faced with a Herculean task.

Use the right buckets

Of course, your organization doesn't store everything in one data bucket. But you need the right buckets -- and the appropriate number of related hierarchical tiers (four or five levels) -- to ensure that your database stores and retains the knowledge you put into it. Many organizations are building their categorization structures on the fly based on help desk incident tracking or service deployment. So I see structures such as "Network/CISCO 7613 Router/Field Notice: Difficultly Passing Traffic Through Port 1 and 2." Network is a lot of territory to search. How likely is the first-level support group in the help desk to relate an incident to a specific manufacturer, much less a specific router model and field notice from the get-go? And what happens when you change or add vendors?

Follow a more straightforward path for your service delivery process

The trick is to have enough levels and use enough generic categories. "C:Documents and SettingsGLenox@Entuition.comMy DocumentsSearchCIOApril Column 3.28.04.doc" makes it easy to locate this file. Keep in mind that the interface shields me from most of this complexity. Similarly, "Network/WAN/Router/Cisco 7613" will get the help desk to a problem fix a lot faster. Generalization in those higher-level categories works in your favor. After all, users call in to complain that they can't get on the network, not that the 7613 router is down.

Get ahead

My advice is to step back, take a global perspective and increase the number of relationship tiers to four or five. Reorganize data categories in a more general, stable way for the first three tiers, and then get into more details on the fourth and/or fifth. To keep your architecture under control, create a disciplined process for adding categories. For example, the help desk can flag an incident as a possible new element. The manager can then examine it with time to think things through. Experience has proven to me that most of these cases can go into existing buckets rather than burdening your database with another category to sift through. The fewer formulas required to access the knowledge base, the more efficiently your operation can run.

And stay ahead

While I've based my discussion on the help desk, properly restructuring your service data will make many aspects of the IT service delivery process more transparent to managers. For example, you'll be able to track incidents against all 17" monitors and compare their service histories before you authorize this year's purchases (similarly for assessing QoS levels). At the organizational level, you can spot opportunities to crush stovepipes and improve service, for instance, by cross-training to distribute formerly restricted skill sets. Strategically, you'll be better able to align your service delivery process with the business, which is, after all, your job.

Greg Lenox, an expert in the processes, methods and practices of IT operations for customer support, help desk, asset management, inventory management, telecommunications management and change management, is president and CEO of Entuition Inc., a maker of operations management solutions in the infrastructure logistics marketplace. At Entuition and in previous positions, he led several major re-engineering projects. His clients included SunTrust Banks, Citibank, Target, GlaxoSmithKline, Baxter Healthcare, Nations Bank, Wachovia Bank, First Union Bank, BB&T, CCNB, CNA Insurance and others.

Dig deeper on Enterprise SOA and Web services

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchCompliance

SearchHealthIT

SearchCloudComputing

SearchMobileComputing

SearchDataCenter

Close