Skill yang Menjembatani Kerja Teknis dan Dampak Bisnis (Pelajaran dari Maria Mouschoutzi)

Belajar dari Maria Mouschoutzi: cara membumikan AI/LLM, memilih use case yang tepat, dan mengubah analisis data menjadi keputusan bisnis lewat komunikasi.

DAFTAR ISI

Mengapa “AI” terasa ada di mana-mana (dan kenapa itu bikin banyak orang salah paham)

Kalau Anda aktif di dunia teknologi beberapa tahun terakhir, Anda pasti merasakan satu hal: label “AI” mendadak ditempel di mana-mana. Produk machine learning lama yang dulu dipasarkan sebagai “otomatisasi”, “statistik”, atau “predictive analytics”, kini sering tampil ulang sebagai “AI” — seolah-olah semua yang pakai model otomatis langsung berubah jadi sihir modern.

Maria Mouschoutzi, Data Analyst sekaligus Project Manager dengan latar Operations Research, Mechanical Engineering, dan optimisasi supply chain maritim, melihat fenomena ini sebagai pedang bermata dua. Di satu sisi, hype membuat banyak orang tertarik belajar. Di sisi lain, hype juga menciptakan ekspektasi yang tidak realistis—terutama di kalangan pengguna bisnis non-teknis yang membayangkan AI sebagai “black-box superintelligence” yang selalu benar dan bisa menjawab apa pun.

Intinya sederhana: begitu kita memahami apa itu AI (dan apa yang bukan), kita jadi lebih jernih memilih use case, lebih rapi merancang solusi, dan lebih tenang saat menjelaskan batasan sistem kepada stakeholder. Dan di situlah “dampak bisnis” mulai terasa nyata—bukan di slide presentasi, tapi di keputusan yang benar-benar berubah.

Profil singkat: gabungan riset, industri, dan kemampuan “membumikan” hal rumit

Dalam percakapan di seri Author Spotlight, Maria digambarkan sebagai profesional yang menggabungkan pengalaman industri dengan analitik berbasis riset. Fokusnya bukan sekadar “membangun model”, tetapi menciptakan decision-support tools, merapikan proses, serta menerjemahkan insight agar dipahami tim teknis maupun non-teknis.

Buat pembaca Indonesia, kombinasi peran Data Analyst + Project Manager ini sangat relevan. Banyak proyek analisis data di perusahaan—mulai dari e-commerce, logistik, manufaktur, sampai instansi publik—gagal bukan karena timnya “kurang pintar”, melainkan karena terjadi miskomunikasi: masalah bisnis tidak didefinisikan dengan rapi, batasan data tidak dibahas sejak awal, atau hasil model tidak bisa “dibaca” oleh pengambil keputusan.

“Thinking” vs “Reasoning” pada AI: kenapa beda istilah bisa beda keputusan

Salah satu tulisan Maria menyoroti “semantic gap”—celah makna antara cara manusia memahami “berpikir/bernalar” dan cara mesin menghasilkan jawaban. Di lapangan, celah ini sering jadi sumber salah paham. Banyak orang mendengar kata “reasoning” lalu menganggap model benar-benar bernalar seperti manusia. Padahal, yang kita sebut Large Language Models (LLMs) adalah sistem yang sangat kuat dalam menghasilkan teks yang terdengar meyakinkan, tetapi tetap punya keterbatasan mendasar.

Maria menekankan: LLMs sangat bagus untuk sebagian pekerjaan—misalnya merangkum, menyusun email, atau membantu draft—tetapi tidak selalu andal untuk kalkulasi kompleks atau analisis sebab-akibat bertingkat. Karena itu, “paham batasan” bukan sekadar pengetahuan teknis; ini adalah kemampuan bisnis: menghindari keputusan salah akibat overtrust.

Hype AI dan “baggage” dari warisan sci-fi

