Enterprise Resource Planning

Please Red this article 
Enterprise Resource Planning (ERP) 

Mengacu pada pendapat Motiwalla dan Jeff (2009: 7) pengertian Sistem ERP (Enterprise Resource Planning) dapat dikemukakan sebagai generasi pertama dari sistem perusahaan yang tujuannya adalah untuk mengintegrasikan data secara menyeluruh dalam mendukung semua fungsi utama perusahaan. Menurut Holtsnider dan Brian (2012: 219), ERP memiliki definisi yang luas. ERP digunakan dalam berbagai cara untuk serangkaian kegiatan yang terlibat dalam perusahaan untuk mengelola seluruh sumber daya yang ada di dalam perusahaan tersebut. 

Berdasarkan pendapat Leon (2008: 14), ERP adalah teknik-teknik dan konsep-konsep untuk pengelolaan terintegrasi suatu bisnis secara menyeluruh dari sudut pandang penggunaan secara efektif sumber daya manajemen untuk meningkatkan efisiensi manajemen perusahaan. 

Ritel 

Mengacu pada pendapat Fazriyah (2008: 4), ritel adalah sebuah bisnis yang bersentuhan langsung dengan kebutuhan konsumen dan dijual secara eceran. Mengacu pada pendapat Mathur ritel dapat didefinisikan dengan menjual barang kepada pelanggan biasanya dalam kuantitas yang kecil dan tidak untuk di jual kembali. 

Point of Sales (POS) 

Menurut Hendry (2010: 1), Point of Sales (POS) adalah sebuah sistem yang terdiri dari hardware dan software yang didesain sesuai dengan keperluan dan dapat diintegrasikan dengan beberapa alat pendukung agar dapat membantu mempercepat proses transaksi. Menurutnya, sistem POS digunakan di supermarket, restoran, hotel, dan tempat-tempat lain yang membuka jasa ritel. Dalam lingkup yang luas, POS juga berarti proses pelayanan transaksi dalam sebuah toko ritel. 

SAP 

