Both the digital transformation and each software provider are multi-faceted, so think of these next stages of the discovery process as ‘peeling back layers of the onion.’ The surface layers involve understanding each vendor’s capabilities and bid components. Slightly deeper are the back-end particulars of the transformation; your team will be focusing on everything from the platform to the financial and commercial terms to ensure the products and services you choose align well with your priorities and that the rollout will be feasible and smooth.
The Vendor Discovery Process
To make the most of our kick-off meetings, my team and I would use the opportunity to both cover our purpose and goals, as well as get to know each software provider individually. We would host a group meeting in the morning with all the vendors to lay out our project, plans, and shared vision, followed by an open question and answer session. This is as much of a chance for them to get to know us as it us for us to get to know them.
In the afternoon, we would schedule one-on-one meetings with each software provider, where they would typically give an overview presentation about their company and its capabilities and ask questions they prefer to discuss privately. After conveying what needs to get done in the first session, these more intimate meetings help create a first impression of what each candidate can effectively contribute to those goals.
I’ve also preferred a two-step vendor discovery process: “information gathering on capabilities,” or the Request for Information (RFI), followed by “quoting/bidding” or a Request for Proposal (RFP). The two-step approach takes longer, so it’s common to combine them into one step if time is short. However, by paring down prospective vendors after the RFI submission, there will be far fewer vendors to have to manage and evaluate.
The Layers of Team Engagement
After the kick off, the work begins in earnest. While the vendors pull together their respective responses to the bid document, your team members will be fully engaged, each with their own point of focus.
Finance
Your controller or FP&A person will need to assemble the necessary information to construct the financial schedules for the project’s business case and subsequent management approval. In general, they’ll be looking for:
- How the vendor charges for use of their platform. (license, perpetual, annual, named users, per “click,” tiered volume)
- The timing and release of progressive payments. (what are the milestones and what constitutes acceptance?)
- Possible hidden charges. (At the start of a project, I once received a vendor’s first travel and lodging expenses invoice for approval only to realize that we hadn’t considered whose expense policy guidelines would apply, ours or the vendor’s. In this case, their policy was more generous and the difference notable. Know your vendor’s travel policy, standard charges, hourly rates, fees, and professional services fees beforehand.)
- Any payments to third parties. (Some implementations require links and other software to function. Understand what other software licensing is needed, like tax calculators, logistics routing or costing services, middle-ware, API providers, sequel server, or database, integration with e-commerce shopping cart platforms).
- The process for handling billing disputes.
Operations
Operations typically drives the commercial terms found in the Scope of Work, Service Level Agreement, Exhibits, and Attachments. Depending on the size of the team, you may also want to involve a business analyst. This branch of the team will cover:
- The projected outcomes of the digital transformation. (i.e. productivity gains and better efficiency, time compression, transaction flattening, freeing up capacity, working capital, increased internal or external synchronization, better OTD to Promise or to Confirm, increased inventory turns, more accurate demand-supply matching, Perfect order compliance).
- How to establish baselines and measure positive change.
- The type of information they will receive and how to leverage it to improve results.
- Descriptive – What is happening/has happened?
- Diagnostic – Why is it happening?
- Predictive – What will be the impact?
- Prescriptive – What should be done about it?
- Where this information best plugs into the workflow to make a difference and realize the expected benefits. (We’ve all seen value-stream maps identifying areas that took weeks to perform only minutes of work. To unclog the backups caused by such inefficiencies, the ops team must figure out how to use the data from your digital transformation.)
IT
The hard crunch happens here. Some of the numerous points of focus will likely be:
- What software platform or tools will be used, and whether they are proprietary or open source.
- The support obligations.
- How the vendor approaches incident management, severity, notice and response, and the escalation process.
- The vendor’s upgrade cycle and maintenance standards.
- Whether modifications and customization would be necessary. If so, whether they’d be implemented automatically and without additional expense with future base releases.
- Who will be able to make changes, as well as the change management process.
- The QA & test process.
- How the vendor ensures data integrity.
- How they handle aspects like cyber security, load balancing, and intrusion detection.
Sales / Business Development
The sales and business development team’s main purpose is to understand the benefit of this digital transformation, craft the value proposition, and then sell it, as the case may dictate, either internally or to clients.
Articulating the benefits and how they differentiate you is not as easy as it might seem. Here are some of the points to examine:
- How the transformation affects current and prospective customers in terms of cost, quality, service, or delivery.
- Whether the implementation will improve your margins. If so, whether you should keep the additional profit or share it with your customers.
- Whether you can articulate a unique selling proposition, and if it will be sustainable.
- Whether the project is a defensive move for customer retention or an offensive move for customer acquisition.
- Whether you should charge extra for these benefits or bundle them without charge as added value for a competitive advantage.
- How easy it is to communicate and demonstrate the benefits or if selling it will be complex.
- Whether current customers have been apprised of your plans and their thoughts on the matter.
Legal
The legal work typically focuses on the “boilerplate” language while the actual “deliverable details” are prepared by the ops and IT people in the Exhibits and Attachments sections. They’ll investigate:
- Whether the sample contract, service level agreement’s construction and form, and typical exhibits look favorable.
- Any issues regarding indemnifications (I would insist on reciprocal indemnifications), warranties, non-solicitation, jurisdiction (like settling on a mutually agreeable territory), acceptance terms, confidentiality, ownership rights, liability limitations.
- The terms and termination conditions.
- Whether the platform can be used for multiple clients and/or their customers.
- What happens if there is a change of control or insolvency of either party.
- The form of the data and who will own it.
At this point, remember to judge the prospective software providers against your wants and needs list. After the team fleshes out these details and receives the RFI/RFP responses, the following stage of the discovery and due diligence process will be the test drive. Next in the series, we’ll discuss how to put prospective providers through their paces.
