Important Terminology

On numerous occasions, we have observed how careless use of language and technical terms has led to problems, both technical and legal. Because cause and effect are separated by a time delay, often several months, people tend not to learn from their mistakes. Lawyers are trained in using precise language – engineers not so much (beyond the very precise language of mathematics). In particular, below terms tend to be conflated and frequently are used interchangeably.

Capacity of a System or of an Element of a System

The capacity of a system or of an element of a system in the context of material flow systems describes the maximum possible throughput, as enabled by the technical equipment and concept employed, measured in throughput units per time unit, e.g., pallets/hour or bins/hour [1].

In some MHE companies, people differentiate between Technical Capacity and System Capacity. The former describes the theoretical maximum throughput when merely looking at (1) the specific element in isolation (say, a shuttle lift) and (2) its acceleration and velocity. This value tends to be pure engineering phantasy and nobody who has to deal with reality cares about it, yet it is frequently used, either out of lack of awareness or deliberately to impress customers with how advanced and speedy one’s equipment is. In reality, this value is almost never reached, which at some point in the project leads to frustration on part of the customer (best case), to serious legal trouble (worst case) e.g., when acceptance test requirements cannot be met, or to the necessity to redo some of the layout in a late stage (frequent case). There are four essential reasons why working with Technical Capacity is problematic:

  1. Elements of a system often do not carry out identical movements but are subject to a broad mix of motion. Think of the shuttle lift: it does not always carry out the exact same sequence of storage and retrieval movements from and to exactly the same levels. In fact, the different storage levels served by the lift can depend on (a) customer orders (which you cannot influence) and (b) software control (which your Software Engineers do influence, yet their heuristics often leave room for improvement). Cycle time calculations of AS/RS (according to FEM 9.851), e.g., pallet cranes in a High Bay Warehouse, take this into account and specify the exact movements to be used for the calculation of capacity. Yet, such calculations do not exist for every piece of equipment, such as shuttle lifts or shuttles in specific setups (e.g., lifts located on both sides of the aisles or alongside the aisles), hence leaving values of Technical Capacity to the somewhat arbitrary and sometimes optimistic guesstimates of Product Managers.
  2. By deriving it from assumed maximum acceleration and velocity, Technical Capacity reflects an instantaneous value rather than one that can be maintained over any significant period of time. Technical elements require maintenance and they occasionally wear out or break, throughput items can fall over or spill, load carriers can be damaged and barcodes can be unreadable, there is human error and there is software hick-ups or even systematic problems, all of which lead to interruptions or lower throughput at some point. This means that the ability to derive capacity in terms of throughput units per time unit may be given for small time units but tends to be problematic when using the most commonly used time unit: hour. It is intellectually dishonest to look at the physical parameters of a technical element and assume that these parameters determine the element’s capacity in term of items/hour when, in fact, the element is unlikely to run uninterrupted for an hour straight.
  3. Elements of a system are just that: elements of a system. They do not exist in isolation but are connected to other elements. As such, their performance (see below) is dependent on other elements’ capacity, too. While this does not inhibit an element’s Technical Capacity, it does change the performance it delivers in combination with other elements of the system. Real systems do not exist in deterministic environments and any variability the system is subjected to will decrease its performance when elements of the system are dependent on each other’s input and output. Technical errors, human errors, differences in operator speed, and customer orders all create variability. We will elaborate on this point in a different article.
  4. In systems with dependence and variability, you can show mathematically that the queue length – the number of items waiting in front of a machine or other technical elements that processes items – approaches infinity as throughput approaches the limit of Technical Capacity. You will still get reasonably high throughput, but your WIP and Cycle Time will skyrocket.

People understand that a chain is only as strong as its weakest link; likewise, most people understand that a material flow system consisting of serial elements is limited by its slowest element. When you look at a material flow system, however, and you look at the slowest element in terms of Technical Capacity – it is unlikely to enable the throughput the numbers suggest, and this is important to understand.

Therefore, there is the concept called System Capacity. System Capacity assumes there will be interruptions and that elements of the system will frequently perform below their Technical Capacity. As a rule of thumb, conservative engineers often deduct 20% from Technical Capacity to arrive at System Capacity; optimistic (aggressive) sales people often deduct merely 10% (assuming they have enjoyed some technical training and deduct anything at all). While these are merely approximations, they capture reality much better than Technical Capacity does.

Whether you are a Logistics Engineer, a Sales Manager or a Project Manager on customer side who is in charge of selecting the right system and the right vendor in a bidding process, it is of utmost importance that you understand the difference between Technical Capacity and System Capacity. As a customer, you alarm bell should ring if the Sales Manager or Sales Engineer is not able to answer your question what kind of capacity their planning is based on in the system they offer you.


Performance is such a terrible term. People frequently do not know what they are talking about when they say performance, and because the term is so generic and overused, the people who they are talking to won’t even notice it, nor will they themselves [2]. In discussions of material flow system, the term appears in combinations such as Picking Performance, System Performance, and Performance Test. Generally, performance can be defined as the degree to which expectations of relevant stakeholders are met. Different stakeholders have different interests. Therefore, performance measures vary widely and can relate to diverse measures such as Service Level, days of operation without injury, picking errors, productivity per employee in units per hour processed (UPH), return on investment (ROI), and average throughput reached, all of which are very common in the context of automated logistics systems.  

If we talk about throughput specifically, the upper boundary of expectations is determined by the system’s capacity.

Importantly, all these measures are technically incomplete as performance measures since they do not imply and reflect expectations (look at the definition again). An ROI period of five years for a large automated system is great – unless you planned for three years. UPH of 120 is remarkable – unless you calculated it should be at 150. Therefore, technically, performance needs to be expressed as a fraction or percentage, which almost nobody ever does. Often, in conversations among professionals who work with a specific system, people know their mutual expectations and it is much more convenient and useful for them to talk about performance values in absolute terms without frequent reference to some level of expectations. In other cases, a distinction is made between performance measures and performance indicators, where the former relates to absolute numbers whereas the latter relates to a fraction or percentage consisting of the absolute number in comparison to the set expectation. This may be the most practical way to approach it.

All of this said, be careful not to conflate performance with capacity. Broadly speaking, capacity is what you can get out of a system or part of a system whereas performance is what you actually get.

Performance Requirements

Performance requirements describes the performance as demanded by the customer (or any other party that provides the impetus for the planning activity). It normally is derived from the results of data analysis and is specified in the Employer’s Requirements Specification (or Request for Quotations or Request for Proposal) or communicated by other means. It determines the minimum capacity needed (excluding safety factors and similar) in the system or in part of the system.


Throughput is one of several important performance measures in a material flow system. It is the most dominant performance measure in many planning efforts and, importantly, it is one that is easy to measure. The measurement unit is items per time unit, and for system design it tends to be units per hour (e.g., cartons per hour, totes per hour, collies per hour…).

Literature Recommendations

Hopp, Wallace J.; Spearman, Mark L. (2011): Factory Physics. 3. ed., international ed. Boston: McGraw-Hill.

Lebas, Michel J. (1995): Performance Measurement and Performance Management. In International Journal of Production Economics 41 (1-3), pp. 23–35. DOI: 10.1016/0925-5273(95)00081-X.


Download this text as a PDF document:

[1] Since elements of a material flow system in most cases do not create items but convey or otherwise transport them, we deliberately use throughout rather than output.

[2] The interested reader is referred to Lebas (1995) for a more elaborate discussion of this point.

Leave a Reply