Welcome Marianne


Marianne has recently started at Konato. She is a result-oriented consultant and wants to raise organisations to a higher level by supporting and executing successful projects. Since there is also the need for soft skills within a project outside of project-based skills, this lady is studying work and organizational psychology (VUB) in her spare time. Welcome to the team! #Konato #teamplayer #newemployee #welkom #topteam


Digital transformation: Bimodel IT?

Bimodel IT is a two-tiered IT operations model which was introduced by Gartner around 2014. It defines the two tiers as “Mode 1, traditional and sequential, emphasizing safety and accuracy, also referred to as exploitation. Mode 2 is exploratory, nonlinear, emphasizing agility and speed.

Each mode will require a different management approach. Processes, organizational structures and people will be different. The pitfall of this model is to just start splitting the IT-systems into these different modes. Splitting the IT-landscape in legacy systems, CRM, ERP, mobile apps,… . Two separate IT groups working at different speeds will not lead to organizational performance. This problem is already raised in many academic reviews on ambidexterity in organizations. It is the balance between exploration and exploitation which will lead to organizational performance.

This shows the need for a proper IT governance, organization structures, hybrid models combining best of both worlds. Forcing an organization into a ‘exploratory’ mode will result in organizational issues, impacting the performance of the organization. Don’t forget that ‘innovative’ companies like Apple have supporting processes which focus on efficiency otherwise they don’t manage the selling and delivery of million products each year. They succeed in combining the two modes and are not only ‘innovative’ as they bring their products into the world.

Digital transformations will handle the questions how to reach this equilibrium, where to start? Focus first on the transformation of the legacy systems? Shift to SAAS-models? Which IT project governance to use? One size doesn’t fit all, therefore the management of an organization needs to be aware of these choices, a proper enterprise architecture will guide in this process. Key is the alignment of the business strategy with the IT-strategy. Digital transformation is not only introducing a mobile app into the organizations or start working in Scrum teams. It is about focusing on the right organizational change within the company.

– Nico Schaetsaert

23 december 2021

Konato team weekend 2021

Ons teamweekend was er weer boenk op! We liepen over vuur, we vochten tegen zombies in een virtuele wereld en we zwierven ‘s nachts door de bossen van Nadrin. Avontuur en plezier in het kwadraat. Collega’s, jullie waren de max! 

4 oktober 2021

EHB gastcollege

Afgelopen vrijdag gaven we een gastcollege aan de Erasmus hogeschool Brussel. Het was een boeiende en leerrijke wisselwerking over hoe een project op te starten, user story mapping, MVP’s , Miro en Atlassian … een hele brok knowledge sharing, waar theorie en praktijk elkaar ontmoeten. Dank aan onze collega’s Nico & Joren en dank aan EHB for having us 😊 it was fun! 

23 maart 2021

Crisp-DM: The Standard

CRISP-DM is the de facto standard for developing Data Mining (DM) & Knowledge Discovery (KD) projects and is thus also the most used methodology for these specific projects.
It arose after a group of prominent enterprises (Teradata, SPSS, …) analyzed the problems and obstructions that occurred during DM & KD projects. Subsequently, they proposed a reference guide to develop projects of this nature which then became CRISP-DM (CRoss Industry Standard Process for Data Mining). It is vendor-independent making it applicable to solve any DM related problem.


Six phases

CRISP-DM defines six phases that need to be carried out during a Data Mining project.


Business understanding: Understanding the project objectives & requirements from a business perspective and converting this knowledge into a DM problem definition and a preliminary plan to achieve these objectives.

Data understanding: discover first insights and detect interesting subsets to form hypotheses for hidden information.

Data preparation: Transform your data into a usable form. Contains all the activities required to construct the final dataset from the initial raw data. If you proceed to the next phase without proper data preparation, your results will never attain the aspired results (garbage in, garbage out).

Modeling: Select and apply various modeling techniques on your data set. During this phase, you usually take a step back to the data preparation phase because some techniques have specific requirements on the form of data.

Evaluation: Evaluate the results of your model thoroughly and review the steps taken to build it to be certain that it properly achieves the business objectives which you defined in phase one.

Deployment: Deploy the model effectively, automate it, plug it into business processes and discuss it with the people that will be using it.


Room for improvement

