Elixir untuk Technical Leader — Bab 11 (Bonus)

Data Intelligence — Nx, Explorer, Bumblebee & Claude API

Kompetitor record data. LabaBersih harus record + analyze + recommend + act. Bab ini tentang bagaimana Elixir membuat itu mungkin dalam satu runtime — dan kapan lebih baik pakai Claude API.

Kenapa Data Intelligence Itu Moat

Setiap hari, LabaBersih memproses 6.300 order. Dari setiap order, kita tahu:

• Produk apa yang laku, di platform mana, jam berapa
• Berapa margin setelah fee + HPP + ongkir
• Kurir mana yang sering RTS
• Customer mana yang repeat, dan mana yang berisiko
• Tren stok: produk mana yang menuju habis, mana yang numpuk

Semua data ini sudah ada di database. Tapi data mentah itu gak ada gunanya kalau cuma disimpan.

Ada 4 level kematangan data:

Kebanyakan SaaS Indonesia masih di Level 1-2. Kalau LabaBersih bisa sampai Level 3-4, itu moat yang susah ditiru. Bukan karena teknologinya sulit — tapi karena butuh data historis + domain knowledge yang sudah kamu punya.

Kenapa Python Dominasi AI/ML — Jujur

Sebelum kita bicara Elixir untuk intelligence, kita harus jujur tentang Python. Kenapa Python jadi bahasa #1 untuk AI/ML?

Timeline Singkat

20 tahun ekosistem. Puluhan ribu library. Jutaan tutorial. Ratusan ribu model pre-trained.

Tapi di sini ada nuansa penting yang sering diabaikan:

Python itu "glue language". Python sendiri lambat. Yang cepat adalah C, C++, dan CUDA di balik layar. NumPy ditulis di C. TensorFlow di C++. PyTorch di C++ dan CUDA. Python hanya memanggil kode yang sudah ditulis di bahasa lain.

# Python: "Hitung matriks 1000x1000"
# NumPy: [panggil C code yang sudah dioptimasi]
# Hasilnya: cepat, tapi bukan karena Python-nya

# Ini persis seperti:
# Python/Elixir: "Tolong bikinin jurnal"
# PostgreSQL: [query execution di C]
# Keduanya cuma pengirim instruksi ke engine yang lebih cepat

Insight ini penting karena: kalau bahasa lain bisa juga jadi "glue" ke engine yang sama, maka Python bukan satu-satunya pilihan untuk menjalankan model. Dan di sinilah cerita Nx dimulai.

Jose Valim dan Nx — Glue yang Sama, Runtime yang Berbeda

Tahun 2021, Jose Valim (pencipta Elixir) mulai Nx — Numerical Elixir. Logikanya sederhana:

"Kalau Python bisa jadi glue ke C/CUDA, kenapa Elixir gak bisa jadi glue ke XLA (compiler yang sama yang dipake TensorFlow)?"

Dan ternyata bisa. Nx tidak mencoba menulis ulang engine numerik di Elixir. Nx memanggil engine yang sama yang dipakai Python:

# Python approach:
# Python code → NumPy → C/BLAS → CPU/GPU
# Python code → TensorFlow → XLA → CPU/GPU

# Elixir approach:
# Elixir code → Nx → EXLA → XLA → CPU/GPU
# Persis engine yang sama! Beda glue language doang.

Yang bikin ini menarik bukan kecepatan komputasinya (sama aja, karena engine-nya sama). Yang menarik adalah: satu runtime untuk web + ML.

Ekosistem Nx — Peta Lengkap

Nx bukan satu library. Ini ekosistem yang mirror Python ecosystem, tapi di atas BEAM:

Explorer — Pandas untuk Elixir

Explorer adalah library yang paling langsung berguna untuk LabaBersih. Ini seperti Pandas di Python — library untuk mengolah data tabular (tabel, spreadsheet, CSV).

Kenapa ini penting? Karena SEMUA analitik bisnis LabaBersih pada dasarnya adalah: ambil data dari database, olah, tampilkan insight.

Contoh 1: Top Produk by Revenue

alias Explorer.DataFrame, as: DF
alias Explorer.Series

