ERP Lisanslama, Danışmanlık ve Geliştirme

Önce ERP'yi değil, ihtiyacı analiz ediyoruz

ERP projesinin başarısı yalnızca seçilen yazılıma bağlı değildir. İş süreçlerinin doğru modellenmesi, verinin güvenilir olması, entegrasyon mimarisinin doğru kurulması, kullanıcıların sisteme adapte edilmesi ve yapılan geliştirmelerin sürdürülebilir olması en az ürün seçimi kadar belirleyicidir.

Bu yüzden bir projeye başlarken ilk sorumuz "hangi ERP'yi almalısınız?" değildir. Önce şu soruların yanıtını arıyoruz:

• Hangi süreçler bugün sağlıklı çalışıyor?
• Hangi süreçler ERP dışında, elle yürütülüyor?
• Hangi veriye güvenilemiyor ve bunun kaynağı nedir?
• Kullanıcılar hangi noktada sistemden çıkıp Excel'e geçiyor?
• Hangi raporlar farklı sistemlerden birleştirilerek hazırlanıyor?
• Hangi entegrasyonlar eksik veya izlenemiyor?
• Mevcut ERP'nin teknik ya da fonksiyonel sınırına gerçekten ulaşılmış mı?

Bu analiz sonucunda genellikle üç yoldan biri ortaya çıkar.

Mevcut ERP'yi geliştirmek

Sistemin temel fonksiyonları yeterliyse eksik süreçleri geliştirme, entegrasyon veya çevre uygulamalarla tamamlamak en doğru yatırım olabilir. Bu durumda çekirdek kayıt yapısı korunur, risk dar bir alanda kalır.

ERP dönüşümü

Mevcut sistem fonksiyonel, teknolojik veya operasyonel olarak işletmenin ihtiyacını karşılamıyorsa yeni ERP alternatifleri değerlendirilir. Bu karar tek bir şikâyete değil, ölçülmüş bir tabloya dayanmalıdır.

Hibrit mimari

ERP çekirdeği korunurken işletmeye özel süreçler B2B, WMS, POS, mobil veya özel uygulamalarla ERP çevresinde konumlandırılır. Çekirdek standart kalır, ayrışan süreç kendi yerinde çözülür.

Bizim için doğru sonuç her zaman "ERP değiştirin" değildir. Analiz mevcut sistemin geliştirilebilir olduğunu gösteriyorsa bunu açıkça söylüyoruz.

ERP'yi değiştirmek mi, mevcut sistemi geliştirmek mi?

ERP değişimi yüksek etkili bir karardır: veri, süreç, kullanıcı alışkanlığı ve entegrasyonların tamamı aynı anda değişir. Yeni sisteme geçmeden önce mevcut ERP'nin gerçekten sınırına ulaşıp ulaşmadığını ölçmek gerekir.

Mevcut sistemi geliştirmek mantıklı olabilir:

• çekirdek finans, stok veya sipariş süreçleri sağlıklı çalışıyorsa,
• sorun belirli birkaç süreçte yoğunlaşıyorsa,
• entegrasyon eksikleri ERP dışından çözülebiliyorsa,
• mevcut sistem teknik olarak sürdürülebilir durumdaysa.

ERP dönüşümü daha güçlü bir seçenek hâline gelebilir:

• kritik fonksiyonel ihtiyaçlar sürekli geçici çözümlerle karşılanıyorsa,
• sistemin teknoloji veya ürün desteği sürdürülebilir değilse,
• veri ve entegrasyon kabiliyeti büyümeyi sınırlıyorsa,
• çok şirketli veya uluslararası yapı mevcut sistem tarafından karşılanamıyorsa,
• bakım ve geliştirme maliyeti işletme için kabul edilebilir seviyenin üzerine çıktıysa,
• kullanım deneyimi ve operasyonel verimsizlik ölçülebilir iş kaybına neden oluyorsa.

Karar çerçevesinin ayrıntısını ERP seçim rehberinde anlatıyoruz.

Hizmet kapsamımız

ERP süreç analizi ve fit-gap

