Call Center Raporlaması ve Ad-hoc Kaostan Data Product Yaklaşımına Geçiş

Comdata (Konecta)

Comdata, 1987’de İtalya’da kurulmuş ve müşteri deneyimi (CX) ile iş süreçleri dış kaynak hizmetleri (BPO) alanında yıllarca faaliyet göstermiş uluslararası bir firmadır. Şirket; çağrı merkezi hizmetleri, müşteri hizmetleri, teknik destek, müşteri kazanımı ve müşteri tutma gibi kapsamlı hizmetler sunarak farklı sektörlerdeki kurumsal müşterilerin operasyonel süreçlerini yönetiyordu. Comdata’nın hizmet portföyü müşteri iletişimi ve operasyonel süreç çözümlemeye odaklıydı ve şirket 30’dan fazla dilde, birçok ülkede hizmet veriyordu.

2013’ten itibaren Türkiye pazarında Comdata Türkiye olarak faaliyet gösteren bu birim, yerel pazardaki büyük kurumsal müşterilere çağrı merkezi ve müşteri hizmetleri çözümleri sunuyordu. Comdata Türkiye, telekomünikasyon, finans, enerji ve perakende gibi alanlarda müşteri deneyimi süreçlerinin yönetilmesine destek veriyordu.

2022 yılında Comdata, İspanyol müşteri deneyimi firması Konecta ile stratejik bir birleşme gerçekleştirdi. Bu birleşme sonucunda hem Comdata hem de Konecta operasyonları, tek bir marka altında yönetilmeye başladı ve şirket artık Konecta markasıyla faaliyet göstermektedir.

Mevcut Durum ve Sorunlar

3 farklı Operasyonel sistem (Çağrı merkezi sistemi) var: AVAYA, SYTEL, ININ, inbound ve outbound operasyonlar.
Projeye başladığımda 7 kişilik ekip sadece call center raporlaması yapıyordu, çağrı istatistikleri, maliyet analizi, agent performansı vb.
3 farklı raporlama aracı (SSRS, Power BI, QlikView) üzerinde 300+ farklı rapor yaratılmıştı ve buna ek olarak müşterilerden gelen talep üzerine Excel export tabanlı ad-hoc raporlar oluşturuluyordu.
Aynı veriden beslenen benzer raporlarda farklı sonuçlar oluşuyordu, Multiple Version of Truth problemi çok yaygındı.
DWH yoktu, raporlar operasyonel veritabanlarına direkt SQL ile bağlanarak üretiliyordu.
Operasyonel sistemlere haliyle rapor sorguları nedeniyle aşırı yük binmesi oluştuğundan ciddi performans problemleri vardı.
Günlük raporlama işleri (BAU, Business as Usual) aşırı manuel ve emek yoğundu, bu nedenle çalışanlar için fazla mesai / overtime standart hale gelmiş durumdaydı.
Üstelik Müşteriler kötü veri kalitesi, yavaş raporlar nedeniyle aşırı memnuniyetsizdi.
Taksonomi ve KPI birliği yoktu, aynı KPI farklı ekiplerde farklı hesaplanıyordu, hatta farklı anlamda kullanılıyordu.
Transaction verileri sistemden sisteme ve müşteri bazında farklı fiziksel modellerde tutuluyordu (kolonla ayrım, müşteri bazlı ayrı DB, müşteri bazlı ayrı tablolar).
Master data duplike, MDM süreci yoktu.
Değişiklik taleplerini yönetme süreci yoktu, kaynak kod ve versiyonlama yoktu (git/VSTS vb).
Data privacy ve GDPR guardrail’leri yoktu, yani mesela müşteri verisinin yanlışlıkla başka müşteriyle paylaşılmasını engelleyen koruma yoktu.
Proje Bütçesi aşırı derecede düşüktü, üst yönetim sponsorluğu olmadan dönüşümün ilerlemesi mümkün değildi.
Müşterilerin çoğu kendi ihtiyaçlarını karşılayan genişletilmiş kapsamda standart raporlara razıydı, ancak büyük müşteriler kendilerine özel rapor hazırlanması konusunda ısrarcıydı.

Çözümler

Yaklaşım, Analiz ve Yönlendirme

Mevcut durumun “tek bir teknik problem” değil, süreç, organizasyon ve teknoloji katmanlarına yayılmış kurumsal bir problem olduğunu gördük. Bu nedenle işe önce kapsamı daraltmadan, doğru teşhis koymaya odaklanan kısa bir ön analizle başladık. Ardından 5 günlük analiz çalışmasıyla; rapor envanterini, veri akışlarını, KPI tanımlarını ve operasyonel bağımlılıkları ortaya çıkardık, en kritik riskleri (performans, veri izolasyonu, GDPR, BAU sürdürülebilirliği) önceliklendirdik.

