Continue in 2 seconds

Telling Where It Hurts

Published
  • February 01 2005, 1:00am EST

Finding and Relieving Information Systems Pain Points

Do you remember in eighth-grade algebra class when you sweated over a problem that began something like, "Two trains leave from New York and Chicago two hours apart ..." - because you had no clue as to how even to begin solving the problem? The issue lay not with you, but with the problem itself; it was complex and, therefore, difficult to solve. That's often the way it is with IT problems. It's easy to look at the surface of a problem and think you know what the answer is when, in reality, the problem is most often multifaceted and pervasive throughout the company.

The key to solving any complex problem - in algebra or IT - is to dig deep into its underbelly to ferret out its underlying components. In algebra, it's about X's and Y's In IT, it's about root cause analysis - finding the source of the problem by mapping the problem's pain points. A pain point is any point in the company where there is a problem that has an impact on the company's performance. That's the vanilla definition. To bring it into an IT focus, a pain point is an issue with the company's ability to collect, store, coalesce and/or analyze its data to make timely, accurate business decisions.

Well, that's great, but how do you even identify these pain points, much less determine their impacts on the company and begin to cobble together a cure? You can use a technique called pain point mapping. Pain point mapping is simply a three-step method that involves building a map from problem to impact to solution. The steps are:

  1. Clearly defining the issues causing "pain" to the company.
  2. Determining the impact of these issues on the company's operations or decision-making ability.
  3. Developing a solution that is a direct response to the pain points.

Before you develop any IT system, you should know where your pain points lie, their impacts and how to fix them. How well you define your problems will largely determine whether the solution you develop succeeds. Poorly stated problems, or impact areas, often lead to ill-conceived and inappropriate solutions. In other words, the system you build might be technically elegant but relatively ineffective at solving your company's problems.
Let's tackle defining the issues first. "Data" pain is pretty much the same as body pain. It's fairly easy to tell where it hurts; it is more of a challenge to accurately verbalize the problem. For example, your company could have a problem with data accuracy in that different regions or business units receive different numbers when they perform similar analyses. That's a good high-level statement of the problem, but it's not very precise.

With some analysis and cross-functional interviews or information-gathering sessions, however, you might emerge with a real, precise problem statement, such as "Our company does not have a common definition and hierarchy for customer, product and vendor information across regions, departments and information systems." Now you have a starting point -- you know exactly where it hurts. However, you must now determine exactly what it's costing you - its impact - in both monetary and non-monetary terms.

A quick survey of your department heads and key knowledge-workers will tell you how this issue is impacting the company. For instance, your marketing people might tell you that they cannot efficiently perform brand and/or retail account management. Managers may not have the ability to report on, or analyze, business information by multiple dimensions, thus hampering forecasting and inhibiting decision making. Ouch! That's a pretty clear impact to the bottom line.

For our discussion of solution development, however, let's look at a more detailed example of a pain point. Your IT people may have defined two pain points relating to data quality that can be stated as follows: "Our company lacks standard data management and governance policies, and we have redundant customer, product and supplier records across different divisions, regions and systems." Now, this could be two separate issues, or it could be a "which came first, the chicken or the egg," problem.

Either way, after you've identified the pain points, you must define their impacts. In this case, it may be that your IT people tell you they spend significant (and costly) time performing manual processes to gather and synchronize customer, product and vendor data across those divisions, regions and systems. That's another pretty clear impact on the bottom line. To fix it, you must now develop a solution that's just as detailed as the problem and impact statements.

Your solution should be a direct response to the problem. Okay, that's a no-brainer, but that simple fact is often overlooked. Why? There are myriad reasons, some of which include misunderstanding the problem, attempting to create a panacea to fix all known (and unknown!) issues or simply developing the wrong solution to the problem. To avoid this, it is important to be able to trace (thus the "mapping" terminology) a direct line backward from solution to impact to problem.

For our two data quality problems, one possible solution could be to define a data governance strategy for the company to ensure that key data elements such as customer sold-to number, product number, vendor number, etc., are standardized throughout the company, regardless of how or when information systems change or are added. This solution would obviously involve initiatives such as conducting a corporate data quality assessment and developing enterprise-wide data quality and data cleansing procedures and systems.

As you can see, there is a direct line from the problem (data quality) to the impact (impaired analysis ability) to the solution (data governance strategy and data quality/cleansing initiatives). You must do this for every critical IT issue your company faces before you build an information system to resolve those issues. It's a matter of precisely defining the problem, accurately assessing its impact and developing an appropriate solution to the problem. Once you've done that for each issue you can identify, you'll be well on your way to solving your thorniest IT problems. And those two trains ... well, maybe you will no longer see the oncoming headlights in your sleep! 

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access