ERP Değiştirmek mi, Mevcut Programa Ek Modül mü? Ne Zaman Hangisi?

ERP değiştirmenin gerçek maliyet kalemleri nelerdir?

ERP değiştirmenin maliyeti yeni programın lisans ya da abonelik bedelinden çok daha geniştir; asıl yük veri taşıma, yeniden kurgulama, eğitim ve paralel çalışma döneminde ortaya çıkar. Teklif aşamasında görünen kalemler genellikle ilk ikisidir, sonradan çıkanlar ise geri kalanlar.

Eski verinin saklanması ayrıca düşünülmelidir. 2026 itibarıyla yürürlükteki düzenlemede Vergi Usul Kanunu'nun 253. maddesine göre defter ve belgeler, ilgili oldukları yılı izleyen takvim yılından başlayarak beş yıl saklanır; Türk Ticaret Kanunu'nun 82. maddesi ise ticari defterler ve belgeler için on yıllık saklama öngörür. Bu, eski programın ya da en azından verisinin yıllarca okunabilir kalması gerektiği anlamına gelir. Hangi kaydın hangi biçimde saklanacağı mali müşavirinizle belirlenir.

Geçiş zamanlaması da maliyeti etkiler. Açılış bakiyelerinin, stok değerlemesinin ve e-belge sürekliliğinin temiz kurulabilmesi için birçok işletme geçişi mali dönem başına planlar. Dönem ortasında geçiş mümkündür, ama hangi kayıtların hangi programda kalacağı daha dikkatli belgelenmelidir.

ERP'yi gerçekten değiştirmeniz gereken durumlar

ERP'nin değişmesi gereken durumlar, sorunun programın çekirdeğinde olduğu ve yanına eklenen hiçbir parçanın bunu düzeltemeyeceği durumlardır. Bunları dürüstçe saymak gerekir; çünkü yanlış yerde kurulan ek katman, değişmesi gereken bir programın ömrünü masraflı biçimde uzatır.

• Üreticinin desteği bitmiş ya da bitmek üzere olan bir sürüm: Mevzuat değişiklikleri ve e-belge güncellemeleri artık gelmiyorsa, üstüne yazılan her parça çürük bir zemine kurulur.
• Temel muhasebe ihtiyacı karşılanmıyor: Çok para birimi, çok şirket, konsolidasyon ya da maliyet yöntemi gibi çekirdek bir ihtiyaç ürünün kendisinde yoksa, bunu dışarıdan tamamlamak sürdürülemez.
• Grup ya da ortak standardı: Şirket bir gruba katıldıysa ya da ana firma tek bir ERP'de birleşmeyi şart koşuyorsa, karar teknik değil kurumsaldır.
• Veri yapısı işinizi taşıyamıyor: Program performans ya da kapasite sınırına dayanmışsa ve üreticinin daha üst bir ürününe geçiş yolu varsa, bu yol değerlendirilmelidir.
• Veriye resmî bir yoldan erişilemiyor: Programa kayıt yazmanın belgelenmiş hiçbir yolu yoksa ve iş, programa düzenli kayıt yazmayı gerektiriyorsa, ek katman ancak dosya aktarımıyla sınırlı kalır.
• Kullanıcılar programı zaten bırakmış: Muhasebe dışındaki herkes işi Excel'de yürütüyor ve program yalnızca resmî kayıt için açılıyorsa, sorun belki program değil kurgu; ama yeniden kurgu çoğu zaman yeni bir kurulum kadar iş çıkarır.

Logo kullanıcıları için bir not: Logo, ürün hattını Logo Edge çatısı altında yeniden adlandırdı. Bu tür bir üretici geçişi, kurulumunuzun hangi yola gireceğini yetkili bayinizle konuşmak için iyi bir vesiledir. Geçiş takvimi konusunda tek doğru kaynak üretici ve bayinizdir.

Mevcut programın üstüne ek katman yazmanın daha mantıklı olduğu durumlar

Ek katman, muhasebe ve resmî kayıt tarafında işini iyi yapan bir programın uzanamadığı süreci kapatmak için yazılan ayrı bir uygulamadır. Programın içine gömülmez; yanında çalışır ve kayıtlarını ürünün desteklediği resmî arayüzden işler. Uyarlamadan da farklıdır: uyarlama programın kendi ekranlarını değiştirir, ek katman ise programın dışında kendi ekranlarıyla çalışır.

Ek katman şu durumlarda genellikle daha mantıklıdır:

