top of page

Proje Yönetimi Metodolojilerine Kapsamlı Bir Bakış: Waterfall’dan SAP Activate’e

Proje Yönetimi Metodolojilerine Kapsamlı Bir Bakış: Waterfall’dan SAP Activate’e

Proje yönetimi dünyasında “hangi metodoloji en iyisidir?” sorusu sıkça gündeme gelir. Özellikle SAP proje yöneticileri ve danışmanları için, Waterfall, Agile, Scrum, Kanban, Lean, Six Sigma, PRINCE2, hibrit yaklaşımlar ve SAP Activate gibi metodolojiler arasındaki farkları anlamak kritik önemdedir. Bu yazıda, her bir metodolojinin net tanımlarını yaparak, kafa karışıklığını gidermeyi ve örneklerle pratik uygulama ipuçları sunmayı hedefliyoruz. Böylece proje yönetimi ve pazarlama perspektifinden, sosyal medyada da dikkat çekebilecek zenginlikte bir bakış açısı kazanacağız.

Proje Yönetimi Metodolojilerine Genel Bakış

Proje metodolojileri, bir projeyi planlama ve yürütme konusunda yol haritası sunan sistematik yaklaşımlardır. Her metodoloji, proje ekibine iş akışının nasıl görselleştirileceği, iş yükünün nasıl yönetileceği, iyileştirme ve değişikliklere ne kadar açık olunacağı gibi konularda farklı prensipler getirir. Kimi yöntem esneklik ve hız odaklıyken, kimisi disiplin ve öngörülebilirliği ön plana alır. Bu nedenle doğru metodolojiyi seçmek, projenin başarısı için hayati olabilir. Örneğin, PMI 2021 raporu, bilişim ve finans sektörlerindeki projelerin dörtte birinin hibrit metodolojilerle yürütüldüğünü göstermiştir. Yani pek çok organizasyon, tek bir yönteme bağlı kalmak yerine proje türüne göre farklı yaklaşımları harmanlamayı seçiyor.

Aşağıda, en yaygın kullanılan metodolojileri tek tek ele alarak tanımlayacak, hangi durumlarda parladıklarını ve hangi araçlarla desteklendiklerini inceleyeceğiz. Ardından, yazının ilerleyen bölümünde bu yöntemleri belirli kriterlere göre karşılaştıran bir tablo bulacaksınız.

Şelale (Waterfall) Modeli – Geleneksel Yaklaşım

Waterfall (Şelale) modeli, proje yönetiminin en eski ve en geleneksel yöntemlerinden biridir. İlk kez 1970 yılında Winston W. Royce’un makalesiyle tanımlanan bu model, ismini suyun şelaleden akarken geri dönmemesinden alır. Proje, ardışık ve sabit fazlara bölünür; her bir aşama tamamlandıktan sonra bir sonraki aşamaya geçilir. Tipik olarak gereksinim toplama, tasarım, geliştirme (uygulama), test (doğrulama) ve bakım şeklinde beş ana faz içerir. Bu yapısıyla Waterfall, net bir başlangıç ve bitiş tanımlar, proje başında kapsam ve çıktı netleştirilir.

Waterfall metodolojisinin en büyük avantajı öngörülebilirlik ve yapısal netlik sağlamasıdır. Proje planı en başta detaylı şekilde hazırlandığı için, bütçe ve zamanlama konusunda daha tutarlı tahminler yapılabilir. Özellikle gereksinimleri baştan sabit ve net olan, değişimin arzu edilmediği projelerde (örneğin inşaat veya savunma sanayi projeleri) Waterfall uygun bir çerçeve sunabilir. Her aşamanın sonunda çıktıların onaylanması, bir sonraki aşamaya temiz bir başlangıç yapılmasını sağlar. Ayrıca yoğun dokümantasyon gerektirdiğinden, proje boyunca bir bilgi birikimi oluşturur; böylece ekip üyelerinden biri ayrılsa dahi yerine gelen kişi kapsamlı dokümanlar sayesinde işe kolayca dahil olabilir.

Buna karşın, Şelale yönteminin esneklikten yoksun oluşu en büyük dezavantajıdır. Proje başladıktan sonra yeni bir gereksinim ortaya çıkarsa ya da değişiklik ihtiyacı doğarsa, Waterfall bunu idare etmekte zorlanır – genellikle projenin başına dönmeyi veya kapsamı yeniden tanımlamayı gerektirir. Müşteri geri bildirimi proje tamamlanana dek sürece dahil olmadığından, ortaya çıkan ürünün kullanıcı ihtiyaçlarını tam karşılayıp karşılamadığı ancak en sonda görülebilir. Bu da özellikle belirsizliği yüksek, ihtiyaçların zamanla evrilebileceği yazılım projelerinde risk yaratır. Nitekim modern çevik yaklaşımların yükselişiyle birlikte, Waterfall’ın katı yapısı birçok çevrede “eski moda” ve inovasyona ket vurucu olarak eleştirilmiştir. Yine de kapsamın sabit, teknolojinin olgun olduğu, yaratıcılıktan ziyade disiplin ve regülasyona uyumun önemli olduğu projelerde (örneğin tıbbi cihaz geliştirme, uçak yazılımları veya kamu ihale projeleri) Waterfall hâlâ güvenli bir seçenek olmaya devam ediyor.

Waterfall’da proje takibi ve araçlar: Şelale modelinde iş akışı genelde bir Gantt şeması veya benzeri proje takviminde görselleştirilir. Her bir fazın başlangıç ve bitiş tarihleri ile bağımlılıkları bir zaman çizelgesinde gösterilir. Kritik Yol Metodu (CPM) ve PERT diagramları, Waterfall projelerinde süreyi ve ardışık bağımlılıkları yönetmek için klasik araçlardandır. İş yükü sınırlandırması genellikle takvimle doğal olarak sağlanır – belirli bir fazda sadece o fazın görevleri yapılır, aynı anda birden fazla büyük iş ilerletilmez. Bununla birlikte Waterfall, işlerin paralel yürütülmesi veya WIP (aynı anda devam eden iş) kısıtlaması gibi kavramlara odaklanmaz; esas olan planın harfiyen izlenmesidir. Sürekli iyileştirme de proje esnasında değil, daha çok proje sonrasında “lessons learned” (çıkarılan dersler) toplantılarıyla, gelecek projeler için yapılır. Yani yöntem kendi içinde döngüsel bir iyileştirme mekanizması barındırmaz.

Özetle, Waterfall metodolojisi “planla ve uygula” felsefesinin bir yansımasıdır. SAP dünyasında da eski ASAP (Accelerated SAP) gibi metodolojiler büyük ölçüde Waterfall yaklaşımındaydı – proje başında kapsam ve tasarım belirlendikten sonra tüm sistem inşa edilir, sonra test ve devreye alma yapılırdı. Günümüzde daha çevik yaklaşımlar öne çıksa da, kapsamı net S/4HANA dönüşüm projelerinde veya regülasyon gereği adım adım onay gerektiren SAP projelerinde Waterfall benzeri kademeli planlama kullanılabilir.

Agile (Çevik) Metodoloji – Esneklik ve Hız

Agile (Çevik) yaklaşım, Waterfall’ın katılığına tepki olarak ortaya çıkan ve değişime uyumu merkezine alan bir proje yönetimi felsefesidir. 2001’de yayınlanan ünlü Çevik Manifesto, yazılım geliştirmede bireyler ve etkileşime, çalışan yazılıma, müşteri iş birliğine ve değişime tepki vermeye öncelik verilmesi gerektiğini vurgulayarak dört değer ve on iki prensip ortaya koymuştur. Agile’ı tek bir yöntem değil, bir prensipler bütünü ve şemsiye kavram olarak görmek gerekir. Scrum, Kanban, XP (Extreme Programming), Crystal gibi pek çok uygulama çerçevesi Agile prensiplerini somutlaştırır.

Çevik proje yönetiminin özünde, projeyi sabit bir plan doğrultusunda tek seferde teslim etmek yerine iteratif (yinelemeli) ve artımlı teslimatlar yapmak yatar. Yani proje, kısa döngülere bölünür ve her döngüde çalışır durumda bir ürün parçası sunulur. Bu sayede ekip, her döngü sonunda müşteriden geri bildirim alabilir ve bir sonraki döngünün gidişatını bu geri bildirime göre şekillendirebilir. Atlassian’ın tanımına göre: “Agile proje yönetimi, sürekli teslimata ve müşteri geri bildirimine odaklanan yinelemeli bir yaklaşımdır.”. Bu, çevik yöntemlerin en önemli avantajlarından birine işaret eder: Değişime hızlı uyum ve müşteri odaklılık. Proje sırasında şartlar değişse bile (örneğin iş gereksinimleri güncellense, piyasa koşulları farklılaşsa vb.), Agile ekipleri kısa süreli planlar yapıp sık sık yön değiştirebildikleri için yeni duruma kolayca adapte olabilirler.

