Özel yazılım ne zaman gerekir?
- PROBLEM
- PROCESS
- BUY vs BUILD
- INTEGRATION
- MVP
- MEASURE
- SCALE
Her işletmenin özel yazılıma ihtiyacı yoktur.
Özel geliştirme daha çok şu durumlarda anlamlı hale gelir:
- işletmenin workflow’u piyasadaki yazılımlara uymuyorsa,
- birden fazla sistem arasında veri taşınması gerekiyorsa,
- manuel işler yüksek zaman kaybı oluşturuyorsa,
- özel yetkilendirme gerekiyorsa,
- çok şubeli operasyon varsa,
- standart raporlar yönetim ihtiyacını karşılamıyorsa,
- mevcut sistemlere API entegrasyonu gerekiyorsa,
- işletmeye özel müşteri/hasta yolculuğu varsa.
Ne zaman özel yazılım yapmamak gerekir?
Bir problem piyasadaki güvenilir bir ürünle düşük maliyetle çözülebiliyorsa sıfırdan geliştirme gereksiz olabilir.
Örneğin:
- basit CRM,
- proje yönetimi,
- muhasebe,
- e-posta,
- standart ticket sistemi
için güçlü hazır ürünler bulunabilir.
Amaç:
yazılım yaptırmak değil, problemi çözmek.
Hazır sistem + özel katman
Birçok projede en verimli çözüm hibrittir.
Örneğin:
CRM + özel API + WhatsApp entegrasyonu + özel dashboard + otomasyon
birlikte kullanılabilir.
Böylece zaten çözülmüş problemler yeniden yazılmaz.
Özel geliştirme yalnız işletmeye özgü bölümde yapılır.
Kliniklerde hangi işler otomatikleştirilebilir?
Örnekler:
- yeni lead atama,
- cevapsız lead uyarısı,
- randevu hatırlatma,
- takip görevi,
- doküman talebi,
- temsilci yönlendirme,
- şube routing,
- UTM kaydı,
- teklif hazırlama akışı,
- yönetici onayı,
- günlük rapor,
- duplicate kontrol,
- webhook işlemleri.
Her otomasyon yararlı değildir.
Tekrar eden ve açık kurallı işler önce değerlendirilmelidir.
Manuel iş maliyeti
Bir personel günde:
20 kez × 3 dakika
aynı bilgiyi iki sistem arasında taşıyorsa:
günde 60 dakika
yalnız bu işlemde harcanıyor olabilir.
Ayda yüzlerce manuel tekrar varsa entegrasyon maliyeti anlamlı hale gelebilir.
Ama önce gerçek kullanım ölçülmelidir.
İş akışı nasıl analiz edilir?
Bir süreci şu formatta çıkarıyorum:
INPUT
İş nereden başlıyor?
ACTOR
Kim yapıyor?
ACTION
Ne yapıyor?
DECISION
Hangi koşulda yol değişiyor?
OUTPUT
Sonuç nedir?
NEXT
Sonraki adım ne?
Bu harita olmadan otomasyon geliştirmek hata riskini artırır.
Kötü süreci otomatikleştirmeyin
Bir süreç zaten kötü tasarlanmışsa otomasyon onu daha iyi hale getirmeyebilir.
Sadece daha hızlı kötü süreç üretir.
Bu nedenle önce:
- gereksiz adımları kaldır,
- sorumluluğu belirle,
- veri alanlarını sadeleştir,
- istisnaları tanımla,
sonra otomatikleştir.
API nedir?
API farklı yazılımların kontrollü biçimde haberleşmesini sağlayan arayüzdür.
Örneğin:
web formu ↓ CRM
veya:
CRM ↓ SMS sistemi
veya:
randevu sistemi ↓ dashboard
gibi entegrasyonlar API üzerinden yapılabilir.
Ancak her sistem API sunmaz.
API yoksa ne olur?
Alternatifler:
- webhook,
- dosya aktarımı,
- scheduled sync,
- resmi connector,
- gerektiğinde kontrollü browser automation
olabilir.
Ekranı taklit eden kırılgan otomasyonları mümkün olduğunca son seçenek olarak değerlendiriyorum.
Webhook
Webhook:
“bir olay olduğunda diğer sisteme haber ver”
mantığıyla çalışır.
Örneğin:
yeni lead oluştu ↓ webhook ↓ CRM kaydı ↓ temsilci ataması.
Real-time süreçlerde faydalıdır.
Otomasyon platformları
Bazı projelerde:
- n8n,
- Make,
- Zapier,
- Power Automate
gibi otomasyon platformları kullanılabilir.
Ancak platform seçimini:
“hangisi popüler?”
diye yapmıyorum.
Değerlendirme:
- veri hassasiyeti,
- hosting,
- maliyet,
- connector,
- workflow karmaşıklığı,
- hata yönetimi,
- ölçek
üzerinden yapılmalıdır.
Low-code / no-code ne zaman yeterli?
Basit:
- form,
- bildirim,
- görev,
- veri senkronizasyonu
işlerinde low-code çok hızlı çözüm olabilir.
Ancak:
- yoğun işlem,
- karmaşık veri modeli,
- yüksek güvenlik,
- özel kullanıcı deneyimi,
- ölçek
gerektiren sistemlerde custom development daha doğru olabilir.
Sağlık kuruluşlarında veri ayrımı
Sağlık sektöründe:
operasyon verisi
ile:
kişisel sağlık verisi
aynı şey değildir.
Örneğin:
“Almanya kaynaklı üroloji lead’i”
operasyon bilgisi olabilir.
Ancak:
- tanı,
- tetkik,
- tıbbi rapor,
- ayrıntılı sağlık geçmişi
özel nitelikli veri kapsamına girebilir.
Bu nedenle yazılım mimarisi:
“teknik olarak tutabiliriz”
mantığıyla değil;
gerçekten gerekli mi?
sorusuyla tasarlanmalıdır.
Rol bazlı yetki
Bir sistemde herkes her şeyi görmek zorunda değildir.
Örnek:
Hasta danışmanı
Kendi lead’leri.
Takım lideri
Ekibin operasyonu.
Klinik yöneticisi
Şube raporu.
Genel yönetim
Konsolide KPI.
Teknik admin
Sistem yönetimi.
Bu model projeye göre özelleştirilir.
Audit log
Kritik sistemlerde:
- kim giriş yaptı,
- kim kayıt değiştirdi,
- ne zaman değiştirdi,
- eski/yeni değer,
- hangi workflow çalıştı
gibi kayıtlar tutulabilir.
Özellikle çok kullanıcılı operasyonlarda önemlidir.
Hata yönetimi
Otomasyon:
“çalışıyorsa vardır”
mantığıyla bırakılmamalıdır.
Örneğin API bağlantısı başarısız olursa:
- retry,
- queue,
- alert,
- dead-letter,
- manuel müdahale
modeli gerekir.
Aksi halde otomasyon sessizce veri kaybettirebilir.
Dashboard
Her özel yazılımın dashboard’a ihtiyacı yoktur.
Dashboard sadece karar için gerekli bilgiyi göstermelidir.
Örneğin:
TODAY
- new leads,
- unanswered,
- appointments,
- arrivals.
OPERATIONS
- failed automations,
- pending approvals,
- overdue tasks.
MANAGEMENT
- branch,
- source,
- service,
- conversion.
Mobil uygulama gerçekten gerekli mi?
Her projeye iOS/Android uygulama eklemek maliyeti artırır.
Çoğu iç operasyon sistemi:
- responsive web app,
- PWA
ile çözülebilir.
Native uygulama ancak:
- cihaz özellikleri,
- offline çalışma,
- push,
- store dağıtımı
gerçekten gerekiyorsa tercih edilebilir.
Teknoloji seçimi
Proje ihtiyacına göre:
- Laravel,
- FastAPI,
- Node,
- Next.js,
- React,
- Astro,
- PostgreSQL,
- MariaDB/MySQL,
- Redis,
- OpenSearch
gibi farklı teknolojiler kullanılabilir.
Stack’i prestij için seçmiyorum.
İhtiyaca göre seçiyorum.
Legacy sistemler
Her projede eski sistemi çöpe atmak gerekmez.
Bazen:
- API katmanı,
- veri temizliği,
- frontend yenileme,
- raporlama,
- entegrasyon
eski sistemin ömrünü uzatabilir.
Tam rewrite ancak gerçekten gerekiyorsa yapılmalıdır.
Migration
Yeni sisteme geçerken:
- veri mapping,
- duplicate,
- encoding,
- tarih formatı,
- ID ilişkileri,
- kullanıcı rolleri
kontrol edilmelidir.
Migration için rollback planı olmalıdır.
AI nerede devreye girer?
AI geleneksel workflow otomasyonundan farklıdır.
Kural tabanlı işlem:
“status NEW ise temsilci ata”
kesindir.
AI ise:
- metni sınıflandırabilir,
- konuşmayı özetleyebilir,
- niyeti tahmin edebilir,
- taslak üretebilir,
- belgede bilgi çıkarabilir.
Bu nedenle AI kullanan workflow’larda:
confidence + human review + fallback
düşünülmelidir.
Yeni hizmet:
AI her sürece eklenmeli mi?
Hayır.
Şu iş:
“randevudan 24 saat önce SMS gönder”
AI gerektirmez.
Klasik otomasyon daha:
- ucuz,
- deterministik,
- hızlı,
- kolay test edilir
olabilir.
AI yalnız gerçekten belirsiz insan dili veya karmaşık veri yorumlama gereken yerde kullanılmalıdır.
Güvenlik
Özel yazılım projesinde temel konular:
- authentication,
- authorization,
- encryption,
- secret management,
- backup,
- rate limiting,
- logging,
- patch/update,
- least privilege.
Teknik güvenlik “SSL var” ile bitmez.
Ben nasıl çalışıyorum?
1. Problem
Neyi çözmeye çalışıyoruz?
2. Current workflow
Bugün nasıl yapılıyor?
3. Waste
Nerede zaman/veri kaybı var?
4. Buy vs Build
Hazır ürün yeterli mi?
5. Architecture
Sistemler nasıl konuşacak?
6. MVP
İlk çalışan kapsam.
7. Pilot
Gerçek kullanıcılarla sınırlı kullanım.
8. Measurement
Gerçekten zaman/kalite kazandırdı mı?
9. Scale
Gerekirse genişlet.
Neleri yapmıyorum?
- özel yazılım gerekli değilse sırf proje olsun diye önermiyorum,
- her probleme AI eklemiyorum,
- sağlık verisini kontrolsüz üçüncü taraf sistemlere göndermiyorum,
- API yoksa riskleri gizleyerek kırılgan otomasyon kurmuyorum,
- çalışan legacy sistemi sırf teknoloji eski diye çöpe atmıyorum,
- MVP yerine ilk günden dev platform kurmaya çalışmıyorum,
- kaynak kod/altyapı bağımlılığını müşteriden gizlemiyorum.
Önce yazılım istemeyin; problemi tarif edin.
Hazır ürün, entegrasyon, otomasyon veya özel geliştirmeden hangisinin gerçekten gerekli olduğunu birlikte belirleyelim.