Adım Adım ERP

Yazılım Teknolojisi tüm dünyada olduğu gibi ülkemizde de geleceği olan bir sektördür. Firma olarak tüm yatırımlarımız bunun üzerine kurduk. Projeyi satın aldığınız andan itibaren yazılımızın teknolojisi değişmeye başlamıştır. Bizim değişimleri göz ardı etmemiz ürünümüzün teknolojisinin de eskimesi anlamına gelir ki bu da firmamızın ölmesidir. Şirketimiz AR-GE çalışmalarına gereken önemi vererek bütçesinin önemli bir kısmını kişisel gelişime ve yazılım teknolojilerine harcamaktadır. Amacımız daha iyi olmak, güncel teknolojileri verimli kullanmak ve sizlerle paylaşmak.

Projeye ön ayak olan kişiler başta olmak üzere sorumluluğu ( bu sorumluluk önemlidir. Görüşmeler ve seçime kadar sürecek uzun bir aşamayı kapsamaktadır.) alabilecek kişiler seçilir. İşletme yapısını bilen tecrübeli kişilerin seçilmesi önerilir.

Proje ekibinin görev tanımlarından bir tanesidir. Öncelikle şirket ihtiyaçlarının tespit edilmesi gerekir. ERP denilince tüm modüller akla gelmektedir. (muhasebe, çek-senet, finansman, stok, kalite kontrol, satış, satın alma, MRP, üretim, personel-bordro, maliyet, CRM, e-business, işletme bakım, dış ticaret gibi) İhtiyaçlar çok iyi tespit edilmelidir. Öncelik sırası oluşturulabilir. Ayrıca tüm modüllerin devreye alınması zorunlu değildir. Bazı modüller tamamlayıcı pozisyonundadır. (CRM, işletme Bakım, dış ticaret gibi) Bu modüller daha sonra da uygulamaya alınabilir. Bu seçim hem finans açısından hem de yapılacak işlerin genel büyüklüğü açısından rahatlama getirecektir. Mevcut durumda kullanılan programlardan da faydalanılabilir. Özellikle şirket bünyesine uygun yazılmış ve uzun süredir verimli olarak kullanılan programların proje ile entegrasyonu düşünebilir. Bu modül hiçbir zaman muhasebe modülü olmamalıdır. ERP fiyatlandırmasında muhasebe modülü diğer modüllere göre daha az maliyet tutmaktadır. Tüm modüllerin muhasebe ile entegrasyonun olduğu düşünülürse projenin eski muhasebe ile entegrasyonunu yapılmasının getireceği ek maliyet çok daha fazla olacaktır.

Şirket içinde kullanılacak modüllere karar verdikten sonra her modül için departmanların yaptığı işler tespit edilir. Şirkete özel durumlar kesinlikle atlanmamalıdır. Örneğin stok yapısı, üretimdeki özellikler gibi. Bu durumlar tek tek detaylı olarak yazılı hale getirilmelidir. Bu aşamada departman sorumlularından yardım alınabilir. Departmanlarla ilgili tüm görüşmeler ve istekler yazılı yapılması önerilir. Bu aşamada atlanılan özellik ileride sıkıntı çıkartabilir. İstekler toplanıldığında bir anlamda şartname oluşmuş gibidir. Bu aşamada teknik alt yapıya girmemek firmaların teknik çözümlerini dinledikten sonra karar vermeyi daha kolay hale getirecektir. Departmanlarla bu görüşmelerin proje sorumlusuna iş akışını kabaca gözden geçirme, bilmediği konularla karşılaşması ve neler yapıldığı noktalarında faydası da olacaktır.

