Ketenregie – Samenwerkingsvorm voor het optimale resultaat?

Het is een vraag die mij de laatste maanden erg bezighoudt. Het ene uiterste is de samenwerking tussen opdrachtgever en leverancier waarbij de leverancier het resultaat moet leveren wat er contractueel is overeengekomen binnen de afgesproken grenzen van tijd, geld en kwaliteit. Het andere uiterste is de samenwerking tussen opdrachtgever en leverancier waarbij beide partners van elkaar willen zijn, een partnership met elkaar willen aangaan. Hierbij moet ‘partnership’ worden vertaald naar ‘we zijn altijd open en transparant naar elkaar’, de opdrachtgever vraagt niet het onmogelijke van de leverancier, de leverancier doet geen onhaalbare toezeggingen en in slechte tijden van de opdrachtgever of van de leverancier helpen we elkaar en nemen we zeker geen afscheid.

Wat zijn de voor- en nadelen van de 2 uitersten?

De voor- en nadelen van laten we het gemakshalve ‘Contractuele samenwerking’ noemen zijn naar mijn idee de volgende:

Voordelen:

  • Zowel opdrachtgever, als leverancier weten exact waar ze aan toe zijn. De gemaakte afspraken zijn duidelijk en als iedereen zich eraan houdt dan is er geen vuiltje aan de lucht.
  • Opdrachtgever kan altijd aanspraak maken op het leveren van het resultaat binnen de afgesproken kaders van tijd, geld en kwaliteit. Dit maakt sturen makkelijk.

Nadelen:

  • Als een leverancier niet in staat is om conform afspraken het resultaat te leveren, dan ontstaat er direct spanning in de relatie met de opdrachtgever. Die legt het contract op tafel en denkt ‘Onder druk wordt alles vloeibaar’ en ‘Als ik maar hard genoeg schop, dan levert de leverancier wel’.
  • De leverancier zal niet uit zichzelf pogingen doen om meer te leveren dan contractueel is afgesproken, sterker nog: hoe minder tijd hij nodig heeft voor het leveren van het afgesproken resultaat, hoe meer winst hij maakt.
  • Er ontstaat al snel een ‘wij/zij’ sfeer, waarin de verwijten over elkaars functioneren over en weer gaan. Niet tegen elkaar, maar binnen de eigen organisatie (‘roddelen’).

De voor- en nadelen van het ‘Partnership’ zijn naar mijn idee de volgende:

Voordelen:

  • In een ‘partnership’ wordt openlijk gesproken over gezamenlijke doelen, – belangen en – risico’s. Ook over de individuele belangen, waardoor er een wederzijds begrip is voor elkaar handelen. Overigens gelden contractuele afspraken ook als basis voor het partnership, maar deze afspraken zijn gemaakt in dienst van het partnership.
    Voorbeeld: iedere opdrachtgever snapt dat zijn leverancier geld wil verdienen, maar als ook bekend is hoeveel en wat de financiële baten voor de opdrachtgever echt zijn, dan is dat geen probleem en kan men samen handelen naar dit gegeven.
  • Als het bij de opdrachtgever of leverancier even iets minder gaat, dan kunnen er afspraken worden gemaakt in de trend van ‘Betaal nu maar wat minder voor het servicecontract, dan betaal je het normale niveau als het weer beter gaat’ of ‘Ik zet een aantal opdrachten voor jou eerder op de planning, zodat jullie er weer sneller bovenop komen’.
  • Opdrachtgever en leverancier bieden elkaar proactief opportunities aan, waardoor de meerwaarde (in business value en kwaliteit) van de leverancier voor de opdrachtgever stijgt. De leverancier krijgt de kans om haar dienstverlening verder uit te breiden, de opdrachtgever bereikt haar business doelstellingen of overstijgt deze.
  • De leverancier gaat meedenken met de opdrachtgever en proactief handelen. De leverancier zet net een stapje harder dan contractueel wordt gevraagd.

Nadelen:

  • ‘Partnership’ kan leiden tot niet zakelijk gedrag, ‘elkaar niet meer de maat durven/kunnen nemen’. Goede partners blijven hier waakzaam op en begrijpen van elkaar dat als er aanleiding voor is dit bij tijd en wijle nodig is.
  • Tunnelvisie bij de opdrachtgever. Vanwege de langdurige en goede relatie met de leverancier verliest de opdrachtgever mogelijk andere opportunities in de markt. De opdrachtgever moet de markt blijven verkennen.