# Ambil data order items dari database
order_data = Repo.all(
  from oi in OrderItem,
    join: o in Order, on: oi.order_id == o.id,
    where: o.org_id == ^org_id and o.status == "selesai",
    select: %{
      sku: oi.sku,
      product_name: oi.product_name,
      quantity: oi.quantity,
      revenue: oi.price
    }
)

# Masukkan ke Explorer DataFrame
df = DF.new(order_data)

# Analisis: top 10 produk by total revenue
top_products =
  df
  |> DF.group_by("sku")
  |> DF.summarise(
    product_name: first("product_name"),
    total_qty: sum("quantity"),
    total_revenue: sum("revenue")
  )
  |> DF.sort_by(desc: "total_revenue")
  |> DF.head(10)

# Output: DataFrame dengan 10 produk tertinggi revenue
# +-------+------------------+----------+--------------+
# | sku   | product_name     | total_qty| total_revenue|
# +-------+------------------+----------+--------------+
# | FRB01 | Forbest New 1kg  | 2,340    | 105,300,000  |
# | RTN01 | Ritrina 1 Liter  | 1,890    | 85,050,000   |
# | ...   | ...              | ...      | ...          |
# +-------+------------------+----------+--------------+

Contoh 2: RTS Rate per Kurir

# Data: semua order yang sudah shipped
shipment_data = Repo.all(
  from o in Order,
    where: o.org_id == ^org_id and o.status in ["selesai", "rts"],
    select: %{
      courier: o.courier,
      status: o.status,
      total_harga: o.total_harga
    }
)

df = DF.new(shipment_data)

rts_by_courier =
  df
  |> DF.group_by("courier")
  |> DF.summarise(
    total_orders: count("status"),
    rts_count: sum(equal("status", "rts")),
    total_value: sum("total_harga")
  )
  |> DF.mutate(rts_rate: divide("rts_count", "total_orders"))
  |> DF.sort_by(desc: "rts_rate")

# Output:
# +---------+-------------+----------+-----------+----------+
# | courier | total_orders | rts_count| total_val | rts_rate |
# +---------+-------------+----------+-----------+----------+
# | ID Exp  | 450         | 38       | 20,250,000| 8.4%     | <-- MASALAH
# | SiCepat | 1,200       | 72       | 54,000,000| 6.0%     |
# | JNE     | 2,100       | 84       | 94,500,000| 4.0%     |
# | J&T     | 2,550       | 76       | 114,750,000| 3.0%    | <-- BAGUS
# +---------+-------------+----------+-----------+----------+

Contoh 3: Margin Trend Bulanan

# Combine: revenue (dari jurnal pendapatan) - HPP (dari jurnal HPP) - fees
monthly_data = Repo.all(monthly_summary_query)

df = DF.new(monthly_data)

margin_trend =
  df
  |> DF.group_by("month")
  |> DF.summarise(
    revenue: sum("revenue"),
    hpp: sum("hpp"),
    fees: sum("platform_fees")
  )
  |> DF.mutate(
    gross_profit: subtract("revenue", "hpp"),
    net_profit: subtract(subtract("revenue", "hpp"), "fees"),
    margin_pct: divide("net_profit", "revenue")
  )

# Output: tren margin 6 bulan terakhir
# Kalau margin turun dari 18% ke 12% → ada masalah yang harus di-investigate

Bumblebee — Penilaian Jujur

Bumblebee adalah library Elixir untuk menjalankan pre-trained model dari HuggingFace. Artinya kamu bisa menjalankan model AI (text classification, sentiment analysis, summarization) langsung di Elixir, tanpa Python, tanpa API call.

# Contoh: sentiment analysis di Elixir
{:ok, model} = Bumblebee.load_model({:hf, "finiteautomata/bertweet-base-sentiment-analysis"})
{:ok, tokenizer} = Bumblebee.load_tokenizer({:hf, "vinai/bertweet-base"})

serving = Bumblebee.Text.text_classification(model, tokenizer)

# Jalankan sebagai Nx.Serving (GenServer) di Phoenix app
Nx.Serving.run(serving, "Produk bagus, pengiriman cepat!")
# => %{predictions: [%{label: "POS", score: 0.97}]}