However, the CRISP-DM model still has room for improvement. Other models based on CRISP-DM propose alternative/additional phases like the Automate phase which focuses on generating a tool to help non-experts in the area to perform Data Mining & Knowledge Discovery tasks.

Another example of a phase that is not covered by CRISP-DM is the On-going support phase. It is very important to take this phase into account, as DM & KD projects require a support and maintenance phase. Maintenance can range from creating and maintaining backups of the data used in the project to the regular reconstruction of DM models. This is because the DM models may change whenever new data emerges, which may in turn cause them to be less applicable.

Nonetheless, changes like these (e.g. adding, renaming or eliminating phases) are being considered for the new version (CRISP-DM 2.0).



After comparing this process model to others (especially Software Engineering process models) the conclusion can be made that CRISP-DM does not cover many project management-, organization and quality-related tasks at all or at least not thoroughly enough. In the present day, this has become a must due to how complex projects have become.
Data Mining projects have become more, as they now not only encounter huge streams of data but also require managing and organizing big collaborating teams.

It remains to be seen if a DM engineering process model can be put together that covers the obstacles mentioned above in combination with CRISP-DM in order to adapt it to the most recent DM and KD processes.


Lode Wouters

15 januari 2020

LipDub Team Weekend Konato

Het teamweekend van Abano, Konato en BIQ was weer super! Tijdens de teambuilding maakten we samen een LipDub Music video!

18 oktober 2019

Procesanalyse: een vak apart!

Wat is een bedrijfsproces?

Een proces is het best te omschrijven als een serie van activiteiten uitgevoerd door mensen of machines, waarbij verschillende middelen nodig zijn. Deze activiteiten worden op hun beurt ondersteunt door informatie en communicatie.

Over verschillende teams of afdelingen heen, zorgen bedrijfsprocessen voor een standvastige structuur (standaardisatie) met als doel een optimaal eindresultaat (kwaliteit) voor de eindklant te bekomen.

Wat we als consultant regelmatig bij bedrijven opmerken, is dat er gedacht wordt in taken binnen bepaalde teams of afdelingen. Desbetreffende teams hebben minimaal weet van hun rol in het bedrijfsproces en hun bijdrage aan het eindresultaat. Indien er enkel gekeken wordt vanuit de bril van eigen handelen, is dit een beperkende factor en kan dit een valkuil zijn voor de organisatie.


Een procesbeschrijving

Om dit gegeven op te vangen, is het belangrijk om bedrijfsprocessen in kaart te brengen over de verschillende teams of afdelingen heen. Niet alleen creëert dit een betrokkenheid bij de verschillende teams, ook is het direct zichtbaar waar er eventueel gaten of overlappingen in het proces zijn.

Een procesbeschrijving is geen proces aan zich, maar geeft wel duidelijk inzicht in de organisatie. Deze blueprint zorgt ervoor dat iedereen weet, wat – wie – waarom – waarmee en wanneer men iets moet doen.

Wat er gedaan moet worden vormt de kern van een procesbeschrijving. Vervolgens is het  duidelijk van elke actie of beslissing wie (welke team) deze uitvoert en wie (welk team) verantwoordelijk is. De noden van de verschillende teams zullen zichtbaar zijn en daarmee ook de doelstellingen van de organisatie.

Kortom, in een procesbeschrijving wordt er duidelijk in kaart gebracht wat er nodig is bij het uitvoeren van de processen, processtappen, acties en het nemen van beslissingen. Niet te vergeten dat er naast de input ook vaak andere (hulp)middelen gebruikt worden bij het proces, zoals ondersteunende informatiesystemen, documenten en dossiers. Soms is het zelfs zo dat een proces is al dan niet afhankelijk is van een incidentele aanleiding ( trigger ).


Hoe breng ik een bedrijfsproces in kaart?

Een proces in kaart brengen zonder dat je er zelf iets van kent is natuurlijk geen goed idee.

Als eerste stap om kennis te vergaren is een individuele bevraging van de verschillende betrokken teams aanbevolen. De vraagstelling kan het best specifiek gericht zijn naar handelingen. Zo is het mogelijk om concreet in kaart te brengen welk aandeel desbetreffende team in het proces heeft. Zo vermijden we in valkuilen te vallen zoals: te veel in details verzeild te geraken, frustraties,…

