Özel Yazılım Projesine Başlamadan Önce İhtiyaç Analizi Nasıl Yapılır?

Bir ERP sistemiyle e-ticaret sitesi arasında sipariş aktarımı yapmak teknik olarak mümkün olabilir. Asıl mesele, hangi sipariş bilgisinin hangi sistemde oluşacağı, nerede değiştirilebileceği ve bir hata olduğunda sürecin nasıl devam edeceğidir. İhtiyaç analizi bu sorular cevaplanmadan tamamlanmış sayılmaz.

Özel yazılım ve entegrasyon projelerinde ilk görüşmeler çoğu zaman “Netsis ile web sitesini bağlayalım”, “stoklar otomatik güncellensin” veya “siparişler ERP’ye düşsün” gibi taleplerle başlar. Bunlar proje hedefini tarif eder; teknik gereksinimi değil.

Yazılım ekibinin geliştirmeye başlayabilmesi için hedefin veri, iş kuralı, yetki, güvenlik ve hata senaryolarına ayrılması gerekir.

Önce sistemleri değil, veri akışını çıkarın

İhtiyaç analizinin en kullanışlı çıktılarından biri veri akış haritasıdır.

Örneğin ERP ile e-ticaret sistemi arasında entegrasyon kurulacaksa yalnızca “stok aktarılacak” demek yeterli değildir. Şunların belli olması gerekir:

• Stok miktarının ana kaynağı hangi sistem?

• E-ticaret sitesi stok bilgisini ne sıklıkla alacak?

• Depo bazında ayrı stok tutulacak mı?

• Rezerve edilmiş ürünler kullanılabilir stoktan düşülecek mi?

• İptal edilen sipariş stoğu ne zaman geri açacak?

• Ürün kodları iki sistemde aynı mı?

• Bir üründe varyant varsa ERP tarafında hangi kayıtla eşleşecek?

• ERP’ye erişilemezse e-ticaret sitesi satışa devam edecek mi?

Bu sorular stok entegrasyonu için bile kapsamın ne kadar hızlı büyüyebildiğini gösterir. Sipariş, müşteri, fiyat, kampanya, fatura, kargo ve tahsilat bilgileri eklendiğinde veri akışının yazılı hale getirilmesi zorunlu hale gelir.

Her veri grubu için en azından kaynak sistem, hedef sistem, aktarım yönü ve güncelleme kuralı belirlenmelidir.

Örneğin ürün açıklamasının e-ticaret panelinden, fiyatın ERP’den yönetilmesi mümkündür. Bu durumda iki sistemde de aynı alanın değiştirilmesine izin vermek yerine hangi sistemin o bilgi için ana kaynak olduğu açıkça tanımlanır.

Aksi halde entegrasyon çalışır, fakat veriler bir süre sonra birbirini ezmeye başlar. Teknik olarak başarılı görünen aktarım operasyonel olarak güvenilmez hale gelir.

“Hangi alan nereye gidecek?” sorusunu kayıt bazında cevaplayın

Entegrasyonlarda sık karşılaşılan sorunlardan biri sistemlerin aynı kavramı farklı veri modelleriyle tutmasıdır.

Bir e-ticaret platformunda müşteri tek bir kayıt ve birden fazla adres olarak tutulabilir. ERP tarafında cari kart, teslimat adresi, vergi bilgileri ve ilgili başka tablolarda farklı kayıt yapıları bulunabilir. Sipariş durumları da birebir eşleşmeyebilir.

Bu nedenle ihtiyaç analizinde alan eşleştirme tablosu hazırlanması yararlıdır.

Örneğin:

Netsis kullanılan projelerde bu çalışma daha da önem kazanır. Stok, cari, fatura ve entegrasyon işlemleri farklı tablolar ve ilişkiler üzerinden yürür. Piasoft’un Netsis tabloları ve açıklamaları rehberi, hangi veri gruplarının hangi Netsis tablolarıyla ilişkili olduğunu incelemek isteyen ekipler için teknik bir başlangıç noktası sunar.

Alan eşleştirmesi geliştirme başladıktan sonra yapılırsa proje sırasında sürekli yeni istisnalar çıkar. Analiz aşamasında hazırlanırsa geliştirici hangi veriyi okuyacağını, nasıl dönüştüreceğini ve nereye yazacağını baştan bilir.

İş kurallarını yazılım ekibinin tahmin etmesine bırakmayın

Verinin bir sistemden diğerine aktarılması genellikle işin kolay kısmıdır. Zor olan, aktarım sırasında hangi kuralların uygulanacağıdır.

