de 5 opties bij het vernieuwen van een it-systeem · “zo uniek zijn we toch niet? hoe moeilijk...

Whitepaper | De 5 opties bij het vervangen van een IT-systeem

De 5 opties bij het vernieuwen van een IT-systeem

Slim Software Nabouwen | Codeless - Whitepaper


Inhoudsopgave0. Introductie

1. Standaard pakket

2. Maatwerk software

3. Automatisch omzetten van code

4. Handmatig omzetten van code

5. Software nabouwen

6. Over de auteur


Introductie.In de wereld zijn veel, onbekende, succesvolle bedrijven die hun positie in de markt te danken hebben aan een uitgekiende

IT strategie. Een IT strategie waarbij bewust is gekozen om IT volgend te laten zijn aan de vele unieke bedrijfsprocessen.

Zo wordt over ICT op strategisch niveau besloten en dient als succesfactor voor de core-business van het bedrijf.

Dergelijke bedrijven hebben de mogelijkheden

van IT vroegtijdig ingezien en zijn dan ook tijdig

ingestapt op het automatiseren van hun proces-

sen. Op technologisch vlak is de wereld, zeker de

laatste jaren, in rap tempo veranderd en blijkt

dat de onderliggende technologie van deze

waardevolle systemen niet meer up-to-date is.

Door de achterstand in technologie, is de time-

to-market van door te voeren veranderingen

beperkt en wordt men zich langzaam bewust

van de nadelen van de verouderde techno-

logie. Mede door digitalisering in de keten en

veranderende wetgeving neemt de druk op de

IT afdeling toe. Logischerwijs kunnen niet alle

verzoeken worden ingewilligd, hetgeen weer kan

leiden tot onvrede bij de gebruikers.

Als een IT-systeem verouderd kan de techno-

logie steeds meer een berperkende factor zijn

in evolutie van de functionaliteit en kan de

continuïteit van de kennis in het geding zijn.

Bovendien kan de relatie met de leverancier ver-

slechteren omdat je steeds minder op elkaars

behoeften aansluit. Als dergelijke dilemma’s

zich voordoen en steeds vaker een struikelblok

vormen, leidt dit tot de vraag of het niet ver-

standig is om het huidige systeem te vervangen.

Op directie niveau wordt dan veelal opdracht

gegeven tot oriëntatie voor een nieuw systeem.

Welke keuzemogelijkheden heb je als IT eind-

verantwoordelijke en hoe pak je een dergelijk

traject dan verder aan?

De keuzemogelijkheden bij het vervangen van

een uniek IT landschap:

Standaard pakket

Maatwerk software

Automatisch omzetten van code

Handmatig omzetten van code

Software nabouwen


COBOL. EXCEL. DOS. ACCESS.

CLIPPER. VB.

De beste functionaliteiten zijn er al.


[1.]Keuzemogelijkheid Het standaard pakket.


Standaard pakket.Standaard softwarepakketten zijn in feite kant-en-klare softwarepakketten. Vaak zijn deze

pakketten branche of sector specifiek. In andere gevallen kunnen ze meer algemeen van

aard zijn en maakt het mogelijk om in uiteenlopende bedrijven te worden geïmplementeerd.

De software kan na implementatie nog aangepast worden, maar de mogelijkheden zijn zeker

niet eindeloos.

Hoe moeilijk kan het zijn?Het selecteren van het juiste standaardpakket

met de juiste partner voor uw bedrijf vergt

aanzienlijke kennis van de markt en diepgaande

kennis van uw bedrijfsprocessen. Zeker gezien

het grote aanbod van partijen in de markt is het

bijna onmogelijk om alle combinaties tussen

pakketten en leveranciers te verkennen. Het in

de arm nemen van een consultant of adviseur

op dit vlak wordt zeker aangeraden.

“Zo uniek zijn we toch niet? Hoe moeilijk kan

het zijn? We bestellen een product, zetten het

op voorraad en verschepen het naar de klant.

