Vilka processer är värda att automatisera och hur du känner igen dem

Fyra frågor som du kan sålla det dagliga arbetet med själv: är det en kedja med ett resultat, tar maskinen emot data eller en bild, avgör steget något om en människa, och har processen redan en yttre tidsfrist.

Frågan ”vad bör vi automatisera” ställs vanligtvis för sent, för den förutsätter att svaret är en lista med verktyg. I praktiken har merparten av de misslyckade automatiseringsprojekten börjat med rätt verktyg, som lades ovanpå ett felvalt arbete, och det var just valet, inte verktyget, som avgjorde resultatet.

Den här artikeln försöker inte definiera vad automatisering av affärsprocesser är, för definitionen avgör ingenting; i stället ger den fyra frågor som du kan sålla det dagliga arbetet med själv, och efter varje fråga visar den hur ett fall som klarar den ser ut, och ett som inte gör det. Sållningen kostar ingenting och tar en eftermiddag, men sparar betydligt mer än vilken verktygsjämförelse som helst, för den svarar på den tidigare frågan i kedjan.

Första frågan: är det en kedja med ett resultat eller en rad klick

Det här är den gräns som avgör mest, och den är värd att dra precis: process är en kedja av handlingar som har indata, ett utfall och en ägare: att utfärda en faktura från en order, att ta emot en ny medarbetare, en kundförfrågans väg från formulär till svar. Procedur eller en enskild handling är hur ett visst steg görs: var du ska klicka, vad du ska kopiera, i vilket fält numret ska läggas.

Båda kan automatiseras, men utbytet skiljer sig flera gånger om, och just därför är ordningen viktig: om du automatiserar kedjan ändrar du resultatet — dokumentet når bokföringen av sig självt, och ingen för över det för hand längre. Om du automatiserar en rad klick snabbar du upp ett steg i en kedja vars övriga del förblir densamma, och vinsten är precis så stor som den andel det enda steget utgjorde.

Det praktiska sättet att känna igen det är helt enkelt att fråga vad som händer med resultatet efteråt, och svaret säger vanligtvis allt: om det är ”då tar någon den här filen och lägger den i ett annat system”, då fortsätter kedjan och att automatisera ett steg betyder att flytta flaskhalsen, inte att ta bort den. Om svaret är ”då är arbetet klart och resultatet finns i systemet”, då har du en process med en tydlig slutpunkt, och just sådana är de som är värda att ta först.

Låt oss ta en typisk kedja och följa den till slutet, för just följandet visar var vinsten faktiskt ligger: kunden fyller i ett formulär på webbplatsen, ansökan kommer till mejlen, någon knappar in den i kundsystemet, någon annan tar fram en offert, och efter godkännandet utfärdar ännu någon en faktura i bokföringsprogrammet. Här finns en process med ett tydligt resultat (från ansökan till faktura), och i den finns minst tre ställen där samma data knappras in på nytt, varje gång med möjlighet att det blir fel.

Om du från den här kedjan bara automatiserar den manuella inmatningen av ansökan till kundsystemet är vinsten verklig, men liten, för de andra två inmatningarna finns kvar. Om du automatiserar hela kedjan ändras själva arbetets karaktär: människan knappar inte in på nytt, utan kontrollerar och fattar beslut där de verkligen behövs. Just därför är kedjans gränser värda att rita upp före varje verktygssamtal, för de avgör hur stor den möjliga vinsten är.

Kedjan har också en ägare, och det är en fråga som ofta inte blir ställd. Om ingen konkret person kan säga hur processen går från början till slut, då blir automatiseringen en rad antaganden om hur den nog går till, och det första verkliga fallet kommer att slå sönder de antagandena. Att hitta ägaren tar vanligtvis ett samtal, men sparar flera veckor, så det är den billigaste delen av projektet.

Andra frågan: tar maskinen emot data eller en bild

Det här är den viktigaste tekniska skillnaden i hela automatiseringen, och i Sverige har den också en rättslig sida. Om systemet tar emot strukturerade data (XML, JSON, en post i en databas) kan det behandla dem utan att gissa. Om det tar emot en bild, det vill säga en PDF-fil eller ett inskannat blad, då måste någon före behandlingen gissa vad som står där, och just den gissningen skapar fel som någon senare rättar för hand.

