Metrics Portal Blog

Few CIOs are happy with the state of their IT ecosystem.  Cobbled together from a motley collection of orphan tools and spare parts, this ERP for IT platform more resembles a beat-up old jalopy than it does the operational system of an enterprise-class IT shop.  But upgrading the platform is a major undertaking whose payoff won’t be evident for years, and not something companies are likely to place ahead of other business priorities.

Near-term, CIOs should instead focus on bringing operational discipline to the organization, and squeezing whatever they can out of their existing toolkit.  Although not the nicest way to get from Point A to Point B, “that old IT jalopy” just may have a few more miles left in it.

Here are some suggestions for making the most of what you got.

Eliminate ‘Human Spackle’

Once the systems map for your organization has been created (see “Mapping your IT Ecosystem”), the next step is to identify where there are gaps in the operation, i.e., either discontinuities in the development process, or unfilled voids in the platform where manual effort has taken the place of proper tools.  Some questions to ask:

• Where don’t you have the right tools for the job?  (Excel and e-mail don’t count.)
• Where are multiple tools doing essentially the same thing?
• How does data flow between the tools?
• How do you trace an activity from beginning to end?  (E.g., change tickets, application groupings)
• Where do people abandon the tools when urgency demands quick action?
• Where is “human spackle” filling holes in the process?

In particular, you want to keep your eyes open for “human spackle”—those pockets of administrative personnel doing manual pre- and post-processing to get data in and out of the tools.  Useful when tools are new and users require extra support, these folks quickly become an unnecessary (and wasteful) crutch that may be limiting the organization’s ability to move forward.

With titles like Reporting Administrator, Change Librarian, Quality Analyst, or whatever—important roles if they’re doing what process dictates rather than plugging holes that should be fixed systemically—they can be notoriously difficult to pinpoint and eliminate from the process.

Identify where you have “human spackle” and you will find many of the priority gaps in your platform.

• What activities are they performing?  E.g., data cleansing, data entry, extracts, analysis, reformatting, graphs, report generation, etc.
• What audience they are serving?  What does the audience do with the stuff they generate?  What triggers their work?
• Which if any of the tasks could be done automatically with present functionality (possibly requiring an upgrade), simple enhancements, or better interfaces?

Unfortunately, people in this role are not the right ones to step back and design new processes, as they’ve been too close to the details for too long, and will find ways to make up new work if they fear their jobs are on the line.  It is important that they be reassigned to other useful roles as soon as analysis is complete and automation opportunities have been realized, or they will continue to exert an influence that could bottleneck others from adopting the new tools and processes.

Define an IT Domain Model

An end-to-end domain model is the foundation on which your ERP for IT strategy will be built.  Without a domain model, you will have difficulty tying together processes and data from different systems and will not achieve the end-to-end visibility needed to improve your IT operation.

Using data that you’re already getting from existing reports and feeds, identify those elements that represent similar activities or concepts, regardless of how each tool defines them.  Look for commonalities that can be used to link together related processes, e.g.,

• Department or SBU
• Application Name
• Team or Individual
• Process Step, Activity Type, or Phase
• Change or Requirements Ticket #
• Source Code File Name
• Physical Platform (vendor and version)
• Physical Location
• Root Cause
• User Base
• Budget Code

Your domain model provides a framework for pulling data from the different tools and combining them into an end-to-end view of the operation.  By abstracting a handful of elements up to the domain model, you create a crude fabric that threads together like steps across fragmented tools and databases.

For each tool, you’ll need to map that tool’s definition of common elements to categories in the domain model, and then create a set of master lookup tables that spans all tools.  Here is where you will find just how dirty your operational data is, especially where user-defined (free-form text) fields have been used in place of properly locked-down menus.  In one example, analysis of SDLC phases in a project management system uncovered more than 20 variations of the “Requirements” option, including “Business Requirements”, “Bus. Requirements”, “Bus. Rqmts”, “Scope and Requirements”, “User Requirements”, “BRQ”, and so on—all of which had to be mapped to the domain model categories.

Lock Down the Master Tools

When your systems map and domain model are complete, you’ll want to determine which tools can serve as master for each set of processes.  Master tools should be chosen from those with the best all-around functionality and data structures (obviously).  But selection will likely be hindered by organizational fiefdoms that force the decision to be “win/lose”.

Where you find overlapping systems competing with the target masters, ask the users:

• What is wrong with the master system?
• Besides administrative control of the tool, what else is missing?
• What would you need functionality-wise to get you to use the master system?

Where you find true holes in the systems map, identify which (if any) of the tools could be used to fill them.  Commercial tools typically have more functionality available than is being used, and even though this functionality may not be best-in-class, the value of an integrated, single-vendor solution almost always outweighs the costs and risks of integrating different products.

A quick way to bring structure to the master toolset is to lock down user input fields (via menus, buttons, drop-downs, etc.) for key domain elements.  Likewise on the output side, you’ll want to build adapters that map existing reports and feeds to the domain model, rather than rewriting the feeds themselves.  Locking down inputs and outputs forces people to use a common set of variables, and reduces the burden of having to scrub the data every time you want to run a metrics report.  You might also consider initiating a one-time cleanup effort at the database level to migrate local variants of the key fields to their new locked-down values.

Once the inputs and outputs for each system have been mapped to the domain model, your ability to track related activities as they move from tool to tool, process to process, even organization to organization, will be greatly enhanced, simply by allowing you to join the separate data tables on their common field definitions.

Build a ‘Metrics Portal’

Finally, having identified pockets of manual overhead, created an end-to-end domain model, and locked down your master tools, you’ll want to add a metrics layer to give better visibility into your IT ecosystem.  The objective of this layer is to glue together the tools with minimum system modification and minimum disruption to IT operations.

The “Metrics Portal” becomes your vehicle for collecting and disseminating IT metrics throughout the organization.  With the data cleansed and presented in a proper light, few people will be shocked by how much things have deviated from their intended course, and they will be encouraged to:

• Start using the tools as they are supposed to be used
• Improve data quality, both inputs and outputs
• Manage their processes better via data-driven decision-making
• Reduce administrative overhead and refocus resources on more value-added work

If you are unable to build a metrics portal right away, there is still value in consolidating the “human spackle” functions into a central reporting group, to reduce the administrative overhead and force data consistency across the teams.

You can go far by squeezing more out of your existing platform.  However, as with any renovation project, you will ultimately run up against systems that are just too dilapidated for your go-forward strategy.  When this happens, the time will be right for investing in a new set of tools.  And thanks to the knowledge of your operation that you gain from this exercise, you will be better prepared to take advantage of all that your new ERP for IT platform has to offer.