Sözleşme talep uygulaması: Hukuk ekipleri için pratik bir tasarım

Sözleşme talepleri neden gecikir?

Sözleşme işleri çoğu zaman bir avukatın şartları inceleyememesi yüzünden durmaz. Gecikme, inceleme başlamadan önce, talep «Bu sözleşmeye bakabilir misin?» gibi kısa bir e-postayla geldiğinde başlar. Taslak daha sonra sohbet uygulamasında paylaşılır, son tarih başka bir mesaja gömülür ve şirket içindeki iletişim kişisi Hukuk ekibinin nadiren kontrol ettiği bir elektronik tabloda kalır.

Bu dağınık kayıt gereksiz yazışmalara yol açar. Hukuk ekibi anlaşmadan kimin sorumlu olduğunu, karşı tarafın beklentisini, bir imza tarihi sözü verilip verilmediğini ve hangi belge sürümünün incelenmesi gerektiğini sormak zorunda kalır. Özellikle farklı saat dilimlerinde çalışan ekiplerde her yanıt bir gün sürebilir.

Bir sözleşme talep uygulaması, biri yardım istediği anda gerekli bilgileri toplar. Her talepte talep sahibi, iş sorumlusu, sözleşme türü, karşı taraf, istenen tamamlanma tarihi, mevcut taslak, destekleyici dosyalar ve alışılmışın dışındaki koşullar yer almalıdır. Bunlara veri güvenliği eki veya standart şartların dışındaki bir ödeme planı örnek verilebilir.

Tutarlılık, hukuk ekiplerinin önce hangi işleri inceleyeceğine karar vermesine yardımcı olur. Yarın müşteri imzası gereken bir satış sözleşmesinin önceliği, kesin son tarihi olmayan erken aşamadaki bir tedarikçi taslağından farklıdır. Talep sahipleri tarihin ne anlama geldiğini açıklamalıdır. Bu tarih imzalanmış bir taahhüt mü, satın alma son tarihi mi, yoksa yalnızca tercih edilen bir hedef mi?

Eksik belgeler de aynı türden gecikmelere neden olur. Talep sahibi bir iş kapsamı belgesi ekleyip bunun değiştirdiği ana hizmet sözleşmesini eklemeyebilir. Hukuk ekibi ya talebi durdurur ya da tam bağlam olmadan maddeleri inceler. Her iki seçenek de işi ilerletmez.

Sorumluluğun net olması da önemlidir. İş sorumlusu ticari soruları yanıtlar, talep sahibi belgeleri sağlar ve hukuk incelemecisi inceleme kararından sorumludur. Roller belirsiz olduğunda «Bilgi bekleniyor» gibi bir sözleşme inceleme durumu günlerce değişmeden kalabilir.

Yapılandırılmış bir sözleşme talep formu her müzakereyi hızlandırmaz. Ancak sıradan taleplerin e-posta, sohbet ve elektronik tablolarda arama yapmaya dönüşmesini önler.

Kişileri ve devirleri eşleyin

Hukuk talep iş akışındaki herkesin açık bir rolü olmalıdır. Bir satış yöneticisi müşteri sözleşmesi gönderebilirken satın alma yöneticisi tedarikçi sözleşmesi isteyebilir. Hukuk ekibi şartları inceler, ek sorular sorar ve taslakları onaya gönderir. Bazı anlaşmaların imzalanmasından önce Finans, güvenlik veya bir yönetici onayı gerekebilir.

Uygulamayı oluşturmadan önce her sözleşme türünün normal yolunu belgeleyin. Basit bir tedarikçi sözleşmesi talep sahibinden Hukuk ekibine, oradan da satın almaya gidebilir. Büyük bir müşteri anlaşması ise Hukuk, Finans ve satış yöneticisinin incelemesini gerektirebilir. İş farklı olduğunda her talebi aynı zincirden geçirmeyin.

Talep sahibi bilgilerini hukuk incelemesi bilgilerinden ayrı tutun. Talep sahipleri şirket adı, sözleşme türü, istenen imza tarihi, anlaşma sorumlusu, değer ve karşı tarafın taslağı gibi iş bilgilerini sağlamalıdır. Hukuk ekibi atanan incelemeciyi, maddeyle ilgili endişeleri, risk düzeyini, müzakere notlarını ve onay kararlarını kaydetmelidir.

