De software van vandaag moet ruimte laten voor de vragen van morgen
Bij bedrijfssoftware telt niet alleen wat een pakket vandaag kan, maar vooral hoeveel technische ruimte het laat om later verder te bouwen, koppelen en aanpassen. Die vrijheid word...
De software van vandaag moet ruimte laten voor de vragen van morgen
Bij de keuze van bedrijfssoftware wordt meestal gekeken naar wat een pakket vandaag kan. Maar minstens even interessant is de vraag wat u er morgen nog mee kunt.
Kan het onze verkoop verwerken?
Kan het voorraad opvolgen?
Kunnen we ermee factureren?
Zijn de nodige rapporten beschikbaar?
Past het bij onze huidige werking?
Logische vragen.
Minstens even belangrijk is wat er gebeurt wanneer de werking binnen enkele jaren verandert.
Wanneer er nieuwe gegevens moeten worden bijgehouden.
Wanneer bestaande schermen niet meer volstaan.
Wanneer een volledig nieuw proces ontstaat.
Wanneer een extern platform gekoppeld moet worden.
Of wanneer een eigen toepassing rechtstreeks met de software moet samenwerken.
Dan wordt niet alleen belangrijk wat het pakket vandaag standaard kan, maar vooral hoeveel technische ruimte het laat om verder te bouwen.
En daar speelt ook de technische kennis van de softwarepartner een grote rol.
Niemand weet wat er over vijf jaar nodig is
Dat hoeft ook niet.
Vijf jaar geleden wist u waarschijnlijk ook niet exact welke toepassingen, koppelingen of automatiseringen vandaag deel zouden uitmaken van uw werking.
Bedrijven veranderen. Processen veranderen. Klanten en leveranciers verwachten andere dingen. Nieuwe technologie wordt beschikbaar. En soms ontstaat intern gewoon een betere manier om iets te doen.
Software hoeft die verandering niet te voorspellen.
Ze moet er wel ruimte voor laten.
Daarom is niet alleen de functionaliteit van vandaag relevant, maar ook de technische mogelijkheden achter het pakket.
Want net die bepalen vaak hoeveel vrijheid er later nog overblijft.
Kunnen we aan de data?
Data is de basis van bijna elke verdere ontwikkeling.
Toch is toegang tot die data niet bij elk softwarepakket vanzelfsprekend.
Soms bent u beperkt tot de rapporten die standaard voorzien zijn. Soms kunt u gegevens exporteren, maar slechts een deel ervan. Soms bepaalt een API welke gegevens beschikbaar zijn en wat u ermee kunt doen.
De interessante vraag komt meestal later:
Kunnen we zelf rapportering bouwen?
Data uit verschillende systemen combineren?
Een eigen toepassing ontwikkelen?
Gegevens gebruiken die niet in een standaardrapport zitten?
Dan maakt het een groot verschil of er technisch toegang is tot de onderliggende gegevens en duidelijk is hoe die gegevens met elkaar samenhangen.
Kunnen we het datamodel uitbreiden?
Een bedrijf houdt vandaag misschien tien kenmerken bij over een klant, artikel, project of bestelling.
Morgen worden dat er elf.
Klinkt eenvoudig, maar technisch kan het verschil groot zijn.
Een veld toevoegen moet verder kunnen gaan dan alleen dat veld ergens opslaan.
- Kunnen we het tonen op bestaande schermen?
- Kunnen we erop zoeken en filteren?
- Kunnen we het gebruiken in rapportering?
- Kunnen we het vanuit eigen code aanspreken?
- Kan het mee in imports, exports en koppelingen?
En wat als één extra veld niet voldoende is?
Kunnen we dan nieuwe tabellen toevoegen? Relaties leggen met bestaande gegevens? En daar vervolgens eigen functionaliteit rond bouwen?
Dat soort mogelijkheden staat zelden bovenaan een commerciële functielijst. Maar enkele jaren later kunnen ze bijzonder belangrijk worden.
Kunnen we bestaande schermen aanpassen?
Standaardschermen worden gebouwd voor een brede groep gebruikers. De kans is klein dat ze perfect aansluiten bij elk specifiek bedrijfsproces.
Daarom is vooral belangrijk of we verder kunnen gaan dan alleen instellen welke bestaande opties actief zijn.
- Informatie toevoegen aan een bestaand scherm
- Een extra tabblad voorzien
- Eigen acties toevoegen
- Specifieke controles uitvoeren
- Bepaalde stappen automatiseren
Een kleine technische aanpassing kan soms voorkomen dat medewerkers naast hun bedrijfssoftware nog aparte Excel-bestanden, losse lijstjes of andere toepassingen nodig hebben.
Kunnen we volledig nieuwe functionaliteit bouwen?
Soms volstaat aanpassen niet.
Een organisatie heeft bijvoorbeeld een specifiek proces waarvoor binnen de standaardsoftware niets voorzien is.
Als de software technisch voldoende open is, kunnen we nieuwe functionaliteit bouwen die aansluit op wat er al bestaat.
Nieuwe tabellen.
Nieuwe schermen.
Eigen businesslogica.
Specifieke workflows.
Achtergrondprocessen.
Of zelfs een volledige webapplicatie.
Die nieuwe functionaliteit kan dan gebruikmaken van dezelfde klanten, artikelen, projecten, documenten of andere gegevens die al in het centrale systeem aanwezig zijn.
Zo ontstaat geen nieuw software-eiland, maar een uitbreiding van de bestaande omgeving.
Blijven uitbreidingen werken na een update?
Technisch iets kunnen aanpassen is één zaak. Er ook op kunnen blijven verderbouwen terwijl de standaardsoftware evolueert, is minstens even belangrijk.
Een ERP-systeem krijgt updates. Nieuwe versies brengen wijzigingen mee aan schermen, databanken, processen, API's en interne logica.
De belangrijke vraag is daarom niet alleen of maatwerk mogelijk is, maar ook hoe de software ermee omgaat wanneer de standaardomgeving verandert.
Blijven eigen velden en tabellen behouden?
Blijven aangepaste schermen functioneren?
Blijven koppelingen en eigen toepassingen werken?
Zijn uitbreidingen technisch gescheiden van de standaardsoftware?
Zijn er duidelijke interfaces waarop developers kunnen blijven bouwen?
Want als iedere ERP-update betekent dat maatwerk opnieuw nagekeken, aangepast of zelfs gedeeltelijk herbouwd moet worden, wordt een gewone software-update al snel een softwareproject op zich.
Daarom is het belangrijk dat uitbreidingen niet alleen technisch mogelijk zijn, maar ook op een gecontroleerde en onderhoudbare manier kunnen worden gebouwd.
Echte technische uitbreidbaarheid betekent niet alleen dat developers iets kunnen bouwen.
Het betekent ook dat de ERP-software hen een stabiele basis geeft waarop ze kunnen blijven bouwen terwijl het pakket zelf verder evolueert.
Net daarom maken de technische architectuur van het ERP-systeem en de uitbreidingsmogelijkheden die het aan developers biedt zo'n groot verschil.
Kan de software samenwerken met andere toepassingen?
Geen enkel softwarepakket hoeft alles zelf te kunnen.
Sterker nog: dat hoeft helemaal niet het doel te zijn.
Een gespecialiseerd platform kan voor een bepaalde taak veel geschikter zijn. Een webshop stelt andere eisen dan een ERP-systeem. Een klantenportaal heeft andere vereisten dan interne administratieve software.
De vraag is vooral of die verschillende systemen goed kunnen samenwerken.
Daar spelen API's uiteraard een belangrijke rol. Maar het bestaan van een API alleen zegt nog niet hoeveel vrijheid u werkelijk hebt.
- Kunnen we de gegevens bereiken die we nodig hebben?
- Kunnen we gegevens lezen én schrijven?
- Kunnen we acties en processen uitvoeren?
- Kunnen we voldoende diep integreren om een volledig proces over verschillende systemen te laten lopen?
Technisch open software maakt het mogelijk om voor elk onderdeel de juiste technologie te gebruiken, zonder dat alle toepassingen losse eilanden worden.
Gegevens schrijven vraagt meer dan toegang tot een database
Gegevens uitlezen is één zaak. Gegevens toevoegen of wijzigen is iets anders.
Bij bedrijfssoftware zit achter een ogenschijnlijk eenvoudige handeling vaak heel wat logica.
Een bestelling kan voorraad beïnvloeden.
Een levering kan statussen aanpassen.
Een factuur kan boekhoudkundige gevolgen hebben.
Een wijziging kan controles, rechten of andere processen activeren.
Rechtstreeks gegevens in een database kunnen plaatsen, is daarom niet voldoende.
Gegevens moeten op een gecontroleerde manier kunnen worden toegevoegd of gewijzigd, rekening houdend met de bestaande logica van het systeem.
Dat kan bijvoorbeeld via API's, services, SDK's of andere technische uitbreidingsmogelijkheden die daarvoor voorzien zijn.
Zo kunnen we verregaand integreren zonder bestaande controles en bedrijfslogica zomaar te omzeilen.
Open software alleen is niet voldoende
Daar komt nog een tweede aspect bij.
Een softwarepakket kan technisch veel mogelijkheden bieden. Maar iemand moet die mogelijkheden natuurlijk ook kunnen benutten.
- Een API moet geïntegreerd worden.
- Een datamodel moet begrepen worden.
- Nieuwe tabellen en relaties moeten correct ontworpen worden.
- Businesslogica moet ontwikkeld worden.
- Een externe toepassing moet veilig met het systeem communiceren.
Dat vraagt meer dan alleen kennis van de standaardinstellingen van een softwarepakket.
Bij Debiscom zijn we developers.
Daarom kijken we niet alleen naar wat binnen de standaardmogelijkheden van software voorzien is, maar ook naar wat we technisch kunnen uitbreiden, integreren of ontwikkelen.
Dat betekent niet dat we standaardfunctionaliteit vervangen door maatwerk zodra iets anders mogelijk is.
Integendeel.
Als standaardfunctionaliteit goed werkt, gebruiken we ze.
Maar wanneer de standaard stopt, hoeft het gesprek niet noodzakelijk te stoppen.
Dan kijken we naar wat technisch nog mogelijk is.
Standaard waar het kan, ontwikkelen waar het zinvol is
Net die combinatie is belangrijk.
Goede standaardsoftware vormt een stevig fundament. Daarbovenop moet voldoende technische vrijheid bestaan om specifieke behoeften op te vangen.
Soms betekent dat een extra veld.
Soms een aangepast scherm.
Soms een API-koppeling.
Soms een achtergrondproces dat gegevens automatisch verwerkt.
En soms bouwen we een volledige toepassing die met de bestaande software samenwerkt.
Niet omdat maatwerk per definitie beter is dan standaardsoftware.
Maar omdat een organisatie zich niet altijd hoeft aan te passen aan de grenzen van een pakket wanneer er technisch een betere manier bestaat.
Kijk dus ook naar wat vandaag nog niet nodig is
Bij een softwarekeuze blijft de functionaliteit van vandaag uiteraard belangrijk.
Maar minstens even belangrijk is de ruimte die het pakket laat voor wat u vandaag nog niet kent.
- Kunnen we bij de data?
- Kunnen we het datamodel uitbreiden?
- Kunnen we schermen aanpassen?
- Kunnen we nieuwe tabellen en functionaliteit toevoegen?
- Kunnen we andere toepassingen koppelen?
- Kunnen we gegevens gecontroleerd lezen én schrijven?
- Blijven uitbreidingen en koppelingen beheersbaar wanneer de ERP-software wordt bijgewerkt?
- En heeft uw softwarepartner de technische kennis om die mogelijkheden daadwerkelijk te benutten?
U hoeft vandaag niet te weten wat u over vijf jaar nodig zult hebben.
Maar u kunt vandaag wel kiezen voor software en een technische partner die ervoor zorgen dat er tegen dan nog voldoende mogelijkheden zijn.
De software van vandaag hoeft de vragen van morgen niet te kennen.
Ze moet er wel ruimte voor laten.