Bab II Tinjauan Pustaka
Bab ini memaparkan teori yang mendasari pembahasan tesis secara menyeluruh.
II.1 Definisi Integrasi Enterprise Bernstein dan Ruh mendefinisikan enterprise integration yaitu : “Unrestricted sharing of information, services, and business processes among any connected applications or data sources in the enterprise.” (4). Hohpe, Gregor dalam bukunya Enterprise Integration Patterns mendefinisikan enterprise integration sebagai : “Enterprise integration has to deal with multiple applications running on multiple platforms in different locations, making the term simple integration pretty much an oxymoron” (5). Lam, Wing dalam tulisan yang berjudul Technical Risk Management on Enterprise Integration Projects mendefinisikan enterprise integration sebagai : “A general term that refers to the integration of IT systems and business processes both within the enterprise and between different enterprises” (8). Dari beberapa definisi di atas dapat ditarik kesimpulan bahwa enterprise integration (EI) merupakan tugas untuk membuat agar aplikasi-aplikasi yang bekerja pada berbagai platform di lokasi yang berbeda dapat bekerja sama guna menghasilkan suatu kesatuan fungsionalitas, sehingga dapat saling berbagi informasi, layanan dan proses bisnis baik di dalam enterprise maupun antar enterprise.
II.2 Macam-macam Proyek EI Yang dimaksud dengan proyek EI adalah proyek IT yang terkait dengan pekerjaan EI, meliputi pemodelan proses bisnis, integrasi aplikasi, perancangan dan pengembangan middleware, serta pengujian integrasi.
7
8
Pembahasan tesis ini fokus pada kegiatan integrasi sistem di dalam enterprise. Pada umumnya, proyek enterprise integration dibagi ke dalam 4 kategori utama yaitu (8) :
1. Enterprise Application Integration (EAI), merupakan integrasi antara sistemsistem IT dalam enterprise, biasanya untuk meningkatkan efisiensi bisnis dan untuk memenuhi kebutuhan pemrosesan informasi secara real-time. 2. Web integration, merupakan integrasi antara legacy system dengan aplikasiaplikasi berbasis Web, dikendalikan oleh kebutuhan penyediaan web channel bagi para konsumen sehingga dapat dengan mudah mengakses produk, layanan atau informasi. 3. B2C integration, merupakan integrasi antara back-end transactional IT system, yang secara alamiah merupakan legacy system dengan aplikasi frontend berbasis Web seperti storefront dan personalization engine untuk penyediaan solusi B2C. 4. B2B integration, merupakan integrasi sistem-sistem IT antara organisasi yang berbeda untuk mendukung akitvitas-aktivitas B2B seperti supply chain management terintegrasi.
II.3 Road Map Integrasi Road map menjelaskan keseluruhan langkah yang menuntun kegiatan integrasi enterprise, secara lengkap dapat dilihat pada Gambar II.1. Dari Gambar II.1 dapat dilihat bahwa langkah pertama kegiatan integrasi enterprise adalah penetapan pengendali dan kebutuhan bisnis, langkah ini akan menentukan ruang lingkup integrasi. Langkah berikutnya setelah pendefinisian pengendali dan kebutuhan bisnis adalah pembuatan strategi integrasi dan pembuatan arsitektur integrasi.
9
Gambar II.1 Road Map Integrasi (4)
II.3.1 Pengendali dan Kebutuhan Bisnis Muara akhir dari proyek integrasi adalah integrasi bisnis enterprise sehingga perlu adanya keterkaitan antara kegiatan integrasi dengan kebutuhan bisnis dalam proses-proses yang dilakukan sedini mungkin untuk mencapai keberhasilan. Kesuksesan bisnis stratejik tergantung pada keselarasan (alignment) antara IT dan tujuan bisnis (business goal). Implementasi dikatakan berhasil jika memenuhi kebutuhan bisnis (business requirement) dan memberikan kontribusi bagi kesuksesan bisnis secara menyeluruh. Guna memenuhi harapan-harapan bisnis, maka diperlukan pendefinisian pengendali-pengendali, maksud, ruang lingkup dan matriks yang dapat mengukur kesuksesan. Spesifikasi pengendali dan kebutuhan bisnis merupakan dokumentasi yang menggambarkan apa yang sedang bisnis coba untuk capai (4). Spesifikasi ini akan menjadi tuntunan bagi proyek dan juga akan digunakan sampai sistem dapat beroperasi untuk menilai dampak pada bisnis.
10
Jenis-jenis inisiatif bisnis paling umum yang mengendalikan kebutuhan integrasi saat ini (4) meliputi pengurangan waktu siklus bisnis untuk meningkatkan efisiensi dan daya saing, meningkatkan kepuasan pelanggan, penggabungan dan akuisisi serta pemenuhan regulasi. Beberapa inisiatif ini bersifat stratejik dan beberapa bersifat taktis, kebutuhan bisnis yang berbeda akan memerlukan teknologi integrasi yang berbeda pula.
Pemahaman dan pendokumentasian kebutuhan bisnis sangatlah penting untuk memastikan penyelarasan (alignment) antara IT dan strategi bisnis sehingga akan mempermudah perencanaan proyek. Kegagalan pada saat pendefinisian kebutuhan bisnis akan mengantarkan pada keputusan yang salah dan kegagalan implementasi.
Saat
mendefinisikan
kebutuhan,
sangatlah
penting
untuk
memahami bagaimana bisnis beroperasi dan dampak proses bisnis baru yang akan dihadapi. Kebutuhan-kebutuhan bisnis ini akan menentukan pendekatan yang perlu diambil apakah stratejik atau taktis.
II.3.2 Strategi Integrasi Enterprise Integrasi enteprise fokus pada peningkatan efisiensi dan efektivitas proses-proses yang menjalankan bisnis, termasuk peningkatan kualitas serta informasi yang tepat waktu dan disediakan sesuai permintaan, tanpa memperhatikan sistem sumber. Tingkatan business agility tidak dapat dicapai secara sederhana hanya dengan mengimplementasikan teknologi integrasi pada tiap proyek tanpa strategi secara menyeluruh mengenai bagaimana kesemuanya dapat cocok. Implementasi strategi secara cepat memerlukan strategi integrasi enterprise-level. Strategi integrasi enterprise akan berujung pada pengurangan waktu dan biaya pengelolaan informasi dan sumber daya IT.
Spesifikasi strategi integrasi bisnis merupakan dokumen yang memetakan kebutuhan, strategi dan inisiatif bisnis menjadi strategi dan proyek integrasi. Spesifikasi strategi integrasi dapat dibuat baik pada tingkatan enterprise maupun proyek (4).
11
II.3.3 Arsitektur Integrasi Enterprise Arsitektur integrasi enterprise menyediakan blueprint untuk proyek integrasi baik stratejik maupun taktis (4), menggambarkan keseluruhan komponen dari arsitektur. Pendekatan-pendekatan taktis untuk mengembangkan infrastruktur teknis ternyata memiliki biaya pemeliharaan yang tinggi dan menghambat business agility. Dikarenakan hal tersebut, maka organisasi-organisasi besar dan juga lembaga-lembaga pemerintahan telah menetapkan framework arsitektur enterprise (enterprise architecture/EA). Arsitektur integrasi enterprise haruslah cocok
dengan
seluruh
framework
arsitektur
enterprise.
Prioritas
dari
pengembangan arsitektur dikendalikan oleh kebutuhan dan strategi bisnis.
Arsitektur integrasi enterprise stratejik meliputi tata kelola untuk memastikan bahwa proyek memenuhi standar-standar yang telah ditetapkan dan terdapat proses untuk pengecualian. Pendekatan ini mengurangi jumlah konfigurasi dan kebutuhan keterampilan teknis sehingga dapat mengurangi biaya. Pendekatan ini juga memastikan bahwa investasi teknologi saat ini dan untuk masa mendatang dioptimalisasi pada tingkatan enterprise.
Pendekatan stratejik untuk mengembangkan infrastruktur integrasi diperlukan sehingga komponen-komponen infrastruktur dapat saling bekerjasama guna menyediakan integrasi antar proses bisnis dan penyebaran solusi bisnis terintegrasi
secara
cepat.
Pendekatan
taktis
integrasi
enterprise
akan
memungkinkan teknologi yang tidak dirancang untuk berintegrasi dapat berkumpul bersama-sama. Pendekatan enterprise memungkinkan pengurangan biaya dan memaksimalkan fleksibilitas.
Arsitektur integrasi enterprise adalah multidimensi, dimana tiap komponen arsitektur yang relevan dengan integrasi masing-masing berfokus pada domain arsitektur integrasi yang berbeda dan saling terkait serta berinteraksi satu sama lain. Gambar II.2 menunjukkan empat domain arsitektur yaitu arsitektur integrasi teknis, arsitektur integrasi layanan, arsitektur integrasi informasi dan arsitektur integrasi proses bisnis.
12
Gambar II.2 Domain Arsitektur Integrasi Enterprise (4) Penjelasan untuk masing-masing domain arsitektur integrasi enterprise adalah : 1. Arsitektur integrasi teknis Arsitektur integrasi teknis mendefinisikan teknologi untuk seluruh solusi integrasi. Domain ini menjadi dasar guna mendukung komponen arsitektur integrasi enterprise yang lain.
2. Arsitektur integrasi layanan Arsitektur integrasi layanan merupakan subset dari arsitektur aplikasi enterprise. Didefinisikan sebagai loosely coupled, reusable business services, arsitektur aplikasi ini paling fleksibel dan dapat beradaptasi terhadap perubahan bisnis, sehingga memungkinkan integrasi aplikasi secara cepat.
3. Arsitektur integrasi informasi Arsitektur integrasi informasi menyediakan pandangan secara enterprise-wide mengenai data yang terdapat pada sistem yang terpisah. Nilai dari data itu sendiri bergantung pada pemeliharaan integritas data antar sistem. Solusi untuk pemeliharaan nilai, makna dan integritas data antara aplikasi adalah metadata. Metadata merupakan informasi mengenai data. Semakin deskriptif, akurat dan lengkap metadata, maka akan semakin baik integrasinya. Untuk
13
kepentingan integrasi, metadata dipresentasikan dalam format kanonik sehingga mempermudah pemetaan kembali ke sistem sumber.
4. Arsitektur integrasi proses bisnis Arsitektur integrasi proses bisnis memodelkan proses bisnis yang melintasi batasan-batasan organisasi. Tujuan dari integrasi adalah untuk meningkatkan proses bisnis dan efisiensi. Arsitektur proses bisnis memaksimalkan business agility
karena
memungkinkan
perubahan
terhadap
proses
bisnis
diimplementasikan secara cepat.
II.3.3.1 Penilaian Lingkungan Integrasi Saat Ini Kesalahan yang sering terjadi pada organisasi saat memulai aktivitas pengembangan arsitektur integrasi enterprise adalah memulainya dengan kertas kosong, padahal arsitektur yang telah ada saat ini baik efisien atau tidak merupakan titik awal karena kenyataannya arsitektur integrasi adalah mengijinkan adanya guna ulang (reuse) aset IT untuk memanfaatkan fungsi-fungsi bisnis baru.
Penilaian arsitektur integrasi saat ini mengidentifikasi semua teknologi integrasi yang saat ini terpasang dalam organisasi dan aplikasi yang saat ini diintegrasikan. Penilaian berguna untuk menentukan komponen-komponen teknologi yang disukai dan vendor-vendor terkait dalam arsitektur integrasi enterprise akhir.
II.3.3.2 Arsitektur Integrasi Teknis Arsitektur integrasi teknis menyajikan enterprise building code bagi seluruh proyek integrasi, merupakan spesifikasi bahwa semua proyek akan mengacu saat harus memilih teknologi integrasi untuk implementasi tertentu. Arsitektur ini meliputi tuntunan dan batasan rancangan mengenai bagaimana seharusnya aplikasi dikembangkan. Oleh karena itu, spesifikasi tersebut harus dapat mendefinisikan semua aspek arsitektur integrasi secara seksama dan mudah diakses, sehingga informasi dapat dengan mudah ditemukan dan dipahami.
14
Arsitektur integrasi teknis harus dikendalikan oleh kebutuhan-kebutuhan bisnis baik saat ini maupun untuk mengatasi kebutuhan bisnis masa mendatang. Arsitektur integrasi teknis harus dapat mendefinisikan layanan business-domain yang umum dan reusable guna dapat mendukung berbagai aplikasi, layanan teknis yang umum dan terstandarisasi sehingga dapat mendukung berbagai jenis integrasi, tingkatan layanan yang harus didukung, framework keamanan komprehensif yang didasarkan pada kebijakan pengamanan enterprise-wide yang jelas serta fokus pada kemampuan meningkatkan sistem informasi yang ada (legacy) dan produk sistem paket untuk menyediakan porsi fungsionalitas aplikasi yang signifikan.
II.3.3.3 Arsitektur Integrasi Layanan Arsitektur integrasi layanan mendefinisikan aplikasi bisnis sebagai komponenkomponen fungsionalitas bisnis yang reusable, mudah dirubah serta bagaimana komponen-komponen ini dapat saling terkait, hal ini merupakan konsep dari service-oriented architecture (SOA). Pada SOA, fungsi-fungsi bisnis atau prosesproses terpisah dibuat sebagai komponen-komponen yang independen dengan antar muka (interface) standar sehingga dapat diakses oleh aplikasi, layanan atau proses bisnis lain, dengan tidak memperhatikan platform atau bahasa pemrogramannya. Layanan-layanan ini dapat secara fleksibel dikombinasikan untuk mendukung perbedaan atau perubahan proses dan fungsi bisnis. SOA mendukung pembuatan aplikasi-aplikasi gabungan yang mana secara cepat dirangkaikan dari layanan yang telah ada dengan yang baru.
Manfaat-manfaat yang diperoleh dengan penerapan konsep SOA (4) adalah : 1. Memungkinkan business agility. 2. Menyediakan return on investment (ROI) yang tinggi. 3. Memungkinkan IT agility. 4. Mengurangi biaya pelatihan. 5. Mengurangi biaya pengujian dan perbaikan bug. 6. Mendukung berbagai jenis client dan platform.
15
7. Mempercepat waktu pengembangan melalui pengembangan secara paralel. 8. Meningkatkan skalabilitas dan ketersediaan.
II.3.3.4 Arsitektur Integrasi Informasi Informasi dan data merupakan jantung dari setiap proyek integrasi. Integrasi terkait dengan tipe pertukaran data yang berbeda, dalam format yang berbeda. Permasalahan yang muncul dari proyek integrasi ini adalah bagaimana memungkinkan adanya interoperability antar sistem dengan data yang memiliki struktur dan format berbeda. Arsitektur integrasi informasi mendefinisikan infrastruktur dan proses untuk memungkinkan informasi dapat diakses antar sistem, metadata enterprise yang independen terhadap teknologi maupun platform.
Terdapat dua cara integrasi informasi yaitu aggregation dan publishing. Agregasi informasi berarti mengumpulkan informasi dari berbagai sumber menjadi model metadata tunggal yang menyediakan pandangan yang juga tunggal akan data antar sistem. Publishing informasi berarti menyediakan informasi ke dalam berbagai back-end-system.
II.3.3.5 Arsitektur Integrasi Proses Bisnis Tujuan integrasi adalah untuk mendukung peningkatan efisiensi bisnis. Integrasi process-level mendefinisikan interaksi diantara sistem melalui definisi alur kerja bisnis. Instruksi untuk integrasi didefinisikan pada tingkatan business-process dan bukan pada tingkatan technical-interface. Meskipun infrastruktur integrasi teknis masih diperlukan untuk mengimplementasikan integrasi proses, proses-prosesnya itu sendiri independen terhadap teknologi.
Peran arsitektur integrasi proses adalah untuk menciptakan model dan definisi proses sebagai entitas yang dapat dikelola sehingga dapat dipandang dan dirubah lebih mudah guna menanggapi perubahan bisnis. Arsitektur integrasi proses
16
mendefinisikan proses bisnis end-to-end, yang lalu diotomatisasi melalui sistem yang ada dengan platform berbeda.
Terdapat berbagai jenis teknologi integrasi proses, seperti business process management (BPM), business process integration (BPI), business process automation (BPA), workflow automation (WA), business activity monitoring (BAM), dan web service orchestration (WSO). Standar-standar pemodelan proses akan
membantu
perusahaan
dalam
menjaga
investasi
memungkinkan portabilitas antar tool, sehingga akan
proses
dengan
mencegah adanya
‘technology lock-in’. Notasi pelaksanaan proses standar dapat dihasilkan dan diperoleh dari semua tool yang secara efektif dapat memecahkan permasalahan yang terjadi akibat ‘technology lock-in’.
Standar pemodelan proses yang dapat digunakan oleh perusahaan diantaranya BPEL, UML dan IDEF : 1. Business Process Execution Language (BPEL) untuk layanan-layanan Web merupakan representasi proses standar, merupakan bahasa pelaksanaan standar
namun
bukan
notasi
standar
artinya
tool
ini
akan
mengimplementasikan gaya modelnya sendiri dan menghasilkan kode BPEL dari model tersebut. 2. Unified Modeling Language (UML) Object Management Group (OMG) juga merupakan standar pemodelan proses yang relevan, terutama untuk perusahaan yang memiliki fokus pada pengembangan baru, dan yang telah menggunakan UML. 3. Integration Definition for Function Modeling (IDEF0) didasarkan pada Structured Analysis and Design Technique (SADT) yang diperkenalkan oleh Douglas T.Ross pada awal tahun 1970. Pada tahun 1981, program angkatan udara Amerika untuk Integrated Computer-Aided Manufacturing (ICAM) menstandarisasi serta mengadopsinya sebagai Federal Information Processing Standard (FPIS), dibuat sebagai subset SADT yang dikenal dengan nama IDEF0.
17
II.4 Enterprise Architecture Planning II.4.1 Pengertian Enterprise Architecture Planning Enterprise architecture (EA), pada Gambar II.3, merupakan “kesatuan orang, proses, informasi dan tool (teknologi merupakan salah satu tool). EA menetapkan suatu blueprint mengenai bagaimana organisasi memenuhi tujuan dan misi bisnisnya.”(14)
Gambar II.3 Membangun Enterprise Architecture (14) Menurut Spewak, enterprise architecture planning (EAP) merupakan “proses mendefinisikan arsitektur untuk menggunakan informasi guna mendukung bisnis dan rencana untuk mengimplementasikan arsitektur tersebut.”(11)
EAP merupakan proses untuk mendefinisikan kedua top layer dari framework arsitektur sistem informasi Zachman. EAP menghasilkan blueprint mengenai data, aplikasi dan teknologi yang menghasilkan solusi jangka panjang yang costeffective, bukan hanya perbaikan secara cepat.
II.4.2 Manfaat Enterprise Architecture Planning EAP berbeda dengan metoda perencanaan sistem tradisional, dimana pendekatan perencanaan tradisional bersifat “technology driven” sedangkan EAP bersifat “business driven”. Terdapat sejumlah manfaat dengan menerapkan EAP, diantaranya :
18
1. Fokus pada penggunaan stratejik teknologi untuk mengelola data sebagai suatu aset. 2. Memfasilitasi komunikasi dengan vocabulary yang standar serta mengurangi inkonsistensi dan redundansi data. 3. Dokumentasi meningkatkan pemahaman pada bisnis. 4. Model-model yang dihasilkan dapat digunakan untuk menjelaskan bisnis dan menilai dampak perubahan bisnis. 5. Kebijakan-kebijakan pembuatan keputusan dapat di-review. 6. Dapat mempertimbangkan integrasi sistem saat ini dengan yang baru. 7. Memungkinkan pendekatan yang komprehensif, objektif dan tidak parsial. 8. Perencanaan sistem jangka panjang melengkapi rencana bisnis. 9. Solusi cost-effective, jangka panjang dengan mempertimbangkan rate of return. 10. Melibatkan strategi migrasi yang feasible dengan pencapaian jangka pendek. 11. Lebih mudah untuk menilai manfaat dan dampak sistem dan software baru. 12. Lebih mudah untuk mengakomodasi perubahan bisnis yang dinamis seperti merger, acquisition, produk-produk baru, dan sebagainya. 13. Partisipasi
manajemen
menyediakan
perspektif
bisnis,
kredibilitas,
kepercayaan.
II.4.3 Komponen Enterprise Architecture Planning EAP yang dinyatakan oleh Spewak (Gambar II.4) membentuk kedua top layer dari framework Zachman, yaitu sasaran/ruang lingkup (ballpark view) dan model bisnis (owner’s view). EAP fokus pada pendefinisian arsitektur data, aplikasi dan teknologi untuk keseluruhan enterprise. Framework Zachman digunakan karena sangat membantu untuk dapat menempatkan tahapan-tahapan perencanaan / pendefinisian ke dalam framework yang konseptual, meskipun framework ini tidak menjelaskan bagaimana cara mendefinisikan kedua top level tersebut dan juga bagaimana mengimplementasikan arsitekturnya.
19
EAP
Gambar II.4 Enterprise Architecture Planning (19) Gambar II.5 menunjukkan 7 komponen atau fase EAP, yang menjelaskan bagaimana mendefinisikan arsitektur dan perencanaan. Komponen-komponen tersebut terbentuk sebagai layer, dimana tiap layer merepresentasikan fokus tugas yang berbeda, yaitu : 1. Layer 1-Where We Start Planning initiation. Memulai EAP pada jalur yang benar, termasuk menentukan metodologi yang digunakan, siapa yang harus dilibatkan dan toolset apa yang digunakan.
2. Layer 2-Where We Are Today a. Business modeling. Menyusun knowledge base mengenai bisnis dan informasi yang digunakan untuk melaksanakan bisnis. b. Current systems & technology. Mendefinisikan sistem aplikasi apa yang terdapat saat ini dan platform teknologi yang mendukung.
20
Planning Initiation Business Modeling Data Architecture
Layer 1
Current Systems & Technology
Applications Architecture
Technology Architecture
Implementation/Migration Plans
Layer 2 Layer 3 Layer 4
Gambar II.5 Komponen Enterprise Architecture Planning (11) 3. Layer 3-Where We Want to Be in the Future a. Data architecture. Mendefinsikan data yang diperlukan untuk mendukung bisnis. b. Application architecture. Mendefinisikan aplikasi yang diperlukan untuk mengelola data dan mendukung fungsi-fungsi bisnis. c. Technology architecture. Mendefinisikan platform teknologi yang diperlukan untuk menyediakan lingkungan bagi aplikasi yang mengelola data dan mendukung fungsi-fungsi bisnis.
Panah pada layer ini menunjukkan bahwa data architecture didefinisikan terlebih dahulu, lalu berturut-turut mendefinisikan application architecture dan technology architecture. Hal ini berbeda dengan metoda perencanaan sistem tradisional yang melakukan sebaliknya, dimana pertama-tama menentukan hardware, kemudian aplikasi yang berjalan pada hardware, dan terakhir data yang perlu diproses.
4. Layer 4-How We Get There Implementation/migration plans. Mendefnisikan urutan langkah untuk mengimplementasikan aplikasi, jadwal implementasi, analisis manfaat/biaya dan mengajukan jalur yang jelas untuk melakukan migrasi dari where we are today ke where we want to be.
21
II.4.3.1 Planning Initiation Proyek-proyek EAP seringkali tidak dapat diselesaikan. Hal ini disebabkan berbagai faktor, yaitu : 1. Proyek-proyek EAP dimulai pada jalur yang salah dengan sasaran yang tidak masuk akal dan ekspektasi yang tidak realistik. 2. Memilih pendekatan yang tidak akan mencapai hasil yang diinginkan sesuai dengan waktu yang ditetapkan. 3. Para partisipan tidak familiar dan berpengalaman dengan EAP. Untuk mengatasi hal tersebut, maka diperlukan tahapan inisiasi EAP sehingga proyek dapat dilaksanakan secara cepat dalam jalur yang benar sejak awal, diselesaikan tepat waktu dan didukung anggota tim yang memiliki kualifikasi.
Terdapat 2 deliverable yang dihasilkan dari fase planning initiation, yaitu : 1. Deliverable
yang
tangible,
berupa
workplan
proyek
EAP
yang
menspesifikasikan fase dan tahapan yang diperlukan untuk menyelesaikan tujuan EAP, yakni mengembangkan arsitektur dan rencana implementasi. 2. Deliverable yang intangible, berupa dukungan serta komitmen para eksekutif dan manajemen enterprise bagi kesuksesan EAP.
Langkah-langkah dari fase planning initiation adalah : 1. Menentukan ruang lingkup dan sasaran EAP. 2. Membuat visi (mengadakan pertemuan terlebih dahulu dengan manajemen). 3. Mengadaptasi metodologi perencanaan. 4. Mengatur sumber daya komputer. 5. Menyusun tim perencana. 6. Mempersiapkan workplan EAP. 7. Memperoleh/mengkonfirmasikan komitmen dan pendanaan.
II.4.3.2 Business Modeling Business modeling merupakan proses untuk mendefinisikan bisnis. Tujuan dari model bisnis adalah menyediakan knowledge base yang lengkap, komprehensif
22
dan konsisten yang dapat digunakan untuk mendefinisikan arsitektur dan rencana implementasi. Dalam EAP, business modeling dilakukan dalam dua bagian yang berbeda, yaitu preliminary business model dan complete business model. Preliminary business model mengidentifikasi fungsi, menyediakan deskripsi yang singkat mengenai tiap fungsi dan mengidentifikasi unit organisasi yang melaksanakan tiap fungsi bisnis.
Terdapat 3 langkah untuk melengkapi preliminary business model, yaitu : 1. Mendokumentasikan struktur organisasi. 2. Mengidentifikasi dan mendefinisikan fungsi-fungsi bisnis. 3. Mendokumentasikan preliminary business model, mendistribusikannya dan mempresentasikannya kembali pada komunitas bisnis untuk memperoleh masukan.
II.4.3.3 Current Systems and Technology Architecture Tujuan dari fase ini adalah untuk mendokumentasikan dan mendefinisikan semua platform sistem dan teknologi yang digunakan dalam enterprise. Deliverable dari fase ini adalah Information Resource Catalog (IRC), sering juga disebut Systems Encyclopedia atau Systems Inventory. Langkah-langkah untuk membuat IRC adalah : 1. Menentukan ruang lingkup, sasaran dan workplan IRC. 2. Mempersiapkan pengumpulan data. 3. Mengumpulkan data IRC. 4. Memasukkan data. 5. Memvalidasi dan mereview draft IRC. 6. Menggambarkan skematik. 7. Mendistribusikan IRC. 8. Mengelola dan memelihara IRC.
23
II.4.3.4 Data Architecture Data architecture mengidentifikasi dan mendefinisikan data yang mendukung fungsi-fungsi bisnis yang didefinisikan dalam business model. Data architecture merupakan salah satu dari 3 enterprise-wide architecture yang diidentifikasi dalam Zachman framework untuk arsitektur sistem informasi. Data architecture didefinisikan pertama kali sebelum arsitektur yang lain karena kualitas data merupakan produk dasar dari fungsi sistem informasi. Data berada pada kolom pertama Zachman framework, dan enterprise data architecture terkait dengan dua baris teratas pada kolom tersebut. Data architecture terdiri atas data entities, dimana masing-masing entitas tersebut memiliki attributes dan relationships dengan entitas data lainnya.
Terdapat 4 langkah dari fase data architecture, yaitu : 1. Mendaftarkan kandidat entitas data. 2. Mendefinisikan entitas, atribut dan relationship. 3. Merelasikan entitas dengan fungsi-fungsi bisnis. 4. Mendistribusikan data architecture.
II.4.3.5 Applications Architecture Tujuan applications architecture adalah untuk mendefinisikan aplikasi-aplikasi yang diperlukan untuk mengelola data dan mendukung fungsi-fungsi bisnis di enterprise. Applications architecture bukanlah rancangan bagi sistem maupun juga analisis requirement yang terinci, namun merupakan definisi tentang apa yang akan dilakukan aplikasi untuk mengelola data dan menyediakan informasi bagi
orang-orang
dalam
melaksanakan
fungsi-fungsi
bisnis.
Aplikasi
memungkinkan fungsi sistem informasi dapat mencapai misinya, oleh karenanya harus dapat menyediakan akses bagi data dalam format yang berguna dan biaya yang dapat diterima.
Applications architecture terkait dengan owner’s view pada kolom process dari Zachman framework, merupakan arsitektur kedua dari 3 arsitektur yang harus
24
dibuat dalam EAP. Terdapat 5 langkah untuk menghasilkan applications architecture, yaitu : 1. Mendaftarkan kandidat aplikasi. 2. Mendefinisikan aplikasi. 3. Merelasikan aplikasi dengan fungsi. 4. Menganalisa dampak bagi aplikasi yang ada saat ini. 5. Mendistribusikan applications architecture.
II.4.3.6 Technology Architecture Tujuan dari technology architecture adalah untuk mendefinisikan teknologi yang diperlukan untuk menyediakan lingkungan bagi aplikasi yang mengelola data. Technology architecture bukanlah meupakan rincian analisis requirement atau rancangan untuk jaringan dan software bagi enterprise, namun merupakan definisi platform teknologi yang akan mendukung bisnis dalam lingkungan data bersama. Technology architecture terkait dengan owner’s view (baris kedua) dari kolom network pada Zachman framework.
Terdapat 4 langkah untuk technology architecture, yaitu : 1. Mengidentifikasi prinsip-prinsip dan platform teknologi. 2. Mendefinisikan platform dan distribusi. 3. Merelasikan technology platform dengan aplikasi dan fungsi-fungsi bisnis. 4. Mendistribusikan technology architecture.
II.4.3.7 Implementation Plan Tujuan dari fase ini adalah untuk memformulasikan dan mempersiapkan rencana untuk implementasi arsitektur. Pada tahapan ini, business model, Information Resource Catalog dan ketiga arsitektur yang telah terdefinisi akan digunakan untuk rencana implementasi. Pada sejumlah proyek EAP, rencana ini disebut sebagai migration strategy untuk menekankan pada adanya perpindahan stratejik dari bisnis saat ini kepada bisnis yang diinginkan di masa mendatang.
25
Terdapat 4 langkah untuk menghasilkan rencana implementasi arsitektur, yaitu : 1. Mengurutkan aplikasi. 2. Mengestimasi, usaha, sumber daya dan menghasilkan jadwal. 3. Mengestimasi biaya dan manfaat rencana. 4. Menentukan faktor-faktor kesuksesan dan membuat rekomendasi.
II.5 Value Chain Michael Porter menyatakan bahwa “setiap perusahaan merupakan kumpulan aktivitas yang dilakukan untuk merancang, menghasilkan, memasarkan, menyampaikan dan mendukung produk atau layanannya. Semua aktivitas ini dapat disajikan dalam bentuk value chain (rantai nilai). Rantai nilai hanya dapat dipahami dalam konteks unit bisnis.” (13).
Value chain analysis dapat membantu institusi menentukan tipe kompetitif yang mana yang harus dicapai dan bagaimana mencapainya. Terdapat dua komponen value chain analysis : industry value chain dan internal value chain organisasi. Industry value chain terdiri atas aktivitas value creating pada industri. Porter (1985) mengidentifikasi 5 competitive forces dalam industri : intensitas persaingan di antara kompetitor, barrier untuk kompetitor baru, ancaman dari produk dan layanan substitusi, daya tawar supplier, daya tawar pembeli. Analisis terhadap tekanan–tekanan seperti ini menunjukkan keatraktifan fundamental industri, mengekspose pengendali profitabilitas industri, serta menunjukkan bagaimana profitabilitas dapat meningkat di masa yang akan datang, memberikan perubahan yang berbeda pada supplier, channels, subtitutes, competitors, atau technology.
Kunci analisis value chain adalah memahami aktivitas di dalam institusi yang menciptakan manfaat kompetitif serta pengaturan aktivitas tersebut lebih baik dari institusi lain pada industri. Porter (1985) mengemukakan bahwa aktivitas bisnis dapat dikelompokan menjadi dua : 1. Primary activities, yang secara langsung berkaitan dengan produksi dan pengiriman produk atau layanan; serta
26
2. Support activities, yang mendukung primary activities, tidak terlibat langsung dalam produksi, namun memiliki potensi meningkatkan efisiensi dan efektivitas.
Value chain analysis ditujukan untuk melaksanakan proses internal serta mengidentifikasi aktivitas mana yang baik untuk diterapkan, yang baik untuk disediakan. Selengkapnya mengenai rantai nilai model Porter dapat dilihat pada Gambar II.6 berikut :
Gambar II.6 Value Chain (13) Menurut Porter (1985), primary activities terdiri atas : 1. Inbound logistic (input), material yang datang, diproses (bisa ditempat penyimpanan, gudang dan lain-lain) dan dalam pemrosesan ini ditambahkan nilai (added value). 2. Operations, material digunakan dalam operasi sehingga memberikan nilai lagi pada produk atau layanan. 3. Outbound logistic (storage and distribution), produk atau layanan perlu dipersiapkan untuk delivery (dapat berupa pengemasan, penyimpanan dan pengiriman). Kembali produk mendapat penambahan nilai. 4. Marketing and sales, berusaha menjual produk atau layanan ke konsumen, meningkatkan nilai produk atau layanan dengan menciptakan demand.
27
5. Services, merupakan after sales service yang diberikan pada konsumen untuk kembali memberikan nilai tambah.
Support activities terdiri atas : 1. Organizational infrastructure, terdiri atas sistem dan fungsi pendukung, contoh : finance, planning, quality control dan general senior management. 2. Human resource management, berhubungan dengan aktivitas rekruitmen, pengembangan, memotivasi, serta memberikan penghargaan pada tenaga kerja. 3. Technology
development,
berhubungan
dengan
aktivitas
pengaturan
pemrosesan informasi dan pengembangan serta proteksi “knowledge” dalam organisasi. 4. Procurement, berhubungan dengan bagaimana sumber daya dibutuhkan dalam organisasi (contohnya sourcing dan negosiasi dengan supplier).
II.6 Four Stage Life Cycle Business System Planning (BSP) Four stage life cycle (7) adalah tool yang digunakan untuk menemukan turunan dari fungsi bisnis yang terkait dengan produk atau layanan yang diberikan oleh fungsi bisnis tersebut. Four stage life cycle pada BSP digunakan pada tahap pendefinisian proses bisnis. Keempat siklus yang digunakan, yaitu : 1. Tahap I, Requirement, Planning, Measurement and Control. Aktivitas yang menentukan berapa banyak produk atau layanan yang dibutuhkan, rencana untuk mendapatkannya dan pengukuran serta kontrol yang terkait dengan rencana.
2. Tahap II, Acquisition. Aktivitas yang dilakukan untuk mengembangkan produk atau layanan atau untuk mendapatkan sumber daya yang akan dipergunakan untuk kegiatan pengembangan.
28
3. Tahap III, Stewardships. Aktivitas untuk membentuk, mempertajam, memodifikasi atau merawat dukungan sumber daya dan untuk menyimpan atau menelusuri produk atau layanan.
4. Tahap IV, Retirement/Disposition. Aktivitas dan keputusan yang mengakhiri tanggung jawab organisasi terhadap suatu produk/layanan atau isyarat terhadap berakhirnya penggunaan suatu sumber daya.
Siklus dari four stage life cycle dapat dilihat pada Gambar II.7 berikut ini. Pada gambar tersebut dapat dilihat bahwa pada proses antar siklus maupun sebuah siklus terdapat kelas-kelas data dari aktivitas yang dilakukan pada siklus tersebut. Kelas data dikategorikan ke dalam data perencanaan, data rangkuman statistik, data transaksi dan data inventaris.
Requirements (Kebutuhan) Data perencanaan
Acquisition (Akuisisi)
Data transaksi
Data rangkuman statistik
Data rangkuman statistik
Stewardship (Pengelolaan)
Gambar II.7 Four Stage Life Cycle (7)
Disposition (Disposisi)
Data transaksi
