HC&H: Pas tijdig uw applicatiestrategie aan op de veranderende positie van het ERP

Geplaatst door CorporatieMedia op
 

Elke corporatie maakt gebruik van een groot aantal applicaties. Naast het bedrijfsinformatiesysteem (ERP) zijn dat bijvoorbeeld ook expertsystemen, externe applicaties (zoals op het gebied van woonruimteverdeling), portalen, apps, een datawarehouse (DWH), een document management systeem (DMS) en een Enterprise Service Bus (ESB) voor het koppelen van applicaties. 

De gehele applicatieportfolio van een corporatie kan uit 50 tot 100 applicaties bestaan. Een applicatiestrategie geeft richting aan de wijze waarop binnen een divers applicatielandschap keuzes worden gemaakt bij het aanschaffen en uitfaseren van applicaties. In dit artikel ga ik in op marktontwikkelingen die hierbij een rol spelen. Wat betekent dit voor uw applicatiestrategie en de selectie van applicaties? Daarnaast presenteer ik een model dat binnen de applicatiestrategie kan worden gehanteerd. 

Wat zien wij in de sector gebeuren en wat is de impact op uw applicatiestrategie
Onderstaande tabel geeft een aantal belangrijke ontwikkelingen weer, gerelateerd aan vraag en aanbod van applicaties voor corporaties. Hierbij wordt tevens de impact aangegeven voor de applicatiestrategie van een corporatie.

Ontwikkeling

Impact applicatiestrategie

Er is geen enkele (ERP) leverancier die alle informatiefuncties voor corporaties ondersteunt.

Er zal altijd de behoefte bestaan om meerdere applicaties aan te schaffen en waar wenselijk te koppelen.

Applicaties worden in toenemende mate als Software as a Service(SaaS), dus als dienst, aangeboden.

Hoe meer er gebruik wordt gemaakt van SaaS, des te minder technisch beheer noodzakelijk is. SaaS leidt ook tot andere contractvormen (pay-per-use), waardoor eenvoudiger afscheid kan worden genomen van de software .

Tevens kan gebruik worden gemaakt van standaard aanwezige SaaS applicaties zoals online (deel)platformen, communities en social media zonder zelf in deze applicaties te investeren.

ERP Leveranciers ontwikkelen niet meer alles zelf maar kiezen vaak voor ERP platformen. ERP applicaties gebaseerd op de platformen van Microsoft, SAP en Axxerion worden nu aangeboden, waarbij de volgende platform gebaseerde ERP applicaties live zijn bij corporaties:

  • Tobias AX (Aareon, Microsoft Dynamics AX)
  • Dynamics Empire (cegeka-dsa, Microsoft Dynamics NAV)
  • Fit4Woco (Ctac, SAP S/4HANA)

Voordeel is dat corporaties (en ERP leveranciers) automatisch bij nieuwere platformversies over nieuwe functionaliteit kunnen beschikken. Nadeel is dat ERP leveranciers en corporaties mee moeten in deze ontwikkelingen.  Een onderliggend ERP platform is voor veel corporaties een belangrijk selectiecriterium bij de keuze voor een ERP applicatie. Hierbij dient dan ook te worden meegewogen in welke mate de leverancier in staat is de platformontwikkeling te volgen om bij te blijven.

Bij uitbreiding van standaard functionaliteit in een onderliggend platform wordt door de jaren heen de toegevoegde functionaliteit door de sectorspecifieke ERP leverancier kleiner. Dit betekent een wijzigende positie van de sector ERP leveranciers.

De vraag is hoe de sectorspecifieke ERP leveranciers hiermee om zullen gaan. Enerzijds kan dit gevolgen hebben voor de prijsstelling: de verhouding tussen de kosten voor de platform leverancier en de ERP leverancier verandert immers. Anderzijds stelt dit eisen aan flexibiliteit in contractduur en afname van modulen (aan- en uitzetten).

Veelal werken ERP leveranciers samen met partners  op specifieke functionele gebieden of nemen deze zelfs over. Ook is er een ontwikkeling dat ERP leveranciers meer naar zichzelf toetrekken, bijvoorbeeld m.b.t. portalen.

Openheid van applicaties zou een belangrijk selectiecriterium moeten zijn. Openheid heeft op dit moment nog wel vaak letterlijk zijn prijs door dure koppelvlakken.

 

