ERP Öncesi Süreç Yönetimi. Bu seride;

○ Bölüm 1: ERP Projelerinin Başarısı Yazılımla Değil, Süreçlerle Başlar

✓ Bölüm 2: Süreç Haritalama Nasıl Yapılır? (Şu an okuyorsunuz)

○ Bölüm 3: Süreç Haritasından Sürekli İyileştirmeye, başlıklı yazılar yer almaktadır.

Süreç Haritalama Nasıl Yapılır?

ERP Öncesi Süreç Yönetimi – Özet

Bir önceki makalede şu tezi ortaya koyduk: ERP projelerinin başarısı, yazılımın kalitesinde değil, o yazılıma girilecek süreç mantığının netliğinde belirlenir. Ancak bu tez tek başına soyut kalıyor. Bir genel müdür veya üretim müdürü için asıl soru şudur: Bu netliği nasıl elde ederim? Kiminle bir araya gelmeliyim, hangi soruları sormalıyım, hangi sırayla ilerlemeliyim?

Bu makale tam olarak bu soruyu cevaplar. Süreç haritalamayı bir çizim egzersizi olarak değil, bir karar mimarisini görünür kılma disiplini olarak ele alır. Doğru süreci seçmekten sahiplik belirlemeye, aktivite ve karar noktalarını netleştirmekten mevcut durumu haritalamaya, darboğazları tespit etmekten hedef duruma geçmeye kadar tüm adımları, Türkiye’nin farklı üretim sahalarından gerçekçi senaryolarla anlatır.

Bu yazının sonunda, kendi işletmenizde bir süreç haritalama çalıştayını planlayıp yürütebilecek düzeyde pratik bilgiye sahip olacaksınız.

Bu Yazıda Neler Öğreneceksiniz?

Bu makaleyi okuduktan sonra şunları yapabilecek durumda olacaksınız:

• Hangi sürecin haritalama için doğru başlangıç noktası olduğuna karar vermek
• Bir sürecin sınırlarını, “nerede başlar, nerede biter” tartışmasını bitirecek netlikte çizmek
• Bir süreç sahibi ile bir süreç katılımcısı arasındaki farkı ayırt etmek
• Bir süreç haritasının dört temel bileşenini (aktivite, karar noktası, girdi/çıktı, olay) doğru tanımlamak
• Swimlane ve sade BPMN mantığını, teknik jargona boğulmadan kullanmak
• Mevcut durumu gerçekçi biçimde haritalamak ve bu haritadan darboğaz ile israf noktalarını çıkarmak
• Hedef durumu tasarlarken ERP’ye aktarılacak kritik bilgileri ayırt etmek
• Ortaya çıkan haritayı, bir kerelik doküman olmaktan çıkarıp kalıcı bir yönetim aracına dönüştürmek

Her bölüm, gerçek bir danışmanlık projesinde yaşanabilecek kadar somut bir fabrika senaryosuyla desteklenmiştir.

Giriş: “Peki Nasıl?” Sorusuna Cevap

Önceki makalede bir işletme sahibiyle yapılan tipik bir görüşmeyi anlatmıştık: masada hep yazılım konuşulur, süreç hiç konuşulmaz. O yazıyı okuyan bir yönetici, muhtemelen şu noktaya gelmiştir: “Tamam, ikna oldum. Önce süreçlerimize bakmalıyız. Peki bunu nasıl yapacağız?”

Bu, tam olarak doğru sorudur ve bu makale ona cevap verir.

Süreç haritalama kelimesi, çoğu yöneticinin zihninde basit bir görüntü canlandırır: bir toplantı odası, duvara yapıştırılmış kağıtlar, oklarla birbirine bağlanmış kutular. Bu görüntü yanlış değildir, ama eksiktir. Çünkü aynı görüntü, hem bir işletmeye gerçekten değer katan bir çalışmanın hem de duvarda toz tutmaya mahkum, işlevsiz bir posterin fotoğrafı olabilir. Aradaki fark, kağıda dökülen çizimde değil, o çizime varılana kadar sorulan sorularda saklıdır.

Önceki makalede bir ayrım yapmıştık: bir süreç haritası size “ne olduğunu” gösterir, ama süreç yönetimi size “kim, neye göre karar veriyor” sorusunu cevaplar. Bu makale, o ayrımı bir adım öteye taşır: iyi kurgulanmış bir süreç haritalama çalışması, baştan itibaren ikinci soruyu da cevaplayacak şekilde tasarlanabilir. Mesele, doğru sırayla ilerlemektir.

Bu yazı boyunca, gerçek bir üretim işletmesinde bir süreç haritalama çalıştayının nasıl planlanacağını, kimlerin katılması gerektiğini, hangi soruların sorulacağını ve ortaya çıkan haritanın bir ERP projesine nasıl doğrudan girdi sağlayacağını, adım adım ele alacağız.

Bölüm 1: Süreç Nedir, Süreç Haritası Nedir?

Bu soruyu sormak, çoğu yöneticiye gereksiz görünür. “Elbette biliyoruz süreç ne demek” der herkes. Ama pratikte, bir işletmede “süreç” kelimesi genellikle üç farklı şeyi ifade etmek için kullanılır: bazen bir departmanın adı (“satınalma süreci” derken aslında “satınalma departmanı” kastedilir), bazen bir yazılım ekranı (“ERP’de sipariş süreci” derken aslında bir modül kastedilir), bazen de gerçekten bir iş akışı.

Bu üçünü birbirinden ayırmak, süreç haritalamanın ilk ve en kritik adımıdır. Bir süreç, belirli bir girdiyle başlayıp belirli bir çıktıyla biten, tanımlı roller tarafından yürütülen, tekrarlanabilir bir işler dizisidir. Departman değildir, yazılım ekranı değildir, bir kişinin günlük rutini de değildir. Bir süreç, bir departmanın sınırlarını aşabilir; genellikle de aşar.

Bir süreç haritası ise bu dizinin görsel temsilidir: hangi adımın hangi adımdan sonra geldiğini, hangi adımların paralel ilerleyebileceğini, sürecin hangi noktada başlayıp hangi noktada bittiğini gösteren bir çizimdir. Ancak burada kritik bir uyarı gerekir: bir süreç haritası, sürecin kendisi değildir. Süreç, işletmede gerçekten olan şeydir; harita, o gerçekliğin bir modelidir. İyi bir model gerçekliği doğru yansıtır; kötü bir model ise haritayı çizenlerin zihnindeki idealize edilmiş versiyonu yansıtır.Bir dokuma makineleri yedek parça üreticisinde yaşanan bir sahne bu farkı net gösterir. İşletme, birkaç yıl önce bir kalite danışmanlık firmasıyla çalışarak tüm ana süreçlerini haritalamıştı. Bu haritalar, ISO belgelendirmesi için hazırlanmış, düzgün, temiz akış şemalarıydı. Yeni bir ERP projesi başladığında, danışmanlık ekibi bu haritaları inceledi ve üretim planlama şefine sordu: “Bu haritada gösterilen adımları, dünkü gerçek bir siparişte birebir izleyebilir miyiz?” Şef gülümsedi: “Hayır, bu harita nasıl çalışmamız gerektiğini gösteriyor. Biz farklı çalışıyoruz.” İşletmenin elinde bir harita vardı, ama bu harita gerçekliğin değil, iyi niyetin belgesiydi.

DANIŞMAN NOTU Bir süreç haritasının ilk testi, “güzel görünüyor mu” değil, “dünkü gerçek bir vakayı bu haritayla birebir anlatabiliyor muyum” sorusudur. Bu teste takılan bir harita, ne kadar profesyonel görünürse görünsün, henüz kullanılabilir değildir.

Peki süreç haritalamanın amacı nedir? Üç farklı düzeyde değer üretir. Birincisi, ortak bir dil oluşturur: aynı süreç hakkında konuşan farklı departmanlar, aynı kelimelerle aynı şeyi kastetmeye başlar. İkincisi, görünürlük sağlar: bir sürecin bütününü gören ilk kişi genellikle haritalama çalışmasına katılan kişilerin kendisidir, çünkü gündelik hayatta herkes yalnızca kendi parçasını görür. Üçüncüsü, ve bu makale açısından en kritik olanı, sonraki çalışmalar için bir temel oluşturur: darboğaz analizi, israf tespiti, ERP’ye aktarım ve sürekli iyileştirme, hepsi doğru çizilmiş bir haritadan başlar.

