ERP sistemleri: basit terimlerle nedir, ERP'nin artıları ve eksileri, genel bakış. V İşletmede ERP sisteminin uygulanması. Bir işletme için bir ERP sistemi nereden edinilir

Rusya'da ERP sistemleri pazarı hızla büyüyor. Ancak, ERP projeleri genellikle başarısızlıkla sonuçlanır. Uzmanlara göre, ERP sistemleri uygulama projelerinin yaklaşık %70'i belirtilen hedeflere ulaşmıyor. Ana nedenleri tartışmayı öneriyoruz. Sonuçta, önceden uyarılmış, önceden hazırlanmış.

ERP (Kurumsal Kaynak Planlama) sistemleri pazarı, dünyadaki en hızlı büyüyen yazılım pazarlarından biri olmaya devam ediyor. TAdviser'e göre, 2015 sonunda Rus ERP sistem pazarının hacmi %9 artarak 108 milyara ulaştı (şekle bakınız). 10 üzerinden 8 gelir en büyük oyuncular yurt içi ERP pazarı da raporlama döneminde olumlu dinamikler gösterdi.

Resim çizme

Her şeyden önce, dile getirilen ilgi ERP sistemleri işletmelerin bu tür sistemlerin kullanımından elde edebilecekleri önemli faydalar beklentisiyle ilişkilendirir. Ancak bu beklentiler, çoğunlukla, bu yazılımı uygulayan şirketlerin vaatlerine dayanmaktadır. Ancak, çoğu zaman ERP sistemlerinin uygulanmasına yönelik projeler başarısızlıkla sonuçlanır. ERP sistemleri uygulama projelerinin yaklaşık %70'i, bir ERP sisteminin ne olduğunun banal bir yanlış anlaşılmasından dolayı belirtilen hedeflere ulaşamıyor.

Bu kadar üzücü istatistiklerin nedeni nedir ve önemli finansal ve zaman kaynakları harcadıktan sonra bunu kanıtlamamak nasıl? ERP projelerinin uygulanmasında yapılan İLK-10 hataları sunuyoruz. Bu liste kapsamlı değildir ve müşterilerle çalışma sırasında uzmanlarımız ve danışmanlarımız tarafından bulunan hataların bir listesidir.

Yararlı belgeleri indirin:

1 numaralı hata. ERP uygulamasına başlamadan önce iş süreçlerini açıklamayın

"Nasıl olması gerektiği" düzeyinde açıklanan iş süreçleri veya en azından net bir anlayış ve bilgi ve malzeme / belgesel akışlarının "kağıt üzerinde" gösterilmesi olmadan ERP sisteminin yüksek kaliteli bir uygulamasını gerçekleştirmek imkansızdır. şirketin. Uygulamanın o kritik anında danışmanların işin içine girmesi, sistemin başarısız olması ve istenilen etkiyi vermemesi, uygulayıcıların ve yönetim ekibinin doğru yola koyamaması gibi bir seçeneğe sıklıkla rastlıyoruz. Bu tür başarısızlıkların nedenlerini araştırırken, sistemi uygulayanlar ve şirketin kendisi tarafından süreçlerin anlaşılmasında ciddi tutarsızlıklar ortaya çıkıyor - bunların hiçbir açıklaması yok veya resmi olarak yapılıyor ve gerçek üretim döngüsünü yansıtmıyor .

Bu tür durumların en yaygın nedeni, müşterinin bu adımın tanımı ve detaylandırılmasından tasarruf etme arzusudur ve bu aslında oldukça maliyetli olabilir. Müşteri, süreçlerde ayarlamaların halihazırda uygulama aşamasında yapılabileceğini beklemektedir. Bir yandan, bu mantıklı, çünkü proje ile doğru yapı, giderek daha fazla bölge ve bölüm dahil olmak üzere aşamalı olarak gelişecek, proje geliştikçe bir şeyleri modernleştirecek ve iyileştirecektir. Ancak bu, gelişim sürecinde iş süreçlerinin sürekli değişebileceği anlamına gelmez - bu, bir daireyi yenilemek, tasarım projesini sürekli değiştirmek gibi... Bir gün yine de tamir edeceksiniz. Tek soru, sonunda size ne zaman ve ne kadara mal olacak?

Bizim açımızdan makul seçeneklerden biri ön iş süreçlerinin açıklaması "Olduğu gibi (olduğu gibi)", uygulama ekibinin yardımıyla yazılım platformuna yerleştirilmesi ve "olduğu gibi (olduğu gibi)" haline dönüştürülmesi, aslında uygulamanın temelidir. Buna paralel olarak, proje ekibiyle birlikte, geliştirme ilerledikçe süreçleri değiştirebilir, çalışan ve otomatikleştirilmiş süreçleri optimize etmek için en iyi çözümleri ve fikirleri bulabilirsiniz.

Hata # 2. Gelecekteki sistemde sürekli değişiklik yapın

