Quick Guide. De Cloud voor Contracten. MOCHADOCS Kennis Support. Quick Guide. Dit werk is auteursrechtelijk beschermd 2014 Pagina: 1 van 25

Quick Guide

MOCHADOCS Kennis Support Quick Guide Dit werk is auteursrechtelijk beschermd © 2014 Pagina: 1 van 25

De Cloud voor Contracten

Uitgave en copyright: Mochadocs B.V. Hanze Stede Diamantstraat 3 7554 TA Hengelo MochaDocs en al bijhorende werken zijn auteursrechtelijk beschermd. Alle rechten voorbehouden. Niets uit deze uitgave mag worden verveelvoudigd, opgeslagen in een geautomatiseerd gegevensbestand, of openbaar gemaakt, in enige vorm of op enige wijze, hetzij elektronisch, mechanisch, door fotokopieën, opnamen of op enige andere manier, zonder voorafgaande schriftelijke toestemming van de auteur. Disclaimer De redactie van MochaDocs besteedt de grootst mogelijke aandacht aan de juistheid van informatie in deze Convention Guide. Fouten zijn echter niet volledig uit te sluiten. U kunt daarom geen rechten ontlenen aan deze teksten.

Aanvragen informatie over en gebruik van MochaDocs: Mochadocs B.V. Hanze Stede Diamantstraat 3 7554 TA Hengelo www.mochadocs.com [email protected]


Inleiding In de kern is het managen van contracten terug te brengen naar drie belangrijke onderdelen: 1. Hoe manage je de einddatum van een contract (randvoorwaardelijk)? 2. Waar is het contract (randvoorwaardelijk)? 3. Welke inhoud van een contract laat je op welke manier door wie managen (afhankelijk van inhoud)? MochaDocs heeft over de afgelopen jaren intensief onderzoek verricht naar falende p+rojecten binnen het implementeren van Contract management binnen organisaties. In de kern kunnen we stellen dat de meeste organisaties die willen starten met het inrichten van Contract Management vaak te complex starten. Deze uitgaven bevat een dosering aan van de mogelijk onderdelen die in een start kunnen worden ingezet. Let wel: Niet alle onderdelen zijn per definitie noodzakelijk, zeker niet. De kernvragen staan hierboven benoemd en vormen de rode draad voor de de start van een dagelijkse Contract Mangement Discipline. Deze Quick Guide geeft je daarom een indruk van de activiteiten die je als CMO (Contract Management Office) in combinatie met de MochaDocs (Contract Management Software). Achter in deze uitgave tref je een samenvatting aan waardoor alle besproken punten nog eens op een rij staan. Mocht je de bijhorende oplossing willen proberen neem dan contact op met MochaDocs voor een demo of een test omgeving. Dat kun je doen door een demo aan te vragen via www.mochadocs.com met vriendelijke groet,

Huib van de Struik MochaDocs


Central MochaDocs Office (CMO) Binnen de organisatie zullen alle leden van een team (hierna CMO) verantwoording moeten nemen voor het opstellen, uitvoeren en handhaven van de in dit handboek opgestelde conventies. Het CMO moet een applicatiebeheerder aanstellen voor het beheer van de MochaDocs Cloud applicatie. De applicatie beheerder vertaalt de gemaakte conventies in de die zorgt het afstemmen van de configuratie van MochaDocs en het Handboek. Daarnaast is het CMO verantwoordelijk voor het definiëren van de rechten binnen MochaDocs. Het CMO kan tevens een applicatiebeheerder aanstellen voor het inregelen en bijhouden van de rechten van gebruikers in de MochaDocs Cloud applicatie.

Wie is de eigenaar van het conventiehandboek en zorgt ook voor het bijwerken en distributie ervan? Daarnaast is het CMO verantwoordelijke voor de communicatie van wijzigingen.

Stap 1 - Het CMO ●

Definieer wie binnen het conventiehandboek waarvoor verantwoordelijk is en leg dit vast.

●

Definieer hoe de distributie van het handboek verloopt en leg dit vast

●

Definieer hoe de communicatie van wijzigingen binnen de organisatie verloopt en leg dit vast