• Şikâyet sahadan geliyor: Üretimde anlık kayıt, depoda raf adresi, sevkiyatta okutarak doğrulama, bayiden sipariş alma gibi işler. Bir üretim takip programı ya da barkodlu stok takip programı bu boşluğa yerleşir, muhasebe düzenine dokunmaz.
• Muhasebe ekibi programdan memnun: On yıllık veri, mali müşavirin alışkanlığı ve e-dönüşüm kurgusu çalışıyorsa, bunları riske atmanın bir gerekçesi olmalı.
• Programın veriye resmî bir erişim yolu var: Logo Objects ve REST Servis, Netsis NetOpenX, Mikro Desktop API gibi belgelenmiş arayüzler varsa, ek katman programa güvenli biçimde kayıt yazabilir.
• Eksik olan şey bir rapor ya da ekran: Yönetimin istediği görünüm programda yoksa, veriyi okuyup gösteren bir panel çoğu zaman yeterlidir. Okuma, programın kayıtlarına dokunmadığı için en düşük riskli iştir.
• Sorun iki sistemin konuşmaması: E-ticaret sitesi ile program, ya da depo ile muhasebe arasında elle taşınan veri varsa, gereken yeni bir program değil, bir ERP entegrasyonu katmanıdır.

Bazen eksik sanılan özellik programda zaten vardır; yalnızca lisansta açılmamış ya da kullanılmıyordur. Bu yüzden ek katman konuşmasının ilk adımı, yetkili bayinizle programın mevcut modüllerine bakmaktır. Var olan bir özelliği yeniden yazmayı önermeyiz.

Karar ağacı: ERP geçişi mi, ek modül mü?

ERP geçişi mi ek modül mü sorusu beş soruyla büyük ölçüde netleşir. Soruları sırayla cevaplayın; erken bir cevap sizi doğrudan bir sonuca götürebilir.

1. Programınız güncel ve üretici tarafından destekleniyor mu? Hayır ise ERP değişikliğini ya da üreticinin güncel sürümüne geçişi ciddi biçimde değerlendirin. Evet ise ikinci soruya geçin.
2. Sorun programın çekirdeğinde mi? Muhasebe, vergi, maliyet, çok şirket gibi temel bir ihtiyaç karşılanmıyorsa ve üreticinin bir modülüyle çözülemiyorsa ERP değişikliği öne çıkar. Sorun sahada, raporda ya da bağlantıdaysa üçüncü soruya geçin.
3. Programa resmî ve belgelenmiş bir yoldan kayıt yazılabiliyor mu? Evetse ek katman güvenli bir seçenektir. Yalnızca dosya aktarımı varsa, ek katmanın kayıtları toplu ve belirli aralıklarla aktaracağını kabul edip etmediğinize bakın.
4. Programın yanında kaç ek parça birikti? Ayrı ayrı yazılmış dört beş küçük araç, birbirinden habersiz Excel makroları ve her birini tek bir kişinin bildiği bağlantılar varsa, önce bunları tek bir ara katmanda toplamayı ya da bütünü yeniden değerlendirmeyi konuşun.
5. Önümüzdeki dönemde şirket yapısı değişecek mi? Birleşme, grup standardı, yeni ülke ya da çok farklı bir iş modeli öngörülüyorsa, büyük bir ek katman yatırımı yerine geçişi bekleyen dar bir çözüm seçin.

Ek katman yolunun riskleri ve sınırları

Ek katman da bedelsiz değildir; en büyük maliyeti bakımdır. ERP üreticileri her sürümde alan ekler, arayüzlerini sürümler, bazen kırıcı değişiklikleri ayrıca ilan etmez. Doğrudan veritabanına yazan bağlantılar bu geçişlerde en kırılgan olanlardır; resmî arayüz üzerinden çalışanlar daha korunaklıdır. Yine de sürüm yükseltmesi öncesi bir kontrol turu gerekir ve bu süreklilik bir bakım anlaşmasının konusudur.

Lisans ve erişim tarafı da baştan netleşmelidir. Bazı ürünlerde resmî arayüzün kullanımı ayrı bir lisansa ya da üreticiye başvuruya bağlıdır. Örneğin Logo Objects bir run-time lisansı ister, Mikro Desktop API için API Key gerekir. Biz hiçbir yazılım üreticisinin bayisi değiliz; bu adımı yetkili bayinizle birlikte yürütürüz ve teyit yapılmadan takvim vermeyiz.

Üçüncü risk dağınıklıktır. Her ihtiyaç için ayrı bir küçük araç yazılırsa, birkaç yıl sonra ortada kimsenin bütününü bilmediği bir parça yığını oluşur. Bunu önlemenin yolu, ERP'ye bağlanan kodu tek bir ara katmanda toplamaktır: saha ekranı, bayi portalı ve rapor paneli aynı katmanı kullanır, ERP'ye yazan kod tek yerde durur ve bir kez test edilir.

