No-code otomasyon mu, özel yazılım mı? İş akışında karar rehberi

No-code otomasyon, tekrar eden bir iş akışını kod yazmadan, hazır bir aracın görsel ekranında kurmaktır. Hızlı başlar, ama hacim, dallanan kurallar, hata yönetimi ve hassas veri arttıkça zorlanır. Özel yazılımla otomasyon daha geç başlar; buna karşılık kurallar, veri ve kod, sözleşmeyle şirketinizin olur. Süreci denerken no-code, süreç oturup büyüdüğünde özel yazılım genellikle daha sağlam bir seçimdir.

Ben bu kararda ilk olarak iki şey sorarım: otomasyon kime ait olacak ve bir adım bozulduğunda bunu kim, ne kadar sürede fark edecek? Bu rehberi sipariş, fatura girişi, gelen talebi doğru kişiye yönlendirme, rapor ve bildirim gibi tekrar eden işleri otomatikleştirmek isteyen bir KOBİ sahibi ya da operasyon sorumlusu için yazdım. Araçları adıyla anmıyorum, çünkü kararın ölçütleri araçtan bağımsızdır. Mevzuata ve fiyatlandırma modellerine dair her bilgi Ekim 2026 itibarıyla geçerlidir.

No-code otomasyon nedir, özel yazılımla otomasyondan farkı ne?

No-code otomasyon, bir iş akışını kod yazmadan, hazır bir aracın görsel ekranında bir tetikleyiciyi ve adımları birbirine bağlayarak kurmaktır. Tetikleyici akışı başlatan olaydır: yeni bir sipariş, gelen bir e-posta ya da doldurulan bir form. Adımlar ardından gelen işlerdir: veriyi bir tabloya yazmak, ekibe bildirim göndermek, bir kaydı muhasebe programına aktarmak. Kod yazmadan otomasyon kuran bu araçların bulut sürümlerinde akış, aracı sağlayan şirketin sunucularında çalışır; bazıları kendi sunucunuza da kurulabilir. Ekim 2026 itibarıyla bu kategorideki birçok araç aylık abonelikle ve çalıştırma ya da görev sayısına bağlı kotalarla satılıyor.

Low-code araçlar aynı görsel yaklaşıma sınırlı miktarda kod eklemeye izin verir. Hazır ürün ile özel geliştirme arasındaki bu ara yolu özel yazılım mı hazır yazılım mı rehberinde ayrıca ele aldık; burada yalnızca tekrar eden işlerin otomasyonuna bakıyorum.

Özel yazılımla otomasyon ise aynı akışın şirketiniz için yazılmış kodla kurulmasıdır. Kod deposu, çalıştığı sunucu ya da bulut hesabı ve çalıştırma kayıtları şirketinizin adına açılabilir; bunu sözleşmeye yazdırmanızı öneririm. Kurallar bir aracın ayar ekranıyla sınırlı kalmaz; kodda yapılan her değişikliği kimin, ne zaman yaptığını kaydeden sürüm kontrolüyle yönetilir ve yayından önce test edilir.

Üçüncü bir yol daha var: işi elle ya da bir tabloyla yapmaya devam etmek. Hacim küçükse bu yol sanıldığından daha makul olabilir. Ben üç yolu da geçerli sayarım; hangisinin uygun olduğunu aracın kendisi değil, sürecin hacmi ve bir hatanın size maliyeti belirler.

Robotik süreç otomasyonu (RPA) nedir, ne zaman kötü bir seçimdir?

Robotik süreç otomasyonu (RPA), bir yazılım robotunun ekranda bir insan gibi tıklayıp yazarak işi yapmasıdır: bir programı açar, alanları okur, değerleri başka bir programa kopyalar. Başka programlara düzenli veri veren bir arayüzü (API) olmayan eski bir masaüstü programından veri almak için bazen tek pratik yoldur. Zayıf noktası ekrana bağımlı olmasıdır. Bir düğmenin yeri, bir pencerenin adı ya da ekran çözünürlüğü değiştiğinde robot yanlış yere tıklayabilir ya da durabilir.

Ben RPA'yı geçici bir köprü olarak görürüm. Hedef sistemin bir API'si varsa ya da yakında olacaksa, ekranı taklit eden bir robotu kalıcı çözüm olarak kurmam. Arayüzü sık güncellenen web uygulamaları, hız gerektiren yüksek hacimli işler ve hatanın sessiz kalmaması gereken finansal aktarımlar, RPA'nın zayıf kaldığı durumlardır.

