Bouwteam-Raamovereenkomst: Hoe beheers je Systems Engineering als de scope nog onbekend is?

Standaard

De GWW- en infrasector staat voor een enorme renovatie- en vervangingsopgave. Om snel en flexibel te kunnen handelen bij het onderhoud van wegen, bruggen en tunnels, kiezen opdrachtgevers steeds vaker voor een relatief nieuwe contractvorm: de bouwteam-raamovereenkomst (conform het Model Bouwteam DG2020 / DG2025). Het idee is super goed: je gunt vooraf het contract, en zodra er onderhoud nodig is, start je een nadere opdracht in bouwteamverband. Maar hoe beheers je de techniek, risico’s en de enorme berg eisen in je informatiesystemen als de scope per object continu verschuift?

Hoe combineer je flexibiliteit met het SE V-model

Binnen Systems Engineering (SE) is structuur heilig. Het klassieke V-model gaat uit van een lineair proces: je stelt de eisen vast, de markt bouwt het, en je verifieert of het klopt. Dit vereist een stabiele ‘baseline’.

Bij een raamovereenkomst voor variabel onderhoud is die basis er juist niet. Je weet vooraf immers nog niet exact welke tunnelventilator vervangen moet worden of welke asfaltlaag onderhoud nodig heeft. Zodra een acute nadere opdracht (nadere overeenkomst) wordt verstrekt, ontstaat er direct een flinke uitdaging op het gebied van informatie- en eisenmanagement:

  • Hoe houd je de eisensets per nadere opdracht actueel en juridisch zuiver?
  • Hoe voorkom je dat ad-hoc aanpassingen in een tunnel de centrale ‘as-built’ database van de assetmanager vervuilen?
  • Hoe behoud je het overkoepelende overzicht over alle verschillende opdrachten die tegelijkertijd lopen?

Om dit datatechnisch in te richten, zijn er in de praktijk twee beproefde opties. Welke opties zijn dat, en wanneer kies je voor welke optie?

Optie 1: De ‘Familie-omgeving’ (Alles in één project via slimme scopes)

In dit model breng je de basiseisenset (de moeder) en alle specifieke nadere opdrachten (de kinderen) samen binnen één en hetzelfde project. In plaats van de data fysiek te splitsen over verschillende databases (project omgevingen), splitsen we de informatie op basis van unieke, dynamische ‘scopes’ en rollen/rechten.

  • Wanneer te kiezen? Ideaal voor een hoge frequentie van kleinere tot middelgrote nadere opdrachten, waarbij vaak dezelfde (of een select aantal) aannemers betrokken zijn.
  • Voordelen: Geen ingewikkelde model-constructies in het systeem nodig. Omdat alle data in één project omgeving zit, is een overkoepelend koepel-dashboard (het helikopteroverzicht voor bijvoorbeeld het IPM team) realtime en zeer eenvoudig te realiseren.
  • Aandachtspunt: Je leunt zwaar op het autorisatiematrix-systeem. Rollen en rechten moeten feilloos zijn ingericht zodat Aannemer A absoluut niet in de scope van Aannemer B kan kijken of wijzigen.

Optie 2: De ‘Moeder-Kinderen omgevingen'(Per project een aparte omgeving, gekoppeld aan de basisomgeving)

In dit scenario kies je er heel bewust voor om voor elke nadere opdracht een fysiek losstaande, unieke contractomgeving (projectomgeving) in te richten. De relevante basiseisen worden aan de start eenmalig gekopieerd uit de Master-omgeving en volledig ‘bevroren’ in de projectomgeving van de specifieke opdracht.

  • Wanneer te kiezen? Bij zeer grote, risicovolle of technisch hoogcomplexe nadere opdrachten (denk aan de volledige renovatie van één specifieke tunnel binnen het raamcontract). Of wanneer je werkt met veel verschillende, concurrerende marktpartijen die gelijktijdig opdrachten uitvoeren.
  • Voordelen: Maximale juridische en operationele scheiding. Er is nul risico op datalekkage of ongewenste kruisbestuiving tussen opdrachten. De aannemer heeft zijn eigen ‘zandbak’ waarin hij ongestoord kan ontwerpen, verifiëren en valideren zonder dat het invloed heeft op de rest van de organisatie.
  • Aandachtspunt: De koepelomgeving (het overzicht over de projecten heen) is complexer te realiseren, omdat data uit verschillende bronnen geaggregeerd moet worden. Ook vereist de afronding (de data weer netjes terugkrijgen in de Master-omgeving) een strak gestructureerd data-acceptatieproces.

Grip op data is grip op het project

Er is geen one-size-fits-all oplossing. Soms vraagt de omvang van een scope vanwege legitieme redenen om een aparte omgeving, soms vraagt de snelheid van het proces om de efficiëntie van een familie-omgeving. Dit geldt voor infraprojecten, maar net zo goed voor complexe IT-omgevingen, hightech installaties of de utiliteitsbouw.

Benieuwd welke inrichting het beste past bij jouw projecten? Neem contact met ons op voor een vrijblijvende sparringsessie.

Waarom het wiel opnieuw uitvinden als de blauwdruk al klaarligt?

Standaard

Een frisse blik op Eenheid van Taal en het Federatief Datastelsel in de Zorg.

“Van Loenen Consultancy vindt federatief samenwerken belangrijk omdat het onze klanten in staat stelt om efficiënt en verantwoord data te delen, zonder dat zij de controle over hun eigen gegevens verliezen. In plaats van alle data te verzamelen in één gigantische, kwetsbare centrale database, blijven de gegevens bij de bron.”

De uitdaging voor informatiearchitecten en beleidsmakers

