BUSINESS REQUIREMENT DOCUMENT (BRD)

eProcureMENT & E-TENDER MANAGEMENT PLATFORM

Document Version: 1.4.23 Document Status: Blueprint terbit — rilis SKT → pemenang + SPK Date: 19 September 2026 Document Type: Business Requirements Document (BRD)

1. Document Control

1.1 Purpose

Dokumen ini mendefinisikan kebutuhan bisnis, ruang lingkup, proses, aktor, modul, aturan, integrasi, pelaporan, dan keamanan platform eProcure.

Aplikasi mencakup pengadaan dari kualifikasi vendor (SKT) hingga tender, evaluasi, award, dan SPK/kontrak — dengan portal internal dan portal vendor, RBAC, serta audit trail. Request kebutuhan ke Head dilakukan di luar platform. Purchase Request in-app, PO, delivery, invoice, pembayaran, dan kinerja vendor adalah gelombang produk berikutnya. Lingkup rilis ada di §1.5.

1.2 Changelog

Daftar Isi

1. Document Control & Product Baseline
2. Executive Summary
3. Product Vision
4. Product Positioning
5. Business Objectives
6. Scope
7. Stakeholders
8. User Roles
9. Organization Model
10. Procurement Lifecycle
11. Module Requirements
12. Business Rules
13. Segregation of Duties
14. Conflict of Interest
15. Risk Management
16. Vendor Performance
17. Integrations
18. API Requirements
19. Non-Functional Requirements
20. Data Model High Level
21. High-Level Relationship
22. Status Management
23. User Experience
24. Search & Filter
25. Approval Engine
26. SLA Management
27. Notification Rules
28. Audit & Compliance Evidence
29. Security Architecture Principles
30. Disaster Recovery
31. Cakupan Sistem
32. MVP Acceptance Criteria
33. Success Criteria
34. Risks
35. Key Governance Principles
36. Recommended Product Architecture
37. Recommended Technology Direction
38. Tahapan di Dalam Sistem
39. Recommended Product Modules
40. Final Business Process
41. Conclusion
42. Phase 1 Functional Requirements
43. Exception & Alternate Flows
44. Sealed Bid & Sensitive Data Requirements
45. State Machines
46. Permission Matrix
47. Non-Functional Targets & Load Assumptions
48. Data Retention, Privacy & Localization
49. Integrasi yang Dikonfigurasi
50. Observability & Operability
51. Compliance Evidence Pack
52. Definition of Done — Phase 1
53. Konfigurasi Organisasi
54. Appendix A — Phase 1 Internal Portal Menu
55. Appendix B — Vendor Portal Menu
56. Appendix C — Operasi Harian
57. Appendix D — Traceability
58. Appendix E — Dokumen Terkait

Catatan: Nomor di atas adalah urutan baca dokumen. Penomoran heading asli dipertahankan di bagian isi untuk menjaga referensi lintas dokumen.

1.3 How to Use This Document

Ini satu-satunya BRD. Jika ada bentrok dengan checklist atau dokumen lain, §1.5 menjelaskan sistem yang dipakai.

UI/UX design bukan bagian paket ini; disiapkan terpisah. Jangan menambah FSD.md / SRS.md — FR bisnis ada di dokumen ini (§11).

BUSINESS
   │
   ▼
doc/BRD.md                              aturan + FR (FSD/SRS bisnis)
   │
   ├── doc/BUMN_DIGITALISASI_CHECKLIST.md   regulatory / policy (backlog evidence)
   └── doc/USER_JOURNEY.md                  business process (bukan BPMN formal)
   │
   ▼
doc/TRD.md                              HLD + security operasi
   ├── doc/API.md
   ├── doc/ENGINEERING.md                   convention development
   └── backend/database/migrations          ERD hidup
   │
   ▼
DEVELOPMENT
   │
   ▼
doc/PHASE1_JOURNEY_CHECKLIST.md         SIT + UAT + GATE
doc/SIT_VENDOR_SKT_SPK.md               skenario: vendor → SKT/TDR → SPK
   │
   ▼
doc/SOW.md                              deploy · produksi · handover

1.4 Product Baseline Decisions (Frozen for Phase 1)

Keputusan berikut dianggap baseline kecuali diganti tertulis oleh stakeholder:

1.5 Lingkup produk yang diterbitkan

Alur per peran: USER_JOURNEY.md. GATE: PHASE1_JOURNEY_CHECKLIST.md.

Jenis tender: Open, Limited, RFQ.

Peta alur

Rilis ini menutup di SPK. HPS tidak ke publik.

flowchart TD
  Home["Home /"] --> Portal["Portal /portal"]
  Home --> Brd["BRD /brd"]
  Home --> VLogin["Login vendor /vendor/login"]
  Home --> SLogin["Login staf /login"]
  VLogin --> Register["Daftar /register"]
  Register --> Company["Perusahaan /vendor/company"]
  Company --> Desk["Review desk /vendors"]
  Desk --> Skt["Terbit SKT"]
  Skt --> VTenders["Tender vendor /vendor/tenders"]
  SLogin --> Open["Buka paket /tenders/new"]
  Open --> Fill["Maker isi TOR"]
  Fill --> Publish["Checker → Ketua → Approver → Publish"]
  Publish --> VTenders
  VTenders --> Aanw["Aanwijzing + hadir"]
  Aanw --> Bid["3 sampul + receipt"]
  Bid --> Opening["Pembukaan + BA"]
  Opening --> Eval["Evaluasi /evaluations"]
  Eval --> Award["Award /awards"]
  Award --> Spk["SPK /contracts"]
  Spk --> VSpk["Vendor lihat SPK /vendor/contracts"]

1.5.1 Rilis ini (SKT → SPK)

Platform yang diterbitkan mencakup sampai penetapan pemenang + terbit SPK.

• identitas, peran, izin (RBAC) — 10 peran standar; roster/desk = assignment, bukan peran baru;
• master organisasi dan katalog kategori kualifikasi (wajib tersedia di portal vendor);
• vendor: daftar → verifikasi email → form lengkapi (draft/revisi, bukan mode baca) → submit → desk rekanan → review + catatan → SKT;
• tender: Head buka paket + wajib tunjuk Maker / Checker / Ketua / Sekretaris / Approver publish; Maker isi TOR/jadwal/dokumen; Checker → Ketua → Approver; Publish hanya Head atau slot Approver publish (bukan Maker / staf di luar roster);
• dokumen, klarifikasi, bid tersegel, opening (hadir + BA milik sesi), evaluasi, award (SoD);
• harga setelah unseal: Ketua, Checker, evaluator komersial, Approver pemenang, Head, Auditor — bukan Maker / evaluator teknis;
• kontrak / SPK;
• portal vendor: tender + lihat SPK jika menang;
• dashboard, laporan, audit trail, notifikasi.

Purchase Request in-app, PO, invoice, pembayaran, dan kinerja vendor bukan menu rilis ini — lihat §1.5.3.

GATE email vendor: simpan profil, unggah dokumen, submit registrasi, dan ikut tender ditolak sampai email terverifikasi.

GATE SKT: ikut lelang / bid ditolak tanpa SKT aktif (atau kadaluarsa / vendor non-aktif).

Pengingat deadline berjalan lewat penjadwal sistem.

1.5.2 Roster Head

Untuk divisi procurement banyak orang / banyak tender, aturan rilis ini:

1. Pemilik pekerjaan mengirim data kebutuhan ke Head / Manager Procurement di luar platform (bukan menu PR).
2. Head / Manager mereview (HPS, metode, syarat), membuka paket di sistem, lalu wajib assign Maker, Checker (banyak), Ketua, Sekretaris, Approver publish (banyak) pada langkah yang sama.
3. Tender review → semua Checker aktif approve dulu → Ketua → Approver publish → Publish (Head atau slot Approver publish). Approver publish ≠ Maker. Approver tidak boleh mendahului Checker.
4. Checker / Approver / Maker / Ketua boleh diganti (mis. pindah divisi). Assignment lama tidak dihapus: waktu berakhir, alasan, pengganti. History wajib.
5. Setelah gerbang Checker lulus: salah satu Approver aktif boleh publish. Checker tidak “salah satu saja” — semua Checker aktif wajib approve.
6. Setelah publish: pemilik pekerjaan (evaluator teknis yang di-assign) cek teknis; penawaran/harga hanya setelah opening resmi. Buka sampul finansial: Ketua panitia (atau Head). User/evaluator teknis tidak melihat angka atau file harga. BA ditandatangani Ketua, Sekretaris, Divisi Pemilik Project, lalu PIC vendor peserta. TTD pemilik project = saksi acara, bukan hak buka harga. Pemenang mendapat SPK.

Katalog peran operasional: USER_JOURNEY.md §1. PDF BA memakai nama Ketua/Sekretaris dari roster. Situs publik (/ /fitur /portal /brd /alur) menjelaskan alur SKT → SPK, tanpa HPS.

1.5.3 Gelombang berikutnya (setelah SPK)

PO, delivery, invoice, pembayaran, dan kinerja vendor merampungkan siklus sampai pembayaran. Request pemilik pekerjaan tetap di luar platform sampai modul PR in-app disepakati. Sanggah, SPPBJ, dan e-sign/TTE tercatat di BUMN_DIGITALISASI_CHECKLIST.md — bukan pengganti gerbang rilis ini.

2. Executive Summary

2.1 Latar Belakang

Proses pengadaan pada banyak organisasi masih menghadapi beberapa permasalahan:

• proses tender dilakukan melalui email dan dokumen terpisah;
• data vendor tidak terpusat;
• dokumen sulit dilacak;
• proses approval bergantung pada komunikasi manual;
• evaluasi vendor tidak terdokumentasi secara konsisten;
• risiko konflik kepentingan dan manipulasi proses;
• sulit melakukan audit terhadap perubahan data;
• monitoring tender dan procurement tidak real-time;
• laporan manajemen membutuhkan proses rekap manual.

Platform eProcurement & E-Tender Management dibangun untuk menyediakan satu sistem terintegrasi yang memungkinkan proses pengadaan dilakukan secara digital, terstruktur, transparan, terdokumentasi, dan dapat diaudit.

2.2 Tujuan Bisnis

Tujuan utama platform:

1. Digitalisasi proses pengadaan.
2. Mempercepat siklus procurement.
3. Meningkatkan transparansi dan akuntabilitas.
4. Memusatkan data vendor.
5. Mengurangi proses manual.
6. Meningkatkan kualitas evaluasi tender.
7. Memastikan seluruh aktivitas memiliki audit trail.
8. Meningkatkan kontrol terhadap dokumen dan informasi sensitif.
9. Menyediakan dashboard dan laporan manajemen.
10. Menjadi fondasi integrasi dengan ERP, finance, legal, dan sistem perusahaan lainnya.

3. Product Vision

Menjadi platform pengadaan digital yang aman, transparan, terukur, dan terintegrasi untuk mengelola proses procurement dari planning hingga contract dan payment.

4. Product Positioning

Produk dikategorikan sebagai:

eProcurement Platform

dengan:

E-Tendering sebagai salah satu modul inti.

Cakupan proses:

flowchart TD
  Plan["Planning"] --> PR["Purchase Request"]
  PR --> Qual["Vendor / SKT"]
  Qual --> Create["Tender"]
  Create --> Pub["Publish"]
  Pub --> Join["Partisipasi"]
  Join --> QA["Klarifikasi"]
  QA --> Bid["Bid"]
  Bid --> Open["Pembukaan"]
  Open --> Tech["Evaluasi teknis"]
  Tech --> Comm["Evaluasi komersial"]
  Comm --> Award["Award"]
  Award --> Spk["Kontrak / SPK"]
  Spk --> Next["PO / Invoice / Pembayaran — gelombang berikutnya"]

5. Business Objectives

5.1 Strategic Objectives

5.2 Business KPIs

Target KPI dapat dikonfigurasi berdasarkan organisasi.

6. Scope

6.1 Full Product Scope (Product Backlog)

Cakupan produk lengkap (bukan janji satu rilis):

Core platform

6.2 Out of Scope (all phases unless separately contracted)

6.3 Cakupan aplikasi

Rilis terbit: §1.5.1. Gelombang berikutnya: §1.5.3.

7. Stakeholders

8. User Roles

Alur kerja per peran (flowchart): USER_JOURNEY.md.

Request User ke Head di luar platform. Peran operasional = slot roster (bukan peran baru): Head/Manager, Maker, Checker (multi), Ketua, Sekretaris, Approver publish (multi), Approver pemenang, evaluator teknis = pemilik pekerjaan. Ganti petugas + history wajib. Lihat USER_JOURNEY.md §1.

8.1 Internal Roles

Super Administrator

Hak:

• seluruh konfigurasi;
• user management;
• role management;
• organization management;
• system configuration;
• audit access.

Procurement Admin

• mengisi paket sebagai Maker (TOR, jadwal, dokumen) setelah Head menunjuk;
• mengelola vendor (jika di-assign desk);
• mengelola dokumen dan jadwal paket yang ditugaskan;
• mengelola clarification;
• tidak membuka paket sendiri; tidak menekan Publish (kecuali di-assign slot Approver — default bukan).

Procurement Manager

• membuka paket dan menunjuk panitia;
• approval publish (setelah gerbang Checker → Ketua → Approver);
• monitoring;
• tender review;
• reporting.

Requester

• membuat procurement request;
• melihat status request;
• memberikan requirement.

Technical Evaluator

• melakukan technical evaluation;
• memberikan score;
• memberikan komentar.

Commercial Evaluator

• melakukan commercial evaluation;
• membandingkan harga;
• memberikan score.

Finance

• budget verification;
• PO;
• invoice;
• payment status.

Tidak ada peran finance terpisah di katalog. Fungsi dijalankan via permission pada Approver / Procurement Admin / Manager. Peran terpisah = change request. PO, invoice, dan pembayaran adalah gelombang berikutnya (§1.5.3). Menu rilis ini: kontrak / SPK.

Legal

• legal review;
• contract review;
• amendment.

Tidak ada peran legal terpisah di katalog. Fungsi kontrak via permission pada Admin / Manager / Approver.

Approver / Management

• approval;
• rejection;
• return for revision.

Auditor

• read-only;
• audit trail;
• report;
• evidence.

Auditor memakai akses vendor read-only. Tidak boleh verify/reject registrasi vendor.

8.2 External Role

Vendor Admin

• registrasi & company profile (kategori, bank, pengalaman);
• upload dokumen legal/compliance;
• unduh SKT setelah terbit;
• user management (vendors.users.manage);
• tender participation, clarification, bid + receipt;
• pasca-award rilis ini: lihat SPK jika menang; PO / invoice / kinerja = gelombang berikutnya.

Vendor User

• melihat profil/SKT perusahaan (tanpa kelola Tim pengguna);
• melihat tender;
• download dokumen;
• clarification;
• bid submission + receipt;
• pasca-award rilis ini: lihat SPK (bila diizinkan permission).

