Selasa, 18 Mei 2010

UPN "VETERAN JAWA TIMUR SURABAYA




Fenomena perkembangan sistem informasi yang semakin hari menunjukkan perkembangan yang pesat mengharuskan kita untuk dapat terus mengikutinya. Program Studi Sistim Informasi –FTI UPN ”Veteran” Jawa Timur bekerjasama dengan berbagai pihak yang berkompeten dalam bidang IT menyelenggarakan IT Fair selama 6 hari yang dimulai pada Senin, 17 Mei 2010 hingga tanggal 22 Mei 2010 bertempat d gedung serbaguna Giriloka. Pameran IT yang dibuka untuk umum tersebut juga diisi dengan workshop Pengenalan Internet, Pembuatan Web, Pembuatan blog dan Talkshow teknologi IT bagi Guru, Pelajar, mahasiswa dan umum. Rektor UPN “Veteran” Jatim, Prof. Dr. Ir. Teguh Soedarto, MP dalam sambutan sekaligus pembukaan pameran mengatakan bahwa kebutuhan akan dunia IT terus berkembang, sehingga diperlukan pemahaman, pengetahuan untuk terus dapat mengikuti perkembangnnya, sehingga momen pameran IT adalah momen yang tepat untuk mendukung perkembangan tersebut.
Pameran IT yang terbuka untuk umum tersebut dibuka secara gratis mulai jam 9.00 – 18.00, didukung oleh beberapa vendor dan sponsor antara lain TELKOM, Axioo, beberapa komunitas IT, Blogger, kelompok entrepreneur mahasiswa, penerbit buku-buku IT , beberapa karya mahasiswa antara lain robotika dan sebagainya.

it2010-7it2010-5it2010-2it2010-4it2010-3


Ka.Progdi Sistem Informasi, Nur Cahyo, Skom, M.Kom menyatakan bahwa kegiatan ini merupakan rangkaian program yang diselenggarakan oleh progdinya setelah sebelumnya menyelenggarakan Workshop tentang Internet yang sehat, dan akan dilanjutkan lagi dengan UKM Fair yang akan mengundang sekitar 50 stand usaha kecil menengah yang bertujuan untuk mengembangkan jiwa wirausaha bagi para mahasiswa, khususnya mahasiswa IT.(mirw@n)

APLIKASI PENILAIAN AUDIT BERDASARKAN COBIT 4.0



APLIKASI PENILAIAN AUDIT BERDASARKAN COBIT 4.0
Nur Cahyo Wibowo, S.Kom, M.Kom
Program Studi Teknik Informatika, Fakultas Teknologi Industri
UPN “Veteran” Jawa Timur
Jl. Raya Rungkut Madya, Gunung Anyar, Surabaya
email : cahyo.upn@gmail.com





ABSTRAK
Cobit dirumuskan oleh para pakar rekayasa perangkat lunak internasional untuk memberikan panduan bagi para pimpinan perusahaan yang berencana melakukan investasi teknologi informasi yang menguntungkan. Di dalam Cobit dijelaskan prosedur dan metodologi bagaimana seharusnya mengatur sebuah proyek implementasi teknologi informasi di sebuah perusahaan mulai dari perencanaan sampai dengan evaluasi kinerjanya. Sebaliknya, dengan sudut pandang yang berbeda, sistem Cobit juga bisa dimanfaatkan sebagai panduan untuk melakukan audit terhadap kelayakan sebuah investasi teknologi informasi yang sudah dilakukan oleh sebuah perusahaan. Namun yang sering menjadi masalah adalah belum adanya panduan kuantitatif untuk melakukan penilaian audit. Sehingga proses audit lebih terasa nuansa atau faktor subjektifitas auditor daripada aturan yang baku. Lebih dari itu, proses audit yang umumnya melibatkan sangat banyak dokumen namun dengan pihak staff perusahaan serta auditornya yang sama, seringkali ditemukan standarisasi pemberian nilai yang berbeda untuk hal-hal yang seharusnya sama. Penelitian ini dibuat sebagai upaya untuk meminimalisasi terjadinya kondisi-kondisi tersebut di atas. Sehingga proses audit bisa dilakukan secara cepat dan konsisten. Penelitian ini akan menjelaskan desain struktur data dan aplikasi sistem Cobit yang dibangun dengan menggunakan DBMS MS SQL Server dan MS Visual Studio – Visual Basic 6.0. Aplikasi ini mampu melakukan otomatisasi hasil score audit yang bisa digunakan oleh auditor sebagai gambaran awal kelayakan sebuah investasi teknologi informasi pada sebuah perusahaan berdasarkan dokumen-dokumen yang tersedia.
Kata kunci: aplikasi COBIT, software engineering, project management, software audit.

1 INTRODUCTION
Control Objectives for Information and related Technology (COBIT®) memberikan panduan lintas domain dan framework proses yang baik. Cobit juga menunjukkan aktifitas ke dalam sebuah struktur yang logis dan mudah diatur. Cobit merupakan hasil konsensus para ahli dalam bidang manajemen proyek perangkat lunak. Fokusnya adalah lebih banyak dalam hal pengendalian dari pada pengerjaan. Panduan ini akan sangat membantu investasi IT yang optimis, memastikan penyerahan layanan dan memberikan sebuah pengukuran daripada sebuah justifikasi ketika terjadi suatu kesalahan. Supaya investasi IT berhasil sesuai permintaan bisnis maka pihak manajemen harus melakukan sistem kendali internal atau framework di dalamnya.

