Daftar Isi:
- Business Analyst, System Analyst, dan Peran Sekitarnya
- Belajar Lewat Satu Proses Bisnis
- Alat Berpikir dan Dokumen yang Perlu Dikenal
- Contoh Kebutuhan: Lemah dan Kuat
- Jalur Belajar dalam 5 Tahap
- Kemampuan Nonteknis yang Menentukan
- Portofolio Berupa Paket Dokumen
- Sertifikasi yang Sering Dilirik
- Pintu Masuk dan Cara Melamar
- Kesalahan yang Sering Terjadi
- FAQ
- Kesimpulan
Di banyak perusahaan, masalah terbesar proyek IT bukan kode yang salah, melainkan kebutuhan yang salah dipahami. Developer membangun apa yang tertulis, pengguna ingin apa yang dibutuhkan, dan keduanya tidak selalu sama. Di situlah business analyst dan system analyst bekerja sebagai penerjemah.
Artikel ini menyusun roadmap bagi pemula yang tertarik pada jalur IT bisnis dan sistem: memahami perbedaan perannya, belajar memetakan proses bisnis, menulis kebutuhan yang jelas, membuat diagram, dan membangun portofolio berupa paket dokumen. Kemampuan coding tidak menjadi syarat awal.
Business Analyst, System Analyst, dan Peran Sekitarnya
Nama jabatan di bidang ini sangat bervariasi antar perusahaan dan sering tumpang tindih. Anggap tabel berikut sebagai gambaran umum, lalu baca uraian tugas tiap lowongan.
| Peran | Pertanyaan utama | Hasil kerja khas |
|---|---|---|
| Business analyst | Masalah bisnis apa yang perlu diselesaikan dan apa yang dibutuhkan? | Peta proses, daftar kebutuhan, dan usulan perbaikan |
| System analyst | Bagaimana sistem harus bekerja agar kebutuhan itu terpenuhi? | Spesifikasi fungsional, alur sistem, dan model data |
| Business systems analyst | Gabungan keduanya, dari kebutuhan bisnis sampai spesifikasi sistem | Dokumen kebutuhan dan spesifikasi yang saling terhubung |
| ERP functional consultant | Bagaimana proses perusahaan dipetakan ke modul perangkat lunak ERP? | Konfigurasi modul dan panduan penggunaan |
| Product owner atau product analyst | Fitur apa yang paling bernilai untuk dikerjakan lebih dulu? | Daftar prioritas dan keputusan produk |
Belajar Lewat Satu Proses Bisnis
Cara paling efektif adalah memilih satu proses nyata yang bisa Anda amati, lalu menganalisisnya dari awal sampai akhir. Contohnya pemesanan barang di sebuah toko, pengelolaan inventaris di sekolah, atau peminjaman buku di perpustakaan. Pilih yang cukup kecil agar bisa Anda selesaikan, tetapi cukup nyata sehingga ada masalah sungguhan di dalamnya.
Proses yang sama akan Anda bawa melewati semua tahap: memahami kondisi sekarang, menulis kebutuhan, membuat diagram, merancang tampilan, dan menyusun skenario uji. Hasilnya adalah satu paket dokumen yang utuh.
Alat Berpikir dan Dokumen yang Perlu Dikenal
| Alat atau dokumen | Fungsinya | Siapa yang membaca |
|---|---|---|
| Peta proses (BPMN) | Menggambarkan urutan kegiatan, keputusan, dan pihak yang terlibat | Pemilik proses dan tim IT |
| User story dan kriteria penerimaan | Menuliskan kebutuhan dari sudut pengguna dan batas kapan dianggap selesai | Developer, penguji, dan pemilik produk |
| Use case | Menjelaskan interaksi pengguna dengan sistem langkah demi langkah | Developer dan penguji |
| Diagram hubungan data (ERD) | Menunjukkan data apa yang disimpan dan hubungannya | Developer dan administrator database |
| Wireframe | Menunjukkan kerangka tampilan sebelum dibangun | Pengguna dan desainer |
| Skenario uji penerimaan pengguna (UAT) | Memastikan sistem sesuai kebutuhan sebelum dipakai | Pengguna bisnis dan penguji |
Contoh Kebutuhan: Lemah dan Kuat
Kebutuhan yang kabur adalah penyebab utama proyek tersendat. Berikut contoh fiktif untuk sistem pemesanan barang.
| Kebutuhan lemah | Kebutuhan kuat |
|---|---|
| Sistem harus cepat. | Halaman daftar pesanan menampilkan hasil dalam waktu tiga detik untuk seribu data. |
| Admin bisa mengelola pesanan. | Sebagai admin gudang, saya ingin mengubah status pesanan menjadi dikirim agar pelanggan menerima pemberitahuan. |
| Laporan harus lengkap. | Laporan penjualan bulanan memuat total per produk dan dapat diunduh dalam format berkas tabel. |
Kriteria penerimaan yang baik menjawab pertanyaan: bagaimana kita tahu kebutuhan ini sudah terpenuhi? Contoh untuk story admin gudang di atas: status berubah menjadi dikirim, pelanggan menerima pemberitahuan, dan pesanan tidak bisa kembali ke status sebelumnya tanpa alasan tercatat.
Jalur Belajar dalam 5 Tahap
Perkiraan waktu mengasumsikan belajar rutin sekitar 10 sampai 15 jam per minggu. Pakai sebagai patokan kasar, karena kecepatan tiap orang berbeda.
- Memahami proses bisnis (sekitar 3 sampai 4 minggu). Wawancarai orang yang menjalankan proses itu, amati langsung, dan petakan kondisi saat ini beserta masalahnya. Biasakan bertanya "mengapa" berulang kali sampai ke akar masalah. Tanda siap: pemilik proses membenarkan peta Anda sebagai gambaran yang akurat.
- Menulis kebutuhan (sekitar 3 sampai 4 minggu). Susun user story, kriteria penerimaan, dan prioritas, misalnya dengan pengelompokan wajib, penting, dan bisa ditunda. Tanda siap: penguji bisa merancang tes hanya dari kebutuhan yang Anda tulis.
- Pemodelan (sekitar 4 sampai 6 minggu). Pelajari dasar BPMN, use case, ERD, dan SQL dasar untuk memahami data. Bagian SQL dibahas di cara jadi data analyst dari nol. Tanda siap: developer bisa membangun sistem hanya dengan membaca diagram dan spesifikasi Anda.
- Prototipe dan komunikasi (sekitar 3 sampai 5 minggu). Buat wireframe sederhana, presentasikan kepada pemangku kepentingan, dan latih menangani perubahan permintaan dengan tenang. Tanda siap: Anda bisa menjelaskan usulan ke orang nonteknis tanpa istilah yang membingungkan.
- Uji penerimaan dan serah terima (sekitar 3 sampai 5 minggu). Susun skenario uji penerimaan, kelola perubahan kebutuhan, dan tulis dokumen serah terima. Kenali juga cara kerja Agile dan Scrum serta alat pelacak tugas. Dasar pengujiannya dibahas di roadmap QA tester. Tanda siap: ada daftar skenario uji yang bisa dijalankan pengguna bisnis.
Kemampuan Nonteknis yang Menentukan
Mewawancarai
Pengguna sering menyebut solusi, bukan masalah. Tugas Anda menggali kebutuhan di balik permintaan, misalnya dengan bertanya apa yang sebenarnya ingin dicapai.
Menulis jelas
Dokumen yang ambigu menghasilkan sistem yang ambigu. Biasakan satu kalimat satu makna, hindari kata seperti cepat atau mudah tanpa ukuran.
Baca Juga:
Menjembatani dan bernegosiasi
Pihak bisnis ingin semuanya, tim teknis punya keterbatasan. Anda membantu mencari prioritas yang masuk akal bagi keduanya.
Portofolio Berupa Paket Dokumen
Portofolio di jalur ini bukan kode, melainkan dokumen yang memperlihatkan cara Anda berpikir. Gunakan proses yang Anda amati sendiri atau studi kasus fiktif, dan samarkan semua informasi sensitif jika berasal dari tempat kerja.
| Proyek | Isi | Yang dibuktikan |
|---|---|---|
| Analisis satu proses bisnis | Peta kondisi sekarang, masalah, peta kondisi usulan, dan alasan perubahan | Kemampuan memahami dan memperbaiki proses |
| Dokumen kebutuhan aplikasi kecil | Daftar user story, kriteria penerimaan, use case, dan ERD | Kemampuan menulis kebutuhan yang bisa dibangun |
| Skenario uji penerimaan | Daftar skenario, langkah, hasil yang diharapkan, dan catatan hasil | Kemampuan memastikan kebutuhan benar-benar terpenuhi |
Yang dicari perekrut dari dokumen Anda:
- Struktur yang rapi dan mudah dibaca orang nonteknis.
- Alasan di balik setiap keputusan, bukan hanya diagramnya.
- Pengakuan terhadap asumsi dan hal yang belum jelas.
Sertifikasi yang Sering Dilirik
Untuk jalur analisis bisnis, sertifikasi dari lembaga seperti IIBA, misalnya tingkat pemula ECBA, sering disebut. Ada juga sertifikasi manajemen produk dan Scrum untuk melengkapi. Sertifikasi tidak wajib dan tidak menggantikan paket dokumen yang rapi. Periksa cakupan, biaya, dan syarat terbaru di situs penyelenggara sebelum memutuskan.
Pintu Masuk dan Cara Melamar
Banyak orang masuk dari peran lain: staf administrasi, keuangan, atau operasional yang paham prosesnya, penguji perangkat lunak yang paham alur sistem, atau developer junior yang tertarik pada sisi kebutuhan. Kata kunci yang bisa dicoba antara lain junior business analyst, system analyst, IT business analyst, ERP functional consultant, atau product analyst. Seleksi biasanya mencakup studi kasus, misalnya menulis kebutuhan dari sebuah cerita proses atau menggambar alur dari deskripsi. Taruh paket dokumen di bagian atas CV, dan panduan penyusunannya ada di cara membuat CV fresh graduate. Untuk membandingkan dengan jalur lain, lihat roadmap 15 jalur karir IT.
Kesalahan yang Sering Terjadi
- Langsung membahas solusi sistem sebelum memahami masalah bisnis yang sebenarnya.
- Menulis kebutuhan yang kabur sehingga tiap orang menafsirkannya berbeda.
- Hanya berbicara dengan satu pihak dan melupakan pengguna lain yang terdampak.
- Membuat diagram yang rumit dan indah tetapi tidak bisa dipahami pembacanya.
- Menganggap pekerjaan selesai setelah dokumen diserahkan, padahal pemantauan perubahan dan uji penerimaan juga bagian tugas.
FAQ
Apa beda business analyst dan system analyst?
Business analyst berfokus pada masalah dan kebutuhan bisnis, sedangkan system analyst berfokus pada bagaimana sistem harus bekerja untuk memenuhinya. Di banyak perusahaan keduanya bercampur, jadi baca uraian tugas lowongan.
Apakah harus bisa coding?
Tidak wajib untuk banyak posisi business analyst. Namun SQL dasar dan pemahaman cara kerja aplikasi sangat membantu, terutama untuk posisi system analyst.
Apakah lulusan nonteknik bisa masuk jalur ini?
Bisa. Pemahaman domain seperti keuangan, logistik, atau pendidikan justru berharga. Yang perlu Anda tambahkan adalah kemampuan memodelkan proses dan menulis kebutuhan.
Apakah harus bergelar sistem informasi?
Tidak selalu. Banyak perekrut menilai dari paket dokumen dan cara berpikir Anda. Namun sebagian lowongan mensyaratkan jurusan tertentu, jadi baca persyaratannya.
Berapa lama dari nol sampai siap melamar?
Bagi banyak orang yang belajar rutin, kisarannya sekitar enam bulan sampai satu tahun lebih, tergantung latar belakang dan jam belajar. Angka ini hanya gambaran kasar, bukan target.
Baca Juga:
Kesimpulan
Pekerjaan analis bisnis dan sistem pada dasarnya adalah pekerjaan mengurangi salah paham. Sebuah proyek yang dimulai dengan kebutuhan yang jelas, dipahami semua pihak, dan bisa diuji hampir selalu berjalan lebih mulus daripada proyek dengan teknologi paling canggih namun kebutuhan yang kabur. Karena itu, perekrut yang berpengalaman sering lebih tertarik pada satu dokumen kebutuhan yang jernih daripada daftar alat yang panjang, sebab dokumen itu memperlihatkan cara Anda berpikir dan berkomunikasi. Mulailah minggu ini dengan mengamati satu proses sederhana di sekitar Anda, misalnya cara sebuah toko menerima pesanan, lalu gambarkan langkahnya di selembar kertas dan tuliskan tiga masalah yang Anda temukan.