Proje ekibi ne istediğinden bu aşamada emin durumdadır. Yazılım firmalarıyla görüşmede sorulacak sorulara verilecek net cevapları vardır. Firma bulmada en etkin yol google gibi arama motorlarıdır. ERP, stok takip programı, MRP gibi anahtar kelimeler yazıldığında yazılım firmaları listelenir. Bazı anahtar kelimeler bu listelerin sayfalarca çıkmasına neden olabilir. Bunun nedeni de bazı temel modüllerin piyasada pek çok yazılım evi tarafından yazılmış olasıdır. (muhasebe, stok, fatura gibi) İhtiyaç sadece bu modüller ise fiyatlar hem düşük hem seçenek çok fazladır. Fakat ERP yi oluşturan entegrasyon ve kapsam bu yazılımlarda bulunmamaktadır. Yazılım firmalarının internet siteleri, yaptıkları işler ve referansları ilk aşamada incelenip bir liste çıkartılır. Ön görüşme için davet edilir. Bu görüşmelerde fiyat genellikle telaffuz edilmez. Kaba maliyet hakkında fikir alınabilir. Bu iki taraf için de faydalı olacaktır. Firmanın bu iş için ayırdığı bütçe yazılım fiyatının çok altında ise daha ilk aşamada eleme gerçekleşmiş olur. Özellikle bazı yabancı ERP projeleri fiyat olarak çok yüksek rakamlarla satılmaktadır. Proje fiyatı proje kalitesini belirleyen bir unsur olarak görülmemelidir. Yine de ortalamanın çok altında veya üstünde fiyatlar için de temkinli davranılmalıdır.

Yazılım firmaları pazarlama veya analiz özelliğine sahip bir vaya birden fazla kişi ile toplantıya gelirler. Bu aşamada firmanın proje sorumluları gelen kişilerden yazılım firması ve ürünleri hakkında ön bilgi sahibi olur. Daha önceden hazırlanmış ihtiyaç olan modüller ve detay talepler karşı tarafa sunulur. Mümkünse örnek çıktılar verilir. Şirket özelini paylaşmayan bu çıktıların verilmesinde herhangi bir sakınca yoktur. (yazılım firmalarının pek çok şirketle çalıştığını, onların çok özel bilgilerini paylaştığını ve bu sırların kapıdan çıkıldığı anda gömüldüğünü unutmayalım.) İstekler anlatıldıktan sonra karşı taraftan çözümlerinin ne kadarının karşıladığı sorulur. İlk izlenimlerin de önemli olduğu bu görüşmelerin bir değerlendirme formunda toplanması çok faydalı olacaktır. Bir süre sonra görüşme ve konuşulanların karıştırılma olasılığı vardır.

Yazılım şirketi çözüme bu aşamada talip olursa sunum (sunum) yapılması istenir. Yazılım şirketleri genel bir sunumu tercih edebilir. Genel sunumdan kasıt, tüm müşterilere gösterilebilecek kayıt bilgisiyle yapılan sunumdur. ERP sunumları yapısı itibariyla hem sunan için hem dinleyen için kolay bir sunum değildir. Laiki ile yapılan sunum 3-4 saatten kısa sürmez. Genel verilerle yapılan sunumlarda dinleyen açısından iş daha da zorlaşır. Örneğin boya sektörü ile ilgili bir firmada tüm örnekleri (stok olsun, üretim prosesleri olsun ) plastik sektörünün yapısına göre yapılırsa proje zor anlaşılacağı gibi dinleyen de oyunu büyük bir ihtimalle olumsuz olarak kullanacaktır. Yazılım evinden firmanın kendi stok yapısı (mamül, hammadde) ve satış, üretim proseslerine özgü sunum yapması talep edilebilir. Sunum kayıtlarının hazırlanması kolay bir işlem değildir. Firma yapısına uygun parametrelerin ayarlanması, proseslerin düzenlenmesi küçük çaplı kurulum sürecine denktir. Kabul edilirse bu yazılım evine artı puan olarak eklenmelidir.

Sunum için yazılım firmalarına randevular kısa gün aralıklarıyla verilmemelidir. Hem karıştırılmasına hem de dinleyici açısından heyecanın kaybolmasına neden olabilir. Sunuma katılacakların önceden belirlenmesi, sunum saatinin en az iki gün öncesinden kendilerine bildirilmesi faydalıdır. Tabii ki tüm bildirimler yazılı olmalıdır. Aksi durumda son dakika sürprizlerine hazırlıklı olmalısınız. ERP sunumu pek çok modülü kapsayacağından bir zorluk ta süreç boyunca ilgiyi sağlamaktır. Burada sunumu yapan kişi veya kişilerin yeteneği de önemlidir. Bir yöntem de yazılım firmasından detaylı sunum planı ve yaklaşık süreçlerini önceden istemektir. Böylece konusu geldikçe ilgili kişiyi sunuma davet ederek performansı üst noktada tutabiliriz. Önceden hazırlanmış değerlendirme formları sunuma katılanlar tarafından doldurulması zorunlu tutulursa dinlemedeki dikkat ve katılımı arttırabiliriz.

