02
sep
Training Oracle SQL
sep
Gebruikers willen een extra scherm, een rapportage moet worden aangepast, er is een nieuwe koppeling nodig of een technische verbetering blijft liggen. Ieder verzoek afzonderlijk lijkt overzichtelijk. Maar ondertussen groeit de lijst sneller dan het ontwikkelteam hem kan wegwerken.
In gesprekken met klanten hoor ik vaak hetzelfde. De applicatie draait, de dagelijkse operatie gaat door en daardoor voelt de backlog niet direct als een groot risico. Totdat wijzigingen steeds langer duren, tijdelijke oplossingen ontstaan en belangrijke kennis bij één of twee mensen blijkt te zitten.
Een applicatie die intensief wordt gebruikt, is eigenlijk nooit af. Processen veranderen, wetgeving wordt aangepast, gebruikers stellen andere eisen en systemen moeten steeds meer informatie met elkaar uitwisselen.
Dat geldt zeker voor applicaties die met Oracle APEX zijn gebouwd. APEX maakt het mogelijk om snel nieuwe functionaliteit te ontwikkelen. Maar daarvoor moet er natuurlijk wel voldoende tijd en kennis beschikbaar zijn.
In de praktijk krijgt de dagelijkse operatie bijna altijd voorrang. Incidenten moeten worden opgelost, gebruikers hebben vragen en nieuwe projecten vragen aandacht. Werk dat belangrijk is, maar niet direct urgent voelt, schuift door naar de volgende planning.
En daarna vaak nog een keer.
Zolang de applicatie blijft functioneren, lijkt uitstel beheersbaar. Toch worden de gevolgen langzaam zichtbaar.
Handmatige tussenstappen blijven bestaan. Gebruikers houden eigen lijstjes bij in Excel. Schermen sluiten niet meer goed aan op het proces en koppelingen vragen steeds meer onderhoud. Ondertussen loopt ook de technische schuld op.
Het grootste risico is meestal niet dat de applicatie morgen uitvalt. Het risico is dat de ruimte om te veranderen steeds kleiner wordt. Iedere volgende aanpassing vraagt meer voorbereiding, omdat documentatie niet meer actueel is of omdat de benodigde kennis bij een beperkt aantal mensen zit.
Op een gegeven moment kost een kleine wijziging daardoor opvallend veel tijd. Dat is meestal het moment waarop een capaciteitsprobleem langzaam een continuïteitsprobleem wordt.
Herken je een of meer van deze situaties?
Eén signaal hoeft niet direct een probleem te zijn. Maar als meerdere situaties tegelijk spelen, is het verstandig om te bepalen wat echt moet bewegen en welke kennis of capaciteit daarvoor ontbreekt.
Bij een groeiende backlog gaat het gesprek soms direct over volledige vervanging of een groot moderniseringstraject. Dat kan nodig zijn, maar lang niet altijd.
Vaak is het verstandiger om eerst een duidelijk onderdeel van de backlog op te pakken. Bijvoorbeeld een koppeling die al maanden wacht, een serie gebruiksverbeteringen of technisch onderhoud dat telkens wordt doorgeschoven.
Een ervaren APEX developer kan tijdelijk aansluiten op het bestaande team. Een andere mogelijkheid is een backlog sprint, waarin een afgebakend pakket aan werkzaamheden wordt geanalyseerd, gebouwd, getest en overgedragen.
Voor een groter onderdeel kan een klein deliveryteam worden ingezet. Op onze pagina over het inhuren van een APEX developer lees je welke inzetvormen mogelijk zijn.
Het doel is niet om zomaar extra mensen toe te voegen. Het doel is om gericht werk af te ronden en het bestaande team weer ruimte te geven.
Extra capaciteit werkt het beste wanneer er duidelijke prioriteiten zijn en de developer toegang krijgt tot de juiste functionele en technische kennis.
De externe developer hoeft de applicatie niet volledig over te nemen. Juist de samenwerking met het interne team is belangrijk. Het bestaande team kent de organisatie, de gebruikers en de historie. De externe specialist brengt extra capaciteit, ervaring en soms precies de technische kennis die op dat moment ontbreekt.
De werkzaamheden kunnen uiteenlopen van nieuwe functionaliteit, SQL en PL/SQL, JavaScript en REST integraties tot upgrades, security, performance en technische optimalisatie.
Ook bij oudere APEX applicaties of Oracle Forms omgevingen kan een kleine eerste stap veel duidelijkheid geven. Lees hierover ook onze praktijkervaring met het moderniseren van Oracle Forms.
Tijdens het wegwerken van werkzaamheden kan blijken dat het probleem dieper zit. De applicatie is complex geworden, technische risico’s lopen op of de beveiliging voldoet niet meer aan de huidige eisen. Alleen extra capaciteit toevoegen is dan niet voldoende.
Met Re-platform Move & Improve zetten we onze AI Factory in om de bestaande applicatie te doorgronden én te moderniseren, bijvoorbeeld naar Oracle APEX. AI versnelt het analyse- en ontwikkelwerk, waardoor moderniseren sneller, eenvoudiger en goedkoper wordt. Onze professionals bewaken de architectuur, security en bedrijfslogica en controleren of de nieuwe applicatie doet wat hij moet doen.
Tijdelijke capaciteit heeft pas blijvende waarde als de opgedane kennis binnen de organisatie blijft.
Daarom horen documentatie, werken volgens bestaande ontwikkelstandaarden en actieve kennisoverdracht bij de opdracht. Het interne team moet na afloop begrijpen wat er is aangepast en zelfs verder kunnen.
Dat voorkomt dat tijdelijke ondersteuning een nieuwe afhankelijkheid creëert.
Je hoeft niet eerst de hele backlog opnieuw uit te werken. Begin met de werkzaamheden die al te lang blijven liggen en stel drie vragen:
De antwoorden maken meestal snel duidelijk of één APEX developer, een korte backlog sprint of een deliveryteam het beste past.
In een gesprek van 30 minuten kijken we welke werkzaamheden prioriteit hebben, welke expertise nodig is en welke vorm van extra slagkracht daarbij past.
28 juli 2026 • Transfer Solutions
29 juli 2026 • Jelle Bouwhuis
