Entegrasyon Bir Bağlantı Değil, Şehrin Ulaşım Planıdır

Çocukken en sevdiğim oyunlar genellikle yönetim ve simülasyon oyunlarıydı. SimCity’de şehirler kurar, bir belediye başkanı olarak o şehirleri yönetir ve yaşayanların mutluluğunu mümkün olduğunca yüksek tutmaya çalışırdım. Sanırım çocukluğumda en çok vakit geçirdiğim oyun SimCity olabilir. Dinosaur Polo Club’ın Mini Motorways ve Mini Metro oyunlarının yakın zamanda ilgimi bu kadar çekmesinin nedeni de muhtemelen bu. Ancak bu iki oyunu artık çocukluğumdakinden farklı bir gözle oynadığımı fark ettim. Her zaman söylerim: İnsan CRM kavramına bir kez bulaştığında, bu alanda yazılımlar geliştirdiğinde ya da kurumlara çözümler sunduğunda hayata bakışı değişiyor. Günlük işlerini planlama biçiminden evindeki bir dolabı düzenlemesine kadar her yerde süreçleri, ilişkileri, eksikleri ve iyileştirme imkanlarını görmeye başlıyor. 2001 yılında Siebel Systems ile tanışıp ilk projemi gerçekleştirdiğimde, ardından bugün Microsoft Dynamics 365 olarak bildiğimiz Microsoft CRM 1.0 versiyonu ile 2003 yılında hayatıma girdiğinde, bir kurum için bütünsel çözüm üretmenin ne anlama geldiğini daha iyi kavradım. Bir kurumsal yapının da tıpkı bir şehir gibi farklı bölgelerden, süreçlerden, insanlardan ve bu parçaları birbirine bağlayan yollardan oluştuğunu gördüm. Bugün şehir kurma ve yönetme oyunlarını oynarken başka bir şeyi daha net görebiliyorum: Bu oyunlarda şehri büyüten kararlar, aynı zamanda onu giderek karmaşıklaştırıyor. Başlangıçta pratik görünen her yeni yol, bağlantı veya çözüm; büyüme hesaba katılmadan uygulandığında ileride sistemin en büyük darboğazına dönüşebiliyor. Aynı durum, benzer bir bakış açısıyla hayata geçirilen kurumsal projelerde de yaşanıyor. Bu nedenle, oyunlarda kurduğumuz şehirlerle kurumsal projelerde oluşturduğumuz veri mimarileri ve entegrasyonlar arasındaki benzerliği anlatmak istedim. Çünkü ister bir şehir ister bir CDP ve CRM ekosistemi kuruyor olalım, bugün attığımız her adım gelecekte oluşacak trafiği, büyümeyi ve yönetim kapasitesini doğrudan belirliyor.

CDP ve CRM projelerinde bugünün ihtiyaçlarını karşılarken yarının veri trafiğini yönetebilecek bir mimari nasıl kurulur?

Bir şehrin nüfusu henüz azken yolları gelişigüzel açmak kolay ve eğlencelidir. Birkaç mahalle, sınırlı sayıda araç ve düşük trafik varken hemen her yol işe yarar. İki bölge arasında ulaşım gerektiğinde yeni bir bağlantı açılır; üçüncü bölge büyüdüğünde ona da ayrı bir yol yapılır. Kısa vadede sorun çözülmüş görünür. Ancak şehir büyümeye başladığında tablo değişir. Yeni yerleşim alanları kurulur, nüfus artar, iş merkezleri çoğalır ve insanların hareket alışkanlıkları farklılaşır. Daha önce yeterli görünen yollar darboğaza dönüşür. Bir bölgede yapılan çalışma bütün şehrin trafiğini etkiler. Alternatif güzergahların bulunmaması, merkezi kavşakların ve trafik ışıklarının yanlış tasarlanması ve toplu taşıma planının geç yapılması, büyümeyi pahalı ve sancılı hale getirir. Entegrasyon projelerinde de benzer bir durum yaşanır. ERP ile CRM arasında veri akışını kurmak, web sitesinden gelen formları satış ekibine ulaştırmak veya çağrı merkezi kayıtlarını müşteri profiline bağlamak başlangıçta birkaç teknik bağlantıdan ibaret görünebilir. Fakat kurum büyüdükçe bu bağlantılar, şirketin veri ulaşım sistemine dönüşür. Bu nedenle entegrasyon yalnızca “iki uygulamayı konuşturma” işi değildir. Entegrasyon mimarisi; verinin hangi sistemden çıkacağını, hangi yollardan geçeceğini, nerede zenginleşeceğini, kimler tarafından kullanılacağını ve büyüyen organizasyonda nasıl yönetileceğini belirleyen uzun vadeli bir şehir planıdır. Özellikle CDP ve CRM projelerinde bu planın projenin başında yapılması kritik öneme sahiptir.