Dat doet toch iedereen? We zouden prima uit

de voeten kunnen met een standaardpakket.

Laten we partij x uitnodigen, daar hoor ik goede

verhalen over.”

Veel te snel maken bedrijven dergelijke keuzes.

Men kiest in korte tijd voor een A-merk met een

bekende leverancier, zonder goed te weten of

het een goede fit is voor het bedrijf. Men kiest

bijvoorbeeld voor Microsoft Navision terwijl dat

beter Microsoft AX had kunnen zijn of andersom.

Vanuit management perspectief lijken de

processen vaak niet uniek en is er al snel een

voorkeur voor een bepaald systeem of

leverancier. Het is dan ook verstandig om

vroegtijdig zowel directie of management te

betrekken bij het project. Op deze wijze kunnen

aannames over complexiteit van processen snel

worden gestaafd.


Hoe kies je een goede IT leverancier?Het kiezen van een standaard softwarepakket

is een bewuste keuze. Standaardpakketten zijn

ideaal als zij passen binnen de organisatie en

als een standaard geïmplementeerd kunnen

worden. Uw huidige bedrijfsprocessen dienen in

kaart te worden gebracht en te worden

afgestemd naar de bedrijfsprocessen die binnen

het systeem standaard worden ondersteund.

Immers, het pakket is veelal opgebouwd uit

best-practices voor dat proces of die branche.

Kiezen voor een standaardpakket is daarmee

ook echt een keuze. Een keuze om het pakket te

volgen en niet af te wijken van de bedrijfsproces-

sen die het pakket ondersteunt. Door gebruik te

maken van de Add-ons bij dit soort pakketten

kunnen eventueel ook andere bedrijfsprocessen

worden vereenvoudigd of geautomatiseerd.

Veelal kunnen standaardpakketten ook worden

geparametriseerd op specifieke

bedrijfskenmerken. Het aanpassen van het

systeem om bepaalde specifieke bedrijfsproces-

sen mogelijk te maken zou voorkomen moeten

worden. Veranderingen aan de kern van het

systeem kunnen leiden tot problemen in de

toekomst bij upgraden van het systeem.

BudgetvriendelijkQua investering is een standaardpakket over het

algemeen de meest interessante optie. U betaalt

licenties en een onderhoudsfee waarvoor uw

partner het systeem doorontwikkelt, gewijzigde

wettelijke eisen implementeert en nieuwe fea-

tures toevoegt. Het pakket wordt veelal breed in

de markt gebruikt waardoor het risico op kinder-

ziektes en fouten voor u minimaal is. Eenieder

in de markt betaalt deze fees zodat in theorie er

voor de leverancier een behoorlijk budget zou

moeten zijn om veranderingen door te voeren.

Door gebruik te maken van bestaande best

practices kan men de inzet van pakketten opti-

maliseren en ervoor zorgen dat men alle opties

benut die het systeem u biedt. U kunt ideeën

opdoen bij uw branchegenoten over de toe-

passingen en mogelijkheden van het systeem.

Wettelijke wijzigingen en aansluiting vinden bij

nieuwe platformen zijn voor rekening van uw le-

verancier. De regie hiervoor ligt bij de leverancier

en u hoeft alleen de nieuwe versie te installeren

op een voor u geschikt moment.


“Zo uniek zijn we toch niet.Hoe moeilijk kan het zijn?”


Regie over het pakketDe regie over functionaliteit ligt bij standaard

software bij de leverancier. Via user groups of

andere kanalen kunt u wijzigingen en verbete-

ringen aandragen en de software leverancier

bepaalt of deze wel of niet zullen worden

opgenomen in de nieuwe versie.

Buiten deze kanalen kunt u verdere wijzigingen

en verbeteringen aandragen, maar het is niet

gegarandeerd dat uw leverancier deze voor

u implementeert of tijdig implementeert. De

meer moderne systemen stellen u zelf in staat

om wijzigingen door te voeren in het systeem of

