STAGERAPPORT

Jana Vieren

Delaware

Juli 2019

Tine Claeys

Faculteit Economie en Bedrijfskunde

Master Business Engineering
Operations Management

Academiejaar 2019-2020
 Inhoudsopgave

1. Voorwoord.....................................................................................................................................3
2. Van situering naar onderzoeksvraag..............................................................................................4
2.1 Situering.......................................................................................................................................4
2.2 Doelstellingen stagerapport en centrale onderzoeksvraag..........................................................5
3. Het theoretisch kader.....................................................................................................................6
3.1 Low-code platformen...................................................................................................................6
3.2 Kenmerken en voordelen van low-code.......................................................................................6
3.3 Mogelijke valkuilen.......................................................................................................................7
4. Toepassen van het theoretisch kader.............................................................................................8
4.1 Het voorbereidend werk..............................................................................................................8
4.2 De componenten van Opentext Appworks...................................................................................9
4.3 The overall picture......................................................................................................................10
4.4 The customer experience...........................................................................................................11
4.5 De veiligheid...............................................................................................................................11
5. Conclusie......................................................................................................................................12
6. Zelfreflectie..................................................................................................................................13
7. Bronnen........................................................................................................................................14
8. Bijlagen.........................................................................................................................................15
 1. Voorwoord

In dit stagerapport zal ik eerst een situering geven van mijn opdracht binnen het bedrijf
Delaware. Uit deze situering volgt dan mijn centrale onderzoeksvraag. In het tweede punt zal
ik het theoretisch kader bespreken die betrekking heeft tot mijn opdracht. Dit theoretisch
kader zal ik dan gebruiken om mijn centrale onderzoeksvraag uit te werken. In het derde
punt zal ik de onderzoeksvraag beantwoorden uit mijn eigen ervaring met een
terugkoppeling naar het theoretisch kader. Hieruit volgt dan ook een conclusie. Tenslotte zal
ik dit rapport beëindigen met een zelfreflectie.

In Delaware kreeg ik 4 weken lang de kans om nieuwe terminologie te leren, mijzelf te

verdiepen en te bewijzen, m.a.w. om met het echte bedrijfsleven in contact te komen. Dit
werd mede mogelijk gemaakt door de behulpzame collega’s die zorgden voor een sfeervolle
werkomgeving.

Mijn dank gaat speciaal uit naar meneer Maes, mijn stagebegeleider, die mij doorheen die 4
weken dagelijks heeft begeleid. Hij zorgde ervoor dat ik telkens weer op het goede pad
terecht kwam als ik door de bomen het bos niet meer zag. Hij leerde mij de kneepjes van het
vak en probeerde mij ook zoveel mogelijk te betrekken bij het team. Hij benadrukte ook altijd
wat goed was. Dit gaf mijn zelfvertrouwen een enorme boost. Daarnaast wil ik zeker ook
meneer Peeters bedanken. Voor vragen en tips kon ik altijd bij hem terecht.

Tenslotte wil ik ook graag meneer Mens bedanken uit Delaware Nederland. Hij is
gespecialiseerd in AppWorks, het digitaliseringsplatform dat ik dagelijks gebruikte om mijn
opdracht uit te voeren. Ook bij hem kon ik altijd terecht met mijn vragen.
 2. Van situering naar onderzoeksvraag

2.1 Situering

Delaware wordt het best samengevat door de beschrijving die terug te vinden is op hun
website: “We zijn een internationale organisatie die geavanceerde ICT-oplossingen en
diensten levert, om onze klanten te ondersteunen in hun zakelijke en digitale transformaties”
(Delaware, 2019). Delaware is een consultancy bedrijf die hun klanten begeleidt in het
digitaliseren en automatiseren van bedrijfsprocessen en het beter beheren van informatie.
Op basis van de nieuwste technologieën wordt er gestreefd naar het creëren van
oplossingen zodat hun klanten steeds intelligentere organisaties worden. Delaware berust
hierbij op haar diepe ervaring met systemen zoals SAP, Microsoft Dynamics, SharePoint,
Office 365, Salesforce en OpenText.

In haar 24 vestigingen verspreid over Europa, het Midden-Oosten, Azië en Amerika stelt
Delaware ruim 2500 professionals tewerk. Haar honinggraatstructuur bestaat uit 8
verschillende domeinen namelijk Finance & Business Controlling, Human Capital, Customer
Obsessed, Support, Data & Analytics, GLocal Services, Connect Systems & People en
Operations (Delaware, persoonlijke communicatie, 2019). Een range van teams behoort tot
deze domeinen. Ik heb de kans gekregen om mij te vervoegen bij het Enterprise Information
Managementteam, dit team behoort tot het domein Operations. De consultants in mijn team
zijn gespecialiseerd in het vinden van oplossingen voor het optimale gebruik van informatie
binnen een bedrijf. Hierbij maken ze vooral gebruik van SAP, Java of OpenText.

