Penawaran Maintenance Aplikasi, Bagaimana Saya Membuatnya?

Selain penentuan harga, banyak rekan-rekan tekno yang menanyakan bagaimana memberikan penawaran maintenance aplikasi untuk pelanggan. Software membutuhkan maintenance, untuk memastikan bebas dari error / bug, tetap mengikuti kebutuhan perusahaan, dan perbaikan kinerja. Pada artikel kali ini saya akan berbagi bagaimana saya memberikan penawaran maintenance untuk klien.

10 Issue Software yang Sering Muncul

Selain menangani bug, saya juga memasukkan Change request (CR) minor ke dalam lingkup maintenance. Minor di sini artinya tidak membuat menu baru atau tabel baru. Hanya penambahan fitur kecil di menu yang sudah ada. Yang dapat diselesaikan dalam 2-4 jam. Jika CR bersifat mayor, maka ada proyek pengembangan, tidak termasuk maintenance.

Berikut ini adalah beberapa issue dan pekerjaan tambahan minor yang sering muncul saat maintenance:

1. Crash

Crash merupakan issue software yang paling sering muncul. Crash ini adalah software berhenti berfungsi (hang) atau menampilkan pesan error teknis saat digunakan. Pesan error teknis maksudnya adalah pesan error yang muncul karena adanya kesalahan dalam script pemrograman. Selain karena script, crash juga dapat disebabkan karena tidak tersedianya resource hardware saat menjalankan fungsi tertentu.

2. Functional Error

Produk software yang sudah terjadi seharusnya siap untuk digunakan. Namun terkadan ada kejadian dimana salah satu fungsinya tidak dapat dijalankan. Yang paling sederhana ada tombol yang menampilkan halaman 404, fungsi ekspor excel tidak berfungsi, atau tombol back yang tidak bekerja. Itu adalah beberapa contoh dari functional error.

3. Typo dan Permintaan Perubahan Teks

Kesalahan yang sangat manusiawi, bahkan untuk programmer. Typo adalah kesalahan ketik, tidak mempengaruhi kinerja sama sekali. Namun ada pengguna yang kritis akan hal ini. Apalagi jika typo ada di dokumen resmi perusahaan yang dihasilkan dari aplikasi. Selain typo, pengguna juga terkadang meminta perubahan pada redaksional di aplikasi, di dokumen, maupun di pesan error.

4. Calculation Error

Di sebagian besar proses software, kalkulasi merupakan bagian yang sangat penting. Seperti akuntansi dan payroll. Kesalahan dalam penghitungan dapat menyebabkan dampak yang fatal. Calculation errors adalah jenis issue yang terletak pada kesalahan penghitungan ini.

5. Masalah pada Hardware atau OS

Jika hardware atau OS mengalami masalah, tentu akan berdampak pada software. Software berjalan di atas hardware dan OS tersebut, sehingga sedikit-banyak akan terdampak. Pengguna biasanya tidak peduli letak kesalahannya, software developer yang wajib memperbaikinya. Meskipun itu hardware dan OS.

6. Workflow Error

Aplikasi yang melibatkan beberapa peran pengguna, biasanya memiliki workflow. Atau bisa dikatakan alur proses bisnis. Contoh paling sederhana adalah pengajuan cuti. Pengajuan cuti ini harus disetujui atasan. Ketika cuti diajukan dan langsung disetujui tanpa diketahui atasan, maka ini terjadi workflow error.

7. Penambahan Fitur di Menu

Di sebuah menu atau halaman terdapat berbagai macam fitur di dalamnya. Fitur-fitur sederhana seperti pencarian, pengurutan, dan penyaringan harus ada saat menampilkan data. Adakalanya pengguna meminta penambahan fitur tambahan, seperti ekspor ke excel, ekspor ke pdf, atau bisa di-share ke WA. Ini merupakan fitur kecil yang seharusnya bisa selesai dalam 2-4 jam.

8. Penambahan Laporan

Ketika transaksi semakin banyak, kebutuhan akan laporan juga akan semakin berkembang. Software yang bagus memiliki fitur report designer. Pengguna dapat membuat laporan baru sendiri tanpa harus memanggil software developer. Jika fitur report designer tidak ada, maka programmer harus membuatkannya.

9. Penambahan Notifikasi

Terkait dengan workflow, biasanya ada notifikasi yang dikirimkan ke pengguna ketika ada task baru. Sebelum WhatsApp membuka API-nya, notifikasi dikirimkan melalui email, sms, dan in-app. API WhatsApp dibuka, pengguna juga membutuhkan notifikasi melalui media ini.

