Inside the STEMLink and Inivos Externship

What Problem Were the Students Asked to Solve?

Vehicles break down mid route with no warning, stalling operations and stranding drivers far from help. Services get missed and job cards get lost, so nobody can say afterwards what was skipped. Nobody can answer what was checked, when, or by whom. And because nobody can answer, the blame game starts: the workshop blames the drivers, the drivers blame the workshop, and management sees neither side clearly enough to settle it.

None of that is exotic. It is the ordinary result of information living in people's heads and on loose paper instead of in a system.

Who Took on the Challenge?

The project was taken on by a team of STEMLink learners placed with Inivos.

Inivos is a technology and business consulting company founded in 2018, based in Colombo, Sri Lanka, with offices in Singapore, the United Kingdom, and the United States. It began as an ERP consultancy and grew from there. Today it works across two connected areas: enterprise resource planning and enterprise asset management consulting, where it is an authorised partner of IFS and works with Acumatica for smaller businesses, and a technology arm that builds software and provides engineering teams to clients in the US, UK, and Australia.

Its people include functional consultants, business analysts, software engineers, QA engineers, DevOps engineers, and database administrators, serving industries including automotive, manufacturing, supply chain, retail, and asset management.

That background is what makes the brief credible. Enterprise asset management is precisely the discipline of tracking physical assets, their condition, their servicing, and their costs across a large organisation. Inivos also already builds transport software. A vehicle maintenance system sits exactly where those two lines cross, which means the team was not solving a hypothetical. They were working on a real gap in a domain the company knows well.

For a small team, the practical consequence is that nobody stays in one lane. Everyone ends up touching the workflow logic, everyone has to understand what a technician actually does on a job, and someone has to own quality whether or not that is their title. The boundaries between roles turn out to be far more porous than job titles suggest.

What Did the Team Need to Build?

The team started by working out what the system had to do, and more usefully, who it had to serve.

Five different people touch a single repair, and each of them needs something different from the same event.

The driver needs to report a problem quickly, from wherever he is, and to know the report went somewhere. The fleet manager needs to know which vehicles are available, which are in the workshop, and which are approaching a service. The maintenance engineer needs to assign work and release it. The technician needs to know exactly what to do rather than receiving a vague instruction to have a look at the brakes. The supervisor needs the cost of parts and labour captured before the job closes.

Designing for one of those and bolting on the others would have produced something usable by nobody. So the requirement was not a screen. It was a chain of custody: an unbroken record following the vehicle from the moment a fault appears to the moment it is cleared to drive.

Two other things fell out of the analysis.

A reported fault is the easy case. The team recognised early that the harder situation is the fault nobody reports. That reframing shaped the entire second half of the product.

The record is the deliverable. Speed is valuable, but the reason paper fails is not that paper is slow. It is that paper disappears. Whatever got built had to make the history of every vehicle permanent and queryable, because that is what ends the blame game.

How Did the Students Design the Solution?

The design replaces five disconnected steps with one tracked sequence, running from fault report to vehicle back on the road. Seven stages, each visible to everyone who needs it.

Someone reports the fault. He submits it from an app on his phone in about thirty seconds, from the roadside, without calling anyone.

A work order is created automatically. The system generates it the instant the report lands. No manual entry, no transcription, no second person needed to turn a phone call into a document.

The fleet manager confirms arrival. When the vehicle reaches the workshop, that arrival is acknowledged, so the timeline is recorded rather than assumed.

The maintenance engineer releases the job. They assign the required tasks and release the work to a technician.

The technician works a checklist. The job appears as a guided step by step sequence, so steps cannot quietly go unperformed.

The supervisor verifies cost. Parts and labour are confirmed before the job can close, capturing the true cost while details are fresh.

The vehicle is marked available. It returns to service with a complete record of what happened, who did it, what it cost, and when.

Then there is the second half of the design, aimed at the fault nobody reports.

Picture three drivers, Sam, Rohan, and John, raising the same concerns: breakdowns mid route, parts wearing out early, unusual noises. The workshop says services are on schedule and everything is fine. The drivers say the vehicles do not feel fine. Both sides are confident. Only one can be right, and on paper there is no way to find out which.

The answer is preventive maintenance that runs itself, in four steps. Every vehicle is enrolled in a maintenance program defining what it needs and at what intervals. The odometer is read after every trip, so the trigger is real distance travelled rather than a calendar guess. Warnings fire at threshold values set in advance, before the limit is reached. And a work order is generated automatically when the interval arrives.

Nobody has to remember. That is the whole point.

How Do You Turn an Idea Into a Working Product?

Turning that into working software meant building three things that had to fit together.

A mobile reporting path simple enough that a driver on a hard shoulder can complete it in thirty seconds without training, because a reporting tool that takes five minutes is a reporting tool nobody uses.

A workflow engine that moves a job through its stages with the right person able to act at each one. A technician cannot approve costs. A supervisor cannot skip the checklist. The job cannot close with the cost blank. These rules are enforced by the system rather than by convention, which is the difference between a process and a suggestion.

A preventive maintenance scheduler that watches odometer readings against each vehicle's programme, raises warnings at the configured thresholds, and generates work orders on its own.