Mevcut süreçleri bölüm bazında analiz ediyor; standart fonksiyonla karşılanan, konfigürasyon gerektiren, geliştirme gerektiren ve entegrasyonla çözülecek alanları ayrıştırıyoruz.

Çıktı yalnızca bir sunum değildir: proje kapsamına ve kabul kriterlerine temel oluşturabilecek, sözleşme ekine girebilecek bir çalışmadır.

ERP seçim danışmanlığı

ERP alternatiflerini yalnızca demo ekranları üzerinden karşılaştırmıyoruz. Kritik iş süreçlerini ve teknik gereksinimleri önem derecesine göre sınıflandırıyor; aday sistemlerin bu gereksinimleri standart fonksiyon, konfigürasyon, geliştirme veya entegrasyon yoluyla nasıl karşıladığını değerlendiriyoruz.

Değerlendirmede birlikte ele alınan başlıklar:

Amaç "en yüksek puanı alan ERP"yi bulmak değil, işletmenin kritik süreçlerini kabul edilebilir maliyet ve riskle sürdürülebilir biçimde karşılayabilecek yapıyı belirlemektir.

Çoklu ERP ekosistemlerinde uygulama ve geliştirme

Tek bir ERP markasını her işletme için doğru kabul etmiyoruz. CANIAS ve Ainos ERP ekosistemlerinde proje ihtiyacına göre süreç uyarlama, entegrasyon, raporlama, iş akışı, veri dönüşümü ve geliştirme çalışmaları yürütüyoruz. Her iki ekosistemde hizmet kapsamımızı ayrıntılı anlattığımız sayfalar var: CANIAS ERP danışmanlığı ve AinosERP danışmanlığı.

Ekosistem hangisi olursa olsun aynı disiplini uyguluyoruz: standart dışına çıkan her uyarlama belgelenir, sürüm yükseltmeye etkisi kayıt altına alınır. Uyarlama borcu, yükseltmeyi yıllar sonra kilitleyen en yaygın sebeplerden biridir.

Ürünlerin hangi koşulda hangisinin daha savunulabilir olduğunu ERP ekosisteminde alternatifler yazısında karşılaştırıyoruz.

Üretim ERP ve maliyet yönetimi

Üretim ERP projelerinde amaç yalnızca üretim emri açmak değildir; planlanan üretim ile gerçekleşen tüketim ve operasyon verilerinin aynı model üzerinde izlenebilmesi gerekir.

İşletmenin üretim tipine göre ürün ağacı/reçete, rota ve operasyon, iş merkezi veya kaynak yapısı, malzeme tüketimi, işçilik ve makine süreleri, fire ve yeniden işleme, fason operasyon, lot/seri izlenebilirliği, kapasite, MRP, kalite ve üretim maliyeti bileşenlerini ihtiyaç doğrultusunda ERP içerisinde modelliyoruz. Her işletmede bu bileşenlerin tamamı gerekmez; alternatif rota veya fason operasyon yalnızca gerçekten kullanılıyorsa kurulur.

Maliyet modelinde tek bir yöntem dayatmıyoruz. Standart maliyet, gerçekleşen maliyet, aktivite/makine/işçilik maliyetleri ve genel gider dağıtım yaklaşımı işletmenin muhasebe ve üretim modeline göre birlikte tasarlanır. Ayrıntısı üretim firmaları için ERP rehberinde.

ERP veri göçü

Veri göçünün kapsamı "kaç yıllık veri taşınacak?" sorusuyla belirlenmez. Taşınacak veriyi üç kategoride ele alıyoruz:

• Ana veriler: cari, stok, ürün ağacı, hesap planı, fiyat, tedarikçi, çalışan.
• Açık işlemler: açık sipariş, açık satın alma, açık bakiye, açık üretim, stok.
• Tarihsel işlemler: geçmiş satış, satın alma, finans, üretim ve maliyet hareketleri.

Geçmiş verinin yeni sistemde yeniden yapılandırılması bazı durumlarda mümkündür; ancak kaynak verinin kalitesi ve eksikliği sonucun doğruluğunu sınırlayabilir. Bu nedenle her veri kümesi için taşınacak mı, arşivlenecek mi, dönüştürülecek mi, yalnızca raporlama için mi tutulacak kararı proje başında verilir ve doğrulama yöntemi yazılı tanımlanır.