Agile yaklaşımın pratikteki bir diğer getirisi de ekip motivasyonu ve verimliliği artırmasıdır. Çevik ekipler genellikle küçük, disiplinlerarası ve kendi kendini yönetebilen ekiplerdir. Mikroyönetim yerine ekip içindeki her bireyin aktif katılımı ve sorumluluk alması teşvik edilir. Düzenli aralıklarla yapılan “retrospektif” toplantılarla ekip, iş yapış biçimini sürekli iyileştirmeye çalışır – ne de olsa sürekli iyileştirme Agile kültürünün temel taşlarından biridir. Lean felsefesinden ödünç alınan Kaizen (sürekli iyileştirme) yaklaşımı burada da geçerlidir: Her iterasyon sonunda süreçler değerlendirilir ve bir sonraki iterasyon için düzeltmeler planlanır.

Agile metodolojiler iş akışını görselleştirmek için genellikle panolar ve görev kartları kullanır. Örneğin bir Scrum veya Kanban panosu, üzerinde “Yapılacak”, “Devam Ediyor”, “Tamamlandı” gibi kolonlar barındırır ve ekip üyeleri iş öğelerini (user story, görev vb.) kartlar halinde bu panoda takip eder. Böylece projenin anlık durumunu görsel olarak izlemek mümkün olur. İş yükü yönetimi, Waterfall’a kıyasla Agile’da daha dinamik bir şekilde ele alınır; öncelikler sürekli tekrar değerlendirilir. Özellikle Kanban gibi çevik yaklaşımlarda aynı anda üzerinde çalışılan iş sayısına (WIP) kısıt konularak, ekiplerin bir işe odaklanmadan diğerine geçmemesi sağlanır. Bu da dağılıp verimsizleşmenin önüne geçer.

Agile yaklaşımın en bilinen uygulama çerçevelerinden ikisi, aşağıda detaylı ele alacağımız Scrum ve Kanban’dır. Ancak Agile bunlarla sınırlı değildir; her ekip kendi dinamiklerine uygun, belki Scrum ve Kanban’ı dahi harmanlayan özgün bir çevik süreç oluşturabilir. Önemli olan, müşteri için değer üretmeye odaklanan, değişikliği tehdit değil fırsat olarak gören bir zihniyeti benimsemektir. SAP projelerine baktığımızda da, son yıllarda SAP’nin Activate metodolojisiyle birlikte Agile prensiplerini barındıran yaklaşımlar teşvik ettiğini görüyoruz – örneğin bir S/4HANA projesinde büyük bir tasarım dokümanı yazıp aylarca geliştirme yapmak yerine, “Fit-to-Standard” atölyeleri ile hızlı geri bildirim alıp kısa sprintlerle sistemi yapılandırmak Agile düşüncesinin bir yansımasıdır.

Scrum – Çevik İterasyonların Çerçevesi

Scrum, Agile felsefesinin en popüler ve yaygın uygulanmakta olan çerçevelerinden biridir. Genellikle metodoloji dense de, Scrum aslında belirli roller, etkinlikler ve artefaktlar tanımlayan hafif bir iskelet (framework) sunar. Amaç, küçük bir ekibin karmaşık bir projeyi parçalara bölerek yönetmesini sağlamaktır. Scrum ismi, rugby sporundaki “scrum” durumundan esinlenir – takımın birlikte ve senkronize şekilde hareket etmesini vurgular.

Scrum’da çalışmalar zaman kutularına bölünmüştür. Bu sabit süreli dönemlere “sprint” denir ve genellikle 1–4 hafta arasında sürer (en yaygını 2 haftadır). Her sprint başında ekip, Sprint Planlama toplantısıyla o sprint içinde tamamlayacağı işleri belirler ve bir Sprint Backlog oluşturur. Sprint boyunca ekip her gün kısa bir Daily Scrum (Günlük Ayaküstü) toplantısı yaparak ilerlemeyi ve engelleri gözden geçirir. Sprint sonunda ortaya çıkan ürün parçası Sprint Review toplantısında paydaşlara gösterilir ve geri bildirim alınır. Hemen ardından ekip kendi çalışma biçimini değerlendirdiği Sprint Retrospective toplantısını yapar. Bu döngü her sprintte tekrarlanır. Sonuçta Scrum, her iterasyonda çalışan bir ürün parçası sunarak adım adım değeri artıran bir yapıya sahiptir.

Scrum’ın belirlediği üç temel rol vardır: Ürün Sahibi (Product Owner), Geliştirme Ekibi ve Scrum Master. Ürün Sahibi, projenin iş ihtiyaçlarını maksimize etmekten sorumludur; bir anlamda müşteri beklentilerini ekibe aktaran ve iş önceliklerini belirleyen kişidir. Geliştirme Ekibi, farklı uzmanlıklardan gelen (yazılımcı, analist, tester vb.) 3–9 kişiden oluşur ve sprint hedeflerini gerçekleştirmek için birlikte çalışır. Scrum Master ise takımın koçudur; Scrum süreçlerinin doğru anlaşılıp uygulandığından emin olur, engelleri kaldırır ve ekibin verimli çalışmasını sağlar. Bu rollerin net tanımlanmış olması, rol ve sorumlulukların şeffaflığını artırarak karmaşayı önler.

Scrum’ın bir diğer ana unsuru da Product Backlog (Ürün İş Listesi)’dur. Bu, ürünle ilgili yapılması gereken tüm işlerin (özellikler, geliştirmeler, hatalar vb.) öncelikli bir listesidir. Ürün Sahibi tarafından sürekli güncellenir ve önceliklendirilir. Her sprintte bu listeden en üst sıralardaki maddeler seçilerek sprint backlog’a dönüştürülür. Bu sayede proje boyunca esneklik korunur – gereksinimler değişse bile backlog güncellenerek sonraki sprintlerde yeni önceliklere yer verilebilir. Bu durum, Scrum’ın değişime uyum sağlayabilme özelliğinin kalbinde yatar.

Scrum uygulayan takımlar işlerini Scrum panosu veya Kanban panosu üzerinde görselleştirir. Her user story veya görev bir kart olarak panoya yazılır ve “Yapılacak”, “Devam ediyor”, “Tamamlandı” kolonları arasında ilerletilir. Bu pano, ekibin sprint boyunca ilerlemesini anlık olarak gösterir. Ayrıca sprint boyunca gerçekleşen işi takip etmek için Burndown Chart denilen grafikler kullanılır; bu grafik, kalan iş yükünün zamana göre nasıl azaldığını gösterir. İdeal olarak sprint sonunda burndown grafiği sıfıra ulaşır (yani tüm işler biter). Eğer ulaşmadıysa, bu durum ekip için bir retrospektif konusu olur – planlama hatası mı yapıldı, beklenmeyen engeller mi çıktı vb. değerlendirilir.

Scrum’ın avantajlarına baktığımızda, belirsiz gereksinimli projelerde riski yönetmek en öne çıkan faydadır. Her sprint sonunda çalışan bir yazılım parçası sunduğunuz için, proje ortasında yön değiştirseniz bile en azından elinizde işe yarar bir çıktı kalmıştır. Müşteri memnuniyeti de genelde yüksektir; zira müşteri temsilcileri (Ürün Sahibi veya stakeholder’lar) sürecin içine dahil olur ve her iterasyonda görüş bildirirler. Ekip motivasyonu, öz-yönetime dayalı kültür sayesinde artar. Öte yandan Scrum’ın her hafta/iki hafta toplantılarla bir ritim tutturması, herkese başlangıçta alışılmışın dışında gelebilir. “Toplantılar çok vakit alıyor” veya “Belgeler nerede?” gibi eleştiriler olabilir çünkü Scrum kasıtlı olarak bürokrasiyi azaltır – belge üretmek için değil, yazılım/ürün üretmek için çalışmayı teşvik eder. Bu yüzden şirket kültürü çok hiyerarşik olan veya ekiplerin kendi karar alma yetkisinin düşük olduğu ortamlarda Scrum’a geçiş iyi yönetilmezse zorlanmalar yaşanabilir.

SAP projelerinde Scrum uygulaması: Klasik SAP ERP projeleri genelde Waterfall tarzı yürütülürdü; ancak yeni nesil SAP projelerinde Scrum gitgide yaygınlaşıyor. Örneğin bir SAP S/4HANA geliştirme projesinde ekipler, 2-3 haftalık sprintlerle yapılandırma ve geliştirme yapıp, her sprint sonunda ilgili iş birimi kullanıcılarına bir demo gösterebiliyor. SAP Activate metodolojisi de Scrum’ı destekleyecek şekilde, Realize (Gerçekleştirme) fazında işleri sprint’ler halinde geliştirmeyi öneriyor. Bu, devasa bir ERP projesinde dahi kontrolü kaybetmeden çevik olmayı sağlıyor.