Bu çıktılarla birlikte çözümü, tek seferde “büyük dönüşüm” olarak değil, kontrollü ve ölçülebilir adımlarla ilerleyecek şekilde fazlara böldük. Her faz için net hedefler, teslimatlar ve karar kriterleri tanımladık: önce operasyonu stabilize etmek ve kaynak sistem yükünü azaltmak, sonra standardizasyon ve yönetişim temellerini kurmak, en son da ürünleşme ve ölçeklenebilirliği devreye almak. Bütçe kısıtı nedeniyle, üst yönetim sponsorluğu ve hızlı değer üretimi kritik olduğundan, yaklaşımı low hanging fruit odaklı kurguladık ve her fazın sonunda bir sonraki fazı tetikleyecek somut kazanımlar üretecek şekilde yönettik.

Böylece raporlamayı “tek tek rapor üretimi” yaklaşımından çıkarıp, platform ve ürün mantığına taşımayı sağladık.

Bu yaklaşımı aşağıdaki proje planıyla yürüttük:

Ön Analiz Toplantıları (2–3 saat)
Analiz Projesi (5 gün)
Agile fazlar: Faz I (15 gün), Faz II (20 gün), Faz III (20 gün)

Faz I (15 gün), Stabilizasyon ve hızlı kazanımlar

Hedef: Operasyonu rahatlatmak, performansı toparlamak, BAU yükünü düşürmek
Teslimatlar:

Operasyonel sistemlere direkt erişimin kaldırılması, replikasyon ve replika üzerinden raporlama
En çok kullanılan raporları ayakta tutacak basit DWH kurulumu
Basit veri tedariği (ETL) akışlarının devreye alınması
İş birimlerine 3 günlük BI ve veri okur-yazarlığı eğitimi
Capability Matrix hazırlanması
Standart raporların tespiti (konsolidasyonun başlangıcı)

Faz II (20 gün), Standardizasyon ve yönetişim temeli

Hedef: Tek dil, tek standart, kontrol edilebilir değişiklik ve müşteri izolasyonu
Teslimatlar:

Raporlama template’lerinin hazırlanması (kurumsal şablon ve standartlar)
Tenant bazlı DWH yaklaşımının hayata geçirilmesi (müşteri izolasyonu)
Basit MDM yaklaşımının hayata geçirilmesi
Anaveri standartlarının oluşturulması
Data Catalog ve Lexicon oluşturulması
Data Governance rutinlerinin oluşturulması
Rapor ve veri modeli değişiklik taleplerinin süreçleştirilmesi ve otomasyonunun kurulması
DWH Management yaklaşımının oluşturulması
Parallel process ve multi-threaded ETL yapısının devreye alınması

Faz III (20 gün), Ürünleşme

Hedef: Standart + esnek yapı, ölçeklenebilir teslimat ve ürün paketleri
Teslimatlar:

Data product’ların tespiti ve geliştirilmesi
Standart raporlarla yetinemeyen müşteriler için Custom Data and Report Model yaklaşımı
Data Sharing API geliştirilmesi ve veri paylaşımı
SaaS temelli altyapının kurulması/olgunlaştırılması
Processing power/resource management, data product bazlı scale up/down
Data product paketlerinin hazırlanması, Basic, Standard, Premium + Data API + Customisation

Mimari Tasarım

Ana veriyi müşteri bazlı çoğaltmadan yönetmek için MasterData veritabanı yaklaşımını kurguladım.
Gizlilik ve müşteri izolasyonu için database-per-tenant DWH modelini seçtim, template ortak modelin publish profilleriyle tüm müşteri veritabanlarına otomatik yayılmasını tasarladım.
Müşteri özel ihtiyaçlar için global modele ek, yalnız gerekli müşterilerde devreye giren özel model, özel ETL, özel rapor yaklaşımını tanımladım.
Tenants, TenantConfigs, Products, TenantProducts gibi kontrol tablolarıyla; model güncelleme, ETL çoklama ve paralel çalıştırma, rapor publish, SSRS klasör ve yetkilendirme otomasyonlarını kapsayan yazılım modelini tasarladım.
Data Marketplace kapsamında bir Web Portal tasarlandı, ancak sadece iç kullanıma açıldı

*_{Ana veri (Master Data) Konsolidasyonu ve Standardizasyonu}*

*_{Referans (Template) Veri Ambarı Modeli}*

Data Otomasyon Adımları

DWH modelinin yayınlanması: Ortak (template) DWH modelinin her müşteri DWH veritabanına publish edilmesi
Müşteri özel nesnelerin yayınlanması: Sadece ilgili müşteriler için özel DWH nesnelerinin publish edilmesi
ETL çalıştırma ve paralelleştirme: Model ETL akışlarının çoklanması ve paralel çalıştırılması
Müşteri özel ETL: Müşteri özel tabloları dolduran ETL akışlarının çalıştırılması
Rapor ve yetkilendirme: SSRS klasör, grup ve yetkilerin otomatik oluşturulması, ürün paketine göre ilgili raporların publish edilmesi

*_{Satılabilir Data Products (Veri Ürünleri) ve Hizmet Paketleri Kapsamındaki Yeni İş Modelleri}*

Benzer bir dönüşüme mi ihtiyacınız var?

Ad-hoc raporlamadan, standart, ölçeklenebilir ve yönetilebilir bir data product yaklaşımına geçiş zor değil! Size bunun için size yardımcı olabilirim! Benimle iletişime geçmeniz yeterli.