64
BAB V Sintesis Usulan Daur Hidup Sistem Informasi Melalui kasus di Perpustakaan Universitas Kristen Petra terlihat bahwa penyebab ketidakmampuan sistem informasi beradaptasi justru dimulai dari pembentukan strategi bisnis yang tidak tepat. Karena itu perlu diupayakan sebuah sistem yang membantu proses pembentukan strategi bisnis yang dapat mencegah faktor keterbatasan wawasan staf teknologi informasi memberikan pengaruh negatif dalam proses pembentukan strategi bisnis tersebut. Bila dilihat lebih lanjut dari data empiris yang ditemukan, maka ditemukan bahwa proses pembentukan strategi bisnis dilakukan melalui beberapa kali pertemuan (rapat). Setelah keputusan diambil melalui beberapa pertemuan tersebut, maka strategi mengembangkan sistem informasi berbasis web dijalankan oleh divisi System Development, dan Software Development tanpa ada sebuah upaya yang mengevaluasi setiap perkembangan dan merevisi strategi bisnis bila diperlukan.. Roger T. Burlton mengusulkan prinsip-prinsip mengelola proses-proses bisnis yang terdiri dari sepuluh prinsip [10]. Prinsip kedelapan menyatakan bahwa setiap inisiatif pembaharuan harus selalu dilakukan melalui pendekatan iteratif, dan time-boxed. Prinsip ketujuh menyatakan bahwa proses pembaharuan tersebut harus dilakukan dari arah luar ke dalam, dan prinsip keenam menyatakan bahwa inisiatif pembaharuan harus menginspirasikan pemikiran yang dapat dibagikan (shared insight). Pada prinsip kedelapan Roger T. Burlton menyatakan bahwa setiap upaya perbaikan akan menghasilkan kesalahan-kesalahan lebih dulu sebelum dapat menentukan apa yang benar. Artinya setiap perubahan harus selalu dilaksanakan lebih dulu agar dapat diketahui apa kesalahannya. Untuk itu maka perlu ditetapkan adanya masa eksekusi yang singkat sebelum dilakukan evaluasi (review) atas upaya tersebut. Periode singkat inilah yang disebut sebagai time-
65 boxed. Periode eksekusi tidak boleh terlalu lama yang justru membuat upaya perbaikan akan menjadi terlambat. Proses eksekusi dan evaluasi berulang-ulang dalam waktu singkat inilah yang seharusnya menjadi dasar upaya perbaikan. Prinsip utamanya adalah incremental finding and execution. Pengetahuanpengetahuan yang didapatkan dari sebuah iterasi akan memperbaiki iterasi berikutnya dalam masa iterasi yang tidak terlalu lama. Prinsip ketujuh menyatakan bahwa upaya perbaikan harus dilakukan berdasarkan level-level tertentu. Tanpa memisahkan upaya analisis perbaikan dalam level-level tertentu, maka para analis akan terjebak dalan “analysis paralysis”. Upaya perbaikan diawali pada level tertinggi, yang kemudian menjadi lebih detail pada level-level berikutnya. Proses analisis dimulai dengan memperhatikan seluruh stakeholder yang terlibat dan memperhatikan interaksi stakeholder dengan organisasi. Dari level tersebut kemudian dilakukan dekomposisi hingga level aktifitas. Prinsip keenam menyatakan bahwa sesungguhnya yang berubah adalah orangorang dalam organisasi tersebut. Dalam setiap upaya perbaikan pasti didapatkan pengetahuan, pemahaman, dan solusi inovatif yang diperlukan oleh organisasi. Tanpa adanya upaya diseminasi pengetahuan tersebut, maka pengetahuan hanya akan dimiliki oleh orang-orang tertentu saja. Perlu dibuat mekanisme pengelolaan pengetahuan (knowledge management) yang menyimpan artifak pengetahuan dalam bentuk dokumen eksplisit yang menjembatani antara “knower” dan “solution stakeholder”. Intinya adalah perlu ada upaya perekaman dan diseminasi pengetahuan yang dikumpulkan dalam setiap iterasi perbaikan sehingga setiap iterasi perbaikan akan membangun dari pengetahuan yang telah dikumpulkan pada iterasi sebelumnya. Dari ketiga prinsip tersebut dan memperhatikan data-data empiris yang ditemukan pada bab 4, maka dapat disimpulkan prinsip-prinsip yang harus digunakan dalam upaya memperbaiki sistem pengembangan sistem informasi di perpustakaan Universitas Kristen Petra, yaitu:
66 1. Baik proses pembentukan strategi bisnis, maupun proses perencanaan, dan proses pengembangan sistem informasi harus dibagi ke dalam beberapa level detail tertentu. 2. Setiap level akan dilakukan pada iterasi terpisah, dan iterasi sebelumnya adalah proses analisis (atau pengembangan) dari level yang lebih tinggi dari level pada iterasi saat ini (proses dekomposisi). 3. Setiap pengetahuan dari iterasi sebelumnya digunakan untuk mengerjakan tujuan iterasi saat itu (incremental finding and execution). 4. Setiap iterasi dilakukan dalam waktu yang singkat (time-boxed) dan dilakukan evaluasi di akhir setiap iterasi (periodic evaluation). 5. Setiap pengetahuan yang didapatkan dalam iterasi harus disimpan agar dapat dimanfaatkan pada iterasi berikutnya (knowledge management). V.1 Usulan Daur Hidup Dengan memperhatikan seluruh prinsip manajemen proses dari Roger T. Burlton, dan secara khusus lima prinsip perbaikan sistem pengembangan sistem informasi di atas, maka diusulkan pendekatan daur hidup sistem informasi yang adaptif yang ditunjukkan pada gambar V.2. Pendekatan yang ditunjukkan pada gambar V.2 tersebut disusun dengan menggunakan urutan tahapan dari eight-stage system development life cycle (SDLC) yang ditulis oleh Turban yang dijelaskan pada bab II.4. Pemetaan daur hidup adaptif ke dalam eight stage SDLC ditunjukkan pada gambar V.1. Dari gambar pemetaan tersebut dapat diperhatikan beberapa hal, yaitu: 1. Tahap ke-2 dan ke-3 dari eight stage SDLC yang adalah proses pembentukan rancangan sistem informasi dijabarkan ke dalam tujuh tahap terpisah pada daur hidup adaptif yang diusulkan, yaitu tahap ke-2 hingga tahap ke-8. Pada daur hidup adaptif, tahap ke-2 hingga tahap ke-8 tidak hanya bertujuan membentuk rancangan sistem informasi saja, tetapi juga dimulai dari proses pembentukan strategi bisnis, hingga ke strategi sistem informasi untuk mengimplementasikan strategi bisnis tersebut.
67 2. Tahap ke-4 dari eight stage SDLC dijabarkan ke dalam dua tahap terpisah pada daur hidup adaptif, yaitu pada tahap ke-9, dan ke-10. Tahap ke-9 dari daur hidup adaptif bertujuan untuk membentuk rencana migrasi dari rancangan sistem informasi yang telah dibuat pada tahap ke-7 dan ke-8 dibandingkan dengan kondisi sistem informasi saat ini. Tahap ke-9 ini penting dilakukan karena hasil rancangan pada tahap ke-8 tidak akan menghasilkan beberapa
sistem
informasi
sehingga
perlu
ditentukan
urutan
pengembangannya. 3. Tahap ke-6 dan ke-7 dari eight stage SDLC disatukan ke dalam tahap ke-12 dari daur hidup adaptif yang diusulkan. Penyatuan ini hanya untuk menyederhanakan gambar walaupun pada tahap ke-12 dari daur hidup adaptif tetap harus dilakukan aktifitas-aktifitas yang berasal dari tahap ke-6 dan ke-7 dari eight stage SDLC. Pada pendekatan daur hidup adaptif yang ditunjukkan pada gambar V.1 dan V.2 tersebut digunakan istilah strategi bisnis, dan strategi sistem informasi. Penggunaan istilah ini sesungguhnya untuk mempermudah membedakan konteks sintesis. Sesungguhnya strategi sistem informasi adalah bagian dari strategi bisnis. Strategi bisnis adalah implementasi dan eksekusi dari model bisnis organisasi yang memperhatikan kondisi organisasi internal dan juga kompetisi dengan organisasi lainnya [22]. Implementasi model bisnis adalah penerjemahan model bisnis dalam aktifitas yang biasanya tidak berubah banyak, misalnya struktur organisasi. Sedangkan eksekusi model bisnis adalah penerjemahan model bisnis yang biasanya beradaptasi terhadap perkembangan sesaat, misalnya kebijakan dan peraturan, dan model proses bisnis. Penerapan model-model sistem informasi, misalnya customer relationship management, extended supply chain, knowledge management, atau decision support system dapat dipandang sebagai eksekusi model bisnis yang melibatkan teknologi informasi. Karena itu sesungguhnya strategi sistem informasi dari sebuah organisasi adalah bagian dari strategi bisnisnya. Dalam sistesis ini agar terdapat kejelasan dan kesederhanaan istilah, maka tetap digunakan istilah strategi bisnis untuk mewakili strategi bisnis non
68 teknologi informasi, dan istilah strategi sistem informasi untuk mewakili strategi bisnis yang melibatkan teknologi informasi.
Gambar V.1. Pemetaan usulan daur hidup adaptif ke eight stage SDLC
69
Gambar V.2 Pendekatan daur hidup adaptif yang diusulkan
70 V.2 Tahap 1: Project Initiation Project initiation adalah sebuah upaya untuk mengawali proyek, yaitu penunjukan kepala proyek, dan anggota-anggota tim. Penentuan ruang lingkup proyek, sekaligus batasan biaya, waktu, dan anggaran yang digunakan. Juga dapat ditentukan ruang-ruang dan kakas yang dapat digunakan oleh tim dalam mengerjakan tugasnya. V.3 Tahap 2: Pengumpulan Data Bisnis dan Sistem Informasi Saat Ini Pendekatan daur hidup sistem informasi diawali dengan menentukan strategi bisnis organisasi, kemudian menentukan strategi sistem informasi berupa arsitektur
data,
aplikasi,
dan
teknologi
yang
diperlukan
untuk
mengimplementasikan strategi bisnis tersebut (tahap 3 – 8). Setelah seluruh arsitektur ditetapkan dilanjutkan dengan melakukan pengembangan sistem informasi (tahap 9 – 10), implementasi (tahap 11), dan perawatan sistem informasi tersebut (tahap 13). Pembentukan strategi bisnis, dan strategi sistem informasi diarahkan untuk mencapai dua target yang disarankan oleh John Ward [31]. Setiap analisis dalam pendekatan ini harus dilakukan dengan pertimbangan untuk meraih: 1. Strategic alignment, yaitu keselarasan antara proses-proses bisnis dengan sistem informasi 2. Competitive advantage yaitu mendapatkan keunggulan terhadap pesaing dengan menggunakan sistem informasi. Untuk membentuk strategi bisnis tersebut diperlukan informasi mengenai organisasi itu sendiri, yaitu lingkungan bisnis internal dan lingkungan sistem informasi internal. Informasi mengenai lingkungan bisnis internal adalah: 1. Strategi Bisnis (tidak hanya sasaran bisnis tetapi cara yang digunakan untuk mencapai sasaran bisnis tersebut) : misi, visi, busines objectives, CSF (Critical Success Factor), rencana bisnis di setiap bagian organisasi. 2. Proses-proses bisnis saat ini, aktifitas, dan entitas-entitas informasi utama. Biasanya dirupakan dalam bentuk Functional Decomposition Diagram,
71 Process Flow Model, Entity Relationship Diagram, Data Flow Diagram, atau Activity / Entity Matrices. Tujuan utama langkah ini adalah mengetahui fungsi-fungsi baik fungsi utama (major function), maupun fungsi-fungsi minor yang dilakukan oleh organisasi. Definisi dari fungsi adalah sekumpulan aktifitas yang dilakukan dalam upaya menjalankan bisnis [28]. 3. Organizational
environment,
meliputi
struktur
organisasi,
aset
dan
kemampuan, dan faktor-faktor yang kurang terlihat (less tangible) seperti knowledge, kompetensi, values, style, culture dan relationships. Seluruh item tersebut dapat dibentuk menjadi business principles, yaitu prinsip-prinsip yang mendasari seluruh aktifitas dan strategi organisasi. Untuk memahami kondisi sistem informasi internal, maka informasi yang dikumpulkan adalah: 1. Mengumpulkan informasi mengenai seluruh aplikasi, file-file spreadsheet lokal yang digunakan oleh setiap bagian dalam organisasi. 2. Mengklasifikasi setiap aplikasi yang ditemukan ke dalam segmen portofolio aplikasi, yaitu strategic, high potential, key operational, dan support. 3. Mengidentifikasi cakupan dan kontribusi aplikasi pada organisasi (fungsifungsi bisnis mana yang dilayani). Termasuk kemungkinan peningkatan kualitas layanan aplikasi dengan melakukan wawancara terhadap senior manager divisi yang bersangkutan. 4. Mengumpulkan informasi mengenai kebijakan-kebijakan dan strategi sistem informasi sebelumnya. 5. Mengumpulkan informasi mengenai organisasi dan proses-proses sistem informasi termasuk : a. Fungsi, ukuran, struktur dan hubungan departemen sistem informasi dengan departemen lain, maupun individu-individu tertentu. b. Pengelolaan penyediaan sumberdaya teknologi informasi. c. Strategi outsourcing bagi sumberdaya teknologi informasi. d. Struktur IS/IT governance, termasuk proses-proses pengambilan keputusan yang ada. e. Bagaimana anggaran investasi sistem informasi disiapkan.
72
V.4 Tahap 3: Identifikasi Model Bisnis Setelah seluruh informasi dikumpulkan, langkah berikutnya yang sangat penting adalah mengidentifikasi model bisnis dari organisasi. Langkah ini menentukan secara jelas apa logika bisnis dari organisasi tanpa terganggu dari strategi, atau taktik sesaat dari organisasi. Analis perlu mengidentifikasi sembilan pilar pembangun bisnis dari model bisnis, meliputi value proposition, target customer, distribution channel, relationship, value configuration, core competency, partner network, cost structure, dan revenue model. Langkah ini sangat penting karena pilar-pilar yang dihasilkan pada langkah ini akan digunakan sebagai bahan analisis oleh langkah-langkah analisis berikutnya. V.5 Tahap 4: Pahami Kondisi Bisnis dan Lingkungan Bisnis Setelah model bisnis diidentifikasi, maka pada tahap ke-4 dilakukan analisis untuk mengetahui kondisi bisnis organisasi, lingkungan eksternal bisnis, dan posisi organisasi di dalam lingkungan eksternal bisnis. Untuk melakukan analisis tersebut dapat digunakan beberapa kakas, misalnya Boston Consulting Group Matrix, Value Chain, Competitive Analysis Porter, SWOT, dan kakas lain. Hal yang penting dilakukan dalam proses pemahaman kondisi bisnis adalah menentukan kakas yang diperlukan sesuai dengan karakteristik organisasi. Organisasi non profit akan kesulitan menggunakan Boston Consulting Group Matrix (BCG) karena orientasi kakas tersebut adalah pada value yang dapat dinilai dengan uang. Demikian juga pada kasus di perpustakaan Universitas Kristen Petra, BCG matrix sulit digunakan karena return value dari anggota bukanlah uang tetapi loyalitas. Tetapi bagaimanapun juga BCG matrix masih dapat digunakan bila pada suatu saat perpustakaan memiliki unit bisnis yang digunakan untuk mendapatkan keuntungan dari para pengguna perpustakaan. Pada tahap ke-4 juga digunakan proses penggambaran Value Network untuk menggambarkan seluruh aset yang beredar, baik tangible maupun intangible asset, baik berupa produk atau jasa antar entitas internal dalam organisasi, dan dengan entitas di luar organisasi. Penggunaan metode Value Network, dan bukan
73 metode Value Chain disebabkan adanya beberapa keterbatasan Value Chain [8], yaitu: 1. Pendekatan linier dari inbound logistic hingga ke outbound logistic sangat dipengaruhi oleh proses-proses dalam industri manufaktur. Padahal dalam kondisi bisnis modern alur informasi atau aset dapat berasal dari mana saja, dan mengarah ke mana saja. Pendekatan mekanistis dan linier dari Value Chain tidak lagi memadai untuk menggambarkan proses produksi saat ini. 2. Dalam Value Chain biasanya yang digambarkan adalah tangible value, padahal dalam dunia informasi saat ini intangible value juga sangat penting bagi organisasi. 3. Value network dapat digunakan pada berbagai jenis organisasi, baik profit, maupun non profit, manufaktur maupun industri jasa. Dengan demikian Value Network lebih cocok digunakan untuk menganalisis aliran aset dan informasi di perpustakaan yang memiliki jasa distribusi informasi daripada value chain. V.6 Tahap 5 dan 6: Analisis Peluang Bisnis Setelah informasi mengenai lingkungan bisnis dan sistem informasi internal diketahui, dan juga pengetahuan mengenai kondisi bisnis organisasi dan lingkungan bisnis yang mengelilingi organisasi, maka pada tahap ke-5, dan ke-6 dilakukan analisis untuk mengetahui kesempatan-kesempatan yang dapat dimanfaatkan oleh organisasi. Tahap ke-5 menggunakan orientasi target bisnis, sedangkan tahap ke-6 menggunakan orientasi informasi yang dipertukarkan baik di dalam, maupun dengan pihak luar organisasi. Analisis peluang berorientasi target bisnis adalah mengetahui apa yang penting bagi organisasi menggunakan kakas seperti Balanced Scorecard (BSC), dan Critical Success Factor (CSF). Menggunakan kedua kakas tersebut harus ditemukan: 1. Aktifitas yang harus dilakukan oleh organisasi yang berkontribusi secara langsung pada pencapaian sasaran bisnis. Dari aktifitas ini kemudian harus
74 ditentukan informasi, dan aplikasi yang dibutuhkan untuk mendukung aktifitas tersebut. 2. Aktifitas yang harus dilakukan oleh organisasi untuk mengawasi dan mengevaluasi aktifitas jenis pertama. Dari aktifitas ini juga harus ditemukan informasi,
dan
aplikasi
yang
diperlukan
untuk
mendukung,
atau
memungkinkan aktifitas tersebut terjadi (enabler). Analisis kesempatan berorientasi informasi menggunakan diagram Value Network yang telah dibuat pada tahap ke-4. Dengan menggunakan diagram tersebut dilakukan dua analisis, yaitu: 1. Value Impact Analysis Analisis ini bertujuan mengetahui masalah, dan kesempatan diperoleh akibat informasi dan aset (produk, dan jasa) yang diterima oleh organisasi yang berasal dari entitas luar. Pada analisis ini dapat dicari keuntungan yang didapatkan bila ada informasi baru yang bisa diperoleh organisasi yang belum dimiliki sebelumnya. 2. Value Creation Analysis Analisis ini bertujuan untuk mengetahui keuntungan yang dapat diperoleh bila organisasi membuat value bagi entitas lain. Keuntungan yang didapat misalnya adanya loyalitas dari konsumen, atau suplier terhadap organisasi. Setiap analisis dilakukan pada dua jenis pertukaran informasi, atau aset, yaitu: 1. Antara organisasi dengan entitas eksternal. 2. Antara entitas internal di dalam organisasi. Jenis pertukaran kedua dapat digunakan dalam analisa untuk keperluan strategic alignment, sedangkan jenis pertukaran pertama dapat digunakan untuk meraih competitive advantage. Sama seperti analisis peluang berorientasi target bisnis, pada analisis ini harus ditentukan informasi, dan aplikasi-aplikasi yang dibutuhkan untuk mewujudkan aset-aset baru yang dapat diberikan pada entitas lain, maupun untuk memanfaatkan aset yang diterima dari entitas lain.
75
V.7 Tahap 7 dan 8: Pembentukan Strategi Bisnis dan Strategi Sistem Informasi Hingga tahap ke-6 telah dikumpulkan informasi yang diperlukan untuk membentuk strategi bisnis, sekaligus strategi sistem informasi. Informasi yang telah dikumpulkan berupa: 1. Informasi mengenai kondisi internal organisasi yang berorientasi bisnis dan sistem informasi 2. Lingkungan bisnis eksternal organisasi 3. Posisi organisasi terhadap lingkungan bisnis eksternal 4. Kesempatan-kesempatan
yang
dapat
diraih
oleh
organisasi
dengan
menggunakan informasi atau aplikasi tertentu. Untuk membentuk strategi bisnis, sekaligus strategi sistem informasi diperlukan kerangka kerja perencanaan arsitektur sistem informasi yang juga menyediakan kesempatan untuk membentuk strategi bisnis. Beberapa kerangka kerja perencanaan enterprise architecture dianalisis untuk mengetahui dukungan terhadap pembentukan strategi bisnis yang lebih luas dari strategi sistem informasi, yaitu The Open Group Architecture Framework (TOGAF), implementasi Zachman Framework seperti Enterprise Architecture Planning dari Spewak [28] dan pendekatan implementasi dari Melissa A. Cook [12], dan Business System Planning (BSP) dari International Business Machine (IBM) [2]. Dari beberapa kerangka kerja tersebut disimpulkan bahwa TOGAF memiliki fasefase yang membantu organisasi merencanakan strategi bisnisnya, yaitu: fase A (Architecture Vision), dan fase B (Business Architecture) sedangkan kerangkakerja yang lainnya lebih kepada upaya menerjemahkan strategi bisnis yang sudah dibentuk sebelumnya ke dalam arsitektur data, aplikasi, dan teknologi yang diperlukan oleh strategi bisnis tersebut. Sedangkan kerangka kerja lainnya lebih berorientasi pada pembentukan strategi sistem informasi tanpa mengubah strategi bisnis yang sudah ada.
76 Alasan lainnya untuk memilih TOGAF adalah bahwa fase-fase di dalamnya dilakukan menurut prinsip iterasi. Dalam TOGAF hasil perencanaan strategi dibagi ke dalam beberapa level, dan tiap fase akan menambah detail dari strategi yang dibentuk dari fase sebelumnya hingga membentuk kedalaman strategi yang memadai untuk implementasi strategi tersebut. Hal ini sesuai dengan prinsip manajemen proses yang diusulkan oleh Roger T. Burlton di atas. Metode perencanaan enterprise architecture lainnya menggunakan pendekatan satu iterasi saja dimana sebuah strategi langsung dibuat sesuai level detail tertentu tanpa ada upaya kembali ke awal fase untuk menambah detail strategi. Dari fase-fase dalam TOGAF tidak seluruh fase digunakan dalam pendekatan yang dihasilkan oleh sistesis ini. Fase dari TOGAF yang digunakan adalah fase yang digunakan untuk membentuk strategi bisnis, dan strategi sistem informasi saja. Fase-fase tersebut adalah fase A (Architecture Vision), fase B (Business Architecture), fase C (Information System Architecture), dan fase D (Technology Architecture). Demikian pula fase-fase tersebut disederhanakan dalam aspek dokumen yang dihasilkan dan aspek urutan pengerjaan dalam setiap fase. Hal ini diperlukan karena perpustakaan Universitas Kristen Petra adalah organisasi yang kecil yang tidak memiliki sumber daya yang memadai untuk mengerjakan seluruh fase dalam TOGAF secara sepenuhnya. Fase-fase TOGAF yang disederhanakan inilah yang mendasari proses pembentukan strategi bisnis dan strategi sistem informasi pada tahap ke-7 dan ke8. Proses pembentukan strategi bisnis dan strategi sistem informasi dimulai dengan membentuk business scenario. Business Scenario adalah sebuah upaya analisis untuk memahami bagaimana proses-proses dalam organisasi dijalankan, siapa saja yang terlibat dan kebutuhan yang harus dipenuhi agar skenario bisnis tersebut dapat berjalan. Kebutuhan ini dapat berorientasi saat ini, maupun peluang yang dapat diambil untuk lebih kompetitif di masa depan.
77 Business scenario terdiri dari: 1. Tujuan skenario 2. Lingkungan dan model proses: a. Deskripsi proses b. Proses yang dipetakan pada divisi yang mengerjakannya c. Aliran informasi 3. Aktor dan tanggungjawabnya: a. Aktor manusia, peran, dan tanggung jawabnya b. Aktor komputer, peran, dan tanggung jawabnya 4. Kebutuhan dari skenario ini Pada perpustakaan business scenario dapat dibuat untuk proses pembelian bahan pustaka dari penerbit, proses diseminasi informasi, atau proses-proses harian dalam rangka transaksi sirkulasi bahan pustaka. Tidak diharuskan seluruh business scenario mencapai level detail tertentu pada iterasi pembuatan business scenario awal karena dapat dibuat menjadi lebih detail melalui dekomposisi business scenario pada iterasi-iterasi pembuatan business scenario selanjutnya. Hal ini sangat penting terutama untuk organisasi berskala besar yang tidak mungkin dapat mendeskripsikan keseluruhan proses secara detail hanya melalui satu iterasi saja. Setelah business scenario awal telah menggambarkan keseluruhan proses yang terjadi dalam organisasi walaupun belum dalam detail yang lengkap (baru melalui satu iterasi pembentukan business scenario), maka proses dilanjutkan pada tahap pembentukan Business Architecture. Business Architecture adalah sebuah model yang menggambarkan struktur bisnis baik dalam orientasi proses bisnis, maupun orientasi teknologi informasi. Business architecture terdiri dari: 1. Struktur organisasi. 2. Fungsi-fungsi bisnis yang didekomposisi mulai dari fungsi utama hingga sub fungsi (functional decomposition diagram).
78 3. Architecture Building Block (ABB) yang terdiri dari: a. Business Process Model. b. Architectural Model yang terdiri dari: i. Data block ii. Application block Langkah pertama dalam pembentukan business architecture adalah identifikasi struktur organisasi, dan pembentukan functional decomposition diagram. Functional decomposition diagram telah dibuat pada tahap pertama. Dari dua informasi tersebut dan dengan menggunakan beberapa business scenario yang telah dibuat pada tahap sebelumnya maka dibuat architecture building block (ABB). ABB pertama yang dibuat menggambarkan blok-blok pembangun dari model proses atau fungsi dari organisasi, yaitu business process model. Tentunya bila saat ini adalah iterasi pertama maka blok-blok pembangun akan memberikan gambaran global dari model proses organisasi. Setelah business process model dibangun, maka dengan menggunakan informasi mengenai aktor manusia dan komputer dalam business scenario, business process model, dan informasi mengenai aplikasi-aplikasi yang telah ada saat ini (telah dikumpulkan pada tahap ke-1) dibangun architecture building blok yang menggambarkan konfigurasi perangkat lunak, perangkat keras dan data yang digunakan untuk mendukung business scenario dan business process model tersebut. Pada iterasi berikutnya pembuatan business scenario dilakukan ulang untuk mendapatkan detail dari sub business scenario. Demikian pula architecture building block yang menggambarkan business process model, dan architectural model direvisi sesuai dengan detail-detail yang didapatkan dari business scenario yang baru. Bila pada iterasi sebelumnya ABB dibuat pada level organisasi, maka dimungkinkan pada iterasi ini ABB dibuat untuk level divisi dalam organisasi. Iterasi pembentukan business scenario dan architecture building block diulangi hingga didapatkan architectural model yang memadai untuk masuk pada proses
79 pengembangan blok-blok tersebut (baik blok perangkat lunak, blok data, maupun perangkat keras). Proses pembentukan business process model, dan architectural model dalam architecture building block dalam beberapa iterasi memungkinkan digunakannya prinsip kreatif atau inovatif yang berusaha menjawab kebutuhan-kebutuhan telah yang diidentifikasi pada business scenario, peluang-peluang bisnis yang didapatkan pada tahap ke-5 dan ke-6, dalam rangka menerjemahkan pilar value proposition dan value configuration dari model bisnis yang ditetapkan pada tahap ke-3. Pada setiap iterasi setiap orang yang terlibat dalam perencanaan akan berusaha memperbaiki proses-proses bisnis baik dengan, atau tanpa, keterlibatan teknologi informasi, dan memperbaiki architectural model sehingga mendukung fungsi-fungsi
dan
proses-proses
bisnis
tersebut
dengan
memanfaatkan
perkembangan teknologi dengan lebih baik. Pada tahap ke-7, dan ke-8 inilah proses pembentukan strategi bisnis, dan strategi sistem informasi dilakukan. Dalam proses pembentukan architectural model juga ditetapkan arsitektur teknologi yang mendasari pembentukan architectural model tersebut. Sebuah organisasi dapat memanfaatkan teknologi service oriented architecture (SOA) sehingga setiap blok aplikasi dianggap sebagai kumpulan client-server penyedia dan
peminta
layanan
mempertahankan
(service).
sebanyak
Organisasi
mungkin
yang
portofolio
lain
aplikasi
dapat lama
berusaha dengan
menggunakan blok-blok aplikasi monolitik yang memerlukan middleware sebagai alat komunikasi atau transfer data antar blok monolitik tersebut. Pada proses pembuatan architectural model setiap blok data dan blok aplikasi harus dievaluasi terus menerus untuk memastikan bahwa setiap fungsi dalam functional decomposition diagram, dan setiap proses dalam business process model telah diakomodasi. Hal ini diperlukan untuk menjamin bahwa architectural model yang baru tidak melupakan fungsi-fungsi, atau proses-proses bisnis tertentu. Juga dibentuk matriks blok aplikasi vs blok data yang menunjukkan
80 operasi (create, reference, update, delete) dari setiap blok aplikasi terhadap blok data. Setelah seluruh iterasi selesai, dan architectural model telah lengkap, maka langkah berikutnya adalah menentukan klasifikasi dan prioritas dari setiap blok aplikasi. Proses klasifikasi blok aplikasi menggunakan usulan dari F. W. McFarlan [30] yang membagi aplikasi menjadi empat kategori, yaitu: 1. High potential. Aplikasi yang mungkin penting dalam mencapai keberhasilan organisasi di masa depan. 2. Key operational. Aplikasi dimana organisasi saat ini bergantung agar berhasil. 3. Strategic. Aplikasi yang kritis bagi strategi bisnis masa depan. 4. Support. Aplikasi yang saat ini bernilai bagi organisasi tetapi tidak kritis bagi kesuksesan organisasi. V.8 Tahap 9: Migration Planning Penentuan urutan pengembangan atau pengadaan blok aplikasi dilakukan pada tahap ke-9, yaitu migration planning. Dengan memperhatikan data mengenai aplikasi yang ada pada saat ini yang dibuat pada tahap ke-2 (current portfolio), dan portofolio aplikasi yang dibuat pada tahap ke-8 (target portfolio), maka dilakukan analisis untuk melihat selisih di antara keduanya. Dari kedua daftar harus diidentifikasi mana aplikasi dari tahap ke-8 yang adalah aplikasi baru, aplikasi yang mengalami perubahan besar, aplikasi yang mengalami perubahan kecil, aplikasi yang tidak mengalami perubahan sama sekali, aplikasi yang merupakan gabungan dari beberapa aplikasi yang lama, dan aplikasi yang merupakan pecahan dari aplikasi yang lama. Dan dari daftar aplikasi dari tahap ke-2 dibuat daftar aplikasi yang tidak dibutuhkan lagi. Proses selanjutnya pada tahap ke-9 ini adalah membentuk peta migrasi aplikasi dengan memanfaatkan: 1. Daftar-daftar aplikasi yang dibuat di atas. 2. Klasifikasi aplikasi yang dibuat pada tahap ke-8. 3. Matriks blok aplikasi vs blok data (CRUD) yang dibuat pada tahap ke-8.
81 Setiap aplikasi dalam peta akan dihubungkan dengan garis yang menunjukkan urutan pengembangan, atau pengadaan. V.9 Tahap 10: Proses Pengembangan Blok Arsitektur Pada tahap ke-10 dimulai proses pengembangan untuk setiap blok aplikasi. Proses pengembangan blok aplikasi tetap harus menggunakan prinsip iteratif, yaitu proses pengembangan dilakukan berdasarkan beberapa level detail dimana setiap detail dikembangkan melalui sebuah iterasi tertentu. Pengembangan proses iteratif ini memungkinkan adanya revisi yang tidak terlalu banyak dari hasil yang dicapai sebelumnya karena iterasi berjalan dalam waktu yang singkat, dan proses evaluasi pun bisa dilakukan dengan segera. Bila diterapkan pada kasus di perpustakaan Universitas Kristen Petra, maka evaluasi formal terhadap proses pengembangan dari blok apliksi pertama akan segera menunjukkan kesulitan-kesulitan yang dialami dalam proses pengembangan aplikasi berbasis web. Hasil evaluasi dapat diarahkan untuk mengevaluasi platform teknologi yang digunakan dalam strategi sistem informasi perpustakaan. Pada saat ini terdapat dua kelompok besar metode pengembangan aplikasi yang menggunakan prinsip iterasi dan incremental, yaitu incremental model seperti yang digunakan oleh Unified Process, dan agile software development yang digunakan oleh Dynamic Software Development Model (DSDM), Scrum, dan Extreme Programming (XP). Walaupun sama-sama menggunakan prinsip incremental dimana setiap iterasi berikutnya menambahkan detail, atau bagian baru, pada hasil iterasi sebelumnya, tetapi kedua model pengembangan aplikasi berbeda dalam ukuran waktu iterasi. Setiap iterasi pada incremental model dapat berlangsung beberapa bulan, sedangkan setiap iterasi dalam agile software development berlangsung jauh lebih singkat, contohnya selama satu minggu, dua minggu, atau satu bulan. Karena itu diputuskan dalam pendekatan yang dibentuk digunakan agile sofware development dalam proses pengembangan blok aplikasi. Ketiga metode
82 pengembangan aplikasi berbasis agile software development, yaitu Dynamic System Development Method (DSDM) [5], Scrum [6], dan Extreme Programming (XP) [4] dianalisis untuk mengetahui metode manakah yang paling cocok diterapkan di perpustakaan Universitas Kristen Petra, dan apakah dapat dihubungkan dengan tahap-tahap lain pada keseluruhan pendekatan daur hidup sistem informasi ini. Hasil dari analisis menunjukkan bahwa: 1. Seluruh jenis metode mensyaratkan jumlah programmer yang kecil sehingga interaksi dan komunikasi dapat berjalan sangat intensif dalam proses pengambilan keputusan di setiap tahap pengembangan. Jumlah programmer di perpustakaan Universitas Kristen Petra berjumlah tidak lebih dari 5 orang sehingga sangat sesuai untuk metode-metode ini. 2. Analisis lebih lanjut menunjukkan bahwa syarat berikutnya tidak terpenuhi, yaitu seluruh programmer tersebut memiliki kualifikasi sebagai senior programmer. Kualifikasi ini sangat penting karena pada agile software development setiap programmer harus dipercaya untuk membuat analisis dan desainnya sendiri setelah melakukan
komunikasi
dengan
pengguna.
Programmer yang kurang cakap akan menghasilkan desain aplikasi yang tidak mudah dipahami oleh programmer lain, dan tidak scalable. Sebagian programmer di perpustakaan Universitas Kristen petra masih berstatus sebagai mahasiswa sehingga pengalaman dan wawasan pengembangan dapat mengurangi kualitas proses requirement analisys, analisis dan desain bagian aplikasi tersebut. DSDM memberikan sedikit peluang untuk mengurangi masalah yang mungkin timbul karena pada DSDM proses pembentukan functional requirement beserta seluruh prototypenya diletakkan pada fase yang berbeda, sedangkan pada Scrum dan XP hal tesebut dilakukan pada fase yang sama (bahkan dapat dilakukan berulang-ulang dalam satu hari bila memang dibutuhkan). Dengan adanya pemisahan functional model iteration, dan design and build iteration maka senior programmer dapat melakukan proses prototyping untuk mencatat functional dan non functional requirement beserta metode terbaik yang diusulkan untuk mewujudkan requirement tersebut, dan pada design and build iteration junior programmer membentuk
83 working prototye sesuai arahan dari senior programmer pada iterasi sebelumnya. 3. Dokumen pengembangan dalam agile software development sering tidak menjadi perhatian utama. Tidak terdapat tahap requirement analysis, analysis, dan design yang formal, dan programmer disarankan untuk langsung menghubungi user, menganalisa permintaan dari user, dan langsung mengaplikasikannya menjadi baris-baris kode membuat dokumen seringkali ditinggalkan. Walaupun dokumen yang dihasilkan tetap lebih sedikit dibandingkan incremental model, DSDM masih memberikan pendekatan yang lebih baik dibandingkan dua metode agile lainnya. Pada DSDM terdapat tahapan business study, dan functional model iteration yang secara formal melakukan analisis pada tahapnya masing-masing dan menghasilkan dokumen yang dapat disimpan yang ditunjukkan pada tabel V.1. Sedangkan dokumen yang dihasilkan oleh Scrum pada intinya adalah backlog dan turunan dari backlog, sedangkan yang dihasilkan oleh XP adalah user story dan CRC. Dokumen-dokumen tersebut tidak menunjukkan pertimbangan-pertimbangan yang diambil dalam proses analisis dan desain. Untuk mengatasi masalah ini setiap programmer diminta untuk mencatat seluruh pertimbangan yang diambil dalam proses analysis dan design dan mencatatnya dalam setiap kode yang ditulis. Selain itu juga akan digunakan kakas yang dapat membuat dokumen secara otomatis dengan menganalisa isi dan hubungan antar setiap komponen dalam baris-baris kode. Tabel V.1 Produk yang dihasilkan dalam DSDM Fase
Produk yang dihasilkan
Business Study
1. 2. 3. 4. 5. 1.
Functional Model Iteration
2. 3. 4. 5. 6.
Business Area Definition Prioritised Requirements List System Architecture Definition Development Plan Updated Risk Log Functional Model (including Functional Prototypes) Functional Model Review Records Non-Functional Requirements List Timebox Plans Implementation Plan Risk Log
84 Sumber: ---, Product Overview, DSDM Consortium, http://www.dsdm.org/version4/2/public/product_overview.html diakses pada tanggal 4 Juni 2007 4. Seluruh metode agile software development menggunakan iterasi yang pendek berkisar antara satu minggu hingga satu bulan dalam menghasilkan working prototype. Interaksi dengan user dalam setiap iterasi dilakukan secara intensif mulai dari menentukan requirement baik functional maupun non-functional, analysis, design, dan testing. Interaksi ini begitu tinggi sehingga timbul kritik bahwa pada akhirnya user yang mewakili organisasi yang memiliki aplikasi yang terlibat dalam tim akan mengalami kesulitan dalam mengerjakan pekerjaannya sendiri. Staf non TI pada perpustakaan Universitas Kristen Petra memiliki jumlah yang relatif sedikit sehingga muncul kesulitan untuk meminta salah satu stafnya terlibat dalam tim. Dan user perwakilan organisasi seharusnya adalah user yang memiliki kedudukan cukup tinggi agar memiliki wawasan dan pengetahuan yang cukup untuk mengambil keputusan, dan juga kewenangan mengambil keputusan itu sendiri tanpa harus setiap kali berhubungan dengan organisasi yang mengirimnya. DSDM memberi kebebasan dalam menentukan waktu iterasi yang lebih panjang dibandingkan dua metode lainnya, dan dengan adanya pemisahan fase functional model dan fase design and build interaksi dengan user dapat dikurangi karena iterasi design and build yang lebih panjang tidak lagi memerlukan intensitas komunikasi dengan user setinggi seperti yang dibutuhkan fase functional model. 5. Seluruh metode agile software development yang dianalisis mensyaratkan tidak adanya interupsi pada iterasi pengembangan. Interupsi akan mengganggu keseluruhan jadwal pada iterasi tersebut, dan pada DSDM bahkan dapat mengganggu keseluruhan proyek. Interupsi yang mungkin muncul pada kasus di perpustakaan Universitas Kristen Petra adalah permintaan data dari jurusan, dan rencana mengembangkan aplikasi yang tidak menjadi prioritas sebelumnya. Untuk mengatasinya harus dibuat sebuah komitmen bahwa pengembangan aplikasi baru yang belum menjadi prioritas sebelumnya harus dilaksanakan setelah sebuah proyek selesai. Dan dibuat sebuah sarana
85 sehingga permintaan data dari jurusan dapat ditangani langsung oleh divisi Pengolahan tanpa perlu melibatkan divisi Software Development lagi. Dengan memperhatikan analisis di atas, maka diputuskan bahwa metode agile software development yang lebih tepat untuk kondisi di perpustakaan Universitas Kristen Petra adalah Dynamic Software Development Method (DSDM) dibandingkan metode Scrum, dan Extreme Programming (XP). DSDM terdiri dari lima fase, ditambah dengan fase pendahuluan (pre-project), dan fase penutup (post-project). Kelima fase tersebut adalah feasibility study, business study, functional model iteration, design and build iteration, dan implementation. Fase feasibility study, dan business study sudah dilakukan secara tidak langsung pada tahap ke-7 dan ke-8 pada proses pembentukan strategi bisnis, dan strategi sistem informasi. Business area definition dan system architecture definition yang seharusnya menjadi produk dari fase business study sudah dihasilkan pada tahap ke-8 sebagai architectural model. Setiap building block dalam architectural model telah menyebutkan fungsi-fungsi dan proses-proses bisnis yang harus dipenuhi oleh blok tersebut, juga pihak-pihak yang terlibat (divisi-divisi, dan tanggung jawabnya), arsitektur data yang dibutuhkan untuk menunjang blok (termasuk operasi pada data – CRUD), termasuk aplikasi-aplikasi lain yang bekerja sama dengan blok aplikasi tersebut. Yang belum dihasilkan dari tahap ke-7 dan ke-8 dibandingkan dengan tahapan DSDM adalah development plan untuk setiap building block. Development plan adalah hasil dari proses perencanaan aktifitas yang berusaha mengidentifikasi prototype apa saja yang diperlukan untuk menghasilkan working prototype. Seperti halnya seluruh metode agile software development yang lain, proses pengembangan dalam agile development menggunakan prototype yang selalu dikembangkan dalam iterasi-iterasi yang singkat dan selalu mendapatkan review dari user. Pada akhir pengembangan adalah working prototype yang telah
86 mendapatkan acceptance dari user setelah melalui proses testing. Dengan menggunakan metode pengembangan seperti ini user selalu terlibat dalam setiap aspek dari working prototype mulai dari requirement analysis, analysis dan design, dan testing. Pada awal tahap ke-10 dilakukan proses pembuatan development plan. Tujuan pembuatan development plan adalah: 1. Membuat prioritas aktifitas pembuatan prototype 2. Menidentifikasi kategori-kategori prototype yang diperlukan untuk building block tersebut, dan kapan dilakukan 3. Menentukan mekanisme untuk menentukan kapan aktifitas pembuatan prototype dapat dihentikan. 4. Menentukan individu-individu baik
dari user maupun programmer yang
mengambil tanggung jawab pengembangan dalam setiap iterasi. Setelah development plan dibentuk, maka proses pengembangan blok aplikasi (tahap ke-10) masuk pada proses iterasi yang berulang dalam menghasilkan prototype mulai dari functional prototype hingga menjadi working prototype. Iterasi-iterasi yang berulang terbagi ke dalam dua fase, yaitu functional model iteration, dan design and build iteration. Functional model iteration bertujuan menghasilkan dokumen dan functional prototype yang mendefinisikan functional requirements, dan beberapa non functional requirements. Design and build iteration bertujuan mengimplementasikan functional prototype menjadi working prototype dengan standar pengembangan yang tinggi yang ditentukan dalam coding principles. Pada iterasi-iterasi dalam fase ini seluruh kriteria non functional requirements harus dipenuhi seperti masalah security, dan performance. DSDM juga lebih mendukung penerapan manajemen proyek pengembangan dibandingkan dengan Extreme Programming (XP). Pada Extreme Programming
87 proses pengembangan berprinsip “apa yang bisa dilakukan besok, jangan dilakukan saat ini”. Hal ini mendasari setiap iterasi Extreme Programming sehingga user story-user story yang belum ditetapkan untuk diimplementasikan pada iterasi tersebut akan disimpan dan tidak boleh dipertimbangkan dalam proses pengembangan, hingga akhirnya jadwal pengembangan user story tersebut tiba. Hal ini mengakibatkan tidak ada seorangpun yang dapat mengatakan kapan seluruh proyek akan diselesaikan. Di sisi lain DSDM justru menetapkan kapan keseluruhan proyek harus diselesaikan melalui outline plan, dan kapan setiap iterasi harus diselesaikan melalui development plan, dan apakah dan kapankah aktifitas-aktifitas harus dikerjakan di setiap iterasi melalui timebox plan. Perbedaan dengan manajemen proyek tradisional adalah manajemen proyek tradisional menetapkan secara pasti dan detail seluruh aktifitas yang harus dikerjakan, sumber daya yang harus disediakan, dan resiko yang harus ditangani sejak awal proyek, bahkan saat proyek tersebut belum dimulai. Manajemen proyek dalam DSDM juga menganut prinsip incremental. Pada awal proyek detail proyek ditetapkan secukupnya agar bisa memulai proyek, setelah didapatkan informasi detail yang lebih lengkap (misalnya: protoype, dan functional requirement) detail proyek akan disesuaikan dengan informasi tersebut. Bila sebuah iterasi diperkirakan tidak dapat menyelesaikan seluruh target pengembangan pada iterasi tersebut, maka requirements yang bukan must-have requirements (should have, could have, dan want to have but won’t have this time) dapat dipindahkan pada iterasi selanjutnya. Pada akhir setiap iterasi pengembangan pada fase design and build selalu dilakukan pengujian untuk memeriksa apakah working prototype telah sesuai dengan functional dan non functional requirements. Dengan menggunakan pendekatan ini maka pada akhir setiap iterasi selalu dihasilkan penambahan produk tanpa harus menunggu akhir proyek keseluruhan. Dengan demikian user dapat lebih mempercayai perkembangan proyek, dan memastikan bahwa hasil akhir akan sesuai dengan harapannya.
88 Setelah proyek pengembangan untuk building block tersebut selesai, maka daur hidup sistem informasi kembali ke tahap ke-9. Pada tahap ini ditentukan building block apa lagi yang harus dikerjakan melalui tahap ke-10 sesuai peta pengembangan yang telah dibuat sebelumnya. Bila seluruh building block yang diperlukan untuk implementasi telah selesai dikembangkan, maka daur hidup dapat memasuki tahap ke-11, yaitu implementasi. V.10 Tahap 11: Implementasi Tahap ke-10 meliputi proses konversi sistem yang lama ke sistem baru, migrasi data bila diperlukan oleh sistem baru, dan pelatihan user agar dapat menggunakan sistem yang baru. Proses konversi memiliki beberapa pendekatan yang dapat dipilih sesuai kebutuhan organisasi, yaitu: 1. Parallel conversion. Sistem lama dan baru beroperasi bersama-sama selama masa pengujian. Bila sistem baru dianggap telah mampu menggantikan sistem lama, maka sistem lama dihentikan. 2. Direct cutover.
Sistem lama dihentikan dan sistem baru langsung
diberlakukan. Pendekatan ini paling cepat, tetapi juga memiliki resiko paling besar. 3. Pilot conversion. Sistem baru diberlakukan pada sebagian lokasi saja, misalnya pada sebuah cabang. Pendekatan ini mirip dengan direct cutover pada cabang tertentu, tetapi secara keseluruhan adalah parallel conversion. Phased (or modular) conversion. Sebuah sistem besar dapat terdiri dari beberapa modul terpisah. Sebagian modul dapat diganti dengan sistem baru, sedangkan modul-modul lain masih menggunakan sistem lama. Pendekatan ini mungkin dilakukan bila sistem lama terbagi menjadi beberapa modul independen. V.11 Tahap 12: Operation dan Post Audit Tahap ke-12 adalah tahap dimana seluruh sistem informasi telah diimplementasi, dan mulai digunakan dalam operasi sehari-hari oleh organisasi. Pada tahap ini juga dilakukan post audit untuk mengevaluasi kinerja seluruh proses pengembangan sistem informasi mulai dari tahap ke-1 hingga tahap ke-11.
89 V.12 Tahap 13: Proses Perawatan Sistem Informasi Daur hidup sistem informasi memasuki tahap ke-13, yaitu upaya perawatan sistem bila terdapat perubahan kebutuhan pada organisasi tersebut, dan perlu adanya perbaikan pada sistem yang telah terimplementasi. Proses perawatan sistem ditunjukkan pada gambar V.3 [24].
Gambar V.3. Proses perawatan dari IEEE Fase-fase perawatan dari IEEE meliputi: 1. Classification, identification dan prioritization. Proses perawatan dimulai dari modification
request,
yaitu
permintaan
perubahan
dari
user
yang
menggunakan sistem. Setiap permintaan perubahan akan diklasifikasikan apakah termasuk permintaan perbaikan (correction), atau penambahan fasilitas (enhancement). Setiap permintaan perubahan kemudian diberi nomor, dan ditentukan prioritasnya dibandingkan dengan permintaan-permintaan perubahan yang lain. 2. Analysis. Fase analisis bertujuan menentukan akibat dari modifikasi, solusisolusi alternatif (elemen-elemen modifikasi), rencana pengujian, dan rencana implementasi. 3. Design. Fase ini bertujuan untuk melakukan proses desain modifikasi, seperti halnya fase desain dalam proses pengembangan sistem.
90 4. Implementation. Fase implementasi bertujuan mengaplikasikan hasil analisis dan desain, melakukan pengujian terhadap modifikasi yang dilakukan, dan analisis resiko. 5. System test. System test adalah fase untuk memeriksa keseluruhan modifikasi ketika digabungkan dengan sistem secara keseluruhan. Dalam tahap ini harus dipastikan bahwa seluruh permintaan perubahan telah dipenuhi, dan tidak terjadi regresi kualitas sistem. 6. Acceptance test. Acceptance test adalah fase bagi user untuk melakukan pengujian dan memberikan konfirmasi atas perubahan. Pada tahap ini dilakukan penyelesaian seluruh dokumen yang diperlukan bagi implementasi perubahan pada sistem sesungguhnya. 7. Delivery. Fase delivery adalah upaya melakukan instalasi pada sistem sesungguhnya. Pada fase ini harus dipastikan bahwa seluruh perubahan benarbenar diimplementasikan. Sistem lama perlu dicadangkan (backup) bila diperlukan di masa depan. V.13 Aktifitas Khusus (Knowledge Management) Prinsip incremental finding and execution yang digunakan pada pendekatan daur hidup sistem informasi ini membutuhkan informasi yang dihasilkan pada iterasi sebelumnya. Karena itu seluruh informasi baik tacit knowlede (pemahaman yang didapatkan oleh setiap anggota tim) dan explicit knowledge (artifak dari setiap tahap daur hidup) itu harus disimpan sehingga dapat dimanfaatkan pada iterasi berikutnya. Dalam setiap tahap daur hidup sistem informasi di atas, anggota tim melakukan pengumpulan data, diskusi, perbandingan penggunaan teknologi yang banyak dipakai, pembuatan model, dan pengambilan keputusan. Biasanya anggota tim berorientasi pada pendokumentasian informasi yang didapat pada setiap tahap, dan memodelkan beberapa informasi tersebut menggunakan notasi model tertentu, misalnya BPMN, DFD, atau IDEF0. Hingga pada kondisi ini belum ada sebuah upaya untuk mengelola data yang didapatkan sebagai pengetahuan (knowledge).
91 Untuk mengelola data sebagai pengetahuan inilah knowledge expert dilibatkan dalam setiap tahap daur hidup sistem informasi. Tugas knowledge expert adalah: 1. Memandu dan membantu pencapaian kesimpulan dalam setiap diskusi dengan melakukan knowledge capture, yaitu mengubah tacit knowledge yang terdapat dalam pikiran setiap anggota tim menjadi explicit knowledge. Diskusi dilakukan baik antara anggota tim, maupun dengan staf organisasi saat pengumpulan data terutama pada tahap ke-2, ke-3, ke-4, ke-7, dan ke-8. Explicit knowledge yang harus digali adalah masalah-masalah dan solusi yang muncul, penggunaan teknologi terbaik (best practices), pilihan-pilihan teknologi yang tersedia, keputusan-keputusan yang diambil saat menentukan strategi bisnis, pengaruh kompetisi dan peluangnya, strategi sistem informasi, standar teknologi, platform teknologi, dan lain-lain. Explicit knowledge yang dihasilkan kemudian dikumpulkan di dalam knowledge base dan menjadi masukan untuk iterasi saat itu dan iterasi berikutnya. Explicit knowledge yang dikumpulkan juga berfungsi sebagai dokumentasi hasil setiap tahap daur hidup sistem informasi. 2. Menentukan format penyimpanan dokumen yang paling sesuai yang diperlukan untuk menyimpan (organize) dan mengambil kembali (retreive) dokumen explicit knowledge yang didapatkan dari proses knowledge capture di atas. Keputusan format penyimpanan ditentukan dari pertimbanganpertimbangan atas tujuan penyimpanan, dan standar format file. Tujuan penyimpanan dokumen dari explicit knowledge dapat dibagi menjadi tiga [25], yaitu: 1. Referensi. Referensi bertujuan untuk memberi gambaran dalam resolusi yang rendah bagi pengguna sistem tentang bentuk informasi yang akan mereka akses. 2. Reproduksi. Kualitas dokumen reproduksi bergantung pada metode
92 reproduksi yang diinginkan. Dokumen-dokumen reproduksi disimpan dengan tujuan untuk penggandaan ulang, atau mendapatkan kualitas informasi yang sama bila dibutuhkan di masa depan. 3. Pengganti
(replacement).
Dokumen
asli
akan
dihancurkan,
atau
diperkirakan tidak memiliki daya tahan yang lama. Dokumen yang disimpan untuk tujuan pengganti berusaha tetap menjaga unsur-unsur fisik seperti ukuran, resolusi, warna dari dokumen asli. 3. Membuat representasi pengetahuan dengan menentukan standar metadata yang dipakai. Representasi dokumen pengetahuan diperlukan karena teknologi information retreival yang ada saat ini masih belum dapat menghasilkan / memberikan hasil pencarian dokumen berdasarkan konteks isi dokumen. Konteks isi dokumen dapat disediakan oleh metadata. Ada dua macam kategori standar metadata, yaitu descriptive dan semantic. Descriptive metadata hanya menjelaskan mengenai penulis, lokasi, informasi tanggal, bentuk fisik. Semantic metadata memberikan gambaran mengenai konteks dan isi dari dokumen. Seorang knowledge expert dapat memakai kedua jenis standar metadata untuk membuat representasi dokumen yang sama. 4. Agar pengetahuan yang diambil memberikan konteks yang utuh, maka pengetahuan yang disimpan dalam knowledge base harus membentuk rantai pengetahuan (knowledge chain). Adanya rantai pengetahuan memberi kesempatan untuk melacak sejarah perkembangan pengetahuan tentang sebuah strategi. Rantai pengetahuan juga dapat digunakan sebagai data sejarah bila diperlukan evaluasi sebuah strategi di masa depan, misalnya untuk mengevaluasi perkembangan strategi bisnis sebuah organisasi dalam kurun waktu 5 tahun terakhir. Rantai pengetahuan tidak hanya tunggal, tetapi bisa bercabang membentuk pohon. Contoh rantai pengetahuan ditampilkan pada gambar V.4.
93
Gambar V.4 Rantai pengetahuan antara strategi bisnis pada iterasi yang berbeda 5. Pemberian label (tagging) pada setiap dokumen pengetahuan. Label tidak dibuat secara bebas, tapi diambil dari controlled vocabulary. Controlled vocabulary adalah sekumpulan istilah (kata, atau frase) yang dikumpulkan untuk memberi gambaran konsep-konsep yang dibicarakan selama daur hidup sistem informasi. Daftar istilah dalam controlled vocabulary tidak harus membentuk urutan, atau hubungan konsep. Hal ini berarti setiap istilah dalam controlled vocabulary dapat berdiri sendiri. Controlled vocabulary berbeda dengan taksonomi karena istilah-istilah di dalamnya tidak harus membentuk hirarki. Sebagian besar isi controlled vocabulary harus dibuat sebelum daur hidup sistem informasi dimulai. Controlled vocabulary diperlukan sehingga ada kesamaan nama istilah (tidak ada dua istilah untuk sebuah definisi yang sama) dan definisi istilah (tidak ada definisi yang berbeda untuk sebuah istilah) antara anggota tim. Contoh controlled vocabulary: BUSINESS FUNCTION FUNCTION CLASSIFICATION DATA CLASSIFICATION USER INTERFACE SECURITY STANDARD APPLICATION STANDARD ARCHITECTURE PATTERN
94 6. Mengapa
sebuah
organisasi
memerlukan
taksonomi
pengetahuan?
pengetahuan yang beredar dan dikumpulkan dalam sebuah organisasi selama bertahun-tahun dapat membentuk apa yang disebut sebagai ‘hutan’ pengetahuan. Ada terlalu banyak pengetahuan yang bila tidak diklasifikasi akan membingungkan setiap staf yang berusaha mempelajarinya. Organisasi perlu membentuk taksonomi pengetahuan dengan ruang lingkup organisasi (enterprise wide taxonomy) yang meliputi seluruh pengetahuan yang dipertukarkan dalam organisasi. Taksonomi ini biasanya digunakan untuk membentuk portal organisasi untuk keperluan pengambilan keputusan dan keunggulan strategis organisasi. Organisasi juga perlu membuat taknomoni kedua yang dibuat secara khusus dengan pertimbangan daur hidup sistem informasi. Taksonomi kedua dibuat untuk mengakomodasi klasifikasi konsep, model, teknologi, strategi bisnis, metode dan kakas yang diperlukan oleh daur hidup sistem informasi tersebut. Diperlukannya lebih dari satu taksonomi karena agar taksonomi efektif maka taksonomi harus dibuat sesuai dengan konteks keilmuan tertentu. Tidak mungkin sebuah konsep yang sangat luas diwakili oleh sebuah taksonomi secara efektif. Hasilnya akan mengandung terlalu banyak level hirarki dan variasi horisontal. Taksonomi juga perlu dikelola dan diperbarui sesuai perkembangan pengetahuan dan teknologi yang diakomodasi organisasi. Knowledge expert harus membentuk taksonomi untuk keperluan daur hidup sistem informasi tersebut sehingga setiap pengetahuan yang dikumpulkan ke dalam knowledge base dimasukkan ke dalam cabang taksonomi tertentu. Ketika sebuah dokumen telah dimasukkan ke dalam cabang pengetahuan tertentu, maka seorang staf dapat dengan mudah mencarinya kembali dengan memperhatikan hirarki pengetahuan yang ditunjukkan dalam taksonomi tersebut.
95 Secara keseluruhan keterlibatan knowledge expert dalam setiap tahap daur hidup sistem informasi pada gambar V.5.
Gambar V.5. Keterlibatan knowledge expert dalam setiap tahap daur hidup sistem informasi
96
V.14 Penutup Sintesis Pada sintesis ini digunakan beberapa prinsip, yaitu: 1. Baik proses pembentukan strategi bisnis, maupun proses perencanaan, dan proses pengembangan sistem informasi harus dibagi ke dalam beberapa level detail tertentu. 2. Setiap level akan dilakukan pada iterasi terpisah, dan iterasi sebelumnya adalah proses analisis (atau pengembangan) dari level yang lebih tinggi dari level pada iterasi saat ini (proses dekomposisi). 3. Setiap pengetahuan dari iterasi sebelumnya digunakan untuk mengerjakan tujuan iterasi saat itu (incremental finding and execution). 4. Setiap iterasi dilakukan dalam waktu yang singkat (time-boxed) dan dilakukan evaluasi di akhir setiap iterasi (periodic evaluation). 5. Setiap pengetahuan yang didapatkan dalam iterasi harus disimpan agar dapat dimanfaatkan pada iterasi berikutnya (knowledge management). Dengan menggunakan prinsip-prinsip di atas diharapkan daur hidup sistem informasi dapat beradaptasi pada perubahan-perubahan kebutuhan karena kebutuhan tidak didefinisikan secara lengkap sejak awal, dan mengijinkan adanya perubahan kebutuhan selama daur hidup sistem informasi baik pada proses pembentukan strategi bisnis dan sistem informasi, maupun pada proses pengembangan sistem informasi. Penggunaan prinsip incremental finding and execution juga memberikan kesempatan untuk melakukan evaluasi pada jarak waktu yang pendek sesuai dengan waktu yang digunakan di setiap iterasi. Hal ini menyebabkan masalah yang mungkin muncul pada hasil akhir pengembangan sistem informasi dapat terdeteksi segera, dan diambil solusinya.
