In the previous article, we reviewed the goals and areas of focus when developing solutions to improve distribution operations. In this segment, we will explain how to best approach these projects to reduce risk and ensure the solutions are focused on achieving business goals. We will also address how to estimate the resource requirements prior to engaging a project, so that you will be prepared and most effective.
Seven Steps for a Successful Operations Improvement Project
1. Develop a Mission Statement
Every project must have a mission statement that is clear and concise. Mission statements encompass both the business goal and the project goal, so that all involved understand the correlation. Examples of mission statements include:
· To design and implement a best-of-breed distribution operation that offers our clients the best customer service and our company the most profit
· To increase the productivity and throughput capacity of operations within our existing DC to meet a 3-year business growth-plan
· To most effectively and efficiently incorporate the defined new value added services into our distribution operation to provide our company with a competitive edge
2. Define Goals
Most projects will have multiple goals to meet the mission statement. For example, if you are designing a new distribution center, undoubtedly you will want to see specific improvements across all of the different areas of the operation. Thus, to fully cover all areas, each goal may have a sub-goal. The development of goals requires analysis and benchmarking (against yourself and with others) to ensure they are set correctly. Goals should be concise, objective, and easily understood. They need to be aggressive enough to achieve optimal results; however they must also be realistic, achievable and quantifiable. Examples of goals include:
· Increase throughput capacity to meet the forecasted demand of 15% annual volume growth and
· 10% SKU growth
· Improve orders-per-man hour by 10%
· Reduce distribution costs as a percentage of sales by 1%
· Decrease cost-per-line or cost-per-unit by 10%
· Improve order accuracy by .5%
· Reduce square footage requirements by 10%-20% through improved slotting and cube-utilization
3. Develop Parameters and Assumptions
Every project should have a set of parameters and assumptions which guide the development of alternatives and solutions. They should be thoroughly defined and documented, and cross-referenced for each alternative being reviewed. Interestingly, parameters and assumptions are not always carved in stone. As alternatives are developed, some modifications may be required. Typical parameters and assumptions for a distribution center design and/or improvement project include:
· Growth: i.e.10% volume growth and 2% overall SKU growth
· SKU mix: i.e. assume same SKU mix for growth
· Inventory Turns / Days on Hand
· Facility; i.e. assume same network, stay within existing square footage, etc.
· Design Year; i.e. assume solution is to meet 5-year plan
· Labour Rates
· Shifts; i.e. assume 2-shift operation
· Systems; i.e. assume systems must be supported by existing WMS; assume any new WMS must be of a particular platform
· Processes; i.e. assume processes must be supported by existing WMS, or through bolt-on modifications or an integrated third-party package
4. Create a Baseline
A baseline is the foundation for all change. A poor effort here will ultimately result in poor downstream efforts and negative overall project results. Existing operations should be documented prior to beginning the alternatives analysis and solution development. A common mistake is believing that an existing operation is well understood by all, which typically is not the case (even in efficiently-run operations). Frequently, a thorough baseline effort surprises many with the revelation of what should be happening on the floor vs. what is actually happening. Baseline efforts include, but are not limited to the following:
· Mission statement that outlines client expectations
· Communications flow diagram and documents
o Inbound (i.e. client order) to outbound (i.e. ASN, manifest, etc.) communications
o Communications between systems (e.g. OMS, WMS, ERP, WCS)
o Internal reporting requirements
· Written process description and task scripts (the more detail the better and may already be developed for training materials)
· Facility information
o Drawings
o Parameters
· MHS / Equipment information
o Drawings
o Descriptions, including technical capabilities / limitations
· Material flow diagrams
· People flow diagrams
· SKU analysis
o SKU lists
o SKU dynamics
o Family grouping requirements
o Other special considerations / requirements
o Growth by SKU category and/or family group if possible
o Physical SKU characteristics
o Inventory levels
· Order/Volume analysis
o Order types
o Receiving volumes
o Volumes (orders, lines, sub-lines, units)
o Seasonality
· Operational metrics
o Productivity
o Cycle times
o Customer service
o Cost
When developing a baseline, especially historical order and SKU analysis, data analysis tools can be very beneficial. They can provide a more detailed review of operations and reveal potential areas for improvement. Database tools are available specifically for this type of analysis and provide a foundation to drive solutions from real information and detailed data, rather than from assumptions and higher-level estimates and averages.
5. Develop and Analyze Alternatives and Solutions
This step is the “meat” of the improvement project. It begins with the development of a set of potential solutions to analyze and compare in working towards the final optimal solution. A good way to start developing alternatives is to identify best practices within your industry. It is very important to note that a “sky’s-the-limit” and “look at anything and everything” approach can be time consuming and expensive. Much thought must be given to the practicality of various alternatives across processes, people, inventory, facilities and systems. Though it does often feel like you are putting-the-cart-beforethe-horse, certain alternatives or general categories of alternatives may be able to be discounted quickly, thus reducing the scope of the project, without sacrificing value. Discarded alternatives should be stated in the assumptions and parameters documentation. On the other hand, it is equally risky to have too few alternatives. It is common to enter a project with preconceived notions, and narrowing the solution set too quickly can result in missed opportunities.
Comparing and evaluating alternatives typically requires a significant amount of time and effort, and is dependent on the quantity and complexity of the alternatives. Additional complexity comes from developing the potential solutions across all of the areas of the operation. One of the most common mistakes is approaching the potential solutions at too high of a level and not fully developing them, which is risky and often ends in a misrepresentation of the solution.
Comparing dramatically different alternatives can be the most challenging. For example, comparing a pick-and-pass operation to a batch-pick operation requires reviewing multiple areas: alternative material handling systems (MHS), warehouse control systems (WCS) communication processes, warehouse management system (WMS) capabilities and interfaces, exception handling processes, metrics and measurement processes, facility layouts, etc. Another example is the comparison of very different order picking technologies, such as goods-to-man systems (i.e. ASRS, carousels, etc.) to manto-goods systems (i.e. pick-modules), which requires the same level of evaluation across all areas of the operation.
When comparing technologies, costly mistakes can be made, such as missing a communication interface or incorrectly assessing pick-rates. These mistakes can skew an alternative one way or the other, effecting decisions involving millions of dollars. Hopefully, these examples make it more obvious that the alternatives analysis process can and should require a significant amount of effort, and that taking a higher level approach increases risk.
When evaluating alternatives, it is critical to have a financial focus centred around the key metrics and performance indicators of the operation. It is also critical to ensure that the expected results of any solution are based on real-life examples, as close to your specific situation as possible, and adjusted to compensate for any differences. Documentation is critical here, as is involving subject matter experts (both internal and external personnel) for the various areas being reviewed.
Once all alternatives have been developed, analyzed and compared, the next step is rarely a selection from the finite set. Rather, to craft the optimal solution, the team must put together the best pieces from each alternative to create the final solution. If the alternatives analysis has been thorough and complete, final selection will be easy and almost anti-climatic. If it seems overly difficult, then steps have more than likely been missed, and it is time to back-up and reassess.
Once general solutions have been determined (process, MHS, etc.), alternatives for optimization typically remain. For example, a decision may be made to go with pick-modules. However, the actual levels of forward and reserve inventory and storage equipment must be analyzed, and the more slotting detail in the analysis the greater the levels of optimization. Database tools, once again, significantly aid this process of comparison and optimization, as manual and even spreadsheet processes are often too limiting.
6. Develop a Plan to Deliver Results
Once the final solution has been designed, a plan must be developed to implement and transition the solution into operations and ensure the greatest chance for achieving results. This plan must be accomplished prior to completing both the solutions development project and the implementation process. When developing the implementation plan, new concerns may be found that affect the final solution, including the overall cost. This plan encompasses much more than how a solution will be installed to meet a schedule. It also includes program management planning and all of the work related to:
· Final solution development and engineering; mechanical, electrical, software, facilities
· Selecting the right partners including key providers of the solution or solution components
· Ensuring the best overall value and lowest overall lifetime cost in acquiring, implementing and supporting the solution
· Working with the key stakeholders to ensure scope and definition are clear and concise
· Developing operational scripts and training aids
· Planning and execution for the comprehensive training of personnel
· Establishing good communication processes and communicating regularly to keep stakeholders, end users, and project teams updated on overall progress and critical issues
· Establishing and involving champions for change management and creating a positive environment for solution deployment
· Creation of test plans
· Creation of success measurement plans and specific metric goals (Note: most of the primary components of the measurement plan should already be in place, having been originated as part of the goal setting and solutions development phases)
7. Reduce Risk
For any operations improvement project, the risks and magnitude of money at stake is significant. The two best ways to avoid risk are simply stated, but not always simply executed: 1) do not skip any of the steps in the process, and 2) devote the correct amount and type of resources to each step. Trying to work with unrealistic schedules and budgets are the two primary culprits of backing projects into shortcuts, which typically cause problems that require more time and money than what was intended to be saved.
Determining Resource Requirements
Operations improvement projects require significant resources, primarily through the investment of people, time and money. How much of a commitment depends on the scope of the project, the goals to be achieved, the alternatives to be analyzed, and most importantly, how deep a dive an organization needs to take to optimize their operations. To determine resource requirements, a list of the specific expertise that will be required should be developed. Then the roles within each area can be created and a plan can be developed to determine how they are to be filled. You may need to consider bringing in outside resources to fill some roles. To begin your list, it is best to start with the expertise needed within each of the main components (processes, people, inventory, facility and systems). Depending on the size and complexity, a solutions development project typically draws subject matter experts (SMEs) from the following areas:
· Distribution Operations
o Representatives from every process area will need to interviewed (typically supervisors)
o Managers should be brought into key meetings to review data, alternatives and for final solution development
o Executive(s) should participate in all key meetings
o A Project Lead should be assigned from the Management or Executive level; involved in all meetings and guides all efforts
· Inventory control: discuss inventory levels, turns, merchandising practices, etc.; work with team as needed through changes
· Data analysis: knowledgeable on orders, volumes and SKUs, with capability to perform special analysis to drive opportunity and solution development; expertise in data analysis software tools is very important
· Finance: required to communicate the financial requirements (i.e. ROI) for any capital investment
· Sales: though often excluded from these types of projects, an SME from Sales, especially in the early phase of the project, can be beneficial to provide areas for improvement from the client’s perspective
· Information Technology (IT): depending on the type and complexity of the project, this could be one SME or a team of SME’s, to guide solution development around host requirements, WMS capabilities and other IT processes and systems
· Facilities: provide guidance on the physical structure as it pertains to the solutions
· Systems: SME’s by specific technology (MHS, WMS, TMS, etc.); very deep expertise necessary when systems are a potential part of the solution
· Industrial Engineering: SME’s to execute tasks related to processes, layouts, drawings, etc.; most projects have a large industrial engineering component, which typically requires one to two very capable IE’s
· Program and Project Management: SME who understands not only how to run the solution development project, but also, the implementation of the solution for effective planning; this role often carries over into the solution implementation phase
The next step is to develop an actual work-plan to estimate the requirements and costs for the solutions development project. Estimating hours is difficult for those without specific past project experience. For a very high-level approach, the above roles provide a starting point to begin assigning resources (people and hours). Project time requirements vary dramatically: from a couple of weeks for high-level assessments to several months for larger scale distribution operations designs. One of the greatest mistakes made is initially underestimating the resource requirements for a solutions development project. Typically, once a project has begun, it is difficult to get more resources, and if they have been underestimated, shortcuts are often taken, producing less than optimal long-term results.
Summary
Although these white papers represent only a fraction of the details that comprise solutions development for a distribution operations improvement project, we have provided you with a workable approach and outlined the specific areas of importance to consider. Remember, the keys to a successful project are a solid approach, a well-defined plan, committed and capable resources and a commitment to detail. This will lead to the reward of a best-of-breed distribution operation that delivers an optimized solution to your organization’s bottom-line profitability.
Contributed by Marc Austin, Managing Director Fortna EMEA (Pty) Ltd