Bir diğer yaygın hata da, gelecekteki sistemde ayarlamalar yapmak ve onları takip etmemek (iğnede olmak ister misiniz?). ERP uygulaması her zaman zaman alıcı ve zahmetlidir. Ancak, uygulayıcılara tamamen güveniyorsanız ve onlardan orijinal platformda yapılan değişikliklerin ayrıntılı bir tanımını talep etmiyorsanız, bu süreç daha da karmaşık hale gelebilir. Sonuç en içler acısı olabilir - sözleşme feshedilirse, kendi başınıza çalışmaya devam edemeyeceğiniz çok sayıda anlaşılmaz kod alma riskiniz olur veya yalnızca onlar anladığı için sınırlı bir uzman çevresiyle etkileşime geçmek zorunda kalırsınız. yarattıkları sistemin özü. İş, bu konuda ortaklara ve onların iyi niyetine (veya eksikliği - bizim pratiğimizde mahkemeler bu konuda yardımcı olabilir, ancak çok fazla zaman alabilir) bağımlı olmamalıdır ve güvenemez. Uygulayıcılarınızın bakım yapmasını isteyin Proje belgeleri, projeyi bağımsız olarak devam ettirebilmek için kadroya uzman personel almak veya yükleniciyi değiştirmek.

3 numaralı hata. Tamamen otomatikleştiricilere güvenin

Otomatların sizin için her şeyi yapacağına inanmaya değmez. Bir nokta bile yok. Şirketinizin tüm özelliklerini, etkileşimlerin nüanslarını ve iş yapmanın inceliklerini hesaba katamayacaklardır. Her şirket bireyseldir. İyi bir sonuç almak istiyorsanız - EPR sistem uygulama projesine en baştan katılın! Proje ekibi, projenin başarısız olma riskini önemli ölçüde azaltacak ve "raporlar için veri giriş sistemi" yerine şirket için yararlı bir yönetim aracı oluşturmanıza olanak sağlayacak şirketin kilit uzmanlarını mutlaka içermelidir. Uygulamanın amacını hatırlayın - şirketin operasyonel verimliliğini artırmak.

Hata # 4. Tüm durumlar için teknik özellikler geliştirmek

Her şeyi hesaba katmak imkansızdır, uygulama sırasında bazı anlar "doğacaktır" ve uygulayıcılarla yapılan anlaşmada belirtilenler de dahil olmak üzere bir dereceye kadar özgürlük olmalıdır. Alternatif olarak, ek geliştirmeler için danışmanlık saatlerinin sayısını sözleşmede tanımlayabilirsiniz - anahtar teslimi olarak uygulanırsa proje maliyetine dahil edilebilir veya ayrıca adam-saat oranında hesaplanabilir. Tüm nüansları göz önünde bulundurarak teknik bir şartname geliştirme girişimi, proje ekibi tarafından okunması ve incelenmesi bile olası olmayan büyük bir talmud oluşturulmasına yol açacaktır.

Hata #5. Personel direncini görmezden gelin

Şirketin uzmanları ERP projesinde yer almıyorsa, risk değişime direnç , bir "liderlik sistemi"nin getirilmesi tüm iyi çabaları mahvedebilir. Uygulamamızda, yönetim baskısı altında şirketin, sistemin uygulanması sırasında personelinin yaklaşık %50'sini kaybettiği durumlar vardır.

Hata #6. ERP uygulama projesine yeterince dikkat etmemek

Otomasyon hiçbir durumda isteğe bağlı değildir. Uygulamamızda, sistemin uygulanması için bir projenin ek bir seçenek olarak bir üst yöneticiye devredildiği bir durum vardı. Sonuç olarak, uygulama süresi ve maliyeti planlanan 2 katı aştı.

Bir ERP sistemi uygulama projesi, tam teşekküllü bir daldırma ve ideal olarak, şirketten tüm proje bilgilerini ve iletişimini elinde birleştirecek ayrı bir proje yöneticisi gerektirir. Sadece uygulayıcılar tarafından proje yöneticisi yeterli olmayacaktır.

Anlamak ve kabul etmek önemlidir - ERP uygulaması-sistemlere öncelikle şirketiniz tarafından ihtiyaç duyulur. Ne yazık ki, uygulama şirketi bununla daha az ilgileniyor - faturaları düzenli olarak ödemenizden memnunlar.

7 numaralı hata. Her şeyi aynı anda yapmaya çalışmak

Uygulama projelerini destekleme konusundaki deneyimimize dayanarak, scrum (çevik yazılım geliştirme metodolojisi) temelli projeleri dağıtma kavramlarının gerçekten işe yaradığından ve sonuç verdiğinden emin olduk (ayrıca okuyun Çevik metodoloji). Her aşamada ürünün çalışan bir versiyonunu elde etmek için küçük modüller halinde (1 aya kadar döngüler) çalışmak, odaklandığımız ana prensiplerdir. Ayrıca, kalan modüllerin geliştirilmiş olanla ayarlanması ve hizalanması olabilir. Sistem, şirketin görevlerine esnek bir şekilde uyum sağlayarak aşamalı olarak dağıtılır. Sistemi bir kerede tamamen devreye alıp test etmeye çalışmak, tüm bütçenizi ve zamanınızı harcama riskine girer ve sonunda çalışmayan bir ürün şeklinde hoş olmayan bir sürprizle karşılaşırsınız.

8 numaralı hata. Yanlış platformu seçin

Bir platform seçerken, işinizin ihtiyaçlarını gerçekten karşıladığından ve yalnızca finans, muhasebe değil, aynı zamanda temel işlemleri (üretim, satış vb.) destekleyeceğinden emin olun. Şirket türünüze (üretim, lojistik, vb.) göre tam olarak tasarlandığından (çok yönlülük burada zarar görebilir) emin olun. Bu gereklilik hem işlevsel hem de donanım ve yazılım platformları için geçerlidir.

Sistem operasyonlarınız için ne kadar iyi olursa, modifikasyonlara o kadar az zaman ve para harcarsınız ve sistemle çalışmak o kadar uygun olur.