Berpusat di Walldorf, Jerman, SAP adalah pemimpin pasar dalam software aplikasi enterprise. Didirikan pada tahun 1972, SAP (System, Applications, Products in Data Processing) mempunyai sejarah yang kaya akan inovasi dan pertumbuhan dari pemimpin industri yang sesungguhnya. SAP mempunyai lebih dari 54.000 karyawan dan mempunyai lokasi penjualan dan pengembangan lebih dari 50 negara di seluruh dunia. (Wan & Jiajun. Mengacu pada pendapat Kogent Learning Solutions,Inc. (2011: 1), SAP adalah sebuah software bisnis yang dapat disesuaikan berdasarkan pada persyaratan dari user. 

Error 

Error merupakan ketidaksesuaian antara nilai yang sebenarnya dengan hasil yang diberikan oleh software dan nilai benar tertentu dari hasil untuk masukan yang diberikan. Jelasnya, error merujuk kepada perbedaan antara hasil yang sebenarnya dari software dengan hasil yang benar. Error juga digunakan untuk merujuk kepada keputusan yang salah yang diberikan dalam kasus dibandingkan dengan hasil yang benar. Error juga merujuk kepada tindakan manusia yang menyebabkan software menjadi rusak atau salah. (Agarwal, Tayal, Gupta.

Faults 

Fault merupakan suatu kondisi yang menyebabkan sistem gagal menjalankan fungsi yang diperlukan. Fault merupakan alasan utama untuk kegagalan pemakaian software, dan biasanya disebut dengan bug. Walaupun input yang diberikan benar telah dimasukkan ke dalam sistem, tetapi tetap terjadi kegagalan, maka kita dapat mengatakan bahwa sistem tersebut memiliki fault atau bug dan membutuhkan perbaikan. (Agarwal, Tayal, Gupta.

Failure 

Failure merupakan ketidakmampuan dari software untuk menjalankan fungsi yang diperlukan berdasarkan spesifikasinya. Dengan kata lain, ketika software tetap melakukan pemrosesan tanpa menunjukkan error atau fault walaupun masukan tertentu dan spesifikasi proses dilanggar, maka hal tersebut disebut dengan software failure. (Agarwal, Tayal, Gupta, 2010:190) 

Activity Diagram 

Mengacu pada pendapat Satzinger, Jackson, dan Burd (2010, p141), activity diagram adalah salah satu jenis workflow diagram yang menggambarkan alur aktivitas – aktivitas pengguna secara berurutan. Menurutnya, workflow adalah urutan langkah-langkah untuk memproses transaksi-transaksi bisnis. Swimlane menggambarkan aktor atau orang yang melakukan aktivitas. Starting activity (pseudo) menggambarkan titik awal dimulainya suatu aktivitas dari diagram tersebut. Transition arrow menggambarkan alur aktivitas. Activity menggambarkan aktivitas yang ada dalam suatu proses bisnis. Ending activity (pseudo) menggambarkan titik berakhirnya pelaksanaan aktivitas dalam suatu proses bisnis. Synchronization bar digunakan untuk menggambarkan aktivitas-aktivitas yang dilakukan secara bersamaan. Decision activity digunakan untuk menggambarkan pengambilan keputusan yang dilakukan oleh pelaku bisnis. (Satzinger, Jackson, dan Burd.Untuk menggambarkan interaksi antara satu activity diagram dengan activity diagram yang lain digunakan simbol sebagai berikut: 

Simbol tersebut digunakan seperti simbol activity, hanya simbol ini menggambarkan nama activity diagram lain yang berinteraksi dengannya. Memang belum ada call activity action resmi dalam spesifikasi UML, meskipun simbol tersebut ada di dalam 

Product Specifications 

Product specification atau sering dikenal sebagai functional specification merupakan definisi fungsi-fungsi yang dibutuhkan untuk memenuhi kebutuhan pengguna.

Integrasi antara SAP Business One dengan IReap POS

SAP Business One dan IReap POS merupakan dua aplikasi yang diterapkan di lingkungan yang berbeda, dimana SAP Business One dimaksudkan untuk back-end user dan IReap POS untuk front-end user. Keduanya saling berkaitan, data-data yang dimasukkan melalui IReap POS akan dikirimkan ke SAP Business One untuk diolah lagi. Selain itu, ada juga data-data yang diinput dari SAP Business One akan dikirimkan ke IReap POS untuk kebutuhan operasional. 

Tidak semua data yang dimasukkan melalui IReap POS dikirimkan ke SAP Business One. Begitu juga sebaliknya, tidak semua data yang dimasukkan melalui SAP Business One akan dikirimkan ke IReap POS. Secara garis besar, integrasi antara IReap POS dengan SAP Business One dapat dilihat pada gambar dibawah ini. 

Data yang dikirim dari SAP Business One ke SAP Business One menggunakan format XML, begitu juga dengan data yang dikirimkan dari IReap POS ke IReap POS. Kedua aplikasi tersebut sama-sama menghasilkan file XML, tetapi format struktur data yang dihasilkan tentunya berbeda. Untuk menyamakan format/ template struktur data antara kedua aplikasi tersebut dibutuhkan proses transformasi. Secara rinci, terdapat enam proses utama dalam integrasi antara IReap POS dengan SAP Business One. Keenam proses tersebut adalah sebagai berikut: 

1. Export dari POS Server 

2. Tranformasi dari dokumen IReap POS ke dokumen SAP Business One 

3. Inbound ke SAP Business One 

4. Outbound dari SAP Business One 

5. Transformasi dari dokumen SAP Business One ke dokumen IReap POS 

6. Import ke POS Server 

Pada saat terjadi proses import – export dan inbound – outbound, masih banyak proses detail yang dijalankan bersamaan. Untuk lebih detailnya dapat dilihat pada gambar dibawah ini. 

Test Tracking Spreadsheet 

Untuk memudahkan pengelolaan terhadap pelaksanaan pengujian dapat digunakan sebuah alat yang dinamakan sebagai test tracking spreadsheet. Dengan penggunaan test tracking spreadsheet, akan memungkinkan tester untuk melacak setiap status dari test case, mengetahui konfigurasi yang digunakan dan mengetahui siapa yang telah melaksanakan pengujian terhadap suatu test case. (Black, 2009: 200) 

Kolom pertama dari test tracking spreadsheet tersebut berisi namatest suite/ test case dari suatu pengujian. Kolom state menggambarkan status dari tiap test case. Jika kolom state ini kosong, maka mengindikasikan bahwa test case tersebut masih dalam antrian untuk dilakukan pengujian. Jika kolom ini berisi pass, maka berarti bahwa pengujian untuk test case tersebut tidak menemukan bug. Jika berisi fail, maka berarti ada bug yang ditemukan dari pengujian test case tersebut baik satu maupun lebih. 

Kolom system config berisi keterangan identifikasi untuk mengetahui konfigurasi sistem yang digunakan oleh tiap test case. Kolom bug id berisi identitas dari bug yang ditemukan dari hasil pengujian test case. Kolom ini yang nantinya akan memudahkan test team untuk melacak bug tersebut dan mereferensikannya terhadap bug report yang dibuat dalam bug tracking database. 

Kolom by berisi inisial dari tester yang telah melakukan pengujian terhadap test case. Kolom comment berisi komentar dari tester atau informasi tambahan mengenai status dari tiap test case. Kolom roll up berisi ringkasan dari informasi mengenai status dari tiap test case. Kolom ini terbagi menjadi tiga kolom, yaitu: 

a) Kolom T berisi nilai 1 jika merupakan test case. 

b) Kolom F berisi nilai 1 jika status dari test case adalah fail. 

c) Kolom P berisi nilai 1 jika status dari test case adalah pass. 

Bug Report 

Mengacu pada pendapat Black (2009: 146), bug report adalah dokumen teknis yang digunakan untuk mendeskripsikan berbagai gejala ataupun kegagalan yang berhubungan dengan suatu bug tertentu secara spesifik. Suatu dokumen bug report yang dirancang dengan baik dapat memberikan informasi yang tepat bagi tim manajemen proyek mengenai bug tersebut sehingga dapat mengambil keputusan yang tepat (misalnya, apakah bug tersebut harus segera diperbaiki atau tidak). Selain itu, bug report juga dapat digunakan oleh para programmer atau developer untuk mengetahui informasi rinci mengenai suatu bug sehingga memudahkan penyelesaian bug tersebut. 

Field Bug ID berisi pengidentifikasi dari suatu bug yang dapat dijadikan referensi dari suatu test tracking spreadsheet. Field Project Name berisi informasi mengenai nama proyek dimana bug tersebut ditemukan. Field Tester berisi informasi mengenai namatester yang menemukan bug tersebut. Field Date Opened berisi informasi mengenai tanggal bug tersebut dimasukkan ke dalam bug tracking database. 

Field Quality Risk Category: Detail berisi informasi mengenai kategori rinci dari quality risk yang ditentukan secara spesifik berdasarkan bug tersebut. Field Subsystem berisi informasi mengenai subsystem dimana bug tersebut ditemukan. Field Configuration berisi informasi mengenai konfigurasi yang digunakan saat melakukan pengujian. 

Field Severity dan Priority diisi dengan skala yang sama dengan yang telah dijelaskan pada bagian failure mode and effects analysis. Field RPN pada bug report didapat dari perkalian antara penilaian severity dan priority. Dengan demikian, range dari RPN adalah berkisar antara 1 – 25, dimana nilai 1 mengindikasikan bahwa bug tersebut sangat berbahaya dan nilai 25 mengindikasikan bahwa bug tersebut hanya hal sepele yang dapat diabaikan. 

Field summary berisi uraian singkat mengenai bug. Field steps to reproduce menyediakan suatu deskripsi yang tepat dan jelas tentang bagaimana menghasilkan kembali bug tersebut. Field isolation berisi informasi untuk menyakinkan developer/ programmer bahwa bug yang ditemukan tersebut adalah benar-benar bug. Hal ini bisa dengan menyebutkan gejala-gejala timbulnya bug tersebut dan bisa juga dengan menjelaskan dampak serta penyebab dari timbulnya bug tersebut. 

Field log berisi informasi rinci mengenai siklus hidup dari suatu bug mulai dari awal ketika bug tersebut di-entry ke dalam bug tracking database.Adapun gambaran siklus hidup dari bug report dapat dilihat pada gambar dibawah ini. 

State review menggambarkan status bug dimana bug telah di-input ke dalam bug tracking database dan menunggu untuk di­-review oleh reviewer sebelum bug tersebut diinformasikan kepada seluruh tim proyek pengembangan. State rejected menggambarkan status dimana bug tersebut ditolak oleh reviewer karena butuh penelitian atau informasi lebih lanjut mengenai bug tersebut. State open menggambarkan status dimana bug tersebut telah di-review dan dianggap relevan dengan informasi rinci mengenai bug tersebut dan diinformasikan keberadaannya kepada seluruh tim proyek pengembangan. 

State assigned menggambarkan status dimana bug tersebut ditugaskan kepada developer untuk mencari informasi lanjut mengenai bug tersebut serta menyelesaikannya. State test menggambarkan status dimana bug tersebut telah selesai diperbaiki oleh developer serta harus diuji untuk memastikan bahwa bug tersebut benar-benar sudah diperbaiki. 

State reopened menggambarkan status dimana bug dibuka kembali untuk diperbaiki lagi oleh developer.  State closed menggambarkan status dimana bug telah selesai diperbaiki dan telah dikonfirmasi kebenarannya melalui pengujian. State deferred dapat digunakan oleh anggota tim proyek untuk menunda perbaikan bug tersebut jika mereka menilai bahwa bug tersebut memiliki prioritas yang rendah. 

State cancelled dapat digunakan oleh anggota tim proyek untuk membatalkan perbaikan terhadap bug tersebut karena dinilai sudah tidak relevan lagi. Field Owner pada bug report menunjukkan nama orang yang bertanggung jawab terhadap bug tersebut. Dengan adanya field ini diharapkan manajer proyek dapat dengan lebih mudah melacak atau mencari informasi yang lebih rinci lagi mengenai bug tersebut. 

Field Estimated Fixed berisi informasi mengenai perkiraan tanggal bug tersebut selesai diperbaiki. Field Root Cause berisi informasi mengenai akar penyebab dari terbentuknya bug tersebut. Menurut Black root cause dari suatu bug secara umum dapat berupa: 

a) Functional 