Haritadaki her bölge bir sistem, her yol bir veri akışıdır

Mini Motorways’te göründüğü gibi haritaya yalnızca bir şehir haritası olarak değil, kurumsal teknoloji ekosisteminin temsili olarak bakalım. Haritadaki farklı bölgeler; CRM, ERP, e-ticaret, mobil uygulama, çağrı merkezi, sadakat sistemi, pazarlama otomasyonu, servis yönetimi ve veri ambarı gibi uygulamaları temsil edebilir. Küçük işaretler müşterileri, işlemleri veya temas noktalarını; yollar ise bu sistemler arasındaki veri akışlarını gösterir. Pembe ana arterler yüksek hacimli ve kritik entegrasyonları, ara yollar daha düşük yoğunluktaki operasyonel bağlantıları temsil ediyor olsun. Köprüler ve kavşaklar ise API yönetimi, entegrasyon platformu, olay akışı altyapısı veya ortak veri modeli gibi merkezi mimari bileşenlerdir. Bu benzetme bize önemli bir gerçeği gösterir: Bir yolun çalışması, ulaşım sisteminin doğru tasarlandığı anlamına gelmez. Benzer şekilde, bir entegrasyonun bugün veri taşıyor olması da mimarinin geleceğe hazır olduğunu göstermez. Asıl soru şudur: Bu yapı, uygulama sayısı beşten yirmi beşe; müşteri sayısı yüz binden on milyona; kullanıcı sayısı elliden iki bine çıktığında da yönetilebilir olacak mı? Entegrasyon mimarisi bu soruya proje başlamadan cevap vermelidir.

En sık yapılan hata: Her yeni ihtiyaç için yeni bir yol açmak

Kurumlarda entegrasyonlar çoğu zaman ihtiyaç ortaya çıktıkça geliştirilir. Web sitesi CRM’e bağlanır. Ardından ERP’den CRM’e müşteri bilgisi aktarılır. Daha sonra mobil uygulama CRM’den veri almaya başlar. Pazarlama platformu eklendiğinde CRM ile onun arasında iki yeni bağlantı kurulur. Bir süre sonra veri ambarı, çağrı merkezi ve müşteri hizmetleri uygulamaları da bu ağa katılır. İki veya üç uygulamanın bulunduğu küçük bir yapıda bu model hızlı sonuç verebilir. Ancak uygulama sayısı arttığında bağlantı sayısı katlanarak büyür. On sistemin birbirleriyle çeşitli yönlerde veri alışverişi yaptığı bir ortamda yalnızca uygulamalar değil; veri formatları, kimlik eşleştirmeleri, hata yönetimi, güvenlik kuralları ve iş süreçleri de birbirine bağımlı hale gelir. Sonuçta kurumun önünde haritadaki karmaşık bir yol ağı belirir: - Aynı müşteri farklı sistemlerde farklı kimliklerle tutulur. - Bir alan değiştirildiğinde birden fazla entegrasyon etkilenir. - Verinin hangi sistemden geldiği belirsizleşir. - Hatalı kayıtların nerede oluştuğunu bulmak zorlaşır. - Sistemlerden biri geçici olarak durduğunda zincirleme sorun yaşanır. - Yeni bir uygulamanın devreye alınması aylar sürebilir. - Entegrasyonların bilgisi belirli kişi veya tedarikçilere bağımlı kalır.