10. Penambahan Tampilan Info dari Data yang Ada

Tabel di database dapat memiliki informasi yang banyak. Tidak semua informasi itu ditampilkan dalam 1 halaman aplikasi. Adakalanya pengguna ingin menampilkan data yang belum terlihat di menu tertentu.

Service Level Agreement (SLA)

Sebelum masuk ke bagian penawaran maintenance, kita perlu pahami dulu apa itu Service Level Agreement (SLA). SLA jika diterjemahkan ke dalam Bahasa Indonesia berarti Kesepakatan Tingkat Layanan. Kesepakatan ini mencakup apa saja layanan yang kita berikan, dan acuan mengenai standar kualitasnya.

Contoh paling mudah adalah SLA dari server hosting. Provider hosting biasanya mencantumkan bahwa garansi uptime selama 99.993% setahun. Ini adalah SLA. Begitu pula dengan layanan maintenance aplikasi kita nanti. Kita perlu mendefinisikan SLA dari layanan maintenance yang ditawarkan.

Saya mempelajari ini dari salah satu perusahaan IT join venture antara perusahaan Indonesia dengan Jepang. Pada saat menjadi vendor di sana, ada kontrak maintenance yang kami kerjakan. Di kontrak tersebut melampirkan adanya SLA. Model ini saya adopsi di perusahaan saya.

Ada 3 kolom pada tabel SLA kontrak saya pada saat itu, yaitu:
1. Jenis Pekerjaan – jenis pekerjaan maintenance yang saya sediakan.
2. Maks. Waktu Respon – ini adalah waktu maksimal tim saya harus merespon issue dari pengguna. Ini cukup respon saja, tidak termasuk menyelesaikan issue-nya.
3. Maks. Waktu Penyelesaian Issue – ini adalah waktu maksimal tim harus menyelesaikan issue yang terjadi.

Contoh dari SLA milik saya adalah sebagai berikut:

SLA di atas adalah jenis issue dan pekerjaan tambahan yang menjadi lingkup maintenance saya. Ini bukan hal yang baku, rekan-rekan dapat mengadopsi dan memodifikasinya sesuai dengan kebutuhan.

Konsep Maintenance Saya

Setelah memahami SLA di bagian sebelumnya, sekarang kita coba merumuskan penawaran maintenance yang cocok. Konsep yang saya sampaikan ini, juga diadopsi dari perusahaan lain. Saya mengadopsi dari principal produk software dari Eropa. Saya yakin perusahaan software lain juga menggunakan konsep yang kurang lebih sama.

Konsepnya adalah dengan menggunakan kuota (man hours) layanan. Di bagian sebelumnya, kita sudah memiliki tabel SLA. Di sana tertulis berapa lama maksimal waktu yang dibutuhkan untuk menangani issue yang muncul. Konsep ini seperti pulsa, kita beli pulsa Rp10.000, digunakan SMS terpotong Rp350, digunakan beli kuota internet terpotong Rp5000, dst.

Pelanggan harus membeli kuota maintenance ini. Saya buat paket tahunannya. Paket 500, 250, atau 100 man hours per tahun. Ketika user membutuhkan laporan baru, yang membutuhkan waktu penyelesaian 4 jam, maka kuota yang dibeli berkurang 4 jam.

Lama kontrak maintenance saya buat 1 tahun. Selama 1 tahun kuota masih dapat digunakan. Jika sudah 1 tahun, bisa diperpanjang atau bisa tidak. Jika diperpanjang, saldo kuota diakumulasi dengan kuota yang baru. Jika tidak diperpanjang, kuota hangus.

Untuk termin pembayaran, sebisa mungkin dibayar di depan. Ini akan membantu cashflow perusahaan. Jika tidak di depan, bisa dibayar per 6 bulan atau 3 bulan. Coba berikan diskon jika bayar 1 tahun di depan. Contohnya untuk maintenance 1 tahun, jika dibayar per 6 bulan harga Rp30 juta, tapi kalo full di depan harga menjadi Rp27 juta (diskon 10%).

Penutup

Pekerjaan maintenance software perlu dilakukan agar software tetap bebas bug, update terhadap perkembangan bisnis, dan ada peningkatan performa. Selain untuk produk, maintenance juga dapat menjadi sarana agar kita tetap terhubung dengan pelanggan. Jadi, pastikan kita memberikan jasa maintenance terbaik untuk mereka.