Bu ayrım, talep sahiplerinin Hukuk ekibinin işi yönetmek için kullandığı alanları değiştirmesini önler. Ayrıca biri bir sözleşmenin neden beklenenden uzun sürdüğünü sorduğunda ekibe tutarlı bir kayıt sunar.

Erişim, her kişinin yaptığı işe göre belirlenmelidir:

• Talep sahipleri talep oluşturabilmeli, eksik dosyaları ekleyebilmeli ve kendi sözleşmelerinin durumunu görebilmelidir.
• Hukuk incelemecileri kendilerine atanan işleri görebilmeli, inceleme alanlarını güncelleyebilmeli ve iş yükü değiştiğinde talepleri yeniden atayabilmelidir.
• Onaylayanlar sözleşmeyi, vermeleri gereken kararı ve bu kararla ilgili notları görebilmelidir.
• Hukuk operasyonları çalışanları formları, durumları ve atama kurallarını yönetebilmelidir.
• Yöneticiler sözleşme kayıtlarını değiştirmeden raporları görüntüleyebilmelidir.

Örneğin bir satış direktörünün açık müşteri sözleşmelerini ve ortalama inceleme süresini haftalık olarak görmesi gerekebilir. Müzakere notlarını görmesine veya bir talebi değiştirmesine gerek yoktur. Yalnızca rapor görüntüleme yetkisi, yanlışlıkla yapılan değişiklikleri sınırlar.

AppMaster ekiplerin bu rolleri kullanıcı izinleriyle modellemesine ve talep sahipleri, incelemeciler, onaylayanlar ve rapor görüntüleyiciler için ayrı ekranlar oluşturmasına olanak tanır. Devirleri gerçek sorumluluklara göre tasarlayın ve herkese yalnızca ihtiyaç duyduğu bilgileri gösterin.

İnsanların tamamlayabileceği bir form oluşturun

İlk ekran, talep sahiplerinin zaten bildiği bilgileri sormalıdır. Form, bir satış yöneticisinin, operasyon sorumlusunun veya kurucunun her yanıtın nasıl yazılacağını Hukuk ekibine sormadan tamamlayabileceği kadar kısa olmalıdır.

Sözleşme türü, iş sorumlusu, karşı tarafın adı ve istenen tamamlanma tarihiyle başlayın. Tedarikçi sözleşmesi, müşteri sözleşmesi, gizlilik sözleşmesi, değişiklik sözleşmesi veya diğer gibi kısa bir sözleşme türü listesi kullanın. İş sorumlusu, talep gönderildikten sonra ticari soruları yanıtlayabilmelidir.

Sade bir özet için daha geniş bir metin alanı ekleyin. Yararlı bir soru şudur: «Ne satın alıyor, satıyor veya üzerinde anlaşıyorsunuz ve Hukuk ekibinin neyi incelemesi gerekiyor?» Belge başlığı nadiren yeterli bağlam sağlar. «Üç aylık ürün lansmanı için bir tasarım ajansıyla çalışmak istiyoruz» ifadesi, «Ajans ana hizmet sözleşmesi» ifadesinden çok daha fazla bilgi verir.

Zorunlu alanları gerçekten gerekli kılın

Hukuk ekibi onsuz başlayamıyorsa bilgiyi zorunlu tutun. Karşı tarafın adı ve hedef tarih genellikle bu gruba girer. Ekip işi yönlendirmek veya maliyetleri raporlamak için kullanmıyorsa proje kodu zorunlu olmamalıdır.

Belge yüklemelerini açık biçimde yönetin. Talep sahiplerinden mümkün olduğunda sözleşme taslağını, değişiklikleri, iş kapsamı belgesini veya karşı tarafın e-postasını eklemelerini isteyin. Taslak ortaya çıkmadan önce gizlilik sözleşmesine ihtiyaç varsa, yükleme olmadan gönderime izin verin ve «Şirket şablonuna ihtiyacım var» seçeneğini sunun.

