As distributors and manufacturers evaluate technology solutions for productivity gains, it’s common to lose sight of the quantifiable outcome they aim to achieve while reviewing options. The evaluation phase can be exhausting, and getting so fatigued by choices is often the reason behind this misstep. Impressive add-on features, elaborate dashboards and user interfaces, even pricing discounts can often shift a decision maker’s focus from evaluating a technology for its ability to achieve the goal that was the impetus for pursuing the technology in the first place.
As an example, a common productivity gain is to use technology to automate order processing. Thinking through this particular example, does it really matter if a solution has a slick validation dashboard if the CSR is still a part of the automation process? Automation in tech means automating a task so a human doesn’t have to do it manually.
Progressive executives behind best-in-class companies searching for technology to solve critical business problems know that when evaluating solutions, simply understanding the product and service capabilities of a solution is no longer of value. The simplest and easiest way to start short-listing the right technology options is to understand how quickly you can get it running, and when it will completely solve your problem. Another easy way to think about whether a solution is the right fit for solving a business problem is from the standpoint of an outcome versus an output. Outcomes are the difference made by the outputs. Which outputs are a solution delivering, and how quickly will they work to get you to your goal?
Below are some questions to consider that help facilitate an understanding of whether a solution can deliver a genuine outcome, instead of just a series of outputs.
Key questions to Ask When Evaluating Technology Solutions
Is it Purpose-Built to Explicitly Solve Your Company’s Business Problem?
Does a technology provider have general solutions that look to leverage an emerging technology for many purposes and industries? If so, it is more likely to deliver suitable outputs but not a true outcome.
In contrast, a purpose-built solution means that the product was designed to meet specific business requirements and problems as defined by the end customer and has a proven track record of doing so among peer companies. Features should be designed to complement and enable meeting your precise industry category’s business requirements. It should not require you to try to find your company’s business requirements among a catalog of options.
When Will it Completely Solve My Problem?
We start to make exceptions when thinking we need to adjust to accommodate a solution so that it can integrate more easily with our organization because it’s believed that one’s own business requirements are unique. Sure, for a technology project, some level of customization may be required to meet your exact business needs. However, having a clear understanding and a timeline of when the project is completed will give you two immediate insights: first, whether the solution will ever actually completely solve the business problem it’s being pursued for, and secondly, how quickly you can begin to see value from the solution.
Is the Technology Introducing a New Problem?
Naturally, an obvious question when shopping for new technology is understanding the plan for implementation and all the necessary resources associated with getting the project up and running. Often, what is overlooked is the depth of maintenance that may be required when shopping for new technology. Of course, a seasoned IT lead understands that technology solutions may require some maintenance. What is often unforeseen when thinking about different technology options is the business impact if urgent restoration or deep technical assistance is required. Ideally, a technology is so effective that the business comes to rely on it completely. That’s a big responsibility for IT, especially if the solution is customer facing or affects how revenue is generated. One outage could have enormous impacts on a company’s reputation for reliability and loyalty of their customers.
When a technology isn’t purpose-built for the business process it’s being tasked to solve, the burden on the company may be exacerbated as it may require more technical maintenance simply because it’s poorly suited for the business problem. Robotic process automation is a good example. Where highly cognitive, complex logic is required for a repeatable task, the task simply being repeatable isn’t enough to support it as a solution. The technical debt to repair bots when they break would outweigh its utility quickly.
What Was the Goal?
Work backwards with what is proposed. Do you need to give time back to team members to redeploy to other specific tasks? Do you need to remove costs associated with the business problem that technology must solve? The solution that will truly solve the business problem it is intended for will have quantifiable metrics that can demonstrate how it will achieve the outcome. It really is that simple. What will it cost, what will it save in hours or resources and, most importantly, how quickly?
Craft
Ricardo Craft oversees the product management and product marketing at Conexiom. He leads his team in developing the product strategy, product roadmap, positioning, and messaging for all Conexiom solutions as well as their packaging and delivery into the market.
