11
17.4 Pengumpulan informasi Berbagai sumber informasi, internal dan eksternal, yang melayani Proses CAPA adalah sangat luar biasa. Mengikuti dikotomi istilah internal / eksternal ,maka terdapat empat informasi utama dari sumber informasi internal : 1. Proses pengembangan software 2. Maintenance software 3. Infratruktur SQA 4. Prosedur manajemen kualitas software Adapun sumber informasi dari eksternal, adalah: 1. Komplain pelanggan 2. Statistik pelayanan pelanggan (customer service) 3. Kritik dan saran pelanggan Klasifikasi ini berkaitan dengan CAPA, yang disajikan lebih rinci di kerangka berikut: Proses pengembangan software laporan manajemen risiko Software laporan review Desain Laporan Pemeriksaan laporan Walkthrough Laporan pendapat Ahli ' ulasan Uji Coba Laporan khusus pada kegagalan pembangunan dan keberhasilan

capa1

Embed Size (px)

DESCRIPTION

industri

Citation preview

Page 1: capa1

17.4 Pengumpulan informasiBerbagai sumber informasi, internal dan eksternal, yang melayani Proses CAPA adalah sangat luar biasa.

Mengikuti dikotomi istilah internal / eksternal ,maka terdapat  empat informasi utama dari  sumber informasi

internal :

1.     Proses pengembangan software

2.     Maintenance software

3.     Infratruktur SQA

4.     Prosedur manajemen kualitas software

Adapun sumber informasi dari eksternal, adalah:

1.     Komplain pelanggan

2.     Statistik pelayanan pelanggan (customer service)

3.     Kritik dan saran pelanggan

Klasifikasi ini berkaitan dengan CAPA, yang disajikan lebih rinci di kerangka berikut:

Proses pengembangan software

         laporan manajemen risiko Software

         laporan review Desain

         Laporan Pemeriksaan

         laporan Walkthrough

         Laporan pendapat Ahli '

         ulasan Uji Coba

         Laporan khusus pada kegagalan pembangunan dan keberhasilan

         Proposal disarankan oleh anggota staf.

Pemeliharaan Software

         Aplikasi statistik Pelanggan

Page 2: capa1

         Permintaan perubahan Software diprakarsai oleh aplikasi pelanggan

         Permintaan perubahan Software diprakarsai oleh staf pemeliharaan

         Laporan khusus pada kegagalan pemeliharaan dan keberhasilan

         Proposal disarankan oleh anggota staf.

Kelas infrastruktur SQA sumber

         Laporan audit mutu internal

         Laporan audit kualitas eksternal

         Kinerja tindak lanjut dari staf yang terlatih dan bersertifikat

         Proposal disarankan oleh anggota staf.

Perangkat Lunak kualitas prosedur manajemen kelas sumber

         laporan kemajuan Proyek

         metrik kualitas laporan Software

         laporan biaya kualitas Software

         Proposal anggota staf.

Page 3: capa1

  

Klasifikasi alternatif sumber informasi (seperti yang ditunjukkan pada Gambar 17,1) membedakan antara 

proses   pengembangan   terkait   dengan  produk   serta  infrastruktur   terkait   (termasuk   manajerial   dan 

pemeliharaan) sumber informasi.  Analisis akumulasi informasi seperti yang dilaporkan dalam berbagai 

dokumen merupakan subyek dari bagian berikutnya.

17.5 Analisis informasi yang terkumpulOperasi rutin dari proses CAPA diharapkan dapat menciptakan aliran besar dokumen yang berkaitan

dengan berbagai informasi.

Analisis meliputi:

Page 4: capa1

Penyaringan Informasi dan mengidentifikasi perbaikan yang potensial.Dokumen yang diterima dari berbagai sumber informasi dan telah dikaji oleh para profesional untuk

mengidentifikasi peluang potensial CAPA. Tahap ini meliputi perbandingan dokumen dari jenis yang sama

yang diterima dari berbagai unit serta perbandingan dokumen dari berbagai jenis terkait dengan kasus

yang sama.

Analisis Pengembangan potensial. Upaya diarahkan untuk menentukan:

         Jenis yang diharapkan dan tingkat kerusakan akibat kesalahan diidentifikasi.

         Penyebab kesalahan. Penyebab khasnya adalah ketidakpatuhan terhadap pekerjaan instruksi dan

