Nama jabatan jarang bisa menggambarkan bagaimana rasanya menjalani pekerjaan itu sehari-hari. "System Analyst" atau "Analis Sistem" terdengar teknis dan agak abstrak, padahal kenyataannya jauh lebih beragam, dan jauh lebih manusiawi, dari sekadar nama jabatannya. Pekerjaan ini adalah campuran antara mendengarkan, menerjemahkan, mendokumentasikan, dan memecahkan masalah, tersebar di berbagai meeting dengan orang-orang yang punya latar belakang sangat berbeda.
Supaya lebih konkret, berikut gambaran realistis satu hari kerja seorang Analis Sistem Informasi (SI) di perusahaan skala menengah yang sedang meluncurkan sistem internal baru.
08.30 Cek Ticket dan Chat yang Masuk Semalam
Hari biasanya dimulai dengan scroll cepat ticket queue dan chat Slack yang menumpuk setelah jam kerja kemarin selesai. Nggak semua ticket butuh langsung dikerjakan, tapi bagian penting dari job ini adalah triase: mana issue yang urgent, mana bug kecil yang bisa dicatat untuk nanti, dan mana yang sebenarnya feature request yang "nyamar" jadi laporan bug.
Ritual pagi ini penting karena menentukan prioritas sebelum hari mulai padat dengan meeting, kebiasaan yang dibangun sejak awal oleh kebanyakan analis dan jarang ditinggalkan.
09.00 Meeting Requirement dengan Stakeholder
Meeting pertama hari itu adalah dengan tim finance, yang minta perubahan di alur approval pengeluaran pada sistem internal. Di sinilah core skill dari role ini kelihatan jelas: dengerin apa yang tim bisnis anggap sebagai masalah, lalu ngasih follow-up question yang tepat buat nemuin apa yang sebenarnya mereka butuhkan.
Tim finance bilang masalahnya adalah "proses approval-nya kelamaan." Analis yang bagus nggak langsung terima mentah-mentah, mereka gali lebih dalam soal kenapa: apakah ini masalah routing? Notifikasi yang nggak sampai? Terlalu banyak tahap approval? Meeting berakhir dengan gambaran yang lebih jelas, tapi belum jadi solusi utuh, itu baru muncul di langkah berikutnya.
10.30 Dokumentasi Requirement
Balik ke meja kerja, analis mengubah catatan meeting jadi requirement yang terstruktur: current-state process map, pain points, dan usulan future-state workflow. Di sinilah tools kayak flowchart, wireframe, atau diagram proses sederhana berperan, visual yang bisa dipahami baik oleh tim bisnis maupun tim development tanpa harus pakai bahasa teknis yang sama.
Dokumentasi memang nggak terlihat keren, tapi bisa dibilang inilah output paling penting dari role ini. Dokumentasi requirement yang berantakan adalah salah satu alasan paling umum proyek software gagal memenuhi ekspektasi, makanya analis sangat hati-hati di tahap ini.
12.00 Lunch Sambil Sync Singkat dengan Tim Dev
Sambil lunch, seorang developer nanya soal requirement yang dikirim minggu lalu, soal gimana sistem harusnya handle satu edge case (kasus khusus). Klarifikasi lima menit sekarang bisa menghemat bolak-balik yang jauh lebih panjang nanti. Analis sering jadi lapisan penerjemah yang terus-menerus antara maksud bisnis dan implementasi teknis, dan penerjemahan itu nggak berhenti begitu dokumen requirement dikirim.
13.00 Testing Fitur yang Baru Selesai Dibangun
Siangnya, analis testing fitur yang baru selesai dibangun tim dev di sprint kemarin, sistem notifikasi baru untuk approval yang pending. Testing bukan sekadar klak-klik fitur, Ini soal membandingkan apa yang dibangun dengan apa yang sebenarnya diminta, ngecek edge case, dan mastiin perbaikan ini nggak bikin bagian lain jadi rusak.
Ini cukup beririsan sama kerjaan QA, pengingat bahwa analis SI dan tim QA sering kolaborasi erat, meski peran keduanya nggak identik.
14.30 Narik Data untuk Laporan ke Leadership
Pihak leadership minta laporan singkat soal berapa lama proses approval berlangsung di tiap divisi, buat validasi apakah keluhan tim finance memang mencerminkan pola yang lebih luas. Analis nulis SQL query ke database sistem, narik data yang relevan, lalu bikin tabel ringkasan dan chart sederhana.
Ini contoh bagus soal gimana role ini memadukan skill teknis dengan business judgment, query-nya sendiri simpel, tapi tahu apa yang perlu diukur dan gimana menyajikannya dengan jelas justru bagian yang lebih susah dan lebih penting.
15.30 Update Status Proyek
Meeting status singkat bareng project manager dan beberapa analis lain bahas posisi proyek saat ini: requirement sudah terdokumentasi, satu fitur lagi di tahap testing, dan ada request baru yang antri dari meeting finance pagi tadi. Sebagian dari kerjaan ini sesederhana tetap terlihat dan bisa diprediksi, stakeholder lebih percaya sama analis yang aktif komunikasi ketimbang yang menghilang di antara meeting.
16.15 Review Dokumentasi Sistem
Sebelum wrap up hari itu, analis update dokumentasi sistem internal biar mencerminkan perubahan alur approval yang lagi berjalan. Kerjaan beres-beres kayak gini gampang kelewat pas lagi kejar deadline, tapi dokumentasi yang usang diam-diam buang waktu tim berbulan-bulan setelahnya, makanya kebanyakan analis berpengalaman selalu menyisihkan waktu buat ini, bahkan di hari sesibuk apa pun.
17.00 Menyusun Rencana Besok
Hari berakhir dengan daftar singkat buat besok: follow up ke finance soal temuan data, review pertanyaan developer soal requirement baru, dan persiapan demo di akhir minggu. Nggak ada yang dramatis, cuma kerjaan dasar yang konsisten dan tenang, yang jaga peluncuran sistem tetap sesuai rencana.
Apa yang Terlihat dari Satu Hari Ini
Perhatikan apa yang nggak ada di hari ini: hampir nggak ada coding langsung. Sebaliknya, hari ini justru dibangun dari mendengarkan, dokumentasi, testing, narik data, dan komunikasi, kombinasi skill analitis dan interpersonal yang jauh lebih dominan dibanding eksekusi teknis aja.
Inilah inti yang membedakan Sistem Informasi dari bidang-bidang yang lebih murni teknis: nilai lebihnya bukan pada siapa yang nulis kode paling banyak, tapi mastiin hal yang tepat yang dibangun, dan semua orang, dari finance, tim dev, sampai leadership paham alasannya.
