Langkah panjang Validasi Komputer? Tergantung seberapa besar cakupan komputerisasi dalam sebuah perusahaan sih sebenarnya. Tapi biasanya, sebuah perusahaan terutama farmasi bila sudah mengalokasikan investasinya pada sistem komputerisasi dan menjadikannya sebagai kebijakan strategis, maka cakupan komputerisasi itu akan diterapkan begitu luas. Apalagi di jaman kekinian, mungkin sudah akan tertinggal bila masih saja mempertahankan kegiatan administrasi dan manajemen industri dengan cara-cara 100% manual.

Dan cakupan itu tentunya akan sampai juga pada hal-hal yang berpotensi mengancam mutu. Itulah mengapa evolusi ide Validasi Komputer menjadi sebuah keharusan kini. Terutama terkait hal-hal pemastian mutu dan hal-hal yang bisa mengancam keselamatan pasien. 

Tapi mengapa itu menjadi sebuah jalan panjang? Pendapat saya mungkin terlalu prematur, tapi hampir semua yang pernah saya ajak diskusi di sana-sini, terutama dengan rekan-rekan se-profesi di beberapa perusahaan farmasi di Indonesia, tantangannya hampir sama. Dari sisi Software Developer, entah itu dikembangkan internal ataupun disubkon ke perusahaan pengembang software, perspektif yang dibawa menjadi hal utama selalu hal-hal terkait fungsionality, yang bisa jadi apa yang terlihat dipermukaan, misal di tampilan layar komputer, hardware konfigurasi, dan sebagainya, akan selalu tampak indah dan mudah bagi orang awam. Sementara sang pemrogram yang berkeringat berkerut dahi di depan layar merancang segala kerumitan dibalik semua yang indah itu terkadang tidak dengan mudah untuk dikomunikasikan menjadi sebuah penjelasan yang bisa langsung dipahami. Sementara dari sisi Validator, bahkan yang memiliki background engineering umum pun kadang masih harus terengah-engah memetakan arsitektur sebuah software, membuat rincian cakupannya, untuk kemudian menganalisa potensi risiko, sampai membuat detail challenge-list yang diperlukan sebagai pembuktiannya.

Kesabaran dalam komunikasi dua pihak itu yang dibutuhkan! Saling menggali informasi dengan pikiran terbuka yang terkadang belum tentu setiap individu memiliki bekal kebiasaan seperti itu. Jadilah kemudian rencana Validasi Komputer yang sangat lama nggak jadi-jadi, sekian lama hanya pada tahap rencana saja sulit beranjak ke tahap eksekusi, yang pada akhirnya yang timbul seperti separuh 'menghibur diri' dengan melakukan hal secara 'asal ada dulu'.

Validasi Komputer ini biasanya akan merujuk kepada pembuktian dua hal, yaitu: kesesuaiannya dengan kebutuhan (functionality), dan kesesuaiannya dengan keharusan atau regulasi (quality).

Kita lihat dulu hal yang pertama. Mendefinisikan kebutuhan terhadap fungsi sebuah program komputer sendiri bisa jadi adalah sebuah pekerjaan yang panjang dan lama. Dari sisi pengguna mungkin berawal dari hal yang sederhana, misal saya ingin program komputerisasi yang mengolah bahan baku, itemnya, masuk, keluar, status, oleh siapa, tanggal berapa. Sepertinya sederhana, tapi program harus bisa mengantisipasi, bagaimana bila itemnya bisa mencapai ribuan? Bagaimana kalau penggunanya bisa sampai puluhan yang mengakses dalam waktu yang sama? Bagaimana bila saya ingin men-strategikan beda tiap item, ada yang FIFO, FEFO? Dan bisa jadi ada puluhan 'bagaimana bila' lagi yang harus digali sehingga sang pemrogram memiiki gambaran utuh atas kebutuhannya. Yang sederhana bisa menjadi tak sederhana lagi.

Kemudian dari sang pemrogram harus juga bisa mengkomunikasikan apa yang bisa, apa yang mungkin bisa, apa yang pasti tidak bisa pada cakupan program. Dan itupun belum tentu bisa disampaikan dengan bahasa yang mudah dipahami oleh para pengguna program. Bisa jadi di ujung pembicaraaan akan masih ada hal-hal di kepala pengguna yang tidak tersampaikan, dan ada hal-hal di pikiran pemrogram yang sulit dikomunikasikan. Dan rincian kebutuhan yang mungkin belum lengkap itu tetap harus menjadi acuan untuk membuat protokol pembuktian tentang kesesuaian dengan kebutuhannya yang harus disusun sang validator, yang juga orangnya belum tentu si pengguna itu sendiri.

Lalu tentang keharusannya? Ada definisi-definisi yang disebut Electronic Recording, Audit Trail, Security, Password Management, Electronic Signature, saya akan bicarakan hal ini di artikel-artikel berikutnya. Yang harus dikonfirmasikan dulu dengan pembuat program untuk bisa menterjemahkannya menjadi protokol pengujian kesesuaian terhadap regulasinya.

Jalan panjang, bagaimana pun juga itu harus diawali. Bagi owner industri yang punya duit cukup untuk membeli program jadi dari pengembang besar yang bisa menyediakannya komplit termasuk tahapan validasinya, mungkin itu yang akan dipilih, walaupun pada kenyataanya tetap saja akan ada pernak-pernik detail penyesuaian yang juga harus dilakukan.

Tapi bagi pelaku profesi validasi seperti saya, akan selalu tampak seperti sebuah tantangan yang menggairahkan.

 

Pitoyo Amrih

 

Ada sebuah perusahaan fiktif bernama PT MAJU. Perusahaan ini memproduksi air mineral dalam kemasan gelasplastik. Mesin yang dimiliki perusahaan ini adalah mesin pembentuk gelas plastik sekaligus mengisi air mineral, sebanyak dua unit.

Bulan ini pesanan begitu meningkat. Bagian pemasaran yang telah berhasil melakukan promosi membuat bagian produksi jungkir-balik selama dua puluh empat jam menjalankan mesinnya untuk mengejar permintaan bagian pemasaran. Dan sudah terlihat di depan mata, bulan depan pesanan bagian pemasaran naik 30 % dari bulan sekarang. Sementara bulan ini mesin telah jalan siang malam, bahkan minggu pun masuk untuk mengejar kekurangannya.

“Gila! Harus segera saya usulkan membeli satu unit mesin lagi untuk mengejar permintaan bulan depan,” teriak Pak Joni, sang kepala produksi. “Dan awal bulan depan mesin itu sudah di sini..!” imbuhnya.   ...selengkapnya

Bookmark This

Follow Us

Powered by CoalaWeb

 

KupasPitoyo, KumpulanTulisan Pitoyo Amrih, yang juga berbicara tentang Pemberdayaan Diri, ..pemberdayaan berkesinambungan bagi diri sendiri, keluarga, dan bangsa... khususnya melalui budaya..  this link is under construction..

Pitoyo Amrih.... terlibat aktif dalam perumusan penerapan konsep-konsep TPM (Total Productive Maintenance) di perusahaan tempatnya bekerja. Juga pernah memimpin kajian dan penerapan rumusan OEE (Overall Equipment Effectiveness) yang bisa.....  ...selengkapnya