Implementing New Software without the Operational Chaos

Technology in last-mile delivery has increasingly become a need, rather than a good-to-have, to meet the consumers’ and businesses’ demands for greater speed and transparency in the delivery of goods. Automating non-core processes allows you and your team to focus on core competencies to let you have an edge over your competitors and make your services more indispensable than ever.

While most are able to recognise the need for software and would go ahead with the purchasing of suitable software, buying the software might be the easiest step yet for some. Implementing the software can sound like a daunting task, for the fact that it could involve entire process flow changes, change management and risk having company operations come to a halt in the absence of proper management.

In our previous article, learn how you can determine the people involved and how to deal with the human element of change.

Here are some steps you can take to kick-start the implementation process of the software while minimising disruption to key daily operations and prevent it from spiralling out of control.

1. Team Buy-in: Get Everyone on the Same Page

Announce the news to the team at the best appropriate time, preferably when things are less busy. It can be quite a challenge to achieve the same level of productivity in the initial stages of software adoption, where people are still trying to navigate their way through the software and figure out how they would like to best use it. Buffering in some time and space for your employees reduces the potential stress that comes with the learning curve and process changes.

Get the buy-in by communicating the benefits of the software, functions, how you can see the software help them achieve a higher level of productivity and address any concerns or fears. Over communicate, if you must. Also, make sure that they are onboard and know the game plan for implementation. Ideally, everyone should know what is going on and are kept in every step in the process along the way, so that the team would feel like a part of the change and come to embrace it.

2. Pacing Change: Create a Project Timeline

Hold a change management workshop before kicking off the software implementation process. Brief stakeholders on the transition that the company is going through, how the company is changing to meet the changing demands of the future: the “As Is” (current) vs the “To Be” (future). This serves to help all stakeholders understand the change in work and process flows. It is also a good time to obtain inputs and hammer out the details on transiting from the old to the new flow, possibly which parts to keep, which parts to change and what to do to make the transition less abrupt.

Decide on an implementation timeline, including when are the scheduled training sessions, who are the people that need to be there, deadline for the migration of processes to the new software. This minimises uncertainty in the implementation process by providing more structure to the change. By setting a concrete plan for the implementation, it is easier for the team to pace themselves and make the necessary arrangements to accommodate or even welcome the changes.

3. Wet Weather Planning: Set a Contingency Plan (Escalation Planning)

Yes, we can agree that technology is reliable and efficient, but it does fail us at times. Thus however robust the software may be, one still needs to plan for rainy days. There should be a protocol that the team can adopt in the event of a software outage. The team should know what to do to keep operations up and working when the software goes down.

Here are some key questions that one should be answering:

  • Is there sufficient offline data to go on?
    Periodical back-ups of data could be scheduled into the process flow, to ensure that sufficient data will be available to keep operations going during service outrages, albeit the slower speed and more manual approaches.
  • How much is affected? Who will do what? How will the problem be mitigated? Who is in charge of pulling it together?
    The affected personnel should be clear about the offline approach in managing deliveries and route planning, as well as how they can support each other to ensure that the jobs can still be completed on time.
  • What is your software vendor’s Service Level Agreement (SLA) to you?
    The SLA stipulates the procedure for reporting problems: who to report to, how to report the problem, possible steps for resolution (if any). This allows for the problem to be raised to the service provider promptly, for recovery actions to be taken. One can take reference from the response time frame defined in the SLA to plan resources to cover for the duration needed for the software to be fixed. It is also essential to find out the type and amount of support your service provider can provide, to reduce the impact of the company’s productivity during software outrages. Also, credit, reimbursement or option to terminate the relationship may be available if the service providers are unable to meet service obligations.

4. Change catalyst: Creating Support Infrastructure

Arrange for training sessions with service providers, preferably with hands-on practice and step-by-step function run-throughs. Request for supporting materials and instruction manual as well, to cater to people of different learning speeds and needs. Arrange for refresher training sessions with your service provider for those who need more time to get used to the software, and have them start the process bit by bit to help them transit.

Do a cheat sheet for staff and drivers, with the easy-to-follow steps that can be used as a quick reference for those who need a little reminder. Process flow reminders are important if you expect a process to run smoothly, especially a new one.

5. Employee engagement: Taking Care of the Users

Essentially, the successful software implementation can only be made possible by the people, thus it is imperative to ensure that the people are well taken care of. Different people on the team can have varying learning paces; some will learn the software faster than others and that is okay. One way to address this issue is to teach the fast learners first and get them to pair up and guide those that need a little more time. Alternatively, small and manageable exercises can be given to the slower learners for them to practice first.

For example, in the case of a new transport management software (TMS), have your staff practice creating five new jobs daily or import the information right at the start of the day, before the pilot begins so they can get used to the process (these can be deleted after the practice is done). In the case of implementing new customer relationship management (CRM) software, it could be to try entering five new client records. The idea is to build habits and make the process more intuitive. This can be applied flexibly; the exercises should not take up more than five to ten minutes a day.

Be mindful of resistance to change, some team members may have concerns or anxiety when dealing with such changes e.g. fear of losing their jobs to the software or unconfident that they will be able to use the software. It is important to be understanding and lend a listening ear to them, when possible. Most of the time, the resistance can be relieved with some assurance and a better understanding of how the software can help them do their jobs better. Some of their concerns brought up may be relevant and reveal a previously unconsidered blind spot, as they are the people on the ground after all. They could have good suggestions to make the flow better or how to best make sure of the new software to optimise operations.

Conclusion

While it may sound intuitive enough, the human element often does not receive as much attention in software implementation, thus the emphasis on a people-oriented approach in the suggestions given above. The implementation process should be about empowering people to find the best way to leverage on the software to become more efficient. Once that happens, it is almost certain that the time saved would be far greater than the time invested to learn the software or have the software implemented. The new software is bound to take some getting used to, and there will certainly be hiccups along the implementation process as process flows are being reconciled and realigned. But with the right mindset of the people, the implementation process does not have to be dreadful, but be seen as a necessary future-proofing or upgrading process for both the company and themselves, to prepare for roads ahead together.