Steve Trucking'in Sistem Haritası

🌐 28 dilde daha mevcut

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

Görsel yapay zekâ ile üretilmiştir

Yapay zekâ ile çevrildi. Henüz topluluk tarafından incelenmedi. İngilizcesini oku

Data Architect kursunun 4. bölümü olan Kurumsal Veriyi Anlamak bölümündeki 6 modülden 6.‘sı. Her modül kendi başına okunabilir. Önceki: Org Stratejisi Bir Harita Kararıdır · Sonraki: sonraki bölüm, Veri Kalitesi ve Yönetişim

Bu modülün yanıtladığı soru: Gerçek bir harita, herhangi bir şey tasarlamadan önce bize ne söyler?

Bu bölüm kamerayı geri çekiyordu: pek çok sistemden biri olarak Salesforce, veri türleri, Salesforce’u çevreleyen sistemler, haritanın nasıl çizileceği ve org stratejisi. Şimdi hepsini Steve Trucking üzerinde bir araya getirelim. Ama henüz hiçbir şeyi düzeltmeyeceğiz. Disiplin budur: var olanı çizin, her oku yürüyün ve haritanın size ne söylediğini görün.

Bildiklerimizle Başlayın

Steve Trucking ABD’de tek bir Salesforce org’u çalıştırıyor. Service Cloud, Alıcılardan ve Perakende Ortaklarından gelen vakaları yönetiyor; Field Service randevuları, ekipleri ve mobil uygulamayı yürütüyor; Experience Cloud, Perakende Ortaklarına bugün yalnızca talepler ve raporlar için kullanılan bir portal sağlıyor; Sales Cloud ortak sözleşmelerini ve yeni DC’ler için teklifleri takip ediyor. Dolayısıyla Salesforce ortaya gider.

Solda insanlar: Perakende Ortaklarının DC’lerinde çalışan 45 sevk koordinatörü, 330 kamyonda yaklaşık 700 ekip üyesi, 60 müşteri hizmetleri temsilcisi, 40 operasyon, finans ve satış çalışanı ve yaklaşık 300 Perakende Ortağı kullanıcısı. Bu bile bize bir şey söyler: bu bir departman CRM’i değil. İşin büyük kısmı için operasyonel bir platform. Ama hâlâ tek bir kutu. Şimdi onu neyin çevrelediğine bakalım.

Click to enlarge

Steve Trucking bugün, düzgün bir uygulamadan önce. Her yük listesi RouteDesk’e düşer; koordinatörler rotaları Salesforce’a, tamamlanmış durakları da geri, elle yeniden girer; FleetLink’in bağlantısı eksik.

Neyin Yanlış Olduğunu İşaretleyin

Bu, düzgün bir uygulamadan önceki mevcut durumdur ve bunu çizimin üzerinde söylerim. Sonra renk paletini açarım. Bitmiş bir sistemin haritasında kırmızı kullanmam; mevcut durumda kullanırım. Kırmızı kötü ya da uygunsuz bir süreci, kesikli çizgi elle yapılan bir şeyi, kırmızı noktalar da eksik bir bağlantıyı işaretler. Bir oku dışarıda bırakmak da bir şey söyler. Bunların hiçbiri süs değildir: her kırmızı çizgi, yazılmayı bekleyen bir gereksinimdir.

Üç Ortak, Üç Entegrasyon

Üç Perakende Ortağı yük listelerini üç farklı şekilde gönderiyor; bu yüzden her birini ayrı çizin.

Keystone her öğleden sonra, iki gün sonraki teslimat için bir SFTP sunucusuna CSV yük listesi bırakıyor ve her gece geri bir durum dosyası istiyor. İki ok: Keystone’un açtığı, dosyayla gelen yük listesi ve RouteDesk’in açtığı, dosyayla giden durum. Eşzamansız, geniş bir zamanlama aralığıyla.

Redrock yük listelerini bir REST API aracılığıyla gönderiyor ve durum güncellemelerini gerçekleştikleri anda webhook ile bekliyor. İki ok, iki mekanizma: Redrock yük listeleriyle API üzerinden içeriyi çağırıyor, RouteDesk de durumla webhook üzerinden dışarıyı çağırıyor. Gerçeğe yakın zaman.

