Bir İş Süreci Nasıl Yazılıma Dönüştürülür? Gerçek Bir Sistemin Analizden Üretime Yolculuğu

Bir iş sürecini yazılıma dönüştürmek; aktörleri, veriyi, kararları ve istisnaları anlayıp bunları tutarlı bir veri modeli, uygulanabilir iş kuralları ve izlenebilir bir iş akışı hâline getirmektir. Ekranlar bu sistemin görünen yüzüdür. Güvenilirliği ise bir kaydın nasıl oluştuğu, kim tarafından değiştirilebildiği ve hata sonrası nasıl devam ettiği belirler.

TankDev’in yazılım mühendisliği yaklaşımında iş süreci analizi, sistem tasarımının başlangıcıdır. Veri tabanı bu tasarımın hafızasını, API’ler sistemler arasındaki sözleşmeleri, entegrasyonlar operasyonun bağlantılarını oluşturur. Otomasyon tekrar eden işleri yürütür; yapay zekâ ise ölçülebilir katkı sunduğu noktalara eklenir.

Bu yolculuğu bir endüstriyel ekipman servisinin müşteri talebi üzerinden izleyelim. Senaryo temsilidir; gerçek bir müşteriye ait başarı hikâyesi değildir. Buna karşılık ele alacağımız sürüm çakışması, eksik belge, yetkisiz onay ve belirsiz ERP sonucu, üretim sistemlerinde tasarlanması gereken somut durumlardır.

Başlangıç: Aynı işin dört ayrı yerde yaşaması

Müşteri, arızalanan cihaz için e-posta gönderir. Cihazın seri numarası bir Excel listesinde, fotoğrafları WhatsApp konuşmasında, servis yöneticisinin onayı başka bir e-postadadır. Operasyon çalışanı bilgileri ERP’ye yeniden girer. Müşteri ertesi gün “Talebimiz ne durumda?” diye sorduğunda cevap vermek için üç kişiye ulaşmak gerekir.

Burada eksik olan yalnızca bir talep ekranı değildir. Hangi cihaz üzerinde çalışıldığı, hangi işin onaylandığı, kimin sıradaki adımdan sorumlu olduğu ve ERP’deki kaydın bu taleple ilişkisi belirsizdir.

İlk sürümün hedefini daraltalım: Talebi ve belgelerini tek kimlik altında toplamak, inceleme ve iç onayı yönetmek, onaylanan kapsamı ERP’de servis iş emrine dönüştürmek, teknik tamamlanma belgesiyle işi kapatmak. Stok, muhasebe ve faturalamanın sahibi ERP olarak kalsın. Böylece çözümün neyi yöneteceği kadar hangi mevcut sistemi esas alacağı da bellidir.

1. Önce kod yazılmaz, süreç anlaşılır

Requirements analysis, yani gereksinim analizi, istenen ekranları listelemekten daha fazlasıdır. Süreci yapan kişiyle yakın zamanda tamamlanmış bir işi baştan sona izleyin. Ardından eksik belge yüzünden bekleyen ve hatalı işlem nedeniyle geri dönen bir örneğe bakın. “Normalde böyle yapıyoruz” ile gerçekten yapılan iş arasındaki farklar burada ortaya çıkar.

Servis örneğinde analiz şu sorulara somut cevap üretmelidir:

• Aktörler: Talebi kim açıyor, kim inceliyor, kim onaylıyor, kim işi yapıyor? Asıl sorumlu izinliyken kim devralıyor?
• Veri kaynakları: Müşteri ve cihaz bilgisi hangi sistemde yetkili? Belgeyi kim sağlıyor? Aynı seri numarası farklı müşteri kayıtlarında görünüyor mu?
• Yetkiler: Teknik personel inceleme notu yazabilir mi? Kendi hazırladığı işi onaylayabilir mi? Müşteri yalnızca kendi taleplerini mi görecek?
• Durumlar: Eksik bilgili talep nerede bekliyor? Reddedilen talep ile iptal edilen talep aynı şey mi? “Tamamlandı” neyi kanıtlıyor?
• İş kuralları: Hangi işlem için hangi belge gerekli? Hangi kapsam değişikliği yeniden onay ister? Maliyet sınırı hangi para birimi ve tutar tanımıyla uygulanır?
• Bağlantılar ve hatalar: ERP kesilirse iş nasıl devam ediyor? Aynı e-posta tekrar işlendiğinde ne oluyor? Sonucun belirsiz kaldığı işi kim çözüyor?

