Bab 3 Analisis dan Perancangan

3.1

Gambaran Umum Perusahaan 3.1.1 Sejarah PT. Indomarco Prismatama PT Indomarco Prismatama adalah perusahaan pengelola jaringan minimarket Indomaret. Indomaret merupakan salah satu jaringan minimarket di Indonesia yang menyediakan kebutuhan pokok dan kebutuhan sehari-hari. Awal terbentuknya perusahaan ini diawali dari sebuah toko Indomaret yang menyediakan kebutuhan pokok dan kebutuhan sehari-hari yang pertama kali dibuka pada tahun 1987 di Pontianak, Kalimantan Barat. Tokoh yang merintis berdirinya perusahaan ini adalah Sudono Salim beserta anaknya yakni Anthony Salim. Tokoh ayah dan anak ini juga dikenal luas sebagai pengusaha yang sukses antara lain sebagai pemilik perusahaan Bogasari, Indofood, Indosiar, dan lain-lain. Usaha ini mulai berkembang ketika PT Indomarco Prismatama pertama kali membuka gerai Indomaret di Jakarta yang berlokasi di Ancol, Jakarta Utara pada November 1988 yang kemudian disusul dengan pembukaan gerai-gerai Indomaret di tempat-tempat lainnya. Pada tahun 1997, setelah 230 gerai Indomaret terbukti menguntungkan, PT. Indomarco Prismatama mulai memperkenalkan sistem kemitraan kepemilikan dan pengelolaan gerai dengan cara waralaba dan mengembangkan bisnis gerai waralaba pertama di Indonesia. Mitra usaha waralaba ini meliputi koperasi, badan usaha dan perorangan. Pada Mei 2003, sistem waralaba Indomaret telah terbukti keberhasilannya dengan diperolehnya

penghargaan dari Presiden Republik Indonesia saat itu yaitu Presiden Megawati 55

56 Soekarno Putri sebagai Perusahaan Waralaba Nasional 2003. Saat ini Indomaret berjumlah 3531 gerai di mana 1998 gerai adalah milik sendiri dan 1533 gerai sisanya merupakan gerai waralaba milik masyarakat yang tersebar di berbagai wilayah seperti Jabodetabek, Jawa Barat, Jawa Tengah, Jawa Timur, Yogyakarta, Bali, Medan, dan Lampung. Di DKI Jakarta sendiri telah hadir sekitar 488 gerai Indomaret yang siap memenuhi hampir semua kebutuhan sehari-hari konsumen dengan menawarkan lebih dari 3.500 jenis produk makanan dan non-makanan dengan harga bersaing. Segmen pasar yang menjadi sasaran Indomaret adalah konsumen dari semua kalangan masyarakat sehingga penempatan lokasi gerai-gerai Indomaret dapat dengan mudah ditemukan di mana saja seperti daerah perumahan, gedung perkantoran, dan fasilitas umum. Penempatan lokasi gerai yang strategis, yang sesuai dengan motto Indomaret yaitu Mudah dan Hemat, ditujukan untuk memudahkan Indomaret melayani sasaran demografisnya yakni keluarga. Hubungan kerja sama yang dijalin dengan lebih dari 500 pemasok membuat Indomaret memiliki posisi yang baik dalam menentukan produk-produk yang akan dijualnya. Selain itu, sistem distribusi yang didukung oleh jaringan pemasok yang handal dalam menyediakan produk terkenal dan berkualitas serta sumber daya manusia yang kompeten menjadikan Indomaret sangat efisien dalam mendistribusikan produknya sehingga Indomaret mampu memberikan pelayanan yang terbaik kepada para konsumennya. Strategi pemasaran Indomaret juga diintegrasikan dengan kegiatan-kegiatan promosi yang dilaksanakan sehingga Indomaret dapat secara berkala menjalankan

57 berbagai program promosi seperti memberikan penawaran harga khusus, undian berhadiah maupun hadiah langsung. Keberadaan Indomaret ini juga diperkuat oleh beberapa anak perusahaan di bawah bendera grup INTRACO seperti Indogrosir, BSD Plaza dan Charmant. Keunggulan-keunggulan yang telah dimiliki oleh Indomaret tersebut tidak menyurutkan semangat PT. Indomarco Prismatama untuk terus berusaha mengembangkan Indomaret sebagai jaringan minimarket terbaik di Indonesia.

3.1.2

Visi, Misi, Motto, dan Budaya Perusahaan Visi dan misi PT. Indomarco Prismatama tentunya berkaitan dengan

Indomaret yakni sebagai berikut: Visi Menjadi aset nasional dalam bentuk jaringan retail waralaba yang unggul dalam persaingan global. Misi Meningkatkan pelayanan terbaik sehingga kepuasan pelanggan menjadi sasaran utama yang harus dapat dipenuhi.

58 Visi dan misi perusahaan juga didukung oleh motto dari Indomaret yakni Mudah dan Hemat dan budaya perusahaan yakni, Dalam bekerja kami menjunjung tinggi nilai-nilai: Kejujuran, kebenaran, dan keadilan Kerja sama tim Kemajuan melalui inovasi yang ekonomis Kepuasan pelanggan

59 3.1.3 Struktur Organisasi PT. Indomarco Prismatama

Gambar 3.1 Struktur Organisasi PT. Indomarco Prismatama

60

Setiap posisi dan bagian dalam perusahaan memiliki wewenang dan tanggung jawabnya masing-masing dalam melaksanakan kegiatan perusahaan untuk mencapai tujuan-tujuan yang diinginkan. Daftar wewenang dan tanggung jawab masing-masing posisi dan bagian di PT. Indomarco Prismatama adalah sebagai berikut: 1. Presiden Director Tanggung jawab dan wewenang yang dimiliki adalah sebagai berikut: a. Mengkoordinasi semua tanggung jawab direktur di bawahnya. b. Mengarahkan dan mengawasi perkembangan perusahaan. c. Menetapkan dan mengarahkan strategi bisnis perusahaan. d. Mengendalikan dan mengawasi jalannya seluruh kegiatan

operasional perusahaan.

2. Internal Audit Director Tanggung jawab dan wewenang yang dimiliki adalah sebagai berikut: a. Memastikan terlaksananya kebijakan perusahaan yang telah ditetapkan di semua divisi. b. Mengaudit dan memastikan apa yang seharusnya dijalankan sesuai dengan sistem dan procedure yang dilaksanakan. c. Menganalisa dan memberikan saran terhadap semua hal yang terjadi di lapangan termasuk perkembangan bisnis yang ada.

61 3. Operation Director Bertanggung jawab terhadap manajemen operasional dan pengembangan bisnis perusahaan secara simultan serta bertanggung jawab membawahi Region I, Region II, dan Marketing. Wewenang dan tanggung jawab bagian-bagian yang disebutkan adalah sebagai berikut: Region I Bertanggung jawab atas kegiatan para kepala cabang yang berada di Jakarta I (Jakarta Barat, Jakarta Utara, dan sebagian Jakarta Timur), Jakarta II (Bogor, Depok, sebagian Jakarta Selatan), dan Bekasi (Cikarang, Cikampek). Region II Bertanggung jawab atas kegiatan kepala cabang yang berada di Semarang, Tangerang, Surabaya, Bandung. Marketing Terdiri dari dua bagian yaitu sebagai berikut: o Bagian yang berhubungan dengan supplier untuk

penyediaan barang dagangan yang ada di toko. o Bagian yang berhubungan dengan waralaba toko yaitu melakukan penjualan toko secara waralaba kepada investor.

62 4. Human Resources & Services Director Tanggung jawab dan wewenang yang dimiliki adalah sebagai berikut: a. Mengatur dan mengelola Sumber Daya Manusia (SDM) yang ada. b. Pengembangan SDM. c. Karir dan perekrutan karyawan. d. Pengadaan barang di luar barang dagangan (contoh : aktiva tetap) e. Membawahi bagian-bagian berikut: Human Resources o Melaksanakan karyawan. o Melaksanakan evaluasi kerja karyawan. Personal and General Affair o Bertanggung jawab untuk mengelola SDM yang telah tersedia secara administrasi. o Memberikan informasi kepada Education and penerimaan dan pengangkatan

Training untuk peningkatan kinerja Sumber Daya Manusia. o Mendata dan memelihara harta perusahaan. o Mengidentifikasikan seluruh karyawan. o Menyelenggarakan pelatihan. o Mengevaluasi efektifitas pelatihan. kebutuhan pelatihan untuk

63 o Menciptakan hubungan kerja yang baik antara karyawan dengan perusahaan. Education and Training o Bertanggung jawab untuk pengembangan SDM sesuai dengan kebutuhan perusahaan baik secara internal maupun eksternal (misalnya, memanggil trainer dari luar perusahaan). General Purchasing o Bertanggung jawab melakukan pembelian barangbarang kebutuhan operasional (aktiva tetap dan barang-barang inventaris) perusahaan di luar barang dagangan. o Melakukan perbandingan harga dari minimal 2 supplier untuk mendapatkan barang-barang

operasional yang lebih murah dan berkualitas. o Melaksanakan pembelian di luar barang dagangan sesuai dengan permintaan dari seluruh bagian. o Menerima dan mengevaluasi semua kontrak

pembelian di luar barang dagangan. Project Development o Bertanggung jawab untuk melakukan renovasi toko yang akan disewa atau dibeli oleh perusahaan atau ter-waralaba agar sesuai dengan standar Indomaret.

64 o Membangun toko baru dan memperbaiki toko-toko yang rusak.

5. Business Development Director Tanggung jawab dan wewenang yang dimiliki adalah sebagai berikut: a. Mencari lokasi dalam upaya pengembangan perusahaan / group. b. Merenovasi toko. c. Pengembangan franchise. d. Membawahi bagian-bagian berikut: Location Development o Bertanggung jawab untuk mencari lokasi yang sesuai dengan standar Indomaret. Franchise Development o Bertanggung jawab untuk mencari investor untuk menjadi ter-waralaba. Project & Renovation o Bertanggung jawab untuk membangun dan

merenovasi toko yang sesuai dengan standar Indomaret.

65 6. Finance Director Bertanggung jawab terhadap administrasi keuangan dan pajak serta membawahi bagian-bagian berikut: Finance & Administration o Melaksanakan pekerjaan-pekerjaan administrasi perusahaan. Treasury o Membayar gaji karyawan yang berada di level manager ke atas. o Melakukan hubungan dengan pihak perbankan. Taxation o Melaksanakan perpajakan perusahaan yang sesuai dengan ketentuan yang berlaku. o Berhubungan langsung dengan kantor pajak. Controlling o Melakukan pemastian agar tidak terjadi penyimpanganpenyimpangan dari budget yang telah ditetapkan

sebelumnya. Apabila telah terjadi maka Controlling akan mencari penyebab terjadinya penyimpangan tersebut. o Mengontrol suatu proses kerja di cabang agar dapat lebih efisien. Policies System

66 o Membuat suatu kerangka kerja dari sebuah divisi secara sistematis sehingga dapat terkontrol dan sasaran perusahaan dapat tercapai.

7. Merchandising Director Tanggung jawab dan wewenang yang dimiliki adalah sebagai berikut: a. Menangani ketersediaan barang-barang dagangan b. Membina hubungan yang baik dengan pemasok c. Melakukan market survey secara berkala dan terinci terutama dalam bidang retail d. Mengevaluasi calon pemasok. e. Evaluasi berkala terhadap pemasok. f. Pengajuan keluhan atau pengembalian barang dagangan yang tidak sesuai kepada pemasok g. Untuk pelaksanaan tanggung jawab di atas lebih lanjutnya ditangani oleh masing-masing bagian di bawah ini : Food Merchandising Non Food Merchandising Perishable Merchandising General Merchandising I General Merchandising II Regional Merchandising Merchandising Support and Development

67

8. Information and Development Director Bertanggung jawab dalam pengadaan program komputer untuk setiap departemen sehingga proses kerja menjadi lebih efisien (tidak padat karya). Selain itu, Information and Development Director juga membawahi bagian Software Development I, II, dan III yang bertanggung jawab dalam pembuatan program atau aplikasi yang berbeda-beda. Contoh pekerjaan dari masing-masing bagian adalah sebagai berikut: Software Development I Contoh: Pembuatan program untuk divisi Finance and Administration Software Development II Contoh: Pembuatan program untuk divisi Operation. Software Development III Contoh: Pembuatan program untuk divisi Merchandising.

