Prinsip Pareto

Nama : Putri Pertiwi

NIM    : 41811110123

Prinsip Kerja Pareto Yang Diimplementasikan Dalam RPL

Pengertian Implementasi

Defenisi Implementasi menurut Kadir, A dalam bukunya “Perancangan Sistem Informasi” Andi , Yogyakarta, 2003.

“Implementasi adalah kegiatan yang dilakukan untuk menguji data dan menerapkan sistem yang diperoleh dari kegiatan seleksi”.

Implementasi merupakan salah satu unsur pertahapan dari keseluruhan pembangunan sistem komputerisasi, dan unsur yang harus dipertimbangkan dalam pembangunan sistem komputerisasi yaitu masalah perangkat lunak (software), karena perangkat lunak yang digunakan haruslah sesuai dengan masalah yang akan diselesaikan, disamping masalah perangkat keras (hardware) itu sendiri.

Implementasi dari perangkat lunak mencakup kebutuhan sistem, instalasi, tampilan output dari perangkat lunak dan hasil proses eksekusi dari perangkat lunak.

 

PRINSIP PARETO

Vilfredo Pareto (1848-1923) terkenal dengan Pareto Principle, atau juga dikenal sebagai aturan 80/20 dengan melakukan 20% dari pekerjaan bisa menghasilkan 80% manfaat dari pekerjaan itu. Aturan 80/20 dapat diterapkan pada hampir semua hal, seperti:

·           80% dari keluhan pelanggan muncul dari 20% dari produk atau jasa.

·           80% dari keluhan pelanggan muncul dari 20% dari produk atau jasa.

·           80% dari keterlambatan jadwal timbul dari 20% dari kemungkinan penyebab penundaan.

·           20% dari produk atau jasa mencapai 80% dari keuntungan.

·           20% dari tenaga penjualan memproduksi 80% dari pendapatan perusahaan.

·           20% dari cacat sistem menyebabkan 80% masalah.

        Prinsip Pareto untuk seorang manajer proyek adalah mengingatkan untuk fokus pada 20% hal-hal yang materi, tetapi tidak mengabaikan 80% masalah. Dengan menggunakan anturan80/20 maka kita dengan mudah melakukan tindakan perbaikan berkelanjutan karena menjadi fokus memperbaiki 20% penyebab masalah yang biasanya tersembunyi atau disembunyikan. Prinsip Pareto digunakan secara luas dalam kegiatan kendali mutu untuk menangani kerangka proyek; proses program; kombinasi pelatihan, proyek dan proses, sehingga sangat membantu dan memberikan kemudahan bagi para pekerja dalam meningkatkan mutu pekerjaan. Selain itu dapat digunakan untuk membandingkan kondisi proses, misalnya ketidaksesuaian proses, sebelum dan setelah diambil tindakan perbaikan terhadap proses. Berikut Hukum Pareto dalam bentuk visual:

digunakan secara luas dalam kegiatan kendali mutu untuk menangani kerangka proyek; proses program; kombinasi pelatihan, proyek dan proses, sehingga sangat membantu dan memberikan kemudahan bagi para pekerja dalam meningkatkan mutu pekerjaan.

Sistem Pareto Dalam Kaitannya Dengan RPL

Dalam ilmu komputer dan teori kontrol rekayasa seperti untuk konverter energi elektromekanis, prinsip Pareto dapat diterapkan untuk upaya optimasi.  Sebagai contoh, Microsoft mencatat bahwa dengan menetapkan atas 20% paling melaporkan bug, 80% dari kesalahan dan crash akan dihilangkan.

Ø  Prinsip Pareto berlaku untuk pengujian perangkat lunak, maksudnya dari 80% kesalahan yang ditemukan selama pengujian dapat ditelusuri sampai 20% dari semua modul program. 

