Jenis-Jenis Data Perusahaan

🌐 Juga tersedia dalam 28 bahasa

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Gambar dibuat dengan AI

Diterjemahkan dengan AI. Belum ditinjau oleh komunitas. Baca dalam bahasa Inggris

Modul 2 dari 6 dalam bab Memahami Data Perusahaan, bab 4 kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: Salesforce Hanyalah Satu dari Banyak Sistem · Berikutnya: Sistem-Sistem di Sekitar Salesforce

Pertanyaan yang dijawab modul ini: Jenis data apa saja yang dimiliki sebuah perusahaan, dan mengapa semuanya seharusnya berada di tempat yang berbeda?

Sebuah rekaman pelanggan. Daftar negara. Sebuah pesanan. Definisi sebuah bidang. Total penjualan lima tahun. Empat juta foto pengiriman. Semuanya data, tetapi secara arsitektur semuanya bukan hal yang sama. Masing-masing berubah secara berbeda, bertumbuh secara berbeda, dipakai secara berbeda, dan dimiliki oleh orang yang berbeda, dan semuanya tidak otomatis harus tinggal di tempat yang sama. Jadi ketika seseorang berkata “kita butuh data ini di Salesforce,” pertanyaan saya berikutnya adalah: data jenis apa ini? Jawabannya mulai memberi tahu saya apa yang harus dilakukan dengannya.

Mulailah dari Jenisnya, Bukan dari Objeknya

Sebagai orang Salesforce, kita menerjemahkan persyaratan menjadi struktur hampir secara instan: pelanggan, Akun; foto, File; status, daftar pilihan. Itu berguna pada akhirnya. Di tingkat perusahaan, saya ingin tahu dulu jenis informasi apa yang sedang saya hadapi. Ada banyak cara untuk mengklasifikasikannya (DAMA body of knowledge adalah rujukan standarnya), dan saya mendapati enam jenis yang berguna: master, referensi, transaksional, metadata, analitis, dan tidak terstruktur. Kategori-kategori itu bukan arsitekturnya. Kategori itu adalah cara untuk mengajukan pertanyaan yang lebih baik.

Data Master: Hal-Hal yang Dikenal Bisnis

Data master menggambarkan hal-hal tahan lama yang menjadi poros bisnis: pelanggan, produk, harga, karyawan, pemasok, lokasi, aset. Di org penjualan Salesforce, itulah Akun dan Kontak Anda, produk dan buku harga Anda. Di Steve Trucking, Mitra Ritel adalah data master. Keystone bukan sebuah kejadian; ia sebuah organisasi yang menjalin hubungan berkelanjutan dengan Steve Trucking. Sembilan pusat distribusi juga merupakan data master.

Data master hidup lebih lama daripada transaksi yang memakainya: satu Mitra Ritel bisa punya jutaan pengiriman. Jadi pertanyaan pertama tentangnya selalu siapa pemiliknya? Mungkin bukan Salesforce. ERP mungkin memiliki produk. Salesforce mungkin memiliki prospek sementara ERP menjadi otoritatif begitu mereka menjadi pelanggan. Platform MDM mungkin memiliki identitas pelanggan di tingkat perusahaan yang dirakit dari beberapa sistem. Bab 6, Data Master dan Identitas, membahasnya secara mendalam. Untuk sekarang, kenali bentuknya.

Data Referensi: Kosakata Bersama dalam Bisnis

Data referensi adalah kosakata terkendali yang dipakai untuk mengklasifikasikan data lain: kode negara, mata uang, kategori produk, kode alasan, status. Status pengiriman Steve Trucking (terjadwal, dimuat, dalam pengiriman, hampir tiba, terkirim, terpasang, pengecualian, dikembalikan) adalah data referensi. Itu bukan pengiriman; itu kata-kata yang dipakai untuk menggambarkan pengiriman.

Kelihatannya kecil dan tidak berbahaya, sering hanya daftar pilihan dengan delapan nilai. Jangan menyamakan kecil dengan tidak penting. Jika Salesforce bilang Delivered, ERP bilang Complete, dan sebuah Mitra Ritel mengirim D, seseorang harus mendefinisikan arti masing-masing dan bagaimana memetakannya. Data referensi adalah tempat asumsi-asumsi integrasi bersembunyi.

