Szablon danych do zarządzania umowami

DocuSign CLM
Szablon danych do zarządzania umowami

Szablon danych do zarządzania umowami

Szablon przedstawia najważniejsze dane potrzebne do analizy procesu zarządzania umowami. Zawiera podstawowe atrybuty do zebrania, działania do śledzenia oraz praktyczne wskazówki dotyczące pozyskiwania informacji. Pomoże zgromadzić dane potrzebne do analizy i optymalizacji procesu.
  • Zalecane atrybuty do zebrania
  • Najważniejsze działania do śledzenia
  • Wskazówki dotyczące pozyskiwania danych
Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Atrybuty zarządzania umowami

To zalecane pola danych, które warto uwzględnić w dzienniku zdarzeń, aby dokładnie przeanalizować proces zarządzania umowami.
5 Wymagane 7 Zalecane 7 Opcjonalne
Nazwa Opis
Contract ID
ContractId
Unikalny identyfikator każdej umowy obsługiwanej w systemie.
Opis

Contract ID to jednoznaczny identyfikator sprawy, który łączy wszystkie zdarzenia i czynności dotyczące konkretnej umowy, od jej utworzenia po zakończenie. W DocuSign CLM może odpowiadać Envelope ID lub niestandardowemu polu identyfikatora umowy.

Ten atrybut jest niezbędny w process mining, ponieważ pozwala odtworzyć przebieg każdej umowy od początku do końca. Grupując powiązane czynności pod jednym Contract ID, analitycy mogą wizualizować pełny przebieg procesu, mierzyć czas realizacji i analizować różnice między umowami.

Dlaczego to ważne

To główny klucz łączący wszystkie powiązane zdarzenia procesu. Pozwala prześledzić i przeanalizować cały cykl życia pojedynczej umowy.

Skąd pobrać

Zwykle jest to główny identyfikator umowy lub obiektu koperty w DocuSign CLM. Może być oznaczony jako Envelope ID albo stanowić niestandardowe pole skonfigurowane do identyfikacji umowy.

Przykłady
CON-2023-03-112MSA-4815162342NDA-CORP-9981
Czas rozpoczęcia
EventTime
Znacznik czasu wskazujący, kiedy rozpoczęło się dane działanie lub zdarzenie.
Opis

Ten atrybut zapisuje dokładną datę i godzinę wykonania działania. Stanowi podstawę czasową analizy process mining i pozwala oceniać przebieg procesu w czasie.

Uporządkowanie zdarzeń według czasu rozpoczęcia tworzy chronologiczny dziennik dla każdej sprawy. Umożliwia to obliczenie czasu cyklu między działaniami, czasu trwania poszczególnych kroków oraz całego procesu. Dane te pomagają wykrywać wąskie gardła, mierzyć czas oczekiwania i oceniać efektywność procesu względem SLA.

Dlaczego to ważne

Ten znacznik czasu pozwala uporządkować zdarzenia chronologicznie i obliczyć wszystkie miary zależne od czasu, takie jak czasy cyklu i czas trwania.

Skąd pobrać

Informacja ta jest standardowym elementem dziennika zdarzeń lub ścieżki audytu w DocuSign CLM i jest przypisana do każdej zarejestrowanej czynności.

Przykłady
2023-04-15T09:00:00Z2023-05-20T14:35:10Z2023-06-01T11:21:05Z
Czynność
ActivityName
Nazwa konkretnego zadania lub zdarzenia, które wystąpiło w cyklu życia umowy.
Opis

Ten atrybut opisuje pojedynczy krok lub kamień milowy w procesie zarządzania umowami, na przykład „Przygotowanie projektu umowy”, „Rozpoczęcie weryfikacji prawnej” lub „Podpisanie umowy”. Te działania składają się na mapę procesu.

Analiza kolejności i częstotliwości działań jest podstawą process mining. Pozwala ustalić, jak przebiega proces w praktyce, wykryć odstępstwa od standardowej procedury oraz wskazać działania, które trwają najdłużej lub często się powtarzają.

Dlaczego to ważne

Określa kolejne kroki procesu, dzięki czemu można wizualizować i analizować przebieg workflow umów, wąskie gardła oraz różnice w jego realizacji.

Skąd pobrać

Informacje te pochodzą zwykle z dziennika zdarzeń lub ścieżki audytu w DocuSign CLM, gdzie rejestrowane są działania wykonywane na dokumencie umowy lub w workflow.

Przykłady
Przygotowanie projektu umowyRozpoczęcie weryfikacji wewnętrznejPrzekazanie kontrahentowiZawarcie umowy
Data ostatniej aktualizacji danych
LastDataUpdate
Znacznik czasu ostatniego odświeżenia danych lub ich pobrania z systemu źródłowego.
Opis

