Ticaret Şirketleri için Power BI Panoları

Bir ticaret şirketi, üzerinde KPI tanımları anlaşılmış ve temiz ERP verisiyle kurulmuş birkaç panoya ihtiyaç duyar: satış ve kârlılık, stok, alacaklar ve sevkiyatlar. Power BI, Tableau ve Looker Studio üçü de bunları sunar; bu yüzden araç kararı veri kaynaklarınıza, kullanıcılarınıza ve yönetişiminize göre verilir — özellik listesine göre değil.

Bir ticaret şirketi hangi panolara ihtiyaç duyar?

Ticaret işletmeleri haftada tekrar eden küçük bir yönetim soruları setini paylaşır ve her biri bir rapor değil bir panodur: Ekibinizin üzerinde tartıştığı KPI sözlüğünü yazın; teklif isteyin, panoları ve arkalarındaki veri modelini birlikte fiyatlandıralım.

• Satış ve kârlılık. Ne satıldı, kime, hangi marjla — ürün, müşteri, pazar ve ay bazında. Davranışı değiştiren kârlılık görünümüdür: bir ticaret şirketi aynı çeyrekte ciroyu büyütebilir ve kârı daraltabilir; bunu yalnızca marj kesiti gösterir.


• Stok. Ne tutuluyor, nerede, ne kadandır ve ne hareketsizleşti? Distribütörler için bu nakit panosudur: stok günleri ve yavaş dönen stok, bir sonraki siparişin ihtiyacı olan işletme sermayesini bağlar.


• Alacaklar. Kim, ne kadar, ne süredir borçludur ve hangi bakiyeler vadesini geçti? Yaşlandırma kovaları, normal bir alacak defteri ile sorunlu bir defteri bir bakışta ayırır.


• Sevkiyatlar. Ne zamanında çıktı, ne geç kaldı ve ne bir belge ya da gümrük adımında takıldı? İhracatçılar için bu aynı zamanda bir hizmet kalitesi panosudur, çünkü müşterinin yaşadığı gecikme bir fatura olayı değil bir sevkiyat olayıdır.


• Açık siparişler. Neyin taahhüt edildiğinin, neyin beklemede ve neyin engelli olduğunun görünümü — bu haftanın üretim, satın alma ve konteyner planını belirleyen operasyonel resim.

KPI tanımları ve veri kaynakları

Tablo projenin çalışır çekirdeğidir: her KPI'ın bir tanımı, bir sahibi ve bir kaynağı olmalıdır ve tuzak sütunu pano tartışmalarının doğduğu yerdir:

Tablo A: KPI | tanım | veri kaynağı | sık tuzak

Bu tabloyu ayakta tutan iki disiplin. Tanımlar formülle değil sade iş diliyle yazılır — formül veri modeline, cümle sözlüğe aittir ve ticari ekiple tartışılacak olan cümledir. Ve her tanım bir tarih ve bir sahip taşır; iş değiştikçe tanımlar kayar ve geçen tanım üzerinde çalışan bir pano dürüstçe bayat değil, sessizce yanlıştır. Bu katmanın yeni bir sistemde mi yoksa mevcut ERP'de mi duracağı sorusunun çerçevsi özel mi paketli mi ERP sayfasında; disiplinin geneli BI ve veri analitiği sayfasında yer alır.

Veri kaynakları ve entegrasyon

Bir ticaret şirketinin gerçeği beş sisteme yayılmıştır ve BI katmanının işi bunları hiçbir şey uydurmadan birleştirmektir:

• ERP. Faturalar, siparişler, stok, ödemeler, ana veri. Birincil kaynak ve genellikle tek işlem bütünlüğü olan kaynak.


• Tablolar. Hedefler, bütçeler, manuel düzeltmeler ve bir kişinin dosyasında yaşayan gölge rakamlar. Ciddiye alın — yalnızca bir tabloda var olan bir bütçe yine gerçek bir bütçedir — ama e-posta eki olarak değil, sahibiyle birlikte veri olarak alın.