Wat mij opvalt aan de beschrijvingen van de voor- en nadelen is dat het partnership gemoedelijker en meer op samenwerking gebaseerd overkomt. Waarschijnlijk is de werksfeer bij de opdrachtgever en de leverancier en daarmee de medewerker tevredenheid daar een afspiegeling van. De kans dat er bij een partnership meer zaken worden gedaan tussen opdrachtgever en leverancier is ook duidelijk lijkt mij. Maar waardoor gaat het in de praktijk dan niet altijd zo? Dat zal voor mij in de aankomende periode nog aanleiding zijn voor nader onderzoek.

Bovenstaande is uiteraard een zeer zwart witte en onvolledige weergave van de werkelijkheid, misschien heeft u nog aanvullingen op de voor- en nadelen van de 2 uitersten? Of misschien heeft u wel andere ervaringen ten aanzien van de sfeer of medewerker tevredenheid? Dan zie ik graag uw aanvullingen en ideeën verschijnen.

Pakketten en testen; een vertragende factor?!

Pakketten en testen. Is dat een logische combinatie? Is het inderdaad een vertragende factor of kan het elkaar juist versterken.

Pakketten kies je om bepaalde redenen. Het gebruik maken van generieke oplossingen of standaarden vanuit de markt, onvoldoende capaciteit om zelf te kunnen ontwikkelen etc. Zo zijn vele redenen te bedenken om te werken met (standaard) pakketten. Een pakket staat niet op zich maar is geïntegreerd in het totale landschap binnen een organisatie. Het pakket vult een onderdeel van de keten in. Daarbij is het natuurlijk van belang dat de keten goed functioneert en er voor zorgt dat de klanten tevreden zijn en blijven.

Zoals bij maatwerk systemen het geval is krijg je ook bij pakketten te maken met updates t.a.v. het pakket of bijvoorbeeld andere wensen t.a.v. de inrichting door bijvoorbeeld veranderende business omstandigheden. Deze wijzigingen moeten gevalideerd worden om te voorkomen dat er allerlei ongewenste neveneffecten gaan ontstaan. De benodigde inspanning kan flink oplopen en heeft wellicht ook een repeterend karakter bij meerdere releases per jaar. Vooral als er (nog) handmatig getest wordt. De benodigde inspanning wordt mede bepaald door de omvang van een regressietest. Uiteraard is deze omvang afhankelijk van de aard van de wijzigingen.

Handmatig testen heeft een grote waarde maar is niet toereikend meer gezien de hoeveelheid updates die beschikbaar zijn, de snelheid waarmee deze geïmplementeerd moeten worden en de tijd die nodig is voor de testuitvoering.

Dan is het toepassen van geautomatiseerd testen een absolute must om het ontwikkeltempo bij te kunnen houden. Zeker gezien als je richting een DevOps situatie gaat bewegen.

Echter, bij de introductie van testautomatisering worden nieuwe uitdagingen geïntroduceerd. Testautomatisering moet herhaalbaar, herbruikbaar en overdraagbaar zijn. Het opvoeren van een bijvoorbeeld een pensioen polis met ingangsdatum vandaag is mooi en de gedefinieerde testgevallen kun je vandaag perfect uitvoeren. Alleen morgen is vandaag niet meer en dan werken je gedefinieerde testgevallen niet meer. Kortom, je testgevallen zijn niet herbruikbaar en herhaalbaar.

Wat kun je er aan doen? De oplossing is voorhanden. Zoals je een informatiesysteem bouwt op basis van een architectuur moet je testautomatisering ook opzetten onder architectuur. We noemen dat testautomatiserings-architectuur waarmee je o.a. herbruikbaarheid en herhaalbaarheid van je geautomatiseerde testen bereikt.

Door deze aanpak kun je snel en gedegen een wijziging, fix, release etc. valideren waarmee de doorlooptijd van de test en daardoor de doorlooptijd van een release aanzienlijk kunt verkorten. Je bereikt dan de situatie dat testen geen vertragende factor meer is maar een katalysator om wijzigingen snel in productie te kunnen zetten.

Wil je meer weten over het opzetten van een toekomstvaste testautomatiserings-architectuur? Kijk dan in het boek: testautomatisering wendbaar organiseren of de website https://mailchi.mp/a6bc6ba0b694/testautomatisering.

Heb je naar aanleiding van dit artikel vragen?

Heb je een vraag of wil je met ons sparren? Neem gerust contact op met Martijn. Hij denkt graag met je mee!