Dijital Dönüşüm Organizasyonunda ERP Ürün Sahibi Kime Raporlamalı?

ERP projesinde ürün sahibi rolü oluşturulduğunda ilk soru görev tanımından önce organizasyon kutusunun nereye çizileceği oldu. Finans altında olursa operasyonun, BT altında olursa iş ihtiyaçlarının geri planda kalacağından endişe ediliyordu. PMO ise takvim ve kapsam disiplinini korumak istiyordu. Aslında tek bir raporlama çizgisinin bütün bu beklentileri çözmesini istemek sorunun kendisiydi.

ERP kurumsal bir üründür: iş süreçlerini taşır, teknik bir platform üzerinde çalışır ve sürekli yatırım kararı gerektirir. Ürün sahibi backlog önceliği ve değer gerçekleşmesini yönetirken süreç sahiplerinin kararını devralmamalı, BT mimari ve güvenlik sorumluluğunu da üstlenmemelidir. Etkili model, idari bağlılık kadar karar haklarını ve forumları açıkça tanımlar.

Sorunun ortaya çıkışı

Proje ekibinde ERP product owner, iş analistleri, uygulama danışmanları, PMO, süreç sahipleri ve altyapı ekibi vardı. Talepler farklı yöneticilerden doğrudan geliyor, öncelik toplantıdaki en güçlü sese göre değişiyordu. Ürün sahibi bütçe üzerinde yetkisiz, sonuçtan sorumlu görünüyordu. Teknik borç işleri iş listesinde geri kalırken bazı birim istekleri ortak veri modelini bozacak özelleştirmelere dönüşüyordu.

İlk belirtiler ve yanlış varsayımlar

Rolü BT’ye bağlamanın onu teknik proje yöneticisi, finansa bağlamanın finans temsilcisi yapacağı düşünüldü. Oysa davranışı asıl belirleyen hedefler ve karar mekanizmasıdır. Product owner’ın bütün süreç kararlarını tek başına vereceği varsayımı da yanlıştı; mevzuat ve operasyon hesabını süreç sahipleri taşır. Her anlaşmazlığı steering committee’ye taşımak ise komiteyi günlük backlog toplantısına dönüştürür.

Teknik analiz

RACI yerine yalnız görev listesi değil, karar hakları matrisi hazırladık. Backlog sırası ürün sahibinde; süreç politikası ilgili iş sahibinde; mimari, entegrasyon ve güvenlik standartları BT’de; bütçe ve büyük kapsam değişikliği yönlendirme komitesindeydi. PMO plan, bağımlılık ve risk görünürlüğünü sağladı. Ürün sahibinin performans hedefleri teslim tarihi kadar kullanıcı benimsemesi, süreç sonucu, veri kalitesi ve teknik borç dengesini içerdi.

Uygulanan çözüm veya önerilen mimari

İdari raporlama dijital dönüşüm veya BT liderliğinde konumlandı; iş yönü için süreç sahiplerinden oluşan ürün konseyiyle güçlü matris kuruldu. Aylık steering committee bütçe, kapsam ve çözülemeyen riskleri ele aldı. Haftalık ürün forumu backlog ve bağımlılıkları yönetti. Ürün sahibi tek talep giriş noktası olmadı; talepler standart kanaldan toplandı ve değer, risk, zorunluluk ve efor ölçütleriyle sıralandı.

Alternatifler ve karar gerekçesi

ERP ağırlıklı olarak finans sistemi ise CFO altında ürün sahipliği işe yakın olabilir; yine de BT mimari kontrolü gerekir. Teknoloji yoğun entegrasyon ortamında CIO altında konumlandırma sürdürülebilirlik sağlar, ancak iş hedefleri ortak KPI ile korunmalıdır. Bağımsız dönüşüm ofisi çapraz süreçlerde tarafsızlık sunar fakat kalıcı işletme modeli belirsiz kalabilir. Kurumun yapısına göre çizgi değişebilir; değişmemesi gereken karar haklarının açıklığıdır.

Güvenlik ve operasyonel riskler