Boyut	Kötü Süreç Haritası	İyi Süreç Haritası
Kaynak	“Nasıl çalışmalıyız” idealine dayanır	“Gerçekte nasıl çalışıyoruz”a dayanır
Katılımcılar	Tek bir yönetici veya dış danışman tarafından çizilir	Sürecin içindeki farklı rollerin katılımıyla çizilir
İstisnalar	Sadece standart akışı gösterir	İstisna ve sınır durumları da içerir
Karar noktaları	“Onaylanır” gibi belirsiz kutular içerir	Kimin, hangi kritere göre karar verdiğini gösterir
Yaşam süresi	Bir kerelik doküman, arşivde kalır	Düzenli güncellenen, kullanılan bir referans
Test	“Güzel görünüyor mu” ile değerlendirilir	“Dünkü gerçek bir vakayı anlatıyor mu” ile değerlendirilir

EN SIK YAPILAN HATA İşletmeler süreç haritalamayı, belgelendirme (ISO, denetim, sertifikasyon) amacıyla bir kez yapılıp bir daha bakılmayan bir egzersiz olarak görür. Oysa bir süreç haritası, belgelendirme için değil, karar vermek ve iyileştirmek için üretilmelidir; bu iki amaç çoğu zaman farklı haritalar doğurur.

YÖNETİCİYE ÖZEL Elinizde geçmişten kalma süreç haritaları varsa, onları çöpe atmadan önce tek bir soruyla test edin: “Bu haritayı, dün yaşanan gerçek bir vakayı anlatmak için kullanabilir miyim?” Cevap hayırsa, bu haritalar bir başlangıç noktası olabilir ama güncel bir çalışma yerine geçemez.

Süreç ve süreç haritasının ne olduğunu netleştirdiğimize göre, sırada daha pratik bir soru var: bir işletmenin onlarca süreci arasından hangisiyle başlamalı, ve o sürecin sınırlarını nasıl çizmeli? Bir sonraki bölümde bu soruyu ele alıyoruz.

Bölüm 2: Nereden Başlamalı: Doğru Süreci Seçmek ve Sınırlarını Çizmek

Bir işletmenin onlarca, bazen yüzlerce süreci vardır. Satınalmadan sevkiyata, bakımdan insan kaynaklarına kadar her biri haritalanabilir. Bu bolluk, tuhaf bir felç etkisi doğurur: “Her şeyi haritalamalıyız” düşüncesi, çoğu zaman “hiçbir şeyi haritalamıyoruz” sonucuna götürür. İlk soru bu yüzden şudur: hangi süreçle başlamalı?

Doğru cevap, “en kolay olanla” değildir. Doğru cevap, iki kritere birden bakmaktır: etki ve karmaşıklık. Yüksek etkili ama aşırı karmaşık bir süreçle başlamak (örneğin bütün üretim planlama sistemini baştan haritalamak), ekibi daha ilk oturumda yorar ve sonuç alınamadan çalışma terk edilir. Düşük etkili ve basit bir süreçle başlamak ise (örneğin ziyaretçi giriş prosedürü) ekibe “bu çalışma zaman kaybı” hissi verir. Aranan nokta, orta karmaşıklıkta ama gerçek bir acı noktasını temsil eden bir süreçtir: üretim planlama, satınalma onayı veya sipariş yönetimi gibi, herkesin günlük hayatında hissettiği ama kimsenin tam olarak sahiplenmediği bir süreç.

Süreç seçildikten sonra, ondan daha zor ve daha çok göz ardı edilen bir adım gelir: sürecin sınırlarını çizmek. “Nerede başlıyor, nerede bitiyor?” sorusu, kulağa basit gelir ama pratikte bir çalıştayın en çok zaman alan ve en çok anlaşmazlık doğuran tartışmasıdır.

Bir elektronik komponent distribütöründe yaşanan bir sahne bunu net gösterir. İşletme, “Satıştan Siparişe” sürecini haritalamak için bir çalıştay düzenledi. Daha ilk on dakikada, katılımcılar sürecin nerede başladığı konusunda anlaşamadı. Satış ekibi, sürecin “müşteriden talep geldiğinde” başladığını söylüyordu. Üretim planlama ekibi, gerçek sürecin “stok kontrolü yapılıp müsaitlik onaylandığında” başladığını iddia ediyordu. Finans ekibi ise “kredi limiti kontrolünden” önce hiçbir şeyin gerçek anlamda “sipariş” sayılmayacağını savunuyordu. Üç ekip de kendi gerçekliğinden haklıydı; ama işletmenin ortak bir sınır tanımı olmadığı için, ERP’ye aktarılacak “sipariş süreci” kavramı üç farklı başlangıç noktasına sahip üç farklı süreç haline geliyordu.

SAHADAN GÖZLEM Bir sürecin sınırları konusunda anlaşmazlık çıkması kötü bir işaret değildir; aksine, çalışmanın doğru ilerlediğinin göstergesidir. Sınır tartışması hiç yaşanmadan hızla ilerleyen bir çalıştay, muhtemelen yüzeysel kalmıştır.

Bu tartışmayı verimli bir sonuca bağlamanın en pratik yolu, sürece dışarıdan bakan bir çerçeve kullanmaktır: SIPOC. Bu çerçeve, bir sürecin beş temel unsurunu netleştirmeyi zorunlu kılar: Tedarikçi (bu sürece girdiyi kim sağlıyor), Girdi (süreç neyle başlıyor), Süreç (ana adımlar, henüz detaylandırılmadan), Çıktı (süreç neyle sonuçlanıyor), Müşteri (bu çıktıyı kim, ne için kullanıyor). SIPOC’un gücü, detaya inmeden önce sürecin çerçevesini sabitlemesindedir; tam olarak elektronik komponent distribütöründeki tartışmayı çözecek türden bir disiplin.

O işletmede SIPOC çalışması yapıldığında, tartışma netleşti: sürecin girdisi “müşteriden gelen, ürün ve miktar bilgisi içeren resmi talep” olarak tanımlandı; kredi ve stok kontrolü, sürecin başlangıcı değil, sürecin içindeki ilk iki karar noktası olarak konumlandırıldı. Üç ekip de haklıydı, sadece farklı şeylerden bahsediyorlardı; biri sınırdan, biri ilk karar noktasından. SIPOC bu karışıklığı tek oturumda çözdü.

EN SIK YAPILAN HATA Ekipler sınır tartışmasını atlayıp doğrudan detaylı adımları çizmeye başlar. Bu, hızlı ilerliyormuş hissi verir ama genellikle çalışmanın ortasında “bu adım gerçekten bu sürecin parçası mı” sorusuyla her şeyin yeniden ele alınmasına yol açar.

Sınırların net olmaması, sadece bir çalıştay verimsizliği değil, doğrudan bir ERP riskidir. İlk makalede ele aldığımız gibi, ERP sistemine aktarılan her belirsizlik bir özelleştirme talebine dönüşür; süreç sınırı belirsizliği ise bu belirsizliklerin en temel ve en pahalı türüdür, çünkü modülün kapsamını baştan yanlış tanımlar.

YÖNETİCİYE ÖZEL Bir süreç haritalama çalıştayına başlamadan önce, tek bir cümlede sürecin sınırlarını yazılı hale getirin: “Bu süreç [şu olayla] başlar, [şu çıktıyla] biter.” Bu cümle üzerinde katılımcıların mutabık kalması, çalıştayın geri kalanını kat kat hızlandırır.

Doğru süreci seçtiğinizde ve sınırlarını netleştirdiğinizde, bir sonraki soru kaçınılmaz olarak ortaya çıkar: bu sürecin içinde kim ne yapıyor, ve daha da önemlisi, bu sürecin sonuçlarından kim sorumlu? Bir sonraki bölümde, süreç haritalamanın en çok atlanan ama en kritik unsurunu ele alıyoruz: süreç sahipliği ve roller.

Bölüm 3: Süreç Sahibi ve Roller: Haritalamanın Görünmez Omurgası

