En İyi Otomasyon Firması Nasıl Seçilir? İş Süreçleri İçin Rehber

“En iyi otomasyon firması” araması iki farklı pazarı aynı sonuçlarda gösterebilir. Bir tarafta PLC, SCADA, robotik, sensör ve makine kontrolüyle çalışan endüstriyel otomasyon firmaları; diğer tarafta CRM, ERP, e-posta, WhatsApp ve özel yazılımları bağlayan iş süreci otomasyonu ekipleri vardır. Yanlış kategoriden teklif istemek zaman kaybettirir ve gerçek ihtiyacı görünmez kılar.

Kısa yanıt: Önce fiziksel üretim hattını mı, yoksa ekiplerin ekranlar arasında yürüttüğü bilgi ve onay akışını mı otomatikleştirdiğinizi belirleyin. İş yazılımı otomasyonu için firmaları süreç analizi, API entegrasyonu, istisna yönetimi, güvenlik, insan onayı, toplam maliyet ve taşınabilirlik üzerinden karşılaştırın.

Endüstriyel Otomasyon mu, İş Süreci Otomasyonu mu?

Alan	Tipik kapsam	Aranacak uzmanlık
Endüstriyel otomasyon	Makine, üretim hattı, PLC, SCADA, sensör, robotik, saha güvenliği	Elektrik/elektronik, kontrol mühendisliği, makine güvenliği ve saha devreye alma
İş süreci otomasyonu	CRM, ERP, sipariş, belge, e-posta, WhatsApp, onay ve raporlama	Süreç analizi, API, veri modeli, sunucu tarafı geliştirme, erişim kontrolü ve izleme
Hibrit proje	Üretim verisinin ERP/CRM ve yönetim raporlarına bağlanması	İki alan arasında tanımlı sorumluluk ve entegrasyon mimarisi

Bir üretim makinesinin güvenli çalışması gerekiyorsa yalnız web yazılımı deneyimi yeterli değildir. Bir satış talebinin WhatsApp’tan CRM’e aktarılması gerekiyorsa da PLC markaları ve pano tecrübesi tek başına doğru yetkinlik değildir. Hibrit projede hangi ekibin saha sistemi, hangi ekibin iş yazılımı ve veri akışından sorumlu olduğunu sözleşmede ayırın.

Bu rehber Niwera’nın çalışma alanıyla uyumlu olarak iş yazılımı ve iş süreci otomasyonuna odaklanır; endüstriyel makine güvenliği veya PLC/SCADA tedarikçisi seçme rehberi değildir.

1. Süreci Ekranlardan Önce Haritalayın

“CRM’i ERP’ye bağlayalım” teknik bir yön gösterir ama iş sonucunu tanımlamaz. Önce başlangıç olayını, gerekli veriyi, karar noktalarını, beklenen çıktıyı ve istisnaları yazın.

Örnek sipariş akışı:

1. Müşteri talebi gelir.
2. Müşteri ve ürün kaydı doğrulanır.
3. Fiyat, stok ve teslimat bilgisi yetkili kaynaktan alınır.
4. Eksik bilgi müşteriden veya ekipten istenir.
5. Sipariş taslağı insan onayına sunulur.
6. Onay sonrası kayıt oluşturulur.
7. İşlemin gerçekten oluştuğu doğrulanır.
8. Hata varsa kuyruğa ve sorumlu ekibe aktarılır.

Teklif yalnız 1 ile 6 arasındaki mutlu yolu anlatıyorsa eksiktir. Mükerrer mesaj, yanlış müşteri eşleşmesi, API kesintisi, stok çelişkisi ve onay gecikmesi de kapsamda değerlendirilmelidir.

2. Hazır Ürün, Kodsuz Platform veya Özel Yazılım Kararını Açıklayın

Her süreç için sıfırdan yazılım gerekmez. Hazır bağlayıcı veya kodsuz platform hızlı başlangıç sağlayabilir; özel sunucu tarafı yazılımı ise karmaşık iş kuralları, yüksek kontrol ihtiyacı veya mevcut sistemlerdeki sınırlamalar için gerekli olabilir.