Around those sit the ordinary but necessary parts: vehicle records, maintenance programme definitions, checklist templates, parts and labour capture, and the availability status that tells a fleet manager at a glance what he can dispatch this morning.

What Changed When the Problem Comes From Industry?

Several problems in this system are harder than they first appear.

A driver reporting a fault is almost never in a good place to do it. He is on a shoulder, in a yard, or under a bridge, and connectivity is whatever it happens to be. A form that fails on submission and loses what was typed is worse than no app at all, because the driver now distrusts the tool and reverts to phoning. Reporting has to be forgiving of bad conditions.

Odometer data has to be trustworthy, and it comes from humans. The entire preventive maintenance mechanism rests on knowing how far each vehicle has travelled. If readings are entered late, skipped, or mistyped, the system either misses a service or raises one that is not due. Both errors damage trust, and the second kind is worse, because a system that cries wolf gets ignored precisely when it is right.

Thresholds have to be set at the right distance ahead. A warning that arrives exactly at the service interval is useless, because there is no time to plan the work. A warning that arrives far too early gets dismissed and forgotten. Getting that lead time right is a judgement call about how the workshop actually schedules, not a technical setting.

Automatic work order generation can flood the workshop. A scheduler that raises jobs the moment each vehicle crosses its threshold does not know that eleven vehicles are about to cross theirs in the same week. The system has to raise work reliably without creating a queue nobody can service.

The checklist has to be strict enough to matter and loose enough to use. Force too much and technicians will tick boxes to get through it, which produces records that look complete and mean nothing. Force too little and the checklist stops guaranteeing anything.

Cost capture is a gate, and gates get resented. Requiring parts and labour before closure is what makes the cost data real. It is also friction placed on a busy person at the end of a job. Making that step fast enough not to be worked around is a design problem more than a coding one.

What Was It Like to Solve a Real Industry Problem?

The difference between this and a classroom project is that the requirements did not arrive fully formed.

Inivos posed a business problem rather than a specification. The team had to turn one into the other, which meant asking questions, proposing an approach, and having that approach questioned back by consultants who have implemented asset management systems for real organisations and know where such projects usually fail.

It also meant designing for people who were not in the room. The team had to reason about what a technician does with oily hands, how a supervisor behaves at the end of a long shift, and what a driver will and will not bother doing on a roadside. None of those people were available to explain themselves, so the design had to anticipate them.

And it meant working inside a domain with established conventions. Preventive maintenance, work orders, and job cards are not concepts the team invented. They are standard practice in asset management, with expected meanings. Learning that vocabulary, and building something a maintenance professional would recognise, was part of the work.

What Did the Students Take Away From the Experience?

The technical skills are real: mobile and web development, workflow and state modelling, scheduling logic, role-based permissions, and data design for records that must remain accurate over years.

The more durable lessons sit underneath those.

That the user in the worst conditions sets the design. The hardest constraint in this system is not the workshop or the office. It is a driver on a hard shoulder with one bar of signal and somewhere else to be. Design for him and everyone else is covered. Design for the office and he stops using it.

That enforcing a process is a product decision, not a technical one. Deciding that a job cannot close without confirmed costs is a choice about how strict to be with people. Software makes it possible, but the judgement about how much friction a real workshop will tolerate is a product judgement.

That the record is the product. The visible feature is faster fault reporting. The thing that changes the business is that after a year there is a complete, queryable history of every vehicle. Arguments become answerable, costs become visible, and patterns become obvious.

That automation only helps if people trust it. A preventive maintenance scheduler that fires at the wrong times will be ignored within a month, and an ignored alert is worse than no alert. Reliability, not cleverness, is what makes automation valuable.

And that domain knowledge is not optional. You cannot design a maintenance workflow without understanding how a workshop actually runs. A great deal of the work was learning the domain well enough to build for it.

What Did They Actually Deliver?

VMMS is a working vehicle maintenance management system covering the full journey: fault reported from the roadside, work order created automatically, arrival confirmed, job assigned and released, checklist worked step by step, costs verified, and vehicle returned to service with a complete record behind it.

Alongside that runs the preventive side, watching odometer readings after every trip and raising the service work before a failure happens rather than after.

Compare the two versions of Sam's morning. Before: five steps, one hour, and a paper trail that may or may not survive the week. After: thirty seconds on a phone, a work order in the system before he has put the phone down, and a record that will still be answerable in a year.

And two months on, the version of the story where he is stranded on the highway with a failed engine mount at 20,000 kilometres past a service nobody flagged simply does not happen, because the system flagged it.

The promise is a small one, and it fits on a single line. Every fault logged. Every service triggered. Every vehicle accounted for.

Why Does This Industry Experience Matter?

The most valuable part of an externship is not the line it adds to a CV.

It is working on a problem that has not been neatly pre-shaped by a lecturer. In a classroom the requirements are clear, the scope is fixed, and a known answer waits at the end. In industry none of that holds. The problem is ambiguous, the constraints compete, and the hardest part is often working out what you are actually being asked to build.

This team took an operational problem that costs real businesses real money, learned a domain they did not start with, designed for five different kinds of user who were not in the room, and built something that changes how a fleet runs.

That is a fundamentally different education from following a tutorial to a known destination. And it is exactly the point of industry-focused learning: not simply preparing learners to enter the technology industry, but giving them a chance to experience it before they do.