Bir sipariş ERP’ye gönderilirken şu sorular ortaya çıkabilir:

Siparişteki ürün ERP’de yoksa ne olacak?

Müşteri daha önce ERP’de açılmışsa mevcut cari kart mı kullanılacak?

Aynı e-posta adresine fakat farklı vergi numarasına sahip kayıt gelirse yeni müşteri mi oluşturulacak?

Sipariş sonradan değişirse mevcut ERP belgesi güncellenecek mi, yoksa yeni işlem mi oluşturulacak?

Fiyat e-ticaret sisteminden mi alınacak, ERP yeniden mı hesaplayacak?

İskonto ve kupon tutarları ERP’ye hangi şekilde aktarılacak?

Bunlar yazılım mimarisiyle çözülecek sorular değildir. İşletmenin çalışma biçimini tarif eden kurallardır. Proje sorumluları, operasyon ekibi ve yazılım ekibi aynı masada bunları netleştirmelidir.

İyi bir ihtiyaç analizi ekran listesinden çok karar listesine benzer.

Gerçek zamanlı aktarım her zaman gerekli değildir

Entegrasyon denildiğinde bütün verilerin anında senkronize edilmesi gerektiği düşünülebilir. Bu tercih teknik maliyeti ve sistem bağımlılığını artırabilir.

Bazı bilgiler gerçek zamana yakın çalışmalıdır. Özellikle satışa açık stok veya sipariş işlemleri buna ihtiyaç duyabilir.

Bazı veriler ise belirli aralıklarla aktarılabilir. Ürün açıklamaları, kategori bilgileri veya bazı raporlama verileri için birkaç dakikalık ya da daha uzun gecikme operasyon açısından sorun yaratmayabilir.

Buradaki karar “API var mı?” sorusundan önce verilmelidir:

Bu veri kaç dakika gecikirse iş süreci bozulur?

Cevap aktarım yöntemini belirlemeye yardımcı olur.

Anlık işlemlerde API veya olay tabanlı yapılar tercih edilebilir. Büyük veri kümeleri için zamanlanmış toplu işlemler daha uygun olabilir. Bazı projelerde ikisinin birlikte kullanılması gerekir.

Tek bir entegrasyon yöntemini bütün veri türlerine zorla uygulamak gereksiz karmaşıklık yaratabilir.

API olup olmadığını öğrenmek yetmez

İki sistemin de API sunması entegrasyonun doğrudan yapılabileceği anlamına gelmez.

İhtiyaç analizinde ilgili API'lerin gerçekten gereken işlemleri destekleyip desteklemediği kontrol edilmelidir. Okuma yapılabiliyor ama kayıt oluşturulamıyor olabilir. İstenen alan API tarafından dışarı açılmamış olabilir. İstek sınırları operasyonun hacmini karşılamayabilir.

Ayrıca şu teknik ayrıntılar incelenmelidir:

• Kimlik doğrulama yöntemi

• Kullanılabilecek servis uçları

• İstek ve yanıt veri yapıları

• Sayfalama yöntemi

• İstek limitleri

• Zaman aşımı davranışı

• API sürümleri

• Test ortamının bulunup bulunmadığı

• Webhook veya benzeri bildirim desteği

• Hata kodları ve hata açıklamaları

Hazır API bulunmayan eski veya kuruma özel sistemlerde doğrudan veritabanı erişimi, ara servis ya da farklı bir entegrasyon katmanı gerekebilir. Böyle bir yaklaşım seçilecekse sistem üreticisinin desteklediği yöntemler ve veri bütünlüğü riskleri ayrıca değerlendirilmelidir.

Hata senaryosu tasarlanmamış entegrasyon tamamlanmış değildir

ERP geçici olarak kapandı.

İnternet bağlantısı kesildi.

API isteği zaman aşımına uğradı.

Ürün kodu bulunamadı.

Aynı sipariş iki kez gönderildi.

Müşteri kaydındaki zorunlu alan boş geldi.

Bunların hiçbiri olağan dışı senaryolar değildir. Entegrasyonun gerçek çalışma koşullarıdır.

İhtiyaç analizinde yalnızca başarılı akış çizilirse yazılım ilk problemde insan müdahalesine bağımlı hale gelir.

Her kritik işlem için şu üç konu belirlenmelidir:

Hata nasıl fark edilecek?

İşlem otomatik olarak tekrar denenecek mi?

Düzeltilemeyen kayıt kimin önüne düşecek?

