Hoe je effectief kunt samenwerken: een echte alliantie opbouwen tussen functionele en technische consultants

(Deel 2 van 5 van de serie "De menselijke code van ERP")

Laten we eerlijk zijn. Als je enige ervaring hebt met de implementatie van bedrijfssoftware, is het je waarschijnlijk opgevallen dat er vaak wrijving bestaat tussen functionele en technische consultants.

Tussen hen gaapt een kloof van misverstanden, passief-agressieve e-mails en vertraagde projectplanningen.

Het Simple Integration Incident

Ik heb projecten wekenlang stil zien liggen, puur omdat twee professionals totaal verschillende talen spraken.

Stel je een typische afstemmingsvergadering voor. De functioneel consultant, net terug van een workshop met de klant, buigt zich voorover en zegt: " De klant moet de productiesoftware synchroniseren met het ERP-systeem. Dat is heel eenvoudig. We hoeven alleen maar een simpele integratie met hun huidige MES te bouwen om de gegevens over te zetten."

Het probleem is dat de functioneel consultant de oplossing als "eenvoudig" verkoopt, vooral omdat zij niet degene zijn die daadwerkelijk de code moeten schrijven. Ze geven weinig details en nemen de technische uitvoering licht op, waarbij ze de zware technische implicaties volledig onderschatten.

Voor de consultant is een integratie slechts een conceptuele brug. Voor de ontwikkelaar is diezelfde "eenvoudige integratie" een nachtmerrie van payloadstructuren, time-outfouten, beveiligingstokens en ontbrekende gegevensvalidaties.

Wanneer de ontwikkelaar onvermijdelijk op deze complexiteiten wijst, ontstaat er onnodige wrijving. De functioneel consultant vindt dat de ontwikkelaar een bedrijfsvereiste onnodig ingewikkeld maakt. De ontwikkelaar heeft het gevoel dat de functioneel consultant hun harde werk bagatelliseert en onhaalbare beloftes aan de klant doet.

De waarheid is dat het werk van een functioneel consultant moeilijkheden kent die een ontwikkelaar niet begrijpt, en omgekeerd. De ontwikkelaar hoeft niet om te gaan met de irrationele eisen van een paniekerige klant, en de functioneel consultant hoeft zich niet te verdiepen in de meedogenloze logica van systeemarchitectuur. Geen van beide beroepen is minder belangrijk of eenvoudiger dan het andere. Ze staan ​​gewoon voor unieke uitdagingen die de andere kant zelden tegenkomt.

De echte vijand in deze ruimte is het ego en het gebrek aan wederzijds begrip.

Welkom bij het tweede deel van De menselijke factor in ERP. Vandaag doorbreken we de barrières tussen de mensen die de bedrijfsprocessen ontwerpen en de mensen die ze daadwerkelijk moeten bouwen.

We hebben het over hoe je een ijzersterke samenwerking kunt smeden tussen functionele en technische teams.

Twee werelden, twee talen

Om dit conflict op te lossen, moeten we eerst de onderliggende oorzaak begrijpen. Functionele en technische consultants leven in twee totaal verschillende werelden.

De functioneel consultant bevindt zich in de rommelige, onvoorspelbare wereld van het bedrijfsleven. Ze lopen over de werkvloer. Ze zien het fysieke zweet van de operators. Ze hebben te maken met de zorgen van de CFO en de chaotische, onlogische manieren waarop mensen hun dagelijkse taken uitvoeren. Hun doel is om de bedrijfsvoering soepel te laten verlopen.

De technisch adviseur leeft in een wereld van absolute, binaire logica. Een databasetabel trekt zich er niets van aan of de magazijnmanager een stressvolle dag heeft. Een systeemarchitectuur vereist strikte regels, precieze definities en geen enkele ambiguïteit. Hun doel is om het systeem stabiel, veilig en performant te maken.

Wanneer deze twee werelden botsen zonder vertaler, slaat het noodlot toe. Je krijgt een systeemintegratie die technisch gezien perfect is, maar volkomen nutteloos voor de mensen op de werkvloer, omdat er geen rekening wordt gehouden met de fysieke vertragingen die een heftruck veroorzaakt bij het verplaatsen van pallets.

De mythe van de technisch adviseur

Er bestaat een wijdverbreide misvatting dat een functioneel consultant moet leren programmeren om deze kloof te overbruggen. Dit is volkomen onjuist. Een goede functionele ERP-consultant hoeft geen scripts te kunnen schrijven of complexe SQL-query's te kunnen uitvoeren.

Ze moeten echter absoluut begrijpen hoe een systeem denkt.