Workflow mapping, bu cevapları aktörler, durumlar, geçişler ve istisnalar olarak görünür kılar. Domain modeling ise operasyonun dilini kesinleştirir: “Talep”, “servis işi” ve “ERP iş emri” aynı nesne değildir. Bir talep incelenmeden iş emrine dönüşmeyebilir; bir ERP bağlantı hatası da servis talebinin reddedildiği anlamına gelmez.

Mevcut akışı aynen otomatikleştirmek zorunda değiliz. Aynı seri numarasını üç kişinin yeniden yazması bir iş kuralı değil, veri paylaşımı eksikliğinin sonucu olabilir. Mevcut durum haritasından sonra hedef akışı çıkarın; kaldırılan adımları ve korunması gereken kontrolleri süreç sahibiyle netleştirin.

Bu aşamanın çıktısı, üzerinde anlaşılmış bir kapsam, terimler sözlüğü, rol–işlem eşleştirmesi ve kabul senaryolarıdır. “Onay modülü olacak” yerine “Yetkisiz kişi talebi onaylayamayacak; kayıt değiştiğinde eski onay kullanılamayacak” denebiliyorsa gereksinim test edilebilir hâle gelmiştir.

2. Veri modeli, işin hafızasını kurar

Customer → Request → Process → Approval → Document → Transaction iyi bir ilk kavram listesidir; fakat doğrudan tablo zinciri değildir. Bir müşterinin birçok talebi, bir talebin birçok belgesi ve bir kapsamın birden fazla onayı olabilir. Gerçek ilişkileri modellemeden her şeyi tek satıra sıkıştırmak, sonraki değişiklikleri zorlaştırır.

Örneğimizde çekirdek model şu sorumlulukları ayırır:

• Customer ve Asset: Yetkili müşteri kaydı ve hizmet verilen cihaz. Seri numarası, cihaz kimliğinin yerine gelişigüzel kullanılmaz; kaynağın benzersizlik kuralı doğrulanır.
• Request ve RequestRevision: Talebin değişmeyen kimliği ile kapsam, miktar veya adres gibi değişebilen bilgilerinin sürümleri.
• ProcessRun: Talebin belirli bir iş akışı sürümüyle yürütülmesi; mevcut aşama, sorumlu ve zaman sınırları.
• Approval: Kararı veren kullanıcı, karar zamanı, uygulanan kural sürümü ve onaylanan talep sürümü.
• DocumentVersion: Belgenin sürümü, türü, saklama konumu ve hangi talep sürümünü desteklediği.
• IntegrationOperation: Dış sistemde yapılacak işlem, sabit işlem anahtarı, uzak kayıt kimliği ve doğrulanmış sonuç. Buradaki iş kaydı, veri tabanındaki SQL transaction kavramından farklıdır.

Şema 1. Bir onayın hangi bilgiye verildiği ve bir ERP işleminin hangi işe ait olduğu kayıttan anlaşılmalıdır.

PostgreSQL gibi ilişkisel bir veri tabanında foreign key’ler geçersiz ilişkiyi, unique constraints istenmeyen tekrarı ve check constraints uygun alan ihlallerini engelleyebilir. Örneğin talep içinde sürüm numarası benzersiz olmalıdır. Çok şirketli yapıda ilişkilerin şirket kapsamını da koruması gerekir; yalnızca ekrandaki filtreye güvenilmez. PostgreSQL kısıt belgeleri, bu kontrollerin hangi koşullarda veri tabanında uygulanabildiğini açıklar.

Onay verildiğinde karar, durum değişikliği ve sonraki adımı tetikleyecek olay birlikte saklanmalıdır. Transaction, bu yerel değişikliklerin birlikte tamamlanmasını veya geri alınmasını sağlar. Süreç kurallarının tamamını tek başına çözmez; uzak ERP işlemini de otomatik olarak aynı bütünlüğe katmaz.

3. İş kuralları, izinli durum geçişlerine dönüşür

Talep için olumlu akış; oluşturuldu → inceleme → onay bekliyor → onaylandı → işlemde → tamamlandı olabilir. Ancak çalışan sistem geri dönüşleri de tanımlar. Eksik bilgi, ret, iptal ve değişiklik talebi ayrı sonuçlardır.

