Zaman kazandıran operasyon ekipleri için iş akışı kalıpları

Operasyon iş akışları neden sürekli yeniden oluşturuluyor

Çoğu operasyon ekibi ortak bir kalıpla başlamaz. Son işe yarayan süreci alır, kopyalar, birkaç etiketi değiştirir ve devam eder. Bir izin talebi ekipman talebine dönüşür. Bir satın alma formu tedarikçi kurulum formuna dönüştürülür. İsimler değişir, ama altında yatan iş genellikle çok benzerdir.

Bu yüzden aynı iş akışı defalarca yeniden oluşturulur. Bir ekip bir adıma "yönetici onayı" der. Başkası buna "inceleme" der. Üçüncüsü bir e-posta uyarısı ekleyip bunu yeni bir süreç gibi ele alır. Kağıt üzerinde bu akışlar farklı görünür. Pratikte çoğu aynı yolu izler: birisi bir talep gönderir, birisi kontrol eder, birisi onaylar ve birileri bilgilendirilir.

Daha büyük sorun, gerçek kuralların genellikle yazılı olmamasıdır. Bu kurallar sohbet dizilerinde, eski e-postalarda, tablo notlarında veya deneyimli bir kişinin kafasında yaşar. Bir kişi bunu bir araca dönüştürmeye çalıştığında, eksikleri hafızasından doldurur. Sonuç bazı durumlarda işe yarar, bazı durumlarda bozulur.

Küçük farklılıklar ekiplerin beklediğinden daha büyük gecikmelere yol açar. Bir alan bir formda isteğe bağlı, diğerinde zorunlu olur. Bir ekip onayı beklemeden önce finansı bilgilendirir, diğer ekip sonuna kadar bekler. Bir inceleyici bir talebi düzenleyebileceğini düşünür, ama form kilitlidir. İki kişi görevi kapatmanın diğer kişinin işi olduğunu varsayar. Bunların hiçbiri tek başına ciddi görünmez. Bir araya geldiklerinde yeniden işleme, yavaş devralmalara ve sürekli açıklamaya neden olurlar.

Bu durum, ekipler kodsuz uygulamalarla hızlıca dahili araçlar oluşturduğunda sıkça olur. Hız fayda sağlar, ama ortak bir kalıp olmadan hız genellikle aynı iş akışının beş versiyonunu üretir. Gerçek zaman kazandıran sadece daha hızlı inşa etmek değil, her süreci sıfırdan yeniden tasarlamak yerine aynı net iş akışı bloklarını yeniden kullanmaktır.

Ekipler çoğu talebin aynı birkaç adımdan oluştuğunu gördükçe, her yeni iş akışı artık baştan tasarım problemi gibi görünmez.

Ekiplerin tekrar tekrar kullandığı beş blok

Çoğu operasyon iş akışı beş yapı taşına indirgenebilir: gönderme, inceleme, onaylama, bildirim ve kapatma. Farklı ekipler farklı isimler kullanabilir, ama yapı tanıdıktır. Birisi bir şey ister, birisi kontrol eder, birisi karar verir, ilgili kişiler bilgilendirilir ve görev tamamlanır.

Gönderme talebin başladığı yerdir. Bu adım, ardından gelen her şey için tonu belirler. Eğer giriş formu belirsizse, süreç geri kalanında tahmin yürütme ve takip mesajları olur.

İnceleme son karar değildir. Bu bir kalite kontrolüdür. Bu adım talebin eksiksiz olduğundan, doğru detayların ekli olduğundan ve karar verene ulaşmadan önce hiçbir şeyin eksik olmadığından emin olur.

Onaylama karar noktasıdır. Bir yönetici, ekip lideri veya sahip bütçe, öncelik, politika veya risk temelinde evet, hayır der veya talebi geri gönderir.

Bildirim insanların sohbette veya e-postada güncellemeleri kovalamasını engeller. Talep sahibi, inceleyici, onaylayıcı ve işi yapan ekipler ne değiştiğini ve harekete geçmeleri gerekip gerekmediğini bilmelidir.

