ERP Projelerinde Teklif Talep Dokümanının Stratejik Önemi

ERP Projelerinde Teklif Talep Dokümanının Stratejik Önemi

ERP için Teklif Talep Dokümanı (RFP) hazırlamak, çoğu kurumda amacı ve rolü tam olarak anlaşılmayan bir çalışmadır. RFP denildiğinde genellikle yüzlerce satırlık özellik listeleri, Excel ortamında hazırlanmış “var / yok” soruları ve ERP üreticilerinin broşür diliyle verdikleri yanıtlar akla gelir. Oysa ERP projelerinde karşılaşılan sorunların önemli bir bölümü, seçilen yazılımdan değil; yanlış veya eksik kurgulanmış Teklif Talep Dokümanlarından (RFP) kaynaklanmaktadır. Çünkü RFP, yalnızca teklif toplamak amacıyla hazırlanan bir satın alma belgesi değil; kurumun önceliklerini, beklentilerini ve risklerini tanımlayan stratejik bir karar ve risk yönetimi aracıdır.

ERP için RFP yazmaya başlamadan önce, kurumun kendisine şu temel soruyu sorması gerekir: “Biz ERP’den ne istiyoruz?” Bu soru, çoğu zaman sanıldığı gibi “hangi modüller olacak?” sorusu değildir. Asıl soru şudur: “ERP’nin, hangi kritik iş problemlerimizi çözmesini bekliyoruz?” Bu ayrım yapılmadığı sürece RFP, teknik bir doküman olmaktan öteye gidemez ve süreçleri ile iş akışlarını gerçek anlamda temsil edemez.

RFP’nin omurgasını oluşturan ihtiyaç listesi, yalnızca ERP’de bulunması beklenen fonksiyonları sıralamakla sınırlı kalmamalıdır. Bu liste, kurumun hangi iş ihtiyaçlarını önceliklendirdiğini ve bu ihtiyaçların ERP tarafından hangi yetkinliklerle karşılanmasının beklendiğini açıkça ortaya koymalıdır. İhtiyaçlar; hangi süreci etkilediği, ne kadar kritik olduğu ve hangi fazda devreye alınmasının planlandığı gibi boyutlarla birlikte ele alınmalıdır. Ancak burada gözden kaçırılmaması gereken önemli bir nokta vardır: faz planı, ERP seçimini yönlendiren bir kriter hâline gelmemelidir. Bir ihtiyaç ilerleyen fazlar için planlanmış olabilir; ancak eğer bu ihtiyaç “olmazsa olmaz” niteliği taşıyorsa, ERP’nin bu ihtiyacı hangi fonksiyonel yetkinliklerle ve ne ölçüde karşılayabildiği seçim aşamasında mutlaka değerlendirilmelidir.

“Olmazsa olmaz” kavramı, ERP RFP’sinin en kritik unsurlarından biridir. Olmazsa olmaz olarak tanımlanan bir ihtiyaç; ertelenebilecek, “sonra bakarız” denilebilecek ya da danışmanlıkla telafi edilebilecek bir konu değildir. Yasal yükümlülükler, finansal kontrol, kalite ve izlenebilirlik gibi alanlardaki beklentiler, ERP’nin kurum için asgari yeterliliğini doğrudan ortaya koyar. Bu nedenle RFP’de her ihtiyaç için yalnızca önem derecesi belirtilmemeli; bu ihtiyacın olmazsa olmaz olup olmadığı ve bunun gerekçesi de açıkça tanımlanmalıdır. Ayrıca, olmazsa olmaz olarak belirlenen her ihtiyaç, ERP’nin değerlendirilmesi sırasında kritik senaryo olarak ele alınmalı ve bu çerçevede test edilmelidir.

ERP çözümleri, sahip oldukları özellikler üzerinden değil; bu özelliklerle iş senaryolarını ERP üzerinde ne ölçüde ve ne şekilde gerçekleştirebildikleri üzerinden değerlendirilmelidir. Bu nedenle RFP, ERP üreticilerinden “bu özellik sistemde var mı?” cevabını almak yerine, “bu iş senaryosunu ERP üzerinde nasıl gerçekleştiriyorsunuz?” sorusuna net yanıtlar istemelidir. Olmazsa olmaz olarak tanımlanan kritik senaryolar, değerlendirme sürecinde özellikle ele alınmalı ve demo oturumları sırasında bizzat gösterilmelidir. Demo sırasında gösterilemeyen bir kritik senaryo, karşılanmış kabul edilmemelidir. Çünkü ERP projelerinde asıl sorunlar, sunumlarda değil; sistem canlı kullanıma geçtiğinde ortaya çıkar.

Bir diğer hayati konu ise beklentilerin bütüncül ele alınmasıdır. ERP’de kritik beklentiler çoğu zaman tek bir fonksiyonla karşılanamaz; anlamlı ve sürdürülebilir olabilmeleri için birlikte talep edilen tamamlayıcı ERP yetkinlikleriyle desteklenmeleri gerekir. Örneğin ERP’den izlenebilirlik bekleniyorsa, bu beklenti yalnızca geriye dönük raporlama yeteneği olarak ele alınmamalı; lot ve seri bazlı takip, kalite kontrol planlarının sistem içinde tanımlanabilmesi, malzeme statülerinin yönetilebilmesi ve bu statülere bağlı hareket kısıtlarının ERP tarafından desteklenmesi gibi tamamlayıcı yetkinliklerle birlikte talep edilmelidir. Benzer şekilde MRP beklentisi de yalnızca planlama fonksiyonlarıyla sınırlı kalmamalı; reçete yönetimi, alternatif malzeme tanımları, teslim süreleri ve kapasite parametrelerinin ERP tarafından bütünleşik şekilde sunulması RFP kapsamında açıkça ifade edilmelidir.