extra programma’s te ontwikkelen, maar deze

mogelijkheden zijn zeker niet eindeloos.

De grote valkuil bij standaardpakketten is dat

enerzijds een keuze is gemaakt voor een

standaardpakket en dat men anderzijds de regie

en zeggenschap over het systeem in eigen hand

wil houden. Helaas wordt dit vaak pas na de

definitieve keuze en tijdens de implementatie

geconstateerd. Immers, op de werkvloer blijkt

dat de processen toch echt anders lopen dan

het pakket voorschrijft.

Tot in de kern aanpassen van het pakketOp het moment dat u ervoor kiest om het

standaardpakket te (laten) aanpassen aan uw

bedrijfsprocessen maakt u van uw standaard-

pakket een maatwerk systeem. Het installeren

van nieuwe updates zullen kostbare aangele-

genheden worden en u kunt niet langer

eenvoudig gebruikmaken van de nieuwe f

uncties en features die worden ontwikkeld.

Vanwege de hoge kosten wordt het installeren

van de nieuwe versies uitgesteld met als gevolg

dat het pakket vroeg of laat niet meer

ondersteund wordt.


VoorbeeldEen treffend voorbeeld hiervan is Microsoft

Navision 2009. Er zijn vele bedrijven die dit

pakket tot in de kern hebben aangepast en niet

meer zijn overstapt op nieuwe versies. Microsoft

heeft aangegeven vanaf 2019 Navision 2009

niet langer te ondersteunen. Bovendien wordt

de ontwikkellicentie ingetrokken, waardoor het

doorvoeren van wijzigingen niet meer mogelijk

is. Buiten de eigen keuze om dient men dus op

korte termijn te vernieuwen om de continuïteit

van het bedrijf te waarborgen.

ImplementatieUw gebruikers hebben jarenlange ervaring met

uw huidige systeem. Zij kennen het systeem

door en door en weten precies hoe ze bepaalde

uitzonderlijke processen binnen het systeem

moeten afhandelen. In het nieuwe systeem is

deze kennis niet langer voorhanden en dient

men zich aan te passen aan de nieuwe situatie.

Doordat zowel de processen als de software

zijn aangepast, is dit voor gebruikers een grote

overstap. De implementatie is daarom geen

sinecure. Het vergt uitgebreide voorbereiding

op het gebied van onder andere training en

conversie.

Projecten variëren qua duur van 4 maanden

tot 2 jaar. In de regel wordt er gecalculeerd met

licenties, onderhoud en benodigde uren. In

bepaalde specifieke gevallen kan een fixed price

worden bedongen.


[2.]Keuzemogelijkheid Maatwerk software.


Maatwerk software.Ook maatwerk software is een van de meest bekende opties om een softwaresysteem

te vervangen. Maatwerk software wordt volledig ontwikkeld op basis van de require-

ments, verwachtingen en inzichten van de opdrachtgever. Dit soort systemen sluiten

naadloos aan bij het bedrijfsproces. Onnodige functionaliteiten worden hierbij dan

ook vermeden.

Verschillen met standaard softwareDe voornaamste verschillen met standaard soft-

ware komen vooral voort uit budget en tijd tot

implementatie. Het budget is vrijwel altijd hoger

dan het budget dat nodig is voor het implemen-

teren van een standaardpakket. Uitgebreide

documentatie en functionele specificaties zijn

veelal minder aanwezig, aangezien dit te

kostbaar is om op te stellen.

Een maatwerk project kent een lange project-

duur, omdat alle functionaliteiten dienen te

worden opgesteld en ontwikkeld. Bovendien is

de acceptatie en implementatie aanzienlijk tijd-

rovender dan bij een standaardpakket het geval

is. Overigens geldt dit ook voor een standaard-

pakket met veel maatwerk aanpassingen.

Bedrijven die kiezen voor maatwerkBedrijven die kiezen voor maatwerk systemen

besteden dit uit aan een daarvoor gekwalificeer-

de leverancier of voeren het project (groten-

deels) zelf uit met een eigen IT-afdeling.

Bij een dergelijk regie model is het belangrijk

dat de IT-afdeling regelmatig op de hoogte blijft

van de laatste ontwikkelingen op het gebied van

softwareontwikkeling, methoden en techno-

logieën. Op deze wijze wordt voorkomen dat

er eigen standaarden ontstaan, omdat er nu

eenmaal zo ontwikkeld werd in het verleden.

Vanuit kostenperspectief wordt veelal anders

gekeken naar de investering voor outsourcing

dan voor het (deels) zelf ontwikkelen. De reden

is dat een bedrijf het eigen personeel niet meer

als extra investring ziet, omdat ze immers al op

de payroll staan. Een eerlijke vergelijking met

outsourcing is daardoor niet goed te maken,

hetgeen tot misvattingen kan leiden over de

kosten van diverse alternatieven.


De investering voor een nieuw te ontwikkelen

systeem is van groot belang in het maken van de

juiste keuze. De omvang van een systeem wordt

veelal uitgedrukt in een onafhankelijke mee-

teenheid, t.w. functiepunten. De investering en

doorlooptijd in het ontwikkelen van maatwerk

wordt verder in sterke mate beïnvloed door de

zogenaamde productiviteit.

De snelheid waarmee functionaliteit (en dus

ook functiepunten) wordt ontwikkeld, wordt

beïnvloed door 3 parameters:

1. Ontwikkelaars: De snelheid en kwaliteit in het

ontwikkelen van software kan sterk verschillen,

bijvoorbeeld doordat een ontwikkelaar een

junior of juist een senior is;

2. Technologie: De ontwikkeltaal of ontwikkel-

platform dat wordt gekozen, bepaalt in sterke

mate de productiviteit die behaald kan worden.

Ontwikkeltalen zoals .Net en Java kunnen een

productiviteit halen van 6 tot 10 uur per func-

tiepunt. Low-code platforms, zoals Outsystems,

Codeless en Mendix, hebben veel voorgedefini-

eerde functionaliteiten die je in bepaalde mate

configureert en assembleert. Hierdoor maken

zij een productiviteit mogelijk die 2 tot 5 keer zo

snel is dan een ontwikkeltaal;

3. Complexiteit: functies van een te ontwikkelen

informatiesysteem kunnen eenvoudig zijn, maar

kernfuncties kunnen soms zeer complexe

algoritmes of berekeningen bevatten. Dit vereist

voor ontwikkelaars veel puzzelwerk en tes-

tinspanning en heeft dus rechtstreeks invloed

op de benodige ontwikkeltijd.

Onderliggende technologieNaast de productiviteit is een groot voordeel van

low-code platforms dat de onderliggende

technologie kan worden geupdate zonder dat

de coding aanpassing behoeft. Op deze wijze

zijn veranderingen op technologisch vlak min-

der problematisch. Zoals het verleden al eens

heeft uitgewezen, is het niet gezegd dat deze

partijen over 5 tot 10 jaar nog bestaan. Vandaar

dat het zeker de moeite waard is om zaken zoals

een exit-strategie te formuleren.

Projecten variëren qua duur van 4 weken tot

vele jaren. In de regel wordt er gecalculeerd op

basis van benodigde uren. In geval van het

werken met een low-code platform kunnen

licenties en onderhoud een rol spelen.

In bepaalde specifieke gevallen kan een

fixed-price worden bedongen.


[3.]Keuzemogelijkheid Automatisch omzetten van code.


Automatisch omzetten van code.Er zijn diverse partijen op de markt die de coding van het huidige systeem volledig

automatisch converteren naar een nieuwe taal. Met het automatisch omzetten, wordt

dan ook bedoeld dat men de computer de vertaling laat maken van bijvoorbeeld de

taal Cobol naar de taal Java.

U kunt het vergelijken met het automatisch

laten vertalen van een boek uit het Nederlands

