The system the company actually uses vs the system the company buys and forgets

Every larger company has at least one piece of software where nobody knows where the login is, or who's supposed to be using it. It was bought for a reason, paid for, installed, and after two weeks active usage disappeared. The spreadsheet it was supposed to replace is still doing the job.

This doesn't happen because the software was bad. It happens because it was bought the wrong way.

What separates a system that gets used

Systems that get used share common traits, regardless of who built them or what they cost:

• They speak the company's language. If the company calls a document "dispatch note", the system calls it that. Not "outbound shipment". Dispatch note.

• They follow the real flow, not the ideal one. The ideal flow says the supervisor approves the document first, then forwards it to bookkeeping. The real flow says when the supervisor is out of the office, the document goes straight to bookkeeping with a note. A system that gets used must support both.

• They reduce the friction the team feels every day. Not the friction management sees from the side. If the team enters the same information into two apps, the system must eliminate that. If management wants reports the team already had in a spreadsheet, that isn't the bottleneck the system should solve.

• They're tested with real data before launch. Not with "test123" data. With a real dispatch note for a real customer, through a real approval route. An edge case that isn't discovered in a test with real data gets discovered in the first week in production — the worst possible place.

How to recognize a system that nobody uses

The clearest signal: the company has an alternative way of working they use in parallel with the system. "Yes, we use that software too, but for most things it's faster through the spreadsheet." That means the system didn't get to the center of the work — it became an extra tool.

Second signal: nobody on the team is asking for new features. A system that gets used creates pressure for expansion. "Can we add this report? Can this step be sped up?" If you don't hear that pressure, the crew has already moved on to using the spreadsheet in parallel and the system no longer matters to them.

What we've seen in practice

The Rudex system we run is in its fifth major version. Each version wasn't delivered because the previous one failed — it was delivered because users asked for more. The warehouse manager asked for a better inventory view. Bookkeeping asked for automated exports for various filings. The shift supervisor asked for a new report that would make shift planning easier.

Those requests are the signal that the system has gotten to the center of the work. Users don't ask for new things because they "have to" — they ask because the system they use every day can make one more piece of their work easier.

We do the same for other clients. Sushi XO, which we started with at one location, now runs at five, and every new location requires some small tweak in the system that makes that location's operations easier. Indigo Luxor is in the third version of its app, and with every new album come new ideas — quizzes, prizes, Discord integrations.

What this means in practice

If you're choosing a system for your company, the most important question isn't "how much does it cost and when will it be done". The most important is "who will use it every day, and how involved are they in defining it".

A system that management decides on and the team uses is shelfware in the making. A system the team defines and management approves is a system that will be used for years, with cycles of new versions because the team itself is pulling for what's next.

The difference is in who was at the table when it was being decided what the system should do.