ERP platformen gaan betere mogelijkheden voor functionele integratie en informatie uitwisseling bieden.

Hiermee wordt openheid als selectiecriterium nog belangrijker. Dit maakt het eenvoudiger om specifieke modulen te vervangen of processen anders vorm te geven over applicaties heen, ook in de keten.

Een bijkomende applicatie-eis hierbij kan ‘Loosly coupled’ zijn. Dit betekent dat een applicatie zoveel mogelijk zelfstandig kan opereren en niet afhankelijk is van beschikbaarheid/uitval van een andere applicatie.

ERP leveranciers bieden vaker ‘standaard’ functionaliteit en inrichting aan en doen liever geen maatwerk.

Voor die processen en informatievoorziening die standaard en efficiënt moeten verlopen, sluit dat goed aan bij de vraag vanuit de markt. 

Toenemende standaardisatie (VERA, KOVRA/SALES, RGS, SBR)

Het toepassen van standaarden is een belangrijke voorwaarde voor het kunnen koppelen van applicaties en voor verantwoording en draagt daarmee bij aan de openheid van applicaties.

Op bepaalde vlakken is door corporaties dynamiek gewenst, bijvoorbeeld omdat processen anders worden vormgegeven. Voorbeelden zijn ketenprocessen (op het gebied van onderhoud) waarbij werkzaamheden in de keten verplaatsen en processen die op basis van data en Artificial Intelligence (AI) worden vormgegeven [zie kader]

Daar waar het vanuit de business dynamiek gewenst is, dient helder te zijn waar dat binnen het applicatielandschap mogelijk is. Met andere woorden: hoe hard is een ‘tenzij’ binnen een uitgangspunt ‘ERP tenzij’? Onder invloed van andere, hierboven geschetste ontwikkelingen, zal het eenvoudiger worden voor de ‘tenzij’ te kiezen.

Appificatie, waarbij apps als kleine applicaties met een specifiek beperkt doel op mobiele apparaten worden gebruikt, gericht op een ultieme gebruikerservaring. Voorbeelden zijn: ReparatieApp,  RenovatieApp,  WoningruilApp (Huisje Huisje), EnergieApp, BetaalApp (Tikkie) en een InspectieApp.

Ook apps dienen een plaats te hebben binnen de applicatiestrategie en bieden de mogelijkheid om specifieke functionaliteit op een andere manier aan te bieden. Ook hierbij kan koppelen met andere applicaties van belang zijn.

ERP platformen bieden eenvoudiger toegang tot innovatieve toepassingen als IoT, block chain, big data, artificial intelligence en machine learning.

Hoewel platformen op dit moment dergelijke mogelijkheden bieden, zien we dat deze nog niet/beperkt vertaald worden naar oplossingen die door de ERP leveranciers in de sector worden aangeboden. Hiervoor is bij hen de kennis veelal ook niet aanwezig. Kennis zul je dus als corporatie als je hiermee aan de slag wilt elders moeten betrekken.

Ook geldt dat je voor innovatieve experimenten niet al direct voor langere tijd vast wil zitten aan een applicatie.

Artificial Intelligence: dynamiek proces huurincasso

Hoe gaat het nu?
Een standaard proces huurincasso kan binnen een ERP applicatie goed worden gestandaardiseerd. Betaaltermijnen bepalen het tijdstip waarop de huurder de huur betaald moet hebben. Bij niet tijdig betalen, gaat een door een corporatiemedewerker geïnitieerd aanmaanproces in werking waarin verschillende niveaus van toepassing kunnen zijn, van herinnering tot en met overdracht aan een deurwaarder, afhankelijk van eerdere aanmaningen. 

Hoe kan het ook?
Artificial Intelligence (Machine Learning) maakt het mogelijk om, mede op basis van betaalgedrag, een huurincasso-proces volledig automatisch via bots te laten verlopen. Hierdoor kan het incassoproces op maat worden toegesneden op een individuele huurder op basis van de informatie die over hem/haar bekend is. Zo kan voor een specifieke huurder bijvoorbeeld op de 28e van de maand een betaalverzoek met een betaallink via mobiel worden verstuurd als geconstateerd wordt dat dit voor deze huurder het meeste effect heeft. Ymere is een corporatie die bezig is het huurincasso-proces op deze manier vorm te geven. De hiervoor benodigde functionaliteit wordt (op dit moment) niet door een ERP applicatie ondersteund.