Özellikle sipariş ve finansal işlem entegrasyonlarında tekrar deneme mekanizması dikkatli tasarlanmalıdır. Ağ hatası nedeniyle cevabı alınamayan bir istek gerçekte ERP tarafından işlenmiş olabilir. Aynı isteğin kontrolsüz tekrar gönderilmesi ikinci bir sipariş veya belge oluşturabilir.

Bu nedenle bazı işlemlerde benzersiz işlem kimliği, mükerrer kayıt kontrolü ve idempotent çalışma mantığı gerekir.

Log tutmak ile izlenebilir bir sistem kurmak aynı şey değildir

“Log tutacağız” ifadesi ihtiyaç analizinde tek başına fazla bir şey söylemez.

Operasyon ekibinin gerçekten ihtiyacı olan şey çoğu zaman şudur:

Bir sipariş neden ERP’ye gitmedi?

Hangi saatte denendi?

ERP ne cevap verdi?

Daha önce başarılı aktarılmış mıydı?

Kullanıcı tekrar gönderebilir mi?

Sonradan yapılan müdahaleyi kim yaptı?

Bunları cevaplayamayan bir kayıt sistemi, geliştiricinin teknik hata ayıklamasına yardımcı olabilir fakat işletmenin günlük operasyonunu yönetmesine yetmez.

Kritik entegrasyonlarda işlem geçmişi, hata mesajı, kaynak kayıt numarası, hedef kayıt numarası, işlem zamanı ve durum bilgisi izlenebilir olmalıdır. Gerekiyorsa operasyon ekibinin başarısız işlemleri görebileceği ve yetkisi dahilinde tekrar çalıştırabileceği bir yönetim ekranı hazırlanır.

Yayın sonrasında bu izlenebilirlik daha da değerli hale gelir. Piasoft’un bakım ve destek yaklaşımında taleplerin ve yapılan işlemlerin kayıt altına alınarak takip edilebilir biçimde yönetildiği belirtiliyor. Bakım & Destek hizmetleri

Güvenlik ihtiyaç analizinde başlamalı

Entegrasyon tamamlandıktan sonra güvenlik kontrolü yapmak geç kalınmış bir yaklaşımdır.

Hangi sistemin hangi sisteme erişeceği proje başında belirlenmelidir. Entegrasyon hesabının gereksiz yetkilere sahip olmaması, erişim bilgilerinin kod içine açık biçimde yazılmaması ve mümkün olan yerlerde sistemler arasındaki iletişimin şifreli bağlantılar üzerinden yapılması gerekir.

Ayrıca hangi verilerin taşındığı önemlidir.

Müşteri bilgileri, adresler, telefon numaraları, finansal bilgiler veya ticari kayıtlar sistemler arasında aktarılıyorsa bu verilerin kimler tarafından görülebileceği ve log kayıtlarında ne kadarının tutulacağı ayrıca tasarlanmalıdır.

Bir başka konu yetkilendirmedir. Operasyon kullanıcısının başarısız siparişi yeniden gönderebilmesi mantıklı olabilir; entegrasyon ayarlarını veya ERP bağlantı bilgilerini değiştirebilmesi gerekmeyebilir.

Teknik kullanıcı, yönetici ve operasyon kullanıcısı aynı yetki seviyesinde tasarlanmamalıdır.

Operasyon ekibini analize dahil etmeden süreç çıkarmayın

Sistemin nasıl çalışması gerektiğini yalnızca yöneticilerden veya bilgi işlem ekibinden dinlemek eksik bir resim çıkarabilir.

ERP’de sipariş açan, stok düzelten, fatura kontrol eden veya e-ticaret panelinden sipariş yöneten kişiler sürecin günlük istisnalarını bilir.

Örneğin teoride bütün ürünlerin stok kodları eşleşiyor olabilir. Operasyonda ise yıllardır kullanılan bazı ürünler farklı kodlarla açılmış olabilir.

Kağıt üzerindeki süreçte bütün müşterilerin vergi bilgileri eksiksiz görünebilir. Gerçek siparişlerde bireysel müşteriler ve şirketler farklı kayıt kurallarına ihtiyaç duyabilir.

Bu ayrıntılar proje geliştirilirken ortaya çıktığında kod değişir, veri modeli değişir ve test senaryoları genişler. Analiz sırasında ortaya çıktığında ise proje kapsamının doğal bir parçası olur.

Test senaryolarını geliştirmeden önce yazın

Test aşaması yalnızca “sipariş ERP’ye geçti mi?” kontrolünden oluşmamalıdır.

