Özel Yazılım mı, Hazır Paket mi? Karar Rehberi

Toplantıda soru hep aynı yerden geliyor: "Bunun hazır bir programı yok mu?" Genelde var. Demo izlenir, ekranlar düzgün görünür, sözleşme imzalanır. Üç ay sonra sipariş sorumlusu, paketin yapamadığı işi kendi tuttuğu bir listede takip ediyordur. Tersi de oluyor: sıfırdan yazdırılan panel yedi ay sürer, canlıya çıktığında yaptığı iş piyasadaki herhangi bir paketin standart modülüdür. İki hatanın kaynağı aynı yer: karar süreç bazında değil, tek parça bir "sistem" üzerinden veriliyor.

Sorunun doğru hali "hangisi daha iyi" değil. Hangi süreç hangi tarafta dursun? Bir işletmenin ön muhasebesiyle iade operasyonu aynı cinsten iş değildir. Birini pakete bırakmak akıllıdır, diğerini bırakmak pahalıya patlar.

İki seçeneği aynı tabloda görmek

Karşılaştırma tablosu ancak satırları ölçülebilir olduğunda işe yarar. "Esnek", "güçlü", "ölçeklenebilir" gibi sıfatlar tabloda yer kaplar ama karar üretmez. Aşağıdakiler sahada gerçekten fark yaratan satırlar.

Tabloda tek başına kazanan bir sütun yok. Zaten olsaydı bu tartışma yıllardır sürmezdi.

Hazır paket ne zaman doğru karardır?

• Süreç standart ve sektörde yaygınsa: ön muhasebe, e-Fatura ve e-Arşiv, bordro, temel CRM. Bunları sıfırdan yazdırmak, çözülmüş bir problemi ikinci kez çözmek olur.
• Hız, esneklikten kıymetliyse. Sezona altı hafta kalmışsa doğru cevap genelde pakettir.
• Süreç henüz oturmamışsa. Paket, süreci öğrenmenin ucuz yoludur; ne istediğinizi bilmeden yazdırdığınız yazılım iki kez yazılır.
• Mevzuat sürekli değişiyorsa ve takibi sağlayıcıya bırakmak istiyorsanız.
• İşletmede yazılım tarafını sahiplenecek kimse yoksa. Özel yazılımın görünmeyen şartı, karşı tarafta karar verebilen bir muhatabın olması.

Faturalama tarafı bunun tipik örneği; orada seçenek listesi zaten dar. e-Fatura ve e-Arşiv belgesi kendi sunucunuzdan doğrudan alıcıya gitmiyor, GİB'in tanımladığı yöntemlerden biriyle iletiliyor; işletmelerin büyük kısmı bunu portal ya da bir entegratör üzerinden yapıyor. Kendi yazılımınızı yazsanız bile sonuçta o kanalın servisine bağlanırsınız. Belge formatları, senaryolar ve GİB tarafındaki akış zaman zaman değişiyor; bunu kendi kodunuzda kovalamanın işletmeye getirdiği bir katkı yok. Konunun ayrıntısını e-Fatura ve e-İrsaliye entegrasyonu yazısında ele almıştık. Aynı mantık ERP çekirdeği için de geçerli; hangi paketin size uyduğuna karar verirken ERP programı seçim kriterleri iyi bir başlangıç.

Özel yazılım ne zaman zorunlu hale gelir?

• Süreç, rakiplerinizden ayrıştığınız yerse. Paket sizi rakibinizle aynı hale getirir; farkınız ekrandan silinir.
• Birden fazla sistemi birbirine bağlamanız gerekiyorsa. ERP, pazaryeri, kargo firması ve muhasebe aynı anda konuşacaksa ortada bir paketin değil, bir ara katmanın işi vardır.
• Excel'ler operasyonun görünmez omurgası haline geldiyse. Bu eşiği Excel'den özel panele geçiş yazısında sinyalleriyle anlatmıştık.
• Paketin "yapamıyor" dediği tek bir madde, işin can damarıysa.
• Lisans kullanıcı başına ücretlendiriliyorsa ve depo, çağrı merkezi, saha ekibi gibi kalabalık gruplar sisteme girecekse.

Sinyali rakama çevirmek