Vervolgens is het mogelijk een eerste verwerking van de verkregen informatie uit te voeren. Het proces over de verschillende teams heen wordt aan elkaar gelinkt zodat we uiteindelijk een draft proces bekomen. Het draft proces fungeert als een ‘kapstok’, die de basis zal zijn voor de interactieve workshop. Door het draft proces reeds te analyseren en visualiseren, worden de linken tussen teams maar ook de gaten en dubbele acties zichtbaar.

De volgende stap is het bekomen draft proces af te toetsen met de realiteit. Een interactieve workshop waar er een afgevaardigde van ieder team op uitgenodigd is, kan dienen als een goed communicatie platform. De teams worden uitgenodigd om het proces aan te vullen vanuit hun expertise met als doel het proces uiteindelijk te finaliseren.

Het is noodzakelijk om tijdens de workshop een buy-in te creëren. De teams die namelijk betrokken zijn bij de proces analyse zullen meer gemotiveerd zijn om het uiteindelijke finale proces uit te voeren tegen over de teams die het proces opgelegd krijgen. Omdat de schematische procesverwerking in BPMN vaak een moeilijk gegeven is voor leken, is het handig om het proces meer visueel, praktischer en behapbaar te maken. Vaak is creativiteit hier de sleutel tot succes. In de foto zie je zo een bijvoorbeeld.  In het proces wordt elk team vertegenwoordigd door een lego mannetje en de proces stappen worden hier visueel aangegeven.

Door samen het proces te analyseren, ontdekken we vereenvoudigingen, hoe we gaten kunnen opvullen en dubbels elimineren. We kunnen stellen dat hier regelmatig bijkomende acties uitvloeien of zelfs projecten. Het finale proces over de verschillende teams heen kan best gedocumenteerd worden (eventueel in een proceshandboek) en uitgeschreven in BPMN. Na een goedkeuring door het management kan dit proces gecommuniceerd en opgevolgd worden binnen de organisatie.

Procesbeheersing is iets is waar alle betrokken teams van een proces elke dag mee bezig zijn. Het gaat om verantwoordelijkheden, openheid en standaardisatie. Procesbeheersing leidt tot grip op processen en hiermee tot grip op de organisatie en de kwaliteit.

Marianne Van Strydonck

27 augustus 2019

DNA van het ideale project!

Ideaal bestaat niet…

Ideaal is een synoniem van perfect. En van perfectionisme weten we al lang dat het niet bestaat. Dus een ideaal project = een perfect project = onbestaand?

Als we echt eerlijk zijn, is er in elk project wel iets dat soms een beetje en soms, veel beter kan. Laten we er dus vanuit gaan dat het perfecte project niet bestaat. Sommige projecten komen echter zo dicht in de buurt dat het wel heel erg lijkt op perfectie. Andere projecten, wel … die komen (n)ergens in de buurt.


Maar waarom lopen sommige projecten beter dan andere?

Je kan er niet altijd de vinger opleggen waarom een project fout loopt. Regelmatig merken we dat de methodologie kop van jut is. De verkeerde aanpak voor dit soort projecten en dat is soms een zeer geldige reden. In sommige omgevingen gedijt agile net iets beter dan in andere.

Maar er kan net zo goed een andere reden zijn waarom een project beter loopt dan een ander. Er is echter één reden dat er voor zorgt dat projecten altijd een stuk aangenamer en vlotter verlopen. Verschillende projecten, verschillende omgevingen en methodologieën en zelfs verschillende industrieën en toch is er een gemeenschappelijke factor. Wat die factor is kom je hieronder te weten…


Zonder “de ziel” kan je project niet overleven!

Wat is dat nu, de ziel van je project? Dat is voor mij het team. Zonder team heeft je project geen kans. En daarom is dat team nu net dé bepalende factor die zo belangrijk is voor het slagen van je project.

Definitie: “Een team is een groep van mensen die meer presteren dan de som van de individuen.”


Wat heb je nodig om een team te vormen?

Een team krijg je niet zomaar, daar moet aan gesleuteld worden, zowel door de projectmanager als door de teamleden zelf.



Voor mij is vertrouwen de basis van een team. Als je als projectmanager vertrouwen geeft aan jouw team en de teamleden geven elkaar vertrouwen, dan is de basis gelegd. Belangrijk hier is dat vertrouwen het tegenovergestelde is van controle. Geef je teamleden van in het begin vertrouwen. Dit vertrouwen kan alleen geschaad worden door de acties van het teamlid zelf.



