Haruskah Pemerintah Mengembangkan Perangkat Lunak Sendiri?


Menjadi seorang pengembang yang peduli terhadap perangkat lunak, dan pernah bekerja untuk pemerintah daerah selama delapan tahun terakhir, saya telah sering merenungkan pertanyaan ini. Di satu sisi, tema filosofis yang berjalan adalah pemrograman merupakan literasi baru, dan karena software menembus setiap aspek kehidupan kita, dalam mengungkapkan pengetahuan pemrograman, berbeda dengan menulis biasa.
Di sisi lain, masih cukup banyak program yang membutuhkan banyak keahlian dan teknik keterampilan, karena itu sulit dan mahal untuk menumbuhkan kompetensi inti organisasi. Bagi pemerintahan yang kecil, sebuah organisasi software yang kompeten bukan berada di atas meja sebagai strategi jangka panjang. Lebih buruk lagi, software dianggap sebagai beban, juga dianggap sebagai sebuah kejahatan namun diperlukan, tidak hanya oleh personel yang merugikan komputer, tetapi oleh departemen TI sendiri. Harga yang dibayarkan untuk sikap itu jauh lebih tinggi dari pada mencurigai.
Penunjang vs Sistem Vital
Ini dilema yang dialami perangkat lunak in house dibandingkan outsourcing, dihadapi oleh semua jenis organisasi, dan analisis biasanya membedakan antara "infrastruktur perangkat lunak" dan "perangkat lunak bisnis", dengan bungkus pengetahuan bisnis. Sebuah esai Philip Armour di "Komunikasi ACM" menawarkan wawasan yang berkualitas tentang pengorbanan. Bukan perbedaan biasa dari infrastruktur vs bisnis, ia berbicara tentang penunjang vs sistem vital. Sebuah sistem pendukung membantu bisnis, tetapi tidak konstitutif dari bisnis itu sendiri. Sebuah sistem penting adalah organisasi pengetahuan operasional. Apa yang membenarkan keberadaannya?
Armour berpendapat bahwa perusahaan-perusahaan baik disarankan untuk menghindari pembangunan sistem in house, tetapi juga untuk menghindari outsourcing sistem vital. Yang terakhir ini, anti ortodoksi, kita seharusnya melakukan outsourcing sebagai bentuk pemotongan biaya tanpa sifat sistem, kan? Itulah pandangan tradisional software sebagai biaya: sebagai aset yang Anda gunakan, seperti Anda menyewa ruangan untuk beroperasi. Masalah dengan pandangan itu adalah bahwa perangkat lunak telah menjadi yang terbaik, yang paling akurat (dan kadang-kadang hanya) pengetahuan bisnis yang memiliki organisasi. Titik kunci di sini memerlukan perubahan radikal dalam sikap terhadap pembangunan in house: daripada melakukannya sebagai jalan terakhir, in house developement harus menjadi pilihan pertama untuk dipertimbangkan.

Konsekuensi yang tidak diinginkan outsourcing bagi pemerintah
Software outsourcing berarti pengetahuan outsourcing. Hal ini mungkin tidak jelas, karena orang-orang yang melakukan layanan bagi manusia yang disediakan masih dipekerjakan oleh agen, namun itu hanya kepastian yang dangkal. Ketika tidak ada spesialis software yang benar tersedia dalam pengadaan TI pemerintah, birokrat yang mudah ditipu akan pergi dengan vendor yang paling menarik. Terlalu banyak keputusan teknik yang sangat konsekuensial yang dibuat oleh administrator dengan pengetahuan yang dangkal. Bahkan, jika seseorang menahan diri dari posisi yang miring bahwa pegawai pemerintah yang dipekerjakan untuk beroperasi dengan sistem keuangan yang longgar, bagaimana kita bisa mengharapkan mereka untuk secara akurat menilai nilai potensial atau moneter software?
Ketika sebuah perusahaan besar datang ke perangkat lunak yang sebenarnya profesional dengan perkiraan anggaran dana sebesar US$ 200.000, untuk apa yang dinyatakan konservatif diperkirakan dua minggu kerja, mereka akan mendapatkan panggilan tersebut ketika mereka melakukan itu petugas excel akan mendapat imbalam sebagai pengambil keputusan. Karena penilaian kritis sudah tidak dapat diharapkan. Semua keahlian teknis dan sebagian besar pengetahuan bisnis pada dasarnya ditangguhkan ke entitas outsourcing. Mereka bertindak sebagai otoritas tertinggi pada subyek. Hal ini tidak mengutuk pribadi, perusahaan yang berorientasi profit. Tidak secara inheren bermaksud buruk dalam perilaku vendor. Namun, dinamika dalam hubungan pribadi vs publik yang miring.
Pemerintah sebagai komunitas open source sendiri
Apakah alternatif yang setiap instansi pemerintah menanggung untuk biaya dan upaya menulis perangkat lunak sendiri? Jelas ini tidak masuk akal. Seperti yang sering terjadi ketika pengaturan ekonomi menjadi terganggu dari waktu ke waktu, memotong tengkulak memecahkan masalah-perantara di sini menjadi perusahaan nirlaba yang mengelola produksi dan biaya sistem vital perangkat lunak.
Bagaimana lembaga mempekerjakan programmer yang berkualitas, berpengalaman dalam teknologi modern untuk menulis kode untuk mendorong bisnis dari pemerintah ke pemerintahan yang lain secara terbuka, berbagi keahlian dan usaha? Itu benar pemotongan biaya, dan investasi jangka panjang open source yang strategis dari pemerintah kepada masyarakat. Selain itu, memiliki tim programmer yang baik membebaskan dan memungkinkan. Perbaikan virus dan upgrade dilakukan dengan cepat, dan karena pengetahuan tetap dalam organisasi, kelangsungan proyek dipastikan, yang sangat penting untuk pengendalian biaya jangka panjang.
Memulai perubahan budaya tersebut membutuhkan cukup banyak inisiatif dan idealisme, tapi ada baiknya dipertimbangkan. Di Miami-Dade County, kami menyelenggarakan konferensi kecil (2010 bersama Gov Simposium) tahun lalu, yang terdiri dari lembaga lokal. Idenya sederhana: Kami telah menulis beberapa kode rumah, bekerja dengan baik, mari kita berikan kepada orang lain, dan mari kita bekerja sama dalam perbaikan dan pemeliharaan sehingga bermanfaat untuk semua orang. Memang, menciptakan sebuah proyek open source berkembang dari sepotong kode internal yang membutuhkan waktu, tapi itu sangat layak. Upaya ini juga dapat menjadi motivator yang baik bagi karyawan ketika mereka melihat pekerjaan mereka melayani orang-orang di luar badan mereka.
Sebuah hasil penting dari upaya Miami-Dade adalah salah satu proyek rumah yang terbesar dan paling sukses, sistem CRM mengemudi 311 pusat. Sistem ini hidup dan operasional, dan pada GitHub menunggu perhatian. Pemerintah mungkin belum pandai pada pengembangan perangkat lunak dan inovasi di masa lalu, tetapi open source mengubah persamaan. (Desi Ratnasari)
Borislav Iordanov, opensource.com/government/15/3/should-government-develop-softwarehttp://nurulfikri.ac.id/index.php/artikel/item/706-haruskah-pemerintah-mengembangkan-perangkat-lunak-sendiri

Komentar

Postingan populer dari blog ini

MVC Model-View-Controller

Algoritma dan Flowchart Untuk Menentukan Bilangan Terbesar