ERP entegrasyonları

ERP çoğu işletmede tek başına çalışmaz. Banka, e-fatura ve e-irsaliye, B2B bayi portalı, perakende POS, WMS, e-ticaret ve pazaryeri kanalları, CRM, saha satış, PDKS, MES, üretim makineleri, kantar ve üçüncü taraf servisler arasında veri akışı gerekebilir.

Entegrasyon tasarımında yalnızca bağlantının kurulmasına değil; kayıt sahipliği, hata yönetimi, tekrar eden isteklerin çift kayıt üretmemesi, mutabakat, yetkilendirme, log, yeniden deneme ve operasyonel izlenebilirlik konularına odaklanıyoruz. Yöntemi API entegrasyonu sayfamızda ve banka entegrasyonu rehberinde anlatıyoruz.

Grup şirketleri ve konsolidasyon

Çok şirketli yapılarda tüm şirketlerin aynı ERP'yi kullanması tek başına konsolidasyon anlamına gelmez. Proje kapsamında ihtiyaç doğrultusunda ortak veya ayrı hesap planı, ortak ana veri yönetimi, şirketler arası satış ve satın alma, bakiyeler, grup içi işlemler, raporlama para birimi, eliminasyon gereksinimleri, yönetim raporlaması ve finansal konsolidasyon değerlendirilir.

Bazı yapılarda ERP'nin kendi fonksiyonları konsolidasyon veya yönetim raporlaması için yeterli olmayabilir; bu durumda ek bir raporlama katmanı gerekebileceğini proje başında açıkça belirtiyoruz.

Mevcut ERP'yi iyileştirme

ERP'den beklenen verimin alınamaması her zaman ürünün yetersiz olduğu anlamına gelmez. Sorun bazen yanlış veya eksik süreç tasarımı, yetersiz ana veri, gereksiz manuel operasyon, raporlama yapısı, entegrasyon eksikleri, performans problemi, yanlış yetkilendirme veya kullanıcı adaptasyonu kaynaklıdır.

Bu nedenle yeni ERP kararı vermeden önce mevcut sistemi teknik ve fonksiyonel olarak değerlendiriyoruz. Mevcut yatırım geliştirilebilir durumdaysa bunu açıkça öneriyoruz.

ERP proje yaklaşımımız

1. Discovery ve süreç analizi. İş akışları, kritik problemler, veri kaynakları ve entegrasyonlar belirlenir.
2. Fit-gap ve çözüm tasarımı. Standart fonksiyon, konfigürasyon, geliştirme ve entegrasyon alanları ayrıştırılır.
3. Kapsam ve kabul kriterleri. Teslimatlar "modül devreye alındı" gibi değil, test edilebilir kriterlerle tanımlanır.
4. Konfigürasyon ve geliştirme. ERP'nin standart kabiliyeti mümkün olduğunca korunur; gerekli özelleştirmeler belgelenir.
5. Entegrasyon ve veri göçü. Veri kaynakları, kontrol toplamları, hata senaryoları ve mutabakat adımları tanımlanır.
6. Test ve UAT. Anahtar kullanıcılarla gerçek iş senaryoları test edilir.
7. Geçiş stratejisi. Projenin riskine göre pilot, fazlı geçiş, paralel çalışma veya kontrollü cutover yaklaşımlarından uygun olanı seçilir.
8. Canlıya geçiş ve hypercare. Kritik kontroller tamamlandıktan sonra canlıya geçilir; ilk dönemde yoğun izleme ve destek uygulanır.

ERP'de yapay zekâyı nerede kullanıyoruz?

Yapay zekâyı ERP'nin denetlenebilir finans, stok ve maliyet kayıtlarında doğrulanabilir iş kurallarının yerine koymuyoruz. Uygun kullanım senaryolarında ise kontrollü biçimde kullanıyoruz: belge sınıflandırma, dekont açıklaması ayrıştırma, talep tahmini, anomali tespiti, doğal dil ile raporlama, yönetici asistanlığı ve karar destek.