Steeds meer bedrijven worden zich bewust van het belang van digitalisering. Het doel van
een bedrijf kan zijn de klantenbeleving te optimaliseren door bijvoorbeeld meer klanten
sneller en efficiënter te bedienen. Hierbij wordt digitalisering gebruikt in de marketing,
verkoop en klantenservice. Denk maar aan Amazon en Coolblue die geen fysieke winkel
hebben maar hun producten enkel verkopen via een e-shop. Digitalisering kan ook gebruikt
worden om interne documenten te automatiseren om bedrijfsprocessen efficiënter te laten
verlopen en zo de rendabiliteit van het bedrijf te verhogen. Mijn stageopdracht is ontstaan uit
de vraag van BelOrta, de grootste coöperatieve groente-en fruitveiling van België, om hun
auditproces te versnellen door hun audits te digitaliseren.

Toen ik tijdens mijn sollicitatieprocedure op gesprek kwam bij mijn stagementor vond ik de
opdracht heel boeiend. Mijn interesses liggen niet enkel in de afstudeerrichting Operations
Management maar ook in Data Analytics. Deze opdracht combineert beide
afstudeerrichtingen op een boeiende manier. Het doel van de opdracht, namelijk het
efficiënter maken van het auditproces van BelOrta, is duidelijk een onderdeel van Operations
Management. De eerste stap om dit doel te bereiken, het analyseren van de data, leunt dan
weer sterk aan bij de afstudeerrichting Data Analytics. Ze hadden mij warm gemaakt voor de
opdracht en ik was dan ook overtuigd van mijn beslissing om Delaware te kiezen als
stageplaats.

Mijn stagementor ging op zoek naar een platform waarop ik de opdracht makkelijk kon
uitvoeren in mijn beperkte stagelooptijd van 1 maand. Hierbij kwam hij op het idee om
gebruik te maken van een recent aangekochte software, namelijk Opentext Appworks, een
low-code platform. De laatste jaren gebruiken steeds meer consultancy bedrijven deze
platformen waarin grafische userinterfaces1 gebruikt worden om toepassingen te
configureren en waarbij programmeervaardigheden geen must zijn. Deze platformen werden
geïntroduceerd op de markt met als doel dat niet enkel programmeurs kunnen bijdragen aan
de ontwikkeling, maar ook mensen met een beperkte ervaring in IT.

Aangezien deze software recent werd aangekocht, was het van groot belang om een
dergelijk onderzoek te voeren naar de nieuwe technologie. De documentatie over het gebruik
van Appworks is eerder gelimiteerd, maar door de openhartigheid en behulpzaamheid van
de werknemers in Delaware heb ik vaak kunnen berusten op hun inzichten in low-code
development. Op het einde van elke werkdag werd een meeting georganiseerd met mijn
stagebegeleiders. Hierdoor volgden zij mijn werk goed op en kon ik altijd met mijn
moeilijkheden bij hun terecht. Ook mijn theoretische kennis leverde hun nieuwe inzichten op.
Vaak kreeg ik dan ook het compliment dat mijn kennis verrijkend was voor hun.

Mijn opdracht bestond uit twee luiken. Het eerste luik was het digitaliseren van audits voor
BelOrta door hun data te verzamelen en structureren, het ontwikkelen van user face
diagrammen en het effectief bouwen van de applicatie in Appworks. Zoals eerder vermeld
bestond het tweede luik uit onderzoek naar de nieuwe software met als doel de beperkingen
en opportuniteiten van de software te documenteren en deze beschikbaar te stellen voor het
bedrijf.

2.2 Doelstellingen stagerapport en centrale onderzoeksvraag

Het gebruik van low-code platformen is een trend die nog maar recent is ontstaan. Voordien
werd er bij digitalisering hoofdzakelijk gebruik gemaakt van traditionele programmeertalen.
Tijdens mijn opleiding Handelsingenieur aan de Universiteit Gent leerde ik in mijn tweede
bachelor programmeren met Java, een traditionele programmeertaal. Ik ontwikkelde mijn
programmeervaardigheden verder tijdens het vak Beleidsinformatica van Geert Poels, maar
stond nog nooit eerder in contact met deze opkomende platformen.

Het doel van mijn stagerapport is om na te gaan wat low-code applicatieontwikkeling precies
is en hoe low-code development verschilt van standaard softwareontwikkeling.

Hierbij onderzoek ik wat de huidige voordelen en valkuilen van low-code platformen zijn in
vergelijking met de traditionele programmeertalen voor de ontwikkelaars van de applicaties.
Hiermee wil ik graag misconcepties over deze nieuwe platformen ontkrachten en mensen
bijleren over deze nieuwste trend. De onderzoeksvraag zal worden beantwoord door de
gelijkenissen en verschillen te onderzoeken waarmee ik tijdens mijn stage geconfronteerd
werd. Hierbij vertrek ik eerst en vooral uit een literatuurstudie die een theoretisch kader
oplevert. Daarna zal ik mijn onderzoeksvraag uitwerken door mijn ervaringen te delen,
gebruikmakend van het voorafgaande theoretische kader.

1
“Een grafische user interface; een user interface is de manier waarop de gebruiker met een computersysteem
communiceert. Bij de grafische user interface communiceert de gebruiker met behulp van de muis en
aanklikbare iconen.” (Encyclo.nl, 2019).
 3. Het theoretisch kader

3.1 Low-code platformen

