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 eigendom behouden van de kennis over processen en systemen en van de plannen voor de ontwikkeling daarvan
Als u besluit dat u zich geen zorgen wilt maken Over ons en uw IT-leverancier algemene instructies geeft, bent u hard op weg naar afhankelijkheid. Wat u wellicht zal verbazen, is dat deze aanpak vaak problemen oplevert voor de leverancier zelf; 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 dit moet, want tegenwoordig beschikken we over voldoende methodieken en normen waarmee we het overzicht over de processen kunnen behouden en een effectieve planning kunnen uitvoeren:
- 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 conceptniveau, hetzij via een proefproject – test of de verandering de verwachte voordelen oplevert. 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, hebben maar weinig mensen de moed 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; nu hebben we ruzie met hen gekregen en hebben ze 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 te zorgen voor een betrouwbare manier om ze in een bruikbaar formaat te verkrijgen.
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 dat de export functioneert en dat het formaat goed gedocumenteerd is, want het kritieke moment waarop we de gegevens moeten ophalen, 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. De intellectuele-eigendomsrechten op de applicaties behouden
Eigendom van applicaties houdt in dat men eigenaar is 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 als gevolg van de gevraagde wijzigingen is ontwikkeld, 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 het contract Over ons toegang tot de code zal verlenen. Daarom is het zeer raadzaam om het versiebeheersysteem, de wiki en andere documenten bij een derde partij op te slaan en de partner te verplichten de gegevens op een bepaalde plaats en op een bepaald tijdstip op te slaan, zodat wij toegang hebben tot de actuele versies.
4. Systeemintegratie in plaats van uitbreiding van 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 totaal andere manier zijn gebouwd. Gegevens worden in een algemeen gangbaar formaat, zoals XML of JSON, uitgewisseld, terwijl de codebases van beide systemen volledig Onafhankelijk blijven.
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 Transparant 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 vereiste systeem te implementeren met zo min mogelijk aanpassingen aan de standaardimplementatie. Meestal bent u 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. U 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 zal elke overgang 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 aan de leverancier over. Het is bijvoorbeeld een goed idee om bedrijfsanalisten en ontwikkelaars van elkaar te scheiden. Het is 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 aansporen om 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 een goed idee om bij de bedrijven die op de 2e en 3e 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:
- Onmisbaar – onmisbaar
- Had moeten – had moeten
- Zou kunnen – zou leuk zijn
- Dit hoef ik nu niet – ik hoef dit op dit moment niet te hebben
9. Vraag andere partijen om ideeën en meningen
Blijf niet op één plek steken; 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 uw beslissingen zowel vanuit technisch als strategisch oogpunt beoordelen. Dat hoeft niet duur te zijn. En zo’n advies is de moeite waard, omdat het u 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 elders 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 Onafhankelijk een bepaalde leverancier en dat u de waarde van uw knowhow als concurrentievoordeel erkent.
De juiste keuze van leveranciers is Over ons
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 is Over ons 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.