Dari sisi functional, akar penyebab dari suatu bug dapat berupa spesifikasi yang salah, atau spesifikasinya benar tetapi implementasinya salah, atau sistem berfungsi dengan benar tetapi hasil pengujian melaporkan error yang salah. 

b) System 

Dari sisi system, akar penyebab dari suatu bug dapat berupa gagalnya komunikasi sistem internal, gagalnya hardware, gagalnya operating system, software architecture yang dibuat salah, atau asumsi perancangan sudah benar tetapi asumsi saat penerapannya salah. 

c) Process 

Dari sisi process, akar penyebab dari suatu bug dapat berupa salahnya operasional aritmatika yang diterapkan, proses inisialisasi yang salah, control atau sequence yang salah, ataupun error dalam pemrosesan. 

d) Data 

Dari sisi data, akar penyebab dari suatu bug dapat berupa tipe data yang digunakan salah, struktur data yang salah atau penyebab lainnya yang berhubungan dengan data. 

e) Code 

Dari sisi code, akar penyebab dari suatu bug dapat berupa salah pengetikan pada code. 

f) Documentation 

Dari sisi documentation, akar penyebab dari suatu bug dapat berupa salahnya dokumentasi terhadap sistem. 

g) Standards 

Dari sisi standards, akar penyebab dari suatu bug dapat berupa tidak terpenuhnya standar yang seharusnya terhadap sistem tersebut. 

h) Other 

