30 saniyelik özet

Paydaş analizi, bir çalışmayı etkileyen veya çalışmadan etkilenen kişi ve grupların ihtiyaçlarını, yetkilerini, bilgilerini ve değişime karşı tutumlarını değerlendirmektir. İsim listesi hazırlamak başlangıçtır. Asıl amaç; kimin karar vereceğini, kimin bilgisinin gerekli olduğunu ve hangi çıkar çatışmasının çözülmesi gerektiğini anlamaktır. İş analisti bu bilgiyi görüşme planına, gereksinim kararlarına ve onay sürecine taşır. Böylece en çok konuşan kişinin talebi, kendiliğinden işletmenin ihtiyacı hâline gelmez.

Neden önemli?

Bir sipariş yönetimi projesinde satış ekibi hızlı teslimat isterken finans ekibi tahsilat riskini sınırlamak isteyebilir. Depo, uygulanabilir bir iş akışı arar; müşteri hizmetleri ise siparişin durumunu açıklayabilmek ister. Bunların hepsi meşru ihtiyaçlardır. Sorun, farklı beklentilerin aynı gereksinimin içine karar verilmeden yerleştirilmesidir.

Paydaşlar yeterince analiz edilmediğinde çatışma ortadan kalkmaz; geliştirme sırasında veya yayına geçişte ortaya çıkar. Geç gelen bir onay koşulu tasarımı değiştirebilir. Kullanıcıların benimsemediği bir süreç, teknik olarak çalışan ürünün yanında eski yöntemlerin devam etmesine yol açabilir. Bu durumun maliyeti yalnızca yeniden geliştirme değildir; belirsiz kararlar ve operasyonel aksama da yatırımın değerini azaltır.

Junior bir iş analisti için paydaş analizi, doğru soruyu doğru kişiye yöneltme becerisidir. Yönetici için ise karar düzeninin görünür hâle gelmesidir. Kimin neyi onayladığını bilmek, herkesin her karara katılmasını istemekten daha uygulanabilir bir yönetim yaklaşımı sağlar.

Terim nedir?

Stakeholder, yani paydaş, çalışmanın sonucunu etkileyebilen veya bu sonuçtan etkilenen kişi ya da gruptur. Proje sponsoru, son kullanıcı, müşteri, operasyon ekibi ve dış hizmet sağlayıcısı paydaş olabilir. Organizasyon şemasındaki konum, bu ilişkinin yalnızca bir parçasıdır. Günlük işi bilen bir kullanıcı, yönetim yetkisi bulunmasa da çözümün doğruluğu açısından kritik bilgiye sahip olabilir.

Paydaş analizinde şu boyutlar birlikte değerlendirilir: beklenen fayda, olası kayıp, karar yetkisi, konu bilgisi, değişimden etkilenme düzeyi ve katılım ihtiyacı. Tutum da önemlidir; ancak kişiyi “destekçi” veya “direnç gösteren” diye etiketlemek tek başına açıklama değildir. Görünürdeki direnç, iş yükünün artması ya da bir kontrolün kaldırılması gibi somut bir gerekçeye dayanabilir.

Güç ve ilgi matrisi, paydaşları kararları etkileyebilme kapasiteleri ve çalışmaya ilgileri üzerinden değerlendiren bir araçtır. Görüşme ve iletişim önceliklerini belirlemeye yardımcı olur. Bununla birlikte düşük etkili görünen bir kullanıcı grubunu dışarıda bırakmak için kullanılmamalıdır. Matris, karar yetkisini ve temsil edilmesi gereken ihtiyaçları tek başına göstermez.

Analiz ile paydaş yönetimi de ayrılmalıdır. Analiz, mevcut ilişkileri ve beklentileri anlamaya çalışır. Paydaş yönetimi ise bu bulgulara göre katılım, iletişim ve uzlaşma düzenini yürütür. İyi analiz bir dosyada kalmaz; kiminle görüşüleceğini, hangi kararın kime götürüleceğini ve hangi gereksinimin nasıl doğrulanacağını değiştirir.

Gerçek vaka: Toptal’ın küresel perakendeciyle çalışması

Toptal’ın yayımladığı vaka, adı açıklanmayan bir ayakkabı şirketindeki ürün geliştirme sorununu anlatıyor. Araştırma ve geliştirme, ürün, pazarlama ve inovasyon ekiplerinin ortak bir yol haritası ve çalışma yaklaşımı bulunmadığı için ekipler arası iş birliği zorlaşıyordu.

Toptal, çalıştay tasarlamadan önce organizasyon genelinde 15 paydaş görüşmesi yaptığını belirtiyor. Görüşmeler, yaşanan güçlükleri ve ekipler arasındaki uyumsuzlukları belirlemek için kullanılmış. Sonraki çalıştayda ekipler inovasyonun anlamı ve ortak ürün çalışma modelinin temeli üzerinde birlikte çalışmış.

Kaynak, çalışma sonucunda ortak ürün inovasyonu sürecinin tanımlandığını ve bölümler arasında uyum sağlandığını aktarıyor. Ancak gerçekleşmiş bir pazara çıkış süresi azalmasını sayısal olarak sunmuyor. Dolayısıyla bu vakayı ölçülmüş hız artışının kanıtı olarak kullanamayız.

Vakadan çıkarılabilecek yöntemsel ders şu: Görüşmeler yalnızca katılımcı toplamak için yapılmamış; ortak çalışmanın gündemini şekillendirmiş. Paydaş analizi, toplantı öncesi idari hazırlığın ötesinde, hangi sorunun birlikte çözülmesi gerektiğini belirleyen bir girdi olmuş.

Kaynak: Toptal, “Toptal brings cross-functional alignment to global retailer’s innovation strategy.”

