Centralized vs Embedded RevOps: Model Operasi Mana yang Cocok untuk Perusahaan Anda?

RevOps centralized dan RevOps embedded menyelesaikan masalah yang berbeda.

RevOps centralized melindungi standar. RevOps embedded melindungi konteks. RevOps hybrid berusaha mempertahankan keduanya.

Pilihan yang salah dapat menciptakan governance yang lambat atau eksekusi yang terfragmentasi.

Untuk struktur yang lebih luas, mulailah dengan RevOps Team Structure.

Riset desain organisasi RevOps dari Forrester membingkai desain RevOps sebagai pilihan lintas fungsi, bukan hanya keputusan garis pelaporan. Riset penyelarasan teknologi RevOps dari Forrester juga menunjukkan mengapa model operasi dan tooling tidak dapat dipisahkan.

Model organisasi menentukan bagaimana standar ditetapkan, seberapa dekat operator berada dengan pekerjaan sehari-hari, dan seberapa cepat perusahaan dapat berubah tanpa merusak data bersama.

Fakta operasional utama

• RevOps centralized melindungi standar bersama, sumber kebenaran (source of truth), dan governance lintas fungsi.
• RevOps embedded melindungi kecepatan, konteks lokal, dan adopsi di tingkat fungsional.
• RevOps hybrid berhasil ketika hak keputusan dinyatakan secara eksplisit: governance terpusat untuk definisi dan sistem bersama, dukungan embedded untuk workflow lokal.
• Model terbaik bergantung pada risiko operasional saat ini. Jika definisi dan dashboard terfragmentasi, sentralisasikan lebih banyak. Jika RevOps terpusat terlalu lambat dan tim membuat solusi sendiri (workaround), tambahkan lebih banyak konteks embedded.

Tiga model

Kebanyakan perusahaan melewati lebih dari satu model. Tim yang dipimpin founder mungkin memulai dengan satu generalis ops. Perusahaan tahap pertumbuhan mungkin melakukan sentralisasi untuk memperbaiki masalah sumber kebenaran. Perusahaan yang lebih besar mungkin menempatkan spesialis embedded dekat dengan fungsi masing-masing sambil tetap mempertahankan governance terpusat.

Kesalahannya adalah memperlakukan model ini sebagai identitas. Model seharusnya menjadi respons terhadap risiko operasional perusahaan saat ini.

Diagnosis risiko operasional terlebih dahulu

Mulailah dari masalah yang perlu dipecahkan oleh model tersebut.

Diagnosis ini mencegah desain organisasi menjadi ideologis. Centralized tidak secara otomatis lebih matang. Embedded tidak secara otomatis lebih gesit (agile). Keduanya bisa berhasil atau gagal tergantung masalah yang dihadapi.

Model yang salah biasanya terlihat dari perilaku. Dalam model yang terlalu centralized, tim membuat spreadsheet sampingan dan workflow pribadi. Dalam model yang terlalu embedded, eksekutif melihat definisi yang saling bertentangan dan tool yang duplikat. Dalam model hybrid yang lemah, semua orang mengatakan "kepemilikan bersama" tetapi tidak ada yang tahu siapa yang memutuskan.

RevOps centralized

RevOps centralized bekerja dengan baik ketika perusahaan membutuhkan satu sistem operasi pendapatan.

Model ini paling kuat ketika:

• Dashboard saling bertentangan.
• Tool terus bertambah banyak.
• Kualitas data tidak konsisten.
• Marketing, sales, dan CS membutuhkan governance bersama.
• Finance membutuhkan satu tampilan pendapatan yang dapat dipercaya.

Risikonya adalah daya tanggap (responsiveness). Jika setiap permintaan harus melalui antrean terpusat, tim mungkin akan mencari jalan pintas di luar RevOps. Itu menciptakan sistem bayangan (shadow systems).

Model centralized dalam praktik

Model centralized biasanya memiliki satu pemimpin RevOps dan spesialis bersama:

• CRM dan sistem
• Analitik dan dashboard
• Proses dan governance
• Operasi forecast
• Desain lifecycle dan serah terima