Basit bir sözleşme talep formunda şunlar bulunabilir:

• Sözleşme türü ve karşı taraf
• İş sorumlusu ve departman
• Hedef imza tarihi ve bu tarihin nedeni
• Sade dille talep özeti
• Mevcut belgeler veya şablon talebi

Hukuk terimleri yerine iş ihtiyaçlarını sorun

Çoğu talep sahibi iş ihtiyaçlarını anlar, ancak sorumluluğun sınırlandırılması veya veri işleme eki gibi terimlere aşina olmayabilir. Sade sorular kullanın. Anlaşmada kişisel veri, gizli bilgi, ödeme taahhüdü, fikri mülkiyet, otomatik yenileme veya ülke dışında çalışma bulunup bulunmadığını sorun.

Basit seçenekler sunun: evet, hayır veya emin değilim. Ayrıntılar için yorum alanı ekleyin. Bir yazılım tedarikçisinin talep sahibi kişisel veri için «evet» seçeneğini işaretleyip «Tedarikçi, müşteri destek taleplerini saklayacak» yazabilir. Hukuk ekibi böylece hangi maddelerin ve şirket içi incelemelerin gerektiğine karar vermek için yeterli bilgiye sahip olur.

Formu Hukuk ekibiyle nadiren çalışan iki veya üç kişiyle test edin. Nerede duraksadıklarını veya «diğer» seçeneğini nerede işaretlediklerini gözlemleyin. Yanıtları, form tüm şirkete açılmadan önce daha açık ifade edilmesi gereken etiketleri gösterir.

Madde ihtiyaçlarını açıkça kaydedin

Bir sözleşme talep uygulaması, Hukuk ekibi belgeyi açmadan önce madde taleplerini toplamalıdır. Genel bir yorum kutusu çoğu zaman yeterli ayrıntıyı vermez. Ayrı alanlar, talep sahiplerinin ihtiyaçlarını açıklamasına ve Hukuk ekibinin riskleri daha erken fark etmesine yardımcı olur.

Yaygın her konu için standart ifadeyi koruma, değişiklik isteme, maddeyi kaldırma veya madde ekleme seçenekleri sunun. Bu yapıyı gizlilik, sorumluluk, ödeme koşulları ve sözleşme süresi ya da yenileme için kullanın. Talep sahibi «Lütfen bunu daha esnek hale getirin» yazmak yerine belirli bir seçim yapabilir.

Örneğin bir satış yöneticisi ödeme koşullarında değişiklik isteyip şöyle yazabilir: «Müşterinin satın alma politikası 30 gün vadeye izin vermediği için 60 gün vade gerekiyor.» Hukuk ekibi hem istenen sonucu hem de iş gerekçesini görebilir.

Yalnızca değişikliği değil, nedeni de sorun

Biri standart dışı bir koşul istediğinde ticari ihtiyacın, son tarihin, müşteri beklentisinin veya bu isteğin arkasındaki politikanın kısa bir açıklamasını zorunlu tutun. Böylece temel bağlamı e-posta üzerinden tekrar tekrar istemek gerekmez.

Sade bir soru kullanın: «Bu maddenin neden değişmesi gerekiyor?» Makul bir karakter sınırı, kullanıcıların tüm e-posta yazışmasını yapıştırmak yerine yararlı bir açıklama yazmasını teşvik eder.

Hukuk incelemecileri önerilen pozisyon, onaylanmış alternatif, müzakere notları ve bekleyen onaylar için kendi alanlarına ihtiyaç duyar. Bunları talep sahibi notlarından ayrı tutun. Talep sahipleri net bir sonuç görmeli, şirket içi hukuk notlarına erişim ise sınırlı olabilir.

Rutin seçimleri istisnalardan ayırın

Çoğu sözleşme, kabul edilmiş az sayıda pozisyondan birini izler. Bu pozisyonları hukuk talep iş akışında seçilebilir hale getirin. Sorumluluk için talep sahibi standart üst sınırı, daha yüksek bir üst sınırı veya sınırsız sorumluluğu seçebilir. Uygulama, daha yüksek riskli seçimleri doğru incelemeciye yönlendirebilir.