Root cause dari bug dikategorikan ke dalam other jika akar penyebab dari bug telah diketahui tetapi tidak sesuai dengan kategori yang ada. 

i) Duplicate 

Root cause yang ini digunakan jika terdapat dua ataupun lebih bug report yang mendeskripsikan bug yang sama. 

j) NAP 

Dikategorikan sebagai NAP (Not a Problem) jika bug yang dilaporkan tersebut hanya karena pemahaman yang salah oleh tester. 

k) Bad Unit 

Root cause ini digunakan jika bug tersebut terjadi kata kegagalan hardware yang tidak diduga. 

l) RCN 

RCN (Root Cause Needed) digunakan jika status dari bug tersebut sudah closed tetapi tidak ada yang mengetahui akar penyebab dari terjadinya bug tersebut. 

m) Unknown 

Root cause unknown digunakan jika tidak ada orang yang mengetahui apa yang terjadi atas bug tersebut. 

1. Field Phase Injected mendeskripsikan fase dimana bug tersebut dikenalkan, biasanya pada fase awal sebelum fase dimana bug tersebut teridentifikasi. 
2. Field Phase Detected mendeskripsikan fase dimana bug tersebut teridentifikasi. 
3. Field Phase Removed mendeskripsikan fase dimana bug tersebut berhasil diperbaiki. 
4. Field Close Date menjelaskan tanggal dimana status dari bug tersebut menjadi closed. 
5. Field Resolution mendeskripsikan bagaimana bug tersebut diperbaiki. 

Dari semua bug report yang telah dimasukkan ke dalam bug tracking database maka dapat dibuatkan grafik-grafik yang mendukung sebagai laporan terhadap manajer proyek.

Failure Mode and Effects Analysis

Failure Mode and Effects Analysis (FMEA) 

Menurut Shirouyehzad, Dabestani, dan Badakhshian, implementasi ERP (enterprise resource planning) telah menjadi salah satu tantangan besar bagi perusahaan-perusahaan dalam dekade akhir ini dan terdapat banyak halangan untuk mengimplementasikan ERP dengan sukses. Perusahaan dapat mengurangi akibat dari kegagalan implementasi dengan mengidentifikasi apa yang menjadi kekuatan dan kelemahannya. Salah satu metode yang dapat diaplikasikan yang dapat mencegah terjadinya kecacatan (defect) dalam implementasi adalah failure mode and effect analysis (FMEA). 

FMEA merupakan teknik perancangan yang secara sistematis mengidentifikasi dan menginvestigasi kelemahan sistem yang potensial (produk atau proses) yang terdiri dari metodologi untuk menganalisa kemungkinan-kemungkinan bagaimana kegagalan sistem dapat terjadi, kegagalan-kegagalan yang mungkin terjadi (potential effects of failures) pada performa dan keamanan sistem, dan seberapa besar dampak dari masalah-masalah ini. Tujuan dari FMEA ini adalah untuk mencegah kegagalan yang tidak dapat diterima dan untuk membantu manajemen mengalokasikan sumber dayanya dengan lebih efisien. 

FMEA (Failure Mode and Effects Analysis) merupakan sebuah teknik untuk mengerti dan memprioritaskan cara-cara kegagalan yang mungkin (atau yang beresiko terhadap kualitas) dalam fungsi-fungsi sistem, fitur-fitur, atribut-atribut, kemampuan-kemampuan, komponen-komponen, dan interfaces. (Black, 2009: 32). 

1) System Function or Feature 

Dalam baris-baris yang ada, dimasukkan deskripsi yang singkat dari fungsi sistem. Jika yang dimasukkan merepresentasikan sebuah kategori, maka harus dibagi-bagi ke dalam fungsi-fungsi atau fitur-fitur spesifik dalam baris berikutinya.

2) Potential Failure Mode(s)—Quality Risk(s). 

Untuk tiap-tiap fungsi atau fitur spesifik (tapi bukan untuk kategori itu sendiri), yang dimasukkan ke dalam kolom ini mengidentifikasikan cara kegagalan itu ditemukan, yang berkaitan dengan resiko-resiko kualitas yang berhubungan dengan hilangnya sistem tertentu. Tiap-tiap fungsi atau fitur spesifik dapat mempunyai lebih dari satu ragam kegagalan (failure modes). 

3) Potential Effect(s) of Failure. 

Setiap ragam kegagalan dapat mempengaruhi user dalam satu atau lebih cara. Isi dalam kolom ini dibuat secara umum dibandingkan dengan mencoba mengantisipasi setiap hasil yang tidak inginkan. 

4) Critical? 

Dalam kolom ini, diindikasikan apakah efek-efek potensial tersebut mempunyai konsekuensi kritis bagi user. Apakah fitur atau fungsi produk tidak dapat digunakan sama sekali jika kegagalan ini terjadi? 

5) Severity 

Kolom severity ini (Black, 2009: 33) menunjukkan setiap efek dari kegagalan (segera ataupun tertunda) pada sistem. Digunakan skala 1 (terburuk) hingga 5 (paling tidak berbahaya), sebagai berikut: 

1. Hilangnya data, kerusakan hardware, atau masalah keamanan. 

2. Hilangnya fungsionalitas tanpa adanya solusi. 

3. Hilanznya fungsionalitas dengan adanya solusi. 

4. Hilangnya sebagian fungsionalitas. 

