If you’re doing a Warehouse Startup, you need to get through design. But how? Some of the dependencies are obvious but some are not. In this post we’ll discuss the key design process and dependencies that you need to keep an eye on.
Design
Design for a warehouse startup goes like this:
One function’s design outputs are another functions requirements input. So when we speak of requirements, we’re really talking about a mostly-sequential, somewhat iterative process of completing design for a Function A and feeding requirements to the next Function B. The Function B may have to iterate with Function A to get to an optimal solution.
The key difference between this requirements design scheme and something like Agile for software is that with construction there are long procurement and lead times, so some things have to be fixed before starting work. So a waterfall methodology is implied for part of the functional work in the project.
Volumes
Let’s examine this. Experts agree that the very first dependency is understanding the volumes and throughput that the facility is expected to handle. This includes total volume amounts and the analysis of the activity profiles to understand the design volume requirements.
Why is this a critical dependency? Because it will drive design of the operational processes and warehouse layout to support them. This in turn drives IT design, staffing, the physical warehouse drawings, equipment, infrastructure, and so on through all aspects of solution design.
Accomplishing this dependency means completing data analysis and getting agreement on the key figures from the stakeholders who approve design.
An effective way to do this is to have a consolidated document with the design volumes assumptions and findings and then reviewing and documenting approval.
Some projects try to skip this part and go straight to layout and systems work. Be warned, if you skip due diligence at this step, you’ll end up fixing the facility after it’s been built.
Operational Processes
Once you know the volume and flow requirements, you can scope your layout and processes. This should start with a material flow diagram, which shows each of the process steps with connecting arrows representing material flows and flow rates.
The material flow diagram serves as the basis for creating a block diagram. Just like it sounds, you can place blocks where the activities will occur over the facility footprint. This creates the first pass of an operational layout. It is not yet the warehouse construction design. Its purpose is to identify warehouse activities and sequences and ensure correct flow through the facility.
The second part of this section is defining the operational processes. These must be understood in detail before starting programming design. While the definition of the operational processes can happen with the IT business Analyst, it is absolutely critical for Operations to define–down to the sequence of scans and keystrokes of the operator, down to the timing and strategy of task release, down to every exception path at every step of every process, when and where which labels and paperwork will print– what the operations will do.
While this can be skipped or glossed over, rest assured that Operations will end up defining these processes in detail after they’ve been developed, and by then they may not be the processes that Ops wanted.
Technology Selection
The required operations processes and volumes will point towards technology options. Here you can select how automated you want the facility to be; which processes to automate; what equipment and storage media to use; and so on. This is important because it give requirements to IT and to Construction workstreams.
This is also where to engage and select the vendors of the equipment. They will be able to later provide detailed requirements for their technology as it fits into your operations.
IT Applications
Now that operations processes are defined and technology selected, they become the functional requirements for the IT applications group. This is the function that will develop or configure the systems to support the distribution center and the communications of those systems with other systems.
Included in this function’s RFIs are all the operational behaviors needed as described in the process definition above. The Applications design will also get into designing documents and labels, so Operations needs to give requirements for those items.
Notice that the diagram branches at this point and goes also to…
Organizational Design
Once the operations volumes, processes, and technology are understood, the facility starts to take shape.
The operations lead can now make some decisions around the organizational structure and headcount required for the site.
Organizational design should also have an underlying philosophy of culture. This will drive later decisions in office layout and amenities in the facility. If you’re looking for a short-term, minimal-cost site, it’s good to be clear on that early in the design and before you go into detailed construction design. On the other hand, if you are looking to attract employees and give tours in a showcase facility, this will lead to a different organizational strategy and facility design.
Examples of this include:
- Defining the ratio of temp employees to permanent employees planned
- Articulating the amenity philosophy
- Understanding how much front-office support will be needed onsite and when
- Making decisions on whether visitors will come, who they will be, and what accommodations are needed for them
- Planning training facilities and support for the employees
This is upstream of warehouse design because the people have needs. Facilities design without organizational planning leads to cramped and inadequate sites. Even though there will be some iteration between technology selection, warehouse design, and organization, a 90% solution for the organization size and structure is required to move on.
Other things to define early include shift size and shift schedules. These will drive parking requirements in the facilities design.
Warehouse Layout
Now we know the technology and the organizational shape and behavior. We can drill down more into what the warehouse will contain and how it will flow.
At this point it’s time to revisit the block diagram. Review it with your teams to see if it makes sense and is efficient. Some things to consider here are overall material flow through the site from receiving to storage to shipping, slotting, employee flow, pedestrian traffic, waste removal and handling, and maintenance.
Ops Equipment Design
In a perfect world, we would select the operations equipment such as automation and forklifts, complete the detailed design, and then turn all the requirements over to the architects and engineers to complete the final facility plans. Ha! Ha!
This process is often iterative with high level designs (“rough order of magnitude”) passed to the facilities team. But to minimize rework and changes, it’s a good idea to complete as much design of the operations equipment as possible.
This is because the operations equipment will dictate facilities requirements like utilities placement. If the equipment needs change later, the facility will have to change.
Typical requirements that come out of this phase include electrical, compressed air, clear height, slab requirements, temperature & environmental control, lighting, and others.
This operations equipment will also include identifying and designing things like workstations and furniture required for the operators.
IT Infrastructure
Let’s not forget the IT infrastructure requirements.
We know that warehouse equipment runs on connectivity. So the Infrastructure team will need to know all the network requirements to support that equipment.
This means RF scanner coverage areas, how many devices will be on the networks, where transactions will take place at workstations, what devices will be used for every input/output area, what networks are required, where data drops are needed, how information will be displayed… you get the idea.
The applications design will also give requirements to the infrastructure team which will point to what type of servers are reuqired. And this will generate additional non-functional requirements around reliability and latency that the Operations and Applications teams will need to provide.
All that information is used to develop the plans for servers and switches and access points and printers and monitors and scanners. Servers require cooled rooms. IDFs require careful placement so they can support the access points. All those things require power.
Bottom line here is that before going to detailed facilities design, the infrastructure team needs an opportunity complete the network and device plan.
Facilities Design
This brings us to the fun part: facility design!
Facilities design will get into the details using all the requirements developed beforehand:
- The warehouse equipment and its utilities requirements mentioned earlier, including power, compressed air, water, slab design (including strength, flatness/levelness, and layout), temperature control, clear height, and so on.
- Organizational needs, like people flow, break areas, travel paths, restrooms, fire & life safety, parking.
- Aesthetics and look-and-feel of the facility.
- Operating needs like lighting, fire control and life safety (do your racks need sprinklers?), accessibility, drainage, sustainability, and security.
- Oh, and parking. Remember the volumes and throughput analysis? That’s needed again here to tell the architects how much trailer parking and dock doors are needed and what traffic controls like guard shacks to have in place.
All this means you’ll have to go into detail on the office space and the block diagram you did earlier, at this point down to the location of individual pieces of equipment, power drops, lighting and rack locations, server room locations, and so on.
This is why it is critical to go through requirements from other functions before going into full facilities design. You can’t design effectively when you don’t know the requirements. If you do, you’ll end up with changes, rework, and delays.
Testing Design
Often neglected by implementations teams, testing is critical to a smooth startup. You will end up testing everything at some point. Whether it is deliberately planned before go-live or in production at a critical moment is up to you.
Testing design should start with the operations process definition and requirements given to the Applications teams in the functional design documents. The testing can be expanded to cover multiple phases of functional, end-to-end, and acceptance testing. The planning can be done in parallel to the other functional areas design. It should include progressive testing phases that cover the full scope of the warehouse operations and solution.
The important thing is to plan for the testing time and resourcing requirements before you actually have to do it.
Conclusion
Warehouse design can be tricky. There are a lot of moving parts. The design phases for each workstream overlap and iterate and are often on different basic timelines. But there is a path through it.
When going through design, start with the fundamentals of what the facility must do, then design for the technology and people to support it. Talk to the teams about what’s coming and what will be needed to be successful.
And you’ll get through it. I promise.
If you found this useful, I help teams work through this process. Like, follow, or send me a note to learn more.