Hoe het echt werkt als één team je website, app en machines bouwt

Stel je een productiebedrijf voor dat drie dingen tegelijk nodig heeft: een klantportaal waar klanten hun orderstatus kunnen checken, een renovatie van een oude verpakkingslijn zodat die eindelijk data doorgeeft in plaats van blind te draaien, en een website die uitlegt wat ze doen. Normaal gesproken betekent dat drie of vier leveranciers: een webbureau, een softwareontwikkelaar, een automatiseringsbedrijf, misschien nog een aparte partij voor hosting. Dit is wat zo'n project meestal stap voor stap doormaakt, en waar het meestal misgaat.

Het intakegesprek dat alles dekt, of maar een derde

Bij losse leveranciers krijg je losse intakegesprekken, soms weken uit elkaar. Het webbureau vraagt naar het portaal en heeft geen idee wat de PLC daadwerkelijk kan leveren. Het automatiseringsbedrijf vraagt naar de machine en weet niet dat het portaal live productieaantallen moet tonen. Elke partij schrijft een offerte zonder te weten wat de andere twee doen.

Bij één team gebeurt die intake één keer, en die dekt alle drie tegelijk: welke data de machine echt bevat, wat het portaal moet tonen, wat de website tegen bezoekers moet zeggen. Beslissingen worden één keer genomen, in dezelfde ruimte, in plaats van drie keer geraden door drie partijen die nooit met elkaar praten.

Ontwerpkeuzes die op twee plekken tegelijk leven

Neem iets doodgewoons als de naamgeving van de data uit de PLC: taggen, eenheden, hoe vaak iets ververst. Wie het portaal bouwt, moet precies weten wat er uit de machine komt en in welke vorm. Praten het automatiseringsbedrijf en de softwareontwikkelaar nooit rechtstreeks met elkaar, dan wordt dit geraden, of gekopieerd uit een oud specificatieblad dat allang niet meer klopt. Meestal komt dat pas weken later boven water, precies op het moment dat iemand beide systemen naast elkaar opent en niets matcht.

Bij één team zitten degene die de API ontwerpt en degene die de PLC configureert aan hetzelfde bureau. Verandert er een tagnaam omdat die duidelijker moet, dan ziet de developer dat diezelfde dag, niet drie sprints later wanneer het dashboard stilletjes stopt met bijwerken.

De bouwfase: wachten op het antwoord van een ander

Hier verliezen losse leveranciers de meeste tijd, en het is zelden het werk zelf. Het is het wachten: wachten tot het automatiseringsbedrijf bevestigt welke data beschikbaar is, wachten tot het webbureau bevestigt welke velden het portaal nodig heeft, wachten op een reactie die vier dagen in iemands mailbox blijft liggen omdat jouw project deze week niet hun prioriteit is, maar een gunst aan de planning van een andere leverancier.

Elke leverancier heeft ook zijn eigen planning en zijn eigen betalende klanten die voor die van jou in de rij staan. Niemand doet daar iets fout mee. Maar het betekent dat een project dat afhankelijk is van drie partijen die met elkaar moeten praten, net zo snel gaat als de traagste reactie tussen hen.

De overdracht, waar de meeste schade ontstaat

Het klassieke breekpunt: de machinerenovatie is klaar, de PLC draait prima, maar het dashboard dat de live lijnsnelheid moet tonen laat niets zien, omdat ergens in de laatste twee weken een tag is hernoemd en niemand dat aan de softwarekant heeft gemeld. Of de nieuwe website gaat live met een contactformulier dat stilletjes nergens naartoe gaat, omdat degene die het formulier bouwde en degene die de mailbox beheert nooit echt hebben overlegd.

Dit zijn geen zeldzame ongelukken. Het is het normale gevolg van het opsplitsen van één samenhangend systeem over losse contracten. Niemand is eigenaar van de naad tussen twee stukken werk, en precies daar gaat het mis.

Bij één team is de overdracht eigenlijk geen overdracht. Degene die de machine heeft bekabeld en degene die het dashboard heeft gebouwd kennen elkaars werk al, omdat ze de hele tijd in hetzelfde project zaten, niet in twee losse projecten die elkaar toevallig raken.

Support: wie neemt op als de lijn zaterdag stilvalt

Na livegang zie je het verschil weer, meestal op het lastigste moment. Bij losse leveranciers betekent een probleem op zaterdag eerst uitzoeken wie er waarschijnlijk verantwoordelijk is voordat je weet wie je moet bellen: is het de machine, de software, de website, de hosting? Bij één team is er één nummer, en degene die opneemt kent de machine, de software en de site al, want het is hetzelfde team dat alle drie heeft gebouwd.

Sta je op het punt iets te plannen dat meer dan één van deze raakt, een website, een app, maatwerksoftware, een machine, doe dan één ding voordat je iets tekent: schrijf elk punt op waar het ene systeem met het andere moet praten, data, logins, hosting, timing, en vraag wie je ook inhuurt wie precies die verbinding beheert. Is het eerlijke antwoord 'iemand anders', dan is dat de naad die je later problemen gaat bezorgen.