Main Menu
Home / IT Governance / Legacy Support / A Fool with an (IT Service Management) Tool is Still a Fool

A Fool with an (IT Service Management) Tool is Still a Fool

foolSystem theory has two design approaches when it comes to implementing a system. As Alex Lichtenberger explains, these two are top-down or decomposition, and bottom-up or synthesis. Each of these two approaches has their champions and their detractors, but what Lichtenberger has his eye on is how to utilize both systems to provide the best solution.

He begins by explaining both systems in brief. Essentially, top-down is the older approach of the two and seems to make the most sense from the surface. Top-down starts with recognizing what your organization needs, designing the IT service support around the business process, defining the processes to support that service, define roles, and find the tools to do the work itself. This seems very logical indeed, as it follows the why/what/how/who/with what process that IT thrives on. But Lichtenberger knows it isn't quite that cut and dry:

In theory there is nothing against such an approach, but if you  have followed it ever in practice, you know how costly and time consuming this can get.  This becomes especially a problem because many of the IT processes that are in focus of an ITSM project get more and more  industrialized  (typically this would be: Incident-, Problem- and Change-Management etc.). Let's put it this way: Is there any real reason why an Incident Management process should look in one company completely different than in other ones? Not really. The only reason I could think of is to get as a company a competitive advantage out of it (you differentiate yourself in the market). As this is most probably not the case, you therefore just could buy a tool with predefined templates and build some KPI's and resolver groups around it?  

The bottom-up approach is quite a bit different. Gaining traction recently, the bottom-up approach re-uses out-of-the-box solutions through IT Service Management vendors. Framing itself on cost efficiency and quick implementation, it also has its drawbacks. For instance, this process focuses on the tool and not the problem to be solved. Likewise it doesn't put emphasis on governance or process, which can ultimately hamstring an organization no matter how good the tool is they went with.

Here is where Lichtenberger presents his argument: combine the two. Look at the environment your organization is currently in and determine which of the two solutions would make sense to start with. Then, define how much “service management” you want and how much uniqueness (more appropriately, customization) you need to thrive. Starting with a top-down approach and then molding into a bottom-up approach once your processes are in place is a smart way to make sure you don't lose any of the value brought by rigid structure while still gaining a cost-efficient tool to utilize.

About Anne Grybowski

Anne is a former staff writer for CAI's Accelerating IT Success, with a degree in Media Studies from Penn State University.

Check Also

COBOL Is Still Around Because Nothing Better Has Replaced It

When COBOL was made in 1959, no one could have dreamed that it would outlive …

Leave a Reply

Your email address will not be published. Required fields are marked *

Sorry, but this content
is for our subscribers only!

But subscribing to ACCELERATING IT SUCCESS is FREE and only one click away!
Join more than 40,000 IT Professionals and get the best IT management articles to your mailbox with Accelerating IT Success!

Unsubscribe at any time