De zorg zoekt de oplossing voor interoperabiliteit en Eenheid van Taal momenteel primair binnen de traditionele zorgtooling. Het resultaat? Complexe, kostbare integratietrajecten die proberen systemen in een star keurslijf te dwingen.

Ondertussen worstelt de sector met het betrouwbaar overbruggen van vitale stelsels zoals SNOMED, LOINC, de Thesaurus Zorg en Welzijn (TZW) en GIZA. Waarom proberen we alles centraal te mappen en te synchroniseren, als de data veel veiliger en zuiverder direct bij de bron kan blijven?

Bewezen in de Bouw, onmisbaar voor de Zorg: Datastorms

De fysieke bouwwereld kent exact dezelfde uitdaging: honderden autonome partijen (architecten, aannemers, installateurs) die moeten samenwerken binnen één keten met hyper-complexe standaarden (zoals BIM). Fouten betekenen hier direct miljoenen aan faalkosten.

Met onze oplossing Datastorms hebben wij deze federatieve theorie in de bouw al jaren geleden omgezet in een robuuste praktijk. Die volwassen technologie en diepgaande expertise ontsluiten we nu voor de zorg.

Wat brengt Datastorms naar de zorgketen?

  • Federatieve Semantische Mapping: Datastorms fungeert als een dynamische, gedistribueerde vertallaag. Het brengt SNOMED, LOINC, TZW en GIZA federatief met elkaar in samenhang, zónder dat bronsystemen hun eigen taal of autonomie hoeven op te geven.
  • Geen data-duplicatie, geen synchronisatiefouten: Geen centrale databases of tijdelijke back-ups die binnen no-time verouderd zijn. Vraagbaak en vertaling vinden realtime plaats op het moment van uitvragen, direct bij de bron.
  • Privacy & Regie by Design: Volledig compliant met de AVG und NEN 7510. Omdat data nooit fysiek verplaatst of centraal gepoold wordt, blijft de datasoevereiniteit van de zorginstelling te allen tijde 100% gegarandeerd.
  • Direct inzetbare volwassenheid: Waar traditionele zorgtooling nog in de ontwerpfase zit voor echte federatieve stelsels, draait de core-engine van Datastorms al jaren op volle toeren in complexe, risicovolle fysieke infrastructuren.

Zullen we de zorgketen écht verbinden?

Wij laten u graag zien hoe we de kloof tussen theorie en zorgpraktijk overbruggen met een direct werkende, federatieve architectuur.

Start vandaag met een onafhankelijke infrastructuur

Standaard

3 partijen beheren samen ±70% van de Europese cloudmarkt: Amazon, Microsoft en Google. En dat heeft direct invloed op jouw data en infrastructuur. Wil jij volledige controle terug? 🛡️

Jij wilt dit:
Je bepaalt zelf waar je data staat.
En hoe je systemen draaien.

Dit wil toch eigenlijk iedere organisatie?

Daarom hebben wij Datastorms ontwikkeld.

Precies om die controle terug te brengen.

Dit platform draait op een 100% Europees fundament.

Onafhankelijk en transparant.

Wat betekent Datastorms concreet?
> Onafhankelijk van Big Tech
Je processen draaien los van AWS, Azure en Google
> Data onder jouw regie
Opslag en verwerking in Europa of op je eigen servers
> Volledige ondersteuning
Van procesbeheer tot data-analyse

Vrijheid in keuzes én volledige controle.

Jouw data. Jouw infrastructuur. Dus: jouw koers en niet de mijne én niet van de andere 3.

Start vandaag met een onafhankelijke infrastructuur. Een sparringspartner nodig om de (ontworpen) architectuur te challengen: neem contact op!

Vacature: Support consultant SE

Standaard

Als Support Consultant Systems Engineer ben je verantwoordelijk voor de ondersteuning van onze consultants op projecten. Je organiseert dat de informatiebehoefte ingeregeld wordt. Door jouw achtergrond ben je in staat snel verbanden te leggen en zal blijken of je meer past bij de technische kant van het vak of juist de processen. Je maakt daarbij vaak deel uit van een multidisciplinair team waarbij je door je kennis van de processen van toegevoegde waarde bent. Tenslotte zal je ook betrokken zijn bij de implementatie van de processen en de uitgewerkte tooling. Je wordt binnen onze organisatie onderdeel van een team van 8 gedreven professionals met een diversiteit aan achtergrond en ervaring. Onderling zorgen we voor kruisbestuiving van onze kennis en ervaring, zodat we onze opdrachtgevers optimaal bedienen. De uitvalbasis is Zoetermeer, maar het merendeel van de tijd zit je bij onze klanten op dynamische plekken waar je jezelf kunt ontwikkelen.

  • HBO/WO denkniveau (technische achtergrond)
  • Kennis van Systems Engineering en deze methodiek zelf ook toegepast binnen projecten
  • IT affiniteit, je snapt hoe databases werken
  • Beheersing Nederlandse en Engelse taal
  • Beschikt over de volgende competenties: leergierig, doorzetter, analytisch en resultaatgericht.
  • Flexibel contract zodat je ook nog kunt studeren
  • Interessante beloningsstructuur
  • Reiskostenvergoeding (ook als je met de fiets komt)

Van Loenen is een no-nonsense ingenieursbureau met een sterke focus op kwaliteit en het realiseren van exclusieve, complexe projecten. Wij onderscheiden ons door een eerlijke en directe aanpak: bij Van Loenen krijg je geen mooipraterij, maar de nuchtere realiteit. Onze klanten kiezen voor ons omdat wij vakinhoudelijk sterk zijn en altijd voor de beste oplossing gaan, zelfs als dat soms betekent dat we tegen de stroom in moeten adviseren.