Son olarak, ek katman bozuk bir süreci düzeltmez. Stok kodları iki sistemde tutarsızsa ya da hangi verinin doğru kabul edileceği konusunda yönetim anlaşamamışsa, önce bunların çözülmesi gerekir. Karışıklığı otomatikleştirmek onu yalnızca hızlandırır.

Geçiş kararı verdiyseniz ek katmanınızı nasıl korursunuz?

ERP değişikliğine karar verdiyseniz, saha uygulamalarınızı ERP'ye doğrudan değil, bir ara katman üzerinden bağlamak geçişin yükünü belirgin biçimde azaltır. Saha ekranları ara katmanla konuşur, ara katman ERP ile. ERP değiştiğinde yalnızca ara katmanın ERP'ye bağlanan parçası yeniden yazılır; operatörün, depocunun ya da bayinin kullandığı ekranlar aynı kalır.

Bu yaklaşımın birkaç pratik sonucu vardır:

• Stok kodu, cari, birim ve ambar eşlemeleri kodda değil, yönetilebilir bir tabloda tutulur; yeni ERP'nin kodlarına geçiş bu tabloda yapılır.
• Geçiş döneminde ara katman bir süre iki programa birden yazabilir ya da kayıtları kuyrukta bekletebilir; saha durmaz.
• Kullanıcı eğitimi yalnızca muhasebe ekibini kapsar, sahadaki ekip alışkanlığını korur.

Bu yüzden, ERP değişikliği iki üç yıl içinde gündemde olsa bile, bugün ihtiyaç duyulan saha uygulamasını ertelemek her zaman doğru değildir. Doğru kurulmuş bir ek katman, geçişe hazırlığın parçası olabilir.

Sıkça Sorulan Sorular

ERP değiştirmek mi, ek modül yazdırmak mı daha ucuz?

Tek bir cevap yok; ama karşılaştırmayı doğru kalemlerle yapmak gerekir. ERP değişikliğinde lisans dışında veri taşıma, yeniden kurgulama, entegrasyonların yeniden yazılması, eğitim ve paralel dönem vardır. Ek katmanda ise geliştirme bedeli, gerekebilecek üretici lisansları ve sürüm takibi için bakım vardır. İki tarafı birkaç yıla yayarak karşılaştırın.

Ek modül yazdırırsak ERP'mize zarar verir mi?

Kayıtlar ürünün resmî arayüzünden yazılırsa, programın kendi doğrulamaları çalışır ve hatalı kayıt baştan reddedilir. Risk, doğrudan veritabanına yazan bağlantılarda büyür; bu yüzden yazmayı yalnızca resmî arayüzden yapıyoruz. Projeye salt okuma pilotuyla başlamak da riski en aza indirir.

Programımızın üreticisi ek geliştirmeye izin veriyor mu?

Programın belgelenmiş bir arayüzü varsa, üretici dışarıdan bağlanmayı zaten bu arayüzle öngörmüş demektir. Kullanımın ayrı bir lisansa, API anahtarına ya da bayi kanalından açılan kimlik bilgilerine bağlı olup olmadığı üründen ürüne değişir. Bu, keşifte yetkili bayinizle birlikte teyit edilen ilk kalemdir.

ERP değişikliği planlıyoruz; şimdi ek katman yaptırmak boşa mı gider?

Ek katman ERP'ye doğrudan değil bir ara katman üzerinden bağlanırsa boşa gitmez. ERP değiştiğinde yalnızca bağlantı parçası yeniden yazılır, saha ekranları kalır. Geçiş çok yakınsa, kapsamı dar tutup kalıcı kurguyu geçişten sonraya bırakmak daha doğru olabilir.

Bu kararı kiminle vermeliyiz?

Muhasebe tarafı için mali müşavirinizle, ürün ve lisans tarafı için yetkili bayinizle, saha ihtiyacı için de süreci yürüten ekip liderleriyle. Biz bayi olmadığımız için hangi programı kullandığınıza göre tavsiyemiz değişmez; elimizdeki kurulum başlangıç noktasıdır.

Sonraki adım: sorunun nerede olduğunu birlikte ayıralım

ERP değiştirmek mi, mevcut programın üstüne fabrikaya özel yazılım ya da ek katman eklemek mi sorusunu, şikâyetlerinizi programın çekirdeği ve kenarı diye ayırarak birlikte cevaplayabiliriz. Görüşmeye kullandığınız programı ve sürümünü, en çok zaman kaybettiren üç süreci ve yanında biriken Excel dosyalarını getirmeniz yeterli. Çözüm ERP değişikliğiyse bunu da açıkça söyleriz. İlk keşif görüşmesi online ve ücretsizdir; kapsam netleşince sabit fiyat ve yazılı kapsam veriyoruz, teslim sonrası 15 gün ücretsiz hata düzeltme standardımızdır. Bizimle iletişime geçin; isterseniz WhatsApp'tan da yazabilirsiniz.