De adoptiegraad van digitalisering, automatisering en de cloud verschilt niet alleen per bedrijf, maar ook per afdeling. De ervaring leert dat de financiële afdeling vaak achterloopt. Financiële gegevens staan vaak verspreid en zijn soms nog als Excel-bestanden opgeslagen. En wanneer de afdeling finance wel de stap zet om bijvoorbeeld het purchase-to-pay-proces te automatiseren, dan haakt it pas laat aan.
Om meerdere redenen heeft it – en het bedrijf als geheel – er belang bij afdelingen zoals finance te helpen.
Tegenwoordig is er veel meer autonomie binnen afdelingen. Dit betekent dat medewerkers zelf software en applicaties aanschaffen en gebruiken, waardoor het lastiger is voor de it-afdeling om hier een compleet overzicht van te krijgen en te houden. Hier komt nog bij dat steeds meer bedrijfsprocessen gedigitaliseerd worden. Neem bijvoorbeeld de digitale transitie op de financiële afdeling, van grote stapels papieren naar elektronische (en geautomatiseerde) factuurverwerking. Of van een basisoplossing naar een meer geavanceerde oplossing.
Een andere ontwikkeling is dat er freemium-modellen worden gebruikt, waarbij iedereen online een oplossing uit kan proberen. Dat is iets waar it weinig grip op heeft. Het gevolg is dat er – niet altijd op een gecontroleerde manier – veel meer it-applicaties binnen een organisatie ontstaan die niet centraal worden beheerd en waar niet automatisch een koppeling tussen zit, waardoor belangrijke informatie beperkt uit is te wisselen.
Te laat
We zien regelmatig dat it niet of te laat bij een aankoopproces van finance betrokken wordt. En dat terwijl je als it’er een belangrijke rol speelt in dit proces. Neem de vraag of je applicaties on-premise houdt, in de cloud laat draaien of kiest voor een hybride model.
Ook kun jij beoordelen of de softwareleveranciers waar andere afdelingen gebruik van willen maken, voldoen aan securityeisen die je stelt en bijvoorbeeld ISO-gecertificeerd zijn, zodat je een veilig it-landschap biedt. Want natuurlijk let jij als it’er niet alleen op features, maar ook op beveiliging, flexibiliteit en openheid van systemen en software.
Door eerder bij het aankoopproces betrokken te zijn, kun je andere afdelingen zoalsfFinance helpen bij het maken van keuzes die hen niet alleen helpen bedrijfsprocessen te verbeteren, maar ook passen bij de door jouw organisatie gehanteerde it-strategie.
Hoe helpen?
Belangrijk is dan wel dat je als it-afdeling weet wat er in het bedrijf speelt en regelmatig in contact bent met andere afdelingen zoals zinance. Als jij als it’er niet je voelsprieten in de organisatie uit hebt staan, dan voltrekt zich een it-vraagstuk buiten jouw zicht. Door proactief je oor te luister te leggen binnen de organisatie, leer je welke (proces)uitdagingen afdelingen ervaren. Als it’er heb je de kennis en expertise in huis en kun je afdelingen advies geven over de meest passende software om deze uitdagingen te overwinnen. Daarom is het belangrijk dat je contact hebt met eindgebruikers en met de managers van de afdelingen.
Ga bijvoorbeeld één keer per kwartaal in gesprek met de finance-verantwoordelijke over het huidige it-pakket. Bevalt dat nog? Wat zijn de belangrijkste dingen die missen? Welke processen kosten (te) veel tijd? Welke (freemium)-oplossingen zijn er nu in gebruik en voldoen die aan de door jou gestelde it-vereisten? Wat is te automatiseren en optimaliseren? Als je dit soort gesprekken regelmatig voert, dan kom je op tijd uitdagingen op het spoor en kun je samen verkennen welke software-oplossingen wel en welke geen passend antwoord bieden.
En om de controle te behouden over de aanschaf van nieuwe software, kun je nieuwe afspraken maken over de budgettering hiervan. Als je afspreekt dat de it-afdeling betrokken wordt bij alle it-aanschaffingen boven een bepaald bedrag, dan kun je vanaf het begin af aan meedenken en advies geven bij automatiseringsprojecten.
Zo zorg je ervoor dat verschillende afdelingen hun adoptiegraad van automatisering, digitalisering en de cloud kunnen verhogen. Met als overkoepelende resultaat dat het hele bedrijf efficiëntieslagen kan maken. Kortom, zoek elkaar op en praat over (nieuwe) it-oplossingen en het it-landschap.
De financiële administratie is één van de core processen van de onderneming waarvoor je een goed business continuity plan moet hebben. Daarin zit zeker een grote IT component maar er is meer want aangaande de aanschaf van software kan het raadzaam zijn om een escrow overeenkomst af te sluiten. Dat geldt evenzo voor een eventuele vlucht naar de cloud want hele idee van data portabiliteit gaat uiteindelijk om de continuïteit na faillissement van een ketenpartner.
Kortom, de heer ter Steege moet nog eens kijken naar de DMU want hoewel het goed is om de IT te betrekken bij zaken die een grote IT component hebben lijkt het me een multidisciplinair proces waarin naast de functionele aspecten ook goed naar de non-functionele aspecten gekeken wordt.
Je kunt ook een FOSS oplossing inzetten. Met wat moed en een goede partner kun je daar ook goed mee werken.
Met wat moed en een goede partner kun je daar ook goed mee werken zegt helaas nog niks over het blijven werken. En nee, ik heb niks tegen FOSS maar het is hierin wel vaak als de administratie van de vereniging als het om vrijblijvendheid gaat. De keus voor OSS – zonder de wortel van gratis – is echter zeker een optie die het overwegen waard is als IT de benodigde kennis heeft om de oplossing niet alleen te onderhouden maar ook om deze aan te passen. Want FOSS als blackbox introduceren is door de ‘updateritis’ ervan een sores in het beheer.
Oudlid “een goede partner” weet met welke Software je kunt blijven werken, dat is net zo bij “closed source software”.
Overigens leiden de financiele paketten minder aan updateritis als OSsen, en de gebruikte programmeertalen, boekhouders zijn van huis uit conservatief.
Jan,
Wat betreft de keus van software is er, zoals ik in eerdere reactie aangaf, meer dan de code welke open of gesloten kan zijn maar uiteindelijk onderhouden zal moeten worden. Daarbij gaat het niet alleen om de fixes maar ook om nieuwe functionaliteiten welke veelal op een roadmap/release schedule staan, een open source project zonder toekomtverwachting is tenslotte een doodlopende weg. En wat betreft de updateritis bij open source moet je gemiddeld rekening houden met om de 1-2 jaar een major release en zo’n 3 tot 6 minor releases per jaar als we het over actieve projecten hebben. En aangezien vele open source projecten eveneens lifecycles kennen betekent dat er maar een beperkt aantal versies actief onderhouden worden en is er geen vrijblijvendheid in updates. Verandering is nu eenmal een constante in de ICT en daarom is het goed als je daarmee rekening houdt in je change management want behoudendheid leidt tot de ’tech debt’ van verweesde oplossingen waar het rode tape om heen zit. Dat het blijft werken is dan vaak meer geluk dan wijsheid;-)
Je spreekt over “een open source project zonder toekomtverwachting”. Kijken we naar wat Google allemaal op de markt gegooid heeft en dan weer opgeeft, dan zie ik geen verschil.
Van software-startups redt het eveneens slechts een klein percentage. En wie zijn “closed source” programma geen updates geeft landt net zo bij de “tech debt”.
Je schrijft “aangezien vele open source projecten eveneens lifecycles kennen betekent dat er maar een beperkt aantal versies actief onderhouden worden”, die stelling is uit de lucht gegrepen.
Kijken we even naar het web, de LAMP-Stack dwingt gebruikers daarvan om hun daarop baserende software steeds updates te geven, daar is Nginx ook niet beter. De fenomenen van steeds snellere updates en verdwijnende software-leveranciers zijn bij closed en open source Software even sterk aanwezig. “Nieuw” is dat steeds meer closed source bedrijven komponenten uit de open source halen en weigeren daaraan bij te dragen, gaat het dan fout, dan krijgt “open source” de schuld.
“Dat het blijft werken is dan vaak meer geluk dan wijsheid” is nonsens. Dat geldt ook voor closed source programma’s die veweesd zijn. Daarvan heb ik de afgelopen jaren meer gezien als me lief is.
Jan,
De stelling over lifecycles is niet uit de lucht gegrepen want alle leveranciers geven een End-of-Life datum alleen willen sommigen die niet horen: https://www.digitaltrustcenter.nl/informatie-advies/end-of-life
Een voordeel van open source kan zijn dat je zelf deze ondersteuning doet, veel projecten komen tenslotte voort uit dit idee als we kijken naar de vele bijdragen van bijvoorbeeld Microsoft. Uiteraard moet je – zoals ik reeds gezegd heb – dan wel de nodige kennis zelf in huis hebben. Zelf je huis bouwen of een turnkey oplevering is vooral een organisatorische keus.