İntranet entegrasyonları: ERP, İK sistemi ve webhook

Bir intranet tek başına dururken sınırlı değer üretir. Asıl fayda, şirketin diğer sistemleriyle konuşmaya başladığında ortaya çıkar: çalışan bilgisi İK sisteminden gelir, izin bakiyesi bordro sistemiyle eşleşir, yeni bir kişi işe girdiğinde hesabı otomatik açılır.

Ama entegrasyon, üzerinde düşünülmeden başlanınca en çok teknik borç üreten alandır.

Önce yön kararı

Her entegrasyonda ilk soru şudur: bu verinin kaynağı hangi sistem?

Tek bir kaynak belirlenmezse, iki sistemde farklı değerler oluşur ve hangisinin doğru olduğu tartışılır. Çalışan unvanı hem İK sisteminde hem intranette düzenlenebiliyorsa, ikisi kaçınılmaz olarak ayrışır.

Sağlıklı kural: her veri alanının tek bir sahibi olur, diğer sistemler onu okur, yazmaz.

Yaygın bir dağılım şöyledir:

• İK sistemi: kimlik, unvan, departman, yönetici, işe giriş tarihi
• Kimlik dizini: hesap durumu, gruplar, erişim yetkileri
• İntranet: içerik, iletişim, talep akışları, takdir
• ERP: maliyet merkezi, satın alma, envanter

Senkronizasyon sıklığı

Gerçek zamanlı entegrasyon kulağa iyi gelir ama her zaman gerekli değildir. Çalışan bilgisinin gecelik senkronize edilmesi çoğu şirket için yeterlidir ve çok daha basittir.

Gerçek zamanlı olması gereken tek durum, güvenlikle ilgili değişikliklerdir: bir çalışan işten çıkarıldığında erişiminin ertesi güne kadar açık kalması kabul edilemez.

İki yönlü entegrasyonun tuzağı

İki sistemin birbirine yazması, çakışma ihtimali doğurur: aynı kayıt iki yerde aynı anda değişirse hangisi kazanır?

Bu sorunun cevabı baştan verilmezse, veri kaybı sessizce oluşur. Mümkün olan her yerde tek yönlü akış tercih edilmelidir; iki yönlü akış gerçekten gerekli olduğunda çakışma kuralı yazılı olmalıdır.

Webhook nedir?

Webhook, bir olay gerçekleştiğinde bir sistemin diğerine haber vermesidir. Sürekli sorgulamanın (polling) tersidir: "bir şey oldu mu?" diye sormak yerine, olduğunda haber gelir.

İntranet tarafında tipik kullanımlar: yeni bir talep oluşturulduğunda ERP'ye bildirim, bir onay tamamlandığında muhasebeye kayıt, kritik bir olayda operasyon sistemine uyarı.

Webhook imzalanmalıdır

Webhook adresini öğrenen herkes, o adrese sahte olay gönderebilir. Alıcı sistemin "bu gerçekten beklediğim kaynaktan mı geldi" sorusunu cevaplayabilmesi gerekir.

Standart çözüm, gövdenin paylaşılan bir sırla imzalanması ve imzanın bir başlıkta taşınmasıdır. Alıcı aynı hesabı yapar ve imzalar tutuyorsa isteği kabul eder.

İki ayrıntı önemlidir. İmza sırrı arayüzden okunabilir olmamalıdır: yönetici sırrı yazabilmeli ama geri okuyamamalıdır; aksi hâlde tarayıcıya inen bir sır, sır olmaktan çıkar. İkincisi, sırrın değiştirilebilir olmasıdır — sızma şüphesinde yenilenebilmelidir.

Teslim garantisi ve tekrar deneme

Ağ her zaman çalışmaz. Alıcı sistem kapalıysa ya da geçici hata verdiyse, olayın kaybolmaması gerekir.

