Honeywell en de ontwikkeling in het credit management en automatisering

Honeywell heeft vestigingen in honderd landen. Wereldwijd telt de onderneming 108.000 medewerkers. De totale omzet in 2003 bedroeg EURO 23 miljard (Europa EURO 6,5 miljard). Het eerste kantoor in Europa werd in 1934 in Nederland geopend. Dat is dus inmiddels zeventig jaar geleden. In die periode heeft Honeywell vele veranderingen doorgemaakt in structuur en activiteiten.

Eén van de belangrijkste wijzigingen was de fusie met Allied Signal eind jaren negentig. Hierdoor verdubbelde ‘het oude Honeywell’ in één klap in omvang. Om uit deze fusie optimaal resultaat te behalen, diende naast het samenvoegen van businessstructuren, ook uniformiteit in processen en rapportage plaats te vinden.

Dit was een belangrijke uitdaging, aangezien al gauw duidelijk werd dat er binnen het ‘nieuwe Honeywell’ twee historisch gevormde culturen (manieren van werken) bestonden. Ook moesten, om deze uniformiteit te ondersteunen, diverse systemen worden aangepast en/of vervangen. Vooral binnen de administratief en financieel ondersteunende diensten was een diversiteit van systemen aanwezig. Dit maakte de mogelijkheid tot stroomlijnen van processen en rapportage niet eenvoudiger. Het toonde echter ook aan dat er op het gebied van automatisering veel ’te verdienen viel’ in de vorm van efficiëntie.

Global Credit & Treasury Services
Credit management heeft binnen Honeywell altijd een duidelijke plaats gehad. Echter, door de fusie met Allied Signal (en daardoor de overstap van landsstructuur naar verticale businessstructuur) diende ook hier het een en ander drastisch te veranderen.

De belangrijkste wijziging ten tijde van de fusie was de ‘lift’ van alle credit management-activiteiten uit de basisorganisatie. Hierdoor ontstond een serviceorganisatie die zich tegenwoordig GCTS (Global Credit & Treasury Services) noemt. Deze wordt in lijn met de nieuwe businessstructuur gemanaged en kan dan ook terecht ‘Global’ worden genoemd.

Het streven van GCTS als organisatie is diensten te verlenen (binnen Honeywell), die ongeacht business, land of werelddeel zo transparant en uniform mogelijk zijn. Tevens dient dit volgens vastgestelde richtlijnen en procedures te worden uitgevoerd (verder versterkt door de invoering van de Sarbanes Oxley wetgeving in de VS). Dit streven dient uiteraard te leiden tot de volgende resultaten:

• verbeterde productiviteit;
• verbeterde cashflow;
• verlaging van de ouderdom van de debiteuren;
• verbetering van de DSO.

Ontwikkeling van nieuwe software
Om GCTS te ondersteunen ontstond de behoefte aan software. Aangezien de diverse applicaties die reeds binnen Honeywell gebruikt werden óf zeer beperkt in hun mogelijkheden waren óf niet over de benodigde functionaliteit beschikten, werd een project opgestart om te onderzoeken aan welke eisen de software moest voldoen. Belangrijk was om over flexibele software te beschikken die wereldwijd inzetbaar was. Een aantal voorbeelden van noodzakelijke basisfunctionaliteit*:
• automatisering van de collectie activiteiten (strategieën);
• automatisering van de klachtenregistratie, afhandeling en escalatie;
• eenvoudige identificatie van de oorspronkelijke oorzaak van het probleem;
• ondersteuning van Six Sigma methodologie;
• mogelijkheid tot analyse van de data;
• robuuste rapportage.

*Aangezien de tijd binnen het vakgebied niet stilstaat, zijn aan de lijst inmiddels vele nieuwe wensen toegevoegd. Er is permanent een team in de weer om vorm te geven aan deze wensen door middel van aanpassingen op basis van uitgifte van nieuwe releases.

Zoals gebruikelijk bij het selecteren van software dienden diverse criteria te worden opgesteld. Voorbeelden hiervan zijn:
• platformonafhankelijk (Honeywell werkt met diverse softwareapplicaties);
• eenvoudig toegankelijk ongeacht locatie (Web based);
• beschikbaar in de meest voorkomende talen (gebruikers drempelvrees);
• wereldwijd toepasbaar (culturele verschillen in processen);
• aanwezigheid van support wereldwijd (tijdzone onafhankelijk).

Op basis van deze criteria is een zogeheten ‘build versus buy’ analyse uitgevoerd. De uiteindelijke uitkomst is ‘build’ geworden. Er is dus besloten de software intern te ontwikkelen en geen product ‘van de plank te kopen’. Hiervoor is een team opgericht, dat verantwoordelijk is voor de ontwikkeling en de ondersteuning van de implementatie wereldwijd.

Implementatie wereldwijd
Na de implementatie van de eerste versie in Amerika, waarbij de overige teams reeds betrokken waren, is de software verder uitgerold naar de overige regio’s. Bij de ontwikkeling van de volgende release zijn alle specifieke Europese (en later ook Aziatische) elementen verenigd met de eerste versie. Hierdoor gingen onder andere valuta en taal een belangrijkere rol spelen.

Om de implementaties binnen Europa zo efficiënt mogelijk te laten verlopen, is destijds voor een schema gekozen waarbij de start afhankelijk was van:
• impact op het bedrijfsresultaat (verbetering van cashflow);
• type business;
• land (taal);
• infrastructuur.

Uiteindelijk is besloten met de meest complexe business binnen Europa te starten, welke tevens de grootste impact qua verbetering van de eerdergenoemde metrics zou moeten hebben.

Bij de tal van implementaties die in Europa gefaseerd en per land hebben plaatsgevonden is ervoor gekozen reeds vanaf het begin een zo breed mogelijk dekkingsveld te hebben en dus binnen de betrokken landen de specifieke wensen en problemen (uitdagingen) te inventariseren.

Dit blijft altijd een moeilijk onderdeel, zeker omdat het onderscheid tussen ‘nice to have’ en ‘necessary’ vaak moeilijk te bepalen is (ervaring in diverse projecten). Vervolgens blijkt ook vaak dat de wensen gedurende een project nog wel eens willen veranderen. Uiteraard dient de opstelling van de projectmanagers altijd zo flexibel mogelijk te zijn. De volgende stelling bleek wederom van toepassing: ‘When I thought I knew the answers, they changed the questions’.

Om vervolgens maar even in de Engelse terminologie te blijven, kunnen we ons afvragen wat de ‘Lessons learned’ zijn en hoe de opgedane ervaring weer kan worden toegepast op de nieuwe projecten. Een aantal logische, maar toch belangrijke elementen die de moeite van het vermelden waard zijn:

• Zorg voor degelijke training en blijvende informatievoorziening.
• Geef goede ondersteuning, ook na de ‘Go Live’ van het project.
• Registreer alle feedback van de gebruikers (en doe er wat mee!).

Waardevolle feedback
De vestigingen in de landen waar de software is geïmplementeerd, draaien momenteel goed. Gebruikers kunnen nu dan ook, op basis van opgedane ervaring, waardevolle feedback geven over eventuele aanpassingen en verbeteringen. Deze feedback wordt geregistreerd en besproken binnen het projectmanagementteam om vervolgens op basis van prioriteit (wereldwijd) te worden ingepland in de nieuw te ontwikkelen releases.

Het meest gecompliceerde onderdeel bij deze implementaties, waarbij vele landen (regio’s) betrokken zijn, is nog altijd de rapportage. Zeker ook aangezien de behoefte op de diverse niveaus nogal kan verschillen en er rekening moet worden gehouden met diverse valuta’s. Maar ook hier blijkt weer dat met de juiste feedback en inzet niets de ontwikkeling in de weg staat.

Het topmanagement binnen Honeywell is momenteel dusdanig tevreden met de huidige implementaties, dat men het liefst zo snel mogelijk een ‘100% dekking’ ziet van het gebruik van de software. Hier dient uiteraard altijd een balans te blijven tussen kwaliteit en kwantiteit. Daarom worden de projecten voor 2005 weer zorgvuldig gepland.