Twelve apps, one Tuesday

At 01:07 on a Tuesday, an email arrives at a furniture maker: Riva Trading, the hardwood supplier, moving Thursday’s delivery to Monday. Four days. Not a catastrophe: a completely ordinary operational fact. What happens to that fact over the next eight hours is the clearest picture we know of why business software fails, and it has nothing to do with any single tool being bad.

Follow the fact around the company. The email sits unread (reasonably, everyone’s asleep). The inventory system knows hardwood cover is down to two days, and displays this faithfully to nobody. The production planner shows Line 2 fully scheduled Thursday, built on a delivery that is no longer coming. The CRM holds a note from March saying Hotel Bruma (thirty sideboards, the biggest open order) is sensitive about delivery dates; nobody has opened that account page in weeks. The accounting system has the Riva invoice politely waiting on goods. The master spreadsheet that is supposed to tie all this together was last edited nine days ago. At 08:12, someone asks in the ops channel whether anyone knows what’s up with the Riva delivery, and gets three shrug emojis.

§Every app is right. The company is wrong.

Notice what’s not broken here. No tool malfunctioned. No data is missing. Every single fragment (the email, the stock level, the schedule, the CRM note, the invoice status) is accurate and sitting in a system that was bought, configured and paid for precisely so that this kind of thing wouldn’t happen. The failure lives entirely in the joins. The delay only means something when the email meets the schedule, the schedule meets the open orders, and the open orders meet that note from March. That meeting is the whole game, and in most companies it happens in exactly one place: somebody’s head, usually at nine in the evening, usually the same somebody.

This is why “we have a tool for that” is never quite an answer. You do have a tool for that. You have twelve. The thing you don’t have is the thing between them, and the industry’s honest name for the thing between them is a person doing unpaid systems integration in their head.

Twelve accurate apps and one exhausted person doing the joins is not a software stack. It’s a single point of failure with a subscription bill.

§What the layer underneath does differently

Now run the same Tuesday with one system underneath the modules instead of walls between them. The email is parsed the minute it arrives: a finding, 01:07. Two minutes later it has met the production schedule and the open orders and become a signal: three orders exposed, Bruma most of all, and Bruma is date-sensitive per its own file. By 01:12 there is a proposal: re-sequence Line 2 to laminate work, notify the three customers tonight, Bruma first. Drafted, staged, unsent. At 09:02 a human reads all of this in ninety seconds and says yes once.

Same facts. Same tools’ worth of information. The difference is that the fragments met each other at one in the morning instead of meeting in the ops channel at 08:12 as a question with shrug emojis. SENA’s claim is not that it knows things your systems don’t; it’s that it reads what all of them know at the same time, and the meaning of a business lives in the overlaps.

The Tuesday in this story cost nothing, in the end: a one-day slip on a delivery the customer had been told about before breakfast. That’s the anticlimax the whole design aims at. The expensive version of this story is the one where the fragments never meet: Bruma finds out on Friday, from the driver. Nobody chose that outcome. Twelve apps chose it together, each one correctly.