Supply Chain Management Software Selection Best Practices

Fail the supply chain management software selection, and the subsequent implementation will be assuredly challenged. Here are some supply chain software selection best practices to help plan your effort.

Define the SCM Initiative

Supply Chain Management software projects are usually driven by an organization’s needs to become more competitive and therefore are initiated at the highest levels of an organization. At this point, an executive sponsor and project manager are needed to define the purpose and scope of a project. These individuals also need to articulate the project vision, identify all stakeholders, assemble a project team, get representation from every affected group and kick off the project with a requirements study.

SCM Requirements Study

Will you need a consultant to assist with the requirements, because of the complex and nuanced nature of business and software requirements? Supply chain strategies and supporting requirements will vary based on many factors. An example of three different supply chain strategies include the following:

A jewelry retailer focuses on style and the customer experience of buying jewelry.

Supply chain management practices in other industries focus on short product life cycles, postponement strategies (to be more responsive to shifts in trends) or build-to-order.

Without an in-house expert experienced in the nuances of Supply Chain Management strategies, a consultant should be considered in order to help flush out and articulate a detailed strategy with supporting requirements.

Business Strategy and Vision – Documenting the prioritized reasons for the SCM initiative is good starting point for putting together a business strategy and vision. Examples of reasons driving the new initiative could be improving financial performance, growing market share, a new line of products, an acquisition or moving manufacturing offshore.

Reviewing supply chain software is an ideal time to also review business processes. Changes to the business such as process changes and new functions should be documented along with the expected improvements, and because process changes can incur user resistance, they should be accompanied with a change management plan.

SCM Model – Starting with a Key-Stakeholder-Analysis that includes individual areas of strengths and areas of improvement helps to create a plan for collecting critical information for formulating business requirements.

A detailed evaluation of what drives demand and what constrains demand (such as value, suppliers, products, competition, channel partners and regulations) is critical. Workshops or brainstorming sessions are a common method to identify these requirements.

At this point, it is highly advisable to look outside the organization for new ideas and to validate the SCM model and requirements.

Limits – Approval for a budget and a commitment of organizational resources should be reviewed and approved.

Planning

Project Charter—A project charter establishes the framework for the supply chain software selection and subsequent implementation. The vendor selection project charter should have all the standard information: project team, stakeholders, objectives, requirements (from the requirements study), scope and budget. To start formulating the big picture, the charter should be written to address both the selection and implementation of software; the charter is not etched in stone and can be revisited at anytime for updates.

Training—The project team should get training on the capabilities of modern Supply Chain Management systems. Between the Project Manager and outside consultants, there should be a large enough pool of knowledge to cover the basics. Industry seminars, software demos and site visits to companies that have already implemented SCM systems is another good training tool.

Kicking off the project with an initial presentation of features from the different vendors can be a valuable educational tool to update the team on state of art SCM systems.

Vendor Research—Collecting detailed data on the supply chain software vendors and organizing the data by categories and requirements is critical to an objective evaluation and selection process.

At some point, the project team needs to decide which software approach to use: Best of Breed or Single Integrated System approach. Best of breed vendors typically offer most robust functionality, but require customers to perform significant system integration to other business systems. Supply chain management vendors are continuously expanding their line of products making the single integrated approach a more common option. A third approach to consider is whether to use one vendor for supply chain execution (SCE) and another vendor for supply chain planning (SCP).

A Gap Analysis based on the most important requirements, will reveal which vendors should be short-listed and considered further. At this point, it might make sense to narrow the list of vendors to no more than three.

Supply Chain Software Vendor Selection

Evaluation—Ground rules for software vendor presentations should be established by the team. A supply chain software selection best practice is to use scripts which require the vendor to illustrate your most important or most difficult business processes during the demo. After each presentation, demo scores should be totaled and team meetings should be held to discuss pros, cons and items not addressed in the presentation. After each presentation, a follow-up call may be needed with the vendor for clarification on any open issues.

Vendor Selection—The project team should revisit the Gap Analysis to provoke constructive dialog towards a consensus on which vendor to select. A weight can be given to each requirement from "must have" to "can live without" and a value is given to how well each vendor meets the requirements.

If a consensus for the preferred vendor cannot be reached, consider a super majority. As a last resort, two vendors can be selected for a Conference Room Pilot (CRP) and a decision can be made based on the CRP results.

Conference Room Pilot

The conference room pilot (CRP) validates the decision and identifies implementation planning issues. Using a demonstration version of the vendor’s software, the team takes a simulated walk through the key processes. As issues come up, potential resolutions are documented.

CRP Planning—A CRP owner, without a vested interest in the outcome, needs to be chosen. The owner develops the CRP plan and processes including the structure for conducting the CRP meetings, the objectives for each meeting, equipment and facilities, IT support and rules. The CRP Owner will solicit help of subject matter experts (SME) to define the key SCM processing scenarios based on the SCM model and requirements. For each vendor, CRP schedules are set.

Develop Process Scenarios—For each processing scenario, the assigned SMEs will diagram current business process flows and the To-Be flows. The diagrams should have a representation of both product and data flows. Relevant collateral information supporting the diagrams should also be included.

Conduct CRP—The team is walked through each business process from start to finish. Open issues are listed and appropriately documented. Depending on amount of time available and the interest at the group level, the issues can be addressed during the CRP or a meeting can be scheduled after the CRP to address open issues.

Post CRP—Open issues not satisfactorily resolved during the CRP are updated as implementation issues. These open items will be evaluated for re-configuration, work-arounds or software customization.

Finalize Vendor Selection

Contracts—The CIO is a key stakeholder and generally experienced in teaming with a business leader and legal council when negotiating software vendor contracts. The CIO should be involved early on in the selection and take the lead role in negotiating technical terms and services such as implementation support, service level agreements, licenses and maintenance fees and access to source code.

Administrative—The requirements and project charter documentation should be reviewed and updated with approval for any changes. An implementation schedule with roles and responsibilities allocated between the vendor, the customer and third parties (such as system integrators) should be agreed upon before the supply chain purchase contract is complete.