Data Transaksional: Apa yang Terjadi

Data transaksional mencatat aktivitas: pesanan dibuat, pembayaran dilakukan, pengiriman selesai, kasus dibuka. Di org penjualan yang sama, itulah penawaran dan baris penawaran, pesanan dan item pesanan, pembayaran: masing-masing merujuk kembali ke seorang pelanggan dan sebuah produk. Satu juta pengiriman Steve Trucking per tahun adalah data transaksional, begitu pula pembaruan statusnya: sekitar delapan per pengiriman, jadi delapan juta perubahan status per tahun, di bisnis yang bertumbuh 30% per tahun.

Itu kurva pertumbuhan yang sama sekali berbeda dari data master. Tiga Mitra Ritel di atas; jutaan baris di bawahnya. Di sinilah Jumlah Nol ala Steve penting: Anda tidak bisa melihat Mitra Ritel → Pengiriman → Status dan memberi bobot yang sama pada setiap kotak. Dengan data transaksional, saya langsung memikirkan volume, kecepatan, retensi, riwayat, pengarsipan, integrasi, dan bagaimana orang benar-benar perlu menemukannya. Bagian 2 menghabiskan banyak waktu di situ.

Metadata: Data tentang Data

Anda sudah bekerja dengan metadata sepanjang kursus: definisi sebuah objek, tipe sebuah bidang, deskripsinya, hubungan-hubungannya. Seluruh perusahaan memilikinya: skema data warehouse, pemetaan integrasi, katalog data, kontrak API, dan untuk setiap bidang ada pemilik, tingkat sensitivitas, definisi, silsilah data, dan aturan retensi. Nilainya adalah data; deskripsi tentang artinya adalah metadata. Seperti dikatakan bab 3, Flag2__c tidak memberi tahu siapa pun apa-apa, dan itu makin penting sekarang ketika AI membaca metadata untuk memahami arti data.

Data Analitis: Data yang Kita Buat dari Data Lain

“Berapa tingkat ketepatan waktu kita per Mitra Ritel selama lima tahun terakhir?” bukanlah transaksi. Itu pertanyaan analitis, yang dijawab dengan menurunkan data baru dari jutaan pengiriman: persentase tepat waktu, tingkat kerusakan, pendapatan per mitra, kualitas pemasangan, tren kru. Dan itu pekerjaan yang berbeda. Dispatcher yang bertanya “di mana titik pemberhentian berikutnya untuk truk 217?” tidak perlu memindai riwayat lima tahun. Pimpinan yang membandingkan kinerja ketepatan waktu lima tahun per wilayah perlu melakukannya. Itulah sebabnya data analitis biasanya tinggal di data warehouse, lakehouse, atau platform analitik yang dibangun untuk pekerjaan itu. Fakta bahwa Salesforce bisa menyimpan sesuatu tidak menjadikan platform operasional itu tempat untuk menjalankan setiap analisis atasnya.

Data Tidak Terstruktur: Yang Tidak Muat dalam Baris

Dokumen, PDF, gambar, audio, video, email, transkrip, artikel pengetahuan. Di Steve Trucking, foto-foto pengiriman: sekitar empat per pengiriman, lebih banyak untuk pemasangan, empat sampai lima juta per tahun. Sebuah foto bukan sekadar satu bidang lagi. Ukurannya besar, ia bisa memperlihatkan bagian dalam rumah seseorang, ia punya aturan retensinya sendiri, dan cara mencarinya berbeda, jika memang dicari.

Jenis ini makin penting setiap tahun, karena AI kini bisa melakukan hal-hal berguna dengan informasi yang dulu berada di luar model terstruktur. Transkrip adalah data. Manual PDF adalah data. Foto pemasangan adalah data. Itu tidak berarti semuanya seharusnya ada di core Salesforce. Itu berarti semuanya seharusnya ada di lanskap.

Click to enlarge

Enam jenis, masing-masing empat pertanyaan. Jawabannya berubah dari jenis ke jenis, dan justru itulah intinya.