No-code, özel yazılım ve elle yapılan iş aynı ölçütlerde nasıl karşılaştırılır?

Bir iş akışında özel yazılım, hazır no-code araç ve elle yapılan iş en sağlıklı biçimde aynı sekiz ölçütle karşılaştırılır: kurulum hızı, hacimle artan ücret, sınırlar, veri konumu, hata yönetimi, bakım ve test, entegrasyon ve sahiplik. Tablo, üç yolu bu sekiz ölçüte göre yan yana koyuyor.

Üç yolun karşılaştırmasının özeti şöyle: no-code araç başlangıçta en hızlı yoldur, elle yapılan iş en ucuz başlangıçtır, özel yazılım ise uzun vadede kuralları, maliyeti ve veriyi en çok kontrol ettiğiniz yoldur. Benim için en önemli iki satır "Hata yönetimi ve izleme" ile "Sahiplik ve çıkış" satırlarıdır. İkisi de ilk haftalarda görünmez, ilk ciddi aksaklıkta ya da aracı değiştirmek istediğinizde ise belirleyici olur.

No-code otomasyon ne zaman yeterli, ne zaman zorlanmaya başlar?

No-code otomasyon, süreci denemek istediğinizde, hacim düşük olduğunda ve akışı bir kişi izlediğinde iyi bir ilk adımdır. Hacim, dallanan kurallar, hata yönetimi ihtiyacı, hassas veri ve akışı düzenleyen kişi sayısı arttıkça zorlanmaya başlar. Bir süreci ilk kez otomatikleştiren bir şirkete, kurallar netleşmeden kod yazdırmayı önermem.

Hangi durumlarda hazır no-code araçla başlamalı?

• Süreci deniyorsanız: Bir bildirimin ya da aktarımın gerçekten zaman kazandırıp kazandırmadığını görmek istiyorsanız, birkaç günlük bir deneme, haftalar süren bir projeden daha hızlı cevap verir.
• Hacim düşükse: Akış günde birkaç kez çalışıyorsa görev kotası ve aylık ücret genellikle sorun olmaz.
• Akışı bir kişi izliyorsa: Bir adım başarısız olduğunda bunu fark edip elle düzeltecek biri varsa, gelişmiş hata yönetimine henüz ihtiyacınız yoktur.
• Veri hassas değilse: Akış kişisel veri ya da ticari sır taşımıyorsa, verinin nerede işlendiği sorusu sadeleşir.
• Sistemlerinizin hazır bağlantısı varsa: Kullandığınız programlar araçta zaten listeleniyorsa, entegrasyon için kod gerekmez.

No-code otomasyonun sınırına geldiğinizi gösteren işaretler

No-code otomasyonun sınırı, akış büyüdükçe ortaya çıkan şu işaretlerle belli olur. Tek başına hiçbiri taşınma sebebi değildir, ama birlikte göründüklerinde aracın başka bir ayarını aramak yerine hesap yapmak gerekir.

• Hacim büyüdü: Ücret görev kotasıyla birlikte her ay artıyor ve gelecek ayın faturasını tahmin etmek zorlaşıyor.
• Kurallar dallandı: Akış "eğer şu ise" adımlarıyla dolup kimsenin tamamını açıklayamadığı bir şemaya dönüştü.
• Hatalar sessiz kalıyor: Bir adım başarısız olduğunda bunu ekipten önce müşteri ya da muhasebe fark ediyor.
• Hassas veri girdi: Akış artık müşterilerin kimlik ve ödeme bilgilerini ya da sağlık gibi özel nitelikli kişisel verileri (KVKK md. 6) taşıyor.
• Çok kişi düzenliyor: Birden fazla kişi akışı doğrudan canlıda değiştiriyor ve neyin, kim tarafından, ne zaman değiştirildiği belli değil.

No-code sınır işaretlerinden ikisini (hacim, dallanan kurallar, sessiz hatalar, hassas veri, çok kişinin düzenlemesi) aynı anda gördüğümde, özel yazılımın üç ila beş yıllık toplam maliyetini hazır aracın büyüyen aboneliğiyle yan yana koymayı öneririm. İş akışınız hâlâ bir Excel dosyasında duruyorsa, önce Excel'den yazılıma geçiş rehberindeki işaretlere bakmak daha doğru bir başlangıç olabilir.

