ERP Seçimi ve Geçiş Rehberi: Riski Tek Güne Yığmadan
ERP seçerken hangi sorular sorulmalı, geçiş nasıl planlanır? Değerlendirme kriterleri, veri hazırlığı, paralel çalışma ve modül modül geçiş yöntemi.
ERP projelerinde en pahalı karar yazılım seçimi değildir. Geçiş yöntemidir.
Doğru yazılımı yanlış yöntemle devreye alan işletme aylarca çalışamaz. Ortalama bir yazılımı doğru yöntemle devreye alan işletme, sistemi zamanla iyileştirir. Bu yazı ikisini de ele alıyor — ama ikincisine daha çok yer ayırıyor, çünkü genelde daha az konuşulan taraf o.
Bölüm 1 — ERP seçimi
Önce süreç, sonra yazılım
Demo izlemeye başlamadan önce cevaplanması gereken sorular:
- Bugün hangi veriyi kaç kez giriyorsunuz?
- Hangi kararı veri olmadığı için sezgiyle veriyorsunuz?
- Ay sonunda hangi rakamı bulmak saatler alıyor?
- Hangi süreç tamamen bir kişinin bilgisine bağlı?
- Müşteriye termin verirken neye bakıyorsunuz?
Bu beş sorunun cevabı, ihtiyaç listenizin kendisidir. Cevaplamadan izlenen demolar, satıcının gösterdiği özelliklerin listesine dönüşür — sizin ihtiyacınızın değil.
Değerlendirme kriterleri
| Kriter | Neden önemli | Nasıl sınanır |
|---|---|---|
| Süreç uyumu | Özelleştirme maliyetini belirler | Kendi senaryonuzla demo isteyin |
| Mevzuat uyumu | e-Dönüşüm, çek-senet, KDV tevkifatı | Canlı bir e-fatura kesimi gösterilsin |
| Veri modeli | Sonradan değiştirmek en pahalı iş | Ürün ağacı ve varyant yapısını sorun |
| Kullanılabilirlik | Benimsenmeyen sistem kullanılmaz | Sahadan bir kullanıcıya denetin |
| Entegrasyon | Banka, tezgâh, e-ticaret, üçüncü parti | API var mı, belgesi var mı |
| Ölçeklenebilirlik | Büyüyünce mimari değişmemeli | Mevcut en büyük müşterisi kaç kullanıcı |
| Destek | Sorun anında kim, ne kadar sürede | SLA yazılı mı, referans arayın |
| Toplam maliyet | Lisans buzdağının görünen kısmı | Aşağıdaki tabloyu doldurtun |
Demoda sorulacak zor sorular
Genel demolar iyi görünür. Farkı bu sorular açar:
- "Bir siparişi girip MRP çalıştırıp iş emri açıp maliyeti kapatana kadar canlı gösterir misiniz?"
Uçtan uca akış, modüller arası boşlukları ortaya çıkarır.
- "Ürün ağacında revizyon yaptığımda devam eden iş emirleri ne olur?"
- "Fire oranını nerede tanımlıyorum, maliyete nasıl yansıyor?"
- "Bu ekranı 40 kullanıcı aynı anda kullanırken ne oluyor?"
- "Kendi verimizle bir pilot kurabilir miyiz?" — En değerli soru. Kendi stok kartlarınız ve ürün
ağaçlarınızla çalışan bir pilot, on demodan fazlasını gösterir.
Toplam sahip olma maliyeti
Lisans, toplamın genelde yarısından azıdır:
| Kalem | Sıklıkla atlanır mı |
|---|---|
| Lisans / abonelik | Hayır |
| Kurulum ve danışmanlık | Hayır |
| Veri hazırlama ve aktarım | Evet |
| Özelleştirme geliştirme | Kısmen |
| Eğitim (ve tekrar eğitim) | Evet |
| Sunucu / altyapı | Kısmen |
| Yıllık bakım ve destek | Hayır |
| Sürüm yükseltme | Evet |
| İç kaynak zamanı (kendi personeliniz) | Evet |
Son kalem en çok küçümsenendir. ERP projesi, anahtar personelin zamanının önemli bir kısmını tüketir — ve bu personel aynı zamanda günlük işi yürütmektedir.
Web tabanlı mı, masaüstü mü?
Masaüstü istemci modelinin görünmeyen maliyeti sürüm dağıtımıdır: 60 kullanıcılı bir işletmede her güncelleme 60 kurulum, her yeni kullanıcı bir kurulum ziyaretidir. Üretim sahasında tablet, ofiste masaüstü, evden dizüstü kullanılacaksa bu yük katlanır.
Web tabanlı sistemlerde bu maliyet sıfırdır. Dikkat edilmesi gereken ayrım şudur: web tabanlı olmak ile bulutta olmak aynı şey değildir. Bir sistem tarayıcıdan çalışırken veritabanı yine sizin sunucunuzda durabilir.
Bölüm 2 — Geçiş
Neden "büyük patlama" başarısız olur?
Klasik yöntem: proje başlar, aylarca hazırlık yapılır, bir pazartesi tüm şirket yeni sisteme geçer.
Bu yöntemin yapısal sorunu şudur: işletme yeni sistemi gerçek veriyle ilk kez canlıya alma günü görür. O güne kadar her şey test ortamındadır. Aynı gün hem sistemi öğrenmek hem işi yürütmek zorunda kalınır.
Sonuç tanıdıktır: ilk hafta sevkiyat yavaşlar, ikinci hafta faturalar birikir, üçüncü hafta bazı bölümler Excel'e geri döner. Geri dönenler bir daha dönmez.
Alternatif: modül modül geçiş
Yeni sistem eskisinin yanında ve aynı veri üzerinde çalışmaya başlar. Bir modül gerçek veriyle tam pariteye ulaşınca kullanıma açılır. Ekipler hazır oldukları modülde yeni sisteme, diğerlerinde eskisinde kalır.
Bu yöntemin şartı, iki sistemin aynı veritabanını kullanmasıdır. Ayrı veritabanları arasında senkronizasyon kurmak, çözdüğünden fazla sorun yaratır.
| Tek seferde geçiş | Modül modül geçiş | |
|---|---|---|
| Risk dağılımı | Tek güne yığılır | Modüllere bölünür |
| Geri dönüş | Zor, maliyetli | Her aşamada mümkün |
| Öğrenme | Aynı anda her şey | Kademeli |
| Toplam süre | Daha kısa | Daha uzun |
| Kesinti | Var | Yok |
| Ön koşul | — | Ortak veritabanı |
Toplam süre uzar. Ama işletme bu süre boyunca çalışmaya devam eder ve her adımda geri dönüş mümkündür. Kendo NX'in geçiş yaklaşımı bunun üzerine kuruludur: masaüstü Kendo ile web sürümü aynı SQL Server veritabanına bağlanır, veri taşıma projesi yoktur.
Paralel çalışma
Bazı modüllerde iki sistemi bir süre birlikte çalıştırmak (aynı işlemi ikisine de girmek) doğrulama sağlar. Faydalıdır ama maliyetlidir: çift iş demektir.
Pratik kural: paralel çalışmayı finans ve muhasebe gibi kritik ve sayısal olarak doğrulanabilir modüllerde, bir dönemle sınırlı uygulayın. Tüm modüllerde süresiz paralel çalışma, ekibi tüketir.
Bölüm 3 — Veri hazırlığı
Projenin en sıkıcı ve en belirleyici aşaması. Kötü veriyle açılan sistem, ilk haftada güven kaybeder.
Hangi veriler taşınır?
| Veri | Kapsam | Zorluk |
|---|---|---|
| Cari kartlar | Aktif olanlar + bakiyeler | Orta — mükerrer kayıt temizliği |
| Stok kartları | Tümü, birim ve barkodlarla | Orta |
| Stok bakiyeleri | Sayım sonrası açılış | Düşük |
| Ürün ağaçları | Aktif ürünler | Yüksek |
| Rotalar | Aktif ürünler | Yüksek |
| Açık siparişler | Kapanmamış olanlar | Orta |
| Hesap planı ve bakiyeler | Tümü | Düşük |
| Geçmiş hareketler | Genelde taşınmaz | — |
Geçmiş hareketleri taşımamak yaygın ve genelde doğru bir karardır: eski sistem raporlama için bir süre erişilebilir tutulur. Aynı veritabanını kullanan bir geçişte bu sorun zaten ortadan kalkar.
Veri temizliği kontrol listesi
- Mükerrer cari kartlar birleştirildi mi? (aynı firma üç farklı kodla var mı)
- Kullanılmayan stok kartları pasife alındı mı?
- Birim dönüşümleri tanımlı ve tutarlı mı? (kg/metre, adet/paket)
- Ürün ağaçlarında döngüsel referans var mı? (A, B'yi içerirken B de A'yı)
- Ürün ağaçları son revizyonu yansıtıyor mu?
- Fire oranları tanımlı mı?
- Tedarik süreleri gerçek mi, yoksa temenni mi?
- Stok sayımı yapıldı mı? (açılış bakiyesi buradan gelir)
Son madde atlanamaz. Yanlış açılış stoğuyla başlayan bir sistemde MRP ilk günden itibaren yanlış hesaplar ve kullanıcılar sisteme değil kendi defterlerine güvenmeye devam eder.
Bölüm 4 — Devreye alma sırası
Modül modül geçişte önerilen sıra, bağımlılık yönünü izler:
1. Temel veri. Cari, stok, birim, fabrika tanımları. Her şeyin ön koşulu.
2. Satınalma ve stok. Görece bağımsız, hızlı fayda verir, veri doğruluğunu erken sınar.
3. Satış ve e-Dönüşüm. Belge akışı kritik; e-Fatura tarafı burada devreye girer.
4. Üretim: ürün ağacı ve iş emri. Veri hazırlığı en ağır adım.
5. Planlama: MRP. Ancak 1–4 doğru çalışıyorsa anlamlı sonuç verir.
6. Saha: üretim yürütme. Operatör benimsemesi zaman ister.
7. Finans ve muhasebe. Genelde dönem başında geçilir.
8. Raporlama ve analiz. Veri birikince değer üretir.
MRP'yi erken devreye almak, projelerdeki en yaygın sıra hatasıdır: stok doğruluğu ve ürün ağacı hazır değilken çalıştırılan MRP saçma öneriler üretir ve kullanıcı bir daha açmaz.
Bölüm 5 — Benimsenme
Teknik olarak başarılı, pratikte kullanılmayan sistemler bu bölümün eksikliğinden doğar.
- Eğitimi son haftaya bırakmayın. Kullanıcı sistemi kendi verisiyle, kendi ekranında görmeli.
- Her bölümden bir "anahtar kullanıcı" belirleyin. Sorular önce ona gider; hem yük dağılır hem
sahiplenme oluşur.
- Neden'i anlatın. "Bu ekranı doldur" ile "bu kayıt sayesinde termin verirken tahmin yürütmeyeceğiz"
arasında ciddi fark vardır.
- Erken kazanç gösterin. İlk aylarda somut bir iyileşme (aranan bilginin saniyeler içinde
bulunması gibi) projeyi taşır.
- Excel'e dönüş yollarını kapatın. Paralel bir gölge sistem devam ediyorsa ERP hiç
tamamlanmayacaktır.
Özet
- Yazılım seçmeden önce kendi süreçlerinizi yazın; demoyu kendi senaryonuzla isteyin.
- Lisans, toplam maliyetin yarısından azıdır; veri hazırlığı ve eğitim atlanan kalemlerdir.
- Tek seferde geçiş riski tek güne yığar; modül modül geçiş riski böler.
- Modül modül geçişin şartı, iki sistemin aynı veriyi kullanmasıdır.
- Veri hazırlığı en sıkıcı ve en belirleyici aşamadır — özellikle ürün ağaçları ve açılış stoğu.
- MRP'yi erken açmayın; önce stok doğruluğu ve ürün ağacı.
Sık sorulan sorular
ERP projesi ne kadar sürer?
Tek seferde geçişte tipik aralık 6–18 aydır ve sürenin büyük kısmı veri hazırlığına gider. Modül modül geçişte ilk modül birkaç haftada devreye girebilir; toplam süre uzasa da işletme bu süre boyunca kesintisiz çalışır.
Eski verilerimizi yeni sisteme taşımak zorunda mıyız?
Açık bakiyeler, açık siparişler ve temel veri taşınmalıdır. Geçmiş hareketleri taşımak genelde gereksiz ve pahalıdır; eski sistem raporlama için bir süre erişilebilir tutulur. Aynı veritabanını kullanan bir geçişte bu sorun ortadan kalkar.
ERP danışmanı şart mı?
Süreçlerinizi yeniden tasarlamanız gerekiyorsa faydalıdır. Ancak danışmanın işi süreç kararlarını sizin yerinize vermek değil, seçenekleri ve sonuçlarını göstermektir. Kararı verecek kişilerin işletme içinden olması gerekir.
Özelleştirme yaptırmalı mıyım?
Rekabet avantajı sağlayan süreçlerde evet, standart işlerde hayır. Her istisna kodlandığında sistem zamanla güncellenemez hâle gelir. İyi bir test: "bu istisna olmadan iş yapamaz mıyız?" Cevap "zorlanırız" ise özelleştirmeyin, süreci uyarlayın.
Geçiş sırasında üretim durur mu?
Tek seferde geçişte pratikte yavaşlama kaçınılmazdır. Modül modül geçişte durmaz — eski sistem çalışmaya devam ederken yeni modüller sırayla devreye alınır ve her aşamada geri dönüş mümkündür.