TOR Example

Senin, 08 Februari 2021
TERMS OF REFERENCE (TOR)

KALBE - E-TESTING
IT Services & Software Solutions
“Enterprise Trusted Friend”
KERANGKA ACUAN KERJA – PERANGKAT LUNAK

NO FORMULIR PEMESANAN : {ORDER_FORM_NO}
DOKUMEN INI MENENTUKAN LINGKUP PEKERJAAN YANG DISEPAKATI KEDUA BELAH PIHAK
SECARA RINCI
DAFTAR ISI
DAFTAR ISI ............................................................................................................................ 2

1 KALBE - E-TESTING FITUR PERANGKAT LUNAK................................................................ 5
1.1 IKHTISAR ................................................................................................................................... 5
1.2 APLIKASI BERBASIS WEB (BACK-END)........................................................................................... 5
1.2.1 Search, Sort, dan Filtering ................................................................................................. 5
1.2.2 Create, Update, Delete, View ............................................................................................ 5
1.2.3 E- Change Control ............................................................................................................. 6
1.2.4 LogIn (ReF ID : A.4, PG: 11)................................................................................................ 6
1.2.5 Lupa Password ................................................................................................................. 6
1.2.6 Dashboard E-Testing (ReF ID : A.5, PG: 12) ........................................................................ 6
1.2.6.1 Pembuatan Prosesdur Analisis & Spesifikasi (ReF ID : A.6 – A.7, PG: 13-15)................................................ 7
1.2.6.2 Pembuatan/Perubahan MWQT (ReF ID : A.8, PG: 15-21) .......................................................................... 8
1.2.7 Approval ......................................................................................................................... 10
1.2.7.1 Request for Approval (ReF ID : A.9, PG: 21) ............................................................................................. 10
1.2.7.2 Review & Approval (ReF ID : A.10, PG: 22-24) ......................................................................................... 10
1.2.8 e-Batch Records (e-BR) e-Deviasi (ReF ID : b.1 –b.3, PG: 26-31) ........................................ 11
1.2.9 WQT aktif (ReF ID : B.4 – b.5, PG: 31-32).......................................................................... 14
1.2.10 Pengujian Sample (ReF ID : B.6 – B.7, PG: 32-33) ............................................................. 14
1.2.11 Pengambilan Sample (ReF ID : b.8 – b.10, PG: 33-34) ....................................................... 15
1.2.12 Dashboard PIC (ReF ID : B.11 – B.15, PG: 34-40) .............................................................. 15
1.2.13 Hasil Analisis dan Trend Analisis (ReF ID : B.16 – B.17, PG: 40-41) .....................................17
1.2.14 OOS/OOT (ReF ID : C.2, PG: 43-44) ................................................................................. 18
1.2.14.1 Pemilihan Jenis Penyimpangan (ReF ID : C.3, PG: 44) .............................................................................. 18
1.2.14.2 E-Form Pelaporan OOS/OOT (ReF ID : C.4 – C.9, PG: 45-46) ................................................................... 18
1.2.14.3 e-form investigasi (ReF ID : C.10 – C.16, PG: 46-48) ................................................................................. 19
1.2.15 Pengujian Ulang ............................................................................................................. 20
1.2.15.1 Dashboard Pengujian Ulang/Retesting (ReF ID : d.2, PG: 52) .................................................................. 20
1.2.15.2 List Material (ReF ID : D.3, PG: 52) ......................................................................................................... 20
1.2.15.3 Notifikasi (ReF ID D.4, PG: 52-53)........................................................................................................... 20
1.2.15.4 Pemilihan Material (ReF ID : D.5, PG: 53) ................................................................................................. 21
1.2.15.5 Generate WQT (RM/PM) (ReF ID : D.7, PG: 53-54) .................................................................................. 21
1.2.15.6 Pengambilan sample (ReF ID : D.8 – D.10, PG: 54-55) .............................................................................. 21
1.2.15.7 Proses perpanjangan tanggal pengujian ulang dan disposisi status material (ReF ID : D.11 – D.13, PG: 55-
56) 22
1.2.16 Pengujian Bahan Awal .................................................................................................... 22
1.2.16.1 Kedatangan RM/PM dan pemastian CoA (ReF ID : E.1, PG: 59) ............................................................... 22
1.2.16.2 Notifikasi (ReF ID : E.2, PG: 59) .............................................................................................................. 22
1.2.16.3 Dashboard (ReF ID : E.4, PG: 60) ............................................................................................................. 23
RAHASIA – DOKUMEN INI ADALAH MILIK WGS PAGE 2 OF 51

1.2.16.4 List Material (ReF ID : E.5, PG: 61) ........................................................................................................... 23
1.2.16.5 Pilih material yang akan diuji (ReF ID : E.6 – E.7, PG: 61).......................................................................... 23
1.2.16.6 Generate worksheet QC testing (ReF ID : E.8, PG: 61-62) ........................................................................ 23
1.2.16.7 Pengambilan sampel pengujian, pengujian, dan input data hasil pengujian RM/PM (ReF ID : E.9 – E.11, PG:
62-64) 24
1.2.16.8 Disposisi status material (ReF ID : E.12, PG: 64-66) .................................................................................25
1.2.16.9 Main Database (ReF ID : E.13, PG: 66) .....................................................................................................25
1.2.17 Kontrol Inventori ............................................................................................................. 25
1.2.17.1 Dashboard (ReF ID : f.2, PG: 68-70) .........................................................................................................25
1.2.17.2 Pembuatan Reagen (ReF ID : F.10, PG: 72-74) ........................................................................................ 26
1.2.17.3 Generate worksheet QC Testing (Pereaksi) (ReF ID : F.11, PG: 74-75) ...................................................... 27
1.2.18 Uji Stabilita ..................................................................................................................... 27
1.2.18.1 Dashboard (ReF ID : G.2, PG: 78-79) ........................................................................................................ 27
1.2.18.2 Request Studi Stabilita (ReF ID : G.3, PG: 79-80) .................................................................................... 28
1.2.18.3 Request Terminasi Stabilita (ReF ID : G.4, PG: 80) .................................................................................. 28
1.2.18.4 Notifikasi (ReF ID : G.5, PG: 80-81) ......................................................................................................... 28
1.2.18.5 Program Stabilita (ReF ID : G.6, PG: 81-83) ............................................................................................ 29
1.2.18.6 protokol stabilita (ReF ID : G.7 – G.9, PG: 83-86) .................................................................................... 29
1.2.18.7 Review, dan approval. (ReF ID : G.10 – G.11, PG: 86-88) .......................................................................... 31
1.2.18.8 Permintaan dan pengambilan sampel stabilita, (ReF ID G.12, PG: 88-89) ................................................ 32
1.2.18.9 Pembuatan label sampel stabilita (ReF ID : G.13 – G.14, PG: 89-90) ......................................................... 32
1.2.18.10 Pemasukan sampel ke dalam chamber (ReF ID : G.15 – G.18, PG: 90-92) ............................................ 33
1.2.18.11 Generate WQT, sampling, result input, dan approval hasil analisa (ReF ID : G.19 – G.25, PG: 92-94) .... 33
1.2.18.12 Pembuatan laporan stabilita dan approval (ReF ID : G.26 – G.29, PG: 94-97) ....................................... 34
1.2.18.13 Terminasi Studi Stabilita, Review dan Approval. (ReF ID : G.30 – G.32, PG: 97-100) ............................. 36
1.2.19 Manajemen User ..............................................................................................................37
1.2.20 Manajemen Grup User / Role ............................................................................................37
1.2.21 Manajemen Hak Akses .....................................................................................................37
1.2.22 Manajemen Push Notification ..........................................................................................37
1.2.23 Settings .......................................................................................................................... 38
1.2.24 Sign Out ......................................................................................................................... 38
2 SOLUSI YANG DIUSULKAN .............................................................................................39
2.1 APLIKASI BERBASIS WEB (FRONT-END & BACK-END) ................................................................... 39
2.1.1 Teknologi yang digunakan............................................................................................... 39
2.1.2 Kompatibilitas browser.................................................................................................... 39
2.1.3 Responsive front-end ...................................................................................................... 39
2.2 STANDAR KUALITAS ................................................................................................................. 39
2.2.1 Standar kode Web back-end dan Baku Mutu.................................................................... 39
2.2.2 Kode standar Web front-end dan Baku Mutu ................................................................... 40
2.2.3 Back-End Application Performance ................................................................................. 40
2.2.4 Keamanan Aplikasi ......................................................................................................... 41
2.2.5 Standar Design ............................................................................................................... 41
2.2.5.1 Blank Slate ............................................................................................................................................. 41
2.2.5.2 E-mail Template ..................................................................................................................................... 41
2.2.5.3 Halaman Error 404 dan 500 .................................................................................................................... 41
2.2.6 Standar Plugin atau 3Rd Party Tools / Vendor ................................................................... 42
2.2.7 Standar Kesesuaian ........................................................................................................ 42
2.2.8 Standar Quality Control .................................................................................................. 42
2.2.8.1 Standar Testing ..................................................................................................................................... 42
2.2.8.2 QC Level 1 .............................................................................................................................................. 43
2.2.8.3 QC Level 2 ............................................................................................................................................. 44
2.2.8.4 QC Level 3 ............................................................................................................................................. 44
2.2.9 Validasi Aplikasi dan Standar Handling ........................................................................... 44
2.2.9.1 Validasi Form ........................................................................................................................................ 44
2.2.9.2 Breadcrumb .......................................................................................................................................... 44
2.2.9.3 Lazy Loading ......................................................................................................................................... 44
2.2.9.4 Pagination............................................................................................................................................. 44
2.2.9.5 Null Handling ........................................................................................................................................ 44
2.2.9.6 Retry Handling .......................................................................................................................................45
2.3 INFRASTRUKTUR ....................................................................................................................... 45
2.3.1 Penyedia Hosting ............................................................................................................ 45
2.3.2 Mode Pemeliharaan ........................................................................................................ 45
2.3.3 Backup dan pemantauan ................................................................................................ 45
2.3.4 Keamanan ...................................................................................................................... 45
2.4 CI/CD PIPELINE ........................................................................................................................ 46
3 HASIL AKHIR DAN DOKUMENTASI..................................................................................47
4 STRATEGI IMPLEMENTASI PROYEK ............................................................................... 48
4.1 STRATEGI DEPLOYMENT KE SISTEM PRODUKSI............................................................................. 48
4.2 MILESTONE ............................................................................................................................. 48

1 KALBE - E-TESTING FITUR PERANGKAT LUNAK
1.1 IKHTISAR
WGS akan mengembang sistem E-Testing. Sistem e-Testing adalah sistem yang memungkinkan
pengolahan data proses pengujian produk jadi dilakukan melalui sistem berbasis elektronik. Pengolahan
data tersebut meliputi dari pembuatan prosedur analisis produk jadi, spesifikasi produk, Catatan Hasil
Pemeriksaan (CHP), dan pelaksanaan pengujian produk. Sistem e-Testing ini bertujuan untuk
mengurangi duplikasi entry data, kesalahan dalam memasukkan data dan mempercepat proses analisis
data pengujian produk jadi.
Hasil dari pengolahan data pengujian produk jadi berbasis elektronik ini akan dikirimkan ke dalam
database utama dan nantinya dapat digunakan dalam pembuatan:
• CHP (Catatan Hasil Pemeriksaan)

• Certificate of Analysis (CoA)
• Trending analysis secara elektronik.
Sistem ini dapat dikembangkan lebih lanjut menjadi sistem manajemen sumber daya yang lebih
komprehensif yang terdiri dari manajemen reagen, media uji, pengujian bahan baku, dan fitur lainnya,
serta dapat diintegrasikan dengan sistem lain di dalam suatu sistem lingkungan digital yang lebih besar.
Project ini akan mencakup pembuatan aplikasi sebagai berikut:
1. Aplikasi back-end berbasis web
Role yang akan dihandle oleh aplikasi antara lain:
1. Superadmin
2. Admin
3. QC Analyst
4. QC Supervisior
5. QC Manager
6. TS/QA Supervisior
1.2 APLIKASI BERBASIS WEB (BACK-END)
1.2.1 SEARCH, SORT, DAN FILTERING

• Setiap halaman manajemen yang ada pada aplikasi ini akan memiliki fitur search, sort dan
filtering.
1.2.2 CREATE, UPDATE, DELETE, VIEW

• Setiap halaman manajemen yang ada pada aplikasi ini akan memiliki fitur create, update,
delete, view.

• Akan ada beberapa halaman manajemen yang tidak memperbolehkan penghapusan data dan
akan didetailkan pada pembahasan halaman manajemen tersebut.
1.2.3 E- CHANGE CONTROL

• Menu ini adalah menu yang mengatur sistem pengajuan perubahan atau usulan perubahan
• Perubahan terkait dengan Prosedur Analisis, Spesifikasi dan Template Worksheet QC Testing
akan diajukan melalui e-CC.
• Integrasi e-CC dan eTesting akan dilakukan pada next development
1.2.4 LOGIN (REF ID : A.4, PG: 11)

• QC supervisor login kedalam sistem e-Testing
• User akses akan dikategorikan menjadi minimal 5 tipe yaitu analis QC, supervisor QC, manager
QC, manager QA, dan TS/QA Supervisor sesuai dengan responsibility matrix.
• Kemudian form untuk mengisikan password akan ditampilkan dan admin dapat mengisikan
password mereka dan klik tombol “Sign In” atau menekan tombol Enter pada keyboard.
• Jika credential yang diisikan valid, admin akan dilempar ke halaman Homepage / Dashboard.
• Jika credential yang diisikan tidak valid, user akan melihat pesan error “Username or password
not match”.
• Session user akan disimpan di cookies sehingga user tidak perlu login kembali setelah menutup
halaman.
• Session user akan memiliki masa berlaku terbatas.
1.2.5 LUPA PASSWORD

• Lupa password menggunakan SSO Kalbe
1.2.6 DASHBOARD E-TESTING (REF ID : A.5, PG: 12)

• Setelah user login, maka user akan di arahkan ke halaman dashboard
• Pada halaman ini berisi informasi realtime graphic yang berisi status MWQT, pengujian produk
jadi/RM/PM yang sedang berjalan dan statusnya, data OOS/OOT, leadtime pengujian, utilisasi
alat dalam bentuk table berbentuk trending serta dapat di sort untuk dianalisa.
• UI berisi logo site, ID aktif, jam-tanggal-bulan dan tahun berjalan, nama produk, kode produk,
MWQT, status, tanggal efektif, terintegrasi pada e-CAPA (untuk pengembangan selanjutnya),
menu log out, menu notifikasi, dan help. -> Sudah dipindah ke persyaratan pengguna
• Status pengujian produk jadi/RM/PM akan diterima dari oracle yang terdiri dari accept, accept
with variance, planned, pending, in progress, complete, reject
• Terdapat master data utilisasi instrumen QC di dalam oracle yang dapat terintegrasi ke dalam
sistem e-Testing.
• Akses kedalam modul lain dapat melalui link portal di dalam dashboard
• Nama dan kode produk, serta RM/PM akan diambil dari item master Oracle.
• Jam, tanggal ,bulan dan tahun akan mengikuti pengaturan dedicated time server.

• ID aktif terdiri dari nama personil, avatar, departemen, job title, nama site, dan waktu login awal
pada sistem.
• Notifikasi sistem berisi update dari hasil kajian /persetujuan MWQT dan muncul secara sistem
• List Register notifikasi akan terdiri dari keseluruhan update dari modul e-Testing.
• Notifikasi menggambarkan status dokumen.
• Notifikasi pada modul ini akan bertintegrasi dengan e-Change Control (future development).
• Pembuatan MWQT dapat diakses melalui list menu dalam portal dashboard.
• Fitur help berisi mekanisme pelaporan bila terjadi gangguan/masalah pada sistem berupa
informasi untuk system support (IT – helpdesk)
• Fitur help mengikuti menu helpdesk yang sudah ada.
1.2.6.1 PEMBUATAN PROSESDUR ANALISIS & SPESIFIKASI (REF ID : A.6 – A.7, PG: 13-15)
• Pembuatan prosedur analisis & spesifikasi dapat diakses melalui menu prosedur analisis
/spesifikasi pada list menu dashboard
• Pada halaman ini Spesifikasi akan terdefinisikan dari oracle
• Prosedur analisis dapat dibuat setelah spesifikasi terdefiniskan
• Muncul pilihan terkait nama dan kode produk/RM/PM -> sudah ditambahkan RMPM
• Dalam laporan pada poin 2 terdapat spesifikasi produk jadi, IPC, RM/PM dan stabilita
• Prosedur Analisis (PA) produk dapat digunakan untuk lebih dari 1 SKU selama tidak terdapat
perbedaan parameter dan prosedur
• Laporan spesifikasi dalam e-Testing dibuat untuk 1 SKU produk jadi/RM/PM dan 1 jenis
spesifikasi-> sudah ditambahkan RMPM
• PA dan laporan spesifikasi dibuat dalam bentuk master template yang dikategorikan
berdasarkan jenis sediaan
• Parameter uji dalam PA dapat ditarik dari oracle berdasarkan nama dan, kode produk/RM/PM,
jenis spesifikasi yang dipilih dalam PA-> sudah ditambahkan RMPM
• Parameter uji berupa list of value
• Field prosedur dalam metode analisa adalah free of text
• Mampu menyediakan kebutuhan input perhitungan (rumus), graphic, dan tabel
• Bila terdapat perubahan didalam PA maupun spesifikasi terdapat notifikasi dalam e-Testing
• Perubahan PA dan spesifikasi dapat dilakukan jika sudah disetujui namun perubahan terkait PA
dan spesifikasi yang sedang digunakan tersebut dapat digunakan bila MWQT sudah di
selesaikan dan perubahan sudah diefektifkan
• Jika PA/spesifikasi direvisi, maka MWQT untuk PA/spek terdampak juga harus direvisi
• 1 PA bisa digunakan untuk beberapa produk (PA umum) -> beberapa produk dapat mengacu PA
yang sama
• Hanya ada satu nomor PA dan spesifikasi efektif yang terdapat didalam sistem.
• MWQT untuk analisis berdasarkan kontrak, user akan memilih pengujian dilakukan berdasarkan
kontrak dan field-field pada worksheet akan berwarna abu-abu (grey out) kecuali pada bagian
hasil akhir.

