Süreçlerinizin envanterini çıkarır, gerçek hâllerini BPMN 2.0 ile haritalar, her birine bir sahip ve bir ölçü tanımlarız. Ardından bir süreç motoru (BPMS) üzerinde işletir; çevrim süresini, bekleme noktalarını ve darboğazı ölçeriz. Tek bir akış yeterliyse bunu da açıkça söyleriz.
Bir firmada teklif verilir, sipariş açılır, üretim planlanır, sevkiyat yapılır ve tahsilat beklenir. Bu zincirin her halkasını bir birim yürütür ve her birim kendi işini genellikle iyi bilir. Kimsenin bilmediği şey, halkaların arasında geçen zamandır. Teklifin onayda kaç gün beklediği, siparişin üretime düşmesiyle planlanması arasında neyin olduğu, sevkiyatın neden bir hafta kaydığı hiçbir yerde tutulmaz. Ortalama kaç günde teslim ettiğiniz sorulduğunda verilen cevap ölçüme değil hafızaya dayanır ve her birim farklı bir sayı söyler. Sorun çoğu zaman birimlerin performansında değil aralarındaki boşluktadır; ama o boşluğun bir sahibi yoktur. Ölçülmeyen bu boşluk, çoğu firmada en pahalı gecikmenin de kaynağıdır.
Bu firmalarda süreçler aslında yazılıdır. ISO 9001 kapsamında hazırlanmış prosedürler, akış şemaları ve talimatlar bir klasörde durur. Ne var ki yazılı süreç ile fiilen yürüyen süreç zamanla ayrışır: birinde üç onay vardır, sahada ikisi atlanır; birinde iş A biriminden başlar, gerçekte B birimi başlatır. Denetim geldiğinde kâğıt üzerindeki hâl savunulur, ertesi gün eski düzene dönülür. Dijitalleşme çabası da bunu tek başına düzeltmez: tek tek onay akışları kurulur, her biri kendi başına çalışır, aralarında ortak bir kural ve ortak bir ölçü yoktur. Akış sayısı arttıkça birbiriyle çelişen kurallar birikir ve kimse bütünü göremez.
İş süreçleri yönetimi (BPM) önce bir yönetim disiplinidir: hangi süreçlerin var olduğunu envanterlemek, her birine bir sahip atamak, süreci ölçmek ve düzenli aralıklarla iyileştirmek. BPMS ise bu disiplini yürüten yazılımdır, kısaca süreç motoru da denir. Motor, BPMN 2.0 standardıyla modellenmiş bir süreci alır ve gerçekten çalıştırır: görevi doğru role düşürür, süresi geçtiğinde üste yükseltir, karar noktalarında tanımlı kuralı uygular ve her adımın ne kadar sürdüğünü kaydeder. Aradaki fark önemlidir. BPM disiplini olmadan kurulan bir BPMS pahalı bir form uygulamasına dönüşür; yazılım süreci kendiliğinden iyileştirmez, iyileştirmeyi ölçülebilir ve tekrarlanabilir kılar. Ölçüm olmadan yapılan iyileştirme ise bir iddia olarak kalır.
Bu yüzden sınırı baştan çizeriz. İş akışı otomasyonu tek bir akışı yürütür: talep gelir, kurala göre ilerler, onaylanır ve kaydedilir. BPM ise akışların bütününü konu alır; hangi süreçlerin var olduğunu, birbirini nerede beklettiğini ve toplam çevrim süresinin nerede kaybedildiğini görünür kılar. Firmanızda otomatikleştirilmesi gereken birkaç akış varsa doğru cevap iş akışı otomasyonudur ve size BPMS önermeyiz; o ölçekte süreç motoru kurmak gereksiz bir ağırlık olur. BPM'e sıra, süreçler birimler ve sistemler arasında koşmaya başladığında gelir. Bir de şunu söylemek zorundayız: süreç sahipliği atanmadan kurulan hiçbir motorun yaşadığını görmedik. Bu yüzden ilk sorumuz teknik değil yönetseldir.
Satış, planlama, üretim, kalite, sevkiyat ve finansın ayrı ayrı iyi çalıştığı ama aralarındaki devirlerin kayıt altında olmadığı orta ve büyük ölçekli firmalar. Buralarda asıl kayıp birimlerin içinde değil devir noktalarında oluşur; süreç ölçümünün ilk gösterdiği şey de genellikle budur. Devir noktalarının kayıt altına alınması, iyileştirmenin başlangıç noktasıdır.
ISO 9001 veya müşteri denetimleri için hazırlanmış prosedürleri olan, ancak yazılı süreçle sahadaki uygulaması ayrışmış işletmeler. Süreç motora taşındığında prosedür bir belge olmaktan çıkıp fiilen çalışan akışın kendisi olur, denetim kaydı da kendiliğinden birikir. Kalite sisteminin ayrı bir iş olmaktan çıkması en somut kazançtır.
ERP, CRM, üretim takip sistemi ve birkaç ayrı panelin bir arada kullanıldığı işletmeler. Süreç tek bir sistemin içinde bitmiyorsa o sistemin kendi onay akışı da süreci baştan sona göremez. Süreç motoru bu sistemlerin üzerinde durur, görevleri sıraya koyar ve verilerini kaynak sistemlerde bırakır.
İşin uzun süre kişilere bağlı yürüdüğü, yeni gelenlerin süreci ancak birine sorarak öğrendiği firmalar. Kurucudan profesyonel yönetime geçiş ya da hızlı işe alım dönemlerinde bu bilgi eksikliği pahalıya mal olur. Süreçlerin hem yazılı hem işler hâlde olması, devri kişiden kuruma taşır.
| Yetenek | Ne sağlar |
|---|---|
| Süreç envanteri ve önceliklendirme | Firmadaki süreçlerin listesi çıkarılır: adı, başlangıç ve bitiş noktası, hangi birimlerden ve sistemlerden geçtiği, yaklaşık hacmi ve bilinen şikâyetleri. Ardından hepsi değil, en çok acıtan üç beş süreç seçilir. Envanteri çıkarmak tek başına bile değerlidir; çoğu firmada aynı işin iki farklı birimde iki farklı şekilde yürüdüğü ilk kez burada görülür. |
| Gerçek hâliyle haritalama (BPMN 2.0) | Süreç, olması gerektiği gibi değil fiilen yürüdüğü gibi haritalanır; hedef hâli ayrı bir model olarak çizilir. Modelleme için BPMN 2.0 standardını kullanırız: görev, karar noktası, olay ve havuz gösterimi standarttır, bize özgü bir çizim dili öğrenmeniz gerekmez. İki model arasındaki fark, iyileştirme listesinin kendisidir. Haritalama, işi fiilen yapan kişilerle ve onların diliyle yapılır. |
| Süreç motoru (BPMS) kurulumu | Modellenen süreç motorda çalıştırılır: görev doğru role düşer, süresi dolduğunda hatırlatılır ve gerekirse üste yükseltilir, izin ve tatil durumları için vekâlet devri tanımlanır. Kullanıcı BPMN görmez; önüne bir görev listesi ve doldurulacak ekran gelir. Motorun sahiplendiği tek şey sürecin kendisidir, ana veri ERP ve CRM gibi kaynak sistemlerde kalır. |
| İş kurallarının koddan ayrılması | Onay limitleri, sınıflandırma eşikleri ve yönlendirme kuralları koda gömülmez; karar tablolarında (DMN) tutulur. Limit değiştiğinde yeni sürüm yazılmaz, tablo güncellenir ve değişikliği kimin ne zaman yaptığı kaydedilir. Sık değişen kuralları olan firmalarda bu ayrım, sistemin uzun vadeli bakım maliyetini en çok düşüren kararlardan biridir. Kural değişikliklerinin geçmişi de aynı yerde saklanır. |
| Ölçüm: çevrim süresi, bekleme ve darboğaz | Her adımın ne zaman başladığı ve bittiği kaydedildiği için toplam çevrim süresi, adım bazında bekleme süreleri ve işin yığıldığı noktalar ölçülebilir hâle gelir. Ayrıca bir işin kaç kez geri döndüğü ve hangi adımda en çok düzeltme yapıldığı görülür. Tartışma böylece kimin haklı olduğundan çıkıp verinin gösterdiği noktaya taşınır. |
| Mevcut kayıtlardan gerçek akışın çıkarılması | Motor kurulmadan önce de ölçüm mümkündür: ERP ve diğer sistemlerdeki kayıtların zaman damgalarından sürecin fiilen nasıl yürüdüğü çıkarılabilir. Süreç madenciliği denen bu analiz, haritalama toplantılarında kimsenin dile getirmediği kestirme yolları ortaya çıkarır. Kayıtların zaman damgası yetersizse bunu baştan söyler, analizi zorlamayız. Bu çalışma, motor kurulup kurulmayacağına karar vermeden önce tek başına da yaptırılabilir. |
| Sürüm ve değişiklik yönetimi | Süreçler değişir. Yeni sürüm yayınlandığında hâlihazırda çalışan işler eski sürümle tamamlanır, yeni başlayanlar yeni modele girer; böylece yarım kalmış işler bozulmaz. Her sürümün neyi değiştirdiği ve kimin onayladığı kayıt altındadır. Denetimde bu işin hangi kurala göre yürüdüğü sorusuna tarihiyle birlikte cevap verilebilir. Model dosyaları sizde durur, bir aracın formatına hapsolmaz. |
Birim yöneticileriyle ve işi fiilen yapan kişilerle görüşerek süreçlerin listesini çıkarırız: nerede başlıyor, nerede bitiyor, hangi sistemlerden geçiyor. Ardından kapsam daraltılır ve ilk turda en çok acıtan üç beş süreç seçilir. Envanter aşaması firmanın büyüklüğüne göre genellikle 2-4 hafta sürer.
Seçilen süreçler fiilen yürüdüğü hâliyle BPMN 2.0 ile çizilir ve mümkünse sistem kayıtlarından doğrulanır. Aynı çalışmada neyin ölçüleceği kararlaştırılır: çevrim süresi, bekleme, geri dönüş oranı. Ölçüsü tanımlanmamış bir sürecin iyileştiğini kimse kanıtlayamaz. Haritanın doğruluğu işi fiilen yapan kişilerin onayıyla teyit edilir; yönetimin anlattığı akışla sahadaki akış çoğu zaman aynı değildir.
Her sürece bir sahip atanır; sahibi olmayan süreci yazılıma almayız. Sahip, sürecin ölçüsünden ve değişiklik kararlarından sorumludur. Bu adım teknik değil yönetsel bir karardır ve firma içinde verilir. Bizim işimiz çerçeveyi kurmak ve karar gerektiren noktaları önünüze koymaktır. Sahiplik tablosu yazılı olarak paylaşılır ve proje boyunca güncel tutulur.
Süreç motoru kurulur, seçilen ilk süreç uçtan uca çalıştırılır ve mevcut sistemlere bağlanır. Pilot dar tutulur: tek süreç, sınırlı kullanıcı. İlk sürecin canlıya alınması için tipik süre 6-10 haftadır; bağlanacak sistem sayısı ve onay zincirinin karmaşıklığı bu süreyi belirler. Pilot boyunca eski yöntem bir süre yedek olarak açık kalır.
Süreç panoları açılır; ilk gerçek veriler süreç sahibiyle birlikte okunur ve ilk iyileştirmeler yapılır. Modelin nasıl güncelleneceği, kuralın nasıl değiştirileceği ve yeni sürümün nasıl yayınlanacağı ekibe yazılı olarak devredilir. Sonraki süreçler aynı çerçeveyle sırayla eklenir. Devirden sonra da isterseniz belirli aralıklarla süreç gözden geçirme toplantılarına katılırız.
İş akışı otomasyonu tek bir akışı yürütür: talep gelir, kurala göre ilerler, onaylanır ve kaydedilir. BPM ise akışların bütününü konu alır. Hangi süreçlerin var olduğunu, birbirini nerede beklettiğini, toplam çevrim süresinin nerede kaybedildiğini ve her sürecin sahibinin kim olduğunu yönetir. Pratikte iş akışı otomasyonu BPM'in içindeki yürütme katmanıdır. Otomatikleştirilecek birkaç akışınız varsa doğru başlangıç iş akışı otomasyonudur; süreçler birimler ve sistemler arasında koşuyorsa BPM katmanı anlam kazanır.
Süreciniz baştan sona o ERP'nin içinde geçiyorsa çoğu zaman gerek yoktur ve bunu size söyleriz. ERP'nin onay akışı kendi verisi üzerinde iyi çalışır. Sorun, sürecin ERP dışına çıktığı yerde başlar: müşteri e-postası, kalite kaydı, tedarikçi belgesi, saha onayı, imzalanmış bir form. Bu adımlar ERP'nin göremediği yerlerde geçtiği için toplam süre de ölçülemez. Süreç motoru bu boşluğu kapatmak için kurulur, ERP'nin yerine geçmek için değil.
Hayır. Süreç sahipliği devredilebilecek bir şey değildir; hangi onayın kalacağı, hangi adımın kaldırılacağı ve limitlerin ne olacağı sizin yönetim kararınızdır. Bizim işimiz mevcut hâli doğru çıkarmak, çelişkileri ve ölçülemeyen noktaları göstermek, alternatifleri sonuçlarıyla birlikte ortaya koymaktır. Süreç sahibi atanmamış bir projeye başlamıyoruz; çünkü sahibi olmayan süreçte yazılım kısa sürede terk ediliyor. Bu bir tercihten çok, gördüğümüz sonuçtan geliyor.
Günlük kullanıcı için hayır. Kullanıcının önüne yalnızca görev listesi ve doldurulacak ekran gelir, arkadaki model görünmez. Süreç sahiplerinin ise modeli okuyabilmesi işe yarar, çünkü değişiklik tartışmaları model üzerinden yürür. BPMN 2.0'ın okumak için gereken kısmı kısa bir eğitimle aktarılabilir ve bunu devir kapsamında yaparız. Modelleme yetkinliğini tamamen içeride tutmak isterseniz aynı çerçeveyi ekibinize de öğretiriz.
Hayır. Süreçler sürümlenir: yeni sürüm yayınlandığında devam eden işler eski sürümle tamamlanır, yeni başlayanlar yeni modele girer. Onay limiti veya yönlendirme kuralı gibi sık değişen kısımlar zaten koddan ayrı karar tablolarında tutulur; bunları geliştirme yaptırmadan güncelleyebilirsiniz. Akışın kendisinin değişmesi geliştirme gerektirir, ama bu tüm sistemi değil yalnızca o modeli ilgilendirir.
Süreç envanteri ve sahiplik tablosu; seçilen süreçlerin BPMN 2.0 ile çizilmiş mevcut ve hedef modelleri; kurulmuş bir süreç motoru ve canlıya alınmış ilk süreç; karar tablolarında tutulan iş kuralları; çevrim süresi, bekleme ve darboğaz panoları; sürüm ve değişiklik kaydı. Motoru ileride başka bir ekiple sürdürmek isterseniz devir dokümanı bunun için hazırlanır. Kaynak kod, modeller ve biriken süreç verisi size aittir.
30 dakikalık keşif görüşmesinde ihtiyacınızı dinler, özele mi yoksa hazır çözüme mi ihtiyacınız olduğunu dürüstçe söyleriz.
Raporun altındaki katmanı kurarız: kaynak sistemlerden ETL veya ELT ile veri çekilir; ham, işlenmiş ve sunum katmanlarında modellenir; geçmişiyle birlikte saklanır. Metrik tanımları tek bir veri sözlüğünde sabitlenir, kalite kontrolleri sessiz bozulmaları daha yükleme sırasında yakalar.
Detay →Aynı müşterinin üç kez açıldığı, aynı malzemenin iki kodla durduğu kayıt düzenini onarırız. Eşleştirme kuralları, benzerlik skoru ve inceleme kuyruğuyla mükerrer kayıtlar tekilleştirilir, altın kayıt üretilir ve kaynak sistemlere geri dağıtılır; yeni kayıt açılırken benzer kayıt uyarısı devreye girer.
Detay →Tanı amaçlı görüntüleme yazılımı üretmiyoruz; mevcut PACS'ınız yerinde kalır. Biz cihaz worklist'i, hasta kaydı, istem, rapor ve paylaşım arasındaki boşluğu kapatan katmanı kurarız: görüntü doğru hastaya bağlanır, bekleyen istem görünür olur, arşivin saklama ve yedekleme durumu denetlenebilir hale gelir.
Detay →Başvuru, kayıt, şube yerleştirme, ders programı, yoklama, not, karne, veli iletişimi ve taksit takibini tek kayıt üzerinde birleştiren öğrenci bilgi sistemi kuruyoruz. Kurumun kendi takvimine ve kendi ücret politikasına göre kurgulanır; hazır bir paketin kalıbına girmeniz gerekmez. Kaynak kod ve veri kuruma aittir.
Detay →Numunenin kabul edildiği andan analiz sertifikasına kadar tüm adımları tek kayıt üzerinde yürüten laboratuvar bilgi yönetim sistemi kuruyoruz: barkodlu numune takibi, metot kütüphanesi, cihaz bağlantısı, spesifikasyon kontrolü, kademeli onay ve denetime hazır kayıt düzeni.
Detay →Teklif, proje, zaman kaydı, hakediş ve fatura zincirini tek kayıt üzerinde birleştiririz. Ajans, danışmanlık, mühendislik ve yazılım firmalarında kimin hangi işe ne kadar zaman verdiği, kaynak doluluk oranı ve proje kârlılığı iş bittikten sonra değil, iş sürerken görünür hale gelir.
Detay →
