TRYON BLOG
Steps to Outsourcing Your WMS Service
What is the current internal process when your team is in the market for supply chain services? Do you have everything start-to-finish down to a science, or simply mash speed dial and talk to your “go-to guy” or “go-to gal” at The International House of WMS Guru-Sages?
Maybe you just need some application support, or perhaps your Warehouse Management System needs an upgrade or replacing altogether. Regardless of exactly what’s needed, you must carefully organize the requirements and goals, thoroughly hone the project scope and deliverables, and – arguably most critical – is being deliberate and diligent throughout the process of acquiring a provider.
There are a wide variety of scenarios that we come across with our supply chain customers, but let’s look at the three most common:
Scenario A
Your team handles everything related to the project, and strictly outsources production support. Smaller companies with limited resources would be well advised to consider Scenarios B or C instead.
Usually reduces cost, and its empowering and often easier having the knowledge in-house. Also, no one knows your needs more specifically than your own personnel and so nothing is lost in external communication. |
Requires engagement, focus, and no rear-view distractions. The required bandwidth is usually underestimated, as personnel are easily overworked handling their normal duties plus project workload. Users want ALL the features, and so the team also needs to take care not to bite off more than what’s chewable as well as scope creep during the project. |
Scenario B
Your team runs and oversees the project at the top level and certain functional areas, but the technical execution is outsourced. This is a common route for most Tier-2 (or mid-size) companies.
Potential for a healthy balance of involvement while not consistently tying up your team who have their daily duties to perform. |
Potential for not feeling involved enough or conversely feeling overly entangled and busy, and the chances of either happening is directly related to the quality of the provider you are working with on the project. |
Scenario C
Everything is outsourced. This situation is the result of the company not having the required knowledge in-house and/or there is simply no bandwidth for any level of involvement in a major project. Smaller companies may not have any other option. Outsourcing an entire project can be perceived as having a higher initial cost, however, nothing drains the company coffers more directly and indirectly than a bungled and/or “seemingly never-ending” in-house project.
Allows for maximum focus on daily business operations, and biggest potential ROI if you have selected the right provider. The project should also be finished more quickly, as external resources are more focused and scalable. |
Requires crystalline understanding along with the precise relaying of requirements and end goals with detailed documentation, and a high level of trust in your supplier who must smoothly handoff the project to your team. |
Let’s look at a rough outline of the steps involved before actually tackling the project and engaging with a supplier:
Step 1
Regardless of which of the above scenarios applies, your team will need to understand the requirements and document them when hammering out the overall scope of what needs to be done. Our previous blog post on Go Live Nuggets of Wisdom may come in handy, so feel free to check that out – along with our other articles.
A big question these days is whether to go SaaS/Cloud or on-premise. Should you have a basic setup and want to keep things in-house, consider going on-premise. If your company must be up-to-date and compatible with the latest technology, then you should consider SaaS – BUT your provider needs to have fast-responding, quality support and they will have to put your cybersecurity folks at ease that all of the involved data is extremely secure. The age-old question must of course also be addressed: What is our budget and timeline?! Both can instantly eliminate potential suppliers and/or what work is done.
Other key considerations for this initial “requirements and scope” stage include:
What problems are you facing with your current system? Consider that you are fixing right problem(s) the right way. For example, ERP integration issues may not be resolved via a WMS upgrade.
What does the current and future market situation look like? For example, due to labor shortages and related supply chain issues should you look for opportunities to increase in automation?
Do you need to integrate with other systems and applications?
Is this a good time to replace dated, legacy technology?
What are your customer competitive options?
What features must you have and what would be beneficial to have?
If the system has to be taken down, when is most ideal? Will our project bleed into peak season?
Step 2
Now that we have ironed out some basics, let’s clearly define goals and deliverables. Work with your top project manager to best hammer this out. We should be as detailed and specific as we can; ambiguities often result in potentially costly Change Requests and time-wasting.
The provider/supplier selection process is absolutely critical. It should as meritocratic and unbiased as possible, and involve quotes from at least three providers. Rank experience, references, and key differentiators (which line up with your needs) highly. A long-time supply chain veteran I know ranks “quality, delivery, and reducing cost” in that order. At the very bottom of the list should be how well you were “wined and dined”, as too much money and livelihoods are on the line to give it to whomever gives you the best night out.
Step 3
Depending on which scenario above is in play, you should be clear-cut and defined on the desired outcome(s) with the supplier – and the importance is even greater if your supplier is handling most or all of the project.
Contractually a time-and-materials SOW may be best suited for the effort undertaken, or perhaps a fixed-bid contract may be a better option to consider in the case of a very specific desired outcome.
When drawing up the contract, include the following:
Strawman project plan
This is a rough outline of a plan that’s open for critique and discussion, and designed to have its failings/holes filled in by your team including those who have strong convictions as well as devil’s advocates. No one is selling this as a THE solution, as its primary purpose is to get both you and the supplier engaged and offering input and ideas.
Resource plan
A resource plan (or resource schedule) dictates which team members get what tasks, based on their skillset, availability, and overall fit. The project manager would use this to track utilization rates, capacity, budget, and timelines – and analyze overall progress.
Clearly defined roles for customer and provider: RACI (or RACI-A) Matrix
A RACI “responsibility matrix” maps out every task, milestone or key decision involved in completing a project and assigns which roles are Responsible for each action item, which personnel are Accountable, and, where appropriate, who needs to be Consulted or Informed.
Its likely you are familiar with project and resource plans, whereas the equally useful “RACI matrix” doesn’t get its due press. You can get very specific with the accountability in these charts, down to the project role is common, but let’s look at a high-level example of a RACI Matrix for upgrading Terminal RF to Mobile scanners for the receiving team at a loading dock:
RF-to-Mobile Upgrade Project Phase
|
Key Milestone/Task | Customer | Provider |
Initiation | Project intro and kickoff | Responsible, Accountable | Consulted, Informed |
Document requirements | R, A | C | |
Budget verification | R, A | C | |
Deliverables and scope approval | R, A | C | |
Design / Plan | Initial compatibility check | I | R, A |
Additional custom menu design | C | R, A | |
User acceptance test | R, A | C | |
Overall plan review | C | R, A | |
Develop | Backup all config files | R, A | I |
Create custom menus | I | R, A | |
Install necessary software / hardware | I | R, A | |
Performance check to parallel system | I | R, A | |
Verify remote access control | C | R, A | |
User training/re-training | R, A | C | |
Mobile receiving w/ real world data | C | R, A | |
Mock Test | Receiving regression testing | R, A | C |
Edge case testing | R, A | C | |
Performance test | R, A | C | |
Go Live | Go live – all containers at loading dock | C | R, A |
Support | Ongoing 24/7 help desk | I | R, A |
List of Deliverables
The project deliverables can be spelled-out as part of the RACI-A Matrix or detailed outside; be specific in terms of outcome and timeline.
Feel free to drop us a line if you have any questions, or feedback on this post! We are a reseller of Blue Yonder WMS, and provide the full gamut of related WMS services.
Written By James Prior
With over two decades in software pre-sales and implementation, James specialized in working with the sales teams and contributed to blog posts. For further information, please email sales@tryonsolutions.com.
More From This Category
A Guided Tour of Supply Chain Execution Systems
Supply Chain Execution (SCE) systems are behind the process workflows of goods going from...
Performance Testing Your Warehouse Management System
We’ve made the case for automated testing in various blog articles with a regression testing...
Top 5 Ways You Could Botch Your Next WMS Go Live
Are things running too smooth? Have you had it too easy in the supply chain world these days,...