prosedur, pengetahuan teknisyang tidak memadai, ekstrim waktu dan / atau tekanan anggaran karena

perkiraan yang kurang realistis, dan kurangnya pengalaman dengan tool pengembangan baru.

         Perkiraan tingkat kedalaman luasnya organisasi yang merupakan kesalahan potensial masing-masing

Jenis. Informasi ini diperlukan untuk memperkirakan total kerusakan yang diharapkan dan untuk

menentukan prioritas setiap kasus kesalahan.

Menyusun umpan balik tentang isi dan keteraturan informasi yang diterima dari sumber-sumber informasi yang ditunjuk.Dua persyaratan yang berlawanan akan mempengaruhi respon pada tahap ini –analisis komprensif dari

kumpulan informasi yang  saling bertentangan dengan kebutuhan untuk bereaksi dengan cepat untuk

merespon suatu kesalahan. Resolusi konflik ini terletak pada organisasi dan metode.

Sebuah tim profesional yang ditugaskan untuk menangani informasi yang masuk tanpa delay harus dibuat

segera. Tim ini akan menetapkan prioritas untuk menangani solusi kesalahan yang telah teridentifikasi,

dimana untuk kasus dengan prioritas rendah akan ditunda atau bahkan tidak dilakukan penanganan sama

sekali.

Page 5: capa1

17.6.1 Pengembangan solusiSolusi untuk mengidentifikasi penyebab dari kesalahan sistem perangkat lunak yang berulang diperlukan

untuk:

1.     Menghilangkan terulangnya jenis kesalahan yang telah terdeteksi

2.     Kontribusi peningkatan efisiensi dengan memungkinkan produktivitas yang lebih tinggi dan jadwal yang

lebih singkat.

Beberapa petunjuk sebagai solusi yang biasanya dilakukan:

         Memperbarui prosedur yang terkait. Perubahan bisa mengacu  kepada sekumpulan prosedur,dari segala

sesuatu yang terkait dengan tahapan kerja yang spesifik dari pengembangan perangkat lunak atau

pemeliharaannya (misalnya, perubahan gaya komentar software, perubahan prosedur review klausul

kontrak yang berhubungan dengan proposal untuk proyek kecil) dengan prosedur yang bersifat umum

(misalnya perubahan prosedur perekrutan karyawan, perubahan jumlah maksimum dan minimum peserta

dalam ulasan desain formal).

         Perubahan disini prakteknya, termasuk memperbarui instruksi kerja yang relevan (jika memang ada).

         Beralih ke alat pengembangan yang lebih efektif dan tahan terhadap kesalahan yang sudah terdekteksi

         Pengembangan dalam pelaporan, termasuk perubahan isi laporan, frekuensi laporan dan penyerahan

laporan. Arahan ini bertujuan agar kesalahan dapat teridentifikasi lebih dini.

         Pelaksanaan training, retraining dan pembaharuan staff. Arah ini diambil hanya dalam kasus-kasus ketika

kekurangan pelatihan yang sama ditemukan di beberapa tim.

Perlu dicatat bahwa:

         Dalam banyak kasus, solusi yang dianjurkan menggabungkan beberapa item tindakan,dari satu tindakan

atau beberapa tindakan.

         Mengubah dan memperbarui prosedur dan instruksi kerja perlu dibahas dan disetujui oleh badan yang

ditugaskan untuk pengembangan dan pemeliharaan.

         Kembali ke contoh kita, "3S" kasus disini menampilkan enam contoh CAPA:

         Memperbarui prosedur yang ada (rekomendasi (1), (2), (3) dan (6))

         Penggantian alat pengembangan yang mempunyai efisiensi rendah dan tidak efektif dengan alat yang

lebih baik (rekomendasi  point(4))

         Peningkatan dalam pengoperasian alat infrastruktur SQA (rekomendasi point (5)).

Page 6: capa1

Untuk memperjelas titik yang dibuat, dua contoh berikut mungkin akan membantu.

Contoh A: Prosentase yang tinggi  dari beberapa defect yang parahAnalisis metrik kualitas perangkat lunak untuk Departemen Pengembangan dari "Peak Performance

Software Ltd" mengidentifikasi proporsi yang tinggi dari besarnya perangkat lunak yang cacat dengan

parah dalam proyek yang diselesaikan oleh dua tim dari enam tim. Disini ditemukan bahwa tuntutan

