Szablon danych do zarządzania umowami
Szablon danych do zarządzania umowami
- Zalecane atrybuty do zebrania
- Działania do śledzenia
- Wskazówki dotyczące pobierania danych z systemu źródłowego
Atrybuty zarządzania umowami
| Nazwa | Opis | ||
|---|---|---|---|
|
Identyfikator umowy
ContractId
|
Unikalny identyfikator każdej umowy obsługiwanej na platformie Icertis. | ||
|
Opis
Identyfikator umowy pełni funkcję jednoznacznego identyfikatora sprawy. Łączy wszystkie zdarzenia i czynności dotyczące konkretnej umowy. Dzięki temu można kompleksowo analizować jej przebieg od rozpoczęcia do zakończenia. W process mining ten atrybut jest podstawą do odtworzenia cyklu życia każdej umowy. Pozwala prawidłowo powiązać z nią wszystkie czynności, takie jak przygotowanie projektu, przeglądy, akceptacje i zawarcie umowy. Umożliwia to dokładny pomiar czasu realizacji i wykrywanie różnic w przebiegu procesu.
Dlaczego to ważne
To główny klucz analizy procesu. Umożliwia śledzenie całego przebiegu umowy i zapewnia spójność danych.
Skąd pobrać
To podstawowy atrybut obiektu Contract Agreement w Icertis.
Przykłady
CTR-2023-00123MSA-2024-589ANDA-FN-00451
|
|||
|
Czas zdarzenia
EventTime
|
Znacznik czasu wskazujący, kiedy wystąpiła dana czynność związana z umową. | ||
|
Opis
Ten atrybut zapisuje dokładną datę i godzinę rozpoczęcia lub zakończenia czynności. Stanowi podstawę analizy czasu w process mining i określa chronologiczną kolejność zdarzeń dla każdej sprawy dotyczącej umowy. Czas zdarzenia jest niezbędny do wszystkich analiz opartych na czasie. Służy do obliczania czasu między czynnościami, wykrywania okresów oczekiwania, mierzenia długości poszczególnych etapów, takich jak negocjacje lub akceptacja, oraz wskazywania wąskich gardeł, w których umowy pozostają przez dłuższy czas.
Dlaczego to ważne
Ten znacznik czasu jest niezbędny do obliczania wszystkich miar efektywności, takich jak czas realizacji i czas trwania, oraz do ustalenia kolejności zdarzeń.
Skąd pobrać
To standardowe pole w dzienniku audytowym lub historii workflow Icertis, przypisane do każdego zarejestrowanego zdarzenia.
Przykłady
2023-05-15T10:22:00Z2023-06-02T14:05:30Z2024-01-10T11:00:00Z
|
|||
|
Nazwa czynności
ActivityName
|
Nazwa zdarzenia lub zadania, które wystąpiło na danym etapie cyklu życia umowy. | ||
|
Opis
Nazwa czynności opisuje konkretny krok lub etap procesu zarządzania umową. Zdarzenia są porządkowane według znaczników czasu, aby odtworzyć przebieg procesu dla każdej umowy. Analiza tego atrybutu pokazuje kolejność operacji, częstotliwość poszczególnych czynności i ogólną strukturę procesu. Pomaga wykrywać typowe ścieżki, odstępstwa od standardowej procedury oraz czynności powodujące poprawki lub opóźnienia, na przykład kolejne rundy zmian.
Dlaczego to ważne
Określa kroki procesu, co jest niezbędne do wizualizacji mapy procesu, analizy jego przebiegu i wykrywania wąskich gardeł.
Skąd pobrać
Informacje te pochodzą zwykle z dzienników zdarzeń lub tabel historii workflow w Icertis, które rejestrują zmiany statusu i zadania wykonane w ramach umowy.
Przykłady
Przygotowanie projektu umowyZakończenie przeglądu prawnegoPodpisanie umowyRozpoczęcie zmiany umowy
|
|||
|
Czas zakończenia
EndTime
|
Znacznik czasu wskazujący, kiedy zakończono daną czynność związaną z umową. | ||
|
Opis
Ten atrybut zapisuje czas zakończenia czynności. StartTime oznacza jej początek, a EndTime koniec, wyznaczając czas trwania czynności. Znajomość czasu rozpoczęcia i zakończenia pozwala dokładnie obliczyć czas realizacji każdej czynności. Można dzięki temu sprawdzić, które etapy trwają najdłużej, oraz odróżnić czas aktywnej pracy od oczekiwania między etapami. Dane te są potrzebne na dashboardach takich jak „Wąskie gardła w procesie akceptacji” oraz „Efektywność przygotowywania i weryfikacji umów”.
Dlaczego to ważne
Pozwala dokładnie obliczyć czas trwania czynności i odróżnić czas realizacji od czasu oczekiwania.
Skąd pobrać
Podobnie jak StartTime, tę wartość można znaleźć w ścieżce audytu Icertis lub dziennikach historii workflow. Niektóre zdarzenia mogą być natychmiastowe, wtedy StartTime i EndTime mają tę samą wartość.
Przykłady
2023-05-15T18:30:00Z2023-06-03T09:00:15Z2024-01-10T11:00:00Z
|
|||
|
Dział osoby odpowiedzialnej
OwnerDepartment
|
Dział, do którego należy osoba odpowiedzialna za czynność. | ||
|
Opis
Ten atrybut określa dział, na przykład prawny, sprzedaży lub zakupów, do którego należy użytkownik wykonujący czynność. Pozwala analizować udział zasobów w procesie w ujęciu zbiorczym. Analiza według działów pomaga zrozumieć współpracę między nimi i przekazywanie spraw. Ułatwia wykrywanie opóźnień, na przykład długiego oczekiwania na weryfikację prawną po przekazaniu umowy przez dział sprzedaży. Temu zagadnieniu poświęcono dashboard „Opóźnienia przy przekazywaniu spraw między działami”.
Dlaczego to ważne
Ułatwia analizę wyników działów i sprawności przekazywania spraw oraz pomaga wykrywać wąskie gardła na styku różnych funkcji.
Skąd pobrać
Dane te mogą wymagać uzupełnienia przez połączenie z systemem HR lub katalogiem użytkowników, z użyciem atrybutu Activity Owner jako klucza. Mogą też być zapisane bezpośrednio w profilach użytkowników Icertis.
Przykłady
Dział prawnySprzedażZakupyFinanse
|
|||
|
Osoba odpowiedzialna za czynność
ActivityOwner
|
Użytkownik lub zasób odpowiedzialny za wykonanie czynności związanej z umową. | ||
|
Opis
Ten atrybut wskazuje osobę, zespół lub użytkownika systemowego, który wykonał daną czynność. Może to być nazwa użytkownika, identyfikator pracownika lub konto systemowe. Analiza osób odpowiedzialnych za czynności pomaga zrozumieć przydział zasobów, rozkład obciążenia pracą i wyniki. Pozwala ustalić, którzy użytkownicy lub zespoły tworzą wąskie gardła, kto najsprawniej weryfikuje umowy i jak rozdzielana jest praca. Dane te są podstawą dashboardu „Rozkład obciążenia pracą osób weryfikujących umowy”.
Dlaczego to ważne
Umożliwia analizę wyników pracy użytkowników i zespołów oraz pomaga wykrywać nierównomierne obciążenie pracą i potrzeby szkoleniowe.
Skąd pobrać
Informacje te są zwykle dostępne w historii workflow lub danych ścieżki audytu w Icertis i są powiązane z poszczególnymi zdarzeniami.
Przykłady
John SmithLegal.Review.QueueSystem.AutoApproveSarah Chen
|
|||
|
Rodzaj umowy
ContractType
|
Klasyfikacja umowy, na przykład umowa ramowa o świadczenie usług lub umowa o zachowaniu poufności. | ||
|
Opis
Atrybut Contract Type klasyfikuje umowy według ich celu prawnego lub biznesowego. To podstawowy wymiar segmentacji i porównywania przebiegu umów. Różne rodzaje umów często przebiegają innymi ścieżkami, różnią się złożonością i mają odrębne SLA. Analiza procesu według rodzaju umowy pozwala wprowadzać ukierunkowane usprawnienia, na przykład optymalizować workflow dla licznych umów o niskim ryzyku, takich jak NDA, zamiast traktować je tak samo jak złożone umowy MSA o wysokiej wartości. Atrybut ten jest potrzebny do analizy KPI „Warianty procesu obsługi umów” i „Zgodność z polityką”.
Dlaczego to ważne
Pozwala podzielić proces na segmenty i porównać przebieg oraz zgodność dla różnych rodzajów umów.
Skąd pobrać
Jest to standardowy atrybut skonfigurowany w obiekcie Contract Agreement w Icertis.
Przykłady
Umowa ramowa o świadczenie usług (MSA)Umowa o zachowaniu poufności (NDA)Zakres prac (SOW)
|
|||
|
Status umowy
ContractStatus
|
Bieżący stan lub etap umowy w jej cyklu życia. | ||
|
Opis
Ten atrybut określa ogólny status sprawy dotyczącej umowy, na przykład „Wersja robocza”, „W trakcie weryfikacji”, „Oczekuje na podpis” lub „Podpisana”. Zazwyczaj jest to atrybut na poziomie sprawy, który odzwierciedla ostatni osiągnięty ważny etap. Status jest potrzebny na dashboardach operacyjnych, takich jak „Status i przepustowość obsługi umów”, które pokazują bieżący obraz portfela umów. Pomaga kierownikom sprawdzić liczbę umów na poszczególnych etapach i wykryć miejsca, w których gromadzi się praca, aby mogli odpowiednio wcześnie zareagować.
Dlaczego to ważne
Pokazuje ogólny obraz portfela umów, potrzebny do monitorowania operacji i zarządzania przepustowością procesu.
Skąd pobrać
To podstawowe pole statusu w obiekcie Contract Agreement w Icertis.
Przykłady
Wersja roboczaW trakcie wewnętrznej weryfikacjiPodpisanaRozwiązana
|
|||
|
Wartość umowy
ContractValue
|
Łączna wartość pieniężna umowy. | ||
|
Opis
Ten atrybut określa wartość finansową umowy, na przykład jej łączną kwotę lub wartość w ujęciu rocznym. To ważny wskaźnik biznesowy, który pomaga ustalać priorytety i oceniać wpływ finansowy. W process mining wartość umowy służy do segmentacji analizy i skupienia się na umowach o wysokiej wartości. Można na przykład sprawdzić, czy ich akceptacja lub negocjacje trwają dłużej. Atrybut pomaga też oceniać ryzyko, ponieważ opóźnienia w przypadku takich umów mogą znacząco wpłynąć na przychody.
Dlaczego to ważne
Ułatwia ustalanie priorytetów i analizę według wartości, dzięki czemu działania usprawniające można skupić na umowach o największym znaczeniu finansowym.
Skąd pobrać
Zazwyczaj jest to standardowe pole walutowe w obiekcie Contract Agreement w Icertis.
Przykłady
50000.001250000.002500.00
|
|||
|
Czy użyto standardowego szablonu
IsStandardTemplate
|
Wskaźnik informujący, czy umowę utworzono na podstawie standardowego szablonu firmy. | ||
|
Opis
Ten atrybut logiczny wskazuje, czy umowa powstała na podstawie zatwierdzonego standardowego szablonu, czy została przygotowana indywidualnie jako niestandardowa umowa. Ma to znaczenie przy ocenie ryzyka i zgodności. Umowy oparte na standardowych szablonach zazwyczaj mają krótszy czas realizacji i wiążą się z mniejszym ryzykiem. Atrybut ten stanowi podstawę KPI „Zgodność umów z szablonem” i pomaga analizować wpływ korzystania z niestandardowych dokumentów na proces. Może wskazać działy lub rodzaje umów, w których często odchodzi się od standardów, co ułatwia działania na rzecz częstszego stosowania szablonów.
Dlaczego to ważne
Mierzy stosowanie standardów firmy, które wpływa na sprawność procesu i ograniczenie ryzyka.
Skąd pobrać
Może to być pole wyboru w umowie lub wartość wyliczana na podstawie źródła dokumentu albo jego metadanych w Icertis.
Przykłady
truefalse
|
|||
|
Data ostatniej aktualizacji danych
LastDataUpdate
|
Znacznik czasu ostatniego odświeżenia danych dotyczących procesu. | ||
|
Opis
Ten atrybut informuje o aktualności analizowanych danych. Zapisuje datę i godzinę ostatniej ekstrakcji danych z systemu źródłowego. Dzięki tej informacji użytkownicy wiedzą, jak aktualne są dane prezentowane na dashboardach. Mogą sprawdzić, czy analizują informacje bieżące, czy dane sprzed kilku godzin lub dni, i uwzględnić to przy podejmowaniu decyzji.
Dlaczego to ważne
Informuje o aktualności danych, dzięki czemu użytkownicy wiedzą, jak aktualna jest analiza procesu.
Skąd pobrać
Ten znacznik czasu generuje potok danych lub narzędzie ETL po każdym pomyślnym odświeżeniu danych.
Przykłady
2024-07-27T08:00:00Z2024-07-26T23:59:59Z
|
|||
|
Data wygaśnięcia
ExpirationDate
|
Data, w której umowa ma wygasnąć. | ||
|
Opis
Ten atrybut przechowuje datę zakończenia okresu obowiązywania umowy. Jest ważna przy zarządzaniu umową po jej podpisaniu, ponieważ może uruchamiać działania związane z odnowieniem lub rozwiązaniem. Data ta pomaga ocenić skuteczność zarządzania umowami po zakończeniu ich obowiązywania. Stanowi podstawę KPI „Terminowe odnowienia i rozwiązania”, który mierzy, czy procesy odnowienia lub rozwiązania są rozpoczynane i kończone na czas. Pozwala to uniknąć niechcianego automatycznego odnowienia umowy lub przerwy w świadczeniu usług.
Dlaczego to ważne
Pomaga zarządzać odnowieniami i rozwiązaniami umów oraz odpowiednio wcześnie podejmować działania przed końcem okresu ich obowiązywania.
Skąd pobrać
To standardowe pole daty w obiekcie Contract Agreement w Icertis.
Przykłady
2025-12-312026-06-302024-08-15
|
|||
|
Jednostka biznesowa
BusinessUnit
|
Wewnętrzna jednostka biznesowa powiązana z umową. | ||
|
Opis
Ten atrybut wskazuje wewnętrzny dział lub jednostkę biznesową, która jest właścicielem umowy lub o nią wnioskowała, na przykład „Sprzedaż korporacyjna, Ameryka Północna” lub „Globalne zakupy”. Podobnie jak dział, jednostka biznesowa pozwala analizować dane o procesie na wyższym poziomie agregacji. Ułatwia porównanie sprawności procesu i zgodności w różnych częściach organizacji. Dostarcza kierownictwu informacji przydatnych przy strategicznym planowaniu zasobów.
Dlaczego to ważne
Umożliwia porównywanie wyników procesu na wysokim poziomie między różnymi jednostkami organizacyjnymi.
Skąd pobrać
Często jest to ważne pole metadanych umowy, które łączy ją ze strukturą organizacyjną.
Przykłady
Jednostka biznesowa, Ameryka PółnocnaUsługi globalneRozwój produktów
|
|||
|
Liczba zmian
RevisionCount
|
Łączna liczba zmian wprowadzonych do umowy. | ||
|
Opis
Ta wyliczana miara zlicza dla każdej sprawy dotyczącej umowy czynności związane ze zmianami, takie jak „Umowa z naniesionymi zmianami lub po poprawkach”. Jest prostym, ale wymownym wskaźnikiem trudności w przebiegu procesu. Duża liczba zmian może wskazywać na problemy podczas przygotowywania umowy lub negocjacji, takie jak niejasne wymagania, słabe pierwsze wersje dokumentu albo trudne negocjacje. Miara ta bezpośrednio zasila KPI „Wskaźnik zmian w umowach” i pomaga na dashboardach wykrywać umowy oraz warianty procesu wymagające nadmiernej liczby poprawek.
Dlaczego to ważne
Określa skalę poprawek w cyklu życia umowy i bezpośrednio mierzy sprawność jej przygotowywania oraz negocjacji.
Skąd pobrać
Wartość oblicza się, zliczając w dzienniku zdarzeń wystąpienia określonych czynności związanych ze zmianami dla każdego „ContractId”.
Przykłady
1503
|
|||
|
Nazwa drugiej strony umowy
CounterpartyName
|
Nazwa strony zewnętrznej, na przykład klienta lub dostawcy, będącej stroną umowy. | ||
|
Opis
Ten atrybut wskazuje drugą stronę umowy. Dostarcza kontekstu potrzebnego do analizy współpracy i negocjacji. Analiza procesu według kontrahenta może ujawnić powtarzające się wzorce negocjacji. Można na przykład sprawdzić, czy negocjacje umów z określonymi dostawcami trwają dłużej lub wymagają większej liczby zmian. Te informacje pomagają zarządzać relacjami i dostosowywać strategie negocjacyjne. Są też podstawą dashboardu „Czas negocjacji i poprawki”.
Dlaczego to ważne
Umożliwia analizę przebiegu negocjacji i jakości współpracy z poszczególnymi stronami zewnętrznymi.
Skąd pobrać
Informacje te są zapisane w metadanych umowy i zazwyczaj zawierają odwołanie do kontrahenta lub obiektu danych podstawowych dostawcy w Icertis.
Przykłady
Acme CorporationGlobal Tech Inc.Innovate Solutions LLC
|
|||
|
Region
Region
|
Region geograficzny, którego dotyczy umowa. | ||
|
Opis
Ten atrybut określa obszar geograficzny, na przykład EMEA, APAC lub Amerykę Północną, którego dotyczy umowa. Ma to znaczenie dla globalnych organizacji, w których procesy różnią się w zależności od regionu. Analiza według regionu może ujawnić różnice w wynikach procesu, wymaganiach dotyczących zgodności lub sposobie prowadzenia negocjacji, wynikające z lokalnego prawa i kultury biznesowej. Umożliwia porównywanie wyników między regionami i wskazywanie dobrych praktyk, które można upowszechnić w całej organizacji.
Dlaczego to ważne
Pomaga wykrywać regionalne różnice w wynikach procesu i wymaganiach dotyczących zgodności, co ma znaczenie dla globalnych organizacji.
Skąd pobrać
Zazwyczaj jest to pole metadanych obiektu umowy w Icertis, często dostępne w standardowej konfiguracji.
Przykłady
EMEAAmeryka PółnocnaAPACAmeryka Łacińska
|
|||
|
Status SLA
SLAState
|
Informuje, czy czynność lub sprawa mieści się w warunkach umowy o gwarantowanym poziomie świadczenia usług (SLA). | ||
|
Opis
Ten atrybut jest wyliczany przez porównanie czasu trwania wybranych etapów procesu z ustalonymi celami SLA. Na przykład weryfikacja prawna może otrzymać status „Po terminie”, jeśli trwa dłużej niż standardowe 48 godzin. Status SLA jest potrzebny do monitorowania zgodności i wyników. Pozwala tworzyć alerty i dashboardy, takie jak „Przegląd zgodności umów”, które od razu wskazują przekroczenia terminów. Dzięki temu zespoły mogą ustalać priorytety zaległych zadań, a kierownicy śledzić wyniki względem założonych celów.
Dlaczego to ważne
Szybko pokazuje, czy dotrzymywane są cele dotyczące poziomu usług, co pomaga ustalać priorytety pracy i monitorować wyniki.
Skąd pobrać
Wartość oblicza się za pomocą reguł biznesowych w narzędziu process mining, które porównują znaczniki czasu z ustalonymi limitami SLA, na przykład gdy czas weryfikacji prawnej przekracza 2 dni.
Przykłady
W terminieZagrożony terminPo terminie
|
|||
|
System źródłowy
SourceSystem
|
System, z którego wyodrębniono dane o umowach. | ||
|
Opis
Ten atrybut wskazuje źródło danych. W tym procesie jest nim „Icertis”. Pomaga w zarządzaniu danymi i śledzeniu ich pochodzenia, zwłaszcza gdy dane pochodzą z wielu systemów. Podczas analizy można go użyć do filtrowania danych według systemu źródłowego lub, jeśli to możliwe, do porównania procesów w różnych systemach. W tym widoku jest stałym identyfikatorem wszystkich zdarzeń.
Dlaczego to ważne
Umożliwia śledzenie pochodzenia danych, co ma znaczenie przy ich weryfikacji i zarządzaniu danymi z wielu źródeł.
Skąd pobrać
Zazwyczaj jest to stała wartość dodawana podczas ekstrakcji i transformacji danych, aby oznaczyć ich źródło.
Przykłady
IcertisIcertisCLM
|
|||
|
Termin realizacji zobowiązania
ObligationDueDate
|
Termin, do którego należy zrealizować określone zobowiązanie umowne. | ||
|
Opis
Ten atrybut śledzi terminy realizacji ważnych zobowiązań, ustaleń i dostaw określonych w umowie po jej podpisaniu. Jedna umowa może obejmować wiele zobowiązań, z których każde ma własny termin. Monitorowanie tych terminów ma zasadnicze znaczenie dla zgodności po podpisaniu umowy i zarządzania ryzykiem. Atrybut ten stanowi podstawę KPI „Terminowa realizacja zobowiązań”. Pozwala organizacji sprawdzać, czy wywiązuje się ze zobowiązań na czas, i odpowiednio wcześnie reagować na ryzyko naruszenia umowy.
Dlaczego to ważne
Umożliwia monitorowanie zgodności po podpisaniu umowy, co pomaga uniknąć kar i utrzymać dobre relacje biznesowe.
Skąd pobrać
Icertis oferuje moduły do zarządzania zobowiązaniami. Dane te pochodzą z zobowiązań powiązanych z umową.
Przykłady
2024-09-302025-01-152024-11-01
|
|||
|
Wersja dokumentu
DocumentVersion
|
Numer wersji dokumentu umowy. | ||
|
Opis
Ten atrybut śledzi kolejne wersje dokumentu umowy podczas jego przygotowywania, nanoszenia zmian i wprowadzania poprawek. Zazwyczaj jest to liczba całkowita lub numer w formacie główna.podrzędna. Liczba wersji dokumentu bezpośrednio wskazuje skalę poprawek. Wiele wersji umowy może oznaczać konieczność wielokrotnych zmian. Analiza przyczyn pozwala ustalić, skąd się biorą. Atrybut ten służy do obliczania KPI „Wskaźnik zmian w umowach” i jest wykorzystywany na dashboardzie „Efektywność przygotowywania i weryfikacji umów”.
Dlaczego to ważne
Bezpośrednio mierzy liczbę poprawek i zmian w umowie, wskazując nieefektywność na etapie przygotowywania dokumentu i negocjacji.
Skąd pobrać
Icertis przechowuje historię wersji wszystkich dokumentów umów. Atrybut można pobrać z metadanych dokumentu lub dziennika zdarzeń.
Przykłady
1.02.34.00.5
|
|||
Działania w procesie zarządzania umowami
| Działanie | Opis | ||
|---|---|---|---|
|
Podpisanie umowy
|
Ta czynność oznacza formalne zawarcie umowy, gdy podpiszą ją wszystkie strony. Jest głównym zdarzeniem kończącym proces przed podpisaniem i jest rejestrowana dzięki integracji z platformą do podpisu elektronicznego. | ||
|
Dlaczego to ważne
Jako główne zdarzenie kończące proces wyznacza koniec okresu mierzonego przez KPI „Średni czas realizacji umowy”. Oznacza moment, w którym umowa staje się prawnie wiążąca i wchodzi w życie.
Skąd pobrać
Po zakończeniu podpisywania przez wszystkie strony platforma do podpisu elektronicznego wysyła jawne zdarzenie, które jest rejestrowane w Icertis.
Rejestrowanie
Zdarzenie zwrotne z integracji z platformą do podpisu elektronicznego.
Typ zdarzenia
explicit
|
|||
|
Rozwiązanie lub wygaśnięcie umowy
|
Oznacza koniec cyklu życia umowy, wskutek aktywnego procesu jej rozwiązania lub upływu terminu ważności. Rozwiązanie jest jawnym zdarzeniem, natomiast wygaśnięcie ustala się na podstawie metadanych umowy. | ||
|
Dlaczego to ważne
To końcowe zdarzenie w cyklu życia umowy. Ma zasadnicze znaczenie przy analizie odnowień i pomiarze KPI „Wskaźnik terminowych odnowień i rozwiązań umów”.
Skąd pobrać
Zdarzenie rozwiązania jest rejestrowane jawnie, gdy użytkownik wykonuje czynność rozwiązania umowy. Wygaśnięcie można ustalić, porównując bieżącą datę z atrybutem „Data wygaśnięcia”.
Rejestrowanie
Ustalane przez porównanie daty systemowej z datą wygaśnięcia umowy lub na podstawie ręcznie zarejestrowanego zdarzenia rozwiązania.
Typ zdarzenia
calculated
|
|||
|
Uzyskanie akceptacji kontrahenta
|
To zdarzenie oznacza, że kontrahent zaakceptował warunki i końcową wersję umowy. Może być rejestrowane jawnie w portalu współpracy lub wynikać z ręcznej aktualizacji statusu przez właściciela umowy. | ||
|
Dlaczego to ważne
Ten etap kończy negocjacje. Wyznacza koniec okresu mierzonego przez KPI „Średni czas negocjacji” i pozwala ocenić sprawność współpracy zewnętrznej.
Skąd pobrać
Zdarzenie może być rejestrowane jawnie, jeśli kontrahent akceptuje umowę w portalu Icertis. W przeciwnym razie można je ustalić na podstawie ręcznej zmiany statusu na „Zaakceptowano przez kontrahenta”.
Rejestrowanie
Zdarzenie zarejestrowane w portalu kontrahenta lub na podstawie ręcznej aktualizacji statusu przez użytkownika wewnętrznego.
Typ zdarzenia
explicit
|
|||
|
Uzyskanie akceptacji wewnętrznych
|
Oznacza moment, w którym wszyscy wymagani interesariusze wewnętrzni zaakceptowali umowę, która może zostać przekazana do negocjacji zewnętrznych lub podpisu. Zdarzenie można ustalić na podstawie osiągnięcia końcowego statusu „Zaakceptowano” przez cały workflow akceptacji. | ||
|
Dlaczego to ważne
To ważny etap kończący cykl przeglądu wewnętrznego. Wyznacza koniec okresu mierzonego przez KPI „Średni czas akceptacji”.
Skąd pobrać
Zdarzenie można ustalić na podstawie zmiany statusu workflow na „W pełni zaakceptowano” lub podobny, oznaczający zakończenie wszystkich zadań akceptacyjnych.
Rejestrowanie
Znacznik czasu zakończenia ostatniego zadania akceptacji wewnętrznej lub zmiany ogólnego statusu workflow.
Typ zdarzenia
inferred
|
|||
|
Zakończenie przeglądu prawnego
|
Oznacza zakończenie przeglądu umowy przez dział prawny. Zwykle jest rejestrowane jawnie, gdy osoba z działu prawnego kończy przypisane jej zadanie w workflow akceptacji. | ||
|
Dlaczego to ważne
Ta czynność pozwala mierzyć czas przeglądu prawnego i wykrywać ewentualne ograniczenia przepustowości zespołu prawnego. Jest podstawą KPI „Czas oczekiwania na przegląd prawny”.
Skąd pobrać
Zdarzenie jest rejestrowane jawnie, gdy zadanie przeglądu prawnego w workflow Icertis otrzymuje status „Zakończone”. Można je też ustalić na podstawie zmiany statusu, na przykład na „Zaakceptowano przez dział prawny”.
Rejestrowanie
Zdarzenie z silnika workflow informujące o zakończeniu zadania „Przegląd prawny”.
Typ zdarzenia
explicit
|
|||
|
Zgłoszenie zapotrzebowania na umowę
|
To zdarzenie oznacza formalne rozpoczęcie cyklu życia umowy, gdy użytkownik biznesowy składa wniosek o nową umowę. Zwykle jest rejestrowane w chwili przesłania formularza wniosku o umowę na platformie Icertis. | ||
|
Dlaczego to ważne
Jako zdarzenie rozpoczynające proces, jest niezbędne do pomiaru całkowitego czasu realizacji umowy. Analiza liczby i rodzajów wniosków pomaga planować zasoby i zarządzać zapotrzebowaniem.
Skąd pobrać
Zdarzenie jest jawnie rejestrowane w Icertis po utworzeniu i przesłaniu obiektu „Wniosek o umowę”.
Rejestrowanie
Zdarzenie rejestrowane po przesłaniu formularza wniosku o umowę.
Typ zdarzenia
explicit
|
|||
|
Odnowienie umowy
|
Oznacza skuteczne przedłużenie istniejącej umowy na kolejny okres. Jest to jawna czynność wykonywana w systemie, która często powoduje utworzenie nowego wpisu umowy lub aktualizację istniejącego. | ||
|
Dlaczego to ważne
Ta czynność pozwala ocenić skuteczność procesu odnawiania umów. Służy do obliczenia KPI „Wskaźnik terminowych odnowień i rozwiązań umów”.
Skąd pobrać
Jawne zdarzenie generowane, gdy użytkownik wybiera w Icertis czynność „Odnów” dla wpisu umowy.
Rejestrowanie
Zdarzenie rejestrowane po transakcji „Odnów” zainicjowanej przez użytkownika.
Typ zdarzenia
explicit
|
|||
|
Przekazanie umowy do podpisu
|
Oznacza wysłanie ostatecznej, zaakceptowanej umowy do podpisu elektronicznego lub odręcznego. Zdarzenie jest rejestrowane jawnie dzięki integracji z platformami do podpisu elektronicznego, takimi jak DocuSign lub Adobe Sign. | ||
|
Dlaczego to ważne
Monitorowanie tego zdarzenia pomaga ocenić sprawność końcowego etapu realizacji umowy. Opóźnienie między akceptacją a wysłaniem do podpisu może wskazywać na administracyjne wąskie gardło.
Skąd pobrać
Zdarzenie jest rejestrowane jawnie przez integrację API z rozwiązaniem do podpisu elektronicznego, gdy proces podpisywania zostaje rozpoczęty w Icertis.
Rejestrowanie
Zdarzenie z konektora do podpisu elektronicznego, rejestrowane po wysłaniu prośby o podpis.
Typ zdarzenia
explicit
|
|||
|
Przygotowanie projektu umowy
|
Oznacza utworzenie pierwszego dokumentu umowy, na podstawie szablonu lub jako nowego pliku. Zdarzenie często można ustalić na podstawie utworzenia lub pierwszego przesłania głównego dokumentu umowy powiązanego z obszarem roboczym umowy. | ||
|
Dlaczego to ważne
Monitorowanie tej czynności pozwala zmierzyć czas przygotowania pierwszego projektu. Jest to ważny etap przy analizie efektywności tworzenia projektów i stosowania szablonów.
Skąd pobrać
Zdarzenie można ustalić na podstawie znacznika czasu utworzenia głównego dokumentu umowy w obszarze roboczym umowy lub obiekcie umowy w Icertis.
Rejestrowanie
Ustal znacznik czasu utworzenia pierwszej wersji głównego dokumentu umowy.
Typ zdarzenia
inferred
|
|||
|
Rozpoczęcie negocjacji z kontrahentem
|
Oznacza moment przekazania umowy kontrahentowi do przeglądu i negocjacji. Zdarzenie często można ustalić na podstawie zmiany statusu umowy na „W negocjacjach” lub dziennika audytowego wskazującego, kiedy dokument po raz pierwszy wysłano na zewnątrz. | ||
|
Dlaczego to ważne
Ta czynność rozpoczyna etap negocjacji. Jest punktem początkowym do obliczenia KPI „Średni czas negocjacji”.
Skąd pobrać
Zdarzenie można ustalić na podstawie ręcznej zmiany statusu na „W negocjacjach” lub zarejestrowania pierwszego udostępnienia dokumentu w portalu zewnętrznym.
Rejestrowanie
Znacznik czasu zmiany statusu na „W negocjacjach” lub „Wysłano do kontrahenta”.
Typ zdarzenia
inferred
|
|||
|
Rozpoczęcie przeglądu wewnętrznego
|
To zdarzenie oznacza rozpoczęcie wewnętrznego przeglądu i workflow akceptacji. Jest rejestrowane, gdy projekt umowy zostaje formalnie przekazany do przeglądu wewnętrznym interesariuszom, na przykład kierownikom działów lub zespołowi finansowemu. | ||
|
Dlaczego to ważne
To początek etapu akceptacji, na którym często pojawiają się wąskie gardła. Analiza czasu od tego zdarzenia pomaga wykryć opóźnienia w rozpoczęciu współpracy wewnętrznej.
Skąd pobrać
Zdarzenie jest rejestrowane jawnie po uruchomieniu w workflow Icertis czynności „Przekaż do przeglądu” lub ustalane na podstawie zmiany statusu na „Przegląd wewnętrzny”.
Rejestrowanie
Zdarzenie rejestrowane, gdy użytkownik rozpoczyna workflow przeglądu wewnętrznego.
Typ zdarzenia
explicit
|
|||
|
Rozpoczęcie zmiany umowy
|
Oznacza rozpoczęcie formalnego procesu zmiany obowiązującej umowy. Zdarzenie jest rejestrowane, gdy użytkownik tworzy wpis dotyczący zmiany powiązany z pierwotną, zawartą umową. | ||
|
Dlaczego to ważne
Zmiany umowy oznaczają istotne poprawki lub zmianę zakresu. Monitorowanie ich częstotliwości i czasu realizacji pozwala ocenić stabilność umów i sprawność zarządzania nimi.
Skąd pobrać
Jawne zdarzenie jest rejestrowane po utworzeniu obiektu „Zmiana umowy” lub podobnego wpisu powiązanego z istniejącą umową.
Rejestrowanie
Utworzenie wpisu dotyczącego zmiany umowy w systemie Icertis.
Typ zdarzenia
explicit
|
|||
|
Uruchomienie monitorowania zobowiązań
|
Ta czynność po zawarciu umowy oznacza uruchomienie w systemie monitorowania zobowiązań i ustaleń umownych. Zwykle jest rejestrowana jawnie i uruchamiana automatycznie po zawarciu umowy lub ręcznie przez osobę zarządzającą umową. | ||
|
Dlaczego to ważne
To zdarzenie rozpoczyna okres zarządzania umową po jej zawarciu. Jest niezbędne do pomiaru i zapewnienia zgodności za pomocą KPI „Wskaźnik realizacji zobowiązań”.
Skąd pobrać
Jawne zdarzenie rejestrowane w module zarządzania zobowiązaniami Icertis, gdy status umowy zmienia się na „Aktywna” lub „Zawarta”.
Rejestrowanie
Automatyczne lub ręczne uruchomienie rejestrów zobowiązań powiązanych z umową.
Typ zdarzenia
explicit
|
|||
|
Wprowadzenie zmian lub poprawek do umowy
|
Ta czynność występuje za każdym razem, gdy dokument umowy zostaje zmieniony podczas przeglądu wewnętrznego lub negocjacji zewnętrznych. Icertis śledzi wersje dokumentów, więc każdą nową zapisaną wersję można zarejestrować jako zdarzenie wprowadzenia zmian. | ||
|
Dlaczego to ważne
Liczba takich zdarzeń dla każdej umowy pozwala obliczyć KPI „Wskaźnik zmian w umowach”. Duża liczba zmian może wskazywać na niejasne zapisy, nieefektywne negocjacje lub brak uzgodnień.
Skąd pobrać
Zdarzenie jest rejestrowane jawnie w module zarządzania dokumentami Icertis za każdym razem, gdy nowa wersja dokumentu umowy zostaje przesłana lub zapisana.
Rejestrowanie
Zdarzenie jest tworzone dla każdego nowego numeru wersji dokumentu.
Typ zdarzenia
explicit
|
|||
Instrukcje pobierania danych
Gotowi do rozpoczęcia?
Ten szablon zawiera wszystko, czego potrzeba, aby rozpocząć usprawnianie procesu zarządzania umowami. Zacznijcie przygotowywać dane i odkryjcie, co można z nich wywnioskować.
Usprawnij umowy w Icertis i ogranicz wąskie gardła
Ogranicz wąskie gardła. Skróć cykl obsługi umów o 30% i popraw nadzór.
Nie trzeba podawać danych karty. Konfiguracja zajmuje kilka minut.