PT SMI's Six Systems Were Never Designed to Connect
PT Sarana Multi Infrastruktur (Persero), known as PT SMI, is a state-owned enabler of Indonesia's infrastructure growth, acting as facilitator and catalyst between project owners and investors. Internally, the company ran on six disconnected systems: e-Procurement, SPPD, FPPD, Surat Keluar, HCIS, and GASS, each covering a different operational function and each living behind its own link and login.
Employees meant to move infrastructure deals forward were instead losing time just locating the right tool for a given task. With the assistance of Suitmedia, SMI aimed to build a Master Apps portal, a single entry point consolidating internal tools, approvals, submissions, and day-to-day operational tasks into one system employees could actually find.
Why a Links Page Wouldn't Have Fixed the Real Problem
1. A landing page listing links to all six systems.
Put e-Procurement, SPPD, FPPD, Surat Keluar, HCIS, and GASS behind one bookmarks page, and the search problem looks solved. However, it does not solve the problem . A link directory fixes discovery, not workflow. Employees would still log into six separate systems, track approvals in whichever tool happened to hold them, and have no shared view of their own pending tasks across any of it.
2. SMI's internal systems were built one at a time, for one function at a time, with no shared access layer connecting any of them.
E-procurement handles procurement. SPPD and FPPD handle travel authorization. HCIS handles HR. Surat Keluar handles outgoing correspondence. Each was a reasonable answer to its own problem the day it was built. None of them was built assuming other systems would eventually need to sit next to it, so every new system added one more disconnected island rather than extending a shared foundation.
3. Depth of integration was the real decision.
Building native workflow logic into Master Apps for approvals, submissions, and correspondence costs more time and development effort than simply linking out to existing tools. Suitmedia and SMI had to decide, system by system, which processes needed to actually run inside Master Apps and which could stay external and just be launched from it.
Building the Access Layer SMI's Systems Never Had
1. The strategy centered on a single question for each existing system: integrate the workflow, or just link to it.
Approval, Submission, To Do List, and Surat Keluar became native modules inside Master Apps, with full CRUD functionality, search and filtering, and status syncing built directly in. Other systems, including e-Procurement, SPPD, FPPD, HCIS, and GASS, were made reachable through a centralized internal application list rather than rebuilt from scratch. That split let SMI get the benefit of deep integration where approvals and submissions actually needed to move between systems, without taking on the cost of rebuilding every existing tool.
2. One module went further than operational necessity required.
Surat Keluar wasn't just linked or lightly wrapped. It was rebuilt inside Master Apps with full CRUD, role-based settings, and master data tied to SMI's divisions and directorates. Outgoing correspondence follows organizational hierarchy and carries compliance weight, so this module needed governance logic a simple link-out could never provide.
3. Adoption got its own feature set, separate from pure operational utility.
A Calendar module synced with Outlook, and the platform included an Instagram feed and OneDrive file sharing alongside the core workflow tools. None of these are core business processes. They exist to give employees a reason to open Master Apps even on days they don't have an approval pending, which is the trade-off: broader product surface area in exchange for habitual use of a tool that only pays off if people actually open it.
4. The build moved through a formal, gated sequence rather than shipping as one release.
Wireframes and full designs each required the client's written sign-off before the next stage began. Front-end development was locked before back-end integration started, so the interface was already fixed before the harder work of wiring six external systems together began underneath it, reducing the risk of late design changes forcing rework on integration already built.
What Internal Platform Consolidation Actually Requires
1. Fragmentation is an accumulation problem.
Six systems built independently over time don't become one coherent experience just because they're linked from the same page. Someone has to decide, deliberately, which workflows get rebuilt inside the new layer and which stay external.
2. Not every system deserves the same depth of integration.
Treating all six existing tools identically would have meant either over-building every integration or under-serving the ones that actually needed shared workflow logic, like approvals and correspondence. Suitmedia's system-by-system decision, native build versus simple link, is the actual design discipline here, not a detail.
Strategic Insights for the C-Suite
1. Internal operational friction is a credibility risk for any organization whose business is helping others move faster.
SMI's job is to accelerate infrastructure development for project owners and investors outside the organization. When employees inside it burn time just locating the right system, that mandate erodes quietly, well before the slowdown ever reaches an external metric.
2. Platform consolidation projects should be evaluated on their integration decisions, not just their feature list.
The harder and more valuable work in a project like this is deciding which existing systems get rebuilt into shared workflows and which stay external, not assembling a list of modules.
Before approving a similar consolidation project, ask your team to name which existing systems will be deeply integrated and why, and require a stated outcome metric for the result, not just a list of delivery milestones. A project with no measurable target set at the start will struggle to prove its value after launch.