Bu seçeneklerin dışındaki talepler için «Diğer veya olağandışı koşul» alanı kullanın ve açıklama ile gerekçe isteyin. Her talep serbest metin olarak gelirse raporlar güvenilirliğini kaybeder ve incelemeciler her başvuruyu sıfırdan okumak zorunda kalır.

Açık madde alanları hukuk işlem süresi raporlamasını da geliştirir. Ekipler, sorumluluk değişikliklerinin ödeme değişikliklerinden daha uzun sürüp sürmediğini veya tekrarlanan bir istisnanın gecikmeye neden olup olmadığını görebilir. Bu kanıt, çalışma kılavuzlarını, formları ve onay kurallarını güncellemeye yardımcı olur.

İnceleme durumunu takip etmeyi kolaylaştırın

Talep sahibinin görünümü iki soruya hızlıca yanıt vermelidir: Talep nerede ve bundan sonra ne olması gerekiyor? Açık bir sözleşme inceleme durumu, hukuk işini bölen takip e-postalarını azaltır.

Ekibin gerçek sürecine uyan az sayıda aşama kullanın. Çok fazla etiket, açıklık sağlamadan güncellemeleri zorlaştırır. Uygulanabilir bir sıra şöyledir:

• Gönderildi: Talep sahibi sözleşme talebini gönderdi.
• Talep incelemesi: Hukuk ekibi ayrıntıları kontrol eder ve talebi atar.
• İnceleniyor: Hukuk sorumlusu taslağı ve madde ihtiyaçlarını inceler.
• Bilgi bekleniyor: Hukuk ekibinin bir yanıta, belgeye veya iş kararına ihtiyacı var.
• Tamamlandı veya geri çekildi: Hukuk talebi tamamladı ya da talep sahibi talebi iptal etti.

Talep gelir gelmez bir hukuk sorumlusu atayın. Bu kişi her görevi tamamlamak zorunda değildir, ancak talebin ilerlemesini sağlamalıdır. Bir operasyon yöneticisi pazartesi günü tedarikçi sözleşmesi gönderip talep koordinatörü bunu Hukuk ekibinden Priya'ya atarsa, yönetici genel bir «Hukuk ekibi» durumu yerine adı belli bir sorumlu görür.

İncelemeci daha fazla bilgi istediğinde soruyu e-posta zincirinde bırakmak yerine sözleşme talep uygulamasına kaydedin. Soruyu, tarihi, yanıt vermesi gereken kişiyi ve sonraki adımı ekleyin. Talep sahibinin ne sağlaması gerektiğini tam olarak anlaması için durumu «Bilgi bekleniyor» olarak değiştirin.

Mevcut aşamayı ve sonraki adımı talep sayfasında birlikte gösterin. «İnceleniyor, Priya veri işleme şartlarını kontrol ediyor» ifadesi «Açık» ifadesinden daha anlaşılırdır. İş ekibinin bir sorumluluk pozisyonunu onaylaması gerekiyorsa bunu doğrudan söyleyin: «İş onayı bekleniyor, önerilen sorumluluk üst sınırının kabul edilebilir olup olmadığını onaylayın.»

Kısa bir etkinlik geçmişi, sorumluluk değiştiğinde veya talep beklenenden uzun sürdüğünde yardımcı olur. Atamaları, durum değişikliklerini ve bilgi taleplerini tarihleriyle kaydedin. Hukuk ekibi gecikmeleri kanıtlarla açıklayabilir, talep sahipleri de tahmin yürütmeden harekete geçebilir.

İş akışını adım adım kurun

Tek bir sözleşme talep formuyla başlayın ve formun tek bir talep kaydı oluşturmasını sağlayın. Aynı anlaşmayı e-posta zincirlerine, elektronik tablolara ve sohbet mesajlarına bölmeyin. Her talebe bir kimlik, sorumlu, gönderim tarihi ve mevcut durum verin.