Fakturaexemplet visar det bäst, för där finns båda möjligheterna sida vid sida och kallas nästan likadant. En strukturerad e-faktura, i vardagen också kallad e-faktura, är ett maskinläsbart dokument i ett bestämt format — i Sverige ska den överensstämma med den europeiska standarden EN 16931, och Upphandlingsmyndigheten rekommenderar profilen Peppol BIS Billing 3. Mottagarens system kan bokföra den utan att en människa är med, och därför är just det formatet det som de lagstadgade tidsfristerna gäller.

En PDF-faktura som mottagaren har godkänt att ta emot elektroniskt är också en giltig handling: mervärdesskattelagen 17 kap. 20 § tillåter att en elektronisk faktura utfärdas bara om mottagaren godkänner det. Men giltig är den som elektronisk faktura i momslagens mening, inte som e-faktura, och för maskinen är den fortfarande en bild.

Därav följer en slutsats som sparar mycket pengar: att känna igen PDF-fakturor med OCR (optisk teckenläsning) är inte att införa e-faktura. Det är en separat handling som människor med rätta automatiserar, för den minskar den manuella inmatningen, men den skapar inget strukturerat dokument och uppfyller inte skyldigheten att utfärda ett. Ett företag som räknar OCR som svaret på det lagstadgade kravet upptäcker efter ett par år att det har automatiserat fel ände, och då måste projektet börja om med det system som utfärdar fakturorna, inte med det som tar emot dem.

Det praktiska sättet att kontrollera här är enkelt: fråga i vilket format systemet kan lämna ut data och ta in dem. Om svaret är ”det går att exportera CSV” är det redan strukturerade data, bara ofullständigt automatiserade. Om svaret är ”det går att skriva ut” eller ”det går att spara som PDF”, då är bilden den enda utdata, och det fortsatta arbetet kräver antingen ett programmeringsgränssnitt eller blir gissning.

Det är också värt att veta att svaret ofta är bättre än företaget tror, för många bokförings- och lagerprogram har ett gränssnitt, bara att ingen någonsin har frågat, för det dagliga arbetet klarar sig med export. En fråga till leverantören om systemet har ett programmeringsgränssnitt (API) och vad som går att göra med det avgör ofta om projektet över huvud taget är värt att starta.

Tredje frågan: avgör steget något om en människa

Merparten av automatiseringen är att flytta siffror mellan system, och där finns inga särskilda juridiska frågor. Det finns dock en grupp steg som måste kännas igen för sig: de steg som avgör något om en konkret människa — om hen ska anställas, om hen ska få kredit, om hen ska sägas upp, om hen ska få ett bidrag.

Artikel 22 i dataskyddsförordningen om automatiserat individuellt beslutsfattande, inbegripet profilering, slår fast att den registrerade har rätt att inte bli föremål för ett beslut som enbart grundas på automatiserad behandling och som har rättsverkan eller på liknande sätt i betydande grad påverkar hen. Undantag finns (nödvändigt för avtal, lag med skyddsåtgärder, uttryckligt samtycke), men även då kvarstår rätten till mänsklig inblandning, att få uttrycka sin åsikt och att bestrida beslutet. Tillsynsmyndigheternas vägledning tillägger en viktig nyans: den mänskliga inblandningen måste vara meningsfull, och en formell godkännandeknapp som någon trycker på utan att se på innehållet tar inte processen ur artikel 22.

Det är inget förbud mot att automatisera, utan en anvisning om vad som just i en sådan process går att automatisera: du kan automatisera det förberedande arbetet (att samla in data, kontrollera, ta fram ett förslag), men själva beslutet stannar hos den människa som faktiskt fattar det. Praktiskt ändrar det projektets omfattning, så det är värt att se före utvecklingen, inte efter.

Vid sidan av det är det värt att känna till en tidsfrist som ännu inte har infallit, men som påverkar de långsiktiga planerna: AI-förordningens krav på högrisksystem på anställningsområdet, det vill säga urval och personalbeslut, börjar tillämpas den 2 december 2027. Det betyder att valet i dag är friare, men för ett system som byggs långsiktigt ska det datumet in i planen.

Fjärde frågan: har processen redan en yttre tidsfrist

För en del processer sätts tidsfristen inte av företagets prioriteringar, utan av en yttre skyldighet, och de flyttar sig automatiskt till toppen av listan, för där behöver du inte längre besluta om saken ska göras, utan bara när och hur. I Sverige är det tydligaste exemplet återigen fakturor, och där finns tre olika datum som brukar blandas ihop.