Permintaan mengalir ke roadmap terpusat. RevOps memprioritaskan berdasarkan dampak di tingkat perusahaan, bukan hanya urgensi fungsional.

Model ini kuat ketika pemimpin membutuhkan satu sumber kebenaran. Model ini membantu mencegah setiap tim membuat field, dashboard, workflow, dan definisinya sendiri-sendiri.

Namun RevOps centralized bisa menjadi terlalu jauh dari pekerjaan sehari-hari. Jika manajer sales merasa RevOps tidak memahami workflow rep, mereka akan membuat spreadsheet sampingan. Jika marketing merasa konteks kampanye hilang, mereka akan membuat pelaporan terpisah. Jika CS merasa proses renewal diabaikan, mereka akan mengelola risiko dengan tool mereka sendiri.

RevOps centralized membutuhkan mekanisme mendengarkan yang terstruktur:

• Jam konsultasi fungsional (office hours)
• Umpan balik rutin dari manajer di lapangan
• Tinjauan roadmap triwulanan bersama pemimpin GTM
• Aturan intake yang jelas
• Service level yang dipublikasikan untuk permintaan umum

Tanpa itu, sentralisasi berubah menjadi kontrol tanpa konteks.

RevOps embedded

Operasi embedded bekerja dengan baik ketika tim membutuhkan kecepatan dan konteks.

Mitra marketing ops memahami kampanye secara mendalam. Mitra sales ops memahami wilayah (territory), kuota, dan workflow rep. Mitra CS ops memahami onboarding dan pola renewal.

Risikonya adalah fragmentasi. Setiap fungsi mungkin melakukan optimasi lokal dan merusak sistem pendapatan bersama.

RevOps embedded membutuhkan standar terpusat untuk definisi lifecycle, field, dashboard, dan perubahan sistem.

Model embedded dalam praktik

Model embedded menempatkan operator di dalam masing-masing fungsi:

• Marketing Ops di dalam marketing
• Sales Ops di dalam sales
• CS Ops di dalam customer success
• Analitik pendapatan dekat dengan pimpinan atau finance

Manfaatnya adalah kecepatan. Operator memahami detail lokal. Mitra sales ops dapat melihat bagaimana rep benar-benar bekerja. Mitra marketing ops dapat menyesuaikan workflow kampanye dengan cepat. Mitra CS ops dapat menyetel sinyal kesehatan berdasarkan percakapan renewal.

Risikonya adalah optimasi lokal.

Marketing mungkin mendefinisikan field sumber untuk pelaporan kampanye, sementara finance membutuhkan konsistensi bookings. Sales mungkin menambahkan field untuk inspeksi manajer sementara rep menolak entri data. CS mungkin membangun kategori kesehatan yang tidak terhubung dengan forecast atau pipeline ekspansi.

Tim embedded membutuhkan lapisan governance RevOps bersama:

• Definisi lifecycle yang umum
• Kamus data bersama
• Aturan pelaporan sumber kebenaran
• Proses perubahan sistem
• RACI lintas fungsi
• Jalur eskalasi eksekutif

Tanpa lapisan itu, RevOps embedded sebenarnya bukan RevOps. Itu hanyalah ops fungsional terpisah dengan label yang lebih modern.

RevOps hybrid

Hybrid biasanya menjadi model terbaik untuk perusahaan mid-market.

RevOps terpusat memegang:

• Lifecycle pendapatan
• Kamus data
• Sumber kebenaran
• Governance sistem
• Dashboard eksekutif
• Irama operasi

Mitra fungsional memegang:

• Eksekusi marketing ops
• Eksekusi sales ops
• Eksekusi CS ops
• Detail workflow lokal
• Kebutuhan pelaporan fungsional

Model ini hanya berhasil jika hak keputusan dituliskan dalam RevOps RACI.

Model hybrid dalam praktik

RevOps hybrid sering menjadi model terkuat begitu perusahaan memiliki kompleksitas yang cukup untuk membutuhkan standar sekaligus konteks.

RevOps terpusat memegang arsitektur operasional:

• Model lifecycle
• Kamus data
• Irama governance
• Dashboard eksekutif
• Proses forecast
• Kontrol perubahan sistem
• Roadmap lintas fungsi

