Tinjauan praktis tentang bagaimana Jay Chaudhry dan Zscaler menggunakan keamanan cloud, zero trust, dan distribusi lewat mitra untuk membangun perusahaan keamanan perusahaan terkemuka.
Ini bukan biografi Jay Chaudhry. Ini adalah cerita praktis tentang bagaimana Zscaler membantu membentuk ulang keamanan perusahaan—dan mengapa pilihan teknis dan komersialnya penting.
Anda akan belajar dua hal secara paralel:
Keamanan perusahaan modern adalah seperangkat kontrol yang memungkinkan karyawan menggunakan internet dan aplikasi internal dengan aman, tanpa menganggap sesuatu aman hanya karena berada “di dalam” jaringan perusahaan. Ini bukan soal membangun tembok yang lebih besar di sekitar pusat data, melainkan memeriksa siapa yang terhubung, apa yang diakses, dan apakah koneksi itu boleh—setiap kali.
Di akhir, Anda bisa menjelaskan inti taruhan Zscaler dalam satu kalimat, mengenali di mana zero trust menggantikan pemikiran era VPN, dan melihat mengapa strategi distribusi bisa sama pentingnya dengan desain produk.
Jay Chaudhry adalah wirausahawan serial yang paling dikenal sebagai pendiri dan CEO Zscaler, sebuah perusahaan yang mendorong keamanan perusahaan dari “melindungi jaringan korporat” menjadi “mengamankan pengguna dan aplikasi di mana pun mereka berada.” Sebelum Zscaler, ia membangun dan menjual beberapa startup keamanan, memberinya pandangan langsung tentang bagaimana perilaku penyerang dan TI perusahaan berubah cepat.
Fokus Chaudhry dengan Zscaler sederhana: ketika pekerjaan dan aplikasi bergerak keluar dari jaringan korporat (ke internet publik dan layanan cloud), model lama yang merutekan semuanya melalui data center pusat untuk inspeksi mulai runtuh.
Perubahan itu menciptakan trade-off yang menyakitkan bagi tim IT:
Premis pendirian Zscaler adalah bahwa keamanan perlu mengikuti pengguna, bukan gedung.
Yang menonjol adalah bagaimana visi produk yang dipimpin pendiri memengaruhi strategi perusahaan sejak awal:
Ini bukan hanya trik pemasaran; itu memengaruhi keputusan produk, kemitraan, dan cara Zscaler menjelaskan “mengapa” kepada pembeli perusahaan yang konservatif. Seiring waktu, kejelasan itu membantu mengubah “keamanan yang dikirim lewat cloud” dan “zero trust” dari ide menjadi alokasi anggaran—sesuatu yang bisa dibeli, diterapkan, dan distandarisasi oleh perusahaan besar.
Bertahun-tahun, keamanan perusahaan dibangun di sekitar ide sederhana: simpan "barang bagus" di dalam jaringan korporat, dan pasang tembok di sekitarnya. Tembok itu biasanya tumpukan perangkat on‑prem—firewall, proxy web, intrusion prevention—yang duduk di beberapa data center. Karyawan jarak jauh mengakses lewat VPN, yang pada dasarnya "memperluas" jaringan internal ke mana pun mereka berada.
Ketika sebagian besar aplikasi berada di pusat data perusahaan, model ini bekerja cukup baik. Lalu lintas web dan aplikasi mengalir melalui titik sempit yang sama, di mana tim keamanan bisa memeriksa, mencatat, dan memblokir.
Namun model itu mengasumsikan dua hal yang mulai tidak lagi benar:
Saat karyawan menjadi lebih mobile dan adopsi SaaS meningkat, pola lalu lintas terbalik. Orang di kafe butuh akses cepat ke Office 365, Salesforce, dan puluhan alat berbasis browser—seringkali tanpa pernah menyentuh pusat data korporat.
Untuk tetap menegakkan kebijakan, banyak perusahaan melakukan “backhaul”: mengirim permintaan internet dan SaaS pengguna lewat kantor pusat dulu, inspeksi, lalu dikirim keluar kembali. Hasilnya dapat diprediksi: performa lambat, pengguna tidak senang, dan tekanan yang tumbuh untuk membuka celah kontrol.
Kompleksitas melonjak (lebih banyak perangkat, lebih banyak aturan, lebih banyak pengecualian). VPN menjadi kewalahan dan berisiko saat memberikan akses jaringan yang luas. Dan setiap kantor cabang baru atau akuisisi berarti rollout perangkat keras lagi, lebih banyak perencanaan kapasitas, dan arsitektur yang lebih rapuh.
Kesenjangan itu—membutuhkan keamanan yang konsisten tanpa memaksa semuanya lewat perimeter fisik—menciptakan celah bagi keamanan yang dikirim lewat cloud yang bisa mengikuti pengguna dan aplikasi, bukan gedung.
Taruhan mendefinisikan Zscaler mudah diucapkan tapi sulit dieksekusi: kirimkan keamanan sebagai layanan cloud, ditempatkan dekat dengan pengguna, bukan sebagai kotak yang duduk di jaringan perusahaan.
Dalam konteks ini, “keamanan cloud” bukan berarti hanya melindungi server cloud. Artinya keamanan itu sendiri berjalan di cloud—jadi pengguna di cabang, di rumah, atau mobile terhubung ke titik kehadiran (PoP) terdekat, dan kebijakan ditegakkan di sana.
"Inlining" seperti merutekan lalu lintas melalui pos pemeriksaan keamanan dalam perjalanan ke tujuan.
Saat seorang karyawan pergi ke situs web atau aplikasi cloud, koneksinya diarahkan melalui layanan terlebih dulu. Layanan memeriksa apa yang bisa (berdasarkan kebijakan), memblokir tujuan berisiko, memindai ancaman, lalu meneruskan lalu lintas yang diizinkan. Tujuannya agar pengguna tidak perlu "berada di jaringan korporat" untuk mendapatkan perlindungan kelas perusahaan—keamanan mengikuti pengguna.
Keamanan yang dikirim lewat cloud mengubah realitas sehari-hari bagi tim IT dan keamanan:
Model ini juga sejalan dengan cara kerja perusahaan sekarang: lalu lintas sering langsung ke SaaS dan internet publik, bukan "kembali ke kantor pusat" terlebih dahulu.
Menempatkan pihak ketiga inline menimbulkan kekhawatiran nyata yang harus dievaluasi tim:
Jadi taruhan inti bukan hanya teknis—melainkan kepercayaan operasional bahwa penyedia cloud dapat menegakkan kebijakan secara andal, transparan, dan pada skala global.
Zero trust adalah prinsip sederhana: jangan pernah menganggap sesuatu aman hanya karena berada “di dalam jaringan perusahaan.” Sebagai gantinya, selalu verifikasi siapa pengguna itu, perangkat apa yang dipakai, dan apakah mereka boleh mengakses aplikasi atau data tertentu—setiap kali itu penting.
Pemikiran VPN tradisional seperti memberikan seseorang lencana yang membuka seluruh gedung setelah mereka lewat pintu depan. Setelah terhubung lewat VPN, banyak sistem memperlakukan pengguna itu sebagai "internal", yang bisa mengekspos lebih banyak dari yang dimaksudkan.
Zero trust membalik model itu. Lebih mirip memberi seseorang akses ke satu ruangan untuk satu tugas. Anda tidak "bergabung dengan jaringan" secara luas; Anda hanya diizinkan mengakses aplikasi yang disetujui.
Seorang kontraktor membutuhkan akses ke alat manajemen proyek selama dua bulan. Dengan zero trust, mereka diizinkan ke satu aplikasi itu—tanpa secara tidak sengaja membuka jalan ke sistem penggajian atau alat admin internal.
Seorang karyawan menggunakan BYOD (laptop pribadi) saat bepergian. Kebijakan zero trust dapat mengharuskan pemeriksaan login lebih kuat atau memblokir akses jika perangkat ketinggalan patch, tidak terenkripsi, atau menunjukkan tanda kompromi.
Kerja jarak jauh menjadi lebih mudah diamankan karena keputusan keamanan mengikuti pengguna dan aplikasi, bukan jaringan kantor fisik.
Zero trust bukan produk tunggal yang dibeli lalu "diaktifkan." Ini adalah pendekatan keamanan yang diterapkan melalui alat dan kebijakan.
Ini juga bukan berarti “percaya tidak seorang pun” secara permusuhan. Praktiknya, artinya kepercayaan diperoleh secara terus‑menerus melalui pemeriksaan identitas, status perangkat, dan prinsip hak paling sedikit—sehingga kesalahan dan pelanggaran tidak menyebar otomatis.
Zscaler paling mudah dipahami sebagai titik kontrol cloud yang duduk di antara orang dan apa yang mereka coba capai. Alih-alih mempercayai batas jaringan korporat, ia mengevaluasi setiap koneksi berdasarkan siapa pengguna dan bagaimana kondisinya, lalu menerapkan kebijakan yang sesuai.
Sebagian besar deployment dapat dijelaskan dengan empat bagian sederhana:
Secara konseptual, Zscaler memisahkan lalu lintas ke dua jalur:
Pemisahan itu penting: satu jalur tentang penggunaan internet yang aman; jalur lain tentang akses tepat ke sistem internal.
Keputusan tidak didasarkan pada alamat IP kantor yang dianggap aman. Mereka berdasarkan sinyal seperti siapa pengguna, kesehatan perangkat (dikelola vs tidak, terpatch vs ketinggalan), dan dari mana/cara mereka terhubung.
Jika dilakukan dengan baik, pendekatan ini mengurangi permukaan serangan yang terekspos, membatasi pergerakan lateral jika terjadi masalah, dan mengubah kontrol akses menjadi model kebijakan yang lebih sederhana dan konsisten—terutama karena kerja jarak jauh dan tumpukan aplikasi cloud-first menjadi default.
Saat orang berbicara tentang “keamanan perusahaan”, mereka sering membayangkan aplikasi privat dan jaringan internal. Tetapi sebagian besar risiko besar berada di sisi internet terbuka: karyawan menjelajah situs berita, mengklik link di email, menggunakan alat berbasis browser, atau mengunggah file ke aplikasi web.
Secure Web Gateway (SWG) adalah kategori yang dibuat untuk membuat akses internet sehari-hari lebih aman—tanpa memaksa lalu lintas setiap pengguna untuk memutar balik lewat kantor pusat.
Sederhananya, SWG bertindak sebagai pos pemeriksaan terkendali antara pengguna dan web publik. Alih-alih mempercayai apa pun yang dijangkau perangkat, gateway menerapkan kebijakan dan inspeksi sehingga organisasi dapat mengurangi paparan ke situs berbahaya, unduhan berisiko, dan kebocoran data tak sengaja.
Perlindungan tipikal meliputi:
Perubahan momentum terjadi ketika pekerjaan berpindah dari kantor tetap ke SaaS, browser, dan perangkat mobile. Jika pengguna ada di mana‑mana dan aplikasi ada di mana‑mana, memutar lalu lintas kembali ke perimeter korporat menambah latensi dan menciptakan titik buta.
SWG yang dikirim lewat cloud cocok dengan realitas baru: kebijakan mengikuti pengguna, lalu lintas dapat diperiksa lebih dekat dengan tempat mereka terhubung, dan tim keamanan mendapatkan kontrol konsisten tanpa memperlakukan internet sebagai pengecualian.
VPN dibangun untuk masa ketika “berada di jaringan” sama dengan “bisa mencapai aplikasi”. Model itu runtuh ketika aplikasi berada di berbagai cloud, SaaS, dan set sistem on‑prem semakin menyusut.
Akses berfokus-aplikasi membalik default. Alih-alih menempatkan pengguna ke jaringan internal (lalu berharap kebijakan segmentasi menahan), pengguna dihubungkan hanya ke aplikasi tertentu.
Secara konseptual, ini bekerja seperti koneksi yang dibroker: pengguna membuktikan siapa mereka dan apa yang boleh mereka gunakan, lalu dibuat jalur singkat dan terkontrol ke aplikasi itu—tanpa mempublikasikan rentang IP internal ke internet dan tanpa memberi visibilitas luas sebagai "internal".
Segmentasi jaringan kuat, tapi rapuh di organisasi nyata: merger, VLAN datar, aplikasi warisan, dan pengecualian cenderung menumpuk. Segmentasi aplikasi lebih mudah dipahami karena memetakan niat bisnis:
Ini mengurangi kepercayaan implisit dan membuat kebijakan akses lebih mudah dibaca: Anda bisa mengaudit berdasarkan aplikasi dan grup pengguna alih-alih menelusuri rute dan subnet.
Kebanyakan tim tidak mengganti VPN dalam semalam. Rollout yang praktis sering terlihat seperti:
Saat akses berfokus-aplikasi dilakukan dengan baik, keuntungan terlihat cepat: lebih sedikit tiket dukungan terkait VPN, aturan akses yang lebih jelas yang bisa dijelaskan tim keamanan dan TI, dan pengalaman pengguna yang lebih mulus—khususnya untuk karyawan remote dan hybrid yang hanya menginginkan aplikasi berfungsi tanpa “terhubung ke jaringan” terlebih dulu.
Produk keamanan hebat tidak otomatis menjadi standar perusahaan. Dalam praktiknya, “distribusi” dalam keamanan perusahaan berarti jalur yang digunakan vendor untuk menjangkau, memenangkan, dan berhasil menerapkan di dalam organisasi besar—seringkali melalui perusahaan lain.
Dalam keamanan, distribusi biasanya meliputi:
Ini bukan tambahan opsional. Mereka adalah pipa yang menghubungkan vendor ke anggaran, pengambil keputusan, dan kapasitas implementasi.
Perusahaan besar membeli dengan hati-hati. Mitra memberikan:
Untuk platform seperti Zscaler, adopsi sering tergantung pada pekerjaan migrasi nyata—memindahkan pengguna dari pola VPN legacy, mengintegrasikan identitas, dan menyetel kebijakan. Mitra membuat perubahan itu terasa dapat dikelola.
Pengiriman cloud menggeser bisnis dari instalasi satu kali ke langganan, ekspansi, dan pembaruan. Itu mengubah distribusi: mitra bukan hanya “penutup transaksi.” Mereka bisa menjadi mitra rollout berkelanjutan yang insentifnya selaras dengan hasil pelanggan—jika program dirancang dengan baik.
Perhatikan insentif mitra, kualitas pemberdayaan mitra (pelatihan, playbook, dukungan co-selling), dan seberapa mulus serah terima customer success setelah kontrak ditandatangani. Banyak deployment gagal bukan karena produk lemah, tetapi karena kepemilikan antara vendor, mitra, dan pelanggan menjadi tidak jelas.
Pembelian keamanan jarang dimulai dengan "kami butuh keamanan lebih baik." Biasanya dimulai dengan perubahan jaringan yang merusak asumsi lama: lebih banyak aplikasi pindah ke SaaS, cabang beralih ke SD-WAN, atau kerja remote menjadi permanen. Ketika lalu lintas tidak lagi mengalir lewat kantor pusat, model "lindungi semuanya di kantor pusat" berubah menjadi koneksi lambat, pengecualian berantakan, dan titik buta.
Zscaler sering disebut dalam percakapan yang sama dengan SASE dan SSE karena label itu menggambarkan perubahan bagaimana keamanan dikirim:
Manfaat sebenarnya bukan akronimnya—melainkan operasi yang lebih sederhana: lebih sedikit kotak on‑prem, pembaruan kebijakan lebih mudah, dan akses langsung ke aplikasi tanpa memutar lalu lintas lewat data center.
Perusahaan biasanya mengevaluasi pendekatan bergaya SSE/SASE ketika:
Ketika pemicu itu muncul, kategori “tiba” secara alami—karena jaringan sudah berubah.
Membeli platform Zero Trust biasanya bagian yang mudah. Membuatnya bekerja di jaringan yang berantakan, aplikasi warisan, dan orang nyata adalah tempat proyek berhasil—atau mandek.
Aplikasi warisan seringkali menjadi pelaku ulang. Sistem lama mungkin mengasumsikan "di dalam jaringan = dipercaya", bergantung pada allowlist IP yang tertanam, atau rusak ketika lalu lintas diperiksa.
Faktor gesekan lain adalah manusia: manajemen perubahan, desain ulang kebijakan, dan debat "siapa bertanggung jawab apa". Beralih dari akses jaringan luas ke aturan tepat‑aplikasi memaksa tim mendokumentasikan bagaimana kerja sebenarnya berlangsung—dan itu bisa menyingkap celah yang lama diabaikan.
Rollout berjalan lebih lancar bila keamanan tidak mencoba bekerja sendiri. Harapkan koordinasi dengan:
Mulailah dengan grup berisiko rendah (mis. satu departemen atau subset kontraktor) dan definisikan metrik keberhasilan di muka: lebih sedikit tiket VPN, akses aplikasi lebih cepat, pengurangan permukaan serangan yang terekspos, atau visibilitas yang membaik.
Jalankan pilot secara iteratif: migrasikan satu kategori aplikasi pada satu waktu, setel kebijakan, lalu perluas. Tujuannya belajar cepat tanpa mengubah seluruh perusahaan menjadi lingkungan uji.
Rencanakan logging dan troubleshooting sejak hari pertama: di mana log disimpan, siapa yang bisa melakukan query, berapa lama disimpan, dan bagaimana alert terhubung ke respons insiden. Jika pengguna tidak dapat mendapatkan bantuan saat “aplikasi diblokir”, kepercayaan cepat menurun—meskipun model keamanan sudah baik.
Akselerator praktis (dan sering diabaikan) adalah tooling internal: portal sederhana untuk permintaan pengecualian, tinjauan akses, inventaris aplikasi, pelacakan rollout, dan pelaporan. Tim semakin sering membangun "glue apps" ringan ini sendiri daripada menunggu roadmap vendor. Platform seperti Koder.ai dapat membantu tim membuat prototipe dan mengirim alat web internal ini dengan cepat melalui workflow chat—berguna ketika Anda membutuhkan dashboard berbasis React dengan backend Go/PostgreSQL, ditambah iterasi cepat saat kebijakan dan proses berkembang.
Memindahkan kontrol keamanan dari perangkat yang Anda miliki ke platform yang dikirim lewat cloud dapat menyederhanakan operasi—tetapi juga mengubah apa yang Anda pertaruhkan. Keputusan yang baik bukan soal “Zero Trust vs. legacy” melainkan memahami mode kegagalan baru.
Jika satu platform menyediakan keamanan web, akses aplikasi privat, penegakan kebijakan, dan logging, Anda mengurangi fragmentasi alat—tetapi juga mengonsentrasikan risiko. Sengketa kontrak, perubahan harga, atau celah produk dapat memiliki dampak lebih luas dibandingkan ketika fungsi-fungsi itu tersebar pada beberapa alat.
Keamanan cloud menambahkan satu hop ekstra antara pengguna dan aplikasi. Saat berjalan baik, pengguna nyaris tidak merasakannya. Saat sebuah region mengalami outage, masalah routing, atau kapasitas, “keamanan” bisa terasa seperti “internet mati.” Ini bukan soal vendor tunggal, melainkan andalan pada konektivitas yang selalu tersedia.
Zero Trust bukan perisai ajaib. Kebijakan yang buruk (terlalu longgar, terlalu ketat, atau tidak konsisten antar grup) bisa meningkatkan paparan atau mengganggu kerja. Semakin fleksibel mesin kebijakan, semakin disiplin yang diperlukan.
Rollout bertahap membantu: mulai dengan kasus penggunaan yang jelas (mis. subset pengguna atau satu kategori aplikasi), ukur latensi dan hasil akses, lalu perluas. Definisikan kebijakan dengan bahasa sederhana, implementasikan monitoring dan alerting sejak awal, dan rencanakan redundansi (routing multi-region, akses break-glass, dan jalur fallback terdokumentasi).
Ketahui jenis data yang melindungi (ter-regulasi vs umum), selaraskan kontrol dengan kebutuhan kepatuhan, dan jadwalkan tinjauan akses berkala. Tujuannya bukan pembelian berbasis ketakutan—melainkan memastikan model baru gagal dengan aman dan dapat diprediksi.
Pelajaran berulang dari Zscaler adalah fokus: memindahkan penegakan keamanan ke cloud dan membuat akses berbasis identitas. Saat mengevaluasi vendor (atau membangun satu), tanyakan satu pertanyaan sederhana: “Apa satu taruhan arsitektural yang membuat semuanya lebih sederhana?” Jika jawabannya “tergantung”, harapkan kompleksitas muncul nanti dalam biaya, waktu rollout, dan pengecualian.
“Zero trust” berhasil karena diterjemahkan menjadi janji praktis: lebih sedikit asumsi kepercayaan implisit, lebih sedikit pipa jaringan, dan kontrol lebih baik saat aplikasi berpindah off‑prem. Bagi tim, ini berarti membeli hasil, bukan jargon. Tuliskan hasil yang diinginkan (mis. “tanpa akses inbound,” “hak paling sedikit ke aplikasi,” “kebijakan konsisten untuk pengguna remote”) dan peta setiap hasil ke kemampuan konkret yang bisa Anda uji.
Keamanan perusahaan menyebar lewat jaringan kepercayaan: reseller, GSI, MSP, dan marketplace cloud. Pendiri bisa meniru ini dengan membangun produk yang siap mitra sejak awal—packaging yang jelas, margin yang dapat diprediksi, playbook deployment, dan metrik bersama. Pemimpin keamanan juga dapat memanfaatkan mitra: gunakan mereka untuk manajemen perubahan, integrasi identitas, dan migrasi bertahap daripada mencoba meng-upskill setiap tim sekaligus.
Mulailah dengan satu kasus penggunaan volume tinggi (sering akses internet atau satu aplikasi kritikal), ukur sebelum/sesudah, dan perluas.
Pertanyaan rollout kunci:
Jangan hanya “menjual keamanan”—jual jalur migrasi. Cerita pemenang biasanya: pain → langkah pertama termudah → kemenangan terukur → ekspansi. Bangun onboarding dan pelaporan yang membuat nilai terlihat dalam 30–60 hari.
Polanya ramah-pendiri adalah melengkapi produk inti dengan aplikasi pendamping yang cepat dibangun (workflow asesmen, pelacak migrasi, kalkulator ROI, portal mitra). Jika Anda ingin membuat ini tanpa membangun ulang pipeline dev warisan, Koder.ai dirancang untuk “vibe-coding” aplikasi full-stack dari chat—berguna untuk mengeluarkan tooling internal atau customer-facing ke produksi cepat, lalu iterasi seiring perkembangan gerakan distribusi Anda.
Jika ingin menggali lebih dalam, lihat /blog/zero-trust-basics dan /blog/sase-vs-sse-overview. Untuk ide pengemasan, kunjungi /pricing.
Zero trust adalah pendekatan di mana keputusan akses dibuat per permintaan berdasarkan identitas, status perangkat, dan konteks, alih-alih menganggap sesuatu aman hanya karena berada “di dalam jaringan”. Secara praktis, ini berarti:
VPN tradisional sering menempatkan pengguna “di dalam jaringan”, yang bisa membuka akses ke sistem lebih dari yang diperlukan. Akses berfokus-aplikasi membalik model itu:
“Inline” berarti lalu lintas diarahkan melalui pos pemeriksaan keamanan sebelum mencapai internet atau aplikasi cloud. Dalam model yang dikirimkan lewat cloud, pos pemeriksaan tersebut berada di titik kehadiran (PoP) terdekat, sehingga penyedia dapat:
Tujuannya adalah keamanan yang konsisten tanpa memaksa lalu lintas kembali lewat kantor pusat.
Backhauling mengirim lalu lintas web dan SaaS pengguna jarak jauh ke pusat data pusat untuk inspeksi, lalu mengirimkannya kembali ke internet. Ini sering gagal karena:
Secure Web Gateway (SWG) melindungi pengguna saat mereka menjelajah internet dan memakai aplikasi SaaS. Kemampuan umum SWG meliputi:
SWG sangat berguna ketika sebagian besar lalu lintas mengarah ke internet dan pengguna tidak berada di belakang firewall korporat tunggal.
Keamanan yang dikirim lewat cloud bisa menyederhanakan operasi, tetapi juga mengubah ketergantungan Anda. Trade-off utama yang harus dinilai:
Pilot yang rendah risiko biasanya berhasil bila ruang lingkupnya sempit dan terukur:
Tujuannya adalah belajar cepat tanpa menjadikan seluruh perusahaan sebagai lingkungan uji.
Mis-konfigurasi sering terjadi karena beralih dari “akses jaringan” ke “akses aplikasi/kebijakan” memaksa tim mendefinisikan intent dengan tepat. Untuk mengurangi risiko:
SSE adalah kontrol keamanan yang dikirim dari cloud (mis. SWG dan akses aplikasi privat) sehingga pengguna mendapat perlindungan konsisten di mana pun mereka berada. SASE menggabungkan model keamanan itu dengan sisi jaringan (biasanya SD-WAN) sehingga konektivitas dan keamanan dirancang bersama.
Dalam istilah pembelian:
Perusahaan besar sering membeli lewat mitra dan membutuhkan kapasitas implementasi. Mitra saluran, SI, dan MSP membantu dengan:
Ekosistem mitra yang kuat bisa menentukan apakah sebuah platform menjadi standar atau berhenti setelah deployment kecil.
