Microsoft 25 yıllık Logosunu değiştiriyor

13 Yaygın ERP Hatası ve Bunlardan Kaçınmanın Yolları

ERP sistemi implementasyonu, bir IT biriminin üstlenebileceği en pahalı , zaman alan ve karmaşık görevdir.Gecikmeler, hesapta olmayan masraflar her köşebaşına gizlenmiş olarak beklerler.  Maliyetli hatalardan korunmanız için CIO.com , IT yöneticilerine ,ERP tedarikçilerine ve teknoloji danışmanlarına ERP korku hikayesine dönüşmesinden kaçınmanın yollarını sordu,

Yüzlerce,binlerce dolardan milyon dolarlara varan maliyeti, yüzlerce adam gün gerektiren uygulama süreleri ile ERP sistemleri büyük para, kaynak ve zaman yatırımlarıdır. Başarılı bir ERP uygulaması şirketinizde iş akışlarının daha düzgün akmasına  ve masrafların azalmasına neden olur, ama kötü uygulanmış ERP, şirketlere düşük üretkenlik ,gecikme ve masraf getirir.

Erp uygulumanızın başarılı olduğundan emin olmanız için ,ya da potansiyel problemleri minimize etmeniz için CIO.com bir çok Erp uzmanı(IT yöneticileri,danışmanlar ve ERP tedarikçileri) ile görüştü ve onlara şirketlerin ERP ile ilgili yapmış olduğu en yaygın hataları , kaçınma yollarını ve nasıl çözüldüğünü sordu.  En yaygın 13 hatayı ve çözümlerini aşağıda bulabilirsiniz.

ERP Hatası #1 : Kötü Planlama , Sage Genel başkanı ve Orta Ölçekli Erp Marketi  Ürün Müdürü Erik Kaas,’ ERP projenizin başarıya ulaşmasını istiyorsanız planlama kesinlikle çok önemli, Erp ile bir anda kanatlanmak mümkün değildir.’ diyor.VAI şirketinde CIO ve Orta ölçekli şirkeltelere Erp yazılım ve çözüm sağlayıcısı Kevin Beasley, bu düşünceye katılıyor. ‘Çoğu şirket Erp yazılım değerlendirmesine başlarken yeterli ölçüde planlama yapmıyorlar.’ ‘Bu da yolun devamında karışıklığa neden oluor çünkü mevcut durumlarını ve iş verimini nasıl maximize edeceklerini anlamamış oluyorlar.’

Bu hatayı çözmek için, erp sistemlerini seçmeden önce şirketler tüm prosesleri ve politikaları ile ilgili bir iç denetçi ile çalışmalılar.Ayrıca , Beasley ilgili taraflardan oluşan karışık bir ERP Geliştirme takımı kurulmasını öneriyor.Eğer şirketinizi ERP sistemini yürütebilecek kadar yeterli görmüyorsanız, kendi sektörünüzde ERP implementasyon tecrübesi bulunan ERP Danışmanlarını işe almayı düşünebilirsiniz.

  ERP Hatası #2 : Deneyimsiz ERP Tedarikçileri , İş süreçlerini iyileştirme alanında çalışan bir firma olan Casemore&Co Başkanı ,Shawn Casemore, ‘Çoğu müşteriler, ERP tedarikçilerinin satış departmanı tarafından ‘satın alınmışlardır’, ancak implementasyon tamamlandığında sistem fonksiyonelliğinde kısıtlar, düşük kapasite ve iç çalışmalar üzerindeki etkileri karşısında şaşkınlık yaşarlar.’ diyor. Yazılım sağlayıcısından, sizinle aynı sektörden ,görüşebileceğiniz ve yazılım hakkında bilgi alabileceğiniz en az üç isim isteyiniz ve ardından o isimleri arayarak,programın özellikleri, fonksiyonelliği ve zorlukları üzerine fikir alınız. Eğer sağlayıcı size en az üç isim veremiyorsa ( ya da vermiyorsa) hemen oradan uzaklaşın, tabi bir kobay faresi olmak istemiyorsanız.

 ERP Hatası #3: Temel özelliklerin anlaşılmaması veya kullanılmaması. Bir iş danışmanlığı ve teknoloji çözümleri şirketi olan MorganFranklin firmasının genel müdürü, John Hoebler “Yıllık ERP anketimizde, katılımcıların sadece %46 sının kendi ERP sistemlerinde kullandıkları özellikleri tamamen bildikleri sonucuyla karşılaştık, milyonlarca şirketin (kendi ERP sistemlerine), yatırım yaptığını göz önünde bulundurursak bu şok edicidir. Özellikler bilinmezse şirketler, iş süreçlerini otomatikleştirmek, çalışmaları daha hızlı tamamlamak ve iş hedeflerini karşılamak için fırsatları kaçırırlar.” Ayrıca “Versiyon yükseltmeleri, geliştirmeler ve bakım  daha maliyetli ve daha az başarılıdır.” diyor

Bu sorunu çözmek için, Hoebler, hangi özelliklerin kullanıldığını ve en yararlı olanları belirlemek için tüm özellikleri içeren, kullanımı takip edilen  ve belirli aralıklarla gözden geçirilen ana bir liste oluşturmayı öneriyor. “Bu bilgi kataloğu(sonrasında) yeni çalışanları eğitmek, test scriptleri yazmak ve denetimi, uyumluluğu ve raporlama gerekliliklerini desteklemek için kullanılabilir.” diyor.

ERP Hatası #4:Gereken zamanın ve kaynakların küçümsenmesi. e2b teknologies’in pazarlama müdürü, James Mallory  “Tüm şirketler, yeni ERP sistemi implementasyonu için gereken zamanı ve kaynakları fena bir şekilde küçümsüyor.” görüşünü savunuyor. Gerekli süreyi nasıl hesaplayabilirsiniz? “ Gereken zaman yazılımın maliyetinin 100 e bölümüyle tahmin edilebilir.” Diye açıklıyor. “Örneğin, 20.000$ lık bir yazılımı, sertifikalı danışman kullanarak hayata geçirmek, yaklaşık olarak 200 adam-saat veya 5 hafta sürecektir. Eğer en az profesyonel yardımla, kendi kendinize uygulamayı planlıyorsanız,bu sayının iki katıdır.” Ayrıca, Mallory dedike kaynak olarak atanmış bir proje yöneticisinin önemini vurguluyor.

ERP Hatası #5: Takımda, başından beri doğru insanların olmaması. Beasley “Çoğu zaman, kuruluşlar ERP implementasyonlarının en başında doğru insaları bir araya getirmez.” diyor ve bu noktaya dikkat çekiyor ,“ERP uygulaması bir kurumun üstlenebileceği en büyük projelerden biridir ve dolayısıyla hatalar olabilir ve eğer karar verme sürecinin tüm adımlarında doğru taraflar yer almazsa, planlar yoldan çıkabilir.” Örneğin bir çok kuruluş, kurumdaki finanstan, süreç yürütmeden, imalattan, satın almadan, depodan ve ayrıca IT’den key kullanıcıları bir araya getirmektense, yönetici onayını almaya odaklanıyor.Bu durumda ne zaman yararlı olur?: ERP uygulamasına en başından aktif olarak bağlı, doğru kullanımı ve doğru sonuç alımı için yatırım yapan çalışanlar bulunduğunda.

ERP Hatası #6: Önceliklerin belirlenmemesi. Realization firmasının bir proje yönetim uzmanı olan başkan yardımcısı, Yoav Ziv “Bir ERP sistemi uygulanırken, yapılabilecek tek ve en önemli şey gecikmeleri azaltmak ve tamamlanma zamanını  hızlandırmak için çoklu görevleri azaltmaktır.” diyor. ”İnsanlar birden fazla görevde zorlandığı zaman çok yavaş çalışırlar ve sık sık vites değiştirirler.” görüşünü savunuyor. Bu nedenle, öncelik sistemi oluşturma , IT yöneticileri için öncelikli olmalıdır. “ Öncelik sistemi sadece hangi görevin ne zaman yapılacağını belirtmemeli, aynı zamanda öcelik sırasına göre hangi sorunların çözülmesi gerektiğini belirtmelidir”diyor. Ayrıca, “ ERP implementasyon yöneticisi sorun çözme prosesini titizlikle uygulamalıdır ve sinyalini aldığında sorunu bir an evvel çözmek için harekete geçmelidir.