Mitra embedded memegang eksekusi lokal:

• Operasi kampanye
• Dukungan wilayah dan kuota
• Detail workflow sales
• Workflow onboarding dan renewal CS
• Kebutuhan pelaporan fungsional
• Umpan balik adopsi lokal

Model ini berhasil ketika semua orang tahu keputusan mana yang bersifat lokal dan mana yang bersifat bersama.

Sebagai contoh, marketing dapat memutuskan konvensi penamaan kampanye untuk penggunaan internal, tetapi RevOps harus mengelola field sumber yang menjadi masukan pelaporan pendapatan. Sales dapat mengelola workflow rep, tetapi RevOps harus mengelola definisi tahap dan aturan forecast category. CS dapat mengelola playbook kesehatan, tetapi RevOps harus mengelola sinyal renewal dan ekspansi mana yang masuk ke pelaporan pendapatan.

Cara memilih

Pilih centralized jika kepercayaan dan standardisasi adalah masalah utama.

Pilih embedded jika kecepatan dan nuansa fungsional adalah masalah utama.

Pilih hybrid jika Anda membutuhkan standardisasi tanpa membuat setiap permintaan lokal menunggu di belakang antrean terpusat.

Cara mendiagnosis model Anda saat ini

Ajukan pertanyaan berikut:

• Apakah tim menggunakan definisi lifecycle yang sama?
• Apakah finance memercayai dashboard yang sama dengan pimpinan sales?
• Bisakah tim ops lokal mengubah field CRM tanpa tinjauan lintas fungsi?
• Apakah manajer tahu ke mana harus meminta perubahan sistem?
• Apakah operator embedded hanya diukur dari kecepatan fungsional?
• Apakah RevOps terpusat memahami workflow sehari-hari?
• Apakah keputusan tool ditinjau dari dampak lanjutannya (downstream)?

Jika standar lemah, pindahkan lebih banyak otoritas ke RevOps terpusat.

Jika eksekusi lambat dan tim membuat solusi sendiri, pindahkan lebih banyak konteks lebih dekat ke fungsi masing-masing.

Jika keduanya benar, perusahaan kemungkinan besar membutuhkan model hybrid dengan hak keputusan yang lebih jelas.

Model berdasarkan tahap perusahaan

Model harus berubah seiring perubahan perusahaan. Struktur yang berhasil pada 50 karyawan mungkin gagal pada 200 karyawan.

Perbandingan hak keputusan

Perbedaan sesungguhnya antar model terletak pada hak keputusan.

Tabel ini adalah inti dari pilihan ini. Garis pelaporan kurang penting dibanding siapa yang bisa mengubah aset operasional bersama.

Anti-pola

RevOps centralized sebagai antrean tiket. Tim menjadi kelebihan beban dan jauh dari pekerjaan. Tim fungsional membuat solusi sendiri.

RevOps embedded tanpa standar. Setiap fungsi bergerak cepat, tetapi perusahaan kehilangan tampilan pendapatan bersama.

RevOps hybrid tanpa RACI. Semua orang mengatakan modelnya hybrid, tetapi tidak ada yang tahu siapa yang memutuskan.

Garis pelaporan dikira sebagai model operasi. RevOps bisa melapor ke CRO, COO, atau finance dan tetap beroperasi secara centralized, embedded, atau hybrid.

Tanpa keterlibatan finance. Definisi pelaporan dan perencanaan bergeser menjauh dari dashboard operasional.

Model yang tepat harus mengurangi friksi, bukan sekadar menggambar ulang struktur organisasi.

Rencana transisi

Jika Anda perlu mengubah model, lakukan secara bertahap:

1. Audit di mana definisi, dashboard, field, dan workflow saling bertentangan.
2. Putuskan aset mana yang harus dikelola secara terpusat.
3. Identifikasi tim mana yang membutuhkan dukungan embedded.
4. Tulis charter dan RACI RevOps.
5. Pindahkan intake dan tinjauan roadmap ke dalam irama bersama.
6. Perbarui scorecard sehingga operator diukur baik dari layanan lokal maupun kesehatan sistem bersama.