Bu senaryoda “tamamlandı”, yetkili teknisyenin işi bitirdiğini kaydetmesi, gerekli tamamlanma belgesinin bulunması ve ERP iş emri bağlantısının doğrulanması demektir. ERP’de iş emri açılması tek başına servis işinin tamamlandığını göstermez.

Bir geçiş, yalnızca status alanına yeni metin yazmak değildir. İş akışı mantığı mevcut durumu, kullanıcının yetkisini, gerekli veriyi ve kaydın sürümünü birlikte kontrol eder. Bu mantık sınırlı bir süreçte uygulama içindeki bir state machine ile kurulabilir. Çok sayıda uzun süren süreç, zamanlayıcı ve değişen akış varsa workflow engine değerlendirilebilir; her projede ayrı motor zorunlu değildir.

Talep R-1042’nin 3. sürümü yöneticiye sunulmuş olsun. Yönetici ekranı açıkken operasyon cihazı veya yapılacak işi değiştirirse 4. sürüm oluşur. Eski ekrandan gelen onay 4. sürümü onaylamış sayılmaz. Sürüm kontrolü ve durum güncellemesi atomik yapılır; eski sürümle işlem reddedilir. Kritik kapsam değişikliği yeni inceleme ve onay gerektirir.

Authorization ve RBAC burada iş kuralıyla birleşir. “Yönetici” rolü tek başına yeterli değildir: Kullanıcı doğru şirket veya servis birimi kapsamında mı, bu işlem türünü onaylayabilir mi, görevler ayrılığı kuralı var mı? Kontrol sunucuda her istekte yapılır; OWASP yetkilendirme rehberi bu yaklaşımı destekler.

İstisnalar da açık davranışlara çevrilir:

• Eksik belge: Talep bilgi bekliyor durumuna alınır; hangi belgenin kimden beklendiği görünürdür.
• Ret: Neden ve karar kaydedilir. Düzeltme sonrası yeniden başvuru, eski kararı silerek yapılmaz.
• Yetkisiz onay: Durum değişmez; yetki hatası kaydedilir. Arayüzde buton gizlemek yeterli değildir.
• İş başladıktan sonra kapsam değişikliği: Yapılmış işlem geçmişi korunur; yeni değişiklik değerlendirilir. status alanını geriye almak dış sistemdeki işi geri almaz.
• Tekrar gönderim: Aynı mantıksal işlem için aynı idempotency anahtarı kullanılır. Aynı anahtar farklı içerikle gelirse çakışma kabul edilir; yeni işlem yaratılmaz.

Audit log, kimin neyi değiştirdiğini ve hangi sürümün esas alındığını gösterir. Saklama süresi, erişimi ve değiştirilmeye karşı koruması tasarlanmalıdır; sıradan bir log tablosu tek başına değiştirilemezlik garantisi değildir. OWASP loglama rehberi kaydedilecek bilgiler ve korunmaları için teknik bir başvuru kaynağıdır.

Şema 2. Talebin iş durumu ile entegrasyonun teknik durumu ayrı tutulur. “Onaylandı” ve “ERP’ye aktarıldı” farklı bilgilerdir.

4. Sistem yalnız yaşamaz: API ve entegrasyon sözleşmeleri

Servis uygulaması müşteri ve cihaz bilgisini ERP’den okuyabilir; onaylanan kapsamı REST API üzerinden iş emrine dönüştürebilir. Belgeler ayrı bir dosya servisinde saklanabilir. Bu yapıda her sistemin sahibi olduğu veri ve diğer sistemlere verdiği sözleşme bellidir.

Örneğin POST /requests/R-1042/approvals isteği şunu taşıyabilir:

{
  "expected_revision": 3,
  "decision": "approve",
  "comment": "Servis kapsamı ve belgeler incelendi."
}

Kimlik doğrulanmış oturumdan gelir; istemcinin gönderdiği rol esas alınmaz. Sunucu talebi onayladığında aynı transaction içinde aktarılacak olayı da outbox’a yazabilir. Bir yayınlayıcı bu olayı kuyruğa, worker da ERP’ye taşır. Transactional outbox, veri tabanı güncellenip mesaj gönderilememesi arasındaki boşluğu yönetir; tekrar teslimi ortadan kaldırmaz.