Ten atrybut wskazuje, kiedy zbiór danych został ostatnio zaktualizowany. Informuje, jak aktualne są dane wykorzystane w analizie.

W dashboardach i raportach ma to znaczenie dla zarządzania danymi i zaufania użytkowników. Analitycy mogą sprawdzić, czy korzystają z danych bieżących, czy z migawki z określonego momentu. To ważne przy podejmowaniu świadomych decyzji na czas.

Dlaczego to ważne

Informuje o aktualności danych, dzięki czemu użytkownicy wiedzą, jak świeża jest analiza procesu.

Skąd pobrać

To atrybut metadanych, zwykle generowany i zapisywany przez narzędzie ETL (Extract, Transform, Load) lub potok danych podczas ich wczytywania.

Przykłady
2023-10-26T08:00:00Z2023-10-27T08:00:00Z
System źródłowy
SourceSystem
Wskazuje system, z którego pobrano dane.
Opis

Ten atrybut określa źródło danych o procesie. W tym widoku jego wartością będzie zawsze „DocuSign CLM” lub podobny identyfikator.

W analizie jednego systemu pole może wydawać się zbędne, ale warto je uwzględnić. Jest niezbędne przy łączeniu danych z wielu systemów, na przykład danych o umowach z CRM z danymi workflow z DocuSign. Ułatwia wtedy ustalenie pochodzenia danych i ich śledzenie.

Dlaczego to ważne

Umożliwia śledzenie pochodzenia danych i jest niezbędny w analizach łączących dane z wielu systemów przedsiębiorstwa.

Skąd pobrać

Zwykle jest to stała wartość dodawana podczas ekstrakcji i transformacji danych, aby oznaczyć źródło zbioru danych.

Przykłady
DocuSign CLMDocuSign CLM v24.1
Czas zakończenia
EndTime
Znacznik czasu wskazujący, kiedy zakończyło się dane działanie lub zdarzenie.
Opis

Ten atrybut zapisuje dokładną datę i godzinę zakończenia działania. Czas rozpoczęcia wskazuje jego początek, a czas zakończenia pozwala precyzyjnie obliczyć czas trwania poszczególnych działań.

Analiza czasu zakończenia pozwala obliczyć czas realizacji działania, czyli czas aktywnej pracy nad zadaniem. Dzięki temu można odróżnić pracę od oczekiwania, lepiej ocenić wykorzystanie zasobów i rzeczywisty koszt opóźnień. Można na przykład dokładnie obliczyć czas trwania działania „Weryfikacja prawna”.

Dlaczego to ważne

Pozwala precyzyjnie obliczyć czas trwania poszczególnych działań i odróżnić czas aktywnej pracy od oczekiwania.

Skąd pobrać

W systemach takich jak DocuSign CLM informacja ta może być zapisana bezpośrednio w ścieżce audytu albo wymagać ustalenia na podstawie czasu rozpoczęcia kolejnego zdarzenia.

Przykłady
2023-04-15T17:30:00Z2023-05-21T10:00:15Z2023-06-01T11:55:00Z
Data wygaśnięcia
ExpirationDate
Data, w której umowa ma wygasnąć.
Opis

Ten atrybut przechowuje umowną datę wygaśnięcia. Jest ważny przy proaktywnym zarządzaniu portfelem umów, zwłaszcza umowami dotyczącymi przychodów cyklicznych lub usług długoterminowych.

Data ta jest podstawą dashboardu „Prognoza odnowień i wygaśnięć umów”. Monitorowanie zbliżających się terminów wygaśnięcia pozwala odpowiednio wcześnie uruchomić workflow odnowienia. Atrybut ten służy również do obliczania KPI „Odsetek umów odnowionych w terminie”, co pomaga zapobiegać utracie przychodów i przerwom w świadczeniu usług.

Dlaczego to ważne

Ułatwia proaktywne zarządzanie umowami, terminowe odnowienia i zapobieganie ich niezamierzonemu wygaśnięciu.

Skąd pobrać

To standardowe pole metadanych, które należy wypełnić dla każdej umowy z określonym terminem obowiązywania w DocuSign CLM.

Przykłady
2024-12-312025-06-302026-01-15
Druga strona umowy
Counterparty
Podmiot zewnętrzny uczestniczący w umowie, na przykład klient lub dostawca.
Opis

Ten atrybut wskazuje drugą organizację będącą stroną umowy. Poszczególne podmioty mogą różnić się stylem negocjacji, wymaganiami prawnymi i czasem odpowiedzi, co może znacząco wpływać na przebieg umowy.

