BAB 2 LANDASAN TEORI
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 orangorang, hardware, software, jaringan komunikasi, dan data yang saling berhubungan yang bekerja sama untuk mengumpulkan, mengubah, memproses, menyimpan, dan menyebarkan informasi yang dibutuhkan untuk mendukung
8
9
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
10
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.
11
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
12
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
13
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,
14
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.
15
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-
16
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
17
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 :
18
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.
19
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.
20
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.
21
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 seharihari. 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
22
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
23
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.
24
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.
25
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.
26
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 komponenkomponen ini harus disediakan untuk subcontractor. Material yang disediakan tidak lagi ada secara fisik di perusahaan namun meskipun begitu tetap dimaintain 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.
27
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
dibutuhkan
untuk
management memantau
pergeseran barang. c. Data accounting diperlukan untuk penilaian material.
28
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
ditemukan
informasi
dapat
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
29
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
merupakan
yang
bagian
valid dari
yang 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
30
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
31
kontrol
yang
berkaitan
dengan
vendor.
2.6.1.3.3 Purchasing Information Record Purchasing menyediakan
Information pilihan
Record
penyimpanan
informasi mengenai vendor dan material, seperti master data pada purchasing organization dan plant level. (SCM 500: 254) Dari
keterangan
disimpulkan Record
bahwa
merupakan
di
atas
dapat
Purchasing tempat
Info
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
32
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 hargaharga dan kondisi dari vendor dan merupakan
dasar
dalam
procurement ‘vendor selection’.
tahap
33
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 merupakan
tanda
komitmen
SAP 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
34
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 penyimpanan
ke
lokasi
satu lokasi penyimpanan
lainnya. Stock transfer di sistem Material Management
antara
lain
termasuk
35
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
36
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 Sumber : Anonim 1. (2006: 109), SCM 500
37
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
38
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:
39
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
Menentukan
pembelian
dan
produksi.
kekurangan
dan
menghasilkan elemen pengadaan barang terkait, termasuk diantaranya planned order, purchase requisition, dan schedule lines. Pada in-house production, sistem membuat perencanaan
planned
orders
produksi.
untuk Setelah
perencanaan lengkap, planned orders diubah menjadi production orders. Pada external procurement, sistem membuat planned order atau purchase requisition perencanaan
secara
langsung
external
untuk
procurement
quantity. Planned order dan purchase
40
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).
41
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
42
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. 5. Kosmetik atau trivial.
43
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.
44
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.
45
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
46
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
requirement
kegiatan
tersebut
operasi
perusahaan
dan
tanpa
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.
47
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.
48
Partial fit – software mempunyai fungsional yang
P
memenuhi
kebutuhan.
Perubahan
sementara,
laporan khusus atau customization, bagaimanapun akan dibutuhkan kemudian agar dapat memenuhi kebutuhan secara maksimal
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.
49
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.
50
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 risikorisiko yang telah diidentifikasi oleh stakeholders. Tujuan dari analisis risiko adalah untuk menentukan kemungkinan dan dampak dari masingmasing risiko pada proyek. Penilaian risiko, pada sisi lain, fokus pada memprioritaskan berbagai risiko sehingga sebuah strategi risiko yang
51
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
52
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.
53
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
menggunakan
tim
teknik
proyek sederhana
memperoleh ini
untuk
keuntungan
dengan
membantu
mereka
mengidentifikasikan risiko yang perlu mereka perhatikan. Untuk menggunkana pendekatan ini, project stakeholder mendaftarkan risikorisiko 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.
54
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.
55
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
Fit/Gap Analysis
FMEA
Requirement Assessment
Ranking Requirement
Fit/Gap Analysis Report
Risk Analysis
Business Process List
Fit/Gap Analysis Report Result
Overview Recommendation & Solution
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 :
56
1.
Severity Tabel 2.2 Severity (FMEA) Description
Skala 1
Arti
Keterangan
Kehilangan data, Skala ini menunjukkan bahwa kegagalan pada sistem atau kerusakan
requirement akan mengakibatkan kehilangan data, kerusakan
perangkat atau
keras, pada perangkat keras, atau masalah keamanan. masalah
keamanan. 2
Kehilangan
Skala ini menunjukkan bahwa kegagalan pada sistem atau
fungsionalitas
requirement akan mengakibatkan fungsi yang diharapkan
yang
3
tidak
solusi.
alternatif lain untuk memenuhi requirement tersebut.
Kehilangan
Skala ini menunjukkan bahwa kegagalan pada sistem atau
fungsionalitas
requirement akan mengakibatkan fungsi yang diharapkan
yang
4
5
ada pada requirement hilang sepenuhnya, serta tidak memiliki
masih pada requirement hilang sepenuhnya, tetapi masih memiliki
memiliki solusi.
alternatif lain untuk memenuhi requirement tersebut.
Kehilangan
Skala ini menunjukkan bahwa kegagalan pada sistem atau
fungsionalitas
requirement akan mengakibatkan fungsi yang diharapkan
parsial.
pada requirement tidak dapat berjalan sepenuhnya.
Kosmetik trivial.
atau Skala ini menunjukkan bahwa kegagalan pada sistem atau requirement bersifat tidak penting atau sepele.
57
2.
Priority Tabel 2.3 Priority (FMEA) Description
Skala 1
Arti Kehilangan
Keterangan total Skala ini menunjukkan bahwa kegagalan pada sistem
dari nilai sistem.
atau requirement akan mengakibatkan pengguna sistem sama sekali tidak dapat menggunakan fungsionalitas dari sistem atau requirement.
2
Kehilangan
yang Skala ini menunjukkan bahwa kegagalan pada sistem
tidak bisa diterima atau requirement akan mengakibatkan sistem tetap dapat dari nilai sistem.
berfungsi
namun
pengguna
sistem
kehilangan
fungsionalitas dari sistem atau requirement.
3
Kehilangan mungkin
yang Skala ini menunjukkan bahwa kegagalan pada sistem dapat atau
requirement
diterima pada nilai fungsionalitas
akan
sistem
mengakibatkan
tidak
dapat
beberapa
berjalan
dan
dibutuhkan oleh pengguna sistem, namun kegagalan
sistem.
tersebut masih dapat diterima oleh pengguna sistem. 4
Kehilangan dapat
yang Skala ini menunjukkan bahwa kegagalan pada sistem diterima atau
pada nilai sistem.
requirement
akan
mengakibatkan
beberapa
fungsionalitas sistem tidak dapat berjalan namun kegagalan tersebut dapat diterima oleh pengguna sistem.
58
Skala 5
Arti
Keterangan yang Skala ini menunjukkan bahwa kegagalan pada sistem
Kehilangan
diacuhkan atau
dapat
pada nilai sistem.
requirement
akan
mengakibatkan
beberapa
fungsionalitas sistem tidak dapat berjalan dan kegagalan tersebut tidak mempengaruhi pengguna sistem.
3.
Skala 1
Likelihood
Arti
Tabel 2.4 Likelihood (FMEA) Description Keterangan
Pasti mempengaruhi Skala ini menunjukkan bahwa kegagalan pada sistem atau requirement akan mengakibatkan semua
semua user.
user yang berkaitan dengan sistem atau requirement tersebut
tidak
dapat
menjalankan
kegiatan
operasionalnya. 2
akan Skala ini menunjukkan bahwa kegagalan pada
Sepertinya mempengaruhi beberapa
sistem atau requirement mungkin mengakibatkan
(banyak) beberapa (banyak) user yang berkaitan dengan
user.
sistem atau requirement tersebut tidak dapat menjalankan kegiatan operasionalnya.
3
Dapat
Skala ini menunjukkan bahwa kegagalan pada
mempengaruhi
sistem atau requirement mengakibatkan beberapa
beberapa (banyak)
(banyak) user yang berkaitan dengan sistem atau
59
Skala
Arti
Keterangan requirement tersebut tidak dapat menjalankan
user.
kegiatan operasionalnya. 4
terbatas Skala ini menunjukkan bahwa kegagalan pada
Pengaruh pada
beberapa sistem atau requirement mengakibatkan beberapa (sedikit) user yang berkaitan dengan sistem atau
(sedikit) user.
requirement tersebut tidak dapat menjalankan kegiatan operasionalnya. 5
dapat Skala ini menunjukkan bahwa kegagalan pada
Tidak
dibayangkan dalam sistem atau requirement mengakibatkan user yang penggunaan nyata.
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
60
adalah langkah pertama dalam melakukan Fit/Gap Analysis. Berikut tabel pemetaannya : Tabel 2.5 Priority Description from FMEA Total Priority
FMEA Total
Description
(RPN) High /
1-42
Merupakan requirement yang penting bagi perusahaan dan dibutuhkan untuk operational sehingga tanpa
Mission Critical
requirement ini perusahaan tidak dapat berfungsi.
Requirements Medium / Value
43-84
Merupakan requirement yang jika terpenuhi, akan
Add
secara signifikan meningkatkan proses namun tidak
Requirements
menghambat operational perusahaan.
Low
85-125
Requirements
/
Merupakan requirement yang tidak begitu perlu dipenuhi dan akan menambah sedikit nilai untuk proses bisnis jika dilakukan.
Desirable Requirements
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.
61
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 Keterangan jika proses tersebut diperbarui, merupakan proses
62
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.