Audit investasi teknologi informasi memang masih belum begitu berkembang di Indonesia. Akan tetapi kebutuhan akan hal itu mulai muncul, khususnya untuk perusahaan berskala menengah ke atas. Perusahaan sudah mulai memperhatikan sejauh mana kontribusi investasi teknologi informasi yang mereka lakukan terhadap kinerja perusahaan.

Pada waktu booming teknologi informasi di pasaran, sekitar tahun 90-an, perusahaan-perusahaan berlomba-lomba untuk investasi di bidang teknologi informasi. Namun yang terjadi sekarang justru cukup banyak perusahaan yang gulung tikar meskipun sudah banyak dana yang dikeluarkan untuk investasi teknologi informasi.

Hal tersebut di atas bukanlah sesuatu yang tidak mungkin terjadi. Karena investasi teknologi informasi yang tidak diatur dan dikendalikan dengan baik justru akan menjadi bom waktu bagi keruntuhan perusahaan yang bersangkutan. Sebagai ilustrasi sederhana adalah sebagai berikut. Sebuah perusahaan menerapkan ketentuan perubahan media penyimpanan data dari yang semula paper-based menjadi digital-based. Sehingga semua berkas-berkas dipindahkan ke dalam format file dengan dukungan aplikasi perangkat lunak yang sudah ada. Pada masa-masa awal terlihat begitu besar efisiensi yang dilakukan. Bisa dibayangkan kemampuan satu buah keping CD-ROM adalah setara dengan kemampuan satu ruang besar gudang arsip perusahaan selama satu tahun operasional. Namun pada suatu waktu datanglah sebuah bencana. CD-ROM data perusahaan corrupt sehingga tidak bisa dibaca dengan lengkap. Karena belum adanya prosedur back up berkala akhirnya data penting perusahaan hilang.

Untuk itulah, Cobit memberikan sebuah panduan bagi investasi teknologi informasi di perusahaan. Prosesnya dimulai dari perencanaan hingga pemantauan dan evaluasi proses investasi. Dengan sudut pandang terbalik Cobit juga bisa dimanfaatkan untuk melakukan panduan proses audit kelayakan investasi teknologi informasi yang sudah dilakukan oleh perusahaan.

Akan tetapi yang sering menjadi masalah adalah konsistensi nilai dan kecepatan proses audit itu sendiri. Di dalam sistem Cobit seperti yang akan dijelaskan pada bagian Dasar Teori terdapat interaksi antar proses yang cukup kompleks. Sehingga masalah konsistensi penilaian menjadi sangat penting. Maksudnya bahwa untuk penilaian dengan melibatkan dokumen yang sama sudah seharusnya nilai dokumen tersebut tetaplah sama, tidak boleh berubah. Namun kenyataan di lapangan bisa saja tidaklah demikian. Keterbatasan manusia dalam hal ingatan dan pengambilan keputusan memang bisa saja berubah-ubah meskipun tidak terlalu besar.

Masalah yang kedua terkait dengan audit adalah kecepatan penghitungan nilai akhir. Proses audit manual yang saat ini diterapkan, rata-rata membutuhkan waktu sekitar 2 sampai 3 bulan. Ini pun terkadang masih perlu beberapa revisi. Penghitungan nilai akhir yang cepat menjadi hal yang penting baik bagi auditor maupun perusahaan yang diaudit. Salah satu alasan yang utama adalah time is money. Begitu perusahaan mendapatkan nilai hasil audit, mereka bisa segera melakukan perbaikan-perbaikan untuk kepentingan bisnisnya. Sedangkan bagi auditor jelas biaya operasional tim kerjanya akan bisa ditekan serta kinerja tim audit akan dinilai lebih baik oleh perusahaan yang diaudit jika prosesnya bisa lebih cepat.

2 MODEL, ANALISIS, DESIGN, AND IMPLEMENTATION
Sesuai dengan rumusan masalah yang sudah dikemukakan di atas, maka penelitian ini bertujuan untuk mengimplementasikan sistem Cobit ke dalam sebuah aplikasi yang bisa digunakan untuk :
• Menerapkan penilaian yang konsisten.
• Mempercepat perolehan nilai audit.

RUANG LINGKUP
Sistem Cobit yang dijadikan panduan bagi penelitian ini cukup luas cakupannya. Namun penulis mengamati adanya pola-pola yang sama yang bisa digunakan sebagai acuan implementasi dalam ruang lingkup yang lebih luas dan kompleks. Untuk itu dalam penelitian ini yang akan digunakan sebagai studi kasus adalah subsistem Cobit yaitu bagian proses PO (Plan and Organize) 1 yaitu Define a Strategic Plan.

