Bu süreci Excel'de yönetiyoruz: ne zaman yazılıma geçmeli?

Bir süreci hesap tablosunda yönetmeyi bırakma kararı, dosyanın kaç satır olduğuyla değil, süreçten ne beklediğinizle ilgilidir. Dört soru kararı verir: aynı veriyi birden fazla kişi aynı anda mı değiştiriyor, yanlış bir giriş girildiği anda yakalanıyor mu, iki ay sonra "bu hücreyi kim değiştirdi" sorusunun bir cevabı var mı, ve bu tablo para, stok ya da müşteriye verilmiş bir söz belirliyor mu. İkisine birden evet diyorsanız elinizde bir hesap tablosu değil, denetimi olmayan bir üretim sistemi vardır. Çözüm Excel'i yasaklamak değil; kayıt kaynağı olma rolünü ondan almak.

Excel'in sorunu Excel değil, ona verilen rol

Hesap tablosu keşif için, modelleme için, tek seferlik hesap için hâlâ en hızlı araç. Bir kişinin yarım saatte kurduğu, kimseden onay istemeyen, kendi kendine yeten bir şey. Bunun değeri tartışmasız. Sorun, o yarım saatlik şeyin üç yıl sonra sipariş kabul etmesi, fiyat belirlemesi ve bordroyu beslemesi.

Kayıt kaynağı olan bir araçtan bekledikleriniz başkadır: girişte kural, eşzamanlı erişim, satır düzeyinde yetki, değişiklik geçmişi, geri alma, yedekten dönüş. Microsoft 365 ile ortak yazma özelliği geldi ve dosyanın kilitlenmesi sorununu büyük ölçüde çözdü. Ama ortak yazma, "bu alana negatif miktar girilemez" kuralını ya da "satış temsilcisi başka temsilcinin müşterisini göremez" kısıtını getirmez. O kurallar tabloda yaşamaz, tabloyu kullanan kişinin dikkatinde yaşar.

Hata sessiz oluyor, uyarı vermiyor

Ekim 2020'de İngiltere'de Public Health England, 25 Eylül ile 2 Ekim arasında 15.841 pozitif Kovid vakasının günlük raporlara hiç girmediğini açıkladı. Sebep laboratuvar sonuçlarını birleştiren şablonun eski XLS biçiminde tutulmasıydı. XLS'in satır sınırı 65.536'dır; dosya dolduğunda yeni sonuçlar hata vermeden düşmeye başladı. Vakalar kayıtta göründü, temas takibine gitmedi.

Buradaki asıl ders sınır değeri değil, sessizliktir. Güncel XLSX biçiminde sayfa başına 1.048.576 satır ve 16.384 sütun var, yani aynı hata bugün aynı yerden çıkmaz. Ama bir veritabanı yer kalmadığında ya da kural ihlal edildiğinde işlemi reddeder ve size bunu söyler. Tablo hiçbir şey söylemez. Bu fark, tek başına, "hangi araç" sorusunun cevabının yarısıdır.

Tablo verinizi izin almadan dönüştürüyor

Excel yapıştırdığınız her hücrenin türünü tahmin eder ve bazen yanılır. Genetik alanı bu yüzden 2020'de gen adlarını değiştirdi: HGNC, Excel'in tarihe çevirdiği 27 gen sembolünü yeniden adlandırdı, MARCH1 MARCHF1 oldu, SEPT1 SEPTIN1 oldu. Sebebi de ölçülmüştü. 2016'daki taramada 3.597 makalenin yüzde 19,6'sında ek dosyalarda bozulmuş gen adı bulunmuştu; 2021'de daha geniş bir örneklemde 11.117 makalenin yüzde 30,9'unda aynı hata çıktı. Yani sorun bilinir hale geldikten sonra da azalmadı.

Microsoft 2023'te Seçenekler altına "Otomatik Veri Dönüştürme" bölümünü ekledi (Windows'ta 2309 sürümü, Mac'te 16.77). Oradan harf ve rakam karışımlarının tarihe çevrilmesini kapatabiliyorsunuz, ama ayarın veri girilmeden önce yapılması gerekiyor ve her durumu yakalamıyor. Türkiye'de bu hikâyenin yerel versiyonu daha sık görülür: başındaki sıfırı yiyen telefon numaraları, tarihe dönüşen ürün kodları, bilimsel gösterime kaçan uzun IBAN ve barkodlar, CSV içe aktarırken virgül ile noktanın yer değiştirmesi. Hepsi sessiz.

