Just as a software program requires a design spec or user stories, and a building needs design drawings, a warehouse distribution or fulfillment operation needs a specification. It is documentation of the entire operation. Experience shows that it is critical to project success and operational continuity.
We think of it as a combination of the basis-of-design document and the warehouse process functional specification, including all operational scope.
Let’s look more into this document–what it is, why it exists, and why to invest in creating and maintaining it.
What The Warehouse Specification Is
This very useful document for any large warehouse project is the Master Process Document. We’ve heard this document go by other names such as Functional Design Document, or Concept of Operations, or others. But the point is the same: It is the functional specification of the warehouse site and operation. We’ll refer to this document as a Master Process Document (MPD).
Organizations should create an MPD to define and describe the processes that facilitate the purpose of a manufacturing plant or distribution center. It is then used by various teams or departments to understand the overall purpose and a roadmap for the final construction of the project. The document is used for design and then maintained as a reference for the facility specification.
Most of the time, this document is written by industrial engineers. They are tasked with designing the processes and selecting equipment for efficient processing, high throughput, and the highest return-on-investment (ROI). They also consider future expansion needs.
The MPD also serves as the basis-of-design document for the operation. This means it should include the “Engineering Specification”, basic data and calculations. This contains the math behind how the equipment designs were selected to meet the objectives. It also articulates the rates for each process and the labor plan to support these processes with the accompanying mathematics to support.
A pitfall we’ve seen is when the MPD does not show this backup detail, which then create more questions than the document can answer. When there is no firm design basis for the site, then every design decision and process can (and will!) be questioned. This can lead to rework as later managers re-discover the original design assumptions.
What The MPD Is For
The MPD helps in these core areas:
- Captures design details
- Ensures continuity
- Improves project quality
- Catalyzes organizational alignment
- Serves as basis for training
- Summarizes the operation for outside stakeholders
Captures Design Details
Design takes a lot of hard work. Don’t let it go to waste.
At its core function, the MPD / engineering specification memorializes the design details for the project by putting to paper the official, version control document that is accessible to anyone needing to understand the project. The document becomes the “go to” resource that can referenced by anyone needing to articulate any detail of the project to others, whether internal or external audiences.
After the project is completed and running for any length of time, there are also often subsequent improvements in the form of CapEx projects. The MPD can again be used as the baseline design specification to get team members up to speed on details of the original design and how to integrate any new updates to minimize disruption.
Build In Continuity For Your Teams
The MPD reduces knowledge gaps. It creates a document that is accessible by the organization. This means that more than one person in the organization has input and understands the design and processes equally so that the content is not “one deep” if a key designer leaves the company for any reason. This ensures knowledge is shared, saved, and maintained by many.
It also provides a vehicle for updating meeting guidance between teams throughout the life of the project. Any team updates or edits can be incorporated into the document or meeting notes and then reflected in the version control. This ensures clear and up-to-date communication between SMEs. This improves collaboration between teams and SMEs. Documenting processes and engineering details provides a culture of knowledge sharing between teams.
Increase Operational Quality
By virtue of an initial engineering design based on solid IE principles of Lean and motion economy, calculated equipment selection, and then having peer review with internal SME teams, the MPD serves as a forcing function for optimal quality and productivity.
By documenting process and design assumptions, these processes become fully integrated across functions though collaboration with different audience viewpoints. The writer, having to write to multiple stakeholders, must then write and edit from different perspectives than his own. It allows for a self-critical process. Also, others, having different perspectives, can provide beneficial feedback into the design.
For example, operations leaders will have a different perspective on operator moves that the engineer. The Operations team may have insights from their experience about frequency of events, equipment requirements, or process steps.
This all improves project quality. As a result, projects with a comprehensive MPD and process have fewer scope gaps, un-documented processes, rework, and so on. This translates into better visibility into true site needs. It reduces unexpected costs and costs arising from poorly designed, after-thought workarounds.
Organizational Alignment
After the first version is distributed to all parties and subsequent meetings to review for clarity and edits have been completed with all internal stakeholders, it provides for organization wide “buy-in” and commitment to the project as all are able to provide input from their areas of expertise to make it work. This results in a fully aligned document and operational plan.
After internal agreement, the document (or parts of it) can be sent to potential vendors for RFQ (request for quotes) either for specific equipment or for entire system integrators. Again, having full project disclosure and purpose in front of them, the vendor can be armed with more detail so that they can in turn provide the best fit options and also suggest alternative option scenarios that can be evaluated internally to compare against benefit and budget constraints.
Basis of Training
Training is a critical but easily-overlooked part of warehouse startups. Lots of attention goes into the site construction plan. Lots of attention goes into automation design and site layout. Huge effort goes into IT systems design, programming, and testing.
Yet we see this too often: when several hundred employees show up to actually do the work, work instructions are inadequate, poorly written, incomplete, and don’t cover all the processes that are needed.
Why is that? After all, a training program that is efficient and complete will improve employee ramp times and reduce error rates.
Many times it is because there is no place to start. Training documentation must be organized and have an owner.
A good way to start is to use the MPD as the foundation of the training program. The MPD contains all the operational processes, so why not build the training and process documentation plans from it? The MPD may have processes articulated from level 1 through level 3. Levels 4 and 5 (detailed processes down to user task level) can then be identified and documented during user acceptance testing.
In the initial stages of a project, engineered standards and methods may not be developed yet, so process steps and rates are driven from estimates or best practices. The MPD/Engineering Specification serves as a guide for developing training documentation. It allows for quicker training and helps ensure employees are trained according to the intent of the design and equipment that is being installed.
Who The MPD Is For
The audience for the document may include a wide group of stakeholder. When writing the MPD, it’s important to ensure that all the details are easily understood by all parties.
This list would include the below subject matter experts that will be involved and reading the MPD:
- I/T business Analyst and programmers
- Automation specialists
- Human Resources
- Operations
- PMO personnel
- Implementation and Start -up teams
- Mid to upper-level management – decision makers
- Engineering
- Training teams
- Integrators and Vendors – MHE, rack, conveyor, sorters, packaging, automation etc.
Since this is such a wide range of experts, it is necessary to write the sections of the MPD as if telling a story that interconnects the processes and the details supporting each process so that it is easy to follow and understand.
These experts should be able to find the information they need to build and construct their required tasks but also to have a good understanding of other interconnected subject areas which may not be in their area of concern but which could have an effect on how they design and implement.
Audience members can provide valuable insight and possible design changes based on their technical experience from their point of view. In this way, after all have read and understood the document, essentially there are multiple “eyes” able to edit and verify design assumptions by the industrial engineers.
Preparing the MPD
Sometimes the MPD is written by various groups based on their “expertise” and then collated and organized together into one document. While this method allows all groups to be involved in the design and writing, this “design by committee” approach tends to be disjointed and “choppy.” This approach delivers an un-integrated document with “connecting the dots” between process descriptions or systems integration. Consequently, it can miss important details.
We recommend the best practice is to have the industrial engineer (IE) own and write the document with all the engineering support detail. The IE should ensure that each section is written as a story describing the processes and equipment as though the reader had no prior experience with the subject matter.
The intent is that a new hire could be given the document and, after reading it, should have an 80% to 90% understanding of why the project is needed for the company, how the design was conceived, calculated and designed, and how all the various parts will be integrated to make it all work.
Version Control
In order to ensure communication with all these internal stakeholders is up to date and to reduce any confusion, it is vital to have a section or table at the beginning (after the title page) showing version control with date of version and short descriptions of add, edits, deletions. These typically come after meetings with stakeholders. The document is sent out to all for reading prior to a specific meeting to review each section and allow each group to comment on their area of expertise or any other section that they may have a question. Many times, the biggestgaps or omissions for clarity are culled out in this way. Engineering should drive this meeting to ensure all participants are able to have a voice.
Content
A typical Table of contents for the MPD is shown below as an example. It should be organized from project starting processes to ending processes.
For a distribution center, this is typically from receipt of goods into the building (including yard management) to shipping and tendering goods outside of the building walls. Included as support sections are CAD drawings of the building showing the details oof equipment and rack designs, pedestrian travel aisles, block diagrams of processing areas showing employees per shift, processing rates, conveyor or mechanical rates that are tied to personnel productivity requirements.
Other operations-critical information should be included. The intent is to have a single baseline document with all information necessary to understand the “how” of the site operations.
- Title Page
- Table of Contents
- Introduction – A description with the background information on the need of the project, goal of the project and operation.
- Revision Table: A critical part of document control is to understand who has revised the document, with what, and when. A revision number scheme should be developed for file names and maintained in a table format showing the date approved or reviewed and a short description.
- Terms and definitions section: This should contain key terms, vocabulary, and acronyms used by the organization.
- Data: Description of data files used in the design calculations with examples. This description should list the data files used, where to find them, and data dictionaries explaining the header or field information in the files. Common files may include the Item Master, Receiving History, Forecasts, Inventory Snapshot, etc. The files should be stored elsewhere but must be accessible.
- Product characteristic information
- Layouts: Include block diagrams and CAD Layouts in the document, showing areas such as: Block diagrams of processing areas in relation to overall layout with FTE per shift in each area; Pedestrian walkways: and lift truck travel aisles; Area Footprint Summary; and other relevant details.
- Various operational requirements and specifications should be included. Examples include Labels, RFID, WMS, WES control requirements etc.
- Lists of integration messages and headers should be included.
- Processing Areas sections should be shown and natural-language descriptions of each area’s operations written. These may include:
- Yard Management
- Receiving & unloading
- Non-conforming inventory disposition
- Quality inspection and sampling
- Putaway
- Storage
- Replenishment
- Picking
- Value-Added Services processing
- Verification
- Manifesting
- Staging
- Loading & Shipping
- Inventory management processes
- Reporting
- Within each processing area section, equipment sizing, and capability is described along with the associated labor process that supports it. Flow-charts and process diagrams are great additions to the document and can avoid misunderstandings. In addition, systems (WMS, WES, sorters, etc.) system functionality and controls are described.
- Other relevant operational details can be included, including things such as storage profiles; planning procedures; picking and putaway strategies; etc.
Conclusion
The MPD takes a lot of effort to develop. Once it is complete, the operation has a documented, aligned baseline approach to operating. This can generate tremendous value during the project and serve as the guidepost for standard operations procedures.
We recommend to any operations team that they should develop such a document during the start-up phase. Even if–especially if–your team is experienced and “knows how it should be done”, they should put it on paper and use it to avoid expensive mistakes and rework later.
As always, your thoughts are welcome!
To learn more about developing the MPD and get help managing your complex projects, get in touch with PL Programs here.
Credit to Director of Engineering Eric Ashbaugh for contributing this article.