Normal işlemlerin yanında sınır ve hata senaryoları da ihtiyaç analizinden çıkarılabilir:

• Yeni müşteri sipariş verdiğinde ne oluyor?

• Mevcut müşteri farklı adres kullandığında ne oluyor?

• ERP’de bulunmayan ürün sipariş edilirse ne oluyor?

• Aynı sipariş ikinci kez gönderilirse ne oluyor?

• Sipariş iptal edildiğinde ERP kaydı nasıl etkileniyor?

• Bağlantı aktarım sırasında kesilirse işlem hangi durumda kalıyor?

• Çok sayıda kayıt aynı anda geldiğinde sistem nasıl davranıyor?

• ERP bakımdayken gelen işlemler kayboluyor mu, kuyruğa mı alınıyor?

Test senaryolarının erken hazırlanması başka bir sorunu da ortaya çıkarır: Tanımlanamayan test çoğu zaman tanımlanamamış gereksinime işaret eder.

“Bu durumda sistem ne yapmalı?” sorusuna cevap verilemiyorsa geliştiricinin de doğru davranışı kendiliğinden bilmesi beklenemez.

Canlıya geçiş de ihtiyaç analizinin parçasıdır

Entegrasyonun geliştirilmiş olması canlı sisteme doğrudan bağlanabileceği anlamına gelmez.

İlk veri aktarımı nasıl yapılacak?

Mevcut ürünler tekrar oluşturulacak mı, eşleştirilecek mi?

Geçmiş siparişler taşınacak mı?

Canlıya geçiş sırasında ERP veya e-ticaret sistemi kısa süreli durdurulacak mı?

Eski entegrasyon varsa hangi anda kapatılacak?

Yeni sistemde sorun çıkarsa geri dönüş planı nedir?

Bu kararlar son güne bırakıldığında teknik ekip veri temizleme ve eşleştirme işlemlerini canlı ortam baskısı altında yapmak zorunda kalabilir.

Özellikle mevcut sistemin yıllardır kullanıldığı ERP projelerinde önce veri kalitesi görülmelidir. Aynı müşterinin birden fazla cari kartı, eksik ürün kodları veya artık kullanılmayan kayıtlar entegrasyon sırasında kendiliğinden ortadan kalkmaz.

Entegrasyon çoğu zaman mevcut veri problemlerini çözmekten çok görünür hale getirir.

İhtiyaç analizi sonunda ne ortaya çıkmalı?

Her proje aynı dokümana ihtiyaç duymaz. Küçük bir entegrasyon için yüzlerce sayfalık analiz hazırlamak işi daha doğru hale getirmez. Fakat geliştirmeye başlanırken ekip şu konularda belirsizlik yaşamamalıdır:

• Hangi sistemlerin bağlanacağı

• Hangi verilerin aktarılacağı

• Her veri için ana kaynağın hangi sistem olduğu

• Aktarım yönleri

• Alan ve kod eşleştirmeleri

• İş kuralları

• Aktarım sıklığı

• API ve diğer teknik bağlantı koşulları

• Yetkilendirme modeli

• Güvenlik gereksinimleri

• Hata ve tekrar deneme davranışları

• Log ve izleme yapısı

• Test senaryoları

• Canlıya geçiş yöntemi

• Bakım ve destek sorumlulukları

Buradaki amaç doküman üretmek değil, geliştirme sırasında verilecek kritik kararları geliştirmeden önce vermektir.

Piasoft da proje yaklaşımını ihtiyaç analiziyle başlatıp teknik planlama, uygulama, test, yayın ve sonrasındaki bakım süreciyle devam eden bir yapı olarak tanımlıyor. Mevcut dijital altyapının ve iş hedeflerinin proje başında incelenmesi, özellikle ERP, Netsis, e-ticaret ve özel web yazılımlarının birlikte çalışacağı projelerde kapsamın gerçek ihtiyaçlara göre kurulmasını sağlıyor. Piasoft özel yazılım ve proje yaklaşımı

Başarılı bir entegrasyonda mesele A sistemindeki kaydı B sistemine göndermek değildir. Doğru verinin doğru kaynaktan alınması, kurallara uygun işlenmesi, güvenli biçimde taşınması ve bir problem çıktığında işlemin nerede kaldığının görülebilmesidir.

Piasoft; ihtiyaç analizinden veri modeli ve entegrasyon mimarisinin oluşturulmasına, özel yazılım geliştirmeden test, canlıya geçiş ve yayın sonrası desteğe kadar süreci uçtan uca planlayıp uygulayabilir.