

How a transformer manufacturer consolidated more than forty internal modules - from travel requests and reimbursements to bank guarantees, tendering, help desk, and legal case files - into a single intranet, with a mobile app for the people who are not at a desk.

A manufacturer of this size runs on a long tail of internal processes. Travel requests. Reimbursements. Vendor registration. Asset tracking. Bank guarantees and letters of credit. Help desk tickets. Job postings. Legal case files. None of them is large enough on its own to justify a system, so each one ends up somewhere different - an email thread, a shared folder, a register, a form on somebody’s desk.
The cost is not in any single process. It is that an employee has to know where each one lives, a manager chases approvals across four different channels, and nobody has a view of the whole. So the brief was not to automate one workflow well. It was to understand how the departments actually interlink, and then put the lot behind one login without the result becoming a menu nobody can navigate.
No single one of these is large enough to justify a system. Together, they are most of the working day.
We built an intranet of more than forty modules, each designed against the department that would use it, all sharing one identity, one set of role permissions, and one place to look. Company news, policies, and announcements sit alongside the transactional modules rather than in a separate publishing tool, because an intranet people only visit to file a claim is not an intranet anyone reads.
A single workflow engine is the spine. Travel requests, reimbursements, and vendor management route through it, and so do the specialised processes: bank guarantee and letter of credit handling, a bidding portal covering vendor registration, tendering, and reverse auctions, enterprise task and project tracking, litigation files, and the help desk. Around those sit the modules that make somewhere worth going - a suggestion scheme, careers and internal job postings, quizzes for training, surveys for feedback. A Xamarin app carries the same features to people away from a desk, and where data already lived in other systems the intranet integrates with them rather than keeping a second copy.
The forty-odd modules fall into two kinds of work.
Outcomes as reported by the client. We have not attached percentages to them, because the ones worth quoting are the ones the client measured themselves.
An employee raising a travel request, opening a help desk ticket, and checking a policy does all three in the same place under the same permissions. Knowing where a process lives stopped being part of the job.
Because the modules share one workflow engine and one identity, a request that crosses departments stays a single record rather than becoming four. Working out those interlinks was the hardest part of the project, and the part that made the rest possible.
Forty modules is where it stands, not where it started. The architecture was built for the client to keep adding, which is why the intranet has grown into day-to-day operations rather than settling as a launch-day artefact.
Built to keep absorbing modules, and integrated with the systems the client already ran.
The small ones - travel, reimbursements, asset registers, internal requests - are rarely worth a system each, which is exactly why they end up scattered. Tell us what yours look like and we will tell you honestly which are worth consolidating and which are fine where they are.