İlk sürümü ekibinizin en sık kullandığı yol etrafında oluşturun. Basit bir akış Gönderildi, Ön değerlendirme, Atandı, İnceleniyor, İş bilgisi bekleniyor, Onaylandı ve Kapatıldı aşamalarından geçebilir. Talep sahiplerinin güncelleme istemeden anlayabilmesi için sade adlar kullanın.

Yönlendirme kurallarını form kaydı kaydettikten sonra oluşturun. Sözleşme türü, anlaşma değeri, iş alanı, bölge ve risk düzeyi çoğu zaman işi doğru kişiye göndermek için yeterlidir. Bir gizlilik sözleşmesi genel hukuk kuyruğuna, yüksek değerli bir tedarikçi sözleşmesi ise ticaret hukukundan sorumlu danışmana ve satın alma yetkilisine gidebilir.

Her aşamada adı belli bir sorumlu atayın. İş akışı bir incelemeci atadığında talep ayrıntılarını, istenen tarihi ve ekli belgeleri içeren bir bildirim gönderin. Hukuk ekibi çalışmaya başladığında, bilgi istediğinde veya incelemeyi tamamladığında talep sahibini bilgilendirin.

AppMaster formu, talep kaydını, iş kurallarını ve durum ekranını tek bir kodsuz uygulamada tutabilir. Görsel Business Process Editor, «Değer onay sınırını aşarsa kıdemli hukuk danışmanına gönder» gibi bir kararı ayrı bir betik yazmadan eşleyebilir.

Yayınlamadan önce gerçekçi talepleri tüm süreçte çalıştırın:

• Bilgileri eksiksiz, rutin bir gizlilik sözleşmesi
• Birkaç maddede değişiklik gerektiren bir tedarikçi sözleşmesi
• Yakın son tarihli acil bir satış sözleşmesi
• Eksik eki veya belirsiz iş sorumlusu olan bir talep
• Hukuk ve Finans ekiplerinin onayını gerektiren bir sözleşme

Bildirimleri kimlerin aldığını, yönlendirmenin doğru sorumluyu seçip seçmediğini ve durumların doğru zamanda değişip değişmediğini kontrol edin. Hem bir talep sahibinden hem de bir incelemeciden uygulamayı test etmesini isteyin. Uygulamayı oluşturan kişi için anlamlı görünen etiket veya durumların başkaları için anlaşılmaz olduğunu çoğu zaman bu kişiler fark eder.

Önce yaygın yolu kullanıma açın. İstisnaları, ekip uygulamayı kullandıktan ve taleplerin nerede yavaşladığını gördükten sonra ekleyin.

Örnek: tedarikçi sözleşmesi talebi

Bir satış yöneticisinin, 28 Haziran'daki müşteri kullanıma açılışından önce yeni bir analiz tedarikçisini devreye alması gerekir. Sözleşme talep uygulamasını açar ve «Tedarikçi sözleşmesi»ni seçer. Form tedarikçinin adını, iş sorumlusunu, planlanan harcamayı, veri erişimini ve işletmenin yanıt beklediği tarihi sorar.

Satın alma ekibinin satın alma siparişini hazırlayabilmesi için hedef tarih olarak 21 Haziran'ı girer. Madde talebi alanında «Sorumluluk üst sınırının en az 12 aylık ücrete çıkarılmasını isteyin» yazar. Tedarikçi taslağını yükler ve şirket içindeki Finans iletişim kişisini belirtir.

Uygulama LA-1842 numaralı talebi oluşturur, zaman damgası ekler ve durumu «Gönderildi» olarak belirler. Satış yöneticisi Hukuk ekibinin henüz çalışmaya başlamadığını görebilir. Hukuk ekibi iş bağlamını, istenen madde değişikliğini, taslağı ve son tarihi tek bir kayıtta alır.

Bir hukuk incelemecisi LA-1842'yi açar ve durumu «Bilgi bekleniyor» olarak değiştirir. Tedarikçi taslağında veri işleme eki bulunmadığı için incelemeci, yöneticiye bu eki kayıt üzerinden sorar. Yönetici belgeyi aynı öğleden sonra yükler. İncelemeci durumu «İnceleniyor» olarak değiştirir ve sorumluluk ifadelerinde değişiklik yapmaya başlar.

