Successful Rollout Part 1: The Use Case

Pilot projects are supposed to lead to more. It’s right there in the name; these are the leaders of soaring ambitions, the work of which lets to projects taking flight.

Of course, a flight without a destination can’t lead to anything.

When we begin our onboarding process, we’re already laying the groundwork for a successful rollout. This is our opportunity to figure out our destination: the use case. The process calls for clear and open communication of needs and capabilities. The two meet at a well-defined use case for the solution, with clear objectives, demonstrable value addition, and enthusiastic participants.

Get Objective

In a classic episode of The Simpsons, a huckster pitches Springfield on building a flashy new monorail system: electrified, six cars, glides softly as a cloud, lots of cushy jobs. While the rest of the town is swept up in monorail fever, Lisa Simpson asks the huckster to, “explain why we should build a mass-transit system in a small town with a centralized population.”

Indeed, Lisa.

The world is long on exciting solutions. We make more every day. But an exciting solution is only the right solution if it actually solves a problem—otherwise it’s no solution at all. Monorail may be fun, but a small town with a centralized population is a poor use case for monorail. Bike lanes would be a more appropriate solution because they would actually address Springfield’s problems.

The same is true of digital manufacturing solutions. Excitement may be enough to launch a pilot project, but that excitement will fizzle when everyone involved realizes that the solution is a poor fit for extant problems. That’s why it is critical that both parties in a project understand what the solution provider offers, and what the customer needs.

At AiSight we make a predictive maintenance solution that includes plug-and-play vibration sensors and a software dashboard to analyse, interpret and visualize sensor information. It is pretty exciting! But we want it put to appropriate use, meeting our customers’ needs.

That means we want to know about pain points—where there are problems we can solve. High-maintenance machines or machines that require frequent manual interventions are best. For example, we recently completed a validation phase in which we installed sensors on every single machine in a parquet flooring line. There wasn’t a bad use case in the bunch—the kinetic and abrasive work, 24-hour production schedule, and high cost of unplanned downtime made the line a perfect candidate for predictive maintenance.

As expected, this validation phase demonstrated significant added value.

Demonstrating Value

Given the fallibility of launching pilot projects based on fleeting emotions, we would be wise to let the data lead. That means that we should be able to back up the merits of any project with provable added value. When launching a pilot project, therefore, we have to be candid about its costs and benefits.

According to this study from Mckinsey, “61% of respondents see lack of ROI as a major obstacle when implementing Digital Manufacturing solutions at scale.”

Mathematically, there are two reasons a digital manufacturing solution would lack ROI: high cost of investment, and low return. These are two sides of the poor-use-case coin. In communicating our respective solutions and problems, we also have to communicate expectations. This means comparing the cost of the solution to the cost of the problem, and expecting a satisfactory difference.

This is the scientific method at work. Launching a pilot project should include an explicit hypothesis: we will see ROI within these parameters. All the solution has to do in the validation phase, then, is deliver. Upon delivering results, it should be easy to move on to rollout because everyone should have been prepared for that result.

In the case of the parquet flooring line above, each hour of downtime could cost our client up to 20.000€. Since breakdowns were common on the line, we could expect that using our predictive maintenance solution to manage downtime would deliver significant savings. Over six months, our system performed to expectations, delivering 200.000€ in savings. Well worth it!

Now We Can Get Excited

This is our chance to get emotional. We have quantifiable expectations. They look great! If the solution performs in the pilot project, we’d be remiss not to scale.

But can we?

It’s not a given. The ability to launch a pilot project doesn’t entail the ability to scale. There are often plans at work beyond the scope of the pilot project—even beyond the scope of broader rollout.

This is why it’s important to get people at the highest level in companies involved in pilot projects from the outset. If they’re sold on the use case and know what to expect, they too can get excited. This calls for communication not only between parties, but also within the organization implementing the solution.

This is also a matter of that organization’s broader goals. It’s a simple reality that, for better or for worse, for reasons good or bad, scaling might not fit organizational goals. Buy-in from high level stakeholders is not only critical for their approval, but for their ability to set a broader agenda.

The Next Step

With a clear use case, made-to-measure expectations, and high-level involvement, we’ve completed step one. Not only have we cleared the first obstacle to successful rollout, we’ve laid the groundwork for the next step.

That’s the topic of our next article: The Strategy. Companies that take on projects as part of broader innovation strategies are primed to both implement innovative solutions, and to maximize their benefits. Stay tuned for part II of our series for an in-depth look at how strategy enables success, plus examples of the principle in action.

If you're eager to get started, schedule a demo now.

‌

© 2022 AiSight GmbH. All rights reserved

Phone: +49 (0) 30 40363399

Website: https://aisight.de