Hata # 9. Yanlış otomasyon ekibi

İşinizi anlayan danışmanlar bulun. Bir imalat şirketinin iş süreçlerinin, üretimde yaygın olan yönetim yöntemleriyle yaklaştırılamayacağını anlamak önemlidir. perakende ya da hizmet sektöründe, her neyse iyi sistem desteklenmediler ve hangi danışmanlar uygularsa uygulasınlar. Programlama, DBMS, muhasebe ve ticaret bilgisi önemlidir, ancak ana işi imalat olan bir şirkette sistemin uygulanmasına pek yardımcı olmazlar.

10 numaralı hata. Yanlış ERP uygulama hedefleri

Şirketin en önemli iş süreçlerinin otomatikleştirildiği projenin bu aşamalarına geçişle birlikte uygulama sorunları genellikle artar. Yani, ana karı getiren faaliyet türüne karşılık gelen iş süreçleri. İçin ticaret şirketleri bu alımlar/satışlar, nakliye şirketleri- sanayi işletmeleri için ulaşım - üretim vb.

Ne yazık ki, çoğu zaman ERP sistemlerini uygulamanın amacı, geliştirmek için çok fazla değildir. üretim faaliyetleri işletme içindeki bilgi akışını sürdürme çabalarında ne kadar azalma olduğu. Klasik bir örnek, finansal ve operasyonel bilgileri tek bir veritabanında birleştirmek için bir sistemin uygulanmasıdır.

Entegre kurumsal sistemler olduğunu iddia eden çoğu ERP, başlangıçta müşteri ilişkileri yönetimi, finans ve muhasebe amaçları için oluşturulmuştur. Buna göre, muhasebe ve finans uzmanları tarafından BT uzmanlarının yardımıyla geliştirilmiştir. Sonuç olarak, ERP sistemleri muhasebenin gerektirdiği bilgileri sağladı ve finans departmanları, üretim ve diğer işletme birimleri (satış, tedarik, depolar) bu bilgileri sağlarken. Firmaların asıl işlerini etkilemeyen bu tür sistemlerin uygulanması genellikle önemli sonuçlar doğurmaz.

ERP sistemleri uygulama süreci geleneksel olarak 7 aşamaya ayrılır: organizasyonel çalışma, kurumsal anket, otomasyon metodolojisinin seçimi, sistem tasarımı, çalışanların işyerlerinde yazılım dağıtımı, sistemin endüstriyel işletime alınması, destek.

ERP uygulama prosedürünü daha ayrıntılı olarak ele almayı öneriyoruz.

I Organizasyon aşaması

Kurumsal bir ERP uygulama projesi üzerinde çalışmak, amaç ve hedeflerin tanımlanması... Otomasyon adına otomasyon olmak zorunda değildir - müşteri, nihai olarak hangi iş etkilerini elde etmek istediğini açıkça bilmelidir.

Hazırlık aşamasında, ayrıca gereklidir bir çalışma grubu oluşturmak müşteri tarafında. Şunları içermelidir:

süpervizör (tercihen şirketin üst düzey yöneticilerinden). Bu kişi, işletmenin tüm yönleri ve iş süreçlerinin organizasyonu konusunda bilgili olmalıdır. Ayrıca, ERP uygulama proje yöneticisi ortaya çıkan herhangi bir konuda tek karar verebilmelidir.
uzmanlar Sistemin yürürlükteki mevzuat gerekliliklerine uygunluğundan ve kurumsal standartlar... Bu kategori şunları içerir: Yönetici müdür, baş muhasebeci, BT hizmeti başkanı.
Tüm daire başkanları ERP sisteminde kimler çalışacak. Görevleri, işletmenin iş süreçlerinin incelenmesi aşamasında uygulayıcılara danışmanlık yapmak ve otomasyon sürecinin tamamlanmasından sonra departmanların çalışmalarını organize etmek olacaktır.
Geniş profilli BT uzmanı ... Sorumluluk alanı, projenin teknik desteği olacaktır.

Otomatik bir kontrol sistemi istiyorsanız üretim işletmesi En kısa sürede somut iş sonuçları veriyorsa, çalışanların onu mümkün olduğunca aktif ve verimli kullanmasını sağlamalısınız. Bunun için personelin ERP'de çalışacak şekilde eğitilmesi ve operasyonun ilk aşamasında sıkı bir şekilde kontrol edilmesi gerekir. Bu sorumluluklar, çalışma grubu temsilcilerinin de omuzlarına düşmektedir.

Ayrıca organizasyon aşamasında finansman kaynaklarının ve entegratör şirketin belirlenmesi gerekmektedir.

II İşletme anketinin aşaması

Organizasyonel çalışmanın tamamlanmasının ardından, işletmenin iş süreçleri hakkında bir anket yapılır. Bu prosedür, uygulama çalışmasının zamanlamasını ve maliyetini doğru bir şekilde belirlemek için gereklidir. Projenin ölçeğine ve belirlenen görevlere bağlı olarak, BT entegratörü müşteriye 2 anket seçeneğinden birini sunabilir:

Ekspres muayene. 1.5-2 ay içerisinde gerçekleştirilir. Sonuçlarına dayanarak, "Proje öncesi analiz" belgesi hazırlanır. Otomatik muhasebenin özelliklerini ve uygulama sürecinde çözülmesi gereken görevlerin bir listesini yansıtır.
Tam muayene ... 3-5 ay içinde gerçekleştirilir. Kapsamlı bir incelemenin sonuçlarına dayanarak, bir "İş Tanımı" hazırlanır, otomatik muhasebe için iş süreçleri geliştirilir ve gerekli yazılım değişikliklerinin bir listesi açıklanır.