Onze ingenieurs werken nauw samen met de opdrachtgever en denken actief mee in elke fase van het project. We zetten ons in om de visie van onze klanten te vertalen naar concrete, haalbare resultaten, waarbij we ons richten op een succesvol eindproduct. Wij zoeken altijd collega’s die zich herkennen in ons profiel en ons samen willen werken aan mooie opdrachten!

Ben jij de kandidaat die past binnen dit plaatje? Ben je daarnaast gemiddeld 16 uur per week beschikbaar voor een periode van 6 maanden? Neem contact op!

Vacature: Procesmodelleur Systems Engineer

Standaard
Unieke antwoord op informatievraagstukken in GWW en maritieme projecten

Als Procesmodelleur Systems Engineer ben je verantwoordelijk voor het inrichten en het begeleiden van processen binnen projecten. Daarnaast organiseer je dat de bijbehorende informatiebehoefte ingeregeld wordt. Dit doe je in nauwe samenwerking met de Opdrachtgever. Je maakt daarbij vaak deel uit van een multidisciplinair team waarbij je door je kennis van de processen van toegevoegde waarde bent. Tenslotte zal je ook betrokken zijn bij de implementatie van de processen en de uitgewerkte tooling. Je wordt binnen onze organisatie onderdeel van een team van 8 gedreven professionals met een diversiteit aan achtergrond en ervaring. Onderling zorgen we voor kruisbestuiving van onze kennis en ervaring, zodat we onze opdrachtgevers optimaal bedienen. De uitvalbasis is Zoetermeer, maar het merendeel van de tijd zit je bij onze klanten op dynamische plekken waar je jezelf kunt ontwikkelen.

    • HBO/WO denkniveau (technische achtergrond)
    • Enkele jaren werkervaring binnen projecten
    • Kennis van Systems Engineering en deze methodiek zelf ook toegepast binnen projecten
    • IT affiniteit, je snapt hoe databases werken
    • Ervaring met Relatics
    • Beheersing Nederlandse en Engelse taal
    • Beschikt over de volgende competenties: analytisch, samenwerken, resultaatgericht en conceptueel denken
    • Concurrerend salaris
    • Eindejaarsuitkering
    • Werktelefoon Iphone
    • Werklaptop Macbook
    • Auto van de zaak
    • Liever met de trein? (NS business card)

    Van Loenen is een no-nonsense ingenieursbureau met een sterke focus op kwaliteit en het realiseren van exclusieve, complexe projecten. Wij onderscheiden ons door een eerlijke en directe aanpak: bij Van Loenen krijg je geen mooipraterij, maar de nuchtere realiteit. Onze klanten kiezen voor ons omdat wij vakinhoudelijk sterk zijn en altijd voor de beste oplossing gaan, zelfs als dat soms betekent dat we tegen de stroom in moeten adviseren.


    Onze ingenieurs werken nauw samen met de opdrachtgever en denken actief mee in elke fase van het project. We zetten ons in om de visie van onze klanten te vertalen naar concrete, haalbare resultaten, waarbij we ons richten op een succesvol eindproduct. Wij zoeken altijd collega’s die zich herkennen in ons profiel en ons samen willen werken aan mooie opdrachten!

    Ben jij de kandidaat die past binnen dit plaatje? Of heb jij de ambitie om de ontbrekende vaardigheden je eigen te maken? Dan hopen we dat je reageert op deze vacature! Naast fulltime is ook parttime bespreekbaar, met een minimum van 24 uur per week.

    Een referentiecheck en vaardighedentoets kunnen onderdeel zijn van de selectieprocedure.

    📁 Haal het maximale uit je data met een slim informatiemodel voor betere projectresultaten

    Standaard

    Een goed beheerde bibliotheek begint met een sterk informatiemodel – zonder dat model raak je al snel de controle kwijt over je data. Denk aan een projectomgeving als een werkplaats: snel, dynamisch, maar vaak ook chaotisch. Een bibliotheek daarentegen is als een magazijn: gestructureerd, georganiseerd en klaar voor hergebruik. Dit hebben we uitvoerig besproken in het eerste blog uit de serie ‘Bibliotheken en projecten – het magazijn en de werkplaats’.

    Nu gaan we een stap verder en duiken we in de vraag: hoe kun je je data efficiënt beheren en toekomstbestendig maken zodat je er op de lange termijn steeds meer waarde uit kunt halen? In dit artikel ontdek je hoe een goed informatiemodel de basis legt voor een perfect georganiseerde bibliotheek, zodat je data altijd herbruikbaar en waardevol blijft.

    Wat is een informatiemodel?

    Eerst even de basis: een informatiemodel is de blauwdruk die vastlegt hoe data wordt georganiseerd en beheerd binnen een bibliotheekomgeving. In een goed informatiemodel bepaal je hoe informatie wordt gestructureerd, gecategoriseerd en toegankelijk blijft, zodat deze niet alleen nuttig is in het hier en nu, maar ook voor toekomstige projecten. Een magazijn is alleen effectief als alles op een vaste plek ligt en volgens duidelijke regels is ingedeeld. Dus net als een bibliotheek waarin informatie consistent en herbruikbaar moet zijn. Een goed informatiemodel biedt een raamwerk dat zorgt voor toegankelijkheid, betrouwbaarheid en duurzaamheid van je data. Maar waarom is dat van belang?

    Waarom een solide informatiemodel belangrijk is

    In een projectomgeving, vergelijk het met de ‘werkplaats’, is alles gericht op snelheid en resultaat. Data is vaak van tijdelijke aard en specifiek voor het project. Maar in een bibliotheek, vergelijkbaar met een ‘magazijn’, is het doel juist om data overzichtelijk te bewaren met focus op gebruik voor de langere termijn. Een goed informatiemodel helpt om chaos te voorkomen, zorgt voor consistente opslag en voorkomt dat waardevolle informatie verloren gaat. Het model geeft de structuur om data niet alleen op te slaan, maar ook altijd te kunnen vinden en begrijpen.

    Een sterk informatiemodel helpt deze scheiding te behouden door data gestructureerd op te slaan in de bibliotheek, waardoor het duurzaam beschikbaar blijft voor toekomstige projecten, net zoals een goed beheerd magazijn dat doet voor essentiële materialen. Maar ook om georganiseerd aanpassingen aan de data in de bibliotheek door te voeren, zodat deze mee blijft bewegen met de behoeften die projecten hebben zonder dat andere projecten daar last van ondervinden.

    Top 3 voordelen van een informatiemodel

    Laten we de voordelen van een goed gebouwd informatiemodel opsommen:

    Herbruikbare data
    Een slim ontwikkeld systeem van bibliotheek en project maakt data vindbaar en toepasbaar in nieuwe projecten.

    Samenwerking verbeteren
    Een duidelijke structuur zorgt ervoor dat iedereen binnen de organisatie dezelfde ’taal’ spreekt als het gaat om data.

    Foutreductie
    Een informatiemodel voorkomt dat gegevens worden verkeerd geïnterpreteerd of verloren raken.

    Hoe een effectief informatiemodel eruit moet zien

    Net zoals een magazijn georganiseerd moet zijn, moet een informatiemodel ook duidelijke kaders bieden. De volgende elementen helpen je een effectief informatiemodel op te bouwen voor je bibliotheek:

    1. Data-entiteiten en -attributen

    In een magazijn kun je items ordenen op soort, formaat of functie. Zo begint een informatiemodel met het aanwijzen van data-entiteiten, zoals documenten, metadata en projectinformatie. Voor elke entiteit worden attributen vastgelegd, zoals naam, datum, auteur en relevante trefwoorden. Deze indeling zorgt ervoor dat informatie consistent en eenvoudig terug te vinden is, net zoals een magazijn waarin alles een vaste plek heeft.

    2. Relaties tussen data

    In een goed informatiemodel is het niet genoeg om data simpelweg op te slaan; de relaties tussen verschillende stukken informatie moeten ook vastgelegd worden. Bijvoorbeeld: een document kan gelinkt zijn aan een project, een rapport, of een bepaald proces. Deze verbindingen geven context en maken het mogelijk om data in een bredere context te zien. Net zoals een magazijn dat efficiënter werkt als alle gerelateerde materialen dichtbij elkaar liggen, wordt een bibliotheek overzichtelijker door relevante informatie aan elkaar te koppelen.

    3. Metadata en classificatie

    Metadata is cruciaal in een informatiemodel. Het bevat informatie over de data zelf, zoals auteur, datum, status en versies. Metadata maakt je ‘magazijn’ overzichtelijk, zodat je snel kunt vinden wat je zoekt. Classificatie voegt hier een extra laag aan toe: door data te categoriseren op basis van onderwerp of type, creëer je een logisch systeem voor het doorzoeken van grote hoeveelheden informatie.

    4. Versiebeheer

    Een magazijn moet ook kunnen doorontwikkelen; verouderde items moeten worden vervangen door nieuwe versies. Net zo is versiebeheer essentieel in een informatiemodel. Projectdata verandert voortdurend, en versiebeheer helpt om wijzigingen bij te houden en terug te kijken naar eerdere versies als dat nodig is. Dit voorkomt verwarring en garandeert dat je altijd de juiste informatie bij de hand hebt, net als een magazijn waarin items nauwkeurig zijn geëtiketteerd en bijgehouden.

    5. Toegangsrechten, beveiliging met normering als puntje op de ‘i’

    Niet iedereen heeft toegang tot alle onderdelen van een magazijn. Dit geldt ook voor een bibliotheek: toegangsrechten bepalen wie bepaalde data mag bekijken, bewerken of verwijderen. Door duidelijke rechten en beveiliging in je informatiemodel op te nemen, bescherm je gevoelige informatie en voorkom je dat data verloren gaat of per ongeluk wordt aangepast.

    Om deze processen verder te verbeteren, het puntje op de ‘i’, kunnen normen zoals ISO 27001 en ISO 9001 je helpen. ISO 27001 biedt richtlijnen voor het beveiligen van informatie, terwijl ISO 9001 ondersteunt bij het organiseren en beheren van kwaliteitsdocumenten. Door je organisatie klaar te maken voor deze normen, versterk je zowel de toegankelijkheid als de beveiliging van je databeheer.

    6. Onderhoud en Updates

    Een informatiemodel vereist net als een magazijn regelmatig onderhoud. Periodieke evaluaties zorgen ervoor dat het model nog steeds aansluit bij de huidige behoeften van de organisatie. Door het model up-to-date te houden, blijft data relevant en bruikbaar, zelfs wanneer de organisatie of technologie verandert.

    Wat zo’n informatiemodel je oplevert in tijd en geld

    Een slim informatiemodel maakt het beheren van data niet alleen eenvoudiger, maar levert direct besparingen op. Volgens McKinsey besparen organisaties met goed gestructureerde informatiesystemen tot wel 30% aan tijd die anders verloren gaat aan zoeken en organiseren van data. Met een robuust model is informatie altijd vindbaar en herbruikbaar, wat de productiviteit aanzienlijk verhoogt (McKinsey & Company, 2012).

    IDC schat zelfs dat kenniswerkers dagelijks tot 2,5 uur kwijt zijn aan het zoeken naar informatie, tijd die door een sterk informatiemodel met 50% verminderd kan worden. Voor een team van 100 mensen levert dat jaarlijks duizenden uren op, die je direct kunt inzetten voor belangrijker werk (IDC, 2014).

    En dan de kosten: slechte datakwaliteit kan wel 20% van de operationele uitgaven opslokken, zegt Gartner. Met een goed informatiemodel voorkom je dubbele data, fouten, en correctiekosten, wat je operationele kosten flink drukt (Gartner, 2020).

    Benieuwd hoe een goed informatiemodel jouw organisatie efficiënter en winstgevender kan maken? Volg dan onze hele serie ‘Bibliotheken en projecten – het magazijn en de werkplaats’: https://van-loenen.org/%f0%9f%93%81-start-van-onze-zesdelige-serie-bibliotheken-en-projecten-het-magazijn-en-de-werkplaats/

    📁  Start van onze zesdelige serie: Bibliotheken en projecten – Het magazijn en de werkplaats.

    Standaard

    Hou je projectdata bruikbaar! Deel 1 van 6

    In veel organisaties heerst een hardnekkige misvatting: een projectomgeving met veel data zou vanzelf een bibliotheek worden. Helaas is dit niet waar. Projectomgevingen en bibliotheken vervullen heel verschillende rollen. Vergelijk het met een werkplaats en een magazijn: de werkplaats is dynamisch, snel en gericht op het hier en nu, terwijl het magazijn zorgvuldig beheerd wordt voor lange termijn gebruik. In deze serie artikelen leggen we uit waarom het belangrijk is deze omgevingen gescheiden te houden en hoe je dat effectief kunt doen.

    In dit eerste artikel van een serie van zeven, bekijken we het verschil tussen een projectomgeving en een bibliotheek. De komende zes artikelen gaan dieper in op specifieke aspecten van bibliotheekbeheer en het belang van een goed informatiemodel om je projectdata bruikbaar te houden. 

    De misvatting: veel data in je projectomgeving creëert geen bibliotheek

    Het is verleidelijk om te denken dat een projectomgeving vol data vanzelf verandert in een bibliotheek. Het lijkt een logische stap: je hebt veel gegevens, je slaat ze op, en voilà—een bibliotheek is geboren. Maar zo simpel is het niet. Een projectomgeving is meer te vergelijken met een werkplaats: dynamisch, chaotisch en gericht op specifieke taken. Zodra het project is afgerond, is de werkplek leeg, en wat overblijft is meestal niet direct bruikbaar voor een ander project.

    Een bibliotheek daarentegen functioneert als een goed georganiseerd magazijn. Hier worden materialen (of data) opgeslagen met het oog op hergebruik. In plaats van dat de informatie specifiek is voor één project, is bibliotheekdata gestandaardiseerd en bedoeld voor gebruik in meerdere projecten. Het magazijn heeft vaste processen: je weet precies wat waar ligt, wat aangevuld moet worden en wanneer iets verouderd raakt. Een bibliotheek moet op dezelfde manier beheerd worden—het vereist een duidelijk informatiemodel, structuur en continue monitoring.

    Als je projectdata zonder een duidelijk systeem probeert op te slaan als bibliotheekdata, ontstaat chaos. Data raakt verspreid, onvindbaar of onbruikbaar. Door de functies van een projectomgeving en een bibliotheek goed te scheiden en elk met de juiste tools en processen te beheren, voorkom je deze problemen en zorg je voor een efficiënte en duurzame datastroom.

    Met deze introductie hebben we de basis gelegd voor wat een duidelijke en nuttige scheiding tussen projectomgevingen en bibliotheken betekent. In de volgende artikelen gaan we dieper in op de specifieke uitdagingen en oplossingen, zodat je leert hoe je data effectief organiseert en beheert, en de waarde van je informatie voor de lange termijn behoudt. Volg ons voor het volgende deel van deze serie!

    Dit kun je verwachten in de komende edities: 

    2. De essentie van een goed informatiemodel voor bibliotheken

    In dit artikel gaan we in op hoe een robuust informatiemodel de ruggengraat vormt van elke goed beheerde bibliotheek, en wat de belangrijkste elementen zijn.

    3. Voorbeeld: het Verschil in proces tussen magazijn en werkplek

    We vergelijken de werkprocessen van een projectomgeving en een bibliotheek, met praktische voorbeelden om de verschillen duidelijk te maken.

    4. Valkuilen van het proberen een bibliotheek te creëren binnen een projectomgeving

    Hier behandelen we de specifieke fouten die gemaakt worden wanneer projectmanagers proberen een bibliotheek op te zetten zonder de juiste structuur of tools.

    5. De juiste structuur: het organiseren van een bibliotheek

    Dit artikel biedt een stappenplan voor het opzetten van een effectieve bibliotheek, met aandacht voor structuur, processen en onderhoud.

    6. Tools en technologieën voor bibliotheekbeheer

    Tot slot bespreken we de software en tools die je helpen bij het effectief beheren van je bibliotheek, zoals Relatics, TopTeam en Datastorms.

    Hoe borg je kwaliteit van je OTL en Eisenbibiotheek? Structuur in je organisatie!  

    Standaard

    Veel organisaties hebben al een stap gezet of overwegen om objecttypenbibliotheken (OTL’s) en eisenbibliotheken op te zetten. Voor technici en ingenieurs is het cruciaal om niet alleen aandacht te besteden aan de initiële inrichting van deze bibliotheken, maar ook aan het voortdurend bijwerken en onderhouden ervan. Het is van essentieel belang om zowel bij de opzet als bij de dagelijkse werking oog te hebben voor de organisatie en structuur om de kwaliteit en effectiviteit van deze hulpmiddelen te waarborgen.

    Hoewel standaardisatie aanzienlijke voordelen biedt, kan het risico ontstaan dat verantwoordelijkheden en rolverdelingen niet voldoende worden gedefinieerd. Voor technici en ingenieurs is het cruciaal dat de implementatie van een standaard samengaat met een heldere structuur van functies en verantwoordelijkheden. Zonder deze duidelijke rolverdeling kunnen taken rondom het beheer en onderhoud van een objecttypenbibliotheek (OTL) en eisenbibliotheek onvolledig of inefficiënt worden uitgevoerd, wat de effectiviteit van het systeem in gevaar kan brengen.

    Standaardisatie en structuur zijn key

    Standaardisatie kan, naast het opleveren van heldere processen en efficiënte samenwerking, ook helpen om inzicht te krijgen in de complexiteit van eisen en objecten binnen een organisatie. Zo kan een goed ingerichte OTL en eisenbibliotheek ervoor zorgen dat de informatie beter wordt beheerd en toegankelijker is voor alle betrokkenen.

    Het opstellen van een objecttypenbibliotheek en eisenbibliotheek is echter slechts een onderdeel van het succes. De vraag die vaak onderbelicht blijft, is wie verantwoordelijk is voor het onderhoud ervan? Wie houdt de bibliotheken up-to-date, zorgt voor de naleving van standaarden, en beheert wijzigingen? Hier ligt een belangrijke organisatorische uitdaging: het creëren van een duidelijke taakverdeling en het inrichten van een beheermodel voor deze bibliotheken.

    BOMOS als start-up of spiegel

    Een goed startpunt voor een raamwerk dat organisaties kan helpen bij het organiseren van de verantwoordelijkheden rondom het beheer van standaarden en bibliotheken is het Beheer- en Ontwikkelmodel voor Open Standaarden (BOMOS). Dit raamwerk, afgeleid van NEN 2522, helpt organisaties niet alleen met de technische aspecten van standaardisatie, maar richt zich ook specifiek op de organisatorische kant.

    BOMOS biedt handvatten voor de inrichting van rollen en verantwoordelijkheden, en legt een duidelijke structuur vast voor het beheer en de ontwikkeling van standaarden. Zo wordt er binnen BOMOS bijvoorbeeld onderscheid gemaakt tussen verschillende rollen, zoals de standaardbeheerder, de ontwikkelaar, en de eindgebruiker. Deze rollen zorgen ervoor dat alle taken en verantwoordelijkheden duidelijk zijn afgebakend, waardoor er minder risico ontstaat op gaten in het beheerproces. Met BOMOS kunnen organisaties zorgen voor een continue ontwikkeling van hun standaarden, waarbij governance een centrale rol speelt. Dit zorgt niet alleen voor duidelijke eigenaarschap, maar ook voor een gestructureerd proces om wijzigingen door te voeren en te controleren of de standaarden actueel blijven.

    Spiegel aan BOMOS als er al een bestaande organisatie structuur is

    Hoewel BOMOS een effectief model biedt voor het organiseren van rollen en verantwoordelijkheden, kunnen organisaties ervoor kiezen hun eigen structuur en functiehuis te hanteren. Dit kan noodzakelijk zijn wanneer interne processen of specifieke eisen afwijken van de standaard BOMOS-aanpak. Belangrijk hierbij is dat de organisatie zich spiegelt aan BOMOS om te waarborgen dat alle noodzakelijke verantwoordelijkheden volledig zijn afgedekt.

    Een eigen structuur biedt flexibiliteit, maar het is cruciaal dat de verantwoordelijkheden helder zijn vastgelegd en dat niets over het hoofd wordt gezien. Organisaties moeten ervoor zorgen dat hun functiehuis duidelijk beschrijft wie verantwoordelijk is voor welke onderdelen van de bibliotheek, zoals de objecttypenbibliotheek (OTL) en eisenbibliotheek.

    Daarnaast moet dit functiehuis niet alleen rollen en verantwoordelijkheden vastleggen, maar ook beschrijven hoe taken worden uitgevoerd, welke bevoegdheden medewerkers nodig hebben, en hoe rapportagelijnen lopen. Door een eigen structuur op deze manier te spiegelen aan het BOMOS-model, kan een organisatie er zeker van zijn dat haar interne processen volledig en effectief blijven, zonder dat er cruciale aspecten van het beheer en onderhoud van de bibliotheek worden gemist.

    Communicatie over structuur en werkwijze

    Bij het opzetten van een eigen structuur, of deze nu gebaseerd is op BOMOS of een eigen functiemodel, is het van cruciaal belang dat alle taken en verantwoordelijkheden rondom het beheer van de bibliotheek volledig afgedekt zijn. De verdeling van taken moet zodanig zijn dat elke stap in het beheerproces duidelijk is toegewezen aan een verantwoordelijke. Dit garandeert dat de bibliotheken actueel blijven en voorkomt miscommunicatie over wie welke wijzigingen moet doorvoeren of controleren.

    Naast volledige dekking is transparante communicatie binnen de organisatie essentieel. Zorg ervoor dat de werkwijzen en verantwoordelijkheden niet alleen intern duidelijk zijn, maar ook breed gedeeld worden via platforms zoals het intranet of interne portals. Zo kunnen medewerkers altijd toegang krijgen tot informatie over de processen en hun rol daarin. Uitleg van procedures, verantwoordelijkheden, en escalatieroutes dient duidelijk en toegankelijk te zijn voor iedereen die betrokken is bij het beheer van de bibliotheek.

    Bovendien is het belangrijk om escalatieprocedures in te richten. Als een medewerker merkt dat bepaalde standaarden niet worden nageleefd of dat er fouten optreden, moet er een heldere route zijn om deze problemen te melden en op te lossen. Het opstellen van een governance-model met duidelijke verantwoordelijkheidslijnen helpt om dergelijke situaties effectief te beheersen en zorgt ervoor dat er tijdig actie wordt ondernomen.

    Door zowel de structuur als de communicatie zorgvuldig op te zetten, creëer je een omgeving waarin medewerkers niet alleen weten wat hun taken zijn, maar ook hoe ze problemen kunnen signaleren en oplossen.

    De praktische toepassing van BOMOS voor een OTL

    In onderstaande afbeelding staat weergegeven welke rollen er vanuit BOMOS van toepassing zijn op de ontwikkeling van een bibliotheek voor een programma.

    De compleet ingerichte organisatie rondom een OTL en/of bibliotheek ziet er dan alsvolgt uit. De volgende functies en verantwoordelijkheden moeten worden ingevuld:

    RolKorte beschrijving
    FinancierVerantwoordelijk voor het financieren van het ontwikkelen en beheren van standaarden.
    Houder:Eindverantwoordelijk voor het ontwikkelen en beheren van een standaard. De eigenaar bepaalt de scope en het doel van een standaard, en bepaalt de principes en de uitgangspunten die worden gehanteerd bij ontwikkeling en beheer.
    AutorisatorKeurt een standaard goed. Toelichting: een autorisator kan een persoon, organisatie of groep van personen en organisaties zijn. Het is aan de eigenaar om de autorisator te benoemen. Een autorisator bevat vaak een vertegenwoordiging van stakeholders, die als persoon of organisatie ook de rol gebruiker hebben.
    Functioneel beheerder (kennisregisseur)Verantwoordelijk voor het proces van ontwikkelen en beheren van standaarden, binnen de kaders van de gemaakte afspraken en afgesproken governance. Toelichting: de functioneel beheerder is verantwoordelijk voor het proces van ontwikkelen en beheer van de inhoud van standaarden. Hiervoor werkt hij nauw samen met experts, gebruikers, de technische beheerder en de distributeur. De functioneel beheerder heeft vaak een regie voerende rol. Resultaten van het proces worden voorgelegd aan de autorisator.
    ExpertBrengt specifieke noodzakelijke expertise in ten behoeve van het ontwikkelen of beheren van een standaard. Toelichting: verschillende type experts kunnen, afhankelijk van de standaard, noodzakelijk zijn. Veel voorkomende experts zijn domein-inhoudelijk SE-kennis, kostendeskundige. Vaak voorkomend is ook een vertegenwoordiging ervaringsdeskundige stakeholders die als persoon of organisatie ook de rol gebruiker hebben.
    Technisch beheerderVerantwoordelijk voor het technisch beheren van standaarden. De technisch beheerder zorgt voor de inrichting en beheer van een technische omgeving die noodzakelijk is om de artefacten die onderdeel zijn van de standaard te ontwikkelen (OBO) en vrij te geven (Bieb/Platform) Toelichting: De technisch beheerder is verantwoordelijk voor de technische omgeving waarin de artefacten, die in beheer zijn, worden onderhouden. Zo’n technische omgeving zal bestaan uit het geheel aan ICT-middelen (tools, hardware, netwerken, e.d.) die noodzakelijk zijn om het functioneel beheer uit te kunnen voeren op de standaard. Onder de verantwoordelijkheid van de technische beheerder valt o.a.. het kunnen toepassen van versiebeheer op de technische omgeving en het beschikbaar stellen en houden van de technische omgeving, in overleg met de functioneel beheerder.
    DistributeurVerantwoordelijk voor het distribueren en communiceren van de standaarden naar de beheeromgeving. Stelt releases van verzamelingen van kennisdocumenten en standaardeisen beschikbaar, conform de afspraken. Stelt gebruikers in staat contact op te nemen, de standaard te verkrijgen en informeert over de beschikbaarheid. Stelt de functioneel beheerder op de hoogte van aangedragen verbeterpunten. Stelt alle betrokkenen op de hoogte van de achtergrond voor de overgang naar de nieuwe versie. 
    GebruikerGebruikt de informatiebouwstenen op gewenste, vastgestelde wijze en conform het vastgestelde doel. Kan commentaar en/of wijzigingsverzoeken indienen m.b.t. de standaard

    Neem contact met ons op

    Bent u benieuwd hoe wij uw organisatie kunnen helpen om de standaarden te borgen in de organisatie? Neem vrijblijvend contact met ons op voor meer informatie over onze diensten en prijzen.
    Bel ons op 079 302 00 00, stuur een e-mail naar info@van-loenen.org, of vul het contactformulier in.

    Why systems engineers with industry expertise are essential for successful software implementations

    Standaard

    Systems engineers with field and industry knowledge play a crucial role in software implementations. Their deep understanding of both technical and operational aspects ensures seamless integration of software into existing systems. Martijn van Loenen, director at Van Loenen Consultancy, states: “There is a common misconception that only consultants from software suppliers are adequately equipped to meet in-depth, industry-specific requirements. However, they often lack essential knowledge about the strategic use of software within current projects. The synergy approach, or ‘1 + 1 = 3,’ is essential for effectively solving complex challenges in sectors such as engineering, production, and construction.”

    In the Netherlands, many tenders are continuously initiated. Martijn explains: “In practice, the requests from clients, as noted in the tender, often do not fully match their actual needs. This almost certainly leads to additional costs. I have seen project tenders with an initial budget of €100,000 rise to €150,000 or more. This often happens without stakeholders being fully aware of the reasons for these cost increases. Although such increases are allowed under procurement law, the question arises whether this is both ethically and operationally justified. More importantly, could this have been prevented?”

    The answer is clear. Martijn states: “Systems engineers with sector knowledge better oversee both the technical and operational aspects of a project, unlike consultants from software companies who often only approach the software side. By utilizing the extensive expertise of systems engineers, the actual needs of a client can be identified more accurately and timely. This significantly reduces the risk of budget overruns and unforeseen costs.”

    Looking for the Dutch version of this article? See this page.

    Incorrect software implementations due to a lack of sector insight can have significant financial implications. Martijn explains: “Costs for revisions, delays, and inefficiencies often skyrocket when the implemented solutions do not meet the client’s actual needs.” Let’s zoom in on these financial implications.

    Revisions/Adjustments: Projects lacking field knowledge frequently lead to multiple rounds of revisions. Each revision incurs additional costs, both in labor hours and material expenses.

    Delays: Project delivery delays are a direct consequence of incorrect implementation. In extreme cases, these delays lead to penalties and almost always result in lost revenue and/or increased operational costs.

    Inefficiencies in business processes: Software that does not align well with business processes results in inefficiencies, leading to higher operational costs as employees spend more time on manual corrections and workarounds.

    Maintenance and support: Poor initial implementation increases the need for ongoing support and maintenance, requiring extra resources that could have been invested in growth and innovation.

    Can it be done differently? Martijn and his team at Van Loenen Consultancy believe so. “Our team consists of systems engineers with field and sector knowledge. They are happy to play that crucial role in software implementations. Their deep understanding of both technical and operational aspects ensures seamless integration of software into existing systems.”

    When engineers have a thorough understanding of both the technical capabilities and the sector they work in, it directly impacts the project. Here are the top 5 benefits:

    1. Identifying relevant requirements: Systems engineers with field and sector knowledge understand which software functions are essential for daily operations within the sector.
    2. Insight into operational processes: increasing efficiency: By understanding both software and the sector, systems engineers can optimize processes and reduce bottlenecks.
    3. Providing innovative solutions: Systems engineers with field and sector knowledge are better able to think outside the box and design innovative solutions tailored to the sector.
    4. Faster problem solving: Systems engineers with dual expertise can identify and solve problems faster because they know how software behaves within specific operational environments.
    5. Effective Communication: Systems engineers with field and sector knowledge act as a bridge between IT and operational teams, reducing misunderstandings and improving collaboration.

    What does this look like in practice? The Amsterdam road tunnels are a good example of how two worlds come together. In this project, a library was developed as a basis for multiple projects. Martijn explains: “The goal was to ensure a structured and consistent approach so that specifications and requirements were clear and applicable. The document used for this was called the ‘Amsterdam Tunnel System’ (ATS). When we reviewed it, many ambiguities quickly emerged, such as missing information and undefined responsibilities. To address these issues, we helped develop the Standard Tunnel Amsterdam (STA) according to the principles of Model-Based Systems Engineering (MBSE).”

    The ATS was initially created in Word. Martijn notes: “We developed the STA according to system architecture. It works much better. For example, if a fan is needed, it must meet specific requirements. By using models with a standard structure and a smart library, we ensure that everything fits and works. By incorporating experiences with deviations in your library, you ensure that the next project runs even better and more efficiently.

    What often goes wrong with standard libraries is that feedback from projects is not well documented. Feedback from projects can be included, and this new knowledge can be passed on to ongoing and future projects. This makes the system better over time.

    Another misconception is that a complete library must be available before projects can use it. But when is a library ever complete? Often, it is thought that the library is complete once the first project starts. However, a library is never really complete. There can always be missing knowledge, errors, or solutions that do not work well in practice.

    Only by actually using the library and collecting and processing feedback does it improve over time. And so do your projects. This process makes the library and your projects ultimately correct, complete, and consistent.”

    Martijn continues: “Many people equate a system library with the project environment, but a library behaves differently. A library contains your completed knowledge, innovations, and useful information you have documented. You incorporate knowledge from previous projects and build on your current knowledge. Additionally, you store information in this library. If done well, you can prevent mistakes.”

    An important prerequisite for a well-functioning library is assigning ownership and responsibility. Martijn states: “There must be a clear escalation route, with an authorized person ultimately responsible for the standard and the management of the library. This prevents miscommunication and ensures consistency and quality. By making good internal agreements and clearly defining responsibilities, we can effectively solve these challenges and strengthen our teams and projects.

    Thanks to our engineers’ extensive field knowledge, this project was a success.”

    Systems engineers with field knowledge are not just technicians; they are a strategic partner who contributes to the success of software implementations.

    – Martijn van Loenen, Director at Van Loenen Consultancy

    Van Loenen Consultancy is an expert in structuring projects and complex configurations with Systems Engineering and information management systems. Since 2008, our engineers have made a difference with our integral concept, utilizing extensive knowledge and skills in both Systems Engineering and Model-Based Systems Engineering, and the technology behind semantic databases. We offer services such as structuring processes and data, project support, application development, and integrations. Van Loenen Consultancy specializes in Relatics, TopTeam, SharePoint, and Datastorms, effectively solving complex issues and managing and supporting the entire cycle of a project or product.

    Martijn concludes, “As a team passionate about the application of Systems Engineering, Van Loenen Consultancy has recently become a member of the International Council on Systems Engineering (INCOSE).”