INTEGRASI PERANGKAT LUNAK ENTERPRISE RESOURCE PLANNING (ERP) DENGAN MENGGUNAKAN METODE SERVICE ORIENTED ARCHITECTURE (SOA) Safuwan, Riyanarto Sarno, Rizky Januar Akbar Jurusan Teknik Informatika, Fakultas Teknologi Informasi, Institut Teknologi Sepuluh Nopember Email : safuwan@gmail.com, riyanarto@gmail.com, ricesky@yahoo.com Abstrak - Integrasi sistem merupakan kebutuhan penting dalam proses bisnis yang komplek dari perusahaan. Dengan mengintegrasikan berbagai macam sistem yang berbeda diharapkan proses kontrol terhadap suatu proses bisnis dapat dilakukan dengan mudah. Service Oriented Architecture (SOA) adalah sebuah permodelan perangkat lunak yang dibangun dengan pendekatan service oriented. Service oriented sendiri merupakan sebuah pendekatan yang memiliki visi ideal di mana setiap resource dari perangkat lunak terpartisi secara bersih satu sama lain. Setiap service memiliki otonomi sendiri yang membuatnya tidak tergantung satu sama lain. Setiap service dapat berkomunikasi satu sama lain melalui sebuah protokol yang sudah terstandardisasi sehingga memudahkan untuk melakukan integrasi. Enterprise Service Bus (ESB) merupakan solusi dari masalah kompleksitas integrasi n-to-n. Konsep ESB sangat mendukung untuk implementasi paradigma Service Oriented Architecture. Interaksi antar komponen layanan dilakukan melalui mediator ESB, hal ini akan menghadirkan sifat loose-coupling pada interaksi antar layanan dan memudahkan pengelolaan pada system terdistribusi.. Kata kunci: Integrasi, Service Oriented Architecture, Enterprise Service Bus (ESB) 1. Pendahuluan Dunia bisnis yang senantiasa berubah secara dinamis, kompetitor bertambah banyak, konsumen semakin kritis dan selalu menuntut pelayanan yang lebih, regulasi pemerintah yang kerap berubah, biaya operasional semakin tinggi dan tuntutan karyawan atas kesejahteraan mungkin adalah sebagian tantangan yang dihadapi para pelaku bisnis saat ini. Perusahaan biasanya akan mengotomasi proses bisnisnya, dan mengkomputerisasi beberapa tugas rutin sehari-hari karyawannya. Perkembangan di dunia teknologi informasi yang begitu pesat membawa dampak dalam proses bisnis yang membutuhkan integritas, kecepatan, dan akuntabilitas dalam semua proses pada suatu sistem Enterprise. Integrasi proses dari maufacturing, inventory, distribution dan financial merupakan suatu yang penting guna meningkatkan efisiensi dan efektifitas kerja pada semua bagian di dalam perusahaan. ERP merupakan suatu sistem yang mengintegrasikan dan mengotomasikan semua fungsi dalam proses bisnis perusahaan sehingga dapat mengurangi redudansi data, menekan tingkat kesalahan proses, mempercepat pemrosesan data dan menghasilkan laporan yang real-time. ERP sering disebut sebagai Back Office System dimana pelanggan dan publik secara umum tidak dilibatkan dalam sistem ini. Berbeda dengan Front Office System yang langsung berurusan dengan pelanggan seperti sistem e-commerce, Customer Relationship Management (CRM), e- Government dan lain-lain[1]. Service Oriented Architecture (SOA) merupakan model arsitektur untuk membuat software sebagai layanan yang bersifat loose coupling, sehingga bisa direuse. Aplikasi pada SOA dibangun berdasar servis. Servis adalah implementasi dari fungsi bisnis yang terdefinisi jelas, dan bisa dikonsumsi oleh klien pada berbagai aplikasi atau proses bisnis [2]. SOA membantu organisasi supaya bisa melakukan bisnis secara lebih efisien dan beradaptasi terhadap perubahan dan kompetisi. Dengan memanfaatkan Service Oriented Architecture merupakan solusi yang tepat untuk mengatasi problema-problema di atas. SOA menawarkan sebuah infrastruktur yang baik dengan kemampuan integrasi yang sudah terkelola, tentunya akan berdampak pada meningkatnya reliability, kemudahan pertukaran informasi antar aplikasi, mengurangi pengaruh jika terjadi perubahan, dan yang tidak kalah pentingnya adalah dapat menekan biaya untuk keperluan integrasi dan modifikasi aplikasi. Enterprise Service Bus (ESB) menyediakan infrastruktur untuk menerapkan konsep Service Oriented Architecture (SOA). ESB merupakan tren teknologi baru untuk arsitektur integrasi SOA. Komunikasi antara provider dan consumer dari layanan tidak dilakukan secara n-ton melainkan melalui sebuah service bus. Hal ini akan sangat menguntungkan consumer karena tidak akan terpengaruh atas perubahan letak dari penyedia layanan, karena yang di ketahui adalah layanan yang ada di ESB. Dengan menggunakan ESB layanan-layanan dapat di integrasikan sehingga mudah di-orkestrasi-kan menjadi suatu 1 Safuwan - 5108100502
layanan baru yang sesuai dengan kebutuhan proses bisnis baru. Makalah ini terdiri dari beberapa bab yang dijelaskan sebagai berikut. 1. BAB 1, Pendahuluan, Bab ini berisi latar belakang masalah, tujuan dan manfaat pembuatan tugas akhir, permasalahan, batasan masalah, metodologi yang digunakan, dan sistematika penyusunan tugas akhir. 2. BAB 2, Kajian Pustaka, Bab ini membahas beberapa teori penunjang yang berhubungan dengan pokok pembahasan dan mendasari pembuatan Tugas Akhir ini. 3. BAB 3, Analisis, Bab ini membahas analisis kebutuhan bisnis dari proses bisnis yang ada dan analisa integrasi. 4. BAB 3, Perancangan, Bab ini membahas desain sistem yang akan di integrasikan meliputi desain integrasi proses bisnis, arsitektur integrasi, dan integrasi antarmuka. 5. BAB 4, Uji Coba dan Evaluasi, Bab ini membahas uji coba dari integrasi yang dibuat dengan melihat hasil keluaran dari integrasi, dan evaluasi untuk mengetahui kemampuan hasil integrasi. 6. BAB 5, Penutup, Bab ini berisi kesimpulan dari hasil uji coba yang dilakukan serta saran untuk pengembangan selanjutnya 2. Kajian Pustaka Pada tahap ini akan membahas dasar teori yang mendasari pembuatan tugas akhir ini. 2.1 Enterprise Resource Planning (ERP) Enterprise resource planning software, atau ERP, tidak dapat kita maknai secara harfiah dari kepanjangannya. Lupakan kata planning dan lupakan kata resource karena terminologi tersebut tidak terlalu menjelaskan. Akan tetapi ingat bagian Enterprise nya. Karena bagian tersebut merupakan ambisi sebenarnya dari istilah ERP, yaitu ambisi untuk menyatukan seluruh departemen dan fungsi yang ada pada sebuah perusahaan kedalam sebuah sistem komputer terpadu yang dapat mengakomodasi seluruh kebutuhan spesifik dari departemen yang berbeda. ERP menggantikan sistem komputer independen di manufaktur, gudang, distribusi dan keuangan dengan sebuah program tunggal yang terbagi menjadi beberapa module yang serupa dengan sistem sebelumnya yang terpisah. Area keuangan, manufaktur dan gudang seluruhnya masih mendapatkan softwarenya masing-masing, yang berbeda sekarang softwarenya terhubung bersama sedemikian hingga seseorang di bagian keuangan dapat melihat software yang ditangani oleh bagian gudang untuk melihat apakah barang pesanan pelanggan sudah dikirim atau belum. Sebagian besar vendor ERP bersikap fleksibel sehingga anda dapat menginstal sebagian modul saja tanpa harus membeli paket utuh nya. Sejumlah perusahaan hanya akan menginstal ERP untuk kebutuhan modul keuangan atau gudang dan tidak menggunakan modul sisanya hingga suatu saat dirasakan perlu untuk menggunakan modul-modul yang lainnya. Harapan terbesar dari penggunaan ERP adalah untuk menunjukan perbaikan cara perusahaan anda mengambil dan mengelola pesanan pelanggan. Itulah sebabnya mengapa ERP seringkali dijadikan acuan sebagai software backoffice. ERP tidak menangani proses penjualan di depan (meski sebagian besar vendor ERP juga telah membangun software CRM untuk melakukan hal tersebut) akan tetapi ERP mengambil pesanan pelanggan dan menyediakan sebuah peta jalan untuk melakukan automasi pada setiap langkah. Ketika customer service anda menginput dokumen pesanan pelanggan pada sistem ERP, maka yang bersangkutan sudah memiliki seluruh informasi yang dibutuhkan untuk melengkapi dokumen order tersebut (angka piutang pelanggan dan histori pesanan dari modul keuangan [3], level inventori yang dimiliki peanggan dari modul gudang dan jadwal pengiriman melalui truk yang ada pada modul distribusi). 2.2 Service Oriented Architecture SOA adalah salah satu bentuk arsitektur yang memuat informasi sistem dalam bentuk services. Dengan menggunakan SOA, programprogram utama akan dibuat menjadi bisnis service. Dengan satu bisnis service, fungsi-fungsi yang sudah disediakan dapat digunakan oleh siapa saja. Dan jika perubahan aturan bisnis diterapkan pada salah satu bagian, maka semua pengguna service akan dapat merasakan perubahannya, sehingga konsistensi terpenuhi. SOA berupaya membangun standar interface untuk mengakses fungsi-fungsi bisnis yang berbeda-beda yang dibuat dengan menggunakan platform system yang berbeda pula. SOA menciptakan struktur yang fleksibel yang akan merubah software IT menjadi bentuk reusable-service, yang dapat selalu digunakan tanpa terhalangi oleh perubahan aturan bisnis [4]. SOA mendefinisikan bagaimana komponen software yang disebut dengan service diorganisir kedalam suatu struktur untuk mendukung kebutuhan bisnis. Web services adalah komponen software yang betugas dalam pertukaran informasi didalam environment heterogen termasuk internet. Service adalah kelompok fungsi independen yang tidak saling berhubungan langsung kecuali dengan interface service [6]. Service ini dapat berjalan diberbagai platform OS, dan dapat digunakan di berbagai lokasi serta ditulis dalam berbagai bahasa 2 Safuwan - 5108100502
pemrograman. Dan Service bus memungkinkan komunikasi terjadi antara service-service tersebut. Interface service adalah metode standard komunikasi yang dapat dipakai oleh siapapun tanpa membedakan vendornya. Service bus bertugas untuk menyembunyikan bagian mana dari service yang berkomunikasi dengan aplikasi. 2.1.1 SOA Modelling Metodologi SOA dimulai dengan modelling. SOA Conseptual Model didasarkan pada bentuk arsitekturnya yang merupakan interaksi diantara bagianbagian utamanya yaitu: 1. Penyedia Service Berfungsi menyediakan service dan dilengkapi dengan implementasinya. Penyedia service berupa network address yang dapat menerima dan mengeksekusi permintaan dari pemakai service. 2. Pemakai Service Pemakai service dapat menggunakan Uniform Resource Identifier (URI) untuk meminta service baik secara langsung atau melakukan pencarian service yang sesuai pada service registry, kemudian melakukan binding dan invoke terhadap service. Peminta service dapat berupa aplikasi, service maupun modul software yang memerlukan service. 3. Service Registry Service Registry berupa directory yang dapat diakses melalui network dan berfungsi untuk menyimpan service-service. Fungsi utamanya adalah menyimpan dan mempublish service dari penyedia service lalu mengirimkannya kepada yang meminta service. 4. Service Broker Service Broker menyediakan dan mengatur service registry. SOA menggunakan paradigma find-bindexecute. Penyedia service meregister servicenya kedalam registry public. Kemudian registry ini digunakan oleh pemakai untuk menemukan service yang sesuai dengan kriteria yang dikehendaki. Apabila didalam registry ini terdapat service yang dikehendaki, maka pemakai akan diberi kontrak dan alamat akhir service tersebut. Gambar 2-1 Paradigma SOA s Find-Bind-Execute 2.1.2 SOA Reference Architecture Aplikasi berbasis SOA adalah aplikasi multi-tier terdistribusi yang terdiri dari layer-layer service yang terhubung dengan proses bisnis. Untuk bisnis yang Service-Oriented diperlukan pendekatan modelling, analysis, desain teknik dan aktivitas untuk mendefinisikan elemen-elemen dari masing-masing SOA layer. SOA Reference Architecture mencakup ketiga komponen SOA dengan dilengkapi pendekatan, permintaan dan desain patern yang memungkinkan. SOA Reference Architecture membentuk bagian-bagian SOA kedalam services, service component dan alirannya yang secara bersama-sama mensupport Enterprise business process dan keberhasilan bisinis. 3. Analisis Pada tahap ini akan dijelaskan mengenai analisa integrasi enterprise resource planning 3.1 Domain Permasalahan Dalam suatu perusahaan skala Enterprise masing-masing department biasanya mempunyai kebijakan sendiri-sendiri, dengan demikian sangat sulit untuk menyatukannya dengan menggunakan aplikasi tunggal. Tentunya setiap department akan membuat aplikasi yang sesuai dengan kebutuhan proses bisnis dari department tesebut. Akan tetapi setiap departemen diharuskan saling berkomunikasi dengan departmen lainya untuk koordinasi dan pertukaran data. Sehingga dengan demikian diperlukan proses untuk mengintegrasikan sistem yang berdiri sendiri-sendiri tersebut menjadi sistem yang terintegrasi satu sama lainnya. Selain sistem yang terintegrasi secara komunikasi data juga di butuhkan daftar integrasi urutan proses bisnis yang jelas sehingga mudah di mengerti oleh pengguna sistem. 3.2 Model Penerapan SOA pada ERP Penggunaan SOA pada penerapan bisnis proses perusahaan dalam pengembangan aplikasi ERP-nya memiliki beberapa keuntungan. Dengan metode SOA, program menyimpan fungsi-fungsi pentingnya dalam bentuk service. Service-service ini memiliki sifat independen, sehingga dapat dipangggil dan digunakan oleh siapa saja yang melakukan request service tanpa terhalangi oleh perbedaan platform. Sebuah aplikasi yang tidak berbasis service-oriented akan mendefinisikan proses bisnisnya bersamaan dengan perintah yang berhubungan dengan sisi teknis. Hal ini menyebabkan perubahan proses bisnis harus turun ke kode. Pengubahan yang langsung turun ke kode ini seharusnya bisa disederhanakan dengan memisahkan antara proses bisnis pada bagian tersendiri, sebab pada umumnya yang berubah pada sistem adalah proses bisnisnya saja. Sementara fungsi-fungsi yang dijalankan tidak berubah. Penggunaan arsitektur SOA akan menjadi jawaban terhadap masalah yang dialami tersebut. Arsitektur SOA menjamin modularitas fungsifungsi dari aplikasi yang ada didalamnya dan 3 Safuwan - 5108100502
memisahkan proses bisnis menjadi sebuah bagian tersendiri yang disebut lapisan orkestrasi. Perubahan proses bisnis cukup berlangsung pada lapisan orkestrasi tersebut dengan memanfaatkan fungsi-fungsi yang ada. ERP yang terdiri dari banyak proses bisnis didalamnya sangat tepat jika dikembangkan dengan menggunakan metode SOA. Setiap bagian pembentuk ERP akan dibuat dalam sebuah serviceservice yang terpisah dan yang akan diletakkan pada sebuah Enterprise Service Bus (ESB). Service-service [5] ini mewakili masing-masing komponen pembentuk ERP yang dapat digunakan dan dipanggil oleh siapa saja dengan bebas tanpa terhalangi oleh perbedaan platform antara penyedia dan peminta service. Dan dengan penerapan SOA, perubahan proses bisnis ERP dapat dibuat lebih fleksibel karena jika terjadi perubahan Gambar 3. 1 Arsitektur Integrasi ERP 4. Tahap Perancangan Pada bab perancangan ini akan dijelaskan mengenai perancangan integrasi proses bisnis dan perancangan integrasi service dalam enterprise service bus 4.1 Perancangan Integrasi Proses Bisnis 4.1.1 Procure-To-Pay Proses bisnis ini merupakan proses pengadaan barang yang dimulai dari purchase requisition hingga pembayaran. Berikut ini merupakan langkah-langkah yang dilakukan dalam proses procure-to-pay: 1. Purchase Request Langkah ini merupakan tahap awal dari proses procure-to-pay, yaitu bagian gudang membuat daftar pemintaan kebutuhan bahan baku yang akan di gunakan untuk proses produksi. 2. Purchase Order Bagian pembelian yang menerima daftar permintaan pembeliaan bahan baku akan mencarikan kebutuhkan bahan baku dari supplier yang dapat memenuhi pengiriman sesuai dengan yang diinginkan. 3. Receiving Setelah dilakukan pembelian dan kemudian barang datang akan diterima di gudang karantina untuk dilakukan internal proses sebelum barang di pindahkan ke gudang bahan baku. 4. Purchase Invoice Dengan di terimannya barang yang di pesan maka bagian keuangan akan mendapatkan tagihan dari supplier terhadap barang yang di pesan. 5. Payment (Bank Out, Cash Out, Issue Cheque/Giro) Sebelum jatuh tempo tagihan pembayaran pembelian, bagain keuangan akan melakukan pembayaran yang biasanya dilakukan secara transfer bank atau mengeluarkan cheque/giro ke supplier. 4.1.1 Order-To-Cash Proses bisnis ini merupakan proses penjualan yang dimulai dari sales order hingga pelunasan. Berikut ini merupakan langkah-langkah yang dilakukan dalam proses order-to-cash: 1. Sales Order Bagian marketing yang mendapatkan pesanan dari pelanggan akan membuat dokumen pesanan pembelian yang selanjutnya akan di teruskan kepada bagian PPIC. Bagian PPIC akan membuatkan perancaan produksi barang pesanan dan memberikan promise date penyelesaian produksi barang yang di pesan. 2. Shipment Setelah barang pesanan selesai di produksi selanjutnya bagian gudang barang jadi membuatkan surat pengiriman. 3. Load Sheet Dari daftar shipment yang ada selanjutnya bagian pengiriman akan mendistribusikan ke pelanggan. 4. Sales Invoice Bagian keuangan membuatkan tagihan pembayaran dari pesanan pelanggan yang sudah dikirimkan. 5. Pelunasan Pelanggan dapat melakukan pembayaran melalui transfer bank, atau memberikan 4 Safuwan - 5108100502
cheque/giro sesuai dengan tagihan pembayaran pembeliannya. 4.1.1 Make-To-Order Manufacturing Proses bisnis ini dijalankan untuk proses produksi barang yang di buat sesuai dengan pesanan pelanggan. Berikut ini merupakan langkah-langkah yang dilakukan dalam proses produksi untuk make-to-order: 1. Production Request Bagian PPIC yang mendapatkan pesanan pembelian dari bagian marketing akan membuat dokumen permintaan produksi. Selanjutnya akan di buatkan perencanaan produksi sehingga dapat di ketahui jadwal proses produksi, dan bagian marketing dapat memberikan konformasi ke pelanggan mengenai kapan selesainya barang pesanan. 2. Production Order Dari jadwal produksi yang telah di buat di hasilkan surat perintah produksi yang kemudian di berikan kepada bagian produksi untuk melakukan proses eksekusi produksi. 3. Material Usage Bagian produksi akan mencatat pemakaian material yang diggunakan dalam proses produksi 4. Machine Usage Bagian produksi juga mencatat pemakaian mesin selama proses produksi. 5. Receipt Product Bagian produksi mencatat jumlah produk yang diterima dari hasil proses produksi. 6. Close Production Setelah semua proses produksi pesanan dalam surat perintah produksi dinyatakan selesai maka bagian produksi akan menutup permintaan produksi yang bersangkutan. 4.2 Perancangan Integrasi Service Perancangan integrasi service dilakukan dengan menggunakan BPEL dan Composite Application yang disediakan oleh framework OpenESB. Setiap BPEL yang di buat terdiri dari satu web service yang berisi banyak operation dan satu BPEL akan di buatkan satu Composite Application. 4.2.1.1 CurrencyManagement Gambar 4. 1 BPEL Currency Management 5. Uji Coba Bab ini membahas uji coba dari aplikasi yang dibuat dengan melihat hasil keluaran yang dihasilkan dari integrasi service, dan evaluasi untuk mengetahui kemampuan integrasi. Berikut ini ujicoba Service Currency Management yang sudah di-integrasikan 1. ProvideCurrency Input: Output: 4.2.1 Cash and Bank Berikut ini merupakan salah satu contoh dari service yang ada pada functional domain Cash & Bank yaitu service CurrencyManagement yang dibuatkan BPEL untuk di-integrasikan. 5 Safuwan - 5108100502
2. ProvideExchangeRate Input: Output: Dari hasil pengamatan mulai tahap analisis, perancangan, implementasi dan uji coba, penulis mengambil kesimpulan sebagai berikut: 1. Integrasi Service dengan menggunakan OpenESB dilakukan dengan membuatkan satu BPEL dan satu Composite Application untuk setiap web service. 2. Web service yang di-integrasikan dengan OpenESB harus stabil dengan tidak ada perubahan nama operation, format masukan dan keluaran karena jika ada perubahan maka mengharuskan membuat ulang BPEL dari web service tersebut karena OpenESB menggunakan static WSDL. 7. Daftar Pustaka [1] Enterprise resource planning, <url: http://en.wikipedia.org/wiki/enterprise_resour ce_planning>, diakses tanggal 5 Juli 2010. [2] IBM. (2004). Patterns: Elements of Service- Oriented Analysis and Design, <url: http://www.ibm.com/developerworks/library/ ws-soad1/>, diakses tanggal 10 Juli 2010. [3] Sarno, R. and Herdiyanti, A. (May 2010), Developing Information Technology Policies for Enterprise Resource Planning to Improve Customer Orientation and Service, International Journal of Computer Science and Network Security, ISSN 1738 7906, Vol. 10, No. 5, pp. 82-94. [4] Sarno, R. and Herdiyanti, A. (March 2010), A Service Portfolio for an Enterprise Resource Planning ; International Journal of Computer Science and Network Security, ISSN 1738 7906, Vol. 10, No. 3, pp. 144-156. [5] ESB Integration Patterns, <url: http://soa.syscon.com/node/46170>, diakses tanggal 15 Juli 2010. [6] Edison1, Virginia Tulenan1, and Ford Lumban Gaol "SERVICE ORIENTED ARCHITECTURE REFERENCE ARCHITECTURE BLUEPRINT"; Jurnal Sistem Informasi MTI UI, Volume 5, Nomor 2, ISBN 1412 8896. 6. Kesimpulan Dari hasil pengamatan mulai tahap analisis, perancangan, implementasi dan uji coba, penulis mengambil kesimpulan sebagai berikut: 1. Menggunakan Service yang telah di integrasikan dengan OpenESB harus dipastikan data yang diminta tidak kosong dengan menambahkan try catch pada saat request operation. Hal tersebut perlu dilakukan karena jika operation yang di minta menghasilkan object kosong maka akan menyebabkan error pada program. 2. Integrasi legacy system dapat dilakukan dengan mudah jika sudah menggunakan arsitektur SOA. 3. Enterprise Service Bus merupakan teknologi yang sangat mendukung implementasi integrasi aplikasi SOA. 6 Safuwan - 5108100502