Archives for June 2016

E-Commerce Fulfillment Scenarios Driving Today’s Businesses, Part 2 of 2

By Ian Hobkirk | 06/28/2016 | 3:53 AM

In Part I of this two-part blog post, I explored three different e-commerce scenarios currently being used by manufacturers and retailers:  Manufacturers Filling E-Commerce Orders Directly to their Consumer Clients; Manufacturers Filling e-Commerce Orders on Behalf of Retailers Scenario; and Pure E-Commerce Retailers. In this blog, Part II, I’ll outline three additional scenarios.


Scenario #4: Multi-Channel or Omni-Channel Retailers

Omni-Channel DiagramMulti-channel or omni-channel retailers (i.e., those with a retail or wholesale channel in addition to direct-to-consumer) require a combination of several strategies to address their e-commerce needs. Like the manufacturers from Scenario #1 (covered in Part I of this blog post), multi-channel retailers can regulate their levels of e-commerce, and make the transition into this channel more gradually. Among this group, there are a number of strategies which have been used successfully, depending on the nature of the demand.

This was an early strategy in response to the e-commerce shift, and it’s still practiced more and more every day as traditional retailers become omni-channel companies. Consumer orders are sent to the nearest retail store for fulfillment in order to reduce freight costs and improve service levels. However, in most instances, store associates are not well trained in packing and shipping processes. Picking e-commerce orders may be viewed as an interruption to the normal day’s work and priority may not be given to making timely shipments. The customer experience may vary greatly depending on the store from which the shipment is made. It is important to note that in the age of omni-channel, many retailers are making “ship-from-store,” a focus and investing in the technologies and training required to perform this function efficiently.

Some companies have adopted a hybrid approach which involves filling e-commerce orders from the distribution center as a matter of practice, but only if sufficient inventory does not exist in the distribution center (DC) to fill the order from a local store’s inventory as a last resort. This practice allows for some centralization and control of e-commerce orders, while still leveraging the store infrastructure as the last line of defense to ensure good customer service.


Scenario #5: Companies Outsourcing the E-Commerce Channel

Some companies determine that e-commerce logistics simply does not integrate well into their supply chain infrastructure, and choose to outsource this distribution to a trading partner. For example, many retailers choose to outsource portions of their e-commerce to vendors, having them drop-ship orders directly to their consumer clients. While not alleviating the need for handling direct-to-consumer shipments, a percentage of the distribution center’s volume can be reduced by using vendors in this fashion. Additionally, the retailer does not need to purchase and stock inventory in advance and can realize a real benefit on the balance sheet.

Retailers choosing this strategy are often able to offer a much broader array of items to the general public, as they are not restricted to SKUs which are physically stocked in their distribution centers. Sometimes these SKUs can be offered at a lower cost, since the retailer is not burdened with the need to stock inventory and handle it multiple times.

However, retailers choosing this strategy are highly dependent on their suppliers’ ability to fill these more complex orders. Many of their suppliers may be accustomed to filling large, palletized orders to retail distribution centers, and may struggle with the ability to pick individual items and pack them. Additionally, for retailers that offer a broad selection of SKUs from multiple vendors, this strategy can lead to consumers receiving several shipments for the same order—each originating in a different location. As a result, the consumer experience can be less consistent.

Other companies choose to outsource their direct-to-consumer commerce to a third-party logistics provider (3PL). This can relieve some of the complications of using vendors or other retailers to ship orders, where the fulfilling party may be less than motivated to ensure good customer service. Many 3PLs specialize in high-volume piece-picking and parcel shipping, and are able to handle these orders quickly and efficiently.

In addition, a 3PL’s business consists of filling orders on behalf of others, so they may be better versed in the rigors of specialized labeling and packaging. 3PL contracts can be structured around attainment of certain customer service levels, so the client is able to ensure high levels of service to the consumer. Lastly, some 3PLs have multiple distribution centers, which allow a company the flexibility of utilizing different distribution points as their e-commerce ramps up.

It’s important to note that not all 3PLs are created equal. Many began life as simple public warehouses, better suited to basic pallet handling than the intensities of piece-picking and packing. In addition, many smaller 3PLs have made a surprising underinvestment in basic automation such as real-time warehousing and packing technology. Companies considering a 3PL should engage in a thorough selection process to ensure that they choose a competent partner.


Scenario #6:  3PLs Specializing in e-Commerce

