İK Yazılımı ve Seyahat Yönetimi: Personel Verisini Seyahat Sistemine Aktarmak

İnsan kaynakları (İK) yazılımı şirketin personel kaydını tutar; seyahat yönetimi ise bu kaydı kullanarak kimin hangi kurallarla seyahat edebileceğine karar verir. İki sistem birbirinden habersiz çalıştığında departman değiştiren kişi eski yöneticisine onay gönderir, ayrılan çalışanın hesabı açık kalır, bütçe yanlış birime yazılır. Aşağıda hangi verinin aktarılması gerektiğini, entegrasyon seçeneklerini ve Kurumsal.pro portalındaki karşılığını bulacaksınız.

Seyahat yönetimi İK'dan hangi veriye ihtiyaç duyar?

Seyahat sisteminin ihtiyaç duyduğu çekirdek veri azdır: ad, soyad, iş e-postası, departman, yönetici, unvan ve sistemdeki rol. Bordro, izin bakiyesi veya performans verisi seyahat kararına girmez. Bu küçük veri seti doğru olduğunda onay, politika ve bütçe kendiliğinden doğru kişiye ve birime bağlanır.

Bu alanların her birinin seyahat tarafında bir işlevi vardır:

Pasaport, doğum tarihi veya sadakat kartı gibi yolculuğa özgü bilgiler İK sisteminden çok, personelin kendi seyahat profilinden gelir. Bu ayrım hem veri doğruluğu hem de KVKK açısından önemlidir: İK, seyahat sistemine yalnız işlevi olan alanları vermelidir.

İK ile seyahat sistemi neden kopuk kalır?

Kopukluğun temel nedeni, iki sistemin farklı ekipler tarafından ve farklı takvimle güncellenmesidir. İK bir terfiyi ya da departman değişikliğini aynı gün işler; seyahat sistemindeki kayıt ise biri hatırlayana kadar eski hâliyle kalır. Sonuç, yanlış kişiye giden onay talebi ve yanlış birime yazılan harcamadır.

İzin ve seyahat çakışması da bu kopukluğun bir görünümüdür: izinli bir çalışana seyahat planlanması, bilginin tek bir yerde toplanmamasından kaynaklanır. Yaygın belirtiler şunlardır:

• Departman değiştiren çalışanın talepleri eski yöneticisine gider.
• Ayrılan çalışanın hesabı aylarca açık kalır.
• Aynı kişi iki farklı e-postayla iki kez kayıtlı olur.
• Raporlarda departman adları tutarsız yazıldığı için harcama bölünür.

Bu sorunların hepsi, personel listesinin tek bir kaynaktan ve düzenli aralıklarla aktarılmasıyla büyük ölçüde azalır.

İK entegrasyonu hangi yöntemlerle kurulur?

İK verisi seyahat sistemine üç yoldan biriyle taşınır: sistemler arası API entegrasyonu, SCIM gibi standart bir dizin eşitleme protokolü ya da dönemsel dosya aktarımı. İlk ikisi anlık eşitleme sağlar ama her iki tarafta da desteklenmesi gerekir; dosya aktarımı ise her İK yazılımında çalışır.

• API entegrasyonu: İK yazılımı ile seyahat sistemi arasında özel olarak geliştirilen bağlantı. Esnektir ama her İK ürünü için ayrı iş gerektirir.
• SCIM: Kimlik bilgilerini farklı sistemler arasında taşımak için tanımlanmış, HTTP tabanlı açık bir protokoldür (IETF, RFC 7644, Eylül 2015). Kimlik sağlayıcısı kullanıcıyı açar, günceller, kapatır; hedef sistem bu çağrıları karşılayan bir uç nokta sunmalıdır.
• Dosya aktarımı: İK yazılımından alınan personel listesi seyahat sisteminin şablonuna dökülüp yüklenir. Anlık değildir ama kurulumu kolaydır ve denetlenebilir bir kayıt bırakır.

Hangi yöntemin seçileceği kadronun büyüklüğüne, değişim sıklığına ve İK yazılımının dışa aktarma imkânlarına bağlıdır.

Kurumsal.pro portalında İK entegrasyonu var mı?

Hayır. Kurumsal.pro portalında SAP SuccessFactors, Workday, BambooHR, Logo J-HR, Oracle veya başka bir İK yazılımıyla hazır entegrasyon yoktur; SCIM uç noktası ve LDAP / Active Directory eşitlemesi de bulunmaz. Personel verisi firma yöneticisinin Excel ile yaptığı toplu yüklemeyle ya da tek tek davetle portala girer.

Portal izin verisini almaz; izin ile seyahatin çakışması, onay akışındaki yöneticinin değerlendirmesine kalır. Politika ve bütçe ise personelin portaldaki güncel departmanına, kademesine ve kişisel kaydına göre uygulanır; bu yüzden kaydın güncel tutulması önemlidir.

SSO (tek oturum açma) da portalda yoktur; personel e-posta ve şifreyle, iki adımlı doğrulamayla veya geçiş anahtarıyla (passkey) giriş yapar. Ayrıntı için SSO sözlük maddesine bakabilirsiniz.

Excel ile toplu personel aktarımı nasıl çalışır?

Firma yöneticisi portaldan personel şablonunu indirir, İK listesini şablona döker ve yükler. Portal dosyayı hemen yazmaz; önce yeni, güncellenecek ve hatalı satırları ve oluşturulacak yeni departmanları gösteren bir doğrulama raporu üretir. Yönetici raporu onaylayınca kayıtlar işlenir. Tek dosyada en çok 5.000 satır yüklenebilir.