Menurut Maria, banyak “beban narasi” tentang AI terbentuk dari sci-fi: robot supercerdas, mesin yang memahami dunia, sistem yang punya niat. Narasi ini membuat orang mudah terbawa suasana dan lupa pada kemampuan AI saat ini. Dalam konteks organisasi, yang paling rentan adalah pengguna bisnis non-teknis—mereka sering berasumsi AI itu kotak hitam yang selalu benar.

Ini bukan kesalahan mereka. Masalahnya, kita jarang membahas AI secara “membumi”: apa inputnya, apa batas datanya, kapan ia bisa halu, dan apa mekanisme kontrolnya. Di sinilah AI generatif harus dipahami sebagai alat, bukan oracle.

Cara kerja praktis: memisahkan “teks yang meyakinkan” dari “hasil yang terverifikasi”

Salah satu kebiasaan yang bisa Anda adopsi dari cara berpikir Maria adalah memisahkan dua hal:

• Jawaban yang “terasa benar” (fluent, meyakinkan, rapi)

• Jawaban yang benar-benar benar (dapat diuji, dihitung, dilacak sumbernya)

Dalam proyek nyata, pemisahan ini mengubah desain sistem. Alih-alih membiarkan model menjawab semua hal, Anda membagi sistem menjadi komponen-komponen yang masing-masing punya tugas jelas: retrieval, pola bahasa, dan eksekusi deterministik (misalnya kalkulasi, query database, atau validasi aturan).

Contoh yang sangat “kena” di dunia kerja: RAG + komponen eksekusi

Maria memberi contoh: bila Anda butuh aplikasi RAG untuk mencari dokumentasi teknis tertentu dan melakukan kalkulasi berdasarkan informasi di dokumen tersebut, Anda sebaiknya menambahkan komponen eksekusi kode (terminal / runtime) untuk menghitung—bukan menyerahkan kalkulasi ke model.

Konsep Retrieval-Augmented Generation (RAG) sendiri sudah banyak dibahas sebagai pendekatan yang menggabungkan model bahasa dengan mekanisme retrieval dari sumber eksternal. Paper yang sering dijadikan rujukan adalah Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, yang menunjukkan bagaimana retrieval dapat membantu menghasilkan jawaban yang lebih spesifik pada tugas yang “knowledge-intensive”.

Agar lebih konkret, bayangkan skenario Indonesia berikut:

• Tim operasional logistik punya SOP tarif: “Jika berat volumetrik > berat aktual, pakai berat volumetrik.”

• Dokumen SOP ada di PDF internal.

• Customer service ingin jawaban cepat: “Berapa ongkir untuk paket A?”

Kalau Anda hanya mengandalkan LLM, ia bisa:

• Mengutip SOP dengan benar, tapi salah hitung.

• Atau menghitung benar, tapi mengutip aturan yang keliru.

• Atau dua-duanya tampak meyakinkan… tapi salah.

Dengan desain yang lebih matang, sistem bisa menjadi:

1. Retrieval: ambil potongan SOP relevan (RAG).

2. Ekstraksi parameter: berat, dimensi, zona, jenis layanan.

3. Eksekusi deterministik: hitung rumus ongkir di komponen yang bisa diuji.

4. Penyajian: LLM menyusun jawaban yang rapi + menyebut dasar aturan.

Pendekatan ini bukan hanya soal teknis. Ini cara mengubah AI menjadi “alat kerja” yang aman untuk bisnis.

Jika Anda ingin menempatkan aspek risiko dan kepercayaan ke dalam desain sejak awal, rujukan yang banyak dipakai organisasi adalah NIST AI Risk Management Framework (AI RMF 1.0).

• Kembangkan aplikasi online lebih cepat dengan bantuan AI—mulai disini
• Jasa Pembuatan Aplikasi Smartphone (Gawai) Android OS
• Jasa Backlink DoFollow Berkualitas Dari Berbagai Topik
• Jasa Renovasi/Perombakan Tampilan Situs Web Dinamis dan Statis
• Jasa Pembuatan Hingga Kustomasi Aplikasi Berbasis Website

Produk & Layanan Kami

Dari obrolan “water cooler” ke edukasi publik: mengapa miskonsepsi itu menular

