I båda fallen beslutar sig företagen för att minimera omfattningen av projekten, för att minska kostnad, risk och arbetsbörda. Båda företagen beslutar sig för att ”ta sitt bästa system” och standardisera på det över hela linjen.
Problemet är att man i inget av fallen har ett realistiskt business case. Företag A bestämmer sig för att strunta i att göra business case och fokuserar på att realisera de besparingar man har kunnat identifiera (främst mjukvarulicenser och konsolidering). Företag B går igenom business case-processen, men hela 25 procent av ”vinsterna” kan aldrig räknas hem.
Såväl företag A som B önskar i efterhand att de inte hade minimerat omfattningen av projektet, utan istället ”gjort jobbet ordentligt”. De var nämligen kvar i samma ineffektiva processer som förut, men nu förstärkta och cementerade till en kostnad av tiotals miljoner dollar.
De hade missat sina chanser att snabba upp processer, och eftersom de ”nya” systemen var designade för det gamla paradigmet var det för dyrt att driva hem vinsterna i efterhand.
Insikt: Fokus ska inte ligga på att hålla nere risk och kostnad. Fokus ska ligga på nettovinst och möjligheten att räkna hem den.
System är automatiserade processer. Förenklar du en process kan du ofta få bort så mycket som hälften av stegen. Det motsvarar 20 procent i minskad implementationskostnad. Hade de här företagen rationaliserat ekonomiprocesserna i förväg skulle projekten troligen ha blivit billigare, och vinsterna större. Att minimera omfattningen är falsk ekonomi, och det kan stjälpa hela projekt.
I vårt exempel skulle man ha börjat med att inventera alla ekonomiprocesser och de relaterade systemen, och slå fast hur man ville sköta ekonomin i framtiden – i processtermer. Det är omfattningen på problemet. Först när den är klargjord blir det möjligt att få ett brett perspektiv och se var det finns mest att vinna.
Processförenklingen borde sedan ha drivits av förbättringsmål – till exempel införandet av tvådagars månadsbokslut med halverad AR-summa och halverad arbetsbörda med AP.
Projektteamet skulle ha jobbat med verksamheten för att definiera nya ekonomiprocesser och se vad systemen kunde bidra med.
Bara för att du har definierat hela processflödena betyder det inte att man måste implementera varje förbättring.
Alltså: Med en rätt gjord processförenkling ser du var du ska sätta in insatserna. Då kan omfattningen bli den optimala, samtidigt som det är känt varför vissa områden inte omfattas.
Problemet är att man i inget av fallen har ett realistiskt business case. Företag A bestämmer sig för att strunta i att göra business case och fokuserar på att realisera de besparingar man har kunnat identifiera (främst mjukvarulicenser och konsolidering). Företag B går igenom business case-processen, men hela 25 procent av ”vinsterna” kan aldrig räknas hem.
Såväl företag A som B önskar i efterhand att de inte hade minimerat omfattningen av projektet, utan istället ”gjort jobbet ordentligt”. De var nämligen kvar i samma ineffektiva processer som förut, men nu förstärkta och cementerade till en kostnad av tiotals miljoner dollar.
De hade missat sina chanser att snabba upp processer, och eftersom de ”nya” systemen var designade för det gamla paradigmet var det för dyrt att driva hem vinsterna i efterhand.
Insikt: Fokus ska inte ligga på att hålla nere risk och kostnad. Fokus ska ligga på nettovinst och möjligheten att räkna hem den.
System är automatiserade processer. Förenklar du en process kan du ofta få bort så mycket som hälften av stegen. Det motsvarar 20 procent i minskad implementationskostnad. Hade de här företagen rationaliserat ekonomiprocesserna i förväg skulle projekten troligen ha blivit billigare, och vinsterna större. Att minimera omfattningen är falsk ekonomi, och det kan stjälpa hela projekt.
I vårt exempel skulle man ha börjat med att inventera alla ekonomiprocesser och de relaterade systemen, och slå fast hur man ville sköta ekonomin i framtiden – i processtermer. Det är omfattningen på problemet. Först när den är klargjord blir det möjligt att få ett brett perspektiv och se var det finns mest att vinna.
Processförenklingen borde sedan ha drivits av förbättringsmål – till exempel införandet av tvådagars månadsbokslut med halverad AR-summa och halverad arbetsbörda med AP.
Projektteamet skulle ha jobbat med verksamheten för att definiera nya ekonomiprocesser och se vad systemen kunde bidra med.
Bara för att du har definierat hela processflödena betyder det inte att man måste implementera varje förbättring.
Alltså: Med en rätt gjord processförenkling ser du var du ska sätta in insatserna. Då kan omfattningen bli den optimala, samtidigt som det är känt varför vissa områden inte omfattas.
Gratis nyhetsbrev
