BSN: Onboarding a Regulated Pharma Distributor onto a Platform That Didn't Exist Yet

Overview

PT Bahtera Sentra Niagatama (BSN) is a pharmaceutical raw-material distributor (PBF) operating under Indonesia's CDOB (Cara Distribusi Obat yang Baik) regulatory framework. They had been running on the same legacy system since 2015. This case study covers the full onboarding journey onto Simplites: from initial interview in January 2026 through data migration, SOP implementation, staff training, and ongoing refinement as of July 2026.

BSN was also an early design partner, which meant direct access to real operations and zero tolerance for a system that only kind of worked.

The Challenge

BSN is not a typical SME customer. The complexity came from four directions at once:

Regulatory requirements. As a CDOB-certified distributor, BSN operates under strict pharmaceutical distribution guidelines. Every purchasing, receiving, sales, shipping, quality, and disposal process has a formal SOP. These aren't internal policies — they're legal documents. The system had to reflect them exactly.

Legacy data going back to 2015. Ten-plus years of inventory, batch records, supplier history, and transaction data lived in a system the team knew intimately. Any migration that produced numbers they didn't recognize would immediately destroy trust in the new system.

27 formal SOPs. Each SOP covers a distinct process: purchasing (local and import), sales, CDOB receiving, CDOB shipping, quality complaints, deviations, CAPA, mock recall, returns, disposal, temperature monitoring, warehouse maintenance, and more. Before staff could use Simplites for a single real order, all 27 had to be live as executable workflows.

Staff who had never used a web-based business system. The team was experienced at their jobs. They were not experienced at learning new software mid-operation.

What the Onboarding Actually Involved

Phase 1 — Discovery (January–February 2026)

The first two months were interviews and SOP analysis. Not software at all.

I sat with BSN staff across roles — purchasing, sales, APJ (responsible pharmacist), warehouse, finance, admin — and walked through how they actually worked. Not how the SOP said they should work: how they actually worked. Those two things are never identical, and the gap between them is where implementation problems live.

I read all 27 SOP documents. Each one became a cluster of workflow stages, task templates, forms, and document types that would need to exist in Simplites before go-live.

Key finding from this phase: the SOPs had branching logic that no simple order-status system could handle. A purchasing workflow, for example, branches at "is this a local or import procurement?" — and the import path has five sub-stages covering customs clearance, import licensing (LARTAS/SKI/LS), PIB documentation, and customs broker coordination, before it rejoins the local path at warehouse receiving. A system with five order statuses (pending, in progress, done) cannot represent this.

That finding directly shaped the Simplites workflow engine design: stages with branching (branch_field_key, yes_stage_id/no_stage_id), role-gated task completion, per-stage form and document attachments, and SOP prose stored as instructions on each task template.

Phase 2 — Data Migration (March–May 2026)

The legacy system had been in use since 2015. The migration involved:

• Product catalog — all raw materials with SKUs, units, purchase/sell unit conversion
• Inventory — batch-level stock with batch numbers, quantities, cost per unit, expiry dates, and supplier reference
• Contacts — customers and suppliers, with pharmaceutical-specific fields (NPWP, CDOB/CPOB license numbers, customer qualification status)
• Transaction history — past orders with reference numbers mapped to BSN's own document numbering conventions (SJ, PJ, DO, PD prefixes)

The hardest part was not the data transformation. It was reconciliation. After each import run, I'd sit with my dad and go through samples — does this batch number match what you remember? Does this quantity match the physical stock count? Does this supplier show the right total spend?

One mismatch in a batch record doesn't sound significant. But for a regulated business where every batch has to be traceable for quality and recall purposes, a wrong batch quantity is a compliance issue, not just a data error. We ran multiple reconciliation cycles before declaring the inventory data clean enough to go live.

The transaction history import also required custom scripts because BSN's legacy document numbers (e.g. SJ/2025/001234) didn't map directly to Simplites' order numbering format — a per-tenant prefix + padding system. The import scripts matched orders to contacts by customer name, amount, and date rather than by ID, because the legacy system's IDs meant nothing in the new one.

Phase 3 — SOP Implementation (April–June 2026)

With the data in place, I built out all 27 SOPs as executable Simplites workflows. They were grouped into five clusters, applied to BSN's production database as idempotent seed SQL files:

• Cluster 1 — Purchasing (local and import, with customs/LARTAS branching, CoA verification, QC accept/reject/quarantine branching)
• Cluster 2 — Sales (customer qualification gate, APJ order-reasonableness assessment, export branching, CDOB shipping with QC check)
• Cluster 3 — Quality Events (customer complaints, deviations, CAPA, mock recall — four linked internal workflows)
• Cluster 4 — Returns & Disposal (return reason branching, quarantine, re-exportable vs destroy assessment)
• Cluster 5 — Standalone Internal (temperature and humidity monitoring, warehouse maintenance, pest control, calibration, staff training records, reference SOP library)

Each SOP's full prose text was stored as instructions on its task templates, so staff could read the SOP guidance directly from the task without switching to a paper document.

The SOP reference library — 27 readable HTML documents generated from the database — was accessible under Documents → Generated, giving the APJ a single place to view any SOP without searching through binders.

One significant technical challenge: the generic Simplites workflow engine didn't initially have pharmaceutical CDOB receiving or shipping modes. Building those out for BSN's requirements (shelf-life checks, batch FIFO drawdown, QC sign-off on dispatch) produced features that are now available to all regulated tenants via the module_pharma_cdob entitlement toggle.

Phase 4 — Training & Go-Live (June–July 2026)

Training for BSN was structured around roles, not features. Each staff member learned the flows relevant to their job, not the full system. The APJ learned the CoA verification and QC branching steps. Warehouse staff learned receiving and stock opname. Sales staff learned order intake, customer qualification, and the APJ sign-off flow.

The reframe that made training land: "Simplites doesn't change your SOP. It runs your SOP." Every checklist item in the app maps directly to a step the staff already knew they had to do. The system makes compliance easier, not different.

Ongoing (July 2026)

The migration from a system used since 2015 doesn't end with go-live. BSN is live and processing real orders in Simplites. Active refinements are still in progress: batch history backfill from the legacy system's lot records, adjustments to form fields based on real usage, and incremental staff feedback as they use the system on actual transactions.

Design Decisions Shaped by BSN

Branching workflow stages. The purchasing SOP alone has three branch points (import vs local, accept vs reject vs quarantine at QC, re-export vs disposal on reject). A linear stage system couldn't model this. Implementing it for BSN produced a generic branching engine (is_branching, branch_field_key, yes_stage_id/no_stage_id) that any tenant can use.

SOP instructions on task templates. Each task in a BSN workflow carries the SOP prose text as its instructions field. Staff don't need to open a separate binder to know what a task requires. This became a standard field in the Simplites task template schema.

CDOB receiving and shipping modes. Standard receiving (scan, enter quantity, confirm) is insufficient for a regulated distributor. CDOB receiving requires shelf-life verification (≥50% remaining), CoA check against compendium, and QC branch. CDOB shipping requires FIFO/FEFO drawdown and APJ sign-off on the delivery order. Both are now separate modes gated by the module_pharma_cdob entitlement.

Idempotent seed SQL for tenant configuration. With 27 SOPs split into five rollout clusters, I needed a way to apply workflow data to a production database that was safe to re-run. Every BSN seed file uses INSERT OR IGNORE with reserved ID ranges per cluster, so a failed deploy can be retried without creating duplicates. This pattern is now the standard for all tenant configuration seeding in Simplites.

Metrics

• 27 pharmaceutical SOPs implemented as executable, role-gated workflows with branching logic
• 5 rollout clusters, each deployed and verified against BSN's production database
• 10+ years of transaction history migrated and reconciled
• January 2026 to July 2026: 7 months from first interview to active live use
• Multiple platform features built out of BSN requirements: CDOB receiving/shipping, branching stages, SOP reference library, idempotent seed pattern

Lessons Learned

Migration trust is built row by row. The technical work of moving data is the easy part. The hard part is sitting with the people who know the data and verifying it matches their memory. Skip that and you get a migration that's technically correct and operationally rejected.

SOPs are the feature spec. For a regulated business, the system requirements aren't "I want to track orders." They're 27 legal documents with specific fields, approval sequences, and branch conditions. Reading the SOPs first meant I never built something BSN couldn't use. Building first and fitting SOPs later would have meant rebuilding everything.

A complex tenant is a platform stress test. Every edge case BSN surfaced — branching workflows, CDOB compliance modes, multi-currency import tracking, batch-level traceability — became a platform-level feature. The most demanding tenant made Simplites significantly more capable for every tenant that followed.

Change management is slower than software. The software was ready before the staff were. That's normal. The rollout timeline wasn't constrained by code; it was constrained by how fast a team with 10 years of muscle memory in one system could build trust in a new one.

CTA

BSN is running on Simplites. If you're working with a regulated or operationally complex business and want to talk through how this kind of implementation works, reach out via email or WhatsApp.