Anket seçeneğinin seçimi, tercih edilen ERP uygulama metodolojisi tarafından belirlenir.

III ERP Uygulama Metodolojisinin Seçimi

1C: Enterprise platformunda ERP çözümlerinin uygulanması 4 senaryodan birine göre gerçekleştirilebilir:

Abone hizmeti ... Entegratör şirket, işletmenin açık bir araştırmasını yapar, entegre bir ERP uygulama planı hazırlar ve buna dayanarak projenin mümkün olan maksimum maliyetini belirler. Bu maliyet sözleşmede belirtilir ve uygulama programcısının bir saatlik çalışmasının maliyeti de orada kaydedilir. Genel çalışma planı aylara göre bölünmüştür. Çalışma saatlerinin sayısına göre aylık bütçenin büyüklüğü belirlenir. Sözleşmeye sabit bir ödeme tutarı da dahildir.
aşamalı teknoloji tanıtma ... Bu ERP uygulama metodolojisi, işletmenin tam bir araştırmasını, tüm otomatikleştirilmiş iş süreçlerinin tanımını ve teknik şartnamelerin hazırlanmasını içerir. Referans şartları şunları yansıtır: programın tipik konfigürasyonuna yönelik revizyonların kapsamı, sabit aşamalara ayrılmış tam bir iş listesi, ERP uygulamasının her aşamasının uygulanmasının zamanlaması ve maliyeti. Bu teknolojinin ana dezavantajı esnek olmamasıdır. Projede en küçük ayarlamaların yapılması, görev tanımında bir değişiklik gerektirir: işin bireysel aşamalarını gerçekleştirmenin zamanlamasının ve maliyetinin gözden geçirilmesi.
Hızlı sonuç teknolojisi ... ERP uygulama algoritması, abone hizmetleriyle yaklaşık olarak aynıdır. Ekspres bir anket de yapılır, projenin maksimum maliyeti hesaplanır, programcının çalışma saati tahmin edilir. Ödeme ayrıca ayda bir kez yapılır, ancak sabit bir oranda değil, programcılar tarafından fiilen harcanan saatlerin sayısına göre yapılır. Bir ay veya bir hafta için katı bir şekilde düzenlenmiş çalışma planı yoktur - görevlerin listesi ve sırası, işletmenin gerçek ihtiyaçlarına bağlı olarak değişebilir. Esneklik, hızlı izleme teknolojisinin kesin bir artısıdır. Projeye herhangi bir aşamada ve uzun onaylar olmadan ek iş süreçleri dahil edilebilir. Bu uygulama şemasının tek dezavantajı, proje uygulama zaman çizelgesinin belirsizliğidir.
Tek seferlik aramalar ... Programın çalışanların işyerlerine kurulumu ve iş süreçlerinin otomasyonu müşterinin imkanları ölçüsünde gerçekleştirilmektedir. Şirket bir kutu satın alır ve tüm uygulama çalışmaları tek seferlik aramalar senaryosuna göre yapılır.

IV ERP sistem tasarımı

Kurumsal anketin sonuçlarına göre, sistemin temel modülleri için işlevsel gereksinimler, ilk verileri yükleme ve halihazırda kullanılanlarla değişimi kurma ihtiyacı yazılım... Sistemde, şirketin ana iş süreçleri tasarlanmakta, işletmenin özelliklerine göre standart işlevsellik sonuçlandırılmaktadır.

V İşletmede bir ERP sisteminin uygulanması

Yazılım, çalışanların işyerlerine yüklenir. Erişim hakları ve raporların ayarlanması. Çalışma verileri ve referans bilgileri eski sistemden, Excel dosyalarından vb. yüklenir.

VI Sistemin ticari işletmeye alınması

Başlangıç olarak, projenin kendisi hakkında: 1C: ERP'nin sanayi kuruluşu... Müşteriye geldiğimizde (2015 yılında) fabrika sayısı 5 bin kişiydi. Proje süresince fabrika önemli ölçüde büyüdü ve üretim hacimlerini artırdı; şu anda yaklaşık 6,5 bin çalışana sahip. 1,2 bin işte 1C kuruldu. Şu anda yaklaşık 350 aktif kullanıcı var (Haziran 2017), 450'ye çıkarılması planlanıyor.

Girişim, Rusya'nın askeri-sanayi kompleksinin bir parçasıdır ve bu nedenle kendine has özellikleri vardır.

Bu projeden önce orta ölçekli işletmeler kurdum (1000-1500 çalışan, 50-150 iş). Net bir metodoloji geliştirerek onları nasıl yapacağımızı zaten öğrendik (şimdi ekibim ve benim bir projeyi ticari işletmeye aktarmak için ortalama süremiz var, karmaşıklığına bağlı olarak 7-10 ay.)

Ancak, ortaya çıktığı gibi, 2,5 binden fazla çalışanla, teknolojinin revizyonunu gerektiren projenin karmaşıklığında niteliksel bir sıçrama var.

