Yıllardır aynı cümleyi duyuyoruz: "Sistemi kurduk ama kimse kullanmıyor." Ya da: "Danışman firma bıraktı, proje yarım kaldı, şimdi ne yapacağımızı bilmiyoruz." Böyle bir durumda çoğu şirketin aklına gelen ilk fikir, her şeyi baştan yapmaktır.
Bizim tecrübemizde bu çoğu zaman gereksiz ve pahalıdır. Yarım kalmış bir projenin içinde genellikle işe yarayan çok şey vardır. Asıl sorun, neyin işe yaradığını, neyin bozuk olduğunu ayırt edebilmektir.
Teşhis neden bu kadar zor?
Yarım kalmış bir F&O projesi binlerce nesneden oluşabilir. Farklı dönemlerde, farklı ekiplerce yazılmış özelleştirmeler, belgelenmemiş entegrasyonlar, yarıda bırakılmış geliştirmeler... Bunları elle incelemek haftalar sürer. Üstelik kodu yazan kişiler çoğu zaman artık ortada yoktur.
Eskiden bu teşhisi tamamen elle yapıyorduk. Tecrübeli bir danışman sistemin içinde günlerce dolaşır, notlar alır, yavaş yavaş bir resim çıkarırdı. Bu hâlâ gerekli. Ama artık ilk ve en zahmetli kısmını yapay zekâ ile çok daha hızlı yapabiliyoruz.
Yapay zekâ ne yapıyor?
Claude'u projenin geliştirme ortamında çalıştırıyoruz. Yaptığı iş özetle şu:
- Özelleştirmeleri tarayıp hangi standart nesnelere dokunduklarını çıkarıyor.
- Kodu Microsoft'un standart yaklaşımıyla karşılaştırıp aykırı ya da riskli görünen yerleri işaretliyor.
- Yarım bırakılmış, hiç çağrılmayan ya da birbirini tekrar eden geliştirmeleri buluyor.
- Entegrasyon noktalarını ve veri akışlarını belgeliyor.
Çıktı, bir analistin okuyabileceği bir teşhis dokümanı. "Sistem kötü" gibi genel bir yargı değil; "şu modülde şu nesne, şu sebeple sorunlu" düzeyinde somut bir liste.
İnsan nerede devreye giriyor?
Teşhis dokümanı bir başlangıç, karar değil. Bir kodun teknik olarak "yanlış" görünmesi, işletme için yanlış olduğu anlamına gelmez. Bazen standarda aykırı bir geliştirme, şirketin gerçek bir ihtiyacını karşılamak için bilerek yapılmıştır.
Bu yüzden teşhisin ardından mutlaka sahaya iniyoruz: kullanıcılarla, süreç sahipleriyle, yönetimle konuşuyoruz. Hangi sorun iş akışını gerçekten durduruyor, hangisi beklenebilir? Öncelikleri bu konuşmalar belirliyor.
Dikkat ettiğimiz bir nokta da şu: müşterinin mevcut kodunu yeni geliştirmeler için örnek almıyoruz. Teşhiste sorunlu çıkmış bir yaklaşımı yeni koda taşımak, eski sorunu yeniden üretmek demek. Yeni geliştirmede rehberimiz Microsoft standardı.
Onarım ve sonrası
Öncelikler netleştikten sonra onarım başlıyor: eksik geliştirmeler tamamlanıyor, hatalı olanlar düzeltiliyor, veri temizleniyor. Bu aşamada da Claude kodu yazıyor, ekibimiz onaylıyor, derliyor ve test ediyor.
Son adım belki en önemlisi: dokümantasyon. Bir projenin yarım kalmasının en yaygın sebeplerinden biri, bilginin tek bir kişide kalmasıdır. O kişi gidince proje sahipsiz kalır. Bu yüzden her onarımı kullanıcı ve teknik dokümanlarla bitiriyoruz.
Çöpe atmadan önce
Yarım kalmış bir ERP projesi, çoğu zaman başarısız bir proje değil, yönetilememiş bir projedir. İçindeki emeği ve yatırımı çöpe atmadan önce ne durumda olduğuna iyi bakmak gerekir. Yapay zekâ bu bakışı hızlandırıyor; doğru kararı vermek hâlâ insana ve tecrübeye kalıyor.
Projenizin bugünkü durumunu birlikte değerlendirmek isterseniz ERP kurtarma ve iyileştirme sayfamıza göz atabilir ya da bize yazabilirsiniz.