Pemanfaatan Architecture Application Planning Untuk Perancangan Sistem Informasi Manufaktur Pada PT. RH

MANUFAKTUR PADA PT. RH

Oleh:

TESIS

Untuk memenuhi salah satu syarat ujian guna memperoleh gelar Magister Komputer

PROGRAM STUDI MAGISTER SISTEM INFORMASI

FAKULTAS PASCA SARJANA

UNIVERSITAS KOMPUTER INDONESIA

BANDUNG

2014

Ajeng Rahayu Ambarwangi 57.10.111.046

vii

DAFTAR ISI

LEMBAR PENGESAHAN……….………….. i

LEMBAR PERNYATAAN……….………….. ii

ABSTRAK……….……… iii

KATA PENGANTAR ……….………. iv

DAFTAR ISI ……….……… vii

DAFTAR TABEL……….……… xi

DAFTAR GAMBAR……….……… xiv

DAFTAR SIMBOL ……….………. xvi

BAB I PENDAHULUAN ………...……… 1

1.1.Latar Belakang ………...……… 1

1.2.Identifikasi Masalah ……….…….……….………… 3

1.3Tujuan Penelitian ……… 4

1.4Manfaat Penelitian ………..………… 4

1.4.1 Manfaat praktis………... 4

1.4.2 Manfaat Akademis……….. 5

1.5Batasan Masalah Dan Asumsi…………..………... 6

1.6Sistematika Penulisan ……….……… 7

BAB II TINJAUAN PUSTAKA……….……… 8

2.1 Tinjauan Pustaka……….………. 8

2.1.1 Perencanaan Sistem Informasi……….………... 8

………..……….…

2.1.3.1 Metodologi Untuk EAP……….…….. 12

2.1.3.1.1 Analisis Rantai Nilai……….…... 1

2.1.3.1.2 Daftar Fungsi Bisnis……….…… 13

2.1.3.1.3 BPMN (Business Process Modeling Notation)……… 13

2.1.3.1.4 Information Resource Catalog (IRC)……….. 14

2.1.3.1.5 Diagram Hubungan Entitas (ERD Diagram)………... 15

2.1.4 Portofolio Aplikasi……….……… 15

2.1.5 Pemodelan Jaringan……….……….. 16

2.1.6 Unified Modeling Language (UML) ……….… 17

2.2 Kerangka Pemikiran……….……… 18

BAB III METODE DAN ANALISA SISTEM……….. 20

3.1 Metode Penelitian……….……… 20

3.2 Inisiasi EAP……….………. 21

3.3 Survei Enterprise……….………. 21

3.4 Pemodelan Bisnis Fungsional……….………. 23

3.4.1 Analisis Rantai Nilai……….……… 24

3.4.2 Bagan Hirarki Fungsi Bisnis……… 29

3.4.2 Penggambaran Proses Bisnis Menggunakan BPMN……… 36

3.5 Sistem Dan Teknologi Saat ini……….……… 44

3.5.1 Aplikasi Legacy……….……….. 44

3.5.2 Arsitektur Teknologi……….………... 53

……….……….

4.1.1 Inbound processing……….………... 58

4.1.2 Planning and Production………... 60

4.1.3 Outbound Processing……….………... 61

4.2 Arsitektur Data……….………... 62

4.2.1 Kandidat Entitas Data……….………... 63

4.2.2 Definisi Entitas, Set, Atribut, dan Relasi……….………. 65

4.3 Arsitektur Aplikasi ……….………... 71

4.3.1 Kandidat Modul Aplikasi bedasarkan Applications Portfolio………. 72

4.3.2 Software Planning……….………... 77

4.3.3 Usecase Diagram……….………... 79

4.3.3.1Inbound processing……….………... 79

4.3.3.2 Planning production ……….………... 82

4.3.3.3 production Processing……….………... 85

4.3.3.4 Outbound Processing……….………... 88

4.3.3.5 User privilege Management……….………. 90

4.4 Arsitektur Teknologi ……….………... 92

4.4.1 Hardware Planning……….………... 93

4.5 Gap Analisys……….………... 93

4.6 Rencana Implementasi ……….………... 96

4.6.1 Rencana Urutan Implementasi Aplikasi……….………... 97

BAB V PENUTUP……… 99

5.2 Saran………

DAFTAR PUSTAKA……… 102

LAMPIRAN A………... 104

LAMPIRAN B………... 105

iv

Kemampuan untuk berpikir dan menganalisa yang dimiliki seseorang tidak menjamin orang tersebut mampu menyampaikan pikiran dan analisanya dalam suatu tulisan yang baik. Terlebih lagi dalam penulisan tesis yang menuntut suatu penulisan yang terstruktur dan ilmiah. Oleh karena itu, selain ketekunan, ketelatenan, dan kesungguhan serta kesabaran dalam penulisan tesis ini, dukungan dari banyak pihak juga merupakan faktor utama dalam penyelesaian tulisan ini.

Puji syukur penulis panjatkan kehadirat Tuhan, atas segala damai, berkat yang dianugerahkan kepada Penulis, sehingga akhirnya dapat menyelesaikan penulisan tesis yang berjudul “ PEMANFAATAN ENTERPRISE ARCHITECTURE PLANNING UNTUK PERENCANAAN SISTEM INFORMASI MANUFAKTUR PADA PT. RH”_.

Pada kesempatan ini, Penulis ingin mengucapkan terima kasih yang sebesar-besarnya kepada kedua orang tua dan keluarga Penulis yang dengan setulus hati dengan sabar mengasuh, mengajar, mendidik, memberikan semangat dan mendoakan Penulis.

Terimakasih yang tak terhingga juga Penulis ucapkan kepada Bapak. Prof.Dr. Estiko Rijanto selaku pembimbing pertama dan Bapak Ir.Taryana Suryana,M.Kom. selaku dosen pembimbing pendamping yang dengan segala kebaikannya telah sabar, setia memberikan arahan, bantuan, dan juga meluangkan waktu dan tenaga, serta pikirannya selama membimbing disela-sela kesibukan beliau dalam penyelesaian tesis ini sehingga Penulis dapat menyelesaikan tesis ini dengan baik.

Penulis sampaikan pula rasa terima kasih yang sebesar-besarnya kepada yang terhormat :

1. Rektor dan Dekan Pasca Sarjana Universitas Komputer Indonesia (UNIKOM) Bandung.

v

2. Dr. Ir. Yeffry Handoko Putra, M.T. Selaku ketua program studi Magister Sistem Informasi Universitas Komputer Indonesia.

3. Teman – teman seperjuangan Magister Sistem Informasi yang saling mendukung dan menyemangati untuk menyelesaikan penelitian ini.

4. Sahabat dan orang terdekat Penulis yang selalu memberikan dorongan dan motivasi dalam hidup.

Kata maaf dan terimaksih Penulis ucapkan kepada semua yang telah membantu dan mendukung proses penulisan tesis ini yang tidak dapat disebutkan satu persatu. Semoga kebaikan semua pihak dapat Penulis balas suatu hari nanti.

Akhir kata Penulis menyadari bahwa tesis yang dibuat ini sangat jauh dari sempurna, disebabkan keterbatasan kemampuan yang penulis miliki. Penulis mohon maaf yang sebesar-besarnya atas ketidaksempurnaan yang terdapat dalam tesis ini. Untuk itu Penulis mengharapkan kritik dan saran yang membangun dari semua pihak, semoga tesis ini dapat memberikan manfaat kepada semua pihak.

Penulis

Bandung, Agustus 2014

102

Estiko Rijanto, Integrasi kendali dan Sistem Informasi untuk Meningkatkan Keunggulan Daya Saing Industri, LIPI Press, Jakarta,2013

Cook, Melissa A., Building Enterprise Information Architectures, Prentice Hall, 1996.

IBM, Business System Planning: Informatio Systems Planning Guide, 1981.

Martin, James, Information Engineering (Book II, Planning and Analysis), Prentice-Hall, 1990.

ISO/TC 184/SC 5/WG 1. 1999.Industrial Automation Systems — Requirements for Enterprise-Reference Architectures and Methodologies.

Lankhorst, Marc. 2005. Enterprise Architecture at Work. Springer

Porter, Michael E., Competitive Advantage: Creating and Sustaining Superior Performance,Free Press, New York, 1985.

Spewak, Steven H., Hill, Steven C., Enterprise Architecture Planning: Developing a Blueprint for Data, Applications, and Technology, John Wiley& Sons, 1992. Surendro, K., Nursikuwagus, Agus, Enterprise Architecture Planning Pusat

Penelitian danPengembangan Geologi Bandung, Prosiding KNSI 2005, 2005, pp. 213-217. Surendro, K., Paulus, Perencanaan Arsitektur Enterprise (Studi Kasus PTS), Prosiding KNSI, 2005, pp. 183-187.

Surendro, K., Purwanto, H., Perancangan Model Enterprise Architecture dengan Menggunakan Zachman Framework, Prosiding KNSI, 2005, pp. 207-212. Surendro, K., Setiawan, EB., Pemodelan Bisnis dalam EAP (Studi Kasus STT

Telkom), Prosiding KNSI, 2005, pp. 195-205.

Surendro, K., Setiawan, EB., Information Resource Catalog (Studi Kasus STT Telkom), Prosiding KNSI, 2005, pp. 201-205.

Ward, J., Peppard, J., Strategic Planning for Information Systems, 3rd Edition, John Wiley &Sons, 2002.

Zachman, John A., A Framework for Information Systems Architecture, IBM Systems Journal, Vol. 26, No.3, 1987.

Ayulius,Yosef, Penerapan Metode Enterprise Architecture Dalam Meningkatkan Kemampuan Strategi Bisnis Dan Teknologi Pada PT. Dwi Naga Sakti Abadi, Sistem Informasi BINUS, 2012.

1

BAB I

PENDAHULUAN

1.1Latar Belakang

PT.RH adalah sebuah perusahaan cat nasional yang berpusat di kawasan industri kota Cimahi. Pada pelaksanaan operasionalnya, PT.RH dibagi ke dalam 2 (dua) ranah bisnis, yaitu manufaktur dan distribusi. Dalam pencapaian misi enterprise, saat ini PT.RH telah memanfaatkan system informasi guna mendukung kegiatan operasional, ranah bisnis distribusi khususnya telah memiliki system informasi yang mapan sedangkan system informasi manufaktur perlu dilakukan peninjauan kembali. Sistem informasi manufaktur memegang peranan penting, karena pada saat system informasi manufaktur dapat menyediakan informasi waktu nyata yang diintegrasikan dengan system informasi enterprise, maka akan meningkatkan keunggulan daya saing, E.Rijanto (2013).

Tidaklah sulit membayangkan bagaimana sebuah kota tumbuh dan berkembang tanpa adanya perencanaan tata kota. Hasilnya akan segera terjadi kekacauan dalam membangun kota; akan terlihat pemandangan aktivitas gali dan tutup lubang untuk pembuatan saluran air bersih, saluran air kotor, penggalian kabel telekomunikasi, perbaikan jalan & sebagainya. Bangunan dan infrastruktur kota akan dibuat sesuai dengan kebutuhan masing-masing pengembang dan seringkali secara tidak terarah, yang akhirnya akan terwujud suatu tatakota yang kurang beraturan. Kondisi seperti itulah yang terjadi pada system informasi PT.RH pada ranah manufaktur, mengembangkan sistem informasi tanpa adanya

perencanaan yang baik. Hasilnya terjadi pulau-pulau sistem yang biasanya, sistem ini saling terpisah satu dengan yang lain, yang diiringi dengan banyak dan menyebarnya ‘pulau data’ yang sulit untuk diintegrasikan.

Pulau – pulau data yang dimaksud adalah bahwa tidak jarang bagian pada perusahaan memiliki data yang tidak terhubung dengan data yang dimiliki bagian lain, walaupun pada proses bisnis memiliki hubungan atau keterkaitan. Keterpisahan ini memberikan dampak yaitu rendahnya tingkat ketersediaan, konsistensi dan efektivitas penyediaan data, Cook (1996) . Kondisi tersebut membuat SI tidak dapat dimanfaatkan sesuai dengan misinya yaitu menyediakan dan mengolah informasi secara efektif bagi unit organisasi yang membutuhkannya, Spewak (1992) . Hal ini memperlihatkan bahwa pengembangan sistem informasi di PT.RH tidak direncanakan secara baik, sehingga terjadi tambal sulam system informasi sesuai kebutuhan setiap bagian organisasi tanpa memperhatikan integritas secara keseluruhan di dalamanya.

Berbagai macam pendekatan bisa digunakan untuk membuat perencanaan sistem informasi. Dalam penelitian ini akan dibahas tentang perencanaan system informasi dengan memanfaatkan metodologi Perencanaan Arsitektur Enterprise (EAP) yang menghasilkan arsitektur data, arsitektur aplikasi, arsitektur teknologi, dan arah rencana implementasi bagi enterprise sehingga dapat memberikan landasan yang lebih mapan bagi pengembangan sistem informasi guna meningkatkan dukungan system informasi yang tepat bagi enterprise dari keterpaduan arah dalam perencanaan, pelaksanaan dan pengendalian yang selaras dengan tujuan bisnis enterprise.

1.2Identifikasi Masalah

Bertitik tolak dari latar belakang masalah yang ada, maka dapat diidentifikasi permasalahan-permasalahan yang sering terjadi adalah sebagai berikut:

1. Sistem yang saling terpisah satu dengan yang lain, yang diiringi dengan banyak dan menyebarnya ‘pulau data’ dalam organisasi, selain itu system belum dapat meng-cover seluruh kegiatan bisnis perusahaan. 2. Pada saat kebutuhan akan informasi yang cepat guna mendukung

keputusan, distribusi ketersediaan dan konsistensi data rendah dikarenakan system yang belum terintegrasi.

3. Kurangnya efektifitas proses bisnis perusahaan, karena masih ditemukan proses yang dinilai tidak perlu.

4. Bercermin pada perkembangan teknologi saat ini, teknologi yang digunakan PT.RH manufaktur sudah tertinggal.

5. SI tidak dapat dimanfaatkan sesuai dengan misinya yaitu menyediakan dan mengolah informasi hingga mendukung mencapai proses kerja dengan standar kualitas tinggi.

6. Perencanaan sistem informasi seperti apa yang dibutuhkan sehingga dapat memberikan landasan yang lebih mapan bagi pengembangan sistem informasi serta dapat diukur proses dan hasil implementasinya.

1.3Tujuan Penelitian

Adapun tujuan yang ingin dicapai melalui serangkaian penelitian ini adalah sebagai berikut:

1. Untuk mengetahui perencanaan SI yang dibutuhkan sehingga dapat memberikan landasan yang lebih mapan bagi pengembangan sistem informasi serta dapat diukur proses dan hasil implementasinya.

2. Untuk mengetahui model arsitektur informasi yang sesuai dengan tujuan dan kebutuhan perusahaan dengan mempertimbangkan masalah yang ada dalam sistem informasi saat ini, ketidaksesuaian prosedur/sistem, dan perincian kebutuhan system manufaktur.

3. Untuk mempersiapkan rencana bagi pengelolaan analisis, perancangan dan pengembangan system berbasis komputer.

2 Manfaat Penelitian

Dengan dilaksanakannya penelitian, mahasiswa dapat membandingkan antara teori yang didapat dengan praktek yang sesungguhnya. Pada prinsipnya penelitian merupakan suatu penerapan dari teori menjadi praktek, maka berikut akan di uraikan kegunaan penelitian bagi akademis dan praktis.

1.4.1 Manfaat Praktis

a) Bagi Lembaga

Dapat menjalin kerjasama yang baik dengan beberapa lembaga atau perusahaan yang dapat menunjang kemajuan pendidikan.Untuk memenuhi kurikulum yang telah ditentukan.

b) Bagi Perusahaan

Dengan adanya sistem informasi ini diharapkan dapat digunakan secara optimal dan tepat guna, sehingga dapat mengefisienkan waktu dalam proses pencarian dan pelaporan data sehingga dapat meningkatkan produktivitas perusahaan.Arsitektur yang dihasilkan akan mempermudah pengelola untuk memetakan aspek-aspek pelayanan. Dengan demikian pengelola dapat memperoleh gambaran secara menyeluruh dan mendalam tentang system informasi manufaktur yang bersangkutan.Kontribusi yang diharapkan dari penelitian ini adalah menggunakan EAP untuk mendapatkan arsitektur dari penggunaan informasi yang mendukung bisnis dan membantu mendapatkan model rencana implementasi tersebut dari arsitektur data, aplikasi dan platform teknologi bagi perusahaan.

c) Bagi Mahasiswa

Dapat memahami dan menambah pengetahuan serta wawasan dibidang teknologi sistem informasi.

1.4.2 Manfaat Akademis

1. Bagi Pengembangan Ilmu

Untuk merealisasikan ilmu yang didapat dan dipelajari di kampus dengan penelitian dan diharapkan penelitian yang dilakukan dapat memperluas khazanah keilmuan yang telah ada sebelumnya.Selain itu juga akan memperluas konsep EA dari konsep enterprise ke konsep entity. Yang dimaksud dengan entity di sini adalah setiap sistem, baik

fisik maupun non-fisik, alamiah maupun artifisial, yang memiliki karakteristik-karakteristik yang dapat dianalogikan dengan EA.

2. Bagi Peneliti Lain

Hasil penelitian diharapkan dapat memberikan manfaat dalam meningkatkan pemahaman/ pemikiran kepada peneliti lain yang akan mengambil skripsi atau tugas akhir dalam kajian yang sama sekalius sebagai referensi di dalam penulisan.

3. Bagi Penulis

Penelitian ini diharapkan dapat menambah pengetahuan baik teori maupun praktek tentang membangun sistem informasi.

3 Batasan Masalah dan Asumsi

Dalam penelitian ini diberikan batasan masalah agar dalam penjelasannya tidak keluar dan menyimpang, lebih terarah dan dapat dipahami sesuai dengan yang diharapkan serta terorganisasi dengan baik.

Adapun batasan masalah dalam pembuatan pemanfaatan enterprise architecture Planning untuk perencanaan strategis system informasi antara lain:

1. Penelitian dilakukan pada PT.RH ranah bisnis manufaktur.

2. Pada tahap penilitian pertama ini, hanya difokuskan pada kegiatan atau aktivitas utama bisnis perusahaan, yang meliputi kegiatan pemasukan barang, kegitan produksi dan kegiatan pengeluaran barang.

3. Proses permintaan pembelian barang dan kedatangan barang yang akan dibahas dalam penelitian ini, hanya mencakup bahan – bahan baku yang diperlukan untuk produksi barang.

4 Sistematika Penulisan

Pada penyusunan Thesis ini Sistematika Penulisan terdiri atas 5 Bab, yaitu : BAB I PENDAHULUAN

Latar Belakang Penelitian, Identifikasi Masalah, Tujuan Penelitian, Manfaat Penelitian, Batasan Masalah dan Asumsi, Lokasi dan Waktu Penelitian, Sistematika Penulisan.

BAB II TINJAUAN PUSTAKA DAN KERANGKA PEMIKIRAN

Berisi teori dan ulasan pustaka yang dipergunakan dalam pembuatan arsitektur data, aplikasi, dan teknologi.

BAB III MODEL PENELITIAN DAN ANALISA SISTEM

Berisi model penelitian yang digunakan dan model bisnis dan kondisi dukungan teknologi informasi yang diperoleh dari proses pengumpulan data. Pada bab ini juga dilakukan analisis data, aplikasi dan teknologi yang sedang berjalan saat ini.

BAB IV PEMODELAN ARCHITECTURE ENTERPRISE

Pada bab ini diuraikan proses pembangunan atau perencanaan arsitektur enterprise, dan hasil arsitektur data, arsitektur aplikasi dan arsitektur teknologi untuk implementasi masa datang dengan menggunakan langkah-langkah EAP.

BAB V PENUTUP

Memuat tentang kesimpulan dan saran dari hasil tesis atau penelitian lanjutan.

8

TINJAUAN PUSTAKA DAN KERANGKA PEMIKIRAN

2.1 Tinjauan Pustaka

Pemanfaatan enterprise Architecture planning (EAP) untuk perencanaan system informasi melibatkan pemahaman dan kejelasan beberapa definisi dan konsep antara lain perencanaan sistem informasi, enterprise Architecture Planning, dan konsep lainnya yang mendukung penulisan ini.

2.1.1 Perencanaan Sistem Informasi

Tujuan utama perencanaan sistem informasi adalah mempersiapkan rencana bagi pengelolaan analisis, perancangan dan pengembangan system berbasis komputer

Martin(1990). Dalam metodologi kerekayasaan informasi, tiap langkah dapat dilihat

dari dua sisi, yaitu data dan aktivitas.Untuk perencanaan sistem informasi di sisi data, arah tinjauan strategisnya adalah terhadap kebutuhan informasi yang dibutuhkan oleh enterprise.Sedangkan di sisi aktivitas, arah tinjauan strategisnya adalah dalam hal pemanfaatan teknologi untuk peningkatan kinerja enterprise (Gambar 1).

Beberapa alasan mengapa sebuah organisasi memelukan perencanaan SI/TI yaitu : a. Adanya investasi untuk pengadaan SI/TI yang tidak mendukung sasaran bisnis suatu organisasi.

b. SI/TI yang ada tidak terkontrol

c. Sistem tidak teintegrasi sehingga data bersifat tersebar sehingga sangat mungkin terjadi kerangkapan data dan hilangnya keterkaitan antar sumber daya informasi. d. Organisasi tidak memiliki skala prioritas dalam mengembangkan proyek SI/TI, sehingga sangat sering terjadi perubahan dan tambal sulam yang akhirnya menurunkan produktivitas organisasi.

e. Manajemen informasi yang buruk dan tidak akurat.

f. Strategi SI/TI tidak sejalan dengan strategi bisnis organisasi

g. Proyek SI/TI hanya dievaluasi untuk kepentingan keuangan semata.

2.1.2 Kerangka Kerja Arsitektur Enterprise

Enterprise Architecture (disingkat EA) yang merupakan salah satu disiplin dalam TI memiliki definisi seperti:

1. Deskripsi misi para stakeholder mencakup parameter informasi, fungsionalitas, lokasi, organisasi, dan kinerja. EA menjelaskan rencana untuk membangun sistem atau sekumpulan sistem.

2. Pendekatan logis, komprehensif, dan holistic untuk merancang dan mengimplementasikan sistem dan komponen sistem yang bersama.

3. Basis aset informasi strategis, yang menentukan misi, informasi dan teknologi yang dibutuhkan untuk melaksanakan misi, dan proses transisi untuk mengimplementasikan teknologi baru sebagai tanggapan terhadap perubahan kebutuhan misi.

4. EA memiliki empat komponen utama: arsitektur bisnis, arsitektur informasi (data), arsitektur teknologi, dan arsitektur aplikasi.

5. Sehubungan dengan keempat komponen ini, produk EA adalah berupa grafik, model,dan/atau narasi yang menjelaskan lingkungan dan rancangan enterprise.

2.1.3 Enterprise Architecture Planning

Perusahaan bisa diartikan sebagai suatu organisasi yang mempunyai misi dan tujuan untuk menawarkan suatu hasil berupa produk atau layanan. ISO (1999). Kebanyakan perusahaan tidak mempunyai blueprint untuk proses, data dan teknologi yang dibutuhkan untuk melakukan bisnisnya. Ketika perusahaan berkembang dan menjadi lebih kompleks, pihak manajemen membutuhkan akses data kapanpun dan dimanapun, secara akurat, dengan format yang mudah dibaca, konsisten di tiap bagian perusahaan, dan yang paling penting dalam waktu yang cepat. Untuk mengakomodasi kebutuhan tersebut, biasanya perusahaan akan membuat aplikasi tambahan tanpa ada perencanaan yang lebih matang dengan mempertimbangkan kondisi seluruh perusahaan. Hal ini hanya akan menyebabkan data yang didapat tidak sesuai dengan yang diharapkan. Satu-satunya cara untuk memperbaiki sistem perusahaan yang semakin lama akan semakin buruk kinerjanya adalah dengan merancang arsitektur perusahaan.

Perusahaan membutuhkan suatu pedoman dalam pelaksanaan proses bisnis untuk mencapai tujuan bisnisnya. Pedoman ini sebaiknya dibuat pada awal masa pendirian perusahaan tersebut. Pedoman ini bisa disebut sebagai arsitektur perusahaan. Berikut adalah definisi arsitektur perusahaan:

1. Arsitektur perusahaan adalah suatu alat konseptual yang membantu perusahaan untuk mengerti struktur dan bagaimana mereka bekerja. Arsitektur perusahaan menyediakan peta perusahaan dan rencana kerja untuk perubahan bisnis dan teknologi. Plat (2002).

2. Arsitektur perusahaan mencoba menggambarkan dan mengontrol struktur organisasi, proses, aplikasi, sistem, dan cara/metode secara terintegrasi. Lankhorst (2005)

Tabel 2.1 Pendekatan EAP dengan Zachman Framework

Perancangan arsitektur perusahaan atau Enterprise Architecture Planning (EAP) adalah proses mendefinisikan arsitektur untuk penggunaan informasi yang berfungsi untuk menjalankan bisnis dan rencana untuk implementasinya. Spewak (1992). Tujuan akhirnya adalah terpenuhinya kebutuhan data dari pihak manajemen. Hubungannya dengan Zachman Framework (ZF), EAP adalah proses mendefinisikan dua level atas ZF seperti terlihat pada Tabel 2.1 dan Gambar 2.1.

Gambar 2.2 EAP

EAP berfokus pada pendefinisian arsitektur data, aplikasi, dan teknologi untuk perusahaan secara keseluruhan. ZF sebagai kerangka berpikir konseptual sedangkan

metodologi EAP terdiri dari tiga level pelaksanaan. Tiga level ini dijabarkan kembali menjadi tujuh tahap yang harus dilalui untuk mendefinisikan arsitektur tersebut. Tujuh tahapan ini dapat dilihat pada Tabel 2.2 dibawah ini.

Tabel 2.2 Tahapan EAP

2.1.3.1Metodologi Untuk EAP

Pendekatan EAP menyediakan arah, tahapan, langkah, tugas, dan artifak arsitektur enterprise yang dihasilkan, sekaligus juga menyarankan agar dilakukan pemilihan metodologi yang dapat menunjang penyelesaian EAP secara efektif sesuai dengan kondisi dan kebutuhan Surendro (2005). Pada bagian ini, metodologi yang dipilih untuk EAP diuraikan sesuai dengan langkah-langkah utama dalam tiap tahap EAP.

2.1.3.1.1 Analisis Rantai Nilai

Analisis rantai nilai yang pertama kali diusulkan oleh Porter merupakan alat analisis stratejik yang digunakan untuk memahami secara lebih baik terhadap keunggulan kompetitif, untuk mengidentifikasi dimana nilai pelanggan dapat ditingkatkan atau penurunan biaya, dan untuk memahami secara lebih baik hubungan perusahaan dengan pemasok, pelanggan, dan perusahaan lain dalam industri. Pengelompokan area-area fungsional kedalam aktivitas utama dan pendukung

2.1.3.1.2 Daftar Fungsi Bisnis

Daftar fungsi bisnis digunakan untuk menentukan konteks dan lingkup enterprise dengan cara mengidentifikasi dan menginventarisasikan area-area fungsi yang dijalankan organisasi. Dalam kerangka kerja Zachman, hasil-hasil ini mengisi baris perencana dan kolom fungsi.Tiap-tiap area fungsi dapat dikomposisikan sehingga menjadi proses-proses bisnis dalam berbagai tingkatannya. Dekomposisi diperlukan untuk menghasilkan model aktual dan nantinya arsitektur enterprise yang lebih utuh dengan definisi yang lebih lengkap.

2.1.3.1.3 BPMN (Business Process Modeling Notation)

BPMN merupakan salah satu metoda pemodelan proses bisnis dari BPMI (Business Process Management Initiative) dan model yang digunakan untuk tahapan awal dalam rangkaian seluruh aktivitas pemodelan proses bisnis. BPMN merupakan tools pemodelan proses bisnis yang masih baru, yang dirilis pada bulan Mei 2004.BPMN menyediakan BPD (Business Process Diagram), yang berlandaskan

pada teknik flowchart yang digunakan untuk membuat model proses bisnis. BPMN mendukung swimlanes, yaitu Pool dan Lane Ward (2002) ,Pool merepresentasikan participant dalam proses, sedangkan Lane merupakan dekomposisi atau sub partisi dari Pool.

2.1.3.1.4 Information Resource Catalog (IRC)

IRC digunakan untuk mendokumentasikan dan mendefinisikan semua landasan sistem dan teknologi yang sedang digunakan dalam enterprise.IRC tidak menjabarkan setiap sistem secara terperinci, melainkan ringkasannya saja.ORC juga bukan kamus data ataupun inventori peralatan komputasi. Spewak melaporkan keuntungan dari pembuatan dan pengelolaan IRC sebagai berikut :

1) IRC menyediakan rujukan akan semua sumber daya informasi. 2) IRC menunjukan distribusi sumber daya informasi dalam enterprise.

3) IRC dapat digunakan sebagai petunjuk lokasi informasi yang dibutuhkan manajemen.

4) IRC dapat digunakan untuk memberikan orientasi bagi personil baru kedalam Departemen SI.

5) IRC digunakan dalam EAP sebagai basis perencanaan.

6) Keputusan penganggaran dan kendali biaya dapat dihubungkan secara langsung dengan IRC.

7) IRC dapat dibuat dengan cepat dan dengan biaya yang layak. 8) IRC merepresentasikan penggunaan internal piranti dokumentasi.

IRC dapat dikerjakan secara terpisah atau bersamaan dengan EAP, akan tetapi lebih baik kalau IRC diselesaikan lebih dahulu sebelum melakukan pekerjaan-pekerjaan arsitektural.

2.1.3.1.5 Diagram Hubungan Entitas (ERD Diagram)

Suatu entitas data bisa menunjang lebih dari satu area fungsi dan tidak berdiri sendiri, melainkan memiliki ketergantungan dan hubungan dengan entitas data lainnya.Pendekatan EAP mengambil ketergantungan dan hubungan antar entitas data ini untuk melandasai pembangunan arsitektur enterprise. Hal ini mempertimbangkan bahwa aplikasi-aplikasi terkait erat dengan basis-basis data, sedangkan suatu basis data terdiri dari kumpulan entitas data dengan hubungan dan ketergantungannya.

Untuk itu, entitas-entitas data perlu dirangkai sesuai dengan ketergantungan dan hubungannya dalam konteks area fungsi yang didukungnya. Dalam penelitian ini, pemodelan untuk hal ini dilakukan dengan Entity Relationship Diagram (ERD).

2.1.4 Portofolio Aplikasi

Portofolio aplikasi adalah hasil dari perencanaan strategi SI, dapat dikategorikan menjadi empat jenis berdasarkan kontribusinya terhadap bisnis.

1. Aplikasi strategis (Strategic)

Adalah aplikasi yang kritis terhadap Strategi Bisnis di masa datang. 2. Aplikasi operasional utama (Key Operational)

Adalah aplikasi yang digunakan saat ini oleh organisasi dan menentukan keberhasilan bisnisnya.

3. Aplikasi potensi tinggi (high Potensial)

Yaitu aplikasi inovatif yang mungkin bisa menciptakan peluang untuk meraih keuntungan di masa datang, tetapi masih belum terbukti.

4. Aplikasi pendukung (Support)

Aplikasi yang bermanfaat tetapi tidak kritis terhadap keberhasilan bisnis. Tabel 2.3. Portfolio Application Matrix

2.1.5 Pemodelan Jaringan

Jaringan dimodelkan dengan menggambarkan tiap node yang berperan dalam prosesdan data.Pemodelan ini mempertimbangkan jenis topologi yang digunakan dan kebutuhan komunikasi antar node tersebut.Node ini bisa berupa user, komputer (client), server, printer,router, ethernet, switch, bridge, firewall, radio tower, wireless access point, tower, hub,scanner. Tidak ada standardisasi untuk penggambaran tiap-tiap node.Walaupun begitu harusada konsistensi dan keterangan yang jelas untuk tiap-tiap node yang digambarkan.Jadi, node ini akan digambarkan sesuai dengan aplikasi pemodelan yang digunakan. Hubungan antar node sendiri digambarkan dengan garis yang menghubungkan node tersebut.Tabel 2.6 menunjukan simbol-simbol yang digunakan untuk pemodelan.

Tabel 2.3 Inset Jaringan

2.1.6 Unified Modeling Language (UML)

Unified Modeling Language (UML) adalah keluaraga notasi grafis yang

membantu pendeskripsian dan desain sistem perangkat lunak, khususnya sistem yang dibangun menggunakan pemrograman berorientasi objek (OO). Definisi ini merupakan definisi yang sederhana. Pada kenyataannya, pendapat orang-orang tentang UML berbeda satu sama lain. Hal ini dikarenakan oleh sejarahnya sendiri dan oleh perbedaan persepsi tentang apa yang membuat sebuah proses rancang-bangun perangkat lunak efektif (Martin 2005:1).

Pada tahap analisis, meliputi usaha untuk mengetahui apa kemampuan sebuah sistem yang diinginkan pengguna dan pelanggan dari sebuah perangkat lunak. Beberapa teknik yang dapat membantu dalam tahapan analisis (Martin 2005:44):

1. Use case diagram, menggambarkan bagaimana orang-orang berinteraksi

dengan sistem tersebut.

2. Class diagram yang diambil dari sudut pandang konseptual, dapat menjadi

cara untuk membangun kosa kata yang sangat besar tentang domain.

3. Activity diagram, menunjukkan aliran kerja organisasi tersebut dapat

menunjukkan bagaimana aktivitas interaksi antara perangkat lunak dan manusia.

4. State diagram, yang berguna jika sebuah siklus hidup yang menarik, dengan bermacam-macam state dan even yang mengubah state tersebut.

2.2 Kerangka Pemikiran

Terdapat beberapa jurnal atau pun tesis yang membahas tentang perancangan system informasi atau Enterprise Architecture yang dapat digunakan penulis sebagai tolak ukur atau kerangka pemikiran yang dapat memperkuat ide serta pemikiran dalam penulisan ini, diantaranya adalah sebagai berikut :

1. Dalam jurnal yang disusun oleh Ali Tarmuji yang berjudul “Perancangan Sistem Informasi pada PT.XYZ” tahun 2010, disebutkan bahwa kegiatan utama manufaktur terdiri dari 3 bagian, yaitu logistic masukan, proses dan logistik keluaran. Pada jurnal tersebut ditekankan hanya pada pembangunan aplikasi untuk membantu kegiatan operasional manufaktur yang saat ini masih dilakukan secara manual.

2. Dalam penelitian yang ditulis oleh Yosef Ayulius Prasriono pada tahun 2012 yang berjudul “Penerapan Metode Enterprise Architecture Dalam Meningkatkan Kemampuan Strategi Bisnis Dan Teknologi Pada PT. Dwi Naga Sakti Abadi” untuk memenuhi salah satu syarat kelulusan pada Universitas BINUS. Dimana PT. Dwi Naga Sakti Abadi merupakan perusahaan manufaktur yang memproduksi sepatu, kegiatan utamanya terdiri dari logistic masukan, proses dan logistic keluaran. Pada tesis tersebut di atas memberikan masukan terhadap perusahaan dalam upaya integrasi data, efisiensi system informasi, pengembangan aplikasi yang

telah ada dan arsitektur teknologi yang lebih efisien dengan menggunakan metode SWOT dan EAP.

Pada penelitian yang berjudul ‘ Pemanfaatan Enterprise Architecture Planning

Untuk Sistem Informasi Manufaktur Pada PTRH’ ini , akan dilakukan pada perusahaan yang bergerak di bidang manufaktur pada proses bisnis inbound processing, planning and production dan outbound processing. Informasi disajikan dari system yang sedang berjalan saat ini, sampai dengan system yang diusulkan selanjutnya. Sistem yang diusulkan selanjutnya, selain dapat memberikan masukan terhadap perusahaan dalam upaya integrasi data, efisiensi system informasi, pengembangan aplikasi yang telah ada dan arsitektur teknologi yang lebih efisien, juga dapat memberikan solusi dalam upaya realtime informasi dengan menggunakan Ilmu Pengetahuan dan Teknologi (IPTEK) yang ada pada saat ini , penghematan biaya dengan melakukan pengembangan aplikasi (paperless), memberikan solusi kemudahan akses data reporting manajerial yang dapat dilakukan mobile, sampai dengan usulan perencanaan tahap implementasi dengan menggunakan metode portofolio.

98 BAB IV

PEMODELAN ARCHITECTURE ENTERPRISE

4.1Alur Proses Produk yang Diharapkan

Untuk proses pengembangan sistem informasi PT.RH maka diperlukan perencanaan agar system informasi dapat meningkatkan hasil dan kualitas produksi. Berdasarkan observasi langsung di lapangan dan wawancara ( LAMPIRAN A) tehadap tiap bagian yang berkepentingan, titik berat keinginan user (user expected) antara lain adalah ada poin- poin berikut:

1 Integritas data, tidak ada lagi pulau – pulau data pada setiap bagian

2 Manajemen bahan baku yang termonitoring dengan baik, sehingga tidak ada lagi produksi yang diberhentikan setengah jalan karena bahan baku yang telah lama dipersiapkan dipakai oleh order yang tidak terduga (unplan). 3 Otomatisasi pada proses – proses yang masih dilakukan manual saat ini 4 Efektifitas proses bisnis, jika masih terdapat proses bisnis yang tidak sesuai

saat ini

5 Paperless, guna mengurangi biaya tambahan yang harus dikeluarkan perusahan

6 Aplikasi yang user friendly, menggunakan teknologi yang mampu menyajikan

Dengan mempertimbangkan keinginan user tersebut (User Expected), berikut merupakan kesimpulan dan solusi terhadap alur proses yang diharapkan untuk menciptakan alur roses yang lebih efektif dari sebelumnya.

4.1.1 Inbound processing PPDS Akunting Purchasing Warehouse _Warehouse Quality Control Purchase order SI Manufaktur

Permintaan pembelian bahan baku Purchase order

Supplier

Cetak Purchase

Purchase order via fax

AAC formula aktif Order Permintaan Pembelian bahan

barang

Buat BTB Pengajuan quality test Barang

Data barang ACC Otorisasi barang ACC

Data purchase order

pembayaran Otorisasi PPB 1 2 3 4 5 6 7 8 9 11

Gambar 4.1 Inbound Processing Deskripsi :

1. Akunting memberikan ACC terhadap formula request yang diajukan R&D 2. PPDS melakukan Permintaan Pembelian bahan baku pada purchasing,

PPB dibuat berdasarkan :

- Kebutuhan buffer stok warehouse atau,

- Kebutuhan bahan untuk keperluan produksi berdasarkan order

3. Melalui bantuan system, purchasing akan segera mengetahui ada permintaan pembelian, kemudian memilih item bahan yang ada pada PPB, tanpa harus menginputkannya kembali, ini akan menjaga konsistensi data. 4. Purchasing dapat melihat data Perminataan Pembelian Bahan dan purchase

5. Setelah itu purchasing dapat mencetak nota PO 6. Nota PO kemudian diberikan pada supplier.

7. Ketika kedatangan barang, warehouse menerima barang

8. Kemudian membuat BTB (Bukti terima Barang) berdasarkan data PO dalam system.

9. Warehouse mengajukan pengujian barang terhadap Quality Control (QC). Dengan bantuan system , QC dapat mengetahui barang apa saja yang diajukan untuk diauji.

10.Setelah barang dinyatakan ACC , QC memberitahukan warehouse kembali melalui bantuan system untuk mengotorisasi dan melakukan penempatan penyimpanan barang secara data.

11.Setelah warehouse melakukan otorisasi, stok warehouse pada system akan bertambah.

4.1.2 Planning and Production Logistik PPDS _Produksi Warehouse R&D Accounting SI manufaktur Order logistik Standar formula Plotting PPH Denah Mesin Status mesin PPH Booking Order Proses produksi Hasil produksi Tablet

Update status mesin

Formula request ACC formula Keluar barang 1 2 3 4 10 Status mesin 5 6 7 8 9

Gambar 4.2 planning and production Deskripsi :

1. Logistik melakukan order barang dan diinput kedalam system 2. R&D melakukan request formula untuk disetujui accounting.

3. Dengan bantuan system, accounting dapat mengetahui daftar formula request yang harus diotorisasi (acc atau non acc) dan melakukan otorisasi. 4. PPDS mendapatkan informasi order dan formula yang sudah disetuji

Accounting dari system.

5. Setelah itu PPDS membuat plotting terhadap kapasitas mesin berdasarkan order, kapasitas mesin, dan formula standar yang digunakan. Setelah itu terbit PPH dan denah mesin sebagai panduan produksi melakukan kegiatan produksi.

6. Berdasarkan PPH, PPDS melakukan booking terhadap stok agar tidak ada lagi dapat memakai bahan secara

7. Dengan bantuan system, PPDS dapat mengeluarkan perintah warehouse untuk mengeluarkan bahan sesuai dengan booking.

8. Produksi kemudian melakukan proses produksi.

9. Sementara itu eksekutor produksi melakukan update kegiatan yang dilakukan mesin pada saat produksi yang disebut status mesin melalui tablet agar memungkinkan data bersifat realtime.

10.Hasil produksi kemudian diinput ke system.

4.1.3 Outbound Processing

PPDS

Warehouse

Produksi Logistik Quality Control

Perintah pengeluaran bahan

Drop to karantine area Pre BKB

BKB BKB tambahan

BKB kemasan

Hasil produksi

Hasil produksi SI manufaktur

Hasil pengujian

Hasil pengujian

1

2

3

4 5

6

7

Deskripsi :

1. Setelah melalui proses booking, PPH siap diproses karena telah memiliki bahan baku. PPDS sebagai perencanaan dapat memerintahkan produksi untuk melakukan eksekusi terhadap PPH yang telah siap dengan bantuan system.

2. Pada H-1, Warehouse menyediakan barang dan disimpan di area karantina yang dekat dengan lokasi produksi.

3. Pada hari H produksi, warehouse menerbitkan BKB utama dan BKB kemasan serta mengambil bahan dari area karantina untuk dikirim ke produksi dan langsung mengurangi stok warehouse.

4. Hasil produksi akan melewati proses pengujian QC,

5. Hasil pengujian akan disimpan di sistem

6. Produksi dapat mengetahui informasi hasil pengujian, jika visualisasi warna kurang, maka produksi meminta tambahan bahan, untuk barang semi finishgood di delivery order pada warehouse.

7. Namun jika hasil produksi berupa finishgood akan langsung disetorkan pada logistic.

4.2Arsitektur Data

Arsitektur data bertujuan mendefinisikan data yang akan dipakai untuk mengembangkan dan membangun arsitektur aplikasi. Berdasarkan langkah yang ada di EAP, arsitektur data mendefinisikan 2 (dua) hal, yaitu:

1. Kandidat Entitas Data

4.2.1 Kandidat Entitas Data

Kandidat entitas didasarkan pada fungsi bisnis yang ada di organisasi berdasarkan value chain Michael E. Porter yang telah dijelaskan sebelumnya, sehingga diperoleh kandidat entitas utama sebagai berikut :

1. Entitas Inbound processing 2. Entitas Planning and production 3. Entitas outbound processing

Entitas-entitas yang terdefinisi di atas merupakan hasil pendefinisian fungsi bisnis utama berdasarkan rantai nilai sehingga hubungan diantaranya merupakan hubungan antara entitas bisnis dan belum memberikan gambaran mengenai entitas data. Oleh karena itu, perlu adanya penurunan dari entitas bisnis yang diperoleh dari fungsi-fungsi bisnis menjadi entitas data. Berikut ini adalah penurunan dari entitas bisnis untuk memperoleh entitas-entitas data.

Tabel 4.1 Rincian Kandidat Entitas Entitas Bisnis Entitas Data

Inbound Ptocessing

1. Daftar Supplier 2. Daftar Raw material 3. Daftar currency 4. Katagori 5. Jenis 6. Sub Jenis 7. Merk 8. Warna 9. Kemasan 10.Satuan

11.Purchase order (PO) 12.Bukti terima barang (BTB) 13.Pengajuan status uji ( MSU) 14.Pengujian raw material 15.Pengujian semi finishgood

16.Pengujian Finishgood 17.Standar waktu pengujian 18.Komplain supplier 19.Penilaian supplier

Planning and production

20.Jenis order 21.Order Logistik 22.Order PPDS 23.Target Harga 24.Standar Harga 25.Harga RM

26.Grup pelaksana produksi 27.Kalendar kerja

28.Base

29.PPB (Permintaan pembelian Barang) 30.Plotting tonnage

31.Plotting unit 32.Sistem produksi

33.PPH ( Perintah produksi Harian) 34.Booking

35.Denah Mesin

36.Registrasi sample Formula 37.Pengujian sample Formula 38.Worksheet R&D

39.Formulasi

40.Status aktif formula 41.Batch Ticket 42.Status mesin

43.KSP (ketidak sesuaian produksi) 44.Pemakaian BS

45.Retur produksi

46.Laporan hasil produksi

Outbound processing

47.Kategori Gudang 48.Tipe Gudang 49.Sub Gudang 50.Gudang

51.Skala Timbangan 52.Stok Raw material 53.Stok produksi 54.Stok KSP 55.Barang 56.Ukuran 57.Warna 58.Merk 59.Kemasan 60.Jenis BJ

62.Validasi BKB

63.Pembuatan BKB lain – lain 64.BSP ( Bukti setoran Produksii)

4.2.2 Definisi Entitas, Set, Atribut, dan Relasi

Untuk menggambarkan hubungan antar entitas data maka tool yang digunakan adalah ER-Diagram.

4.2.2.1 ER-Diagram inbound processing

PPB memiliki PO memiliki RAW_MATERIAL memiliki MSU memiliki QUALITY_RM memiliki STD_WAKTU_UJI BTB memiliki n 1 1 1 1 n n memiliki SUPPLIER CURRENCY PPB_DET BTB_DET SATUAN KEMASAN WARNA Merk SubJenis JENIS KATEGORI KOMPLAIN_SP Penilaian _supplier PO_DET memiliki memiliki 1 n 1 n 1 memiliki n 1 1 1 1 memiliki 1 n 1 1 1 n n 1 n 1 1 1 memiliki 1 1 n HARGA_RM memiliki TARGET_HARGA 1 1 n

Gambar 4.4 ER-Diagram inbound processing

Skema Diagram dari gambar 4.4 adalah sebagai berikut:

1. _{RAW_MATERIAL { id_bb, id_kategori_bb, kode_bb, kode_barang_jmw,} id_jenis_bb, id_sub_jenis_bb, id_warna_bb, id_kemasan_bb, keterangan_bb, nilai_bb, id_satuan, sat_kg_packaging, stok_min, harga_po, id_currency_po, nama_bb, id_supplier, bb_penyebutan, timbangan_di, id_group_bb,

stok_max, bj_blendo, j_moving_bb, rop, bj, status_aktif, tgl_update, id_user }

2. _{HARGA_RM { id_bb_det, id_bb, id_proses_harga_prc, harga_prc_1,} id_currency_1, harga_prc_2, id_currency_2, harga_prc_3, id_currency_3, harga_prc_4, id_currency_4, harga_prc_5, id_currency_5, harga_prc_6, id_currency_6, harga_prc_7, id_currency_7, harga_prc_8, id_currency_8, harga_prc_9, id_currency_9, id_currency_10, harga_prc_11, id_currency_11, harga_prc_12, id_currency_12, harga_prc_old_12, id_currency_old_12, harga_prc_old_11, id_currency_old_11, harga_prc_old_10,

id_currency_old_10, tgl_update, id_user}

3. _{KATEGORI_BB { id_kategori_bb, kode_kategori_bb, nama_kategori_bb,} status_aktif }

4. _{JENIS_BB{ id_jenis_bb, id_kategori_bb, kode_jenis_bb, nama_jenis_bb,} status_aktif }

5. _{JENIS_BB_SUB {id_sub_jenis_bb, id_kategori_bb, kode_jenis_bb,} kode_sub_jenis_bb, nama_sub_jenis_bb, status_aktif}

6. _{WARNA { id_warna_bb, kode_warna_bb, nama_warna_bb, status_aktif}} 7. _{KEMASAN { id_kemasan_bb, kode_kemasan_bb, nama_kemasan_bb,}

status_aktif)

8. _{CURRENCY { id_currency, currency, nilai_kurs_rp}}

9. _{PPB { id_ppb, no_ppb, tgl_input, tgl_ppb, tgl_pakai, keterangan_ppb,} diajukan, acc_mengetahui, diketahui_oleh, acc_menyetujui, disetujui_oleh, dikirim_ke, status_aktif}

10._{PPB_DET { id_ppb_det, id_ppb, id_bb, id_kemasan_bb, sat_kg_trans,} qty_ppb, status_aktif, untuk, tujuan_ke, tgl_pakai_det, ket_target_datang, keterangan_ppb_det}

11._{SUPPLIER { id_supplier, kode_supplier, nama_supplier, alamat, kota,} telepon, fax, kontak1, kontak2, kontak3}

12._{SATUAN { id_satuan, satuan_bb, bj}}

13._{BTB { id_btb, tax_btb, no_btb, tgl_btb, with_qr, no_surat_jalan, angkutan}} 14. _{BTB_DET { id_btb, id_btb_det, id_po, no_lot, id_kemasan_bb,}

sat_kg_trans, qty_terima, id_currency_btb, harga_btb, id_supplier, id_msu, id_user, id_lokasi, ket_btb}

15. _{QUALITY_RM { id_qr, id_msu_det, tgl_qr, jam_mulai, jam_selesai,} id_user, tgl_exp, bj, ph, warna, bentuk, bau, absorpsi_air, absorpsi_minyak,

viscositas, viscositas_dlmlarutan, kehalusan_visual, kehalusan_dlmlarutan, index_bias, solid_content, moisture_content, we, ye, opacity, strength, keterangan}

16. _{QUALITY_RM_DET { id_qr, id_qr_det, qty_qr, status_qr, status_otorisasi,} id_slot_rak}

17. _{PO { id_po, jenis_po, tax_po, no_po, po_untuk, tanggal_po, id_supplier,} contact_person, syarat_bayar , kirim_ke, tgl_kirim_awal, tgl_kirim_akhir, status_aktif}

18. _{PO_DET { id_po_det, id_po, no_ppb, id_bb, id_kemasan_bb, sat_kg_trans,} qty_po, id_currency_po, harga, ket_po_det}

19. _{MSU { id_msu, no_msu, tgl_msu}}

20. _{MSU_DET { id_msu, id_msu_det, id_btb_det, qr, id_user, id_lokasi}}

4.2.2.1 ER-Diagram Planning and production

ORDER memiliki BARANG ORDER_PPDS Mengacu PLOTTING TONNAGE Mengacu FORMULA memiliki PPH memiliki MEMILIKI Denah mesin memiliki Status mesin memiliki memiliki Mesin memiliki

SYS_PROD Kapasitas mesin memiliki

1 1 1 1 1 1 n 1 n n 1 1 1 1 1 n 1 n n 1 Batch ticket memiliki 1 JENIS_ORDER PPH_DET Base PLOT_UNIT FORMULA_AKTIF DENAH_MESIN_DET STATUS_MESIN_SP 1 memiliki n 1 1 1 n n 1 memiliki 1 n BOOKING_WH MEMILIKI RAW_MATERIAL n 1 memiliki 1 n PELAKSANA 1 memiliki GROUP_PELAKSANA 1 n

Skema Diagram dari gambar 4.5 adalah sebagai berikut:

1. _{JENIS_ORDER { id_jenis_order, kode_jenis_order, nama_jenis_order}} 2. _{ORDER { id_order_log, no_order_log, tgl_awal_order, tgl_akhir_order,}

week_order, keterangan, link_ploting}

3. _{ORDER_DET { id_jenis_order, id_order_det, id_order_log,}

tgl_awal_order, tanggal_akhir_order, kode_barang, jumlah_unit_order, jumlah_dus_order, keterangan_det, jumlah_dus_order_tambah, , jumlah_unit_batal , jumlah_dus_batal, jumlah_unit_adjustment, status_close, tanggal_input, id_sys_prod, id_bases}

4. _{BASE { id_bases, bases_prd, kode_base}} 5. _{SYS_PROD { id_sys_prod, sys_prod}}

6. _{MESIN { id_mesin, jenis_mesin, id_sys_prod, jml_kap_giling, per_hari,} total_hari_schedule, id_bases, urut_mesin, link_ploting, kap_min,

kap_max}

7. _{MESIN_DET { id_tangki, id_mesin, kode_tangki}}

8. _{KAPASITAS_MESIN {id_kap_mesin, id_mesin, kode_barang_jmw,} id_bb, kap_min, kap_max}

9. _{BOOKING_WH { id_pph, id_pph_from, id_bb, id_bb, id_qr, qty_pick,} id_user, tgl_book, jam_book}

10._{PPH { id_pph, no_batch, kode_jenis_pph, id_sys_prod, id_user,}

status_trans, status_print, status_aktif, kode_barang_jmw, id_jenis_order, kode_plot, no_urut_pph, tgl_pph, id_bases, tonage_renc_prod,

tonage_real_prod, tgl_rencana_prd, tgl_rencana_exp, id_pph_from, week_order, keterangan_pph, id_tangki, plot_by, tgl_renc_dm, tgl_dm} 11._{PPH_DET{ id_pph_det, id_pph, kode_barang, id_order_log,}

tgl_order_log, qty_unit, qty_dus, bj, keterangan, status_trans_det, tgl_trans_det, status_aktif}

12._{FORMULA { id_formula, no_formula, id_sys_prod, id_bb, no_rm, no_sf,} uji_coba, ratio_formula, keterangan, status_index, bj_formula, remarks , id_bases, id_satuan, tgl_transaksi, id_user, tgl_dokumen, status,

13._{FORMULA_DET { id_formula_det, id_formula, nama_proses, ik_no,} no_urut, id_bb, id_satuan_det, id_f_chosen, qty_sm, p_jawab, jml_menit, status_aktif, tgl_transaksi, id_user, keterangan_det}

14._{FORMULA_AKTIF { id_formula, id_aktif_f, tgl_aktif, tgl_remove}} 15._{BATCH_TICKET { id_pph, id_formula_det, id_bb, qty_need,}

qty_booked}

16._{QUALITY_SF {no_batch, tgl_pph,kode_pasta,tgl_mulai, tgl_selesai,} jam_mulai, jam_selesai}

17._{QUALITY_SF_DET { status_sf,warna_sf,visc_sf, catatan_sf, tgl_mulai,} tgl_selesai, jam_mulai, jam_selesai}

18._{QUALITY_FG {no_batch, tgl_pph, no_mesin, kode_jens, kode_merk,} kode_warna, kode_cat, tgl_mulai, tgl_selesai, jam_mulai, jam_selesai} 19._{QUALITY_FG_DET {status_sf,warna_sf,visc_sf, catatan_sf, tgl_mulai,}

tgl_selesai, jam_mulai, jam_selesai}

20._{PLOTTING { id_order_log, tgl_awal_order, tanggal_akhir_order,} kode_barang, kode_barang_jmw, jumlah_unit_order, netto, tonnage, mesin, no, plot, sys_prod, sts_plot, kode_base_jmw, total_f, keb_base_f, qty_base, jumlah_dus_order, keterangan_det, jumlah_unit_order_tambah, jumlah_dus_order_tambah, plot by}

21._{PLOTTING_UNIT {no_batch, kode_barang, plot_tonnage,presentasi,} netto, plot_unit, tonnage}

22._{DENAH_MESIN {id_mesin, tanggal_awal, tanggal_akhir, id_tanki}} 23._{DENAH_MESIN_DET { id_pph, tgl_rencana, tgl_realisasi, id_mesin,}

kode_barang, no_batch, kode_base, mesin_detail, status, id_tanki} 24._{STATUS_MESIN {id_user, id_pph, id_mesin, id_tanki, kode_barang,}

no_batch, no_batch_base, kode_base, jumlah, waktu, jam_mulai, jam_selesai, id_sts_msn_sp, keterangan}

25._{STATUS_MESIN_SP { id_sts_msn_sp, urutan_prs, id_bases,} id_sys_prod, waktu_prs}

26._{GROUP_PELAKSANA { id_group_pelaksana, desc_group, nik,} status_aktif}

27._{PELAKSANA { id_pelaksana_det, id_pph, id_pelaksanaan,} id_group_pelaksana, nik }

4.2.2.3 ER- Diagram Outbound processing BKB ISA BKB_KEMASAN BSP ISA RAW_MATERIAL n 1 BARANG memiliki memiliki 1 1 UKURAN Warna MERK KEMASAN JENIS JENIS_GUDANG KATEGORI_GUDANG SUB_GUDANG GUDANG STOK_PROD n memiliki memiliki TARGET_PRICE memiliki n n n 1 1 1 1 1 memiliki 1 n n memiliki 1 n memiliki 1 n 1 BKB memiliki 1 n 1 1 1 memiliki n 1 memiliki 1 1

Gambar 4.6 Outbound processing

Skema Diagram dari gambar 4.6 adalah sebagai berikut:

1. BKB { id_bkb, id_pph, tgl_bkb, status_aktif, status_periksa}

2. BKB_DET { id_bkb, id_bb, sat_kg_trans, id_qr, qty_pick, check_k, percent_bc, check_valid, qty_valid, check_otorisasi, id_pph_from, tgl_k, tgl_valid, tgl_otorisasi}

3. BARANG { kode_barang, kode_jenis , kode_merk, kode_kemasan, kode_ukuran, kode_warna, nama_barang, kode_ekivalen1,

kode_ekivalen2, kode_volume, netto, brutto, id_user, status_aktif} 4. JENIS {kode_jenis, nama_jenis, status_aktif}

5. KEMASAN { kode_kemasan, nama_kemasan, status_aktif} 6. MERK { kode_merk, nama_merk, status_aktif}

7. UKURAN { kode_ukuran, nama_ukuran, status_aktif}

8. WARNA { kode_warna, kode_jenis, kode_merk, nama_warna, status_aktif}

9. KATEGORI_GUDANG{id_kategori_gudang,nama_kategori_gudang, status_aktif}

10.JENIS_GUDANG {id_kategori,_gudang, id_jenis_gudang, nama_jenis_gudang, status_aktif}

11.GUDANG { id_gudang, nama_gudang, jenis_gudang, luas, volume, jml_pintu, status_aktif, id_kategori_gudang, status_gudang, ket_gudang} 12.SUB_GUDANG{ id_gudang_sub, id_gudang, nama_gudang_sub,

status_aktif}

13.BSP { id_bsp, no_bsp, tgl_bsp, id_dept, id_status_git, status_aktif, id_slot_rak_asal, status_periksa}

14.BSP_DET { id_bsp_det, id_bsp, id_order_log, id_pph, kode_barang, id_bb, qty_bsp_unit, qty_bsp_dus, valid, qty_bsp_unit_valid,

qty_bsp_dus_valid, keterangan}

15.STOK_PRD { id_stok_prd, status_trans, tgl_trans, id_dept, id_lokasi, id_pph, id_order_log, kode_barang, qty_dus, qty_unit}

4.3Arsitektur Aplikasi

Pada tahap arsitektur aplikasi dilakukan beberapa tahap seperti berikut : 1. Membuat daftar kandidat modul aplikasi, Tools yang dipakai untuk

mendefinisikan kandidat aplikasi adalah Applications Portfolio.

2. Software planning , memberikan usulan migrasi aplikasi untuk masa datang sesuai dengan kebijakan perusahaan.

3. Membuat diagram interaksi user dan system ( usecase diagram ), sehingga dapat diketahui fungsi system yang diharapkan di masa datang.

4.3.1 Kandidat Modul Aplikasi bedasarkan Applications Portfolio

Berdasarkan fungsi bisnis yang terdaftar, berikut kandidat modul pada aplikasi berdasarkan application portfolio, yang dapat dijelaskan seperti dibawah ini.

1. Kuadran I, Strategic Applications:

- Komplain supplier - Penilaian supplier - Harga RM

- Target Harga - Standar Harga - Worksheet R&D - Laporan hasil produksi

2. Kuadran II, Key Operasional Applications :

- Pendaftaran data Supplier - Pendaftaran data Raw material - Pendaftaran data Kemasan - Pendaftaran data Satuan - Pendaftaran data base - Grup pelaksana produksi - Purchase order (PO) - Bukti terima barang (BTB) - Pengajuan status uji ( MSU) - Pengujian raw material

- Pengujian semi finishgood - Pengujian Finishgood

- Order Logistik - Order PPDS

- Permintaan Pembelian Barang (PPB) - PPH ( Perintah produksi Harian) - Denah Mesin

- Bukti Keluar Barang (BKB) - formulasi

- Status mesin - Stok Raw material - Stok produksi

- BSP ( Bukti setoran Produksii) 3. Kuadran III, Support Applications :

- Kalendar kerja

- Registrasi sample Formula - Pengujian sample Formula - Pendaftaran data Barang - Standar waktu pengujian

4. Kuadran IV, High Potential Applications :

- Booking

- Plotting Tonnage - Plotting unit

- Batch Ticket - Status aktif formula - Pendaftaran data currency - Pendaftaran data Gudang - Manajemen hak akses user

Tabel 4.2. Application Portfolio PT.RH

Strategic Applications High Potential Applications

Komplain supplier √ Penilaian supplier√ Harga RM√

Target Harga √ Standar Harga√ Worksheet R&D √

Booking ✉

Plotting Tonnage ✉ Plotting unit ✉ Batch Ticket ✉ Status aktif formula ✉ Pendaftaran data Gudang * Management Hak akses user✉

Key Operasional Applications Support Applications

Pendaftaran data Supplier√ Grup pelaksana produksi √ Pendaftaran data Raw material* Pendaftaran data Kemasan√ Pendaftaran data Satuan√ Pendaftaran data base√ Pendaftaran data Barang√

Purchase order (PO) * Bukti terima barang (BTB) * Pengajuan status uji ( MSU) ✉ Pengujian raw material√ Pengujian semi finishgood√ Pengujian Finishgood√ Order Logistik √

Order PPDS√

Permintaan Pembelian Barang (PPB) *

PPH (Perintah produksi Harian) * Denah Mesin *

BKB* Formulasi * Status mesin * Stok Raw material√ Stok produksi√

BSP ( Bukti setoran Produksi) √

Kalendar kerja √

Registrasi sample Formula✉ Pengujian sample Formula✉ Standar waktu pengujian ✉

Keterangan:

√ : Modul Aplikasi yang sudah berjalan, tetapi dibutuhkan re-design (data dan aplikasi)

*: Modul Aplikasi yang dilakukan proses pengembangan

✉ : Modul Aplikasi yang direncanakan

Pengelompokan di atas berdasarkan pada:

1. Modul-modul aplikasi yang telah teridentifikasi di atas didasarkan dari aktivitas utama yang digambarkan dengan value chain.

2. Modul aplikasi strategis yang dibutuhkan untuk keberhasilan bisnis pada masa mendatang dimasukkan pada kuadran strategic application. Modul aplikasi yang sudah ada dan mendukung operasional organisasi dimasukkan pada kuadran key operational.

3. Modul aplikasi yang sifatnya penting tapi jika dibandingkan dengan aktivitas lain dapat dikatakan memiliki tingkat kepentingan yang sedikit lebih kecil, dikelompokkan pada kuadran support Apllication. Modul aplikasi yang bersifat inovatif yang mungkin dapat memperbesar peluang peningkatan keuntungan dimasa yang akan datang, dikelompokan pada kuadran high potential application.

Berdasarkan application portfolio di atas, dapat dikelompok ke dalam beberapa kelompok berdasarkan kondisi yang ada, seperti tampak tabel 4.3:

Tabel 4.3. Kandidat Aplikasi Berdasarkan Status

STATUS MODUL APLIKASI

Modul Aplikasi yang sudah berjalan, tetapi dibutuhkan re-design (data dan aplikasi)

1. Komplain supplier √ 2. Penilaian supplier√ 3. Harga RM√

4. Target Harga √ 5. Standar Harga√ 6. Worksheet R&D √

7. Pendaftaran data Supplier√ 8. Pendaftaran data Kemasan√ 9. Pendaftaran data Raw material√ 10.Pendaftaran data base√

11.Pengujian raw material√ 12.Pengujian semi finishgood√ 13.Pengujian Finishgood√ 14.Order Logistik √

15.Order PPDS√ 16.Stok Raw material√ 17.Stok produksi√

18.Pendaftaran data Barang√ 19.Grup pelaksana produksi √ 20.Kalendar kerja √

Modul Aplikasi yang direncanakan 1. Standar waktu pengujian ✉ 2. Booking ✉

3. Plotting Tonnage ✉ 4. Plotting unit ✉ 5. Batch Ticket ✉ 6. Status aktif formula ✉

7. Pengajuan status uji ( MSU) ✉ 8. Registrasi sample Formula✉ 9. Pengujian sample Formula✉ Modul Aplikasi yang dilakukan proses

pengembangan

1. Pendaftaran data Raw material* 2. Purchase order (PO) *

3. Bukti terima barang (BTB) * 4. Permintaan Pembelian Barang

(PPB) *

5. PPH (Perintah produksi Harian) 6. Denah Mesin *

7. BKB 8. Formulasi * 9. Status mesin *

10.Pendaftaran data Gudang *

Berdasarkan tabel 4.3 dapat diidentifikasi 39 (tiga puluh sembilan ) modul aplikasi yang mendukung fungsi bisnis organisasi, 20 modul aplikasi yang sudah berjalan dan dibutuhkan re-design (data dan aplikasi), 10 modul aplikasi yang dilakukan proses pengembangan dan 9 modul aplikasi yang direncanakan,

4.3.2 Software Planning

Disesuaikan dengan kebijakan perusahaan, yaitu suatu saat memungkinkan untuk migrasi terhadap sistem operasi opensource ( Linux), maka berikut adalah software yang disarankan untuk digunakan untuk pengembangan aplikasi manufaktur :

Tabel 4.4 software planning Software

PHP Oracle DB

Berikut beberapa alasan yang telah disesuaikan dengan kebijakan perusahaan mengenai mengapa harus menggunakan PHP :

1. PHP adalah bahasa open source yang dapat digunakan di berbagai mesin (Linux, Unix, Macintosh, Windows) dan dapat dijalankan secara runtime melalui console serta juga dapat menjalankan perintah-perintah system. 2. Open Source , gratis dan dapat diinstal tanpa harus membayar apapun. 3. HTML Integrasi: Kode PHP dapat dengan mudah tertanam dalam kode

HTML dan ini memungkinkan server untuk memproses web tertentu pager bahkan sebelum ditampilkan pada browser web dan juga hasil pemrosesan lebih cepat.

4. Web Server yang mendukung PHP dapat ditemukan dimana - mana dari mulai apache, IIS, Lighttpd, hingga Xitami dengan konfigurasi yang relatif mudah.

Berikut beberapa alasan yang telah disesuaikan dengan kebijakan perusahaan, mengenai mengapa harus menggunakan Oracle :

1. Merupakan software DBMS yang handal dan memiliki kemampuan yang tinggi.

2. Dapat menangani jumlah data dalam ukuran yang besar.

3. Dapat mengolah data dalam ukuran besar dan mengolahnya dengan cepat sehingga didapatkan informasi yang akurat sesuai permintaan pengguna/user.

4. Memiliki kemampuan akan fleksibilitas dan skalabilitas yang dapat memenuhi tuntutan akan data dan informasi yang bervolume besar dan terus-menerus bertambah besar.

5. Memiliki kemampuan untuk management user dan tiap user bisa diatur hak akses terhadap suatu database oleh database administrator.

6. Bisa berjalan pada lebih dari satu platform system operasi. 7. Pemrosesan data yang sangat cepat, open source.

8. Ketika kita mengakses database dan kemudian ada kejadian seperti listrik mati misalnya maka data yang sudah kita simpan tidak rusak/hilang. Oracle memiliki kemampuan flashback, sehingga semua jenis transaksi yang salah akan dapat dikembalikan. Dan dapat menampung data dalam sekala besar.

4.3.3 Usecase Diagram

Diagram yang menggambarkan interaksi antara system dan user, dan fungsi yang diharapkan dalam system aplikasi. Alur proses yang diharapkan dapat dilihat secara jelas dalam penggambaran usecase berikut ini :

4.3.3.1Inbound processing

Proses penerimaan atau inbound processing adalah pintu utama penerimaan barang agar mendapatkan barang yang sesuai dengan standar kualitas perusahaan. Berikut alur proses yang diharapkan agar manajemen penerimaan barang PT.RH dapat berlangsung dengan baik digambarkan dalam Usecase Inbound Processing :

Tabel 4.3 usecase specification create PPB

Use case Specification

Name Use case Create PPB (Permintaan Pembelian Barang) Primary actor PPDS, Purchasing

Preconditions Bahan baku telah terdaftar

Success guarantee Data PPB berhasil diinput dan diberi nomor PPB otomatis, seta list data PPB dapat dilihat oleh purchasing

Main flow PPDS memasukan data bahan kebutuhan yang akan diajukan untuk dibeli kepada purchasing.Setelah selesai PPB diajukan pada purchasing untuk di-review dan diberi otoritas.

Tabel 4.4 usecase specification PPB otorisation

Use case Specification

Name Use case PPB Otorisation Primary actor Purchasing

Preconditions PPDS telah mengajukan PPB yang berstatus pending Success guarantee Otorisasi purchasing dapat dilakukan tiap item barang pada

PPB

Main flow PPDS membuat PPB, kemudian diajukan pada purchasing dengan notifikasi. Purchasing dapat langsung membuka notifikasi dan melakukan otorisasi tiap item PPB. Alternate flow Purchasing membuka list PPB yang berstatus pending,

kemudian melakukan otorisasi.

Tabel 4.5 usecase specification create PO

Use case Specification

Name Use case Create PO(Purchase order) Primary actor Purchasing

Preconditions PPB telah diotorisasi,data supplier telah tersedia Success guarantee Data PPB dan data PO terintegrasi

Main flow Pada saat membuat PO, purchasing hanya tinggal memilih no PPB dan menginput data supplier

Tabel 4.6 usecase specification BTB

Use case Specification

Name Use case BTB (Bukti terima barang) Primary actor Warehouse

Preconditions Penerimaan barang berdasarkan PO Success guarantee Data PO dan Data PPB terintegrasi

Main flow Pada saat kedatangan barang, Warehouse menerima kedatangan barang berdasarkan data PO. Tetapi barang belum bertambah menjadi stok perusahaan dan masih berada pada area penerimaan (receiving area). Sehingga BKB pada tahapan penerimaan ini berstatus BTB receiving. Alternate flow -

Tabel 4.7 usecase specification MSU

Use case Specification

Name Use case MSU (Minta Status Uji) Primary actor Warehouse, QC

Preconditions BTB status receiving diajukan untuk diuji oleh QC

Success guarantee Data BTB dan MSU terintegrasi, Notifikasi Warehouse ke QC

Main flow Warehouse memilih BTB status receiving untuk diajukan dilakukan proses pengujian terhadap QC

Alternate flow -

Tabel 4.8 Usecase Specification Quality Status

Use case Specification

Name Use case Quality status Primary actor QC

Preconditions QC melalukan pengujian terhadap barang yang telah diajukan warehouse pada MSU dengan system sampling. Success guarantee QC dapat menginput data hasil pengujian dan memberikan

no status quality.

Main flow QC mendapat notifikasi MSU, melakukan pengujian

berdasarkan MSU dan menginputkan hasil pengujian quality status. Pada detail Quality status QC menentukan status barang (ACC, ACC bersyarat atau tidak ACC)

Alternate flow QC membuka list MSU dan melakukan pengujian terhadap MSU yang berstatus

Tabel 4.9 Usecase Specification BTB change status

Use case Specification

Name Use case BTB change status Primary actor QC, Warehouse

Preconditions Setelah pengujian selesai, barang harus diotorisasi kembali oleh warehouse.

Success guarantee Barang berstatus ACC dan ACC bersyarat otomatis menambah jumlah stok barang warehouse

Main flow Barang hasil pengujian yang telah memiliki no quality status diajukan melalui notifikasi terhadap warehouse untuk diotorisasi, warehouse langsung menentukan penempatan penyimpanan dan stok otomatis bertambah.

Alternate flow -

4.3.3.2 Planning Production

Gambar 4.8 Usecase Planning and production Processing

Tabel 4.10 Usecase Specification Upload order

Use case Specification

Name Use case Upload Order Primary actor Logistic

Preconditions Logistik melakukan perkiraan order cat pada excel Success guarantee Order cat/ barang jadi dapat terunggah pada system Main flow Logistik mengunggah dokumen excel pada system agara

dapat diolah kembali oleh PPDS Alternate flow -

Upload order

Logistic

Standard Formula _R&D Breakdown order

<<include>>

Plotting

<<include>>

PPH

Booking PPDS

Tabel 4.11 Usecase Specification Breakdown order

Use case Specification

Name Use case Breakdown order Primary actor PPDS

Preconditions Logistik upload order

Success guarantee PPDS membuat order per minggu

Main flow Dari order yang telah di upload oleh logistic, PPDS menyederhanakan order tersebut menjadi per minggu Alternate flow -

Tabel 4.12 Usecase Specification Standard Formula

Use case Specification

Name Use case Standard formula Primary actor R&D , Accounting

Preconditions Karena ketersediaan bahan yang tidak pasti, R&D harus selalu mengembangkan penelitian untuk menemukan komposisi formula tepat dan formula pengganti. Setelah R&D melakukan formula percobaan, maka formula tersebut diajukan sebagai formula request terhadap accounting, jika disetujui formula tersebut berubah status menjadi standard formula

Success guarantee Tampil daftar formula beserta statusnya dan formula dapat dipakai jika telah berstatus standar.

Main flow R&D membuat formula percobaan (formula status percobaan), diajukan terhdap accounting (formula request), accounting melakukan perhitungan di worksheet untuk mengetahui kesesuaian harga, jika disetujui formula berstatus standard (formula standard) dan dapat dipakai dalam produksi barang.

Alternate flow -

Tabel 4.13 Usecase Specification Plotting

Use case Specification

Name Use case Plotting Primary actor PPDS

Preconditions Data mesin, kapasitas mesin, system produksi telah tersedia Success guarantee Sistem dapat melakukan ploting order terhadap mesin secara

otomatis

Main flow Order yang telah di-break down oleh PPDS secara otomatis memiliki standard formula dan dilakukan proses plotting otomatis dengan mempertimbangkan kapasitas mesin dan

system produksi, sehingga menghasilkan data banyaknya bahan yang harus diproses di mesin dan system produksi yang digunakan.

Alternate flow -

Tabel 4.14 Usecase Specification

Use case Specification

Name Use case PPH (Perintah Produksi Harian) Primary actor PPDS

Preconditions Plotting dilakukan system batch,

Success guarantee PPH dapat dibuat secara otomatis dari plotting dan dapat dicetak

Main flow Proses produksi dalam satu batch menjadi satu no batch PPH, Tiap no batch PPH memiliki kuantitas barang yang harus dihasilkan. Oleh karena itu PPH merupakan acuan setiap proses atau hasil dalam produksi. Setelah dipastikan No batch PPH siap untuk produksi (bahan tersedia) maka PPH dicetak dan diberikan kepada produksi sebagai perintah dan acuan produksi.

Alternate flow -

Tabel 4.15 Usecase Specification Booking

Use case Specification

Name Use case Booking Primary actor PPDS

Preconditions Dari PPH dan standar formula, tiap no batch PPH memiliki kebutuhan bahan bakunya masing – masing

Success guarantee

Main flow Agar tidak terjadi kondisi ketika akan melakukan proses produksi pada hari H, tetapi bahan baku tidak tersedia karena dipakai oleh order unplan, maka perlu pengamanan pemakaian bahan baku secara data sejak awal. PPDS mem- booking bahan baku sesuai dengan kebutuhan dan akan mengurangi stok free ( stok keseluruhan = stok free+stok booking), sehingga ketika melihat stok untuk kebutuhan PPH yang lain, akan ditampilkan stok free.

Tabel 4.16 Usecase Specification Batch Ticket

Use case Specification

Name Use case Batch Ticket Primary actor PPDS, Produksi

Preconditions Dari data formula dan order, dihasilkan kebutuhan baku Success guarantee Mencetak batch ticket

Main flow Kebutuhan baku disusun dengan urutan proses pencampuran bahan baku pada mesin berdasarkan standar formula

4.3.4 Production processing

4.9 Gambar Production Processing

Tabel 4.17 Usecase Specification Denah Mesin

Use case Specification

Name Use case Denah mesin Primary actor PPDS, Produksi

Preconditions PPH telah siap, booking telah terealisasi menjadi pengeluaran bahan

Success guarantee Menampilkan data dari PPH ke denah mesin

Main flow H-2 Produksi, PPH yang telah siap akan diantrikan terhadap mesin (denah mesin) pada denah mesin dapat dilihat rencana dan realisasi produksi mesin serta dapat dimonitoring status batch pada mesin

Tabel 4.18 Usecase Specification Status mesin

Use case Specification

Name Use case Status mesin Primary actor PPDS, Produksi

Preconditions No batch PPH yang berada di denah mesin, merupakan no batch PPH yang harus terealisasi diproduksi

Success guarantee update status mesin secara realtime dan data status mesin terintegrasi dengan data status mesin.

Main flow No batch PPH diproduksi, update setiap tahapan proses yang terjadi pada mesin secara realtime dapat diinformasikan pada denah mesin, agar dapat dimonitoring oleh PPDS

Alternate flow -

Tabel 4.19 Usecase Specification Hasil produksi

Use case Specification

Name Use case Hasil produksi Primary actor Produksi

Preconditions No batch yang telah terealisasi diproduksi, menghasilkan hasil produksi yang dapat dibedakan menjadi 2 ; semi finishgood dam finishgood.

Success guarantee Menambah stok

Main flow Hasil produksi harus di setorkan sebagai setoran produksi. Alternate flow -

Tabel 4.20 Usecase Specification Semi finishgood

Use case Specification

Name Use case Semi finishgood Primary actor Produksi

Preconditions Semi finishgood merupakan jenis hasil produksi yang disetorkan pada warehouse untuk dipakai kembali dalan proses produksi selanjutnya.

Success guarantee BSP dapat menambah stok semifinishgood pada stok WH Main flow Hasil produksi semi finishgood di setorkan sebagai setoran

Tabel 4.21 Usecase Specification Finishgood

Use case Specification

Name Use case Finishgood Primary actor Produksi

Preconditions finishgood merupakan jenis hasil produksi yang disetorkan pada warehouse untuk dipakai kembali dalan proses produksi selanjutnya

Success guarantee BSP dapat menambah stok finishgood pada stok WH

Main flow Hasil produksi finishgood di setorkan sebagai setoran produksi ke logistik.

Alternate flow -

Tabel 4.22 Usecase Specification Quality test

Use case Specification

Name Use case Quality Test Primary actor QC

Preconditions Hasil produksi sebelum di setorkan menjadi setoran produksi, harus melewati pengujian terlebih dahulu.

Success guarantee Menginput hasil pengujian danmelakukan printing

Main flow Hasil produksi kemudian diuji oleh QC untuk kesesuaian warna dan kualitas, jika sesuai maka disetorkan kepada warehouse atau logistic

Alternate flow -

Tabel 4.23 Usecase Specification Dashboard Communication

Use case Specification

Name Use case Dashboard Communication Primary actor Manajer

Preconditions Rekap hasil produksi dari status mesin

Success guarantee Menampilkan laporan hasil produksi dalam chart bar

Main flow Dashboard communication merupakan sub aplikasi yang diperuntukan untuk manajer, dimana didalamnya berisi laporan realtime yang disajikan dalam chartbar dan memungkinkan untuk dikembangkan selanjutnya menjadi ranah komunikasi antar manajer.

Tabel 4.24 Usecase Specification Sticky Note

Use case Specification

Name Use case Sticky Note Primary actor Manajer

Preconditions Dashboard communication selain untuk data reporting juga digunakan sebagai ranah komunikasi manajer, dimana didalamnya manajer dapat berkomunikasi melalui note. Success guarantee Para manajer dapat saling berkomunikasi dengan dashboard

communication, dimana pesan dalam note tidak dapat dihilangkan sebelum ada perlakuan dari penerima pesan. Hal ini agar manajer tidak perlu khawatir jika pesan pentingnya akan terlewatkan oleh penerima pesan.

Main flow Pengirim pesan masuk ke dalam sub menu dashboard, membuat sticky note dan dapat mengirimkannya antar manajer yang berkepentingan

Alternate flow -

4.3.5 Outbound Processing

Tabel 4.25 Usecase Specification BKB

Use case Specification

Name Use case BKB

Primary actor PPDS, Warehouse

Preconditions Setelah dilakukan booking penuh terhadap bahan berdasarkan no batch PPH pada perencanaan H-2 produksi. Maka akan dibuat BKB secara dokumen.

Success guarantee Notifikasi BKB realisasi ke Warehouse, realisasi

Main flow PPDS memberikan notifikasi pada warehouse untuk menyiapkan bahan yang akan dipakai produksi pada area karantina dan belum memotong stok warehouse. Setelah siap di area karantina warehouse memberikan notifikasi pada PPDS, dan setelah itu PPDS memerikan notifikasi jika bahan harus dikirimkan ke produksi untuk realisasi produksi.

Alternate flow -

Tabel 4.26 Usecase Specification BKB utama

Use case Specification

Name Use case BKB Utama Primary actor Warehouse, PPDS

Preconditions Setelah dilakukan full booking,terbit BKB yang terdiri dari BKB utama dan BKB tambahan

Success guarantee BKB utama dan BKB tambahan menggunakan 1 Tabel yaitu, Tabel BKB

Main flow BKB yang keluar pertama kali, diberikan no urut 1 sehingga yang mempunyai no urut 1 merupakan BKB utama

Alternate flow -

Tabel 4.27 Usecase Specification BKB tambahan

Use case Specification

Name Use case BKB Tambahan Primary actor Warehouse,PPDS

Preconditions Bahan pada kenyataan di lapangan, khusus untuk colorant dapat dikeluarkan minimal 70% dari jumlah formula yang seharusnya dikeluarkan. Jika kurang maka akan ditambah lagi sampai dengan mencapai 100%

Success guarantee Insert terhadap Tabel BKB

Main flow Setelah dilakukan full booking,terbit BKB yang ber-nomor urut 1, jika ketika pengujian oleh QC dinyatakan ada

kekurangan maka QC akan menganjurkan penambahan suatu bahan. Dengan persetujuan PPDS, maka akan terbit BKB tambahan dengan no urut 2 dan seterusnya.

Alternate flow -

Tabel 4.28 Usecase Specification BSP

Use case Specification

Name Use case BSP (Bukti Setoran Produksi) Primary actor Produksi, warehouse, logistic

Preconditions Hasil produksi disetorkan sesuai dengan jenis hasil produksinya

Success guarantee Insert into BSP Tabel dan menambah stok

Main flow Hasil produksi dapat berupa tonnage disetorkan ke warehouse dan menambah stok WH, sedangkan finishgood dalam bentuk unit disetorkan pada logistik untuk kemudian didistribusikan.

Alternate flow -

4.3.6 User privilege Management

Gambar 4.11 User Privilege management

R&D

Warehouse

Purchasing

QC

Accounting

Production User Register

Hirarki menu Admin

User privilage Register <<include>>

Tabel 4.30 Usecase Specification User register

Use case Specification

Name Use case User register Primary actor Admin

Preconditions Untuk mengakses aplikasi, user harus memasukan username dan password

Success guarantee Insert to Tabel user

Main flow User dari setiap departement didaftarkan dan diberikan password untuk login

Alternate flow -

Tabel 4.31 Usecase Specification menu hierarchy

Use case Specification

Name Use case Menu hierarchy Primary actor Admin

Preconditions Pengaturan tampilan menu pada aplikasi disesuaikan dengan privilege dari masing-masing user.

Success guarantee Menu tampil sesuai dengan privilege user

Main flow Menu dikelompokan berdasarkan hirarchynya. Setiap account user memiliki pengaturan tampilan menu dengan men-checklist menu apa saja yang dapat tampil pada hirarchy menu, ketka masing – masing user login.

Tabel 4.32 Usecase Specification user privilege register

Use case Specification

Name Use case User privilege register Primary actor Admin

Preconditions Menu tampil sesuai dengan privilege user, tetapi didalam sub menu terdapat lagi privilege behaviour, seperti edit, update atau pun delete.

Success guarantee User privilege dalam behaviour data dapat berfungsi

Main flow Tiap account user memiliki daftar behaviour apa saja yang boleh dilakukan tiap sub menu. Dan flexible dapat dipasang ataupun dihapus

4.4Arsitektur Teknologi

Pada tahapan ini pengembangan arsitektur teknologi yang diusulkan ditekankan pada kemampuannya untuk mendukung aplikasi yang diusulkan. Pada dasarnya arsitektur teknologi PT.RH sudah cukup menunjang, namun ada beberapa pengembangan untuk mendukung aplikasi yang diusulkan seperti, membuat jaringan wireless pada area produksi untuk memungkinkan distribusi data secara realtime.

router switch switch Server Converter Converter switch Converter Converter switch Converter Converter LOGISTIK WAREHOUSE QC PURCHASING switch Converter PPDS Converter switch Converter PRODUKSI Converter switch Converter Converter R&D switch ACCOUNTING Converter Converter WiFI Tablet Server Server Area produksi

4.6.1 Rencana Urutan Implementasi Aplikasi

Hubungan antara aplikasi dengan entitas data yang disajikan pada matriks aplikasi terhadap data, merupakan suatu hasil dari arsitektur aplikasi yang mempunyai manfaat, antara lain :

1. Karena seluruh aktivitas utama manufaktur sedikit banyaknya akan mengalami migrasi baik struktur atau pun atribut datanya, maka seluruh modul aplikasi akan menjadi kandidat untuk urutan proses implementasi.

2. Dapat digunakan untuk membuat urutan modul aplikasi yang akan dibangun dengan acuan bahwa modul aplikasi yang menghasilkan data harus diimplementasikan terlebih dahulu dari pada aplikasi yang akan menggunakan/membutuhkan data.

Aplikasi yang telah diurutkan dikelompokkan menjadi roadmap

implementasi, data depedency bukan merupakan satu-satunya penentu urutan

aplikasi yang harus dibangun ada faktor lain yang dapat dipertimbangkan, antara lain : kebutuan, manfaat, resiko dan dampaknya terhadap organisasi dapat dijadikan acuan berikutnya dalam implementasi modul aplikasi. Urutan modul aplikasi dapat setelah dirasionalisasi terhadap kebutuhan, sebagai berikut :

98 Gambar 4.13 Rencana implementasi

99 5.1 Kesimpulan

Berdasarkan tahapan yang telah dilakukan pada bab sebelumnya, maka dapat diambil kesimpulan sebagai berikut :

1) Berhasil membuat blueprint (arsitektur data, aplikasi, dan teknologi) yang

merupakan landasan perbaikan dan pengembangan sistem informasi manufaktur pada PTRH.

2) Dengan adanya perencanaan arsitektur data, dapat memberikan landasan kebutuhan data dan integritas data bagi pengembangan system informasi perusahaan yang mampu memberikan solusi sebagai berikut :

a. Dengan perencanaan kebutuhan dan integritas data, maka data yang dihasilkan akan konsisten dan ketersediaan data ketika dibutuhkan. b. Melalui analisa data, dapat memberikan rujukan efektifitas proses

bisnis perusahaan.

3) Memberikan gambaran perencanaan aplikasi yang dapat dijadikan landasan pengembangan aplikasi perusahaan dengan memberikan dokumentasi dan rujukan sebagai berikut :

a. Arsitektur aplikasi yang terdiri dari 39 (tiga puluh sembilan ) modul aplikasi yang mendukung fungsi bisnis organisasi, 20 modul aplikasi yang sudah berjalan dan dibutuhkan re-design (data dan aplikasi), 10

modul aplikasi yang dilakukan proses pengembangan dan 9 modul

aplikasi yang direncanakan

b. Usecase diagram yang dapat menggambarkan interaksi antara user dan

dan system

c. Dengan aplikasi yang direncanakan dapat memberikan solusi

paperless untuk mengurangi biaya tambahan perusahaan yang harus

dikeluarkan.

4) Perencanaan arsitektur teknologi yang terdiri dari penggambaran

workstation konseptual dan kebutuhan hardware perusahaan. Teknologi

yang diusulkan penulis telah dapat mendukung kebutuhan data secara real

time.

5) Selain itu, pembuatan dokumentasi system informasi yang sedang berjalan dapat menjadi referensi perusahaan, mengapa memerlukan perencanaan pengembangan system informasi. Dokumentasi yang dihasilkan diantanya adalah sebagai berikut :

a. BPMN menggambarkan proses bisnis yang sedang terjadi saat ini pada setiap bagian dalam perusahaan. Selain itu BPMN juga dapat memberikan informasi aktifitas perusahaan yang masih dilakukan manual.

b. Katalog sumber daya informasi yang terdiri dari 3 aplikasi utama (G3 distribusi, PTRH, HRIDS) dan 2 aplikasi pendukung (Ms.Excel, MS.Words)

5.2 Saran

1) Penelitian terhadap arsitektur enterprise PTRH sebaiknya dilakukan

sampai dengan tahap perencanaan migrasi mengingat migrasi yang dilakukan secara besar, artinya hampir membangun ulang semua modul aplikasi yang ada di dalamnya.

2) Karena perencanaan dilakukan bertahap, setelah kegiatan utama berhasil direncanakan sebaiknya tahap kedua dapat dilanjutkan pada modul accounting untuk perhitungan hagra pokok produksi (HPP) beserta laporan dan monitoring yang dibutuhkan accounting.

3) Setelah tahap kedua berhasil direncanakan, maka tahap selanjutnya dapat dilanjutkan pada tahap perencanaan aktifitas pendukung perusahaan.

CURRICULUM VITAE

Personal Particulars

Full Name : Ajeng Rahayu Ambarwangi

Place, Date of Birth : Subang, June 27th, 1988

Sex : Female

Marital Status : Single

Height / Weight : 159 Cm / 47 Kg

Religion : Islam

Nationality : Indonesia

Address : Jl. Dipati Ukur No 43 Bandung