Inspirasi seri “Water Cooler Small Talk” versi Maria datang dari obrolan santai di kantor dan cerita teman-temannya. Ia memperhatikan pola yang sangat manusiawi: demi menghindari konflik, orang sering membiarkan klaim yang salah lewat begitu saja. Niatnya baik—cuma ngobrol santai—tapi efeknya bisa panjang: miskonsepsi menyebar, lalu dianggap fakta.

Contoh yang memicu Maria menulis satu artikel penuh adalah klaim: “Kalau main roulette cukup lama, pada akhirnya akan menang karena peluangnya 50/50 dan nanti bakal seimbang.” Ini terdengar logis untuk orang awam, tapi jelas bermasalah. Pada kejadian independen, hasil masa lalu tidak mengubah peluang kejadian berikutnya—itulah alasan mengapa konsep seperti law of large numbers sering disalahpahami.

Kalau Anda butuh rujukan yang enak untuk dipahami, video Law of large numbers menjelaskan bahwa proporsi hasil akan mendekati nilai harapan seiring jumlah percobaan membesar—bukan berarti “kekalahan pasti dibalas kemenangan” di putaran berikutnya.

Di sisi psikologi kognitif, miskonsepsi ini sering dijelaskan sebagai bias bernama “gambler’s fallacy”. Definisi ringkasnya bisa Anda lihat di APA Dictionary of Psychology — gambler’s fallacy.

Mengapa analogi ini relevan untuk AI?

Karena pola miskonsepsi yang sama terjadi pada AI—bahkan lebih parah. AI terdengar canggih, bahasa yang dihasilkan rapi, dan orang sering percaya diri saat menjelaskan sesuatu yang tidak mereka pahami. Kombinasi “percaya diri + kompleksitas” adalah resep sempurna untuk misinformation.

Pelajarannya buat tim data:

• Jangan hanya membangun model; bangun pemahaman.

• Jangan hanya memberi output; beri konteks.

• Jangan hanya bicara akurasi; bicara juga batasan.

Kalau Anda pernah menulis materi edukasi di kantor—misalnya untuk tim sales atau manajemen—Anda akan merasakan betapa pentingnya komunikasi data yang rapi, tidak menggurui, tapi tetap tegas.

Proses menulis artikel teknis ala Maria: konsep → dataset → code → cerita

Maria menggambarkan prosesnya dengan struktur yang sangat praktis (dan jujur). Setiap tulisan teknis dimulai dari satu konsep yang ingin ia jelaskan: memakai library tertentu, atau menyusun masalah dengan Python. Lalu ia mencari dataset yang pas untuk mendemonstrasikan konsep tersebut.

Tahap 1 — Menentukan konsep teknis (yang “worth it” untuk pembaca)

Konsep yang dipilih Maria biasanya spesifik, misalnya:

• Cara menyusun problem operations research di Python

• Cara memakai library untuk visualisasi atau rute laut (searoute)

• Cara memanggil API (dan menggeneralisasi pola itu)

Tahap 2 — Dataset: bagian paling sulit dan paling menentukan

Maria menyebut: menemukan dataset open-source yang bebas dipakai, lengkap, dan menarik untuk cerita, adalah bagian yang paling menantang dan memakan waktu. Banyak dataset tersedia, tapi tidak semuanya “bercerita”.

Di titik ini, pembaca Indonesia punya banyak opsi yang legitim:

• Untuk dataset global yang sangat sering dipakai latihan, Anda bisa mulai dari UCI Machine Learning Repository.

• Untuk data publik Indonesia, ada Portal Satu Data Indonesia.

• Untuk dokumentasi dan rujukan statistik Indonesia, Anda bisa menjelajah situs resmi Badan Pusat Statistik (BPS).

Kenapa dataset memengaruhi popularitas tulisan? Karena dataset menentukan rasa cerita. “Optimisasi jadwal shift karyawan” mungkin penting, tapi bagi banyak pembaca itu terasa hambar. Sementara dataset bertema Pokémon, online retail, atau logistik terasa lebih fun—dan fun itu menurunkan hambatan belajar.