1.2.6.2 PEMBUATAN/PERUBAHAN MWQT (REF ID : A.8, PG: 15-21)

• Pembuatan MWQT dapat diakses melalui menu MWQT pada list menu dashboard
• Pada halaman ini Pembuatan/perubahan MWQT berupa modul pengujian yang terdiri dari PA,
spesifikasi produk/material, ragen, dan hasil analisis.
• MWQT akan dibuat per SKU dan materia
• MWQT dibuat dalam bentuk template sesuai jenis sediaan/material/stabilita
• Pembuatan MWQT dapat diakses melalui menu MWQT pada list menu dashboard
• Satu MWQT terdiri dari spesifikasi dan PA untuk satu tahapan produk/RM/PM
• Pada jendela MWQT terdapat menu pembuatan dan perubahan.
• Bila dipilih menu pembuatan seperti pada point 1 maka akan muncul jendela kerja pembuatan
MWQT dimana terdapat field parameter kosong yang harus diisi.
• Field parameter dapat berupa numeric range (angka) dan isian manual/free text untuk data
dinamis (cara analisis, dan rumus perhitungan). Parameter uji dapat ditarik dari oracle sesuai
dengan pemilihan kode atau nama produk/RM/PM.
• MWQT terdiri dari tahapan proses produksi/pengujian material/stabilita/ dan pereaksi yang
tergenerate dari PA dan spesifikasi yang sudah dibuat pada tahapan A.6 dan A.7.
• Setiap tahapan akan terdiri dari prosedur dan spesifikasi.
• Pada saat pemakaian MWQT spesifikasi yang dipilih akan disesuaikan dengan tahapan proses.
Misal: bila MWQT digunakan saat proses produksi maka spesifikasi yang digunakan adalah
spesifikasi IPC dan bila MWQT digunakan saat pengujian produk jadi/stabilita maka spesifikasi
yang digunakan adalah spesifikasi produk jadi/stabilita.
• Untuk hasil In Process Control (IPC) data yang tergenerate ke dalam WQT adalah nilai uji
minum dan maximum, namun secara raw data IPC akan tetap terinput kedalam sistem.
• Font default adalah Tahoma, ukuran 11, ukuran form A4, headernya terdapat logo perusahaan,
halaman terdiri dari x of y.
• Form MWQT berisi logo perusahaan, nama produk, kode produk, spesifikasi produk, tanggal
efektif, tanggal review, bentuk sediaan, komposisi zat aktif, potensi/dosis, parameter uji,
prosedur analisis tiap parameter uji, setting alat, reagen yang digunakan dan aktual
penggunannya, limit keberterimaan. --- header – (Logo perusahaan, nama produk/RM/PM, kode
produk/RM/PM, no. MWQT, tanggal efektif, tanggal review)
o Parameter dan prosedur analisis akan tergenerate dari prosedur analisis yang telah
dibuat.
o Spesifikasi/limit akan tergenerate dari spesifikasi yang telah dibuat.
o Pada setiap parameter pengujian didalam MWQT terdapat link antara prosedur analisis
dan spesifikasi pengujian yang digunakan.
o Untuk aktual, diisi sesuai kondisi aktual penyiapan reagen, penimbangan, dan pengujian.
o MWQT berisi prosedur analisis untuk raw material, packaging material, reagen, produk
jadi, dan stabilita.
o MWQT terbagi menjadi prosedur analisis yang dilakukan oleh personil produksi dan
personil QC.
o Rumus dalam MWQT harus dilakukan validasi secara sistem. -> Rumus harus divalidasi
sebelum digunakan

o Data instrumen uji seperti data kalibrasi dan kualifikasi terintegrasi dengan oracle dan e-
PM.
o Terdapat manual input bila laporan data kalibrasi dan kualifikasi belum dimasukkan
kedalam sistem dengan catatan kalibrasi atau kualifikasi sudah selesai dilakukan,
sehingga instrumen dapat digunakan.
• Nomor MWQT akan mengikuti prosedur penomoran dokumen terkait, untuk value yang bersifat
statis (contoh: kode departemen) maka akan berupa LOV dan untuk nomor urut dan versi akan
tergenerate otomatis.
• Form MWQT tidak bisa diubah (locked), kecuali pada bagian isian harus diisi sesuai aktualnya.
• Tanggal efektif akan terinput oleh sistem ketika status MWQT berubah dari approved menjadi
efektif.
• Bila terdapat perubahan baik dari PA, spesifikasi atau MWQT maka nomor yang terevisi hanya
pada dokumen yang berubah.
• Tanggal review ulang akan terinput oleh sistem, tiga tahun setelah tanggal efektif.
• Notifikasi untuk review ulang akan dimunculkan oleh sistem 3 bulan sebelum tanggal jatuh
tempo review ulang. Bila MWQT tidak direview sampai masa berlaku habis/jatuh tempo maka
MWQT tidak dapat digunakan.
• Riwayat perubahan terdiri dari riwayat perubahan MWQT sebelumnya (tergenerate langsung)
dan berupa kolom isian untuk perubahan yang baru.
• Riwayat perubahan ini terintegrasi dengan e-Change control.
• Status pada MWQT adalah obsolete, approved, efektif dan in progress.
• MWQT dapat diubah dengan menu edit yang memiliki tombol auto save untuk menyimpan draft
MWQT dan memiliki status in progress. -> ini masih dalam bentuk draft sehingga tidak perlu cc
bu
• Pengisian WQT dilakukan dengan memilih icon (+) untuk satu parameternya.
• Multiple selection dapat menggunakan tick box
• Setting instrumen berupa list of value dan terdapat kolom option untuk menambah instrumen
yang dibutuhkan.
• MWQT dapat diprint dalam bentuk pdf yang terproteksi.
• MWQT dapat diduplikasi untuk digunakan lebih dari satu kode produk. -> benar bu yang
diduplikasi MWQT nya
• Nomor change control setelah input MWQT menjadi mandatory field.
• MWQT akan tergenerate bersamaan dengan penomoran bets pada e-Bets Records.
• MWQT dapat dieksekusi sesuai dengan tahapan proses produksi dan parameter uji.
• Terdapat pilihan apabila produk akan diuji secara campaign. mis.: dilakukan analisa produk x,
dari bn 01-10 (campaign), maka pada MWQT bagian aktual hanya diisi pada bets number 1
dengan mempertimbangkan jumlah reagen yang diperlukan untuk pengujian campaign. Untuk
aktual pada bn 2-10 diisi mengacu pada bn 01 dengan ketentuan jumlah penyediaan reagen yang
sama/mengacu pada bn 01. Jumlah reagen pada BN1 diisi dgn kebutuhan untuk 10 BN.
• Pembuatan versi dari MWQT

o Versi dari MWQT akan diatur oleh sistem.

o Setiap pembuatan atau perubahan pada MWQT akan mengupdate versi dari dokumen
elektronis tersebut dan menarik dokumen yang telah obsolete secara sistem.
o Versi terdiri dari 2-digit angka yang berada pada urutan terakhir dari penomoran
dokumen elektronis.
o Hanya akan ada satu dokumen MWQT yang aktif dan dapat digunakan
o Nomor MWQT akan saling terkait dengan spesifikasi dan PA yang digunakan
• Untuk kedepannya dimungkinkan pembuatan MWQT dari permintaan pengujian diluar aktivitas
normal (FPP)
• Perubahan yang terjadi pada MWQT akan berlaku pada worksheet yang akan tergenerate
berikutnya.
• Fitur “Version Control” Spec pada sistem Oracle diaktifkan.
1.2.7 APPROVAL
1.2.7.1 REQUEST FOR APPROVAL (REF ID : A.9, PG: 21)

• MWQT yang sudah dibuat akan di- save sebagai draft dan di posting untuk mendapatkan
persetujuan
• Dokumen elektronis MWQT dapat diubah dengan menu edit dan memiliki status in progress
(auto save).
• Dalam menu edit terdapat tombol save untuk menyimpan MWQT.
• Status pada existing MWQT akan berubah dari efektif menjadi obsolete ketika MWQT yang baru
bersatus efektif.
• Draft dokumen elektronis pengujian dapat diakses dengan login sistem e-Testing, menu MWQT,
pilih produk, RM-PM/kode produk, RM-PM/MWQT
• Selama bersatus in progress, MWQT belum dapat digunakan untuk pengujian.
• Proses perubahan diatas harus terekam di dalam audit trail.
• Bila akan lanjut ke proses kajian dan persetujuan dapat memilih menu posting.
• Terdapat informasi tanggal terakhir draft dibuat/diperbarui.
• Tanggal posting, nama personil, jabatan dan e-sign akan tergenerate pada MWQT sebagai
informasi awal data pembuat.
1.2.7.2 REVIEW & APPROVAL (REF ID : A.10, PG: 22-24)

• Proses kajian dan persetujuan dilakukan sesuai dengan responsibility masing-masing personnel
yang telah ditentukan.
• Proses kajian dan persetujuan dilakukan bersamaan untuk spesifikasi, prosedur analisis dan
MWQT
• Untuk yang mengkaji dan menyetujui MWQT dibuat master data grup dan bisa dipilih personil
yang melakukan kajian sesuai dengan grup yang sudah dibuat
• Kajian MWQT dilakukan secara paralel, jika sudah dikaji baru dapat lanjut ke proses persetujuan

• Notifikasi dan reminder untuk melakukan kajian dan persetujuan dilakukan oleh sistem secara
otomatis bila pengkaji / yang menyetujui personil QC, jika pengkaji / yang menyetujui dari
departemen lain, maka notifikasi akan dikirimkan melalui email.
• Tombol yang muncul pada menu reviewer dan approver adalah, approve, revise dan reject
dengan kolom komentar.
• Jika terdapat lebih dari 1 orang yang mengkaji, maka user baru bisa melakukan perbaikan apabila
sudah diberikan feedback dari semua pengkaji.
• Kajian proses dilakukan secara paralel. Setelah seluruh reviewer selesai mereview maka
dokumen akan kembali kepada requestor untuk direvisi.
• Terdapat user interface tersendiri untuk yang mengkaji dan menyetujui
• Jendela reviewer dan approver akan menampilkan daftar MWQT produk/RM/PM yang perlu
dikaji.
• Pilih produk /RM/PM yang terdapat pada jendela menu reviewer dan approver.
• Pilih menu review/approval in progress untuk menginformasikan proses sedang berjalan.
• Proses kajian dilakukan maksimal 2 hari kerja setelah menu review/approval in progress di pilih.
• Bila lebih dari 2 hari kerja untuk melakukan kajian maka pilih menu extend review/approval in
progress.
o Proses perpanjangan maksimal 2 hari kerja dihitung dari menu extend review/approval
in progress dipilih.
o Extend hanya dapat dilakukan 1 kali.
o Bila proses kajian belum juga selesai setelah perpanjangan maka kajian dokumen
elektronis pengujian produk / material akan otomatis naik kepada atasan reviewer yang
ditentukan.
• Terdapat fitur delegasi dalam menu review dan approval
• Jika dilakukan delegasi, semua task yang masih pending akan diberikan kepada personil yang
mendapat delegasi
• MWQT yang dibuat baru atau perubahan memiliki keterangan dan setiap field parameter yang
mengalami perubahan dapat diberi komentar.
• Terdapat field review /comment pada masing-masing field parameter MWQT.
• Dokumen elektronis MWQT hasil kajian yang harus diperbaiki akan kembali bersatus draft
dengan keterangan.
• Dokumen elektronis MWQT hasil kajian yang sudah disetujui akan bersatus approved
• Sistem tidak boleh mempunyai lebih dari satu MWQT yang berstatus efektif
• Hasil review dan persetujuan dari Draft dokumen elektronis worksheet QC testing
1.2.8 E-BATCH RECORDS (E-BR) E-DEVIASI (REF ID : B.1 –B.3, PG: 26-31)
• Proses penurunan (issuance) e-BR yang siap digunakan untuk proses produksi akan memberikan
informasi pada sistem e-Testing.
• Setiap perintah pengujian akan dimulai saat terjadinya pembuatan sampel di oracle
• Field uji dalam WQT akan terikat dengan setiap proses routing didalam e-BR
• Notifikasi dikirimkan sesuai dengan tahapan routing proses produksi

• e-Deviasi merupakan media bila terjadi ketidaksesuaian pada saat proses produksi, salah satu
aksinya adalah permintaan pengujian ulang pada sistem e-Testing
• e-BR memiliki step yang dapat digunakan untuk memberikan informasi pada sistem e-Testing
untuk dapat mengenerate WQT dari produk terkait.
• Generate WQT (FG)
o Penurunan WQT yang akan digunakan sebagai modul pengujian produk
o Hasil generate pertama kali setelah penurunan e-BR adalah template WQT secara utuh
untuk produk.
o WQT yang dikeluarkan akan menarik data nama produk, kode produk dan nomor bets
dari e-BR
o WQT yang dikeluarkan berasal dari database MWQT yang sudah dibuat pada modul 1
dan berstatus efektif.
o Field kosong pada kolom isian setiap parameter bersifat inaktif.
o WQT akan digenerate sejak e-BR digenerate, jika ada WQT terkait produk tersebut
efektif di tengah proses, maka proses akan tetap mengikuti WQT yang awal digenerate,
sampai proses produksi bets tersebut selesai.
o Jika e-BR dibatalkan maka WQT yang terbentuk akan secara otomatis dibatalkan.
o Sistem e-Testing akan melakukan validasi data no. sampel yang dikirim dari sistem
oracle. Ketika no. sampel yang baru ter-create, sistem e-Testing akan melakukan validasi
melalui no lot dan Spec yang dikirim ke e-Testing. Apabila sudah ada worksheet dengan
no lot tersebut, maka sistem e-Testing tidak mengenerate worksheet baru melainkan
menghubungkan no sampel yang baru ter-create kepada worksheet yang sudah aktif.
Perubahan ini hanya dapat dilakukan oleh user dengan responsibility “QC Supervisor”
dan “QC Manager”.
• Routing proses didalam e-BR
o Routing proses produksi akan terikat dengan setiap parameter uji pada WQT yang
diperlukan dari proses produksi tersebut.
o Routing proses produksi akan menjadi informasi awal untuk memberikan notifikasi
pengujian pada analis QC melalui sistem e-Testing.
o Routing proses produksi akan mengaktifkan field parameter uji pada WQT sesuai dengan
tahapannya.
• Notifikasi untuk melakukan pengujian
o Notifikasi berada didalam sistem e-Testing. Notifikasi terdiri dari pengujian rutin dan
pengujian permintaan.
o Notifikasi berisi nomor e-BR, nama produk, kode produk, nomor WQT, tanggal dan jam
permintaan pengujian dan dapat di-sort.
o Notifikasi untuk pengujian yang melibatkan penyiapan reagen/media yang dilakukan
personil QC akan dikirim ke dalam sistem e-Testing setelah e-BR aktif.
o Notifikasi pada poin c akan mengaktifkan field didalam WQT.
o Status List Register dapat berubah sesuai dengan tahapan atau progress dari aktivitas
pengujian.

