Lanskap Steve Trucking

🌐 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 6 dari 6 dalam bab Memahami Data Perusahaan, bab 4 kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: Strategi Org Adalah Keputusan Lanskap · Berikutnya: bab berikutnya, Kualitas dan Tata Kelola Data

Pertanyaan yang dijawab modul ini: Apa yang diceritakan lanskap nyata kepada kita sebelum kita merancang apa pun?

Bab ini terus menarik kamera mundur: Salesforce sebagai satu dari banyak sistem, jenis-jenis data, sistem-sistem di sekitar Salesforce, cara menggambar lanskap, dan strategi org. Sekarang mari satukan semuanya pada Steve Trucking. Tetapi kita belum akan memperbaiki apa pun. Itulah disiplinnya: gambarkan apa yang ada, susuri setiap panah, dan lihat apa yang diceritakan lanskap kepada kita.

Mulailah dari Apa yang Kita Ketahui

Steve Trucking menjalankan satu org Salesforce, di AS. Service Cloud menangani kasus dari Penerima dan Mitra Ritel; Field Service menjalankan janji temu, kru, dan aplikasi seluler; Experience Cloud memberi Mitra Ritel sebuah portal, yang saat ini hanya dipakai untuk klaim dan laporan; Sales Cloud melacak kontrak mitra dan penawaran untuk DC baru. Jadi Salesforce ditaruh di tengah.

Di sebelah kiri, orang-orangnya: 45 koordinator dispatch yang bekerja di dalam DC milik Mitra Ritel, sekitar 700 anggota kru di 330 truk, 60 agen layanan pelanggan, 40 staf operasional, keuangan, dan penjualan, serta sekitar 300 pengguna dari Mitra Ritel. Itu saja sudah memberi tahu kita sesuatu: ini bukan CRM departemen. Ini platform operasional untuk sebagian besar bisnis. Tetapi ia tetap satu kotak. Sekarang mari lihat apa yang mengelilinginya.

Click to enlarge

Steve Trucking hari ini, sebelum implementasi yang layak. Setiap manifes mendarat di RouteDesk; koordinator mengetik ulang rute ke Salesforce dan titik pemberhentian yang selesai kembali, secara manual; FleetLink tidak punya koneksinya.

Tandai Apa yang Salah

Ini kondisi saat ini, sebelum implementasi yang layak, dan saya menyatakannya di gambar. Lalu saya membuka palet warnanya. Di lanskap sistem yang sudah jadi, saya tidak memakai merah; di kondisi saat ini, saya memakainya. Merah menandai proses yang buruk atau tidak semestinya, putus-putus menandai sesuatu yang dikerjakan manual, dan titik-titik merah menandai koneksi yang tidak ada. Tidak menggambar sebuah panah juga menyatakan sesuatu. Semua itu bukan hiasan: setiap garis merah adalah persyaratan yang menunggu untuk ditulis.

Tiga Mitra, Tiga Integrasi

Ketiga Mitra Ritel mengirim manifes dengan tiga cara berbeda, jadi gambarkan masing-masing secara terpisah.

Keystone menaruh manifes CSV di server SFTP setiap sore, untuk pengiriman dua hari kemudian, dan ingin file status dikirim balik setiap malam. Dua panah: manifes masuk lewat file, dibuka oleh Keystone, dan status keluar lewat file, dibuka oleh RouteDesk. Asinkron, dengan jendela waktu yang lebar.

Redrock mengirim manifes melalui REST API dan mengharapkan pembaruan status lewat webhook saat terjadi. Dua panah, dua mekanisme: Redrock memanggil masuk dengan manifes melalui API, dan RouteDesk memanggil keluar dengan status melalui webhook. Mendekati waktu nyata.

Brightwave mengirim file EDI melalui jaringan pihak ketiga dan mengharapkan pesan status EDI dikirim kembali. Format lain, mekanisme lain.

