Melihat Lebih Dalam

Tulisan kali ini sedikit bersentuhan dengan dunia konstruksi bangunan. Karena latar belakang saya bukan teknik sipil atau arsitektur, mohon maaf bila ada kesalahan penggunaan nama dan istilah.

Jika kita melewati jalan-jalan utama ibukota, pastilah kita menemui banyak gedung-gedung tinggi, dengan berbagai model dan gaya arsitektur. Ada yang berbentuk standar, lurus dan simetris, namun ada juga yang kelihatan tidak beraturan. Bagaimana pun bentuk dan modelnya, sebuah gedung pasti memiliki pintu/gerbang dimana orang bisa masuk dan keluar, ruangan-ruangan, jendela/kaca untuk mengatur pencahayaan di dalam (gedung-gedung baru hampir seluruhnya ditutupi dengan kaca), dan tentunya atap gedung. Jika kita masuk ke dalam area gedung, kita mungkin akan menemui lantai parkir gedung, fasilitas elevator, dan sebagainya. Semua komponen gedung ini memiliki fungsinya masing-masing, namun membentuk fungsi gedung secara keseluruhan.

Selain gedung-gedung yang sudah jadi dan sudah digunakan, kita juga dapat menemui beberapa gedung yang sedang dalam tahap konstruksi atau gedung setengah jadi. Ada yang baru beberapa lantai, ada juga yang mungkin sudah “topping off” alias sudah mencapai lantai teratas. Apapun itu, yang jelas terlihat adalah struktur utama dari gedung, baik vertikal (kolom) maupun horisontal (lantai). Kita seperti sedang melihat kerangka dari “tubuh” gedung tersebut, yang kelihatan tidak menarik karena belum ditutupi apapun. Namun demikian struktur ini memperlihatkan bagaimana gedung tersebut telah dirancang dan dbangun untuk dengan kokoh menopang semua benda dan aktivitas yang nantinya akan berada di dalamnya.

Selain gedung yang sudah jadi dan setengah jadi, jika beruntung mungkin kita dapat menemukan lokasi dimana konstruksi gedung baru saja dimulai. Belum ada yang secara langsung dapat dilihat, namun kalau kita perhatikan lebih dekat, kita dapat menemukan para pekerja sedang membangun fondasi dari gedung, termasuk menanam tiang pancang gedung ke dalam bumi.

Semakin tinggi gedung, semakin dalam pula fondasi tiang pancangnya. Meskipun setelah gedung selesai dibangun kita sama sekali tidak akan dapat melihat fondasi gedung, namun kita semua tahu bahwa pada fondasi inilah terletak kekuatan utama dari gedung di atasnya.

Konsep konstruksi bangunan yang secara garis besar terdiri dari 3 komponen, yaitu fondasi, struktural, dan fungsional ini ternyata berlaku dalam banyak, jika tidak dapat dikatakan semua hal di muka bumi. Termasuk kita manusia. Aspek fungsional atau faali yang kita miliki (gerak, penglihatan, pernafasan, pencernaan), dapat terjadi karena ada aspek struktural atau anatomis (rangka dan otot, organ tubuh, pembuluh darah dengan jantung sebagai pompanya, dan jaringan saraf termasuk otak sebagai pusat kendalinya). Namun demikian kita juga punya aspek fondasi, yaitu jiwa/roh.

Jika kita sedang menganalisa sesuatu, apapun itu, sebaiknya kita tidak hanya melihat apa yang tampak di permukaan, tapi juga apa yang berada di baliknya, dan bahkan apa yang menjadi akar/dasar dari objek yang sedang kita analisa tersebut.