ERP Hatası #7: Eğitim ve değişim yönetimine yatırım yapılmaması Kaas “Doğru eğitim eksikliği ERP projelerinin başarısız olmasının en yaygın sebeplerinden biridir ve çalışanların yeni sisteme ısınamamasına yol açabilir çünkü sistemi anlamamışlardır.” diyor. Oracle’ın JD Edwards ürününde ERP yazılım uzmanı olan GSI başkanı ve CEO'su Kevin Herrig “Emin olun sistem hayata geçmeden önce çalışanların yeni sisteme alışmak için bir şanslarının olması ERP başarınızda harikalar yaratacak” diye ekliyor.” Kullanıcılarla eğitim yapmaya ve sık iletişim kurmaya öncelik vermezseniz, sonunda Excel’in en pahalı versiyonuna sahip olursunuz.”

ERP Hatası #8 Doğru datanın önemini küçümseme: ERP sisteminiz içindeki data kadar iyidir.  Döküman yönetimi  ve iş akış çözümleri sağlayıcısı olan iDatix’in profesyonel hizmetler direktörü, Martin Levesque’a göre eğer ERP implementasyonunuzun başarılı olmasını istiyorsanız, uygun programlama şarttır ve hata ihtimalini en aza indirmek için prosedürel(yöntemsel) parametreler en başında doğru kurgulanmalıdır.

ERP Hatası #9 ERP sisteminin herşeyi karşıladığını düşünme: Bir websitesi geliştirme şirketi olan NetFoliage’in  yazılım mimarı olan Akan Iza “ERP sistemi ne kadar güçlü ve esnek olursa olsun tüm iş mantığını barındırmayacaktır.”. “ERP implementasyonları sırasında yapılan en yaygın hatalardan biri, uygulamanın iş sürecinin tümüne uygun olduğunu düşünmektir.” Bu maliyetli hatadan kaçınmak için şirketler değer zinciri optimizasyonu ve maliyet takibi adına ERP implemente etmelidirler. Harici herşey ikincil hedef olmalıdır.

ERP Hatası #10  Eski programı kullanımdan kaldırmama:Application Modernization & Optimization at Accenture’ın başkanı, John Picciotto “Eğer kurumlar implementasyon anında diğer uygulamaları devreden çıkarmak için çalışmıyorsa, sonuç tüm eski uygulamarıyla bekleyen bir ERP olur.” görüşünü savunuyor.”Amaç, iş akışını hızlandırmak, maliyet ve gereksiz harcamaları azaltmak için bir ERP sistemi sahibi olmak iken, sonuçta, bakım , destek, donanım , versiyon yükseltimi , ana program dışında arayüzleri için para ödediğiniz farklı bir yazılıma sahip olmanızdır.

ERP Hatası #11 Aktif bir yük testi ortamının olmaması: Herrig “Bir kaç test kullanıcısını dikkate alarak doğru sonuçlar elde edilemez. Değişikliklerin gerçek etkilerini görmek ve masraf oluşturan çalışılmayan zamandan kaçınmak için iş yükü doğru simule edilmeli.” diyor.

ERP Hatası #12 Üçüncü şahıs destek alternatiflerinin görmezden gelinmesi: Fortune 1000 işletmeleriyle çalışan IT harcama yönetimi danışmanı, NPI’ın CEO‘su Jon Winsett “Bakım fiyatları tüm zamanların en yüksek oranlarında olmasına rağmen bir çok şirket yüksek kaliteli satış desteğinde ısrarcı ve bu hizmeti aynı düzeydeki üçüncü şahıs destek sağlayıcısından da alabilirler.” diyor. “Şirketler destek aldıkları şirket ile çalışan karma hizmet sağlayıcıları ya da bu tip şirketlerden tamamen bağımsız çalışan hizmet sağlayıcı seçeneklerini  araştırmalıdır.Bir üçüncü şahıs destek alternatifi destek maliyetini %30 ila 50 oranında düşürebilir.”diyor.

ERP Hatası #13 Bir bakım stratejisinin olmaması: SAP America, Inc. ‘nın Kuzey ve Latin Amerika,Upgrade Ofisi başkan yardımcısı, Marco Valencia “Koruyucu bakım almayan müşteriler, ERP yatırımlarının tüm avantajlarından yararlanamaz ve paralarını koruyamazlar. Dahası bakım uygulanmayınca, iş sürecindeyken sistemleri hızlı bir şekilde eskiyecek(teknik açıdan).” diyor. “Potansiyel sorunları önlemede uygulanan değişikliklerle çekirdeği güncel tutmak önemlidir ve kurulum teknolojisindeki gelişmelerle, müşteriler artık destek paketlerini implemente ederken sınırlı bir aksama yaşar.

ERP uygulamasından ne bekleyebilirsiniz?

 

ERP projesi yapan şirketler hangi niyetle bu işe başlarlar, işin bu kısmına girmeyeceğim. Ancak ne elde edebileceğiniz konusunda yapılan çalışmaları sizlere özetleyebilirim. Yapılan çalışmalar genellikle ABD kaynaklı, umarım bir gün ülkemizde de benzerleri yapılır …

1. Toplam envanterin azalması % 3 – % 24 arası
Diğer bir deyimle en kötü netice % 3 azalma en iyisi ise % 24. Azalmanın yanısıra muhtemelen stok karışımında da iyileşme olmuştur, diğer bir deyim ile arananın bulunma ihtimali de yükselmiştir.

2. Stok Kayıt Doğruluğunda % 90 – 97 aralığı
Bu çok önemli bir konu, bildiğiniz gibi bu konuda seminerlerde veriyorum. Stok Kayıt Doğruluğu sağlanmadığı takdirde zaten hem malzeme planlama hem de günlük yönetim çok ağır darbe yer. Aksayan üretim, fazla / eksik satınalma, düzensiz sevkiyatların oluşmasına yol açar. Dünya ölçeğinde alt limit % 95′tir, araştırmada 5 şirketten birinin %97 tutturduğu (% 20’si) görülmüştür. Şirketlerin % 30′u doğruluk oranında limitin altında kalmışlar ve % 90 değerine ulaşabilmişler, geriye kalanlar ise (% 50) % 94′e ulaşarak sınıfı geçmiş gibi olmuşlar.

3. Dönem kapatma süresi 3 – 7 gün arası
Ay sonu kapatma işlemleri açısından bakıldığında başarılı ERP kullanıcıları 3 gün civarında biten ayı kapatabiliyor, en kötü kullanıcılarda 7 gün içinde.

4. Üretim planına uyumluluk % 73 – % 96
En kötü değer yapılan plana % 73 uyumluluk, diğer bir deyimle üretim emirlerinin % 73′ü planlanan tarihte bitiyormuş. En başarılı grup ise % 96 uyumluluğa sahip. (Bu değer % 95 ve üzerinde olduğunda A-Sınıfı olunuyor)

5. Zamanında sevkiyat % 84 – % 98
Gelelim sonuçları en ağır olan konuya. Başarılı kullanıcılar % 98 oranında teslim tarihlerine uyum sağlıyorlar, yani 100 satır siparişin 98 satırı teslim tarihine uyumlu sevk edilmiş. Bu alanda kötü sonuç ise % 84 olmuş.
Bunlar gerçek sonuçlar, şimdi siz de kendi sonuçlarınızı düşünün, tartışın. Ölçümlerin nasıl yapılacağı hakkında sorularınızı bana yönlendirebilirsiniz. Burada yayınlanmasını uygun gördüğünüz tecrübeleriniz var ise benimle paylaşmanızı umuyorum.

http://www.cengizpak.com.tr/erp-uygulamasindan-ne-bekleyebilirsiniz/

ERP sizi değiştirmek istiyor, peki siz istiyormusunuz ?

ERP, şirketleri, çalışanlarını ve iş ortaklarını iş yapma yöntemlerini yeniden düşünmeye, değişiklikler yapmaya çağırır ama insanların çoğu yıllardır izledikleri yolu değiştirmekten pek de hoşlanmazlar. ERP projelerinden umulan faydayı geciktiren sebeplerden biri de budur.
ERP projelerinin yarısı yazılım ise diğer yarısı bu değişimi yönetmek ve gerçekleştirmektir. Eğer ERP yazılımını etkin sipariş alma, imalatı yönetme, zamanında sevkiyat, doğru bilginin firma içinde hızlı gezinmesi için kullanırsanız size fayda sağlayacaktır. Ancak ERP yazılımını kurarken kendi iş yapma biçiminizin olabilecek en iyi yol olduğunu, yazılımın buna ayak uydurması gerektiğini düşünür ve süreçlerinizin arasından gerekenleri değiştirmeyi hedeflemezseniz elde edebileceğiniz sonuçlara muhtemelen ulaşamazsınız.