68 Bagian-bagian lain yang dibawahinya adalah sebagai berikut: Data Processing o Bertanggung jawab atas pemrosesan data-data yang ada. Technology Development o Bertanggung jawab untuk pengembangan program-program dengan teknologi atau hal-hal baru. Technical Support o Bertanggung jawab terhadap hardware, jaringan, dan lainlain yang terkait dengan komputer.

69 3.2 Analisis Sistem yang Berjalan 3.2.1 Proses Bisnis Terkait Purchase Order

Gambar 3.2 Flow Chart Sistem yang Berjalan

70 Proses pembelian barang hingga menghasilkan purchase order pada PT. Indomarco Prismatama dijelaskan sebagai berikut: 1. Jika suatu gerai Indomaret membutuhkan barang, maka gerai tersebut akan meminta barang yang dibutuhkan kepada Distribution Centre (DC). Ada 13 buah DC yang ditempatkan sesuai dengan kawasan operasional yang sudah ditentukan sehingga setiap gerai hanya akan dilayani oleh satu DC saja dan sebaliknya setiap DC tentunya melayani ratusan gerai. 2. Permintaan barang dari seluruh gerai yang menjadi tanggung jawab Distribution Centre (DC) bersangkutan akan diproses setiap harinya. DC yang juga berfungsi sebagai gudang ini, akan terlebih dahulu memeriksa ketersediaan barang di gudang. Jika barang yang diminta masih tersedia, maka barang tersebut akan segera dikirimkan ke gerai Indomaret yang membutuhkannya. Jika ternyata barang yang diminta sudah tidak tersedia, maka DC akan mengeluarkan surat permintaan barang (PB) dan mengirimkannya ke bagian merchandising. Surat PB ini berisikan daftar permintaan barang oleh seluruh toko yang menjadi tanggung jawab DC tersebut. Setiap DC biasanya mengirimkan satu PB, yang berisikan sekitar 3000 barang, kepada bagian merchandising setiap harinya. Dalam kasus tertentu seperti menipisnya persediaan barang di gudang, DC dapat mengeluarkan PB tanpa harus menunggu adanya permintaan dari gerai yang menjadi tanggung jawabnya. 3. Bagian merchandising kemudian akan memproses setiap Permintaan Barang (PB) ini dengan memecahnya menjadi beberapa usulan order (UO) yang kemudian setiap UO ini akan diproses menjadi purchase order (PO)

71 yang ditujukan untuk satu atau lebih supplier. PB harus dipecah menjadi beberapa PO dikarenakan daftar permintaan barang, yang terdapat di dalam PB, disusun tanpa memperhatikan jenis barangnya yang pada kenyataannya barang-barang tersebut sangat mungkin dipasok oleh supplier yang berbeda-beda. Meskipun demikian, jika ada dua buah PB yang berisikan permintaan atas barang yang sama, permintaan ini tidak akan digabungkan dalam PO yang sama dikarena pada saat proses pengiriman barang, supplier akan mengirimkan barang langsung kepada Distribution Centre (DC) yang dituju tanpa melalui bagian merchandising. Akibatnya, sebuah PO hanya mungkin berasal dari sebuah PB saja. Selain mengirimkan PO kepada supplier, bagian merchandising juga akan mengirimkan salinan PO tersebut kepada DC yang bersangkutan. Hal ini dilakukan agar nantinya DC dapat mencocokkannya dengan barang-barang yang dikirim oleh supplier. 4. Setelah menerima purchase order (PO) dari bagian merchandising, supplier akan langsung menyiapkan dan mengirimkan barang yang diminta ke DC yang bersangkutan. Jika barang yang dipesan tersedia, maka supplier akan segera mengirimkannya ke DC yang dituju. Akan tetapi, apabila barang yang diminta tersebut tidak tersedia maka supplier akan menginformasikan hal ini kepada bagian merchandising dan barang yang tidak tersedia tersebut akan dipesan kembali pada PO yang akan dikirim selanjutnya. 5. Ketika barang-barang yang dikirim oleh supplier telah sampai di Distribution Centre (DC), maka DC akan mengeluarkan surat Bukti Terima

72 Barang (BTB) dan menyerahkannya kepada pihak supplier sebagai bukti bahwa barang telah diterima. Salinan dari surat BTB ini akan dikirimkan kepada bagian merchandising untuk kemudian dicatat.

Jumlah barang yang dipesan oleh DC dalam usulan order (UO) secara umum tidak akan sama dengan jumlah barang yang dipesan secara riil ke supplier melalui purchase order (PO). Perbedaan jumlah barang yang sesungguhnya dibutuhkan dan yang dipesan secara riil ini dikarenakan pemesanan barang oleh DC merupakan kumpulan dari permintaan-permintaan gerai-gerai yang biasanya dalam jumlah kecil sedangkan pemesanan barang yang dilakukan secara riil ke supplier biasanya dalam jumlah yang relatif lebih besar untuk menekan harga modal. Oleh sebab itu, pihak manajerial merasa perlu untuk mengetahui efektivitas dari pemesanan suatu jenis barang barang kepada supplier. Informasi mengenai efektivitas realisasi pemesanan ini dapat dilihat dari detail usulan order dan purchase order serta selisihnya sehingga pihak manajerial dapat mengetahui berapa besar persentase kelebihan barang pada setiap pemesanan yang dilakukan. Informasi ini nantinya akan ditampilkan dalam laporan purchase order sehingga laporan purchase order ini digunakan oleh pihak manajerial untuk memonitor atau mengawasi proses pembelian barang yang sesungguhnya terjadi. Namun pada saat ini, aplikasi yang digunakan untuk menghasilkan laporan ini mengalami masalah berupa lamanya waktu yang dibutuhkan oleh aplikasi ini untuk menghasilkan laporan. Jika aplikasi tersebut dijalankan untuk menghasilkan sebuah laporan, maka user harus menunggu sekitar 1 jam atau lebih sampai laporan tesebut keluar.

73 Penulis akan melakukan analisis pada data-data yang dikumpulkan, dari hasil survei dan wawancara yang telah dilakukan dengan pihak perusahaan, dari beberapa aspek untuk menemukan penyebab utama masalah performance pada aplikasi ditinjau dari sisi response time. Aspek-aspek yang akan dianalisis oleh penulis, dalam rangka menemukan faktor utama penyebab masalah performance, secara berturut-turut adalah sebagai berikut: 1. Aspek Data Model Penulis akan melakukan analisis pada tabel-tabel database yang digunakan terkait dengan aplikasi Reporting Purchase Order.

2. Aspek PL/SQL Code Penulis akan melakukan analisis pada PL/SQL code yang digunakan di aplikasi Reporting Purchase Order.

3. Aspek-aspek lainnya Penulis akan melakukan analisis pada informasi-informasi, yang tidak tergolong pada aspek data model dan aspek PL/SQL Code, yang diperoleh melalui hasil wawancara.

3.2.2

Tabel-tabel yang Dipakai untuk Reporting Purchase Order Jumlah tabel yang dipakai oleh sistem pembelian barang di PT. Indomarco

Prismatama sangatlah banyak sehingga penulis akan membatasi cakupan analisisnya hanya sebatas pada tabel-tabel yang berkaitan dengan aplikasi Reporting Purchase Order.

74 Dari data-data yang berhasil didapatkan, penulis menemukan bahwa data model atau tabel-tabel yang digunakan oleh sistem tidak sesuai dengan standar yang digunakan pada DBMS pada umumnya. Hal ini terlihat pada tidak didefinisikannya primary key (PK) dan foreign key (FK) pada tabel-tabel tersebut. Melalui proses wawancara lanjutan yang dilakukan oleh penulis kepada pihak PT. Indomarco Prismatama, penulis mengambil kesimpulan bahwa struktur tabel yang tanpa disertai PK dan FK ini sebagai akibat dari proses migrasi sistem yang terdahulu yakni DBASE. Akibatnya, dalam menjaga relasi antar tabelnya, sistem saat ini tidak melakukannya pada level database dengan PK-FK melainkan pada level implementasi yakni pada aplikasi yang digunakan. Meskipun demikian, penulis tetap merasa perlu untuk melakukan analisis primary key dan foreign key pada tabel-tabel tersebut karena dengan mengetahui primary key dan foreign key dari setiap tabel akan membantu pemahaman atas relasi yang ada pada data model sistem yang sedang berjalan. Field-field yang berhubungan dengan aplikasi reporting prurchase order pada tabel-tabel tersebut beserta hasil analisis primary key dan foreign key-nya masing-masing adalah sebagai berikut: 1. Tabel T_UNIT Primary Key: FTKODE Foreign Key: Keterangan: Tabel ini berisi data tentang unit perusahaan. Primary key tabel ini adalah FTKODE.

75 Field Keterangan Jenis FTKODE FTNAMA Kode unit Nama unit CHAR VARCHAR2 Tipe Data Ukuran 1 BYTE 30 BYTE

Tabel 3.1 Tabel T_UNIT

2. Tabel T_WILAYAH Primary Key: FTKODE Foreign Key: Keterangan: Tabel ini berisi data tentang wilayah-wilayah toko di perusahaan. Primary key tabel ini adalah FTKODE. Field Keterangan Jenis FTKODE FTNAMA Kode wilayah Nama wilayah VARCHAR2 VARCHAR2 Tipe Data Ukuran 3 BYTE 30 BYTE

Tabel 3.2 Tabel T_WILAYAH

3. Tabel T_CABANG Primary Key: FTKODE Foreign Key: FTKWIL, FTKSBU Keterangan: Tabel ini merupakan tabel yang berisi data tentang cabang perusahaan. Primary key tabel ini adalah FTKODE. Pada tabel ini, terdapat foreign key FTKWIL yang menghubungkan tabel T_CABANG dengan tabel

76 T_WILAYAH serta FTKSBU yang menghubungkan tabel T_CABANG dan T_UNIT. Field Keterangan Jenis FTKODE FTNAMA FTKWIL FTKSBU Kode cabang Nama cabang Kode wilayah Kode unit VARCHAR2 VARCHAR2 VARCHAR2 CHAR Tipe Data Ukuran 4 BYTE 30 BYTE 3 BYTE 1 BYTE

Tabel 3.3 Tabel T_CABANG

4. Tabel T_SUPPLIER Primary Key: FTKODE Foreign Key: Keterangan: Tabel ini berisi data-data tentang supplier. Primary key pada tabel ini adalah FTKODE. Field Keterangan Jenis FTKODE FTNAMA Kode supplier Nama supplier NUMBER VARCHAR2 Tipe Data Ukuran 5 50 BYTE

Tabel 3.4 Tabel T_SUPPLIER

5. Tabel T_DIVISI Primary Key: FTKODE Foreign Key: Keterangan:

77 Tabel ini merupakan tabel divisi pada perusahaan yang menangani suatu divisi produk. Primary key tabel ini adalah FTKODE. Field Keterangan Jenis FTKODE FTNAMA FTKMGR Kode divisi Nama divisi Kode manager VARCHAR2 VARCHAR2 VARCHAR2 Tipe Data Ukuran 2 BYTE 30 BYTE 15 BYTE

Tabel 3.5 Tabel T_DIVISI

6. Tabel T_DEPT Primary Key: FTKODE Foreign Key : FTKDIV Keterangan: Tabel ini merupakan tabel departemen produk pada perusahaan. Primary key pada tabel ini adalah FTKODE. Foreign key pada tabel ini adalah FTKDIV yang menghubungkan tabel ini dengan tabel T_DIVISI. Pada tabel ini, terlihat redudansi pada field FTKMGR yang merupakan kode manager divisi dan ada pada tabel T_DIVISI. Field Keterangan Jenis FTKODE FTNAMA FTKDIV FTKMGR FTKSPV Kode departemen Nama departemen Kode divisi Kode manager Kode supervisor VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 Tipe Data Ukuran 2 BYTE 30 BYTE 2 BYTE 15 BYTE 15 BYTE

Tabel 3.6 Tabel T_DEPT

78

