İş Ortağı Ağınız İçin Olgunluk Modeli Nasıl Oluşturulur?

Talep çoğu zaman yönetim kurulu raporunda tek satır olarak karşınıza çıkar: İş ortaklarımız için bir olgunluk modeli geliştirin. Sekretaryadan biri bir elektronik tablo açar, Temel’den Mükemmel’e uzanan beş başlık yazar ve hücreleri doldurmaya başlar. Haftalar sonra, üyeler toplantısında kimse yönetişimi ya da dijital becerileri konuşmaz. Konu, bir üyenin “iyi” mi yoksa “çok iyi” mi olduğu ve buna kimin karar verdiğidir.

Sorun genellikle harcanan emek değil, kararların hangi sırayla alındığıdır. Bu rehberde, amacı belirlemekten ilk revizyona kadar iş ortağı ağı için olgunluk modelini sekiz adımda nasıl oluşturacağınızı; ücretsiz dört sayfalık şablonu, hayalî bir federasyon için doldurulmuş örneği ve kaçınacağım hataları bulabilirsiniz.

Olgunluk modeli nedir ve bu fikir nereden çıktı?

Kasım 1986’da Carnegie Mellon Üniversitesi’ndeki Yazılım Mühendisliği Enstitüsü, ABD federal hükümetinin yazılım yüklenicilerinin yetkinliğini değerlendirmesine yönelik bir yöntem geliştirme talebine yanıt olarak bir süreç olgunluğu çerçevesi geliştirmeye başladı. 1993’e gelindiğinde bu çerçeve, SEI’nin kendi ifadesiyle beş olgunluk seviyesi “sıralı bir ölçek tanımlayan” Yazılım için Yetenek Olgunluk Modeli’ne dönüşmüştü [1].

Modelin temel yapısı değişmedi: beklenen, arzu edilen ya da tipik bir gelişim yolunu ayrık aşamalar halinde tanımlayan bir seviye dizisi [2]. Her seviye, o aşamaya ulaşmak için nelerin doğru olması gerektiğini belirtir; böylece değerlendirme, bir kuruluşun bu yoldaki yerini gösterir ve atacağı bir sonraki adımı ortaya koyar. 2005’e gelindiğinde BT hizmetlerinden bilgi yönetimine kadar çeşitli alanlarda 150’den fazla olgunluk modeli vardı [3]. Ancak Becker, Knackstedt ve Pöppelbuß bu modellerden 51’ini incelediğinde, yalnızca dokuzunun tasarım sürecini ayrıntılı biçimde belgelediğini gördü [2]. Aşağıda, bu araştırmada sunulan yöntemin program ekiplerine uyarlanmış hâlini bulacaksınız.

Olgunluk modeli oluşturmanın sekiz adımı

Bu adımlar, de Bruin, Rosemann, Freeze ve Kulkarni’nin herhangi bir olgunluk modelini geliştirmek için önerdiği aşamaları izler: kapsam belirleme, tasarlama, içeriği oluşturma, test etme, kullanıma sunma ve sürdürme [3]. Her karar bir sonraki adımı sınırlar; pilot uygulama da tanımlayıcıları en az bir kez yeniden yazmanıza yol açacaktır.

1. Modelin amacına karar verin

Herhangi bir seviyeyi belirlemeden önce, modelin hangi kararlara ışık tutacağını yazın. Araştırmalarda üç kullanım türü ayırt edilir [3][4]: betimleyici model, her iş ortağının bugün nerede olduğunu gösterir; yönlendirici model, buna ek olarak sırada ne yapılması gerektiğini de gösterir; karşılaştırmalı model ise iş ortaklarını veya bölgeleri kıyaslar ve bunun için çok sayıda değerlendirme ile son derece istikrarlı ölçütler gerekir. Çoğu iş ortağı ağının ilk iki türe ihtiyacı vardır.

Aynı sayfada, modeli kimin dolduracağını (yalnızca iş ortağının mı, sizinle birlikte mi, yoksa sizin teyidinizle mi), ne sıklıkta doldurulacağını ve hangi amaçla kesinlikle kullanılmayacağını yanıtlayın. Deneyimime göre son satır, dürüst yanıtlar alınmasına her türlü talimattan daha fazla katkı sağlar. Üyeler modelin üyeliklerini ya da hibelerini belirleyeceğinden şüphelenirse kendilerine yüksek puan verirler; model de gerçekte var olmayan bir ağı betimler.