●

Definieer wie verantwoordelijk is voor het aanpassen van rechten van gebruiken en leg dit vast


Contract Hiërarchie MochaDocs is de grondlegger van de methode waarbij eerst gekeken wordt naar de hiërarchie van het contract en daarna pas naar de hiërarchie van de organisatie waarin het contract gemanaged moet worden.

Binnen deze structuur kan een onderwerp echt alles zijn. Het kan een paragraaf van een contract zijn maar kan ook iets zijn wat niet in het contract staat omschreven zoals een tussentijdse interne evaluatie.

Het vereenvoudigd schema treft u rechts aan. Elke “bubble” heeft een eigenaar. Op het hoogste

niveau

is

de

contracteigenaar.

Daaronder kan een onderwerpeigenaar zitten. Onder een onderwerp kan vervolgens weer een taak eigenaar zitten en daaronder kan een financiële data eigenaar zitten. Zowel de taak als de financiële waarde kunnen rechtstreeks worden gehangen aan het contract en de financiële waarde kan eveneens rechtstreeks worden gehangen aan het onderwerp. Documenten kunnen rechtstreeks aan contracten, onderwerpen en taken worden gehangen. Door deze structuur kan er per contract een hiërarchie ontstaan. Indien deze hiërarchie te benoemen is in het conventiehandboek, is het zaak dit te doen. U treft die informatie aan op de volgende pagina(s).

Contractsoorten definiëren MOCHADOCS Kennis Support Quick Guide Dit werk is auteursrechtelijk beschermd © 2014 Pagina: 5 van 25

Een vuistregel binnen het definiëren van contractsoorten is dat het verstandig is om te starten met 7 contractsoorten. Het geeft goed overzicht en het dwingt de organisatie niet in detail; te treden, iets wat snel wil gebeuren. We hebben een set van 7 contractsoorten opgenomen in de bijlage bij deze template. Het geldt slecht als indicatie.

Stap 2 - contractsoorten definiëren ●

Definieer ongeveer 7 contractsoorten maar dan zo dat alle contracten van de organisatie ergens in deze 7 passen. Het gebruik van contractsoort “overig”, “diverse” of soortgelijke soort moet je niet laten toestaan. Voorbeelden zijn: ○

abonnement

○

diensten

○

geheimhoudingsverklaring (NDA)

○

onderhoudscontract

○

leasecontract

○

service level agreement (SLA)

○

inkoopcontract

○

verkoopcontract

○

vergunning

○

IT contract

○

telecom contract

○

huisvestingscontract

○

partnercontract

○

personeelscontract

Een logische stap bij het definiëren van een contractsoort is ook het nadenken of er bij een contractsoort ook een herinnering moet worden gestuurd gerelateerd aan de einddatum (of opzegtermijn) van de contractsoort. En zo ja, wanneer deze melding moet komen? Het betreft hier alleen onderwerpen en taken die als standaard voor die contractsoort kunnen worden gedefinieerd. Een voorbeeld is een taak gerelateerd aan een bankgarantie / borgstelling (het onderwerp) van een vastgoed overeenkomst. Een dergelijke taak (en onderwerp) is veelvuldig van toepassing op vastgoedcontacten. MOCHADOCS Kennis Support Quick Guide Dit werk is auteursrechtelijk beschermd © 2014 Pagina: 6 van 25

Stap 3 - standaard taak einddatum ●

Definieer per contractsoort de periode die benodigd is om te bepalen of een contract moet worden opgezegd, heronderhandeld moet worden of moet worden beëindigd.

Een tweede logische stap bij het definiëren van een contractsoort is het nadenken of er bij een bepaald contractsoort ook onderwerpen zijn die altijd een rol spelen bij die contractsoort. Een voorbeeld daarvan is bijvoorbeeld een onderwerp: “Bankgarantie/Borgstelling” bij een contractsoort gerelateerd aan Vastgoed. Zo kunnen er veel meer onderwerpen zijn die bij bepaalde contractsoorten standaard kunnen worden opgenomen.

