2019 GMMS Phase 1
Functions & Features
v20190927

Creation & Editing

Request dibuat oleh karyawan tingkat supervisor ke atas yang berhak menyusun daftar kebutuhan untuk unit kerjanya atau proyeknya.

Setiap Request mencantumkan identitas Budget yang telah terdaftar untuk menutup biaya (cost) yang akan muncul dan juga tujuan Purchasing Org yang akan mengeksekusi.

Request berisi satu atau lebih Request Item. Masing-masing Request Items menyebutkan nama dan jumlah barang atau jasa yang diminta, tanggal diperlukan, tujuan pengiriman, dan estimasi harganya.

Request dapat diedit berkali-kali sebelum dikirimkan untuk mendapat persetujuan (approval) "atasan". Perubahan sudah tidak dapat dilakukan setelah Request dikirimkan.

Approval

Approval dilakukan oleh "atasan" di dalam hirarki otorisasi Budget yang dirujuk oleh Request.

Jalur otorisasi Request bisa bercabang tergantung pada nilai estimasi total harga barang dan jasa di dalam Request

"Atasan" memiliki opsi untuk menolak, meminta revisi, atau meneruskan Request ke Purchasing Org yang sesuai.

Processing

Daftar item dari Request yang sudah disetujui akan diterima oleh Unit procurement di Purchasing Org

Setiap barang atau jasa di dalam Request Item perlu dirujukkan ke Product dan Product Vendor yang sesuai sebelum diproses lebih lanjut. Petugas dapat memeriksa dan mengulang perujukan tersebut.

Rencana pemenuhan Request Item dilakukan dengan melekatkan salah satu tanda (tag) sbb: to Asset (dari Asset), to SR (ambil stok), to PR (membeli), Reimburse (sudah dibeli) dan Reject (tidak bisa dipenuhi).

Di fase 1 ini hanya Request Item yang ditandai to PR akan diproses menjadi Memo Permintaan Pembelian (PR). Yang lainnya hanya akan di-listing menjadi report.

Grouping for PR

Saat diproses, Request Item yang ditandai to PR yang berarti "akan dibeli" diproses menjadi PR Item. Beberapa Request Item akan dikelompokkan (merge/group) menjadi satu PR Item jika:

• Ditujukan ke Purchasing Org yang sama
• Merujuk Budget yang sama
• Menggunakan Currency yang sama
• Memesan Product Vendor yang sama

Jumlah barang yang dipesan diakumulasikan (dijumlahkan) menggunakan UOM default Product Vendor. Harga per unit mengambil harga termurah dari item-item yang digabungkan. Tanggal kedatangan (expected date) mengambil tanggal paling dekat.

Vendor Selection

Fungsi utama PR untuk merencanakan pembelian, memilih vendor(s) yang tepat. Ada 2 opsi yang bisa dipilih, yaitu:

• Mengalirkan PR Item menjadi PO dengan melekatkan tanda to PO dilanjutkan dengan memilih 1 Vendor. Opsi ini bisa dipilih jika informasi harga sudah diperoleh dan sudah terekam di GMMS melalui proses Quotation.

• Mengalirkan PR Item menjadi RFQ dengan melekatkan tanda to RFQ dilanjutkan dengan memilih beberapa kandidat Vendor. Opsi ini dipilih jika vendor dan informasi harga masih harus dicari.

Generate PO & RFQ

Semua PR Item yang sudah ditandai to PO atau to RFQ akan diproses sekaligus menghasilkan satu atau beberapa dokumen PO atau RFQ sesuai dengan pilihan Vendornya.

Creation, Editing

RFQ dibuat oleh petugas pembelian baik secara langsung (manual) maupun dihasilkan (generate) dari proses PR. Tujuan membuat RFQ adalah memperoleh penawaran harga barang atau jasa dari kandidat Vendor. Setiap RFQ Item menyebutkan Product Vendor (barang/ jasa), jumlah unit yang akan dibeli serta Warehouse tujuan pengiriman agar Vendor dapat menghitung harga dan ongkos kirim yang mungkin timbul.

Sending

Setelah selesai diedit, RFQ dikirimkan ke Vendor. Proses ini sebenarnya hanya menandai bahwa RFQ sudah selesai diedit dan siap dicetak atau dikirimkan ke kandidat Vendor

Ralat sudah tidak boleh dilakukan pada RFQ yang sudah dikirimkan

Generate Quotation

Normalnya, RFQ yang dikirimkan akan dibalas oleh Vendor dengan dokumen penawaran atau Quotation yang berisi harga dan ongkos untuk masing-masing barang atau jasa.

Untuk mempercepat proses input Quotation ke GMMS maka Quotation dapat di generate dari RFQ sehingga sebagian besar isian sudah terisi.

Creation & Editing

Saat informasi harga diterima, petugas dapat langsung membuka layar Quotation untuk mencatat informasi harga yang diterimanya. Informasi harga tidak terbatas pada Surat Penawaran vendor saja, tetapi bisa juga dari iklan, flyer, brosur, bahkan informasi harga verbal saat negosiasi melalui telepon.

Selain dibuat secara langsung (manual), Quotation dapat juga dihasilkan (generate) dari proses RFP. Cara ini lebih cepat karena sebagian besar isian sudah terisi.

Workflow

Setelah selesai di edit, Quotation di-approve untuk langsung mengupdate price. Namun, jika pembuat Quotation bukan petugas atau staff pembelian, maka Quotation dapat dikirimkan ke Purchasing Org yang ditunjuk untuk mendapat approval dari petugas atau staff pembelian.

Saat di-approve, informasi harga barang dan jasa dalam Quotation akan langsung disimpan ke dalam Price (daftar harga)

Price Information

Informasi harga mencakup 2 hal yaitu:

Harga

Yaitu nominal harga dalam Currency tertentu per jumlah UOM(unit) tertentu. Contoh: Rp.1000 / 3 bungkus.

Kriteria Berlakunya Harga

Masa berlakunya. Contoh: Rp.1000 / 3 bungkus, setiap Jumat dari tgl 1 - 30 Okt 2019.

Jumlah unit pembelian. Contoh: Rp.1000 / 3 bungkus, minimal 3000 bungkus

Lead Time. Contoh: Rp.1000 / 3 bungkus untuk pengiriman 1 - 3 hari.

Area Pengiriman. Contoh: Rp.1000 / 3 bungkus untuk area Jawa-Bali.

Generate PO

Jika seluruh item di dalam Quotation ingin dibeli, maka Quotation tersebut bisa langsung diproses (generate) menjadi PO. Referensi PO ke Quotation akan dijaga.

Creation & Editing

Tersedia 3 cara membuat PO yaitu:

Dihasilkan dari PR (normal)

PO yang dihasilkan dari (generated from) proses PR membawa serta informasi sumber Request nya, sehingga sesuai dengan bisnis proses yang direkomendasikan (normal). Item dan jumlah barang di PO jenis ini sama dengan PR sumbernya. Yang bisa diubah hanya harga dan beberapa atribut lainnya.

Dihasilkan dari Quotation (tipe Q)

PO yang dihasilkan dari (generate from) proses Quotation membawa serta rujukan Quotation nya, namun tidak membawa informasi sumber Request nya, sehingga tidak sesuai dengan bisnis proses yang direkomendasikan. Item, jumlah, dan harga barang di PO jenis ini sama dengan Quotation sumbernya.

Dibuat secara manual langsung (tipe M)

PO yang dibuat secara manual langsung dari penekanan tombol "New" tidak membawa serta rujukan baik ke Quotation maupun ke Request, sehingga tidak sesuai dengan bisnis proses yang direkomendasikan. Semua informasi di dalam PO jenis ini dapat di edit.

Workflow

Selesai diedit, PO dapat langsung dikirimkan ke Vendor. Hanya PO yang sudah dikirimkan (status "Sent") yang bisa dicetak.

Dalam beberapa kasus tersebut di bawah ini, PO yang dikirimkan menuju Vendor akan dibelokkan terlebih dahulu untuk mendapat approval dari otoritas di Purchasing Org tersebut.

• Harga di PO lebih tinggi dari harga di PR
• Jika PO berasal dari Quotation (tipe Q)
• Jika PO dibuat secara manual (tipe M)

Hirarki approval PO mengikuti hirarki di Purchasing Org terkait.

Saat dikirimkan (send), item-item PO tersebut akan masuk ke daftar tunggu agar history pemenuhannya melalui GR dapat dilacak.

Closing

Secara normal PO akan otomatis ditutup saat jumlah barang yang dipesan sudah dipenuhi melalui proses GR. Namun, PO juga dapat ditutup "paksa" karena berbagai macam alasan, misalnya barang habis, atau kenaikan harga yang tidak wajar.

GMMS menerapkan mekanisme "batal sebagian" pada PO yang di closing secara "paksa". Item-item yang sudah diterima tetap diakui dan yang belum diterima tidak lagi ditunggu. Penilaian ulang nilai PO dilakukan langsung di sistem keuangan

Hanya petugas atau staf pembelian yang memiliki hak approval dapat melakukan closing secara "paksa"

Creation & Editing

Barang diterima di Warehouse kedatangan barang (dock) oleh petugas atau staf penerima barang. Ada proses fisik yaitu menerima barang, memeriksa kecocokan dan kondisi barang saat diterima dan menghitung jumlahnya.

Biasanya barang dikirimkan oleh Vendor disertai dengan surat kirim Delivery Order (DO), dan biasanya di DO itulah penerima barang melakukan check-list. GR adalah bentuk internal dari DO vendor. Fungsinya sebagai tanda terima (internal) yang bisa juga disampaikan kepada Vendor sebagai balasan surat pengiriman.

GR dapat dibuat secara manual, item barang dan jumlah yang diterima harus di input satu per satu. Cara yang lebih cepat adalah dengan memanggil nomor PO terlebih dahulu sehingga item di dalam PO tersebut langsung terpapar, tinggal diisi jumlah yang diterima.

Confirm & Send to SAP

Setelah selesai dibuat, GR perlu di confirm untuk menandai bahwa GR sudah benar dan tidak lagi mengalami perubahan. Confirm bisa dilakukan oleh penerima barang sendiri.

Saat di confirm GR akan memperbarui history daftar tunggu barang untuk PO yang dirujuk. Jika jumlah yang diterima sudah memenuhi, maka PO Item barang akan otomatis di Closing. Jika seluruh item sudah diterima maka PO juga di closing

Proses confirm GR juga memicu proses pengiriman data GR beserta dengan PO nya ke SAP. Subsystem SAP API dan memastikan bahwa PO hanya tersimpan 1 kali di SAP.

Karena pada fase 1 ini modul Warehouse belum dikembangkan maka fungsi GR masih terbatas pada pemenuhan item PO saja. Proses selanjutnya setelah barang diterima akan tetap dijalankan menggunakan aplikasi gudang yang digunakan oleh masing-masing unit bisnis di GoMED. Termasuk di dalamnya: Pengiriman (transfer) ke gudang penyimpan dan juga retur.

Creation & Editing

SN dibuat oleh petugas gudang atau penerima barang dari Vendor dan ditujukan kepada pengguna barang seperti tertera di dalam Request.

Pembuatan SN> dilakukan secara manual (langsung). Prioritas barang yang akan dikirimkan ke pengguna sbb:

• Barang di Warehouse penerimaan barang yang belum terkirim.
• Barang di dalam daftar tunggu Request.

Confirm

Setelah selesai dibuat SN dapat dicetak untuk menjadi lampiran saat pengiriman barang ke penggunanya.

Setelah barang diterima oleh pengguna, maka SN bisa di confirm untuk menandai bahwa SN tersebut sudah tidak bisa diedit lagi. SN kemudian digunakan untuk memperbarui daftar tunggu Request.

Penyusunan

RAB disusun oleh pimpinan unit dalam proses perencanaan pengeluaran untuk akuisisi aset dan biaya operasional unit di suatu periode waktu (tahunan, semester, bulanan, dll). RAB juga bisa disusun oleh inisiator proyek atau event planner dalam proses perencanaan biaya untuk proyek atau event.

Item-item barang dan atau jasa yang akan dibeli didaftarkan satu per satu ke dalam RAB. GMMS dapat membantu proses ini dengan:

Menyediakan estimasi harga

Estimasi harga diambil dari Price (buku harga) yang dikelola di GMMS dan diperbarui melalui proses Quotation

Menyediakan template isian RAB

RAB yang sudah jadi dapat disimpan menjadi template yang bisa dipanggil. Template bisa mempercepat proses penyusunan karena sebagian (besar) item belanja sudah terdaftar, tinggal menghapus yang tidak perlu atau menambahkan item baru. Template juga mencegah ada item biaya yang terlewat (lupa) untuk dianggarkan.

Pengajuan

Setelah selesai disusun, RAB diajukan ke otorisator sesuai hirarki otorisasi di dalam organisasi penyusun RAB. Otorisator memiliki opsi untuk meminta revisi, menolak, atau meng approve RAB yang diajukan.

RAB yang telah di appprove kemudian dikirimkan ke unit budget controller untuk di registrasi menjadi Budget

Registrasi

RAB yang telah di approve diterima oleh unit pengawasan untuk diregistrasi menjadi Budget. Karena anggaran masuk dalam ranah keuangan yang ditangani oleh sistem SAP, maka anggaran harus harus diregistrasikan ke sistem SAP terlebih dahulu sebelum dilakukan di GMMS.

Approval Hierarchy

Approval hierarchy adakah hirarki berstruktur parent-child yang dapat dilekatkan ke entitas-entitas bisnis di GMMS seperti: Budget, Purchasing Orh, dan Organization

Approval hierarchy tidak mengacu pada hirarki atasan-bawahan Human Resource (HR) yang diterapkan di unit kerja. Jika dikehendaki, approval lintas organisasi dapat dilakukan. Misalnya didalam organisasi proyek, atau di organisasi seperti GoMed.

Tracking & Control

Karena proses keuangan seluruhnya ditangani di SAP, sebagian fungsi Budget di GMMS menjadi tidak berfungsi (defunc). Nilai anggaran yang tertera di dalam Budget hanyalah catatan saja yang tidak digunakan di dalam proses apapun di GMMS.

Informasi nilai dan sisa anggaran dibaca langsung dari SAP oleh GMMS melalui subsystem SAP-API. GMMS tetap menjalankan sebagian fungsi kontrol anggaran melalui:

Status Budget

Hanya Budget berstatus (Open) saja yang bisa dirujuk dalam transaksi-transaksi di GMMS seperti Request dan PO

Approval Hierarchy

Approval hierarchy mengontrol anggaran pada tingkat penggunaannya di dalam transaksi.

Product, Product Vendor, "Informal" Product

Secara singkat dapat dijelaskan, Product adalah identifikasi barang atau jasa menurut GoMED, Product Vendor adalah identifikasi barang atau jasa menurut Vendor, "Informal" product adalah identifikasi barang atau jasa menurut pengguna awam di luar unit procurement.

Product	Product Vendor
Identifikasi barang atau jasa menurut GoMED	Identifikasi barang atau jasa menurut Vendor atau retail = Store Shelf Product
Digunakan untuk kepentingan internal	Digunakan untuk berkomunikasi dengan Vendor
Biasanya lebih general	Biasanya lebih spesifik
Detail menuju ke spesifikasi	Detail menuju ke retail (brand, packaging)
Tissue Wajah, Tissue Basah, Battery AA, Kertas HVS A4 80gr	Tessa Facial 250, Paseo 250, Mitu Baby 50, Energizer AA (2+1), Energizer Max AA (6+2), PaperOne A4 80gr, Sinar Dunia A4 80gr

Product

Pada konteks persediaan (di GoMED tentu saja), SKU (Stock Keeping Unit) dilekatkan ke Produk sehingga di tingkat Product inilah barang-barang dalam persediaan akan dijumlahkan. Secara umum, Product digunakan secara internal untuk:

• Identifikasi dan akumulasi barang di dalam persediaan (berapa persediaan kertas HVS A4?)
• Identifikasi dan akumulasi barang-barang aset (TI memelihara 30 notebook dan 25 server)
• Permintaan barang di dalam Request (saya minta 3 buah mouse untuk anak buah saya)

Hubungan antar entitas produk:

• Setiap Product merujuk ke 1 Product Category
• Setiap Product merujuk ke 1 Product Type, yaitu "Barang" (good) atau "Jasa" (services)
• Setiap Product memiliki 1 standar (default) satuan ukur UOM (Unit of Measurement)

Product Vendor

Secara umum, Product Vendor digunakan untuk:

• Berkomunikasi dengan Vendor
• Melekatkan harga di Price
• Identifikasi barang dan jasa di item-item RFQ, Quotation, PO, GR, dan SN
• Menjadi "detail" dari Product

"Informal Product"

GMMS mendukung penyebutan barang dan jasa secara informal pada proses penyusunan Request dan RAB. Tentu saja "informal product" ini akan diformalkan diproses-proses selanjutnya. "Informal product" menjadi bagian dari GMMS karena:

• Barang atau jasa belum terdaftar sebagai Product pada saat Request atau RAB disusun. GMMS menganut prinsip "diterima dulu" dan diformalkan di dalam proses daripada menolak Request atau RAB tersebut dan diulang lagi ketika barang atau jasa sudah diregister menjadi Product
• Product harus dikelola secara terpusat di GoMED, dan kemungkinan tidak terjangkau oleh peminta barang atau perencana anggaran.
• Untuk meningkatkan partisipasi user di dalam proses pengadaan. User di luar unit procurement yang awam dapat menyampaikan kebutuhannya menggunakan sebutan yang mereka pahami.

Product ≈ Material

GMMS menggunakan istilah Product untuk menyebut "Material". Sebutan ini dipilih karena "Produk" selain dapat digunakan untuk menyebut "Barang" atau "Benda" dapat juga digunakan untuk menyebut "Jasa".

Product Category

Product Category berfungsi mengelompokkan Produk yang sejenis untuk digunakan di report atau analisa.

Fungsi lain Product Category digunakan untuk menempelkan definisi attribut-atribut spesifikasi barang. Misalnya kategori PC memiliki atribut: Processor, RAM, Tahun Pembuatan. Kategori Pakaian punya atribut: Size, Warna, dll.

Product Category disusun secara hirarkis dengan level yang tidak dibatasi.

Product Cataloging

Proses penyusunan katalog barang dan jasa adalah salah satu proses terpenting di dalam manajemen pengadaan dan manajemen persediaan. Penyusunan katalog produk (Cataloging) ini membutuhkan perencanaan yang matang didukung pemahaman dan pengalaman karena:

• Hanya ada 1 (satu) katalog produk di GMMS yang dikelola secara terpusat (centralized)
• Katalog produk yang tunggal itu akan digunakan oleh seluruh Purchasing Org dan seluruh Warehouse di GoMED yang multi-organization
• Re-organisasi produk dan jasa meskipun sangat mudah dilakukan di GMMS efeknya di lapangan bisa sangat luas melintas organisasi.

Secara mudah, proses penyusunan katalog produk adalah mengidentifikasi barang dan jasa, menyusun klasifikasi dan mengkodekan barang atau jasa tersebut. Secara mudah juga, hanya ada 4 entitas di GMMS yang ditujukan khusus untuk mengelola katalog produk, yaitu: Product, Product Vendor, Product Type, dan Product Category.

Product Identification

Proses mendata produk (barang dan jasa) dan menentukan perbedaan produk satu dengan yang lainnya. Setiap produk yang teridentifikasi kemudian dicatat sebagai Product di GMMS. Beberapa pertimbangan saat mengidentifikasi produk:

• No Duplication. Produk yang sama hanya perlu dicatat 1 (satu) kali ke Product. Di GMMS, duplikasi produk akan menyebabkan masalah akumulasi (penjumlahan), di operasional bisa menimbulkan kerugian.
• Unique. Identitas produk (nama, kode) harus unique dan berlaku di semua unit pengadaan Purchasing Org dan gudang Warehouse
• Proper Detail. Proses generalisasi dan spesialisasi saat menentukan perbedaan setiap produk harus menemukan tingkat detail yang cukup, mengakomodir kebutuhan operasional dan analisa seluruh unit pengadaan Purchasing Org dan gudang Warehouse
• Intuitif. Nama, kode barang sebaiknya menggunakan bahasa, istilah, dan format yang umum serta konsisten, sehingga mudah dipahami dan ditemukan (browsed and searched). Kesulitan menemukan sebuah produk akan meningkatkan risiko duplikasi.

Product Classification

Proses menggolongkan atau mengelompokkan produk sejenis dan menyusunnya secara hirarkis. Klasifikasi produk dikelola di GMMS menggunakan Product Category dan Product Type. Dilingkungan yang multi-organization seperti di GoMED perlu dipertimbangkan hal-hal berikut:

• Hanya ada 1 (satu) hirarki produk yang dikelola secara terpusat yang akan digunakan oleh seluruh Purchasing Org dan Warehouse untuk reporting dan analisa.
• Klasifikasi sebaiknya menjawab pertanyaan "APA?" bukan "UNTUK APA?" karena peruntukan produk di masing-masing organisasi bisa berbeda. Contoh klasifikasi yang dihindari: "Barang Stock", "Perlengkapan Event", "Perlengkapan Produksi", "Lain-Lain", "Barang Promosi", dll.

Product Codification

Proses menyusun dan menetapkan aturan pengkodean produk untuk dilekatkan ke setiap produk (barang dan jasa). Field "kode" di Product dan Product Vendor disediakan untuk menyimpan kode produk, sudah ada pemeriksaan duplikasi. Karena "kode" produk hanya teks bebas maka bisa mengakomodir semua format yang mungkin seperti: Numerik, Alphanumeric, Mnemonic, Kodak Format, EAN, UPC, dll.

Timeline

Tanggal	Keterangan
13 Maret 2019	Permintaan dari CEO KGMedia → “Event Management System”.
14 Maret 2019	Pertemuan KGMedia Operation, KGMedia IT/ES Division, dan Corporate IT (CITIS) → “Pengembangan KGMedia Procurement System”. KMMS (Kompas) dipresentasikan untuk pertama kali CITIS menawarkan SAP MM untuk digunakan oleh KGMedia Kesepakatan: KMMS + SAP sebagai paket solusi procurement di KGMedia
19 Maret 2019	Pertemuan pertama KGMedia IT/ES, CITIS dan Comptroller → Base: Penyesuaian Fitur KMMS + SAP Integration. Investigasi dan beberapa pertemuan lanjutan di bulan Maret, April dan Mei → Cakupan Pengembangan.
20 Mei 2019	Pengembangan GMMS dimulai Pertemuan awal dan briefing kepada tim pengembang GMMS dari IT/ES dan CITIS Target bisa digunakan: 1 September 2019

Sasaran

Fungsi-fungsi GMMS awalnya ditujukan untuk membantu penyusunan anggaran Event. Kesepakatan-kesepakatan berikutnya melebar mencakup sebagian besar operasional pembelian.

1. Kecepatan dan akurasi penyusunan anggaran (event)

• Mempercepat proses Event Offering
• Database vendor, harga, history
• Proses approval anggaran yang lebih cepat

2. Mengurangi kesalahan estimasi margin

3. Mendorong pencatatan (administrasi) pada tingkat pelaksana (event).

• Mengurangi pencatatan “excel”
• Sistem yang mudah diakses, dioperasikan, berorientasi pelaksana
• Mempercepat proses pelaporan event → closing, perhitungan “real” margin.

Area Pekerjaan

Pekerjaan pengembangan meliputi 2 area yaitu:

1. Pengembangan sistem baru GMMS

• Fungsi-fungsi procurement: Request, PR, PO, GR, SN, RFQ, Quotation, RAB, Budget
• Fungsi-fungsi integrasi: GMMS-SAP Data Mapper, Front-end Process to SAP (PO, GR, Vendor, Product)
• Fitur-fitur tambahan: Email CTA, document & action tracking, warehouse (dock) untuk tracking PO dan Request.
• Pengembangan data terutama untuk Product Category, Product, dan Vendor

2. Pengembangan dan Konfigurasi di sisi SAP

• Pengembangan data terutama: Organizational (Cost Center, Plant), Budget, Unit Conversion
• BAPI untuk PO, MIGO, dan semua master yang terkait.
• Konfigurasi: PO Release strategy.

Status (as per Feb 25, 2020)

Pengembangan sistem baru GMMS sudah selesai

Update-update masih perlu dilakukan di beberapa tempat.

• Masalah/ isu baru ditemukan saat implementasi, belum muncul saat testing, langsung diselesaikan.
• Detail fitur yang di deliver dan statusnya ada di lampiran

Pengembangan di sisi SAP masih berlangsung

• SAP BAPI untuk update Vendor dan Material masih harus dicari
• Konversi unit untuk setiap material akan dikerjakan sambil jalan
• Release Strategy untuk PO SAP yang sempat bisa namun menimbulkan masalah lain

Implementasi tahap 1 di Jalan Panjang (2 business unit)

• Implementasi sudah mundur 4 bulan dari kesepakatan awal.
• Fungsi-fungsi pengadaan sudah dicoba: REQUEST, PR, RFQ, QUOTATION, PO, GR, SN, BUDGET. Fungsi yang belum dicoba: RAB
• Test menggunakan PO yang sudah ada, tidak benar-benar mengikuti workflow.

Selanjutnya

Melanjutkan implementasi

• Implementasi dilanjutkan setelah pengembangan dari sisi SAP selesai

Pengembangan modul warehouse (inventory) management

• Pengembangan KMMS (Harian Kompas) sudah tidak dilanjutkan. Inisiatif dan kebutuhan diarahkan ke GMMS.
• Mengakomodasi kebutuhan Harian Kompas (Suryatono, Asep Suryadi)
• Sudah disepakati di rapat tanggal: