MEP InSight — installaties die je bezit, en installaties die je onderhoudt

Situatie

Twee soorten organisaties hebben hetzelfde probleem, maar van de andere kant bekeken.

Een fabriek bezit honderden installaties en moet ze draaiende houden. Wat staat waar, wanneer is het laatst nagekeken, welk plan is het actuele, wie heeft de laatste wijziging afgetekend.

Een leverancier heeft installaties verkocht en geplaatst bij tientallen klanten en moet die onderhouden. De vragen zijn identiek — alleen zijn de installaties niet van hem, staan ze op andermans terrein, en moet alles per klant beantwoord kunnen worden.

Software kiest doorgaans een kant. Onderhoudssystemen gaan ervan uit dat je de fabriek bezit en behandelen klanten als bijzaak. Systemen voor buitendienstwerk gaan van het omgekeerde uit en laten de technische diepgang vallen. Organisaties die het allebei zijn — en dat zijn er heel wat, met een eigen productie én een onderhoudsdienst voor wat ze verkocht hebben — houden er twee systemen op na en leggen die met de hand naast elkaar.

MEP InSight is mijn antwoord daarop: gebouwd en in eigendom van DynDaCo, en uitgerold bij bedrijven in plaats van opgeleverd en losgelaten.

Wat ik gebouwd heb

Eén register dat allebei de situaties aankan, en de beslissing die dat mogelijk maakt is klein: de installatiehiërarchie hangt aan een bedrijf.

Functionele locaties beschrijven waar apparatuur staat, los van welk toestel daar vandaag effectief hangt — het klassieke onderhoudsprincipe, en de reden waarom een pomp vervangen niet tien jaar geschiedenis weggooit. Die locaties vormen een boom, en de wortel van elke boom is een bedrijf. Richt hem op je eigen bedrijf en je beheert je eigen installatie. Richt hem op je klanten en je beheert een geïnstalleerd park over al die klanten heen. Dezelfde schermen, dezelfde rechten, dezelfde geschiedenis; het enige verschil is wiens naam bovenaan staat.

Bovenop die structuur:

De installatie zoals ze echt is. Het besturingsnetwerk gedocumenteerd zoals gebouwd — toestellen, hun types, hun poorten en interfaces, en de segmenten waarop ze zitten — zodat je bij één toestel kan beginnen en naar buiten kan wandelen naar alles waar het mee verbonden is, in plaats van een schema te raadplegen dat klopte bij de oplevering en sindsdien afdrijft.

Documenten die actueel blijven. Een kluis met revisiebeheer bevat plannen, handleidingen en configuratiebestanden, gekoppeld aan de locaties en toestellen die ze beschrijven, en zichtbaar in de browser. Je krijgt standaard de huidige revisie, en de vorige staan er nog wanneer iemand vraagt wat er veranderd is.

Nazicht en geschiedenis. Nazichten stapelen zich op per locatie, zodat een installatie haar eigen verleden meedraagt — precies waar het model van functionele locaties voor dient.

De planning, zonder het .mpp-bestand. Projectplanning zat vroeger in MS Project-bestanden die per mail rondgingen. InSight leest ze in — de volledige opdeling van het werk, de afhankelijkheden, de toewijzingen en de namen van de resources — en toont ze als een interactieve Gantt met vier vensters: de belasting van een ploeg, één project, één persoon, één week. Een planner herrekent afhankelijke datums met dezelfde werkdagenrekenkunde als MS Project, zodat één taak verschuiven ook verschuift wat erop volgt, zoals de planner het verwacht. Verlof en afwezigheden staan achter de balken, zodat het plan en wie er effectief beschikbaar is één beeld vormen. Plannen zijn ter plaatse aanpasbaar, en elk plan wordt vastgezet op de kant die er de eerste taak in schreef — zo verlaat een ploeg MS Project project per project in plaats van in één keer.

Automatisering als tekst, niet als nieuwe versie. Wat er gebeurt wanneer een melding binnenkomt, een status verandert of iemand toegewezen wordt, zit niet in de code: het is een kleine taal die een beheerder zelf in de browser schrijft. De regels lezen zoals je ze zou uitspreken — wanneer de behandelaar verandert, verwittig wie er net bijgekomen is, en zeg het tegen wie er net af gehaald is. De server ontleedt en valideert het document terwijl je typt en onderlijnt waar hij het niet mee eens is, dus een kapotte regel kan niet bewaard worden, en elke evaluatie — geldig of verworpen, en welke voorwaarde ze verwierp — komt in een logboek terecht. De verwerkende code neemt zelf geen enkele beslissing: ze zoekt uit over welke melding een bericht gaat en vuurt een gebeurtenis af. Of een antwoord een afgesloten melding heropent, is een regel en geen nieuwe versie.

De mensen errond. Bedrijven, contactpersonen en de aannemers die voor elke zone verantwoordelijk zijn, met een activiteitenoverzicht op elk record, plus zoeken in de volledige tekst van alles, exports en een auditspoor.

Meldingen die hun context meedragen. Abonneer je op een bedrijf, een installatie of een project en je hoort wat er daaronder verandert. De bezorging staat per persoon en per kanaal in — badge in de app, melding in de browser, e-mail — en de mail voegt toe waar één regel geen plaats voor heeft: het spoor van bedrijf tot taak, en tijdstippen in de tijdzone van de lezer. Elke titel begint met het dichtstbijzijnde dat het benoemen waard is, want er zijn tientallen plannen met een taak "Elektrische afwerking"; ze wordt één keer opgesteld en door alle drie de kanalen gelezen, zodat het onderwerp van de mail en de regel in de belknop niet uit elkaar kunnen groeien.

Een hiërarchie, niet dé hiërarchie. Bedrijf → locatie → installatie → apparatuur is de vorm die een fabriek nodig heeft, maar niets in de kern legt ze op. Tot de boom behoren is een verklaring die een model over zichzelf aflegt — één regel, geen controller en geen configuratie — en alles wat de boom leest, volgt daaruit: de navigator, de kruimelpaden, rechten die tot één tak beperkt blijven ("mag apparatuur wijzigen, maar enkel onder deze installatie"), het activiteitenoverzicht, de abonnementen, de zoekfunctie en de documentenkluis. Zo dragen de twee uitrollen vandaag al verschillende bomen op hetzelfde raamwerk — de ene daalt af via apparatuur en veldtoestellen tot hun bekabeling, de andere via projecten en de taken eronder — en een nieuw soort knooppunt is een verklaring in plaats van een project.

Twee bedrijven, één codebase. InSight draait voor twee organisaties met onverenigbare identiteitssystemen — de ene tegen Active Directory, de andere via OAuth. Vrijwel alle code zit in een gedeelde Rails-engine, met per klant een dunne hosttoepassing die enkel de authenticatie, de afwijkingen en de uitrolconfiguratie bevat. Een wijziging voor de ene betekent niet langer nadenken over het effect op de andere, en een derde erbij nemen is een host toevoegen in plaats van weer een vertakking door gedeelde code.

Resultaat

De ingenieur die wist hoe alles in elkaar zat, is niet langer het enige punt waar het op vastloopt, en één product bedient zowel een eigenaar-uitbater als een onderhoudsorganisatie, zonder dat een van beide het gevoel heeft het gereedschap van de ander te lenen.

De flexibele stukken komen allemaal uit dezelfde reflex: leg de variatie in het datamodel, waar ze niets kost — een hiërarchie die op een bedrijf kan wortelen, een boom waarvan elke uitrol zelf de soorten knooppunten bepaalt, een gedeelde engine met dunne hosts — in plaats van in vertakkende code die voor altijd onderhouden moet worden.