İş akışı otomasyonunda iş takvimlerinin resmi tatilleri, hafta sonlarını, kesme zamanlarını ve çalışma saatlerini nasıl yönettiğini öğrenin; böylece SLA'lar ve teslim tarihlerinin gerçekçi kalmasını sağlayın.
Bir son tarih kulağa net gelir, ta ki gerçek çalışma saatleri devreye girene kadar. Bir iş akışı "8 saat içinde yanıt ver" ya da "yarına öğlen kadar onayla" diyebilir, ama sabit bir zamanlayıcı her saati aynı sayar. Geceyi, hafta sonlarını, tatilleri ve ofis kapanışlarını insan sanki her an müsaitmiş gibi sayar.
İşte bu yüzden iş takvimi önemlidir. Basit bir zamanlayıcıyı, ekibin gerçekten çalışabileceği zamanla eşleşen bir son tarihe dönüştürür.
Bunun yaygın bir örneği destek talepleridir. Eğer bir talep Cuma 16:30'da gelir ve 4 saatlik bir SLA varsa, basit bir zamanlayıcı aynı gece geç kaldı işareti verebilir. Oysa ekip hafta içi 09:00–18:00 çalışıyorsa, cuma günü sadece 90 çalışma dakikası geçmiş olur. Geri kalan süre Pazartesi'ye devredilmelidir.
Satış ekipleri de günlük kesme saatleriyle aynı sorunu yaşar. Bir lead yönlendirme kesmesinden sonra gelirse, iş akışı onu aynı gün takip kuyruğuna itebilir. Kağıt üzerinde süreç hızlı görünür. Ama gerçekte ekip çevrimdışıdır, dolayısıyla vaat edilen yanıt süresi baştan yanlıştır.
Onay süreçleri de genellikle aynı sebeple kırılır. Bir yöneticinin satın alma talebi resmi tatilden bir gün önce gelirse ve iş akışı ona 24 saat veriyorsa, zamanlayıcı ofis kapalıyken sona erebilir. Sistem talebin geciktiğini söyler, oysa kimsenin adil bir şansı olmamıştır.
Çoğu hatalı son tarih birkaç eksik kuraldan kaynaklanır. İş akışları hafta sonlarını normal iş günü gibi sayar, resmi tatilleri görmezden gelir, yerel ofis çalışma saatlerini atlar veya gün sonu kesme zamanlarını unutur. Bu kurallar eksik olduğunda son tarih hesapları süreç başlamadan önce bozulmuş olur.
Bu da her yerde ekstra iş yaratır. Ekipler gecikmeleri açıklar, biletleri el ile geçirir, son tarihleri elle değiştirir ve otomasyona güvenmeyi bırakır.
Çözüm basittir: son tarihler sadece saatle değil, ofis zamanıyla uyuşmalı. Çalışma günleri, tatiller, ofis saatleri ve kesme zamanları iş akışına dahil edildiğinde, son tarih insanların güvenebileceği bir şeye dönüşür.
Bir iş akışı, takvimi insanların gerçekten nasıl çalıştığını yansıttığında gerçek son tarihler sağlar. Sistem her saati aynı sayıyorsa, kimsenin müsait olmadığı gün ve saatlerde iş vadetmeye devam edecektir.
İlk kural basit ama hayati. Hangi günlerin normal çalışma günü sayıldığını tanımlayın. Birçok ekip için bu Pazartesi–Cuma ve hafta sonlarının hariç tutulması demektir. Ancak her departman için bu doğru değildir. Destek ekibi yedi gün çalışabilirken, finans sadece hafta içi çalışabilir.
Bu adımı atlerseniz, basit bir iki günlük onay bile Pazar gününe denk gelebilir.
Resmi tatiller de en az çalışma günleri kadar önemlidir. Bir ofiste süreci tasarlayan biri bunları kaçırabilirken, aynı süreci birden çok ofis kullanıyorsa sorun olasıdır. Şirket kapanış günleri de önemli—yıllık geri çekilme, envanter günü veya yıl sonu kapanışı gibi.
Tatillerin türlerini ayrı tutmak işleri daha kolay bakım yapılabilir kılar. Resmi tatiller, yerel ofis tatilleri, şirket çapında kapanış günleri ve tek seferlik kapanışlar farklı ekipler için değişiyorsa bir arada karıştırılmamalıdır.
Bir iş günü 24 saatlik bir gün değildir. Yerel ofis saatleri iş akışına çalışmanın gerçekten ne zaman yapılabileceğini söyler. Satış 09:00–18:00 çalışabilir, destek daha uzun kapsama sahip olabilir, finans ise talepleri 17:00'de durdurabilir. Farklı ekiplerin genellikle farklı takvimlere ihtiyacı vardır.
Kesme zamanları aynı gün içi işler için en önemli olanlardır. Bir onay isteği 16:45'te gelmiş ve kesme 16:30 ise, iş akışı bunu bir sonraki iş günü işi olarak işlemelidir. Bu kural yoksa sistem yerine getirilemeyecek son tarihler oluşturur.
Saat dilimleri de yaygın bir boşluktur. New York'ta oluşturulan bir istek Berlin'de onaylanıyorsa tek bir saat dilimiyle gitmemelidir. İş akışının hangi yerel saatin adımı kontrol ettiğini bilmesi gerekir. Çoğu durumda bu, isteği veren kişi değil, görevin sorumluluğunu alan takımın yerel saati olmalıdır.
Bu kurallar netleştiğinde SLA takibi daha doğru olur ve güveni artırır.
Yazılımla değil insanlarla başlayın. Bir takvim kuralı yalnızca her bir takımın günlük çalışma şekliyle uyuşuyorsa işe yarar.
Destek hafta sonları çalışabilir. Finans sadece Pazartesi–Cuma çalışabilir. Hukuk 16:00'dan sonra incelemeyi durdurabilir. Tüm bunlar tek bir takvim paylaşıyorsa son tarihler baştan yanlış olur.
İşi etkileyen zamanlama farklılıklarını not ederek iş akışına dokunan her grubu listeleyin. Kenar durumlar yerine gerçek farklılıklara odaklanın. Genellikle bu; çalışma günleri, saat dilimleri, bazı günlerde daha kısa çalışma saatleri, yerel tatiller ve herhangi bir kesme zamanını içerir.
Daha sonra her bir program modeli için bir takvim oluşturun. Genellikle her kişi için ayrı bir takvim gerekmez.
Her takvim için çalışma saatlerini tanımlayın. Başlangıç ve bitiş saatlerini ekleyin ve son tarihlerin nasıl sayılacağını etkileyen planlı kapanışları dahil edin.
Ardından resmi tatilleri, şirket kapanışlarını ve ofise özel kapanışları ekleyin. Birçok son tarih hatası buradan başlar. Bir iş akışı bir tatili göz ardı ederse, hiçbir kimsenin müsait olmadığı bir günde aynı gün içinde iş vaat edebilir.
Platformunuz iş takvimlerini doğrudan destekliyorsa, doğru plan mantığını yalnızca forma veya süreci başlatan isteğe değil, iş akışı adımına da ekleyin.
Kesme zamanları, gerçekçi olmayan geç gün son tarihlerine karşı iş akışını korur. Finans bir iş için bir iş günü vaat ediyorsa, 16:55'te gelen bir istek 10:00'de gelen bir istek gibi sayılmamalıdır.
Pratik bir kural basittir: kesme saatinden sonra saat sayımı bir sonraki iş döneminde başlar.
Canlıya almadan önce örnek vakaları iş akışından geçirin. Normal bir hafta içi, bir Cuma öğleden sonra, bir tatil ve bir tatilden önceki günü test edin.
Eğer bir istek Cuma 17:30'da gelmiş ve Pazartesi yerel tatilse, son tarih o ofisin çalışma saatlerine göre Salı'ya kaymalıdır. Bunu yapmıyorsa, takvim lansmandan önce daha fazla çalışmaya ihtiyaç duyar.
Küçük bir test seti şimdi daha sonradan yapılacak çok sayıda elle düzeltmeyi önler.
Takvim kuralları zamanın kararları etkilediği her yerde bulunmalıdır. Eğer sadece son aşamada eklenirse, süreç kağıt üzerinde doğru görünse bile gerçek son tarihlerde hata yapabilir.
İlk yer zamanlayıcının kendisidir. Bir iş akışı, geceyi, hafta sonunu veya tatilleri aktif iş zamanı olarak saymak yerine bu zamanların dışında durmalıdır. Bir onay 16:45'te başlıyorsa ve ofis 17:00'de kapanıyorsa, o gün sadece 15 dakika sayılmalıdır.
Bir sonraki yer görev yönlendirmesidir. İş genellikle farklı takvimlere sahip ekipler arasında hareket eder. Bir bölgede Cuma geçe oluşturulan bir istek, başka bir ekibin kuyruklarına o ekip zaten çevrimdışıyken düşmemelidir.
Bildirimlerin de takvim mantığına ihtiyacı vardır. 02:00'de veya yerel tatilde gönderilen hatırlatmalar kolayca gözden kaçırılır ve karışıklık yaratır. Daha iyi bir kural, mesajı tutup bir sonraki geçerli iş zamanında göndermektir.
Yükseltmeler de aynı şekilde ele alınmalıdır. Bir vaka dört saatlik yanıt hedefi taşıyorsa, bu atanan takvime göre dört çalışma saatidir, dört saatlik gerçek zaman değil.
Ana kontrol noktaları genellikle şunlardır:
Her zaman tabanlı adım için yararlı bir soru basittir: bu, görevin sorumlusu olan kişi veya ekip için iş zamanı mı?
AppMaster gibi görsel araçlarda, bu kuralları onları kullanan süreç adımlarına, zamanlayıcılara ve bildirimlere yakın tutmak yardımcı olur. Takvim mantığı kararın olduğu yerde yaşadığında, son tarihler gerçeğe daha yakın kalır.
Basit bir SLA örneği farkı net gösterir. Diyelim ki bir müşteri destek isteği Cuma 17:30'da gönderildi. Destek ekibi Pazartesi–Cuma 09:00–18:00 çalışıyor ve yeni talepler için 17:00 kesme saati var.
Bu kesme her şeyi değiştirir. Ofis hala açık olsa da, istek yeni iş sayılmaya başladığı noktadan sonra geldi. Bu yüzden iki saatlik SLA Cuma akşamı başlamaz. Bir sonraki iş açılışı olan Pazartesi 09:00'da başlar.
Bunu düz takvim zamanıyla karşılaştırın. Sistem sadece iki saati gönderim zamanına ekliyorsa, son tarihi Cuma 19:30 olarak ayarlar. Bu hassas görünür, ama ekibin çalışma biçimiyle uyuşmaz.
İşte takvim zamanı ile iş zamanı arasındaki fark. Takvim zamanı saate göre her saati sayar. İş zamanı sadece ekibin isteği işleyebildiği saatleri sayar.
Son tarihi atamadan önce iş akışı üç şeyi kontrol etmelidir: istek ofis saatlerinde mi geldi, kesmeden önce mi geldi ve sonraki saatler bir çalışma gününe mi denk geliyor. Bu kontrollerden herhangi biri başarısızsa, zamanlayıcı bir sonraki geçerli iş aralığına kadar beklemelidir.
Bu, ihlal uyarılarını adil tutar ve müşteri vaatlerini gerçekçi kılar.
Bir iş akışı diyagramda güzel görünebilir ama her gün yanlış son tarih üretebilir. Yaygın problem sistemin zamanı makine gibi saymasıdır; oysa iş yerel takvimler ve istisnalar üzerinde çalışır.
En büyük hatalardan biri her ekip için tek bir takvim kullanmaktır. Bu düzenli görünür ama destek hafta sonları çalıştığında, finans daha erken kapandığında ve operasyon farklı bir tatil listesi uyguladığında hızla bozulur. Her adım aynı takvimi kullanırsa, bazı görevler geciktiği halde geç zamanlı görünmeyebilir, bazıları ise vaktinde görünürken aslında yükseltilmiş olmalıdır.
Bir diğer yaygın hata bölgesel tatilleri görmezden gelmektir. Bir şirket tek bir süreç kullanabilir ama süreçteki insanlar farklı ofislerde oturur. Bir istek Londra'dan Dubai'ye oradan New York'a giderse, tek bir tatil takvimi yerel kapanışları kaçırır ve sahte SLA ihlalleri yaratır.
Saat dilimleri de, iş akışı sunucu zamanını yerel iş zamanına tercih ettiğinde sorun çıkarır. Yerel saatte 16:30'da gönderilen bir istek, sunucu başka bir yerdeyse ertesi gün işi sayılabilir. Tersine, otomasyon saati ekibin saatine uymadığı için işler erken gecikmiş görünebilir.
Kesme zamanları sık sık küçük bir detay olarak atlanır, ama büyük etkisi vardır. Bir görevin "aynı iş günü" demesi, 17:00'den sonra gelen isteklerin bir sonraki iş gününden sayılmaması anlamına gelmiyorsa yeterli değildir. Bu kural olmadan geç gün gönderimler imkânsız son tarihler alır ve insanlar sistemi güvenilmez bulur.
Bir diğer kolay hata da bir takvim değiştikten sonra yeniden test etmeyi unutmaktır. Ofis saatleri kayar. Ekipler yarım gün ekler. Tatil politikaları değişir. İş akışı bunlarla birlikte değişmezse son tarih hataları geri döner.
Kodsuz bir platformda bunu inşa ediyorsanız, takvim kurallarını küçük bir ayar olarak değil çekirdek iş mantığı olarak ele alın. Lansmandan önce Cuma akşamı isteği, bölgesel tatil ve saat dilimleri arası el değiştirme gibi birkaç gerçekçi test genellikle zayıf noktaları ilk ortaya çıkarır.
Bir iş akışı temel testleri geçse bile, takvim kuralları yanlışsa ilk günde başarısız olabilir. Yayınlamadan önce genellikle bozan vakaları test edin.
Normal bir iş günü içinde, mesai saatleri içinde gönderilmiş bir istekle başlayın. Sonra gün bitimine yakın başlayan bir isteği test edin. Ardından hafta sonunu geçen bir vaka, bir resmi tatilde gelen bir vaka ve en az iki saat dilimi arasında el değiştiren bir vaka test edin.
Kısa bir ön lansman kontrol listesi yeterlidir:
Mümkünse, kağıt üzerinde beklenen son zamanı sistemin gösterdiği son zamanla karşılaştırın. Bu küçük elle kontrol, kullanıcılar görmeden önce kötü takvim kurallarını yakalar.
Eğer iş akışını AppMaster'da kuruyorsanız, her takvim kuralını tam sürece bağlamadan önce kendi adımı olarak test etmek yardımcı olur. Bu, sorunun zamanlayıcıda mı, yönlendirme mantığında mı yoksa bildirim kurallarında mı olduğunu bulmayı kolaylaştırır.
İlk olarak, zaten kaçırılan son tarihlere, acele onaylara veya karışık el değişimlerine neden olan bir iş akışıyla başlayın. Gerçek bir SLA'ya sahip bir destek kuyruğu, onay akışı veya istek süreci genellikle başlamak için en iyi yerdir.
Tüm işletme çapında her takvim kuralını aynı anda düzeltmeye çalışmayın. Bir iş akışı, gerçek iş takviminin değerini kanıtlamak için yeterlidir.
Kuralları önce düz bir dille yazın. "İş saatlerini kullanın" demek yerine bunun ne anlama geldiğini açıkça yazın: hangi günlerin çalışma günü olduğu, ofis saatlerinin ne olduğu, kesmenin ne zaman uygulandığı, hangi tatillerin saati durdurduğu ve hangi ofislerin farklı takvimleri takip ettiği. Bu adım önemlidir çünkü birçok son tarih sorunu ilk başta teknik değil; farklı ekipler farklı kurallar varsaydığı için ortaya çıkar.
Kurallar netleştikten sonra, bunları geliştiricileri beklemeden güncelleyebilecekleri bir araca taşıyın. Bu, ekiplerin dahili süreçler için AppMaster gibi platformları kullanmasının bir nedenidir. Kod yazmadan ofis takvimlerini depolayan, iş akışı mantığını uygulayan ve onay sistemleri, yönetim panelleri, destek kuyrukları ve müşteri portalları gibi iç araçları destekleyen bir uygulama oluşturabilirsiniz.
İlk sürümü test etmek kolay tutun. Birkaç gerçek örneği iş akışından geçirin, son tarihin bir ekip liderinin elle bekleyeceği zamanla uyuşup uyuşmadığını kontrol edin ve oradan ayarlayın.
Hedef basittir: son tarihler sadece saate değil, gerçek çalışma zamanına uyum sağlamalıdır.
10 Mar 2026
7 dk
08 Mar 20268 dk
07 Mar 202611 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