Dalam sistem Cobit sendiri ada 5 penilaian yang bisa dilakukan. Diantaranya adalah penilaian terhadap Maturity Level, Control Objective, Key Performance Indicator, Process Key Goal Indicator, dan IT Key Goal Indicator dari sebuah perusahaan. Yang akan dibahas di dalam penelitian ini adalah dua penilaian yang pertama, yaitu penilaian terhadap Maturity Level dan Control Objective.

COBIT FRAMEWORK
Framework kendali Cobit memberikan kontribusi untuk keperluan tersebut :
• Membuat sebuah hubungan dengan kebutuhan bisnis.
• Mengorganisasikan aktifitas investasi IT.
• Mengidentifikasi sumber daya IT utama yang mendesak untuk diselesaikan.
• Mendefinisikan tujuan kendali manajemen yang perlu diperhatikan.

PLAN AND ORGANISE (PO)
Domain ini mencakup strategi dan taktik, dan juga memperhatikan identifikasi cara IT dapat memberikan kontribusi terbaik untuk pencapaian tujuan bisnis. Lebih jauh, realisasi visi strategis perlu untuk direncanakan, dikomunikasikan dan diatur untuk perpsektif yang berbeda. Akhirnya, sebuah organisasi yang tepat sebagaimana juga infrastruktur teknologinya perlu untuk dibuat.

ACQUIRE AND IMPLEMENT (AI)
Untuk mewujudkan strategi IT, solusi IT perlu untuk diidentifikasi, dibangun atau diperoleh, sebagaimana juga perlu untuk diimplementasikan dan diintegrasikan ke dalam proses bisnis. Selain itu, perubahan dan pemeliharaan sistem yang sudah ada juga tercakup dalam domain ini untuk memastikan bahwa solusi senantiasa sesuai dengan tujuan bisnis.

DELIVER AND SUPPORT (DS)
Domain ini menerangkan tentang hal-hal terkait dengan penyerahan layanan yang dibutuhkan. Termasuk didalamnya adalah penyerahan layanan itu sendiri, manajemen keamanan dan kesinambungan, dukungan layanan bagi pemakai dan manajemen data serta fasilitas operasional.

MONITOR AND EVALUATE (ME)
Seluruh proses IT perlu untuk dipantau secara teratur. Hal ini dimaksudkan untuk menjaga kualitas dan pemenuhan dengan kebutuhan kendali. Domain ini membahas tentang manajemen kinerja, pemantauan kendali internal, pemenuhan regulasi, dan penyediaan pengaturan.

Gambar 2.1 di bawah ini menjelaskan tentang sistem framework Cobit 4.0 secara menyeluruh.
























Gambar 2.1 COBIT4.0 Framework
Dimulai dengan tujuan bisnis dan pengaturan. Kemudian di break-down menjadi beberapa domain yang saling berkaitan dan membentuk sebuah siklus.

DETAIL CONTROL OBJECTIVES
Ada enam control objectives di dalam subproses PO 1, yaitu:
1. Manajemen nilai teknologi informasi.
2. Penyesuaian antara kepentingan bisnis dengan teknologi informasi.
3. Penilaian kinerja teknologi informasi saat ini.
4. Rencana strategis penerapan teknologi informasi.
5. Rencana taktis penereapan teknologi informasi.
6. Manajemen portfolio penerapan teknologi informasi.

MATURITY LEVEL
Secara umum maturity level akan menunjukkan berada pada tingkat manakah kinerja sebuah perusahaan. Di dalam Cobit dikelompokkan menjadi 6 yaitu:
- Level 0 : Non Existent
- Level 1 : Initial/ Ad Hoc
- Level 2 : Repeatable but Intuitive
- Level 3 : Defined Process
- Level 4 : Managed and Measurable
- Level 5 : Optimised

DESAIN DATABASE
Untuk melakukan otomatisasi audit perlu dilakukan terlebih dahulu standarisasi jenis dokumen yang terlibat. Dokumen dalam penelitian ini dibedakan menjadi dua, yaitu dokumen sistem dan dokumen yang dimiliki client. Strategi ini sengaja dipilih karena pengalaman di lapangan menunjukkan bahwa dokumen client itu seringkali tidak sesuai dengan struktur model dokumen yang sudah disediakan oleh sistem. Untuk itulah dalam desain databasenya dibuat sebuah tabel transaksional untuk menyimpan peta hubungan antara dokumen client dengan dokuman sistem.

Sebagai tabel master untuk desain ini adalah tabel dokumen sistem, tabel client, tabel control objective dan tabel maturity level. Tabel-tabel ini akan direferensi oleh tabel-tabel yang lain untuk membangun skema database Cobit yang lengkap. Sedangkan tabel turunannya adalah tabel dokumen client, tabel detail control objective dan tabel detail maturity level.

Otomatisasi audit sebuah control objective maupun maturity level akan ditentukan berdasar tabel peta relasi antara dokumen client dengan dokumen sistem, peta relasi antara control objective dengan dokumen sistem apa saja yang terlibat dan terakhir peta relasi antara dokumen sistem dengan maturity level. Nilai dan bobot yang berada pada dokumen client akan dapat ditransformasikan menjadi nilai dokumen di sistem berdasarkan bobot dokumen internal sistem yang sudah didefinisikan sebelumnya. Nilai transformasi ini akan bersifat kuantitatif, murni diperoleh berdasarkan perhitungan. Untuk penilaian dokumen yang berhubungan dengan control objective akan disimpan di dalam tabel quantitatif control objective. Sedangkan yang berhubungan dengan maturity level akan disimpan ke dalam tabel quantitative maturity level. Untuk lebih jelasnya bisa dilihat pada Gambar 2.2 di bawah ini.

