Contoh, jika kita melihat problem kemacetan, kita tidak hanya cukup melihat pada apa yang kelihatan (kurangnya badan jalan dibandingkan dengan jumlah kendaraan), tetapi mungkin juga apa yang berada di balik fenomena tersebut (transportasi umum yang kurang memadai), bahkan melihat apa yang menjadi akar masalahnya (urbanisasi akibat ketidakseimbangan pertumbuhan pusat-pusat ekonomi antara kota dan daerah di sekitarnya). Dengan demikian solusi yang diambil pun bukan sekedar solusi simtomatik (batuk hanya diberikan obat pereda batuk), tetapi solusi yang bersifat kausatif dan holistik (batuk akibat TB maka harus diberikan obat anti TB plus perbaikan gaya hidup seperti tidak merokok, rutin berolahraga dan konsumsi makanan bergizi).

Konsep ini juga dapat diterapkan pada hal-hal yang bersifat progresif. Proyek pembangunan gedung, selalu diawali dengan tahap konstruksi fondasi, kemudian struktur, baru komponen fungsionalnya. Dinding dan kaca tidak dapat dipasang jika belum ada struktur yang menyangganya, dan struktur tidak akan kokoh tanpa fondasi yang mendasarinya.

Demikian juga dalam membangun atau menerapkan sesuatu, apapun itu, seharusnya dimulai dari akar atau intinya, bukan melompat pada apa yang kelihatan di luar. Jika ingin membangun sistem perangkat lunak untuk mendukung suatu fungsi dalam suatu institusi, seharusnya tidak langsung mulai dari fitur-fitur perangkat lunak tersebut. Mulailah dengan melakukan analisa terhadap masalah yang terjadi, lakukan perbaikan prosedur (SOP) yang berlangsung, jika sudah ada sistem inti (core system) perbaiki dan optimalkan dulu sistem inti tersebut, baru kita bisa mulai memikirkan fitur-fitur seperti apa yang sebaiknya kita bangun.

Dalam sudah pandang yang lebih luas, dalam melakukan suatu perubahan kita tidak hanya membutuhkan kapabilitas, melainkan juga perasaan krisis (sense of crisis), dan komitmen. Kita tidak hanya perlu kemampuan, tetapi juga perlu merasakan adanya kebutuhan yang mendesak untuk melakukan perubahan tersebut. Adanya alasan yang kuat dan nyata (tidak dibuat-buat) untuk melakukan sesuatu menjadi struktur penyangga yang kokoh dari kemampuan yang kita miliki. Dan semuanya itu didasari oleh fondasi bernama komitmen, baik dari tingkat pribadi, tim, maupun institusi secara keseluruhan. Komitmen untuk dengan penuh ketulusan dan kejujuran memperjuangkan yang lebih baik untuk kepentingan bersama yang lebih besar.

Digerakkan oleh Tujuan

Jika seorang ibu membuat nasi goreng untuk sarapan pagi, apakah setelah selesai, nasi goreng yang sudah jadi tersebut dibiarkan saja di wajan untuk kemudian menjadi dingin, dihinggapi lalat dan dikerubuti semut? Tentu sang ibu akan menyajikan nasi goreng tersebut di meja makan untuk disantap keluarganya. Ibu tersebut tidak membuat nasi goreng tanpa tujuan, tapi justru diawali oleh suatu tujuan, yakni memberikan makanan yang enak dan bergizi untuk keluarganya sebagai bekal awal melakukan berbagai aktivitas di sepanjang hari.

Seorang pencipta lagu tidak menciptakan lagu untuk kemudian hanya didengungkan dan didengar sendiri. Seorang pelukis tidak membuat lukisan untuk kemudian dipajang di dinding kamarnya sendiri. Lagu dan lukisan tersebut pasti diciptakan untuk suatu tujuan, mungkin untuk mengekspresikan suatu perasaan, atau menggambarkan suasana dan keindahan alam di suatu tempat. Perasaan dan keindahan yang kemudian dibagikan kepada orang lain.

Dalam perencanaan strategis, setiap organisasi harus memiliki visi dan misi. Visi dan misi tersebut diterjemahkan dalam bentuk strategi. Strategi kemudian diimplementasikan dalam bentuk rencana aksi.

