Om en kille

En verklig historia, jag har sett allt med egna ögon.

I flera år arbetade en kille, precis som många av er, som programmerare. För säkerhets skull skriver jag så här: "programmerare". För han var en 1C-specialist, anställd i ett produktionsföretag.

Innan dess hade han provat olika yrken – 4 år som programmerare i franchise, projektledare, kunde stänga 200 timmar och samtidigt få procent från projektet, för ledarskap och lite försäljning. Han försökte utveckla produkter själv, var IT-chef i ett stort företag med 6 000 anställda, och testade olika sätt att tillämpa sin ”specialitet” – 1C-programmerare.

Men alla dessa positioner var lite av en återvändsgränd, framför allt vad gäller inkomster. Vi fick alla ungefär samma pengar och jobbade under liknande förhållanden.

Denna kille blev intresserad av hur man kunde tjäna mer pengar, utan att sälja eller starta eget företag.

Han trodde att han var smart och beslutade att hitta en nisch i det företag där han arbetade. Denna nisch borde vara något speciellt, som ingen annan tog. Och han ville att företaget självmant skulle vilja betala pengar till en person i denna nisch, så att ingen behövde ljuga eller manipulera. Det skulle vara objektivt: man måste betala mycket pengar för den här positionen. En galning, med andra ord.

Sökandet var kortvarigt. I företaget där denna kille arbetade fanns det en helt fri nisch som man skulle kunna kalla "organisering av affärsprocesserna". I varje företag finns det massor av problem. Något fungerar alltid inte, och det finns ingen som kommer och åtgärdar affärsprocesserna. Så han beslutade att pröva sig själv som specialist som kan hjälpa ägaren att lösa sina problem i affärsprocesserna.

Vid det tillfället hade han arbetat i företaget i sex månader och fick marknadens genomsnittliga lön. Han hade inget att förlora – särskilt eftersom han lätt skulle kunna hitta ett liknande jobb inom en vecka. Så den här killen resonerade att inget hemskt skulle hända om det plötsligt inte skulle fungera och han blev uppsagd.

Han samlade mod och gick till ägaren. Han föreslog att förbättra den mest problematiska processen i verksamheten. Vid den tidpunkten var det lagerhanteringen. Nu skäms alla som arbetar i detta företag till och med för att minnas dessa problem, men de kvartalsvisa inventeringarna visade avvikelser mellan bokföringssystemet och de faktiska lagernivåerna med tiotals procent. Både när det gällde värde, mängd och antalet artiklar. Det var en katastrof. Företaget hade faktiskt korrekta lagernivåer i bokföringssystemet endast fyra gånger om året – dagen efter inventeringen. Denna process var vår kille ansvarig för att få ordning på.

Killen kom överens med ägaren om att han skulle minska avvikelserna från inventeringarna med hälften. Dessutom hade ägaren inte mycket att förlora, eftersom olika anställda redan hade försökt åtgärda det innan vår hjälte, och uppgiften ansågs i princip vara oöverkomlig. Allt detta ökade intresset, eftersom om det lyckades, skulle killen automatiskt bli någon som kan få ordning och lösa till synes olösliga problem.

Således stod han inför uppgiften: under ett år minska avvikelserna från inventeringarna med 50%. Vid projektets start hade han ingen aning om hur han skulle åstadkomma detta, men han visste att lagerhantering är en enkel sak, så han var säker på att han skulle kunna göra något användbart. Dessutom, att minska avvikelserna från tiotals procent till endast ett par procent verkar inte så svårt. Alla som har arbetat inom rådgivning eller liknande verksamhet förstår att de flesta processproblem kan lösas med ganska enkla åtgärder.

Från januari till maj förberedde han sig, automatiserade lite här och där, omskrev affärsprocessen för lagerredovisning, ändrade arbetsflödena för lagermedarbetare, revisorer och omarbetade hela systemet utan att visa eller berätta för någon. I maj delade han ut nya instruktioner till alla, och efter årets första inventering började ett nytt liv – arbete enligt hans regler. För att observera resultatet började företaget därefter genomföra inventeringar oftare – varannan månad. Redan de första resultaten var positiva, och vid slutet av året föll avvikelserna i revisionsresultaten till delar av en procent.

Framgången var kolossal, men det var svårt att tro på dess hållbarhet. Själv tvivlade killen på att resultatet skulle bestå om han drog sig tillbaka och slutade observera processen. Trots det var resultatet verkligt, och killen fick allt han hade kommit överens om med ägaren. Efter några år bekräftades resultatets hållbarhet – avvikelserna hölls inom en procent under flera år.

Då beslutade han att upprepa experimentet och föreslog ägaren att förbättra en annan problematisk process – försörjningen. Där fanns brister som hindrade leverans av de volymer våra kunder ville ha. De kom överens om att bristerna skulle halveras inom ett år, och killen skulle dessutom genomföra 10-15 projekt relaterade till 1C – för automatisering av olika affärsprocesser och annan nonsens.

Under det andra året lyckades de igen avsluta allt framgångsrikt, bristerna minskade med mer än två gånger, alla IT-projekt slutfördes framgångsrikt.

Eftersom lönen redan helt tillfredsställde alla krav från den killen för två år framåt, bestämde han sig för att stabilisera sig lite, lugna ner sig och sitta på en bekväm, varm plats som han själv hade skapat.

Vad var han egentligen? Formellt var han IT-chef. Men vad han faktiskt var, är svårt att förstå. Vad gör en IT-chef? Vanligtvis administrerar de IT-infrastrukturen, leder systemadministratörer, implementerar ERP-system, deltar i styrelsemöten.

Denna kille hade en av sina nyckeluppgifter i att delta i förändringsprocesser, och i huvudsak — generera och initiera dessa processer, leta efter och föreslå lösningar, tillämpa nya ledningsmetoder, granska föreslagna förändringar, analysera effektiviteten hos andra funktioner och avdelningar, och slutligen — delta direkt i företagets strategiska utveckling, ända till att självständigt utveckla strategiska planer för hela företaget.

Han fick fria händer. Han kunde delta i vilket möte som helst där han tidigare inte hade haft tillgång. Han satt där med en anteckningsblock, antecknade något eller lyssnade bara. Han pratade sällan. Sedan började han spela på mobilen — han påstod att det hjälpte den associativa minnet att arbeta bättre.

På möten gav han sällan något användbart. Han gick, funderade, och sedan kom ett mejl — antingen med kritik, eller en åsikt, eller förslag, eller en beskrivning av lösningar som han redan hade tillämpat.

Men oftare drog han samman möten själv. Han hittade ett problem, kom på lösningsalternativ, identifierade intressenter och drog in alla i förhandlingsrummet. Där gjorde han det han kunde. Han övertygade, motiverade, bevisade, diskuterade, kämpade.

Inofficiellt ansågs han vara tredje parten i företaget, efter ägaren och direktören. Naturligtvis irriterade han alla 'företagsansikten', börja med nummer 4. Särskilt med sina trasiga jeans och färgglada t-shirts, samt ägarens tid.

Ägaren avsatte en timme om dagen till honom. Varje dag. De pratade, diskuterade problem, lösningar, nya affärer, utvecklingsriktningar, indikatorer och effektivitet, personlig utveckling, böcker, och bara — livet.

Men den här killen var konstig. Det verkade som att han skulle sitta och njuta av livet. Men nej. Han bestämde sig för att reflektera.

Han blev nyfiken: varför lyckades just han, medan andra inte gjorde det? Ägaren pushade också honom: han sa att han ville att andra också skulle lyckas skapa ordning, eftersom det finns många chefer. De sysslar som regel med dagligt ledarskap och strategisk planering, men praktiskt taget ingen jobbar med systemiska förändringar av sina processer. I deras befattningsbeskrivning kanske det står att de ska snabba upp sina processer och öka deras effektivitet, men i verkligheten gör ingen det. Varför är det så? Den här killen blev också nyfiken på varför, och han gick för att prata med alla dessa chefer.

Han kom till kvalitetssamordnaren och föreslog att införa Shewhart-diagram för att produkten skulle bli bättre än den japanska. Men det visade sig att kollegan inte visste vad Shewhart-diagram var, vad statistisk processtyrning var, och han hade bara hört lite grann om tillämpningen av Demings cykel i kvalitetsstyrning. Okej...

Han gick till en annan ställföreträdande direktör och föreslog att införa controlling. Men inte här heller fick han stöd. Lite senare fick han veta om gränshantering (boundary management) och föreslog att alla ställföreträdande direktörer skulle införa den systematiska delen av denna metod för att förbättra processerna. Men hur mycket han än pratade, ville ingen egentligen förstå vad det handlade om. Kanske var det ointressant för dem eller för svårt. Men i praktiken förstod ingen.

I allmänhet berättade han allt han visste och hade tillämpat i företaget. Men ingen förstod honom. Även nu förstår de fortfarande inte varför, till exempel, allt gick att rätta till i lagerredovisningen, vad controlling och gränshantering har med saken att göra.

Som sista steg vände han sig till sina programmerare – det fanns tre stycken i teamet. Han berättade om gränshantering, om controlling, om kvalitetsledning, om agile och scrum... Och till hans förvåning förstod de alla, och kunde till och med diskutera med honom, inklusive tekniska och metodiska detaljer. De förstod varför projekten för lagret och inköp lyckades. Och då insåg killen: i själva verket kommer programmerarna att rädda världen.

Programmerarna, förstod han – de är de enda som verkligen kan förstå affärsprocesserna på rätt detaljerad nivå.

Varför just de? I själva verket lyckades han aldrig hitta något entydigt svar. Han formulerade bara vissa antydningar.

För det första känner programmerarna till de affärsområden som företaget arbetar inom, och de känner dem bättre än någon annan i företaget.

Dessutom förstår programmerarna verkligen vad som är en processalgoritm. Detta är viktigt eftersom affärsprocesser är algoritmer, och elementen i dem kan vara rent oeniga. Till exempel, i processen för inköp, som killen arbetade med, är första steget att upprätta en årlig inköpsplan, och det andra är dagliga inköp. Dessa steg är kopplade med en direkt koppling, vilket innebär att människorna förväntas arbeta enligt denna algoritm – att upprätta en årlig inköpsplan och omedelbart uppfylla beställningen. Den årliga inköpsplanen upprättas en gång om året, medan beställningar kommer in 50 gånger om dagen. Denna algoritm tar slut här, och man måste arbeta med den. I själva verket, resonerade han, för programmerare är kunskapen om algoritmer en konkurrensfördel, eftersom vem som helst annan som inte är bekant med dem helt enkelt inte förstår hur en affärsprocess ska fungera och hur detta kan avbildas.

En annan fördel med programmerare, enligt killen, är att de har tillräckligt med fritid. Vi förstår alla hur en programmerare kan ägna tre gånger så mycket tid till en uppgift än vad den egentligen kräver, och få märker det. Detta är återigen en konkurrensfördel, för att kunna få en affärsprocess i ordning krävs det mycket fritid – att tänka, observera, studera och prova.

Bland de flesta chefer, enligt killen, finns detta fria tid inte, och de är stolta över det. Även om det faktiskt innebär att en människa inte kan bli effektiv, eftersom de inte har tid att öka sin effektivitet – en ond cirkel. I vår kultur är det trendigt att vara upptagen, därför står allt still. Men för oss programmerare är detta en fördel. Vi kan hitta ledig tid och tänka över allt.

Programmerna, sa han, kan snabbt byta informationssystem. Detta är inte tillämpligt på alla företag, men där han har arbetat var det alltid möjligt att göra alla ändringar som kändes rätt. Särskilt om de inte berör någon annans arbete. Till exempel kunde han starta ett system som hemligt mäter användarnas aktiviteter och sedan använda den informationen för att analysera effektiviteten hos exempelvis bokföringen och spåra kostnaderna för redovisningen.

Och det sista jag minns från hans ord - programmerare har tillgång till en stor mängd information eftersom de har administrativ åtkomst till systemet. Därför kan de använda denna information i sin analys. Ingen annan på ett vanligt företag har en sådan resurs.

Och sen gick han. Under den avtalade två veckor långa uppsägningstiden fick vi honom att dela med sig av sin erfarenhet, eftersom vi ville fortsätta med det arbete han hade gjort. Och hans position blev förstås vakant.

Under några dagar satte vi honom på en stol, slog på kameran och spelade in hans monologer. Vi bad honom berätta om alla genomförda projekt, metoder, angreppssätt, framgångar och misslyckanden, orsaker och konsekvenser, porträtt av chefer osv. Vi satte inte många begränsningar eftersom vi inte visste vad som rörde sig i hans huvud.

I monologerna fanns det förstås mest struntprat och skratt - han var på gott humör eftersom han lämnade en avlägsen plats för Petersburg. Men var skulle man arbeta i Petersburg? I Gazprom, självklart.

Men vi lyckades få ut något användbart ur hans monologer. Låt mig berätta vad jag minns.

Så, rekommendationer från den killen. Till dem som vill försöka ställa ordning på affärsprocesserna.

För att göra ett sådant arbete måste man först ha en viss nivå av 'kylighet'. Man måste inte vara rädd för att förlora jobbet, inte vara rädd för att ta risker, inte vara rädd för konflikter med kollegor. Han lyckades lätt med detta eftersom han började sin resa efter att ha arbetat i företaget i bara ett halvår och inte hade hunnit komma i kontakt med någon, och inte hade för avsikt att göra det. Han förstod att människor kommer och går, men för honom var hans egna resultat och deras bedömning av företagsägaren viktiga. Hur kollegorna behandlade honom var då inte något som bekymrade honom.

Den andra punkten är att för att arbeta effektivt med detta måste man tyvärr lära sig. Men inte via MBA, kurser eller institutioner, utan på egen hand. Till exempel i mitt första projekt, när det gällde lagret, agerade han intuitivt, visste ingenting, förutom vad "kvalitetsstyrning" innebär.

När han började läsa litteratur om vilka metoder för att öka effektiviteten som finns, upptäckte han de teknologier som han hade använt. Killen tillämpade dem intuitivt, men det visade sig att det inte var hans egen uppfinning; det hade redan skrivits om det för länge sedan. Men han slösade tid, och mycket mer än om han direkt hade läst den rätta boken. Det är viktigt att förstå att när man studerar en specifik metodik, löser inte någon av dem, även den mest avancerade, alla problem i affärsprocessen.

Den andra poängen är att ju fler metodiker du känner till, desto bättre. Till exempel i det gamla Japan fanns Miyamoto Musashi – en av de mest kända svärdskämparna, skaparen av stilen med två svärd. Han studerade vid någon skola hos någon mästare, reste sedan runt i Japan och slogs med olika killar. Om en kille var starkare, stannade hans resande en tid, och Musashi gick i lära. Resultatet blev att han på några år förvärvade färdigheter från olika praktikermästare och skapade sin egen skola, där han lade till något eget. På så sätt fick han en unik skicklighet. Här är det samma sak.

Självklart kan man agera som affärskonsulter. De är egentligen väldigt bra. Men i allmänhet kommer de för att implementera en viss metodik, och de implementerar inte den metodik som behövs för verksamheten. Vi har också haft sådana ledsamma situationer: ingen vet hur man löser problemet och ingen vill tänka på hur det ska lösas. Vi börjar söka antingen på internet eller kallar en konsult, och frågar honom vad som kan hjälpa oss. Konsulten tänker och säger att vi måste implementera teorin om begränsningar. Vi betalar honom för rekommendationen, spenderar pengar på implementeringen, men resultatet är noll.

Varför blir det så här? För att konsulten sa att vi ska implementera ett sådant system, och alla gick med på det. Bra, men en metodik stänger inte alla problem i ens affärsprocess, särskilt om de grundläggande förutsättningarna – våra och de som krävs för att implementera metoden – inte stämmer överens.

I den praktik som killen rekommenderar bör man ta det bästa och implementera det bästa. Inte ta metoder i sin helhet, utan ta deras nyckelfunktioner, tricks och praxis. Och det viktigaste - man måste förstå kärnan.

Låt oss ta skrumm (scrum) eller Agile, sa han som exempel. I sina monologer upprepade killen många gånger att inte alla helt förstår kärnan i skrumm. Han hade också läst boken av Jeff Sutherland, som vissa anser vara "lättläst". För honom verkade den djup, eftersom en av de grundläggande aspekterna av skrumm är kvalitetsstyrning, vilket boken beskriver direkt.

Det står om Toyota Production, om hur Jeff Sutherland visade skrumm i Japan, hur väl det mottogs där och hur nära det var deras filosofi. Och Sutherland berättade om vikten av rollen som skrumm-master, om Deming-cykeln. Skrumm-masterns roll är att ständigt påskynda processen. Allt annat som finns i skrumm - etappvis leverans, kundnöjdhet, en tydlig lista över arbeten under sprinterperioden - är också viktigt, men allt detta måste röra sig snabbare och snabbare. Arbetsinriktningen måste hela tiden öka i de enheter som den mäts i.

Kanske handlar det här om översättning, för vi har översatt boken till "Skrumm - en revolutionerande metod för projektledning", men om man översätter den engelska titeln bokstavligt blir det: "Skrumm - dubbelt så mycket på halva tiden", vilket innebär att även i titeln görs åberopande till hastighet som en nyckelfunktion i skrumm.

När den här killen implementerade skrumm ökade hastigheten dubbelt under den första månaden utan några särskilda förändringar. Han fann punkter för förändringar och modifierade skrumm för att det skulle fungera mycket snabbare. Det enda, som folk skriver på internet, är att de fick ställa sig frågan: "Vi har ökat hastigheten dubbelt, men vad ska vi göra med den hastigheten?". Men det är en helt annan fråga...

Han rekommenderade också personligen flera metoder. Han nämnde dem som grundläggande och centrala.

Den första är boundary management (gränshantering).

Han undervisar detta i "Skolkovo", och det finns inga andra böcker eller material, enligt honom. Han hade turen att delta i en föreläsning av en professor från Harvard som predikar om boundary management, samt att läsa några artiklar i Harvard Business Review om arbetena av Eric Trist.

Boundary management handlar om att kunna se gränser och arbeta med dem. Det finns många gränser, de är överallt — mellan avdelningar, mellan olika typer av arbete, mellan funktioner, mellan operativ och analytisk verksamhet. Att förstå boundary management avslöjar inga högre sanningar, men ger oss möjlighet att se verkligheten i ett annat ljus — genom gränsernas prisma. Och därmed hantera dem — bygga upp där det behövs och ta bort dem där de stör.

Men oftare och mer pratade han om controllingen. Han hade en riktig besatthet för det ämnet.

Controlling, kort sagt, är styrning baserad på siffror. Här, sa han, är varje del av definitionen viktig — både "styrning", och "baserad på", och "siffror".

Vi har, sa han, det dåligt ställt med alla tre delarna av controllingen. Särskilt med tanke på att de är nära sammanlänkade med varandra och med andra delar av affärssystemet.

Det första som är dåligt — siffrorna. De är få och av låg kvalitet.

En stor del av siffrorna tog vi då från informationssystemet 1C. Så, kvaliteten på siffrorna i 1C, påstod han, är undermålig. Åtminstone på grund av möjligheten att ändra data retroaktivt.

Det är tydligt att utvecklarna av 1C inte är skyldiga till detta — de tar bara hänsyn till marknadens krav och vår inhemska redovisningsmentalitet. Men för controllings syften bör principerna för hur 1C arbetar med data ändras på det specifika företaget.

Sen får siffrorna från 1C, enligt honom, en halvhändig behandling, med hjälp av Excel till exempel. Sådan behandling tillför inte kvalitet till data, inte heller snabbhet.

Till slut kontrollerar någon den slutliga rapporten för att inte av misstag ge ledningen siffror med fel. Resultatet är att siffrorna når mottagaren vackra, kontrollerade, men väldigt sent. Vanligtvis — efter att perioden (månad, vecka, etc.) har avslutats.

Och här, sa han, är allt mycket enkelt. Om siffrorna för januari kom till er i februari, kan ni inte längre styra över januari. Eftersom januari redan är slut.

Och om siffrorna baseras på bokföring och företaget är helt vanligt, med kvartalsvis momsredovisning, får dess ledare rimliga siffror en gång i kvartalet.

Därefter är det tydligt. Ni får siffror en gång i månaden — ni har möjlighet att styra med siffror (det vill säga utföra kontroll) 12 gånger om året. Om ni praktiserar kvartalsrapportering — styr ni 4 gånger om året. Dessutom bonus — årsrapportering. En gång till kan ni ratta.

Under resten av tiden styrs verksamheten oftast i blindo.

När (och om) siffrorna faktiskt dyker upp, inträder det andra problemet — hur ska man styra baserat på siffror? Med denna punkt i sina resonemang kunde jag verkligen inte hålla med.

Killen hävdade att om ledaren aldrig haft siffror förut, så skulle deras framkomst orsaka en wow-effekt. Han skulle titta på och leks med siffrorna på olika sätt, kalla in folk till matten, kräva förklaringar och utredningar. Efter att ha lekt med siffrorna och genomfört analyser, lovade han hotfullt alla anställda att "nu ska jag inte släppa er". Ledaren skulle mycket snabbt lugna ner sig och släppa det hela. Han skulle sluta använda verktyget. Och problemen skulle förbli.

Så sker det, sa han, på grund av ledarens otillräckliga kompetens. Framför allt inom controllingen. Ledaren vet helt enkelt inte vad han ska göra med dessa siffror. Vad medatt göra — vet han, vad han ska göra — vet han inte. Att göra — det är det som beskrivs ovan (skälla, leka). Göra — det är en daglig affärsprocess.

Han hävdade att allt är mycket enkelt: siffran ska bli en del av affärsprocessen. I affärsprocessen ska det tydligt framgå: vem, vad och när som ska göras vid avvikelser från normen (alla alternativ — över gränsen, under gränsen, utanför korridoren, närvaro av trend, brist på kvantil, etc.)

Och här angav han den viktigaste dilemmat: siffran finns, den ska bli en del av affärssystemet för att öka effektiviteten i ledningen, men… det sker inte. Varför?

För att den ryska ledaren inte kommer att ge bort en del av sin makt till en konkurrent.

Konkurrenterna till den ryska ledaren — en kvalitativ och fungerande affärsprocess, genomtänkt ömsesidigt fördelaktig motivation och korrekt automatisering — tyvärr, kommer att lämna ledaren utan arbete.

Det är bara nonsens, eller hur? Särskilt när det gäller chefer. Okej, jag berättade, ni får själva avgöra.

Lite mindre, men ändå för mycket, enligt min mening, talade han om scrum.

Absolut, sa han, läs och försök använda scrum i praktiken. Om du har läst men inte prövat, räknas det som att du inte vet. Det är bättre att läsa en bok, till exempel av Sutherland, snarare än artiklar och diverse guider (vad är det för skräp?) på internet.

Scrum, sa han, förstås endast genom praktisk tillämpning, och med nödvändiga mätningar av utfört arbete. Prova personligen de två viktigaste rollerna — produktägaren och scrum-mästaren.

Särskilt viktigt, enligt killen, är att verkligen uppleva rollen som scrum-mästare i praktiken, när du kan öka mängden uppgifter som stängs under en sprint utan att öka resurserna och kostnaderna för sprinten.

Och en annan grej han nämnde var TOC (Theory of Constraints).

Detta, enligt killen, är grundläggande och fundamentala principer för att öka effektiviteten, som kan tillämpas praktiskt i nästan alla områden, i alla affärsprocesser och affärssystem i stort.

När han fick veta att vi inte var bekanta med TOC slutade han berätta. Han tillade bara att han inte skulle beröva oss nöjet att läsa Eliyahu Goldratt's böcker. Han gav en liknande rekommendation som för scrum — läs och pröva. Typ, oavsett vilken position ni har, vilken typ av arbete ni utför, så finns det utrymme för att höja effektiviteten med hjälp av TOC-metoder.

Sen verkar hans verktygslåda med metoder ha sina begränsningar, och han sa: mixa principerna för att skapa tillämpade lösningar i specifika situationer.

Detta, sa han, är den viktigaste rekommendationen, nyckeln till framgång. Förstå principerna, essensen, och skapa unika tillämpade lösningar — affärsprocesser och affärssystem.

Sen försökte han påminna sig om ett citat, och till slut var han tvungen att söka på internet. Det visade sig vara ett citat från artikeln "Att stå på gigantors axlar" av Eliyahu Goldratt:

Det finns en skillnad mellan tillämpade lösningar och de grundläggande koncepten som dessa lösningar bygger på. Koncepten är allmänna, medan tillämpade lösningar är anpassningar av koncepten till en specifik miljö. Som vi redan har sett är denna anpassning inte enkel och kräver utveckling av vissa delar av lösningen. Vi måste komma ihåg att en tillämpad lösning baseras på ursprungliga antaganden (ibland dolda) om den specifika miljön. Man ska inte förvänta sig att denna tillämpade lösning kommer att fungera i en miljö där de ursprungliga antagandena inte är korrekta.

Han sa att arbetet som programmerare och "förbättrare av affärsprocesser" är mycket likt. Och så gick han.

Källa: habr.com