Kurumsal kaynak planlama (ERP) projeleri özelinde düşünecek olursak, bu projeler yalnızca teknolojik bir dönüşüm değil, aynı zamanda örgütsel yapıların, süreçlerin ve kültürlerin yeniden inşasıdır. Bu dönüşümün başarısında proje yönetimi disiplininin merkezi bir rol oynadığı açıktır. Ancak bu rolün niteliği, kullanılan metodoloji, sistem mimarisiyle olan uyumu ve insan kaynağına yaklaşım biçimiyle doğrudan ilişkilidir.

ERP sistemleri, monolitik yapılarla mı yoksa modüler ve servis tabanlı yaklaşımlarla mı inşa edildiğine göre farklı proje yönetim metodolojilerine ihtiyaç duyar. Agile ve türevleri, mikro hizmet mimarisiyle entegre çalışan bulut tabanlı ERP’lerde çevikliği teşvik ederken; klasik waterfall yaklaşımı, büyük ve yerleşik sistemlerin adaptasyonu için hâlâ tercih edilmektedir.

Ancak asıl mesele, metodolojiyi seçmekten öte, mimari ile metodoloji arasındaki uyumu kurabilmektir. Proje yönetim yaklaşımı, teknik mimarinin ritmiyle senkronize değilse, proje yönetimi yalnızca bir formaliteye dönüşür. Bu noktada, ERP projelerinde “mimari-uyumlu metodoloji tasarımı” kavramının daha fazla önem kazanması gerektiğini düşünüyorum.

Özetle proje yönetim metodolojisi için her zaman ve her koşulda Scrum yada Waterfall yaklaşımı doğrudur diyemeyiz. Ancak biz bu yazıda scrum yaklaşımından ve onun dayandığı temel argümanlardan bahsedeceğiz. 

Bu yüzden de Neden Scrum? sorusunu sorarak devam edelim.

Çünkü; Herby, Brooks ve n(n–1)/2 Uyarıyor: Kalabalık Yavaşlatır

Proje yönetiminde başarı, çoğu zaman teknolojik araçlardan ya da bütçeden çok, ekiplerin iç yapısı ve etkileşim biçimleriyle belirlenir. Bu bağlamda, scrum yalnızca çevik bir geliştirme modeli değil, aynı zamanda sistem düşüncesine dayalı, insan merkezli bir organizasyon yaklaşımıdır.

Scrum’un temel önerilerinden biri olan küçük ve disiplinli ekip yapısı, sadece pratik bir tercih değil; derin bir mühendislik ve psikoloji bilgisinin ürünüdür. Peki neden küçük ekipler? Kalabalık ekipler neden işleri hızlandırmak yerine yavaşlatabilir?

Darboğaz Teorisi ve Şişman Çocuk Herby

Eliyahu M. Goldratt’ın The Goal (Amaç) kitabında geçen Herby metaforu, sistemdeki darboğazların tüm iş akışını nasıl yavaşlattığını sade bir örnekle açıklar. Ormanda yürüyen bir grup çocuk, Herby adlı kilolu bir çocuk yüzünden yavaşlar. Çünkü grup onun hızına uymak zorundadır.

Scrum’da da benzer bir mantık geçerlidir. Büyük, heterojen ekiplerde en yavaş öğrenen ya da en az üretken birey, tüm akışı yavaşlatabilir. Küçük, kendi kendini yöneten ekipler bu darboğazları minimize eder. Çünkü uyum daha hızlı, farkındalık daha yüksektir.

Ekip Sayısı ve İletişim Kanallarının Matematiği: n(n–1)/2

Scrum’un ekip boyutu önerisi (5–9 kişi) rastgele değildir. Ekip büyüdükçe sadece fiziksel değil, bilişsel yük de artar. Her bir birey, diğer herkesle bilgi alışverişi yapmak zorundadır. Scrum’un özünde çapraz fonksiyonellik vardır. Bu da projeye her yeni katılan bir kişi için iletişim kanal sayısının onlarca kat daha fazla artması demektir.

Burada çapraz fonksiyonelliğe bir paragraf açmakta fayda var. Çapraz fonksiyonellik, yani bireylerin birden fazla sürece hâkim olması, teoride çeviklik sunsa da pratikte bilgi derinliğini azaltabilir. Örneğin bir danışmanın hem finans hem üretimi yönetmeye çalışması, yüzeysel uzmanlık ve düşük karar kalitesi doğurabilir. Burada Sakıp Sabancı’nın o meşhur sözü aklıma geldi. ‘‘Her şeyin bir şeyini, bir şeyin her şeyini bileceksin.”

Her uzman, net tanımlı bir rol üstlenir. Sorumluluklar ayrıştırılır, sadece gerekli düzeyde çapraz fonksiyonellik teşvik edilir. Az ama etkili ekiplerle ERP projeleri daha odaklı ve sürdürülebilir ilerler.

Kanal Sayısı= n(n−1)/2