Bir süreç haritalama çalıştayının en heyecanlı kısmı genellikle adımların çizilmesidir: post-it’ler duvara yapıştırılır, oklar çizilir, herkes kendi işini anlatmaktan keyif alır. Ama bu heyecanın gölgesinde kalan, çoğu zaman sorulmayan bir soru vardır: bu sürecin sahibi kim?

Süreç sahibi, bir sürecin içindeki herhangi bir adımı yapan kişi değildir. Süreç sahibi, sürecin bütününden, baştan sona, tüm departman sınırlarını aşarak hesap veren kişidir. Bu ayrım küçük görünür ama sonuçları büyüktür: bir süreçte çalışan onlarca kişi olabilir, ama süreç sahibi tek kişidir ve bu kişi, sürecin bir bölümünde değil, sürecin tamamında yetkilidir.

Bir otomotiv yan sanayi firmasında yaşanan bir sahne, sahiplik eksikliğinin somut bedelini gösterir. İşletmenin satınalma süreci haritalanmak istendiğinde, danışmanlık ekibi basit bir soruyla başladı: “Bu sürecin sahibi kim?” Cevap beklenmedik biçimde belirsizdi. Satınalma müdürü “teklif toplama ve tedarikçi seçiminden ben sorumluyum” dedi. Finans müdürü “ödeme koşulları ve bütçe onayından biz sorumluyuz” dedi. Depo şefi “malzeme kabul ve stok girişinden ben sorumluyum” dedi. Üçü de kendi parçasından gerçekten sorumluydu; ama sürecin bütününden, baştan sona, hiç kimse sorumlu değildi. Bir tedarikçiyle yaşanan gecikme sorununda, üç yönetici de “benim parçamda sorun yoktu” diyebiliyor, ama sürecin bütününde neyin yanlış gittiğini kimse açıklayamıyordu.

EN SIK YAPILAN HATA İşletmeler bir süreçte “en çok iş yapan” departmanı otomatik olarak süreç sahibi sanır. Oysa süreç sahipliği, iş yükü değil, hesap verebilirlik meselesidir; sürecin en az iş yaptığı ama en çok etkilendiği departman bile, doğru kişiyse süreç sahibi olabilir.

Süreç sahibinin görevi, günlük işleri yürütmek değildir; bu, süreç katılımcılarının işidir. Süreç sahibinin görevi, sürecin performansını izlemek, departmanlar arası çatışmaları çözmek, iyileştirme kararlarını almak ve, bu makale bağlamında kritik olarak, ERP’ye aktarılacak karar kurallarını nihai olarak onaylamaktır. Bir süreç haritalama çalışmasında süreç sahibi netleşmeden ilerlemek, kaptansız bir gemide rota çizmeye benzer: herkes bir yöne işaret edebilir, ama nihai kararı kimse veremez.

Sorumluluk Alanı	Süreç Sahibinin Görevi
Performans izleme	Sürecin uçtan uca performansını (süre, hata oranı, maliyet) düzenli izler
Karar kuralı onayı	Belirsiz kalan karar noktalarında nihai kuralı belirler ve yazılı hale getirir
Çatışma çözümü	Departmanlar arası anlaşmazlıklarda (örneğin sınır tartışmalarında) hakemlik yapar
İyileştirme önceliklendirmesi	Hangi darboğazın önce ele alınacağına karar verir
ERP’ye aktarım onayı	Sürecin sisteme girilecek nihai mantığını onaylar
Güncel tutma	Süreç değiştiğinde haritanın güncellenmesini sağlar

Süreç sahibi netleştikten sonra, ikinci katman gelir: roller. Bir rol, bir kişi değildir; bir sürecin içinde belirli görevleri üstlenen, ismi değil işlevi tanımlanan bir katılımcı türüdür. “Satınalma uzmanı” bir roldür; Ahmet Bey o rolü bugün üstleniyordur, yarın başka biri üstlenebilir. Bu ayrımın önemi, bir süreç haritasının kişilere değil işlevlere bağlı olması gerektiğidir; aksi halde İK’da bir değişiklik olduğunda harita da geçersiz hale gelir.

SAHADAN GÖZLEM Bir çalıştayda katılımcılara “bu adımı kim yapıyor” diye sorulduğunda, genellikle bir kişinin adı söylenir (“Ayşe Hanım yapıyor”). Bu cevap yanlış değildir ama eksiktir. Doğru soru şudur: “Ayşe Hanım bunu hangi rolüyle yapıyor, ve o rol başka hangi adımlarda da devreye giriyor?” Bu ikinci soru, genellikle haritanın gerçek yapısını ortaya çıkarır.

YÖNETİCİYE ÖZEL Süreç haritalama çalıştayına başlamadan önce, süreç sahibini yazılı olarak atayın ve bu atamayı ilgili tüm departmanlara duyurun. Sahiplik çalıştay sırasında “kim üstlenmek ister” tartışmasıyla belirlenmeye çalışılırsa, ya kimse üstlenmek istemez ya da yanlış kişi, sadece sesi en çok çıktığı için sahip ilan edilir.

Süreç sahibi ve roller netleştiğinde, artık haritanın gövdesine geçebiliriz: sürecin içinde gerçekte ne oluyor? Hangi adımlar atılıyor, hangi noktalarda karar veriliyor, süreç neyle besleniyor ve neyle sonuçlanıyor? Bir sonraki bölümde, bir süreç haritasının dört temel bileşenini ele alıyoruz: aktiviteler, karar noktaları, girdi/çıktılar ve olaylar.

Bölüm 4: Bir Süreç Haritasının Anatomisi: Aktiviteler, Karar Noktaları, Girdi-Çıktı, Olaylar

Süreç sahibi belirlendi, roller netleşti. Şimdi sıra, haritanın asıl gövdesine geldi: sürecin içinde gerçekte ne oluyor?

Bir süreç haritası, dört temel yapı taşından oluşur. Bu dördü, birbirinin yerine geçemeyecek kadar farklı işlevler görür ve bir haritalama çalışmasının en sık düştüğü hata, bu dördünü birbirine karıştırmaktır.

Birinci yapı taşı, aktivitedir. Bir aktivite, sürecin içinde birinin gerçekten yaptığı bir iştir: bir teklif hazırlamak, bir siparişi onaylamak, bir parçayı ölçmek. Aktivitenin tanımlayıcı özelliği, bir kişi veya bir sistem tarafından aktif olarak yapılmasıdır. “Sipariş bekler” bir aktivite değildir; bu bir durumdur. “Depo şefi siparişi kontrol eder” bir aktivitedir.

İkinci yapı taşı, karar noktasıdır. Bir karar noktası, sürecin birden fazla yola ayrılabildiği andır. Burada kritik olan, karar noktasının kendisini çizmek değil, o noktadaki kararın hangi kritere göre verildiğini yazmaktır. İlk makalede bu ayrımı ayrıntılı işlemiştik: “onaylanır” yazan bir kutu, karar noktası değil, gizlenmiş bir belirsizliktir.

Üçüncü yapı taşı, girdi ve çıktılardır. Her aktivite bir şeyle beslenir ve bir şey üretir. Girdi, bir aktivitenin başlayabilmesi için gereken bilgi, malzeme veya onaydır; çıktı, o aktivitenin tamamlanmasıyla ortaya çıkan sonuçtur. Bir aktivitenin girdisi genellikle bir önceki aktivitenin çıktısıdır, ama her zaman değil; bazen girdi, sürecin dışından (bir müşteriden, bir tedarikçiden, bir başka süreçten) gelir.

Dördüncü yapı taşı, olaylardır. Bir olay, sürecin akışında gerçekleşen, kendiliğinden bir sonuç veya durum değişikliğidir: “sipariş onaylandı”, “malzeme depoya ulaştı”, “kalite testi tamamlandı”. Olaylar, aktivitelerle karıştırılmaya en müsait unsurdur; çünkü ikisi de kutu olarak çizilir. Ama aralarındaki fark netleştirilmezse, harita “kim ne zaman ne yapıyor” sorusuna doğru cevap veremez.

