8 BAB 2 LANDASAN TEORI
2.1 Teori Umum 2.1.1 Pengertian Sistem Pengertian sistem menurut O‟Brien (2003,p8) adalah sekumpulan komponen yang saling berhubungan dan bekerja sama untuk suatu tujuan tertentu dengan menerima input dan memproduksi output di dalam proses transformasi yang terorganisir. Menurut Mathiassen (2000,p3), sistem adalah sekumpulan komponen yang mengimplementasikan kebutuhan akan pemodelan, fungsi dan interface. Dari pengertian di atas dapat disimpulkan, pada dasarnya sistem adalah kumpulan dari elemen yang berinteraksi untuk mencapai suatu tujuan tertentu.
2.1.2 Pengertian Informasi Pengertian informasi menurut O‟Brien ( 2003, p13 ) adalah data yang telah diolah menjadi berarti dan berguna untuk pengguna akhir tertentu. Menurut McLeod ( 2004, p10 ), informasi adalah data yang telah di proses atau data yang memiliki arti. Dari pengertian diatas dapat disimpulkan bahwa informasi adalah data yang telah diproses dan diolah sehingga memiliki arti bagi user, yang bermanfaat dalam membantu memperoleh suatu kesimpulan dan mendukung dalam proses pengambilan keputusan.
8
9 2.1.3 Pengertian Sistem Informasi Menurut O‟Brien (2003,p10), sistem informasi adalah gabungan yang terorganisasi dari manusia, perangkat keras, perangkat lunak, jaringan komunikasi dan sumber data dalam mengumpulkan, mengubah, dan menyebarkan informasi dalam suatu organisasi. Menurut McLeod (2004, p19), sistem informasi adalah sekumpulan komponen-komponen
yang
terintegrasi
dengan
batasan-batasan
yang
teridentifikasi yang mengimplementasikan model dari requirement, function dan interface yang bekerja untuk mencapai suatu tujuan dengan menerima data sebagai input dan memprosesnya menjadi output yang mempunyai arti bagi penerimanya. Dari pengertian diatas dapat disimpulkan bahwa sistem informasi adalah kumpulan komponen-komponen yang terdiri dari : manusia, perangkat keras, perangkat lunak, jaringan komunikasi yang saling terkait satu sama lain dalam mengumpulkan dan mengolah sumber data sehingga menghasilkan informasi yang bermanfaat untuk mendukung proses pengambilan keputusan, koordinasi, dan kontrol organisasi.
2.1.4 Enterprise Resource Planning (ERP) ERP memiliki ciri-ciri terpusat (centralized) dan database yang komprehensif mulai dari mengumpulkan, menyimpan dan menyebarkan data ke semua fungsi bisnis dan aktifitas didalam perusahaan. Dengan mengintegrasikan semua fungsi bisnis, akan diperoleh keuntungan secara ekonomis, yaitu dengan berkurangnya biaya operasional, dapat meningkatkan
10 kemampuan dan transparansi informasi (Nah et al. 2007) Enterprise Resource Planning (ERP) adalah tulang punggung perusahaan lintas fungsi yang mengintegrasi dan mengotomatisasi banyak proses bisnis internal dan sistem informasi dalam fungsi penjualan dan distribusi, produksi, logistik, akuntansi, dan sumber daya manusia sebuah perusahaan. (O‟Brien, 2004, p.194)
2.1.4.1 Evolusi ERP Konsep Enterprise Resource Planning (ERP) dikembangkan dari sistem Manufacturing Resorce Planning II (MRP II). Sedangkan sistem MRP II sendiri dikembangkan dari sistem Materials Requirement Planning (MRP). Sistem MRP dikembangkan pada tahun 1970-an berdasarkan pada prinsip mengelola dan mengendalikan persediaan. Sistem MRP memungkinkan manajer pabrik untuk merencanakan produksi dan kebutuhan bahan baku dengan melihat prakiraan permintaan dan jadwal produksi yang dibutuhkan untuk memenuhi permintaan tersebut. MRP II yang dikenal luas pada tahun 1980-an merupakan pengembangan dari MRP untuk mendukung kegiatan produksi di pabrik dan juga kegiatan distribusi hasil produksi. Pada tahun 1990-an MRP II dikembangkan untuk mendukung fungsi bisnis yang lain seperti akuntansi, keuangan, personalia, penjualan dan pemasaran. Pada masa itu, prinsip-prinsip Just In Time (JIT) dan Total Quality Management (TQM) dikembangkan dengan sasaran menurunkan pemborosan dan
11 meningkatkan
kualitas,
secara
terus-menerus.
Konsep
ERP
dikembangkan dari MRP II dan dikombinasikan dengan prinsip JIT dan TQM.
2000s
Extended ERP
1990s
Enterprise Resource Planning (ERP)
1980s
Manufacturing Resource Planning (MRP II)
1970s
Material Requirements Planning (MRP)
1960s
Inventory Control Packages
Gambar 2.1 Evolusi ERP (Rashid et al. 2002)
2.1.4.2 ERP dan Competitive Advantage Michael Porter mengidentifikasi ada tiga tipe competitive advantage yaitu cost leadership (low cost), differentiation dan focus (Wad and Peppard 2006) Sistem ERP mengintegrasikan aliran informasi dan proses bisnis kedalam paket tunggal, yang pada akhirnya mempengaruhi proses informasi perusahaan, aliran pekerjaan dan interaksi antar karyawan. Sistem
ERP
juga
memfasilitasi
integrasi
informasi
yang
12 menghubungkan pemasok, penyalur dan konsumen tanpa batas wilayah. Menurut Cooke dan Peterson sistem ERP memberi keuntungan sebagai berikut (Mzoughi et al. 2008) : (1) normalisasi prosedur perusahaan; (2) integrasi operasi dan data; (3) komputerisasi proses bisnis; (4) optimalisasi persediaan; (5) meningkatkan fleksibilitas; (6) meningkatkan produktifitas; (7) mengurangi karyawan; (8) memperkuat strategi globalisasi; (9) memecahkan masalah. Dan secara umum keuntungan menggunakan sistem ERP yang dapat memberikan competitive advantage dapat dikelompokkan menjadi dua yaitu: 1.
Tangible atau kuantitatif yang dapat secara langsung memberi profit, misalnya penurunan biaya tenaga kerja, optimalisasi persediaan, efisiens proses, percepatan waktu pemenuhan pesanan, dst.
2.
Intangible atau kualitatif yang secara tidak langsung memberi
profit,
ketersediaan
misalnya
informasi,
memperbaiki
kerjasama,
normalisasi
prosedur,
meningkatkan fleksibilitas, meningkatkan produktifitas, memperkuat strategi, dst.
2.1.4.3 ERP Vendors Menurut Daniel E. O‟Leary, terdapat beberapa produk sistem ERP yang utama, yaitu BOPSE (Baan, Oracle, PeopleSoft, SAP, dan J.D.
13 Edwards). Sementara itu, vendor ERP lainnya, yaitu: Great Plains, Lawson, Platinum, QAD, Ross & Solomon. (O‟Leary, 2000, p.28)
2.1.4.3.1
SAP (Systeme Anwendungen Produkte) 1.4.3.1.1 Sejarah SAP Pada tahun 1972, lima mantan karyawan IBM - Dietmar Hopp, Hans-Werner Hector, Hasso Plattner, Klaus Tschira, dan Claus Wellenreuther – meluncurkan sebuah perusahaan yang disebut Systems, Applications, and Products in Data Processing di Mannheim, Jerman. Visi mereka adalah untuk mengembangkan standar software aplikasi untuk pemrosesan bisnis secara real-time. Setahun kemudian, software akuntansi keuangan pertama
selesai,
perkembangan
menjadi
selanjutnya
dasar untuk
untuk
komponen
software yang akan dikenal sebagai sistem R/1. “R” adalah untuk pemrosesan data real-time. Lima puluh dari seratus perusahaan terbesar Jerman sudah menjadi pelanggan SAP. Sistem SAP R/2 mencapai tingkat stabilitas yang tinggi dari program
generasi
sebelumnya.
Memikirkan
pelanggannya yang multinasional, SAP merancang
14 SAP R/2 untuk menangani bahasa dan mata uang yang berbeda. Pada Agustus 1988, SAP GmbH berubah menjadi SAP AG. SAP mengembangkan cabangcabang di Denmark, Swedia, Itali, dan United State. Pada tahun 1990an SAP R/3 dipasarkan. Dengan
konsep
client-server,
keseragaman
tampilan grafikal, penggunaan database relasional yang konsisten, dan kemampuan untuk dijalankan pada komputer dari vendor berbeda sangat diterima pasar. Dengan SAP R/3, SAP masuk ke generasi baru software perusahaan – dari mainframe sampai arsitektur three-tier database, aplikasi, dan user interface. Sampai hari ini, arsitektur client-sever adalah standar dalam software bisnis. Hasso Plattner, Co-Founder, Co-Chairman, dan CEO mengumumkan strategi mySAP.com. mySAP.com menghubungkan solusi e-commerce menjadi aplikasi ERP yang nyata, menggunakan teknologi Web state-of-the-art. Dengan internet, pemakai menjadi fokus dari aplikasi software. SAP mengembangkan SAP Workplace dan membuka jalan untuk ide portal perusahaan dan akses peran khusus ke informasi.
15 Tahun
2000an,
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.
1.4.3.1.2 SAP Application-Based modules Menurut Daniel E. O‟Leary (2000,p31), Komponen utama sistem SAP R/3 memiliki beberapa Application-Based modules yang saling terintegrasi satu sama lain, yaitu :
Tabel 2.1 SAP Application-Based modules AM (Asset Management) : Modul yang mengelola informasi terkait pembelian aset tetap yang berhubungan dengan depresiasi, asuransi, nilai properti dan sebagainya. CO (Controlling) : Modul yang mencakup CCA (Cost Center Accounting), PC (Product Cost Controlling), serta ABC (Activity-Based Costing). FI (Financial Accounting) : Modul yang mencakup GL (General Ledger),
16 AR (Accounts Receivable), dan LC (Legal Consolidations). HR (Human Resource) : Modul yang mencakup PA (Personnel Administration), dan PD (Planning and Development). MM (Materials Management) : Modul yang memiliki cakupan IM (Inventory Management), IV (Invoice Verivication), dan WM (Warehouse Management). PM (Plant Maintenance) : Modul dengan cakupan EQM (Equipment and Technical Objects), PRM (Preventive Maintenance), SMA (Service management), dan WOC (Maintenance Order Management). PP (Production Planning) : Mencakup SOP (Sales Operations Planning), MRP
(Materials
Requirements
Planning),
dan
CRP
(Capacity
Requirements Planning). PS (Project Systems) : Mencakup project tracking dan budget management. QM (Quality Management): Mencakup CA (Quality Certificates), IM (Inspection Processing), PT (Planning Tools), dan QN (Quality Notifications). SD (Sales and distribution) system. Sebagai tambahan, terdapat beberapa modul-modul Cross-Application (CA) yang dapat digunakan secara menyeluruh pada sistem R/3; termasuk dalam alur kerja bisnis pada SAP dan SAP office.
17 2.1.5 Pengembangan Implementasi Proyek ERP Dipandang sebagai sebuah proses, implementasi ERP dapat dibagi menjadi tiga fase proses, yaitu inisiasi, pelaksanaan, dan penyelesaian proses dengan beberapa pendekatan dalam pengembangan implementasi proyek ERP yaitu big bang dan incremental/phased rollout (Mäkipää 2003).
Business Process Reengineering
Initiative
Evaluation
Selection
Modification
Training
Go-Live
Termination
Exploitation and Development
Conversion of Data
Big Bang, Incremental / Phased Rollout
Gambar 2.2 Fase-fase Implementasi Sistem ERP (Mäkipää 2003)
Menurut Daniel E. O‟Leary, Big-bang dan Phased merupakan pendekatan mendasar yang digunakan dalam pengembangan implementasi sistem ERP. Implementasi Big-bang adalah suatu pendekatan dimana aplikasi ERP secara keseluruhan diimplementasikan pada waktu yang sama. Dengan penggunaan pendekatan Big-bang sistem bergerak dari test version system menjadi actual system untuk nantinya diadopsi langsung pada transaksi operasional dalam jangka waktu yang singkat. Pendekatan ini memerlukan sejumlah besar pengujian sebelum
18 dilakukannya cut over ke sistem ERP yang baru. Implementasi Phased merupakan implementasi yang berurutan terdiri atas perancangan, pengembangan, pengujian, dan penginstallan untuk modul-modul yang berbeda. Berbeda dengan Big-bang, selain pendekatan ini lebih mengarah pada “potongan-potongan” proses modul, perancangan, pengembangan, pengujian dan implementasi yang lebih sederhana, implementasi Phased membutuhkan perhatian yang substansial disertai pemeliharaan di tiap-tiap fase pada sistem terdahulu, sehingga sedikit demi sedikit tujuan pengintegrasian kepada sistem ERP yang baru dapat terjadi. (O‟Leary 2000, p151-152) Pada pendekatan Phased/Incremental, implementasi dilakukan secara bertahap dan dibagi menjadi beberapa sub proyek. (Mäkipää 2003)
19 2.2 Teori Khusus 2.2.1 SAP Warehouse Management sebagai bagian dari Logistic Execution 2.2.1.1
Logistic Execution 2.2.1.1.1
Pemahaman Logistic Execution Pada
mySAP
Enterprise
Resource
Planning
(mySAP ERP) dan mySAP Supply Chain Management (mySAP SCM), Logistics Execution memungkinkan berbagai macam fitur untuk semua proses logistik, termasuk
Warehouse
Management,
Shipping
and
Transportation. Logistics Execution adalah sekumpulan fitur yang menjadi inti dari proses logistik, yang terhubung ke Production Planning and Control, Material Management, dan Sales. Pada SAP R/3 Logistics Execution sudah terintegrasi ke dalam sistem dengan tujuan untuk menggabungkan semua fitur logistik yang sudah ada serta untuk mengembangkan grup fitur ini lebih jauh. (SCM630, 2006, p2)
2.2.1.1.2
Logistic Execution : Elements and sources Warehouse Management didasarkan dari Material Management (MM), sedang Shipping dan Transportation merupakan penerusan dari Sales and Distribution (SD). Customizing
untuk
Warehouse
Management
20 didasarkan langsung dari customizing untuk Material Management. Sedangkan komponen customizing untuk Shipping and Transportation bisa ditemukan pada Sales and Distribution dan Logistics Execution. (SCM630, 2006, p3-4)
Gambar 2.3 Logistic Execution : Elements and sources (SCM 630 2006, p3)
2.2.1.1.3
Fungsi Logistic Execution Logistics
Execution
menghubungkan
antara
Procurement dan Distribution pada SAP ECC, tanpa melihat apakah proses yang terjadi bersifat internal atau terkait dengan pihak ketiga (vendor, pelanggan, atau penyedia layanan), dan apakah Material diproduksi sendiri ataupun diadakan dari luar, keduanya ditempatkan dan diambil dari penyimpanan menggunakan Warehouse
21 Management,
untuk
men-supply
bagian
produksi
perusahaan maupun untuk pengiriman ke pengecer atau konsumen. (SCM 630 2006, p4)
Gambar 2.4 Logistic Execution: Function in SAP ECC (SCM 630 2006, p4) Logistics Execution menggunakan unit organisasi dan master data tersendiri, yang terintegrasi ke struktur organisatoris pada SAP ECC. Elemen struktural tersebut dapat digunakan untuk memetakan situasi bisnis yang kompleks.
2.2.1.1.4
Bentuk Dasar Proses Pemetaan (Mapping) Terdapat dua cara untuk memetakan proses pada penerimaan barang dan pengeluaran barang pada Logistics
22 Execution : Pertama membuat suatu delivery (pengiriman) atau melakukan posting Inventory Management (biasanya dengan reference kepada suatu document) diawal proses.
Gambar 2.5 Process Overview (SCM 630 2006, p5)
Jika melalui proses delivery, proses pada Warehouse Management (pembuatan dan konfirmasi transfer order) diselesaikan sebelum melakukan posting pada Inventory Management. Posting penerimaan barang/pengeluaran barang selalu terkait kepada proses delivery. Inventory Management Posting juga dapat terjadi di awal
proses.
Diawali
posting
penerimaan
23 barang/pengeluaran
barang
lalu
membuat
Transfer
requirement, dan proses nantinya akan diselesaikan dengan aktivitas putaway (penempatan barang) atau picking (pengambilan barang) dengan suatu Transfer order. Umumnya, alasan penempatan atau pengambilan barang bisa menentukan bagaimana suatu proses akan dipetakan. Misalnya, pada proses penerimaan barang dari bagian produksi, sistem standar hanya menawarkan posting penerimaan barang untuk work order dengan proses penempatan barang lanjutan. Sebaliknya, pada Sales Order proses pengambilan barang umumnya didasarkan pada proses pengeluaran barang. (SCM630, 2006, p5)
2.2.1.2
Hubungan Warehouse Management dengan Logistic Execution 2.2.1.2.1
Warehouse Management pada Logistic Execution Warehouse Management merupakan bagian dari Logistics Execution, dan mengelompokkan semua fitur utama dari Logistics Execution pada Sales and Distribution (SD) dan Material Management (MM). Dengan menggunakan Warehouse Management, dapat dipetakan seluruh proses pada Logistics Execution. Warehouse Management akan menyediakan perangkat
24 yang diperlukan, apakah sales order harus dipenuhi atau bagian produksi mendapat supply material, apakah barang dikirim dari vendor atau barang jadi dari bagian produksi akan ditempatkan di gudang.
2.2.1.2.2
Fungsi Dasar Warehouse Management Warehouse Management pada SAP ECC mempunyai lima fungsi dasar berikut:
Inventory Management sampai ke level storage bin.
Pemetaan dan pengendalian semua perpindahan barang.
Pengawasan pengerjaan proses perpindahan barang tersebut.
Koneksi ke perangkat entri data mobile sebagai bagian
dari
solusi
Radio
Frequency
(RF)
terintegrasi.
Koneksi ke sistem eksternal khusus menggunakan suatu interface.
Jika Inventory Management, sebagai bagian dari Material Management, hanya bisa memberikan informasi mengenai kuantitas total material pada barang, Warehouse Management dapat memberikan informasi mengenai lokasi pasti kuantitas tertentu dari
25 suatu material dan menginformasikan apakah kuantitas ini berada dalam storage bin atau sedang dipindahkan. Proses perpindahan barang dari storage bin ini biasanya
dipicu
oleh
penerimaan
barang
dan
pengeluaran barang, atau Stock Transfer. Sistem yang terkonfigurasi sepenuhnya, bahkan masih dapat terjadi error, hal-hal seperti kelalaian untuk memproses dokumen dengan status open, atau lainnya.
Karenanya,
Warehouse
Management
dilengkapi dengan perangkat pengawasan. Pada
SAP,
memungkinkan
penggunaan
perangkat entry data mobile untuk koneksi langsung ke Warehouse Management. Perangkat ini berbasis teknologi Radio Frequency (RF) dan secara hardware bersifat netral. Transaksi pada SAP ECC dengan menggunakan RF mencakup hampir semua aktivitas didalam
dan
diluar
fasilitas.
Pengemasan
dan
pemuatan barang ke transport, serta Penghitungan inventori juga dapat dilakukan. (SCM630, 2006, p5)
2.2.1.2.3
Interface Terhadap Aplikasi SAP ECC Lainnya Warehouse Management pada SAP ECC juga bisa melakukan pertukaran data dengan komponen aplikasi lainnya melalui interface. Berikut adalah
26 macam koneksi ke komponen aplikasi lainnya:
Inventory Management (IM-MM)
Delivery Processing (LE-SHP)
Production Planning and Control (PP, PP-PI)
Quality Management (QM)
Gambar 2.6 Interface to other application components (SCM 630 2006, p12)
Interface ke Inventory Management adalah alasan utama penggunaan Warehouse Management pada SAP ECC; posting dari Inventory Management dapat memicu aktivitas pada Warehouse Management atau menandai penyelesaian pada proses penerimaan
27 barang atau pengeluaran barang. Koneksi ke Delivery Processsing
pada
Logistics
Execution
berperan
penting pada Sales Order Processing. Umumnya, barang diambil berdasarkan Outbound Delivery. Jika ingin menyediakan supply material yang teratur ke bagian produksi, bisa menggunakan interface ke Production
Control.
Dan
ketika
penggunaan
komponen Quality Management dilakukan, hal ini memungkinkan konfigurasi interface ke Warehouse Management
untuk
mengendalikan
bagaimana
perlakuan barang di gudang ketika menjalani proses quality inspection dapat terjadi.
2.2.2 Warehouse Management 2.2.2.1
Warehouse Structure Elements Struktur gudang pada Warehouse Management bersifat hierarki dan terdiri dari beberapa komponen, beberapa diantaranya terkait dengan penelitian penulis, antara lain (WM Guide 2001, p20): 1. Warehouse Number 2. Storage type 3. Storage Section 4. Storage Area 5. Picking Area 6. Storage bin
28
Gambar 2.7 Substructure of the warehouse (SCM 630 2006, p22)
Gambar 2.8 Depiction of The Physical Warehouse in Warehouse Management (WM Guide 2001, p20) 2.2.2.1.1
Warehouse Number Warehouse number adalah unit organisatoris
29 dengan level tertinggi di Warehouse Management pada SAP
ECC.
Warehouse
number
digunakan
untuk
melambangkan suatu kompleksitas pergudangan. Gudang pada umumnya merujuk ke suatu bangunan fisik atau suatu distribution center. Tiap warehouse number mempunyai substruktur yang memetakan hubungan spasial pada kompleks pergudangan secara detail. Tiap warehouse number mempunyai sejumlah unit
organisatoris
bawahan
(sesuai
setting
pada
customizing): Storage type, Storage section, dan Picking area. (SCM 630 2006, p21) Pada Warehouse Management (WM), fisik suatu gudang terwakili oleh satu Warehouse Number. Dengan
menggunakan
Warehouse
Number,
dapat
dilakukannya penanganan beberapa bangunan gudang yang merupakan bagian dari kompleks pergudangan. (WM Guide 2001,p22)
2.2.2.1.2
Storage type Storage type digunakan untuk memetakan ruang penyimpanan yang membentuk suatu unit terpisah pada warehouse number, baik secara spasial dan/atau organisatoris. Suatu sistem standar sudah mempunyai beberapa
storage
type
yang
sudah
terkonfigurasi,
30 misalnya: high rack, fixed bin, dan bulk storage type. Dapat
dimodifikasikan
template
yang
ada
sesuai
kebutuhan, atau menambahkan storage type baru. (SCM 630 2005,22) Storage type adalah area penyimpanan, fasilitas pergudangan,
atau
zona
pergudangan
yang
telah
ditentukan pada Warehouse Management (WM) untuk suatu warehouse number. Area tersebut merupakan bagian fisik atau logic dari suatu kompleksitas pergudangan yang dicirikan dengan warehouse technique yang diadopsi, ruang yang digunakan, bentuk organisasinya, atau fungsinya. Suatu storage type terdiri dari satu atau lebih storage bin.. Dan Beberapa storage type dapat ditentukan untuk tiap nomor gudang. (WM Guide 2001, p23)
31
Gambar 2.9 Illustrasi 5 Storage type Ditempatkan pada 1 Warehouse Number (WM Guide 2001, p25)
2.2.2.1.3
Storage Section Pada Warehouse Management (WM), Storage section merupakan subdivisi dari Storage type, yang mengelompokkan Storage bin dengan tampilan serupa untuk tujuan penempatan barang. Kriteria pengelompokan Storage bin bisa ditentukan sesuai kebutuhan, misalnya heavy parts, bulky materials, fast moving items, atau slow moving items.(WM Guide 2001, p26) Untuk membagi ruang penyimpanan lebih lanjut, sistem akan membuat storage section pada storage type. Terdapat berbagai kriteria untuk pembuatan berbagai
32 storage section. Biasanya, material yang akan disimpan pada Storage type memegang peranan penting dalam penentuan kriteria. Seperti, barang fast moving akan disimpan di storage section yang mudah diakses, sedang barang yang cepat rusak akan disimpan di area yang mempunyai pendingin. Sistem hanya mempertimbangkan Storage section selama Putaway processing. Walau
tidak
diharuskan
untuk
membagi
storage type menjadi dua atau lebih storage section, atau bahkan sekalipun tidak dirasa perlu membagi ruang penyimpanan pada Storage type namun harus dibuat paling tidak satu storage section untuk tiap storage type. (SCM 630 2005, p23)
Gambar 2.10 Storage Section (WM Guide 2001, p27)
33 2.2.2.1.4
Picking Area Picking area merupakan bagian dalam suatu Storage type dimana suatu aktivitas pengambilan barang dilakukan. Picking area mengelompokkan Storage bin berdasarkan Picking strategies dan merupakan kebalikan dari Storage section, yang mengelompokkan Storage bin berdasarkan Putaway strategies. (WM Guide,28) Picking area berada pada level hierarki yang sama dengan Storage section dan bisa digunakan untuk membagi area Storage type untuk mengendalikan proses Stock removal. Tidak seperti Storage section, Picking area bersifat optional. (SCM 630 2005, p28)
2.2.2.1.5
Storage bin Suatu storage type pada umumnya berisi satu atau lebih slot, yang dikenal dengan storage bin pada Warehouse Management (WM). Storage bin adalah unit penyimpanan terkecil di suatu gudang. Storage bin bisa menunjukkan posisi di gudang tempat suatu barang bisa atau akan disimpan. (WM Guide,29) Pada Warehouse Management, Storage bin merupakan master data yang dibuat melalui menu aplikasi atau pada customizing di Storage section. Berdasarkan master data tersebut, tampilan barang pada Warehouse
34 Management akan menampilkan status suatu kuantitas barang/material di gudang. Storage bin selalu dibuat pada Storage section. Juga dapat ditempatkan didalamnya suatu Picking area dan jika
diperlukan
suatu
bagian
fire
containment
(pengendalian kebakaran) untuk pengelolaan barang berbahaya. Tiap storage bin diidentifikasi secara unik menggunakan coordinates pada storage type. Penggunaan karakter alphanumeric dengan karakter lain untuk coordinate dapat dilakukan. Storage bin juga dapat ditempatkan ke suatu Storage bin type. Storage bin type merupakan kategori opsional yang bebas ditentukan pada customizing untuk Warehouse Management, yang bertujuan menentukan dimensi dari suatu storage bin. Storage bin type terutama berguna jika storage bin dari Storage type atau Storage section tertentu pada Storage type mempunyai dimensi yang berbeda. Pada prakteknya, kebutuhan jumlah bin yang sangat besar berarti sangat tidak efisien untuk membuat Storage bin secara manual. Untuk membuat Storage bin serupa dalam jumlah besar dapat digunakan kode transaksi pada aplikasi SAP yang memungkinkan pembuatan Storage bin secara otomatis. (SCM 630 2005, p33)
35
Gambar 2.11 Storage Bin Types (SCM 603 2005, p34)
2.2.2.1.6
Quant Quant adalah isi dari suatu storage bin. Dengan kata lain Quant merupakan kuantitas material pada suatu storage bin. Pada Warehouse Management SAP ECC, material hanya bisa diperhitungkan dan dipindahkan dalam bentuk quant. Quant suatu material bisa terdiri dari satu atau x pieces, kilogram, atau liter. Tetapi, kriteria yang digunakan sistem selama proses putaway atau picking untuk menentukan seberapa kuantitas material untuk satu quant atau beberapa quant pada satu atau beberapa storage bin adalah tetap. (SCM 630 2005, p56) Kriteria untuk pembentukan/pembagian quant adalah:
36
Material number
Stock type atau stock category
Special stock
Plant dan storage location dan jika memang digunakan,
Batch number material
Gambar 2.12 The Quant (SCM 603 2005, p57)
2.2.2.2
Organizational Connection to Inventory Management Untuk bisa menggunakan Warehouse Management pada SAP ECC, perlu dipastikan bahwa Warehouse Management sudah terkoneksi ke Inventory Management.
37 2.2.2.2.1
Plant Plant didefinisikan dalam system sebagai 4 karakter alfanumerik
yang
unik
didalam Client.
(SAP 01
Fundamentals, p33) Plant merupakan suatu unit organisasi dalam logistic yang
memisahkan
perusahaan
dari
sudut
pandang
produksi, procurement, dan perencanaan material. Suatu plant dapat merepresentasikan beberapa entitas dalam perusahaan, seperti :
2.2.2.2.2
Production Facility
Distribution Centre
Kantor pusat perusahaan
Maintenance Location
Storage Location Storage location adalah unit organisatoris quantity-based dari Inventory Management. (SCM 630 2005, p47) Storage location adalah unit organisatoris yang membedakan material dalam suatu Plant. Manajemen Persediaan (Inventory Management) dan persediaan secara fisik (Physical Inventory) terjadi pada tingkat Storage Location. Storage Location didefinisikan dengan 4 karakter alfanumerik yang unik dalam Plant. (SCM
38 500,p46)
2.2.2.2.3
Connection of Warehouse Management to Inventory
Management Warehouse number, dapat digunakan paling tidak harus selalu dihubungkan ke satu kombinasi Plant dan Storage location. Proses inilah yang nantinya akan membentuk koneksi dengan Inventory Management yang diperlukan untuk memetakan proses Goods receipt, Goods issue dan Posting change. Jika hanya diaplikasikan Inventory Management, Storage location biasanya digunakan untuk memetakan Storage area pada sistem. Sesuai dengan namanya, Storage location menunjukkan dimana suatu material disimpan pada gudang. Storage location masih diperlukan sebagai suatu unit organisatoris sehingga stock bisa dikelola berdasarkan pada kuantitas, namun Storage location tidak lagi berhubungan dengan situasi spasial. Dari sudut pandang Warehouse Management, satu Storage location sudah memadai. Tetapi, bisa terdapat alasan dari sudut pandang Inventory Management untuk mempunyai beberapa storage location. Misalnya, bila akan membagi barang menurut batch produksi yang berbeda atau special stock.
39 Atau mungkin ingin membagi blocked stock (barang yang tertutup aksesnya) atau barang yang sedang menjalani quality inspection menggunakan Storage location yang terpisah. (SCM 630 2005, p47)
Gambar 2.13 Connection of Warehouse Management to Inventory Management (SCM 630 2005, p47)
2.2.3 Warehouse / Good Movements Dengan menempatkan Plant/Storage Location pada sistem Inventory Management ke Warehouse Number di sistem Warehouse Management, barang secara total akan tetap seimbang antara Inventory Management dan Warehouse Management ketika proses penerimaan dan pengeluaran barang dilakukan, hal ini sekaligus menyebabkan perubahan kuantitas pada sistem. Pada perpindahan barang, biasanya diperlukan dua posting untuk menyempurnakan proses. Tetapi
40 dimungkinkan untuk mengerjakannya secara otomatisasi pada proses ini.
Selama perpindahan barang, sistem akan melibatkan beberapa aktivitas dan dokumen kunci pada gudang. Aktivitas dan dokumen kunci terpenting tersebut, antara lain (WM Guide, 139) :
Goods receipt (Penerimaan barang)
Goods issue (Pengeluaran barang)
Stock transfer
Posting change
Transfer requirement
Transfer order
2.2.3.1
Penerimaan Barang (Good Receipt) Penerimaan barang (Good Receipt) adalah perpidahan barang pada gudang, yang mana barang diterima sebagai hasil dari permintaan pembelian, permintaan produksi, atau dengan alasan lainnya. Semua penerimaan barang akan meningkatkan barang total di Inventory Management dan Warehouse Management. Posting pada Inventory Management akan meningkatkan barang total di Inventory Management dan Warehouse Management secara bersamaan. Dalam hal ini, Warehouse Management mempunyai fitur “distribusi” untuk memindahkan barang yang di-posting di Inventory Management dari area penerimaan barang ke storage bin di gudang. Untuk melakukan proses tersebut, sistem akan membuat transfer order untuk menentukan storage bin yang paling sesuai.
41 Transfer order akan dikonfrimasi begitu barang sudah dipindahkan. (WM Guide,142) Suatu Goods receipt adalah perpindahan fisik barang atau material ke dalam gudang. Goods receipt merupakan goods movement yang digunakan untuk mem-posting barang yang diterima dari vendor eksternal atau merupakan hasil produksi sendiri. Semua goods receipt akan meningkatkan barang di gudang. Sistem SAP mempunyai beberapa tipe goods receipt:
Goods receipt dengan reference ke suatu purchase order
Goods receipt dengan reference ke suatu production order
Goods receipt dengan reference ke suatu delivery
Goods receipt lainnya (tanpa reference)
(Murray 2007, p83)
2.2.3.1.1
Proses Penerimaan Barang (Good Receipt) Ketika barang diterima di gudang, proses yang terjadi di sistem Warehouse Management pada umumnya bersifat otomatis dan transparan bagi user. Warehouse Management menyimpan catatan semua transaksi yang terjadi yang dihubungkan dengan tiap barang. Tiap langkah-langkah penting dari posting penerimaan barang di aplikasi Inventory Management sampai konfirmasi perpindahan barang yang sudah terjadi, bisa dilakukan
42 secara otomatis oleh sistem. Berikut langkah-langkah
posting
penerimaan
merupakan Inventory
Management apabila ingin dilakukan secara manual 1. Untuk memulai proses penerimaan barang ke Warehouse Management, dapat dilakukan posting goods receipt di Inventory Management. 2. Setelah melakukan posting di IM, sistem akan menempatkan sejumlah kuantitas material ke suatu storage bin di suatu interim storage area untuk goods receipt dan membuat transfer requirement yang diperlukan di WM. 3. Selanjutnya, sistem akan membuat transfer order berdasarkan informasi pada transfer requirement. 4. Sistem lalu menentukan lokasi penempatan barang digudang menggunakan suatu metode pencarian, dan lalu menaruh barang di suatu pallet. 5. Transfer order digunakan untuk mentransfer barang dari interim storage bin di area penerimaan barang ke satu atau beberapa storage bin di gudang. 6. Pekerja gudang mengkonfirmasi bahwa barang sudah ditransfer. Konfirmasi bisa dimasukkan secara manual ke sistem atau secara otomatis dengan menggunakan perlengkapan RF untuk men-scan barcode pada kontener.
43 Selisih apa pun antara kuantitas yang diminta dan kuantitas yang ditransfer ke gudang akan terekam di WM. Selisih tersebut nantinya harus ditangani pada aplikasi IM. Pada titik ini, proses goods receipt sudah selesai. (WM Guide 2001, p193-194)
Gambar 2.13 Aktifitas pada Warehouse Management saat Good Receipt Processing (WM Guide 2001, p193-194)
44 2.2.3.2
Pengeluaran Barang (Good Issue) Pengeluaran barang (Goods Issue) pada WM didefinisikan sebagai perpindahan barang keluar gudang secara fisik. Goods Issue adalah suatu goods movement yang digunakan untuk
mem-posting
penggunaan
internal
suatu
material,
pengeluaran suatu material, dan delivery suatu barang ke pelanggan. Suatu Goods Issue menyebabkan penurunan jumlah barang di gudang. (WM Guide 2001, p218)
Tabel 2.2 Overview of Good Issue (WM Guide 2001, p218)
Seperti ditunjukkan pada tabel 2.2 berikut, berbagai komponen aplikasi pada sistem SAP mengawali transfer barang dari sistem Warehouse Management dengan membuat suatu document sebagai dasar goods movement tersebut. Sistem juga melakukan pemeriksaan yang diperlukan untuk menentukan apakah material tersebut ada di gudang.
45 Goods issue pada WM bisa didasarkan pada:
Delivery Dalam hal ini, barang dikeluarkan dari gudang untuk tujuan delivery yang dibuat di komponen Shipping.
Posting pada Inventory Management Ketika suatu goods issue di -posting pada IM, sistem akan membuat suatu transfer requirement yang digunakan sebagai dasar untuk membuat transfer order.
Two steps picking Pada Two steps picking, proses pengambilan barang dibagi menjadi dua langkah terpisah. Pada langkah pertama, semua kuantitas
material
yang
dibutuhkan
diambil
untuk
memenuhi permintaan tersebut (misalnya, beberapa delivery atau transfer requirement). Pada langkah kedua, material dibagi dan dialokasikan untuk memenuhi persyaratan yang diberikan. (WM Guide 2001, p219)
2.2.3.2.1
Proses
Pengeluaran
Barang
(Good
Issue)
Berdasarkan Suatu Delivery Komponen Sales and Distribution (SD) pada sistem SAP dapat digunakan untuk mengerjakan semua aktivitas sales (penjualan) dengan pelanggan dan Plant. Pada SD Shipping suatu delivery dibuat berdasarkan suatu sales order atau scheduling agreements. Delivery
46 menjadi dasar untuk shipping dan pada umumnya digunakan untuk memulai proses pengambilan barang. Hal – hal yang berlaku pada umumnya :
Delivery akan mengambil alih peranan dari transfer requirement.
Sistem akan membuat satu transfer order untuk tiap delivery. Jika fitur transfer order split diaktifkan, sistem juga dapat membuat beberapa transfer order untuk satu pengiriman.
Pada item level pada storage location, sistem akan mengenali bahwa item tersebut releven terhadap Warehouse Management. (WM Guide 2001, p220)
Gambar 2.15 Good Issue Processing Based Upon a Delivery (WM Guide 2001, p221)
47 Terbergantung
teknik
pengambilan
barang
digunakan, sistem akan mengambil material dari fixed bin (menggunakan picking list dari SD) atau membuat suatu transfer order untuk delivery. Jika proses pengambilan dilakukan bersamaan dengan suatu transfer order, status WM pada delivery akan diset menjadi “A” (relevan untuk Warehouse Management). Status WM akan di-updated setelah tiap langkah selama pengerjaan transfer order. Jika proses pengambilan tidak dilakukan bersama dengan transfer order, status WM pada delivery akan diset menjadi “N” (tidak relevan untuk Warehouse Management). (WM Guide 2001, p221)
2.2.3.3
Stock Transfer Stock Transfer pada WM adalah perpindahan fisik suatu barang dari satu lokasi penyimpanana ke lainnya, dari satu gudang ke lainnya atau dari satu storage bin gudang ke lainnya. Stock Transfer pada gudang (dalam satu warehouse number) tidak menyebabkan perubahan barang secara total dan hanya memerlukan posting di sistem WM (misalnya, ketika memindahkan barang dari satu storage bin ke lainnya). Proses ini tidak relevan bagi IM karena barang secara total pada sistem tetap sama. (WM Guide 2001, p316)
48 Stock transfer di sistem Material Management antara lain termasuk perpindahan fisik material dari:
Suatu plant/storage location ke plant/storage location lain
Gudang ke gudang
Storage bin ke storage bin (internal transfer)
Gambar 2.16 Stock Transfer in Material Management (WM Guide 2001, p316)
Untuk stock transfer yang terjadi di kompleks pergudangan yang sama (dalam satu warehouse number), dapat dibuat, dikelola dan ditampilkan informasi mengenai stock movement sejak barang tersebut diterima sampai meninggalkan gudang menggunakan sistem Warehouse Management (WM). Untuk proses stock transfer yang terjadi dari satu storage location ke storage location lain, proses akan dimulai di komponen Inventory Management (IM) dan
49 diselesaikan di Warehouse Management (WM). (WM Guide 360 2001, p316)
2.2.3.4
Posting Change Suatu Posting change pada umumnya adalah perubahan informasi mengenai material tertentu, misalnya ketika melepaskan barang dari proses pengawasan. Pada umumnya, Posting changes tidak melibatkan perpindahan barang secara fisik. Suatu Posting change biasanya merujuk kepada suatu perubahan informasi untuk material tertentu. Pada hampir semua proses Posting change, seperti perubahan batch number atau membuka akses ke barang yang tertutup, fisik barang akan berada di lokasi barang yang sama.
Posting change dilakukan untuk beberapa alasan, seperti:
Melepaskan barang dari proses pemeriksaan sehingga menjadi avalaible stock
Merubah status stock dari blocked stock (barang yang tidak bisa diakses) menjadi inspection stock
Merancang suatu material sebagai inspection stock
Merubah material number
Membagi suatu avalaible material menjadi dua batch atau lebih
50
Merubah special stock, seperti consignment stock atau returned stock, menjadi barang milik perusahaan
Mengganti kepemilikan barang di gudang yang sama dari satu plant ke plant lainnya. Meski dapat dimulai proses perubahan status material pada
komponen Warehouse Management (WM), proses posting change biasanya dimulai pada komponen aplikasi IM sebagai transfer posting dan selanjutnya diproses di WM. Ketika dimulai suatu transfer posting di IM, sistem akan membuat suatu posting change notice pada WM. Posting change notice hanya relevan untuk material yang dilacak pada WM yang sudah mengalami perubahan status. Untuk mengakhiri proses, transfer order untuk proses posting change notice pada WM harus dibuat dan dikonfirmasi.
2.2.3.4.1
Processing Posting changes Entirely Within WM Seluruh pemrosesan beberapa posting change untuk quant dapat dilakukan pada komponen Warehouse Management. Sistem lalu akan menjalankan semua proses yang diperlukan pada komponen Inventory Management (MM-IM). Metode pemrosesan ini bisa dilakukan untuk perubahan status material antara lain:
51
Quality
inspection,
unrestricted-use
blocked
stock
stock
dan
(barang yang
bisa
digunakan untuk tujuan apapun)
Consignment stock dan own restricted stock (barang milik sendiri dengan penggunaan terbatas)
Individual customer stock dan own stock
Returnable transport packing dan own stock
Project stock dan own stock Contoh
situasi
yang
digunakan
untuk
menjalankan posting change sebagai proses satu langkah adalah:
Mengganti status avalaible stock menjadi blocked
stock
karena
kerusakan
karton
pengemas, atau
Merubah consignment stock menjadi own stock untuk digunakan pada bagian produksi
(WM Guide 2001, p326)
2.2.3.5
Transfer requirement Transfer requirement digunakan untuk merencanakan dan memulai perpindahan barang. Transfer requirement melambangkan persyaratan tertentu yang diperlukan untuk memindahkan barang di
52 gudang. Transfer requirement adalah document yang bertujuan untuk merencanakan perpindahan barang menggunakan sistem Warehouse Management. Dengan membedakan antara perencanaan dan pelaksanaan suatu
perpindahan
barang,
dapat
diketahui
apakah
suatu
perpindahan barang masih akan dilaksanakan (transfer requirement open) atau sedang dilaksanakan (transfer order dibuat), atau sudah diselesaikan (transfer order dikonfirmasi). (WM Guide 2001, p 150)
2.2.3.5.1
Use of Transfer requirement Transfer requirement digunakan untuk meneruskan informasi perpindahan barang yang di-posting di Inventory Management (IM-MM) ke sistem Warehouse Management.
Transfer
requirement
dapat
juga
digunakan untuk tujuan berikut:
Untuk memulai perpindahan barang di WM
Untuk memulai proses pengisian ulang barang untuk production storage bin di area supply produksi
dengan
menggunakan
Production Planning (PP).
komponen
53
Untuk memanggil laporan transfer requirement untuk mendapatkan gambaran mengenai semua proses perpindahan barang yang tertunda.
Untuk mengakhiri transfer requirement, sistem Warehouse Management membuat transfer order, yang berfungsi untuk menjalankan proses perpindahan fisik barang di gudang. Sistem melakukan update terhadap transfer requirement ketika:
Transfer
order
dibuat,
dikonfirmasi,
atau
dibatalkan.
Posting penerimaan barang atau pengeluaran barang
di
inventory
management
(IM-MM)
dibatalkan sebelum transfer order yang terkait dibuat di sistem Warehouse Management.
Informasi-informasi dalam Transfer requirement umumnya mencakup, hal-hal berikut :
Barang apa yang akan dipindahkan?
Berapa banyak kuantitas yang akan dipindahkan?
Kapan akan dipindahkan? Tanggal
perencanaan
pengerjaan otomatis.
penting
untuk
fitur
54
Transfer type mana yang digunakan sebagai dasar perpindahan barang?
2.2.3.6
Transfer order Transfer order adalah dokumen yang digunakan untuk menjalankan perpindahan barang dengan bantuan Warehouse Management. Transfer order berisi semua informasi yang diperlukan untuk menjalankan transfer fisik material ke gudang, keluar gudang, atau dari storage bin ke storage bin lainnya digudang yang sama. Selain itu, transfer order juga digunakan untuk logical Stock Transfer. Stock Transfer logical terjadi misalnya, ketika suatu barang tidak lagi dalam status pemeriksaan dan bisa digunakan untuk operasional. Transfer logical ini pada WM disebut sebagai Posting changes. (WM Guide 2001, p 159)
Perpindahan barang secara fisik maupun logical, atau bahkan perubahan stok, bisa menjadi dasar suatu transfer order, seperti:
Pengambilan barang (picking)
Penempatan barang (putaway)
Posting changes
Repacking
Inventory
55 2.2.3.6.1
Use of Transfer order Sebagai prinsip dasar, anda bisa membuat transfer order menggunakan referensi suatu document asal dari sistem WM atau komponen aplikasi SAP lainnya, seperti:
Delivery document
Transfer requirement
Material document
Posting change notice
a. Transfer order Header Transfer order header berisi nomor transfer order dan tanggal pembuatan serta konfirmasi. Didalam Header juga akan didentifikasi transfer requirement atau delivery yang menjadi dasar transfer order, dan juga movement type yang digunakan.
b. Transfer order Item Jumlah item yang terdapat pada transfer order tergantung pada berapa banyak storage bin yang diakses sistem untuk mencapai kuantitas total barang yang diperlukan untuk picking requirement atau berapa
banyak
bin
yang
diperlukan
untuk
56 menyimpan barang (putaway). Transfer order item mempunyai bagian yang menjelaskan tujuan perpindahan barang untuk tiap item. Source Storage bin Destination storage bin Return storage bin (WM Guide 2001, p 160)
2.2.4
Picking dan Putaways Strategies 2.2.4.1
Putaway Strategies Putaway strategy yang digunakan oleh WM bertujuan untuk mengoptimalkan penyimpanan barang di gudang. (WM Guide 2001, p355) Sistem SAP ECC standar memiliki sejumlah Putaway Strategy yang sudah dikonfigurasi sebelumnya. Untuk beberapa strategi tersebut, cukup ditempatkan pada storage type yang diinginkan/diperlukan. Untuk strategi lainnya, perlu dilakukan beberapa setting tambahan sebelum dapat digunakan. Putaway strategy merupakan bagian dari “fitur dasar” pada SAP ECC. (SCM 630, p135)
57 Tabel 2.3 Putaway Strategy in Warehouse Management (WM Guide 2001, p355) Strategi (blank)
Pencarian Sistem According to user entry
F
Fixed Bin Storage Putaway Strategy
C
Open Storage Putaway Strategy
I
Addition to Existing Stock Putaway Strategy
L
Next Empty Storage bin Putaway Strategy
K
Putaway Near Picking Bin Putaway Strategy
P
Storage Unit type Putaway Strategy
B
Bulk Storage Putaway Strategy
Q
Dynamic Quant Number Putaway Strategy
(user exit)
Customer-defined strategy
Gambar 2.17 Source and Destination Storage (Putaway Process) (WM Guide 2001, p316)
58 Ketika barang disimpan di gudang, barang tersebut ditransfer dari interim storage area untuk Goods receipt. Informasi mengenai sumber (interim storage type, interim storage section, dan interim storage bin) tercatat pada transfer requirement atau akan ditentukan oleh sistem dari WM movement type.
2.2.4.1.1 Manual Entry Putaway Strategy Dalam Manual Entry Putaway Strategy, sistem tidak menggunakan suatu strategi untuk mencari suatu storage bin. User memasukkan storage bin tujuan ketika membuat suatu transfer order. Prosedur ini digunakan jika pencarian untuk suatu storage bin dilakukan ditempat oleh pekerja gudang. Pekerja gudang mencari storage bin yang sesuai. Lalu data mengenai storage bin tersebut (misalnya storage type dan koordinat) dimasukkan ke transfer order. Dianjurkan untuk menggunakan „manual entry‟ untuk mixed storage type dan interim storage type. (WM Guide 2001, p359)
2.2.4.1.2 Strategy F : Fixed Bin Storage Putaway Strategy Fixed Bin Storage Putaway Strategy, merupakan Putaway strategy yang digunakan ketika suatu material akan disimpan pada Fixed bin pada suatu Storage type. Strategi ini terutama digunakan pada Storage type yang
59 melakukan pengambilan barang secara manual. Tentukan fixed bin pada material master record (warehouse view). (WM Guide 2001, p360)
Gambar 2.18 Strategy F : Fixed Bin Storage Putaway Strategy (WM Guide 2001, p360)
2.2.4.1.3 Strategy C : Open Storage Putaway Strategy Open Storage Putaway Strategy merupakan Putaway strategy, dimana sistem menggunakan Open Storage Putaway Strategy untuk mencari storage bin pada suatu open
storage
section.
Open
storage
adalah
tipe
pengorganisasian gudang dimana a satu storage bin ditentukan untuk suatu storage section. Quant pada storage bin dalam hal ini juga dapat berupa mixed storage. (WM Guide 2001, p362)
60
Gambar 2.19 Strategy C : Open Storage Putaway Strategy (WM Guide 2001, p362)
2.2.4.1.4 Strategy I : Addition to Existing Stock Putaway Strategy Dengan menggunakan Addition to Existing Stock, sistem akan menempatkan barang pada storage bin yang sudah berisi bahan yang sama. Dengan menggunakan strategi ini, sistem akan mencari storage bin yang sudah berisi bahan tersebut. Satu persyaratan untuk penggunaan addition to existing stock adalah storage bin tersebut masih mempunyai kapasitas yang memadai. Jika sistem tidak bisa menemukan storage bin yang mempunyai bahan yang sama atau kapasitas storage bin tidak lagi memadai untuk
menampung
quant
tambahan,
sistem
akan
menggunakan strategi „rak kosong selanjutnya‟, yaitu
61 mencari storage bin kosong berikutnya. Prinsip FIFO akan dilanggar dengan penggunaan strategi ini; oleh karena itu, penggunaan stretegi ini dilakukan hanya jika gudang mempunyai ruang yang terbatas. (WM Guide 2001, p363)
Gambar 2.20 Strategy I : Addition to Existing Stock Putaway Strategy (WM Guide 2001, p363)
2.2.4.1.5 Strategy L : Next Empty Storage bin Putaway Strategy Next Empty Storage bin Putaway Strategy pada penerapannya,
storage
bin
kosong
yang
berikut
(setelahnya) akan diajukan oleh sistem. Gudang dengan metode pengorganisasian secara acak didukung oleh
62 strategi ini, dimana bahan disimpan pada storage section terpisah. Strategi ini terutama sesuai untuk high rack storage dan shelf storage. (WM Guide 2001, p365)
2.2.4.1.6 Strategy K : Putaway Near Picking Bin Strategy Putaway Near Picking Bin Strategy digunakan ketika suatu bahan akan ditempatkan di reserve storage area (area penyimpanan cadangan). Sistem tidak akan mencari untuk melihat apakah suatu fixed storage bin tersedia. Konfigurasi dapat dilakukan pada sistem sehingga penentuan fixed bin dilakukan pada awalnya dan jika rak kosong tidak ditemukan, sistem lalu menggunakan strategi untuk mencari area penyimpanan cadangan terdekat dari area fixed storage untuk bahan tersebut. Sistem pertama kali akan mencoba mencari reserve storage area di sekitar lokasi fixed storage bin, dimana pencarian dimulai dari lokasi terendah dan naik ke lokasi yang lebih tinggi. Jika storage bin kosong tidak ditemukan, sistem akan mencari ke sisi kanan dari fixed bin, lalu ke sisi kiri pada lorong yang sama, dan lalu pada lorong yang berdekatan. Sistem selalu mencari dari bawah ke atas. (WM Guide 2001, p366)
63 2.2.4.1.7 Strategy P : Storage Unit type Putaway Strategy Pada Storage Unit type Putaway Strategy, sistem akan memproses berbagai storage unit type (misalnya, pallet) dan menempatkannya pada bagian yang sesuai. Biasanya, satu storage bin dibagi menjadi beberapa bagian yang lebih kecil. Biasanya, hanya storage unit type yang sama yang bisa ditempatkan ke suatu storage bin pada satu waktu. High rack storage biasanya dirancang sehingga suatu storage bin bisa menampung beberapa storage unit type yang berbeda. Misalnya suatu storage bin bisa menampung sejumlah pallet tergantung pada ukuran pallet, seperti tiga standard pallet (80 x 120) atau dua industrial pallet (100 x 120). Suatu storage bin bisa menampung satu pallet dengan ukuran melebihi normal atau beberapa pallet yang berukuran sempit. Untuk strategi ini, jumlah quant maksimum perlu ditentukan untuk tiap kombinasi storage bin type dan storage unit type. Ketika barang pertama kali ditransfer ke storage bin, sistem akan menentukan tipe bin sectioning untuk storage bin tersebut. Sistem juga menentukan bagaimana dan berapa banyak storage unit yang bisa ditransfer ke storage bin. (WM Guide 2001, p367)
64
Gambar 2.21 Strategy P : Storage Unit type Putaway Strategy (WM Guide 2001, p367)
2.2.4.1.8 Strategy B : Bulk Storage Putaway Strategy Bulk Storage Putaway Strategy, merupakan strategi dimana Material dalam jumlah besar memakai banyak tempat untuk penyimpanan (misalnya ban, produk gelas dan minuman) seringkali disimpan dalam bentuk bulk storage. Keuntungan bulk storage antara lain:
Mengurangi kebutuhan storage bin fisik.
Mendapatkan akses yang lebih cepat ke trading unit.
Menghasilkan pembagian gudang secara terstruktur (menjadi blok dan baris).
65 Putaway strategy ini akan melakukan pencarian storage bin pada bulk storage. Fitur terpenting dari penggunaan bulk storage antara lain:
Bebas
menentukan
koordinat
struktur
gudang
Satu storage bin per baris
Storage unit type yang berbeda
Mixed storage
Storage unit type yang berbeda untuk tiap bahan
Automatic blocking per baris
Ketika storage type control untuk strategi ini ditentukan, terdapat beberapa indikator yang harus dipertimbangkan untuk mengendalikan pergerakan barang ke bulk storage, yaitu:
Combined Putaway
Partial Quantities
Block Transfer into the Row
Time Limit for Blocking
Total
Round off
(WM Guide 2001, p371)
66
Gambar 2.22 Strategy B : Bulk Storage Putaway Putaway Strategy (WM Guide 2001, p371)
2.2.4.1.9 Strategy Q : Dynamic Quant Number Putaway Strategy Dengan menggunakan Dynamic Quant Number Putaway Strategy, kapasitas gudang dapat didayagunakan dengan lebih baik. Dynamic storage bin coordinate dapat digunakan
untuk
menyimpan
bahan
yang
akan
ditempatkan di lokasi lain (seperti ID point) secara sementara jika proses putaway akan berlangsung lama. (WM Guide 2001, p371)
2.2.4.2
PickingStrategies Sistem SAP ECC standar memiliki beberapa picking strategy yang sudah terkonfigurasi. Dua strategi cukup ditempatkan
67 ke storage type yang diinginkan/dibutuhkan. Untuk lainnya, anda harus dibuat setting tambahan sebelum dapat digunakan. Picking strategy merupakan bagian dari “fungsi dasar” pada SAP ECC. (SCM 630, p195) Strategi-strategi
pada
WM
yang
digunakan
untuk
mengeluarkan barang dari gudang, ditunjukkan melalui Tabel 2.2 berikut. (WM Guide 2001, p390) Tabel 2.4 Picking Strategy in Warehouse Management (WM Guide 2001, p390) Strategi
Pencarian Sistem
F
FIFO (First In, First Out) Picking Strategy
(blank)
Using stringent FIFO for all storage types
L
LIFO (Last In First Out) Picking Strategy
A
Partial Quantities First Picking Strategy
M
According to Quantity Picking Strategy
H
Shelf Life Expiration Date Picking Strategy
P
Fixed Storage bin Picking Strategy
(user exit) Q
Customer-defined strategy Dynamic Quant Number Putaway Strategy
(user exit)
Customer-defined strategy
Informasi mengenai storage bin asal dan tujuan ketika barang diambil dan ditransfer keluar gudang akan ditangkap oleh sistem seperti ditunjukkan gambar dibawah ini.
68
Gambar 2.23 Source and Destination Storage (Putaway Process) (WM Guide 2001, p390)
2.2.4.2.1 Strategy F : FIFO (First In, First Out) Picking Strategy Pada Strategy F : FIFO (First In, First Out) Picking Strategy, sistem akan mengajukan quant terlama pada storage type sebagai quant yang sebaiknya ditransfer. Pada dasarnya, sistem menghitung „usia‟ (lama penyimpanan) dari suatu quant berdasarkan tanggal penerimaan barang dari aplikasi Inventory Management (IM). Tanggal penerimaan barang pada quant dan transfer requirement diaktifkan secara otomatis untuk semua penerimaan barang yang dimasukkan pada IM. Ketika
69 transfer order dibuat, tanggal ini akan di-copy ke quant record dari storage bin tujuan. Tanggal penerimaan barang yang diaktifkan oleh sistem dapat digunakan atau dapat juga menggunakan tanggal yang berbeda. Tanggal tersebut akan digunakan untuk
menghitung
usia
quant.
Tanggal
ini
akan
mempengaruhi urutan sortir untuk tiap bahan. (WM Guide 2001, p392)
2.2.4.2.2 Strategy L : LIFO (Last In First Out) Picking Strategy FIFO Picking Strategy tidak bisa digunakan untuk beberapa sektor industri atau tipe pergudangan. Misalnya, pada industri bahan bangunan, bahan yang disimpan sementara (bahan yang akan segera ditransfer keluar gudang), ditumpuk pada bahan yang sebelumnya sudah berada di gudang. Jika strategi FIFO digunakan selama pengambilan, bahan yang berada di tumpukan teratas harus dipindahkan sehingga pekerja bisa mencapai bahan dengan tanggal penerimaan terlama. LIFO (Last In First Out) Picking Strategy dapat digunakan ketika sistem mencari sebuah quant untuk dikeluarkan dari penyimpanan, sistem akan selalu mencari quant terakhir yang dimasukkan pada penyimpanan. (WM Guide 2001, p394)
70 2.2.4.2.3 Strategy A : Partial Quantities First Picking Strategy Pada penggunaan Partial Quantities First Picking Strategy,
prinsip
FIFO
akan
ditunda
untuk
mengoptimalkan penanganan barang pada gudang. Jumlah storage unit dengan partial quantities pada storage type akan dikurangi menjadi sesedikit mungkin. Strategi ini sesuai untuk kondisi ketika:
Fitur Standard Storage unit type digunakan untuk penempatan barang (terdapat bahan untuk storage unit tertentu dalam jumlah yang sama).
Kuantitas parsial storage unit kurang dari kuantitas standar storage unit.
Sistem akan mencari quant berdasarkan langkah berikut: 1. Jika kuantitas yang diinginkan pada transfer order sama atau lebih besar dari kuantitas suatu standard storage
unit,
sistem
akan
mencoba
untuk
memindahkan suatu standard storage unit dari stok. 2. Jika tidak terdapat standard storage unit, sistem akan menggunakan kuantitas parsial storage unit. 3. Jika kuantitas yang diinginkan pada transfer oder kurang dari kuantitas standard storage unit, sistem pertama akan mencoba memindahkan kuantitas parsial storage unit dari stok.
71 4. Jika tidak terdapat kuantitas parsial storage unit, full storage unit akan dipecah. Pencarian full storage unit dilakukan berdasarkan prinsip FIFO. (WM Guide 2001, p395)
2.2.4.2.4 Strategy M : According to Quantity Picking Strategy Penggunaan
According
to
Quantity
Picking
Strategy merupakan strategi yang memiliki prinsip utama, berdasarkan apakah kuantitas yang diperlukan pada transfer order berjumlah besar atau kecil. Anda bisa mempunyai storage type tempat menyimpan bahan dalam jumlah kecil (biasanya suatu fixed storage bin). Anda juga bisa mempunyai tempat penyimpanan cadangan untuk menyimpan bahan dalam jumlah besar. Sistem akan menentukan transfer yang akan dilakukan dalam „jumlah kecil‟ atau „jumlah besar‟ berdasarkan kuantitas yang diperlukan di transfer order. Storage bin tempat pengambilan bahan bisa berupa storage type untuk kuantitas kecil maupun storage bin untuk kuantitas besar. Sebagai standar untuk pemeriksaan kuantitas ini, sistem menggunakan control quantity yang ditentukan pada kolom Control Quantity di material master record. Sistem
dapat
menganjurkan
kuantitas
72 pemindahan barang untuk picking strategy ‘according to quantity’ dan juga ‘random picking’.
Penanganan Kuantitas Besar dan Kecil Pada contoh, digunakan dua storage type yaitu fixed bin storage dan high rack storage. Sistem memilih quant dari storage bin di fixed bin storage jika kuantitas yang diinginkan kurang dari atau sama dengan control quantity yang sudah ditentukan di material master record. Sistem akan mencari quant di high rack storage jika kuantitas yang diinginkan lebih besar dari control quantity. (WM Guide 2001, p396)
Gambar 2.24 Small and Large Quantites Handling (WM Guide 2001, p396)
73 2.2.4.2.5 Strategy H : Shelf Life Expiration Date Picking Strategy Pada Shelf Life Expiration Date Picking Strategy, sistem akan memastikan bahwa bahan dengan waktu kadaluarsa terdekat akan dikeluarkan terlebih dahulu dari sistem. (WM Guide 2001, p399)
Tabel 2.5 Kode warna pada SLED Control List Warna
Keterangan Tanggal Kadaluarsa
Hijau
Belum sampai
Kuning
Hari ini
Merah
Sudah terlampaui
2.2.4.2.6 Strategy P : Fixed Storage bin Picking Strategy Pada Fixed Storage bin Picking Strategy, sistem akan mencari barang menggunakan storage bin yang sudah ditentukan oleh user di material master. Dianjurkan replenishment control diaktifkan untuk fixed storage bin ketika strategi ini digunakan. (WM Guide 2001, p400)
2.2.5 Implementing R/3 - ASAP (Acelerated SAP) Implementing R/3 dapat diartikan sebagai penggunaan aplikasi software SAP R/3 untuk memenuhi kebutuhan informasi bisnis. SAP R/3 menyediakan beberapa tools dan extensive documentation yang berguna memfasilitasi implementasi sistem. Tools dan implementation manuals dapat diakses melalui SAP online documentation atau secara langsung melalui sistem R/3 dari menu Tools Business Engineering.
74
The Customizing Manual The Customizing Manual merupakan kostumisasi melalui menu
Tools Business Engineering Customizing dilakukan untuk menerapkan software SAP R/3 ke dalam bisnis. Manual tersebut menyediakan suatu petunjuk yang komprehensif dari proses keseluruhan termasuk referensi kepada petunjuk lainnya.
The Procedure Model and ASAP (Accelerated SAP) The Procedure Model diperkenalkan pada tahun 1995 dan
merupakan langkah kemajuan yang besar bagi proses implementasi yang lebih mudah serta menyediakan framework terhadapnya. ASAP diperkenalkan tahun 1996 di USA sebagai solusi bagi implementasi yang lebih cepat, dan telah dikembangkan pada full-featured solution. (Hernández, 2000, p.591)
Gambar 2.25 Procedure Model vs ASAP (Hernández, 2000, p592)
75 ASAP adalah metode dan tools untuk mengimplementasikan SAP R/3 yang
memberikan
support
terbaik
dengan
mengambil
pertimbangan
pengalaman dari banyak proyek implementasi R/3 yang telah sukses. Pengalaman-pengalaman tersebut didokumentasikan dalam Roadmap, yang digunakan untuk merencanakan implementasi R/3. (Brand, 1998, p.5) Metode implementasi ASAP ini memiliki lima tahap atau fase implementasi, yaitu Project Preparation, Business Blueprint, Realization, Final Preparation, dan Go Live and Support.
2.2.5.1 Project Preparation Pada tahap ini ditentukan strategi untuk implementasi, mengatur tim proyek, menentukan system landscape, menentukan permintaan teknikal dan memilih vendor hardware dan database. Proyek implementasi dimulai dengan kick-off meeting. Pada pertemuan tersebut manajer proyek akan menjelaskan tujuan dan rencana kerja. Sebelum melanjutkan ke tahap implementasi berikutnya, manajer proyek harus mengecek kualitas hasil dan me-release tahap Project Preparation. (Brand, 1998, p.5)
2.2.5.1.1 Strategi Implementasi Terdapat dua hal penting dalam menentukan strategi implementasi, antara lain: (Brand, 1998, p.8)
Menentukan pilihan mengenai kebutuhan jumlah sistem
R/3
yang
terhubung
untuk
struktur
76 organisasi perusahaan.
Bagaimana R/3 akan menggantikan sistem yang berjalan saat ini dan melalui interface apa R/3 akan melakukan
pertukaran
data
dengan
sistem
eksternal.
2.5.1.1.1 System Topology Sistem
SAP
R/3
memiliki
arsitektur
three-tier
client/server. Seluruh data disimpan pada satu database dan data diproses pada application layer pada application server. SAPgui frontend (presentation layer) adalah interface ke user. Ketiga layer tersebut terhubung satu sama lain melalui jaringan. (Brand, 1998, p.8)
Gambar 2.26 R/3 Architecture (Sumber : www.help.sap.com)
77 2.5.1.1.2 Migrasi Pada awalnya, kebanyakan perusahaan hanya mengganti sebagian infrastruktur teknologi informasinya dengan R/3. Dalam mengimplementasi modul R/3 yang beragam, dapat bergantung pada ukuran perusahaan atau batasan
geografis.
R/3
hampir
selalu
melakukan
pertukaran data dengan sistem sebelumnya. Perusahaan yang memiliki mainframe sebagai sistem sebelumnya memiliki beberapa pilihan, diantaranya: (Brand, 1998, p.9)
Full Migration (Big Bang) R/3 mengganti seluruh aplikasi dari sistem sebelumnya dalam satu waktu. Interface permanen untuk sistem sebelumnya tidak diperlukan.
Step by step migration (cooperative operation) R/3 hanya sebelumnya.
mengganti sebagian dari sistem Contoh:
mengimplementasi Controlling, Production
lalu
pertama,
Financial Sales
Planning.
Accounting and
hanya dan
Distribution,
Aplikasi-aplikasi
ini
membutuhkan interface permanen unuk sistem sebelumnya.
78 2.2.5.1.2 Organisasi Proyek Menurut Brand (1998, p.10), kesuksesan sebuah proyek tidak hanya bergantung pada metode yang digunakan, tetapi juga bergantung pada orang-orang yang terlibat didalamnya. Jika para karyawan dimasukkan ke dalam tim proyek berdasarkan perilaku dan kemampuan mereka, hal ini bisa menghemat uang dan waktu. Untuk memastikan anggota tim dapat bekerja sama secara efektif dan menghindari pekerjaan yang tidak diperlukan, maka harus ada batasan untuk setiap tugas dan pembagian tanggung jawab untuk setiap anggota tim terhadap aspek dari implementasi. Dalam
melakukan
implementasi,
peran
Tim
Proyek dibagi menjadi Manajemen Proyek, Proses Bisnis, Implementasi Teknikal, Quality Assurance, Production Support, dan Pelatihan dan Dokumentasi. Peranan dalam sebuah Tim Proyek antara lain: ● Steering Committee Steering Committee terdiri dari Sponsor Proyek, Manajer Proyek,
dan Manajer Konsultasi SAP. Komite ini
mengalokasikan
sumber
daya
dan
memonitor
perkembangan proyek. ● Manajemen Proyek Manajemen Proyek menentukan strategi implementasi, mendapatkan dan mengelola sumber daya, dan secara
79 berkala menginformasikan
status proyek kepada
Steering Committee dan Tim Proyek. ● Tim Proses Bisnis Tim Proses Bisnis membuat To-Be Vision untuk proses bisnis (Business Blueprint), melakukan setting proses tersebut pada R/3, melakukan pengujian terhadap setting, membuat dokumentasi untuk pelatihan user. ● Tim Teknikal Tim Teknikal membuat To-Be Vision untuk kebutuhan teknikal, meng-install dan mengkonfigurasi R/3 System Landscape, melakukan pengujian terhadap setting, mengelola sistem R/3, dan menjabarkan operasi sistem. ● Tim Pelatihan dan Dokumentasi Tim Pelatihan dan Dokumentasi menentukan strategi pelatihan,
mengembangkan
materi
pelatihan,
dan
melatih user.
2.2.5.1.3 System Landscape Dalam merencanakan System Landscape, terdapat tiga aspek penting, antara lain: (Brand, 1998, p.12) ●
Menentukan
banyaknya
sistem
R/3
yang
dibutuhkan untuk melakukan adaptasi sistem ke proses bisnis dalam perusahaan. ●
Menentukan berapa banyak dan ke dalam unit organisasi apa sistem R/3 akan dibagi. Hal ini biasa
80 dikenal sebagai Clients. ●
Menentukan bagaimana cara memindahkan setting dari standar sistem R/3 dan program yang baru dikembangkan antara sistem sebelumnya dengan sistem yang baru.
2.5.1.3.1 Three System Landscape Aplikasi produksi tidak dapat dijalankan dalam sistem R/3 ketika customizing dan pengembangan software sedang dijalankan karena terjadi perubahan dalam lingkungan sistem R/3. SAP merekomendasikan Three-System Landscape dengan sistem yang berbeda untuk pengembangan (development), quality assurance, dan produksi. (Brand, 1998, p.92)
●
Sistem Pengembangan (Development) Pada sistem R/3 ini dilakukan pengembangan program dan customize sistem R/3. Objek yang berubah dikumpulkan sesuai dengan kebutuhan yang berubah dan disiapkan untuk ditransfer ke sistem yang lain.
●
Sistem Quality Assurance Pada sistem R/3 ini dilakukan pengujian terhadap objek yang berubah yang sudah
81 disiapkan dalam sistem pengembangan dan dilakukan validasi terhadap customizing dan software yang berubah. Setelah itu akan dirilis customizing dan software yang bebas kesalahan (error-free) untuk keperluan sistem produksi. ●
Sistem Produksi Pada sistem R/3 ini customizing dan software hasil pengujian digunakan untuk menjalankan aplikasi
2.5.1.3.2 Client Dalam setiap System Landscape, harus ada minimal tiga clients yang berbeda yang mempunyai peran yang berbeda, yaitu development client, quality assurance client, dan production client. Peran yang berbeda dapat ditambahkan tergantung kebutuhan, misalnya training client.
Masing-masing
client
dalam
sistem
R/3
diidentifikasi dengan kombinasi tiga angka yang unik. (Brand, 1998, p.12)
2.5.1.3.3 Transport System Untuk memastikan tidak terjadinya kesalahan dalam perpindahan ke Sistem Produksi, ada empat tahapan
82 dalam melakukan suatu perpindahan: (Brand, 1998, p.16) ●
Me-release objek hasil pengembangan atau perubahan dari Sistem Pengembangan.
●
Meng-import objek hasil pengembangan atau perubahan ke dalam Quality Assurance System.
●
Melakukan
pengujian
dan
validasi
pengembangan setting dan software pada Quality Assurance System. Meng-import objek hasil pengembangan atau perubahan ke dalam Sistem Produksi.
2.2.5.2 Business Blueprint Menurut Brand (1998, p.6), Business Blueprint menyediakan strategi umum mengenai bagaimana proses bisnis dalam perusahaan dipetakan ke dalam satu atau lebih sistem SAP. Business Blueprint mendokumentasikan secara rinci lingkup dari skenario bisnis, proses bisnis, tahapan proses, dan kebutuhan dalam implementasi solusi SAP. Business Blueprint terdiri dari elemen-elemen di bawah ini: ●
Unit Organisasi (Organizational Unit)
●
Master Data
●
Business Scenarios
●
Business Processes
83 2.2.5.2.1 Unit Organisasi Unit Organisasi merupakan objek organisasi yang digunakan untuk membentuk dasar dari suatu rencana organisasi. Unit Organisasi merupakan unit fungsional dalam perusahaan. Dengan menggambarkan unit organisasi dan hubungan hirarki atau matriks di antara unit organisasi, maka struktur organisasi bisa dibentuk. (www.help.sap.com)
2.2.5.2.2 Master Data Master Data berisi semua informasi yang penting pada SAP Retail misalnya pada site, vendor, dan customer dan juga untuk articles yang terlibat. Informasi ini termasuk pricing dan siklus kontrol data dan disimpan dalam sistem untuk digunakan kembali ketika user memproses transaksi bisnis. Ketika master data dirawat secara konsisten, waktu yang dibutuhkan untuk memproses transaksi bisa berkurang secara drastis, karena sistem bisa secara otomatis men-default transaksi bisnis pada field yang relevan. (www.help.sap.com)
2.2.5.2.3 Business Scenario Business Scenario merupakan suatu kumpulan proses bisnis yang mendefinisikan suatu kegiatan bisnis dalam metode komprehensif dan serba lengkap pada level makro. Business scenario berhubungan dengan unit bisnis, fungsi
84 utama, atau pusat keuntangan (profit center) perusahaan, dan bisa juga melibatkan mitra bisnis dari perusahaan yang lain. Business scenario terdiri dari sejumlah varian, masing-masing varian menjelaskan suatu arus bisnis end-to-end. Setiap arus bisnis end-to-end diwakilkan dengan suatu rangkaian yang tersusun dari proses bisnis. (www.help.sap.com)
2.2.5.2.4 Business Process Proses bisnis merupakan rangkaian aktivitas logikal atau kronologikal untuk melakukan suatu kegiatan yang menghasilkan informasi. (www.help.sap.com)
2.2.5.3 Realization Pada tahap ini, dilakukan set-up sistem R/3 untuk menguji setting. Proses ini dinamakan Quality Assurance System. Seperti tahap-tahap sebelumnya, manajer proyek akan mengecek
hasil
dan
me-release
tahap
Realization.
(Brand, 1998, p.6)
2.2.5.4 Final Preparation Pada tahap ini, dilakukan set-up operasi produksi sistem dan import data dari sistem yang berjalan. Untuk memulai produksi dengan R/3 tanpa masalah, harus dilakukan pengecekan setting sistem, menguji sistem melalui proses bisnis yang paling penting, dan membuat help
85 desk. Pada akhir tahap ini, harus diputuskan kapan akan memulai produksi. (Brand, 1998, p.6)
2.2.5.5 Go live and Support Setelah memulai produksi, harus dipastikan availability produksi sistem. Pada tahap Final Preparation tidak bisa dilakukan pengecekan seluruh setting dan sistem secara rinci. Maka setelah sistem baru dijalankan, sistem akan dipantau apakah ada kesalahan atau tidak (support). Setelah tahap support selesai maka implementasi sistem R/3 selesai. (Brand, 1998, p.7)
2.2.6 Flowchart Menurut Mulyadi (2001, p60) Sistem akuntansi dapat dijelaskan menggunakan bagan alir dokumen. Flowchart adalah salah satu cara metode penggambaran untuk meggambarkan bagan alir suatu sistem.
2.2.7 Unified Modeling Language (UML ) UML adalah alat untuk menggambarkan gambaran dari sistem yang akan dibuat melalui diagram dan simbol. UML menggunakan konsep Object Oriented Programming. Melalui seperangkat diagram, UML menyediakan standar yang memungkinkan sistem analis untuk merancang berbagai sudut pandang dari sistem, yang dinamakan model, yang dimengerti oleh client, programmer, dan siapapun yang terlibat dalam proses pengembangannya (Schmuller, 1999, p16-17).
86 2.2.7.1
Use Case Diagram 2.2.7.1.1
Usage Mencerminkan bagaimana sistem berinteraksi dengan actor di dalam sebuah context. Actor adalah suatu abstrak dari pemakai atau sistem lain yang berinteraksi dengan target sistem. Sedangkan use case adalah suatu pola interaksi antar sistem dan actor di dalam Application Domain. (Mathiassen et al. 2000, p135)