7. Tabel M_PRODUK Primary Key: FMKODE Foreign Key: FMKDIV, FMKDEP Keterangan: Tabel ini merupakan tabel master produk yang dijual perusahaan. Primary key pada tabel ini adalah FMKODE. Foreign key pada tabel ini adalah FMKDIV yang menghubungkan tabel M_PRODUK dan T_DIVISI serta FMKDEP yang menghubungkan tabel M_PRODUK dan T_DEPT. Padahal, dengan FMKDEP saja, suatu produk dapat ditentukan divisi produknya karena pada tabel T_DEPT juga terdapat foreign key penghubung ke tabel T_DIVISI. Field Keterangan Jenis FMKODE FMMERK FMNAMA FMFLAV FMKMSN FMSIZE FMKDIV FMKDEP Kode produk Merek produk Nama produk Flavour produk Kemasan produk Ukuran produk Kode divisi Kode departemen NUMBER VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 Tipe Data Ukuran 8 15 BYTE 30 BYTE 15 BYTE 3 BYTE 10 BYTE 2 BYTE 2 BYTE

Tabel 3.7 Tabel M_PRODUK

79 8. Tabel DD_PRODUK Primary Key: FDKODE, FDKSBU Foreign Key: FDKODE, FDKSBU Keterangan: Tabel ini merupakan tabel detail produk. Primary key tabel ini adalah FDKODE dan FDKSBU yang juga merupakan foreign key penghubung tabel ini dengan tabel M_PRODUK dan T_UNIT. Field Keterangan Jenis FDKODE FDKSBU FDFCRS Kode produk Kode unit Flag cursor warehouse NUMBER CHAR VARCHAR2 Tipe Data Ukuran 8 1 BYTE 1 BYTE

Tabel 3.8 Tabel DD_PRODUK

9. Tabel M_PLU_KONV Primary Key: FMKSBU, FMKODE Foreign Key: FMKSBU, FMKODE Keterangan: Tabel ini merupakan tabel yang berisi konversi kode produk dari unit-unit perusahaan yang berbeda menjadi kode produk yang dipakai perusahaan. Primary key tabel ini adalah FMKSBU dan FMKODE yang juga merupakan foreign key penghubung tabel ini dengan tabel T_UNIT dan M_PRODUK.

80 Field Keterangan Jenis FMKSBU FMKODE FMKPLU Kode unit Kode produk Kode produk pada unit CHAR NUMBER VARCHAR2 Tipe Data Ukuran 1 BYTE 8 8 BYTE

Tabel 3.9 Tabel M_PLU_KONV

10. Tabel T_STATUS Primary Key: FTKODE Foreign Key: Keterangan: Tabel ini merupakan tabel status produk. Primary key tabel ini adalah FTKODE. Field Keterangan Jenis FTKODE FTNAMA FTFTBO Kode status Nama status Status produk boleh dipesan atau tidak Tabel 3.10 Tabel T_STATUS VARCHAR2 VARCHAR2 CHAR Tipe Data Ukuran 2 BYTE 30 BYTE 1 BYTE

11. Tabel D_REGION_PR Primary Key: FDKODE, FDKSBU, FDKWIL Foreign Key: FDKODE, FDKSBU, FDKWIL, FDKSTS Keterangan: Tabel ini berisi data tentang produk di wilayah yang ada. Primary key tabel ini adalah FDKODE, FDKSBU, dan FDKWIL yang sekaligus

81 merupakan field foreign key penghubung tabel ini dengan tabel M_PRODUK, T_UNIT, dan T_WILAYAH. Selain itu, terdapat foreign key FDKSTS yang merupakan penghubung tabel D_REGION_PR dan T_STATUS. Field Keterangan Jenis FDKODE FDKSBU FDKWIL FDKSTS FDKRTL Kode produk Kode unit Kode wilayah Kode status Kode retail NUMBER CHAR VARCHAR2 VARCHAR2 VARCHAR2 Tipe Data Ukuran 8 1 BYTE 3 BYTE 2 BYTE 1 BYTE

Tabel 3.11 Tabel D_REGION_PR

12. Tabel MH_POORD Primary Key : FHNOPO Foreign Key : FHKSBU, FHKWIL, FHKCAB, FHKSUP, FHNOUO Keterangan: Tabel ini berisi data-data umum tentang Purchase Order. Primary key tabel ini adalah FHNOPO yang merupakan nomor Purchase Order. Selain itu, pada tabel ini, juga terdapat foreign key FHKSBU yang menghubungkan tabel MH_POORD dan T_UNIT, FHKWIL yang menghubungkan tabel MH_POORD dengan tabel T_WILAYAH,

FHKCAB yang menghubungkan tabel MH_POORD dengan tabel T_CABANG, dan FHKSUP yang menghubungkan tabel MH_POORD dengan tabel T_SUPPLIER. Selain itu, terdapat pula FHNOUO yang

82 merupakan primary key pada MD_ORDER. Di sini, redudansi dapat dilihat dari field FHKSBU dan FHKWIL yang sebenarnya sudah ada pada tabel T_CABANG sehingga seharusnya nilai FHKCAB sudah dapat digunakan untuk mengetahui nilai FHKSBU dan FHKWIL. Field Keterangan Jenis FHNOPO FHTGPO FHKSBU FHKWIL FHKCAB FHNOPB FHTGPB FHTNIL FHTPPN FHTPPM FHTBTL FHKSUP FHNOUO Nomor PO Tanggal PO Kode unit Kode wilayah Kode cabang Nomor PB Tanggal PB Total nilai Total PPN Total PPNBM Total botol Kode supplier Nomor UO VARCHAR2 DATE CHAR VARCHAR2 VARCHAR2 VARCHAR2 DATE NUMBER NUMBER NUMBER NUMBER NUMBER VARCHAR2 Tipe Data Ukuran 9 BYTE 1 BYTE 3 BYTE 4 BYTE 9 BYTE 12, 2 12, 2 12, 2 12, 2 5 9 BYTE

Tabel 3.12 Tabel MH_POORD

13. Tabel MD_ORDER Primary Key: FDNOUO, FDKODE Foreign Key: FDNOPO, FDKODE, FDKSBU, FDKWIL, FDKCAB, FDKSUP.

83 Keterangan: Tabel ini berisi detail usulan order (UO). Primary key tabel ini adalah FDNOUO dan FDKODE. Kedua field ini juga merupakan foreign key penghubung tabel MH_POORD dan M_PRODUK. Selain itu ada pula foreign key FDKSBU yang menghubungkan tabel MD_ORDER dan T_UNIT, FDKWIL yang menghubungkan tabel MD_ORDER dengan tabel T_WILAYAH, FDKCAB yang menghubungkan tabel MD_ORDER dengan tabel T_CABANG, dan FDKSUP yang menghubungkan tabel MD_ORDER dengan tabel T_SUPPLIER. Dilihat dari foreign key ini, kita dapat melihat adanya redudansi karena pada tabel MH_POORD terdapat foreign key FDKSBU, FDKWIL, FDKCAB dan FDKSUP. Selain itu redudansi juga terlihat dari adanya field FDNOPB, FDTGPB dan FDTGPO yang terdapat pada tabel MH_POORD dan field FDKDIV yang terdapat pada tabel M_PRODUK. Field Keterangan Jenis FDNOUO FDKODE FDISIP FDSATB FDTGUO FDKSBU FDKWIL FDKCAB FDQTYB FDQTYF Nomor UO Kode produk Satuan isi Satuan barang Tanggal UO Kode unit Kode wilayah Kode cabang Jumlah barang Jumlah barang bonus VARCHAR2 NUMBER NUMBER VARCHAR2 DATE CHAR VARCHAR2 VARCHAR2 NUMBER NUMBER 1 BYTE 3 BYTE 4 BYTE 6 5 Tipe Data Ukuran 9 BYTE 8 6 3 BYTE

84 FDHSAT FDDISC FDTNIL FDTPPN FDTPPM FDTBTL FDKSUP FDNOPO FDTGPO FDNOPB FDTGPB FDKDIV FDRCID Harga satuan Diskon Total nilai Total PPN Total PPNBM Total botol Kode supplier Nomor PO Tanggal PO Nomor PB Tanggal PB Kode divisi Status delete NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER VARCHAR2 DATE VARCHAR2 DATE VARCHAR2 CHAR 12, 2 12, 2 12, 2 12, 2 12, 2 12, 2 5 9 BYTE 9 BYTE 2 BYTE 1 BYTE

Tabel 3.13 Tabel MD_ORDER

14. Tabel T_PO_TYPE Primary Key: FTNOPO Foreign Key: FTNOPO, FTKODE Keterangan: Tabel ini berisi data-data tentang jenis Purchase Order. Primary key tabel ini adalah FTNOPO yang sekaligus merupakan foreign key penghubung tabel T_PO_TYPE dan MH_POORD. Foreign key yang lain yaitu FTKODE merupakan penghubung tabel T_PO_TYPE dan M_PRODUK. Ada 2 jenis PO yang ada yaitu PO Seasonal yang merupakan jenis PO musiman (bukan PO rutin) dan GOD yang merupakan jenis PO yang mendapat Grand Opening Discount. Selain kedua jenis PO ini, ada PO rutin yang merupakan pemesanan barang rutin.

85 Field Keterangan Jenis FTNOPO FTKODE FTPOTP Nomor PO Kode produk Jenis PO VARCHAR2 NUMBER VARCHAR2 Tipe Data Ukuran 9 BYTE 8 100 BYTE

Tabel 3.14 Tabel T_PO_TYPE

15. Tabel MD_TSTOCK Primary Key: FDNOPO, FDKODE Foreign Key: FDNOPO, FDKODE, FDKSBU, FDKWIL, FDKCAB, FDKSUP Keterangan: Tabel ini berisi data realisasi produk yang dipesan melalui PO. Tidak semua produk yang dipesan pada PO bisa diperoleh, maka dari itu tabel ini akan mencatat realisasinya. Primary key pada tabel ini adalah FDNOPO dan FDKODE. Kedua field ini juga merupakan foreign key penghubung tabel MH_POORD dan M_PRODUK. Selain itu ada pula foreign key FDKSBU yang menghubungkan tabel MD_TSTOCK dan T_UNIT, FDKWIL yang menghubungkan tabel MD_TSTOCK dengan tabel T_WILAYAH, FDKCAB yang menghubungkan tabel MD_TSTOCK dengan tabel T_CABANG, dan FDKSUP yang menghubungkan tabel MD_TSTOCK dengan tabel T_SUPPLIER. Dilihat dari foreign key ini, kita dapat melihat adanya redudansi lagi karena pada tabel MH_POORD terdapat foreign key FDKSBU, FDKWIL, FDKCAB dan FDKSUP.

86 Field Keterangan Jenis FDNOPO FDKODE FDKSBU FDKWIL FDKCAB FDQTYR FDTNIL FDTPPN FDTPPM FDTBTL FDKSUP FDNBTB FDTBTB Nomor PO Kode produk Kode unit Kode wilayah Kode cabang Jumlah barang real Total nilai Total PPN Total PPM Total botol Kode supplier Nomor BTB Tanggal BTB VARCHAR2 NUMBER CHAR VARCHAR2 VARCHAR2 NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER VARCHAR2 DATE Tipe Data Ukuran 9 BYTE 8 1 BYTE 3 BYTE 4 BYTE 12 12, 2 12, 2 12, 2 5 9 BYTE -

Tabel 3.15 Tabel MD_TSTOCK

16. Tabel MD_GOD Primary Key: FDNOPO, FDKODE Foreign Key: FDNOPO, FDKODE, FDNOUO Keterangan: Tabel ini berisi data produk yang mendapatkan diskon Grand Opening. Primary key pada tabel ini adalah FDNOPO dan FDKODE yang juga merupakan foreign key penghubung dengan tabel MH_POORD dan M_PRODUK. Selain itu, ada pula FDNOUO yang merupakan primary key pada tabel MD_ORDER.

87 Field Keterangan Jenis FDNOPO FDKODE FDPDIS FDNILD FDNOUO Nomor PO Kode produk Potongan diskon Nilai diskon Nomor UO Tipe Data Ukuran

VARCHAR2 9 BYTE NUMBER NUMBER NUMBER 8 5, 2 12, 2

VARCHAR2 9 BYTE

Tabel 3.16 Tabel MD_GOD

17. Tabel T_LAP_REAL_PO_I_DETAIL Primary Key: FTNOPO, FTKODE, FTUSER Foreign Key: FTNOPO, FTKODE, FTKSBU, FTKWIL, FTKCAB, FTKSUP, FTKDIV, FTKDEP Keterangan: Tabel ini berisi detail realisasi PO. Tabel ini merupakan tabel yang isinya diambil dari isi tabel-tabel lain. Primary key tabel ini adalah FTNOPO, FTKODE dan FTUSER yang juga merupakan foreign key penghubung tabel MH_POORD dan M_PRODUK. Selain itu ada pula foreign key FTKSBU yang merupakan penghubung dengan tabel T_UNIT, FTKWIL yang merupakan penghubung dengan tabel T_WILAYAH, FTKCAB yang merupakan penghubung dengan tabel T_CABANG, FTKSUP yang merupakan penghubung dengan tabel T_SUPPLIER.

88 Field Keterangan Jenis FTNOPO FTKODE FTNAMA FTSATB FTKSBU FTKWIL FTKCAB FTQTYB FTTNIL FTQTYR FTNILR FTQTYS FTNILS FTNMDM FTKTAG FTKSUP FTTGPO FTKDIV FTKDEP FTTGUP FTUSER DISKON_GO Nomor PO Kode produk Nama produk Satuan barang Kode unit Kode wilayah Kode cabang Jumlah barang Total nilai Jumlah barang real Total nilai real Selisih jumlah barang Selisih total nilai Nama departemen Kode status barang Kode supplier Tanggal PO Kode divisi Kode departemen Tanggal update Kode user Diskon Grand Opening VARCHAR2 NUMBER VARCHAR2 VARCHAR2 CHAR VARCHAR2 VARCHAR2 NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER VARCHAR2 VARCHAR2 NUMBER DATE VARCHAR2 VARCHAR2 DATE VARCHAR2 NUMBER Tipe Data Ukuran 9 BYTE 8 100 BYTE 30 BYTE 1 BYTE 3 BYTE 4 BYTE 8 14, 4 8 14, 4 8 14, 4 15 2 5 2 BYTE 2 BYTE 15 BYTE -

Tabel 3.17 Tabel T_LAP_REAL_PO_I_DETAIL

89 18. TABEL T_TAG_LAP Primary Key: FTKODE, FTUSER Foreign Key: FTKODE Keterangan: Tabel ini merupakan tabel yang berisi kode status barang serta nama user. Primary key pada tabel ini adalah FTKODE dan FTUSER. Sedangkan foreign key pada tabel ini adalah FTKODE yang menghubungkan tabel T_TAG_LAP dengan tabel T_STATUS. Jika seorang user tidak terdaftar di sini, maka user tersebut dapat mengakses semua status barang yang ada. Field Keterangan Jenis FTKODE FTUSER Kode status barang Kode user VARCHAR2 VARCHAR2 Tipe Data Ukuran 2 BYTE 15 BYTE

Tabel 3.18 Tabel T_TAG_LAP

19. Tabel T_PLU_LAP Primary Key: FTKODE, FTUSER Foreign Key: FTKODE Keterangan: Tabel ini merupakan tabel sementara yang berisi kode barang dan nama user. Primary key pada tabel ini adalah FTKODE dan FTUSER. Sedangkan foreign key pada tabel ini adalah FTKODE yang menghubungkan tabel T_TAG_LAP dengan tabel M_PRODUK.

90 Field Keterangan Jenis FTKODE FTUSER Kode produk Kode user NUMBER VARCHAR2 Tipe Data Ukuran 8 15 BYTE

Tabel 3.19 Tabel T_PLU_LAP

Pada tabel-tabel di atas, ada beberapa index yang dibuat, yaitu sebagai berikut: Nama Tabel Nama Index Kolom-kolom yang di-index T_UNIT T_CABANG T_UNIT_FTKODE_PK T_CABANG_FTKODE_PK T_CABANG_IDX1 FTKODE FTKODE FTKODE, FTKSBU T_CABANG_IDX2 FTKSBU, FTKWIL T_SUPPLIER T_DIVISI T_DEPT M_PRODUK T_SUPPLIER_FTKODE_PK T_DIVISI_FTKODE_PK T_DEPT_FTKODE_PK DEP_IDX M_PRODUK_FMKODE_PK DIV_IDX DD_PRODUK DD_PRODUK_PK FTKODE FTKODE FTKODE FMKDEP FMKODE FMKDIV FDKODE, FDKSBU MH_POORD MH_POORD_PK MH_POORD_TGPO MH_POORD_SUPP MH_POORD_ORD_REAL FHNOPO FHTGPO FHKSUP FHTGPO, FHKSBU,

91 FHKSUP, FHKCAB, FHKWIL MD_ORDER MD_ORDER_PK FDNOUO, FDKODE MD_ORDER_IDX1 MD_ORDER_IDX2 MD_ORDER_IDX FDTGPB FDNOPB FDKSBU, FDKWIL, FDKCAB MD_ORDER_NOPO MD_ORDER_TGPO MD_ORDER_SUPP MD_ORDER_FDKODE MD_TSTOCK MD_TSTOCK_PK FDNOPO FDTGPO FDKSUP FDKODE FDNOPO, FDKODE MD_TSTOCK_CAB MD_TSTOCK_SBU MD_TSTOCK_SUPP FDKCAB FDKSBU FDKSUP

T_LAP_REAL_PO_I_DETAIL T_LAP_REAL_PO_I_DETAIL_PK FTNOPO, FTKODE, FTUSER T_TAG_LAP T_TAG_LAP_PK FTKODE, FTUSER T_PLU_LAP T_PLU_LAP_PK FTKODE, FTUSER Tabel 3.20 Tabel Index yang Digunakan

92 Relationship atau hubungan antar tabel-tabel di atas dapat dilihat pada tabel relationship berikut: Tabel T_UNIT Multiplicity Relationship 1..1 Memiliki cabang 1..1 Memiliki detail produk 1..1 Memiliki kode barang 1..1 Memiliki detail produk wilayah 1..1 Memiliki master purchase order 1..1 Memiliki detail usulan order 1..1 Memiliki detail purchase order 1..1 Memiliki realisasi order T_WILAYAH 1..1 Memiliki cabang 1..1 Memiliki detail produk D_REGION_PR 1..* T_CABANG 1..* T_LAP_REAL_PO_I_DETAIL 1..* MD_TSTOCK 1..* MD_ORDER 1..* MH_POORD 1..* D_REGION_PR 1..* M_PLU_KONV 1..* DD_PRODUK 1..* Tabel T_CABANG Multiplicity 1..*

93 wilayah 1..1 Memiliki master purchase order 1..1 Memiliki detail usulan order 1..1 Memiliki detail purchase order 1..1 Memiliki realisasi order T_CABANG 1..1 Memiliki master purchase order 1..1 Memiliki detail usulan order 1..1 Memiliki detail purchase order 1..1 Memiliki realisasi order T_SUPPLIER 1..1 Memiliki master MH_POORD 1..* T_LAP_REAL_PO_I_DETAIL 1..* MD_TSTOCK 1..* MD_ORDER 1..* MH_POORD 1..* T_LAP_REAL_PO_I_DETAIL 1..* MD_TSTOCK 1..* MD_ORDER 1..* MH_POORD 1..*

94 purchase order 1..1 Memiliki detail usulan order 1..1 Memiliki detail purchase order 1..1 Memiliki realisasi order T_DIVISI 1..1 Memiliki departemen 1..1 Memiliki master produk 1..1 Memiliki realisasi order T_DEPT 1..1 Memiliki master produk 1..1 Memiliki realisasi order M_PRODUK 1..1 Memiliki detail produk 1..1 Memiliki kode produk unit M_PLU_KONV 1..* DD_PRODUK 1..* T_LAP_REAL_PO_I_DETAIL 1..* M_PRODUK 1..* T_LAP_REAL_PO_I_DETAIL 1..* M_PRODUK 1..* T_DEPT 1..* T_LAP_REAL_PO_I_DETAIL 1..* MD_TSTOCK 1..* MD_ORDER 1..*

95 1..1 Memiliki detail produk wilayah 1..1 Memiliki detail usulan order 1..* Memiliki jenis PO 1..1 Memiliki detail purchase order 1..1 Memiliki diskon GO 1..1 Memiliki realisasi order 1..1 Memiliki akses user T_STATUS 1..1 Memiliki detail produk wilayah 1..1 Memiliki akses user MH_POORD 1..1 Memiliki detail usulan order 1..1 Memiliki jenis PO 1..1 Memiliki detail MD_TSTOCK 1..* T_PO_TYPE 1..1 MD_ORDER 1..* T_TAG_LAP 1..* D_REGION_PR 1..* T_PLU_LAP 1..* T_LAP_REAL_PO_I_DETAIL 1..* MD_GOD 1..* MD_TSTOCK 1..* T_PO_TYPE 1..1 MD_ORDER 1..* D_REGION_PR 1..*

96 purchase order 1..1 Memiliki diskon GO 1..1 Memiliki realisasi order MD_ORDER 1..1 Memiliki diskon GO Tabel 3.21 Tabel Relationship antar tabel MD_GOD 1..1 T_LAP_REAL_PO_I_DETAIL 1..* MD_GOD 1..*

3.2.3

Aplikasi Reporting Purchase Order Aplikasi Reporting Purchase Order digunakan untuk menghasilkan laporan

tentang realisasi dari purchase order. Laporan realisasi PO ini dibutuhkan untuk membandingkan usulan order dengan realisasi pemesanannya melalui purchase order. Realisasi pemesanan barang ini akan ditampilkan pada laporan purchase order yang berisikan daftar detail barang yang menjadi usulan order dan yang sudah dipesan pada purchase order serta selisihnya. Jadi laporan purchase order merupakan laporan yang digunakan untuk memonitor atau mengawasi proses pembelian barang yang sesungguhnya terjadi. Aplikasi Reporting Purchase Order ini dapat diakses dan digunakan oleh semua pengguna sistem untuk menghasilkan laporan PO kapan saja. Akan tetapi dari hasil wawancara yang telah dilakukan, penulis menemukan bahwa aplikasi ini digunakan secara periodik yakni hanya sekali setiap bulannya dan jumlah penggunanya kurang lebih hanya sepuluh user yang merupakan clerk pada bagian Technical Support. Masalah kelambatan pada aplikasi selalu dialami, bahkan

97 ketika aplikasi ini dijalankan pada waktu yang bukan peak time dan hanya ada satu user yang sedang menggunakan aplikasi ini meskipun user ini mengakses langsung dari kantor pusat. Tabel utama yang digunakan oleh aplikasi Reporting Purchase Order untuk menghasilkan laporan adalah tabel T_LAP_REAL_PO_I_DETAIL. Tabel ini berisikan data-data yang merupakan hasil summary dari beberapa tabel lainnya. Proses summary dari beberapa tabel lain dan memasukkannya ke dalam tabel T_LAP_REAL_PO_I_DETAIL dapat dilakukan dengan menjalankan procedure LAP_REAL_PO_I_OPU_DETAIL terlebih dahulu. Sebuah view bernama VU_LAP_REAL_PO_ITEM dibuat untuk membantu mengurangi kompleksitas query yang berisikan banyak proses join dari berbagai tabel, yakni MD_ORDER, D_REGION_PR, T_STATUS, M_PRODUK, dan T_PO_TYPE, yang kemudian akan digunakan oleh procedure

LAP_REAL_PO_I_OPU_DETAIL dalam proses pemasukan data ke dalam tabel T_LAP_REAL_PO_I_DETAIL.

98 Skema tabel pembentuk view VU_LAP_REAL_PO_ITEM adalah sebagai berikut:

D_REGION_PR T_PO_TYPE PK PK FTNOPO FTKODE FTPOTP VU_LAP_REAL_PO_ITEM FDNOUO FDKODE FDISIP FDSATB FDTGUO FDKSBU FDKWIL FDKCAB FDQTYB FDQTYF FDHSAT FDDISC FDTNIL FDTPPN FDTPPM FDTBTL FDKSUP FDNOPO FDTGPO FDNOPB FDTGPB FDKDIV FDRCID FMKDIV FMKDEP FMNAMA FDKSTS FTFTBO PO_TYPE PK PK PK FDKODE FDKSBU FDKWIL FDKSTS FDKRTL

