ERP Projesinde İç Ekibin Rolü: Sahiplik ve Görevler

ERP projesi, danışmana ihale edilip sonucu teslim alınabilecek bir iş değildir: yazılımı danışman kurar, ama süreç kararlarını, veriyi ve yeni çalışma düzenini şirketin kendi ekibi taşır. Projenin kaderini belirleyen üç iç rol vardır — yetkili bir sponsor, günlük işi yürüten bir proje lideri ve her süreçten doğru seçilmiş anahtar kullanıcılar. Bu yazıda bu rollerin ne yaptığını, anahtar kullanıcının nasıl seçildiğini, direncin nasıl yönetildiğini ve iç mesainin nasıl planlandığını sahada gördüğümüz desenlerle anlatıyoruz.

“Anahtar teslim ERP” neden yanıltıcı bir beklenti

Teklif görüşmelerinde zaman zaman şu cümleyi duyarız: “Biz işimize bakalım, siz kurun, bitince kullanmaya başlayalım.” Bu beklenti anlaşılır ama gerçekçi değil. ERP kurulumu bir yazılım kurulumu değil, şirketin çalışma biçiminin yeniden yazılmasıdır — ve çalışma biçimine dair kararları dışarıdan hiç kimse sizin yerinize veremez.

Danışman size maliyetlendirme yöntemlerinin seçeneklerini anlatır; hangisinin sizin ürün ağacınıza uyduğuna siz karar verirsiniz. Danışman onay akışının nasıl kurulabileceğini gösterir; kimin neyi onaylayacağını siz söylersiniz. Stok kartlarının nasıl kodlanacağı, hangi depoların ayrı izleneceği, iade sürecinin kaç adımdan oluşacağı — bunların hepsi şirket kararıdır. İyi bir SAP Business One danışmanlık ekibi bu kararları hızlandırır, seçeneklerin bedelini önden gösterir; ama karar mercii olamaz, olmamalıdır.

Sahada en net gördüğümüz desen şu: projeyi “BT’nin işi” ya da “danışmanın işi” olarak konumlayan şirketlerde sistem teknik olarak kurulur, ama kimse sahiplenmediği için eski alışkanlıklar Excel üzerinden geri döner. Bir üretici müşterimizde canlıya geçişten sonra planlama ekibinin üretim emirlerini yine eski tablolarında takip ettiğini, sisteme sadece “muhasebe istiyor diye” veri girdiğini gördük. Yazılım çalışıyordu; proje çalışmıyordu. Sorun yazılımda değil, sahiplikteydi.

Proje sahipliği: sponsor ve proje lideri

ERP projesinin iç organizasyonunda birbirine karıştırılmaması gereken iki rol var. İkisini tek kişide birleştirmeye çalışmak — genellikle “zaten genel müdür ilgileniyor” cümlesiyle — iki rolün de boş kalmasıyla sonuçlanır.

Rol	Kim olmalı	Ana sorumluluk
Proje sponsoru	Üst yönetimden, kaynak ve yaptırım yetkisi olan biri	Önceliklendirme, kaynak tahsisi, tıkanan kararları açmak
Proje lideri	Süreçleri yatay tanıyan, sahada saygınlığı olan bir yönetici	Günlük koordinasyon, takvim takibi, danışmanla tek muhatap
Anahtar kullanıcılar	Her ana süreçten işi fiilen yapan deneyimli çalışanlar	Süreç kararları, test, veri doğrulama, kendi ekibini eğitmek

Sponsorun görevi: karar açmak ve öncelik korumak

Sponsor projede her gün görünmez; göründüğü anlar kritiktir. İki departman bir süreç kararında uzlaşamadığında, anahtar kullanıcının yöneticisi “benim elemanım bu hafta müsait değil” dediğinde, kapsam tartışması büyüdüğünde devreye girer. Sponsorun asıl işi toplantı yönetmek değil, projenin şirket gündemindeki önceliğini korumaktır. Sponsoru olmayan — ya da sponsoru sadece kickoff toplantısında görünen — projelerde kararlar haftalarca askıda kalır, takvim sessizce kayar.

Proje liderinin görevi: günlük ritmi taşımak

Proje lideri, danışman ekiple şirket arasındaki tek muhataptır. Açık konuların listesini tutar, test turlarını organize eder, anahtar kullanıcıların mesaisini korur, riskleri sponsora zamanında taşır. Bu rol için en sık yapılan hata, işi “en boş görünen” kişiye vermektir. Doğru profil bunun tam tersi: süreçleri uçtan uca tanıyan, departmanlar arasında sözü dinlenen, hayır diyebilen biri. Bu kişi çoğu şirkette zaten en meşgul kişidir — o yüzden görevlendirme, mevcut işlerinin bir kısmının devriyle birlikte yapılmalıdır.

Anahtar kullanıcılar: projenin gerçek omurgası

Anahtar kullanıcı (key user), bir sürecin hem mevcut halini hem istisnalarını bilen, o süreç adına konuşma yetkisi verilen kişidir. Satın almadan, satıştan, depodan, muhasebeden, üretimden — kapsamdaki her ana süreçten en az bir anahtar kullanıcı çıkmalıdır.