Aşırı merkezi ürün sahipliği görev ayrılığı ve süreç onaylarını zayıflatabilir. Tek kişiye bağlı bilgi, izin veya ayrılıkta karar boşluğu yaratır; vekalet ve dokümantasyon tanımlandı. Ürün sahibine üretim ortamında sınırsız teknik yetki verilmedi. Tedarikçiyle ticari ve teknik kararlar kayıtlı forumlarda alındı. Backlogda güvenlik, yasal zorunluluk ve yaşam döngüsü işleri görünür kapasite payına sahip oldu.

Çıkarılan Dersler

Kontrol Listesi

Dijital dönüşüm ekibi kurulurken iki ayrı pozisyon için iş vardı, fakat başlangıç hacmi iki tam zamanlı rolü doldurmuyordu. Aynı kişinin hem gereksinim görüşmelerini yürütmesi hem de plan, risk ve toplantı takibini yapması önerildi. Küçük ekiplerde bu yaklaşım pratik olabilir; ancak “şimdilik birlikte” kararı sınırları yazılmazsa kalıcı ve aşırı yüklü bir role dönüşür.

İş analisti problemi, süreç ve gereksinimi derinleştirir. PMO rolü ise portföy görünürlüğü, standart, bağımlılık, risk ve karar ritmini korur. İki rol ortak bilgi kullanır, fakat odak ve bağımsızlık ihtiyacı farklıdır. Birleştirme kararı unvan tartışmasıyla değil, gerçek iş yükü, proje karmaşıklığı ve kontrol ihtiyacıyla verilmelidir.

Sorunun ortaya çıkışı

Ekip aynı anda birkaç dijitalleşme girişimi yürütüyordu. Gereksinim toplantıları, süreç şemaları, test senaryoları, haftalık durum raporu, risk kaydı ve tedarikçi takibi için tek koordinasyon noktası isteniyordu. Ayrı roller bütçe açısından erken görünürken işler yöneticiler arasında paylaşıldığında standart kayboluyordu. Birleşik rol, başlangıç için sahiplik sağladı; sürdürülebilir sınırları ayrıca tasarlamak gerekti.

İlk belirtiler ve yanlış varsayımlar

İki rolün de toplantı ve dokümantasyon yapması aynı iş oldukları izlenimini verdi. Oysa analist gereksinimin doğruluğunu sorgularken PMO teslimatın plan ve yönetişim kalitesini izler. Bir kişinin bütün toplantılara girmesi iletişimi hızlandırabilir, fakat odak değiştirme maliyeti yaratır. Ayrıca kendi hazırladığı gereksinimin ilerlemesini bağımsız raporlamak iyimserlik yanlılığına açık olabilir.

Teknik analiz

Sorumlulukları haftalık saat, uzmanlık ve kontrol ihtiyacına göre ayırdık. Süreç keşfi, gereksinim, kabul kriteri ve UAT desteği BA tarafında; portföy takvimi, risk standardı, karar kaydı, bağımlılık ve yönetim raporu PMO tarafındaydı. Proje sayısı, paydaş sayısı, tedarikçi yoğunluğu ve kritik teslimatlar kapasite göstergesi oldu. Rolün onay vermediği, kolaylaştırdığı noktalar açıklandı.

Uygulanan çözüm veya önerilen mimari

Başlangıçta birleşik rol kuruldu, fakat haftalık kapasite iki iş kovasında ayrı izlendi. Gereksinim onayını süreç sahibi, proje durum doğrulamasını sponsor veya portföy yöneticisi yaptı. Ortak şablonlar ve tek karar günlüğü çift çalışmayı azalttı. Derin analiz günleri toplantısız bloklandı. Üç aylık gözden geçirmede kapasite, geciken analiz, rapor kalitesi ve yeni proje hattına göre rolün ayrılması değerlendirildi.

Alternatifler ve karar gerekçesi

BA’yı süreç ekiplerine dağıtıp merkezi hafif PMO kurmak iş bilgisine yakınlık sağlar; yöntem tutarlılığı için topluluk yapısı gerekir. Dış analist pik dönemi karşılayabilir, fakat kurumsal bilginin içeride kalması sağlanmalıdır. Tam teşekküllü PMO erken aşamada bürokrasi yaratabilir. Birleşik rolü geçiş modeli olarak seçtik; ayrışma eşiğini proje sayısı, kritik yol çatışması ve sürekli kapasite aşımıyla önceden tanımladık.