Dalam pengembangan perangkat lunak proses yang khas adalah bahwa pengumpulan persyaratan, persyaratan review, desain, desain review, coding, kode review, pengujian komponen, pengujian integrasi, rilis, dan pemeliharaan. Singkatnya, proyek mulai dengan satu set persyaratan, dan kemudian pergi melalui serangkaian perbaikan dimana spesifikasi asli dibandingkan dengan produk akhir untuk kelengkapan dan kebenaran dan terhadap penggunaan dunia nyata untuk perbaikan tambahan. Selama  revisi, jika persyaratan dari proses pembangunan mengikuti distribusi Pareto, maka beberapa isu kunci akan menampakkan diri dan perlu ditangani pada setiap revisi baru. Persyaratan lama akan memudar , dan yang baru akan muncul dengan konteks mereka sendiri .

Praktis pengalaman memberitahu kita bahwa pada awal proyek perangkat lunak masalah tersebut mencakup isu-isu tersebut pada platform pilihan, bahasa implementasi, database model data, modus akses dan fungsi utama dari aplikasi. Seiring waktu, penyempurnaan lanjutan dapat memperkenalkan persyaratan yang membahas bagaimana aplikasi bekerja untuk kelompok tertentu pengguna, atau dalam konsep dengan aplikasi eksternal lainnya.

Pertambahan Manfaat Open Source :

Perancang sering menggunakan prinsip pareto dalam pengelolaan  teknik desain dan pengembangan . Bahwa 80 % dari proyek mudah dibandingkan dengan yang 20 % terakhir. Lebih khusus lagi dalam proses formal prioritas persayaratan menggunakan analisis pareto, setiap persyaratan yang unik diberi peringkat sebagai persentase dari seluruh proyek. Kebutuhan individu tersebut kemudian disajikan dalam grafik batang dari yang paling signifikan.

 

Perusahaan perangkat lunak seperti Microsoft memahami hal ini, dan desain untuk produk yang membahas 80 persen dari persyaratan, meninggalkan 20% terakhir sebagai kustomisasi oleh pengguna akhir. Sebagian besar aplikasi saat ini telah dirancang untuk mencakup beberapa bentuk penyesuaian atau diperpanjang termasuk pengaturan preferensi pengguna, bahasa scripting atau API untuk ekstensi kustom menggunakan bahasa yang lebih tradisional. 

Ada lima  cara utama prinsip dapat diterapkan untuk pengembangan perangkat lunak dan kualitas perangkat lunak :

1. mengidentifikasi cacat yang paling sering terjadi sehingga mereka bisa diperbaiki. Seperti kata J.M. Juran, target banyak, bukan sedikit.  waktu dan energi untuk memperbaiki cacat ini akan memiliki keuntungan terbesar atas investasi. 
2. Mengidentifikasi cacat paling mahal berdasarkan biaya untuk memperbaiki mereka atau biaya yang dikeluarkan ketika mereka terjadi. Cacat serius yang sistem crash pengguna atau menyebabkan pengguna untuk kehilangan semua data yang paling parah, dan ini adalah cacat Anda harus menargetkan.
3. Identifikasi kelas yang paling umum dari kesalahan. Apakah sebagian besar kesalahan hasil dari kesalahan pengetikan? Apakah sebagian besar kesalahan logis? Apakah sebagian besar cacat pada antarmuka perangkat lunak? Identifikasi jenis yang paling umum dari kesalahan dan memfokuskan upaya kualitas perangkat lunak, debugging dan pengujian di daerah itu. 
4. Menggunakan prinsip Pareto untuk mengidentifikasi ketika tingkat kecacatan telah turun di bawah titik ketika itu bernilai waktu dan usaha untuk terus mencari cacat. Banyak model pengembangan perangkat lunak, seperti model kualitas perangkat lunak yang menggunakan pembibitan untuk menghasilkan perkiraan mengenai jumlah cacat aplikasi perangkat lunak . Anda mungkin mengatakan masih ada beberapa cacat tersisa di kode. Bila Anda menghentikan pengujian? Bila Anda telah menemukan setidaknya 85% dari perangkat lunak cacat diprediksi, pengujian perangkat lunak dapat menurunkan sementara bug besar atau bug yang paling sering terjadi adalah tetap. Ketika 90% atau lebih dari perkiraan jumlah bug yang ditemukan, mungkin tidak lagi efektif.
5. Prioritaskan permintaan perubahan perangkat lunak dan perangkat tambahan berdasarkan permintaan dan kebutuhan. Pilih untuk membuat perubahan yang mewakili 80% dari keluhan pengguna, bukan yang paling mudah untuk menerapkan atau diminta oleh klien yang paling menuntut.