Stap 4 - standaard onderwerp contractsoort ●

Definieer per contractsoort de onderwerpen die standaard bij die contractsoort altijd kunnen worden opgenomen (dit kunnen bijvoorbeeld ook paragrafen uit het contract zijn). Voorbeelden zijn: ○

tussentijdse evaluatie

○

bonus

○

penalty

○

opzegging

○

borg/bankgarantie

○

aansprakelijkheid

○

prijsafspraken

○

prijsstijgingen

○

gespreksverslag

Nu per contractsoort onderwerpen zijn gedefinieerd kunnen ook bijhorende taken gedefinieerd worden. Welke taken horen bij welke onderwerpen en wanneer moeten deze worden geactiveerd?

Stap 5 - standaard taak of taken onder een onderwerp


●

Definieer per contractsoort en per onderwerp welke taken wanneer moeten worden geactiveerd.

●

Definieer vervolgens per taak wanneer de notificatie naar de taakeigenaar moet worden gestuurd.

Stap 6 - aanbesteding / tender (zie ook stap 22) Met het definiëren van contractsoorten stelt de CMO de organisatie in staat om elke vorm van “workflow” te benoemen bij bepaalde contractsoorten.

●

Benoem de verschillende aanbestedingen.

●

Definieer de verschillende aanbestedingen als activiteitenproces.

Entiteiten definiëren Het doel van het benoemen van verschillende entiteiten is dat een enkel contract in verschillende entiteiten een rol kan spelen. Organisaties worden vaak in beeld gebracht met behulp van een organigram. Toch kan het zijn dat de operationele opbouw van een organisatie gebaseerd op een matrix organisatie of gewoonweg op een geografische ligging. En ook divisies, afdelingen en andere vormen van de organisatie kunnen ook aan de standaard wijze van het in beeld brengen van de organisatie worden toegevoegd. Zoals we eerder hebben lezen in deze template is de contract hiërarchie een bepalende factor in het managen van contracten. Zo is dat ook de situatie in het in beeld brengen van de verschillende entiteiten van de organisatie. Dit betekent dat er bij het in beeld brengen van entiteiten altijd wordt vanuit het managen van contracten. Hiermee start het benoemen van entiteiten. De basis van het managen van contracten ligt bij het eigenaarschap van die contracten en de onderdelen daarvan. Dus Wie is de eigenaar van een contract en wat is de rol van deze persoon binnen de organisatie en waar liggen de verantwoordelijkheden.

Stap 7 - onderzoek entiteitenbepaling ●

Benoem de verschillende eigenaren van contracten

●

Benoem de rol(len) van de verschillende contracteigenaren

●

Benoem de fysieke positie van de verschillende contracteigenaren. MOCHADOCS Kennis Support Quick Guide Dit werk is auteursrechtelijk beschermd © 2014 Pagina: 8 van 25

●

Benoem de verschillende divisies, locaties, afdelingen, departementen, units, branches, onderdelen of/en organisaties begrippen waar de contracteigena(a)r(en) zich begeven.

Op basis van bovenstaande gegevens kan er een duidelijke basis worden gelegd voor het definiëren van de verschillende entiteiten.

Documentsoorten definiëren Een belangrijk onderdeel van het managen van contracten is het hebben van een systeem waarin contracten makkelijk kunnen worden terug gevonden. Vaak zijn er echter meer documenten betrokken bij een contract denk maar eens aan orderformulieren, offertes, bijlagen, certificaten en zo verder. Het inrichten van de manier van digitaal opslaan van de documenten in combinatie met contract management kan eenvoudiger worden gemaakt door de verschillende documenten typeringen mee te geven.

Stap 8 - Documentsoorten definiëren ●

Definieer alle documentsoorten binnen de organisatie. Voorbeelden zijn; ○

origineel contract

○

oude versie origineel contract

○

addendum

○

certificaat

○

factuur

○

orderformulier

○

verslag

○

rapport

○

offerte

○

evaluatieverslag

○

verklaring

Stap 9 - Documentnaam conventie maken MOCHADOCS Kennis Support Quick Guide Dit werk is auteursrechtelijk beschermd © 2014 Pagina: 9 van 25

