Puanlama, fotoğraf kanıtı, düzeltici işlemler ve net raporlama içeren bir kalite inceleme kontrol listesi uygulaması planlayın; böylece operasyon ekipleri sonuçları takip edip sorunları kapatabilir.
Operasyon ekiplerinin genellikle denetim formları vardır, ama asıl iş form doldurulduktan sonra başlar. Günlük sıkıntılar tahmin edilebilir: insanlar aynı soruyu farklı yorumlar, vardiya yoğun olduğunda kontroller atlanır ve sonuçlar tablolar ve sohbet dizileri arasında dağılır. Başarısız bir madde bir kez bahsedilip sahip ve son tarih olmadan kaybolabilir.
Kanıt eksikliği de sık görülen bir boşluktur. Eğer tek kanıt “iyi görünüyor” veya “düzeltildi” ise, denetçiler sorunun gerçekten var olduğunu veya gerçekten çözüldüğünü onaylayamaz. Denetimler veya müşteri şikayetleri geldiğinde ekipler ne olduğunu yeniden oluşturmak için saatler harcar.
Bir kalite inspeksiyon kontrol listesi uygulaması spesifikasyonu, tekrarlanabilir denetimler, ölçülebilir sonuçlar ve hızlı, takip edilebilir takipler üretmelidir. Kötü yapılmış bir denetimi zorlaştırmalı ve telefonla, gürültülü ve zaman sınırlı ortamlarda bile iyi bir denetimi kolaylaştırmalıdır.
Çoğu ekipte küçük bir rol zinciri vardır:
Basit bir senaryo kapsamı belirler: bir denetçi depo yükleme alanını kontrol eder, hasarlı güvenlik tabelası bulur, fotoğraf çeker, bakıma düzeltici bir görev atar ve süpervizör ertesi gün başka bir fotoğraf ve not ile düzeltmeyi doğrular.
"Bitti" açık ve test edilebilir olmalıdır. Tam bir denetim kaydı; nihai bir puan (ve nasıl hesaplandığı), önemli bulgular için kanıt (fotoğraflar ve kısa notlar), sahibi, son tarih ve durumu olan düzeltici işlemler ve sıcak noktaları, tekrarlayan hataları ve gecikmiş işleri gösteren raporları içermelidir.
Bunu AppMaster gibi bir no-code araçta yapacaksanız, spesifikasyonu platformdan bağımsız tutun. Uygulamanın zorlaması gereken davranışlara, verilere ve hesap verebilirliğe odaklanın.
Aynı kelimenin farklı anlamlarda kullanılması denetim uygulamalarını hızla bozabilir. Ekranlar ve kurallar yazmadan önce küçük bir sözlük üzerinde anlaşın ve alan etiketlerinde, bildirimlerde ve raporlarda tutarlı kullanın.
Günlük etkinlik için tek bir ana terim seçin. Birçok ekip rutin kontroller (vardiya başlangıcı, hat değişimi, mağaza açılışı) için “inspection/denetim” kelimesini; daha seyrek ve resmi incelemeler için “audit” terimini kullanır.
Eğer "spot check" de yapıyorsanız, bunları daha az zorunlu alanı olan hafif denetimler olarak tanımlayın; tamamen farklı bir nesne olmasın. Sonra tipler arasında neyin değiştiğine karar verin: kim çalıştırabilir, hangi kanıt gerekli ve puanlama ne kadar sıkı.
İnsanların tasarladığı kontrol listesini, insanların tamamladığı kontrol listesinden ayırın.
Bir şablon (veya kontrol listesi şablonu) ana tanımdır: bölümler, sorular, kurallar, puanlama ve gerekli kanıt. Bir denetim çalıştırması ise siteye, varlığa ve zamana bağlı tamamlanmış bir örnektir; cevapları, fotoğrafları ve nihai puanı içerir.
Bu, “Geçen ayın sonuçları neden bugün bizim checklisti düzenlediğimizde değişti?” sorusunu önler. Ayrıca şablon sürümüne göre gruplarsanız raporlama temiz kalır.
İş diliyi basit ve öngörülebilir tutun:
Eğer ekibiniz bugün PA kullanmıyorsa, yine de isteğe bağlı tutabilirsiniz. Sadece açıkça tanımlayın.
Hangi kanıtın kabul edileceğine karar verin: fotoğraf, not, imza veya dosya eki. Hangi durumda hangisinin gerekli olduğunu açıkça belirtin (sadece başarısızlıklar, tüm kritik sorular veya her zaman). Örneğin, gıda güvenliği maddelerindeki herhangi bir "Fail" için fotoğraf zorunlu kılın ve denetim kapatıldığında yönetici imzası isteyin.
AppMaster uyguluyorsanız, bu terimleri enum olarak tutun ve durum adlarını tutarlı kullanın ki iş akışları ve raporlar takip edilebilir olsun.
İyi bir veri modeli, uygulamayı sahada hızlı ve sonrasında raporlamayı kolay kılar. Planladığınız şeyi (şablonlar), olanı (denetim sonuçları) ve yaptıklarınızı (takipler) ayrı tutun.
Başlangıç için net bir "nerede" ve "ne" yapısı kurun. Çoğu operasyon ekibi Sites (tesis veya mağaza), Alanlar (yükleme alanı, mutfak) ve bazen Asset'ler (forklift #12, friteöz #3) ihtiyacı duyar. Sonra şablonları ve yürütmeleri ekleyin.
Temel varlıkların basit bir gruplaması şöyle görünür:
Şablonlar sürümlenmeli. Bir kontrol listesini düzenlediğinizde yeni bir sürüm oluşturun ki eski denetimler o sırada sorulan sorularla eşleşsin.
Denetim kayıtları genellikle şunu gerektirir: kim yaptı, nerede oldu (site/alan/asset), hangi kontrol listesi sürümü, zaman damgaları ve bir durum. Durumları küçük ve öngörülebilir tutun: Taslak, Devam ediyor, Gönderildi, İncelendi.
Bulgular cevaplar ile yapılacak işleri bağlar. Bir bulgu bir kontrol listesi maddesine bağlanır ve yanıtı, puanı (varsa), notları ve kanıtı (fotoğraflar) saklar.
İşlemler bulgulardan ayrı olmalıdır ki atanabilsin, izlenebilsin ve doğrulanabilsin. Kısa bir durum seti kullanın: Açık, Devam ediyor, Engellendi, Doğrulandı, Kapandı.
İzinler tablolar kadar önemlidir. Yaygın bir kural seti: sadece yöneticiler veya kalite liderleri şablonları düzenleyebilir; denetçiler denetim oluşturup gönderebilir; süpervizörler denetimleri inceleyip işlemleri kapatabilir.
Örnek: bir denetçi Site A için "Dock safety" denetimini gönderir. İki bulgu başarısız olur ve otomatik olarak iki işlem oluşturularak bakıma atanır. Bir süpervizör bunları doğrular ve kapatır.
AppMaster'da yapıyorsanız, önce Data Designer'da bu varlıkları modelleyin, sonra iş süreçlerinde durum ve rol kontrollerini zorunlu kılın ki iş akışı tutarlı olsun.
İki farklı kişi aynı şekilde cevap verebilecek şekilde tasarlanmış bir kontrol listesi en iyi sonuç verir. Her kontrol listesini sıralı sorular olarak tanımlayın; her birinin bir tipi, kuralları ve metin değişse bile asla değişmeyen stabil bir kimliği olsun.
Küçük bir soru tipi seti kullanın ve her birinin ne anlama geldiği konusunda katı olun. Yaygın seçenekler: geçer-geçmez (pass-fail), çoktan seçmeli (tek seçim), sayısal (birimler ve min-maks sınırları ile) ve serbest metin.
Fotoğrafı özel bir soru tipi olarak değil, bir kural olarak ele alın. Herhangi bir soruda zorunlu kılınabilecek bir özellik olmalıdır.
Her soruya üç işaret ekleyin: gerekli, isteğe bağlı ve kritik. Kritik, gerekli ile aynı şey değildir. Bir soru isteğe bağlı olabilir ama sadece bazı yerlerde geçerliyse kritik olarak işaretlenebilir.
Koşullu sorular karmaşayı azaltır ve veri kalitesini artırır. Örnek: "Yangın çıkışı engellenmiş mi?" evet ise "Engelin fotoğrafını çek" ve "Engel türünü seç" (palet, çöp, diğer) göster. Koşulları basit tutun. Testi zorlaştıran uzun bağımlılık zincirlerinden kaçının.
Şablon değişiklikleri geçmişi yeniden yazmamalıdır. Şablonları yayımlanan sürümler olarak ele alın:
AppMaster'da soruları şablon sürümüne bağlı kayıtlar olarak saklayın ve yayımlanmış sürümlerde düzenlemeyi kilitleyin ki denetimler denetimler sırasında temiz kalsın.
Bir puanlama modeli ancak bir süpervizörün 10 saniyede anlayabileceği ve daha sonra bir itiraz sırasında güvenebileceği kadar basit çalışır. Bir yaklaşım seçin ve ekranlardan önce düz metinle kuralları yazın.
Üç yaygın seçenek: puan bazlı (her soru puan ekler), ağırlıklı yüzde (bazı sorular daha fazla önem taşır) veya cezme/düşüntü (100'den başlayıp eksiltme). Puanlar en kolay açıklanandır. Ağırlıklı yüzde, birkaç maddenin riskin çoğunu oluşturduğu durumlarda iyidir (örneğin gıda güvenliği). Düşüntü tarzı, "ceza" hisli denetimler için sezgiseldir.
Kuralları önceden tanımlayın ki puanlar tutarlı olsun:
Örnek: bir depo dock denetiminde 20 soru, her biri 1 puan. İkisi N/A, dolayısıyla maksimum 18 olur. Denetçi 16 geçer, 2 başarısız yapar, puan 16/18 = %88.9 olur. Eğer başarısızlardan biri "Acil çıkış engellenmiş" ve Kritik ise, denetim yüzdeye bakılmaksızın otomatik başarısız olur.
Denetlenebilirlik için hem ne olduğuna hem de nedenine dair bilgiyi saklayın: her cevap, puanı veya ağırlığı, herhangi bir kritik bayrak ve hesaplanmış nihai puan. AppMaster'da bunu Business Process içinde hesaplayıp bir puan kırılımı (scoring breakdown) saklayabilirsiniz ki sayı aylardır bile yeniden üretilebilir.
Fotoğraflar bir denetimi "bana güven"den doğrulanabilir bir şeye dönüştürür. Ama her şey için fotoğraf zorunlu kılarsanız insanlar acele eder, yüklemeler başarısız olur ve doğrulayıcılar görüntülerle boğulur. Basit, görünür kurallar kullanılabilirliği korur.
Tartışmayı azaltıyorsa fotoğrafı zorunlu kılın. Yaygın tetikleyiciler: herhangi bir başarısız madde, herhangi bir kritik madde (geçse bile), rastgele örneklem veya gıda güvenliği ya da ağır ekipman kontrolleri gibi yüksek riskli alanlardaki her madde. Gerekliliği kullanıcının cevaplamadan önce görünür yapın ki sürpriz olmasın.
Kanıtı anlamlı kılmak için yeterli meta veriyi saklayın: zaman damgası ve zaman dilimi, denetçi kimliği, site/alan, ilgili kontrol listesi maddesi ve sonuç, ve yükleme durumu (çevrimdışı yakalandı, yüklendi, başarısız).
Kanıt incelemesi açık olmalıdır. Bir fotoğrafı kim kabul edebilir tanımlayın (genellikle bir süpervizör veya QA lideri) ve kabulün ne anlama geldiğini belirtin. Reddedildiğinde ne olacağı da net olmalı: yeniden çekim isteği, denetimi yeniden açma veya bir düzeltici işlem oluşturma gibi.
Gizlilik için temel rehberlik ekleyin. Ekranda kısa bir çekim ipucu verin: yüzlerden, isim etiketlerinden ve müşteri verisi içeren ekranlardan kaçının. Düzenlemeye tabi alanlarda galeriden içe aktarmayı devre dışı bırakan ve canlı çekimi zorunlu kılan bir "gizli/sensitif alan" bayrağı düşünün.
Çevrimdışı yakalama birçok uygulamanın kırıldığı noktadır. Her fotoğrafı kuyruklanmış bir görev gibi ele alın: önce yerelde kaydedin, net bir "yükleme bekliyor" rozeti gösterin ve bağlantı geri geldiğinde otomatik tekrar deneyin. Biri uygulamayı vardiya ortasında kapatsa bile kanıt orada kalmalıdır.
Örnek: bir depo denetçisi "Palet sargısı sağlam" maddesini Fail olarak işaretler. Uygulama fotoğraf ister, zaman ve konumu yakalar, çevrimdışı kuyruklar ve süpervizör daha sonra görüntüyü kabul edip düzeltici işlemi onaylar.
Bir denetim uygulaması yalnızca sorunları düzeltmeye dönüştürdüğünde faydalıdır. Düzeltici işlemleri yorumlar olarak değil, birinci sınıf kayıtlar olarak ele alın.
Düzeltici işlemler iki yolla oluşturulmalıdır:
Sade ama hesap verebilirlik ve raporlama için yeterli alan tutun. En azından: sahip (kişi veya rol), lokasyon/asset, son tarih, öncelik, kök neden (seçim listesi artı isteğe bağlı metin), çözüm notları ve durum.
Sahibi zorunlu yapın ve sahip yokken ne olacağını kararlaştırın (örnek: varsayılan olarak saha süpervizörüne ata).
Yükseltme (escalation) kuralları öngörülebilir olmalıdır. Hatırlatmalar ne zaman gider ve kim bilgilendirilir açıkça yazılmalı. Örnek: son tarihten önce bir hatırlatma, son tarihte bir gecikme bildirimi, sonra tanımlı gün sayısından sonra yükseltme.
Senaryo: bir denetçi Mağaza 14'te "El yıkama lavabo sabunu var" maddesini Fail olarak işaretler ve fotoğraf ekler. Uygulama otomatik olarak Yüksek öncelikli bir işlem oluşturur, sahibi "Vardiya lideri" olur, 4 saat içinde tamamlanması istenir ve önerilen kök neden "Stok bitti".
İşlemlerin kendi kendine kapanmasına izin vermeyin. Düzeltmenin kanıtı olarak yeni bir fotoğraf, bir not veya her ikisini de gerektiren bir doğrulama adımı ekleyin. Kimlerin doğrulayabileceğini tanımlayın (aynı denetçi, süpervizör veya sahibinden farklı birisi) ve imza ile zaman damgası gerektirin.
Açık bir geçmiş zorunludur. Sahip, son tarih, durum ve notlardaki her değişiklik kimin ne zaman değiştirdiğiyle birlikte kaydedilmelidir. AppMaster'da Business Process Editor ve dahili mesajlaşma entegrasyonları, atamalar, hatırlatmalar ve doğrulama kapıları için temiz bir eşleme yapabilir ve denetlenebilirliği korur.
Spesifikasyonu iki yolculuk etrafında yazın: sahadaki denetçi ve döngüyü kapatan süpervizör. Her ekranı adlandırın, ne gösterdiğini ve ilerlemeyi hangi durumların engellediğini belirtin.
Basit bir akış: site ve denetim tipini seç, kontrol listesi sürümünü onayla, sonra maddeleri tek tek tamamla. Her madde görünümü "bitti"nin ne olduğunu (cevap, isteğe bağlı not ve gerekliyse kanıt) açıkça göstermelidir.
Ekran setini sıkı tutun: site seçici, kontrol listesi genel görünümü (ilerleme ve eksik zorunlu maddeler), madde detay (cevap, notlar, fotoğraf çekme, N/A), gözden geçir ve gönder (özet, puan, eksik gereksinimler).
Doğrulamalar açık olmalıdır. Örnek: bir madde Fail olarak işaretlenip kanıt zorunluysa, kullanıcı en az bir fotoğraf eklemeden gönderemez. Sinyal kaybı sırasında denetimin devam etmesi ve çevrimdışı çalışma gibi uç durumları belirtin.
Süpervizörlerin site, tarih, denetçi, başarısız maddelere göre filtrelenebilen bir inceleme kuyruğuna ihtiyacı vardır. Bir sonuçtan yeniden çalışma isteyebilmeli, onaylayabilmeli ve bir desen ortaya çıktığında ekstra işlemler ekleyebilmelidir.
Bildirimler spesifikasyonda yer almalıdır:
AppMaster'da inşa ediyorsanız, ekranları web ve mobil UI oluşturucularına eşleyin ve "gönderilemez" kurallarını Business Process mantığında zorunlu kılın ki her yerde tutarlı olsun.
Raporlama üç soruyu hızlıca yanıtlamalı: ne başarısız oluyor, nerede oluyor ve sıradaki işi kim yapmalı. Bir rapor birkaç dakikada bir karara yol açmıyorsa, göz ardı edilir.
Günlük kullanım için operatif görünümlerle başlayın:
Filtrelemeyi görünür yapın. Ekipler genellikle site, kontrol listesi tipi, tarih aralığı, puan aralığı ve sahibe göre dilimlemek ister. Eğer sadece bir kısayol yapacaksanız, "son 7 gün içinde Site X'te düşük puanlar" olsun.
Eğilim raporları için basit bir grafik ile düz sayıları eşleştirin: tamamlanan denetimler, ortalama puan ve başarısız sayısı. İki "neden bulun" raporu ekleyin: tüm denetimler genelinde en çok başarısız olan maddeler ve site bazında tekrarlayan sorunlar (aynı madde haftadan haftaya başarısız oluyor).
Dışa aktarmalar önemlidir çünkü sonuçlar uygulama dışında paylaşılır. Her rolün neyi dışa aktarabileceğini ve nasıl (CSV analiz için, PDF paylaşım için) tanımlayın. Zamanlanmış teslimat destekliyorsanız, rol tabanlı erişimi gözettiğinden emin olun ki yöneticiler sadece kendi sitelerini alsın.
Örnek: bölge operasyon yöneticisi Site B'nin ortalama puanının 92'den 81'e düştüğünü görür, sonra "en çok başarısız olan maddeler"i açar ve "temizlik kayıtlarının eksik" maddesinin tekrarladığını bulur. Bir düzeltici işlem site sahibine atanır ve sorun durana kadar haftalık özet gönderimi planlanır.
AppMaster'da inşa ediyorsanız, rapor ekranlarını filtreler, toplamlar ve en fazla bir grafik ile odaklı tutun. Önce sayılar, sonra görseller.
Güveni kaybetmenin en hızlı yolu dünün sonuçlarının bugün değişmiş görünmesidir. Bu genellikle şablon düzenlemelerinin geçmiş denetimleri yeniden yazmasından kaynaklanır. Şablonları sürümlü dokümanlar olarak ele alın. Sonuçlar her zaman kullanılan kesin sürüme işaret etmelidir.
Puanlama sessizce bozulabilir. Kurallar bir tablo gerektiriyorsa ve uzun açıklamalar gerekiyorsa insanlar puanı kullanmayı bırakır ve tartışmaya başlar. Puanlamayı zeminde bir dakikada açıklanabilir olacak kadar basit tutun ve her puanın spesifik cevaplara dayanmasını sağlayın.
Kanıt kuralları katı ve öngörülebilir olmalıdır. Yaygın hata "fotoğraflar isteğe bağlı" denilip denetimlerde fotoğraf beklenmesidir. Bir soru fotoğraf veya imza gerektiriyorsa, gönderimi engelleyin ve nedenini sade bir dille açıklayın.
Düzeltici işlemler sahip belirsizliğinde başarısız olur. Spesifikasyonunuz zorunlu bir atama ve son tarih gerektirmiyorsa, maddeler sonsuza kadar "açık" kalır. Kapanış açık olmalıdır: bir düzeltme doğrulanana kadar tamamlanmış sayılmaz; notlar ve gerekirse yeni fotoğraflar ile doğrulama gerekir.
Bağlantı durumu saha gerçeğidir, uç durum değil. Denetçiler bodrumlarda, tesislerde veya uzak sahalarda çalışıyorsa, çevrimdışı öncelikli davranış baştan spesifikasyona konmalıdır.
İnceleme sırasında dikkat edilmesi gereken temel tuzaklar:
AppMaster'da modelliyorsanız, aynı ilkeler geçerlidir: şablon sürümlerini sonuçlardan ayırın ve kanıt ile düzeltici işlemleri not değil gerçek kayıtlar olarak tutun.
Ekip ekranlarda anlaşsa ama hangi durumun geçerli bir denetim sayılacağı, neyin kanıtlanması gerektiği ve hangi durumun takip işi tetikleyeceği konusunda anlaşmazsa bir spesifikasyon dağılır.
Bu maddeleri netleştirin:
Hızlı bir akıl sağlığı kontrolü olarak gerçekçi bir senaryoyu kağıt üzerinde yürütün. Örnek: bir süpervizör Pazartesi 9:10'da Mağaza 12'yi denetler, "soğutucu sıcaklığı" (kritik) başarısız olur, bir fotoğraf ekler, gönderir ve bir düzeltici işlem mağaza yöneticisine Çarşamba için atanır. Şimdi sorun: her anda denetim durumu nedir, hangi puan gösterilir, kim neyi düzenleyebilir ve haftalık raporda ne görünür gibi soruları cevaplayın.
Sonraki adımlar tam geliştirmeden önce doğrulamaya odaklanmalıdır. Veri modelini ve ana iş akışlarını prototipleyin ki eksik alanlar, kafa karıştırıcı izinler ve rapor boşlukları ortaya çıksın.
Hızlı bir no-code hızında ilerlemek isterseniz, AppMaster (appmaster.io) bu işi prototiplemek için pratik bir yerdir: Data Designer'da varlıkları modelleyin, Business Process Editor ile iş akışını zorunlu kılın ve mobil ekranları ve raporlamayı tam açmadan önce doğrulayın.
What’s the difference between an inspection, an audit, and a spot check in the spec?Use one main term for the routine activity and stick to it everywhere. Most teams call the frequent, shift-based work an inspection, reserve audit for less frequent formal reviews, and treat spot checks as a lighter inspection with fewer required fields rather than a separate system.
Why do I need both checklist templates and inspection runs?A template defines the questions, rules, and scoring, and an inspection run is one completed instance tied to a site, time, and person. Keeping them separate prevents old results from changing when you edit the checklist later.
How should checklist versioning work so reports stay auditable?Create a new published version whenever the checklist changes and make every inspection store the exact version it used. Lock editing on published versions so you can improve the checklist without rewriting history during audits or disputes.
What’s a practical scoring model that won’t cause arguments later?Pick one approach that a supervisor can explain quickly and document the rules in plain language. Save both the raw answers and the computed score so you can reproduce the number later even if scoring rules evolve.
How should N/A answers affect the score?The safest default is to exclude N/A items from the denominator so the score reflects only applicable checks. Also store the N/A reason so reviewers can tell whether it was valid or used to dodge a hard question.
What should happen when a “critical” question fails?Decide up front whether a critical failure forces the whole inspection to fail or simply caps the score, and apply it consistently. Make the critical flag part of the checklist definition so it is not a subjective choice during the run.
When should the app require photo proof, and how do we handle offline capture?Require photos only when they prevent debate, such as for failed items or high-risk checks, and show the requirement before the user answers. For field conditions, treat each photo as a queued upload that can be captured offline and synced later with a clear upload status.
What fields must a corrective action include to avoid “open forever” issues?Create actions as first-class records that can be assigned, tracked, and verified independently from the inspection. At minimum, require an owner, due date, priority, and status so nothing sits in limbo with unclear accountability.
How do we enforce verification and keep a clear history of changes?Do not allow actions to close without a verification step, ideally with new evidence or a clear note and a timestamped sign-off. Keep an audit trail of who changed the owner, due date, status, and notes so you can reconstruct what happened later.
What reports matter most for operations, and how should we structure them?Focus reports on decisions people make daily: what is failing, where it is failing, and who needs to act next. If you build in AppMaster, keep reporting screens simple with strong filters and persist the key computed fields, like final score and overdue days, so queries stay fast and consistent.
21 Oca 2026
8 dk
20 Oca 20268 dk
20 Oca 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
