Om en kille

Historien är verklig, jag såg allt med mina egna ögon.

I flera år arbetade en kille, som många av er, som programmerare. För säkerhets skull kommer jag att skriva det så här: "programmerare." Eftersom han var 1Snik, på en fix, produktionsbolag.

Innan dess provade han olika specialiteter - 4 år i Frankrike som programmerare, projektledare, han kunde slutföra 200 timmar, samtidigt som han fick en procentandel av projektet, för ledning och att göra lite försäljning. Jag försökte utveckla produkter på egen hand, var chef för IT-avdelningen i ett stort företag med 6 tusen personer, provade olika alternativ för att använda mitt kvoterade yrke - 1C-programmerare.

Men alla dessa positioner var något återvändsgränd, främst när det gäller inkomster. På den tiden fick vi alla ungefär samma pengar och arbetade under samma villkor.

Den här killen undrade hur han kunde tjäna mer pengar utan att sälja eller skapa sitt eget företag.

Han ansåg sig vara en smart kille och bestämde sig för att hitta en nisch i företaget där han arbetade. Denna nisch måste vara något speciellt, inte ockuperat av någon. Och jag ville att företaget självt skulle vilja betala pengar till en person i denna nisch, så att man inte skulle behöva lura någon eller lura någonting. För att uppnå detta mål: en person i denna position måste få mycket pengar. En excentriker, med ett ord.

Sökandet blev kortlivat. I företaget där den här killen arbetade fanns det en helt gratis nisch som kan kallas "att sätta ordning i affärsprocesser." Varje företag har många problem. Något fungerar alltid inte, och det finns ingen person som kommer och fixar affärsprocessen. Så han bestämde sig för att prova sig själv som en specialist som kan hjälpa ägaren att lösa sina problem i affärsprocesser.

Då hade han jobbat på företaget i ett halvår och fått medellönen på marknaden. Det fanns inget att förlora, särskilt eftersom han lätt kunde hitta samma jobb inom en vecka. I allmänhet bestämde den här killen att inget dåligt skulle hända om plötsligt inget fungerade och han fick sparken.

Han tog mod till sig och kom till ägaren. Jag föreslog att han skulle förbättra den mest problematiska processen i verksamheten. På den tiden var det lagerbokföring. Nu skäms alla som arbetar i det här företaget till och med över att komma ihåg de problemen, men inventeringar, som genomfördes kvartalsvis, visade avvikelser mellan redovisningssystemet och faktiska saldon på tiotals procent. Och i kostnad, och i kvantitet och i antal positioner. Det var en katastrof. Företaget hade faktiskt rätt saldon i redovisningssystemet bara fyra gånger om året – dagen efter lagerräkningen. Vår kille började sätta ordning på den här processen.

Killen kom överens med ägaren om att han skulle minska avvikelserna från inventeringsresultaten med hälften. Dessutom hade ägaren inget speciellt att förlora, för före vår hjälte hade olika arbetare redan gjort försök att fixa allt, och i allmänhet ansågs uppgiften vara praktiskt taget olöslig. Allt detta väckte stort intresse, för om allt fungerade skulle snubben automatiskt bli en person som vet hur man ställer saker i ordning och löser olösliga problem.

Så han stod inför uppgiften: att minska avvikelser baserat på inventeringsresultat med 2 gånger inom ett år. I början av projektet hade han ingen aning om hur han skulle uppnå detta, men han förstod att lagerredovisning är en enkel sak, så han skulle ändå kunna göra något användbart. Att minska avvikelserna från tiotals procent till tiotals procent verkar dessutom inte vara så svårt. Alla som har arbetat med konsultverksamhet eller liknande verksamhet förstår att de flesta processproblem kan lösas med ganska enkla steg.

Från januari till maj förberedde han, automatiserade något lite, skrev om affärsprocessen för lagerbokföring, ändrade arbetsflödena för lagerhållare, revisorer och gjorde i allmänhet om hela systemet, utan att visa eller berätta något för någon. I maj delade han ut nya instruktioner till alla och efter årets första inventering började ett nytt liv – att arbeta enligt hans regler. För att observera resultaten började företaget i framtiden genomföra inventeringar oftare - en gång varannan månad. Redan de första resultaten var positiva och i slutet av året hade avvikelserna från revisionsresultaten sjunkit till en bråkdel av en procent.

Framgången var kolossal, men man kunde inte tro på dess hållbarhet. Killen själv tvivlade på att resultatet skulle bevaras om han klev åt sidan och slutade observera processen. Ändå blev det ett resultat, och killen fick allt han kommit överens om med ägaren. Sedan, efter flera år, bekräftades stabiliteten i resultatet - i flera år låg avvikelserna inom 1%.

Sedan bestämde han sig för att upprepa experimentet och föreslog att ägaren skulle förbättra en annan problematisk process - leverans. Det fanns brister som inte gjorde att vi kunde frakta de volymer som våra kunder ville ha. Vi kom överens om att inom ett år skulle underskotten halveras, och killen skulle även slutföra 10-15 projekt relaterade till 1C – för att automatisera olika affärsprocesser och andra kätterier.

Under det andra året slutfördes allt framgångsrikt igen, underskotten minskade med mer än 2 gånger, alla IT-projekt slutfördes framgångsrikt.

Eftersom lönen redan till fullo tillfredsställde alla behov hos den killen två år i förväg, bestämde han sig för att slå sig ner lite, lugna ner sig och sitta på en mysig, varm plats som han hade skapat för sig själv.

Hur var det? Formellt var han IT-direktör. Men vem han egentligen var är svårt att förstå. När allt kommer omkring, vad gör en IT-direktör? Som regel administrerar han IT-infrastrukturen, hanterar systemadministratörer, implementerar ett affärssystem och deltar i styrelsemöten.

Och den här snubben hade ett av nyckelansvaren att delta i förändringsprocesser, och främst - generering, initiering av dessa processer, sökning och förslag på lösningar, tillämpning av nya ledningstekniker, granskning av föreslagna förändringar, analys av effektiviteten hos andra funktioner och divisioner och slutligen direkt deltagande i den strategiska utvecklingen av företaget, fram till den oberoende utvecklingen av en strategisk plan för hela företaget.

Han fick carte blanche. Han kunde komma till vilket möte som helst där han inte tidigare haft tillgång. Jag satt där med ett anteckningsblock, skrev ner något eller bara lyssnade. Han talade sällan. Sedan började han spela i telefonen och hävdade att det associativa minnet fungerar bättre på det här sättet.

På mötet gav han sällan ut något användbart. Han gick, tänkte, sedan kom ett brev - antingen med kritik, eller med en åsikt, eller med förslag eller med en beskrivning av de lösningar som han redan tillämpat.

Men oftare sammankallade han själv möten. Jag hittade ett problem, kom på lösningar, identifierade intressenter och tog med alla på mötet. Och sedan - så gott han kunde. Han övertygade, motiverade, bevisade, argumenterade, uppnådde.

Inofficiellt ansågs han vara den tredje personen i företaget, efter ägaren och direktören. Naturligtvis gjorde han fruktansvärt arg på alla "företagets personer", med början med nummer 4. Speciellt med sina trasiga jeans och ljusa T-shirts, och även med sin tid som ägare.

Ägaren gav honom 1 timme om dagen. Varje dag. De pratade, diskuterade problem, lösningar, nya företag, utvecklingsområden, indikatorer och effektivitet, personlig utveckling, böcker och helt enkelt livet.

Men den här killen var konstig. Det är som, luta dig tillbaka och var glad, livet är bra. Men nej. Han bestämde sig för att reflektera.

Han undrade: varför fungerade det för honom, men andra gjorde det inte? Ägaren pushade honom också: han sa att han ville att andra också skulle kunna återställa ordningen, eftersom det finns många chefer, de är som regel engagerade i operativ ledning och strategisk planering, men praktiskt taget ingen är engagerad i systemförändringar i sina processer. Det kanske står i deras arbetsbeskrivning att de borde snabba på sin process och öka dess effektivitet, men det är faktiskt ingen som gör detta. Varför är det så? Killen blev också intresserad av varför, och han gick för att prata med alla dessa chefer.

Han kom till biträdande direktören för kvalitet och föreslog att man skulle införa Shewhart kontrolldiagram så att produkterna skulle bli bättre än japanska. Men det visade sig att kollegan inte visste vad Shewhart kontrolldiagram var, vad statistisk processkontroll var och bara hade hört talas om användningen av Deming-cykeln i kvalitetsstyrning. OK…

Han gick till en annan biträdande direktör och föreslog att man skulle införa kontroll. Men jag hittade inget stöd här heller. Lite senare lärde han sig om gränshantering (boundary management) och föreslog att alla biträdande direktörer skulle implementera den systemiska delen av denna metodik för att förbättra processerna. Men hur mycket vår kille än pratade var det ingen som verkligen ville fördjupa sig i vad det handlade om. Kanske var de inte intresserade eller så var det för svårt. Men det var faktiskt ingen som fattade det.

I allmänhet pratade han om allt han visste och använde i företaget. Men ingen förstod honom. De förstår fortfarande inte varför, till exempel, allt korrigerades i lagerbokföring, och vad har kontroll och gränshantering med det att göra.

Sist av allt nådde han sina programmerare - personalen omfattade 3 personer. Han pratade om gränskontroll, om kontroll, om kvalitetsstyrning, om agilt och scrum... Och överraskande nog förstod de allt, och kunde till och med diskutera med honom på något sätt, inklusive tekniska och metodologiska finesser. De förstod varför lager- och leveransprojekten fungerade. Och då gick det upp för killen: i själva verket kommer programmerare att rädda världen.

Programmerare, insåg han, är de enda som kan förstå affärsprocesser normalt, med nödvändiga detaljer.

Varför dem? I själva verket hittade han aldrig något tydligt svar. Jag formulerade bara avhandlingstips.

För det första känner programmerare till verksamhetens ämnesområden, och de kan dem bättre än alla andra personer i företaget.

Dessutom förstår programmerare verkligen vad en processalgoritm är. Detta är viktigt eftersom affärsprocesser är algoritmer, och elementen i dem kanske helt enkelt inte är konsekventa. Till exempel, i upphandlingsprocessen som killen arbetade med, var det första steget att skapa en årlig inköpsplan och det andra var dagliga inköp. Dessa steg är sammankopplade med en direkt anslutning, det vill säga det antas att människor ska arbeta enligt denna algoritm - upprätta en årlig upphandlingsplan och omedelbart exekvera begäran. Den årliga upphandlingsplanen upprättas en gång per år och ansökningar kommer in 50 gånger om dagen. Det är här algoritmen slutar, och du måste arbeta med den. Faktum är att, resonerade han, för programmerare är kunskap om algoritmer en konkurrensfördel, eftersom alla andra som inte är bekanta med dem helt enkelt inte förstår hur en affärsprocess ska fungera och hur den kan representeras.

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 spendera tre gånger längre tid på en uppgift än vad den faktiskt kräver, och få kommer att märka. Detta är återigen en konkurrensfördel, för för att få ordning på en affärsprocess måste du ha mycket fritid - tänka, observera, studera och prova.

De flesta chefer, enligt killen, har inte den här fritiden och är stolta över det. Även om detta i själva verket betyder att en person inte kan bli effektiv eftersom han inte har tid att förbättra effektiviteten - en ond cirkel. I vår kultur är det på modet att vara upptagen, så allt förblir detsamma. Och för oss programmerare är detta en fördel. Vi kan hitta ledig tid och tänka på allt.

Programmerare, sa han, kan snabbt ändra ett informationssystem. Detta är inte tillämpligt på alla företag, men var han än arbetade kunde han göra vilka ändringar han ville. Särskilt om de inte rör någon annans arbete. Han kunde till exempel lansera ett system som i hemlighet skulle mäta användaråtgärder och sedan använda denna information för att analysera effektiviteten hos samma redovisningsavdelning och spåra kostnaden för redovisning.

Och det sista jag kommer ihåg från hans ord är att programmerare har tillgång till en stor mängd information, eftersom... ha administrativ åtkomst till systemet. Därför kan de använda denna information i sin analys. Ingen annan på en vanlig anläggning har en sådan resurs.

Och så gick han. Under de två veckor långa frihetsberövandena tvingade vi honom att dela med sig av sin erfarenhet eftersom vi ville fortsätta det arbete han utförde. Nåväl, hans tjänst blev ledig.

Under flera dagar satte de honom på en stol, slog på kameran och spelade in hans monologer. De bad att få berätta om alla genomförda projekt, metoder, tillvägagångssätt, framgångar och misslyckanden, orsaker och effekter, porträtt av chefer m.m. Det fanns inga särskilda begränsningar, eftersom De visste inte vad som pågick i hans huvud.