Jenis Hanyalah Separuh Pertanyaan: Beban Kerjanya

Mengetahui jenis data yang kita punya belum cukup. Saya juga ingin tahu apa yang kita lakukan dengannya. Ada tiga beban kerja yang penting di sini, dan mencampuradukkannya menghasilkan arsitektur yang buruk.

Operasional: menjalankan bisnis. Seorang dispatcher memperbarui sebuah pengiriman, sebuah kru menyelesaikan sebuah titik pemberhentian, seorang agen membuka sebuah kasus. Banyak pembacaan dan penulisan kecil: cari ini, perbarui itu, tampilkan titik pemberhentian hari ini. Inilah OLTP, online transaction processing (pemrosesan transaksi online), dan Salesforce sangat bagus untuk ini; di sinilah admin dan developer berkarya.

Analitis: memahami bisnis. Setiap pengiriman selama lima tahun, dikelompokkan per mitra dan DC, dibandingkan dari tahun ke tahun, digabungkan dengan data keuangan. Sekarang kita memindai dan mengagregasi. Inilah OLAP, online analytical processing (pemrosesan analitis online), dan untuk itulah data warehouse, lakehouse, dan platform analitik dibangun. Sederhananya: org menjalankan bisnis; data warehouse dan data lake menganalisisnya. Kesalahan klasiknya adalah menaruh beban kerja itu di platform operasional lalu terkejut ketika jumlah nolnya bertambah. Jika seseorang ingin memindai riwayat dalam jumlah sangat besar berulang kali, jangan memperlakukannya sebagai “sekadar laporan lain.” Tanyakan apakah itu platform yang tepat. Bagian 2 kembali membahas ini di Merancang untuk Skala (coming soon) (jangan jadikan core sebagai data warehouse Anda), dan Bagian 3 menunjukkan bagaimana struktur analitis dibangun di Melampaui Relasional (coming soon).

Streaming: data yang bergerak. Event, telemetri, perubahan status, pembacaan sensor. Truk-truk Steve Trucking mengirim sekitar 200.000 pembacaan GPS per hari. Dispatcher peduli di mana truk 217 berada saat ini. Apakah Salesforce perlu menyimpan setiap pembacaan menit demi menit dari setiap truk? Mungkin tidak. “Di mana truknya sekarang?” dan “bagaimana tren efisiensi rute kuartal lalu?” berasal dari sumber yang sama dan mengarah ke keputusan penyimpanan yang sama sekali berbeda.

Seberapa Cepat Data Perlu Berpindah?

Lalu latensi. Di kelas saya menjelaskannya begini: waktu nyata adalah menunggu di pintu sampai seseorang kembali. Anda menyuruhnya pergi lalu berdiri di sana, karena Anda tidak bisa melanjutkan sampai ia kembali. Itu sinkron. Mendekati waktu nyata adalah melihatnya pergi lalu mengerjakan hal lain; ketika ia kembali tak lama kemudian, Anda menanganinya. Itu asinkron. Lalu ada batch: tidak ada yang keluar pintu satu per satu. Datanya menunggu dan berpindah sebagai satu kelompok sesuai jadwal: per jam, setiap beberapa jam, atau harian. Ada banyak situasi di mana batch sudah cukup, dan ada yang tidak. Mengetahui mana yang mana adalah tugasnya. Ketiganya bukan sekadar istilah integrasi; ketiganya pilihan arsitektur.

Ambil integrasi ERP yang umum. Sebuah produk baru dibuat di ERP pukul 11 pagi. Apakah tim penjualan benar-benar perlu menjualnya sebelum tengah hari? Saya pernah melihat kedua jawabannya. Sebagian klien menginginkannya secepat mungkin; yang lain berkata, jika kami belum mengirimkan SKU itu kepada Anda, kami tidak bisa berharap Anda sudah menjualnya. Jadi produk biasanya diperbarui harian, kadang lebih cepat. Pelanggan, paling tidak harian; saya pernah melihat per jam, dan dalam kasus ekstrem mendekati waktu nyata. Pesanan berbeda: pemenuhan harus dimulai, jadi mendekati waktu nyata. Tenaga penjual menutup transaksi lalu lanjut ke pekerjaan berikutnya, dan pesanannya mendarat di ERP dalam hitungan detik sampai satu atau dua menit. Tidak ada satu latensi yang benar untuk “data perusahaan.” Tanyakan apa yang benar-benar dibutuhkan bisnis, dan jangan membuat semuanya waktu nyata hanya karena terdengar mengesankan. Waktu nyata ada harganya.