Konsep bisnis yang sama (manifes, pengiriman, status), tiga integrasi yang sama sekali berbeda. Jangan menyederhanakan gambarnya karena Anda ingin semuanya konsisten. Kenyataannya tidak. Itulah kondisi saat ini.

Lalu susuri. Keystone: bagaimana koneksi SFTP diautentikasi, di mana file mendarat, apa yang mengambilnya, bagaimana kita tahu seluruh file sudah diproses, apa yang terjadi pada baris yang buruk, dan bagaimana Keystone mendengar tentang perubahan sebelum file malam ini? Redrock: bagaimana API-nya diautentikasi, apa yang terjadi ketika salah satu sisi mati, apa yang dihitung sebagai webhook yang berhasil, bagaimana jika status yang sama tiba dua kali? Brightwave: siapa yang menjalankan jaringan EDI, di mana penerjemahannya, pengakuan apa yang kembali? Kita tidak sedang merancang ulang apa pun. Kita sedang menemukan pertanyaan-pertanyaannya. Itulah tugas lanskap.

RouteDesk Masih Ada

RouteDesk adalah alat dispatch dan perutean desktop lama yang dipakai koordinator di setiap DC untuk mengubah manifes menjadi rute. Ia menyimpan riwayat pengiriman delapan tahun, dan dijadwalkan untuk dipensiunkan. Gambarkan saja tetap. Kesalahan umum adalah tidak menggambar sistem yang “akan kita singkirkan.” Kapan? Katakanlah jawabannya delapan belas bulan. Berarti ia bagian dari arsitektur setidaknya selama delapan belas bulan, dan riwayat delapan tahunnya, sekitar lima juta pengiriman, tidak lenyap ketika aplikasinya lenyap. Dan lihat apa yang disingkap lanskap: RouteDesk dan Salesforce tidak terhubung. Kru mengerjakan titik pemberhentian mereka di aplikasi Field Service Salesforce, tetapi rutenya dibuat di RouteDesk, jadi koordinator mengetik ulang rute itu ke Salesforce setiap sore, lalu mengetik ulang titik pemberhentian yang sudah selesai kembali ke RouteDesk agar RouteDesk bisa mengirim status ke para mitra. Sekitar 3.300 titik pemberhentian per hari, dua kali, secara manual. Itu digambar putus-putus dan merah. Hal itu juga memberi tahu Anda bahwa webhook Redrock yang “saat terjadi” sebenarnya tidak benar-benar saat terjadi. Apa yang dimiliki RouteDesk hari ini? Apa yang bergantung padanya? Riwayat apa yang harus bertahan setelahnya, dan di mana: Salesforce, data warehouse, sebuah arsip? Kita belum menjawabnya. Lanskap baru saja menyingkap pertanyaan-pertanyaannya.

FleetLink Adalah Sebuah Pulau

FleetLink, platform telematika, menerima GPS dari setiap truk: sekitar 200.000 pembacaan per hari, setiap truk, setiap menit selama truk berjalan. Dan ia tidak terhubung ke apa pun. Koordinator melihatnya di layar terpisah. Jadi gambarkan FleetLink tanpa panah. Jangan ada garis integrasi ajaib hanya karena kita merasa seharusnya ada.

Lalu hitung nolnya: 200.000 per hari berarti lebih dari 70 juta per tahun. Itu bukan “kami punya data GPS.” Itu sumber streaming dengan banyak nol, berada di luar pengalaman Salesforce. Apakah Salesforce butuh 70 juta pembacaan per tahun? Mungkin tidak semuanya. Itu pertanyaan desain untuk nanti.

Keuangan Punya Kebenarannya Sendiri