Kapatma sürecin tamamlandığını işaretler. Birçok ekip bu adımı atlar. Kapatma işin bitirildiği, durumun kesin olduğu ve kimsenin öğeyi açık görev gibi değerlendirmemesi gerektiği anlamına gelir.

Bu bloklar işe yarar çünkü her birinin net bir görevi vardır. Gönderme talebi toplar. İnceleme kaliteyi kontrol eder. Onaylama kararı verir. Bildirim sonucu paylaşır. Kapatma süreci tamamlanmış olarak işaretler.

Ekipler bu işleri ayrı tuttuğunda, erişim taleplerinden tedarikçi kabulüne kadar birçok akışta yeniden kullanabilirler. AppMaster gibi bir kodsuz platformda bu genellikle aynı form mantığını, durum kurallarını ve bildirimleri yeniden kullanmak anlamına gelir; her seferinde sıfırdan yeniden kurmak yerine.

Gönderme ile başlayın ve talebi net yakalayın

Gönderme adımı sonraki her şeyi şekillendirir. İlk talep dağınık olursa, her inceleme, onay ve güncelleme daha uzun sürer.

Kimin talep oluşturabileceğine karar vererek başlayın. Bazen bu herkes olur. Bazen sadece ekip liderleri, koordinatörler veya onaylı tedarikçiler olmalıdır. Bu karar izinleri, form tasarımını ve formun ne kadar rehberlik gerektirdiğini etkiler.

Formu kısa tutun. İnsanlar formu açıp çabucak anlayıp tahmin yürütmeden bitirebilmelidir. Bir alan daha sonra birinin incelemesine, onaylamasına, yerine getirmesine veya raporlamasına yardımcı olmuyorsa muhtemelen orada olmamalıdır.

Çoğu talep formu sadece birkaç temel bilgi ister:

• ne isteniyor
• neden gerekli
• ne zaman gerekli
• kim istiyor
• gerekli dosya veya notlar

Bunlar genellikle işi ilerletmek için yeterlidir. Uzun formlar genellikle daha iyi veri değil, daha kötü veri üretir çünkü insanlar acele eder, ayrıntıları atlar veya formu bitirmek için rastgele seçenekler seçer.

Gönderim sonrası açıklık da önemlidir. Talep sahibinin ne olacağını bilmesi gerekir. Basit bir onay, talebin kim tarafından inceleneceğini, hangi durumla başlayacağını ve ne zaman güncelleme bekleyeceklerini açıklayarak çok fazla karışıklığı önleyebilir.

Yeniden kullanım burada da yardımcı olur. Birçok ekip aynı talebin küçük varyasyonları için ayrı formlar oluşturur ve sonra tümünü bakım için harcar. Birçok durumda tek, paylaşılan bir form ve içinde bir talep türü alanı daha iyi işler. Ofis malzemesi talepleri, yazılım erişim talepleri ve küçük ekipman talepleri aynı başlangıç kalıbını takip edebilir.

Bunu kodsuz bir uygulamada inşa ediyorsanız amaç daha fazla veri toplamak değil, bir sonraki kişinin hızlı ve güvenle hareket etmesi için gereken az bilgiyi toplamaktır.

İnceleme ve onay aynı adım olmamalı

Birçok ekip inceleme ve onayı tek bir işlem gibi ele alır. Bu daha basit gibi görünse de genellikle kafa karışıklığı yaratır. Bir kişi talebin eksiksiz olup olmadığını kontrol eder. Başka biri ekibin devam edip etmeyeceğine karar verir.

İnceleme kalite ve eksiksizliği kontrol eder. Onay net bir evet veya hayır kararıdır.

Bu adımlar ayrıldığında sorumluluk daha net olur. İnceleyen kişi detayları kontrol eder, eksik bilgileri işaretler ve hazır değilse talebi geri gönderir. Onaylayan kişi bütçe, risk, zamanlama veya politika göz önünde bulundurarak devam edip edilmeyeceğine karar verir.