sumber daya tim untuk memperbaiki cacat jauh lebih tinggi dibandingkan dengan tim lain.

Analisis ini didasarkan pada informasi terdokumentasi terkait dengan dua tim ini, saat ini para mantan tim

proyek ', di samping proyek-proyek yang dilakukan oleh empat tim lainnya yang dianggap  "sehat". Temuan

menunjukkan bahwa karakteristik umum untuk sebagian besar modul yang rusak adalah kehadiran

algoritma dari kompleksitas sedang hingga kompleksitas tinggi. Pertanyaan yang berkaitan dengan tool

SQA yang diterapkan oleh semua tim mengungkapkan perbedaan yang berarti dalam sejumlah aplikasi

yang diperiksa, terutama dalam analisis dan tahap desain. Sementara itu tim "sehat" memperlakukan

kegiatan inspeksi  sebagai prosedur standar yang lebih-atau-kurang tergantung kerumitan modul ,

sedangkan tim lain yang menggunakan kegiatan inspeksi lebih rendah. Solusi CAPA

merekomendasikan  untuk memperkenalkan definisi jenis-jenis modul yang memerlukan pemeriksaan

dalam inspeksi instruksi kerja.

Contoh kedua mengilustrasikan bagaimana proses CAPA dapat menghasilkan temuan dan rekomendasi

yang tak terduga.

Contoh B: Kenaikan panggilan help desk yang membutuhkan layanan di tempat pelangganSebuah perusahaan pemograman yang sempurna" secara teratur mengoperasikan dua tim help desk

untuk mendukung pengguna dari dua produk perangkat lunak yang paling populer: Tim 1 mengkhususkan

diri dalam titik penjualan (POS) paket, Tim 2 dalam paket akuntansi.

Manajemen Unit Help Desk merumuskan beberapa metrik kualitas yang baru untuk mendukung kontrol

efektivitas dan efisiensi tim 'Metrik baru ini menekankan pengendalian dari beberapa pelayanan yang

dilakukan di lokasi pelanggan, dikarenakan biaya tinggi pelayanan, dan terus melacak dari dua variabel

(metrik), yaitu prosentase dari kunjungan pelanggan dan waktu rata-rata per kunjungan teknisi ke lokasi.

Laporan metrik triwulan untuk kedua tim help desk ditunjukkan pada Tabel 17.1.

Page 7: capa1

Laporan untuk kuartal keempat memicu sinyal peringatan kepada manajemen perusahaan. Sedangkan

Tim 2 menunjukkan stabilitas dalam kinerjanya, di sisi lainnya sebuah perubahan yang berbahaya

teredeteksi dalam kinerja Tim 1.

Pihak manajemen sangat prihatin dengan peningkatan yang berarti dari persentase kunjungan pelanggan

di lokasi dan waktu rata-rata per kunjungan teknisi ke lokasi. Tim perbaikan dan pencegahan (tim CAPA)

dipimpin oleh seorang anggota staf unit SQA yang ditunjuk. Tim CAPA mengadakan tiga pertemuan

panjang yang ditujukan untuk mewawancarai pemimpin tim help desk, meninjau contoh laporan kunjungan

pelanggan mereka ke lokasi dan memeriksa laporan rinci statistik bulanan. Tim juga mengamati tim “help

desk” di tempat kerja selama satu sore.

Tim CAPA menemukan bahwa semenjak tahun sebelumnya terdapat salah satu operasi yang konservatif

untuk Tim 2, menampilkan beberapa regresi dalam efisiensi mereka, dalam kurun satu tahun

terdapat  perubahan besar dalam operasional dari Tim 1.Selama kuartal pertama dan kedua, tim telah

menginvestasikan upaya yang berarti dalam perbaikan user interface dari paket POS dan menambahkan

beberapa hal yang membantu pesan kesalahan. Selain itu, user manual yang telah direvisi diterbitkan.

Semua perbaikan ini termasuk dalam Versi baru 6.4 yang menggantii Versi 6,3 dari paket POS yang telah

melayani perusahaan selama 20 bulan terakhir. Versi 6.4 telah dipasang oleh sebagian besar pengguna

selama kuartal ketiga.

Analisis statistik operasi bulanan mengungkapkan ternyata  laporan perkuartal yang digunakan saat ini

adalah tidak benar. Tanpa diduga, masalah segera menjadi jelas dalam dua kuartal terakhir Tim 1 telah