ERP keuangan menagih setiap Mitra Ritel per pengiriman, pemasangan, dan pengangkutan barang lama, serta membayar insentif kru. Dan jumlah pengiriman sampai ke sana melalui spreadsheet bulanan. Gambarkan spreadsheet itu. Jangan menggantinya dengan panah API yang rapi karena kita arsitek dan merasa lebih tahu; spreadsheet itu bagian dari arsitektur saat ini. Dan begitu digambar, pertanyaannya bermunculan: siapa yang membuatnya, dari sistem mana, siapa yang memeriksanya, bagaimana jika sebuah pengiriman berubah setelah spreadsheet dikirim, dan angka siapa yang menang? Ada uang yang melekat pada jawaban-jawaban itu.

Snowflake Mendapat Ekspor Mingguan

Snowflake menyimpan analitik operasional dan keuangan, diisi oleh ekspor mingguan. Snowflake tidak bisa melakukannya sendiri; ada sesuatu di tengah yang melakukannya: sebuah job ekspor terjadwal, berjalan di luar Salesforce, yang menarik data melalui Bulk API dan memuatnya ke Snowflake. Di mana analitik tinggal mengikuti di mana data tinggal, dan Snowflake sudah menjadi rumah analitisnya. Tetapi waktunya juga memberi tahu kita sesuatu. “Apa yang terjadi bulan lalu?” Umpan data mingguan sudah cukup. “Di mana pengiriman ini sekarang?” Snowflake bukan tempat saya akan memulai. Perusahaan yang sama, beban kerja berbeda, kesegaran data berbeda, jawaban berbeda.

Identitas Tidak Menjangkau Semua Orang dengan Cara yang Sama

Penyedia identitas perusahaan ditaruh di atas Salesforce. Staf kantor memakai single sign-on. Tetapi koordinator dan kru login dengan kredensial Salesforce. Jadi satu garis kepercayaan dari IdP ke Salesforce akan menyembunyikan separuh ceritanya. Pertanyaan sebenarnya adalah pengguna mana yang login melalui jalur mana, dan itu layak ada di lanskap.

Pengalaman Penerima Punya Celah

Penyedia SMS dan email mengirimi Penerima pesan generik “kiriman Anda dijadwalkan besok” dari RouteDesk. Tidak ada tautan pelacakan. Sementara itu ada sekitar 180.000 kasus per tahun, dan sekitar 60% di antaranya adalah “kiriman saya di mana?”: kira-kira 108.000 kasus per tahun yang menanyakan hal yang sama. Sekarang taruh itu di sebelah FleetLink. Perusahaan tahu di mana truk-truknya. Penerimanya terus menelepon untuk bertanya. Dan sistem yang tahu tidak terhubung ke sistem yang menjawab. Saya belum perlu merancang solusinya. Lanskap sudah menceritakan kisahnya.

Taruh Jumlah Nol di Inventaris

Sekarang hitung apa yang berpindah. Seperti di modul 4, jumlah nol tidak ditaruh di panah; jumlah nol masuk ke inventaris di balik gambar, tempat angka-angka itu akan menentukan mekanismenya ketika kita merancang. Sekitar satu juta pengiriman per tahun, sekitar 3.300 per hari, bertumbuh 30% per tahun; sekitar 1,6 item baris per pengiriman; sekitar delapan pembaruan status per pengiriman, jadi delapan juta pembaruan status per tahun saat ini; empat sampai lima juta foto per tahun, saat ini di ponsel pribadi para kru; sekitar 200.000 pembacaan GPS per hari; sekitar 180.000 kasus per tahun. Panah berlabel “status pengiriman” bukanlah pesan sesekali. Kotak memberi tahu Anda apa yang ada. Panah memberi tahu Anda apa yang berpindah. Jumlah nol memberi tahu Anda apakah asumsi Anda bertahan menghadapi kenyataan.

Click to enlarge

Inventaris di balik lanskap Steve Trucking: volume di samping mekanisme yang akan ditentukannya.

Belum ada arsitektur target, dan saya sudah bisa melihat di mana data penting tinggal, jenisnya apa, seberapa cepat ia berpindah, dan bagaimana sistem-sistem saling bertukar data.

