1C:ERP uygulaması için danışmanlığa ihtiyacınız var mı?
Muhasebe metodolojisinin sistem kurulumundan önce ne zaman yazılması gerektiği ve danışmanlığın neden entegratörle birlikte yürütülmesinin daha doğru olduğu
Bolshaya Pochtovaya Cad. No: 55/59, Blok 1, Ofis 548, 105082 Moskova (Elektrozavodskaya metro istasyonu)
09.03.2024
Büyük işletmeler ve holdingler için ERP uygulama metodolojisi
Büyük şirketler ve holdingler için.
Bu metodoloji, SAP ve Oracle'dan 1C'ye geçişler için tasarlanmıştır. Eski 1C sistemlerinden daha modern olanlara geçiş için de uygundur (örneğin 1C:UPP'den 1C:ERP'ye).
*Kamu sektörü veya küçük işletmeler için uygun değildir.
Uygulama projelerinin çoğu, müşteri ihtiyacı anlamadığı ya da projeye yeterli zaman ayırmaya ve çalışmaları zamanında yürütmeye hazır olmadığı için başarısız olur. Ne yazık ki bir ekip gelip her şeyi kurup gidemez. Bilgileri sağlayacak, düzeltmeler yapacak, sonuçları test edecek, proje ilerledikçe kilit kararları verecek ve tamamlanan işi kabul edecek olan müşteridir. Metodolojimiz projeyi sonuca kadar götürmemizi sağlıyor; müşteri de her aşamaya katılıyor, gelişmelerden haberdar oluyor ve süreci etkileyebiliyor, böylece tam olarak istediğine kavuşuyor.
Her müşterinin hedefi:
1) yeni sisteme zamanında ve bütçe dahilinde geçmek,
2) verimlilikten ödün vermeden, işin sürdürülmesi için kritik olan temel süreçleri korumak,
3) yeni sistemdeki özel geliştirmeleri asgaride tutmak; çünkü bunlar her zaman ek geliştirme ve gelecekte destek maliyeti anlamına gelir.
Yeni bir sistemin uygulanması her şeyden önce danışmanlıktır. Eskiden uygulamaları geliştiriciler yönlendirirken bugün işin büyük kısmını analistler yapıyor. Analiz ne kadar iyi olursa, o kadar az özel geliştirme gerekir.
1. Aşama: Tasarım.
- Şirketin mevcut iş süreçlerini analiz etmek ve belgelemek; böylece Uygulayıcı Firma ile Müşteri tüm süreçlere ilişkin ortak bir görüşe sahip olur.
- Bu süreçleri yeni sistemde modellemek. Yani gerçek belgeleri ve süreçleri alıp yeni sistemde yeniden oluşturmaya çalışmak. Müşteriye bir demo gösteriyoruz ve sonuçlara göre sistemin doğru çalışmasını engelleyecek “darboğazları” (işlevsel eksikleri) kaydediyoruz.
Verilerin eski sistemden yenisine aktarılması gerektiğinde, aktarılacak veri kapsamı üzerinde anlaşılmalı ve veri aktarım araçları geliştirilmelidir.
2. Aşama: Geliştirme.
Kritik eksikler belirlendikten sonra çözümler geliştirip müşteriyle mutabık kalıyoruz; müşterinin ne alacağını anlaması ve geliştirmeyi yönlendirebilmesi için çalışmamızın sonuçlarını her hafta gösteriyoruz.
3. Aşama: Pilot kullanım.
Sık karşılaşılan bir sorun: geliştirme tamamlanmış ve veriler yüklenmiştir, ancak hatalar nedeniyle sistem çalışmaz. Bu nedenle kapsamlı test gerekir.
Dahili test: teknik ve fonksiyonel mimarların liderliğinde, sistemin kendi bünyemizde baştan sona eksiksiz çalıştırılması.
Harici test: aynı çalıştırma, bu kez müşteriyle birlikte. Bu aşamada müşteri düzeltme talep edebilir.
Kabul testi: adım adım test senaryoları hazırlıyoruz ve müşteri, sistemin nasıl çalıştığını kontrol etmek için tüm süreci kendi başına baştan sona yürütüyor.
Sonuçlara göre hataları düzeltiyor, kullanıcı kılavuzlarını hazırlıyor ve çalışanları eğitiyoruz.
4. Aşama: Canlı kullanım.
Çalışanlar sisteme alışırken, canlıya geçişten sonra projeyi her zaman 3–6 ay boyunca destekliyoruz.
Projeye ilişkin tüm bilgileri (planlar, çizelgeler, hedefler ve sonuçlar) müşteriye bir sunum olarak aktarmak en iyisidir. Böylece müşteri sonuca dair ilk fikri edinir. Müşteriler genellikle kendilerinin de belirli işler yapması gerekeceğinin farkında olmaz. Sunum bunu açıkça gösterir.
Uygulama yalnızca uygulayıcı firmanın ekibine bırakılamaz. Ortak çalışmanın kapsamını göstererek, projenin başarısının bağlı olduğu kuralları fiilen ortaya koyuyoruz. Aşağıdaki tabloda müşteri çalışanlarının nasıl yer aldığı gösterilmektedir.
Proje sponsoru nihai kararları onaylar, bütçeyi tahsis eder ve projeyi bir bütün olarak kabul eder.
Proje yöneticisi projenin bütününü yönetir. Örneğin hizmet sağlayıcının müşteri şirketi içinde yetkisi yoktur; bu nedenle astlarından gerekli disiplini talep edebilecek bir iç proje yöneticisine ihtiyaç vardır.
Anahtar kullanıcılar, sistemi uyguladığımız ana alanların sahipleridir. Genellikle bölüm yöneticileridir. Örneğin finans modülünü uyguluyorsak bu kişi finans direktörüdür (CFO); diğer alanlarda da durum benzerdir.
Geçiş yaptığımız sistemin uzmanı. Mevcut sistemdeki verileri yenisine aktarmak üzere hazırlayan teknik bir uzmandır.
BT uzmanları harici sistemlerle çalışır, gerekli erişimleri verir, dahili araçları sağlar ve gerekli sunucu işlerini yapar.
Uygulama sırasında her zaman takvime ve bütçeye uymamız gerekir. Ancak insanlar genellikle yıllar içinde özelleştirilmiş eski sistemlerini olduğu gibi yeni sisteme taşımak ve bu arada yeni gereksinimler de eklemek ister; yani 1C'yi alıp SAP'ye dönüştürmek. Ama gerçekçi olalım: yıllar ve büyük bütçelerle kurulmuş olanı altı ayda ya da bir yılda elde edemezsiniz. Bu gibi durumlarda özel geliştirme maliyetleri bütçeyi 3–4 kat aşar.
Peki bütçeyi aşmamak için ne yapılacağına nasıl karar verilir?
Bu çelişkiyi şöyle çözüyoruz.
Tüm iş süreçlerinin kritiklik düzeyine göre sıralanmasını öneriyoruz.
Bütçe genellikle yüksek öncelikli süreçleri ve orta öncelikli süreçlerin bir kısmını karşılar. Düşük kritiklikteki kalemler, sistemin sonraki geliştirmelerine ertelenir.
Deneyimlerimiz, yüksek ve orta öncelikli kalemler hayata geçirilerek uygulamanın zamanında ve planlanan bütçe içinde tamamlanabileceğini gösteriyor. Ancak canlıya geçişte genellikle yalnızca yüksek kritikliğe sahip kalemler devrede olur. Sistemi geliştirmeye canlıya geçişten sonra bir yıl, iki yıl, hatta 10 yıl devam edersiniz.
Her şeyi bir anda yapmaya çalışırsanız proje tıkanır, takvime de bütçeye de uyamayız.
Bu nedenle:
Bu aşamalı yaklaşım, istenen sonuca ulaşma şansını en üst düzeye çıkarır.
BT alanındaki on yıllık deneyimimiz, projenin temel sorularına yanıt veren bir metodoloji geliştirmemize yardımcı oldu: otomasyonu kritik iş süreçlerini ve verimliliği koruyarak, asgari özel geliştirmeyle, takvime ve bütçeye uygun biçimde nasıl hayata geçirebiliriz.
Muhasebe metodolojisinin sistem kurulumundan önce ne zaman yazılması gerektiği ve danışmanlığın neden entegratörle birlikte yürütülmesinin daha doğru olduğu
1C:ERP, SAP Business One, Odoo, Dynamics 365 ve Megaplan karşılaştırması: artılar, eksiler ve sektörünüze uygun seçim
Müşteri tarafında beş rol: bütçeyi kim onaylar, alanlardan kim sorumludur, verileri ve erişimleri kim hazırlar