Dynamics NAV ve Business Central Danışmanlık: sisteminiz çalışıyor, arkasında kimse kalmadı
Dynamics NAV ve Business Central danışmanlığını, kurulum satmak için değil, kurulmuş bir sistemi ayakta tutmak için yapıyoruz. Çoğu firmada sistem çalışıyor; asıl sorun, yıllar içinde birikmiş soruları cevaplayacak kimsenin kalmaması. Rapor isteği "bu geliştirme ister" diye geri dönüyor, ay sonu kapanışı elle müdahaleyle bitiyor, geçiş sorusuna tarafsız cevap veren bulunmuyor. Biz tam bu boşlukta çalışıyoruz.
Tanıdık geldi mi?
- Kurulumu yapan firma değişti, o ekipten kimse kalmadı. Bir şey sorduğumuzda cevap alana kadar haftalar geçiyor.
- Basit bir rapor istiyoruz, 'bu geliştirme gerektirir' diye geri dönüyor. Sonuçta herkes Excel'e döküp kendi tablosunu tutuyor.
- Ay sonu maliyet kapanışında her seferinde tutmayan bir şey çıkıyor; elle müdahale etmeden dönem kapanmıyor.
- Business Central'a geçelim mi diye soruyoruz, herkes kendi sattığı şeyi anlatıyor. Kalsak ne olur, geçsek ne olur, kimse yazılı söylemiyor.
İşin iç yüzü
Miktar doğru, tutar yanlış: madde hareketi ile değer hareketi ayrı yerlerde durur
NAV ve Business Central'da bir stok hareketinin miktarı ile parası aynı satırda tutulmaz. Miktar madde hareketinde, maliyet ise ona bağlı bir ya da birden çok değer hareketinde yazar; bir mal girişinin navlunu, gümrüğü, sonradan gelen fiyat farkı ayrı değer hareketleri olarak sonradan eklenir. Bu yüzden yalnızca madde hareketinden rapor çeken herkes eninde sonunda 'miktar tutuyor ama tutar tutmuyor' noktasına gelir. Doğru rapor, iki tabloyu doğru yönde birleştirmekle başlar; yön yanlışsa aynı miktar sessizce iki kez sayılır.
Ham sorguda boş dönen alanlar: 'kayıt yok' sanılan hesaplanan alanlar
Bakiye, stok miktarı, dönem tutarı gibi alanların çoğu tabloda fiziksel olarak durmaz; kullanıcı ekranı açtığında altındaki hareketlerden anlık hesaplanır. Veritabanına doğrudan sorgu yazan biri bu alanları boş veya sıfır görür ve 'bu veri sistemde yok' sonucuna varır. Oysa veri vardır, yalnızca başka yerdedir. Rapor yazarken bu alanların kaynak hareket tablolarından yeniden hesaplanması gerekir; aksi halde rapor hata vermeden yanlış üretir ve bu, fark edilmesi en zor hata türüdür.
Numara serileri: belgenin kimliği tek bir tanımdan ilerler
Sipariş, fatura, irsaliye, cari kart, madde kartı — hepsinin numarası merkezî bir numara serisi tanımından sırayla ilerler. Bu tanım kurulumda bir kez yapılır, sonra yıllarca kimse dokunmaz; ancak yeni şirket açıldığında, yeni bir belge tipi devreye girdiğinde ya da seri sonuna gelindiğinde tıkanır veya iki kayıt aynı numarayı ister. Seriyi elle atlatmak o anki sorunu kapatır, birkaç ay sonra başka bir belgeyi bozar. Doğru çözüm seriyi kendi mekanizması üzerinden, boşluk ve mükerrer üretmeden ilerletmektir.
Boyut kurgusu: sonradan düzeltmenin bedeli en yüksek olan yapı
Masraf merkezi, proje, bölge gibi boyutlar hareketin üzerine yazıldığı anda donar. Kurulumda eksik ya da yanlış kurgulandıysa, iki yıl sonra 'gideri departman bazında görelim' dendiğinde geçmiş hareketlerde o bilgi hiç yoktur — rapor yazmakla gelmez. Geriye dönük düzeltme kapanmış dönemleri ve mizanı etkilediği için çoğu zaman yapılmaz; yapılabilen kısmı ayrı bir eşleştirme katmanıyla telafi edilir. Bu yüzden bir firmaya girdiğimizde ilk baktığımız yerlerden biri boyut kurgusudur.
Servis katmanı önbelleği: veritabanına yazdığınızı sistem görmeyebilir
NAV ve Business Central, veritabanının üstünde kendi uygulama servisini çalıştırır ve tanımların önemli bir kısmını bellekte tutar. SQL tarafından doğrudan yapılan bir değişiklik, servis o tanımı yeniden okumadığı sürece ekranda görünmez; bazen de yarım görünür ve başlangıçtakinden daha büyük bir tutarsızlık üretir. Bu yüzden veri değiştiren işlemleri kural olarak sistemin kendi servis katmanı üzerinden yaparız. SQL bizde teşhis ve okuma aracıdır, yazma aracı değil.
Nasıl çalışıyoruz
Sistemin bugünkü halini çıkarıyoruz
Sürüm, şirket sayısı, kullanılan modüller ve kurulumdan bu yana yapılmış tüm özel geliştirmelerin envanteri. Çoğu firmada böyle bir liste yoktur; ilk teslim ettiğimiz şey genelde bu envanterin kendisi olur.
Şikâyeti kendimiz tekrar üretiyoruz
'Rapor yanlış' cümlesiyle iş yapmıyoruz. Hatalı çıktıyı aynı veriyle, aynı tarih aralığında biz de üretene kadar teşhis yazmıyoruz; tekrar üretemediğimiz bir hata için çözüm de önermiyoruz.
Kurgu sorunu mu, rapor sorunu mu — ayırıyoruz
Bazı sorunlar kurulum kurgusundan gelir: maliyet yöntemi, deftere nakil grupları, birim çevrimi, boyut. Bazıları yalnızca doğru raporun hiç yazılmamış olmasıdır. Kurgu sorununun üstünü raporla örtmek sorunu görünmez yapar, çözmez; bu ayrım yapılmadan geliştirmeye başlamıyoruz.
İşi yapıyoruz
Özel rapor geliştirme, maliyet ve stok değerleme kurgusu, e-fatura ve e-irsaliye bağlantısı, yavaşlama ve kilitlenme analizi, geçmiş veride düzeltme, üretim ve depo tarafıyla entegrasyon, ATLAS'ı sisteme bağlayarak sorulara WhatsApp üzerinden cevap alınması.
Veri değiştiren her işlem: yedek, onay, servis katmanı
Sırası hiç değişmez — önce yedek, sonra sizin yazılı onayınız, sonra sistemin kendi servis katmanı üzerinden uygulama. Acil olsa bile onaysız kayıt değiştirmiyoruz; bunu istisnasız uyguluyoruz.
Kalmak mı, geçmek mi — kararı yazılı veriyoruz
Dynamics NAV'da kalmakla Business Central'a geçmek arasındaki kararı beş ölçüde yazarız: ürün desteğinin bugünkü durumu, mevcut özel geliştirmelerin taşınabilirliği, entegrasyon yükü, veri hacmi ve lisans modelinin size ne getirip ne götürdüğü. Sonuç 'şimdilik kalın' da çıkabilir; gelirimiz bu kararın yönüne bağlı değil.
Kimler için
- Dynamics NAV (2009, 2013, 2016, 2018) veya Business Central kullanan, kurulumu yıllar önce bitmiş üretici ve dağıtıcı firmalar.
- Mali işler ve muhasebe yöneticileri: ay sonu kapanışında, maliyette, stok değerlemede ya da mizanda tutmayan bir rakamla uğraşanlar.
- Bayisi olan ama bayinin gündemine giremeyen firmalar; küçük ama sürekli tekrar eden işleri hep sıraya girenler.
- Business Central'a geçiş kararını, o geçişi satacak taraftan bağımsız bir görüşle almak isteyen yöneticiler.
Kapsam dışı — yapmadıklarımız
Ne yaptığımız kadar ne yapmadığımız da önemli. Bu sayfadaki iş için aşağıdakileri üstlenmiyoruz:
- Lisans satmıyoruz, bayi değiliz. Microsoft lisansınız, kullanıcı sayınız ve yenilemeniz bizde değil, bayinizde kalır. Sizden lisans geliri elde etmediğimiz için 'geçin' demek bizim işimize yaramaz.
- Microsoft partner işlemlerini yürütmüyoruz. Ürün seviyesinde destek kaydı açma, sürüm hakkı, partner portalı işleri bayinizin sorumluluğundadır; onun yerine geçmeye çalışmıyoruz.
- Onayınız olmadan veritabanınıza yazmıyoruz. Yedek alınmadan, yazılı onay olmadan ve sistemin kendi servis katmanı dışından hiçbir kayıt değiştirilmez — talep sizden gelse bile.
- Tekrar üretemediğimiz hataya çözüm satmıyoruz. Sizin gördüğünüz hatayı biz de üretemiyorsak teşhis uydurmayız, 'bilmiyoruz, şu adımla bakalım' deriz.
- Çalışan bir kurulumu baştan kurmayı peşinen önermiyoruz. Ayakta duran bir sistemi değiştirmek, çalışmayan bir raporu düzeltmekten kat kat pahalıdır; yeniden kurulum ancak başka yol kalmadığında konuşulur.
Sık sorulanlar
Bayimiz varken sizinle çalışabilir miyiz?
Evet, en sık karşılaştığımız durum bu. Bayiniz lisans, sürüm ve ürün seviyesindeki işlerde yerinde kalır; biz günlük işleyişte takılan yerlerle ilgileniriz — rapor, kurgu, veri, entegrasyon. Aynı işi ikinci kez faturalamamak için kimin neyi üstlendiğini baştan yazılı ayırırız. Bayinizle rekabet etmek gibi bir işimiz yok.
Sürümümüz çok eski, dokunmak riskli değil mi?
NAV 2009'dan Business Central'a kadar kurulumlarla çalışıyoruz; sürümün yaşı tek başına engel değil. Asıl risk, kurulumdan bu yana yapılmış özel geliştirmelerin belgelenmemiş olmasıdır — hangi nesneye dokunulduğu bilinmeden yapılan her değişiklik kumar olur. Bu yüzden ilk iş o geliştirmelerin envanterini çıkarmaktır; envanter çıkmadan üretim ortamında değişiklik yapmıyoruz.
Rapor mu geliştiriyorsunuz, kurguyu mu düzeltiyorsunuz?
İkisini de yapıyoruz, ama önce hangisi olduğunu ayırıyoruz. Rakam yanlış çıkıyorsa sorun çoğu zaman raporda değil, altındaki kurgudadır: maliyet yöntemi, deftere nakil grupları, birim çevrimi, boyut. Kurgu sorununun üstüne rapor yazmak rakamı bir süre düzeltilmiş gösterir, sonra başka bir yerden patlar. Bu ayrımı yapmadan geliştirme teklifi vermiyoruz.
Uzaktan mı çalışıyorsunuz, yerinde mi?
İşin büyük kısmı uzaktan yürür: teşhis, sorgu, rapor geliştirme, veri düzeltme. Kurgu değişikliği, devreye alma ve kullanıcıyla birebir çalışma gerektiren adımlarda yerinde oluruz. Küçük bir ekibiz; sizinle konuşan kişi işi yapan kişidir, arada müşteri temsilcisi katmanı yoktur ve sisteminizi tanıyan kişi proje ortasında değişmez.
Business Central'a geçersek verinin ne kadarı taşınır?
Cari, madde, satıcı gibi ana kartlar ve açık bakiyeler taşınabilir. Kapanmış geçmiş hareketlerin tamamı çoğu projede taşınmaz; arşiv olarak eski veritabanında ya da ayrı bir raporlama alanında tutulur ve raporlar oradan beslenir. Asıl maliyet kalemi veri değil, özel geliştirmelerdir: eski sürümdeki nesne bazlı geliştirmeler yeni mimariye birebir taşınmaz, yeniden yazılır. Geçiş kararı verilmeden önce bu listenin çıkarılmasını isteriz.
Küçük bir ekipsiniz, bu bizim için risk değil mi?
Açıkça söylüyoruz: küçük ve butik bir ekibiz, arkamızda 25 yıllık yazılım ve ERP birikimi var. Bu, aynı anda sınırsız iş alamayacağımız anlamına gelir — alamayacağımız işi de baştan söyleriz. Buna karşılık işiniz sıraya girmez, konuştuğunuz kişi işi yapan kişidir ve sisteminizi öğrenen kişi ekipten ayrılıp gitmez.
İlgili sayfalar
Önce bir konuşalım
Keşif görüşmesi ücretsizdir ve bir şey satın almanızı gerektirmez. Mevcut durumunuzu dinler, yapılabilecekleri açıkça söyleriz.
Görüşme talebi bırakın →