Analiza wyników procesu według drugiej strony umowy pomaga ustalić, z którymi partnerami współpraca przebiega sprawnie, a którzy regularnie powodują opóźnienia. Informacje te można wykorzystać do lepszego zarządzania relacjami i ustalania realistycznych oczekiwań przed kolejnymi negocjacjami. To ważny wymiar analizy „Poprawki do umów i częstotliwość zmian”.

Dlaczego to ważne

Pomaga ocenić, jak współpraca z różnymi podmiotami zewnętrznymi wpływa na czas negocjacji, liczbę poprawek i łączny czas cyklu.

Skąd pobrać

Informacja ta jest podstawowym elementem rekordu umowy i często znajduje się w osobnym polu „Nazwa drugiej strony” lub „Firma”.

Przykłady
Acme CorporationGlobex Inc.Stark Industries
Osoba odpowiedzialna za umowę
ContractOwner
Użytkownik lub pracownik odpowiedzialny za prowadzenie umowy przez cały cykl jej życia.
Opis

Osoba odpowiedzialna za umowę jest głównym punktem kontaktu i odpowiada za postępy w jej obsłudze. Zwykle jest to osoba, która zainicjowała wniosek o umowę lub odpowiada za relację biznesową.

Analiza wyników według osób odpowiedzialnych za umowy może ujawnić różnice w efektywności, liczbie poprawek i czasie cyklu. Pomaga wskazać osoby lub zespoły osiągające dobre wyniki, a także te, które mogą potrzebować dodatkowego wsparcia lub szkolenia. To ważny wymiar analizy w dashboardach, takich jak „Analiza czasu cyklu umowy”.

Dlaczego to ważne

Umożliwia analizę wyników poszczególnych osób i zespołów, pomaga wskazać dobre praktyki oraz obszary do poprawy w działaniach wykonywanych przez użytkowników.

Skąd pobrać

Zwykle jest to pole użytkownika przypisane do obiektu umowy, wypełniane nazwiskiem osoby, która utworzyła workflow lub za niego odpowiada.

Przykłady
Alice SmithBob JohnsonCharlie Brown
Rodzaj umowy
ContractType
Klasyfikacja umowy, na przykład NDA, MSA lub SOW.
Opis

Ten atrybut klasyfikuje umowy według ich celu prawnego lub biznesowego. Poszczególne rodzaje umów mogą mieć różne workflow, wymagania dotyczące akceptacji i poziom złożoności.

Podział analizy według rodzaju umowy pozwala zrozumieć różnice w wynikach procesu. Analitycy mogą porównywać czas cyklu, poziom zgodności i przebieg negocjacji dla różnych umów. Na przykład NDA powinno być obsługiwane znacznie szybciej niż złożona umowa ramowa o świadczenie usług. Ten atrybut umożliwia takie porównanie.

Dlaczego to ważne

Umożliwia porównanie wyników procesu dla różnych rodzajów umów, które często mają odrębne workflow i różnią się złożonością.

Skąd pobrać

To ważne pole metadanych, zwykle wybierane z listy podczas tworzenia umowy w DocuSign CLM.

Przykłady
Umowa o zachowaniu poufności (NDA)Ramowa umowa o świadczenie usług (MSA)Zakres prac (SOW)
Status umowy
ContractStatus
Bieżący stan umowy na danym etapie jej cyklu życia.
Opis

Ten atrybut wskazuje ogólny status umowy w danym momencie, na przykład „Projekt”, „W trakcie weryfikacji”, „Oczekuje na podpis” lub „Podpisana”. Pokazuje, na jakim etapie procesu znajduje się umowa.

W process mining analiza statusu ułatwia filtrowanie spraw i tworzenie dashboardów pokazujących liczbę umów na poszczególnych etapach. Dashboard „Bieżący status umów” korzysta bezpośrednio z tego atrybutu, aby pokazać aktywne umowy i wskazać, gdzie gromadzą się zadania.

Dlaczego to ważne

Pokazuje postęp prac nad umową, co ułatwia śledzenie statusu, zarządzanie obciążeniem i wykrywanie wąskich gardeł.

Skąd pobrać

Informacja ta jest zwykle dostępna jako podstawowy atrybut obiektu umowy lub workflow w DocuSign CLM.

Przykłady
ProjektW trakcie weryfikacji wewnętrznejOczekuje na podpisPodpisanaRozwiązana
Wartość umowy
ContractValue
Łączna wartość pieniężna umowy.
Opis

Ten atrybut określa wartość finansową umowy, jednorazową lub cykliczną. Od wartości umowy często zależą wymagany poziom kontroli i złożoność ścieżki akceptacji.