Seçimde neye bakılır

• İşi fiilen yapıyor olmak. Süreci yöneticisinden değil, içinden bilen kişi. İstisnaları — “ama iade gelirse şöyle yapıyoruz” — ancak işi yapan bilir.
• Sahada saygınlık. Canlıya geçişte ekip arkadaşları soruyu ona soracak; “o biliyorsa doğrudur” dedirtebilen biri olmalı.
• Değişime açıklık. Mevcut düzenin mimarı olan kişi bazen en bilgili ama en dirençli adaydır; bilgiyi alın, rolü değişimi taşıyabilecek kişiye verin.
• Kalıcılık. Ayrılması muhtemel ya da rotasyondaki birine bu rolü vermek, proje bilgisini kapıya emanet etmektir.

Anahtar kullanıcının görevleri proje bitince bitmez

Proje sırasında anahtar kullanıcı süreç tasarım kararlarına katılır, test senaryolarını kendi gerçek işinden yazar, göç eden veriyi doğrular ve kendi ekibinin eğitiminde danışmanın yanında durur. Canlıya geçişten sonra ise ilk destek hattı olur: ekip arkadaşlarının günlük sorularını karşılar, gerçek sorunları toplayıp danışmana iletir. Bu ikinci evre çoğu projede hiç planlanmaz; oysa kullanıcı eğitiminin kalıcı olması, eğitimin sınıfta değil, canlıya geçtikten sonra omuz başında sürdürülmesine bağlıdır — ve o omuz başındaki kişi danışman değil, anahtar kullanıcıdır.

Değişim yönetimi: direnç bir arıza değil, veri

ERP projesinde direnç istisna değil kuraldır. Yıllardır aynı ekranda, aynı Excel’de çalışan bir insandan alışkanlıklarını değiştirmesini istiyorsunuz; üstelik geçiş döneminde işi yavaşlayacak. “Eski sistemde bu tek tuştu” cümlesini duyacaksınız — ve bazen haklı olacaklar.

Direnci yönetmenin ilk adımı onu bastırmak değil, dinlemektir. Sahada gördüğümüz itirazların önemli bölümü duygusal değil, bilgi taşıyan itirazlardır: kullanıcı, sürecin tasarımda unutulmuş bir istisnasını anlatıyordur. Bu itirazları test döneminde duymak, canlıda duymaktan her zaman ucuzdur.

İkinci adım, insanları sonuçla değil süreçle tanıştırmaktır. Kararlara katılan kullanıcı, o kararın savunucusu olur; karar kendisine tebliğ edilen kullanıcı, ilk aksaklıkta “ben demiştim” pozisyonuna geçer. Anahtar kullanıcı modelinin asıl değeri de burada: her departman, sistemi “dışarıdan gelen bir dayatma” olarak değil, kendi temsilcisinin ortak olduğu bir iş olarak görür.

Üçüncü adım dürüst iletişimdir. İlk haftalarda işlerin yavaşlayacağını, hataların çıkacağını ve bunun normal olduğunu baştan söyleyin. “Her şey daha kolay olacak” vaadiyle açılan projelerde ilk zorluk, güven kaybına dönüşür.

İç mesai planlaması: faturada görünmeyen en büyük kalem

Projenin danışmanlık günleri teklifte yazar; kendi ekibinizin harcayacağı mesai hiçbir yerde yazmaz. Oysa anahtar kullanıcılar proje boyunca haftada bir-iki günlerini teste, veri doğrulamaya ve karar toplantılarına verir. Bu mesai planlanmazsa iki şeyden biri olur: ya proje işleri günlük işlere yenilir ve takvim uzar, ya da anahtar kullanıcı iki işi birden taşıyıp tükenir.

Planlamanın pratik tarafı şudur: anahtar kullanıcının günlük işinin bir bölümünü proje süresince kim devralacak, bunu yöneticisiyle baştan konuşun. Test ve veri doğrulama haftalarında bu yük belirgin artar; yoğun dönemleri proje takviminden önceden görüp o haftalara başka büyük iş koymayın. Kapsamlı bir KOBİ kurulumu tipik olarak 2-8 hafta sürer; çok lokasyonlu, geniş kapsamlı projeler 8-12 aya uzayabilir — süre uzadıkça iç mesai da aynı oranda büyür, bu yüzden takvimi korumak sadece danışmanlık bütçesini değil kendi ekibinizi de korur.

Bir de şirket büyüklüğüyle ilgili yaygın bir yanılgı var: “Biz küçük firmayız, bu roller bize ağır.” Tersine — SAP Business One ölçeğindeki bir projede roller birleşebilir (proje lideri aynı zamanda bir sürecin anahtar kullanıcısı olabilir), ama hiçbir rol boş kalamaz. Küçük şirkette sponsor genellikle patronun kendisidir ve bu, doğru kurgulanırsa projenin en büyük avantajıdır: karar mesafesi kısadır.

Proje takvimi boyunca yük nasıl dağılır

