Analyse & architectuur
Afbakenen en ontwerpen vóór u bouwt.
Veel projecten lopen vast nog vóór de eerste regel code: de vraag is slecht gesteld, de scope is onrealistisch, de architectuur is uit gewoonte gekozen. Een analysefase dient om beslissingen te documenteren en om vast te leggen wat níét gedaan wordt. Ze is niet altijd nodig, en dat zeggen we dan ook.
Wanneer een analysefase helpt
Wanneer er een structurele beslissing op tafel ligt en de meningen uiteenlopen.
U twijfelt tussen een standaardpakket kopen en op maat laten bouwen.
Een project is door meerdere partijen geprijsd met verschillen die niemand kan uitleggen.
U moet een kernsysteem vervangen en u weet niet waar te beginnen.
Verschillende teams hebben een ander beeld van dezelfde vraag.
Een vorig project is halverwege stilgevallen en u wilt begrijpen waarom voor u opnieuw start.
U moet een investeringsdossier voorleggen en u hebt cijfers nodig die standhouden.
Wat een analyse omvat
Begrijpen wat er is, vastleggen wat werkelijk gevraagd wordt, en dan knopen doorhakken.
Het bestaande begrijpen
- Applicaties, stromen en afhankelijkheden in kaart brengen
- De code en de aanwezige infrastructuur lezen
- Bedrijfsregels die in de huidige tools verborgen zitten
- Zwakke punten: niet-onderhouden afhankelijkheden, kennis bij één persoon
De vraag scherpstellen
- Gesprekken met de werkelijke gebruikers, niet alleen met de opdrachtgevers
- Processen beschrijven zoals ze zijn, vóór hoe ze zouden moeten zijn
- Onderscheid tussen vereisten, voorkeuren en gewoonten
- Expliciete prioritering, inclusief wat buiten scope valt
Beslissen
- Een beredeneerde vergelijking van de opties, inclusief niets veranderen
- Architectuurkeuzes gedocumenteerd met hun keerzijde
- Raming van bouwkost en exploitatiekost
- Een traject in stappen in plaats van één groot project
Wat een analyse terugdringt
Elke stap haalt onbekenden weg vóór er een regel code geschreven is. Dat is het moment waarop beslissingen het goedkoopst te wijzigen zijn.
- 01
Bedrijfsprobleem
Het symptoom, vóór elke oplossing
- 02
Proces & gebruikers
Wat er werkelijk gebeurt, omwegen inbegrepen
- 03
Scope
Wat erin zit, en vooral wat erbuiten valt
- 04
Architectuur
De structurele keuzes en hun keerzijde
- 05
Prioriteiten
De bouwvolgorde en haar afhankelijkheden
- 06
Te bouwen oplossing
Een project dat geprijsd kan worden, opgedeeld in stappen
- 01
Bedrijfsprobleem
Het symptoom, vóór elke oplossing
- 02
Proces & gebruikers
Wat er werkelijk gebeurt, omwegen inbegrepen
- 03
Scope
Wat erin zit, en vooral wat erbuiten valt
- 04
Architectuur
De structurele keuzes en hun keerzijde
- 05
Prioriteiten
De bouwvolgorde en haar afhankelijkheden
- 06
Te bouwen oplossing
Een project dat geprijsd kan worden, opgedeeld in stappen
Onzekerheid wordt nooit nul. Het doel is ze laag genoeg te krijgen om een budget vast te leggen zonder te gokken.
Wanneer een analyse niet nodig is
Een studiefase factureren op een vraag die al helder is, helpt niemand.
- De vraag is al afgebakend
- Is het proces begrepen, de scope stabiel en de beslissing genomen, ga dan meteen bouwen. Een studie zal alleen de eerste bruikbare versie vertragen.
- De scope is klein
- Bij een kort project kan een voorstudie meer kosten dan een eerste versie bouwen en die al doende bijsturen.
- De beslissing is al genomen
- Is de keuze om niet-technische redenen al gemaakt, dan kleedt een analyse ze enkel aan. Dat zeggen we liever dan een verantwoordingsdocument te schrijven.
Hoe een analyseopdracht verloopt
Een analyse is kort en begrensd: de datum van de terugkoppeling ligt vast vóór het werk begint. Duurt ze langer dan de eerste stap van het project dat ze voorbereidt, dan heeft ze haar doel gemist.
- 01
De vraag afbakenen
Welke beslissing moet u nemen, tegen wanneer, en met wie? Zonder die vraag levert een analyse een document zonder bestemmeling.
- 02
Verzamelen
Gesprekken, de code en de gegevens lezen, de werkelijke processen observeren. We spreken met wie de tools gebruikt, niet alleen met wie ze bestelt.
- 03
Opties afwegen
Elke optie wordt beoordeeld met haar kosten, haar risico’s en wat ze later uitsluit. Inclusief de optie om niets te veranderen.
- 04
Terugkoppelen
Een mondelinge toelichting aan de beslissers, een document dat zonder ons overeind blijft, en een aanbeveling die we verdedigen.
Wat opgeleverd kan worden
Niet alles is bij elke opdracht nodig. Het resultaat wordt bij de afbakening bepaald, op basis van de beslissing en van wie ze neemt.
- 01
Overzicht van het bestaande
Wat er werkelijk draait, wat waarvan afhangt, en wat niet meer onderhouden wordt.
- 02
Beslissingsdossier
De overwogen opties, hun keerzijden en een beredeneerde aanbeveling.
- 03
Doelarchitectuur
Het beoogde beeld en, vooral, een realistisch pad in stappen om er te geraken.
- 04
Kostenraming
Bouwkost en exploitatiekost, met de onderliggende aannames neergeschreven.
- 05
Stappenplan
Een opdeling in leverbare stappen, met afhankelijkheden en risico’s benoemd.
- 06
Lastenboek
Wanneer u de markt moet bevragen, een document dat vergelijkbare antwoorden oplevert.
Hoe we werken
Een analyse verloopt als een korte opdracht. Ze kan uitmonden in een project, in begeleiding van uw teams, of in niets als dat de juiste conclusie is.
Consultancy & expertiseversterking
Onze consultants vervoegen uw team met de competenties die u nodig hebt: ontwikkeling, functionele analyse, technische analyse, business analyse of architectuur.
Meer wetenMaatwerkproject
Wij nemen de verantwoordelijkheid voor het geheel: analyse, ontwerp, ontwikkeling, integratie, oplevering en verdere evolutie.
Meer weten
Verwante toepassingen
Bedrijfssoftware moderniseren
De applicatie werkt nog, maar wordt duur in onderhoud, moeilijk aanpasbaar en afhankelijk van enkele personen.
Een bedrijfsproces automatiseren
Dezelfde gegevens worden meermaals ingegeven, goedkeuringen lopen via e-mail en niemand weet waar een dossier staat.
Systemen koppelen die niet met elkaar praten
Uw ERP, uw CRM en uw bedrijfstools bevatten elk een stuk van de waarheid, zonder betrouwbare uitwisseling ertussen.
Veelgestelde vragen
Kan een analyse zonder dat u nadien ook bouwt?
Ja, en dat gebeurt geregeld. Het resultaat is opgesteld om bruikbaar te zijn voor elk team, ook voor uw eigen ontwikkelaars of een andere partner. Een dossier waarmee alleen de auteur iets kan, is geen oplevering.
Wat als uw aanbeveling is om niets te doen?
Dan geven we ze toch. Sommige situaties lossen op met een procesaanpassing, een instelling, of het laten vallen van een slecht gesteld project. Dat is een resultaat van de opdracht, geen mislukking.
Hebben we een lastenboek nodig voor we u contacteren?
Nee. Veel vragen komen binnen als symptoom: "onze teams verliezen tijd", "dit systeem houdt het niet". Dat is een voldoende vertrekpunt. Een lastenboek dat te vroeg geschreven wordt, legt vaak een oplossing vast voor het probleem gesteld is.
Werkt u samen met een partij die er al zit?
Ja. Een analyse is er niet om het bestaande team te diskwalificeren. In meerdere gevallen luidt de conclusie dat de scope of de prioritering verduidelijkt moet worden, niet dat de partner vervangen moet worden.
Zit er een budgetraming in de analyse?
Dat kan, op voorwaarde dat de aannames neergeschreven zijn. Een raming zonder expliciete aannames houdt geen stand in een stuurgroep en overleeft de eerste tegenvaller niet.
Laten we de beslissing bespreken
Zeg ons welke afweging u blokkeert. We zeggen u of een analysefase verantwoord is, en wat ze zou moeten opleveren.