Analiza procesu według wartości umowy pomaga ustalać priorytety dla umów o dużej wartości i sprawdzać, czy nie dochodzi do nieuzasadnionych opóźnień. Można też kontrolować zgodność, na przykład sprawdzić, czy umowy przekraczające określony próg uzyskały akceptację dyrektora finansowego. Atrybut ten pozwala skupić działania usprawniające na umowach o największym znaczeniu finansowym.

Dlaczego to ważne

Ułatwia ustalanie priorytetów i ocenę ryzyka. Umowy o wyższej wartości często wymagają dokładniejszej weryfikacji i mają większy wpływ na działalność.

Skąd pobrać

W DocuSign CLM jest to zwykle pole liczbowe lub walutowe w metadanych umowy.

Przykłady
500002500001200000
Czas trwania etapu akceptacji
ApprovalPhaseDuration
Łączny czas wszystkich działań związanych z akceptacją.
Opis

Ta miara oblicza łączny czas, jaki umowa spędza na etapie akceptacji: od wysłania jej do pierwszej akceptacji wewnętrznej do uzyskania ostatniej wymaganej akceptacji. Można ją obliczyć, sumując czas trwania wszystkich działań związanych z akceptacją albo mierząc czas od rozpoczęcia pierwszego działania do zakończenia ostatniego.

Atrybut ten jest podstawą KPI „Średni czas trwania etapu akceptacji”. Pomaga oddzielić opóźnienia związane z akceptacją od tych wynikających z przygotowania projektu lub negocjacji. Śledzenie tego czasu pozwala lepiej ocenić wpływ matrycy akceptacji i wskazać możliwości jej uproszczenia.

Dlaczego to ważne

Pokazuje czas poświęcony na akceptacje, ułatwiając wykrywanie i usuwanie wąskich gardeł w tym etapie procesu.

Skąd pobrać

Wartość oblicza się w narzędziu process mining, wyszukując wszystkie zdarzenia związane z akceptacją, na przykład „Wysłano do akceptacji wewnętrznej” i „Uzyskano akceptację wewnętrzną”, a następnie mierząc czas między pierwszym a ostatnim takim zdarzeniem dla każdej sprawy.

Przykłady
5 dni 2 godziny10 dni 1 godzina2 dni 6 godzin
Dział
Department
Wewnętrzna jednostka biznesowa lub dział odpowiedzialny za umowę.
Opis

Ten atrybut wskazuje dział, na przykład sprzedaży, marketingu lub IT, który zainicjował umowę lub za nią odpowiada. Sposób obsługi umów i potrzeby mogą się różnić między działami.

Podział analizy według działów pozwala zrozumieć, jak różne części firmy korzystają z procesu zarządzania umowami. Ułatwia przygotowanie raportów, takich jak „Raport o wąskich gardłach w akceptacji umów”, które pokazują, czy opóźnienia koncentrują się w określonych jednostkach. Dzięki temu można dostosować usprawnienia do potrzeb poszczególnych działów.

Dlaczego to ważne

Umożliwia porównanie wyników różnych jednostek biznesowych i wskazuje różnice w efektywności, zgodności oraz obciążeniu pracą.

Skąd pobrać

Może to być pole metadanych umowy lub informacja ustalona na podstawie działu, do którego należy osoba odpowiedzialna za umowę.

Przykłady
SprzedażDział prawnyZakupyMarketing
Podpisana elektronicznie
IsESigned
Wartość logiczna wskazująca, czy umowę podpisano elektronicznie.
Opis

Ten atrybut wskazuje, czy umowę podpisano za pomocą zintegrowanego narzędzia do podpisu elektronicznego, takiego jak DocuSign eSignature, czy w inny sposób, na przykład odręcznie, a następnie zeskanowano.

Atrybut ten służy bezpośrednio do obliczania KPI „Odsetek umów podpisanych elektronicznie”. Analiza udziału umów podpisanych elektronicznie pozwala ocenić skuteczność działań związanych z cyfryzacją. Wyższy odsetek zwykle wiąże się z krótszym czasem podpisywania, niższymi kosztami administracyjnymi oraz lepszą zgodnością i możliwością śledzenia dokumentów.

Dlaczego to ważne

Mierzy wykorzystanie procesów cyfrowych i pozwala określić wzrost efektywności dzięki zintegrowanym funkcjom podpisu elektronicznego.

Skąd pobrać

Można to ustalić, sprawdzając, czy zdarzenie „Podpisanie umowy” pochodzi ze zintegrowanej usługi DocuSign eSignature.

Przykłady
truefalse
Prawnik
LegalCounsel
Prawnik lub członek zespołu prawnego przydzielony do weryfikacji umowy.
Opis

Ten atrybut wskazuje konkretną osobę z działu prawnego odpowiedzialną za weryfikację i akceptację umowy. Jest to inna osoba niż ta odpowiedzialna za umowę, która zwykle reprezentuje stronę biznesową.