Bu dört unsurun birlikte nasıl çalıştığını, bir plastik enjeksiyon fabrikasında yaşanan bir örnek üzerinden görelim. İşletme, üretim planlama sürecini haritalarken, kalıp değişimi konusunda bir belirsizlikle karşılaştı. Çalıştaydaki ilk taslak şöyleydi: “Planlama şefi kalıp değişim kararı verir” tek bir kutuda gösterilmişti. Danışmanlık ekibi sordu: “Bu kararı tetikleyen şey nedir? Planlama şefi her sabah rastgele mi karar veriyor?”Bu soru, gizli kalmış bir olayı ortaya çıkardı: kalıp değişim kararı aslında iki farklı olaydan biriyle tetikleniyordu; ya “günlük üretim hedefi tamamlandı” olayıyla, ya da “acil sipariş sisteme düştü” olayıyla. Bu iki olay, iki farklı karar noktasına yol açıyordu: birincisinde planlama şefi bir sonraki planlı kalıbı devreye alıyordu, ikincisinde ise mevcut kalıbı durdurup durdurmama kararını kalite şefiyle birlikte veriyordu, çünkü yarım kalan bir üretim partisinin kalite riski oluşturup oluşturmadığını değerlendirmesi gerekiyordu. Tek bir belirsiz kutu, gerçekte iki olay, iki karar noktası ve iki farklı rolün devreye girdiği bir yapıyı gizliyordu.

DANIŞMAN NOTU Bir aktivite kutusunun içinde “karar verir” ifadesi görüyorsanız, orada durup sorun: “Bu kararı tetikleyen olay nedir?” Bu tek soru, çoğu zaman haritanın en kritik ve en gizli katmanını ortaya çıkarır.

Girdi ve çıktıların netleşmemesi de benzer bir risk taşır, ama daha sinsi biçimde. Aynı fabrikada, “malzeme talebi oluşturulur” aktivitesinin girdisi olarak sadece “üretim planı” yazılmıştı. Ancak derinlemesine sorulduğunda, gerçek girdinin üç parçadan oluştuğu ortaya çıktı: üretim planı, güncel stok seviyesi ve tedarikçi teslim süresi. Bu üç girdiden biri eksik olduğunda (örneğin stok seviyesi güncel değilse), aktivite gerçekte yapılamıyordu ama harita bunu göstermiyordu; sanki tek bir girdiyle her zaman sorunsuz ilerleyen bir adımmış gibi duruyordu.

Bileşen	Tanımlayıcı Soru	Yaygın Karıştırma
Aktivite	Burada kim, hangi işi yapıyor?	Bir durum (“bekliyor”) aktivite sanılır
Karar noktası	Bu noktada hangi kritere göre karar veriliyor?	“Onaylanır” gibi belirsiz kutular karar noktası sanılır
Girdi/Çıktı	Bu aktivite neyle besleniyor, neyi üretiyor?	Girdinin sadece bir parçası yazılır, diğerleri atlanır
Olay	Bu kararı veya aktiviteyi tetikleyen şey ne?	Olay ile aktivite birbirine karıştırılır

YÖNETİCİYE ÖZEL Çalıştay sırasında ekibinize şu dört soruyu sırayla sordurun: “Burada kim ne yapıyor?”, “Bu iş nasıl tetiklendi?”, “Bu işe başlamak için elimizde ne olmalı?”, “Bu iş bittiğinde ortaya ne çıkıyor?” Bu dört soru, dört yapı taşını doğal biçimde ortaya çıkarır ve haritanın atlanan katmanlarını görünür kılar.

Bu dört bileşen netleştiğinde, elinizde artık gerçek bir süreç haritasının iskeleti var demektir. Ancak bu iskeleti kağıda dökerken, ekibin ortak bir görsel dile ihtiyacı vardır; aksi halde herkes kendi tarzında çizer ve harita, bir kişiden diğerine anlaşılmaz hale gelir. Bir sonraki bölümde, bu ortak dili ele alıyoruz: swimlane mantığını ve teknik detaya boğulmadan sade bir BPMN yaklaşımını.

Bölüm 5: Haritalama Dilini Öğrenmek: Swimlane ve BPMN Mantığı

Bir süreç haritalama çalıştayının sonunda, genellikle şu sahne yaşanır: duvarda onlarca post-it var, oklar çizilmiş, herkes kendi bölümünü anlamış. Ama iki hafta sonra o haritayı temize çekip ekip dışındaki birine gösterdiğinizde, karşı taraf sorar: “Bu kutu ne demek, bu ok neyi gösteriyor?” Ortak bir görsel dil olmadan üretilen bir harita, sadece onu çizenler için anlamlıdır.

Bu ortak dilin iki temel bileşeni vardır: swimlane mantığı ve sade bir BPMN yaklaşımı.

Swimlane, sorumluluğu görünür kılan bir düzenlemedir. Fikir basittir: sayfayı yatay şeritlere bölersiniz, her şeridi bir role ayırırsınız, ve her aktiviteyi ait olduğu rolün şeridine yerleştirirsiniz. Bu düzenlemenin gücü, “kim ne yapıyor” sorusunu metinle değil, konumla cevaplamasıdır. Bir aktivite sürecin ortasında bir şeritten diğerine geçtiğinde, bu geçiş görsel olarak hemen fark edilir; ve bu geçişler, genellikle bir sürecin en kırılgan noktalarıdır.

Bir CNC işleme atölyesinde yaşanan bir örnek bunu net gösterir. İşletme, bir parça üretim istasyonunun sürecini haritalarken, swimlane kullanmadan önce sadece doğrusal bir akış çizmişti: “parça işlenir, kontrol edilir, sevke hazırlanır.” Swimlane uygulandığında, gizli kalmış bir gerçek ortaya çıktı: “kontrol edilir” adımı aslında operatörün kendi ölçümü ile kalite teknisyeninin bağımsız kontrolü arasında, günün saatine ve iş yüküne göre değişen bir geçiş içeriyordu. Vardiya yoğunken operatör kendi ölçümüyle yetiniyor, kalite teknisyeni sadece örnekleme yapıyordu; sakin saatlerde ise her parça kalite teknisyeninden geçiyordu. Bu değişkenlik, doğrusal akışta görünmüyordu; swimlane’de operatör ve kalite şeritleri arasındaki geçişin tutarsızlığı olarak hemen göze çarptı.

DİKKAT EDİLMESİ GEREKENLER Swimlane’de bir aktivite iki şerit arasında sık sık gidip geliyorsa (operatörden kaliteye, kaliteden operatöre, tekrar operatöre), bu genellikle bir tasarım sorununun işaretidir. Sağlıklı bir süreçte, bir aktivite bir şeritten diğerine net ve az sayıda geçiş yapar; sık geçiş, sorumluluk belirsizliğinin görsel imzasıdır.

Swimlane, “kim” sorusunu çözer. BPMN (İş Süreci Modelleme Notasyonu) ise “ne tür bir adım” sorusunu çözer. BPMN’nin tam teknik standardı, onlarca sembol ve kural içerir; bu makalenin amacı bu teknik derinliğe girmek değildir. Ancak bir yöneticinin ve bir süreç ekibinin bilmesi gereken, işin gerçek değişimini sağlayan birkaç temel sembol vardır.

Sembol	Anlamı	Kullanım Örneği
Yuvarlak (ince çizgi)	Başlangıç olayı	“Müşteri siparişi alındı”
Yuvarlak (kalın çizgi)	Bitiş olayı	“Sevkiyat tamamlandı”
Dikdörtgen (köşeleri yumuşatılmış)	Aktivite (görev)	“Teklif hazırlanır”
Eşkenar dörtgen (baklava)	Karar noktası	“Kredi limiti yeterli mi?”
Ok	Akış yönü	Bir adımdan diğerine geçiş
Kesikli ok	Bilgi/mesaj akışı	Bir sistemden diğerine veri aktarımı

Bu altı sembol, bir sürecin yüzde doksanını anlatmaya yeter. İşletmelerin büyük çoğunluğu için bunun ötesine geçmek (alt süreçler, olay tabanlı ara kesmeler, karmaşık ağ geçitleri gibi ileri BPMN unsurları) gerekli değildir; bu detaylar, ancak bir süreç doğrudan bir BPMN motoruyla otomatikleştirilecekse anlam kazanır.