İki gün sonra Hukuk ekibi işaretlenmiş taslağı geri gönderir ve durumu «İnceleme tamamlandı» olarak belirler. Kayıt her durum değişikliğini, yorumu ve dosyayı birlikte tutar. Yönetici, Hukuk ekibinin işi tamamlayıp tamamlamadığını öğrenmek için e-posta zincirlerini aramak zorunda kalmaz.

Bir işlem süresi raporu LA-1842'nin 10 Haziran'da gönderildiğini ve 14 Haziran'da tamamlandığını, toplam sürenin dört iş günü olduğunu gösterebilir. Ayrıca eksik eki beklerken geçen süreyi de gösterebilir. Bu ayrım, hukuk inceleme süresini eksik taleplerden kaynaklanan gecikmelerden ayırır.

İşlem süresini raporlayın

Hukuk işlem süresi raporlaması yalnızca Hukuk ekibinin kaç talebi kapattığını değil, taleplerin nerede beklediğini de göstermelidir. Saati biri sözleşme talep formunu gönderdiğinde başlatın. İlk yanıt süresini, hukuk incelemecisinin belge talebi, risk notu veya incelemeye başlama onayı gibi anlamlı bir yanıt gönderdiğinde durdurun.

Toplam döngü süresini ayrı takip edin. Bu sayaç Hukuk ekibi talebi tamamlandı olarak işaretlediğinde, imza için geri gönderdiğinde veya başka açık bir nedenle kapattığında sona erer. Yalnızca ortalamaya güvenmeyin. Tedarikçi sözleşmelerinin çoğu dört günde tamamlanırken bazıları üç hafta sürüyorsa medyan, yöneticilere normal performans hakkında daha yararlı bir tablo sunar.

Her talebin aşağıdaki durumlarda geçirdiği süreyi kaydedin:

• Ön değerlendirme bekleyen gönderilmiş talepler
• Bir hukuk incelemecisine atanmış talepler
• İş bilgisi veya belge bekleyen talepler
• Hukuk incelemesindeki talepler
• Talep sahibine geri gönderilen veya imzaya hazır talepler

«İş bilgisi bekleniyor» durumunda altı gün kalan bir talep, hukuk kapasitesi sorununa işaret etmez. Durum geçmişi bu farkı görünür kılar. İncelemeci durumu değiştirdiğinde, sorumlu atadığında veya daha fazla ayrıntı istediğinde zaman damgası kaydedin.

Sonuç çıkarmadan önce filtreleri kullanın. İşlem süresini sözleşme türüne, talepte bulunan ekibe, atanan incelemeciye ve önceliğe göre karşılaştırın. Satın alma ekibi hızlı ilerleyen çok sayıda standart tedarikçi sözleşmesi gönderebilirken satış ekibi müzakere gerektiren müşteri belgeleri gönderebilir. Bu gruplar bağlam olmadan aynı hedefi paylaşmamalıdır.

Geri çekilen talepleri ayrı ele alın. Talep sahibi başka bir tedarikçi seçtiği için bir saat sonra talebi iptal edebilir. Bu kayıtları hacim ve iptal raporlaması için saklayın, ancak tamamlanan işlem süresi ortalamalarına dahil etmeyin. Bekletilen işler için de net bir kural koyun. Örneğin iş ekibi eksik bir güvenlik belgesini toplarken süreyi duraklatabilirsiniz.

AppMaster ekiplerin gönderim ve durum değişikliği zaman damgalarını veri modelinde saklamasına, iş süreçleriyle geçen süreyi hesaplamasına ve filtrelenmiş raporları şirket içi bir panoda göstermesine olanak tanır. Raporu her ay inceleyin ve taleplerin en çok zaman geçirdiği aşamayı ele alın.

Yaygın kurulum hataları

Bir sözleşme talep uygulaması, her çalışanı hukuk konusunda yeni başlayan bir kişiye dönüştürmemeli, yazışmaları azaltmalıdır. Yaygın bir hata, talep sahiplerinden risk değerlendirmesini, hukuk terimlerini veya sözleşmenin tüm yapısını açıklamasını istemektir. Çoğu kişi bu soruları iyi yanıtlayamaz ve yanıtlamak zorunda da olmamalıdır.