2. Boyutları seçin

Boyutlar, modelin kapsadığı temalardır: yönetişim, finans, dijital beceriler, koruma, gençlerin katılımı. Karmaşıklığı sınırlamak ve boyutların birbirinden bağımsız olmasını sağlamak için sayıyı düşük tutun (de Bruin ve çalışma arkadaşlarının iki modelinde sırasıyla altı ve dört ana bileşen vardı) ve boyutları birbirini dışlayacak, birlikte tüm alanı kapsayacak şekilde belirleyin [3]: hiçbir kanıt iki kez sayılmamalı ve amacınız açısından gerekli hiçbir unsur dışarıda kalmamalı. Ben dört ila yedi boyut hedefliyor, kapsamı geniş temaları da iki ya da üç alt boyuta ayırıyorum.

Kendi modelinizi yazmadan önce mevcut çalışmalara göz atın: Becker ve çalışma arkadaşlarının yeni bir model oluşturmak için belirlediği ilk gereklilik, mevcut modellerle karşılaştırma yapmaktır [2]. Kapasite güçlendirme alanında, McKinsey’nin 2001’de Venture Philanthropy Partners için hazırladığı çerçevedeki yedi unsur iyi bir başlangıçtır [5]. İş ortağı kapasitesi değerlendirme rehberimizdeki altı alan da aynı şekilde kullanılabilir.

3. Dört ya da beş seviye belirleyin

CMM beş seviye [1], McKinsey çerçevesi ise dört seviye kullanır [5]. Sayıdan daha önemli olan, de Bruin ve çalışma arkadaşlarının belirttiği gerekliliktir: Aşamalar birbirinden farklı ve iyi tanımlanmış, aralarında mantıklı bir ilerleme olmalı; her aşama da amacını yansıtan kısa bir etiket taşımalıdır [3].

Benim kuralım, yöneylem araştırması deneyimime dayanıyor: Bir seviye ancak kanıtlarla tanımlanabiliyor ve komşu seviyelerden ayırt edilebiliyorsa modelde yer almayı hak eder. Ağınızda gerçekten gözlemleyebildiğiniz durumları sayın ve orada durun. Seviye sayısı sonradan artırılabilir de: Becker ve çalışma arkadaşları, BT performansı modellerini dört aşamayla başlattı; BT yöneticileriyle yaptıkları görüşmelerin ardından, daha düşük performans gösteren durumları birbirinden ayırmak için “var olmayan”dan “optimize edilmiş”e uzanan altı aşamaya geçtiler [2]. En alt seviyeyi bir hüküm değil, başlangıç noktası olarak yazın: “Keşfetme” konuşmaya kapı açar; “Yetersiz” ise konuşmayı bitirir.

4. Her seviyeyi gözlemleyebileceğiniz bir durum olarak tanımlayın

Çoğu modelin başarısız olduğu nokta burasıdır. Tanımlayıcı, seviye tablosundaki tek bir hücrede yer alan metindir. Pöppelbuß ve Röglinger, yararlı bir olgunluk modelinin tasarım ilkeleri arasında özneler arası doğrulanabilir ölçütleri sayar: Tanımlar, bir seviyeyi diğerinden ayıracak kadar açık ve kesin olmalıdır [4]. Basitçe söylemek gerekirse, aynı iş ortağına bakan iki kişi aynı hücreyi seçmelidir.

Üç alışkanlık yardımcı olur:

• Görebileceğiniz ya da elinizde tutabileceğiniz bir şey belirtin: belge, rutin, rol ya da sayı. “İyi”, “güçlü”, “yeterli” ve “etkili” sözcüklerini kullanmayın.
• Her adımda tek bir şeyi değiştirin. 3. seviye aynı anda bütçe, sorumlu ve yıllık değerlendirme gerektiriyorsa, bu üçünün ikisine sahip bir iş ortağı kendine uygun bir yer bulamaz.
• Seviyeleri birikimli kurgulayın. Her aşama, kendisinden önceki aşamaların gerekliliklerini de içermelidir [3]. Yöneylem araştırması yaptığım günlerden bir test: 3. seviyenin geçerli olduğu ama 2. seviyenin geçerli olmadığı bir iş ortağı hayal etmeye çalışın. Böyle bir durum mümkünse sıralama yanlıştır ya da ilgili hücre başka bir boyuta aittir.