Dört yaygın KOBİ akışı hangi yola uyar?

Dört yaygın KOBİ akışı, aynı ölçütlerle değerlendirildiğinde farklı yollara düşer. Bu eşleştirmeler kesin bir kural değil, ilk tahmin için bir başlangıçtır; kendi hacminiz ve bir hatanın size maliyeti sonucu değiştirebilir.

• Yeni sipariş bildirimi: Siparişi ekibe bir mesajla iletmek basit ve düşük riskli bir akıştır; hazır bir no-code araç ya da satış altyapınızın kendi bildirimi yeterlidir.
• Tedarikçi faturasını muhasebeye girmek: Tutar, vergi ve cari hesap eşleştirmesi hata kaldırmaz; hacim düşükse kontrollü elle giriş, hacim büyüdüğünde tekrarı önleyen ve hata kuyruğu olan özel bir akış daha güvenlidir.
• Gelen talebi doğru kişiye yönlendirmek: Kurallar az ve sabitse kodsuz otomasyon iyi bir başlangıçtır; yönlendirme bölgeye, ürüne ve müşteri geçmişine göre dallanmaya başladığında kuralları koda taşımaya değer.
• Haftalık rapor: Birkaç tablodan özet çıkarmak için elle hazırlanan bir şablon ya da hazır bir araç yeterlidir; rapor birden çok sistemi birleştiriyor ve yönetim kararları ona dayanıyorsa, kurumsal bir panelde otomatik üretilen rapor daha tutarlıdır.

Özel yazılımla otomasyon hangi durumda kazanır ve bedeli nedir?

Özel yazılımla otomasyon, süreç oturduğunda, hacim büyüdüğünde, kurallar işinize özgü olduğunda ve verinin ve kodun şirketinizde kalması gerektiğinde kazanır. Bedeli ise daha uzun bir ilk sürüm, şirket içinde bir sahip ve sürekli bakımdır. Ben bu noktaya gelmiş bir süreçte şu avantajları belirleyici bulurum:

• Kurallar işinize uyar: İndirim, onay, stok ya da yönlendirme kuralı bir aracın ayar ekranına sığdırılmaya çalışılmaz; olduğu gibi koda yazılır ve test edilir.
• Çalıştırma başına lisans ücreti yoktur: Sunucu ve dış servis maliyeti hacimle artar, ama görev ya da çalıştırma başına bir lisans ücreti ödemezsiniz ve maliyet öngörülebilir kalır.
• Veri seçtiğiniz yerde durur: Sunucunun bulunduğu ülkeyi siz seçersiniz; bu, KVKK'daki yurt dışına aktarım kararını sizin elinize verir; ancak akışın çağırdığı dış servisler (e-posta, yapay zekâ adımı) yurt dışındaysa aktarım yine doğar.
• Kendi sistemlerinize doğrudan bağlanır: İç veritabanınız, ERP'niz, muhasebe programınız ya da kendi yönetim paneliniz, bir hazır bağlantı listesine girmeyi beklemeden entegre edilir.
• Değişiklik hızı sizin elinizdedir: Bir kural değiştiğinde bir ürünün yol haritasını beklemezsiniz; değişiklik test edilip yayına alınır.
• Kod ve sunucu sizin adınıza kayıtlı olur: Bunu sözleşmeye yazdırdığınızda, yazılım ekibini değiştirseniz bile sistem şirketinizle kalır ve başka bir ekibe devredilebilir.

Özel yazılımla otomasyonun bedelinin teklifte açıkça yazılmasından yanayım. İlk sürüm no-code bir akıştan daha uzun sürer, çünkü keşif, yazılı kapsam, test ve izleme kurulumu gerekir. Sistemin şirket içinde bir sahibi olmalıdır: kuralları onaylayacak ve değişiklik isteyecek biri. Bir de süreklilik bedeli vardır; bağlandığı sistemler güncellendikçe kodun da bakımı gerekir.

Ekim 2026 itibarıyla yapay zekâ destekli geliştirmeyi, özel yazılımın kurulum maliyetini düşürebilen bir etken olarak görüyorum. Tekrar eden kod, testler ve entegrasyon iskeletleri daha kısa sürede yazılabiliyor. Bu, mühendis incelemesini, testi ve güvenlik kontrolünü ortadan kaldırmıyor; yalnızca no-code ile özel yazılım arasındaki ilk maliyet farkını daraltıyor. Yapay zekâyla yazılan kodun nerede yeterli olduğunu yapay zekâ ile uygulama nasıl yapılır yazısında ayrıca ele aldım.