Genel tanıtım amaçlı sunum detaylı proje arayışlarında başarılı olma olasılığı azdır. Sunum sırasında proje anlatılırken dinleyenler sürekli olarak kendi güncel işleyişleri ile projeyi karşılaştıracak anlatılanlardan kendine uygun çözümler bulmak isteyecektir. Sunum öncesi firmaya sadece pazarlama amaçlı ziyaret yapılmış ise sunumu yapanın bu sorulara cevap vermesi ya çok zor olacak ya da veremeyecektir. Anlık ürettiği yama çözümler de daha sunum esnasında projeden soğumaya neden olabilecektir. Şirketin yaptığı iş, genel ve çok zorlayan özel sıkıntıları önceden analiz edilmelidir. Sunumda bu noktalara değinilmeli veya bu konuyla ilgili çözümler müşavirlik bilgisiyle harmanlanıp ifade edilmelidir.

Sunum, yazılım firması için üniversite sınavı gibidir. Birkaç saatlik sürede tüm proje özelliklerini anlaşılabilir şekilde anlatmalıdır. Şirket yapısını, üretim proseslerini bilmeli gelebilecek sorulara hazır olmalıdır. İlgiyi üst sınırda tutmak için sunumu yapan ek caba sarf etmelidir. Sunumu yapan tüm konulara detaylı vakıf değilse gelecek detaylı sorulara mutlaka yanında cevap verebilecek sorumlu veya sorumlular olmalıdır. Bu sunum, yazılım firmasının yapabileceklerinin sınırının izlendiği, verdiği cevaplarla konuya ne oranda vakıf olduğu ve hatta yaklaşımlarıyla insani ilişkileri hakkında ciddi fikir sahibi olmamızı sağlar. ERP çalışmaları uzun süreçli çalışmalardır. Bu nedenle proje kadar ekip de önemlidir. Ekip bilgi bakımından öncelikle yeterli olmalıdır. Başarılı insan ilişkileri de projenin devamı için önemlidir. Proje ekibinin çalışması şirket kültürünün bir yansımasıdır. Şirket kültürü sağlam ve yapıcı ise ekip içinde problem çıkmayacak, çıksa bile kısa sürede halledilecektir.

Sunum sonucunda her şey bire-bir örtüşmeyebilir. Projenin isteklere ne oranda cevap verdiği önemlidir. Peki, uymayan kısımlar ne olacaktır. Burada yazılım firmasının genel duruşu çok önemlidir. Israrla işleyişi projeye uydurmaya mı çalışıyor, yoksa uyumsuzlukları kabul mü ediyor? Proje fiyatlandırmayı bir bütün olarak mı bakıyor? Proje farklılıklarını fiyatlandırmayı mı düşünüyor? Her eksiklik veya farklılık sunum sonunda tespit edilebildi mi? Bu soruların hepsine net cevaplar alınmalıdır. Netleşmeyen sadece ‘’Her eksiklik veya farklılık sunum sonunda tespit edilebildi mi?’’ sorusudur. Buna cevap vermek gerçekten zordur. Ne kadar ön çalışma yapılırsa yapılsın tüm detayları tespit etmek imkansızdır. Burada öncelikle yazılım firmasının sunacağı önerilerin dinlenmesi faydalı olacaktır. Ön çalışma esnasında ve sunum sonunda projeye yapılacak ek düzenlemelerin boyutunu yazılım firması tecrübesiyle büyük oranda tespit etmesi beklenir. Daha evvel de bahsedildiği gibi özel durumların muhakkak paylaşılması gerekmektedir. Teklif sonrası hatırlanan özel işlemler her iki taraf için sıkıntı yaratabilir. Sunum sonuç değerlendirme formunun katılan herkes tarafından doldurulması istenir. Proje sorumlusu tarafından toplu olarak yapılan kısa değerlendirme toplantısı faydalı olacaktır. Yazılım firmasından fiyat teklifi istenerek bir sonraki aşamaya geçilir.