Bunun yerine iş bilgilerini sorun: karşı taraf kim, ne sağlayacak, beklenen değer nedir, son tarih nedir ve bir taslak gönderildi mi? Risk notları ve şirket içi analiz için Hukuk ekibine ayrı bir alan verin. Bir satış yöneticisi kapanış tarihini bilebilir, ancak sorumluluk üst sınırının değiştirilmesi gerekip gerekmediğini bilmeyebilir.

Serbest metin alanları başka bir sorun yaratır. Kullanıcılar kendi sözleşme türünü yazarsa bir ekip «NDA», diğeri «gizlilik» ve üçüncüsü «gizlilik formu» girebilir. Raporlar aynı işi birkaç etikete böler. Sözleşme türü, talep nedeni, öncelik ve sözleşme inceleme durumu için kontrollü listeler kullanın. Gerçek istisnalar için kısa açıklama alanı olan bir «Diğer» seçeneği bulundurun.

Biri talebi «Gönderildi»den «İnceleniyor»a veya «İş bilgisi bekleniyor»a taşıdığında önceki durumu silmeyin. Hukuk talep iş akışı, her değişikliğin kim tarafından ve neden yapıldığını, talebin neden durakladığını tarihli olarak kaydetmelidir. Bu geçmiş, basit bir soruyu yanıtlar: Hukuk ekibi üç gün boyunca tedarikçi taslağını mı bekledi, yoksa talep atanmadan mı kaldı?

Tarihleri iş yüküyle karşılaştırın

Talep sahibi acil bir son tarih seçebilir, ancak uygulama Hukuk ekibinin o tarihe kadar işi bitireceğini vaat etmemelidir. İstenen imza tarihi yararlıdır, ancak onaylanmış inceleme tarihinden farklıdır.

Hukuk çalışanlarının bir son tarih taahhüt etmeden önce mevcut atamaları kontrol etmesini sağlayın. Sözleşme talep uygulaması talep sahibinin hedef tarihini planlama sinyali olarak gösterebilir ve ön değerlendirmeden sonra üzerinde anlaşılmış inceleme son tarihini kaydedebilir. Pazartesi günü cuma imzası için bir talep geldiğinde ancak Finans'ın hâlâ bilgi sağlaması gerektiğinde uygulama, cuma gününü garanti gibi göstermek yerine bu bağımlılığı belirtmelidir.

Bu yaklaşım hukuk işlem süresi raporlamasını da daha dürüst hale getirir. Anlamlı aşamalar arasındaki süreyi ölçün ve hukuk incelemesinde geçen zamanı talep sahibinden veya başka bir departmandan yanıt beklenen zamandan ayırın. Aksi halde başka bir yerdeki yavaş onay süreci hukuk gecikmesi gibi görünebilir.

Yayından önce hızlı kontroller

Ekip uygulamaya güvenmeden önce kısa bir deneme yapın. Bir talep sahibinden, hukuk incelemecisinden ve yöneticiden gerçekçi talepler göndermesini ve işlemesini isteyin. Geri bildirimleri, uzun bir planlama toplantısından daha hızlı şekilde anlaşılması zor etiketleri ve eksik alanları ortaya çıkarır.

Her talebin adı belli bir sorumlusu ve bir son tarihi olmalıdır. İş kişiler arasında ilerledikçe sorumlu değişebilir, ancak uygulama her zaman mevcut sorumluyu göstermelidir. Açık sorumluluk olmadan genel bir kuyruk, sessiz gecikmelere davetiye çıkarır.

Talep sahiplerinin Hukuk ekibinin hâlâ neye ihtiyaç duyduğunu görebildiğinden emin olun. «Talep sahibinden yanıt bekleniyor» yardımcı olur, ancak eksik olanı açıklayan doğrudan bir görev veya mesaj ekleyin: tedarikçinin belgesi, sözleşme değeri, imza atan şirket veya hedef başlangıç tarihi.