"Paket bize dar geliyor" cümlesi ölçülebilir hale gelmeden karar verilmemeli. En pratik ölçü, paketin açığını kapatmak için harcanan insan saati. Günde 250 sipariş çıkaran bir mağazada iki kişi her gün ikişer saatini pazaryeri siparişlerini ERP'ye elle girmeye ayırıyorsa, ayda 80 saat eder. O 80 saat hiçbir faturada görünmez ama her ay ödenir. İkinci ölçü hata oranı: 3.000 kalemlik bir katalogda ayda kaç yanlış sevkiyat, kaç iptal, kaç düzeltme fişi çıkıyor? Bu iki rakamı bir ay boyunca tutan işletme, kararı tartışarak değil toplayarak veriyor.

Üç yıllık toplam maliyet nasıl çıkarılır?

Teklifleri yan yana koyarken en sık yapılan hata, yalnızca faturalanan kalemleri toplamak. Aşağıdaki tabloda fiyat yok, bilerek yok; her işletmede rakamlar farklı. Önemli olan hangi kalemin nerede durduğu ve hangisinin hesap dışında kalma ihtimalinin yüksek olduğu.

Beşinci satır kararların çoğunu tek başına çeviriyor. Manuel iş hesaba katılmadığında karşılaştırma her zaman paketi kazandırır, çünkü paketin eksiği bir gider kalemi olarak değil, mesai olarak ödenir.

Hazır paketin faturası aylık gelir, özel yazılımın faturası peşin gelir. Paketin yapamadığı işin faturası ise hiç gelmez; personelin mesaisinden düşer. En pahalı kalem çoğu zaman görünmeyen kalemdir.

Hibrit yaklaşım: paketi değiştirmeden üzerine inşa etmek

ERP'yi baştan aşağı özelleştirmek yerine, ERP'yi olduğu gibi bırakıp yanına özel bir uygulama koymak çoğu senaryoda daha sağlıklı. Çekirdeğe dokunulmadığı için paket güncellemeleri alınabilir, özel ihtiyaç bağımsız bir serviste yaşar. Bir tarafta hata çıktığında diğer taraf ayakta kalır. Bedava da değil: aradaki API'nin sürüm değişikliklerini takip etmek ve her güncellemeden sonra entegrasyonu sınamak sizin işiniz olur.

İade Yönetim Paneli bunun somut bir örneği: mağazanın e-ticaret altyapısı yerinde kalırken iade operasyonu ayrı bir panelde toplandı; ödeme yöntemi takibi ve müşteri bilgilendirmesi tek akışa bağlandı. Ticimax tarafında çekirdeğe dokunulmadı.

Sınır nereden geçmeli?

• Kayıt sistemi pakette kalır. Cari, stok bakiyesi, fatura ve muhasebe fişi tek yerde doğar. İki sistemde birden doğan kayıt, er ya da geç mutabakat toplantısına dönüşür.
• Operasyon ekranı özel tarafta olur. Kullanıcının günde yüz kez kullandığı ekran, işletmenin kendi diline göre yazılmalı.
• Veri yönü baştan yazılır. Fiyat, stok ve sipariş durumu iki tarafta da değişebiliyorsa hangisinin haklı sayıldığı tanımlanmadan tek satır kod yazılmaz.
• Hata kuyruğu görünür olur. Aktarılamayan kayıt sessizce kaybolmaz; ekranda durur, tekrar denenir. Bu tarafın klasik tuzaklarını REST API entegrasyonu hataları yazısında topladık.

Paketi ağır özelleştirmenin bedeli

Hibritin karşıtı, paketin içine girip çekirdeği değiştirmek. İlk altı ay iyi gider. Sonra sağlayıcı yeni sürüm çıkarır, sürümü alamazsınız; çünkü değişiklikleriniz üzerine yazılacaktır. Sürüm donar, mevzuat güncellemesi gelmez, destek talebine "siz değiştirmişsiniz" cevabı döner. Paketi bir yerden sonra hem paket hem özel yazılım olarak taşımaya başlarsınız, ikisinin de maliyetiyle.

Pratikte doğru cevap çoğu zaman "ikisi birden"dir: çekirdekte hazır bir ERP, üzerinde işletmeye özel ince bir katman. Yatırım, farkın yaratıldığı yere yapılır.

Kararı projeye çevirmek

Karar verildikten sonraki sıra, kararın kendisi kadar belirleyici. Özel yazılım tarafına geçiliyorsa yürüyüş şöyle oluyor.