Brightwave EDI dosyalarını üçüncü taraf bir ağ üzerinden gönderiyor ve geri EDI durum mesajları bekliyor. Başka bir biçim, başka bir mekanizma.

Aynı iş kavramları (yük listesi, teslimat, durum), bambaşka üç entegrasyon. Tutarlı olmalarını istediğiniz için çizimi basitleştirmeyin. Tutarlı değiller. Mevcut durum bu.

Sonra onları yürüyün. Keystone: SFTP bağlantısı nasıl kimlik doğruluyor, dosya nereye düşüyor, onu ne alıyor, tüm dosyanın işlendiğini nasıl biliyoruz, hatalı bir satıra ne oluyor ve Keystone bir değişikliği bu geceki dosyadan önce nasıl duyuyor? Redrock: API nasıl kimlik doğruluyor, taraflardan biri çöktüğünde ne oluyor, başarılı bir webhook ne sayılıyor, aynı durum iki kez gelirse ne oluyor? Brightwave: EDI ağını kim işletiyor, dönüşüm nerede, hangi alındılar geri geliyor? Hiçbir şeyi yeniden tasarlamıyoruz. Soruları keşfediyoruz. Haritanın işi bu.

RouteDesk Hâlâ Orada

RouteDesk, koordinatörlerin her DC’de yük listelerini rotalara dönüştürmek için kullandığı eski masaüstü sevk ve rota planlama aracıdır. Sekiz yıllık teslimat geçmişini tutuyor ve emekliye ayrılması planlanıyor. Yine de çizin. Yaygın bir hata, “kurtulacağımız” sistemi dışarıda bırakmaktır. Ne zaman? Diyelim ki yanıt on sekiz ay. O halde en az on sekiz ay boyunca mimarinin bir parçasıdır ve sekiz yıllık geçmişi, yaklaşık beş milyon teslimat, uygulama gittiğinde yok olmaz. Ve haritanın neyi açığa çıkardığına bakın: RouteDesk ile Salesforce bağlı değil. Ekipler duraklarını Salesforce’un Field Service uygulamasında işliyor, ama rotalar RouteDesk’te oluşturuluyor; bu yüzden koordinatörler her akşam onları Salesforce’a yeniden giriyor, sonra RouteDesk ortaklara durum gönderebilsin diye tamamlanmış durakları RouteDesk’e geri giriyor. Günde yaklaşık 3.300 durak, iki kez, elle. Bu çizimde kesikli ve kırmızıdır. Ayrıca size Redrock’ın “gerçekleştikleri anda” webhook’unun aslında gerçekleştikleri anda olmadığını da söylüyor. RouteDesk bugün neyin sahibi? Ona ne bağlı? Hangi geçmişin ondan sonra da yaşaması gerekiyor ve nerede: Salesforce’ta mı, ambarda mı, bir arşivde mi? Henüz yanıtlamıyoruz. Harita yalnızca soruları açığa çıkardı.

FleetLink Bir Ada

Telematik platformu FleetLink her kamyondan GPS verisi alıyor: günde yaklaşık 200.000 okuma, her kamyon, çalıştığı her dakika. Ve hiçbir şeye bağlı değil. Koordinatörler ona ayrı bir ekranda bakıyor. Öyleyse FleetLink’i hiç oksuz çizin. Olması gerektiğini düşündüğümüz için sihirli bir entegrasyon çizgisi yok.

Sonra sıfırları sayın: günde 200.000, yılda 70 milyonun üzerinde eder. Bu “GPS verimiz var” demek değil. Salesforce deneyiminin dışında duran, çok sıfırlı bir akış kaynağı. Salesforce’un yılda 70 milyon okumaya ihtiyacı var mı? Muhtemelen hepsine değil. Bu sonraya kalan bir tasarım sorusu.

Finansın Kendi Gerçeği Var