naar het Engels. Om dit te kunnen doen moet

elke punt en comma uit het Nederlands worden

gekoppeld aan een taalelement uit het Engels.

Alhoewel er uiteraard tools bestaan om hierbij

te helpen blijft het een arbeidsintensief proces.

Volledig automatisch proces Zodra alle taalelementen zijn gekoppeld kan de

conversie in principe plaatsvinden. Het is een

volledig automatisch proces waarbij alle codere-

gels en daarmee functionaliteiten uit het oude

systeem worden overgezet naar het nieuwe

systeem. Deze methode is alleen mogelijk als

de code van het oude systeem voorhanden is.

In het geval dat dat niet zo is of als er sprake is

van een verouderd standaardpakket, dan is dee

methode niet goed toepasbaar.

Helaas is deze methode niet zo simpel als het

lijkt. Het is namelijk niet alleen code van uw ap-

plicatie die omgezet dient te worden, maar ook

links naar het operating systeem, de database

en bijvoorbeeld zeer specifieke omgevingsfac-

toren. Deze extra factoren houden in dat er veel

werk benodigd is om alle taalelementen correct

aan elkaar te koppelen en ervoor te zorgen dat

alles goed werkt. Afrekening vindt plaats op

basis van het aantal zogenaamde lines of code

(geprogrammeerde coderegels). Hoe meer re-

gels er zijn, hoe kostbaarder het vervangen is.

Bij het overzetten wordt er automatisch code

geïnjecteerd, waarmee vastgesteld kan worden

of de code voor en na de conversie hetzelfde

werkt. Dit kan vergeleken worden met een auto-

matisch gegenereerde test.


AandachtspuntEen aandachtspunt bij automatische conver-

sie is dat de gegenereerde code in de nieuwe

taal structuren bevat die horen bij de oude

programmeertaal. Kortom, wat bijvoorbeeld

in Cobol heel gebruikelijk is, kan na automati-

sche conversie in Java zeer ongebruikelijk zijn.

Hierdoor kan het nodig zijn om na conversie

een optimalisatiefase in te plannen op de nieuw

gegenereerde broncode.

Resultaat automatische conversieVerder is het goed om te beseffen dat dit een

werkwijze is waarbij men alleen kijkt naar de

technische aspecten van de conversie. De func-

tionele werking van het systeem is niet relevant.

De leverancier beschouwt dit dan ook als een

black-box. Er ontstaat geen inhoudelijke kennis

bij de softwareleverancier over het systeem en

zij kunnen dan ook niet helpen bij eventuele

extra benodigde capaciteit.

Automatische conversie is overduidelijk een

unieke aanpak om software te vernieuwen die

in veel gevallen een uitkomst zou kunnen zijn.

Zoals bij iedere methode zitten er voordelen

en nadelen aan de aanpak vast, waar je je van

tevoren goed bewust van moet zijn.

Het resultaat bij automatische conversie is

een exacte kopie van uw huidige omgeving. De

schermen en functionaliteiten worden allen

overgenomen. Dit inclusief eventuele onge-

wenste functionaliteiten en fouten.

Projecten duren gemiddeld 9 – 15 maanden en

zijn in de regel fixed-price, vastgesteld per regel

broncode. Voorbeelden van bedrijven die

automatische conversie aanbieden:

Cornerstone, TSRI en BluAge.


Automatisch omzetten van code,de functionele werking niet relevant.


[4.]Keuzemogelijkheid Coding handmatig omzetten.


Coding handmatig omzetten.Coding handmatig omzetten houdt in dat alle coderegels van het te vervangen

IT landschap handmatig worden bekeken en een voor een worden overgezet.

Arbeidsintensief proces Het is een arbeidsintensief proces waarbij men

alle codingregels individueel beoordeelt. Tech-

nische bugs zullen niet worden meegenomen en

afhankelijk van de vaardigheden van de persoon

die het overzet, worden ook bepaalde logische