http://www.cengizpak.com.tr/erp-sizi-degistirmek-istiyor-peki-siz-istiyormusunuz/

Maliyet Köprüsü

Şirketlerin para kazanıp kazanmadıklarını anlamak için kullandığı ölçekler ile operasyonel kararlar arasında “maliyet köprüsü” kullanılır

 

· Firma kar ediyor mu ? (Net Kar)

· Firma yatırımına orantılı kazanıyor mu ? (Yatırım Karlılığı)

· Nakit akış tablosunda nakit var mı? (Yaşama Kuralı)

Peki bu ölçekleri bildiğinizde veya izlediğinizde aşağıdaki gibi sorulara ne cevap verebileceğinizi de bilmiş oluyor musunuz ?

.

· Üretim parti miktarlarınız ne olmalı ?

· Parti miktarları firmanızın mali sonuçlarını nasıl etkileyecek?

· Yeni ve daha hızlı bir tezgah mı almalısınız ?

· Standart maliyetinizin altında gözüken siparişi kabul etmeli misiniz ?

· Ne kadar stok tutmalısınız ?

Bu tür sorulara cevap ararken yukarıdaki ölçekler size faydalı olmazlar, bunlara cevap bulabilmek için maliyet hesabı yapma ihtiyacı duyarsınız; ürün maliyeti, ekonomik sipariş/üretim miktarı gibi ölçüler günlük hayatta önemli bir yer tutar. Bu tür kararlarınız ile temel üç ölçek olan – net kar, yatırım karlılığı, nakit akış – arasındaki köprü, maliyet ve maliyet hesaplama yönteminizdir. Bu sayede önce bir karar verir daha sonra yine aynı hesaplama yöntemleri ile kararınızın doğru olup olmadığını test edersiniz.

Bir firmanın maliyet hesaplama yaklaşımı ile günlük operasyonel kararları arasında olan ilişki onun verimliliğini de doğrudan etkiler. Hatalı maliyet varsayımları fazla veya eksik stok, üretim gecikmeleri, satış ve müşteri kaybı gibi sonuçta firmaya “para kaybettiren” olayların yaşanmasına sebep olur. Bu nedenle firmalar maliyet hesaplama yöntem ve varsayımlarını gözden geçirmelidir.

 

http://www.cengizpak.com.tr/sirketlerin-para-kazanip-kazanmadiklarini-anlamak-icin-kullandigi-olcekler-ile-operasyonel-kararlar-arasinda-maliyet-koprusu-kullanilir/

 

 

Dengeli Şirket Karnesi - Balanced Scorecard - Nedir ?

Balanced Scorecard, Dengelenmiş veya Dengeli Şirket Karnesi veya Kurumsal Karne ismi verilen uygulama firmanın uzun vadeli hedefleri ile kısa vadeli hedef ve aksiyon planını bir arada tutmak, atılan adımların uzun vadeli hedeflere hizmet edip etmediğini ölçmek ve şirket çalışanlarının hedefleri ile şirket hedefleri arasında ilişki ve dengeyi sağlamak amacı ile hazırlanır.
Bu uygulamada firma içinde sürdürülecek herhangi bir çalışmanın bu karne ile ilişkilendirilmesi, eğer çalışma ile karne ilişkilenmiyor ise hangisinde ne tür bir değişiklik yapılacağına yönetim tarafından karar verilmesi gerekir. Bu sayede şirketin her zaman aktif ve tutarlı iş planı olması, hedeflere uygun olmayan adımların sorgulanması kolaylaşır. Şirket üst yönetimi açısından bakıldığında karnenin 4 temel bölümü bulunmaktadır. Karne bölüm veya kişi seviyesine indirildikçe aynı tanıma sadık kalınarak ilişkilendirme yapılmalıdır.
Şirket Karnesinin 4 Ekseni
1. Finansal değerlendirme
2. Müşteri açısından değerlendirme
3. İç işlemler, verimlilik, operasyonel iyileştirme
4. Geliştirme, inovasyon ve öğrenme

http://www.cengizpak.com.tr/dengeli-sirket-karnesi-nedir/

İş arkadaşlarınıza sorumluluk alabilmeleri için nasıl yardım edebilirsiniz ?

İyi çalışan bir ekibiniz var. Ancak aralarından birisi problem yaratıyor, üzerine aldığı işi zamanında bitirmiyor, sorulduğunda ekibin diğer üyelerini işaret ediyor ...

Dolayısı ile kimse onunla birlikte çalışmak istemiyor ... Bu tür birisi ile çalışmak zorunda olmak gerçektende sinir bozucudur. Zorunda değilseniz mesele yok ancak çözmeniz gereken bir sorun ise yapılabilecek bir şeyler  olduğunu söyleyebilirim.

İnsanların sorumluluk almamasının sebebi nedir ?

İnsanlar tembellikten başlayan başaramama korkusuna uzanan bir gerekçe listesine sahiptir. Sebep ne olursa olsun sorumluluk almayan kişiler işlerini yapamaz, içinde bulunduğu takımı zor durumda bırakır ve kariyerlerinde ilerleyemezler. Dolayısı ile bu konu insanın iş ve özel hayatında önemlidir.

Göstergeleri neler ...

- İşine ilgisiz olması

- Hatalar için başkalarını suçlama

- Söz verdiği tarihlere uymaması

- Zor işlerden uzak kalmaya çalışmak

- Düzenli olarak mızıldanmak, yönetici ve ekip arkadaşları hakkında söylenmek

- Kendi başına hareket etmek yerine kendisine "yap" denilmesini beklemek, "söylemediniz ki" bahanesini önceden hazırlamak

- Ekip arkadaşlarına güvenmemek

İzlenecek strateji

Ekip üyelerinden birisi sorumluluk almaktan kaçındığında bunun zamanla geçeceğini düşünmemelisiniz, onu ekipten ayırmak ise son seçeneğiniz olmalı, özellikle iş yapabilme kabiliyeti var ise.

Bunların yerine onları işlerini en iyi şekilde yapabilmeleri için donatmalı ve sorumluluk alabilecekleri ortamı yaratmalısınız.

Şimdi gelelim bunu nasıl yapabileceğinize ...

İlk adım konuşmaktır

İlk yapmanız gereken bu kişi ile konuşmak, belki sebebi hemen anlayacak ve durumu çözmüş olacaksınız.

Bu konuşmada kendisine davranışının değişmesi gerektiği mesajını (geri besleme) mutlaka aktarmalısınız. Geri besleme mesajınızı aktarırken kolay anlaşılan örnek ve ifadeler kullanmalısınız. Eğer karşınızda bulunan kişi ne söylendiğini anlamaz ise "kurban edildiğini" düşünecektir.

Şimdi bu aşamada öğrendiklerinizi bir sonraki adımlarınız için kullanabilirsiniz.

Yeterli kaynağın ayrıldığına emin olun

Problemli olarak belirlenen kişinin işini yapabiliyor olması için yeterli kaynağa sahip olup olmadığı en başta kontol edilmesi gereken bir noktadır. Eğitim, araçlar, tecrübeli kişilere erişim, sorularına cevap alabilme imkanı gibi ayrıntılar olduğunu anlamalısınız.

Eğer bir kişi yeterli kaynağa ulaşamıyor ise işini yapamayacaktır, sakın bunu zamanında dile getirebileceğini ve koşulların ne olması gerektiğini size söyleyebileceğini varsaymayın. Bu boşluğu bırakır iseniz bahaneyi kendiniz yaratmış olursunuz.

Görev tanımını, sorumlulukları ve amaçları anlatın

İnsanlar görev tanımlarını, kendisinden ne beklendiğini açıkça bilmelidir. Görev tanımında kişinin yapacağı işin ve sorumluluklarının ne olduğunun açık olup olmadığına bakmalısınız.

Bazende insanlar kendi yaptıkları iş ile şirketin hedefini ilişkilendiremezler. Dolayısı ile yaptıklarının değersiz olduğunu düşünürler. Sorunun bu olup olmadığını bu aşamada keşfetmelisiniz.

Konunun herkes için net olabilmesi için kişiler - sorumluklar tablosu hazırlamanız ve bunu paylaşmanız çok yararlı olacaktır.

Yeniden başlamasını sağlayın