• E-ticaret ve pazaryerleri. Çevrim içi satış yapan şirketler için sipariş ve trafik; ERP ile genellikle bire bir örtüşmeyen kanal verisi, bu yüzden eşleme kuralları (ne sayılır satış, ne zaman) sözlüğün parçası olur.


• Lojistik. Sevkiyatlar, takip referansları, taşıyıcı durumu — zamanında KPI'ının ve sevkiyat panosunun kaynağı ve çoğu zaman manuel anahtar ya da partner beslemesi isteyen kaynak.


• Banka. Tahsilatlar ve ödemeler, açık kalemlerle eşleştirilerek — alacak panosu ile nakit gerçeği arasındaki köprü.

Veri modeli temelleri

Bunu doğru yapmak için veri mühendisi olmanız gerekmez; ama üç kavram projenin ikinci yılında ayakta kalıp kalmayacağını belirler:

• Olgu ve boyut tabloları. Olgu tabloları olaylardır — fatura satırları, sevkiyatlar, ödemeler — miktar ve değerleriyle. Boyutlar bağlamdır — ürün, müşteri, pazar, tarih, depo — süzme ve gruplama yaptığınız nitelikleriyle. Yukarıdaki tablodaki her KPI, boyutlara göre dilimlenmiş olguların toplamıdır; bir modelin beş panoya hizmet etmesi de bundandır.


• Bilinçli yıldız şeması. Olgu tablolarını merkezde, boyutları etrafında tutmak, zekice çoktan-çoğa kısayollar olmadan, ölçüleri toplanabilir kılar: bölgeye göre toplanan satış, aya göre topan satışa, toplam satışa eşittir. Bu yapıyı atlayan modeller demoda çalışır ve üçüncü raporda çöker.


• Gerçeğin tek sürümü. Her olgu tablosunda aynı ürün kodu, müşteri kodu ve para birimi, aynı ana veriden alınarak. Birbirinden kopan kopya boyutlar, iki panonun aynı ay için iki farklı toplam göstermeye başlamasının yoludur; sonrasında çıkan tartışma, modelin tasarruf ettiğinden pahalıya mal olur.

Power BI, Tableau ve Looker Studio karşılaştırması

Üçü de yukarıdaki panoları sunar; farklar uyumdadır. Karşılaştırma bilerek niteliksel tutulmuştur — bu pazarda lisans koşulları ve özellik setleri sık değişir; bu yüzden karar vermeden önce güncel satıcı bilgisine bakın ve döngü eski her rakamı bilgi değil ipucu kabul edin:

Tablo B: ölçüt | Power BI | Tableau | Looker Studio

