5 things to remember before customising a Service digital tool
Francesco Mancuso
Global Service Leader | Business Strategy | Agile leadership ★ Creating change
When it comes to implementing a digital solution, be it a CRM, Field Service tool, etc., rarely there is a 100% fit between the off-the-shelf solution you might buy and the processes that run in your company.?
The Customisation Dilemma
The lack of consistency in processes across the various service organisations in your company may be there for good reasons: here some examples:
On the other hand, going full in into customisation is a very expensive game, because of the obvious customisation related activities (endless process mapping, writing user stories, coding, testing etc.) but also for some hidden resource consuming tasks.?
So here is the dilemma: how much do you need to customise a new service digital tool vs. how much to accept the off-the-shelf solution?
In my experience so far, I have noted 5 key things to consider, in the space of digital solution customisation.
#1 “Some” customisation is better than too much customisation
While there is no perfect recipe to help us decide how much customisation is really required, I concluded that an 80:20 approach is directionally the best way to start. In one article that I linked below, ServiceMax suggests to have even a “80 : 15 : 5” approach to customisation, where:
#2 When we all work under the same principles and goals, it’s easier to sort out our differences
Now let’s address the 80% we mentioned above, aka all the common business processes. There will be among your stakeholders people with strong opinions on why “their process works only in the way they do it currently”, as “they have always done it this way” and “why change something that works”.
So first off, I would strongly suggest including users in the process mapping phase, and, at the very start of the work, agree on basic principles and goals we should all adhere to.?
When push comes to shove, or when things will not work as expected, you will have common principles to point to in order to help with the decision making. E.g.: Do we all agree we need to deploy the most efficient and effective workflow, that minimises the admin work done by our people? - and then - Can you support with data that your process meets these requirements??
领英推荐
#3 Gap analysis: make change proposals VERY tangible
When making a process gap analysis with the users, I suggest being very explicit in showcasing what is going to change in the new process. If this is not super clear, the users might end up agreeing on something, but reject the final solution during the test phase, as it does not fit with what they had in mind.
Make the new workflow VERY tangible. A paper prototype could be enough for the users to realise what they will have to deal with, and you will have a meaningful discussion ahead of time, even before starting any coding or customisation.
#4 Harmonisation is a journey, not a goal
While we can all agree that standard work is the “most efficient and effective combination of people, material, and equipment to perform the work” we also realise that humans are not hardwired for repetitive work. How dare we impose standardised tasks?
There are 3 things to consider here:
#5 Establish a Service standardisation board
When we all buy into harmonisation as the foundation of continuous improvement, having a standardisation board will allow you to quickly and transparently assess the improvement proposals coming from the users. Having clear, transparent and strong criteria for the assessment will help identify the best proposals that will make it into your product backlog.
What else is important to consider in your experience? Please let me know in your comments!
Building a start-up fintech in the SRT space | Programme Director | Operations Director | SaaS | Blockchain | Building smarter digital workflows for capital risk management
1 年Francesco Mancuso All great points. Your key text for me is: "I would strongly suggest including users in the process mapping phase" Absolutely. End users understand the BAU pain points better than the C-Suite or programme team. Involving them at design stage will facilitate better design and better buy-in. I'd expand it to also include communication. Users need to understand what, why, when, what are the benefits and what will I need to do differently? And tailor the comms to the audience; the Board may want a Powerpoint but end users want a Q&A session. What are your thoughts on that?