An MLA project does not begin with the question that is so often asked:
Which solution should we use?
Self-checkout?
Self-scanning?
Scan & Go?
Self-order terminal?
Kiosk?
Because that question usually comes far too early.
Before technology, suppliers or specific equipment come into focus, an MLA project first clarifies which problems need to be solved and which goals need to be achieved.
Sounds obvious? In practice, this step is often skipped.
An MLA project starts with goals – not with technology
The introduction of self-service can serve very different purposes (see also Diebold Nixdorf Blog: Redesigning the Self-Checkout Experience). One retailer may want to reduce labour costs. Another may aim to increase floor space productivity. A third may want to shorten waiting times or offer customers additional ways to complete their purchases.
Other objectives may include:
- making better use of available floor space,
- providing more flexibility during fluctuating customer traffic,
- improving the customer experience,
- reducing pressure on staff,
- increasing process speed,
- improving scalability, or
- reducing inventory discrepancies and losses.
Several of these goals may be relevant at the same time. However, they are not identical.
And that distinction matters.
Depending on which goals take priority, the requirements for layout, technology, processes, staffing, data analysis and loss prevention will change.
For example, retailer primarily looking to improve throughput and reduce waiting times, for example, will need to set different priorities from one whose main concern is high inventory discrepancies.
Therefore, a self-service project therefore needs a clear definition of its objectives first.
Only then should the discussion move on to the solution itself.
What is the starting point of an MLA project?
Alongside the objectives, a second question is crucial at the outset:
Where does the organisation stand today?
Here too, starting points can differ considerably.
One retailer may be considering self-service for the first time. Another may already be running a pilot store. A third may operate several hundred systems and now want to optimise existing processes.
Typical starting points include:
- initial strategic considerations,
- preparing a pilot project,
- evaluating different self-service concepts,
- preparing for a roll-out,
- optimising existing installations,
- analysing recurring process problems, or
- stabilising a project that has not delivered the expected results in day-to-day operation.
These differences have a major influence on how an MLA project should be structured.
An organisation considering self-checkout for the first time initially needs orientation and structure.
A retailer already operating 300 systems may no longer need a fundamental discussion about the technology. Instead, the focus may be on better understanding intervention rates, customer flow, system data, staff organisation or inventory discrepancies.
The methodology must therefore reflect the actual starting point.
The Multi-Level approach is not a rigid model
My first article in this series introduced exactly this principle: Self-service should not be treated as an isolated technology project, but as a system of several interconnected levels (see Retail Engineering: Rethinking Self-Service – Structure Before Decision.).
The Multi-Level Approach (MLA) maps these relationships across five levels.
Objectives, starting point and level of maturity determine which of these levels require particular attention in a specific project.
The graphic illustrates the underlying logic: from the strategic decision and the layout of the SCO zone through to network and data use, usability and customer experience, and finally loss prevention.
This second article focuses primarily on the first two levels.
Level 1: What is Self-Service supposed to achieve?
Level 1 begins with the fundamental question of whether self-service makes sense for the specific use case and under which conditions.
At this stage, the focus is not yet on manufacturers, equipment or specific technical solutions.
The key issues are objectives, commercial viability and the relevant framework conditions.
What needs to be achieved? Which problems should the project solve? What expectations exist regarding staffing, floor space productivity, throughput, customer experience or inventory discrepancies?
At the same time, the starting point is also part of this assessment.
An organisation considering self-checkout for the first time faces different decisions from a retailer already operating several hundred systems and looking to optimise existing processes.
Level 1 therefore creates the basis for deciding why self-service should be used and which requirements result from that decision.
Only once these questions have been sufficiently clarified can the next step be planned on a sound basis.
Level 2: Turning goals into a functional SCO zone
With Level 2, the strategic objective becomes a concrete spatial and operational task.
However, even the best self-checkout technology will not automatically work well simply because the equipment has been installed.
What matters is how the entire SCO zone is designed and integrated into the store.
This raises questions such as:
- Where should the SCO zone be positioned within the store?
- How should customers be guided into and out of the zone?
- How many SCO systems are required, and how should they be arranged?
- Where should the attendant be positioned, and how well can the entire zone be monitored?
- How should waiting areas, access points and potential bottlenecks be designed?
- How can usability, accessibility and loss prevention be considered in the layout from the outset?
- How does the zone integrate with existing customer routes and checkout processes?
Importantly, these are by no means purely design-related questions.
The layout directly affects how easily customers understand the self-service process, how quickly staff can intervene, how effectively the area can be monitored and how efficiently the available floor space is used.
That is precisely why SCO zone layout forms a separate level within the MLA.
Why Levels 1 and 2 belong together
The connection between the two levels is crucial.
Level 1 answers the “why”. Level 2 translates that “why” into a spatial and operational structure.
For example, if the main objective is to reduce waiting times, the resulting zone design may look very different from a project focused primarily on staff efficiency or loss prevention.
Likewise, higher floor space productivity cannot be considered in isolation.
Placing more SCO units into the smallest possible area is not automatically the better solution. An overly compact arrangement can impair customer flow, accessibility or the attendant’s ability to manage the zone effectively.
Strategic objectives and layout decisions must therefore not be considered separately.
This is where the systems thinking behind the Multi-Level Approach becomes particularly clear.
How deep should an MLA project go?
Another key decision concerns the depth of the project.
Not every self-service project requires an extensive analysis lasting several months. In some cases, a compact strategic review is enough to identify risks, open questions and potential areas for action.
In other cases, however, a much more detailed assessment is required.
The focus may then include areas such as:
- business case and commercial targets,
- zone layout and customer flow,
- process logic and operational procedures,
- network architecture and data use,
- usability and customer acceptance,
- requirements for employees and attendants,
- loss prevention and risk management, and
- interfaces between technology, operations and organisation.
The aim is not to examine as many topics as possible.
Instead, the focus should be on the right topics at the depth actually required.
This is one of the key advantages of the Multi-Level Approach.
Good projects start with better questions
Once goals, starting point and project depth are clear, the quality of the subsequent decisions changes.
It becomes much easier to determine:
- Which MLA levels are particularly relevant?
- Which parts of the organisation the project should involve?
- Which data are required for evaluation?
- Which risks need early analysis?
- Which decisions must be considered in combination rather than in isolation?
A general question such as
“Which self-service technology should we use?”
then becomes a much better one:
“What do we want to achieve with self-service, and which relationships do we need to understand before we invest?”
The difference may appear small.
For the success of the project, it is significant.
Before selecting the most appropriate solution, you need to understand how different technology choices will affect the overall system.
Goals first. Technology later.
An MLA project therefore does not begin with a product catalogue.
It begins with classification and context.
What needs to be achieved?
Where does the organisation stand today?
What experience is already available?
Which problems need to be solved?
How deep should the analysis go?
How must strategic goals be translated into a functional SCO zone?
The answers to these questions create a sound basis for technology, layout and investment decisions.
The Multi-Level Approach does not add another process simply for the sake of process.
Instead, it creates structure.
As a result, decisions are less likely to be made in isolation before their impact on the overall system is understood.
Goals first. Technology later.
That is how an MLA project starts.
The next article looks at how self-service data can be turned into sound decisions. Which information really matters, how operational problems can be identified, and how measuring and understanding lead to more effective management.