Ondanks dat documenten te typeren zijn kan aan documenten identificatie worden gegeven. Hierbij kan gedacht worden aan een beschrijving. Zo’n beschrijving kan elke vorm aannemen. Indien het voor de organisatie raadzaam is daarin structuur aan te brengen is het raadzaam om deze structuur op te nemen in het Conventiehandboek

●

Definieer een document beschrijvingsstructuur indien van toepassing.

Document opslag conventie Binnen het MochaDocs (hiërarchische) mechanisme is een eenvoudige en intuïtieve

wijze van

documentopslag gedefinieerd. Dit betekent in de praktijk dat gebruikers documenten aan alle componenten van een contract kunnen hangen mits ze daartoe geautoriseerd zijn. De documenten op eenvoudige intuïtieve wijze op de juiste plek onder het contract gehangen. De voordelen daarvan zijn veelzijdig: ●

documenten zijn direct op autorisatie basis te raadplegen.

●

documenten zitten direct op de juiste plaats in het contract en zijn daardoor makkelijk terug te vinden.

●

Op het hoogste niveau zijn alle documenten te raadplegen mits geautoriseerd.

●

Op het hoogste niveau kan de gebruiker direct zien waar het document in de contract hiërarchie zich bevindt.


Waarom een document opslag conventie?

Dit voorkomt dat de opslag van documenten na verloop van tijd onoverzichtelijk gaat worden door grote hoeveelheden documenten en contracten. Voor de opslag van documenten in contracten heeft MochaDocs een standaardindeling ontworpen gebaseerd op de contract hiërarchie.

De indeling is

makkelijk documenten kunnen worden gevonden en geraadpleegd. Indien een onderwerpeigenaar of contracteigenaar meerdere onderwerpen kunnen aanpassen dan kunnen ook documenten onder meerdere onderwerpen worden gehangen. Ondanks dat het logisch is en daardoor eigenlijk niet fout kan gaan een document onder het juiste onderwerp te hangen (of onder de juiste taak) is het handig een conventie op te nemen in het conventiehandboek zodat de gebruiker het handboek kan raadplegen in geval van twijfel.

Stap 10 - Documentopslag definiëren ●

Benoem de wijze waarop documentsoorten moeten worden opgeslagen binnen een contract. Denk hierbij altijd aan de contract hiërarchie want de hiërarchie is tevens bepalend wie welke componenten kan zien en de daarbij horende documenten.

Financiële waardes definiëren Waardevolle financiële informatie staat vaak in contracten. Het is dus de kunst om op eenvoudige wijze MOCHADOCS Kennis Support Quick Guide Dit werk is auteursrechtelijk beschermd © 2014 Pagina: 11 van 25

deze waarde uit alle contracten in beeld te brengen waardoor de organisatie in staat wordt gesteld snel en doeltreffend financiële informatie uit alle contracten te halen, of een deel daarvan. Voorbeeld daarvan is het afzetten van alle uitgaven in een bepaalde periode van de organisatie af te zetten tegen hetgeen in contracten is vastgelegd. Alle uitgaven die in contracten zijn vastgelegd zijn goed voorspelbaar.

Stap 11 - Financiële waardes definiëren ●

Definieer de financiële waardes die de organisatie uit contracten in beeld wil gaan krijgen. Voorbeelden zijn; ○

aansprakelijkheid

○

kosten per jaar

○

kosten per kwartaal

○

kosten per maand

○

kosten per week

○

indexatie

○

budget

○

penalty

○

bonus

○

totale contractwaarde

○

borgstelling

○

premie

○

uurtarief

○

verkoopwaarde

○

verzekerde waarde

○

factuurwaarde

Naast het definiëren van financiële waardes is het vastleggen van de conventie hoe om te gaan met deze financiële waardes eveneens van belang. De financiële waardes zijn vaak datum gerelateerd. Een voorbeeld daarvan is de contractwaarde per jaar of een betaling per maand. De houdbaarheidsperiode van een een financiële waarde kan per financiële waarde worden vastgelegd in het conventiehandboek. Het is