Bir akışın içinde serbest metni okuyup sınıflandırmak gerekiyorsa, örneğin gelen bir e-postanın sipariş mi şikâyet mi olduğunu ayırmak için, akışa bir yapay zekâ adımı eklenebilir. Kural tabanlı bir akışın ne zaman yettiğini, ne zaman bir yapay zekâ ajanı gerektiğini yapay zekâ ajanı nedir yazısında anlattım.

Otomasyonda bir adım gece 3'te hata verirse ne olur?

Bir otomasyonda bir adım gece 3'te hata verdiğinde ne olacağı, kurulum sırasında verilmiş kararlara bağlıdır: akış ya sessizce durur, ya aynı işi iki kez yapar ya da hatayı kaydedip birine haber verir. Örneğin, her yeni siparişte muhasebe programında taslak bir fatura açan bir akışınız olduğunu ve muhasebe programının gece yarım saatliğine bakıma girdiğini varsayalım.

Muhasebe programı bakımdayken hazırlıksız bir otomasyonda o yarım saatte gelen siparişlerin faturası hiç açılmaz ve bunu sabah kimse fark etmez. Ya da akış yeniden denediğinde bazı siparişler için ikinci bir fatura açar. Ben bir otomasyonun kalitesini en çok bu senaryoda ölçerim, çünkü her şeyin yolunda gittiği gün her akış çalışır. İyi bir hata yönetimi şu parçalardan oluşur:

1. Yeniden deneme: Geçici bir hatada adımı belirli aralıklarla, sınırlı sayıda yeniden denemek.
2. Tekrarı önleme: Adım yeniden çalışsa bile aynı sipariş için ikinci bir fatura açılmasını engelleyen kontrol; yazılımcılar buna idempotency der.
3. Hata kuyruğu: Yeniden denemelere rağmen başarısız olan işlerin kaybolmadan beklediği ve sonra işlendiği liste.
4. Alarm: Hata eşiği aşıldığında doğru kişiye e-posta ya da mesajla haber verilmesi.
5. Çalıştırma kaydı: Her çalıştırmanın ne zaman, hangi veriyle ve hangi sonuçla bittiğinin aranabilir kaydı.

Hazır no-code araçlarda yeniden deneme, tekrarı önleme, hata kuyruğu, alarm ve çalıştırma kaydından hangilerinin bulunduğu araca ve pakete göre değişir. Deneme hesabında bilerek bir hata üretip ne olduğunu görmenizi öneririm. Özel yazılımda ise bu parçaların kapsam dokümanına yazılmasını isterim; yazılmayan bir davranışın test edilmesi de zorlaşır.

Otomasyonda veri nerede durur, KVKK açısından neye bakılmalı?

Otomasyonda verinin nerede durduğu, hazır bir aracın sunucuları yurt dışındaysa KVKK'nın yurt dışına aktarım kuralını doğrudan ilgilendirir. 6698 sayılı Kişisel Verilerin Korunması Kanunu'nun (KVKK) 9. maddesi, 2 Mart 2024 tarihli ve 7499 sayılı Kanunla değiştirildi; Kanunun güncel metni (yeni sekmede açılır) Mevzuat Bilgi Sistemi'nde yayımlanıyor. Ekim 2026 itibarıyla yürürlükteki metne göre kişisel veriler, işleme şartlarından biri varsa ve aktarılacak ülke için Kişisel Verileri Koruma Kurulu'nun bir yeterlilik kararı bulunuyorsa yurt dışına aktarılabilir.

KVKK'nın 9. maddesine göre yeterlilik kararı yoksa, ilgili kişinin aktarılan ülkede de haklarını kullanabilmesi ve etkili kanun yollarına başvurabilmesi, ayrıca standart sözleşme gibi uygun güvencelerden birinin taraflarca sağlanması gerekir. Standart sözleşme, imzalanmasından itibaren beş iş günü içinde Kişisel Verileri Koruma Kurumu'na bildirilir. KVKK'nın 12. maddesi ise veri sorumlusuna uygun güvenlik düzeyi için teknik ve idari tedbirleri alma yükümlülüğü verir. Veri sorumlusu, kişisel verileri kendi adına başka bir kişi ya da şirkete işletiyorsa, bu tedbirlerden o kişiyle birlikte müştereken sorumludur.