In een team waar er sprake is van vertrouwen is geen plaats voor ego’s. Het team gaat samen voor hetzelfde doel. Iedereen kent wel de stelling: ‘There is no I in team’. Dat is een stelling waar ik 100% achter sta. Hoe waar dit ook is, het is niet altijd eenvoudig voor elk teamlid om dit ego los te laten. Er is trouwens ook geen plaats voor het ego van de projectmanager. De functie van de projectmanager is het team faciliteren zodat ze niet afgeleid worden door administratieve of andere zaken. Als projectmanager sta jij ten dienste van het team, niet andersom. Dat is iets wat het team heel snel doorheeft.


Veilige omgeving

Het team moet in een veilige omgeving kunnen functioneren. Dat betekent concreet dat het team of de individuele leden nooit mogen afgerekend of beïnvloed worden door stakeholders buiten het team. Daar moet jij als projectmanager je rol spelen en het team afschermen. Het team afschermen en een veilige omgeving bieden is één van de allerbelangrijkste taken die je als projectmanager hebt.



Je ziet dat in deze punten de methodologie niet naar boven komt. Dat wil niet zeggen dat een methodologie in het project niet belangrijk is. Integendeel, het is juist heel belangrijk, maar ook weer totaal irrelevant als de vorige drie punten niet in orde zijn. Wat de methodologie toevoegt, is een houvast, structuur en overzicht. En ook daar heb ik veel projecten zien fout lopen, omdat het team te weinig structuur heeft, niet weet waar het project naartoe gaat en geen overzicht heeft van wat er te doen staat.

Zeker in een iteratieve omgeving ligt de focus vaak op waar op dat moment aan gewerkt wordt. Het is echter belangrijk dat ook dan het overzicht in beeld blijft. Daar komt de methodologie die je gebruikt van pas. Of dit nu eerder waterval is of eerder agile, dat is echt niet belangrijk. Ik heb de magie van een team al in beide omgevingen gezien.


Ga voor een vlotte teamwerking

Alle andere aspecten van projectmanagement waar we het hier niet over gehad hebben, zijn alleen maar belangrijk als je een team hebt. Ze worden echt leuk op het moment dat je team ook echt als een team gaat functioneren.

En jij als projectmanager plukt daarvan mee de vruchten. Jij kan dan over meer vooruitgang rapporteren. Je business zal tevreden zijn, het management zal tevreden zijn en jij kan elke avond naar huis gaan met een gerust gemoed.

Het is dus zeker niet overdreven om te zeggen dat je team het goud is in je project.


… En van zodra die groep van individuen begint te functioneren als een team, gebeurt er iets heel mooi in je project.


Peter Willekens

19 augustus 2019

Konato VIP Summer Event

Op vrijdag 21 juni kwamen we met het team samen voor een uitgebreide knowledge sharing rond de verschillende methodologieën, rollen en verantwoordelijkheden in IT Project management. We kregen interessante lezingen rond PMI, Prince2, SAFe, Spotify Model, PMO, etc. Er werden ervaringen gedeeld over hoe deze methodologieën vanuit de theorie werden vertaald naar de praktijk.

Achteraf kwamen we samen met onze zusterbedrijven Abano en BIQ op het festival Denderpop. Met een echte VIP behandeling hebben we de zomer goed ingezet. Bedankt aan alle collega’s om er weer een top feest van te maken.

Bedankt collega’s! Hieronder vinden jullie alvast nog een paar sfeerbeelden.




21 juni 2019

DevOps: een paar belangrijke lessen

Sinds het begin van dit decennium is DevOps voor velen geëvolueerd van een hol buzzword naar een effectieve implementatie van een betere samenwerking tussen development en operations. Aangezien meerdere organisaties dit principe beginnen op te pikken, geven we enkel belangerijke ‘key takeaways’ mee:


DevOps draait om meer dan louter een snelle pijplijn om code in productie te krijgen.

