Why a Visual Routing Beats a Spreadsheet BOM

A visual routing beats a spreadsheet bill of materials because it shows the one thing a grid of rows cannot: the shape of the process. A routing is not just a list of operations. It is a set of dependencies, which step feeds which, where two paths merge, where a chain dead-ends before it reaches the finished product. Those relationships are the whole point of a routing, and they are exactly what disappears when you flatten them into spreadsheet rows. EDGEBIC by User Solutions draws the routing as a flow chart of connected nodes, so the logic you care about is the logic you can see.

This post makes the case for the visual view, then shows where the grid still earns its place. Both are covered in depth in the visual scheduling guide, the pillar for this cluster.

What a Routing Actually Is

A bill of materials tells you what goes into a product. A routing tells you how it gets built: the ordered operations, each with a work center, a setup time, and hours per unit. The word "ordered" is doing heavy lifting. Step 20 cannot start until step 10 finishes, unless you have deliberately set up overlap. A routing without its sequence is just a parts list with hours attached.

In a spreadsheet, that sequence lives in a column: a next-in-sequence value on each row that names the step after it. It works, in the narrow sense that the data is present. But you cannot read the flow from it. To trace one part's path through the shop you scan down the rows, hold each next-in-sequence value in your head, and jump back up to find the row it points to. For a linear three-step routing that is tolerable. For a routing with a sub-assembly feeding a final step, or two machines running in parallel, or a rework loop, the rows stop telling the story.

The Failure Mode Spreadsheets Hide

The dangerous spreadsheet routing is not the one with a wrong number. A wrong number produces a schedule that is off by hours, which someone usually notices. The dangerous one is structurally broken: a chain that never reaches the finished product.

Picture a five-row routing where step 40 was supposed to point at the finished product but instead points at a step that was later deleted. In the grid, row 40 looks fine. It has a work center, hours, a next-in-sequence value. Nothing on the screen flags it. Only when the job schedules do you find out that step 40 either landed in the wrong place or dropped out of the plan entirely.

EDGEBIC's routing designer will not let that mistake save. Every chain must arrive at the terminal end-product node, and the designer validates the diagram when you press save. A missing end product, a step that cannot reach the end product, or an end product with outgoing arrows are reported as errors on the spot. The fix is to complete the connector, not to save around the warning. A spreadsheet has no equivalent. It accepts a broken chain silently because a spreadsheet has no concept of "chain" at all.

Connectors Carry the Logic

On the canvas, each step is a node with an icon and a name. Each next-in-sequence link is a connector, an arrow from one node to the next. That arrow is not decoration. It is the same next-in-sequence value the grid holds, drawn instead of typed.

Because the logic lives in the arrows, the routing's shape becomes literal:

• A linear routing is a straight run of nodes: saw to drill to deburr to the finished bracket.
• A branch is two paths that merge: a sub-assembly node feeds into an assembly step, so the frame is ready when assembly needs it.
• A dead-end is a node with no arrow out, and it is impossible to miss because the eye follows arrows and stops where they stop.

EDGEBIC also computes a depth for each step from these connectors, a level that counts how far a step sits from the finished product. Level 0 is the step immediately before the end product; higher numbers are further upstream. You do not have to read that number, because the layout shows it: keep the diagram flowing one way, left to right, and depth is just position. A circular link (A feeds B feeds A) is caught and marked with a warning icon on the affected node, so a loop you created by accident cannot quietly confuse the schedule.

Where the Grid Still Wins

None of this means the grid is obsolete. EDGEBIC keeps both because each is better at a different job, and they are two views of one routing. Switch between them with the Data Grid and Designer toggles on the toolbar; anything you save in one view is exactly what the other shows.

The rule of thumb is short: grid for numbers, designer for structure. You type 0.25 hours per unit and 0.5 hours setup in the grid, then flip to the canvas to confirm the operation sits where you meant it to. Neither view is a second copy of the data. There is one routing behind both, and the data grid and flow chart are the same routing.

A Worked Example: The Bracket That Broke

Acme Industries has a steel bracket routing with three operations, held for years in a spreadsheet:

For a 500-unit order this schedules cleanly: sawing runs about 11 hours (0.02 x 500 + 1.0 setup), then drilling, then deburring, each step waiting for the one before. Read as rows it is fine because it is short and linear.

Now engineering adds a plating step between drill and deburr, and someone edits the spreadsheet in a hurry. They add a plating row but forget to change S20's next-in-sequence value, which still points at S30. The plating row points at S30 too. Two rows now feed deburr, and nothing feeds plating. In the grid, every row looks complete.

Drawn on the canvas, the break is a glowing red flag: the plating node has arrows pointing out but no arrow pointing in, so it floats disconnected from the chain. Press save and EDGEBIC reports that a step cannot reach the finished product. You draw one connector from drill to plating, and the routing is correct. The spreadsheet version would have scheduled 500 brackets with the plating step orphaned, and the first anyone would have heard of it is a supervisor asking why the plating machine has no work.

The Bigger Point: Run the Factory as a Flow Chart

User Solutions has been building scheduling tools for manufacturers since 1991, for shops and for names like GE, Cummins, BAE Systems, and the US Navy. The lesson across 35 years is that planners reason about their shop as a flow, not as a table. A routing is a small map of that flow. When the map is drawn, mistakes look like mistakes and the shop's logic is legible to anyone who walks up to the screen.

That is the argument in one line. A spreadsheet stores a routing. A flow chart lets you read it. For the schedule that comes out the other side, being able to read the routing is what keeps production scheduling honest, and it is the same reason a Gantt chart beats a dispatch list once the work is on the floor.

Bring one of your workbook routings to a demo and draw it. Give US a chance to show you what the rows were hiding.