Örneğin, bir üretim şirketine SAP’nin Üretim Modülü (PP) uygulanacağını varsayalım. Waterfall’da aylar süren analiz ve tasarımdan sonra tüm sistemi kurmak yerine, Scrum ile ilk sprint’te temel üretim planlama fonksiyonlarını canlıya yakın ortama kurup kullanıcılarla test edebilirsiniz. İkinci sprint’te bu sefer detay planlama fonksiyonlarını ekler, yine geri bildirim alırsınız. Bu şekilde parça parça ilerleyerek, proje sonunda büyük sürprizler yaşamadan kullanıcı alışkanlığını da artırmış olursunuz. Bu pratik faydalar, Scrum’ı SAP ekosisteminde de çekici kılmaktadır.

Kanban – Görsel İş Akışı Yönetimi

Kanban, üretim hattından köken alan ve yazılım dahil pek çok alanda benimsenen bir diğer çevik metodolojidir. Japonca’da “kanban” kelimesi tabela veya işaret panosu anlamına gelir. İlk olarak Toyota’nın 1950’lerdeki Toyota Üretim Sistemi içinde ortaya çıkmıştır. Toyota, süpermarketlerin raf doldurma mantığından ilham alarak, hattında bir parça kullanıldığında yerine yenisinin üretilip konulmasını öngören bir kart sistemi geliştirdi. Bu sistem, üretimde tam zamanında (Just-in-Time) ve çeken (pull) prensiplerini hayata geçirdi. Yani üretim, talebe göre tetikleniyor; fazla üretim ve stok minimizasyonu sağlanıyordu. Kanban yöntemi buradan doğarak, önce üretimde sonra da iş süreçlerinin her alanında iş akışını dengelemek ve israfı azaltmak için kullanılan bir planlama yöntemi haline geldi.

Çağdaş proje ve iş yönetiminde Kanban denince akla gelen ilk şey, Kanban panosudur. Kanban panosu, devam eden işleri ve durumlarını gösteren görsel bir araçtır. En basit haliyle pano dikey sütunlara bölünür: Yapılacak, Devam Ediyor, Tamamlandı gibi kolonlar her işin durumunu belirtir. Ekip üyeleri yapmakta oldukları işleri kartlar halinde bu panoya yazar ve iş ilerledikçe kartı ilgili kolona taşırlar. Böylece tüm ekip ve paydaşlar, iş yükünün anlık durumunu tek bakışta görebilir. Kanban’ın ana fikri, iş akışının görselleştirilmesi ve işlerin “çekme” sistemiyle, kapasiteye göre yapılmasıdır. Bu sayede darboğazlar hızlıca tespit edilir ve verimlilik artar.

Kanban’ın Scrum’dan farkı, zaman kutuları (sprintler) kullanmamasıdır. İş akışı sürekli ve akıcıdır; her iş öğesi sırayla alınır, bitirilir, bittiğinde yeni iş sıraya girer. Burada dengeyi korumak için Kanban’ın getirdiği kilit kavram WIP (Work-In-Progress) limitleri, yani eşzamanlı iş limitidir. Her kolon için en fazla kaç iş olabileceği kuralı koyulur. Örneğin “Devam Ediyor” kolonuna en fazla 3 kart koyma kuralınız varsa, ekip o anda üç iş üzerine çalışıyorken yeni bir işi başlatamaz. Önce mevcutlardan birini tamamlayıp ilerletmesi gerekir. Bu, biriken işleri ve darboğazları göz önüne sererken ekibin kapasitesini aşmamasını da sağlar. İş yükü böylece sınırlandırılmış olur; bir anlamda “az iş, hızlı iş” prensibi işler.

Kanban’ın güzelliği, uygulanmasının son derece kolay olmasıdır. Aslında Kanban, mevcut sürecinize devrimsel bir değişiklik yapmadan ekleyebileceğiniz evrimsel bir yöntemdir. Mevcut süreçte ne yapıyorsanız yapın, önce onu görselleştirerek başlarsınız (“Şu an ne yapıyorsanız onunla başlayın” Kanban’ın 4 prensibinden biridir. Sonra ufak ufak iyileştirmelerle (örneğin WIP limitlerini düşürerek, süreç adımlarını netleştirerek) akışı pürüzsüz hale getirmeye çalışırsınız. Bu yüzden Kanban’ı uygulamak, ekiplerde genellikle büyük dirence yol açmaz; aksine mevcut rollere ve süreçlere saygı duyar, sadece onları şeffaf hale getirir. Kanban’ın bir diğer prensibi de sürekli iyileştirme ve liderlikte herkesin sorumluluğudur. Yani takımın her üyesi, akışı iyileştirme yönünde fikir getirebilir, inisiyatif alabilir (yalın felsefesindeki Kaizen kültürüyle paralel).

Günümüzde yazılım ekipleri Kanban’ı özellikle IT operasyon, bakım, destek gibi işlerde sıkça kullanıyor. Örneğin bir teknik destek ekibi, gelen destek taleplerini bir backlog (yapılacaklar listesi) olarak tutabilir ve Kanban panosunda sırayla ele alabilir. Her bir talep kartı “Yeni – Atandı – Çözümde – Test Ediliyor – Kapatıldı” gibi kolonlardan geçerken ekip hem önceliklendirmeyi hem de birikmeleri yönetir. Böylece acil işler anında görülür, kimin üzerinde hangi iş var şeffaftır ve hiç bir iş gözden kaçmaz.

SAP projelerinde de Kanban yaklaşımı, özellikle SAP Destek Merkezleri veya DevOps takımlarında kullanılmaktadır. Örneğin, bir SAP uygulama bakım ekibi gelen kullanıcı taleplerini (ek geliştirme veya hata düzeltme istekleri) bir Kanban sistemiyle yönetebilir. Talepler önem sırasına göre backlog’a alınır, ekip üyeleri uygun oldukça üstten iş çekip yapar, tamamlar. Bu şekilde, hizmet düzeyi taahhütleri (SLA) de daha rahat izlenebilir. Hatta bazı durumlarda, Scrum-ban denen, Scrum ile Kanban’ın kombinasyonu yaklaşımlar kullanılarak, hem sprint planlaması yapılır hem de sprint içi akış Kanban ile takip edilir.

Kanban araçları ve görseller: Kanban uygulamak için fiziksel bir pano ve yapışkan notlar yeterlidir. Nitekim birçok ekip duvarlarına astıkları beyaz tahtaları Kanban panosu olarak kullanır. Dijital ortamda ise Trello, Jira (Kanban modülü), Asana gibi araçlar Kanban panolarını sanal olarak sunar. Bu araçlar aynı zamanda kümülatif akış diyagramı (CFD) gibi metriksel grafiklerle akışın hızını ölçmeye imkân tanır. CFD grafikleri, belirli bir zaman diliminde backlog’da, yapım aşamasında ve tamamlanmış kaç iş olduğunu göstererek akışın tıkanıp tıkanmadığını ortaya koyar. Ayrıca lead time (bir işin sisteme girişinden çıkışına kadar geçen süre) ve cycle time (işin aktif çalışıldığı süre) gibi ölçümler, Kanban’ın sürekli iyileştirme vizyonu için kritik geri bildirimler sağlar.

Sonuç olarak, Kanban yaklaşımı işleri akış halinde tutmak, darboğazları görünür kılmak ve ekibin kapasitesini aşmadan, “çekme” prensibiyle işleri yürütmek üzerine kuruludur. Proje yönetiminden ziyade bir iş yönetim sistemi olarak da görülebilir. Bu esnek ve görsel sistem, tek başına kullanılabildiği gibi, Scrum gibi iteratif yaklaşımlarla bir arada da kullanılabilir. Önemli olan takımın üzerinde çalıştığı işlerin gerçek zamanlı fotoğrafını ekrana (veya duvara) yansıtabilmektir – Kanban tam olarak bunu sağlar.

Lean (Yalın) Metodoloji – İsrafı Yok Etme Sanatı

Lean (Yalın) metodoloji, kökleri Toyota Üretim Sistemi’ne dayanan ve temelinde israfın ortadan kaldırılması, sürekli iyileştirme ve insana saygı bulunan bir yönetim felsefesidir. “Yalın” kavramı 1988’de John Krafcik tarafından Toyota’nın üretim tekniklerini tarif etmek için literatüre sokulmuştur. Ancak Lean prensipleri, 1940’lardan itibaren Japonya’da geliştirilmiş; 1990’larda Womack ve Jones’un “Lean Thinking” kitabıyla batıya yayılmıştır. Lean esasen üretimde ortaya çıksa da, günümüzde yazılım geliştirme, startup yönetimi, sağlık hizmetleri gibi pek çok alana uygulanmaktadır.

Lean felsefesi şirketlerin üç alana odaklanmasını öğütler: Amaç (değer yaratma amacı), süreç (değer üretim süreci) ve insanlar. Bir organizasyon, müşterisinin problemini en etkin şekilde çözmeye odaklanmalı (amaç), bunu yaparken değer yaratmayan adımları elimine etmeli (süreç) ve bu iyileştirme yolculuğunda çalışanlarına güvenip onların fikirlerine değer vermelidir (insan unsuru). Bu perspektiften bakıldığında Lean, bir şirket kültürü ve zihniyeti temsil eder.

Lean metodolojisinin iki temel ilkesi sıkça vurgulanır: İnsana saygı ve sürekli iyileştirme. İnsana saygı, işi fiilen yapanların (sahada çalışanların) süreçleri geliştirebileceğine inanmaktır; onların katılımını teşvik etmektir. Sürekli iyileştirme (Kaizen) ise her gün küçük adımlarla daha iyiye gitme arayışıdır. Lean ortamlarında çalışanlardan sadece işlerini yapmaları değil, aynı zamanda işlerini geliştirmeleri de beklenir. Hatalardan öğrenme ve şeffaflık kültürü mevcuttur.

Lean uygulamalarının merkezinde israfın (muda) yok edilmesi bulunur. Toyota, üretimde katma değer yaratmayan faaliyetleri yedi başlıkta tanımlamıştır: Fazla üretim, gereksiz taşıma, stok fazlası, gereksiz hareket, hatalar (defect), aşırı işleme, bekleme. Bu yedi israf, her süreç adımında mercek altına alınır ve mümkün olduğunca ortadan kaldırılmaya çalışılır. Örneğin yazılım geliştirme bağlamında bekleme israfı, bir onay sürecinde işi bekletmek olabileceği gibi; aşırı işleme, müşterinin kullanmayacağı özellikleri geliştirmek şeklinde tezahür edebilir. Lean, bu israf türlerini tespit etmek için Değer Akış Haritalama (Value Stream Mapping) gibi araçlar kullanır. Bir ürün veya hizmetin uçtan uca süreç haritası çıkartılır ve her adımın müşteriye kattığı değer sorgulanır. Değer katmayan adımlar ya düzeltilecek, ya devreden çıkartılacaktır.

Yazılım geliştirme alanında Lean prensipleri, Mary ve Tom Poppendieck’in “Lean Software Development” adlı kitabıyla (2003) somutlaşmıştır. Poppendieck’ler yazılım için 7 temel Lean prensibini şöyle özetlemiştir: İsrafı Yok Et, Kaliteyi Baştan İnşa Et, Bilgiyi Oluştur, Kararları Son Ana Ertele, Hızlı Teslimat Yap, İnsanlara Saygı Duy, Bütünü Optimize Et. Bu prensipler, Agile manifestonun şekillenmesinde de etkili olmuştur – zira Agile’ın kökeninde Lean düşünce vardır.

Lean metodolojisi bir proje yönetimi yöntemi olmaktan ziyade genel bir yönetim felsefesi olduğu için, geleneksel anlamda fazları veya ayrıntılı süreç adımları tanımlamaz. Bunun yerine hangi sektöre uygulanırsa uygulansın ana ilkeler sabittir ve o bağlamda özelleştirilir. Örneğin üretimde Kanban kartları ve Andon (uyarı lambaları) Lean araçlarıyken, yazılımda Continuous Integration veya Kanban panoları Lean düşüncenin araçları olabilir. Proje bazında bakarsak, Lean yaklaşım ile yönetilen projelerde genellikle PDCA (Planla-Uygula-Kontrol Et-Önlem Al) döngüsü benimsenir. Yani proje boyunca kısa döngülerle deneyip öğrenmek, gerektiğinde rotayı düzeltmek esas alınır.

Lean’in uygulama esnekliği yüksektir çünkü katı bir çerçeve sunmaz; aksine mevcut ortama uyum sağlar. Örneğin bazı şirketler Lean Startup metodolojisini kullanarak ürün geliştirmede hızlı deney yapmayı ve müşteri geri bildirimine dayalı pivot etmeyi (yön değiştirmeyi) alışkanlık haline getirmiştir. Burada temel Lean fikri – israfı önlemek – “müşterinin istemediği bir ürünü tamamen geliştirip sonra fark etmek” gibi büyük israf kalemlerinin önüne geçmektir. Bunun için asgari işe yarar ürün (MVP) hızlıca piyasaya sürülür, geri bildirim alınır, ürün ona göre evrilir. Bu döngü de bir nevi Lean’in sürekli iyileştirme kültürünün pazarlama alanındaki yansımasıdır.

SAP projelerinde Lean yaklaşım, genellikle süreç iyileştirme ve kalite yönetimi tarafında kendini gösterir. Örneğin, bir SAP destek birimi, ITIL süreçlerini Lean prensipleriyle iyileştirebilir; gereksiz onay adımlarını kaldırarak, tekrarlanan hataları kalıcı çözerek, destek sürecini yalınlaştırabilir. Keza, SAP içinde Lean Six Sigma gibi metodolojiler kullanılarak, hem Lean (israfı yok et) hem Six Sigma (hataları veriye dayalı azalt) birlikte uygulanabilir.

Sonuç olarak Lean metodoloji, bir projeyi veya süreci en verimli, hatasız ve değer odaklı şekilde işletme arayışıdır. “Az kaynakla, daha çok değer üretme” mottosunu benimsetir. Bunu yaparken de en önemli sermayenin insan olduğunu unutmadan, ekipleri güçlendirir. Proje yönetimi metodolojileri arasında Lean, diğerlerinden biraz ayrışır çünkü genel bir iş felsefesidir; ancak birçok modern proje yönetimi tekniğinin arkasındaki görünmez el Lean düşüncedir.

Six Sigma – Veri Odaklı Süreç İyileştirme

Six Sigma (Altı Sigma), 1980’lerde Motorola’da doğmuş, süreçlerdeki hataları neredeyse sıfıra indirmeyi amaçlayan istatistik temelli bir iyileştirme metodolojisidir. “Six Sigma” terimi, bir süreçteki çıktılarının %99.99966’sının hatasız olmasını ifade eder – yani bir süreç 1 milyon üretimde en fazla 3.4 hata yapıyorsa “6 sigma seviyesinde” kabul edilir. Bu yaklaşım, üretim kalitesini radikal biçimde artırmak ve değişkenliği azaltmak için geliştirilmiştir. General Electric gibi devlerin 1990’larda yoğun şekilde sahiplenmesiyle Six Sigma, iş dünyasında popülerlik kazanmış ve üretim dışı alanlara da yayılmıştır.

Six Sigma’nın temelinde DMAIC adında 5 aşamalı bir problem çözme döngüsü yatar: Define (Tanımla), Measure (Ölç), Analyze (Analiz Et), Improve (İyileştir), Control (Kontrol Et). Bir süreç problemi ele alındığında önce sorun ve hedef tanımlanır, sonra mevcut performans ölçülür, veri analiziyle kök nedenler araştırılır, çözüm geliştirilip uygulanır ve son olarak kazanımların kalıcı olması için kontrol mekanizmaları kurulur. Bu yapı, bilimsel yöntemin yönetime uyarlanmış halidir denebilir – veriye dayalı karar alma Six Sigma’nın kalbidir.

Six Sigma aynı zamanda organizasyon içinde bir yetkinlik ve proje sistemi tanımlar. Yeşil Kuşak, Kara Kuşak gibi sertifikasyonlar vererek çalışanları istatistiksel problem çözme konusunda uzmanlaştırır. Six Sigma projeleri genelde bu uzmanlar liderliğinde yürütülür, üst yönetimde bir sponsor olur, finansal getiriler baştan hesaplanır. Bu yönüyle Six Sigma, bir şirket içinde programatik bir iyileştirme girişimi olarak yapılandırılır.

Ancak kritik bir nokta, Six Sigma’nın bağımsız bir proje yönetim metodolojisi olmadığı gerçeğidir. Six Sigma, mevcut süreçlerin iyileştirilmesi üzerine odaklanır ve bunu yapabilmek için genellikle mevcut bir proje çerçevesine ihtiyaç duyar. Başka bir deyişle, Six Sigma “ne yapılacağını, kimin yapacağını” söylemez; daha çok “nasıl analiz edip sorunu çözeceğini” söyler. Bu nedenle şirketler Six Sigma’yı genelde Waterfall veya Agile gibi yöntemlerle birlikte kullanır. Örneğin, bir üretim süreç iyileştirme projesi Waterfall tarzı planlanırken, çözüm geliştirme aşamasında Six Sigma teknikleri (İshikawa diyagramı, ANOVA, Hipotez testleri vb.) uygulanabilir. Bu ikili kullanım, Lean Six Sigma kavramının da temelini oluşturur: Lean ile israfı azaltırken, Six Sigma ile süreç varyasyonunu azaltmak.

Six Sigma’nın güçlü olduğu nokta ölçülebilir ve somut sonuçlar getirmesidir. Hedefi genelde finansal kazanç veya müşteri memnuniyeti artışı gibi metriklerle tanımlar ve proje sonunda bunları doğrular. Disiplinli veri toplama ve analiz gerektirdiğinden, kararlar hipotezlere ve istatistiksel kanıtlara dayanır. Örneğin bir banka, kredi başvuru sürecinin çok uzun sürdüğünü fark ederse, Six Sigma ile bu süreyi kısaltmak için bir proje başlatabilir. Proje ekibi süreç adımlarını ölçer, hangi adımda gecikme olduğunu tespit eder (belki kredi skor kontrolünde dış sistem beklemesi vardır), sonra bu adımı iyileştirmek için çözüm üretir ve uygular. Sonuçta ortalama süre örneğin %50 kısalır ve proje başarıyla kapanır – aynı zamanda bu kazanımın kalıcı olması için sürece kontrol adımları eklenir (yeni sistem uyarıları veya performans göstergeleri gibi).

Six Sigma araçları ve uygulama alanları: Six Sigma deyince çoğu kişinin aklına istatistiksel süreç kontrolü (SPC), hata türü ve etki analizi (FMEA), tasarım deneyi (DOE) gibi teknik araçlar gelir. Gerçekten de Six Sigma kara kuşakları bu araçlarda yetkindir ve sorun çözümünde kullanırlar. Üretim sektöründe başlayıp başarı kazandığı için, özellikle tekrarlı ve verisi bol süreçlerde çok etkilidir. Otomotiv, elektronik, havacılık gibi sektörler Six Sigma’dan yoğun fayda sağlamıştır. Hizmet sektöründe de (bankacılık, telekom vb.) süreç standartlaşması ve hata azaltma amacıyla uygulanmıştır. Örneğin bir çağrı merkezi, müşteri memnuniyetini etkileyen faktörleri Six Sigma ile analiz edip iyileştirebilir.

SAP açısından baktığımızda, Six Sigma doğrudan bir yazılım geliştirme metodolojisi değildir. Fakat SAP kullanan işletmeler, süreç performansını artırmak için Six Sigma projeleri yapabilirler. Örneğin, depo yönetimi süreçlerinde SAP verilerini analiz ederek stok hata oranlarını düşürmek veya üretim hattında SAP’den alınan kalite verilerini inceleyerek hatalı ürün oranını azaltmak gibi projeler Six Sigma kapsamında ele alınabilir. SAP içindeki Analytics ve Process Mining araçları, Six Sigma’nın Measure ve Analyze adımlarında veri sağlama açısından değerlidir. Ayrıca SAP uygulama projelerinde, süreçlerin tasarımında varyasyonu azaltmak (farklı birimler arasında gereksiz farklılıkları kaldırmak) Six Sigma düşüncesiyle paraleldir.

Özetle Six Sigma, mevcut süreçleri iyileştirmeye odaklanan, veri ve istatistiği kılavuz alan bir metodolojidir. Yalın (Lean) ile birlikte kullanıldığında hem verimsiz adımlar atılır, hem de geriye kalan adımlar hatasızlaştırılır. Her ne kadar proje yönetimi kavramının kendisi olmasa da, proje başarısını sürekli kılmak için önemli bir araç kutusudur. Organizasyonların kaliteyi kurumsal bir alışkanlık haline getirmesi Six Sigma’nın nihai hedefidir. Unutmamak gerekir ki, Six Sigma bir kültür dönüşümüdür aynı zamanda – veriye inanan, hatayı en büyük öğrenme fırsatı gören bir kültür.

PRINCE2 – Kontrollü Proje Ortamları

PRINCE2, adı “Projects IN Controlled Environments” ifadesinin kısaltması olan, yapılandırılmış bir proje yönetim metodolojisidir. 1996’da İngiliz hükümetinin PRINCE yöntemini revize etmesiyle doğan PRINCE2, bugün dünya genelinde yaygın biçimde uygulanan bir standarttır. PRINCE2 özellikle kamu projelerinde ve büyük ölçekli kurumsal projelerde sıkça tercih edilir; zira sunduğu kapsamlı kontrol mekanizmaları ve ayrıntılı süreç yapısı, karmaşık projelerde düzen ve izlenebilirlik sağlar.

PRINCE2’nin temel felsefesi, projeyi kontrollü ve yönetilebilir dilimlere ayırmaktır. Proje, birbirinden belirgin şekilde ayrılmış fazlara (stage) bölünür ve her faz sonunda bir “kapsam kontrol noktası” bulunur. Üst yönetimde tanımlanan bir Proje Yönlendirme Komitesi (Project Board), her fazın sonunda projeyi gözden geçirir ve bir sonraki faza geçiş onayı verir. Bu sayede proje başlangıcında belirlenen iş gerekçesinin (business case) hala geçerli olup olmadığı, projenin istenen faydaya doğru ilerleyip ilerlemediği düzenli olarak değerlendirilir. Eğer proje artık iş gerekçesini karşılamıyorsa, PRINCE2 ortamında projeyi sonlandırmak da doğal bir sonuç olabilir – “Justification (iş gerekçesi) ilkesi” bunu gerektirir.

PRINCE2, 7 ilke, 7 tema ve 7 süreç etrafında tanımlanmıştır. Bu yedi ilke, metodolojinin uygulanması için vazgeçilmez kurallardır; örneğin “Sürekli iş gerekçesi olmalı”, “Derslerden öğrenilmeli”, “Roller ve sorumluluklar net olmalı”, “Aşamalar halinde yönetilmeli”, “Sapmalar istisna bazda yönetilmeli”, “Ürüne odaklanılmalı”, “Metodoloji projeye uyarlanmalı” şeklinde özetlenebilir. Bu ilkelerden de görüleceği üzere PRINCE2, her boyutta ve sektörde projeye uygulanabilecek esnekliğe de sahiptir (Tailoring ilkesi). 7 tema ise projenin farklı boyutlarını (iş gerekçesi, organizasyon yapısı, kalite, risk, planlama, değişiklik, ilerleme takibi) sürekli ele alır. Yani bir PRINCE2 projesinde bu yedi konunun her birine dair asgari gerekleri karşılayan dokümantasyon ve süreç bulunur. Örneğin Risk Teması, projenin en başından sonuna kadar risk yönetiminin nasıl yapılacağını tanımlar ve bir risk kayıtı tutulmasını şart koşar.

PRINCE2’nin süreç yapısı ise projeyi aşamalara bölen başlatma, yönlendirme, sınırlandırma süreçlerini içerir. Özetle bir PRINCE2 projesinin yaşam döngüsü şöyle akabilir: “Proje Başlatma Öncesi” evresinde bir proje görevlisi atanır ve kabaca fizibilite değerlendirilir. Sonra “Proje Başlatma” evresinde ayrıntılı bir Proje Başlatma Dokümanı (Project Initiation Documentation – PID) hazırlanır; bu doküman iş gerekçesini, kapsamı, proje planını, riskleri, proje organizasyon yapısını vb. içerir. Proje Board’u bunu onayladığında proje resmen başlar. Ardından proje, bir veya birden fazla “Teslimat Aşaması”na bölünür; her aşama öncesi ayrıntılı plan yapılır, sonunda kontrol edilir. Günlük yönetim, Proje Yöneticisi tarafından “Aşama Kontrolü” süreci ile yapılır. Proje Board ise “Aşamayı Yönlendirme” süreçleri ile gerekli yönlendirmeleri verir (ve önemli kararlarda devreye girer). Proje sonunda da “Proje Kapatma” süreciyle resmi kapanış yapılır, dersler dokümante edilir.

Bu yapısı sayesinde PRINCE2, projede sıkı bir kontrol ve yönetişim sağlar. Roller ve sorumluluklar net tanımlıdır (ör. Proje Yöneticisi, Proje Sahibesi, Kullanıcı temsilcisi, Tedarikçi temsilcisi vb. rolleri olan bir proje yönetim yapısı vardır). Dokümantasyon yoğundur; her şey kayda geçer. Değişiklik talepleri için formal bir Değişiklik Kontrol Süreci vardır. Kısacası belirsizlikleri en aza indirmek için gereken tüm araçlar sunulmuştur.

PRINCE2’nin avantajı tam da bu kontrollü yapısıdır: Öngörülebilirlik ve hesap verebilirlik artar. Özellikle kamu projelerinde şeffaflık ve hesap verilebilirlik önemli olduğundan, PRINCE2 gibi yöntemler tercih edilir. Ayrıca ekip üyelerinin değişmesi durumunda bile dokümantasyon sayesinde proje devam edebilir; kurumsal hafıza oluşturulur. Risk yönetimi, kalite yönetimi gibi konular sistematik biçimde yapıldığı için sürpriz risklerin veya kalite sorunlarının ortaya çıkma ihtimali düşürülür.

Dezavantajı ise, çevikliğinin düşük olması ve getirdiği bürokratik yük olabilir. Küçük ve hızlı teslimat gerektiren projelerde PRINCE2 biraz hantal kaçabilir; zira her adımda formlar, raporlar, onaylar gerekebilir. Bu noktada, günümüzde PRINCE2’nin Agile yaklaşımı ile nasıl bağdaştırılabileceği gündeme gelmiştir (Axelos, PRINCE2 Agile adlı bir çerçeve de yayınlamıştır). PRINCE2 Agile, PRINCE2’nin yönetişim yapısını korurken teslimat için Agile yöntemlerin (Scrum, Kanban) kullanılmasını teşvik eder. Böylece hem denetim hem esneklik amaçlanır.

SAP projelerinde PRINCE2: Özellikle Avrupa’da bazı SAP uygulama projeleri PRINCE2 ile yönetilmiştir. PRINCE2, SAP gibi birden çok modül ve paydaşı olan projelerde düzen sağlamak için faydalı olabilir. Örneğin, bir ülke çapında SAP rollout (yaygınlaştırma) projesi düşünün; onlarca alt proje var, merkezi bir yönetişim gerekiyor. PRINCE2’nin aşamalı kontrol yaklaşımıyla, her alt projenin belirli kilometre taşlarında rapor vermesi ve onay alması sağlanabilir. Riskler merkezi olarak ele alınabilir. Tabii, PRINCE2 klasik olarak daha “waterfall” bir yaklaşım olduğu için, SAP Activate gibi Agile yönelimli yöntemlerle bir miktar zıtlaşabilir. Fakat PRINCE2’nin uyarlanabilirlik ilkesi sayesinde, Activate’in faz yapısı PRINCE2’nin aşamaları olarak kabul edilip, her faz sonunda PRINCE2 kontrolü yapılabilir. Nitekim bazı kuruluşlar PRINCE2-Agile hibrit yapılarla SAP projelerini yönetmeyi tercih etmektedir.

Özetle PRINCE2, proje yönetimini kurumsal bir süreç haline getirmek ve kontrol altında tutmak isteyen organizasyonların tercih ettiği bir metodolojidir. Sertifika programlarıyla desteklenmiş olması, terminolojisinin oturmuş ve uluslararası kabul görmüş olması da yaygınlığını artırmıştır. Eğer projenizde net fazlar, sıkı değişiklik kontrolü, yönetim kurulu onay mekanizmaları gerekiyorsa PRINCE2 sağlam bir çerçeve sunar. Ancak hızlı uyum gerektiren ortamlarda tek başına yeterli olmayabileceği için, çevik uygulamalarla desteklemek gerekebilir.

Hibrit Yaklaşımlar – İki Dünyanın En İyisi?

Proje yönetiminde hibrit yaklaşım, bir projeyi aynı anda birden fazla metodolojinin unsurlarını kullanarak yönetmek anlamına gelir. Çoğunlukla, Waterfall (şelale) ve Agile (çevik) yöntemlerin bir karışımı kastedilir. Hibrit model, tek bir yöntemin katı sınırlarına bağlı kalmadan, projenin farklı kısımlarında en uygun yaklaşımı uygulamayı hedefler. Son yıllarda hızla artan hibrit proje yönetimi, aslında teoride uzun zamandır vardı: Birçok büyük organizasyon, yazılım projelerinde resmi olarak Waterfall planlar yaparken, ekipler gayriresmi şekilde iteratif geliştirme yapıyorlardı. Artık bunun adı kondu ve yayıldı diyebiliriz.

Hibrit yaklaşımın ardındaki itici güç, projelerin tek tip olmaması gerçeğidir. Bazı projelerin belli bölümleri belirsiz ve keşif gerektirirken, diğer bölümleri net ve adım adım planlanabilir olabilir. Örneğin bir banka için geliştirilen yeni bir yazılım projesinde, kullanıcı arayüzü inovatif olabilir (çevik yaklaşımla hızlı prototiplenip kullanıcıyla test edilmeli), ancak arka planda bankanın ana bilgisayar sistemine entegrasyon gibi kısımlar çok katı düzenlemelere tabidir (adım adım planlanıp test edilmeli, sürprize yer yoktur). İşte hibrit model bu gibi durumlarda devreye girer: Projenin öngörülebilir kısımlarını Waterfall disiplininde, belirsiz kısımlarını Agile esnekliğinde yönetmek.

Bir hibrit proje ortamında tipik olarak üst seviye planlama Waterfall tarzı yapılır. Örneğin projenin bir bütün olarak başlangıç ve bitiş tarihleri, ana teslimatları, fazları belirlenir. Ancak uygulama ekipleri bu fazların içini Agile yöntemlerle doldurur. Toptal’dan bir uzman hibrit modeli şöyle tanımlıyor: “Gerçek hibrit, öngörülebilir işi planlamacı yaklaşımla, belirsiz işi çevik yaklaşımla harmanlamaktır. Hibrit modelde Waterfall, projenin iyi anlaşılan kısımlarına genel yapıyı verir; Agile ise belirsiz kısımlarda yinelemeli çalışmayı sağlar.”. Örneğin şirket genelinde bir yazılım devreye alma projesinde, eğitimlerin verilmesi, altyapının kurulması gibi işler sıralı planlanır (Waterfall), ama yazılımın geliştirme ekibi Scrum ile sprintler yapar (Agile).

Hibrit modeli somut bir örnekle düşünelim: Diyelim ki bir otomotiv firması SAP üzerinde yeni bir üretim planlama modülü geliştiriyor. Bu projenin yasal uyum ve raporlama kısmı çok net kurallara bağlı; burada Waterfall mantığıyla önceden tüm gereksinimler toplanıp, geliştirme ve test planlanabilir. Ancak kullanıcı arayüzü ve deneyim kısmı belirsiz; burada belki birkaç tasarım denemesi yapmak, kullanıcı geri bildirimiyle ilerlemek gerekebilir – yani Agile yaklaşım uygun. Hibrit olarak proje yönetimi yapıldığında, proje yöneticisi genel bir plan dahilinde bu iki parçayı da koordine eder. Belki kullanıcı arayüzü ekibi Kanban panosu ile işlerini yönetir ve 2 haftada bir prototip sunar, bu arada arka uç geliştirme ekibi de klasik bir Gantt takvimine göre ilerler. Yine belirli entegrasyon noktalarında iki ekip senkronize olur (örneğin her ay sonunda bir bütünleşik test yapılacağı Waterfall planında belirtilmiştir). Bu şekilde hibrit model, esneklik ile kontrol arasında bir köprü kurar.

Hibrit proje yönetimi, proje yöneticisinden oldukça yüksek bir beceri seti talep eder. Çünkü aynı anda iki farklı yaklaşımın mantığını anlamak ve bunları çelişmeden işletmek gerekir. Proje ekibinin bir kısmı günlük stand-up toplantıları yaparken diğer kısmı haftalık ilerleme raporları veriyor olabilir; PM bunların ikisini de yönetebilmelidir. Organizasyon kültürü de hibrit için belirleyicidir – bazı kurumlar katı su yolunda giderken bir kısmını esnek bırakmaya sıcak bakmayabilir. Ancak birçok endüstride, özellikle finans, telekom, savunma gibi alanlarda hibrit modeller başarılı örnekler sergilemiştir. PMI’ın araştırmasına göre de hibrit kullanımının artışı bunun bir göstergesidir.

Hibrit araçlar ve uygulama: Hibrit bir ortamda genellikle iki düzeyde araç seti kullanılır. Üst yönetim, genel ilerlemeyi klasik araçlarla (Gantt şeması, kilometre taşı çizelgesi, vs.) takip ederken, ekip seviyesinde Agile araçlar (Jira, Azure DevOps, Trello vb.) kullanılır. Örneğin bir hibrit SAP projesinde, proje yöneticisi MS Project’te bir master plan tutabilir; bu planda “Sprint 1, Sprint 2, …, Integration Test, UAT, Go-Live” gibi üst seviyede aktiviteler ve tarihleri vardır. Ekip ise Sprint 1 içindeki işleri Jira yazılımında user story’ler olarak yönetir. Bu iki katmanı bağlamak için proje yöneticisi düzenli sync toplantıları yapar, belki Scrum of Scrums toplantıları ile farklı alt ekipleri koordine eder.

Hibrit yaklaşıma dair dikkat edilmesi gereken nokta, her iki yöntemin de en kötü yönlerini birleştirmemek gerektiğidir. Yanlış uygulanan hibrit modellerde, Agile ekipler esneklik kazanamaz ama Waterfall’ın bürokrasi yüküne de maruz kalırlar; ya da su yoluna konmuş planlar, Agile ekiplerin değişken hızına uymadığı için sürekli revize edilmek zorunda kalır. Bunu önlemek için, hibrit modele geçmeden önce iyi bir planlama ve tüm paydaşlarda anlayış birliği olmalı. Ekibin Agile çalışma biçimi üst yönetime doğru anlatılmalı, üst yönetimin beklenti ve raporlama ihtiyaçları ise ekibe doğru aktarılmalıdır. Kısacası kültürel adaptasyon, hibritte başarının anahtarıdır

SAP Activate metodolojisi de aslında bir tür hibrit sayılabilir – “fit-to-standard” workshop’larla esnek analiz yapılır ama sonunda Scope baselining ile sabit bir backlog oluşturulur; Realize fazı çevik sprintlerle işler ama Deploy fazı Waterfall gibi planlı bir kesinti ve canlıya geçiş içerir. Bu kombinasyon, SAP projelerinde pratik bir hibrit örneğidir. Nitekim Activate, “Waterfall’dan Agile’a tam geçemeyenler için bir köprü” şeklinde de yorumlanır.

Özetle, hibrit yaklaşımlar “duruma göre metodoloji” anlayışının ürünüdür. Katı doktrinler yerine pragmatizmi koyar: Projenizin doğası neyi gerektiriyorsa onu kullanın. Hem yönetimin gönlü rahat olsun (plan-kitap var), hem ekip rahat olsun (kendi içinde çevik davranabiliyor) isterseniz, doğru kurgulandığında hibrit modeller iki dünyanın en iyisini sunabilir. Elbette, kötü kurgulandığında da iki dünyanın en kötüsünü bir araya getirme riski vardır – bu da proje yöneticisinin ustalığına kalmış.

SAP Activate – SAP Projelerinde Yeni Nesil Metodoloji

SAP Activate, SAP’nin özellikle S/4HANA ve bulut ürünleri için geliştirdiği, modern proje yönetimi yaklaşımlarını barındıran yeni nesil uygulama metodolojisidir. 2015 yılında, eski ASAP (Accelerated SAP) yönteminin yerini almak üzere tanıtılan SAP Activate, üç ana bileşenden oluşur: SAP Best Practices (En İyi Uygulamalar paketleri), Guided Configuration (Yönlendirmeli Yapılandırma araçları) ve Activate Metodolojisi. Burada odaklandığımız Activate metodolojisi, proje ekiplerine hem Waterfall benzeri bir fazlı yol haritası sunar hem de Agile yaklaşımlarla hızlı değer üretmeyi hedefler.

Activate metodolojisi toplam 6 fazdan oluşur: Discover (Keşfet), Prepare (Hazırlık), Explore (Keşfet/Detaylandır), Realize (Gerçekleştir), Deploy (Canlıya Geçir), Run (İşlet). Her fazın net amaçları ve çıktıları tanımlanmıştı.

  • Discover (Keşfet): Bu ön fazda kuruluş, ihtiyacına uygun SAP çözümünü araştırır. Örneğin S/4HANA dönüşümü öncesi mevcut süreçlerini değerlendirir, iş değeri analizleri yapar, bir iş vakası (business case) oluşturur. SAP, Discover aşamasında ücretsiz deneme sistemleri ve demo gösterimleriyle müşterinin çözümü keşfetmesine imkân tanır. Bu fazın sonunda “evet, biz bu SAP çözümüne geçeceğiz” kararı netleşir ve proje resmi olarak başlatılmak üzere onaylanır.

  • Prepare (Hazırlık): Proje ekipleri oluşturulur, detaylı proje planı çıkarılır, gerekli altyapı ve erişimler hazırlanır. Bu aşama adeta PRINCE2’nin “başlatma” evresine denktir – proje yönetim planı, yönetişim yapısı, sprint takvimi (eğer çevik gelişim olacaksa) bu noktada belirlenir. Ayrıca ekiplere metodoloji ve araçlarla ilgili eğitimler verilir. Bu fazın çıktısı, projenin sağlam bir temel üzerinde başlamasıdır. Örneğin, SAP Activate’e özgü “Proje Ekibi Hazır/Kabiliyet Değerlendirmesi” yapılır, eksik yetkinlik varsa tamamlanır.

  • Explore (Keşfet/Detaylandır): Bu faz, geleneksel ASAP’taki “Business Blueprint” safhasının evrim geçirmiş halidir. Ancak farkı, doküman üzerinden gereksinim toplamak yerine sistem üzerinde keşif atölyeleri (Fit-to-Standard workshops) yapılmasıdır. SAP’nin hazır Best Practice süreçleri canlı bir sistemde gösterilir, iş birimi kullanıcıları bunları görüp kendi ihtiyaçlarıyla kıyaslar. “Standarda uyum” (fit) ve “geliştirme ihtiyacı” (gaps) listeleri çıkarılır. Tüm ek gereksinimler bir Backlog listesine işlenir. Bu backlog, Activate metodolojisinde çok kritik bir yere sahiptir; zira sonraki Realize fazındaki geliştirmeler bu backlog’a göre yapılacaktır. Explore fazının sonunda, proje kapsamı backlog ile baz alınır (baseline) – yani hangi standart süreçlerin aynen kullanılacağı, hangi ek geliştirmelerin yapılacağı netleşir. Örneğin, “Satınalma siparişi onay akışı standart kullanılacak, ek olarak tedarikçi risk skoru entegrasyonu geliştirilecek” gibi kararlar bu aşamada verilir ve onaylanır.

  • Realize (Gerçekleştir): Bu faz, çözümün inşa edildiği dönemdir. SAP Activate burada iteratif (yinelemeli) geliştirme yaklaşımını teşvik eder. Yani backlog’daki işleri alıp bir dizi sprint ile sistemi yapılandırmak ve gerekli geliştirmeleri yapmak esastır. Ekipler paralel sprintler halinde çalışabilir. Her sprint sonunda ortaya çıkan yazılım bileşenleri “Show & Tell” oturumlarıyla iş birimine gösterilip geri bildirim alınır. Bu sayede final kullanıcı testi öncesi birçok mini-test yapılmış olur. Realize fazı boyunca sadece geliştirme değil, veri yükleme denemeleri, sistem entegrasyon testleri de planlı şekilde gerçekleştirilir. SAP Activate, Realize aşamasında her sprint sonunda “solution demo” yapılmasını ve kabul kriterlerine göre onay alınmasını önerir. Bu aşamanın sonunda, tüm yapılandırmalar, geliştirmeler tamamlanmış ve sistem bir bütün olarak kabul testine (UAT) hazır hale gelmiş olmalıdır.

  • Deploy (Canlıya Geçirme): Projenin üretim ortamına geçiş safhasıdır. Son kullanıcı eğitimleri verilir, verilerin canlı ortama yüklenmesi (cutover) gerçekleştirilir, son kontroller yapılır. Bu aşama, aslında klasik Waterfall projelerdeki “Go-Live” dönemine benzer ve çok kısa süreli ama yoğun bir dönemdir. Activate metodolojisi, bu aşamada bir Cutover Planı oluşturulmasını ve iş sürekliliğini koruyacak şekilde geçiş yapılmasını söyler. Tüm hazırlıklar yapıldıktan sonra sistem üretime (kullanıcıların gerçek ortamına) alınır ve proje resmi olarak sonlandırılır.

  • Run (İşletme): Proje sonrası bakım ve destek dönemine verilen isimdir. Bu aşamada proje kapanmış, çözüm artık IT operasyonunun rutin sorumluluğuna geçmiştir. Kullanıcılar canlı sistemi kullanırken, IT ekibi de ortaya çıkan sorunları çözmeye veya küçük iyileştirmeler yapmaya devam edebilir. SAP Activate bu faz için detaylı bir aktivite seti vermez, daha çok ITIL gibi destek süreçlerine referans yapar. Ancak projenin faydalarını izleme (benefits realization) ve varsa sonraki fazları planlama gibi konular burada değerlendirilir.

SAP Activate metodolojisi, tüm bu fazlarda proje ekiplerine yardımcı olacak yol göstericiler ve doküman şablonları da sunar. SAP’nin Roadmap Viewer adlı aracı, her faz ve aktivite için kılavuz bilgiler ve hızlandırıcı dokümanlar içerir. Örneğin Explore fazı için “Fit-to-Standard Workshop Agenda” örneği veya Realize fazı için “Sprint Backlog Template” gibi kaynaklar mevcuttur. Ayrıca SAP’nin Solution Manager ve Focused Build gibi araçları, Activate metodolojisini entegre bir şekilde destekler – gereksinimden test yönetimine kadar tek bir platformda takip yapmaya imkan tanır.

Activate metodolojisini diğerlerinden ayıran önemli bir yön, SAP’nin yılların proje deneyimini içeriyor olmasıdır. Yani Activate, bir yerde SAP’nin “en iyi uygulamalar kataloğu” üzerine inşa edilmiştir. Bu yüzden Activate kullanan bir proje, sıfırdan kendi metodunu geliştirmek zorunda kalmaz; SAP’nin hazır süreç tanımları ve dokümanları üzerinden ilerler. Kullanım alanı doğal olarak SAP projeleriyle sınırlıdır – S/4HANA dönüşümü, SAP bulut ürün implementasyonları gibi projeler Activate için tasarlanmıştır. Başka bir kurumsal yazılım projesine doğrudan uygulanması düşünülmez.

Activate metodolojisinin bir diğer artısı, agile prensipleriyle uyumlu olmasıdır. Nitekim SAP Activate açıkça kendisini “S/4HANA için bir çevik uygulama yaklaşımı” olarak tanımlar. Örneğin backlog kullanımı, sprint’lerle geliştirme, sık sık geri bildirim döngüsü Activate’in özü sayılabilir. Bununla birlikte Activate, tamamen saf bir Agile değildir; fazlı yapısı gereği ve SAP’nin kurumsal müşterilerine hizmet ettiği için, Waterfall’dan gelen bazı yapıları barındırır. Bu nedenle Activate’i bir hibrit metodoloji olarak görmek yanlış olmaz. Hatta Axelos’un PRINCE2 Agile yaklaşımına benzetilebilir – belirli kalite kapıları ve dokümantasyon gereklilikleri ile çevik geliştirme birleştirilir.

Bir örnek üzerinden Activate’i değerlendirelim: Bir şirket, mevcut ERP’sini SAP S/4HANA’ya yükseltme kararı alsın. Discover fazında üst yönetim iş gerekçesini onayladı, proje ekibi kuruldu. Prepare’de proje planı yapıldı, ekip eğitim aldı ve sistem erişimleri kuruldu. Explore aşamasında iş birimleriyle Fit-to-Standard atölyeleri yapıldı; SAP’nin standart fonksiyonları görüldü ve şirketin ek talepleri backlog’a yazıldı. Sonrasında Realize’da, danışmanlar 2-3 haftalık sprint’lerle sistemi kurup geliştirirken, her sprint sonunda anahtar kullanıcılarla bir gösterim yaptı. Bu esnada verilerin temizlenmesi ve taşınması için BT ekibi de paralel çalıştı. Birkaç sprint sonunda tüm fonksiyonlar bitince, entegre testler yapıldı, kullanıcı kabul testleri geçti. Deploy aşamasında hafta sonu bir cutover planıyla eski sistemden yenisine geçiş yapıldı, kullanıcılar eğitildi. Pazartesi günü yeni SAP sistemiyle çalışma başladı (Go-Live). Run aşamasında da proje ekibi bir süre destek verdi ve sonra işleri destek birimine devredip projeyi kapattı. Bu senaryoda Activate, projenin her adımında yol gösterici olmuş oldu.

SAP Activate ile proje izleme ve araçlar: Activate projeleri genelde Jira gibi araçlarla backlog/sprint takibi yaparken, bir yandan MS Project gibi araçlarla yüksek seviyede plan takibi yapılabilir. SAP özelinde, Solution Manager Focused Build aracı, Activate adımlarına uyumlu bir takip sağlar; örneğin backlog kaydı açıp onun hangi çözüm öğelerine (WRICEF – Workflow, Report, Interface, Conversion, Enhancement, Form) karşılık geldiğini yönetebilirsiniz. Proje izleme, Activate’te “faz sonu kalite kontrolleri” ile güvenceye alınır – her faz sonunda belirli teslimatlar gözden geçirilir ve bir sonraki faza geçiş onayı verilir (tıpkı PRINCE2 mantığında). Örneğin Explore fazı sonunda Solution Backlog onaylanmadan Realize’a geçilemez.

Toparlarsak, SAP Activate SAP projelerine özel, entegre bir metodoloji olarak öne çıkar. Waterfall’ın disiplinini, Agile’ın çevikliğini ve SAP’nin hazır en iyi uygulamalar bilgisini harmanlar. SAP ekosistemindeki proje yöneticileri ve danışmanlar için Activate’i bilmek artık neredeyse zorunlu hale gelmiştir. Çünkü SAP, yeni ürünleri için dokümantasyonu, yol haritalarını hep Activate çerçevesinde sunmaktadır. Activate ile yönetilen bir proje, hem SAP’nin yol göstericiliğinden faydalanır hem de modern proje yönetimi pratiklerini (scrum, kanban, sürekli entegrasyon vb.) uygulama şansı bulur. Sonuç olarak, SAP Activate metodolojisi SAP dünyasının güncel ihtiyaçlarına göre şekillendirilmiş, kanıtlanmış ve literatürde kendini ispat etmiş bir yaklaşımdır.

Yukarıda her bir metodolojinin özelliklerini detaylı biçimde ele aldık. Peki bunları belirli kriterler açısından yan yana koyduğumuzda nasıl bir tablo ortaya çıkar? Aşağıdaki karşılaştırma tablosu, farklı yöntemleri iş akışını görselleştirme, iş yükü sınırlandırma, sürekli iyileştirme, esneklik, kullanım alanları, faz yapısı, avantajları ve kullanılan araçlar bakımından özetlemektedir. Bu tablo, metodolojileri hızlıca kıyaslamak isteyenler için pratik bir rehber olacaktır.

Metodolojilerin Karşılaştırma Tablosu


Metodolojilerin Karşılaştırma Tablosu
Metodolojilerin Karşılaştırma Tablosu

Yukarıdaki tablo, metodolojileri hızlı bir bakışta karşılaştırmayı sağlasa da elbette her bir projenin kendine has dinamikleri olabileceğini unutmamak gerekir. Kimi zaman “en iyi” metodoloji diye bir şey yoktur; duruma, ekibe ve hedefe en uygun metodoloji vardır. Hatta çoğu şirkette resmi olarak bir metodoloji uygulansa bile, ekipler zamanla onu kendi ihtiyaçlarına göre değiştirir – bir nevi şirket içi pragmatik metodolojiler oluşur. Önemli olan, temel prensipleri anlamak ve proje koşullarına göre doğru uyarlamayı yapabilmektir.

Özet, Yorumlar ve Uygulama Notları

Proje yönetimi metodolojileri yelpazesi, tıpkı bir araç kutusu gibidir. Waterfall’ın çekici disiplin ve öngörülebilirlik sağlarken çevik metodolojilerin belirsizlikte yön bulma ve hız kazandırma avantajı vardır. Lean ve Six Sigma, süreçleri iyileştirip kaliteyi yükseltirken, PRINCE2 gibi yöntemler kontrol ve yönetişim güvencesi sunar. SAP Activate ise SAP projelerinin bu geniş yelpazedeki ihtiyaçlarını sentezlemeye çalışan, literatürde kendini kanıtlamış bir “melez” yaklaşım olarak karşımıza çıkıyor.

Bir SAP proje yöneticisi veya danışmanı için önemli olan, bu yöntemlerin hangisinin ne zaman daha uygun olduğunu değerlendirebilmektir. Örneğin, proje çıktılarınız kanunlarla sıkı düzenlenmişse ve her adımda onay almak zorundaysanız, saf Agile yaklaşım riskli olabilir – bu durumda Waterfall veya PRINCE2 çizgisini korumak gerekir. Tersine, hedef belirsiz ve inovatif bir çözüme ulaşmaksa, Waterfall ile fırsatları kaçırabilirsiniz; Agile yöntemler deneme-yanılma yoluyla daha iyi sonuç verecektir. SAP projeleri genellikle işin içinde yazılım olduğu ve kurumsal değişim yönetimi de barındırdığı için, hibrit bir strateji sıkça başarılı olmuştur: Analiz ve tasarım için belirli bir çerçeve (Activate’in Explore fazı gibi), geliştirme için çevik sprintler, dağıtım için yine planlı bir yaklaşım birleşik kullanılabilir.

Şunu da vurgulamak gerekir ki, metodoloji araçtır, amaç değil. Nihai amaç projeyi başarıyla tamamlamak, beklenen faydayı gerçekleştirmektir. Bu amaca hizmet ettiği sürece metodolojiler kullanılmalı, aksi halde gerektiğinde adapte edilmelidir. Kimi zaman “kuralları çiğnemek” de gerekebilir – örneğin Scrum yaparken bir sprinti 2 hafta değil de 3 hafta yapmak takımınıza daha uygunsa, manifesto buna engel değildir. Yahut PRINCE2 uyguluyorsunuz diye illa 100 sayfa PID dökümanı yazmak zorunda değilsiniz; gerekliyse yazarsınız.

Bu bakışla, SAP Activate metodolojisi de dahil tüm metodolojileri öğrenmek ama dogmatik yaklaşmamak en sağlıklısıdır. SAP Activate, SAP’nin deneyimlerinin ürünü olsa da her projede körü körüne tüm adımlarını uygulamak yerine, projenin doğasına göre odaklanılacak aktiviteleri seçmek en iyi sonuca götürür. Mesela küçük bir SAP e-ticaret entegrasyonu projesinde Discover fazına uzun zaman ayırmak anlamsız olabilir – doğrudan Prepare/Explore’a geçilebilir. Bu esneklik, deneyimli proje yöneticilerinin kararlarıyla sağlanır.

Sonuç olarak, ister Waterfall ister Agile, ister hibrit veya SAP Activate olsun, başarının sırrı metodolojiden ziyade metodolojiyi uygulayan insanların becerisi ve uyumunda yatar. İyi iletişim, net roller, üst yönetimin desteği, ekibin motivasyonu gibi faktörler, seçilen yöntemden bağımsız olarak proje kaderini belirler. Metodoloji ise bu faktörleri en iyi şekilde yönetecek çerçeveyi sunar. Dolayısıyla, metodolojilere hakim olmak bir SAP profesyoneli için kritik olsa da, bunları işletme içinde doğru kültür ve süreçlerle desteklemek bir o kadar kritiktir.

Umarım bu kapsamlı inceleme, farklı proje yönetim metodolojilerinin ne olduğunu, birbirlerinden nasıl ayrıldığını ve gerçek hayatta nasıl uygulandığını netleştirmeye katkı sağlamıştır. Projelerinizde durumunuza en uygun yaklaşımı seçip veya harmanlayıp, başarıyla uygulamanız dileğiyle.

Kaynakça

Yorumlar

bottom of page