Di luar ujian: apa yang diubah AI. Misalkan Steve Trucking membangun sebuah agen untuk menjawab pertanyaan Penerima “kiriman saya di mana?” Sistem mana yang harus ditanyainya? Salesforce tahu janji temunya, FleetLink tahu di mana truknya, manifes mitra mendefinisikan pengirimannya. Lanskap saat ini adalah peta bagi agen, dan sebelum agen bisa menjawab dengan aman, arsitek harus tahu sistem mana yang otoritatif untuk setiap fakta dan seberapa terkini datanya. Arahkan agen ke sumber yang salah dan data basi akan menjadi jawaban yang terdengar yakin.

Baca Rasa Sakitnya, Jangan Diperbaiki Dulu

Mundur selangkah. Tiga mitra, tiga gaya integrasi. Alat dispatch lama yang menyimpan riwayat delapan tahun, dan koordinator yang mengetik ulang 3.300 titik pemberhentian per hari ke Salesforce dan kembali. Platform telematika dengan 200.000 pembacaan per hari, tidak terhubung. Keuangan menghitung pengiriman dari spreadsheet bulanan. Analitik tertinggal seminggu. Single sign-on untuk sebagian pengguna, tidak untuk yang lain. Tidak ada tautan pelacakan, dan 108.000 kasus per tahun menanyakan di mana kirimannya. Semuanya bertumbuh 30% per tahun.

Itu banyak sekali arsitektur dari satu gambar. Godaannya adalah mulai memperbaikinya. Jangan. Belum. Saya ingin Anda nyaman membiarkan diagram kondisi saat ini tetap jelek, karena kadang kondisi saat ini memang jelek. Intinya bukan membuat orang terkesan dengan gambar yang rapi; intinya adalah pemahaman bersama tentang kenyataan. Merancang ulang sambil mendokumentasikan membuat Anda kehilangan titik acuan. Nanti saya ingin bisa berkata: inilah yang ada, inilah masalah yang kami selesaikan, inilah yang kami ubah, dan inilah alasannya. Bab 6 mulai mengambil keputusan tentang kepemilikan dan identitas, dan Checkpoint 1 menyatukan Bagian 1. Kursus Integration Architect merancang aliran-aliran mitra secara mendalam.

Yang Diputuskan Arsitek di Sini

Pada tahap ini, arsitek belum memutuskan arsitektur target. Keputusannya adalah apakah kondisi saat ini sudah cukup dipahami untuk merancang arsitektur target:

• Sistem, kelompok pengguna, penyimpanan data, dan mitra eksternal mana yang benar-benar ada saat ini.
• Data apa yang melintasi setiap batas penting, ke arah mana, seberapa sering, dan dengan mekanisme apa.
• Di mana data operasional, analitis, streaming, historis, dan tidak terstruktur tinggal saat ini.
• Aliran mana yang membawa volume terbesar dan layak mendapat perhatian lebih awal.
• Celah, langkah manual, sistem yang tidak terhubung, otoritas yang tidak jelas, dan pola yang tidak konsisten mana yang menjadi pertanyaan desain yang eksplisit.

Bab ini dimulai dengan satu gagasan: gambarkan lanskapnya sebelum merancang org. Seandainya saya memulai dari model data Steve Trucking, saya bisa menghabiskan berjam-jam untuk objek dan hubungan sementara FleetLink tetap di luar dengan 200.000 pembacaan per hari, RouteDesk menyimpan riwayat delapan tahun, tiga mitra berbicara dalam tiga bahasa, keuangan memakai spreadsheet, dan seratus ribu kasus per tahun menanyakan di mana sebuah kiriman. Itu bukan pertanyaan model objek. Itu pertanyaan data perusahaan. Gambarkan integrasi yang jelek, spreadsheet-nya, sistem yang katanya akan dipensiunkan. Tuliskan jumlah nolnya. Susuri setiap panah. Barulah Anda siap untuk mengubahnya.

Jelajahi

• Ringkasan Steve Trucking, bagian 2–4, dan diagram lanskapnya (bahasa Inggris).