Four Reasons Why Companies Struggle with Deploying an Analytic Application

As analyst firm Aberdeen discussed in our recent webinar, more and more companies have realized the importance of embedding analytics into the user’s workflow and getting insights into the hands of more users. However, because many of them are fairly new to the world of analytics, they may not think through the entire process of building and launching an analytic application. There’s a lot of work that needs to happen before we even start building, and in reality, there are a number of common stumbling blocks that companies can encounter on their road to deployment.

In my work as Director of Data Product Management, I tend to see four main reasons why companies struggle with deploying an analytic application.

They haven’t defined the end user

Defining the end business user drives everything—the design, the build, the launch, and the post-launch plan—so there’s no way a company can successfully deploy an analytic application if they haven’t addressed this crucial question: Who exactly are your users, and what do they need?

If you're building an analytic application to be used to improve a process in the finance team, who’s using it? Is it Sarah, who has to decide which payments should go through or which need to be investigated? Or is it Keith, who often gets bogged down on approving expense reports? Or is this for your customer’s finance team, and do you know what their specific questions are and where they need to make decisions in their workflow? Without defining this, you run the risk of stalling in your application development or worse: launching an application to users who can’t find any value from it.

They have messy data

On its own, having messy data isn’t a dealbreaker. The problem here is having messy data and no real plan in place to address it. If a company commits to cleaning up and reformatting their data themselves, then they need to do so. Conversely, if a company knows they lack the time or the resources to clean up their data, then they need to raise that flag and find help from their analytics vendor.

Any vendor has the resources necessary to help you turn messy data into clean, analytics-ready datasets, but if companies don’t communicate that this needs to be done, then it can put a hold on actually building the application. The time it takes to clean up data sources can range from weeks to months, and how the data is cleaned up depends on how the data is being used for reporting and analytics. Communication between a company and the vendor is key to keeping things moving smoothly.

They lack the resources needed

By that same token, I find that many companies struggle purely because they lack any number of resources, an issue that can crop up at any point in the process of creating a full-fledged analytic application.

Maybe a company lacks the resources necessary to clean up their data as mentioned earlier, so the build is on hold until they can do so. Maybe they weren’t able to get people to agree to be beta users, and it’s led to delays as the project team tries to hunt down some form of feedback or validation. Maybe a company doesn’t have the team necessary to support users once the application has been launched, so they’re hesitant to actually deploy the analytics solution.

Communicating these concerns to a vendor ahead of time can help mitigate these risks. Chances are that the vendor you’re partnering with has gone through this many times before and has developed a way to address any issue related to lack of internal resources and can provide suggestions and best practices. One of the benefits of partnering with a vendor is to extend your resources and take advantage of their expertise. Just be sure to keep your vendor in the loop so all parties have the same expectations and are working toward the same end goal.

They decide too late how they want to sell their analytic application

This is a big one, and I find that many companies don’t realize how big of an issue it is. When we’re building an application at GoodData, it’s much easier and more efficient to build multiple versions—like a paid version and a free version, or a paid version and a more robust “pro” version—of the application if we know about it from the start.

If a company only reaches this business decision when they get close to the launch phase, then you’re essentially developing two different applications from start to finish, instead of two different iterations within each step of the process. They’ll need to rethink everything within the application, rebuilding as necessary to support the different needs, structures, and capabilities of each version of the application. This, alone, is a reason to make sure that you have all the right people in the room from the very beginning when designing your analytic application.

It’s been said time and again that companies need to do their homework ahead of time, but it can’t be overstated. Consider every aspect of your application—who you want to use it, how you want them to use it, how you want to sell it, and what you want included—before you start building it. It’ll pay off in the long run.