Tek tuşluk hata, on bin biletlik sonuç

2012 Londra Olimpiyatları'nda senkronize yüzmenin dört seansı için elde olandan 10.000 fazla bilet satıldı. Sebep basitti: bir çalışan tabloya 10.000 yerine 20.000 yazmıştı. Hata haftalar sonra fark edildi, yaklaşık 3.000 müşteriyle tek tek iletişime geçilip biletleri başka etkinliklerle değiştirildi.

Yazılımda bu hata tek satırlık bir kısıtla durur: satılan bilet sayısı kapasiteyi aşamaz. Tabloda böyle bir kısıt yoktur, çünkü tablo neyin makul olduğunu bilmez. Veri doğrulama kuralları ekleyebilirsiniz, ama bir sonraki kişi kopyala-yapıştır yaptığında o kurallar çoğu zaman birlikte gelmez.

Kopyala-yapıştır bir sürece dönüştüğünde

JPMorgan'ın 2013 Ocak ayında yayımladığı iç inceleme raporu, riski ölçen VaR modelinin nasıl çalıştığını anlatır: model bir dizi Excel tablosu üzerinden işliyordu ve tablolar elle, birinden diğerine kopyala-yapıştır yapılarak dolduruluyordu. Süreçte yanlış hücrelerden kopyalama dahil operasyonel hatalar bulundu ve model riski olduğundan düşük gösterdi. Zarar tabloların değil, pozisyonların sonucuydu; ama zararı erken görmesi gereken uyarı sistemi bir kopyala-yapıştır adımına dayanıyordu.

Şirketinizde bunun karşılığı şudur: her sabah bir sistemden rapor indirip başka bir tabloya yapıştıran bir kişi varsa, o kişi entegrasyondur. İzinli olduğu gün, hasta olduğu gün ya da dikkatinin dağıldığı gün süreç durur veya yanlış çalışır. Bu iş ERP ile e-ticaret arasındaki veri senkronizasyonu gibi kalıcı bir bağlantıya dönüşmediği sürece maliyeti her ay yeniden ödersiniz.

Gözle kontrol neden yeterli olmuyor

Hesap tablosu hataları üzerine yapılmış akademik çalışmaların özeti rahatsız edici derecede nettir. Ray Panko'nun alandaki araştırmaları derlediği çalışma üç sonuca varır: hatalar hücre başına bakıldığında nadirdir ama büyük tablolarda en az bir yanlış sonuç bulunması çok olasıdır, bu hataları tespit etmek ve düzeltmek son derece zordur, ve tabloyu hazırlayanlar ile şirketler tablolarının doğruluğu konusunda aşırı özgüvenlidir.

Üçüncüsü en pahalıya patlayanı. "Biz kontrol ediyoruz" cümlesi genelde bir kontrol sürecini değil, bir alışkanlığı tarif eder. Yazılımdaki karşılığı, kuralın kodda tek bir yerde durması ve her kayıt için otomatik çalışmasıdır. Kimse hatırlamak zorunda kalmaz.

Geçiş vaktinin geldiğini gösteren beş sinyal

• Dosyayı aynı anda birden fazla kişi düzenliyor ve "kim en son kaydetti" tartışması ayda birden fazla yaşanıyor.
• Dosya adlarında sürüm var: teklif_son_v3_gercek_son.xlsx. Hangisinin doğru olduğunu bilen tek kişi izne çıkabiliyor.
• Bir insan iki sistem arasında veri taşıyor. Süreç o kişinin takvimine bağlı.
• "Bu satır ne zaman, kim tarafından değiştirildi" sorusuna cevap veremiyorsunuz. Değişiklik geçmişi yok, iz kaydı yok.
• Tablo doğrudan para belirliyor: fiyat, stok, prim, bordro, fatura. Hata maliyeti hesaplanabilir bir sayı.

Beşinin ikisi varsa konuşmayı başlatın. Üçü varsa takvim koyun.

Dosya şirketten çıktığında geri dönmüyor

Bir tabloyu e-posta ekiyle gönderdiğinizde erişimi geri alamazsınız. Kimin indirdiğini, kimin kopyaladığını, kaç kopyanın kimin bilgisayarında durduğunu göremezsiniz. İşten ayrılan bir çalışanın diskinde altı ay önceki müşteri listesi kalır ve bunu kimse fark etmez. Sistem üzerinden çalışıldığında ise erişim tek bir yerden kapatılır, kimin ne gördüğü rol ve izin modeliyle tanımlanır ve kayıtlar iz bırakır.

