Excel ile Yönetilen İş Süreçleri Ne Zaman Yazılıma Taşınmalı?

Bir Excel dosyası aynı anda üç kişinin bilgisayarında farklı rakamlar gösteriyorsa sorun artık Excel değildir. Süreç, kullandığınız aracın sınırlarını aşmaya başlamıştır.

Excel, WhatsApp, e-posta ve hatta kâğıt formlar birçok işletmenin ilk yıllarında gayet işe yarar. Birkaç kişinin yürüttüğü, işlem sayısının düşük olduğu ve sık değişen işlerde özel bir yazılım geliştirmek gereksiz bile olabilir. Her tabloyu gördüğü anda yazılıma dönüştürmeye çalışan bir işletme, dijitalleşmekten çok kendine pahalı bir hobi edinir.

Asıl soru “Excel kullanıyor muyuz?” değil, “Bu yöntem artık işin yapılmasını zorlaştırıyor mu?” olmalıdır.

Excel ne zaman yetersiz kalmaya başlar?

Bir sipariş tablosunu düşünün. Satış ekibi siparişi Excel'e giriyor, stok bilgisi WhatsApp grubundan soruluyor, sevkiyat tarihi e-postayla depoya gönderiliyor, ödeme durumu başka bir dosyada tutuluyor.

Her araç tek başına görevini yapıyor gibi görünür. Sorun, işin tamamını görmek istediğinizde ortaya çıkar.

Siparişin hangi aşamada olduğunu öğrenmek için birkaç kişiye sormak gerekiyorsa, aynı bilgi birden fazla yere giriliyorsa veya bir çalışanın izinli olması işleri görünmez hâle getiriyorsa süreç kişilere ve dağınık kayıtlara bağımlı hale gelmiştir.

Yazılıma geçiş ihtiyacını gösteren en güçlü işaretlerden bazıları şunlardır:

• Aynı bilgi farklı Excel dosyalarına tekrar tekrar giriliyorsa,

• Dosyanın güncel sürümünün hangisi olduğu sık sık karışıyorsa,

• İşlem geçmişini kimin, ne zaman değiştirdiği izlenemiyorsa,

• Yönetici güncel durumu görmek için çalışanlardan rapor bekliyorsa,

• Onaylar WhatsApp veya e-posta mesajlarının arasında kayboluyorsa,

• Hatalı veri girişi operasyonu, müşteriyi veya finansal kayıtları etkiliyorsa,

• Yeni çalışanların süreci öğrenmesi belirli kişilerin anlatımına bağlıysa,

• İşlem sayısı arttıkça aynı işi yürütmek için daha fazla insan gerekiyorsa,

• Yetkilendirme ihtiyacı doğduğu hâlde herkes aynı dosyaya erişiyorsa,

• Müşteri, sipariş, servis, üretim veya stok bilgilerinin birbiriyle ilişkisi elle kuruluyorsa

artık kullanılan araçların değil, sürecin kendisinin yeniden ele alınması gerekir.

Burada tek bir belirtinin görülmesi otomatik olarak özel yazılım gerektiği anlamına gelmez. Örneğin ayda on kez kullanılan basit bir takip tablosunun yeni bir sisteme taşınması yatırım açısından mantıklı olmayabilir. Aynı tablo her gün yüzlerce işlemde kullanılıyor ve hata üretmeye başladıysa denklem değişir.

İlk hangi süreç dijitalleştirilmeli?

En kolay süreçten başlamak rahat görünür. Her zaman doğru seçim değildir.

Önceliği en fazla sorun çıkaran ve iyileştirildiğinde işletmeye ölçülebilir fayda sağlayacak süreç almalıdır.

Bunu belirlemek için karmaşık bir danışmanlık modeli kurmaya gerek yok. Süreçleri dört soruyla değerlendirmek çoğu işletmede yeterince açıklayıcı bir ilk fotoğraf verir:

Ne kadar sık kullanılıyor?
Her gün yüzlerce kez çalışan bir süreçte küçük bir verimsizlik bile birikir. Yılda birkaç kez yapılan işlem aynı önceliğe sahip olmayabilir.

Hata olduğunda bedeli ne oluyor?
Yanlış ürün sevkiyatı, unutulan tahsilat, hatalı fiyat, geciken teklif veya kaybolan servis kaydı yalnızca birkaç dakikalık işçilik kaybı değildir.

Süreç ne kadar kişiye bağımlı?
“Onu sadece Ayşe Hanım biliyor” cümlesi operasyon açısından ciddi bir uyarıdır. Bilgi bir çalışanın hafızasında veya kişisel dosyalarında duruyorsa işletmenin kurumsal hafızasına dönüşmemiştir.

Ne kadar elle işlem yapılıyor?
Bir bilgi satıştan muhasebeye, muhasebeden depoya, depodan yönetime tekrar yazılıyorsa hata ihtimali de gereksiz iş yükü de artar.