Finans ERP’si her Perakende Ortağını teslimat, kurulum ve eski ürün götürme başına faturalandırıyor ve ekip teşviklerini ödüyor. Ve teslimat sayıları ona aylık bir elektronik tabloyla ulaşıyor. Elektronik tabloyu çizin. Mimarız ve daha iyisini biliyoruz diye onu düzenli bir API okuyla değiştirmeyin; mevcut mimarinin bir parçası. Ve çizildiğinde sorular gelir: onu kim hazırlıyor, hangi sistemden, kim kontrol ediyor, gönderildikten sonra bir teslimat değişirse ne oluyor ve kimin sayısı geçerli? Yanıtlara para bağlı.

Snowflake Haftalık Bir Dışa Aktarım Alıyor

Snowflake, haftalık bir dışa aktarımla beslenen operasyon ve finans analitiğini tutuyor. Snowflake bunu kendisi yapamaz; ortadaki bir şey yapar: Salesforce dışında çalışan, Bulk API aracılığıyla veri çekip Snowflake’e yükleyen zamanlanmış bir dışa aktarım işi. Analitiğin yaşadığı yer verinin yaşadığı yeri izler ve Snowflake zaten analitiğin evi. Ama zamanlama da bize bir şey söylüyor. “Geçen ay ne oldu?” Haftalık bir akış yeterli. “Bu teslimat şu an nerede?” Başlayacağım yer Snowflake değil. Aynı kurum, farklı iş yükü, farklı güncellik, farklı yanıt.

Kimlik Herkese Aynı Yoldan Ulaşmıyor

Kurumsal kimlik sağlayıcı Salesforce’un üstüne gider. Ofis çalışanları tek oturum açma kullanıyor. Ama koordinatörler ve ekipler Salesforce kimlik bilgileriyle oturum açıyor. Dolayısıyla IdP’den Salesforce’a tek bir güven çizgisi hikâyenin yarısını gizlerdi. Asıl soru hangi kullanıcıların hangi yoldan oturum açtığıdır ve bu haritaya aittir.

Alıcı Deneyiminde Bir Boşluk Var

SMS ve e-posta sağlayıcısı Alıcılara RouteDesk’ten genel bir “teslimatınız yarın” mesajı gönderiyor. Takip bağlantısı yok. Bu arada yılda yaklaşık 180.000 vaka var ve bunların yaklaşık %60’ı “teslimatım nerede?”: yılda kabaca 108.000 vaka aynı soruyu soruyor. Şimdi bunu FleetLink’in yanına koyun. Şirket kamyonlarının nerede olduğunu biliyor. Alıcıları sormak için aramaya devam ediyor. Ve bilen sistem, yanıt veren sisteme bağlı değil. Çözümü henüz tasarlamam gerekmiyor. Harita hikâyeyi zaten anlatıyor.

Sıfırları Envantere Koyun

Şimdi neyin hareket ettiğini sayın. 4. modülde olduğu gibi sıfırlar oklara gitmez; resmin arkasındaki envantere gider ve tasarım yaparken mekanizmaları orada belirler. Yılda yaklaşık bir milyon teslimat, günde yaklaşık 3.300, yılda %30 büyüyor; her biri yaklaşık 1,6 satır kalemi; her biri yaklaşık sekiz durum güncellemesi, yani bugün yılda sekiz milyon durum güncellemesi; yılda dört ila beş milyon fotoğraf, şu anda ekiplerin kendi telefonlarında; günde yaklaşık 200.000 GPS okuması; yılda yaklaşık 180.000 vaka. “Teslimat durumu” etiketli bir ok ara sıra gelen bir mesaj değildir. Kutular size neyin var olduğunu söyler. Oklar neyin hareket ettiğini söyler. Sıfırlar ise varsayımlarınızın gerçekliğe dayanıp dayanmadığını söyler.

Click to enlarge

Steve Trucking’in haritasının arkasındaki envanter: hacim, belirleyeceği mekanizmanın yanında.

Henüz hedef mimari yok ve önemli verinin nerede yaşadığını, ne tür olduğunu, ne hızla hareket ettiğini ve sistemlerin onu nasıl alıp verdiğini şimdiden görebiliyorum.

