Client pilot · Operations platform
A centralized operations platform that turns shift handovers, testing, and production updates into one structured, auditable system.
Manufacturing a metro train runs on continuous, multi-shift work — and for a long time the most important information moved on paper and across scattered chat threads. When one shift ended, the next began with a verbal recap and a hunt through messages: what had been tested, what failed, what was still pending. Any detail that didn't get written down was simply lost.
This platform replaces that with a single operations system. Technicians, supervisors, and managers record shift handovers, track testing progress train by train, log pending activities, and post production updates in a consistent, structured format — so nothing falls through the gap between shifts, and management can read the state of the floor without asking anyone for a report.
The opportunity surfaced from inside a metro manufacturing operation, where someone close to the floor saw that critical work — shift handovers, testing updates, pending tasks, and team communication — still moved through manual notes and fragmented channels. Each gap carried risk: information lost between shifts, status that was hard to reconcile, and managers without a clear operational picture.
The brief was direct: turn those workflows into a single digital system that the people doing the work would actually use.
Over a series of discussions, I gathered operational requirements directly from the people involved in manufacturing and testing. The early focus was on how shift handovers pass between teams, how testing activities are tracked, how pending tasks get communicated, how train-specific work is monitored, and how managers receive updates.
As the picture sharpened, additional workflows and reporting needs emerged — so discovery continued in parallel with the build rather than ending before it.
Rather than building a generic dashboard, I designed the system around the actual shape of day-to-day operations. The core model followed the real hierarchy of the work — trains, test chapters and sub-chapters, statuses, and pending activities — so the software mirrored how teams already thought about the job instead of imposing a new mental model.
The handover flow became the spine of the system, with every entry, test, and update tied to the unit of work it belonged to.
I built the platform as a workflow-driven web application: structured shift-handover capture, hierarchical train → test chapter → sub-chapter selection, live test-status tracking, automatic pending-activity carry-forward, and aggregated reporting for supervisors and management.
Role-based access scoped each view to the user, and a mobile-friendly interface let technicians record updates from the floor rather than only from a desk.
I worked prototype-first, putting a working build in front of users early and iterating on real operational scenarios instead of assumptions. Successive rounds refined the handover workflow, the test chapter and sub-chapter tracking, train selection, pending-activity management, and the status-reporting structures — each change driven by feedback from the people who would actually use it.
The prototype is currently under stakeholder review, with feedback being collected to guide its next direction.
The project was an exercise in translating real-world industrial operations into a structured digital workflow — and it sharpened how I convert business processes into software, gather requirements from non-technical stakeholders, design enterprise operational systems, and build around real-world constraints instead of assumptions.
Outgoing shifts record what was done and what's outstanding; the incoming shift starts from a complete, structured handover instead of a verbal recap.
Work is organized per train, so every entry, test, and update is tied to the unit it belongs to and stays easy to trace.
A hierarchical test structure lets teams drill from chapter to sub-chapter, capturing exactly which procedure an entry refers to.
Each test carries a live status, making it clear at a glance what has passed, what's pending, and what needs attention.
Unfinished work is carried forward automatically, so open items follow the train across shifts instead of being forgotten.
Daily production progress is logged in a consistent format, building a reliable timeline of how each unit advanced.
Coordination happens inside the system and stays attached to the relevant work, replacing fragmented messaging threads.
Aggregated views summarize testing status, pending activities, and production progress for supervisors and management.
A responsive layout lets technicians capture updates from the shop floor on a phone, not only from a desk.
Technicians, supervisors, and managers each see and act on what is relevant to their role.
Challenge
Replacing an entrenched mix of paper logs and chat threads — without slowing the floor down or asking people to learn a foreign process.
Solution
I modeled the system on the team's real handover flow rather than imposing a new one, and kept data entry fast enough to complete mid-shift. Adoption didn't cost time on the floor; it gave time back.
Challenge
Capturing testing work that spans many trains and a deep procedure hierarchy, without rigid forms that break the moment reality differs from the template.
Solution
A train → test chapter → sub-chapter model with per-item status keeps every entry precise and consistent, while staying flexible across units and stages of work.
Challenge
Information was being lost at the single hardest point to cover — the boundary between two shifts.
Solution
Pending activities carry forward into the next shift's handover automatically, so open work is never re-typed or dropped, and every change leaves an auditable trail.
Challenge
Management needed visibility into daily operations without adding yet another manual reporting burden on the floor.
Solution
Dashboards aggregate testing status, pending work, and production updates straight from the records the floor already maintains — visibility becomes a by-product of normal work, not a separate task.
Challenge
The same data had to serve technicians on phones at the line and managers reviewing at a desk.
Solution
A mobile-first responsive interface built on Material UI, with role-based access scoping each view, so one system fits both contexts without compromise.