A wide variety of 3PLs offer ecommerce services. Some focus exclusively in direct-to-consumer orders, while others only dabble in it to help their customers whose primary business consists of pallet or case handling. The issue here is that managing e-commerce distribution requires a very specific set of capabilities and enabling technology. In some cases, 3PLs that offer e-commerce but that do not have a defined roadmap for improving efficiency do their clients a disservice, and risk losing their business entirely.

Even if a 3PL doesn’t specialize in e-commerce, it will almost certainly need to offer it on some level or risk losing its core client base. Due to the unpredictability of short, two-to-three year client contracts, most 3PLs are reluctant to invest in large amounts of specialized automation that cannot be easily adapted to other clients’ needs. However, a certain basic set of requirements such as real-time warehousing and an effective forward pick area must be adopted in order to have any credible e-commerce program. A handful of software vendors offer WMS systems that are tailored to the 3PL industry, with features like accessorial billing and tracking ownership of inventory. A modern, web-based WMS can also be an excellent tool to give clients real-time visibility into the status of orders and workflow. (Check out: SaaS WMS – A Look Under the Hood, to read about some of the strengths and weakness of web-based WMS systems)

Finally, 3PLs should initially be selective about which e-commerce accounts they choose to pursue. Starting up a new account can be like driving up a cliff—there is often no gradual ramp-up period. Offering e-commerce to existing clients and gradually introducing automation may be a sound strategy for 3PLs seeking to support this type of order fulfillment.


Now that I’ve explored the various contexts under which companies must fulfill e-commerce orders, my next blog will address the reasons why these orders can present such a challenge in the distribution center.  Stay tuned.

The GPS to WMS Part 6 of 6 - Teamwork, Communication and Status Reports = WMS Success

By Ian Hobkirk | 06/09/2016 | 6:34 AM

This blog is the last in the "GPS to WMS" series and I am wrapping up the discussion on the topics of communication and teamwork. Without effective communication among team members, warehouse management systems (WMS) implementations can unravel pretty quickly and wind up costing shippers more time, money, and effort than they originally allocated to the project. Put simply, there is no substitute for clear, crisp communication—from the point of software selection until it’s up and running…and beyond.


Why Communication is Critical

Two trends have made team communications more important than ever:  the increasingly diverse workforce and the expansion of personal technology.

We’re living and operating in a real-time world, where project teams encompass dozens of people using a myriad communication tools. For one professional, a text message carries the same importance as an email; it’s just an alternate means of communicating. But to another worker, the text may not be viewed with the same level of importance as an email. Establishing a common understanding of how the team is going to communicate is critical to the success of the project. “I didn’t get your text,” could mean a delay in the project.


Project rhythms—or the establishment of standing meetings and documenting processes—are another critical component of WMS implementation success. You can use status reports, status meetings, stage gate reviews, functional reviews, design reviews, testing reports, and readiness reviews to enhance and support project rhythms. These meetings should be defined in the Integrated Project Plan, with meeting invitations sent to all attendees. Distribute document templates and other collateral materials in advance to help members prepare for the meeting.


The Value of the Status Report

When it comes to documentation, the best WMS implementations rely on status reports to keep tabs on progress and anticipate possible delays and other issues. Some status reports are very short and to the point, while others are very long and detailed. I tend to skew toward the short and sweet side, and I like using color codes to indicate the status of project categories (i.e., risk, financial, schedule, etc.). Going a step further, be sure to have project managers and team leads fill out status reports for their respective areas and then present those reports at status meetings. Finally, the document that gets distributed to senior management should include a page for the overall project status and then the status of each work stream (e.g., IT, WMS vendor, distribution, etc.).


It’s important to note that if you’re using this status reporting method, you must come to an agreement with the other report contributors on how project issues should be determined and reported. For example, does a one-day slip in one work stream mean the overall project goes from on-time to behind schedule? You need to report a fair view of project status, but if you get too granular, you may run the risk of only reporting problems. Not granular enough, and potentially major issues could be overlooked.


Managing Individual Task Assignments

Individual task assignments should flow out of your integrated project plan. If you use Microsoft Project, for example, it’s easy to assign resources to tasks and then print or email a report of individual task assignments. The project plan needs to be a living document that is continually updated and distributed among team members. Throughout the WMS implementation process, be clear on how the plan will be updated and by whom.


What’s the PM’s Role?