Tahap 3 — Menulis kode sampai benar-benar jalan

Setelah topik dan dataset beres, Maria menulis kode dan memastikan hasilnya benar. Ini langkah yang terlihat “lurus”, tapi sebenarnya fondasinya: tanpa kode yang jalan, tutorial akan rapuh.

Buat pembaca yang suka Python, dokumentasi resmi adalah teman terbaik—misalnya pandas User Guide yang sangat lengkap untuk kerja data di Python.

Tahap 4 — Draft: intro, premis teori, lalu step-by-step

Bagian ini yang membuat tulisan Maria terasa “hidup”:

• Ia memulai dengan alasan personal yang relatable (“saya butuh visualisasi kompleks untuk PhD…”)

• Lalu ia jelaskan manfaat praktis untuk pembaca (“kalau Anda paham pola API call ini, Anda bisa pakai ke API apa pun…”)

• Ia sisipkan teori seperlunya, tidak kebanyakan

• Lalu ia masuk ke struktur code dengan potongan (snippets) dan penjelasan langkah demi langkah

Tahap 5 — Visual yang membuat orang betah (GIF, diagram interaktif)

Maria suka menambahkan GIF screenshot untuk demo diagram interaktif. Ini detail kecil, tapi dampaknya besar: pembaca lebih “ngeh” dan artikel terasa lebih modern.

Kalau Anda mengelola konten tutorial, Anda bisa menerapkan prinsip yang sama:

• Tampilkan before-after.

• Tampilkan hasil yang bisa diverifikasi.

• Beri checkpoint: “Kalau kode Anda benar, Anda akan melihat output seperti ini…”

• Berbisnis halal bikin hati tenang. Cek caranya disini!
• Ubah idemu jadi aplikasi online siap pakai lebih cepat bersama Emergent
• Domain, Hosting, Hingga VPS Murah untuk Proyek Anda!
• Tingkatkan SEO Website Dengan Ribuan Weblink Bebagai Topik!
• Hemat Biaya Transfer Antar Bank dan Isi Saldo e-Wallet?

Promo Afiliasi

Mengapa menulis itu memperkuat karier data, bukan sekadar “berbagi”

Motivasi Maria untuk menulis mulai tumbuh sejak ia menemukan Medium dan Towards Data Science pada 2017 saat mengerjakan diploma thesis. Ia terpukau oleh banyaknya materi teknis, variasi topik, dan kreativitas storytelling—sesuatu yang berbeda dari halaman GitHub atau jawaban Stack Overflow.

Hal menariknya: Maria tidak memposisikan tulisan sebagai “pamer skill”. Ia justru suka membahas hal yang dulu ia sendiri anggap sulit. Dengan mengubah topik yang kompleks menjadi versi yang lebih sederhana dan bahkan fun, ia membantu orang berani mulai belajar. Dan di saat yang sama, ia melatih dirinya untuk benar-benar paham, karena mengajar orang lain memaksa Anda menutup “bagian yang ambigu”.

Buat profesional Indonesia—terutama yang sedang membangun personal brand di AI untuk bisnis—ini strategi yang sangat masuk akal:

• Menulis membuat Anda lebih tajam.

• Menulis menciptakan jejak karya yang bisa dinilai.

• Menulis memaksa Anda menyusun argumen, bukan hanya mengandalkan insting.

Skill non-teknis yang paling “mengangkat” karier data: komunikasi

Saat ditanya skill non-teknis yang ia harap ia fokuskan lebih awal, Maria menjawab lugas: komunikasi.

Kalau Anda pernah merasa “saya sudah bikin dashboard, tapi kok tidak dipakai?”, jawaban Maria akan terasa dekat. Di banyak organisasi, dampak bukan ditentukan oleh seberapa canggih model Anda, tapi oleh seberapa jelas orang lain memahami nilai kerja Anda.

Kenapa komunikasi itu “jembatan” antara data dan keputusan

Komunikasi di peran data bukan soal berbicara lancar. Ini soal:

• Menerjemahkan angka menjadi narasi yang bermakna

• Mengaitkan insight dengan KPI yang dipedulikan manajemen

• Menunjukkan trade-off dan risiko, bukan menyembunyikannya

• Membuat rekomendasi yang bisa ditindaklanjuti

Operations Research sendiri sering dipandang sebagai disiplin “membuat keputusan lebih baik lewat pemodelan dan optimisasi”. Definisi yang mudah dipahami bisa Anda temukan di INFORMS — Operations Research & Analytics.

Nah, komunikasi adalah bagian yang membuat “insight” itu benar-benar sampai ke meja keputusan.

Bahasa yang dipahami bisnis: dari metrik teknis ke hasil yang dirasakan

Di dunia data, kita gampang tergoda membicarakan:

• RMSE, precision-recall, AUC

• hyperparameter tuning

• feature importance

• embedding, vector search

Semuanya penting—tetapi untuk banyak stakeholder, itu terdengar seperti bahasa asing.

Yang sering lebih “masuk” untuk bisnis:

• “Waktu proses klaim turun 20%”

• “Akurasi prediksi stok naik, sehingga stockout berkurang”

• “Biaya retur turun karena rekomendasi produk lebih relevan”

• “Waktu tim CS menjawab tiket lebih cepat karena sistem pencarian dokumen lebih akurat”

Agar terstruktur, Anda bisa memakai pola komunikasi sederhana berikut:

1. Masalah: apa yang menghambat hari ini?

2. Dampak: apa konsekuensinya (biaya/waktu/risiko)?

3. Temuan: apa yang data katakan (dengan bukti)?

4. Rekomendasi: apa yang harus dilakukan, oleh siapa, kapan?

5. Risiko & batasan: kondisi apa yang bisa membuat rekomendasi meleset?

Pola ini membuat kerja data governance dan manajemen proyek lebih nyambung, karena stakeholder melihat “benang merah” dari data ke tindakan.

• Qur’an Camp (Healing with Qur’an together)
• Gap Year With Quran: 1 Tahun Mutqin 30 Juz
• Healing With Quran: 1 Bulan Bersama Al Quran
• Pesantren Tahfidz SMP/SMA: 3 Tahun Mutqin 30 Juz

Promo Afiliasi

Checklist praktis: cara membangun komunikasi yang menghasilkan dampak

Agar bagian ini tidak hanya terasa inspiratif, berikut checklist yang bisa langsung Anda coba di pekerjaan:

1) Mulai dari pertanyaan bisnis, bukan dari model

• Apa keputusan yang ingin dibantu?

• Apa opsi yang tersedia (A/B/C)?

• Apa definisi “sukses” versi bisnis?

2) Gunakan data untuk memperjelas trade-off

Alih-alih berkata “model saya akurat”, coba:

• “Kalau kita ingin recall tinggi, false positive juga naik. Ini artinya tim verifikasi perlu kapasitas tambahan.”

3) Buat output yang “bisa dipakai” besok pagi

• Ringkasan 5–7 bullet, bukan 20 slide

• Satu grafik utama yang menjawab inti pertanyaan

• Satu rekomendasi yang jelas (bukan “tergantung”)

4) Jelaskan batasan sejak awal (agar Anda tidak jadi kambing hitam)

Ini penting di era AI. Anda bisa menuliskan batasan seperti:

• Data historis belum mencakup musim promo tertentu

• Distribusi pelanggan berubah setelah fitur baru rilis

• Model tidak menghitung faktor eksternal (cuaca, kebijakan, kompetitor)

Untuk konteks AI generatif, NIST juga merilis panduan pendamping AI RMF yang khusus membahas risiko Generative AI: NIST AI 600-1 — Generative AI Profile.

5) Latih “terjemahan dua arah”

Komunikasi yang kuat itu dua arah:

• Anda menerjemahkan teknis → bisnis

• Anda juga menerjemahkan bisnis → teknis (problem framing, definisi label, asumsi)

