welke features heeft je CLM-systeem zeker nodig?

ontdek het hier!

In een markt vol kant-en-klare IT-oplossingen, is het vaak moeilijk om te beslissen welke oplossing jij als bedrijf zal aankopen. Bovendien is het aankopen en implementeren van zo’n oplossing vaak niet goedkoop, dus het kiezen van de verkeerde IT-oplossing kan desastreuze gevolgen hebben voor jouw bedrijf. 

Waar let je dan best op wanneer je je keuze maakt? Wij raden je aan zeker eerst het wat en waarom vast te leggen en dan pas het hoe. Lijkt je dat een moeilijke taak? Geen zorgen, wij helpen je graag!

it oplossingselectie: vaak niet het gewenste resultaat.

Vandaag worden veel ondernemingen geconfronteerd met een overvloed aan geïnstalleerde IT-oplossingen die hun doel voorbij gaan en niet de verwachte uitkomst bieden. Vaak worden ondernemingen met een probleem geconfronteerd en willen ze onmiddellijk een oplossing aankopen of ontwikkelen. Dat doen ze zonder grondige analyse van hun noden.

Hierbij valt vooral op dat er al snel gekeken wordt naar wat de concurrentie heeft, of oplossingen die men tegenkomt op commerciële events of via het zoeken op het web. Bovendien worden oplossingen die al beschikbaar zijn in de onderneming vaak beschouwd als minderwaardig of geen oplossing. Veel stakeholders zijn ervan overtuigd dat alleen iets nieuws goed genoeg is. Nog opvallend is dat er zelden een beroep wordt gedaan op de bedrijfskennis die er al is: de architecten, applicatiebeheerders, en zelfs de business experts worden niet betrokken. Er is meestal geen echte oplossingsstructuur. 

welke impact heeft een foute oplossing op je bedrijf?

Veel bedrijven zitten vandaag met de volgende problemen:

  • Hun licentiekosten swingen de pan uit als gevolg van een overvloed aan ondermaatse applicaties die nog steeds gebruikt worden.
     
  • Hun applicaties zijn volledig outdated, en er zijn er zo veel dat ze door de bomen het bos niet meer zien. 
     
  • Hun enterprise architecture en onderliggende applicatie architectuur omvat de realiteit niet meer en is chaotisch, of zelfs niet meer up to date.
     
  • De budgettaire ruimte en vrijheid uit het verleden, onder andere door de impact van COVID-19, zijn geslonken, en ze hebben opnieuw nood aan een sterk budgetbeheer op basis van hun strategische visie en invulling daarvan.
     
  • De business en IT-afdelingen werken naast elkaar. In veel organisaties worden vandaag applicaties gebouwd en beheerd door zowel IT als de business (zonder betrokkenheid van IT). Als je dan niet kan terugvallen op een sterk citizen development governance model, mondt het beheer van de applicaties al snel uit in chaos.


Wat moet je als onderneming dan doen om bovenstaande scenario’s te vermijden?

  • Werk een sterke applicatie-architectuur uit, liefst binnen de bredere enterprise architectuur waarbij ook de link wordt gelegd met de proces- en data architectuur.
     
  • Rationaliseer het applicatieportfolio: zorg ervoor dat de kostentoewijzing vs het voordeel van gebruik tot het beste resultaat leidt en creëer daarbij voor de gebruikers een bewustwording.
     
  • Zet een degelijke applicatie governance op: centralisatie moet de basis vormen, maar gecontroleerde decentrale oplossingen kunnen zeker behouden worden met een centrale opvolging.
     
  • Creëer een IT-oplossingsproces, zodat je de instroom van oplossingen en applicaties onder controle kan houden en je je kan baseren op een doordachte wat en waarom analyse voor je verder gaat naar het hoe. 

 
Wij bieden ondersteuning bij elk van deze acties, maar in dit artikel focussen we vooral op het laatste: het creëren van een sterk IT-oplossingsproces.

A woman looking away from the camera, smiling.

een sterk IT-oplossingsproces: hoe begin je eraan?

We hebben het IT-oplossingsproces opgedeeld in een aantal stappen die elkaar ondersteunen en leiden tot de juiste oplossing en vooral tot het bekomen van de gewenste voordelen.
 
Ons stappenplan bestaat uit de volgende onderdelen:

  • wat (de definitie van de nood, ook wel eens scope genoemd)
  • waarom (feasibility studie)
  • hoe (concept)

wat.

De eerste stap in het IT-oplossingsproces is het definiëren van het probleem en zijn oorzaak. Welke nood heeft je bedrijf op dit moment? Dat is de wat-fase. Het is cruciaal dat alle stakeholders hierover meedenken en het met elkaar eens zijn. 

Vaak blijkt na de implementatie van de oplossing dat men die wat-vraag toch niet correct heeft begrepen. Dan horen we de opmerking: “dit is niet wat we gevraagd hebben” of “dit voldoet niet aan onze verwachtingen”. Dat zorgt voor frustratie, maar ook voor extra kosten wanneer er aanpassingen of zelfs een herontwikkeling gedaan moeten worden. 

waarom. 

In een tweede stap gebruiken we de definitie van de nood van je bedrijf om te achterhalen waarom de oplossing zo belangrijk is voor de onderneming en vooral voor haar klanten. Waar zit de toegevoegde waarde?

Hierbij betrekken we in een eerste fase weer alle stakeholders. Van zodra het ‘waarom’ en vooral de toegevoegde waarde duidelijk is, doen we een check-in. Hiervoor gebruiken we een feasibility studie waarbij op korte tijd, naast de uitwerking met de praktijkeigenaren op basis van een check van het ‘wat’ en ‘waarom’, geprobeerd wordt om te kijken of het ‘wat’ wel degelijk oplosbaar is en dat we kunnen voldoen aan de verwachte voordelen vanuit het ‘waarom’. Hierbij proberen we om de voordelen te kwantificeren op basis van budget, maar ook zachte parameters zoals mogelijke positieve impact op de werking van de organisatie. 

hoe.

Pas in de derde stap bepalen we hoe we de wat-vraag invullen en de waarom-vraag realiseren. We starten hier met een concept-fase, waarbij we vooral de wat-vraag uitwerken op het vlak van proces en organisatie. We bevragen tegelijk ook de markt over mogelijke oplossingen die al beschikbaar zijn. Men kan dit een beperkte proces-, organisatie- en applicatie-architectuur oefening noemen die, indien beschikbaar, gemakkelijk kan gemaakt worden binnen de enterprise architecture. 

Deze oefening maakt onder andere duidelijk hoe groot de verandering is, maar ook of de onderneming niet al een geschikte interne oplossing heeft. We willen vooral voorkomen dat ondernemingen voor hetzelfde proces verschillende gelijkaardige oplossingen hebben, die dan ook nog eens elk hun eigen kosten met zich meebrengen (licenties, onderhoud …). 

Deze concept fase zal dus leiden tot een proces- en data beschrijving, een organisatie-impact analyse en een voorstel voor een oplossing. 

design fase.

Een volgende stap in de zoektocht naar een geschikte oplossing, is de uitvoering van een design fase waarbij we de resultaten van de concepten verder verfijnen om te komen tot een werkbare oplossing (proces, data, technologie, applicatie en organisatie). 

De design fase is de laatste theoretische check waarbij alle elementen (proces, organisatie, data, applicatie en technologie) worden samengelegd. Deze kan ook de basis vormen voor een business case. De uitkomst is een kant-en-klare invulling van de wat-vraag, met een grote garantie dat de toegevoegde waarde van de waarom-vraag zal worden gerealiseerd. 

Nu we de theoretische oplossing hebben, kunnen we overgaan tot de implementatie. Wij raden vaak aan om beperkt te starten: eventueel met een zogenaamde proof of concept (POC) waarbij we naast de effectieve realisatie van het concept ook aandacht besteden aan de mogelijke partners (proof of partnership). We waken erover dat de geplande aanpak voldoet voor verdere roll-out (proof of approach) en dat de voorgestelde architectuur binnen het ruimere bedrijfskader past en vooral werkt (proof of architecture/tooling). 

Je kan ook kiezen voor een pilootimplementatie, waarbij we voor een aantal gebruikers of sites een eerste implementatie doen van de oplossing en in detail de resultaten analyseren. Daarna gebeurt de zogenaamde roll-out naar de onderneming.

Door gebruik te maken van de verschillende fases voor de uitwerking van de oplossing, houdt de onderneming op elk moment controle over de implementatie. We gaan te werk via de zogenaamde stage gate approach, waarbij we elke fase duidelijk inplannen op resultaat en oplevering, en op het einde van de fase steeds controle houden en zelfs kunnen besluiten om het oplossen van het ‘wat’ en ‘waarom’ stop te zetten, als de kosten niet opwegen tegen de baten. 

wat als je de fases in het proces niet doorloopt?

Als je de wat- en waarom-vraag niet duidelijk definieert, is het risico op falen beduidend hoger en worden er veel verloren inspanningen gedaan. Enkele praktijkvoorbeelden:

  • Mijn concurrent digitaliseert via methode X, dat moet ik ook doen.
    • Resultaat: de digitalisatie levert weinig tot geen meerwaarde op en creëert geen duidelijk voordeel ten opzichte van de concurrentie. 
       
  • Bij het bezoek aan een beurs zie ik een rapportage oplossing die pas nieuw is en er fancy uitziet. Ik beslis dan ook dadelijk om deze oplossing aan te kopen.
    • Resultaat: tijdens of na de implementatie blijkt de oplossing toch niet zo veel voordelen te bieden, en stel ik ook vast dat mijn huidige manier van werken eigenlijk al mijn noden invult.
       
  • Ik heb mijn wat-analyse gedaan en ik heb een issue gedefinieerd. Ik beslis dat een waarom-analyse of feasibility studie niet noodzakelijk is en koop onmiddellijk een oplossing op de markt. 
    • Resultaat: de oplossing wordt geïmplementeerd, maar biedt eigenlijk geen oplossing voor de wat-vraag, of heeft zo veel neveneffecten dat de toegevoegde waarde, die normaal in de waarom-vraag zou worden duidelijk gemaakt, compleet ontbreekt. 


Bovenstaand niet-exhaustief overzicht van voorbeelden waarbij het fout ging, maakt duidelijk dat door een goede voorbereiding en duidelijk geplande aanpak, de kans op succes een pak groter is. Door ook nog eens gebruikt te maken van de stage gate approach, zetten we een intermediate bewaking op die ervoor zorgt dat het finaal beoogde resultaat wordt opgeleverd. 

concrete invulling.

AUSY heeft de bovenstaande aanpak ondertussen voor een aantal bedrijven omgezet in een concreet framework. Wil je graag meer weten of heb je een specifieke vraag? Aarzel niet en neem contact op met jan.verbieren@ausy.be.