5. Her seviye için gereken kanıtları belirleyin

Her hücre için, o durumu neyin göstereceğini yazın: politika, tutanak, rapor ya da rakam. İddiaların daha kapsamlı olduğu üst seviyelerde kanıt beklentisini artırın; alt seviyelerde ise daha sınırlı tutun. Kanıtı kimin sunacağını ve kimin teyit edeceğini belirtin. Kimsenin okumayacağı kanıtları asla istemeyin: her belge, iş ortağının kendi çalışmalarına ayırabileceği zamandan götürür.

6. Modeli iş ortaklarıyla doğrulayın

Taslağı, modeli uygulayacak kişilere gösterin. De Bruin ve çalışma arkadaşları modellerini geliştirmek ve kontrol etmek için Delphi tekniği ile odak gruplarından yararlandı [3]; McKinsey, çerçevesini yaklaşık bir düzine kâr amacı gütmeyen kuruluşun icra direktörüyle test etti [5]; CMM’nin 1.1 sürümü ise yaklaşık 200 yazılım uzmanının katıldığı 1.0 sürümü atölyesinden gelen geri bildirimler üzerine hazırlandı [1]. İş ortağı ağı için, farklı özelliklere sahip sekiz ila on iş ortağıyla iki saatlik bir atölye çalışmasıyla başlayın. Şunları sorun: Kendinizi bu modelde görüyor musunuz? Bu sizin kullandığınız dil mi? Neler eksik? Herhangi bir ifade aşağılayıcı mı?

7. Pilot uygulama yapın ve kalibrasyon sağlayın

Modeli üç ila beş iş ortağıyla gerçek koşullarda uygulayın. De Bruin ve çalışma arkadaşları, sonuçların doğru ve tekrarlanabilir olması için aracın geçerlilik ve güvenilirlik açısından test edilmesi gerektiğini vurgular [3]. Pratikte bunun anlamı şudur: İki kişi aynı iş ortağını birbirinden bağımsız değerlendirir ve her anlaşmazlık, yeniden yazılması gereken bir tanımlayıcıya işaret eder. Pilot uygulamadaki her iş ortağı 2. seviyede kalıyorsa seviyeleriniz yeterince ayırt edici değildir; hiç kimse 4. seviyeye ulaşabileceğini düşünemiyorsa elinizde bir dilek listesi vardır. Herkesi aynı kutuya koyan bir ölçek bilgi sağlamaz.

8. Değişiklikleri yönetin ve yeniden değerlendirme yapın

Becker ve çalışma arkadaşları; koşullar, teknoloji ve bilgi değiştikçe tüm olgunluk modellerinin eskidiğini, gereken değişikliklerin de modelin yeni bir sürümünde yer alması gerektiğini belirtir [2]. Modelinizi bir standart gibi ele alın: sürüm numarası belirleyin, yılda bir değişiklik dönemi oluşturun, nelerin neden değiştiğini kaydedin ve değerlendirme turunun ortasında değişiklik yapmayın. 1.1 sürümünde bir hücre değiştiğinde, 1.0 sürümündeki konumların yeni sürüme nasıl aktarılacağını açıklayın; böylece bir iş ortağı, cümleyi yeniden yazdığınız için seviye kaybetmez. Ardından her 6 ila 12 ayda bir yeniden değerlendirme yapın. Bu turları nasıl yürüteceğiniz ve seviyeleri neden asla tek bir puanda ortalamamanız gerektiği, iş ortağı kapasitesi değerlendirme rehberimizde açıklanıyor.

İş ortağı olgunluk modeli şablonu (ücretsiz indirme)

Şablon, sekiz adımı dört A4 sayfasına dönüştürüyor: amaç ve kapsam; boyutlar ve seviyeler; tanımlayıcı testi ve kalibrasyon notları içeren tanımlayıcı tablosu; kanıt planı, doğrulama planı ve sürüm kaydı.