DANIŞMAN NOTU BPMN’yi tam teknik standardıyla öğretmeye çalışmak, çoğu çalıştayı boğar ve katılımcıları haritalamaktan çok notasyon öğrenmeye odaklar. Amaç, ekibin BPMN sertifikası almasını sağlamak değil, ekibin aynı sembolü gördüğünde aynı şeyi anlamasını sağlamaktır. Altı sembol, bu amaç için fazlasıyla yeterlidir.

Peki bu haritalar hangi araçla çizilmeli? Cevap, çalışmanın aşamasına göre değişir.

Araç	Ne Zaman Kullanılır	Avantajı	Sınırı
Post-it ve pano	İlk keşif oturumları	Hızlı, herkes katılabilir	Kalıcı değil, paylaşılması zor
Excel veya basit tablo	Görev/rol/olay listesini düzenlemek	Herkeste var, öğrenme eğrisi yok	Görsel akışı göstermekte zayıf
Visio veya benzeri çizim yazılımı	Temize çekilmiş, paylaşılacak harita	Profesyonel görünüm, kolay düzenleme	Sürüm kontrolü zayıf
Adanmış BPMN yazılımı	Kalıcı, kurumsal, ERP’ye bağlanacak haritalar	Sürüm kontrolü, ortak erişim, simülasyon	Öğrenme eğrisi, maliyet

EN SIK YAPILAN HATA İşletmeler ya en baştan pahalı bir yazılıma yatırım yapıp ekibi bunaltır, ya da hiçbir zaman post-it aşamasından çıkmaz. Doğru yaklaşım, keşif aşamasında en basit araçla hızlı ilerlemek, ancak harita olgunlaştığında onu kalıcı ve paylaşılabilir bir ortama taşımaktır.

YÖNETİCİYE ÖZEL İlk çalıştayınıza asla bir yazılımla başlamayın. Post-it ve pano yeterlidir. Yazılım yatırımı kararını, en az bir süreci uçtan uca elle haritaladıktan ve bu haritanın gerçekten işe yaradığını gördükten sonra verin.

Artık elimizde hem sürecin bileşenleri hem de bunları ifade edecek ortak bir dil var. Sırada, bu dili kullanarak sürecin bugün gerçekte nasıl işlediğini, olduğu gibi, süslemeden çizmek geliyor. Bir sonraki bölümde, mevcut durum haritalamanın nasıl yapılacağını ele alıyoruz.

Bölüm 6: Mevcut Durumu Çizmek: As-Is Haritalama Nasıl Yapılır

“As-Is” (mevcut durum) ifadesi, süreç yönetimi literatüründe en çok kullanılan ama en çok yanlış uygulanan kavramlardan biridir. Kelime anlamı nettir: sürecin şu an, gerçekte, olduğu gibi haritalanmasıdır. Ama pratikte, bir çalıştay odasına on kişi bir araya geldiğinde, “olduğu gibi” çizmek göründüğünden çok daha zordur; çünkü herkesin zihninde, farkında olmadan, “olması gereken” versiyonu devreye girer.

Bir beyaz eşya yan sanayi firmasında yaşanan bir sahne bunu açık biçimde gösterir. İşletme, gelen malzeme kalite kontrol sürecini haritalamak için bir çalıştay düzenledi. Kalite şefi, süreci şöyle anlattı: “Malzeme gelir, numune alınır, laboratuvarda test edilir, sonuç uygunsa depoya kabul edilir.” Temiz, mantıklı, dört adımlık bir akış. Danışmanlık ekibi, bu akışı doğrulamak için kalite teknisyenlerinden biriyle sahada birebir görüştü. Gerçek akış farklıydı: teslimat yoğun günlerde, numune alma adımı atlanıyor, sadece sevk irsaliyesindeki bilgiye güvenilerek malzeme depoya alınıyordu; test sonucu iki gün sonra geldiğinde, eğer uygunsuzluk çıkarsa, malzeme depodan geri çağrılmaya çalışılıyordu, ki bu çoğu zaman çok geçti çünkü malzeme üretimde kullanılmıştı bile.

Kalite şefinin anlattığı süreç, gerçek değildi, olması gereken haldi. Sahadaki gerçek süreç, çok daha riskli ve çok daha karmaşıktı. Bu fark ortaya çıkmasaydı, ERP’ye kurulacak kalite modülü, hiçbir zaman gerçekleşmeyen ideal bir akışı kodlayacak ve sistem devreye girdiğinde, yoğun günlerdeki bu kısayol ya tamamen imkânsız hale gelecek ya da kullanıcılar sistemi atlatmanın yeni yollarını bulacaktı.

SAHADAN GÖZLEM Bir toplantı odasında anlatılan süreç ile sahada gözlemlenen süreç arasında fark yoksa, muhtemelen yeterince derine inilmemiştir. Neredeyse her süreçte, yoğunluk anlarında, tatil dönemlerinde veya personel eksikliğinde devreye giren “resmi olmayan” bir kısayol vardır; bu kısayol tespit edilmeden çizilen bir harita, sadece sakin günlerin fotoğrafını çeker.

Bu riski azaltmanın en etkili yolu, As-Is haritalamayı iki kaynaktan beslemektir: toplantı odasındaki anlatım ve sahadaki doğrudan gözlem. Toplantı odası, sürecin genel yapısını ve rolleri hızlıca ortaya çıkarır; saha gözlemi ise gerçek istisnaları, kısayolları ve söylenmeyen ayrıntıları yakalar. Sadece toplantı odasıyla yetinen bir çalışma, resmi anlatıyı; sadece sahayı gözlemleyen bir çalışma ise bağlamdan kopuk, parçalı bir görüntüyü üretir. İkisi birlikte kullanıldığında, gerçek bir As-Is ortaya çıkar.

As-Is haritalama sırasında dikkat edilmesi gereken bir başka nokta, istisnaların haritadan çıkarılmaması gerektiğidir. İlk makalede, ERP projelerindeki en pahalı kırılma noktalarının tam olarak istisna anlarında yaşandığını göstermiştik. Bu nedenle, As-Is çalışmasında “genellikle böyle oluyor, ama şu durumda farklı” cümlesi duyulduğunda, bu farklılık atlanmamalı, ayrı bir dal olarak haritaya eklenmelidir.

Pratikte bunu yapmanın basit bir yolu, her aktivite için şu üç soruyu sormaktır: “Bu her zaman böyle mi olur?”, “Yoğun dönemde farklı bir şey oluyor mu?”, “Birisi izinliyken veya sistem çalışmıyorken ne yapılıyor?” Bu üç soru, gizli kalmış istisnaların büyük kısmını yüzeye çıkarır.

EN SIK YAPILAN HATA Çalıştay katılımcıları, istisna durumlarını “nadiren oluyor, önemli değil” diyerek haritadan çıkarmak ister; çünkü istisnaları anlatmak zaman alır ve akışı karmaşıklaştırır. Oysa bir sürecin en riskli anları, tam olarak bu “nadiren olan” durumlardır ve haritadan çıkarılan her istisna, ileride ya bir ERP kırılma noktasına ya da sahada devam eden gölge bir sürece dönüşür.

As-Is haritalama tamamlandığında, elinizde artık süslenmemiş, gerçek bir resim var: süreç gerçekte nasıl işliyor, nerede istisnalar var, nerede tutarsızlıklar var. Bu resim, kendi başına rahatsız edici olabilir; çoğu işletme, kendi süreçlerinin ne kadar dağınık olduğunu ilk kez bu haritada görür. Ama bu rahatsızlık, tam olarak aranan şeydir; çünkü bu haritanın asıl değeri, bir sonraki adımda ortaya çıkar: nerede darboğaz var, nerede israf var? Bir sonraki bölümde bu analizi ele alıyoruz.

Bölüm 7: Darboğaz ve İsraf Analizi: Haritanın Ortaya Çıkardığı Gerçek

Bir As-Is haritası tamamlandığında, çoğu ekip aynı tepkiyi verir: “Bunu hiç bu şekilde görmemiştik.” Bu tepki, haritalamanın en değerli anıdır; çünkü artık süreç, dağınık gerçekliğiyle, tek bir sayfada görünür hale gelmiştir. Bu görünürlük, iki türden soruna doğrudan işaret eder: darboğazlar ve israf noktaları.

