Önerimiz kısaca şöyle. Access uygulamanızı tek seferde yeniden yazmaya çalışmayın. Önce ne olduğunu çıkarın, veriyi temizleyin, sonra parça parça taşıyın ve eski sistemle yeni sistemi bir süre yan yana çalıştırın. Bu yaklaşım daha yavaş görünür ama işi durdurmaz ve sürpriz riskini ciddi şekilde düşürür.
Access, birçok şirkette "geçici çözüm" olarak başlar. Bir çalışan birkaç tablo ve form hazırlar, iş büyür, uygulama da büyür. On yıl sonra şirketin siparişi, stoku veya hakedişi o dosyanın içinde döner. Kimse dokunmaya cesaret edemez.
Access uygulaması ne zaman sorun olmaya başlar?
Şu işaretlerden birkaçı tanıdık geliyorsa modernizasyon zamanı gelmiştir:
- Aynı anda birkaç kişi çalışınca dosya kilitleniyor veya bozuluyor.
- Uygulama sadece ofisteki belirli bilgisayarlardan açılabiliyor.
- Uzaktan çalışan ekip veya sahadaki personel sisteme erişemiyor.
- VBA kodunu yazan kişi şirketten ayrıldı ve kimse kodu tam anlamıyor.
- Yetkilendirme yok; herkes her veriyi görebiliyor ve değiştirebiliyor.
- Veriler Excel'e aktarılıp elle birleştiriliyor.
- Dosya boyutu sınıra yaklaşıyor ve sıkıştırma rutini aksarsa sorun çıkıyor.
Adım 1: Envanter çıkarın
Taşıyamayacağınız şeyi bilmeden plan yapamazsınız. İlk adım, uygulamanın tam bir fotoğrafını çekmektir. Bu aşamada şu soruların cevabını yazılı hâle getirin:
- Tablolar: Kaç tablo var, hangileri hâlâ kullanılıyor, hangileri bağlı (linked) tablo?
- Sorgular: Hangi sorgular iş kuralı içeriyor? Access'te iş mantığı çoğu zaman sorgulara gömülüdür.
- Formlar ve raporlar: Hangileri günlük kullanılıyor, hangileri yıllardır açılmadı?
- VBA kodu ve makrolar: Hesaplama, doğrulama ve otomasyon nerede yapılıyor?
- Dış bağlantılar: Excel dosyaları, muhasebe yazılımı, e-posta veya dosya klasörleriyle bağlantılar var mı?
- Kullanıcılar: Kim, hangi ekranı, hangi sıklıkla kullanıyor?
Envanterin en değerli kısmı kullanıcı görüşmeleridir. Kod size sistemin ne yaptığını söyler. Kullanıcılar ise sistemin etrafında hangi elle yapılan işleri biriktirdiklerini söyler. Bu "gölge süreçler" yeni sistemde en büyük kazanç alanıdır.
Adım 2: Veri modelini temizleyin
Access veritabanları yıllar içinde dağınık hâle gelir. Aynı müşteri farklı yazımlarla birkaç kez kayıtlıdır. Tarih alanları metin olarak tutulmuştur. İlişkiler tanımlanmamış, bütünlük kuralları yoktur.
Taşımadan önce veri modelini yeniden tasarlayın:
- Tekrarlanan kayıtları tespit edin ve birleştirme kurallarını iş birimiyle belirleyin.
- Alan tiplerini düzeltin. Tarih alanı tarih, tutar ondalık, kod metin tipinde olsun.
- Tablolar arası ilişkileri ve yabancı anahtarları açıkça tanımlayın.
- Kullanılmayan alan ve tabloları arşivleyin, yeni modele taşımayın.
- Veri taşıma betiklerini tekrar çalıştırılabilir yazın. Taşımayı defalarca deneyeceksiniz.
Hedef veritabanı olarak PostgreSQL, SQL Server veya MySQL gibi gerçek bir veritabanı sunucusu kullanın. Bazı ekipler ilk adım olarak sadece tabloları sunucuya taşır ve Access'i ön yüz olarak bırakır. Bu, geçiş sürecinde faydalı bir ara basamak olabilir.
Adım 3: Hedef mimariyi seçin
Modern bir web uygulaması tarayıcıdan çalışır, merkezi bir sunucuda durur ve rol bazlı yetkilendirme sunar. Teknoloji seçimi ekibinizin ve bakım yapacak kişilerin yetkinliğine göre yapılmalıdır. Java, PHP (Symfony gibi), .NET veya başka bir olgun platform olabilir. Önemli olan uzun vadeli destek, iyi dokümantasyon ve bulunabilir geliştiricidir. On yıl sonra da bakımı yapılabilecek bir teknoloji seçin. Bir teknolojinin moda olması tek başına seçim nedeni olmamalı.
Adım 4: Strangler yaklaşımıyla parça parça taşıyın
"Strangler fig" (boğan incir) deseni, eski sistemi tek seferde kapatmak yerine işlevleri tek tek yeni sisteme taşımaktır. Yeni sistem büyüdükçe eski sistem küçülür ve sonunda devre dışı kalır.
Pratikte şöyle ilerler:
- Önce yüksek değerli ama görece bağımsız bir modül seçin. Örneğin müşteri kartları veya sipariş girişi.
- Bu modülü yeni web uygulamasında yazın ve ortak veritabanına bağlayın.
- Kullanıcıları o işlev için yeni ekrana yönlendirin; geri kalan işleri Access'te yapmaya devam etsinler.
- Bir sonraki modüle geçin. Raporlar ve nadir kullanılan ekranlar genellikle en sona kalır.
Bu yaklaşımın en büyük faydası, her adımda çalışan bir sistem olmasıdır. Bütçe veya öncelik değişse bile elinizde kısmen modernleşmiş ve çalışan bir sistem kalır.
Adım 5: Paralel çalıştırın ve sonuçları karşılaştırın
Kritik hesaplamalar içeren modüllerde, örneğin fiyatlandırma, hakediş veya stok maliyeti, yeni sistemi bir süre eskisiyle paralel çalıştırın. Aynı girdiyle iki sistemin ürettiği sonuçları karşılaştırın. Fark çıktığında çoğu zaman eski sistemde kimsenin bilmediği bir kural bulursunuz. Bu kuralı belgeleyin ve korunacak mı, düzeltilecek mi, bilinçli olarak karar verin.
İpucu: Paralel çalıştırma dönemini baştan sınırlayın ve bitiş kriterini yazılı hâle getirin. "Birkaç ay deneriz" diye başlayan paralel dönemler uzar, ekip iki sisteme birden veri girmekten yorulur.
Paralel dönemde veri girişini de planlayın. Mümkünse kullanıcılar sadece yeni sisteme veri girsin ve eski sisteme veri otomatik olarak aktarılsın. Böylece çift veri girişi yükü ortadan kalkar ve karşılaştırma daha güvenilir olur.
Adım 6: Kullanıcıları erkenden dahil edin ve eğitin
Teknik açıdan sorunsuz bir geçiş, kullanıcılar benimsemezse başarısız olur. Access ile yıllarca çalışmış biri için klavye kısayolları, ekran düzeni ve alışkanlıklar önemlidir.
- Her departmandan bir "anahtar kullanıcı" belirleyin ve tasarım sürecine katın.
- Eğitimi genel sunum yerine kullanıcının kendi günlük işi üzerinden yapın.
- Kısa ekran kayıtları ve tek sayfalık rehberler hazırlayın.
- Canlıya geçişten sonraki ilk haftalarda hızlı destek kanalı açın.
Gerçek bir örnek: Ares Vida
Vida ve bağlantı elemanı üreticisi Ares Vida'nın yıllardır kullandığı Access tabanlı iş uygulamasını modern bir Java web uygulamasına taşıdık. Bu projede yukarıdaki adımların neredeyse tamamını uyguladık. Önce mevcut tablo, sorgu ve formların envanterini çıkardık ve kullanıcılarla görüştük. Ardından veri modelini yeniden tasarladık, taşıma betiklerini tekrar çalıştırılabilir yazdık ve modülleri öncelik sırasına göre devreye aldık.
Bu projeden çıkardığımız en net ders, asıl iş kurallarının sorgularda ve kullanıcıların alışkanlıklarında saklı olmasıydı. VBA kodu bu kuralların ancak bir kısmını gösteriyordu. Bunları ortaya çıkarmadan yazılan her ekran, tekrar yazılmak zorunda kalırdı. Envantere ve kullanıcı görüşmelerine harcanan zaman, projenin geri kalanında katlanarak geri döndü.
Raporlar ve Excel çıktıları ne olacak?
Access uygulamalarında raporlar çoğu zaman en çok kullanılan kısımdır ve en son düşünülen kısım olur. Yönetim her ay aynı raporu bekler, muhasebe belirli bir Excel çıktısına göre çalışır. Taşıma planında raporları ayrı bir iş kalemi olarak ele alın. Hangi raporun hâlâ okunduğunu kullanıcılara sorun. Bazıları yıllardır kimsenin bakmadığı alışkanlıklardır. Gerekli olanları yeni sistemde ya ekran içi raporlar olarak ya da standart bir raporlama aracıyla yeniden kurun. Excel çıktısına bağımlı süreçler için geçiş döneminde aynı formatta dışa aktarım sunmak, kullanıcıların uyumunu ciddi şekilde kolaylaştırır.
Zamanlamayı nasıl planlamalısınız?
Modernizasyonun süresi uygulamanın büyüklüğüne, veri kalitesine ve iş biriminin ayırabileceği zamana bağlıdır. Bu yüzden tek bir tarih vermek yerine aşamalı bir plan yapın. Envanter ve veri analizi ilk aşamadır ve sonraki tüm tahminlerin temelini oluşturur. Ardından ilk modül gelir; bu modül hem teknik altyapıyı hem de ekibin birlikte çalışma biçimini sınar. Sonraki modüller genellikle daha hızlı ilerler. Yoğun dönemlerinizi, örneğin yıl sonu kapanışını veya sezon başlangıcını, canlıya geçiş takviminden uzak tutun.
Sık yapılan hatalar
- Eski ekranları birebir kopyalamak. Taşıma, süreci iyileştirmek için bir fırsattır.
- Veriyi temizlemeden taşımak. Kirli veri yeni sistemde de kirli kalır.
- Her şeyi tek seferde canlıya almak. Geri dönüş planı olmayan büyük geçişler en riskli olanlardır.
- Kullanıcıları sadece test aşamasında hatırlamak.
Özet
Access'ten modern bir web uygulamasına geçiş, bir yazılım projesinden çok bir iş projesidir. Envanterle başlayın, veriyi temizleyin, strangler yaklaşımıyla parça parça taşıyın, kritik modülleri paralel çalıştırın ve kullanıcıları en baştan dahil edin. 2004'ten beri yürüttüğümüz projelerde aynı sonucu görüyoruz. Sabırla planlanan geçişler, aceleyle yapılan büyük yeniden yazımlardan hem daha hızlı hem daha ucuz sonuçlanıyor.