Bir inceleme adımı şu soruları yanıtlamalıdır:

• Tüm gerekli bilgiler dolduruldu mu?
• Tarihler, rakamlar ve ekler doğru mu?
• Talep temel sürece uyuyor mu?

Bir onay adımı farklı bir soruyu yanıtlamalıdır: bu talebi kabul ediyor muyuz?

Bu ayrım kararları temiz tutar. Bir finans inceleyicisi satın alma talebinin doğru teklif içerdiğini doğrulayabilir. Bölüm yöneticisi sonra harcamanın uygun olup olmadığını onaylar veya reddeder. Aynı kişi hem ikisini yaparsa, kurallar net değilse talepler sıkışır veya dolaşır.

Ayrıca önceden kimin düzenleme için geri gönderme yapabileceğine karar vermek faydalıdır. Birçok ekipte inceleyen kişi düzeltmeler için talebi geri gönderebilirken onaylayan kişi yalnızca onaylayabilir veya reddedebilir. Bu, kıdemli onaylayanların detayları düzenleyip karar vermek yerine işi uzatmasının önüne geçer.

Reddetme ve yeniden çalışma kurallarını basit tutun. Bir talep düzeltilebiliyorsa "düzeltme gerekiyor" olarak işaretleyin ve kısa bir notla geri gönderin. Eğer devam etmemesi gerekiyorsa "reddedildi" olarak işaretleyin. Bu sonuçlar karıştırılmamalıdır.

Her zaman bir talebin neden onaylandığını veya reddedildiğini kaydedin. Kısa bir neden talep sahibinin sonraki başvuruyu iyileştirmesine yardımcı olur ve ekibe net bir geçmiş sağlar. Reddetme üzerine zorunlu bir açıklama alanı bile birçok yineleyen soruyu engelleyebilir.

Bildirim ve kapatma gevşek uçlar olmadan

Bir iş akışı doğru kişiler ne değiştiğini bilmediğinde ve kayıt tam olmadığında gerçekten bitmiş hissetmez. Pek çok ekip burada zaman kaybeder. Çok fazla uyarı gönderir, son adımı belirsiz bırakır ve sonra işin gerçekten yapılıp yapılmadığını anlamak için ekstra mesajlara ihtiyaç duyar.

Bildirimler anlamlı bir şey değiştiğinde olmalı, her tıklamada değil. Yeni bir talep, bir karar, engelleyen bir durum veya tamamlanmış bir öğe genellikle uyarı gerektirir. Küçük iç güncellemeler genellikle gerekmez. Her adım bir mesaj tetikliyorsa insanlar dikkat etmeyi bırakır ve önemli olan uyarı kaçırılır.

Biri bilgilendirildiğinde mesaj spesifik olmalıdır. Üç soruyu hemen cevaplamalı: ne değişti, kim ne yapmalı ve ne zamana kadar? "Satın alma talebi onaylandı. Finansın Cuma'ya kadar siparişi vermesi gerekiyor" "Talep güncellendi" mesajından çok daha faydalıdır.

Kapatma da aynı şekilde net olmalıdır. Son bir kayıt bırakmalı: son eylemin sahibi, kapatma tarihi, onaylandı/reddedildi/tamamlandı/iptal edildi gibi son durum ve istisnalar veya takipler varsa kısa bir not.

Bu son kaydı tek bir yerde tutun. Karar e-postadaysa, tarih sohbette ve durum bir tabloda ise süreç gerçekten kapanmış sayılmaz. Sonraki kişi ne olduğunu yine sormak zorunda kalır.

Basit bir satın alma talebi bunun neden önemli olduğunu gösterir. Onaylandıktan sonra talep sahibine net bir güncelleme gitmelidir. Ürün sipariş edildikten sonra ise iş satın alıcının adı, sipariş tarihi ve nihai durum ile kapatılmalıdır. Böylece kimse gelecek hafta "Bu halledildi mi?" diye ayrı bir mesaj göndermek zorunda kalmaz.