Alhoewel het concept al meerdere jaren bestond, werd de term “low-code development” pas
op 9 juni 2014 toegekend door de sectoranalist Forrester Research. Low-code development
wordt uitgevoerd op low-code development platforms. Deze low-code platformen vinden hun
roots terug in de jaren 90. In 2011 begon de markt voor deze platformen te groeien. Volgens
het Amerikaans onderzoeksbureau gebruiken steeds meer bedrijven low-code platformen
om de klant sneller te voorzien van de gewenste applicatie. Deze platforms zijn gericht op
het ontwerp en de ontwikkeling van databases, bedrijfsprocessen of gebruikersinterfaces
zoals web- of mobiele applicaties.

IT-bedrijven kunnen de digitale transformaties nauwelijks bijbenen. De laatste jaren zijn het
aantal IT-bedrijven op de markt enorm toegenomen en bijgevolg ook de concurrentie. De
vraag naar digitale transformaties neemt enorm toe waardoor bedrijven zo snel mogelijk een
oplossing willen bieden voor hun klanten. Low-code platformen zijn in het leven geroepen
met als doel een snelle levering mogelijk te maken van businessapplicaties door code te
minimaliseren. Deze platformen gebruiken een alternatieve benadering van ontwikkeling,
namelijk visuele modellering in plaats van codering. De bedoeling van deze platformen is om
de hoeveelheid code dat moet geschreven worden om een applicatie te ontwikkelen terug te
schroeven, vandaar de benaming “low-code”. Eenvoudige applicaties kunnen bijna volledig
worden opgebouwd zonder codering, maar de mogelijkheid bestaat om code toe te voegen.

Concreet komt het erop neer dat de ontwikkelaar een grafische interface te zien krijgt en
a.d.h.v. drag-and-drop tools2 applicaties kan bouwen. Op deze manier kan je als consultant
sneller klantklare applicaties maken en zo een meerwaarde bieden aan het bedrijf in kwestie.

3.2 Kenmerken en voordelen van low-code platformen

Het voorbereidend werk die moet worden uitgevoerd is bij elke software gelijkaardig, of we
nu werken met low-code of traditionele software. Data wordt gestructureerd met behulp van
een ER-diagram. Eens het ER-diagram is opgesteld kunnen we visueel de gebruikseisen
van de applicatie gaan voorstellen aan de hand van een usecasediagram. Graag wil ik hier
de nadruk leggen op het feit dat het maken van zowel een ER-diagram als een
usecasediagram voorbereidend werk is en dus niet in de ontwikkelingssoftware wordt
gemaakt. Beide concepten worden verder toegelicht in puntje 4.

Richardson & Rymer (2016) stellen dat deze platformen enkel ontworpen zijn voor
zogenaamde burgerontwikkelaars en niet voor professionele ontwikkelaars doordat de
platformen het schrijven van code elimineren. Deze platforms worden aangedreven door
logica zelf en maken gebruik van declaratieve hulpmiddelen. Hierdoor kan de productiviteit
2
Drag-and-drop tools zijn componenten die het platform ter beschikking stelt van de ontwikkelaar. Bij low-code
platformen komt het erop neer dat de gewenste functies/componenten gewoon sleept naar waar je ze precies
wenst in de applicatie. Achter deze functies zit er al een code dus hoeft de ontwikkelaar van de applicatie ze
niet meer zelf te programmeren. Bijvoorbeeld het slepen van een kalender, Google Maps… Bij het toepassen
van het theoretisch kader zal het gebruik van low-code platformen duidelijker worden.
van de professionele ontwikkelaars verhoogd worden. Ze kunnen nu meer worden ingezet
voor meer technische taken zoals beveiliging, het uitvoeren van platformupgrades en het
bouwen van grootschalige applicaties. Nu kan ook de gewone burgerontwikkelaar met weinig
of geen ervaring in programmeren, bijdragen tot softwareontwikkeling. (Rymer, 2018)

Doordat er weinig tot niet hoeft gecodeerd te worden, is de leveringstijd van de applicatie ook
korter. Aangezien alles visueel wordt voorgesteld, heeft de klant de mogelijkheid om
feedback te geven in de vroege fases van ontwikkeling. Hierdoor kunnen beide partijen hun
ideeën uitwisselen en heeft de klant meer het gevoel van betrokken te zijn bij het project.
Indien de klant graag zaken anders had gezien, kan hij/zij dus in de vroege testfases van de
applicatie inpikken. Bij het gebruik van traditionele software moet de code zo goed als af zijn
vooraleer de applicatie kan worden voorgesteld aan de klant. Als dit niet voldoet aan de
wensen, verliezen ook ontwikkelaars hier veel tijd door code aan te passen. (Van Schetsen,
2016)

Volgens De & Jones (2015) is één van de voordelen van low-code platformen de veiligheid.
Op de meeste platforms is het mogelijk om aan te duiden welke gebruikers bepaalde data al
dan niet mogen zien. De gebruikersrechten kunnen door een beheerder worden ingesteld.

Een andere grote troef die deze platformen hebben is de capabiliteit om de applicatie ook op
je smartphone te raadplegen ook al werd deze initieel ontwikkeld op een computer. De
applicatie past zich vanzelf aan, afhankelijk van het apparaat waarop deze wordt uitgevoerd.
Dit is een groot voordeel t.o.v. traditionele programmeertalen die meestal niet in staat zijn om
de gebouwde applicatie ook op andere apparaten te raadplegen. (Nepal, 2018)