5. Hal-hal kecil lainnya. 

6) Potential Cause(s) of Failure 

Kolom ini mendaftarkan faktor-faktor yang mungkin memicu terjadinya kegagalan, contohnya kesalahan operating system, kesalahan user, atau penggunaan secara normal. (Black, 2009: 33). 

7) Priority 

Priority (Black, 2009: 34) berarti efek dari kegagalan terhadap user, customer, dan operator. Digunakan skala 1 (terburuk) hingga 5 (paling tidak berbahaya), sebagai berikut: 

1. Hilangnya nilai sistem secara total 

2. Kehilangan nilai sistem yang tidak dapat diterima 

3. Pengurangan nilai sistem yang mungkin dapat diterima 

4. Pengurangan nilai sistem yang dapat diterima 

5. Pengurangan nilai sistem yang tidak berarti 

8) Detection Method

Kolom ini mendaftarkan metode atau prosedur yang ada seperti aktivitas-aktivitas pengembangan atau pengujian vendor yang dapat menemukan masalah sebelum hal tersebut mempengaruhi user, kecuali tindakan-tindakan yang dilakukan nantinya (seperti membuat dan mengeksekusi test suite) yang mungkin dilakukan untuk menemukannya. 

9) Likelihood 

Angka pada kolom ini merepresentasikan kerentanan, dari 1 (paling mungkin) hingga 5 (paling tidak mungkin), yang berkaitan dengan: a) eksistensi dari produk yang berdasarkan pada faktor-faktor resiko teknis seperti kerumitan dan kecacatan yang pernah terjadi sebelumnya; b) lepas dari proses pengembangan yang ada; dan c) gangguan pada operasi user. Digunakan skala 1 sampai 5 seperti berikut ini 

1. Pasti mempengaruhi semua user 

2. Kemungkinan besar mempengaruhi sebagian user 

3. Mungkin mempengaruhi sebagian user 

4. Pengaruh terbatas ke beberapa user 

5. Tidak dapat dibayangkan dalam penggunaan sebenarnya. 

10) RPN (Risk Priority Number) 

Kolom ini menceritakan betapa pentingnya melakukan pengujian ragam kegagalan tertentu. RPN (Risk Priority Number) merupakan hasil dari severity, priority, dan likelihood. Karena digunakan skala dari 1 sampai 5 untuk ketiga parameter ini, maka RPN berkisar antara 1 (resiko kualitas yang paling berbahaya) hingga 125 (resiko kualitas yang paling tidak berbahaya). 

11) Recommended Action 

Kolom ini berisi satu atau lebih tindakan untuk setiap efek potensial untuk mengurangi resiko yang berkaitan (yang menekan RPN menuju angka 125). 

12) Who/When? 

Kolom ini mengindikasikan siapa yang bertanggung jawab untuk setiap tindakan yang disarankan dan kapan mereka bertanggung jawab untuk tindakan tersebut (contohnya, dalam fase mana). 

13) References 

Kolom ini menyediakan referensi untuk informasi tambahan tentang resiko kualitas. Biasanya, berkaitan dengan spesifikasi produk, dokumen persyaratan dan sejenisnya. 

14) Action Results 

Kolom terakhir ini (tidak terdapat pada gambar) mengizinkan untuk mencatat pengaruh dari tindakan yang diambil pada priority, severity, likelihood, dan nilai RPN. Kolom ini digunakan setelah mengimplementasikan pengujian, bukan pada awal FMEA. 

Teori-Teori Khusus Dalam Bisnis

Testing 

Pengujian (testing) merupakan fase yang penting untuk memastikan kualitas dari suatu pengembangan software. Alasan utama untuk mengadakan pengujian adalah untuk menemukan bugs di dalam software. Walaupun tidak ada bugs yang ditemukan, pengujian tidak dapat menjamin bahwa software tersebut bebas dari bugs. Pengujian meningkatkan keyakinan terhadap reliabilitas software. Selain itu, jika kita dapat memprediksi kerusakan dari software, kita dapat menghemat waktu dan juga biaya untuk pengembangan software. 

(a) Phased Test 

Pendekatan phased test (Black, 2009: 8) menyusun pengujian secara metodis melintasi fokus pengujian granularity spectrum, dari pengujian struktural menuju pengujian behavioral black-box hingga pengujian live. 

(b) Integration/Product Testing 

Pengujian integrasi atau produk (Black, 2009: 6) melibatkan penguji untuk menemukan bugs yang terdapat dalam hubungan dan interface antara pasangan-pasangan komponen dan sekumpulan komponen dalam sistem yang dilakukan pengujian. 

(c) System Testing 

Dalam fase ini, penguji mencari berbagai jenis bugs dalam sistem secara keseluruhan yang terintegrasi secara utuh. Kadangkala, seperti dalam pengujian instalasi dan kegunaan, pengujian ini melihat sistem dari perspektif customer atau end user. Di lain waktu, pengujian ini juga dirancang untuk menekankan aspek-aspek tertentu dari sistem yang mungkin tidak disadari oleh user tetapi bersifat kritis untuk jalannya sistem yang benar. 

(d) Acceptance/ User Acceptance Testing 