Bunu dahili bir uygulamaya koyuyorsanız, kapatma adımını isteğe bağlı yerine zorunlu yapın. Bu küçük kural gevşek uçları azaltır ve şaşırtıcı miktarda takip işini önler.

Bir süreci tekrar kullanılabilir bir kalıba dönüştürme

Sık yaptığınız bir süreçle başlayın. Sıradışı değil, yaygın bir şey seçin. Tekrarlanan işler bir kalıbın nerede en çok zaman kazandıracağını gösterir.

Mevcut süreci insanların bugün yaptığı şekilde sade bir dille yazın. Basit tutun. "Çalışan talep gönderir, yönetici detayları kontrol eder, finans onaylar, talep sahibi güncellenir, vaka kapatılır" gibi bir ifade bu aşamada cilalı bir diyagramdan daha faydalıdır.

Sonra her adımı beş bloktan birine gruplandırın: gönderme, inceleme, onaylama, bildirim veya kapatma. İşte süreç yeniden kullanılabilir hale geldi. Her iş akışını birer örnek gibi ele almak yerine altında aynı yapıyı görmeye başlarsınız.

Her adımı test etmenin iyi bir yolu birkaç temel soruyu sormaktır: Bunu kim başlatıyor? Sonra kimin sorumluluğunda? Burada hangi karar veya eylem oluyor? Adım bittiğinde ne sonuç olmalı? Kim bundan sonra bilgilendirilmeli?

Bu sorular her bloğun sahibi ve beklenen sonucunu tanımlar. Bir adımın sahibi yoksa genellikle durur. Bir adımın net sonucu yoksa insanlar bunun bitip bitmediğini sormaya devam eder.

Örneğin bir inceleme adımı sadece "birisi bakar" demek olmamalıdır. "Ekip lideri gerekli tüm detayların mevcut olduğunu kontrol eder" anlamına gelebilir. Bir onay adımı "bölüm yöneticisi evet veya hayır der" olabilir. Bir kapatma adımı "talep tamamlandı olarak işaretlenir ve raporlama için saklanır" anlamına gelebilir. Net etiketler kalıbın yeniden kullanılmasını kolaylaştırır.

Genel kullanıma sunmadan önce kalıbı yakın zamanda yapılmış bir taleple test edin. Uydurma bir vaka değil, gerçek bir talep kullanın. Gerçek talepler eksik alanları, belirsiz devralmaları ve çok geç gelen bildirimleri ortaya çıkarır.

Test işe yararsa aynı yapıyı benzer iş akışlarında yeniden kullanın. Seyahat talebi, satın alma talebi ve yazılım erişim talebi farklı formlar gerektirse de genellikle aynı blokları paylaşır.

Bu noktada AppMaster gibi platformlar pratik olarak yardımcı olabilir. Yapı zaten netse, bu blokları veri modellerine, iş mantığına, durumlara ve bildirimlere eşleyebilirsiniz; böylece her seferinde akışı baştan kurmak zorunda kalmazsınız.

Örnek: basit bir satın alma talebi akışı

Yazılım satın alma talebi iyi bir örnektir çünkü anlaşılması kolaydır ve yine de ekiplerin her gün kullandığı aynı blokları içerir: gönderme, inceleme, onaylama, bildirim ve kapatma.

Bir çalışan yeni bir tasarım aracı veya raporlama uygulaması ister. Araç adı, iş gerekçesi, beklenen maliyet ve bilirlerse bütçe kodu ile bir talep gönderir. Güçlü talepler ayrıca kimin erişmesi gerektiğini ve ne kadar acil olduğunu içerir.

Operasyon hemen aracı onaylamaz. Önce birisi talebi inceler ve ihtiyacın net olup olmadığını, bütçe detaylarının doğru olup olmadığını kontrol eder. Bir şey eksikse talep açıklama için geri gider; zayıf durumda ilerlemez.