Sınavın ötesinde: yapay zekânın değiştirdikleri. Steve Trucking’in bir Alıcının “teslimatım nerede?” sorusunu yanıtlamak için bir ajan inşa ettiğini varsayın. Hangi sisteme sormalı? Salesforce randevuyu biliyor, FleetLink kamyonun nerede olduğunu biliyor, teslimatı ortağın yük listesi tanımladı. Mevcut harita ajanın haritasıdır ve ajan güvenle yanıt verebilmeden önce mimar her olgu için hangi sistemin esas olduğunu ve ne kadar güncel olduğunu bilmek zorundadır. Bir ajanı yanlış kaynağa yönlendirin, bayat veri kendinden emin bir yanıta dönüşür.

Acıyı Okuyun, Henüz Düzeltmeyin

Geri çekilin. Üç ortak, üç entegrasyon tarzı. Sekiz yıllık geçmişi tutan eski bir sevk aracı ve günde 3.300 durağı Salesforce’a ve geri elle yeniden giren koordinatörler. Günde 200.000 okumalı, bağlantısız bir telematik platformu. Teslimatları aylık bir elektronik tablodan sayan finans. Bir hafta geriden gelen analitik. Bazı kullanıcılar için tek oturum açma, diğerleri için değil. Takip bağlantısı yok ve yılda 108.000 vaka bir teslimatın nerede olduğunu soruyor. Hepsi yılda %30 büyüyor.

Tek bir resimden çok fazla mimari. Düzeltmeye başlama isteği gelir. Yapmayın. Henüz değil. Bir mevcut durum diyagramını çirkin bırakmaktan rahatsız olmamanızı istiyorum, çünkü bazen mevcut durum çirkindir. Amaç kimseyi temiz çizimle etkilemek değil; gerçekliğin ortak bir anlayışıdır. Belgelerken yeniden tasarlarsanız başlangıç noktasını kaybedersiniz. Sonra şunu söyleyebilmek isterim: var olan buydu, çözdüğümüz sorun buydu, değiştirdiğimiz şey buydu ve nedeni bu. 6. bölüm sahiplik ve kimlik hakkında kararlar vermeye başlıyor ve 1. Kontrol Noktası 1. Kısım’ı bir araya getiriyor. Integration Architect kursu ortak akışlarını derinlemesine tasarlıyor.

Mimarın Burada Karar Verdikleri

Bu aşamada mimar hedef mimariye karar vermiyor. Karar, mevcut durumun bir hedef tasarlayacak kadar iyi anlaşılıp anlaşılmadığıdır:

• Bugün gerçekte hangi sistemlerin, kullanıcı kitlelerinin, veri depolarının ve harici ortakların var olduğu.
• Her önemli sınırı hangi verinin, hangi yönde, ne sıklıkla ve hangi mekanizmayla geçtiği.
• Operasyonel, analitik, akış, tarihsel ve yapılandırılmamış verinin şu an nerede yaşadığı.
• Hangi akışların en fazla hacmi taşıdığı ve erken ilgiyi hak ettiği.
• Hangi boşlukların, manuel adımların, bağlantısız sistemlerin, belirsiz yetkilerin ve tutarsız kalıpların açık tasarım sorularına dönüştüğü.

Bu bölüm tek bir fikirle başladı: org’u tasarlamadan önce haritayı çizin. Steve Trucking’in veri modeliyle başlasaydım, FleetLink günde 200.000 okumayla dışarıda dururken, RouteDesk sekiz yıllık geçmişi tutarken, üç ortak üç dil konuşurken, finans bir elektronik tablo kullanırken ve yılda yüz bin vaka bir teslimatın nerede olduğunu sorarken saatlerimi nesneler ve ilişkiler üzerinde harcayabilirdim. Bunlar nesne modeli soruları değil. Kurumsal veri sorularıdır. Çirkin entegrasyonları, elektronik tabloyu, sözde emekliye ayırdığınız sistemi çizin. Sıfırları yazın. Her oku yürüyün. O zaman onu değiştirmeye hazırsınız.

Daha Fazlası

• Steve Trucking senaryo özeti, 2–4. kısımlar ve harita diyagramı (İngilizce).