9. Organization Model

Platform harus mendukung struktur:

Organization
 ├── Business Unit
 │    ├── Department
 │    │    ├── User
 │    │    └── Cost Center
 │    └── Location
 └── Procurement Category

9.1 Procurement Category Tree (spesialisasi pekerjaan)

Kategori pengadaan bukan daftar flat tetap di kode. Harus berupa pohon yang dikelola Admin:

Category (root)
 └── Sub-category
      └── Sub-sub-category (opsional, depth fleksibel)

Aturan bisnis:

• Siapa mengisi: Super Admin / Proc Admin (master data), sesuai kebutuhan organisasi.
• Acuan isi: pengkategorian pekerjaan organisasi, dapat diselaraskan dengan regulasi OSS / KBLI (kode eksternal opsional per node). Sistem tidak mengunci satu skema KBLI nasional di kode aplikasi — admin yang menyesuaikan.
• Vendor: memilih satu atau lebih node kualifikasi (disarankan sampai leaf) saat registrasi; dokumen syarat dapat berbeda per cabang.
• Tender: menetapkan kategori paket; undangan / visibility vendor mengikuti kecocokan kualifikasi.
• Implementasi data: parent_id (adjacency list); opsional external_code (KBLI/OSS), path/level untuk query.

Kategori dikelola di master data (pohon parent_id). Vendor memilih kualifikasi; tender mengacu kategori paket.

Opsional:

Holding
 ├── Company A
 ├── Company B
 └── Company C

10. Procurement Lifecycle

10.1 Standard Flow

flowchart TD
  Need["Need"] --> Head["Head buka paket"]
  Head --> Tender["Tender"]
  Tender --> Bid["Bid"]
  Bid --> Eval["Evaluasi"]
  Eval --> Award["Award"]
  Award --> Spk["SPK"]
  Spk --> Next["PO / Fulfillment / Invoice / Pembayaran — gelombang berikutnya"]

Lifecycle produk lengkap. Rilis ini berhenti di Award → SPK. PR in-app dan langkah setelah SPK = gelombang berikutnya, lihat §1.5.

11. Module Requirements

11.1 Identity & Access Management

Functional Requirements

Priority: Must = wajib untuk baseline; Should = direkomendasikan dan dapat bergantung pada konfigurasi/kebijakan organisasi.

11.2 Organization Management

Fitur:

• company;
• business unit;
• department;
• branch;
• location;
• cost center;
• organizational hierarchy.

Requirement:

ORG-001 Sistem harus dapat menyimpan struktur organisasi.

ORG-002 User harus dapat dikaitkan dengan unit organisasi.

ORG-003 Approval dapat menggunakan struktur organisasi.

11.3 Procurement Planning

Fitur:

• Annual Procurement Plan;
• procurement category;
• estimated budget;
• target date;
• requester;
• department;
• priority;
• procurement method.

Status:

Draft
→ Submitted
→ Review
→ Approved
→ Rejected
→ Cancelled

11.4 Purchase Request

Fitur:

• request number;
• requester;
• department;
• item/service;
• quantity;
• specification;
• estimated price;
• budget;
• required date;
• attachment;
• justification.

Approval (contoh aliran PR in-app — gelombang berikutnya):

flowchart TD
  Req["Requester"] --> Dept["Department Head"]
  Dept --> Fin["Finance / Budget"]
  Fin --> Proc["Procurement"]

11.5 Vendor Management

Vendor lifecycle (rilis ini):

flowchart TD
  Draft["Draft / Registered"] --> Submit["Submitted"]
  Submit --> Review["Review per file"]
  Review -->|tolak| Rev["Revision"]
  Rev --> Submit
  Review --> Skt["Verified + SKT"]
  Skt --> Active["Active"]
  Active --> Hold["Suspended / Blacklisted"]

SKT (Surat Keterangan Terdaftar): bukti resmi bahwa vendor terdaftar dan boleh ikut lelang. Diterbitkan internal (Terbitkan SKT) setelah semua dokumen wajib berstatus approved. Sistem mengisi nomor SKT + masa berlaku (bulan dikonfigurasi, default 12). Vendor mengunduh PDF SKT di portal. Perpanjang SKT hanya oleh akun vendor pemilik perusahaan di portal (masa berlaku baru otomatis, tanpa input tanggal). Internal Head/PIC/Approver tidak menerbitkan perpanjangan. Tidak ada SKT sementara. UI menampilkan masa berlaku + kewajiban perpanjangan (H-90 / H-60 / H-30 / H-7, lalu kadaluarsa): ikut lelang baru diblokir sampai vendor memperpanjang. Bid yang sudah masuk sebelum kadaluarsa tetap diproses.

Data vendor:

11.6 Vendor Registration

Vendor harus dapat:

1. membuat account;
2. memverifikasi email (wajib sebelum simpan / unggah / submit / ikut tender);
3. mengisi company profile pada form lengkapi (status draft / revision / rejected — bukan mode baca + Edit/Download);
4. memilih kategori kualifikasi dari katalog master aktif (multi-select);
5. upload legal documents (requirement mengikuti kategori);
6. mengisi PIC;
7. mengisi bank information;
8. mengisi experience;
9. submit registration (checklist kelengkapan: identitas → kategori → bank → keuangan → dokumen → pengalaman);
10. setelah SKT terbit: unduh PDF SKT. Download profil perusahaan hanya setelah submit / SKT.

Sistem membuat status registrasi:

flowchart TD
  Draft["draft"] --> Submitted["submitted"]
  Submitted --> Review["review"]
  Review --> Revision["revision"]
  Revision --> Submitted
  Review --> Verified["verified + SKT"]
  Review --> Rejected["rejected"]

Desk rekanan: Head menunjuk PIC registrasi, Checker berkas, dan Approver SKT (bukan role baru). Petugas boleh diganti; assignment lama tidak dihapus. Hanya PIC/Checker (atau Head setelah PIC ditunjuk) yang mereview. Tolak berkas wajib catatan yang tampil ke vendor (mis. data keuangan salah unggah, mohon ganti). Terbitkan SKT (TDR) hanya Approver SKT, atau PIC jika Approver belum diisi, atau Head. Ditolak jika dokumen wajib belum semua approved.

Internal review dokumen per file (Preview / Approve / Tolak + catatan wajib saat tolak). Tolak dokumen dapat mengembalikan status ke revision. Jejak status (submit, revisi, ganti petugas, SKT) tercatat.

Peta peran dan slot: USER_JOURNEY.md “Keputusan terkunci”. Jangan menambah role Spatie untuk desk atau roster.

11.7 Vendor Qualification

Qualification memakai checklist dokumen per kategori:

• legal;
• administrative;
• financial;
• technical;
• experience;
• certification;
• compliance.

Setiap file punya status review: pending / approved / rejected (+ catatan).

Scoring kualifikasi dokumen:

Pass / Fail per dokumen wajib → prasyarat Terbitkan SKT

Scoring kinerja vendor pasca-award terpisah (modul performance).

11.8 Tender Management

Data tender:

Tender status:

flowchart TD
  Draft["draft"] --> Open["open / published"]
  Open --> Eval["evaluation"]
  Eval --> Appr["approval"]
  Appr --> Awarded["awarded"]
  Awarded --> Closed["closed"]
  Draft --> Cancel["cancelled"]
  Open --> Cancel

11.9 Tender Types

Jenis yang didukung:

• Open Tender;
• Limited Tender;
• Request for Quotation (RFQ).

11.10 Tender Package / Lot

Satu tender dapat memiliki beberapa lot.

Contoh:

Tender: IT Infrastructure

Lot 1 - Server
Lot 2 - Network
Lot 3 - Storage
Lot 4 - Security

Vendor dapat:

• mengikuti semua lot;
• mengikuti sebagian lot;
• memberikan penawaran per lot.

11.11 Tender Publication

Public information:

• tender number;
• title;
• category;
• location;
• deadline;
• qualification;
• procurement method;
• estimated value jika diperbolehkan.

Private information:

• confidential documents;
• HPS;
• internal evaluation;
• committee notes.

11.12 Tender Invitation

Procurement dapat memilih:

• seluruh qualified vendor;
• vendor tertentu;
• vendor berdasarkan category;
• vendor berdasarkan location;
• vendor berdasarkan qualification.

11.13 Tender Document

Dokumen dapat memiliki:

• version;
• upload date;
• uploader;
• classification;
• access rule;
• checksum;
• revision.

Contoh:

Tender Document v1
Addendum v2
Addendum v3

11.14 Clarification / Q&A

Fitur:

• question;
• answer;
• attachment;
• public/private flag;
• timestamp;
• deadline;
• notification.

Public clarification harus dapat diberikan kepada seluruh peserta apabila informasinya relevan untuk semua peserta.

11.15 Bid Submission

Bid terdiri dari:

Sistem wajib:

• melakukan validation;
• memastikan required documents;
• mencatat timestamp;
• mengunci submission setelah deadline;
• menyediakan bukti submission.

11.16 Sealed Bid

Commercial bid harus dapat dikunci sampai waktu bid opening.

flowchart TD
  Before["Sebelum deadline — harga terkunci"] --> After["Setelah deadline — boleh dibuka"]
  After --> Unseal["Ketua / Head unseal"]

Procurement user yang tidak berwenang tidak boleh melihat harga sebelum bid opening.

11.17 Bid Opening

Bid opening harus menghasilkan:

• opening timestamp;
• list peserta;
• submission status;
• technical document status;
• commercial document status;
• bid value jika sudah dibuka;
• opening record.

11.18 Evaluation

Urutan GATE Phase 1:

flowchart TD
  Open["Pembukaan"] --> CoI["CoI"]
  CoI --> Check["Pass / Fail"]
  Check --> Score["Skor teknis / komersial"]
  Score --> Rec["Recommend per lot"]
  Rec --> Lock["Ranking lock"]
  Lock --> Dec{"Approver"}
  Dec -->|approve| Award["Award + notify"]
  Dec -->|reject atau return| Score

Evaluation dapat menggunakan:

Pass / Fail

Requirement
→ Pass
→ Fail

Weighted Scoring

Contoh:

Combined Evaluation

Technical = 60%
Commercial = 40%

Formula:

Final Score =
(Technical Score × Technical Weight)
+
(Commercial Score × Commercial Weight)

11.19 Evaluation Independence

Technical evaluator tidak boleh mengubah commercial score.

Commercial evaluator tidak boleh mengubah technical score.

Setiap evaluator memiliki:

• assigned task;
• deadline;
• scoring form;
• comment;
• submission timestamp.

11.20 Evaluation Matrix

Sistem harus dapat membuat matrix:

11.21 Tender Ranking

Sistem otomatis membuat ranking berdasarkan evaluation rule.

Ranking dapat:

• manual override dengan alasan;
• otomatis;
• locked setelah approval.

Setiap perubahan ranking harus tercatat dalam audit trail.

11.22 Approval Workflow

Workflow harus configurable.

Contoh (produk penuh; rilis ini memakai roster publish + SoD award):

flowchart TD
  Tender["Tender"] --> PM["Procurement Manager"]
  PM --> DH["Department Head"]
  DH --> Dir["Director"]
  Dir --> Mgmt["Management"]

Rule berdasarkan:

• value;
• category;
• organization;
• procurement method;
• risk level.

Action:

• Approve;
• Reject;
• Return;
• Request Revision;
• Delegate.

11.23 Award Management

Setelah evaluation:

flowchart TD
  Eval["Evaluasi"] --> Rec["Recommend per lot"]
  Rec --> Appr["Approver pemenang"]
  Appr -->|approve| Award["Award + notify menang/kalah"]
  Appr -->|reject atau return| Eval
  Award --> Spk["SPK"]

Award data:

• winner;
• lot;
• awarded value;
• reason;
• approval;
• award date.

11.24 Vendor Notification

Vendor mendapatkan:

• selected;
• unsuccessful;
• clarification;
• revision;
• additional document request.

11.25 Contract Management

Kontrak: nomor, vendor, tender/lot, nilai, periode, payment terms, notes, dan status lifecycle.

Contract data:

Contract status:

flowchart TD
  Draft["Draft"] --> Review["Review"]
  Review --> Ok["Approved"]
  Ok --> Active["Active"]
  Active --> Exp["Expired"]
  Active --> Term["Terminated"]

11.26 Contract Amendment

Mendukung:

• value amendment;
• scope amendment;
• date extension;
• clause amendment;
• vendor amendment.

Setiap amendment harus memiliki:

• reason;
• approval;
• effective date;
• document.

11.27 Purchase Order

PO dari kontrak aktif (bukan langsung dari award). Modul ini gelombang berikutnya (§1.5.3).

PO dibuat berdasarkan award/contract.

Data:

• PO number;
• vendor;
• item/service;
• quantity;
• price;
• tax;
• delivery;
• payment terms.

PO status:

Draft
Approved
Issued
Partially Fulfilled
Completed
Cancelled

11.28 Fulfillment

Untuk barang:

• shipment;
• delivery;
• receiving;
• quantity received;
• inspection;
• goods receipt.

Untuk jasa:

• milestone;
• progress;
• service acceptance;
• completion.

11.29 Invoice

Vendor dapat submit:

• invoice;
• tax invoice;
• supporting document;
• PO;
• delivery receipt;
• service acceptance.

Validation:

PO
+
Receipt
+
Invoice
=
Three-Way Match

11.30 Payment Tracking

Sistem tidak harus menjadi banking system.

Sistem mencatat:

• invoice approved;
• payment requested;
• payment processed;
• payment date;
• payment reference;
• payment status.

11.31 Document Management

| Document Category |

|---|

| vendor |

| tender |

| technical |

| commercial |

| evaluation |

| award |

| contract |

| PO |

| invoice |

| payment |

Requirement:

• versioning;
• access control;
• retention;
• download tracking;
• upload history;
• checksum;
• metadata.

11.32 Notification Center

Channels:

• Email;
• in-app;
• push;
• WhatsApp (optional).

Events:

• tender invitation;
• clarification;
• deadline;
• approval;
• award;
• contract;
• invoice;
• payment.

11.33 Dashboard

Procurement Dashboard

Metrics:

• active tender;
• upcoming tender;
• completed tender;
• total procurement value;
• savings;
• average cycle time;
• vendor participation.

Management Dashboard

• procurement spend;
• procurement by department;
• procurement by category;
• vendor concentration;
• savings;
• contract utilization;
• pending approvals.

Vendor Dashboard

• available tender;
• participated tender;
• active tender;
• submitted bids;
• award;
• contracts;
• invoices;
• payment status.

11.34 Reporting

Reports:

1. Procurement Plan Report
2. Purchase Request Report
3. Tender Report
4. Vendor Report
5. Bid Participation Report
6. Evaluation Report
7. Award Report
8. Contract Report
9. PO Report
10. Invoice Report
11. Payment Report
12. Savings Report
13. Vendor Performance Report
14. Audit Report

Export:

• PDF;
• Excel;
• CSV.

