Mevcut program yetmiyor — değiştirmeli mi, üstüne eklemeli mi?
Yıllardır kullandığınız program bazı işleri görmüyor. Komple değiştirmek ilk akla gelen çözüm ama çoğu zaman en pahalı olanı. Üçüncü bir yol var.
“Bu program bize yetmiyor” dendiğinde
Yıllardır kullanılan bir program var. Muhasebe tarafı çalışıyor, stok bir şekilde tutuluyor, fatura kesiliyor. Ama üretim takibi yok, raporlar istenen bilgiyi vermiyor ya da sahadaki ekip sisteme hiç dokunmuyor.
İlk akla gelen çözüm komple değiştirmek oluyor. Bu, üç seçenekten yalnızca biri ve genellikle en pahalısı.
Karar vermeden önce yapılacak bir tespit var ve birkaç gün sürüyor.
Yapamıyor mu, bilinmiyor mu?
Sahada gördüğümüz şikâyetlerin azımsanmayacak kısmı, programın yapamadığı işlerden değil, kimsenin nasıl yapıldığını bilmediği işlerden kaynaklanıyor.
Program yıllar önce kurulmuş, kuran kişi ayrılmış, sonraki kullanıcılar yalnızca kendilerine gösterilen üç ekranı kullanıyor. Programın rapor üreteci, alan ekleme özelliği ya da toplu işlem ekranı hiç açılmamış.
Bu yüzden ilk iş, hiçbir maliyeti olmayan iki adım:
- Üreticiden güncel kullanım kılavuzunu ve sürüm notlarını isteyin. Son iki yılda eklenen özellikler listesi çoğu zaman şaşırtıyor.
- Şikâyet listesini kalem kalem yazın ve her birinin karşısına “yapamıyor” mu “bilinmiyor” mu işaretleyin.
Örnek senaryo — Bir işletme, programının üretim maliyeti hesaplayamadığını söylüyor ve değiştirmeye karar vermiş. Üreticiyle görüşüldüğünde modülün lisanslarında zaten dahil olduğu, ancak hiç açılmadığı ortaya çıkıyor. Kurulum ve eğitim bir haftalık iş. Değiştirme kararı iptal ediliyor.
Veri dışarı açılıyor mu — belirleyici teknik soru
Tespit bittiğinde ve gerçekten eksik olan bir şey varsa, tek bir soru seçenekleri belirliyor:
Mevcut programınız dışarıya veri açıyor mu?
Açıyorsa — veritabanına erişim veriyorsa ya da bir arayüz sunuyorsa — üstüne ekleme yapılabiliyor. Açmıyorsa, yani veri ancak ekrandan okunabiliyorsa, ekleme yolu kapanıyor.
Bu soruyu üreticiye sormanın somut biçimi şu: “Verimize dışarıdan erişebiliyor muyuz, hangi yöntemle?” Cevap belirsizse ısrar edin; bu, ileride tüm seçeneklerinizi belirleyen tek cevap.
Üç seçenek ve gerçek maliyetleri
Değiştirmek | Üstüne eklemek | Bekletmek | |
|---|---|---|---|
Görünen maliyet | Yeni program | Ek geliştirme | Yok |
Veri taşıma | Zorunlu | Yok | Yok |
Yeniden eğitim | Tüm ekip | Yalnızca yeni kısım | Yok |
Paralel dönem | Aylar | Yok veya kısa | Yok |
Risk | Yüksek | Orta | Sorun büyür |
Ne zaman doğru | Temel mantık uymuyorsa | Eksik tek bir parçaysa | Süreç oturmamışsa |
Değiştirmek en görünür seçenek ama maliyeti tabloda görünenden fazla. Veri taşıma, tüm ekibin yeniden eğitimi ve aylarca süren paralel dönem — üçü birden hesaba katıldığında, eksik olan tek parçayı yazdırmanın birkaç katına çıkabiliyor.
Üstüne eklemek çoğu durumda en makul yol: çalışan sistem çalışmaya devam ediyor, yalnızca eksik parça ekleniyor, ekibin öğreneceği şey küçük.
Bekletmek bir seçenek olarak görülmüyor ama bazen doğru. Süreç henüz oturmamışsa yazılıma dökmek, değişimi pahalı hâle getiriyor.
Değiştirme kararı ne zaman doğru?
Dört durumda değiştirmek makul:
Üretici desteği bıraktıysa. Sürüm çıkmıyorsa, destek hattı cevap vermiyorsa, sistem yaşlanıyor demektir.
Mevzuata zamanında uyum sağlayamıyorsa. e-Fatura ve e-İrsaliye tarafındaki kapsam ve tarihler değişiyor; güncel metin GİB e-Belge portalında yayımlanıyor. Bir zorunluluk tarihi geldiğinde programınız hazır değilse, bu tek başına değiştirme gerekçesi.
Verinize erişemiyorsanız. Kendi verinizi dışa aktaramıyorsanız her yıl bağımlılık artıyor.
Eksik olan tek bir modül değil, sistemin temel mantığıysa. Program seri üretim varsayıyor ama siz sipariş üzerine üretim yapıyorsanız, üstüne yapılacak her ekleme yamayı büyütüyor.
Dikkat — “Yeni program daha modern görünüyor” bir değiştirme gerekçesi değil. Arayüz tazeliği, veri taşıma ve yeniden eğitim maliyetini karşılamıyor.
Üstüne eklerken tek kural
Ekleme yaparken bozulan tek şey genellikle aynı: aynı veri iki yerde tutulmaya başlıyor.
Ürün tanımı hem eski programda hem yeni ekte var. Bir süre sonra ikisi birbirinden ayrılıyor; hangisinin doğru olduğu bilinmiyor ve iki sistem de güvenilmez hâle geliyor.
Kural şu: her veri parçasının tek bir sahibi olmalı. Ürün ve stok hangi sistemdeyse orada kalır, diğeri oradan okur. Yeni ek yalnızca kendi ürettiği veriyi tutar.
Bu, karma kurgunun tek gerçek şartı; aynı ilkeyi hazır paket ile özel yazılımı birlikte kullanırken de uyguluyoruz. Karşılaştırmayı üretim takip programı nasıl seçilir yazısında yaptık.
İpucu — Ekleme projesine başlarken tek sayfalık bir “veri sahipliği” tablosu çıkarın: hangi bilgi hangi sistemde tutulacak, hangisi nereden okuyacak. Bu tablo, projedeki en pahalı hatayı baştan önlüyor.
Süreç mi program mı sorunlu?
Bazen program suçsuz. Sorun, programın kaydettiği sürecin kendisinde oluyor.
Ayırt etmenin yolu şu soru: program olmasaydı bu iş nasıl yürürdü ve daha mı iyi olurdu? Cevap “daha iyi olurdu” ise programın engel olduğu bir süreç var. Cevap “daha kötü olurdu” ise sorun süreçte ve yeni program da aynı sorunu kaydedecek.
Sanayi ve Teknoloji Bakanlığı’nın yürüttüğü Model Fabrika programı bu ayrımı yapmak isteyen işletmeler için uygulamalı bir yapı sunuyor: dijitalleşmeden önce sürecin kendisini iyileştirmek üzerine kurulu.
Yatırım tarafı
Hangi yol seçilirse seçilsin bir bütçe kalemi doğuyor. İmalat sanayiinde faaliyet gösteren KOBİ’ler için KOSGEB’in dijital dönüşüm başlığı yazılım ve donanım yatırımını kapsıyor; program NACE sınıflamasına göre imalat sektöründe faaliyet gösterme şartı arıyor.
Güncel koşullar KOSGEB’in program sayfasında, diğer başlıklar destekler dizininde yayımlanıyor.
Tespit çalışması — beş adım
Değiştirme kararından önceki tespit, birkaç gün süren ve hiçbir dış maliyeti olmayan bir iş.
- Şikâyetleri kalem kalem yazın. "Yetmiyor" değil, "üretim maliyetini hesaplayamıyoruz" gibi tek tek.
- Her şikâyeti sınıflayın. Yapamıyor mu, bilinmiyor mu, lisansta yok mu?
- Üreticiye sorun. Güncel kılavuz, sürüm notları ve lisans kapsamınız.
- Kalanı ölçün. Gerçekten yapamadığı işler listesi ne kadar uzun ve bunlar işin ne kadarını kapsıyor?
- Veri erişimini test edin. Verinizi dışarı aktarabiliyor musunuz, hangi biçimde?
Beşinci adım en kritiği: cevabı hem üstüne ekleme yapılıp yapılamayacağını hem de değiştirme durumunda veri taşımanın ne kadar zor olacağını belirliyor.
Üreticiyle görüşmede sorulacaklar
Mevcut programın üreticisiyle yapılacak tek bir görüşme, çoğu zaman değiştirme kararını gereksiz kılıyor. Beş soru:
Bu iş sizin programınızda yapılabiliyor mu? Şikâyet listesini tek tek sorun.
Lisansımızda hangi modüller var, hangileri açık? Alınmış ama hiç açılmamış modüller sık çıkıyor.
Son iki yılda hangi özellikler eklendi? Sürüm notları, programın hâlâ geliştirilip geliştirilmediğini de gösteriyor.
Mevzuat değişikliklerine ne kadar sürede uyum sağlıyorsunuz? Geçmiş performans, gelecek riskin en iyi göstergesi.
Verimize dışarıdan erişebilir miyiz? Cevap belirsizse ısrar edin.
Örnek senaryo — Bir işletme, programının bayi siparişi alamadığı için değiştirilmesi gerektiğini düşünüyor. Üreticiyle görüşüldüğünde programın veri erişimine açık olduğu ortaya çıkıyor. Program değişmiyor; üstüne bir sipariş portalı kuruluyor ve stok bilgisi mevcut sistemden okunuyor. Değiştirme maliyetinin küçük bir kısmıyla aynı sonuç alınıyor.
Değiştirme kararı verildiyse zamanlama
Değiştirmek gerçekten doğru karar çıktıysa, zamanlama maliyeti belirleyen ikinci etken oluyor.
Mali dönem başını hedefleyin. Yıl ortasında yapılan geçişte açılış bakiyeleri ve karşılaştırmalı raporlar zorlaşıyor.
Üretimin yoğun dönemini bekleyin. Yoğunlukta yapılan geçişte kimsenin öğrenecek vakti olmuyor.
Mevzuat takvimini kontrol edin. Bir e-belge zorunluluğu tarihine yakın geçiş planlamak, iki riski aynı haftaya toplamak demek; kapsam ve tarihler GİB e-Belge portalında yayımlanıyor.
Paralel dönem için süre ayırın. Eski sistem en az iki üç ay açık kalmalı ve bu sürenin bir bitiş tarihi olmalı.
Ne zaman hiçbir şey yapılmaz?
Üç durumda doğru cevap "şimdilik dokunmayın" oluyor.
Süreç değişim hâlindeyse. Üretim biçiminiz ya da ürün gamınız değişiyorsa, oturmamış bir süreci yazılıma bağlamak değişimi pahalı hâle getiriyor.
Şikâyet tek bir kişiden geliyorsa. Bir kişinin rahatsız olduğu bir ekran, sistem sorunu olmayabilir. Aynı şikâyet birden çok rolden geliyorsa sorun gerçek.
Yakın zamanda büyük bir değişiklik yapıldıysa. Yeni bir modül açıldıysa veya sürüm güncellendiyse, birkaç ay beklemek gerekiyor; ilk haftalardaki şikâyetlerin bir kısmı alışma kaynaklı.
Karar tablosunu kendiniz doldurun
Tespit bittiğinde elinizde şu üç sayı olmalı ve karar bu üç sayıdan çıkıyor.
Gerçekten yapılamayan iş sayısı. Şikâyet listesinden "bilinmiyor" ve "lisansta yok" olanlar çıkarıldıktan sonra kalan.
Bu işlerin toplam süreçteki payı. Bir iki ekran mı, yoksa günlük akışın yarısı mı?
Veri erişiminin durumu. Açık, kısıtlı ya da kapalı.
Kalan iş sayısı azsa ve veri erişimi açıksa cevap üstüne eklemek. Kalan iş günlük akışın büyük kısmını kapsıyorsa cevap değiştirmek. Veri erişimi kapalıysa üstüne ekleme seçeneği zaten yok ve karar ikiye iniyor: değiştirmek ya da bugünkü hâliyle devam etmek.
Sonuç — “Program bize yetmiyor” cümlesi üç farklı sorunun ortak ifadesi olabiliyor: bilinmeyen özellik, eksik tek parça ya da temelden uyumsuzluk. Üçünün cevabı farklı ve teşhis koymadan verilen değiştirme kararı, en pahalı seçeneği seçmek anlamına geliyor.
Eksik parçayı mevcut sisteminizin üstüne kurma işini özel yazılım geliştirme kapsamında yürütüyoruz. Kümenin genel çerçevesi fabrikalar için yazılım, maliyet tarafı üretim takip programı fiyatları yazısında.