Kalau kita bicara mengenai strategi TI, maka pasti diawali dengan strategi bisnis. Strategi bisnis diterjemahkan dalam bentuk strategi sistem informasi (proses dan prosedur). Strategi sistem informasi ini kemudian diimplementasikan dalam bentuk strategi teknologi informasi (perangkat lunak, perangkat keras, dan jaringan).

Setiap rencana aksi adalah buah dari strategi, dan berakar pada visi dan misi. Setiap penerapan teknologi informasi pada suatu organisasi, haruslah merupakan buah dari strategi sistem informasi, dan berakar pada strategi bisnis dari organisasi tersebut.

Seperti yang dipaparkan oleh Rick Warren pada video di atas, semua yang kita lakukan dan kerjakan dalam hidup ini seharusnya punya alasan dan tujuan filosofis yang benar. Bagaimana kita melakukan suatu pekerjaan, sebenarnya adalah buah dari apa yang kita kerjakan, dan berakar pada mengapa kita mengerjakannya. 

Dalam membangun suatu sistem teknologi informasi, kita tentu harus memikirkan BAGAIMANA cara kita membangun sistem tersebut. Kita juga harus memastikan APA sebenarnya yang sedang kita bangun. Namun demikan, satu pertanyaan maha penting yang tidak boleh kita lupakan adalah MENGAPA kita membangun sistem tersebut. Apa sebenarnya maksud dan tujuan dari sistem ini. Apa manfaat yang akan diperoleh seorang pengguna, suatu divisi, atau sebuah perusahaan, setelah menggunakan sistem ini.  Dengan berusaha memetakan setiap komponen dalam sistem dengan maksud dan tujuan sebenarnya dari sistem tersebut, kita sebenarnya sedang memberikan “nyawa” kepada sistem yang kita bangun, sehingga pada akhirnya tidak hanya menjadi objek yang canggih namun mati, tetapi memiliki “kehidupan” yang efektif untuk memberi manfaat bagi setiap orang yang menggunakannya.

Membuat Kesalahan yang Lebih Benar

Pada video di atas, seorang ekonom bernama Tim Harford mengatakan bahwa kita manusia seringkali berpikir diri kita adalah Tuhan, dalam arti menganggap bahwa kita tidak bisa salah. Dalam film Malice, seorang dokter yang diperankan oleh Alec Baldwin digambarkan sedemikian angkuhnya sehingga dokter tersebut mengatakan bahwa, jika dia sedang melakukan operasi untuk menyelamatkan nyawa seorang pasien yang sedang sekarat, maka ketika keluarga si pasien menunggu sambil berharap dan berdoa, sebenarnya yang sedang diharapkan bukanlah Tuhan, tapi dirinya sebagai dokter yang memiliki kemampuan untuk menyelamatkan orang yang sedang sekarat tersebut.

Dalam pembangunan sistem, mungkin tanpa disadari kita seringkali juga berperilaku angkuh seperti itu. Kita berpikir analisa kebutuhan kita sudah yang paling benar dan tidak mungkin meleset. Kita menganggap solusi yang kita rancang sudah yang paling sempurna dan tidak mungkin keliru. Apa yang tertulis dalam dokumen analisis kebutuhan dan dokumen rancangan kita anggap sebagai hukum Tuhan yang tidak boleh diganggu gugat. Kesalahan kita anggap sebagai kelemahan. Perubahan kita anggap sebagai dosa.

Jika konstitusi negara saja bisa di-amandemen, bagaimana kita bisa dengan angkuh mengatakan hasil analisis dan perancangan sistem sebagai dokumen keramat yang tidak boleh dikoreksi dan diperbaharui? Jika proyek Apollo yang dikerjakan oleh ribuan ilmuwan dan teknisi jenius saja harus melalui berbagai tahapan “trial and error” untuk kemudian mencapai tujuannya mendaratkan manusia di bulan pada Apollo 11 (bukan Apollo 1),  bagaimana kita bisa dengan yakin menganggap satu siklus pembangunan sistem sudah cukup untuk membuat sistem yang sempurna?

Daripada memiliki pola pikir “sekali tembak” yang menolak kesalahan dan menghindari perubahan, kita sebaiknya memulai pendekatan evolusioner yang justru bercirikan kesalahan-kesalahan yang terus dikoreksi dan perubahan gradual untuk menjadi lebih baik. Ada 2 karakteristik dalam pendekatan ini, yakni iteratif dan inkremental. Iteratif berarti pembangunan sistem harus dilakukan dalam sejumlah siklus yang berulang. Dalam sebuah proyek 6 bulan, daripada 1 bulan dihabiskan untuk analisis dan desain, 4 bulan untuk membangun, dan 1 bulan untuk pengujian dan implementasi, akan lebih baik bila dibagi dalam 3 “mini-proyek” yang masing-masing terdiri dari 2 minggu analisis dan desain, 4 minggu membangun, dan 2 minggu untuk pengujian dan implementasi. Setiap iterasi menghasilkan produk siap pakai yang sudah dapat dicoba oleh pengguna. Inkremental, berarti setiap iterasi harus memberikan hasil akhir yang lebih baik.  Kita tidak melakukan hal yang sama dan berputar-putar sebanyak 3 kali. Pada setiap iterasi harus ada persepsi yang diluruskan, kesalahan yang dikoreksi, proses yang diperbaiki, dan produk yang disempurnakan.

Orang Tidak Tahu Apa yang Mereka Inginkan

Salah satu contoh yang dipaparkan penulis Malcolm Gladwell pada video di atas kira-kita seperti ini: jika orang ditanya saus spageti seperti apa yang dia paling sukai, orang hanya menyebutkan jenis saus yang dia ketahui. Anggaplah dari saus tipe A, B, dan C, dia menyebutkan tipe A. Tapi setelah orang tersebut diberikan beberapa jenis saus spageti untuk dicoba, termasuk jenis2 yang tidak dia ketahui sebelumnya (misalkan selain tipe A, B, dan C, juga diberikan tipe D, E, dan F) barulah ditemukan bahwa ternyata orang itu sangat menyukai saus tipe F.

Demikian juga pada proyek pengembangan sistem, pernahkah kita menemukan pernyataan-pernyataan kebutuhan baik dalam bentuk lisan maupun tulisan, yang ternyata sama persis dengan apa yang sebenarnya diinginkan? Sesuai perjalanan waktu, setelah sistem tersebut sedikit demi sedikit dibangun, seringkali terjadi atau mungkin dapat dipastikan muncul hal-hal yang sebelumnya tidak terpikirkan. Kita bisa menanyakan sebanyak mungkin pertanyaan kepada pengguna, dan membuat dokumen analisis kebutuhan yang sangat terperinci dan lengkap, untuk kemudian menemukan bahwa apa yang kita tulis dalam dokumen tersebut ternyata tidak sesuai dengan keinginan dan kebutuhan pengguna yang sebenarnya.

Lalu, apa yang bisa kita lakukan agar apa yang kita bangun bisa semendekati mungkin dengan apa yang dibutuhkan? Rahasianya sebenarnya terletak pada hal sederhana yang mungkin seringkali kita anggap remeh, yakni komunikasi. Bangun relasi yang erat dengan pengguna. Jangan sebut pengguna dengan kata “mereka”, tetapi jadikan pengguna sebagai bagian dari tim. Bagian dari “kita”.