Gambar 2.2 Skema Relasi Database

Keterangan:
- DC :Dokumen client.
- MDC :Peta relasi dokumen sistem dengan dokumen client.
- DS :Dokumen sistem.
- MCO :Peta relasi dokumen sistem dengan control objective.
- DCO :Detail control objective.
- QCO :Quantitative control objective.
- MML :Peta relasi dokumen sistem dengan maturity level.
- DML :Detail maturity level.
- QML :Quantitative maturity level.

Nilai transformasi dokumen yang diperoleh akan diolah berdasarkan perhitungan untuk mendapatkan score audit baik pada detail control objective maupun maturity level. Ada tiga kondisi yang perlu diperhatikan yaitu:
1. Sebuah dokumen sistem direferensi oleh sebuah dokumen client.
2. Sebuah dokumen sistem direferensi oleh banyak dokumen client.
3. Dokumen sistem yang tidak direferensi oleh dokumen client. Hal ini dimungkinkan terjadi ketika struktur dokumen di sistem begitu lengkap dan detail akan tetapi struktur dokumen di client lebih sederhana dan global/ umum.

3 RESULT
Secara umum operasi pada aplikasi ini dikelompokkan ke dalam tiga bagian utama, yaitu bagian tabel master, bagian knowledge base-nya yaitu tabel-tabel yang berisikan peta relasi, dan yang ketiga adalah bagian otomatisasi penghitungan score audit.






















Gambar 3.1 Antarmuka Utama
ANALISIS DAN UJI COBA
Sebagaimana telah disinggung pada pokok bahasan Ruang Lingkup, maka yang akan dijadikan skenario uji coba adalah khusus pada subproses PO 1 yaitu Define a Strategic IT Value. Skenario uji coba dimulai dengan kondisi dokumen client seperti yang ada pada Gambar 3.2 di bawah ini. Sebagai contoh terlihat sebuah dokumen dengan nama IT Master Plan yang diberi kode ITMP. Munculnya tambahan label satu, dua, tiga dan seterusnya, hal itu dimaksudkan bahwa dokumen tersebut diasumsikan terdiri atas beberapa bagian penyusun yang mana untuk perusahaan satu dengan lainnya dimungkinkan memiliki kondisi yang berbeda.



Gambar 3.2 Tabel Dokumen Client

Kemudian peta relasi antara dokumen client dengan dokumen sistem didefinisikan sebagaimana isian tabel yang terlihat pada Gambar 3.3 berikut ini. Salah satu contohnya adalah mapping antara dokumen IT Strategic Plan dengan IT Master Plan.



Gambar 3.3 Form Pemetaan Dokumen

Maka dengan kondisi peta relasi antara dokumen sistem dengan detail control objective seperti pada Gambar 3.4 di bawah ini:


Gambar 3.4 Form Peta Relasi CO

Akan diperoleh score audit untuk pernyataan pertama pada PO 1 adalah sebagai berikut:



Gambar 3.5 Hasil Score CO untuk PO 1

Score akhir pada uji coba di atas adalah 0.74 yang berarti termasuk dalam kelompok HIGH. Di dalam aplikasi ini pengelompokan nilainya adalah sebagai berikut:

If (total <= 0.3) Then
Label.Caption = "POOR"
ElseIf (total <= 0.5) Then
Label.Caption = "LOW"
ElseIf (total <= 0.7) Then
Label.Caption = "MEDIUM"
ElseIf (total <= 0.9) Then
Label.Caption = "HIGH"
ElseIf (total <= 1) Then
Label.Caption = "COMPLETE"
End If

Gambar 3.6 Aturan Klasifikasi Score

Sedangkan untuk kondisi peta relasi antara dokumen sistem dengan maturity level seperti gambar di bawah ini:



Gambar 3.7 Peta Relasi Maturity Level

Maka akan diperoleh skor audit maturity level untuk PO 1 adalah seperti dalam gambar berikut:



Gambar 3.8 Score Maturity Level untuk PO 1

Terlihat pada gambar di atas bahwa score ML-nya adalah 1.429… dan ini termasuk ke dalam tingkat Repeatable. Pengelompokan ini berdasar pada aturan berikut:

If (totall <= 1) Then
Label.Caption = "INITIAL"
ElseIf (totall <= 2) Then
Label.Caption ="REPEATABLE"
ElseIf (totall <= 3) Then
Label.Caption = "DEFINED"
ElseIf (totall <= 4) Then
Label.Caption = "MANAGED"
ElseIf (totall <= 5) Then
Label.Caption = "OPTIMIZED"
End If