Sağlam bir kurgu şunları içerir: gönderilecek olayların bir kuyrukta tutulması, başarısız denemelerin artan aralıklarla tekrarlanması, belirli bir deneme sayısından sonra hata olarak işaretlenmesi ve son hatanın kayda geçmesi.

Son madde teşhis için kritiktir: "gitmedi" bilgisi yeterli değildir, neden gitmediği yazılmalıdır.

Hazır bağlayıcılar mı, özel geliştirme mi?

Zapier ve benzeri otomasyon platformları, kod yazmadan entegrasyon kurmayı mümkün kılar. Küçük hacimli ve kritik olmayan akışlar için hızlı bir çözümdür.

Yüksek hacimli, hassas veri taşıyan ya da düşük gecikme gerektiren akışlarda doğrudan entegrasyon daha uygundur. Aracı bir platform, hem ek bir arıza noktası hem de verinin üçüncü bir taraftan geçmesi demektir.

Test ve izleme

Entegrasyonların en büyük riski, sessizce durmasıdır. Gece senkronizasyonu üç haftadır çalışmıyorsa ve kimse fark etmiyorsa, veri sessizce eskir.

Bu yüzden her entegrasyonun bir sağlık göstergesi olmalı: son başarılı çalışma zamanı, işlenen kayıt sayısı ve hata sayısı görünür olmalıdır. Bir eşiğin altına düştüğünde uyarı üretmesi, sorunun haftalar sonra değil aynı gün fark edilmesini sağlar.

Kimlik tarafındaki entegrasyonları kimlik ve dizin entegrasyonu ve SSO nedir yazılarında ayrıntılandırdık.

Kimlik eşleme sorunu

Entegrasyonların en sık takıldığı yer, aynı kişinin farklı sistemlerde farklı kimliklerle durmasıdır: İK sisteminde sicil numarası, dizinde kullanıcı adı, ERP'de personel kodu.

Bu üçünü birbirine bağlayan bir eşleme tablosu olmadan entegrasyon kurulamaz. Eşlemenin e-posta üzerinden yapılması yaygın ama kırılgandır: soyadı değişikliği ya da benzer isimler sorun çıkarır.

En sağlam yöntem, İK sistemindeki değişmeyen sicil numarasını ana anahtar kabul etmek ve diğer sistemlere bu alanı taşımaktır. Bu karar baştan verilmezse, her yeni entegrasyonda yeniden tartışılır.

Hata durumunda ne olacak?

Entegrasyon tasarımının en çok atlanan kısmı hata senaryolarıdır. Kaynak sistem bir kaydı yanlış gönderirse, hedef sistem ne yapmalı?

İki yaklaşım vardır: hatalı kaydı atlayıp devam etmek ya da bütün işlemi durdurmak. Doğru seçim veriye bağlıdır — tek bir çalışanın telefon numarası hatalıysa devam etmek makul, yetki bilgisi hatalıysa durmak gerekir.

Her iki durumda da hatanın görünür olması şarttır. Sessizce atlanan kayıtlar, aylar sonra "bu kişi neden sistemde yok" sorusuyla ortaya çıkar.

Test ortamı gerçekten gerekli

Entegrasyonlar üretim verisiyle test edilemez: yanlış bir senkronizasyon yüzlerce kaydı bozabilir ve geri alınması zordur.

Ayrı bir test ortamı ve gerçekçi ama anonimleştirilmiş test verisi, bu riski ortadan kaldırır. Test verisinde gerçek kişisel bilgi kullanılmaması ayrıca bir KVKK gerekliliğidir.

Belgeleyin

Entegrasyonlar, kuran kişinin ayrılmasıyla en çok riske giren varlıklardır. Hangi sistem hangi veriyi hangi sıklıkla nereye gönderiyor — bunun yazılı olmadığı bir kurumda, bir yıl sonra kimse dokunmaya cesaret edemez.

Basit bir tablo yeterlidir: kaynak, hedef, veri, yön, sıklık, sorumlu. Bu tablonun güncel tutulması, entegrasyon mimarisinin bakımını mümkün kılar.