Ekibinizin her gün kullandığı durum adlarını seçin. İncelemeciler «Paydaş işlemi bekleniyor» yerine «İş ekibinde» diyorsa «İş ekibinde» ifadesini kullanın. Liste, yeni bir talep sahibinin anlayabileceği kadar kısa olmalıdır.

Uygulanabilir bir durum listesi şöyledir:

• Yeni talep
• Hukuk ekibine atandı
• Talep sahibinden yanıt bekleniyor
• Hukuk incelemesinde
• İmzaya hazır

Aynı örnek talebi her durumdan geçirin. Sorumluluğun doğru zamanda değiştiğini, talep sahiplerinin amaçlanan güncellemeleri aldığını ve geçmişin her hareketi kaydettiğini doğrulayın. Eki olmayan bir talebi ve gerçekçi olmayan son tarihi olan bir talebi test edin.

Yayınlamadan önce hukuk işlem süresi raporlamasını inceleyin. Her rapor için, talep sahibinin eksiksiz talebi gönderdiği an gibi tek bir başlangıç tarihi belirleyin. Hukuk ekibinin incelemeyi tamamlandı olarak işaretlediği an gibi bir bitiş tarihi de belirleyin. Gönderimden imzaya kadar geçen süre ile gönderimden ilk yanıta kadar geçen süre farklı sorulara yanıt verir ve ayrı tutulmalıdır.

Sonraki adımları seçin

Hukuk ekibinizin en sık aldığı iki veya üç sözleşme türüyle başlayın. Bunlar tedarikçi sözleşmeleri, gizlilik sözleşmeleri ve müşteri şartları olabilir. Böylece ilk günden her hukuk senaryosunu kapsamaya çalışmadan talep sürecini test edecek yeterli hacme sahip olursunuz.

İlk sürümü incelemecilerin ilk karar için kullandığı ayrıntılar etrafında oluşturun: talep sahibi, iş sorumlusu, karşı taraf, sözleşme türü, hedef imza tarihi, değer, bölge ve madde talepleri. İsteğe bağlı alanları en aza indirin. Uzun bir sözleşme talep formu, insanları yeniden e-postaya yönlendirebilir.

Sık talepte bulunan iki kişiden ve iki hukuk incelemecisinden yakın tarihli anlaşmaları normalde yaptıkları gibi uygulama üzerinden yürütmelerini isteyin. Atladıkları alanları, farklı yorumladıkları soruları ve ekibin çalışmasına uymayan durumları gözlemleyin.

Geri bildirimlerini kullanarak hiçbir incelemecinin kullanmadığı alanları kaldırın, insanların tutarsız bilgi girdiği yerlere yardım metni ekleyin, durumları sade bir dille yeniden adlandırın, engellenen talepler ve yaklaşan imza tarihleri için uyarılar belirleyin ve incelemeci sözleşme dosyasını açmadan önce madde ihtiyaçlarını görünür kılın.

İlk aydan sonra her talebin geldiği tarihi Hukuk ekibinin işi tamamladığı tarihle karşılaştırın. Eksik iş bilgilerinden, şirket içi incelemeden ve karşı taraf müzakeresinden kaynaklanan gecikmeleri birbirinden ayırın. On rutin gizlilik sözleşmesi bir günde kapanırken bazı eksik tedarikçi talepleri Hukuk ekibi başlayamadan bir hafta bekleyebilir.

AppMaster ekiplerin görsel gönderim formları, Business Process Editor içindeki durum kuralları ve talepler için yapılandırılmış bir veritabanıyla kodsuz sözleşme talep uygulaması oluşturmasına yardımcı olabilir. Bir pano, açık işleri, gecikmiş talepleri ve sözleşme türüne göre işlem süresini gösterebilir.

Yayın sonrasında da sorumluluğu net tutun. Bir hukuk operasyonları sorumlusu alanları ve raporları düzenli olarak incelemeli, hukuk ekibi de yeni sözleşme örüntüleri ortaya çıktıkça eksikleri bildirmelidir. Küçük ve aylık değişiklikler, hukuk talep iş akışının insanların kaçındığı başka bir forma dönüşmesini önler.