Start with the problem, not the technology
Authored by Clare Banks, Strategic Delivery Director, CloudClevr
I recently had the opportunity to attend the MSP Growth Forum Birmingham and, somewhat outside my usual comfort zone, join the panel discussing Processes & Technology: Building Operational Maturity.
Unsurprisingly, AI featured heavily throughout the day. But one of the things I found most interesting was that, despite all the discussion about new technology, we kept coming back to a much more familiar question: what problem are we actually trying to solve?
It’s a question I’ve asked many times over the years, across lots of different types of transformation, and it is no less relevant for AI.
Start with the problem
There is clearly a huge amount of opportunity around AI, both for MSPs themselves and for their customers. But starting with “The answer is AI – what is the question?” feels the wrong way round to me.
Customers don’t really want AI. They want something to be better.
They might want to respond to customers faster, reduce repetitive work, improve productivity, manage risk better or take cost out of a process. The technology is the means of getting there, not the reason for doing it.
That came through strongly in several of the conversations during the day. The opportunity for MSPs isn’t just to take the latest technology to customers. It is to understand enough about the customer’s business to help identify where it can genuinely make a difference.
And that may mean telling them that technology isn’t the first thing they need to fix.
Don't automate the problem
One comment during the event particularly made me smile; the language used on the day was rather more colourful, but the gist was that if you’re not very good at something already, introducing AI may simply help you be not very good at it considerably faster.
I’ve seen exactly the same thing with automation.
If a process is cumbersome, has too many hand-offs, nobody really owns it and half of the knowledge required to make it work lives in somebody’s head, automating it isn’t necessarily progress.
There is still some boring groundwork to do first. You need to understand how the process actually works, rather than how everyone thinks it works. You need decent data and clear ownership. And you need to understand the exceptions, because they’re usually where the interesting problems are hiding.
None of that is particularly new or exciting, but it creates the foundation that allows you to do something genuinely useful with the exciting technology.
"Going live" isn't the same as transforming
This was one of the areas I talked about on our panel and is probably the part of transformation I feel most strongly about.
I’ve seen plenty of projects where an enormous amount of energy goes into getting to go-live. Dates, plans, testing, migration, training, communications – and then the system goes live and everyone breathes a sigh of relief.
But that’s the point where you find out whether the change actually works.
Are people using it in the way you expected? Has it removed the problem you were trying to solve? Has it made life easier for the customer or the people delivering the service? Or have people quietly developed a new spreadsheet and a workaround because the new process doesn’t quite work in reality?
That’s why involving the people who actually do the job matters so much. They know where the awkward hand-offs are. They know which part of the process everyone avoids. They know the exceptions that weren’t in the process map.
For me, go-live is an important milestone, but success is measured by adoption and business outcomes.
More technology ≠ Great maturity
This was another interesting theme from the day, particularly in the context of MSPs.
We operate in an industry with no shortage of technology. There is a platform, tool or product available for almost everything, and many of them are very good.
The challenge comes when you look across the whole operation.
Individual technology decisions made for perfectly sensible reasons over several years can leave you with duplicated capability, disconnected data and different teams working in different ways. Add acquisitions into the mix and that complexity can increase very quickly.
Operational maturity, for me, is less about having the best individual systems and more about understanding how the whole thing joins together.
The same is true of reporting. The answer to poor visibility is not simply another dashboard. I’d rather know what decision somebody is trying to make and whether we actually trust the information we’re giving them.
Getting the basics right
What I took away from the day is that, while the technology we’re talking about is changing incredibly quickly, the fundamentals have stayed the same.
Sometimes AI will be part of the answer. Sometimes automation or a different platform will be. And occasionally the most useful advice might be: don’t buy anything yet – let’s fix the problem first.
For me, that’s what operational maturity really comes down to. Not having more technology, but being in a position to make good use of the technology you have – and knowing when something new will genuinely make things better.
Technology will keep changing. Getting the fundamentals right is what gives us the ability to take advantage of it.
A special thank you to Will Garside and the IT Europa team for inviting me to take part in the MSP Growth Forum Birmingham, to my fellow panellists for a great discussion, and to everyone I spoke to throughout the day who generously shared their experiences and perspectives.
