Network Development: Building a Warehouse Automation Strategy Beyond the Four Walls

When organisations think about developing a warehouse automation strategy, the conversation usually starts inside the building.

How much throughput do we need? What storage density can we achieve? Which technologies should we consider? How do we reduce labour dependency?

All are valid questions. But for a business operating multiple distribution centres, there is a bigger question that should come first:

Are you automating the right building?

It may sound obvious, but it is easy to overlook.

Distribution networks develop over years, sometimes decades. Sites are added as businesses grow. Acquisitions bring new facilities into the network. Customer locations change, product ranges expand and ecommerce introduces different fulfilment profiles.

What was once a logical network can gradually become something quite different.

Then one site reaches a constraint and automation becomes the answer.

There is nothing necessarily wrong with that. The problem comes when we assume that improving an individual distribution centre will automatically improve the network around it.

“An efficient automated warehouse can still sit inside an inefficient distribution network.” – Dan Migliozzi

This is where Network Development changes the conversation.

Rather than starting with an individual facility or a particular technology, it considers the role of each site, how inventory and orders move across the network, where future capacity is likely to be needed and where automation can create the most value.

The objective is not more automation.

It is the right automation network.

Look Beyond the Building

I have seen automation discussions begin with a building that has effectively already been chosen.

The site exists. Volumes are increasing. Labour is becoming difficult. Capacity is tightening. The natural conversation is therefore about what can be put into that building.

That may well be the right conversation, but I do not think it should automatically be the first one.

Before committing significant capital to a facility, it is worth understanding the role that facility is expected to play in five or ten years.

Will the same products still flow through it? Will customer demand remain in the same locations? Could inventory be positioned differently? Is there usable capacity elsewhere in the network?

There are practical considerations too. A building can be in the right geographical location but unsuitable for the automation being considered. Height, column grids, floor condition, yard space, power availability and expansion potential can all begin to dictate the solution before the design has really started.

Then there is the harder question:

If you were designing the network today, knowing what you know about the business now, would you put that distribution centre there at all?

Sometimes the answer is yes.

Sometimes the answer creates a much bigger conversation.

Either way, it is better to have that conversation before the automation is installed.

Start With Flow, Not Technology

Network Development should begin with understanding how the business actually operates.

Where does product enter the network? Where is inventory held? Where are the customers? Which service levels genuinely matter? Which sites are approaching capacity, and which have room available?

On paper, some of this sounds straightforward. In practice, the picture can be complex.

The fastest-growing customer base might be moving away from an existing distribution centre. A site with apparent spare capacity may not have the right labour profile or building characteristics to use it effectively. Inventory may have accumulated in certain locations due to historical decisions that no longer make operational sense.

This is why automation technology should come later in the conversation.

Starting with a technology makes it easy to begin designing the operation around that solution. Once significant time has been invested in a concept, it becomes increasingly difficult to challenge the assumptions underneath it.

The sequence should be the other way around.

Understand the network and its flows first. Define the role each facility needs to perform. Understand its processes, capacity and service requirements. Then decide what should be automated.

For an integration partner, this distinction matters. The objective should not be to fit a preferred technology into an operation. It should be to understand the operational requirement first, then bring together the appropriate automation, software and controls around it.

Different Sites Need Different Answers

There is a temptation, particularly across larger organisations, to standardise everything.

There are good reasons for this. Common controls, software, equipment and maintenance practices can make a network easier to support. Standardisation can also simplify training, spare parts, integration and future projects.

However, standardisation does not mean every distribution centre should look the same.

One facility might handle a predictable range of fast-moving products where high levels of automation make complete sense. Another could carry thousands of slower-moving SKUs with volatile demand, making flexibility far more important than maximum automation density.

A third may have a completely different purpose. Its value may simply be its proximity to a major customer population and the service level that location enables.

They are all distribution centres, but they are not doing the same job.

Their automation strategies should recognise that.

“Network Development is not about finding one automation answer and repeating it. It is about understanding what each part of the network needs to do.” – Dan Migliozzi

In some locations, extensive automation will be the right answer. In others, a targeted investment could deliver a stronger return. There will also be facilities where retaining manual processes provides flexibility that the wider network needs.

Occasionally, the analysis may show that the best investment in a particular building is no investment at all.

That is still an automation decision.

Capacity Is a Network Question

Consider a distribution centre approaching capacity.

The instinct is usually to create more capacity there. Extend the building, increase storage density, introduce automation or find a way to push more volume through the existing footprint.

Sometimes that is exactly what needs to happen.

Before investing, however, it is worth understanding why that site is full.

The issue might be inventory allocation rather than physical capacity. Another facility could be underutilised. Certain product families might be better served elsewhere. Customer allocation may have changed since the network was originally designed.

In those circumstances, creating additional capacity at the constrained facility risks treating the symptom rather than addressing the underlying network issue.

This becomes particularly important with automation because major infrastructure decisions can be difficult and expensive to reverse. Systems installed today may remain operational for decades, during which the facility’s role could change considerably.