Bir darboğaz, sürecin akışını yavaşlatan, diğer adımların bekleyerek zaman kaybettiği noktadır. Bir israf ise, sürecin hiçbir gerçek değer üretmeyen, sadece zaman ve kaynak tüketen adımıdır. İkisi bazen aynı noktada çakışır, ama kavramsal olarak farklıdır: bir darboğaz genellikle gerekli ama yetersiz kapasiteli bir adımdır (örneğin tek bir kişinin onayladığı bir onay noktası); bir israf ise, kapasitesi ne olursa olsun, hiç var olmaması gereken bir adımdır.

Bir tekstil hazır giyim deposunda yaşanan bir örnek, bu ikisinin nasıl bir arada ortaya çıktığını gösterir. İşletme, sipariş toplama sürecini haritaladığında, akışta şu adımlar görünüyordu: sipariş listesi yazdırılır, depo görevlisi rafları dolaşarak ürünleri toplar, toplanan ürünler paketleme masasına götürülür, orada sayılır, ardından sevkiyat alanına taşınır. Harita tamamlandığında, iki ayrı sorun netlik kazandı.

Birincisi, bir darboğazdı: sipariş listesi yazdırma adımı, tek bir yazıcıdan ve tek bir depo sorumlusundan geçiyordu. Yoğun günlerde, diğer görevliler ellerinde iş olmadan bu yazdırma adımını bekliyordu; çünkü kapasitesi yetersiz, ama gerekli bir adımdı.İkincisi, bir israftı: paketleme masasındaki sayım adımı, aslında raflardan toplama sırasında zaten bir kez yapılan sayımın birebir tekrarıydı. Depo görevlisi ürünleri raftan alırken zaten sayıyordu; paketleme masasındaki ikinci sayım, hiçbir yeni bilgi üretmiyordu, sadece geçmişte yaşanan bir güven sorunu yüzünden (bir dönem yanlış sayımlar sevkiyata gitmişti) kurumsal bir alışkanlık olarak kalmıştı. Bu adım tamamen kaldırılabilirdi; kaldırılmadığı için her gün, her siparişte, gereksiz yere zaman tüketiliyordu.

SAHADAN GÖZLEM Darboğazlar genellikle gürültülüdür; insanlar bekler, şikayet eder, “bu adım bizi yavaşlatıyor” der. İsraflar ise sessizdir; kimse şikayet etmez çünkü israf, kimsenin canını doğrudan yakmaz, sadece sistemin görünmeyen bir yerinde kaynak tüketir. Bir haritalama çalışmasının değeri, gürültülü darboğazları değil, sessiz israfları da yüzeye çıkarmasındadır.

İsraf noktalarını sistematik biçimde ayıklamak için, Yalın Üretim yaklaşımının klasik israf sınıflandırması, üretim dışı süreçlere de rahatlıkla uyarlanabilir:

İsraf Türü	Üretim Dışı Süreçte Örnek	Depo Örneğindeki Karşılığı
Fazla üretim/işlem	Gerekenden fazla bilgi veya onay üretmek	Zaten yapılmış bir sayımı tekrar yapmak
Bekleme	Bir adımın bir öncekini beklemesi	Tek yazıcıyı beklemek
Taşıma	Gereksiz fiziksel veya dijital hareket	Ürünün gereksiz yere bir masaya taşınması
Fazla stok/envanter	Gereğinden fazla biriktirme	Sayılmayı bekleyen ürün yığınları
Gereksiz hareket	Kişinin gereksiz yere dolaşması	Görevlinin yazıcı için sık sık başka masaya gitmesi
Hata ve yeniden işleme	Bir işin yanlış yapılıp tekrar yapılması	Yanlış toplanan ürünün rafa geri konması
Kullanılmayan yetenek	Kişinin yetkinliğinin doğru kullanılmaması	Deneyimli bir görevlinin sadece sayım yapması

DİKKAT EDİLMESİ GEREKENLER Bir adımı “israf” ilan etmeden önce, o adımın gerçekten hiçbir değer üretmediğinden emin olun. Bazı adımlar, ilk bakışta gereksiz görünse de, geçmişte yaşanan somut bir sorunu önlemek için eklenmiştir. Doğru yaklaşım, adımı hemen kaldırmak değil, “bu adımı doğuran sorun hâlâ geçerli mi?” sorusunu sormaktır. Depo örneğinde, ikinci sayımı doğuran güven sorunu yıllar önce çözülmüştü; adım sadece alışkanlıktan kalmıştı. Ama bazı işletmelerde benzer bir adım, hâlâ geçerli bir riski karşılıyor olabilir.

Darboğaz ve israf analizi, bir haritalama çalışmasını resim çizme egzersizinden karar destek aracına dönüştüren adımdır. Bu analiz olmadan bir As-Is haritası, sadece mevcut kaosun güzelce çerçevelenmiş bir fotoğrafıdır. Analizle birlikte, aynı harita, nereye müdahale edileceğini gösteren bir yol haritasına dönüşür.

Peki bu tespitler netleştikten sonra ne yapılır? Sadece darboğazı gidermek veya israfı kaldırmak yeterli midir, yoksa sürecin bütününü yeniden mi tasarlamak gerekir? Ve bu yeniden tasarım, ERP projesine nasıl aktarılır? Bir sonraki bölümde, hedef durum tasarımını ve bu tasarımın ERP açısından taşıdığı kritik bilgileri ele alıyoruz.

Bölüm 8: Hedef Duruma Geçiş: To-Be Tasarımı ve ERP’ye Aktarım

As-Is haritası, size neyin yanlış gittiğini gösterir. To-Be (hedef durum) tasarımı ise, size neyin doğru olması gerektiğini sorar. Bu iki soru birbirine benzer görünür ama aralarında kritik bir fark vardır: To-Be, As-Is’in sadece düzeltilmiş bir kopyası değildir; sürecin sıfırdan, hangi amaca hizmet ettiği sorularak yeniden tasarlanmasıdır.

Bu fark, pratikte sık atlanır. Çoğu ekip, darboğaz ve israf tespitinden sonra doğrudan “bu adımı kaldıralım, şu adımı hızlandıralım” şeklinde küçük düzeltmelere geçer. Bu düzeltmeler faydalı olabilir, ama gerçek bir To-Be tasarımı, daha kökten bir soru sorar: “Bu sürecin nihai amacı neyse, bugünkü adımların hiçbirini bilmeseydik, bu amaca en kısa yoldan nasıl ulaşırdık?”

Bir makine imalat firmasında yaşanan bir örnek, bu farkı somutlaştırır. İşletmenin sevkiyat sürecinde, As-Is haritası şunu gösteriyordu: sevkiyat evrakı (irsaliye, fatura, kalite sertifikası, ihracat belgeleri) dört farklı departman tarafından, sırayla, elden ele hazırlanıyordu. Depo irsaliyeyi hazırlıyor, finans faturayı kesiyor, kalite sertifikayı imzalıyor, dış ticaret ihracat belgelerini tamamlıyordu. Her devir, ortalama yarım gün bekleme süresi ekliyordu; bir sevkiyatın evrak süreci toplamda iki gün sürebiliyordu.

İlk refleks, “bu devirleri hızlandıralım” olabilirdi: her departmana bir hatırlatma sistemi kurmak, bekleme sürelerini kısaltmaya çalışmak. Ama To-Be tasarımı sırasında sorulan soru farklıydı: “Bu evrakların nihai amacı, sevkiyatın yasal ve ticari olarak eksiksiz çıkmasını sağlamaktır. Bu amaca ulaşmak için evrakların sırayla mı, yoksa paralel mi hazırlanması gerekir?” Cevap açıktı: dört evrakın çoğu, birbirinden bağımsız hazırlanabilirdi; sadece faturanın kesilmesi, irsaliyedeki miktar bilgisine bağlıydı. To-Be tasarımında süreç, sıralı dört adımdan, bir senkronizasyon noktasıyla birleşen paralel bir yapıya dönüştürüldü: irsaliye hazırlanır hazırlanmaz, kalite ve dış ticaret kendi belgelerini eş zamanlı hazırlamaya başlıyor, fatura ise irsaliye tamamlandığı anda kesiliyordu. İki günlük süreç yarım güne indi; sadece hızlandırılarak değil, yeniden tasarlanarak.

