In het eerste deel van deze reeks hebben we besproken hoe we op een ongezonde manier afhankelijk kunnen raken van onze leverancier en, bovenal, welke problemen dit voor ons bedrijf kan veroorzaken.
Vandaag gaan we bekijken wat we kunnen doen om een dergelijke afhankelijkheid te voorkomen.
1. De verantwoordelijkheid behouden voor de kennis van processen en systemen en de plannen voor de verdere ontwikkeling daarvan
Als je besluit dat je je geen zorgen wilt maken over IT en je IT-leverancier algemene instructies geeft, ben je hard op weg naar afhankelijkheid. Wat je misschien zal verbazen, is dat deze aanpak vaak ook voor de leverancier zelf problemen oplevert; want na verloop van tijd gaan de eisen van de klant elkaar overlappen en in de knoop raken, en wordt het voor de leverancier een groot probleem om aan nieuwe eisen te voldoen.
Voor een bedrijf dat concurrerend wil blijven, is het belangrijk om IT te zien als een hulpmiddel om zijn processen te ondersteunen, te verbeteren en te meten. Het is niet moeilijk om uit te vinden hoe je dit moet aanpakken, want tegenwoordig beschikken we over voldoende methodieken en normen waarmee we het overzicht over de processen kunnen behouden en een effectieve planning kunnen opstellen:
- Enterprise-architectuur – een manier om de doelstellingen van een organisatie te beschrijven; de manieren waarop deze doelstellingen via bedrijfsprocessen worden gerealiseerd; en hoe deze processen door technologie kunnen worden ondersteund. Zie voor meer informatie het artikel „Don't get bogged down” door slechte enterprise-architectuur. De twee bekendste benaderingen van enterprise-architectuur zijn te vinden op de websites van The Open Group en Zachmann.
- Procesbeschrijving – de bekendste en meest gebruikte standaarden zijn opgesteld door de Open Management Group (www.omg.org). Door processen te beschrijven volgens de BPMN-specificatie (Business Process Model and Notation) kan het management de processen die binnen het bedrijf plaatsvinden eenvoudig inzien en vastleggen.
- Gebruikersdocumentatie – dit hoeft geen document te zijn dat door de leverancier is opgesteld en vervolgens in een la belandt om stof te verzamelen. Een goede aanpak is het maken van video's die gebruikers laten zien hoe ze de applicatie in hun dagelijkse werk kunnen gebruiken; dit vereenvoudigt de productondersteuning en training voor nieuwe gebruikers. De video's duren vaak maar een paar minuten en beschrijven alles wat je moet weten om het systeem effectief te gebruiken. Bekijk bijvoorbeeld de handleiding voor het gebruik van Yammer in een onderzoeksproject; of de handleiding voor het bestellen van goederen in een online winkel.
Alle normen en methodieken gaan vergezeld van uitgebreide documentatie en studiemateriaal waarin elk onderdeel uitvoerig wordt beschreven. Mijn ervaring leert dat het de moeite loont om een specialist in te schakelen die de onderdelen van de methodiek selecteert die geschikt zijn voor een specifiek bedrijf.
Als u uw knowhow op een gestandaardiseerde manier vastlegt, beschikt u niet alleen over een hulpmiddel om onderwerpen te bespreken die tot bedrijfsverbetering leiden, maar krijgt u ook de zekerheid dat u met de overgrote meerderheid van uw huidige en potentiële leveranciers op één lijn zit.
Als u iets wilt veranderen aan uw processen en informatiestromen, begin dan met het aanbrengen van wijzigingen in de werkorganisatie; hetzij op modelniveau, hetzij via een proefproject – test of de verandering de voordelen oplevert die u verwacht. Bereken vervolgens de voordelen van de verandering en de kosten van de implementatie. Als alles in orde is, begin dan met het aanpassen van de systemen; en zo niet, dan kunt u de actie zonder problemen stopzetten. Wanneer u dit volledig aan een externe leverancier toevertrouwt, zijn er maar weinig mensen die de moed hebben om een project te stoppen waarin we al middelen hebben geïnvesteerd.
2. De gegevens moeten onder alle omstandigheden van jou zijn
De gegevens worden opgeslagen bij onze leverancier; we hebben nu echter ruzie met hen gekregen en zij hebben ons laten weten dat de gegevens hun eigendom zijn... Helaas is deze situatie niet zo ongewoon als je misschien zou denken. Het komt niet vaak voor bij aanbieders van clouddiensten en hosting, zoals mensen vaak denken, maar juist bij op maat ontwikkelde systemen, waarbij gegevens worden opgeslagen in een ‘black box’ die volledig onder controle staat van de leverancier.
Dit is een traditionele manier om de klant onder controle van de leverancier te houden. Het probleem kan over het algemeen op twee manieren worden opgelost: door de gegevens rechtstreeks te beheren of door ervoor te zorgen dat ze op een betrouwbare manier in een bruikbaar formaat kunnen worden verkregen.
Bijvoorbeeld: een dienst voor het beheer van e-mailcontacten die we verkrijgen door ons te registreren op de website van onze leverancier. De eerste aanpak bestaat erin ervoor te zorgen dat de gegevens in onze eigen systemen worden gerepliceerd; de tweede aanpak is om de informatie die in de systemen van de leverancier is opgeslagen regelmatig te downloaden en bij ons op te slaan voor het geval dat.
Zelfs in ons eigen systeem, waar de gegevensopslag goed gedocumenteerd is, kan de werkwijze voor het exporteren van gegevens naar een standaardtabel, database of XML de integratie van een nieuw systeem aanzienlijk vergemakkelijken. Het is belangrijk om procedures vast te stellen voor gegevensextractie, om te verifiëren of de export functioneert en of het formaat goed gedocumenteerd is, want het kritieke moment waarop we de gegevens nodig hebben, is precies het slechtste moment om te ontdekken dat de export niet werkt of dat de perfect geëxporteerde gegevens zijn gecodeerd in een formaat waarmee we niet kunnen werken.
Bij het accepteren van nieuwe functionaliteiten of wijzigingen aan systemen van de leverancier moeten de bovenstaande vereisten worden gecontroleerd.
3. Intellectuele eigendomsrechten op applicaties behouden
Eigendom van applicaties omvat het eigendom van de broncode of het ontwerp van de applicatie. Als we geen zeggenschap hebben over de broncode, lopen we het risico dat we, wanneer we van leverancier willen veranderen, tot de ontdekking komen dat de huidige leverancier eigenaar is van een cruciaal deel van de code en niet bereid is deze kosteloos ter beschikking te stellen. We kunnen dit voorkomen door het eigendom duidelijk in het contract vast te leggen; door te vermelden dat de code die is ontwikkeld als gevolg van de gevraagde wijzigingen uitsluitend ons eigendom is; of dat deze wijzigingen zijn gemaakt onder een licentie die ons toestaat ze kosteloos te gebruiken en te verspreiden.
Zelfs als we het eigendomsrecht contractueel hebben vastgelegd, betekent dit nog niet dat de leverancier met wie we op het punt staan het contract te beëindigen, ons toegang tot de broncode zal verlenen. Daarom is het zeer raadzaam om het versiebeheersysteem, de wiki en andere documenten bij een derde partij te laten opslaan en de partner te verplichten de gegevens op een bepaald moment op een bepaalde plaats op te slaan, zodat wij toegang hebben tot de actuele versies.
4. Systeemintegratie in plaats van uitbreiding van de functionaliteit
Webservice-API’s (Application Programming Interfaces) zijn tegenwoordig een gangbaar onderdeel van veel commerciële en open-sourceapplicaties. Dit betekent dat alle functies die beschikbaar zijn voor gebruikers van de applicatie, ook kunnen worden gebruikt tussen verschillende systemen en applicaties.
Door gebruik te maken van protocollen en standaarden om deze interface te definiëren, vormen deze diensten een uniform communicatiemiddel en platform; een applicatie die in één taal of op één besturingssysteem is geschreven, is toegankelijk voor systemen die op een geheel andere manier zijn gebouwd. Gegevens worden in een gangbaar formaat, zoals XML of JSON, uitgewisseld, en de codebases van beide systemen blijven volledig onafhankelijk van elkaar.
Tegenwoordig kan elke gebruiker zich wel voorstellen hoe systeemintegratie eruitziet. We maken immers allemaal gebruik van webapplicaties die met elkaar zijn geïntegreerd – bijvoorbeeld Google Agenda met Google Contacten en Gmail. Als we besluiten om een andere agenda te gaan gebruiken in plaats van de bestaande, hoeven we deze alleen maar te koppelen aan de bestaande gegevens. Deze manier van overstappen is niet mogelijk als we een eigen systeem hebben, dat we oorspronkelijk alleen voor de boekhouding hebben aangeschaft en waarvoor we de leverancier geleidelijk een CRM-module, servicemodule, enzovoort hebben laten ontwikkelen.
Dezelfde redenering geldt voor de integratie met systemen die door clouddienstverleners als dienst worden aangeboden (SaaS – Software as a Service). Door het gebruik van webservices worden afzonderlijke applicaties van elkaar gescheiden, waardoor het hele systeem flexibeler en transparanter wordt. Daarentegen maken vaste koppelingen tussen verschillende modules het voor de leverancier gemakkelijker om onze afhankelijkheid van hen te vergroten, de complexiteit van de code te verhogen en de flexibiliteit van het systeem te beperken tot die van het minst flexibele onderdeel.
5. Probeer wijzigingen aan het standaardsysteem tot een minimum te beperken
Probeer het benodigde systeem te implementeren met zo min mogelijk aanpassingen aan de standaardimplementatie. Je bent meestal niet de eerste klant van de leverancier. Probeer tijdens de implementatie optimaal gebruik te maken van de ervaring die de leverancier met andere klanten heeft opgedaan. Je zult waarschijnlijk verbaasd zijn hoe veel efficiënter sommige processen kunnen worden geïmplementeerd, of dat bepaalde gegevens die we voorheen over het hoofd zagen, ons concurrentievoordeel zullen worden.
Als we ingrijpende wijzigingen in de functionaliteit van de applicatie moeten doorvoeren, kan dit de overgang naar nieuwe versies in de toekomst aanzienlijk bemoeilijken; en elke overgang zal een uitdaging vormen op het gebied van ontwikkeling en implementatie.
6. Maak gebruik van meerdere leveranciers
Probeer het volledige systeemontwerp, de ontwikkeling, de implementatie en het beheer zelf te regelen en laat dit niet over aan de leverancier. Het is bijvoorbeeld een goed idee om bedrijfsanalisten en ontwikkelaars van elkaar te scheiden. Het is ook een goed idee om het systeem te laten testen door testers die geen deel uitmaken van het ontwikkelingsteam. Zij zullen het werk efficiënter uitvoeren en de kans dat u een foutloos product krijgt, is veel groter. Als een andere partij verantwoordelijk is voor de exploitatie (bijvoorbeeld een clouddienstverlener), zorg er dan voor dat zij de ontwikkelaars ertoe aanzetten een product te leveren dat problemen bij de systeemexploitatie tot een minimum beperkt.
7. Leg de beëindigingsprocedure vast in het contract, inclusief boetes voor de leverancier
Hoe is de beëindiging van de samenwerking in het contract vastgelegd? Een opzegtermijn van drie maanden, waarna u niet meer betaalt en de leverancier geen ondersteuning meer biedt? Dat is volstrekt ontoereikend.
Het is noodzakelijk om vast te leggen welke documentatie en in welke kwaliteit de leverancier deze aan u – of rechtstreeks aan de nieuwe leverancier – moet verstrekken tijdens de opzegtermijn. Als u intellectuele-eigendomsrechten hebt verworven op het ontwerp, de broncode en andere onderdelen van de in punt 3 genoemde documentatie, des te beter. Bij het sluiten van een contract met een leverancier is het verstandig om bij de bedrijven die op de tweede en derde plaats zijn geëindigd na te gaan wat zij nodig hebben om de ontwikkeling en het onderhoud van de winnaar over te nemen.
8. Leveranciers op de hoogte brengen van toekomstige ontwikkelingsplannen
Streef naar een langdurige samenwerking met uw leveranciers. Als u regelmatig uw ontwikkelingsplannen en strategische kwesties met hen bespreekt – en niet alleen de huidige wijzigingen in de functionaliteit – kan de leverancier met voorstellen komen die leiden tot een systeemarchitectuur die stabiel, efficiënt en kosteneffectief is, niet alleen voor uw huidige behoeften, maar ook voor toekomstige behoeften. Om uw eisen te verduidelijken, kunt u bijvoorbeeld gebruikmaken van de MuSCoW-methode, die eisen in de volgende categorieën indeelt:
- Moet je hebben – moet je hebben
- Had moeten – had moeten
- Zou kunnen – zou leuk zijn
- Dit hoef ik nu niet te hebben – ik heb dit op dit moment niet nodig
9. Vraag andere partijen om ideeën en meningen
Blijf niet op één plek hangen; volg trends; zoek naar de beste methoden en werkwijzen; en houd alles in de gaten. Schakel een bedrijf in voor een derde mening – zij zullen je beslissingen zowel vanuit technisch als strategisch oogpunt beoordelen. Dat hoeft niet duur te zijn. En zo’n advies is de moeite waard, omdat het je helpt fouten te voorkomen. Uit ervaring ken ik een geval waarbij een leverancier een klant dwong om enkele miljoenen kronen te investeren in het oplossen van een probleem dat hij zelf had veroorzaakt; en een consultant ontdekte dat de investering het probleem helemaal niet zou oplossen omdat de oorzaak ergens anders lag.
Een consultant kan u helpen bij het uitstippelen van uw strategie, het creëren van vraag, het evalueren van opties en het bekijken van zaken vanuit een onverwachte invalshoek. Hij of zij kan u ook helpen bij het beoordelen van uw leveranciers en ervoor zorgen dat u het best mogelijke resultaat behaalt. Een consultant moet altijd in gedachten houden dat u onafhankelijk wilt zijn van een bepaalde leverancier en dat u de waarde van uw knowhow als concurrentievoordeel erkent.
Bij de juiste keuze van leveranciers draait het om risicobeheer
Ik denk dat u na het lezen van dit artikel een duidelijker beeld heeft van hoe u uw leveranciers kunt betrekken bij uw succes, in plaats van hun ondergeschikte te worden. Het voorkomen van onaangename situaties draait om consequent risicobeheer en het kiezen van oplossingen die een evenwicht bieden tussen de huidige behoeften en toekomstige flexibiliteit. Door u aan bovenstaande principes te houden, zorgt u ervoor dat u de juiste keuze maakt wat betreft leveranciers en nieuwe systemen.