Bu aşamada sorun tek tek yolların kalitesi değildir. Sorun, yolların ortak bir ulaşım politikası olmadan yani geleceği düşünmeden yapılmış olmasıdır. Bu gelecek büyümenin öngörülmesi ve o yoldan geçecek araçların sayısının ne kadar artabileceğini tahminlemeleriyle başlar. Burada çalıştığınız danışmanların önemi yani şehir planlayıcıların rolleri çok önemli sanırım bunu söylemeye gerek yok. Uzman ve Yaratıcı danışmanlarla çalışmak sizi uzun vadeli bir yapılanmaya götürecektir.

CRM ve CDP aynı şehirde farklı görevler üstlenir

Doğru mimariyi kurabilmek için CRM ile CDP’nin görevlerini ayırmak gerekir. CRM, müşteriyle kurulan ilişkinin operasyonel hafızasıdır. Satış fırsatları, teklifler, görüşmeler, servis talepleri, görevler ve müşteri temsilcilerinin aksiyonları burada yönetilir. Microsoft Dynamics 365 gibi bir CRM çözümü, satış, müşteri hizmetleri ve ilişki yönetimi süreçlerinin merkezinde konumlanabilir. CDP ise müşterinin farklı kanallarda bıraktığı izleri bir araya getirerek birleşik bir müşteri görünümü oluşturmayı amaçlar. Web davranışları, mobil uygulama etkinlikleri, e-ticaret işlemleri, kampanya tepkileri, sadakat hareketleri ve diğer temas verileri CDP içinde kimlik çözümleme, segmentasyon ve aktivasyon amacıyla kullanılabilir. Basit bir ifadeyle: - CRM, “Bu müşteriyle hangi ilişkiyi yürütüyoruz?” sorusuna cevap verir. - CDP, “Bu müşteriyi bütün temas noktalarında ne kadar iyi tanıyoruz?” sorusuna cevap verir. Bu iki yapı birbirinin alternatifi değildir. Doğru tasarlandığında birbirini besler. CDP, müşterinin davranış ve tercih sinyallerini CRM’e aktarabilir. CRM’de gerçekleşen satış, servis veya temsilci etkileşimleri de CDP’deki müşteri profilini zenginleştirebilir. Ancak bu ilişkinin sağlıklı kurulabilmesi için hangi verinin hangi sistemde üretileceği ve hangi sistemin hangi veri alanında otorite kabul edileceği önceden belirlenmelidir. Aksi takdirde CRM, CDP, ERP ve pazarlama platformu arasında “doğru müşteri kaydı hangisi?” tartışması başlar.

İlk karar teknoloji değil, veri sahipliği olmalıdır

Entegrasyon mimarisinin başlangıç noktası kullanılacak araç değildir. İlk karar, verinin sahipliğidir. Müşterinin ticari unvanını hangi sistem yönetir? İletişim izninin ana kaydı nerede tutulur? Güncel adres bilgisi CRM’den mi, ERP’den mi alınır? Sadakat puanının sahibi hangi uygulamadır? Bir müşterinin tekil kimliği nasıl oluşturulur? Farklı kanallarda oluşan kayıtların aynı kişiye ait olduğu nasıl anlaşılır? Bu sorular cevaplanmadan geliştirilen entegrasyonlar, belirsizliği yalnızca sistemler arasında taşır. Her önemli veri kümesi için bir ana kayıt veya ana veri kaynağı, yani güvenilir kaynak belirlenmelidir. Diğer sistemler bu veriyi kullanabilir, zenginleştirebilir veya kendi operasyonel ihtiyaçları için kopyalayabilir. Ancak ana kaynağın hangisi olduğu tartışmasız olmalıdır. Örneğin: - Finansal müşteri ve fatura verisinin ana kaynağı ERP olabilir. - Satış fırsatlarının ve müşteri temsilcisi aktivitelerinin ana kaynağı Microsoft Dynamics 365 olabilir. - Davranışsal olaylar ve birleşik profil CDP’de yönetilebilir. - İletişim izinleri, mevzuat ve süreç tasarımına bağlı olarak özel bir izin yönetimi sisteminde tutulabilir. - 1Page-Platform gibi müşteri etkileşimi veya deneyim katmanları, farklı kaynaklardaki veriyi kullanıcıya tek bağlamda sunabilir. Bu dağılım her kurumda aynı olmak zorunda değildir. Önemli olan, rollerin ve veri mimarisinin belirlenmiş olmasıdır.

