“To each there comes in their lifetime a special moment when they are figuratively tapped on the shoulder and offered the chance to do a very special thing, unique to them and fitted to their talents. What a tragedy if that moment finds them unprepared or unqualified for that which could have been their finest hour.”
Following on from Implementations, the third post in this Customer Experience series, today’s post discusses the next phase, when the OSS is handed over to operational teams to use.
The customer experience during the handover stage revolves around the feeling of under-preparedness. Unfortunately I’ve seen perfectly workable OSS solutions laying fallow shortly after handover because the customer’s teams have not been adequately prepared to take over the reins.
When handover day finally arrives and all the hard work of building the OSS reaches fruition, customers and integrators alike are always worried about whether they’re adequately prepared. This crosses into many different areas, including:
- Operational teams – Have I acquired enough knowledge to handle any situation that arises?
- OSS Administrative teams – ditto
- OSS user groups – Not another OSS. I was only just starting to get my head around the last one… and don’t get me started on the changes in my way of doing things, it will take me months to get efficient again
- Customer’s project teams – Have I understood the real user requirements and guided the integrator to deliver a usable solution for our operational teams?
- Integrator team – Have we configured and tested everything so that nothing could possibly go wrong after we hand over?
Since the first four relate to the customer and we’re talking about the customer’s experience, I’ll focus on those. The fifth is a whole other point for discussion.
The first four can basically be managed by two things, knowledge transfer and communication, which fit within the broader subject of organisational change management. An investment in both needs to happen months prior to handover, but are often an afterthough.
Knowledge Transfer – Vendors are often happy to conduct their implementation, provide a few weeks of training, hand over the user guides and move onto the next project. Customers are often agreeable to this “minimal training” approach as a means of reducing costs on an already expensive project. Financial controllers often mistakenly believe that their operational teams will become competent on a new OSS within days, so weeks of training are perceived as overkill.
But we all know better. I consider this to be the equivalent of buying a brand new Ferrari and then filling the tank with diesel because it’s cheaper per litre.
Communications – come in many forms, but an OSS generally works within lengthy end-to-end process chains that require communications between many of the customer’s business units. Unfortunately, OSS testing and operational readiness activities don’t tend to adequately verify and refine these communications prior to go-live.
To be truly operationally ready, the customer’s teams need to have done an OSS apprenticeship on the integrator’s specific solution. As an integrator, you must insist that the customer’s teams are embedded with the project team to learn the solution’s inner workings from the integrator in addition to conducting training courses at various stages throughout the project timeline, not just at the end.
Another way an integrator can support their customer during the stressful transition period is via Production Support, whereby the integrator provides resources that shadow the customer’s operational staff. This gives the customer the peace-of-mind that if they forget how to do a task or experience problems they can’t resolve, they can call upon the integrator’s experts that are on-site during the early days after go-live.