1,500 employees off spreadsheets

The pre-platform reality at Hino was structurally similar to most large Indonesian manufacturers. The visible work happened on the floor — assembly, quality control, logistics. The invisible work happened in Excel: dozens of spreadsheets per department, copy-pasted between teams, emailed as attachments, manually reconciled on Friday afternoons.

Concrete examples I can share:

• A daily production-tracking spreadsheet that three different teams maintained their own copy of. Reconciliation happened weekly. Discrepancies between the copies were normal.
• A maintenance-request workflow that ran on email. A floor supervisor would email a request; somewhere it would land on a maintenance-team inbox; sometimes it got actioned, sometimes it didn't. There was no audit trail.
• A shift-handover document filled out in Word, printed, signed, scanned, emailed, archived. Six steps to capture information that had been in the supervisor's head fifteen minutes earlier.

The pattern: every manual workflow had at least one step that depended on someone remembering to do it. Memory is a poor coordination layer for 1,500 people.

The constraint that drove every technical decision: this had to be supportable by a small internal team for years after I left the contract. That ruled out anything exotic. Microsoft stack, DevExtreme UI, SQL Server data, ASP.NET MVC request lifecycle. None of it is fashionable. All of it is what the support team could already maintain.

The working method that survived all seven months: every workflow got mapped to a clean relational schema in SQL Server before any UI work started.

Why this is uncomfortable: enterprise stakeholders almost universally want to see a UI first. They can't evaluate a schema. They can evaluate a screenshot. The pressure to skip directly to screens is constant.

What I did instead: for every workflow, I'd sit with the operations team, talk through the actual procedure as they'd been running it on paper or in Excel, and write the data model on a whiteboard. The conversation moved between what does this entity represent, what fields does it have, how does it relate to that other entity — and consistently surfaced the unstated parts of the workflow that everyone knew but nobody had ever written down.

One concrete workflow: maintenance requests. The naïve schema is MaintenanceRequest with fields for description, requester, status. The actual schema after the whiteboard sessions had: request entity, asset entity (the thing being maintained), location entity, technician assignment with role-aware permissions, escalation rules tied to severity, audit log on every state transition, and an SLA tracker tied to the request's age. Twenty-something fields across five tables.

The naïve schema would have shipped in a week. It would have failed within a month because the operations team would have hit case after case the model didn't cover. The full schema took three weeks to model and two more to build. It's been in production for six months without a structural revision.

The rollout question is usually how do you get 1,500 people to use a new system? The answer at Hino was structurally different from the answer in startup land:

Don't ask people to adopt new behavior. Replace the steps in their existing behavior.

The maintenance-request workflow rolled out by replacing the old email-based step with a form. The supervisor doesn't learn a new tool — they fill in a form that takes the same five minutes the email took. The form happens to also: create the request entity, notify the right technician based on the role-aware permissions, start the SLA timer, log the audit entry. None of that is visible to the supervisor. They sent an email. The platform did the rest.

The user-facing surface area for each workflow was tiny by design. The system did the work; users did the same thing they'd been doing.

By week six the ops lead said that line in a meeting and I knew the rollout was working. Adoption metrics had been positive but adoption metrics for an internal tool are easy to manipulate. The unguarded comment from someone who didn't know I was listening was the real signal.

Reach by month three: ~1,500 active monthly users. Operational efficiency lift across the digitized workflows: ~25% by the company's own measurement, which I'd characterize as probably true within a 5-point margin given how soft self-reported productivity measures are.

Three places I'd run the project differently if I started over.

Spend the first week on production-data shape, not requirements. I spent week one in requirements interviews. The most useful single week, in hindsight, would have been spent exporting and analyzing the existing spreadsheets — what data shapes had actually accumulated, what the edge cases were, where the data was inconsistent. By week three I had to backtrack to do this. Earlier would have saved weeks.

Build the support documentation in parallel, not after. The internal team that would maintain the platform after I left needed onboarding materials. I underestimated this and built docs in the final two weeks, which was both stressful and lower quality than if I'd written them as I built each module.

Test on a 2017-vintage Windows laptop on the actual plant network. I tested on my MacBook on home wifi for too long. The production environment was older Windows machines on a plant network that occasionally had real packet loss. Two of the three production-bug categories I shipped would have been caught in week four if I'd tested in the actual deployment environment from day one.

The honest accounting of where the framework slowed me down.

Custom editors and the ASP.NET model binder. A combo-box that worked in dev but submitted the wrong value on postback. The model binder didn't recognize the editor's internal state. Three days lost before I understood the convention I needed to follow.

Server-side data source quirks. The default dataSource was loading 60,000 rows into the client on a single grid. I'd misconfigured the server-side operations. Switching to true server-side paging took an afternoon to diagnose and an afternoon to fix; should have taken thirty minutes. The DevExpress docs assume you already know the convention.

Multi-language support. Indonesian and English. DevExtreme has built-in localization but the integration with our ASP.NET MVC routing was non-obvious. Half a day to get the locale-detection logic working, another half-day to retrofit all existing pages.

These cost a cumulative week-plus of the contract. Not catastrophic. Worth flagging for anyone walking into a similar build — the framework is good, the docs are reference-grade, the production wisdom is sparse.

Seven months. Roughly 1,500 active users at peak. A measured 25% operational lift in the workflows that got digitized. Zero spreadsheets retired outside the scoped workflows — the work is still ongoing — but for the workflows I touched, the spreadsheets are gone, the audit trail is clean, and the support team can maintain it without me.

The single most-defensible decision: schema-first, schema-paper-reviewed, schema-tested before any UI work. The single most-uncomfortable lesson: even with that discipline, the first version of every workflow's UI was worse than the spreadsheet it replaced for the first two weeks, until users got used to it. That two-week gap is invisible from outside the project. It's where most rollouts fail.

The platform is still running. I'm proud of it in a quiet way that internal tools earn — nobody outside the company will ever know it exists, but 1,500 people open it every morning. That's the kind of impact most public-facing work doesn't match.