aan het CMO te bepalen welke financiële waarde vast moet worden gerelateerd aan een periode.

Stap 12 - Datum relaties financiële waardes definiëren ●

Definieer hoe binnen de organisatie wordt omgegaan met de datumnotatie van financiële waardes.

Het hebben van een financiële waarde alleen is vaak voor het managen van contracten niet toereikend. Handig is daarom het kunnen opnemen van opmerkingen over die financiële waarde. Voorbeeld kan zijn “Percentage 2012 geld niet meer. Dit percentage toepassen”. Dergelijke opmerkingen worden opgenomen bij het getal waardoor een getal op individueel niveau een andere betekenis kan krijgen.

Stap 13 - Het toepassen van opmerkingen bij financiële waarden ●

Definieer of en hoe opmerkingen kunnen worden toegepast bij financiële waarden.

Om het voor de gebruiker makkelijk te maken om te gaan met valuta in contracten is het mogelijk om de benodigde valuta’s te selecteren in de setup van MochaDocs. Hierdoor wordt MochaDocs beperkt tot een voorgeselecteerde set valuta’s.

Stap 14 - Valuta’s bij financiële waarden ●

Het CMO selecteert de te gebruiken valuta’s binnen het financiële gedeelte van MochaDocs.

Algemene Conventie(s) definiëren Nu alle componenten in beeld zijn gebracht kunnen de overige conventies worden gedefinieerd. Conventies zijn de afspraken die de CMO maakt waaraan de organisatie zich moet houden wil er een maximale waarde worden behaald met het managen van contracten. Deze afspraken hebben een direct relatie met alle hiervoor benoemde componenten van de contracten of de organisatie.

Ook is dit het deel van het handboek waarin ruimte is om afgesproken processen in beeld te brengen.


Automatiseren Contracten Register Misschien wel één van de grootste wensen van een auditor of een accountant is het kunnen terugvinden van alle actuele contracten. En dat is dat direct de ook een grote pijn van de organisatie: het actueel houden van contractuele data. Alles binnen MochaDocs is er op gericht het voor de gebruiker zo makkelijk mogelijk te maken. De geautomatiseerde administratieve verwerking van actuele en gearchiveerde contracten is daar een mooi voorbeeld van. Dit betekent dat MochaDocs er voor zorgt dat alle einddatums van de contracten actueel zijn (dus of vandaag aflopen of in de toekomst). De vraag die door het CMO beantwoordt moet worden is of het wenselijk is dit register geautomatiseerd te laten verlopen of dat het handmatig gebeurd.

Bij het geautomatiseerd laten verlopen is het belangrijk in de conventie van het invoeren van een nieuwe contract de wijze waarop dit wordt gedaan uniform af te spreken. Bij het geautomatiseerd laten verlopen van het contractenregister moeten de volgende informatie correct worden ingevoerd: ●

startdatum

●

einddatum (of onbepaalde tijd)

●

opzegtermijn

●

bevat het contract een automatische verlengingsclausule?

●

Zo ja, wat is de verlengtermijn

Stap 15 - Het toepassen van een geautomatiseerd contractenregister. ●

Definieer met het CMO of de Cloud voor Contracten van MochaDocs wordt ingesteld op het geautomatiseerd bijhouden contractenregister.

Verlengingsclausule standaard aan of uit In de set-up voorkeursinstellingen kan er gekozen worden om de standaard clausule verlengingstermijn automatisch aan of uit te vinken voor de invoer van nieuwe contracten. Als er meer contracten met dan zonder verlengingsclausule worden ingevoerd vink dan de checkbox aan. En natuurlijk andersom.


Standaard notificatie instellingen Gebruikers van MochaDocs die de schrijfmogelijkheid hebben kunnen taken uitvoeren maar ook aanmaken. Bij het aanmaken van een taak is het nodig om de notificatie periode af te stemmen op de einddatum van de taak. Dat kan handmatig maar ook met behulp van een standaard instelling (is handmatig aanpasbaar). Het CMO bepaalt wat de standaard notificatietermijn is bij het aanmaken van een taak. Ervaring wijst uit dat 31 dagen een veel gekozen standaard is voor die periode.

