Onderhandelen over de uitdagingen om de ROI te halen

Het doel van Operationele Analytics

In een notendop moet Operational Analytics in staat zijn om relevante analyses te leveren op het niveau waarop uw organisatie daadwerkelijk opereert. Niet samengevat, maar gedetailleerd. In praktische termen betekent dit inzicht in uw projecten, producten of SKU's, klanten, magazijnen, verkopers en meer, en de mogelijkheid om winstgevendheidsanalyses uit te voeren over alle dimensies van de gegevens.

De uitdaging is dat je misschien niet vanaf de eerste dag precies weet welke analyse moet worden uitgevoerd (als eindgebruikers eenmaal een analyse hebben, willen ze altijd meer!) Een flexibel en allesomvattend datamodel kan nodig zijn, zelfs als je om praktische redenen later eenvoudigere analyses maakt - zie Navigatie van hoogdimensionale data verderop. Denk aan een wendbare aanpak met de constante mogelijkheid om te buigen en te veranderen als er nieuwe vereisten aan het licht komen.

Planning vs. Analytics - het verschil tussen gegevens - een waarschuwing

Op dit punt is het belangrijk op te merken dat een Operationele Analytics kubus, misschien met 20 of meer dimensies, GEEN Planning kubus is - de twee vereisten zijn zeer verschillend. Ik heb gewerkt met bedrijven die probeerden hun verkopers te laten plannen op een gedetailleerd operationeel niveau - bijvoorbeeld voor elk SKU (20.000), voor elke klant, verkooppunt, magazijn, regio, merk, herkomstbedrijf, industriesegment, tijd en nog veel meer. Dit wordt een nachtmerrie voor de vertegenwoordiger en een potentiële bron van risico's, omdat het vrijwel onmogelijk is om de juiste plaats te vinden voor de gegevens.

Een strategie die ik heb gevolgd, is het creëren van een eenvoudige planningskubus die vooraf is gevuld met alle echte combinaties van planningsgegevens (ik heb dit planningsknooppunten genoemd - elk planningsknooppunt vertegenwoordigt een enkele reële combinatie van vele andere dimensies)

enkele echte combinatie van vele andere dimensies). Dat geeft de rep de exacte gegevenspunten om de plangegevens in te stoppen op SKU, Planning Node en Tijd, wat het planningsproces enorm vereenvoudigt. Laat de CPM-software dit vervolgens voor hen toewijzen aan de gedetailleerde kubussen. Hoe meer automatisering in een CPM-oplossing, hoe beter. Bij Prophix gebruiken we Detailed Planning Manager voor precies dit doel.

Finance Breakout - Controle ontnemen aan boekhouders door waarde toe te voegen

Een van mijn oorspronkelijke uitdagingen was dus om Financiën, die meestal eigenaar zijn van CPM-oplossingen, zover te krijgen dat ze een breder gebruik van de oplossing toestaan. De meest effectieve manier om dit te bereiken is om waarde toe te voegen, in de naam van nauwkeurigheid en detail, aan de gegevens die ze al verzamelen. Financiën ziet meestal alleen samengevatte operationele gegevens in de P&L. Door de mogelijkheid te bieden om in enkele van de belangrijkste P&L-lijnen (zoals Verkoop) in te zoomen en gedetailleerde klantwinstgevendheid te krijgen, of een kubus die hen het verschil kan laten zien tussen verwachte en werkelijke verzenddata per factuur per klant, kunnen financieel directeuren en hun medewerkers een enorm inzicht krijgen in de nauwkeurigheid van hun planningsproces. Proactieve analyse van uitschieters is ook mogelijk: stuur maandelijkse problemen rechtstreeks naar Financiën met behulp van geautomatiseerde rapportage.

Het is niet nodig om de operationele kubussen direct te verbinden met de financiële kubussen als je dat niet wilt - hoewel sommige CPM tools je zullen vertellen dat je veel kubussen direct met elkaar kunt verbinden is er zelden een goede business case; het is beter om ze per proces te verbinden (d.w.z. on demand refresh in plaats van live) om de prestaties voor zowel Finance als Operations te garanderen. Operations-gegevens veranderen vaak veel sneller dan Finance-gegevens, of zijn gewoon dagelijks nodig.

Finance vs IT - waar ligt de verantwoordelijkheid?

Ik zou dit ook kunnen formuleren als "wie moet er voor CPM-systemen zorgen, IT of de business? De uitdaging hier is dat IT technisch bekwaam personeel heeft dat misschien ervaring heeft met databases en systemen, maar over het algemeen weinig tijd heeft en verantwoordelijk is voor het hele bedrijf in plaats van een expert in een bepaald onderdeel. Bedrijfsafdelingen zijn experts op hun gebied, maar meestal geen systeemexperts, en ook tijdgebrek.

Projecten die ik het meest succesvol heb zien zijn, hebben een aantal middelen van het bedrijf gecombineerd:

1. Zakelijke gebruikers - de zakelijke gebruikers moeten voortdurend betrokken zijn om ervoor te zorgen dat ze zich het toekomstige systeem eigen maken.

2. User Requirements - de business moet de scope bepalen; wees niet bang om huidige processen te heroverwegen in plaats van een nieuwe versie te bouwen van wat je al hebt.

3. Projectmanagement - zelfs als de leverancier zijn implementatie projectmanagement uitvoert, moet u uw betrokkenheid projectmanagement uitvoeren - u moet bij elk project betrokken zijn om er zeker van te zijn dat u de oplossing in de toekomst kunt beheren.

4. IT - IT moet zich erbij aansluiten om je te voorzien van de infrastructuur en ondersteuning tijdens het project.

Dus realistisch gezien zul je, voor het project of op permanente basis, een multidisciplinair team of 'kenniscentrum' opzetten op basis van een gedeeld servicemodel, ter ondersteuning van de oplossing. CPM-oplossingen moeten mee evolueren met het veranderende bedrijf en dit team zal daartoe in staat zijn.

Navigatie op hoogdimensionale gegevens - Strategieën voor eindgebruikers

Een van de uitdagingen van hoogdimensionale data is de navigatie voor eindgebruikers - de mogelijkheid om je data te analyseren op dag, SKU, klant en nog 10 andere dimensies is erg krachtig, maar zal uiteindelijk eindigen met veel lege cellen, of nul data als de sparsity tot in de miljardste procent of minder van de gevulde cellen reikt.

Wat je uiteindelijk moet doen, is de toegang van de gebruiker tot de gegevens controleren of de gegevens die beschikbaar worden gesteld aan elke gebruiker beperken. Dit klinkt misschien hetzelfde, maar er is een subtiel verschil.

Als u uitgaat van één grote gegevenskubus, kunt u door een uitgebreid beveiligingsmodel toe te voegen dat is gebaseerd op groepen, de gegevens in die kubus beperken die beschikbaar zijn voor eindgebruikers. Normaal gesproken is een groep gebaseerd beveiligingsmodel 'additief' (d.w.z. als een gebruiker lid is van meer dan één groep, dan krijgt hij toegang van beide groepen samen). Hierdoor kun je groepen instellen voor toegang tot producten, klanten, regio's, versies, afdelingen of iets anders, en vervolgens de gebruikers meerdere groepen geven om hun toegang te definiëren. Als gebruikers verschillende toegang nodig hebben, kunnen ze gewoon worden toegevoegd aan/verwijderd uit groepen en je kunt zelfs een groep hebben voor alleen-lezen/schrijven om snel gegevenstoegang te verlenen of te verwijderen. Uiteindelijk kun je zo'n complex of eenvoudig beveiligingsmodel maken als je zelf wilt.

De tweede methode bestaat uit het maken van subkubussen van de master kubus, die veel minder dimensies en veel minder gegevens kunnen hebben. Het voordeel van kleinere kubussen zijn de prestaties, eenvoud en flexibiliteit. In producten zoals Prophix is het maken van een kleine kubus met een subset van gegevens een eenvoudige taak voor zakelijke gebruikers, zodat kubussen kunnen worden gebouwd, verwijderd, op een ad-hoc basis. Sommige grotere retailmodellen hebben dagelijkse kubussen, wekelijkse kubussen, periodekubussen voor voorraad- en verkoopinformatie op basis van de verschillende behoeften van hun gebruikers. Nogmaals, de daadwerkelijke implementatie zal afhangen van je behoeften.

-

Dus, samengevat, doe het! Navigeer door de politiek, begrijp wat je probeert te bereiken en ontwerp je modellen om de gegevens op een gebruiksvriendelijke en krachtige manier aan de gebruikers te leveren.