Bu formül bize şunu söyler: 5 kişilik bir ekipte 10 kanal varken, 10 kişilik bir ekipte bu sayı 45’e çıkar. Her yeni kanal, karar alma sürecinde yeni bir potansiyel gecikme ve yanlış anlama kaynağıdır. Bu yalnızca teknik değil, aynı zamanda bilişsel bir problemdir.

Brooks Yasası

Frederick P. Brooks tarafından ortaya atılan Brooks Yasası, proje yönetimi anlayışına radikal bir bakış açısı getirmiştir. Bu yasayı şöyle ifade edebiliriz.

“Geç kalmış bir yazılım projesine daha fazla insan kaynağı eklemek, projeyi daha da geciktirir.”

Bu ifade ilk bakışta aykırı gibi görünebilir. ‘‘Daha fazla insan daha fazla iş yapar” genel kabul görmüş bir varsayımdır. Her ne kadar bir kaç atasözümüz tersini söylese de… Ancak genel olarak bilgi temelli işler doğrusal değil, karmaşık sistemlerdir. Bu yüzden iş gücü eklemek, çıktıyı her zaman arttırmaz.

Şu nedenlerle:

1. 1. Yeni gelen kişilerin eğitilmesi gerekir.

1. 1. İş bölümü her zaman paralel yapılamaz.

1. 1. İletişim karmaşası büyür.

Bu yasa, proje yönetiminin fizik yasası gibidir. Scrum ise bu yasa ile uyumlu bir çözüm proje yönetim sistemidir. Küçük ekipler, net rol tanımları, yüksek ritim. Böyle yazınca ne kadar da basit duruyor.

İşin Bölünemezliği ve Amdahl Yasası

Her işi paralel yapabileceğimizi düşünmek tehlikelidir. Hayatın doğal akışında bu zaten böyle değildir. Hayatta da projelerde de işlerin önemli bir kısmı sıralı (öncül-ardıl) ilişki içerisindedir. Analiz, karar, entegrasyon…sıralı olmak durumunda olabilir. Amdahl Yasası da bunu doğrular.

Amdahl Yasası: Eğer işin büyük bölümü seriyse, kişi eklemek anlamlı bir fayda sağlamaz.

MRP (Malzeme İhtiyaç Planlaması) sistemlerinin temel çalışma mantığı da aslında Amdahl Yasası’nın pratiğe yansımasıdır.

Çünkü:

1. 1. MRP, üretim süreçlerini alt bileşenlerine ayırır.

1. 1. Bir bileşenin üretimi, bir öncekinin tamamlanmasına bağlı olabilir. (Dikey bağımlılık ilişkisi)

1. 1. Bir bileşenin üretimi başka bir bileşen ile aynı anda paralel olabilir. (Yatay bağımlılık ilişkisi)

SCRUM Sadece Küçük Ekip Demek Değil, Akıllı Sistem Kurmaktır

Scrum, yüzeyde bir iş yönetim modeli gibi görünse de özünde bir sistem mühendisliği yaklaşımıdır. Herby ile gelen darboğaz riski, büyüyen iletişim yükü ve Brooks Yasası ile gelen gecikme tehdidi, bize Scrum’un neden küçük ekipleri ısrarla önerdiğini anlatır.

Scrum mimarisi:

• • 5–9 kişilik küçük ekipler,

• • Net roller (Product Owner, Scrum Master, Developer),

• • Zaman kutulu sprint yapısı,

• • Günlük ayakta toplantılar,

• • Sürekli iyileştirme kültürü.

Bu yapı, yalnızca proje yönetimi değil, aynı zamanda organizasyonel öğrenme açısından da verimlidir. Her sprint bir öğrenme döngüsüdür. Büyük ekiplerde bu öğrenme gözlemlenemez hale gelebilir.

Sonuç yerine

ERP projeleri, hâlâ karmaşık, pahalı ve yüksek riskli projeler olarak algılanıyor. Oysa bu risk, yanlış yapılandırılmış proje yönetimi anlayışından da kaynaklanıyor olabilir. Proje yönetimi, yalnızca görev takibi değil; doğru mimariye uyarlanmış doğru metodolojiyle, yalınlaştırılmış sistem tasarımı ve stratejik insan kaynağı yönetimiyle anlam kazanır.

Bu yüzden de Kirpi Consulting olarak sunduğumuz hizmetlerden biri Proje Yönetimi eğitim ve danışmanlığıdır. 

Her ne kadar birçok firma bu hizmet için para ödemek zorunda kaldığında yüreklerine taş basmak zorunda hissetse de, proje süreçlerinde yaşanan aksaklıklar, kayıplar, kavgalar bu alandaki yetersizliğin bedelinin çok daha ağır olduğunu her seferinde gözler önüne sermeye devam ediyor.

NOT VE BİR KİTAP ÖNERİSİ: Bu yazıyı tekrar okumaya başladığım Jeff Sutherland’ın ”SCRUM” kitabından esinlenerek yazdım. Okumayanlar için tavsiye etmiş olayım.

İyi pazarlar.