ICT-industrialisering voor corporaties

Ook binnen de corporatiebranche is dit een bekend verschijnsel.

Er zijn natuurlijk ook redenen te bedenken waar om een proces bij de een toch anders loopt dan bij een ander, dat kan bijvoorbeeld afhankelijk zijn van grootte of de regio waar men in werkt. Ook is er een aantal standaarden in de corporatiewereld, maar vaak worden die niet geheel doorgevoerd.

Als we bovenstaande vertalen naar software en software-implementaties dan is het bovenstaande vaak de oorzaak van de verschillen die we tegenkomen bij gebruikers van dezelfde toepassing. Op zich natuurlijk niet erg, maar kunnen we het onszelf niet veel makkelijker maken door vast te houden aan 1 standaard?

Misschien moeten we het eens vergelijken met de apps op een smartphone. Hoewel je bepaalde instellingen kan wijzigen, blijft het proces dat je wilt uitvoeren, bijvoorbeeld een betaalverzoek sturen, qua werkwijze volledig gelijk. We zijn dus niet als gebruiker of gebruikersorganisatie in staat om het proces te beïnvloeden en niemand vindt dit erg. Aan de andere kant hebben we wel een toepassing die doet wat het moet doen, die verrassend weinig uit de lucht is, die eigenlijk nooit fouten vertoond en waar iedereen mee kan werken zonder daar specifiek voor opgeleid te zijn. Was alles maar zo eenvoudig!

Behandel het ERP als een app

Laten we ons eens voorstellen wat we kunnen doen om ook binnen Tobias 365 te bereiken wat de apps al bereikt hebben. Misschien gaat het voor het gevoel af en toe heel ver, maar we kunnen het bezien als een uitwerking van een mogelijk iets te rooskleurig idee. Misschien kunnen we daardoor toch zaken vinden die we kunnen gebruiken, maar duurt het nog een tijd voordat we het zover is. We gaan voor deze uitwerking uit van de situatie dat bij een corporatie de implementatie van Tobias 365 wordt uitgevoerd. Het maakt daarbij niet uit vanaf welk systeem de organisatie komt. Het begint eigenlijk allemaal bij de leverancier van het systeem. Die zorgt voor een basissysteem waar alle instellingen en alle inrichting van gegevens en processen al gedaan is. Hierbij is gebruik gemaakt van reeds bestaande standaarden, zoals bijvoorbeeld het Aedes-processenboek, het RGS en de standaard KPI’s zoals deze in VERA beschreven staan. De basis van het systeem staat dan. Ook moet de leverancier een drempel opwerpen, waardoor het voor de organisatie die het systeem gaat gebruiken onmogelijk wordt om af te wijken van deze standaard. Dus geen instellingen aanpassen en geen inrichting wijzigen. Als dit gebeurd is, kan er worden getest op basis van de gegevens van een corporatie. Laten we dit de nultest noemen. Omdat we een standaardconfiguratie hebben is dit dus een test die representatief is voor de implementaties die op basis van dit systeem worden uitgevoerd*. Alleen het aantal VHE’s is dan nog een variabel gegeven. De conversie is een van de stappen bij implementatie van het oude naar het nieuwe systeem. Hier zullen we misschien een iets complexere voorbereiding krijgen, want we moeten de oude situatie ombuigen naar de nieuwe standaard, zonder concessies. Zodra de conversie is uitgevoerd en goedgekeurd, staat er een systeem dat direct gebruikt kan worden. Testen zou door de eerdere nultest niet meer noodzakelijk zijn en dit mechanisme kunnen we ook gebruiken bij updates van de software. We kunnen ons zelfs afvragen of een proefconversie nog wel nodig is. Doorgaans wordt deze gebruikt om, naast een eerste blik op de resultaten van de conversie, de inrichting van het systeem vast te leggen en te testen. Door de standaard niet aanpasbare inrichting en de eerder uitgevoerd nultest is dit niet meer nodig

Ook in de opleiding van de medewerkers kan veel tijdswinst worden behaald. We hoeven alleen op te leiden in de standaard. En dat betekent dat we niet verschillende varianten van processen moeten doorlopen. Als we af zouden stappen van opleiding met eigen gegevens, kunnen we ook hier de stappen als een proefconversie en andere weer uitsluiten. Alleen de persoonsgegevens en adressen zijn nog eigen, de rest van de inrichting is standaard.

Voor de opleiding zouden we ons eigenlijk het volgende, waarschijnlijk niet reële, doel moeten stellen: opleiding is niet nodig, zoals ook bij apps het geval is. Dan kunnen we de implementatie nog meer beperken. Dit zal waarschijnlijk in de praktijk niet haalbaar zijn, maar wat als we de opleidingstijd terug kunnen brengen tot maximaal 5 dagen voor de hele organisatie? Misschien kunnen we dat bereiken door handelingen die nu in het ERP worden uitgevoerd te verplaatsen naar kleine apps, die niets meer en niets minder doen dan deze ene handeling, zoals het wijzigen van persoonsgegevens.

Bij updates van de software is het waarschijnlijk best wel handig om per rol, zoals deze in de standaard inrichting aanwezig is, via een video te laten zien wat de wijzigingen zijn. Deze video wordt dan getoond op het moment dat een medewerker inlogt na een update van de software.

Tenslotte zouden we ook nog kunnen denken aan het verder automatiseren van stappen in het ERP. Want wat automatisch gaat, hoef je niet te leren.

Samenvattend

Samenvattend zou dit voor een implementatie betekenen dat de doorlooptijd aanzienlijk minder wordt, doordat we van de volgende zaken uit kunnen gaan:

• Projectplan kan een standaard plan zijn.
• Processen hoeven niet te worden getoetst, maar eenmaal toegelicht
• Opleiding gebruikers in maximaal 5 dagen
• Inrichtingsfase is niet meer nodig
• Testfase niet meer nodig
• Voorbereiding conversie kost extra tijd

En door

Het is natuurlijk nog niet zover, maar door er nu bij stil te staan, komen er wellicht zaken voorbij die snel te realiseren zijn. Een uitdaging voor ons om dit samen met onze relaties verder te verkennen.