Güvenlik ve operasyonel riskler

Tek kişide gereksinim, rapor ve tedarikçi iletişiminin toplanması bilgi ve süreklilik riski yaratır. Belgeler kişisel klasörde değil ortak kontrollü alanda tutuldu, vekil belirlendi. Ticari değerlendirme ve kapsam onayı rolün tek başına vereceği kararlar olmadı. Fazla iş yükünün riskleri yeşil raporlama baskısıyla gizlenmemesi için kapasite görünür kılındı. Hassas proje bilgisine erişim her iki sorumluluk için de ihtiyaç kadar sınırlandı.

Çıkarılan Dersler

Kontrol Listesi

Bir ERP programında ilk aylarda takvim düzenli ilerliyor, çalışma grupları toplanıyor ve danışman ekip teslimatlarını yapıyordu. Buna rağmen kapsam dışı talepler birikiyor, süreç sahipleri kritik kararlara imza atmıyor ve bütçeyi etkileyen konular haftalarca bekliyordu. Sorun proje ekibinin çalışmaması değildi; karar alması gereken yönetim katmanının nasıl çalışacağının tanımlanmamış olmasıydı.

Uzun yıllar çok lokasyonlu yapılarda gördüğüm ortak nokta şu oldu: yönlendirme komitesinin değeri üye sayısıyla değil, çözebildiği engellerle ölçülür. Bu çalışma ilk olarak 22 Temmuz 2026 tarihinde ele alındı. Buradaki model tek bir kuruma özgü değil; sponsor, operasyon, finans, BT ve proje yönetimi arasında uygulanabilir bir karar düzeni kurmayı amaçlıyor.

Sorunun ortaya çıkışı

Çok lokasyonlu bir kurumun dijital dönüşüm programında her iş birimi projeyi kendi önceliğiyle yorumluyordu. Finans kontrol ve raporlama bütünlüğünü, operasyon kesintisiz üretimi, BT sürdürülebilir mimariyi, tedarik tarafı ise sözleşmedeki teslimatı korumaya çalışıyordu. Bu hedeflerin hiçbiri yanlış değildi; fakat aralarında seçim yapacak yetkili bir mekanizma olmadığı için günlük proje toplantıları stratejik kararların taşındığı verimsiz oturumlara dönüştü.

Komite kurulması gündeme geldiğinde ilk eğilim bütün yöneticileri davet etmekti. Böyle bir liste temsil sorununu azaltıyor gibi görünse de karar sorumluluğunu dağıtıyordu. Bazı katılımcılar bilgi almak, bazıları karar vermek, bazıları da yalnızca kendi bölümünü savunmak için masadaydı. Önce komitenin amacını “proje durumunu dinlemek” yerine “kapsam, bütçe, öncelik ve kritik risklerde karar vermek” olarak yeniden tanımladık.

İlk belirtiler ve yanlış varsayımlar

İlk belirti, aynı konunun üç toplantı boyunca açık kalmasıydı. Proje yöneticisi karar bekliyor, süreç sahibi üst yönetim desteği arıyor, sponsor ise konunun teknik ekipçe çözülebileceğini düşünüyordu. Bir başka belirti de kapsam değişikliklerinin resmi onay olmadan iş paketlerine girmesiydi. Takvim sapması görünür olduğunda sorun danışman kapasitesine bağlandı; oysa ekip, kararı verilmemiş işleri bekliyordu.

En yaygın yanlış varsayım, sponsorun tek başına bütün iş kararlarını vereceğidir. Sponsor yönü ve önceliği belirler, ancak süreç etkisini operasyon sahibi; mali sonucu finans; mimari ve güvenlik etkisini BT değerlendirmelidir. Diğer yanlış varsayım her toplantıya bütün uzmanların katılması gerektiğidir. Uzmanlar gündem maddesi için davet edilebilir; kalıcı üyelik ise karar yetkisi ve hesap verebilirlikle sınırlı tutulmalıdır.

Teknik analiz