İş hayatında boşluğa düşülebilir, şimdi ben ne yapacağım noktasında kararsız kalınabilir, yapılması gereken o kişinin koşullarını revize ederek yeniden başlayabilmesine olanak tanımaktır. Eğer kişi kendi değerleri ile şirketinin hedeflerini uzlaştırabilir ve yaptığı iş ile hem kariyer hem de şirket hedefini ilişkilendirebilir ise sorun çözülebilir.

Herkesi kendi yeteneklerine uygun biçimde görevlendirmelisiniz. Bunun için ise biraz beklemeniz gerekebilir, hatalı bir karar verdiğinizi düşünüyor iseniz geriye dönebilme cesaretini göstermelisiniz. Ortam koşullarını belirlemek için ise Herzberg'in motivasyon ve hijyen faktörleri hakkında olan çalışmasından faydalanabilirsiniz.

İş arkadaşlarınıza kontrolu ele alabilmeleri için yardımcı olun

Bazen insanlar kendi hayatlarının kontrolunu kaybettiklerini ve bir akıntının içinde savrulduklarını hisseder. Artık onlar için ne yaptıkları ve nasıl yaptıkları önemini yitirir, "nasıl olsa bir şeye yaramayacak" fikri yerleşir.

Düşünürseniz bu fikir herhangi bir ast - üst ilişkisinin bozulması veya kişinin kendi hedefine "bu koşullarda" ulaşamayacağına inanmaya başlaması ile hızla ortaya çıkabilir. Sonucunda yapmakta olduğu işin kalitesi bozulur, nasıl olsa fark etmemektedir !

Böyle bir durumu anlamak zor değildir. Örneğin "biz de olmaz", "ben nasıl yaparım" gibi ifadeler veya "her şeye karşı çıkma" ve "negatif" tutum bu durumun birer göstergesidir. Sanki olaylar kendi kendilerine oluyor ve biz akışı etkileyemeyiz görüşüne karşı savunma yapabilmek için insanlara kısa dönemde başarabilecekleri işler vermek, pozitif düşünmelerini sağlamak için eğitim veya bire bir destek gerekir. Negatif tutumlarını sürdüren kişileri geçici veya kalıcı ortamdan uzaklaştırmak, tartışmalara almamak da birer çözümdür.

Projelerinizi küçük parçalara bölüp sorumluluğu buna göre dağıtmanız ve insanların başarı duygusunu yaşamalarını sağlamanız büyük oranda bu problemi çözecektir. Diğer yandan sorumluluk almaktan kaçınıp sonra da suçlama yolunu seçenleri ya durdurmalı ve sorunun çözümü için çalışmalarını sağlamalı ya da oradan uzaklaştırmalısınız.

Siz her detayı yönetmeye çalışan birisi olabilir misiniz ?

Peki siz nasıl bir yöneticisiniz ? Eğer işleri delege etmeyip her adımına karışmak isteyen, insanların verecekleri her kararın size danışılmasını isteyen, her detay için "niçin bunu böyle yaptın" diye soran, verdiğiniz işi ilk hatada geri alıp başkasına veren birisi iseniz sizinle çalışanlar sorumluluk almak için istekli olmayacaklardır.

Sizin öğrenmeniz gereken ise işlerinizi nasıl delege edeceğiniz. Bunun için sitede bulunan yazılarım size yardımcı olabilir.

Bol bol takdir edin

İşini iyi yapmış olanı, sorumluluk almaktan korkmayan ve yerine getirenleri zaman geçirmeden takdir edin, bunun için ayın sonunu veya yılın sonunu beklemeyin, o anda yapın.

Şimdi kendinizin ne yaptığını bir düşünün, bunları yapıyor musunuz ?

http://www.cengizpak.com.tr/is-arkadaslariniza-sorumluluk-alabilmeleri-icin-nasil-yardim-edebilirsiniz/

Video: NAV 2013 Beta - NAS on the Service Tier

Tradesoft, Bilişim 500’deki Yerini Aldı!

Türkiye Bilişim Pazarı, geçen yıl 29 milyar dolarlık büyüklüğe ulaştı.

Interpromedya’nın bu yıl 13. kez düzenlediği Türkiye’de bilişim alanında yapılan araştırmanın, Bilişim 500’ün sonuçları açıklandı. 2011 yılı ilk 500 bilişim şirketi listesinde Tradesoft her geçen sene büyüyen cirosu ile bu sene de geçen senelere göre bir adım daha yukarı çıktı ve 150’inci olarak ilk 500 firma arasına girmeyi başardı.

Sırayla son 4 yıla bakacak olursak;

2008 yılında 182., 2009 yılında 157., 2010 yılında 156. sırada, ve 2011 yılında ise artan toplam satış gelirimiz ile 150. sırada yerimizi aldık.

"BİLİŞİM PAZARI 2012'DE 30 MİLYAR DOLARI AŞACAK"

Araştırmanın Türkiye bilişim pazarına ilişkin ortaya koyduğu verilere göre, BT donanımı, yazılım ve hizmetleri içeren bilgi teknolojileri pazarı yüzde 12,7 büyürken, telekom donanımı ve taşıyıcı hizmetleri içeren iletişim teknolojileri pazarı yüzde 1,9 küçüldü.

Bilgi ve iletişim teknolojileri toplamı olarak bilişim pazarı ise 2011'de yüzde 2 artışla 29 milyar dolarlık bir büyüklüğe ulaştı.

Gecede, İnterpromedya yetkilileri, bilişim pazarının 2012'de yüzde 6 büyüyerek 30 milyar doları aşacağı tahminini de paylaştı. Büyüme tahmini bilgi teknolojileri pazarı özelinde yüzde 14,1, iletişim teknolojilerinde yüzde 2,6 olarak ortaya kondu.

“CEO'LAR 2012'DE HEDEF BÜYÜTTÜ”

Bu arada törende, araştırma kapsamında, ilk 500'deki 446 bilişim şirketinin üst yöneticilerinin (CEO) katılımıyla gerçekleştirilen anket sonuçları da açıklandı. Buna göre CEO'ların yüzde 55'i 2012 büyüme hedeflerini artırdıklarını belirtirken, hedeflenen sektörler arasından yüzde 50,4 ile kamu, yüzde 43,7 ile finans, yüzde 41,5 ile telekom ilk üçte yer aldığı açıklandı.

Anket sonuçlarına göre şirketlerin yüzde 58'inin Ar-Ge yatırımı yaptığı tespit edilirken, Ar-Ge harcamalarının toplam ciro içindeki payının önceki yıla oranla yüzde 1 artışla yüzde 13'e ulaştığı gözlendiği belirtildi.

CEO'lar en önemli sorunlarının başında nitelikli insan kaynağı sıkıntısını yüzde 65,2'lik oranla birinci sırada gösterirken, gündemlerinde yer tutan başlıklardan öne çıkanları sırasıyla markalaşma, çevrecilik, yeni sektörlere yatırım, Ar-Ge ve inovasyon yatırımları, sosyal sorumluluk ve reorganizasyon olarak sayıldığı araştırmalar sonucu ortaya çıktı.

Microsoft Dynamics NAV ile Google Apps Entegrasyonu/Integrating Google Apps with Microsoft Dynamics NAV

A framework has been created whereby NAV data can be sent to Google Apps. ArcherPoint or the community in general can build upon this framework in order to empower the entity to have as much synchronicity as is desired. The framework currently supports authentication on an individual basis and can even store username and password credentials for automatic re-authentication. A huge potential exists … imagine displaying one or more customers as markers on a Google map, linking to product images in Picasa, or even displaying grid-like form data in a Google spreadsheet.
Three videos have been created to demonstrate the framework. In this first video, a Contact record is uploaded to Google Apps:

This second video demonstrates how the Customer Online Map feature links to Google Maps; in addition, a new report creates markers on a Google Map for all customers matching a filter:

The third video demonstrates how the data in a List Page is uploaded to a spreadsheet in Google Drive:

Are you ready to begin? Download the framework and begin your integration with Google Apps!
You can also view these videos, along with many other Microsoft Dynamics NAV tutorials, on ArcherPoint's YouTube channel.

NAV Hesap Tabloları Kullanarak Nakit Akış Tabloları Oluşturma/Using NAV Account Schedules to create Cash Flow Statements

Using NAV Account Schedules to create Cash Flow Statements

This blog is an attempt to document how a Cash Flow Statement can be created using standard NAV Account Schedules.

