Talep formunun, ekiplerin ihtiyaç duymaya başlamasıyla birlikte durum takibi, onaylar, bildirimler ve dışa aktarmalar ekleyerek nasıl aşamalı olarak iş akışı uygulamasına dönüştürüleceğini öğrenin.
Basit bir form başlamak için iyi bir yerdir. İnsanlara istekte bulunmanın tek bir yolunu verir ve dağınık mesajları azaltır. Bir süre bu büyük bir ilerleme gibi gelebilir.
Sorun gönderimden sonra başlar. İstek formla gelir, ama gerçek işler e-posta, sohbet, toplantılar ve tabloların içine kayar. Birisi detayları bir takip tablosuna kopyalar. Başkası bir mesajla ek soru sorar. Bir yönetici neyin beklemede olduğunu görmek için ayrı bir liste tutar.
O noktada form sistem değildir. Sadece ön kapıdır.
Bu, iç taleplerde sık sık olur. Bir ekip yeni bir açılış sayfası, bütçe onayı veya destek sorunu için form kullanır. Form temelleri toplar, fakat ekip yine kimin sahip olduğunu, hangi aşamada olduğunu ve neyin engellediğini belirlemek zorundadır. Bu bilgiler görünür değilse insanlar aynı soruyu tekrar tekrar sormaya başlar: "Durum ne?"
Bu genellikle formun bir iş akışı uygulamasına dönüşmesi gerektiğinin ilk işaretidir. Form başarısız olmadı. Onun etrafındaki iş büyüdü.
Hata her şeyi bir anda eklemeye çalışmaktır. Onayları, bildirimleri, panoları ve dışa aktarmaları çok erken eklerseniz süreç, ekip buna ihtiyaç duyduğunu kanıtlamadan ağırlaşır. Daha fazla alan görünür. Daha fazla tıklama olur. Basit talepler yavaşlamış gibi hissedilir.
Daha iyi bir test, tekrarlayan sürtünmedir. Talepler birden fazla yerde izleniyorsa, insanlar güncelleme istemeye devam ediyorsa, sahiplik belirsizse veya ekip aynı bilgiyi başka yere tekrar giriyorsa form işin yalnızca bir kısmını yapıyordur.
Genişletme zamanı geldiğinde dikkatli olun. Her seferinde bir faydalı adım ekleyin.
Bir talep formunu iş akışı uygulamasına dönüştürmek istiyorsanız, ilk sürümün yine de basit hissettirmesi gerekir. İnsanlar formu açıp doldurup yardım istemeden gönderide bulunabilmelidir.
Tek bir talep türüyle başlayın. Satın alma talepleri, izin talepleri, BT sorunları ve tedarikçi işe alımı gibi farklı türleri aynı ilk sürüme karıştırmayın. Ekibinizin en sık işlediği talebi veya şu anda en fazla ileri geri yaratan talebi seçin.
İnsanların gerçekten kullandığı bilgileri sorun. Bir alan sonraki adımı asla değiştirmiyorsa muhtemelen birinci sürüme ait değildir.
Güçlü bir ilk sürüm genellikle şunları içerir:
Genellikle gerçek talepleri toplamaya başlamak ve hangi eksiğin olduğunu öğrenmek için bu yeterlidir.
İlk günde gönderimi kolay tutun. Uzun formlar kapsamlı görünebilir, ama insanları uzaklaştırır. Düz etiketli kısa bir form, kimsenin kullanmak istemediği mükemmel bir formdan bir haftada daha fazla öğretir.
Örneğin ekibiniz yazılım erişim talepleri topluyorsa, muhtemelen sadece araç adı, kimin erişime ihtiyacı olduğu, neden gerek duyduğu ve ne zamana kadar gerektiği yeterlidir. Maliyet merkezi, yönetici notları, güvenlik notları ve bölüm kodu gibi alanlara yalnızca birisi her seferinde kullanıyorsa ihtiyaç vardır.
Koder.ai'de inşa ediyorsanız, ilk promptu dar tutun. Bir form, bir gönderim akışı ve bir temel talep listesi isteyin. Bu uygulamayı test etmeyi, alanları yeniden adlandırmayı ve insanların görmezden geldiği öğeleri kaldırmayı çok daha kolaylaştırır.
İlk sürümün hedefi tamamlanmışlık değil, öğrenmedir. Küçük bir uygulama düzeltmesi daha kolaydır, açıklaması daha kolaydır ve gerçek kullanım hangi adımın geleceğini gösterdikten sonra büyütmesi çok daha kolaydır.
Başlangıçta bir net yol olsun: biri bir talep gönderir ve bir kişi veya ekip bunu alır. İnsanlar karışıklık olmadan talep gönderebiliyorsa zaten kullanışlı bir şeyiniz var demektir.
Sonra neler olduğunu izleyin. İnsanlar her seferinde aynı takip sorusunu mu soruyor? Birisi detayları bir tabloya mı kopyalıyor, manuel hatırlatmalar mı gönderiyor veya güncellemeleri sohbette mi kovalıyor? Bu tekrar eden davranışlar uygulamanın neye ihtiyacı olduğunu söyler.
Bir iş akışı uygulamasını büyütmenin en güvenli yolu, gerçek bir sorun birden fazla kez ortaya çıktığında özellik eklemektir. Olası olduğu için değil, başka bir aracın sahip olduğu için değil; yalnızca ekibiniz aynı sürtüşmeyle tekrar tekrar karşılaştığı için.
Mantıklı bir sıra genellikle şöyle görünür:
Her adım belirli bir elle yapılan işi ortadan kaldırmalıdır. Yeni bir özellik zaman kazandırmıyor, hataları azaltmıyor veya sahipliği netleştirmiyorsa bekleyebilir.
Bir ekipman talep formunu hayal edin. İlk başta idari ekip sadece talepleri toplar. Birkaç hafta sonra insanlar dizüstü siparişlerinin onaylanıp onaylanmadığını veya hâlâ beklemede olup olmadığını sormaya başlar. İşte durum takibini eklemek için doğru an budur. Daha sonra finans belirli bir tutarın üzerindeki talepleri onaylamalıysa tek bir onay adımı ekleyin. Fazlasına gerek yok.
Bu adım adım yaklaşım, Koder.ai gibi bir oluşturucuda özellikle faydalıdır; çünkü kalıbı ortaya çıktıkça akışı ayarlayabilirsiniz, tüm sistemi baştan tasarlamaya çalışmak yerine.
Her birkaç haftada bir kullanımı gözden geçirin. İnsanların gerçekten neler gönderdiğine, işin nerede yavaşladığına ve hangi kuralları kimsenin takip etmediğine bakın. Bu inceleme genellikle bir sonraki değişikliği açıkça gösterir.
Aynı soru sürekli geliyorsa durum takibini ekleyin: "Talebimi aldınız mı?" veya "Sonraki adım ne?" Basit bir form başlangıçta iyi çalışır, ama talepler birikmeye başlayınca insanlar görünürlük ister.
İyi bir kural basittir: güncellemeler sohbette, e-postada veya birinin hafızasında oluyorsa, bunları uygulamaya taşıyın. Bu zaman kazandırır, takip mesajlarını azaltır ve insanların sürece güvenmesini sağlar.
Çok kısa bir durum setiyle başlayın. Çoğu ekip için dört yeterlidir:
Her durumu anlaşılır tutun. İki kişinin farklı açıklama yapacağı bir durum çok belirsizdir.
Sahiplik durum kadar önemlidir. Her talep şu anda kimden sorumlu olduğunu göstermelidir; bu tek bir kişi veya bir ekip olabilir. Sahip yoksa bir durum etiketi çok yardımcı olmaz çünkü kimin işi ilerleteceği belli değildir.
Basit bir örnek: Bir ekip dahili yazılım taleplerini bir formla toplar. Başta yönetici gelen kutusunu kontrol edip manuel yanıt veriyordu. Birkaç hafta sonra çalışanlar güncelleme istemeye başlar ve bazı talepler dokunulmadan kalır. Durum alanı ve bir sahip eklemek çoğu karışıklığı karmaşık onaylar olmadan çözer.
Erken uzun bir durum zinciri oluşturmaktan kaçının. On etiket düzenli görünse de genellikle insanları yavaşlatır. Ekipler bir talebin "değerlendiriliyor" mu yoksa "inceleme bekliyor" mu olduğunu tartışmak yerine işi bitirmeyi tercih etmelidir.
Bir talep gönderildiği andan bitişe kadar birkaç gerçek adımda ilerleyebiliyorsa durum modeliniz de aynı şekilde küçük olmalıdır.
Onaylar, birinin gerçek bir karar vermesi gerektiğinde faydalıdır; sadece ekip daha fazla kontrol istediğinde değil. Her talebin onay gerektirdiği bir alışkanlık varsa uygulama yavaşlar ama iyileşmez.
Bir onay adımı ekleyin when sonuç para, risk, erişim veya paylaşılan bir ekip kaynağını etkiliyorsa. İyi örnekler arasında belirli bir tutarın üzerindeki satın almalar, özel verilere veya yönetici araçlara erişim, personel durumunu etkileyen izinler veya şirketi harcama taahhüdüne sokan sözleşmeler vardır.
Rutin ve düşük riskli talepler için onay genellikle gecikme getirir ve gerçek bir fayda sağlamaz. Bu durumlarda net bir form ve görünür durum genellikle yeterlidir.
Onaylayıcı listesi kısa tutun. Bir karar vermesi gereken tek bir net kişi üç kişiden daha iyidir; üç kişi kimin karar vereceğini düşünür ya da beklerse iş yavaşlar. Yedek onaylayıcı gerekiyorsa bunu baştan tanımlayın ki talepler beklemesin.
Ne onaylandığının açık olması da yardımcı olur. Onaylayan tam taleple mi, bütçeyle mi, tarihle mi yoksa yalnızca bir sonraki adımla mı ilgili karar veriyor? Bulanıksa insanlar istemedikleri şeyleri onaylar ve ekip sonradan işleri düzeltmek zorunda kalır.
Kararı talep kaydıyla aynı yerde kaydedin. Uygulama kimin onayladığını, ne zaman onayladığını ve bıraktığı notu göstermelidir. Böylece kimse ne olduğunu anlamak için e-postada veya sohbette kazı yapmak zorunda kalmaz.
Çoğu ekip için basit bir kurulum iyi çalışır: küçük yazılım satın almaları doğrudan incelenir, daha büyük satın almalar bir yönetici onayına gider. Talep, yorum ve nihai karar aynı kayıtta kalır. Bu süreci net ve güvenilir kılar.
Önemli bir şey harekete geçirmeyi gerektirdiğinde bildirimler yardımcı olur. İyi örnekler beklemede kalan bir talep, onayın kabul veya reddedilmesi ya da bir görevin bir ekipten diğerine geçmesi gibidir. Bu anlar net bir sonraki adım yaratır, bu yüzden bir uyarı faydalıdır, gürültü değil.
Hata her küçük güncelleme için mesaj göndermektir. Birisi bir yazım hatasını düzeltirken, bir etiketi değiştirirken veya dahili bir not eklerken sürekli bildirim gelirse insanlar artık mesajlara bakmaz. O noktadan sonra faydalı uyarılar bile göz ardı edilir.
Basit bir kural iyi çalışır:
Dışa aktarmalar aynı mantığı izler. İlk günde bunlara ihtiyacınız yoksa sadece yararlı göründükleri için eklemeyin. Birisi veriyi uygulama dışına gerçekten almak istiyorsa ekleyin. Genellikle bu bir yöneticinin düzenli raporlamaya ihtiyacı olduğu veya başka bir ekibin finans, destek veya uyumluluk için dosya gerektiği anlardır.
Dışa aktarmalar eklendiğinde küçük tutun. Çoğu ekip her alanı, her yorumu ve her durum değişikliğini tek bir dosyada istemez. Genellikle sıralayabilecekleri veya paylaşabilecekleri kısa, güvenilir bir veri setine ihtiyaçları vardır.
Bu genellikle sadece birkaç alan demektir:
Küçük bir operasyon ekibini düşünün: onlar için birinin açıklamayı düzenlediğinde uyarı almak gerekli olmayabilir, ama bir talep beş gün boyunca incelenmeden bekliyorsa uyarı gerekir. Belki tam bir veritabanı dışa aktarımı da gerekmez; ama haftalık bir dosya ile durum, sahip ve onay sonucu yöneticinin gecikmeleri hızlıca görmesine yardımcı olabilir.
Koder.ai'de bunu inşa ediyorsanız disiplinli kalmak faydalıdır. Bildirimleri ve dışa aktarmaları ancak insanlar bunları bir kereden fazla istediklerinde ekleyin.
Büyüyen bir şirketteki küçük bir operasyon ekibi satın alma taleplerini daha iyi yönetmek istedi. Tam bir iş akışı sistemi kurarak başlamadılar. Önce öğenin ne olduğu, sebebi, maliyeti ve gerekli tarih gibi bilgileri isteyen tek bir basit formla başladılar.
Başta bir kişi her gönderimi elle inceliyordu. Eksik bir şey varsa detayları kontrol edip takip soruları soruyor ve sonuçla talep edene yanıt veriyordu. Haftada sadece birkaç talep gelirken bu işe yaradı.
İlk gerçek sorun form değildi. Sürekli kontrol etme ihtiyacıydı. İnsanlar sürekli olarak "Talebimi gördünüz mü?" ve "Henüz bir gelişme var mı?" gibi mesajlar gönderiyordu.
Böylece ekip küçük bir değişiklik yaptı. Birkaç net aşamayla durum takibi eklediler: New, Under review, Approved ve Ordered. Bu, talep edenlerin ilerlemeyi kendi başlarına kontrol etmelerini sağladı.
Sonuç anında görüldü. Güncelleme mesajları azaldı ve inceleyen kişi aynı soruyu tekrar tekrar yanıtlarken daha az zaman harcadı.
Birkaç ay sonra başka bir örüntü ortaya çıktı. Küçük talepler kolayca onaylanabiliyordu, ama maliyeti yüksek olanlar bir yöneticinin onayını gerektiriyordu. Her şeye onay eklemek yerine ekip bunu dar tuttu. Belirli bir tutarın üzerindeki talepler doğru yöneticiye gidiyordu. Düşük maliyetli öğeler daha hızlı yolunda kaldı.
Bu süreci basit tuttu. Çoğu talep hızlı kaldı; daha büyük satın almalar gerçekten ihtiyaç duydukları ek incelemeyi aldı.
Sadece daha sonra dışa aktarmalar eklendi. Tetikleyici pratikti: finans, takım bazında, tutar ve onay durumu ile aylık bir satın alma raporu istemeye başladı. O noktada veri dışa aktarmak gerçek bir raporlama ihtiyacını çözdü.
İşte istikrarlı büyüme böyle görünür. Bir formla başlayın. İnsanlar gerçek bir sorun hissettiğinde durum, onaylar, bildirimler veya dışa aktarmalar ekleyin. Her adım yerini hak etmelidir.
En kolay hata çok erken çok fazla şey eklemektir. Basit bir talep formu, gerekli olmayan alanlar ve adımlar göründüğünde yavaş, kafa karıştırıcı ve güvenilmesi zor hale gelir.
İlk problem formu fazla doldurmaktır. Ekipler genellikle bir gün lazım olabilecek her alanı ekler: bütçe, bölüm kodu, öncelik, hukuk notları, tedarikçi detayları vb. Gerçek kullanımda bu alanların çoğu boş kalır veya talebi göndermek için rastgele metin girilir. Daha iyi bir ilk sürüm, bir sonraki adımı atmaya yardımcı olan tek şeyleri ister.
Onaylar başka bir yaygın tuzaktır. Her talep için onay istemek güvenli gelir ama genellikle gecikme yaratır. Düşük riskli talepler, aynı onayı pahalı veya hassas taleplerle aynı şekilde gerektirdiğinde insanlar sebepsiz yere beklemeye başlar.
Durum tasarımı da hızlıca karışık hale gelebilir. Ekipler "Open," "Under review," "Pending internal review," "In progress," ve "Being processed" gibi etiketler oluşturur ve neden kimsenin doğru güncelleme yapmadığını sorgularlar. İyi durumlar kısa ve anlaşılır olmalıdır. Yeni bir kişi on farkı on saniyede anlayamıyorsa liste çok uzundur.
Bildirimler benzer sorunlara yol açar. İlk başta yardımcı gibi görünürler. Sonra her gönderim, yorum, güncelleme ve durum değişikliği herkese mesaj gönderir. İnsanlar bunları okumayı bırakır. Uyarıları yalnızca birinin harekete geçmesi gerektiğinde veya talep edenin gerçekten güncelleme alması gerektiğinde gönderin.
Dışa aktarmalar genellikle daha kimse istemeden varsayılan bir özellik gibi ele alınır. Bu genellikle boşa harcanmış emektir. Bunları oluşturmadan önce bir soru sorun: bu dosyayı kim kullanacak ve hangi kararı destekleyecek? Net bir cevap yoksa erteleyin.
Basit bir kural yardımcı olur:
Daha hafif uygulama genellikle kazanır çünkü insanlar onu gerçekten kullanır.
Yeni bir şey eklemeden önce mevcut sürümün işi zaten yapıp yapmadığını kontrol edin. Amaç özellik yığmak değil; bir sonraki gerçek sürtünme noktasını ortadan kaldırmaktır.
Yararlı bir kural: bir sorun bir kez ortaya çıkarsa not edin. Her hafta ortaya çıkıyorsa düzeltin.
Form çok uzun sürüyorsa daha fazla alan veya adım eklemeyin. Önce sürtünmeyi azaltın.
Kimsenin bir sonraki adımı bilmemesi durumunda sahipliği önce düzeltin. Birçok ekip otomasyon gerektiğini düşünür, ama gerçek sorun taleplerin paylaşılan bir gelen kutusuna düşüp orada kalmasıdır. Görünür bir sahip çoğu sorunu yeni bir özellikten daha iyi çözer.
Durum takibi insanlar sık sık "Talebime ne oldu?" diye soruyorsa yardımcı olur. Bu soru günde birkaç kez geliyorsa basit bir durum alanı herkesin zamanından tasarruf sağlar. Nadiren oluyorsa durum eklemek ekstra iş yaratabilir.
Onaylar sadece birinin gerçek bir evet/hayır kararı vermesi gerektiğinde faydalıdır. Onay yalnızca bir alışkanlıksa süreci yavaşlatır. Onayları bütçe, risk, erişim veya politika açısından önemli olduklarında kaydedin.
Dışa aktarmalar ve raporlar, ekip zaten veriyi uygulama dışında kullanıyorsa mantıklıdır. Bir yönetici haftalık sayıları bir tabloya çekiyorsa veya finans aylık kayıt istiyorsa dışa aktarma pratik olur. Kimse istemiyorsa şimdilik bırakın.
Küçük bir test yardımcı olur. Bir talep sahibinin formu doldurmasını ve bir ekip arkadaşının bunu işlemesini izleyin. Eğer her ikisi de soru sormadan işlerini bitirebiliyorsa bir sonraki özelliğe muhtemelen gerek yoktur. Değilse, darboğaz genellikle çabuk ortaya çıkar.
Bir talep formunu iş akışı uygulamasına dönüştürmenin en iyi yolu düşündüğünüzden daha küçük başlamaktır. İçinde zaten her hafta olan, örneğin içerik talepleri, ekipman talepleri veya yeni müşteri kabulü gibi tekrar eden bir süreci seçin. İnsanlar aynı bilgileri tekrar tekrar gönderiyorsa genellikle başlamak için doğru yerdir.
İlk sürümü tek bir hedef etrafında kurun: talebi net yakalayın ve akışta tutun. Ekip onlarsız gerçek acı hissediyorsa onayları, uyarıları veya dışa aktarmaları hemen eklemeyin. İnsanların gerçekten kullandığı küçük bir uygulama, eğitim ve geçici çözümler gerektiren büyük bir uygulamadan çok daha iyidir.
Basit bir yol şöyle görünür:
Bu son adım önemlidir. Durum takibi eklediyseniz daha az kişi güncelleme istiyor mu bakın. Onay eklediyseniz kararlar daha mı hızlı alınıyor yoksa sadece başka bir bekleme noktası mı yarattınız kontrol edin. Bildirim eklediyseniz takip mesajlarını azaltıyor mu yoksa sadece gürültü mü ekliyor ölçün.
Örneğin bir pazarlama ekibi kampanya talep formuyla başladı. İki hafta sonra aynı soru sıkça tekrarlanıyordu: "Bu incelendi mi?" Bu, basit bir durum alanı eklemek için iyi bir sebepti. Rapor isteyen kimse yoksa dışa aktarmalar bekleyebilir.
Hızlı test edip ayarlamak istiyorsanız Koder.ai pratik bir seçenek olabilir. Teknik olmayan ekiplerin düz metin sohbetten web, sunucu veya mobil uygulama inşa etmesine izin verir; bu da temel bir talep akışıyla başlayıp gerçek kullanım eksiklerini gösterdikçe geliştirmeyi kolaylaştırır.
Bir sonraki iyi hamle nadiren en büyük özellik olur. Tekrar eden bir sorunu ortadan kaldıran en küçük değişikliktir.
Süreç form gönderildikten sonra e-posta, sohbet ve tablolarla takip ediliyorsa form tek başına yetmiyor demektir; o zaman basit bir iş akışı uygulamasına ihtiyaç vardır.
Sık yaşanan ve tekrarlayan geri-gönderim gerektiren bir türle başlayın. İyi ilk seçimler arasında ekipman talepleri, yazılım erişimi, içerik talepleri veya satın alma talepleri vardır.
Küçük tutun. Bir başlık, temel talep detayları, kim için olduğu ve gereken tarih gibi bir sonraki adımı atmak için gerçekten kullanılan bilgileri isteyin.
Hayır. Uzun formlar insanları uzaklaştırır ve kötü veriye yol açar. Bir alan sonraki sonucu değiştirmiyorsa şimdilik bırakın; açıkça faydalı olduğunda ekleyin.
İnsanlar sürekli güncelleme istiyorsa veya talepler görünmeden bekliyorsa durum takibi ekleyin. "New, In review, Needs info, Done" gibi kısa bir set genellikle yeterlidir.
Bütçe, risk, erişim veya politika açısından gerçek bir karar verilmesi gerektiğinde onay ekleyin. Alışkanlık için onay isteniyorsa genellikle yalnızca gecikme getirir.
Her talep için bir sonraki adımdan kim sorumlu olduğunu gösterin. Basit bir sahip alanı bile karışıklığı azaltır ve otomasyondan daha fazla sorunu çözer.
Birinin harekete geçmesi gerektiğinde veya talep edenin gerçekten güncelleme alması gerektiğinde bildirim gönderin. Gecikmeler, kararlar ve devralmalar için uyarılar faydalıdır; küçük düzenlemeler için atlayın.
Veriyi uygulama dışına gerçekten taşıma ihtiyacı olduğunda export ekleyin: raporlama, finans veya uyumluluk gibi. Export, her alanı içermek yerine birkaç güvenilir alana odaklanmalıdır.
Bir form, bir gönderim akışı ve bir temel talep listesiyle başlayın. Koder.ai'de promptu dar tutmak, uygulamayı test etmeyi, alanları yeniden adlandırmayı ve gerçek kullanım gösterdikçe bir sonraki özelliği eklemeyi kolaylaştırır.
