Audit
Teknologi Sistem Informasi
Audit Proyek Perusahaan
Audit Proyek Perusahaan
(Auditing Company Projects)
Disusun Oleh :
1.
Ananda Rizky Desmansyah (10114992)
2.
Arieq Hanif (11114576)
3.
Hari Angga (14114788)
4.
Muhammad Syahrul Ramadhan (17114557)
5.
Nabhila Ayu Azzahra (17114701)
Kelas :
4KA30
Dosen :
Ardisa Pramudhita
UNIVERSITAS GUNADARMA
SISTEM INFORMASI
PTA 2017/2018
Audit Proyek
Perusahaan
Pendahuluan
Berikut ini akan dibahas
hal-hal yang harus dicari pada saat mengaudit proses-proses pengelolaan proyek
perusahaan, termasuk memahami hal-hal berikut yang berkaitan dengan manajemen
proyek audit teknologi informasi:
• Kunci keberhasilan
manajemen proyek
• Kebutuhan pengumpulan
dan desain awal
• Perancangan dan
pengembangan sistem
• Pengujian
• Implementasi
• Pelatihan
• Wrap up proyek
Sebelum sistem atau
proses dapat diimplementasikan, sebuah proyek harus didanai dan dikelola terlebih
dahulu untuk dapat dikembangkan atau mendapatkan sistem atau proses tersebut.
Jika disiplin yang benar tidak diberlakukan selama proyek berlangsung,
kemungkinan kegagalan dalam memenuhi persyaratan dan atau penggunaan aset
perusahaan yang tidak efisien sangat meningkat.
Latar
belakang:
Teknik manajemen proyek
yang tepat merupakan elemen penting dalam keberhasilan usaha perusahaan.
Teknik-teknik ini membantu memastikan bahwa persyaratan terkait dikumpulkan dan
diuji, sumber daya proyek digunakan secara efisien, dan semua elemen sistem
diuji dengan benar. Tanpa teknik seperti itu, kemungkinan sistemnya yang
dikembangkan tidak akan berfungsi atau tidak akan berjalan seperti yang
diharapkan oleh pemangku kepentingan utama. Hal ini menyebabkan pengerjaan
ulang dan biaya tambahan bagi perusahaan (dan terkadang dapat menyebabkan orang
kehilangan pekerjaan mereka). Manajemen proyek yang baik tidak menjamin
kesuksesan, namun meningkatkan peluang keberhasilan.
Maksud dari penulisan
ini adalah menyediakan daftar risiko dasar yang harus ditinjau saat mengaudit
proyek sistem untuk memastikan bahwa disiplin manajemen proyek yang paling
penting sedang diikuti.
Tujuan:
Tingkat Tinggi Audit
Proyek Audit proyek dilakukan untuk mengidentifikasi risiko terhadap keberhasilan
proyek perusahaan. Di sini membahas secara khusus proyek TI (seperti
pengembangan perangkat lunak, penyebaran infrastruktur, dan penerapan aplikasi
bisnis), namun konsep tersebut dapat diterapkan pada proyek apa pun.
Berikut adalah beberapa tujuan tingkat
tinggi dari audit proyek:
• Memastikan bahwa semua
pemangku kepentingan terkait terlibat dalam pengembangan persyaratan dan
pengujian sistem dan komunikasi yang sering dan efektif terjadi dengan semua
pemangku kepentingan. Kegagalan untuk mengumpulkan persyaratan pelanggan dan untuk
mendapatkan keterlibatan pelanggan yang berkelanjutan dan pembelian mengarah
pada perangkat lunak, sistem, dan proses yang sedang dikembangkan atau dibeli
yang tidak sesuai dengan kebutuhan bisnis.
• Memastikan bahwa
masalah proyek, anggaran, tonggak sejarah, dan sebagainya, dicatat, diputuskan,
dan dilacak. Tanpa mekanisme ini, proyek lebih cenderung membahas anggaran dan
jadwal dengan masalah yang belum terselesaikan.
• Pastikan pengujian
yang efektif mencakup semua persyaratan sistem. Pengujian yang tidak memadai
menyebabkan sistem yang tidak stabil dan bermutu rendah yang gagal memenuhi
kebutuhan pelanggan.
• Pastikan dokumentasi
yang tepat dikembangkan dan dipelihara. Dokumentasi teknis dan pengguna yang
tidak lengkap atau ketinggalan zaman dapat meningkatkan waktu biaya dan siklus
untuk mempertahankan perangkat lunak, meningkatkan biaya dukungan dan
pelatihan, dan membatasi kegunaan sistem kepada pelanggan.
• Pastikan bahwa
pelatihan yang memadai diberikan kepada pengguna akhir pada saat pelaksanaan.
Pelatihan yang tidak memadai mengarah pada sistem, proses, dan perangkat lunak
yang tidak terpakai atau digunakan dengan tidak semestinya.
Pendekatan
Dasar untuk Audit Proyek
Dua pendekatan dasar
dapat dilakukan dengan audit proyek. Pendekatan pertama adalah pendekatan cepat
dan singkat. Pendekatan kedua mengambil pandangan jangka panjang dari proyek
ini dan sebuah pendekatan yang lebih konsisten.
Pendekatan jangka pendek
bisa menjadi tantangan; auditor memilih satu titik dalam proyek untuk melakukan
audit mereka, dan kemudian mereka meninjau proyek tersebut pada saat itu dan
membuat keputusan berdasarkan apa yang telah terjadi dan apa yang direncanakan.
Pendekatan ini memiliki dua kekurangan utama.
Pertama, sulit bagi
auditor untuk mempengaruhi fase yang telah selesai. Misalnya, tahap pengujian
penerimaan pengguna adalah saat yang buruk untuk mengetahui bahwa proses yang
kurang terkontrol digunakan selama fase definisi proyek. Tim proyek harus
meninjau kembali dan mengolah ulang untuk memperbaiki tugas sebelumnya atau
melangkah maju, mengetahui bahwa ada masalah dan berharap mendapatkan yang
terbaik. Either way, masukan auditor tidak terlalu tepat waktu dan bahkan dapat
dilihat sebagai hubungan kontraproduktif dan merusak antara auditor dan
pelanggannya.
Kedua, tahap evaluasi
sepenuhnya yang belum dimulai sulit dilakukan. Auditor mungkin dapat meninjau
rencana pengujian penerimaan pengguna pada awal proyek, misalnya, namun sampai
rencana tersebut dikembangkan sepenuhnya dan dijalankan, auditor akan merasa
sulit untuk mengevaluasi keefektifan sebenarnya mereka.
Keterlibatan jangka
panjang, atau keterlibatan yang konsisten, memungkinkan auditor untuk melakukan
beberapa kegiatan penilaian selama setiap tahap utama proyek. Setiap audit
mengevaluasi proses dalam fase saat ini sambil menilai dan memberikan masukan
pada rencana untuk fase yang akan datang. Ini adalah cara efektif untuk
mengaudit proyek dan mengarah pada pendekatan kolaboratif dengan pelanggan
audit.
Di sisi negatif,
pendekatan ini membentang di luar audit dalam jangka waktu yang panjang dan
sulit untuk dijadwal. Namun, memiliki hal positif jauh lebih banyak daripada
yang negatif.
Jika proyek ini mencakup
periode waktu yang sangat lama, auditor mungkin mempertimbangkan salah satu
dari dua pendekatan berikut:
• Melepaskan laporan
audit interim setelah setiap tahap proyek utama sehingga informasi dalam
laporan tidak menjadi terlalu basi.
• Bertemu dengan manajer
proyek untuk mendiskusikan masalah secara reguler (seperti setiap dua minggu).
Pada pertemuan ini, auditor dapat mengkomunikasikan risiko baru terhadap proyek
yang ditemukan sejak pertemuan terakhir dan juga menindaklanjuti status isu-isu
sebelumnya untuk menentukan apakah remediasi telah selesai. Jika, menurut
pendapat auditor, risiko proyek meningkat ke tingkat yang tidak memuaskan, atau
jika masalah tidak diatasi, auditor dapat meningkat ke tingkat manajemen yang
lebih tinggi atas kebijaksanaan mereka sendiri. Auditor harus memiliki hak
untuk mengeluarkan laporan audit secara skala penuh setiap saat, namun dengan
mencoba bekerja sama dengan manajer proyek terlebih dahulu, masalah akan
dipecahkan tanpa eskalasi dan tanpa dikeluarkannya laporan audit sementara.
Tujuh
Bagian Utama Proyek Audit
Proyek dapat dipisahkan
menjadi tujuh bagian utama, masing-masing memerlukan disiplin dan kontrol yang
akan kita evaluasi selama audit proyek. :
1. Keseluruhan
manajemen proyek.
Mekanisme yang harus
digunakan sepanjang proyek, seperti pelacakan isu, dokumentasi proyek, dan
manajemen perubahan.
2. Permulaan proyek,
pengumpulan kebutuhan, dan desain awal.
Meliputi permulaan
proyek: di mana kebutuhan akan proyek ditetapkan, persyaratan dikumpulkan, dan
desain awal dan studi kelayakan dilakukan.
3. Desain dan pengembangan
sistem.
Meliputi "isi"
proyek: di mana kode ditulis, produk dibeli atau diimplementasikan, prosesnya
dikembangkan, dan seterusnya.
4. Pengujian.
Sistem, perangkat lunak,
atau proses diuji untuk memastikan memenuhi persyaratan.
5. Implementasi.
Sistem, perangkat lunak,
atau proses diimplementasikan atau dipasang ke lingkungan produksi.
6. Pelatihan.
Meliputi kegiatan untuk
melatih pengguna akhir dalam menggunakan sistem, perangkat lunak, atau proses
yang telah dikembangkan dan diimplementasikan.
7. Wrap-up proyek.
Meliputi kegiatan
pasca-implementasi.
Unsur-unsur proyek ini
tidak harus dilakukan dalam urutan yang tepat, dan juga tidak akan dilakukan
secara berurutan. Beberapa iterasi setiap fase mungkin ada, dan beberapa
mungkin dilakukan sejajar satu sama lain (misalnya, pelatihan pengguna sering
dilakukan bersamaan dengan pengujian dan implementasi). Namun, hampir setiap
proyek harus memiliki beberapa dari masing-masing elemen ini.
Bagian selanjutnya dari
bab ini akan berfokus pada langkah-langkah audit utama dan tes untuk dilakukan
berkenaan dengan tujuh kategori ini.
Langkah-langkah
Uji untuk mengaudit Proyek Perusahaan
Untuk menyediakan
beberapa konteks dan struktur, langkah-langkah uji di bagian ini disediakan
sesuai dengan tahap proyek. Namun, langkah-langkahnya tidak selalu berjalan
semulus apa yang telah ditata; setiap proses memiliki situasi dan persyaratan
yang unik untuk dipertimbangkan. Misalnya, waktu untuk mengatasi langkah dari
bagian pengujian mungkin terjadi selama fase pengumpulan-permintaan.
Anda harus melakukan
setiap langkah pada titik di proyek yang paling masuk akal, berdasarkan
bagaimana proyek dijalankan.Sangat penting bagi auditor untuk memahami
metodologi proyek dan menyesuaikan pendekatannya dengan tepat. Misalnya, jika
proyek menggunakan pengembangan inkremental, di mana setiap fase proyek
dieksekusi berkali-kali, Anda mungkin perlu mengaudit setiap fase secara
bersamaan atau bahkan mungkin berkali-kali.
Kontrol yang diperlukan
untuk sebuah proyek umumnya akan sama terlepas dari metodologi proyek, namun
sesuai dengan fase audit terhadap proyek dan mengkoordinasikan waktunya akan
lebih sulit untuk beberapa jenis proyek daripada proyek lainnya. Bagian dari
proses perencanaan harus melibatkan pemahaman metodologi proyek yang digunakan
dan menentukan waktu dan metode yang tepat untuk menyelesaikan langkah-langkah
dalam program ini.
Saat merencanakan audit,
Anda harus menentukan alat manajemen proyek apa yang digunakan oleh tim proyek
dan menjadi terbiasa dengan alat dan terminologinya. Ini akan memungkinkan Anda
untuk "berbicara bahasa yang sama" sebagai orang yang Anda audit dan
selanjutnya meningkatkan kredibilitas. Selain itu, beberapa langkah ini mungkin
berlebihan untuk proyek yang lebih kecil. Anda harus menggunakan penilaian
dalam menentukan risiko mana yang cukup material untuk ditangani untuk setiap
proyek tertentu.
Akhirnya,
langkah-langkah ini ditulis sehingga bisa digunakan untuk proyek TI apa pun,
apakah melibatkan perolehan atau pengembangan perangkat lunak, pengadaan
teknologi baru, atau pengembangan proses. Gunakan penilaian Anda untuk
menentukan langkah mana yang paling sesuai dengan jenis proyek yang diaudit.
Keseluruhan
Manajemen Proyek
Langkah-langkah dalam
bagian ini biasanya harus dilakukan secara menyeluruh pada awal proyek dan
sekali lagi ringan selama setiap tahap proyek untuk memastikan bahwa disiplin
ilmu masih diikuti. Manajemen proyek mungkin mulai kuat, tapi sering kali
berkurang saat orang menjadi sibuk dan berjuang untuk memenuhi tenggat waktu.
1. Pastikan dokumentasi proyek dan
dokumentasi pengembangan perangkat lunak yang memadai (jika ada) telah dibuat.
Pastikan standar metodologi proyek perusahaan diikuti. Dokumentasi semacam ini
akan meningkatkan kemungkinan bahwa proyek tersebut dilaksanakan secara
disiplin dan mengikuti standar dan metodologi yang ditetapkan perusahaan Anda.
Hal ini, pada gilirannya, sangat meningkatkan kemungkinan bahwa proyek akan
berhasil dilaksanakan dan akan menghasilkan nilai bisnis yang diinginkan.
Dokumentasi ini juga dapat menguntungkan proyek-proyek masa depan, yang
memungkinkan perusahaan memanfaatkan usaha masa lalu. Akhirnya, perusahaan Anda
mungkin memiliki standar khusus untuk melaksanakan proyek berbasis, baik dalam
persyaratan internal maupun peraturan.
Bagaimana
caranya? Tinjau
salinan dokumentasi proyek yang ada dan membandingkannya dengan standar dan
persyaratan perusahaan Anda. Dokumen yang dibutuhkan akan bervariasi oleh
perusahaan, namun mencari dokumen yang mencakup area seperti tonggak, struktur
rincian pekerjaan (work breakdown structure / WBS), pendekatan proyek,
pernyataan kerja (SOW), persyaratan, rencana uji, dan dokumen desain. Dapatkan
salinan standar metodologi proyek perusahaan Anda dan bandingkan dengan
metodologi yang sedang dijalankan pada proyek yang sedang ditinjau. Saat
meninjau dokumentasi ini, carilah bukti perencanaan proyek dan sumber daya yang
memadai. Melakukan langkah ini bukanlah ilmu pasti; Anda mencoba mengembangkan
nuansa untuk keseluruhan tingkat dokumentasi dan proses yang ditetapkan untuk
proyek ini. Beberapa dokumentasi ini akan diperiksa secara lebih rinci pada
langkah selanjutnya. Dalam langkah ini, auditor harus memperoleh dokumen yang
merupakan rencana proyek dasar dan menentukan apakah kebutuhan, kiriman,
sasaran, dan cakupan pelanggan didefinisikan secara jelas.
2.
Tinjau prosedur untuk
memastikan bahwa dokumentasi proyek selalu diperbarui. Untuk alasan yang
disebutkan di langkah sebelumnya, dokumentasi ini meningkatkan kualitas proyek
saat ini dan masa depan. Namun, jika dibiarkan menjadi usang, dengan cepat
menjadi tidak berguna.
Bagaimana
caranya? Lakukan
wawancara dengan tim proyek, pahami proses yang ada untuk memperbarui
dokumen-dokumen ini bila diperlukan. Carilah bukti bahwa pembaruan telah
dilakukan.
3. Evaluasi proses manajemen keamanan
dan perubahan untuk dokumentasi proyek kritis. Jika kontrol keamanan dan
perubahan yang benar tidak dilakukan, perubahan yang tidak sah, tidak akurat,
dan / atau tidak perlu dapat dilakukan pada dokumentasi proyek.
Bagaimana
caranya? Pastikan
bahwa file yang berisi dokumentasi proyek dikunci dan dapat dimodifikasi hanya
oleh subkumpulan personil proyek yang sesuai (menggunakan teknik yang
dijelaskan pada Bab 6 untuk file Windows dan Bab 7 untuk file Unix atau Linux).
Wawancara personil proyek untuk memahami proses perubahan dokumen proyek
kritis. Pastikan proses persetujuan diperlukan sebelum perubahan dilakukan
terhadap dokumen proyek yang signifikan dan bahwa proses persetujuan tidak
dapat dielakkan. Dokumen-dokumen yang merupakan rencana proyek dasar (seperti
kebutuhan pelanggan, kiriman, sasaran, cakupan, anggaran, risiko, dan strategi
komunikasi) harus dimulai pada awal proyek sehingga tidak dapat diubah tanpa
persetujuan dari semua pemangku kepentingan utama.
4. Mengevaluasi prosedur untuk memback
up perangkat lunak dan dokumentasi proyek kritis. Pastikan bahwa backup
disimpan di luar lokasi dan prosedur terdokumentasi ada untuk pemulihan. Jika
proses ini tidak berjalan, sistem crash atau bencana data center dapat mengakibatkan
hilangnya permanen perangkat lunak dan dokumentasi proyek.
Bagaimana
caranya? Review proses atau skrip yang menunjukkan
bahwa data proyek dicadangkan dan disimpan di luar kantor. Tinjau prosedur
pemulihan tertulis, pastikan mereka menentukan langkah-langkah apa yang harus
dilakukan untuk pemulihan, urutan langkah-langkah tersebut, dan siapa yang
harus melakukan setiap langkahnya. Perhatikan bahwa prosedur pemulihan tertulis
ini mungkin tidak dibuat dan unik untuk proyek tertentu. Mereka mungkin malah
menjadi bagian dari prosedur pemulihan standar tim TI untuk file yang hilang.
Pertimbangkan untuk meminta pemulihan uji materi proyek kritis.
5. Pastikan proses yang efektif ada
untuk menangkap isu-isu proyek, meningkatkan isu-isu tersebut sebagaimana
mestinya, dan melacaknya sesuai resolusi. Selama proyek apapun, masalah pasti
akan timbul mengenai proyek itu sendiri atau sistem, proses, atau perangkat
lunak yang sedang dikembangkan. Tanpa metode yang kuat untuk menangkap dan
menyelesaikan masalah tersebut, beberapa masalah kemungkinan akan "lolos
dari celah" dan tidak dapat diselesaikan, yang mengakibatkan kegagalan
dalam produk atau kegagalan dalam pelaksanaan proyek.
Bagaimana
caranya? Tinjau ulang
masalah database, spreadsheet, atau metode lain yang ada untuk mencatat dan
melacak masalah. Pastikan alat pelacak masalah mencatat informasi yang memadai
mengenai setiap masalah, termasuk deskripsi masalah, tingkat prioritas, tanggal
jatuh tempo, status terbaru, dan informasi resolusi. Pastikan kontrol ada di
atas alat yang digunakan untuk melacak masalah, seperti backup dan keamanan
untuk mencegah pembaruan yang tidak sah. Tinjau ulang proses untuk mengatasi
masalah dan untuk memastikan bahwa isu dilacak ke resolusi. Tinjau daftar
masalah untuk bukti bahwa masalah sedang ditutup. Wawancara pelanggan untuk
memastikan prosesnya berjalan.
6. Pastikan ada proses yang efektif
untuk menangkap permintaan perubahan proyek, memprioritaskan, dan
memposisikannya. Selama sebagian besar proyek, permintaan untuk fungsi tambahan
akan muncul setelah proyek dimulai dan persyaratan telah ditetapkan dan
disetujui. Tanpa metode untuk memastikan bahwa permintaan ini diprioritaskan
dan diposisikan, permintaan ini mungkin akan hilang, dan / atau ruang lingkup
proyek akan terus bergeser, sehingga tidak mungkin melaksanakan proyek secara
efektif. Proses permintaan perubahan akan membantu mencegah creep lingkup dan
menyediakan diskusi yang sedang berlangsung dengan pelanggan proyek mengenai
bagaimana perubahan permintaan akan berdampak pada anggaran dan jadwal proyek.
Bagaimana
caranya? Kaji ulang
proses manajemen perubahan dan memastikan bahwa ia menyediakan penyisihan untuk
memasukkan, memberi peringkat, dan menyetujui permintaan perubahan. Verifikasi
bahwa hal itu mencakup perubahan pada lingkup, jadwal, anggaran, persyaratan,
desain, dan sebagainya (yaitu, semua elemen utama proyek). Pastikan informasi
tersebut mencatat informasi yang memadai mengenai setiap permintaan perubahan,
termasuk deskripsi permintaan, tingkat prioritas, status terbaru, persetujuan,
dan informasi resolusi. Pilih contoh permintaan perubahan, dan jalanilah mereka
melalui proses tersebut, pastikan persetujuan yang benar telah diterima sebelum
resolusi akhir.
7. Pastikan jadwal proyek telah dibuat
dan berisi detail yang cukup berdasarkan ukuran proyek. Pastikan bahwa ada
proses untuk memantau kemajuan dan melaporkan penundaan yang signifikan. Jadwal
proyek digunakan untuk memastikan bahwa proyek berjalan dengan baik, sumber
daya digunakan secara efektif, dan semua tugas telah dicatat dan dijadwalkan.
Bagaimana
caranya? Tinjau
jadwal proyek, dan mencari item seperti rincian pekerjaan, tanggal tonggak,
dependensi tugas, dan jalur kritis. Carilah bukti bahwa jadwal diikuti dan
selalu up-to-date. Carilah penjelasan untuk delta yang signifikan. Pastikan
bahwa prosedur eskalasi ada untuk jadwal yang signifikan atau overruns sumber
daya, dan tinjau kembali bukti bahwa proses tersebut telah digunakan. Salah
satu cara potensial untuk memastikan pemenuhan jadwal adalah membuat titik
strategis dalam siklus hidup dimana proyek melewati proses "pintu
gerbang". Pada titik-titik ini, tim proyek melapor ke panel tinjauan untuk
menyampaikan status proyek , keberhasilan dan isu, dan kemajuan dibandingkan
jadwal dan anggaran. Ini membantu mengidentifikasi perjuangan dan kegagalan
dengan cepat saat terjadi.
8. Pastikan bahwa ada metode untuk
melacak biaya proyek dan melaporkan overruns. Pastikan semua biaya proyek,
termasuk tenaga kerja, dipertimbangkan dan dilacak. Tanpa mekanisme ini,
anggaran proyek seringkali dapat terlampaui, dan seringkali tingkat pengelolaan
yang sesuai tidak diketahui masalah ini. Manajemen mungkin telah menempatkan
topi pada pendanaan untuk proyek tertentu. Jika semua biaya yang relevan tidak
dilacak, manajemen tidak akan mengetahui jika batas tersebut telah terlampaui
dan oleh karena itu, tidak dapat mengambil keputusan mengenai bagaimana
melanjutkan.
Bagaimana
caranya? Dapatkan
salinan anggaran, dan membandingkannya dengan biaya sampai saat ini. Carilah
penjelasan untuk delta yang signifikan. Pastikan anggaran mencakup semua biaya
yang terkait dengan proyek, termasuk tenaga kerja, perangkat lunak, dan
perangkat keras. Pastikan prosedur eskalasi ada untuk overruns biaya yang
signifikan, dan meninjau bukti bahwa proses telah digunakan.
9. Evaluasi struktur kepemimpinan proyek
untuk memastikan bahwa bisnis dan TI diwakili secara memadai. Kecuali untuk
beberapa proyek infrastruktur murni, sebagian besar proyek dilakukan sesuai
permintaan bisnis untuk memenuhi kebutuhan bisnis. Jika pemangku kepentingan
bisnis utama bukan bagian dari struktur kepemimpinan dan persetujuan
keseluruhan untuk proyek ini, kemungkinan proyek tersebut tidak dapat dilacak
dari kebutuhan bisnis, karena informasi dan keputusan tentang proyek akan
ditangani oleh orang-orang TI, yang mungkin tidak memiliki perspektif yang
diperlukan untuk membuat semua keputusan. Ingatlah bahwa TI ada untuk mendukung
bisnis, dan karena itu organisasi TI seharusnya tidak membuat keputusan
mengenai kebutuhan TI bisnis dalam ruang hampa. Sebaliknya, personel IT juga
harus menjadi bagian dari struktur, karena pada umumnya mereka membawa
pengetahuan dan perspektif penting mengenai unsur-unsur kesuksesan proyek yang
berhubungan dengan TI. Mereka dapat membantu memastikan bahwa sistem dirancang
dengan cara yang efektif yang memungkinkan dukungan jangka panjang. Sistem yang
dikembangkan tanpa keterlibatan TI jauh lebih mungkin memiliki masalah dengan
skalabilitas, interoperabilitas, dan dukungan. Mereka juga lebih cenderung
mengalami masalah penyebaran, yang mengakibatkan dampak negatif pada jadwal
proyek.
Bagaimana
caranya? Dapatkan salinan struktur kepemimpinan
proyek, dan mencari bukti bahwa pemimpin bisnis dan TI dan pemangku kepentingan
diwakili.
Project
Start-up: Persyaratan Gathering dan Initial Design
10. Pastikan proses persetujuan proyek
yang tepat diikuti sebelum inisiasi proyek. Proyek tidak boleh dimulai tanpa
persetujuan dari anggota manajemen yang tepat yang berwenang untuk
mengalokasikan sumber daya dan dana ke proyek baru.
Bagaimana
caranya? Kaji ulang
bukti bahwa proyek tersebut melewati proses persetujuan standar perusahaan.
Jika tidak ada proses seperti itu, tinjau bukti bahwa manajer yang tepat
menyetujui proyek sebelum memulai. Carilah bukti bahwa analisis alternatif dan
biaya-manfaat dilakukan. Pastikan analisis biaya-manfaat tidak hanya
mempertimbangkan biaya start-up proyek tetapi juga biaya yang terus berlanjut,
seperti pemeliharaan perangkat lunak, perawatan perangkat keras, biaya dukungan
(tenaga kerja), persyaratan daya dan pendinginan untuk perangkat keras sistem,
dan faktor lainnya. Unsur ini sering dihilangkan secara keliru, yang
menyebabkan keputusan salah informasi. Biaya awal hanya sebagian kecil dari
total biaya yang dikeluarkan untuk menerapkan sistem baru. Multiyears (lima
tahun sering menjadi target yang baik) model biaya total harus dikembangkan
sebagai bagian dari analisis awal proyek.
11. Pastikan bahwa analisis kelayakan
teknis telah dilakukan bersamaan dengan, jika ada, sebuah analisis kelayakan
oleh departemen hukum perusahaan. Sebelum memulai proyek TI, arsitek teknis
yang berkualitas, personil jaringan, administrator database, dan pakar IT lainnya
harus setuju bahwa konsep yang diajukan akan sesuai dengan lingkungan
perusahaan. Jika para ahli ini dibawa awal, kemungkinan profesional teknis
dapat menemukan cara untuk membuat konsep tersebut berjalan. Namun, jika dibawa
setelah elemen kunci dari sistem telah dikembangkan atau dibeli, mungkin
ditentukan bahwa solusinya tidak layak secara teknis, menyebabkan pengerjaan
ulang atau penghentian proyek yang mahal. Demikian juga, penting untuk
melibatkan tim hukum untuk memastikan bahwa persyaratan peraturan
dipertimbangkan dalam proyek.
Bagaimana
caranya? Tinjau ulang
bukti bahwa personil teknis dan hukum yang sesuai terlibat dalam proposal
proyek awal dan mereka menyetujui kelayakan proyek tersebut.
12. Tinjau dan mengevaluasi dokumen
persyaratan. Tentukan apakah dan bagaimana persyaratan pelanggan untuk proyek
diperoleh dan didokumentasikan sebelum pembangunan berlangsung. Pastikan
pelanggan menandatangani persyaratan dan persyaratan mencakup elemen standar
TI. Sistem, perangkat lunak, dan proses harus dibangun berdasarkan persyaratan
pengguna akhir. Jika persyaratan pengguna akhir tidak ditangkap dan disetujui
oleh pelanggan, produk tersebut kemungkinan tidak akan memenuhi kebutuhan
pelanggan, memerlukan pengerjaan ulang dan perubahan. Selain itu, elemen
standar TI tertentu harus disertakan dalam definisi persyaratan sistem apapun.
Pelanggan mungkin tidak menyadari unsur-unsur ini dan oleh karena itu
memerlukan bimbingan dari tim TI. Menetapkan persyaratan yang didefinisikan
dengan jelas juga akan membantu dalam diskusi di jalan mengenai apa yang
diperbaiki bug (yaitu saat sistem tidak berfungsi sebagaimana mestinya) dan
apakah permintaan peningkatan (yaitu, ketika sistem berfungsi seperti yang
dirancang namun pelanggan ingin melakukan perubahan), yang bisa menjadi
perbedaan penting tergantung pada model dukungan dan pendanaan organisasi TI
Anda.
Bagaimana
caranya? Tinjau
dokumentasi proyek untuk bukti bahwa persyaratan pelanggan dikumpulkan. Pastikan
semua pemangku kepentingan utama, termasuk sponsor proyek, terlibat dalam
proses ini. Carilah bukti bahwa pemangku kepentingan utama menyetujui daftar
persyaratan akhir. Tinjau persyaratan pelanggan untuk memastikan bahwa mereka
mendokumentasikan persyaratan bisnis dan tidak mendikte solusi. Seringkali,
pemimpin bisnis akan berbicara kepada vendor atau membaca artikel dan
memutuskan untuk membuat sebuah proyek dengan tujuan menerapkan produk atau
teknologi tertentu. Namun, produk tertentu itu mungkin bukan yang paling banyak
cocok untuk situasi perusahaan Anda. Misalnya, mungkin tidak sepenuhnya
memenuhi kebutuhan bisnis, namun mungkin berlebihan dengan produk lain yang
saat ini digunakan di lingkungan, atau mungkin tidak terlalu sesuai dengan
teknologi perusahaan yang ada. Sangat penting bahwa fokus pelanggan pada
menentukan dan mendokumentasikan persyaratan bisnis dan memungkinkan organisasi
TI fleksibilitas untuk menentukan alat apa yang paling sesuai dengan
persyaratan tersebut.
Pastikan persyaratan mencakup elemen
TI standar seperti berikut ini:
Persyaratan
pemrosesan terdistribusi dan tersentralisasi (misalnya, lokasi penyimpanan
dan pemrosesan dalam arsitektur multitier)
|
Perjanjian tingkat
layanan (misalnya, ketersediaan sistem, kecepatan respons terhadap masalah)
|
Waktu respon (untuk
transaksi online)
|
Persyaratan
antarmuka
|
Keamanan
|
Persyaratan Backup/
Restart/Recovery
|
Frekuensi eksekusi
|
Restorasi Kebutuhan
perangkat keras
|
Persyaratan
penyimpanan data
|
Kapasitas, termasuk
kebutuhan untuk pertumbuhan yang diantisipasi di masa depan
|
Persyaratan untuk
keluaran distribusi
|
Toleransi kesalahan
dan redundansi
|
Definisi layar
|
Jika proyek ini
dimaksudkan untuk mengganti sistem yang ada, cari bukti bahwa analisis sistem
saat ini dilakukan untuk menentukan apa yang bekerja dengan baik dan mana yang
tidak. Juga, carilah bukti bahwa sistem yang ada telah dianalisis dengan
seksama dan semua kasus penggunaan (fungsi) yang ada yang dipenuhi dipenuhi
dengan sistem yang baru. Hasil analisis ini harus tercermin dalam dokumentasi
persyaratan. Kesalahan log dan permintaan backlog dari sistem lama dapat
membantu dalam upaya menentukan apa yang sebenarnya tidak bekerja dengan baik
13. Evaluasi proses untuk memastikan
bahwa semua kelompok yang terkena dampak yang akan membantu mendukung sistem,
perangkat lunak, atau proses terlibat dalam proyek dan akan menjadi bagian dari
penandatanganan proses, menunjukkan kesiapan mereka untuk mendukungnya.
Beberapa organisasi di lingkungan TI biasanya terlibat dalam mendukung sistem
baru, termasuk dukungan jaringan, dukungan sistem operasi, dukungan basis data,
personil pusat data, keamanan TI, dan meja bantuan. Jika organisasi-organisasi
ini tidak terlibat dalam proyek sejak awal, mereka mungkin tidak siap untuk
mendukung sistem setelah sistem siap, dan / atau sistem mungkin tidak sesuai
dengan standar dan kebijakan yang berlaku.
Bagaimana
caranya? Tinjau kembali
bukti bahwa organisasi TI yang terkena dampak telah diberitahu tentang proyek
tersebut dan merupakan bagian dari proses persetujuan (yang berkaitan dengan
kesiapan mereka untuk mendukungnya).
14. Tinjau kembali proses penetapan
prioritas persyaratan. Seringkali, lebih banyak persyaratan sistem ada daripada
yang dapat tercakup dalam proyek (atau setidaknya pada tahap awal proyek).
Persyaratan yang paling penting harus diidentifikasi, diprioritaskan, dan
diterapkan.
Bagaimana
caranya? Cari bukti bahwa persyaratan diprioritaskan
dan pemegang saham utama menyetujui prioritasnya.
15. Tentukan apakah persyaratan sistem
dan desain awal memastikan bahwa elemen pengendalian internal dan keamanan yang
tepat akan dirancang ke dalam sistem, proses, atau perangkat lunak. Kontrol
internal diperlukan untuk melindungi sistem perusahaan dan memastikan
integritas mereka. Jauh lebih mudah membangun kontrol ke sistem baru di depan
daripada mencoba menambahkannya pasca implementasi.
Bagaimana
caranya? Auditor
perlu menentukan jenis kontrol apa yang akan dia audit sistem untuk penerapan
di masa depan dan memastikan bahwa kontrol tersebut dirancang ke dalam sistem.
Kontrol aplikasi dan kontrol infrastruktur yang tepat harus dipertimbangkan. Selain
itu, mungkin tepat untuk menetapkan auditor keuangan / operasional ke proyek
tersebut untuk memastikan bahwa pengendalian bisnis yang tepat dibangun ke
dalam logika sistem dan alur kerja.
16. Jika proyek melibatkan pembelian
perangkat lunak, teknologi, atau layanan eksternal lainnya, tinjau dan evaluasi
proses seleksi vendor dan kontrak terkait. Membeli produk dari vendor luar
biasanya merupakan investasi yang signifikan dan merupakan komitmen terhadap
produk vendor itu. Jika proses pemilihan vendor tidak memadai atau kontrak
tidak memberi perusahaan perlindungan yang memadai, hal itu dapat menyebabkan
pembelian produk yang tidak memenuhi persyaratan proyek dan kurangnya jalur
hukum.
Bagaimana
caranya? Tinjau
proses seleksi vendor untuk elemen seperti ini:
• Pastikan produk dari
beberapa vendor dievaluasi mengenai kemampuan mereka untuk memenuhi semua
persyaratan proyek dan kompatibilitasnya dengan lingkungan TI perusahaan. Ini
tidak hanya membantu Anda memilih produk terbaik untuk kebutuhan Anda, namun
penawarannya kompetitif dan harga yang lebih rendah.
• Pastikan analisis
biaya telah dilakukan pada produk yang sedang dievaluasi. Analisis ini harus
mencakup semua biaya yang relevan, termasuk biaya produk, biaya startup satu
kali, biaya perangkat keras, biaya perizinan, dan biaya perawatan.
• Menentukan apakah
stabilitas keuangan vendor diselidiki sebagai bagian dari proses evaluasi.
Kegagalan untuk melakukannya dapat mengakibatkan perusahaan Anda mendaftar
dengan vendor yang gulung tikar, menyebabkan gangguan yang signifikan pada
operasi Anda saat Anda mencoba memindahkannya ke vendor lain.
• Tentukan apakah
pengalaman vendor dengan memberikan dukungan untuk produk untuk perusahaan
sejenis di industri ini dievaluasi. Ini mungkin termasuk mendapatkan dan
mewawancarai referensi dari perusahaan yang saat ini menggunakan produk. Anda
umumnya ingin menggunakan vendor yang telah menunjukkan bahwa mereka dapat
melakukan jenis layanan yang Anda butuhkan pada skala yang serupa dengan Anda.
• Pastikan kemampuan
dukungan teknis vendor dipertimbangkan dan dievaluasi.
• Pastikan setiap vendor
dibandingkan dengan kriteria yang telah ditentukan, memberikan evaluasi yang
obyektif.
• Tentukan apakah ada
keterlibatan personil pengadaan yang tepat untuk membantu menegosiasikan
kontrak, personil operasi untuk memberikan evaluasi ahli mengenai kemampuan
vendor untuk memenuhi persyaratan, dan personil hukum untuk memberikan panduan
mengenai potensi peraturan dan konsekuensi hukum lainnya.
• Setelah vendor
dipilih, pastikan kontrak mengidentifikasi dengan jelas kiriman, persyaratan,
dan tanggung jawab. Kontrak harus menentukan bagaimana kinerja akan diukur dan
denda untuk kinerja yang tidak kinerja atau tertunda. Ini juga harus memberikan
syarat untuk mengakhiri kesepakatan. Pada dasarnya, apa pun yang Anda harapkan
dari vendor perlu dijelaskan secara khusus dalam kontrak.
• Pastikan bahwa kontrak
berisi klausul nondisclosure yang mencegah vendor untuk mengungkapkan informasi
perusahaan.
• Pastikan bahwa kontrak
berisi klausul "hak untuk mengaudit" yang memungkinkan Anda mengaudit
aktivitas vendor yang penting bagi perusahaan Anda.
• Bila memungkinkan,
pastikankode tersebut dimasukkan ke dalam escrow untuk melindungi dari
ketidaktersediaan jika vendor tersebut gulung tikar dan bahwa strategi exit
yang tepat ada jika hubungan antara perusahaan Anda dan vendor dihentikan
karena alasan apa pun.
Desain
dan Pengembangan Sistem Terperinci
17. Pastikan bahwa semua persyaratan
dapat dipetakan ke elemen desain. Proses yang didefinisikan untuk melacak
persyaratan pada perancangan sistem akan memberikan kepastian bahwa semua
persyaratan ditangani, termasuk elemen TI standar seperti antarmuka, waktu respon,
dan kapasitas.
Bagaimana
caranya? Jika ada
daftar jejak persyaratan, tinjau dan verifikasi bahwa semua persyaratan
diwakili dan dipetakan ke elemen desain. Jika peta jejak tidak ada, tinjau
proses untuk memastikan bahwa semua persyaratan tercakup.
18. Verifikasi bahwa pemangku kepentingan
utama telah menandatangani dokumen desain rinci atau katalog "use
case". Dokumen desain rinci digunakan untuk perancangan sistem, perangkat
lunak, atau proses. Katalog "use case" dapat dibuat untuk pelanggan
proyek sebagai dokumen teknis kurang yang merinci desain sistem dari sudut
pandang yang lebih fungsional (yaitu, merinci dengan tepat bagaimana setiap
fungsi sistem yang dibutuhkan akan diterapkan). Dokumen ini akan menentukan
kriteria keberhasilan dan kegagalan untuk setiap skenario dalam aplikasi.
Misalnya, check out pelanggan untuk aplikasi e-commerce akan menjadi kasus
penggunaan yang akan menghasilkan banyak langkah (seperti memverifikasi bahwa
pengguna masuk, memvalidasi alamat pengiriman, dan sebagainya), yang kesemuanya
akan didokumentasikan. secara terperinci. Jika pemangku kepentingan utama belum
menandatangani dokumen yang sesuai ini, kemungkinannya lebih besar bahwa output
dari proyek mungkin tidak sesuai dengan kebutuhan mereka.
Bagaimana
caranya? Cari dokumen desain rinci yang setara sebagai
bukti persetujuan pelanggan. Perhatikan bahwa personil nonteknis mungkin tidak
dalam posisi untuk memahami dokumen desain terperinci, tergantung pada
bagaimana penulisannya. Jika demikian, pastikan bahwa review desain kompensasi
atau katalog "use case" telah dikembangkan yang memungkinkan pemangku
kepentingan memahami elemen desain yang direncanakan.
19. Tinjau kembali proses untuk
memastikan keterlibatan pelanggan yang berkelanjutan dengan memprioritaskan
tugas pada proyek. Sebagian besar proyek mengalami fluiditas, dengan
persyaratan awal yang jarang berakhir sebagai persyaratan akhir. Jika pemangku
kepentingan utama tidak terlibat dalam keseluruhan proyek, proyek ini berisiko
tersesat dari persyaratan pelanggan, dan keputusan dapat dibuat yang tidak
sesuai dengan keinginan pelanggan.
Bagaimana
caranya? Tentukan
apakah kelompok pengaturan arah telah ditetapkan dan berisi kunci pelanggan dan
apakah mereka terlibat dalam keputusan proyek secara reguler. Menipu Sider
mewawancarai sejumlah kecil pelanggan untuk mendapatkan pendapat mereka
mengenai keterlibatan pelanggan. Carilah bukti pertemuan review proyek berkala
dan komunikasi berkala dengan pemangku kepentingan utama.
20. Carilah bukti peer review dalam
desain dan pengembangan. Disiplin kontrol kualitas ini, yang melibatkan
peninjauan kode dan konfigurasi oleh rekan-rekan pengembang, dapat membantu
meningkatkan peluang bahwa sistem akan dirancang dengan logika suara dan
minimal kesalahan.
Bagaimana
caranya? Tentukan
apakah peer review diperlukan oleh proses, dan mencari bukti bahwa mereka
benar-benar terjadi.
21. Pastikan pengendalian internal dan
keamanan yang tepat telah dirancang ke dalam sistem. Lihat langkah 15 untuk
informasi lebih lanjut.
Bagaimana
caranya? Validasi
(baik melalui wawancara atau ulasan desain) bahwa masukan yang Anda berikan
pada langkah 15 telah tercakup dalam perancangan sistem.
Pengujian
22. Pastikan desain dan pengujian sedang
terjadi di lingkungan pengembangan / uji dan tidak di lingkungan produksi.
Kegagalan dalam melakukan desain dan uji kerja di lingkungan yang berdedikasi
dapat mengakibatkan terganggunya kegiatan bisnis normal.
Bagaimana
caranya? Lihat bukti
bahwa lingkungan yang digunakan selama pengembangan dan pengujian terpisah dari
lingkungan yang digunakan untuk produksi. Melihat tata letak arsitektur, dan
memvalidasi segregasi lingkungan. Melihat anggota proyek masuk ke berbagai lingkungan,
dan memastikan bahwa server yang digunakan untuk desain, pengujian, dan
produksi sesuai dengan tata letak arsitektur. Juga, pastikan bahwa lingkungan
uji erat mencerminkan lingkungan produksi. Jika tidak, tes kode yang berhasil
di lingkungan pengujian mungkin bukan indikator bahwa kode tersebut akan
bekerja di lingkungan produksi atau akan terukur dengan beban produksi.
23. Tinjau dan mengevaluasi proses
pengujian. Pastikan bahwa proyek memiliki rencana uji yang memadai dan
mengikuti rencana uji ini. Menguji sistem, perangkat lunak, atau proses akan
memberikan kepastian bahwa ia bekerja sebagaimana mestinya.
Bagaimana
caranya? Kaji rencana
uji untuk beberapa elemen.
Pertama, tentukan apakah
rencana uji meliputi:
• Pengujian unit
Pengujian modul sistem individual atau unit atau kelompok unit terkait
• Pengujian integrasi
Pengujian beberapa modul atau unit untuk memastikannya bekerja sama dengan
benar
• Pengujian sistem
Pengujian keseluruhan sistem oleh tim pengembang
• Uji penerimaan
Pengujian yang dilakukan oleh pengguna akhir untuk memvalidasi bahwa sistem
memenuhi persyaratan dan dapat diterima
• Pengujian regresi
Retestasi area pilih untuk memastikan bahwa perubahan yang dilakukan pada satu
bagian sistem tidak menyebabkan masalah pada bagian lain sistem.
Kemudian tinjau
rencananya berikut ini:
• Pastikan bahwa rencana
uji dan prosedur dan uji kasus yang terkait dapat diulang sehingga dapat
digunakan untuk pengujian regresi dan untuk rilis di masa mendatang.
• Pastikan bahwa rencana
dan kasus uji coba dilakukan melalui peer review untuk memastikan kualitas.
• Tentukan apakah
rencana pengujian mencakup pengujian data yang buruk / tidak benar, penanganan
kesalahan sistem, dan pemulihan sistem.
• Tentukan apakah
rencana pengujian mencakup pengujian keamanan dan pengendalian internal.
• Pastikan hasil
pengujian didokumentasikan secara lengkap.
• Pastikan bahwa
kesenjangan yang diidentifikasi selama pengujian didokumentasikan, dilacak,
dipecahkan, dan diuji ulang. Pastikan proses gap/bug-tracking disetujui di
depan. Proses ini perlu disederhanakan dan sistem perubahan terkontrol
terbentuk dengan cepat, atau bisa menjadi berantakan, dengan kode ditarik masuk
dan keluar dari produksi sembarangan.
• Pastikan tim proyek
telah menyetujui metrik yang akan ditangkap dan dilaporkan selama pengujian dan
bahwa metrik ini dilaporkan secara tepat waktu kepada anggota kepemimpinan
proyek yang sesuai.
• Pastikan bahwa rencana
pengujian mencakup pengujian persyaratan kinerja dan ambang batas.
• Pastikan setiap kasus
uji mengidentifikasi produk, komponen, atau modul yang sedang diuji.
• Evaluasi proses untuk
memastikan bahwa semua fungsi utama diuji dan semua jalur logika kunci
diidentifikasi dan diuji. Jika katalog use case digunakan, evaluasi proses
untuk memastikan semua elemen dari semua kasus penggunaan diuji.
• Pastikan data uji
telah dibuat dan pelanggan setuju bahwa data uji valid.
• Tentukan apakah
langkah-langkah uji menentukan hasil yang diharapkan dan kriteria penerimaan
pelanggan.
• Pastikan semua tugas
tes diidentifikasi dan ditetapkan sebagai pemilik dan bahwa "siapa, kapan,
dan kapan" pengujian telah diidentifikasi dengan jelas untuk semua pihak
yang terlibat.
• Pastikan bahwa tanda
tangan yang sesuai telah diperoleh untuk rencana tersebut.
• Tentukan apakah
rencana uji mencantumkan urutan di mana langkah-langkah uji harus dilakukan.
• Pastikan bahwa
perencanaan pengujian mencakup identifikasi dan rencana untuk mendapatkan
perangkat keras dan perangkat lunak yang diperlukan untuk pengujian.
• Jika menggunakan
kombinasi perangkat lunak vendor dan kode yang dikembangkan secara internal,
tentukan apakah sebuah proses telah ditetapkan untuk memastikan kode kedua
belah pihak akan digabungkan dengan cara yang terkoordinasi dengan baik.
24. Pastikan semua persyaratan dapat
dipetakan ke dalam kasus uji. Proses yang didefinisikan untuk melacak
persyaratan ke rencana uji akan memberikan kepastian bahwa semua persyaratan
ditangani dan diuji.
Bagaimana
caranya? Jika ada
daftar jejak persyaratan, tinjau dan verifikasi bahwa semua persyaratan
diwakili dan dipetakan ke kasus uji. Jika peta jejak tidak ada, tinjau proses
untuk memastikan bahwa semua persyaratan diuji.
25. Pastikan pengguna terlibat dalam
pengujian dan setujui bahwa sistem tersebut memenuhi persyaratan. Ini harus
mencakup personil TI yang akan mendukung sistem dan personil TI yang terlibat
dalam melakukan studi kelayakan teknis awal untuk proyek tersebut. Sistem,
perangkat lunak, atau proses sedang dikembangkan untuk memenuhi kebutuhan
bisnis yang spesifik. Proyek ini tidak bisa sukses jika pemangku kepentingan
utama tidak puas. Oleh karena itu, mereka harus dilibatkan dalam pengujian dan
harus menandatangani sistem sebelum melakukan implementasi. Selain itu, seperti
yang disebutkan pada langkah 13, beberapa organisasi di lingkungan TI biasanya
akan terlibat dalam mendukung sistem baru, termasuk dukungan jaringan, dukungan
sistem operasi, dukungan basis data, personil pusat data, keamanan TI, dan meja
bantuan. Jika organisasi-organisasi ini tidak dilibatkan dalam pengujian dan
penghentian sistem, mereka mungkin tidak siap untuk mendukungnya, dan / atau
sistem mungkin tidak sesuai dengan standar dan kebijakan yang berlaku.
Bagaimana
caranya? Cari bukti pengujian penerimaan pengguna.
Pastikan pemegang saha, utama yang terlibat dalam meminta dan menyetujui proyek
dan dalam menentukan persyaratan sistem (termasuk organisasi TI yang terkena
dampak) juga terlibat dalam pengujian proyek dan sign-off.
26. Pertimbangkan untuk berpartisipasi
dalam pengujian penerimaan pengguna dan memvalidasi bahwa keamanan sistem dan
pengendalian internal berfungsi sebagaimana mestinya. Hal ini diperlukan untuk
alasan yang sama yang diuraikan pada langkah 15. Dengan berpartisipasi dalam
pengujian, Anda dapat memvalidasi kontrol ini secara independen.
Bagaimana
caranya? Selama
langkah awal, Anda seharusnya sudah bekerja dengan tim proyek untuk
mengidentifikasi pengendalian internal yang harus dibangun di dalam sistem,
perangkat lunak, atau proses. Tinjau kembali rencana pengujian untuk memastikan
pengujian tersebut mencakup pengujian terhadap kontrol internal tersebut.
Berpartisipasi sebagai tester penerimaan dari kasus uji tersebut.
Implementasi
27. Pastikan bahwa ada proses yang
efektif untuk mencatat, melacak, meningkatkan, dan menyelesaikan masalah yang
timbul setelah implementasi. Masalah yang tidak terduga muncul setelah
implementasi hampir semua sistem baru. Tanpa metode yang kuat untuk menangkap
dan menyelesaikan masalah tersebut, masalah dapat "lolos dari celah"
dan tidak dapat diselesaikan secara tepat waktu. Juga diperlukan sistem pelacak
masalah untuk memastikan bahwa isu diprioritaskan dan diperbaiki sesuai dengan
kepentingannya.
Bagaimana
caranya? Tinjau ulang
database masalah, menerbitkan spreadsheet, atau metode lain yang telah
ditetapkan untuk merekam dan melacak masalah pasca implementasi. Pastikan alat
yang mengeluarkan catatan mencatat informasi yang memadai mengenai setiap
masalah, termasuk deskripsi masalah, tingkat prioritas, tanggal jatuh tempo,
status terbaru, dan informasi resolusi. Pastikan kontrol ada di atas alat yang
digunakan untuk melacak masalah, seperti backup dan keamanan untuk mencegah
pembaruan yang tidak sah. Tinjau ulang proses untuk mengatasi masalah dan untuk
memastikan bahwa isu dilacak ke resolusi. Tinjau daftar masalah untuk bukti
bahwa masalah sedang ditutup. Wawancara pelanggan untuk memastikan prosesnya
berjalan.
28. Tinjau dan mengevaluasi rencana
konversi proyek. Pastikan bahwa proyek memiliki rencana konversi yang memadai
dan mengikuti rencana ini. Jika proyek yang ditinjau melibatkan penggantian
sistem yang ada, pada titik tertentu, pengguna akan beralih ke sistem yang
baru. Sangat penting bahwa data yang ada berhasil dikonversi ke sistem baru
sebelum waktu ini untuk memastikan transisi yang mulus.
Bagaimana
caranya? Tinjau
rencana konversi, dan mencari elemen seperti berikut ini:
• Pastikan semua data
penting diidentifikasi dan dipertimbangkan untuk konversi.
• Mengkaji ulang kontrol
untuk memastikan bahwa semua data dikonversi sepenuhnya dan akurat. Contoh
mekanisme kontrol semacam itu bisa jadi kontrol totalbidang kunci, catatan, dan
prosedur rekonsiliasi pengguna.
• Tentukan apakah semua
program konversi diuji sepenuhnya dengan keterlibatan pengguna dan hasil tes
didokumentasikan.
• Jika data historis
tidak dikonversi, pastikan metode dikembangkan untuk mengakses data jika
diperlukan. Misalnya, jika data keuangan dilibatkan, data keuangan historis
mungkin diperlukan di masa depan untuk pelaporan pajak.
• Meninjau dan
mengevaluasi rencana pemrosesan paralel atau metode fallback lainnya jika
terjadi kesulitan dalam transisi ke sistem yang baru.
• Pastikan bahwa proses
konversi mencakup penetapan data yang tidak digunakan dalam sistem warisan.
Misalnya, catatan di sistem baru mungkin berisi bidang yang tidak terdapat
dalam catatan serupa tentang sistem warisan. Pertimbangan harus diberikan untuk
mengisi bidang baru ini.
• Meninjau dan
mengevaluasi rencana untuk "akhir pekan konversi." Rencana terperinci
harus berisi kriteria dan pos pemeriksaan untuk membuat keputusan "go /
no-go".
29. Tinjau kembali rencana untuk mengubah
dukungan sistem atau perangkat lunak baru dari tim proyek ke tim dukungan
operasional. Setelah proyek selesai, kemungkinan personil proyek akan
dipindah-tangankan ke proyek lain. Oleh karena itu penting untuk menjalankan /
mempertahankan personil pendukung agar dilatih dengan benar dalam
fungsionalitas sistem sehingga mereka siap untuk mendukungnya saat pengguna
mengidentifikasi masalah atau meminta penyempurnaan. Ini adalah salah satu
elemen proyek yang paling sering diabaikan.
Bagaimana
caranya? Lakukan wawancara atau peninjauan
dokumentasi, cari bukti bahwa personil pendukung telah diidentifikasi, terlibat
secara memadai dalam proyek, dan dilatih secara tepat terhadap sistem dan
fungsinya.
30. Pastikan dokumentasi yang memadai
telah dibuat untuk penggunaan sistem atau proses yang sedang dikembangkan dan
pemeliharaan sistem atau perangkat lunak. Evaluasi proses agar dokumentasi
tetap up-to-date. Evaluasi kontrol dan keamanan perubahan atas dokumentasi itu.
Dokumentasi teknis dan pengguna yang tidak lengkap atau ketinggalan jaman dapat
meningkatkan biaya dan waktu siklus untuk mempertahankan perangkat lunak,
meningkatkan biaya dukungan dan pelatihan, dan membatasi kegunaan sistem,
proses, atau perangkat lunak kepada pelanggan.
Bagaimana
caranya? Dapatkan salinan dokumentasi yang ada, dan
mengevaluasi kecukupannya. Carilah bukti yang akan menunjukkan bahwa
dokumentasi telah diperbarui saat sistem telah berubah, dan meninjau proses
untuk memastikan pemeliharaan dokumentasi yang sedang berlangsung. Pastikan
file yang berisi dokumentasi dikunci dan hanya dapat diubah oleh personil yang
tepat. Wawancara personil yang tepat untuk memahami proses perubahan dokumen
kritis. Pastikan proses persetujuan diperlukan sebelum perubahan dilakukan
terhadap dokumen penting dan bahwa proses persetujuan tidak dapat dielakkan.
Pelatihan :
31. Tinjau kembali rencana untuk
memastikan bahwa semua pengguna yang terkena dampak dilatih dalam penggunaan
sistem, perangkat lunak, atau proses yang baru. Pelatihan merupakan elemen
penting untuk mempersiapkan pengguna akhir mengenai fungsionalitas dan nuansa
sistem yang baru dikembangkan. Jika pelatihan tidak diberikan atau tidak
memadai, sistem, perangkat lunak, atau proses baru kemungkinan akan
disalahgunakan, digunakan secara tidak efektif, atau dihindari.
Bagaimana
caranya? Tinjau
rencana pelatihan dan mewawancarai pengguna untuk mengembangkan opini tentang
kecukupannya. Bandingkan daftar penerima pelatihan yang direncanakan dengan
populasi pengguna akhir untuk memastikan tidak ada kesenjangan yang signifikan.
32. Pastikan bahwa proses telah dilakukan
untuk menjaga materi pelatihan tetap up-to-date. Evaluasi kontrol perubahan dan
keamanan materi pelatihan. Karena karyawan baru dan pengguna baru perlu
menggunakan sistem ini, mereka ingin memanfaatkan materi pelatihan tersebut.
Jika materi pelatihan ini sudah usang (misalnya, karena perubahan sistem),
efektivitas materi pelatihan akan terbatas.
Bagaimana
caranya? Cari bukti yang menunjukkan bahwa pelatihan
telah diperbarui saat sistem telah berubah, dan meninjau proses untuk
memastikan pemeliharaan dokumentasi yang sedang berlangsung. Pastikan file yang
berisi dokumentasi dikunci dan hanya dapat dimodifikasi oleh personil yang
tepat. Wawancara personil yang tepat untuk memahami proses perubahan dokumen
kritis. Pastikan proses persetujuan diperlukan sebelum perubahan dilakukan
terhadap dokumen penting dan bahwa proses persetujuan tidak dapat dielakkan.
Wrap-up
Proyek :
33. Pastikan sebuah proses ada untuk
menutup proyek dan mencatat pelajaran yang dipetik dan bahwa prosesnya diikuti.
Dokumentasi proyek akhir dan pelajaran terekam dapat digunakan untuk membantu
efektivitas dan efisiensi proyek perusahaan masa depan. Langkah ini sering tidak
terjawab, karena tim proyek dengan cepat beralih ke tugas lain setelah sukses
diimplementasikan.
Bagaimana
caranya? Tinjau
dokumentasi proyek, dan memastikan bahwa semua dokumen yang relevan telah
selesai dan telah ditetapkan sebelumnya. Carilah bukti bahwa daftar akhir
pelajaran yang dipetik dari proyek telah didokumentasikan.
Sumber:
Davis, Chris. Schiller, Mike. Wheeler, Kevin. 2011. IT Auditing: Using Controls to Protect Information Assets Second Edition. New York. The McGraw-Hill Companies.