I’ve been asked a few times by Finance Type individuals for a Cash Flow Statement report (yes there is not an out of the box report . . . darn!). It usually takes me a couple attempts to explain how to accomplish using Account Schedules, and I usually kick myself for not keeping an example on hand.
As some may know, there are two methods, Direct and Indirect, that can be used for a Cash Flow Statement. I understand the Indirect Method is the more common of the two, regardless I choose to do both in this blog. Other than the operating activities section, the methods are similar. A well-structured chart of accounts will greatly assist in setup/maintenance of this Account Schedule. You’ll see from my examples that I’m largely using Total Accounts to accomplish; hopefully this will eliminate the necessity to reconsider this account schedule if new accounts are setup in the future. For those of you that are new to NAV or have not yet implanted NAV, a good exercise may be to consider the necessary structure to accomplish a cash flow statement. This may dictate certain accounts/structure in your chart of accounts for your reporting requirements.
My examples are all from NAV 2013 BETA (CRONUS USA, Inc.), but these examples should apply to prior versions also. I’m sure my examples aren’t necessarily fully GAAP compliant, but I think you’ll understand the basics so that you can incorporate into your own schedules.
Indirect Method Account Schedule:

Indirect Method Account Schedule comments:

• Total Accounts, in Totaling Types column, used for many account schedule lines.
• In operating activities section, non-cash Depreciation and amortization has a unique row no. (095). Row No. 095 participates in two formulas, Net Cash flows from operating activities line and Net increase in cash and cash equivalents line.
• Row Type of Beginning Balance for Cash and cash equivalents, beginning of period line.
• Show column is used to show only certain rows on printed report.
  • Check Total Lines which will only show up on the printed report if the report is out of balance with cash accounts (certainly not necessary – but I like to have check totals just in case).

Direct Method Account Schedule:

Direct Method Account Schedule comments:

• The operating activities section is where the differences reside as compared to the Indirect Method, other sections are largely the same.
  • Note that I choose to have many rows set with Show = No. I found when reconciling it was nice to see those rows in the Account Schedule Overview (those rows won’t show on the printed report).

Column Layout:

Column Layout comments:

• Again, I choose to Show certain columns as Never so that I could see in Account Schedule Overview, but not on the printed report. Again, this is very useful when setting up and reconciling the report.

Account Schedule Overview:

Account Schedule Overview comments:

• Again, here you’ll be able to see columns and rows even if you set Show = Never in column layout and Show = No in account schedule. Those settings only apply to the printed report.

Printed Report:

I hope this blog helps provide you an example you can follow to establish your own Cash Flow Statement from standard NAV functionality.

http://www.archerpoint.com/blog/Posts/using-nav-account-schedules-create-cash-flow-statements?goback=%2Egde_1134_member_136386077

Yeni TTK’daki 55 Maddelik Değişiklik

55 Maddelik Değişiklik

Türk Ticaret Kanunu ile ilgili 55 maddelik değişiklik gerçekleşti. Kısaca değişiklikler şöyle olacaktır.

İşlem Denetçisi Kaldırılmıştır: İşlem denetçisinin sorumlulukları Yönetim Kurulu’na, görevleri bilirkişilere, bakanlık görevlilerine, uzman kuruluşlara bırakılmıştır.

TFRS’lere Göre Defter Tutma Kanun Metninden Çıkarılmıştır: Kanunda yer alan defterlerin Türkiye Finansal Raporlama Standartlarına göre tutulması zorunluluğu metinden çıkarılmıştır. 64 üncü maddeye eklenen 5. Paragraf ile kanuna tabi tüm gerçek ve tüzel kişilerin defterlerini tutarken vergi usul kanununa uymak zorunda olduğu açıkça belirtilmiştir.

TFRS’lere göre Mali Tablo Düzenleme Zorunluluğu devam etmektedir: Tüm şirketlerin mali tablolarını ölçeklerine göre Türkiye Finansal Raporlama Standartlarına göre veya Kamu Gözetim Kurumu tarafından TFRS’nın Kavramsal Çerçevesine aykırı olmamak kaydıyla çıkaracağı Raporlama standartlarına göre Mali Tablolarını düzenleme zorunluluğu aynen devam etmektedir. Yani tüm gerçek veya tüzel kişiler her raporlama döneminde TFRS’lere veya TFRS kavramsal çerçevesine aykırı olmamak kaydıyla muhasebe standartlarına uygun finansal tablo düzenlemek zorundadır.

Bağımsız Denetim Zorunluluğu sadece Bakanlar Kurulu tarafından belirlenecek Şirketlere uygulanacaktır: En önemli değişiklik denetim kapsamının daraltılmasıdır. Kimin bağımsız denetime tabi olacağına sadece ve sadece bakanlar kurulu karar verecektir.

Denetçinin SMMM veya YMM Olması zorunluluğu Kanun Metninden Çıkartılmaktadır: Kanundaki en önemli değişikliklerden birisi de kanun metninden Bağımsız Denetçinin SMMM veya YMM olması zorunluluğunun ortadan kaldırılarak, denetçinin kim olacağı ile ilgili tüm yetkinin Kamu Gözetim Kurumu’na bırakılmasıdır. Esasında Kamu Gözetim Kurumu’nu ortaya çıkaran 660 sayılı Kanun hükmünde kararnameye bakıldığında Kamu Gözetim Kurumu bağımsız denetçileri sadece meslek mensupları arasından seçebilmektedir. Tasarı aynen kanunlaşsa dahi bağımsız denetim yetkilisi olarak seçilebilecek kişiler 660 sayılı kanun hükmünde kararname gereği SMMM veya YMM’lerdir.

Denetçinin Görüşü ile Yönetim Kurulunu Seçime Zorlama Uygulaması Devam Ediyor: Denetçinin görüşü ile yönetim kurulunu genel kurula ve seçime zorlayabilmesi hakkı tasarıda devam etmektedir. Ancak burada görüş bildirmekten kaçınma hali kaldırılmış sadece olumsuz görüş verilmesi halinde bu hakkın olması uygulaması getirilmiştir.

TFRS Kavramsal Çerçevesine Uygun Finansal Tablo Zorunluluğu: Türkiye’deki tüm gerçek veya tüzel kişiler vergiye esas kayıtlarından ortaya çıkan finansal tabloları dışında TFRS’ye veya Kamu Gözetim Kurumu tarafından TFRS kavramsal çerçevesine aykırı olmamak kaydıyla çıkarılan Muhasebe Standartlarına uygun finansal tablo düzenlemek zorundadır. Bu finansal tablolar bakanlar kurulu tarafından belirlenen şirketler için bağımsız denetime de tabidir.

Şirkete Borçlanma
Yasağı: Şirkete Borçlanma yasağı neredeyse tamamen kaldırılmıştır. Yapılan düzenleme ile şirkete sermaye borcu olan ortaklar dışında borçlanma serbest bırakılmaktadır.

İnternet Sitesi Zorunluluğu: İnternet sitesinin kapsamı oldukça daraltılmış ve sadece bağımsız denetime tabi şirketler için zorunlu tutulmuştur.

Güvenebileceğiniz Deneyim , Tradesoft Uzmanlığı

Dynamics NAV Tecrübemiz

---

Dynamics NAV / Navision Tecrübesi
Dynamics NAV (Navision) Tecrübesi	Toplamda 94 yıldan fazla
ERP Tecrübesi	Toplamda 130 yıldan fazla
Dynamics NAV (Navision) implementasyonları	50’den fazla
Dynamics NAV (Navision) Upgrade – Versiyon Yükseltme	20’den fazla
Web / eCommerce Entegrasyonları	20+
Barkod/RFID	10+
Kredi Kartı İşlemleri Entegrasyonları	Türkiye’de en yaygın 6 banka ile
POS Çözümleri Entegrasyonları	500+ satış noktası
EDI (Electronic Data Interchange)	30+
Diğer Entegrasyonlar	10+

Dynamics NAV / Navision Sertifikasyonları
Financial Management
Manufacturing
Warehouse Management
Advanced Distribution (Trade)
Trade & Inventory
CRM / Relationship Management
Service Management
C/SIDE Introduction
C/SIDE Solution Development
Installation & Configuration
SQL Server
Sure Step – Implementation
Project Management