DANIŞMAN NOTU To-Be tasarımının en yaygın tuzağı, “mevcut adımları nasıl hızlandırırız” sorusuyla başlamaktır. Doğru başlangıç sorusu şudur: “Bu sürecin var olma amacı nedir, ve bu amaca bugünkü adımların hiçbirini miras almadan nasıl ulaşırız?” Bu soru, küçük iyileştirmeler yerine yapısal yeniden tasarımı mümkün kılar.

To-Be tasarımı tamamlandığında, serinin ilk makalesinde bıraktığımız yere döneriz: bu tasarımın ERP’ye aktarılması. Burada kritik olan, To-Be haritasının her köşesinin sisteme aynı önemde aktarılmadığıdır. Bir süreç haritası, genel bir anlayış aracıyken; ERP’ye aktarılacak olan, bu haritanın içinden süzülmüş, belirli bir alt kümedir.

ERP açısından kritik olan bilgiler şunlardır: her karar noktasındaki nihai kural (kim, hangi eşiğe göre karar veriyor), her rol geçişindeki veri gereksinimi (bir sonraki role hangi bilginin, hangi formatta aktarılması gerektiği), her istisna senaryosunun nasıl yönetileceği, ve hangi adımların sistemde otomatik, hangilerinin hâlâ manuel bir onay gerektirdiği. Sevkiyat örneğinde, ERP’ye aktarılacak en kritik bilgi, paralel çalışan üç departmanın hangi ortak veri noktasında (irsaliye tamamlanma olayında) senkronize olacağıydı; bu senkronizasyon noktası netleşmeden sisteme girilen bir paralel akış, üç departmanın birbirini beklemeden hatalı ilerlemesine yol açabilirdi.

Boyut	As-Is (Mevcut Durum)	To-Be (Hedef Durum)
Amaç	Süreç bugün gerçekte nasıl işliyor, olduğu gibi göstermek	Süreç, nihai amacına en kısa yoldan nasıl ulaşır, tasarlamak
Başlangıç noktası	Sahadaki gerçek gözlem ve anlatım	Sürecin var olma amacı
İçerik	İstisnalar, kısayollar, tutarsızlıklar dahil edilir	Yalnızca amaca hizmet eden adımlar yer alır
Değeri	Darboğaz ve israfın nerede olduğunu gösterir	Nasıl çalışılması gerektiğine dair somut bir hedef sunar
ERP ile ilişkisi	ERP’ye doğrudan aktarılmaz, teşhis aracıdır	ERP’ye aktarılacak nihai mantığın kaynağıdır

YÖNETİCİYE ÖZEL To-Be tasarımını, ERP tedarikçisi seçilmeden önce tamamlayın. Aksi halde, tasarım kararlarını yazılımın mevcut kısıtlarına göre şekillendirme riskiyle karşılaşırsınız; bu, “yazılım bunu yapamıyor, o zaman böyle tasarlamayalım” mantığıyla, aslında işletmenizin ihtiyacını değil, seçilen sistemin sınırlarını yansıtan bir sürece razı olmanız anlamına gelir.

EN SIK YAPILAN HATA Ekipler, To-Be tasarımını “As-Is’teki sorunları düzeltmek” olarak sınırlar ve büyük resmi kaçırır. Sevkiyat örneğinde, sadece “devirler arası bekleme süresini kısaltalım” denmiş olsaydı, süreç yine sıralı kalır, sadece biraz daha hızlı işlerdi. Yapısal soru sorulmasaydı, paralel çalışma fırsatı hiç görülemezdi.

Elinizde artık netleşmiş bir To-Be haritası ve bu haritanın ERP’ye aktarılacak kritik noktaları var. Ama bir harita, ne kadar iyi tasarlanmış olursa olsun, kağıt üzerinde kaldığı sürece hiçbir işe yaramaz. Bir sonraki bölümde, bu tasarımın nasıl kalıcı bir standart haline getirileceğini ve nasıl dokümante edileceğini ele alıyoruz.

Bölüm 9: Süreç Standardizasyonu ve Dokümantasyon: Haritanın Kalıcı Hale Gelmesi

Bir çalıştayın sonunda ortaya çıkan harita, ne kadar iyi tasarlanmış olursa olsun, kendiliğinden kalıcı olmaz. Çalıştay biter, katılımcılar günlük işlerine döner, ve birkaç ay sonra harita bir klasörde ya da paylaşılan bir sürücüde unutulmaya başlar. Bu unutuluş, kötü niyetten değil, standardizasyon ve dokümantasyon adımının atlanmasından kaynaklanır.

Standardizasyon, bir sürecin tasarlanan halinin, günlük uygulamanın varsayılan biçimi haline getirilmesidir. Dokümantasyon ise, bu standardın herkesin erişebileceği, güncellenebilir bir referansa dönüştürülmesidir. İkisi birbirinden ayrı işlemlerdir: bir süreç standartlaştırılabilir ama hiç dokümante edilmemiş olabilir (o zaman standart, yine birkaç kişinin kafasında yaşar); ya da tam tersi, güzel dokümante edilmiş ama kimse tarafından uygulanmayan bir standart olabilir (o zaman dokümantasyon, sadece bir raf süsüdür).

Bir gıda üretim tesisinde yaşanan bir örnek, bu ikisinin birlikte nasıl işlemesi gerektiğini gösterir. İşletme, ekipman arıza bildirim sürecini haritalamış ve yeniden tasarlamıştı: bir arıza fark edildiğinde, operatör belirli bir formu doldurup bakım ekibine iletecek, bakım ekibi arızayı önem derecesine göre sınıflandırıp müdahale sırasına koyacaktı. Çalıştay sonunda herkes bu yeni akışı onaylamıştı. Üç ay sonra yapılan bir denetimde, operatörlerin üçte birinin hâlâ eski yöntemi kullandığı, yani arızayı doğrudan bakım şefine telefonla bildirdiği ortaya çıktı. Yeni süreç hiçbir yerde yazılı değildi; sadece çalıştaya katılanların hafızasında yaşıyordu, ve çalıştaya katılmayan operatörler eski alışkanlıklarını sürdürüyordu.

EN SIK YAPILAN HATA Bir çalıştayda üzerinde anlaşılan yeni süreç, sadece sözlü bir mutabakat olarak kalır; yazıya dökülmez veya yazıya döküldüğünde çalıştaya katılmayanlara hiç ulaştırılmaz. Bu durumda, “yeni süreç” aslında hiç var olmamış gibi davranır; çünkü bir standart, sadece onu bilenler için bir standarttır.

Bu riski önlemenin yolu, dokümantasyonu çalıştayın bir sonraki adımı değil, çalıştayın kendisinin bir çıktısı olarak tasarlamaktır. Pratikte bu, üç unsuru gerektirir: birincisi, sürecin güncel halinin herkesin erişebileceği tek bir kaynakta tutulması, ikincisi, bu kaynağın süreç sahibi tarafından düzenli aralıklarla gözden geçirilmesi, üçüncüsü, sürece yeni katılan kişilerin bu dokümana yönlendirilmesinin, işe alım sürecinin doğal bir parçası haline getirilmesi.

Gıda üretim tesisinde, bu üç unsur sonradan devreye alındığında, sorun kökten çözüldü: yeni süreç, tek sayfalık, görsel bir akış şeması ve kısa bir açıklama olarak vardiya panolarına asıldı; bakım şefi, her ay bu sürecin uygulanıp uygulanmadığını rastgele örneklemle kontrol etmeye başladı; ve yeni işe başlayan her operatöre, oryantasyon sürecinin bir parçası olarak bu doküman gösterildi.

YÖNETİCİYE ÖZEL Bir süreç haritalama çalışmasını, “harita çizildi, iş bitti” diyerek kapatmayın. Çalışmanın gerçek bitiş noktası, haritanın herkesin erişebileceği bir yerde durması, düzenli gözden geçirilmesi ve yeni katılımcılara aktarılan bir referans haline gelmesidir. Aksi halde, harcanan onca emek, birkaç ay içinde sıfırlanır.

