Tutorial Penerapan Slowly Changing Dimension (Part 2)
Posted on February 11, 2008
Di Bagian pertama tulisan ini pada artikel sebelumnya, saya sudah memberikan tutorial kenapa perlu adanya Slowly Changing Dimension (SCD) dan sebuah sampel kegiatan kenapa perlu adanya SCD. Sekarang tahapan berikut-nya adalah bagaimana mewujudkan SCD dalam bentuk yang sebenarnya ketika proses ETL (Ektrak Transform and Loading) dengan menggunakan teknologi SQL 2005. Sebelumnya kita lanjutkan lakukan perintah SQL berikut untuk melengkapi proses transaksi sales order untuk Sales ber nomer SalesOrderID = 280 yang telah berubah menjadi territory 10. Jalankan script ini di dalam SQL Managemet Studio.
Tahapan berikut-nya adalah Membuat sebuah Package di dalam Sql Server Integration Services(SSIS). Package awal-nya menggunakan sebuah package yang sudah jadi LoadDimEmployee.dtsx. Package yang sudah jadi tampilan-nya seperti ini
Selanjut-nya adalah kita ingin membuat sebuah tambahan proses Slowly Changing Dimension yang akan dimasukkan ke dalam proses yang ada di dalam Data Flow Layout. Ikuti beberapa step ini :
- Buka Data Flow, kemudian pilih dari toolbox di bagian data flow transformations sebuah tools yaitu Slowly Changing Dimension (SCD).
- Klik and Drag ke dalam Layout Pane. Kemudian dari sebuah proses bernama Lookup sales territory tarik panah yang berwarna hijau ke arah kotak SCD yang barusan kita masukkan.
- Kemudian klik kanan dari SCD tools tadi , setelah itu klik edit. Tunggu sebentar hingga muncul Sebuah wizard Slowly Changing Dimension, kemudian klik next.
- Dari Connection manager, pilih koneksi yang mengarahkan ke Database AdventureWorksDW, di dalam package sudah diarahkan ke chicago.adventureWorksDW yang sebenarnya mengarahkan ke server Localhost. Setelah itu klik OK.
- Dari Bagian Select a Dimension Table and Keys, pilih table or view = dbo.DimEmployee. Kemudian dari bagian key ubah Key Type menjadi business Key Sebuah kolom ParentEmployeeNationalIDAlternateKey , lebih jelas-nya lihat di gambar bawah ini. Kemudian Klik Next
6. Kemudian dari tampilan berikut-nya arahkan 2 dimension kolom yang akan dipantau perubahannya. Yaitu Lastname sebagai Changing Attribute (SCD type 1) dan SalesTerritoryKey sebagai Historical Attribute (SCD type 2). Berikut-nya klik NEXT.
7. Di tampilan berikut-nya, Klik Next
8. Di Dalam tampilan berikut-nya rubah tampilannya seperti ini :
setelah itu klik next.
9. Di tampilan berikut-nya clear Enable Inferred Member Support
10. Klik Next kemudian Finish.
11. Tunggu beberapa saat kemudian muncul di bagian data flow sebuah tampilan sebagai berikut :
12. save package kemudian execute package, tunggu beberapa saat hingga muncul tampilan seperti ini :
13. Proses Selesai.
Sekian bagian ke 2 dari tutorial ini, selanjutnya kita akan melanjutkan pada proses upload fact table-nya dan bagaimana hasil cube setelah SCD dilakukan.
Please feel free your comment.
regards,
» Filed Under Database | 1 Comment
Tutorial Penerapan Slowly Changing Dimension di SQL 2005 (Part 1)
Posted on February 6, 2008
Menyambung tulisan sebelumnya tentang penggunaan Slowly Changing Dimension (SCD), saat ini saya akan memberikan sedikit tutorial tentang penerapan SCD di SQL 2005. Dalam hal ini saya akan menggunakan Database AdventureWorks dan AdventureWorksDW yang terdapat dalam sample-nya SQL 2005. Seperti kita ketahui 2 database tadi menunjukan 2 proses dalam tahapan pengembangan BI Solution, yaitu bermula dari OLTP –> Data Warehouse (staging), Star Schema sebelum menjadi sebuah cube.
Sebelumnya kita lihat kondisi tabel dan struktur data di AdventureWorks :
Fokus kita adalah sebuah tabel SalesPerson, di dalam tabel ini terdapat data Employee karyawan yang berfungsi sebagai sales di organisasi adventureworks ini. Selain itu ada data salesterritory sebagai reference tabel untuk SalesPerson yang digunakan untuk meng-identifikasi area teritory sales yang ada. Akan tetapi seiring perubahan waktu, tentunya seorang sales person akan mempunyai teritory yang berbeda seiring dengan perkembangan organisasi. Secara fisik pada saat terjadi perubahan territory sales akan menggunakan data yang terkini sehingga semua penjualan seorang sales pada waktu dia menjadi bagian dari territory sebelum-nya akan hilang, digantikan dengan penjualan seorang sales di teritory yang baru dengan data menggunakan teritori yang lama. Kalau sebuah teritori tadi menjadi bagian performance management-nya seorang branch manager, tentunya si branch manager ini akan kehilangan revenue / GP di mata management. Oleh karena itu diperlukan sebuah pendekatan khusus yang di sebut sebagai Slowly Changing Dimension (lihat blog saya sebelumnya).
Sekarang kita buat sebuah simulasi untuk melakukan sebuah proses perubahan data OLTP-nya adventureworks.
1. Execute stored Procedure dari SSMS : uspInsertSalesPerson_new (adventureWorks database), kalau belum ada silakan ambil disini script-nya. ingat jalankan script ini di AdventureWorks DB.
2. Setelah proses pembuatan stored procedure selesai : jalankan script ini utk menambah record baru ke dalam Sales.SalesPerson tabel. :
declare @msg varchar(100)EXECUTE [AdventureWorks].[Sales].[uspInsertSalesPerson_new]
‘123456778′
,’mr.’
,’Sony’
,’S’
,’Setiawan’
,’Sales Representative’
,’M’
,’M’
,’Pasific: Australia’
,@msg output
Hasil dari eksekusi ini akan disimpan di dalam beberapa tabel sesuai dengan diagram relationship di atas.
Langkah berikut-nya adalah melakukan update ke salah satu field yang ada di dalam sales person, misal-nya terjadi perubahan dalam informasi sales territory-nya. Sedangkan update yang satu lagi adalah update terhadap kolom lastname.
3. Untuk melakukan update silakan ambil disini sebuah file utk pembuatan stored procedure yang melakukan update terhadap data salesperson. Eksekusi di database AdventureWorks. dan kemudian eksekusi data update-nya seperti ini :
EXECUTE [AdventureWorks].[Sales].[uspUpdateSalesPerson_new]280
,10
,’Ms.’
,’Shannon’
,’P.’
,’Elliott’
Sebagai informasi nilai yang berubah hanya nilai sales teritory ID dari 1 menjadi 10. Berarti mulai dari sekarang nilai sales teritory id utk ’shannon elliot’ menjadi 10. Kemudian eksekusi update perubahan lastName :
277
,3
,’Ms.’
,’Linda’
,’R.’
,’Ecoffey’
Selesai Part 1:
» Filed Under Database | 2 Comments
Penggunaan Slowly Changing Dimension
Posted on February 2, 2008
Data-data history merupakan sebuah asset yang sangat berharga dalam sebuah organisasi. Akan tetapi tidak semua data history itu berguna. Sebagai ilustrasi ketika terjadi perpindahan pegawai atau sales dari organisasi kerja antar departemen yang berbeda atau antar cabang, tentunya kita tidak ingin semua data transaksi-nya hilang begitu saja. Kita tentunya tahu dalam pembuatan sebuah star schema (data warehouse) sebuah dimension dipakai untuk merepresentasikan dari sudut pandang mana sebuah data akan diukur (measures). Di dalam konsep tradisional pembentukan sebuah dimension, semua data-data reference dari sebuah transaksi hanya akan memiliki satu record saja.
Lihat diagram dibawah ini tentang penggambaran sebuah dimensi employee :
Kita lihat dua kotak sebelah kanan merupakan repsentasi sebuah record no 295, di kotak bagian before adalah kondisi record sebelum di rubah dan kotak yang sebelah kanan hasil perubahan yang terjadi di dalam record tersebut. Jadi ketika terjadi perubahan dalam record di tabel dimEmployee, perubahan data yang lama dengan yang baru akan dilakukan proses data yang lama akan di-timpa (replace) dengan data yang baru. Efeknya adalah data-data transaksi yang lama dan berkaitan dengan dimEmployee tersebut akan berubah mengikuti perubahan tadi. Jika di organisasi tersebut ingin melihat data-data transaksi lama sebelum data dimEmployee berubah tidak akan bisa dilihat, karena data tersebut sudah digantikan dengan data reference yang baru.
Sedangkan gambar di atas merupakan penggambaran SCD type-2. Coba perhatikan data sebelumnya menggunakan nilai 9 di dalam field SalesTeritoryKey dan di kolom end date data-nya masih NULL. Setelah terjadi proses perubahan data contoh-nya pindah sales teritory di dalam record lama akan terjadi proses expiry yaitu menambah data di dalam kolom end date dengan tanggal saat terjadi perubahan. Dan akan dibuat sebuah record baru yang menampung perubahan data-nya dan data yang lama. Lihat di record yang baru nilai employeeKey berubah sesuai nilai identity-nya (auto number). sedangkan info yang lain masih sama kecuali field SalesTeritoryKey yang berubah menjadi 10, dan start date-nya menjadi tanggal data yang baru.
Itulah penggunaan Slowly Changing Dimension, didalam artikel berikut-nya kita lihat bagaimana menggunakan SCD dengan SQL Server 2005.
» Filed Under Database | Leave a Comment
Penerapan Knowledge management di Organisasi kerja pemerintahan
Posted on January 12, 2008
Organisasi kerja pemerintahan disini termasuk Departemen, kementrian dan juga pemerintahan daerah. Pertama pada saat mendengar organisasi pemerintahan mungkin timbul pertanyaan apakah memungkinkan penerapan knowledge management di lingkungan kerja yang sarat dengan isu budaya kerja santai dan mempunyai kecenderungan ABS (asal bapak senang). Tentunya jawaban-nya beragam dan sangat tergantung pada unsur leadership di organisasi tersebut. Mengapa saya bilang unsur leadership mempunyai peranan yg sangat penting ? Karena ciri khas di beberapa departement pemerintahan umumnya selalu menggunakan top down approach. Pendekatan ini merupakan salah satu peninggalan konsep sentralisasi dimana ide dan kreasi dari bawah masih takut untuk ditunjukan ke publik. Kembali ke topik utama tentang penerapan knowledge management di organisasi, saya melihat dari hasil pengalaman secara umum di lapangan tahapan penerapan bisa dibagi menjadi 3 tahap antara lain adalah sbb:
1. Awareness
Di dalam tahap ini pemahaman terhadap knowledge management harus dibuat dengan cara sosialisasi kepada semua level tapi tidak melebar hingga lingkup yang terlalu luas. Dalam tahapan ini perlunya kesadaran top level management terhadap penting-nya knowledge management.
2. Assessment
Dalam tahap ini kita harus bisa melakukan sebuah analisa terhadap kondisi yang ada saat ini dan membuat sebuah pendekatan praktis mana yang bisa dilakukan perbaikan dengan mempertimbangkan keuntungan dan kerugian dari setiap pendekatan tadi.
3. Design system
Setelah tahapan assessment selesai dan memberikan beberapa alternatif solusi. Di dalam tahapan design system akan ditentukan solusi mana yang akan diterapkan dalam penyelesaian project KM. Semua teknologi dan solusi yang ada di telaah dan disesuaikan dengan kondisi yang ada, termasuk budget pelaksanaan pekerjaan serta kualitas SDM.
4. Implementation
Semua desain system yang sudah dibuat dilaksanakan dan dimonitor pelaksanaannya. Di dalam tahapan ini semua kejadian yang tidak terbayangkan pada saat desain system akan muncul, sehingga disinalah dibutuhkan pendekatan seorang project manager yang dapat menentukan tindak lanjut proyek ini. Umumnya seorang PM harus dapat menentukan kapan sesuatu yang di luar desain system harus di akomodir atau tidak. Kultur di sebuah lembaga pemerintahan yang umumnya terjadi adalah ketidakmampuan kita melakukan capture terhadap ownership solusi KM ini. Di awal seringkali pada saat kita melakukan assessment system, kita mendapati bahwa orang yang kita assess ternyata orang kurang tepat, sehingga pada saat selesai proyek ternyata orang yang melakukan pengetesan melihat sesuatu yang tidak sesuai dengan keinginan mereka, sehingga harus dirubah desain system-nya. Saran saya dalam hal ini adalah dokumentasi-kan semua kegiatan yang berkaitan dengan proyek ini dan minta pejabat / staf terkait yang berani bertanggung jawab dan simpan sebagai bagian dari dokumentasi proyek. Ini digunakan untuk menjaga kemungkinan-kemungkinan yang dapat saja terjadi pada saat tahapan implementasi proyek ini.
5. Socialization.
Setelah semua-nya selesai terkadang tugas kita belum selesai saja sampai disitu, diperlukan sebuah proses tambahan yang biasa disebut sebagai sosialisasi ke pengguna, disinipun harus dihindari beberapa permintaan di luar dari desain system karena sekali kita ikuti 1 permintaan mereka maka akan terjadi ‘NEVER ENDING PROJECT’ yang efeknya nanti akan mengakibatkan semakin tertundanya penerapan akhir dari proyek KM ini.
» Filed Under Knowledge Management | 4 Comments
Membuat Desain Datawarehouse dengan MS SQL 2005
Posted on December 23, 2007
Beberapa praktisi di bidang teknologi Business Intelligence mengutarakan sebuah fakta bahwa hampir 80% kesalahan fatal dari pengembangan sebuah proyek BI / datawarehouse adalah kesalahan assessment kebutuhan dan desain dari star schema. Star schema sendiri merupakan sebuah desain standard di teori datawarehouse untuk membuat sebuah database siap dijadikan menjadi Cube atau bentuk MultiDimensional Database. Beberapa kaidah yang perlu diperhatikan dalam membuat desain datawarehouse adalah sebagai berikut :
- Apakah di dalam 1 database star schema akan dipakai oleh lebih dari 1 buah fokus bisnis proses. Fokus bisnis proses itu merupakan sebuah proses pekerjaan yang akan kita ukur pekerjaannya contohnya adalah sales, purchasing, human resource, production dan masih banyak lainnya. Jika nantinya di dalam sebuah star schema design akan menggunakan lebih dari 1 fokus bisnis proses berarti kita harus mempersiapkan tabel - tabel dimension yang nanti-nya bisa digunakan untuk semua proses fokus bisnis.
- Kebutuhan minimal desain 1 buah database star schema adalah terdiri dari minimal 1 buah fact table , 1 measure dan 1 buah dimension table.
- Kebutuhan sebuah tabel dimension terhadap surrogate key harus disesuaikan dengan proses bisnis yang mengacu kepada dimension table tersebut.
- Keberadaan data yang terdapat didalam dimension table dan fact table harus dijaga dengan menggunakan referential integrity antara dimension tabel dan fact table-nya.
secara umum gambaran dari diagram star schema seperti ini :
Tabel sales yang berada di tengah-tengah itu yang akan menjadi fact table-nya. Kemudian tabel store,time,product,promotion dan customer mereka itulah yang disebut sebagai tabel-tabel dimensi.
Di dalam tulisan ini saya menyajikan contoh pembuatan desain database star schema dengan menggunakan data sumber OLTP-nya menggunakan database AdventureWorks database. Di dalam contoh ini saya menggunakan proses bisnis purchasing yang menggunakan sumber data fact table-nya menggunakan 2 buah tabel yaitu : purchasing.purchasingOrderHeader dan purchasing.purchasingOrderDetail. Hasil desain yang saya buat secara umum mempunyai deskripsi susunan dimension dan fact table dan measure sebagai berikut :
Dimension Table :
dimTime
Year
|- Quarter
|- Month
dimProduct
Category
|- SubCategory
|- Product
dimEmployee (Parent Child Dimension table)
ManagerID
|- EmployeeFullName
dimShipMethod
ShipMethodNamedimVendor
VendorCountry
|- VendorProvince
|- VendorCity
|- VendorName
Fact Table :
Measures :
OrderQuantity
LineTotal
ReceivedQuantity
Berikut desain starschema fisik-nya :
Script database ini bisa di ambil di http://miimlc.metrodata.co.id/forum/files/folders/microsoft_training/entry54.aspx
Sekian dulu tulisan saya tentang pembuatan desain datawarehouse POAdventureWorks, tulisan saya berikut-nya tentang proses ETL (Extraction Transform and Loading) dari adventureworks ke POAdventureworks dengan menggunakan SSIS 2005.
Feel free for your comment.
» Filed Under Database | 8 Comments
Membuat Audit delete record log dengan trigger MS SQL 2005
Posted on December 23, 2007
Tulisan ini sebenarnya merupakan pemenuhan janji saya kepada salah satu peserta training yang ingin mengetahui tentang konsep Auditing Record Log di sebuah database MS SQL Server 2005 (any edition). Saya mohon maaf kepada Pak Indra yang sudah menanti cukup lama untuk tulisan ini 
.
Kita mulai dari cara yang sederhana yaitu dengan membuat sebuah database / menggunakan sebuah database yang sudah ada. Beberapa prasyarat awal untuk mengetahui lebih detail konsep ini bisa dimulai pemahaman tentang Trigger. Kenaapa menggunakan trigger ? Sebagai sebuah object database yang sebenarnya ‘berdiri sendiri’, trigger mempunyai kemampuan utk meng-antisipasi sebuah aksi yang dilakukan ke database / table dengan merespon balik berupa reaksi terhadap table itu sendiri (tempat trigger berada) / kepada object (table,view dll) yang juga terdapat di dalam database itu. Fungsi trigger sebenarnya mirip Check constraint tetapi trigger mempunya fungsionalitas yang lebih luas dibandingkan dengan Check Constraint.
Mari kita mulai pembahasan topik ini dengan membuat sebuah skenario berikut : Sebuah aplikasi berbasis windows based client dan database MS SQL 2005 sebagai backend-nya sering mendapatkan sebuah kasus dimana database-nya / tabel / record-nya tiba-tiba data-nya menghilang, sebagai seorang DBA tentunya kita harus mempunyai cara untuk mengetahui siapa, kapan, dan lewat mana data tersebut ‘terhapus’ entah itu sengaja atau tidak sengaja. Beberapa prasyarat untuk membuatnya adalah sebagai berikut :
- Tentukan terlebih dahulu mana tabel yang akan di audit, karena semakin banyak trigger yang harus di aktifkan di sebuah database dapat menurunkan performance dari database tersebut.
- Buat database dan table kosong yang baru di SQL 2005 dengan menggunakan SQL Management Studio nama-nya terserah anda : “testingAudit” dengan menggunakan konfigurasi standard :
create database testingAudit
go
create table testDelete
(
id_record varchar(5),
Deskripsi varchar(20)
)
go
‘insert data dummy ke table testDelete, jalankan script :insert into testDelete values (’ABC’,'testing 123′)
insert into testDelete values (’BCD’,'testing 124′)
insert into testDelete values (’CDE’,'testing 125′)
insert into testDelete values (’EFG’,'testing 126′)
insert into testDelete values (’FGH’,'testing 126′)
insert into testDelete values (’GHI’,'testing 127′)
insert into testDelete values (’HIJ’,'testing 128′)
insert into testDelete values (’IJK’,'testing 129′)
insert into testDelete values (’JKL’,'testing 130′)
insert into testDelete values (’KLM’,'testing 131′)
insert into testDelete values (’LMN’,'testing 132′)
insert into testDelete values (’MNO’,'testing 133′) - Setelah kita tentukan tabel mana yang akan di audit yaitu testdelete table, buatlah sebuah tabel yang dimanfaatkan sebagai audit log table yang di dalamnya terdapat beberapa informasi seperti : deleted_date_hour_minute,who_deleted,id_record_deleted,application. Berikut contoh script untuk membuat tabel-nya :
use testingAudit
go
create table log_record
(
dateDeleted datetime,
personWho varchar(30),
Id_record varchar(10)
) - Setelah table log dibuat, tahap berikut-nya adalah membuat trigger on delete di dalam table testDelete
Setiap perintah transaction (insert,update,delete) statement di table MS SQL Server pasti selalu muncul beberapa table sementara yang hanya muncul disaat eksekusi trigger. Table-table itu diantaranya adalah sebagai berikut :
- inserted (muncul pada saat terjadi proses transaksi perintah insert terhadap sebuah tabel)
- deleted (muncul pada saat terjadi proses transaksi perintah delete terhadap sebuah tabel)
- Sedangkan untuk transaksi Update , proses yang terjadi adalah deleted yang pertama kali di kerjakan baru setelah itu Inserted.Gambaran script untuk pembuatan trigger-nya adalah sebagai berikut :
create trigger tr_test on testdelete
for delete
as
declare @date1 datetime,@person varchar(30) , @id varchar(10)
set @date1 = getdate()
set @person = suser_sname()
select @id = id_record from deleted
insert into log_record values (@date1,@person,@id) - Pastikan trigger tr_test sudah terdapat dalam tabel testDelete, dengan menggunaan SSMS (SQL Server Management Studio).
- Coba jalankan perintah delete terhadap 1 record di tabel testDelete kemudian cek apakah log_record table telah terisi siapa, kapan dan record mana yang terhapus.
- Tolong dipastikan juga bahwa user yang authorized delete record di testDelete bisa melakukan perintah insert di table log_record.
- Selamat mencoba.
Feel free your comment,
Sony
» Filed Under Database | 8 Comments
Pengelolaan Knowledge Management di Perusahaan
Posted on December 23, 2007
Terminologi tentang Knowledge Management (KM) pada dasarnya mempunyai arti sebuah proses untuk meng-optimalisasi kekayaan intelektual di suatu organisasi untuk kepentingan organisasi. Keberadaan KM di sebuah organisasi tidak secara langsung dapat terlihat hasilnya karena beberapa hal yang berkaitan dengan Kekayaan Intelektual (Intelektual capital) yang di dalamnya terdiri dari komponen utama yaitu : human capital , Social capital, dan Corporate capital. Ketiga komponen ini merupakan komponen inti dari enterprise knowledge. Ketika salah satu dari ketiga komponen tadi tidak dapat dipenuhi oleh sebuah organisasi maka bisa dibilang implementasi dari KM ini akan gagal.
-
Human Capital (Kekayaan sumber daya manusia)
Kekayaan sumber daya manusia merupakan kekayaan yang paling besar dan paling berpengaruh terhadap pengembangan KM di sebuah organisasi. Masing-masing individu di sebuah organisasi mempunyai sumber daya yang disesuaikan dengan kemampuan dan pengetahuan yang saat ini dimilikinya. Seringkali kondisi pengelolaan kemampuan intelektual dari setiap individu selalu dipegang dan hanya dikembangkan oleh 1 orang tertentu saja. Hal ini berakibat ketergantungan terhadap 1 orang ini akan sangat tinggi dan ketika sudah saatnya dia menyatakan keluar (resign) perusahaan akan kelabakan karena sangat tergantung pada kemampuan skill-nya. -
Corporate Capital (Kekayaan milik korporasi)
Di dalamnya termasuk kekayaan intelektual (Intellectual Property) baik itu formal maupun informal seperti contohnya adalah : source code, paten, ide, merek dagang dan lain sebagainya, terutama yang berkaitan dengan sesuatu hal yang bisa menjadikan kekayaan ini sebagai sumber daya potensial untuk perusahaan agar bisa dikenal dan dianggap sebagai kekuatan utama di dunia luar. -
Social Capital (Kekayaan sosial)
Bagian kerja dari sebuah perangkat komunikasi di sebuah perusahaan di dalamnya termasuk ketersediaan hubungan antar manusia menggunakan Virtual Network dan juga interaksi antar setiap komponen sosial yang ada di dalam perusahaan.
- Teknologi : berkaitan erat dengan beberapa hal yaitu memberdayakan, mem-fasilitasi dan menyebar luaskan inovasi keseluruh organisasi.
- Isi (Content) : berkaitan dengan nilai, relevansi dan keadaan informasi yang terkini
- Proses : berkaitan dengan pengelompokan, pengumpulan, penyelarasan (synchronize), menganalisa dan penyebaran informasi.
- Budaya (culture) : berkaitan dengan komitmen, memberikan informasi ke orang lain (sharing) , saling bertukar (exchange) dan membangun hubungan (relationship).
- Pembelajaran (Learning) : berkaitan dengan membangun kontekstual, membuat dan mengembangkan proses transfer ilmu.
- Identifikasi mana “Nilai” yang paling tinggi dari sebuah organisasi di sesuaikan dengan kebutuhan organisasi tersebut untuk dapat meningkatkan nilai perusahaan itu di dunia luar. Contohnya adalah perusahaan yang bergerak di bidang IT Solutions harus selalu meningkatkan kemampuan mengelola portfolio apa yang sudah pernah mereka lakukan agar lebih dikenal di kalangan industri yang menggunakan jasa-nya. Dengan kemampuan mengelola portfolio di perusahaan berbasis IT Solutions dapat dipergunakan untuk kalangan internal agar dapat mencontoh success stories dari sebuah solusi yang pernah dikembangkan sebelumnya. Selain itu kegagalan-kegagalan yang terjadi dapat juga dijadikan sebagai senjata agar mereka tidak kembali mengulang kegagalan yang sudah pernah mereka dapat sebelumnya.
- Penjelasan yang detail belum tentu penting. Sebuah penjelasan yang terlalu “dalam” dari sebuah hirarki di dalam akar pengetahuan di organisasi dapat membuat terlalu banyaknya pekerjaan yang tidak penting dilakukan oleh seorang pengelola KM di organisasi. Oleh karena itu harus dilakukan pengamatan terlebih dahulu antara pengembangan keluasan dan kedalaman pengetahuan disesuaikan need and demand dari sebuah organisasi.
- Buka Forum untuk mencari pola. Diperlukan waktu yang cukup lama untuk organisasi jika ingin menemukan pola yang tepat dari sebuah pendekatan yang sistematis untuk tukar menukar informasi jika hanya mengandalkan pengamatan belaka. Diperlukan sebuah perangkat tools yang sanggup untuk menjembatani proses tukar menukar informasi tadi, salah satu yang cukup mewakili adalah Blog dan Wiki. Kedua tools tadi dapat dijadikan sebagai ajang untuk mewakili suara dari setiap karyawan organisasi untuk membahas sebuah topik secara bertanggung jawab demi kepentingan perusahaan dengan mengurangi hambatan waktu dan tempat dalam pembahasan sebuah topik yang bersifat terbuka.
- KM harus sejalan dengan penerapan bisnis. Sebuah proses pekerjaan di organisasi seharusnya mempunyai standar kerja yang dijadikan sebagai patokan kecepatan dan kualitas pekerjaan tersebut untuk dapat memenuhi kebutuhan bisnis yang cepat. Proses KM yang benar dapat mempercepat waktu tempuh dalam pembuatan proses bisnis secara keseluruhan, sehingga dapat dijadikan alat pengukuran bagaimana mengetahui KM dapat memberikan ROI (Return of Investment) terhadap organisasi penaung-nya. Itu adalah tantangan bagi para praktisi informasi untuk dapat mencari cara-cara yang paling tepat agar mereka dapat melakukan efesiensi pekerjaan dalam mencari informasi yang tepat dan cepat.
Berikut tulisan saya yang pertama tentang Knowledge Management, selanjutnya dalam tulisan berikutnya saya akan memberikan detail penerapan KM ditinjau dari pemanfaatan teknologi yang ada saat ini.
» Filed Under Knowledge Management | 2 Comments