Bu nedenle ERP RFP’sinde her ihtiyaç, tekil bir madde olarak değil; hangi diğer ERP yetkinlikleriyle birlikte beklendiği belirtilerek yazılmalıdır. ERP üreticisinden de bu yetkinliklerin her birini ayrı ayrı değil, birlikte ve tutarlı şekilde ne ölçüde sunduğu açıkça talep edilmelidir. Bu yaklaşım benimsenmediğinde, RFP’ler fonksiyonları var gibi görünen ancak beklentiyi bütünsel olarak karşılamayan ERP çözümlerini ayırt etmekte yetersiz kalır.

ERP üreticilerinden alınan cevaplarda en sık karşılaşılan kelime “var”dır. Ancak RFP’de asıl cevaplanması gereken soru “nasıl”dır. Bir ihtiyacın standart mı, parametrik mi, uyarlama ile mi yoksa entegrasyonla mı karşılandığı mutlaka yazılı ve sayısal olarak değerlendirilmelidir. Özellikle olmazsa olmaz ihtiyaçlarda sağlanma derecesi, ERP seçimindeki en önemli kriterlerden biridir. İkinci fazda planlanmış olsa bile, sağlanma derecesi düşük olan bir olmazsa olmaz, ERP çözümünü doğrudan riskli hâle getirir.

RFP’nin doğru hazırlanmış olması, tek başına doğru ERP’nin seçileceği anlamına gelmez. Asıl kritik aşama, RFP’ye verilen yanıtların nasıl değerlendirildiği ve bu değerlendirme sürecinin ne kadar objektif yürütülebildiğidir. Bu noktada tüm değerlendirmelerin eşit ağırlıkta ele alınması her zaman sağlıklı sonuçlar üretmez. ERP’nin belirli modül ve fonksiyonları bazı departmanları doğrudan etkilerken, diğer departmanlar bu alanlardan dolaylı olarak etkilenir. Bu nedenle değerlendirme sürecinde, doğrudan etkilenen departmanların ve ilgili süreç sahiplerinin puanlarının, seçime etkisi daha yüksek olacak şekilde ağırlıklandırılması gerekir. Dolaylı etkilenen departmanların değerlendirmeleri ise çözümün kurumsal bütünlük içindeki uyumunu tamamlayıcı bir rol oynar.

Bununla birlikte RFP değerlendirme süreci, yalnızca teknik yeterlilikler ve senaryo bazlı karşılamalarla sınırlı tutulmamalıdır. ERP seçiminde başarıyı belirleyen unsurların önemli bir bölümü, sistemin kullanıcılar tarafından ne kadar kolay ve etkin kullanılabildiğiyle ilgilidir. Bu nedenle kullanım kolaylığı, kullanıcı deneyimi, çözümün kurumun iş yapış biçimine uygunluğu, esneklik ve ölçeklenebilirlik gibi kriterler de ayrı başlıklar altında puanlanmalıdır. Ayrıca ERP üreticisinin sektörel deneyimi, proje yönetim yaklaşımı, danışmanlık kadrosunun yetkinliği ve uzun vadeli ürün vizyonu da değerlendirme kapsamına dâhil edilmelidir.

Olgun bir RFP’nin en ayırt edici noktalarından biri de best practice veya süreç referanslarıdır. ERP üreticisinden, her kritik ihtiyaca karşılık gelen süreç ya da “best practice” referansı alınmalıdır. Bu bilgiler yalnızca teklif aşamasında değil, proje başladığında da referans alınır; sözleşme eki olur, kapsam tartışmalarını büyük ölçüde ortadan kaldırır ve danışman değişse bile bilginin kaybolmasını engeller.

RFP’nin stratejik bir araç olarak konumlandırılabilmesi için, kurum içinde doğru şekilde sahiplenilmesi de gerekir. RFP; yalnızca bilgi teknolojileri departmanının hazırladığı teknik bir doküman ya da satın alma biriminin yönettiği bir teklif süreci olarak ele alındığında, kaçınılmaz olarak dar bir perspektife sıkışır. Oysa RFP, iş süreçlerini, öncelikleri ve riskleri doğrudan etkileyen bir karar mekanizmasıdır ve bu nedenle kurum genelinde sahipliği olan bir çalışmadır. İş birimleri ihtiyaçların tanımlanmasında aktif rol alırken, IT teknik uygunluğu ve entegrasyon boyutunu değerlendirir; proje sponsoru ise olmazsa olmazları ve stratejik öncelikleri netleştirir.

Sonuç olarak ERP için Teklif Talep Dokümanı hazırlamak, bir doküman yazma işi değildir. Bu, kurumun kendi önceliklerini netleştirdiği, risklerini görünür kıldığı bir karar modeli kurma sürecidir. İyi hazırlanmış bir RFP, ERP projesini garanti etmez; ancak kötü bir ERP projesini daha başlamadan engeller. Ve bu, çoğu zaman projenin kendisinden çok daha değerlidir.