MD_ORDER PK PK FDNOUO FDKODE FDISIP FDSATB FDTGUO FDKSBU FDKWIL FDKCAB FDQTYB FDQTYF FDHSAT FDDISC FDTNIL FDTPPN FDTPPM FDTBTL FDKSUP FDNOPO FDTGPO FDNOPB FDTGPB FDKDIV FDRCID

T_STATUS PK FTKODE FTNAMA FTFTBO

M_PRODUK PK FMKODE FMMERK FMNAMA FMFLAV FMKMSN FMSIZE FMKDIV FMKDEP

Gambar 3.3 Skema Tabel Pembentuk View VU_LAP_REAL_PO_ITEM

99 Sedangkan skema pembentukan tabel T_LAP_REAL_PO_I_DETAIL adalah sebagai berikut:

MD_GOD VU_LAP_REAL_PO_ITEM FDNOUO FDKODE FDISIP FDSATB FDTGUO FDKSBU FDKWIL FDKCAB FDQTYB FDQTYF FDHSAT FDDISC FDTNIL FDTPPN FDTPPM FDTBTL FDKSUP FDNOPO FDTGPO FDNOPB FDTGPB FDKDIV FDRCID FMKDIV FMKDEP FMNAMA FDKSTS FTFTBO PO_TYPE PK PK T_LAP_REAL_PO_I_DETAIL PK PK PK FTNOPO FTKODE FTUSER FTNAMA FTSATB FTKSBU FTKWIL FTKCAB FTQTYB FTTNIL FTQTYR FTNILR FTQTYS FTNILS FTNMDM FTKTAG FTKSUP FTTGPO FTKDIV FTKDEP FTTGUP DISKON_GO FDNOPO FDKODE FDPDIS FDNILD FDNOUO

T_DEPT PK FTKODE FTNAMA FTKDIV FTKMGR FTKSPV

MD_TSTOCK PK PK FDNOPO FDKODE FDKSBU FDKWIL FDKCAB FDQTYR FDTNIL FDTPPN FDTPPM FDTBTL FDKSUP FDNBTB FDTBTB

Gambar 3.4 Skema Pembentukan Tabel T_LAP_REAL_PO_I_DETAIL

100 Procedure LAP_REAL_PO_I_OPU_DETAIL yang digunakan dapat dilihat pada lampiran (L1 L14). Procedure ini akan meminta parameterparameter, yang harus diisi oleh user, yang nantinya akan digunakan sebagai parameter dalam memasukkan data ke dalam tabel. Parameter-parameter yang diminta pada procedure ini adalah sebagai berikut: 1. p_ksbu1 dan p_ksbu2 Parameter ini berisi kode unit perusahaan.

2. p_kwil Paramater ini berisi kode wilayah.

3. p_kcab1 dan p_kcab2 Parameter ini berisi kode cabang. Jika salah satu parameter ini berisi NULL, maka dipilihlah kode cabang yang paling kecil dan paling besar dari tabel t_cabang. Dengan demikian, laporan yang dihasilkan berasal dari semua cabang yang ada di suatu wilayah tertentu.

4. p_supp1 dan p_supp2 Parameter ini berisi kode supplier. Sama seperti parameter kode cabang (p_kcab1 dan p_kcab2), jika salah satu parameter ini berisi NULL, maka dipilihlah kode supplier yang paling kecil dan paling besar dari tabel t_supplier.

101 5. p_date1 dan p_date2 Parameter ini merupakan parameter jangka waktu PO yang diinginkan.

6. p_tag Parameter ini merupakan parameter status barang yang ingin dilihat. Ada dua jenis parameter ini yaitu A dan N. Parameter ini diisi A jika user ingin melihat pemesanan untuk barang yang aktif. Status barang tersebut disebut aktif jika field ftftbo pada tabel t_status tidak bernilai Y. Nilai Y pada field ftftbo berarti barang tersebut tidak boleh dipesan. Sebaliknya, jika nilai pada field ftftbo sama dengan NULL atau bernilai N, maka barang tersebut aktif dan bisa dipesan. Untuk itu, jika ingin melihat pemesanan barang yang dahulu bisa dipesan tetapi sekarang tidak bisa karena alasan-alasan tertentu maka parameter p_tag harus diisi N. Selain itu, jika user yang menjalankan procedure ini terdaftar di dalam tabel t_tag_lap yang merupakan tabel untuk membatasi akses user terhadap status barang tertentu, maka status barang tersebut juga harus dilihat, apakah dapat diakses oleh user tersebut atau tidak.

7. p_all Parameter ini bisa diisi Y atau N. Jika diisi Y, maka tidak perlu dilakukan pengaksesan pada t_plu_lap untuk melihat kode barang yang dapat diakses user tersebut. Jika diisi N, maka akan dilakukan pengaksesan pada t_plu_lap untuk melihat kode barang apa saja yang dapat diakses user tersebut.

102

8. p_usr Parameter ini merupakan parameter user yang berfungsi untuk menandai record yang dimasukkan oleh user tersebut. Hal ini dimaksudkan agar ketika aplikasi dijalankan untuk menghasilkan laporan, query yang dilakukan pada tabel T_LAP_REAL_PO_I_DETAIL hanya dilakukan pada record yang sesuai dengan parameter user yang diisikan. Jika user yang sama ingin menghasilkan laporan dengan parameter yang berbeda, misalnya kode wilayah yang berbeda dari laporan sebelumnya, maka user tersebut harus menjalankan procedure LAP_REAL_PO_I_OPU_DETAIL lagi. Procedure ini kemudian akan terlebih dahulu menghapus semua record yang dimiliki oleh user tersebut pada tabel

T_LAP_REAL_PO_I_DETAIL, kemudian baru memasukkan data baru yang diinginkan. User dapat melihat laporan baru ini dengan menjalankan aplikasi lagi.

9. p_warehouse Jika parameter ini diisi dengan nilai Y maka setiap barang pada unit tertentu akan dilihat kolom fdfcrs yang dimilikinya pada tabel dd_produk. Jika kolom fdfcrs berisi Y, maka barang tersebut dapat dimasukkan ke T_LAP_REAL_PO_I_DETAIL. Jika parameter diisi N atau NULL, maka pengaksesan tabel dd_produk tidak diperlukan.

103 10. p_retail Jika parameter ini diisi Y maka setiap barang pada unit dan wilayah tertentu akan dilihat kolom fdkrtl yang dimilikinya pada tabel d_region_pr. Jika kolom fdkrtl berisi Y, maka barang tersebut dapat dimasukkan ke T_LAP_REAL_PO_I_DETAIL. Jika parameter tidak diisi Y, maka pengaksesan tabel d_region_pr tidak diperlukan.

11. p_potype Parameter ini merupakan parameter jenis PO. Jika diisi A, maka jenis PO yang diinginkan adalah jenis PO biasa, bukan PO Seasonal atau GOD. Jika diisi B, maka jenis PO yang diinginkan adalah PO GOD dan jika diisi C maka jenis PO yang diinginkan adalah PO Seasonal.

Procedure LAP_REAL_PO_I_OPU_DETAIL juga menggunakan beberapa cursor yakni sebagai berikut: 1. Cursor cur1 Cursor ini mengakses data pada view VU_LAP_REAL_PO_ITEM dengan menggunakan parameter p_ksbu1, p_ksbu2, p_kwil, p_cab1, p_cab2, p_supp1, p_supp2, p_date1, dan p_date2. Cursor ini menghasilkan data tanpa memperhatikan user dan jenis PO.

104 2. Cursor cur2 Cursor ini mengakses data pada view VU_LAP_REAL_PO_ITEM dengan menggunakan parameter p_ksbu1, p_ksbu2, p_kwil, p_cab1, p_cab2, p_supp1, p_supp2, p_date1, dan p_date2. Cursor ini menghasilkan data tanpa memperhatikan jenis PO tetapi melakukan pengaksesan pada tabel t_plu_lap untuk melihat kode barang yang bisa diakses oleh user dengan menggunakan p_usr.

3. Cursor cur3 Cursor ini mengakses data pada view VU_LAP_REAL_PO_ITEM dengan menggunakan parameter p_ksbu1, p_ksbu2, p_kwil, p_cab1, p_cab2, p_supp1, p_supp2, p_date1, p_date2, dan p_potype. Cursor ini menghasilkan data tanpa memperhatikan user tetapi berdasarkan jenis PO tertentu.

4. Cursor cur4 Cursor ini mengakses data pada view VU_LAP_REAL_PO_ITEM dengan menggunakan parameter p_ksbu1, p_ksbu2, p_kwil, p_cab1, p_cab2, p_supp1, p_supp2, p_date1, p_date2, dan p_potype. Cursor ini menghasilkan data dengan berdasarkan pada jenis PO tertentu dan melakukan pengaksesan pada tabel t_plu_lap untuk melihat kode barang yang bisa diakses oleh user dengan menggunakan p_usr.

105 5. Cursor warehouse Cursor ini mengakses data pada tabel dd_produk untuk mengetahui apakah suatu barang terdaftar di sana sebagai barang warehouse.

6. Cursor retail Cursor ini mengakses data pada tabel d_region_pr untuk mengetahui apakah suatu barang terdaftar di sana sebagai barang retail.

Cara kerja dari procedure LAP_REAL_PO_I_OPU_DETAIL adalah dengan membuka salah satu cursor dari cur1, cur2, cur3 atau cur4 berdasarkan parameter p_all, dan p_potype dengan ketentuan-ketentuan berikut: 1. Jika p_all = Y dan p_potype =A, maka cursor yang diakses adalah cursor cur1. 2. Jika p_all = Y dan p_potype bernilai B atau C, maka cursor yang diakses adalah cursor cur3. 3. Jika p_all tidak bernilai Y dan p_potype =A, maka cursor yang diakses adalah cursor cur2. 4. Jika p_all tidak bernilai Y dan p_potype bernilai B atau C, maka cursor yang diakses adalah cursor cur4.

Akan dilakukan proses validasi pada setiap record yang diakses melalui cursor di atas sesuai parameter lain yang dimasukkan. Jika record tersebut lolos uji validasi, maka record tersebut akan dimasukkan ke tabel

T_LAP_REAL_PO_I_DETAIL. Proses validasi ini akan terus dijalankan hingga

106 record terakhir telah diakses cursor. Proses validasi yang dilakukan adalah sebagai berikut: 1. Jika p_tag =A, tetapi field ftftbo pada record bernilai Y, maka record ini tidak dimasukkan. 2. Jika p_tag =N, tetapi field ftftbo pada record bernilai NULL atau N, maka record ini tidak dimasukkan. 3. Jika p_usr ada pada tabel t_tag_lap, tetapi field fdksts pada record tidak sesuai dengan ftkode yang dimiki user pada tabel tersebut, maka record ini tidak dimasukkan. 4. Jika p_warehouse = Y, maka diakseslah cursor warehouse untuk menemukan kode barang dan kode unit pada record yang sama dengan kode barang dan kode unit pada tabel dd_produk yang mempunyai nilai fdfcrs = Y. Jika tidak ditemukan, maka record ini tidak dimasukkan. 5. Jika p_retail = Y, maka diakseslah cursor retail untuk menemukan kode barang, kode unit dan kode wilayah pada record yang sama dengan kode barang, kode unit dan kode wilayah pada tabel dd_produk yang mempunyai nilai fdkrtl = Y. Jika tidak ditemukan, maka record ini tidak dimasukkan.

Dari code procedure di atas, penulis menemukan adanya beberapa PL/SQL code yang tidak digunakan secara efisien. Penggalan PL/SQL code yang dimaksud adalah sebagai berikut: 1. Adanya proses delete terlebih dahulu untuk menghapus data pada tabel T_LAP_REAL_PO_I_DETAIL yang pernah dimasukkan user sebelumnya baru kemudian proses insert data yang baru dijalankan. Algoritma delete-

