Hafta sonu kılavuzu: elektronik tablo iş akışını bir uygulamaya taşıyın—veri temizliği, veritabanı modelleme, rol tabanlı ekranlar, otomasyonlar ve güvenli yayına alma.
Elektronik tablolar izlemek için iyidir. İnsanlar bunları bir süreci işletmek için kullanmaya başladığında dağılıverir: talepler gelir, onaylar olur, iş devredilir ve birinin her şeyi elle “doğru” tutması beklenir.
İlk çatlaklar genellikle görünmezdir. İki kişi aynı satırı düzenler, bir filtre kayıtları gizler ve “en son” sürüm birinin e-posta eki olarak yaşar. Sonra çoğaltmalar olur (“Bu yeni bir talep mi yoksa aynı mı?”), karışık formatlar (tarihler, durumlar, öncelikler) ve satır oluşturulurken “açık” olan eksik alanlar ortaya çıkar.
Sahiplik de bulanıklaşır. Bir sütunda “Assignee” yazıyorsa ama herkes bunu değiştirebiliyorsa gerçek bir hesap verebilirlik yoktur. Bir şey ters gittiğinde temel sorulara cevap vermek zordur: Durumu kim değiştirdi? Ne zaman “Tamamlandı” oldu? Neden yeniden açıldı?
Bir üretim uygulaması kuralları değiştirir. Paylaşılan bir ızgara yerine net izinler, tek bir doğruluk kaynağı, bir denetim izi ve otomasyon (durum değişiklikleri mesajlar ve görevler tetikleyebilir) elde edersiniz. En önemlisi, iş akışı tek bir dikkatli kişiye bağlı kalmaz.
Hedefiniz bir hafta sonu içinde elektronik tablo iş akışını bir uygulamayla değiştirmekse gerçekçi olun: mükemmel sistemi değil, ilk kullanılabilir sürümü inşa edin. “Kullanılabilir”, birinin bir talep gönderebilmesi, başka birinin bunu işleyebilmesi ve ekibin manuel peşinde koşmadan nelerin yapıldığını görebilmesi demektir.
Şimdi taşınması gerekenleri ve bir süre elektronik tabloda kalabilecekleri ayırın. Çekirdek kayıtları ve en çok acı veren adımları taşıyın (giriş, durum, sahiplik, teslim tarihleri). İyi-to-have raporlama, tarihsel temizlik ve uç vaka alanlarını sonraya bırakın.
AppMaster gibi araçlar burada yardımcı olur çünkü veriyi modelleyebilir, rol tabanlı ekranlar ekleyebilir ve temel otomasyonları kod yazmadan kurup birinci günden sonra yineleyebilirsiniz.
Elektronik tablo iş akışını değiştirmek için en hızlı yol ilk sürümü küçük ve dürüst tutmaktır. Amaç mükemmellik değil; Pazartesi günü insanlarınızın size mesaj atmadan kullanabileceği çalışan bir akıştır.
İş akışını yeni bir iş arkadaşına açıklıyormuş gibi düz adımlarla yazın. Kim başlatır, kim gözden geçirir ve “tamam” ne demektir belirtin. Elektronik tabloda çok sayıda sekme ve yan kurallar varsa bir ana yol (yüzde 80 vakayı kapsayan) seçin ve şimdilik uç vakaları görmezden gelin.
Sonra çekirdek kayıtlarınızı adlandırın. Sistemi 3 ila 5 isimle tarif edemiyorsanız, hafta sonu için çok büyüktür. Bir operasyon takipçisi Requests, Customers, Approvals ve Comments gibi şeylere indirgenebilir. Diğer her şey (etiketler, ekler, özel alanlar) bekleyebilir.
Hafta sonu kapsamı örneği:
Herhangi bir şeyi inşa etmeden önce uygulamanın saniyeler içinde cevaplaması gereken soruları yazın: Durum nedir? Bunu kim sahipleniyor? Bu hafta ne teslim edilecek? Ne engelleniyor ve kim tarafından? Bu sorular ilk ekranlarınızı ve filtrelerinizi şekillendirecek.
Pazartesi sabahı için başarı kriterlerini tanımlayın ki ne zaman duracağınızı bilin:
AppMaster’da inşa ediyorsanız bu kapsam hızlı bir Data Designer modeli, birkaç rol tabanlı sayfa ve çekirdek devretme için tek bir Business Process'e düzgünce uyar.
Bir hafta sonunda bunu yapmak istiyorsanız, en hızlı kazanım temiz veridir. Çoğu içe aktarma sıkıcı nedenlerle başarısız olur: karışık tarih formatları, sayı alanlarında “TBD” ve aynı anlama gelen üç sütun.
Önce elektronik tablonun bir yedeğini alın ve tarihle adlandırın. Sonra kimsenin tabloyu düzenlemediği kısa bir dondurma penceresi planlayın (30–60 dakika bile yardımcı olur). Düzenlemeler devam etmesi gerekiyorsa, bunları “new changes” adında ayrı bir sekmede yakalayın ki daha sonra uzlaştırabilesiniz.
Şimdi her sütunu uygulamanın gerçek bir alan olarak ele alabileceği şekilde standartlaştırın:
Çoğaltmalar ve eksik kimlikler diğer yaygın engeldir. Kararlı tanımlayıcınızın ne olduğunu belirleyin (çoğunlukla ardışık bir ID veya oluşturulmuş UUID). Satır numaralarını kimlik olarak kullanmaktan kaçının çünkü satırlar hareket eder. İki satır aynı gerçek nesneyi temsil ediyorsa şimdi birleştirin ve neyi değiştirdiğinizi not edin.
Yeni bir sekmede küçük bir veri sözlüğü oluşturun: her alan, ne anlama geldiği, örnek değer ve kimin “sahibi” olduğu (kimin doğruyu söyleyebileceği). Bu, tabloları kurarken zaman kazandırır.
Son olarak hangi sütunların hesaplanan, hangilerinin saklanan olduğunu işaretleyin. Toplamlar, “açık gün sayısı” ve SLA bayrakları genelde uygulamada hesaplanır. Sadece sonra denetlenmesi gerekenleri saklayın (ör. orijinal talep tarihi).
Bir elektronik tablo tek bir ızgara olduğu için işe yarar. Bir uygulama her “şey”in kendi tablosu olduğu ve ilişkilerin bağladığı için çalışır. Burada dağınıklık istikrarlı bir temele dönüşür.
Her ana sayfayı bir tablo olarak ele alın; her kaydın bir satırı olsun. Birleştirilmiş hücrelerden, boş başlık satırlarından ve veri içinde “toplam” satırlarından kaçının. Hesaplama olan her şey daha sonra bir görünüm veya rapor olarak yeniden yapılabilir.
Basit bir kural: bir sütun birçok satırda aynı türde bir değeri tekrarlıyorsa, aynı tabloda olmalıdır. Bir sayfa esas olarak değerleri aramak için varsa (takımlar listesi gibi) bu bir referans tablodur.
Yaygın ilişkiler, sade terimlerle:
Referans listeleri verinizi temiz tutar. Durumlar, kategoriler, ekipler, lokasyonlar veya öncelik seviyeleri için ayrı tablolar yapın ki insanlar yeni varyantlar yazmak yerine listeden seçebilsin.
Elektronik tablolar değişiklikleri gizler. Uygulamalar bunları kaydedebilir. Durum değişiklikleri önemliyse bir StatusHistory tablosu ekleyin (RequestId, OldStatusId, NewStatusId, ChangedBy, ChangedAt). Onaylar için de aynı şekilde ekleme yapın; kimin neyi ne zaman onayladığı kanıtı gerekir.
AppMaster’ın Data Designer'ında (PostgreSQL) inşa etmeden önce elektronik tablo sütunlarını alanlara eşleyen basit bir harita yazın:
Bu tek sayfalık harita içe aktarma sürprizlerini önler ve sonraki adımları (ekranlar, izinler, otomasyonlar) çok daha hızlı yapmanızı sağlar.
İzinler elektronik tablo iş akışlarının genellikle başarısız olduğu yerdir. Herkes her şeyi düzenleyebiliyorsa, sessiz değişiklikler, kazara silmeler ve net bir sahiplik olmaz.
Dört rol ile başlayın ve bunları sade tutun:
Ardından satır düzeyinde erişim kurallarını basit cümlelerle tanımlayın:
Onaylar yeni bir uygulamanın güvenilir hissetmesini sağlayan emniyet ağıdır. Onaylanması gereken 1 veya 2 işlemi seçin, geri kalanını esnek bırakın. Yaygın seçimler: bir isteği kapatma, anlaşmadan sonra teslim tarihini değiştirme, bir bütçe/fiyat alanını düzenleme veya öğe silme. Kimin onaylayacağını (genelde Manager, yedek olarak Admin) ve onaylandığında ne olacağını (durum değişikliği, zaman damgası, onaylayan adı) belirleyin.
Hızlıca test edebileceğiniz minimal bir matris: Contributor'lar kendi sahip oldukları Draft ve In Progress öğelerini oluşturup düzenleyebilir; Manager'lar takımın herhangi bir öğesini düzenleyip onaylayabilir; Viewer'lar hiçbir şeyi düzenleyemez; Admin'ler tüm işlemleri, kullanıcı yönetimi dahil, yapabilir.
No-code bir araç kullanıyorsanız (ör. AppMaster), izinleri erken inşa edip “kötü gün” senaryosuyla test edin: bir Contributor başka birinin öğesini düzenlemeye çalışıyor, bir Viewer durum değiştirmeye çalışıyor ve bir Manager değişikliği onaylıyor. Her vaka beklendiği gibi davranıyorsa temeliniz sağlam demektir.
İnsanların her gün dokunduğu üç ekranla başlayın: liste, detay sayfası ve oluşturma/düzenleme formu. Bunlar hızlı ve tanıdık gelirse benimseme daha kolay olur.
İyi bir liste sayfası bir soruyu hızlıca cevaplar: "Sırada ne yapmalıyım?" İnsanların bir elektronik tabloda taradığı ana sütunları gösterin (başlık, durum, sahip, öncelik, teslim tarihi) ve her satırı tıklanabilir yapın.
Detay sayfasında tek doğruluk kaynağı okunabilir olsun. Ana alanları üstte, destekleyici bilgileri altta koyun. Tartışmalar bu sayfada durur çünkü herkes aynı kaydı görüyor.
Form için amaç daha az karar, daha çok netlik olmalı. Alanları gruplandırın, girdileri doğrulayın ve gönderme eylemini belirgin yapın.
Çoğu “yavaş uygulama” çok fazla tıklama zorlayarak yavaş hissettirir. Mantıklı varsayılanlar ayarlayın (status = New, owner = mevcut kullanıcı, teslim tarihi = +3 gün). Zorunlu alanları kısa ipuçlarıyla işaretleyin (“Yönlendirme için gerekli”).
Filtreler gerçek sorularla eşleşmeli, her alanla değil. Yaygın filtreler durum, sahip, tarih aralığı ve önceliktir. Uygun ise üstte küçük bir özet ekleyin (duruma göre sayılar, artı Geciken sayısı) ki insanlar iki saniyede değer görsün.
Güven oluşturmak için basit bir etkinlik kaydı ekleyin: kim neyi ne zaman değiştirdi. Örnek: “Öncelik Medium'dan High'a değiştirildi — Sam, 14:14.” Bu geri dönüşleri önler ve devretmeleri yumuşatır.
Elektronik tablodaki “iş akışı” genellikle insanların kafında yaşar: hangi sütunu kim günceller, ne zaman ve neyin tamamlandığı ne demek. Bir uygulamada amaç basit: sonraki adımı belirgin hale getirmek ve hatalı adımı zorlaştırmak.
İlk olarak sürecinizi net durumlara haritalayın. Kısa ve eylem odaklı tutun:
Sonra veri kalitesini koruyan kurallar ekleyin. Temel alanları zorunlu kılın (requester, teslim tarihi, öncelik). İzin verilen geçişleri zorunlu kılın (Submitted'tan doğrudan Completed'a atlanamaz). Bir şey benzersiz olmalıysa bunu zorlayın (ör. dış bilet numarası).
AppMaster'da bu mantık Business Process Editor'da doğal olarak yerleşir: her karar için bir blok, net adlarla. Her adımı isimlendirmek ve bir amaç cümlesi eklemek iyi bir alışkanlıktır, örneğin: "Onayı ver: sadece manager onaylayabilir ve maliyet alanlarını kilitler." Böylece geri döndüğünüzde okunabilir kalır.
Sonra iş akışının kendini çalıştırması için tetikleyiciler tanımlayın:
Baştan geri alma planı yapın. Bir adım başarısız olursa (ör. bildirim servisi kapalıysa) kaydı yarım bırakmayın. Ya kaydetmeden önce hatayı gösterin, ya da durum değişikliğini kaydedip başarısız eylemi tekrar denemeye kuyruğa alın ve kaydı "needs_attention" ile işaretleyin.
Somut örnek: bir istek Approved durumuna geçtiğinde önce onaylayan adı ve zamanı kaydedin, sonra bildirimi gönderin. Bildirim başarısız olursa onay yine geçerli olsun ve uygulama yeniden göndermek için bir banner göstersin.
Amaç daha fazla bildirim değil; birinin gerçekten bir şey yapması gerektiğinde bildirim göndermektir.
Öncelikle gecikmelere her zaman sebep olan anları seçin. Çoğu ekip yalnızca üç-dört bildirim türüne ihtiyaç duyar:
Aciliyete göre kanalları seçin. Çoğu güncelleme için e-posta uygundur. Zaman duyarlı meseleler için SMS; hızlı iç koordinasyon için Telegram işe yarayabilir. AppMaster’da bunları durum değişiklikleri veya teslim tarihlerine göre dahili mesaj modülleriyle bağlayabilirsiniz.
Mesajları kısa ve eylem odaklı yapın. Her bildirimde alıcının kaydı hızlıca bulabilmesi için net bir tanımlayıcı olsun, bağlantı olmasa bile. Örnek: “REQ-1842: Vendor erişim onayı gerekli. Bugün teslim. Mevcut adım: Security review.”
Gürültüyü azaltmak için haftalık özet gibi günlük bir özet sunun; bu tür FYI güncellemeleri için uygundur. İnsanların rollere göre abone olmasına izin verin (onaylayanlar, yöneticiler) yerine herkese göndermeyin.
Ayrıca ne zaman bildirim göndermeyeceğinize dair kurallar yazın:
Bir bildirim bir sonraki adımı söylemiyorsa, o mesaj özet içinde olmalı.
Geçişi bir kopyala-yapıştır işi değil, mini bir sürüm olarak ele alın. Veriyi bir kere taşıyın, doğru tutun ve yeni uygulama Pazartesi açıldığında insanların beklediğiyle eşleşsin.
Her şeyi taşımadan önce küçük bir test içe aktarma ile başlayın. 20–50 temsilî satır içeren bir CSV dışa aktarın; içinde bazı dağınık örnekler olsun (boş hücreler, tuhaf tarihler, özel karakterler). Modellediğiniz tablolara içe aktarın ve her sütunun doğru alana düştüğünü onaylayın.
Test içe aktarmadan sonra üç şeyi doğrulayın:
Hafta sonu projelerinin çoğu burada kazanır veya başarısız olur. 5.000 satır içe aktardıktan sonra değil, şimdi eşlemeyi düzeltin.
Sonra ilişkilerin mantıklı olduğunu kontrol edin. Elektronik tablo ile uygulama arasındaki sayımları karşılaştırın (ör. Requests ve Request Items). Lookupların çözüldüğünden emin olun ve yetim kayıtları (var olmayan bir isteğe referans veren öğeler) arayın.
Uç vakalarda hızlı spot kontroller yapın: null olması gereken boş değerler, virgül veya tırnak içeren isimler, uzun notlar ve karışık tarih formatları.
Son olarak elektronik tablonun izin verdiği belirsizlikleri ele alın. Tablo "birisi" veya boş sahip bırakmışsa şimdi kimin sahip olacağına karar verin. Gerçek bir kullanıcı atayın veya varsayılan bir kuyruk belirleyin ki hiçbir şey takılı kalmasın.
Test sonuçları temizse tüm veriyle içe aktarmayı tekrarlayın. Sonra uzlaştırın: rasgele 10–20 kayıt seçin ve tam hikayenin eşleştiğini doğrulayın (durum, atanan kişi, zaman damgaları, ilişkili kayıtlar). Bir şey yanlışsa geri alıp nedeni düzeltin ve tekrar içe aktarın; el ile yamalamayın.
Bir zamanlar tek bir elektronik tablo sekmesinde yaşayan basit bir operasyon talep takipçisi hayal edin. Her satır bir taleptir ve sütunlar sahibi, durum, onay notları gibi her şeyi yakalamaya çalışır. Amaç aynı işi sürdürmek, ama kırılması daha zor hale getirmek.
Temiz bir uygulama versiyonu genelde bir ana tablo (Requests) ve birkaç destekleyici tablo (People, Teams, StatusHistory, Attachments) içerir. İş akışı tanıdıktır: Intake -> Triage -> Approval -> Done. Fark, uygulamanın doğru eylemleri doğru kişiye göstermesidir.
Gün birinde her rol devasa ızgara yerine odaklanmış bir görünüm alır:
Manuel peşin takibi ortadan kaldıran bir otomasyon: bir istek Waiting for approval durumuna geldiğinde, onaylayana istek özeti ile bir bildirim gider ve 24 saat içinde kalırsa yedek onaylayıcıya veya operasyon liderine yükseltilir.
Elektronik tablodaki filtrelemeyi değiştiren bir rapor: haftalık Ops yükü görünümü, istekleri duruma göre, her aşamada ortalama süreyi ve sahibine göre geciken öğeleri gösterir. AppMaster'da bu, kaydedilmiş sorgularla desteklenen basit bir pano sayfası olabilir.
İstisnalar uygulamanın değer kattığı yerdir. Ad-hoc düzenlemeler yerine bunları açık yapın:
Yayın günü özelliklerden çok güvenle ilgilidir. İnsanlar erişim doğruysa, veri doğru görünüyorsa ve yardım almak için net bir yol varsa geçiş yaparlar.
Sıkı bir kontrol listesi çalıştırın ki Pazartesi'yi yangın söndürmeyle geçirmeyesiniz:
Bunun ardından yeni bir kullanıcının yapacağı gibi duman testi yapın. Bir kayıt oluşturun, düzenleyin, onaya gönderin, arayın ve filtrelenmiş görünümü dışa aktarın. İnsanlar telefon kullanacaksa en yaygın iki veya üç işlem için mobil erişimi test edin (gönder, onayla, durum kontrol et).
Eğitimi kısa tutun. Mutlu yolunu bir kez gösterin, sonra bir sayfalık bir kılavuz verin: “Talebi nereye girerim?”, “Bekleyen işimi nasıl görürüm?”, “Tamamlandığını nasıl anlarım?” sorularının cevapları olsun.
İlk hafta için basit bir destek planı belirleyin. Bir soru soracak kişi, bir yedek kişi ve sorun bildirmek için bir yer seçin. Rapor edenlerden ekran görüntüsü, kayıt ID'si ve beklenen davranışı eklemelerini isteyin.
Uygulama stabil olduğunda gerçek kullanım verilerine göre küçük iyileştirmeler planlayın: temel raporlar ekleyin (hacim, çevrim süresi, darboğazlar), hataların sık yaşandığı yerlerde doğrulamayı sıkılaştırın, atladığınız entegrasyonları bağlayın (ödeme, mesajlaşma, diğer araçlar) ve bildirimleri daha az ama daha eyleme çağıran şekilde azaltın.
Eğer hızlıca inşa edip yayınlamak istiyorsanız ve ağır kodlama yapmak istemiyorsanız, AppMaster (appmaster.io) PostgreSQL veritabanı modellemesi, rol tabanlı web ve mobil ekranlar oluşturma ve iş akışı otomasyonlarını tek bir yerde kurma için pratik bir seçenektir.
Elektronik tablomun bir “iş akışı” haline gelip uygulamaya ihtiyaç duyduğunu nasıl anlarım?Elektronik tablolar listeleri takip etmek için uygundur, ancak bir süreci aynı anda birden çok kişi işletmeye başladığında kırılgan hale gelir. Sahiplik, onaylar ve neyin ne zaman değiştiği belirsizleşir; filtreler, yinelenen satırlar ve üzerine yazılan hücreler gibi küçük hatalar gerçek gecikmelere dönüşür.
Elektronik tablo iş akışını değiştirmek için gerçekçi bir “hafta sonu yapımı” kapsamı nedir?Gerçekçi bir hafta sonu MVP'si, birinin talep gönderebilmesini, bir başkasının bunu işleyebilmesini ve ekibin manuel takip olmadan neler üzerinde çalışıldığını görmesini sağlar. Bir ana kayıt, kısa bir durum akışı, üç temel ekran (liste, detay, form) ve en büyük darboğazı ortadan kaldıracak bir otomasyonla sınırlayın.
Önce neyi taşımalıyım, neyi bir süre elektronik tabloda bırakabilirim?Çekirdek kayıtları ve en çok acı veren adımları taşımalısınız: giriş, durum, sahiplik ve teslim tarihleri. Raporlama, tarihsel temizlik ve uç vaka alanlarını daha sonra bırakın, böylece hızla yayına geçip kullanıcı geri bildirimine göre iyileştirebilirsiniz.
Veriyi en hızlı nasıl temizleyip düzgün içe aktarılır hale getiririm?Her sütunun tek bir anlamı ve tek bir formatı olacak şekilde veriyi standartlaştırın. Karışık tarih formatlarını düzeltin, sayısal alanlardan “TBD” gibi değerleri kaldırın, izin verilen durum değerlerini tanımlayın, çakışma varsa hangi sütunun geçerli olduğunu belirleyin ve satır numarası olmayan kararlı bir kimlik (ID) oluşturun.
Elektronik tablo sekmelerini ve sütunlarını veritabanı modeline nasıl çeviririm?İzlediğiniz “şeyleri” isimlendirin ve her birini bir tabloya dönüştürün; sonra bunları ilişkilerle bağlayın. Örneğin Requests tabloları Customers, Users (atananlar) ve StatusHistory gibi tablolarla ilişkilendirilebilir, böylece kim neyi ve ne zaman değiştirdiğini görebilirsiniz.
İlk olarak hangi roller ve izinler kurulmalı?İlk sürüm için basit tutun: dört rol (Admin, Manager, Contributor, Viewer). "Contributors kendi sahip oldukları öğeleri düzenleyebilir" ve "Managers onaylayabilir" gibi net kurallar yazın ve izinlerin çalıştığından emin olmak için kötü gün senaryolarını test edin.
Kullanım için hangi ekranları ilk öncelikli yapmalıyım?İnsanların gerçekten kullanacağı üç ekranı oluşturun: üzerinde çalışılması gerekenleri gösteren bir liste sayfası, tek kaynak olarak işleyen bir detay sayfası ve girdileri doğrulayan bir oluşturma/düzenleme formu. Varsayılanlar (status = New, owner = current user) ile tıklama sayısını azaltın.
İş akışı mantığını elektronik tablo kaosunu yeniden üretmeden nasıl kopyalarım?Gerçek elden ele teslimleri yansıtacak küçük bir durum seti seçin ve temel kuralları zorunlu kılın (zorunlu alanlar, izin verilen geçişler). Önemli değişiklikler için bir denetim izi tutun ve adımlar yarım kalmayacak şekilde hataları ele alın.
İlk günde hangi otomasyonlar ve bildirimler eklemeye değer?Birinin harekete geçmesi gerektiğinde bildirim gönderin: yeni atama, onay bekleyen öğe veya geciken işler gibi. Mesajlar kısa ve eyleme çağırır nitelikte olsun, bir kayıt tanımlayıcısı içersin ve küçük düzenli güncellemeler için günlük özetler kullanın.
Her şeyi bozmadan güvenle geçiş yapıp canlıya almak için en güvenli yol nedir?Küçük bir test içe aktarma yapın, alan tiplerini ve ilişkileri doğrulayın, sonra tüm veri setini içe aktarın ve sayımları eşleştirin. Yayına almadan önce rollerle izinleri test edin, bildirimleri uçtan uca doğrulayın ve geri alma planınızı yazılı hale getirin.
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.
