Case study · Lembaga Pembangunan Industri Pembinaan

Eighteen human resource modules, on one employee record.

Eighteen modules

— RM 2.3 million, 2023 to 2026

01 · Client and system

Client
Lembaga Pembangunan Industri Pembinaan
System
Portal Pengurusan Sumber Manusia
Period
2023 – 2026
Current status
In production. Delivered beside other vendors’ teams.

02 · The problem

Eighteen modules, one employee, and a master record we do not own.

The Construction Industry Development Board runs its employee master data in SAP HANA, a system it owns and we do not. Eighteen human resource functions — appointment, leave, claims, performance — each needed the same employee, cost centre, and organisation structure, and none of them could be allowed to hold a second copy of the truth. The portal therefore had to read from SAP HANA continuously, stay usable when that read failed, and do it while other vendors’ teams were changing the same project around us.

03 · What we built

Five things we are accountable for.

  1. 01 Requirements analysis with the agency’s own HR officers, documented so a developer could build from it.
  2. 02 Eighteen modules built, tested, and accepted — module by module, not in one release.
  3. 03 Read integration against the agency’s SAP HANA instance for employee master, cost centre, and organisation structure.
  4. 04 Mobile approval path for leave and claims, with the decision recorded in the portal rather than in the notification.
  5. 05 User acceptance testing run with the client, and Bahasa Malaysia documentation for each module.

04 · Scale

The numbers this engagement is measured on.

RM 2.3m
Contract value

Approximate, rounded

18
Modules

Each separately accepted

3 years
Delivery period

2023 to 2026

2
External interfaces

SAP HANA · Firebase Cloud Messaging

Employees on the system — to supply
Population
Concurrent users — to supply
Load

Two figures are held back until the agency confirms what may be published. An evaluator reads a blank field as honest; a made-up one costs the whole submission.

Architecture explorer

Six layers, in the order a leave application passes through them.

Scroll to move through the stack. Every layer and its detail is on the page whether the highlight runs or not.

Stack

  1. 01 Client
  2. 02 Gateway
  3. 03 Application
  4. 04 Master data sync
  5. 05 Database
  6. 06 Notification
  1. 01

    Client

    The officer or staff member raising a leave application, a claim, or an approval.

    Session is bound to the individual, so an approval is always recorded against a named person and never against a role.

    • Web client
    • Mobile approval
  2. 02

    Gateway

    Authentication and request validation before anything downstream is touched.

    A request for a record outside the user’s own cost centre is refused here, not filtered later in the application.

    • Authentication
    • Request validation
  3. 03

    Application

    The eighteen modules, each holding its own rules but sharing one employee record.

    A module can be changed or accepted without the other seventeen being redeployed — which is what let the agency accept them one at a time.

    • 18 modules
    • Laravel
  4. 04

    Master data sync

    The delta job that reads employee master, cost centre, and organisation structure from SAP HANA.

    The portal never writes to SAP HANA. It is a reader, so a fault here can delay a record but can never corrupt the agency’s system of truth.

    • SAP HANA
    • SQL view and REST
  5. 05

    Database

    The portal’s own record of every application, approval, and claim.

    HR transactions live here; identity lives in SAP HANA. Neither store is asked to be the other, which is why the sync can fail safely.

    • Relational store
    • MySQL
  6. 06

    Notification

    Push notification to the approver when something is waiting on them.

    Approval state lives in the portal. The notification carries no decision, so a lost message cannot approve or reject anything.

    • Firebase Cloud Messaging
    • FCM HTTP v1

Interfaces

Two interfaces, one of them to a system the agency owns.

SAP HANA SQL view and REST Inbound

Payload — Employee master, cost centre, organisation structure.

On failure — The last successful snapshot is served with its timestamp visible to the user. The delta job re-runs on the next cycle without operator action.

Firebase Cloud Messaging FCM HTTP v1 Outbound

Payload — Leave and claim approval request.

On failure — Approval state lives in the portal. The notification carries no decision, so a lost message cannot approve or reject anything.

05 · Result

Three measured outcomes.

Outcome 1 — to supply

Modules accepted on first submission, as a proportion of the eighteen.

Outcome 2 — to supply

Median time from application to approval, before and after the portal.

Outcome 3 — to supply

Master data sync success rate, and the longest stale window in the period.

This block is deliberately empty. It is the block an evaluation committee reads hardest, and it must carry numbers you can stand behind in a clarification meeting.

06 · Stack and standards

  • Laravel
  • ReactJS
  • MySQL
  • SAP HANA
  • RESTful API
  • SQL view
  • Firebase Cloud Messaging
  • 18 modules

Standards and compliance schedules applicable to this engagement are to be listed here — confirm which may be named publicly before this page is published.