fouten weggenomen. Het blijft hierbij altijd lastig

te voorspellen welke verandering ongewenst

leidt tot andere veranderingen.

Waarom bepaalde functionaliteit op een

dergelijke manier is ingebouwd wordt niet

achterhaald. Wellicht dat bepaalde keuzes zijn

bepaald op basis van iets wat eerder is ontwik-

keld, maar niet meer relevant is. Er wordt alleen

gekeken naar hoe de coding is geschreven en

hoe het is opgezet, niet hoe het zou moeten zijn.

Verder kunnen zich situaties voordoen waarin

grote delen van de coding worden herschreven,

maar waarbij deze coding niet wordt gebruikt.

Uitgebreide test scenario’s Bij de livegang van dergelijke systemen dienen

uitgebreide test scenario’s aanwezig te zijn om

vast te stellen of alle relevante coding is over-

genomen en juist is overgenomen. De tests-

cenario’s kunnen op zowel het oude als nieuwe

systeem uitgevoerd worden, waardoor de

testresultaten ook identiek zouden moeten zijn.

Aangezien geen functioneel inhoudelijke kennis

is opgedaan, is er geen beeld van de bedrijfs-

processen die wel of niet zijn overgenomen.

Afhankelijk van de scope van het project heeft

men na het omzetten een nieuwe omgeving in

een moderne technologie.

Nieuwe taalEen voordeel ten opzichte van automatisch con-

verteren is dat de nieuwe taal correct is gebruikt

en structuren van de oude taal niet meer terug

te vinden zijn. Nadat uw medewerkers zijn om-

geschoold naar de nieuwe taal, zijn zij in staat


om de applicatie te onderhouden. Je dient wel

rekening te houden met een bepaalde inleertijd,

aangezien de nieuwe taal en structuren anders

kunnen zijn dan men gewend is.

Een ander voordeel ten opzichte van de

automatische omzetting is dat de nieuwe

applicatie gefaseerd module voor module kan

implementeren. Omdat de omzetting handma-

tig plaatsvindt, is er ook een enorme flexibiliteit

om bijvoorbeeld oude en nieuwe applicatie

voor een tijdelijke periode tegelijk te ondersteu-

nen en naast elkaar te laten draaien. Verdere

voordelen zijn: flexibiliteit, vrijheid bij bepalen

van doelarchitectuur en een groot aanbod aan

specialisten bij overstap naar marktconforme

technologie.

Nadelen handmatige conversieNadelen bij handmatige conversie zijn de hoge

investering en het risico. Doordat alle regels

handmatig worden omgezet, dienen er

uitgebreide testscenario’s te worden opgesteld

om te bepalen of alle functionaliteit is omgezet

en correct werkt. De omzetting vindt meestal

plaats naar een huidige programmeertaal,

bijvoorbeeld .Net of Java, waardoor na het

omzetten wederom geborgd dient te worden

dat het landschap niet snel verouderd.

Er is geen informatie over de gemiddelde

projectduur van dergelijke projecten.

Vanwege de grote hoeveelheid uren is het inte-

ressant om grote outsourcingspartijen hiervoor

te overwegen.


[5.]Keuzemogelijkheid Software nabouwen.


Software nabouwen.Software nabouwen is het een op een nabouwen van de gebruikte en gewenste functionalitei-

ten en schermen van het huidige systeem. Het is bedoeld voor bedrijven die in de kern tevreden

zijn met de functionaliteiten van hun oude systeem, maar hier vanwege andere redenen dan de

functionaliteit afscheid van moeten nemen.

Denk hierbij aan technische veroudering,

pensionering van applicatiebeheerders of

faillissement van IT-leveranciers.

Risicomijdend conceptSoftware nabouwen is een risicobeperkend

concept bij het vervangen van verouderde

softwaresystemen. De kern van de aanpak is

tweeledig. Ten eerste is leidend dat u in de

kern tevreden bent met uw huidige systeem en

dat daardoor de blauwdruk van dat systeem