Kemudian yang perlu diperhatikan adalah bagaimana cara kita berkomunikasi. Kata-kata tidaklah cukup. Pernyataan lisan bahkan tulisan seringkali tidak mampu mengekspresikan secara lengkap apa yang ada di benak pengguna, sehingga memungkinkan terjadinya salah persepsi. Sebuah gambar bermakna ribuan kata. Gambarlah diagram atau model, yang berfungsi sebagai cetak biru dari sistem yang akan kita bangun. Setelah itu, buatlah prototype. Jika kita hendak membangun gedung, setelah kita membuat rancangan arsitektur dalam bentuk cetak biru, apa yang kita lakukan sebelum membangun gedung yang sebenarnya? Kita membuat maket gedung tersebut. Demikian juga jika kita ingin membangun mobil, kapal laut atau pesawat terbang, kita tentu membuat model/prototype-nya terlebih dahulu. 

Pembuatan prototype adalah suatu keharusan dalam dunia rekayasa/engineering. Jika untuk membuat objek yang kelihatan saja kita perlu membuat cetak biru dan prototype, apalagi untuk membangun sistem yang tidak kelihatan.

Melihat yang Tidak Terlihat

Semakin lama kita berkecimpung dalam bidang pembangunan sistem teknologi informasi, semakin banyak kita belajar bahwa keberhasilan dari apa yang kita lakukan seringkali terletak pada hal-hal yang tidak kelihatan ketimbang hal-hal yang kelihatan. Mungkin dulu kita menilai keberhasilan pengembangan sistem lebih pada parameter-parameter teknis seperti kecepatan respons, jumlah bug, dan tingkat keamanan. Parameter-parameter ini tentu penting, tapi berapa sering kita menemui sistem yang terbukti cepat, bebas dari bug, dan aman, namun ternyata tidak dapat memberi manfaat yang optimal terhadap penggunanya. Canggih, namun tidak efektif.

Kalau kita meningkat ke level proyek, parameter keberhasilan yang umum dijadikan acuan adalah tepat waktu, tepat biaya dan tepat cakupan. Tetapi tidak jarang kita mendengar proyek-proyek yang berdasarkan ketiga parameter tersebut tampaknya berhasil, tapi ternyata tidak. Bisa jadi proyek tersebut tepat waktu, tapi ternyata ketepatan waktu tersebut diperoleh dengan cara menutup mata dan telinga terhadap masukan dan kritik dari pengguna. Tepat waktu, tapi pengguna kesal karena tidak merasa dilibatkan. Akibatnya terjadi reaksi penolakan dalam wujud keengganan untuk menggunakan sistem yang sudah dibangun tersebut. Atau bisa jadi proyek tepat dari sisi biaya, tetapi diperoleh dengan cara murahan dan mengorbankan kualitas. Sekilas sistem bekerja dengan normal, hingga sampai pada suatu waktu dan kondisi dimana kelemahan-kelemahannya muncul di permukaan dan mengakibatkan masalah. Bisa jadi juga seolah-olah tepat dari sisi cakupan, tepat sesuai dengan yang diinginkan pengguna dalam dokumen kebutuhan, hingga kemudian pada saat sistem pertama kali digunakan, diketahui bahwa isi dokumen kebutuhan yang dibuat 3 bulan, 6 bulan atau 1 tahun yang lalu terrnyata sudah tidak sesuai dengan kebutuhan pengguna 3 bulan, 6 bulan atau 1 tahun kemudian.

Mengapa hal ini bisa terjadi? Mari kita coba belajar dari beberapa ide dan pemikiran yang dipaparkan dalam sejumlah presentasi dari konferensi TED. Konferensi TED (Technology, Entertainment and Design) adalah suatu acara dimana orang dapat mempresentasikan gagasannya dalam berbagai bidang, entah itu sosial, ilmu pengetahuan, ekonomi, teknologi, dsb. Konferensi ini pertama kali diselenggarakan tahun 1990 di Monterey, California. Versi lokalnya sudah diselenggarakan di banyak negara termasuk Indonesia. 

Mari kita simak 3 presentasi oleh 3 orang pembicara yang berbeda yang dapat kita jadikan pelajaran untuk melakukan pengembangan sistem yang lebih baik.

