Search About
Any questions? is available to answer any questions you might have
Email
X

How can we help?

Welcome to Pink Elephant EMEA! We offer a comprehensive range of ITSM and ESM services designed to support your organisation's digital transformation.

Whether you're looking for expert ITSM consulting, cutting-edge technology solutions, award-winning training courses, or hands-on IT support, explore our website and use the search box to easily find the resources, insights, and services you need.

How to Transform Information from Raw Data to SME Knowledge Effortlessly!

Many IT Professionals look at the same set of data and come to the conclusion that the raw data as it is represented at that time does not add any value towards making a conclusion. That might be true, but if you know what to do, that same set of data could be transformed successfully into highly useful insights for a problem situation. The secret is to use a process that would allow the investigator to transform the data into useful information. How do we do that? Like I said, using a specific process such as the following:

Continue reading after the photo

How to Transform Information from Raw Data to SME Knowledge Effortlessly!

Raw Data to SME 210415

You need to know what to look for and how to go about doing this, but once you know which questions to ask it is fairly simple. The golden rule is to ask the right questions from the right information sources at the right time to get the right answers that would provide a more detailed insight into the problem situation.

The following procedure would be most effective in getting the right answers. We’ve been using these tools and techniques for at least 30 years and helped hundreds of clients to better understand the situation they are dealing with. Following the combination of the process above and the tools below helped them to solve really vexing problems in a relatively short space of time.

  1. Insist on identifying the correct fault. In more than 95% of instances our clients were looking at the wrong problem and it is because they did not concentrate on finding the correct fault first.The Root Cause Analysis Cycle
  2. Who has the information? Simple question, but powerful! One of two things we do differently from what the client tried before, is that we insist on having the right people at the session.
  3. Asking, “What it is not?” This will create significant insight into the incident being experienced. This question normally leads to a curious contrast of what is happening and what is not happening and why that would be.
  4. What is unique about this fault? This will get you and your team to the core in minutes! Providing normal answers would solve any fault that is normal, because they’ve seen it before and know the resolution. However, a persistent fault is normally a fault that has never been experienced before and needs an extraordinary answer.
  5. Secret to virtual collaboration is a common process.  That process makes provision for organised inputs and the array of information in such a way that would stimulate unique answers to the problem experienced.
  6. “Thinking outside the box” is this a cliché or does it really work? It is really working and this is most probably the most difficult exercise for IT professionals who are used to working with hard facts only.Past now future
  7. Learn how to eliminate “pet theories” and “born losers” early. These theories are normally highly distracting and surprisingly tenacious. They keep on coming up and not adding any progress towards resolution.
  8. Learn how to develop a useful hypothesis and test its logic. Learn how to imagine “what could have happened” and then be destructive in trying to eliminate it. This sounds counter-productive, but it works.

IT Professionals on a day to day basis are confronted with a variety of incidents that degrade the performance of operations.  On a continuous basis the root cause of these problems need to be found and eliminated to reduce inefficiency and ensure service availability.

Root Cause Analysis involces a number of distinct activities.  Initially problem solvrs in IT environments need to do technical cause analysis to ensure that end user service can be restored to its required level of performance.

I will cover each of these tools/factors and techniques separately in upcoming posts, expanding on the “how to” so that you would be able to incorporate this into your own investigative approach, hopefully making you a savvier investigator!

Post written by John Hudson, Thinking Dimensions.