ERP projelerinin başarı oranları oldukça düşük düzeylerde seyrediyor. Başlanan projelerin bazıları tamamlanamıyor; tamamlananlar ise beklenen sonucu veremiyor. İstenilen sonuçların alındığı ERP proje oranı % 30’lar seviyesinde seyrediyor. Projeler planlanan sürelerin üzerinde tamamlanıyor, hedeflenen bütçenin çok üzerine çıkılıyor ve nihayetinde hayal kırıklığı ya da az çok eski sisteme benzeyen bir eser ile proje sonlanıyor.
ERP projeleri neden böyle kötü bir şöhrete sahip? Bence yapılan en büyük hata ERP projelerinin IT ağırlıklı bir iş olarak görülmesi. Halbuki ERP projelerinin belki de en küçük parçalarından birisi IT konuları. ERP projerelerinin içinde insan psikolojisi var, kariyer korkuları, kariyer umutları, çelişkiler, çatışmalar, prosesler ve daha bir çok faktör var. Gelişmiş bir proje yönetimi ve disiplini de en önemli bileşenlerden birisi. Bu yazıda ERP projelerinin başarısını belirleyen önemli noktaları ele almaya çalıştım. Hiçbir ERP projesi kolay değildir ama yıllardır test edilmiş ve ders alınmış noktalara dikkat ederseniz daha az acıyla tamamlayabilirsiniz.
Üst Yönetimin Desteği: Herhangi bir proje yönetmemiş birisi için bu kavram çok havada kalabilir. “Yönetim desteklemediği birşey için neden bu kadar zaman ve para harcasınki zaten” diye sorduğunuzu duyar gibi oldum. Üst yönetimin ERP projesini nasıl onayladığı çok önemli. Yönetimin proje gerekliliğini masaya getirmesi ile başkalarının yönetimi bu projeye ikna etmesi çok farklı durumları ifade eder. Böylesine büyük bir projeye zorla ikna edilmiş bir yönetim ERP projesini tali bir iş olarak görebilir. Özellikle elindeki kıymetli insan kaynağını projeye yeterince tahsis etmeyebilir.
Yönetimin isteksiz davrandığı projelerin başarısının yüksek olmayacağını bilmeniz gerekir. Proje yöneticisi olarak acil gerekli tedbirleri almalısınız. Özellikle kaynak sıkıntısı çektiğiniz durumlarda yönetimi bilgilendirmelisiniz. ERP projelerinin sadece % 20- %30 luk bir kısmı IT ile ilgilidir. Geriye kalan herşey bireyler arası ilişkiler ve kendini projeye adama ile ilgilidir. Projenin ilerleyen safhalarında kritik kaynakları kullanamazsanız projeniz zamanında bitmeyecektir, bitirseniz bile istenen kalitede olmayacaktır.
Projenin başında proje liderlerinin ve son kullanıcıların ne kadar zamanlarını bu projeye ayıracaklarını net olarak sayılarla ortaya koymalısınız. Eğer bu kaynağın ayrılacağını garantileyemiyorsanız projenin başarısızlığını garantilemiş olursunuz. Patlayan projelerin bir numaralı nedeni üst yönetimin projeyi anlayamaması ve yeterli desteği vermemesidir.
Proje Yöneticisi: Projenin en önemli kişisi belki de proje yöneticisidir. Proje yöneticisinin IT sistemlerini, database yapısını ve yönetimini iyi bildiği gibi firmaların sahip olduğu prosesleri ve birbirleriyle olan bağlantısını da iyi bilmesi gerekir. Bunun yanı sıra bireysel ilişkilerde güçlü, ikna yeteneği gelişmiş olmalı. Çatışma yönetiminde mahir bir kişi olmalı. Proje yöneticisi alacağı kritik kararlarla projeyi çok iyi bir noktaya götürebileceği gibi çıkmaz sokaklara da sokabilir. Gününün büyük bir kısmı insanları dinlemekle, konuşmakla ve problem çözmekle geçecektir. Çabuk vazgeçen, olaylara olumsuz yaklaşan birisinin yapabileceği bir iş değildir. ERP paket seçiminden sonra yapılacak en önemli seçim proje yöneticisidir.
Çözüm Ortağı: ERP paketinin uyarlamasını yapan firmadaki proje yöneticisinin ve diğer danışmanların yetkinliği başarıda belirleyici bir faktördür. Şirketler içerisindeki prosesleri yeterince bilmeyen, uyarlamasını yaptığı programı tanımayan danışmanlar başınıza büyük dertler açabilirler. Bazen çok küçük bir modifikasyon ile ya da bir parametre değişikliği ile ihtiyacınız giderilebilir. Yetkin olmayan ve bu incelikleri bilmeyen danışmanlar sizi yorucu çözümlere zorlayabilir, gereksiz geliştirmeler için zaman ve para harcamanıza sebep olabilir. Proje ekipleri içinde danışmanların yetersiz olduğuna dair genelde hep bir rahatsızlık vardır. Eğer bu doğru değilse proje yöneticisi olarak bu kaygıları kolayca giderebilirsiniz. Ama gerçekten yetersizlerse proje yöneticisi proje ekibi ve danışmanlar arasında sıkışıp kalacaktır.
Bünyenize uygun çok iyi bir ERP paketi seçmiş olsanız bile, kötü bir çözüm ortağı ile başarılı bir implementasyon yapmanız güç olacaktır.
Doğru ERP Paketini Seçmek: Bu konu başlı başına başka bir yazının konusu olabilir. Çok spesifik bir endüstri kolunda değilseniz çok doğru bir yazılımı seçmemiş olsanız bile bu yazıda anlatılan diğer başlıklara dikkat ettiğinizde hala başarılı bir proje elde edebilirsiniz.
Paketi seçerken zaman, ayrılan bütçe ve insan kaynağı elbette çok önemli kriterler. Ama en önemlisi neden ERP projesine başlamak istediğiniz. Bunun altında yatan temel neden en belirleyici faktördür. En önemli proseslerinizi belirleyin ve en iyi cevabı verebilen paketi tercih edin. Yoğun bir fason prosesiniz varsa, fason için zayıf bir çözümü olan program sorun yaratacaktır. Satışınızın %30 ‘u konsinye mallardan oluşuyorsa ve siz standard konsinye çözümü olmayan bir program aldıysanız işiniz zor olacaktır. Ya da kuruluşunuzun bünyesinde üretici ve pazarlama firmaları varsa ve bunların arasında ihraç kayıtlı faturalaşma varsa bu çok iş yükü getiren bir prosestir. Öncelikli olarak standard çözümü olan paketlerden yana olmalısınız. Paketin içine sonradan gömülmeye çalışılan özellikler hem zaman hem de parayı tüketen değirmene dönüşmektedirler.
Projenin Planı Olmalı: İnsanlara nereye doğru gittiklerini gösteren çok net proje planınız olmalı. Önünüzdeki haftalarda hangi görevlerin yapılacağı ne kadar kaynak gerektiği belli değilse kimse ne yapacağından emin değil demektir. Proje ekibindeki kişilere en az bir hafta önceden çalışma davetiyelerini göndermelisiniz. Planınınız yoksa, plana uyulmadığını da gösteremezseniz. Proje paydaşlarına herhangi bir anda projenin hangi safhasında olduğunuzu gösterebilmelisiniz. MS Project bu konuda gerçekten çok iyi bir araç. 8/80 kuralını proje planını hazırlarken uygulayabilirsiniz. Yani 8 saatten daha az zaman alan işler ile 80 saati aşan işleri plana koymamalısınız. Daha küçük görevleri Sharepoint ile takip edebilirsiniz. 80 saati geçen işleri de daha küçük parçalara bölüp yönetilebilir hale getirmelisiniz. Projenin günlük planlamasında Sharepoint oldukça güçlü bir platform.
Projenin Önceliği: ERP projesinin firmada en öncelikli iş olduğunu kabul ettirmelisiniz. Proje toplantıları ertelenebilen toplantılar, proje ile ilgili görevler sonra da yapılsa olur türünden görevler olarak görülmemelidir. Proje yöneticisi bu konuda gevşeklik gördüğünde derhal yönetime bunu muhtemel sonuçlarıyla raporlamalıdır. Mümkünse proje için özel bir oda ayrılmalıdır. Proje yöneticisi kendisine kıyıda köşede gösterilen yerleri kabul etmemelidir. Projenin önemli olduğunu çalışanlara kabul ettiremezseniz gerçekten önemli olmayacaktır. Şundan hiç şüpheniz olmasın: siz bu raporlamayı yapmadığınızda, projedeki gecikmeden, zaman ve para kaybından dolayı suçlanan kişi yine siz olacaksınız.
Prosesler Hayatidir: Şirketler ve çalışanlar ERP projelerinden mucize beklerler. Sistem hayata geçtikten sonra sihirli değnek değmiş gibi işlerin düzelmesini ya da daha iyiye gitmesini isterler. Aslında ERP, süreçlerin bütünleşik bir sistem üzerinde yürütülmesidir. Eğer firmadaki prosesler ve prosedürlerde ciddi sıkıntılar varsa proje başlamadan bunlar gözden geçirilmelidir. Prosesler iyileştirilmeden proje bitirildiğinde yine sıkıntılar devam edecektir. Çalışma şeklini düzeltmeden hangi ERP paketini kurarsanız kurun beklenen sonuç alınamayacaktır.
ERP projeleri değişimi de beraberinde getirmelidir. ERP programını sürekli firmanın prosedürlerine uymaya zorlamak yerine, bazı prosedürlerin programın işleyiş şekline göre değiştirilmesi gerekebilir. Proje yöneticisi bu konuda çok dikkatli olmalı, problemin prosesten mi yoksa ERP paketinden mi kaynakladığını görebilmeli ve gösterebilmelidir.
Her İstenen Talep Kabul Edilmemelidir: ERP programları çok kompleks yapılardır. Database içerisinde birbiriyle ilişkili binlerce alan vardır. Bir yerde yapılan küçük bir değişiklik başka bir ekranda hiç ummadığınız sonuçlara yol açabilir. Küçük değiklik istekleri ile yazılım ihtiyaçları birbirinden ayrılmalıdır. Proje kapsamı dışında kabul edilen orta çapta bir değişiklik projenin aylarca uzamasına yol açabilir. Projenin analiz safhasında ya da ortalarında kabul ettiğiniz bu değişikşik ya da geliştirme isteği ayağınıza sürekli dolanıp diğer modüllerde de ciddi sıkıntılara yol açabilir. Belli bir zaman dilimini aştığınız için geriye de dönemezsiniz. Sonunda ya bir yama ile işi çözerseniz ya da eski sistemden daha kötü bir çözüm ile projeyi bitirirsiniz. Hiç bitmeyen projeler de var maalesef.
Değişiklik ya da geliştirme taleplerini mutlaka yazılı olarak almalı, projeye zaman ve para olarak ne kadar yük getireceğini yazılı olarak bildirip ilgili bölümden imza almalısınız. Konuyu mutlaka steering committee’ye götürüp onaylatmalısınız. ERP paketi üzerinde geliştirme yapmak mayınlı bir sahada yürümek gibidir. Ne zaman mayına basacağınızı kestirmek zordur. İmplementasyonu yapan çözüm ortağı yeterince deneyimli değilse işiniz daha da zor olacaktır.
İlişkiler: Proje yöneticisi proje paydaşları arasında bir harmoni oluşturmalıdır. Özellikle proje takımı ile düzenli olarak bir araya gelip takım ruhunu geliştirmelidir. Projeyi ekip arasında sürekli olarak canlı tutmalıdır.
Proje ile ilgili her zaman olumsuz konuşan, asla hayata geçmeyeceğini düşünen insanlar olmuştur ve olacaktır. Bunlara karşı direkt olarak karşı çıkmak yerine, yapılan çalışmaların somut sonuçları gösterilmelidir. Gerilim yaratmak yerine projenin içine çekilmeye çalışılmalıdır.
Prototipin Mümkün Olduğunca Erken Hazırlanması: Sistem analizi bittikten sonra proje yöneticisinin ve danışmanların kafasında sistem yavaş yavaş canlanmaya başlar. Analizden hemen sonra sistem prototipinin hazırlanmaya başlanması çok faydalı olacaktır. Sistem testlerine başlamadan önce prototip üzerinde domain liderlere ve son kullanıcılara işlemler yaptırılarak ekranlar üzerinde ayarlamalar yapılabilir. İlave yazılım ihtiyacı ve modifikasyon istekleri daha açık hale getirilir. Projenin ileriki aşamalarında gelen değişiklik talepleri her bakımdan daha maliyetli olacaktır. Bu nedenle eski sistemden database transfer işlemlerine mümkün olan en kısa zamanda başlanmalıdır. Prototip üzerinde çalışmalara başlamak yerine, workshoplar’da sürekli prosesler üzerinde fikir yürütmek havanda su dövmek gibidir.
Testler: Testler projenin belkide en önemli safhasıdır. Yeterince test edilmeyen proseslerin canlı kullanıma geçtikten sonra patlayacağından emin olabilirsiniz. Test edilmemiş hiç bir prosesin, üzerinde işlem yapılmamış hiç bir ekranın kalmadığından emin olmalısınız. İlk etapta unit testler ile prosesler kendi içinde test edilir. Daha sonra entegrasyon testleri ile proseslerin birbirleriyle olan ilişkileri kontrol edilmelidir. Depoya mal kabul işlemi sorunsuz çalışıyor olabilir ama fatura girişi esnasında muhasebede doğru hesaplar çalışıyor mu acaba? Carilerle ilgili bir sıkıntı var mı? Müşteri siparişleri düzgün şekilde açılıyordur ama KDV hesapları doğru mu? İskontolar doğru hesaba gidiyor mu? Buna benzer yüzlerce ilişkinin bıkmadan usanmadan test edilmesi gerekir.
Test ortamında sınırlı sayıda veri olabilir ve bu veriler ile test yaparken problem çıkmayabilir ama canlı kullanıma geçtikten sonra büyük miktarda veri ile çalışmak sorun yaratabilir. Mesela test ortamında MRP ‘yi birkaç sipariş ya da birkaç satır forecast için çalıştırmış olabilirsiniz. Gayet hızlı ve düzgün çalışıyor olabilir. Ama canlı kullanıma geçtiğinizde yüklü miktarlar için çalıştırdığınızda sürprizle karşılaşabilirsiniz. Bu nedenle test ortamınızı mümkün olduğunca doldurmanızı tavsiye ederim.
Kullanma kılavuzları modül sorumluları tarafından mutlaka son testler sırasında yazılmalıdır. Çok formal ya da edebi bir eser beklemiyoruz. Ekran kopyaları ile beraber hangi işlemlerin yapıldığı yazılmalıdır. MRP ekranları gibi kritik parametre ayarlarının da ekran kopyaları alınıp ileride başvurulmak üzere saklanmalıdır. Bu aşamada kullanma kılavuzları hazırlanmazsa, proje bittikten sonra kimse hazırlamayacaktır. ERP programlarının kendi kullanma kılavuzları genel bilgiler vermektedir. Son kullanıcı için çok anlaşılır değildir. Testler esnasında gerçek ekran kopyaları üzerinden yazılan kılavuzlar çok daha fazla yol gösterici olacaktır.
Eğitimler: İnsan bilmediği şeyden korkar. Sistem prototipi oluşturulduktan sonra hemen eğitimlere başlanmalıdır. Kullanıcıların testleri yapabilmeleri için sistemi tanımları gerekir. İlk verilen eğitimlerden sonra kullancılar test yaptıkça sistem üzerinde hakimiyetlerini arttıracaklardır. Eğitimlerdeki kritik nokta modül sorumlularının sistemi çok iyi öğrenmeleridir. Kendi modülleriyle ilgili parametreleri, diğer bazı modüllerle ilişkilerini öğrenmeleri önemlidir. Son kullanıcıların bu kadar detay bilmelerini bekleyemeyiz. Modül sorumluları sisteme hakim oldukları takdirde canlı kullanıma geçtikten sonra problemlerin büyük bir kısmını göğüsleyebilirler. Altından kalkamadıkları durumlar için proje yöneticisi ve danışmanlara müracaat ederler. Eğer bu kilit kişileri implementasyon sırasında iyi yetiştiremezseniz canlı kullanımdan sonra en küçük işler için bile danışmanları meşgul etmek zorunda kalırsınız. Bu da daha öncelikli ve kapsamlı işlerin gecikmesine yol açar. Bunun yanı sıra böyle ufak tefek işlerle sürekli meşgul olmak proje ekibinde yılgınlığa sebep olabilir.
Eğitimler mutlaka bir plan dahilinde verilmelidir. Kayıt altına alınıp saklanması önemlidir. Sharepoint yine bu konuda size yardımcı olacaktır. Proje bittikten sonra bize eğitim vermediler diyenler çıkarsa hiç şaşırmayın. Uyarlama sırasında projeyle ilgilenmeyen bazı arkadaşlar proje bitiminde gerçekle yüz yüze gelirler. Sistemi kullanmaktan başka çareleri yoktur ama kullanmayı da bilmiyorlardır. İşte tam o sırada bize eğitim vermediler demek iyi bir sıyrılma yoludur. O nedenle eğitimlerin ve testlerin mutlaka kaydını tutun.
ERP ‘yi tek çözüm olarak düşünmeyin: ERP paketlerinin her yaranıza merhem olmasını beklemeyin. Bazı alanlarda güçlü çözümlere ihtiyacınız olabilir. Mesela enjeksiyon atölyenizdeki farklı tonajlardaki 100 tane makinenizin detaylı üretim planlama çizelgelemesi için ERP paketiniz yetersiz kalıyor olabilir. Proje sırasında ERP üzerinde oynamalar yapıp projeyi riske etmak yerine, bu alanda uzmanlaşmış bir paket alıp ERP ile entegre edebilirsiniz.
Yine çok yoğun forecasting çalışmalarınız varsa, bunu ERP ‘den beklemek yerine proje bitiminde iyi bir forecasting paketi alıp ERP ile entegre çalıştırabilirsiniz. Artık günümüzde farklı bir çok paket ERP ‘ler ile uyumlu bir şekilde çalışabilmektedir.
Risk Yönetimi: Mücbir sebepler dediğimiz kontrol edemeyeceğiniz ama proje sırasında başınıza gelebilecek riskler vardır. Projenin sonlarına doğru ERP paketinin sahibi firma satılmış olabilir ve siz düzenli destek alamamaya başlamış olabilirsiniz. Kurulumunu yaptığınız firma satın alınılabir ve proje bir anda askıya alınabilir. Buna benzer birçok olasılık var ama siz bunları kontrol edemezsiniz.
Fakat mücbir sebepler dışındaki riskler için risk planlarınız olmalı. Proje yöneticisi ayrılırsa ne yapacaksınız? IFM modülünün tüm dizaynını yapan elemanınız işten ayrılırsa bir planınız var mı? Bu tür risklere karşı mutlaka B planınız olmalı.
Hiç bir modülü tek kişi ile kurmayın. Mutlaka ikili gruplar halinde çalışmalara katılmalarını sağlayın. Kaynak yetersizliği nedeniyle mümkün olmuyorsa daha sonra bilginin ikinci kişiye aktarıldığından emin olun. Projenin sonuna doğru anahtar kullanıcılardan birisinin ayrılması başınızı çok ağrıtabilir.
Tüm bu yazılan faktörler içinde en önemli üç tanesi hangisi derseniz: Üst yönetimin desteği, proje yöneticisi ve çözüm ortağı derim. Bu üçlünün uyumlu çalışması projeyi alıp götürecektir.
ERP projeleri neden böyle kötü bir şöhrete sahip? Bence yapılan en büyük hata ERP projelerinin IT ağırlıklı bir iş olarak görülmesi. Halbuki ERP projelerinin belki de en küçük parçalarından birisi IT konuları. ERP projerelerinin içinde insan psikolojisi var, kariyer korkuları, kariyer umutları, çelişkiler, çatışmalar, prosesler ve daha bir çok faktör var. Gelişmiş bir proje yönetimi ve disiplini de en önemli bileşenlerden birisi. Bu yazıda ERP projelerinin başarısını belirleyen önemli noktaları ele almaya çalıştım. Hiçbir ERP projesi kolay değildir ama yıllardır test edilmiş ve ders alınmış noktalara dikkat ederseniz daha az acıyla tamamlayabilirsiniz.
Üst Yönetimin Desteği: Herhangi bir proje yönetmemiş birisi için bu kavram çok havada kalabilir. “Yönetim desteklemediği birşey için neden bu kadar zaman ve para harcasınki zaten” diye sorduğunuzu duyar gibi oldum. Üst yönetimin ERP projesini nasıl onayladığı çok önemli. Yönetimin proje gerekliliğini masaya getirmesi ile başkalarının yönetimi bu projeye ikna etmesi çok farklı durumları ifade eder. Böylesine büyük bir projeye zorla ikna edilmiş bir yönetim ERP projesini tali bir iş olarak görebilir. Özellikle elindeki kıymetli insan kaynağını projeye yeterince tahsis etmeyebilir.
Yönetimin isteksiz davrandığı projelerin başarısının yüksek olmayacağını bilmeniz gerekir. Proje yöneticisi olarak acil gerekli tedbirleri almalısınız. Özellikle kaynak sıkıntısı çektiğiniz durumlarda yönetimi bilgilendirmelisiniz. ERP projelerinin sadece % 20- %30 luk bir kısmı IT ile ilgilidir. Geriye kalan herşey bireyler arası ilişkiler ve kendini projeye adama ile ilgilidir. Projenin ilerleyen safhalarında kritik kaynakları kullanamazsanız projeniz zamanında bitmeyecektir, bitirseniz bile istenen kalitede olmayacaktır.
Projenin başında proje liderlerinin ve son kullanıcıların ne kadar zamanlarını bu projeye ayıracaklarını net olarak sayılarla ortaya koymalısınız. Eğer bu kaynağın ayrılacağını garantileyemiyorsanız projenin başarısızlığını garantilemiş olursunuz. Patlayan projelerin bir numaralı nedeni üst yönetimin projeyi anlayamaması ve yeterli desteği vermemesidir.
Proje Yöneticisi: Projenin en önemli kişisi belki de proje yöneticisidir. Proje yöneticisinin IT sistemlerini, database yapısını ve yönetimini iyi bildiği gibi firmaların sahip olduğu prosesleri ve birbirleriyle olan bağlantısını da iyi bilmesi gerekir. Bunun yanı sıra bireysel ilişkilerde güçlü, ikna yeteneği gelişmiş olmalı. Çatışma yönetiminde mahir bir kişi olmalı. Proje yöneticisi alacağı kritik kararlarla projeyi çok iyi bir noktaya götürebileceği gibi çıkmaz sokaklara da sokabilir. Gününün büyük bir kısmı insanları dinlemekle, konuşmakla ve problem çözmekle geçecektir. Çabuk vazgeçen, olaylara olumsuz yaklaşan birisinin yapabileceği bir iş değildir. ERP paket seçiminden sonra yapılacak en önemli seçim proje yöneticisidir.
Çözüm Ortağı: ERP paketinin uyarlamasını yapan firmadaki proje yöneticisinin ve diğer danışmanların yetkinliği başarıda belirleyici bir faktördür. Şirketler içerisindeki prosesleri yeterince bilmeyen, uyarlamasını yaptığı programı tanımayan danışmanlar başınıza büyük dertler açabilirler. Bazen çok küçük bir modifikasyon ile ya da bir parametre değişikliği ile ihtiyacınız giderilebilir. Yetkin olmayan ve bu incelikleri bilmeyen danışmanlar sizi yorucu çözümlere zorlayabilir, gereksiz geliştirmeler için zaman ve para harcamanıza sebep olabilir. Proje ekipleri içinde danışmanların yetersiz olduğuna dair genelde hep bir rahatsızlık vardır. Eğer bu doğru değilse proje yöneticisi olarak bu kaygıları kolayca giderebilirsiniz. Ama gerçekten yetersizlerse proje yöneticisi proje ekibi ve danışmanlar arasında sıkışıp kalacaktır.
Bünyenize uygun çok iyi bir ERP paketi seçmiş olsanız bile, kötü bir çözüm ortağı ile başarılı bir implementasyon yapmanız güç olacaktır.
Doğru ERP Paketini Seçmek: Bu konu başlı başına başka bir yazının konusu olabilir. Çok spesifik bir endüstri kolunda değilseniz çok doğru bir yazılımı seçmemiş olsanız bile bu yazıda anlatılan diğer başlıklara dikkat ettiğinizde hala başarılı bir proje elde edebilirsiniz.
Paketi seçerken zaman, ayrılan bütçe ve insan kaynağı elbette çok önemli kriterler. Ama en önemlisi neden ERP projesine başlamak istediğiniz. Bunun altında yatan temel neden en belirleyici faktördür. En önemli proseslerinizi belirleyin ve en iyi cevabı verebilen paketi tercih edin. Yoğun bir fason prosesiniz varsa, fason için zayıf bir çözümü olan program sorun yaratacaktır. Satışınızın %30 ‘u konsinye mallardan oluşuyorsa ve siz standard konsinye çözümü olmayan bir program aldıysanız işiniz zor olacaktır. Ya da kuruluşunuzun bünyesinde üretici ve pazarlama firmaları varsa ve bunların arasında ihraç kayıtlı faturalaşma varsa bu çok iş yükü getiren bir prosestir. Öncelikli olarak standard çözümü olan paketlerden yana olmalısınız. Paketin içine sonradan gömülmeye çalışılan özellikler hem zaman hem de parayı tüketen değirmene dönüşmektedirler.
Projenin Planı Olmalı: İnsanlara nereye doğru gittiklerini gösteren çok net proje planınız olmalı. Önünüzdeki haftalarda hangi görevlerin yapılacağı ne kadar kaynak gerektiği belli değilse kimse ne yapacağından emin değil demektir. Proje ekibindeki kişilere en az bir hafta önceden çalışma davetiyelerini göndermelisiniz. Planınınız yoksa, plana uyulmadığını da gösteremezseniz. Proje paydaşlarına herhangi bir anda projenin hangi safhasında olduğunuzu gösterebilmelisiniz. MS Project bu konuda gerçekten çok iyi bir araç. 8/80 kuralını proje planını hazırlarken uygulayabilirsiniz. Yani 8 saatten daha az zaman alan işler ile 80 saati aşan işleri plana koymamalısınız. Daha küçük görevleri Sharepoint ile takip edebilirsiniz. 80 saati geçen işleri de daha küçük parçalara bölüp yönetilebilir hale getirmelisiniz. Projenin günlük planlamasında Sharepoint oldukça güçlü bir platform.
Projenin Önceliği: ERP projesinin firmada en öncelikli iş olduğunu kabul ettirmelisiniz. Proje toplantıları ertelenebilen toplantılar, proje ile ilgili görevler sonra da yapılsa olur türünden görevler olarak görülmemelidir. Proje yöneticisi bu konuda gevşeklik gördüğünde derhal yönetime bunu muhtemel sonuçlarıyla raporlamalıdır. Mümkünse proje için özel bir oda ayrılmalıdır. Proje yöneticisi kendisine kıyıda köşede gösterilen yerleri kabul etmemelidir. Projenin önemli olduğunu çalışanlara kabul ettiremezseniz gerçekten önemli olmayacaktır. Şundan hiç şüpheniz olmasın: siz bu raporlamayı yapmadığınızda, projedeki gecikmeden, zaman ve para kaybından dolayı suçlanan kişi yine siz olacaksınız.
Prosesler Hayatidir: Şirketler ve çalışanlar ERP projelerinden mucize beklerler. Sistem hayata geçtikten sonra sihirli değnek değmiş gibi işlerin düzelmesini ya da daha iyiye gitmesini isterler. Aslında ERP, süreçlerin bütünleşik bir sistem üzerinde yürütülmesidir. Eğer firmadaki prosesler ve prosedürlerde ciddi sıkıntılar varsa proje başlamadan bunlar gözden geçirilmelidir. Prosesler iyileştirilmeden proje bitirildiğinde yine sıkıntılar devam edecektir. Çalışma şeklini düzeltmeden hangi ERP paketini kurarsanız kurun beklenen sonuç alınamayacaktır.
ERP projeleri değişimi de beraberinde getirmelidir. ERP programını sürekli firmanın prosedürlerine uymaya zorlamak yerine, bazı prosedürlerin programın işleyiş şekline göre değiştirilmesi gerekebilir. Proje yöneticisi bu konuda çok dikkatli olmalı, problemin prosesten mi yoksa ERP paketinden mi kaynakladığını görebilmeli ve gösterebilmelidir.
Her İstenen Talep Kabul Edilmemelidir: ERP programları çok kompleks yapılardır. Database içerisinde birbiriyle ilişkili binlerce alan vardır. Bir yerde yapılan küçük bir değişiklik başka bir ekranda hiç ummadığınız sonuçlara yol açabilir. Küçük değiklik istekleri ile yazılım ihtiyaçları birbirinden ayrılmalıdır. Proje kapsamı dışında kabul edilen orta çapta bir değişiklik projenin aylarca uzamasına yol açabilir. Projenin analiz safhasında ya da ortalarında kabul ettiğiniz bu değişikşik ya da geliştirme isteği ayağınıza sürekli dolanıp diğer modüllerde de ciddi sıkıntılara yol açabilir. Belli bir zaman dilimini aştığınız için geriye de dönemezsiniz. Sonunda ya bir yama ile işi çözerseniz ya da eski sistemden daha kötü bir çözüm ile projeyi bitirirsiniz. Hiç bitmeyen projeler de var maalesef.
Değişiklik ya da geliştirme taleplerini mutlaka yazılı olarak almalı, projeye zaman ve para olarak ne kadar yük getireceğini yazılı olarak bildirip ilgili bölümden imza almalısınız. Konuyu mutlaka steering committee’ye götürüp onaylatmalısınız. ERP paketi üzerinde geliştirme yapmak mayınlı bir sahada yürümek gibidir. Ne zaman mayına basacağınızı kestirmek zordur. İmplementasyonu yapan çözüm ortağı yeterince deneyimli değilse işiniz daha da zor olacaktır.
İlişkiler: Proje yöneticisi proje paydaşları arasında bir harmoni oluşturmalıdır. Özellikle proje takımı ile düzenli olarak bir araya gelip takım ruhunu geliştirmelidir. Projeyi ekip arasında sürekli olarak canlı tutmalıdır.
Proje ile ilgili her zaman olumsuz konuşan, asla hayata geçmeyeceğini düşünen insanlar olmuştur ve olacaktır. Bunlara karşı direkt olarak karşı çıkmak yerine, yapılan çalışmaların somut sonuçları gösterilmelidir. Gerilim yaratmak yerine projenin içine çekilmeye çalışılmalıdır.
Prototipin Mümkün Olduğunca Erken Hazırlanması: Sistem analizi bittikten sonra proje yöneticisinin ve danışmanların kafasında sistem yavaş yavaş canlanmaya başlar. Analizden hemen sonra sistem prototipinin hazırlanmaya başlanması çok faydalı olacaktır. Sistem testlerine başlamadan önce prototip üzerinde domain liderlere ve son kullanıcılara işlemler yaptırılarak ekranlar üzerinde ayarlamalar yapılabilir. İlave yazılım ihtiyacı ve modifikasyon istekleri daha açık hale getirilir. Projenin ileriki aşamalarında gelen değişiklik talepleri her bakımdan daha maliyetli olacaktır. Bu nedenle eski sistemden database transfer işlemlerine mümkün olan en kısa zamanda başlanmalıdır. Prototip üzerinde çalışmalara başlamak yerine, workshoplar’da sürekli prosesler üzerinde fikir yürütmek havanda su dövmek gibidir.
Testler: Testler projenin belkide en önemli safhasıdır. Yeterince test edilmeyen proseslerin canlı kullanıma geçtikten sonra patlayacağından emin olabilirsiniz. Test edilmemiş hiç bir prosesin, üzerinde işlem yapılmamış hiç bir ekranın kalmadığından emin olmalısınız. İlk etapta unit testler ile prosesler kendi içinde test edilir. Daha sonra entegrasyon testleri ile proseslerin birbirleriyle olan ilişkileri kontrol edilmelidir. Depoya mal kabul işlemi sorunsuz çalışıyor olabilir ama fatura girişi esnasında muhasebede doğru hesaplar çalışıyor mu acaba? Carilerle ilgili bir sıkıntı var mı? Müşteri siparişleri düzgün şekilde açılıyordur ama KDV hesapları doğru mu? İskontolar doğru hesaba gidiyor mu? Buna benzer yüzlerce ilişkinin bıkmadan usanmadan test edilmesi gerekir.
Test ortamında sınırlı sayıda veri olabilir ve bu veriler ile test yaparken problem çıkmayabilir ama canlı kullanıma geçtikten sonra büyük miktarda veri ile çalışmak sorun yaratabilir. Mesela test ortamında MRP ‘yi birkaç sipariş ya da birkaç satır forecast için çalıştırmış olabilirsiniz. Gayet hızlı ve düzgün çalışıyor olabilir. Ama canlı kullanıma geçtiğinizde yüklü miktarlar için çalıştırdığınızda sürprizle karşılaşabilirsiniz. Bu nedenle test ortamınızı mümkün olduğunca doldurmanızı tavsiye ederim.
Kullanma kılavuzları modül sorumluları tarafından mutlaka son testler sırasında yazılmalıdır. Çok formal ya da edebi bir eser beklemiyoruz. Ekran kopyaları ile beraber hangi işlemlerin yapıldığı yazılmalıdır. MRP ekranları gibi kritik parametre ayarlarının da ekran kopyaları alınıp ileride başvurulmak üzere saklanmalıdır. Bu aşamada kullanma kılavuzları hazırlanmazsa, proje bittikten sonra kimse hazırlamayacaktır. ERP programlarının kendi kullanma kılavuzları genel bilgiler vermektedir. Son kullanıcı için çok anlaşılır değildir. Testler esnasında gerçek ekran kopyaları üzerinden yazılan kılavuzlar çok daha fazla yol gösterici olacaktır.
Eğitimler: İnsan bilmediği şeyden korkar. Sistem prototipi oluşturulduktan sonra hemen eğitimlere başlanmalıdır. Kullanıcıların testleri yapabilmeleri için sistemi tanımları gerekir. İlk verilen eğitimlerden sonra kullancılar test yaptıkça sistem üzerinde hakimiyetlerini arttıracaklardır. Eğitimlerdeki kritik nokta modül sorumlularının sistemi çok iyi öğrenmeleridir. Kendi modülleriyle ilgili parametreleri, diğer bazı modüllerle ilişkilerini öğrenmeleri önemlidir. Son kullanıcıların bu kadar detay bilmelerini bekleyemeyiz. Modül sorumluları sisteme hakim oldukları takdirde canlı kullanıma geçtikten sonra problemlerin büyük bir kısmını göğüsleyebilirler. Altından kalkamadıkları durumlar için proje yöneticisi ve danışmanlara müracaat ederler. Eğer bu kilit kişileri implementasyon sırasında iyi yetiştiremezseniz canlı kullanımdan sonra en küçük işler için bile danışmanları meşgul etmek zorunda kalırsınız. Bu da daha öncelikli ve kapsamlı işlerin gecikmesine yol açar. Bunun yanı sıra böyle ufak tefek işlerle sürekli meşgul olmak proje ekibinde yılgınlığa sebep olabilir.
Eğitimler mutlaka bir plan dahilinde verilmelidir. Kayıt altına alınıp saklanması önemlidir. Sharepoint yine bu konuda size yardımcı olacaktır. Proje bittikten sonra bize eğitim vermediler diyenler çıkarsa hiç şaşırmayın. Uyarlama sırasında projeyle ilgilenmeyen bazı arkadaşlar proje bitiminde gerçekle yüz yüze gelirler. Sistemi kullanmaktan başka çareleri yoktur ama kullanmayı da bilmiyorlardır. İşte tam o sırada bize eğitim vermediler demek iyi bir sıyrılma yoludur. O nedenle eğitimlerin ve testlerin mutlaka kaydını tutun.
ERP ‘yi tek çözüm olarak düşünmeyin: ERP paketlerinin her yaranıza merhem olmasını beklemeyin. Bazı alanlarda güçlü çözümlere ihtiyacınız olabilir. Mesela enjeksiyon atölyenizdeki farklı tonajlardaki 100 tane makinenizin detaylı üretim planlama çizelgelemesi için ERP paketiniz yetersiz kalıyor olabilir. Proje sırasında ERP üzerinde oynamalar yapıp projeyi riske etmak yerine, bu alanda uzmanlaşmış bir paket alıp ERP ile entegre edebilirsiniz.
Yine çok yoğun forecasting çalışmalarınız varsa, bunu ERP ‘den beklemek yerine proje bitiminde iyi bir forecasting paketi alıp ERP ile entegre çalıştırabilirsiniz. Artık günümüzde farklı bir çok paket ERP ‘ler ile uyumlu bir şekilde çalışabilmektedir.
Risk Yönetimi: Mücbir sebepler dediğimiz kontrol edemeyeceğiniz ama proje sırasında başınıza gelebilecek riskler vardır. Projenin sonlarına doğru ERP paketinin sahibi firma satılmış olabilir ve siz düzenli destek alamamaya başlamış olabilirsiniz. Kurulumunu yaptığınız firma satın alınılabir ve proje bir anda askıya alınabilir. Buna benzer birçok olasılık var ama siz bunları kontrol edemezsiniz.
Fakat mücbir sebepler dışındaki riskler için risk planlarınız olmalı. Proje yöneticisi ayrılırsa ne yapacaksınız? IFM modülünün tüm dizaynını yapan elemanınız işten ayrılırsa bir planınız var mı? Bu tür risklere karşı mutlaka B planınız olmalı.
Hiç bir modülü tek kişi ile kurmayın. Mutlaka ikili gruplar halinde çalışmalara katılmalarını sağlayın. Kaynak yetersizliği nedeniyle mümkün olmuyorsa daha sonra bilginin ikinci kişiye aktarıldığından emin olun. Projenin sonuna doğru anahtar kullanıcılardan birisinin ayrılması başınızı çok ağrıtabilir.
Tüm bu yazılan faktörler içinde en önemli üç tanesi hangisi derseniz: Üst yönetimin desteği, proje yöneticisi ve çözüm ortağı derim. Bu üçlünün uyumlu çalışması projeyi alıp götürecektir.