A critical planning piece for a warehouse startup is the volume ramp plan. This is important because it informs the organization about what the new facility will be capable of and what they should plan for. It is a key deliverable that the Project Manager should identify and track during the planning process. Let’s explore this some more.
Why a Ramp Plan is Needed
Ramp plans are required because a new facility starting up usually can’t do 100% of planned volume on day one. If a facility “flipped the switch” and went from test volume to 100% of peak volumes on day one, there would likely be a lot of frustrated employees and disappointed customers. If you’ve ever lived through an overly aggressive ramp, you’ve seen this first-hand.
There are many reasons for not producing at 100% from the first moments. Equipment may not be fully installed or commissioned. Or the entire team isn’t hired yet. Or the team doesn’t have the experience and tacit knowledge to be completely efficient yet. There are often technological, operational, and process “bugs” to work out no matter how thorough the design and testing phases were.
So the ramp plan formalizes the business expectations to help the facility and team get to 100% without causing service failures. If there is no ramp plan, you can be sure everyone sees a go-live date and assumes full production and capability on the day of go-live / cutover to production.
Ramp Plan Parts
The ramp plan is essentially the volume plan for the facility broken up into all of the facility’s main capabilities over a calendar. So it should contain capability activation dates and the stages of volume over time.
Capability activations means the start dates of any different capabilities that the site will deploy. These commonly include inbound receiving and outbound shipping. Each of those activations needs to have a start date and associated volume increase plan.
Sometimes the site may need to specify that there are “go-lives” for other capabilities. An example would be starting to use more modes of transportation after shipping goes live. If the site goes live shipping only FTL loads, then starting LTL or direct-to-consumer parcel might be another launch or go-live date. Or perhaps the site starts to do VAS orders at a certain time after receiving and shipping start.
The takeaway is that if a capability is within scope for the startup project, then the ramp plan should identify the capability, the date it starts, and the volume ramp to stabilization.
Capacity
Volume planning is a function of facility capacity. But capacity is an ambiguous term–what do we mean by “capacity”?
“Capacity” in conversation can refer to:
- storage space available
- Process throughput available for inbound, putaway, picking, or shipping
- Labor available
- Transportation available
Broadly understood “capacity” should refer to the bottleneck in the facility that is most restrictive on output. But because “capacity” can refer to any of the items above, two people can be having a conversation about capacity and mean completely different things. One person may say “you definitely have capacity for 100k units” while looking at storage available, and the other person, thinking about the hours required to do 100k units and staffing only available to do 50k even with overtime and temps, may say “no we can only do 50k”. So the entire capacity picture has to be articulated.
How does this affect the ramp plan?
Operations needs to be able to commit to a volume plan. This volume capacity is a function of all of the above things. If the team is not fully hired or had a learning curve; if not all the forklifts are available; if racking is still being installed; or robots are not all onsite yet; any one of these things may constrain capacity. So the ramp plan should have a volume increase plan that reflects the actual plant capacity at a point in time.
What to include
The ramp plan can be drafted by Operations in Excel or a spreadsheet tool or the planning tool of choice. It should contain at least the following:
- Columns for weeks or months. This is a time-bound plan after all. The duration is as long as the business plans to get to operational stabilization. (again a term people can debate, here we mean to substantial planned operational effectiveness).
- Rows for any applicable capacity constraints such as number of storage positions, mechanical throughput schedule, or headcount, over time. And importantly translate these to what they mean in terms of volumes. Showing pick headcount over time doesn’t mean a lot by itself but daily units picked does.
- Rows for each capability activation. Inbound/receiving and outbound/shipping at a minimum should be shown.
- Volumes: show monthly, or preferably weekly, volumes for each capability. Volumes should generally increase week-over-week though the first week or two may need to be planned at the daily level before going into production. Note that this volume plan should account for discovery and fix of bugs or issues in production and learning curves for the people. Some system issues will only be discovered by adding volume and complexity to an operation. For that reason including some extra time for finding and solving issues will help save cost and operational pain.
- Inventory balance projected by subtracting cumulative outbound volumes from cumulative inbound volume. From this, derive storage percent fill by dividing inventory balance(s) over storage capacity. It’s important to project storage fill during the ramp up and plan for balance in the site.
The purpose is to show, in one place, what and when the volumes, major startup activations, and the major capacity constraints.
Ramp Planning Considerations
Activation timing: It’s a good practice to separate the inbound and outbound activations by some period of time. If the operations are simple, a week may be adequate. If operations are complex and the stabilization ramp is long, then several weeks between receiving and first shipping might be needed.
Team experience: If the team starting the warehouse is experienced and has had an opportunity to train, the ramp period can be shorter. If not then you can expect a steeper learning curve.
Stakeholder feedback: The ramp plan will affect IT, logistics, fulfillment, and cost targets. Make sure to socialize the plan and get feedback on it, then publish it to a group and put a copy in the document repository. Different groups will have different input, and they all need to know what to plan to.
Speed of ramp: The initial ramp should include some ‘cushion’ to allow for problem fixing. Especially in the first week of putting some capability into production, use “smoke testing” of an order or two to confirm functionality, then plan a quiet period to resolve issues. Then start the volume ramp “for real.” This allows time to fix anything that came up in the production cutover. You can go faster if everything is working well. It’s very hard to go slower after a volume target is published.
When to build the ramp
The ramp plan should be built when defining the go-live schedule in project planning. If it can’t be fully built then it needs to be considered. Otherwise the business will have a lot of ambiguity in the planning.
Questions will come up: Does “Go-live” mean starting to receive and ship the same day? If it only means receiving, when is shipping starting? If it is the first ship date, when is the system going into production and starting to receive? How much and how quickly should the site hire? And so on.
Having a draft on paper early will help align stakeholders around key decisions regarding volumes, cutover schedules, staffing and hiring, cost planning, and other events. Finalizing the plan probably won’t happen until a month or two (or planning cycle) before go-live. And the ramp will be flexible during the startup as events happen.
Something as simple as this can be a tremendous tool to align stakeholders early in the process on what to expect during the go-live process:
Conclusion
Ramp plans are a critical part of bridging the project start-up to a fully functioning operation, especially if the organization hasn’t done it before. The project manager should list it as an Operations deliverable at least before going into integrated testing, and preferably in planning cycles before that.
The plans can get as complex as you want them to be but they should include at a minimum major capability starts, volume increases, and capacity constraints. Eventually planning teams will start regular business planning processes. But a proposal from operations to the rest of the business ensures that capacity constraints and growing pains are part of the plan.