Przypisanie weryfikacji do konkretnego prawnika umożliwia szczegółową analizę tego etapu. Pozwala przygotować dashboard „Wyniki weryfikacji prawnej” i porównać liczbę obsłużonych spraw oraz czas cyklu poszczególnych członków zespołu prawnego. Wyniki mogą pomóc w równoważeniu obciążenia i wskazaniu możliwości usprawnienia pracy działu.

Dlaczego to ważne

Umożliwia szczegółową analizę etapu weryfikacji prawnej, pomaga równoważyć obciążenie i oceniać wyniki zespołu prawnego.

Skąd pobrać

Dane pochodzą z informacji o przydziale zadań w workflow DocuSign CLM i wskazują, komu przydzielono zadanie „Weryfikacja prawna”.

Przykłady
Jennifer WaltersMatt MurdockHarvey Specter
Status akceptacji
ApprovalStatus
Status poszczególnych etapów akceptacji, na przykład „Oczekuje”, „Zaakceptowano” lub „Odrzucono”.
Opis

Ten atrybut pokazuje szczegółowy status etapu akceptacji umowy. Status umowy przedstawia ogólny stan sprawy, natomiast status akceptacji dotyczy wyniku poszczególnych działań akceptacyjnych.

Atrybut ten jest niezbędny w raportach „Raport o wąskich gardłach w akceptacji umów” i dashboardzie „Bieżący status umów”. Pokazuje, które umowy oczekują na akceptację, które odrzucono i trzeba poprawić, a które pomyślnie przeszły ten etap. Analiza zmian statusu pomaga wskazać miejsca, w których proces akceptacji zawodzi lub się opóźnia.

Dlaczego to ważne

Pokazuje szczegóły etapu akceptacji i pozwala ustalić, które umowy utknęły oraz z jakiego powodu.

Skąd pobrać

Jest to wynik zadania akceptacyjnego lub kroku workflow w DocuSign CLM.

Przykłady
Oczekuje na akceptację działu prawnegoZaakceptowano przez dział finansowyOdrzucono przez wiceprezesa ds. sprzedaży
Wersja dokumentu
DocumentVersion
Numer wersji dokumentu umowy.
Opis

Ten atrybut śledzi kolejne wersje dokumentu umowy wprowadzane podczas poprawek i nanoszenia zmian. Numer powinien zwiększać się przy każdym przesłaniu lub zapisaniu nowej wersji.

Śledzenie wersji dokumentu pozwala bezpośrednio mierzyć liczbę poprawek i złożoność negocjacji. Duża liczba wersji umowy oznacza intensywną wymianę zmian między stronami. Atrybut ten jest podstawą do obliczenia KPI „Średnia liczba poprawek dokumentu” i analizy dashboardu „Poprawki do umów i częstotliwość zmian”.

Dlaczego to ważne

Bezpośrednio mierzy liczbę poprawek i nakład pracy związany z negocjacjami, pokazując, ile razy zmieniano dokument.

Skąd pobrać

DocuSign CLM ma wbudowaną kontrolę wersji dokumentów. Atrybut ten można pobrać z historii wersji dokumentu.

Przykłady
1234
Wymagał poprawek
IsRework
Wartość logiczna wskazująca, czy umowa przeszła istotną pętlę poprawek.
Opis

Ten obliczany atrybut wskazuje umowy wymagające poprawek, na przykład takie, które po uzyskaniu wewnętrznej akceptacji ponownie skierowano do naniesienia zmian. Zwykle ustala się go na podstawie określonych, niepożądanych sekwencji działań.

Flaga ta ułatwia analizę nieefektywności procesu. Pozwala bezpośrednio obliczyć KPI „Odsetek umów wymagających poprawek” oraz filtrować umowy, które wymagały dodatkowej pracy. Dzięki temu można ustalić przyczyny poprawek, takie jak niejasne wymagania początkowe lub trudne kwestie negocjacyjne.

Dlaczego to ważne

Pozwala mierzyć i analizować częstotliwość poprawek, która wskazuje na nieefektywność procesu i ukryte koszty.

Skąd pobrać

Atrybut oblicza się w narzędziu process mining, definiując reguły wykrywające pętle poprawek, na przykład zdarzenie „Wprowadzono zmiany w umowie” występujące po zdarzeniu „Uzyskano akceptację wewnętrzną”.

Przykłady
truefalse
Wymagane Zalecane Opcjonalne

Działania w procesie zarządzania umowami

To najważniejsze kroki i kamienie milowe, które warto rejestrować w dzienniku zdarzeń, aby dokładnie odtworzyć proces zarządzania umowami.
6 Zalecane 9 Opcjonalne
Działanie Opis
Przekazanie umowy do podpisu
To zdarzenie oznacza rozpoczęcie procesu podpisu elektronicznego ostatecznej, zatwierdzonej umowy. Jest to podstawowa funkcja DocuSign. Zdarzenie jest rejestrowane, gdy użytkownik wysyła dokument w kopercie DocuSign eSignature.
Dlaczego to ważne

To ważny etap przed zawarciem umowy. Analiza czasu od tego momentu do jej zawarcia pozwala ocenić sprawność zbierania podpisów i wspiera pomiar KPI „E-Signature Adoption Rate”.

Skąd pobrać

To jawne, podstawowe zdarzenie zapisywane w szczegółowej historii dokumentu lub ścieżce audytu, często określanej jako „Envelope History”.

Rejestrowanie

Rejestrowane bezpośrednio przez system po utworzeniu i wysłaniu koperty eSignature.

Typ zdarzenia explicit
Rozpoczęcie weryfikacji prawnej
Oznacza formalne przekazanie umowy do działu prawnego w celu weryfikacji i przekazania uwag. To ważny etap, rejestrowany, gdy umowa przechodzi do etapu „Legal Review” w workflow.
Dlaczego to ważne

Weryfikacja prawna często stanowi wąskie gardło w zarządzaniu umowami. Pomiar czasu jej trwania jest ważny dla dashboardu „Legal Review Performance” i pomaga wskazać możliwości przyspieszenia pracy.

Skąd pobrać

Zdarzenie jest rejestrowane w ścieżce audytu workflow, która zapisuje timestamp przypisania zadania zespołowi prawnemu lub zmiany statusu umowy na „In Legal Review”.

Rejestrowanie

Rejestrowane przez silnik workflow, gdy umowa zostaje przypisana do zadania lub kolejki weryfikacji prawnej.

Typ zdarzenia explicit
Zakończenie umowy
To zdarzenie oznacza formalny koniec cyklu życia umowy, na przykład z powodu wygaśnięcia, anulowania lub porozumienia stron. Często jest rejestrowane po ręcznej zmianie statusu w systemie.
Dlaczego to ważne

To alternatywny punkt końcowy procesu. Śledzenie zakończeń i wygaśnięć jest niezbędne do analizy pełnego cyklu życia umowy i jej odnowień.

Skąd pobrać

Zdarzenie jest rejestrowane, gdy użytkownik zmieni pole statusu umowy na „Terminated”, „Expired” lub „Cancelled”. Wykorzystywany jest timestamp tej zmiany.

Rejestrowanie

Zdarzenie można ustalić na podstawie zmiany głównego statusu umowy na status końcowy.

Typ zdarzenia inferred
Zatwierdzenie wewnętrzne
To zdarzenie oznacza, że wszyscy wymagani zatwierdzający w organizacji zaakceptowali umowę. Jest rejestrowane, gdy ostatnia wymagana osoba zakończy swoje zadanie w workflow.
Dlaczego to ważne

To ważny etap, który oznacza, że umowa jest gotowa do negocjacji zewnętrznych lub zawarcia. Opóźnienia przed tym momentem mogą wskazywać na problemy z uzgodnieniami wewnętrznymi.

Skąd pobrać

Zdarzenie jest zapisywane w historii workflow, gdy zadanie zatwierdzenia osiąga końcowy status „Approved”.

Rejestrowanie

Rejestrowane, gdy ostatnia osoba zatwierdzająca w sekwencyjnym lub równoległym workflow zatwierdzania zaakceptuje umowę.

Typ zdarzenia explicit
Zawarcie umowy
Oznacza pomyślne zakończenie procesu zawierania umowy, gdy ostatnia wymagana osoba podpisze dokument. Zdarzenie jest rejestrowane bezpośrednio przez platformę DocuSign eSignature.
Dlaczego to ważne

To główny punkt końcowy procesu zawierania umowy. Jest niezbędny do obliczenia KPI „Average Contract Cycle Time” i pomiaru łącznej liczby umów obsłużonych w procesie.

Skąd pobrać

Timestamp zdarzenia jest zapisywany w certyfikacie ukończenia i dzienniku audytu dokumentu po zakończeniu workflow eSignature.

Rejestrowanie

Rejestrowane automatycznie przez komponent eSignature po złożeniu ostatniego podpisu.

Typ zdarzenia explicit
Zgłoszenie umowy
To zdarzenie formalnie rozpoczyna cykl życia umowy. Zwykle jest rejestrowane, gdy użytkownik przesyła formularz zgłoszenia umowy lub tworzy nowy rekord umowy w DocuSign CLM, uruchamiając powiązany workflow.
Dlaczego to ważne