benar-benar mencapai pengurangan substansial dari  jumlah effort help desk, yang diukur dalam jam

layanan help desk per pelanggan. Selain itu, penurunan dramatis dalam jumlah panggilan pengguna yang

diamati, jelas sebagai akibat dari lebih user friendly dan lebih handalnya dari  versi baru paket aplikasi.

Kenaikan rata-rata waktu yang dihabiskan pada pelanggan Kunjungan situs adalah karena persentase

yang lebih tinggi dari layanan sekarang diberikan kepada pelanggan baru.

Tim CAPA berdasarkan kesimpulan hasil revisi, Laporan kuartalan yang diperpanjang, disajikan pada

Tabel 17.2. Penerapan dari  revisi laporan help desk per triwulan untuk Tim 2 menunjukkan angka

penurunan konstan dalam efisiensi dan efektivitas layanan HD tim.

Page 8: capa1

Dua tindakan korektif yang diusulkan oleh tim CAPA:

(1) Untuk mengganti laporan kuartalan yang saat ini digunakan dengan yang lebih komprehensif,

berdasarkan pada baris Tabel 17.2.

(2) Sebuah penyelidikan praktek dilaksanakan oleh Tim 2 disarankan untuk mencapai perbaikan

substansial dalam kinerja tim.

17.6.2 Pelaksanaan proses CAPAImplementasi solusi CAPA bergantung pada instruksi yang tepat dan seringnya pelatihan namun  paling

banyak tergantung pada  kerjasama unit dan individu yang terkait.

Oleh karena itu, keberhasilan pelaksanaan mengharuskan anggota staff yang ditargetkan diyakinkan

terhadap kelayakan solusi yang ditawarkan.

Tanpa kerjasama, kontribusi dari CAPA maka dapat menimbukan ketidak beresan.

Page 9: capa1

17,7 Tindak Lanjut kegiatanTiga tugas pokok tindak lanjut diperlukan untuk memfungsikan korektif dan proses tindakan pencegahan

dalam setiap organisasi:

1.     Tindak lanjut alur pengembangan dan pemeliharaan terhadap catatan CAPA . Hal ini memungkinkan

umpan balik yang mengungkapkan kasus tidak adanya pelaporan serta pelaporan berkualitas rendah,

yang mana terdapat rincian penting yang hilang atau tidak akurat. Jenis tindak lanjut dilakukan terutama

melalui analisis informasi aktivitas jangka panjang, yang menghasilkan umpan balik kepada sumber-

sumber informasi CAPA.

2.     Tindak lanjut penerapan CAPA. Kegiatan ini dimaksudkan untuk menunjukkan apa saja tindakan-tindakan

yang dirancang berupa:

         kegiatan pelatihan

         penggantian dari tool-tool development

         perubahan prosedur (setelah persetujuan)

semua telah dilaksanakan . Umpan balik yang memadai dikirimkan ke badan-badan yang bertanggung

jawab untuk pelaksanaan tindakan perbaikan dan pencegahan.

3.     Tindak lanjut hasil CAPA. Tindak lanjut hasil yang nyata dari metode perbaikan ',seperti yang diamati oleh

tim proyek dan unit organisasi, memungkinkan penilaian sejauh mana tindakan korektif atau preventif telah

mencapai hasil yang diharapkan. Umpan balik terhadap hasil dikirimkan ke pengembang metode

perbaikan '. Dalam kasus kinerja rendah, maka diperlukan formulasi dari tindakan korektif yang direvisi

atau yang baru, ini merupakan tugas yang dilakukan oleh tim CAPA

Jelas, kegiatan tindak lanjut rutin  yang langsung memeriksa informasi yang masuk dan memulai alur yang

memadai dari umpan balik adalah link penting dalam kegiatan-kegiatan berantai CAPA.

17,8 Pengorganisasian untuk tindakan preventif dan korektifKinerja yang tepat dari kegiatan ini CAPA tergantung pada keberadaan unit organisasi ini yang permanen

serta tergantung dari banyaknya partisipasi  dari tim  ad hoc.

Organisasi inti ini, umumnya dikenal sebagai komite Dewan Corrective Action (CAB), meskipun mungkin

memiliki judul lain dalam organisasi yang berbeda, Dewan mempromosikan penyebab CAPA dalam

organisasi. Tugasnya meliputi: