Een tijd terug las ik een artikel in “De Ingenieur” over het software monster. Het software monster is een onzichtbaar, maar groeiend probleem in veel bedrijven.
In de loop van de tijd groeien bedrijven en van de gebruikte software worden meer functionaliteiten verwacht en zo evolueert de software en worden steeds meer add-ons gebouwd. Maar weet jij zeker of de gebruikte software eigenlijk nog wel de juiste keuze is om tegemoet te komen aan wat jouw bedrijf nodig heeft?
Ga eens lekker zitten met een kopje koffie of thee en denk na over alle programma’s die in jouw bedrijf worden gebruikt. Weet jij zeker dat die nog voldoen om de processen in jouw bedrijf te ondersteunen? Weet jij zeker dat er geen overlap zit in functionaliteit? Gebeurt het regelmatig dat jij dubbele data moet invoeren omdat de programma’s niet (kunnen) samenwerken? Weet jij ook het waarom achter alle programma’s en tools? Hebben ze überhaupt nog wel bestaansrecht? En bij wie moet je zijn als er iets moet worden aangepast?
Veel bedrijven hebben software en tools ontwikkeld om aan één enkele behoefte te voldoen. Soms omdat de beschikbare software op dat moment niet de juiste specificaties had, soms omdat iemand in Excel iets heeft gebouwd en een paar macro’s heeft toegevoegd maar wat ik vooral vaak ben tegengekomen: een gebrek aan kennis over de bestaande software. En dan wordt er iets ontwikkeld in een nieuwe tool terwijl dit eenvoudig opgelost had kunnen worden met de bestaande software.
En dat vind ik gewoon zonde, jij toch ook?
Mijn advies is: doe een stap terug en bedenk wat jij eigenlijk wil bereiken met jouw systemen. Wat zijn de processen van jouw bedrijf, welke informatie heb jij nodig om jouw bedrijf te managen of jouw producten of projecten? Zodra deze uitgangspunten duidelijk zijn, kan er een Architectual Software Landscape opgezet worden van jouw huidige en gewenste programma’s. Zorg ervoor dat jij alle ins & outs weet van de mogelijkheden van de software maar laat je vooral niet te snel verleiden door extra functionaliteit die jij niet echt nodig hebt. Maak een duidelijk onderscheid tussen “nice to have” en “need to have”. Ik heb ervaren dat vele “nice to have” het project compleet lieten ontsporen en de klant uiteindelijk ook zijn “need to have” niet had.
Dit landschap opzetten en de demarcatie maken tussen “nice to have” en “need to have” kost inderdaad extra tijd in de voorbereiding. Maar bedenk dat het jou heel veel kosten gaat besparen door het elimineren van overtollige software(abonnementen) en het gaat jou heel veel tijd schelen zowel tijdens de implementatie als tijdens het gebruik.