Dynamics NAV Uygulamaları
Finans
Muhasebe
Hesap Tabloları
Bütçe
Tahmin
Konsolidasyon
Çoklu Şirket
Çoklu Döviz
Satış Sipariş İşlemleri
TR Bordro
Alım Siparişi İşlemleri
Üretim
Dağıtım
Ambar Yönetimi
Sevkiyat İşlemleri
Teslim Alma İşlemleri
Barkod
Maliyet
Profesyonel Servisler
Çalışma ve Harcama Girişleri
Proje
Proje Maliyeti
Dashboard , KPI
Sorumluluk Merkezleri

Dynamics NAV Versiyon Geçişleri / Versiyonlar 20+ Microsoft Dynamics NAV versiyon geçişi gerçekleştirdik. Aşağıdaki versiyonlarda tecrübelere sahibiz ;
Dynamics NAV Versiyonları :
Navision Financials 2.60
Navision Attain 3.10A, 3.70B
Microsoft Business Solutions Navision 4.0, 4.0 SP1, 4.0 SP2, 4.0 SP3
Microsoft Dynamics NAV 5.0, 5.01,5.02
Microsoft Dynamics NAV 2009, 2009 SP1, 2009 R2

Dynamics NAV Entegrasyonları
Logo Tiger (Türkiye’deki en yaygın yerel ERP sağlayıcısı)
Çoks ayıda Web Sitesi , e-ticaret portalı
Microsoft CRM
Dijital Arşivleme Sistemleri
Tedarikçi Sistemleri (Adidas,Reebok,Nike)
DBS (Doğrudan Borçlandırma Sistemi)
Kredit Kartı İşlemleri (yaygın bankalar ile)
Yemek Çekleri (sodexo , ticket, vb.)
Ödeme sistemleri (yaygın bankalar ile)
Yasal Bildirimler (beyannameler)

Dynamics NAV Teknolojileri
SQL Server ve Hardware Server Setup, Architecture, Optimization
Microsoft Dynamics NAV on Virtual Machines (VM Ware ve Virtual Server)
Remote Access ve Support
Terminal Server, Citrix
SharePoint Entegrasyonu
Microsoft Dynamics NAV ile XML entegrasyonu
SaaS / Private Cloud / Hosted Microsoft Dynamics NAV Uygulamaları
Web Servisleri
SOAP
.NET
C++

Dynamics NAV üzerinde yapılan geliştirme örnekleri ;
Hesap Tabloları
Boyutlara Göre Analizler
Özel Raporlar
Dashboard , Grafik , KPI
Veri Aktarımı
Çoklı NAS Kullanımı
Web Servis Kullanımları
Otomatik Fatura Aktarımları
Excel Şablonlarından Veri Girişleri
Atık/Fire Yönetimi
Reporting Services (SSRS)
Ekstre ve Faturaların e-mail olarak Gödnerimi
Nakit Akış
Konsolide Raporlar
Nakit Çekim Yönetimi
Fiziksel Envanter
Stok Sayımları
İhtiyaç Planlama
Tedarik Planlama
Makine Merkezi Optimizasyonu
Ambar İşlemleri
Özel Sabit Kıymetlerin Yönetimi
Teminatlar
Temlikler
KDV Yönetimi
KDV İstisnaları
KDV İadeleri
Kur Farkları
Doküman Yönetimi
Banka Mutabakatları
Grup İçin Şirketlerarası İşlemler
Çalışma Zamanı ve Masraf Yönetimi
Kira Yönetimi
Royalty Gelirleri ve Raporlaması

Tradesoft aşağıdaki programlardan Dynamics NAV geçişi gerçekleştirdi
Programlar :
Logo Unity
Logo Tiger
Logo Go
Logo Gold
Netsis
Mikro
Uyumsoft
Orka
EuroPro
Link
Set

NAV 2013'de G/M Hesap Adı Alanının Uzunluğu

Length of G/L Account Name in NAV 2013

by Vjekoslav Babic on June 10, 2012

A small but important change often slips under the radar of the What’s New kinds of documents. One of those is the standard length of the Name field in G/L Account table. I’ve just noticed that in Microsoft Dynamics NAV 2013 the length of this field has been increased from 30 characters to 50 characters.
While this seams a minor thing, it’s actually a huge improvement. If 30 characters was not enough in previous versions, increasing it was not a simple thing to do, and required you to change thirty or so other objects as well. It was in fact one of those annoying things that you better got used to, rather than changed. Yes, I’ve seen customers who insisted on changing it, but most of them simply gave in.
In NAV 2013, this change is not only about G/L Account – the length of all Name and Description fields in all master tables has been consistently set to 50. In the previous versions of NAV the length varied between 30 and 50, but now all of the master table Name and Description fields are of length 50.
A small step for man, a giant leap for mankind.

http://navigateintosuccess.com/blog/length-of-gl-account-name-in-nav-2013

NAV 2013 ile yapılan en iyi 5 SQL Server İyileştirmeleri

Top 5 SQL Server Improvements in NAV 2013

by Vjekoslav Babic on June 21, 2012

Performance is one of those things you can’t get enough of and NAV is one of those systems where an extra operation per second is always welcome. Yesterday, during the Expert Panel at the NAV day of the Decisions Spring conference, there was a question: is there any improvement in how NAV 2013 works on SQL Server.
And the answer is: oh yeah!
As a matter of fact, everything is new and improved.
Jörg has already posted an overview of the news of NAV on SQL Server in his last blog post, but I still think there’s room for a couple of more words on the really amazing palette of news and improvements.

As I said, the SQL Server improvements are plenty. Here’s the list of the top 5 technical improvements that rock my boat.
1. Cursors are gone
If there was a single thing that was killing performance in NAV, that was server-side cursors. The burden on SQL Server, especially in critical multi-user environments was tremendous, and I’ve seen server monsters crawling under pressure. The cursors are replaced with MARS (Multiple Active Result Sets), which basically take the browsing through recordset chore away from the SQL and assign it to the NST.
2. Caching
Apart from MARS, another killer improvement is the caching. Most of data access operations are cached on the NST, which results in a considerable reduction in the number of SQL Server calls. Now, caching alone is a great improvement, but caching + MARS is a winner.
Try profiling a simple thing, such as this:

IF Cust.FINDSET THEN

  REPEAT

  UNTIL Cust.NEXT = 0;

Run it a couple of times in a row. Under NAV 2013, you get a single SELECT against the SQL Server, then nothing else. The iteration happens on the NST, and every consecutive call to the same stuff does everything on the NST. Try that under NAV 2009, and the profiler goes bananas.
3. SIFTs
There are several improvements in how NAV 2013 handles SIFTs. First – you don’t have to explicitly declare SIFT fields on keys. You can do CALCFIELDS and CALCSUMS on any decimal field, regardless of the structure of keys on the source table. And SQL simply calculates the value. This relieves SQL from maintaining too many indexed views. Yes, I know, it also slows the read operations slightly, but did I mention the caching? Oh, sorry, I have. There.
Another improvement is that you can include the SIFT fields into the SQL statement, and get the SIFTs with the same single SELECT statement that NST issues against SQL. You do this with the SETAUTOCALCFIELDS statement which you call on a record variable just before you FIND or FINDSET the records.
Compare these two in the profiler, and it’s clear right away:
a) with CALCFIELDS

IF Cust.FINDSET THEN

  REPEAT

    // Balance is not calculated, we have to do it manually

    Cust.CALCFIELDS(Balance);

  UNTIL Cust.NEXT = 0;

b) with SETAUTOCALCFIELDS

Cust.SETAUTOCALCFIELDS(Balance);

IF Cust.FINDSET THEN

  REPEAT

    // No need for CALCFIELDS, Balance is returned already

  UNTIL Cust.NEXT = 0;

With the option a, whenever you hit the CALCFIELDS, the NST obeys and fetches the sum. With the option b, there is a single SELECT statement, which already includes the OUTER APPLY clause, which calculates the SUM for each row retrieved.
Pretty cool stuff.
4. ADO.NET
The whole shebang is now run on ADO.NET, instead of OLEDB/ODBC that it was before. There are plenty of benefits of that, performance included.
ADO.NET streamlines deployment and administration, increases performance, reduces the number of SQL connections (Jörg has explained some drawbacks of this access, but I think generally that this is a good thing), reduces the memory consumption, and maybe a couple other things.
5. Unicode
I’ve already blogged about this, Jörg has also mentioned this, so I won’t play the same tune yet another time. NAV is now Unicode, which allows you to store characters in any language, at the same time.
Unfortunately, Unicode is not as Unicode as I’d truly love it to be, because the object captions remain tied to the chosen database collation (yes, you still need to choose this). That practically means that while you’ll be able to store characters from any alphabet, your RTC user interface will remain limited to a single character set.
Wrap up
So, to wrap it up, there is a lot of new things, bigger or smaller, that have been changed and that warrant better performance, or user experience, or both.
You may notice that I didn’t mention queries. Yes, they are a mind-boggling improvement over previous versions, but they are simply a completely new feature, not something that NAV had, and now has better than before. My list here is the list of tweaks and tune-ups that take those things that we are used to have to a new level altogether. Queries? Well, they are out of this world, but their true power is yet to come – when (I’m kind of sure it’s about “when”, not “if”) we’ll be able to use them as sources for pages or reports.