Mimari yalnızca bugünkü veri miktarına göre kurulmamalıdır

Başlangıçta günlük birkaç bin kayıt taşıyan bir entegrasyon, iki yıl sonra milyonlarca davranışsal olayı yönetmek zorunda kalabilir. Bu nedenle mimari tasarım sırasında yalnızca mevcut veri büyüklüğü değil, veri büyüme eğilimi değerlendirilmelidir. Aşağıdaki soruların en az üç ve tercihen beş yıllık öngörülerle cevaplanması gerekir: - Toplam müşteri ve potansiyel müşteri sayısı ne kadar büyüyebilir? - Günlük işlem ve olay sayısı hangi seviyeye ulaşabilir? - Web, mobil uygulama ve fiziksel kanallardan saniyede kaç olay gelebilir? - Geçmiş verinin ne kadarı saklanacaktır? - Veri ne kadar hızlı güncellenmelidir? - Hangi süreçler gerçek zamanlı, hangileri toplu çalışabilir? - Kampanya veya sezon dönemlerinde normal hacmin kaç katına çıkılabilir? - Bir müşteriye ait profil kaç farklı kaynaktan beslenecektir? Burada gerçek zamanlı entegrasyonun her durumda en doğru seçenek olmadığını da vurgulamak gerekir. Bir satış temsilcisinin müşterinin son servis talebini anında görmesi gerekebilir. Buna karşılık aylık finansal sınıflandırma verisinin gece çalışan toplu bir süreçle aktarılması yeterli olabilir. Her veriyi gerçek zamanlı taşımaya çalışmak maliyeti ve karmaşıklığı artırır. Her şeyi toplu aktarmak ise müşteri deneyimini yavaşlatır. Doğru mimari, hız ihtiyacını verinin iş değeriyle eşleştirir. Bu konuda sanırım örnek verilebilecek en kıymetli proje deneyimlerimizden birisi Starbucks projesi olabilir. 7 yılda 7M+ üzerinde müşteriye ulaşmak. Müşterinin işlem yaptığı kanallarda milisaniyeler içerisinde işlem yapabilmek. Oluşan kasa trafiğinin doğru aksiyonlarla eritilebilmesi projede çalıştığımız süre zarfında sanırım doğru bir şehir planlaması kurduğumuzun bir kanıtı niteliğindedir.

Uygulama sayısı kadar uygulamaların çeşitliliği de önemlidir

Gelecekte kaç uygulama kullanılacağını tahmin etmek tek başına yeterli değildir. Bu uygulamaların nerede çalışacağı ve kimler tarafından yönetileceği de planlanmalıdır. Kurumsal ekosistem zamanla şu bileşenlerin karışımına dönüşebilir: - Bulut tabanlı kurumsal uygulamalar, - Kurum içinde çalışan eski sistemler, - Farklı iş birimlerinin satın aldığı SaaS çözümleri, - İş ortaklarının ve bayilerin platformları, - Mobil uygulamalar, - Özel geliştirilen mikroservisler, - Veri ambarları ve analitik ortamlar, - Yapay zeka servisleri, - Fiziksel mağaza ve saha sistemleri, Bu dağılım büyüdükçe yalnızca bağlantı kurmak değil, bağlantıların güvenliğini ve gözlemlenebilirliğini sağlamak da zorlaşır. Hangi servis hangi veriye erişiyor? Yetkilendirme nasıl yapılıyor? Bir müşteri silme veya anonimleştirme talebinde bulunduğunda veri hangi sistemlerden kaldırılacak? API kullanım sınırları nasıl yönetilecek? Bir veri akışı durduğunda bunu kim fark edecek? Bu nedenle entegrasyon mimarisinin API yönetimi, kimlik doğrulama, yetkilendirme, şifreleme, kayıt tutma, hata izleme ve yeniden işleme gibi konuları baştan kapsaması gerekir. Güvenlik, sonradan eklenen bir bariyer değil, yollar yapılırken tasarlanan trafik kurallarıdır.

