Uyarlama sorusunun cevabı "yapılabilir mi" değil, "yükseltmede ne olur" sorusudur. CANIAS ERP'de geliştirme, ürünle birlikte gelen TROIA platformu üzerinde yapılır. Bu esneklik gerçek bir avantajtır; ancak avantaja dönüşmesi, uyarlamanın nasıl yapıldığına ve nasıl belgelendiğine bağlıdır. Bu yazı o disiplini anlatır.

TROIA nedir?

Üreticinin tanımına göre TROIA, dördüncü nesil ve nesne tabanlı bir programlama dilidir; tümleşik geliştirme ortamı, derleyici ve yorumlayıcı birlikte sunulur. Üretici ayrıca şunları belirtir: müşteriler kaynak koda erişebilir, geliştirme sırasında yeniden derleme gerekmez ve mevcut uygulamalar sistem yeniden başlatılmadan düzenlenebilir. Hata ayıklayıcı ve izleme araçları platformun içindedir.

Pratikte bunun anlamı şudur: ekran, rapor ve iş kuralı uyarlaması için ayrı bir geliştirme yığını kurmanız gerekmez. Bu, projedeki teknik kurulum yükünü azaltır.

Cross yapı: standart nesneyi değiştirmeden uyarlamak

Üreticinin belirttiği uyarlama yaklaşımı, standart bir sınıfın yerine müşteriye özel bir sınıfın kullanılabilmesine dayanır. Ayrımın önemi şudur:

  • Standart nesneye dokunulmaz. Üretici standart nesneyi güncellediğinde çakışma yüzeyi dar kalır.
  • Uyarlama kendi kimliğiyle durur. Neyin değiştiği, standart olanla karşılaştırılarak görülebilir.
  • Yükseltmede tekrar test edilecek küme belirlenebilir. "Her şeyi test edelim" yerine, dokunulan nesnelerin listesi test kapsamını tanımlar.

Bu yaklaşımın karşılığı, standart nesneyi doğrudan değiştiren uyarlamadır. Kısa vadede daha hızlı görünür; sürüm yükseltmede en pahalı kalemi üretir.

Esnekliğin bedeli: uyarlama borcu

Geliştirme platformunun ürünle gelmesi, "yapılabilir" cevabını kolaylaştırır. Kolaylaşan her cevap, kapsamı biraz daha büyütür. Uygulamada en sık gördüğümüz tablo şudur: proje sırasında küçük görünen otuz uyarlama, üç yıl sonra yükseltmeyi kilitleyen bir yüke dönüşür.

Bu yüzden her geliştirme talebini önce fit-gap tablosuna geri götürüyoruz: bu ihtiyaç standart fonksiyonla, konfigürasyonla veya entegrasyonla karşılanabiliyor mu? Karşılanamıyorsa geliştirme yapılır — ancak yöntemi ve sürüm yükseltmeye etkisi belgelenir. Bu ayrımın nasıl kurulduğunu ERP nasıl seçilir rehberinde anlatıyoruz.

Her uyarlamada kayda geçmesi gerekenler

  • Ne değişti? Ekran, rapor, iş kuralı veya entegrasyon ucu.
  • Neden değişti? Talebi doğuran iş gereksinimi ve talebi veren birim.
  • Hangi standart nesneye dokunuldu? Dokunulmadıysa bu da yazılır.
  • Yükseltmede ne test edilecek? Uyarlamanın bağlı olduğu iş akışının adı.
  • Kim yaptı, ne zaman? Devir sırasında bu tek satır çok zaman kazandırır.

Bu beş satır, uyarlama sayısı arttıkça değerini artıran tek dokümandır. Tutulmadığında, üç yıl sonra "bu ekran neden böyle" sorusunun cevabı kimsede olmaz.

Yükseltme öncesi ölçülecek üç sayı

  • Uyarlanan ekran ve rapor sayısı. Kapsamın büyüklüğünü gösterir.
  • Standart nesneye dokunan uyarlama sayısı. Riskin yoğunlaştığı yeri gösterir.
  • Yükseltme sonrası tekrar test edilecek iş akışı sayısı. Yükseltme projesinin süresini belirleyen sayıdır.

Bu üç sayı izlenmiyorsa yükseltme süresi tahmin edilemez; tahmin edilemeyen yükseltme ertelenir ve erteleme borcu büyütür.

Devralınabilirlik

Uyarlama disiplininin ikinci amacı ekip bağımsızlığıdır. Kaynak koda erişim, dokümantasyon ve ortam kurulum adımları sözleşmede tanımlandığında, projeyi başka bir ekip devralabilir. Bu koşulların hangi başlıklarda yazılması gerektiğini ERP danışmanlık firması nasıl seçilir yazısında listeliyoruz.

Ürünün katman yapısını ve modül gruplarını CANIAS ERP nedir yazısında ele alıyoruz.

Sık sorulan sorular

Uyarlama yerine standart kalmak her zaman daha mı iyi?

Hayır. İşletmeye gerçek değer üreten, rekabet avantajı taşıyan süreçlerde uyarlama gereklidir. Sorun uyarlamanın kendisi değil, belgelenmemiş ve etkisi bilinmeyen uyarlamadır.

Yükseltme ne sıklıkla yapılmalı?

Sıklığı ürün sürüm takvimi ve sizin risk toleransınız birlikte belirler. Belirleyici olan, yükseltmenin ertelenerek biriktirilmemesidir: iki sürüm geride kalmış bir kurulumda yükseltme, ayrı bir proje boyutuna ulaşır.

Uyarlamaları kim yapmalı: iç ekip mi, danışman mı?

İkisi de olabilir; kritik olan yöntemin aynı olmasıdır. Kurum içinde rapor ve ekran değiştirebilen bir kilit kullanıcı yetiştirmek, sonraki yılların danışmanlık maliyetini düşürür.

Kaynak koda erişim yükseltmeyi zorlaştırır mı?

Erişimin kendisi zorlaştırmaz. Zorlaştıran, erişimi kullanarak standart nesneleri doğrudan değiştirmektir. Desteklenen yöntemle yapılan uyarlama, erişimden bağımsız olarak taşınabilir kalır.