1. Analiz: Süreç sahipleriyle mevcut akış çıkarılır, ölçülebilir hedefler konur. Hedef "daha iyi olsun" değil, "mal kabul satırı başına dokunuş sayısı düşsün" gibi somut bir cümle.
2. Kapsam ve öncelik: İlk sürümde neyin olmayacağına da karar verilir. Kapsam dışı listesi, kapsam listesinden daha çok tartışma bitiriyor.
3. Geliştirme: Çalışan parçalar kısa aralıklarla teslim edilir; geri bildirim erken alınır. Altı ay sonra tek seferde gösterilen yazılım, altı aylık yanlış anlamayı da beraberinde getirir.
4. Paralel çalışma: Gerçek veriyle bir süre iki sistem birlikte yürür, farklar her akşam karşılaştırılır. Eski sistemin ne zaman kapatılacağına his değil, bu karşılaştırma karar verir.
5. Destek: Teslim sonrası izleme, hata müdahalesi ve iyileştirme sürer. İlk aylarda kullanıcıların hangi işi sistem dışında hallettiği kayda geçer; ikinci sürümün kapsamı büyük ölçüde o listeden çıkar.

Teklif almadan önce yazılacak bir belge daha var. Kapsam, kabul kriterleri ve entegrasyon maddeleri netleşmeden gelen fiyatlar karşılaştırılabilir olmuyor; yazılım şartnamesi nasıl hazırlanır yazısı bu bölümü madde madde anlatıyor.

Teknoloji seçimi

Backend tarafında PHP, Python ve .NET çalışıyoruz; veri MySQL'de duruyor, sık okunan sorgular Redis'te önbelleğe alınıyor. Sistemler arası iletişimi REST ve GraphQL API'leriyle, yetkilendirmeyi OAuth/JWT ile kuruyoruz. Seçimi modaya göre değil, ekibinizin sürdürebileceği yapıya göre yapıyoruz. Beş yıl sonra o kodu kimin açacağı, bugün hangi çatının popüler olduğundan daha önemli. Kapsam ve çalışma biçimi için özel yazılım geliştirme sayfasına bakabilirsiniz; sipariş, kargo ve stok uyarısı gibi tekrarlı işler ise süreç otomasyonu başlığına giriyor.

Karar öncesi kontrol listesi

Aşağıdaki soruların cevabı elinizde yoksa karar erken demektir. Hepsi bir sayfaya sığar; sığmıyorsa kapsam henüz netleşmemiştir.

• Bu süreç bizi rakiplerimizden ayırıyor mu, yoksa herkes aynısını mı yapıyor?
• Paketin eksiğini kapatmak için ayda kaç saat manuel iş yapıyoruz? Bu saati kim ölçtü?
• Üç yıl sonra bu sistemin toplam maliyeti ne olur? Kullanıcı sayısı ikiye katlanırsa fatura ne olur?
• Verimizi istediğimiz an, kullanılabilir bir formatta dışarı alabiliyor muyuz?
• Paketin yapamadığı madde gerçekten zorunlu mu, yoksa alışkanlık mı? Süreci değiştirmek yazılım yazmaktan ucuz olabilir.
• Entegre olacağı sistemin API'si var mı, dokümanı var mı, test ortamı verilebiliyor mu?
• İşletme tarafında bu projeyi sahiplenecek, karar verebilen bir kişi var mı?
• Bir yıl sonra tedarikçi değiştirmek istersek elimizde ne kalır: kod mu, veri mi, ikisi de mi?

Bu listeye dürüst cevap veren işletmelerin bir kısmı özel yazılım yaptırmaktan vazgeçiyor, bir kısmı da ertelediği projeye o hafta başlıyor. İkisi de iyi sonuç. Kötü olan, kararı demo ekranlarının parlaklığına ya da tek bir fiyat teklifine bakarak vermek.

Bu konuda nasıl yardımcı oluyoruz?

Yuog Dev olarak e-ticaret işletmelerinin ERP, entegrasyon ve otomasyon altyapısını kuruyoruz. İhtiyaç analiziyle başlıyor, ölçülebilir hedefler koyuyor ve teslim sonrasında da destek veriyoruz. Süreçlerinizi konuşmak isterseniz iletişim sayfasından bize ulaşabilirsiniz.