11.35 Audit Trail

Audit event harus mencatat:

| Field |

|---|

| user |

| role |

| timestamp |

| IP |

| action |

| entity |

| entity ID |

| old value |

| new value |

| reason |

| document |

| session/device bila tersedia |

Contoh:

User: procurement.manager
Action: APPROVE_TENDER
Tender: TR-2026-001
Timestamp: 2026-08-11 14:32:20
IP: x.x.x.x

Audit record tidak boleh dapat diubah melalui UI biasa.

12. Business Rules

BR-001 Tender Number

Nomor tender harus unik.

Format dapat dikonfigurasi:

TR/{YEAR}/{SEQUENCE}

Contoh:

TR/2026/0001

BR-002 Deadline

Vendor tidak dapat submit bid setelah deadline.

BR-003 Bid Lock

Commercial bid tidak dapat dilihat sebelum opening time.

BR-004 Submission

Setiap submission harus memiliki timestamp.

BR-005 Modification

Setelah deadline, vendor tidak dapat mengubah submission.

BR-006 Approval

User tidak boleh approve request yang dibuat sendiri apabila segregation of duties diterapkan.

BR-007 Evaluation

Evaluator hanya dapat mengakses tender yang ditugaskan.

BR-008 Audit

Perubahan data penting harus tercatat.

BR-009 Document

Dokumen confidential hanya dapat diakses role yang berwenang.

BR-010 Award

Award hanya dapat dibuat setelah evaluation selesai dan approval terpenuhi.

BR-011 Timezone & Clock

Semua deadline (clarification, bid submission, opening) dievaluasi terhadap server time. Storage timestamp dalam UTC; tampilan default Asia/Jakarta. Client clock diabaikan.

BR-012 Bid Submission Evidence

Setiap submit menghasilkan submission receipt (ID unik, hash dokumen, timestamp server, tender/lot, vendor) yang dapat diunduh vendor.

BR-013 Late Bid

Request yang mencapai server setelah deadline → ditolak (409/422), tercatat di audit sebagai late attempt (tanpa menyimpan isi commercial bila ditolak).

BR-014 Tender Cancellation

Tender dapat dibatalkan oleh role berwenang dengan alasan wajib. Status → CANCELLED. Vendor peserta wajib dinotifikasi. Data tetap teraudit; tidak hard-delete.

BR-015 Retender

Retender membuat tender baru yang mereferensikan tender sebelumnya (supersedesTenderId). Tender lama ditutup/dibatalkan sesuai rule; history tetap ada.

BR-016 Disqualification

Vendor peserta dapat didiskualifikasi pada tahap administrasi/teknis/komersial dengan alasan + evidence. Vendor mendapat notifikasi. Bid tetap tersimpan untuk audit tetapi tidak masuk ranking aktif.

BR-017 Ranking Override

Override ranking hanya oleh role berwenang, wajib alasan, wajib approval tambahan bila dikonfigurasi, dan selalu masuk audit (old rank → new rank).

BR-018 HPS Confidentiality

HPS / owner estimate hanya untuk role internal berwenang. Tidak boleh muncul di Vendor Portal atau dokumen publik.

Pagu anggaran (plafond) boleh diinformasikan ke peserta jika panitia memilih mengumumkannya. Bukan kewajiban setiap paket. HPS dan pagu tidak boleh disamakan: pagu = batas anggaran yang diumumkan; HPS = perkiraan sendiri untuk menilai kewajaran harga.

BR-019 Document Immutability after Deadline

Setelah bid deadline, file bid vendor bersifat immutable (tidak replace/delete oleh vendor). Addendum tender dari procurement mengikuti versioning resmi.

BR-020 Minimum Participants (configurable)

Untuk tipe tender tertentu, sistem dapat menegakkan jumlah peserta minimum sebelum opening/evaluation. Jika tidak terpenuhi → flag warning atau blok sesuai konfigurasi organisasi.

BR-021 One Active Bid per Vendor per Lot

Satu vendor hanya punya satu bid aktif per lot. Resubmit sebelum deadline menimpa versi sebelumnya dan mencatat versi/history.

BR-022 Soft Delete

Entity bisnis penting menggunakan soft-delete / status archive. Hard delete hanya untuk data draft milik sendiri atau oleh Super Admin dengan audit.

BR-023 Numbering

Nomor Tender, PR, Award, (dan Phase 2: Contract/PO/Invoice) unik per organization, format configurable, tidak dipakai ulang.

BR-024 Conflict of Interest Gate

Evaluator wajib menandatangani deklarasi CoI sebelum dapat submit score. Jika declared conflict → tidak dapat menilai vendor terkait sampai diganti.

BR-025 Currency

Phase 1: satu currency per tender (default IDR). Multi-currency = future.

13. Segregation of Duties

Sistem harus mencegah konflik kewenangan.

Contoh:

flowchart TD
  Req["Requester"] -.->|bukan| Ev["Evaluator"]
  Ev -.->|bukan| Ap["Approver"]
  Bid["Submit bid"] -.->|bukan| Open["Buka bid"]
  Open -.->|bukan| Final["Approve award"]

Maker ≠ Checker / Approver publish. Recommender ≠ Approver pemenang.

Rule dapat dikonfigurasi berdasarkan organisasi.

14. Conflict of Interest

Sistem dapat menyediakan declaration:

"Saya menyatakan tidak memiliki konflik kepentingan terhadap proses tender ini."

Data:

• evaluator;
• declaration;
• timestamp;
• status;
• disclosure.

Jika conflict ditemukan:

Declared
↓
Review
↓
Replacement Evaluator

15. Risk Management

Tender dapat memiliki risk score:

• Low;
• Medium;
• High;
• Critical.

| Parameter |

|---|

| procurement value |

| vendor risk |

| category risk |

| regulatory risk |

| operational risk |

Risk level dapat memengaruhi approval workflow.

16. Vendor Performance

Setelah contract selesai:

| Parameter |

|---|

| quality |

| delivery |

| service |

| compliance |

| communication |

| safety |

| documentation |

Score:

0–100

Vendor classification:

Excellent
Good
Fair
Poor
Critical

19. Integrations

Mandatory / Recommended

Email

Untuk:

• registration;
• notification;
• approval;
• tender;
• award.

Object Storage

Untuk:

• tender documents;
• vendor documents;
• bid documents;
• contracts.

Authentication

Dapat mendukung:

• local account;
• SSO;
• OAuth/OIDC.

Optional

| Integration |

|---|

| ERP |

| Accounting |

| HR |

| Tax |

| Digital Signature |

| WhatsApp |

| Payment Gateway |

| BI/Data Warehouse |

20. API Requirements

Platform harus menyediakan REST API untuk integrasi.

Contoh:

/api/auth
/api/users
/api/organizations
/api/vendors
/api/vendor-qualifications
/api/procurement-plans
/api/purchase-requests
/api/tenders
/api/tenders/{id}/participants
/api/tenders/{id}/clarifications
/api/tenders/{id}/bids
/api/tenders/{id}/evaluations
/api/awards
/api/contracts
/api/purchase-orders
/api/invoices
/api/payments
/api/documents
/api/notifications
/api/audit-logs
/api/reports

API harus menggunakan:

| Capability |

|---|

| authentication |

| authorization |

| validation |

| pagination |

| filtering |

| sorting |

| rate limiting |

| consistent error response |

| API versioning |

21. Non-Functional Requirements

21.1 Performance

Target awal:

• page response API: p95 < 500 ms untuk operasi standar;
• dashboard: < 3 detik untuk dataset normal;
• file upload mendukung resumable/chunk upload untuk file besar;
• pagination wajib untuk data besar.