Departman ve kullanıcı büyümesi mimarinin parçasıdır

Bir CRM veya CDP projesi yalnızca veri ve sistem ölçeğinde büyümez. Organizasyon da büyür. Başlangıçta CRM’i yalnızca on kişilik bir satış ekibi kullanırken zamanla müşteri hizmetleri, pazarlama, saha operasyonları, finans, yönetim, bayiler ve iş ortakları sisteme dahil olabilir. Elli kullanıcılık bir yapı yüzlerce, hatta binlerce kullanıcıya ulaşabilir. Her departman müşteriye farklı bir pencereden bakar: - Satış ekibi fırsatları ve ticari potansiyeli, - pazarlama ekibi segmentleri ve kampanya tepkilerini, - müşteri hizmetleri talepleri ve memnuniyeti, - finans ekibi risk ve ödeme durumunu, - operasyon ekipleri teslimat veya hizmet sürecini görmek ister. Bu ihtiyaçlar ortak bir müşteri görünümüne dayanır; ancak herkesin bütün verilere erişmesi gerekmez. Dolayısıyla gelecekteki departman ve kullanıcı sayısı; rol modelini, erişim yetkilerini, ekran tasarımlarını, raporlama yapısını ve lisans planlamasını doğrudan etkiler. Entegrasyon mimarisi de veriyi yalnızca doğru sisteme değil, doğru yetki ve bağlamla doğru kullanıcıya ulaştırmalıdır.

Sağlam bir entegrasyon mimarisinin temel ilkeleri neler olabilir?

Geleceğe hazırlanmak, ilk günden en büyük ve en pahalı altyapıyı kurmak anlamına gelmez. Ama büyüme gerçekleştiğinde mimarinin tamamen değiştirilmesini önleyecek kararların erken verilmesi gerekir. Bunun için bazı temel ilkeler benimsenebilir. Teknolojik bağlılık Bir sistemdeki değişiklik diğer bütün sistemleri doğrudan etkilememelidir. Uygulamalar mümkün olduğunca tanımlı API’ler, olaylar veya ortak entegrasyon servisleri üzerinden haberleşmelidir. Ortak veri sözlüğü “Müşteri”, “aktif müşteri”, “potansiyel müşteri”, “sipariş” ve “etkileşim” gibi kavramların ortak tanımları bulunmalıdır. Aynı alanın farklı departmanlarda farklı anlamlara gelmesi engellenmelidir. Servis/API öncelikli tasarım Yeni bir kabiliyet geliştirilirken yalnızca mevcut ekran veya uygulama düşünülmemelidir. Bu kabiliyetin gelecekte başka uygulamalar tarafından nasıl kullanılacağı da planlanmalıdır. Olay tabanlı iletişim Müşterinin sipariş vermesi, profilini güncellemesi veya kampanyaya dahil olması gibi olaylar, ilgili sistemlere kontrollü biçimde tetiklenerek iletilebilir. Böylece her uygulamanın kaynak sistemi sürekli sorgulaması gerekmez. Gözlemlenebilirlik Bir entegrasyonun çalışıp çalışmadığı yalnızca teknik ekip tarafından manuel olarak kontrol edilmemelidir. Gecikmeler, hatalar, başarısız kayıtlar ve hacim değişiklikleri izlenebilir olmalıdır. Gün sonu almak ve süreci belirli periyotlarla healthcheck uygulamak sistemin güvenilirliğini de arttıracaktır. Tekrar çalıştırılabilirlik Bir sistem geçici olarak erişilemez olduğunda veri kaybolmamalıdır. Başarısız işlemler güvenli biçimde saklanmalı ve sorun çözüldükten sonra yeniden işlenebilmelidir. Kuyruk yapıları, özellikle mobil uygulamalar için offline çalışabilme yetenekleri kritik önem arz edecektir. Güvenlik ve gizlilik Veri erişim yetkileri, maskeleme, şifreleme, saklama süreleri ve silme süreçleri mimarinin doğal parçaları olmalıdır.