Olgunluk modeli oluşturma şablonunu indirin (PDF, 4 sayfa). Tasarım atölyesinde kullanmak için yazdırabilir ya da bölümleri kopyalayabilirsiniz.

Örnek: bir federasyonun Üye Dijital Olgunluk Yolu

İşte Meridian Gençlik Federasyonu için doldurulmuş şablon. Bu, ulusal düzeyde 26 üye kuruluştan oluşan hayalî bir federasyondur.

Doldurulmuş örneği indirin (PDF, 4 sayfa). Örnekten alınabilecek dört karar:

• Amaç, bazı kullanımları açıkça dışarıda bırakıyor. Model, akran koçluğunu ilk kimin alacağına ve dijital destek fonunun neleri karşılayacağına yön veriyor; üyelik statüsü ya da sıralama için hiçbir zaman kullanılmıyor.
• Beş seviye denendikten sonra dört seviyede karar kılındı. İlk taslağın iki orta seviyesi arasındaki fark kanıtlarla gösterilemeyince beşinci seviye kaldırıldı.
• Üç tema altında altı alan var. Bir üye çevrimiçi katılımda Öncülük ediyor, veri korumada ise Keşfetme aşamasında olabilir; federasyonun görmesi gereken profil de budur.
• Pilot uygulama ifadeleri değiştirdi. İki değerlendirici “düzenli paylaşım yapar” ifadesini haftalık ve aylık olarak farklı yorumladı; bu nedenle çevrimiçi katılımın 2. seviyesi “her hedef kitle için kanallar içeren bir içerik takvimi” olarak değiştirildi.

Olgunluk modeli oluştururken sık yapılan hatalar

1. Amaç belirlemeden seviyeleri yazmak. Modelin yön vereceği bir karar yoksa model zamanla sıralamaya dönüşür ve iş ortakları da onu öyle görür.
2. Anketi model sanmak. SEI, 1987’de kendi olgunluk anketini hazırlarken bu sorunla karşılaştı; birçok kişi anketi modelin kendisi sandı [1]. Model gelişim yoludur; anket ise bu yolu ölçme yöntemlerinden biridir.
3. Gözlemlenebilir durumlar yerine sıfatlar kullanmak. “Yeterli” her değerlendirici için farklı bir anlama gelir.
4. Çok fazla boyut eklemek. Kırk gösterge, kimsenin tamamlayamayacağı bir model ortaya çıkarır.
5. Modeli iş ortakları için tasarlayıp onlarla birlikte tasarlamamak. Başarısızlıklar listesi olarak yazılmış 1. seviye, iş ortaklarına sorunları gizlemeyi öğretir.
6. Değerlendirme turunun ortasında değişiklik yapmak. Tek bir tanımlayıcıyı değiştirmek bile bu turun sonuçlarını önceki turla karşılaştırılamaz hâle getirir.

Olgunluk modelinizi Advancer.World’de oluşturun

Advancer.World; UNICEF ve Airbus gibi kuruluşlardaki programların dijital dönüşümünden doğdu. Platformdaki bir program, olgunluk modelinin yapısına sahiptir: aşamalarınız seviyeleriniz, konularınız ve alt konularınız boyutlarınız, her hücre de bir tanımlayıcınızdır.

Hücreler arasındaki adımlarda, iş ortağının bir üst seviyeye geçmek için yapması gerekenler yer alır: kanıtlar için belge yükleme talepleri, anketler, girişimler ve elektronik imza talepleri. İş ortaklarının her programda nasıl ilerleyeceğine siz karar verirsiniz: öz değerlendirme yoluyla, önceki adım tamamlandığında otomatik olarak ya da yalnızca ekibiniz onay verdiğinde. Ekibiniz tasarımı gerçek zamanlı olarak birlikte düzenleyebilir. İş ortakları bulundukları yeri ve bir sonraki seviyenin kendilerinden ne beklediğini 22 dilde görebilir; diğer iş ortaklarının verilerini ise hiçbir zaman göremez. Günlük anlık görüntüler geçmişi korur ve raporlar, turlar arasında ağın nasıl ilerlediğini gösterir.