You can’t have a conversation about good teamwork and communication without mentioning the important role that the project manager plays in the process. I’ve had many discussions over the years with individuals regarding the skillset for the project manager. In my mind, the project manager should be person who has lived through multiple cradle-to-grave WMS implementations. This is critical because the project manager is the one person responsible for the integrated project plan and he or she is the only person who can look across all work streams and see if all tasks have been included in the plan.


In this "GPS to WMS" series,  I’ve provided insights into what you can do before you sign on the dotted line with your chosen WMS vendor to minimize cost or schedule overruns, how to structure your team and what skillsets to include, the pros and cons of the different implementation methodologies, and how to create project management tools to drive communication, set expectations, and stay on track for an on-time go-live. Additional resources on the topic of WMS that might interest you include:


Presentation: WMS vs. WES vs. WCS - Sorting out the Truth from the Hype

Whitepaper: Selecting the Right WMS

Whitepaper: Six Tips to Avoid a Failed WMS Implementation


The GPS to WMS Part 5 - WMS Implementation Approach: Classic Waterfall or Rapid Deployment?

By Ian Hobkirk | 06/07/2016 | 11:22 AM

Every Warehouse Management System (WMS) vendor uses its own WMS implementation approach, with most opting for one of two basic options: Classic waterfall or rapid deployment. In this blog, we’ll look at both and help you decide which might be the best fit for your company.


WMS Implementation Approach #1:  Classic Waterfall

The waterfall methodology is the oldest and most popular project methodology. As you can see in the diagram below, it’s a sequential process that begins with a determination of the requirements for the project and ends with a “big bang” go-live.


These projects typically have discrete milestones or “stage gates,” that come with predefined timelines. The typical stages of a waterfall style project are:  requirements definition, detailed design, coding and/or configuration, testing, training, and deployment.


As you can see, this is a linear methodology, which means decisions or misses that occur early on can negatively impact later steps. For example, if a critical interface message design was missed and not discovered until testing, deployment must be delayed until the message is coded and tested.


Figure 1: Classic Waterfall Methodology

Classic Waterfall WMS Deployment

WMS Implementation Approach #2: Rapid Deployment

Think of the rapid deployment implementation as being circular or “trial and error” in nature. As you can see from the diagram below, this methodology begins with installing the WMS and immediately training a core group of client users. Depending on how closely the base implementation meets its operational needs, the company may decide to immediately go live with the system or may decide to build/configure additional functionality.


By using the system, the client determines what it needs and when to deploy it. Thus, we typically see a series of discover, build/configure, and test cycles. It’s important to note that the rapid deployment model dictates that the new WMS must operate in parallel with the company’s current processes or systems. That said, if any major problems occur during deployment, the operation can easily fall back on its existing systems while those issues are cleared up.


Figure 2: Rapid Deployment Methodology

WMS Rapid Deployment Methodology


Two Paths to the Same Goal

Both classic waterfall and rapid deployment implementations achieve the same goal, yet they take different paths to get there. Most IT departments I’ve worked with are comfortable with the waterfall methodology but less so with the rapid deployment methodology. This is something to be aware of because if problems crop up between the vendor and company’s IT department, for example, project time lines may be extended and additional costs incurred.


Of the two different implementation options we’re discussing here, classic waterfall is most easily understood and accepted in IT organizations. It’s also easy to communicate milestones and track costs. Thus, when building the team and outlining task responsibilities, it is easier to define when certain tasks should start and to estimate timelines.


The drawbacks to the waterfall methodology are twofold. Along with the misses that can interfere with timeline and cost, there is typically a high upfront cost before the organization starts to get a return on investment (ROI). This cost may be too much for small companies to bear, forcing them to turn to rapid deployment.


The major benefits of the rapid deployment methodology—an approach that’s often used by cloud-based WMS providers—are lower upfront costs and a shorter time to value. The downside is that the functionality is not fully assessed and documented prior to building or configuring the system. This can result in a significant amount of rework.


There’s No Magic Bullet

I generally see larger companies using the waterfall methodology and smaller companies turning to the rapid deployment model (although many smaller companies still opt for the waterfall methodology and vice versa). This likely has more to do with the complexity and extensiveness of the requirements than anything else. A small company will often have less complex distribution requirements than a large company—especially in the retail arena, where multi-channel distribution is becoming more prevalent. There’s no one right methodology that every company can use. By assessing your firm’s needs well in advance and understanding your own IT team’s capabilities and limitations, you’ll be able to make the best WMS implementation decisions.

