Most enterprise software deployments I have been part of ended well. The rollout finished, the platform worked, and the professional services engagement ended.
The issue came afterwards: Across almost every customer I worked with, the pattern was the same: a capable platform with tons of useful data, a small team or single person responsible for it, and no or barely any captured value.
In the conversations that followed a focal point was always the tool itself. There was an underlying expectation that value just comes from having the platform implemented. The issue I saw was that, although a tool could always improve, technology is only one of three verticals: People, Process and Technology. If an organization doesn't dedicate the right people or resources and implement the supporting processes then technology adoption is guaranteed to fail one way or another.
To simplify this in the enterprise context: If you look at enterprise software such as SAP or ServiceNow, look at the amount of effort it takes to support an organization in their successful use. My observation is that this applies to any enterprise software platform in varying degrees.
What I did with Nexthink
For my customers that faced these issues I tried to find a model thats reusable regardless of resource capacity to make it work for their organizations.
The first thing was to change the mental picture of a tool or platform. My priority was for our customers to view it as a service.
Positioning the platform as a service rather than a tool immediately had an impact in perception for my customers. The conversations moved from trying to aimlessly find value within the tool to building a structure around it that enables finding value with ease.
My go-to process when building a service
A use-case intake process really shifted how my customers started working with our platform and building their service. Having a process that allows an application owner to put a lifecycle on an idea, ask or request enabled them to understand what the next thing is they should be working on within the platform.
FYI: Detailed reasoning available by hovering over the process steps.
First, value is estimated before effort is spent. A ballpark value estimate at intake is imprecise, but it forces the conversation about why the request exists and it creates the foundation of tracking the value of the use-case.
Second, the gates produce documented decisions: Proposal, prioritization, timing, complexity. Much of the value of the process is in what it stops. A declined use case that would have cost hours of engineering efforts with little to no return of value is resources saved.
This process is flexible enough to further integrate contributing roles or to add more nuanced steps in between depending on an organizations need.
What is missing: A service catalog for repeatable work
Not every request should go through the use-case intake process. A predefined dashboard, a standard report, a templated communication campaign are repeatable, low-complexity tasks, and pushing them through that process would be pure overhead.
So the second part of the model is a service-request lane: a small catalog of predefined offerings, requested through a standard form and handled entirely by the platform team, with no gates.
Building a service catalog does two things at once. The business gets fast, predictable turnaround, which makes the platform feel like a service rather than a project or a tool. And the intake process is protected from being flooded with small tasks, so it keeps its focus on high-value work.
The two lanes also feed each other: a use case that went through intake and proved repeatable can graduate into a catalog item. Over time, the catalog becomes a record of what the platform reliably does (well).
The artifacts that hold it together
Services decay unless something holds them in place. The third part of the model is a combination of documents and people, that together form the service offering. I picture them as a house: the offering is the roof, the artifacts are the pillars, and IT and business objectives are the foundation everything must trace back to.
FYI: Detailed explanation available by hovering over the elements..
The two elements that I believe to be critical are the value tracker and the board. The value tracker helps move the renewal conversation from cost to review of value. And the board provides the platform team with a mechanism to defend its priorities and decisions made.
My current reflection
Although I initially designed this for one product, I think this methodology holds up well in any enterprise software scenario as it contains nothing product-specific. It applies especially for a product when its value is not self-evident from usage alone.
At least it helped me answer the question "we bought the capability, now what?".
As I'm writing this post I realize that it might be worth revisiting this specifically for AI.
I'll have a think about it...