Örneğin bir işletmede teklif hazırlama, satın alma, izin talepleri ve servis yönetimi Excel ile yürütülüyor olabilir. İzin taleplerini yazılıma geçirmek kolaydır. Fakat asıl gecikme servis tarafında yaşanıyor, müşteriler kayıtlarının durumunu soruyor ve teknisyenlerin işleri düzenli takip edilemiyorsa ilk yatırım servis sürecine yapılmalıdır.

Dijitalleşme vitrinden değil, darboğazdan başlamalıdır.

Yazılım geliştirmeden önce mevcut süreci çıkarın

Kötü çalışan bir süreci olduğu gibi yazılıma aktarmak onu iyi hale getirmez. Sadece daha hızlı çalışan kötü bir süreç elde edilir. İnsanlığın otomasyona kazandırdığı tuhaf başarılardan biri de budur.

Yazılım konuşulmadan önce mevcut işin nasıl yürüdüğü açık biçimde görülmelidir.

Bir sipariş sürecinde örneğin şu akış çıkarılabilir:

Müşteri siparişi gönderiyor → satış kaydı açıyor → stok kontrol ediliyor → fiyat veya iskonto onayı alınıyor → sipariş depoya aktarılıyor → sevkiyat yapılıyor → fatura kesiliyor → ödeme takip ediliyor.

Ardından her adım için birkaç somut bilgi toplanır:

Kim yapıyor? Hangi bilgi gerekiyor? Veri nereden geliyor? Nereye kaydediliyor? Kim onaylıyor? Hangi durumda süreç bekliyor? Hangi bilgiler daha sonra raporlanıyor?

Bu çalışma sırasında gereksiz adımlar da görünmeye başlar. Bir çalışan başka sistemde zaten bulunan müşteri bilgisini yeniden Excel'e yazıyorsa yeni yazılımın görevi ona daha güzel bir veri giriş ekranı hazırlamak değildir. Mümkünse mevcut veriyi doğrudan kullanmaktır.

İhtiyaç analizi tam olarak burada değer kazanır.

Piasoft da web yazılım projelerini işletmenin iş süreçleri ve operasyonel ihtiyaçları üzerinden ele aldığını; kuruma özel paneller, süreç otomasyonları, veri yönetimi ve iş akışı çözümlerinin ERP ve CRM gibi mevcut kurumsal sistemlerle entegre biçimde planlanabildiğini belirtiyor. İşletmeye özel yazılım yaklaşımı için Piasoft’un web yazılım ve özel yazılım çözümlerini inceleyebilirsiniz.

Her şeyi tek projede yazılıma taşımak zorunda değilsiniz

Bir işletmede Excel kullanılan on farklı süreç varsa bunların tamamını aynı anda değiştirmek cazip gelebilir. Kâğıt üzerinde düzenli görünür. Uygulamada kapsam hızla büyür, kullanıcı ihtiyaçları birbirine karışır ve ilk çalışan sürüm gecikir.

Daha kontrollü yöntem, sınırları belirlenmiş bir süreci seçip onu uçtan uca çözmektir.

Örneğin teklif yönetimiyle başlanabilir.

İlk sürümde müşteri seçimi, teklif oluşturma, fiyat onayı, PDF çıktısı, teklif durumu ve temel raporlama bulunabilir. CRM, muhasebe entegrasyonu, gelişmiş satış tahminleri veya mobil uygulama gibi özellikler gerçekten gerekiyorsa sonraki aşamalara bırakılabilir.

Böyle bir yaklaşım iki şeyi erkenden gösterir: Yazılım gerçek problemi çözüyor mu ve çalışanlar sistemi günlük işlerinde kullanabiliyor mu?

Bu soruların cevabını proje bittikten aylar sonra öğrenmek pahalıdır.

Excel'i bir gecede kapatmayın

Yeni sistem hazır olduğunda eski dosyaları hemen kaldırmak çoğu işletme için gereksiz risk yaratır.

Özellikle kritik operasyonlarda belirli bir dönem paralel kullanım gerekebilir. Yeni kayıtlar yazılım üzerinden yürütülürken eski veriler kontrol amacıyla erişilebilir tutulabilir. Kullanıcıların karşılaştığı eksikler kaydedilir. Raporlar mevcut sonuçlarla karşılaştırılır. Yetkiler, bildirimler ve iş akışları gerçek kullanım altında test edilir.

Geçiş sırasında cevaplanması gereken pratik sorular vardır:

Eski Excel kayıtlarının tamamı gerçekten sisteme aktarılmalı mı? Hangi veriler hatalı veya tekrar ediyor? Açık siparişler nasıl taşınacak? Kullanıcıların hangi kayıtlara erişmesi gerekiyor? Eski dosyalar ne kadar süre saklanacak? Sistem kullanılamazsa geçici çalışma yöntemi ne olacak?

Veri taşıma konusu özellikle hafife alınmamalıdır. Yıllardır elle kullanılan tablolarda müşteri isimlerinin farklı yazılması, boş alanlar, aynı kaydın birden fazla kez açılması veya standart dışı tarih ve ürün kodları bulunabilir. Yeni sisteme kirli veriyi olduğu gibi aktarmak eski düzensizliği yeni ekranlara taşır.

