Senior executives generally do not feel the pain of manual, cumbersome operations at the same level as other employees because their teams put the pieces together for them. For this reason, it is not uncommon that catalysts for change come from individuals outside of the C-Suite. Burdened in spreadsheets, exporting from one system, cleansing, adding various fields, merging with a report from another system, sending emails to clarify items – this is the reality for so many employees at start-ups through to global enterprises. If companies do not invest in innovation, they are inherently accepting inefficiency in their business.
On the flip side, it is natural to have an “if it isn’t broke, why fix it” mentality. Many studies, such as McKinsey Consulting, have found that 70% of digital transformation projects fail. It is sometimes difficult for executives at the top of the totem pole to recognize the challenges in day-to-day manual processes! That is why it is on the mid-level employees to prove the need for innovation in the day-to-day operations. This article provides five areas of consideration when navigating resistance to changing SCM software systems.
Start the conversation early – identify resistant team members vs. early adopters.
The last thing you want as an employee is for your boss to feel like you neglected to follow the proper protocol by identifying potential software investments without consulting them. Software projects can be substantial investments, both in terms of cost and time, and as such, executive leadership generally wants to be privy to some of these discussions. That said, executives like to have varying levels of involvement in the evaluation and implementation process. It is essential to understand:
- Are your team members and leadership team members generally resistant to change within the business, or are they innovators?
- What level of involvement does your executive team want to have in the process?
To understand your executive team’s level of involvement you may want to have in a systems process, an excellent place to start is considering past sizeable business investments. Think back to a situation such as selecting a new office space or store location, purchasing another software system, or making an expensive executive hire. Who was involved in driving those decisions? At what stages were they involved? What questions did they ask? Who had the authority to say no? What metrics did they use to justify a decision and quantify the ROI?
If you know a team member is somewhat resistant to change, do not leave them out of the conversation. In fact, you should introduce the topic earlier, but you must bring data-backed insights to the conversation to support your proposal.
Quantify your problem statements and leverage conservative metrics when considering ROI models.
If you are considering investment into an SCM platform, you see inefficient processes running rampant in your organization. If people could reallocate time spent in spreadsheets/email back into more productive activities, it would drive meaningful improvements to the business. That observation is not enough to support the need for a new system. You must be SPECIFIC in the problem statements and potential ROI to solve those problems.
As you observe inefficiencies within your organization, it is essential to document your problem statements beyond surface-level. Here is an example of surface-level problem statements vs. a specific one:
- Surface Level: Everyone is operating in silos, and we do not have one version of the truth.
- Specific: To complete our end-to-end supply chain process, our team currently leverages four different systems in addition to email, WhatsApp, and spreadsheets. We have 45 people on our team and observing calendars over the past month; 25 team members spend more than 1/3rd of their time reconciling data across systems, emailing vendors to track down products, and alleviating discrepancies, and correcting errors. At an average salary of $50,000/yr, if we were to drive a 33% reduction in manual efforts for those 25 employees, that would cause a $136k+/yr business impact.
Observe. Document. Quantify.
Value selling has become such a commonplace tactic by sales professionals that it can come across as almost artificial, where the salesperson uses value purely to justify the pricing. Being in sales, I can attest that sellers sometimes leverage value as a tactic to get a deal within a defined timeframe. While that may be the case, talk to your CFO and understand how they make their most crucial business spending decisions. CFOs are well known as being the most calculated and shrewd decision-makers. They welcome value conversations, but they make their own ROI calculator based on their perceived value points at the end of the day. My recommendation is to quantify your problem statements before the sales team does.
Analyze the status quo and consider where time could be better allocated so that when you begin evaluating systems, your initiative has momentum rooted in quantifiable benefits. As you embark on the evaluation, remember the well known saying, “value is in the eye of the beholder.” This statement rings particularly true when considering the value a software system may bring your organization. There are SO many different metrics to harp on when quantifying value, but at the end of the day, the only metrics that matter are ones that will resonate with your team. Below are five general buckets you can consider when modeling a software investment’s potential value.
Considering the above value buckets, take your analysis to the next level by applying hard metrics. MAKE THEM CONSERVATIVE! Try modeling out the power of 1%. A 50% benefit is not believable, and it probably isn’t achievable. Consider the below model as an example:
Consider not just internal stakeholders but also relevant parties outside of your entity/business.
So you’ve done a great job of quantifying your problem statements and have convinced your team to evaluate, that is chapter one. But you also need to ensure that the new system is readily compatible with your existing vendor relationships and processes. If your team feels that the system works well for internal users but is inflexible in working with crucial external business partners, that is a tough sell.
Supply chain business processes inherently involve many different teams across many entities to make products. I wrote an article last month explaining how there is SO much more to supply chain management than cutting a PO in an ERP system. Communication, file sharing, sampling, sourcing, trial production runs, etc., are all high-touch and intricate aspects of executing an effective supply chain. So the new system must work well with your vendors. To understand how interoperable the new system will be with your vendor network, you should consider questions like the below:
- Is there specific training and documentation for the vendor to efficiently accomplish their job with the new system? How long does it take to get vendors set up on the new system?
- How can the vendor continue to run their business seamlessly by having information flow to the new system?
- How does the new system make doing business easier for BOTH parties? How? Is it scalable?
- Is there a specific role/login for the vendor to make doing business easier? Will using the new system lead to less time on manual activities and disparate phone conversations?
- How will the new system make doing business more challenging?
- Are there additional costs for integrating with vendor systems or vendor users?
There is a reason why supply chain management features are limited to purchase order execution in ERPs. It is because there is a monthly cost to have vendors set up users in the system. Companies have to customize a role-specific to them (another expense). There is also a risk associated with vendors entering or deleting inaccurate data. In addition to these additional costs and risks, there isn’t a way to hold the vendor accountable for updating the system. When looking at supply chain management software, you want to purchase a flexible and easy-to-use system that the vendors even want to buy the software to run their own business. It also might help to speak with your vendors and discuss the new system before purchasing. It will help you navigate internal resistance within your team if your vendors are excited about and ready for the systems project.
Understand that no matter what system you select, garbage in is garbage out. Training and onboarding properly is everything.
Garbage in is garbage out – another very common saying in the software world – and it is true! The number one reason digital transformations fail is due to ineffective project teams. Many big companies bite off more than they can chew. My brother has been an implementation consultant at a few large tech companies, and I was amazed to hear that he was often in charge of managing 35+ coterminous ERP projects. How can someone feasibly manage that many coterminous projects knowing the average time to go-live was six months? However, my brother has delivered hundreds of great projects, but is it scalable for one person to drive that many projects? How can you ensure consistent quality?
One way to navigate resistance towards onboarding a new system is by knowing your stuff. If you can speak knowledgeably to the deployment process’s granular elements, you will convince your team that you are well equipped to handle the project and make it successful.
Here are some questions to ask and topics to consider:
- It is imperative to understand the difference between T&M (time and materials) engagements vs. fixed bid statements of work. It is also imperative to understand who is physically delivering the project. Is it a 3rd party offered solution, or does the team that makes the software also deploy it?
- How many hours are in scope for training? What is the training format? Train the trainer, in-person training, online courses/training modules? What materials will be left behind to train future generations of users?
- How long do you estimate our implementation will be from kick-off to go-live? What are the key elements that will make our project longer or shorter?
- How many consultants will be on our project? What is their experience? Can we speak with your project team that will be delivering our project before signing?
- How many coterminous projects will our project manager be delivering?
- How much post go-live support is in scope? If we need to purchase more training hours, what are the hourly rates and the process?
Expect the implementation to reveal other problems.
If you had a dime for every time a software salesperson used the term “best practices,” how many dimes would you have? Probably a whole lot. While the term is undoubtedly over-used, software companies choose to develop their products with best practices in mind. Best practices mean the industry standard. While the software is innovative and, for the most part, is flexible, “customizations” can be expensive. At the surface level, high-cost customizations may drive some people to think the software is rigid. However, if you are looking to purchase costly new software purely to replicate your current process framework, it would be ignorant to expect drastically different business outcomes. As an innovator and catalyst for change, you should be asking your team how we can leverage leading practices to drive more efficient business processes? Of course, some methods are your “secret sauce,” and the new system must handle these processes correctly, but aside from that, it is crucial to keep an open mind when it comes to digitization projects.
Reinventing your business on a digital platform is no small task. As it is such a complex project, some things will inevitably be missed in scoping, or you may have improperly understood the granularity of one of your internal processes during the evaluation phase. This is ok!
Going through implementation is different from evaluation as it is a real transformation. It is more granular, and you genuinely leave no stone unturned before you go-live. When you are implementing a SaaS product built on best practices, implementation is an opportunity to reinvent your business in some capacities and double down on the already efficient processes. You may learn that you can cut out extra steps in a process or learn you need to add another step to have necessary controls/approvals in place. You may discover that hundreds of your industry peers manage a particular process differently from you and that changing your process will drive better adoption of the new system and better business outcomes. You want to identify as many of these process changes before purchasing software so that there are no eyebrows raised. However, there will inevitably be some process change with any software project.
Conclusion
It all starts with knowing your sh**! Be prepared for every conversation. Analyze the business and ask lots of thought-provoking, specific questions on every call with every software vendor you are considering. More specifically:
- Start the conversation early with the right people.
- Bring business metrics to the table early and quantify the business problems and the potential efficiency to be gained.
- Ensure all parties internally and externally are better off with the new system. At a minimum, have a plan for all of your participants.
- Ensure training and implementation services are more than sufficient. They are generally one-time costs anyways, so spend more to get it right the first time.
- Expect that no matter how detail-oriented you were in the evaluation, you can’t overturn every stone until you live. Benefit from leading practices but know where you can’t compromise.
Bobby Hamill is the VP of Sales at Suuchi Inc. With over five years experience at Netsuite, Bobby leads the Suuchi team to help hundreds of businesses take the first step to a digital future for their supply chains. Learn more about Bobby.