Jangan melakukan reorganisasi terlebih dahulu baru mendefinisikan kepemilikan kemudian. Itu akan menciptakan kebingungan selama berbulan-bulan.

Scorecard berdasarkan model

Ukur model berdasarkan masalah yang seharusnya diselesaikan.

Untuk RevOps centralized, lacak:

• Kepercayaan terhadap dashboard
• Pengurangan pelaporan duplikat
• Peningkatan kualitas data
• Waktu siklus perubahan sistem
• Konsistensi proses forecast
• Penyelesaian roadmap lintas fungsi

Untuk RevOps embedded, lacak:

• Waktu penyelesaian permintaan fungsional
• Adopsi workflow lokal
• Kepuasan manajer
• Peningkatan proses lokal
• Kepatuhan terhadap definisi terpusat
• Jumlah solusi sendiri (workaround) yang dibuat di luar sistem

Untuk RevOps hybrid, lacak keduanya:

• Kepatuhan terhadap definisi bersama
• Kecepatan fungsional
• Penyelesaian roadmap terpusat
• Adopsi lokal
• Volume eskalasi
• Waktu penyelesaian perselisihan lintas fungsi

Jika tim terpusat dipercaya tetapi terlalu lambat, model membutuhkan lebih banyak dukungan embedded. Jika tim embedded cepat tetapi definisinya mulai bergeser, model membutuhkan governance terpusat yang lebih kuat. Jika tim hybrid kebingungan, masalahnya biasanya ada pada hak keputusan.

Garis pelaporan vs model operasi

Jangan mencampuradukkan garis pelaporan dengan model operasi.

RevOps dapat melapor kepada:

• CRO
• COO
• CFO
• CEO
• Chief Customer Officer

Semua pilihan itu bisa berhasil jika mandatnya jelas.

Model operasi menjawab pertanyaan yang berbeda: bagaimana RevOps melayani bisnis sehari-hari?

Sebuah tim dapat melapor ke CRO dan tetap beroperasi secara terpusat di seluruh marketing, sales, CS, dan finance. Sebuah tim dapat melapor ke COO dan tetap menempatkan spesialis embedded di dalam masing-masing fungsi. Sebuah tim dapat melapor ke finance dan tetap memegang governance operasional di luar sekadar pelaporan.

Bahayanya adalah ketika garis pelaporan diam-diam mempersempit mandat. Jika RevOps melapor ke sales dan setiap keputusan lebih mengutamakan kecepatan sales dibanding kualitas data bersama, marketing, CS, dan finance akan berhenti memercayai fungsi ini. Jika RevOps melapor ke finance dan hanya berfokus pada kontrol pelaporan, sales dan marketing mungkin melihatnya sebagai tim kepatuhan (compliance) semata.

Sponsor eksekutif harus melindungi netralitas ini. RevOps membutuhkan cukup jarak untuk mengelola sistem bersama dan cukup kedekatan untuk memahami pekerjaan sehari-hari.

Rekomendasi praktis

Untuk banyak perusahaan B2B SaaS dan jasa dengan 50 hingga 500 karyawan, model hybrid yang ringan adalah titik awal terbaik.

Itu biasanya berarti:

• Satu pemilik RevOps terpusat
• Governance lifecycle dan data yang jelas
• Kemitraan erat dengan marketing, sales, CS, dan finance
• Kontak fungsional yang ditunjuk, bukan tim embedded penuh di awal
• Irama governance sistem dan pelaporan bulanan
• Roadmap RevOps triwulanan

Seiring pertumbuhan volume, perusahaan dapat menambah mitra embedded. Marketing mungkin mendapatkan mitra ops khusus. Sales mungkin mendapatkan operasi wilayah, kompensasi, atau enablement. CS mungkin mendapatkan CS Ops untuk workflow kesehatan, renewal, dan ekspansi. Namun semuanya tetap harus mengikuti satu model operasi pendapatan.

Ini mencegah perusahaan membangun struktur berlebihan terlalu dini, sekaligus mencegah fragmentasi yang muncul ketika setiap tim menyelesaikan masalahnya sendiri secara terpisah.