Acceptance testing atau pengujian penerimaan (Black, 2009: 7) seringkali mencoba untuk menunjukkan sejauh mana sistem telah memenuhi persyaratan yang ada. Fase pengujian ini biasanya dilakukan dalam perjanjian dimana keberhasilan pengujian mewajibkan pembeli untuk menerima sistem yang ada. Pengujian ini melibatkan data-data yang dibutuhkan untuk go live, lingkungan sistem, dan user scenario. 

(e) Functional Test 

Kadangkala frasa ini mempunyai makna yang sama dengan behavioral tests, tetapi dapat juga berarti pengujian yang berfokus kepada ketepatan fungsionalitas dengan seksama. Dalam kasus ini, functionality test atau pengujian fungsionalitas harus ditambahkan dengan pendekatan pengujian yang lain untuk mengatasi resiko-resiko kualitas yang penting seperti performa, beban, kapasitas, volume, dan sebagainya. 

(f) Test Architecture 

Test system architecture merupakan sebuah dokumen yang mendefinisikan prinsip-prinsip perancangan, struktur, dan alat-alat yang digunakan dalam testware dan test environment, layaknya juga kebergantungan antara bagian-bagian utama; independent terhadap proyek, tetapi merefleksikan sistem yang diuji. 

(g) Testware 

Testware meliputi semua peralatan, dokumen-dokumen, scripts, data-data, kasus-kasus, mekanisme pelacakan, dan hal-hal lainnya yang digunakan tim pengujian untuk melakukan pengujian. (Black, 2009: 80). 

(h) Test Environment 

Test environment atau lingkungan pengujian meliputi hardware, software, networks dan infrastruktur lainnya, kertas, perlengkapan lainnya, fasilitas, laboratorium atau tempat yang digunakan, dan hal-hal lainnya yang timpengujian dapatkan, instalasi, dan konfigurasi untuk menjalankan sistem pengujian dengan tujuan melakukan pengujian.

(i) Test Case 

Test case merupakan urutan langkah-langkah, sub dari langkah-langkah tersebut, dan tindakan-tindakan lain yang dijalankan secara berurutan, atau merupakan kombinasi-kombinasi dari konsekuensi yang menciptakan kondisi pengujian yang diinginkan sehingga dapat digunakan untuk evaluasi. Test case menurut Ammann dan Jeff (2008: 15) tersusun dari test case value, hasil yang diharapkan, prefix value, postfix value yang dibutuhkan untuk eksekusi secara lengkap dan evaluasi dari software di dalam pengujian. Test case value (2008: 14) merupakan masukan yang diperlukan untuk menyelesaikan eksekusi dari software yang berada dalam pengujian. Prefix value (2008: 15) berarti masukan apa pun yang diperlukan untuk menempatkan software ke dalam kondisi yang benar untuk menerima test case value. Sedangkan postfix value berarti masukan apapun yang butuh untuk dikirimkan ke software setelah test case value dikirimkan. 

(j) Test Suites 

Test suite merupakan sebuah kerangka untuk melakukan eksekusi terhadap sekumpulan test case; suatu cara mengatur test case. Dalam sebuah test suite, test case dapat digabungkan untuk menjadi kondisi-kondisi pengujian yang unik

(k) Test Plan 

Test plan biasanya mendeskripsikan ruang lingkup pengujian, tujuan pengujian, strategi pengujian, lingkungan pengujian, hasil yang didapatkan dari pengujian (deliverables), resiko dan penanggulangannya, jadwal, tingkatan pengujian yang akan digunakan, metode, teknik, dan alat-alat yang digunakan. Test plan seharusnya memenuhi kebutuhan dari perusahaan dan client. 

(l) Setting 

Dalam kaitannya dengan perencanaan pengujian, setting dideskripsikan dengan bagaimana kita ingin menjalankan pengujian dan cara organisasi menghubungkan pengujian ini dengan seluruh bagian organisasi. 

(m) Transitions 

Untuk setiap fase pengujian, sistem dalam pengujian harus memenuhi serangkaian kualifikasi minimal sebelum organisasi pengujian dapat menjalankan pengujian dengan efektif dan efisien. 

(1) Entry Criteria 

Serangkaian petunjuk pengambilan keputusan yang mengindikasikan apakah proyek siap memasuki fase pengujian tertentu. Entry criteria biasanya menjadi semakin ditekankan pada integration testing dan system testing. 

(2) Continuation/ Stopping Criteria 

Serangkaian petunjuk pengambilan keputusan yang mengindikasikan apakah fase tertentu dari pengujian dijalankan dengan efektif dan efisien. Sebaliknya, ketika digunakan sebagai stopping criteria, petunjuk ini diekspresikan sebagai istilah dalam menentukan apakah pengujian harus berhenti dikarenakan kualitas sistem dalam pengujian yang buruk atau masalah logika sistem yang berhubungan dengan pengujian sistem. 

(3) Exit Criteria 

Serangkaian petunjuk pengambilan keputusan yang mengindikasikan apakah proyek siap untuk melewati fase pengujian tertentu, atau berpindah dari satu fase ke fase lain atau menyelesaikan proyek. Exit criteria biasanya menjadi semakin ditekankan pada integration testing dan system testing.  

(n) Test Development 

Test development (Black, 2009: 61) dalam perencanaan pengujian digunakan untuk mendeskripsikan bagaimana tim pengujian akan menciptakan setiap obyek-obyek pengujian, seperti test cases, test tools, test procedures, test suites, test scripts, dan seterusnya. 

