Excel'den Kurumsal Yazılıma: Bir İş Süreci Ne Zaman Özel Yazılıma Dönüştürülmeli?

Bir iş süreci; doğru kaydı bulmak, kimin ne yapacağını belirlemek ve değişiklikleri izlemek için sürekli insan takibine ihtiyaç duyuyorsa kurumsal bir sisteme geçiş değerlendirilmelidir. Eşik, Excel dosyasındaki satır sayısı değildir. Asıl işaret, işin doğruluğunun çalışanların birbirini hatırlatmasına ve dosyaları uzlaştırmasına bağlı hâle gelmesidir.

Excel hesaplama ve analiz, e-posta yazışma, WhatsApp hızlı iletişim için değerlidir. Sorun, aynı siparişin durumunu bu araçların her birinde ayrı ayrı tutmaya başladığınızda ortaya çıkar. Bir yerde fiyat değiştirilir, başka bir yerde onay verilir, üçüncü yerde eski teslim tarihi kalır. Her kayıt kendi içinde makul görünür; birlikte tutarlı bir süreç oluşturmazlar.

Bu yazıda, müşteri talebinden siparişe uzanan temsili bir akışı ele alacağız. Amaç, her tabloyu yazılıma çevirmek değil; veri, yetki ve iş kuralları ortak bir yerde yönetildiğinde neyin değiştiğini göstermek.

Sorun dosyanın büyüklüğü değil, kararların dağılmasıdır

Satış ekibi teklifi Excel'de hazırlasın, müşteri revizyonu e-postayla iletsin, yönetici indirimi WhatsApp'tan onaylasın. Operasyon da siparişi başka bir takip listesine yazsın. Müşteri miktarı sonradan değiştirdiğinde yöneticinin onayı hangi teklif sürümü için geçerlidir?

Buradaki hata ihtimali, bir çalışanın dikkatsizliğinden önce sürecin yapısından doğar. Kayıt, onay ve uygulama birbirinden ayrılmıştır. İş büyüdükçe ekip daha fazla zamanını işi yapmaya değil, ne olduğuna dair ortak bir cevap bulmaya harcar.

Paylaşımlı dosyalar ve sürüm geçmişi bazı sorunları azaltabilir. Ancak dosyaya erişebilmek; belirli müşteriyi görebilmek, indirimi onaylayabilmek veya onaylanmış siparişi değiştirebilmekle aynı yetki değildir. İş kuralları ayrıntılandıkça dosya paylaşımından daha kapsamlı bir tasarım gerekir.

Şema 1. İletişim kanalları kullanılmaya devam edebilir; işlem durumu ortak kayıttan okunur.

Geçiş zamanını gösteren beş somut işaret

• Aynı bilgi tekrar giriliyor: Müşteri, tutar ve teslim tarihi farklı listelere taşınıyor; düzeltmeler her kopyaya ulaşmıyor.
• İşler hatırlatmayla ilerliyor: Bekleyen onayı bulmak için mesaj atılıyor, sorumlu izinliyken süreç duruyor.
• Yetki sınırları belirsiz: Kimin yalnızca görebileceği, değiştirebileceği veya onaylayabileceği ayrıştırılamıyor.
• Geçmiş yeniden kuruluyor: Bir uyuşmazlıkta güncel dosyadan çok eski e-postalar ve ekran görüntüleri aranıyor.
• Rapor hazırlamak uzlaştırmaya dönüşüyor: Toplantıdan önce ekipler hangi sayının doğru olduğunu bulmak için listeleri eşleştiriyor.

Kararı görünür maliyetle destekleyin. Örneğin tamamen varsayımsal olarak ayda 300 işlemde işlem başına 8 dakika tekrar giriş ve kontrol varsa, ayda 40 saat bu işe gider. Bu süreyi otomasyonla bütünüyle ortadan kalkacak bir tasarruf saymayın. Gerçekte azaltılabilecek kısmı pilotta ölçün; hata düzeltme ve bekleme maliyetlerini de ayrı izleyin.

Özel yazılım her zaman doğru ilk seçenek mi?

Önce mevcut ERP veya CRM'in ilgili modülünü, hazır iş akışı ürünlerini ve düşük kodlu araçları değerlendirin. Süreç standartsa, gerekli yetkiler ve entegrasyonlar hazır üründe karşılanıyorsa, sıfırdan geliştirme gerekmeyebilir.

