Bab II Tinjauan Pustaka

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