Gambar 3.9 Aturan Klasifikasi Maturity Level
4 CONCLUSION
Aplikasi ini dapat membantu proses audit berdasarkan framework Cobit. Dengan aplikasi ini standar skor audit dapat diterapkan, sehingga konsistensi penilaian dapat dipertahankan. Selain standar nilai skor, aplikasi ini juga mempunyai pemetaan dokumen, antara dokumen yang disyaratkan oleh sistem dengan dokumen yang dimiliki oleh client/ customer.

REFERENCE
[1] COBIT Framework 4.0, 2007, ISACA.

[2] John Connel, Beginning Visual Basic 6 Database Programming, Wrox Press, 1999.

[3] Francesco Balena, Programming Microsoft Visual Basic 6.0, Microsoft Press, 1999.

interface manusia komputasi


1. c

ANALISA
User-centered design fokus pada user dan task sejak awal desain
Participative design user sebagai anggota dari tim desainer
Experimental design terdapat testing usability oleh user secara formal pada percobaan awal, simulasi dan evaluasi prototype secara keseluruhan
Iterative design desain, testing dan penilaian hasilnya, dan desain ulang sampai hasilnya memenuhi spesifikasi usability yang diinginkan
User-supportive design training, seleksi (jika perlu) manual, quick reference cards, bantuan dari ‘ahli’ yang ada disekitarnya, sistem bantuan (help) seperti:
- on-line: context-specific help
- off-line: ‘hot-line’ phone service


3.


Jadi perbedaanya low dan high fidelity adalah :
1. low fidelity
a. Alat untuk meletakkan, kontrol, interface, dll
b. Telah membangun dan menguji modul dengan lebih baik untukmenunjukkan tampilan
c. Menghasilkan kode melalui pemrograman

2. high fidelity
a. Mudah untuk mengembangkan & memodifikasi tampilan
b. Mendukung jenis interface
c. Mendukung berbagai I / O devices
d. Mudah untuk menghubungkan dan memodifikasi link
e. Memungkinkan memanggil prosedur & program eksternal
f. Memungkinkan mengimpor teks, grafik, media lain
g. Mudah dipelajari dan menggunakan
h. Mempunyai dukungan dari vendor yang baik

hdgshagdjha

Sistem Pendukung Keputusan (Decision Support System)

Definisi
Sistem Pendukung Keputusan
(Decision Support System)
? Suatu sistem yg menyediakan sarana bagi para manajer
untuk mengembangkan informasi sesuai dengan
keputusan yg akan dibuat.
? Tujuan: menunjang keputusan-keputusan yg relatif
tidak terstruktur (unstructured).
? Kebutuhan: 1) sistem yg fleksibel dengan informasi yg
interaktif; 2) mudah digunakan (user friendly); 3)
memungkinkan pembuatan simulasi, proses trial-anderror,
memperhitungkan akibat dari suatu keputusan

Manfaat
Sistem Pendukung Keputusan
1. Pengambilan keputusan yg rasional, sesuai
dengan jenis keputusan yg diperlukan
2. Membuat peramalan (forecasting)
3. Membandingkan alternatif tindakan
4. Membuat analisis dampak
5. Membuat model

Data untuk Perencanaan Daerah
Unsur Data Perencanaan:
1. Survai geodesi: topografi, semantik (alamat, luas, klasifikasi,
nilai)
2. Sumberdaya lahan: tanah (struktur, kondisi), pemanfaatan
penggunaan lahan
3. Kadaster/yuridis: preferensi lahan, beban, pembatasan
(carrying-capacity)
4. Sumberdaya alam: geologi, cadangan air, vegetasi, iklim
5. Instalasi/konstruksi: instalasi bawah/atas permukaan, industri
& energi, permukiman, lalu-lintas & transportasi
6. Kondisi lingkungan: kualitas air, tingkat polusi, kebisingan,
aktivitas yg mempengaruhi lingkungan
7. Ekonomi, sosial & politik: kependudukan, SDM, fasilitas
sosial-budaya, kesehatan, aspirasi politik masyarakat.
Syarat analitis: 1) Data Statistik, 2) Data Spasial, 3) Data
waktu.

contoh sistem pendukung keputusan
Sistem Pendukung Keputusan Klinik
September 13, 2005 — anisfuad
A. Pengantar
Dalam berbagai literatur mengenai mutu pelayanan klinik mutakhir, sistem pendukung keputusan klinik (SPKK) merupakan salah satu jargon yang sering disebut sebagai salah satu alternatif solusi sistemik untuk mencegah medical error dan mendorong sistem pelayanan kesehatan yang menjunjung aspek kemanan pasien (patient safety). Artikel ini akan membahas mengenai pengertian SPKK (khususnya yang berbasis komputer), karakteristik, berbagai contoh aplikasinya serta prospek masa depan.