3.3 Mogelijke valkuilen

Alhoewel low-code ontwikkelingsplatformen zeer populair zijn, hebben er ook veel hun
bedenkingen bij. De meningen zijn uiteenlopend. Reselman (2018) is ervan overtuigd dat als
de ontwikkelaars niet over genoeg programmeervaardigheden beschikken, het niet uitmaakt
welke softwarepakket je gebruikt. Het project zal gegarandeerd falen. Volgens hem is het
nodig dat iedereen die deelneemt aan zo’n project de basis van programmeren onder de
knie heeft en de code achter de functionaliteiten die de software aanbiedt verstaat.

Volgens De & Sam (2015) werkt een low-code platform volgens het black box principe. De
platformen elimineren de hoeveelheid code die moet geschreven worden eigenlijk niet maar
ze verstoppen deze achter de componenten waarmee de burgerontwikkelaars werken. Er
moet sowieso gecodeerd worden. Codeert de burgerontwikkelaar niet tijdens het ontwikkelen
van de applicatie, dan zijn het de professionele ontwikkelaars die de componenten die zij
gebruiken hebben gecodeerd. Ze argumenteren dan ook dat je geen tijd wint door met deze
platformen te werken omdat er aan de basis van de software nog steeds moet worden
geprogrammeerd.
 4. Toepassen van het theoretisch kader

4.1 Het voorbereidend werk

Wanneer bedrijven digitalisering willen doorvoeren, voorzien zij het consultancy bedrijf van
ongestructureerde data. BelOrta bezorgde Delaware een auditdocument dat gebruikt werd
om de hygiëne te controleren in hun verschillende departementen. Hun wens was om hun
auditdocumenten te digitaliseren zodanig dat iedereen die betrokken was in een bepaald
auditproces de documenten digitaal kon raadplegen en bewerken op een smartphone, tablet
of computer. De eerste pagina van dit auditdocument is te zien in figuur 1. Hier is de data
niet helemaal ongeordend omdat Delaware eigenlijk al een PDF van het auditdocument
ontving en niet gewoon een Excel bestand met ongeordende gegevens. Hierdoor had ik ook
sneller een idee van hoe de schermen op de applicatie er zouden uitzien. Toch was het
belangrijk om elk vakje tekst op het document goed te verstaan. Noodzakelijk is ook om te
weten wie er precies betrokken is bij de auditprocedure en wie dus allemaal het
auditdocument mag bewerken en raadplegen. Samen met mijn begeleider hebben we het
document grondig doorgenomen en een betekenis gegeven aan alle data. Sommige data
was niet helemaal duidelijk. Hier hebben we de hulp van BelOrta ingeschakeld. Een
voorbeeld daarvan is de code “F-KZS-CPM-01-02” onderaan op figuur 1. Ik had geen idee
waarvoor deze code stond en alleen BelOrta’s auditdepartement kon mijn vraag
beantwoorden. Deze ID staat voor een combinatie van de soort controle, de plaats waar
deze wordt uitgevoerd en de versie van het document. Deze informatie was belangrijk voor
mij om mijn applicatie op te bouwen aangezien BelOrta de wens heeft dat deze ID
automatisch wordt gegenereerd eens de auditor het document invult. Dit betekent dat,
afhankelijk van de soort controlelijst, de versie en de plaats waar de controle wordt
uitgevoerd, er een unieke code op het formulier moet verschijnen.

Eens ik alle data verstond kon ik deze gestructureerd weergeven in een ER-diagram (ook
gekend als entiteit-relatie diagram). Dit concept was niet nieuw voor mij, tijdens het vak
Beleidsinformatica3 hebben we zelf een database moeten opstellen aan de hand van een
ER-diagram. Een ER-diagram bestaat uit symbolen en connectoren die 2 belangrijke soorten
informatie weergeven: de belangrijkste entiteiten binnen het systeembereik en de relaties
tussen deze entiteiten. Elke entiteit bestaat uit 1 of meerdere attributen en heeft een primaire
sleutel. De attributen zijn de kenmerken van de entiteit. Eén van die attributen moet uniek
zijn, deze is dan de primaire sleutel van de entiteit. De relaties tussen deze entiteiten worden
weergegeven door pijlen. Het type pijlen bepalen het type relatie. De meeste voorkomende
relatie is een één-op-veel relatie, hier wordt één record in een tabel gekoppeld aan één of
meerdere records van een andere tabel. In bijlage figuur 2 is mijn initieel ER-model te zien.
Alle data die ik geïdentificeerd heb is weergegeven in dit model. De ID combinatie is terug te
vinden in de entiteit ‘Report’ als primaire sleutel. Elk rapport dat aangemaakt wordt genereert
een unieke ‘ReportID’. Geen enkel rapport zal ooit dezelfde ID hebben aangezien er steeds
recentere versies zullen worden aangemaakt. Elk rapport bestaat uit 1 of meerdere audits,
maar elke audit behoort tot juist 1 rapport. Dit is een voorbeeld van een één-op-veel relatie.
In het ER-diagram wordt ook een speciale relatie weergegeven: de ‘parent-child’ relatie. Elk
rapport bestaat uit meerdere ‘Reportchecks’, dit zijn de categorieën ‘ALGEMEEN’,
‘AFVALBEHEER’, ‘ROOKVERBOD’… terug te vinden in figuur 1. De categorieën moeten
3
Beleidsinformatica werd gedoceerd door professor Poels in de derde Bachelor
beoordeeld worden op de datum dat de audit uitgevoerd wordt. Een categorie kan bestaan
uit subcategorieën. De categorie ‘AFVALBEHEER’ bestaat namelijk uit 3 subcategorieën:
‘Scheiding afval’, ‘Lediging van de afvalbakken’ en ‘Reiniging van de afvalbakken’. Hier is de
hoofdcategorie ‘AFVALBEHEER’ de ouder in de relatie en de subcategorieën zijn de
kinderen. Alle categorieën, hoofd- of subcategorie, hebben de kenmerken/attributen van de
entiteit ‘ReportCheck’.