To główne zdarzenie rozpoczynające proces. Jego analiza jest niezbędna do pomiaru łącznej liczby obsługiwanych umów i czasu realizacji od początku do końca.

Skąd pobrać

Zdarzenie jest rejestrowane w dzienniku audytu lub historii workflow. Odpowiada timestampowi utworzenia rekordu umowy albo przesłania formularza zgłoszeniowego.

Rejestrowanie

Rejestrowane po przesłaniu formularza rozpoczęcia obsługi umowy lub utworzeniu nowego obiektu umowy.

Typ zdarzenia explicit
Przekazanie do zatwierdzenia wewnętrznego
To zdarzenie występuje, gdy umowa po zakończeniu weryfikacji zostaje przekazana do formalnego zatwierdzenia przez wyznaczone osoby w organizacji. Jest rejestrowane po uruchomieniu workflow zatwierdzania.
Dlaczego to ważne

To początek końcowego etapu wewnętrznego zatwierdzania. Czas jego trwania jest ważnym składnikiem KPI „Average Approval Phase Duration”.

Skąd pobrać

To jawnie rejestrowana czynność w historii workflow. Użytkownik przekazuje umowę do zatwierdzenia, co powoduje przypisanie zadań osobom zatwierdzającym.

Rejestrowanie

Rejestrowane po wykonaniu czynności workflow „Send for Approval” lub podobnej.

Typ zdarzenia explicit
Przekazanie kontrahentowi
Oznacza udostępnienie dokumentu umowy kontrahentowi zewnętrznemu do weryfikacji i podpisu. Zdarzenie jest rejestrowane po użyciu w DocuSign CLM funkcji „send” lub „share”.
Dlaczego to ważne

To przekazanie sprawy stronie zewnętrznej, nad którą organizacja ma ograniczoną kontrolę. Wiedza o czasie spędzonym po stronie kontrahenta pomaga wykrywać opóźnienia zewnętrzne.

Skąd pobrać

Zdarzenie jest rejestrowane w ścieżce audytu, która zapisuje między innymi wysłanie dokumentu e-mailem z CLM lub udostępnienie go przez portal zewnętrzny.

Rejestrowanie

Rejestrowane po użyciu funkcji platformy do udostępnienia dokumentu stronie zewnętrznej.

Typ zdarzenia explicit
Przygotowanie projektu umowy
Oznacza utworzenie i ukończenie pierwszego projektu dokumentu umowy. Zdarzenie można zarejestrować, gdy pierwsza wersja dokumentu zostanie przesłana lub wygenerowana i zapisana w systemie.
Dlaczego to ważne

Śledzenie tego zdarzenia pozwala ustalić, ile czasu zajmuje przygotowanie projektu, zanim rozpocznie się jego weryfikacja. Stanowi też punkt odniesienia do pomiaru liczby późniejszych zmian.

Skąd pobrać

Zdarzenie można ustalić na podstawie timestampu utworzenia pierwszej wersji dokumentu w historii dokumentów umowy albo zmiany statusu na „Drafting Complete”.

Rejestrowanie

Wskaż zdarzenie utworzenia pierwszej wersji dokumentu powiązanej z Contract ID.

Typ zdarzenia inferred
Rozpoczęcie monitorowania zobowiązań
To zdarzenie oznacza początek zarządzania umową po jej zawarciu, kiedy monitorowane są ważne terminy i zobowiązania. Jest rejestrowane po uruchomieniu zadania lub podprocesu służącego do monitorowania zobowiązań umownych.
Dlaczego to ważne

To zdarzenie ma zasadnicze znaczenie dla KPI „Post-Execution Obligation Adherence Rate”. Pokazuje, czy zobowiązania umowne są monitorowane po podpisaniu umowy.

Skąd pobrać

Wymaga analizy systemu. Zdarzenie można prawdopodobnie ustalić na podstawie utworzenia zadań lub workflow do monitorowania zobowiązań, powiązanych z umową główną.

Rejestrowanie

Rejestrowane po utworzeniu zadania lub workflow dotyczącego zarządzania zobowiązaniami po zawarciu umowy.

Typ zdarzenia explicit
Rozpoczęcie negocjacji z kontrahentem
Oznacza, że kontrahent odpowiedział, zwykle przekazując uwagi lub zmienioną wersję umowy. Zdarzenie można ustalić, gdy strona zewnętrzna prześle nową wersję dokumentu albo status wróci do etapu weryfikacji wewnętrznej.
Dlaczego to ważne

To zdarzenie jest ważne przy analizie KPI „Negotiation Handoff Count Per Contract”. Częste przekazywanie umowy między zespołami wewnętrznymi a kontrahentem wskazuje na trudności w negocjacjach.

