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. It is not a perfect measure, since a single screen can be dense and confusing. But screen count tracks the number of system boundaries a user has to 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.

A team that needs 14 screens for a delivery receipt will be averaging nine or so across its most common tasks. Two years into the system, they still don't use the three-way match module. They reconcile by hand in a spreadsheet, because the spreadsheet is faster. The system has the feature. The feature just takes 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. 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). All of those tables need 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 real 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.

The order of work matters. Clean the supplier master data, standardize the PO reference formats, and link goods receipt records to their originating POs before anyone writes a line of AI integration code. An AI interface built after that works, and it works because the data is finally consistent, not because the AI is 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 start. 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 exception management full time, not routine work interrupted by exceptions. 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. 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

One metric is the best predictor we know of whether a supply chain system will 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 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 adoption of the new module is low, because the team is already carrying the overhead of the existing ones.

For many operations teams the honest answer is a usability audit of the current system, a consolidation project for the highest-friction workflows, and a data cleaning exercise so the system's existing features work. A new system or more features will not fix it. That is less exciting than a new AI-powered platform. It is also far cheaper than a replacement, and it takes months instead of years.