Özel yazılım; şirkete özgü karar kuralları, birden fazla sistem arasında zorunlu bağlantılar veya hazır araçlarda sürdürülemeyen istisnalar bulunduğunda daha anlamlı hâle gelir. Karşılaştırmada lisans ya da ilk geliştirme bedeli kadar bakım, destek, veri taşıma, kullanıcı eğitimi ve üründen çıkış maliyeti de yer almalıdır.

Sürecin sahibi ve onay kuralları henüz belli değilse önce bunları netleştirin. Belirsizliği kodlamak, onu ortadan kaldırmaz.

Merkezi veri tabanı: Her işin tanımlı bir kaydı olsun

Merkezi veri tabanı, ilgili uygulamada aynı iş nesnesi için ortak bir kayıt ve kimlik sağlar. Örneğin müşteri, teklif, teklif revizyonu, onay ve sipariş birbirine bağlı kayıtlardır. Müşteri adını her satırda yeniden yazarak eşleştirmek yerine müşteri kimliği kullanılır; teklifin hangi sürümünün onaylandığı açıkça saklanır.

Benzersizlik, zorunlu alan ve ilişki kuralları hatalı kayıtların bir kısmını veri tabanı düzeyinde engelleyebilir. Birbiriyle tutarlı olması gereken değişiklikler uygun bir transaction, yani işlem bütünlüğü içinde ele alınır. Bu mekanizmalar için PostgreSQL veri kısıtları ve transaction açıklaması iyi bir teknik başlangıçtır.

“Merkezi” bütün şirket verilerinin tek fiziksel veri tabanına taşınması demek değildir. Muhasebe kaydının yetkili kaynağı ERP, teklif sürecinin kaynağı yeni uygulama olabilir. Kritik olan, her alan için hangi sistemin esas alınacağının belli olmasıdır.

İki kişi aynı teklifi açtığında son kaydedenin diğerinin değişikliğini sessizce ezmesi de önlenmelidir. Kayıt sürümü kontrolüyle eski veri üzerinden yapılan güncelleme reddedilebilir ve kullanıcıdan güncel sürümü incelemesi istenebilir.

Kullanıcı yetkileri: Giriş yapmak, her işlemi yapabilmek değildir

Kimlik doğrulama kullanıcının kim olduğunu belirler; yetkilendirme hangi kayıt üzerinde hangi işlemi yapabileceğini belirler. Satış temsilcisi kendi müşterisinin teklifini düzenleyebilirken, indirim onayı bir yöneticiye ait olabilir. Finans ekibinin ihtiyaç duyduğu alanlar depo ekibinin ihtiyaçlarından farklıdır.

Kontrolü yalnızca ekranda buton gizleyerek yapmayın. Sunucu her istekte işlem ve kayıt yetkisini doğrulamalıdır. Varsayılan erişimi kapalı tutmak ve gerekli yetkiyi vermek, OWASP yetkilendirme rehberinin temel ilkelerindendir.

Bir çalışan görev değiştirdiğinde yetkisi de değişmelidir. İzin dönemindeki vekâletin kapsamı ve süresi tanımlanabilir; ortak hesap kullanımı kimin işlem yaptığını belirsizleştirir.

Workflow: “Sırada kim var?” sorusunu sistem cevaplasın

Workflow, bir işin durumlarını ve bu durumlar arasındaki geçiş koşullarını tanımlar. Teklif örneğinde akış taslak, onay bekliyor, onaylandı ve siparişe dönüştü durumlarından oluşabilir. İade ve iptal yolları da tasarlanmalıdır.

Her geçiş için sorumlu, gerekli veri ve izin verilen işlem bellidir. Belirli bir indirim sınırını aşan teklif yöneticiye gider. Kritik fiyat veya miktar değişikliği, önceki onayı geçersiz kılıp yeniden onay gerektirebilir. Hatırlatma süresi aşılırsa iş tanımlı bir kişiye eskale edilir; sistem sessizce onay vermiş saymaz.

Şema 2. Durum adları kadar geri dönüşler ve onayın hangi sürüme ait olduğu da önemlidir.