Önce karar envanteri çıkardık: kapsam değişikliği, ek bütçe, süreç tasarımı, veri sahipliği, mimari istisna, risk kabulü ve canlıya geçiş onayı. Her karar türü için öneren, değerlendiren, onaylayan ve bilgilendirilen roller belirlendi. Böylece RACI tablosu yalnızca sunum malzemesi olmaktan çıktı; komite gündeminin hangi eşikte devreye gireceğini gösteren operasyonel bir araç haline geldi.

Komitenin çekirdek yapısı yönetici sponsor, ilgili ana süreç sahipleri, finans temsilcisi, BT yöneticisi ve proje/program yöneticisinden oluştu. PMO karar kaydını, riskleri ve takvimi hazırladı; oy sahibi gibi davranmadı. Her gündem maddesinde karar talebi, seçenekler, etki, öneri ve son karar tek sayfalık formatta sunuldu. Kırmızı-sarı-yeşil rapor yerine gecikmenin iş etkisini ve gereken yönetim kararını öne çıkardık.

Uygulanan çözüm veya önerilen mimari

Aylık olağan komite ve gerektiğinde kısa olağanüstü oturum düzeni kurduk. Operasyonel ekip haftalık çalışmaya devam ederken yalnızca yetki sınırını aşan maddeleri eskale etti. Gündemin ilk bölümü önceki kararların gerçekleşme durumuna, ikinci bölümü yeni karar taleplerine, son bölümü ise en önemli risk ve bağımlılıklara ayrıldı. Sunum süresini kısaltıp karar süresini artırmak toplantı kalitesinde belirgin fark yarattı.

Kapsam veya bütçe değişikliği, sözlü mutabakatla değil standart değişiklik kaydıyla ilerledi. Talebin iş değeri, toplam sahip olma etkisi, takvim sonucu, veri ve güvenlik etkisi birlikte değerlendirildi. Komite karar veremediğinde eksik bilginin sahibi ve tamamlanma tarihi belirlendi. Böylece “değerlendirilecek” ifadesi süresiz bir bekleme alanına dönüşmedi; projenin denetlenebilir hafızası oluştu.

Alternatifler ve karar gerekçesi

Tek sponsor modeli hızlıdır ve küçük, düşük riskli projelerde yeterli olabilir. Ancak kurum çapında süreç ve veri değişikliği yaratan programlarda tek kişinin ayrıntılı etkileri görmesi zordur. Geniş katılımlı kurul ise temsil gücü sağlar fakat gündem kalabalığı, düşük katılım ve belirsiz sorumluluk üretir. Bu nedenle küçük çekirdek komite ile gündeme göre çağrılan uzmanların dengeli modelini seçtik.

Haftalık komite seçeneğini de değerlendirdik. Kriz döneminde yararlı olsa da olağan düzende yöneticileri operasyonel ayrıntıya çekiyor ve proje ekibinin inisiyatifini azaltıyordu. Aylık ritim, tanımlı eskalasyon eşiği ve acil toplantı hakkı daha dengeli oldu. Kararın gerekçesi toplantı takviminden çok, doğru seviyedeki kararın doğru sürede alınmasını sağlamaktı.

Güvenlik ve operasyonel riskler

Komite belgeleri bütçe, denetim bulgusu, tedarikçi değerlendirmesi ve güvenlik riski içerebilir. Bu nedenle karar kayıtları rol bazlı erişilen kurumsal depoda tutulmalı; kişisel e-posta zincirlerinde veya kontrolsüz mesaj gruplarında paylaşılmamalıdır. Tutanaklar gerekli ayrıntıyı taşımalı, fakat gerçek kimlik bilgileri, özel ağ yapısı veya sistem sırları gibi proje kararı için gereksiz teknik bilgilerden arındırılmalıdır.

Operasyonel açıdan en büyük risk komitenin mikro yönetime kaymasıdır. Her küçük konu yukarı taşınırsa ekip sorumluluk alamaz; yalnızca büyük kararlar taşınır ama sonuçlar izlenmezse kurul sembolik kalır. Üye vekâletleri, karar yeter sayısı, risk kabul yetkisi ve acil durum yöntemi baştan yazılmalıdır. Ayrıca sponsor değişikliği halinde açık kararların ve taahhütlerin devri planlanmalıdır.

Çıkarılan Dersler

Kontrol Listesi