B. Pengertian
Sistem Pendukung Keputusan (SPK) atau decision support system merupakan salah satu jenis sistem informasi yang bertujuan untuk menyediakan informasi, membimbing, memberikan prediksi serta mengarahkan kepada pengguna informasi agar dapat melakukan pengambilan keputusan dengan lebih baik dan berbasis evidence. Secara hirarkis, SPK biasanya dikembangkan untuk pengguna pada tingkatan manajemen menengah dan tertinggi. Dalam pengembangan sistem informasi, SPK baru dapat dikembangkan jika sistem pengolahan transaksi (level pertama) dan sistem informasi manajemen (level kedua) sudah berjalan dengan baik. SPK yang baik harus mampu menggali informasi dari database, melakukan analisis serta memberikan interpretasi dalam bentuk yang mudah dipahami dengan format yang mudah untuk digunakan (user friendly).
Dari sisi konteks, pada dasarnya sebuah Sistem Pendukung Keputusan Klinik (SPKK) adalah SPK yang diterapkan untuk manajemen klinis. Secara definitif SPKK adalah aplikasi perangkat lunak yang mengintegrasikan informasi yang berasal dari pasien (karakteristik demografis, klinis, sosial psikologis) dengan basis pengetahuan (knowledge base) untuk membantu klinisi dan atau pasien dalam membuat keputusan klinis. Pengguna SPKK adalah tenaga kesehatan yang terlibat dalam tata laksana klinis pasien di rumah sakit mulai dari dokter, perawat, bidan, fisioterapis dan lain-lain.

SPKK tidak harus bersifat elektronis. Kartu Menuju Sehat (KMS) pada dasarnya adalah suatu SPKK sederhana yang menyediakan fasilitas untuk memasukkan data balita secara lengkap mulai dari riwayat persalinan, imunisasi, riwayat minum ASI, berat badan serta grafik yang dilengkapi dengan kriteria status gizi serta panduan tentang bagaimana menginterpretasikan naik turunnya berat badan balita dan dapat digunakan baik oleh tenaga kesehatan maupun orang tua balita. Model SPKK manual lainnya adalah penerapan berbagai algoritma klinis untuk penanganan penyakit tertentu. Namun, dalam tulisan ini kita akan lebih banyak mengulas tentang SPKK yang berbasis komputer.

Sebagaimana ditampilkan pada gambar 1, SPKK tersusun atas komponen sebagai berikut:
Database yaitu kumpulan data yang tersusun secara terstruktur dan dalam format elektronik yang mudah diolah oleh program komputer. Database ini menghimpun berbagai jenis data baik yang berasal dari pasien, obat (jenis, dosis, indikasi, kontraindikasi dll), dokter/perawat dll.
Knowledge base: merupakan kumpulan pengetahuan kedokteran yang merupakan sintesis dari berbagai literatur, protokol klinik (clinical guidelines), pendapat pakar maupun hasil penelitian lainnya yang sudah diterjemahkan dalam bahasa yang dapat dipahami oleh komputer.
Instrumen : adalah alat yang dapat mengumpulkan data klinis seperti: alat pemeriksaan laboratorium, EKG, radiologis dan lain-lain. Keberadaan instrumen dalam suatu SPKK tidak mutlak.
Mesin inferensial (inference engine) : merupakan program utama dalam suatu SPKK yang mengendalikan keseluruhan sistem, mulai dari menangkap informasi yang berasal dari pasien, mengkonsultasikannya dengan knowledge base dan memberikan hasil interpretasinya kepada pengguna.
Antar muka (user interface) : adalah tampilan program komputer yang memungkinkan pengguna berkonsultasi untuk memasukkan data, memilih menu hingga mendapatkan hasil baik berupa teks, grafis, sinyal, simbol dan bentuk interaktivitas lainnya. Interaktivitas dapat bersifat aktif-otomatis maupun pasif.

Jika mesin inferensial adalah program utama yang mengendalikan SPKK maka knowledge base adalah otaknya. Knowledge base dapat diibaratkan sebagai tiruan manusia (dokter) yang ditanamkan ke dalam komputer agar komputer dapat berpikir dan mengambil keputusan sebagaimana manusia(dokter) aslinya. Knowledge base biasanya dikembangkan menggunakan berbagai metode matematis (statistik) seperti Bayesian, neural network maupun aturan simbolis sederhana (IF-THEN). MYCIN, salah satu program SPKK yang paling populer dan dikembangkan pada tahun 1974 menggunakan metode aturan simbolis sederhana seperti pada gambar 2:
Gambar 2. Salah satu rule dalam program MYCIN
ATURAN no 543
JIKA :
jenis infeksinya adalah meningitis
tipe infeksinya adalah bakterial
pasien sedang mendapatkan terapi kortikosteroid

MAKA
Organisme yang mungkin menyebabkan infeksi adalah e.coli (0.4), klebsiella-pneumoniae(0.2), atau pseudomonas aeruginosa(0.1)

Dalam program tersebut, angka 1 menunjukkan derajat kepastian adalah 100% sebaliknya angka -1 menunjukkan derajat ketidakpastian sebesar 100 %. Angka tersebut merupakan hasil sintesis dari berbagai studi dan pendapat pakar. Terdapat juga SPKK yang knowledge basednya menggunakan metode Bayesian untuk manajemen klinis pneumonia seperti pada gambar 3.
Gambar 3. Contoh penghitungan risiko mortalitas pada penderita pneumonia yang menggunakan pendekatan statistik Bayesian.