Akışın temiz bir versiyonu şöyle olabilir:

• yeni talep gönderildi
• operasyon incelemesi tamamlandı
• yönetici onayladı veya reddetti
• BT bilgilendirildi ve erişim atandı
• doğrulamadan sonra talep kapatıldı

Yönetici adımı basit kalmalıdır. Yönetici detayları yeniden girmek veya eksik bilgi peşinde koşmak için orada değildir. Rol, ekip ve bütçe için satın almanın mantıklı olup olmadığına karar verir ve reddederse kısa bir neden bırakır.

Onaylandıktan sonra BT gerekli detayları alır: çalışan adı, yazılım adı, lisans tipi ve son tarih gibi. BT sonra lisansı satın alır veya atar ve talebi onaylama için hazır olarak işaretler.

Talep BT "tamamlandı" diyince hemen kapanmamalıdır. Çalışanın oturum açıp kullanabildiğini onaylamadan kapanmamalıdır. Bu son kontrol, sık görülen bir sorunu önler: kağıt üzerinde bilet bitmiş görünür ama kişi hala erişemiyordur.

Kodsuz bir uygulamada bu akış bir form, birkaç durum kuralı ve ekipler arası otomatik mesajlarla inşa edilebilir. Yazılım adı, onaylayan veya bütçe sahibi değişebilir, ama kalıp aynı kalır.

Ekipi yavaşlatan yaygın hatalar

Küçük iş akışı sorunları ilk başta ciddi görünmez. Bir talep yine ilerler, bir e-posta yine gider ve birisi yine onaylar. Ama bir veya iki hafta sonra bu küçük boşluklar gecikmelere, yeniden işe ve karışıklığa dönüşür.

Yaygın hatalardan biri düşük riskli işler için çok fazla onay eklemektir. Küçük bir ofis malzemesi talebi büyük bir tedarik sözleşmesiyle aynı zinciri gerektiriyorsa insanlar sürece güvenmeyi bırakır. Ya çok uzun beklerler ya da süreçten kaçarak işi hallederler.

Bir diğer hata inceleme ve onayı karıştırmaktır. İnceleyen talebin eksiksiz veya mantıklı olup olmadığını kontrol eder. Onaylayan karar verir. Aynı kişi yanlışlıkla ikisini yaparsa, talebin düzgünce kontrol edilip edilmediğini veya sadece geçişten geçirilip geçirilmediğini anlamak zorlaşır.

Bildirimler gürültü yaratabilir. Her güncelleme herkese giderse çoğu insan dikkat etmeyi bırakır. Önemli olan bir mesaj o zaman kaçırılır.

Belirsiz durum adları da sorun yaratır. "Devam ediyor", "Beklemede" ve "İncelemede" gibi etiketler sıklıkla örtüşür. Farklı kişiler onları farklı okur. Temiz bir süreç, işin nerede olduğunu ve sırada ne olması gerektiğini açıkça gösteren durumlar kullanır.

Erken belirti veren birkaç işaret şunlardır:

• basit talepler karmaşık kadar uzun sürer
• personel sonraki adımın sahibini sık sık sorar
• durum belirsiz olduğu için insanlar sohbette takip eder
• kapatılmış öğeler hâlâ birinin yapılacaklar listesinde durur
• raporlar ekibin sandığıyla uyuşmaz

Son büyük hata "kapatıldı"yı son adım saymak ama hâlâ manuel temizlik gerektirmesidir. Bir finans talebi kaydedilmeden, talep sahibi bilgilendirilmeden veya ilgili görev arşivlenmeden önce tamamlandı olarak işaretlenebilir. Bu gevşek uçlar bırakır ve raporlamayı güvensiz kılar.

Amaç daha fazla adım eklemek değil. Her adımı net, gerekli ve yeniden kullanılabilir yapmak. Daha hızlı iş akışları genellikle kontrol eklemekten değil, kafa karışıklığını gidermekten gelir.