o List Register setiap sampel yang masuk memiliki identitas produk, nomor bets,
parameter uji, nomor uji sampel, status pengujian, list reagen/media/perlengkapan
pengujian yang diperlukan, dashboard PIC dan keterangan jenis pengujian.
o List Register digunakan untuk membuka WQT
o Di dalam List Register, pengujian yang sudah ditunjuk PIC nya tidak dapat ditunjuk
kembali sebelum proses pengujian selesai/pengujian tersebut di suspend/dibatalkan.
• Permintaan pengujian tambahan
o Untuk pengujian tambahan melalui jalur deviasi dan jika parameter uji diluar spesifikasi
maka akan membuat spek/PA/ WQT
o FPP (Formulir Permintaan Pemeriksaan) dibuat jika ada Reproses produksi, deviasi,
permintaan TS, permintaan QA. Ruang lingkup fase ini hanya mengakomodir proses FPP
yang muncul dari reproses produksi. Untuk proses FPP dari proses non-rutin (validasi,
pilot, proses robustness, Transfer prosedur analisis, keluhan pelanggan) akan dikerjakan
pada scope project berikutnya.
o Aktivitas ini akan terintegrasi dengan proses di produksi yang menggunakan e-BR.
o Saat memerlukan WQT baru, misalnya untuk reproses produksi, maka akan terintegrasi
kembali dengan e-BR.
o Untuk permintaan pengujian tambahan user akan menginput data permintaan
pengujian ke dalam portal menu FPP di e-Testing. Permintaan tersebut dilakukan oleh
TS Supervisor/Manager, QA Supervisor/Manager, dan Production Supervisor/Manager.
o Input data terkait nama produk, kode produk, nomor bets, nomor laporan deviasi, data
pengujian tambahan (penambahan jumlah sampel pada satu atau beberapa parameter
uji/penambahan parameter uji baru).
o Terdapat kolom untuk mengatur jumlah sampel yang perlu dikirimkan sebagai sampel
tambahan untuk pengujian yang diminta pada FPP. Jumlah sampel yang sudah di-entry
akan dikirimkan e-BR sebagai trigger pengiriman sampel tersebut ketika FPP sudah
disetujui.
o Jika FPP tidak menggunakan WQT baru maka no sampel oracle akan menggunakan no
sampel yang sama. Pada worksheet akan terdapat kolom tambahan untuk pengujian
yang diminta.
o FPP akan dikaji dan disetujui oleh requestor dan QC manager
o Bila diperlukan penambahan parameter uji baru maka perlu pembuatan item sampel
baru didalam oracle dimana item sampel, spesifikasi, PA , WQT akan memiliki kode unik
yang terintegrasi dengan kode unik baru di dalam e-BR
o Proses pembuatan spesifikasi, PA dan MWQT sesuai dengan modul A
o Bila FPP hanya memerlukan penambahan sampel uji maka item sampel masih
menggunakan item sampel yang terbentuk sebelumnya, hanya saja di dalam WQT pada
routing proses terkait akan aktif menu penambahan sampel uji
o Nomor deviasi terkait dengan penambahan pengujian akan tercatat didalam WQT
terkait
o Akan terdapat 2 spesifikasi untuk 1 produk (jika mengalami deviasi atau butuh uji
tambahan), namun dengan penomoran yang berbeda

1.2.9 WQT AKTIF (REF ID : B.4 – B.5, PG: 31-32)

• WQT akan aktif per parameter/field pengujian, sesuai dengan routing dalam proses produksi
• WQT yang aktif akan terlihat pada dashboard (penjelasan mengacu pada A.5)
• WQT dapat diisi setelah ditunjuk PIC dan diakses melalui dashboard atau notifikasi.
• Penunjukan PIC pada WQT dapat dilakukan oleh QC supervisor. Bila berhalangan dapat
didelegasikan kepada QC manager.
• Bila pengujian belum terselesaikan, penunjukan PIC dapat dilakukan ulang/diserah terimakan
kepada analis lain dengan memberi keterangan status pengujian pada kolom keterangan.
• WQT yang aktif ditandai dengan field parameter hasil pengujian yang dapat diisi.
• Field parameter uji yang sudah di-assign tidak dapat dilakukan oleh personel lain secara
bersamaan.
• Parameter pengujian hanya bisa di input oleh satu PIC, tetapi untuk analisa dapat dilakukan oleh
> 1 PIC
• Field parameter pengujian bersifat mandatory.
• Field parameter yang sudah terisi sesuai tahapan routing-nya tidak dapat diinput/diubah kembali
bila sudah menekan tombol “next”, setelah di submit untuk dikaji per parameter oleh SPV.
1.2.10 PENGUJIAN SAMPLE (REF ID : B.6 – B.7, PG: 32-33)

• Personil produksi melakukan pengujian sampel dan memasukkan hasil pemeriksaan dalam e-BR
• Parameter pengujian selama proses produksi pada e-BR akan terintegrasi dengan WQT.
• Personil produksi melakukan pengujian selama proses sesuai dengan routing proses produksi
pada e-BR.
• Input data hasil pengujian selama proses dapat dilakukan otomatis melalui integrasi instrumen
uji dengan sistem e-BR atau dengan meng-input manual hasil uji kedalam e-BR dengan
melampirkan hardcopy sebagai bukti pendukung, kemudian di tanda tangani dengan
membubuhkan e-sign (di dalam e-BR).
• Kesimpulan dari hasil pengujian akan langsung pada WQT sesuai dengan spesifikasi pengujian
pada masing-masing parameter.
• Bila hasil pengujian dan tren analisis memenuhi persyaratan, sistem mendisposisi perubahan
status sampel dari “pending
• menjadi “complete” dan memberikan notifikasi yang menyatakan bahwa nomor bets produk
tersebut dengan nomor WQT terkait sesuai dengan persyaratan dan tren, sehingga proses
produksi berikutnya dapat dilanjutkan.
• Bila hasil pengujian memenuhi persyaratan tetapi tidak sesuai dengan tren maka muncul
informasi khusus pada sistem e-testing untuk mendisposisikan sampel dan meneruskannya
kedalam modul OOS/OOT agar proses produksi berikutnya dapat dilanjutkan.
• Bila hasil pengujian diluar spesifikasi, muncul sign khusus yang menandakan hal tersebut untuk
ditindaklanjuti dalam e-deviation. Notifikasi akan muncul per parameter uji yang tidak
memenuhi persyaratan.
• Data hasil pengujian dalam database dapat terintegrasi dengan disposisi bets dan pembuatan
sertifikat hasil analisa (CoA) pada Oracle.

• Data Hasil IPC ditampung di e-Testing.

• Hasil pengujian selama proses ter-input ke dalam e-BR dan WQT.
1.2.11 PENGAMBILAN SAMPLE (REF ID : B.8 – B.10, PG: 33-34)

• Pengambilan sampel oleh personil yang ditunjuk dan personil QC melakukan pengujian sampel
• Personil yang ditunjuk akan mengambil sampel untuk diuji oleh QC
• Data sampel yang diambil akan terinput didalam e-BR
• Personil QC akan melakukan pengujian sampel dan menginput data hasil pengujian kedalam
WQT
• Personil yang ditunjuk melakukan pengambilan sampel untuk dilakukan pengujian oleh QC.
• Personil yang ditunjuk meng-input jumlah sampel yang diambil didalam e-BR.
• Label sampel berisi minimal nama & kode produk, nomor bets, routing produksi, nomor lot,
urutan dan jumlah sampel (Parameter), tanggal pembuatan & pengambilan sampel serta
identitas personil yang ditunjuk. Label sampel berasal dari Oracle/e-Testing. Informasi jumlah
sampel yang diperlukan akan dikirimkan ke eBR berdasarkan “Daftar Pengambilan Sampel”
(pada PA)
• Penerimaan sampel di-input secara manual kedalam sistem e-Testing.
• Input data hasil pengujian dilakukan secara manual ke dalam WQT dan di tanda tangani dengan
membubuhkan e-sign oleh analis QC, data hardcopy harus dilampirkan sebagai bukti pendukung.
Dimungkinkan didalam development selanjutnya untuk dapat terintegrasi secara otomatis
dengan mesin/instrumen
• Terdapat menu untuk memfasilitasi bila ada pengujian yang memerlukan jasa vendor/pihak
ketiga/ kontrak analisis.
• Hasil pengujian selama proses terinput dalam e-BR dan WQT
1.2.12 DASHBOARD PIC (REF ID : B.11 – B.15, PG: 34-40)

• Pada halaman ini PIC akan mendapat notifikasi dan melakukan pengecekan data hasil
pemeriksaan
• Dashboard PIC untuk melakukan pengajian
• Notifikasi pada e-Testing dari supervisor QC untuk mendisposisikan hasil pengujian
• Pengecekan data hasil pengujian
• Kesimpulan hasil pengujian akan muncul langsung pada WQT sesuai dengan spesifikasi pada
masing-masing parameter pengujian.
• Bila hasil diluar spesifikasi, akan muncul sign khusus yang menandakan hal tersebut didalam
WQT.
• Bila hasil pengujian memenuhi persyaratan dan tren analisis, disposisi perubahan status sampel
dari “pending” menjadi “complete” akan diatur sistem dan memberikan notifikasi dengan
informasi yang menyatakan nomor bets dengan nomor WQT sesuai dengan persyaratan dan
tren, sehingga proses produksi berikutnya dapat dilanjutkan.

• Sebaliknya dari point 9. Bila hasil uji memenuhi persyaratan tetapi tidak sesuai dengan tren maka
terdapat informasi khusus pada sistem e-Testing untuk mendisposisikan sampel dan
meneruskannya kedalam modul OOS/OOT agar proses produksi berikutnya dapat dilanjutkan.
• Bila hasil diluar spesifikasi maka akan terdapat sign khusus yang menandakan hal tersebut sudah
ditindaklanjuti dalam modul OOS/OOT. Notifikasi akan muncul per parameter uji yang tidak
• Dashboard PIC dilakukan oleh supervisor kepada setiap analisis
• 1 WQT dapat di-assign kepada lebih dari 1 analis dan 1 analis dapat di-assign untuk mengerjakan
lebih dari 1 worksheet.
• Jobdesc yang sudah di-assign pada analis terkait hanya akan muncul pada dashboard analis
tersebut.
• Jika pada saat shift berakhir worksheet yang di-assign pada analis terkait belum selesai, maka
Supervisor dapat meng-assign analis tambahan untuk melanjutkan worksheet tersebut.
Diperlukan button untuk mengganti atau menambah analis.
• Notifikasi terdiri dari nomor bets, nama produk, kode produk/RM/PM, nomor WQT, parameter
pengujian, tanggal dan jam permintaan/penyelesaian pengujian dan dapat di-sort.
• Kajian WQT
o Supervisor QC melakukan kajian untuk hasil WQT melalui fitur e-sign.
o Kajian WQT dapat dilakukan secara keseluruhan melalui fitur “review by exception”.
o Setiap WQT yang sudah ter-input akan memberikan notifikasi kepada supervisor QC
untuk dikaji.
o Kajian CHP dilakukan saat keseluruhan parameter pengujian sudah berstatus complete.
o Supervisor QC akan mendapatkan notifikasi CHP melalui sistem dan melakukan kajian
per parameter. Setelah keseluruhan parameter selesai dikaji, QC
• Supervisor akan mengirimkan CHP yang telah dikaji ke QC manager melalui tombol “Send”
o Manager QC akan mendapatkan notifikasi, dan melakukan persetujuan akhir CHP.
o Data-data dari CHP yang sudah dikaji secara sistem akan ter-input ke dalam database
dan dikirim ke sistem oracle.
o Status sampel pada sistem oracle yang telah memenuhi spesifikasi akan menjadi
“Complete” dan dilakukan disposisi pada sistem oracle sesuai dengan ketentuan di
oracle.
o Status disposisi sampel di oracle akan mengupdate status worksheet pada e-Testing.
Data worksheet yang telah dilakukan disposisi akan dikunci dan tidak dapat dilakukan
edit.
o Semua Spv QC dibuat menjadi 1 grup agar semua spv bisa mendapat notifikasi terkait
dashboard PIC analis
o Bila terdapat kesalahan penginputan data di dalam WQT maka WQT dapat diperbaiki
atas otorisasi QC supervisor/manager. Diperlukan input data alasan mengapa data
tersebut diubah.
• Bila kesalahan input (tanpa pengujian ulang) terjadi saat Hasil Analisa sudah ditransfer di dalam
oracle namun sebelum dilakukan disposisi,
o Hasil analisa yang telah dikirim ke oracle perlu di-unapproved dan parameter yang perlu
direvisi diberi tanda di dalam e-Testing oleh QC Manager dan status parameter
pengujian serta worksheet kembali menjadi “In Progress”. Parameter pengujian dengan
status “In Progress” dapat diedit oleh QC analis dan QC Supervisor.
o Parameter pengujian dapat direvisi dengan memasukkan alasan dilakukannya revisi dan
akan melalui workflow yang sama dengan submit parameter awal.
o Alasan yang di-entry oleh QC analis/supervisor saat merevisi parameter pengujian pada
worksheet akan dikirim ke sistem oracle untuk disimpan dalam kolom DFF Reason.
o Bila kesalahan input (tanpa pengujian ulang) terjadi saat Hasil Analisa sudah ditransfer
di dalam oracle dan sudah dilakukan disposisi, maka:
• Hasil analisa yang telah didisposisi perlu dibatalkan di dalam oracle.
o Diperlukan pembuatan sampel baru di dalam oracle.
o Pembuatan sampel baru ini akan mengenerate WQT terkait (sesuai tahapan routing
proses sampel)
o Penginputan hasil analisa ke dalam WQT yang baru tergenerate dapat dilakukan dengan
cara meng-copy hasil analisa dari WQT original. Aktivitas copy harus disertai dengan
alasan.
o Ketika dilakukan aktivitas copy, fitur pemakaian reagen/instrumen tidak dijalankan.
o Aktivitas copy dapat dilakukan oleh user dengan responsibility QC Supervisor atau
Manager yang ditunjuk. Setelah semua parameter pengujian terisi dan dikaji oleh user,
kemudian disubmit untuk masuk kedalam tahapan kajian dan persetujuan.
o WQT yang telah disetujui akan dikirimkan ke oracle dan dilakukan disposisi sesuai
dengan ketentuan oracle.
• WQT & hasil analisa perbaikan ini akan menjadi bagian tambahan dokumen elektronik dari WQT
dan hasil analisa induk didalam sistem e-Testing.
1.2.13 HASIL ANALISIS DAN TREND ANALISIS (REF ID : B.16 – B.17, PG: 40-41)
• Pada halaman ini user dapat melihat hasil analisis dan trend, sampel memiliki 4 status yaitu
o Pending
o In progress
o Complete
o Accept
• Default status sampel adalah pending. Status ini akan berubah menjadi “in progress” bila sampel
tidak memenuhi spesifikasi atau “complete” bila sampel memenuhi spesifikasi.
• Bila terdapat pengujian yang tidak memenuhi spesifikasi maka sistem akan memberikan
notifikasi seperti pada poin B.14 dan B.15 no. 5.
• Parameter tidak memenuhi spesifikasi/tren akan diteruskan secara sistem ke dalam fitur Out of
Specification (OOS)/ Out of Trend (OOT) per parameter uji. Bila terjadi pada saat pemeriksaan
selama proses, pengujian kimia-fisika dan atau mikrobiologi maka akan terdapat pop up pada e-
BR atau WQT untuk diteruskan ke dalam menu OOS/OOT/deviasi pada sistem e-Testing.
• CHP dapat di generate dalam bentuk pdf terproteksi.
• Generate CHP dapat dilakukan oleh QC supervisor atau manager untuk dikaji dan disetujui

• Trend analisa dapat ditampilkan dalam bentuk grafik didalam dashboard. Trend analisa dapat
difilter sesuai dengan parameter uji.
• Setelah hasil analisa tahap kemas disetujui oleh QC manager, sistem mengirimkan notifikasi
kepada tim QA melalui email.
1.2.14 OOS/OOT (REF ID : C.2, PG: 43-44)

• Pada halaman ini menangani proses penanganan OOS/OOT
• Pada halaman ini ditampilkan Berupa dashboard dan register list OOS/OOT yang terjadi berikut
dengan statusnya.
• Realtime graphic dari setiap data OOS/OOT yang terjadi tersaji dalam dashboard utama dan
dapat di sort.
• List Register OOS/OOT terdiri dari tanggal, bulan , tahun dan jam kejadian, nomor pelaporan
OOS/OOT, kode produk/material, nama produk/material, no bets produk / material / kondisi
stabilita, parameter pengujian yang mengalami OOS/OOT, hasil pengujian parameter yang
OOS/OOT, syarat penerimaan parameter pengujian, dan status OOS/OOT.
• Bila OOS dan OOT terjadi terdapat informasi pada e-BR/WQT berupa pop up untuk dilanjutkan
ke dalam fitur OOS/OOT. Jika OOT terjadi pada IPC maka tetap dilakukan pengujian ulang sama
seperti OOS, namun perbedaan OOS dari OOT adalah pada OOT produksi tetap dapat
melanjutkan proses produksi. Justifikasi terhadap proses produksi dilakukan diluar sistem.
1.2.14.1 PEMILIHAN JENIS PENYIMPANGAN (REF ID : C.3, PG: 44)