Pelajaran 1: Orang tidak tahu apa yang mereka inginkan

Pelajaran 2: Membuat kesalahan yang lebih benar

Pelajaran 3: Digerakkan oleh tujuan

divide et impera

Divide et impera? Apakah kita akan membahas sejarah pendudukan Belanda? Bukan, kita justru akan belajar Biologi!

Kita mungkin masih ingat sewaktu sekolah dulu ada salah satu topik mata pelajaran Biologi yang berkaitan dengan penggolongan atau pembagian jenis makhluk hidup. Kita mungkin ingat dengan nama Carolus Linnaeus, seorang naturalis Swedia yang berusaha mengelompokkan semua biota yang hidup di bumi baik di atas daratan maupun di kedalaman laut menurut persamaan dan perbedaan karakteristik yang dimiliki oleh makhluk hidup tersebut dibandingkan dengan makhluk hidup lain. Sebagai contoh semua hewan yang memiliki karakteristik menyusui dikelompokkan dalam Mamalia. Tingkat penggolongan makhluk hidup mulai dari yang tertinggi Domain, kemudian Kingdom, lalu Filum (untuk hewan) atau Divisi (untuk tumbuhan), Kelas, Ordo, Famili, Genus, dan akhirnya Spesies.

Penamaan ilmiah makhluk hidup mengambil 2 tingkat klasifikasi terbawah, yakni genus dan spesies. Seperti contoh kita manusia memiliki nama ilmiah Homo sapiens. Pengklasifikasian ini dikenal dengan istilah taksonomi, berasal dari kata Yunani taxis yang berarti untuk mengelompokkan dan nomos yang berarti aturan. Carolus Linnaeus kemudian dikenal sebagai bapak taksonomi modern.

Lalu bagaimana dengan konten informasi yang ada di dalam suatu institusi/perusahaan? Apakah perlu diklasifikasi seperti ini? Tentu saja. Seperti halnya makhluk hidup, konten informasi dalam suatu perusahaan memiliki banyak keragaman. Yang paling mudah dilihat adalah formatnya, ada yang berbentuk teks, gambar, dokumen atau multimedia. Namun sesuai namanya, yang dilihat adalah konten/isinya, bukan formatnya. Sebagai contoh dokumen SOP untuk pengajuan cuti, dokumen teknis instalasi mail server, dan dokumen laporan keuangan, kesemuanya bisa saja memiliki tipe yang sama yakni dokumen MS Word atau PDF, namun pasti memiliki isi, tujuan dan pengguna yang berbeda. Mirip dengan pengklasifikasian buku perpustakaan, yang tidak digolongkan menurut ukuran buku atau apakah hard cover atau soft cover, namun berdasarkan isinya.

Taksonomi dalam konteks ECM (enterprise content management) sebenarnya adalah penciptaan struktur organisasi dari konten informasi perusahaan, yang sedikit banyak akan mengacu pada struktur organisasi perusahaan itu sendiri. Misalkan dalam suatu perusahaan terdapat divisi HR, IT, dan Finance maka dalam implementasi portal sebagai ECM akan mengelompokkan konten informasi ke dalam ketiga kelompok tersebut. Secara struktural, portal akan memiliki 3 sub portal, masing-masing untuk setiap divisi, dan jika melihat contoh ketiga dokumen pada uraian sebelumnya, maka dokumen SOP akan masuk ke sub portal divisi HR, dokemen teknis mail server ke sub portal IT, dan dokumen laporan keuangan ke sub portal Finance. Ini adalah model taksonomi yang paling mudah dan gamblang.

Selain mengikuti struktur organisasi, pada perusahaan yang lebih bersifat lintas fungsional dimana aktivitas banyak bersifat project lintas divisi, maka taksonomi dapat juga dilakukan berdasarkan project. Jika lokasi perusahaan tersebar di beberapa lokasi, taksonomi dapat berdasarkan lokasi/cabang. Perusahaan manufaktur yang memproduksi sejumlah produk dapat menambahkan taksonomi menurut produk. 

