ERP Projelerinde Geliştirme Kararlarının Uzun Vadeli Etkileri
Geliştirme yapmak çoğu zaman hızlı ve mantıklı görünür. Ancak asıl maliyet, çok daha sonra ortaya çıkar.
ERP projelerinde uzun süredir vurgulanan bir yaklaşım var: mümkün olduğunca standart fonksiyonları kullan. Bu prensip yeni değil. Birçok metodolojide ve proje deneyiminde tekrar tekrar ortaya konmuş. Ancak saha uygulamalarına bakıldığında, her zaman aynı ölçüde karşılık bulmadığı görülüyor.
Standart fonksiyonlar zaman içinde daha kapsamlı ve olgun hale gelmiş olsa da, projelerde geliştirme kararlarının görece erken ve hızlı alındığına sıklıkla rastlanıyor. Bu durum tek bir nedene indirgenemeyecek kadar çok boyutlu.
Geliştirme kararı çoğu zaman açıkça tartışılan bir alternatif olmaktan ziyade, sürecin varsayılan çıktısı haline gelebiliyor.
Sisteme hâkimiyetin zorlaşması, ekiplerin deneyim seviyesi, iş birimlerinin mevcut alışkanlıklarını koruma eğilimi ve geliştirme süreçlerinin teknik olarak daha erişilebilir hale gelmesi — tüm bu faktörler bir araya geldiğinde, geliştirme seçeneği giderek daha erken değerlendiriliyor. Ve bu durum her zaman bir sorun yaratmıyor; ama zemin hazırlıyor.
Bu çerçevede, karar anında şu sorunun daha bilinçli şekilde sorulması gerekiyor: Bu ihtiyacın geliştirme olmadan karşılanma olasılığı yeterince değerlendirildi mi?
Standart neden yeterince kullanılmıyor?
Bunun birkaç temel sebebi var ve çoğu zaman birbirini besliyor.
Standart fonksiyonlara hâkimiyet
Dynamics 365 gibi platformlar yıllar içinde önemli ölçüde olgunlaştı; ancak kapsam genişledikçe sistemin tüm yeteneklerini doğru değerlendirmek zorlaşıyor. Bu nedenle, birçok projede standart çözümün sınırları yeterince analiz edilmeden geliştirme kararı alınabiliyor. Çoğu zaman bu sınırlar, geliştirme yapıldıktan sonra daha net anlaşılıyor.
İş birimlerinin mevcut süreçlere bağlılığı
ERP projeleri doğası gereği bir dönüşüm içeriyor; ancak pratikte süreçlerin olduğu gibi korunma eğilimi baskın olabiliyor. Bu da çözümün standarda uyarlanmasındansa, sistemin mevcut sürece uyarlanmasını daha olası hale getiriyor.
Hız algısı
Geliştirme, ilk aşamada daha hızlı bir çözüm gibi görülebiliyor. Standart çözümün değerlendirilmesi ve süreçlerin yeniden ele alınması zaman gerektirirken, geliştirme daha doğrudan bir yol sunuyor. Ancak bu hız genellikle ilk teslimatla sınırlı kalıyor; sonrasında bakım ve uyarlama yükü artıyor.
Geliştirme süreçlerinin kolaylaşması
Teknik olarak çözüm üretmenin hızlanması, geliştirme seçeneğinin daha erken aşamada gündeme gelmesine neden olabiliyor. Bu durum doğrudan bir sorun yaratmamakla birlikte, kararların daha az sorgulanmasına zemin hazırlıyor.
Asıl problem nerede başlıyor?
Geliştirme yapıldığı anda değil. Asıl etkisi zaman içinde ortaya çıkıyor.
İlk aşamada, standart ile çözülebilecek bir ihtiyacın geliştirme ile ele alınması, sistemi yavaş yavaş standart yapısından uzaklaştırıyor. Bu uzaklaşma çoğu zaman hemen fark edilmiyor; çünkü sistem çalışmaya devam ediyor. Ancak zamanla, standart fonksiyonlarla birlikte hareket etme kabiliyeti azalıyor.
Buna ek olarak, bu tür geliştirmeler genellikle belirli bir ihtiyacı hızlı şekilde çözmek amacıyla, sınırlı bir perspektifle tasarlanıyor. Çoğu zaman birkaç kişinin bilgisi ve yaklaşımıyla şekillenen bu çözümler, firmanın zaman içinde değişen ve genişleyen ihtiyaçlarına uyum sağlamakta zorlanabiliyor.
Esneklik kaybı
Süreçler, standart yapıdan uzaklaştıkça değişime daha dirençli hale geliyor.
Kişi bağımlılığı
Sistem, geliştirmeyi yapan kişinin bilgisine bağımlı hale gelebiliyor. O kişi ayrıldığında boşluk büyüyor.
Yazılım kalitesi
Yeterince dokümante edilmemiş geliştirmeler, destek ve bakım süreçlerini doğrudan etkiliyor.
Teknik boyutun ötesi
Gereksiz geliştirme yalnızca uygulama seviyesinde kalmıyor; sistemin temel yapısını da etkiliyor. Veri modeli gereksiz yere genişleyebiliyor, veri tekrarları ve tutarsızlıklar oluşabiliyor, yanlış kurgulanmış yapılar veri bütünlüğünü zorlayabiliyor.
ERP sistemlerinin doğası gereği veri modeli ve süreçler birbirine sıkı bağlıdır. Bu nedenle, geliştirme seviyesinde yapılan bir tercih, zaman içinde tüm sistemi etkileyen sonuçlar doğurabiliyor.
Entegrasyon yapıları da bu durumdan etkileniyor. Standarttan uzaklaşan sistemlerde entegrasyonlar daha kırılgan hale geliyor ve değişikliklere karşı daha hassas bir yapı oluşuyor.
Çoğu zaman geç fark edilen bir etki
Standart yapıdan uzaklaşan çözümler, kullanıcıların sistem içerisindeki rol ve yetki kurgusunu dolaylı olarak etkileyebiliyor. Bu da zaman içinde daha yüksek lisans ihtiyaçlarına ve ek maliyetlere yol açabiliyor.
Nasıl yaklaşmak gerekir?
Bu konuda çok karmaşık modellere ihtiyaç yok. Ancak kararların belirli bir disiplinle alınması önemli. Genel yaklaşım çoğu projede benzer bir sırayı takip ediyor: önce standart fonksiyonlar gerçekten değerlendirilmeli, ihtiyaç karşılanmıyorsa konfigürasyon seçenekleri ele alınmalı, geliştirme ise çoğu zaman en son başvurulması gereken alternatif olmalı.
Burada kritik olan nokta, “standartı zorlamak” ifadesinin yalnızca teknik bir değerlendirme olmamasıdır. Bu aynı zamanda doğru bilgiye ve deneyime sahip bir ekip gerektirir. Standart fonksiyonların gerçekten neyi karşılayabildiğini anlayabilmek, büyük ölçüde danışmanlık kalitesiyle doğrudan ilişkilidir.
Bununla birlikte, standartın kullanımı yalnızca danışmanlık tarafında belirlenen bir konu değil. İş birimlerinin yaklaşımı da bu sürecin önemli bir parçası. Yeni sisteme geçişte alışkanlıkların değişmesi, süreçlerin yeniden ele alınması ve belirli bir konfor alanından çıkılması gerekebiliyor. Bu da zaman zaman standart çözümlere karşı direnç oluşturabiliyor. Bu noktada, standart kullanımının yalnızca teknik olarak değil, organizasyonel olarak da desteklenmesi gerekiyor.
Karar anında sorulması gereken sorular
Geliştirme kararı verilmeden önce birkaç temel sorunun sistematik şekilde ele alınması, süreci önemli ölçüde değiştiriyor:
Bu ihtiyaç iş açısından gerçekten kritik mi?
Standart çözümle ne kadar karşılanabiliyor?
Bu geliştirme 1–2 yıl sonra da anlamlı olacak mı?
Bakım ve sahiplik kimde olacak?
Bu ihtiyacın sıklığı nedir? Nadirse manuel çözüm daha dengeli olabilir mi?
Son soru çoğu zaman gözden kaçıyor. Bazı ihtiyaçlar teknik olarak standartla karşılanamayabilir — ama bu her zaman geliştirme gerektirdiği anlamına gelmiyor. Temel soru şu: Sistemi daha karmaşık hale getirmenin karşılığında elde edilen fayda ne kadar sürdürülebilir?
Son bir gözlem
ERP projelerinde başarı genellikle yapılan geliştirme sayısıyla ölçülmez. Daha çok, ne kadar az geliştirme ile sürdürülebilir bir yapı kurulabildiğiyle ilgilidir.
Gözden kaçırılan önemli bir konu var: bir ERP projesi, canlıya alındığı anda tamamlanmış bir proje değildir. Aksine, o andan itibaren yaşamaya başlayan bir yapıdır. Dolayısıyla ERP sistemi, tek seferlik bir kurulumdan ziyade, sürekli beslenmesi, korunması ve geliştirilmesi gereken bir varlık olarak ele alınmalıdır.
Doğru şekilde beslenmeyen ve dengeli büyümeyen bir yapı, zaman içinde hem teknik hem operasyonel anlamda zayıflar. Bu zayıflıklar çoğu zaman hemen görünür olmaz; ancak ilerleyen süreçte daha büyük ve çözülmesi zor problemlere dönüşebilir.
Saha gözlemlerinde sık karşılaşılan bir durum da bu süreci destekler nitelikte. Proje canlıya geçene kadar belirli bir disiplin ve kontrol mekanizması içinde ilerlerken, canlıya geçiş sonrasında bu yapı zaman zaman zayıflayabiliyor. Özellikle iç ekiplerin hızlı çözüm üretme isteğiyle yaptığı müdahaleler, çoğu zaman aynı seviyede sorgulanmadan sisteme dahil edilebiliyor. Bu durum kısa vadede çevik bir yapı hissi verse de, uzun vadede sistemin daha karmaşık ve yönetilmesi zor bir hale gelmesine neden olabiliyor.
Bu nedenle, proje yaklaşımının yalnızca canlıya geçişe kadar değil, sonrasında da aynı hassasiyetle devam etmesi gerekiyor. Sistem sağlığının gözetilmesi, yapılan her değişikliğin etkisinin değerlendirilmesi ve ürünün teknolojik olarak güncel kalmasının sağlanması bu sürecin temel unsurları arasında yer alıyor.
Bugün Dynamics 365 gibi platformlar, sürekli güncellenen ve gelişen bir yapı sunuyor. Bu da sistemlerin standart fonksiyonlar üzerinden büyümesine ve yeni yeteneklerden hızlı şekilde faydalanmasına olanak tanıyor. Ancak bu avantajın sürdürülebilmesi, yapılan geliştirmelerin bu yapıyı bozmayacak şekilde ele alınmasına bağlı.
Yapay zekâ ile birlikte iş uygulamalarının daha esnek ve hızlı geliştiği bir dönemdeyiz. Ancak bu durum, geliştirme kararlarının daha dikkatli alınmasını gerektiriyor.
Yapay zekâya hazır, sürdürülebilir iş uygulamaları oluşturabilmek için, geliştirme ihtiyacının kendisi kadar, bu ihtiyacın nasıl karşılandığı da belirleyici hale geliyor.
Selamlar.
Fatih Demirci