C. Fungsi SPKK
Alasan mengapa SPKK disebut-sebut sebagai salah satu alternatif untuk mencegah medical error dan mendorong patient safety terletak pada potensi dan fungsinya. SPKK secara umum akan bermanfaat bagi dokter dalam pengambilan keputusan karena memiliki fungsi mulai dari alerting, assisting, critiquing, diagnosis hingga ke manajemen.
a. Alerting
Alert otomatis akan muncul dan memberikan data serta informasi kepada dokter secara cepat pada situasi kritis yang kadang membahayakan. Pada kondisi tersebut, informasi yang lengkap sangat penting dalam pengambilan keputusan, misalnya: nilai laboratorium abnormal, kecenderungan vital sign, kontraindikasi pengobatan maupun kegagalan prosedur tertentu. Sistem alert telah digunakan secara rutin dalam program HELP (Health Evaluation through Logical Processing) mampu menurunkan laju infeksi pasca operatif dari 13% ke 5.5% per hari dan menurunkan prosentase pemberian antibiotik berlebihan dari 35% ke 18%.Gambar 4 menampilkan contoh SPKK yang memberikan alert jika ada permintaan pemeriksaan laboratorium yang berlebihan.
b. Interpretasi
Interpretasi merupakan asimilasi dari data klinis untuk memahami data pasien. Contoh sederhana adalah mesin penginterpretasi EKG, analisis gas datah maupun pemeriksaan radiologis.

c. Assisting (memberikan bantuan)
Adalah contoh SPKK yang bertujuan untuk mempermudah atau mempercepat aktivitas klinis. SPKK yang bersifat hibrid (campuran manual dan elektronik) akan memberikan hasil print out sintesis data pasien yang mengarahkan kepada tindakan manajemen selanjutnya. Pada sistem yang online, SPKK akan menampilkan seluruh data dalam tampilan grafis yang mudah dilihat dan komprehensif seperti pada gambar 5.
Gambar 5. Tampilan grafis rekam medis elektronik yang menampilkan data pasien secara lengkap hingga ke perhitungan risikonya.

d. Critiquing (memberikan kritik)
Jenis aplikasi ini akan memberikan kritik kepada pengguna untuk memverifikasi keputusan klinis yang telah dipilih. Berbagai contoh aplikasi SPKK jenis ini dapat bermanfaat untuk mencegah permintaan pemeriksaan klinis yang tidak tepat (seperti pada gambar 6), pemberian obat yang tidak sesuai dengan indikasi maupun penerapan protokol klinik.

e. Diagnosis
Merupakan contoh aplikasi SPKK yang paling populer dan banyak dipublikasikan sejak tahun 1970-an. Tujuan aplikasi ini adalah memberikan daftar probabilitas berbagai differential diagnosis berdasarkan data pasien yang diinputkan ke dalam komputer.

e. Manajemen
Pada dasarnya, aplikasi jenis ini bertujuan untuk meningkatkan/memperbaiki sistem manajemen klinis yang ada, mulai dari operasional rumah sakit, alokasi sumber daya (termasuk SDM) hingga ke assessment terhadap perubahan pola penyakit yang dirawat.
Gambar 6. Saran tentang pilihan cara pengambilan pemeriksaan rontgen abdomen..

d. Perkembangan SPKK
Hingga saat ini, banyak sekali publikasi mengenai SPKK yang dapat ditemukan di jurnal internasional dengan berbagai kategori. Tabel 1 menyajikan tiga kategori utama SPKK, yaitu SPKK berspektrum luas, mengenah dan kecil dengan contoh aplikasinya masing-masing.

Namun, pengalaman di lapangan menunjukkan bahwa tidak semua aplikasi SPKK diterapkan dalam praktek sehari-hari. Pada waktu awal, gairah riset untuk pengembangan SPKK terpesona dengan kemampuan komputer untuk melakukan analisis secara cepat dan mengumpulkan data yang cukup besar. Sehingga tujuan pengembangan SPKK seakan-akan bertujuan untuk mengganti peran dokter (ingat pertarungan catur Gary Kasparov melawan Deep Blue). Model konsultasi diagnosisk pada program INTERNIST-I pada tahun 1974 menempatkan dokter sebagai pihak yang tidak mampu melakukan diagnosis. Sehingga, dokter diminta untuk memasukkan semua informasi pasien, mulai dari riwayat penyakit, data laboratorium hingga temuan pemeriksaan fisik ke dalam program tersebut untuk mendapatkan hasilnya. Dokter hanya berperan sebagai observer yang pasif dan menjawab YES atau NO terhadap pertanyaan dari INTERNIST-I. Meskipun dari sisi teknis, program INTERNIST-I memiliki kemampuan tinggi untuk mendiagonosis penyakit, tetapi di lapangan tidak ada dokter yang mau memfeed komputer dengan hasil temuannya. Di sisi lain, sangatlah wajar apabila banyak dokter yang menolak SPKK karena aplikasi ini cenderung membatasi otoritas seorang dokter. Namun di sisi lain, perkembangan teknologi informasi menunjukkan hasil yang cukup menggembirakan yang memungkinkan rumahsakit mengintegrasikan berbagai sumber data menggunakan perangkat keras yang semakin mini (komputer yang dikembangkan untuk SPKK pada tahun 1970-an ukurannya sebesar lemari) dan terintegrasi dengan jaringan (termasuk jalur nir kabel). Di Kanada, 50 persen dokter di bawah usia 35 tahun saat ini sudah menggunakan PDA dan aktif mendownload berbagai e-book tentang clinical guidelines yang terdapat di Internet.