E-posta veya WhatsApp bildirimi, kullanıcıyı ilgili kayda götürebilir. Mesajın gönderilmesi onayın verildiği anlamına gelmez. Onay; yetkili kullanıcının, belirli kayıt sürümü üzerinde gerçekleştirdiği doğrulanmış bir işlem olmalıdır.

Audit log: Son durumu değil, değişimin hikâyesini de saklayın

Audit log, yani denetim izi, anlamlı işlemlerin kim tarafından, ne zaman ve hangi kayıt üzerinde yapıldığını kaydeder. Kritik alanlarda önceki ve sonraki değer, değişiklik nedeni, kayıt sürümü ve işlem kimliği de tutulabilir. Böylece “Tutar şu an ne?” sorusunun yanında “Onaydan sonra tutar değişti mi?” sorusu cevaplanır.

Bu geçmiş sıradan kullanıcılar tarafından değiştirilememeli; erişimi ve saklama süresi tanımlanmalıdır. Tek başına bir log tablosu değiştirilemezlik garantisi vermez. İşin riskine göre ayrı saklama ve bütünlük kontrolleri gerekebilir. Parolaları, erişim anahtarlarını veya gereksiz kişisel bilgileri loga yazmayın. OWASP loglama rehberi, hangi bilgilerin kaydedileceği ve nasıl korunacağı konusunda yol gösterir.

Raporlama: Önce ölçünün anlamını ortaklaştırın

Merkezi kayıtlar, ekiplerin aynı tanımlarla rapor üretmesini sağlar. Ancak bir grafik eklemek ölçüm sorununu kendiliğinden çözmez. “Tamamlanan işlem” onaylanan teklif mi, oluşan sipariş mi, teslim edilen ürün mü? İptaller dahil mi? Hangi zaman aralığı esas alınıyor?

İlk raporları sürecin darboğazlarına bağlayın: onayda bekleme süresi, tekrar düzeltmeye dönen teklif oranı, entegrasyon hatası yüzünden bekleyen işler ve zamanında tamamlanma oranı. İşlem geçmişi bu ölçümler için veri sağlar. Yoğun raporlama operasyonel sistemi yavaşlatıyorsa ayrı okuma altyapısı değerlendirilebilir; verinin güncellik zamanı kullanıcıya gösterilir.

API entegrasyonu: Aynı bilgiyi yeniden yazmayı azaltın

API, sistemlerin tanımlı bir sözleşmeyle veri ve işlem alışverişi yapmasını sağlar. Onaylanan teklif ERP'de siparişe dönüştürülebilir; oluşan sipariş numarası uygulamaya geri yazılır. Bu bağlantıda alan eşleştirmeleri, yetkiler, hatalar ve tekrar deneme kuralları net olmalıdır.

ERP yanıtı gelmediğinde siparişin hiç oluşmadığı varsayılamaz. Aynı isteği tekrar göndermek çift kayıt yaratabilir. İşlem anahtarıyla tekrarı güvenli hâle getirin; uzak sistem bunu desteklemiyorsa durum sorgulama ve uzlaştırma tasarlayın. Ekranda “aktarılıyor”, “doğrulama bekliyor” ve “başarısız” durumlarını ayırın.

Geçişi tek bir kritik akışla başlatın

İlk sürümü bütün departmanları kapsayan bir projeye dönüştürmek yerine talep–onay–sipariş gibi sınırları belli bir akış seçin. Sürecin sahibiyle normal akışı ve istisnaları yazın; mevcut veriyi temizleyip deneme aktarımı yapın. Kayıt sayıları kadar tutarları, ilişkileri ve açık işlerin durumunu da karşılaştırın.

Pilot sırasında aynı işin hem Excel'de hem uygulamada bağımsız değiştirilmesine izin vermek yeni bir uzlaştırma sorunu yaratır. Pilot kapsamındaki işlerin esas kaydını belirleyin. Kullanıcıları gerçek örneklerle eğitin; yetkisiz işlem, eşzamanlı değişiklik, kesilen entegrasyon ve yedekten dönüş senaryolarını deneyin.

Başarıyı ekran sayısıyla ölçmeyin. Bir işin sahibini bulmak, bekleyen onayı görmek, hatalı aktarımı düzeltmek ve geçmişini açıklamak gerçekten kolaylaştı mı? Özel yazılıma geçiş, bu soruların cevaplarını kişilerin hafızasından çıkarıp işleyen bir sisteme yerleştirdiğinde değer üretir.