Kedengarannya keren. Tapi saya harus jujur.

Kapan Bumblebee Masuk Akal

Claude API — Intelligence yang Praktis

Untuk LabaBersih, pendekatan yang paling masuk akal untuk Level 3 intelligence (recommend) adalah: kumpulkan data terstruktur, kirim ke Claude API, dapat insight natural language.

Arsitektur

# Flow:
# 1. Elixir query database → data terstruktur
# 2. Format jadi prompt yang jelas
# 3. Kirim ke Claude API via Req (HTTP client)
# 4. Dapat response natural language
# 5. Tampilkan di dashboard LiveView

# Gak butuh GPU. Gak butuh Python. Gak butuh Docker.
# Cuma HTTP call dari Elixir ke API endpoint.

Contoh: Weekly Business Insight

defmodule Lababersih.Intelligence.WeeklyInsight do
  @moduledoc "Generate weekly business insight via Claude API"

  def generate(org_id) do
    # 1. Kumpulkan data minggu ini
    data = collect_weekly_data(org_id)

    # 2. Format jadi prompt
    prompt = """
    Kamu adalah analis bisnis untuk toko online Indonesia.
    Analisis data 7 hari terakhir dan berikan 3-5 insight actionable.
    Jawab dalam Bahasa Indonesia. Fokus pada:
    - Tren yang perlu diperhatikan
    - Masalah yang harus segera ditangani
    - Peluang yang bisa dimanfaatkan

    DATA:
    Total order: #{data.total_orders}
    Revenue: Rp #{data.revenue}
    RTS count: #{data.rts_count} (#{data.rts_rate}%)
    Top produk: #{inspect(data.top_products)}
    Kurir bermasalah: #{inspect(data.worst_couriers)}
    Margin rata-rata: #{data.avg_margin}%
    Stok rendah: #{inspect(data.low_stock_products)}
    Perbandingan minggu lalu: revenue #{data.revenue_change}%
    """

    # 3. Kirim ke Claude API
    {:ok, response} = call_claude_api(prompt)

    # 4. Return insight
    {:ok, response.body["content"]}
  end

  defp call_claude_api(prompt) do
    Req.post("https://api.anthropic.com/v1/messages",
      headers: [
        {"x-api-key", System.get_env("ANTHROPIC_API_KEY")},
        {"anthropic-version", "2023-06-01"},
        {"content-type", "application/json"}
      ],
      json: %{
        "model" => "claude-sonnet-4-20250514",
        "max_tokens" => 1024,
        "messages" => [%{"role" => "user", "content" => prompt}]
      }
    )
  end

  defp collect_weekly_data(org_id) do
    # Query semua metrik dari database
    # Return struct dengan semua angka yang dibutuhkan
    %{
      total_orders: Orders.count_this_week(org_id),
      revenue: Orders.revenue_this_week(org_id),
      rts_count: Returns.count_this_week(org_id),
      # ... dst
    }
  end
end

Contoh Output Claude

Biaya

Sebelas ribu rupiah per bulan untuk insight yang bisa save Rp 3.8 juta dari RTS saja. ROI-nya absurd.

3 Level Arsitektur Intelligence

Gak semua intelligence butuh AI. Ini arsitektur berlapis yang pragmatis:

Level 1: Rule-Based (SQL + Elixir)

Ini fondasi. Gak butuh library tambahan. Cuma query database + logic Elixir biasa.

# Contoh: Reorder alert
def products_needing_reorder(org_id) do
  from(p in Product,
    where: p.org_id == ^org_id,
    where: p.stok <= 10,     # threshold sederhana
    where: p.is_active == true,
    order_by: [asc: p.stok],
    select: %{name: p.name, sku: p.sku, stok: p.stok}
  )
  |> Repo.all()
end

