8 2.1 Pengertian Sistem Informasi
Menurut O’Brien (2006: 703), sistem informasi adalah kombinasi teratur dari orang-orang, hardware, software, jaringan komunikasi, dan sumber daya data yang mengumpulkan, mengubah, dan menyebarkan informasi dalam sebuah organisasi. Orang bergantung pada sistem informasi untuk berkomunikasi antara satu sama lain dengan menggunakan berbagai jenis alat fisik (hardware), perintah dan prosedur pemrosesan informasi (software), saluran komunikasi (jaringan), dan data yang disimpan (sumber daya data) sejak permulaan peradaban.
Menurut Whitten dan Bentley (2007: 6) sistem informasi adalah suatu pengaturan dari orang, data, proses, dan teknologi informasi yang saling berinteraksi untuk kegunaan yang berupa informasi yang dibutuhkan untuk mendukung suatu organisasi.
Menurut Laudon (2007: 14), sistem informasi adalah sekumpulan komponen yang saling berhubungan yang bekerjasama mengumpulkan, memproses, menyimpan dan menyebar informasi untuk mendukung pengambilan keputusan, koordinasi dan pengawasan dalam suatu organisasi.
Dari uraian yang dipaparkan di atas, dapat disimpulkan bahwa sistem informasi adalah sekumpulan komponen-komponen yang terdiri dari orang-orang, hardware, software, jaringan komunikasi, dan data yang saling berhubungan yang bekerja sama untuk mengumpulkan, mengubah, memproses, menyimpan, dan menyebarkan informasi yang dibutuhkan untuk mendukung
suatu organisasi. Dalam jurnal oleh Agus Sunarto dan Zainal (2007 : Vol 3 (2), 33-34), terdapat empat golongan dalam mengkategorikan sistem informasi yaitu:
- Strategic : Sistem informasi yang kritis untuk bisnis dan kesuksesan mendatang.
- Key Operational : Sistem informasi yang penting untuk mendukung kelangsungan bisnis saat ini dan harus selalu dijaga keefektifannya. - Support : Membantu meningkatkan efisiensi proses bisnis dan efektifitas
manajemen, namun tidak kritis bagi bisnis.
- High Potential : Sistem Informasi yang terwujud dari inovasi-inovasi baru dan sangat potensial mencapai keunggulan kompetitif.
2.2 Pengertian Evaluasi
Menurut Boulmetis dan Dutwin (2005: 4), Evaluasi adalah proses yang sistematis dalam mengumpulkan data yang membantu mengidentifikasikan kekuatan dan kelemahan suatu program atau proyek.
Adapun menurut Arikunto dan Cepi (2008: 2), evaluasi adalah kegiatan untuk mengumpulkan informasi tentang bekerjanya sesuatu, yang selanjutnya informasi tersebut digunakan untuk menentukan alternatif yang tepat dalam mengambil sebuah keputusan. Fungsi utama evaluasi dalam hal ini adalah menyediakan informasi-informasi yang berguna bagi pihak decision maker untuk menentukan kebijakan yang akan diambil berdasarkan evaluasi yang telah dilakukan.
Dari uraian di atas, dapat disimpulkan bahwa evaluasi merupakan kegiatan mengumpulkan informasi yang dapat membantu mengidentifikasikan
kekuatan dan kelemahan suatu sistem yang berguna dalam proses pengambilan keputusan.
2.3 Metode Pengumpulan Data
Menurut Gulo (2003: 116-123), metode pengumpulan data terdiri dari: 1. Pengamatan (Observasi)
Pengamatan (observasi) adalah metode pengumpulan data dimana peneliti atau kolaboratornya mencatat informasi sebagaimana yang mereka saksikan selama penelitian.
2. Survei
Survei adalah metode pengumpulan data dengan menggunakan instrumen untuk meminta tanggapan dari responden tentang sampel. 3. Wawancara
Wawancara adalah bentuk komunikasi langsung antara peneliti dan responden. Komunikasi berlangsung dalam bentuk tanya-jawab dalam hubungan tatap muka, sehingga gerak dan mimik responden merupakan pola media yang melengkapi kata-kata secara verbal. Karena itu, wawancara tidak hanya menangkap pemahaman atau ide, tetapi juga dapat menangkap perasaan, pengalaman, emosi, motif, yang dimiliki oleh responden yang bersangkutan. Disinilah letak keunggulan dari metode wawancara.
4. Kuesioner (Angket)
Pada kuesioner, pertanyaan disusun dalam bentuk kalimat tanya, sedangkan pada angket, pertanyaan disusun dalam kalimat pertanyaan dengan opsi jawaban yang tersedia.
5. Dokumenter
Dokumen adalah catatan tertulis tentang berbagai kegiatan atau peristiwa pada waktu lalu. Jurnal dalam bidang keilmuan tertentu termasuk dokumen penting yang merupakan acuan bagi peneliti dalam memahami obyek penelitiannya. Semua dokumen yang bersangkutan perlu dicatat sebagai sumber informasi
2.4 Enterprise Resource Planning (ERP)
2.4.1 Pengertian Enterprise Resource Planning (ERP)
Menurut O’Brien (2006: 320), Enterprise Resource Planning atau disingkat ERP adalah suatu tulang punggung lintas fungsi perusahaan yang mengintegrasikan dan mengotomatisasi banyak proses internal dan sistem informasi dalam hal fungsi produksi, logistik, distribusi, akuntansi, keuangan, dan sumber daya manusia perusahaan. ERP adalah sebuah sistem informasi perusahaan yang dirancang untuk mengkoordinasikan semua sumber daya, informasi dan aktivitas yang diperlukan untuk proses bisnis lengkap. Sistem ERP didasarkan pada database pada umumnya dan rancangan perangkat lunak modular. ERP merupakan software yang mengintegrasikan semua departemen dan fungsi suatu perusahaan ke dalam satu sistem komputer yang dapat melayani semua kebutuhan perusahaan, baik dari departemen penjualan, HRD, produksi atau keuangan.
Menurut Kumar (2010: 264), Enterprise Resource Planning (ERP) adalah sistem manajemen bisnis yang terintegrasi dan operasi bisnisnya sudah memiliki standar. ERP dapat meningkatkan efektivitas dan
efisiensi organisasi. ERP merupakan nama dari sistem software manajemen yang diciptakan melalui pemikiran korporasi diseluruh dunia untuk meningkatkan kemampuan fungsi bisnis mereka yang penting. Sistem ERP menyatukan, menstandarisasi dan meluruskan semua aktivitas bisnis kedalam satu sistem yang akan mencapai standar tertinggi untuk informasi yang aman, dipercaya, mudah diakses, dan real time. Setiap orang yang berpartisipasi didalam aktivitas bisnis baik di dalam maupun di luar organisasi dapat mengakses sistem menggunakan struktur yang sama. Prosesnya terus di-update dan disederhanakan serta redudansi diminimalkan.
Berdasarkan uraian diatas, dapat disimpulkan bahwa ERP adalah sebuah konsep sistem informasi perusahaan yang dirancang untuk menghubungkan semua sumber daya, informasi, dan aktivitas pada perusahaan secara real time yang dapat meningkatkan efektivitas dan efisiensi proses bisnis perusahaan
2.4.2 Sejarah Perkembangan ERP
Menurut Leon (2008: 18-20), sejarah perkembangan ERP dibagi menjadi 4 tahap, yaitu :
1. Material Requirement Planning (MRP)
Pada pertengahan tahun 1970-an, MRP menjadi konsep dasar manajemen produksi dan kontrol dalam industri manufaktur. MRP merupakan hasil dari pemrosesan bill of material (BOM) yang merupakan daftar berbagai bahan baku atau komponen yang diperlukan dalam industri. MRP dilihat sebagai solusi sempurna
untuk kebutuhan manufaktur dan perencanaan produksi karena mampu memecahkan masalah-masalah utama yang ada. Berdasarkan jurnal oleh Chandraju, Raviprasad dan Chidan (2012 : Vol 2 (9), 1), MRP adalah sebuah sistem manajemen inventori berbasis komputer yang dirancang khusus untuk membantu manajer produksi dalam penjadwalan dan penempatan order untuk permintaan item tertentu.
2. Closed-loop MRP
Sistem MRP dapat mengelola tanggal jatuh tempo dari pemesanan dan dapat digunakan untuk mendeteksi dan memberikan peringatan ketika suatu barang tidak diterima pada saat tanggal jatuh tempo. Kemampuan ini dapat membantu mengurangi ketidakpastian proses produksi. Beberapa tools dikembangkan untuk mendukung perencanaan penjualan dan tahap produksi, pengembangan jadwal produksi, peramalan, perencanaan kapasitas, dan pemrosesan pemesanan. Pengembangan ini menciptakan closed-loop MRP. Closed-loop MRP tidak hanya sekedar perencanaan kebutuhan material namun berupa fungsi untuk mengotomatisasi proses produksi.
3. Manufacturing Resource Planning (MRP II)
MRP II merupakan metode untuk perencanaan yang efektif dari semua sumber daya yang dimiliki perusahaan manufaktur. MRP II terbentuk dari kumpulan fungsi yang saling terhubung: perencanaan bisnis, perencanaan operasional dan penjualan, manajemen permintaan, perencanaan produksi, master scheduling,
perencanaan kebutuhan material, perencanaan kebutuhan kapasitas, dan pelaksanaan sistem pendukung untuk kapasitas dan material. Hasil sistem tersebut akan terintegrasi dengan laporan finansial seperti perencanaan bisnis, laporan komitmen pembelian, biaya pengiriman, proyeksi inventory, dan sebagainya.
4. Enterprise Resource Planning (ERP)
Konsep dasar dari ERP sama dengan konsep MRP II. Namun perusahaan software menciptakan ERP dengan sekumpulan proses bisnis yang lebih luas dalam hal ruang lingkup, kemampuan untuk menangani beberapa fungsi bisnis tambahan serta integrasi yang lebih baik dan erat dengan fungsi finansial dan akuntansi. ERP juga mampu mengintegrasikan tools lain seperti Customer Relationship Management (CRM), Supply Chain Management (SCM), dan lain sebagainya. ERP juga mampu mendukung aktivitas bisnis yang melibatkan pihak eksternal perusahaan
2.4.3 Manfaat dan Kelemahan ERP 2.4.3.1 Manfaat ERP
Leon (2005: 54) menyatakan bahwa ERP mempunyai keuntungan dengan pengurangan lead-time, pengiriman tepat waktu, pengurangan dalam waktu siklus, kepuasan pelanggan yang lebih baik, kinerja pemasok yang lebih baik, peningkatan fleksibilitas, pengurangan dalam biaya-biaya kualitas, penggunaan sumber daya yang lebih baik, peningkatan akurasi informasi dan kemampuan pembuatan keputusan.
2.4.3.2 Kelemahan ERP
Menurut Magalhaes, Jahankhani, dan Hessami (2010: 164), kelemahan-kelemahan pada sistem ERP diantaranya sebagai berikut:
1. Terbatasnya kustomisasi software ERP. 2. Sistem ERP masih sangat mahal.
3. ERP sering kali dilihat terlalu sulit untuk diadaptasikan ke kerangka kerja dan proses bisnis spesifik beberapa perusahaan.
4. Banyak integrated links yang membutuhkan akurasi tinggi di aplikasi lain untuk dapat bekerja secara efektif.
2.5 Systems, Applications, and Products in Data Processing (SAP) 2.5.1 Sejarah SAP
Menurut Brady, Monk, dan Wagner (2001: 21) SAP berasal dari bahasa Jerman yang diperkenalkan pada tahun 1972 berarti Systeme, Anwendungen and produkte in derdatenverarbeitung, yang dalam bahasa Inggris adalah Systems, Applications, and Products in data processing. SAP merupakan vendor utama software ERP di Manheim Jerman yang dibangun oleh 5 orang dari IBM.
Versi pertama SAP’s flagship software enterprise adalah sistem akuntansi keuangan bernama R1. Setelah itu digantikan oleh R/2 pada akhir tahun 1970-an. SAP R/2 berada disebuah mainframe perangkat lumak aplikasi bisnis berbasis suite yang sangat sukses di tahun 1980-an dan awal 1990-an. Hal ini sangat populer dengan porsi besar
perusahaan-perusahaan multinasional Eropa yang membutuhkan aplikasi bisnis yang real time, dengan multi-currency dan kemampuan multi-bahasa yang tertanam di dalamnya. Dengan didistribusikannya komputasi client server, SAP-AG mengeluarkan client-server versi perangkat lunak yang disebut SAP R/3 (‘R’ adalah untuk pengolahan data ‘real time’ dan 3 adalah untuk three tier). Arsitektur baru ini kompatibel dengan berbagai platform dan sistem operasi, seperti Microsoft Windows atau UNIX. Hal ini membuka SAP ke seluruh basis pelanggan baru, sistem SAP R/3.
SAP R/3 secara resmi diluncurkan pada tanggal 6 Juli 1992. Ia kemudian dinamakan SAP ERP dan kemudian kembali berganti nama menjadi ECC (ERP Central Component). SAP datang untuk mendominasikan pasar aplikasi bisnis besar selama 10 tahun. SAP ECC 5.0 ERP adalah penerus SAP R/3 4.7. versi terbaru dari suite adalah mySAP 2005 atau SAP ECC 6.0. Tahun 2000-an, SAP menjadi vendor independent software terbesar ketiga dengan 121.000 instalasi di seluruh dunia, lebih dari 1.500 rekan kerja, lebih dari 25 solusi bisnis industri khusus, dan lebih dari 41.200 pelanggan di 120 negara. Sekarang SAP dilengkapi dengan arsitektur berorientasikan layanan (services-oriented architecture-SOA) dan platform integrasi dan aplikasi, SAP NetWeaver.
2.5.2 Produk SAP
Menurut Hernandez, Keogh, dan Martinez (2005: 17-18), beberapa produk yang diperkenalkan oleh SAP yaitu :
1. SAP for industry, didasarkan pada SAP Industry Solution sebelumnya dan untuk sebagian besar masih didasarkan pada SAP
R/3 yang dimigrasikan pertama kali ke Enterprise R/3 dan ke SAP Web Application Server dan juga mempunyai elemen dari SAP NetWeaver.
2. mySAP business suite menyajikan sekumpulan dari semua produk SAP lintas industri dan didasarkan pada strategi platform SAP Netweaver. Beberapa solusi di dalam Business Suite adalah mySAP CRM, mySAP SCM, dan mySAP ERP.
3. SAP x Apps singkatan dari SAP Cross Application, juga merupakan pengembangan khusus yang didasarkan pada Java yang didasarkan pada SAP NetWeaver yang mengizinkan integrasi dari fungsi yang spesifik dari beberapa solusi SAP.
4. SAP Smart Business Solution, ditargetkan untuk segmen pasar dari bisnis yang kecil dan menengah. Produk di dalam solusi ini meliputi:
a. mySAP All-in-One merupakan paket khusus yang didasarkan pada sistem SAP R/3 yang telah ditingkatkan dengan fungsi dan aplikasi dari SAP Solution lainnya.
b. SAP Business One merupakan produk khusus yang tidak secara langsung didasarkan pada sistem SAP R/3 tetapi ditambahkan fungsi yang kritis yang dibutuhkan oleh bisnis kecil dan menengah seperti accounting dan warehouse management
2.5.3 Modul-modul SAP
Menurut Dewanto dan Falahah (2007: 172), modul-modul yang disediakan dalam SAP antara lain :
1. Financials
1.1 Financial Accounting (FI) 1.2 Controlling (CO)
1.3 Fixed Asset Management (AM) 1.4 Project System (PS)
1.5 Enterprise Controlling (EC) 1.6 Real Estate Management 2. Logistics
2.1 Sales and Distribution (SD) 2.2 Materials Management (MM) 2.3 Quality Management (QM) 2.4 Plant Maintenance (PM) 2.5 Customer Service (CS)
2.6 Production Planning and Control (PP) 2.7 SAP Retail
3. Human Resources
3.1 Personnel Management (PA) 3.2 Personnel Time Management (PT) 3.3 Payroll (PY)
3.4 Training and Event Management (PE)
Modul-modul yang disebutkan di atas tidak harus diimplementasi seluruhnya oleh perusahaan. Perusahaan dapat memilih modul yang sesuai dengan kebutuhan proses bisnis yang dijalankan.
2.6 SAP Material Management
Menurut Anonim 1 (2006: 209), Material Management dalam SAP digunakan untuk memastikan bahwa perusahaan telah mendapatkan produk yang benar, ditempat yang tepat, pada jumlah dan harga yang sesuai.
2.6.1 The Procurement Process: Basics
2.6.1.1 Organizational Level in Procurement Process
Organizational level yang ada pada proses procurement adalah sebagai berikut (SCM 500, 50-53):
Gambar 2.1 Organizational Levels in the Procurement Process
Sumber : Anonim 1. (2006: 50), SCM 500 a. Client
Client adalah tingkat hirarki tertinggi dalam sistem SAP. Spesifikasi atau data yang dibuat dan dimasukkan pada level ini berlaku untuk semua company code dan organizational unit lainnya.
b. Company Code
Company Code adalah unit organisasi terkecil yang memuat sekumpulan akun yang dibuat untuk tujuan pelaporan eksternal. Meliputi semua transaksi terkait dan menghasilkan semua dokumen pendukung untuk laporan keuangan seperti neraca dan laporan laba rugi.
c. Plant
Plant adalah unit organisasi dalam logistik yang membagi perusahaan dari sudut pandang produksi, procurement, dan material planning. Plant dapat mewakili berbagai entitas yang ada dalam perusahaan, seperti:
- Production Facility
- Distribution Center
- Regional Sales Office
- Corporate Headquarters
- Maintenance Location d. Storage Location
Storage Location adalah unit organisasi yang memfasilitasi perbedaan stok material di dalam plant. Manajemen inventarisasi secara kuantitas dan persediaan fisik dilakukan pada level unit ini.
e. Purchasing Organization/Purchasing Group
Unit organisasi yang bertanggung jawab untuk pembelian material atau pelayanan untuk satu atau lebih plant untuk negosiasi kondisi umum pembelian dengan vendor. Purchasing organization bertanggung jawab atas semua transaksi pembelian eksternal. Purchasing Organization dibagi lagi ke dalam purchasing group (buyer groups) yang mana bertanggung jawab untuk aktivitas pembelian sehari-hari. Sebuah purchasing group juga bisa beraksi untuk beberapa purchasing organization.
2.6.1.2 Procurement Process
Gambar 2.2 Procurement Cycle Sumber: Anonim 1. (2006: 44), SCM 500
Gambar 2.3 Proses Detail Procurement PT Unilever Indonesia (Sumber : MDM Manager – PT Unilever)
a. Determination of requirements: Bagian yang bertanggung jawab atas ini dapat secara manual menyerahkan data-data material yang dibutuhkan kepada bagian pembelian melalui purchase requisition. Jika perusahaan telah menentukan MRP Procedure di dalam material master, sistem SAP dapat secara otomatis menghasilkan purchase requisition.
b. Determination of source of supply: Sebagai pembeli, SAP mendukung penentuan sumber pasokan material. Penentuan sumber pasokan dapat digunakan untuk membuat request for quotation (RFQ). Selain itu, dapat juga dibuat dengan merujuk
ke purchase orders, contracts, dan conditions yang telah ada di dalam sistem.
c. Vendor Selection & Comparison of Quotations: Sistem menyederhanakan pemilihan vendor dengan membuat perbandingan harga di antara berbagai quotations. Sistem juga dapat secara otomatis dapat mengirimkan surat penolakan.
d. Purchase order Processing: Seperti halnya purchase requisitions, purchase order dapat dibuat secara manual atau otomatis oleh sistem. Saat membuat purchase order, data dapat disalin dari dokumen lain seperti purchase requisitions atau quotations, untuk mengurangi jumlah input yang dibutuhkan.
e. Purchase order monitoring/follow-up: Status dari purchase order dapat diawasi di sistem seperti misalnya apakah delivery atau invoice untuk purchase order telah dimasukkan.
f. Goods receiving and Inventory Management: Penerimaan barang atas barang yang dipesan melalui purchase order untuk dikonfirmasi kecocokan jumlah dan harga dari barang yang masuk ke gudang.
g. Invoice Verification: proses untuk mengecek data invoice yang dimasukkan apakah sesuai dengan purchase order yang berkaitan.
h. Payment Processing: proses dalam modul material management tidak mengeksekusi tahap ini melainkan akan dijalankan oleh financial accounting secara berkala.
Selain prosedur normal seperti yang ada di atas, terdapat juga beberapa proses procurement khusus yang dapat terjadi, yaitu:
a. Stock transfer with stock transfer orders
Dengan tipe procurement ini, material didapatkan dan dikirim di dalam satu perusahaan. Plant yang membutuhkan material membuat internal order dengan plant yang lain yang dapat menyuplai material tersebut.
Gambar 2.4 Stock transfer with stock transfer orders Sumber: Anonim 1. (2006: 46), SCM 500
Proses dimulai pada plant penerima dengan membuat stock transfer order pada pembelian. Lalu plant pengirim akan membuat goods issue dengan referensi dari stock transfer order. Proses ini berakhir dengan pembuatan goods issue terhadap stock transfer order di plant penerima.
b. Subcontracting
Dengan proses ini, perusahaan memesan material dari vendor eksternal. Berbeda dengan external procurement process yang biasa, perusahaan menyediakan beberapa atau semua komponen yang terkait dengan produksi material kepada vendor.
Gambar 2.5 Subcontracting
Sumber : Anonim 1. (2006: 47), SCM 500
Proses ini memiliki karakteristik berikut:
Perusahaan memesan produk akhir dengan subcontract order. Pemesanan ini berisi tidak hanya informasi mengenai material yang akan dikirim, tapi juga detil komponen yang terkait. Lalu komponen-komponen ini harus disediakan untuk subcontractor. Material yang disediakan tidak lagi ada secara fisik di perusahaan namun meskipun begitu tetap di-maintain di sistem perusahaan karena masih tetap milik perusahaan. Informasi ini dilihat di tipe stok stock of material provided to vendor. Saat subcontractor telah menyelesaikan pekerjaannya, lalu dia akan mengirimkan material yang telah jadi.
Goods Receipt pun terjadi disini dengan referensi dari subcontract order.
2.6.1.3 Master Data
2.6.1.3.1 Material Master Records
Material Master Records merupakan sumber utama data material perusahaan dan digunakan oleh semua area logistik. Integrasi seluruh material data ke dalam satu objek database menghapus masalah redundansi data. Semua area, seperti purchasing, inventory management, materials planning, dan invoice verification dapat bersama-sama menggunakan data yang tersimpan.
Data yang tersimpan di dalam material master records diperlukan untuk beberapa tujuan, termasuk diantaranya:
a. Data purchasing diperlukan untuk melakukan pemesanan.
b. Data inventory management dibutuhkan untuk memantau pergeseran barang.
c. Data accounting diperlukan untuk penilaian material.
d. Data materials planning dibutuhkan untuk perencanaan kebutuhan material.
Layar untuk memproses material master record dapat dibedakan menjadi tipe berikut ini:
a. Main data
Merupakan layar untuk setiap user di perusahaan, seperti basic data, materials planning, dan sebagainya. b. Additional data
Merupakan layar dimana dapat ditemukan informasi tambahan, seperti unit of measure alternative, material short descriptions, dan consumption values.
Beberapa data material valid untuk semua level organisasi, dan beberapa lainnya hanya valid pada level organisasi tertentu. Sehingga material data dapat diatur secara terpusat, mengurangi pengambilan data yang tidak diperlukan dari database demi meminimalisir
redundansi. Material Master dapat diatur dalam cara yang mencerminkan struktur dari perusahaan. Dijelaskan seperti berikut :
1. Data at Client Level
General master data valid untuk seluruh perusahaan disimpan pada level Client.
2. Data at Plant Level
Semua data yang valid dalam suatu plant dan untuk kepunyaan semua storage location disimpan dalam level plant.
3. Data at Storage Location Level
Semua data yang valid yang merupakan bagian dari storage location disimpan pada storage location level.
2.6.1.3.2 Vendor Master
Vendor master record berisi informasi mengenai vendor perusahaan. Informasi ini disimpan di dalam individual vendor master records. Selain
nama dan alamat vendor, vendor master record juga berisi data sebagai berikut:
• Mata uang yang digunakan dalam transaksi
• Syarat dan ketentuan pembayaran • Kontak penting
Data dalam vendor master record dibagi menjadi beberapa kategori:
a. General Data
Data ini valid untuk semua client. Yang termasuk dalam data ini contohnya seperti alamat vendor, dan bank.
b. Accounting Data
Dikelola pada level company code. Terdiri dari data seperti jumlah rekening rekonsiliasi dan metode pembayaran untuk transaksi pembayaran otomatis.
c. Purchasing Data
Data ini dikelola untuk setiap purchasing organization. Termasuk diantaranya mata uang yang digunakan, incoterm, dan berbagai
kontrol yang berkaitan dengan vendor.
2.6.1.3.3 Purchasing Information Record
Purchasing Information Record menyediakan pilihan penyimpanan informasi mengenai vendor dan material, seperti master data pada purchasing organization dan plant level. (SCM 500: 254)
Dari keterangan di atas dapat disimpulkan bahwa Purchasing Info Record merupakan tempat dimana informasi spesifik atas material dan vendor yang nantinya dapat digunakan dalam pembuatan PO.
2.6.1.4 Purchase Documents
2.6.1.4.1 Planned Order
Sebuah planned order dikirim ke plant dan merupakan sebuah permintaan MRP untuk proses procurement material tertentu dalam jangka waktu tertentu. Planned order ini menentukan kapan
perpindahan material kedepannya sebaiknya dilakukan dan berapa banyak material yang dibutuhkan nantinya.
2.6.1.4.2 Purchase Requisition
Adalah sebuah dokumen request atau instruksi untuk pembelian sejumlah barang/jasa tertentu supaya barang/jasa itu tersedia pada waktu yang diinginkan.
2.6.1.4.3 Request for Quotation (RFQ)
Suatu dokumen yang terdiri dari data-data kebutuhan yang ditransisi dari dokumen requisition untuk material atau jasa, dan RFQ ini dikirim ke vendor.
2.6.1.4.4 Quotation
Adalah sebuah tawaran dari vendor terhadap purchasing organization dalam hal suplai material atau pelayanan jasa untuk kondisi tertentu. Terdiri dari harga-harga dan kondisi dari vendor dan merupakan dasar dalam tahap procurement ‘vendor selection’.
2.6.1.4.5 Purchase order
Purchase order merupakan formal request kepada vendor untuk menyuplai barang atau jasa dengan kondisi yang dinyatakan dalam Purchase order.
2.6.1.4.6 Contract
Merupakan perjanjian pembelian kontrak jangka panjang dalam SAP merupakan tanda komitmen dalam pembelian material atau jasa tertentu dari seorang vendor dalam jangka waktu tertentu.
2.6.1.4.7 Inbound Delivery
Inbound Delivery adalah sebuah proses dalam penerimaan dalam pengantaran barang ke tempat penerimaan barang (warehouse). Proses ini dimulai pada saat barang siap di kirim oleh vendor dan telah ditentukan melalui jalur apa dan menggunakan apa pengantarannya, sampai ketika barang tiba di warehouse
dan warehouse receiver membuat good receipt.
2.6.1.4.8 Goods Receipt
Gambar 2.6 Goods Receipt pada SAP Sumber : Anonim 1. (2006: 87). SCM
500
Goods Receipt merupakan pergerakan inbound dalam bentuk fisik barang atau material ke dalam gudang. Hal ini berdampak pada meningkatnya stok barang di gudang.
2.6.1.4.9 Stock Transfer
Stock Transfer adalah perpindahan fisik suatu barang dari satu lokasi penyimpanan ke lokasi penyimpanan lainnya. Stock transfer di sistem Material Management antara lain termasuk
perpindahan fisik material dari suatu plant ke plant yang lain dan storage location ke storage location yang lain.
2.6.1.4.10 Goods Return
Retur adalah sistem pengembalian barang yang telah dibeli dari vendor sebagai akibat dari beberapa sebab seperti barangnya tidak sesuai dengan yang dipesan sebelumnya, barang rusak, dan sebab lainnya.
Gambar 2.7 Retur pada SAP Sumber: help.sap.com
2.6.1.4.11 Invoice Verification
Logistic Invoice Verification dikembangkan untuk memfasilitasi entri invoice dan credit memo untuk mengecek kebenaran aritmatika dan untuk mengecek apakah harga untuk material tertentu sudah sesuai atau belum. Dalam proses invoice verification tidak termasuk pembayaran akan invoice dan evaluasi invoice tersebut. Proses ini menciptakan hubungan antara Material Management dengan Accounting eksternal/internal.
Gambar 2.8 Invoice Verification with reference to PO
2.6.1.5 Automated Procurement
2.1.6.5.1 Material Resource Planning
Gambar 2.9 Automated Procurement : MRP Sumber : Anonim 1. (2006: 504), SCM 500
Siklus procurement dapat disederhanakan di beberapa titik dengan mengotomatisasi langkah-langkah individual dimana ada tiga tahap dalam 4 tahap procurement bisa berjalan secara otomatis.
Proses ini merupakan cara singkat dalam melakukan procurement process, terdiri dari:
a. Purchase requisition dengan MRP tanpa harus menginput secara
manual. Oleh karena itu, penting untuk menentukan data yang relevan di dalam material master record. b. Automatic conversion PR into PO,
di mana hal-hal berikut harus terpenuhi :
1. Pada material master record, indikator ‘automated PO’ harus di pilih.
2. Pada vendor master record, indikator ‘automated PO’ harus di pilih.
3. Barang pada dokumen PR harus memiliki sumber suplai yang valid.
c. Evaluated Receipt Settlement (ERS) Dalam proses ERS ini, harus setuju dengan vendor bahwa proses ini tidak akan menghasilkan invoice untuk transaksi pemesanan. Tapi, sistem SAP akan secara otomatis membuat invoice bersangkutan untuk penerimaan barang. Proses ini memiliki beberapa keuntungan:
a. Transaksi pemesanan selesai lebih cepat.
b. Error dapat dihindarkan.
c. Jumlah dan varian harga tidak terjadi pada invoice verification.
Requirement planning membantu mengawasi stok material dan mencakup otomatisasi permintaan pengadaan barang dalam hal pembelian dan produksi. Menentukan kekurangan dan menghasilkan elemen pengadaan barang terkait, termasuk diantaranya planned order, purchase requisition, dan schedule lines.
Pada in-house production, sistem membuat planned orders untuk perencanaan produksi. Setelah perencanaan lengkap, planned orders diubah menjadi production orders.
Pada external procurement, sistem membuat planned order atau purchase requisition secara langsung untuk perencanaan external procurement quantity. Planned order dan purchase
requisition merupakan elemen perencanaan internal yang dapat diubah, dijadwalkan ulang, atau dihapus kapan saja. Jika sebuah planned order dibuat, bagian pembelian dapat memesan material hanya apabila MRP controller telah memeriksa planned order dan mengubahnya menjadi sebuah purchase requisition. Sebaliknya, permintaan pemesanan dapat langsung tersedia untuk dilakukan pembelian.
2.7 Flowchart
Menurut Mulyadi (2001: 60), sistem akuntansi dapat dijelaskan menggunakan bagan alir dokumen. Flowchart adalah salah satu cara metode penggambaran untuk menggambarkan bagan alir suatu sistem. Flowchart adalah representasi grafik dari langkah-langkah yang harus diikuti dalam menyelesaikan suatu permasalahan yang terdiri atas sekumpulan simbol, dimana masing-masing simbol merepresentasikan suatu kegiatan tertentu. Flowchart diawali dengan penerimaan input, pemrosesan input, dan diakhiri dengan penampilan output. Penerimaan input, pemrosesan input, dan penampilan output merupakan kegiatan utama yang membentuk siklus dari semua kegiatan yang dilakukan oleh komputer. Siklus ini disebut dengan siklus I-P-O (Input-Process-Output).
2.8 Activity Diagram
Menurut Satzinger, Jackson, dan Burd (2005: 144), Activity Diagram adalah sebuah tipe diagram alur kerja yang menggambarkan aktivitas pengguna dan aliran sekuensialnya. Activity diagram menggambarkan berbagai aliran aktivitas dalam sistem yang sedang dirancang, bagaimana masing-masing aliran berawal, decision yang mungkin terjadi, dan bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi. Activity diagram merupakan state diagram khusus, di mana sebagian besar state adalah action dan sebagian besar transisi di-trigger oleh selesainya state sebelumnya (internal processing).
Activity diagram adalah diagram untuk menggambarkan aksi-aksi dan keputusan-keputusan yang terjadi sesuai fungsi-fungsi yang telah dilakukan, menurut Pressman (2010: 161).
2.9 Failure Mode and Effect Analysis (FMEA)
Menurut Black (2009, p32), Failure Mode and Effect Analysis (FMEA) adalah sebuah teknik untuk memahami dan memberi prioritas pada failure mode (symptom bug) atau risiko kualitas yang mungkin pada fungsi, fitur, atribut, behaviour, komponen, dan interface sistem. Pada dasarnya, FMEA adalah sebuah prosedur dalam pengembangan produk dan manajemen operasi untuk menganalisis failure mode yang mungkin pada suatu sistem dengan klasifikasi berdasarkan prioritas dan kemungkinan kegagalan. Aktifitas FMEA yang berhasil membantu sebuah tim mengidentifikasikan failure mode yang mungkin berdasarkan pengalaman sebelumnya dengan proses atau produk yang
serupa. Ini memungkinkan tim untuk menghindari kegagalan-kegalan tersebut dengan usaha dan pengeluaran yang minimum.
FMEA adalah teknik desain yang sistematis mengidentifikasikan dan menyelidiki kelemahan sistem potensial (produk atau proses). Ini terdiri dari metodologi untuk memeriksa semua cara dimana kegagalan sistem dapat terjadi, efek-efek potensial dari kegagalan pada kinerja sistem dan keamanan, dan besarnya dampak dari efek tersbut. FMEA ditujukan untuk menentukan keandalan desain dengan mempertimbangkan potensi penyebab kegagalan dan efeknya pada sistem yang diteliti. Tujuan dari FMEA adalah untuk mencegah kegagalan yang tidak dapat diterima oleh user atau pelanggan dan untuk membantu manajemen dalam alokasi sumber daya yang lebih efisien. FMEA digunakan dalam program manajemen risiko perusahaan untuk mencegah user atau pelanggan menjadi sasaran kesalahan yang tidak dapat diterima dan untuk menghindari ketidakpuasan user atau pelanggan menurut Shirouyehzad (2011: Vol 4(1), 1).
A. Severity. Kolom ini menunjukkan efek dari kegagalan (langsung atau tertunda) pada sistem. Rex Black menggunakan skala 1 (terburuk) sampai 5 (paling tidak berbahaya), sebagaimana berikut ini:
1. Kehilangan data, kerusakan perangkat keras, atau masalah keamanan.
2. Kehilangan fungsionalitas yang tidak ada solusi. 3. Kehilangan fungsionalitas yang masih memiliki solusi. 4. Kehilangan fungsionalitas parsial.
B. Priority. Pada kolom ini didefinisikan efek dari kegagalan tersebut pada user , pelanggan, atau operator. Rex Black menggunakan skala dari 1 (terburuk) sampai 5 (paling tidak berbahaya), seperti berikut ini:
1. Kehilangan total dari nilai sistem.
2. Kehilangan yang tidak bisa diterima dari nilai sistem. 3. Kehilangan yang mungkin dapat diterima pada nilai sistem. 4. Kehilangan yang dapat diterima pada nilai sistem.
5. Kehilangan yang dapat diacuhkan pada nilai sistem.
Nomor ini tidak didefinisikan dengan pasti, dan oleh karena itu membuat staf testing sulit meng-estimasinya. Rex Black menyarankan untuk melibatkan sales, marketing, techiniccal support, dan business analyst.
C. Likehood. Kolom ini merepresentasikan kerentanan, dari 1 (paling rentan) sampai 5 (paling jarang), dari sudut pandang: a) keberadaan dalam produk (berdasarkan faktor risiko teknis seperti kompleksitas dan histori kecacatan); b) di luar proses pengembangan saat ini; dan, c) intruksi pada operasi user. Skala yang digunakan sebagai berikut:
1. Pasti mempengaruhi semua user.
2. Sepertinya akan mempengaruhi beberapa (banyak) user. 3. Dapat mempengaruhi beberapa (banyak) user.
4. Pengaruh terbatas pada beberapa (sedikit) user. 5. Tidak dapat dibayangkan dalam penggunaan nyata.
Penomoran ini memerlukan baik penilaian teknis maupun pemahaman akan komunitas user. Oleh karena itu partisipasi programmer dan insinyur lain berasama business analyst, technical support, marketing dan sales sangat penting.
2.10 Fit /Gap Analysis
2.10.1 Pengertian Fit/Gap Analysis
Menurut Pol dan Paturkar (2011: 2), Fit/Gap Analysis (FGA) adalah metodologi yang digunakan untuk membandingkan proses bisnis dengan fungsi sistem dimana akan di lakukan evaluasi dan di urutkan prioritasnya untuk melihat pencapaian apakah terjadi kecocokan (Fit) dan kesenjangan (Gap).
Menurut Hoffman dan Bateson (2006: 334), Gap Analysis adalah suatu alat yang digunakan untuk mengetahui mengenai kondisi aktual yang sedang berjalan di perusahaan tersebut, untuk kemudian diperbandingkan dengan sumber daya perusahaan tersebut. Hal tersebut dilakukan agar dapat mengetahui apakah suatu perusahaan sudah bergerak di proses bisnisnya secara optimal untuk memaksimalkan kinerja perusahaan tersebut.
Dalam proses Fit/Gap Analysis terdapat dua pengertian umum, yang pertama membandingkan proses bisnis yang berjalan dengan proses bisnis best practice untuk jenis perusahaan tertentu, yang kedua membandingkan proses bisnis yang berjalan sekarang dengan user requirement yang telah ditentukan di awal implementasi sistem.
2.10.2 Tujuan Analisis
Fit/Gap analysis bertujuan untuk mengevaluasi kebutuhan pengguna terhadap sistem dan mengidentifikasikan apakah Fit atau Gap antara kebutuhan pengguna dengan sistem. Fit berarti kebutuhan / requirement terpenuhi oleh sistem. Sedangkan Gap berarti kebutuhan / requirement tidak terpenuhi oleh sistem.
Tujuan dari analisis Fit/Gap adalah ([http 2]): a. Mengumpulkan requirement dari perusahaan.
b. Langkah awal untuk menentukan penyesuaian (customization) yang diperlukan.
c. Memastikan sistem yang baru memenuhi kebutuhan proses bisnis perusahaan.
d. Memastikan bahwa proses bisnis akan menjadi “Best Practice”. Mengadopsi best practice industri kepada lokal proses yang berjalan.
e. Mengidentifikasikan permasalahan yang membutuhkan perubahan kebijakan
2.10.3 Langkah-langkah Fit/Gap Analysis 2.10.3.1 Ranking Requirement
Tahapan ini mendukung tim proyek dan sponsor proyek untuk memastikan proses bisnis dapat diakomodasikan selama implementasi sistem yang baru. Selain itu, berfungsi untuk memastikan tim proyek berfokus pada area yang paling penting bagi organisasi
agar functionality yang baru dapat memberikan nilai tambah bagi perusahanaan dalam meningkatkan proses bisnis.
Requirement harus diidentifikasikan sesuai dengan tingkat prioritasnya. Adapun tingkat prioritasnya dijelaskan sebagai berikut:
b. High Critical Requirement (Mission critical requirement): Merupakan requirement yang sangat penting untuk kegiatan operasi dan tanpa requirement tersebut perusahaan tidak dapat berfungsi, termasuk didalamnya kebutuhan akan pelaporan internal dan eksternal yang penting.
c. Medium Critical Requirement (Value add requirement): Merupakan requirement di mana ketika dipenuhi akan meningkatkan proses bisnis perusahaan.
d. Low Critical Requirement (Desirable requirement): Merupakan reqirement yang hanya menambah nilai yang kecil / minor value bagi proses bisnis perusahaan apabila requirement tersebut dipenuhi.
Adapun requirement tersebut akan dikelompokkan berdasarkan kategori, yaitu:
a. Operasional: requirement pada kategori operasional merupakan requirement yang bersifat sebagai peningkatan produktivitas karyawan seperti efisiensi waktu, dan penyempurnaan operasional.
b. Strategis: requirement pada kategori strategis merupakan requirement yang bersifat sebagai alat pendukung pengambilan keputusan bagi pihak manajemen.
2.10.3.2 Degree of Fit
Degree of Fit menentukan sejauh mana kebutuhan dapat diakomodir oleh sistem yang baru. Dibagi menjadi : Fit, Gap, Partial Fit.
Tabel 2.1 Degree of Fit/Gap Analysis
Kode Keterangan
F FIT – kebutuhan sepenuhnya dipenuhi oleh software
G GAP – software tidak dapat memenuhi kebutuhan. Komentar, alternatif saran dan rekomendasi yang dibuat akan menghasilkan rekomendasi untuk melakukan customization terhadap software.
Sumber: ([http 1])
2.10.3.3 Gap Resolution
Saat gap ditemukan, tim akan menentukan alternatif dan rekomendasi solusi untuk mengatasi gap yang ada. Terdapat beberapa jalan untuk menyelesaikan gap seperti mengubah proses bisnis, mendesain lingkungan bisnis atau mengkustomisasi SAP ERP versi yang digunakan.
Pilihan-pilihan untuk gap resolution, diantaranya adalah:
a. Package Work Around: pertama kali tim akan mengidentifikasi jalan alternatif untuk mencapai kebutuhan dengan proses yang ada di SAP.
b. Membuat bisnis sesuai dengan Package: jika opsi pertama tidak memungkinkan, sebaiknya merekomendasikan perubahan potensial pada proses bisnis untuk disesuaikan dengan proses pada SAP dan mengeliminasi gap yang terjadi.
P Partial fit – software mempunyai fungsional yang memenuhi kebutuhan. Perubahan sementara, laporan khusus atau customization, bagaimanapun akan dibutuhkan kemudian agar dapat memenuhi kebutuhan secara maksimal
c. Customization: ini adalah jalan terakhir, strategi yang dipilih adalah membangun fungsionalitas baru di luar SAP dan memisahkan package dari pada mengubah package. Yang merupakan customization dari paket SAP adalah perubahan pada aplikasi yang memerlukan campur tangan staf pengembangan, atau beberapa perubahan yang dapat berdampak kurang baik untuk kemampuan upgrade pada software yang akan datang, contohnya :
1. Membuat atau memodifikasi menu, field atau kode SAP.
2. Membuat atau memodifikasi proses SAP. 3. Membuat laporan baru atau modifikasi untuk
menghasilkan laporan SAP.
4. Mengubah kode SAP untul
mengimplementasikan level keamanan.
2.11 Risk Analysis and Identification 2.11.1 Pengertian
Menurut Marchewka (2010: 207), identifikasi risiko pada tahap proses manajemen risiko adalah menentukan risiko mana yang mempengaruhi suatu proyek. Identifikasi risiko biasanya termasuk project stakeholder dan membutuhkan sebuah pemahaman dari tujuan proyek juga lingkup, jadwal, anggaran, dan tujuan kualitas proyek.
Menurut Schwalbe (2010: 434), identifikasi risiko adalah sebuah proses pemahaman kejadian potensial mana yang dapat merugikan atau meningkatkan sebuah obyek tertentu. Sangat penting untuk menentukan risiko potensial lebih cepat, tetapi juga harus berlanjut untuk mengidentifikasi risiko yang berdasarkan perubahan lingkungan proyek. Di dalam identifikasi risiko terdapat penentuan risiko mana yang mungkin mempengaruhi sebuah proyek dan mendokumentasi karakteristik dari masing-masing risiko. Output dari proses ini adalah permulaan dari sebuah risk register.
2.11.2 Alat dan Teknik untuk Identifikasi Risiko
Teknik yang digunakan untuk mengidentifikasi dan memahami dasar dari risiko proyek adalah dengan melakukan tanya-jawab dengan beberapa stakeholder. Teknik ini dapat membuktikan kegunaan untuk menentukan alternatif dari pandangan seseorang, tetapi kualitas informasi yang diperoleh tergantung dari keahlian pihak penanya dan pihak yang ditanya.
2.11.3 Analisis dan Penilaian Risiko
Menurut Marchewka (2010: 217), analisis dan penilaian risiko menyediakan sebuah pendekatan sistematis untuk mengevaluasi risiko-risiko yang telah diidentifikasi oleh stakeholders. Tujuan dari analisis risiko adalah untuk menentukan kemungkinan dan dampak dari masing-masing risiko pada proyek. Penilaian risiko, pada sisi lain, fokus pada memprioritaskan berbagai risiko sehingga sebuah strategi risiko yang
efektif dapat diformulasikan. Secara ringkas, risiko mana yang harus direspon? Untuk derajat yang tinggi, ini akan ditentukan oleh toleransi stakeholder terhadap risiko.
Terdapat dua dasar pendekatan untuk menganalisis dan menilai risiko proyek. Pendekatan pertama lebih kualitatif sifatnya karena terdiri atas penilaian subjektif yang didasarkan pada pengalaman atau instuisi. Analisis kuantitatif, berdasarkan pada teknik matematika dan statistika. Masing-masing pendekatan memiliki kekuatan dan kelemahan ketika dihadapkan pada ketidakpastian, maka kombinasi dari metode kualitatif dan kuantitatif menyediakan wawasan yang bernilai ketika melakukan penilaian dan analisis risiko, yaitu pendekatan kualitatif dan pendekatan kuantitatif.
2.11.4 Pendekatan Kualitatif (Qualitative Approach)
Menurut Marchewka (2010: 207), analisis risiko kualitatif pada tahap proses manajemen risiko difokuskan pada analisis kualitas yang berkenaan dengan dampak dan kemungkinan dari risiko risiko yang telah diidentifikasikan.
Analisis risiko kualitatif berfokus pada analisis risiko yang subjektif berdasarkan pengalaman dan penilaian dari project stakeholder. Walaupun teknik-teknik untuk menganalisis risiko proyek secara kualitatif dapat dilakukan oleh masing masing stakeholder, tetapi dapat menjadi lebih efektif jika dilakukan secara berkelompok. Proses berkelompok ini memperkenankan masing-masing stakeholder mendengarkan pandangan yang lain dan mendukung komunikasi yang
terbuka diantara berbagai stakeholder. Sebagai hasilnya, pandangan yang luas dari ancaman, kesempatan , isu-isu dan sudut pandang dapat didiskusikan dan dimengerti.
Menurut Schwalbe (2010: 464), analisis risiko kualitatif menilai kemungkinan dan dampak atas risiko-risiko yang teridentifikasi untuk menentukan tingkat dan prioritas.
2.11.5 Pendekatan Kuantitatif (Quantitative Approach)
Biasanya analisis risiko kuantitatif merupakan kelanjutan dari analisis risiko kualitatif, di mana kedua proses dapat dikerjakan secara bersamaan, atau secara terpisah. Namun pada beberapa proyek dapat dilakukan analisis risiko kualitatif saja tanpa diikuti analisis risiko kuantitatif. Analisis risiko kuantitatif mencakup pengukuran kemungkinan dan konsekuensinya dari risiko secara numerik dan mengestimasi dampaknya pada tujuan proyek.
Menurut Schwalbe (2010: 466), Pendekatan kuantitatif ini merupakan pengukuran risiko yang dihubungkan dengan perhitungan numerik, nilai-nilai dari sumber daya ditentukan jumlahnya, dan menhitung frekuensi dari terjadinya ancaman dan kerentanan dari probabilitas kerugian. Pada proses ini melibatkan proses pengukuran probabilitas dan konsekuensi dari risiko dan mengestimasi efeknya pada tujuan proyek. Setelah mengidentifikasikan risiko, tim proyek dapat menggunakan metode dan teknik untuk mengidentifikasikan kuantitas risiko dan mengestimasikan probabilitas dalam pencapaian tujuan proyek.
2.11.6 Matriks Peluang/Dampak (Probability/Impact Matrix)
Menurut Schwalbe (2010: 465), seorang manajer proyek dapat menuangkan dalam bentuk grafik peluang dan dampak risiko pada Matriks Peluang/Dampak. Sebuah Matriks Peluang/Dampak mendaftarkan peluang dari sebuah risiko yang muncul pada satu sisi dari matriks dan dampak yang berhubungan dengan risiko pada sisi lainnya. Banyak tim proyek memperoleh keuntungan dengan menggunakan teknik sederhana ini untuk membantu mereka mengidentifikasikan risiko yang perlu mereka perhatikan. Untuk menggunkana pendekatan ini, project stakeholder mendaftarkan risiko-risiko yanng mereka perkirakan mungkin muncul atas proyek yang dilaksanakan. Mereka kemudian menentukan apakah risiko tersebut termasuk dalam kategori High (tinggi). Medium (Sedang), atau Low (Rendah) atas peluang timbulnya dan dampaknya jika risiko tersebut muncul.
Manajer proyek kemudian membuat ringkasan atas hasil dalam Probability/Impact Matrix. Tim proyek memposisikan risiko pada matriks, mengkombinasikan semua risiko umum, dan memutuskan di mana risiko-risiko tersebut diletakkan pada matriks. Tim proyek harus fokus pada setiap risiko yang termasuk pada kategori High dalam matriks. Tim proyek harus mendiskusikan bagaimana mereka merencanakan untuk merespon risiko-risiko tersebut jika terjadi.
Gambar 2.10 Probability/Impact Matrix
Sumber : Schwalbe. (2010: 464), Information Technology Project Management. (6th Edition).
Berikut penjelasan penentuan tingkat probability dan impact pada matrix tersebut :
1. Penilaian kemungkinan timbulnya risiko (probability) menggunakan Risk Probability Rank :
a. HIGH : kemungkinan akan timbulnya risiko relatif tinggi jika fungsi tidak digunakan
b. MEDIUM : kemungkinan akan timbulnya risiko jika fungsi tidak digunakan cukup tinggi
c. LOW: Kemungkinan akan timbulnya risiko jika fungsi tidak digunakan relatif rendah.
2. Penilaian dampak (impact) yang dapat timbul dikarenakan risiko menggunakan Risk Impact Rank :
a. HIGH: dampak yang timbul dari risiko akan mempengaruhi dan menghambat aktivitas utama proses bisnis perusahaan.
b. MEDIUM: Dampak yang ditimbulkan dari risiko cukup mempengaruhi aktivitas utama proses bisnis perusahaan, namun tidak menghambat proses bisnis.
c. LOW: dampak yang ditimbulkan dari risiko sangat kecil bahkan tidak mempengaruhi aktivitas utama proses bisnis perusahaan.
2.12 Kerangka Evaluasi
Gambar 2.11 Kerangka Evaluasi
A. TAHAP 1
Failure Mode Effect Analysis (FMEA) digunakan untuk menilai kebutuhan (Requirement Assessment) untuk mengetahui kebutuhan tersebut berada memiliki prioritas pada nilai berapa. Berikut adalah keterangan cara penilaian :
Fit/Gap Analysis
FMEA
Risk Analysis
Ranking Requirement Fit/Gap Analysis Report Fit/Gap Analysis Report Result Business Process ListOverview Recommendation & Solution
Requirement Assessment
1. Severity
Tabel 2.2 Severity (FMEA) Description
Skala Arti Keterangan
1 Kehilangan data, kerusakan
perangkat keras, atau masalah keamanan.
Skala ini menunjukkan bahwa kegagalan pada sistem atau requirement akan mengakibatkan kehilangan data, kerusakan pada perangkat keras, atau masalah keamanan.
2 Kehilangan fungsionalitas yang tidak ada solusi.
Skala ini menunjukkan bahwa kegagalan pada sistem atau requirement akan mengakibatkan fungsi yang diharapkan pada requirement hilang sepenuhnya, serta tidak memiliki alternatif lain untuk memenuhi requirement tersebut.
3 Kehilangan fungsionalitas yang masih memiliki solusi.
Skala ini menunjukkan bahwa kegagalan pada sistem atau requirement akan mengakibatkan fungsi yang diharapkan pada requirement hilang sepenuhnya, tetapi masih memiliki alternatif lain untuk memenuhi requirement tersebut.
4 Kehilangan fungsionalitas parsial.
Skala ini menunjukkan bahwa kegagalan pada sistem atau requirement akan mengakibatkan fungsi yang diharapkan pada requirement tidak dapat berjalan sepenuhnya.
5 Kosmetik atau trivial.
Skala ini menunjukkan bahwa kegagalan pada sistem atau requirement bersifat tidak penting atau sepele.
2. Priority
Tabel 2.3 Priority (FMEA) Description
Skala Arti Keterangan
1 Kehilangan total dari nilai sistem.
Skala ini menunjukkan bahwa kegagalan pada sistem atau requirement akan mengakibatkan pengguna sistem sama sekali tidak dapat menggunakan fungsionalitas dari sistem atau requirement.
2 Kehilangan yang tidak bisa diterima dari nilai sistem.
Skala ini menunjukkan bahwa kegagalan pada sistem atau requirement akan mengakibatkan sistem tetap dapat berfungsi namun pengguna sistem kehilangan fungsionalitas dari sistem atau requirement.
3 Kehilangan yang mungkin dapat diterima pada nilai sistem.
Skala ini menunjukkan bahwa kegagalan pada sistem atau requirement akan mengakibatkan beberapa fungsionalitas sistem tidak dapat berjalan dan dibutuhkan oleh pengguna sistem, namun kegagalan tersebut masih dapat diterima oleh pengguna sistem.
4 Kehilangan yang dapat diterima pada nilai sistem.
Skala ini menunjukkan bahwa kegagalan pada sistem atau requirement akan mengakibatkan beberapa fungsionalitas sistem tidak dapat berjalan namun kegagalan tersebut dapat diterima oleh pengguna sistem.
Skala Arti Keterangan 5 Kehilangan yang
dapat diacuhkan pada nilai sistem.
Skala ini menunjukkan bahwa kegagalan pada sistem atau requirement akan mengakibatkan beberapa fungsionalitas sistem tidak dapat berjalan dan kegagalan tersebut tidak mempengaruhi pengguna sistem.
3. Likelihood
Tabel 2.4 Likelihood (FMEA) Description
Skala Arti Keterangan
1 Pasti mempengaruhi semua user.
Skala ini menunjukkan bahwa kegagalan pada sistem atau requirement akan mengakibatkan semua user yang berkaitan dengan sistem atau requirement tersebut tidak dapat menjalankan kegiatan operasionalnya.
2 Sepertinya akan mempengaruhi beberapa (banyak) user.
Skala ini menunjukkan bahwa kegagalan pada sistem atau requirement mungkin mengakibatkan beberapa (banyak) user yang berkaitan dengan sistem atau requirement tersebut tidak dapat menjalankan kegiatan operasionalnya.
3 Dapat
mempengaruhi beberapa (banyak)
Skala ini menunjukkan bahwa kegagalan pada sistem atau requirement mengakibatkan beberapa (banyak) user yang berkaitan dengan sistem atau
Skala Arti Keterangan
user. requirement tersebut tidak dapat menjalankan
kegiatan operasionalnya.
4 Pengaruh terbatas pada beberapa (sedikit) user.
Skala ini menunjukkan bahwa kegagalan pada sistem atau requirement mengakibatkan beberapa (sedikit) user yang berkaitan dengan sistem atau requirement tersebut tidak dapat menjalankan kegiatan operasionalnya.
5 Tidak dapat
dibayangkan dalam penggunaan nyata.
Skala ini menunjukkan bahwa kegagalan pada sistem atau requirement mengakibatkan user yang berkaitan dengan sistem atau requirement tersebut tidak dapat menjalankan kegiatan operasionalnya, namun jumlah user yang terpengaruh tidak dapat diidentifikasikan.
Setelah menentukan nilai Severity, Priority dan Likelihood akan didapat total nilai dari perkalian ketiganya yang disebut Risk Priority Number (RPN) :
RPN = Severity x Priority x Likelihood
B. TAHAP 2
Hasil Requirement Assessment akan menghasilkan RPN yang akan dipetakan pada Ranking Requirement dimana akan menentukan apakah suatu requirement memiliki rank High, Medium, atau Low. Langkah ini
adalah langkah pertama dalam melakukan Fit/Gap Analysis. Berikut tabel pemetaannya :
Tabel 2.5 Priority Description from FMEA Total
C. TAHAP 3
1.
Tahap selanjutnya pada Fit/Gap Analysis adalah Degree of Fit terdapat Fit/Gap Analysis Report yang mengevaluasi user requirement, menentukan apakah proses yang sedang berjalan sekarang sudah Fit atau Gap setelah dibandingkan dengan user requirement, dan menentukan rekomendasi atas user requirement yang Gap.Priority FMEA Total (RPN)
Description
High /
Mission Critical Requirements
1-42 Merupakan requirement yang penting bagi perusahaan dan dibutuhkan untuk operational sehingga tanpa requirement ini perusahaan tidak dapat berfungsi.
Medium / Value Add
Requirements
43-84 Merupakan requirement yang jika terpenuhi, akan secara signifikan meningkatkan proses namun tidak menghambat operational perusahaan.
Low
Requirements / Desirable
Requirements
85-125 Merupakan requirement yang tidak begitu perlu dipenuhi dan akan menambah sedikit nilai untuk proses bisnis jika dilakukan.
2.
Selanjutnya adalah Fit/Gap Analysis Report Result yang menerangkan hasil dari Fit/Gap Analysis Report dalam bentuk presentase yaitu presentase jumlah user requirement yang Fit dan Gap, presentase jumlah user requirement yang Fit atau Gap pada rank High, Medium, dan Low.3.
Setelah mengetahui hasil tersebut, perlu dilakukan Business Process List. Tahap ini akan dilakukannya pendaftaran proses bisnis yang menunjukkan daftar proses – proses apa saja yang berubah dan tidak berubah atau proses apa saja yang dihilangkan dengan proses bisnis yang diusulkan. Penjelasan akan menggunakan tabel yang terdiri dari:1. Requirement
Kebutuhan sistem yang mendukung proses bisnis. 2. Description
Keterangan dari proses yang dituliskan pada requirement 3. Old Process
Keterangan apakah suatu proses bisnis terdapat pada kondisi sistem lama (current). Tanda checklist () menandakan proses
tersebut ada, sedangkan tanda garis menandakan proses tersebut tidak ada.
4. New Process
Keterangan apakah suatu proses bisnis terdapat pada kondisi baru (rekomendasi). Tanda checklist () menandakan proses tersebut ada, sedangkan tanda garis menandakan proses tersebut tidak ada. 5. Keterangan
lama (tidak diperbarui), proses baru, atau proses yang tidak digunakan lagi.
- Updated = proses diperbarui.
- New = proses baru.
- Deleted = proses dihilangkan.
- Tanpa keterangan (-) = proses tidak mengalami perubahan.
D. TAHAP 4
Sebelum masuk pada tahap terakhir pada Fit/Gap Analysis yaitu Gap Resolution, dilakukan Risk Analysis yang mengidentifikasi risiko yang mungkin terjadi apabila perusahaan tidak menjalankan rekomendasi yang diberikan. Dan penentuan user requirement / proses yang mana yang menjadi prioritas pertama, kedua, ketiga dan seterusnya untuk diterapkan sesuai rekomendasi yang diberikan.
E. TAHAP 5
Tahap terakhir yaitu overview recommendation dan solution yang merupakan langkah terakhir pada Fit/Gap Analysis yaitu Gap Resolution. Overview recommendation adalah gambaran secara detil mengenai rekomendasi yang telah dibuat pada Fit/Gap analysis report dan merupakan langkah-langkah teknis ke sistem. Sedangkan solution merupakan business impact atas rekomendasi yang diberikan baik dari segi perubahan proses bisnis, perubahan struktur organisasi, dan procurement policy.