Stap 16 - Standaard notificatie periode bepalen ●

definieer standaard systeeminstelling voor de notificatietermijn voor taken die worden aangemaakt door gebruikers. Gebruikers zijn nog steeds in staat zelfstandig deze standaard instelling aan te passen op taak niveau.

Een gebruiker van MochaDocs die taken krijgen toegezonden per email kan ook meerdere taken per dag krijgen. Tijdens het configureren van MochaDocs is het mogelijk alle taken van een dag in een enkelvoudige email te ontvangen maar ook is het mogelijk alle taken afzonderlijk te laten versturen. Indien deze taken stuk voor stuk afgewerkt moeten worden door een gebruiker is het wellicht handig deze taken per stuk te krijgen en niet alle taken in 1 email.

Stap 17 - Standaard alle notificatie afzonderlijk versturen ●

definieer standaard systeeminstelling voor het versturen van notificaties: per stuk of samengevoegd per gebruiker per dag.

Alle notificatie e-mails worden standaard gestuurd met het e-mailonderwerp “Notificatie van MochaDocs”. Deze tekst is echter aan te passen in een tekst die meer voor de organisatie van toepassing kan zijn. Daarnaast is het mogelijk om zowel de contractnaam als het onderwerpnaam op te nemen in het e-mailonderwerp. Zonder notificatie e-mail te openen weet te ontvanger over welk contract het gaat en eventueel welk onderwerp


Stap 18 - Onderwerp notificatie e-mail van de taak ●

Definieer of er eigen tekst wordt gebruikt bij een e-mail notificatie onderwerp van de taak

●

Definieer welke eigen tekst wordt gebruikt bij een e-mail notificatie onderwerp van de taak

●

Definieer of de contractnaam bij een e-mail notificatie onderwerp van de taak wordt meegezonden

●

Definieer of de onderwerpnaam bij een e-mail notificatie onderwerp van de taak wordt meegezonden

Er kan bij de bepaling van contractsoorten gekozen zijn voor een organisatie specifieke benaming van het contractsoort. In de instellingen kan geselecteerd worden dat ook de benaming van het contractsoort worden meegegeven in de e-mail notificatie van de taak.

Stap 19 - Contractsoort benaming in e-mail notificatie ●

Bepaal of de contractsoort benaming wordt meegezonden in de e-mail notificatie van de taak.

In een e-mail notificatie van een taak kunnen de financiële gegevens van die taak worden meegestuurd. deze zijn regelbaar in de set-up. Indien een financiële waarde aan een taak wordt gekoppeld kan het dus praktisch zijn deze informatie mee te sturen met de notificatie e-mail. De financiële gegevens in een taak kunnen zijn: ●

Naam

●

Waarde

●

Eenheid (valuta)

●

Opmerkingen

●

Begindatum financiële waarde

●

Einddatum financiële waarde


Stap 20 - Financiële waarden in een e-mail notificatie ●

Besluit of de financiële waardes in taken als standaard kunnen worden meegestuurd met een email notificatie

●

Definieer welk financiële informatie naar Naam, Waarde en Eenheid (valuta) kunnen worden meegestuurd met een e-mail notificatie


Contract Hiërarchie en het Escalatieproces In tegenstelling tot veel processen binnen organisaties hebben contracten een eigen procesgang met bijhorende hiërarchie. Het escaleren van een probleem bij de operationele uitvoer van een taak is op basis van het contract gebaseerd, niet op basis van de organisatorische uitvoer (hoewel dit in de praktijk wel vaak overeenkomstige situaties zijn).

Van

belang

is

dus

te

escaleren

binnen

de

verantwoordingen van het contract, of beter gezegd wie er verantwoordelijk is voor een bepaald deel van een contract met bijhorende taken. Wat nu indien de taak niet tijdig voor de einddatum van die taak wordt uitgevoerd?