SSS

Bir olgunluk modelinde kaç seviye olmalı?

Çoğu iş ortağı ağı için dört veya beş seviye uygundur. Önemli olan, her seviyenin birbirinden farklı, iyi tanımlanmış ve bir alt seviyeden sonraki mantıklı adım olmasıdır [3]. Değerlendiriciler pilot uygulamada iki seviyeyi birbirinden ayıramıyorsa bunları birleştirin.

Bir olgunluk modeli oluşturmak ne kadar sürer?

İlk sürüm için iki ila üç ay planlayın: amaç, boyutlar ve seviyeler için birkaç hafta; tanımlayıcılar ve kanıtlar için birkaç hafta daha; ardından iş ortaklarıyla atölye çalışması ve pilot uygulama. Kestirme yolların bedeli, kimsenin bütçe ayırmadığı ikinci bir sürümle çıkar.

Yeni bir model oluşturmak yerine mevcut bir olgunluk modelini uyarlayabilir miyiz?

Çoğu zaman evet; önce bunu araştırmanız gerekir [2]. Lisans koşullarını kontrol edin, amacınıza uyuyorsa yapıyı koruyun ve tanımlayıcıları ağınızın diline göre yeniden yazın.

Bir iş ortağı farklı boyutlarda farklı seviyelerde olabilir mi?

Evet, çoğunlukla da öyledir; modelin en faydalı çıktısı bu profildir. Bir iş ortağı aynı boyut içinde seviyeleri atlamamalıdır; CMM'nin yazarları da kendi seviyeleriyle ilgili bu noktayı vurgulamıştır [1].

Seviyelerle değil, amaçla başlayın

Bu rehberden tek bir şey alacaksanız, bu sıralama olsun. Amacı tek sayfada yazın, birkaç iş ortağıyla mutabık kalın ve ancak bundan sonra matrisi açın. Bu şekilde oluşturulan bir modelin başlangıcı daha uzun sürer, ancak savunulması çok daha az zaman alır.

Kaynaklar

1. Mark C. Paulk, Bill Curtis, Mary Beth Chrissis ve Charles V. Weber, Software Engineering Institute, Carnegie Mellon University, “Yazılım için Yetenek Olgunluk Modeli, Sürüm 1.1” (CMU/SEI-93-TR-024), Şubat 1993, https://www.sei.cmu.edu/library/capability-maturity-model-for-software-version-11/ (Ekim 2026'da erişildi).
2. Jörg Becker, Ralf Knackstedt ve Jens Pöppelbuß, “BT Yönetimi için Olgunluk Modelleri Geliştirme: Bir Süreç Modeli ve Uygulaması”, Business & Information Systems Engineering, 1(3), 2009, s. 213-222, https://doi.org/10.1007/s12599-009-0044-5 (Ekim 2026'da erişildi).
3. Tonia de Bruin, Michael Rosemann, Ronald Freeze ve Uday Kulkarni, “Olgunluk Değerlendirme Modeli Geliştirmenin Temel Aşamalarını Anlamak”, 16. Australasian Information Systems Conference (ACIS), Sydney, 2005, https://aisel.aisnet.org/acis2005/109 (Ekim 2026'da erişildi).
4. Jens Pöppelbuß ve Maximilian Röglinger, “Kullanışlı Bir Olgunluk Modelini Ne Yarar? Olgunluk Modelleri için Genel Tasarım İlkeleri Çerçevesi ve İş Süreçleri Yönetiminde Uygulaması”, 19. European Conference on Information Systems (ECIS 2011) Bildirileri, Haziran 2011, https://aisel.aisnet.org/ecis2011/28/ (Ekim 2026'da erişildi).
5. McKinsey & Company, Venture Philanthropy Partners adına, “Kâr Amacı Gütmeyen Kuruluşlarda Etkili Kapasite Geliştirme”, 2001, https://www.bridgespan.org/getmedia/ef1ff943-173b-48ec-843a-b5ce85c6c807/effective-capacity-building-VPP.pdf (Ekim 2026'da erişildi).

© 2026 Mourinho Solutions. Tüm hakları saklıdır.