overgenomen kan worden. Dit houdt in dat bij

gelijke invoer in de systemen er ook een gelijke

uitvoer is. Ten tweede is het aantrekkelijk als de

overstap van systeem A naar systeem B laag-

drempelig is voor de eindgebruikers. Het nieuwe

systeem dient dusdanig herkenbaar te zijn dat

gebruikers eenvoudig en soepel over kunnen

stappen. Wijzigingen in bedrijfsprocessen

worden dan ook pas na livegang doorgevoerd.

Op deze wijze kunnen gebruikers wennen aan

de nieuwe omgeving en wordt de volgende

release als een onderhoudsrelease gezien. Dit

levert een naadloze implementatie op.

Aangezien het huidige, verouderde systeem

in vele jaren en soms door vele medewerkers

is ontwikkeld, is het starten met behulp van

bijvoorbeeld Microsoft Visual Studio geen optie.

De productiviteit van deze traditionele tools is

te laag waardoor de kosten voor het vervangen

van een dergelijk traject dusdanig hoog oplopen

dat er geen business case voor op te stellen is.


Record, Analyse en BuildSoftware nabouwen vindt plaats via de Record,

Analyse en Build methode. Het team start met

het opnemen (Record) van de huidige software

om vervolgens deze opnames te analyseren

(analyse). Na de analyse fase zijn in feite de

functionele specificaties vastgelegd en kan

gestart worden met de ontwikkeling (Build) in

een low-code platform. Voorbeelden hiervan

zijn OutSystems en Codeless.

Het eindproduct is een state-of-the-art nieuw

systeem dat dezelfde functionaliteiten bevat als

het huidige systeem. Het onderhouden van de

software wordt gedaan door de opdrachtgever

zelf of door de leverancier. Nieuwe eisen en

wensen worden dan na het software nabouwen

in de vorm van nieuwe releases ontwikkeld.

Doordat de software wordt omgezet naar een

low-code platform met hoge productiviteit,

wordt hiermee ook de slagkracht van de IT-afde-

ling binnen het bedrijf aanzienlijk vergroot.

De gemiddelde projectduur van software nabou-

wen is 6-9 maanden. Voor grotere systemen ligt

dat gemiddeld op 12 tot 15 maanden.


Compleet responsive. Past moeiteloos aan elk apparaat.


[6.]Overde auteur.


Over Roland WormsRoland Worms is oprichter van

Codeless Technology en heeft 15 jaar ervaring

op het gebied van softwareontwikkeling &

implementatie. Hij is ervan overtuigd dat de

kennis die een bedrijf in een softwaresysteem

heeft geplaatst, zo veel mogelijk moet worden

gerespecteerd en hergebruikt.

Op basis van deze ervaring wil hij mensen

helpen om die kennis te benutten om een vol-

gende digitale stap te kunnen maken.

Het bedrijf Copycats SoftwareOnderscheidend technologie-huis dat opdracht-

gevers helpt in deze complexe en mondiale

wereld om digitaal zaken te doen. Dat doen

we door software-oplossingen aan te bieden

waarbij we het zakelijk gebruikersgemak, Mobile

& Cloud first principe, herdefiniëren.

Met een team van 75 man. Onze oplossingen,

zoals Slim Software nabouwen kenmerken zich

door de laatste technologische eigenschappen,

hoog gebruikersgemak en subliem vormgege-

ven User Interfaces.

Meer weten?

Neem contact met ons op via

078 6534448 of ga naar codeless.com

Over de auteur.

Roland WormsOprichter Codeless Technology

Roland is te bereiken via:

[email protected]

linkedin.com/in/codeless

Lees zijn blog op codeless.com/blog

http://codeless.com

mailto:rworms%40codeless.com?subject=

http://linkedin.com/in/codeless

http://codeless.com/blog

de 5 opties bij het vernieuwen van een it-systeem · “zo uniek zijn we toch niet? hoe moeilijk...

Documents