AI tarafından üretilen bir sonucun finansal veya operasyonel kayda dönüşeceği senaryolarda doğrulama ve yetkilendirme mekanizması ayrıca tasarlanır: hangi eşik altında otomatik işlendiği, kimin onayladığı ve sonucun nasıl geri alınabildiği baştan tanımlanır.

ERP maliyeti nasıl değerlendirilir?

Lisans bedeli toplam maliyetin yalnızca bir kalemidir. Projenin yapısına göre şu kalemler doğabilir: lisans/abonelik, altyapı veya bulut, analiz, danışmanlık, konfigürasyon, geliştirme, entegrasyon, veri temizliği, veri göçü, test, eğitim, iç proje ekibi zamanı, canlıya geçiş, hypercare, bakım ve destek, sürüm yükseltme ve üçüncü taraf lisanslar. Paralel çalışma gerekiyorsa bu da ayrı bir kalem olarak bütçelenir.

Kalemlerin ağırlığı her projede aynı değildir: bazı projelerde lisans önemli bir maliyet kalemiyken, yoğun uyarlama, veri dönüşümü veya entegrasyon gerektiren projelerde uygulama ve iç iş gücü toplam maliyet içinde benzer ya da daha yüksek ağırlığa ulaşabilir.

Kalem kalem hesabı ERP maliyeti nasıl hesaplanır yazısında anlatıyoruz; kendi kapsamınıza göre karmaşıklık ve kalem listesi çıkarmak için ERP yatırım ve TCO ön değerlendirme aracını kullanabilirsiniz.

ERP projesinde neden FAB Teknoloji?

Tek ürün perspektifiyle başlamıyoruz

Değerlendirmeye ürün karşılaştırmasıyla değil, işletmenin süreç ve veri gerçeğiyle başlıyoruz.

Danışmanlık ve geliştirmeyi birlikte yürütüyoruz

Süreç analizinden çıkan yol haritasını yalnızca rapor olarak bırakmıyoruz. ERP konfigürasyonu, geliştirme, entegrasyon, veri göçü ve çevre uygulamaları dahil gerekli teknik çalışmaları aynı proje çatısı altında yürütebiliyoruz. Böylece analiz ile uygulama, birbirini suçlayan iki ayrı proje hâline gelmez.

ERP'nin çevresindeki sistemleri de geliştiriyoruz

B2B, POS, banka, mobil, WMS veya işletmeye özel uygulama gerektiğinde ERP çevresindeki mimariyi de kurabiliyoruz. Bunlar bizim için ERP projesinin dışında kalan işler değildir.

Üretim ve entegrasyon tarafına teknik derinlikle yaklaşıyoruz

ERP'yi yalnızca finans ve muhasebe uygulaması olarak ele almıyoruz; üretim modeli, veri toplama ve entegrasyon mimarisi projenin merkezinde yer alıyor.

Mevcut yatırımınızı korumayı da seçenek olarak görüyoruz

Yeni ERP gerekmiyorsa mevcut sistemi geliştirmek proje seçeneklerinden biridir ve bunu proje kaybetme pahasına söylüyoruz.

Bağımlılık yaratmamayı önemsiyoruz

Dokümantasyon, kilit kullanıcı eğitimi, entegrasyon dokümanı, değişiklik kayıtları, veri sahipliği ve rol/yetki yapısı projenin devralınabilir olmasını sağlar. Projenin veri sahipliği, geliştirme kapsamı, erişim hakları, dokümantasyon ve devralınabilirlik koşullarının sözleşme aşamasında açık biçimde tanımlanmasını öneriyoruz.

Hangi sektörlerde çalışıyoruz?

Gıda ve içecek, plastik, metal ve makine, ambalaj, matbaa, tekstil, mobilya, çok şubeli perakende, sağlık ve bankacılık/finans. Her sektörün ERP'den beklediği kritik yetenek farklıdır; sektör sayfalarında bunu madde madde yazdık.

Demo ve sözleşme öncesi yazılı isteyeceğiniz sorular