# Contoh: ABC classification
def abc_classification(org_id) do
  products = list_products_by_revenue(org_id)
  total_revenue = Enum.sum(Enum.map(products, & &1.revenue))

  products
  |> Enum.reduce({[], 0}, fn product, {acc, cumulative} ->
    new_cumulative = cumulative + product.revenue
    pct = new_cumulative / total_revenue * 100
    class = cond do
      pct <= 80  -> "A"  # Top 80% revenue
      pct <= 95  -> "B"  # Next 15%
      true       -> "C"  # Bottom 5%
    end
    {[Map.put(product, :class, class) | acc], new_cumulative}
  end)
  |> elem(0)
  |> Enum.reverse()
end

Apa yang bisa dilakukan Level 1:

• ABC-XYZ classification (produk mana yang paling penting)
• Reorder alert (stok mau habis)
• RTS rate threshold alert (kurir bermasalah)
• PKP threshold warning (omzet mendekati 4.8M)
• Aged receivables (piutang menggantung terlalu lama)
• Daily summary (ringkasan harian)

Level 2: Statistical (Nx + Explorer)

Satu level di atas. Pakai Explorer untuk analisis yang lebih sophisticated:

# Moving average untuk demand forecasting
def demand_forecast(org_id, product_id, window \\ 14) do
  # Ambil demand 30 hari terakhir
  daily_demand = get_daily_demand(org_id, product_id, 30)

  df = Explorer.DataFrame.new(daily_demand)

  # Hitung 14-day moving average
  df
  |> DF.mutate(
    ma_14: window_mean("qty_sold", window),
    std_14: window_standard_deviation("qty_sold", window)
  )
  |> DF.mutate(
    # Safety stock = 2 standard deviations
    safety_stock: multiply("std_14", 2),
    # Reorder point = (daily avg * lead time) + safety stock
    reorder_point: add(
      multiply("ma_14", 7),  # lead time 7 hari
      multiply("std_14", 2)
    )
  )
end

Apa yang bisa dilakukan Level 2:

• Demand forecasting (moving average + seasonality)
• Trend detection (margin naik/turun signifikan?)
• Anomaly detection (spike penjualan yang gak biasa)
• Customer clustering (segmentasi by behavior)
• Correlation analysis (apakah promo X naikkan revenue?)

Level 3: LLM (Claude API)

Paling atas. Kirim data terstruktur dari Level 1-2, dapat insight natural language.

# Combine semua data → kirim ke Claude → dapat insight
def generate_daily_brief(org_id) do
  # Level 1 data
  low_stock = products_needing_reorder(org_id)
  rts_alert = courier_rts_rates(org_id)
  abc = abc_classification(org_id)

  # Level 2 data
  margin_trend = margin_trend_30d(org_id)
  demand_spikes = detect_demand_spikes(org_id)

  # Level 3: Claude bikin narasi dari semua data
  prompt = build_daily_brief_prompt(%{
    low_stock: low_stock,
    rts_alert: rts_alert,
    abc: abc,
    margin_trend: margin_trend,
    demand_spikes: demand_spikes
  })

  call_claude_api(prompt)
end

Yang paling penting: ketiga level ini jalan di satu Phoenix application. Level 1 = Ecto query. Level 2 = Explorer di proses Elixir. Level 3 = HTTP call ke API. Gak ada microservice, gak ada Python server terpisah, gak ada Docker container tambahan.

Fondasi yang Harus Dibangun SEKARANG

Ini bagian yang paling penting di bab ini. Intelligence yang bagus butuh data yang bagus. Dan struktur data harus benar dari awal — bukan di-retrofit nanti.

1. Demand Snapshots Table

# Rekam demand harian per produk per gudang
# Ini bahan baku untuk forecasting, ABC-XYZ, spike detection

create table(:demand_snapshots) do
  add :org_id,        # siapa
  add :product_id,    # produk apa
  add :warehouse_id,  # gudang mana
  add :date,           # tanggal berapa
  add :qty_ordered,    # berapa yang dipesan
  add :qty_shipped,    # berapa yang dikirim
  add :source_breakdown, :map  # %{"tiktok" => 15, "shopee" => 8}
  add :is_spike,       # true kalau > 2x moving average
end

# Unique per org + product + warehouse + date
# Diisi oleh Oban job setiap malam (23:59 WIB)

Kenapa penting: Tanpa tabel ini, setiap kali mau analisis demand, kamu harus query orders + order_items + aggregate on-the-fly. Dengan snapshot, datanya sudah pre-computed dan bisa di-query langsung.