Target harus divalidasi melalui performance testing terhadap asumsi beban di §49.

21.2 Availability

Target awal:

• Production availability: 99.5% atau lebih sesuai SLA.
• Backup terjadwal.
• Monitoring dan alerting.
• Observability minimum mengikuti §52.

21.3 Scalability

Sistem harus dapat berkembang untuk:

• multiple organizations;
• thousands of vendors;
• large tender documents;
• concurrent bid submission;
• multiple active tenders.

21.4 Security

| Security Control |

|---|

| TLS/HTTPS |

| secure password hashing |

| RBAC |

| MFA |

| CSRF/XSS/SQL injection protection |

| rate limiting |

| secure headers |

| encrypted sensitive data |

| private file storage |

| malware scanning |

| audit logging |

| backup encryption |

21.5 Privacy

Data pribadi dan data perusahaan harus:

• memiliki access control;
• tidak ditampilkan kepada user yang tidak berwenang;
• memiliki retention policy;
• dapat dihapus/diarsipkan sesuai kebijakan organisasi dan kewajiban hukum.

22. Data Model High Level

Entity utama:

Organization
User
Role
Permission
Department
CostCenter

Vendor
VendorUser
VendorDocument
VendorQualification
VendorCategory
VendorPerformance

ProcurementPlan
PurchaseRequest
PurchaseRequestItem

Tender
TenderLot
TenderDocument
TenderParticipant
TenderInvitation
TenderClarification

Bid
BidDocument
BidItem
BidOpening

Evaluation
EvaluationCriteria
EvaluationScore
EvaluationCommittee

Approval
ApprovalStep

Award
AwardItem

Contract
ContractAmendment

PurchaseOrder
PurchaseOrderItem

Delivery
Receipt

Invoice
InvoiceItem
Payment

Notification
AuditLog

23. High-Level Relationship

Organization
 ├── Users
 ├── Departments
 ├── Vendors
 └── Procurement Plans

Procurement Plan
 └── Purchase Request
      └── Tender
           ├── Lots
           ├── Documents
           ├── Participants
           ├── Clarifications
           └── Bids
                └── Evaluations
                     └── Award
                          └── Contract
                               └── PO
                                    ├── Delivery
                                    └── Invoice
                                         └── Payment

24. Status Management

Semua entity utama harus menggunakan state machine yang jelas.

Contoh Tender (normalized — lihat detail §47):

DRAFT
REVIEW
APPROVED
PUBLISHED
OPEN
CLARIFICATION
BID_SUBMISSION
SUBMISSION_CLOSED
BID_OPENING
EVALUATION
PENDING_APPROVAL
AWARDED
CLOSED
CANCELLED

CONTRACTED masuk Phase 2 setelah modul kontrak. Transisi status harus memiliki rule dan permission.

25. User Experience

Internal Portal

Menu:

Dashboard
Procurement
 ├── Procurement Plan
 ├── Purchase Request
 ├── Tenders
 ├── Evaluations
 └── Awards

Vendors
 ├── Vendor List
 ├── Qualification
 └── Performance

Contracts
 ├── Contracts
 ├── PO
 └── Amendments

Finance
 ├── Invoice
 └── Payment

Reports
Audit
Settings

Vendor Portal

Dashboard
Company Profile
Documents
Tender
 ├── Available
 ├── Participating
 └── Completed

Clarification
Bid Submission
Award
Contract
Invoice
Payment
Notifications

26. Search & Filter

Data utama harus mendukung:

• keyword;
• status;
• date range;
• organization;
• category;
• vendor;
• value range;
• procurement method.

Contoh:

Tender
[ Search ]

Status: Active
Category: IT
Value: > Rp1 M
Date: Aug 2026

27. Approval Engine

Approval engine harus configurable tanpa perubahan source code untuk rule umum.

Contoh rule:

IF tender_value < 500M
THEN Procurement Manager

IF tender_value >= 500M AND < 5B
THEN Procurement Manager + Director

IF tender_value >= 5B
THEN Procurement Manager + Director + Board

Workflow juga dapat berdasarkan:

• department;
• category;
• risk;
• procurement method.

28. SLA Management

Setiap proses dapat memiliki SLA:

Sistem harus memberikan:

• countdown;
• overdue status;
• reminder;
• escalation.

29. Notification Rules

Contoh:

Tender Published
→ Notify Qualified Vendors

Bid Deadline - 24 Hours
→ Reminder Vendor

Evaluation Assigned
→ Notify Evaluator

Approval Pending
→ Notify Approver

Approval Overdue
→ Escalation

30. Audit & Compliance Evidence

Untuk setiap tender, sistem harus dapat menghasilkan Tender Dossier:

Tender Dossier
├── Procurement Request
├── Approval
├── Tender Document
├── Addendum
├── Participant List
├── Clarification
├── Bid Submission Evidence
├── Bid Opening Record
├── Evaluation
├── Approval
├── Award
└── Contract

Tujuannya agar auditor dapat memperoleh seluruh evidence tender dari satu tempat.

31. Security Architecture Principles

Prinsip:

1. Least privilege.
2. Defense in depth.
3. Segregation of duties.
4. Zero trust untuk akses sensitif.
5. Secure-by-default.
6. Auditability.
7. Encryption.
8. Data minimization.

Dokumen bid harus menggunakan storage private dan authorization-based download.

32. Disaster Recovery

Minimum:

• automated backup;
• database backup;
• object storage backup;
• offsite backup;
• restore testing;
• disaster recovery procedure.

Parameter:

• RPO;
• RTO.

Contoh target:

RPO: ≤ 1 hour
RTO: ≤ 4 hours

Target final harus ditentukan berdasarkan SLA bisnis.

33. Cakupan sistem

Sumber: §6.3 dan §1.5.

Inti tender

Authentication & Session
Organization / Department / Cost Center (dasar)
User & Role & Permission Matrix
Vendor Registration + Email Verify + Document review (per-file Approve/Tolak)
Vendor SKT (Terbitkan / Perpanjang / PDF) + gate ikut lelang
Vendor List (Active / Suspended / Rejected / Verified)
Simplified Purchase Request (opsional → dapat dilink ke Tender)
Tender Management (Open / Limited / RFQ)
Tender Lots (dasar)
Tender Publication + Invitation
Tender Documents (version + ACL + checksum)
Clarification / Q&A (public/private)
Bid Submission (Technical + Commercial sealed)
Bid Opening (official record)
Evaluation (Pass/Fail + Weighted + Combined)
Evaluation Independence + Conflict of Interest declaration
Ranking (+ override beralasan + audit)
Configurable Approval (value-based minimal)
Award Management + Vendor notification
Email + In-app Notification
Immutable Audit Trail
Internal + Vendor Dashboard (dasar)
Document download tracking
System Admin: users, roles, master data, numbering, workflow rules
Panduan operasional in-app (DoD + SOP per role)

Pasca-award

Contract Management + Amendment
PO + Delivery / Service Acceptance
Invoice + Three-Way Match
Payment Status Tracking
Vendor Performance
Advanced Reporting / Export
SSO / MFA

34. MVP Acceptance Criteria

MVP dianggap berhasil apabila:

Vendor

• dapat registrasi;
• dapat melengkapi profil (termasuk kategori, bank, pengalaman);
• dapat upload dokumen wajib;
• dapat melihat status review dokumen (pending / approved / rejected);
• setelah SKT terbit: dapat unduh PDF SKT;
• dapat mengikuti tender hanya jika SKT aktif;
• dapat mengajukan pertanyaan;
• dapat submit bid;
• mendapatkan bukti submission (receipt PDF).

