Oracle'ın iş uygulamaları segmentinde müşterileri için sunduğu "Applications Unlimited" yaklaşımı doğrultusunda, Oracle E-business Suite ERP uygulaması da zaman içerisinde fonksiyonellik, ölçeklenebilirlik, daha düşük toplam sahip olma maliyeti unsurlarında büyük yol katetmiş ve Release 12 versiyonu ile de teknik kabiliyetlerini en üst noktaya taşımıştır.
Son yayınlanan 12.2 versiyonu ile de gelişimini aralıksız sürdürmektedir. İlk kez Ocak 2007 yılında kullanıma sunulan R12, 12.1 sürümünden itibaren stabil bir yapıya kavuşmuş ve yeni implementasyonlar R12 üzerinden yürütülmeye başlanmıştır.
Oracle E-Business Suite kullanıcısı durumunda olan kurumların bir önceki versiyon olan 11i ailesinden Sürüm 12'ye geçişi
konusunda gerekçeleri irdeleyecek olursak bu geçişi doğru bir planlama ve zamanlama ile gerçekleştirmek konusunda daha net bir algıya sahip olabiliriz.
Oracle yıllar boyunca iş uygulamaları segmentinde yapmış olduğu yatırımları ve en iyi iş tecrübelerini global bir teknolojik mimari altında toplama stratejisini sürdürüyor. Bundan dolayı Oracle Fusion Suite ve Fusion Middleware yapısına geçişte teknolojik anlamda önemli bir mihenk taşı oluşturan Sürüm 12, tüm Oracle dünyasının bundan sonra alışagelmesi gereken ana teknoloji bileşenlerini ve süreçsel öğeleri içerisinde barındırıyor. Bundan dolayı da Oracle EBS çatısı altında yapılması planlanan
yeni modül, iş süreçleri ve uygulama geliştirme yatırımları için Sürüm 12'yi bir önkoşul olarak düşünmek yanlış olmaz. Ayrıca bulut bilişim teknolojilerine dayanan Fusion Applications modüllerinin de "co-existance" adı verilen bir modelle EBS modülleriyle eşzamanlı ve entegre çalışabildiğini düşünürsek, Fusion yapısına ve gelecek nesil iş uygulamalarına aşamalı geçiş için de Sürüm 12'yi bir ilk adım olarak düşünmek gerekiyor.
Oracle firmasının da, hem kendi bünyesindeki yatırımları hem de totaldeki teknoloji çizgisini bu zaruri ve doğal dönüşüm
sürecine yönlendirebilmek için müşterilerini yormayacak ve mevcut yatırımlarını da riske atmayacak bir planlama ve takvimlendirme yaptığını görüyoruz. Buna göre 11i versiyonu için Oracle destek yapısının kademeli olarak sırasıyla
"Premier", "Extended" ve "Sustaining" destek modellerine geçiriliyor ve 2014 yılı sonuna kadar firmaların sürüm yükseltim
çalışmalarını gerçekleştirmeleri gerekiyor. Bu tarihten sonra 11i versiyonları için kritik yama üretimlerinin durdurulacağını, destek süreçlerinde ise 1. öncelik destek taleplerinin iletilemeyeceğini görmekteyiz.
Bunların ötesinde Yeni Türk Ticaret Kanunu ile gelen UFRS yükümlülüklerinin uygulanabilirliği, gömülü iş zekası uygulamalarının sağlayacağı karar destek olanakları, raporlama altyapısındaki ilerlemeler, daha hızlı teknik yerleştirim, zenginleştirilmiş mali işler ve satınalma fonksiyonları, yeni nesil insan kaynakları yaklaşımlarına uygun ürünler, 3. parti entegrasyonlar için SOA tabanlı açık-standartlar teknolojisi, back-office operasyonlarında paylaşımlı servis yapıları (ör: Multi-org erişim kontrolü), vb. Sürüm 12 için tercih nedeni olabilecek sayısız avantajdan sadece birkaçı.
R12 versiyonuna geçiş fırsatlarını kaynak uygunluğunuza göre farklı stratejilerle gerçekleştirmeniz mümkün. Birçok firma
daha doğru zamanı ve geçiş için somut bir iş gereksinimini beklemeyi tercih etti ancak artık takvimin sonuna gelindi. Bazı firmalar ise endirek yada işletme bazında geçiş stratejileri ile süreci zamana yaymayı tercih etti. Ancak bu yöntemlerin hepsinin çözüm sürecini kaynak kısıtları nedeniyle öteleyen ve daha fazla riske sokan yöntemler olduğunu biliyoruz. Doğru bir proje planı ve
analiz ile sürüm yükseltimini direk uygulamak çok daha efektif görünüyor.
Sürüm yükseltimi için öngörülebilecek iki farklı yöntem bulunuyor: Yeniden implementasyon (migration) ve upgrade. Bakıldığında nihai ürün olarak her iki yöntemle de aynı sonuca varacağımız aşikar, ancak seçeceğimiz yöntemin projelendirme aşamasında ortaya koyduğumuz proje hedefleri ve kısıtlarıyla da tam olarak ilişkili olduğunu da belirtmek gerekiyor.
Sürüm yükseltimini migration yöntemiyle yapmak bakıldığında yeni bir sistem kurulumu, yeniden implementasyon, tüm verilerin ve mevcut ek geliştirmelerin yeni sisteme aktarılması ve test demek. Migration yönteminin sıfır bir EBS projesinden teknik anlamda bir farkı olmadığı şeklinde yorumlansa da, mevcut yapının analizi sonrasında yalnızca R12'ye uyarlanacak farkların ve fark tasarımının ele alınacağını düşünürsek danışmanlık eforu mutlaka yeni implementasyon projelerinden daha az olacaktır.
Ancak migration yönteminin upgrade'e tercih edilmesi konusunda çok daha rasyonel sebepler bulunuyor. Eğer yeni R12 projelendirmesi ile birlikte kurumsal iş süreçlerinizde de bir yeniden yapılanma ve optimizasyon hedefliyorsanız, dolayısıyla majör değişiklikler yapmayı öngörüyorsanız, bununla birlikte organizasyonel yapınızda süregelen değişiklikler var ve bunları ERP sisteminize yansıtmak, yeni faaliyet alanları ve işletmeleri sisteme dahil etmek istiyorsanız, modül kurulumlarında belirgin değişiklikler öngörüyorsanız veya sürüm yükseltim projesi kapsamında yeni EBS modüllerinin kurulumları söz konusuysa, tarihçeli verilerinizi rafine ve standardize etmek hedefindeyseniz ve yoğun bir customizasyon altyapınız varsa migration yöntemi sizin için daha doğru bir tercih olacaktır.
Upgrade çalışmalarını ise temelde 3 kelimede özetleyebiliriz: teknik dönüşüm, test ve upgrade yamalarının uygulaması. Yeniden implementasyona kıyasla veri transferi ve kurulumlar için harcanan efor upgrade yönteminde çok daha az seviyededir, mevcut veri kümesi ve kurulumlar korunmuş olur. Eğer tek-sistem yapısındaysanız ve mevcut iş süreçlerindeki "as-is" yapıdan uzaklaşmayı hedeflemiyorsanız upgrade'in daha uygun bir tercih olacağını söyleyebiliriz, ancak bu durum upgrade yönteminin daha yalın ve basit bir proje çalışması olduğu anlamına asla gelmemektedir. Kendi içinde proje yönetimi anlamında yüksek hassasiyet gerektirdiğini ve upgrade projelerinde anahtar kelimenin "TEST" olduğunu vurgulamak gerekiyor.
Eğer öngörülen kalite ve detayda testler gerçekleştirildiyse upgrade projelerinin canlıya geçiş sonrasında destek sürecini kısalttığını ve potansiyel destek maliyetlerini de daha fazla düşürdüğünü söyleyebiliriz.
Athena Bilişim Çözümleri olarak sürüm güncelleme projelerinde görev alacak danışman kadroların gerek teknik gerek fonksiyonel yetkinlikler bazında hem R12 ürününü çok iyi tanıyor olması hem de mevcut EBS yatırımlarını R12 mimarisine en optimal yaklaşımlarla dönüştürebilmesi gerektiğini düşünüyoruz.
Bu mimari dönüşümün belki de en önemli bacağını mali işler uygulamaları oluşturuyor. Yeni versiyonla birlikte yeni yasal defter mantığı, ana defter ve raporlama defterleri, kural bazlı finansal muhasebe mekanizması olan Cari Hesap Muhasebesi (SLA), yeni vergi yönetim yaklaşımı, çoklu organizasyon erişim kontrolleri (MOAC), kurum içi faturalama, merkezi ödeme, tedarikçi bilgileri yönetim mekanizması (TCA) gibi konu başlıklarıyla birlikte daha tutarlı, entegre, izlenebilir bir finansal yapının oluşturulduğunu görmekteyiz. Ayrıca finansal uygulamalar özelinde kullanılan bir çok raporlama ve karar destek aracının Oracle'ın sunduğu yeni teknolojiler doğrultusunda sürüm yükseltim projelerinde kullanılabileceğini göz ardı etmemek gerek.
Athena olarak projelerimizde yeni teknolojileri ve beraberinde gündeme gelen performans geliştirme olanaklarına da odaklandığımızı belirtmeliyiz.
Ayrıca diğer tüm R12 ve sonrası sürümlerde ve modüllerde genel eğilim Oracle EBS'in giderek daha self servis tabanlı işletime sahip, Oracle Application Framework (OAF) teknolojisini referans alan bir yapıya ulaştırılması yönünde. OAF teknolojisi de tüm Oracle uygulama geliştirme teknolojileri içerisinde en spesifik yetkinlik alanlarından birini oluşturuyor. Bu yüzden R12 özelindeki projeleriniz için tedarikçilerinizi seçerken bu konuda daha dikkatli olunmasını öneririz.
R12'nin diğer fonksiyonel avantajları ve değişiklikleri olarak iş akışlarındaki yeniden tasarım ve geliştirilmiş detay süreç senaryoları, daha sezgisel ve erişilebilirliği artırılmış arayüz özellikleri (favoriler, navigasyon menüleri, giriş sayfası özellikleri, yardımcı pop-up ve hover pencereleri, vb), daha yüksek performans, yama uygulamalarında daha düşük sürelerinden bahsedebiliriz.
Gerek migration gerekse upgrade yöntemleriyle yapılan sürüm yükseltim projelerinde Athena Bilişim Çözümleri olarak özel bir proje yönetim metodolojisi kullanmaktayız. Temelde Oracle Unified Method üzerine inşa edilmiş olan bu metodoloji, R12 sürümünün kuruma ait mevcut iş süreçleri üzerindeki etkilerinin doğru ölçümlenmesi ve proje aktivitelerinin en optimal teknik yöntemlerle gerçekleştirilmesine dayanıyor.
Her ne yöntemle yapılırsa yapılsın bir ERP projesindeki çıkış noktasının öncelikle proje hedeflerinin net bir şekilde ortaya konulması prensibini hatırlatmakta fayda var. Bu sayede proje yönetim yaklaşımımızı, proje kapsamını, araçlarımızı, proje yönetim planımızı ve hedef tarihlerimizi tümdengelim düşüncesiyle ortaya daha net bir şekilde koyabilir ve risklerimizi minimize edebiliriz.
Tüm Oracle projelerinde olduğu gibi ilk adımda detaylı bir mevcut durum iş süreç analizinin gerçekleştirilmesi, proje yaklaşımı doğrultusunda iş süreçleri ve ek geliştirme envanteri için izlenecek stratejinin belirlenmesinin kritik olduğunu söyleyebiliriz. R12 versiyonu ile birlikte gelen mimari değişiklikler ve yeni fonksiyoneliteler, "as-is" olarak isimlendirdiğimiz mevcut yapının ne oranda ve hangi koşullarda korunacağını ya da etkilerinin hangi noktalarda ele alınarak projelendirilmesi gerektiğini bize söyleyecektir.
R12 versiyonu değişikliklerinin ve sistem bileşenleri üzerindeki etkilerinin zaruri değişikikler, olası değişiklikler, tercihli değişiklikler olarak gruplanması ve önceliklendirilmesi, "to be" yapısının buna göre dizayn edilmesi gerekmektedir.
R12 sürüm yükseltim projeleri firmaların hâlihazırda kullanımda olan EBS yatırımlarına odaklanan bir çalışma olduğu için, mevcut verilerin, ek geliştirmelerin ve sistem entegrasyon bileşenlerinin aktarımı ve/veya R12 yapısına uyumlaştırılması konusunda büyük hassasiyet gerektiriyor. Bu noktada teknik danışmanlık çalışmaları içeren ve dikkatli planlanması gereken yoğun bir çalışma planı programı bizleri bekliyor.
Athena Bilişim Çözümleri olarak teknik yetkinliklerimizin ve tecrübelerimizin bu noktada fark yaratmakta olduğunu özellikle vurgulamak istiyoruz.
R12 sürüm yükseltimi projeleri kapsamında değinebileceğimiz sayısız konu başlığı olmakla birlikte satır aralarında özellikle dokümantasyon, R12 fark eğitimlerinin proje ekipleri ve kullanıcılara aktarımı, stratejik test planlamasının yapılması, risk yönetiminin gerçekleştirilmesi, canlı geçiş (cut-off) ve iletişim planı, felaket senaryolarının oluşturulması, Oracle destek planının ve servis çağrılarının yönetimi, dahili konu ve issue yönetimi, sistem yama uygulamalarının tespiti ve koordinasyonu, upgrade/migration öncesi önkoşul çalışmalarının planlanması, Oracle sürüm yükseltim yönergelerinin ve kaynaklarının doğru taranması ve aksiyonların doğru belirlenmesi gibi maddelerin büyük önem taşıdığını söyleyebiliriz.
Tüm bu konular arasında test planlamasına ayrı bir parantez açmak gerekiyor. Başta upgrade olmak üzere tüm R12 yükseltim projelerinde eksiksiz, detaylı planlanmış ve senaryolaştırılmış test çalışmalarının yürütülmesi ve firma sistem kullanıcılarının anahtar ve son kullanıcı seviyesinde bu test organizasyonuna katılımı belki de en büyük önemi taşıyor. Özellikle upgrade projelerinde test iterasyonlarının her birini ayrı birer proje fazı olarak ele alıp her bir iterasyonda yeni bir sistem kopyası üzerinde sürüm yükseltimini fiilen uygulayıp amaçlarına göre test aktivitelerinin gruplanması ve hiçbir istisna veya tolerans gözetmeksizin testlerin gerekirse defalarca yapılması gerektiğini önemle vurguluyoruz.
Bir artı paragrafı da R12 ile birlikte ekstra dikkat ve kontrol gerektiren noktalara açalım. Özellikle majör mimari değişikliklerin gözlemlendiği mali işler uygulamaları ve özellikle borçlar muhasebesi uygulamalarının ve verilerin ekstra bir konsantrasyon ve kontrole tabi tutulması gerektiği çok aşikar. Burada mevcut tedarikçi tanımlama mimarisinin TCA ve OAF yapısına transforme edildiğini , ödeme işleme modelinin ve fatura-satır-dağıtım yapısının değiştiğini, vergi kurulumlarının tümüyle farklılaştığını görüyoruz. Eğer canlı geçiş sonrası kötü sürprizlerle karşılaşmamak istiyorsanız test sistemlerinin üzerinde yapacağınız R12 veri analizleri ile mevcut mali kayıtların nerelerde deforme olabileceğini tespit etmeniz ve düzeltme çalışmalarınızı öncesinde planlayıp canlı geçiş sonrasında direk uygulamanız gerektiğini söylemeliyiz. Ayrıca üretim modüllerini kullanan firmalar için sistemde R12 maliyet yönetimi ayağının doğru modellendirilmesi ve ayrı bir önem verilmesi gerekiyor.