İç mesai projeye eşit yayılmaz; hangi aşamada kimin yükleneceğini önden bilmek, o haftaları korumayı mümkün kılar. Kaba harita şöyle:

Proje aşaması	İç ekipten beklenen	Yükün ağırlaştığı rol
Hazırlık ve kickoff	Rollerin atanması, hedef ve kapsamın netleşmesi	Sponsor
Analiz ve süreç tasarımı	Süreçlerin ve istisnaların anlatılması, tasarım kararları	Anahtar kullanıcılar
Gerçekleştirme	Ara doğrulamalar, açık soruların hızlı cevaplanması	Proje lideri
Veri hazırlığı ve göç	Veri temizliği, göç sonrası doğrulama	Anahtar kullanıcılar
Test turları	Gerçek senaryolarla uçtan uca test, hata kaydı	Anahtar kullanıcılar
Canlıya geçiş	Yoğun saha varlığı, anında karar	Tüm roller birden
Canlı sonrası	İlk destek hattı, ilk ay kapanışının doğrulanması	Anahtar kullanıcılar

Tabloda gözden kaçırılmaması gereken satır sonuncusu: canlıya geçiş projenin bitişi değil, iç ekip için en yoğun evrenin başlangıcıdır. İlk ay kapanışı sorunsuz dönene kadar anahtar kullanıcıların takvimi esnek tutulmalıdır.

Kickoff’tan önce cevaplanması gereken sorular

Projeye başlamadan şu soruların hepsinin yazılı cevabı olmalı; boş kalan her satır, ileride bir gecikme olarak geri döner:

1. Sponsor kim ve karar açma toplantılarına fiilen katılacak mı? İsim yoksa proje sahipsizdir.
2. Proje liderinin mevcut işlerinin ne kadarı, kime devredildi? Devir yoksa görevlendirme kağıt üzerindedir.
3. Her ana süreç için anahtar kullanıcı atandı mı ve yöneticileri mesai payını onayladı mı? Yönetici onayı alınmamış görevlendirme, ilk yoğun haftada geri çekilir.
4. Test ve veri doğrulama haftaları şirket takviminde bloke edildi mi? Sezon yoğunluğu, fuar ya da denetimle çakışan test turu, yapılmamış test turudur.
5. Karar mekanizması tanımlı mı — hangi karar kimde, kaç günde döner? “Toplantıda konuşuruz” bir mekanizma değildir.
6. Canlı sonrası ilk ay için destek düzeni ve anahtar kullanıcı nöbeti planlandı mı? Geçiş günü değil, ilk kapanış günü hedeftir.

Kapanış: danışman ne yapar, ne yapamaz

On beş yılı aşkın deneyimimizde ve 30’dan fazla ERP dönüşümünde gördüğümüz tablo net: başarılı projelerle sorunlu projeler arasındaki fark, seçilen yazılımdan çok masanın şirket tarafında oturan ekipte açılıyor. Danışman metodolojiyi, ürün bilgisini ve başka projelerden taşıdığı deneyimi getirir; sizin ekibiniz işin gerçeğini, kararları ve kalıcılığı getirir. İkisi birden masadaysa proje yürür. Projeyi ihale eden değil, ortak olan şirket kazanır.

Sık sorulan sorular

ERP projesinde anahtar kullanıcı ne iş yapar?

Anahtar kullanıcı, kendi sürecinin tasarım kararlarına katılır, test senaryolarını gerçek işinden yazar, göç eden veriyi doğrular ve canlıya geçiş sonrasında ekibinin ilk destek noktası olur. Süreci fiilen yapan, istisnaları bilen ve ekibi içinde sözü dinlenen kişilerden seçilmelidir; rolü proje bitiminde değil, sistem oturduğunda biter.

ERP projesi için şirketten kaç kişi görevlendirilmeli?

Ölçeğe bağlıdır, ama asgari kadro bellidir: bir sponsor, bir proje lideri ve kapsamdaki her ana süreçten en az bir anahtar kullanıcı. Küçük şirketlerde roller birleşebilir — proje lideri aynı zamanda bir sürecin anahtar kullanıcısı olabilir — ancak hiçbir rolün sahipsiz kalmaması gerekir.

ERP projesinde çalışanların direnci nasıl yönetilir?

Direnç bastırılarak değil, erken katılımla yönetilir: kararlara katılan kullanıcı o kararın savunucusu olur. İtirazların önemli bölümü sürecin gözden kaçmış bir istisnasını taşır, bu yüzden dinlemek aynı zamanda bir test yöntemidir. Geçiş döneminde işlerin yavaşlayacağını baştan ve dürüstçe söylemek, sonradan oluşacak güven kaybını önler.

Proje sponsoru kim olmalı, ne yapar?

Sponsor, üst yönetimden kaynak ve yaptırım yetkisi olan kişidir; KOBİ’lerde genellikle genel müdür ya da patronun kendisi. Günlük işleri yürütmez — tıkanan kararları açar, departmanlar arası anlaşmazlıkları çözer ve projenin şirket gündemindeki önceliğini korur. Sponsorsuz projede kararlar askıda kalır ve takvim sessizce kayar.