Historien er sand, jeg har set det med egne øjne.
I flere år arbejdede en fyr, ligesom mange af jer, som programmør. Bare for at tydeliggøre: 'programmør'. Fordi han var en 1C-udvikler i en produktionsvirksomhed.
Før dette havde han prøvet forskellige stillinger – 4 år som programmør i en franchise, projektleder, hvor han kunne lukke op til 200 timer, samtidigt modtage procent fra projektet for ledelsen og lidt arbejde med salg. Han prøvede at udvikle produkter selv, var IT-chef i en stor virksomhed med 6.000 ansatte, og havde afprøvet forskellige muligheder for at anvende sin niche-profession – 1C-programmør.
Men alle disse stillinger var lidt blindgyder, primært på grund af indkomsten. Vi tjente alle omtrent de samme penge og arbejdede under de samme betingelser.
Denne fyr blev interesseret i, hvordan man kunne tjene flere penge uden at arbejde med salg og uden at starte sin egen virksomhed.
Han fik sig selv til at tro, at han var smart, og besluttede at finde en niche i den virksomhed, hvor han arbejdede. Denne niche skulle være noget særligt, som ingen andre besatte. Og han ønskede, at virksomheden selv skulle ville betale penge til en person i denne niche, så der ikke var behov for at bedrage nogen eller dreje tallene. Det skulle være objektivt: en person i denne position skulle have høj løn. En tosse, med andre ord.
Søgen var ikke lang. I den virksomhed, hvor denne fyr arbejdede, var der en helt fri niche, som man groft kan kalde 'forbedring af forretningsprocesser'. I hver virksomhed er der masser af problemer. Der virker altid noget ikke, og der er ikke nogen, der kommer og retter forretningsprocesserne. Så han besluttede at prøve sig som specialist, der kunne hjælpe virksomhedsejeren med at løse sine problemer i forretningsprocesserne.
På det tidspunkt havde han arbejdet i virksomheden i et halvt år, og han fik en gennemsnitlig løn i markedet. Der var intet at tabe – især da han let kunne finde et lignende arbejde inden for en uge. Så i det store hele tænkte denne fyr, at der ikke ville ske noget skræmmende, hvis det pludselig ikke fungerede, og han blev fyret.
Han samlede mod og gik til ejeren. Han tilbød at forbedre den mest problematiske proces i forretningen. På det tidspunkt var det lagerregnskab. I dag er det endda pinligt for alle, der arbejder i denne virksomhed, at mindes de problemer, men de kvartalsvise lageropgørelser viste afvigelser mellem regnskabssystemet og de faktiske lagre på op til flere procent. Både hvad angår værdi, antal og varianter. Det var en katastrofe. Virksomheden havde faktisk kun korrekte rester i regnskabssystemet fire gange om året – dagen efter lageropgørelsen. Denne proces var det, vores fyr satte i system.
Fyren indgik en aftale med ejeren om, at han skulle reducere afvigelserne i lageropgørelserne med halvdelen. For ejeren var der ikke meget at tabe, da forskellige medarbejdere før ham allerede havde forsøgt at løse problemet, og opgaven blev betragtet som næsten umulig. Alt dette gjorde interessen endnu større, for hvis det lykkedes, ville fyren automatisk blive en person, der kan skabe orden og løse umulige opgaver.
Så opgaven foran ham var klar: i løbet af et år at reducere afvigelserne i lageropgørelserne med 50%. På projektets start havde han ikke en idé om, hvordan dette skulle opnås, men han forstod, at lagerregnskab var en enkel proces, så det ville være muligt at gøre noget nyttigt. Især fordi det ikke skulle være så svært at reducere afvigelserne fra flere procent til et enkelt decimal. Alle, der har arbejdet inden for rådgivning eller lignende aktiviteter, ved, at de fleste procesproblemer kan løses med relativt enkle handlinger.
Fra januar til maj forberedte han sig, automatiserede noget, omskrev forretningsprocessen for lagerbeholdning, ændrede arbejdsstrømmen for lagermedarbejdere, revisorer og ændrede generelt hele systemet uden at vise eller fortælle nogen noget. I maj delte han nye instruktioner ud til alle, og efter årets første lageroptælling begyndte et nyt liv – arbejde efter hans regler. For at kunne se resultaterne begyndte virksomheden at gennemføre lageroptællinger oftere – hver anden måned. Allerede de første resultater var positive, og inden årets slutning faldt afvigelserne i revisionsresultaterne til brøkdelen af en procent.
Succesen var kolossal, men det var svært at tro på dens stabilitet. Selve drengen var usikker på, om resultaterne ville blive opretholdt, hvis han trak sig tilbage og stoppede med at overvåge processen. Ikke desto mindre var der et resultat, og drengen fik alt, hvad han havde aftalt med ejeren. Senere, efter et par år, blev stabiliteten i resultaterne bekræftet – i flere år var afvigelserne inden for 1 %.
Så besluttede han at gentage eksperimentet og foreslog ejeren at forbedre en anden problematisk proces – forsyning. Der var mangler, som ikke tillod at levere de mængder, vores kunder ønskede. De blev enige om, at manglerne skulle reduceres med halvdelen i løbet af året, og fyren ville også udføre 10-15 projekter relateret til 1C — automatisering af forskellige forretningsprocesser og anden skørhed.
I det andet år lykkedes det igen at afslutte alt med succes, manglerne blev reduceret med mere end halvdelen, og alle IT-projekter blev afsluttet med succes.
Da lønnen nu fuldt ud tilfredsstillede alle krav fra fyren, i to år frem, besluttede han at tage det roligt, slappe af og sidde på det hyggelige varme sted, som han selv havde skabt.
Hvad bestod det af? Formelt set var han IT-direktør. Men hvad han egentlig var, er svært at forstå. Hvad laver en IT-direktør? Som regel administrerer han IT-infrastrukturen, leder systemadministratorer, implementerer ERP-systemer, deltager i møder i bestyrelsen.
En af hans nøgleopgaver var at deltage i forandringsprocesser, primært med at generere og iniere disse processer, finde og foreslå løsninger, anvende nye ledelsesmetoder, evaluere de foreslåede ændringer, analysere effektiviteten af andre funktioner og afdelinger, og endelig direkte deltage i virksomhedens strategiske udvikling, selv til at udvikle virksomhedens helhedsstrategiske plan.
Han fik frie hænder. Han kunne være med til ethvert møde, han tidligere ikke havde adgang til. Han sad der med en notesbog, noterede noget, eller bare lyttede. Han talte sjældent. Senere begyndte han at spille på sin telefon - han hævdede, at det hjalp hans associative hukommelse.
På mødet kom han sjældent med noget nyttigt. Han forlod det, tænkte, og så kom der et brev - enten med kritik, eller med meninger, eller med forslag, eller med beskrivelser af løsninger, han allerede havde anvendt.
Men oftere holdt han møderne selv. Han fandt et problem, opfandt løsningsmuligheder, identificerede de interesserede parter og fik alle ind i forhandlingslokalet. Og dér — gjorde han, som han kunne. Han overbeviste, motiverede, argumenterede, diskuterede, og fik sin vilje.
Uformelt blev han anset som den tredje person i virksomheden, efter ejeren og direktøren. Selvfølgelig irriterede han alle 'personer i virksomheden', begyndende fra nummer 4, voldsomt. Især med sine slidte jeans og farverige T-shirts, og ikke mindst — ejerens tid.
Ejeren gav ham 1 time om dagen. Hver dag. De talte, diskuterede problemer, løsninger, nye forretningsområder, udviklingsretninger, indikatorer og effektivitet, personlig udvikling, bøger, og bare — livet.
Men denne fyr var underlig. Det skulle man tro — sidde og glæde sig, livet er lykkedes. Men nej. Han besluttede sig for at reflektere.
Han blev nysgerrig: hvorfor lykkedes det ham, men ikke andre? Ejeren pressede også ham: han sagde, at han ønskede, at andre også kunne få orden på tingene, fordi der er mange ledere, som normalt beskæftiger sig med operationel ledelse og strategisk planlægning, men der er praktisk talt ingen, der arbejder med systemiske ændringer af deres processer. Måske står det i deres jobbeskrivelser, at de skal accelerere deres processer og øge effektiviteten, men i virkeligheden er der ingen, der gør det. Hvorfor er det sådan? Den unge mand blev også nysgerrig på, hvorfor det var tilfældet, og han begyndte at tale med alle disse ledere.
Han henvendte sig til vicechefen for kvalitet og foreslog at implementere kontrolkort fra Shewhart for at produktet kunne være bedre end det japanske. Men det viste sig, at kollegaen ikke vidste, hvad kontrolkort fra Shewhart var, hvad statistisk processtyring er, og kun havde hørt lidt om anvendelsen af Deming-cyklussen i kvalitetsledelse. Nå ja…
Han gik til en anden vicechef og foreslog at implementere controlling. Men heller ikke her fandt han støtte. Senere hørte han om boundary management og foreslog til alle vicechefer at implementere den systemiske del af metoden for at forbedre processerne. Men uanset hvor meget den unge mand talte, var der ingen, der var interesseret i at forstå, hvad det drejede sig om. Måske var det kedeligt for dem eller for kompliceret. Men faktum er, at ingen forstod det.
Alt i alt fortalte han om alt, hvad han vidste og havde anvendt i virksomheden. Men ingen forstod ham. De forstod stadig ikke, hvorfor alt f.eks. lykkedes i lagerregnskabet, og hvordan det hænger sammen med controlling og boundary management.
Til sidst nåede han til sine programmører – der var 3 personer ansat. Han fortalte om boundary management, om controlling, om kvalitetsledelse, om agile og scrum… Og til sin overraskelse forstod de alt og kunne endda diskutere med ham, inklusive de tekniske og metodiske detaljer. De forstod, hvorfor projekterne i lageret og forsyningen var gået godt. Og her fik den unge mand en indsigt: det er faktisk programmørerne, der vil redde verden.
Programmørerne, indså han, er de eneste, der kan forstå forretningsprocesserne grundigt og med den nødvendige detaljeringsgrad.
Hvorfor netop dem? Faktisk fandt han aldrig et entydigt svar. Han formulerede kun nogle stikord som antydninger.
For det første kender programmører forretningsområderne, og de kender dem bedre end alle andre i virksomheden.
Desuden forstår programmører virkelig, hvad en procesalgoritme er. Det er vigtigt, fordi forretningsprocesser er algoritmer, og elementerne i dem kan være banalt usammenhængende. For eksempel, i forsyningsprocessen, som fyren arbejdede med, er det første skridt at lave en årlig indkøbsplan, og det andet er daglig indkøb. Disse skridt er forbundet med en direkte forbindelse, det vil sige, at det antages, at folk skal arbejde efter denne algoritme – lave en årlig indkøbsplan og straks udføre bestillingen. Den årlige indkøbsplan laves én gang om året, mens bestillingen kommer 50 gange om dagen. Algoritmen stopper her, og man skal arbejde ud fra den. Faktisk, ræsonnerede han, er kendskab til algoritmer en konkurrencefordel for programmører, fordi enhver anden person, der ikke er bekendt med dem, simpelthen ikke forstår, hvordan en forretningsproces skal fungere, og hvordan den kan visualiseres.
En anden fordel ved programmører, ifølge fyren, er, at de har tilstrækkeligt med fritid. Vi forstår alle, hvordan en programmør kan bruge tre gange så lang tid på en opgave, som den faktisk kræver, og meget få vil lægge mærke til det. Dette er igen en konkurrencefordel, fordi for at kunne bringe en forretningsproces i orden, skal man have meget fritid - tænke, observere, studere og prøve.
De fleste ledere, ifølge fyren, har ikke denne fritid og er stolte af det. Selvom det faktisk betyder, at en person ikke kan blive effektiv, fordi de ikke har tid til at øge effektiviteten - en ond cirkel. I vores kultur er det moderne at være optaget, så alt forbliver det samme. Og for os programmører er det en fordel. Vi kan finde fritid og tænke over alt.
programmører kan hurtigt ændre informationssystemet. Det gælder ikke på alle virksomheder, men hvor end han har arbejdet, kunne der laves alle mulige tilpasninger, man måtte ønske. Især hvis de ikke vedrører nogen andres arbejde. For eksempel kunne han starte et system, der hemmeligt måler brugeraktiviteter, og derefter bruge disse oplysninger til at analysere effektiviteten af for eksempel regnskabsafdelingen og overvåge omkostningerne ved bogføring.
Og det sidste, jeg husker fra hans ord - programmører har adgang til en stor mængde information, da de har administrative rettigheder i systemet. Derfor kan de bruge disse oplysninger i deres analyser. Ingen andre på en almindelig fabrik har sådne ressourcer.
Og så gik han. I de fornødne to uger, vi fik ham til at dele sin erfaring, fordi vi ønskede at fortsætte det arbejde, han havde udført. Og hans stilling blev vakant.
I løbet af nogle dage satte vi ham på en stol, tændte for kameraet og optog hans monologer. Vi bad ham fortælle om alle udførte projekter, metoder, tilgange, succeser og fiaskoer, årsager og konsekvenser, portrætter af ledere osv. Vi begrænsede ikke meget, da vi ikke vidste, hvad der foregik i hans hoved.
I monologerne var der selvfølgelig mest sludder og sjovt - han var i et fremragende humør, da han forlod det provinsielle til fordel for St. Petersborg. Hvor skulle man arbejde i St. Petersborg? Hos Gazprom, selvfølgelig.
Men vi fik trukket noget nyttigt ud af hans monologer. Jeg vil fortælle, hvad jeg husker.
Så her er anbefalingerne fra den fyr. Til dem, der ønsker at prøve at bringe orden i forretningsprocesserne.
For at lave sådan et arbejde kræver det først og fremmest et bestemt niveau af "afsondrethed". Man skal ikke være bange for at miste sit job, ikke være bange for at tage risici, ikke være bange for konflikter med kolleger. Det kom nemt for ham, fordi han startede sin rejse, da han kun havde arbejdet i firmaet i et halvt år, og ikke havde fået mulighed for at knytte kontakt til nogen, og havde heller ikke intentioner om at gøre det. Han forstod, at folk kommer og går, men for ham var hans egne resultater og deres vurdering af virksomhedsejeren vigtigst. Om kollegerne havde en god eller dårlig holdning til ham - det bekymrede ham ikke meget dengang.
Det andet punkt er, at for effektivt at arbejde med dette, må man desværre lære. Men det skal ikke være på MBA, kurser eller i universiteter, men selvstændigt. For eksempel, i sit første projekt om et lager handlede han intuitivt, vidste ingenting, kun hvad 'kvalitetsstyring' var.
Da han begyndte at læse om, hvilke metoder der findes for at øge effektiviteten, opdagede han de teknologier, han allerede havde brugt. Drengen anvendte dem intuitivt, og det viste sig, at det ikke var hans opfindelse; alt var allerede blevet beskrevet for længe siden. Men han brugte mere tid, end hvis han straks havde læst den rigtige bog. Det er vigtigt at forstå, at når man studerer en specifik metode, vil ingen af dem, heller ikke den mest avancerede, helt løse alle problemer i forretningsprocessen.
Den anden ting er, at jo flere metoder du kender, jo bedre. For eksempel, i det gamle Japan levede Miyamoto Musashi - en af de mest kendte sværdkampe, forfatter til stilen med to sværd. Han lærte på en skole hos en mester, og rejste derefter rundt i Japan og kæmpede mod forskellige modstandere. Hvis modstanderen var stærkere, stoppede rejsen i et stykke tid, og Musashi blev elev. Resultatet var, at han i løbet af nogle år tilegnede sig færdigheder fra forskellige mestre og dannede sin egen skole, hvor han tilføjede sine egne elementer. Til sidst opnåede han en unik dygtighed. Her er det det samme.
Man kan selvfølgelig handle som businesskonsulenter. Generelt er de gode folk. Men som regel kommer de for at implementere en bestemt metode og implementerer ikke den metode, som virksomheden har brug for. Vi har også haft triste situationer som dette: ingen ved, hvordan man løser problemet, og ingen ønsker at tænke over, hvordan det skal løses. Vi begynder enten at søge på internettet, eller vi kalder en konsulent og spørger ham, hvad der kan hjælpe os. Konsulenten tænker og siger, at vi skal implementere teorien om begrænsninger. Vi betaler ham for rådgivningen, bruger penge på implementeringen, men resultatet er nul.
Hvorfor sker det? Fordi konsulenten sagde, at denne metode skal implementeres, og alle er enige med ham. Det er fint, men én metode løser ikke alle problemer, selv i én forretningsproces, især hvis de grundlæggende betingelser ikke stemmer overens – vores og dem, der kræves for at implementere metoden.
I den praksis, som fyren anbefaler, skal man tage det bedste og implementere det bedste. Man skal ikke tage metoderne i sin helhed, men tage deres nøglefunktioner, tricks og praksisser. Og det vigtigste er, at man skal forstå essensen.
Lad os tage skridtet videre, sagde han, for eksempel scrum eller agile. I sine monologer gentog fyren mange gange, at ikke alle forstår essensen af scrum til fulde. Han havde også læst Jeff Sutherlands bog, som nogle anser for at være en "let læsning". For ham virkede det som en dyb læsning, fordi en af de grundlæggende elementer i scrum er kvalitetsledelse, som der direkte skrives om i bogen.
Der står skrevet om Toyota Production, hvordan Jeff Sutherland præsenterede scrum i Japan, og hvor godt det blev modtaget og passede til deres filosofi. Sutherland talte om vigtigheden af scrum-masterens rolle, om Deming-cyklussen. Scrum-masterens rolle er at accelerere processen konstant. Alt andet, der er i scrum – faseopdeling, kundetilfredshed, en klar liste over opgaver for sprintperioden – er også vigtigt, men alt dette skal bevæge sig hurtigere og hurtigere. Arbejdshastigheden skal hele tiden øges i de enheder, hvori den måles.
Måske handler det her om oversættelsen, fordi vi har oversat bogen som "Scrum – en revolutionsmetode til projektledelse", men hvis man oversætter den engelske titel ordret, så bliver det: "Scrum – dobbelt så meget på halvt så kort tid", hvilket også i titlen henviser til hastigheden som en nøglefunktion i scrum.
Da denne fyr implementerede scrum, fordobledes hastigheden i den første måned uden nogen særlige ændringer. Han fandt punkter til ændringer, modificerede scrum til sig selv, så det arbejdede meget hurtigere. Det eneste, som de nævner på internettet, er spørgsmålet: "Vi har fordoblet hastigheden, men hvad skal vi gøre med så høj en hastighed?". Men det er en helt anden område…
Han anbefalede også personligt flere metoder. Han kaldte dem fundamentale og grundlæggende.
Den første er boundary management.
Det undervises om det på "Skolkovo", og ifølge drengen findes der ikke andre bøger eller materialer. Han har været så heldig at være til en forelæsning af en professor fra Harvard, som taler om boundary management, samt læse nogle artikler i Harvard Business Review om Eric Trists arbejde.
Boundary management handler om evnen til at se grænser og arbejde med dem. Der er grænser overalt - mellem afdelinger, mellem forskellige arbejdsformer, mellem funktioner, mellem operationel og analytisk arbejde. At kende til boundary management åbner ikke op for højere sandheder, men giver et anderledes perspektiv på virkeligheden - set gennem grænsers prism.
Men drengen talte mest om controlling. Han havde nærmest en besættelse på dette emne.
Controlling, kort sagt, er ledelse baseret på tal. Her er hver del af definitionen vigtig - både "ledelse", "baseret på" og "tal".
Vi har, sagde han, problemer med alle tre elementer af controlling. Især når man tager i betragtning, at de er tæt forbundet både med hinanden og med andre dele af forretningssystemet.
Det første, der er dårligt - er tallene. Der er for få, og de er af lav kvalitet.
En betydelig del af tallene tog vi dengang fra informationssystemet 1C. Kvaliteten af tallene i 1C, som han hævdede, er under lavmålet. I det mindste på grund af muligheden for at ændre data retroaktivt.
Det er klart, at udviklernes skyld i 1C ikke er problemet - de tager blot højde for markedets krav og den hjemlige regnskabsmentalitet. Men til controlling-formål burde arbejdsprincipperne for 1C med data ændres på det specifikke firma.
Desuden, ifølge ham, gennemgår tallene fra 1C en halvautomatisk behandling, for eksempel ved brug af Excel. Denne behandling bidrager heller ikke til kvaliteten eller hastigheden af dataene.
I sidste ende bliver den endelige rapport yderligere tjekket af nogen for at sikre, at der ikke utilsigtet gives ledelsen tal med fejl. Resultatet er, at tallene kommer til modtageren smukke, kontrollerede, men meget sent. Normalt - efter afslutningen af perioden (måned, uge, osv.).
Og her, sagde han, er alt meget simpelt. Hvis tallene fra januar når dig i februar, kan du ikke længere styre januar-aktiviteterne. Fordi januar allerede er slut.
Og hvis tallene er baseret på regnskab, og virksomheden er helt almindelig, med kvartalsvis momsafregning, så får virksomhedens leder relativt fornuftige tal en gang om kvartalet.
Derefter er det klart. Hvis I får tallene en gang om måneden, har I mulighed for at styre efter tallene (dvs. foretage kontrol) 12 gange om året. Praktiserer I kvartalsrapportering, styrer I 4 gange om året. Plus bonus — årsrapportering. En sidste chance for at styre.
Resten af tiden udføres styringen som regel blindt.
Når (og hvis) tallene alligevel fremkommer, træder det andet problem ind — hvordan styres der baseret på tallene? Her kunne jeg ikke helt enes med hans betragtninger.
Drengen hævdede, at hvis lederen tidligere ikke har haft tal, så vil deres fremkomst skabe en wow-effekt. Han vil se og lege med tallene på alle mulige måder, kalde folk til sig, kræve forklaringer og undersøgelser. Efter at have leget med tallene, lavet analyser og truet alle medarbejdere med: 'nu slipper jeg jer ikke,' vil lederen hurtigt miste interessen og lade det ligge. Han vil ikke længere bruge værktøjet. Men problemerne vil forblive.
Sådan sker det, sagde han, på grund af lederens utilstrækkelige kompetencer. Især i kontrollen. Lederen ved simpelthen ikke, hvad han skal gøre med disse tal. Hvad medman skal gøre — ved han, hvad man skal gøre — ved han ikke. At gøre — det er det, der er skrevet ovenfor (at skælde ud, lege). At handle — det er en daglig forretningsproces.
Han hævdede, at det er meget enkelt: tallet skal blive en del af forretningsprocessen. I forretningsprocessen skal det være klart, hvem der skal gøre hvad, og hvornår, hvis tallet afviger fra normen (alle varianter — over grænsen, under grænsen, ud over korridoren, forekomst af trend, manglende opfyldelse af kvantiler osv.)
Og her definerede han den centrale dilemma: tallet eksisterer, det skal blive en del af forretningssystemet for at øge effektiviteten af styringen, men... det sker ikke. Hvorfor?
Fordi den russiske leder ikke vil give konkurrenten en del af sin magt.
Konkurrenterne til den russiske leder — et kvalitets- og fungerende forretningsproces, gennemtænkt gensidig motivation og korrekt automatisering — vil desværre efterlade lederen uden job.
Er det ikke noget vrøvl? Især hvad angår lederne. Nå, jeg har fortalt det, nu må I selv afgøre.
Lidt mindre, men stadig for meget, efter min mening, talte han om scrum.
Det er vigtigt, sagde han, at læse og prøve scrum i praksis. Hvis du har læst, men ikke prøvet — så ved du ikke noget. Læs hellere en bog, for eksempel af Sutherland, end artikler og diverse guides (hvad er det for noget?) på internettet.
Scrum, sagde han, forstås kun gennem praksis, og med obligatoriske målinger af den udførte arbejdsbyrde. Prøv personligt de to vigtigste roller — produkt ejer og scrum-master.
Især vigtigt, ifølge fyren, er det at mærke rollen som scrum-master i praksis, når du kan øge mængden af opgaver, der lukkes i sprinten, uden at øge ressourcerne og omkostningerne ved sprinten.
Og så var TOC (Theory of Constraints) også blandt hans topvalg.
Dette, sagde fyren, er de grundlæggende, fundamentale principper for at øge effektiviteten, som kan anvendes praktisk i næsten alle områder, i enhver forretningsproces og forretningssystem i det hele taget.
Da han fandt ud af, at vi ikke var bekendte med TOC, stoppede han med at fortælle. Han tilføjede blot, at han ikke ville berøve os fornøjelsen ved at læse bøgerne af Eliyahu Goldratt. Han gav en tilsvarende anbefaling som til scrum — læs og prøv. Uanset hvilken stilling du besidder, uanset hvilket arbejde du udfører, vil der være plads til at øge effektiviteten ved hjælp af TOC-metoder.
Derefter, da hans vægt af metoder tilsyneladende var opbrugt, sagde han: bland principperne for at skabe anvendelige løsninger i den konkrete situation.
Dette, siger han, er den vigtigste anbefaling, nøglen til succes. Forstå principperne, essensen, og skab unikke anvendelige løsninger — forretningsprocesser og forretningssystemer.
Senere forsøgte han at huske et citat, og i sidste ende måtte han søge på internettet. Det viste sig at være et citat fra artiklen "Stående på gigantens skuldre" af Eliyahu Goldratt:
Der er en forskel mellem anvendelsesløsninger og de fundamentale koncepter, som disse løsninger bygger på. Koncepterne er generelle, mens anvendelsesløsninger er en tilpasning af koncepterne til en konkret kontekst. Som vi har set, er en sådan tilpasning ikke enkel og kræver udvikling af bestemte elementer af løsningen. Vi skal huske, at en anvendelsesløsning er baseret på grundlæggende forudsætninger (nogle gange skjulte) om den specifikke kontekst. Man skal ikke forvente, at denne anvendelsesløsning fungerer i en kontekst, hvor de grundlæggende forudsætninger ikke holder.
Han sagde, at arbejdet som programmør og "forbedrer af forretningsprocesser" er meget ens. Og han gik.
Kilde: habr.com