The GPS to WMS Part 4 - Three Ways to Minimize Risk During a Warehouse Management System Implementation

By Ian Hobkirk | 06/07/2016 | 10:39 AM

No substantial software implementation is easy and Warehouse Management Systems (WMS) are certainly not the exception. Before, during, and even after implementation there are numerous steps that must be taken and plans put into place to ensure a smooth transition from an existing system—or the smooth adoption of a brand new solution.

Three big obstacles that tend to trip companies up during the WMS implementation process are:

  • Not allowing enough time upfront to properly prepare for the project
  • Not allocating enough time for the actual implementation phase
  • Not knowing when to delay the “go-live” date

Let’s look at each of the issues and the steps that can be taken to avoid these problems altogether when implementing a new WMS.

1) Not Allowing Enough Time Upfront 

Project preparation should be a defined phase of your project that requires about four weeks to complete. During this phase, you’ll want to clearly define roles, processes, and execution, as well as disseminate relevant information to all stakeholders. Here’s a checklist of documents that should be developed before the warehouse management system implementation project officially starts:

Integrated Project Plan:  Use a platform like Microsoft Project to create an integrated plan. Doing so will ensure that the dependencies among the different work streams are rationalized.

Project Plan WMS

Detailed Roles and Responsibilities Document: This is a matrix that clearly defines all of the tasks that your team will be accountable for, and which ones the WMS vendor will handle. Here’s a sample task list excerpt:

Sample WMS Task List

Risk Management Plan: Successful IT projects are all about balancing risk in the areas of cost, time delays, or a disruption to shipping. An experienced WMS project manager can help anticipate and ward off possible risks during implementation. As part of your Risk Management Plan, perform an organizational impact analysis to identify major impacts to other areas of the business outside of distribution. The Risk Management Plan should answer questions like:

  • What constitutes an issue?
  • How are issues to be reported?
  • Who is responsible for collecting the issues?
  • What is the process to review and decide on actions to resolve the issues?
  • How will issues be prioritized?
  • What are the criteria for successfully resolving an issue?
  • What happens when issues cannot be successfully resolved?
  • What is the escalation plan for unresolved issues?

Answering these questions before project kickoff will ensure that the necessary processes are in place to track and resolve issues.

Develop Systems Architecture Plan: Identify the systems architecture that will support the new systems.


Financial Reporting Plan:  Use a document, Excel spreadsheet, or your ERP’s financial reporting function to track project spending and to keep financial stakeholders updated on project finances. Your company may also have a template and procedures that specify what and how to track spending. Larger companies may use a financial report out of their ERP system.

2) Not Allocating Enough Time for Implementation

“What is a realistic time frame for a WMS implementation?” is a common question.

In rare instances, I’ve seen very simple (with no changes or customizations) WMS implementations take 6-8 weeks. I’ve also seen implementations take well over a year, especially if the WMS project is part of a new building or major material handling automation project.

3)  Not Knowing When to Delay the “Go-Live” Date

No matter how determined you are to get your new WMS up and running, it pays to take a step back and make sure the system is indeed ready to go live. Do this by conducting a WMS readiness assessment to evaluate your company’s level of preparation in these six areas:

1. System readiness
2. Interface readiness
3. Visibility and reporting
4. Training
5. Data conversion
6. Inventory condition

Much like you would have a marine engineer check out your boat before launching it, a readiness assessment ensures that the system and its users are actually ready to begin working. Delay go-live and you may have to use your existing systems for a few more days, but jump the gun and risk everything from shipment delays to errors to unhappy customers. Which would you rather have?


The opinions expressed herein are those solely of the participants, and do not necessarily represent the views of Agile Business Media, LLC., its properties or its employees.

About Ian Hobkirk

Ian Hobkirk

Ian Hobkirk is the founder and Managing Director of Commonwealth Supply Chain Advisors. Over his 20-year career, he has helped hundreds of companies reduce their distribution labor costs, improve space utilization, and meet their customer service objectives. He has formed supply chain consulting organizations for two different systems integration firms, and managed the supply chain execution practice at The AberdeenGroup, a leading technology analyst firm.


Popular Tags

Subscribe to DC Velocity

Subscribe to DC Velocity Start your FREE subscription to DC Velocity!

Subscribe to DC Velocity
Go digital