(o) Test Configurations and Environtments 

Test configuration and environtments dalam perencanaan pengujian digunakan untuk mendokumentasikan hardware, software, network, dan pengaturan tempat yang seperti apa yang akan digunakan untuk pengujian.

(p) Test Execution 

Dalam perencanaan pengujian bagian ini menunjukan faktor-faktor penting yang berhubungan dengan eksekusi pengujian. Contohnya, untuk menjalankan pengujian, seringkali dibutuhkan barang-barang dari pihak luar, sumber-sumber daya utama dan sistem untuk diuji. Dalam menjalankan pengujian ini, kita akan mengumpulkan data-data yang akan ditinjau, dianalisis, dan dilaporkan kepada tim, rekan kerja, dan manager

(1) Resources 

Dalam perencanaan pengujian, bagian ini mengidentifikasikan peserta-peserta kunci dalam usaha pengujian dan peran dari mereka masing-masing, beserta dengan sumber daya-sumber daya lain yang belum diidentifikasikan. 

(2) Test Case and Bug Tracking 

Dalam perencanaan pengujian, bagian ini berhubungan dengan sistem yang digunakan untuk mengolah dan meninjau test cases dan bugs. Peninjauan test cases merujuk kepada spreadsheets, database atau alat yang digunakan untuk mengolah semua test cases di dalam test suites dan bagaimana perkembangan dari pengujian tersebut ditinjau. 

(3) Bug Isolation and Classification 

Dalam perencanaan pengujian, bagian ini digunakan untuk menjelaskan seberapa jauh bugs akan diisolasi dan diklasifikasikan dalam laporan bugs. Mengisolasi bugs berarti mengadakan percobaan dengan sistem yang diuji dalam usaha pengujian untuk mendapatkan variabel yang berkaitan, kualitas atau sejenisnya. Mengklasifikasikan laporan bugs berarti menempatkan bugs yang ditemukan ke dalam kategori-kategori tertentu yang mengindikasikan bagaimana bugs seharusnya dikomunikasikan dan diatasi. 

(4) Test Cycle 

Eksekusi total atau sebagian dari semua test suite yang telah direncanakan untuk setiap fase pengujian. Setiap fase pengujian setidaknya melibatkan paling tidak satu siklus melalui semua test suite yang telah ditentukan. Test cycle biasanya berhubungan dengan perilisan suatu sistem dalam pengujian, seperti software atau motherboard. Umumnya, pengadaan pengujian baru terjadi selama fase pengujian, yang akan memicu munculnya test cycle yang lain.

Integrated Retail Application Point of Sales

Integrated Retail Application Point of Sales (IReap POS). Berdasarkan website resmi PT Sterling Tulus Cemerlang. IReap POS merupakan solusi lengkap yang dikembangkan oleh STEM berdasarkan oleh banyaknya proyek implementasi mySAP untuk perusahaan ritel, dan interaksi dengan pemain ritel yang menjanjikan di Indonesia. 

IReap POS terbagi ke dalam beberapa fungsi utama, yaitu order, sales, inventory, physical inventory, loyalty, miscellaneous, report, administration, dan personnel. 

a) Order 

Modul Order digunakan untuk melayani pemesanan item yang sedang tidak tersedia di toko sehingga harus dilakukan pengiriman dari Head Office. 

b) Sales 

Modul Sales digunakan untuk melayani transaksi penjualan yang terjadi di toko. 

c) Inventory 

Modul Inventory digunakan untuk mencatat persediaan barang dan perubahan keluar masuk barang yang ada serta untuk menyesuaikan data persediaan yang ada di sistem dengan jumlah fisik barang yang ada di gudang. 

d) Loyalty 

Modul loyalty digunakan untuk untuk mendukung pengelolaan data member (customer). 

e) Miscellaneous 

Miscellaneous digunakan untuk mencatat arus kas masuk dan arus kas keluar (petty cash). 

f) Report 

Modul report digunakan untuk mencetak dan melihat laporan-laporan yang dihasilkan, yang terbagi ke dalam sales reporting, misc, dan inventory reporting. 

g) Administration 

Modul ini digunakan untuk mendukung proses administrasi termasuk melakukan proses start of day, mengelola exchange rate, memantau proses upload dan download data, mengedit MOP (means of payment), system diagnostic dan proses backup data. 

h) Personnel 

Modul ini digunakan untuk mencatat absensi karyawan, mendaftarkan sidik jari karyawan untuk proses absensi atau mengganti password karyawan serta untuk mencatat permintaan cuti atau izin karyawan. 

SAP Business One 

Mengacu pada pendapat Anderson (2011: 60), SAP Business One dirancang untuk firma kecil, yang secara umum memiliki karyawan kurang dari 100 orang, yang memiliki lebih dari lima kantor cabang atau lokasi-lokasi dan kantor cabang yang independen. SAP menempatkan Business One sebagai solusi yang ideal untuk kantor-kantor cabang dari perusahaan multinasional karena solusi ini dengan mudah terhubung dengan solusi SAP Business Suite di kantor utama perusahaan. 

Layaknya pada solusi SAP ERP, Business One mendukung proses-proses bisnis penting seperti Financial Management, Warehouse Management, Purchasing, Inventory, Manufacturing, Banking, dan CRM (Customer Relationship Management). 

a) Sales 