Empat Pertanyaan di Balik Kategori

Anda tidak perlu berkeliling mengumumkan “ini data transaksional!” Klasifikasi itu ada untuk memicu empat pertanyaan tentang setiap kumpulan data yang penting:

• Siapa pemiliknya? Sistem mana yang otoritatif? Saya memecahnya menjadi tiga: di mana ia dibuat, di mana ia diedit, dan di mana ia dirujuk? Bab 6 membahasnya secara mendalam (Dibuat, Diedit, Dirujuk, dan Seberapa Cepat?).
• Seberapa cepat ia berubah? Setahun sekali, harian, puluhan sampai ratusan kali per detik?
• Seberapa besar ia bisa tumbuh? Sepuluh rekaman, sepuluh ribu, sepuluh juta, sepuluh miliar?
• Bagaimana siklus hidupnya? Apakah ia hidup selamanya, diarsipkan, harus dihapus, atau kehilangan nilai seiring waktu?

Keempat pertanyaan itu memberi tahu saya jauh lebih banyak daripada “bisakah Salesforce menyimpan ini?” Dan keempatnya menyatukan apa yang sudah kita pelajari: kepemilikan, siklus hidup, Jumlah Nol, dan tempat data tinggal.

Satu Bisnis Menghasilkan Semua Jenis

Di Steve Trucking, Mitra Ritel adalah data master; kosakata status adalah data referensi; setiap pengiriman adalah transaksional; definisi bidang-bidangnya adalah metadata; scorecard ketepatan waktu lima tahun adalah analitis; foto pemasangan tidak terstruktur; dan umpan GPS adalah streaming. Semuanya “data Steve Trucking.” Tidak satu pun dari itu berarti semuanya seharusnya ada di database yang sama. Itulah pergeserannya.

Di luar ujian: apa yang diubah AI. Untuk menjawab satu pertanyaan, sebuah agen mungkin butuh rekaman pelanggan yang terstruktur, transaksi terbaru, manual PDF, transkrip layanan, dan telemetri langsung. Data tidak terstruktur dan streaming menjadi bagian utama arsitektur bahkan ketika tidak seharusnya ada di database CRM, dan arsitek tetap harus tahu siapa pemilik setiap sumber, seberapa terkini datanya, dan apakah agen sebaiknya memercayainya.

Yang Diputuskan Arsitek di Sini

• Jenis data apa setiap kumpulan data penting, dan siapa pemiliknya.
• Apakah beban kerjanya operasional, analitis, streaming, atau campuran.
• Seberapa cepat ia berubah, dan seberapa cepat sistem lain benar-benar perlu melihat perubahannya.
• Bagaimana volume dan siklus hidup membentuk tempat tinggalnya dan berapa lama.
• Apakah Salesforce seharusnya memilikinya, menyimpan salinannya, merujuknya, atau membiarkannya di tempat yang lebih cocok untuk beban kerjanya.

Ketika seseorang memberi Anda sebuah persyaratan, jangan langsung melompat ke objek mana, bidang mana, API mana. Pertama tanyakan jenis data apa itu, siapa pemiliknya, seberapa cepat ia berubah, seberapa besar ia tumbuh, berapa lama ia hidup, dan apa yang ingin kita lakukan dengannya. Sebuah Akun, sebuah event pengiriman, agregat lima tahun, dan sebuah foto bisa sama-sama penting bagi bisnis yang sama tanpa menjadi masalah arsitektur yang sama.

Jelajahi

• DAMA International, DAMA-DMBOK: Data Management Body of Knowledge, edisi ke-2 (2017), bahasa Inggris: rujukan standar untuk kategori data dan manajemen data.
• Ringkasan Steve Trucking, bagian 4 (volume), bahasa Inggris.