Monologerna var förstås mest bara nonsens och skratt - han var på strålande humör, eftersom lämnade outbacken för St. Petersburg. Vart ska du gå för att arbeta i St. Petersburg? Till Gazprom förstås.

Men vi lyckades få fram något användbart ur hans monologer. Jag ska berätta vad jag minns.

Så, killens rekommendationer. För dig som vill försöka få ordning på saker och ting i affärsprocesser.

För att utföra den här typen av arbete måste du för det första ha en viss nivå av "frostbite". Man ska inte vara rädd för att bli av med jobbet, inte vara rädd för att ta risker, inte vara rädd för konflikter med kollegor. Det var lätt för honom, eftersom han började sin resa när han hade arbetat i företaget i bara ett halvår, och inte hade tid att komma i kontakt med någon, och inte tänkte göra det. Han förstod att människor kommer och går, men hans egna resultat och deras bedömning av företagaren är viktiga för honom. Huruvida hans kollegor behandlade honom bra eller dåligt bekymrade honom då inte mycket.

Den andra punkten är att för att effektivt kunna utföra detta arbete, tyvärr, måste du studera. Men studera inte för en MBA, inte i kurser, inte på institut, utan på egen hand. Till exempel, i sitt första projekt, ett lagerprojekt, agerade han intuitivt, han visste ingenting, bara vad "kvalitetsledning" var.

När han började läsa litteraturen om vilka metoder för att öka effektiviteten som fanns, upptäckte han de teknologier som han använde. Killen tillämpade dem intuitivt, men det visar sig att detta inte var hans uppfinning, allt var redan skrivet för länge sedan. Men han spenderade tid, och mycket mer än om han omedelbart hade läst rätt bok. Här är det bara viktigt att förstå att när du studerar en specifik teknik, kommer inte en av dem, inte ens den mest avancerade, att helt lösa alla problem i en affärsprocess.

Det andra tricket är att ju fler tekniker du kan, desto bättre. Till exempel, i det antika Japan bodde Miyamoto Musashi, en av de mest kända svärdsmännen, författaren till tvåsvärdsstilen. Han studerade på någon skola med någon mästare, reste sedan runt i Japan, slogs med olika killar. Om killen var starkare, stannade resan en tid och Musashi blev student. Som ett resultat fick han under flera år färdigheterna i olika metoder från olika mästare och bildade sin egen skola och lade till något eget. Som ett resultat uppnådde han en unik färdighet. Det är samma sak här.

Du kan självklart agera företagskonsulter. I allmänhet är de bra killar. Men som regel kommer de att införa någon form av metodik, och de implementerar fel metodik som verksamheten behöver. Vi hade också sådana sorgliga situationer: ingen vet hur man löser problemet och ingen vill tänka på hur man löser det. Vi börjar söka antingen på Internet eller ringer en konsult och frågar honom vad som kan hjälpa oss. Konsulten tänker och säger att vi måste införa teorin om begränsningar. Vi betalar honom för hans rekommendation, vi spenderar pengar på genomförandet, men resultaten är noll.

Varför händer detta? För att konsulten sa, vi inför ett sådant och ett sådant system, och alla höll med honom. Bra, men en metod täcker inte alla problem i ens en affärsprocess, särskilt om de initiala förutsättningarna - våra och de som krävs för att implementera metoden - inte sammanfaller.

I praktiken som killen rekommenderar måste du ta det bästa och implementera det bästa. Ta inte metoderna helt och hållet, utan ta deras nyckelfunktioner, funktioner och metoder. Och det viktigaste är att förstå essensen.

Ta, sa han, till exempel Scrum eller Agile. I sina monologer upprepade killen många gånger att inte alla helt förstår essensen av Scrum. Han läste också Jeff Sutherlands bok, som vissa tycker är "lätt läsning". Det verkade som en djup läsning för honom, eftersom en av Scrums grundläggande principer är kvalitetsledning, detta skrivs direkt i boken.

Det står om Toyota Production, om hur Jeff Sutherland visade Scrum i Japan, hur det slog rot där och hur nära det var deras filosofi. Och Sutherland pratade om vikten av rollen som Scrum Master, om Deming-cykeln. Scrum Masters roll är att hela tiden påskynda processen. Allt annat som finns i Scrum – fasleverans, kundnöjdhet, en tydlig lista över arbeten för sprintperioden – är också viktigt, men allt detta måste gå snabbare och snabbare. Arbetshastigheten måste hela tiden öka i de enheter som den mäts i.