Pratikte ben bir otomasyon aracına kişisel veri vermeden önce üç şeyi sorarım: veri hangi ülkede işleniyor ve saklanıyor, sağlayıcıyla hangi aktarım güvencesi kuruluyor ve çalıştırma kayıtlarında kişisel veri ne kadar süre tutuluyor. Özel yazılımda sunucunun bulunduğu ülke sizin kararınızdır. Bu, KVKK yükümlülüklerini kaldırmaz ama aktarımın gerekip gerekmediğini baştan belirlemenizi sağlar. Bu bölüm bilgi amaçlıdır, hukuki görüş değildir; kendi durumunuz için bir hukukçudan görüş alın.

Otomasyonun maliyetini ve süresini ne belirler?

Bir otomasyonun maliyetini ve süresini en çok şu etkenler belirler: bağlanan sistemler, kuralların dallanması, hata yönetimi beklentisi, verinin hassasiyeti ve hacim. Bu etkenleri teklif istemeden önce yazıya dökmek, gelen fiyatları karşılaştırılabilir kılar.

• Bağlanan sistemler: Belgelenmiş bir API'si olan sistem hızlı bağlanır; API'si olmayan eski bir program süreyi uzatır ve bazen RPA gibi kırılgan bir köprü gerektirir.
• Kuralların dallanması: Her istisna, örneğin iade, kısmi sevkiyat ya da farklı bir vergi oranı, yeni bir yol ve yeni testler demektir.
• Hata yönetimi beklentisi: Yeniden deneme, tekrarı önleme ve alarm kurmak ilk sürümü uzatır ama sonraki aylarda elle düzeltme maliyetini düşürür.
• Verinin hassasiyeti: Kişisel veri; yetki, kayıt ve saklama kuralları ekler.
• Hacim: No-code tarafında abonelik kademesini, özel yazılımda sunucu ve kuyruk tasarımını belirler.

Kararı sınamak için üç yolun üç ila beş yıllık toplamını kendi rakamlarınızla yan yana koymanızı öneririm: hazır aracın bugünkü ve iki katı hacimdeki aylık ücreti, özel yazılımın kurulum ve yıllık bakım bedeli, elle yapılan işin personel saati. Gelen teklifleri birbiriyle karşılaştırmak için yazılım yaptırma maliyeti rehberindeki sorular işinize yarar.

Otomasyon görüşmesine hangi sorularla gitmeli, hangi hatalardan kaçınmalı?

Otomasyon görüşmesinde sorulacak temel sorular şunlardır: akış neyle başlıyor ve ayda kaç kez çalışıyor, bir adım bozulunca ne oluyor, veri hangi ülkede işleniyor, akışı kim değiştirebiliyor ve hizmetten çıkışta veri nasıl alınıyor. İster bir aracın satış ekibiyle ister bir yazılım firmasıyla konuşun, aynı listeyle gitmek cevapları karşılaştırmayı kolaylaştırır. Ben bu listeyi görüşmeden önce doldurulmuş bir süreç tarifiyle birlikte götürmeyi öneririm; süreci tek sayfada anlatmak için yazılım brief şablonu iyi bir başlangıçtır.

Otomasyon görüşmesi için kontrol listesi

1. Akış hangi olayla başlıyor, hangi adımlardan geçiyor, sonunda ne üretiyor?
2. Ayda kaç kez çalışacak ve bir yıl sonra kaç kez çalışması bekleniyor?
3. Bir adım başarısız olunca ne oluyor: yeniden deneme, tekrarı önleme, alarm ve hata kuyruğu var mı?
4. Veri hangi ülkede işleniyor ve saklanıyor, çalıştırma kayıtları ne kadar süre tutuluyor?
5. Akışı kim değiştirebilir, değişiklikler nerede kayıt altına alınıyor, yayından önce nasıl test ediliyor?
6. Bağlanacak her sistem için hazır bağlantı mı, API mi kullanılacak, yoksa ekrandan mı okunacak?
7. Hizmeti bırakırsak akış, kayıtlar ve veri nasıl dışa aktarılır; özel yazılımda kod deposu ve sunucu kimin adına?
8. Ücret hacimle nasıl değişiyor ve iki katı hacimde aylık bedel ne olur?

Otomasyon projelerinde sık yapılan hatalar