Makrolar ayrı bir konu. Office, Windows'ta internetten indirilen dosyalardaki VBA makrolarını Temmuz 2022'den beri varsayılan olarak engelliyor; Excel de bu listede. Yıllardır makroyla otomatikleştirdiğiniz bir sürece güveniyorsanız, o sürecin bir gün kullanıcıdan güvenlik uyarısını atlamasını istemesi ihtimalini hesaba katın. Dosyanın içinde müşteri verisi varsa kaybının ayrıca bildirim yükümlülüğü doğurabileceğini de hatırlatmakla yetinelim.

Yazılıma geçerken aslında ne satın alıyorsunuz

Karar toplantılarında yazılım genelde ekranlarla anlatılır, oysa satın aldığınız şey ekran değil. Altı şey satın alırsınız: girişte doğrulama (kural ihlal eden kayıt hiç oluşmaz), eşzamanlılık (iki kişi aynı kaydı bozmadan çalışır), yetki (kim neyi görür ve değiştirir), iz kaydı (kim, ne zaman, neyi, hangi eski değerden), entegrasyon (veri elle taşınmaz), ve tekrar hesaplanabilir raporlama (aynı soru her seferinde aynı cevabı verir).

Bu listede olmayan bir şeye dikkat edin: hız. Yeni sistem, tabloyu iyi bilen bir kullanıcı için ilk aylarda daha yavaş hissettirir. Kazanç, hata düzeltmeye ve mutabakata giden saatlerde ortaya çıkar, veri girişi saniyelerinde değil. Bunu baştan söylemezseniz projeyi kullanıcılar değil beklenti batırır.

Her şeyi taşımak zorunda değilsiniz

Doğru hedef "Excel'siz şirket" değil. Doğru hedef, kayıt kaynağının tablodan çıkması. Analiz, senaryo hesabı, bütçe modeli, bir defalık liste karşılaştırması tabloda kalabilir ve kalmalı da. Taşınacak olan, üzerinde başkalarının işlem yaptığı veridir.

Üç seçenek var ve üçü de meşru: hazır bir SaaS ürünü, düşük kodlu bir platform üzerinde iç uygulama, ya da özel yazılım. Ölçüt süreç: sektörde standart olan bir işi (muhasebe, İK, destek talebi) hazır ürün genelde daha ucuza ve daha iyi yapar. Süreç sizi rakiplerinizden ayıran şeyse özel geliştirme mantıklı hale gelir. Düşük kodlu araçlar arada iyi bir basamaktır, ama kullanıcı başına lisans maliyetini, yönetişimi ve "yarın bu uygulamayı taşımak istersek elimizde ne kalır" sorusunu baştan sorun.

O tablo zaten sizin şartnameniz

Taşımaya karar verdiğinizde en değerli kaynak elinizde: yıllardır kullanılan tablonun kendisi. Formüller iş kurallarıdır. Sarıya boyanmış satırlar istisnalardır ve o istisnaların neden var olduğunu genelde tek bir kişi bilir. Yeni sistemin gerçekten çalışması için bunların yazıya dökülmesi gerekir; yazılım şartnamesini sıfırdan hayal etmek yerine mevcut tabloyu satır satır sorgulamak çok daha hızlı sonuç verir.

Veri tarafında da sürpriz beklemeyin, hazırlıklı olun: aynı müşterinin üç farklı yazımı, boş bırakılmış zorunlu alanlar, "bilinmiyor" anlamında kullanılmış 1900 tarihleri. Eski veriyi taşımanın kuralları burada da geçerli: önce prova, sonra mutabakat, ilk dönemde tablo ile sistemi paralel çalıştırıp farkları kapatma.

Bu hafta yapılabilecek ilk adım

Bir sayfa açın ve şirkette karar üreten tabloları listeleyin. Her satıra dört bilgi yazın: bu tablo bir hafta yanlış çalışsa ne olur, kaç kişi düzenliyor, içinde müşteri ya da personel verisi var mı, sahibi kim. Liste genelde on beş satırı geçmez ve iki ya da üç tanesi hemen öne çıkar.

Sonra en riskli olanı seçip tek bir soruyu yanıtlayın: bu tablonun kayıt kaynağı olmaktan çıkması için en küçük değişiklik ne? Cevap çoğu zaman tüm süreci yazan büyük bir proje değil, tek bir formun ve tek bir doğrulama kuralının yerini değiştirmektir. Hangi tablonuzun sizi endişelendirdiğini biliyorsanız, konuşmaya oradan başlayalım.