Yazılım firmaları lisanlama teklifini çeşitli kriterlere göre verebilirler. Kullanıcı bazlı, proje modülü bazlı, grup kullanıcı bazlı, kullanacak şirket sayısı veya kullanıcı bağımsız tüm proje için olabilir. Bunun tek bir standardı yoktur. Eğitim hizmetlerini ayrıca fiyatlandıran firmalar da vardır. Teklif öncesinde fiyat verebilmek için bu detay bilgiler sorulabilir. Tekliflerin sağlıklı değerlendirilebilmesi için mevcut kullanıcı sayısı ve ileriki süreçlerde eklenebilecek kullanıcı sayısı, şirket sayısı, eğitim saatlerinin yeterliliği, ek eğitim alınırsa bunun maliyeti ve diğer tüm parametreler dikkatlice yorumlanmalıdır. Paket fiyat teklifleri her zaman avantajlıdır. İlerleyen süreçte olası sürprizlere kapalıdır. Teklif içeriğinde sadece fiyat değil proje farklılıklarına değinilmeli bu düzenlemeler madde madde belirtilmelidir. Tam detaylı olmasa da Proje işleyiş akışından bahsedilmeli tahmini iş süreçlerine değinilmelidir.

Sunumlar sonucunda elde birçok veri oluşmuştur. Her sunum sonunda katılanların değerlendirmeleri, sunum sonu genel kanaat değerlendirmesi, proje yeterliliği, ekip firma yeterliliği gibi. En son olarak fiyat bilgisi de gelince elemeler kolaylaşacaktır. Bu eleme sonucunda 2-3 firmaya düşülebilir. Fiyat yüksekliği nedeniyle elenen firmalar aklı meşgul etmemelidir. ERP projelerinde tek başına fiyatı yüksek demek kalitenin bir yansıması değildir. İkinci tur görüşmeler firmalarla tekrar bir sunum daha veya tam anlaşılamayan modüllerin küçük sunumu şeklinde olabileceği gibi detayları konuşma şeklinde de olabilir. Bu görüşmeler sonrası ikinci bir eleme daha yapılabilir.

Referansların incelenmesi teklif değerlendirmenin bir sonraki boyutudur. Firma geçmişi önemlidir. Baştan beri söylendiği gibi ERP uzun soluklu bir çalışmadır. Birkaç senelik geçmişi olan yazılım firmalarının bu alanda işleri zordur. Kendi sektörünüz veya başka sektörlerden birkaç firma ile bire bir görüşebilir, ziyaret edebilirsiniz. Bu ziyaret sırasında yazılım firması hakkında yapabilecekleri ve en önemlisi sorunlara yaklaşımları hakkında bilgi alabilirsiniz. Hiçbir zaman unutulmamalı ki tam memnuniyet sağlamak çok zordur. Kişiler değiştiğinde bile bir önceki kullanıcı memnuniyeti bir sonraki için geçerli olmayabilir. Görüşmelerde ana konular sorgulanmalı, süreçlerin nasıl geçtiği neler yapıldığı, yazılım firmasının verdiği terminlere uyup uymadığı, başarısız noktalar varsa (karşı taraf bunlara değinmeyi pek istemeyecektir) nedenini öğrenebilirsiniz.

Projenin belki de en önemli parametresidir. Standart bir ürün, hizmet olmadığı için birbirlerine yakın veya uzak farlılıkta fiyat teklifleri olabilmektedir. Yabancı yazılım firmaları dünya standartlarındaki fiyatlarını ne kadar indirse de Türkiye standartlarına göre yüksek fiyatta kalmaktadır. Fiyatları yüksek bulduğunuz ya da ürünü beğendiğiniz için elenmesini istemediğiniz projeler için fiyat indirimi isteyebilirsiniz. Fiyat değerlendirmesini farklı başlıklarla vermiş firmalar için ( proje + eğitim + değişiklik gibi) olası artışları da dikkate alıp değerlendirmek gereklidir. İndirim istendiğinde fiyatlarında yüksek oranda düşüren firmaların güveni bir kez daha incelenmelidir. Yüksek oranda indirimi yapabilen firmanın başlangıç aşamasında yüksek fiyat vermesi ciddi bir fiyat politikası olmadığını, muhtemelen firmanın büyüklüğüne, hatta dış görünüşüne göre fiyat verdiği izlenimini güçlendirir.

Tüm görüşmeler tamamlanıp fiyat ve yorumlar ile birlikte yönetime teklifler sunulur. Bir tanesi onaylanan firmadır. Neden onaylandığı detayları ile tanımlanmalıdır. Seçim çok dikkatli yapılmalıdır. Yıllar sürecek bir çalışma olacağı unutulmamalıdır. Yönetimin isteği ile son anda farklı bir teklif ön plana çıkabilir. Her projenin artı ve eksileri yazılı olarak bulunmalı ve istendiğinde sunulabilmelidir. Karar verildikten sonra doğru mu yanlış mı cevabı en erken bir yıl sonra alınabilir.

Projeyi kullanacak tüm personel ile yazılım firması proje sorumlularının tanışmaları önemli andır. Bu toplantıda projenin kısa bir sunumu ile birlikte neler getireceği konusunda çalışanlar bilgilendirir. Bu toplantıda üst düzey yönetimden birilerinin olması firmanın projeye gösterdiği ciddiyeti ifade edecektir. Yönetim tarafından desteklenen ve sonrasında da izlenen projelerde başarısızlık hemen hemen imkansızdır. Toplantı sırasında çalışanların işlerinin elden alınması veya ben bunları yapabilir miyim şeklinde oluşan soru işaretlerine de cevap verilmelidir. Toplantı sonucunda bu saatten sonra herkesin daha fazla çalışmak zorunda olduğu fakat bunun süreli bir çalışma olacağı ve pek çok yöntemin değişeceği net anlatılmalı ve anlaşılmalıdır.

Yazılım firmasının proje sorumluları firma işleyişini detaylı olarak öğrenmek zorundadırlar. İşleyişin yanında bu işleyişi gerçekleştiren kişileri de tanımak çözüm aşamalarında faydalı olacaktır. Her departman ziyaret edilir. Kişilerle tanışılır. Mevcut görev tanımları ve uygulamada yaptıkları işlerin detayı öğrenilir. Mümkünse bunlarla ilgili dokümanlar toplanır. İş akışının yeni ERP projesinde karşılıkları bulunur. Eksik kalan kısımlar için yazılım ekibi ile görüşülerek yapılabilecekler ve süreçleri tespit edilir. Yeni çözüm önerileri öncelikle proje sorumlusu sonra da departman sorumlusuyla paylaşılır. Tüm görüşmelerin ve alınan kararların yazılı yapılması daha sonra olası bir geri dönüşte izlenme açısından faydası olacaktır. Mevcut yapı incelenirken ERP ye geçen firmaların büyük çoğunluğunda stok kodlama yapısı revize edilir. Bir önceki projede kullanılmayan veya dikkat edilmeyen kodlar ERP projesinde önem taşımaktadır. Hatta takip edilmeyen işletme malzemesi gibi kodların sıfırdan kodlanması söz konusu olabilir. Değişim nedeniyle Hesap planı da revize edilebilir. Eski yapıda takip edilemeyen departman giderleri, araç kişi giderleri için gider yerleri ve detayları belirlenebilir.

Firmanın daha önce kullandığı bir yazılım olabilir. Genellikle muhasebe ağırlıklı yazılımlar ve uzun süredir bunlara girilmiş bilgiler vardır. Eğitim öncesinde bazı ana bilgilerin (hesap planı, cari bilgiler gibi) kopyalanmasında fayda vardır. Özellikle muhasebe departmanı binlerce satırlık hesap planı bilgilerini tekrar girmek istemeyecektir. Bu bilgilerin yeni sistemde hazır olması eğitim aşamasında daha hızlı yol alınmasına yardımcı olacaktır.