107 insert yang dipakai pada procedure ini sangatlah tidak efisien karena ketika user ingin menghasilkan sebuah laporan baru bahkan dengan hanya satu parameter yang berbeda, proses delete dan insert ini harus dijalankan kembali. Selain itu, jika ada beberapa user yang ingin menghasilkan laporan yang sesungguhnya sama, setiap user harus tetap menjalankan procedure ini masing-masing secara terpisah. Hal ini harus dilakukan karena pada saat akan menghasilkan laporan, parameter user yang bersangkutan harus diisi dan tabel T_LAP_REAL_PO_I_DETAIL hanya akan diakses berdasarkan user yang mengisi tabel ini melalui procedure. Hal ini tercermin pada penggalan PL/SQL code berikut: PROCEDURE LAP_REAL_PO_I_OPU_DETAIL(...) is ... BEGIN delete from T_LAP_REAL_PO_I_DETAIL where ftuser=p_usr; ... Loop ... if p_potype = 'B' then ... insert into T_LAP_REAL_PO_I_DETAIL(...) values(...); ... end if; if p_potype = 'A' or p_potype = 'C' then ... insert into T_LAP_REAL_PO_I_DETAIL(...) values(...); ... end if; ... End loop; ... End;

108 2. Adanya proses looping yang tidak tepat pada procedure tersebut. Contohnya seperti pada penggalan PL/SQL code berikut: v_qtyr:=0; v_nilr:=0; for x in(select nvl(fdqtyr,0) fdqtyr, nvl(fdtnil,0)+nvl(fdtppn,0)+ nvl(fdtppm,0)+nvl(fdtbtl,0) fdtnil from md_tstock where fdnopo=cur_rec.fdnopo and fdkode=cur_rec.fdkode) loop v_qtyr:=x.fdqtyr; v_nilr:=x.fdtnil; end loop;

Penggalan PL/SQL code di atas berfungsi untuk mencari nilai fdqtyr dan fdtnil yang tersimpan di tabel md_tstock di mana fdnopo dan fdkode di tabel md_tstock sama dengan fdnopo dan fdkode pada cursor yang diakses. Akan tetapi, proses looping di atas sesungguhnya tidak dibutuhkan karena suatu fdnopo dan fdkode pada cursor sudah pasti hanya mempunyai satu pasangan fdnopo dan fdkode pada tabel md_tstock.

Hal yang serupa juga terjadi pada penggalan PL/SQL code berikut: v_mdm:=null; for x in(select ftkmgr from t_dept where ftkode=cur_rec.fmkdep) loop v_mdm:=x.ftkmgr; end loop;

109 Penggalan code di atas berfungsi untuk mencari manager dari departemen produk yang sedang diakses cursor. Akan tetapi, proses looping tersebut tidak dibutuhkan karena manager suatu departemen hanya terdiri dari satu orang saja.

3. Adanya proses join yang kompleks pada procedure tersebut. Awalnya, proses join dilakukan pada saat pengaksesan view

VU_LAP_REAL_PO_ITEM. Setelah itu, untuk mengetahui nilai real atau diskon yang diberikan, proses join akan dilakukan lagi. Selain itu, untuk memeriksa apakah setiap record yang diakses akan dimasukkan ke tabel T_LAP_REAL_PO_I_DETAIL atau tidak, proses join ke tabel-tabel lain untuk proses validasi juga akan dilakukan. Setelah data dimasukkan pada tabel T_LAP_REAL_PO_I_DETAIL, proses join dilakukan lagi untuk menghasilkan laporan. Proses-proses join ini tentunya membutuhkan waktu yang tidak sedikit.

Setelah menjalankan procedure ini, maka user baru dapat menghasilkan laporan yang diinginkan. Dalam proses menghasilkan laporan, aplikasi ini tidak hanya mengakses tabel T_LAP_REAL_PO_I_DETAIL tetapi tabel-tabel lainnya seperti T_UNIT, T_SUPPLIER, T_CABANG, dan M_PLU_KONV juga akan diakses. Pada saat proses pembuatan laporan dijalankan, aplikasi ini akan meminta parameter user untuk dimasukkan oleh pengguna. Parameter ini akan digunakan sebagai filter ketika melakukan query pada tabel T_LAP_REAL_PO_I_DETAIL sehingga laporan yang dihasilkan sesuai dengan data yang sebelumnya telah

110 dimasukkan pada tabel T_LAP_REAL_PO_I_DETAIL oleh user tersebut dengan menggunakan procedure LAP_REAL_PO_I_OPU_DETAIL. Selain itu,

parameter-parameter lain seperti kode cabang, kode supplier, tanggal, dan lain-lain juga akan diminta untuk dicantumkan pada header laporan. Keseluruhan parameter yang diminta adalah sebagai berikut: 1. P Usr Parameter ini merupakan satu-satunya parameter yang akan digunakan dalam proses query pada aplikasi sedangkan parameter lain hanya akan digunakan untuk mengisi header laporan. Melalui parameter ini, user dapat melihat isi tabel T_LAP_REAL_PO_I_DETAIL yang data-datanya berasal dari hasil procedure LAP_REAL_PO_I_OPU_DETAIL yang telah dijalankan user tersebut.

2. P Sbu Parameter ini merupakan parameter unit perusahaan yang akan diisi pada header laporan dengan label SBU.

3. P Cab Parameter ini merupakan parameter cabang perusahaan yang akan diisi pada header laporan dengan label CABANG.

4. P Wil Parameter ini merupakan parameter wilayah perusahaan yang akan diisi pada header laporan dengan label WILAYAH.

111

5. P Tgl Parameter ini merupakan parameter tanggal yang akan diisi pada header laporan dengan label TGL.

6. P Supp Parameter ini merupakan parameter supplier perusahaan yang akan diisi pada header laporan dengan label SUPPLIER.

7. P Potype Parameter ini merupakan parameter jenis PO yang akan diisi pada header laporan dengan label PO TYPE.

8. P Wh Parameter ini merupakan parameter warehouse yang akan diisi pada header laporan dengan label WAREHOUSE.

9. P Ret Parameter ini merupakan parameter retail yang akan diisi pada header laporan dengan label RETAIL.

112 3.2.4 Spesifikasi Hardware dan Software Spesifikasi hardware dan software yang dipakai pada DBMS serta aplikasi Reporting Purchase Order perusahaan ini adalah sebagai berikut: Spesifikasi Prosesor Server RAM Server Hard Disk Server Operating System Server Database Report Builder Quad Core Processor 32GB 1 TB Red Hat Enterprise Linux x86-64 Oracle Database 10g R2 Oracle Developer Suite 10 g Tabel 3.22 Tabel spesifikasi sistem

3.3 Permasalahan yang Dihadapi Berdasarkan hasil wawancara dan survei yang telah dilakukan, masalah yang dihadapi PT. Indomarco Prismatama saat ini terletak pada salah satu aplikasi yang terkait dengan DBMS-nya yakni aplikasi Reporting Purchase Order. Aplikasi yang berfungsi untuk memonitor purchase order (PO) ini membutuhkan waktu yang relatif cukup lama, yakni sekitar 1 jam bahkan lebih, untuk menghasilkan sebuah laporan PO. Lamanya waktu yang dibutuhkan untuk menghasilkan laporan PO berdampak negatif berupa ketidakefisienan waktu yang terutama sering dialami oleh pihak-pihak manajerial yang sering kali terpaksa harus memundurkan jadwal rapat mereka, hanya demi menunggu aplikasi ini menghasilkan laporan PO yang mereka butuhkan untuk rapat, dan tidak jarang juga mereka terpaksa melaksanakan rapat bulanan tanpa laporan PO karena aplikasi report ini tidak mengeluarkan laporan PO nya tepat waktu.

113 Dari hasil wawancara, penulis menemukan bahwa masalah performance tetap terjadi baik pada waktu sibuk perusahaan ketika banyak user yang mengakses sistem maupun pada saat-saat senggang dimana tidak banyak user yang mengakses sistem seperti pada pagi hari dimana hanya seorang user saja yang menggunakan aplikasi tersebut. Selain itu, masalah performance ini juga tetap dirasakan baik oleh user yang mengakses dari kantor cabang yang jauh dari kantor pusat maupun user yang mengaksesnya secara langsung dari kantor pusat. Setelah menganalisis hasil wawancara tersebut, penulis mengambil beberapa kesimpulan sebagai berikut: 1. Aspek pengaturan pada Oracle Instance, seperti pembagian memory, tidak terindikasi kuat sebagai faktor utama penyebab masalah. Hal ini dikarenakan masalah kelambatan tetap terjadi setiap saat tanpa mempedulikan besar tidaknya load pada database. 2. Aspek networking yang menghubungkan client dengan server, tidak terindikasi kuat sebagai faktor utama penyebab masalah. Hal ini dikarenakan masalah kelambatan tetap terjadi baik pada user yang melakukan akses melalui client yang jauh dari server maupun pada user yang melakukan akses melalui client yang sangat dekat dengan server yakni di kantor pusat.

Setelah melakukan analisis dari beberapa aspek yang mungkin menjadi penyebab utama masalah kelambatan, penulis mengambil kesimpulan bahwa faktor utama penyebab kelambatan pada aplikasi ini terindikasi kuat terletak pada: 1. Data model yang kurang baik terindikasi dari banyaknya redudansi data dan operasi join yang kompleks.

114 2. PL/SQL code pada procedure pada aplikasi yang sangat tidak efisien terutama pada algoritmanya yang melakukan operasi delete dan insert setiap kali procedure dijalankan. Ketidak-efisienan juga terlihat dari banyaknya code yang tidak dibutuhkan. Hal ini terlihat dengan adanya beberapa penggunaan proses looping yang tidak perlu.

Dari hasil wawancara lebih lanjut, penulis menemukan bahwa kedua faktor penyebab masalah kelambatan aplikasi itu muncul dikarenakan database dan aplikasi sering mengalami perubahan atau penambahan modul, tanpa melalui tahapan analisis dan perancangan yang mendalam telebih dahulu, untuk memenuhi permintaan user.

3.4 Usulan Solusi Pemecahan Masalah Berdasarkan permasalahan yang dihadapi PT. Indomarco Prismatama pada aplikasi Reporting Purchase Order, maka usulan solusi pemecahan atas masalah yang diajukan adalah dengan melakukan reactive performance tuning untuk response time pada data model dan PL/SQL code yang digunakan pada aplikasi Reporting Purchase Order. Dengan melakukan tuning pada komponen-komponen yang berkaitan dengan aplikasi tersebut, performance dari sisi response time aplikasi Reporting Purchase Order diharapkan dapat lebih baik sehingga aplikasi tersebut mampu menghasilkan laporannya dengan lebih cepat.

115 3.5 Perancangan 3.5.1 Restrukturisasi Procedure dengan Penggunaan Materialized View Berdasarkan hasil analisis pada procedure, dapat dilihat bahwa tabel T_LAP_REAL_PO_I_DETAIL tidak digunakan secara efisien. Setiap kali ingin menghasilkan laporan, user harus menjalankan procedure untuk menghapus semua data sebelumnya dan memasukkan kembali data baru pada tabel ini, baru kemudian aplikasi Reporting Purchase Order dijalankan untuk melakukan query pada tabel ini dan tabel penyusun laporan lainnya. Dengan demikian proses yang terjadi jika disederhanakan terdiri dari delete, insert dan select. Proses delete-insert yang harus selalu dilakukan setiap aplikasi dijalankan tentunya memakan waktu dan sangat tidak efisien, maka untuk mengatasinya penulis akan menghilangkan proses delete dan insert tersebut dengan merancang sebuah procedure baru. Procedure baru ini hanya akan melakukan proses select pada sebuah materialized view MV_LAP_REAL_PO_I_DETAIL yang akan digunakan sebagai pengganti tabel T_LAP_REAL_PO_I_DETAIL. Dengan menggunakan materialized view yang up to date, user tidak perlu lagi menjalankan proses delete dan insert pada procedure LAP_REAL_PO_I_OPU_DETAIL. Selain itu, materialized view ini juga sudah memuat data hasil join beberapa tabel sehingga penggunaan operasi join yang kompleks tidak perlu dilakukan lagi. Hal ini sangat kontras sekali jika dibandingkan dengan procedure lama yang menggunakan view VU_LAP_REAL_PO_ITEM. Pada view tersebut, operasi join yang kompleks tetap dilakukan karena view harus tetap mengakses tabel asli. View hanya mengurangi kompleksitas code pada procedure tetapi sama sekali tidak meningkatkan performance. Penghapusan proses delete dan insert yang tidak

