Bir kurumda “satış raporu” diye anılan yedi rapor varsa, bunların en az beşi aynı tabloları okur. Yine de hiçbiri diğerine benzemez: malzeme grubu birinde filtre, ikincisinde çıktı kolonu, üçüncüsünde hiç yoktur.
Bu duruma genellikle şu açıklama yapılır: “Her iş birimi farklı şey istiyor.” Kısmen doğru. Ama alan adlarının, metinlerin ve dönüşüm kurallarının ayrışması iş biriminden gelmez; her tasarımın boş sayfadan başlamasından gelir.
Ayrışma nerede başlıyor: alan adı, filtre, liste düzeni
Ayrışma tek seferde olmaz, üç kapıdan sızar. Alan adı ve metin: aynı alan raporlarda farklı etiketlerle görünür. Koşul: şirket kodu bir raporda tanımın içinde sabit, diğerinde seçim ekranındadır. Çıktı düzeni: aynı bilgi bir yerde kolon, diğerinde toplam satırıdır.
Bedeli tek bir alan değiştiğinde ortaya çıkar. Değişikliği yedi tanımda ayrı ayrı bulmak, her birini kendi test verisiyle yeniden sınamak ve yedi ayrı onay toplamak gerekir. Kimse bu işi bitirmez; birkaç rapor güncellenir, gerisi geride kalır ve aynı soruya farklı cevap veren raporlar birlikte yaşamaya başlar.
Mevcut iDataView tanımını kopyalamak
Doğru soru “bu raporu ne kadar hızlı tasarlarız?” değil, “yeni rapor hangi tanımın devamı olacak?” REP bu soruya basit bir cevap verir: mevcut bir iDataView tanımı yeni tasarımın başlangıç noktası olur. Şablondan yeni rapor oluşturabilir ya da çalıştığı bilinen bir tanımı kopyalayıp kaynaklarını, bağlantılarını, koşullarını ve alan ayarlarını yeni ihtiyaca göre düzenleyebilirsiniz.
Kazanç tasarım süresinden çok tutarlılıktır. Aynı alan aynı adla, aynı metinle ve aynı dönüşüm kuralıyla gelir; yeni rapor eskisinin kurduğu adlandırma düzenini sürdürür.
Kopyanın üzerinden geçilecek dört nokta
Kopyalamak yeni raporun doğru olduğunu göstermez. Şu dört maddeyi tek tek geçmeden yayına almayın:
- Kaynağa özgü koşullar. Önceki raporun iş yılı, şirket kodu veya hareket türü filtresi yeni ihtiyaca uymuyor olabilir.
- Tablo bağlantıları. Yeni bir tablo eklediyseniz anahtar alanları ve bağlantı türünü yeniden kurmanız gerekir.
- Yetki nesneleri. Alan kümesi değiştiyse yetki eşlemesi de değişir; devralınan eşleme yanıltıcı olabilir.
- Test verisi. Yeni tanımı kendi verisiyle çalıştırın; önceki raporun testi bu rapor için kanıt değildir.
Alan adı bir gün entegrasyon sözleşmesine girer
Aktif bir iDataView tanımı rapor olarak kalmak zorunda değil; aynı tanım bir giden API servisinin veya SQL aktarım projesinin kaynağı olabilir. Bu yüzden alan adlarını ve metinleri baştan düzgün kurmak sonraki kullanımın da işine yarar. “Sonra düzeltiriz” diye bırakılan bir alan adı, altı ay sonra bir entegrasyon sözleşmesinin içinde karşınıza çıkar ve o noktada değişikliğin muhatabı artık yalnızca sizin ekibiniz değildir.
Tasarım süresinde ne kazandığınıza dair paylaşabileceğimiz bir ölçüm yok. Ortak başlangıç noktasının yaptığı şey farklı: rapor tanımlarını birbirine yakın tutar ve bir sonraki değişikliği izlenebilir kılar.
Şu envanterle başlayın: aynı adla anılan rapor kümenizi listeleyin ve hangisinin diğerlerine şablon olabileceğini işaretleyin. O tanımı gözden geçirip kopyalanmaya hazır hâle getirelim; sekizinci raporun nereden başlayacağı böylece belli olur.