Het usecasediagram, weergegeven in figuur 3, is de grafische representatie van de

applicatie. Een usecasediagram weergeeft de scope en de gebruikseisen van het
systeem/applicatie die voor de klant zal worden ontwikkeld. Het helpt ons met het systeem te
ontwerpen vanuit het perspectief van BelOrta. Tijdens het vak Datagestuurde en robuuste
besliskunde leerde ik dat het belangrijk is om eerst een grafische presentatie weer te geven
van het systeem vooraleer te verdiepen in de software. Zo krijgen we een beeld van hoe de
applicatie zal werken en welke vereisten er nodig zijn om deze te ontwikkelen.

Het voorbereidend werk is helemaal hetzelfde als bij de traditionele programmeertaal Java.
Het grote verschil is dat een ER-diagram doorheen de opdracht nauwelijks verandert als je
met Java werkt. De reden hiervoor is dat je elke entiteit en functie die de applicatie moet
kunnen zelf programmeert. Tijdens de opdracht van BelOrta heb ik mijn ER-diagram moeten
minimaliseren tot figuur 4. Het resultaat is zeer simplistisch. De reden hiervoor is dat een
low-code platform anders werkt. Dit brengt mij dan ook bij het volgende puntje, mijn ervaring
met Appworks Opentext.

4.2 De componenten van Opentext Appworks

In Appworks werken we met ‘building blocks’. Dit zijn reeds geprogrammeerde

functionaliteiten die beschikbaar zijn op het platform. Aan de hand van deze building blocks
heb ik formulieren ontwikkeld die worden weergegeven in de applicatie. Elke entiteit uit figuur
4 representeert een formulier. Ter illustratie heb ik figuur 5 toegevoegd als voorbeeld van
een formulier die behoort tot de entiteit ‘Report’. Dit formulier moet worden ingevuld door de
supervisor en worden goedgekeurd vooraleer we een template verkrijgen die kan worden
gebruikt om de audit op uit te voeren.

Wanneer je programmeert met Java of andere traditionele software moeten alle stappen in
het proces gecodeerd worden. Een groot voordeel die ik ervaren heb door te werken met
Appworks, is de mogelijkheid om levenscyclussen te implementeren. In de applicatie zijn 2
levenscycli geïmplementeerd. De eerste levenscyclus heeft betrekking op het aanmaken van
een rapporttemplate en dus de entiteit ‘Report’. De tweede levenscyclus kan worden gestart
wanneer de eerste levenscyclus voltooid is en heeft betrekking op de uitvoering van de
controle en bijgevolg op de entiteit ‘Audit’. De eerste levenscyclus wordt weergegeven in
figuur 6. Om een rapporttemplate te bekomen, moet de template de stappen van de cyclus
voltooien en uiteindelijk de status ‘Approved’ krijgen. De supervisor vult de template in (figuur
5). Hierdoor verandert de status ‘Draft’ van het rapport naar ‘For Approval’. Nu is de template
klaar om door een approver te worden goedgekeurd. Indien de approver akkoord gaat met
de template wordt deze geaccepteerd en krijgt wordt de status ‘Approved’ toegekend. Als de
approver het niet eens is met de template, wordt deze teruggestuurd naar de supervisor en
krijgt deze opnieuw de status ’Draft’. De supervisor heeft nu de optie om de template aan te
passen. Eens dat gedaan is wordt de template weer voorgelegd aan de approver. Een
template met de status ‘Approved’ kan worden geraadpleegd door een auditor. Deze kan nu
gebruikt worden om de audit op uit te voeren. Dit wil eveneens zeggen dat de tweede
levenscyclus voor dat specifieke rapport van start kan gaan. Deze wordt weergegeven in
figuur 7 en spreekt voor zich. Deze zal ik dus niet verder uitleggen.