http://navigateintosuccess.com/blog/top-5-sql-server-improvements-in-nav-2013

NAV 2013 Performans Karşılaştırmaları

Benchmarking Results: NAV 2013 Outperforms All Previous Versions

by Vjekoslav Babic on June 25, 2012

Marketing is nice as long as it matches the reality. With Microsoft Dynamics NAV 2013, Microsoft has promised a lot of improvements, but how well does NAV 2013 stand the reality test?
Apparently, outstandingly well.
Over the past two days, I have intensively tested NAV 2009 and NAV 2013 through a series of five different tests that measure different aspects of NAV data handling. My conclusion is clear: NAV 2013 is faster than any NAV you have ever seen, including the Classic client on the native database.
Continue reading to find out more about my findings and testing approach.

Is This Some Kind Of A Trick?
No, this is not a trick. It’s for real.
Several days ago I wrote about performance improvements in Microsoft Dynamics NAV 2013, and then got a comment that it all looks nice in theory, but that NAV 2013 is actually slower than NAV 2009. Per Mogensen of Mergetool.com has done some testing and published a video demonstrating the results.
I’ve reviewed the video, and I’ve noticed a couple of possible issues with how the performance was measured, so I decided to do check for myself. My results show something completely different: not only NAV 2013 is faster than NAV 2009, it’s also faster than the Classic client on the native database – kind of a holy grail of NAV performance.
And then I double-checked with Per, and he confirmed to me that he also noticed a couple of problems himself. He has repeated the tests, and his tests now also show great improvement in NAV 2013. His updated video is here.
But, let’s continue with my results.
The Racing Horses
To find out how fast NAV 2013 really is, I’ve compared it to other flavors of NAV. The racing horses were:

• Microsoft Dynamics NAV 2013 RoleTailored Client
• Microsoft Dynamics NAV 2013 Web Services
• Microsoft Dynamics NAV 2009 RoleTailored Client
• Microsoft Dynamics NAV 2009 Web Services
• Microsoft Dynamics NAV 2009 Classic Client – SQL Server Option
• Microsoft Dynamics NAV 2009 Classic Client – Native Database Option

So, quite a jolly bunch. I would love if I could also have tested the performance of 2009 NAS on both native database and SQL Server, but I chose to let it pass.
The Environment
All of the applications have had exactly the same operating conditions, under exactly the same environment and system configuration settings. The following are the system specifications:

• Intel Core i7-2620M CPU (Quad Core)
• 8 GB of RAM
• OCZ Vertex2 SSD drive
• Windows 7 Ultimate, Service Pack 1, 64-bit
• Microsoft SQL Server 2008 R2, Standard Edition, 64-bit

The machine was physical, not virtual. All flavors of NAV were installed on the same physical instance.
The Tests
All of the six applications had to endure the same testing conditions, and have run the following tests:

• Creating, releasing, shipping and invoicing a sales order, 100 times in a row (the original Per Mogensen’s test)
• Iterating through all customers, vendors, and items, 500 times in a row
• Iterating through a filtered list of customers, vendors, and items, with an inefficient filter over a text field, 500 times in a row
• Iterating through a unique list of G/L accounts from the G/L Entry table, 500 times in a row.
• Manually summing flow fields of all customers, vendors, and items, by calling CALCFIELDS on each row, 500 times in a row.

In addition, under NAV 2013 I’ve run the following test as well:

• Manually summing the balance and inventory flow fields of all customers, vendors, and items, respectively, by calling SETAUTOCALCFIELDS before the iteration, 500 times in a row.

The Methodology
Before each of the tests, I prepared the environment by doing the following:

• I stopped all instances of NAV and closed all clients and made sure no applications were running.
• I created a new empty database.
• I restored the W1 database into the just created database.
• I started the relevant service tier and clients, and then ran all the tests three times to warm the system up.
• I cleared the time logs to eliminate the warm-up results, and make sure they don’t distort the test results.
• Closed any unnecessary applications (e.g. the Classic Client before using the RTC to run the tests) to ensure that only the environment which is running the test is open.

Then, after the environment was ready, for each of the tests I did the following:

• Ran the test three times in a row.
• Copied the results from the log table into Excel.

The warm-up is indeed slower under NAV 2013, than under any other system, and my methodology disregarded the warm-up measurements. Warm up times mostly don’t show anything useful.
Each of the tests records the time right before the test starts, and then again right after it ends. The time difference is then logged into the database.
I measured the time by creating two DateTime instances, setting them to current system time, then subtracting the start time from the end time. This gives the duration in milliseconds. In addition to this, under NAV 2013 I’ve added another measurement method: the .NET System.Diagnostics.Stopwatch class, just in case – if there is anything flawed with NAV’s time variable in 2013, certainly nothing will be wrong with the .NET Stopwatch. As expected, there was no difference between what NAV calculated and what the System.Diagnostics.Stopwatch measured.
In the results, all measurements I present are in milliseconds, and in all test results I’ll show, less is better.
The Results
Finally, we get to the point which I believe you await as much as did I: the results. Let me present them test by test.
1. Sales Orders
In the Per Mogensen’s tests, the NAV 2009 Classic Client on a native database is the winner of this test. At pure C/AL level, NAV 2013 there performs almost as fast as Classic on native, but the RTC under NAV 2013 is still the slowest. My results are very different. I can’t be 100% sure why, but I’ll give a couple of thoughts at the end of this post.
In any case, these are the measurements I got:

2013, Web Services	5,169
2013, RoleTailored Client	6,186
2009, Classic Client, Native	7,467
2009, Web Services	11,778
2009, Classic Client, SQL	14,420
2009, RoleTailored Client	14,690

A picture is worth a thousand words, so here it comes:

Image 1: Sales Orders test results

As I expected, the Web Services perform faster on both 2009 and 2013, because there is no user interface and only the NST is involved in code execution. Under Web Services, NAV 2013 performs about 44% faster than the fastest breed of NAV ever – the Classic Client on a native database. Stripped off the burden of a UI, NAV 2013 Web Services practically demonstrate pure SQL Server performance, and SQL Server is faster than ever before, just as it says on the tin.
But NAV 2013 RTC also showed respectable performance. It performed 21% better than NAV 2009 Classic Client on native database. I kind of didn’t expect this to occur, because the Classic Client on native database is a native ISAM system and NAV business logic is entirely optimized to fly on it. What astonishes me is 128% improvement of NAV 2013 over NAV 2009 in Web Services, or 137% improvement in RoleTailored Client performance. That’s truly amazing.
Obviously, NAV 2013 provides considerable improvement over NAV 2009.
2. Repeated Read
This test measures the capability of a client to iterate through a series of records. Iteration is something that C/AL code frequently does, and where any flavor of NAV somewhat sucked under SQL Server, as compared with the sheer performance of the native database. Again, native database and C/AL as a language are optimized precisely for this kind of access, and it was never a wonder that the native was a king here.
However, NAV 2013 seems to have just deposed that king:

2013, Web Services	16
2013, RoleTailored Client	25
2009, Classic Client, Native	644
2009, Web Services	8,081
2009, RoleTailored Client	8,133
2009, Classic Client, SQL	8,637

Graphically, this is how it looks:

Image 2: Repeated Read of Customers, Vendors and Items

NAV 2013 is lightning fast here, and no wonder why: the caching. While NAV 2009 on SQL Server had to maintain a series of cursors, NAV 2013 ran a single T-SQL query, and then cached the records for subsequent reads. It simply outperforms everything.
I don’t want to spend any time comparing the speed of NAV 2013 with the speed of NAV 2009 native; what I want to do is point out the speed improvement by a factor of more than 400x over NAV 2009 on SQL. How cool is that?
3. Repeated Read of Filtered Tables
The beauty of this test is that it shows how well a system copes with a complex filter. I’ve set the filter on Name and Description columns on Customer, Vendor and Item table respectively to this: @*a* (it searches for letter a anywhere in the field, in a case-insensitive way).
This filter can’t make meaningful use of any key, so what shall win or lose this race will be the capability of the database management system to handle such a process on foot.
Again, NAV 2013 played this one coolly.
Here go the results:

2013, Web Services	20
2013, RoleTailored Client	24
2009, Classic Client, Native	515
2009, Web Services	5,720
2009, RoleTailored Client	5,741
2009, Classic Client, SQL	6,178

This is the graph:

Image 3: Repeated Read of Filtered Tables

While the variances in NAV 2009 SQL Server flavors are insignificant, the improvement of NAV 2013 is again verging with insane. It’s obvious that the cache kicked in here bit time, but I also assume that there may be some .NET-level code optimization that made this kind of thing possible.
4. Reading Unique G/L Account Numbers from G/L Entry
Now, this was a tricky one. It uses several concepts, combination of which is a total no-brainer for the ISAM-based NAV 2009 on native, but verges on rocket science for anything SQL-related. It was literally the most inefficient thing to do to a SQL database in NAV, and running a piece of code such as this literally smothers SQL by causing it to drop existing and create new cursors all the time.
The algorithm is as follows:

1. Set the key on G/L Account column
2. Find the first G/L Entry row
3. Set a filter on the G/L Account column to that G/L Account which is currently selected
4. Find the last G/L Entry with this filter applied
5. Remove the filter on the G/L Account column
6. Repeat 3 to 6 until there are more G/L Entry rows

In previous versions, steps 2, 4, and 6 drop existing (except for the first iteration) and create new cursors in SQL Server, and I was curious to find out how well SQL coped with this task now that cursors are gone, and MARS is taking their role. There are much less read rows in this test than in the simple repeated read, and if you understand how ISAM works, and how SQL works, you should also expect ISAM to do this with no speed penalty over a simple iterative read, while you can expect SQL to run way slower than a simple iterative read, no matter which approach it takes.
And this is exactly what the results show:

2009, Classic Client, Native	478
2013, Web Services	1,129
2013, RoleTailored Client	1,142
2009, Web Services	11,029
2009, RoleTailored Client	11,113
2009, Classic Client, SQL	11,555

And then, the picture:

Image 4: Repeated Read of SIFT-Filtered Tables

Now, before jumping out from your seat and shouting “gotcha!”, think of this test once again. NAV 2013 is almost 10x faster than NAV 2009 here, and whatever it did deep there in its engine is close to a miracle. If it did caching to attain this speed, that caching must be pretty smart, because this piece of code was accessing some very small sets and jumping around the records like crazy.
While I have a very plausible explanation what made NAV 2013 win all previous tests, I don’t have a faintest idea what kind of magic made it perform this well here. Yes, it is slower than native, but this was kind of like making a Formula One compete in a rally.
Catch this: native is fully optimized to do this kind of access, and doing this is no smarter for it than doing the simplest kind of data iteration. As a matter of fact, since there were less rows to read, this one should have been faster than the repeated read test. And it was. At the same time, NAV 2009 on SQL was slower here, because this put much more pressure on it, and it had to struggle. And struggle it did.
Yet, NAV 2013, while still struggling, has shown an incredible performance improvement to make even this kind of thing perform well. Quite a job, Microsoft!
5. SIFT Read
I measured how various systems perform with SIFTs, in a scenario quite common in real life: iterating through a set of data and calculating flow fields for each row. NAV does this in many situations, and I was very curious to find out how fast NAV 2013 would be here, because of the many changes Microsoft has done in handling the flow fields in NAV 2013.
Here are the results:

2013, RoleTailored Client	1,517
2013, Web Services	1,518
2009, Classic Client, Native	1,638
2009, Web Services	9,500
2009, RoleTailored Client	9,552
2009, Classic Client, SQL	9,745

Or graphically:

Image 5: SIFT Read

When handling flow fields, NAV 2013 performs slightly better than native ever did, about 8% faster. This is quite a feat, if you have in mind that native handles this functionality again, well, natively, by building the flow field information right into indexes, something that SQL never could.
Okay, I assume that some serious caching took place here as well, but still, caching or not, the whole system performs better and faster in NAV 2013. Compared to SQL Server flavors in NAV 2009, the improvement of 532% is quite amazing, and even more so if you think that probably everybody thought that Microsoft has hit the limit with replacing SIFT tables with indexed views in 5.0 SP1. With that obviously not having been a limit at all, I now wonder shall we experience even more improvement here in the future?
5a. SETAUTOCALCFIELDS
Finally, I ran the same test as the previous one, with the SETAUTOCALCFIELDS. I expected serious improvement, but at average of 1,466 milliseconds, this test performed practically only insignificantly faster than the previous one. I expected this one to show the real improvement over the traditional CALCFIELDS approach, but it stubbornly declined. I can’t explain this, but hey, let’s not get too picky
Overall Results
When you add all of the figures above together, the cumulative results demonstrate that Microsoft Dynamics NAV 2013 outperforms its previous incarnations, including the so-far unbeatable Classic Client on a native database.
On average, this is what it took the three clients to execute all tests:

2009 SQL	48,636
2009 Native	10,743
2013	8,374

And the last picture of the day:

Image 6: Overall Results

Obviously, the improvements that NAV 2013 promises are not just plain words, as these test results show. The overall performance is about 28% better than with the NAV 2009 Classic Client on a native database, and about 480% better (that’s almost 6x performance improvement!) than with NAV 2009 under SQL Server.
However, this is only a part of the story. There is another one: concurrency. Performance is always welcome, but performance is not what has been preventing NAV to scale as much as, for example, AX could. I wonder if Microsoft will release a hardware sizing document that would estimate some kind of the upper limit for vertical scalability of NAV 2013. The last time we got such numbers from Microsoft was with version 5.0 SP1, when it was set at 250 concurrent users.
Of course, any estimates of the kind are comparing apples to oranges, anyway, because at that number of users, the application is probably always heavily customized, and the actual upper vertical scalability limit will invariably depend on a very complex set of parameters, and can be determined only on a case-by-case basis.
I would’ve loved to have done concurrency tests together with the performance tests, but I may do that another time. However, based on the figures I see here, I dare estimating that everything else being equal, concurrency levels can at least be doubled in any given NAV 2013 deployment, over an equal NAV 2009 deployment.
But What About The Other Test?
So, why do Per Mogensen’s test show somewhat different results? On the C/AL level, hist test is very consistent with my measurements with Web services, but in Per’s tests, NAV 2013 performance with RTC is still inferior to all other clients and platforms.
I can’t tell for sure, but I’ll give my best guess:

• Virtualization: The systems were comparable, but the tests were run under different virtual machines, and the virtual hypervisor in charge might have redistributed resources, or other virtual machines were doing some cleanups while NAV 2013 was running, or a whole range of other things might have happened.
• Hardware: The RTC is a .NET application, and depends a lot on hardware on a machine to execute all the things that .NET applications do: just-in-time compilation during warm-up, and talking to video drivers at run time. Since it was a virtual box, maybe the virtual hardware causes troubles with .NET applications talking to it, while it performs better when Win32 applications (as the Classic client) are talking to it.
• Warm-up: While it certainly should be enough to run 100 sales orders through the create-release-ship-invoice cycle to warm a system up, I still think that a thorough warm-up is required for any kind of benchmarking. The warm-up time itself should be disregarded as it is no measure of either real performance under pressure, or the scalability. To determine if the system is properly warmed up, you need to keep running warm-ups until you see no significant performance between the two runs. Only then you can start measuring. The minimum number of runs to determine this condition is three runs.

Don’t Take My Word For This
So, who do you trust, Per or me? Neither one! Please, don’t just take my findings for granted. Do the measurements yourself.
Here, I’ve attached the objects that I’ve used to run the benchmark, so you can run the same tests on your own machine, and see your own results. I am really curious about the results you’ll get.
So, download the objects:

• Performance Test, NAV 2009 Native
• Performance Test, NAV 2009 SQL
• Performance Test, NAV 2013

The reason why there are three distinct sets of objects is that NAV 2013 uses .NET Interoperability in addition to system time to measure time, and that native doesn’t use role centers. Everything else is exactly the same.
(Just in case you need it, here is also my Excel sheet with testing results and charts.)
Run the tests, and then come back here and share your findings. I’d love to hear from you!

http://navigateintosuccess.com/blog/benchmarking-results-nav-2013-outperforms-all-previous-versions