Kanske är det här en fråga om översättning, eftersom vår bok översattes som "Scrum - en revolutionerande metod för projektledning", och om den engelska titeln översätts bokstavligt, kommer det att visa sig: "Scrum - dubbelt så mycket på halva tiden" , det vill säga även i Namnet hänvisar till hastighet som en nyckelfunktion i Scrum.

När den här killen implementerade Scrum fördubblades hastigheten under den första månaden utan några betydande förändringar. Han hittade punkter för förändring och modifierade själva Scrum för att få det att fungera mycket snabbare. Det enda de skriver på Internet är att de ställdes inför frågan: "Vi har fördubblat hastigheten, allt som återstår är att förstå vad vi gör i en sådan hastighet?" Men detta är ett helt annat område...

Han rekommenderade också personligen flera tekniker. Han kallade dem grundläggande och grundläggande.

Den första är gränskontroll.

De lär ut det på Skolkovo, enligt killen finns det inga andra böcker och material. Han hade på något sätt turen att gå på en föreläsning av en professor från Harvard som predikar gränskontroll, och även läsa flera artiklar i Harvard Business Review om Eric Trists arbete.

Gränshantering säger att man måste kunna se gränser och arbeta med gränser. Det finns gott om gränser, de finns överallt – mellan avdelningar, mellan olika typer av arbete, mellan funktioner, mellan operativt och analytiskt arbete. Kunskapen om gränsstyrning avslöjar inga högre sanningar, men den låter oss se verkligheten i ett lite annorlunda ljus – genom gränsernas prisma. Och följaktligen hantera dem - montera dem där det behövs och ta bort dem där de är i vägen.

Men oftast pratade killen om att kontrollera. Han hade bara någon sorts egenhet i det här ämnet.

Att styra är kort sagt styrning baserad på siffror. Här, sa han, är varje del av definitionen viktig - både "ledning" och "baserat på" och "siffror".

Vi, sa han, är dåliga med alla tre komponenterna i kontroll. Särskilt med tanke på att de är nära sammankopplade både med varandra och med andra delar av affärssystemet.

Det första som är dåligt är siffrorna. Det finns få av dem och de är av låg kvalitet.

Vi tog sedan en betydande del av siffrorna från informationssystemet 1C. Så kvaliteten på siffrorna i 1C, som han hävdade, är inte bra. Åtminstone på grund av möjligheten att ändra data retroaktivt.

Det är tydligt att detta inte är 1C-utvecklarnas fel - de tar bara hänsyn till marknadens krav och mentaliteten hos inhemsk redovisning. Men för kontrolländamål är det bättre att ändra principerna för 1C-arbete med data på ett specifikt företag.

Vidare genomgår siffrorna från 1C, enligt honom, semi-manuell bearbetning, med till exempel Excel. Sådan bearbetning tillför inte heller kvalitet till uppgifterna, liksom effektivitet.

I slutändan dubbelkollar någon annan slutrapporten för att inte av misstag skicka in siffror med fel till chefen. Som ett resultat når siffrorna mottagaren vackra, verifierade, men väldigt sent. Vanligtvis - efter slutet av perioden (månad, vecka, etc.).

Och här, sa han, är allt väldigt enkelt. Om siffrorna om januari kom till dig i februari, kan du inte längre hantera aktiviteterna i januari. För januari är redan över.

Och om siffrorna baseras på bokföring, och företaget är det vanligaste, med kvartalsvis inlämning av moms, så får dess chef relativt adekvata siffror en gång i kvartalet.

Resten är klart. Du får nummer en gång i månaden - du har möjlighet att styra efter nummer (dvs styra) 12 gånger per år. Övar du kvartalsrapportering så klarar du det 4 gånger per år. Plus en bonus - årsredovisning. Styr en gång till.

Resten av tiden utförs kontroll oftast blint.

När (och om) siffrorna dyker upp, kommer det andra problemet in i bilden - hur hanterar man utifrån siffrorna? Jag kunde inte hålla med om denna punkt i hans resonemang.