De building blocks in Appworks zijn zeer handig. Maar toch stootte ik soms op de
inflexibiliteit van het low-code platform. De building blocks die Appworks ter beschikking stelt
zijn zeer simplistisch. Een voorbeeld hiervan is de lijst met departementen waaruit de
supervisor kan kiezen wanneer hij een template aanmaakt. BelOrta heeft verschillende
vestigingen in België. Elke vestiging heeft verschillende departementen. Een wens van mij
was dan ook dat wanneer de supervisor een bepaalde vestiging koos op de template, de lijst
met de keuzemogelijkheden van departementen beperkt werd tot de departementen van die
vestiging. Dit was niet mogelijk in Appworks. Onmiddellijk dacht ik dan ook aan de
mogelijkheid om in Java gebruik te maken van zogenaamde HashMaps. Een HashMap laat
toe om meerdere gegevens te koppelen aan een object. Zo kun je departementen die
behoren tot éénzelfde locatie ook effectief aan die locatie koppelen. Als de vestiging dan
wordt opgehaald, kun je enkel de departementen zien die ertoe behoren. Dat Appworks die
functie niet aanbiedt lijkt geen grote beperking. BelOrta heeft dan ook maar 3 vestigingen.
Stel je nu even een internationaal bedrijf voor met meer dan 20 vestigingen in Europa die elk
uit 3 departementen bestaan. De supervisor van het bedrijf moet dan telkens kiezen uit 60
departementen. Daarbovenop laat de applicatie ook toe om foute combinaties van een
vestiging en departement te maken. Het toevoegen van extra code is dus wel noodzakelijk
als je aan de wensen van de klant wilt voldoen. De vereisten overtreffen vaak de
mogelijkheden van het platform. Verder had BelOrta de wens dat de auditor foto’s zou
kunnen uploaden tijdens het maken van de audit. Indien hij niet akkoord gaat met de orde en
netheid in de aanvoerloods zou hij zijn afkeuring kunnen versterken door een foto te
uploaden van het afval en de rommel in de loods. Opnieuw stootte ik hier weer tegen de
beperkingen van het platform. Appworks biedt ook deze functionaliteit niet aan.

Meerdere keren heb ik de gelimiteerde functionaliteit van het systeem ervaren. Bijgevolg
ontkracht ik dan ook de stelling van Richardson & Rymer die luidt dat deze platformen
ontworpen zijn voor burgerontwikkelaars. Indien je wilt voldoen aan de wensen van de klant
is het nodig code toe te voegen aan de componenten die het platform ter beschikking stelt.
Dit vergt uiteraard ervaring en een goeie basiskennis programmeren.

4.3 The overall picture

Klanten zijn de traditionele software gewoon waarin bijna alles mogelijk is. De stageopdracht
die ik kreeg werd uitgevoerd met een nieuwe software waardoor het vooraf moeilijk in te
schatten was of we aan de wensen van BelOrta konden voldoen. De documentatie was zeer
beperkt en niemand in het bedrijf had ervaring met Appworks.

Belangrijk tijdens een opdracht is dat je vooraf goed weet wat je wilt bereiken. Een besef van
de beperkingen en mogelijkheden van het gekozen platform is nooit eerder zo belangrijk
geweest. Uit ervaring weet ik dat de traditionele programmeertalen ongeveer allemaal
hetzelfde toelaten. Het zijn dan eerder de specifieke benodigdheden die ertoe leiden dat
programmeurs opteren voor een andere taal. Bijvoorbeeld als juist die ene programmeertaal
beter kan connecteren met een bepaald type database dan is de keuze snel gemaakt. Maar
wanneer je vergeet dat een bepaald platform de beperking heeft om foto’s te uploaden en
het besef komt pas wanneer je halverwege de opdracht zit, dan is het veel te laat en te
kostelijk om te veranderen van platform. Een goede kennis van alle mogelijkheden en
beperkingen van de low-code platformen in het bedrijf is dus een must.

4.4 The customer experience

Doordat ik gedurende de ontwikkeling van de applicatie het tussenresultaat kon tonen aan
de klant, stuurden zij bij waar nodig. Nadat ik het eerste formulier had getoond aan BelOrta,
vonden zij de compositie van de elementen op het formulier niet optimaal. Daarnaast hadden
ze ook graag het logo van BelOrta gezien op het formulier. Enkele minuten later was aan
hun wens dan ook voldaan. Het is dus zeker een feit dat door de visuele voorstelling van de
applicatie, de klant kan bijsturen in de vroege fasen van ontwikkeling. In Java moet het
volledige programma geschreven zijn vooraleer je de applicatie kan demonstreren. Als er
dan een aanpassing moet gebeuren aan de formulieren, moet je tussen alle code gaan
zoeken om dit weer aan te passen. Dit vraagt veel tijd.

Niet alleen de visuele representatie tijdens de ontwikkeling van de app, maar ook het feit dat
zowel je smartphone als tablet compatibel zijn met Appworks Opentext is voortreffelijk. De
auditapplicatie kan door iedereen die te maken heeft met het proces geraadpleegd worden
als ze verbonden zijn met wifi. Een systeem gemaakt door een traditionele programmeertaal
is enkel beschikbaar op een computer. Dit zou voor BelOrta niet zo’n grote meerwaarde
bieden als nu. De auditor is instaat om in een mum van tijd de audit uit te voeren op zijn
smartphone zonder dat hij notities hoeft te nemen om deze dan later in te vullen op zijn
computer.

4.5 De veiligheid

