Why Your Supply Chain Software Has Too Many Screens

Supply chain software is not bad because vendors are incompetent. It is bad because it was designed by people who understood the data model and the business rules but never stood at a receiving dock at 3pm on a Friday with three trucks backed up, a delayed shipment from the previous day still unprocessed, a supplier rep on the phone, and a supervisor waiting for the inventory update to release a manufacturing order.

The result is software that is technically complete and operationally punishing. Every workflow is there. Every field is present. Every process is supported. The system just requires fourteen screens to do what a paper-based process accomplished with a clipboard and a phone call. This is the supply chain software problem: not missing features, but wrong design assumptions about how work actually happens.

The screen count metric

We use screen count as a first-pass metric when evaluating supply chain software. Not because it is a perfect measure — a single screen can be dense and confusing — but because screen count correlates strongly with the number of system boundaries a user must cross to complete a task. Each boundary is a context switch. Each context switch is a chance for the user to lose track of what they were doing, enter data in the wrong place, or decide the workaround is faster.

The metric: pick your five most common operational tasks and count the number of distinct screens required to complete each one from start to finish. Include navigation between modules. Include confirmation screens. Include the "saved successfully" pages that require a click to dismiss. Add them up. If the average is above 6 screens per task, the system has a usability problem that feature training will not solve.

The client with 14 screens for a delivery receipt had an average of 9.3 screens across their five most common tasks. The team had been on the system for two years and was still not using the three-way match module — they were reconciling manually in a spreadsheet because the spreadsheet was faster. The system had the feature. The feature just required too much friction to use.

AI overlays fail if the data model is wrong underneath

The current vendor pitch for supply chain software problems is an AI overlay: a conversational interface or intelligent assistant built on top of the existing system that lets users ask questions and perform actions in natural language rather than navigating screens. We have built these. They work in demos. They fail in production when the underlying data model cannot support the queries users actually ask.

"What is the current status of the Riyadh delivery from Al-Noor Trading?" is a simple question. Answering it requires joining the purchase order table (for supplier reference), the goods receipt table (for delivery status), the quality inspection table (for QC hold status), and the warehouse management table (for put-away status) — and all of those tables have to have the same supplier ID format, and the records have to be linked by a consistent document reference. In a legacy supply chain system with five years of inconsistent data entry, that query returns nothing useful.

The AI overlay problem is that it makes the data model problem more visible without fixing it. Users ask questions, get incomplete or wrong answers, and conclude the AI does not work — when the actual problem is that the underlying data was never clean enough to support the query. Before any AI layer can add value, the data foundation has to be solid: consistent entity identifiers, linked records, complete fields on the transactions that matter.

On a logistics client project last year, we spent six weeks cleaning supplier master data, standardising PO reference formats, and linking goods receipt records to their originating POs before writing a line of AI integration code. The AI interface we built afterward genuinely worked — but it worked because the data was finally consistent, not because the AI was sophisticated.

Consolidation patterns that reduce friction without a full migration

Most supply chain teams cannot migrate to a new system in the short term — the cost, disruption, and risk are too high. The practical path is consolidation: reducing screen count and cognitive load within the existing system, and building lightweight interfaces for the highest-frequency tasks that bypass the system's full navigation structure.

The first consolidation target is always the receiving workflow. It is the highest-frequency task in most warehouse environments, it involves the most time pressure, and it is where data quality problems originate — a receiving clerk under time pressure who skips fields creates reconciliation problems downstream for days. A single-screen receiving interface that pre-populates from the PO, requires only confirmation fields rather than re-entry, and posts to all relevant modules in one action typically cuts screen count from 8–14 to 2–3. We build these as lightweight web applications on top of the ERP's API, not as ERP modifications.

The second target is exception visibility. Supply chain work is not routine work interrupted by exceptions — it is exception management full time. A driver reports a short delivery. A QC hold on a critical component blocks a production order. A supplier invoice does not match the received quantity. The system has all of this information. It is distributed across six modules with no single view. Building a consolidated exception dashboard — one screen showing everything that needs attention today, ranked by operational impact — changes how the team works. They stop firefighting and start managing.

The one metric that predicts system adoption

We have settled on one metric as the strongest predictor of whether a supply chain system will actually get used as designed: task completion rate without supervisor intervention. Pick your five most common tasks. Sit next to a new team member doing each one for the first time. Count how often they complete the task correctly without asking for help or looking up a reference document.

Systems with high completion rates have workflows that match how users think about the work. Systems with low completion rates have workflows designed around the system's data model rather than the user's task model. The difference shows up in system usage data within six months of go-live: low-completion systems develop shadow processes, usually spreadsheets, that parallel the system for the tasks users find confusing.

We measure this at the start of every supply chain engagement and again six months after any implementation. The delta tells us whether the system is being adopted or worked around. A system where 60% of transactions go through the correct workflow and 40% go through the workaround is not a 60%-successful implementation — it is a system with a data quality problem in the making, because the 40% that bypasses the system does not feed the analytics, the compliance reporting, or the AI features the business paid for.

Supply chain software that is not used as designed is not a training problem. It is a design problem. Adding more training budget to a system people route around is one of the most reliable ways to waste money in operations.

The honest conversation about legacy supply chain software

Most supply chain teams are running software that was the right choice five to ten years ago and has not kept pace with how operations work now. The vendor has added features. The system has not fundamentally changed. Every year there is a new module — AI-powered demand forecasting, predictive maintenance, supplier risk scoring. Every year the adoption rate for the new module is 20–30%, because the team is already managing the overhead of the existing modules.

The honest answer for many operations teams is not a new system and not more features — it is a usability audit of the current system, a consolidation project for the highest-friction workflows, and a data cleaning exercise so that the system's existing features actually work. That is less exciting than a new AI-powered platform. It is also $800K cheaper and takes six months instead of two years.