Instead of only asking:

“How much more can we fit in this building?”

A better question may be:

“Where does the network actually need capacity?”

Then comes an equally important question:

When?

Capacity required in two years may demand a very different investment strategy from capacity that may not be needed for another eight years.

Inventory Changes Everything

Inventory and automation strategies are closely linked, yet they are often developed through separate conversations.

The connection is simple:

Move inventory and you move workload.

Centralising stock can improve inventory utilisation and reduce duplication, but it may increase transport distances or make certain service levels harder to achieve.

Positioning more inventory closer to customers can improve responsiveness, but it also means managing stock across more locations.

Neither approach is automatically right or wrong.

It depends on the network.

What matters from an automation perspective is understanding those trade-offs before the solution becomes fixed.

A system designed around today’s SKU profile, inventory allocation and order characteristics may perform well. Move a significant proportion of inventory several years later and the same system could suddenly be operating against a very different profile.

This is where Network Development and automation design have to meet.

You cannot make a sensible long-term decision about one without understanding what might happen to the other.

Plan for More Than One Future

One reality of long-term automation planning is that it is not possible to know exactly what the business will look like in ten years.

Forecasts still matter. Historical data, commercial input and credible assumptions around growth give us something tangible to design against.

What they cannot give us is certainty.

I have always found it more useful to think in scenarios rather than trying to create one fixed version of the future.

What happens if growth is higher than expected? What if it is lower? What if ecommerce becomes a much larger part of the operation? What happens if the SKU range changes or an acquisition introduces another distribution centre into the network?

The purpose is not to predict every possible outcome. That would require extensive modelling with limited practical value.

The useful part is identifying where the network begins to struggle.

Perhaps one site becomes a bottleneck under almost every growth scenario. Another facility may become strategically important if customer demand shifts geographically. A proposed automated solution may perform well at the expected volume but offer limited flexibility above or below it.

Those are valuable things to know before the purchase order is placed.

“A sound network strategy does not need to predict the future perfectly. It needs to give the business options when the future changes.” – Dan Migliozzi

Build an Investment Roadmap

Automation does not have to happen all at once.

A strong network strategy should give an organisation a roadmap, particularly when capital is limited.

When that wider view is absent, investment naturally follows operational pressure. One site reaches capacity and receives capital. Two years later, another facility develops a different constraint and another project begins. Volumes move again and suddenly a third site requires urgent attention.

Every individual decision may be justifiable.

The problem only becomes visible when you look across the network.

You can end up with several successful automation projects that do not form a coherent automation strategy.

Network Development allows investment to be sequenced in line with a longer-term direction.

One site might be identified as the future automated hub, justifying significant investment now. Another may only require modest changes to extend its useful life. A third could eventually be consolidated once capacity becomes available elsewhere.

The answer will be different for every organisation.

What matters is that there is a reason behind the sequence.

Capital can then be invested in line with a strategic direction rather than in whichever operational problem happens to be most urgent at the time.

Avoid Creating Automation Islands

This becomes increasingly important as organisations automate more facilities.

Individual projects can perform successfully while collectively creating unnecessary complexity.

One site uses one control architecture. The next introduces different software. Another has a new interface or data structure. Maintenance teams require different skills, spare parts become fragmented and similar integrations are developed repeatedly in slightly different ways.

Viewed individually, none of those decisions may seem particularly concerning.

Across a network of ten or twenty facilities, they start to matter.

Network Development provides an opportunity to decide where consistency creates genuine value before individual projects make those decisions independently.

That does not mean forcing identical equipment into every building.

In fact, doing so can create the opposite problem by making the operation fit the standard rather than selecting what the operation needs.

“A common architecture is more useful than identical hardware.” – Dan Migliozzi

Software, controls, data, safety, integration, and support can follow shared principles, while the physical automation remains appropriate to each facility’s role.

That balance matters.

Too little standardisation creates unnecessary complexity. Too much can force the wrong solution into the wrong operation.

This is also where integration becomes important. Individual technologies cannot be considered in isolation if the wider objective is to create a scalable, connected operation. Controls, software, automation, existing infrastructure, and third-party technologies need to work as part of a single operational architecture.

The Business Case Is Bigger Than the Warehouse

Warehouse automation business cases naturally focus on what happens inside the facility: labour, throughput, storage density, accuracy and operating cost.

They should.

Network Development also widens the boundary of that business case.

Transport costs can change depending on where facilities and inventory are located. Inventory holding costs can increase or decrease. Property may be released. Service levels can improve. A different network design could reduce exposure to difficult labour markets or remove the need for another capital project several years later.

Those benefits do not always sit neatly within the automation project budget.

Neither do all the costs.

An automated facility might produce an attractive standalone return while reinforcing a network that requires excessive transport, duplicated inventory or additional property elsewhere.

“The numbers inside the facility can look excellent while the network around it is becoming more expensive.” – Dan Migliozzi

If the analysis stops at the warehouse door, that wider impact can easily be missed.

A credible business case needs to understand both.

Data Informs the Decision. People Make It.

Network Development can sound like a modelling exercise. Put enough data into a model, run enough scenarios and eventually it tells you where everything should go.

Real operations are not that tidy.

Operations teams understand things the data will never fully explain. Property teams know lease events, planning constraints and the limitations of individual buildings. Supply chain teams understand how inventory really behaves. IT understands where architecture and integration can be challenging. Engineering knows what can realistically be automated, while Finance understands what the business can afford and when.

Those perspectives matter because there will always be trade-offs.

Closing a facility might appear favourable in a model but create unacceptable operational risk. Centralising inventory may improve working capital while negatively affecting service. The most technically suitable automation solution may simply require too much capital at the wrong point in the business cycle.

These are not failures in the Network Development process.

They are the process.

The value comes from making those trade-offs visible so the business can make informed, deliberate decisions.

The model informs the decision. It should never be expected to make it.

From Automated Warehouses to an Automated Network

There is an important difference between owning several automated distribution centres and having an automated network.

You can arrive at the first simply by completing enough projects.

The second must be developed intentionally.

A developed network has clear roles for its facilities. Inventory is positioned with purpose. Capacity is considered across sites rather than only within them. Technology standards exist to make the organisation easier to operate, and investment occurs in a sequence that supports where the business is trying to go.

Most importantly, automation supports the network strategy rather than defining it.

For me, that is the shift Network Development needs to create.

Instead of only asking:

How do we automate this distribution centre?

We should be asking:

What should our future distribution network look like, and where will automation make the biggest difference?

The right automation decision is not always about choosing between a robot, shuttle, conveyor or storage system.

Sometimes it is deciding where to automate in the first place.

Turning Network Strategy Into an Automation Roadmap

At AGITO Global, Network Development is about creating the strategic foundation for better automation decisions.

That means looking beyond an individual piece of equipment or facility to understand material and inventory flows, capacity requirements, operational constraints, future demand and the role different sites need to perform.

From there, Network Development can inform the next stages of automation planning and Solution Design, helping organisations determine where to prioritise investment, what level of automation is appropriate, and how individual solutions can fit within a coherent, wider architecture.

This reflects a broader principle behind AGITO’s approach to integration: technology should be selected and integrated around the needs of the operation, not the other way around.

For organisations reviewing their distribution networks, the principles are straightforward:

Start above the site level

Understand what each facility is expected to contribute to the future network before developing an automation concept around it.

Follow the flow

Understand where products enter, where inventory sits, how orders move and where customers need to be served.

Challenge the existing estate

A building should not automatically receive investment simply because it already exists. Location, layout, height, expansion potential, labour availability and long-term purpose all matter.

Plan for more than one future

Use scenarios to understand what happens when growth, SKU profiles, channels, or customer requirements deviate from the expected case.

Give facilities a purpose

Different sites can justify very different levels and types of automation. Consistency is valuable. Uniformity for its own sake is not.

Phase the investment

Be clear about what needs to happen now, what can wait and what conditions should trigger the next stage.

Standardise intelligently

Common principles for software, data, controls, integration, and support can reduce complexity without forcing identical physical solutions across facilities that do very different jobs.

Finally, keep challenging the network

Customer demand changes. Businesses grow. Products and channels evolve. Network Development should therefore be revisited rather than completed once and left on a shelf.

The Right Automation Network

Automation is a long-term commitment.

Some of the systems being designed today will still be operating long after the assumptions that justified them have changed.

That is why the conversation must extend beyond the four walls of the distribution centre.

The organisations that get this right will not necessarily be those with the greatest amount of automation. They will be the ones that are more deliberate about where it belongs.

Some facilities will justify significant investment. Others will need flexibility. Some may perform very different roles in the future, and, in certain cases, a facility may no longer belong in the network at all.

Getting to those answers requires data, modelling and technical expertise, but it also requires judgement. Existing assumptions need to be challenged, and local operational problems need to be considered in the context of what is happening across the wider network.

You can design an efficient automated warehouse.

The wider objective is making sure it is the right warehouse, in the right place, doing the right job for the wider network.

“The goal is not more automation. It is the right automation network.” – Dan Migliozzi

That is Network Development.

About the Author

@Dan Migliozzi is Sales Director for the UK, EU and North America at AGITO Global, with over 12 years of experience in automation across manufacturing, logistics, warehousing and ecommerce.

He has led complex automation sales, solution design and project delivery for tier-one and blue-chip organisations. At AGITO Global, Dan directs commercial strategy and client engagement, helping organisations scale and optimise warehouse and intralogistics automation solutions.

He is a professional member of the Institution of Engineering and Technology (MIET) and an Associate Member of the International Society of Environmental Professionals (AISEP), reflecting his commitment to sustainability and responsible innovation.

Dan believes that successful automation comes from aligning technology, people and strategy to create operations that are efficient, resilient and ready for what comes next.