IMPLEMENTASI ENTEPRISE SISTEM

       Enterprise system adalah  sistem berbasis software untuk membantu pengelolaan sistem informasi pada suatu organisasi dengan skala besar. Skala besar berarti volume transaksi yang besar, concern terhadap kualitas informasi yang tinggi, mengintegrasikan berbagai proses bisnis, lintas bidang (horisontal) maupun lintas strata (vertikal). Contoh dari ES adalah ERP (Enterprise Resource Planning) atau e-Business secara umum, e-Government, dan ingrated software lainnya.

       Mengimplementasikan ES tidak mudah, atau setidaknya memilki strategi yang berbeda dengan sistem lain yang terbatas ruang lingkupnya, penggunanya dan tidak terpadu. Implementasi di sini bermakna bahwa software telah dapat digunakan dan bisa memberikan value bagi penggunanya sesuai tujuan pemanfaatan software tsb. Implementasi ini bisa dilakukan secara internal organisasi (oleh divisi IT/MIS) atau dengan pihak eksternal dalam kerangka proyek dan terikat legalitas berbentuk kontrak.

Implementator sebagai pihak eksternal yang melakukan implementasi dan klien sebagai organisasi yang diimplementasikan softwarenya.

       Implementasi ES berbeda dengan implementasi software berskala kecil atau yang penggunanya tunggal seperti MS Word, Database Rental VCD atau website, meskipun produknya sama-sama software yang berjalan di atas server dan membutuhkan konektivitas. Tentu nanti ada strategi yang berbeda, metode pemilihan bahan yang berbeda, tahapan yang berbeda, standar-standar tertentu, dst. Demikian pula dalam konteks software, bisa dipilah berdasar cakupan penggunaannya, bisa dilihat juga dari jenisnya (generik dan customized), yang masing-masing punya strategi implementasi yang berbeda. SE berkaitan dengan pengelolaan sistem informasi, yang tidak hanya bicara teknologi saja, tapi berkaitan dengan proses bisnis, struktur organisasi dan manusianya.

       Pola pikir ”developer” adalah menganggap suatu problem bisa selesai dengan solusi berbasis software yang baik dan tepat. Tapi apakah cukup seperti itu? Dalam membangun solusi, ya itu cukup, tapi belum tentu menjamin kesuksesan implementasi. Pola pikir developer cenderung berfokus pada analisis dan development tidak pada implementasinya. Padahal sukses tidaknya proyek software, baik buruknya reputasi implementator, seringkali orang luar melihat pada keberhasilan implementasinya dan value yang didapatkan klien. ES untuk organisasi dengan puluhan divisi, ribuan orang, puluhan kepentingan, dan mungkin ratusan konflik. Apalagi jika software yang kita implementasikan bukan sekedar supporting tools tapi adalah core dari bisnis itu sendiri (konsep e-business). Cara implementasi dengan pola pikir seperti ini hanya akan menghasilkan solusi dan software yang bagus, tapi tidak optimal dan memberikan value untuk organisasi tsb, atau bahkan malah tidak pernah akan digunakan.

       Implementator tidak bisa memposisikan diri sebagai project manager pada sebuah proyek yang berkaitan langsung dengan proses bisnis internal klien. Seorang project manager harus mampu mengelola semua resource berkaitan dengan proyek. Kadang kita tidak menyadari bahwa sebagaian besar resource dari proyek software justru berada di sisi organisasi klien. Sementara, project manager seharusnya memiliki akses ke seluruh resource tersebut, karena jika tidak, itu bukan project manager namanya.

       Dalam kasus ini, maka project manager seharusnya justru berada di sisi klien, bukan implementator. Akan sia-sia jika aktivitas project planning, project controlling dsb sepenuhnya dilakukan oleh implementator, sementara klien hanya ”tahu beres” saja. Pada akhirnya aktivitas-aktivitas project management tsb hanya akan menghasilkan berkas-berkas dan dokumen administratif saja, yang pada kenyataannya tidak pernah dilaksanakan.

       Peran yang paling pas untuk implementator adalah sebagai konsultan. Tugas utama dari konsultan adalah memberikan informasi, mendampingi, memfasilitasi dan menjadi motor ”behind the screen”. Tentu saja jika kontraknya melibatkan pengadaan software, konsultan juga akan melakukan development atau implementasi secara teknis, namun implementasi keseluruhannya harus dipimpin oleh klien sendiri melalui project manager. Jika klien tidak memiliki pengetahuan yang cukup untuk mengelola proyek software, itulah tugas konsultan untuk mendampinginya, sehingga proses project planning, control, evaluation, dst sepenuhnya akan berasal dari ide-ide, komitmen dan effort dari klien sendiri.

       Tugas konsultan adalah memfasilitasi dan mengarahkannya. Model seperti ini yang kemudian memunculkan teknik JAD (Joint Application Design), yang intinya adalah melibatkan dan kolaborasi seluruh stakeholder proyek. salah satu fase dalam implementasi sistem adalah fase transisi, yang pasti akan menuntut perubahan baik kecil maupun besar. Adanya sistem baru, mau tidak mau akan merubah proses bisnis. Perubahan proses bisnis berarti perubahan cara kerja, alur kerja dan bahkan budaya kerja. Perubahan ini menyangkut aspek people dan proses bisnis, sehingga dikenal konsep change management.

       Dalam eksekusinya, change ini harus dipimpin dan dimanage oleh leader di internal organisasi. Yang jelas seorang konsultan tidak hanya dituntut memiliki pengetahuan tentang software engineering dan hal-hal teknis, dan juga tidak cukup ditambah dengan pengalaman dan keterampilan project management, namun konsep dan bestpractice tentang change management, communication skill yang excellent sangat diperlukan.