Door de simpele en tegelijkertijd doeltreffende contract hiërarchie zijn alle stappen escalatie stappen eenvoudig te definiëren. MochaDocs voorziet in een escalatie via een onderwerpeigenaar en dan naar de contracteigenaar of, indien er geen onderwerp is, rechtstreeks naar de contracteigenaar. We doen dat op basis van een percentage

van

de

verstreken

tijd

tussen

het

notificatiemoment en de einddatum van de taak. Is er een y% tijd verstreken en de taak is niet gereed dan zal de taak escaleren naar de onderwerpeigenaar. Is er vervolgens een x% tijd verstreken en de taak is nog steeds niet gereed dan zal de contracteigenaar worden genotificeerd.


Stap 21 - Escalatiemomenten ●

Definieer wanneer er een escalatie notificatie moet worden gestuurd naar de onderwerp eigenaar indien de taak nog niet op gereed staat (y%)

●

Definieer wanneer er een escalatie notificatie moet worden gestuurd naar de contracteigenaar indien de taak nog niet op gereed staat (x%).


Nu we de basisbeginselen van Contract Management volgens het Hiërarchische model hebben doorlopen kunnen we verfijningen aanbrengen in de wijze waarop er gewerkt gaat worden. Per contractsoort kunnen conventies worden gedefinieerd. Er zullen onderwerpen en taken voor te definiëren zijn voor een contractsoort die voor ieder contract uit die soort altijd geldig zullen zijn. Daarnaast kunnen er per contract individuele onderwerpen zijn die later kunnen worden toegevoegd nadat het contract is aangemaakt in MochaDocs. De tekening hieronder laat een contractsoort zien met een opbouw van allerlei voorgedefinieerde onderwerpen en taken eruit kan zien. De lichtblauwe bubbles zijn standaard aangemaakt, de witte zijn aangemaakt door de contracteigenaar nadat het getekende contract werd

geregistreerd in MochaDocs.

Stap 22 - Contractsoort templates aanmaken MOCHADOCS Kennis Support Quick Guide Dit werk is auteursrechtelijk beschermd © 2014 Pagina: 20 van 25

●

Definieer welke onderwerpen per contractsoort als standaard kunnen worden geconfigureerd (de licht blauwe bubbles uit het figuur).

●

Definieer welke taken als standaard per onderwerp kunnen worden gedefinieerd (de licht blauwe bubbles uit het figuur)


Samenvatting vragen Stap 1 - Het CMO ●

Definieer wie binnen het conventiehandboek waarvoor verantwoordelijk is en leg dit vast.

●

Definieer hoe de distributie van het handboek verloopt en leg dit vast

●

Definieer hoe de communicatie van wijzigingen binnen de organisatie verloopt en leg dit vast

●

Definieer wie verantwoordelijk is voor het aanpassen van rechten van gebruiken en leg dit vast

Stap 2 - Contractsoorten definiëren ●

Definieer 7 contractsoorten maar dan zo dat alle contracten van de organisatie ergens in deze 7 passen. Het gebruik van contractsoort “overig”, “diverse” of soortgelijke soort is niet toegestaan.

Stap 3 - default taak einddatum ●

Definieer per contractsoort de periode die benodigd is om te bepalen of een contract moet worden opgezegd, heronderhandeld moet worden of moet worden beëindigd.

Stap 4 - default onderwerp contractsoort ●

Definieer per contractsoort de onderwerpen die standaard bij die contractsoort altijd kunnen worden opgenomen

Stap 5 - default taak of taken onder een onderwerp ●

Definieer per contractsoort en per onderwerp welke taken wanneer moeten worden geactiveerd.

●

Definieer vervolgens per taak wanneer de notificatie naar de taakeigenaar moet worden gestuurd.

Stap 6 - aanbesteding / tender (zie ook stap 22) ●

Benoem de verschillende aanbestedingen.

●

Definieer de verschillende aanbestedingen als activiteitenproces.

Stap 7 - onderzoek entiteitenbepaling ●

Benoem de verschillende eigenaren van contracten

●

Benoem de rol(len) van de verschillende contracteigenaren

●

Benoem de fysieke positie van de verschillende contracteigenaren.

●

