Supply Chain Problems, No. 2: Why is Buying Supply Chain Software So Hard?
Co-authored by Brittany Brown & Suhas Sreedhar
Welcome to Supply Chain Problems, the series where we look at some of the messiest issues in supply chain today.
Issue #2 – Why is Buying Supply Chain Software So Hard?
While trying to solve your supply chain problems, you might occasionally come across a promising solution in the form of software. But the process of buying and implementing a supply chain software solution can be surprisingly difficult, especially within the context of an enterprise. Why is that?
Well, we often talk about how there are many stakeholders in the global supply chain that need to align for the entire system to work successfully. The same holds true within an enterprise. When it comes to purchasing supply chain software, there are many stakeholders who each have their own priorities and metrics to satisfy. This can easily lead to a misalignment of incentives, and stalled progress.
To make headway, it’s important to know who’s involved. But it’s even more important to understand what they want. Let’s take a look:
The Business. Tasked with solving supply chain problems, the business is the focal point and driving force behind the evaluation and procurement of supply chain software. This group stands to benefit the most from implementing a solution, but also takes on the lion share of responsibility and risk. The business has spent countless hours:
- Defining what improvements are necessary and determining their correlated value
- Assessing the scope of the project (across regions, business units, and departments)
- Outlining the requirements of a solution
- Evaluating multiple solution providers
- Awarding the business to a provider
At times, the business can get tunnel vision, not seeing the other stakeholders and departments that need to be involved when purchasing a software solution. Coordination with these other parties is vital, and if done well, can greatly increase the chances of a successful project, implementation, and relationship with the chosen vendor.
IT Department. IT is usually the gatekeeper for all technology-focused enterprise projects. This team is heavily involved in the evaluation and buying of software. This is because the IT department will be responsible for implementing the solution. Because of this, IT tends to be skeptical about solutions, serving as a technology-feasibility check for the company. At a high level, their responsibility is to:
- Understand the business purpose and value of technology
- Recognize how current systems and processes fit with the solution
- Implement the solution on time and preferably under budget
- Ensure security and compliance
This is a tall order. Getting IT involved early can avoid nasty implementation issues that can take derail a successful business solution. But it isn’t just IT that needs to be involved. Other stakeholder departments also interact with IT and the business and are critical to a successful deployment.
Finance. Finance controls the purse strings of the entire enterprise. Software projects require funding. Whether the funding is budgeted to IT or the business, there are stiff requirements to ensure the project/software will have positive financial implications over a specific period of time. Cost, ROI, NPV all become the factors by which finance evaluates a project.
In a SAAS (Software as a service) model, there are at least two funding requests:
- Capital expenditure: Implementation of software is a onetime cost and budgeted to IT.
- Operating expenditure: The subscription is an ongoing cost and is considered working capital and budgeted to the business.
The overall financial priorities of the enterprise can easily affect any software project, so it’s better to be aware of this in order to reach an optimal solution.
Legal. You’re going to need a lawyer. It is the job of your lawyer to provide legal and contractual protection—from both well-known scenarios, as well as important, unforeseen, and unlikely scenarios that could threaten either party. For your lawyers, a successfully negotiated contract safeguards the company and its interests in all dealings. The most common legal documents to focus on include:
- General terms: Most companies have a standard template for contracts with vendors. However, most vendors also have their own standard templates. The legal teams of both parties should compare templates and determine which will require fewer changes for the specifications of the project, and use that template as the foundation for the contract.
- Commercials: These are the negotiated terms of the agreement. How long is the contract, when does it start, what’s the fee, what are the payment terms, etc. The business negotiates these terms with the help of procurement, but legal will need to have final say to ensure continuity and agreeability.
- Statement of work: The statement of work is agreed to terms for implementation that IT and the business will have responsibility for. Again, legal will have final approval.
Procurement. In the buying or procuring of software, it's only logical that the procurement department would be involved. This group takes an objective and methodological approach, and becomes very heavily involved towards the tail end of the process. Some may even call this group ruthless, because one of their main objectives is to secure the best deal possible—they are stern negotiators. Due to procurement's objective nature, and their intimate understanding of the project-approval process, their early involvement can move the process forward more expeditiously.
Building Bridges is Hard, But Worth It
As we’ve learned, buying supply chain software is hard because it can be an intimidatingly complex process. There are many parties involved, and each have their own priorities and interests. Sometimes, their priorities clash. It’s kind of a given that all parties need to negotiate and compromise to reach an optimal solution. But most enterprises aren’t set up to collaborate rapidly across many different departments. That’s where things get stuck. So here are some best practices on how to build bridges to make the buying process run much smoother:
- Have a liaison role: Whether done in an official capacity or not, having a person responsible for understanding, via direct contact, the agenda and objectives of all parties helps the process move forward with all perspectives considered.
- Create a Center of Excellence (COE) or Continuous Improvement (CI) department: The continued growth of COE departments is partially a result of challenges like those outlined in this post. Just like a supply chain, companies often operate in silos even though there are necessary interconnectivities and dependencies. COE departments can find synergies, cost savings, best practices, and innovations that normal siloed approaches miss out on.
- Take a holistic and methodological approach as early as possible. Even before selecting a vendor, define a process for evaluation that considers all the stakeholders we've mentioned. Some examples include:
- Reviewing your IT Footprint and roadmap. Before evaluating new software providers, ensure you understand the current ones. How will this new software overlap, interact, or complement the current systems in place today? IT will surely be able to help you with this, and would appreciate the foresight.
- Facilitating discussions early and often between your IT departments and the vendor’s implementation team. Ensure the methodologies align and can be mutually agreed to.
- Requesting the Master Services Agreements of your possible vendors during the evaluation. This would allow your legal team to review and highlight any red flags well in advance.
- Understanding the metrics necessary for an approvable project with finance. Even before the evaluation, make sure you know what financial levers matter to your CFO.
- Reviewing the project plan, purpose, and process with procurement. Get their feedback. Procurement might offer some advice that mitigates possible roadblocks or hurdles.
- Being global, if applicable. Take global consideration where necessary. Software and technology have removed the boundaries from borders. Supply chains today are typically global. Make sure you're incorporating the goals, systems, hurdles, and specifications of your cross-border cohorts.