Procurement

• dapat review dokumen vendor (Preview / Approve / Tolak per file);
• dapat Terbitkan SKT (ditolak jika dokumen wajib belum approved);
• Perpanjang SKT hanya akun vendor pemilik di portal (bukan menu detail vendor internal);
• Head dapat membuka paket + menunjuk panitia; Maker dapat mengisi TOR/jadwal/dokumen;
• dapat menentukan peserta;
• dapat upload dokumen;
• dapat membuat jadwal;
• dapat mengelola clarification;
• dapat membuka bid sesuai jadwal;
• dapat melakukan evaluasi;
• dapat membuat ranking;
• dapat meminta approval;
• dapat menetapkan pemenang.

Governance

• semua action penting tercatat;
• role dan permission berjalan;
• commercial bid terlindungi sebelum opening;
• approval workflow berjalan;
• dokumen memiliki access control;
• DoD/SOP per role tersedia di halaman Panduan (/guides, /vendor/guides).

Pasca-award

• award approved dapat dijadikan kontrak;
• panitia menerbitkan SPK dan dokumen pendukung; jaminan pelaksanaan (biasanya 5% nilai kontrak) punya batas, serah, dan terima sebelum kontrak berlaku;
• paket dokumen kontrak fleksibel: beberapa PDF, masing-masing nama + catatan (regulasi organisasi berbeda);
• addendum (nilai/tanggal/lingkup) pada kontrak aktif;
• kontrak dapat di-activate lalu diterbitkan PO;
• delivery dapat diterima/ditolak;
• invoice dapat di-submit, di-match (3-way dasar), di-approve/reject;
• pengajuan invoice wajib scan BAST, invoice, dan faktur pajak; dokumen asli diserahkan ke loket yang diumumkan (pembayaran menunggu penerimaan asli);
• payment dapat di-track (request → process);
• vendor dapat melihat dan mengerjakan pemenuhan di portal (scoped);
• kinerja vendor dapat dicatat;
• laporan ringkasan + export CSV tersedia bagi role yang berwenang;
• MFA TOTP dapat diaktifkan; SSO/OIDC dikonfigurasi di environment (mock atau oidc).

35. Success Criteria

Produk dianggap sukses jika:

1. Tender dapat diselesaikan secara end-to-end tanpa email sebagai media utama.
2. Vendor dapat melakukan seluruh aktivitas dari portal.
3. Procurement dapat mengelola tender dari satu dashboard.
4. Evaluation dapat dilakukan secara digital.
5. Management dapat melakukan approval secara digital.
6. Seluruh evidence tender dapat ditelusuri.
7. Audit trail tersedia.
8. Waktu procurement cycle menurun.
9. Penggunaan dokumen manual berkurang.
10. Data procurement dapat digunakan untuk analytics.

36. Risks

37. Key Governance Principles

Platform harus menerapkan:

| Principle |

|---|

| Transparency |

| Accountability |

| Traceability |

| Segregation of Duties |

| Least Privilege |

| Fair Competition |

| Confidentiality |

| Auditability |

38. Recommended Product Architecture

High level:

                    USERS
                      │
          ┌───────────┴───────────┐
          │                       │
    Internal Portal          Vendor Portal
          │                       │
          └───────────┬───────────┘
                      │
                  API Layer
                      │
          ┌───────────┴───────────┐
          │                       │
   Procurement Services      Identity/Auth
          │
   ┌──────┼──────┬──────┬──────┐
   │      │      │      │      │
 Tender Vendor Eval Contract Finance
   │      │      │      │      │
   └──────┴──────┴──────┴──────┘
                  │
             Database
                  │
           Object Storage
                  │
        Notification Services

39. Recommended Technology Direction

Technology dapat disesuaikan dengan organisasi.

Untuk web enterprise modern, salah satu opsi:

Frontend

• Next.js
• React
• TypeScript
• Bootstrap 5
• Bootstrap Icons

Backend

• Node.js
• REST API
• TypeScript

atau:

• PHP
• CodeIgniter / Laravel
• REST API

Database

• PostgreSQL atau MySQL

Storage

• S3-compatible Object Storage

Cache / Queue

• Redis

Search

• PostgreSQL Full Text Search untuk MVP;
• Elasticsearch/OpenSearch jika kebutuhan berkembang.

Infrastructure

• Linux
• Nginx
• Docker
• CI/CD
• Monitoring
• Centralized Logging

40. Tahapan di dalam sistem

Tahap 1 — Fondasi

• authentication;
• organization;
• RBAC;
• vendor;
• master data.

Tahap 2 — Tender

• procurement request;
• tender;
• publication;
• vendor participation;
• clarification;
• bid.

Tahap 3 — Evaluasi

• bid opening;
• technical evaluation;
• commercial evaluation;
• ranking;
• approval;
• award.

Tahap 4 — Pasca-award

• contract;
• PO;
• delivery;
• invoice;
• payment tracking.

Tahap 5 — Laporan & kinerja

• analytics;
• vendor performance;
• pelaporan operasional.

41. Recommended Product Modules

Final module structure:

01 Identity & Access
02 Organization
03 Master Data
04 Procurement Planning
05 Purchase Request
06 Vendor Management
07 Vendor Qualification
08 Tender Management
09 Tender Participation
10 Clarification
11 Bid Management
12 Bid Opening
13 Evaluation
14 Approval Workflow
15 Award Management
16 Contract Management
17 Purchase Order
18 Fulfillment
19 Invoice
20 Payment Tracking
21 Vendor Performance
22 Document Management
23 Notification
24 Dashboard
25 Reporting
26 Audit & Compliance
27 Risk Management
28 System Administration

42. Final Business Process

flowchart TD
  Plan["Planning"] --> PR["Purchase Request"]
  PR --> Budget["Budget"]
  Budget --> Source["Sourcing"]
  Source --> Tender["E-Tender"]
  Tender --> Bid["Bid"]
  Bid --> Open["Pembukaan"]
  Open --> Tech["Evaluasi teknis"]
  Tech --> Comm["Evaluasi komersial"]
  Comm --> Rank["Ranking"]
  Rank --> Rec["Recommend"]
  Rec --> Award["Award"]
  Award --> Spk["SPK"]
  Spk --> Next["PO / Invoice / Pembayaran — gelombang berikutnya"]

43. Conclusion

eProcurement & E-Tender Management Platform bukan sekadar aplikasi untuk mengumumkan tender. Produk ini harus menjadi sistem yang mengendalikan seluruh lifecycle procurement dengan prinsip:

• digital;
• transparent;
• secure;
• auditable;
• configurable;
• scalable;
• data-driven.

E-Tender menjadi core module, sedangkan Vendor Management, Evaluation, Approval, Contract, Document Management, Audit Trail, dan Reporting menjadi komponen yang memastikan proses procurement dapat berjalan secara end-to-end.

Rilis ini memprioritaskan Vendor → Tender → Bid → Evaluation → Approval → Award → SPK, dengan roster per tender (request User ke Head di luar platform, §1.5.2). PO → Invoice → Payment adalah gelombang berikutnya.

Detail kontrak build, FR MVP, keamanan sealed bid, exception flow, NFR load, dan Definition of Done ada di §44–§55.

44. Phase 1 Functional Requirements (Build-Ready)

Prioritas: Must = fitur sistem; Should = tersedia lewat konfigurasi atau kebijakan organisasi.

44.1 Identity & Access

44.2 Organization & Master Data

44.3 Vendor

44.4 Purchase Request (Simplified)

44.5 Tender

44.6 Clarification

44.7 Bid & Opening

44.8 Evaluation, Ranking, Approval, Award

44.9 Document, Notification, Audit, Dashboard

45. Exception & Alternate Flows (Phase 1)

46. Sealed Bid & Sensitive Data Requirements

46.1 Business guarantee

Sebelum Bid Opening resmi:

• Commercial price/details tidak dapat dibaca oleh Procurement Admin, Evaluator teknis, Approver, atau Vendor lain.
• Role dengan privilege bid.commercial.preopen (jika ada) harus dinonaktifkan default; pemakaian privilege ini wajib audit kritis.
• Technical documents dapat dibuka sesuai konfigurasi metode (satu tahap vs dua tahap).

46.2 Technical expectations (untuk FRD)

Minimal salah satu pendekatan yang diterima:

1. Application-enforced seal (MVP acceptable): commercial payload tersimpan terenkripsi at-rest; decrypt key hanya di unlock workflow saat opening event; API menolak read sebelum status opening.
2. Stronger (Should/Phase 2): envelope encryption per tender; key split / quorum opening.

Wajib:

• Enkripsi at-rest untuk file sensitif;
• Authorization check setiap download;
• Signed opening record (who, when, which bids unlocked);
• Penolakan akses tercatat di audit.

46.3 Two-envelope support

47. State Machines (Normalized)

47.1 Tender

flowchart TD
  Draft["draft"] --> Open["open"]
  Open --> Eval["evaluation"]
  Eval --> Appr["approval"]
  Appr --> Awarded["awarded"]
  Awarded --> Closed["closed"]
  Draft --> Cancel["cancelled"]
  Open --> Cancel
  Eval --> Cancel

Klarifikasi tertulis overlap dengan open, bukan status terpisah. Jangan pakai dua arti closed.

47.2 Vendor Registration

flowchart TD
  Draft["draft"] --> Submitted["submitted"]
  Submitted --> Review["review"]
  Review --> Revision["revision"]
  Revision --> Submitted
  Review --> Verified["verified + SKT"]
  Review --> Rejected["rejected"]
  Verified --> Active["active"]
  Active --> Hold["suspended / blacklisted"]

47.3 Bid

flowchart TD
  Draft["draft"] --> Submitted["submitted"]
  Submitted --> Locked["locked — deadline"]
  Locked --> Opened["opened — pembukaan"]
  Opened --> Eval["under evaluation"]
  Eval --> Qual["qualified"]
  Eval --> Dq["disqualified"]

47.4 Approval

flowchart TD
  Pending["pending"] --> Ok["approved"]
  Pending --> No["rejected"]
  Pending --> Back["returned"]
  Pending --> Del["delegated"]
  Del --> Pending

48. Permission Matrix (Phase 1 Minimum)

R = read-only. config = boleh jika diizinkan permission matrix organisasi.

49. Non-Functional Targets with Load Assumptions

Asumsi awal Phase 1 (wajib dipakai performance test):

Target:

50. Data Retention, Privacy & Localization

51. Integrasi yang dikonfigurasi

52. Observability & Operability

Must:

• Structured application logs (request id, user id, org id);
• Metrics: latency, error rate, bid submit rate, queue lag;
• Alerting: 5xx spike, job failures, storage errors, login anomaly;
• Backup otomatis DB + object storage;
• Restore drill checklist minimal 1x sebelum production.

53. Compliance Evidence Pack (per Tender)

Satu aksi Generate Tender Dossier menghasilkan paket:

Tender Dossier
├── 00_index.pdf
├── 01_purchase_request/          (jika ada)
├── 02_tender_documents/
├── 03_addenda/
├── 04_invitations_participants/
├── 05_clarifications/
├── 06_bid_receipts/
├── 07_bid_opening_record/
├── 08_evaluations/
├── 09_ranking_and_overrides/
├── 10_approvals/
├── 11_award/
└── 12_audit_extract/

Priority: Should di Phase 1; Must di Phase 2.

54. Definition of Done — Phase 1

Phase 1 selesai untuk development jika:

1. Semua FR Must di §44 terpenuhi.
2. Sealed commercial bid terverifikasi (uji akses negatif sebelum opening).
3. Deadline server-side ditegakkan (uji late bid).
4. SoD & permission matrix minimal §48 berjalan di server (bukan hanya di antarmuka).
5. Audit trail ada untuk: publish, invite, submit bid, open bid, score, override rank, approve, award, cancel.
6. Vendor dapat menyelesaikan registrasi → ikut tender → submit → terima receipt → terima hasil award notification.
7. Internal dapat draft → publish → open → evaluate → approve → award end-to-end tanpa email sebagai media utama dokumen.
8. Tidak ada lint/type error baru di area perubahan; smoke test path utama lulus.
9. Backup/restore dan secret management production-ready sesuai handbook.
10. Alur tender hingga pemenuhan kontrak berjalan sesuai §1.5 dan checklist GATE.

55. Konfigurasi organisasi

Nilai berikut mengikuti kebijakan organisasi (lihat juga §1.4):

Appendix A — Menu portal internal (rilis ini)

Dashboard

Tenders
├── Semua
├── Draft
├── Published
├── Evaluation
├── Awarded
└── Closed / Cancelled

Vendors
├── Daftar rekanan
├── Antrian registrasi
└── Kualifikasi / desk

Evaluation
├── Tugas saya
├── Teknis
├── Komersial
└── Ranking

Awards

Kontrak / SPK

Laporan

Audit Trail

Notifikasi

Panduan

Settings
├── Users
├── Roles & Permissions
├── Approval Workflow
├── Master Data
├── Numbering
└── System Configuration

Item menu hanya tampil jika pengguna punya permission terkait. URL tanpa izin → 403. Purchase Request, PO, invoice, pembayaran, dan kinerja vendor = gelombang berikutnya (§1.5.3).

Appendix B — Menu portal vendor (rilis ini)

Dashboard

Perusahaan
├── Profil (legal, kategori, bank, pengalaman, dokumen)
├── Status registrasi + status review dokumen
└── Unduh SKT (bila sudah terbit)

Tim pengguna          ← hanya Vendor Admin
Keamanan

Tender tersedia
├── Detail / dokumen (+ addendum)
├── Clarification
├── Ikut + Bid (GATE: SKT aktif)
└── Submission receipt PDF

Kontrak / SPK

Panduan

Tanpa SKT aktif, ikut tender diblokir. PO, invoice, dan kinerja vendor = gelombang berikutnya (§1.5.3).

Appendix C — Operasi harian

Agar email, pengingat, dan berkas berjalan di lingkungan organisasi:

• atur SMTP;
• jalankan scheduler dan queue worker;
• pilih disk penyimpanan (lokal atau S3);
• aktifkan pemindai unggahan bila diwajibkan kebijakan;
• pilih SSO mock atau oidc sesuai IdP.

Appendix D — Traceability (Phase 1 Core Path)

Appendix E — Dokumen terkait

1. SOW.md — lingkup operasional.
2. TRD.md — desain teknis.
3. API.md — REST /api/v1.
4. USER_JOURNEY.md — alur per peran.
5. PHASE1_JOURNEY_CHECKLIST.md — GATE dan UAT.
6. ENGINEERING.md — convention kode.
7. SIT_VENDOR_SKT_SPK.md — skenario SIT vendor → SPK.
8. UAT_GELOMBANG_1_4.md — skenario UAT TIM Gelombang 1–4.
9. BUMN_DIGITALISASI_CHECKLIST.md — backlog evidence BUMN.

End of Document