Şablonun sütunları ad, soyad, e-posta, departman, yönetici e-postası, roller ve unvandır. Doğrulama sırasında şu kontroller yapılır:

• Ad, soyad ve e-posta boş olamaz; e-posta geçerli biçimde olmalıdır.
• E-posta, kurum için tanımlı iş alan adlarından birine ait olmalıdır.
• Aynı e-posta dosyada iki kez geçemez ve başka bir kurumda kayıtlı olamaz.
• Yönetici e-postası dosyada ya da kurumda bulunmalıdır.
• Rol adları kurumda tanımlı rollerle eşleşmelidir.

Hatalı satırlar ayrı bir hata dosyası olarak indirilebilir; düzeltilip yeniden yüklenir. Portalda olmayan departmanlar raporda "yeni departman" olarak görünür ve onayda oluşturulur. Ayrıntılı ekranlar için firma yöneticisi paneli sayfasına bakabilirsiniz.

İK değişiklikleri portala nasıl yansıtılır?

En pratik yöntem, İK listesini dönemsel olarak yeniden yüklemektir. Aynı e-postayla zaten kayıtlı olan kişiler raporda "güncellenecek" olarak işaretlenir; yeni gelenler eklenir. Böylece İK yazılımından alınan güncel liste, ayda bir ya da büyük organizasyon değişikliklerinden sonra portala taşınabilir. Yükleme öncesindeki doğrulama raporu, hangi kayıtların değişeceğini önceden gösterir.

Tek kişilik değişiklikler için personel detayı kullanılır. Firma yöneticisi buradan departman, unvan, yönetici, unvan kademesi, varsayılan fatura profili ve rolleri düzenler. Hesap işlemleri de aynı ekrandadır: kilidi açma, daveti yeniden gönderme, iki adımlı doğrulamayı sıfırlama, hesabı kapatma ve yeniden açma.

İşten çıkışta dikkat edilmesi gereken nokta şudur: hesabı ileri bir tarihte otomatik kapatan bir zamanlama yoktur. Ayrılan kişinin hesabı, ayrılık anında yönetici tarafından kapatılmalıdır. Bu adımı İK'nın çıkış kontrol listesine eklemek, açık kalan hesap riskini azaltır.

Yolcu profili ile portal hesabı arasındaki fark nedir?

Her personelin portala giriş yapması gerekmez. Davet sırasında "hesap açma, yalnız yolcu profili oluştur" seçeneğiyle kişi yalnız yolcu olarak kaydedilir; onun adına rezervasyonu yetkili bir çalışan yapar. Portal hesabı ise kişinin kendi girişini, kendi aramasını ve kendi taleplerini mümkün kılar.

Bu ayrım, sahada çalışan ya da seyrek seyahat eden personel için kullanışlıdır. İK listesinin tamamını portal hesabına dönüştürmek yerine yalnız seyahat eden ve rezervasyon yapan kişilere hesap açmak hem davet trafiğini hem de yönetilecek hesap sayısını azaltır. Personel portala kendiliğinden üye olamaz; her hesabı kurum yöneticisi ya da acente açar.

İK verisi doğru olunca onay ve politika nasıl çalışır?

Yönetici alanı doğruysa onay talebi kendiliğinden doğru kişiye gider; akış tanımlı değilse portal talebi yolcunun yöneticisine, o yoksa departman yöneticisine gönderir. Departman ve kademe doğruysa doğru politika ve doğru bütçe uygulanır. İK verisinin kalitesi, seyahat kurallarının kalitesini doğrudan belirler. Bu nedenle yönetici ve departman alanları, aktarımda en çok özen gösterilmesi gereken sütunlardır.

Bu bağlantıyı somutlaştırmak için birkaç örnek:

1. Kurumda özel bir onay akışı tanımlı değilse, yönetici e-postası eksik yüklenen bir kişinin talebi departman yöneticisine düşer.
2. Unvan kademesi tanımlanmamış bir çalışana kademe politikası uygulanmaz; varsa departman, şube veya kurum politikası devreye girer.
3. Yanlış departmana bağlanan bir kişinin harcaması o departmanın bütçesinden düşülür ve raporlarda orada görünür.

Onay akışının kademe tasarımı için seyahat onay sistemi, çok şirketli yapılarda kurum ağacının kurulması için holdinglerde seyahat yönetimi yazısına bakabilirsiniz.

İK verisini aktarırken KVKK açısından nelere dikkat edilir?

Seyahat sistemine yalnız seyahat kararında işlevi olan alanlar aktarılmalıdır. İK yazılımındaki maaş, izin bakiyesi veya sağlık bilgisi gibi verilerin seyahat sistemine taşınmasına gerek yoktur. Az veri aktarmak hem hata yüzeyini hem de korunması gereken veri miktarını küçültür. Aktarım listesini İK ile birlikte belirlemek, gereksiz alanın hiç taşınmamasını sağlar.

Portal tarafında personel kaydındaki Kimlik No maskeli tutulur ve salt okunurdur; davet kabulünde KVKK onayı istenir. Pasaport ve sadakat kartı gibi yolculuk bilgileri personelin kendi profilinde saklanır. Güvenlik önlemlerinin ayrıntısı güvenlik sayfasında, yolcu verisinin hukuki çerçevesi ise kurumsal seyahatte KVKK yazısında anlatılır.

Acenteniz Kurumsal.pro altyapısıyla kurumsal portal sunuyorsa, personel aktarımı kurulumun ilk adımlarından biridir. Portalı canlı görmek için demo talep edebilirsiniz.