ERP iş emrini oluşturmuş fakat yanıt yolda kaybolmuşsa sistem “başarısız” sonucunu kesinleştirmez. İşlemi sonuç doğrulanıyor durumunda tutar; uzak işlem anahtarıyla sorgular veya ERP’nin desteklediği idempotent tekrar sözleşmesini kullanır. Yerel kaydın varlığı, uzak sistemde kaç kayıt oluştuğunu tek başına kanıtlamaz.

Geçici hatalarda süre ve deneme sayısıyla sınırlı retry uygulanır. Geçersiz müşteri veya yetkisiz erişim beklemekle düzelmez. Kuyruktan aynı mesajı alan worker önceki sonucu kontrol eder; çözülemeyen iş hata nedeni ve sahibiyle incelemeye gider. Servis personeli ham hata kodu yerine neyin beklendiğini ve müdahale gerekip gerekmediğini görür.

Webhook, dış sistemin olay bildirimidir. İmza veya servis sözleşmesindeki kimlik kontrolü yapılır; olay kimliği kaydedilir. Bildirim dayanıklı biçimde alındıktan sonra hızlıca yanıt verilip uzun işler arka planda yürütülebilir. GitHub’ın webhook uygulama rehberi bu tür teslim ve kuyruklama ilkelerine somut örnek verir. Teslim sırası garanti edilmiyorsa eski olay güncel durumu geriye götürmemeli; sürüm kontrolü veya yetkili kaynaktan yeniden okuma kullanılmalıdır.

5. Otomasyon, tanımlanmış bir kuralı güvenle tekrarlar

Süreç ve veri modeli netleşince bildirim, belge üretimi, hatırlatma ve raporlama doğal biçimde otomatikleşir. Ama her otomasyonun tetikleyicisi, girdisi, sonucu ve hata davranışı olmalıdır.

Servis kapsamı onaylandığında belge, onaylanan sürümden üretilir. Hatırlatma gönderilmeden önce işin hâlâ ilgili kişide beklediği kontrol edilir. Tamamlanma raporu, gerekli teknik belge ve doğrulanmış ERP bağlantısı mevcut olduğunda hazırlanır. Uygulama yeniden başlarsa planlanmış işlerin kaybolmaması gerekir.

Raporlama için “kaç talep var?” kadar tanımlar önemlidir. Müşteriden belge beklenen süre ile ekibin inceleme süresini ayırın. Yeniden açılan işleri, reddedilenleri ve entegrasyonda bekleyenleri aynı tamamlanma oranına gelişigüzel katmayın. Durum geçişlerinin zamanları, darboğazın hangi aşamada olduğunu ölçmeyi sağlar.

6. Her probleme yapay zekâ gerekmez

Gerekli belge eksik mi? Maliyet onay sınırını aşıyor mu? Talep doğru şirkete mi ait? Bu soruların cevabı açık kurallarla bulunabiliyorsa business rule veya klasik algoritma kullanılır. Yapay zekâ, net bir kuralın yerine belirsizlik eklemek için kullanılmamalıdır.

Servis operasyonunda AI’nin değerlendirilebileceği noktalar farklıdır:

• Document classification: Gelen eki servis formu, fotoğraf veya başka bir belge olarak sınıflandırmak.
• Computer vision: Cihaz etiketi fotoğrafından seri numarası çıkarmaya veya uygun veri varsa hasar incelemesine yardımcı olmak.
• Anomaly detection: Benzer cihazlara göre sıra dışı tekrar arıza veya servis süresi örüntülerini işaretlemek.
• LLM ve semantic search: Serbest metin talebi yapılandırılmış alanlara ayırmak, ilgili teknik dokümanı anlam üzerinden bulmak.
• Decision-support: Teknisyene kaynaklarıyla olası kontrol adımları sunmak; nihai iş yetkisini modelin metnine bırakmamak.

R-1042 için LLM “cihaz çalışmıyor” mesajından bir arıza kategorisi önerebilir. Etiket fotoğrafından okunan seri numarası katalogda iki kayıtla eşleşiyorsa sistem otomatik seçim yapmamalıdır. Modelin ürettiği alan doğrulamadan geçer; belirsiz sonuç insana yönlenir. Model çıktısı müşteri yetkisini, onay eşiğini veya kesin işlem hakkını belirlemez.

AI ekleme kararı da ölçülür: Kural tabanlı başlangıca göre işlem süresi azalıyor mu, alan doğruluğu yeterli mi, yanlış yönlendirme ve insan inceleme yükü ne oluyor? Gerçek örneklerden ayrılmış değerlendirme verisiyle karşılaştırın; maliyeti ve hatalı kararın etkisini birlikte okuyun. Başarıyı göstermeyen AI bileşeni ilk sürümün şartı olmamalıdır.