Yazılım firmasının eğitim sürecini başlatmadan önce hangi departmanlara eğitimi vereceğini, ne zaman verileceğini önceden belirtmelidir. Firmanın proje sorumlusu da eğitim alacak kişileri tespit edip eğitim zamanlarını bu kişilere bildirir. Teori olarak güzel görünen bu plan maalesef uygulamaya geçişte problem yaşayabilmektedir. Güncel işlerin yapılmak zorunda olması, periyodik veya acil raporların hazırlanması, çalan telefonlarda sorulan sorular eğitimi hep aksatacaktır. Eğitim veren tüm bunlarla moralini ve konsantresini bozmadan mücadele etmelidir. İşin en zor yanlarından biri de proje tam olarak anlaşılmadığından kullanıcılar güncel yaptıklarını yeni sistemde nasıl yapacaklarını sorgulayacaklardır. Bu durum zaman zaman eğitim planından çıkmalara neden olabilir. Fakat eğitim alanı rahatlatacağı için önemli değildir. Sorularına cevap alamadığı zaman o noktada kalıp anlatılan diğer konulara konsantre alamama olasılığı riski alınmamalıdır. Eğitim süreci ilerledikçe hem eğitim veren hem de eğitim alan tarafında işler rahatlayacaktır.

Eğitimler bire bir yapılmalıdır. Birebir ifadesini açarsak eğitim veren projeyi kullanacak kişinin yanına gidip uygulamaları beraber yapmalıdır. Projeksiyon ile duvara yansıtıp çok kişiye konferans şeklinde verilen eğitimler verimsiz olur. Toplum psikolojisi içinde sorulması gereken sorular sorulamaz. Kullanıcının güncel işlediği evraklar öncelikle eğitim veren tarafından girilir. Bu ilk bilgi girişleri sancılıdır. Öncesinde onlarca parametrenin ayarlanması gerekebilir. Temel parametreler mümkün olduğu kadar eğitim öncesi firma proje sorumlusu ile ayarlanmasının kullanıcılar yanında harcanacak süre açısından faydası vardır. Parametre ayarları yüzünden ilk bilgi giriş süreleri uzayabilir. Bu durum kullanıcıların zaman zaman moralini bozabilir. Sanki her belge girişinde bu ayarlamaları yapmak zorundayım düşüncesine kapılabilmektedirler. Kendi başlarına giriş yaptıkları ilk belgeler moral çizgisinin dipten yukarıya doğru ivme kazandığı anlardır. Bu aşamada takıldıkları anda soru sorabilecekleri kişi veya kişilerin olması yukarı çıkan ivme çizgisinin tekrar aşağıya düşmemesine neden olur.

Güncel evrakları birkaç kez sisteme giren kullanıcıların güveni yerine gelmiştir. Fakat gerçek işleyiş bu birkaç evraktan oluşmamaktadır. Birbirinden farklı evrak türleri veya olaylar esnasında da neler yapacaklarının yaşanması gerekmektedir. Bunun için de mevcut işleyişin yeni sistemde de yürütülmesi gerekmektedir. Bunu çözümü de tüm bilgilerin yeni projeye de işlenmesi demektir. Söylemesi kolay olsa da yürütmesi gerçekten zor bir işlemdir. Az sayıda elemanla çok iş yapan firmalarda eleman fazlası hemen hemen yoktur. Tüm bilgilerin ikinci bir sisteme girilmesi normalde mesai dışı çalışmalar ile desteklenirse başarılabilir. En az bir aylık bilginin çift taraflı takip edilmesi uygulama başladığı anda sorunları en aza indirecektir.

Zorlu geçen çift kayıt uygulamasından sonra yeni proje kullanılmaya hazırdır. Geçiş dönemi yeni yıl ile birlikte olması idealdir. Yeni yıla kısa bir süre kaldıysa da bu sürenin geçmesi önerilir. Fakat yıl ortasına rastlayan durumlarda iki seçenek vardır. Birinci seçenek geçmiş dönem bilgilerinin belki sadece muhasebe bağlantıları sisteme girilerek yasal defterlerin çekimi kolaylaştırılabilir. Bu aşamada eski sistemin verileri yeni proje yapısına uygunsa bilgiler transfer edilebilir. İkinci seçenek ise geçiş ayını milat kabul edip ilgili aydan bilgileri sisteme girmektir. Muhasebe olarak geçmiş ayların yasal defterini eski sistemden alarak devam edebiliriz. Tek sakıncası sistemden alınacak analiz raporlarının eksik bilgi sunmasıdır. Paralel uygulama aşamasında dersine iyi çalışmayan kullanıcılar bu aşamada en fazla bağıranlardır. Her yeni konuda neler yapacaklarını sorarlar. Sanki hiç eğitim almamış gibidirler. Eğitim verenler tarafından bu sonuç çok iyi bilindiği halde eğitim esnasında hep uyarıldığı halde maalesef bu kişiler için yapacak bir şey yoktur. Eğitim süreci bu kişiler için bir kez daha yaşanmak zorunda kalınabilir.

