Are you seriously ready for AI and ML in Incident Automation?

Can you trust your data to lead you to AIOps?
This is the first post of a three-blog series that’s dedicated to helping you automate incidents with greater efficiency.

Garbage in, garbage out is a maxim as old as computing.

The phrase is also a haunting reminder for IT operations (ITOps) that outputs are only as good as their inputs. And while nobody argues with the substance of the adage, a surprising number of organizations are still hoping to glean actionable insight from deeply flawed data. Now, more than ever, companies are adopting a philosophy of collecting as much data as possible – known as big data – throwing it into machine learning platforms and hoping to receive actionable results.

But hope is not a strategy.

Brian Amaro

The rush to get on board with the big data trend without an underlying strategy has been a spectacular failure. Last year Gartner estimated that 85% of big data projects fail because they are not correctly implemented. ITOps is not immune. When the garbage going in is used to manage your network, the garbage out costs your organization time and money. When you double down by using that garbage to automate processes all you accomplish is the automation of bad results. That costs your organization more money—a lot more.

All is not lost, however.

Even if you’re among the 85% and have been frustrated with your attempts thus far, you can still build an IT operation that runs with high accuracy and efficiency. As with any structure, you’ll need an architectural plan that begins with a solid foundation, frames a design that meets your current (while accommodating future) needs, and finishes with features that allow your design to function correctly.

For ITOps the best foundation is clean, accurate data that gives you a clear, complete picture of the composition and health of your network.

Building that foundation requires identifying the sources that feed into the data stream, including endpoints, applications, human interfaces, and more. Incomplete discovery, especially in heavily siloed organizations, will leave knowledge gaps that could result in bad data entering the stream or vital data being left out of it.

So, how do you fix it? By employing a discovery method that’s capable of identifying each and every source of data – including third-party streams. You need holistic insight into what’s taking place. You need complete discovery.

Complete discovery is necessary not only to identify your current state but also to ensure you are keeping up with the frenzied pace of change that’s taking place within your infrastructure. According to Digital Enterprise Journal, the rapid pace of change is causing organizations to adopt new management systems 3.1 times faster than they were five years ago as new technologies “are entering the enterprise much faster and organizations are realizing that they need to be leveraging new capabilities to make sure that these technologies are delivering on their promise.”

Once all of your sources are discovered and mapped out in a comprehensive topology, corrections can be made, databases locked down, and knowledge gaps closed through correlation. Then you can move on to framing the structure of your IT operations.

The DEJ study emphasizes the importance of framing because “the effectiveness of their IT automation, AIOps, and machine learning solutions is defined by the quality of data that their monitoring tools (application, network, infrastructure, etc.) are generating.” In other words, garbage in, garbage out.

If you’re wondering if there’s a real-world example of how to turn your inoperable data into something useful, here’s how we helped a major consumer products manufacturer achieve that goal:

Before our engagement, the company invested in state-of-the-art process automation tech and were anxious to enjoy the promised ROI… a little too anxious. They rushed the foundational phase, and once the integration was complete, found themselves addressing a recurring error that forced them to restart their network 35 times a month at the cost of an hour of downtime with each incident. After a few months, we were called in to assess the situation and, upon identifying a source of bad data, traced the issue to a conflict caused by overlapping event schedules. With good data, the problem was diagnosed and fixed within thirty minutes, saving the company more than $11 million per month according to Gartner’s cost of IT downtime estimate. 

In other words, possessing good, operable data is a difference maker.

Good data is the difference between knowing a device has failed and knowing if a device is going to fail—as well as precisely which device will fail, the cause of failure, the associated business processes that will be affected, other relational effects and the appropriate resolution. This is the difference between the cost of doing business and return on investment.

Good data is the difference between yesterday’s ITOps and tomorrow’s AIOps.

Don’t be left behind. Even if you’ve been disappointed in the past, with good data and the right strategy you can capitalize on the capabilities available to your organization through AI and process automation. While you’re at it, that data—and your results—can be used to demonstrate and support organizational change among the C-suite and your organization’s business leaders who may be more eager to adopt their own IT strategies for problem-solving, product creation and delivery, or better customer service.

Learn how ScienceLogic can help you efficiently automate your incident resolution process.

Request a demo