Firmadan neden seçtiği yaklaşımın uygun olduğunu şu başlıklarla açıklamasını isteyin:

• Kurulum ve değişiklik hızı.
• API ve veri hacmi sınırları.
• Kullanıcı, iş akışı ve işlem başına lisanslar.
• Sürüm değişikliklerinin etkisi.
• Test ve devreye alma süreci.
• Tedarikçiye bağımlılık ve dışa aktarma seçenekleri.
• Kurum içi ekibin sistemi devralabilme düzeyi.

“En yeni araç” bir iş gerekçesi değildir. Araç seçimi süreç, risk, ekip yetkinliği ve toplam maliyetle ilişkilendirilmelidir.

3. Entegrasyon Sözleşmesini Alan Alan Tanımlayın

API bağlantısı kurmak, veri sorumluluğunu çözmez. CRM’deki müşteri telefonu ile ERP’deki teslimat adresi çelişirse hangi kaynak esas alınacak? Bir sipariş iptal edildiğinde diğer sistemde ne kadar sürede görünmeli? Hangi alan tek yönlü, hangisi çift yönlü güncellenmeli?

Microsoft’un data unification dokümantasyonu, kaynak alanlarının seçimi, yinelenen kayıtların bulunması, eşleştirme ve birleşik görünüm adımlarını ayrı ele alır. Belirli bir CRM ürünü kullanmasanız da bu ayrım entegrasyon teklifini değerlendirmek için yararlıdır.

Teklif ekinde şu tabloyu isteyin:

Alan	Ana kaynak	Akış yönü	Güncelleme sıklığı	Çelişki kuralı	Hata sahibi
Müşteri telefonu	CRM	Çift yönlü	Olay bazlı	En son doğrulanmış kayıt	Satış operasyonu
Sipariş durumu	ERP	ERP → CRM	Olay bazlı	ERP değeri geçerli	Sipariş operasyonu

Tablodaki örnek değerler kendi sisteminiz için karar değildir. Ama teklifin hangi ayrıntı seviyesine ulaşması gerektiğini gösterir.

4. Hata Yönetimi ve Gözlemlenebilirlik

Otomasyon yalnız çalıştığında değil, çalışmadığında da yönetilebilir olmalıdır. Firma şu durumları nasıl ele alacağını göstermelidir:

• Aynı olayın iki kez gelmesi.
• İstek zaman aşımına uğradığında işlemin gerçekte tamamlanmış olma ihtimali.
• İstek sınırı ve geçici servis kesintisi.
• Değişen API alanları veya kimlik doğrulama yöntemi.
• Eksik ya da beklenmeyen veri.
• İnsan onayının süresinde gelmemesi.
• Yanlış işlemi geri alma veya telafi etme.

Her yeniden deneme güvenli değildir. Müşteriye mesaj gönderme veya sipariş oluşturma gibi dış etkili işlemlerde işlem kimliği ve gerçek sonuç doğrulanmadan tekrar çalıştırmak mükerrer kayıt üretebilir. Hata kuyruğu, uyarı, sorumlu kişi ve manuel düzeltme ekranı teklifin parçası olmalıdır.

5. Güvenlik ve Yetkiyi İş Akışı Seviyesinde İnceleyin

Otomasyon hesabına “yönetici” yetkisi vermek kolay ama risklidir. Her API aracı için gereken en düşük okuma/yazma izinlerini tanımlayın. Gizli anahtarların nerede tutulduğunu, erişimlerin nasıl yenilendiğini ve eski çalışan/tedarikçi hesaplarının nasıl kapatıldığını sorun.

CISA Software Acquisition Guide, tedarikçilerin güvenli geliştirme, zafiyet yönetimi, üçüncü taraf bileşenler ve olay süreçleri hakkında değerlendirilmesine yönelik ayrıntılı bir soru seti sunar. Küçük bir otomasyon projesi için tüm maddeler aynı ağırlıkta olmayabilir; veri ve işlem riskine göre uyarlanmalıdır.