Standardizasyon ve dokümantasyon, aynı zamanda ERP projesi açısından da kritik bir işlev görür. Bir süreç, sisteme girilmeden önce standartlaştırılmamışsa, ERP projesi sırasında her kullanıcı kendi alışkanlığını “doğru yöntem” olarak savunmaya başlar ve bu, ilk makalede ele aldığımız özelleştirme sarmalını doğrudan besler. Standardizasyon, ERP’ye girilecek mantığın tek ve tutarlı olmasını güvence altına alan son adımdır.

Buraya kadar, bir süreci nasıl seçeceğinizi, sınırlarını nasıl çizeceğinizi, sahiplik ve rolleri nasıl netleştireceğinizi, haritanın dört bileşenini nasıl doğru kuracağınızı, ortak bir görsel dili nasıl kullanacağınızı, mevcut durumu nasıl gerçekçi haritalayacağınızı, darboğaz ve israfı nasıl tespit edeceğinizi, hedef duruma nasıl geçeceğinizi ve bu çalışmayı nasıl kalıcı hale getireceğinizi gördük. Bu uzun yolculukta, tekrarlayan bazı hatalar var; bunları tek bir yerde toplamak, kendi çalışmanızda aynı tuzaklara düşmemenizi kolaylaştıracaktır.

Bölüm 10: Sık Yapılan Hatalar: Özet ve Sentez

Bu makale boyunca, her bölümde bir hataya işaret ettik. Bu hataların ortak bir özelliği var: hiçbiri teknik bir yetersizlikten kaynaklanmıyor. Hiçbiri “yanlış yazılım seçildi” ya da “yanlış sembol kullanıldı” türünden değil. Hepsi, disiplin ve sabır eksikliğinden doğuyor; çalışmanın en zor, en can sıkıcı kısımlarını atlayıp doğrudan sonuca varma isteğinden.

Bu hataları tek bir tabloda toplamak, kendi çalışmanıza başlamadan önce hızlı bir öz kontrol imkânı sunar.

Hata	Nerede Görülür	Gerçek Sonuç
Belgelendirme amaçlı, gerçekliği yansıtmayan harita çizmek	Süreç seçimi ve genel yaklaşım	Harita “olması gereken”i gösterir, ERP’ye aktarılınca gerçeklikle çatışır
Süreç sınırlarını netleştirmeden detaya girmek	Çalışmanın başlangıcı	Çalışmanın ortasında sınır tartışması yeniden açılır
Süreç sahibini belirlemeden ilerlemek	Sahiplik ve roller	Sürecin bütününden kimse sorumlu olmaz
Karar noktalarını belirsiz bırakmak	Haritanın anatomisi	Sistem, kişiye bağlı kararı otomatikleştiremez
BPMN’yi tam teknik standardıyla öğretmeye çalışmak	Ortak görsel dil	Çalıştay, notasyon öğrenmeye kayar
İstisna durumlarını atlamak	As-Is haritalama	En riskli anlar haritada hiç görünmez
To-Be tasarımını sadece hızlandırma olarak görmek	Hedef durum tasarımı	Yapısal iyileştirme fırsatları kaçırılır
Ortaya çıkan haritayı dokümante etmemek	Standardizasyon	Birkaç ay içinde eski alışkanlıklar geri döner

DİKKAT EDİLMESİ GEREKENLER Bu tablodaki hataların hiçbiri tek başına bir projeyi bitirmez; asıl risk, birkaçının bir arada yaşanmasıdır. Sınırı belirsiz, sahibi olmayan, istisnaları atlanmış bir harita, ERP projesine girdiğinde, bu makalenin ele aldığı sorunların hepsini aynı anda tetikler. İyi haber şudur: her biri, tek bir doğru soruyla önlenebilir; bu makale boyunca o soruları tek tek gösterdik.

Sonuç: Bir Harita, Bir Varış Noktası Değil, Bir Başlangıç Noktasıdır

Bu makalenin başında sorduğumuz soru şuydu: süreç haritalamaya nereden başlanır ve profesyonel olarak nasıl yapılır? Cevap, tek bir teknikte değil, doğru sırayla atılan adımların bütününde saklıydı: doğru süreci seçmek, sınırlarını netleştirmek, sahiplik ve rolleri belirlemek, aktivite ve karar noktalarını doğru ayırt etmek, ortak bir görsel dil kullanmak, mevcut durumu olduğu gibi çizmek, darboğaz ve israfı tespit etmek, hedef durumu yeniden tasarlamak, ve son olarak bu çalışmayı kalıcı bir standarda dönüştürmek.

Bu adımların hepsini tamamlayan bir işletme, elinde artık sadece bir çizim değil, ERP’ye doğrudan aktarılabilir, ekibin ortak dilini yansıtan, gerçekliğe dayanan bir karar mimarisi bulundurur. İlk makalede sorduğumuz soruya, şimdi somut bir cevap verebiliriz: evet, süreçlerinizi bir sisteme anlatabilecek kadar tanıyabilirsiniz, çünkü bu tanımanın yöntemi artık elinizde.

Ama burada durmak, yolun yarısında bırakmak olur. Bir harita, ne kadar özenle çizilmiş olursa olsun, statik bir belgedir; oysa işletmeniz statik değildir. Yeni bir ürün, yeni bir müşteri talebi, yeni bir ekip üyesi, mevcut bir tedarikçinin değişmesi: bunların her biri, dikkatle çizdiğiniz haritayı yavaş yavaş gerçeklikten uzaklaştırır. Bugün doğru olan bir harita, on sekiz ay sonra sessizce yanlış hale gelebilir; ve çoğu işletme bunu, harita tekrar ihtiyaç duyulana kadar fark etmez.Bu nedenle, asıl soru şudur: bir süreç haritası çizdikten sonra, bu harita zamanla yeniden bozulmayacak mı? Bir işletme, sürecini bir kez doğru haritaladıktan sonra, onu nasıl canlı, doğru ve değerli tutar? Serinin bir sonraki makalesinde, tam olarak bu soruyu ele alıyoruz: süreç haritası çizmek yetmez; asıl amaç, sürekli iyileştirmedir.

---

Kontrol Listeleri

1. Süreç Haritalama Başlamadan Önce

• Haritalanacak süreç, etki ve karmaşıklık dengesine göre seçildi mi?
• Sürecin başlangıç ve bitiş noktası tek bir cümleyle yazılı hale getirildi mi?
• Süreç sahibi belirlendi ve ilgili departmanlara resmen duyuruldu mu?
• Çalışmanın birincil amacı (ortak dil mi, ERP hazırlığı mı, iyileştirme mi) net biçimde tanımlandı mı?
• Katılımcı listesi, sürecin farklı rollerini (sadece yöneticileri değil) kapsıyor mu?

2. Süreç Çalıştayı Hazırlık Listesi

• Post-it, kalem ve pano gibi basit malzemeler temin edildi mi?
• Çalıştay süresi, katılımcı sayısına göre gerçekçi biçimde planlandı mı?
• Çalıştay sırasında düzenli fotoğraf çekimiyle ilerlemenin kayıt altına alınması planlandı mı?
• SIPOC çerçevesi, sınır tartışmalarını çözmek için hazır bulunduruldu mu?
• Katılımcılara, “olması gereken” değil “gerçekte olan”ı anlatmaları gerektiği baştan hatırlatıldı mı?

3. ERP Öncesi Hazırlık Kontrol Listesi

• Sürecin As-Is haritası, sahada doğrudan gözlemle doğrulandı mı?
• Tüm karar noktalarındaki kurallar, “kim, hangi kritere göre” netliğinde yazılı hale getirildi mi?
• İstisna senaryoları haritadan çıkarılmadan, ayrı dallar olarak belgelendi mi?
• To-Be tasarımı, ERP tedarikçisi seçilmeden önce tamamlandı mı?
• Sürecin nihai hali dokümante edilip, erişilebilir bir kaynağa yerleştirildi mi?
• Süreç sahibi, bu dokümanı düzenli gözden geçirme sorumluluğunu üstlendi mi?