2. Consistent Timestamp Fields

# SETIAP event penting harus punya timestamp yang jelas:

orders:
  :platform_order_date  # kapan customer pesan (dari platform)
  :imported_at          # kapan masuk ke LabaBersih
  :shipped_at           # kapan dikirim (event date, bukan process date!)
  :delivered_at         # kapan sampai
  :settled_at           # kapan uang cair

return_records:
  :rts_detected_at     # kapan RTS terdeteksi
  :rts_resolved_at     # kapan RTS selesai (returned / saved)

# SEMUA dalam WIB. SEMUA diisi. JANGAN ada yang null
# kalau event-nya sudah terjadi.

Kenapa penting: "Days to cash" = settled_at - shipped_at. "RTS response time" = rts_resolved_at - rts_detected_at. Kalau salah satu timestamp kosong, metrik ini gak bisa dihitung.

3. Denormalized Counters

# Di tabel customers (sudah di-design):
customers:
  :total_orders    # gak perlu COUNT(*) setiap query
  :total_spent     # gak perlu SUM() setiap query
  :total_rts       # langsung tau RTS rate per customer
  :last_order_at   # langsung tau kapan terakhir beli

# Di tabel products:
products:
  :stok            # sudah denormalized (sum dari lots)
  :reserved_stock  # sudah di-design

# Aturan: update counter saat event terjadi (bukan query saat butuh)
# Order masuk → customer.total_orders += 1
# RTS terdeteksi → customer.total_rts += 1

Kenapa penting: Untuk dashboard real-time dan sorting (top customers, worst RTS rate), denormalized counter = instant query. Tanpa ini, setiap dashboard load = heavy aggregation.

4. Fee Breakdown per Order

# Saat ini: fee estimasi dihitung on-the-fly dari store.fee_mapping
# Problem: kalau fee_mapping berubah, estimasi lama ikut berubah
# Solusi: simpan fee breakdown per order saat ship

# Di journal_entry_lines (sudah ada order_id field):
# Setiap line punya: account_code, debit, credit, order_id
# Dari sini bisa reconstruct: per order, fee apa saja, berapa

# Ini sudah di-design di daily summary journal architecture:
# 1 jurnal per toko per hari, lines per order
# Jadi fee breakdown per order = gratis dari journal lines

5. Source Field untuk Attribution

# Setiap order HARUS punya source:
orders:
  :source   # "xlsx" / "api_tiktok" / "api_shopee" / "manual" / "webhook_scalev"

# Kenapa: attribution analysis
# "Berapa % order masuk dari XLSX vs API?"
# "Apakah order dari API lebih akurat (kurang RTS)?"
# "Channel mana yang paling banyak cancel?"

Elixir vs Python — Untuk Use Case LabaBersih

Ini bukan debat "mana yang lebih baik secara umum" (gak ada gunanya). Ini penilaian spesifik untuk apa yang LabaBersih butuh:

Penilaian Jujur — Hype vs Real

Kamu pernah bilang "kamu jangan asal iya." Berikut penilaian jujur tentang apa yang hype dan apa yang nyata di ekosistem ini:

Roadmap Intelligence LabaBersih

Berdasarkan penilaian jujur di atas, ini timeline yang pragmatis:

NOW (Phase 1-2) — Data Structure Ready

Gak ada intelligence code. Tapi struktur data harus benar:

• demand_snapshots table design + migration (sudah di blueprint)
• Consistent timestamp fields di semua tabel (shipped_at, delivered_at, settled_at)
• Denormalized counters di customers + products
• Source field di orders
• Fee breakdown via daily summary journal (sudah di-design)

Phase 3 — Rule-Based Intelligence

Implementasi analitik sederhana yang langsung berguna:

• Oban Worker: DailyDemandSnapshot — rekam demand per produk per hari
• ABC-XYZ Classification — klasifikasi produk by revenue + variability
• Reorder Suggestions — stok × lead time → "order Forbest 300 unit sebelum Jumat"
• RTS Rate Alerts — kurir yang melewati threshold → flag
• Aged Receivables — piutang menggantung > 14 hari → warning
• Financial Health Metrics — 7 metrik dashboard (piutang ratio, days to cash, dll)