Daftar periksa kesiapan

Sebelum mengubah model, periksa apakah para pemimpin sepakat tentang:

• Definisi pendapatan mana yang bersifat bersama
• Permintaan mana yang bisa ditangani secara lokal
• Perubahan mana yang membutuhkan tinjauan terpusat
• Dashboard mana yang menjadi sumber kebenaran
• Tim fungsional mana yang membutuhkan dukungan lebih dekat
• Sponsor eksekutif mana yang menyelesaikan trade-off

Jika pertanyaan-pertanyaan itu belum terjawab, mengubah kotak di struktur organisasi tidak akan memperbaiki masalah operasionalnya.

Risiko transisi

Mengubah model RevOps menciptakan risiko jika perusahaan memindahkan orang sebelum memindahkan hak keputusan.

Risiko transisi yang umum:

Kelola transisi dengan tiga dokumen: charter, RACI, dan roadmap. Charter menjelaskan mandat. RACI menjelaskan siapa yang memutuskan. Roadmap menunjukkan masalah bersama mana yang akan diselesaikan lebih dulu oleh model tersebut.

Jangan menilai model baru hanya dari kecepatan permintaan jangka pendek. Perpindahan menuju sentralisasi mungkin memperlambat permintaan lokal di awal sambil meningkatkan kepercayaan terhadap pelaporan bersama. Perpindahan menuju dukungan embedded mungkin meningkatkan kecepatan lokal sambil membutuhkan governance yang lebih kuat untuk mencegah fragmentasi. Metrik operasional harus disesuaikan dengan alasan di balik perubahan tersebut.

Workshop pemilihan model

Jalankan workshop singkat sebelum mengubah model.

Agenda:

1. Buat daftar konflik RevOps yang paling sering berulang pada kuartal terakhir.
2. Tandai setiap konflik sebagai masalah standar, masalah konteks, masalah kapasitas, atau masalah hak keputusan.
3. Identifikasi aset mana yang harus dikelola secara terpusat.
4. Identifikasi workflow mana yang membutuhkan dukungan fungsional yang lebih dekat.
5. Putuskan keputusan mana yang bisa bersifat lokal dan mana yang membutuhkan persetujuan terpusat.
6. Perbarui charter, RACI, roadmap, dan proses intake.

Workshop ini menjaga desain organisasi tetap berbasis bukti. Jika masalah utamanya adalah dashboard yang saling bertentangan, field yang duplikat, dan ketidakpercayaan finance, jawabannya bukan lebih banyak otonomi embedded. Jika masalah utamanya adalah dukungan yang lambat, adopsi manajer yang buruk, dan RevOps terpusat yang kehilangan konteks workflow, jawabannya bukan lebih banyak kontrol terpusat.

Model harus menyelesaikan friksi yang sesungguhnya, bukan friksi yang diasumsikan ada oleh para pemimpin.

Pemicu perubahan model

Jangan mengubah model RevOps hanya karena perusahaan lain menggunakan struktur yang berbeda.

Ubah model ketika buktinya sudah jelas:

Model harus berubah untuk menyelesaikan kegagalan operasional yang spesifik. Jika kegagalannya tidak jelas, perbaiki dulu charter dan intake-nya.

FAQ

Apakah RevOps centralized lebih baik?

Tidak selalu. Model ini lebih baik untuk masalah governance dan sumber kebenaran. Model ini bisa lebih buruk untuk kecepatan jika tim menjadi bottleneck.

Apakah RevOps embedded benar-benar RevOps?

Bisa, jika operator embedded mengikuti governance RevOps bersama. Tanpa governance bersama, itu biasanya hanya ops fungsional yang terpisah.

Model apa yang sebaiknya digunakan perusahaan B2B dengan 100 karyawan?

Biasanya hybrid yang ringan: satu pemilik RevOps dengan dukungan fungsional yang erat dari marketing, sales, dan CS.

Pelajari lebih lanjut

• RevOps Charter
• First RevOps Hire
• RevOps vs Marketing Ops vs Sales Ops
• RACI Matrix