Yani, sırayla. 2015 yılı sonunda fabrikaya geldik. Başlangıçta, görev düzenlenmiş muhasebeyi başlatmaktı. İşlevsel modelleme sırasında, Müşteri yönetimi (baş muhasebecinin dosyalanmasıyla birlikte), birincil belgeleri “sahaya” girme işlevini devretme kararı aldı. Proje sınırları, merkezi depolar, depolar, mağaza muhasebesi, sözleşme yönetimi ve BDDS'yi içerecek şekilde revize edilmiştir. Düzenlenmiş muhasebe uygulamasının zamanlaması 2017'ye kaydırıldı ve 2016'da "birincil" otomatikleştirildi.

Fonksiyonel blokların aşamalı olarak pilot operasyona (bundan sonra "OPE" olarak anılacaktır) başlatılacağı kararı, bize çok fazla baş ağrısı getirse de, küresel olarak doğru olduğu ortaya çıktı: hepsini bir kerede başlatırsak, boğulurduk. bir sorunlar barajında, ah ki bunu daha sonra tartışacağım.

Dürüst olmak gerekirse, asıl zorluğun kullanıcılar tarafında sabotaj olacağını düşündüm. 1C'nin tanıtılmasından önce, hiçbir yere merkezi olarak hiçbir şey girmediler: biri Excel'de çalıştı, biri kendi kendine yazılan sistemlerde. İş akışının temeli, daha sonra operatörlerin muhasebe programına girmeleri için otomatik kontrol sistemine devredilen "evrak işleri" idi. Burada, Müşteri tarafındaki proje ekibi konuya yetkin bir şekilde yaklaştı - bir dizi sipariş verildi, imzalandı Genel Müdür hangi sorunu kapattı. Siparişler olağan tarzda "sistem işletmemizde başlatılıyor ..." şeklinde düzenlenmemiştir, ancak oldukça spesifiktir "şu ve böyle bir tarihten itibaren muhasebe departmanı yalnızca depolardan 1C'den yazılan belgeleri kabul eder." Olası bir yanlış anlamayı ortadan kaldırmak için, belgelerin barkodunu hemen açtık ve muhasebe departmanına tarayıcılar dağıttık (aslında Word'deki kişiler tarafından “çizilmiş” belgeleri gönderme girişimleri vardı).

Lansmanın sırası şu şekilde belirlendi: merkezi depolar, sözleşmeler, BDDS, atölye depoları, atölye muhasebesi ve sonuç olarak - ayrıca ayrı işlevsel alanlara bölünmüş olan zaten düzenlenmiş muhasebe.

İlk (aslında olmasa da) sorun oldukça tahmin edilebilirdi - veri miktarıydı. Ancak, başlangıçta ölçeğini hafife aldım. Örneğin, artıkları "düşük fiyata" yüklemek (herhangi bir işlem yapmadan) yaklaşık 4 gün sürer. Ve sonuçlar aniden tutarsızlıklar ortaya çıkarırsa, o zaman dört gün daha ve sonra bir tane daha ... Yani, bu çalışma aşaması, müşteri ile birlikte planlama sırasında kelimenin tam anlamıyla her gün çok dikkatli bir şekilde çalışılmalıdır. Örneğin, burada olağan yoldan gittik: yalnızca referans kitaplarını indirdik ve kullanıcıların "birincil" olanı yenmesini sağladık, böylece kalanların indirilmesinin bitiminden sonra her şey yapıldı, kontrol edildi ve kaydedildi. Sonuç olarak, fiziki olarak muhasebeyi indirip ay sonuna kadar maliyetin geri ödemesini hesaplamak için zamanımız olmadı ve yönetim raporlarını sunmak için maliyetleri eski sistemden elle aktarmak zorunda kaldık, ve daha sonra farklı muhasebe yöntemleri nedeniyle bunları ayarlayın.

Ayrıca, müşteri normal formda gerekli verilerin çoğuna sahip değildir ve buna bağlı olarak, onlardan önceden hazırlanmalarını istemek gerekir: örneğin, açık siparişlerin bir listesini üç (!!! ) ay. Görünüşe göre, daha kolay ne olabilir? Firma neyi, kime, ne zaman üretip sevk etmesi gerektiği konusunda bilgi sahibi olmalıdır. Ancak, ortaya çıktığı gibi, resmi bir biçimde, yalnızca sipariş numaralarına (Devlet Savunma Emri için ayrı muhasebe düzenleme gerekliliği) ve ürünün adı, miktarı, zamanlaması vb. Excel'de bir yerde veya kağıt sözleşmelerde saklandı.

Sonraki projelerde, biz ve müşteriler, projenin ilk aşaması olan fonksiyonel modellemeden hemen sonra veri aktarımı için hazırlanmaya başlarız.

ve ölçek kendi emeğiyle Tasarım yaparken her zaman aklınızda bulundurmalısınız: örneğin, başlangıçta, karşılıklı yerleşimleri tasarlarken, müşteri borcu sözleşmelerin aşamalarına göre bölmek istedi, ancak bizimle yapılan hazırlık çalışmalarının işçilik maliyetlerini analiz ettikten sonra, bundan vazgeçti. fikir.

Ayrıca, çok sayıda "birincil" hata maliyetini artırır: aniden bazı gereksinimleri doldurmayı unuttuysanız veya yanlış doldurmayı öğrettiyseniz (ki bu ne yazık ki olur), o zaman "hızlı bir şekilde geçemezsiniz" her şey senin ellerinle." En iyi durumda, gelecek aydan itibaren doğru verileri alacaksınız. Yani, bu tür projelerde yalnızca çok deneyimli bir proje ekibi kullanılabilir - yeni gelenlerin "sürüleri" düzeltemeyebilir.

Ek olarak, böyle bir ölçek deneysel endüstriyel operasyon için özel gereksinimler getirir: genellikle basit bölümler için (örneğin, merkezi depolar) bir buçuk ila iki aylık destek koydum, bu bloğu çözmek için oldukça yeterli. Ve burada bazı mağaza sahipleri programdaki verileri ancak 3 ay sonra ciddi şekilde analiz etmeye başladılar. Yani, ondan önce, sisteme belge girmeyi öğrendiler. Diğer bölümlerin başlatılması sırasında, kapalı işlevsel blokları desteklemek için kaynakları yönlendirmenin gerekli olduğu ortaya çıktı. İnsanları ve bütçeyi planlarken bu dikkate alınmalıdır.

Programın kullanıcılarının bilgilendirilmesi organizasyonundan da bahsetmeliyiz. Zorunlu mesajların görüntülenmesi için modülleri konfigürasyona önceden entegre etmek gerekir: 350 kişiyi arayıp talimatın güncellendiğini veya maliyet fiyatı hesaplamasının bugün başlayacağını söylemek gerçekçi değildir. Burada BSP'den (standart alt sistemler kitaplığı) bir yama bize büyük ölçüde yardımcı oldu.

Yukarıda açıklanan ölçek sorununa ek olarak, projenin ikinci ve ana sorunu, işletmede bazı muhasebe alanlarının çalışmasına tamamen sahip olan hiç kimsenin olmamasıydı. İlk başta bunların yalnızca bu bitkinin özellikleri olduğunu düşündüm, ancak şimdi büyük kuruluşlar için böyle bir durumun norm olduğunu anlıyorum. Kendi "parçalarını" yöneten birkaç kilit kullanıcı var ve bunların nasıl çalıştığına dair kendi fikrine sahip bir departman başkanı var. Ve aralarında bir uçurum var.

Daha önce nasıl çalıştım: Her süreç için Sahibi belirlendi, onun gereksinimlerini kim oluşturdu, bir çalışma şeması geliştirdik, kilit kullanıcılarla birlikte yürüdük ve ardından sahibinden onayladı. Tipik olarak, bu teknik operasyonların %80'ini kapsar ve kalan 20 tanesi pilot üretim aşamasında "ayarlanır". Biz de burada bu yolu izledik. Gerçek ve bölüm başkanları arasındaki fark neredeyse hemen belliydi. Ama patronlar "olamaz!" dediler. şirket kültürü aldırış etmediler. Sonuç olarak, onaylanan çalışma planı, çok fazla zaman alan işlemlerin bir bölümünü, çok sayıda gereksiz kontrolü içeriyordu ve "kesinlikle sahip olmadıkları" belirli bir miktarda şey içermiyordu. Tüm bunların pilot operasyon sırasında yeniden yapılması gerekiyordu. Halihazırda uygulanan ve teslim edilen iyileştirmeler sonunda kökten yeniden yazıldı ve OPE'nin kendisi sürekli programcıların varlığını gerektirdi.

Düzinelerce insan arasındaki her süreç hakkında bilginin “bulaşması” sorununa, benzer işlevlere sahip kendi özelliklerine ve kendi muhasebelerine sahip çok sayıda görünüşte benzer departman (sadece yaklaşık 30 merkezi depoları vardır) eklendi. özellikler - bu, aynı işlemlerin bile birkaç yolla gerçekleştirilebileceği anlamına gelir. Projenin başlangıcında duyurulan "süreçlerin birleştirilmesi" sloganı, ilk muharebe lansmanı sırasında öldü.

Sonuçlara göre, projeyi analiz ederken, açıklanan süreçler ve gerçeklik arasında önemli bir tutarsızlık riskini özellikle azaltmanın bir yolunu görmüyorum: şemayı her departmanla ve daha sonra kendileriyle ayrıntılı olarak çalışmak için. Liderler, Fonksiyonel Modelleme bütçesinin 5-7 kat artırılması gerekecek ve müşterilerin bu aşamanın değerini anlaması ve sadece bir "kağıt parçası" için proje maliyetinin %25'ini ödemesi genellikle zor. Başka bir projede denediğim, sistemin birkaç bölüm üzerinde test çalıştırması hakkında bir düşünce vardı, ancak kendini tam olarak haklı çıkarmadı.

Şu anda, benzer ölçekteki projelerde, yinelemeli iyileştirmeye katlanmak zorunda kalacağımı kendim belirledim - sadece doğru şekilde düzenleyin ve tüm pilot operasyon için programcıların çalışmalarını derhal değerlendirmeye dahil edin ve artırın. kullanıcı desteği süresi en az iki kez.

Üçüncü proje sorunu ilk ikisinden kaynaklanmaktadır: çok sayıda kullanıcı (bunun için çok sayıda danışmana ihtiyaç vardır) ve PEA aşamasında verilen çok sayıda tasarım kararı. Ve ERP'de bir ve aynı görev çözülebildiğinden Farklı yollar, daha sonra farklı danışmanlar kullanır farklı yöntemler ve sonuç olarak sistem "uzaklaşmaya" başlar. Burada "günün sonundaki toplantılar" yardımcı olmaz, çünkü çeşitli konuların hacmi nedeniyle danışmanlar akşama kadar pek çok şeyi unuturlar.

Gelecekte, bu tür projelere, şimdilik kullanıcılardan izole edilecek ve tüm tasarım kararlarının onun aracılığıyla verileceği ayrı bir mimarı tanıtacağım. Ayrıca kullanıcı talimatlarını her gün güncelleyecektir (çok sayıda kullanıcı için gerçekten gereklidir).

Sonuç ne? Tümseklere, gözyaşlarına ve gri saçlara rağmen müşterinin yönetim birimi başlatıldı. Şimdi düzenlenmiş olana geçtik. Umarım ilk aşamalarda edinilen deneyim, onu başlatmada yardımcı olur.

(%32). Seçim yapıldıktan sonra, sistemlerin popülaritesi karşılaştırılabilir kalır: sırasıyla %21, %18 ve %14 (yani bu platformların uygulama için seçildiği durumlar).

Genel olarak, ERP projelerinin zamanlaması için acı verici sorunlardan biri olmaya devam etmektedir. bu pazar: sadece %36'sı önceden belirlenmiş zaman dilimlerini karşılayabildiklerini belirtti ve %62'si - bunların önemli ölçüde ötesine geçti ve sadece %3'ü uygulama projelerini planlanandan daha erken tamamlayabildi. Hepsinden önemlisi, Microsoft Dynamics çözümlerine dayalı projeler zaman aşımına uğradı, ortalama olarak 12,5 ay sürdü, bu da planlanandan 4 ay (%47) daha fazla.

Oracle projelerinin süresi ortalama 22,5 ay, ortalama 17,5 aya karşılık %29 aşım oldu. SAP ERP'ye gelince, bu tür uygulamaların ortalama süresi, başlangıçta planlanan 16 aya kıyasla minimum %16 veya 2,5 ay gecikme ile 18,5 aydı.

ERP projelerinin ortalama süresi: planlı ve gerçek

Panorama Danışmanlık, 2014

ERP projelerindeki gecikmelerin ana nedenleri

№	Neden	2011	2012	2013
1	Projenin kapsamı genişletildi	17%	29%	29%
2	organizasyonel konular	14%	20%	29%
3	Veri sorunları	14%	17%	29%
4	Gerçekçi olmayan zamanlama	8%	11%	25%
5	Kaynak kısıtlamaları	13%	17%	21%
6	Öğrenme sorunları	10%	15%	17%
7	Platform işleviyle ilgili sorunlar	8%	4%	13%
8	Diğer teknik sorunlar	7%	14%	8%
9	Projede çelişen öncelikler	10%	12%	8%

Panorama Danışmanlık, 2014

ERP projelerinin zaman aşımına uğramasının ana nedenleri, yukarıdaki tablodan da anlaşılacağı gibi, planlanan proje hacminin genişlemesinin yanı sıra organizasyonel sorunlar, veri sorunlarıdır - tüm bunlar, başarıyla geçen projelerin üçte birinde gerçekleşir. gecikme.

Belki de iyi haber, 2012'den 2013'e kadar olan dönemde analistler, ERP projelerinin ortalama geri ödeme süresinin 2,4 yıldan ortalama 1,7 yıla düştüğünü kaydetti. Bununla birlikte, yatırımlarını hiçbir şekilde telafi edemeyen kuruluş sayısı otomatik sistemler kurumsal kaynak yönetimi %31'den %38'e yükseldi. En uzun geri ödeme süresi Microsoft Dynamics çözümleri için (24 ay) bulundu, SAP için 23 ay, Oracle için - 16 ay.

Ve bir önemli nokta daha: 2013 yılı sonunda planlanan yıla göre projelerin fiili bütçesi tekrar arttı. Bu durumda en pahalı uygulama SAP ERP'nin uygulanmasıdır, ortalama olarak böyle bir projenin bütçesi 2,55 milyon dolar, ardından Oracle - 2,25 milyon dolar, Microsoft Dynamics - 1,8 milyon dolar İşletmelerin yıllık cirolarından, Tier I sistemlerinin uygulanması %2-4'tür, ancak Tier II ve III'e dayalı ERP projelerinin maliyetinin, bunları uygulama için seçen şirketlerin cirosundaki payı önemli ölçüde daha yüksek olabilir.

Şirketlerin yalnızca %66'sı hedeflerin en az %50'sine ulaşabildi

ERP projelerinde genel olarak (belirli satıcılardan bağımsız olarak), 2013 yılı sonu itibarıyla şirketlerin sadece %66'sı uygulamalar çerçevesinde amaçlanan hedeflerin en az %50'sine ulaşabilmiştir. Vakaların %72'sinde, proje ortalama 16.3 aylık bir süre ile önceden planlanandan daha uzun sürdü. Vakaların %54'ünde bütçe aşımları kaydedildi, ortalama proje bütçesi 2,8 milyon dolardı.

2012-2013 ERP projelerinin ortalama göstergeleri

Panorama Danışmanlığı, 2014

%63'ü uygulanan ERP projelerini başarılı buldu, %21'i uygulamanın etkisini değerlendirmeyi zor buldu, %16'sı uygulamanın başarısızlıkla sonuçlandığını kabul etti.

Rus gerçekleri

The Standish Group'un raporlarından biri, ABD pazarındaki yazılım endüstrisinin durumuna ilişkin iç karartıcı istatistiklere atıfta bulunuyor:

projelerin sadece %32'si başarıyla tamamlandı,
%44'ü çeşitli zorluklar yaşadı (bütçenin aşılması, teslim tarihlerinin dışına çıkılması vb.),
Projelerin %24'ü başarısız oldu.

First BIT şirketinin uzmanları, Rusya pazarındaki durumun pek de iyi olmadığını belirtiyor.

ERP projelerinin "başarısı" istatistikleri 1C tarafından paylaşıldı. 2010-2013'te uygulanan 555 tamamlanmış 1C ERP çözümlerinin bir çalışmasına göre:

Projelerin %66'sı son teslim tarihini karşıladı veya son teslim tarihinden %10'a kadar hafif bir sapmaya sahip,
Projelerin %24'ü son teslim tarihinden %11-30 oranında sapmış ve
projelerin sadece %10'u son teslim tarihinden %30'dan fazla sapmıştır.

Proje bütçelerine gelince, müşteriler için durum daha da cesaret verici:

Projelerin %78'i bütçe dahilinde veya bütçeyi %10'dan fazla aşmamış,
Projelerin %19'u bütçeyi %11-30 aşıyor ve
projelerin sadece %3'ü bütçeyi %30'dan fazla aşıyor.

ERP projelerinin başarısız olmasının ana nedenleri arasında, Rus entegratörleri şunları tespit ediyor:

Yüksek beklentiler

Microsoft Dynamics AX Tops Consulting'in (Tops Consulting) İş Geliştirme Direktörü Efim Fish, istenen sonucun, müşterinin elde etmek istediği şeyin net bir şekilde anlaşılmamasının büyük bir sorun olduğunu söylüyor. Bu durumda, iyi bilinen bir deyimle, proje tamamlanamaz, ancak sonlandırılabilir. Müşteriler genellikle arzularını ve gerekli maliyetleri yanlış değerlendirirler. Her iki taraf da projenin hedefleri üzerinde anlaşmalı ve anahtar noktaları Projenin başarılı bir şekilde uygulanması için gerekenler açısından.

“ERP uygulama sürecinin iki taraflı, özenli bir süreç olduğunu anlamak önemlidir. Burada uyku ilacı alamazsınız ve uyandığınızda sistemin harici bir tedarikçi tarafından uygulandığını ve çalıştığını görürsünüz, tüm personel her türlü öneriyi memnuniyetle kabul eder ve şirkete getirilen tüm değişiklikleri memnuniyetle kabul eder. yeni sistem... Ve her durumda tanıtıldılar, çünkü hiçbir değişiklik olmadı, ancak hiçbir şey olmadıysa. Ve ERP söz konusu olduğunda açıkça hedef bu değil ”dedi.

İnsan faktörü, yönetim desteği eksikliği

Bir ERP sisteminin uygulanması sadece bir BT bileşeni değildir, aynı zamanda bir şirketteki iş süreçlerinde bir değişikliktir, çünkü uygulama sırasında birçok süreç iyileştirilir, sorumluluk alanları yeniden dağıtılır. Sonuçlara ulaşmak için müşteriler bu değişikliklere hazırlıklı olmalı ve bunları desteklemelidir. İnsan kaynaklarının en değerli kaynaklardan biri olduğu göz önüne alındığında, sistemin iyi bir şekilde kabul edilmesinin yanı sıra kuruluş genelinde kişisel bağlılık ve katılım da çok önemlidir. Destek eksikliği üst yönetim 1C'ye göre, proje süresi boyunca şirketler başarısızlığın ana nedenlerinden biridir.

Örneğin 1C'de proje teslim tarihlerini karşılamak için "Hızlı Sonuç Teknolojisi" (TBR) adlı bir teknik kullanırlar. 1C'den ERP çözümlerinin uygulanmasının zamanlamasının istatistiklerine göre (2010-2013 için 1420 proje), ortalama olarak, ilk alt sistemin deneme işletimine alınmasından yaklaşık 3 ay önce ve 6 ila 10 ay arasında sürer. son alt sistem ticari işletmeye alınır. ... projenin ölçeğine bağlı olarak. Özellikle büyük işletmeler uygulanması 1-2 yıl sürebilir.

Aleksey Petrushov'un belirttiği gibi, projenin verimsizliğinin ana göstergelerinden biri de teslim tarihlerinin gecikmesi. Bu sorunun temel nedeni kesinlikle insan faktörü ekledi.

* Uygulamadan sonra ödeme. Başarılı uygulama.

eBusinessDrive'dan Sabina Borshchevskaya, “Başarısız uygulamalarda“ suçlu ”(her iki taraf da her zaman suçludur) aramıyoruz, müşteriden sadece sonuçtan memnun olduğunda para alıyoruz” diyor. ERP uygulamasını pratik olarak kendi masraflarımızla gerçekleştiriyoruz ve müşteri sonuçtan memnun değilse ödeme yapmıyor. Şu anda, Rusya'daki ve hatta dünyadaki bu tür koşullar, ERP sistemlerinin uygulanması için pazar, İsviçre dağlarındaki hava kadar temiz. Gel.

Yetersiz veya fazla harcama bütçesi

Fiyatların yayılması Rus pazarı ERP sistemleri önemlidir: ERP sisteminin karmaşık bir ürün olduğu gerçeğiyle belirlenir. son sonuç bir proje, ERP sisteminin işlevselliğinden müşterinin organizasyonundaki yönetim sistemine kadar birçok faktörden etkilenir.

Her şeyden önce, projenin gerçek maliyetini hesaplamak için, işletmenin mevcut iş görevlerini öğrenerek açık bir anket yapmak ve hedef durum üzerinde anlaşmak gerekir. organizasyon sistemi Sonuç olarak işletmenin yönetimi, diyor Alexey Petrushov. Tahminlerine göre, Rusya'da ERP uygulaması için ortalama bütçe 1 milyon ila on milyon ruble arasında değişiyor.