För det första ska ett företag som utfärdar en faktura till en upphandlande myndighet eller enhet använda det strukturerade formatet redan sedan den 1 april 2019. För det andra blir samma strukturerade format obligatoriskt för gränsöverskridande handel mellan företag inom EU från och med den 1 juli 2030. För det tredje börjar någon skyldighet att utfärda en strukturerad faktura till ett annat svenskt företag inte vid ett beslutat datum — en statlig utredning ska redovisa senast den 30 november 2027 om inhemsk e-faktura ska införas, och fram till dess är e-faktura mellan företag frivillig.

Just det tredje datumet är det som i det offentliga samtalet oftast är fel, och det har ett enkelt skäl: EU-datumet för gränsöverskridande handel läses som om det vore ett svenskt inhemskt krav, och en del sekundära artiklar har redan satt ut ett år. För ett företag som planerar budget är skillnaden mellan ett verkligt datum och ett gissat stor, så datumet är värt att kontrollera i förstahandskällan, inte i ett återberättande.

Yttre tidsfrister finns också på andra håll: övertid, mertid och jourtid ska antecknas, räkenskapsinformation har en sjuårig bevarandetid, och i avtal finns ofta rapportdatum. Det gemensamma är att de här tidsfristerna inte går att förhandla bort, och en process som har en sådan ger ett tydligt skäl till arbetet — till skillnad från en process som automatiseras för att det verkar modernt.

Så ser en process ut som är värd att ta först

Om du slår ihop alla fyra frågorna blir det ett ganska konkret porträtt som du kan lägga mot vilken lista som helst: den värdefullaste första kandidaten är en kedja med ett tydligt resultat, där data redan finns i strukturerad form eller kan bli det, där inget steg avgör något om en människa, och som har en yttre tidsfrist eller åtminstone en mätbar volym.

I praktiken ser det vanligtvis ut så här: en order från webbutiken når bokföringssystemet utan manuell inmatning; en godkännandekedja där ansökan går till rätt person och kommer tillbaka med en markering; datasynkronisering mellan lager och webbplats, där en människa i dag exporterar en fil två gånger om dagen. I alla tre finns ett gemensamt tecken — mellan två system går det i dag en människa med en fil.

Just det tecknet är lättast att lägga märke till och svårast att glömma, så det är värt att börja inventeringen med. Skriv ner var i ditt företag någon exporterar, kopierar in eller knappar in på nytt, hur ofta och hur länge. Den här listan är vanligtvis kortare än väntat, och i den finns nästan alltid en post som sticker ut.

Ett andra tecken som lyfter fram en kandidat är priset på felet, och det brukar utelämnas i kalkylerna: om ett inmatningsfel i den här kedjan betyder en felaktig faktura till kunden, ett felaktigt lagersaldo eller en missad tidsfrist, då är vinsten av automatiseringen inte bara de sparade timmarna, utan också de fel som undviks, och det är vanligtvis det större av de två talen. En process där felet är omärkligt och harmlöst är i det avseendet en mindre värdefull kandidat, även om den tar lika mycket tid.

Ett tredje tecken är hur volymen ändras med företaget, och det är det viktigaste av de tre: ett arbete som växer med företaget, för fler order betyder mer inmatning för hand, blir med tiden allt dyrare, och just där lönar sig automatiseringen dubbelt: den frigör tid i dag och tar bort en kostnad som annars skulle ha vuxit. Ett arbete med oförändrad volym oberoende av omsättningen ger inte den andra vinsten.

Till porträttet är det värt att lägga en sak om ordningen, för där felar företagen oftare än i valet av verktyg: den första automatiserade processen ska inte väljas efter vilken som är störst eller mest smärtsam, utan efter vilken som är bäst förstådd och snabbast att bli klar med, för det första projektet lär företaget hur sådana projekt över huvud taget går till — hur undantag beskrivs, hur det testas och hur fel hanteras. Den lärdomen är mycket billigare att få på ett enkelt arbete än på det som kassaflödet hänger på.

Så ser en process ut som inte är värd att ta först

Lika nyttigt som att känna igen en bra kandidat är att känna igen det som ser lockande ut men lönar sig dåligt, och sådana fall är fyra. Det första är ett arbete som sker sällan (en gång i kvartalet eller en gång om året), för utvecklingskostnaden förblir densamma, men besparingen delas med fyra eller med ett.

Det andra är en process vars ordning fortfarande ändras, och det är fallet där brådskan kostar mest: om ordningen det senaste halvåret har ändrats tre gånger, då kommer automatiseringen att låsa den version som ändå snart blir en annan, och förvaltningen äter upp vinsten. Här är den rätta ordningen att först komma överens om hur det ska gå till och först därefter automatisera, även om det i praktiken brukar ske tvärtom.

Det tredje är ett arbete där varje fall är ett undantag, och där ligger gränsen i själva uppgiftens natur, för automatisering klarar det vanliga och förutsägbara bra, men dåligt en situation där tio fall har tio olika vägar; där är människans omdöme själva arbetet, och att ersätta det med ett regelträd skapar vanligtvis fler undantag än det tar bort.

De här tre fallen förenas av ett tecken: där låser automatiseringen något som ännu inte är redo att låsas. Det sällsynta arbetet är inte tillräckligt genomarbetat för att vara värt att hugga i sten; den föränderliga processen söker fortfarande sin form; undantagsarbetet är till sin natur omdöme. I alla tre är den rätta handlingen att vänta eller först städa, inte att automatisera fortare.

Det fjärde är fallet där skärmen imiteras därför att systemet saknar gränssnitt. Det är ibland den enda möjliga vägen, men det är också den sköraste: det räcker med en ändring på skärmen, så stannar arbetet. Om systemet har ett programmeringsgränssnitt eller om det kan begäras, är det nästan alltid ett förmånligare val än att imitera skärmen.

Vad händer med människorna vars arbete automatiseras

Den här frågan brukar automatiseringsförslag gå runt, även om den i företaget ställs redan första dagen, och obesvarad blir den ett tyst motstånd som kan stoppa projektet säkrare än något tekniskt problem. Det ärliga svaret i de flesta små och medelstora företag är att automatiseringen frigör tid, inte en människa: den manuella inmatningen är den del av arbetet som ingen vill ha, och när den försvinner betyder det vanligtvis att samma människa äntligen hinner göra det som det tidigare inte fanns tid för.

Därav följer en praktisk rekommendation som låter mjuk, men är en ren projektledningsfråga: den människa som gör arbetet i dag ska tas med i projektet som den mest kunniga källan, inte informeras om resultatet. Hen känner undantagen som ingen har skrivit ner, och just undantagen är det som slår sönder automatiseringen. Ett projekt där det samtalet sker i början kostar mindre än ett där det sker efter det första felet.

Det är också ärligt att säga den andra sidan, för motsatsen skulle vara att låtsas: om någons arbete i företaget helt består av att föra data mellan två system, då ersätter automatiseringen verkligen det arbetet, och det är ett samtal om att byta roll, som företagets ledning leder, inte leverantören. Ett förslag som inte ställer den här frågan alls är inte finkänsligt — det är helt enkelt inte tänkt till slutet.

Så räknar du fram ditt eget tal

Kalkylen som behövs för beslutet ryms på ett blad och kräver varken en konsult eller en undersökning. Det som behövs är fyra tal: hur många gånger i veckan det här arbetet sker, hur många minuter det tar varje gång, vad en timme kostar för den människa som gör det, och hur ofta det uppstår ett fel som någon sedan rättar.

De första tre ger den direkta tidskostnaden per år, och det talet är vanligtvis mindre än väntat — just därför lyckas det ofta inte att grunda projektet bara på det. Det fjärde talet är det som mest avgör, för priset på felet är sällan bara tiden att rätta det: en felaktig faktura betyder korrespondens med kunden, ett felaktigt saldo betyder antingen en vara som blir osåld, eller en beställning av en vara som inte längre finns i lagret, och en missad tidsfrist betyder ibland vite.

Mot de här talen ställer du utvecklingskostnaden och förvaltningen, och just förvaltningen är det som glöms. En automatisering som kopplar ihop två system är levande så länge båda gränssnitten är levande, så i planen måste det finnas rum för ändringar som någon annan kommer att kräva. Om kalkylen bara lönar sig när förvaltningskostnaden inte räknas in, då lönar den sig i själva verket inte alls.

En sak till som är värd att reda ut före samtalet är hur ofta systemen ändras. En molntjänst som uppdaterar sig själv kan ändra gränssnittet utan förvarning, medan ett program installerat på plats förblir oförändrat i åratal, men uppdateringen av det kräver någon gång att allt kontrolleras på nytt. Ingen av de två varianterna är sämre, men de kräver olika förvaltningsplaner, och ett förslag som inte återspeglar det kommer att vara för billigt just där kostnaderna senare uppstår.

Varför du inte ska lita på procent från undersökningar

I automatiseringsförslag dyker det nästan alltid upp ett tal: att hälften av arbetet kan automatiseras, att projekt faller i en tredjedel av fallen, att någon sparade tiotusentals timmar. De här talen finns och går att citera, men de beskriver nästan aldrig det företag de visas för, och just det gör dem till en dålig grund för ett beslut.

Det brett citerade måttet om att en stor del av aktiviteterna går att automatisera är en kalkyl om aktiviteter i lönemassan i ett visst land och ett visst år, med det årets teknik, och det publicerades av ett konsultföretag som säljer just den här tjänsten. Måttet om projektmisslyckanden kommer från en konsults erfarenhet med kunder som kallade in honom efter de första misslyckandena, så urvalet är skevt redan per definition. Talet om sparade timmar beskriver en konkret ekonomiavdelning på fyrtio personer i ett annat land för flera år sedan.

Därav följer inte att automatisering inte lönar sig, utan att det rätta talet är ditt eget: hur många gånger i veckan det här arbetet sker, hur länge det tar och vad en timme kostar. Den kalkylen kan du göra på ett blad, den beskriver just ditt företag, och den är den enda som det är värt att grunda ett beslut på.

Vad du behöver veta om systemen innan du begär en offert

När kandidaten är vald är nästa steg inte att begära en offert, utan fem minuters undersökning av själva systemen, för just det avgör om samtalet med utföraren kommer att handla om en lösning eller om en möjlighet. Ta reda på om varje inblandat system har ett programmeringsgränssnitt, om det är tillgängligt på din licensnivå och om leverantören tar extra betalt för det, för alla tre svaren brukar skilja sig åt.

Den andra frågan är vem som lagrar data och vem som får ändra dem. Om två system innehåller samma information, till exempel kunduppgifter eller varans lagersaldo, då ska du före kopplingen besluta vilket av dem som är huvudsystem, för annars kommer automatiseringen att börja skriva över båda ömsesidigt och resultatet blir sämre än före. Det beslutet är gratis om det fattas i början, och dyrt om det upptäcks under testningen.

Den tredje är frågan om vad som händer när något inte går. I varje automatisering finns fall som inte går igenom (ett fält saknas, systemet svarar inte, data strider mot varandra), och de behöver en plats att hamna på, och en människa som tittar på dem. En automatisering utan felhantering fungerar så länge allt är i sin ordning, och det är aldrig länge.

Det är också värt att i förväg besluta efter vad du ska bedöma om det lyckades, för utan det tar projektet aldrig slut, utan det bara avbryts. Måttet kan vara helt enkelt: hur många gånger i månaden någon fortfarande för över data för hand, hur många fel som rättades förra månaden och hur länge en ansökan går från formulär till svar. Det talet är värt att mäta en gång innan arbetet börjar, så att det senare finns något att jämföra med. Företag som inte gör den mätningen bråkar efter ett halvår om huruvida något över huvud taget förändrades.

Till sist är det värt att minnas att automatisering inte är ett engångsarbete, utan något som blir kvar i företaget och kräver en ägare precis som vilket annat system som helst. När processen är kopplad måste någon veta var hen ska titta om den stannar, och någon måste ha rätt att stoppa den om resultatet ser fel ut. I företag där den rollen inte är namngiven slutar automatiseringen tyst att fungera, och det märks först efter en månad, när någon letar efter ett försvunnet dokument.

Vad du ska börja med i praktiken

Början är varken valet av verktyg eller att begära en offert, utan en vecka där det skrivs ner vad som händer: vilket arbete som upprepas, hur ofta, hur länge och var i det en människa för data mellan system. Därefter ställer du de fyra frågorna i den här artikeln till varje post, och merparten av listan faller bort redan efter de två första.

Kvar blir vanligtvis en eller två kandidater, och det är bra, för just så många är det också värt att starta samtidigt: två avslutade arbeten ger mer än sex påbörjade. När kandidaten är vald är nästa steg att ta reda på om de inblandade systemen har programmeringsgränssnitt, för det avgör både priset och lösningens hållbarhet.

Om det i det här läget är klart vilken process som är din, men inte hur den ska kopplas, kan det diskuteras med oss: automatisering av affärsprocesser i vårt utförande är integrationer och arbetsflöden mellan system som du redan har. Om du först vill förstå vad som skiljer de olika angreppssätten och verktygsgrupperna, skriv till oss eller skicka din lista — ofta är svaret att det räcker med en koppling, inte med en plattform.