Kuruma Özel Onay Akışları: Hazır Ürünü Süreçlerinize Uyarlamak

Kurumsal bir yazılım seçerken neredeyse her ekipten aynı cümle duyulur: “Bizim süreçlerimiz biraz farklı.” Bu çoğu zaman doğrudur. Satın alma talebinin hangi tutarın üzerinde genel müdüre çıktığı, bir izin talebinin hangi birimlerde ayrıca İK onayı gerektirdiği ya da bir dokümanın hangi klasörde kimin onayından geçtiği kurumdan kuruma değişir. Soru, bu farklılıkların hazır bir ürünle nasıl karşılanacağıdır.

Bu yazıda kuruma özel onay akışlarını ele almanın pratik bir yolunu anlatıyoruz: önce hazır ürünün sunduğu esnekliği sonuna kadar kullanmak, sonra gerçekten karşılanamayan ihtiyaçları özel geliştirme ya da entegrasyonla kapatmak.

“Bizim sürecimiz farklı” cümlesinin üç anlamı

Kurumların süreçlerinin farklı olduğu söylendiğinde aslında üç farklı durumdan biri kastedilir. Bunları ayırt etmek, doğru çözümü seçmenin ilk adımıdır:

Durum	Örnek	Genellikle doğru çözüm
Ayar farkı	Onay zincirinde kaç adım olacağı, adımlarda kimin yer alacağı	Ürünün mevcut ayarlarıyla tanımlamak
Alışkanlık farkı	Yıllardır kullanılan bir formun alan sırası ya da adlandırması	Süreci sadeleştirip ürünün akışına uyum sağlamak
Gerçek süreç farkı	Standart modüllerin hiç karşılamadığı, kuruma özgü bir iş akışı	Özel geliştirme ya da entegrasyon

Deneyim gösteriyor ki “farklı” denen ihtiyaçların önemli bir kısmı ilk iki gruba girer. Bunları özel geliştirmeyle çözmeye çalışmak, maliyeti ve bakım yükünü gereksiz yere artırır. Gerçek süreç farkları ise özel geliştirme için doğru adaylardır.

Adım 1: Mevcut süreci olduğu gibi çizin

Uyarlamaya başlamadan önce, sürecin bugün gerçekte nasıl işlediğini yazıya dökün; prosedür belgesinde yazdığı gibi değil, uygulamada olduğu gibi. Her onay akışı için şu soruları cevaplayın:

• Talebi kim başlatıyor ve hangi bilgilerle?
• Hangi adımlarda kim onay veriyor? Bu kişiler bir unvana mı, bir birime mi, yoksa belirli bir kişiye mi bağlı?
• Reddedilen ya da geri gönderilen talep nereye dönüyor?
• Hangi durumlarda ek bir onay adımı devreye giriyor?
• Süreç sonunda hangi kayıt kalıyor ve kim tarafından görülüyor?

Bu çalışma çoğu zaman kendi başına değerlidir: aynı sürecin iki birimde farklı uygulandığı, bazı onay adımlarının artık hiçbir işe yaramadığı ya da kimsenin sahiplenmediği adımlar olduğu bu aşamada ortaya çıkar.

Adım 2: Hazır ürünün sunduğu esnekliği haritalayın

İyi bir kurumsal ürün, onay akışlarında belirli bir esneklik sunar. Hazır ürünün neleri ayarla karşıladığını görmek için çizdiğiniz süreci ürünün sunduğu seçeneklerle eşleştirin. Örneğin HibritİK’te onay akışları modüle göre farklı biçimlerde tanımlanır:

• Görevler: Yöneticisi tanımlı bir görev tamamlandığında onay bekleyen duruma geçer; yönetici onaylar ya da gerekçesini yazarak geri gönderir. Test eden atanmışsa görev teste gider ve sonuç Başarılı ya da Başarısız olarak kaydedilir. Alt görevlerin onay durumu üst göreve otomatik yansır.
• İzin talepleri: Onay, departman ağacınızdaki yöneticilerden ilerler; isteğe bağlı bir İK adımı eklenebilir.
• Kalite dokümanları: Revizyonlar klasör bazında tanımlanan onay zincirinden geçer.
• Proje ve araç talepleri: Tanımladığınız çok adımlı onay zincirinden ilerler.

Tüm bu akışlarda her adımda ilgili kişi bildirim alır ve onay geçmişi kayıtta kalır. Onay bekleyen işler merkezi bir onay kuyruğunda toplanır ve toplu olarak onaylanabilir. Ayrıntılar için onay ve test süreçleri sayfasına göz atabilirsiniz.

Adım 3: Gerçek boşlukları ayırın

Eşleştirme sonunda elinizde üç liste olmalı: ürünün doğrudan karşıladıkları, küçük bir süreç sadeleştirmesiyle karşılanabilecekler ve gerçekten karşılanamayanlar. Üçüncü listedeki her madde için şu soruları sorun:

1. Bu ihtiyaç ne sıklıkla ortaya çıkıyor? Yılda birkaç kez yaşanan bir istisna için özel geliştirme yerine manuel bir adım yeterli olabilir.
2. Bir mevzuat ya da denetim gereksinimine mi dayanıyor? Öyleyse önceliği yüksektir.
3. Başka bir sistemle veri alışverişi mi gerektiriyor? Öyleyse ihtiyaç aslında bir entegrasyon ihtiyacı olabilir.
4. Kuruma özgü yeni bir süreç mi? Standart modüllerin hiç kapsamadığı bir iş akışıysa, özel modül geliştirme gündeme gelir.

Adım 4: Entegrasyon mu, özel modül mü?

Gerçek boşluklar genellikle iki yoldan biriyle kapatılır:

Entegrasyon

Onay akışının bir parçası başka bir sistemde yaşıyorsa, örneğin onaylanan bir talebin muhasebe ya da başka bir kurum sistemine aktarılması gerekiyorsa, çözüm çoğu zaman bir entegrasyondur. HibritİK, REST API üzerinden diğer uygulamalarınızla konuşabilir. Her entegrasyon için ayrı bir entegrasyon hesabı ve API anahtarı tanımlanır; anahtar yalnızca kendisine verilen rolün izinleriyle çalışır, böylece entegrasyonun erişebileceği veri baştan sınırlanır. Mevcut sistemlerinizle veri alışverişini hazır bir bağlayıcı olarak değil, ihtiyacınıza göre planlanan bir entegrasyon projesi olarak yürütürüz.

Özel modül

Standart modüllerin hiç karşılamadığı, kuruma özgü bir süreç söz konusuysa kurumunuza özel bir modül geliştirilebilir. Bu yaklaşımın avantajı, yeni sürecin kullanılan diğer modüllerle aynı ürün içinde yer almasıdır; çalışanların bu iş için ayrı bir araç aramasına gerek kalmaz.

Özel geliştirme projesini doğru yürütmek

Özel geliştirmenin başarısı çoğu zaman kod yazılmadan önce belirlenir. HibritİK’te özel geliştirme ve entegrasyon projeleri üç adımda ilerler:

1. İhtiyacı belirleyelim: Hangi sistemlerle hangi verinin, hangi yönde aktarılacağını ya da yeni sürecin hangi adımlardan oluşacağını birlikte netleştiririz.
2. Erişimi tanımlayalım: Entegrasyon gerekiyorsa, yalnızca gerekli izinlere sahip bir entegrasyon hesabı ve API anahtarı oluşturulur.
3. Geliştirip devreye alalım: Entegrasyon ya da özel modül geliştirilir, test edilir ve kullanıma açılır.

Kurum tarafında ise şu noktalara dikkat etmek projeyi kolaylaştırır:

• Süreç sahibini baştan belirleyin; ihtiyaç tanımında son sözü kimin söyleyeceği belli olsun.
• Kapsamı küçük tutun; önce en kritik akışı devreye alıp sonra genişletin.
• Test aşamasına gerçek kullanıcıları dahil edin; akışın sahada nasıl çalıştığını en iyi onlar görür.
• İstisnaları da tanımlayın; “bu durumda ne olacak?” sorusu, akışın en çok zorlandığı yerdir.

Pratik ipucu: Özel geliştirme talebinden önce ürünü kendi ekibinizle birkaç hafta standart akışlarla kullanın. Bu süre, gerçekten neye ihtiyacınız olduğunu ve neyin yalnızca alışkanlık olduğunu ayırt etmenin en güvenilir yoludur.

Sık yapılan hatalar

• Eski süreci birebir kopyalamak: Kâğıt üzerinde işleyen her adımın dijitalde de gerekli olduğunu varsaymak, gereksiz karmaşıklık yaratır.
• Her istisnaya ayrı akış kurmak: Nadir istisnalar için ayrı bir akış yerine, mevcut akışta açıklama ya da ek bir adımla çözüm aramak çoğu zaman yeterlidir.
• Entegrasyonlara geniş yetki vermek: Bir entegrasyonun yalnızca ihtiyaç duyduğu veriye erişmesi, güvenlik ve KVKK açısından temel bir ilkedir.
• Onay geçmişini önemsememek: Kimin ne zaman onay verdiği, denetimlerde ve anlaşmazlıklarda ilk bakılan kayıttır.

Sonuç: Önce uyum, sonra uyarlama

Kuruma özel onay akışları kurmanın en sağlıklı yolu, hazır ürünün sunduğu esnekliği önce sonuna kadar kullanmak, ardından gerçek boşlukları entegrasyon ya da özel modül geliştirmeyle kapatmaktır. Bu yaklaşım hem maliyeti hem de uzun vadeli bakım yükünü düşük tutar. Onay akışlarının temel tasarım ilkeleri için görev onay süreci yazımıza, entegrasyon ve özel geliştirme seçenekleri için entegrasyon ve özel geliştirme sayfamıza göz atabilirsiniz. Kurumunuza özel bir ihtiyacı konuşmak için bizimle iletişime geçin; standart akışları denemek için 14 gün ücretsiz deneyin.