bab 2 landasan teori 2.1 teori umum 2.1.1 pengertian...
TRANSCRIPT
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.
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
2000s Extended ERP
1990s Enterprise Resource Planning (ERP)
1980s Manufacturing Resource Planning (MRP II)
1970s Material Requirements Planning (MRP)
1960s Inventory Control Packages
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, misalnya memperbaiki kerjasama,
ketersediaan informasi, 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, menjadi dasar untuk
perkembangan selanjutnya 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 cabang-
cabang 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).
Initiative Evaluation Selection
Business
Process
Reengineering
Modification Training
Conversion of
Data
Go-Live Termination
Exploitation
and
Development
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 :
Production Facility
Distribution Centre
Kantor pusat perusahaan
Maintenance Location
2.2.2.2.2 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 merupakan
langkah-langkah posting penerimaan 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, blocked stock dan
unrestricted-use stock (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 komponen
Production Planning (PP).
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 penting untuk fitur
pengerjaan otomatis.
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 Pencarian Sistem
(blank) 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)
Informasi mengenai storage bin asal dan tujuan ketika
barang diambil dan ditransfer keluar gudang akan ditangkap oleh
sistem seperti ditunjukkan gambar dibawah ini.
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) Customer-defined strategy
Q Dynamic Quant Number Putaway Strategy
(user exit) Customer-defined strategy
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 mengganti sebagian dari sistem
sebelumnya. Contoh: pertama, hanya
mengimplementasi Financial Accounting dan
Controlling, lalu Sales and Distribution,
Production Planning. 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)