TREN
Teklif al

Yazılım entegrasyonu teklifinde hangi sorular sorulmalı?

İki sistemi bağlamak için teklif alırken veri yönü, ürün eşlemesi, hata yönetimi ve bakım sorumluluğunu netleştirin. İşletmeler için entegrasyon rehberi.

Güven Göç
Kurucu, Kariha
· 4 dk okuma

“İki program birbirine bağlanacak” cümlesi, aynı işi tarif eden iki teklif aldığınız anlamına gelmez. Bir ekip yalnızca müşteri listesini aktarırken diğeri sipariş durumlarını ve başarısız işlemleri de yönetiyor olabilir. Teklifleri karşılaştırabilmek için ekran sayısından önce veri akışını ve sorumlulukları netleştirin.

Hangi işin tamamlanmasını istiyorsunuz?

Entegrasyon ihtiyacını program isimleriyle değil, bugün tekrar eden işlemle anlatın. Örneğin web formundan gelen bilgiler muhasebe sisteminde yeniden yazılıyor olabilir. Burada hedef, yalnızca iki uygulama arasında bağlantı kurmak değil, doğru bilgiyi doğru kayda ulaştırarak tekrar girişi azaltmaktır.

İşin başlangıcını ve bitişini tanımlayın. Başvuru alındığında müşteri mi açılacak, satış onaylandığında sipariş mi oluşacak? İşlem tamamlanınca kullanıcı bunu nerede görecek? Bitişi belli olmayan bir kapsamda bağlantının çalıştığı söylenebilir, fakat işletmenin ihtiyacı hâlâ karşılanmamış olabilir.

Teklif isteyen kişiyle sistemi kullanacak kişiyi aynı örnekte buluşturun. Yönetim rapor beklerken çalışan veri girişindeki tekrardan şikâyet ediyor olabilir. Bu iki ihtiyaç aynı entegrasyonla karşılanabilir; ancak ikisinin de açıkça tarif edilmesi gerekir.

Hangi veri hangi yönde aktarılacak?

“Çift yönlü entegrasyon” tek başına yeterli açıklama değildir. Müşteri adı, adres, sipariş durumu, ürün fiyatı ve stok gibi alanlar için kaynak belirleyin. Her bilginin iki tarafta düzenlenmesi gerekmeyebilir. Hangi alanın hangi sistemde yönetileceği yazılı olmalıdır.

Örneğin ürün açıklaması web ekibi tarafından hazırlanıyorsa muhasebe tarafındaki kısa tanım bu metni ezmemelidir. Fiyat muhasebede belirleniyorsa web panelinde yapılan geçici değişikliğin ne olacağı konuşulmalıdır. Bu kurallar verilmeden otomatik aktarım başlatmak, düzenli çalışan bir veri çatışması yaratabilir.

Teklifte bir alan eşleme tablosu isteyin. Kaynak alan, hedef alan, dönüşüm kuralı ve zorunluluk durumu görülsün. Tarih biçimi veya para birimi gibi ayrıntılar bile yanlış eşlendiğinde işletme hatasına dönüşebilir. Teknik ekibin bu ayrıntıları gerçek örneklerle doğrulaması gerekir.

Mevcut sistem gereken erişimi sunuyor mu?

Bir yazılımın API sunması, ihtiyacınız olan bütün işlemleri açtığını göstermez. Gerekli alan okunabiliyor mu, yeni kayıt oluşturulabiliyor mu ve güncelleme için hangi yetki gerekiyor? Dokümantasyon, test hesabı ve sağlayıcı koşulları değerlendirilmeden kesin uygulama sözü verilmemelidir.

İstek sınırları, lisans koşulları ve erişim süreleri kapsamı etkileyebilir. Örneğin yalnızca belirli aralıklarla veri alınabiliyorsa bunu “her değişiklik anında aktarılır” diye sunmak doğru olmaz. Bağlantının gerçek davranışı kullanıcı beklentisiyle birlikte açıklanmalıdır.

Erişim başka sağlayıcıya bağlıysa kimin iletişim kuracağı belli olsun. Test hesabını müşterinin açması, geliştiricinin talep etmesi veya ayrı yetkilendirme gerekmesi takvimi değiştirebilir. Bu bağımlılıkları teklifin dışında görünmez bırakmayın.

Kayıtların aynı kişiye veya ürüne ait olduğu nasıl anlaşılacak?

