Uji kiriman posterous ke dagdigdug
Sesuai pengumuman dari posterous, seharusnya tulisan ini muncul di dagdigdug.
Perangkat lunak berbentuk layanan
Perangkat lunak berbentuk layanan (PLBL) atau software as a service (SaaS) , adalah suatu model penyampaian aplikasi perangkat lunak oleh suatu vendor perangkat lunak yang mengembangkan aplikasi berbasis web yang diinangi dan dioperasikan (baik secara mandiri maupun melalui pihak ketiga) untuk digunakan oleh pelanggannya melalui Internet.
Pelanggan tidak mengeluarkan uang untuk memiliki perangkat lunak tersebut melainkan hanya untuk menggunakan. Pelanggan menggunakan perangkat lunak tersebut melalui suatu API (application programming interface, antarmuka pemrograman aplikasi) yang dapat diakses melalui web dan seringkali ditulis menggunakan layanan web (web services) atau REST.
Istilah ini belakangan mulai lebih dipilih kalangan industri terkait sebagai pengganti istilah ASP (application service provider, penyedia layanan aplikasi) dan on-demand (sesuai permintaan).
Menurut kajian dari Springboard Research, sekitar 54% pasar PLBL di Asia-Pasifik saat ini diperkirakan dimiliki oleh ISV (independent software vendor, vendor perangkat lunak independen) lokal atau vendor global kecil. Sementara sisanya masih didominasi oleh vendor-vendor besar dengan porsi terbesar dipunyai salesforce dan WebEx. Pasar PLBL di Asia Pasifik meningkat 68% pada tahun 2007 dan diperkirakan akan mencapai 460 juta USD pada tahun 2010
Meskipun aplikasi CRM dan kolaborasi masih menjadi sumber penghasilan terbesar bagi PLBL, mulai populer juga ceruk aplikasi lain seperti aplikasi perkantoran, kepatuhan, serta manajemen SDM. Pemain kecil banyak bergantung pada ceruk aplikasi yang tidak dilirik oleh pemain besar. Pengetahuan dan pengalaman spesifik ISV kecil terhadap UKM (SMB, small medium business) juga menjadi sumber kekuatan persaingan mereka terhadap vendor besar.
Beberapa contoh pemain lokal yang dipandang cukup berhasil menurut kajian Springboard adalah 800CRM (Cina), HRMantra (India), Justlogin (Singapura), Nothacker (Singapura) serta Pyxis (India).
1 CommentKetersediaan server vs. ketersediaan layanan
Bagian teknologi informasi atau TI sering menggunakan ketersediaan server (server availability) dalam bentuk persentase serta jumlah jam dan menit lamanya suatu server atau peladen beroperasi sebagai metrik untuk mengukur kinerja mereka. Dalam banyak kasus, metrik ini tidak tepat digunakan untuk berbagi informasi dengan pihak di luar departemen TI.
Bagi pengguna teknologi informasi, angka-angka tersebut tidaklah berarti. Yang terpenting bagi mereka adalah ketersediaan layanan (service availability) atau jumlah waktu suatu layanan teknologi informasi, seperti surat elektronik dan sistem CRM, tersedia untuk digunakan.
Pemahaman bagian TI mengenai dua konsep yang berbeda ini dapat membantu suksesnya pemberian layanan TI. Di samping memantau tetap berjalannya suatu server atau gugus/ladang server (server farm atau server cluster), yang terpenting juga adalah memastikan bahwa layanan dalam server tersebut (seperti layanan web atau surat-e) berjalan dan dapat digunakan. Bahkan juga perlu dipikirkan bagaimana suatu layanan teknologi informasi masih dapat disediakan dalam kondisi ketidaktersediaan server-server tersebut.
Sumber: ZDNet TechGuides.
Ciri persyaratan proyek palsu
Dalam manajemen proyek, persyaratan atau kebutuhan (requirement) proyek menjelaskan bagaimana seharusnya aksi, tampilan, atau kinerja suatu produk atau layanan. Detil-detil ini menjelaskan fitur dan fungsi yang harus dimiliki produk atau hasil kerja (deliverables) suatu proyek.
Pengumpulan persyaratan suatu proyek akan sangat mudah dilakukan jika Anda dapat menanyakannya kepada klien dan mereka dapat menjawabnya tepat sesuai kebutuhan mereka. Sayangnya, hal tersebut seringkali tidak semudah yang dibayangkan. Bahkan pada kenyataannya, informasi dari klien yang tampak seperti suatu persyaratan ternyata bukanlah demikian. Berikut beberapa ciri persyaratan proyek palsu yang sering ditemukan:
- Persyaratan samar; Persyaratan harus cukup spesifik untuk dapat dimengerti. Contohnya, pernyataan “Saya ingin aplikasi ini berguna bagi karyawan” bukanlah suatu persyaratan yang spesifik dan harus diperjelas dengan pertanyaan lanjutan untuk mendapatkan kebutuhan yang sesungguhnya.
- Opini; Walaupun opini kadang dapat menjadi persyaratan yang valid, seringkali sebaliknya. Contohnya, pernyataan “Perusahaan terlalu banyak menghabiskan uang untuk proyek ini” hanyalah suatu opini yang bukan merupakan persyaratan proyek.
- Pernyataan yang berkaitan dengan proyek; Persyaratan menjelaskan hasil kerja, dan bukan proyek. Contohnya, pernyataan “Kita harus membuat prototipe terlebih dulu untuk proyek ini” merupakan masukan bagi proyek dan bukanlah suatu persyaratan.
- Pernyataan di luar lingkup proyek; Contohnya, pernyataan “Saya ingin pencetak (printer) baru yang serupa dengan pencetak rekan kerja saya itu” adalah di luar lingkup proyek dan bukan persyaratan.
- Komentar dari orang yang salah; Pastikan bahwa semua persyaratan muncul dari orang yang tepat. Contohnya, pernyataan “Kita harus mengizinkan pemasok untuk mengakses aplikasi ini” bukanlah suatu persyaratan yang valid jika tidak muncul dari pengguna yang berwenang.
- Tidak realistis atau tak dapat diuji; Suatu persyaratan kadang hanyalah merupakan pernyataan hiperbolis atau untuk keperluan pemasaran semata. Contohnya, pernyataan “Aplikasi ini harus dapat menjadi inspirasi umat manusia” tidaklah dapat dijadikan suatu persyaratan karena sangat hiperbolis dan sulit untuk diuji.
Sumber: ZDNet TechGuides.
Elemen kunci perencanaan kelangsungan bisnis yang efektif
Perencanaan kelangsungan bisnis (BCP, business continuity planning) adalah suatu rencana yang dibuat untuk mencegah gangguan terhadap proses bisnis normal suatu perusahaan. Secara tradisional, BCP ditujukan untuk menanggulangi bencana alam seperti gempa bumi dan kebakaran, walaupun kini BCP juga mencakup penanggulangan terhadap peristiwa kerugian yang disebabkan tindakan manusia seperti sabotase, pelanggaran keamanan (security breach), serangan virus komputer, dll.
Tantangan terbesar dalam pembuatan BCP adalah identifikasi elemen kunci yang harus dilindungi. Dalam perencanaan tersebut, ada empat hal penting yang harus dilakukan yaitu peninjauan semua bagian dari bisnis, putuskan mana bagian yang kritis untuk kelangsungan bisnis, tentukan berapa lama suatu unit bisa bertahan tanpa adanya bagian kritis tersebut, serta berapa besar kerugian operasional dan finansial yang dapat timbul jika terjadi kegagalan pada bagian kritis itu.
Ada tiga ukuran atau metrik penting yang harus diperhatikan dalam pembuatan lingkup BCP, yaitu
- RTO (recovery time objective, sasaran waktu pemulihan) yaitu waktu yang dibutuhkan dari peristiwa bencana hingga pulihnya sistem.
- RPO (recovery point objective, sasaran titik pemulihan) yaitu waktu antara peristiwa bencana dengan waktu pencadangan (backup) terakhir.
- LOS (level of service, tingkat layanan) yaitu kombinasi antara hasil dan fungsionalitas yang tersedia dan merupakan indikator fungsi mana yang esensial.
Beberapa elemen kunci penting yang sangat mempengaruhi efektivitas BCP adalah
- Dukungan eksekutif; terutama mengenai penentuan bagian bisnis perusahaan mana yang harus tetap beroperasi dalam keadaan darurat serta nilai metrik (RTO, RPO, LOS) yang diinginkan.
- Pengujian secara berkala; untuk meregang rencana, menunjukkan potensi kelemahan, serta menemukan hal-hal yang belum tercakup dalam rencana.
- Pendanaan yang memadai; karena tanpa adanya dana yang mencukupi, rencana sebaik apa pun tak akan berguna.
- Pelaksana yang dipercaya; karena manusia bisa lebih fleksibel dan inovatif dari pada sistem, terutama dalam keadaan darurat.