İş Yazılımları: Excel'den Çıkıp Otomasyona Geçmenin Doğru Zamanı

Excel harika bir araçtır ve çoğu işletme için uzun süre yeterlidir. Sorun Excel'in kendisi değil, iki kişiden fazlasının aynı dosyaya dokunmaya başladığı an. O noktadan sonra dosya bir kayıt sistemi olmaktan çıkıp bir risk kaynağına dönüşür.

Bu yazıda, iş yazılımına geçiş kararının ne zaman verilmesi gerektiğini, geçişin nasıl aşamalandırılacağını ve hangi süreçten başlamanın en mantıklı olduğunu anlatıyoruz.

Geçiş zamanının beş işareti

Aşağıdakilerden üçü sizde varsa, artık maliyet yazılımda değil, yazılımsızlıkta.

Aynı veriyi iki kez giriyorsunuz. Sipariş bir yere, stok düşümü başka yere, fatura üçüncü bir yere. Her tekrar bir hata ihtimalidir ve hata er geç gerçekleşir.

"Son hali hangisi" sorusu soruluyor. Dosya adında tarih, versiyon numarası veya kişi adı geçiyorsa, kayıt sisteminiz artık güvenilir değildir.

Bir kişi işe gelmediğinde süreç duruyor. Bilgi dosyada değil, kişinin kafasındaysa, o bilgi şirketin değildir.

Rapor hazırlamak saatler sürüyor. Ay sonunda birinin oturup dosyaları birleştirmesi gerekiyorsa, veri var ama erişilebilir değil.

Stokta olmayan ürünü satıyorsunuz. Bu, müşteri kaybının en pahalı biçimidir ve neredeyse her zaman veri gecikmesinden kaynaklanır.

Hazır paket mi, özel yazılım mı

Bu kararı ideolojik değil, süreç odaklı vermek gerekir.

En sık yapılan hata, hazır paketi alıp süreci pakete uydurmak. Eğer sipariş akışınız rakiplerinizden farklı olduğu için hızlıysanız, paketin standart akışına geçmek o avantajı bilerek elden çıkarmaktır.

Buna karşılık muhasebe, bordro gibi mevzuatın belirlediği alanlarda özel yazılım yazmak neredeyse her zaman gereksizdir. O alanlarda hazır paket kullanıp kendi sisteminizle API üzerinden konuşturmak doğru kurgudur.

Nereden başlanmalı: en çok acıtan tek süreç

Kurumsal yazılım projelerinin başarısızlık sebeplerinin başında, her şeyi aynı anda değiştirmeye kalkmak geliyor. On sekiz ay süren, yayına alındığında kimsenin kullanmadığı sistemler hep böyle doğuyor.

Doğru yaklaşım tek bir süreçle başlamak ve onu uçtan uca çalışır hale getirmek. Genelde bu süreç sipariş ve stok arasındaki bağlantı oluyor, çünkü hatanın maliyeti orada en yüksek.

Kendi markamız Temizle.co'da tam olarak bunu yaptık: web sitesinden gelen her sipariş, hizmet türüne göre gereken malzeme listesini otomatik oluşturup stoktan düşecek şekilde kuruldu. Kritik seviyeye inildiğinde sistem uyarı veriyordu. Projenin ayrıntıları Temizle.co vaka çalışmamızda yazılı.

Aşamalı geçiş planı

1. Mevcut süreci olduğu gibi haritalayın. İyileştirmeden önce ne olduğunu yazın. Kim ne yapıyor, hangi bilgi nereden nereye gidiyor, hangi adımda bekleme oluyor.
2. Gereksiz adımları silin. Otomatikleştirilecek en iyi adım, hiç olmaması gereken adımdır. Süreç haritası genelde yıllar önce eklenmiş ve artık kimsenin sebebini bilmediği kontrol adımları ortaya çıkarır.
3. Tek süreci yazılıma alın. Kalan her şey Excel'de kalabilir; sorun değil.
4. Paralel çalıştırın. İki ile dört hafta boyunca hem eski hem yeni sistem birlikte yürüsün. Fark çıkarsa, veri kaybetmeden düzeltirsiniz.
5. Eskiyi kapatın. Paralel dönem bitince eski dosyayı salt okunur yapın. Açık bırakılan bir Excel, mutlaka kullanılmaya devam eder.
6. Sonraki sürece geçin.

Bu planın en çok atlanan adımı ikincisi. Süreç haritalama, yazılım maliyetini doğrudan düşürür çünkü yazılmayacak modülleri ortaya çıkarır. Süreç haritalama çalışması genelde bir ile iki hafta sürer ve projenin geri kalanının kapsamını belirler.

Kullanıcı benimsemesi: teknik olmayan asıl risk