• Bu ekranı kim değiştirebilir, ne kadar sürede, hangi maliyetle?
• API ve veri erişimi lisansa dâhil mi? Çağrı veya hacim sınırı var mı?
• Yapılan uyarlamalar sürüm yükseltmede hangi yöntemle korunuyor?
• Aynı sektörde bizim ölçeğimizde kaç canlı kurulum var?
• Bize atanan ekip sözleşmede isimli mi ve aynı anda kaç projede çalışıyor?
• Kapsam dışı taleplerde birim fiyat ve süreç ne?
• Uyarlama dokümanı, konfigürasyon kayıtları ve veri hangi koşullarda bize teslim ediliyor?

Danışmanlık firması değerlendirmesinin tamamını ERP danışmanlık firması nasıl seçilir yazısında bulabilirsiniz.

Sık sorulan sorular

Hangi ERP ürünleriyle çalışıyorsunuz?

Tek bir ERP ürününe bağlı değiliz. CANIAS ve Ainos ERP ekosistemlerinde danışmanlık, geliştirme, entegrasyon ve dönüşüm projeleri yürütüyoruz. Proje kapsamı ve kullanılacak yöntem, işletmenin mevcut sistemi ve ihtiyaçları doğrultusunda belirlenir.

ERP'mizi değiştirmeden sizinle çalışabilir miyiz?

Evet. ERP danışmanlığı yalnızca yeni ERP kurulumu anlamına gelmez. Mevcut ERP üzerinde süreç analizi, entegrasyon, geliştirme, raporlama, veri modeli ve performans iyileştirme çalışmaları da yapıyoruz.

Yeni ERP gerektiğine nasıl karar veriyorsunuz?

Kararı tek bir soruna göre vermiyoruz. Fonksiyonel uyum, teknik sürdürülebilirlik, entegrasyon kabiliyeti, kullanıcı ihtiyaçları, geliştirme yükü, toplam sahip olma maliyeti ve büyüme hedeflerini birlikte değerlendiriyoruz.

ERP projesi ne kadar sürer?

Proje süresi şirket sayısı, kullanıcı sayısı, modül kapsamı, üretim karmaşıklığı, entegrasyonlar, veri göçü ve özel geliştirme ihtiyacına göre değişir. Bu nedenle sağlıklı süre tahmini süreç ve kapsam analizi sonrasında yapılmalıdır. Süre taahhüdü isterken kapsamın da sabitlendiğinden emin olun.

ERP veri göçünde tüm geçmiş taşınmalı mı?

Her zaman değil. Ana veriler, açık işlemler ve tarihsel veriler ayrı değerlendirilmelidir. Bazı geçmiş verilerin yeni ERP'ye taşınması yerine arşiv veya raporlama ortamında tutulması daha doğru olabilir.

ERP projesinde paralel çalışma şart mı?

Hayır. Geçiş yöntemi projenin riskine göre belirlenir. Paralel çalışma, pilot, fazlı geçiş veya kontrollü cutover seçeneklerinden uygun olanı kullanılabilir.

ERP'de özel geliştirme kötü müdür?

Hayır. İşletmeye gerçek değer sağlayan süreçlerde özel geliştirme gerekli olabilir. Önemli olan geliştirmelerin belgelenmesi, sürüm yükseltmeye etkisinin bilinmesi ve platformun desteklediği yöntemlerle sürdürülebilir biçimde uygulanmasıdır.

ERP seçiminde en önemli kriter nedir?

Tek bir kriter yoktur. Fonksiyonel uyum, teknik mimari, entegrasyon, toplam maliyet, uygulama ekosistemi ve sürdürülebilirlik birlikte değerlendirilmelidir.

Canlıya geçişte veri kaybı riski nasıl yönetiliyor?

Geçiş öncesi tam yedek, veri göçünün kontrol toplamlarıyla doğrulanması, kabul kriterleri sağlanmadan geçilmemesi ve yazılı bir geri dönüş planı ile. Projenin riskine göre pilot veya fazlı geçiş de bu kontrolün parçası olabilir.

Kullanıcı eğitimini kim veriyor?

Rol bazlı eğitim veriyoruz: her rol yalnızca kendi ekranlarını öğreniyor. Ayrıca kilit kullanıcı modeliyle kurum içinden sistemi taşıyacak kişileri yetiştiriyoruz. Bu, sonraki her küçük değişiklikte danışmanlığa bağımlı kalmamak için önemlidir.