JAD (Joint Application Development/Design) sebagai salah satu teknik manajemen dalam mengimplementasikan sebuah sistem informasi (SI) dalam konteks proyek. porsi terbesar dan terumit dari proses implementasi SI adalah justru pada proses transisinya, karena terkait banyak aspek tidak hanya di sisi teknologi tapi harus memahami sisi sosial, manajerial dan SDM.

Implementasi SI

Masalah terbesar dari implementasi SI adalah untuk mengetahui kebutuhan dari user, apalagi dengan karakter proyek :

• Sistem yang melibatkan multi-organisasi/divisi (penggunanya dari beberapa role dan divisi)
• Bisnis proses yang kompleks
• Kebutuhan yang sangat spesifik dan customized.

            Dengan karakter proyek yang semacam ini, tidak cukup bagi seorang system analyst (SA) menentukan kebutuhan hanya dengan teknik wawancara, observasi ataupun kuesioner. Banyak kasus ditemui, bahwa pada akhirnya apa yang kita dapatkan dari proses analisa kebutuhan di awal proyek, tidak match dengan kebutuhan sesungguhnya dari pengguna sistem, sehingga sistem akhirnya tidak dapat digunakan dengan baik. Masalah lain adalah di sisi waktu. Teknik-teknik seperti itu seringkali sangat time consuming, sangat membutuhkan waktu yang lama. Sering juga tim developer dihadapkan situasi bahwa tidak semua stakeholder proyek memiliki kepedulian yang sama dengan yang lain. Seorang manajer tidak mengetahui kebutuhan detail dari staf-staf operasional, sementara itu staf operasional mungkin juga tidak memahami sepenuhnya spirit, goal dari SI. JAD merupakan sebuah teknik yang berfokus pada keterlibatan dan komitmen pengguna dalam menentukan kebutuhan dan merancang (desain) aplikasi. JAD biasanya dilakukan dalam bentuk tim yang merupakan gabungan dari seluruh stakeholder proyek, yang bekerja dalam bentuk workshop-workshop atau forum diskusi.