• Untuk mengakses halaman ini user harus masuk ke menu pelaporan OOS/OOT
• Jenis penyimpangan dapat terdiri dari kimia, fisika dan mikrobiologi
• Jenis pelaporan OOS/OOT terdiri dari kimia, fisika dan mikrobiologi.
• Berupa tik box dalam pemilihan jenis penyimpangannya.
• Tik box hanya dapat dipilih salah satu dalam membuat laporan OOS/OOT.
• Tik box ini muncul pada pop up saat OOS/OOT terjadi pada salah satu parameter saat
pemeriksaan sampel.
• Terdapat tombol untuk membuat laporan penyimpangan pada pop up tersebut.
• Pop up akan hilang apabila laporan penyimpangan sudah dibuat.
1.2.14.2 E-FORM PELAPORAN OOS/OOT (REF ID : C.4 – C.9, PG: 45-46)

• Pelaporan OOS/OOT dapat dibuat dalam e-form yang muncul saat tombol laporan
penyimpangan pada pop up dipilih
• e-form OOS/OOT terdiri dari nomor pelaporan OOS/OOT, kode produk/material, nama
produk/material, no. Bets produk / material / kondisi stabilita, tanggal penerimaan sampel,
tanggal terjadinya penyimpangan, tanggal pelaporan penyimpangan, parameter uji yang
mengalami OOS/OOT, hasil pengujian parameter yang OOS/OOT, syarat penerimaan
parameter uji, rincian tindakan sementara yang diambil, identifikasi pelapor & penanggung
jawab terkait, evaluasi terhadap laporan & tindakan, dan field persetujuan oleh manager QA dan
QC.

• Nomor OOS dibedakan berdasarkan OOS kimia, fisika dan mikrobiologi

• Field parameter yang berupa data statis (no. Bets produk / material / kondisi stabilita, nomor
pelaporan OOS/OOT, nama produk/material, kode produk/material, tanggal terjadinya
penyimpangan dapat mengambil informasi worksheet pada e-Testing sedangkan data dinamis
(tanggal penerimaan sampel, tanggal pelaporan penyimpangan, rincian penyimpangan yang
terjadi, rincian tindakan sementara yang diambil, identifikasi pelapor & penanggung jawab
terkait, evaluasi terhadap laporan & tindakan, dan field persetujuan oleh manager QA dan QC)
berupa isian.
• Proses pembuatan, kajian dan persetujuan dilakukan dengan menginput e-sign.
• Terdapat fitur notifikasi
1.2.14.3 E-FORM INVESTIGASI (REF ID : C.10 – C.16, PG: 46-48)

• Setelah pelaporan OOS/OOT disetujui maka lakukan investigasi dengan urutan seperti pada alur
proses diatas (f)
• e-form investigasi terdiri dari 3 tahapan yaitu investigasi Ia, Ib, dan II.
• Setiap pertanyaan pada form investigasi harus di selesaikan sebelum melenjutkan ketahapan
selanjutnya untuk menghindari ditemukan masalah lainnya dari form tersebut
• e-form investigasi Ia. berisi nomor pelaporan OOS/OOT, nama produk/material, kode
produk/material, nomor bets produk / material / kondisi stabilita, rincian penyimpangan yang
terjadi, tahapan investigasi, PIC pelaporan penyimpangan, kesimpulan, keputusan, dan evaluasi
oleh supervisor QC.
• Untuk lingkup SFG, field parameter yang berupa data statis (nomor bets produk, nomor
pelaporan OOS/OOT, nama produk, kode produk) dapat terintegrasi dengan e-BR dan
worksheet pada e-Testing sedangkan data dinamis (rincian penyimpangan yang terjadi, tahapan
investigasi, PIC pelaporan penyimpangan,kesimpulan, keputusan, dan field evaluasi oleh
supervisor QC) berupa isian.
• Field hasil pemeriksaan dibuat dalam bentuk list of value (LOV)
• Field berupa mandatory dan harus diinput secara berurutan
• Proses melakukan analisa dan evaluasi dilakukan dengan menginput e-sign.
• Tidak diperlukan tik box untuk memilih investigasi lanjutan.
• Fitur parameter investigasi pada e-form investigasi Ib mengikuti poin 4-8. Pada beberapa
parameter investigasi bila dimungkinkan dapat terintegrasi dengan sistem/fitur lainnya.
• Bila diperlukan investigasi lanjutan, perlu pertanyaan apakah investigasi perlu dilanjutkan ke
tahap II (Dijawab oleh QC Mgr).
• Pada e-form investigasi lanjutan, tahap II, diperlukan kajian dan persetujuan dari QC & QA
manager. Form ini akan menentukan apakah diperlukan pengambilan sampel tambahan.
• Bila pada investigasi lanjutan, tahap II, belum ditemukan kesalahan maka sistem akan
melanjutkan kedalam sistem e-Deviasi.
• Pada tahapan investigasi II, jika diperlukan pengambilan sampel baru.
• Proses pengambilan sampel baru akan dilakukan dengan dua kondisi, bila masih dalam tahap
proses produksi maka terdapat fitur permintaan sampel tambahan ke e-BR. -> sudah masuk
investigasi tahap 2 sehingga memerlukan sampel baru

• Bila produk jadi sudah berada didalam Gudang, maka pengambilan sampel akan melalui proses
FKB.
• Bila investigasi sudah ditemukan akar permasalahannya maka perbaikan dapat dilakukan pada
menu “perbaikan” didalam fitur OOS/OOT ini.
• Pada saat terjadi OOS/OOT sistem akan mengirimkan notifikasi kedalam e-BR dan WQT.
Notifikasi ini akan dijadikan informasi bahwa telah terjadi OOS pada bets tersebut, sehingga
data laporan OOS/OOT diperlukan untuk dikirimkan ke e-BR
• Investigasi OOS/OOT II dapat dilakukan berulang dengan melakukan pengujian ulang dengan
tombol konfirmasi, jika pada OOS/OOT tahap II sebelumnya hasil pengujian ulang masih tidak
memenuhi syarat.
• Form Investigasi ini akan tergenerate menjadi satu kesatuan pada saat laporan dari WQT dan e-
BR disposisi untuk perilisan.
• Status OOS/OOT akan tetap open hingga 1 cycle OOS/ OOT selesai dilakukan. Status OOS/OOT
closed ketika masuk ke deviasi.
• Terdapat kolom untuk melampirkan data pendukung berupa attachments dan kolom summary
hasil investigasi untuk setiap tahapan investigasi.
1.2.15 PENGUJIAN ULANG
1.2.15.1 DASHBOARD PENGUJIAN ULANG/RETESTING (REF ID : D.2, PG: 52)

• Pada halaman ini informasi di tampilkan berupa dashboard material yang perlu di-retest beserta
statusnya.
• Realtime graphic terdiri dari nama dan kode material, serta countdown hari material awal
(RM/PM) yang harus diuji ulang
1.2.15.2 LIST MATERIAL (REF ID : D.3, PG: 52)

• Pada halaman ini data di tampilkan berupa List Register material yang harus diuji ulang
• List Register material berisi nomor bets atau kode RM/PM, nama RM/PM, manufaktur, expired
date, shelf life, retest date, best before dari RM/PM, tanggal diperlukan uji ulang/masa berlaku
RM/PM setelah perpanjangan, Informasi awal yang terintegrasi dari Oracle untuk mengupdate
material baru dan perubahan (terdiri dari List Material, tanggal ED, Best Before, Shelf Life atau
retest date). List ini dapat disort untuk memudahkan pemantauan dapat melalui ED, Best before,
atau shelf life.
• List Register digunakan untuk membuka WQT
1.2.15.3 NOTIFIKASI (REF ID D.4, PG: 52-53)

• Notifikasi di sini adalah notifikasi terkait pengujian ulang
• Notifikasi berasal dari Oracle (FPP) dan reminder dari perhitungan retest date dari sistem
• Notifikasi berisi nomor bets atau kode RM/PM, nama RM/PM, manufaktur, expired date, shelf
life, retest date, best before dari RM/PM, tanggal diperlukan uji ulang/retest date RM/PM setelah
perpanjangan.
• Notifikasi dapat dipilih/digolongkan berdasarkan point no.1.

• Notifikasi akan berada didalam sistem e-Testing.

• Notifikasi pengujian dapat ditutup dengan mengubah proses terkait notifikasi tersebut di dalam
List Register material.
• Notifikasi pengujian ulang akan muncul 3 bulan sebelum jatuh tempo retest date. -> ini hanya
notifikasi saja bu, jika bahan awal masih dalam masa shelf life, walaupun sedang dilakukan
pemeriksaan maka bahan awal masih dapat digunakan (dengan syarat belum melewati jatuh
tempo tanggal pengujian ulang)
1.2.15.4 PEMILIHAN MATERIAL (REF ID : D.5, PG: 53)

• Pada halaman ini terkait pemilihan material yang akan diuji ulang
• Proses pemilihan material dari List Register
• Pilih material yang akan diuji ulang dengan mengklik materialnya
• Tentukan PIC yang akan melakukan pengujian ulang
• Di dalam List Register, pengujian yang sudah di assign PICnya tidak dapat di assign kembali
sebelum proses pengujian selesai.
1.2.15.5 GENERATE WQT (RM/PM) (REF ID : D.7, PG: 53-54)

• WQT akan tergenerate sesuai parameter yang dipilih saat pembuatan FPP oleh user
• WQT muncul setelah dashboard PIC.
• PIC untuk WQT dapat lebih dari satu.
• WQT yang aktif akan ditandai dengan field parameter hasil pengujian yang dapat diinput/diisi.
• Pada WQT, PIC harus meng- assign kembali field parameter pengujian yang akan dilakukan.
lebih dari 1 worksheet. Perubahan dashboard PIC hanya dapat dilakukan di level supervisor dan
manager.
• Jobdesc yang sudah di-assign pada analis tertentu hanya akan muncul pada dashboard analis
tersebut.
• Field parameter pengujian tersebut bersifat mandatory.
• Field parameter yang sudah terisi tidak dapat diinput/diubah kembali bila sudah menekan
tombol “next”. Perubahan isi field parameter hanya dapat dilakukan di level supervisor dan
manager.
1.2.15.6 PENGAMBILAN SAMPLE (REF ID : D.8 – D.10, PG: 54-55)

• Pengambilan sampel, melakukan pengujian ulang dan input data hasil pengujian
• Pada saat dilakukan pengujian ulang, status pada material akan menjadi “karantina uji ulang”.
• Status seperti disebutkan pada nomor 1, akan memotong stok material pada oracle sehingga
material yang sedang diuji ulang tidak dapat digunakan.
• Untuk material yang hanya memiliki expired date, maka status material akan berubah menjadi
“rejected” paling lambat 1 hari sebelum jatuh tempo ED.
• Perubahan status ini akan terlihat pada List Register.
• Pemotongan stok secara sistem yang terintegrasi dengan oracle untuk material ED
1.2.15.7 PROSES PERPANJANGAN TANGGAL PENGUJIAN ULANG DAN DISPOSISI STATUS

MATERIAL (REF ID : D.11 – D.13, PG: 55-56)
• WQT harus melalui proses kajian dan persetujuan untuk pendisposisian hasil pengujian ulang.
• Jika hasil pengujian ulang memenuhi spesifikasi, Status material akan berubah dari “karantina uji
ulang” menjadi “release”. Status ini harus memiliki pembeda dengan release material saat
pertama kali diterima.
• Material yang tidak sesuai dengan spesifikasi maka akan bersatus “rejected”.
• Material yang di-reject akan di disposisikan di dalam Oracle
• Perpanjangan tanggal pengujian ulang dilakukan melalui sistem Oracle.
• Hasil pengujian ulang dan raw data dapat diprint menjadi laporan dalam bentuk PDF yang
terenkripsi, lalu akan dikirim kedalam main database dan Oracle.
• Proses pembuatan laporan hanya dapat dilakukan oleh supervisor yang ditunjuk.
• Terdapat menu “accept with variance” pada saat disposisi, jika hasil analisa tidak memenuhi
spesifikasi setelah melalui proses investigasi OOS/OOT dan deviasi.
• “Accept with variance” hanya dapat dilakukan oleh QC manager.
• Untuk material yang berstatus “release” maka secara otomatis akan menambah stok didalam
oracle, sehingga dapat digunakan kembali untuk proses produksi.
• Point nomor 8-10 dilakukan di dalam sistem Oracle
1.2.16 PENGUJIAN BAHAN AWAL
1.2.16.1 KEDATANGAN RM/PM DAN PEMASTIAN COA (REF ID : E.1, PG: 59)
• Penerimaan RM/PM dilakukan diluar sistem ini (Oracle)
• Pemeriksaan fisik CoA dilakukan oleh analis di luar sistem (offline)
• Penerimaan RM/PM akan mengikuti alur pada sistem Oracle/sistem warehouse yang berlaku.
• Pemastian CoA dari RM/PM meliputi nomor CoA, nama RM/PM, kode material, dan ketentuan
lainnya yang ditetapkan.
• Arsipkan dokumen hardcopy dari CoA sesuai dengan prosedur penanganan dokumen
1.2.16.2 NOTIFIKASI (REF ID : E.2, PG: 59)

• Notifikasi dikirimkan setelah RM/PM diproses pada sistem Oracle
• Notifikasi pada modul ini terjadi ketika kedatangan RM/PM telah diproses melalui sistem Oracle
tahapan “Register Delivery Material” yang mengubah status material pada Oracle manjadi
“planned” dan adanya permintaan sampling.
• Notifikasi ini berisi list permintaan pengujian terhadap RM/PM yang datang dan sampel sudah
siap untuk diuji.
• Notifikasi berisi identitas RM/PM meliputi nomor bets, kode material, nama material,
manufaktur, nomor bets manufaktur, expired date, shelf life, retest date, best before, assigned
PIC atau sesuai dengan data yang di-input dari Oracle.

• Notifikasi yang dipilih berdasarkan point no.2. berupa list permintaan uji RM/PM
• Notifikasi akan berada didalam sistem e-Testing.
• Notifikasi pengujian dapat di tutup dengan mengubah proses terkait notifikasi tersebut di dalam
List Register material. Detail ketentuan merujuk ke Modul 2, nomor B1-3 poin 4.
1.2.16.3 DASHBOARD (REF ID : E.4, PG: 60)

• Berupa dashboard material yang perlu diuji beserta statusnya.
• Realtime graphic berisi jumlah RM/PM yang perlu diuji, status material uji (release/pending/in
progess). Status ini akan digenerate dari Oracle
1.2.16.4 LIST MATERIAL (REF ID : E.5, PG: 61)

• Berupa List Register material RM/PM yang akan diuji
• List Register material akan terdiri dari identitas RM/PM meliputi nomor sampel lab QC, nomor
QC oracle, kode material, nama material, manufaktur, bets manufaktur, expired date, shelf life,
retest date, best before, dashboard PIC, tanggal dan waktu penerimaan. List ini dapat disort
untuk mempermudah pemantauan.
• List Register akan terupdate bila terdapat RM/PM yang diinput ke dalam Oracle.
• List Register digunakan untuk membuka WQT
1.2.16.5 PILIH MATERIAL YANG AKAN DIUJI (REF ID : E.6 – E.7, PG: 61)
• Proses pemilihan material dari List Register & dashboard PIC pengujian
• Pilih material yang akan diuji dengan meng-klik material pada List Register RM/PM
• Tentukan PIC / analis yang akan melakukan pengujian.
• Di dalam List Register, pengujian yang sudah di-assign PIC nya, tidak dapat di assign ulang
sebelum proses pengujian selesai/pengujian tersebut di- suspend.
1.2.16.6 GENERATE WORKSHEET QC TESTING (REF ID : E.8, PG: 61-62)

• Worksheet QC testing akan aktif sesuai dengan RM/PM yang akan diuji
• WQT muncul setelah dashboard PIC.
• PIC untuk WQT dapat lebih dari satu.
• WQT yang aktif akan ditandai dengan field parameter hasil pengujian yang dapat diinput/diisi.
• Pada WQT, PIC harus meng- assign kembali field parameter pengujian yang akan dilakukan.
lebih dari 1 worksheet. Perubahan dashboard PIC hanya dapat dilakukan di level supervisor dan
manager.
tersebut.


• Field parameter yang sudah terisi tidak dapat diinput/diubah kembali bila sudah menekan
tombol “next”. Perubahan isi field parameter hanya dapat dilakukan di level supervisor dan
manager.
1.2.16.7 PENGAMBILAN SAMPEL PENGUJIAN, PENGUJIAN, DAN INPUT DATA HASIL

PENGUJIAN RM/PM (REF ID : E.9 – E.11, PG: 62-64)
• Pengambilan sampel pengujian dilakukan oleh analis.
• Sampel pengujian akan diberi label pengujian sebagai penandaan.
• Pengujian RM/PM
• Rekap data hasil pengujian RM/PM
• Personil yang ditunjuk melakukan pengambilan sampel untuk dilakukan pengujian.
• Pilih generate label sampel. Pop-up label sampel akan muncul.
• Label sampel berupa 2D barcode yang berisi kode material, nama material, nomor bets material,
nomor bets manufaktur, jumlah sampel, tanggal pengambilan sampel dan identitas personil
yang ditunjuk.
• Pada saat dilakukan pengujian, status pada material berubah menjadi “karantina”. Status
material ini berada di dalam oracle
• Dengan perubahan status menjadi “karantina”, akan terjadi pemotongan stok material di oracle
sehingga material yang sedang diuji tidak dapat digunakan.
• Perubahan status ini akan terlihat pada List Register.
• Pemotongan stok secara sistem yang terintegrasi dengan oracle.
• Input data hasil pengujian dilakukan otomatis melalui integrasi instrument uji atau dengan
meng-input manual hasil pengujian ke dalam WQT serta di tanda tangani dengan membubuhkan
e-sign oleh analis QC, data hardcopy harus dilampirkan sebagai bukti pendukung.
• Kesimpulan dari hasil pengujian akan muncul langsung pada WQT sesuai dengan spesifkasi
pengujian pada masing-masing parameter.
• Bila hasil diluar spesifikasi maka akan terdapat sign khusus yang menandakan hal tersebut
didalam WQT.
• Bila hasil dari pengujian memenuhi persyaratan dan tren analisis maka disposisi perubahan
status sampel dari “pending” menjadi “complete” akan diatur sistem dan memberikan notifikasi
dengan informasi yang menyatakan nomor QC material dengan nomor WQT c sesuai dengan
persyaratan dan tren.
• Sebaliknya dari point 11. Bila hasil uji memenuhi persyaratan tetapi tidak sesuai dengan tren
maka terdapat informasi khusus pada sistem e-testing untuk mendisposisikan sampel dan
meneruskannya kedalam modul OOS/OOT untuk ditindak lanjuti. Material dapat digunakan
untuk proses produksi.

• Bila hasil diluar spesifikasi dan sudah dikonfirmasi bahwa terdapat defect pada material maka
akan terdapat sign khusus yang menandakan hal tersebut sudah ditindaklanjuti dalam disposisi
produk untuk “reject” untuk ditahapan ATB (Alasan Tolak Barang) material.
• Data hasil analisa dalam database dapat terintegrasi dengan disposisi dan pembuatan sertifikat
hasil analisa (CoA) pada Oracle.
• Terdapat menu untuk memfasilitasi bila ada pengujian yang memerlukan jasa vendor/pihak
ketiga/toll out analisa
1.2.16.8 DISPOSISI STATUS MATERIAL (REF ID : E.12, PG: 64-66)

• Disposisi dilakukan di dalam Oracle
• Perubahan status material pada sistem e-Testing dan Oracle
• Pendisposisian hasil pengujian pada WQT harus melalui proses kajian dan persetujuan .
• Supervisor QC melakukan kajian hasil WQT melalui fitur e-sign.
• Kajian WQT dilakukan secara keseluruhan melalui fitur “review by exception”.
• Kajian WQT dilakukan saat keseluruhan parameter pengajuan sudah berstatus complete.
• Supervisor QC dan Manager QC akan mendapatkan notifikasi untuk mengkaji hasil pengujian
melalui sistem e-Testing.
• Persetujuan WQT dilakukan oleh Manager QC.
• Data-data WQT yang sudah dikaji secara sistem akan ter-input ke dalam database sistem e-
Testing dan Oracle untuk proses disposisi.
• Status material akan berubah dari “karantina” menjadi “release”. Status berada di dalam oracle
• Material yang tidak sesuai dengan pesyaratan uji maka akan bersatus “rejected” setelah melalui
proses pada poin E.11 nomor 13. Status berada di dalam oracle
• Hasil uji ulang dan raw data dapat diprint menjadi laporan dalam bentuk PDF yang terenkripsi,
lalu akan dikirim kedalam main database, sistim ini (List Register) dan Oracle.
• Proses pembuatan laporan hanya dapat dilakukan oleh supervisor yang ditunjuk.
• Untuk material yang berstatus “release” secara otomatis akan menambah stok didalam oracle,
sehingga dapat digunakan untuk proses produksi.
• Terdapat menu “accept with variance” pada saat disposisi, jika hasil analisa tidak memenuhi
spesifikasi setelah melalui proses investigasi OOS/OOT dan deviasi.
• “Accept with variance” dapat dilakukan oleh QC manager.
• Proses nomor 12-14 akan dilakukan di dalam Oracle
1.2.16.9 MAIN DATABASE (REF ID : E.13, PG: 66)

• Database status material (RM/PM)
• Data pada Main Database ter-update ketika ada aktivitas disposisi pada sistem
1.2.17 KONTROL INVENTORI
1.2.17.1 DASHBOARD (REF ID : F.2, PG: 68-70)

• QC supervisor login kedalam sistem e-Testing dan akan diarahkan ke halaman Dashboard

• Menu inventory merupakan bagian dari e-Testing.

• User Interface pada e-Inventory berisi realtime stock dari setiap kategori inventori, yakni reagen,
reference standard (RS), dan media dalam bentuk tabel.
• Diperlukan pembuatan master data reagen, RS, kolom dan media uji di dalam Oracle
• Hal yang dijelaskan pada nomor 3 akan menjadi inventori pada on hand stock yang dimonitoring
• Default tampilan tabel realtime stock akan diurutkan berdasarkan abjad nama item reagen.
• List Register dapat di sort berdasarkan nama reagen, RS, media, jumlah yang tersisa, dan status.
• list di-sort by jumlah tersisa. Status bisa diberikan dengan. (untuk proses akan dijalankan di
oracle dengan auto PBJ sesuai dengan limit tertentu).
• Terdapat notifikasi sistem bila ada inventori yang berstatus “sedikit “dan “habis”. Jika inventori
merupakan reagen, RS, media, kolom maka sistem oracle akan mengirimkan notifikasi ke sistem
e-Testing terkait dengan status inventori, sedangkan jika inventori merupakan reagen, maka
oracle akan mengirimkan notifikasi ke sistem e-Testing untuk membuat reagen
• Informasi yang terdapat pada notifikasi PBJ mencakup No PBJ, nama item (reagen, RS, kolom,
media), catalog number, merek, sisa stok saat ini.
• Informasi yang terdapat pada notifikasi request pembuatan reagen pereaksi mencakup nama
reagen, kode item, dan sisa stok.
• Catalog number tidak mencantumkan ukuran kemasan
• Fitur help berisi mekanisme pelaporan bila terjadi gangguan/masalah pada sistem
1.2.17.2 PEMBUATAN REAGEN (REF ID : F.10, PG: 72-74)

• Khusus untuk reagen. Merupakan fungsi untuk pembuatan reagen yang dibuat dalam jumlah
besar untuk digunakan berkali-kali
• Pilih menu Pembuatan reagen, dilanjutkan dengan nama reagen yang akan dibuat
• Sistem otomatis meng-generate worksheet khusus untuk pembuatan reagen
• Reagen yang telah dibuat akan tercatat sebagai inventori dan masuk dalam stock on hand.
Fungsi pencatatan seperti pada point F.8 dan berlanjut ke point F.9
• Terdapat master data untuk reagen yang dibuat dalam jumlah besar. Master data reagen berisi
info nama reagen, jumlah, tanggal pembuatan dan ED.
• Master data tersebut berada di dalam Oracle
• ED reagen mengikuti ED supplier, kecuali jika sudah dibuka max 6 bulan sudah tidak boleh
digunakan kembali atau tergantung dari stabilita reagen.
• ED 6 bulan akan dinput secara manual pada label
• Penggunaan awal reagen akan tercatat pada saat reagen tersebut digunakan pertama kali dalam
pengujian.
• Klik tombol generate label untuk meng-generate label sesuai dengan jumlah reagen yang dibuat.
• Label akan di-generate dari Oracle
• Label berisikan informasi tanggal pembuatan dan tanggal kadaluarsa.
• Label diprint untuk ditempelkan pada reagen. Pengaturan ED reagen akan didefinisikan pada
saat pembuatan master reagen di oracle.

• Akan muncul notifikasi bila reagen dan pereaksi sudah mendekati ED supplier dan 6 bulan
setelah reagen/pereaksi digunakan, tiga bulan sebelum masa ED berakhir.
1.2.17.3 GENERATE WORKSHEET QC TESTING (PEREAKSI) (REF ID : F.11, PG: 74-75)

• Pengerjaan sampel dan pengurangan stok berdasarkan WQT
• Pengerjaan sampel sesuai WQT untuk pereaksi
• Reagen, Media, RS yang digunakan untuk pengujian, diinput ke dalam WQT sesuai dengan
jumlah yang digunakan.
• Apabila field reagen pada WQT diisi NA (untuk analisa secara campaign), maka tidak mengurangi
stock pada inventori
• Jika ada kegiatan pembuatan pereaksi atau larutan uji, maka di tiap modul ada tombol generate
label yang berisikan keterangan pereaksi yang dibuat, seperti komposisi pereaksi, volume
larutan, expired date, inisial pembuat, nomor bets pereaksi akan tergenerate otomatis seperti
nomor sampel di oracle.
• Reagen, Media, RS yang digunakan untuk pengujian akan secara otomatis mengurangi stock on
hand yang ada pada main database inventory control
• Pengurangan stock on hand akan dikalkulasi sebagai biaya pengujian. Harga Reagen, Media, RS
yang digunakan dapat diubah sesuai dengan harga aktual oleh user.
1.2.18 UJI STABILITA
1.2.18.1 DASHBOARD (REF ID : G.2, PG: 78-79)

• User Interface utama saat berhasil masuk kedalam sistem e-Testing.
• User Interface berisi logo site, ID aktif, jam-tanggal-
• bulan dan tahun berjalan, nama produk, kode produk, WQT, status studi stabilita, tanggal
efektif, menu log out, menu notifikasi, dan help
• Terdapat menu Request Studi Stabilita, Program Stabilita (sesuai responsibility)
• Tampilan user interface berbeda antar resposibility user yang melakukan login. User dengan
responsibility TS / QA Supervisor hanya dapat mengakses menu Request Studi Stabilita (G.3).
QA dan QC manager dapat melakukan kajian dan persetujuan
• Protokol/laporan stabilita. QC Supervisor dan QC Manager dapat mengakses menu poin 2-9.
• List Register dapat di-sort berdasarkan nama produk, kode produk, WQT, dan tanggal efektif.
• Nama dan kode produk akan diambil dari item master ORACLE.
• Jam, tanggal, bulan dan tahun akan mengikuti pengaturan dedicated time server.
• ID aktif terdiri dari nama personil, avatar, departemen, job title, nama site, dan waktu login awal
pada sistem.
• Terdapat menu Notifikasi (poin G.5).
• Fitur help berisi mekanisme pelaporan bila terjadi gangguan/masalah pada sistem.
• Tampilan utama pada Dashboard menunjukkan Sampel yang sedang dalam tahap pengujian,
sampel yang jatuh tempo untuk diambil dari chamber.
• Terdapat Menu Program stabilita (G.6)

1.2.18.2 REQUEST STUDI STABILITA (REF ID : G.3, PG: 79-80)

• Menu untuk mengusulkan dilakukan studi stabilita
• Teknis penyusunan usulan protokol stabilita
• Menu Request Studi Stabilita hanya dapat diakses oleh user dengan responsibility TS / QA
Supervisor.
• Menu Request Studi stabilita akan mengarahkan user untuk mengisi identitas sampel dan test
design sesuai dengan ketentuan pada penyusunan protokol test design stabilita
• Pada Menu Request Studi Stabilita terdapat tombol send yang mengirimkan output test design.
• Output dari menu test design akan berupa notifikasi kepada QC supervisor.
1.2.18.3 REQUEST TERMINASI STABILITA (REF ID : G.4, PG: 80)

• Menu untuk mengusulkan penghentian studi stabilita
• Menu Request Terminasi Studi Stabilita hanya dapat diakses oleh user dengan responsibility TS
/ QA Supervisor.
• Menu Request Terminasi Studi Stabilita digunakan untuk menghentikan studi stabilita yang
sudah disetujui yang sudah berjalan.
• Ketika Menu dipilih akan muncul list stabilita dengan status Sampel Required dan In Progress.
User dapat memilih studi yang akan di usulkan untuk diterminasi dengan cara klik. Sistem akan
menampilkan informasi sesuai protokol untuk studi yang dipilih dan terdapat tombol “Request
to Terminate” pada bagian bawah window.
• Ketika User menekan tombol tersebut akan muncul window untuk mengisi Reason terminate
dan terdapat tombol send.
• Field Reason bersifat mandatori, ketika alasan belum diisi maka tombol send akan greyed out
(tidak dapat dipilih).
• Output dari menu Terminasi akan berupa notifikasi kepada QC supervisor.
1.2.18.4 NOTIFIKASI (REF ID : G.5, PG: 80-81)

• Notifikasi adanya kebutuhan dilakukannya uji stabilita
• Notifikasi hanya dapat diakses untuk responsibility QC Supervisor
• Terdapat notifikasi dari menu request studi stabilita.
• Notifikasi yang ditampilkan berupa link, sehingga ketika QC Supervisor melakukan klik pada
notifikasi tersebut, akan membuka
• window pembuatan protokol stabilita (Program Stabilita poin G.6) dengan informasi otomatis
terisi dari request studi stabilita.
• Terdapat notifikasi dari menu request terminasi stabilita
• Notifikasi akan berupa link, sehingga ketika dipilih, akan membuka window Terminasi Studi
Stabilita sesuai dengan uji stabilita yang dipilih (Otomatis dari request) beserta alasan yang telah
di-input requestor.
• Notifikasi Pengambilan sampel akan muncul ketika jatuh tempo pengambilan sampel tercapai
(sesuai jadwal)

1.2.18.5 PROGRAM STABILITA (REF ID : G.6, PG: 81-83)

• window pembuatan protokol stabilita (Program Stabilita poin G.6) dengan informasi otomatis
terisi dari request studi stabilita.
• Terdapat notifikasi dari menu request terminasi stabilita
• Notifikasi akan berupa link, sehingga ketika dipilih, akan membuka window Terminasi Studi
Stabilita sesuai dengan uji stabilita yang dipilih (Otomatis dari request) beserta alasan yang telah
di-input requestor.
• Notifikasi Pengambilan sampel akan muncul ketika jatuh tempo pengambilan sampel tercapai
(sesuai jadwal)
• persetujuan dengan informasi status dan history review dokumen sesuai dengan ketentuan yang
diatur pada poin G.10.
• Pada Menu List Studi Stabilita, akan memuat tabel yang mengandung list studi stabilita yang
sedang berjalan (sudah disetujui). Informasi yang ditampilkan berupa No. Studi stabilita, Kode
Produk, Nomor bets, PPI no, Status studi stabilita. List studi ketika dipilih akan menampilkan
informasi studi sesuai dengan protokol stabilitanya.
• Kolom Status Studi Stabilita pada Poin 4 dapat berupa Sampel Required, In Progress, Report
Required, Report Required (Terminated), dan Complete. Status sampel required muncul ketika
protokol pertama kali disetujui dan belum dialokasikan sampel sesuai dengan protokol tersebut.
Status In Progress muncul ketika studi sudah berjalan namun data hasil pengujian stabilita belum
lengkap hingga interval terakhir atau studi telah diterminasi namun data hasil pengujiannya
belum lengkap hingga interval terakhir sebelum studi diterminasi. Status Report Required,
muncul ketika data sudah lengkap hingga titik akhir, namun belum dibuatkan laporan stabilita
(approved). Status Report Required (Terminated) muncul ketika data sudah lengkap hingga titik
jatuh tempo terakhir sebelum studi di terminasi, namun belum dibuatkan laporan stabilita
(approved). Status complete muncul ketika terdapat laporan stabilita yang sudah disetujui untuk
studi terkait.
• Menu Pembuatan Laporan stabilita, ketika dipilih akan menampilkan halaman pembuatan
laporan stabilita sesuai dengan ketentuan pada Poin G.26.
• Menu Status persetujuan laporan stabilita akan memunculkan list draft laporan stabilita yang
berada pada tahapan posting untuk persetujuan dengan informasi status dan history review
dokumen sesuai dengan ketentuan yang diatur pada poin G.27
• Menu Terminasi Studi Stabilita digunakan untuk menghentikan studi stabilita yang sedang
berjalan sesuai ketentuan yang diatur pada poin G.30. Terminasi dapat dilakukan melalui 2 cara
yaitu, melalui jalur request (G.4) oleh dept lain (QA dan TS), dan melalui pembuatan secara
mandiri oleh QC Supervisor (tanpa adanya request) (G.30).
1.2.18.6 PROTOKOL STABILITA (REF ID : G.7 – G.9, PG: 83-86)

• Penyusunan protokol dan test design.
• Pengambilan data template periode stablity dan spesifikasi dari oracle
• Drafting
• Menu Penambahan protokol stabilita baru memuat kolom: tipe dari uji stabilita (LOV, value dari
master data template uji stabilita), Kode produk (LOV value dari oracle, lalu secara otomatis

mengisi Kolom Nama produk, Shelf Life, spesifikasi, dan Prosedur Analisis sesuai dengan No
yang efektif pada Master Data), nomor bets (LOV dari Oracle), zona iklim (LOV dari master zona
iklim), tujuan studi (free text), test design (Table), Jumlah sampel (terisi otomatis sesuai dengan
parameter yang dipilih), dan report content (checkbox, untuk memilih parameter kritis yang
akan ditampilkan datanya saat pembuatan laporan stabilita).
• LoV nomor bets yang dijelaskan pada poin 1, akan menggunakan sistem flag untuk penandaan
bets record yang dilakukan uji stabilita. Flag yang dibuat dari e-Testing akan dikirimkan ke e-BR
paling lambat sebelum release step kemas pertama. Ketika terdapat bets dengan flag, maka e-
BR akan melakukan pengecekan pada database e-Testing saat akan melakukan rilis step kemas
pertama untuk mengetahui apakah terdapat protokol yang sudah disetujui untuk bets tersebut.
• LoV akan mengambil database dari List Register WO yang dibuat oleh PPIC.
• Ketika terdapat bets yang di flag, sistem e-Testing akan melakukan monitoring proses produksi
terhadap bets tersebut dan akan mengirimkan notifikasi kepada QC Supervisor ketika proses
produksi mengirim sampel ruah ke QC untuk mengingatkan pembuat protokol.
• Tabel Test design berisi kolom parameter pengujian yang terisi otomatis sesuai dengan
parameter pada spek (Oracle), dan kolom Interval pengujian (Template Periode Oracle).
Template pengujian Oracle akan dibuat berdasarkan Shelf Life produk (terisi secara otomatis
ketika user memilih kode produk). Interval pengujian yang muncul dari template tersebut dapat
diedit dengan pilihan insert/add dan delete column.
• Pada tabel yang terbentuk dari poin sebelumnya user akan memberikan checkmark pada
parameter yang ingin diuji pada interval tertentu. Pengisian ini yang akan menentukan WQT
yang aktif ketika interval pengujian tercapai. Contoh kolom Test design memiliki tampilan
sebagai berikut:
Interval
Parameter Uji
Pengujian
3M 6M 9M 12M 18M 24M
Bobot Individu √ √ √ √ √ √
Kekerasan √ √ √ √
Kadar √ √ √ √
Disolusi √ √ √ √
• Jika penambahan protokol stabilita baru dilakukan melalui Notifikasi (G.5) maka informasi pada
poin 1 terisi sesuai dengan request studi stabilita yang dibuat.
• Pada Menu Penambahan Protokol stabilita terdapat tombol save untuk menyimpan data yang
telah diinput, tombol edit untuk
• melanjutkan atau mengubah data yang telah disimpan, tombol send untuk posting draft
protokol.
• Ketika tombol save ditekan pertama kali pada penambahan protokol stabilita maka sistem men-
generate nomor versi secara otomatis dan sistem akan menyimpan nama personil, jabatan dan
e-sign pada protokol stabilita sebagai informasi awal data pembuat.
• Proses diatas harus terekam di dalam audit trail.
• Program stabilita mencakup produk jadi dan produk intermediate (contohnya: premix).

• Terdapat tombol delete/discard untuk membatalkan protokol yang sedang dibuat

• Prosedur Analisis dan spesifikasi pada Protokol stabilita yang sudah disetujui akan terupdate
ketika terdapat MWQT versi terbaru.
• Perubahan prosedur analisis dan spefikasi pada protokol stabilita yang sudah disetujui akan
tercatat pada audit trail
• Perubahan ini akan berdampak pada WQT yang ter-generate pada schedule stabilita interval
setelah perubahan terjadi. Worksheet tersebut akan ter-generate berdasarkan MWQT versi
terbaru.
1.2.18.7 REVIEW, DAN APPROVAL. (REF ID : G.10 – G.11, PG: 86-88)

• Penentuan alur posting, kajian dan persetujuan protokol uji stabilita
• Proses kajian oleh personel yang ditunjuk
• Proses kajian dan persetujuan dimulai ketika draft protokol di-send. Pada tahapan ini dokumen
elektronis sudah memiliki nomor versi dokumen elektronik.
• Terdapat informasi tanggal terakhir draft dibuat/diperbarui, tanggal send, nama personil,
jabatan dan e-sign akan ter-generate.
• Proses kajian/persetujuan melalui mekanisme group review.
• Notifikasi untuk melakukan kajian/ ada di sistem.
• Terdapat User Interface tersendiri untuk reviewer dan approver.
• Jendela reviewer dan approver akan menampilkan list produk yang perlu dikaji.
• Pilih protokol studi yang terdapat pada jendela menu reviewer dan approver.
• Pilih menu review/approval in progress untuk menginformasikan proses kajian sedang berjalan.
• Proses kajian ini dapat dilakukan maksimal 2 hari kerja setelah menu review/approval in progress
di pilih.
• Menu review/approval in progress berisi worklist yang butuh kajian/persetujuan. (Setiap worklist
ditampilkan pada menu ini selama 2 hari)
• Bila diperlukan lebih dari 2 hari kerja untuk melakukan kajian pilih menu extend review/approval
in progress.
• Proses perpanjangan maksimal 2 hari kerja dihitung dari menu extend review/approval in
progress dipilih.
• Maksimal extend adalah 1 kali.
• Bila proses kajian belum juga selesai setelah perpanjangan maka kajian dokumen elektronis akan
otomatis naik ke atasan reviewer yang ditentukan.
• Pada Jendela Review/approval, terdapat 2 tombol yaitu Approve atau revise.
• Ketika tombol revise dipilih maka reviewer harus mengisi komentar/note untuk diperbaiki oleh
pembuat. Dokumen tersebut akan kembali berstatus draft disertai notifikasi kepada pembuat.
• Reviewer dapat melihat comment dari reviewer lain.
• Protokol studi stabilita hasil kajian yang sudah disetujui akan bersatus approved.
• Tanggal protokol studi stabilita akan ter-generate sesuai dengan tanggal approved.
• Protokol yang sudah disetujui akan muncul pada Menu List Studi Stabilita dengan status sampel
required.

• Jika terdapat lebih dari satu reviewer maka proses kajian berjalan paralel. Namun proses
persetujuan baru dapat dilakukan setelah semua reviewer mengkaji usulan.
1.2.18.8 PERMINTAAN DAN PENGAMBILAN SAMPEL STABILITA, (REF ID G.12, PG: 88-89)
• Ketentuan pengambilan sampel sesuai dengan lokasi produk:
o Produk masih diproduksi (Open Bets).
o Produk sudah digudang (closed bets)
• Request sampel stabilita dilakukan dengan mekanisme yang berkaitan dengan kapan protokol
stabilita untuk bets yang di-flag telah disetujui (sebelum atau sesudah rilis step kemas primer).
• Bila saat e-BR melakukan rilis step kemas primer belum terdapat protokol stabilita yang telah
disetujui untuk bets tersebut (masih
• dalam tahap persetujuan atau belum dibuat) maka sistem e-Testing melakukan un-Flag secara
otomatis (sistem akan memberikan alasan pada audit trail) tanpa menghambat proses produksi.
Permintaan sampel stabilita akan melalui jalur FKB.
• Bila saat e-BR melakukan rilis step kemas primer sudah terdapat protokol stabilita yang disetujui
untuk bets tersebut maka sistem e-Testing akan mengirimkan data jumlah sampel kepada e-BR
dan mengharuskan tim produksi untuk mengirimkan sampel stabilita sesuai jumlah tersebut
sebelum closed bets. Jika sampel tersebut belum dikirimkan (belum input jumlah sampel yang
dikirim) maka proses closed bets tidak dapat dilakukan.
• Proses FKB disesuaikan dengan kebutuhan oracle.
1.2.18.9 PEMBUATAN LABEL SAMPEL STABILITA (REF ID : G.13 – G.14, PG: 89-90)
• Penerimaan sampel oleh QC
• Pembuatan label identitas sampel stabilita sesuai dengan posisi produk:
o Produk masih diproduksi
o Produk sudah di gudang
• Pembuatan label identitas sampel jika produk masih dalam proses produksi akan dilakukan oleh
personil produksi, melalui Oracle.
• Label yang ter-generate berisi informasi: Kode Produk, Nama Produk, Jumlah Sampel, Tanggal
dan waktu generate label, dan personil yang men-generate label tersebut disertai barcode.
Informasi tersebut akan terisi secara otomatis ketika personel produksi mengklik notifikasi.
Barcode akan berisi informasi diatas dan akan memudahkan dalam proses penerimaan sampel
oleh tim QC (poin 8).
• Catatan pada poin 2 akan tersimpan dalam audit trail.
• Personil produksi menempelkan label tersebut kepada produk yang akan dikirim ke QC.
• Pembuatan label sampel yang melalui jalur FKB oracle, akan dibuat oleh personil QC.
• Personel QC akan mencocokkan sampel yang datang sesuai dengan FKB yang dibuat (G.12 poin
4). Sampel yang sudah dicocokkan akan diberi label identitas yang di-generate melalui oracle
• Informasi yang terkandung pada label mengikuti ketentuan pada poin 2 dan 3.
• Penerimaan sampel dilakukan dengan men-scan barcode. Waktu penerimaan sampel dicatat
dari hasil barcode tersebut dan sistem akan menampilkan jendela protokol stabilita untuk

mengupdate bahwa sampel telah diterima dan meminta entry lokasi penempatan sampel pada
chamber (alocate sampel) (G.16).
1.2.18.10 PEMASUKAN SAMPEL KE DALAM CHAMBER (REF ID : G.15 – G.18, PG: 90-92)
• Pemasukan sampel ke dalam chamber, dan input data waktu memasukkan sampel, jadwal jatuh
tempo dan notifikasi pengambilan sampel
• Alur dan mekanisme alokasi sampel ke dalam chamber.
• Mekanisme aktivasi scheduling
• Notifikasi pengambilan sampel ketika due date tercapai
• Sampel yang sudah diterima, dimasukkan kedalam chamber stabilita sesuai dengan kondisi yang
ditentukan pada protokol.
• Terdapat fitur alocate sampel untuk memasukkan kode penempatan pada chamber. Pada
jendela tersebut terdapat kolom Chamber (LOV chamber yang tersedia, diambil dari database
e-PM), dan kolom Kode Penempatan (LOV). Kolom kode penempatan disesuaikan dengan
jumlah titik pengujian pada protokol.
• Pada pengembangan selanjutkan direncanakan kode penempatan dapat di-entry secara
otomatis melalui aktivitas scan barcode.
• Status kalibrasi, kualifikasi, dan maintenance chamber pada kolom Chamber terkoneksi secara
otomatis dengan sistem e-PM, e-Calibration & Qualification. Chamber dengan status kalibrasi
atau kualifikasi yang tidak memenuhi syarat atau melewati due date rekalibrasi/rekualifikasi
akan ditandai dengan warna merah dan muncul peringatan ketika dipilih serta diperlukan
remarks atau alasan penggunaan.
• Peringatan yang muncul akan berisi informasi alasan dan status kalibrasi/kualifikasi alat.
• Waktu dan personel yang melakukan alocate sampel akan tercatat pada audit trail.
• Data pada poin 2 dan 3 akan otomatis masuk kedalam protokol studi stabilita terkait. Ketika data
yang dibutuhkan belum terinput lengkap, maka tombol Start Scheduling akan di grey out dan
tidak dapat dipilih. Terdapat tombol save untuk menyimpan data yang telah diinput.
• Ketika data yang dibutuhkan sudah lengkap, sistem secara otomatis akan memunculkan pop up
konfirmasi untuk memulai Scheduling sampel. Ketika scheduling sampel dimulai, sistem akan
mengupdate status studi stabilita pada list studi stabilita dari sampel required menjadi In
Progress dan sistem akan mengkalkukasi estimasi jatuh tempo pengambilan sampel setiap
• titik pengujian beserta jumlah yang harus diambil sesuai dengan protokol stabilita terkait.
• Ketika jatuh tempo pengambilan sampel tercapai, akan muncul notifikasi kepada personil QC
pada panel notifikasi dan dashboard untuk mengambil sampel pada chamber. Sistem akan
memberikan informasi chamber dan kode penempatan berdasarkan data yang di-entry pada
poin 2 serta jumlah sampel sesuai dengan protokol stabilita.
• Sampel yang sudah dikeluarkan dari chamber, dilakukan scan barcode untuk mencatat tanggal,
waktu, dan personel yang melakukan pengambilan sampel dan memotong jumlah sampel serta
memindahkan entry stabilita di dashboard dari list pending pengambilan sampel ke list
inprogress pengujian dan men-generate WQT sesuai parameter pada jatuh tempo
1.2.18.11 GENERATE WQT, SAMPLING, RESULT INPUT, DAN APPROVAL HASIL

ANALISA (REF ID : G.19 – G.25, PG: 92-94)
• WQT akan aktif per parameter sesuai dengan jatuh tempo stabilita
• Dashboard PIC analisa
• Input hasil analisa
• Review hasil analisa → Kajian hasil pengujian
• Penyimpanan ke database
• WQT aktif setelah personel QC melakukan scan barcode pada sampel yang telah diambil dari
chamber dan sistem akan memberikan nomer sampel yang spesifik untuk setiap sampel yang
ter-generate.
• WQT yang muncul akan menyesuaikan test design pada protokol stabilita dan MWQT yang
berlaku pada interval tersebut.
• WQT yang muncul dapat di-assign pada analis yang dipilih pada menu Dashboard (LOV).
Assigment analisa dan kajian akan dilakukan secara sub group
lebih dari 1 worksheet.
tersebut.
• Input data hasil pengujian dilakukan secara manual kedalam WQT, hardcopy dilampirkan
sebagai bukti pendukung dan diberikan informasi sesuai dengan ketentuan GdocP yang berlaku.
• Pengembangan sistem kedepannya mencakup integrasi data dengan instrumen sehingga
penginputan data tidak lagi dilakukan secara manual, data yang terinput pada sistem adalah data
yang telah disetujui melalui sign off (jika instrumen memiliki fitur tersebut).
• Kesimpulan dari hasil pengujian akan muncul langsung pada WQT sesuai dengan spesifkasi
pengujian pada masing-masing parameter.
• Bila hasil diluar spesifikasi maka akan terdapat sign khusus yang menandakan hal tersebut
didalam WQT.
• Bila hasil dari pengujian memenuhi persyaratan dan tren analisis maka disposisi perubahan
status sampel dari “pending” menjadi “complete” akan diatur sistem dan memberikan notifikasi
dengan informasi yang menyatakan nomor bets produk tersebut dengan nomor WQT terkait
sesuai dengan persyaratan dan tren.
• Sebaliknya, bila hasil uji memenuhi persyaratan tetapi tidak sesuai dengan tren maka terdapat
informasi khusus pada sistem e-testing untuk meneruskannya kedalam modul OOS/OOT.
• Ketentuan prosedur OOS/OOT mengikuti alur pada modul OOS/OOT.
• Data CHP yang telah disetujui akan tersimpan pada database. Data tersebut digunakan ketika
user membuat laporan stabilita untuk studi stabilita terkait.
1.2.18.12 PEMBUATAN LAPORAN STABILITA DAN APPROVAL (REF ID : G.26 – G.29,

PG: 94-97)
• Alur Pembuatan laporan stabilita

• Alur review dan Approval laporan stabilita
• Penyimpanan data laporan approved
• Terdapat menu pembuatan laporan stabilita. Menu tersebut ketika dipilih akan mengarahkan
user untuk memilih studi yang akan dibuat laporannya dari list studi stabilita yang berstatus
Report Required.
• Informasi pada protokol akan digunakan pada pembuatan laporan
• Data CHP yang telah tersimpan pada database akan muncul dalam bentuk tabel sesuai dengan
desain stabilita yang dipilih, seperti berikut:
Interval Pengujian
Parameter Uji Spesifikasi
3M 6M 9M 12M 18M 24M
450 - 550
Bobot Individu 500 501 541* 432* 499 511
mg
Kekerasan 10 - 15 kp 11 12 - 9* - 14
90.0 -
Kadar 95 96 - 96.1 - 97.2
110.0%
Disolusi NLT 80% 97 95 - 95 - 93
• Terdapat efek warna merah pada font untuk hasil yang OOS/OOT, dan terdapat tanda (*) untuk
hasil analisis yang sebelumnya telah melalui investigasi OOS.
• Terdapat kolom untuk keterangan tambahan untuk hasil pengujian yang mengalami
penyimpangan.
• Terdapat tombol untuk menambahkan field baru sebagai keterangan/narasi dari data CHP per
parameter.
• QC supervisor membubuhkan e-sign pada laporan yang sudah dibuat lalu dipilih tombol send.
• Proses review dan approval dimulai ketika draft laporan di-send. Pada tahapan ini dokumen
elektronis sudah memiliki nomor versi dokumen elektronik.
• Terdapat informasi tanggal terakhir draft dibuat/diperbarui, tanggal send, nama personil,
jabatan dan e-sign akan ter-generate.
• Notifikasi untuk melakukan review dan approval akan berada pada sistem.
• Terdapat User Interface tersendiri untuk reviewer dan approver.
• Jendela reviewer dan approver akan menampilkan list laporan yang perlu dikaji.
• Pilih laporan stabilita yang terdapat pada jendela menu reviewer dan approver.
• Proses review ini dapat dilakukan maksimal 2 hari kerja setelah menu review/approval in progress
di pilih.
progress.
o Proses perpanjangan maksimal 2 hari kerja dihitung dari menu extend review/approval
in progress dipilih.
o Extend hanya dapat dilakukan 1 kali.

otomatis naik kepada atasan reviewer yang ditentukan.
• Pada Jendela Review/approval, terdapat 2 tombol yaitu Approve atau Revise.
pembuat. Dokumen tersebut akan kembali berstatus draft disertai notifikasi kepada pembuat.
• Jika terdapat lebih dari satu reviewer maka proses kajian berjalan paralel. Namun proses
approval baru dapat dilakukan setelah semua reviewer menyetujui usulan.
• Laporan studi stabilita hasil kajian yang sudah disetujui maka akan bersatus approved.
• Tanggal laporan studi stabilita akan tergenerate sesuai dengan tanggal approved dan akan
tersimpan pada main database
• laporan yang sudah approved akan mengupdate status studi pada List Studi Stabilita menjadi
complete.
1.2.18.13 TERMINASI STUDI STABILITA, REVIEW DAN APPROVAL. (REF ID : G.30 –

G.32, PG: 97-100)
• Mekanisme terminasi Studi Stabilita
• Alur Review dan Approval Studi Stabilita
• Terdapat menu Terminasi Studi Stabilita. Menu tersebut ketika dipilih akan mengarahkan user
untuk memilih studi yang akan dilakukan terminasi.
• Informasi pada protokol akan ditampilkan pada saat studi stabilita dipilih.
• Pada bagian dasar window informasi tersebut terdapat tombol “Terminate”.
• Ketika tombol terminate dipilih, maka akan muncul window Reason dengan Tombol Send dan
Cancel
• Reason bersifat mandatory, tombol send tidak dapat pilih ketika kolom reason belum terisi.
• Ketika tombol send dipilih sistem akan merecord informasi tanggal request terminasi di send,
nama personil, jabatan dan e-sign.
• Proses review dan approval dimulai. Pada tahapan ini request sudah memiliki nomor versi
dokumen elektronik.
• Notifikasi untuk melakukan review dan approval akan berada pada sistem.
• Terdapat UI tersendiri untuk reviewer dan approver.
• Jendela reviewer dan approver akan menampilkan list request yang perlu direview.
• Pilih request terminasi yang terdapat pada jendela menu reviewer dan approver.
• Proses kajian ini dapat dilakukan maksimal 2 hari kerja setelah menu review/approval in progress
di pilih.
progress.
• Proses perpanjangan maksimal 2 hari kerja dihitung dari menu extend review/approval in
progress dipilih.
• Maksimal extend adalah 1 kali.

otomatis naik ke atasan reviewer yang ditentukan.
• Pada Jendela Review/approval, terdapat 2 tombol yaitu Approve atau Revise.
pembuat. Request yang telah direvise akan kembali berstatus draft disertai notifikasi kepada
pembuat.
• Jika terdapat lebih dari satu reviewer maka proses review berjalan paralel. Namun proses
approval baru dapat dilakukan setelah semua reviewer menyetujui usulan.
• Ketika Request sudah di approve, sistem akan merecord tanggal approved dan mengupdate
status studi pada List Studi Stabilita menjadi Report Required (Terminated) jika data sudah
approved. Jika data belum lengkap hingga interval terakhir sebelum studi diterminasi maka studi
tetap dalam status In Progress.
• Ketika Studi sudah diterminasi maka terdapat satu kolom tambahan pada jendela informasi studi
yang memberikan informasi bahwa studi sudah diterminasi dan scheduling telah dihentikan.
• Studi stabilita yang sudah disetujui untuk diterminasi tidak dapat diaktifkan kembali. Studi
stabilita tersebut akan menampilkan sisa jumlah sampel yang perlu dimusnah beserta lokasi
peletakannya
1.2.19 MANAJEMEN USER

• Pada halaman ini, admin dapat mengatur user (staff) yang dapat mengakses aplikasi backend
ini.
• Akan ada user superadmin yang akan ditambahkan secara otomatis oleh sistem dan tidak
dapat dihapus.
• User Management akan terintegrasi dengan Active Directory yang sudah dimiliki oleh Kalbe
1.2.20 MANAJEMEN GRUP USER / ROLE

• Pada halaman ini, admin dapat mengatur role / group user.
• Akan ada role / group admin yang akan ditambahkan secara otomatis dan tidak dapat dihapus.
1.2.21 MANAJEMEN HAK AKSES

• Pada halaman ini, admin dapat mengatur hak akses dari role / group dan user secara spesifik.
• Hak akses akan berupa sebagai berikut:
o View / akses halaman (Read Permission)
o Edit / update data (Read and Write Permission)
o Delete data (Delete Permission)
• Jika semua hak akses diceklis, maka user akan memiliki All Permission.
• Jika tidak ada hak akses yang diceklis, maka user tidak memiliki akses sama sekali.
1.2.22 MANAJEMEN PUSH NOTIFICATION

• Pada halaman ini, user dapat mengirimkan push notification secara manual.
• Admin dapat melihat seluruh list push notification yang pernah dikirimkan.
• List push notification tidak dapat dihapus.
1.2.23 SETTINGS
• Pada halaman ini, admin dapat mengubah password mereka dan mengubah data profil
mereka.
1.2.24 SIGN OUT

• Untuk keluar dari aplikasi, user dapat menekan tombol “Sign Out” dan semua session user akan
dihapus dan user akan dilempar ke halaman Login.

2 SOLUSI YANG DIUSULKAN
2.1 APLIKASI BERBASIS WEB (FRONT-END & BACK-END)
2.1.1 TEKNOLOGI YANG DIGUNAKAN

Web Back-end .NET Core version 3.1
Web Front-end HTML5, CSS3, JavaScript, jQuery, Bootstrap
Operating System Windows Server 2019
Web Server IIS
Database Server SQL Server
2.1.2 KOMPATIBILITAS BROWSER

HTML/CSS yang sesuai dengan standar aplikasi berbasis web.
Kompabilitas browser sebagai berikut:
Browser / Pixel width (16:9) 1280 1366 1920

Windows, Firefox latest N/A Yes Yes
Windows, IE 11.x & Edge N/A Yes Yes
Windows, Chrome latest N/A Yes Yes
Linux, Chrome latest N/A Yes Yes
Mac, Safari latest Yes N/A Yes
Komputer klien harus menggunakan Windows 7 dengan setidaknya RAM 2 GB.
2.1.3 RESPONSIVE FRONT-END

Kompatibilitas browser sebagai berikut:
Browser 720p 1080p

Safari latest, iOS 12 & 13 Yes Yes
Chrome latest, Oreo & Pie OS Yes Yes
2.2 STANDAR KUALITAS
2.2.1 STANDAR KODE WEB BACK-END DAN BAKU MUTU

WGS akan mengembangkan kode yang mengikuti standar-standar ini:
• Semua parameter masukan akan bersih dan tervalidasi.

• Semua parameter masukan yang penting akan divalidasi dengan kode dari sisi server.
• Server akan memberikan pesan untuk menangani kesalahan dan tidak akan memberikan
informasi yang bersifat sensitif kepada pengguna.
• Server akan memberikan response API sesuai dengan format standar JSON milik WGS untuk
web services.
• Server akan memberikan response kepada pemanggil API jika pemanggil API menggunakan
access token acak (untuk aplikasi yang tidak memiliki fitur sign in) atau membuat access token
(untuk aplikasi yang memiliki fitur sign in)
• OAuth 2.0 akan digunakan sebagai standar untuk melakukan Sign In ke aplikasi.
• Rutinitas enkripsi berdasarkan pada algoritma standar industri dan library.
• Kode yang dibuat tidak mengandung kode statis basis data dan sandi dari layanan pihak ketiga.
• Server akan membuat thumbnail gambar dari gambar yang diunggah.
• Penggunaan soft delete untuk master data dan data yang berhubungan dengan transaksi.
• Kata sandi diacak dengan menggunakan enkripsi sebelum disimpan, tidak disimpan dalam
bentuk teks biasa dalam berkas teks maupun basis data.
• Kode yang dibuat tidak mengandung Easter-Egg atau back-door.
• Kode tidak akan menggunakan mode development di lingkungan produksi.
• Kode debug telah di hapus.
2.2.2 KODE STANDAR WEB FRONT-END DAN BAKU MUTU

• Menggunakan DOCTYPE yang benar.
• Menggunakan validasi dan struktur markup.
• Menggunakan CSS untuk mengontrol halaman web dan elemen styling.
• Semua form input harus divalidasi sebelum dikirimkan ke server.
• Encode karakter HTML sebagai entitas karakter HTML (&amp, dll.).
• Menentukan pengkodean karakter untuk setiap halaman web.
• Menggunakan thumbnail gambar terutama pada halaman yang menyajikan banyak gambar
• Pesan kesalahan yang mudah dimengerti
o Menulis pesan kesalahan yang jelas, dengan konten yang konsisten, format teks
(termasuk warna)
o Memberikan pesan kesalahan dan kemampuan untuk memperbaiki kesalahan pada
halaman yang sama
o Tidak membuat pengguna mengetik ulang informasi yang benar pada validasi formulir
• Kode yang dibuat tidak mengandung Easter-Egg atau back-door.
• Kode tidak akan menggunakan mode development di lingkungan produksi.
• Kode debug telah di hapus.
2.2.3 BACK-END APPLICATION PERFORMANCE

Data harus berada dalam basis data untuk jangka waktu minimal 4 tahun; sebelum 4 tahun data yang
tidak boleh dihapus atau diarsipkan. Aplikasi akan dapat menangani sekitar:

• 2000 – 4000 produk

• 1000 bahan baku
• 600 testing / hari
• 15 concurrent user (backoffice)
Kecuali jika ada batasan yang dijelaskan sebelumnya, tidak akan ada peringatan pada laporan NewRelic
(versi gratis) selama simulasi stress test menggunakan lingkungan produksi.
Data kinerja yang disebutkan di atas hanyalah sebagai benchmark besaran data yang akan diolah oleh
aplikasi.
2.2.4 KEAMANAN APLIKASI

WGS akan memenuhi standar keamanan OWASP Top 10 tahun 2017
• Injection
• Broken Authentication
• Sensitive Data Exposure
• XXE – XML External Entities
• Broken Access Control
• Security Misconfiguration
• XSS – Cross Site Scripting
• Insecure Deserialization
• Using Components with Known Vulnerabilities
• Insufficient Logging & Monitoring
2.2.5 STANDAR DESIGN

Design akan disediakan pada fase Pre-development dan design akan digunakan setelah approval Klien.
2.2.5.1 BLANK SLATE

WGS akan menyediakan halaman blank slate yang akan digunakan pada aplikasi saat kondisi data
masih kosong sebelum user melakukan entri data ke dalam aplikasi dan sebagai panduan untuk user
yang akan mulai menggunakan aplikasi.
2.2.5.2 E-MAIL TEMPLATE

WGS akan menyediakan desain template e-mail untuk setiap e-mail yang dikirimkan kepada user oleh
aplikasi.
2.2.5.3 HALAMAN ERROR 404 DAN 500

WGS akan menyediakan halaman error kustom untuk 404 (Page Not Found) dan 500 (Internal Server
Error) yang akan ditampilkan sesuai dengan HTML Error Code sehingga tidak ada error message yang
ditampilkan langsung dari framework yang digunakan.

2.2.6 STANDAR PLUGIN ATAU 3 RD PARTY TOOLS / VENDOR

WGS akan menggunakan plugin atau 3rd party tools atau 3rd party vendor yang sudah WGS percaya
dalam pembuatan aplikasi, antara lain:
Plugin Technology
Transaction E-mail Amazon SES / Sendgrid / Use Client’s Existing Tools
Knowledge Base and Live Freshdesk / Use Client’s Existing Tools
Chat
Application Performance NewRelic, Jennifer / Use Client’s Existing Tools
Monitoring (APM)
2.2.7 STANDAR KESESUAIAN

WGS menggunakan standar kesesuaian untuk keamanan dan bahasa pemrograman yang dituliskan
dibawah ini:
Component Standard Compliance

Security & Vulnerability OWASP Compliance
.NET FxCop Compliance dan mengikuti standar SonarQube dari Kalbe
2.2.8 STANDAR QUALITY CONTROL
2.2.8.1 STANDAR TESTING

Gambar 1 Infografik Quality Control
Untuk membuat aplikasi yang solid, dan mengurangi upaya pemeliharaan di masa depan, skrip tes
otomatis akan ditulis untuk menangani masalah fungsi kritis.
2.2.8.2 QC LEVEL 1

WGS menggunakan Black Box Testing untuk memastikan bahwa aplikasi yang dibuat dapat digunakan
oleh user tanpa harus mengikuti pelatihan terlebih dahulu dan White Box Testing untuk memastikan
bahwa setiap bisnis proses dan flow yang dibuat sesuai dengan kebutuhan Klien.
2.2.8.3 QC LEVEL 2
WGS akan melakukan Performance Testing, Stress Testing, dan Penetration Testing untuk memastikan
aplikasi dapat berjalan dengan baik tanpa masalah ketika digunakan oleh banyak user secara bersamaan.
2.2.8.4 QC LEVEL 3
WGS akan menggunakan unit testing tools yang sesuai dengan bahasa pemrograman yang digunakan
dan menggunakan Katalon dan Cucumber berdasarkan Test Plan / Traceable Matrix sebagai functional
test kemudian mengintegrasikan kedua test tersebut dengan Continuous Integration and Delivery
menggunakan deployment tools untuk memastikan aplikasi yang di-deploy sesuai dengan Standar dan
Kualitas Kesesuaian WGS.
2.2.9 VALIDASI APLIKASI DAN STANDAR HANDLING
2.2.9.1 VALIDASI FORM

Beberapa validasi umum yang akan ditangani antara lain:
• Persentase diskon tidak boleh dibawah nol atau di atas 100 persen
• Harga tidak boleh dibawah nol
• Tanggal Lahir tidak boleh kurang dari 10 tahun
• E-mail akan divalidasi menggunakan regex
• Nomor telepon akan divalidasi dan hanya akan menermia tanda plus (+) dan angka saja
• Password harus termasuk kominasi antara angka, huruf besar, dan huruf kecil
2.2.9.2 BREADCRUMB
Breadcrumb akan diimplementasikan sebagai pembantu navigasi di user interface untuk membantu user
dalam mengetahui di mana user berada pada aplikasi sehingga user dapat melakukan tilas balik ke titik
awal.
2.2.9.3 LAZY LOADING

Lazy loading akan diimplementasikan untuk menunda inisialisasi objek sampai waktu di mana objek
tersebut diperlukan untuk meningkatkan efisiensi dan performa aplikasi
2.2.9.4 PAGINATION
Pagination akan diimplementasikan terutama pada aplikasi back-end dan beberapa fitur di aplikasi front-
end yang menyajikan banyak data yang identic (contoh: produk, promo, dll.)
2.2.9.5 NULL HANDLING

Nilai null mengindikasikan bahwa data kosong atau tidak ditemukan dan sering kali dapat menyebabkan
runtime error. Aplikasi harus dapat menangani nilai null sehingga aplikasi tidak akan crash ketika
menemukan nilai null dari basis data atau API request / response.
2.2.9.6 RETRY HANDLING

Jika aplikasi mengalami kesalahan atau runtime error, harus ada aksi yang dapat melakukan kembali aksi
yang gagal dilakukan sebelumnya.
2.3 INFRASTRUKTUR
2.3.1 PENYEDIA HOSTING

WGS akan menggunakan server on-premise milik Klien atau server cloud milik Klien sebagai penyedia
hosting pada lingkungan produksi
2.3.2 MODE PEMELIHARAAN

Kami akan membuat mode pemeliharaan yang dapat diaktifkan dari halaman Setting Admin. Halaman
ini digunakan saat server sedang mati, saat pemeliharaan aplikasi atau server, saat deployment aplikasi
ketika aplikasi sudah live.
2.3.3 BACKUP DAN PEMANTAUAN

Kami akan membuat backup ke dalam penyimpanan.
1. Basis data
2. Data aplikasi (contoh: berkas yang diunggah pengguna, berkas yang dibuat secara dinamis)
Backup data akan dilakukan secara otomatis setiap satu hari sekali, dan disimpan selama satu bulan.
WGS akan menyediakan notifikasi pemberitahuan ketika server sedang tidak aktif. WGS akan
menyediakan pemantauan kinerja server menggunakan NewRelic dengan akun dari klien.
WGS hanya akan melakukan backup dan monitoring jika deployment dilakukan oleh WGS dan selama
masa support aktif.
2.3.4 KEAMANAN
WGS akan menggunakan standar tertentu untuk memastikan pihak yang tidak bertanggung jawab tidak
bisa masuk ke dalam sistem:
• Menonaktifkan kata kunci login dan menggunakan kunci SSH untuk membuat pihak yang tidak
bertanggung jawab lebih sulit untuk masuk.
• Menonaktifkan login root untuk mencegah pihak yang tidak bertanggung jawab tidak dapat
login sebagai pengguna istimewa.

• Menggunakan sudo dan password yang kompleks, seperti minimal 8 karakter, setidaknya 1
karakter kapital, 1 karakter biasa, 1 angka, dan 1 karakter khusus.
• Menggunakan sertifikat SSL (HTTPS) untuk formulir yang bersifat penting seperti login atau
formulir pendaftaran.
2.4 CI/CD PIPELINE
Gambar 2 CI/CD Pipeline

3 HASIL AKHIR DAN DOKUMENTASI
Berikut ini adalah hasil akhir yang akan disediakan kepada klien saat proyek selesai:
1. Fitur Aplikasi, Kode Aplikasi atau Hasil Build Aplikasi

WGS akan memberikan aplikasi berbasis web / aplikasi native mobile yang disetujui dan
dinyatakan pada bagian fitur perangkat lunak di atas. Kode aplikasi akan disimpan dan dapat
diakses secara keseluruhan di server repositori kolaborasi seperti Github atau Bitbucket atau
pada server klien.
2. Akses Credential
Data info akses credential akan diberikan kepada klien untuk server development atau server
produksi di mana klien dapat mengubah semua credential setelah akhir fase support.
3. Laporan Harian
Laporan harian adalah laporan yang diberikan kepada klien mengenai apa yang sudah dikerjakan
hari ini dan apa yang akan dikerjakan esok hari. Berikut ini adalah contoh Laporan Harian kami.
Bersamaan dengan hasil akhir tersebut, dokumentasi perangkat lunak yang penting juga akan
disediakan untuk klien saat proyek selesai, yaitu:
1. Rencana Uji
Dokumen rencana uji akan dibuat untuk memastikan semua fungsionalitas yang sudah
dikembangkan dan yang sudah disetujui dan untuk memastikan standar kualitas seperti
disebutkan pada KAK ini. Hasil akhir rencana uji akan diberikan kepada klien pada akhir proyek.
Dokumen ini akan diberikan dalam format Excel.
2. Dokumentasi Teknis
Dokumen penting ini dapat digunakan oleh developer bahkan developer selanjutnya, penguji
aplikasi, dan juga pengguna akhir untuk mengetahui hal teknis dari aplikasi ketika ada perubahan
struktur atau informasi selama periode waktu tertentu. Dokumentasi teknis yang diberikan akan
berisi detail dari arsitektur sistem, kebutuhan perangkat lunak, teknologi spesifik yang
digunakan, desain basis data (ERD, diagram kelas, dan struktur basis data), arsitektur aplikasi
(model, kontroler, API, dll.) dan tentunya instalasi sistem dan prosedur pemeliharaan.
3. Panduan Pengguna
Panduan pengguna ini akan membantu orang yang bekerja dalam menggunakan aplikasi ini
mengerti fitur dan fungsi dari perangkat lunak berdasarkan pada peran dan alur bisnis.

4 STRATEGI IMPLEMENTASI PROYEK
4.1 STRATEGI DEPLOYMENT KE SISTEM PRODUKSI
Untuk menjaga kualitas aplikasi saat akan Go-live, maka hal-hal berikut ini akan dilakukan, yaitu:
• Menjaga spesifikasi dan rule aplikasi agar tetap sesuai dengan hasil UAT.
• Aplikasi yang baru go-live akan berstatus Beta dan akan ada logo Beta juga pada logo aplikasi
untuk mempersiapkan aplikasi dan operasional dari aplikasi agar up to speed dan juga menjaga
ekspektasi dari pengguna / customer.
• Label Beta akan di lepas jika aplikasi sudah stabil atau fase free support berakhir tanpa
perpanjangan kontrak support dengan persetujuan berupa BAST antara Klien dengan WGS.
• Klien memastikan adanya SOP untuk menyimpan / validasi informasi penting sebagai data
pendukung untuk validasi data di kemudian hari.
• Untuk quick fix tim support akan fokus ke pengecekan data terlebih dahulu (data first), untuk
solusi permanen tim support baru akan memperbaiki kode.
• Setiap defect akan dicatat step untuk reproduce dan solusinya dan dikumpulkan dalam sebuah
Knowledge Base yang dapat diakses kembali di kemudian hari.
4.2 MILESTONE
Berikut ini adalah estimasi waktu untuk setiap fase, namun akan ada kemungkinan estimasi waktu ini
akan berubah di fase project planning / pre-development:
Fase / Periode Timeline Tanggung Jawab Klien & WGS

Project Planning 4 minggu • Setelah uang muka diterima, WGS akan mengatur jadwal
proyek berdasarkan tanggal kalender.
• WGS akan mengatur arsitektur aplikasi dan skema basis
data.
• WGS akan menulis skenario dalam bentuk dokumen use
case yang disertakan mockup yang harus disetujui oleh
Klien; format akan ditentukan oleh WGS dan ruang lingkup
sesuai dengan 'Fitur Perangkat Lunak' di atas.
• WGS akan membuat server staging.
• Pada akhir fase project planning, apa yang harus sudah
disiapkan oleh Klien atau diketahui oleh Klien adalah:
o Menyediakan SSL (production)
o Menyediakan Domain Name (production)
o Memilih penggunaan server production (on-premise /
cloud)
o Menyediakan server terutama jika server on-premise
dan harus dibeli terlebih dahulu (production)
o Menyediakan mail account master untuk pendaftaran
3rd party (staging & production)

o Subscribe aplikasi 3rd party yang diperlukan (staging &

production)
o Menyediakan hardware penunjang / pendukung yang
sesuai dengan aplikasi yang akan dibangun jika
diperlukan dalam development
• Pada akhir fase project planning, apa yang akan disetujui
oleh kedua belah pihak, apa yang akan ditetapkan sebagai
batasan dari proyek adalah:
o Dokumen SRS dengan Use Case yang lengkap, Desain
Database, dan Desain UI
o Draft Dokumentasi Teknis
o Timeline dan pembagian Task
Development 4 bulan • WGS akan mengembangkan aplikasi berdasarkan
kebutuhan dan dokumen yang disetujui saat pre-
development
• WGS akan melakukan progress demo setidaknya pada akhir
sprint di server tes WGS. Deployment ke server staging
Klien akan bergantung pada persentase pembayaran yang
diterima.
• Klien akan melakukan tes kinerja aplikasi dan memberikan
umpan balik pada komponen yang sudah selesai.
• Milestone berdasarkan pada syarat pembayaran adalah:
Milestone #1 (4 minggu pengerjaan), Milestone #2 (8
minggu).
Proofing 5 hari • WGS akan melakukan uji coba secara internal untuk seluruh
proyek berdasarkan pada batasan yang sudah disetujui,
dokumen hasil dari uji coba ini adalah dokumen rencana uji.
• WGS akan memberikan draf Panduan Pengguna dan
dokumentasi teknis yang akan ditinjau oleh klien.
Final Demo 1 hari • WGS akan memberikan notifikasi kepada Klien untuk
melakukan demo akhir dan melakukan perubahan jadwal
dari seluruh periode yang tersisa bila perlu.
• Klien harus menandatangani dokumen yang mengakui
bahwa demo akhir sudah dilaksanakan, dan Klien dapat
memulai uji coba pada semua aspek dari aplikasi (tidak ada
penghambat, semua fungsionalitas dapat diuji).
Deployment 1 hari • WGS akan melakukan deploy aplikasi pada server staging
Klien dan/atau server production setelah BAST Final Demo
dan/atau Development completion ditandatangani.
• WGS akan memasang tool untuk backup / pemantauan
pada sistem produksi.
• WGS akan mengkonfigurasi aplikasi yang diperlukan.
• Hasil deployment pada fase ini disebut sebagai aplikasi
Alpha.

Training 1 hari • WGS akan memberikan notifikasi kepada klien untuk

mengikuti training.
• WGS akan memberikan training kepada klien dan
pengguna aplikasi.
• Semua pengguna aplikasi harus dikumpulkan pada satu
tempat untuk melakukan training.
UAT / Simulasi 8 hari • Klien dan pengguna aplikasi melakukan simulasi dan uji
coba pada aplikasi menggunakan data yang sesungguhnya.
• Klien harus menandatangani dokumen yang mengakui
bahwa simulasi sudah dilakukan dan semua feedback sudah
dilaporkan.
Finishing 8 hari • Klien sudah tidak melakukan uji coba.
• WGS akan melakukan patch pada aplikasi berdasarkan
semua feedback yang diberikan pada saat simulasi.
Closed Beta 8 hari • Klien akan melakukan uji coba ulang aplikasi dan
memberikan laporan feedback lanjutan jika ada.
• Semua feedback yang diberikan pada periode ini akan
diperbaiki oleh WGS selama periode Support.
• Klien menandatangani dokumen BAST UAT sebagai bukti
penyelesaian proyek.
• WGS akan memberikan seluruh dokumentasi kepada Klien.
• Hasil deployment setelah phase UAT ini disebut aplikasi
Beta.
Clean up & Cut 1 hari • Setelah Klien menandatangani dokumen BAST Go-Live,
off dan WGS sudah menerima 100% pembayaran, barulah
Klien diperbolehkan Go-Live, dan preparation Go-Live
dimulai.
• WGS akan menghapus semua data uji coba (clean up).
• Klien berhenti menggunakan system lama bila ada (cut off).
• WGS memberikan semua hasil akhir dan dokumentasi yang
telah disetujui.
Support 6 bulan • WGS akan menyediakan seorang penanggung jawab untuk
support.
• WGS akan menyediakan support / aplikasi pembuatan tiket.
• WGS membantu dalam memperbaiki isu.
• WGS akan melakukan patch pada aplikasi berdasarkan
feedback yang diberikan pada aplikasi.
Semua ruang lingkup proyek dari perangkat lunak ini telah dinyatakan dalam KAK ini dan telah dibaca
dan dipahami seluruh persyaratannya; bahwa semua pihak menyetujui KAK ini tanpa paksaan atau
tekanan apapun; bahwa semua pihak memahami hak masing-masing yang dimiliki; dan bahwa semua
pihak yang menandatangani KAK ini memiliki pemahaman penuh atas hak-hak yang dimiliki.

Para Pihak dengan ini menerima dan sepakat bahwa segala isi dari proposal yang dibuat oleh WGS terkait maksud
kerjasama yang akan dirintis antara WGS dengan Perusahaan merupakan hak dan milik dari WGS sepenuhnya yang
tidak dapat dimintakan pengembaliannya oleh Perusahaan.
Tanggal: 8 Februari 2021 Tanggal: 8 Februari 2021
Nama: Nama:
PT. Walden Global Services Klien:

TOR Example

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

TOR Example

Diunggah oleh

Hak Cipta:

Format Tersedia

Senin, 08 Februari 2021

TERMS OF REFERENCE (TOR)

KERANGKA ACUAN KERJA – PERANGKAT LUNAK

DAFTAR ISI ............................................................................................................................ 2

RAHASIA – DOKUMEN INI ADALAH MILIK WGS PAGE 2 OF 51

RAHASIA – DOKUMEN INI ADALAH MILIK WGS PAGE 4 OF 51

1 KALBE - E-TESTING FITUR PERANGKAT LUNAK

• CHP (Catatan Hasil Pemeriksaan)

Project ini akan mencakup pembuatan aplikasi sebagai berikut:

1. Aplikasi back-end berbasis web

Role yang akan dihandle oleh aplikasi antara lain:

1.2 APLIKASI BERBASIS WEB (BACK-END)

1.2.1 SEARCH, SORT, DAN FILTERING

1.2.2 CREATE, UPDATE, DELETE, VIEW

RAHASIA – DOKUMEN INI ADALAH MILIK WGS PAGE 5 OF 51

1.2.3 E- CHANGE CONTROL

1.2.4 LOGIN (REF ID : A.4, PG: 11)

1.2.5 LUPA PASSWORD

1.2.6 DASHBOARD E-TESTING (REF ID : A.5, PG: 12)

RAHASIA – DOKUMEN INI ADALAH MILIK WGS PAGE 6 OF 51

RAHASIA – DOKUMEN INI ADALAH MILIK WGS PAGE 7 OF 51

1.2.6.2 PEMBUATAN/PERUBAHAN MWQT (REF ID : A.8, PG: 15-21)

RAHASIA – DOKUMEN INI ADALAH MILIK WGS PAGE 8 OF 51

RAHASIA – DOKUMEN INI ADALAH MILIK WGS PAGE 9 OF 51

o Versi dari MWQT akan diatur oleh sistem.

1.2.7.1 REQUEST FOR APPROVAL (REF ID : A.9, PG: 21)

1.2.7.2 REVIEW & APPROVAL (REF ID : A.10, PG: 22-24)

RAHASIA – DOKUMEN INI ADALAH MILIK WGS PAGE 10 OF 51

RAHASIA – DOKUMEN INI ADALAH MILIK WGS PAGE 11 OF 51

RAHASIA – DOKUMEN INI ADALAH MILIK WGS PAGE 12 OF 51

RAHASIA – DOKUMEN INI ADALAH MILIK WGS PAGE 13 OF 51

1.2.9 WQT AKTIF (REF ID : B.4 – B.5, PG: 31-32)

1.2.10 PENGUJIAN SAMPLE (REF ID : B.6 – B.7, PG: 32-33)

RAHASIA – DOKUMEN INI ADALAH MILIK WGS PAGE 14 OF 51

• Data Hasil IPC ditampung di e-Testing.

1.2.11 PENGAMBILAN SAMPLE (REF ID : B.8 – B.10, PG: 33-34)

1.2.12 DASHBOARD PIC (REF ID : B.11 – B.15, PG: 34-40)

RAHASIA – DOKUMEN INI ADALAH MILIK WGS PAGE 15 OF 51

RAHASIA – DOKUMEN INI ADALAH MILIK WGS PAGE 17 OF 51

1.2.14 OOS/OOT (REF ID : C.2, PG: 43-44)

1.2.14.1 PEMILIHAN JENIS PENYIMPANGAN (REF ID : C.3, PG: 44)

1.2.14.2 E-FORM PELAPORAN OOS/OOT (REF ID : C.4 – C.9, PG: 45-46)

RAHASIA – DOKUMEN INI ADALAH MILIK WGS PAGE 18 OF 51

• Nomor OOS dibedakan berdasarkan OOS kimia, fisika dan mikrobiologi

1.2.14.3 E-FORM INVESTIGASI (REF ID : C.10 – C.16, PG: 46-48)

RAHASIA – DOKUMEN INI ADALAH MILIK WGS PAGE 19 OF 51

1.2.15 PENGUJIAN ULANG

1.2.15.1 DASHBOARD PENGUJIAN ULANG/RETESTING (REF ID : D.2, PG: 52)

1.2.15.2 LIST MATERIAL (REF ID : D.3, PG: 52)

1.2.15.3 NOTIFIKASI (REF ID D.4, PG: 52-53)

RAHASIA – DOKUMEN INI ADALAH MILIK WGS PAGE 20 OF 51

• Notifikasi akan berada didalam sistem e-Testing.

1.2.15.4 PEMILIHAN MATERIAL (REF ID : D.5, PG: 53)

1.2.15.5 GENERATE WQT (RM/PM) (REF ID : D.7, PG: 53-54)

1.2.15.6 PENGAMBILAN SAMPLE (REF ID : D.8 – D.10, PG: 54-55)

1.2.15.7 PROSES PERPANJANGAN TANGGAL PENGUJIAN ULANG DAN DISPOSISI STATUS

1.2.16 PENGUJIAN BAHAN AWAL

1.2.16.2 NOTIFIKASI (REF ID : E.2, PG: 59)

RAHASIA – DOKUMEN INI ADALAH MILIK WGS PAGE 22 OF 51

1.2.16.3 DASHBOARD (REF ID : E.4, PG: 60)

1.2.16.4 LIST MATERIAL (REF ID : E.5, PG: 61)

1.2.16.6 GENERATE WORKSHEET QC TESTING (REF ID : E.8, PG: 61-62)

RAHASIA – DOKUMEN INI ADALAH MILIK WGS PAGE 23 OF 51

• Field parameter pengujian tersebut bersifat mandatory.