116 efisien serta operasi join yang kompleks dengan menggunakan procedure baru yang memanfaatkan materialized view MV_LAP_REAL_PO_I_DETAIL

diharapkan dapat meningkatkan response time aplikasi. Materialized view ini memuat data yang sebagian besar sama dengan data yang disimpan pada tabel T_LAP_REAL_PO_I_DETAIL. Akan tetapi, pada materialized view dilakukan pemangkasan beberapa kolom yang tidak digunakan di dalam procedure LAP_REAL_PO_I_OPU_DETAIL dan penambahan beberapa kolom baru guna mengurangi proses pengaksesan tabel lain yang berguna dalam proses validasi parameter. Kolom-kolom yang dihilangkan pada materialized view adalah sebagai berikut: 1. FTKDIV dan FTKDEP Kedua kolom di atas dihilangkan karena dalam proses pemasukan data pada tabel T_LAP_REAL_PO_I_DETAIL, kolom-kolom di atas tidak dimasukkan nilai sama sekali. Dalam laporan pun, nilai keempat kolom ini tidak diakses.

2. FTTGUP dan FTUSER Kolom FTUSER yang awalnya berguna untuk menandai record T_LAP_REAL_PO_I_DETAIL sebagai record hasil procedure

LAP_REAL_PO_I_OPU_DETAIL oleh user tersebut tentunya tidak lagi diperlukan pada materialized view. Demikian juga dengan FTTGUP yang merupakan tanggal dilakukannya proses pemasukan data tersebut.

117 Kolom-kolom yang ditambahkan pada materialized view adalah sebagai berikut: 1. FTFCRS Kolom ini merupakan kolom yang terdapat pada tabel dd_produk dan digunakan jika parameter p_warehouse pada procedure

LAP_REAL_PO_I_OPU_DETAIL diisi Y. Untuk mengurangi operasi join pada procedure baru, maka kolom ini pun dimasukkan pada materialized view.

2. FTKRTL Kolom ini merupakan kolom yang terdapat pada tabel d_region_pr dan digunakan jika parameter p_retail pada procedure

LAP_REAL_PO_I_OPU_DETAIL diisi Y. Penambahan kolom ini tidak menambah tabel yang harus di-join-kan karena tabel d_region_pr sudah merupakan tabel dasar penyusun T_LAP_REAL_PO_I_DETAIL.

3. FTFTBO Kolom ini terdapat pada tabel t_status dan berhubungan dengan nilai parameter p_tag pada procedure LAP_REAL_PO_I_OPU_DETAIL. Kolom ini sudah terdapat pada view VU_LAP_REAL_PO_ITEM pembentuk tabel T_LAP_REAL_PO_I_DETAIL.

118 4. PO_TYPE Kolom ini terdapat pada tabel t_po_type dan berhubungan dengan nilai parameter p_potype pada procedure LAP_REAL_PO_I_OPU_DETAIL. Kolom ini juga sudah terdapat pada view VU_LAP_REAL_PO_ITEM pembentuk tabel T_LAP_REAL_PO_I_DETAIL.

5. FTNSBU Kolom ini merupakan kolom nama unit yang berasal dari tabel T_UNIT. Data kolom ini dimasukkan pada pada materialized saat view

MV_LAP_REAL_PO_I_DETAIL

sehingga

menghasilkan

laporan, materialized view MV_LAP_REAL_PO_I_DETAIL tidak perlu di-join dengan tabel T_UNIT.

6. FTNCAB Kolom ini merupakan kolom nama cabang yang berasal dari tabel T_CABANG. Data kolom ini dimasukkan pada materialized view MV_LAP_REAL_PO_I_DETAIL sehingga pada saat menghasilkan

laporan, materialized view MV_LAP_REAL_PO_I_DETAIL tidak perlu di-join dengan tabel T_CABANG.

119 7. FTNSUP Kolom ini merupakan kolom nama supplier yang berasal dari tabel T_SUPPLIER. Data kolom ini dimasukkan pada materialized view MV_LAP_REAL_PO_I_DETAIL sehingga pada saat menghasilkan

laporan, materialized view MV_LAP_REAL_PO_I_DETAIL tidak perlu di-join dengan tabel T_SUPPLIER.

8. FTKPLU Kolom ini merupakan kolom kode barang pada unit yang berasal dari tabel M_PLU_KONV. Data kolom ini dimasukkan pada materialized view MV_LAP_REAL_PO_I_DETAIL sehingga pada saat menghasilkan

laporan, materialized view MV_LAP_REAL_PO_I_DETAIL tidak perlu di-join dengan tabel M_PLU_KONV.

9. ID_M_PRODUK, ID_T_DEPT, ID_D_REGION_PR, ID_DD_PRODUK, ID_MD_ORDER, ID_MD_TSTOCK, ID_MD_GOD, ID_T_PO_TYPE, ID_T_STATUS, ID_T_UNIT, ID_T_SUPPLIER, ID_T_CABANG,

ID_M_PLU_KONV Kolom-kolom tersebut merupakan kolom-kolom yang berisi ROWID pada tabel-tabel penyusun materialized view

MV_LAP_REAL_PO_I_DETAIL sehingga proses refresh fast dapat dilakukan.

120 Perbandingan struktur tabel pada T_LAP_REAL_PO_I_DETAIL dengan

materialized view MV_LAP_REAL_PO_I_DETAIL adalah sebagai berikut:

T_LAP_REAL_PO_I_DETAIL PK PK PK FTNOPO FTKODE FTUSER FTNAMA FTSATB FTKSBU FTKWIL FTKCAB FTQTYB FTTNIL FTQTYR FTNILR FTQTYS FTNILS FTNMDM FTKTAG FTKSUP FTTGPO FTKDIV FTKDEP FTTGUP DISKON_GO MV_LAP_REAL_PO_I_DETAIL FTNOPO FTKODE FTNAMA FTSATB FTKSBU FTKWIL FTKCAB FTQTYB FTTNIL FTQTYR FTNILR FTQTYS FTNILS FTNMDM FTKTAG FTKSUP FTTGPO DISKON_GO FTFCRS FTKRTL FTFTBO PO_TYPE FTNSBU FTNCAB FTNSUP FTKPLU ID_M_PRODUK ID_D_REGION_PR ID_MD_TSTOCK ID_MD_ORDER ID_DD_PRODUK ID_MD_GOD ID_T_DEPT ID_T_STATUS ID_T_PO_TYPE ID_T_UNIT ID_T_SUPPLIER ID_M_PLU_KONV ID_T_CABANG

Gambar 3.5 Perbandingan Tabel T_LAP_REAL_PO_I_DETAIL dan Materialized View MV_LAP_REAL_PO_I_DETAIL

121 Skema tabel dasar pembentuk materialized vied MV_LAP_REAL_PO_I_DETAIL adalah sebagai berikut:

Gambar 3.6 Skema Pembentukan Materialized View MV_LAP_REAL_PO_I_DETAIL

122

Hal yang harus diperhatikan sebelum membuat materialized view MV_LAP_REAL_PO_I_DETAIL adalah pembuatan materialized view log pada tabel-tabel dasar penyusun materialized view ini. Materialized view log ini dibutuhkan agar proses refresh dengan metode fast bisa digunakan pada materialized view. Materialized view log akan mencatat record yang mengalami perubahan pada tabel dasar sehingga ketika refresh dijalankan hanya recordrecord yang mengalami perubahan yang ikut di-update pada materialized view. Syarat pembuatan materialized view log pada sebuah tabel adalah tabel tersebut harus memiliki constraint primary key yang didefinisikan pada tabel tersebut. Oleh sebab itu, penambahan constraint primary key pada tabel-tabel dasar penyusun materialized view MV_LAP_REAL_PO_I_DETAIL perlu dilakukan. Selain penambahan constraint primary key, pengecekan constraint juga perlu dilakukan pada tabel -tabel tersebut mengingat tabel-tabel tersebut tidak memiliki primary key sebelumnya. Selain itu, agar proses refresh fast dapat dilakukan, maka pada materialized view harus disimpan ROWID dari setiap tabel penyusun materialized view. Struktur dan isi procedure baru yang menggunakan materialized view MV_LAP_REAL_PO_I_DETAIL tentu saja berbeda dengan procedure

sebelumnya. Pada procedure yang lama, dilakukan proses insert atau pemasukan record, dari view VU_LAP_REAL_PO_ITEM dan tabel-tabel lainnya seperti MD_TSTOCK, MD_GOD dan T_PO_TYPE, sesuai parameter-parameter yang diberikan pada tabel T_LAP_REAL_PO_I_DETAIL. Pada procedure baru, akan dibuat sebuah SQL statement untuk mengakses record berdasarkan parameter-

123 parameter tersebut. Pedoman yang digunakan penulis ketika melakukan pembuatan procedure yang baru adalah procedure yang baru harus memiliki fungsionalitas dan efektivitas yang sama dengan procedure yang lama. Perbedaan PL/SQL code antara procedure lama dan procedure baru adalah sebagai berikut: 1. SQL statement pada procedure lama yang pasti dijalankan apapun parameter yang diberikan adalah sebagai berikut: select * from VU_LAP_REAL_PO_ITEM where fdksbu between p_ksbu1 and p_ksbu2 and fdkwil=p_kwil and trim(fdkcab) between trim(p_cab1) and trim(p_cab2) and fdksup between p_sup1 and p_sup2 and trunc(fdtgpo) between trunc(p_date1) and trunc(p_date2); Di procedure baru hal ini diganti menjadi: select FTNOPO, FTKODE, FTNAMA, FTSATB, FTKSBU, FTKWIL, FTKCAB, FTQTYB, FTTNIL, FTQTYR, FTNILR, FTQTYS, FTNILS, FTNMDM, FTKTAG, FTKSUP, FTTGPO, FTKDIV, FTKDEP, FTKATB, FTTGUP, FTUSER, FTNCAB, FTNSBU, FTNSUP, FTKPLU, DISKON_GO from MV_LAP_REAL_PO_I_DETAIL where fdksbu between p_ksbu1 and p_ksbu2 and fdkwil=p_kwil and fdkcab between p_cab1 and p_cab2 and fdksup between p_sup1 and p_sup2 and fdtgpo between p_date1 and trunk p_date2;

124 2. Jika p_all = Y dan p_potype =A, maka pada procedure lama, record yang dimasukkan berasal dari SQL statement berikut: select * from VU_LAP_REAL_PO_ITEM where fdksbu between p_ksbu1 and p_ksbu2 and fdkwil=p_kwil and trim(fdkcab) between trim(p_cab1)and trim(p_cab2)and fdksup between p_sup1 and p_sup2 and trunc(fdtgpo) between trunc(p_date1) and trunc(p_date2);

Sedangkan pada procedure baru, dilakukan proses select berikut: select FTNOPO, FTKODE, FTNAMA, FTSATB, FTKSBU, FTKWIL, FTKCAB, FTQTYB, FTTNIL, FTQTYR, FTNILR, FTQTYS, FTNILS, FTNMDM, FTKTAG, FTKSUP, FTTGPO, FTKDIV, FTKDEP, FTKATB, FTTGUP, FTUSER, FTNCAB, FTNSBU, FTNSUP, FTKPLU, DISKON_GO from MV_LAP_REAL_PO_I_DETAIL where fdksbu between p_ksbu1 and p_ksbu2 and fdkwil=p_kwil and fdkcab between p_cab1 and p_cab2 and fdksup between p_sup1 and p_sup2 and fdtgpo between p_date1 and trunk p_date2;

125 3. Jika p_all = Y dan p_potype tidak bernilai A, maka pada procedure lama, record yang dimasukkan pada procedure lama berasal dari SQL statement berikut: select * from VU_LAP_REAL_PO_ITEM where fdksbu between p_ksbu1 and p_ksbu2 and fdkwil=p_kwil and trim(fdkcab) between trim(p_cab1)and trim(p_cab2)and fdksup between p_sup1 and p_sup2 and trunc(fdtgpo) between trunc(p_date1) and trunc(p_date2) and po_type = p_tipepo;