Jika Anda sedang membangun konten di rizalconsulting.id, bagian ini bisa diangkat menjadi seri: menggunakan big data untuk pengambilan keputusan, bagaimana bisnis memanfaatkan AI, dan AI bisa mengganggu bisnis—karena pembaca biasanya mencari panduan yang bisa dipakai, bukan teori yang menggantung.

7 pelajaran yang bisa Anda bawa ke proyek berikutnya

Dari cerita dan cara berpikir Maria Mouschoutzi, ada tujuh pelajaran yang terasa sangat aplikatif untuk profesional data di Indonesia:

1. Jangan terhipnotis label “AI”—pahami mekanismenya dulu.

2. Pisahkan “jawaban meyakinkan” dari “jawaban terverifikasi”.

3. Bangun solusi dari komponen: retrieval, eksekusi, dan penyajian.

4. Jadikan miskonsepsi sebagai bahan edukasi, bukan bahan debat.

5. Dataset bukan detail kecil—ia menentukan kualitas cerita dan kualitas pembelajaran.

6. Menulis melatih pemahaman dan memperkuat portofolio secara alami.

7. Skill komunikasi adalah multiplier: ia membuat kerja teknis berubah menjadi dampak bisnis.

Kalau Anda bekerja di bidang data science atau sedang belajar machine learning, Anda tidak perlu menunggu jadi “pakar” dulu untuk mulai membangun dampak. Mulailah dari hal yang sederhana: jelaskan satu konsep dengan jelas, buat satu demo yang jalan, lalu tunjukkan manfaatnya dengan bahasa yang dimengerti bisnis. Sisanya akan mengikuti.

Atribusi

Artikel ini merupakan adaptasi Bahasa Indonesia dari tulisan The Skills That Bridge Technical Work and Business Impact, dipublikasikan 14 Desember 2025 oleh tim redaksi Towards Data Science.

Siap Menjadikan Insight Jadi Eksekusi yang Rapi?

Kalau artikel tadi menekankan bahwa komunikasi adalah jembatan antara kerja teknis dan dampak bisnis, tantangan berikutnya biasanya lebih “mendarat”: siapa yang memastikan semuanya benar-benar jalan setiap hari? Karena pada akhirnya, ide bagus dan laporan rapi tetap butuh eksekusi—data diinput tepat waktu, riset terkumpul, konten terkelola, dan dokumen siap dipakai tim.

Di Rizal IT Consulting, Anda bisa mendapatkan bantuan asisten virtual & freelancer online yang fokus pada hasil yang langsung terasa untuk UMKM dan profesional bisnis—terutama di bidang kuliner, jasa, retail, edukasi, dan properti:

• VA Admin & Admin Konten: rapikan dokumen, susun materi, follow-up tugas rutin agar alur kerja tidak putus.

• Data Entry & Olah Data Sederhana: input data rapi, validasi dasar, rekap, dan format laporan yang mudah dibaca.

• Riset Cepat untuk Keputusan: rangkum opsi, bandingkan sumber tepercaya, dan siapkan poin-poin yang siap dibawa ke rapat.

• Dukungan Konten: draft/copy ringan, perapihan naskah, ringkasan, dan materi posting yang konsisten.

Anda bisa mulai kecil dulu: delegasikan 1–2 pekerjaan yang paling menyita waktu—lalu lihat seberapa cepat operasional jadi lebih lega dan keputusan jadi lebih cepat diambil.

Rizal IT Consulting
Email:
WhatsApp: 0857-1587-2597 | 0813-8229-7207
Operasional: Sabtu – Kamis, 08.00 – 17.30 WIB

Layanan tersedia online untuk seluruh Indonesia.

Blog ini didukung oleh pembaca. Rizal IT Consulting dapat memperoleh komisi afiliasi ketika Anda bertransaksi di tautan yang ditampilkan di situs ini. Ikuti kami juga di Google News Publisher untuk mendapatkan notifikasi artikel terbaru. Info lanjut, kolaborasi, sponsorship dan promosi, ataupun kerjasama, bisa menghubungi: 0857-1587-2597 | 0813-8229-7207 | .