Müşteri adı ve ürün adı güvenilir tekil kimlikler olmayabilir. Aynı isimli iki kişi veya farklı yazılmış aynı ürün bulunabilir. Teklifte eşleme anahtarını ve mükerrer kayıt davranışını sorun. Yanlış kişiye bağlanan doğru veri, yine yanlış sonuç üretir.

Eski verilerde eksik kimlikler varsa bir hazırlık işi gerekebilir. Örnek bir dosya üzerinde aktarım denemesi yapın ve sorunları listeleyin. Hangi kayıtları işletmenin temizleyeceği, hangi dönüşümün yazılımla yapılacağı açık olsun. Veri temizliği ile bağlantı geliştirmesi aynı iş kalemi değildir.

Veri kapsamı, kimlik eşlemesi, hata yönetimi ve kabul senaryolarını içeren entegrasyon teklif kontrolü

Hata olursa işlem nerede bekleyecek?

Bağlantının başarılı senaryosu kadar başarısız senaryosu da tarif edilmelidir. Hedef sistem yanıt vermediğinde kayıt kaybolacak mı, sırada mı bekleyecek, tekrar mı denenecek? Kullanıcının sorunu anlayabileceği durum bilgisi ve ilgili kişinin görebileceği hata kaydı bulunmalıdır.

Aynı bildirim tekrar geldiğinde çift kayıt oluşmaması da önemlidir. İşlemin daha önce tamamlandığı nasıl anlaşılacak? Yeniden deneme hangi koşulda güvenli? Bu ayrıntıları müşterinin uygulaması gerekmez; fakat teklifte bunların ele alındığını görmesi gerekir.

Hata kaydının içinde gereksiz hassas veriler tutulmamalıdır. Sorunu incelemek için yeterli işlem kimliği ve açıklama tercih edilebilir. Kayıtların kim tarafından görüleceği ve ne kadar tutulacağı uygulamanın veri ve işletim ihtiyaçlarıyla uyumlu belirlenmelidir.

Kabul testinde hangi örnekler bulunacak?

En az bir normal işlem, bir eksik veri durumu ve bir bağlantı hatası seçin. Konuya göre iptal, iade veya aynı kaydın güncellenmesi de eklenebilir. Her senaryoda iki sistemde beklenen sonucu yazın. Sadece “bağlantı kuruldu” bildirimi teslim kabulü için yeterli değildir.

Ödeme veya stok gibi sonuç doğuran işlemleri uygun test ortamında deneyin. Gerçek ortamda deneme gerekiyorsa işletmenin belirlediği yöntem kullanılsın. Amaç kontrolsüz işlem üretmek değil, tanımlı senaryonun güvenilir biçimde tamamlandığını göstermektir.

Testin sonucunu hangi kişinin onaylayacağını belirleyin. Teknik bağlantıyı geliştirici kontrol edebilir; fakat oluşan kaydın operasyon açısından doğru olduğunu günlük kullanıcı da değerlendirmelidir. Tarih, tutar veya durum bilgisi ekranda görünse bile iş kuralı yanlış uygulanmış olabilir. Teslim kaydında denenen senaryoların ve bekleyen istisnaların bulunması bu ayrımı görünür kılar.

Bakım ve değişiklik sorumluluğu kimde?

Bağlanan sistemin alanı, erişim yöntemi veya sürümü değişebilir. Böyle bir durumda izleme, müdahale ve ücretlendirme koşulları baştan konuşulmalıdır. İlk geliştirme bedeli, sınırsız gelecek uyarlamasını kendiliğinden kapsamaz. Aynı şekilde teslimden sonra kimsenin izlemediği bağlantı da sağlıklı bir işletim düzeni değildir.

Teklifte kurulum, test, veri hazırlığı, dokümantasyon ve destek kalemlerini ayrı görün. Kapsamı dar teklif bazen ihtiyacı tam karşılar; daha uzun teklif ise gereksiz işler içeriyor olabilir. Değerlendirmeyi kalem sayısıyla değil, tanımlanan işin tamamlanmasıyla yapın.

Stok ve sipariş bağlantısını özel olarak düşünüyorsanız e-ticaret stok entegrasyonu rehberi gerçek senaryoları netleştirmeye yardımcı olur. Kariha’nın özel yazılım hizmetinde entegrasyonu veri ve operasyon akışıyla ele alıyoruz. Bağlamak istediğiniz sistemleri ve bugün tekrar ettiğiniz işlemi bize anlatın; karşılaştırılabilir bir kapsam hazırlayalım.