AI ajanı işleme karar veriyorsa ek riskler vardır. OWASP’ın LLM uygulamaları risk listesi hassas bilgi açıklanması ve aşırı yetkilendirme başlıklarını içerir. Model girdisini talimat olarak kabul edip yetkisiz işlem yapmamalı; araç çağrıları doğrulama ve yetki kontrolünden geçmelidir.

6. İnsan Onayı ve Manuel Çalışma Yolu

İnsan onayı yalnız yüksek tutarlı ödeme gibi belirgin işlemlerde değil, belirsiz müşteri eşleşmesi ve sıra dışı fiyat talebi gibi durumlarda da gerekebilir. Şunları netleştirin:

• Hangi işlem hangi rolden onay ister?
• Onay ekranı karar için gerekli bağlamı gösteriyor mu?
• Reddedilen işlem nasıl kaydediliyor?
• Sistem kapalıyken ekip işi manuel sürdürebiliyor mu?
• Otomasyon tekrar açıldığında manuel kayıtlarla nasıl uzlaşıyor?
• Acil durumda bir acil durdurma veya yetki kapatma yolu var mı?

Amaç her adımı insana onaylatmak değildir. Yanlış işlemin etkisi ile otomasyonun hız faydasını birlikte değerlendirip doğru kontrol noktasını seçmektir.

7. WhatsApp ve CRM Tekliflerinde Ek Sorular

WhatsApp otomasyonu, mesaj ekranından daha geniştir. WhatsApp Business Messaging Policy, opt-in, iletişimi durdurma talepleri, belirli durumlarda onaylı message template kullanımı ve otomasyonda açık insan desteği yolları gibi koşullar içerir. Güncel platform fiyatı, template kategorileri ve sağlayıcı ücretleri toplam maliyete ayrıca eklenmelidir.

WhatsApp teklifi için sorun:

• Resmî WhatsApp Business Platform yolu mu kullanılıyor?
• Meta ücretleri ile sağlayıcı ücretleri ayrı gösteriliyor mu?
• Opt-in kaynağı ve zamanı nerede tutuluyor?
• 24 saatlik hizmet penceresi dışında template akışı nasıl yönetiliyor?
• İnsan devrinde konuşma özeti ve kontrol edilen kayıtlar aktarılıyor mu?

CRM entegrasyonu için sorun:

• Aynı müşteriyi eşleştirme kuralı nedir?
• Olası eşleşme otomatik birleşiyor mu, incelemeye mi gidiyor?
• Yanlış birleşme geri alınabiliyor mu?
• İletişim izni ile müşteri profili ayrı kayıtlar olarak korunuyor mu?
• Senkronizasyon hatası kullanıcıya nerede gösteriliyor?

Daha ayrıntılı uygulama örnekleri için WhatsApp otomasyonu rehberini ve CRM entegrasyonu rehberini inceleyebilirsiniz.

8. Toplam Maliyet ve Güvenilir Üst Sınır

Teklifte yalnız proje kurulum bedelini değil, en az 12 aylık işletim varsayımını görün:

Toplam maliyet = analiz + kurulum + özel geliştirme + lisans + API/işlem ücretleri + barındırma + izleme + destek + iç ekip zamanı + bakım + çıkış

Kullanıma bağlı maliyetlerde ortalama tahminin yanında güvenilir bir üst sınır isteyin. Üçüncü taraf sağlayıcının fiyatı kontrol edilemiyorsa bütçe uyarısı, istek sınırı, kullanım kotası veya otomatik durdurma gibi teknik kontrolleri değerlendirin. Tahmin, harcama limiti değildir.

Değişiklik talebinin nasıl fiyatlandığını da sorun. İlk kapsamda olmayan her alan eşleştirmesi veya iş akışı adımı ayrı ücretleniyorsa küçük düzeltmeler toplam maliyeti büyütebilir.

9. Taşınabilirlik, Dokümantasyon ve Çıkış

Otomasyonun çalıştığı platform değişebilir; firma da bir gün hizmet vermeyebilir. Çıkış planı şu varlıkları kapsamalıdır:

• İş akışı tanımları ve dışa aktarılabilir yapılandırma.
• Kaynak kodu ve kullanım hakları.
• API şemaları, olay bildirimi sözleşmeleri ve alan eşleştirmeleri.
• Veri sözlüğü, gizli anahtar envanteri ve erişim devir planı.
• Test senaryoları ve bilinen istisnalar.
• Sistem kayıtları ve işlem geçmişinin erişilebilir formatı.
• Üçüncü taraf hesaplarının kime ait olduğu.
• Devir desteğinin süresi ve bedeli.

Taşınabilirlik, her aracın anında değiştirilebilmesi değildir. Bağımlılıkların görünür olması ve geçiş maliyetinin karar öncesinde anlaşılmasıdır.

Teklifte Sorulacak 15 Soru

1. Bu proje endüstriyel otomasyon mu, iş süreci otomasyonu mu, hibrit mi?
2. Tek cümlelik iş sonucu ve başlangıç ölçümü nedir?
3. Kapsama girmeyen sistemler ve işlemler hangileri?
4. Hangi sistem her veri alanının ana kaynağıdır?
5. API yoksa hangi yöntem kullanılacak ve kırılma riski nedir?
6. Mükerrer olay ve yarım kalan işlem nasıl önlenecek?
7. Hata kuyruğunu kim izleyecek, kim düzeltecek?
8. Her bağlantı için gereken en düşük yetkiler nelerdir?
9. Hangi işlemler insan onayı gerektirir?
10. Üçüncü taraf platformlar ve alt yükleniciler hangileridir?
11. Aylık maliyet hangi işlem hacmine dayanıyor?
12. Kullanım artarsa güvenilir üst sınır veya durdurma kontrolü nedir?
13. Kabul testi hangi senaryolarla ve hangi veriyle yapılacak?
14. Veri, iş akışı ve kod sözleşme sonunda nasıl teslim edilecek?
15. Canlı destek, bakım ve kritik hata yanıt süresi nedir?

Aynı Puan Kartıyla Karşılaştırın

Ölçüt	Örnek ağırlık
Süreç ve kapsam uyumu	%20
Entegrasyon mimarisi	%15
Hata yönetimi ve işletim	%15
Güvenlik ve veri sorumluluğu	%15
İnsan kontrolü	%10
Toplam maliyet	%15
Taşınabilirlik ve dokümantasyon	%10

Bu ağırlıklar ölçülmüş pazar verisi değildir; teklifleri aynı çerçevede değerlendirmek için başlangıç hipotezidir. İşlem riski, sistem kritiklik seviyesi ve kurum içi yetkinliğe göre değiştirin.

Küçük Ama Gerçek Bir Akışla Kanıt İsteyin

Demo için yalnız örnek mesaj kullanmayın. Kişisel verilerden arındırılmış gerçekçi kayıtlar, bir API kesintisi, bir mükerrer olay ve bir insan onayı senaryosu ekleyin. Pilot sonunda yalnız çalışan ekranı değil; test sonucu, hata listesi, gerçekleşen maliyet, işletim sorumluluğu ve çıkış teslimlerini değerlendirin.

Niwera’nın sipariş ve tedarik, WhatsApp ve CRM örnekleri iş yazılımı otomasyonunun farklı parçalarını simülasyon olarak gösterir. Bunlar gerçek müşteri sonucu veya belirli bir verimlilik artışı iddiası değildir.

Kaynaklar

• CISA: Software Acquisition Guide — Supplier Response Tool
• OWASP: Top 10 for Large Language Model Applications
• Microsoft Learn: Data Unification Overview
• WhatsApp Business Messaging Policy
• NIST: Artificial Intelligence Risk Management Framework — Generative AI Profile

Bu yazı iş süreci otomasyonu için genel seçim rehberidir. Endüstriyel makine güvenliği, mevzuat, hukuk veya bilgi güvenliği değerlendirmesinin yerine geçmez ve belirli bir firmayı “en iyi” ilan etmez.