De security building block van Appworks heeft het grote voordeel dat je door enkele hokjes
aan te vinken bepaald wie een formulier al dan niet mag zien of invullen. De ontvanger van
de documenten mag niet in staat zijn om het rapport, ingevuld door de auditor, aan te
passen. Wanneer je in Java deze veiligheid wil garanderen dan moet er veel code
geschreven worden. De veiligheid is een voordeel maar hier moet zeer voorzichtig mee
worden omgegaan. Wanneer je je applicatie update of achteraf nog aanpast moet je
bijvoorbeeld goed letten op de instellingen van de beveiliging. Deze staan standaard niet
ingesteld waardoor ik soms uren heb zitten zoeken op het feit dat een bepaald element niet
tevoorschijn kwam op het formulier wanneer ik ingelogd was als supervisor of auditor. Dit
brengt ons ook onmiddellijk tot het belang van testen. Debuggen is zeker evenveel nodig als
bij de traditionele programmeertaal. Alhoewel componenten hun functionaliteiten hebben, is
het belangrijk om ook de samenhang van de componenten te testen. Dit kan een ander
resultaat geven dan je verwacht.

5. Conclusie
Door gebruik te maken van low-code ontwikkelingsplatformen kan Delaware meer
werknemers met kwalitatieve programmeervaardigheden inzetten voor complexere taken en
toepassingen zoals upgrades van de platformen of grootschalige toepassingen.
Burgerontwikkelaars kunnen gebruiken maken van low-code platformen bij toepassingen
waar geen complexe logica, hoog beveiligingsniveau of aangepaste functionaliteit nodig is.
Meestal bestaan business toepassingen van bedrijven uit complexe uitdagingen die de
basiscomponenten van een platform niet altijd kunnen ondersteunen. Daarbovenop zijn low-
code platformen nog volop in ontwikkeling en zolang dat het geval is, is het belangrijk om de
basisvaardigheden programmeren onder de knie te hebben.

Een voorwaarde hierbij is wel dat er een goeie documentatie beschikbaar is van de software
en dat bij het maken van elke opdracht ook de documentatie wordt aangevuld met de
beperkingen en opportuniteiten van het platform. De kwaliteit van deze platformen kan
hooggehouden worden door dagelijks te testen. Het is belangrijk voor Delaware om een
goeie kennis te hebben van de verschillende low-code platformen die zij ter beschikking
stellen van hun consultants. Enkel op deze manier zijn ze in staat om het juiste low-code
platformen in te zetten voor een bepaalde opdracht en zo kunnen consultants ook op
voorhand inschatten welke wensen van de klant al dan niet realiseerbaar zijn. Dit bespaart
tijd voor de consultant, kosten voor de klant en levert ook een waarde aan Delaware.

6. Zelfreflectie
Tijdens mijn opleiding Handelsingenieur ben ik erg benieuwd geworden naar de praktijk.
Deze stage heeft mij meer dan warm gemaakt om aan het werkleven te beginnen. Ik werd
onmiddellijk ondergedompeld in de leerrijke en motiverende bedrijfscultuur van Delaware
waarbij ik de kans kreeg om de bedrijfsrealiteit grondig te analyseren. Mijn takenpakket was
vooraf grondig afgelijnd waardoor ik op voorhand een goeie inschatting kon maken omtrent
de tijd die ik nodig had voor het voorbereidend werk en het effectief ontwikkelen van de
applicatie.

Het belangrijkste dat ik tijdens mijn stage heb geleerd is het zelfstandig te werk gaan en te
vertrouwen op mijn eigen kennis. Mijn begeleider gaf mij dagelijks feedback maar ook de
ruimte om mijn eigen ideeën te verwerken in de opdracht. Dit heeft mijn zelfvertrouwen een
enorme boost gegeven. Bij de aanvang van de stage was ik vaak onzeker over het werk dat
ik leverde. Vaak vroeg ik dan ook om instructies en hulp omdat ik niet overtuigd was van mijn
eigen kunnen. Dit heeft mijn stagebegeleider goed aangepakt door mij fouten te laten maken
en ook mij de tijd te geven om mijn eigen problemen eerst zelfstandig op te lossen. Naar
verloop van tijd was het ook duidelijk dat ik vaak zelf met goeie ideeën kwam en niet altijd de
hulp van buitenaf nodig had. Ze gaven mij complimenten over mijn creativiteit naar het
zoeken voor oplossingen.

Ik durfde ook vaker verschillende teamleden aanspreken als ik hulp nodig had. Door hun
ervaring waren ze voor mij een enorme meerwaarde. Hierbij merkte ik ook dat elke persoon
uit het team een andere visie heeft over hoe een bepaald probleem kan worden aangepakt.
Ik leerde dat het belangrijk is om aandacht te schenken aan deze visies aangezien ze mij
extra kennis en inzichten opleverden en vaak ook uit een ander perspectief. Later zal ik bij
de start van mijn nieuwe job mij vooral inzetten om een goeie band te scheppen met de
verschillende teamleden. Zij maken het werken zeer aangenaam en kunnen je altijd helpen
om tot een beter resultaat te komen. Verder was het leren werken met Opentext Appworks
een grote uitdaging voor mij. De software is nieuw in het bedrijf en hierin zijn vele
werknemers onervaren. Door te praten met verschillende teamleden ben ik bij meneer Mens
terecht gekomen. Meneer Mens werkt voor Delaware Nederland en heeft enorm veel
ervaring in deze software. Door af en toe te skypen met hem ben ik veel gevorderd in mijn
opdracht. Ook hier kwam ik weer tot de conclusie dat door initiatief te nemen en niet bang te
zijn om mensen aan te spreken, je met opbouwend kritiek tot een gewenst resultaat kunt
komen.