Bu kararı dürüstçe kendi kısıtlarınızla verin, satırlardaki ürünlerle değil: veri nerede yaşıyor (Microsoft merkezli bir ekosistem Power BI'ı basitçe bağlantı ve kimlik açısından öne çıkarır), günlük kullanıcılar kimdir ve modeli iki kim yönetecek? Yazılı şartnamenize bu satırları puanlayan bir satın alma çalışması — yöntemi tedarikçi RFP listesinde — savunulabilir bir cevaba ulaşır; üç ana sayfayı karşılaştıran bir demo ulaşmaz.

Erişim kontrolü ve yönetişim

Ticaret panoları marjı, müşteri adlarını ve ödeme davranışını gösterir; bu yüzden erişim teknik değil önce ticari bir sorudur:

• Satır bazlı güvenlik. Bölgesel müdürü kendi bölgesi, satış temsilcisini kendi hesapları, yönetim kurulu her şeyi görür — pano kopyalarında değil, veri modelinde zorlanır. Ayrı kopyalar "aynı ay için iki rakam"ın geri dönmesinin yoludur.


• Raporlarda değil rollerde. Erişim iş rollerine göre verilir, bir kez verilir ve periyodik gözden geçirilir; bir çalışanın erişiminin işten ayrılmasıyla bitmesi bir proje değil bir yönetişim rutinidir.


• Hassas alanlar. Marj ve maliyet sütunları açık kararlar ister — kimler onları hiç görür ve daha geniş dolaşım için onlarsız bir pano var mıdır.


• Veri koruma. Panodaki müşteri kişisel verisi, şirketin zaten taşıdığı yükümlülüklerin altındadır: Türkiye operasyonları için KVKK, Avrupa müşteri verisi için GDPR; hukuki dayanak, dışa aktarmaların saklanması ve erişim günlüklerini kapsar. Yükümlülükler verinin geldiği sistemlerle aynıdır; bir pano yalnızca okuduğu için muaf değildir. Barındırma ve satıcı erişimi dâhil daha geniş sözleşme bağlamı IT outsourcing sayfasında ele alınır.


• Yenileme ve değişim kontrolü. Tanımı değişen bir pano görünür biçimde değişmelidir — sürüm notu, tarih, sahip — çünkü bir KPI'ın sessizce yeniden tanımlanması iki bölümün birbirinin rakamlarına güvenmemesinin yoludur.

Uygulama adımları

İşe yarayan sıra, sırayla:

1. Önce metrik tanımları. Ticari, finans ve lojistik yöneticilerince onaylanmış KPI sözlüğü. Bir iki sayfa; tüm projenin başarısızlık riski bu adımın düzgün yapılıp yapılmamasında oturur.


2. Tek veri kaynaklı, tek pilot pano. Genellikle ERP faturaları ve satış-kârlılık panosu — yönetimin en çok sorduğu soru ve genellikle en temiz veri. Pilot boru hattını, modeli ve tanımı aynı anda kanıtlar.


3. Gerçek sorularla kullanıcı testi. Panoyu iki hafta boyunca üç gerçek kullanıcıya gerçek haftalık sorularıyla verin ve cevaplayamadıklarını izleyin. Bu iki haftanın boşluk listesi, üzerinde çalışılmaya değer iş kalemlerinin kendisidir; üretilen özellik talepleri bunların korkusundan genellikle küçüktür.


4. Önce düzelt, sonra genişle. Pilotta bulunan veri kalitesi sorunları panoda değil kaynakta düzeltilir; bir rapordaki hesaplamalı düzeltme, sonraki her panoyu zehirleyecek kirli bir ERP'yi gizler.


5. Kullanıcı sayısıyla değil pano ile yayınla. Beş anlaşılmış panoyu sırayla, her biri sahibi ve tanım tariyle çıkarın; aracı herkese bir anda açmak yerine — benimseme probleminin ikinci yarısı insanların neye baktığıdır ve sahipli beş pano boş bir tuvalden iyidir.


6. İşlet. Yenileme izleme, pano başına isimli bir sahip ve çeyreklik tanım gözden geçirmesi. Go-live'da biten bir BI projesi bir yıl içinde bir raporlama hobisine döner; onu yönetim altyapısı yapan işletim rutinidir.

Sıkça Sorulan Sorular

Veri ambarına ihtiyacımız var mı?

Başlarken hayır. ERP'ye doğrudan bağlantı ve bir avuç boyut tablosu, çoğu ticaret şirketi için ilk beş panoyu karşılar; bir ambar, kaynak sistemler çoğaldığında, geçmişin ERP saklama süresinin ötesinde tutulması gerektiğinde ya da performans bozulduğunda kendini haklı çıkarır. Dürüst tetikleyici tekrardır: aynı dışa aktarım çareleri sürekli yeniden kuruluyorsa bu ambar konuşmasıdır ve gündeme getirdiği yapım-satın alma sorusu özel mi paketli mi ERP sayfasında ele alınır.

Veriler ne sıklıkla yenilenmeli?

Yenilemeyi karar döngüsüne göre, kaynak bazında eşleştirin: satış ve açık siparişler günlük ya da günlük e yakın yenilemeyi hak eder; stok ve alacaklar genellikle günlük; pazaryerleri ve banka beslemeleri güvenilir güncellendikçe. Verinin gerçekten değiştiğinden daha sık yenileme bilgi olmadan maliyet alır ve yenileme hataları kullanıcılara sessiz değil görünür olmalıdır — dünkü veriyi bugünmüş gösteren bir pano, geciktiğini söyleyen bir panodan kötüdür.

Excel'den dışa aktarım kullanabilir miyiz?

Evet, meşru bir kaynak olarak — ilk panoların çoğu zamanlanmış bir dışa aktarım rutiniyle çalışır ve bütçeler çoğu zaman yalnızca tablolarda yaşar. Disiplin, dışa aktarımları sahibi, programı ve kontrol edilen bir biçimi olan veri beslemeleri olarak ele almaktır; hata kipi düzensiz gelen ve sessizce kesilen, yanında bir KPI'ı da götüren e-posta dosyasıdır.

KPI'ları kim tanımlar?

Sayıların iş sahipleri: satış ve marj için ticari yöneticiler, stok ve sevkiyat için operasyon, alacaklar için finans. BI ekibi anlaşılmış cümleleri ölçüye çevirir; KPI'ları BI ekibi tek başına tanımladığında panolar kimsenin istemediği bir şeyi ölçer — teknik doğru, kurumsal olarak kullanılmayan.

Power BI ücretsiz midir?

Bu pazarda lisans koşulları sık değişir; bu yüzden bütçe ayırırken güncel Microsoft bilgisine bakın, döngü öncesi rakamlara güvenmeyin. Değişmeyen kararın şeklidir: rolle ayrılmış kullanıcı abonelikleri, yönetişim isteyen bir modelleme katmanı ve kararların iyileşmesi yanında genellikle mütevazı bir maliyet — ama güncel koşullarla, yazılı olarak karar verin.

Müşteri verisini nasıl koruruz?

Modelde satır bazlı güvenlik ki insanlar rolünün izin verdiğini görsün; marj ve maliyet alanları için açık kararlar; role göre verilip periyodik gözden geçirilen erişim; ve KVKK/GDPR yükümlülüklerinin pano katmanına uygulanması — hukuki dayanak, extract saklama, erişim günlükleri — kaynak sistemlerdeki gibi. Barındırma ve satıcı erişimi soruları IT outsourcing sayfasında ele alınanların aynısıdır ve devreden önce sözleşmeye ait olmalıdır.

Kaynaklar ve standartlar

• Burada tarif edilen KPI seti, veri kaynakları eşlemesi, modelleme kavramları (olgular, boyutlar, yıldız şeması, gerçeğin tek sürümü), yönetişim konuları (satır bazlı güvenlik, yenileme görünürlüğü, değişim kontrolü) ve uygulama sırası ticaret ve lojistik şirketleri için genel iş zekâsı pratiğini izler; bu sayfada kullanım istatistiği, benimseme rakamı ya da ölçülmüş sonuç yoktur.
• Üç araç karşılaştırması bilerek niteliksel tutulmuş ve sürüm döngüleri arasında değişen lisans fiyatları, limitler ya da özellik iddiaları içermez; her lisans satırı okuyucuya güncel satıcı bilgisine bakmasını söyler ve Microsoft, Tableau ya da Google ile bir ortaklık iddia edilmez.
• Süreç ifadeleri bu sitenin sayfalarını izler: BI ve veri analitiği, özel mi paketli mi ERP (veri katmanının yeri) ve Türkiye'den yazılım outsourcing (KVKK ve GDPR yükümlülükleri, satıcı erişimi, sözleşme soruları).
• Veri koruma yükümlülükleri adıyla anılır, yorumlanmaz: Türkiye operasyonları için KVKK ve Avrupa müşteri verisi için GDPR, şirketin durumuna göre geçerlidir; uygulanacak rejimi yetkili bir danışmanla doğrulayın.

İlgili sayfalar

BI ve veri analitiği · Özel mi paketli mi ERP · Yazılım geliştirme · Tedarikçi RFP listesi · Yapay zekâ otomasyonu · Teklif isteyin