Je hoeft niet te weten hoe je de API-payload schrijft. Maar je moet wel begrijpen dat een systeem een ​​specifieke reactie verwacht wanneer het een bericht verzendt. Je moet een bedrijfsproces ontwerpen voor wat er gebeurt als die reactie nooit komt. Je moet het verschil begrijpen tussen een stamtabel en een transactietabel. Je moet de basisprincipes van systeemarchitectuur doorgronden.

Jouw ware taak als functioneel consultant is om de ultieme menselijke vertaler te zijn. Jij bent de brug, geen programmeur. Je moet de chaotische, emotionele behoeften van het bedrijf vertalen naar heldere, logische kaders waarmee een ontwikkelaar daadwerkelijk aan de slag kan.

Het beschermen van de loopgraven

Het ergste type functionele consultant is de blinde uitvoerder. Dit is de consultant die zich niet echt bekommert om de daadwerkelijke bedrijfsbehoefte. Ze voeren orders uit als een soldaatje, luisteren naar een onlogisch of volstrekt onhaalbaar verzoek van de klant, schrijven het letterlijk op zoals het gezegd is en geven het direct door aan het technische team zonder zich af te vragen of het wel zinvol is.

De moderne CloudSuite-architectuur voorkomt dat je de database letterlijk kunt beschadigen, maar gebruikers zullen nog steeds om aanpassingen vragen die volledig in strijd zijn met de standaard systeemlogica. Wanneer de ontwikkelaar er onvermijdelijk op wijst dat het verzoek technisch gezien absurd is, haalt dit type consultant zijn schouders op en zegt: "Geef mij de schuld niet. Dat is wat de klant wil."

Dit gedrag ondermijnt het vertrouwen op de lange termijn. Het schuift de schuld af op het technische team.

Een echte consultant fungeert als een schild. Het is jouw taak om te beoordelen of een verzoek volstrekt onhaalbaar is voordat je het doorspeelt naar de IT-afdeling. Je moet de "Vijf Waarom-vragen" die we in deel 1 hebben besproken toepassen en de werkelijke bedrijfsbehoefte achterhalen.

Bovendien, als de ontwikkelaar moeite heeft om een ​​vereiste uit te voeren, wijs je niet alleen naar het specificatiedocument en eis je resultaten. Je werkt met hem samen. Je onderzoekt gezamenlijk of de technische beperking objectief is. Als het een objectieve belemmering is, moet je als brug fungeren en teruggaan naar de klant om tot een compromis te komen.

Klanten gebruiken graag de klassieke uitspraak: "In de IT is alles mogelijk." Je moet je technische team beschermen tegen deze denkwijze, want zo werkt de echte wereld niet. Wij herschrijven geen kernprocessen van de grond af aan. Wij breiden standaardfunctionaliteiten uit.

Als ontwikkelaars beseffen dat je aan de poort staat, de rommel eruit filtert en hen beschermt tegen onhaalbare beloftes, zullen ze je respecteren. Ze zullen stoppen met zich tegen je verzoeken te verzetten en in plaats daarvan samenwerken aan jouw oplossingen.

De hitte trotseren

Functionele consultants klagen vaak over een heel specifieke dynamiek. Wanneer een aangepast script faalt of een systeem crasht, zit de technische consultant veilig achter een monitor. Ondertussen moet de functionele consultant in een vergaderruimte zitten, een boze klant recht in de ogen kijken en uitleggen waarom de nieuw geïmplementeerde aanpassing niet werkt zoals verwacht. Het voelt ontzettend oneerlijk om de schuld te krijgen van een technische fout die je niet hebt veroorzaakt.

Of je het nu leuk vindt of niet, het is nu eenmaal jouw taak om de schakel te zijn tussen het technische team en de klant. Jij bent de brug. Klagen over het contact met de klant is als een schild dat klaagt over een klap.

Het geheim van een gezond project is wederzijdse bescherming. Een sterke alliantie betekent dat je elkaar dekt. ​​De functioneel consultant vangt de klappen op, neemt de kritiek voor zijn rekening en beheert de frustraties van de klant om waardevolle tijd te winnen. Deze dynamiek werkt alleen als de ontwikkelaar hen ook steunt.

In een echte samenwerking is de ontwikkelaar al op de hoogte en werkt hij achter de schermen aan een oplossing zodra de consultant de vijandige vergaderruimte binnenstapt. Jij beschermt de ontwikkelaar tegen de paniek van de klant, en de ontwikkelaar beschermt jouw geloofwaardigheid door de bug snel te verhelpen.

Het handboek voor allianties

Hoe maak je van een vijandige IT-afdeling je grootste bondgenoot? Hier zijn drie praktische regels die je kunt toepassen in je volgende project om een ​​echte samenwerking op te bouwen.

1. Schrijf binaire specificaties, geen romans

Ontwikkelaars haten dubbelzinnigheid meer dan wat dan ook ter wereld. Schrijf nooit een functionele specificatie die zegt: "Het systeem moet de status automatisch bijwerken en de gebruiker hiervan op de hoogte stellen." Dat is een roman, geen specificatie. Schrijf in plaats daarvan in binaire logica. Specificeer precies welke trigger de gebeurtenis activeert. Definieer precies welk tabelveld moet veranderen van Status A naar Status B.

Verduidelijk precies wat de melding moet inhouden en wie de exacte ontvanger is. Verwijder bijvoeglijke naamwoorden en vervang ze door precieze voorwaarden. Als uw specificatie ruimte laat voor persoonlijke interpretatie, is het een slechte specificatie. Zelfs de kleinste details moeten worden vastgelegd in een formele analyse en gedeeld. Een kort overleg om deze details in eerste instantie te bespreken, kan een groot verschil maken bij het vaststellen van een gemeenschappelijke taal.

2. Leg in de analyse altijd de "waarom" uit

Bij het schrijven van een functionele specificatie moet u de zakelijke motivatie achter het verzoek duidelijk uitleggen. Beschouw de ontwikkelaar niet als een simpele code-uitvoerder. Net als functionele consultants hebben ontwikkelaars de volledige context van de vereisten nodig. Ze moeten begrijpen waaraan ze werken, maar vooral waaromze het doen. Geef ze niet zomaar een technische instructie.

Leg het zakelijke probleem uit. Zeg bijvoorbeeld: " De medewerkers in het magazijn typen dit nummer momenteel 500 keer per dag handmatig in, wat vertragingen in de verzending veroorzaakt. We moeten dit veld automatiseren om hen twee uur per shift te besparen." Wanneer een ontwikkelaar de context en de menselijke impact van zijn code begrijpt, verandert hij van een ordernemer in een actieve partner die wellicht een veel betere technische oplossing kan aandragen dan je oorspronkelijk voor ogen had.

3. Betrek ze bij de reis

In de meeste projecten is de functioneel consultant degene die naar de klant reist en bij de belangrijke vergaderingen aanwezig is. Deze dynamiek zorgt er vaak voor dat de ontwikkelaar geïsoleerd achter de schermen werkt. Als je echt als een team wilt werken, moet je dat op de juiste manier doen. Je kunt niet zomaar je technische collega's benaderen wanneer je een specifieke programmeertaak hebt, zonder de bredere context te schetsen.

Je moet ze het gevoel geven dat ze een integraal onderdeel van het project zijn. Maak van de gelegenheid gebruik om regelmatig met ze te praten en ze op de hoogte te houden van recente ontwikkelingen bij de klant, veranderingen in het project en de algemene sfeer. Door deze continue context te bieden, zorg je ervoor dat ze nauw betrokken zijn. Wanneer ontwikkelaars het grotere geheel begrijpen en zich betrokken voelen bij het proces, zijn ze niet langer louter uitvoerders, maar echte projectpartners. Een project waarin een functioneel consultant en een ontwikkelaar samenwerken, zal ongetwijfeld uitstekende resultaten opleveren, zowel voor het project als voor hun dagelijkse werk.

De alliantie in de loopgraven

Het ontwikkelen van een aangepaste extensie of het integreren van externe software in een ERP-systeem is nooit alleen een kwestie van het schrijven van code. Het is een oefening in menselijke communicatie.

Zelfs de beste technische architectuur ter wereld stort in elkaar als de mensen die het proces definiëren en de mensen die de logica schrijven weigeren elkaar te begrijpen. Door onze ego's opzij te zetten, duidelijk te communiceren en elkaars tijd te respecteren, kunnen we een einde maken aan de eeuwige strijd en software gaan bouwen die daadwerkelijk een verschil maakt.

Een succesvolle implementatie is sterk afhankelijk van de onbreekbare samenwerking tussen een functioneel en een technisch consultant. Geen van beiden kan in zijn eentje succesvol zijn.

Volgende onderwerp: Hoe ontwikkel je de meest onderschatte vaardigheid in de consultancybranche? We onderzoeken de kracht van nieuwsgierigheid boven een encyclopedisch geheugen.

Geschreven door Andrea Guaccio 

7 mei 2026