Killen hävdade att om chefen inte hade siffrorna tidigare, skulle deras utseende orsaka en wow-effekt. Han kommer att titta och vrida på siffrorna åt det och det andra, ringa folk på mattan, kräva förklaringar och utredningar. Efter att ha lekt med siffror, gjort analyser och hotfullt lovat alla anställda att "nu blir jag inte av med dig", kommer chefen mycket snabbt att lugna ner sig och ge upp i den här frågan. Sluta använda verktyget. Men problemen kommer att finnas kvar.

Detta händer, sade han, på grund av otillräcklig chefskompetens. När det gäller kontroll, först och främst. Chefen vet helt enkelt inte vad han ska göra med dessa siffror. Vad сatt göra - vet vad man ska göra - nej. Att göra är det som står skrivet om ovan (att bråka, att leka). Att göra är en daglig affärsprocess.

Han menade att allt är väldigt enkelt: digitalt måste bli en del av affärsprocessen. I affärsprocessen bör det vara tydligt: ​​vem ska göra vad och när om siffrorna avviker från normen (alla alternativ - ovanför gränsen, under gränsen, gå bortom korridoren, förekomsten av en trend, misslyckande att uppfylla kvantil etc.)

Och så beskrev han nyckeldilemmat: antalet finns, det borde bli en del av affärssystemet för att öka effektiviteten i förvaltningen, men... detta händer inte. Varför?

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

Den ryska chefens konkurrenter - en högkvalitativ och fungerande affärsprocess, genomtänkt ömsesidigt fördelaktig motivation och korrekt automatisering - tyvärr kommer att lämna chefen utan jobb.

Något nonsens, håller du inte med? Särskilt om ledare. Okej, jag sa ju att du bestämmer själv.

Lite mindre, men ändå för mycket, enligt mig, pratade han om Scrum.

Var säker, sa jag, läs och prova Scrum i praktiken. Om, säger han, du har läst den men inte provat den, betrakta dig själv som okunnig. Det är bättre att läsa en bok, till exempel av Sutherland, snarare än artiklar och alla sorters guider (vad i helvete?) på Internet.

Scrum, sa han, kan bara läras genom övning och med obligatoriska mätningar av mängden utfört arbete. Pröva personligen de två viktigaste rollerna - Product Owner och Scrum Master.

Det är särskilt viktigt, enligt killen, att i praktiken uppleva rollen som Scrum Master, när man kan öka volymen av utförda uppgifter per sprint utan att öka resurserna och kostnaden för sprinten.

Tja, i hans topp fanns TOS (teori om systembegränsningar).

Dessa, enligt killen, är de grundläggande, grundläggande principerna för att öka effektiviteten som kan tillämpas på nästan alla områden, i alla affärsprocesser och affärssystem som helhet.

När han fick reda på att vi inte var bekanta med TOS, slutade han berätta för oss. Han tillade bara att han inte skulle beröva oss nöjet att läsa Eliyahu Goldratts böcker. Han gav en liknande rekommendation till Scrum - läs den och prova den. Som, oavsett vilken position du är i, oavsett vilket arbete du utför, finns det en plats för att öka effektiviteten med hjälp av TOC-metoder.

Sedan torkade tydligen hans påse med tekniker ut, och han sa: blanda principerna för att skapa tillämpade lösningar i en specifik situation.

Detta, säger han, är huvudrekommendationen, nyckeln till framgång. Förstå principerna, essensen och skapa unika applikationslösningar - affärsprocesser och affärssystem.

Sedan försökte han komma ihåg något citat, och till slut var han tvungen att gå online. Det visade sig vara ett citat från artikeln "Standing on the Shoulders of Giants" av Eliyahu Goldratt:

”Det finns en skillnad mellan tillämpade lösningar (applikationer) och de grundläggande koncept som dessa lösningar bygger på. Koncept är generella, tillämpade lösningar är anpassning av koncept till en specifik miljö. Som vi redan har sett är en sådan anpassning inte enkel och kräver utveckling av vissa delar av lösningen. Vi måste komma ihåg att en applikationslösning är baserad på initiala antaganden (ibland dolda) om en specifik miljö. Denna applikationslösning bör inte förväntas fungera i en miljö där antagandena inte är korrekta."

Han sa att arbetet med en programmerare och en "förbättrare av affärsprocesser" är väldigt lika. Och vänster.

Källa: will.com