Alhoewel een snelle time to market van nieuwe functionaliteit zeker een kernonderdeel van DevOps kan genoemd worden, speelt de menselijke aanpak een nog belangrijkere rol. Werknemers van beide afdelingen die elkaar met gelijkheid behandelen en openstaan voor samenwerking, vormen de kernwaarden van DevOps. Waar ruimte is voor discussie en directe communicatie, versterkt de samenwerking tussen beide partijen zodat ze meer als één team beschouwd kunnen worden.


Waar Agile methodologieën de afstand tussen IT en business proberen overbruggen, tracht DevOps dit te doen tussen development en operations.

In oudere denkpatronen zijn de verantwoordelijkheden van deze afdelingen sterk gescheiden. De ontwikkelaars schrijven de software. Wanneer deze klaar is, is het aan de systeembeheerders om de software aan de praat te krijgen en te houden. Aangezien continuous integration en continuous delivery meer en meer hun waarde tonen in het opleveren van software, wordt samenwerken alsmaar belangrijker. Deze samenwerking mag echter niet gezien worden als een noodzakelijk kwaad, maar moet zoveel mogelijk omarmd en uitgespeeld worden.


De vier pijlers van DevOps zijn allen even belangrijk om het volledige concept in evenwicht te houden

  1. Collaboration

DevOps gaat in eerste instantie over mensen te laten samenwerken. Dit kan verschillende vormen aannemen zoals code reviews houden, documentatie schrijven, aan pair programming doen, … Binnen het DevOps team willen we een zogenaamde blameless culture kweken, waarbij in eerste instantie wordt onderzocht wát er is fout gelopen en niet door wíe.

  1. Affinity

Deze pijler is vergelijkbaar met collaboration, maar dan op teamniveau. Er doen vaak een aantal vooroordelen de ronde die ervoor zorgen dat teams niet goed kunnen samenwerken, zoals het gevoel dat sommige teams belangrijker zijn dan andere.

  1. Tools

Tools kunnen de samenwerking bevorderen, maar het is belangrijk om in te zien dat deze een middel zijn en geen doel op zich. Indien men een DevOps tool aanwendt (Chef, Ansible, …), wil dit niet per sé zeggen dat men aan DevOps doet. Het is belangrijker hoe men een tool toepast dan welke tool men gebruikt.

  1. Scaling

Bedrijven moeten in hun achterhoofd houden dat ze blijven evolueren. Dit kan zowel groei als inkrimping betekenen waarmee de organisatie rekening moet houden (bij het uittekenen van teams, informele processen, …).

Het is niet altijd even evident om DevOps te introduceren bij cliënten of op projecten. Hieronder enkele valkuilen die een implementatie verhinderen of bemoeilijken:


Uiterlijke schijn

Wat we op het werkveld vaak zien is dat bedrijven een werkwijze of methodologie proberen aanmeten door de uiterlijke kenmerken ervan na te bootsen. Zo zijn er organisaties die afgebakende ontwikkelperiodes sprints noemen, ’s ochtends rechtopstaand vergaderen en hierdoor menen aan Scrum te doen. Niets is uiteraard minder waar. Net zoals bij agile methodologieën, is er bij DevOps vooral nood aan een mentaliteitswijziging. Enkele zicthbare trekjes overnemen volstaat niet.


Aparte teams

Het oprichten van een apart DevOps team kan logisch lijken, maar is in feite een contradictio in terminis. Hoe willen we namelijk een betere samenwerking tussen teams realiseren door nog een extra team op te richten? En nee, het volstaat niet om een andere naam voor dit team te verzinnen…


DevOps is geen methodologie of framework

DevOps blijft een behoorlijk abstract gegeven. Er is nog wel wat werk om de processen te formalizeren. Formele processen zouden kunnen helpen bij het opzetten van een omgeving die conform is aan de kernwaarden. Er zijn momenteel nog weinig concrete implementatiemiddelen waartoe iemand zich kan wenden als hij of zij DevOps wenst te gebruiken. Veel bronnen geraken helaas niet verder dan dat DevOps voor goed samenwerken staat. Het is dan ook sterk afhankelijk van hoe je omgeving eruit ziet waarin je DevOps wil gaan toepassen.


Conclusie, DevOps verandert fundamenteel de samenwerking van vandaag tussen Dev en Ops. Er zijn nieuwe skills voor nodig, nieuwe tools en nieuwe prioriteiten. Het is een continu proces dat tijd in beslag neemt en een nieuw perspectief over samenwerken vereist.

13 mei 2019