Yazılıma geçişin başarılı olup olmadığını nasıl anlarsınız?

“Program çalışıyor” yeterli bir ölçü değildir.

Başlangıçta yaşanan problem neyse başarı ölçüsü de oradan çıkmalıdır.

Siparişlerin durumu görülemiyorsa, sistemden açık siparişlerin anlık görülebilmesi gerekir. Teklif hazırlamak uzun sürüyorsa süre karşılaştırılabilir. Hatalı veri girişi sorun yaratıyorsa düzeltme ve iptal kayıtları takip edilebilir. Yönetim rapor için üç gün bekliyorsa hedef raporun doğrudan sistemden alınması olabilir.

Ölçü mümkün olduğunca günlük işe bağlanmalıdır:

“Dijital dönüşüm sağlandı” ölçü değildir.

“Bir siparişin kimde beklediği görülebiliyor” ölçülebilir bir sonuçtur.

Hazır yazılım mı, özel yazılım mı?

Her Excel dosyasının karşılığı özel yazılım değildir.

Muhasebe, standart CRM, insan kaynakları veya proje yönetimi gibi yaygın ihtiyaçlarda piyasadaki hazır çözümler işletmenin ihtiyacını karşılayabilir. Sürecinizi değiştirmeden önce mevcut ürünleri değerlendirmek çoğu zaman daha ekonomik bir başlangıçtır.

Özel yazılım ihtiyacı daha çok işletmenin çalışma şekli standart ürünlere sığmadığında ortaya çıkar. Örneğin fiyatlandırma kuralları şirkete özgüyse, farklı departmanların kendine has onay akışları varsa, mevcut ERP ile özel veri alışverişi gerekiyorsa veya müşteri, bayi, saha ekibi ve yönetimin aynı süreçte farklı ekranlara ihtiyaç duyduğu bir yapı bulunuyorsa hazır bir ürün fazla sınırlı kalabilir.

Buradaki karar “özel yazılım daha iyidir” kadar basit değildir. Asıl ölçüt, çözümün iş ihtiyacına uygunluğu ve toplam işletme maliyetidir.

Yazılıma geçmeden önce cevaplanması gereken sorular

Bir yazılım firmasıyla görüşmeden önce yüz sayfalık teknik doküman hazırlamanız gerekmez. Fakat aşağıdaki soruların cevapları proje kapsamını ciddi biçimde netleştirir:

• Bugün en fazla zaman kaybettiren süreç hangisi?

• En sık yapılan hata nerede oluşuyor?

• Sürecin başlangıcı ve bitişi nedir?

• Kimler sistemi kullanacak?

• Kullanıcıların yetkileri birbirinden farklı mı?

• Hangi onaylar gerekiyor?

• Hangi raporlar gerçekten kullanılıyor?

• Mevcut ERP, muhasebe, CRM, e-ticaret veya diğer sistemlerle veri alışverişi gerekiyor mu?

• Geçmiş verilerin ne kadarı taşınmalı?

• İlk sürüm çalıştığında mutlaka yapılabilmesi gereken işler neler?

Bu sorular cevaplanmadan başlayan projelerde ihtiyaç listesi geliştirme sırasında büyümeye eğilimlidir. Bir süre sonra “küçük bir takip sistemi” stoktan muhasebeye, saha uygulamasından müşteri portalına kadar her şeyi çözmesi beklenen dev bir projeye dönüşebilir.

İhtiyaç analizi, gereksiz özellikleri elemek için de yapılır.

Piasoft'un açıkladığı çalışma modeli de projeyi ihtiyaç analiziyle başlatıp kapsam ve teknik yapının planlanması, geliştirme, test, kontrollü yayın ve yayın sonrası destek adımlarıyla sürdürüyor. Yazılım yayına alındıktan sonraki bakım, güncelleme ve teknik destek yaklaşımı ise Bakım & Destek hizmetleri sayfasında açıklanıyor.

Excel'in hâlâ işi düzgün yaptığı yerde Excel'i bırakmak zorunda değilsiniz. Değişim, araç eski göründüğü için değil; süreç görünmez hâle geldiği, hata üretmeye başladığı, kişilere bağımlı olduğu veya büyümeyi zorlaştırdığı için anlamlıdır.

Başlangıç noktası da en gösterişli proje değil, işletmede bugün en fazla sorun yaratan süreçtir. Süreç netleştirilir, gerçek ihtiyaç çıkarılır, ilk kapsam kontrollü tutulur ve sistem gerçek kullanıcılarla sınanarak genişletilir.

Piasoft, mevcut iş akışlarını ve kullanılan sistemleri inceleyerek işletmeye uygun bir dijitalleşme yol haritası oluşturabilir; hazır çözümlerin yeterli olmadığı süreçlerde ihtiyaca göre özel yazılım ve otomasyon altyapısı geliştirebilir. Piasoft'un yaklaşımında ihtiyaç analizi, planlama, uygulama, test ve yayın sonrası bakım aynı proje yaşam döngüsünün parçaları olarak ele alınıyor.