Skąd pobrać

Zdarzenie można ustalić na podstawie otrzymania nowej wersji dokumentu ze źródła zewnętrznego lub ręcznej zmiany statusu przez użytkownika, która oznacza otrzymanie uwag kontrahenta.

Rejestrowanie

Zdarzenie można ustalić na podstawie zmiany statusu z powrotem na „Internal Review” lub „Drafting” po przekazaniu umowy kontrahentowi.

Typ zdarzenia inferred
Rozpoczęcie odnowienia umowy
Oznacza początek procesu odnowienia istniejącej umowy. Zdarzenie jest zwykle uruchamiane ręcznie przez opiekuna umowy lub automatycznie na podstawie daty jej wygaśnięcia.
Dlaczego to ważne

To zdarzenie jest niezbędne do śledzenia KPI „Timely Contract Renewal Rate”. Pokazuje, z jakim wyprzedzeniem organizacja zajmuje się wygasającymi umowami.

Skąd pobrać

Zdarzenie jest rejestrowane po użyciu czynności „Renew Contract”. Może ona utworzyć nowy rekord umowy powiązany z pierwotną umową lub uruchomić workflow odnowienia.

Rejestrowanie

Rejestrowane po konkretnej czynności użytkownika lub automatycznym wyzwalaczu uruchamiającym workflow odnowienia.

Typ zdarzenia explicit
Rozpoczęcie weryfikacji wewnętrznej
To zdarzenie oznacza przekazanie projektu umowy do weryfikacji przez wewnętrzne działy biznesowe, na przykład finanse lub operacje. Jest rejestrowane, gdy użytkownik uruchamia zadanie „Internal Review” w workflow.
Dlaczego to ważne

To początek etapu weryfikacji, na którym często powstają wąskie gardła. Pomiar czasu jego trwania pomaga wykryć opóźnienia w przekazywaniu uwag przez zaangażowane osoby.

Skąd pobrać

Zdarzenie jest zapisywane w historii workflow, gdy status umowy zmienia się na „Internal Review” albo zadanie weryfikacji zostaje przypisane wewnętrznemu użytkownikowi spoza działu prawnego.

Rejestrowanie

Rejestrowane, gdy workflow przechodzi do stanu lub zadania przeznaczonego do wewnętrznej weryfikacji biznesowej.

Typ zdarzenia explicit
Wprowadzenie zmian w umowie
To zdarzenie oznacza zmianę lub poprawkę w dokumencie umowy w trakcie negocjacji lub weryfikacji. Jest rejestrowane za każdym razem, gdy nowa wersja dokumentu zostaje przesłana lub zapisana.
Dlaczego to ważne

Śledzenie liczby zmian jest niezbędne do obliczania KPI „Contract Rework Rate”. Duża liczba poprawek może świadczyć o niejasnych warunkach, nieefektywnych negocjacjach lub słabym pierwszym projekcie.

Skąd pobrać

Zdarzenie można ustalić na podstawie historii wersji dokumentu powiązanej z umową. Każdą nową wersję utworzoną po pierwszym projekcie można uznać za zdarzenie „Contract Redlined”.

Rejestrowanie

Rejestrowane, gdy nowa wersja dokumentu zostaje przesłana lub wygenerowana w repozytorium DocuSign CLM.

Typ zdarzenia explicit
Zapisanie umowy w repozytorium
To ostatni krok administracyjny. W pełni podpisana umowa zostaje automatycznie zapisana w centralnym repozytorium umów. Zdarzenie jest zwykle uruchamiane po zakończeniu procesu podpisywania.
Dlaczego to ważne

Zapewnia prawidłowe zakończenie procesu i zapisanie dokumentacji. Oznacza koniec cyklu życia umowy przed jej zawarciem oraz początek etapu po zawarciu.

Skąd pobrać

Rejestrowane w historii workflow jako zakończenie ostatniego kroku, który archiwizuje podpisany dokument.

Rejestrowanie

Rejestrowane przez silnik workflow jako ostatni zautomatyzowany krok po pomyślnym zawarciu umowy.

Typ zdarzenia explicit
Zalecane Opcjonalne

Instrukcje pozyskiwania danych

Jak pobrać dane z DocuSign CLM

Jak zacząć?

Skorzystaj z tego szablonu danych, aby rozpocząć analizę procesu i znaleźć możliwości usprawnienia workflow zarządzania umowami.

Ogranicz opóźnienia i usprawnij zarządzanie umowami

Wskaż nieefektywne działania, skróć czas realizacji o 30% i popraw zgodność.

Rozpocznij okres próbny

Karta kredytowa nie jest wymagana • Rozpoczęcie zajmuje kilka minut