Bilgi girişi bir süre bilinçsizce devam eder. Kimse girdiği evrakın nelerle bağlantılı olduğunu hangi raporlarla çapraz kontrol yapması gerektiği ile ilgili caba harcamaz. Burada hem firmanın hem de yazılım firmasının proje sorumluları çok dikkatli olmalıdır. Parametrelerin iyi ayarlanamaması veya bir rapor için gereken girilmesi ek bilgi eksikliğinin geç fark edilmesi tekrar geriye dönülüp aynı bilgilerin tekrar girilmesine neden olur. Bu olabilecek en kötü olaylardandır. Daha işin başında projeye olan güvenin sarsılmasına ve hatta proje sorumlularının yeterliliğinin sınanmasına neden olabilir. Tekrar aynı heyecanı yakalamak gerçekten zordur. Zaten mevcut düzeninin bozulmasından şikayetçi kullanıcılar için kendi konularıyla ilgili olmasa bile bu durumu pek çok ortamda gündeme getirerek kullanmasına neden olacaktır. Bilgi girişleri ilerledikçe bağlantılı raporlar alınmak istenecektir. Raporların alınması ERP sürecinde yol alındığının bir göstergesidir. ERP güç odaklarını yok ederek kendi sistematiğini koyar. Bu durum bazı kişileri rahatsız edecektir. Yıllardır kendi kontrolündeki sistemin herkes tarafından bilinmesi ve hatta kendi işlerini yapabilmesi için başkalarını beklemesi istemediği bir durumdur. Bunlarla yapılan savaş ayrı bir makale konusudur.

ERP ucu görünmeyen bir okyanus gibidir. Proje ne kadar parametrik olursa olsun değişen yapıya ve gelişen düşünce yapısına yenik düşer. Yapının değişmesine paralel olarak projenin de güncellenmesi gerekir. Aksi durumda kullanıcı Excel üzerinde çözümler üretmeye başlayacaktır. Bu geçişin önüne hemen set konmazsa bir süre sonra istense de sunulan çözümler kullanılmayacaktır. Kullanıcı kendi ürettiği çözümün arkasında duracak ve onu kullanmaya devam edecektir. Pek çok yazılım firması müşteriden gelen istekleri sıraya alıp bir sonraki sürümde (o da hepsi değil) cevaplamaktadır. Bazı firmalar da çözüm ortakları vasıtasıyla ‘’dikey çözüm’’ adını verdikleri o modülün çözüm ortağı tarafından yazılmış yeni sürümü olarak sunmaktadırlar. Bu dikey çözümde en önemli problem yazılım firmasının o modül ile yaptığı bu aşamadan sonraki yenilikleri kullanamaz hale gelmektir. İstediğiniz değişikliklerin firmanız haricinde de kullanılabilecek olması durumunda değişim kısa sürede ve parametrik olarak sizlere sunulmalıdır. Bu istekleri yazılım firmasından rahatlıkla istemenin en güzel yolu kapsamlı bakım anlaşmaları yapılabilir. Bu anlaşmalar ile hem projeniz güncel değişikleri yakalar hem çıkabilecek teknik sorulara cevap alabilir hem de özel durumlarınız için ERP harici çözümler üretmek zorunda kalmazsınız.

İsteklerimize gem vurup proje dışı çözümler yaratmamalıyız.
Projedeki her aksaklık için bir sonraki adıma geçişi durdurmamalıyız.
Projeyi para verip satın alanlar beklentileri olduğunu unutmamalıyız.
Proje bizi işimizden etmeyeceğini aksine verimliliğimizi arttırıp sağlamlaştıracağını unutmamalıyız.
Yaptığımız işin kimlerle bağlantılı olduğunu bilmemizin başkalarının işine karışmak olduğunu düşünmemeliyiz.
Sistem içersinde fazladan yapılan işleri görüp bunları sadece kendi kendinizle paylaşmamalıyız.