Manuel işleri izleyen, kanıt ve süre yakalayan ve tekrar eden görevleri otomasyona hazır bir backlog'a dönüştüren bir web uygulamasını nasıl planlayıp inşa edeceğinizi öğrenin.
Ekran taslağı çizmeden veya bir veritabanı seçmeden önce neyi ölçmeye çalıştığınızı netleştirin. Amaç “çalışanların her yaptığı şeyi izlemek” değil. Amaç, önce neyi otomatikleştireceğinize kanıta dayalı olarak karar verecek kadar güvenilir şekilde manuel işi yakalamak.
Elle yapılan tekrar eden aktiviteleri yazın (sistemler arasında kopyala/yapıştır, veriyi yeniden girmek, belgeleri kontrol etmek, onayları takip etmek, tabloları mutabıklaştırmak). Her aktivite için açıklayın:
İki cümlede tarif edemiyorsanız muhtemelen birden fazla iş akışını karıştırıyorsunuz.
Bir takip uygulaması, işi dokunan herkesin ihtiyaçlarını karşıladığında başarılı olur—sadece rapor isteyen kişinin değil.
Farklı motivasyonlar bekleyin: operatörler daha az idari iş; yöneticiler daha öngörülebilirlik; BT ise stabil gereksinimler ister.
Takip, sonuçlarla bağlantılı olmadıktan sonra işe yaramaz. Tutarlı şekilde hesaplayabileceğiniz küçük bir set seçin:
Sınırları erken tanımlayın ki kazara devasa bir şey inşa etmeyin.
Bu uygulama tipik olarak şu değildir:
Bunlarla tamamlayıcı olabilir—ve bazen dar bir dilimi değiştirebilir—eğer bu açıkça niyetinizse. Zaten bilet sistemi kullanıyorsanız, takip uygulamanız basitçe mevcut öğelere yapılandırılmış “manuel çaba” verisi ekleyebilir (bkz. /blog/integrations).
Bir takip uygulaması odaklanmaya göre başarılı olur veya başarısız olur. İnsanların yaptığı her “meşgul işi” yakalamaya çalışırsanız, gürültülü veri toplar, kullanıcıları hayal kırıklığına uğratır ve yine de ilk otomatikleştirilecek şeyi bilemezsiniz. Tutarlı ölçülebilen küçük, açık bir kapsamla başlayın.
Yaygın, tekrarlı ve zaten acı veren iş akışlarını seçin. İyi bir başlangıç seti genellikle farklı manuel çaba türlerini kapsar, örneğin:
Herkesin aynı şekilde uygulayabileceği basit bir tanım yazın. Örneğin: “Sistemin otomatik olarak yapmadığı, bir kişinin bilgiyi taşıdığı, kontrol ettiği veya dönüştürdüğü her adım.” Müşteri çağrıları, yaratıcı yazma, ilişki yönetimi gibi birkaç hariç tutma ekleyin ki insanlar her şeyi kaydetmesin.
İş akışının nerede başladığını ve bittiğini açıkça belirleyin:
Zamanın nasıl kaydedileceğine karar verin: görev başına, vardiya başına ya da hafta başına. “Görev başına” en iyi otomasyon sinyalini verir, ama görevler çok parçalıysa “vardiya/hafta başına” pratik bir MVP olabilir. Anahtar tutarlılıktır, kesinlik değil.
Alanları, ekranları veya panoları seçmeden önce işin bugün nasıl gerçekçi şekilde yürüdüğünü net bir şekilde görün. Hafif bir harita neyi takip etmeniz gerektiğini ve neyi görmezden gelebileceğinizi ortaya çıkarır.
Tek bir iş akışıyla başlayın ve düz bir çizgi halinde yazın:
Tetikleyici → adımlar → devralmalar → sonuç
Somut olun. “Paylaşılan bir gelen kutusuna istek gelir” gibi ifadeler, “Alım olur” demekten daha iyidir. Her adım için kim yaptığı, hangi aracı kullandığı ve “tamam”ın ne anlama geldiğini not edin. Devralmalar varsa (Satış’tan Operasyon’a, Operasyon’dan Finans’a), bunları açıkça belirtin—işin kaybolduğu yerler devralmalardır.
Takip uygulamanız, sadece aktiviteyi değil sürtünmeyi de vurgulamalıdır. Akışı haritalarken işaretleyin:
Bu gecikme noktaları daha sonra yüksek değerli alanlar (örn. “engellendi sebebi”) ve öncelikli otomasyon adayları olur.
İşin tamamlanması için insanların güvendiği sistemleri listeleyin: e-posta dizileri, tablolar, ticketing araçları, paylaşılan sürücüler, eski uygulamalar, sohbet mesajları. Birden fazla kaynak çelişiyorsa hangi kaynağın “kazandığını” not edin. Bu, sonraki entegrasyonlar için ve veri tekrarını önlemek için çok önemlidir.
Çoğu manuel iş dağınık olur. Görevlerin neden saptığını sıklıkla açıklayan yaygın nedenleri not edin: özel müşteri koşulları, eksik belgeler, bölgesel kurallar, tek seferlik onaylar. Her kenar durumu modellemeye çalışmıyorsunuz—sadece bir görevin daha uzun sürmesine veya ekstra adım gerektirmesine neden olan kategorileri kaydedin.
Bir manuel iş takipçisi, insanların işi hızlıca kaydedip yine de işe yarar veri üretebilmesine dayanır. Amaç “her şeyi toplamak” değil. Tekrar eden acıyı otomasyon adaylarına çevirebilecek kadar yapı yakalamaktır.
Çekirdek veri modelinizi ekipler arasında basit ve tutarlı tutun:
Bu yapı hem günlük kayıt hem de sonraki analiz için destek sağlar, kullanıcılardan uzun bir anket doldurmalarını istemez.
Zaman otomasyon önceliklendirmesi için şarttır ama kolay olmalı:
Zaman “izleniyormuş” hissedilirse benimseme düşer. Bunu bireyleri izlemek değil, meşguliyeti azaltmak olarak konumlandırın.
İşi otomatik yapamayan nedeni açıklayan bir zorunlu alan ekleyin:
Kısa bir açılır liste + isteğe bağlı not, raporlama için uygun yapı sağlar; not ise istisnaların bağlamını verir.
Her Task şu tutarlı sonuçlarla bitmeli:
Bu alanlarla israfı nicelendirir (yeniden iş), arıza modlarını belirler (hata türleri) ve gerçek işe dayalı güvenilir bir otomasyon backlog'u oluşturabilirsiniz.
Bir işi kaydetmek, işi yapmaktan daha yavaş hissettiriyorsa insanlar atlar—veya kullanışsız veri girerler. UX hedefiniz basit: en az sürtünmeyle en kullanışlı minimum detayı yakalayın.
Tam döngüyü kapsayan küçük bir ekran setiyle başlayın:
Hızı mükemmellikten önce tasarlayın. Yaygın eylemler için klavye kısayolları (öğe oluştur, durum değiştir, kaydet) sağlayın. Tekrarlayan işler için kullanıcıların aynı açıklamaları ve adımları tekrar yazmaması adına şablonlar sunun.
Mümkünse yerinde düzenleme ve mantıklı varsayılanlar kullanın (örn. otomatik olarak mevcut kullanıcıya ata, bir öğeyi açtıklarında “başladı” zamanını ayarla).
Serbest metin işe yarar ama iyi toplamaz. Raporlamayı güvenilir kılmak için rehber alanlar ekleyin:
Uygulamayı herkes için okunur ve kullanılabilir yapın: yüksek kontrast, açık etiketler (yalnızca yer tutucu değil), klavye odak durumları görünür, ve hızlı kayıt için mobil uyumlu tasarım.
Uygulamanız otomasyon kararlarını yönlendirecekse, insanlar veriye güvenmeli. Herkes her şeyi düzenleyebildiğinde, onaylar belirsiz olduğunda veya değişiklik kaydı yoksa güven kırılır. Basit bir izin modeli ve hafif bir denetim izi çoğu sorunu çözer.
İşi nasıl kaydettiklerine göre dört rolle başlayın:
Erken aşamada kullanıcı başına özel kurallardan kaçının; rol tabanlı erişim açıklaması ve bakımı daha kolaydır.
Hangi alanların “gerçek” olduğunu ve hangi notların serbestçe düzenlenebileceğini belirleyin, ve gerçekleri gözden geçirme sonrası kilitleyin.
Pratik bir yaklaşım:
Bu, raporlamayı sabit tutar fakat meşru düzeltmelere izin verir.
Ana olaylar için bir denetim kaydı ekleyin: durum değişiklikleri, zaman ayarlamaları, onay/redler, ek/çıkarılan kanıtlar ve izin değişiklikleri. En az şu bilgileri saklayın: işlem yapan, zaman damgası, eski değer, yeni değer ve (isteğe bağlı) kısa bir yorum.
Her kaydın üzerinde görünür hale getirin (örn. “Aktivite” sekmesi) ki anlaşmazlıklar Slack arkeolojisine dönüşmesin.
Saklama kurallarını erken belirleyin: kayıtları ve ilişkili kanıtları (görseller, dosyalar, bağlantılar) ne kadar süre tutacaksınız? Birçok ekip loglar için 12–24 ay, büyük ekler için daha kısa süre uygular.
Eğer yüklemeye izin veriyorsanız, bunları denetim hikayesinin parçası olarak ele alın: dosyaları sürümlendirin, silmeleri kaydedin ve erişimi role göre kısıtlayın. Bu, bir giriş otomasyon projesinin temeli olduğunda önem kazanır.
Pratik bir MVP inşa etmesi ve işletmesi kolay, değiştirilebilir ve işletmesi sıkıcı olmalı. Amaç gelecekteki otomasyon platformunuzu tahmin etmek değil—manuel iş kanıtlarını düşük sürtünmeyle güvenilir şekilde yakalamaktır.
Aşağıdaki ayrımı kullanarak başlayın:
Bu ayrım UI'nın hızlı yinelemesine izin verirken API gerçeğin kaynağı olmaya devam eder.
Ekiplerin hızlıca teslim edebileceği bir yığını seçin. Yaygın kombinasyonlar:
Erken dönemde egzotik teknolojiye kaçmayın—en büyük risk ürün belirsizliğidir, performans değil.
Eğer MVP'yi hızlandırmak ve kilitlenmeden ilerlemek isterseniz, Koder.ai gibi bir araç yazma platformu yazılı gereksinimden çalışan bir React web uygulaması, Go API ve PostgreSQL'e—sohbet yoluyla—dönmenize yardım edebilir; ayrıca kaynak kodunu dışa aktarma, dağıtma/ barındırma ve anlık görüntülerle geri alma seçenekleri sunar. Bu, pilot sonrası gereksinimlerin hızla evrildiği iç araçlar için özellikle yararlıdır.
Endpointleri veritabanı tablolarınızın değil, kullanıcıların gerçekte yaptığı eylemlerin aynası olacak şekilde tasarlayın. Tipik “fiil-odaklı” yetenekler:
Bu, gelecekte mobil veya entegrasyon istemcileri eklerken çekirdek kodu yeniden yazmayı zorlaştırmaz.
POST /work-items
POST /work-items/{id}/time-logs
POST /work-items/{id}/attachments
POST /work-items/{id}/status
GET /work-items?assignee=me&status=in_progress
Erken benimseyenler genellikle "Zaten sahip olduğum şeyi yükleyebilir miyim?" ve "Verimi dışarı alabilir miyim?" diye sorar. Ekleyin:
Bu, yeniden girişten kurtarır, işe almayı hızlandırır ve MVP'nizin çıkmaz bir araç gibi hissettirmesini önler.
Uygulamanız insanların her şeyi hatırlamasına dayanıyorsa benimseme zamanla düşer. Pratik yaklaşım, önce manuel girişi başlatmak (iş akışını netleştirir), sonra gerçekten çaba azaltan konektörleri eklemektir—özellikle yüksek hacimli, tekrarlı işler için.
İnsanların zaten başka yerlerde iz bıraktığı adımlara bakın. Yaygın “düşük sürtünme” entegrasyonlar:
Elele entegrasyonlar hızla karmakarışık olur eğer öğeleri sistemler arasında güvenilir şekilde eşleştiremiyorsanız. Benzersiz bir tanımlayıcı oluşturun (örn. MW-10482) ve email mesaj ID'si, tablo satır anahtarı, ticket ID gibi dış ID'leri yanında saklayın. Bildirimlerde ve dışa aktarımlarda bu tanımlayıcıyı gösterin ki insanlar aynı öğeye her yerde referans verebilsin.
Amaç insanları hemen ortadan kaldırmak değil—yazmayı azaltmak ve yeniden girişi önlemektir.
Entegrasyonlardan gelen alanları (talep eden, konu, zaman damgaları, ekler) ön-doldurun, ama insanların üzerine yazmasına izin verin ki kayıt gerçeği yansıtsın. Örneğin, bir e-posta kategori ve tahmini çaba önerebilir; kişi gerçek harcanan süreyi ve sonucu onaylar.
İyi bir kural: entegrasyonlar varsayılan olarak taslaklar oluştursun; insan onayıyla “onayla ve gönder” adımı kalıcı olsun, ta ki eşleştirmeye güvenene kadar.
Manuel işi izlemek yalnızca kararlara dönüşürse değerlidir. Uygulamanızın hedefi ham kayıtları önceliklendirilmiş otomasyon fırsatları listesine—haftalık ops veya iyileştirme toplantısında kolayca gözden geçirilebilen—dönüştürmek olmalıdır.
Basit, açıklanabilir bir puanla başlayın ki paydaşlar neden bir şeyin üst sıraya çıktığını görebilsin. Pratik kriter seti:
Skoru altta yatan sayılarla birlikte görünür tutun ki karar kutudan çıkan bir kara kutu gibi olmasın.
Kayıtları tekrarlanabilir “iş öğeleri” halinde gruplandıran özel bir görünüm ekleyin (ör. “Müşteri adresini Sistem A’da güncelle, sonra Sistem B’de doğrula”). Öğe otomatik olarak puana göre sıralansın ve şu bilgileri göstersin:
Etiketlemeyi hafif tutun: bir tıkla eklenen etiketler (sistem, girdi tipi, istisna türü). Zamanla bunlar otomatikleştirilebilir stabil desenleri (iyi) ve karmaşık kenar durumlarını (eğitim veya süreç düzeltmesi için daha uygun) ortaya çıkarır.
Basit bir tahmin yeterlidir:
YG (zaman) = (kazanılan zaman × sıklık) − bakım varsayımı
Bakım için sabit aylık saat tahmini kullanın (örn. 2–6 saat/ay) ki ekipler fırsatları tutarlı şekilde karşılaştırsın. Bu backlog'u etki odaklı tutar, görüş odaklı değil.
Panolar gerçek soruları hızlı cevaplamıyorsa işe yaramaz: “Nerede zaman harcıyoruz?”, “Bizi ne yavaşlatıyor?” ve “Son değişiklik gerçekten işe yaradı mı?” Raporlamayı kararlar etrafında tasarlayın, gösterişli grafikler değil.
Çoğu lider her detayı istemez—net sinyaller ister. Pratik bir temel pano şunları içerir:
Her kart tıklanabilir olsun ki liderler bir başlık rakamından “bunu ne tetikliyor”a gidebilsin.
Tek bir hafta yanıltıcı olabilir. Trend çizgileri ve basit tarih filtreleri (son 7/30/90 gün) ekleyin. Bir iş akışını değiştirdiğinizde—ör. entegrasyon eklediğinizde—önce ve sonra karşılaştırmasını kolaylaştırın.
Hafif bir yaklaşım: bir “değişiklik işareti” (tarih ve açıklama) saklayın ve grafikte dikey bir çizgi gösterin. Bu, iyileşmeleri gerçek müdahalelere bağlamayı kolaylaştırır.
Manuel iş takibi sert veriler (zaman damgaları, sayılar) ile yumuşak girdileri (tahmini süre) karıştırır. Metrikleri açıkça etiketleyin:
Zaman tahmini ise kullanıcı arayüzünde belirtin. Yanlış görünüp kesinmiş gibi hissettirmektense dürüst olmak daha iyidir.
Her grafik “kayıtları göster” seçeneğini desteklesin. Drill-down güven oluşturur ve aksiyonu hızlandırır: kullanıcılar iş akışına, ekibe ve tarih aralığına göre filtreleyip alttaki work item'ları açarak notları, devralmaları ve ortak engelleyicileri görebilsin.
Panoları otomasyon backlog görünümüyle ilişkilendirin ki en büyük zaman yiyenler bağlam taze iken iyileştirme adaylarına dönüştürülebilsin.
Uygulamanız işin nasıl yapıldığını yakaladıkça hassas ayrıntılar—müşteri adları, dahili notlar, ekler ve “kim ne zaman ne yaptı”—toplanır. Güvenlik ve güvenilirlik eklenti değildir—benimseme olmadan güven kaybedersiniz.
Gerçek sorumluluklara uyan rol tabanlı erişimle başlayın. Çoğu kullanıcı yalnızca kendi kayıtlarını veya ekibinin kayıtlarını görmeli. Yönetici haklarını sınırlayın; “girişleri düzenleyebilir” ile “veri dışa aktarabilir/onaylayabilir” yetkilerini ayırın.
Dosya yüklemeleri için her eki güvensiz kabul edin:
Bir MVP göndermek için kurumsal güvenlik gerekmez ama şu temel şartlar olmalı:
Sistem olaylarını hata ayıklama ve denetim için yakalayın: oturum açmalar, izin değişiklikleri, onaylar, içe aktarma işler ve başarısız entegrasyonlar. Günlükleri yapılandırılmış ve aranabilir tutun, ama sırları dökmeyin—API tokenları, parolalar veya tam ek içeriklerini asla günlüklemeyin. Hassas alanları varsayılan olarak sansürleyin.
Kişisel verilerle çalışıyorsanız erken karar verin:
Bu seçimler şemasını, izinlerini ve yedeklemelerini etkiler—sonradan düzeltmektense baştan planlamak daha kolaydır.
Bir takip uygulaması benimsemeye bağlıdır. Yayını bir ürün lansmanı gibi ele alın: küçük başlayın, davranışı ölçün ve hızlıca yineleyin.
Önce bir ekip ile pilot yapın—tercihen manuel iş acısını zaten hisseden ve net bir iş akışına sahip bir grup. Kapsamı dar tutun (bir veya iki iş türü) ki kullanıcıları yakından destekleyip uygulamayı bozmadan ayarlamalar yapabilesiniz.
Pilot süresince anında geri bildirim toplayın: kayıttan sonra bir tıkla “Bir şey zordu” istemi ve haftalık 15 dakikalık kısa kontrol. Benimseme stabil olduğunda, benzer iş örüntüsüne sahip bir sonraki ekibe genişletin.
Herkesin “iyi”nin ne olduğunu bilmesi için basit, görünür hedefler koyun:
Bunları dahili bir panoda takip edin ve ekip liderleriyle gözden geçirin.
İçeride yardım sağlayın:
Aylık bir gözden geçirme rutini belirleyin ki sırada ne otomatikleştirileceğine karar verilebilsin. Kayıt verisini kullanarak önceliklendirin: yüksek sıklık + yüksek süre olanlar önce, açık sahipler ve beklenen etki ile.
Kapanışta sonuçları gösterin: “X kadar kaydettiğiniz için Y otomatikleştirildi.” Bu, insanların kaydetmeye devam etmesi için en hızlı yoldur.
Hızlı yineleme yapan ekipler için, pilot ilerledikçe uygulamayı kararsız hale getirmeyen araçlar düşünün. Örneğin, Koder.ai'nin planning mode özelliği kapsam ve akışları tasarlamanıza yardımcı olur; snapshot/rollback ise alanları, alanlarından ve izinleri öğrenirken güvenlice değiştirmenizi sağlar.
Öncelikle elle yapılan tekrar eden aktiviteleri listeleyerek ve her birini basit terimlerle yazarak başlayın:
Eğer iki cümlede tarif edemiyorsanız, ölçülebilir olması için iş akışını birden fazla parçaya ayırın.
Başlangıç için 3–5 iş akışı seçin: yaygın, tekrar eden ve zaten acı veren süreçler (kopyala/yapıştır, veri girişi, onaylar, mutabakatlar, elle raporlama). Dar bir kapsam benimsemeyi kolaylaştırır ve otomasyon kararları için daha temiz veri üretir.
Herkesin tutarlı bir şekilde kaydedebilmesi için uygulanabilir bir tanım kullanın, örneğin: “Sistemin otomatik olarak yapmadığı, bir kişinin bilgiyi taşıdığı, kontrol ettiği veya dönüştürdüğü her adım.”
Ayrıca hariç tutulanları (ör. ilişki yönetimi, yaratıcı yazma, müşteri aramaları) dokümante edin ki insanlar her şeyi kaydetmesin ve veri setiniz sulanmasın.
Her iş akışını şu şekilde haritalayın:
Her adım için kimin yaptığı, hangi aracı kullandığı ve “tamam”ın ne anlama geldiğini kaydedin. Devralmaları ve yeniden iş döngülerini açıkça not edin—bunlar daha sonra yüksek değerli takip alanları olur (ör. tıkanma sebepleri, yeniden iş sayıları).
Aşırıya kaçmayan, pratik ve yeniden kullanılabilir bir çekirdek model işe yarar:
İnsanların uygulamayı kullanmaktan kaçınmaması için birden fazla kolay yol sunun:
Öncelik tutarlılık ve düşük sürtünmedir, kusursuz doğruluk değil—bunu gözetim değil, yükü azaltma olarak konumlandırın.
İşin neden otomatik olmadığını açıklayan tek bir zorunlu kategori ekleyin:
Kısa bir açılır liste ve isteğe bağlı bir not bağlam sağlar; açılır liste raporlamayı mümkün kılar, not istisnalar için bağlam verir.
Basit rol tabanlı erişim kullanın:
Onaydan sonra zaman, durum veya kanıt gibi “gerçekleri” kilitleyin ve önemli değişikliklerin denetim kaydıyla yapılmasını sağlayın. Bu, raporlamayı istikrarlı kılar ve güveni artırır.
Genelde yeterli olan “sıkıcı” bir MVP mimarisi:
Bu, yinelemeyi hızlı tutar ve tek gerçek veri kaynağınızı korur.
Günlük kayıtları tekrarlanabilir fırsatlara dönüştürmek için şeffaf kriterlerle sıralayın:
Ardından otomasyon backlog’unu gösteren bir görünüm oluşturun; toplam harcanan süre, trendler, en çok etkilenen ekipler ve ortak tıkanma noktalarını gösterin ki haftalık kararlar kanıta dayansın.
Ekipler arasında tutarlı tutun ki raporlama ve otomasyon puanlaması daha sonra çalışsın.