UNIVERSITAS INDONESIA

Transkripsi

1 UNIVERSITAS INDONESIA PERANCANGAN KERANGKA PENILAIAN KAPASITAS PENYEDIA JASA KONSULTANSI PERANGKAT LUNAK YANG MENGACU PADA CMMI-DEV : STUDI KASUS KEMENTERIAN SEKRETARIAT NEGARA KARYA AKHIR Diajukan sebagai salah satu syarat untuk memperoleh gelar Magister Teknologi Informasi HERU MARTIN SAPUTRA FAKULTAS ILMU KOMPUTER PROGRAM STUDI MAGISTER TEKNOLOGI INFORMASI JAKARTA JANUARI 2014 i

2 HALAMAN PERNYATAAN ORISINALITAS Karya Akhir ini adalah hasil karya saya sendiri, dan semua sumber baik yang dikutip maupun dirujuk telah saya nyatakan dengan benar. Nama : Heru Martin Saputra NPM : Tanda tangan : Tanggal : 17 Januari 2014 ii

3 HALAMAN PENGESAHAN Karya Akhir ini diajukan oleh : Nama : Heru Martin Saputra NPM : Program Studi : Magister Teknologi Informasi Judul Karya Akhir : Perancangan Kerangka Penilaian Kapasitas Penyedia Jasa Konsultansi Perangkat Lunak yang Mengacu pada CMMI-Dev : Studi Kasus Kementerian Sekretariat Negara Telah berhasil dipertahankan di hadapan Dewan Penguji dan diterima sebagai bagian persyaratan yang diperlukan untuk memperoleh gelar Magister Teknologi Informasi pada Program Studi Magister Teknologi Informasi, Fakultas Ilmu Komputer,. DEWAN PENGUJI Pembimbing : Alex Ferdinansyah M.Kom. (......) Penguji : Dr. Eko K. Budiardjo (......) Penguji : Yudho Giri Sucahyo, Ph.D. (......) Ditetapkan di : Jakarta Tanggal : iii iii

4 KATA PENGANTAR Segala puji dan syukur penulis panjatkan kehadirat Allah SWT, yang telah melimpahkan rahmat, taufik, nikmat, dan hidayah-nya, sehingga Karya Akhir ini dapat penulis selesaikan. Penulisan Karya Akhir ini dilakukan dalam rangka memenuhi salah satu syarat untuk mencapai gelar Magiter Teknologi Informasi pada Program Studi Magister Teknologi Informasi, Fakultas Ilmu Komputer,. Penulis menyadari bahwa, bantuan dan bimbingan dari berbagai pihak, dari masa perkuliahan sampai pada penyusunan karya akhir ini, sangat berarti bagi penulis dalam menyelesaikan karya akhir ini. Dalam kesempatan yang baik ini penulis ingin menyampaikan penghargaan yang setinggi-tingginya dan terima kasih yang sedalam-dalamnya kepada semua pihak yang telah memberikan perhatian, dukungan, dan bantuannya dalam penyelesaian karya akhir ini, diantaranya adalah: 1. Bapak Alex Ferdinansyah M.Kom. selaku dosen pembimbing yang telah menyediakan waktu, tenaga, dan pikiran untuk mengarahkan penulis dalam penyusunan karya akhir ini. 2. Bapak Dr. Eko K. Budiardjo dan Bapak Yudho Giri Sucahyo, Ph.D. selaku dosen penguji yang telah memberikan masukan, saran, dan kritikan demi penyempurnaan karya akhir ini. 3. Seluruh Dosen MTI, yang telah memberikan pembelajaran, bimbingan, dan pencerahan yang sangat bermanfaat bagi penulis dalam meningkatkan wawasan keilmuan dan kualitas kepribadian. 4. Bapak Dr. Drs. Cecep Sutiawan, M.Si., Deputi Bidang Sumber Daya Manusia Kementerian Sekretariat Negara, yang telah memberikan kesempatan dan motivasi dalam menyelesaikan tugas belajar ini. 5. Kementerian Komunikasi dan Informatika RI sebagai instansi pemberi beasiswa Government Chief Information Officer (GCIO). 6. Pihak-pihak yang secara langsung maupun tidak langsung terlibat dalam pembuatan Karya Akhir ini, yaitu Bapak Drs. Harly Agung Prabowo, M.Si. iv

5 selaku Kepala Biro Administrasi Pejabat Negara, dan Bapak Andrie Syahriza, S.Kom., M.Si. selaku Asisten Deputi Dukungan Data Kebijakan dan Informatika. 7. Bapak dan Ibu, orang tua tercinta, yang selalu mendoakan, memberikan dukungan, bimbingan, nasihat, serta menjadi suri tauladan yang baik. 8. Istri tercinta dan buah hati tersayang, yang telah menjadi semangat bagi penulis dalam menjalani pendidikan ini. 9. Adik-adik penulis atas dukungan dan doanya. 10. Seluruh Pejabat dan Pegawai di Asisten Deputi Dukungan Data Kebijakan dan Informatika, PT. Belant Persada, PT. Malloci Software Solution, dan CV. Torche Indonesia yang telah memberikan data dan informasi yang sangat berguna untuk kesempurnaan karya akhir ini. 11. Seluruh Pejabat dan Pegawai di Biro Administrasi Pejabat Negara yang telah memberikan dukungannya. 12. Bapak dan Ibu di Sekretariat MTI untuk pelayanan yang diberikan selama penulis belajar di MTI. 13. Seluruh sahabat di kelas 2012SA yang telah menjadi bagian dari perjalanan perjuangan dalam menempuh pendidikan dan pembelajaran di MTI UI. 14. Semua pihak yang telah berkenan membantu dalam penyelesaian karya akhir yang tidak dapat penulis sebutkan, semoga Allah SWT membalas semua kebaikan kalian. Jakarta, 17 Januari 2014 Penulis v

6 HALAMAN PERNYATAAN PERSETUJUAN PUBLIKASI KARYA AKHIR UNTUK KEPENTINGAN AKADEMIS Sebagai sivitas akademik, saya yang bertanda tangan di bawah ini: Nama : Heru Martin Saputra NPM : Program Studi : Magister Teknologi Informasi Fakultas : Ilmu Komputer Jenis Karya : Karya Akhir Demi pengembangan ilmu pengetahuan, menyetujui untuk memberikan kepada Hak Bebas Royalti Nonekslusif (Non-exclusive Royalty- Free Right) atas karya ilmiah saya yang berjudul : Perancangan Kerangka Penilaian Kapasitas Penyedia Jasa Konsultansi Perangkat Lunak yang Mengacu pada CMMI-Dev : Studi Kasus Kementerian Sekretariat Negara Beserta perangkat yang ada (jika diperlukan). Dengan Hak Bebas Royalti Nonekskutif ini berhak menyimpan, mengalihmedia/formatkan, mengelola dalam bentuk pangkalan data (database). Merawat, dan mempublikasikan karya akhir saya tanpa meminta izin dari saya selama tetap mencantumkan saya sebagai penulis/pencipta dan sebagai pemilik Hak Cipta. Demikian pernyataan ini saya buat dengan sebenarnya. Dibuat di : Jakarta Pada tanggal : 17 Januari 2014 Yang menyatakan ( Heru Martin Saputra ) vi

7 ABSTRAK Nama : Heru Martin Saputra Program Studi : Magister Teknologi Informasi Judul : Perancangan Kerangka Penilaian Kapasitas Penyedia Jasa Konsultansi Perangkat Lunak yang Mengacu pada CMMI-Dev : Studi Kasus Kementerian Sekretariat Negara Teknologi informasi (TI) telah menjadi bagian strategi bagi Kementerian Sekretariat Negara dalam rangka meningkatkan pelayanan dan kinerja. Hal ini dituangkan pada beberapa Peraturan Menteri Sekretaris Negara sebagai kebijakan dari organisasi yang ingin mengoptimalkan kinerja dengan dukungan TI di lingkungan Kementerian Sekretariat Negara. Perangkat lunak pun dibangun dan dikembangkan dalam menunjang kegiatan dari unit-unit kerja yang ada. Pengembangan dilakukan melalui lelang atau swakelola. Terlibatnya pihak luar dalam pengembangan perangkat lunak melalui lelang memerlukan pengawasan dan kontrol, karena kadang terjadi masalah dalam pengembangan perangkat lunak, seperti gagal dalam membangun atau pembangunan terlambat (tidak sesuai jadwal). Dalam rangka mendapatkan penyedia yang lebih berkualitas maka dilakukan kajian penilaian kapasitas penyedia perangkat lunak. Penilaian kapasitas dari penyedia dilakukan untuk mengetahui kualitas dari penyedia sehingga dapat mengurangi kesalahan atau kelemahan yang sering terjadi pada pengembangan melalui lelang. Capability Maturity Model Integration for Development (CMMI-DEV) representasi Continuous dan Standard CMMI Appraisal Method for Process Improvement (SCAMPI) digunakan sebagai bahan dalam merancang kerangka penilaian kapasitas penyedia. Rancangan kerangka penilaian kapasitas penyedia digunakan untuk dua hal, yaitu untuk menilai kapasitas peserta lelang sebagai calon penyedia, dan menilai penyedia pada saat pemeriksaan pekerjaan. Dengan adanya rancangan kerangka penilaian kapasitas penyedia diharapkan dapat memilih penyedia yang lebih baik lagi, dan sebagai pembelajaran bagi tenaga teknis di Unit Kerja TI Kementerian Sekretariat Negara dalam mengembangkan perangkat lunak secara swakelola. Kata kunci : Kerangka Penilaian, CMMI-DEV, SCAMPI, model, tingkat kapasitas, area proses, specific practice, generic practice xvi halaman; 7 gambar; 40 tabel; 6 lampiran vii

8 ABSTRACT Name : Heru Martin Saputra Study program : Master of Information Technology Title : Framework Designing of Capacity Assessment for Software Consultancy Provider Referring to CMMI-Dev: A Case Study in the Ministry of State Secretariat Information technology ( IT ) has become a part of the strategy of the Ministry of State Secretariat in order to improve its services and performance. This matter is stated in some of the Regulations of the Ministry of State Secretary as the policies of the organization who wants to optimize the performance of the IT support at the Ministry of State Secretariat. The software is built and developed to support the activities of the available working units. The development process is performed through an auction or a self-management. The involvement of external parties in the development of software through an auction requires supervision and control, because sometimes there are problems in software development, such as building failure or late construction (behind schedule). In order to get a higher quality provider, then a capacity assessment study on software provider should be conducted. Assessment of the capacity of providers is conducted to know the quality of providers so that the errors or weaknesses that frequently occur in the development process through auction could be minimized. Capability Maturity Model Integration for Development (CMMI-DEV) Continuous representation and Standard CMMI Appraisal Method for Process Improvement (SCAMPI) are used as the materials in designing a framework for assessing the capacity of providers. The framework design of provider capacity assessment is used for two objectives, namely to assess the capacity of the prospective bidders as the candidates of the future providers, and to assess the provider when examining the work performed. With the framework design of provider capacity assessment, it is expected that a better provider can be chosen, and it is also expected that the technical personnel in the IT Work Unit of the Ministry of State Secretariat will be able to learn how to develop software by a self-management. Keywords : Assessment Framework, CMMI-DEV, SCAMPI, the model, the level of capacity, process areas, specific practices, generic practice xvi pages; 7 images; 40 tables; 6 attachments viii

9 DAFTAR ISI HALAMAN JUDUL...i HALAMAN PERNYATAAN ORISINALITAS... ii HALAMAN PENGESAHAN... iii KATA PENGANTAR... iv HALAMAN PERNYATAAN PERSETUJUAN PUBLIKASI... vi ABSTRAK... vii ABSTRACT... viii DAFTAR ISI... ix DAFTAR TABEL... xiii DAFTAR GAMBAR... xv DAFTAR LAMPIRAN... xvi BAB 1 PENDAHULUAN Latar Belakang Perumusan Masalah Tujuan Manfaat Penelitian Ruang Lingkup Penelitian... 8 BAB 2 KAJIAN PUSTAKA Rekayasa Perangkat Lunak Manajemen Proyek TI CMMI-DEV Process Area Representasi Continuous Hubungan Antara Area Proses Standard CMMI Appraisal Method for Process Improvement Kerangka Standar Kompetensi Berbasis Kinerja dari GAPPS Projects in a Controlled Environment PMBOK Guide Perbandingan Manajemen Proyek Penelitian Sebelumnya Theoretical Framework ix

10 BAB 3 METODOLOGI PENELITIAN Tahapan Penelitian Metode Pengumpulan Data Metode Analisis Data BAB 4 PROFILE ORGANISASI Kementerian Sekretariat Negara Kedudukan, Tugas dan Fungsi Kementerian Sekretariat Negara Struktur Organisasi Kementerian Sekretariat Negara PT. Belant Persada PT. Malloci Software Solution Produk Layanan CV. Torche Indonesia BAB 5 ANALISA DAN PEMBAHASAN Pemilihan Proyek Pemilihan Representasi CMMI Pemilihan Area Proses Proses Penilaian SCAMPI C Plan and Prepare for Appraisal Conduct Appraisal Report Results Hasil Penilaian Penyedia Penilaian REQM Penyedia REQM Capability Level 1 Penyedia REQM Capability Level 2 Penyedia Penilaian PP Penyedia PP Capability Level 1 Penyedia PP Capability Level 2 Penyedia Penilaian PMC Penyedia PMC Capability Level 1 Penyedia PMC Capability Level 2 Penyedia x

11 5.5.4 Penilaian SAM Penyedia Hasil Penilaian Penyedia Penilaian REQM Penyedia REQM Capability Level 1 Penyedia REQM Capability Level Level 2 Penyedia Penilaian PP Penyedia PP Capability Level 1 Penyedia PP Capability Level 2 Penyedia Penilaian PMC Penyedia PMC Capability Level 1 Penyedia PMC Capability Level 2 Penyedia Penilaian SAM Penyedia Hasil Penilaian Penyedia Penilaian REQM Penyedia REQM Capability Level 1 Penyedia REQM Capability Level 2 Penyedia Penilaian PP Penyedia PP Capability Level 1 Penyedia PP Capability Level 2 Penyedia Penilaian PMC Penyedia PMC Capability Level 1 Penyedia PMC Capability Level 2 Penyedia Penilaian SAM Penyedia Profil Capability Level Verifikasi Kebutuhan Penilaian Analisis Hubungan Masalah, Hasil Penilaian, dan Hasil Verifikasi Keterhubungan Data Dalam REQM Keterhubungan Data Dalam PP Keterhubungan Data Dalam PMC Keterhubungan Data Dalam SAM Penyusunan dan Validasi Kerangka Penilaian Kapasitas Penyedia xi

12 5.12 Rekomendasi Kerangka Penilaian Kapasitas Penyedia BAB 6 KESIMPULAN DAN SARAN DAFTAR PUSTAKA xii

13 DAFTAR TABEL Tabel 1.1 Kebutuhan Pendanaan Sistem Informasi... 2 Tabel 2.1 Unit Kompetensi Tabel 2.2 Penelitian Sebelumnya Tabel 5.1 Skala Karakter Penilaian Tabel 5.2 Persiapan Penilaian Proyek Tabel 5.3 Persiapan Penilaian Proyek Tabel 5.4 Persiapan Penilaian Proyek Tabel 5.5 Rencana Penilaian Tabel 5.6 Daftar Dokumen Tabel 5.7 Penilaian REQM CL 1 Penyedia Tabel 5.8 Penilaian REQM CL 2 Penyedia Tabel 5.9 Penilaian PP CL 1 Penyedia Tabel 5.10 Penilaian PP CL 2 Penyedia Tabel 5.11 Penilaian PMC CL 1 Penyedia Tabel 5.12 Penilaian PMC CL 2 Penyedia Tabel 5.13 Penilaian REQM CL 1 Penyedia Tabel 5.14 Penilaian REQM CL 2 Penyedia Tabel 5.15 Penilaian PP CL 1 Penyedia Tabel 5.16 Penilaian PP CL 2 Penyedia Tabel 5.17 Penilaian PMC CL 1 Penyedia Tabel 5.18 Penilaian PMC CL 2 Penyedia Tabel 5.19 Penilaian REQM CL 1 Penyedia Tabel 5.20 Penilaian REQM CL 2 Penyedia Tabel 5.21 Penilaian PP CL 1 Penyedia Tabel 5.22 Penilaian PP CL 2 Penyedia Tabel 5.23 Penilaian PMC CL 1 Penyedia Tabel 5.24 Penilaian PMC CL 2 Penyedia Tabel 5.25 Verifikasi REQM Tabel 5.26 Verifikasi PP Tabel 5.27 Verifikasi PMC Tabel 5.28 Verifikasi SAM xiii

14 Tabel 5.29 Data Masalah Tabel 5.30 Skala Karakter Rekomendasi Tabel 5.31 Keterhubungan Data Dalam REQM Tabel 5.32 Keterhubungan Data Dalam PP Tabel 5.33 Keterhubungan Data Dalam PMC Tabel 5.34 Keterhubungan Data Dalam SAM Tabel 6.1 Penilaian pada Area Proses REQM Tabel 6.2 Penilaian pada Area Proses PP Tabel 6.3 Penilaian pada Area Proses PMC xiv

15 DAFTAR GAMBAR Gambar 1.1 Fishbone Analysis... 4 Gambar 2.1 CMMI Model Components Gambar 2.2 Basic Project Management Process Areas Gambar 2.3 Theoretical Framework Gambar 3.1 Tahapan Penelitian Gambar 4.1 Struktur Organisasi Kementerian Sekretariat Negara Gambar 5.1 Profil Capability Level xv

16 DAFTAR LAMPIRAN Lampiran 1 Lampiran 2 Lampiran 3 Lampiran 4 Lampiran 5 Lampiran 6 : Wawancara : Administrasi : Keterangan Goals dan Practices dari Process Area : Rancangan Penilaian Kapasitas Penyedia : Rancangan Formulir Penilaian Kapasitas Penyedia : Rancangan Formulir Rangkuman Penilaian Kapasitas Penyedia xvi

17 BAB 1 PENDAHULUAN 1.1 Latar Belakang Berdasarkan Peraturan Presiden Republik Indonesia Nomor 58 Tahun 2010, Kementerian Sekretariat Negara berada di bawah dan bertanggung jawab kepada Presiden yang dipimpin oleh Menteri Sekretaris Negara. Kementerian Sekretariat Negara mempunyai tugas memberikan dukungan teknis dan administrasi serta analisis kepada Presiden dan Wakil Presiden dalam menyelenggarakan kekuasaan negara. Sebagai kementerian yang berada di bawah Presiden, Kementerian Sekretariat Negara memiliki tugas yang sangat vital. Karena dukungan teknis, administrasi, dan analisis dari Kementerian Sekretariat Negara akan langsung terhubung ke Presiden dan Wakil Presiden yang akan mempengaruhi kinerja Presiden dan Wakil Presiden. Dalam rangka memberikan pelayanan prima kepada Presiden dan Wakil Presiden, serta meningkatkan kualitas dan kapasitas kinerja, Kementerian Sekretariat Negara memanfaatkan sistem informasi/teknologi informasi (SI/TI) agar ketatalaksanaan organisasi dapat dilakukan dengan efektif dan efisien mengacu pada kebutuhan, skala prioritas, pengurangan duplikasi (tumpang tindih) kegiatan, serta perlunya pengendalian dan pengawasan kinerja organisasi. Pemanfaatan SI/TI menjadi penting bagi Kementerian Sekretariat Negara, ini dapat dilihat dimana SI/TI sudah dituangkan pada beberapa peraturan menteri. Pada Rencana Strategis (Renstra) yang tertuang dalam Peraturan Menteri Sekretaris Negara Nomor 2 Tahun 2010 tentang Rencana Strategis Sekretariat Negara Republik Indonesia tahun yang disempurnakan pada Peraturan Menteri Sekretaris Negara Nomor 7 Tahun 2011 tentang Penyempurnaan Rencana Strategis Kementerian Sekretariat Negara Republik Indonesia tahun , SI/TI menjadi salah satu program Renstra, yaitu program dukungan manajemen dan pelaksanaan tugas teknis lainnya Kementerian Sekretariat Negara dengan 1

18 2 salah satu outcome-nya meningkatnya kualitas analisis dan kecepatan dalam memberikan dukungan informatika. Pada tabel 1.1 dapat dilihat anggaran yang dialokasikan untuk penerapan dan pengembangan sistem informasi di Kementerian Sekretariat Negara dari tahun 2010 sampai Anggaran tersebut merupakan investasi pada bidang sistem informasi dalam rangka meningkatkan kualitas analisis dan kecepatan dalam memberikan dukungan informatika. Dengan anggaran tersebut diharapkan dapat mewujudkan ketersediaan sistem aplikasi, layanan infrastruktur jaringan dan layanan data dan informasi dukungan kebijakan yang dapat memaksimalkan kinerja Kementerian Sekretariat Negara. Tabel 1.1 Kebutuhan Pendanaan Sistem Informasi Tahun Anggaran Anggaran (Rp) Sumber : Peraturan Menteri Sekretaris Negara Republik Indonesia Nomor 7 Tahun 2011 Peraturan Menteri Sekretaris Negara Republik Indonesia Nomor 9 Tahun 2011 tentang Road Map Reformasi Birokrasi Kementerian Sekretariat Negara Republik Indonesia tahun , selain memaparkan capaian Reformasi Birokrasi gelombang I Tahun pada Bidang Sistem Informasi Manajemen juga mencantumkan rencana program Reformasi Birokrasi gelombang II yang menargetkan peningkatan penggunaan Teknologi Informasi (TI) dalam proses penyelenggaraan manajemen pemerintahan di Kementerian Sekretariat Negara dengan kegiatan pembangunan proses manajemen pemerintahan menggunakan TI. Dan pada Peraturan Menteri Sekretaris Negara Nomor 14 Tahun 2011 tentang Grand Design Pengembangan E-Governtment (Pengembangan Sistem Informasi) Kementerian Sekretariat Negara tahun , ditetapkan visi pengembangan

19 3 Sistem Informasi Kementerian Sekretariat Negara (SIKSN) untuk tahun adalah: Tersedianya dukungan data dan informasi serta ketatalaksanaan berbasis TIK yang terintegrasi dalam rangka memujudkan layanan teknis dan administrasi yang prima kepada Presiden dan Wakil Presiden. Tiga kebijakan yang ada diharapkan dapat menguatkan dan memperjelas arah implementasi dan pengembangan SI/TI di Kementerian Sekretariat Negara yang saat ini bukan saja menjadi pendukung proses bisnis unit-unit kerja tetapi diharapkan menjadi bagian dari proses bisnis pada unit-unit kerja yang membutuhkannya. Berdasarkan hasil rapat-rapat koordinasi aplikasi pada tahun 2011 antara unit-unit kerja di Kementerian Sekretariat Negara yang mengajukan dukungan SI dengan Asisten Deputi Dukungan Data Kebijakan dan Informatika (unit kerja pengelola TI di Kementerian Sekretariat Negara), disimpulkan 9 (sembilan) unit kerja mengajukan dukungan SI untuk mendukung proses bisnisnya dengan jumlah pengajuan sebanyak 16 (enam belas) aplikasi. Adanya semangat dari unit-unit kerja yang ingin mengimplementasikan SI harus segera ditindaklanjuti oleh unit kerja TI untuk menjaga gairah penerapan SI yang memang membutuhkan kecepatan dan ketepatan. 1.2 Perumusan Masalah Berdasarkan Peraturan Menteri Sekretaris Negara Republik Indonesia Nomor 7 Tahun 2011, Peraturan Menteri Sekretaris Negara Republik Indonesia Nomor 9 Tahun 2011, dan Peraturan Menteri Sekretaris Negara Republik Indonesia Nomor 14 Tahun 2011 serta observasi dari penulis, dapat diketahui sejak tahun 2010 Kementerian Sekretariat Negara memiliki rencana pengembangan 18 (delapan belas) perangkat lunak. Saat ini 6 (enam) perangkat lunak yang sudah terimplementasi, 5 (lima) perangkat lunak masih proses pembangunan, dan 7 (tujuh) perangkat lunak belum dilaksanakan. Belum terimplementasinya perangkat lunak yang sudah direncanakan tentu akan menjadi masalah, bahkan untuk pengembangan yang dilakukan melalui proses lelang apabila gagal dikembangkan akan berdampak pada penundaan pengembangan atau hilang pada perencanaan pengembangan pada tahun berikutnya. Walaupun ini memiliki solusi dengan pengalihan pengembangan menjadi swakelola, namun bertambahnya

20 4 antrian pengembangan dengan swakelola akan menyebabkan penundaan implementasi program dalam waktu yang cukup lama. Dari masalah pengembangan perangkat lunak yang merujuk pada kebijakankebijakan yang ada, dan kebutuhan-kebutuhan dukungan perangkat lunak yang terus muncul menjadi bahan evaluasi dalam strategi peningkatan kualitas proses pengembangan perangkat lunak di Kementerian Sekretariat Negara kedepannya. Berdasarkan observasi penulis dan wawancara kepada pejabat dan tenaga teknis unit kerja TI di Kementerian Sekretariat Negara, ada beberapa hal yang menjadi kendala sehingga belum terimplementasinya perangkat lunak yang sudah direncanakan. Kendala-kendala yang ada tergambar pada gambar 1.1 tentang Fishbone Analysis dari belum terimplementasi perangkat lunak yang sudah direncanakan. Gambar 1.1 Fishbone Analysis

21 5 Dari gambar fishbone analysis di atas dapat dilihat 3 (tiga) kelompok kendala yang membuat belum terimplementasinya perangkat lunak yang sudah direncanakan. Berikut penjabaran kendala-kendala yang ada: A. Pengguna Berdasarkan hasil wawancara, pemahaman pengguna terhadap kebutuhannya menjadi permasalahan dalam pengembangan perangkat lunak. Pengguna yang tidak paham terhadap kebutuhannya akan menyebabkan scope perkerjaan menjadi berubah-ubah, sehingga mempengaruhi waktu pengerjaan menjadi bertambah panjang. Terlebih apabila pengembangan dilakukan melalui pelelangan, dimana waktu dan biaya tidak dapat berubah (wawancara dengan Asisten Deputi Dukungan Data Kebijakan dan Informatika pada tanggal 13 Agustus 2013). Untuk itu dibutuhkan diskusi yang lebih terhadap pengguna untuk lebih memahami kebutuhannya, karena hal ini juga terkait dengan kesiapan pengguna dalam mengimplementasi perangkat lunak tersebut. Implementasi perangkat lunak akan merubah pola kerja pengguna, selama ini yang dilakukan secara manual akan berubah dengan lebih banyak berinteraksi dengan komputer. Ada sebagian pengguna yang belum siap, sehingga membutuhkan waktu yang lebih lama dalam menggunakan aplikasi tersebut (wawancara dengan Kepala Bidang Pengembangan Sistem pada tanggal 13 Agustus 2013). B. Swakelola Pengembangan perangkat lunak di Kementerian Sekretariat Negara dilakukan dengan dua cara. Cara pertama dengan pelelangan, dimana pekerjaan akan dilelang, pengembangan perangkat lunak akan dilakukan oleh perusahaan luar yang terikat kontrak dengan Kementerian Sekretariat Negara. Dan yang kedua dengan swakelola, dimana pengembangan perangkat lunak akan dilakukan oleh pranata komputer Kementerian Sekretariat Negara. Dalam pengembangan perangkat lunak dengan swakelola terdapat beberapa kendala terkait implementasi perangkat lunak. Berdasarkan wawancara dan observasi, kegiatan pengembangan perangkat lunak secara swakelola saat ini belum terdokumentasi dengan baik. Dokumentasi dibutuhkan sebagai dasar dari pengembangan dan integrasi perangkat lunak kedepannya. Selain

22 6 dokumentasi, control dan monitoring terhadap pekerjaan swakelola dirasa masih kurang, karena hanya mengandalkan inisiatif dari tim swakelola untuk melaporkan perkembangannya kepada pengguna (wawancara dengan Pranata Komputer, 13 Agustus 2013). Untuk jumlah tenaga teknis, saat ini Asdep DDKI didukung 8 (delapan) pranata komputer sebagai tenaga ahli yang mengerjakan pengembangan perangkat lunak secara swakelola. Kemampuan pranata komputer yang ada tidak merata membutuhkan pembagian tugas sebaik mungkin (wawancara dengan Asisten Deputi Dukungan Data Kebijakan dan Informatika pada tanggal, 13 Agustus 2013). Sedangkan jumlah permintaan akan dukungan perangkat lunak terus bertambah tidak sebanding dengan jumlah pranata komputer yang melakukan pengembangan perangkat lunak. Dengan jumlah permintaan yang terus bertambah juga membuat pengerjaan menjadi tidak fokus. Karena kadang datang permintaan yang harus segera diselesaikan. Selain itu (wawancara Pranata Komputer pada tanggal 31 Agustus 2013). C. Pelelangan Berdasarkan Peraturan Presiden Nomor 70 Tahun 2012, pengadaan barang/jasa adalah kegiatan untuk memperoleh Barang/Jasa oleh Kementerian/Lembaga/Satuan Kerja Perangkat Daerah/Institusi yang prosesnya dimulai dari perencanaan kebutuhan sampai diselesaikannya seluruh kegiatan untuk memperoleh Barang/Jasa. Jasa pengembangan perangkat lunak masuk pada pengadaan jasa konsultansi, jasa konsultansi adalah jasa layanan profesional yang membutuhkan keahlian tertentu diberbagai bidang keilmuan yang mengutamakan adanya olah pikir (brainware). Keberhasilan pengembangan perangkat lunak dengan pelelangan sangat penting, karena kegagalan pengembangan perangkat lunak yag dilakukan melalui proses lelang akan menyebabkan implementasi perangkat lunak yang sudah direncanakan menjadi terhambat. Program yang gagal akan sangat sulit untuk masuk ke usulan rencana anggaran tahun berikutnya, solusinya program dikerjakan dengan swakelola. Namun program tersebut harus masuk antrian pengerjaan, dimana waktu yang dibutuhkan juga menjadi bertambah lama

23 7 untuk proram tersebut dapat diimplementasikan. Berdasarkan Petunjuk Operasional Kegiatan Asdep DDKI dan observasi penulis, diketahui tahun 2011 Kementerian Sekretariat Negara memiliki 4 (empat) kegiatan pengembangan perangkat lunak yang dilelang dengan hasil 3 (tiga) kegiatan berhasil dan 1 (satu) gagal (surat berita acara pemeriksaan nomor BA- 1/BAPP/PPB/12/2011). Untuk tahun 2012 dari 2 (dua) kegiatan yang dilelang, 1 (satu) kegiatan mengalami keterlambatan (surat berita acara restitusi/denda nomor BARD-01/PPBJ-PUUN/12/2012). Ada beberapa hal yang membuat kegiatan melalui pelelangan mengalami keterlambatan maupun kegagalan, diantaranya kerangka acuan kerja yang dibuat masih bersifat umum sehingga penyedia jasa konsultansi perlu mendalami keinginan dan kebutuhan dari pengguna. Hal ini kadang tidak dilakukan oleh penyedia, sehingga penyedia kurang memahami keinginan dan kebutuhan pengguna. Ini berakibat pada pelaksanaan yang tidak sesuai jadwal, bahkan kadang fungsi dari aplikasi belum siap disaat waktu pengerjaan sudah habis. Selama ini pemilihan penyedia melalui pelelangan dinilai berdasarkan administrasi, teknis (pengalaman perusahaan, metodologi, dan kualifikasi tenaga ahli), dan harga. Belum pernah dilakukan penilaian kapasitas teknis pengembangan perangkat lunak yang mengacu pada standar internasional (wawancara dengan Kepala Subbidang Aplikasi Otomasi Perkantoran pada tanggal 13 dan 27 Agustus 2013 dan Kepala Subbagian Informasi dan Dokumentasi Kepegawaian, Biro Kepegawaian pada tanggal 28 Agustus 2013). Dari masalah-masalah yang ada, penulis tertarik untuk meneliti bagaimana meningkatkan proses pemilihan penyedia jasa konsultansi dengan menilai kapasitas penyedia dalam mengembangkan perangkat lunak yang mengacu pada CMMI-DEV sebagai bahan penyusunan kerangka penilaian kapasitas terhadap penyedia untuk meningkatkan kualitas pemilihan penyedia jasa konsultasi perangkat lunak. Hal ini dilakukan untuk mengurangi kesalahan atau kelemahan dalam pengembangan perangkat lunak oleh penyedia, dan mendapatkan penyedia yang memiliki kualitas semakin baik, sehingga semakin ada peningkatan dalam menyelesaikan pekerjaan pengembangan perangkat lunak di Kementerian Sekretariat Negara. Diharapkan juga dari model-model pengembangan terbaik

24 8 yang ada akan menjadi bahan pembelajaran bagi pranata komputer dalam mengembangkan perangkat lunak secara swakelola. Berkaitan dengan hal tersebut, penulis mencoba mengkaji proses pengembangan perangkat lunak yang mengacu pada kerangka kerja CMMI-DEV dalam rangka menyusun rancangan kerangka penilaian kapasitas penyedia perangkat lunak pada proses lelang sehingga dapat meningkatkan kualitas pemilihan penyedia jasa konsultansi pada Kementerian Sekretariat Negara. Maka ditarik pertanyaan penelitian Bagaimana rancangan kerangka penilaian kapasitas penyedia jasa konsultansi perangkat lunak yang mengacu pada CMMI-DEV di Kementerian Sekretariat Negara? 1.3 Tujuan Tujuan dari penelitian ini adalah untuk merancang kerangka penilaian kapasitas penyedia perangkat lunak yang akan digunakan memilih penyedia pada proses lelang dan menilai pekerjaan dari penyedia yang telah melaksanakan pekerjaannya di Kementerian Sekretariat Negara. Pembuatan rancangan penilaian kapasitas penyedia mengacu pada CMMI Dev, sebagai bahan pengkajian model kerangka penilaian kapasitas penyedia perangkat lunak. 1.4 Manfaat Penelitian Manfaat yang diharapkan dari penelitian ini adalah: a. Penelitian ini dapat menjadi referensi Kementerian Sekretariat Negara dalam melakukan penilaian kapasitas penyedia pada proses lelang dan penilaian pekerjaan penyedia pada proses penerimaan pekerjaan. b. Penelitian ini dapat menjadi referensi atau pembanding akademik dalam mengukur kapasitas penyedia jasa konsultansi perangkat lunak. 1.5 Ruang Lingkup Penelitian Penelitian ini akan mengkaji penilaian kapasitas para penyedia jasa konsultansi perangkat lunak yang sedang mengerjakan proyek pengembangan perangkat lunak di Kementerian Sekretariat Negara tahun Penilaian mengacu pada kerangka

25 9 kerja CMMI-DEV V 1.3 representasi Continuous dengan proses area Requirements Management, Project Planning, Project Monitoring And Control dan Supplier Agreement Management.

26 BAB 2 KAJIAN PUSTAKA 2.1 Rekayasa Perangkat Lunak Perangkat lunak merupakan program komputer, dokumentasi, dan konfigurasi yang diperlukan untuk membuat program tersebut dapat beroperasi dengan benar. Suatu perangat lunak biasanya terdiri dari beberapa bagian program yang terpisah, seperti file-file konfigurasi yang digunakan untuk membuat program, dokumentasi sistem yang menggambarkan struktur dari sistem, dan dokumentasi untuk pengguna yang menjelaskan bagaimana mengoperasikan perangkat lunak tersebut (Sommerville, 2007). Perangkat lunak terbagi dua jenis, yang pertama generic products, produk yang sudah jadi dan dipakai banyak orang karena fungsinya yang bersifat umum. yang kedua customised products, produk khusus dimana fungsinya disesuaikan pada suatu kebutuhan yang lebih spesifik. Rekayasa perangkat lunak merupakan disiplin rekayasa yang berkaitan dengan semua aspek produksi perangkat lunak dari tahap awal spesifikasi sistem sampai merawat sistem ketika sudah digunakan (Sommerville, 2007). Dalam mengembangkan perangkat lunak terdapat empat proses dasar yang umum digunakan, yaitu: 1. Software specification, dimana pengguna dan penganalisa sistem mendefinisikan perangkat lunak yang akan dibangun. 2. Software development, dimana perangkat lunak dirancang dan diprogram. 3. Software validation, dimana perangkat lunak diperiksa untuk memastikan sesuai dengan kebutuhan pengguna. 4. Software evolution, dimana perangkat lunak dimodifikasi sehingga dapat beradaptasi dengan perubahan dari pelanggan dan kebutuhan pasar. 10

27 11 Adapun kebanyakan model proses perangkat lunak yang didasarkan pada salah satu dari tiga model umum atau paradigma pengembangan perangkat lunak : 1. The waterfall approach, terdiri dari beberapa kegiatan yang diwakilkan dalam fase proses terpisah seperti spesifikasi kebutuhan, desain, implementasi, pengujian dan seterusnya. Setelah setiap tahap didefinisikan dan selesai, pengembangan pergi ke tahap berikut. 2. Iterative development, pendekatan ini terdiri dari kegiatan penspesifikasian, pengembangan dan validasi. Awal dari sistem dengan cepat dikembangkan dari spesifikasi yang sangat abstrak. Hal ini kemudian disempurnakan dengan masukan pengguna untuk menghasilkan sistem yang memenuhi kebutuhan pengguna. Sistem ini kemudian dapat digunakan. Atau, mungkin disempurnakan lagi menggunakan pendekatan yang lebih terstruktur untuk menghasilkan sistem yang lebih kuat dan terjaga. 3. Component-based software engineering (CBSE), teknik ini mengasumsikan bahwa bagian-bagian dari sistem sudah ada. Proses pengembangan sistem berfokus pada mengintegrasikan bagian-bagian pengembangan dari awal. (Sommerville, 2007) 2.2 Manajemen Proyek TI Dalam mengembangkan perangkat lunak dibutuhkan manajemen untuk menjaga pengembangan itu dapat berjalan sesuai dengan yang direncanakan sehinga pengembangan itu dapat mencapai target. Dalam buku Information Technology Project Management (ITPM) (Marchewka, 2010), merujuk pada penelitian dari CHAOS (West Yarmouth, MA, 1995) menyebutkan faktor-faktor yang membuat proyek TI menjadi gagal adalah requirements yang tidak lengkap atau jelas, kurangnya keterlibatan pengguna, kurangnya sumber daya, harapan yang tidak realistis, perubahan kebutuhan dan spesifikasi, kurangnya perencanaan, produk tidak dibutuhkan lagi, kurangnya manajemen TI, dan teknologi yang kurang

28 12 literatur. Faktor-faktor ini tentu akan menjadi perhatian dalam meningkatkan kualitas mengelola pengembangan perangkat lunak. Marchewka menjelaskan dalam buku ITPM, manajemen proyek merupakan penerapan pengetahuan, keterampilan, peralatan, dan teknik dalam kegiatan proyek untuk memenuhi kebutuhan stakeholder dan harapan dari proyek. Adapun manajemen proyek meliputi: - Mengidentifikasi kebutuhan - Menetapkan tujuan yang jelas dan dapat dicapai - Menyeimbangkan permintaan yang bersaing pada kualitas, ruang lingkup, waktu, dan biaya - Beradaptasi dengan spesifikasi, rencana, dan pendekatan terhadap masalah yang berbeda dan harapan dari berbagai pemangku kepentingan (Marchewka, 2010) 2.3 CMMI-DEV CMMI (Capability Maturity Model Integration) model merupakan model yang terdiri dari praktik-praktik terbaik yang digunakan untuk membantu organisasi dalam meningkatkan proses mereka. Model ini dikembangkan oleh tim produk dengan anggota dari industri, pemerintah, dan Software Engineering Institute (SEI). CMMI for Development (CMMI-DEV), merupakan model terpadu komprehensif digunakan sebagai pedoman dalam mengembangkan produk dan jasa. CMMI-DEV digunakan untuk berbagai industri, diantaranya ruang angkasa, perbankan, perangkat keras komputer, perangkat lunak, pertahanan, manufaktur mobil, dan telekomunikasi. CMMI-DEV mengandung praktik yang mencakup manajemen proyek, manajemen proses, rekayasa sistem, rekayasa perangkat keras, rekayasa perangkat lunak, dan proses pendukung lainnya yang digunakan dalam pengembangan dan pemeliharaan. CMMI-DEV terdiri dari praktek-praktek terbaik dimana kegiatan pembangunan diterapkan untuk produk dan jasa. Praktik-praktik yang mencakup siklus hidup produk mulai dari konsepsi, penggunaan dan pemeliharaan. Penekanannya pada

29 13 pekerjaan yang diperlukan untuk membangun dan memelihara produk secara keseluruhan. CMMI-DEV berisi 22 area proses, yang terbagi 16 area proses inti, 1 area proses bersama, dan 5 pengembangan area proses tertentu. Semua CMMI-DEV model praktek fokus pada kegiatan organisasi pengembangan. Lima area proses berfokus pada praktek khusus untuk pembangunan: menangani kebutuhan pengembangan, solusi teknis, integrasi produk, verifikasi, dan validasi. Kerangka kerja CMMI menghasilkan model CMMI yang terdiri dari tujuan dan praktek-praktek. Dan model CMMI mengandung 16 area proses inti yang meliputi proses konsep dasar sebagai proses perbaikan pada setiap area yang terkait (Software Engineering Institute, 2010) Process Area Sebuah area proses merupakan sekelompok praktek terkait di daerah yang sedang diimplementasikan secara kolektif, dengan memenuhi serangkaian tujuan dianggap penting untuk membuat perbaikan di daerah itu. Berikut ini merupakan 22 area proses yang diurutkan berdasarkan abjad: - Causal Analysis and Resolution (CAR) - Configuration Management (CM) - Decision Analysis and Resolution (DAR) - Integrated Project Management (IPM) - Measurement and Analysis (MA) - Organizational Process Definition (OPD) - Organizational Process Focus (OPF) - Organizational Performance Management (OPM) - Organizational Process Performance (OPP) - Organizational Training (OT) - Product Integration (PI) - Project Monitoring and Control (PMC) - Project Planning (PP) - Process and Product Quality Assurance (PPQA)

30 14 - Quantitative Project Management (QPM) - Requirements Development (RD) - Requirements Management (REQM) - Risk Management (RSKM) - Supplier Agreement Management (SAM) - Technical Solution (TS) - Validation (VAL) - Verification (VER) Gambar 2.1 CMMI Model Components Sumber: CMMI Product Team, Software Engineering Institute, Carnegie Mellon University (2010) Pada Gambar 2.1 dapat terlihat CMMI terdiri dari model komponen-komponen yang dikelompokkan menjadi tiga kategori, yaitu required (yang diperlukan), expected (yang diharapkan) dan informative (informatif). Komponen required merupakan komponen CMMI yang penting dalam mencapai perbaikan proses pada area proses. Pemenuhan komponen ini harus tampak diterapkan dalam proses di organisasi. Komponen required dalam CMMI adalah specific goals dan generic goals. Komponen expected adalah komponen CMMI yang menggambarkan kegiatan yang penting dalam mencapai komponen required

31 15 CMMI. Komponen expected memandu dalam melaksanakan perbaikan atau penilaian. Komponen expected CMMI adalah specific practices dan generic practices. Komponen informative merupakan komponen CMMI yang membantu pengguna model memahami komponen required dan komponen expected CMMI. Konponen informative dapat berupa kotak contoh, rincian penjelasan, atau informasi lain yang berguna. Subpractices, notes, references, goal titles, practice titles, sources, example work products, dan generic practice elaborations merupakan komponen model informative. Sebuah area proses terdiri dari Specific Goals dan Generic Goals. Dimana Specific Goal terdiri dari beberapa Specific Practice yang sebagian memiliki Example Work Product dan Subpractices. Generic Goal terdiri dari Generic Practice yang sebagian memiliki Subpractices dan Generic Practice Elaborators. Specific Goal menggambarkan karakteristik unik yang ada untuk memenuhi area proses. Specific Goal adalah model komponen yang diperlukan dan digunakan dalam penilaian untuk membantu menentukan apakah suatu area proses terpenuhi. Generic Goal menggambarkan karakteristik yang ada untuk melembagakan proses yang menerapkan area proses. Generic Goal adalah model komponen yang diperlukan dan digunakan dalam penilaian untuk menentukan apakah suatu area proses terpenuhi. Specific practice merupakan deskripsi dari suatu kegiatan yang dianggap penting dalam mencapai specific goal. Specific practice menggambarkan kegiatan yang diharapkan dapat mencapai specific goal dari area proses. Subpractice merupakan penjelasan rinci yang memandu untuk menafsirkan dan menerapkan specific practice atau generic practice. Generic practice terkait dengan generic goal, menggambarkan kegiatan yang dianggap penting dalam mencapai generic goal dan berkontribusi terhadap pelembagaan proses yang terkait dengan area proses (Software Engineering Institute, 2010) Representasi Continuous CMMI-DEV menggunakan level (tingkatan) untuk menggambarkan jalur evolusi yang direkomendasikan untuk sebuah organisasi yang ingin meningkatkan proses yang digunakan untuk mengembangkan produk atau jasa. Level juga dapat menjadi hasil dari kegiatan pemeringkatan dalam penilaian. Penilaian dapat

32 16 berlaku untuk seluruh organisasi atau kelompok-kelompok kecil seperti kelompok proyek atau divisi. CMMI mendukung dua jalur perbaikan dengan menentukan level. Satu jalur memungkinkan organisasi untuk secara bertahap meningkatkan proses sesuai dengan area proses individu (atau kelompok area proses) yang dipilih oleh organisasi. Jalur lain memungkinkan organisasi untuk meningkatkan serangkaian proses terkait dengan bertahap secara berturut-turut dalam paket area proses. Kedua jalur perbaikan terkait dengan dua jenis tingkat: capability levels dan maturity levels. Level ini sesuai dengan dua pendekatan untuk perbaikan proses yang disebut "Representations". Kedua representasi disebut "continuous dan staged". Menggunakan representasi continuous memungkinkan untuk mencapai "capability levels". Menggunakan representasi staged memungkinkan untuk mencapai "maturity levels". Untuk mencapai tingkat tertentu, sebuah organisasi harus memenuhi semua tujuan area proses atau paket area proses yang ditargetkan untuk perbaikan, terlepas dari apakah itu adalah capability atau maturity level. Kedua representasi menyediakan cara untuk meningkatkan proses dalam mencapai tujuan bisnis, dan keduanya menyediakan konten penting yang sama dan menggunakan model komponen yang sama. Representasi continuous menggunakan capability level untuk mencirikan keadaan proses organisasi ke area proses individu. Representasi continuous berfokus pada capability area proses yang diukur dengan capability level. Capability level berlaku untuk proses peningkatan prestasi organisasi dalam area proses individu. Tingkatan ini merupakan sarana untuk secara bertahap meningkatkan proses sesuai dengan area proses. Empat tingkat kemampuan diberi nomor 0 sampai 3. Representasi continuous fokus pada meningkatkan area proses dan meningkatkan kemampuan pada area proses yang diinginkan. Dalam konteks ini, apakah proses dilakukan atau tidak lengkap adalah penting. Oleh karena itu, nama "Incomplete" diberikan kepada representasi continuous pada titik awal.

33 17 Untuk mendukung mereka yang menggunakan representasi continuous, semua model CMMI mencerminkan capability levels dalam desain dan konten mereka. Empat capability levels, masing-masing lapisan dalam dasar bagi perbaikan proses yang sedang berlangsung, yang ditunjuk oleh angka 0 sampai 3: 0. Incomplete 1. Performed 2. Managed 3. Defined Capability levels untuk area proses dicapai ketika semua generic goals terpenuhi sampai ke tingkat itu. Kenyataan bahwa tingkat kemampuan 2 dan 3 menggunakan istilah yang sama sebagai generic goals 2 dan 3 adalah disengaja karena masing-masing generic goals dan practices goals mencerminkan arti dari tujuan dan praktek capability levels. Penjelasan singkat dari setiap tingkat kemampuan berikut. Capability Level 0: Incomplete Sebuah proses yang tidak lengkap adalah sebuah proses yang tidak dilakukan atau sebagian dilakukan. Satu atau lebih dari specific goals dari area proses tidak terpenuhi dan tidak ada generic goals untuk tingkat ini karena tidak ada alasan untuk melembagakan proses parsial. Capability Level 1: Performed Proses capability level 1 ditandai sebagai proses yang dilakukan. Sebuah proses yang dilakukan adalah proses yang menyelesaikan pekerjaan yang diperlukan untuk menghasilkan work products, dan dapat terpenuhinya specific goals dari area proses. Meskipun hasil capability level 1 di perbaikan penting, perbaikan-perbaikan dapat hilang dari waktu ke waktu jika mereka tidak dilembagakan. Penerapan pelembagaan membantu untuk memastikan bahwa perbaikan dapat dipertahankan.

34 18 Capability Level 2: Managed Proses capability level 2 dicirikan sebagai proses yang dikelola. Sebuah proses yang dikelola adalah proses yang direncanakan dan dilaksanakan sesuai dengan kebijakan; mempekerjakan orang-orang terampil dengan sumber daya yang memadai untuk menghasilkan output terkendali, melibatkan stakeholder yang relevan; dipantau, dikendalikan, dan terpantau, dan dievaluasi untuk kepatuhan terhadap deskripsi prosesnya. Proses disiplin tercermin pada capability level 2 akan membantu untuk memastikan bahwa praktek-praktek yang ada dipertahankan selama masa-masa sulit. Capability Level 3: Defined Proses capability level 3 ditandai sebagai proses yang terdefinisi. Proses yang terdefinisi adalah proses yang dikelola yang disesuaikan dari proses standar dari organisasi proses standar sesuai dengan pedoman organisasi, memiliki gambaran proses yang dapat dipertahankan, dan memberikan kontribusi terkait pengalaman proses organisasi. Perbedaan penting antara tingkat kemampuan 2 dan 3 adalah ruang lingkup standar, deskripsi proses, dan prosedur. Pada capability level 2, standar, deskripsi proses, dan prosedur bisa sangat berbeda dalam setiap contoh spesifik dari proses. Pada capability level 3, standar, deskripsi proses, dan prosedur untuk proyek dirancang dari set organisasi proses standar sesuai dengan suatu proyek tertentu atau unit organisasi dan oleh karena itu lebih konsisten, kecuali untuk perbedaan yang diizinkan oleh pedoman pemadu. Perbedaan penting yang lain adalah bahwa pada capability level 3 proses biasanya digambarkan lebih ketat daripada di capability level 2. Proses yang didefinisikan dengan jelas menyatakan tujuan, masukan, kriteria masuk, kegiatan, peran, langkah-langkah, langkah-langkah verifikasi, output, dan kriteria keluar. Pada capability level 3, proses yang dikelola lebih proaktif menggunakan pemahaman

35 19 tentang keterkaitan kegiatan proses dan langkah-langkah rinci proses serta produk kerjanya (Software Engineering Institute, 2010) Hubungan Antara Area Proses Dalam CMMI-DEV dijelaskan keterhubungan antara area proses untuk membantu dalam pengorganisasian dari perbaikan proses dan bagaimana area proses saling terhubung dan bergantung pada pelaksanaan area proses yang lain. Berikut ini kelompok area proses yang saling terhubung: - Keterhubungan area proses pada Basic Process Management Process Areas menyediakan pengorganisasian dengan kemampuan untuk mendokumentasikan dan berbagi praktik terbaik, organisasi aset proses, dan pembelajaran seluruh organisasi. Adapun area proses yang terhubung adalah Organizational Process Focus (OPF), Organizational Process Definition (OPD), dan Organizational Training (OT). - Keterhubungan area proses pada Advanced Process Management Process Areas menyediakan pengorganisasian dengan kemampuan yang lebih baik untuk mencapai tujuan kuantitatif untuk kualitas dan kinerja proses. Adapun area proses yang terhubung adalah Organizational Performance Management (OPM) dan Organizational Process Performance (OPP). - Keterhubungan area proses pada Basic Project Management Process Areas untuk mengatasi kegiatan yang berkaitan dengan membangun dan mempertahankan rencana proyek, membangun dan mempertahankan komitmen, pemantauan kemajuan terhadap rencana, mengambil perjanjian tindakan korektif, dan mengelola pemasok. Adapun area proses yang terhubung adalah Requirements Management (REQM), Project Planning (PP), Project Monitoring and Control (PMC), dan Supplier Agreement Management (SAM). - Keterhubungan area proses pada Advanced Project Management Process Areas untuk menangani kegiatan seperti membangun proses yang didefinisikan dan disesuaikan dari himpunan standar proses organisasi, membangun lingkungan kerja proyek dari standar lingkungan kerja organisasi, koordinasi dan bekerja sama dengan stakeholder terkait,

36 20 membentuk dan mempertahankan tim untuk melakukan proyek, secara kuantitatif mengelola proyek, dan mengelola risiko. Adapun area proses yang terhubung adalah Quantitative Project Management (QPM), Integrated Project Management (IPM), dan Risk Management (RSKM). - Keterhubungan area proses pada Engineering meliputi pengembangan dan pemeliharaan kegiatan yang dibagi di seluruh disiplin ilmu teknik. Area proses engineering ditulis menggunakan terminologi engineering umum sehingga setiap disiplin teknis yang terlibat dalam proses pengembangan produk (misalnya, rekayasa perangkat lunak, teknik mesin) dapat menggunakannya untuk perbaikan proses. Adapun area proses yang terhubung adalah Product Integration (PI), Requirements Development (RD), Technical Solution (TS), Validation (VAL), dan Verification (VER). - Keterhubungan area proses pada Basic Support Process Areas untuk menangani fungsi dukungan fundamental yang digunakan oleh semua area proses. Meskipun semua bidang proses support mengandalkan pada area proses lain untuk input, Basic Support Process Areas memberikan fungsi pendukung yang juga membantu melaksanakan beberapa praktek generik. Adapun area proses yang terhubung adalah Measurement and Analysis (MA), Process and Product Quality Assurance (PPQA), dan Configuration Management (CM). - Keterhubungan area proses pada Advanced Support Process Areas menyediakan proyek dan organisasi dengan kemampuan dukungan ditingkatkan. Masing-masing daerah proses ini bergantung pada input tertentu atau praktek dari area proses lainnya. Adapun area proses yang terhubung adalah Causal Analysis and Resolution (CAR) dan Decision Analysis and Resolution (DAR). Berkaitan dengan permasalahan yang ada di Kementerian Sekretariat Negara untuk pengembangan perangkat lunak yang melibatkan penyedia. Basic Project Management Process Areas sangat dekat dengan permasalahan project management yang ada. Gambar 2.2 memberikan gambaran mengenai interaksi antara proses area Basic Project Management dengan proses area yang lain. Seperti terlihat dalam Gambar 2.2, proses area Project Planning meliputi

37 21 pengembangan rencana proyek, pelibatan pemangku kepentingan yang relevan, memperoleh komitmen terhadap rencana, dan menjaga rencana. Gambar 2.2 Basic Project Management Process Areas Sumber: CMMI Product Team, Software Engineering Institute, Carnegie Mellon University (2010) Perencanaan dimulai dengan persyaratan yang menentukan produk dan proyek ( What to Build pada Gambar 2.2). Rencana proyek meliputi berbagai kegiatan pengelolaan dan pengembangan yang dilakukan pada proyek. Proyek mengulas rencana lain yang mempengaruhi proyek dari berbagai pemangku kepentingan yang relevan dan komitmen untuk kontribusi mereka terhadap proyek. Area proses Project Monitoring and Control berisi praktek pemantauan dan pengendalian kegiatan dan mengambil tindakan korektif. Rencana proyek menentukan frekuensi tinjauan kemajuan dan langkah-langkah yang digunakan untuk memantau kemajuan. Kemajuan ditentukan dengan membandingkan proyek status rencana. Ketika status sebenarnya menyimpang secara signifikan dari nilainilai yang diharapkan, tindakan korektif yang dapat diambil adalah perencanaan ulang, yang mengharuskan menggunakan praktek Project Planning.

38 22 Area proses Requirements Management menjaga kebutuhan. Ini menggambarkan kegiatan untuk memperoleh dan mengendalikan perubahan kebutuhan dan memastikan bahwa rencana lain yang relevan dan data tetap tersimpan. Disini tersedia penelusuran terhadap kebutuhan pelanggan terhadap kebutuhan dari produk. Requirements Management memastikan bahwa perubahan kebutuhan dapat terlihat pada rencana proyek, kegiatan, dan produk. Siklus perubahan dapat mempengaruhi area proses Engineering. Requirements Management merupakan urutan dinamis dan sering rekursif peristiwa. Area proses Requirements Management adalah fundamental bagi proses rekayasa terkendali dan disiplin. Area proses Supplier Agreement Management menunjukan kebutuhan proyek untuk memperoleh bagian-bagian dari pekerjaan yang diproduksi oleh pemasok. Sumber produk dapat digunakan untuk memenuhi kebutuhan proyek proaktif yang diidentifikasi. Pemasok yang dipilih, dan perjanjian pemasok dibuat untuk mengelola pemasok. Kemajuan dan kinerja pemasok dilacak sebagaimana ditentukan dalam perjanjian pemasok, dan perjanjian pemasok dapat direvisi dan disesuaikan. Ulasan penerimaan dan tes dilakukan pada pemasok komponen produk. Untuk keterangan mengenai goals dan practices dari kelompok keterhubungan area proses Basic Project Management Process Areas dapat dilihat pada lampiran Standard CMMI Appraisal Method for Process Improvement Standard CMMI Appraisal Method for Process Improvement (SCAMPI) merupakan kelanjutan penilaian CMM-Based Assessment for Internal Process Improvement (CBA-IPI), metode yang ditetapkan untuk CMM. Dengan bantuan sebuah penilaian, organisasi dapat mengetahui tingkat CMMI dan mendapatkan rekomendasi tentang bagaimana untuk lebih meningkatkan proses pembangunan, serta mendapat pernyataan tentang kematangan prosesnya. Penilaian CMMI akan lebih menekankan pada perbaikan proses.

39 23 SCAMPI merupakan metode penilaian yang didefinisikan oleh SEI. Untuk membedakan kelengkapan dari metode, SCAMPI dibagi menjadi SCAMPI A, B dan C. SEI membedakan dua macam penilaian berdasarkan tujuan mereka: - Untuk perbaikan proses internal dengan tujuan mengevaluasi diri dan mengidentifikasi peluang dalam melakukan peningkatan. - Untuk mengevaluasi proses kematangan (calon) pemasok sebelum kontrak, sebagai dasar untuk pengambilan keputusan tentang pemasok, atau untuk memantau dukungan dari pemasok. Ini merupakan alasan awal yang utama untuk pengembangan CMM dan CMMI- Departemen Pertahanan Amerika Serikat ingin dasar yang lebih baik untuk keputusan dalam pemberian kontrak kepada pemasok perangkat lunak. Terlepas dari metode yang telah didefinisikan oleh SEI, setiap organisasi dapat menentukan metode penilaian sendiri yang mungkin lebih baik disesuaikan dengan spesifik organisasi, khususnya untuk pengecekan yang lebih rendah. Dalam rangka mencapai tingkat minimum tertentu dengan keseragaman dan kualitas penilaian, SEI telah mendefinisikan Appraisal Requirements for CMMI (ARC), yang mendefinisikan tiga kelas metode penilaian dengan berbagai paket persyaratan minimum. Appraisal Requirements for CMMI mendefinisikan tiga kelas metode penilaian yang berbeda dalam ketelitian dan upaya yang dilakukan. - Kelas A Metode penilaian kelas A yang dioptimalkan untuk hasil yang dapat diandalkan dan benar, tetapi membutuhkan usaha yang paling besar. Metode yang paling penting dalam kelas ini adalah SCAMPI A (kelas A metode yang didefinisikan oleh SEI). Hanya kelas A penilaian yang diperbolehkan menggunakan rating untuk melaporkan tingkat kematangan terntentu dari profil kemampuan, dan SEI hanya akan menerima penilaian SCAMPI A.

40 24 - Kelas B Metode penilaian kelas B memiliki persyaratan yang lebih rendah dari kelas A pada keandalan dan kebenaran hasil. Ada pengecekan yang lebih rendah dalam menghasilkan laporan tertentu. Akibatnya, hanya sedikit usaha yang diperlukan dalam melakukan penilaian. - Kelas C Metode kelas C digunakan untuk penilaian yang lebih sering dan untuk pengecekan cepat. Persyaratan dan usaha yang dilakukan lebih rendah lagi dari kelas B. Meskipun hasil penilaian kelas C tidak dapat diandalkan seperti penilaian kelas A atau B, untuk berbagai tujuan keandalannya masih mencukupi. Semakin rendah upaya yang dilakukan, penilaian dapat dilakukan lebih sering dalam rangka menngetahui kemajuan. 2.4 Kerangka Standar Kompetensi Berbasis Kinerja dari GAPPS Global Alliance for Project Performance Standards (GAPPS) merupakan organisasi relawan yang bekerja untuk menciptakan kerangka kerja dan standar project management dengan menyediakan forum bagi para stakeholder dari sistem, latar belakang, dan konteks operasi yang berbeda untuk bekerja sama dalam memenuhi kebutuhan komunitas global project management. Kerangka GAPPS digunakan oleh kalangan bisnis, lembaga akademis, penyedia pelatihan, asosiasi profesi, dan standar pemerintah, serta kualifikasi badan global. Kerangka dapat digunakan sebagaimana adanya atau disesuaikan dengan kebutuhan organisasi. Adapun kerangka yang dihasilkan oleh GAPPS adalah kerangka untuk Performance Based Competency Standards for Global Level 1 and 2 Project Managers. Kerangka ini digunakan untuk menilai ambang kompetensi dan kemampuan dalam melakukan proyek pada standar dianggap dapat diterima di organisasi. Hal ini berlaku Global Level 1 dan Global Level 2 manajer proyek di semua bidang usaha, dan tidak terbatas pada: arsitektur, bioteknologi, konstruksi, desain, pendidikan, teknik, jasa keuangan, pemerintah, kontraktor pemerintah, sistem informasi, kegiatan non-profit, obat-obatan, perangkat lunak, dan telekomunikasi.

41 25 Tabel di bawah ini merupakan ringkasan dari unit kompetensi yang dinilai: Tabel 2.1 Unit Kompetensi No Unit Judul Unit Deksrisi Unit PM01 Manage Stakeholder Satuan ini mendefinisikan Elemen yang dibutuhkan untuk mengelola hubungan stakeholder selama Relationships proyek. Ini mencakup kriteria kinerja yang dibutuhkan untuk menunjukkan kompetensi dalam memastikan tepat waktu dan ketepatan dari keterlibatan individu, organisasi, dan kelompok seluruh proyek. PM02 Manage Unit Proyek ini mendefinisikan elemen yang Development of the Plan for the Project dibutuhkan untuk mengelola pengembangan rencana untuk proyek tersebut. Ini mencakup kriteria kinerja yang dibutuhkan untuk mendemonstrasikan kompetensi dalam menentukan bagaimana untuk mewujudkan proyek secara efisien dan efektif. PM03 Manage Project Unit ini mendefinisikan elemen yang dibutuhkan Progress untuk mengelola kemajuan proyek. Ini mencakup kriteria kinerja yang dibutuhkan untuk mendemonstrasikan kompetensi dalam memastikan bahwa proyek bergerak konstruktif menuju pengiriman produk dari proyek dan mendukung hasil proyek yang telah disepakati. PM04 Manage Product Satuan ini mendefinisikan elemen yang diperlukan Acceptance untuk memastikan bahwa produk, layanan, atau hasil dari proyek tersebut akan diterima oleh pemangku kepentingan yang relevan. Ini mencakup kriteria kinerja yang dibutuhkan untuk mendemonstrasikan kompetensi dalam memastikan bahwa produk dari proyek didefinisikan, disetujui, dikomunikasikan, dan diterima.

42 26 No Unit Judul Unit Deksrisi Unit PM05 Manage Project Satuan ini mendefinisikan elemen yang dibutuhkan Transitions untuk mengelola transisi proyek. Ini mencakup kriteria kinerja yang dibutuhkan untuk mendemonstrasikan kompetensi dalam menjalankan proyek sedang berlangsung, dalam bergerak dari satu fase proyek ke fase berikutnya, dan penyelesaian proyek hingga pada suatu kesimpulan. PM06 Evaluate and Unit Proyek ini mendefinisikan elemen yang Improve Project dibutuhkan untuk mengevaluasi dan meningkatkan Performance kinerja proyek. Hal ini mencakup kriteria kinerja yang dibutuhkan untuk mendemonstrasikan kompetensi dalam memastikan bahwa peluang untuk perbaikan diterapkan pada proyek ini dan dibuat tersedia untuk proyek-proyek masa depan. Sumber: Global Alliance for Project Performance Standards (2007) 2.5 Projects in a Controlled Environment Projects in a Controlled Environment (PRINCE2) merupakan metode manajemen proyek terstruktur berdasarkan pengalaman yang diambil dari ribuan proyek dan kontribusi yang tak terhitung jumlahnya dari sponsor proyek, manajer proyek, tim proyek, akademisi, pelatih dan konsultan. PRINCE2 dikembangkan oleh Office of Government Commerce (OGC). PRINCE2 adalah metode yang tidak- eksklusif dan telah banyak digunbakan dibanyak negara untuk mengelola proyek yang dapat diterapkan pada beragam proyek terlepas dari skala proyek, jenis, organisasi, geografi atau budaya. Metode PRINCE2 dapat diadopsi sebagai standar subtansi suatu organisasi untuk meningkatkan kemampuan dan kematangan di beberapa bidang kegiatan usaha - perubahan bisnis, konstruksi, IT, merger dan akuisisi, penelitian, pengembangan produk dan sebagainya.

43 27 PRINCE2 merupakan sebuah framework yang terintegrasi dari proses dan tema yang membahas perencanaan, delegasi, pemantauan dan pengendalian semua enam aspek kinerja proyek (biaya, skala waktu, kualitas, ruang lingkup, resiko, dan manfaat). Adapun tiga hal yang tidak masuk dalam PRINCE2 adalah: - Specialist aspects, kekuatan PRINCE2 adalah dalam penerapan secara luas - itu sepenuhnya bersifat umum. Akibatnya, aktivitas industri tertentu atau tipe tertentu dikecualikan. - Detailed techniques, hanya teknik yang memiliki pendekatan spesifik PRINCE2 yang dijelaskan, misalnya perencanaan berbasis produk dan review kualitas teknik. - Leadership capability, Kepemimpinan, keterampilan motivasi dan keterampilan interpersonal lainnya sangat penting dalam manajemen proyek tetapi tidak disusun dalam PRINCE2. PRINCE2 menentukan tema yang menjelaskan aspek-aspek manajemen proyek yang harus diatasi. Perhatian menyeluruh untuk tema-tema ini akan memenuhi peran secara profesional bagi manajer proyek. Berikut tema-tema yang terdapat pada PRINCE2: - Business Case, proyek dimulai dengan sebuah ide yang dianggap memiliki potensi nilai organisasi yang bersangkutan. Tema ini membahas bagaimana ide dikembangkan menjadi proposisi investasi yang layak bagi organisasi dan bagaimana proyek manajemen mempertahankan fokus pada tujuan organisasi di seluruh proyek. - Organization, organisasi yang mensponsori proyek ini perlu mengalokasikan pekerjaan untuk manajer yang akan bertanggung jawab dan mengarahkan sampai selesai. Proyek adalah lintas fungsional sehingga struktur fungsi garis normal tidak cocok. Tema ini menggambarkan peran dan tanggung jawab yang dibutuhkan untuk mengelola secara efektif proyek dalam tim manajemen proyek. - Quality, ide awal hanya akan dipahami sebagai garis besar. Tema ini menjelaskan bagaimana garis besar dikembangkan sehingga semua peserta memahami kualitas atribut produk yang akan dihasilkan, kemudian bagaimana

44 28 manajemen proyek akan memastikan bahwa kebutuhan yang ada dapat terpenuhi. - Plans, proyek PRINCE2 berjalan atas dasar rencana yang telah disetujui. Ini tema melengkapi tema kualitas dengan menjelaskan langkah-langkah yang diperlukan untuk mengembangkan rencana dan teknik PRINCE2 yang harus diterapkan. Di PRINCE2, rencana yang disesuaikan dengan kebutuhan personel di berbagai tingkat organisasi. Mereka adalah fokus untuk komunikasi dan kontrol seluruh proyek. - Risk, proyek yang dibutuhkan biasanya lebih berisiko daripada kegiatan operasional yang stabil. Tema ini untuk mengetahui bagaimana manajemen proyek mengelola ketidakpastian dalam rencana dan dalam lingkungan proyek yang lebih luas. - Change, tema ini menggambarkan bagaimana manajemen proyek menilai dan bertindak atas isu-isu yang memiliki dampak potensial pada salah satu aspek dasar dari proyek (yang sudah terencana dan produk yang selesai). Masalah mungkin masalah umum yang tak terduga, permintaan untuk perubahan atau misalnya kegagalan kualitas. - Progress, tema ini membahas keberlangsungan rencana. Tema menjelaskan proses pengambilan keputusan untuk menyetujui rencana, pemantauan aktual kinerja dan proses eskalasi jika peristiwa tidak berjalan sesuai rencana. Pada akhirnya, tema progress menentukan apakah dan bagaimana proyek harus melanjutkan. (Office of Government Commerce, 2009) 2.6 PMBOK Guide A Guide to the Project Management Body of Knowledge (PMBOK Guide) merupakan pedoman untuk mengelola proyek-proyek dan mendefinisikan manajemen terkait konsep proyek. Hal ini untuk menggambarkan siklus hidup manajemen proyek dan proses terkait, serta siklus hidup dari proyek. PMBOK Guide dikembangkan oleh Project Management Institute, Inc. (PMI). PMBOK Guide menjelaskan konsep-konsep kunci dalam bidang manajemen proyek, ringkasan Process Groups dan gambaran tentang proses interaksi antara sepuluh

45 29 Knowledge Areas dan lima Process Group, panduan project management body of knowledge. PMBOK Guide terdiri dari: Organizational Influences and Project Life Cycle Bagian ini menjelaskan bagaimana pengaruh organisasi mempengaruhi metode yang digunakan untuk kepegawaian, pengelolaan, dan pelaksanaan proyek. Ini membahas pengaruh stakeholder pada proyek dan pemerintahan, struktur dan keanggotaan tim proyek, dan pendekatan yang berbeda untuk pentahapan dan hubungan kegiatan dalam siklus hidup proyek. Project Management Processes Manajemen proyek adalah penerapan pengetahuan, keterampilan, peralatan, dan teknik untuk kegiatan proyek untuk memenuhi persyaratan proyek. Aplikasi ini membutuhkan pengetahuan manajemen yang efektif dari proses manajemen proyek. Proses adalah serangkaian tindakan yang saling terkait dan kegiatan yang dilakukan untuk menciptakan produk pra-ditentukan, layanan, atau hasil. Setiap proses ditandai dengan input, alat dan teknik yang dapat diterapkan, dan output yang dihasilkan. Project Integration Management Project Integration Management mencakup proses-proses dan kegiatan untuk mengidentifikasi, menentukan, menggabungkan, menyatukan, dan mengkoordinasikan berbagai proses dan kegiatan manajemen proyek dalam Project Management Process Groups. Project Scope Management Project Scope Management mencakup proses-proses yang diperlukan untuk memastikan bahwa proyek tersebut mencakup semua pekerjaan yang diperlukan, dan hanya pekerjaan yang diperlukan, untuk menyelesaikan proyek dengan sukses. Mengelola ruang lingkup proyek terutama berkaitan dengan mendefinisikan dan mengendalikan apa yang bisa dan tidak termasuk dalam proyek. Project Time Management Project Time Management mencakup proses-proses yang dibutuhkan untuk mengelola penyelesaian tepat waktu proyek.

46 30 Project Cost Management Project Cost Management mencakup proses-proses yang terlibat dalam perencanaan, memperkirakan, anggaran, pembiayaan, pendanaan, pengelolaan, dan biaya pengendalian sehingga proyek dapat diselesaikan dalam anggaran yang disetujui. Project Quality Management Project Quality Management mencakup proses-proses dan kegiatan organisasi yang menentukan kebijakan mutu, sasaran, dan tanggung jawab sehingga proyek akan memenuhi kebutuhan yang dituju. Project Human Resource Management Project Human Resource Management mencakup proses-proses yang mengatur, mengelola, dan memimpin tim proyek. Project Communications Management Project Communications Management mencakup proses-proses yang diperlukan untuk memastikan perencanaan yang tepat waktu dan tepat, pengumpulan, penciptaan, distribusi, penyimpanan, pencarian, manajemen, pengawasan, pemantauan, dan disposisi akhir dari informasi proyek. Project Risk Management Project Risk Management mencakup proses-proses melakukan perencanaan manajemen risiko, identifikasi, analisis, perencanaan respon, dan risiko pengendalian pada sebuah proyek. Tujuan dari Project Risk Management adalah untuk meningkatkan kemungkinan dan dampak peristiwa positif, mengurangi kemungkinan dan dampak dari kejadian negatif dalam proyek. Project Procurement Management Project Procurement Management mencakup proses-proses yang diperlukan untuk membeli atau memperoleh produk, jasa, atau hasil yang dibutuhkan dari luar tim proyek. Organisasi dapat berupa pembeli atau penjual dari produk, jasa, atau hasil dari sebuah proyek. Project Stakeholder Management Project Stakeholder Management mencakup proses-proses yang diperlukan untuk mengidentifikasi orang-orang, kelompok, atau organisasi yang dapat

47 31 mempengaruhi atau dipengaruhi oleh proyek, menganalisis harapan pemangku kepentingan dan dampaknya terhadap proyek, dan untuk mengembangkan strategi pengelolaan yang tepat untuk secara efektif melibatkan para pemangku kepentingan dalam pengambilan keputusan proyek dan eksekusi. Manajemen Stakeholder juga berfokus pada komunikasi yang berkelanjutan dengan para pemangku kepentingan untuk memahami kebutuhan dan harapan, isu-isu yang terjadi, mengelola konflik kepentingan dan mendorong keterlibatan pemangku kepentingan yang tepat dalam keputusan dan kegiatan proyek mereka. Kepuasan stakeholder harus dikelola sebagai tujuan utama proyek. (Project Management Institute, 2013) 2.7 Perbandingan Manajemen Proyek Pada penelitian ini penulis membandingkan 4 (empat) model yang dapat dijadikan acuan dalam menjalankan proyek sebagai mekanisme dasar yang nantinya diukur tingkat kapasitas atau kemampuan dari pengembangan perangkat lunak, yaitu Kerangka Standar Kompetensi Berbasis Kinerja dari GAPPS, PRINCE2, PMBOK Guide, dan CMMI-DEV. Kerangka Standar Kompetensi Berbasis Kinerja dari GAPPS digunakan sebagai panduan bagi manajer proyek dalam menjalankan proyek sesuai standar dari GAPPS, namun dalam kerangka ini dapat ditentukan tingkat kinerja sesuai keadaan dari organisasi. Sehingga nantinya kegiatan dari proyek dapat diukur kinerjanya. PRINCE2 merupakan kerangka kerja dalam mengatur proyek yang memperhatikan biaya, skala waktu, kualitas, ruang lingkup, resiko, dan manfaat. Dalam pelaksanaan kerangka dari PRINCE2, manajer proyek diharuskan memperhatikan pemenuhan dari tema-tema yang telah ditetapkan PRINCE2, yaitu business case, organization, quality, plans, risk, change, dan progress. PMBOK Guide merupakan panduan dalam menjalankan proyek yang menjelaskan definisi-definisi manajemen dalam menjalankan proyek. Di PMBOK

48 32 Guide juga digambarkan siklus dalam menjalankan proyek dan proses, serta siklus dari proyeknya. CMMI merupakan model yang berisi praktek-praktek yang dapat digunakan oleh suatu organisasi untuk memperbaiki atau meningkatkan proses-proses dalam organisasi. Sedangkan CMMI-DEV berfokus pada pengembangan produk dan layanan berkualitas untuk memenuhi kebutuhan pelanggan dan pengguna. Kerangka GAPPS, PRINCE2, dan CMMI-DEV merupakan kerangka kerja dalam mengelola atau menjalankan suatu proyek. Sedangkan PMBOK Guide merupakan panduan yang sudah menjadi standar dalam mengelola proyek. Dari keempatnya dapat digunakan sebagai panduan dalam menjalankan atau mengelola suatu proyek, dan dapat digunakan sebagai acuan dalam merancang kerangka penilaian bagi pelaksana proyek. Karena dari keempatnya ada beberapa point yang sama yang menjadi standar dalam menjalankan proyek, seperti perencanaan, perkembanan proyek, pengendalian proyek, hubungan dengan stakeholder, perubahan dalam proyek, penerimaan pekerjaan, manajemen risiko, dan penyerahan proyek. Kerangka GAPPS dan PRINCE2 bersifat umum, namun dapat digunakan untuk proyek-proyek TI, sedangkan CMMI-DEV terdiri dari 22 area proses, ada kelompok area proses yang saling terhubung yang berkaitan dengan manajemen proyek yang dinamakan Basic Project Management Process Areas. Adapun PMBOK Guide,definisi-definis manajemen proyeknya telah menjadi standar bagi banyak organisasi. Dalam penelitian ini penulis akan menggunakan CMMI-DEV, selain karena fokus pada proses tertentu pada manajemen proyek perangkat lunak, juga karena pada CMMI-DEV disertakan contoh-contoh work product yang akan membantu dalam menilai hasil kegiatan dari penyedia. Dan pada CMMI terdapat metode penilaian yang sudah dapat digunakan yaitu SCAMPI. Sedangkan PMBOK Guide juga akan digunakan dalam melihat definisi-definisi dari manajemen proyek. 2.8 Penelitian Sebelumnya Pada penelitian ini penulis mencoba membandingkan dengan 4 (empat) penelitian sebelumnya, yaitu Haminullah (2011), Andrianto (2013), Nico (2013), dan

49 33 Husnul (2013). Keempatnya sama-sama melakukan penelitian pada perusahaan swasta. Haminullah (2011) melakukan penelitian terhadap produk Pharis yang dikembangkan oleh PT. Malloci Software Solution, dengan berfokus pada enam area proses, yaitu Requirement Management (REQM), Requirement Development (RD), Configuration Management (CM), Process and Product Qualitiy Assurance (PPQA), Technical Solution (TS), dan Verification (VER). Pemilihan area proses didasarkan pada rekomendasi Software Engineering Institute tentang Product Roadmap. Appraisal dilakukan dengan metode SCAMPI C dengan meneliti artefak langsung dari proyek Pharis. Haminullah (2011) juga melakukan analisa fishbone terhadap specific practice yang tidak terlaksana dan dicari sumber penyebabnya. Data lalu dioleh dengan diagram Pareto untuk mengetahui sumbersumber masalah mana yang memberi kontribusi terhadap 80% permasalahan yang terjadi. Rekomendasi diambil dari hasil analisa pareto. Penelitian Haminullah (2011) menghasilkan rekomendasi strategi menyelesaikan permasalahan, yaitu pembuatan prosedur, menambah jumlah SDM, memperbaiki sistem dokumentasi, dan melaksanakan pelatihan kepada karyawan terkait dengan SOP, metodologi, penggunaan alat bantu dan pengenalan CMMI-DEV. Andrianto (2013) melakukan penelitian terhadap masalah pada divisi EBS (Enterprise Bussiness Solution) PT. Sigma Metrasys Solution dengan menggunakan metode Software Process Improvement terpilih CMMI-DEV 1.2 pendekatan continuous. Proses pengukuran tingkat kemampuan (capability level) akan dilakukan menggunakan SCAMPI C dengan alat bantu PST Kneuper. Data yang akan dikumpulkan berdasarkan data-data dari beberapa area proses kerja terpilih dari CMMI Project Roadmap dimana ada 5 (lima) area proses kerja. Analisa data dilakukan dengan alat bantu PST untuk membantu menyimpulkan usulan perbaikan bagi proses, lalu akan digunakan juga AHP (Analitical Hierarchy Process) untuk menentukan prioritas perbaikan kepada PT. Sigma Metrasys Solution. Penelitian Andrianto (2013) menyimpulkan bahwa PT. Sigma Metrasys Solution telah menerapkan 4 dari 5 area proses kerja pada project roadmap sampai dengan capability level 1 performed. 2. Pada level 2 ada total

50 34 33 praktik yang sudah dijalankan dari total 52 praktik area proses kerja dijalankan. Ada sekitar 19 praktik yang belum dijalankan atau sekitar 36,54% lagi untuk menuju pada capability level 2. Seluruh praktik untuk mencapai capabilitiy level 3 Defined belum sepenuhnya dijalankan dengan baik, menandakan belum adanya praktik-praktik yang melibatkan jajaran manajemen di pusat. Nico (2013) melakukan penelitian terhadap permasalahan yang ada di PT. XYZ, yaitu klien, bugs yang ditemukan, sumber daya manusia, perlengkapan dan proses pengembangan. Penilaian menggunakan SCAMPI C dengan alat bantu PST Kneuper. Data yang dikumpulkan merupakan data-data dari beberapa area proses terpilih yang dapat membantu peningkatan kualitas produk dari PT. XYZ. Analisa data dilakukan dengan menggunakan alat PST. Penelitian Nico (2013) menghasilkan kesimpulan bahwa PT. XYZ sudah mengimplementasikan sebagian praktik dari CMMI-DEV 1.2 tetapi tidak satupun area proses yang terpenuhi. PT.XYZ masih pada level 0 atau incomplete. Dihasilkan 24 rekomendasi perbaikan untuk mencapai capability level 1dan 38 rekomendasi perbaikan untuk mencapai capability level 2, disimpulkan PT. XYZ masih kurang menerapkan kebijakan untuk mengontrol prosesnya. Diperlukan standarisasi dokumen pada setiap proyek. Adanya praktik yang tidak konsisten diimplementasikan karena tidak ada kebijakan yang mengatur. Terdapat masalah pada mitigasi risiko. Untuk mengadopsi CMMI-DEV PT. XYZ membutuhkan kebijakan dan proses baru dalam meningkatkan kendali dan kualitas dari prosesnya. Husnul (2013) melakukan penelitian terhadap tata kelola TI pada domain Delivey dan Service (DS) dari PT. Bursa Efek Indonesia. Penelitian dilakukan dengan melakukan assessment dari setiap proses di domain DS, menyusun rekomendasi perbaikan dari hasil assessment, melakukan risk assessment untuk melihat tingkat risiko jika rekomendasi perbaikan tidak dilakukan, melakukan validasi dari hasil rekomendasi dan penyusunan perbaikan SOP. Penelitian dilakukan dengan menggunakan Cobit dan ITIL versi 3. Penelitian Husnul (2013) menghasilkan rekomendasi untuk peningkatan nilai kemampanan tata kelola TI pada domain DS.

51 35 Tiga dari empat penelitian diatas menggunakan kerangka kerja CMMI-DEV Continuous dengan penilaian menggunakan SCAMPI C. Satu penelitian menggunakan Cobit dan ITIL versi 3. Tujuan dari penelitian yang menggunakan CMMI hampir sama yaitu menghasilkan strategi atau melakukan perbaikan terhadap proses pengembangan perangkat lunak. Sedangkan penelitian Husnul (2013) bertujuan melakukan perbaikan tingkat kemampanan tata kelola TI. Sedangkan penelitian ini yang memiliki tujuan menghasilkan model penilaian kapasitas teknis dalam memilih penyedia jasa konsultasi pengembang perangkat lunak di Kementerian Sekretariat Negara yang mengacu pada kerangka kerja CMMI-DEV. Rangkuman dari penelitian-penelitian sebelumnya dapat dilihat pada tabel 2.2 dibawah ini.

52 36 Tabel 2.2 Penelitian Sebelumnya Penelitian Sebelumnya Penelitian Kesimpulan Relevansi Perbedaan Haminullah Melakukan penelitian Pembuatan prosedur, Penelitian berdasarkan Penelitian dilakukan untuk (2011) terhadap permasalahan menambah jumlah SDM, kerangka kerja CMMI- menghasilkan strategi yang pada produk Pharis yang memperbaiki dokumentasi, dan DEV Continuous dengan digunakan untuk meningkatkan dikembangkan oleh PT. pelatihan karyawan terkait penilaian menggunakan kualitas proses pengembangan Malloci Software dengan SOP, metodologi, metode SCAMPI C. peranti lunak. Solution penggunaan alat bantu dan pengenalan CMMI-DEV. Andrianto Penelitian di lakukan Telah menerapkan 4 dari 5 area Penelitian berdasarkan Penelitian dilakukan untuk (2013) terhadap masalah pada proses pada capability level 1, kerangka kerja CMMI- melakukan perbaikan kualitas divisi EBS (Enterprise pada level 2 ada 33 dari 52 area DEV Continuous dengan proses pengembangan Bussiness Solution) PT. proses, dan pada level 3 belum penilaian menggunakan perangkat lunak. Sigma Metrasys sepenuhnya. metode SCAMPI C. Solution.

53 37 Tabel 2.2 Penelitian Sebelumnya (lanjutan) Penelitian Sebelumnya Topik Kesimpulan Relevansi Perbedaan Nico Baruna Penelitian dilakukan PT. XYZ sudah Penelitian berdasarkan Penelitian dilakukan untuk Putra (2013) terhadap permasalahan mengimplementasikan sebagian kerangka kerja CMMI- memprebaiki proses yang ada di PT. XYZ, praktik dari CMMI-DEV 1.2 DEV Continuous dengan pengembangan perangkat lunak yaitu klien, bugs yang tetapi tidak satupun area proses penilaian menggunakan untuk meningkatkan kualitas ditemukan, sumber daya yang terpenuhi. PT.XYZ masih metode SCAMPI C. produk pada PT.XYZ. manusia, perlengkapan pada level 0 atau incomplete. dan proses Pada penelitian ini metode pengembangan.

54 38 Tabel 2.2 Penelitian Sebelumnya (lanjutan) Penelitian Sebelumnya Topik Kesimpulan Relevansi Perbedaan Husnul Penelitian dilakukan Domain DS pada PT. Penelitian dikukan dengan Penelitian dilakukan untuk Hidayat (2013) terhadap tata kelola TI Bursa Efek Indonesia melakukan assessment memprebaiki nilai kemapanan pada domain Delivey dan memilki tingkat terhadap barang bukti yang tata kelola TI pada domain DS Service (DS) dari PT. kemapanan (maturity level) dinilai. di PT.BEI. Bursa Efek Indonesia tata kelola TI dengan nilai 3.5. Penelitian merekomendasikan perbaikan pada maturity attribute yang memiliki nilai maturity level dibawah 4.

55 Theoretical Framework Dalam menentukan model penilaian terhadap proses pengembangan perangkat lunak, maka pada penelitian ini dibuat suatu theoretical framework. Pada theoretical framework ini, pemahaman dasar perangkat lunak dan proses pengembangan dasar perangkat lunak diambil dari Sommerville (2007). Penelitian ini memakai kerangka kerja dari CMMI for Development Version 1.3 dari Software Engineering Institute (2010), dengan representasi Continuous. Dengan fokus area proses Requirements Management (REQM), Project Planning (PP), Project Monitoring And Control (PMC), dan Supplier Agreement Management (SAM). Area-area proses ini dipilih disesuaikan dengan permasalahan pengembangan perangkat lunak yang melibatkan penyedia jasa konsultasi yang pernah ada. Karena area proses yang diteliti atau dinilai berkaitan dengan project management, maka penelitian ini akan memperhatikan pembahasan atau apa-apa saja yang menjadi bagian dari project management dari Marchewka (2010). Area proses yang dipilih akan dinilai dengan menggunakan metode SCAMPI C. Hasil penilaian dengan SCAMPI C terhadap perusahaanperusahaan penyedia akan diambil rata-rata untuk mengetahui rata-rata kapasitas penyedia pada tahun ini. Hasil penilaian juga digunakan sebagai bahan dalam menyusun rekomendasi penilaian kapasitaspenyedia pada pemilihan penyedia jasa konsultasi. Rangkuman theoretical framework pada penelitian ini dapat dilihat pada gambar 2.8 dibawah ini. Gambar 2.3 Theoretical Framework

56 40 BAB 3 METODOLOGI PENELITIAN 3.1 Tahapan Penelitian Berikut ini adalah tahapan-tahapan yang dilakukan dalam penelitian ini : a. Penelitian diawali dengan merumuskan masalah-masalah yang terkait dengan proses pengembangan perangkat lunak yang akan diteliti untuk menemukan pertanyaan penelitian. Dari masalah kemudian dirumuskan tujuan dan manfaat penelitian; b. Melakukan studi literatur terhadap teori dan metode-metode yang berhubungan dengan permasalahan yang ada. Studi literatur akan menghasilkan theoritical framerwork; c. Mengembangkan metodologi penelitian dengan menentukan langkahlangkah penelitian, sehingga dapat dirancang output dari tiap-tiap langkah. Selain itu juga mengidentifikasi metode pengumpulan data, metode analisis, serta metode dalam membuat kesimpulan. Tahap ini akan menghasilkan metodologi penelitian; d. Mengumpulkan data primer dan data sekunder. Pengumpulan data primer dilakukan melalui proses wawancara dengan pihak-pihak yang terkait dengan penelitian, dan penilaian terhadap penyedia-penyedia jasa konsultasi dengan yang mengacu pada CMMI-Dev dan menggunakan metode penilaian SCAMPI C. Data sekunder didapat melalui pengumpulan dokumen-dokumen kerja penyedia yang terkait dengan pekerjaan yang dilakukan di Kementerian Sekretariat Negara. Tahap ini akan dihasilkan prediksi nilai kapasitas dari penyedia yang dinilai; e. Melakukan verifikasi kebutuhan praktek-praktek yang akan menjadi bahan penilaian panitia dan pemeriksa lelang pada kerangka penilaian kapasitas penyedia. Verifikasi berfokus pada proses kegiatan terkait proyek untuk memastikan produk sesuai dengan kebutuhan (Marchewka, 2010).Tahap 40

57 41 ini akan menghasilkan data kebutuhan praktek-praktek yang menjadi bahan kerangka penilaian kapasitas penyedia; f. Melakukan analisis keterhubungan data masalah, data hasil penilaian terhadap penyedia, dan data hasil verifikasi. Tahap ini akan menghasilkan rekomendasi nilai minimal yang masuk pada kerangka penilaian kapasitas penyedia. g. Melakukan pembuatan kerangka penilaian berdasarkan teori yang menjadi dasar penilaian dan data-data penelitian yang telah terkumpul dan telah teranalisis. Perumusan kerangka penilaian kapasitas penyedia akan disesuaikan dengan mekanisme pengadaan yang berlaku dan disesuaikan dengan kebutuhan dan keadaan Kementerian Sekretariat Negara saat ini. Setelah kerangka penilaian kapasitas penyedia dapat dibangun, kerangka penilaian di validasi ke pejabat yang bertanggung jawab terhadap kebijakan pembangunan dan pengembangan perangkat lunak di Kementerian Sekretariat Negara. Kegiatan validasi berorientasi pada produk, untuk memastikan bahwa produk sesuai dengan kebutuhan. Validasi dilakukan menjelang akhir proyek atau setelah produk jadi (Marchewka, 2010). Pada tahap ini akan dihasilkan rekomendasi penilaian kapasitas penyedia yang digunakan untuk pemilihan penyedia jasa konsultasi; h. Membuat kesimpulan dan saran perbaikan penilaian pemilihan penyedia jasa konsultasi. Ringkasan tahapan penelitian dapat dilihat pada gambar 3.1 dibawah.

58 42 Gambar 3.1 Tahapan Penelitian 3.2 Metode Pengumpulan Data Pengumpulan data dan informasi sebagai bahan penelitian dilakukan dengan cara: a. Wawancara dengan pihak-pihak yang terkait dengan penelitian, pihak yang mempunyai kapasitas dalam mewakili proyek yang sedang

59 43 dilaksanakan. Wawancara juga dilakukan terhadap pejabat penanggung jawab proyek dan pengguna. b. Penilaian dilakukan terhadap penyedia jasa konsultasi yang mengerjakan proyek pengembangan perangkat lunak pada tahun c. Observasi secara langsung ke lapangan untuk mengamati proses pengembangan yang terjadi dalam organisasi; d. Data sekunder didapat melalui pengumpulan dokumen kerja dari unit kerja terkait yang bertanggung jawab terhadap proyek maupun penyedia jasa konsultasi. 3.3 Metode Analisis Data Setelah mendapatkan data penelitian maka dilakukan analisis dan perumusan penilaian yang disesuaikan dengan mekanisme pengadaan yang berlaku dan disesuaikan dengan kebutuhan dan keadaan Kementerian Sekretariat Negara saat ini. Penyusunan penilaian akan mengacu pada CMMI-DEV, hal ini terinspirasi dari apa yang dilakukan Departemen Pertahanan Amerika dalam melakukan pemilihan penyedia yang merupakan asal mula hadirnya CMMI itu sendiri. Untuk penilaian digunakan metode penilaian SCAMPI C.

60 44 BAB 4 PROFILE ORGANISASI 4.1 Kementerian Sekretariat Negara Sekretariat Negara yang berdiri pada taggal 2 September 1945, pada awalnya merupakan sebuah lembaga yang sederhana. Ketika pertama berdiri Sekretariat Negara bukanlah sebuah kementerian atau depantemen, tetapi menjadi bagian dalam struktur kabitnet. Dalam perjalanan sejarahnya, Sekretariat Negara mengalami beberapa kali perubahan, baik tugas pokok, fungsi, kedudukan, maupun struktur kelembagaannya. Perubahan itu sangat dipengaruhi oleh situasi politik yang terjadi di tanah air. Awalnya, Sekretariat Negara hanya berfungsi untuk membantu tugas-tugas administrasi kepresidenan. Seiring dengan dinamika perkembangan pemerintahan Republik Indonesia, kini Sekretariat Negara (Kementerian Sekretarait Negara) telah menjadi lembaga yang besar dan kompleks serta memiliki peran dan kedudukan yang penting dan strategis, lembaga yang memberikan dukungan teknis dan administrasi serta analisis kepada Prediden dan Wakil Presiden. Organisasi Kementerian Sekretariat Negara yang berlaku saat ini ditetapkan berdasarkan Peraturan Presiden Republik Indonesia Nomor 58 Tahun 2010 tentang Kementerian Sekretariat Negara, dan Peraturan Menteri Sekretaris Negara Republik Indonesia Nomor 2 Tahun 2011 tentang organisasi dan tata kerja Kementerian Sekretariat Negara. Visi Kementerian Sekretariat Negara adalah sebagai berikut: Terwujudnya Kementerian Sekretariat Negara yang profesional, transparan, dan akuntabel dalam rangka memberikan pelayanan prima kepada Presiden dan Wakil Presiden. Dalam rangka mewujudkan Kementerian Sekretariat Negara ditetapkan misi Kementerian Sekretariat Negara sebagai berikut: 44

61 45 Memberikan dukungan pelayanan teknis dan administrasi yang prima kepada Presiden dan Wakil Presiden dalam pengambilan kebijakan penyelenggaraaan kekuasaan negara; Memberikan pelayanan kerumahtanggaan dan keprotokolan yang optimal kepada Presiden dan Wakil Presiden; Memberikan dukungan teknis dan administrasi secara efektif kepada Presiden dalam menyelenggarakan kekuasaan tertinggi atas Angkatan Darat, Angkatan Laut, dan Angkatan Udara; Menyelenggarakan pelayanan yang efektif dan efisien di bidang pengawasan, administrasi umum, informasi, dan hubungan kelembagaan; Meningkatkan kualitas sumber daya manusia dan prasarana Kementerian Sekretariat Negara Kedudukan, Tugas dan Fungsi Kementerian Sekretariat Negara Kedudukan, tugas dan fungsi Kementerian Sekretariat Negara berdasarkan Peraturan Presiden Nomor 58 Tahun 2010 tentang Kementerian Sekretariat Negara, sebagaimana telah diubah dengan Peraturan Presiden Nomor 80 Tahun 2010, adalah sebagai berikut: a. Kedudukan Kementerian Sekretariat Negara dipimpin oleh Menteri Sekretaris berada di bawah dan bertanggung jawab kepada Presiden. b. Tugas Kementerian Sekretariat Negara mempunyai tugas memberikan dukungan teknis dan administrasi serta analisis kepada Presiden dan Wakil Presiden dalam menyelenggarakan kekuasaan negara. c. Fungsi Dalam melaksanakan tugas tersebut, Kementerian Sekretariat Negara menyelenggarakan fungsi: i. Pemberian dukungan data, informasi, dan analisis dalam rangka pengambilan kebijakan di bidang politik, hukum, keamanan, perekonomian, dan kesejahteraan rakyat;

62 46 ii. Pemberian dukungan teknis dan administrasi serta analisis dalam rangka penyiapan izin prakarsa dan penyelesaian Rancangan Undang-Undang, Rancangan Peraturan Pemerintah Pengganti Undang-Undang, dan Rancangan Peraturan Pemerintah, serta pemberian pertimbangan kepada Sekretaris Kabinet dalam penyusunan Rancangan Peraturan Presiden, penyiapan pendapat hukum, serta penyelesaian Rancangan Keputusan Presiden tentang pemberian grasi, amnesti, abolisi, rehabililitasi, ekstradisi, remisi perubahan dari pidana penjara seumur hidup menjadi pidana sementara, dan naturalisasi; iii. Pemberian dukungan teknis dan administrasi kerumahtanggaan, keprotokolan, pers, dan media kepada Presiden dan Wakil Presiden; iv. Penyiapan naskah-naskah bagi Presiden dan Wakil Presiden; v. Pemberian dukungan teknis dan administrasi kepada Presiden dalam menyelenggarakan kekuasaan tertinggi atas Angkatan Darat, Angkatan Laut, dan Angkatan Udara, dalam hal pengangkatan dan pemberhentian perwira TNI dan Polri, penganugerahan gelar, tanda jasa dan tanda kehormatan, yang wewenang penetapannya berada pada Presiden, serta koordinasi pengamanan Presiden dan Wakil Presiden; vi. Pemberian dukungan teknis dan administrasi serta analisis dalam penyelenggaraan administrasi pejabat negara dan pejabat lainnya yang dalam proses penetapannya memerlukan pertimbangan Dewan Perwakilan Rakyat atau pejabat yang kedudukannya disetarakan dengan Menteri Negara, yang wewenang penetapannya berada pada Presiden; vii. Pemberian dukungan teknis dan administrasi serta analisis dalam penyelenggaraan hubungan dengan lembaga negara, lembaga daerah, lembaga non struktural, organisasi politik, lembaga swadaya masyarakat, dan organisasi kemasyarakatan, serta penanganan pengaduan masyarakat; viii. Penyelenggaraan koordinasi pelaksanaan kerja sama teknik antara pemerintah Indonesia dengan pihak luar negeri; ix. Penyelenggaraan pembinaan dan pengembangan sumber daya manusia serta penataan organisasi dan tata laksana di lingkungan Kementerian Sekretariat Negara;

63 47 x. Pengembangan sistem akuntabilitas kinerja di lingkungan Kementerian Sekretariat Negara; xi. Penyelenggaraan pelayanan dan dukungan perencanaan, pengelolaan keuangan, ketatausahaan, kehumasan, teknologi informasi, pengelolaan barang milik/kekayaan negara yang menjadi tanggung jawab Kementerian Sekretariat Negara, penyediaan prasarana dan sarana, serta administrasi umum lainnya di lingkungan Kementerian Sekretariat Negara; xii. Pengawasan atas pelaksanaan tugas di lingkungan Kementerian Sekretariat Negara; dan xiii. Pelaksanaan fungsi-fungsi lain yang diberikan oleh Presiden dan Wakil Presiden serta oleh peraturan perundang-undangan Struktur Organisasi Kementerian Sekretariat Negara Berdasarkan Peraturan Presiden Nomor 58 Tahun 2010 tentang Kementerian Sekretariat Negara, sebagaimana telah diubah dengan Peraturan Presiden Nomor 80 Tahun 2010, struktur organisasi Kementerian Sekretariat Negara sebagai berikut:

64 48 Gambar 4.1 Struktur Organisasi Kementerian Sekretariat Negara Sumber: Permensesneg Nomor 2 Tahun 2011 Kementerian Sekretariat Negara terdiri atas: a. Sekretariat Presiden; b. Sekretariat Wakil Presiden; c. Sekretariat Militer Presiden; d. Sekretariat Kementerian; e. Deputi Bidang Dukungan Kebijakan; f. Deputi Bidang Sumber Daya Manusia; g. Deputi Bidang Hubungan Kelembagaan dan Kemasyarakatan; h. Deputi Bidang Perundang-undangan; i. Staf Ahli Bidang Politik, Pertahanan dan Keamanan; j. Staf Ahli Bidang Hukum, dan Hak Asasi Manusia; k. Staf Ahli Bidang Ekonomi dan Kesejahteraan Rakyat; l. Staf Ahli Bidang Komunikasi dan Informatika; dan m. Staf Ahli Bidang Aparatur Negara dan Otonomi Daerah.

65 49 A. Sekretariat Presiden Sekretariat Presiden berada di bawah dan bertanggung jawab kepada Menteri Sekretaris Negara. Sekretariat Presiden dipimpin oleh Kepala Sekretariat Presiden. Dalam melaksanakan tugasnya Kepala Sekretariat Presiden dapat menerima penugasan langsung dari Presiden. Sekretariat Presiden mempunyai tugas menyelenggarakan pemberian dukungan teknis dan administrasi kerumahtanggaan, keprotokolan, pers, dan media kepada Presiden. B. Sekretariat Wakil Presiden Sekretariat Wakil Presiden berada di bawah dan bertanggung jawab kepada Menteri Sekretaris Negara. Sekretariat Wakil Presiden dipimpin oleh Sekretaris Wakil Presiden. Dalam melaksanakan tugasnya Sekretaris Wakil Presiden dapat menerima penugasan langsung dari Wakil Presiden. Sekretariat Wakil Presiden mempunyai tugas menyelenggarakan pemberian dukungan teknis dan administrasi kerumahtanggaan dan keprotokolan kepada Wakil Presiden, serta analisis dalam rangka pengambilan kebijakan Wakil Presiden dalam penyelenggaraan pemerintahan dan pembangunan. C. Sekretariat Militer Presiden Sekretariat Militer Presiden berada di bawah dan bertanggung jawab kepada Menteri Sekretaris Negara. Sekretariat Militer Presiden dipimpin oleh Sekretaris Militer Presiden. Sekretaris Militer Presiden karena jabatannya melaksanakan tugas sebagai Sekretaris Dewan Gelar, Tanda Jasa, dan Tanda Kehormatan. Dalam melaksanakan tugasnya Sekretaris Militer Presiden dapat menerima penugasan langsung dari Presiden. Sekretariat Militer Presiden mempunyai tugas menyelenggarakan pemberian dukungan teknis dan administrasi kepada Presiden dalam menyelenggarakan kekuasaan tertinggi atas Angkatan Darat, Angkatan Laut, dan Angkatan Udara, dalam hal pengangkatan dan pemberhentian perwira Tentara Nasional Indonesia (TNI) dan Kepolisian Negara Republik Indonesia (Polri), penganugerahan gelar, tanda jasa dan tanda kehormatan yang wewenangnya berada pada Presiden, serta koordinasi pengamanan Presiden dan Wakil Presiden.

66 50 D. Sekretariat Kementerian Sekretariat Kementerian berada di bawah dan bertanggung jawab kepada Menteri Sekretaris Negara. Sekretariat Kementerian dipimpin oleh Sekretaris Kementerian. Sekretariat Kementerian mempunyai tugas membantu Menteri Sekretaris Negara dalam menyelenggarakan pemberian dukungan teknis dan administrasi di bidang perencanaan program dan anggaran, administrasi keuangan, perlengkapan, pengelolaan barang milik/kekayaan negara, ketatausahaan, hubungan masyarakat, koordinasi kerja sama teknik luar negeri, dan urusan kerumahtanggaan di lingkungan Kementerian Sekretariat Negara. E. Deputi Bidang Dukungan Kebijakan Deputi Bidang Dukungan Kebijakan berada di bawah dan bertanggung jawab kepada Menteri Sekretaris Negara. Deputi Bidang Dukungan Kebijakan dipimpin oleh Deputi. Deputi Bidang Dukungan Kebijakan mempunyai tugas membantu Menteri Sekretaris Negara dalam pemberian dukungan teknis dan administrasi, serta analisis dalam rangka pengambilan kebijakan dalam negeri dan hubungan internasional, serta penyiapan naskah kepresidenan dan kenegaraan, penerjemahan, dan pengelolaan informatika di lingkungan Kementerian Sekretariat Negara. F. Deputi Bidang Sumber Daya Manusia Deputi Bidang Sumber Daya Manusia berada di bawah dan bertanggung jawab kepada Menteri Sekretaris Negara. Deputi Bidang Sumber Daya Manusia dipimpin oleh Deputi. Deputi Bidang Sumber Daya Manusia mempunyai tugas membantu Menteri Sekretaris Negara dalam pemberian dukungan teknis dan administrasi serta analisis dalam pengangkatan, pemberhentian, dan pensiun pejabat negara dan pejabat lainnya yang proses penetapannya memerlukan pertimbangan Dewan Perwakilan Rakyat (DPR) atau pejabat yang kedudukannya disetarakan dengan Menteri Negara, yang wewenangnya berada pada Presiden, serta pembinaan dan pengembangan sumber daya manusia, penataan organisasi dan tata laksana, dan pengembangan akuntabilitas kinerja di lingkungan Kementerian Sekretariat Negara.

67 51 G. Deputi Bidang Hubungan Kelembagaan dan Kemasyarakatan Deputi Bidang Hubungan Kelembagaan dan Kemasyarakatan berada di bawah dan bertanggung jawab kepada Menteri Sekretaris Negara. Deputi Bidang Hubungan Kelembagaan dan Kemasyarakatan dipimpin oleh Deputi. Deputi Bidang Hubungan Kelembagaan dan Kemasyarakatan mempunyai tugas membantu Menteri Sekretaris Negara dalam pemberian dukungan teknis dan administrasi serta analisis kepada Presiden/Wakil Presiden dalam rangka menyelenggarakan hubungan dengan lembaga-lembaga negara, lembaga daerah, lembaga non struktural, organisasi politik, lembaga swadaya masyarakat, dan organisasi kemasyarakatan, serta penanganan pengaduan masyarakat. H. Deputi Bidang Perundang-undangan Deputi Bidang Perundang-undangan berada di bawah dan bertanggung jawab kepada Menteri Sekretaris Negara. Deputi Bidang Perundang-undangan dipimpin oleh Deputi. Deputi Bidang Perundang-undangan mempunyai tugas membantu Menteri Sekretaris Negara dalam menyelenggarakan pemberian dukungan teknis dan administrasi serta analisis dalam rangka penyiapan izin prakarsa dan penyelesaian Rancangan Undang-Undang, Rancangan Peraturan Pemerintah Pengganti Undang-Undang, dan Rancangan Peraturan Pemerintah, pemberian pertimbangan kepada Sekretaris Kabinet dalam penyusunan Rancangan Peraturan Presiden, penyiapan pendapat hukum, serta penyelesaian Rancangan Keputusan Presiden tentang pemberian grasi, amnesti, abolisi, rehabililitasi, ekstradisi, remisi perubahan dari pidana penjara seumur hidup menjadi pidana sementara, dan naturalisasi. I. Staf Ahli Staf Ahli berada di bawah dan bertanggung jawab kepada Menteri Sekretaris Negara dan secara administratif dikoordinasikan oleh Sekretaris Kementerian Sekretariat Negara. Pembagian tugas Staf Ahli dibagi menurut bidang-bidang seperti penjelasan dibawah ini:

68 52 a. Staf Ahli Bidang Politik, Pertahanan dan Keamanan mempunyai tugas memberikan telaahan kepada Menteri Sekretaris Negara mengenai masalah politik, pertahanan, dan keamanan. b. Staf Ahli Bidang Hukum, dan Hak Asasi Manusia mempunyai tugas memberikan telaahan kepada Menteri Sekretaris Negara mengenai masalah hukum dan hak asasi manusia. c. Staf Ahli Bidang Ekonomi dan Kesejahteraan Rakyat mempunyai tugas memberikan telaahan kepada Menteri Sekretaris Negara mengenai masalah ekonomi dan kesejahteraan rakyat. d. Staf Ahli Bidang Komunikasi dan Informatika mempunyai tugas memberikan telaahan kepada Menteri Sekretaris Negara mengenai masalah komunikasi dan informatika. e. Staf Ahli Bidang Aparatur Negara dan Otonomi Daerah mempunyai tugas memberikan telaahan kepada Menteri Sekretaris Negara mengenai masalah aparatur negara dan otonomi daerah. 4.2 PT. Belant Persada PT. Belant Persada merupakan sebuah perusahaan konsultan Teknologi Informasi yang didirikan pada tahun 2001 oleh tim IT Profesional untuk memberikan solusi sistem dan teknologi informasi yang terintegrasi bagi komunitas bisnis. Fokus usaha adalah memberikan solusi dengan pendekatan Cost Effective Solution bagi berbagai latar belakang industri dan pemerintahan. Termasuk dalam solusi yang ditawarkan adalah pembangunan, pengembangan dan penyempurnaan sistem, integrasi sistem, service provider telekomunikasi, dan infrastruktur Data Center. Belant berkomitmen untuk dapat membantu kliennya agar dapat berkonsentrasi pada bisnis inti melalui bantuan penanganan Pengembangan dan Pemeliharaan Sistem Informasinya, sehingga mampu menghasilkan informasi yang akurat serta dapat terintegrasi dengan sistem lain.

69 53 Visi PT. Belant Persada adalah Menjadi partner IT Solution yang terpercaya, strategis, dan inovatif yang membantu dalam mencapai keseluruhan efektifitas bisnis dan kesuksesan bersama Misi PT. Belant Persada adalah Meningkatkan nilai perusahaan dan portofolio dari produk dan solusi secara lebih rinci dengan melampaui harapan pelanggan dan menjadi market leader serta beroperasi secara unggul di setiap segmen perusahaan 4.3 PT. Malloci Software Solution PT. Malloci Software Solution didirikan pada tanggal 18 Maret 2009 di Jakarta. Fokus utama bisnis Malloci adalah pada layanan pengembangan system informasi dalam mendukung operasi dan strategi bisnis pelanggan. Sebagai perusahaan yang baru berdiri, Malloci saat ini memfokuskan diri dalam menata dan meningkatkan proses pengembangan piranti lunak dan pengembangan sumber daya manusia yang unggul. Dalam kualitas perangkat lunak yang dihasilkan, Malloci berusaha untuk mengadopsi praktik-praktik terbaik dalam proses pengembangan piranti lunak secara bertahap sehingga mencapai kapabilitas dan level kematangan yang diakui secara nasional maupun internasional. Visi PT.Malloci Software Solution adalah Menjadi perusahaan pengembang piranti lunak terkemuka di Indonesia Sedangkan misinya adalah - Menyediakan layanan pengembangan piranti lunak yang mampu memberikan solusi bagi pelanggan dalam mewujudkan strategi bisnisnya. - Menghasilkan piranti lunak berqualitas tinggi melalui penerapan praktik-praktik terbaik dalam proses pengembangan produk serta dukungan SDM yang unggul.

70 Produk Berbagai produk piranti lunak telah dihasilkan oleh Malloci, baik sebelum ataupun sesudah resmi menjadi perseroan. Produk-produk yang telah dihasilkan antara lain: - SMS Gateway SMS Gateway adalah solusi pemanfaatan Short Message Service (SMS) dalam memberikan layanan nilai tambah terhadap bisnis pelanggan. Berbagai pemanfaatan SMS Gateway antara lain: Info on Demand, SMS Broadcast,dll. - e-payment e-payment adalah solusi sistem pembayaran secara online melalui media internet. Dengan semakin berkembangnya transaksi elektronik saat ini, e-payment menjadi salah satu solusi dalam menyediakan layanan pembayaran elektronik di samping system pembayaran yang sudah ada seperti PayPal, Credit Card, dll. - e- Voucher e-voucher merupakan aplikasi penjualan pulsa elektronik yang menggabungkan sistem isi ulang beberapa operator telekomunikasi di Indonesia ke dalam suatu sistem terintegrasi. Dengan pengabungan ini, seorang dealer bisa melakukan penjualan pulsa elektronik multi operator melalui media SMS, Yahoo Messenger, Host to Host, dan aplikasi berbaris Web. Saat ini, system e-voucher juga sudah dilengkapi dengan aplikasi pembayaran jasa telekomunikasi seperti pembayaran PSTN, Telkom Flexi Postpaid, Speedy, dan lain-lain. - Interactive Kiosk Application Interactive Kiosk Application memberikan layanan interaktif kepada pelanggan melalui mesin-mesin kiosk. Aplikasi ini menawarkan layanan dengan konsep self service kepada pelanggan. Layanan-layanan yang disediakan antara lain: layanan pembayaran, penjualan secara fisik dan elektronik, informasi produk, iklan, dan lain-lain.

71 55 - Malloci Track Malloci Track adalah aplikasi pemantauan posisi kendaraan atau objek lain dengan menggabungkan antara teknologi GSM (Global System for Mobile Communication), GPS (Global Positioning System) dan Google Map. Aplikasi ini memungkinkan Kita mengetahui posisi ( longitude dan latitude ) saat ini dan posisi di masa lalu suatu objek. - Sistem Informasi Apotek Sistem Informasi Apotek ditujukan untuk menunjang operasional apotek sehingga pelayanan apotek bisa semakin meningkat. Bagi pemilik sarana apotek, aplikasi ini sangat berguna dalam memantau laporan pembelian, penjualan, kondisi stok barang-barang apotek, serta absensi dan kegiatan karyawan. Sistem Informasi Apotek memiliki modul untuk melakukan penjualan, pembelian (pembuatan PO, penerimaan barang, dan pembayaran pemasok), manajemen pelanggan, manajemen pemasok, manajemen produk, stock opname, dan laporan-laporan. - Sistem Informasi Lab Klinik Sistem informasi Lab Klinik dirancang sesuai dengan alur proses standar ISO untuk manajemen Lab Klinik. Aplikasi ini diharapkan bisa menyelaraskan antara proses bisnis pelanggan dengan standar ISO sehingga mutu layanan bisa terus terjaga dengan baik. Aplikasi ini juga mendukung integrasi dengan instrument-instrumen Lab mutakhir seperti instrument dari Sysmex, Cobas, Hitachi, dll. - Volume Compare Application Volume Compare Application (VCA) adalah aplikasi yang bertujuan untuk melakukan komparasi antara dua file CDR (Call Detail Record) dari dua operator telekomunikasi berdasarkan kriteria-kriteria tertentu yang diberikan, seperti Start Time, Duration, A# dan B#. Hasil komparasi akan disimpan dalam database untuk pengolahan lebih lanjut.

72 Layanan Malloci menyediakan layanan konsultasi, perancangan, dan pengembangan piranti lunak berdasarkan kebutuhan spesifik pelanggan. Layanan Malloci meliputi pengembangan produk baru atau penyesuaian produk-produk lama yang sebelumnya telah dikembangkan dengan proses bisnis pelanggan. Malloci memberikan layanan purna jual gratis selama periode tertentu seperti upgrade, pemeliharaan dan perbaikan. Malloci juga menyediakan layanan tambahan berupa pengembangan IT Master Plan serta pengadaan infrastruktur TI pelanggan. Malloci berkomitmen untuk memberikan layanan terbaik bagi pelanggan melalui dukungan sumber daya manusia yang professional serta penerapan praktik-praktik terbaik dalam proses pengembangan piranti lunak. 4.4 CV. Torche Indonesia CV. Torche Indonesia merupakan perusahaan penyedia solusi teknologi informasi, berbasis di Bandung yang dipelopori oleh beberapa alumni ITB. Sebagai sebuah entitas bisnis Torche Indonesia dimulai sejak tahun Seiring dengan perkembangan dan kepercayaan dari berbagai pihak maka kemudian entitas bisnis tersebut disahkan secara hukum menjadi CV. Torche Indonesia pada tanggal 18 September CV. Torche Indonesia fokus menjalankan usahanya pada desain, pembangunan dan implementasi Information system yang berbasis kepada penggunaan media teknologi informasi (TI). Dalam perkembangan dunia teknologi informasi, inovasi dan invention menjadi karakter yang sangat lekat. Demikian pula penguasaan akan proven technology (teknologi yang telah dipergunakan & teruji) juga menjadi sangat penting. Sebagai konsultan di bidang teknologi informasi, CV. Torche Indonesia mencoba meramu kompetensi-kompetensi itu untuk menjadi karakter utama, yaitu sebagai konsultan yang kaya akan inovasi dan invention serta mantap dalam penguasaan akan proven technology.

73 57 Dalam memberikan jasa pelayanan kepada klien, CV. Torche Indonesia yakin bahwa: No two companies are exactly the same. Penerapan sistem informasi di perusahaan dan institusi manapun tetaplah harus selalu berdasar kepada empat domain utama, yaitu: (1) Data; (2) Sumber Daya Manusia; (3) Proses; (4) Teknologi Informasi yang meliputi hardware, software, network, dan telekomunikasi. Sehingga dalam menawarkan solusi, CV. Torche Indonesia selalu berpegangan kepada empat domain yang saling terkait agar dapat memberikan nilai tambah yang signifikan kepada organisasi yang menggunakan jasa maupun produk yang ditawarkan. Atas dasar hal tersebut, dalam menghantarkan sebuah solusi sistem informasi, CV. Torche Indonesia selalu mengawali dengan proses studi terkait dengan data, sumber daya manusia, proses serta teknologi informasi yang telah dimiliki oleh organisasi saat ini, sehingga dapat dikembangkan sebuah solusi yang dapat memberdayakan secara maksimal sumber daya yang telah dimiliki oleh organisasi tersebut. Pengalaman-pengalaman dalam mengembangkan sebuah sistem informasi menjadi modal dari tim CV. Torche Indonesia dalam mengukur risiko teknis dan non teknis yang harus dikelola dalam proses pengembangan sebuah sistem informasi. CV. Torche Indonesia melibatkan pengguna sistem secara aktif dalam proses pengembangan sehingga diharapkan terjadi knowledge transfer yang dapat membuat pengguna dapat mengelola sistem yang dimilikinya secara mandiri. CV. Torche Indonesia didukung oleh tim yang memiliki kapasitas, kompetensi serta karakter yang sesuai dengan business nature pengembangan solusi bisnis berbasis teknologi informasi Produk dan Jasa yang ditawarkan oleh CV. Torche Indonesia adalah : 1. Web design and development, yaitu jasa desain, konsultansi, analisis, pengembangan, dan implementasi aplikasi berbasis web 2. Network Design and Development, yaitu jasa desain, konsultansi, analisis, pengembangan, dan implementasi jaringan, baik LAN maupun WAN.

74 58 3. System Integrator, yaitu jasa desain, konsultansi, analisis, pengembangan, dan implementasi sistem informasi yang menggunakan multimedia (multi hardware) dan aplikasi multiplatform sehingga membutuhkan integrasi. 4. Custom Software Design & development, yaitu jasa desain, konsultansi, analisis, pengembangan dan implementasi aplikasi yang spesifik sesuai dengan kebutuhan pengguna. 5. Reporting, Data Mining, & data Integration, yaitu jasa untuk membuat laporan analisis (business intelligence) yang terkait dengan ETL dan data warehousing dan representasi laporan yang dibutuhkan. 6. Mobile Application design & development, yaitu jasa desain,konsultansi, analisis, pengembangan dan implementasi mobile application, dimana client menggunakan HW mobile seperti Smart Phone, PDA, atau Mobile Phone 7. IS Maintenance & Deskktop Support, yaitu jasa pemeliharaan sistem informasi terkait dengan disaster recovery, performance tuning maupun berupa desktop support.

75 BAB 5 ANALISA DAN PEMBAHASAN 5.1 Pemilihan Proyek Proyek yang akan dinilai adalah proyek-proyek pembangunan perangkat lunak milik Kementerian Sekretariat Negara pada tahun Proyek-proyek ini dikerjakan oleh para penyedia jasa konsultasi yang telah terpilih pada proses lelang. Pada tahun 2013 terdapat tiga proyek pengembangan perangkat lunak, ketiga proyek tersebut Pembangunan Aplikasi Sistem Informasi Poliklinik, Pembangunan Aplikasi Sistem Pengendalian Persediaan Barang, dan Pembangunan Aplikasi Sistem Monitoring Masa Berlaku Surat Tanda Nomor Kendaraan (STNK). Semua proyek ditujukan untuk mendukung kinerja dari beberapa bagian di Biro Umum Sekretariat Kementerian Sekretarait Negara, yaitu Bagian Pelayanan Kesehatan, Bagian Perlengkapan dan Rumah Tangga, dan Bagian Perlengkapan dan Rumah Tangga. Ketiga proyek ini dilaksanakan pada tahun 2013 sebagai tindak lanjut dari permintaan unit kerja terkait akan kebutuhan dukungan aplikasi dan hasil analisa unit kerja TI di Kementerian Sekretariat Negara. Proyek-proyek ini ditargetkan selesai antara akhir November dan awal Desember tahun 2013, sehingga proyek ini pada tahun 2014 dapat digunakan dalam meningkatkan pelayanan dan mendukung pekerjaan dari unit kerja terkait. Berikut ini rangkuman penjelasan mengenai proyek-proyek yang akan dinilai: a. Pembangunan Aplikasi Sistem Informasi Poliklinik Nama proyek Pembangunan Aplikasi Sistem Informasi Poliklinik (Proyek 1) Jangka waktu 120 (seratus dua puluh) hari kalender Penyedia PT. Belant Persada (Penyedia 1) Pengguna Bagian Pelayanan Kesehatan, Biro Umum, Sekretariat 59

76 60 Kementerian Sekretariat Negara Uraian proyek Aplikasi Sistem Informasi Poliklinik digunakan untuk mendukung tugas Bagian Pelayanan Kesehatan, Biro Umum, Sekretariat Kementerian Sekretariat Negara. Aplikasi ini diharapkan dapat membantu pengelolaan penanganan kesehatan di poliklinik Kementerian Sekretariat Negara. Aplikasi ini akan berfungsi diantaranya sebagai informasi catatan medis. Informasi catatan medis menjadi informasi yang dibutuhkan dokter saat melakukan pelayanan medis khususnya untuk kepentingan kesinambungan pelayanan medis pada pasien. Informasi catatan medis ini menerangkan kronologi atau urutan status kesehatan dan pengobatan pasien sehingga mempermudah bagi dokter untuk pemberian kesinambungan pelayanan untuk menentukan pengobatan, perawatan serta diagnosis dan tindakan yang tepat. Disamping itu informasi ini juga berfungsi sebagai salah satu syarat tertib administrasi dalam pengelolaan dokumen rekam medis untuk peningkatan mutu pelayanan. Selain itu aplikasi ini juga akan menghasilkan beberapa laporan yang sangat diperlukan seperti laporan kunjungan pasien, laporan penyakit dan tindakan yang dilakukan dan laporan obat. Laporan kunjungan merupakan laporan yang menerangkan tentang jumlah kunjungan pasien pada suatu periode tertentu. Dari laporan tersebut dapat diketahui indikator produktifitas rawat jalan yaitu dengan mengetahui jumlah kunjungan dalam suatu periode, jumlah kunjungan pasien baru / hari atau dalam suatu periode, jumlah kunjungan pasien lama / periode, jumlah kunjungan spesialistik poliklinik dalam serta perbandingan jumlah kunjungan pasien baru dengan pasien lama dalam

77 61 prosentase serta jumlah kunjungan menurut umur pasien, serta jenis kelamin. Laporan penyakit menunjukkan tentang penyakit-penyakit atau kasus-kasus yang dilayani pada poliklinik. Dari laporan ini dapat diketahui peringkat sepuluh besar penyakit rawat jalan pada poliklinik penyakit dalam / periode. Laporan ini dapat digunakan untuk pengambilan keputusan dalam perencanaan sumber daya yang akan dan harus disediakan seperti penambahan tenaga spesialis tertentu atau penambahan alat-alat canggih dan sarana prasarana lain untuk memenuhi kebutuhan klien dalam pemberian pelayanan medis rawat jalan poliklinik. b. Pembangunan Aplikasi Sistem Pengendalian Persediaan Barang Nama proyek Jangka waktu Pembangunan Aplikasi Sistem Pengendalian Persediaan Barang (Proyek 2) 92 (sembilan puluh dua) hari kalender Penyedia PT. Malloci Software Solution (Penyedia 2) Pengguna Uraian proyek Bagian Perlengkapan dan Rumah Tangga, Biro Umum, Sekretariat Kementerian Sekretariat Negara Aplikasi Sistem Pengendalian Persediaan Barang digunakan untuk mendukung tugas Bagian Perlengkapan dan Rumah Tangga dalam mengelola penyediaan perlengkapan kantor, rumah negara golongan I, Mess, Flat, dan Wisma yang berada dalam penguasaan Satuan Kerja Sekretariat Negara, serta pengelolaan urusan kerumahtanggaan kantor. Aplikasi ini juga digunakan untuk membantu Bagian Perlengkapan dan Rumah Tangga dalam menyelenggarakan fungsinya, yaitu: mengelola

78 62 pelaksanaan perencanaan dan pengadaan perlengkapan kantor dan rumah negara golongan I, Mess, Flat, dan Wisma; mengelola pelaksanaan pelayanan rumah tangga kantor; mengelola pemeliharaan kebersihan gedung kantor, dan rumah negara golongan I, Mess, Flat, dan Wisma beserta halaman dan taman; mengelola penyimpanan, pendistribusian, dan perawatan perlengkapan kantor dan rumah negara golongan I, Mess, Flat, dan Wisma; mengelola penatausahaan perlengkapan kantor, rumah negara golongan I, Mess, Flat, dan Wisma, serta barang persediaan; mengelola pelaksanaan urusan penggunaan jasa telepon gedung kantor dan rumah negara golongan I dan Wisma; dan mengelola pengusulan penghapusan perlengkapan kantor dan rumah negara golongan I, Mess, Flat, dan Wisma serta barang persediaan. c. Pembangunan Aplikasi Sistem Monitoring Masa Berlaku Surat Tanda Nomor Kendaraan (STNK) Nama proyek Jangka waktu Pembangunan Aplikasi Sistem Monitoring Masa Berlaku STNK (Proyek 3) 92 (sembilan puluh dua) hari kalender Penyedia CV. Torche Indonesia (Penyedia 3) Pengguna Uraian proyek Bagian Kendaraan, Biro Umum, Sekretariat Kementerian Sekretariat Negara Aplikasi Sistem Monitoring Masa Berlaku STNK digunakan untuk mendukung tugas Bagian Kendaraan dalam mengelola penyediaan kendaraan dinas di lingkungan Kementerian Sekretariat Negara dan pelayanan tamu negara/pemerintah. Aplikasi ini juga digunakan untuk membantu Bagian Kendaraan

79 63 dalam menyelenggarakan fungsinya, yaitu: mengelola pelaksanaan perencanaan dan pengadaan, serta pelayanan administrasi kendaraan dinas; mengelola pelaksanaan pelayanan penggunaan kendaraan dinas; mengelola pelaksanaan pelayanan antar jemput pegawai; mengelola pelaksanaan koordinasi pelayanan kendaraan dinas untuk kegiatan para menteri, dan ketua/wakil ketua lembaga negara, serta pelaksanaan koordinasi pelayanan kendaraan dinas untuk panitia negara urusan penerimaan kepala-kepala negara asing; mengelola pelaksanaan perawatan kendaraan dinas; dan mengelola pengusulan penghapusan kendaraan dinas. 5.2 Pemilihan Representasi CMMI CMMI memiliki dua model representasi, yaitu Staged dan Continuous. Pada representasi staged diharuskan mengimplementasikan semua area proses yang menjadi paket dalam satu maturity level. Sedangkan pada representasi continuous dimungkinkan untuk hanya memilih beberapa area proses yang menjadi fokus implementasi dari organisasi. Pada penelitian ini digunakan model representasi continuous. Pemilihan representasi continuous karena penilitian ini akan fokus hanya pada beberapa area proses yang sangat dekat atau berkaitan dengan permasalahan yang ada. 5.3 Pemilihan Area Proses Dalam memilih area proses penulis memperhatikan studi kasus pada buku Project Management Success with CMMI: Seven CMMI Process Areas oleh Persse pada tahun Pada buku ini Persse mencoba menunjukkan bagaimana menerapkan CMMI level 2 untuk meningkatkan efesiensi, efektifitas, dan akuntabilitas dari proses project management. Penjelasan dilakukan dengan memberikan gambaran pengalaman melalui studi kasus dan contoh.

80 64 Selain itu penulis juga melihat adanya kelompok area proses yang saling terhubung pada proses project management, terutama pada kelompok Basic Project Management Process Areas berdasarkan dokumen CMMI for Development, Version 1.3 dari Software Engineering Institute tahun Pada Basic Project Management Process Areas dijelaskan keterhubungan antara area proses Project Monitoring and Control, Project Planning, Requirements Management, dan Supplier Agreement Management. Keterhubungan antara area proses ini ditujukan untuk menangani kegiatan-kegiatan yang berkaitan dengan membangun dan menjaga rencana proyek, membuat dan menjaga komitmen, memantau kemajuan rencana, mengambil tindakan korektif, dan mengelola perjanjian dengan pemasok. Hal ini sangat berkaitan dengan permasalahan yang sedang dihadapi oleh Kementerian Sekretariat Negara dalam mengembangkan perangkat lunak yang melibatkan penyedia. Terhadap permasalahan yang ada dilakukan pemetaan masalah terhadap area proses yang menjadi studi kasus pada Project Management Success with CMMI oleh Persse dan kelompok keterhubungan dari area proses pada Basic Project Management Process Areas yang berfokus pada penanganan project management. Maka pada penelitian ini penulis coba fukus pada area proses berikut ini: a. Requirements Management (REQM) Area proses ini berkaitan dengan masalah kurangnya pemahaman penyedia terhadap kebutuhan dari pengguna. Tujuan dari area proses Requirements Management adalah untuk mengelola kebutuhan produk proyek dan komponen produk, serta untuk memastikan keselarasan antara kebutuhan, rencana proyek, dan produk. b. Project Planning (PP) Area proses Project Planning berkaitan dengan masalah ruang lingkup, sumber daya, dan perencanaan jadwal kerja. Area proses Project Planning ditujukan untuk membangun dan memelihara rencana yang mendefinisikan kegiatan proyek. c. Project Monitoring and Control (PMC)

81 65 Area proses Project Monitoring and Control berkaitan dengan pengontrolan dan pengendalian dari masalah-masalah pemenuhan dan kesesuaian kebutuhan pengguna, kesesuaian ruang lingkup, kesesuaian sumber daya, dan kesesuaian jadwal kerja, serta untuk mengawal kesiapan dari aplikasi. Area proses Project Monitoring and Control memiliki tujuan untuk memberikan pemahaman tentang perkembangan proyek sehingga tindakan koreksi yang tepat dapat diambil ketika kinerja proyek menyimpang secara signifikan dari rencana. d. Supplier Agreement Management (SAM) Area proses Supplier Agreement Management berkaitan dengan mekanisme apabila penyedia melibatkan pihak ketiga dalam pengerjaan proyeknya. Tujuan dari area proses Supplier Agreement Management adalah untuk mengelola akuisisi produk dan jasa dari pemasok. 5.4 Proses Penilaian SCAMPI C Penilaian pada penelitian ini mengacu pada Standard CMMI Appraisal Method for Process Improvement (SCAMPI) C. Pada SCAMPI penilaian terdiri dari tiga tahap, yaitu Plan and Prepare for Appraisal, Conduct Appraisal, dan Report Results. Selanjutnya akan diterangkan proses-proses yang dilakukan dalam penilaian yang mengacu pada SCAMPI C Plan and Prepare for Appraisal Pada tahap Plan and Prepare for Appraisal dilakukan Analyze Requirements atau analisa terhadap kebutuhan penilaian. Pada penelitian ini penilaian dilakukan bertujuan untuk mengetahui kapasitas dari penyedia jasa kosultasi perangkat lunak yang sedang mengerjakan proyek pengembangan perangkat lunak di Kementerian Sekretariat Negara. Hasil penilaian ini sendiri digunakan sebagai bahan dalam menyusun rekomendasi kerangka penilaian penyedia dalam lelang pengembangan perangkat lunak. Penilaian dilakukan dengan mengecek work products dari penyedia yang sesuai dengan area proses yang telah ditentukan. Tabel dibawah ini adalah skala karakter penilaian SCAMPI C yang digunakan sebagai acuan pada penilaian.

82 66 Tabel 5.1 Skala Karakter Penilaian Rendah Tujuan dari praktek model dinilai tidak ada, atau tidak cukup dibahas dalam pendekatan, pencapaian tujuan yang dinilai tidak mungkin karena tidak adanya atau kekurangan. Sedang Tujuan dari praktek model dinilai secara parsial dibahas dalam pendekatan, dan hanya dukungan dengan terbatas untuk pencapaian tujuan jelas. Tinggi Tujuan dari praktek model dinilai ditangani secara memadai dalam serangkaian praktek (direncanakan atau digunakan), dengan cara yang mendukung pencapaian tujuan dalam konteks proses yang diberikan. Proyek yang akan dinilai adalah: a. Pembangunan Aplikasi Sistem Informasi Poliklinik b. Pembangunan Aplikasi Sistem Pengendalian Persediaan Barang c. Pembangunan Aplikasi Sistem Monitoring Masa Berlaku STNK Analyze Requirements menghasilkan ringkasan cakupan dari proses penilaian. Ringkasan cakupan penilaian mewakili Appraisal Input Document. Berikut ini tabel-tabel persiapan penilaian proyek-proyek yang akan dinilai : Tabel 5.2 Persiapan Penilaian Proyek 1 Goal Tingkat kapasitas penyedia jasa konsultasi perangkat lunak Sponsor CMMI Model CMMI Development Version 1.3, Continuous Representation Organizational Unit PT. Belant Persada (Penyedia 1) Constraints -

83 67 Appraisal Team Method Tools Scope Heru Martin Saputra SCAMPI C Pengecekan work products CMMI Dev Continuous: Basic Project Management Process Areas Process Area, Capability Level (CL) and Practices: a. Requirements Management (REQM) CL 1 : SP 1.1, SP 1.2, SP 1.3, SP 1.4, SP 1.5, GP 1.1 CL 2 : GP 2.1, GP 2.2, GP 2.3, GP 2.4, GP 2.5, GP 2.6, GP 2.7, GP 2.8, GP 2.9, GP 2.10 b. Project Planning (PP) CL 1 : SP 1.1, SP 1.2, SP 1.3, SP 1.4, SP 2.1, SP 2.2, SP 2.3, SP 2.4, SP 2.5, SP 2.6, SP 2.7, SP 3.1, SP 3.2, SP 3.3, GP 1.1 CL 2 : GP 2.1, GP 2.2, GP 2.3, GP 2.4, GP 2.5, GP 2.6, GP 2.7, GP 2.8, GP 2.9 c. Project Monitoring and Control (PMC) CL 1 : SP 1.1, SP 1.2, SP 1.3, SP 1.4, SP 1.5, SP 1.6, SP 1.7, SP 2.1, SP 2.2, SP 2.3, GP 1.1 CL 2 : GP 2.1, GP 2.2, GP 2.3, GP 2.4, GP 2.5, GP 2.6, GP 2.7, GP 2.8, GP 2.9 d. Supplier Agreement Management (SAM) CL 1 : SP 1.1, SP 1.2, SP 1.3, SP 2.1, SP 2.2, SP 2.3, GP 1.1 CL 2 : GP 2.1, GP 2.2, GP 2.3, GP 2.4, GP 2.5, GP 2.6, GP 2.7, GP 2.8, GP 2.9 Sample / Instance Proyek Pembangunan Aplikasi Sistem Informasi Poliklinik (Proyek 1)

84 68 Datasource Planned Output Wawancara dengan perwakilan tim dan pengecekan dokumen. Daftar kapasitas penyedia jasa konsultasi perangkat lunak Tabel 5.3 Persiapan Penilaian Proyek 2 Goal Tingkat kapasitas penyedia jasa konsultasi perangkat lunak Sponsor CMMI Model CMMI Development Version 1.3, Continuous Representation Organizational Unit PT. Malloci Software Solution (Penyedia 2) Constraints - Appraisal Team Method Tools Scope Heru Martin Saputra SCAMPI C Pengecekan work products CMMI Dev Continuous: Basic Project Management Process Areas Process Area, Capability Level (CL) and Practices: a. Requirements Management (REQM) CL 1 : SP 1.1, SP 1.2, SP 1.3, SP 1.4, SP 1.5, GP 1.1 CL 2 : GP 2.1, GP 2.2, GP 2.3, GP 2.4, GP 2.5, GP 2.6, GP 2.7, GP 2.8, GP 2.9, GP 2.10 b. Project Planning (PP) CL 1 : SP 1.1, SP 1.2, SP 1.3, SP 1.4, SP 2.1, SP 2.2, SP 2.3, SP 2.4, SP 2.5, SP 2.6, SP 2.7, SP 3.1,

85 69 SP 3.2, SP 3.3, GP 1.1 CL 2 : GP 2.1, GP 2.2, GP 2.3, GP 2.4, GP 2.5, GP 2.6, GP 2.7, GP 2.8, GP 2.9 c. Project Monitoring and Control (PMC) CL 1 : SP 1.1, SP 1.2, SP 1.3, SP 1.4, SP 1.5, SP 1.6, SP 1.7, SP 2.1, SP 2.2, SP 2.3, GP 1.1 CL 2 : GP 2.1, GP 2.2, GP 2.3, GP 2.4, GP 2.5, GP 2.6, GP 2.7, GP 2.8, GP 2.9 d. Supplier Agreement Management (SAM) CL 1 : SP 1.1, SP 1.2, SP 1.3, SP 2.1, SP 2.2, SP 2.3, GP 1.1 CL 2 : GP 2.1, GP 2.2, GP 2.3, GP 2.4, GP 2.5, GP 2.6, GP 2.7, GP 2.8, GP 2.9 Sample / Instance Datasource Planned Output Proyek Pembangunan Aplikasi Sistem Pengendalian Persediaan Barang (Proyek 2) Wawancara dengan perwakilan tim dan pengecekan dokumen. Daftar kapasitas penyedia jasa konsultasi perangkat lunak Tabel 5.4 Persiapan Penilaian Proyek 3 Goal Tingkat kapasitas penyedia jasa konsultasi perangkat lunak Sponsor CMMI Model CMMI Development Version 1.3, Continuous Representation Organizational Unit CV. Torche Indonesia (Penyedia 3)

86 70 Constraints - Appraisal Team Method Tools Scope Heru Martin Saputra SCAMPI C Pengecekan work products CMMI Dev Continuous: Basic Project Management Process Areas Process Area, Capability Level (CL) and Practices: a. Requirements Management (REQM) CL 1 : SP 1.1, SP 1.2, SP 1.3, SP 1.4, SP 1.5, GP 1.1 CL 2 : GP 2.1, GP 2.2, GP 2.3, GP 2.4, GP 2.5, GP 2.6, GP 2.7, GP 2.8, GP 2.9, GP 2.10 b. Project Planning (PP) CL 1 : SP 1.1, SP 1.2, SP 1.3, SP 1.4, SP 2.1, SP 2.2, SP 2.3, SP 2.4, SP 2.5, SP 2.6, SP 2.7, SP 3.1, SP 3.2, SP 3.3, GP 1.1 CL 2 : GP 2.1, GP 2.2, GP 2.3, GP 2.4, GP 2.5, GP 2.6, GP 2.7, GP 2.8, GP 2.9 c. Project Monitoring and Control (PMC) CL 1 : SP 1.1, SP 1.2, SP 1.3, SP 1.4, SP 1.5, SP 1.6, SP 1.7, SP 2.1, SP 2.2, SP 2.3, GP 1.1 CL 2 : GP 2.1, GP 2.2, GP 2.3, GP 2.4, GP 2.5, GP 2.6, GP 2.7, GP 2.8, GP 2.9 d. Supplier Agreement Management (SAM) CL 1 : SP 1.1, SP 1.2, SP 1.3, SP 2.1, SP 2.2, SP 2.3, GP 1.1 CL 2 : GP 2.1, GP 2.2, GP 2.3, GP 2.4, GP 2.5, GP 2.6, GP 2.7, GP 2.8, GP 2.9 Sample / Instance Proyek Pembangunan Aplikasi Sistem Monitoring Masa

87 71 Berlaku STNK (Proyek 3) Datasource Planned Output Wawancara dengan perwakilan tim dan pengecekan dokumen. Daftar kapasitas penyedia jasa konsultasi perangkat lunak Selanjutnya dilakukan Develop Appraisal Plan, rencana ini buat sebagai dasar komitmen dan fungsi dalam memantau dan mengendalikan proses penilaian. Rencana-rencana penilaian akan dilihat pada tabel-tabel di bawah ini. Tabel 5.5 Rencana Penilaian Kegiatan yang akan dilakukan Kegiatan pada area proses: 1. Pendataan awal dokumen yang biasa dipakai di Kementerian Sekretariat Negara 2. Melakukan wawancara 3. Mengumpulkan dokumen 4. Memverifikasi kesesuaian wawancara, dokumen dan work products area proses 5. Melaporkan hasil kegiatan Jadwal 1. Proyek 1 (30/09/ /10/2013) 2. Proyek 2 (07/10/ /10/2013) 3. Proyek 3 (16/10/ /10/2013) Logistik Penilaian Risiko dan mitigasi Alat untuk merekam, flashdisk, modem koneksi internet, dan persiapan untuk setiap area proses yang akan dinilai. Risiko: - Kantor penyedia tidak berdomisili di Jakarta

88 72 - Penyedia sulit untuk ditemui Mitigasi: - Wawancara melalui telepon - Pengiriman work products melalui - Penjadwalan ulang untuk verifikasi hasil wawancara melalui telepon Kegiatan selanjutnya Select and Prepare Team, karena menggunakan SCAMPI C pembentukan tim tidak diperlukan. Langkah berikutnya adalah Prepare Participants and Obtain Initial Objective Evidence. Data awal terkait work products adalah dokumen yang biasa dipakai atau dokumen yang wajib dipenuhi penyedia dalam proses lelang dan pengembangan peranti lunaknya. Pada tabel dibawah dapat dilihat pendataan dokumen awal. Tabel 5.6 Daftar Dokumen No Dokumen Keterangan Area Proses Terkait 1 Dokumen Penawaran Teknis Dokumen Penawaran meliputi: 1) data pengalaman perusahaan, terdiri dari : a) data organisasi perusahaan, b) daftar pengalaman kerja sejenis, c) uraian pengalaman kerja sejenis, diuraikan secara jelas dengan mencantumkan informasi : nama pekerjaan yang dilaksanakan, lingkup dan data pekerjaan yang dilaksanakan REQM, PP

89 73 No Dokumen Keterangan Area Proses Terkait secara singkat, lokasi, pemberi tugas, nilai, dan waktu pelaksanaan (menyebutkan bulan dan tahun), d) uraian data pekerjaan yang sedang dilaksanakan diuraikan secara jelas dengan mencantumkan informasi : nama pekerjaan yang dilaksanakan, lingkup dan data pekerjaan yang dilaksanakan secara singkat, lokasi, pemberi tugas, nilai, dan waktu pelaksanaan (menyebutkan bulan dan tahun). 2) pendekatandan metodologi, terdiri dari : a) tanggapan dan saran terhadap Kerangka Acuan Kerja, b) uraian pendekatan, metodologi dan program kerja, c) jadwal waktu pelaksanaan

90 74 No Dokumen Keterangan Area Proses Terkait pekerjaan sampai dengan serah terima pekerjaan, d) komposisi tim dan penugasan, e) jadwal penugasan tenaga ahli, 2 Dokumen Penawaran Harga 3) kualifikasi tenaga ahli, terdiri dari : a) Daftar Riwayat Hidup personil yang diusulkan, b) surat pernyataan kesediaan untuk ditugaskan. Dokumen Penawaran Biaya harus terdiri dari: a. surat penawaran biaya yang didalamnya tercantum masa berlaku penawaran dan total biaya penawaran (dalam angka dan huruf); b. rekapitulasi penawaran biaya; c. rincian Biaya Langsung Personil (remuneration); d. rincian Biaya Langsung Non- Personil (direct reimburseable cost); PP 3 Surat Perjanjian Surat perjanjian merupakan surat kontrak bentuk kesepakatan antara REQM

91 75 No Dokumen Keterangan Area Proses Terkait organisasi dengan penyedia jasa konsultasi, yang artinya penyedia menyetujui kebutuhan atau persyaratan yang harus dipenuhi dan organisasi setuju untuk mengeluarkan biaya sesuai degan yang disepakati. Surat perjanjian menjadi satu kesatuan dengan dokumen-dokumen berikut dan bagian yang tidak terpisahkan dari surat perjanjian: a) Adendum Surat Perjanjian (apabila ada); b) Pokok Perjanjian; c) Berita Acara Hasil Klarifikasi dan Negosiasi; d) Surat Penawaran berikut Data Penawaran Biaya; e) Syarat-Syarat Khusus Kontrak; f) Syarat-Syarat Umum Kontrak; g) Kerangka Acuan Kerja; h) Daftar kuantitas (apabila ada); i) Data Teknis selain Kerangka Acuan Kerja; j) Dokumen-dokumen kelengkapan

92 76 No Dokumen Keterangan Area Proses Terkait 4 Laporan Pendahuluan seleksi, yaitu Surat Jaminan, Surat Penunjukan Penyedia Barang/Jasa, dan Berita-Berita Acara Seleksi. Laporan Pendahuluan memuat analisis alur data, formulir transaksi, dan laporan-laporan dari sistem yang sedang berjalan, usulan formulir transkripsi, dokumen transaksi, rancangan database, rancangan aplikasi dan laporan-laporan yang diperlukan, serta rancangan proses bisnis elektronis. REQM, PP, PMC 5 Laporan Antara Laporan Antara memuat perkembangan pembangunan aplikasi. PMC 6 Laporan Uji coba & Keamanan Laporan Uji coba & Keamanan memuat hasil uji coba aplikasi yang sudah berjalan dengan sempurna dan hasil uji keamanan terhadap aplikasi dan database, serta prosedur-prosedur (tata kelola) keamanan yang akan dijalankan. PMC 7 Laporan Akhir Laporan Akhir memuat dokumentasi hasil akhir seluruh kegiatan pembangunan aplikasi, spesifikasi rinci aplikasi dan database, dan penerapan keamanan terhadap aplikasi dan PMC

93 77 No Dokumen Keterangan Area Proses Terkait database. Evaluasi terhadap Appraisal Input, Appraisal Plan, dan Objective Evidence dilakukan pada tahap Prepare for Collection of Objective Evidence. Pada tahap ini revisi dapat dilakukan jika dibutuhkan Conduct Appraisal Tahap penilaian dimulai dengan Examine Objective Evidence, yaitu proses pengumpulan data. Pada proses pengumpulan data, wawancara dilakukan untuk mengkonfirmasi paraktek-praktek yang dilakukan terkait area proses. Dokumendokumen terkait area proses juga dikumpulkan sebagai bukti dari pelaksanaan praktek-praktek dari area proses. Dokumen yang tidak bisa dibawa, diperlihatkan atau diambil gambarnya untuk memperkuat pelaksanaan praktek. Lalu pada tahap Document Objective Evidence, data yang didapat didokumentasikan, baik berupa hasil wawancara, dokumen praktek, maupun cuplikan gambar dari praktek. Kegiatan dilanjutkan dengan Verify Objective Evidence untuk memeriksa bukti-bukti objektif terkait praktek-praktek yang dilaksanakan. Setelah memeriksa bukti-bukti objektif, kemudian dilakukan validasi hasil penilaian pada tahap Validate Preliminary Appraisal Outputs Report Results Report Results terdiri dari dua tahapan, pertama Deliver Appraisal Results yaitu melaporkan hasil dari penilaian ke penyedia atau pihak yang terkait dengan penilaian ini. Kedua Package and Archive Appraisal Assets yaitu pendokumentasian hasil penilaian. Pada penelitian ini hasil penilaian digunakan untuk kebutuhan penelitian, materi evaluasi pengadaan lelang perangkat lunak, dan menyampaikan hasil kepada penyedia yang terkait dengan penelitian ini.

94 Hasil Penilaian Penyedia 1 Berikut ini merupakan hasil penilaian terhadap Penyedia 1 yang mengerjakan proyek Pembangunan Aplikasi Sistem Informasi Poliklinik Penilaian REQM Penyedia 1 Penilaian REQM sesuai dengan yang telah ditetapkan pada persiapan penilaian proyek akan mencakup Capability Level 2 yang terdiri dari: Capability Level 1: o SG 1 Manage Requirements SP 1.1 Understand Requirements SP 1.2 Obtain Commitment to Requirements SP 1.3 Manage Requirements Changes SP 1.4 Maintain Bidirectional Traceability of Requirements SP 1.5 Ensure Alignment Between Project Work and Requirements o GG 1 Achieve Specific Goals GP 1 Perform Specific Practices Capability Level 2: o GG 2 Institutionalize a Managed Process GP 2.1 Establish an Organizational Policy GP 2.2 Plan the Process GP 2.3 Provide Resources GP 2.4 Assign Responsibility GP 2.5 Train People GP 2.6 Control Work Products GP 2.7 Identify and Involve Relevant Stakeholders GP 2.8 Monitor and Control the Process GP 2.9 Objectively Evaluate Adherence GP 2.10 Review Status with Higher Level Management

95 REQM Capability Level 1 Penyedia 1 Untuk mencapai REQM capability level 1 diperlukan penilaian terhadap semua Specific Practice (SP) untuk mencapai semua Specific Goal (SG) pada area proses ini. Tabel 5.7 Penilaian REQM CL 1 Penyedia 1 Goal Practice Work Products Result SG 1 SP Surat Penawaran Administrasi dan Teknis (Nomor 027/BP-SP/PR/VII/2013) : B-1-Dokumen.Penawaran.Teknis, Pemahaman Terhadap KAK (hal 68) Sedang - Laporan Pendahuluan (Nomor DLP.1.SETNEG.SIPOLI.2013) : Pelaksanaan Pekerjaan (hal 41), Lampiran (hal 41) - Surat Perjanjian (Nomor 1/PERJANJIAN-ASIP/D- 1/PPK/07/2013) SP Untuk dokumentasi komitmen terhadap Sedang requirements terekam pada - Surat Perjanjian (Nomor 1/PERJANJIAN-ASIP/D-1/PPK/07/2013), sedangkan komitmen terhadap requirements changes terekam padadokumen Minute of Meeting namun dokumentasi lemah. SP Dokumen Minute Of Meeting: Rendah MOM (pdf), MOM (doc) SP Penelusuran requirements melalui dokumen Rendah Minute Of Meeting, dokumen PROGRESS_REPORT, namun dokumentasi tidak terintegrasi dan cukup sulit melakukan penelusuran kebutuhan. SP Dokumen Minute of Meeting tidak terintegrasi Sedang dengan dokumen requirements, dan dokumentasi lemah. GG 1 GP 1.1 Specific practice dari specific goal belum dipenuhi. Rendah Pada tabel 5.7 dapat dilihat bahwa Penyedia 1 belum memenuhi specific practice pada area proses REQM, sehingga belum dapat mencapai capability level 1. Sebagaian specific practice sudah dijalankan namun belum begitu kuat, dikarenakan ada praktek-praktek yang masih kurang dalam mendukung specific practice.

96 REQM Capability Level 2 Penyedia 1 Untuk mencapai REQM capability level 2 diperlukan penilaian terhadap semua Specific Practice (SP) untuk mencapai semua Specific Goal (SG) dan semua Generic Practice (GP) untuk memenuhi Generic Goal (GG) 2 pada area proses ini. Tabel 5.8 Penilaian REQM CL 2 Penyedia 1 Goal Practice Work Products Result SG 1 SP Surat Penawaran Administrasi dan Teknis (Nomor 027/BP-SP/PR/VII/2013) : B-1-Dokumen.Penawaran.Teknis, Pemahaman Terhadap KAK (hal 68) Sedang - Laporan Pendahuluan (Nomor DLP.1.SETNEG.SIPOLI.2013) : Pelaksanaan Pekerjaan (hal 41), Lampiran (hal 41) - Surat Perjanjian (Nomor 1/PERJANJIAN-ASIP/D- 1/PPK/07/2013) SP Untuk dokumentasi komitmen terhadap Sedang requirements terekam pada - Surat Perjanjian (Nomor 1/PERJANJIAN-ASIP/D-1/PPK/07/2013), sedangkan komitmen terhadap requirements changes terekam padadokumen Minute of Meeting namun dokumentasi lemah. SP Dokumen Minute Of Meeting: Rendah MOM (pdf), MOM (doc) SP Penelusuran requirements melalui dokumen Rendah Minute Of Meeting, dokumen PROGRESS_REPORT, namun dokumentasi tidak terintegrasi dan cukup sulit melakukan penelusuran kebutuhan. SP Dokumen Minute of Meeting tidak terintegrasi Sedang dengan dokumen requirements, dan dokumentasi lemah. GG 1 GP 1.1 Specific practice dari specific goal belum dipenuhi. Rendah GG 2 GP 2.1 Kebijakan penyedia membentuk tim kecil Sedang (Marketing dan Divisi Software Development) yang melakukan investigasi terkait kebutuhan proyek. GP 2.2 Memiliki dokumen Requirements Management tapi Sedang tidak lengkap

97 81 Goal Practice Work Products Result GP Penelusuran requirements melalui dokumen Rendah Minute Of Meeting, dokumen PROGRESS_REPORT, namun dokumentasi tidak terintegrasi dan cukup sulit melakukan penelusuran. GP Surat Penawaran Administrasi dan Teknis (Nomor Sedang 027/BP-SP/PR/VII/2013): 5. Kualifikasi Tenaga Ahli (hal 135), B-4- Lampiran.Pernyataan.Kesediaan.Ditugaskan (pdf) GP 2.5 Pelatihan teknis, tidak ada pelatihan terkait topik Rendah REQM GP Kegiatan didokumentasikan pada dokumen MOM, Rendah namun dokumentasi tidak cukup kuat GP Kegiatan dilakukan dengan rapat dan Rendah didokumentasikan pada dokumen MOM, namun dokumentasi tidak cukup kuat GP Kegiatan tidak terdokumentasi. Rendah GP Kegiatan dilakukan dengan rapat dan Rendah didokumentasikan pada dokumen MOM, namun dokumentasi tidak cukup kuat GP Kegiatan tidak terdokumentasi. Rendah Dari tabel 5.7 sebenarnya sudah bisa ditentukan Penyedia 1 tidak dapat mencapai capability level 2 karena tidak dapat memenuhi semua specific practice yang ada pada area proses REQM. Tabel 5.8 menjadi penguat bahwa Penyedia 1 belum dapat mencapai capability level 2, karena selain specific practice yang belum dapat dipenuhi, juga generic practice dari generic goal 2 belum dapat dipenuhi Penilaian PP Penyedia 1 Penilaian PP sesuai dengan yang telah ditetapkan pada persiapan penilaian proyek akan mencakup Capability Level 2 yang terdiri dari: Capability Level 1: o SG 1 Establish Estimates SP 1.1 Estimate the Scope of the Project SP 1.2 Establish Estimates of Work Product and Task Attributes SP 1.3 Define Project Lifecycle Phases SP 1.4 Estimate Effort and Cost

98 82 o SG 2 Develop a Project Plan SP 2.1 Establish the Budget and Schedule SP 2.2 Identify Project Risks SP 2.3 Plan Data Management SP 2.4 Plan the Project s Resources SP 2.5 Plan Needed Knowledge and Skills SP 2.6 Plan Stakeholder Involvement SP 2.7 Establish the Project Plan o SG 3 Obtain Commitment to the Plan SP 3.1 Review Plans That Affect the Project SP 3.2 Reconcile Work and Resource Levels SP 3.3 Obtain Plan Commitment o GG 1 Achieve Specific Goals GP 1 Perform Specific Practices Capability Level 2: o GG 2 Institutionalize a Managed Process GP 2.1 Establish an Organizational Policy GP 2.2 Plan the Process GP 2.3 Provide Resources GP 2.4 Assign Responsibility GP 2.5 Train People GP 2.6 Control Work Products GP 2.7 Identify and Involve Relevant Stakeholders GP 2.8 Monitor and Control the Process GP 2.9 Objectively Evaluate Adherence PP Capability Level 1 Penyedia 1 Untuk mencapai PP capability level 1 diperlukan penilaian terhadap semua Specific Practice untuk mencapai semua Specific Goal pada area proses ini.

99 83 Tabel 5.9 Penilaian PP CL 1 Penyedia 1 Goal Practice Work Products Result SG 1 SP Surat Penawaran Administrasi dan Teknis (Nomor Rendah 027/BP-SP/PR/VII/2013) : 4. Pendekatan dan Metodologi (hal 68) SP Surat Penawaran Administrasi dan Teknis (Nomor Sedang 027/BP-SP/PR/VII/2013) : 4.2 METODOLOGI PEKERJAAN (hal 79), 4.4 Hasil Kerja (hal 122), SPESIFIKASI TEKNIS (hal 135) SP Enterprise Unified Process Tinggi (Surat Penawaran Administrasi dan Teknis (Nomor 027/BP-SP/PR/VII/2013) ): ENTERPRISE UNIFIED PROCESS (EUP) (hal 81) SP Surat Penawaran Administrasi dan Teknis (Nomor Tinggi 027/BP-SP/PR/VII/2013) : PROGRAM KERJA (hal 113), 4.3 Rencana Kerja (hal 101), 4.4 Hasil Kerja (Deliverables) (hal 122), 4.5 Gagasan dan Usulan Baru (hal 139), - Surat Penawaran Biaya (Nomor 028/BP- SPH/PR/VII/2013) SG 2 SP Surat Penawaran Administrasi dan Teknis (Nomor Sedang 027/BP-SP/PR/VII/2013) : Jadwal Pelaksanaan Pekerjaan (hal 103) - Surat Penawaran Biaya (Nomor 028/BP- SPH/PR/VII/2013) SP Surat Penawaran Administrasi dan Teknis (Nomor Rendah 027/BP-SP/PR/VII/2013) 4.8 Pengelolaan Risiko (hal 152) (Memaparkan konsep risiko) SP Surat Penawaran Administrasi dan Teknis (Nomor 027/BP-SP/PR/VII/2013) : 4.1 Pemahaman Terhadap KAK (hal 68), PROGRAM KERJA (hal 113), Jadwal Pelaksanaan Pekerjaan (hal 103) - Laporan Pendahuluan (Nomor DLP.1.SETNEG.SIPOLI.2013) : 4.2 Analisis Kebutuhan Sistem (hal 42), 3.2 Jadwal Pelaksanaan Pekerjaan (hal 22) Rendah

100 84 Goal Practice Work Products Result SP Surat Penawaran Administrasi dan Teknis (Nomor Sedang 027/BP-SP/PR/VII/2013) : 4. Pendekatan dan Metodologi (hal 68), Uraian Jenis Keahlian Tenaga Ahli (hal 108), 4.6 Fasilitas Pendukung (hal 148), Fase/Tahapan Dalam EUP (hal 82), Laporan dan Dokumentasi Pekerjaan (hal 119) - Laporan Pendahuluan (Nomor DLP.1.SETNEG.SIPOLI.2013): Pelaksanaan Pekerjaan (hal 41), 3.7 Sistem Dokumentasi (hal 40) SP Surat Penawaran Administrasi dan Teknis (Nomor Tinggi 027/BP-SP/PR/VII/2013): URAIAN JENIS KEAHLIAN TENAGA AHLI (hal 108), Daftar Tenaga Ahli yang Diusulkan (hal 106), B-3 Lampiran CV SP Tidak ditemukan Rendah SP Laporan Pendahuluan (Nomor Tinggi DLP.1.SETNEG.SIPOLI.2013) SG 3 SP Tidak ditemukan Rendah SP Tidak ditemukan - Pada pekerjaan dipemerintahan umumnya tidak ada penambahan anggaran dan waktu Rendah SP Surat Perjanjian (Nomor 1/PERJANJIAN-ASIP/D- 1/PPK/07/2013) Sedang - Dokumentasi pada Minute of Meeting lemah. GG 1 GP 1.1 Specific practice dari specific goal belum dipenuhi. Rendah Pada tabel 5.9 dapat dilihat bahwa Penyedia 1 belum memenuhi specific practice pada area proses PP, sehingga belum dapat mencapai capability level 1. Dari 14 specific practice hanya 4 specific practice yang mendapat skala nilai tinggi PP Capability Level 2 Penyedia 1 Untuk mencapai PP capability level 2 diperlukan penilaian terhadap semua Specific Practice untuk mencapai semua Specific Goal dan semua Generic Practice untuk memenuhi Generic Goal 2 pada area proses ini.

101 85 Tabel 5.10 Penilaian PP CL 2 Penyedia 1 Goal Practice Work Products Result SG 1 SP Surat Penawaran Administrasi dan Teknis (Nomor Rendah 027/BP-SP/PR/VII/2013) : 4. Pendekatan dan Metodologi (hal 68) SP Surat Penawaran Administrasi dan Teknis (Nomor Sedang 027/BP-SP/PR/VII/2013) : 4.2 METODOLOGI PEKERJAAN (hal 79), 4.4 Hasil Kerja (hal 122), SPESIFIKASI TEKNIS (hal 135) SP Enterprise Unified Process Tinggi (Surat Penawaran Administrasi dan Teknis (Nomor 027/BP-SP/PR/VII/2013) ): ENTERPRISE UNIFIED PROCESS (EUP) (hal 81) SP Surat Penawaran Administrasi dan Teknis (Nomor Tinggi 027/BP-SP/PR/VII/2013) : PROGRAM KERJA (hal 113), 4.3 Rencana Kerja (hal 101), 4.4 Hasil Kerja (Deliverables) (hal 122), 4.5 Gagasan dan Usulan Baru (hal 139), - Surat Penawaran Biaya (Nomor 028/BP- SPH/PR/VII/2013) SG 2 SP Surat Penawaran Administrasi dan Teknis (Nomor Sedang 027/BP-SP/PR/VII/2013) : Jadwal Pelaksanaan Pekerjaan (hal 103) - Surat Penawaran Biaya (Nomor 028/BP- SPH/PR/VII/2013) SP Surat Penawaran Administrasi dan Teknis (Nomor Rendah 027/BP-SP/PR/VII/2013) 4.8 Pengelolaan Risiko (hal 152) (Memaparkan konsep risiko) SP Surat Penawaran Administrasi dan Teknis (Nomor 027/BP-SP/PR/VII/2013) : 4.1 Pemahaman Terhadap KAK (hal 68), PROGRAM KERJA (hal 113), Jadwal Pelaksanaan Pekerjaan (hal 103) - Laporan Pendahuluan (Nomor DLP.1.SETNEG.SIPOLI.2013) : 4.2 Analisis Kebutuhan Sistem (hal 42), 3.2 Jadwal Pelaksanaan Pekerjaan (hal 22) Rendah

102 86 Goal Practice Work Products Result SP Surat Penawaran Administrasi dan Teknis (Nomor Sedang 027/BP-SP/PR/VII/2013) : 4. Pendekatan dan Metodologi (hal 68), Uraian Jenis Keahlian Tenaga Ahli (hal 108), 4.6 Fasilitas Pendukung (hal 148), Fase/Tahapan Dalam EUP (hal 82), Laporan dan Dokumentasi Pekerjaan (hal 119) - Laporan Pendahuluan (Nomor DLP.1.SETNEG.SIPOLI.2013): Pelaksanaan Pekerjaan (hal 41), 3.7 Sistem Dokumentasi (hal 40) SP Surat Penawaran Administrasi dan Teknis (Nomor Tinggi 027/BP-SP/PR/VII/2013): URAIAN JENIS KEAHLIAN TENAGA AHLI (hal 108), Daftar Tenaga Ahli yang Diusulkan (hal 106), B-3 Lampiran CV SP Tidak ditemukan Rendah SP Laporan Pendahuluan (Nomor Tinggi DLP.1.SETNEG.SIPOLI.2013) SG 3 SP Tidak ditemukan Rendah SP Tidak ditemukan - Pada pekerjaan dipemerintahan umumnya tidak ada penambahan anggaran dan waktu Rendah SP Surat Perjanjian (Nomor 1/PERJANJIAN-ASIP/D- 1/PPK/07/2013) Sedang - Dokumentasi pada Minute of Meeting lemah. GG 1 GP 1.1 Specific practice dari specific goal belum dipenuhi. Rendah GG 2 GP Surat Penawaran Administrasi dan Teknis (Nomor Tinggi 027/BP-SP/PR/VII/2013) - Laporan Pendahuluan (Nomor DLP.1.SETNEG.SIPOLI.2013) GP Laporan Pendahuluan (Nomor Tinggi DLP.1.SETNEG.SIPOLI.2013) GP Surat Penawaran Administrasi dan Teknis (Nomor Sedang 027/BP-SP/PR/VII/2013): 3. Pengalaman Perusahaan (hal 8), Jadwal Pelaksanaan Pekerjaan (hal 83), Spesifikasi Teknis (hal 115), 4.2 Metodologi Pekerjaan (hal 59), 4.3 Rencana Kerja (hal 81) '- Laporan Pendahuluan (Nomor DLP.1.SETNEG.SIPOLI.2013)

103 87 Goal Practice Work Products Result GP Surat Penawaran Administrasi dan Teknis (Nomor Sedang 027/BP-SP/PR/VII/2013): 5. Kualifikasi Tenaga Ahli (hal 135), B-4-Lampiran.Pernyataan.Kesediaan.Ditugaskan (pdf) GP 2.5 Pelatihan teknis, tidak ada pelatihan terkait topik PP Rendah GP Surat Penawaran Administrasi dan Teknis (Nomor 027/BP-SP/PR/VII/2013): 4.3 Rencana Kerja (hal 81) Rendah - Laporan Pendahuluan (Nomor DLP.1.SETNEG.SIPOLI.2013): Rencana Kerja (hal 21) GP Tidak ditemukan Rendah GP Tidak ditemukan Rendah GP Kegiatan tidak ditemukan Rendah Dari tabel 5.9 sudah diketahui Penyedia 1 tidak dapat mencapai capability level 2 karena tidak dapat memenuhi semua specific practice yang ada pada area proses PP. Tabel 5.10 menjadi penguat bahwa Penyedia 1 belum dapat mencapai capability level 2, karena selain specific practice yang belum dapat dipenuhi, juga generic practice dari generic goal 2 belum dapat dipenuhi. Dari 9 generic practice hanya 2 yang mendapat nilai tinggi Penilaian PMC Penyedia 1 Penilaian PMC sesuai dengan yang telah ditetapkan pada persiapan penilaian proyek akan mencakup Capability Level 2 yang terdiri dari: Capability Level 1: o SG 1 Monitor the Project Against the Plan SP 1.1 Monitor Project Planning Parameters SP 1.2 Monitor Commitments SP 1.3 Monitor Project Risks SP 1.4 Monitor Data Management SP 1.5 Monitor Stakeholder Involvement SP 1.6 Conduct Progress Reviews SP 1.7 Conduct Milestone Reviews

104 88 o SG 2 Manage Corrective Action to Closure SP 2.1 Analyze Issues SP 2.2 Take Corrective Action SP 2.3 Manage Corrective Actions o GG 1 Achieve Specific Goals Capability Level 2: GP 1 Perform Specific Practices o GG 2 Institutionalize a Managed Process GP 2.1 Establish an Organizational Policy GP 2.2 Plan the Process GP 2.3 Provide Resources GP 2.4 Assign Responsibility GP 2.5 Train People GP 2.6 Control Work Products GP 2.7 Identify and Involve Relevant Stakeholders GP 2.8 Monitor and Control the Process GP 2.9 Objectively Evaluate Adherence PMC Capability Level 1 Penyedia 1 Untuk mencapai PMC capability level 1 diperlukan penilaian terhadap semua Specific Practice untuk mencapai semua Specific Goal pada area proses ini. Tabel 5.11 Penilaian PMC CL 1 Penyedia 1 Goal Practice Work Products Result SG 1 SP Terdokumentasi dalam PROGRESS_REPORT, Rendah Progres Pekerjaan. Namun dokumentasi masih lemah tidak menunjukkan perkembangan requirements. - Web development SP Dokumentasi pada dokumen Minute of Meeting Rendah masih lemah SP Dokumentasi pada dokumen Minute of Meeting Rendah masih lemah SP Perkembangan data semua tersimpan pada website basecamp.com namun tidak terintegrasi dengan project plan. Rendah

105 89 Goal Practice Work Products Result SP Dokumentasi pada dokumen Minute of Meeting Sedang masih lemah SP Review proyek terdapat pada dokumen Sedang PROGRESS_REPORT, Review. Namun dokumentasi kurang lengkap dan tidak begitu jelas. SP Dokumentasi tersebut terdapat pada Laporan Sedang Pendahuluan (Nomor DLP.1.SETNEG.SIPOLI.2013), Laporan Antara (DLA.1.SETNEG.SIPOLI.2013), dan Laporan Akhir. Namun dokumentasi kurang lengkap dan tidak begitu jelas. SG 2 SP Tidak ditemukan Rendah SP Terdokumentasi pada dokumen Rendah PROGRESS_REPORT. Namun dokumentasi yang ada tidak jelas, tidak lengkap dan tidak terintegrasi dengan project plan. SP Tidak ditemukan Rendah GG 1 GP 1.1 Specific practice dari specific goal belum dipenuhi. Rendah Pada tabel 5.11 dapat dilihat bahwa Penyedia 1 belum memenuhi specific practice pada area proses PMC, sehingga belum dapat mencapai capability level PMC Capability Level 2 Penyedia 1 Untuk mencapai PMC capability level 2 diperlukan penilaian terhadap semua Specific Practice untuk mencapai semua Specific Goal dan semua Generic Practice untuk memenuhi Generic Goal 2 pada area proses ini. Tabel 5.12 Penilaian PMC CL 2 Penyedia 1 Goal Practice Work Products Result SG 1 SP Terdokumentasi dalam PROGRESS_REPORT, Rendah Progres Pekerjaan. Namun dokumentasi masih lemah tidak menunjukkan perkembangan requirements. - Web development SP Dokumentasi pada dokumen Minute of Meeting Rendah masih lemah SP Dokumentasi pada dokumen Minute of Meeting Rendah masih lemah SP Perkembangan data semua tersimpan pada website basecamp.com namun tidak terintegrasi dengan Rendah

106 90 Goal Practice Work Products Result project plan. SP Dokumentasi pada dokumen Minute of Meeting Sedang masih lemah SP Review proyek terdapat pada dokumen Sedang PROGRESS_REPORT, Review. Namun dokumentasi kurang lengkap dan tidak begitu jelas. SP Dokumentasi tersebut terdapat pada Laporan Sedang Pendahuluan (Nomor DLP.1.SETNEG.SIPOLI.2013), Laporan Antara (DLA.1.SETNEG.SIPOLI.2013), dan Laporan Akhir. Namun dokumentasi kurang lengkap dan tidak begitu jelas. SG 2 SP Tidak ditemukan Rendah SP Terdokumentasi pada dokumen Rendah PROGRESS_REPORT. Namun dokumentasi yang ada tidak jelas, tidak lengkap dan tidak terintegrasi dengan project plan. SP Tidak ditemukan Rendah GG 1 GP 1.1 Specific practice dari specific goal belum dipenuhi. Rendah GG 2 GP Dokumen PROGRESS_REPORT Sedang - Website basecamp.com - Data tidak terintegrasi dengan project plan dan requirement management GP Dokumen PROGRESS_REPORT Sedang - Website basecamp.com - Data tidak terintegrasi dengan project plan dan requirement management GP Dokumen PROGRESS_REPORT dan Website Rendah basecamp.com GP Surat Penawaran Administrasi dan Teknis (Nomor 027/BP-SP/PR/VII/2013): 5. Kualifikasi Tenaga Ahli (hal 135), B-4-Lampiran.Pernyataan.Kesediaan.Ditugaskan Sedang GP 2.5 Pelatihan teknis, tidak ada pelatihan terkait topik PMC Rendah GP Dokumen PROGRESS_REPORT: Rendah 2.4. STATUS PROGRESS, perkembangan secara umum, tidak memperlihatkan perkembangan requirements, Progres Pekerjaan, tapi tidak menunjukkan perkembangan dari requirements GP 2.7 Stakeholder dilibatkan dalam rapat, namun tidak ada Rendah dokumentasi yang terintegrasi terkait point-point GP 2.7 GP Kegiatan tidak ditemukan Rendah

107 91 Goal Practice Work Products Result GP Dokumen PROGRESS_REPORT: Status Progres, Review Data tidak terintegrasi dengan project plan dan requirement management Sedang Dari tabel 5.11 sudah diketahui Penyedia 1 tidak dapat mencapai capability level 2 karena tidak dapat memenuhi semua specific practice yang ada pada area proses PMC. Tabel 5.12 menjadi penguat bahwa Penyedia 1 belum dapat mencapai capability level 2, karena selain specific practice yang belum dapat dipenuhi, juga generic practice dari generic goal 2 belum dapat dipenuhi Penilaian SAM Penyedia 1 Penilaian SAM sesuai dengan yang telah ditetapkan pada persiapan penilaian proyek akan mencakup Capability Level 2 yang terdiri dari: Capability Level 1: o SG 1 Establish Supplier Agreements SP 1.1 Determine Acquisition Type SP 1.2 Select Suppliers SP 1.3 Establish Supplier Agreements o SG 2 Satisfy Supplier Agreements SP 2.1 Execute the Supplier Agreement SP 2.2 Accept the Acquired Product SP 2.3 Ensure Transition of Products o GG 1 Achieve Specific Goals GP 1 Perform Specific Practices Capability Level 2: o GG 2 Institutionalize a Managed Process GP 2.1 Establish an Organizational Policy GP 2.2 Plan the Process GP 2.3 Provide Resources GP 2.4 Assign Responsibility

108 92 GP 2.5 Train People GP 2.6 Control Work Products GP 2.7 Identify and Involve Relevant Stakeholders GP 2.8 Monitor and Control the Process GP 2.9 Objectively Evaluate Adherence Area proses ini tidak dapat dinilai, karena pada proyek ini penyedia tidak melibatkan pihak ketiga. Dari semua specific practice dan generic practice yang ada tidak ada yang dipraktekkan. 5.6 Hasil Penilaian Penyedia 2 Berikut ini merupakan hasil penilaian terhadap Penyedia 2 yang mengerjakan proyek Pembangunan Aplikasi Sistem Pengendalian Persediaan Barang Penilaian REQM Penyedia 2 Penilaian REQM sesuai dengan yang telah ditetapkan pada persiapan penilaian proyek akan mencakup Capability Level REQM Capability Level 1 Penyedia 2 Untuk mencapai REQM capability level 1 diperlukan penilaian terhadap semua Specific Practice (SP) untuk mencapai semua Specific Goal (SG) pada area proses ini. Tabel 5.13 Penilaian REQM CL 1 Penyedia 2 Goal Practice Work Products Result SG 1 SP Surat Penawaran Administrasi dan Teknis (Nomor 56/SPAT-PBJP/MSS/VIII/2013): B. Pendekatan dan Metodologi Sedang - Laporan Pendahuluan (Nomor LP-01-SPPB- SEKNEG-X-2013) : Laporan Perkembangan Proyek (hal 9) - Surat Perjanjian (Nomor Perj-001/PPK/PPBJ- PASPPB/9/2013)

109 93 Goal Practice Work Products Result SP Dokumentasi komitmen terhadap requirements Sedang terekam pada - Surat Perjanjian (Nomor Perj- 001/PPK/PPBJ-PASPPB/9/2013), sedangkan komitmen terhadap requirements changes terekam pada Formulir Perubahan namun dokumentasi lemah. SP Formulir perubahan, belum pernah digunakan utuk Rendah proyek ini SP Tidak ditemukan Rendah SP Tidak ditemukan Rendah GG 1 GP 1.1 Specific practice dari specific goal belum dipenuhi. Rendah Pada tabel 5.13 dapat dilihat bahwa Penyedia 2 belum memenuhi specific practice pada area proses REQM, sehingga belum dapat mencapai capability level 1. Sebagaian specific practice sudah dijalankan namun belum begitu kuat, dikarenakan ada praktek-praktek yang masih kurang dalam mendukung specific practice REQM Capability Level Level 2 Penyedia 2 Untuk mencapai REQM capability level 2 diperlukan penilaian terhadap semua Specific Practice (SP) untuk mencapai semua Specific Goal (SG) dan semua Generic Practice (GP) untuk memenuhi Generic Goal (GG) 2 pada area proses ini. Tabel 5.14 Penilaian REQM CL 2 Penyedia 2 Goal Practice Work Products Result SG 1 SP Surat Penawaran Administrasi dan Teknis (Nomor 56/SPAT-PBJP/MSS/VIII/2013): B. Pendekatan dan Metodologi Sedang - Laporan Pendahuluan (Nomor LP-01-SPPB- SEKNEG-X-2013) : Laporan Perkembangan Proyek (hal 9) - Surat Perjanjian (Nomor Perj-001/PPK/PPBJ- PASPPB/9/2013)

110 94 Goal Practice Work Products Result SP Dokumentasi komitmen terhadap requirements Sedang terekam pada - Surat Perjanjian (Nomor Perj- 001/PPK/PPBJ-PASPPB/9/2013), sedangkan komitmen terhadap requirements changes terekam pada Formulir Perubahan namun dokumentasi lemah. SP Formulir perubahan, belum pernah digunakan utuk Rendah proyek ini SP Tidak ditemukan Rendah SP Tidak ditemukan Rendah GG 1 GP 1.1 Specific practice dari specific goal belum dipenuhi. Rendah GG 2 GP 2.1 Tidak menemukan standar atau kebijakan dari Rendah penyedia terkait Requirements Management GP 2.2 Dokumen Requirements Management tidak cukup Rendah lengkap untuk mendukung dokumen perencanaan GP Tidak ditemukan Rendah GP Surat Penawaran Administrasi dan Teknis (Nomor Sedang 56/SPAT-PBJP/MSS/VIII/2013): B.4 Komposisi Tim dan Penugasan (hal 109), C.2 Surat pernyataan kesediaan untuk ditugaskan dari personil yang diusulkan GP Pelatihan untuk karyawan baru, tidak ada pelatihan Rendah terkait topik REQM GP Kegiatan/dokumen tidak ditemukan Rendah GP Kegiatan dilakukan dengan rapat tapi dokumentasi Rendah tidak ditemukan GP Kegiatan tidak ditemukan Rendah GP Kegiatan dilakukan dengan rapat tapi dokumentasi Rendah tidak ditemukan GP Kegiatan/dokumen tidak ditemukan Rendah Pada Tabel 5.14 dapat terlihat Penyedia 2 tidak dapat mencapai capability level 2 karena tidak dapat memenuhi specific practice dan generic practice yang telah ditentukan Penilaian PP Penyedia 2 Penilaian PP sesuai dengan yang telah ditetapkan pada persiapan penilaian proyek akan mencakup Capability Level 2.

111 PP Capability Level 1 Penyedia 2 Untuk mencapai PP capability level 1 diperlukan penilaian terhadap semua Specific Practice untuk mencapai semua Specific Goal pada area proses ini. Tabel 5.15 Penilaian PP CL 1 Penyedia 2 Goal Practice Work Products Result SG 1 SP Surat Penawaran Administrasi dan Teknis (Nomor 56/SPAT-PBJP/MSS/VIII/2013) : B. Pendekatan dan Metodologi (hal 91) Rendah SP Surat Penawaran Administrasi dan Teknis (Nomor Rendah 56/SPAT-PBJP/MSS/VIII/2013) : B. Pendekatan dan Metodologi (hal 91) SP Rational Unified Process Tinggi (Surat Penawaran Administrasi dan Teknis (Nomor 56/SPAT-PBJP/MSS/VIII/2013) ) B.2.3 Metodologi (117) SP Surat Penawaran Administrasi dan Teknis (Nomor Sedang 56/SPAT-PBJP/MSS/VIII/2013) : B.2.4 Program Kerja (hal 119) - Surat Penawaran Biaya (Nomor 48/SPH- PBJP/MSS/VIII/2013) SG 2 SP Surat Penawaran Administrasi dan Teknis (Nomor Sedang 56/SPAT-PBJP/MSS/VIII/2013) : B.3 Jadwal Pelaksanaan Pekerjaan (hal 108) - Surat Penawaran Biaya (Nomor 48/SPH- PBJP/MSS/VIII/2013) SP 2.2 Tidak ada dokumentasi. Rendah SP Surat Penawaran Administrasi dan Teknis (Nomor Rendah 56/SPAT-PBJP/MSS/VIII/2013) : C. Kebutuhan Fungsionalitas Sistem (97), B.3 Jadwal Pelaksanaan Pekerjaan (108) - Laporan Pendahuluan (Nomor LP-01-SPPB- SEKNEG-X-2013) 4.2 Spesifikasi Perangkat Lunak (12), 3.1 Jadwal Pelaksanaan Pekerjaan (8) SP Surat Penawaran Administrasi dan Teknis (Nomor 56/SPAT-PBJP/MSS/VIII/2013) : B. Pendekatan dan Metodologi (hal 91), B.4 Komposisi Tim dan Penugasan (hal 109), B.2.3 Metodologi (hal 103) - Laporan Pendahuluan (Nomor LP-01-SPPB- SEKNEG-X-2013) 4. Laporan Perkembangan Proyek (9) Rendah

112 96 Goal Practice Work Products Result SP Surat Penawaran Administrasi dan Teknis (Nomor Tinggi 56/SPAT-PBJP/MSS/VIII/2013) : B.4 Komposisi Tim dan Penugasan (hal 109), B.4 Komposisi Tim dan Penugasan (hal 109), C.1. Daftar Riwayat Hidup personil yang diusulkan (hal 126) SP Rapat, tidak terdokumentasi Rendah SP Laporan Pendahuluan (Nomor LP-01-SPPB- Tinggi SEKNEG-X-2013) SG 3 SP Rapat internal, tidak menemukan dokumentasi Rendah SP Tidak ditemukan - Pada pekerjaan dipemerintahan umumnya tidak ada penambahan anggaran dan waktu Rendah SP Surat Perjanjian (Nomor Perj-001/PPK/PPBJ- Sedang PASPPB/9/2013) GG 1 GP 1.1 Specific practice dari specific goal belum dipenuhi. Rendah Pada tabel 5.15 dapat dilihat bahwa Penyedia 2 belum memenuhi specific practice pada area proses PP, sehingga belum dapat mencapai capability level 1. Dari 14 specific practice hanya 3 specific practice yang mendapat skala nilai tinggi PP Capability Level 2 Penyedia 2 Untuk mencapai PP capability level 2 diperlukan penilaian terhadap semua Specific Practice untuk mencapai semua Specific Goal dan semua Generic Practice untuk memenuhi Generic Goal 2 pada area proses ini. Tabel 5.16 Penilaian PP CL 2 Penyedia 2 Goal Practice Work Products Result SG 1 SP Surat Penawaran Administrasi dan Teknis (Nomor 56/SPAT-PBJP/MSS/VIII/2013) : B. Pendekatan dan Metodologi (hal 91) Rendah SP 1.2 SP Surat Penawaran Administrasi dan Teknis (Nomor 56/SPAT-PBJP/MSS/VIII/2013) : B. Pendekatan dan Metodologi (hal 91) - Rational Unified Process (Surat Penawaran Administrasi dan Teknis (Nomor 56/SPAT-PBJP/MSS/VIII/2013) ) Rendah Tinggi

113 97 Goal Practice Work Products Result B.2.3 Metodologi (117) SP Surat Penawaran Administrasi dan Teknis (Nomor Sedang 56/SPAT-PBJP/MSS/VIII/2013) : B.2.4 Program Kerja (hal 119) - Surat Penawaran Biaya (Nomor 48/SPH- PBJP/MSS/VIII/2013) SG 2 SP Surat Penawaran Administrasi dan Teknis (Nomor Sedang 56/SPAT-PBJP/MSS/VIII/2013) : B.3 Jadwal Pelaksanaan Pekerjaan (hal 108) - Surat Penawaran Biaya (Nomor 48/SPH- PBJP/MSS/VIII/2013) SP 2.2 Tidak ada dokumentasi. Rendah SP Surat Penawaran Administrasi dan Teknis (Nomor Rendah 56/SPAT-PBJP/MSS/VIII/2013) : C. Kebutuhan Fungsionalitas Sistem (97), B.3 Jadwal Pelaksanaan Pekerjaan (108) - Laporan Pendahuluan (Nomor LP-01-SPPB- SEKNEG-X-2013) 4.2 Spesifikasi Perangkat Lunak (12), 3.1 Jadwal Pelaksanaan Pekerjaan (8) SP Surat Penawaran Administrasi dan Teknis (Nomor Rendah 56/SPAT-PBJP/MSS/VIII/2013) : B. Pendekatan dan Metodologi (hal 91), B.4 Komposisi Tim dan Penugasan (hal 109), B.2.3 Metodologi (hal 103) - Laporan Pendahuluan (Nomor LP-01-SPPB- SEKNEG-X-2013) 4. Laporan Perkembangan Proyek (9) SP Surat Penawaran Administrasi dan Teknis (Nomor Tinggi 56/SPAT-PBJP/MSS/VIII/2013) : B.4 Komposisi Tim dan Penugasan (hal 109), B.4 Komposisi Tim dan Penugasan (hal 109), C.1. Daftar Riwayat Hidup personil yang diusulkan (hal 126) SP Rapat, tidak terdokumentasi Rendah SP Laporan Pendahuluan (Nomor LP-01-SPPB- Tinggi SEKNEG-X-2013) SG 3 SP Rapat internal, tidak menemukan dokumentasi Rendah SP Tidak ditemukan - Pada pekerjaan dipemerintahan umumnya tidak ada penambahan anggaran dan waktu Rendah SP Surat Perjanjian (Nomor Perj-001/PPK/PPBJ- PASPPB/9/2013) Sedang

114 98 Goal Practice Work Products Result GG 1 GP 1.1 Specific practice dari specific goal belum dipenuhi. Rendah GG 2 GP Surat Penawaran Administrasi dan Teknis (Nomor Tinggi 56/SPAT-PBJP/MSS/VIII/2013) - Laporan Pendahuluan (Nomor LP-01-SPPB- SEKNEG-X-2013) GP Laporan Pendahuluan (Nomor LP-01-SPPB- Tinggi SEKNEG-X-2013) GP Surat Penawaran Administrasi dan Teknis (Nomor Sedang 56/SPAT-PBJP/MSS/VIII/2013): A. Data Pengalaman Perusahaan (hal 6), B.3 Jadwal Pelaksanaan Pekerjaan (hal 108), B.2.2 Pendekatan dan Solusi Teknis (hal 91), B. Pendekatan dan Metodologi (hal 91), B. Pendekatan dan Metodologi (hal 91) GP Surat Penawaran Administrasi dan Teknis (Nomor Sedang 56/SPAT-PBJP/MSS/VIII/2013): B.4 Komposisi Tim dan Penugasan (hal 109), C.2 Surat pernyataan kesediaan untuk ditugaskan dari personil yang diusulkan GP 2.5 Pelatihan teknis, tidak ada pelatihan terkait topik PP Rendah GP Laporan Pendahuluan (Nomor LP-01-SPPB- Rendah SEKNEG-X-2013) GP Data/dokumen tidak ditemukan Rendah GP Tidak ditemukan Rendah GP Kegiatan tidak ditemukan Rendah Pada tabel 5.16 dapat terlihat Penyedia 2 tidak dapat mencapai capability level 2 karena tidak dapat memenuhi semua specific practice dan generic practice yang telah ditentukan Penilaian PMC Penyedia 2 Penilaian PMC sesuai dengan yang telah ditetapkan pada persiapan penilaian proyek akan mencakup Capability Level PMC Capability Level 1 Penyedia 2 Untuk mencapai PMC capability level 1 diperlukan penilaian terhadap semua Specific Practice untuk mencapai semua Specific Goal pada area proses ini.

115 99 Tabel 5.17 Penilaian PMC CL 1 Penyedia 2 Goal Practice Work Products Result SG 1 SP Aplikasi TortoiseSVN. Namun dokumentasi Rendah masih lemah tidak menunjukkan perkembangan requirements. - Web development SP Data/dokumen tidak ditemukan Rendah SP Data/dokumen tidak ditemukan Rendah SP Data/dokumen tidak ditemukan Rendah SP Data/dokumen tidak ditemukan Rendah SP Data/dokumen tidak ditemukan Rendah SP Laporan Pendahuluan (Nomor LP-01-SPPB- Sedang SEKNEG-X-2013) - Laporan Antara - Laporan Akhir Namun dokumentasi kurang lengkap dan tidak begitu jelas. SG 2 SP Data/dokumen tidak ditemukan Rendah SP Data/dokumen tidak ditemukan Rendah SP Tidak ditemukan Rendah GG 1 GP 1.1 Specific practice dari specific goal belum dipenuhi. Rendah Pada tabel 5.17 dapat dilihat bahwa Penyedia 2 belum memenuhi specific practice pada area proses PMC, sehingga belum dapat mencapai capability level PMC Capability Level 2 Penyedia 2 Untuk mencapai PMC capability level 2 diperlukan penilaian terhadap semua Specific Practice untuk mencapai semua Specific Goal dan semua Generic Practice untuk memenuhi Generic Goal 2 pada area proses ini. Tabel 5.18 Penilaian PMC CL 2 Penyedia 2 Goal Practice Work Products Result SG 1 SP Aplikasi TortoiseSVN. Namun dokumentasi masih lemah tidak menunjukkan perkembangan requirements. - Web development Rendah

116 100 Goal Practice Work Products Result SP Data/dokumen tidak ditemukan Rendah SP Data/dokumen tidak ditemukan Rendah SP Data/dokumen tidak ditemukan Rendah SP Data/dokumen tidak ditemukan Rendah SP Data/dokumen tidak ditemukan Rendah SP Laporan Pendahuluan (Nomor LP-01-SPPB- Sedang SEKNEG-X-2013) - Laporan Antara - Laporan Akhir Namun dokumentasi kurang lengkap dan tidak begitu jelas. SG 2 SP Data/dokumen tidak ditemukan Rendah SP Data/dokumen tidak ditemukan Rendah SP Tidak ditemukan Rendah GG 1 GP 1.1 Specific practice dari specific goal belum dipenuhi. Rendah GG 2 GP Data/dokumen tidak ditemukan Rendah GP Data/dokumen tidak ditemukan Rendah GP Laporan accounting Rendah - Laporan Project Manager (Data/dokumen tidak ditemukan) GP Surat Penawaran Administrasi dan Teknis (Nomor Sedang 56/SPAT-PBJP/MSS/VIII/2013): B.4 Komposisi Tim dan Penugasan (hal 109), C.2 Surat pernyataan kesediaan untuk ditugaskan dari personil yang diusulkan GP Pelatihan untuk karyawan baru, tidak ada pelatihan Rendah terkait topik PMC GP Data/dokumen tidak ditemukan Rendah GP Data/dokumen tidak ditemukan Rendah GP Data/dokumen tidak ditemukan Rendah GP Data/dokumen tidak ditemukan Rendah Pada tabel 5.18 dapat dilihat Penyedia 2 belum dapat mencapai capability level 2, karena specific practice dan generic practice yang telah ditentukan belum dapat dipenuhi Penilaian SAM Penyedia 2 Area proses ini tidak dapat dinilai, karena pada proyek ini penyedia tidak melibatkan pihak ketiga. Dari semua specific practice dan generic practice yang ada tidak ada yang dipraktekkan.

117 Hasil Penilaian Penyedia 3 Berikut ini merupakan hasil penilaian terhadap Penyedia 3 yang mengerjakan proyek Pembangunan Aplikasi Sistem Monitoring Masa Berlaku STNK Penilaian REQM Penyedia 3 Penilaian REQM sesuai dengan yang telah ditetapkan pada persiapan penilaian proyek akan mencakup Capability Level REQM Capability Level 1 Penyedia 3 Untuk mencapai REQM capability level 1 diperlukan penilaian terhadap semua Specific Practice (SP) untuk mencapai semua Specific Goal (SG) pada area proses ini. Tabel 5.19 Penilaian REQM CL 1 Penyedia 3 Goal Practice Work Products Result SG 1 SP Surat Penawaran Administrasi dan Teknis (Nomor SP-ADM/2013/SETNEG/VIII/162): Requirement System (hal 375) Sedang - Surat Perjanjian (Nomor Perj-001/PPK/PPBJ- PASMMS/9/2013) - Laporan Awal: 4 PEMAHAMAN KAMI (hal 10) - Pada Surat Penawaran Administrasi dan Teknis (Nomor SP-ADM/2013/SETNEG/VIII/162), 4.2. Pemahaman dan Tanggapan Terhadap Kerangka Acuan Kerja (369) tidak dijabarkan pemahaman dan tanggapan terhadap KAK SP Dokumentasi komitmen terhadap requirements terekam pada - Surat Perjanjian (Nomor 1/PERJANJIAN-ASIP/D-1/PPK/07/2013), sedangkan komitmen terhadap requirements changes terekam padadokumen Minute of Meeting namun dokumentasi lemah. Sedang

118 102 Goal Practice Work Products Result SP Dokumentasi pada dokumen Minute of Meeting Rendah lemah SP Tidak ditemukan Rendah SP Dokumentasi pada dokumen Minute of Meeting Rendah lemah GG 1 GP 1.1 Specific practice dari specific goal belum dipenuhi. Rendah Penyedia 3 belum dapat mencapai capability level 1 karena belum memenuhi specific practice pada area proses REQM, ini dapat terlihat pada tabel REQM Capability Level 2 Penyedia 3 Untuk mencapai REQM capability level 2 diperlukan penilaian terhadap semua Specific Practice (SP) untuk mencapai semua Specific Goal (SG) dan semua Generic Practice (GP) untuk memenuhi Generic Goal (GG) 2 pada area proses ini. Tabel 5.20 Penilaian REQM CL 2 Penyedia 3 Goal Practice Work Products Result SG 1 SP Surat Penawaran Administrasi dan Teknis (Nomor SP-ADM/2013/SETNEG/VIII/162): Requirement System (hal 375) Sedang - Surat Perjanjian (Nomor Perj-001/PPK/PPBJ- PASMMS/9/2013) - Laporan Awal: 4 PEMAHAMAN KAMI (hal 10) - Pada Surat Penawaran Administrasi dan Teknis (Nomor SP-ADM/2013/SETNEG/VIII/162), 4.2. Pemahaman dan Tanggapan Terhadap Kerangka Acuan Kerja (369) tidak dijabarkan pemahaman dan tanggapan terhadap KAK

119 103 Goal Practice Work Products Result SP Dokumentasi komitmen terhadap requirements terekam pada - Surat Perjanjian (Nomor 1/PERJANJIAN-ASIP/D-1/PPK/07/2013), sedangkan komitmen terhadap requirements changes terekam padadokumen Minute of Meeting namun dokumentasi lemah. Sedang SP Dokumentasi pada dokumen Minute of Meeting Rendah lemah SP Tidak ditemukan Rendah SP Dokumentasi pada dokumen Minute of Meeting Rendah lemah GG 1 GP 1.1 Specific practice dari specific goal belum dipenuhi. Rendah GG 2 GP 2.1 Tidak menemukan standar atau kebijakan dari Rendah penyedia terkait Requirements Management GP 2.2 Dokumen Requirements Management tidak cukup Rendah lengkap untuk mendukung dokumen perencanaan GP 2.3 MOM digunakan sebagai alat tracking, namun tidak Rendah cukup kuat sebagai alat tracking GP Surat Penawaran Administrasi dan Teknis (Nomor SP-ADM/2013/SETNEG/VIII/162): BAB VII. BENTUK KOMPOSISI TIM DAN PENUGASAN (414), PERNYATAAN KESEDIAAN UNTUK DITUGASKAN (hal 846) Sedang GP Kegiatan tidak ditemukan Rendah GP Kegiatan didokumentasikan pada dokumen MOM, Rendah namun dokumentasi tidak cukup kuat GP Kegiatan dilakukan dengan rapat dan didokumentasikan pada dokumen MOM, namun dokumentasi tidak cukup kuat Rendah GP Kegiatan tidak ditemukan Rendah GP Kegiatan dilakukan dengan rapat dan didokumentasikan pada dokumen MOM, namun dokumentasi tidak cukup kuat Rendah GP Kegiatan tidak ditemukan Rendah Tabel 5.20 menunjukan Penyedia 3 belum dapat mencapai capability level 2 karena belum dapat memenuhi semua specific practice dan generic practice yang telah ditentukan.

120 Penilaian PP Penyedia 3 Penilaian PP sesuai dengan yang telah ditetapkan pada persiapan penilaian proyek akan mencakup Capability Level PP Capability Level 1 Penyedia 3 Untuk mencapai PP capability level 1 diperlukan penilaian terhadap semua Specific Practice untuk mencapai semua Specific Goal pada area proses ini. Tabel 5.21 Penilaian PP CL 1 Penyedia 3 Goal Practice Work Products Result SG 1 SP Surat Penawaran Administrasi dan Teknis (Nomor Rendah SP-ADM/2013/SETNEG/VIII/162): BAB V. BENTUK URAIAN PENDEKATAN, METODOLOGI DAN PROGRAM KERJA (hal 386) SP Surat Penawaran Administrasi dan Teknis (Nomor SP-ADM/2013/SETNEG/VIII/162): Metodologi :Software Engineering Institute (SEI) CMMI-SE/SW/IPPD/SS, V1.1. tentang rekayasa perangkat lunak (hal 386), Usulan Teknologi (hal 378) Rendah SP 1.3 SP Surat Penawaran Administrasi dan Teknis (Nomor SP-ADM/2013/SETNEG/VIII/162): Software Engineering Institute (SEI) CMMI- SE/SW/IPPD/SS, V1.1. tentang rekayasa perangkat lunak (hal 386) - Surat Penawaran Administrasi dan Teknis (Nomor SP-ADM/2013/SETNEG/VIII/162): 4.3. KONSEP SARAN APLIKASI SISTEM MONITORING MASA BERLAKU STNK (hal 370), Usulan Teknologi (hal 378), KUALIFIKASI TENAGA AHLI (hal 420) - Surat Penawaran Biaya (Nomor SPB/2013/SETNEG/VIII/163) - Pemaparan estimasi usaha proyek masih sangat kurang Tinggi Sedang

121 105 Goal Practice Work Products Result SG 2 SP Surat Penawaran Administrasi dan Teknis (Nomor SP-ADM/2013/SETNEG/VIII/162): Jadwal Pelaksanaan Kegiatan (hal 411) - Surat Penawaran Biaya (Nomor SPB/2013/SETNEG/VIII/163) Sedang SP Tidak ditemukan point [1], [2] dan [3] Rendah SP Surat Penawaran Administrasi dan Teknis (Nomor SP-ADM/2013/SETNEG/VIII/162): Requirement System (hal 375), BAB VI. BENTUK JADWAL PELAKSANAAN PEKERJAAN (hal 409), Jadwal Pelaksanaan Kegiatan (hal 411) Rendah SP 2.4 SP Surat Penawaran Administrasi dan Teknis (Nomor SP-ADM/2013/SETNEG/VIII/162): BAB V. BENTUK URAIAN PENDEKATAN, METODOLOGI DAN PROGRAM KERJA (hal 386), KUALIFIKASI TENAGA AHLI (hal 420), General Technical Requirement (hal 380) - Laporan Awal: 5.2 Flowchart aplikasi (hal 16) tanpa penjelasan - Surat Penawaran Administrasi dan Teknis (Nomor SP-ADM/2013/SETNEG/VIII/162): BAB VII. BENTUK KOMPOSISI TIM DAN PENUGASAN (414), KUALIFIKASI TENAGA AHLI (hal 420), DAFTAR RIWAYAT HIDUP TENAGA AHLI (hal 419) Rendah Tinggi SP Tidak ditemukan Rendah SP 2.7 Laporan Awal Tinggi SG 3 SP Dokumentasi pada dokumen Minute of Meeting Rendah lemah SP Dokumentasi pada dokumen Minute of Meeting lemah - Pada pekerjaan dipemerintahan umumnya tidak ada penambahan anggaran dan waktu Rendah SP Surat Perjanjian (Nomor Perj-001/PPK/PPBJ- Sedang PASMMS/9/2013) GG 1 GP 1.1 Specific practice dari specific goal belum dipenuhi. Rendah

122 106 Pada tabel 5.21 dapat dilihat bahwa Penyedia 3 belum memenuhi specific practice pada area proses PP, sehingga belum dapat mencapai capability level PP Capability Level 2 Penyedia 3 Untuk mencapai PP capability level 2 diperlukan penilaian terhadap semua Specific Practice untuk mencapai semua Specific Goal dan semua Generic Practice untuk memenuhi Generic Goal 2 pada area proses ini. Tabel 5.22 Penilaian PP CL 2 Penyedia 3 Goal Practice Work Products Result SG 1 SP Surat Penawaran Administrasi dan Teknis (Nomor Rendah SP-ADM/2013/SETNEG/VIII/162): BAB V. BENTUK URAIAN PENDEKATAN, METODOLOGI DAN PROGRAM KERJA (hal 386) SP Surat Penawaran Administrasi dan Teknis (Nomor SP-ADM/2013/SETNEG/VIII/162): Metodologi :Software Engineering Institute (SEI) CMMI-SE/SW/IPPD/SS, V1.1. tentang rekayasa perangkat lunak (hal 386), Usulan Teknologi (hal 378) Rendah SP 1.3 SP Surat Penawaran Administrasi dan Teknis (Nomor SP-ADM/2013/SETNEG/VIII/162): Software Engineering Institute (SEI) CMMI- SE/SW/IPPD/SS, V1.1. tentang rekayasa perangkat lunak (hal 386) - Surat Penawaran Administrasi dan Teknis (Nomor SP-ADM/2013/SETNEG/VIII/162): 4.3. KONSEP SARAN APLIKASI SISTEM MONITORING MASA BERLAKU STNK (hal 370), Usulan Teknologi (hal 378), KUALIFIKASI TENAGA AHLI (hal 420) - Surat Penawaran Biaya (Nomor SPB/2013/SETNEG/VIII/163) - Pemaparan estimasi usaha proyek masih sangat kurang Tinggi Sedang

123 107 Goal Practice Work Products Result SG 2 SP Surat Penawaran Administrasi dan Teknis (Nomor SP-ADM/2013/SETNEG/VIII/162): Jadwal Pelaksanaan Kegiatan (hal 411) - Surat Penawaran Biaya (Nomor SPB/2013/SETNEG/VIII/163) Sedang SP Tidak ditemukan point [1], [2] dan [3] Rendah SP Surat Penawaran Administrasi dan Teknis (Nomor SP-ADM/2013/SETNEG/VIII/162): Requirement System (hal 375), BAB VI. BENTUK JADWAL PELAKSANAAN PEKERJAAN (hal 409), Jadwal Pelaksanaan Kegiatan (hal 411) Rendah SP 2.4 SP Surat Penawaran Administrasi dan Teknis (Nomor SP-ADM/2013/SETNEG/VIII/162): BAB V. BENTUK URAIAN PENDEKATAN, METODOLOGI DAN PROGRAM KERJA (hal 386), KUALIFIKASI TENAGA AHLI (hal 420), General Technical Requirement (hal 380) - Laporan Awal: 5.2 Flowchart aplikasi (hal 16) tanpa penjelasan - Surat Penawaran Administrasi dan Teknis (Nomor SP-ADM/2013/SETNEG/VIII/162): BAB VII. BENTUK KOMPOSISI TIM DAN PENUGASAN (414), KUALIFIKASI TENAGA AHLI (hal 420), DAFTAR RIWAYAT HIDUP TENAGA AHLI (hal 419) Rendah Tinggi SP Tidak ditemukan Rendah SP 2.7 Laporan Awal Tinggi SG 3 SP Dokumentasi pada dokumen Minute of Meeting Rendah lemah SP Dokumentasi pada dokumen Minute of Meeting lemah - Pada pekerjaan dipemerintahan umumnya tidak ada penambahan anggaran dan waktu Rendah SP Surat Perjanjian (Nomor Perj-001/PPK/PPBJ- Sedang PASMMS/9/2013) GG 1 GP 1.1 Specific practice dari specific goal belum dipenuhi. Rendah GG 2 GP Surat Penawaran Administrasi dan Teknis (Nomor SP-ADM/2013/SETNEG/VIII/162) - Laporan Awal Tinggi

124 108 Goal Practice Work Products Result GP Laporan Awal Tinggi GP Surat Penawaran Administrasi dan Teknis (Nomor SP-ADM/2013/SETNEG/VIII/162): 1.2 DAFTAR PENGALAMAN KERJA SEJENIS 10 (SEPULUH) TAHUN TERAKHIR (hal 9), Jadwal Pelaksanaan Kegiatan (hal 411), Usulan Teknologi (hal 378), Metodologi :Software Engineering Institute (SEI) CMMI-SE/SW/IPPD/SS, V1.1. tentang rekayasa perangkat lunak (hal 386) - Laporan Awal Sedang GP Surat Penawaran Administrasi dan Teknis (Nomor SP-ADM/2013/SETNEG/VIII/162): BAB VII. BENTUK KOMPOSISI TIM DAN PENUGASAN (hal 414), PERNYATAAN KESEDIAAN UNTUK DITUGASKAN (hal 846) Sedang GP Kegiatan tidak ditemukan Rendah GP Laporan Awal Rendah GP Tidak ditemukan Rendah GP Tidak ditemukan Rendah GP Kegiatan tidak ditemukan Rendah Dari tabel 5.22 sudah diketahui Penyedia 3 tidak dapat mencapai capability level 2 karena tidak dapat memenuhi semua specific practice dan generic practice yang telah ditentukan pada area proses PP Penilaian PMC Penyedia 3 Penilaian PMC sesuai dengan yang telah ditetapkan pada persiapan penilaian proyek akan mencakup Capability Level PMC Capability Level 1 Penyedia 3 Untuk mencapai PMC capability level 1 diperlukan penilaian terhadap semua Specific Practice untuk mencapai semua Specific Goal pada area proses ini.

125 109 Tabel 5.23 Penilaian PMC CL 1 Penyedia 3 Goal Practice Work Products Result SG 1 SP Website Trello (data tidak dapat ditunjukkan) - Dokumentasi pada dokumen Minute of Meeting lemah Rendah SP Tidak ditemukan - Menurut penyedia terdapat pada dokumen Minute of Meeting (dokumentasi lemah) Rendah SP Tidak ditemukan Rendah SP Tidak ditemukan Rendah SP Dokumentasi pada dokumen Minute of Meeting Sedang lemah SP Tidak ditemukan Rendah SP Laporan Awal, Laporan Antara, dan Laporan Akhir. Namun dokumentasi kurang lengkap dan tidak begitu jelas. Sedang - Website Trello (data tidak dapat ditunjukkan) SG 2 SP Tidak ditemukan Rendah SP Tidak ditemukan Rendah - Website Trello dan catatan internal (data tidak dapat ditunjukkan) SP Website Trello (data tidak dapat ditunjukkan) Rendah GG 1 GP 1.1 Specific practice dari specific goal belum dipenuhi. Rendah Pada tabel 5.23 dapat dilihat bahwa Penyedia 3 belum memenuhi specific practice pada area proses PMC, sehingga belum dapat mencapai capability level PMC Capability Level 2 Penyedia 3 Untuk mencapai PMC capability level 2 diperlukan penilaian terhadap semua Specific Practice untuk mencapai semua Specific Goal dan semua Generic Practice untuk memenuhi Generic Goal 2 pada area proses ini.

126 110 Tabel 5.24 Penilaian PMC CL 2 Penyedia 3 Goal Practice Work Products Result SG 1 SP Website Trello (data tidak dapat ditunjukkan) - Dokumentasi pada dokumen Minute of Meeting lemah Rendah SP Tidak ditemukan - Menurut penyedia terdapat pada dokumen Minute of Meeting (dokumentasi lemah) Rendah SP Tidak ditemukan Rendah SP Tidak ditemukan Rendah SP Dokumentasi pada dokumen Minute of Meeting Sedang lemah SP Tidak ditemukan Rendah SP Laporan Awal, Laporan Antara, dan Laporan Akhir. Namun dokumentasi kurang lengkap dan tidak begitu jelas. Sedang - Website Trello (data tidak dapat ditunjukkan) SG 2 SP Tidak ditemukan Rendah SP Tidak ditemukan Rendah - Website Trello dan catatan internal (data tidak dapat ditunjukkan) SP Website Trello (data tidak dapat ditunjukkan) Rendah GG 1 GP 1.1 Specific practice dari specific goal belum dipenuhi. Rendah GG 2 GP 2.1 Standar atau kebijakan terkait Project Monitoring & Rendah Control tidak kuat GP 2.2 Kegiatan tidak kuat dan dokumentasi tidak lengkap Rendah GP Laporan Awal: Rendah 7 JADWAL DAN TAHAPAN PELAKSANAAN (36) GP Surat Penawaran Administrasi dan Teknis (Nomor SP-ADM/2013/SETNEG/VIII/162): BAB VII. BENTUK KOMPOSISI TIM DAN PENUGASAN (hal 414), PERNYATAAN KESEDIAAN UNTUK DITUGASKAN (hal 846) Sedang GP Kegiatan tidak ditemukan Rendah GP Kegiatan tidak ditemukan Rendah

127 111 Goal Practice Work Products Result GP Kegiatan dilakukan dengan rapat dan didokumentasikan pada dokumen MOM, namun dokumentasi tidak cukup kuat Rendah GP Kegiatan tidak ditemukan Rendah GP Kegiatan tidak ditemukan Rendah Dari tabel 5.24 diketahui Penyedia 3 tidak dapat mencapai capability level 2 karena tidak dapat memenuhi semua specific practice dan generic practice yang telah ditentukan ada pada area proses PMC Penilaian SAM Penyedia 3 Area proses ini tidak dapat dinilai, karena pada proyek ini penyedia tidak melibatkan pihak ketiga. Dari semua specific practice dan generic practice yang ada tidak ada yang dipraktekkan. 5.8 Profil Capability Level Merujuk hasil dari penilaian pada area proses yang telah ditentukan terhadap ketiga penyedia, dapat diketahui profil Capability Level pada masing-masing Penyedia sebagai berikut: Penyedia 1 Penyedia 2 Penyedia 3 Ekspektasi 0 REQM PP PMC SAM Gambar 5.1 Profil Capability Level

128 112 Berdasarkan hasil penilaian penyedia 1 untuk area proses Requirements Management masih berada pada capability level 0, karena belum dapat memenuhi specific practice yang disyaratkan walaupun sudah ada beberapa praktek yang dijalankan. Untuk area proses Project Planning, penyedia 1 walaupun sudah menjalankan beberapa praktek namun belum dapat memenuhi specific practice yang disyaratkan, sehingga masih berada pada capability level 0. Pada area proses Project Monitoring and Control, specific practice yang disyaratkan juga belum dapat dipenuhi meskipun ada beberapa praktek yang sudah dijalankan, sehingga untuk area proses ini penyedia 1 masih di capability level 0. Sedangkan untuk area proses Supplier Agreement Management tidak dapat dinilai karena penyedia 1 pada pengerjaannya tidak melibatkan pihak ketiga. Dari hasil penilaian dapat dilihat ada beberapa praktek yang sudah dijalankan oleh penyedia 2 untuk area proses Requirements Management, namun penyedia 2 belum dapat memenuhi specific practice yang disyaratkan, sehingga untuk area proses ini penyedia 2 masih berada pada capability level 0. Untuk area proses Project Planning, penyedia 2 masih berada pada capability level 0 karena belum dapat memenuhi specific practice yang disyaratkan. Pada area proses Project Monitoring and Control, meskipun ada beberapa praktek yang sudah dijalankan namun belum dapat memenuhi specific practice yang disyaratkan, sehingga untuk area proses ini penyedia 2 masih di capability level 0. Karena penyedia 2 pada pengerjaannya tidak melibatkan pihak ketiga maka untuk area proses Supplier Agreement Management tidak dapat dinilai. Terakhir hasil penilaian terhadap penyedia 3 menunjukkan ada beberapa praktek yang sudah dijalankan untuk area proses Requirements Management, namun praktek-praktek itu belum memenuhi specific practice yang disyaratkan, sehingga untuk area proses ini penyedia 3 masih berada pada capability level 0. Pada area proses Project Planning, penyedia 3 belum dapat memenuhi specific practice yang disyaratkan sehingga masih berada pada capability level 0. Untuk area proses Project Monitoring and Control, penyedia 3 belum dapat memenuhi specific practice yang disyaratkan, sehingga untuk area proses ini penyedia 3 masih di capability level 0. Sama dengan kedua penyedia sebelumnya, dalam

129 113 pengerjaan proyek penyedia 3 tidak melibatkan pihak ketiga sehingga untuk area proses Supplier Agreement Management tidak dapat dinilai. Dengan ekspektasi semua penyedia dapat mencapai capability level 2, dari hasil penilaian menunjukkan bahwa semua penyedia belum dapat memenuhi specific practice dan generic practice yang telah ditentukan pada masing-masing area proses, sehingga hasilnya semua penyedia yang dinilai masih berada pada capability level 0 atau incomplete. Masih banyak specific practice yang belum diimplementasikan pada para penyedia dimana fungsi specific practice itu dapat menjadi pengontrol untuk meminimalisir terjadinya kesalahan. Dari hasil ini, upaya mendorong peningkatan kualitas untuk penyedia kedepannya bisa fokus pada pemenuhan capability level 1 atau memenuhi semua specific practice pada area proses yang telah ditentukan sesuai kebutuhan organisasi. 5.9 Verifikasi Kebutuhan Penilaian Selanjutnya dilakukasn verifikasi kebutuhan terhadap specific practice yang akan menjadi kerangka penyusunan penilaian penyedia jasa konsultasi perangkat lunak untuk kedepannya. Mengacu pada hasil penilaian, verifikasi ini akan berfokus pada pemenuhan capability level 1, hanya specific practice pada area proses Requirements Management, Project Planning, Project Monitoring and Control, dan Supplier Agreement Management yang akan menjadi bahan verifikasi. Verifikasi melibatkan semua panitia dan pemeriksa dari proyek pengembangan perangkat lunak yang memiliki latar belakang pendidikan teknologi informasi dan pekerjaan yang sangat berkaitan dengan teknologi informasi. Keseluruhan orang yang di verifikasi berjumlah tujuh orang, yang terdiri satu kepala bagian, dua kepala subbagian, dan empat pranata komputer. Semuanya merupakan praktisi teknologi informasi di unit kerja Asisten Deputi Dukungan Data Kebijakan dan Informatika yang merupakan unit kerja yang menangani kebutuhan, perencanaan, pengadaan dan pemeliharaan teknologi informasi di Kementerian Sekretariat Negara. Dari tujuh orang yang dimintai keterangannya, tiga orang berlatar belakang pendidikan S2 teknologi informasi dan empat orang berlatar belakang S1 teknlogi informasi. Verifikasi dilakukan dengan menyebar daftar specific

130 114 practice yang akan diberikan skala nilai dari yang sangat tidak penting, tidak penting, cukup penting, penting, dan sangat penting. Dari semua hasil yang diterima akan dihitung rata-ratanya yang menjadi gambaran hasil dari kegiatan verifikasi. Berikut ini adalah hasil verifikasi: Tabel 5.25 Verifikasi REQM Goal Practice Rata-rata Hasil Verifikasi SG 1 SP Sangat Penting SP Penting SP Penting SP Penting SP Penting Tabel 5.25 merupakan verifikasi terhadap area proses Requirements Management. Dari lima specific practice,empat praktek hasilnya penting dan satu praktek hasilnya sangat penting. Satu praktek yang hasilnya sangat penting berkaitan dengan praktek pemahaman terhadap kebutuhan dari pengguna. Pada area proses Requirements Management, para panitia dan pemeriksa lelang menekankan sangat pentingnya pemahaman penyedia terhadap kebutuhan dari pengguna, praktek ini sangat mendasar karena akan menjadi acuan dalam pembangunan perangkat lunak dan terpakainya perangkat lunak yang terbangun karena sesuai kebutuhan dari pengguna. Tabel 5.26 Verifikasi PP Goal Practice Rata-rata Hasil Verifikasi SG SP Penting 1 SP Penting SP Penting SP Sangat Penting SG 2 SP Sangat Penting SP Penting

131 115 Goal Practice Rata-rata Hasil Verifikasi SP Penting SP Penting SP Penting SP Penting SP Penting SG SP Penting 3 SP Cukup Penting SP Penting Tabel 5.26 merupakan verifikasi terhadap area proses Project Planning. Empat parakte pada specific goal 1 tentang Establish Estimates, tiga hasilnya penting dan satu hasilnya sangat penting. Satu yang dinilai sangat penting merupakan praktek Estimate Effort and Cost. Pada specific goal 2 tentang Develop a Project Plan, dari tujuh praktek hasilnya enam penting dan satu sangat penting. Satu yang sangat penting merupakan specific practice 2.1 tentang Establish the Budget and Schedule. Dan pada specific goal 3 tentang Obtain Commitment to the Plan, dari tiga praktek hasilnya dua penting dan satu cukup penting. Pada area proses ini para panitia dan pemeriksa lelang menekankan sangat pentingnya praktek terkait estimasi usaha dan biaya dalam proyek, dari estimasi usaha dapat diketahui kegiatan dan fasilitas pendukung yang diusahakan dalam menjalankankan proyek. Tabel 5.27 Verifikasi PMC Goal Practice Rata-rata Hasil Verifikasi SG SP Penting 1 SP Penting SP Penting SP Penting SP Penting SP Penting SP Penting SG SP Penting 2 SP Penting SP Cukup Penting

132 116 Tabel 5.27 merupakan verifikasi terhadap area proses Project Monitoring and Control. Pada specific goal 1 tentang Establish the Budget and Schedule, hasilnya penting semua pada setiap praktek. Sedangkan pada specific goal 2, hasilnya dua praktek penting dan satu praktek cukup penting. Hasil dari area proses Project Monitoring and Control menunjukkan panitia dan pemeriksa lelang menganggap penting hampir semua praktek yang ada pada area proses ini, hanya specific practice 2.3 yang dianggap cukup penting. Specific practice 2.3 berkaitan dengan penglolaan tindakan korektif terhadap kegiatan yang tidak sesuai dengan rencana. Tabel 5.28 Verifikasi SAM Goal Practice Rata-rata Hasil Verifikasi SG 1 SP Cukup Penting SP Penting SP Penting SG SP Penting 2 SP Cukup Penting SP Cukup Penting Tabel 5.28 merupakan verifikasi terhadap area proses Supplier Agreement Management. Pada specific goal 1 tentang Establish Supplier Agreements, hasilnya dua praktek dianggap penting dan satu dianggap cukup penting. Sedangkan pada specific goal 2 tentang Satisfy Supplier Agreements, hasilnya dua praktek dianggap cukup penting dan satu praktek dianggap penting Analisis Hubungan Masalah, Hasil Penilaian, dan Hasil Verifikasi Pada tahap ini dilakukan analisis terhadap data masalah, hasil penilaian terhadap penyedia, dan hasil verifikasi dari panitia dan pemeriksa lelang. Data masalah merupakan gambaran permasalahan atau kelemahan yang terdapat pada pengembangan perangkat lunak melalui lelang yang melibatkan penyedia jasa

133 117 konsultasi perangkat lunak. Selain menggambarkan permasalahan yang ada, data masalah juga menunjukkan harapan agar masalah yang ada dapat selesai atau tidak ditemukan lagi dikemudian hari, serta bisa mendapatkan kualitas proses pengembangan perangkat lunak yang lebih baik. Data masalah yang ada diberi kode pada tabel Tabel 5.29 Data Masalah Kode Masalah Masalah M1 Kurangnya pemahaman penyedia terhadap kebutuhan pengguna M2 M3 M4 M5 Penyedia tidak memperhatikan ruang lingkup pekerjaan Sumber daya penyedia tidak sesuai dengan yang ditawarkan Pelaksanaan pekerjaan tidak sesuai jadwal Aplikasi yang tidak siap atau masih ada yang kurang Data hasil penilaian terhadap para penyedia digunakan sebagai gambaran keadaan proses pengembangan perangkat lunak melalui lelang tahun ini. Dengan mengetahui hasil penilaian dengan CMMI, data yang ada dapat digunakan sebagai bahan evaluasi penyeleksian kedepannya, dimana kedepannya dapat ditentukan standar minimal dari penyedia yang ingin mengerjakan proyek pengembangan perangkat lunak di Kementerian Sekretariat Negara. Dalam menentukan standar ini dapat mengacu pada CMMI. Data hasil verifikasi merupakan pendapat dari tenaga teknis dan ahli di lapangan yang memilki tugas menjalankan proses lelang perangkat lunak dan pemeriksa hasil lelang perangkat lunak. Data verifikasi untuk mengkonfirmasi kebutuhan terhadap praktek-praktek dalam pengembangan perangkat lunak yang perlu untuk dinilai oleh panitia dan penyedia, serta praktek-praktek minimal yang harus dilakukan oleh penyedia.

134 118 Berkaitan dengan hasil penilaian terhadap penyedia dimana hasil pada penilaian tersebut para penyedia masih berada di level 0 atau incomplete, maka analisis ini fokus pada semua specific practice yang ada pada semua specific goal pada area proses yang telah ditentukan, yaitu Requirements Management, Project Planning, Project Monitoring and Control, dan Supplier Agreement Management. Rekomendasi nilai minimal mengacu pada skala karakter penilaian SCAMPI C, sama seperti skala karakter yang digunakan pada penilaian terhadap penyedia. Bedanya pada penilaian terhadap penyedia menunjukkan nilai dari penyedia, sedangkan pada rekomendasi merupakan rekomendasi nilai minimal yang harus dipenuhi penyedia nantinya pada penilaian yang menggunakan kerangka ini. Skala karekter penilaian dan penjelasan rekomendai dapat dilihat pada tabel Tabel 5.30 Skala Karakter Rekomendasi Skala Keterangan Skala Nilai Nilai Rendah Tujuan dari praktek model dinilai tidak ada, atau tidak cukup dibahas dalam pendekatan, pencapaian tujuan yang dinilai tidak mungkin karena tidak adanya atau kekurangan. Sedang Tujuan dari praktek model dinilai secara parsial dibahas dalam pendekatan, dan hanya dukungan dengan terbatas untuk pencapaian tujuan jelas. Tinggi Tujuan dari praktek model dinilai ditangani secara memadai dalam serangkaian praktek (direncanakan atau digunakan), dengan cara yang mendukung pencapaian tujuan dalam Keterangan Rekomendasi Penyedia tidak harus memenuhi praktek ini, namun bila praktek ini dipenuhi akan menambah nilainya. Penyedia diwajibkan memenuhi praktek dengan skala minimal sedang. Bila tidak memenuhi nilai minimal sedang, maka dianggap penyedia tidak memenuhi kriteria minimal. Penyedia diwajibkan memenuhi praktek dengan skala minimal tinggi. Bila tidak memenuhi nilai minimal tinggi, maka dianggap

135 119 Skala Nilai Keterangan Skala Nilai Keterangan Rekomendasi konteks proses yang diberikan. penyedia tidak memenuhi kriteria minimal. Analisis keterhubungan data ini akan memperhatikan masalah yang ada yang akan menjadi dasar dalam memberikan rekomendasi nilai minimal. Karena analisis ini ditujukan untuk memperbaiki proses yang bermasalah pada kegiatan pengembangan penyedia, dan mendorong calon penyedia atau penyedia terpilih untuk memperhatikan proses pengembangan perangkat lunak yang selama ini bermasalah. Analisis lalu didukung oleh keadaan penyedia pada tahun 2013, atau hasil penilaian kapasitas penyedia pada tahun Hal ini menjadi dasar kemampuan dari penyedia dalam menjalankan praktek yang dinilai, sehingga rekomendasi nilai juga akan memperhatikan kemampuan penyedia berdasarkan hasil penilaian kapasitas pada tahun Terakhir analisis akan memperhatikan masukan dari panitia dan pemeriksa lelang perangkat lunak yang telah ditentukan, untuk memberikan pendapatnya melalui kegiatan verifikasi. Disini panitia dan pemeriksa lelang perangkat lunak akan memberikan skala penilaian mulai dari sangat tidak penting, tidak penting, cukup penting, penting dan sangat penting terkait specific practice yang diperlukan dalam menilai kapasitas dari penyedia. Hasil verifikasi merupakan rata-rata penilaian dari panita dan pemeriksa lelang perangkat lunak. Hasil verifikasi akan menguatkan rekomendasi nilai minimal untuk penyedia. Berikut ini merupakan analisis hubungan antara specific goal, specific practice, data masalah, hasil penilaian terhadap penyedia, hasil verifikasi dari panitia dan pemeriksa lelang, dan rekomendasi nilai minimal yang akan digunakan pada kerangka penilaian terhadap penyedia Keterhubungan Data Dalam REQM Pada tabel 5.31 dapat kita lihat specific practice (SP) 1.1 atau praktek Understand Requirements, terdapat masalah yang berkaitan dengan praktek ini, yaitu tentang

136 120 kurangnya pemahaman penyedia terhadap kebutuhan. Hasil penilaian terhadap para penyedia pada SP 1.1 adalah sedang untuk semua penyedia. Disini menunjukkan penyedia telah memiliki kegiatan atau dokumen yang memperlihatkan bahwa mereka sudah melakukan praktek ini walaupun belum maksimal. Sedangkan hasil verifikasi terhadap panitia dan pemeriksa lelang menekankan sangat pentingnya praktek ini. Berdasarkan data tersebut dan melihat praktek ini sangat mendasar maka direkomendasikan praktek ini wajib dilakukan dengan nilai minimal sedang. Masih di tabel 5.31, pada SP 1.2 sampai dengan SP 1.5 tidak ditemukan keterkaitan dengan masalah, namun hasil verifikasi menunjukkan bahwa praktekpraktek ini adalah penting. Hasil penilaian terhadap penyedia juga beragam, untuk SP 1.2 hasilnya sedang semua, SP 1.3 hasilnya rendah semua, SP 1.4 hasilnya rendah semua, dan SP1.5 hasilnya satu penyedia sedang dan dua penyedia rendah. Untuk SP 1.2 sampai SP 1.5 direkomendasikan nilai minimal rendah, atau tidak ada kewajiban untuk memenuhi praktek-praktek ini bagi penyedia, namun bila praktek ini dipenuhi akan menambah nilai penialaian.

137 121 Tabel 5.31 Keterhubungan Data Dalam REQM Goal Practice Kode Masalah Hasil Penilaian Penyedia 1 Penyedia 2 Penyedia 3 Hasil Verifikasi Rekomendasi SG 1 SP 1.1 M1 Sedang Sedang Sedang Sangat Penting Sedang SP 1.2 Sedang Sedang Sedang Penting Rendah SP 1.3 Rendah Rendah Rendah Penting Rendah SP 1.4 Rendah Rendah Rendah Penting Rendah SP 1.5 Sedang Rendah Rendah Penting Rendah

138 Keterhubungan Data Dalam PP Tabel 5.32 memperlihakan tentang data analisis area proses Project Planning, pada SG 1 Establish Estimates dari empat praktek hanya satu praktek yang tidak terkait dengan masalah yang ada. SP 1.1 Estimate the Scope of the Project dan SP 1.2 Establish Estimates of Work Product and Task Attributes terkait dengan masalah penyedia tidak memperhatikan ruang lingkup pekerjaan, sedangkan SP 1.4 Estimate Effort and Cost terkait dengan masalah pelaksanaan pekerjaan tidak sesuai jadwal. Hasil penilaian penyedia SP 1.1 adalah rendah dengan hasil verifikasi penting. Memperhatikan data yang ada dan estimasi ruang lingkup merupakan kebutuhan dasar proyek, maka direkomendasikan untuk SP 1.1 penyedia wajib memenuhi nilai minimal sedang. Hasil penilaian terhadap penyedia SP 1.2, satu penyedia hasilnya sedang dan dua penyedia hasilnya rendah, dengan hasil verifikasi penting. Berdasarkan data yang ada dan memperhatikan SP 1.2 tidak hanya berkaitan dengan masalah ruang lingkup penyedia tapi berpengaruh juga kelangkapan atau kesiapan dari aplikasi yang dibangun, maka direkomendasikan nilai minimal SP 1.2 sedang. SP 1.3 tidak terkait dengan masalah yang ada, hasil dari penilaian terhadap penyedia pun semuanya tinggi. Hal ini menunjukkan SP 1.3 sudah menjadi praktek umum pada penyedia tahun ini. Hasil verifikasi untuk SP 1.3 penting, maka untuk SP 1.3 direkomendasikan para penyedia wajib mengadakan praktek ini dengan minimal nilai sedang. Pada SP 1.4 satu penyedia memiliki nilai tinggi dan dua penyedia memiliki rendah. Praktek dari SP 1.4 biasanya dijabarkan pada dokumen penawaran teknis dan biaya. Pada dokumen tersebut dijabarkan usaha-usaha apa yang akan penyedia lakukan dalam mengembangkan proyek, dan penawaran harga terkait dengan proyek. Namun pada kenyataannya apa yang ditawarkan kadang tidak sesuai, usaha yang seharusnya dilakukan tidak dilakukan sehingga terjadi ketidaksesuain dengan jadwal kerja. Hal ini juga dikonfirmasi oleh para panitia dan pemeriksa bahwal praktek ini sangat penting. Memperhatikan data yang ada,

139 123 maka direkomendasikan SP 1.4 wajib dilakukan penyedia dengan minimal nilai sedang. SG 2 Develop a Project Plan pada area proses Project Planning memiliki tujuh SP. Empat dari tujuh SP memiliki keterkaitan dengan masalah yaitu SP 2.1 Establish the Budget and Schedule dan SP 2.7 Establish the Project Plan berkaitan dengan maslah pelaksanaan pekerjaan yang tidak sesuai jadwal, dan SP 2.4 Plan the Project s Resources dan SP 2.5 Plan Needed Knowledge and Skills berkaitan dengan masalah sumber daya penyedia tidak sesuai dengan yang ditawarkan. Sedangkan SP yang tidak berkaitan dengan masalah adalah SP 2.2 Identify Project Risks, SP 2.3 Plan Data Management, dan SP 2.6 Plan Stakeholder Involvement. Tidak adanya keterkaitan dengan masalah yang ada saat ini bukan berarti ketiga SP itu tidak penting, ketiga SP itu juga penting dan bermasalah pada penyedia tahun ini. Hal ini dapat dilihat pada hasil penilaian terhadap penyedia terhadap SP tersebut yang mendapat nilai rendah semua. Terhadap ketiga SP yang tidak terkait dengan masalah yang ada sekarang, panitia dan pemeriksa mengkonfirmasi bahwa SP tersebut penting. Memperhatikan saat ini belum ada masalah yang terkait dengan SP 2.2, SP 2.3, dan SP 2.6, dan belum siapnya mengimplementasikan praktek-praktek tersebut secara optimal, maka direkomendasikan untuk SP 2.2, SP 2.3, dan SP 2.6 nilai minimalnya rendah. Hasil penilaian terhadap penyedia pada SP 2.1 semuanya sedang, dengan hasil verifikasi sangat penting. Dalam pengembangan melalui lelang di Kementerian Sekretariat Negara, hal-hal yang tidak dapat berubah atau bertambah adalah biaya dan waktu pengembangan yang telah ditentukan, oleh karenanya penting bagi penyedia memperhatikan kedua hal tersebut. Berkaitan dengan biaya dan waktu yang tidak dapat berubah, pada SP 2.1 direkomendasikan penyedia wajib memenuhi praktek ini dengan minimal nilai sedang. Pada SP 2.4 hasil penilaian terhadap penyedia adalah satu penyedia hasilnya sedang dan dua penyedia hasilnya rendah, dengan hasil verifikasi dari panitia dan pemriksa hasilnya penting. Untuk SP 2.4 direkomendasikan penilaian minimalnya sedang.

140 124 Untuk sebuah lelang pengembangan perangkat lunak, pengajuan atau penawaran terhadap tenaga ahli sangat penting. Keahlian, pendidikan, jabatan dan pengalaman menjadi penilaian utama terhadap tenaga ahli, oleh karenanya pada SP 2.5 hasil penilaian terhadap penyedia tinggi semua, dan verifikasi dari panitia dan pemeriksa mengkonfirmasi bahwa praktek ini penting. Memperhatikan praktek ini sudah menjadi keharusan pada setiap lelang pengembangan perangkat lunak, maka direkomendasikan untuk SP 2.5 wajib dipenuhi oleh penyedia dengan nilai minimal tinggi. Pada pengembangan proses lelang para penyedia diharuskan menyerahkan rencana kerja pada laporan awal, walaupun pada dokumen teknis biasanya penyedia sudah memberikan gambaran secara umum terkait rencana pengembangan yang ditawarkan. Dapat dilihat pada SP 2.7 penilaian terhadap penyedia memiliki hasil tinggi semua, dengan verifikasi dari panitia dan pemeriksa hasilnya penting. Maka untuk SP 2.7 direkomendasikan prakteknya wajib dipenuhi oleh penyedia dengan nilai minimal tinggi. SG 3 Obtain Commitment to the Plan pada area proses Project Planning terdiri dari SP 3.1 Review Plans That Affect the Project, SP 3.2 Reconcile Work and Resource Levels, dan SP 3.3 Obtain Plan Commitment. Hasil penilaian terhadap penyedia terhada ketiga SP tersebut, hasil rendah untuk semua penyedia pada SP 3.1 dan Sp 3.2, sedangnkan pada SP 3.3 hasilnya sedang untuk semua penyedia. Untuk hasil verifikasi dari panitia dan pemeriksa lelang, SP 3.1 dan SP 3.3 hasilnya penting, sedangkan untuk SP 3.2 hasilnya cukup penting. Praktekpraktek pada SG 3 merupakan praktek-praktek penting dalam menjaga komitmen terhadap rencana yang sudah disepakati, namun melihat data yang ada, untuk SP 3.1, SP 3.2, dan SP 3.3 direkomendasikan nilai minimalnya rendah.

141 125 Tabel 5.32 Keterhubungan Data Dalam PP Goal Practice Kode Masalah Hasil Penilaian Penyedia 1 Penyedia 2 Penyedia 3 Hasil Verifikasi Rekomendasi SG 1 SP 1.1 M2 Rendah Rendah Rendah Penting Sedang SP 1.2 M2 Sedang Rendah Rendah Penting Sedang SP 1.3 Tinggi Tinggi Tinggi Penting Sedang SP 1.4 M4 Tinggi Sedang Sedang Sangat Penting Sedang SG 2 SP 2.1 M4 Sedang Sedang Sedang Sangat Penting Sedang SP 2.2 Rendah Rendah Rendah Penting Rendah SP 2.3 Rendah Rendah Rendah Penting Rendah SP 2.4 M3 Sedang Rendah Rendah Penting Sedang SP 2.5 M3 Tinggi Tinggi Tinggi Penting Tinggi SP 2.6 Rendah Rendah Rendah Penting Rendah SP 2.7 M4 Tinggi Tinggi Tinggi Penting Tinggi SG 3 SP 3.1 Rendah Rendah Rendah Penting Rendah SP 3.2 Rendah Rendah Rendah Cukup Penting Rendah SP 3.3 Sedang Sedang Sedang Penting Rendah

142 Keterhubungan Data Dalam PMC Analisis keterhubungan data pada area proses Project Monitoring and Control terlihat pada tabel SG 1 Monitor the Project Against the Plan dari area proses PMC terdiri dari tujuh SP, lima SP memiliki keterhubungan dengan masalah dan sisanya tidak memiliki keterhubungan dengan masalah yang ada. Dua SP yang tidak memiliki keterhubungan dengan masalah adalah SP 1.3 Monitor Project Risks dan SP 1.5 Monitor Stakeholder Involvement. Namun pada kedua SP tersebut para penyedia mendapatkan nilai yang rendah. Disini kita bisa melihat SP yang tidak ada hubungannya dengan masalah yang ada bukan berati tidak penting, tetapi bisa jadi masalah terkait SP tersebut bukan masalah yang sering ditemukan, belum memahami kepentingan penanganan dari maslah, atau bukan menjadi perhatian khusus dari organisasi. Untuk SP 1.3 dan SP 1.5 memiliki nilai verifikasi penting dari panitia dan pemerksa lelang. Berdasarkan data yang ada, direkomendasikan untuk SP 1.3 dan SP 1.5 nilainya rendah. SP 1.1 Monitor Project Planning Parameters, SP 1.2 Monitor Commitments, SP 1.4 Monitor Data Management, SP 1.6 Conduct Progress Reviews, dan SP 1.7 Conduct Milestone Reviews memiliki keterhubungan dengan masalah pelaksanaan pekerjaan tidak sesuai jadwal. Masalah pelaksanaan pekerjaan yang tidak sesuai jadwal dapat menyebabkan keterlambatan penyelesaian pekerjaan atau bahkan kegagalan dan penyelesaian pekerjaan. Untuk SP 1.6 dan SP 1.7 keterhubungan masalah ditambahkan dengan masalah aplikasi yang tidak siap atau masih ada yang kekurangan pada aplikasi. Hasil penilaian terhadap para penyedia pada SP 1.1, SP 1.2, dan SP 1.4 adalah rendah. Penyedia sangat rendah dalam melakukan praktek pemantauan terhadap rencana proyek, komitmen, dan manajemen data. Sedangkan hasil dari verifikasi dari panitia dan pemeriksa lelang untuk SP 1.1, SP 1.2, dan SP 1.4 dianggap penting. Berdasarkan data yang ada, maka direkomendasikan untuk SP 1.1, SP 1.2, dan SP 1.4, penyedia wajib memenuhi nilai minimal sedang. Rekomendasi sedang ditujukan agar ada peningkatan kualitas dari penyedia dalam mekakukan praktek pemantauan, dimana prektekpraktek pemantauan tersebut juga dapat terdokumentasi dengan baik.

143 127 Hasil penilaian terhadap penyedia pada SP 1.6 adalah satu penyedia hasilnya sedang, dan dua penyedia hasilnya rendah. Panitia dan pemeriksa lelang mengkonfirmasi bahwa SP 1.6 penting. Pada pelaksanaannya untuk para penyedia tahun ini melakukan pelaporan kemajuan dari proyek pada rapat-rapat, namun laporan tersebut tidak dibuat dalam dokumen yang lengkap dan terintegrasi dengan data requirements. Sehingga sulit menelusuri asal dari kebutuhan dasarnya dan bila ada perubahan sejarah dari perubahannya sulit untuk ditelusuri, kalaupun bisa ditelusuri membutuhkan waktu dan membutuhkan membuka-buka beberapa dokumen yang berbeda. Untuk SP 1.6 direkomendasikan nilai minimal yang harus dipenuhi penyedia nantiya minimal sedang. Hasil penilaian terhadap penyedia pada SP 1.7, semua penyedia memiliki nilai sedang, dengan hasil verifikasi dari panitia dan pemeriksa lelang penting. Selama ini para penyedia tidak menentukan milstone sendiri, tetapi mengikuti pola waktu pelaporan dari panitia yaitu waktu menyerahkan laporan pendahuluan, laporan antara, dan laporan akhir. Padahal akan sangat baik apabila penyedia berinisiatif membuat milstone yang lebih lengkap sesuai kebutuhan proyek, sehingga distribusi laporan tidak menumpuk pada satu waktu. Terhadap SP 1.7 direkomendasikan para penyedia harus memenuhi nilai minimal sedang. SG 2 Manage Corrective Action to Closure pada area proses Project Monitoring and Control memiliki tiga praktek, dua praktek yaitu SP 2.2 Take Corrective Action dan SP 2.3 Manage Corrective Actions memiliki keterhubungan dengan masalah aplikasi yang tidak siap atau masih ada yang kekurangan pada aplikasi. Satu praktek yang tidak memiliki keterhubungan dengan masalah yang ada adalah SP 2.1 Analyze Issues. Hasil penilaian terhadap penyedia pada semua SP pada SG 2 hasilnya semuanya rendah. Sedangkan hasil verifikasi dari panitia dan pemeriksa, SP 2.1 dan SP 2.2 hasilnya penting, dan SP 2.3 hasilnya cukup penting. Berdasarkan data yang ada, rekomendasi untuk SP 2.1 nilainya rendah, sedangkan untuk SP 2.2 dan SP 2.3 nilainya minimal sedang.

144 128 Tabel 5.33 Keterhubungan Data Dalam PMC Goal Practice Kode Masalah Hasil Penilaian Penyedia 1 Penyedia 2 Penyedia 3 Hasil Verifikasi Rekomendasi SG 1 SP 1.1 M4 Rendah Rendah Rendah Penting Sedang SP 1.2 M4 Rendah Rendah Rendah Penting Sedang SP 1.3 Rendah Rendah Rendah Penting Rendah SP 1.4 M4 Rendah Rendah Rendah Penting Sedang SP 1.5 Sedang Rendah Sedang Penting Rendah SP 1.6 M4, M5 Sedang Rendah Rendah Penting Sedang SP 1.7 M4, M5 Sedang Sedang Sedang Penting Sedang SG 2 SP 2.1 Rendah Rendah Rendah Penting Rendah SP 2.2 M5 Rendah Rendah Rendah Penting Sedang SP 2.3 M5 Rendah Rendah Rendah Cukup Penting Sedang

145 Keterhubungan Data Dalam SAM Keterhubungan data pada area proses Supplier Agreement Management dapat dilihat pada tabel Area proses SAM terdiri dari SG 1 Establish Supplier Agreements dan SG 2 Satisfy Supplier Agreements. SG 1 terdiri dari SP 1.1 Determine Acquisition Type, SP 1.2 Select Suppliers, dan SP 1.3 Establish Supplier Agreements. Sedangkan SG 2 terdiri dari SP 2.1 Execute the Supplier Agreement, SP 2.2 Accept the Acquired Product, dan SP 2.3 Ensure Transition of Products. Dari semua SP yang ada pada area proses SAM, tidak ada yang terhubung dengan masalah yang ada saat ini. Pada proyek ini semua penyedia tidak melibatkan pihak ketiga, pengembangan dilakukan sendiri oleh masingmasing penyedia, sehingga penilaian tidak dapat dilakukan karena tidak ada praktek yang dijalankan. Panitia dan pemeriksa mengkonfirmasi praktek yang dinilai penting yaitu SP 1.2, SP 1.3, dan SP 2.1. Sedangkan praktek yang dinilai cukup penting yaitu SP 1.1, SP 2.2, dan SP 2.3. Melihat data yang ada, untuk area proses SAM untuk sementara tidak digunakan. Sehingga kerangka penilaian nantinya hanya fokus pada tiga area proses yaitu Requirements Management, Project Planning,dan Project Monitoring and Control. Hasil penilaian terhadap penyedia menunjukkan

146 130 Tabel 5.34 Keterhubungan Data Dalam SAM Goal Practice Kode Masalah Hasil Penilaian Penyedia 1 Penyedia 2 Penyedia 3 Hasil Verifikasi Rekomendasi SG 1 SP 1.1 Rendah Rendah Rendah Cukup Penting Tidak digunakan SP 1.2 Rendah Rendah Rendah Penting Tidak digunakan SP 1.3 Rendah Rendah Rendah Penting Tidak digunakan SG 2 SP 2.1 Rendah Rendah Rendah Penting Tidak digunakan SP 2.2 Rendah Rendah Rendah Cukup Penting Tidak digunakan SP 2.3 Rendah Rendah Rendah Cukup Penting Tidak digunakan

147 Penyusunan dan Validasi Kerangka Penilaian Kapasitas Penyedia Penyusunan kerangka penilaian dan kapasitas penyedia dilakukan dengan memperhatikan empat proses dasar pengembangan perangkat lunak dari Sommerville. Empat proses dasar itu menguatkan penilaian terhadap area proses Requirements Management dan Project Planning yang berkaitan dengan Software specification dan Software development, area proses Requirements Management dan Project Monitoring and Control yang berkaitan dengan Software validation dan Software evolution. Penyusunan juga memperhatikan bagian-bagian manajemen proyek dari Marchewka, dimana identifikasi kebutuhan menguatkan penilain terhadap area proses Requirements Management, menetapkan tujuan berkaitan Project Planning, menyeimbangkan permintaan yang bersaing pada kualitas, ruang lingkup, waktu, dan biaya berkaitan dengan Project Planning, dan adaptasi spesifikasi, rencana, dan pendekatan terhadap masalah dan harapan berkaitan dengan Requirements Management dan Project Monitoring and Control. Dan rancangan ini mengacu best practices yang terdapat di CMMI Dev V 1.3 pada area proses yang telah ditentukan yaitu Requirements Management, Project Planning, dan Project Monitoring and Contro, dengan model penilaian SCAMPI C. Penyusunan rancangan ini juga memperhatikan data masalah yang ada, hasil penilaian terhadap penyedia, verifikasi dari panitia dan pemeriksa pengadaan perangkat lunak, dan analisis keterhubungan data. Hasil rancangan selanjutnya dilaporkan dan divalidasi kepada Asisten Deputi Dukungan Data Kebijakan dan Informatika selaku penanggung jawab terhadap segala yang berkaitan dengan kebijakan, pengembangan, dan pemeliharaan teknologi informasi di Kementerian Sekretariat Negara. Hasil dari dari pelaporan itu, pada intinya Asisten Deputi Dukungan Data Kebijakan dan Informatika setuju dengan adanya penilaian kapasitas terhadap penyedia, dan menanyakan kesiapan dari kerangka penilaian ini bisa diimplementasikan pada pengadaan perangkat lunak melaui lelang di Kementerian Sekretariat Negara, karena saat ini diperlukan alat ukur terkait kualitas pekerjaan dan penyedia pelaksana. Asisten Deputi Dukungan Data Kebijakan dan Informatika juga mengusulkan penilaian bukan saja ditujukan untuk pihak luar yang melaksanakan pekerjaan tapi praktek-praktek

148 132 apa yang bisa digunakan oleh pegawai di Kementerian Sekretariat Negara untuk mengontrol pekerjaan pengembangan perangkat lunak baik yang dilakukan oleh pihak luar maupun yang dilakukan oleh pihak dalam secara swakelola. Rancangan penilaian kapasitas penyedia perangkat lunak akan dijabarkan pada sub bab rekomendasi kerangka penilaian kapasitas penyedia Rekomendasi Kerangka Penilaian Kapasitas Penyedia Berdasarkan best practices yang terdapat di CMMI Dev V 1.3, prinsip dasar pengembangan perangkat lunak, unsur-unsur manajemen proyek, dan model penilaian SCAMPI C, serta dipadukan dengan data masalah yang ada, hasil penilaian terhadap penyedia, verifikasi dari panitia dan pemeriksa pengadaan perangkat lunak, dan analisis keterhubungan data, maka disusun rekomendasi dalam rangka meningkatkan pemilihan atau penilaian penyedia jasa konsultasi perangkat lunak di Kementerian Sekretariat Negara. Adapun untuk pembuatan kerangka penilaian kapasitas penyedia dilakukan sebelum membuat rekomendasi. Kerangka yang berhasil disusun divalidasi dahulu oleh Asisten Deputi Dukungan data Kebijakan dan Informatika (pejabat yang bertanggung jawab atas kebijakan pembangunan dan pengembangan perangkat lunak di Kementerian Sekretariat Negara). Kerangka penilaian kapasitas penyedia hasil validasi ditampilkan pada daftar rekomendasi. Berikut merupakan rekomendasi berdasarkan analisis dari penelitian ini: A. Rancangan kerangka penilaian terhadap penyedia yang mengadopsi dari CMMI Dev disebut Rancangan Penilaian Kapasitas Penyedia. Rancangan ini berisi pelaksanaan penilaian terhadap penyedia. Isi lengkap dari rancangan penilaian kapasitas penyedia dapat dilihat pada lampiran 4. B. Penilaian kapasitas penyedia dapat digunakan oleh panitia lelang ketika menilai peserta lelang atau disebut penilaian kapasitas penyedia oleh panitia, dan digunakan oleh pemeriksa lelang ketika menilai penerimaan pekerjaan dari penyedia atau disebut penialaian kapasitas penyedia oleh pemeriksa. C. Sebelum penilaian kapasitas penyedia dilaksanakan, sebaiknya diadakan pelatihan atau pembahasan tentang CMMI Dev untuk panitia dan pemeriksa

149 133 lelang dalam rangka menyamakan persepsi penilaian yang mengacu pada CMMI Dev. D. Implementasi penilaian kapasitas penyedia terbagi dalam beberapa tahap: i. Tahap pertama (diperkirakan pada tahun pertama dan kedua), penilaian kapasitas dilakukan pada para pemenang lelang atau penyedia yang mengerjakan proyek tapi hasil penilaian belum mempengaruhi diterima atau tidaknya pekerjaan. Meskipun hasil penilaian tidak mempengaruhi, tetapi pada awal sebelum memulai mengerjakan proyek, penyedia diberitahukan dokumen-dokumen apa yang harus dilengkapi mengacu pada penilaian kapasitas penyedia. Pada tahap ini terus dipantau dan dievaluasi terkait kesiapan untuk berlanjut ke tahap kedua. ii. Tahap kedua (diperkirakan pada tahun ketiga dan keempat), penilaian kapasitas penyedia dilakukan pada peserta lelang dan pemenang lelang. Bedanya pada peserta lelang hasil penilaian belum mempengaruhi penilaian pemilihan pemenang lelang namun dokumen-dokumen penilaian sudah mulai disosialisasikan, penilaian hanya sebagai dokumentasi organisasi dan uji coba kesiapan penilaian kapasitas terhadap penyedia. Sedangkan untuk pemenang lelang atau penyedia pelaksana pekerjaan, sebelum memulai pekerjaan diberitahukan mengenai pemeriksaan hasil pekerjaan nantinya terdiri dari dokumen-dokumen yang dinilai dalam penilaian kapasitas penyedia dan hasil ini akan mempengaruhi penerimaan pekerjaan. Pada tahap ini juga terus dipantau dan dievaluasi terkait kesiapan berlanjut ke tahap ketiga, apabila hasil pantauan dan evaluasi masih belum memungkinkan, maka penilaian kapasitas penyedia tetap menjalankan penilaian berdasarkan tahap kedua. iii. Tahap ketiga (diperkirakan pada tahun kelima dan keenam), penilaian kapasitas penyedia dilakukan terhadap peserta lelang dan pemenang lelang. Peserta lelang akan diberitahukan mekanisme penilaian dan dokumen-dokumen yang akan dinilai pada penilaian kapasitas penyedia. Hasil penilaian berpengaruh pada nilai pemilihan pemenang. Untuk pemenang lelang atau penyedia pelaksana pekerjaan akan diberitahu mekanisme penilaian dan dokumen-dokumen yang akan menjadi syarat

150 134 penerimaan pekerjaan. Pada tahap ketiga penilaian kapasitas penyedia masih berfokus pada pemenuhan praktek-praktek spesifik untuk mencapai level 1 atau Performed yang ada pada area proses Requirements Management, Project Planning, dan Project Monitoring and Control. Pada tahap ketiga juga terus dilakukan pemantauan, evaluasi, dan analisis untuk mengetahui apabila level 1 pada area proses Requirements Management, Project Planning, dan Project Monitoring and Control sudah stabil dapat dipenuhi, maka dianalisis apakah terdapat permasalahan terkini yang perlu diselesaikan sehingga perlu menambah area proses atau peningkatan menjadi level 2. Penambahan area proses atau peningkatan level dilakukan pada tahap keempat. iv. Tahap keempat (diperkirakan pada tahun ketujuh), mekanisme penilaian kapasitas penyedia sama seperti yang dilakukan pada tahap tiga, hanya saja pada tahap keempat dilakukan penambahan area proses atau peningkatan level. Hal ini dapat terus dilakukan peningkatan-peningkatan pada tahap-tahap berikutnya. E. Pelaksanaan penilaian kapasitas penyedia memerlukan keaktifan panitia dan pemeriksa lelang dalam memberikan informasi terkait penilaian, pemantauan pekerjaan dan dokumen pada saat pengembangan perangkat lunak, dan control terhadap pekerjaan. F. Penilaian kapasitas penyedia pada saat pelaksanaan pekerjaan akan membuat dokumen-dokumen pekerjaan pengembangan perangkat lunak tidak lagi bertumpuk pada tiga titik, yaitu pada saat penyerahan laporan pendahuluan, laporan antara, dan laporan akhir. Tetapi dokumen-dokumen tersebut akan menempel pada praktek dari proses pengembangan yang sedang dilaksanakan. G. Pada penilaian kapasitas penyedia oleh panitia, ada praktek-praktek yang dapat langsung dinilai dengan melihat dokumen penawaran teknis dan biaya dari peserta lelang. Karena format dokumen penawaran teknis dan biaya dari peserta lelang telah mengandung unsur-unsur praktek yang dinilai. Hal ini dapat dilihat pada kerangka penilaian kapasitas penyedia. H. Panita melakukan penilaian kapasitas penyedia pada saat evaluasi dokumen penawaran teknis dan biaya. Penilaian dapat dilakukan dengan mengundang

151 135 peserta lelang atau mendatangi peserta lelang. Sebelum penilaian, panitia menginformasikan praktek-praktek yang akan dinilai dan mekanisme penilaian. I. Pemeriksa melakukan penilaian kapasitas penyedia pada saat pemeriksaan akhir pekerjaan. Penilaian oleh pemeriksa dapat dilakukan mulai dari awal ketika pekerjaan sudah dimulai. J. Rekomendasi nilai minimal dari pembahasan Analisis Hubungan Masalah, Hasil Penilaian, dan Hasil Verifikasi akan digunakan pada penilaian kapasitas penyedia oleh panitia. Bila nilai peserta lelang tidak mencapai nilai minimal maka dianggap tidak mampu memenuhi standar kriteria penyedia yang telah ditentukan. Namun apabila dari semua peserta lelang tidak ada yang memenuhi standar kriteria penyedia maka dipilih peserta yang masuk kebutuhan formasi nilai tertinggi.

152 136 BAB 6 KESIMPULAN DAN SARAN Seperti yang sudah dijelaskan sebelumnya, penelitian ini ditujukan melakukan penilaian kapasitas penyedia jasa konsultansi sebagai bahan pengkajian model kerangka penilaian teknis pengembangan perangkat lunak yang mengacu pada CMMI-DEV, sehingga menghasilkan rekomendasi kerangka penilaian kapasitaas penyedia sebagai bagian dari pemilihan penyedia jasa konsultasi perangkat lunak di Kementerian Sekretariat Negara. Pada bab ini akan dijelaskan mengenai kesimpulan dan saran dari hasil penelitian yang sudah dilakukan. 6.1 Kesimpulan Pada penelitian ini penilaian terhadap penyedia didasarkan pada CMMI Dev V 1.3 dan SCAMPI C. Penilaian dilakukan terhadap para penyedia yang sedang melakukan pembangunan perangkat lunak di Kementerian Sekretariat Negara pada tahun Sebagai salah satu bahan penyusunan rancangan penilaian kapasitas penyedia jasa konsultasi perangkat lunak. Berdasarkan hasil analisis dan pembahasan yang sudah disampaikan pada Bab 5, maka dapat ditarik beberapa kesimpulan sebgai berikut: A. Penilaian terhadap penyedia jasa konsultasi perangkat lunak di Kementrian Sekretariat Negara dilakukan dengan mengacu pada CMMI Dev V 1.3 representasi Continuous dengan metode penilaian SCAMPI C. Hasil penilaian diketahui prediksi nilai dari semua penyedia masih berada pada level 0 atau incomplete di semua area proses yang telah ditentukan. Hal ini memperkuat bahwa permasalahan pada pengembangan perangkat lunak melaui lelang perlu mendapat perhatian, sehingga permasalahan dan kelemahan yang ada tidak terus berulang. Dibutuhkan kerangka penilaian untuk menilai penyedia sehingga evaluasi peningkatan kualitas penyedia dapat terukur dan masalah yang ada dapat diidentifikasi untuk menjadi perhatian penyedia sehingga tidak terulang lagi. 136

153 137 B. Berikut rangkuman hasil penilaian terhadap para penyedia Tabel 6.1 Penilaian pada Area Proses REQM Goal Practice Hasil Penilaian Penyedia 1 Penyedia 2 Penyedia 3 SG 1 SP 1.1 Sedang Sedang Sedang SP 1.2 Sedang Sedang Sedang SP 1.3 Rendah Rendah Rendah SP 1.4 Rendah Rendah Rendah SP 1.5 Sedang Rendah Rendah Tabel 6.2 Penilaian pada Area Proses PP Goal Practice Hasil Penilaian Penyedia 1 Penyedia 2 Penyedia 3 SG 1 SP 1.1 Rendah Rendah Rendah SP 1.2 Sedang Rendah Rendah SP 1.3 Tinggi Tinggi Tinggi SP 1.4 Tinggi Sedang Sedang SG 2 SP 2.1 Sedang Sedang Sedang SP 2.2 Rendah Rendah Rendah SP 2.3 Rendah Rendah Rendah SP 2.4 Sedang Rendah Rendah SP 2.5 Tinggi Tinggi Tinggi SP 2.6 Rendah Rendah Rendah SP 2.7 Tinggi Tinggi Tinggi SG 3 SP 3.1 Rendah Rendah Rendah SP 3.2 Rendah Rendah Rendah SP 3.3 Sedang Sedang Sedang

154 138 Tabel 6.3 Penilaian pada Area Proses PMC Goal Practice Hasil Penilaian Penyedia 1 Penyedia 2 Penyedia 3 SG 1 SP 1.1 Rendah Rendah Rendah SP 1.2 Rendah Rendah Rendah SP 1.3 Rendah Rendah Rendah SP 1.4 Rendah Rendah Rendah SP 1.5 Sedang Rendah Sedang SP 1.6 Sedang Rendah Rendah SP 1.7 Sedang Sedang Sedang SG 2 SP 2.1 Rendah Rendah Rendah SP 2.2 Rendah Rendah Rendah SP 2.3 Rendah Rendah Rendah Untuk are proses SAM tidak dapat dimasukkan penilaian, semua penyedia tidak melibatkan pihak ketiga, sehingga tidak ada praktek yang dijalankan pada area proses SAM. C. Verifikasi kebutuhan terhadap praktek yang akan dinilai dilakukan terhadap para panitia dan pemeriksa lelang perangkat lunak yang memiliki latar belakang pendidikan di bidang teknologi informasi dan latar belakang pekerjaan di bidang teknologi informasi. Hasil verifikasi menunjukkan ratarata praktek-praktek yang ada pada area proses Requirements Management, Project Planning, Project Monitoring and Control, dan Supplier Agreement Management dianggap penting. D. Berdasarkan data masalah yang ada saat ini, hasil penilaian terhadap penyedia, verifikasi kebutuhan penilaian praktek pada panitia dan pemeriksa lelang, dan analisis keterhubungan antar data, maka disusun rancangan kerangka penilaian kapasitas penyedia yang divalidasi kepada pejabat yang berwenang terhadap TI di Kementerian Sekretariat Negara. Rekomendasi kerangka penilaian

155 139 kapasitas penyedia berfokus pada tiga are proses (Requirements Management, Project Planning,dan Project Monitoring and Control), dengan standar minimal kualitas penyedia yang fokus pada pencapaian level 1 (performed) atau berfokus pada pemenuhan praktek-praktek spesifik yang ada pada specific goal. 6.2 Saran Berikut adalah saran penulis terkait penelitian kerangka penilaian kapasitas penyedia di Kementerian Sekretariat Negara. A. Penilaian kapasitas penyedia atau kerangka penilaian kapasitas yang mengacu pada pengalaman-pengalaman terbaik yang terdapat pada CMMI Dev dapat digunakan untuk mengukur kualitas praktek dan dokumentasi dari penyedia dalam mengembangankan perangkat lunak. Kegiatan ini bukan saja untuk meningkatkan pemilihan penyedia yang memilki kapasitas yang lebih baik, tetapi bahan penilaian ini dapat digunakan oleh internal Kementerian Sekretariat Negara dalam rangka meningkatkan kapasitas internal dalam mengembangkan perangkat lunak. B. Untuk menguatkan penilaian kapasitas penyedia, Kementerian Sekretariat Negara perlu menetapkan standar dan prosedur dalam kegiatan pemilihan penyedia dan penilaian terhadap pekerjaan lelang. Sehingga peningkatan pemilihan penyedia dan penerimaan pekerjaan lelang dapat diukur kualitasnya dari waktu ke waktu. Hal ini juga untuk menghindari terjadinya kesalahan yang berulang-ulang. C. Diharapkan kedepannya ada penelitian-penelitian selanjutnya dengan kerangka penilaian yang berbeda terhadap penilaian kapasitas penyedia, sehingga dapat memperkaya cara dalam menilai kapasitas penyedia pada pemilihan penyedia di kegiatan lelang.

156 140 DAFTAR PUSTAKA Andrianto (2013). Perbaikan Kualitas Proses Pengembangan Perangkat Lunak Berdasarkan Kerangka Kerja CMMI-DEV Representasi Continuous: Studi Kasus PT. Sigma Metrasys Solution. Program Studi Magister Teknoloi Informasi,. CMMI Product Team, Software Engineering Institute, Carnegie Mellon University (2010), CMMI FOR Development, Version 1.3: Improving process for developing better products and services, Carnegie Mellon Software Engineering Institute. Global Alliance for Project Performance Standards (2007). A Framework for Performance Based Competency Standards for Global Level 1 and 2 Project Managers. Global Alliance for Project Performance Standards. Haminullah (2011). Strategi Penigkatan Kualitas Proses Pengembangan Peranti Lunak Berdasarkan Kerangka Kerja CMMI-DEV Continuous: Studi Kasus PT Malloci Software Solution. Program Studi Magister Teknoloi Informasi,. Husnul Hidayat (2013). Evaluasi dan Analisis Tingkat Kemapanan Tata Kelola Teknologi Informasi: Studi Kasus PT Bursa Efek Indonesia. Program Studi Magister Teknoloi Informasi,. Marchewka, Jack T. (2010). Information Technology Project Management Third Edition. John Wiley & Sons, Inc. Nico Baruna Putra (2013). Perbaikan Proses Pengembangan Perangkat Lunak untuk Peningkatan Kualitas Produk pada PT. XYZ dengan Pendekatan CMMI- DEV Representasi Continuous. Program Studi Magister Teknoloi Informasi,. Office of Government Commerce (2009). Managing Successful Projects with PRINCE2. The Stationery Office. Peraturan Presiden Republik Indonesia Nomor 58 Tahun 2010 tentang Kementerian Sekretariat Negara. Peraturan Presiden Republik Indonesia Nomor 70 Tahun 2012 tentang Perubahan Kedua Atas Peraturan Presiden Nomor 54 Tahun 2010 tentang Pengadaan Barang/Jasa Pemerintah. Peraturan Menteri Sekretaris Negara Republik Indonesia Nomor 2 Tahun 2010 tentang Rencana Strategis Sekretariat Negara Republik Indonesia tahun

157 141 Peraturan Menteri Sekretaris Negara Republik Indonesia Nomor 2 Tahun 2011 tentang Organisasi dan Tata Kerja Kementerian Sekretariat Negara. Peraturan Menteri Sekretaris Negara Republik Indonesia Nomor 7 Tahun 2011 tentang Penyempurnaan Rencana Strategis Kementerian Sekretariat Negara Republik Indonesia tahun Peraturan Menteri Sekretaris Negara Republik Indonesia Nomor 9 Tahun 2011 tentang Road Map Reformasi Birokrasi Kementerian Sekretariat Negara Republik Indonesia tahun Peraturan Menteri Sekretaris Negara Republik Indonesia Nomor 14 Tahun 2011 tentang Grand Design Pengembangan E-Governtment (Pengembangan Sistem Informasi) Kementerian Sekretariat Negara tahun Peraturan Presiden Nomor 70 Tahun 2012 tentang Perubahan Kedua Atas Peraturan Presiden Nomor 54 Tahun 2010 tentang Pengadaan Barang/Jasa Pemerintah. Persse, J. (2007). Project Management Success with CMMI: Seven CMMI Process Areas. Prentice Hall. Project Management Institute (2013). A Guide to the Project Management Body of Knowledge (PMBOK Guide) Fifth Edition. Project Management Institute. Kneuper, R. (2008). CMMI Improving Software and System Development Processing Using Capability Maturity Model Integration (CMMI-Dev). Santa Barbara: Rockynook. Sommerville, Ian (2007). Software Engineering Eighth Edition. Addison Wesley. Will Hayes, W., Miluk, G., Ming, L., dan Glover, M. (2005). Handbook for Conducting Standard CMMI Appraisal Method for Process Improvement (SCAMPI) B and C Appraisals, Version 1.1, Carnegie Mellon Software Engineering Institute.

158 142 Lampiran 1 : Wawancara TRANSKRIP WAWANCARA Nama Jabatan : Andrie Syahriza, S.Kom., M.Si. : Asisten Deputi Dukungan Data Kebijakan dan Informatika Tanggal : 13 Agustus 2013 Bisa diceritakan perkembangan sistem informasi di Kementerian Sekretariat Negara? Dalam hal apa? Berkaitan perkembangan perangkat lunak di sekretariat negara. Kalau perkembangan secara kebutuhan aplikasi, sekarang ini cukup tinggi. Itu terbukti setiap satuan kerja atau unit kerja eselon 2 banyak memberikan permintaan untuk dibuatkan aplikasi sesuai tugasnya mereka masing-masing. Ini terlihat berbeda dengan tahun-tahun sebelumnya karena kalau tahun sebelumnya itu banyak dilakukan pembangunann itu dengan lelang. Semua dipihak ketigakan. Sekarang, sejak 2008 sudah banyak kita kerjakan secara mandari atau swadaya, jadi tenaga-tenaga pranata komputer (prakom) itu benar-benar dimanfaatkan. Dan itu menambah waktu kerja untuk bisa dikerjakan aplikasi-aplikasi lain, plus ditambah beberapa aplikasi itu bisa jadi contoh berhasil. Karena keberhasilan itu membuat unit kerja lain percaya untuk dikerjakan oleh tenaga prakom, makanya permintaan-permintaan pembangunan aplikasi bertambah banyak. Peran tugas Asdep DDKI? Sesuai dengan tugas fungsinya salah satu yang utama kita kerjakan, mulai dari kebutuhan kemudian kita persiapan dengan user dalam hal membaca kebutuhan itu seperti apa perencanaannnya pelaksanaannya sampai dengan kasusnya sampai

159 143 dengan implementasi semua itu rangkaian satu proses, sampai monitoring dan evaluasi. Itu tugasnya memang ada di kita semua. Berarti memang ada perencanaan pengembangan perangkat lunak? Itu ada di grand design e government atau pengembangan TIK Setneg. Bila dilihat. pengembangan perangkat lunak di Setneg dibagi dua jenis, yaitu lelang dan swakelola. Bagaimana penentuan pengembangan perangkat lunak itu akan dilelang atau dilakukan secara swakelola? Pertama melihat permintaan-permintaan yang masuk, kita lihat dan analisa mana yang bisa di handle oleh tim pranata komputer, mana yang tingkat kesulitannya cukup tinggi, secara waktu dan pemrograman sulit, itu yang dilelangkan. Dipilih mana yang tingkat kesulitan tinggi kita lelangkan dan memakan waktu cukup lama. Mana tingkat kesulitanya average selalu rata itu bisa di tangani oleh pranata komputer, karena kalau semuanya ditangani oleh pranata komputer tidak mungkin, orangnya terbatas, waktu terbatas sedangkan permintaan cukup tinggi. Untuk lelang dan swakelola ada pembiayaan, dan pembiayaannya berbeda? Iya, sesuai dengan DIPAnya, kan harus dianggarkan sesuai dengan ketentuanketentuan yang ada di standar biaya umum. Untuk organisasi, perbedaan lelang dengan swakelola? Kalau lelang sendiri organisasinya bagaimana? Kalau lelang, sesuai dengan ketentuan perpres no 70 tahun 2012 tentang pengadaan barang dan jasa. Ada tim khusus dan segala macam, pengangkatan, dan mereka bekerja berdasarkan Term of Reference (TOR) yang mereka terima. TOR nya ini harus dibuat antara Asdep DDKI dengan usernya, kalau permintaan aplikasi dari user, tapi kalau aplikasi itu dari kita sendiri tentu Asdep DDKI sendiri yang menyiapkannya. Makanya kalau dari pertama untuk lelang TOR nya dibuat bersama-sama dengan user, sampai nanti ditetapkan kebutuhannya, disepakati. Nantinya diberikan kepada tim lelang yang akan membuat dokumen lelangnya berdasarkan spek teknis berdasarkan TOR tersebut. Kalau yang

160 144 swakelola, awal itu tetap sama, jadi dibuat sebuah TOR atau Kerangka Acuan Kerja (KAK), kebutuhan user seperti apa, cuman bedanya langsung dikerjakan oleh tim prakom. Jadi kalau yang swakelola juga dibuat sebuah SK untuk pembentukan tim, cuman bedanya kalau yang swakelola yang menandatangani SK Asdep nya, kalau yang lelang yang menandatangani KPA. Selebihnya tim prakom akan bekerja sesuai dengan batas waktu yang telah ditentukan dan jenis pekerjaannya apa dengan TOR yang sudah disetujui. Untuk yang lelang, yang melakukan control dari panitia lelang? Iya Atau ada penunjukan tim lain? Kalau di panitia lelang itu biasanya ada anggota yang mengetahui masalah teknis, tapi menurut peraturan yang baru itu dimungkinkan dibentuk tim khusus sendiri apabila dalam keanggotaan tim lelang itu tidak ada yang memahami teknis. Sejauh ini kebetulan tim lelangnya itu teman-teman yang mengetahui masalah teknis, sehingga tidak diperlukan tim teknis khusus diluar panitia lelang. Kalau di tempat lain ada seperti itu jadi tim lelangnya itu orang-orang umum yang tidak memahami secara pasti subtansi pekerjaan sehingga dia membutuhkan bantuan dari orang yang expert sehingga dibuat tim khusus. Untuk yang swakelola ada yang mengontrol pekerjaannya? Tim khusus diluar tim itu tidak ada, kontrol itu langsung dipegang oleh user sama Kabagnya atau Asdepnya langsung. Tidak ada tim khusus untuk mengontrol. Kontrolnya melalui time table, mereka akan bikin berapa lama itu ditentukan sama-sama. Harapannya sendiri pak terhadap pengembangan perangkat lunak di Setneg? Harapannya tentu semua bekerja dengan baik, sesuai dengan harapan user, digunakan secara maksimal, sehingga membantu kinerja dari user tersebut, aman dari segala ancaman dan serangan, sehingga user itu bisa bekerja dengan baik.

161 145 Apakah ada kendala dalam pengembangan perangkat lunak? Kendalanya kalau untuk yang lelang pada saat awal untuk pembuatan TOR bersama dengan user, jadi kadang-kadang dibutuhkan waktu lebih lama, karena user kadang-kadang tidak paham yang dibutuhkan itu apa, sehingga kita membantu mereka untuk menggali kebutuhan yang mereka inginkan sesuai dengan harapan. Kalau proses lelang sesuai dengan jadwal yang telah ditentukan. Cuman diujungnya itu pernah kejadian, pada saat penunjukkan pemenang kemudian dilakukan pekerjaannya, ternyata ada juga yang tidak selesai, sesuai dengan masa kontraknya dia, sehingga itu kita batalkan dan kita kenakan denda ataupun hukuman terhadap perusahaan tersebut. Kalau untuk yang swakelola, masalahnya dengan SDM nya kurang, yang kedua dari sisi kompetensi dari tenaga prakom itu belum semuanya dikatakan komplit. Karena biasanya kalau tim prakom itu kan ada yang menguasai bidang-bidang tertentu, sehingga bisa cepat dia bekerja. Contohnya desainnya, codingnya dan segala macamnya, belum semuanya lengkap, jadi masih banyak ke salah satu bidang saja. Dari sisi tenaga manusianya, dari kompetensinya perlu juga ditambah atau dikembangkan, sehingga apabila sudah lengkap tidak perlu lagi kita melakukan lelang. Diluar dari pada itu adalah adanya permintaaan-permintaan dari unit kerja lain terhadap tenaga kita, sehingga yang sudah kita bangun, yang sudah kita persiapkan dari dulu jadi berubah lagi, karena tenaga-tenaga ini dimintakan membantu atau mengisi kekosongan di tempat lain. Untuk pengembangan perangkat lunak di Asdep DDKI apakah memiliki standar atau SOP? Ada, ada SOP nya untuk swakelola dan lelang. Dari SOP yang ada apakah sudah mencukupi? Kalau memadai secara keseluruhan artinya rinci ya, setiap segmen itu ada turunan SOP nya lagi. Itu memang belum. Kita membuat SOP pekerjaan yang sifatnya umum. SOP yang bagus itu sebenarnya begini, setiap bidang-bidang pekerjaan itu ada SOP nya lagi. Katakanlah SOP nya membuat TOR dengan user terus ke bawahnya TOR tersebut diberikan kepada tim prakom, prakom melakukan analisa

162 146 study, melakukan coding dan seterusnya. Pada saat melakukan coding atau pembuatan aplikasi tersebut seharusnya ada rincian lagi, misalnya dari sektor keamanan atau securitynya itu ada SOP nya lagi, dari sektor design graphicnya ada SOP nya lagi dan seterusnya. Jadi kita seharusnya kayak menerapkan ISO, ISO di TI itu untuk aplikasi itu seperti apa. Itu sama seperti ISO nya sistem keamanan informasi, ISO nya itu banyak rinciannya, kalau untuk sistem keamanannya komputer personal apa yang harus dilakukan. Mulai pengguna itu membuat password tertentu, tidak boleh mengakses web-web yang mengandung ancaman, itu salah satu SOP nya. Jadi kalau secara rinci memang perlu diperbaiki lagi perlu ditambah, kalau secara umum pekerjaan itu sudah ada. Untuk kedepannya apakah masih banyak kegiatan pengembangan perangkat lunak? Pastinya, karena kebutuhan manusia, kebutuhan unit kerja akan terus bertambah. Selain itu juga paling tidak minimal meraka melakukan perubahan-perubahan pada contentnya, apalagi kalau dilihat trendnya perubahan ke depan itu nanti akan membuat sistem itu akan terintegrasi satu dengan lainnya. Itu sebuah pekerjaan yang cukup besar. Apakah akan ada perbaikan terhadap kendala yang ada? Perbaikan akan ada terus karena kita belum menemukan model yang menurut kita sempurna. Kalau kita anggap manajemennya sudah baik memang sudah berjalan dengan baik. Tapi dengan segala kekurangannya dan masalah tadi, manajemennya itu juga harus diperbaiki, dengan adanya nanti penambahan atau perbaikan dari sisi SDM nya nanti akan otomatis merubah manajemen pengelolanya juga. Jadi pasti ada perbaikan-perbaikan manajemen kedepan. Tergantung dari sejauh mana kebutuhan kekurangan kita itu bisa dipenuhi. Kalau di PNS itu kan beda dengan di swasta. Rekrutmen, kompetesni, karir, itu juga menentukan model manajemen prakom.

163 147 TRANSKRIP WAWANCARA Nama Jabatan : Janawir, S.Si., M.Si. : Kepala Bidang Pengembangan Sistem dan Jaringan, Asisten Deputi Dukungan Data Kebijakan dan Informatika Tanggal : 13 Agustus 2013 Bisa diceritakan perkembangan sistem informasi di Kementerian Sekretariat Negara? Terkait dengan perkembangan sistem informasi di Kementerian Sekretariat Negara, ini proses pengembangan dan pembangunan dilakukan dengan dua cara, yaitu cara lelang khususnya untuk aplikasi tingkat komplesitasnya tinggi dan juga pengerjaannya banyak, sehingga membutuhkan waktu yang lebih banyak. Ini yang ditenderkan. Sedangkan untuk aplikasi kecil yang bisa dikerjakan paranata komputer ini bisa diswakelolakan. Tentang perkembangannya dari sistem informasi atau aplikasi yang di kembangkan secara umum bisa disimpulkan atau bisa dikatakan aplikasi yang dikerjakan secara swakelola ini lebih banyak yang bisa terimplementasi dengan baik, dalam arti aplikasi yang dikembangkan ini oleh user yang minta dibuatkan sistem informasinya ini dapat dengan mudah diimplementasikan digunakan oleh user. Tentu ini banyak faktor yang mempengaruhi mengapa ini dapat berhasil. Karena yang pertama komunikasi antara user dengan pranata komputer yang lebih banyak waktunya, dan diskusinya tidak terbatas pada pertemuan yang bersifat teknis, tapi lebih sering berdiskusi bagaimana pengembangan sistem ini layaknya dikembangkan. Kemudian aplikasi yang dikembangkan secara swakelola, tingkat kompleksitasnya tidak terlalu besar, sifatnya aplikasi kecil umu, dan waktu pengerjaannya itu tidak ditargetkan dalam secepat mungkin, kalau ditender itu ada batas waktu 3 bulan atau 4 bulan, kalau di swakelola ini bisa 6 bulan, sehingga bisa dihasilkan aplikasi yang maksimal. Dari sisi teknis para pranata komputer ini kemampuannya semakin meningkat sehingga aplikasi yang dihasilkan jauh lebih baik dari sebelum-sebelumnya. Kita yakin

164 148 orang yang semakin sering mengerjakan sesuatu, dalam hal ini mengembangkan sistem informasi maka lama kelamaan dia akan terlatih dengan baik untuk mengembangkan aplikasi yang hampir mirip dan juga mengembangkan dengan pengembangan-pengembangan yang jauh lebih baik sesuai dengan perkembangan teknologi informasi. Sebaliknya dari sisi aplikasi yang dikerjakan secara lelang itu biasanya fator kendalanya adalah pada saat implementasinya, itu biasanya seperti yang itdak diharapkan. Sebagai contoh aplikasi yang dari awal sudah diminta oleh user dengan berbagai item-item atau fasilitas yang dipesan, itu sudah termuat dalam TOR dalam kerangka acuan, itu sebagai acuan bagian pengembang dalam mengembangkan sesuai kontraknya. Ketika itu serahkan, aplikasi itu sudah dibuat sesuai batas waktu, dan sudah disetujui, bahkan boleh dikatakan aplikasi itu sudah sesuai dengan permintaan, tetapi pada saat implementasi ternyata tidak mudah untuk dilaksanakan sesuai dengan keinginan awal. Misalnya saja untuk menjalankan aplikasi itu dengan maksimal ini kan merubah kebiasaan atau budaya kerja yang tadinya sifatnya manual simple, tapi dia harus lain melaksanakan sifatnya manual dia juga harus memasukkan inputing data sesuai dengan mekanisme sistem informasi sehingga data tersebut terdaftar. Ini yang sering kali menjadi pekerjaan baru khususnya bagi para pejabat yang merupakan bagian dari komponen sistem ini. Hal seperti ini yang banyak menjadi kendala, disamping mis komunikasi antara user dengan vendor, itu umum terjadi tapi bisa diminimalisir. Tidak seperti kendala saat implementasi yang dirasa banyak kendala-kendala yang akhirnya aplikasi sudah dibuat tapi tidak berjalan maksimal. Bisa dikatakan banyak aplikasi seperti itu. Untuk pemilihan vendornya, untuk sistem yang ada saat ini sudah mencukupi atau perlu ada penambahan? Kalau pemilihan vendor itu terikat pada pemilihan yang aturannya sudah ada dalam petunjuk pelaksanaan pengadaan barang atau jasa pemerintahan diatur oleh LKPP melalui mekanisme eproc. Tentunya di sistem eproc itu juga, yang namanya sistem masih ada celah kekurangan kelemahan. Bahwasannya eproc itu menutup kemungkinan-kemungkinan tidak ada peluang bagi vendor untuk mempengaruhi panitia. Itu memang diminimalisir dengan berbagai macam aturan-

165 149 aturan yang sekarang sudah semakin baik di eproc. Hanya saja di eproc masih terpaku pada dokumen pasti yang sifatnya legalitas formal tidak terlalu menekankan pada kemampuan teknis seperti beauty contest yang memang itu akan sangat terlihat kemampuan dari calon vendor yang akan kita pilih. Memang di eproc ini akan menekan subjektifitas, tetapi kita tidak hanya memprioritaskan pada objektifitas bahwa perusahaan ini lengkap baik secara organisasi, tenaga kerja yang tertera pada dokumentasi perusahaan tersebut. Kepastian bahwa tenaga ahli yang akan mempunyai kapabilitas yang baik, itu juga harus bisa dipastikan. Ini unsur subjektifitasnya jadi tidak terlihat, kita tidak bisa melihat kemampuan orang dari ijazah, kemudian dari lulusan mana, perusahaan dari proyek yang pernah ditangani bermilyar-milyar tetapi belum tentu juga, belum tentu perusahaan memiliki kemampuan yang tinggi. Disini eproc ini juga saya tidak tahu bagaimana menyempurnakannya sehingga tidak terpaku pada legalitas tenaga ahli bahkan pengalaman-pengalaman sejenis yang pernah dimiliki pada perusahaan itu. Kalau acuannya pada pengalaman sejenis, tentu dia akan menang terus pada tender-tender berikutnya karena rangkingnya akan tinggi, pada saat bersamaan dia akan mempunyai load pekerjaan yang bisa menjadi risiko mengerjakan pekerjaan bersamaan itu akan menjadi beban bagi perusahaan tersebut untuk dapat melaksanakan pekerjaan dengan baik, maka tenaga ahli yang disodorkan itu pun itu itu juga. Peran dan tugas kepala bidang sistem dan jaringan terkait dengan pengembangan perangkat lunak? Kita mengkoordinir semua pengembangan sistem informasi yang ada di Sekretariat Negara, dalam arti pengadaan pembangunan sistem informasi dan juga atau pengembangan sistem informasi itu sendiri kita bertanggung jawab untuk terlaksananya pengembangan sistem informasi itu agar terlaksana dengan baik, dan juga kita memfasilitasi jaringan informasi di Sekretariat Negara bisa terfasilitasi bisa berjalan dengan baik. Berarti disini yang mengelola perangkat lunak?

166 150 Iya betul, kita yang mengelola menginventarisir dan juga pada saat pengembangan kita yang memantau dan juga kita bertanggung jawab pada aplikasi pelaksanaan pengadaan itu dilaksanakan dengan baik. Implementasinya juga kita memastikan bahwa digunakan oleh user dengan baik. Dan juga kita mendukung fasilitas bahwa aplikasi itu berjalan pada jaringan yang terimplementasi di Sekretariat Negara. Pada pengembangannya ada metodologi khusus yang digunakan di Setneg? Tidak kita menitik beratkan pada metode bagaimana pengembangan akan menyelesaikan atau mengerjakan pekerjaan itu, apakah dengan SDLC atau dengan metode-metode yang lain, tapi yang kita sarankan pada vendor dikembangkan dengan open source. Kita disini banyak aplikasi yang dikembangkan dengan open source. Bagaimana organisasi untuk pengontrolan monitoring, di bagian ini ada pembagiannya? Sebenarnya belum terorganisisr atau tidak ada pengaturan organisasi yang terstruktur seperti itu. Untuk aplikasi swakelola ada koordinator tim, untuk aplikasi-aplikasi yang sudah diinventarisir dalam satu tahun ini akan dikembangkan. Misalnya koordinator tim untuk aplikasi A ini siapa koordinatornya. Kemudian siapa yang akan menjadi system analyst, kemudian programmer dan sebagainya. Tapi itu juga tidak artinya system analyst tidak hanya mengerjakan analis saja, tetapi juga mengerjakan sistem database secara bersamaan. Sistemnya hanya berbagi tugas saja, berbagi pekerjaan. Tugas-tugas dalam membuat sistem informasi ini, merancang pondasi siapa, kemudian mendesain tampilan saiapa, database, kemudian ada modul-mudol, ada modul report, input data, backend, frontend ini siapa, ini hanya dibagi seperti itu. Kita tahu pranata komputer ini kan selain tugas berdasarkan perintah dari pimpinan, tugasnya juga mengumpulkan poin angka kredit. Dengan dibagi-bagi seperti ini, pranata komputer yang ada akan mendapatkan bagian sehingga sama-sama mendapatkan poin. Sedangkan untuk yang lelang ini sepenuhnya pembagian tugas dan sebagainya pada vendor. Hanya kita pada saat pelaksanaannya ada yang

167 151 namanya panitia, pemeriksa, user, juga ada sebagai penanggung jawab pekerjaan. Perlu diketahui di bidang pengembangan sistem dan jaringan bertanggung jawab pada aplikasi yang bersifat baik dan juga kompatibel untuk diimplementasikan dengan perangkat yang ada. Dan pelaksanaan implementasinya memantau. Kalau panitia itu hanya sampai pemilihan pengembang. Ada organisasi khusus yang memantau dari bidang pengembangan sistem dan jaringan? Kalau di bidang pengembangan sistem dan jaringan ini ada tiga sub bidang. Sub bidang yang pertama adalah sub bidang aplikasi dukungan kebijakan dan website, ini yang mengkoordir aplikasi yang dikembangkan di Sekretariat Negara dengan aplikasi yang sifatnya menyediakan data dukungan kebijakan seperti SDDKN dan website resmi setneg.go.di dan indonesia.go.id. yang kedua adalah sub bidang otomasi perkantoran, yang mengkoordinasi pengembangan sistem informasi atau pelaksanaan implementasi dari sistem informasi perkantoran. Seperti aplikasi poliklinik, aplikasi keuangan, aplikasi SIMPEG, aplikasi perundang-undangan. Banyak aplikasi yang sudah dikembangkan disini merupakan aplikasi internal untuk unit kerja yang dikembangkan, baik itu secara lelang atau swakelola. Ketiga sub bidang jaringan terkait infrastruktur dan jaringan. Harapan terhadap pengembangan perangkat lunak? Harapannya yang pertama kepada unit kerja yang membutuhkan aplikasi, diharapkan dukungan peran aktif dari unit kerja bahwa aplikasi sistem informasi itu sendiri bagian dari sistem, didalamnya ada perangkat lunak yang diminta user, tapi itu inputnya sumber datanya dari user, dan operatornya juga dari user. Itu dimana dibutuhkan data awal diperlukan peran serta user untuk aktif apa yang semestinya ada pada sistem, tentunya data ini menjadi tanggung jawab user untuk menginputnya.pada pelaksanaannya user juga harus berperan aktif dan peduli pada sistem dapat berjalan sesuai. Tentu sistem ini tidak dapat langsung berjalan dengan sempurna tapi melalui proses perbaikan-perbaikan. Perbaikan-perbaikan dari vendor tidak dalam kurun waktu yang terlalu lama. Dalam kurun waktu yang tidak terlalu lama kesempatan bagi user untuk aktif mempelajari menggunakan

168 152 sehingga familiar. Ketika sudah familiar maka dia akan tahu mana yang kurang, yang kurang akan diperbaiki. Kalau tidak seperti itu, pada saat habis masa garansinya sedangkan aplikasi itu tidak berjalan sesuai dengan permintaan, dia akan tidak dipergunakan atau bahkan user merasa aplikasinya tidak sesuai dengan yang diinginkan. Berarti kesiapan user dalam implementasi menjadi kendala juga? Betul, sangat mempengaruhi implementasi. Selain kesiapan user, ada kendala lain? Seperti tadi sudah disampaikan mekanisme pemilihan penyedia itu juga masih ada celahnya. Memang sesuai dengan peraturan tapi kita harus bisa memilih vendor, harus jeli dalam menilai, yang mampu melaksankan ini dengan baik. Selain dari dokumentasi, keahlian, dan juga tanggung jawab. Tantangan bagi kita bagaimana kita teliti dalam memilih vendor yang terbaik untuk mengerjakan pekerjaan sesuai keinginan dari user secara maksimal. Kedepannya masih akan ada pengembangan perangkat lunak? Masih, pasti akan semakin banyak. Kenapa? Pertama masih banyak permintaan yang belum kita akomodir, kedua aplikasi yang sudah dikembangkan itu berkembang, sistem yang dibuat itu sebelumnya requirementnya belum termuat, sementara user sekarang sudah mulai ada semacam keinginan yang berkembang. Maka dengan adanya hal seperti itu dibutuhkan pengembangan, jadi dalam hal ini pembangunan sistem informasi itu mampu mengaplikasi yang belum terakomodir ditambah dengan pengembangan mengakomodir keinginan user yang menjadi berkembang. Apakah ada dari bidang ini rencana perbaikan atau peningkatan kualitas pengelolaan pengembangan perangkat lunak? Ya tentu itu ada, pertama dari segi SDM, SDM ini sangat diperlukan, baik secara jumlah maupun kualitas. Terutama SDM untuk pranata komputer yang akan menangani pekerjaan pengembangan sistem informasi dari swakelola. Dengan

169 153 adanya penambahan secara jumlah tentu kita bisa mengerjakan pekerjaanpekerjaan yang sudah banyak diminta oleh unit kerja yang saat ini masih kita tunda, karena kita merasa pekerjaan yang ada saat ini dirasa sudah banyak. Mungkin tidak tertangani. Yang kedua selain secara jumlah, yang lebih penting kualitasnya. Kualitas SDM yang memang benar-benar dalam hal ini menghasilkan produk sistem informasi yang sesuai dengan permintaan dari user.

170 154 TRANSKRIP WAWANCARA Nama Jabatan : Muhaziron Sulistiyo Wibowo : Kepala Subbidang Aplikasi Otomasi Perkantoran Tanggal : 13 Agustus 2013 Bisa diceritakan perkembangan sistem informasi di Kementerian Sekretariat Negara? Kalau dari sisi pembangunan kita menerapkan dua metode, yaitu dibangun secara swakelola dalam hal ini teman-teman pranata komputer, yang kedua by tender dengan diadakannya lelang jadi pihak ketiga yang akan melaksanakannya. Itu kalau dari sisi siapa pelakunya dalam penanganan aplikasi tersebut. Kalau dari pengelolaan di lapangan ketika aplikasinya sudah dibangun atau dikembangkan itu murni tanggung jawab pengelola SI TI di Kementerian Sekretariat Negara, dalam hal ini Asdep DDKI. Biasanya yang melakukan itu adalah pranata komputer dengan dikoordinasikan oleh para Kabag dan Kasubag yang bertanggung jawab terhadap aplikasi-aplikasi tersebut, dibantu juga oleh para pengguna atau user dari masing-masing aplikasi. Dari sisi implimentasi yang melakukan pengawalan, asistensi dan monitoring tentunya dilakukan oleh para pranata komputer dikoordinasikan oleh para Kabag dan Kasubagnya juga bekerja sama dengan para penggunanya. Jadi tiga tahap dari sisi pembangunannya, pengelolaan, maintenance itu memang sudah berjalan dengan cukup baik dari hulu ke hilir. Kedepannya pengembangan dengan metode outsource dan swakelola tetap menjadi pilihan dan disesuaikan dengan kondisi yang ada. Berarti ada tugas dari Kasubid Aplikasi Otomasi Perkantoran sebagai koordinator dari pelaksanaan? Ya ada beberapa.

171 155 Atau ada peran lain dari Kasubid terkait dengan pengembangan perangkat lunak? Tentunya untuk pengelolaaan, beberapa aplikasi tentunya dibawah Kasubid aplikasi Otomasi Perkantoran, antara lain aplikasi SPDE, aplikasi Pengaduan Masyarakat, aplikasi KTLN yang sifatnya terkait dengan sub bidang aplikasi otomasi perkantoran, tapi ada juga aplikasi lain yang dikelola oleh sub bidang yang lain. Jadi memang masing-masing sub bidang dibawah Bidang Sistem dan Jaringan memiliki tugas fungsi yang berbeda-beda dalam hal pengelolaan aplikasi sistem informasi di Setneg. Bagaimana proses pengembangan perangkat lunak di Kementerian Sekretariat Negara? Proses pengembangannya tentunya tadi dengan dua metode, dengan outsource dalam hal ini diserahkan pada pihak ketiga, yang kedua dengan di swakelolakan oleh para pranata komputer. Kalau dari awal permohonannya bagaimana? Kalau dari pemohon tentunya semua aplikasi itu mengacu kepada permohonan tiap-tiap unit kerja atau satuan organisasi yang membutuhkan sistem informasi dalam mendukung tugas dan fungsi kerjanya. Selama permohonan itu ada oleh bagian pengembangan sistem dan jaringan itu akan dibahas kemudian coba dianalisa kira-kira kebutuhan aplikasinya seperti apa. Apakah aplikasi itu sudah ada, belum ada atau sedang dikembangkan. Apabila sudah ada berarti tinggal menggunakan aplikasi yang sudah ada sekarang ini. Tapi kalau memang belum ada, ada dua metode yang akan digunakan, bisa dengan menggunakan tender atau pun dengan swakelola. Tergantung dari kesiapan, yang pertama kesiapan anggaran, kesiapan para pengelola teknis dalam hal ini pranata komputer. Karena load kerja mereka juga tidak sedikit, cukup banyak. Itu juga menjadi pertimbangan apakah ini diswakelolakan atau ditenderkan. Berarti tidak semua permintaan akan dikerjakan?

172 156 Betul, untuk dipenuhi tahun yang sekarang ini dipertimbangkan juga beban anggaran, dan beban dari tugas fungsi pranata komputer selaku orang atau tim yang melakukan pengembangan aplikasi tersebut. Bisa jadi bila ditunda dipending, bisa tahun depan. Berarti banyak permintaan juga untuk pengembangan? Kalau permintaan cukup banyak. Dari permintaan yang banyak apakah ada SOP pengembangan perangkat lunak? Standar pelayanan lebih tepatnya, yang sudah ada standar pelayanan. Jadi standar pelayanan permintaan untuk mengembangkan suatu aplikasi itu sudah ada, dan sudah dibakukan dalam peraturan menteri. Dan itu menjadi dasar atau proses dari mekanisme kerja di Asdep DDKI dalam mengakomodir para pengguna di setiap unit kerja dan satuan organisasi. Dari standar pelayanan yang ada apakah sudah mencukupi kebutuhan atau ada kemungkinan untuk dikembangkan? Untuk saat ini sudah cukup, namun perlu untuk dan harus untuk dikembangkan di tahun berikunya, kenapa? Karena pastinya aplikasi yang dikelola di maintenance itu akan semakin banyak, sehingga tidak cukuplah dengan standar pelayanan terkait yang sudah ada, itu perlu lagi dikembangkan lagi, bahkan dibuat lebih rinci lebih komperhensif, sehingga mampu mengakomodir setiap proses dalam pengembangan aplikasi tersebut. Bagaimana organisasi dalam pengembangan perangkat lunak? Kalau secara struktural tentunya mengacu pada Permensetneg nomor 2 tahun 2011, dimana kalau secara struktur Adep membawahi beberapa Kabid, Kabid membawahi beberapa Kasubid, Ksubid membawahi beberapa pejabat struktural umum. untuk pranata komputer itu langsung dibawah Asdep. Tugas Kabid dan Kasubid mengkoordinasikan saja, tetapi untuk pertanggung jawaban itu langsung kepada Asdep.

173 157 Jadi peran Kabid dan Kasubid sebagai pengontrol pengembangan? Iya, biasanya akan dibentuk tim teknis, dalam hal ini tim panitia pengembangan aplikasi A sebutlah seperti itu, nanti yang dipimpin oleh Kabid atau Kasubidnya, nanti anggotanya terdiri dari para pranata komputer. Dalam pengembangan perangkat lunak, apakah ada metodologi khusus yang digunakan? Metodolgi khusus tidak, kita disini lebih kepada yang penting target pencapaian waktunya tercapai, dan target pencapaian outputnya tercapai, mengenai metodologi kita biasanya memberikan suatu alur dari proses perancangan, penyusunan, coding, testing, training, sampai kepada instalasi itu sudah kami berikan satu aturan guideline, tapi kalau untuk teknis detilnya kalau untuk tender dikembalikan kepada para penyedia, mereka menawarkannya seperti apa, mungkin ada yang menggunakan metode waterfall, prototype itu tergantung dari para penyedia melihat dari kompleksitas pekerjaan. Yang penting adalah target output tercapai, target waktu tercapai. Dan anggaran sesuai dengan apa yang sudah ditetapkan. Kalau untuk swakelola kita kembalikan lagi dilapangan tergantung juga kompleksitas dari pekerjaan atau aplikasi yang akan dibangun, kalau semakin komplek tentunya waktu juga semakin panjang. Kalau metodologi yang digunakan ini fleksibel menyesuaikan kepada kondisi di lapangan. Kalau memang kondisinya tepat menggunakan metode prototype itu aan digunakan. Tapi kalau tepatnya menggunakan waterfall atau menggunakan siklus SDLC itu juga digunakan. Jadi kalau metode itu sangat fleksibel, tergantung kondisi aplikasi yang dibangun, kondisi dari kesiapan user dalam pengimplementasian aplikasi tersebut. Apa harapan dari pengembangan perangkat lunak? Harapanya tentunya aplikasi yang dibangun sesuai dengan kebutuhan kita dan dapat dimanfaatkan secara maksimal oleh user, karena pembangunan aplikasi sering dijadikan semacam alasan, aplikasi dibangun tetapi banyak tidak digunakan. Tidak hanya di Setneg, di kantor pemerintah lain seperti itu. Lebih kepada pemborosan anggaran, masih banyak paradigma seperti itu. Perlu dikaji

174 158 lagi kenapa tidak bisa diimplementasi secara maksimal. Apakah salah disisi aplikasinya atau kemampuan dari pengguna yang belum siap atau mungkin dari budaya kerja yang belum terbentuk, ataukah banyak hal-hal lain. Karena yang perlu dikaji itu tidak hanya faktor teknis, tapi faktor non teknis juga. Kalau selama ini kendala dalam pengembangan perangkat lunak? Kendalanya tidak spesifik, tapi beragam. Ada aplikasi yang usernya siap tapi fungsi aplikasinya banyak yang belum mengakomodir kebutuhan user, sehingga dibutuhkan waktu untuk meng-customize, sedangkan kebutuhan semakin lama semakin cepat berubah. Akhirnya aplikasi yang sudah jadi berubah lagi. Itu salah satunya. Kedua, ada juga aplikasinya siap, tapi usernya tidak siap, karena belum didukung dengan infrastruktur. Dan juga belum didukung kemampuan user dalam mengoperasikan komputer. Ketiga, aplikasi siap, user siap, tetapi infrastruktur networknya masih ada kendala, itu juga ada. Itu semua harus menjadi PR bersama, tidak hanya dari bagian sistem dan jaringan, tetapi juga dari bagian lain, serta dari user-user lain yang memang menggunakan aplikasi tersebut. Ini adalah adanya semacam komitment bersama untuk sama-sama punya komitmen yang sama satu ingin memanfaatkan aplikasi ini sebaik mungkin. Itu yang penting. Kalau dari sisi dokumentasi apakah ada kendala? Kalau dari sisi dokumentasi, sejauh ini sudah banyak perbaikan. Dibanding tahuntahun sebelumnya, dokumentasi sudah mulai rapih. Ini tetap terus ditingkatkan, karena nanti penilaian kinerja tidak hanya dilihat dari aplikasi digunakan atau tidak, tetapi dilihat juga dari administrasi pendukung. Kedepannya masih akan ada pengembangan perangkat lunak? Masih, apalagi dengan adanya Reformasi Birokrasi dimana salah satu bidangnya adalah sistem informasi sehingga itu menjadi indikator penilaian bahwa masyarakat membutuhkan akses informasi yang cepat, yang tepat, yang akurat, maka membutuhkan suatu perangkat pendukung yaitu sistem informasi itu. Apakah ada rencana dari Kasubid Aplikasi Otomasi Perkantoran untuk perbaikan atau peningkatan kualitas penglolaan perangkat lunak?

175 159 Kalau melihat secara spesifik kita tentunya melihat kepada Grand Design SIKSN yang sudah ada dalam Permensetneg nomor 15 tahun Itu adalah rencana induk dari pengembangan sistem informasi dan teknologi informasi di Kementerian Sekretariat Negara. Dan seluruh unsur organisasi, baik itu Asdep, Kabid, Kasubid, bahkan staf harus mendukung itu semua, jadi rencana tentunya kita mengacu kepada Grand Design dari SIKSN tersebut.

176 160 TRANSKRIP WAWANCARA Nama Jabatan : Yusri Syahrul Mujib, S.Kom. : Pranata Komputer Pertama, Asisten Deputi Dukungan Data Kebijakan dan Informatika Tanggal : 13 Agustus 2013 Bisa diceritakan perkembangan sistem informasi di Kementerian Sekretariat Negara? Perkembangannya disini sistem informasi, yang existing juga sudah ada. Selanjutnya tetap setiap tahun ada pengembangan sistem yang baru dibuat sesuai permintaan user di unit-unit kerja lain di Setneg. Pengembangannya ada dua, yaitu secara swakelola dan lelang. Bagaimana peran pranata komputer dalam pengembangan perangkat lunak di Kementerian Sekretariat Negara? Untuk pranata komputer pastinya di level teknis, kalau untuk sistem yang sudah ada memaintenance, merawat, stand by apabila ada kerusakan dan lain-lain. Kalau untuk pengembangan sistem yang baru untuk swakelola tentunya harus terjun langsung development dari awal mulai dari requirement sampai dengan dipakai user. Kalau untuk sistem yang baru tapi dilelang pranata fungsinya di awal dan di akhir. Ketika di awal menyusun spesifikasi teknis kebutuhan misalnya seperti KAK nya, dan bilsa sudah lelang bisa jadi sebagai salah satu tim pemeriksa atau penerima dari software yang sudah jadi. Bisa diceritakan proses pengembangan perangkat lunak di Kemensetneg? Selama ini di Setneg untuk yang swakelola kita awalnya dari permintaan user ada requirement masuk terus ada pembentukan tim, pranata komputer sebagai anggota dari tim tersebut. Melakukan assessment kita rapat dengan user tersebut untuk

177 161 mengetahui kebutuhannya lalu dipetakan dimodelkan dalam rancangan. Untuk pendukung tes rancangannya masih kurang. Setelah itu masuk tahap pengembangan. Baru di deliver ke user. Setelah di deliver biasanya ada permintaan tambahan, ada kesalahan bug error semacam itu biasa terjadi. Untuk controlling dan monitoring terhadap pekerjaan apakah langsung dari tim pranata komputer atau ada struktur lain? Controlling dan monitoring belum ada, setiap pengembangan metodenya hanya progres report saja. Tiap periodik waktu tertentu kita rapat dengan user sejauh mana progressnya. Secara struktur tidak ada. Seharusnya dari level strukturalnya ada yang berfungsi sebagai controlling, istilahnya penanggung jawabnya dari tim tersebut. Dan dari pranata komputer hanya di level tekisnya. Apakah ada standar dalam pengembangan perangkat lunak selama ini? Yang ada standar pelayanan permintaan, tapi kalau lebih detilnya lagi itu belum ada. Lebih detil SOP nya pembuatan design itu berapa lama SOP nya harus bagaimana, siapa yang terlibat, sampai sedetil itu belum ada, SOP untuk pengembangan aplikasi. Apakah SOP seperti itu dibutuhkan untuk pengembangan aplikasi? Pastinya dibutuhkan, kedepan harus ada hal-hal seperti itu, hasrus disusun SOP. Bisa diceritakan organisasi pengembangan swakelola? Untuk swakelola masih sangat kurang, kita kerjanya masih serabutan. Belum terdokumentasi dengan baik, belum terstruktur dengan baik. Sehingga outpunya pun kadang kurang terkontrol dengan baik juga. Tapi sejauh ini masih bisa berjalan untuk pengembangan aplikasi swakelola. Tapi itu masih jauh dari kondisi ideal dalam pengembangan aplikasi. Ini memang kekurangan kita, ke depan memang harus kita standarisasi kita menganut framework pengembangan aplikasi tertentu, ya mungkin harus dikembangkan ke arah sana. Harapan dari pengembangan perangkat lunak di Setneg?

178 162 Ke depan kita dapat menerapkan sebuah metodologi tertentu. Pengembangan aplikasi yang sudah ada punya SOP yang bagus, terdokumentasi dengan baik. Sehingga di organisasi pengembangan aplikasi ini di tim itu ada knowledgenya. Meskipun nantinya ganti-ganti orang, tapi karena terdokumentasi dan ada metodologi yang sudah baku jadi siapapun orangnya akan bisa melaksanakan. Apakah ada kendala dalam pengembangan perangkat lunak? Kendalanya kadang-kadang kita kurang fokus, jadi tim pranata komputer yang aplikasi khususnya tidak fokus ke aplikasi. Banyak pekerjaan-pekerjaan lain yang harus ditangani dan itu tidak bisa dihindari. Sehingga pengembangan jadi terhambat dan lain-lain. Untuk saat ini masih ada perencanaan pengembangan perangkat lunak? Untuk saat ini masih banyak, ada beberapa pekerjaan yang belum tersentuh, belum dikerjakan dari yang sudah direncanakan.

179 163 TRANSKRIP WAWANCARA Nama Jabatan : Suhariono : Kepala Subbidang Data dan Informasi Politik, Hukum, dan Keamanan Tanggal : 26 Agustus 2013 Berkaitan dengan aplikasi yang dilelang yang gagal dikerjakan oleh pihak perusahaan dari luar, dimana pak Sehariono sebagai salah satu dari tim pemeriksa. Bisa diceritakan bagaimana waktu itu prosesnya? Waktu itu perusahaannya sudah menang lelang, dan diberikan waktu untuk mengerjakannya, sudah diceritakan maunya gimana dan segala macam. Ketika ditampilkan adalah proyek sebelumnya yang pernah dikerjakan sama dia. Dari pertama ada requirment dari user nya atau ada dokumentasi yang dibuat? Sudah ada requirement dan wawancara juga, kita undang dari eselon empat sampai karo. Dari pertama berarti sudah ada TOR dan dokumentasi kebutuhan user, kalau untuk yang membuat perencanaan pelaksanaan? Perencanaan pelaksanaan dari perusahaan, kita hanya memberitahukan keinginan dan output yang diberikan. Kita berikan berkas-berkas. Apakah ada proses pertemuan dari awal? Dari awal ada pertemuan, kita menceritakan yang kita inginkan, pekerjaannya apa. Proses selanjutnya di pertengahan ada pertemuan? Tetap ada pertemuan dengan usernya langsung.

180 164 Dari perusahaannya ada laporan perkembangan? Kalau perkembangan sepertinya tidak ada perkembangan, karena yang dilaporkan itu lagi itu lagi, progresnya tidak maju-maju. Dari usernya sendiri di pertengahan ada tambahan permintaan tidak? Tambahan permintaan belum, karena fokusnya yang pertama dulu bisa. Berarti masih permintaan pertama, sampai terakhirnya tidak ada perkembangan? Tidak ada perkembangan. Pak Asdep bilang kalau tidak bisa digagalkan saja. Berarti ketika pemeriksaan banyak yang tidak dipenuhi oleh perusahaannya? Tidak ada. Kita undang usernya dan kita kasih lihat hasilnya, dari pihak usernya mempertanyakan hasilnya karena jauh dari ekspektasi yang diharapkan, sehingga gagal. Ada dokumen planning yang diserahkan? Tidak ada, lisan saja. Pada waktu itu kan tugasnya sebagai anggota tim pemeriksa yang salah satu tugasnya mengontrol dan monitoring sampai dengan pekerjaannya diterima, dari tim pemeriksa apa yang sudah diusahakan untuk mengontrol pekerjaan tersebut? Kita dipertemuan melihat sejauh mana pekerjaannya, tapi tidak ada perubahan. Jadi secara umum masalahnya diperusahaan? Iya, karena mereka juga mengakui, karena ketika kena pinalti akan kita gugurkan, kita undang dia. Kita kasih lihat hasil-hasil yang telah dia buat, keinginan kita, sudah kita kasih waktu, mereka kasih alasan karena tim belum siap.

181 165 TRANSKRIP WAWANCARA Nama Jabatan : Muhaziron Sulistiyo Wibowo : Kepala Subbidang Aplikasi Otomasi Perkantoran Tanggal : 27 Agustus 2013 Seperti yang kita ketahui pengembangan perangkat lunak di Setneg terbagi dua, melalui proses lelang dan swakelola. Mungkin bisa diceritakan prosesnya dari awalnya mulai dari permintaan user? Kalau secara teknis tadi tentunya didahulukan dengan memorandum dari user kepada pimpinan dalam hal ini Asep DDKI, jadi memorandum setingkat eselon 2. Dari user kepada Asdep DDKI meminta untuk dibantu pembangunan aplikasi x misalkan. Setelah memonya jadi pak Asdep akan memberikan disposisi perintah kepada jajarannya dalam hal ini Kepala Bagian Sistem dan Jaringan beserta struktur dibawahnya Kasubid Aplikasi Otomasi Perkantoran, Kasubid Aplikasi Kebijakan sesuai dengan tugas fungsinya masing-masing. Kira-kira aplikasi yang diminta oleh user itu bisa dilakukan bagaimana caranya, apakah melalui tender atau melalui swakelola. Kalau memang anggarannya tersedia untuk tender, akan dilakukan melaui tender. Namun bila anggarannya tidak tersedia untuk tender tapi aplikasinya sangat dibutuhkan biasanya solusinya adalah swakelola dibangun oleh pranata komputer. Penilaian kedua dari kompleksitas aplikasi, kalau permintaan aplikasinya dibangun oleh perangkat software yang agak kompleks kita serahkan kepada vendor melalui tender, tapi kalau simple aplikasinya dan bisa dikerjakan sendiri, itu teman-teman pranata komputer yang mengerjakan. Semisal diputuskan hasil dari analisa, aplikasi ini dilakukan melalui ternder, berarti kita akan menjawab memorandum dari pejabat dalam hal ini user untuk menindaklanjuti dengan diadakannya suatu pertemuan. Pertemuan tersebut nanti akan dibahas kebutuhan detailnya seperti apa sistem informasi yang akan dibangun, kemudian fungsi-fungsi yang diminta seperti apa, inputnya seperti apa, outputnya seperti apa, penggunanya bagaimana, itu akan dibahas secara detail. Ketika itu sudah

182 166 dibahas, antra Asdep DDKI dan user akan dituangkan dalam bentuk dokumen Kerangka Acuan Kerja (KAK), dokumen KAK itu nantinya akan ditanda tangani oleh pimpinan user eselon 2 dan Asdep DDKI sebagai acuan bahwa nanti aplikasi yang dibangun akan memiliki fungsi dan fasilitas seperti yang tertuang dalam KAK tersebut. Setelah itu ditanda tangani KAK akan diberikan kepada Pejabat Pembuat Komitmen (PPK) beserta rincian anggaran belanja yang dibutuhkan dalam membangun aplikasi ini. Oleh Pejabat Pembuat Komitmen KAK akan dianalisa, dan RAB juga akan dianalisa sehingga nanti akan menghasilkan Harga Prakiraan Sendiri (HPS). Setelah ditentukan HPS oleh Pejabat Pembuat Komitmen berikut dengan perbaikan atau penyempurnaan KAK, itu akan diserahkan kepada panitia pengadaan atau pejabat pengadaan untuk dilakukan lelang. Lelang tersebut nanti akan dilakukan pejabat dimulai dengan membuat dokumen pengadaan dengan materinya salah satunya adalah KAK tersebut, kemudian akan dibuat jadwal pelelangan, metode pelelangan, jangka waktu yang akan dibuat oleh panitia pengadaan. Ditambah rancangan kontrak akan dibuat pejabat pembuat komitmen beserta dengan pejabat pengadaan. Kemudian lelang dilaksanakan oleh panitia pengadaan, peserta lelang sudah mulai masuk dan akan dilakukan evaluasi. Setelah dilakukan evaluasi, perusahaan dengan nilai tertinggi sesuai dengan metodologi yang telah ditentukan akan ditetapkan sebagai pemenang, dilanjutkan dengan penandatanganan kontrak. Disitulah dimulai kickoff meeting dimana akan bertemu user selaku pengguna pekerjaan, Asdep DDKI selaku penanggung jawab anggaran untuk pembangunan aplikasi tersebut, pemenang yaitu perusahaan yang akan mengerjekan, serta Pejabat Pembuat Komitmen yang menandatangani kontrak atas nama Kementerian Sekretariat Negara. Setelah itu pekerjaan dilakukan dengan diawasi Tim Pemeriksa atau Pejabat Pemeriksa Pekerjaan selama proses pekerjaan itu berlangsung. Berarti terhadap pemenang itu tanggung jawab pemeriksa? Iya, setelah ada pemenang, kemudian ditetapkan oleh SPPBJ dan kemudian ada kontrak itu tanggung jawab PPK, kemudian sudah mulai mengerjakan itu adalah tanggung jawab Tim Pemeriksa.

183 167 Dari pertama apakah ada yang bertanggung jawab, maksudnya mulai dibuat KAK terus ada pengawalan? Atau pelimpahan kepada Kasubag disini atau yang lain untuk mengawal program tersebut? Kalau secara strutktur Asdep DKKI tentunya Kasubag yang ditugaskan yang mengawal atau memonitoring pekerjaan tentunya ada, sesuai fungsi masingmasing Kasubag dan Kabag tentunya. Dan dia akan berkoordinasi dengan tim pemeriksa, tim pemeriksanya biasanya diangkat dari Kasubag, Kabag, ataupun teman-teman dari pranata komputer yang memahami secara teknis, atau tidak menutup kemungkinan diangkat dari user selaku pengguna. Andai tim pemeriksa diangkat dari orang luar ya tentunya secara teknis tim dari Asdep DDKI dalam hal ini pejabat yang ditunjuk Asdep DDKI bertugas mengawal sampai semua pekerjaan itu selesai. Proses lelang ini terikat waktu dan biaya, untuk manajeman kebutuhan user itu bagaimana? Kalau penambahannya itu bersifat minor kecil, mengerjakannya tidak membuat penambahan resources sumber daya manusia, tidak signifikan, biasanya pelaksana dalam hal ini pemenang pekerjaan akan siap mengakomodir perubahan tersebut. Namun, apabila bersifat kompleks atau major dan juga ketika dianalisa bisa menyebabkan penambahan resources yang cukup besar, itu nantinya akan dibicarakan dan dicarikan solusinya. Biasanya kalau tidak bisa dilakukan karena keterbatasan anggaran itu menjadi suatu perencanaan ke depan. Bisa dalam bentuk pemeliharaan atau perawatan aplikasi. Untuk yang memutuskan perubahan atau penambahan permintaan? Itu akan didiskusikan antara tim panita, pemeriksa, PPK dan pelaksana pekerjaan. Dalam kontrak pun dijelaskan secara detail poin apa saja yang menjadi tanggung jawab yang harus dilaksanakan. Kalau tidak ada dalam poin-poin tersebut tentunya bukan menjadi suatu kewajiban bagi penyedia. Untuk perencanaan proyek, untuk lelang apakah diserahkan kepada tim penyedia untuk membuat project plan?

184 168 Project palan kalau secra teknis dilapangan kita melihat pada jadwal yang sudah ditetapkan dalam KAK, nanti penyedia juga akan membuat rencana jadwal mereka. Nanti akan kita lihat, kalau memang dalam proses pencocokan jadwal tersebut memang bisa diakomodir semua pekerjaan pekerjaan dapat diselesaikan jadwal yang telah ditetapkan. Penyedia barang jasa sepanjang itu bisa dipertanggung jawabkan bisa dilaksanakan tidak apa-apa. Batas akhirnya adalah batas akhir ketika semua pekerjaan harus diserahkan semua. Selama ini dari penyedia menyerahkan project plan? Selama ini iya, dalam dokumen penawaran, mereka menyerahkan project plan. Rencana-rencana apa saja yang akan mereka kerjakan dalam kurun waktu beberapa waktu. Misalkan project ada tiga bulan, dalam waktu tiga bulan mereka akan melakukan apa saja tahapan-tahapannya. Mereka sedia dan jelaskan dalam metodologi serta jadwal pelaksanaan pekerjaan. Untuk monitoring control oleh tim pemeriksa, setelah serah terima ada penyerahan pekerjaan lagi? Iya, pekerjaan nanti diserahkan kepada tim pemeriksa. Tim pemeriksa akan membuat suatu berita acara bahwa pekerjaan telah diterima dengan baik. Setelah itu dilaporkan kepada PPK, lalu dibuatkan suatu proses pencairan anggaran. Berarti disini ada prosedur dari awal sampai akhir penanganan project? Betul, dan melibatkan beberapa tim yang berbeda, baik itu dari PPK, panitia pengadaan, tim pemeriksa, biro atau unit kerja yang bertanggung jawab atas anggaran tersebut, dan user selaku pengguna aplikasi sistem informasi tersebut. Bila dilihat dari data yang ada, ada pekerjaan yang gagal juga? Iya benar. Kira-kira kalau pekerjaannya gagal menjadi masalah tidak? Kalau jadi masalah dalam artian mungkin target tidak tercapai, namun perlu juga dianalisa atau dikaji kenapa terjadi. Itu muncul dari banyak hal, bisa dari

185 169 vendornya tidak mampu melaksanakan pekerjaan tepat waktu, dari kompleksitas pekerjaan yang terlalu berat, ada penambahan-penambahan di jalan, penambahan user requirement, banyak faktor-faktor non teknis sehingga pekerjaan itu gagal. Namun, dalam Perpres no 70 tahun 2012 itu sudah diatur bahwa kalau memang pekerjaan itu tidak dapat dilaksanakan atau tidak tepat waktu, ada waktu keterlambatan yang bisa ditoleransi yaitu 50 hari kalender, kalau lebih dari 50 hari kalender itu tidak ada perpanjangan lagi, itu akan diputuskan oleh tim pemeriksa apakah penyedia ini bisa mendapatkan haknya atau sebagian atau sama sekali tidak dibayarkan. Pada keterlambatan itu ada denda? Ada per hari kalender. Bisa jadi pekerjaan yang gagal diusulkan lagi tahun depannya? Iya betul. Itu kemungkinan bisa masuk program tahun depannya bagaimana? Jadi ada kemungkinan tahun depan tidak bisa dilaksanakan melalui sistem tender, namun ada solusi lain yaitu swakelola oleh teman-teman pranata komputer dengan catatan kompleksitas disesuaikan. Jadi mungkin tidak selengkap requirement yang ditenderkan, harus disesuaikan dengan kemampuan atau resources yang ada terutama pranata komputer. Kalau ingin membuat persis sama dengan apa yang akan kita tenderkan itu berat, paling kita akan coba dengan strategi memilah mana dulu prioritas, poin-poin mana dulu yang bisa ada, untuk waktu selanjutnya bisa dikembangkan lagi poin-poin yang belum ada. Disini pernah ada perusahaan yang gagal? Ada, dua bahkan. Tahun 2009 sekali, itu perusahaan tidak mendapatkan sama sekali apapun, bahkan dia harus membayar denda pada negara. Itu pernah terjadi. Itu dikarenakan kesalahan penyedianya tidak komit dengan jadwal yang telah mereka usulkan, mereka hanya membuat jadwal itu ditulisan saja, tetapi pada pelaksanaan tidak dilaksanakan.

186 170 Apakah ada bahan yang sudah jadi? Tidak, karena aplikasi itu tidak bisa digunakan dengan kondisi yang setengah seperti itu, akhirnya sama sekali tidak dipakai. Penyedia mendapat konsekuesi tidak dibayar sama sekali, bahkan mendapatkan denda. Itu faktor karena penyedia? Betul. Tidak ada penambahan kebutuhan? Tidak, yang kedua pun tahun 2011 kejadian sama, penyedia yang tidak komit ternyata resources yang mereka gunakan tidak maksimal di Setneg mereka hanya menggunakan beberapa orang. Padahal dalam kontrak yang sudah ditandatangani mereka mengerahkan misalkan 10 orang tetapi yang bekerja hanya 2 orang tidak akan selesai. Tapi dia tidak kena denda, tapi tidak dibayar. Seharusnya kena denda dan masuk daftar hitam, itu yang tidak dilakukan. Dua pekerjaan yang gagal yang pernah saya temukan seperti itu. Mungkin ada pekerjaan lain yang juga bisa dikatakan tidak berhasil dan faktornya mungkin tidak dari penyedia juga dari usernya pun mungkin ada, tapi ketika saya menangani pengadaan yang saya temukan dan saya terlibat langsung itu dua. Untuk dua yang gagal tersebut, proses yang sudah dilakukan oleh pemeriksa seperti apa? Sebenarnya monitoring dilaksanakan terus, perusahaan diingatkan terus bahwa waktu tinggal sekian hari. Tapi mereka menganggap remeh. Tapi dari pertama perusahaan sudah melaporkan perkembangannya? Sudah, ada perkembangan tapi tidak sampai 100% berhenti di 70%. Apakah ada penambahan pekerjaan pada kegiatan tersebut? Tidak ada. Bagaimana perkembangan pengadaan saat ini?

187 171 Kalau untuk proses lelangnya sekarang jauh lebih maju. Karena sekarang sudah online dimana sudah tidak ada lagi untuk memperbaiki dokumen penawaran, tidak ada lagi kesempatan terlalu banyak untuk bertatap muka, dengan prosesnya yang lebih baik, saya yakin hasilnya pun akan lebih baik. Untuk kedepannya apa yang diinginkan? Ada dua faktor, faktor dari pemilik pekerjaan Setneg sendiri, maupun faktor yang melaksanakan pekerjaan dari pihak luar. Tantangan kedepan adalah bagaimana kita bisa, antara pemilik pekerjaan dan pelaksana pekerjaan itu bisa memiliki pemahaman yang sama terhadap apa yang akan dikerjakan. Jangan sampai nanti pemiliknya punya persepsi A, yang melaksanakan persepsinya B, itu alamat tidak akan selesai pekerjaan. Tantangan kedepan adalah bagaimana apa yang dibutuhkan oleh user bisa diterjemahkan ke dalam KAK dan dipahami oleh pelaksana pekerjaan, sehingga apa yang diminta dibutuhkan sesuai dengan apa yang dikerjakan. Dan yang perlu diperbaiki adalah study kelayakan pengembangan pembangunan sistem informasi, apakah usulan dari suatu pengembangan sistem informasi layak untuk ditenderkan atau layak untuk diswakelolakan, itu juga ada pertimbangan-pertimbangan secara ilmiah dapat dipertanggung jawabkan. Penilaian aplikasi mana yang memang pantas ditenderkan diswakelolakan. Kemudian dalam penentuan anggarannya pun mudah-mudahan jauh lebih tepat, karena selama ini hanya berdasarkan jumlah tenaga ahli dan itu sangat subjektif. Jadi kedepanya perlu dikembangkan penilaian terhadap pengembangan aplikasi yang jauh lebih objektif. Seharusnya kita bisa berbicara berapa jumlah modul, jumlah report yang diinginkan, form yang ingin dibuat dlam aplikasi tersebut, jumlah query yang ingin di developt itu juga perlu dihitung, berapa jumlah layer. Apakah di Setneg dibutuhkan penilaian terhadap pengembang? Iya, makanya sekarangkan sudah ada Inkindo, Ikatan Nasional Konsultan Indonesia dan asosiasi konsultan juga sudah ada, alangkah lebih baiknya misalkan dari asosiasi konsultan itu bisa memberikan peringkat kepada perusahaanperusahaan yang memang sudah ada di Indonesia bahkan dia masuk ke level 3

188 172 level 2, sebagai masukan bagi pemilik-pemilik pekerjaan ketika mereka memilih perusahaan-perusahaan mana yang akan diikutsertakan dalam project mereka. Jadi sepertinya perlulah, makanya CMMI, leveling untuk tiap perusahaan. Yang saya tahu di Indonesia baru ada dua, Jati sama Sigma, kalau tidak salah Jati dan Sigma tiga levelingnya. Tapi untuk perusahaan-perusahaan lain saya belum pernah dengar, kalau memang semua IT consultant itu akan di leveling itu akan lebih enak lagi dalam penilaian. Jadi memang diperlukan lagi peningkatan? Pemeringkatan dan peningkatan, karena kalau peningkata itu kalau bisa semuanya bisa diukur secara quantitative dengan adanya leveling itu. Jadi siapapun pemilik pekerjaan bisa tahu bahwa perusahaan ini memiliki pemeringkatan dalam tahun ini nomor berapa, masuk tidak dalam kategori 10 perusahaan yang bagus tahun lalu. Itu sepertinya belum ada? Belum ada, tahunya informasi informal, seperti dari teman, dari instansi lain.

189 173 TRANSKRIP WAWANCARA Nama Jabatan : Andi Nugroho : Kepala Subbagian Informasi dan Dokumentasi Kepegawaian, Biro Kepegawaian Tanggal : 28 Agustus 2013 Bagaimana perkembangan perangkat lunak di Kementerian Sekretariat Negara? Di Sekretariat Negara perkembangannya pesat karena di masing-masing instansi, masing-masing satuan organisasi unit kerja membutuhkan aplikasi, tapi harus dilihat juga grand design yang dimiliki Setneg, kira-kira mengakomodir itu semua atau tidak. Pada unit kerja ini memiliki aplikasi SIMPEG, bisa diceritakan proses pembangunan dari aplikasi tersebut? Seperti biasa, ada lelang, dipilih pemenangnya siapa, diberitahu yang kita inginkan apa. Dari awal proses ada pengajuan ke unit kerja IT? Ada pengajuan ke unit kerja IT karena anggaran ada di unit IT. Untuk requirementnya yang buat dari unit kerja ini? Unit kerja ini sendiri yang nyusun kemudian diberikan ke unit kerja IT. Pada saat pembangunan di tengah jalan ada tambahan kebutuhan baru? Biasanya kita sesuai dengan KAK dulu, soalnya kadang-kadang sesuai dengan KAK saja pengerjaannya bisa mundur. Jadi kalau kita tetapkan 3 bulan, dia bisa sampai 3 bulan pas. Jarang ada sistem di kita, kalau sudah ditetapkan 3 lalu mereka mengajukan tenaga ahli dan segala macam 3 bulan, biasanya mundur.

190 174 Penyebab kemundurannya apa? Penyebab kemunduran bisa juga karena lebih sering mereka mengajukan tenaga ahli, ternyata tenaga ahlinya tidak sebanyak yang mereka cantumkan pada saat dilelang. Bisa juga karena perusahaannya kurang bisa menterjemahkan apa yang kita inginkan. Walaupun sudah sedetail mungkin, kita buatkan flownya, sistem seperti apa, dia tidak bisa menterjemahkan, jadinya mundur juga. Itu tanpa ada penambahan baru? Iya. Itu kan sebenarnya tugas dari pemenangnya, tapi karena kita belajar dari pengalaman pengadaan sebelumnya, kita buatkan flownya. Supaya ketika kita kasih flownya kita kasih sedetail mungkin, mereka tinggal buat saja. Tetapi ternyata tetap saja mereka terkendala dalam membaca flownya, atau terkendala memahami bisnis proses yang ada. Karena pada saat lelang, dokumen lelang itu hanya gambaran umum, mereka juga memberikan tanggapan terhadap dokumen tersebut juga umum menjawabnya. Kita menilai jawaban umum yang mereka berikan yang paling mendekati yang mana. Tapi pada saat yang paling mendekati itu menang dan kita berikan flownya tetap saja ada kesulitan bagi mereka. Untuk pembangunan ini sebelumnya sudah ada perkiraan untuk pekerjaan SIMPEG dengan beberapa modul yang diinginkan diperkirakan dengan waktu 3 bulan dan tenaga ahli yang ditentukan seharusnya selesai? Kalau perkiraan awal disini biasanya jarang, dalam artia kita benar-benar secara teori memperkirakan pekerjaan ini berapa, itu jarang. Tapi menurut kami, dari apa yang kita minta sama waktu pengerjaannya seharusnya cukup. Jadi kalau melihat berapa tenaga ahli yang mereka punya, kalau memang itu benar-benar tenaga ahlinya yang mereka tawarkan itu sesuai, seharusnya cukup. Misalnya 10 tenaga ahli, kalau benar-benar 10 tenaga ahli seharusnya cukup. Tapi yang seringnya sekarangkan yang 10 itu tidak benar-benar 10 itu ada, karang-kadang 10 itu hanya untuk administrasi atau apa. Paling yang mengerjakan hanya beberapa orang, itu yang buat lama. Dari unit kerja ini ada yang memantau dari awal untuk pekerjaan itu?

191 175 Iya. Berarti dari sini membuat dokumen KAK, pembuatan flow tadi namanya apa? Ada dokumen seperti UML. Tapi dari penyedia buat juga? Tidak, mereka membuat tanggapan terhadap dokumen pengadaan, tapi tidak membuat UML itu. Mereka membuat laporan awal? Buat, tapi tidak sedetail yang kita inginkan. Bila tidak ada penambahan berarti tidak ada yang berubah dari permintaan awal? Iya. Dipertengahan jalan tidak ada permintaan penambahan baru? Karena yang kita minta diawal saja sebenarnya belum semuanya, makanya itu mundur berapa lama kita menekankan ini ini ada di KAK. Jadi kalau nanti ini diperiksai mau tidak mau harus diproses semua. Mungkin bisa juga di Setneg ini sebelum buat software ada kajian seperti tadi, misalnya diselesaikannya berapa lama, untuk pekerjaan ini untuk programmer yang expert satu modul butuh berapa. Berarti ini untuk proses pertamanya tidak ada pembahasan perkiraan waktu dengan modul yang dimintakan? Kalau kajian yang benar-benar memang tidak ada, maksudnya untuk membuat software memang ada kajiannya. Kalau di departemen atau instansi lain ada, sebelum melakukan untuk lelang ini, suatu sistem itu dikaji dulu, benar-benar kajian teknis yang benar-benar teknis. Kalau disini perkiraan kira-kira modul ini tinggal waktu yang tersedia berapa bulan, 3 bulan, 4 bulan itu kan disini tidak ada.

192 176 Sebenarnya itukan dikaji dulu, anggarannya yang sesuai berapa, itu juga yang buat nanti di Asdep DDKI buat bargaining juga ke Biro Perencanaan. Dari kajian profesional kajian konsultan sebenarnya anggarannya tidak segini atau lebih tinggi atau anggarannya ketinggian harusnya dikurangin. Jadi misalnya kita butuh satu tahun di bulan Januari kita sudah bisa mulai pengadaan. Jadi itu juga jadi maslah juga buat pengembang? Iya, pengembang itu kan kadang-kadang dia tidak lihat lagi waktunya berapa bulan yang penting dia dapat proyek, disesuaikan saja berapa bulan maunya panitia. Itu yang seringnya jadinya terlewat. Jarang ada konsultan tepat waktunya dan sesuai. Untuk pengembangan SIMPEG ini, dari analisa awal sudah ada, perancangan sudah ada, terus sampai pembuatan sistem dia melaporkan kegiatannya? Melaporkan, berkala melaporkan. Diakhirnya ada uji coba? Ada uji coba, bahkan kita ikut uji coba, tidak kita serahkan ke mereka, jadi kita temukan bug-bugnya. Sampai ke instalasi? Ya. Umunya kalau pelelangan di Setneg tahapannya analisa, perancangan, penyusunan, uji coba, instalasi, pelatihan, dan dokumentasi. Berarti pelatihan juga ada? Iya. Kalau dokumentasi dari penyedia bagaimana? Dokumentasi sesuai dengan yang kita minta, paling buat memenuhi syarat administrasi saja. Jarang sampai lengkap sekali. Biasanya kalau itu sudah lewat

193 177 dari tanggal periode lelangnya nanti kita minta lagi yang lebih lengkapnya, di terakhir biasanya. Berarti yang ini ada ya? Ada. Kalau dari usernya ada kendala untuk pengembangan ini? Kalau dari usernya menunggu dari pengembangan ini jadi. Jadi misalnya dia sudah jadi 90% atau 80% baru di uji coba dengan usernya yang ada masukan biasanya. Harapan terhadap pengembangan perangkat lunak di Setneg, ada tidak proses-proses yang perlu ditambahkan? Paling tidak semua sistem yang dikembangkan mengacu pada grand design Asdep DDKI, paling tidak jangan sampai semua satuan kerja itu buat tapi tidak ada integrasinya, saling tumpang tindih fungsi. Untuk pengembangnya paling tidak bisa terukur setiap kerjaanya mereka, jadi kita ada kajiannya sebelum melakukan lelang, kita monitornya juga bisa tahu, saat pengadaan benar tidak ini personilnya, personil yang diajukan benar tidak, jangan sampai yang mengerjakan beda lagi.

194 178 Lampiran 2 : Administrasi

195 179

196 180

197 181

198 182

199 183

200 184

201 185

202 186

203 187 Lampiran 3 : Keterangan Goals dan Practices dari Process Area

204 188 Keterangan Goals dan Practices dari Process Area yang dinilai: REQUIREMENTS MANAGEMENT Tujuan dari Manajemen Kebutuhan adalah untuk mengelola kebutuhan produk proyek dan komponen produk, serta untuk memastikan keselarasan antara kebutuhan, rencana proyek, dan produk kerja. Specific Goal dan Specific Practice SG 1 Manage Requirements Kebutuhan dikelola dan dihubungkan dengan rencana proyek dan produk kerja yang sudah diidentifikasi. SP 1.1 Understand Requirements Mengembangkan pemahaman dengan kebutuhan penyedia tentang makna kebutuhan. SP 1.2 Obtain Commitment to Requirements Mendapatkan komitmen untuk kebutuhan dari peserta proyek. SP 1.3 Manage Requirements Changes Mengelola perubahan kebutuhan sebagaimana mereka berevolusi selama proyek. SP 1.4 Maintain Bidirectional Traceability of Requirements Menjaga bidirectional traceability antara kebutuhan dan produk kerja. SP 1.5 Ensure Alignment Between Project Work and Requirements Memastikan bahwa rencana proyek dan produk kerja tetap selaras dengan kebutuhan. Work Products 1. Daftar kriteria untuk membedakan sesuai kebutuhan penyedia 2. Kriteria untuk evaluasi dan penerimaan kebutuhan 3. Hasil analisis terhadap kriteria 4. Satu set kebutuhan yang telah disetujui 1. Penilaian dampak kebutuhan 2. Komitmen yang terdokumentasi terkait kebutuhan dan perubahan kebutuhan 1. Permintaan perubahan kebutuhan 2. Laporan dampak perubahan kebutuhan 3. Status kebutuhan 4. Database kebutuhan 1 Matriks penelusuran kebutuhan 2. Sistem pelacakan kebutuhan 1. Dokumentasi inkonsistensi antara kebutuhan dan rencana proyek dan produk kerja, termasuk sumber dan kondisi 2. Tindakan korektif

205 189 Generic Goal dan Generic Practice GG 1 Achieve Specific Goals Specific goals dari area proses didukung proses perubahan input work products yang teridentifikasi ke output work products yang teridentifikasi. GP 1.1 Perform Specific Practices Melakukan specific practices dari area proses untuk mengembangkan produk kerja dan memberikan pelayanan untuk mencapai specific goals dari area proses. GG 2 Institutionalize a Managed Process Proses ini dilembagakan sebagai proses yang dikelola. GP 2.1 Establish an Organizational Policy Membentuk dan memelihara kebijakan organisasi untuk perencanaan dan melakukan proses. GP 2.2 Plan the Process Membangun dan mempertahankan rencana untuk melakukan proses tersebut. GP 2.3 Provide Resources Menyediakan sumber daya yang memadai untuk melakukan proses, pengembangan produk kerja, dan menyediakan jasa dari proses. Work Products / Elaboration REQM Elaboration Kebijakan ini menetapkan harapan organisasi untuk mengelola kebutuhan dan mengidentifikasi inkonsistensi antara kebutuhan, work products, dan rencana proyek. REQM Elaboration Rencana ini untuk melakukan proses requirements management yang menjadi bagian dari (atau direferensikan oleh) rencana proyek seperti yang dijelaskan dalam area proses project planning.

206 190 GP 2.4 Assign Responsibility Menetapkan tanggung jawab dan wewenang untuk melakukan proses, pengembangan produk kerja, dan menyediakan jasa proses. GP 2.5 Train People Melatih orang yang melakukan atau mendukung proses yang diperlukan. REQM Elaboration Contoh sumber daya yang disediakan meliputi: 1. Alat lacak kebutuhan 2. Alat Lacak Subpractices 1. Menetapkan tanggung jawab keseluruhan dan kewenangan untuk melakukan proses. 2. Menetapkan tanggung jawab dan wewenang untuk melakukan tugastugas khusus dari proses. 3. Konfirmasikan bahwa orang-orang yang ditugaskan untuk tanggung jawab dan wewenang memahami dan menerima mereka. REQM Elaboration Contoh topik pelatihan meliputi : 1. Aplikasi domain 2. Definisi persyaratan, analisis, review, dan manajemen 3. Alat manajemen kebutuhan 4. Manajemen konfigurasi GP 2.6 Control Work Products Penempatan produk kerja yang dipilih dari proses di bawah tingkat yang sesuai kontrol. 5. Negosiasi dan resolusi konflik REQM Elaboration Contoh produk kerja ditempatkan di bawah kontrol meliputi : 1. Kebutuhan 2. Matrik penelusuran kebutuhan

207 191 GP 2.7 Identify and Involve Relevant Stakeholders Mengidentifikasi dan melibatkan pemangku kepentingan yang relevan dari proses seperti yang direncanakan. REQM Elaboration Contoh kegiatan keterlibatan stakeholder meliputi: 1. Menyelesaikan masalah pada pemahaman kebutuhan 2. Menilai dampak perubahan kebutuhan 3. Berkomunikasi traceability bidirectional GP 2.8 Monitor and Control the Process Memantau dan mengendalikan proses terhadap rencana untuk melakukan proses dan mengambil tindakan korektif yang tepat. 4. Mengidentifikasi inkonsistensi antara kebutuhan, rencana proyek, dan produk kerja REQM Elaboration Contoh langkah-langkah dan produk kerja yang digunakan dalam pemantauan dan pengendalian meliputi: 1. Persyaratan volatilitas (persentase kebutuhan yang berubah) 2. Jadwal koordinasi kebutuhan GP 2.9 Objectively Evaluate Adherence Objektif mengevaluasi kepatuhan dari proses dan produk kerja yang dipilih terhadap deskripsi proses, standar, dan prosedur, dan ketidakpatuhan. 3. Jadwal untuk analisis kebutuhan yang diusulkan berubah

208 192 REQM Elaboration Contoh kegiatan ulasan meliputi: A1. Mengelola kebutuhan A2. Memastikan keselarasan antara rencana proyek, produk kerja, dan kebutuhan Contoh produk kerja terakhir adalah sebagai berikut: B1. Kebutuhan GP 2.10 Review Status with Higher Level Management Review kegiatan, status, dan hasil proses dengan manajemen tingkat yang lebih tinggi dan menyelesaikan masalah. B2. Matrik penelusuran kebutuhan REQM Elaboration Usulan perubahan komitmen terakhir yang akan dibuat eksternal organisasi dengan manajemen tingkat yang lebih tinggi untuk memastikan bahwa semua komitmen dapat dicapai. PROJECT PLANNING Tujuan Perencanaan Proyek adalah untuk membangun dan memelihara rencana yang mendefinisikan kegiatan proyek. Specific Goal dan Specific Practice SG 1 Establish Estimates Memperkirakan parameter perencanaan proyek yang akan dibangun dan dipelihara. SP 1.1 Estimate the Scope of the Project Membentuk tingkat atas work breakdown structure (WBS) untuk memperkirakan lingkup proyek. Work Products 1. Deskripsi tugas 2. Deskripsi paket pekerjaan 3. WBS

209 193 SP 1.2 Establish Estimates of Work Product and Task Attributes Membangun dan memelihara perkiraan produk kerja dan atribut tugas. SP 1.3 Define Project Lifecycle Phases Menentukan fase siklus hidup proyek yang menjadi ruang lingkup perencanaan. SP 1.4 Estimate Effort and Cost Perkirakan usaha dan biaya untuk produk kerja dan tugas berdasarkan estimasi pemikiran proyek. SG 2 Develop a Project Plan Sebuah rencana proyek ditetapkan dan dipelihara sebagai dasar untuk mengelola proyek. SP 2.1 Establish the Budget and Schedule Membangun dan memelihara anggaran proyek dan jadwal. SP 2.2 Identify Project Risks Mengidentifikasi dan menganalisis risiko proyek. SP 2.3 Plan Data Management Rencana pengelolaan data proyek. 1. Ukuran dan kompleksitas tugas dan produk kerja 2. Memperkirakan model 3. Perkiraan atribut 4. Pendekatan Teknis Fase siklus hidup proyek 1. Estimasi pemikiran 2. Estimasi usaha proyek 3. Perkiraan biaya proyek 1. Jadwal proyek 2. Jadwal dependensi 3. Anggaran proyek 1. Risiko yang teridentifikasi 2. Dampak risiko dan kemungkinan terjadinya 3. Prioritas Risiko 1. Rencana pengelolaan data 2. Daftar induk data yang dikelola 3. Data content dan deskripsi format 4. Daftar kebutuhan data untuk pengakuisisi dan pemasok 5. Kebutuhan privasi 6. Kebutuhan keamanan 7. Prosedur keamanan 8. Mekanisme untuk pengambilan data, reproduksi, dan distribusi 9. Jadwal pengumpulan data proyek 10. Daftar data proyek yang akan dikumpulkan

210 194 SP 2.4 Plan the Project s Resources Rencana sumber daya untuk melakukan proyek. SP 2.5 Plan Needed Knowledge and Skills Rencana kebutuhan pengetahuan dan keterampilan untuk melakukan proyek. SP 2.6 Plan Stakeholder Involvement Rencana keterlibatan stakeholder yang diidentifikasi. SP 2.7 Establish the Project Plan Membangun dan memelihara rencana proyek secara keseluruhan. SG 3 Obtain Commitment to the Plan Komitmen dengan rencana proyek yang ditetapkan dan dipelihara. SP 3.1 Review Plans That Affect the Project Meninjau semua rencana yang mempengaruhi proyek untuk memahami komitmen proyek. SP 3.2 Reconcile Work and Resource Levels Menyesuaikan rencana proyek untuk menyelaraskan ketersediaan dan sumber daya yang diperkirakan. 1. Paket pekerjaan 2. WBS kamus pekerjaan 3. Kebutuhan staf berdasarkan ukuran dan ruang lingkup proyek 4. Fasilitas kritis dan daftar peralatan 5. Definisi proses dan alur kerja, dan diagram 6. Daftar kebutuhan administrasi proyyek 7. Laporan status 1. Inventarisasi keterampilan yang dibutuhkan 2. Staffing dan rencana karyawan baru 3. Database (mis., keterampilan, pelatihan) 4. Rencana pelatihan Rencana keterlibatan stakeholder Rencana proyek secara keseluruhan Rekaman dari tinjauan rencana yang mempengaruhi proyek 1. Metode Revisi dan parameter estimasi yang sesuai (misalnya, alat yang lebih baik, penggunaan komponen off-the-shelf) 2. Renegosiasi anggaran 3. Revisi jadwal 4. Daftar revisi kebutuhan 5. Negosiasi ulang perjanjian dengan pemangku kepentingan

211 195 SP 3.3 Obtain Plan Commitment Mendapatkan komitmen dari pemangku kepentingan terkait yang bertanggung jawab untuk melakukan dan mendukung pelaksanaan rencana. Generic Goal dan Generic Practice GG 1 Achieve Specific Goals Specific goals dari area proses didukung proses perubahan input work products yang teridentifikasi ke output work products yang teridentifikasi. GP 1.1 Perform Specific Practices Melakukan specific practices dari area proses untuk mengembangkan produk kerja dan memberikan pelayanan untuk mencapai specific goals dari area proses. GG 2 Institutionalize a Managed Process Proses ini dilembagakan sebagai proses yang dikelola. GP 2.1 Establish an Organizational Policy Membentuk dan memelihara kebijakan organisasi untuk perencanaan dan melakukan proses. GP 2.2 Plan the Process Membangun dan mempertahankan rencana untuk melakukan proses tersebut. GP 2.3 Provide Resources Menyediakan sumber daya yang memadai untuk melakukan proses, pengembangan produk kerja, dan menyediakan jasa dari proses. 1. Permintaan terdokumentasi untuk komitmen 2. Komitmen terdokumentasi Work Products / Elaboration PP Elaboration Kebijakan ini menetapkan harapan organisasi untuk memperkirakan parameter perencanaan, membuat komitmen internal dan eksternal, dan mengembangkan rencana untuk mengelola proyek.

212 196 PP Elaboration Keahlian khusus dalam perencanaan proyek dapat meliputi: A1. Estimator berpengalaman A2. Penjadwal A3. Tenaga ahli teknis di daerah yang berlaku (misalnya, domain produk, teknologi) Contoh sumber daya yang disediakan meliputi: B1. Spreadsheet programs B2. Perkiraan model GP 2.4 Assign Responsibility Menetapkan tanggung jawab dan wewenang untuk melakukan proses, pengembangan produk kerja, dan menyediakan jasa proses. B3. Perencanaan proyek dan penjadwalan paket Subpractices 1. Menetapkan tanggung jawab keseluruhan dan kewenangan untuk melakukan proses. 2. Menetapkan tanggung jawab dan wewenang untuk melakukan tugastugas khusus dari proses. GP 2.5 Train People Melatih orang yang melakukan atau mendukung proses yang diperlukan. 3. Konfirmasikan bahwa orang-orang yang ditugaskan untuk tanggung jawab dan wewenang memahami dan menerima mereka.

213 197 PP Elaboration Contoh topik pelatihan meliputi berikut ini: 1. Perkiraan 2. Penganggaran 3. Negosiasi 4. Mengidentifikasi dan menganalisis risiko 5. Mengelola Data 6. Perencanaan GP 2.6 Control Work Products Penempatan produk kerja yang dipilih dari proses di bawah tingkat yang sesuai kontrol. GP 2.7 Identify and Involve Relevant Stakeholders Mengidentifikasi dan melibatkan pemangku kepentingan yang relevan dari proses seperti yang direncanakan. 7. Penjadwalan PP Elaboration Contoh produk kerja ditempatkan di bawah kontrol meliputi berikut ini: Work breakdown structure Rencana Proyek Rencana pengelolaan data Rencana keterlibatan Stakeholder PP Elaboration Contoh kegiatan untuk keterlibatan stakeholder meliputi berikut ini: 1. Menetapkan perkiraan 2. Meninjau dan menyelesaikan masalah pada kelengkapan dan kebenaran risiko proyek 3. Meninjau rencana pengelolaan data

214 Menetapkan rencana proyek GP 2.8 Monitor and Control the Process Memantau dan mengendalikan proses terhadap rencana untuk melakukan proses dan mengambil tindakan korektif yang tepat. 5. Meninjau rencana proyek dan menyelesaikan masalah pada masalah kerja dan sumber daya PP Elaboration Contoh langkah-langkah dan produk kerja yang digunakan dalam pemantauan dan pengendalian meliputi: 1. Jumlah revisi rencana 2. Biaya, jadwal, dan variasi usaha per revisi rencana GP 2.9 Objectively Evaluate Adherence Objektif mengevaluasi kepatuhan dari proses dan produk kerja yang dipilih terhadap deskripsi proses, standar, dan prosedur, dan ketidakpatuhan. 3. Jadwal untuk pengembangan dan pemeliharaan program rencana PP Elaboration Contoh kegiatan Ulasan meliputi: Perkiraan Membangun Mengembangkan rencana proyek Mendapatkan komitmen dengan rencana proyek Contoh produk kerja terakhir adalah sebagai berikut: WBS Rencana Proyek

215 199 Rencana pengelolaan data Rencana keterlibatan stakeholder PROJECT MONITORING AND CONTROL Tujuan Pemantauan dan Pengendalian Proyek adalah untuk memberikan pemahaman tentang perkembangan proyek sehingga tindakan koreksi yang tepat dapat diambil ketika kinerja proyek menyimpang secara signifikan dari rencana. Specific Goal dan Specific Practice SG 1 Monitor the Project Against the Plan Kemajuan proyek aktual dan kinerja yang dipantau terhadap rencana proyek. SP 1.1 Monitor Project Planning Parameters Memantau nilai yang sebenarnya dari parameter perencanaan proyek terhadap rencana proyek. SP 1.2 Monitor Commitments Memantau komitmen terhadap yang diidentifikasi dalam rencana proyek. SP 1.3 Monitor Project Risks Memantau risiko terhadap yang diidentifikasi dalam rencana proyek. SP 1.4 Monitor Data Management Memantau pengelolaan data proyek terhadap rencana proyek. SP 1.5 Monitor Stakeholder Involvement Memantau keterlibatan stakeholder terhadap rencana proyek. SP 1.6 Conduct Progress Reviews Tinjauan berkala kemajuan proyek, kinerja, dan masalah. SP 1.7 Conduct Milestone Reviews Tinjau prestasi proyek dan hasil di milestone proyek yang ditentukan. SG 2 Manage Corrective Action to Closure Work Products 1. Rekaman kinerja proyek 2. Rekaman penyimpangan yang signifikan 3. Laporan kinerja biaya Rekaman kaji komitmen Rekaman pemantauan risiko proyek Rekaman manajemen data Rekaman keterlibatan stakeholder Hasil peninjauan proyek didokumentasikan Dokumentasi hasil review per milestone

216 200 Tindakan korektif yang berhasil untuk penyelesaian ketika kinerja proyek atau hasil menyimpang secara signifikan dari rencana. SP 2.1 Analyze Issues Mengumpulkan dan menganalisa masalah dan menentukan tindakan korektif untuk mengatasinya. SP 2.2 Take Corrective Action Mengambil tindakan korektif terhadap permasalahan yang diidentifikasi. SP 2.3 Manage Corrective Actions Mengelola tindakan korektif untuk penutupan. Generic Goal dan Generic Practice GG 1 Achieve Specific Goals Specific goals dari area proses didukung proses perubahan input work products yang teridentifikasi ke output work products yang teridentifikasi. GP 1.1 Perform Specific Practices Melakukan specific practices dari area proses untuk mengembangkan produk kerja dan memberikan pelayanan untuk mencapai specific goals dari area proses. GG 2 Institutionalize a Managed Process Proses ini dilembagakan sebagai proses yang dikelola. GP 2.1 Establish an Organizational Policy Membentuk dan memelihara kebijakan organisasi untuk perencanaan dan melakukan proses. Daftar masalah yang memerlukan tindakan korektif Rencana aksi korektif Hasil Tindakan korektif Work Products / Elaboration PMC Elaboration Kebijakan ini menetapkan harapan organisasi untuk memantau kemajuan proyek dan kinerja terhadap rencana proyek dan mengelola tindakan korektif untuk penutupan ketika aktual atau hasil menyimpang secara signifikan dari rencana.

217 201 GP 2.2 Plan the Process Membangun dan mempertahankan rencana untuk melakukan proses tersebut. GP 2.3 Provide Resources Menyediakan sumber daya yang memadai untuk melakukan proses, pengembangan produk kerja, dan menyediakan jasa dari proses. PMC Elaboration Rencana ini untuk melakukan proses pemantauan dan pengendalian proyek dapat menjadi bagian dari (atau direferensikan oleh) rencana proyek, seperti yang dijelaskan dalam area proses Project Planning. PMC Elaboration Contoh sumber daya yang disediakan meliputi: 1. Sistem pelacakan biaya 2. Sistem pelaporan usaha 3. Sistem pelacakan tindakan GP 2.4 Assign Responsibility Menetapkan tanggung jawab dan wewenang untuk melakukan proses, pengembangan produk kerja, dan menyediakan jasa proses. 4. Program manajemen proyek dan penjadwalan Subpractices 1. Menetapkan tanggung jawab keseluruhan dan kewenangan untuk melakukan proses. 2. Menetapkan tanggung jawab dan wewenang untuk melakukan tugastugas khusus dari proses. 3. Konfirmasikan bahwa orang-orang yang ditugaskan untuk tanggung jawab dan wewenang memahami dan menerima mereka.

218 202 GP 2.5 Train People Melatih orang yang melakukan atau mendukung proses yang diperlukan. PMC Elaboration Contoh topik pelatihan meliputi berikut ini: 1. Pemantauan dan pengendalian proyek 2. Manajemen risiko GP 2.6 Control Work Products Penempatan produk kerja yang dipilih dari proses di bawah tingkat yang sesuai kontrol. 3. Manajemen data PMC Elaboration Contoh produk kerja ditempatkan di bawah kontrol meliputi berikut ini: 1. Jadwal proyek dengan statusnya 2. Data pengukuran proyek dan analisis GP 2.7 Identify and Involve Relevant Stakeholders Mengidentifikasi dan melibatkan pemangku kepentingan yang relevan dari proses seperti yang direncanakan. 3. Laporan nilai yang diperoleh PMC Elaboration Contoh kegiatan untuk keterlibatan stakeholder meliputi berikut ini: 1. Menilai proyek terhadap rencana 2. Meninjau komitmen dan menyelesaikan masalah 3. Meninjau risiko proyek 4. Meninjau kegiatan pengelolaan data

219 Meninjau kemajuan proyek 6. Mengelola tindakan korektif untuk penutupan GP 2.8 Monitor and Control the Process Memantau dan mengendalikan proses terhadap rencana untuk melakukan proses dan mengambil tindakan korektif yang tepat. PMC Elaboration Contoh langkah-langkah dan produk kerja yang digunakan dalam pemantauan dan pengendalian meliputi: 1. Jumlah tindakan korektif terbuka dan tertutup 2. Jadwal dengan status pengumpulan bulanan data keuangan, analisis, dan pelaporan 3. Jumlah dan jenis ulasan yang dilakukan 4. Jadwal Ulasan (direncanakan dibandingkan aktual dan keluar tanggal target) GP 2.9 Objectively Evaluate Adherence Objektif mengevaluasi kepatuhan dari proses dan produk kerja yang dipilih terhadap deskripsi proses, standar, dan prosedur, dan ketidakpatuhan. 5. Jadwal pengumpulan dan analisis data pemantauan

220 204 PMC Elaboration Contoh kegiatan ulasan meliputi: A1. Pemantauan kemajuan proyek dan kinerja terhadap rencana proyek A2. Mengelola tindakan korektif untuk penutupan Contoh produk kerja terakhir adalah sebagai berikut: B1. Rekaman kemajuan proyek dan kinerja B2. Peninjauan proyek hasil SUPPLIER AGREEMENT MANAGEMENT Tujuan Manajemen Perjanjian Pemasok adalah untuk mengelola akuisisi produk dan jasa dari pemasok. Specific Goal dan Specific Practice SG 1 Establish Supplier Agreements Perjanjian dengan pemasok ditetapkan dan dipelihara. SP 1.1 Determine Acquisition Type Tentukan jenis akuisisi untuk setiap produk atau komponen produk yang akan dibeli. SP 1.2 Select Suppliers Memilih pemasok berdasarkan evaluasi dari kemampuan mereka untuk memenuhi kebutuhan yang ditentukan dan kriteria yang telah ditetapkan. SP 1.3 Establish Supplier Agreements Membangun dan memelihara perjanjian dengan pemasok. Work Products Daftar jenis akuisisi yang akan digunakan untuk semua produk dan komponen produk yang akan dibeli 1. Studi pasar 2. Daftar calon pemasok 3. Daftar pemasok pilihan 4. Studi perdagangan atau catatan lain dari kriteria evaluasi, keuntungan dan kerugian dari pemasok calon, dan dasar pemikiran untuk pemilihan pemasok 5. Bahan permintaan dan kebutuhan 1. Laporan kerja 2. kontrak 3. Nota kesepakatan 4. Perjanjian lisensi

221 205 SG 2 Satisfy Supplier Agreements Perjanjian dengan pemasok dipenuhi oleh kedua proyek dan pemasok. SP 2.1 Execute the Supplier Agreement Kegiatan dengan pemasok sebagaimana ditentukan dalam perjanjian pemasok. SP 2.2 Accept the Acquired Product Memastikan bahwa perjanjian pemasok puas sebelum menerima produk yang diperoleh. SP 2.3 Ensure Transition of Products Memastikan transisi dari produk yang diperoleh dari pemasok. Generic Goal dan Generic Practice GG 1 Achieve Specific Goals Specific goals dari area proses didukung proses perubahan input work products yang teridentifikasi ke output work products yang teridentifikasi. GP 1.1 Perform Specific Practices Melakukan specific practices dari area proses untuk mengembangkan produk kerja dan memberikan pelayanan untuk mencapai specific goals dari area proses. GG 2 Institutionalize a Managed Process Proses ini dilembagakan sebagai proses yang dikelola. GP 2.1 Establish an Organizational Policy Membentuk dan memelihara kebijakan organisasi untuk perencanaan dan melakukan proses. 1. Laporan kemajuan pemasok dan ukuran kinerja 2. Bahan tinjauan pemasok dan laporan 3. Item tindakan yang terlacak untuk penyelesaian 4. Produk dan dokumentasi 1. Prosedur penerimaan 2. Ulasan penerimaan atau hasil tes 3. Kesenjangan laporan atau rencana tindakan korektif 1. Rencana transisi 2. Laporan pelatihan 3. Dukungan dan pemeliharaan laporan Work Products / Elaboration

222 206 GP 2.2 Plan the Process Membangun dan mempertahankan rencana untuk melakukan proses tersebut. GP 2.3 Provide Resources Menyediakan sumber daya yang memadai untuk melakukan proses, pengembangan produk kerja, dan menyediakan jasa dari proses. SAM Elaboration Kebijakan ini menetapkan harapan organisasi untuk membangun, memelihara, dan memuaskan perjanjian dengan pemasok. SAM Elaboration Bagian-bagian dari rencana ini untuk melakukan proses manajemen perjanjian pemasok dapat menjadi bagian dari (atau direferensikan oleh) rencana proyek seperti yang dijelaskan dalam area proses Project Planning. Beberapa bagian dari rencana berada di luar proyek dengan kelompok seperti kontrak manajemen. SAM Elaboration Contoh sumber daya yang disediakan meliputi: 1. Daftar pemasok yang dipilih GP 2.4 Assign Responsibility Menetapkan tanggung jawab dan wewenang untuk melakukan proses, pengembangan produk kerja, dan menyediakan jasa proses. 2. Alat pelacakan kebutuhan 3. Program manajemen proyek dan penjadwalan

223 207 Subpractices 1. Menetapkan tanggung jawab keseluruhan dan kewenangan untuk melakukan proses. 2. Menetapkan tanggung jawab dan wewenang untuk melakukan tugastugas khusus dari proses. GP 2.5 Train People Melatih orang yang melakukan atau mendukung proses yang diperlukan. 3. Konfirmasikan bahwa orang-orang yang ditugaskan untuk tanggung jawab dan wewenang memahami dan menerima mereka. SAM Elaboration Contoh topik pelatihan meliputi berikut ini: - Peraturan dan praktek bisnis yang berkaitan dengan negosiasi dan bekerja dengan pemasok - Perencanaan dan persiapan Akuisisi - Commercial off-the-shelf produk akuisisi - Evaluasi Pemasok dan seleksi - Negosiasi dan resolusi konflik - Manajemen Pemasok - Pengujian dan transisi dari produk yang diperoleh GP 2.6 Control Work Products Penempatan produk kerja yang dipilih dari proses di bawah tingkat yang sesuai kontrol. - Menerima, menyimpan, menggunakan, dan memelihara produk yang diperoleh

224 208 SAM Elaboration Contoh produk kerja ditempatkan di bawah kontrol meliputi berikut ini: - Laporan kerja - Perjanjian Pemasok - Nota kesepakatan - Subkontrak GP 2.7 Identify and Involve Relevant Stakeholders Mengidentifikasi dan melibatkan pemangku kepentingan yang relevan dari proses seperti yang direncanakan. - Daftar pemasok yang diutamakan SAM Elaboration Contoh kegiatan untuk keterlibatan stakeholder meliputi berikut ini: - Menetapkan kriteria untuk evaluasi pemasok potensial - Meninjau pemasok potensial - Perjanjian dengan pemasok membangun - Menyelesaikan masalah dengan pemasok GP 2.8 Monitor and Control the Process Memantau dan mengendalikan proses terhadap rencana untuk melakukan proses dan mengambil tindakan korektif yang tepat. - Meninjau kinerja pemasok

225 209 SAM Elaboration Contoh langkah-langkah dan produk kerja yang digunakan dalam pemantauan dan pengendalian meliputi: - Jumlah perubahan yang dibuat untuk persyaratan untuk pemasok - Biaya dan varians jadwal sesuai dengan perjanjian pemasok GP 2.9 Objectively Evaluate Adherence Objektif mengevaluasi kepatuhan dari proses dan produk kerja yang dipilih terhadap deskripsi proses, standar, dan prosedur, dan ketidakpatuhan. - Jadwal untuk memilih pemasok dan membangun kesepakatan SAM Elaboration Contoh kegiatan Ulasan meliputi: - Membentuk dan memelihara perjanjian pemasok - Memuaskan perjanjian pemasok Contoh produk kerja terakhir adalah sebagai berikut: - Rencana manajemen perjanjian pemasok - Perjanjian Pemasok

226 210 Lampiran 4 : Rancangan Penilaian Kapasitas Penyedia

227 211 RANCANGAN PENILAIAN KAPASITAS PENYEDIA 1. Penilaian Kapasitas Penyedia Penilaian kapasitas penyedia merupakan penilaian yang dilakukan kepada penyedia atau peserta lelang jasa konsultansi perangkat lunak atau lelang untuk pengadaan paket pembangunan/pengembangan perangkat lunak. Penilaian kapasitas penyedia dilakukan untuk mengetahui kapasitas atau kemampuan dari peserta lelang dalam menjalankan proses pengembangan perangkat lunak dengan menilai hasil proses tersebut yang berupa work product. Perancangan penilaian kapasitas penyedia mengadopsi Capability Maturity Model Integration for Development (CMMI-DEV) V dan Standard CMMI Appraisal Method for Process Improvement (SCAMPI) C 2. Penilaian ini berfokus pada area proses Requirements Management, Project Planning, dan Project Monitoring and Control. Penilaian kapasitas penyedia digunakan untuk lelang yang bernilai diatas Rp ,- dengan penilaian kualifikasi lelang melalui prakualifikasi. 2. Panitia Panitia adalah panitia/pejabat yang ditetapkan oleh pejabat pengguna anggaran atau pejabat kuasa anggaran yang bertugas memeriksa dan menerima hasil pekerjaan. 3. Penilai Teknis Penilai teknis adalah pejabat/pegawai yang ditetapkan oleh pejabat pengguna anggaran atau pejabat kuasa anggaran yang bertugas membantu panitia dalam menilai kapasitas penyedia dan pemeriksaan dokumen teknis. Syarat minimal pendidikan penilai adalah S2 Magister Teknologi Informasi. 1 CMMI Product Team, Software Engineering Institute, Carnegie Mellon University (2010), CMMI FOR Development, Version 1.3: Improving process for developing better products and services, Carnegie Mellon Software Engineering Institute. 2 Will Hayes, W., Miluk, G., Ming, L., dan Glover, M. (2005). Handbook for Conducting Standard CMMI Appraisal Method for Process Improvement (SCAMPI) B and C Appraisals, Version 1.1, Carnegie Mellon Software Engineering Institute.

228 Peserta Peserta adalah penyedia barang/jasa yang telah lulus tahap prakualifikasi atau yang masuk dalam daftar pendek peserta lelang. 5. Waktu dan Tempat Tempat penilaian dilakukan dikantor instansi terkait dari panitia. Waktu penilaian kapasitas dilakukan sebelum penilaian dokumen penawaran teknis dan dokumen penawaran harga. Waktu penilaian kapasitas ditentukan oleh panitia, disesuaikan dengan jadwal penilaian dokumen penawaran teknis pada jadwal proses lelang. Panitia memberikan undangan resmi terkait penilaian kapasitas penyedia. Peserta menentukan perwakilan peserta yang akan hadir di penilaian dalam rangka memperlihatkan dokumen yang akan dinilai dan memberikan penjelasan tambahan apabila diperlukan. 6. Paket Dokumen Kapasitas Paket dokumen kapasitas merupakan dokumen-dokumen yang berkaitan dengan manajemen pada suatu proyek dari peserta lelang yang akan dinilai, dokumen ini dapat berupa dokumen proyek yang pernah dilakukan atau dapat berupa template dokumen yang akan digunakan pada pelaksanaan proyek. Dokumen yang disiapkan adalah dokumen yang terkait dengan area-area proses dibawah ini:

229 213 Tabel Requirements Management Requirements Management (Manajemen Kebutuhan), tujuannya adalah untuk mengelola kebutuhan produk proyek dan komponen produk, serta untuk memastikan keselarasan antara kebutuhan, rencana proyek, dan produk kerja. Kode Tujuan / Keterangan Tujuan/Praktek Praktek Spesifik TS 1 Tujuan Praktek: Mengelola Kebutuhan Kebutuhan dikelola dan dihubungkan dengan rencana proyek dan produk kerja yang sudah diidentifikasi. PS 1.1 Nama Praktek: Memahami Kebutuhan Penilaian pada praktek ini untuk mengetahui pemahaman penyedia terhadap kebutuhan dari pengguna. Praktek ini dapat dilihat pada dokumen penawaran teknis pada bagian pemahaman atas jasa layanan yang tercantum dalam Kerangka Acuan Kerja (KAK). Dokumen yang dapat dinilai: 1. Daftar kriteria kebutuhan 2. Kriteria untuk evaluasi dan penerimaan kebutuhan 3. Hasil analisis terhadap kriteria 4. Satu set kebutuhan yang telah disetujui PS 1.2 Nilai minimal: Nilai sedang (50%), minimal terdapat 2 dokumen dari 4 yang disyaratkan, bila tidak maka nilai (0%). Nama Praktek: Mendapatkan Komitmen Kebutuhan Penilaian pada praktek ini untuk mengetahui komitmen penyedia terhadap kebutuhan proyek.

230 214 Dokumen yang dapat dinilai: 1. Penilaian dampak kebutuhan 2. Komitmen yang terdokumentasi terkait kebutuhan dan perubahan kebutuhan PS 1.3 Nilai minimal: Nilai sedang (50%), minimal terdapat 1 dokumen dari 2 yang disyaratkan, bila tidak maka nilai (0%). Nama Praktek: Mengelola Perubahan kebutuhan Penilaian pada praktek ini untuk mengetahui bagaimana penyedia mengelola perubahan kebutuhan sebagaimana mereka berevolusi selama proyek. Dokumen yang dapat dinilai: 1. Permintaan perubahan kebutuhan 2. Laporan dampak perubahan kebutuhan 3. Status kebutuhan 4. Database kebutuhan PS 1.4 Nilai minimal : tidak ada. Nama Praktek: Menjaga Bidirectional Traceability kebutuhan Penilaian praktek ini untuk mengetahui bagaimana penyedia menjaga bidirectional traceability antara kebutuhan dan produk kerja. Dokumen yang dapat dinilai: 1. Matriks penelusuran kebutuhan 2. Sistem pelacakan kebutuhan PS 1.5 Nilai minimal : tidak ada. Nama Praktek: Memastikan Keselarasan Antara Proyek Kerja dan kebutuhan Penilaian pada prektek ini untuk mengetahui bagaimana penyedia dapat memastikan bahwa rencana proyek dan produk kerja tetap selaras dengan kebutuhan.

231 215 Dokumen yang dapat dinilai: 1. Dokumentasi inkonsistensi antara kebutuhan, rencana proyek dan produk kerja, termasuk sumber dan kondisi 2. Tindakan korektif Nilai minimal : tidak ada. Tabel Project Planning Project Planning (Perencanaan Proyek) bertujuan untuk membangun dan memelihara rencana yang mendefinisikan kegiatan proyek. Kode Tujuan / Keterangan Tujuan/Praktek Praktek Spesifik TS 1 Tujuan Praktek: Menetapkan Perkiraan Memperkirakan parameter perencanaan proyek yang akan dibangun dan dipelihara. PS 1.1 Nama Praktek: Perkirakan Ruang Lingkup Proyek Penilaian praktek ini untuk mengetahui pembuatan tingkat pada work breakdown structure (WBS) untuk memperkirakan lingkup proyek. Sebagian data dari praktek ini dapat dilihat pada dokumen penawaran teknis pada bagian pemahaman atas jasa layanan yang tercantum dalam KAK, dan bagian kualitas metodologi. Dokumen yang dapat dinilai: 1. Deskripsi tugas 2. Deskripsi paket pekerjaan 3. WBS Nilai minimal: Nilai sedang (50%), minimal terdapat 2 dokumen dari 3 yang disyaratkan, bila tidak maka nilai (0%).

232 216 PS 1.2 Nama Praktek: Menetapkan Perkiraan Produk Kerja dan Atribut Tugas Penilaian praktek ini untuk mengetahui bagaimana penyedia membangun dan memelihara perkiraan produk kerja dan atribut tugas. Praktek ini dapat dilihat pada dokumen penawatan teknis pada bagian kualitas metodologi, dan bagian hasil kerja (deliverable). Dokumen yang dapat dinilai: 1. Ukuran dan kompleksitas tugas dan produk kerja 2. Memperkirakan model 3. Perkiraan atribut 4. Pendekatan Teknis PS 1.3 PS 1.4 Nilai minimal: Nilai sedang (50%), minimal terdapat 2 dokumen dari 4 yang disyaratkan, bila tidak maka nilai (0%). Nama Praktek: Menentukan Fase Siklus Hidup Proyek Penilaian praktek ini untuk mengetahui bagaimana penyedia menentukan fase siklus hidup proyek yang menjadi ruang lingkup perencanaan.praktek ini dapat dilihat pada dokumen penawatan teknis pada bagian kualitas metodologi. Dokumen yang dapat dinilai: Fase siklus hidup proyek Nilai minimal: Nilai sedang (50%), minimal terdapat dokumen disyaratkan, bila tidak maka nilai (0%). Perkiraan Usaha dan Biaya Penilaian praktek ini untuk mengetahui perkirakan usaha dan biaya untuk produk kerja dan tugas berdasarkan estimasi pemikiran proyek dari penyedia. Praktek terkait perkiraan usaha dapat dilihat pada dokumen penawatan teknis pada bagian pemahaman atas jasa layanan yang tercantum dalam KAK, bagian kualitas metodologi, bagian hasil kerja (deliverable), dan bagian gagasan baru. Sedangkan praktek terkait perkiraan biaya dapat dilihat pada dokumen penawaran biaya.

233 217 Dokumen yang dapat dinilai: 1. Estimasi pemikiran 2. Estimasi usaha proyek 3. Perkiraan biaya proyek TS 2 PS 2.1 Nilai minimal: Nilai sedang (50%), minimal terdapat 2 dokumen dari 3 yang disyaratkan, bila tidak maka nilai (0%). Tujuan: Mengembangkan Rencana Proyek Sebuah rencana proyek ditetapkan dan dipelihara sebagai dasar untuk mengelola proyek. Nama Praktek: Menetapkan Anggaran dan Jadwal Penilaian praktek ini untuk mengetahui bagaimana penyedia membangun dan memelihara anggaran proyek dan jadwal. Praktek terkait dengan jadwal dapat dilihat pada dokumen penawatan teknis pada bagian kualitas metodologi. Sedangkan praktek terkait anggaran dapat dilihat pada dokumen penawaran biaya. Dokumen yang dapat dinilai: 1. Jadwal proyek 2. Jadwal dependensi 3. Anggaran proyek PS 2.2 Nilai minimal: Nilai sedang (50%), minimal terdapat 2 dokumen dari 3 yang disyaratkan, bila tidak maka nilai (0%). Nama Praktek: Identifikasi Rsiko Proyek Penilaian praktek ini untuk mengetahui bagaimana penyedia mengidentifikasi dan menganalisis risiko proyek. Dokumen yang dapat dinilai: 1. Risiko yang teridentifikasi 2. Dampak risiko dan kemungkinan terjadinya 3. Prioritas Risiko

234 218 Nilai minimal : tidak ada. PS 2.3 Nama Praktek: Rencana Pengelolaan Data Penilaian praktek ini untuk mengetahui rencana pengelolaan data proyek dari penyedia. Dokumen yang dapat dinilai: 1. Rencana pengelolaan data 2. Daftar master data yang dikelola 3. Data content dan deskripsi format 4. Daftar kebutuhan data untuk pengakuisisi dan pemasok 5. Kebutuhan privasi 6. Kebutuhan keamanan 7. Prosedur keamanan 8. Mekanisme untuk pengambilan data, reproduksi, dan distribusi 9. Jadwal pengumpulan data proyek 10. Daftar data proyek yang akan dikumpulkan PS 2.4 Nilai minimal : tidak ada. Nama Praktek: Rencana Sumber Daya Proyek Penilaian praktek ini untuk mengetahui bagaimana penyedia menyiapkan rencana sumber daya untuk menjalankan proyek. Sebagian data dari praktek ini dapat dilihat pada dokumen penawaran teknis pada bagian kualitas metodologi, dan bagian tenaga ahli. Dokumen yang dapat dinilai: 1. Paket pekerjaan 2. Kamus pekerjaan WBS 3. Kebutuhan staf berdasarkan ukuran dan ruang lingkup proyek 4. Fasilitas kritis dan daftar peralatan 5. Definisi proses dan alur kerja, dan diagram 6. Daftar kebutuhan administrasi proyyek 7. Laporan status

235 219 PS 2.5 Nilai minimal: Nilai sedang (50%), minimal terdapat 4 dokumen dari 7 yang disyaratkan, bila tidak maka nilai (0%). Nama Praktek: Rencana Kebutuhan Pengetahuan dan Keterampilan Penilaian praktek ini untuk mengetahui rencana kebutuhan pengetahuan dan keterampilan untuk melakukan proyek dari penyedia. Sebagian data dari praktek ini dapat dilihat pada dokumen penawaran teknis pada bagian tenaga ahli. Dokumen yang dapat dinilai: 1. Inventarisasi keterampilan yang dibutuhkan 2. Staffing dan rencana karyawan baru 3. Database (mis., keterampilan, pelatihan) 4. Rencana pelatihan PS 2.6 Nilai minimal: Nilai tinggi (100%), harus terdapat 4 dokumen yang disyaratkan, bila tidak maka nilai (0%). Nama Praktek: Rencana Keterlibatan Pemangku Kepentingan Penilaian praktek ini untuk mengetahui rencana keterlibatan stakeholder yang diidentifikasi dari penyedia. Dokumen yang dapat dinilai: Rencana keterlibatan stakeholder Nilai minimal : tidak ada. PS 2.7 Nama Praktek: Menetapkan Rencana Proyek Penilaian praktek ini untuk mengetahui bagaimana penyedia membangun dan memelihara rencana proyek secara keseluruhan. Dokumen yang dapat dinilai: Rencana proyek secara keseluruhan Nilai minimal: Nilai tinggi (100%), harus terdapat dokumen dengan penjelasan yang mendukung praktek yang terkait, bila tidak maka nilai (0%).

236 220 TS 3 Tujuan: Mendapatkan Komitmen untuk Rencana Komitmen dengan rencana proyek yang ditetapkan dan dipelihara. PS 3.1 Nama Praktek: Ulasan Rencana yang Mempengaruhi Proyek Penilaian praktek ini untuk mengetahui bagaimana penyedia meninjau semua rencana yang mempengaruhi proyek untuk memahami komitmen proyek. Dokumen yang dapat dinilai: Rekaman dari tinjauan rencana yang mempengaruhi proyek PS 3.2 Nilai minimal : tidak ada. Nama Praktek: Rekonsiliasi Kerja dan Tingkat Sumberdaya Penilaian praktek ini untuk mengetahui bagaimana penyedia menyesuaikan rencana proyek untuk menyelaraskan ketersediaan dan sumber daya yang diperkirakan. Dokumen yang dapat dinilai: 1. Metode Revisi dan parameter estimasi yang sesuai (misalnya, alat yang lebih baik) 2. Renegosiasi anggaran 3. Revisi jadwal 4. Daftar revisi kebutuhan 5. Negosiasi ulang perjanjian dengan pemangku kepentingan PS 3.3 Nilai minimal : tidak ada. Nama Praktek: Mendapatkan Komitmen Rencana Penilaian praktek ini untuk mengetahui bagaimana komitmen dapat terbangun antara penyedia denganpemangku kepentingan terkait yang bertanggung jawab untuk melakukan dan mendukung pelaksanaan rencana. Dokumen yang dapat dinilai: 1. Permintaan terdokumentasi untuk komitmen 2. Komitmen terdokumentasi

237 221 Nilai minimal : tidak ada. Tabel Project Planning Project Monitoring and Control (Pemantauan dan Pengendalian Proyek) memilki tujuan untuk memberikan pemahaman tentang perkembangan proyek sehingga tindakan koreksi yang tepat dapat diambil ketika kinerja proyek menyimpang secara signifikan dari rencana. Kode Tujuan / Keterangan Tujuan/Praktek Praktek Spesifik TS 1 Tujuan Praktek: Memantau Proyek Terhadap Rencana Kemajuan proyek aktual dan kinerja yang dipantau terhadap rencana proyek. PS 1.1 Nama Praktek: Memantau Parameter Perencanaan Proyek Penilaian praktek ini untuk mengetahui bagaimana penyedia memantau hasil dari parameter perencanaan proyek terhadap rencana proyek. Dokumen yang dapat dinilai: 1. Rekaman kinerja proyek 2. Rekaman penyimpangan yang signifikan 3. Laporan kinerja biaya PS 1.2 Nilai minimal: Nilai sedang (50%), minimal terdapat 2 dokumen dari 3 yang disyaratkan, bila tidak maka nilai (0%). Nama Praktek: Memantau Komitmen Penilaian praktek ini untuk mengetahui bagaimana penyedia memantau komitmen yang masuk dalam rencana proyek. Dokumen yang dapat dinilai: Rekaman tinjauan komitmen Nilai minimal: Nilai sedang (50%), minimal terdapat dokumen yang

238 222 PS 1.3 disyaratkan, bila tidak maka nilai (0%). Nama Praktek: Memantau Risiko Proyek Penilaian praktek ini untuk mengetahui bagaimana penyedia memantau risiko teridentifikasi rencana proyek. Dokumen yang dapat dinilai: Rekaman pemantauan risiko proyek PS 1.4 Nilai minimal : tidak ada. Nama Praktek: Memantau Manajemen Data Penilaian praktek ini untuk mengetahui bagaimana penyedia memantau pengelolaan data proyek terhadap rencana proyek. Dokumen yang dapat dinilai: Rekaman manajemen data PS 1.5 Nilai minimal: Nilai sedang (50%), minimal terdapat dokumen yang disyaratkan, bila tidak maka nilai (0%). Nama Praktek: Memantau Keterlibatan Pemangku Kepentingan Penilaian praktek ini untuk mengetahui bagaimana penyedia memantau keterlibatan stakeholder terhadap rencana proyek. Dokumen yang dapat dinilai: Rekaman keterlibatan stakeholder PS 1.6 Nilai minimal : tidak ada. Nama Praktek: Tinjauan Kemajuan Penilaian praktek ini untuk mengetahui bagaimana penyedia melakukan tinjauan berkala kemajuan proyek, kinerja, dan masalah. Dokumen yang dapat dinilai: Hasil peninjauan proyek didokumentasikan Nilai minimal: Nilai sedang (50%), minimal terdapat dokumen yang disyaratkan, bila tidak maka nilai (0%).

239 223 PS 1.7 Nama Praktek: Tinjauan Milestone Penilaian praktek ini untuk mengetahui bagaimana penyedia meninjau prestasi proyek dan hasil di milestone proyek yang ditentukan. Dokumen yang dapat dinilai: Dokumentasi hasil review per milestone TS 2 PS 2.1 Nilai minimal: Nilai sedang (50%), minimal terdapat dokumen yang disyaratkan, bila tidak maka nilai (0%). Tujuan: Mengelola Tindakan Korektif untuk Penutupan Tindakan korektif yang berhasil untuk penyelesaian ketika kinerja proyek atau hasil menyimpang secara signifikan dari rencana. Nama Praktek: Menganalisis Masalah Penilaian praktek ini untuk mengetahui bagaimana penyedia mengumpulkan dan menganalisa masalah dan menentukan tindakan korektif untuk mengatasinya. Dokumen yang dapat dinilai: Daftar masalah yang memerlukan tindakan korektif PS 2.2 Nilai minimal : tidak ada. Nama Praktek: Pengambilan Tindakan Perbaikan Penilaian praktek ini untuk mengetahui bagaimana penyedia mengambil tindakan korektif terhadap permasalahan yang diidentifikasi. Dokumen yang dapat dinilai: Rencana aksi korektif PS 2.3 Nilai minimal: Nilai sedang (50%), minimal terdapat dokumen yang disyaratkan, bila tidak maka nilai (0%). Nama Praktek: Kelola Tindakan korektif Penilaian praktek ini untuk mengetahui bagaimana penyedia mengelola tindakan korektif untuk menyelesaikan proyek. Dokumen yang dapat dinilai:

240 224 Hasil Tindakan korektif Nilai minimal: Nilai sedang (50%), minimal terdapat dokumen yang disyaratkan, bila tidak maka nilai (0%). 7. Penilaian Penilaian dilakukan dengan memeriksa dokumen yang disyaratkan dalam dinilai. Dokumen yang dimaksud dapat berupa file softcopy, dokumen hardcopy, produk, bagian dari produk, aplikasi/web aplikasi layanan, deskripsi proses, spesifikasi, dan invoices. Dokumen dapat diberi nilai apabila dokumen sesuai dengan praktek dimaksud. 8. Pengisian Formulir Penilaian Kapasitas Penyedia Panitia mengisi formulir penilaian kapasitas penyedia sesuai hasil dokumen yang dapat dinilai. Nilai pada formulir diisi sesuai syarat nilai yang ada pada formulir. Nilai diisi dengan rendah/sedang/tinggi. 9. Pengisian Formulir Rangkuman Penilaian Kapasitas Penyedia Hasil pengisian formulir penilaian kapasitas dipindahkan ke formulir rangkuman penilaian penyedia pada masing-masing praktek dari area proses. Keterangan pengisian tabel Requirements Managemen, Project Planning, dan Project Monitoring and Control: - Kolom 3 (Skala Nilai) diisi dengan rendah/sedang/tinggi hasil dari formulir penilaian kapasitas penyedia. - Kolom 4 (Persentase Skala Nilai) merupakan konversi nilai dari kolom 3, dengan ketentuan : o Rendah = 0% o Sedang = 50% o Tinggi = 100% - Kolom 5 (Bobot Praktek) merupakan bobot praktek yang telah ditentukan panita dan/atau penilai teknis.

241 225 - Kolom 6 (Nilai Praktek) merupakan hasil perkalian dari kolom 4 dan kolom 5. - Nilai Area Proses merupakan penjumlahan dari semua nilai praktek. Setelah melakukan pengisian nilai pada tabel area proses, dilanjutkan mengisi tabel jumlah keseluruhan. Berikut tata cara pengisian tabel jumlah keseluruhan: - Kolom 2 (Bobot Area Proses) merupakan bobot area proses yang telah ditentukan panita dan/atau penilai teknis. - Kolom 3 (Nilai Area Proses) merupakan nilai area proses dari tabel area proses terkait. - Kolom 4 (Nilai Bobot Area Proses) merupakan hasil perkalian dari kolom 2 dan kolom 3. - Total nilai merupakan penjumlahan dari nilai bobot area proses. Total nilai akan menjadi nilai akhir dari penilaian kapasitas penyedia yang selanjutnya masuk ke dalam evaluasi teknis, dimana nilai akhir penilaian kapasitas penyedia menjadi sub unsur penilaian terhadap Pendekatan dan Metodologi. Penilaian terhadap Pendekatan dan Metodologi memiliki sub unsur penilaian yang terdiri dari sub unsur pemahaman atas jasa layanan yang tercantum dalam KAK, kualitas metodologi, hasil kerja (deliverable), gagasan baru, dan akan ditambah sub unsur penilaian kapasitas penyedia. Hasil dari penilaian kapasitas penyedia bukan saja menghasilkan nilai yang dimasukkan ke dalam evaluasi teknis, tapi dapat juga digunakan sebagai prediksi nilai Capability Level CMMI-DEV dari penyedia. Penilaian ini berfokus pada pencapaian Capability Level 1 (performed), yang dapat diketahui apabila peserta dapat memenuhi praktek-praktek pada area proses dengan nilai tinggi semua. Apabila ada praktek yang belum dapat dipenuhi dengan nilai tinggi, diprediksi peserta tersebut masih berada pada Capability Level 0 (incomplete).

242 226 Lampiran 5 : Rancangan Formulir Penilaian Kapasitas Penyedia

243 227 Rancangan Formulir Penilaian Kapasitas Penyedia Nama Perusahaan Tim Penilai Nama Proyek Sumber data Tanggal Pukul Tempat

244 228 Requirements Management (Manajemen Kebutuhan), tujuannya adalah untuk mengelola kebutuhan produk proyek dan komponen produk, serta untuk memastikan keselarasan antara kebutuhan, rencana proyek, dan produk kerja. Kode Tujuan / Praktek Spesifik TS 1 PS 1.1 Keterangan Tujuan Praktek: Mengelola Kebutuhan Kebutuhan dikelola dan dihubungkan dengan rencana proyek dan produk kerja yang sudah diidentifikasi. Nama Praktek: Memahami Kebutuhan Penilaian pada praktek ini untuk mengetahui pemahaman penyedia terhadap kebutuhan dari pengguna. Praktek ini dapat dilihat pada dokumen penawaran teknis pada bagian pemahaman atas jasa layanan yang tercantum dalam Kerangka Acuan Kerja (KAK). Dokumen yang dapat dinilai: 1. Daftar kriteria kebutuhan 2. Kriteria untuk evaluasi dan penerimaan kebutuhan 3. Hasil analisis terhadap kriteria 4. Satu set kebutuhan yang telah disetujui Nilai minimal: Nilai sedang (50%), minimal terdapat 2 dokumen dari 4 yang disyaratkan, bila tidak maka nilai (0%). Bobot nilai : 40 Mekanisme penilaian: - Nilai rendah (0%) apabila dokumen berjumlah dibawah 2 dari 4 yang disyaratkan. - Nilai sedang (50%) apabila dokumen berjumlah dibawah 4 atau minimal 2 dari 4 yang disyaratkan. - Nilai tinggi (100%) apabila dokumen berjumlah 4 dari 4 yang disyaratkan. - Dokumen yang dapat dinilai adalah dokumen yang dapat memenuhi atau memberikan penjelasan yang sesuai dengan praktek terkait. Nilai :

245 229 PS 1.2 Nama Praktek: Mendapatkan Komitmen Kebutuhan Penilaian pada praktek ini untuk mengetahui komitmen penyedia terhadap kebutuhan proyek. Dokumen yang dapat dinilai: 1. Penilaian dampak kebutuhan 2. Komitmen yang terdokumentasi terkait kebutuhan dan perubahan kebutuhan Nilai minimal: Nilai sedang (50%), minimal terdapat 1 dokumen dari 2 yang disyaratkan, bila tidak maka nilai (0%). Bobot nilai : 15 Mekanisme penilaian: - Nilai rendah (0%) apabila tidak ada dokumen yang disyaratkan. - Nilai sedang (50%) apabila ada 1 dokumen dari 2 yang disyaratkan. - Nilai tinggi (100%) apabila ada 2 dokumen dari 2 yang disyaratkan. - Dokumen yang dapat dinilai adalah dokumen yang dapat memenuhi atau memberikan penjelasan yang sesuai dengan praktek terkait. Nilai : PS 1.3 Nama Praktek: Mengelola Perubahan kebutuhan Penilaian pada praktek ini untuk mengetahui bagaimana penyedia mengelola perubahan kebutuhan sebagaimana mereka berevolusi selama proyek. Dokumen yang dapat dinilai: 1. Permintaan perubahan kebutuhan 2. Laporan dampak perubahan kebutuhan 3. Status kebutuhan 4. Database kebutuhan Nilai minimal : tidak ada. Bobot nilai : 15 Mekanisme penilaian: - Nilai rendah (0%) apabila dokumen berjumlah dibawah 2 dari 4 yang disyaratkan. - Nilai sedang (50%) apabila dokumen berjumlah dibawah 4 atau minimal 2 dari 4 yang disyaratkan. - Nilai tinggi (100%) apabila dokumen berjumlah 4 dari 4 yang disyaratkan. - Dokumen yang dapat dinilai adalah dokumen yang dapat memenuhi atau memberikan penjelasan yang sesuai dengan

246 230 praktek terkait. Nilai : PS 1.4 Nama Praktek: Menjaga Bidirectional Traceability kebutuhan Penilaian praktek ini untuk mengetahui bagaimana penyedia menjaga bidirectional traceability antara kebutuhan dan produk kerja. Dokumen yang dapat dinilai: 1. Matriks penelusuran kebutuhan 2. Sistem pelacakan kebutuhan Nilai minimal : tidak ada. Bobot nilai : 15 Mekanisme penilaian: - Nilai rendah (0%) apabila tidak ada dokumen yang disyaratkan. - Nilai sedang (50%) apabila ada 1 dokumen dari 2 yang disyaratkan. - Nilai tinggi (100%) apabila ada 2 dokumen dari 2 yang disyaratkan. - Dokumen yang dapat dinilai adalah dokumen yang dapat memenuhi atau memberikan penjelasan yang sesuai dengan praktek terkait. Nilai : PS 1.5 Nama Praktek: Memastikan Keselarasan Antara Proyek Kerja dan kebutuhan Penilaian pada prektek ini untuk mengetahui bagaimana penyedia dapat memastikan bahwa rencana proyek dan produk kerja tetap selaras dengan kebutuhan. Dokumen yang dapat dinilai: 1. Dokumentasi inkonsistensi antara kebutuhan, rencana proyek dan produk kerja, termasuk sumber dan kondisi 2. Tindakan korektif Nilai minimal : tidak ada. Bobot nilai : 15 Mekanisme penilaian: - Nilai rendah (0%) apabila tidak ada dokumen yang disyaratkan. - Nilai sedang (50%) apabila ada 1 dokumen dari 2 yang disyaratkan. - Nilai tinggi (100%) apabila ada 2 dokumen dari 2 yang disyaratkan. - Dokumen yang dapat dinilai adalah dokumen yang dapat

247 231 memenuhi atau memberikan penjelasan yang sesuai dengan praktek terkait. Nilai : Project Planning (Perencanaan Proyek) bertujuan untuk membangun dan memelihara rencana yang mendefinisikan kegiatan proyek. Kode Tujuan / Praktek Spesifik TS 1 PS 1.1 Keterangan Tujuan Praktek: Menetapkan Perkiraan Memperkirakan parameter perencanaan proyek yang akan dibangun dan dipelihara. Nama Praktek: Perkirakan Ruang Lingkup Proyek Penilaian praktek ini untuk mengetahui pembuatan tingkat pada work breakdown structure (WBS) untuk memperkirakan lingkup proyek. Sebagian data dari praktek ini dapat dilihat pada dokumen penawaran teknis pada bagian pemahaman atas jasa layanan yang tercantum dalam KAK, dan bagian kualitas metodologi. Dokumen yang dapat dinilai: 1. Deskripsi tugas 2. Deskripsi paket pekerjaan 3. WBS Nilai minimal: Nilai sedang (50%), minimal terdapat 2 dokumen dari 3 yang disyaratkan, bila tidak maka nilai (0%). Bobot nilai : 8 Mekanisme penilaian: - Nilai rendah (0%) apabila dokumen berjumlah dibawah 2 dari 3 yang disyaratkan. - Nilai sedang (50%) apabila dokumen berjumlah dibawah 3 atau minimal 2 dari 3 yang disyaratkan. - Nilai tinggi (100%) apabila dokumen berjumlah 3 dari 3 yang disyaratkan. - Dokumen yang dapat dinilai adalah dokumen yang dapat memenuhi atau memberikan penjelasan yang sesuai dengan praktek terkait. Nilai :

248 232 PS 1.2 Nama Praktek: Menetapkan Perkiraan Produk Kerja dan Atribut Tugas Penilaian praktek ini untuk mengetahui bagaimana penyedia membangun dan memelihara perkiraan produk kerja dan atribut tugas. Praktek ini dapat dilihat pada dokumen penawatan teknis pada bagian kualitas metodologi, dan bagian hasil kerja (deliverable). Dokumen yang dapat dinilai: 1. Ukuran dan kompleksitas tugas dan produk kerja 2. Memperkirakan model 3. Perkiraan atribut 4. Pendekatan Teknis Nilai minimal: Nilai sedang (50%), minimal terdapat 2 dokumen dari 4 yang disyaratkan, bila tidak maka nilai (0%). Bobot nilai : 8 Mekanisme penilaian: - Nilai rendah (0%) apabila dokumen berjumlah dibawah 2 dari 4 yang disyaratkan. - Nilai sedang (50%) apabila dokumen berjumlah dibawah 4 atau minimal 2 dari 4 yang disyaratkan. - Nilai tinggi (100%) apabila dokumen berjumlah 4 dari 4 yang disyaratkan. - Dokumen yang dapat dinilai adalah dokumen yang dapat memenuhi atau memberikan penjelasan yang sesuai dengan praktek terkait. Nilai : PS 1.3 Nama Praktek: Menentukan Fase Siklus Hidup Proyek Penilaian praktek ini untuk mengetahui bagaimana penyedia menentukan fase siklus hidup proyek yang menjadi ruang lingkup perencanaan.praktek ini dapat dilihat pada dokumen penawatan teknis pada bagian kualitas metodologi. Dokumen yang dapat dinilai: Fase siklus hidup proyek Nilai minimal: Nilai sedang (50%), minimal terdapat dokumen disyaratkan, bila tidak maka nilai (0%). Bobot nilai : 8 Mekanisme penilaian: - Nilai rendah (0%) apabila tidak ada dokumen yang disyaratkan. - Nilai sedang (50%) apabila terdapat dalam dokumen tapi tidak ada penjelasan yang mendukung maksud praktek.

249 233 - Nilai tinggi (100%) apabila terdapat dalam dokumen dan ada penjelasan yang mendukung maksud praktek. - Dokumen yang dapat dinilai adalah dokumen yang dapat memenuhi atau memberikan penjelasan yang sesuai dengan praktek terkait. Nilai : PS 1.4 Perkiraan Usaha dan Biaya Penilaian praktek ini untuk mengetahui perkirakan usaha dan biaya untuk produk kerja dan tugas berdasarkan estimasi pemikiran proyek dari penyedia. Praktek terkait perkiraan usaha dapat dilihat pada dokumen penawatan teknis pada bagian pemahaman atas jasa layanan yang tercantum dalam KAK, bagian kualitas metodologi, bagian hasil kerja (deliverable), dan bagian gagasan baru. Sedangkan praktek terkait perkiraan biaya dapat dilihat pada dokumen penawaran biaya. Dokumen yang dapat dinilai: 1. Estimasi pemikiran 2. Estimasi usaha proyek 3. Perkiraan biaya proyek Nilai minimal: Nilai sedang (50%), minimal terdapat 2 dokumen dari 3 yang disyaratkan, bila tidak maka nilai (0%). Bobot nilai : 8 Mekanisme penilaian: - Nilai rendah (0%) apabila dokumen berjumlah dibawah 2 dari 3 yang disyaratkan. - Nilai sedang (50%) apabila dokumen berjumlah dibawah 3 atau minimal 2 dari 3 yang disyaratkan. - Nilai tinggi (100%) apabila dokumen berjumlah 3 dari 3 yang disyaratkan. - Dokumen yang dapat dinilai adalah dokumen yang dapat memenuhi atau memberikan penjelasan yang sesuai dengan praktek terkait. Nilai :

250 234 TS 2 PS 2.1 Tujuan: Mengembangkan Rencana Proyek Sebuah rencana proyek ditetapkan dan dipelihara sebagai dasar untuk mengelola proyek. Nama Praktek: Menetapkan Anggaran dan Jadwal Penilaian praktek ini untuk mengetahui bagaimana penyedia membangun dan memelihara anggaran proyek dan jadwal. Praktek terkait dengan jadwal dapat dilihat pada dokumen penawatan teknis pada bagian kualitas metodologi. Sedangkan praktek terkait anggaran dapat dilihat pada dokumen penawaran biaya. Dokumen yang dapat dinilai: 1. Jadwal proyek 2. Jadwal dependensi 3. Anggaran proyek Nilai minimal: Nilai sedang (50%), minimal terdapat 2 dokumen dari 3 yang disyaratkan, bila tidak maka nilai (0%). Bobot nilai : 8 Mekanisme penilaian: - Nilai rendah (0%) apabila dokumen berjumlah dibawah 2 dari 3 yang disyaratkan. - Nilai sedang (50%) apabila dokumen berjumlah dibawah 3 atau minimal 2 dari 3 yang disyaratkan. - Nilai tinggi (100%) apabila dokumen berjumlah 3 dari 3 yang disyaratkan. - Dokumen yang dapat dinilai adalah dokumen yang dapat memenuhi atau memberikan penjelasan yang sesuai dengan praktek terkait. Nilai : PS 2.2 Nama Praktek: Identifikasi Rsiko Proyek Penilaian praktek ini untuk mengetahui bagaimana penyedia mengidentifikasi dan menganalisis risiko proyek. Dokumen yang dapat dinilai: 1. Risiko yang teridentifikasi 2. Dampak risiko dan kemungkinan terjadinya 3. Prioritas Risiko Nilai minimal : tidak ada. Bobot nilai : 4 Mekanisme penilaian: - Nilai rendah (0%) apabila dokumen berjumlah dibawah 2 dari 3 yang disyaratkan. - Nilai sedang (50%) apabila dokumen berjumlah dibawah 3 atau

251 235 minimal 2 dari 3 yang disyaratkan. - Nilai tinggi (100%) apabila dokumen berjumlah 3 dari 3 yang disyaratkan. - Dokumen yang dapat dinilai adalah dokumen yang dapat memenuhi atau memberikan penjelasan yang sesuai dengan praktek terkait. PS 2.3 Nilai : Nama Praktek: Rencana Pengelolaan Data Penilaian praktek ini untuk mengetahui rencana pengelolaan data proyek dari penyedia. Dokumen yang dapat dinilai: 1. Rencana pengelolaan data 2. Daftar master data yang dikelola 3. Data content dan deskripsi format 4. Daftar kebutuhan data untuk pengakuisisi dan pemasok 5. Kebutuhan privasi 6. Kebutuhan keamanan 7. Prosedur keamanan 8. Mekanisme untuk pengambilan data, reproduksi, dan distribusi 9. Jadwal pengumpulan data proyek 10. Daftar data proyek yang akan dikumpulkan Nilai minimal : tidak ada. Bobot nilai : 4 Mekanisme penilaian: - Nilai rendah (0%) apabila dokumen berjumlah dibawah 5 dari 10 yang disyaratkan. - Nilai sedang (50%) apabila dokumen berjumlah dibawah 10 atau minimal 5 dari 10 yang disyaratkan. - Nilai tinggi (100%) apabila dokumen berjumlah 10 dari 10 yang disyaratkan. - Dokumen yang dapat dinilai adalah dokumen yang dapat memenuhi atau memberikan penjelasan yang sesuai dengan praktek terkait. Nilai :

252 236 PS 2.4 Nama Praktek: Rencana Sumber Daya Proyek Penilaian praktek ini untuk mengetahui bagaimana penyedia menyiapkan rencana sumber daya untuk menjalankan proyek. Sebagian data dari praktek ini dapat dilihat pada dokumen penawaran teknis pada bagian kualitas metodologi, dan bagian tenaga ahli. Dokumen yang dapat dinilai: 1. Paket pekerjaan 2. Kamus pekerjaan WBS 3. Kebutuhan staf berdasarkan ukuran dan ruang lingkup proyek 4. Fasilitas kritis dan daftar peralatan 5. Definisi proses dan alur kerja, dan diagram 6. Daftar kebutuhan administrasi proyyek 7. Laporan status Nilai minimal: Nilai sedang (50%), minimal terdapat 4 dokumen dari 7 yang disyaratkan, bila tidak maka nilai (0%). Bobot nilai : 8 Mekanisme penilaian: - Nilai rendah (0%) apabila dokumen berjumlah dibawah 4 dari 7 yang disyaratkan. - Nilai sedang (50%) apabila dokumen berjumlah dibawah 7 atau minimal 4 dari 7 yang disyaratkan. - Nilai tinggi (100%) apabila dokumen berjumlah 7 dari 7 yang disyaratkan. - Dokumen yang dapat dinilai adalah dokumen yang dapat memenuhi atau memberikan penjelasan yang sesuai dengan praktek terkait. Nilai : PS 2.5 Nama Praktek: Rencana Kebutuhan Pengetahuan dan Keterampilan Penilaian praktek ini untuk mengetahui rencana kebutuhan pengetahuan dan keterampilan untuk melakukan proyek dari penyedia. Sebagian data dari praktek ini dapat dilihat pada dokumen penawaran teknis pada bagian tenaga ahli. Dokumen yang dapat dinilai: 1. Inventarisasi keterampilan yang dibutuhkan 2. Staffing dan rencana karyawan baru 3. Database (mis., keterampilan, pelatihan) 4. Rencana pelatihan Nilai minimal: Nilai tinggi (100%), harus terdapat 4 dokumen yang disyaratkan, bila tidak maka nilai (0%).

253 237 Bobot nilai : 16 Mekanisme penilaian: - Nilai rendah (0%) apabila dokumen berjumlah dibawah 2 dari 4 yang disyaratkan. - Nilai sedang (50%) apabila dokumen berjumlah dibawah 4 atau minimal 2 dari 4 yang disyaratkan. - Nilai tinggi (100%) apabila dokumen berjumlah 4 dari 4 yang disyaratkan. - Dokumen yang dapat dinilai adalah dokumen yang dapat memenuhi atau memberikan penjelasan yang sesuai dengan praktek terkait. PS 2.6 Nilai : Nama Praktek: Rencana Keterlibatan Pemangku Kepentingan Penilaian praktek ini untuk mengetahui rencana keterlibatan stakeholder yang diidentifikasi dari penyedia. Dokumen yang dapat dinilai: Rencana keterlibatan stakeholder Nilai minimal : tidak ada. Bobot nilai : 4 Mekanisme penilaian: - Nilai rendah (0%) apabila tidak ada dokumen yang disyaratkan. - Nilai sedang (50%) apabila terdapat dalam dokumen tapi tidak ada penjelasan yang mendukung maksud praktek. - Nilai tinggi (100%) apabila terdapat dalam dokumen dan ada penjelasan yang mendukung maksud praktek. - Dokumen yang dapat dinilai adalah dokumen yang dapat memenuhi atau memberikan penjelasan yang sesuai dengan praktek terkait. Nilai : PS 2.7 Nama Praktek: Menetapkan Rencana Proyek Penilaian praktek ini untuk mengetahui bagaimana penyedia membangun dan memelihara rencana proyek secara keseluruhan. Dokumen yang dapat dinilai: Rencana proyek secara keseluruhan Nilai minimal: Nilai tinggi (100%), harus terdapat dokumen dengan penjelasan yang mendukung praktek yang terkait, bila tidak maka nilai (0%). Bobot nilai : 16

254 238 Mekanisme penilaian: - Nilai rendah (0%) apabila tidak ada dokumen yang disyaratkan. - Nilai sedang (50%) apabila terdapat dalam dokumen tapi tidak ada penjelasan yang mendukung maksud praktek. - Nilai tinggi (100%) apabila terdapat dalam dokumen dan ada penjelasan yang mendukung maksud praktek. - Dokumen yang dapat dinilai adalah dokumen yang dapat memenuhi atau memberikan penjelasan yang sesuai dengan praktek terkait. Nilai : TS 3 PS 3.1 Tujuan: Mendapatkan Komitmen untuk Rencana Komitmen dengan rencana proyek yang ditetapkan dan dipelihara. Nama Praktek: Ulasan Rencana yang Mempengaruhi Proyek Penilaian praktek ini untuk mengetahui bagaimana penyedia meninjau semua rencana yang mempengaruhi proyek untuk memahami komitmen proyek. Dokumen yang dapat dinilai: Rekaman dari tinjauan rencana yang mempengaruhi proyek Nilai minimal : tidak ada. Bobot nilai : 4 Mekanisme penilaian: - Nilai rendah (0%) apabila tidak ada dokumen yang disyaratkan. - Nilai sedang (50%) apabila terdapat dalam dokumen tapi tidak ada penjelasan yang mendukung maksud praktek. - Nilai tinggi (100%) apabila terdapat dalam dokumen dan ada penjelasan yang mendukung maksud praktek. - Dokumen yang dapat dinilai adalah dokumen yang dapat memenuhi atau memberikan penjelasan yang sesuai dengan praktek terkait. Nilai : PS 3.2 Nama Praktek: Rekonsiliasi Kerja dan Tingkat Sumberdaya Penilaian praktek ini untuk mengetahui bagaimana penyedia menyesuaikan rencana proyek untuk menyelaraskan ketersediaan dan sumber daya yang diperkirakan. Dokumen yang dapat dinilai: 1. Metode Revisi dan parameter estimasi yang sesuai (misalnya, alat yang lebih baik) 2. Renegosiasi anggaran 3. Revisi jadwal

255 Daftar revisi kebutuhan 5. Negosiasi ulang perjanjian dengan pemangku kepentingan Nilai minimal : tidak ada. Bobot nilai : 4 Mekanisme penilaian: - Nilai rendah (0%) apabila dokumen berjumlah dibawah 3 dari 5 yang disyaratkan. - Nilai sedang (50%) apabila dokumen berjumlah dibawah 5 atau minimal 3 dari 5 yang disyaratkan. - Nilai tinggi (100%) apabila dokumen berjumlah 5 dari 5 yang disyaratkan. - Dokumen yang dapat dinilai adalah dokumen yang dapat memenuhi atau memberikan penjelasan yang sesuai dengan praktek terkait. PS 3.3 Nilai : Nama Praktek: Mendapatkan Komitmen Rencana Penilaian praktek ini untuk mengetahui bagaimana komitmen dapat terbangun antara penyedia denganpemangku kepentingan terkait yang bertanggung jawab untuk melakukan dan mendukung pelaksanaan rencana. Dokumen yang dapat dinilai: 1. Permintaan terdokumentasi untuk komitmen 2. Komitmen terdokumentasi Nilai minimal : tidak ada. Bobot nilai : 4 Mekanisme penilaian: - Nilai rendah (0%) apabila tidak ada dokumen yang disyaratkan. - Nilai sedang (50%) apabila ada 1 dokumen dari 2 yang disyaratkan. - Nilai tinggi (100%) apabila ada 2 dokumen dari 2 yang disyaratkan. - Dokumen yang dapat dinilai adalah dokumen yang dapat memenuhi atau memberikan penjelasan yang sesuai dengan praktek terkait. Nilai :

256 240 Project Monitoring and Control (Pemantauan dan Pengendalian Proyek) memilki tujuan untuk memberikan pemahaman tentang perkembangan proyek sehingga tindakan koreksi yang tepat dapat diambil ketika kinerja proyek menyimpang secara signifikan dari rencana. Kode Tujuan / Praktek Keterangan Spesifik TS 1 PS 1.1 Tujuan Praktek: Memantau Proyek Terhadap Rencana Kemajuan proyek aktual dan kinerja yang dipantau terhadap rencana proyek. Nama Praktek: Memantau Parameter Perencanaan Proyek Penilaian praktek ini untuk mengetahui bagaimana penyedia memantau hasil dari parameter perencanaan proyek terhadap rencana proyek. Dokumen yang dapat dinilai: 1. Rekaman kinerja proyek 2. Rekaman penyimpangan yang signifikan 3. Laporan kinerja biaya Nilai minimal: Nilai sedang (50%), minimal terdapat 2 dokumen dari 3 yang disyaratkan, bila tidak maka nilai (0%). Bobot nilai : 12 Mekanisme penilaian: - Nilai rendah (0%) apabila dokumen berjumlah dibawah 2 dari 3 yang disyaratkan. - Nilai sedang (50%) apabila dokumen berjumlah dibawah 3 atau minimal 2 dari 3 yang disyaratkan. - Nilai tinggi (100%) apabila dokumen berjumlah 3 dari 3 yang disyaratkan. - Dokumen yang dapat dinilai adalah dokumen yang dapat memenuhi atau memberikan penjelasan yang sesuai dengan praktek terkait. Nilai : PS 1.2 Nama Praktek: Memantau Komitmen Penilaian praktek ini untuk mengetahui bagaimana penyedia memantau komitmen yang masuk dalam rencana proyek.

257 241 Dokumen yang dapat dinilai: Rekaman tinjauan komitmen Nilai minimal: Nilai sedang (50%), minimal terdapat dokumen yang disyaratkan, bila tidak maka nilai (0%). Bobot nilai : 11 Mekanisme penilaian: - Nilai rendah (0%) apabila tidak ada dokumen yang disyaratkan. - Nilai sedang (50%) apabila terdapat dalam dokumen tapi tidak ada penjelasan yang mendukung maksud praktek. - Nilai tinggi (100%) apabila terdapat dalam dokumen dan ada penjelasan yang mendukung maksud praktek. - Dokumen yang dapat dinilai adalah dokumen yang dapat memenuhi atau memberikan penjelasan yang sesuai dengan praktek terkait. Nilai : PS 1.3 Nama Praktek: Memantau Risiko Proyek Penilaian praktek ini untuk mengetahui bagaimana penyedia memantau risiko teridentifikasi rencana proyek. Dokumen yang dapat dinilai: Rekaman pemantauan risiko proyek Nilai minimal : tidak ada. Bobot nilai : 7 Mekanisme penilaian: - Nilai rendah (0%) apabila tidak ada dokumen yang disyaratkan. - Nilai sedang (50%) apabila terdapat dalam dokumen tapi tidak ada penjelasan yang mendukung maksud praktek. - Nilai tinggi (100%) apabila terdapat dalam dokumen dan ada penjelasan yang mendukung maksud praktek. - Dokumen yang dapat dinilai adalah dokumen yang dapat memenuhi atau memberikan penjelasan yang sesuai dengan praktek terkait. Nilai : PS 1.4 Nama Praktek: Memantau Manajemen Data Penilaian praktek ini untuk mengetahui bagaimana penyedia memantau pengelolaan data proyek terhadap rencana proyek.

258 242 Dokumen yang dapat dinilai: Rekaman manajemen data Nilai minimal: Nilai sedang (50%), minimal terdapat dokumen yang disyaratkan, bila tidak maka nilai (0%). Bobot nilai : 11 Mekanisme penilaian: - Nilai rendah (0%) apabila tidak ada dokumen yang disyaratkan. - Nilai sedang (50%) apabila terdapat dalam dokumen tapi tidak ada penjelasan yang mendukung maksud praktek. - Nilai tinggi (100%) apabila terdapat dalam dokumen dan ada penjelasan yang mendukung maksud praktek. - Dokumen yang dapat dinilai adalah dokumen yang dapat memenuhi atau memberikan penjelasan yang sesuai dengan praktek terkait. PS 1.5 Nilai : Nama Praktek: Memantau Keterlibatan Pemangku Kepentingan Penilaian praktek ini untuk mengetahui bagaimana penyedia memantau keterlibatan stakeholder terhadap rencana proyek. Dokumen yang dapat dinilai: Rekaman keterlibatan stakeholder Nilai minimal : tidak ada. Bobot nilai : 7 Mekanisme penilaian: - Nilai rendah (0%) apabila tidak ada dokumen yang disyaratkan. - Nilai sedang (50%) apabila terdapat dalam dokumen tapi tidak ada penjelasan yang mendukung maksud praktek. - Nilai tinggi (100%) apabila terdapat dalam dokumen dan ada penjelasan yang mendukung maksud praktek. - Dokumen yang dapat dinilai adalah dokumen yang dapat memenuhi atau memberikan penjelasan yang sesuai dengan praktek terkait. Nilai : PS 1.6 Nama Praktek: Tinjauan Kemajuan Penilaian praktek ini untuk mengetahui bagaimana penyedia melakukan tinjauan berkala kemajuan proyek, kinerja, dan masalah.

259 243 Dokumen yang dapat dinilai: Hasil peninjauan proyek didokumentasikan Nilai minimal: Nilai sedang (50%), minimal terdapat dokumen yang disyaratkan, bila tidak maka nilai (0%). Bobot nilai : 12 Mekanisme penilaian: - Nilai rendah (0%) apabila tidak ada dokumen yang disyaratkan. - Nilai sedang (50%) apabila terdapat dalam dokumen tapi tidak ada penjelasan yang mendukung maksud praktek. - Nilai tinggi (100%) apabila terdapat dalam dokumen dan ada penjelasan yang mendukung maksud praktek. - Dokumen yang dapat dinilai adalah dokumen yang dapat memenuhi atau memberikan penjelasan yang sesuai dengan praktek terkait. Nilai : PS 1.7 Nama Praktek: Tinjauan Milestone Penilaian praktek ini untuk mengetahui bagaimana penyedia meninjau prestasi proyek dan hasil di milestone proyek yang ditentukan. Dokumen yang dapat dinilai: Dokumentasi hasil review per milestone Nilai minimal: Nilai sedang (50%), minimal terdapat dokumen yang disyaratkan, bila tidak maka nilai (0%). Bobot nilai : 11 Mekanisme penilaian: - Nilai rendah (0%) apabila tidak ada dokumen yang disyaratkan. - Nilai sedang (50%) apabila terdapat dalam dokumen tapi tidak ada penjelasan yang mendukung maksud praktek. - Nilai tinggi (100%) apabila terdapat dalam dokumen dan ada penjelasan yang mendukung maksud praktek. - Dokumen yang dapat dinilai adalah dokumen yang dapat memenuhi atau memberikan penjelasan yang sesuai dengan praktek terkait. Nilai :

260 244 TS 2 PS 2.1 Tujuan: Mengelola Tindakan Korektif untuk Penutupan Tindakan korektif yang berhasil untuk penyelesaian ketika kinerja proyek atau hasil menyimpang secara signifikan dari rencana. Nama Praktek: Menganalisis Masalah Penilaian praktek ini untuk mengetahui bagaimana penyedia mengumpulkan dan menganalisa masalah dan menentukan tindakan korektif untuk mengatasinya. Dokumen yang dapat dinilai: Daftar masalah yang memerlukan tindakan korektif Nilai minimal : tidak ada. Bobot nilai : 7 Mekanisme penilaian: - Nilai rendah (0%) apabila tidak ada dokumen yang disyaratkan. - Nilai sedang (50%) apabila terdapat dalam dokumen tapi tidak ada penjelasan yang mendukung maksud praktek. - Nilai tinggi (100%) apabila terdapat dalam dokumen dan ada penjelasan yang mendukung maksud praktek. - Dokumen yang dapat dinilai adalah dokumen yang dapat memenuhi atau memberikan penjelasan yang sesuai dengan praktek terkait. Nilai : PS 2.2 Nama Praktek: Pengambilan Tindakan Perbaikan Penilaian praktek ini untuk mengetahui bagaimana penyedia mengambil tindakan korektif terhadap permasalahan yang diidentifikasi. Dokumen yang dapat dinilai: Rencana aksi korektif Nilai minimal: Nilai sedang (50%), minimal terdapat dokumen yang disyaratkan, bila tidak maka nilai (0%). Bobot nilai : 11 Mekanisme penilaian: - Nilai rendah (0%) apabila tidak ada dokumen yang disyaratkan. - Nilai sedang (50%) apabila terdapat dalam dokumen tapi tidak ada penjelasan yang mendukung maksud praktek. - Nilai tinggi (100%) apabila terdapat dalam dokumen dan ada penjelasan yang mendukung maksud praktek. - Dokumen yang dapat dinilai adalah dokumen yang dapat memenuhi atau memberikan penjelasan yang sesuai dengan praktek terkait.

261 245 Nilai : PS 2.3 Nama Praktek: Kelola Tindakan korektif Penilaian praktek ini untuk mengetahui bagaimana penyedia mengelola tindakan korektif untuk menyelesaikan proyek. Dokumen yang dapat dinilai: Hasil Tindakan korektif Nilai minimal: Nilai sedang (50%), minimal terdapat dokumen yang disyaratkan, bila tidak maka nilai (0%). Bobot nilai : 11 Mekanisme penilaian: - Nilai rendah (0%) apabila tidak ada dokumen yang disyaratkan. - Nilai sedang (50%) apabila terdapat dalam dokumen tapi tidak ada penjelasan yang mendukung maksud praktek. - Nilai tinggi (100%) apabila terdapat dalam dokumen dan ada penjelasan yang mendukung maksud praktek. - Dokumen yang dapat dinilai adalah dokumen yang dapat memenuhi atau memberikan penjelasan yang sesuai dengan praktek terkait. Nilai :

262 246 Lampiran 6 : Rancangan Formulir Rangkuman Penilaian Kapasitas Penyedia

263 247 Nama Perusahaan Nama Proyek Rancangan Formulir Rangkuman Penilaian Kapasitas Penyedia Requirements Management (Manajemen Kebutuhan) Kode Tujuan / Rekomendasi Skala Persentase Praktek Nilai Minimal Nilai Skala Nilai Spesifik Bobot Prakte k Nilai Praktek TS 1 PS 1.1 Sedang 40 PS PS PS PS Nilai Area Proses Keterangan: Project Planning (Perencanaan Proyek) Kode Tujuan / Rekomendasi Skala Praktek Nilai Minimal Nilai Spesifik Persentase Skala Nilai Bobot Prakte k Nilai Praktek TS 1 PS 1.1 Sedang 8 PS 1.2 Sedang 8 PS 1.3 Sedang 8 PS 1.4 Sedang 8 TS 2 PS 2.1 Sedang 8 PS PS PS 2.4 Sedang 8 PS 2.5 Tinggi 14 PS PS 2.7 Tinggi 14 TS 3 PS PS 3.2-4

264 248 PS Nilai Area Proses Keterangan: Project Monitoring and Control (Pemantauan dan Pengendalian Proyek) Kode Tujuan / Praktek Spesifik Rekomendasi Nilai Minimal Skala Nilai Persentase Skala Nilai Bobot Prakte k Nilai Praktek TS 1 PS 1.1 Sedang 12 PS 1.2 Sedang 11 PS PS 1.4 Sedang 11 PS PS 1.6 Sedang 12 PS 1.7 Sedang 11 TS 2 PS PS 2.2 Sedang 11 PS 2.3 Sedang 11 Nilai Area Proses Keterangan: Jumlah Keseluruhan Area Proses Bobot Area Proses Nilai Area Proses Nilai Bobot Area Proses Requirements Management 30% Project Planning 35% Project Monitoring and Control 35% Total Nilai