Hoe creëert u meer flexibiliteit in uw applicatielandschap?
Door Gartner is enige jaren geleden een applicatievisie (Pace-Layered Application Strategy) ontwikkeld die onderscheid maakt tussen verschil in levenscyclus van applicaties om beter in te kunnen spelen op behoeften van de business en de omgevingsdynamiek. Dit model past goed op de in dit artikel geschetste ontwikkelingen. De corporaties die HC&H de afgelopen periode heeft ondersteund bij hun applicatiestrategie hebben dit model daarin ook toegepast.

In onderstaand figuur is dit model weergegeven. Kern is dat er onderscheid wordt gemaakt tussen een drietal lagen die een aantal kenmerken hebben en die tevens de levenscyclus van applicaties binnen de organisatie bepalen:

  • Systems of Record bevatten de kritische bedrijfsdata en ondersteunen de belangrijke bedrijfsprocessen. De nadruk ligt hierbij op stabiliteit, efficiency en standaard.  De mate van verandering van deze applicaties is laag, mede doordat de ondersteunende processen goed ingeburgerd zijn bij de meeste corporaties en veelal onderworpen zijn aan wettelijke vereisten. Systems of record hebben de langste levenscyclus (7-10 jaar).
  • Systems of Differentiation ondersteunen unieke en vaker veranderende (keten)processen. Het gaat hierbij veelal om bedrijfsspecifieke wensen, vaak dichter bij de klant. Deze hebben een middellange levenscyclus van 3-4 jaar. 
  • Systems of Innovation zijn nieuwe applicaties bijvoorbeeld apps die ad-hoc worden ingezet. Inzet is veelal als experiment waarbij ook weer gestopt wordt op het moment dat de applicatie niet werkt. De levenscyclus is veelal korter dan 1 jaar. 

Actualiseer tijdig uw  applicatiestrategie naar de huidige ontwikkelingen
Op basis van toepassing van het bovenstaand model bij een aantal corporaties treft u onderstaand een aantal suggesties aan:

  1. Toekomstbestendige corporatie: het model sluit goed aan op de uitgangspunten ‘solide waar het moet’ en ‘flexibel waar gewenst’. Het model geeft tevens meer verdieping dan een uitgangspunt als ‘ERP tenzij’. Door in te spelen op ontwikkelingen in de markt en tijdig uw applicatiestrategie te actualiseren vergroot u de toekomstbestendigheid van uw corporatie.
  2. Inzicht naar levenscyclus: de gelaagdheid is goed toe te passen om een huidig applicatielandschap in beeld te brengen. Het basisdeel van het ERP is te positioneren binnen Systems of Record. Specifieke modulen van een ERP of expertsystemen worden gepositioneerd binnen Systems of Differentiation. Een voorbeeld van een System of Differentiation is een Klantportaal, ongeacht of dit onderdeel uitmaakt van een ERP of als aparte applicatie wordt aangeschaft omdat een ERP leverancier deze functionaliteit niet of onvoldoende biedt. Ook een DMS als basisapplicatie voor ongestructureerde informatie kan als System of Record worden gepositioneerd.
  3. Positie ERP binnen uw applicatiestrategie: bij nieuwe contracten met ERP leveranciers zal voor die modulen die worden gepositioneerd binnen de Systems of Differentiation vanwege de gewenste flexibiliteit worden gekozen voor een contractvorm en -duur die past bij het soort applicatie zonder vendor lock-in. Dit impliceert keuzevrijheid bij het al dan niet inzetten van modules in de tijd (aan- en uitzetten). De verwachting is dat de rol van het ERP binnen Systems of Differentiation de komende jaren zal afnemen.
  4. Digitaliseringsdoelstelling: een belangrijk deel van het realiseren van digitaliseringsdoelstellingen voor corporaties moet worden gezocht binnen de Systems of Differentiation. Uiteraard is dat afhankelijk van het ambitieniveau van een corporatie. Als voorbeeld kan het eerder in dit artikel genoemde huurincasso-proces worden genoemd. Voor veel corporaties zal de standaard functionaliteit die een ERP biedt binnen de Systems of Record op dit moment voldoende zijn.

Bron: HC&H Consultants, Foto: HC&H Consultants