Yazılım çalışıyor olabilir ama kimse kullanmıyorsa proje başarısızdır. Sahadan gelen direncin sebebi genelde teknoloji korkusu değil, yeni sistemin işi zorlaştırması.

Üç şeye dikkat edin. Yeni sistem, eski yöntemden daha az tıklama gerektirmeli; aksi halde kullanıcı haklı olarak direnç gösterir. Eğitim, kullanıma başlamadan değil, başladıktan sonra da devam etmeli. Ve en önemlisi, süreci günlük kullanan kişi tasarım aşamasında masada olmalı.

Entegrasyon: yeni sistem tek başına yaşamaz

İş yazılımı, şirketteki diğer sistemlerle konuşmadığı sürece yalnızca yeni bir ada olur. Manuel veri girişini bir yerden kaldırıp başka bir yere taşımak, sorunu çözmez.

Tipik olarak bağlanması gereken noktalar şunlar: muhasebe programı, e-fatura sağlayıcısı, kargo firmaları, banka veya ödeme altyapısı, ve varsa e-ticaret siteniz.

Entegrasyon kararında iki soruyu baştan sorun. Karşı sistemin açık bir arayüzü var mı? Yoksa entegrasyon maliyeti hızla artar. Ve veri hangi yöne akacak? Tek yönlü aktarım basittir; çift yönlü senkronizasyon çakışma yönetimi gerektirir ve belirgin biçimde daha pahalıdır.

Çoğu projede doğru cevap, kritik veriyi tek bir sistemde tutup diğerlerine oradan beslemektir. İki sistemin de aynı veriyi değiştirebildiği kurgular, er geç tutarsızlık üretir.

Kim sahiplenecek: bakım ve devir

Yazılım teslim edildiğinde proje bitmez. Bakımsız kalan bir iş yazılımı iki üç yıl içinde kullanılamaz hale gelir.

Baştan netleştirilmesi gereken üç konu var. Kaynak kodu kimde duruyor ve kime ait? Sunucu ve veritabanı kimin hesabında? Ve bir hata çıktığında kime, hangi sürede ulaşılacak?

Bu soruların cevabı sözleşmede yazmıyorsa, ilerideki en pahalı sürpriz oradan gelir. Kaynak kodun ve altyapı hesaplarının işletmede olması, geliştirici değiştirme ihtimalini gerçek bir seçenek olarak korur.

Ne kadar sürer

Bu süreler geliştirme süresidir. Üzerine süreç haritalama, paralel çalıştırma dönemi ve eğitim eklenir. Toplam takvimi planlarken bunları ayrı kalem olarak yazın; projelerin gecikme sebebi genelde geliştirme değil, bu üç kalemin hesaba katılmamış olmasıdır.

Veri güvenliği ve yasal yükümlülük

İş yazılımı çoğu zaman kişisel veri işler: müşteri bilgisi, çalışan kaydı, adres. Bu, KVKK kapsamında sorumluluk doğurur.

Asgari olarak şunlar kurulmalı: rol bazlı yetkilendirme (herkes her veriyi görmemeli), iletim ve depolamada şifreleme, düzenli ve test edilmiş yedekleme, ve kim neyi ne zaman değiştirdi kaydı. Uygulama güvenliği tarafında OWASP Top 10 listesi, geliştirme sırasında baz alınacak pratik bir kontrol listesi sunuyor.

Yedeklemede sık yapılan hata, yedek almak ama geri yüklemeyi hiç denememek. Test edilmemiş yedek, yedek değildir.

Maliyet nasıl hesaplanır

Karşılaştırmayı yalnızca yazılım fiyatı üzerinden yapmak yanıltıcıdır. Gerçek karşılaştırma, mevcut durumun gizli maliyetiyle yapılmalı.

Şunları toplayın: manuel veri girişine harcanan aylık saat, hatalı sipariş ve stok açığının aylık maliyeti, rapor hazırlamaya giden süre, ve süreç bilgisinin tek kişide olmasının yarattığı risk. Çoğu işletmede bu toplam, yazılım maliyetini bir yıldan kısa sürede karşılıyor.

Özetle

İş yazılımına geçiş bir teknoloji projesi değil, bir süreç projesidir. Yazılım, iyi tanımlanmış bir süreci hızlandırır; tanımsız bir süreci ise yalnızca daha pahalı biçimde karmaşıklaştırır.

En çok acıtan tek süreçle başlayın, onu uçtan uca çalıştırın, paralel dönemde doğrulayın, sonra ilerleyin. İş yazılımları ve otomasyon araçları hizmetlerimiz bu aşamalı yaklaşım üzerine kurulu. Mevcut sürecinizi birlikte haritalamak için bize yazın.