Bir kalıbı yeniden kullanmadan önce hızlı bir kontrol

Bir iş akışını yeni bir sürece kopyalamadan önce durup temel noktaları kontrol edin.

Sahiplik ile başlayın. Her adım tek bir kişiye veya role ait olmalıdır; belirsiz bir gruba değil. Herkes harekete geçebiliyorsa kimse sorumluluk hissetmez.

Sürecin gerektiğinde geriye hareket edebildiğinden emin olun. Gerçek talepler çoğunlukla eksiktir. Bir inceleyici eksik detay isteyebilir, tutarsız miktarı düzeltebilir veya yeni bir ek talep edebilir. Eğer tek seçenekler onayla veya reddetmekse insanlar sistemi sohbet ve e-posta ile aşmaya başlar.

Veri girişini sıkı tutun. Zorunlu alanlar sadece sonraki adımın gerçekten ihtiyaç duyduğu bilgileri kapsamalıdır. Bir satın alma talebi tedarikçi, miktar ve gerekçe gerektiriyorsa, belki ileride kullanışlı olabileceği için beş ekstra alan zorunlu kılmayın.

Her bildirimi de kontrol edin. Bir bildirimin net bir eylemi tetiklemesi, net bir sonucu onaylaması, takılı kalındığını uyarması veya talebi gönderenin döngüsünü kapatması gerekir. Bunlardan hiçbiri değilse muhtemelen gürültüdür.

Son olarak, durumu bir bakışta anlaşılır kılın. Birisi talebi açtığında ne olduğunu anlamak için tüm geçmişi okumak zorunda kalmamalıdır. Submitted, In Review, Needs Fixes, Approved ve Closed gibi basit durumlar genellikle yeterlidir.

Kalıpları gerçek araçlara dönüştürme

Başlangıç yeri en büyük süreciniz olmamalıdır. Haftada birkaç kez kullandığınız ve iyi bildiğiniz bir kalıp seçin. Bir izin talebi, satın alma talebi, olay devri veya içerik onayı ilk testi için yeterlidir.

İlk sürümü küçük tutun. İnsanlar bir talep gönderebiliyorsa, doğru kişi inceleyebiliyorsa ve herkes net bir sonuç alıyorsa zaten kullanışlı bir şeyiniz var demektir. Bu, ilk günden mükemmel sistemi kurmaktan daha önemlidir.

Pratik bir sonraki adım bu kalıbı küçük bir dahili uygulamaya dönüştürmektir. Masa başı ekipler için web uygulaması, hareket halindeki işlemler için mobil uygulama uygundur.

İlk sürümü üç bölümde oluşturun: yakalamanız gereken verileri tanımlayın. Gönderim sonrası mantığı, inceleme, onay ve geri gönderimleri haritalayın. Ardından bildirimler, durum güncellemeleri ve net bir kapatma durumu gibi devralma adımlarını ekleyin.

Bunu elle yazmadan yapmak istiyorsanız AppMaster bu konuda bir seçenektir: aynı kurulumdan backend mantığı, web uygulamaları ve mobil uygulamalar oluşturur. Ana avantaj sadece hız değil; kalıp netleştiğinde aynı yapıyı birçok dahili süreçte yeniden kullanabilmektir.

İlk akış canlı olduğunda hemen her şeyi yeniden inşa etmeyin. İnsanların nasıl kullandığını bir veya iki hafta izleyin. Nerede durakladıklarını, neyi atladıklarını ve hangi alanların karışıklık yarattığını gözlemleyin.

Sonra işe yarayanı bir sonraki sürece kopyalayın. Benzer yerlerde aynı gönderme kurallarını, onay mantığını ve bildirim yapısını yeniden kullanın. İşte böylece yeniden kullanılabilir iş akışı blokları, ekip için güvenilir bir işletim sistemi haline gelir—bir süreçte bir adımda.