Secara umum, gambaran proses sales adalah sebagai berikut:.  Alur dokumen proses penjualan secara umum dimulai dari: 

1. Sales quotation: tawaran atau proposal yang berisi komitmen harga terhadap suatu produk/ jasa tertentu yang akan diberikan kepada customer atau lead jika diterima. 
2. Sales order: komitmen dari customer atau lead untuk membeli suatu produk atau jasa dengan jumlah dan harga tertentu yang telah disepakati 
3. Delivery note: dokumen yang secara umum mengindikasikan bahwa barang telah dikirimkan kepada customer. 
4. Return: dokumen retur digunakan untuk membalikkan sebagian atau seluruhnya suatu posting delivery note yang telah dilakukan. Hal ini dilakukan ketika customer meretur barang atau dilakukan untuk memperbaiki kesalahan yang telah dibuat dalam base document sebelum A/R Invoice di-posting. 
5. A/R Invoice: dokumen yang harus dibuat dalam proses penjualan yang merupakan permintaan untuk pembayaran atau mencatat pendapatan dalam laporan laba-rugi. 
6. A/R Invoice plus payment: merupakan dokumen A/R Invoice yang digunakan untuk penjualan tunai bagi one-time customers. 
7. A/R Credit Memo: dokumen ini digunakan untuk membalikkan sebagian atau seluruhnya suatu posting dari A/R Invoice. Dokumen ini digunakan ketika customer mengembalikan barang yang A/R Invoice-nya telah dibuat atau digunakan untuk memperbaiki kesalahan yang ada pada dokumen A/R Invoice. 
8. Incoming payments: pembayaran dalam proses sales yang bisa dilakukan dalam empat cara, yaitu tunai, cek, kartu kredit dan transfer bank. 

b) Banking 

Incoming payments adalah pembayaran dalam proses sales yang bisa dilakukan dalam empat cara, yaitu tunai, cek, kartu kredit dan transfer bank.Deposits adalah sejumlah uang yang dibayar kepada suatu lembaga keuangan atau bisnis untuk kredit pada suatu akun. Pembayaran deposit tersebut dapat dilakukan baik secara tunai, cek ataupun dengan kartu kredit. Outgoing payments adalah sejumlah uang yang dikeluarkan oleh pembeli untuk membayar suatu produk atau jasa. 

Payment system/ wizard adalah batch tool yang secara otomatis membuat suatu incoming/ outgoing payment untuk melunasi A/R dan atau A/P Invoice. Adapun jenis atau metode pembayaran yang dimungkinkan dengan alat ini mencakup cek, transfer bank dan bills of exchange (hanya tersedia pada beberapa negara tertentu, tidak termasuk Indonesia). Bank statements adalah pemberitahuan yang mengikat secara hukum dari suatu bank untuk memberitahukan mitra bisnisnya mengenai turnovers pada rekening.  Reconciliation adalah perbandingan rekening untuk memastikan bahwa tidak ada kesalahan dalam perhitungan atau item yang dimasukkan.

c) Inventory 

Sesuai dengan sumber dari SAP library (2011), modul inventory pada SAP Business One 8.82 mencakup pengelolaan master data barang; manajemen serial number dan batch number; pengelolaan transaksi inventory seperti goods receipt, goods issue, inventory transfer, initial item quantity settings, dan inventory counts; pengelolaan price lists; proses pick and pack; dan pembuatan laporan-laporan inventory terkait. 

1. Item Master Data: berfungsi untuk pengelolaan semua data barang yang dibeli, dijual, diproduksi, atau disimpan sebagai persediaan barang serta service dari perusahaan. Item master data ini digunakan oleh modul purchasing, sales, production, warehouse management, accounting, dan service. 
2. Item Management: fungsi yang memungkinkan pengguna untuk menginput dan memodifikasi informasi dari suatu item. (SAP, 2011: 75). 
3. Inventory Transaction: mencakup fungsi-fungsi untuk mendukung goods receipt, goods issue, inventory transfer, initial item quantity settings, dan inventory counts. 

a. Goods Receipt 

Goods receipt adalah dokumen yang digunakan untuk mencatat penerimaan persediaan barang tanpa ada hubungan langsung dengan dokumen lainnya seperti dokumen-dokumen dari penjualan maupun pembelian. 

b. Goods Issue 

Goods issue adalah dokumen yang digunakan untuk mencatat pengeluaran persediaan barang tanpa ada hubungan langsung dengan dokumen lainnya pada modul lain. 

c. Inventory Transfer 

Inventory transfer digunakan untuk mencatat transaksi pemindahan barang dari satu gudang ke gudang lainnya. 

4. Price Lists 

Price lists digunakan untuk mencatat daftar harga yang berbeda-beda untuk suatu barang. Saat pembuatan dokumen sales maupun purchasing, SAP Business One akan mengambil harga sesuai dengan daftar harga yang di-assign terhadap business partner-nya. 

5. Pick and Pack 

Pick and pack pada SAP Business One memungkinkan user untuk mengotomatisasi pemrosesan sales order dan A/R reserve invoice dengan cara yang teratur, mulai dari pembuatan daftar pick up sampai pengemasan untuk pengiriman dengan dokumen delivery. 

6. Inventory Reports 

Inventory reports pada SAP Business One digunakan untuk melihat laporan-laporan terkait dengan item tertentu, persediaan barang yang ada beserta penilaian persediaannya.