Pada intinya, taksonomi harus dirancang sesuai dengan kebutuhan pengguna dan selaras dengan aspek anatomis/struktural dan fungsional dari perusahaan. Taksonomi yang tepat akan membawa manfaat yang besar, di antaranya kemudahan dalam menemukan informasi yang dibutuhkan, menempatkan informasi dalam konteks, dan menciptakan relasi antar informasi tersebut. Jika ini sudah tercapai, informasi dapat bertransformasi menjadi apa yang disebut sebagai knowledge (pengetahuan). Dan seperti pepatah mengatakan: Knowledge is power. Pengetahuan adalah kekuatan, yang akan membedakan perusahaan terdepan dari kompetitor di belakangnya.

jawara berkolaborasi

Kolaborasi berarti bekerja bersama. Lingkungan pekerjaan individual, dimana tidak ada orang yang dapat ikut serta dalam pekerjaan seorang karyawan, digantikan oleh kebutuhan dan tuntutan untuk menciptakan lingkungan kerja kolaboratif. Karyawan harus dapat bekerja sama, mengkomunikasikan ide antara karyawan, saling memberikan umpan balik, memainkan peran dalam sejumlah alur kerja proses bisnis bersama-sama karyawan lain untuk mencapai tujuan tertentu. Karyawan harus dapat saling berbagi pengetahuan, and perusahaan/institusi harus dapat mensarikan lautan pengetahuan dari seluruh karyawan ke dalam pengetahuan organisasi yang sangat berharga. Pengetahuan/knowledge adalah aset sejati dari organisasi yang memberikan keunggulan kompetitif (competitive advantage) kepada organisasi tersebut, yang pada akhirnya akan menjadikan organisasi tersebut organisasi yang gesit (agile).

Portal intranet, menurut definisi dari Wikipedia, adalah gerbang yang menyatukan akses bagi seluruh informasi dan aplikasi perusahaan dalam jaringan lokal intranet. Sementara itu portal korporat didefinisikan sebagai kerangka kerja (framework) untuk mengintegrasikan seluruh informasi, orang dan proses yang berada dalam lingkup suatu perusahaan. Saat ini hampir semua pemain IT besar (seperti Microsoft, IBM, SAP dan Oracle) memiliki solusi portal. Di samping itu ada juga sejumlah solusi yang dikembangkan vendor2 yang lebih kecil, baik komersial maupun open source. Teknologi portal ini, yang pada dasarnya meliputi manajemen dokumen/konten/pengetahuan, fitur komunitas seperti forum diskusi dan blog, dan juga proses bisnis atau workflow, dapat membantu perusahaan/institusi untuk menciptakan lingkungan kerja bersifat kolaboratif.

Tapi teknologi tidak dapat bekerja sendiri. Ada dua faktor utama lainnya: orang dan proses. Untuk dapat menciptakan lingkungan dimana orang memiliki keinginan atau bahkan antusias untuk berkolaborasi dengan orang lain, dan dimana proses bisnis yang melibatkan banyak peran yang bekerja sama untuk mencapai suatu tujuan dapat berjalan, organisasi harus mentransformasikan budayanya menjadi budaya kolaboratif. Organisasi yang bersifat command and control, dengan tingkat power distance yang besar antara anggotanya, tidak lagi dapat diteruskan. Ini tidak berarti harus mengubah struktur organisasi menjadi flat. Tetap akan ada atasan dan bawahan, manajer dan staf, pemimpin dan pengikut, tetapi menumbuhkan budaya kolaboratif mensyaratkan semua orang untuk berpikir dirinya sebagai bagian dari tim. Tidak boleh hanya ada satu superhero dalam sebuah organisasi, setiap orang seharusnya menjadi pahlawan, bekerja bersama untuk menciptakan sebuah superteam yang dashyat.

 jagoan berkolaborasi