Sedangkan pada procedure baru, dilakukan proses select berikut: select FTNOPO, FTKODE, FTNAMA, FTSATB, FTKSBU, FTKWIL, FTKCAB, FTQTYB, FTTNIL, FTQTYR, FTNILR, FTQTYS, FTNILS, FTNMDM, FTKTAG, FTKSUP, FTTGPO, FTKDIV, FTKDEP, FTKATB, FTTGUP, FTUSER, FTNCAB, FTNSBU, FTNSUP, FTKPLU, DISKON_GO from MV_LAP_REAL_PO_I_DETAIL where fdksbu between p_ksbu1 and p_ksbu2 and fdkwil=p_kwil and fdkcab between p_cab1 and p_cab2 and fdksup between p_sup1 and p_sup2 and fdtgpo between p_date1 and trunk p_date2 and po_type = p_tipepo;

126 4. Jika p_all tidak benilai Y dan p_potype = A, maka pada procedure lama, record yang dimasukkan berasal dari SQL statement berikut: select * from VU_LAP_REAL_PO_ITEM where fdksbu between p_ksbu1 and p_ksbu2 and fdkwil=p_kwil and trim(fdkcab) between trim(p_cab1)and trim(p_cab2)and fdksup between p_sup1 and p_sup2 and trunc(fdtgpo) between trunc(p_date1) and trunc(p_date2) fdkode in(select ftkode from t_plu_lap where ftuser=p_usr); Sedangkan pada procedure baru, dilakukan proses select berikut: select FTNOPO, FTKODE, FTNAMA, FTSATB, FTKSBU, FTKWIL, FTKCAB, FTQTYB, FTTNIL, FTQTYR, FTNILR, FTQTYS, FTNILS, FTNMDM, FTKTAG, FTKSUP, FTTGPO, FTKDIV, FTKDEP, FTKATB, FTTGUP, FTUSER, FTNCAB, FTNSBU, FTNSUP, FTKPLU, DISKON_GO from MV_LAP_REAL_PO_I_DETAIL where fdksbu between p_ksbu1 and p_ksbu2 and fdkwil=p_kwil and fdkcab between p_cab1 and p_cab2 and fdksup between p_sup1 and p_sup2 and fdtgpo between p_date1 and trunk p_date2 fdkode in(select ftkode from t_plu_lap where ftuser=p_usr);

127 5. Jika p_all tidak benilai Y dan p_potype tidak bernilai A, maka pada procedure lama, record yang dimasukkan berasal dari SQL statement berikut: select * from VU_LAP_REAL_PO_ITEM where fdksbu between p_ksbu1 and p_ksbu2 and fdkwil=p_kwil and trim(fdkcab) between trim(p_cab1)and trim(p_cab2)and fdksup between p_sup1 and p_sup2 and trunc(fdtgpo) between trunc(p_date1) and trunc(p_date2) and po_type = p_tipepo and fdkode in(select ftkode from t_plu_lap where ftuser=p_usr); Sedangkan pada procedure baru, dilakukan proses select berikut: select FTNOPO, FTKODE, FTNAMA, FTSATB, FTKSBU, FTKWIL, FTKCAB, FTQTYB, FTTNIL, FTQTYR, FTNILR, FTQTYS, FTNILS, FTNMDM, FTKTAG, FTKSUP, FTTGPO, FTKDIV, FTKDEP, FTKATB, FTTGUP, FTUSER, FTNCAB, FTNSBU, FTNSUP, FTKPLU, DISKON_GO from MV_LAP_REAL_PO_I_DETAIL where fdksbu between p_ksbu1 and p_ksbu2 and fdkwil=p_kwil and fdkcab between p_cab1 and p_cab2 and fdksup between p_sup1 and p_sup2 and fdtgpo between p_date1 and trunk p_date2; and po_type = p_tipepo and fdkode in(select ftkode from t_plu_lap where ftuser=p_usr);

SQL statement pada proses select di materialized view selanjutnya akan menggunakan SQL statement berdasarkan p_all dan p_potype di atas, ditambah dengan conditional clause pada WHERE clause untuk proses validasinya.

128

6. Pada procedure lama, validasi p_tag dilakukan dengan SQL statement berikut: v_tru:=true; if p_tag='A' then if cur_rec.ftftbo='Y' then v_tru:=false; end if; elsif p_tag='N' then if cur_rec.ftftbo is null or cur_rec.ftftbo='N' then v_tru:=false; end if; end if; Sedangkan pada procedure baru, validasi ini dilakukan dengan menambahkan conditional clause berikut pada WHERE clause di SQL statement yakni sebagai berikut: a. Jika p_tag =A, maka tambahkan: AND FTFTBO != Y b. Jika p_tag =N, maka tambahkan: AND FTFTBO = Y

129 7. Pada procedure lama, jika p_usr terdapat pada tabel t_tag_lap, maka akan dilakukan validasi berikut untuk mengecek apakah kode status barang record yang ingin dimasukkan ke tabel T_LAP_REAL_PO_I_DETAIL saat itu sama dengan kode status yang dapat dimiliki user tersebut pada tabel t_tag_lap. Proses validasi yang dilakukan adalah sebagai berikut: if v_tru and v_tag then select count(ftkode) into v_count from t_tag_lap where ftkode=cur_rec.fdksts and ftuser=p_usr; if v_count=0 then v_tru:=false; end if; end if;

Sedangkan pada procedure yang baru, validasi dilakukan dengan menambahkan conditional clause berikut pada WHERE clause di SQL statement berikut: AND ftktag in(select ftkode from t_tag_lap where ftuser=p_usr)

130 8. Pada procedure lama, validasi untuk p_warehouse dan p_retail dilakukan dengan validasi berikut: v_warehouse := false; if nvl(p_warehouse,'N') = 'Y' then open warehouse(cur_rec.fdkode,cur_rec.fdksbu); fetch warehouse into v_temp; if warehouse%found then v_warehouse := true; end if; close warehouse; else v_warehouse := true; end if;

v_retail := false; if p_retail = 'Y' then open retail(cur_rec.fdkode,cur_rec.fdksbu,cur_rec.fdkwil); fetch retail into v_temp; if retail%found then v_retail := true; end if; close retail; else v_retail := true; end if;

131 Cursor warehouse dan cursor retail yang digunakan didefinisikan sebagai berikut: cursor warehouse(p_plu number,p_opu varchar2)is select 1 from dd_produk where fdkode = p_plu and fdksbu = p_opu and fdfcrs = 'Y'; cursor retail (p_plu1 number,p_opu1 varchar2,p_reg1 varchar2)is select 1 from d_region_pr where fdkode = p_plu1 and fdksbu = p_opu1 and fdkwil = p_reg1 and fdkrtl = 'Y';

Sedangkan pada procedure yang baru, validasi ini dilakukan dengan menambahkan condition clause berikut pada WHERE clause di SQL statement berikut: a. Jika p_warehouse=Y maka tambahkan AND FTFCRS = Y b. Jika p_retail =Y maka tambahkan AND FTKRTL = Y

Dengan melakukan perubahan-perubahan di atas, maka procedure baru akan tetap memiliki fungsionalitas dan efektivitas yang sama dengan procedure lama dalam menghasilkan data.

132 3.5.2 Normalisasi dan Denormalisai Normalisasi dan denormalisasi, yang merupakan salah satu teknik pada data model tuning, dapat dilakukan sebagai salah satu cara untuk meningkatkan performance. Hasil analisis pada tabel-tabel yang sebelumnya telah dilakukan menunjukan bahwa memang terdapat banyak redudansi data yang tidak perlu pada tabel-tabel tersebut. Akan tetapi, melakukan proses normalisasi dan denormalisasi pada struktur database perusahaan sangat tidak practical. Dikatakan tidak practical, karena struktur tabel yang dipakai perusahaan ini tidak hanya digunakan oleh aplikasi Reporting Purchase order tetapi juga dipakai oleh aplikasi penting perusahaan lainnya sehingga jika proses normalisasi dan denormalisasi diimplementasikan akan menyebabkan perombakan total juga terhadap sekian banyak aplikasi penting tersebut. Hal ini tidak sesuai dengan salah satu kriteria metodologi tuning yang baik menurut Milsap (2003, Chapter 1.2) yaitu practicality yang berarti metodologi harus dapat dipakai pada keadaan apapun, dalam berbagai lingkungan.

3.5.3

Pemberian Index Penggunaan index yang tepat, sesuai dengan yang tertulis pada landasan

teori, secara umum dapat meningkatkan waktu pencarian data dalam suatu tabel. Pada perancangan ini, data yang akan diberi index adalah kolom yang sering digunakan dalam operasi where dan join. Index tidak diberikan lagi pada kolomkolom primary key karena primary key sendiri sudah merupakan index. Pemberian index juga akan dilakukan pada materialized view

133 MV_LAP_REAL_PO_I_DETAIL serta tabel-tabel lain yang digunakan pada procedure baru. Pengaksesan materialized view pada procedure baru, dengan WHERE clause yang ditentukan dari parameter-parameter pada saat menjalankan procedure, akan menggunakan sejumlah kolom yang tidak sedikit. Namun ada beberapa kolom yang akan selalu digunakan seperti ftksbu, ftkwil, ftkcab, ftksup, fttgpo, dan ftftbo. Kolom ftftbo nantinya akan dicek berdasarkan parameter p_tag yang diberikan. Berikut SQL statement yang pasti digunakan: select FTNOPO, FTKODE, FTNAMA, FTSATB, FTKSBU, FTKWIL, FTKCAB, FTQTYB, FTTNIL, FTQTYR, FTNILR, FTQTYS, FTNILS, FTNMDM, FTKTAG, FTKSUP, FTTGPO, FTKDIV, FTKDEP, FTKATB, FTTGUP, FTUSER, FTNCAB, FTNSBU, FTNSUP, FTKPLU, DISKON_GO from MV_LAP_REAL_PO_I_DETAIL where fdksbu between p_ksbu1 and p_ksbu2 and fdkwil=p_kwil and fdkcab between p_cab1 and p_cab2 and fdksup between p_sup1 and p_sup2 and fdtgpo between p_date1 and trunk p_date2; AND ftftbo ;

Selain kolom-kolom di atas, kolom-kolom lain yang akan diakses, berdasarkan parameter yang ada, pada WHERE clause adalah sebagai berikut:

134 1. po_type Kolom ini diakses jika parameter p_potype diisi B atau C

2. ftkode Kolom ini diakses jika parameter p_all diisi N

3. ftfcrs Kolom ini diakses jika parameter p_warehouse diisi Y

4. ftkrtl Kolom ini diakses jika parameter p_retail diisi Y

5. ftktag Kolom ini diakses jika parameter p_usr berada pada tabel t_tag_lap

Sehingga jika disimpulkan, kolom-kolom yang digunakan dalam WHERE clause dan merupakan kolom yang akan diberi index pada materialized view MV_LAP_REAL_PO_I_DETAIL adalah sebagai berikut: 1. FTKSBU 2. FTKWIL 3. FTKCAB 4. FTKSUP 5. FTTGPO 6. PO_TYPE

135 7. FTKODE 8. FTKTAG 9. FTFCRS 10. FTKRTL 11. FTFTBO

Karena kolom-kolom ini memiliki cardinality yang rendah, maka index yang akan dibuat pada kolom-kolom ini adalah bitmap index.

3.5.4

Partitioning Tabel yang berukuran besar dapat dipartisi menjadi bagian-bagian yang

lebih kecil untuk mempercepat pembacaan tabel. Sebuah materialized view seperti tabel juga dapat dipartisi menjadi bagian-bagian yang lebih kecil berdasarkan field tertentu. Materialized view MV_LAP_REAL_PO_I_DETAIL yang berukuran sangat besar dapat mengakibatkan proses pengaksesan menjadi lebih lambat. Oleh sebab itu, perlu dilakukan partitioning pada materialized view tersebut. Dari hasil wawancara, laporan yang biasanya dihasilkan merupakan laporan bulanan. Maka dari itu, partisi berdasarkan bulan pada materialized view

MV_LAP_REAL_PO_I_DETAIL dianggap yang paling sesuai oleh penulis.