7. Analizden üretime geçişin kanıtı, test edilebilir davranıştır

Tasarımın gücü, her iş kuralının veri modeli, uygulama davranışı ve kabul testiyle ilişkilendirilebilmesidir. Örneğin “eski kapsam onaylanamaz” kuralı; RequestRevision ve Approval ilişkisine, atomik sürüm kontrolüne ve iki eşzamanlı kullanıcıyla yapılan teste dönüşür. “Tek talep iki iş emri açamaz” kuralı ise entegrasyon kimliği, idempotency sözleşmesi ve yanıt kaybı testini gerektirir.

İlk pilot için tamamlanma koşullarını açık yazın:

• R-1042 eksik seri numarasıyla ilerleyemez; kullanıcı eksik alanı görebilir.
• Yetkisiz kullanıcı doğrudan API isteğiyle de onay veremez.
• 3. sürümü açmış yönetici, 4. sürüm oluştuğunda eski ekranla onaylayamaz.
• Aynı olay veya aktarım mesajı tekrar geldiğinde ikinci ERP iş emri oluşmaz.
• ERP yanıtı kaybolduğunda kayıt sonuç doğrulanıyor olarak görünür ve güvenli biçimde uzlaştırılır.
• Kapsam değişiklikleri, kararlar ve teknik tamamlanma belgesi iş geçmişinden izlenebilir.

Şema 3. Gereksinim → tasarım → doğrulama → üretim geri bildirimi. Bir bileşenin varlığı değil, beklenen davranışın gösterilmesi kabul ölçütüdür.

Veri geçişinde eski Excel satırlarını yalnızca içeri almak yetmez. Kaynak kimliklerini koruyun, tekrarları ve eksik ilişkileri ayırın, açık işlerin durumunu doğrulayın. Pilot kapsamındaki kayıtlar için esas sistem belli olsun; aynı işi iki tarafta bağımsız değiştirerek yeni bir uzlaştırma sorunu yaratmayın.

Üretim hazırlığına yetki testleri, migration planı, bağlantı kesintisi, çalışan işin yeniden başlaması ve yedekten dönüş provası dahildir. Uygulama sürümünden geri dönüş ile veri geri yüklemenin farklı işlemler olduğunu açıklayın. ERP’ye gitmiş işleri geri yüklenen verilerle uzlaştırmadan kuyrukları yeniden çalıştırmayın.

Yayından sonra işlem kimliğiyle talebi, onayı, background job’ı ve ERP kaydını birlikte izleyin. En eski bekleyen işin yaşı, inceleme süresi, düzeltmeye dönme oranı ve doğrulanmış tamamlanma oranı teknik hata oranıyla birlikte takip edilir. Alarmın sahibi, kullanıcı desteği ve süreç değişikliği için sorumlu kişi teslimin parçasıdır. Üretimde öğrendikleriniz bir sonraki sürümün gereksinimleridir.

TankDev için mühendislik çıktısı, çalışan bir sistemdir

Bu yaklaşımda teslim edilen şey ekranlardan ibaret değildir: Süreç haritası, domain modeli, veri tabanı kuralları, API sözleşmeleri, yetki yapısı, entegrasyon davranışı, otomasyonlar ve işletim yöntemi birlikte bir sistem oluşturur. Yapay zekâ bu sistemin gerekli görülen bir bileşeni olabilir; sistem tasarımının yerine geçmez.

Bu yolculuğun farklı parçalarını Excel’den kurumsal yazılıma geçiş, üretim mimarisi tasarımı, AI otomasyonu ve özel model geliştirme yazılarında daha ayrıntılı ele alıyoruz.

İyi yazılım, mevcut sürecin yalnızca ekrana taşınmış hâli değildir. Verinin nereden geldiğini, hangi kurallardan geçtiğini, kim tarafından değiştirilebildiğini, diğer sistemlerle nasıl konuştuğunu ve bir şeyler ters gittiğinde nasıl davranacağını tanımlar.

Kodlama bu yolculuğun bir bölümüdür. Asıl mühendislik işi, gerçek dünyadaki dağınık operasyonu; durumu anlaşılabilen, kararları izlenebilen ve hatadan sonra güvenle devam edebilen bir sisteme dönüştürmektir.