Szablon danych do zarządzania umowami
Szablon danych do zarządzania umowami
- Zalecane atrybuty do zebrania
- Najważniejsze działania do śledzenia
- Wskazówki dotyczące pozyskiwania danych
Atrybuty zarządzania umowami
| 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
|
|||
Działania w procesie zarządzania umowami
| 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
|
|||
Instrukcje pozyskiwania danych
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ść.
Karta kredytowa nie jest wymagana • Rozpoczęcie zajmuje kilka minut