Entegrasyon yol haritası nasıl hazırlanmalı?

Mimari vizyon uzun vadeli olabilir; uygulama planı ise aşamalı ilerlemelidir. İlk adım: Haritayı çıkarmak İlk aşamada sistem envanteri, veri kaynakları, mevcut bağlantılar ve kritik iş süreçleri belirlenir. Hangi sistemin hangi verinin sahibi olduğu netleştirilir. Bu dönemin sonunda kurumun elinde en azından şu çıktılar bulunmalıdır: - Mevcut ve hedef sistem haritası, - Kritik veri akışları, - Veri sahipliği matrisi, - Ortak müşteri kimliği yaklaşımı, - Güvenlik ve yetkilendirme prensipleri, - Hacim ve performans tahminleri, - Önceliklendirilmiş entegrasyon listesi, İkinci adım: Omurgayı kurmak İkinci aşamada API ve entegrasyon standartları belirlenir. Kimlik eşleştirme, hata yönetimi, izleme ve kayıt mekanizmaları devreye alınır. En yüksek iş değerine sahip birkaç akış uçtan uca uygulanır. Amaç bütün sistemleri bir anda bağlamak değil, sonraki bağlantıların üzerinde ilerleyeceği güvenilir omurgayı oluşturmaktır. Üçüncü adım: CDP ve CRM kullanım senaryolarını genişletmek Müşteri profili zenginleştirilir; satış, servis ve pazarlama senaryoları sisteme alınır. Departman bazlı görünüm ve yetkiler olgunlaştırılır. Dördüncü adım ve sonrası: Ölçek ve model Veri hacmi, uygulama sayısı ve kullanıcı tabanı büyüdükçe kapasite testleri, maliyet optimizasyonu ve mimari gözden geçirmeler düzenli hale getirilir. Yeni entegrasyonların aynı standartlara uyması için bir entegrasyon kılavuzu modeli işletilir. Yol haritası sabit bir proje planı değil, kurum büyüdükçe güncellenen bir şehir planı gibi ele alınmalıdır.

Başarıyı bağlantı sayısıyla ölçmeyin

Bir entegrasyon programının başarısı, kaç sistemin bağlandığıyla ölçülemez. Çok sayıda bağlantı, iyi bir mimariden çok kontrolsüz büyümenin göstergesi de olabilir. Daha anlamlı ölçütler şunlardır: - Yeni bir uygulamanın ekosisteme bağlanma süresi, - Hatalı veya kaybolan kayıt oranı, - Müşteri profilinin güncellenme gecikmesi, - Tekilleştirilemeyen müşteri oranı, - Manuel veri düzeltme ihtiyacı, - Entegrasyon kesintilerinin tespit süresi, - Yeni departmanların sisteme dahil olma süresi, - Veri alanlarının sahiplik ve kaynak bilgisinin açıklığı, - Bir sistem değişikliğinin etkilediği bağlantı sayısı, Sağlıklı bir mimari büyümeyi görünmez hale getirir. Uygulama, kullanıcı ve veri sayısı artarken karmaşıklık aynı hızda artmıyorsa doğru bir temel kurulmuş demektir.

Sonuç: Geleceğin trafiği bugünün mimari kararlarında saklıdır

CDP ve CRM projeleri çoğu zaman ekranlar, özellikler ve kısa vadeli entegrasyon listeleri üzerinden başlatılır. Oysa bu projelerin uzun vadeli başarısını belirleyen temel unsur, arka plandaki veri ulaşım sistemidir. Bugün yalnızca birkaç uygulamayı bağlayan bir kurum, birkaç yıl içinde onlarca uygulamadan veri alan, milyonlarca müşteri olayını işleyen ve farklı departmanlardan binlerce kullanıcıya hizmet veren bir yapıya dönüşebilir. Bu büyüme ihtimali proje başlangıcında öngörülmezse her yeni bağlantı hem yatırımsal yükü hem de operasyonel yükü artırır. Görülür ve doğru planlanırsa her yeni uygulama mevcut mimarinin doğal bir tak çalıştır parçası haline gelir.