Tijdens mijn stage hechte ik heel veel belang aan mijn opdracht en wilde ik deze ook graag
tot een zo goed mogelijk einde brengen. Als ik tegen het einde van de dag, mijn eigen
vooropgestelde doel niet bereikte, werkte ik vaak thuis verder om mijn werk tot een goed
einde te brengen. Hiervoor zal ik in de toekomst wel moeten opletten dat ik het werk wel wat
meer probeer los te laten eenmaal ik het bedrijf verlaat.

Ik heb gekozen om mijn stage te lopen in de IT-consultancy omdat ik het leuk vind dat je in
de consultancy wereld vaak in contact komt met verschillende klanten, daarnaast ben ik ook
zeer geïnteresseerd in het werken met verschillende software. Daarom wil ik mij graag
verder inzetten op mijn technische competenties en beter worden in deze sector. Ik heb
geleerd dat je op de werkvloer veel sneller bijleert. Hierbij wil ik dan ook graag de methoden
en technieken verder ontwikkelen.

7. Bronnen
Ambler, S. W. (2003-2018). Geraadpleegd op 19 augustus 2019, via
http://www.agilemodeling.com/artifacts/useCaseDiagram.htm

De, S., Sam,J. (2015). Low-code development meets fine-grained security. Geraadpleegd op
14 oktober 2019, via https://www.infoworld.com/article/3000572/applicationdevelopment/low-
code-development-meets-fine-grained-security.html

Delaware. (2019). Geraadpleegd op 19 augustus 2019, via https://www.delaware.pro/nl-

NL/About-Us

Encyclo. (2019). Geraadpleegd op 19 augustus 2019, via

https://www.encyclo.nl/begrip/User_interface

Nepal, M. (2018). Low-Code Development Platforms – Launchpads to Build Powerful Apps

Easily. Geraadpleegd op 13 oktober 2019, via https://kissflow.com/low-code/low-code-
development-platform-launchpad-build-apps-easily/

Opentext Appworks. (2019). Geraadpleegd op 19 augustus 2019, via

https://www.onefox.nl/product/opentext-appworks/

Reselman, B. (2018). Why the promise of low-code software platforms is deceiving.

Geraadpleegd op 14 oktober 2019, via https://devopsagenda.techtarget.com/opinion/Why-
the-promise-of-low-codesoftware-platforms-is-deceiving

Richardson, C., & Rymer, J. R. (2014). New Development Platforms Emerge For Customer-
Facing Applications. Geraadpleegd via Forrester website:
https://www.forrester.com/report/New+Development+Platforms+Emerge+For+CustomerFaci
ng+Applications/-/E-RES113411

Richardson, C., & Rymer, J.R. (2016). Vendor Landscape: The Fractured, Fertile Terrain Of
Low-Code Application Platforms. Geraadpleegd via Forrester website:
https://www.forrester.com/report/Vendor+Landscape+The+Fractured+Fertile+Terrain+Of+Lo
wCode+Application+Platforms/-/E-RES122549

Rymer, J.R. (2018). Customers Illuminate The Benefits And Challenges Of Low-Code
Development Platforms. Geraadpleegd via Forrester website:
https://www.forrester.com/report/Customers+Illuminate+The+Benefits+And+Challenges+Of+
LowCode+Development+Platforms/-/E-RES141793

Sambandam, S. (2018). Where low-code development works—and where it doesn’t.

Geraadpleegd op 19 augustus 2019, via https://www.infoworld.com/article/3295882/where-
low-code-development-works-and-where-it-doesnt.html

Van Schetsen, A. (2016). Guest View: Five reasons low-code development is no longer
optional. Geraadpleegd op 19 augustus 2019, via https://sdtimes.com/agile/guest-view-five-
reasons-low-code-development-no-longer-optional/

VBO. (2018). Digitalisering is geen optie, maar een noodzaak. Geraadpleegd via VBO
website: https://www.vbo-feb.be/globalassets/actiedomeinen/economie--conjunctuur/digitale-
economie/reflect--cyberveiligheid-ook-uw-verantwoordelijkheid/digital-ceo.pdf

8. Bijlagen
 Figuur 1 : Eerste pagina huidige
controlelijst hygiëne en milieu van BelOrta
Figuur 2 : Het
initieel ER-
diagram
Figuur 3 : het usecasediagram van Belorta’s auditapplicatie

Figuur 4 : het herziene ER-diagram

Figuur 5 : Het scherm dat de supervisor te zien krijgt wanneer hij een nieuwe
rapporttemplate aanmaakt

Figuur 6 : De levenscyclus van de rapporttemplate

Figuur 7 : De levenscyclus van het auditrapport