Why asking what you want to report on is the wrong way to implement a tool

By ITIL from Experience ©

IT Consultants or techies, implementing an ITSM tool often ask the organization: What do you want to report on? What do you want to know from the tool? This is an effective approach to configure the tool. However, will the result be useful to the business?

This approach assumes that people answering the question have control over the business process and authority over the people that will create and manage the life cycle of the data and that there are no constraints. Furthermore, the answer is a wish list like: “If we could know the PCs with this model of power supply, we could claim compensation under our warranty from the supplier.” Or, “It would be interesting to know X or Y.” The real question is how is X produced? Who needs it? How will it be used? What value does X bring and is it worth the cost of creating and maintaining it?

Too often the result of this approach is a system populated with data that was (perhaps) accurate when the inventory was taken and loaded in the tool. In addition, most of the time the people assembling the inventory of data are seldom the people responsible to create it after the project is complete. Moreover, they usually do not have the authority to modify processes or to decide that the organization will invest in this data and incur its life-cycle costs. Nonetheless, Consultants delivered on their mandate and initially fulfilled the requirements. Now the organization is left managing a system with no processes to create and maintain the data it contains. It was simply assumed that people would be creating or updating the data.

After a while, the organization will likely start to question if they have the right tool. The saying: “Garbage in, garbage out” can be heard. Lack of processes and controls is the reason why it ends up being garbage. It is the result of taking a technology based approach to implementing the tool instead of looking at it from a business process perspective. Thus, its an implementation for the tool’s sake; not for the business’ sake.

A business approach to implementing a tool looks at enabling the business and starts by defining the business instead of the data. Thus, the following questions should be asked instead:

  1. What does the business need to accomplish? (e.g. Manage warranty claims)
  2. What data is required by the process at each of its task? (i.e. Inputs)
  3. Is there a process(es) in place that can create this data or is a new process needed?
  4. What process is required or which process needs to be modified to meet the business need?
  5. Is the data created before it is needed by the process? (i.e. Sequence)
  6. If the data is not created today, or it is being created too late, can we modify the process or procedure to create the data when it is needed?
  7. If the data available in another tool or does it have to be communicated by people (i.e. automated vs. manual)?
  8. Are there restrictions to sharing this data? (e.g. Financial or personnel related data)

Asking these questions before configuring the tool ensures that processes are in place to create and maintain the data in the system. Now, buy-in is needed from the different groups and people responsible for creating and maintaining the data needed. This is more easily said than done. A lot of convincing may be required to ask a group or someone to create data for you. Especially if there is nothing in it for them. For example, it is easy for the individual receiving the equipment from the supplier to capture the PO number used to purchase it and its serial number, but that requires additional effort.

For the business approach to work, business analysts that know little about the tool. System analysts are needed to identify tool features and functionality to implement the process. Having these two roles on the project will help balance the tool and business needs.

For further information on using a business approach to system design consult consult the Architecture Development Method of The Open Group Architecture Framework (TOGAF)1 2 . It starts with the vision, determines the business process, the data and application requirements before the tool is considered.


From Around the Web:

Implementation > Technology (ITSM Tools)

2 The text book is available online at http://pubs.opengroup.org/architecture/togaf9-doc/arch

Copyright 2012-2014 - ITIL from Experience - D.Matte