Varsayımsal örnek: Sipariş onay sürecini değiştirmek

Kurumsal müşterilere sipariş yönetimi yazılımı sunan bir işletmenin, bekleyen siparişleri daha hızlı onaylamak istediğini düşünelim. İlk talep satış direktöründen geliyor: “Kredi kontrolünü kaldırıp siparişleri otomatik geçirelim.”

İş analisti bu talebi doğrudan gereksinime çevirmeden paydaşları belirler. Satışın beklentisi gecikmenin azalmasıdır. Finans, ödeme riski ve müşteri limitiyle ilgilenir. Depo, hangi siparişin hazırlanmaya başlayabileceğini bilmek ister. Müşteri hizmetleri bekleme nedenini açıklamak zorundadır. Bilgi teknolojileri ekibi ise sistemler arasındaki veri akışının güvenilirliğini değerlendirir.

Ardından unvanlarla yetinmeden somut kararları araştırır: Kredi limitini kim belirliyor? İstisnaya kim izin veriyor? Siparişi fiilen kim kontrol ediyor? Limit bilgisi geciktiğinde ne yapılıyor? Satışın değişiklik istemesi, risk politikasını değiştirme yetkisinin de satışta olduğu anlamına gelmeyebilir. Bu yetki kurumun mevcut kurallarından doğrulanmalıdır.

Görüşmelerde finansın asıl kaygısının otomasyon değil, kayıtsız istisna kararları olduğu ortaya çıkabilir. Depo çalışanları da onaylanan siparişlerin sonradan durdurulmasından zarar gördüklerini anlatabilir. Böylece tartışma “otomasyon olsun mu?” sorusundan, “hangi koşullarda otomatik onay güvenli ve uygulanabilir?” sorusuna taşınır.

Analist, üzerinde uzlaşılan kuralı bir karar kaydına yazar: geçerli limit bilgisi bulunan siparişler tanımlı koşullarda otomatik ilerler; istisnalar yetkili role yönlendirilir; kararın gerekçesi saklanır. Koşulların doğruluğu ilgili paydaşlarla sınanır. Kullanıcılar da normal akışın yanında eksik veri ve istisna senaryolarını değerlendirir.

Çalışmanın başarısını toplantıya katılım sayısıyla ölçmek yeterli değildir. Onay beklemeleri, sonradan geri çevrilen siparişler ve manuel müdahaleler izlenebilir. Bu ölçüler henüz belirlenmemiş sonuçları temsil etmez; uygulama sonrasında değerlendirilmesi gereken alanları gösterir. Paydaş analizi burada hem çözüm sınırını hem de hangi sonucun izleneceğini şekillendirir.

Yaygın üç hata

  1. Unvanı bilgi ve yetkiyle aynı şey sanmak. Yönetici hedefi ve önceliği açıklayabilir; günlük işin istisnalarını işi yapan kişi daha iyi biliyor olabilir. Karar sahibi, konu uzmanı ve kullanıcı ayrı ayrı belirlenmelidir. Bir kişinin bu rollerden birkaçını taşıması, roller arasındaki farkı ortadan kaldırmaz.
  2. Görüş birliğini karar yöntemi olarak kullanmak. Herkesin bütün ayrıntıları onaylamasını beklemek, sorumluluğu dağıtır ve kararları geciktirir. Paydaşların görüşleri alınmalı; ardından hangi kararın kim tarafından, hangi girdilerle verileceği açıkça yazılmalıdır. Karara katılmak ile kararın sorumluluğunu taşımak aynı rol değildir.
  3. Analizi başlangıçta yapıp bırakmak. Kapsam değiştiğinde, yeni bir hizmet sağlayıcı eklendiğinde veya süreç başka bir ekibe devredildiğinde paydaş ilişkileri de değişebilir. Eski listeyle devam etmek yeni ihtiyaçları kaçırır. Önemli değişikliklerden sonra yetki, temsil ve katılım planı yeniden değerlendirilmelidir.

Mini uygulama: Paydaş kartı ve karar kontrolü

Bir sonraki analiz çalışmanızda her önemli paydaş grubu için aşağıdaki kartı doldurun. Tahminleri doğrulanmış bilgilerden ayırın; kişi adı yazmak yetkiyi doğruladığınız anlamına gelmez.

Paydaş veya rol
—
Çalışmayla ilişkisi
—
Beklediği fayda
—
Kaybetmekten endişe ettiği şey
—
Bildiği süreç ve istisnalar
—
Verebildiği kararlar
—
Onaylaması gereken konular
—
Temsil ettiği kullanıcı grubu
—
Katılması gereken görüşme veya değerlendirme
—
Bilginin kaynağı ve son doğrulama tarihi
—

Ardından önemli bir gereksinimi seçip şu kontrolü yapın: Talebi kim iletti? İhtiyacı kim doğruladı? Uygulanabilirliği kim değerlendirdi? Kararı kim verecek? Sonuçtan kim etkilenecek? Bu soruların cevapları aynı kişi olmak zorunda değildir.

Görüşme planını da karta bağlayın. Bir paydaşın talebini anlamak için geçmişte yaşanmış somut bir olayı sorun; genel beklentiyi süreç kaydı veya başka bir paydaşın anlatımıyla karşılaştırın. Çelişkiyi hemen yanlış bilgi diye yorumlamayın. Farklı roller, aynı sürecin farklı bölümünü görüyor olabilir. Analizin değeri bu farkı ortak karar verebilecek kadar açıklığa kavuşturmasındadır.

İlgili terimler

Problem Statement, Business Objective, Requirements Elicitation, Stakeholder Management ve Alignment, Project Sponsor, Project Governance, Business Requirement, Business Rule, Change Request ve Impact Analysis