5 things to remember before customising a Service digital tool
Digital Transformation Cookbook #1 (credit: @Cheq.Tiger)

5 things to remember before customising a Service digital tool

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:

  • Local constraints such as local regulations, customer habits, …
  • Available capabilities: High specialisation and know-how are often grouped in few locations.
  • Variability in product lines: Different products require different service models.?

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:

  • 80% represents the bulk of all the common business processes
  • 15% those that pertain to special commercial conditions
  • 5% represents the flexibility you need for instance, to service the most diverse products in your portfolio.


#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.

An example of paper prototype (credit: @Cheq.Tiger)


#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:

  • Standardising tasks does not mean we kill creativity by bashing it with a pile of procedures. We just need to agree on key outcomes and isolate the foundational components of a task
  • When we execute a task in the most efficient and effective way, chances are that we now have some spare time that we can reinvest for instance, in creating meaningful relationships with customers. Customer intimacy is a key differentiator in the service business.?
  • When we all work in a standard manner, we can scale improvements faster and more effectively. Standard work is the foundation of continuous improvement. We also need to consider a framework that allows users to propose improvements and a continuous review and deployment of updates. Which brings us to the next and final point.


#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!


For further reading

ServiceMax: Standardization vs Flexibility: How to Shape Your Service Transformation

Lean: Standardized Work is a Goal To Work Toward, Not a Tool to Implement

Paul Meredith

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?

要查看或添加评论,请登录

Francesco Mancuso的更多文章

社区洞察

其他会员也浏览了