Semua ini = SQL query + Elixir logic. Zero ML. Zero API call. Zero tambahan cost.

Phase 3+ — Explorer Dashboards

Upgrade analitik dengan Explorer:

• Demand Forecasting — moving average + trend detection dari demand_snapshots
• Margin Trend Analysis — per toko, per platform, per produk, over time
• Customer Segmentation — clustering by purchase behavior (Explorer + Scholar)
• Spike Detection — statistik anomaly detection untuk demand gak biasa
• Campaign ROI — correlate promo spend dengan revenue lift

Phase 4 — Claude API Insights

Layer teratas — natural language insight dari data:

• Weekly Business Brief — Oban job Senin pagi, kirim summary ke dashboard
• Anomaly Explanation — "margin turun 2%, ini kemungkinan penyebabnya..."
• Restock Recommendation — "berdasarkan demand trend + lead time + upcoming promo..."
• RTS Root Cause — "ID Express RTS tinggi di area Bekasi, pattern: COD + berat > 3kg"
• On-demand Q&A — "kenapa revenue Shopee turun 15% minggu ini?" (typed question → Claude analysis)

Estimasi cost: < $1/bulan. ROI: berpotensi save jutaan rupiah per bulan dari insight yang actionable.

Bonus: Nx.Serving — Kalau Nanti Butuh

Kalau di masa depan LabaBersih butuh ML on-device (misal: real-time classification untuk 100.000 order/hari), begini caranya di Elixir:

# Di application.ex (startup)
children = [
  # Web server
  LababersihWeb.Endpoint,
  # Background jobs
  {Oban, Application.fetch_env!(:lababersih, Oban)},
  # ML model serving (jalan di proses yang SAMA)
  {Nx.Serving,
    serving: build_sentiment_serving(),
    name: Lababersih.SentimentServing,
    batch_size: 16,
    batch_timeout: 100
  }
]

# Panggil dari mana saja di app:
Nx.Serving.batched_run(Lababersih.SentimentServing, "Produk bagus!")
# => %{label: "positive", score: 0.97}

# Auto-batching: kalau 50 request masuk dalam 100ms,
# Nx.Serving otomatis batch jadi 1 inference call.
# Ini optimasi yang di Python butuh setup TorchServe + queue.

Ini yang dimaksud "satu runtime." Web server, background jobs, dan ML inference jalan di application supervisor yang sama. Kalau model crash, supervisor restart. Kalau web server sibuk, ML serving tetap jalan di proses terpisah. BEAM handle semua ini secara native.

Ringkasan — Bab 11

Penutup — Kenapa LabaBersih Akan Menang

Di satu bab ini, kamu sudah tau lebih banyak tentang data intelligence daripada 99% SaaS founder di Indonesia. Bukan karena kamu baca teori — tapi karena kamu punya context yang gak dimiliki orang lain.

Kamu tau bahwa setiap RTS = Rp 80k-125k rugi. Kamu tau bahwa fee platform bisa berubah tanpa notice. Kamu tau bahwa seller Indonesia pecah bisnis ke beberapa entitas untuk tax planning. Kamu tau bahwa Mengantar itu COD offline, beda total dari Shopee.

Domain knowledge itu gak bisa di-copy. Kompetitor bisa copy fitur, tapi gak bisa copy pemahaman tentang kenapa fitur itu ada.

Dan sekarang kamu punya stack teknologi yang mendukung visi itu:

Path ke intelligence bukan tentang AI yang canggih. Ini tentang:

1. Struktur data yang benar (sedang dibangun)
2. Rule-based analytics yang berguna (Phase 3)
3. Statistical insight dari data historis (Phase 3+)
4. Natural language insight untuk decision-making (Phase 4)

Setiap level dibangun di atas level sebelumnya. Gak ada shortcut. Tapi juga gak ada blocker teknologi — stack-nya sudah siap.

Fondasi sudah dibangun. Data mengalir. Intelligence tinggal dinyalakan. Ini jalan panjang, tapi kamu sudah di track yang benar.