Leverancier klantrelatie
Leverancier en klant hebben een relatie voor een specifiek project.
Bij omvangrijke (turnkey) projecten is veel overleg noodzakelijk. Daar zijn meerdere personen van zowel de leverancier als de klant bij betrokken. Vaak zijn de details zeer groot wat volume betreft en accuratesse voor elk detail is cruciaal voor het goed functioneren van het eindproduct. In die situaties is een wiki voor een leverancier-klant-relatie een goede oplossing.
Inhoud |
Details
Bij een groot project moet precies beschreven staan wat de specificatie van een bepaalde moer, pomp, of bij software wat de validatieregels zijn voor een bepaald invoerveld. Ongeveer is niet goed genoeg. Het is ook niet goed genoeg dat de specificatie 3 weken geleden "x" was. Het gaat er om wat actuele specificatie, actuele kennis is. Deze moet altijd up to date zijn. Uiteraard kunnen de specificaties zich, door voortschrijdend inzicht, wijzigen. Dat kan. Maar zelfs dan moeten altijd de meest recente gegevens getoond worden, zonder mitsen en maren, met eventueel de bijbehorende geschiedenis van de wijzigingen.
Volume
Bij een omvangrijk project zijn zeer veel details noodzakelijk. Dat volume van details moet beheerst kunnen worden. En bovendien moet het overzicht behouden blijven. Er is geen maximum van het aantal details wat in een project wordt gebruikt. Wel is er sprake van fair use. Een wiki moet niet misbruikt worden voor doeleinden waarvoor het niet geschikt is. In de praktijk betekent dit dat vrijwel elk project hiermee haalbaar is.
Meerdere personen
Bij zowel de leverancier als de klant zijn bij grote projecten meerdere personen betrokken. En iedere persoon heeft zijn eigen invalshoek. Maar toch heeft elke invalshoek raakvlakken met andere invalshoeken. Doordat alle gegevens van het hele project in één wiki staan, staan deze gegevens tot ieders beschikking. Het essentiële overleg vindt uiteraard plaats door middel van vergaderingen. Maar door de details vooraf uit te werken in een wiki kan de vergadering efficiënter verlopen. De vergadering kan dan echt over de hoofdzaken gaan.
Leverancier
Een wiki heeft voor de leverancier als voordeel dat alle gegevens betreffende het project gedeeld worden met de klant. Deze kan ze inzien en desnoods wijzigen als hij ze onjuist vindt. De historie wordt vastgelegd en de leverancier krijgt een melding wanneer er een aanpassing plaats vindt. Dit lijkt chaos te worden maar in de praktijk is dit juist niet zo. Omdat de historie van elke wijziging wordt vastgelegd is het moeilijker voor een klant om zomaar een specificatie te geven en deze later om te gooien. Dat blijft namelijk altijd zichtbaar. Dit werkt zorgvuldigheid in de hand.
Bevriezen
In een bepaald stadium worden er keiharde afspraken gemaakt. Beide partijen gaan hiermee akkoord. Dan is het belangrijk dat die afspraken daarna niet meer gewijzigd mogen worden. Dat kan door de afspraken te "bevriezen". In de meeste wiki's is dit mogelijk.
Klant
Een klant wil graag het product gerealiseerd zien dat hij voor ogen heeft. Aan loze beloften heeft hij niets. Vandaar dat een wiki een goed middel voor de klant is om de toezeggingen betreffende zijn specificatie in een wiki vastgelegd te zien worden. Als er dan later een overschrijding in tijd zou zijn, of dat een specificatie niet gerealiseerd is dan is dat in de wiki aantoonbaar.
Wie start de wiki op
De klant of de leverancier? Dat kunnen beiden zijn. Diegene die het belangrijk vindt dat de afspraken nagekomen worden en miscommunicatie voorkomen dient te worden kan daarvoor kiezen. Dat kan zowel de leverancier zijn als de klant. Het belang van de andere partij dient echter wel dusdanig groot te zijn dat deze bereid is een wiki toe te passen. Wikiation kan hierbij ondersteuning verlenen. Wikiation heeft bij een klant-leverancier-relatie maar één opdrachtgever. En mocht er wat structuur betreft een verschil van mening tussen de leverancier en de klant zijn dan wordt, binnen de termen van redelijkheid en billijkheid natuurlijk, de mening van de opdrachtgever gevolgd. Mocht het buiten de redelijkheid en billijkheid liggen dan kan Wikiation de ondersteuning als moderator in de wiki staken. De wiki kan dan nog steeds functioneren. Maar voor professioneel gebruik is het dan eigenlijk minder geschikt geworden.
Wanneer de leverancier een wiki opstart
De leverancier kan aangeven kwaliteit en volgens afspraak te willen leveren. Dat kan hij doen door onder andere de inzet van een wiki. Wanneer de klant dit niet wenst, dan kan dat maar dit heeft wel effect op de kwaliteit, de doorlooptijd en eventueel de kosten.
Wanneer de klant een wiki opstart
De klant heeft een dusdanig grote opdracht die aan een leverancier gegeven kan worden dat deze de leverancier kan verzoeken om een wiki als communicatiemedium te gebruiken.
Meerdere partijen
Samenwerking tussen meerdere partijen zijn ook mogelijk via een wiki. Belangrijk is dat er één hoofdaannemer is. Deze kan, als hoofdaannemer zijnde, zaken opleggen als dit noodzakelijk is. De hoofdaannemer wordt dan de eigenaar van de wiki en kan zelf bepalen welke onderaannemers hij toelaat. Belangrijk is wel alle partijen hetzelfde hoofddoel hebben, b.v. gezamenlijk een project willen realiseren. Dat subdoelen van de verschillende partijen uiteen kunnen lopen is niet zo'n probleem.
Is een wiki altijd geschikt
Nee! Zowel de klant als de leverancier moeten bereid zijn afspraken na te komen. Natuurlijk kan er wel eens wat mis gaan maar openheid en eerlijkheid dient de basis intentie van beide partijen te zijn. Als één van beide partijen denkt, door afspraken geheel of gedeeltelijk niet na te komen er een voordeel behaald kan worden dan is een wiki een ongeschikt middel. Als het voor de andere partij duidelijk is wat een wiki is, en hij wil dit communicatiemiddel niet gebruiken, forceer dit dan niet maar respecteer dit. Een geforceerd gebruik van een wiki door één van beide partijen zal niet werken. Het is dan wel goed om na te gaan wat de motivering achter die weigering is.