Benoem de verschillende divisies, locaties, afdelingen, departementen, units, branches, onderdelen of/en organisaties begrippen waar de contracteigena(a)r(en) zich begeven.


Stap 8 - Documentsoorten definiëren ●

Definieer alle documentsoorten binnen de organisatie.

Stap 9 - Documentnaam conventie maken ●

Definieer een document beschrijvingsstructuur indien van toepassing.

Stap 10 - Documentopslag definiëren ●

Benoem de wijze waarop documentsoorten moeten worden opgeslagen binnen een contract. Denk hierbij altijd aan de contract hiërarchie want de hiërarchie is tevens bepalend wie welke componenten kan zien en de daarbij horende documenten.

Stap 11 - Financiële waardes definiëren ●

Definieer de financiële waardes die de organisatie uit contracten in beeld wil gaan krijgen.

Stap 12 - Datum relaties financiële waardes definiëren ●

Definieer hoe binnen de organisatie wordt omgegaan met de datumnotatie van financiële waardes.

Stap 13 - Het toepassen van opmerkingen bij financiële waarden ●

Definieer of en hoe opmerkingen kunnen worden toegepast bij financiële waarden.

Stap 14 - Valuta’s bij financiële waarden ● Het CMO selecteert de te gebruiken valuta’s binnen het financiële gedeelte van MochaDocs.

Stap 15 - Het toepassen van een geautomatiseerd contractenregister. ●

Definieer met het CMO of de Cloud voor Contracten van MochaDocs wordt ingesteld op het geautomatiseerd bijhouden contractenregister.

Stap 16 - Standaard notificatie periode bepalen ●

definieer standaard systeeminstelling voor de notificatietermijn voor taken die worden aangemaakt door gebruikers. Gebruikers zijn nog steeds in staat zelfstandig deze standaard instelling aan te passen op taak niveau.

Stap 17 - Standaard alle notificatie afzonderlijk versturen ●

definieer standaard systeeminstelling voor het versturen van notificaties: per stuk of samengevoegd per gebruiker per dag.


Stap 18 - Onderwerp notificatie e-mail van de taak ●

Definieer of er eigen tekst wordt gebruikt bij een e-mail notificatie onderwerp van de taak

●

Definieer welke eigen tekst wordt gebruikt bij een e-mail notificatie onderwerp van de taak

●

Definieer of de contractnaam bij een e-mail notificatie onderwerp van de taak wordt meegezonden

●

Definieer of de onderwerpnaam bij een e-mail notificatie onderwerp van de taak wordt meegezonden

Stap 19 - Contractsoort benaming in e-mail notificatie ●

Bepaal of de contractsoort benaming wordt meegezonden in de e-mail notificatie van de taak.

Stap 20 - Financiële waarden in een e-mail notificatie ●

Besluit of de financiële waardes in taken als standaard kunnen worden meegestuurd met een e-mail notificatie

●

Definieer welk financiële informatie naar Naam, Waarde en Eenheid (valuta) kunnen worden meegestuurd met een email notificatie

Stap 21 - Escalatiemomenten ●

Definieer wanneer er een escalatie notificatie moet worden gestuurd naar de onderwerp eigenaar indien de taak nog niet op gereed staat (y%)

●

Definieer wanneer er een escalatie notificatie moet worden gestuurd naar de contracteigenaar indien de taak nog niet op gereed staat (x%).

Stap 22 - Contractsoort templates aanmaken ●

Definieer welke onderwerpen per contractsoort als standaard kunnen worden geconfigureerd (de licht blauwe bubbles uit het figuur).

●

Definieer welke taken als standaard per onderwerp kunnen worden gedefinieerd (de licht blauwe bubbles uit het figuur)


Aanvragen informatie over en gebruik van MochaDocs:

Mochadocs B.V. Hanze Stede Diamantstraat 3 7554 TA Hengelo www.mochadocs.com [email protected]


Quick Guide. De Cloud voor Contracten. MOCHADOCS Kennis Support. Quick Guide. Dit werk is auteursrechtelijk beschermd 2014 Pagina: 1 van 25

Recommend Documents