Dalam analisisnya tentang perkembangan SPKK, Bates et al menyarankan 10 syarat agar SPKK diterapkan di lapangan, sebagai berikut:
Speed is everything
Anticipate needs and deliver in a real time
Fit into the user’s workflow
Little things can make a big difference
Recognize that physician will strongly resist stopping
Changing direction is easier than stopping
Simple interventions work best
Ask for additional information only when you really need it
Monitor impact, get feedback and respond
Manage and maintain your knowledge based systems

D. Penutup
Sistem pendukung keputusan klinik yang spesifik akan terus berkembang dan meluas penggunaannya. Analisis EKG, interpretasi analisis gas darah, elektroforesis protein serta hitung jenis sel darah berkomputer merupakan beberapa contoh kecil keberhasilan SPK di bidang klinik.
Namun demikian, SPKK generik yang berskala besar masih dipertanyakan. Hal ini sangat tergantung kepada konstruksi dan pemeliharaan basis pengetahuan medis (medical knowledge base). Seperti kita, ketahui, sampai sekarang, sebagian besar rumah sakit di Indonesia masih berkutat dengan subsistem informasi keuangan (khususnya billing). Meskipun, beberapa rumah sakit sudah mengembangkan database rekam medis, tetapi masih terbatas pada pengumpulan data demografis dan diagnosis. Medical knowledge base memerlukan effort yang besar karena harus mengembangkan database klinis pasien (dengan mengumpulkan data diagnosis, simtom, faktor risiko, multimedia, laboratorium hingga ke genetis) serta sumber daya manusia yang konsisten dan terus menerus memelihara dan mengkaji perkembangan mutakhir yang terdapat dalam database pasien serta sumber-sumber literatur kedokteran mutakhir, seperti MEDLINE. Perkembangan pengetahuan terbaru selanjutnya diadaptasi menjadi basis literatur dan dikombinasikan dengan protokol klinik dan outcome terbaik dalam pelayanan klinik sebagai bahan makanan bagi SPKK agar tetap terjaga kekiniannya (gambar 7). Oleh karena itu, pengembangan SPKK jenis ini biasanya sesuai untuk rumah sakit tipe B pendidikan yang memiliki komitmen lebih jelas dalam aspek riset. Sebagian besar literatur yang menjelaskan keberhasilan SPKKpun juga berasal dari institusi besar, dengan jenis layanan tersier dan mayoritas penggunanya adalah residen.

Di sisi yang lain, mengembangkan SPKK generik untuk taraf menengah dan kecil, agar dapat digunakan oleh dokter praktek umum juga sangat dilematis. Kecuali, jika SPKK tersebut didesain dalam bentuk tertentu yang justru akan meningkatkan image dokter di mata pasien. Oleh karena itu, salah satu harapan agar semakin banyak dokter menggunakan SPKK adalah integrasi modul SPKK dengan perangkat yang handy yaitu personal digital assistant (PDA). Namun, hingga saat ini SPKK yang terdapat dalam bentuk PDA lebih banyak bertujuan membantu dokter dalam memilih jenis terapi. Akan tetapi, kemampuan PDA untuk menyimpan database dalam skala besar masih dalam perkembangan. Di rumah sakit besar, pemanfaatan PDA dapat difasilitasi dengan jaringan nir kabel yangmemungkinkan koneksi ke database pasien di rumah sakit.

Sebagai penutup SPKK memiliki prospek yang sangat baik di masa depan. Para peneliti serta publikasi mengenai SPKK menunjukkan pertumbuhan yang meyakinkan dengan jenis aplikasi SPKK yang semakin beragam. Di sisi lain perusahan komersial yang tertarik dengan SPKK juga semakin banyak. Namun, di sisi lain perlu diimbangi dengan assessment tentang cost effectiveness serta prosedur pengujian dan standar mutunya. Semua hal tersebut nantinya akan mendorong perkembangan SPKK baru yang produktif, teruji dan (yang penting lagi) digunakan dalam praktek klinis.

Referensi

Aronsky, D Haug, PJ. An Integrated Decision Support System for Diagnosing and Managing Patients with Community-Acquired Pneumonia. Proceding of AMIA Conference 2002

Zupana, B, Porenta, A. Vidmard, G, Aoki, N. Bratko, I. Beckc, JR.Decisions at Hand: A Decision Support System on Handhelds. Proceeding of MEDINFO 2001 in V. Patel et al. (Eds)Amsterdam: IOS Press 2001

Bates DW, Kuperman, GJ, Wang, S, Gandhi, T, Kittler, A, Volk, L. Spurr, C, Khorasani, R. Tanasijevic, M. Middleton, B. Ten Commandments for Effective Clinical Decision Support: Making the Practice of Evidence-based Medicine a Reality. J Am Med Inform Assoc. 2003;10:523–530.