• Süreci düzeltmeden otomatikleştirmek: Karışık bir süreç otomasyonla hızlanır ama düzelmez; önce adımları sadeleştirmek gerekir.
• Akışın sahibini belirlememek: Akışı kuran kişi ayrıldığında kimse akışın ne yaptığını bilmez.
• Yalnızca başarılı senaryoyu test etmek: Akış her şeyin yolunda gittiği durumla denenir ve ilk kesintide sessizce durur.
• Canlıda düzenlemek: Test ortamı olmadan yapılan bir değişiklik, müşteriye giden mesajı ya da faturayı doğrudan etkiler.
• Ücreti bugünkü hacimle hesaplamak: Büyüme planı varken kotayı bugünkü sayıya göre seçmek, birkaç ay sonra maliyet sürprizi yaratır.
• Ekran tıklayan robotu kalıcı sanmak: RPA ile kurulan köprü, hedef programın arayüzü değişene kadar çalışır.

Otomasyon projelerindeki bu hatalar içinde bana göre en pahalısı, akışın sahibini belirlememektir. Kimse izlemediğinde bozulan bir otomasyon, ancak bir müşteri şikâyet ettiğinde fark edilir.

Biz olsak ne yapardık?

UlvionTech olarak biz, tekrar eden bir iş akışını önce yazıya döker, kuralları dar bir denemeyle netleştirir ve süreç oturduğunda kalıcı kısmı özel yazılımla kurardık. Önce akışın hangi olayla başladığını, kimin neyi elle yaptığını, nerede hata çıktığını ve ayda kaç kez tekrarlandığını yazardık. Kurallar henüz belirsizse dar bir deneme önerirdik; bu deneme hazır bir no-code araçla da olabilir, küçük bir betikle de.

Deneme oturduğunda ve sınır işaretlerinden ikisi görüldüğünde, kalıcı akışı şirketinizin adına açılan bir kod deposunda, test, izleme ve hata kuyruğuyla birlikte yazardık. Yazılı kapsam olmadan fiyat vermiyoruz; kapsam yazıya döküldüğünde fiyat sabittir ve geliştirme iki haftalık döngülerle, her döngüde deneyebileceğiniz çalışan bir sürümle ilerler. Yapay zekâ ve süreç otomasyonu hizmetimiz bu sırayı izler ve kararlaştırılan bir destek dönemiyle biter.

Benim kişisel tercihim, ilk kalıcı sürümde yalnızca en sık tekrarlanan ve hatası en pahalı olan akışı yazmak, geri kalanını bir süre hazır araçta bırakmaktır. Hibrit bir düzen, her şeyi bir anda taşımaktan daha güvenli bir geçiştir. Akışın içinde yapay zekâ adımı varsa, ilk 90 günün nasıl planlanacağını şirketlerde yapay zekâ otomasyonu rehberinde adım adım anlattık.

Hangi durumlarda bizimle çalışmamalısınız?

Otomasyon ihtiyacınız küçükse, hazır bir araç işinizi görüyorsa ya da ekibinizde bu işi üstlenebilecek bir geliştirici varsa, UlvionTech ile çalışmanıza gerek yoktur. Bunu açıkça söylemeyi tercih ederim, çünkü küçük bir ihtiyaç için kurulan özel bir sistem, bütçeyi asıl gerektiği yerden çeker.

• Akış basit ve düşük hacimliyse: Bir formu bir tabloya ve bir bildirime bağlamak için keşif, yazılı kapsam ve iki haftalık döngüler gereğinden ağırdır; hazır bir araç yeterlidir.
• Süreç henüz belli değilse: Kurallar her hafta değişiyorsa, önce elle ya da hazır bir araçla denemek daha ucuzdur; koda dökülecek kural henüz yoktur.
• Şirket içinde bir geliştiriciniz varsa: Bu işi üstlenecek bir ekibiniz varsa, ona bu rehberdeki hata yönetimi ve sahiplik listesini vermeniz yeterli olabilir.
• Akışın bir sahibi olmayacaksa: Kimse kuralların doğruluğundan sorumlu olmayacaksa, özel yazılım da bir süre sonra sahipsiz kalır; önce bir sorumlu belirleyin.

Otomatikleştirmek istediğiniz bir süreç varsa, adımlarını ve ayda kaç kez tekrarlandığını iletişim formundan yazın; hazır bir aracın mı, özel bir otomasyonun mu size uyduğunu açıkça söyleriz.