Historien er ægte, jeg så alt med mine egne øjne.
I flere år arbejdede en fyr, som mange af jer, som programmør. For en sikkerheds skyld vil jeg skrive det på denne måde: "programmør." Fordi han var 1Snik, på et fix, produktionsselskab.
Før det prøvede han forskellige specialer - 4 år i Frankrig som programmør, projektleder, han var i stand til at gennemføre 200 timer, samtidig med at han modtog en procentdel af projektet, til ledelse og laver lidt salg. Jeg forsøgte at udvikle produkter på egen hånd, var leder af IT-afdelingen i en stor virksomhed med 6 tusinde mennesker, prøvede forskellige muligheder for at bruge mit citerede erhverv - 1C programmør.
Men alle disse stillinger var noget blindgyde, primært med hensyn til indkomst. På det tidspunkt fik vi alle nogenlunde de samme penge og arbejdede under de samme vilkår.
Denne fyr spekulerede på, hvordan han kunne tjene flere penge uden at sælge eller skabe sin egen virksomhed.
Han så sig selv som en smart fyr og besluttede at finde en niche i virksomheden, hvor han arbejdede. Denne niche skulle være noget særligt, ikke besat af nogen. Og jeg ønskede, at virksomheden selv ville betale penge til en person i denne niche, så der ikke skulle være behov for at snyde nogen eller snyde noget. For at nå dette mål: en person i denne stilling skal betales en masse penge. En excentriker, med et ord.
Eftersøgningen var kortvarig. I virksomheden, hvor denne fyr arbejdede, var der en helt gratis niche, der kunne kaldes "at sætte tingene i orden i forretningsprocesser." Hver virksomhed har mange problemer. Der er altid noget, der ikke fungerer, og der er ingen, der kommer og ordner forretningsprocessen. Så han besluttede at prøve sig selv som en specialist, der kan hjælpe ejeren med at løse sine problemer i forretningsprocesser.
På det tidspunkt havde han arbejdet i virksomheden i seks måneder og fik gennemsnitslønnen på markedet. Der var intet at tabe, især da han nemt kunne finde det samme job inden for en uge. Generelt besluttede denne fyr, at der ikke ville ske noget dårligt, hvis intet pludselig fungerede, og han blev fyret.
Han tog mod til sig og kom til ejeren. Jeg foreslog, at han forbedrede den mest problematiske proces i virksomheden. Dengang var det lagerregnskab. Nu skammer alle, der arbejder i denne virksomhed, sig endda over at huske disse problemer, men opgørelser, der blev udført kvartalsvis, viste uoverensstemmelser mellem regnskabssystemet og faktiske saldi på titusinder af procent. Og i omkostninger, og i mængde og i antallet af positioner. Det var en katastrofe. Virksomheden havde faktisk kun de korrekte saldi i regnskabssystemet fire gange om året – dagen efter lageroptællingen. Vores fyr begyndte at bringe denne proces i orden.
Fyren aftalte med ejeren, at han skulle reducere afvigelserne fra lagerresultaterne med det halve. Desuden havde ejeren ikke noget særligt at tabe, for før vores helt havde forskellige arbejdere allerede gjort forsøg på at reparere alt, og generelt blev opgaven betragtet som praktisk talt uløselig. Alt dette gav stor næring til interessen, for hvis alt fungerede, ville fyren automatisk blive en person, der ved, hvordan man bringer tingene i orden og løser uløselige problemer.
Så han stod over for opgaven: at reducere afvigelser baseret på lagerresultater med 2 gange inden for et år. I starten af projektet anede han ikke, hvordan han skulle opnå dette, men han forstod, at lagerregnskab er en simpel ting, så han ville stadig være i stand til at gøre noget nyttigt. Desuden ser det ikke ud til at være så svært at reducere afvigelser fra XNUMX af procent til XNUMX XNUMX procent. Enhver, der har arbejdet med rådgivning eller lignende aktiviteter, forstår, at de fleste procesproblemer kan løses med ret enkle trin.
Fra januar til maj forberedte han sig, automatiserede noget lidt, omskrev lagerregnskabets forretningsproces, ændrede arbejdsgangene for butiksejere, revisorer og lavede generelt hele systemet om uden at vise eller fortælle noget til nogen. I maj delte han nye instruktioner ud til alle, og efter årets første opgørelse begyndte et nyt liv – at arbejde efter hans regler. For at observere resultaterne begyndte virksomheden i fremtiden at foretage opgørelser oftere - en gang hver anden måned. Allerede de første resultater var positive, og ved årets udgang var afvigelserne fra revisionsresultaterne faldet til en brøkdel af én procent.
Succesen var kolossal, men man kunne ikke tro på dens bæredygtighed. Fyren tvivlede selv på, at resultatet ville blive bevaret, hvis han trådte til side og holdt op med at observere processen. Ikke desto mindre var der et resultat, og fyren modtog alt, hvad han aftalte med ejeren. Derefter, efter flere år, blev stabiliteten af resultatet bekræftet - i flere år forblev afvigelserne inden for 1%.
Så besluttede han at gentage eksperimentet og foreslog, at ejeren forbedrede en anden problematisk proces - forsyning. Der var mangel, som ikke tillod os at sende de mængder, som vores kunder ønskede. Vi blev enige om, at underskuddene inden for et år skulle være halveret, og fyren ville også gennemføre 10-15 projekter relateret til 1C - for at automatisere diverse forretningsprocesser og andre kætterier.
I det andet år blev alt afsluttet med succes igen, underskuddet faldt med mere end 2 gange, alle IT-projekter blev afsluttet med succes.
Da lønnen allerede fuldt ud opfyldte alle den fyrs behov i to år i forvejen, besluttede han at slå sig lidt ned, falde til ro og sidde et hyggeligt, varmt sted, som han havde skabt til sig selv.
Hvad var det ligesom? Formelt var han it-direktør. Men hvem han egentlig var, er svært at forstå. Når alt kommer til alt, hvad laver en it-direktør? Som regel administrerer han IT-infrastrukturen, administrerer systemadministratorer, implementerer et ERP-system og deltager i bestyrelsesmøder.
Og denne fyr havde et af nøgleansvarene for at deltage i forandringsprocesser, og hovedsageligt - generering, igangsættelse af disse processer, søgning og forslag til løsninger, anvendelse af nye ledelsesteknikker, undersøgelse af foreslåede ændringer, analyse af effektiviteten af andre funktioner og divisioner og endelig direkte deltagelse i virksomhedens strategiske udvikling frem til selvstændig udvikling af en strategisk plan for hele virksomheden.
Han fik carte blanche. Han kunne komme til ethvert møde, hvor han ikke tidligere havde haft adgang. Jeg sad der med en notesblok, skrev noget ned eller lyttede bare. Han talte sjældent. Så begyndte han at spille på telefonen og hævdede, at associativ hukommelse fungerer bedre på denne måde.
På mødet gav han sjældent noget brugbart ud. Han gik, tænkte, så kom der et brev - enten med kritik, eller med en mening, eller med forslag eller med en beskrivelse af de løsninger, som han allerede havde anvendt.
Men oftere indkaldte han selv til møder. Jeg fandt et problem, fandt på løsninger, identificerede interesserede og fik alle med ind i mødet. Og så - så godt han kunne. Han overbeviste, motiverede, beviste, argumenterede, opnåede.
Uofficielt blev han betragtet som den tredje person i virksomheden, efter ejeren og direktøren. Selvfølgelig gjorde han frygtelig rasende alle "virksomhedens personer", begyndende med nummer 4. Især med sine iturevne jeans og lyse T-shirts, og også med sin tid som ejer.
Ejeren gav ham 1 time om dagen. Hver dag. De talte, diskuterede problemer, løsninger, nye virksomheder, udviklingsområder, indikatorer og effektivitet, personlig udvikling, bøger og simpelthen livet.
Men denne fyr var mærkelig. Det er ligesom, læn dig tilbage og vær glad, livet er godt. Men nej. Han besluttede at reflektere.
Han undrede sig: hvorfor gik det for ham, men andre gjorde det ikke? Ejeren pressede ham også: han sagde, at han ønskede, at andre også skulle være i stand til at genoprette orden, fordi der er mange ledere, de er som regel engageret i operationel ledelse og strategisk planlægning, men praktisk talt ingen er involveret i systemiske ændringer i deres processer. Det kan være skrevet i deres jobbeskrivelse, at de skal fremskynde deres proces og øge dens effektivitet, men faktisk er der ingen, der gør dette. Hvorfor det? Fyren blev også interesseret i hvorfor, og han gik for at tale med alle disse ledere.
Han kom til vicedirektøren for kvalitet og foreslog at introducere Shewhart kontroldiagrammer, så produkterne ville være bedre end japanske. Men det viste sig, at kollegaen ikke vidste, hvad Shewhart kontroldiagrammer var, hvad statistisk proceskontrol var, og kun havde hørt om brugen af Deming-cyklussen i kvalitetsstyring. OKAY…
Han gik til en anden vicedirektør og foreslog at indføre kontrol. Men jeg fandt heller ikke støtte her. Lidt senere lærte han om grænsestyring (boundary management) og foreslog, at alle vicedirektører implementerede den systemiske del af denne metode for at forbedre processer. Men uanset hvor meget vores fyr snakkede, var der ingen, der rigtig ville dykke ned i, hvad det handlede om. Måske var de ikke interesserede, eller det var for svært. Men faktisk var der ingen, der fandt ud af det.
Generelt talte han om alt, hvad han kendte og brugte i virksomheden. Men ingen forstod ham. De forstår stadig ikke, hvorfor for eksempel alt blev rettet i lagerregnskabet, og hvad har kontrol og grænsestyring med det at gøre.
Sidst af alt nåede han sine programmører - personalet omfattede 3 personer. Han talte om grænsestyring, om kontrol, om kvalitetsstyring, om agile og scrum... Og overraskende nok forstod de alt, og var endda i stand til at diskutere med ham, inklusive tekniske og metodiske finesser. De forstod, hvorfor lager- og forsyningsprojekterne lykkedes. Og så gik det op for fyren: Faktisk vil programmører redde verden.
Programmører, indså han, er de eneste, der kan forstå forretningsprocesser normalt med de nødvendige detaljer.
Hvorfor dem? Faktisk fandt han aldrig et klart svar. Jeg formulerede kun afhandlingstips.
For det første kender programmører fagområderne i virksomheden, og de kender dem bedre end alle andre i virksomheden.
Derudover forstår programmører virkelig, hvad en procesalgoritme er. Dette er vigtigt, fordi forretningsprocesser er algoritmer, og elementerne i dem kan simpelthen ikke være konsistente. For eksempel i indkøbsprocessen, som fyren arbejdede på, var det første trin at oprette en årlig indkøbsplan, og det andet var daglige indkøb. Disse trin er forbundet med en direkte forbindelse, det vil sige, det antages, at folk skal arbejde i henhold til denne algoritme - udarbejde en årlig indkøbsplan og straks udføre anmodningen. Den årlige indkøbsplan udarbejdes én gang årligt, og ansøgninger modtages 50 gange dagligt. Det er her algoritmen slutter, og du skal arbejde på den. Faktisk, ræsonnerede han, for programmører er viden om algoritmer en konkurrencefordel, fordi enhver anden, der ikke er bekendt med dem, simpelthen ikke forstår, hvordan en forretningsproces skal fungere, og hvordan den kan repræsenteres.
En anden fordel ved programmører, ifølge fyren, er, at de har nok fritid. Vi forstår alle, hvordan en programmør kan bruge tre gange længere tid på en opgave, end den faktisk kræver, og få vil bemærke det. Dette er igen en konkurrencefordel, for for at bringe nogle forretningsprocesser i orden, skal du have en masse 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 han ikke har tid til at forbedre effektiviteten - en ond cirkel. I vores kultur er det moderne at have travlt, 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, sagde han, kan hurtigt ændre et informationssystem. Dette gælder ikke for alle virksomheder, men hvor han end arbejdede, kunne han foretage de ændringer, han ønskede. Især hvis de ikke vedrører andres arbejde. For eksempel kunne han lancere et system, der hemmeligt måler brugerhandlinger, og derefter bruge disse oplysninger til at analysere effektiviteten af den samme regnskabsafdeling og spore omkostningerne ved regnskabsføring.
Og det sidste, jeg husker fra hans ord, er, at programmører har adgang til en stor mængde information, fordi... har administrativ adgang til systemet. Derfor kan de bruge denne information i deres analyse. Ingen andre på et almindeligt anlæg har sådan en ressource.
Og så gik han. Under de påkrævede to ugers tilbageholdelse tvang vi ham til at dele sin erfaring, fordi vi ønskede at fortsætte det arbejde, han udførte. Nå, hans stilling blev ledig.
I løbet af flere dage satte de ham på en stol, tændte kameraet og optog hans monologer. De bad om at fortælle os om alle afsluttede projekter, metoder, tilgange, succeser og fiaskoer, årsager og virkninger, portrætter af ledere mv. Der var ingen særlige restriktioner, pga De vidste ikke, hvad der foregik i hans hoved.
Monologerne var selvfølgelig for det meste pjat og grin – han var i godt humør, fordi var på vej ud af outbacken til St. Petersborg. Hvor skal du tage hen for at arbejde i St. Petersborg? Til Gazprom, selvfølgelig.
Men det lykkedes os at uddrage noget nyttigt fra hans monologer. Jeg skal fortælle dig, hvad jeg husker.
Så fyrens anbefalinger. For dem, der vil forsøge at bringe tingene i orden i forretningsprocesser.
For at udføre denne form for arbejde skal du for det første have et vist niveau af "frostbid". Du skal ikke være bange for at miste dit job, ikke være bange for at tage risici, ikke være bange for konflikter med kolleger. Det var let for ham, for han begyndte sin rejse, da han kun havde arbejdet i virksomheden i et halvt år, og ikke havde tid til at komme i kontakt med nogen, og ikke havde tænkt sig at gøre det. Han forstod, at folk kommer og går, men hans egne resultater og deres vurdering fra virksomhedsejeren er vigtige for ham. Hvorvidt hans kolleger behandlede ham godt eller dårligt, bekymrede ham ikke meget dengang.
Det andet punkt er, at for effektivt at kunne udføre dette arbejde, bliver du desværre nødt til at studere. Men læs ikke til en MBA, ikke i kurser, ikke på institutter, men på egen hånd. For eksempel i sit første projekt, et lagerprojekt, handlede han intuitivt, han vidste ikke noget, bare hvad "kvalitetsstyring" var.
Da han begyndte at læse litteraturen om, hvilke metoder der fandtes til at øge effektiviteten, opdagede han de teknologier, han brugte. Fyren anvendte dem intuitivt, men det viser sig, at dette ikke var hans opfindelse, alt var allerede skrevet for længe siden. Men han brugte tid, og meget mere, end hvis han straks havde læst den rigtige bog. Her er det kun vigtigt at forstå, at når du studerer en bestemt teknik, vil ikke en af dem, selv den mest avancerede, fuldstændig løse alle problemerne i en forretningsproces.
Det andet trick er, at jo flere teknikker du kender, jo bedre. For eksempel levede Miyamoto Musashi i det gamle Japan, en af de mest berømte sværdkæmpere, forfatteren til to-sværdstilen. Han studerede på en skole med en mester, rejste derefter rundt i Japan, kæmpede med forskellige fyre. Hvis fyren var stærkere, stoppede rejsen i nogen tid, og Musashi blev student. Som følge heraf tilegnede han sig gennem flere år færdighederne i forskellige praksisser fra forskellige mestre og dannede sin egen skole og tilføjede noget af sit eget. Som et resultat opnåede han en unik færdighed. Det er det samme her.
Du kan selvfølgelig fungere som virksomhedskonsulent. Generelt er de gode fyre. Men som regel kommer de for at indføre en form for metodik, og de implementerer den forkerte metode, som virksomheden har brug for. Vi havde også sådanne triste situationer: ingen ved, hvordan man løser problemet, og ingen ønsker at tænke på, hvordan man løser det. Vi begynder at søge enten på internettet eller ringer til en konsulent og spørger ham, hvad der kan hjælpe os. Konsulenten tænker og siger, at vi skal introducere teorien om begrænsninger. Vi betaler ham for hans anbefaling, vi bruger penge på implementering, men resultaterne er nul.
Hvorfor sker dette? Fordi konsulenten sagde, vi indfører sådan og sådan et system, og alle var enige med ham. Fantastisk, men én metode dækker ikke alle problemerne i en enkelt forretningsproces, især hvis de indledende forudsætninger - vores og dem, der kræves for at implementere metoden - ikke er sammenfaldende.
I den praksis, som fyren anbefaler, skal du tage det bedste og implementere det bedste. Tag ikke helt metoderne, men tag deres nøglefunktioner, funktioner og praksisser. Og det vigtigste er at forstå essensen.
Tag, sagde han, for eksempel Scrum eller Agile. I sine monologer gentog fyren mange gange, at ikke alle fuldt ud forstår essensen af Scrum. Han læste også Jeff Sutherlands bog, som nogle mennesker finder "let læsning". Det virkede som en dyb læsning for ham, for et af de grundlæggende principper i Scrum er kvalitetsstyring, dette er skrevet direkte i bogen.
Det siger om Toyota Production, om hvordan Jeff Sutherland viste Scrum i Japan, hvordan det slog rod der og hvor tæt det var på deres filosofi. Og Sutherland talte om vigtigheden af rollen som Scrum Master, om Deming-cyklussen. Scrum Masterens rolle er konstant at fremskynde processen. Alt det andet, der er i Scrum - trinvis levering, kundetilfredshed, en overskuelig liste over arbejde til sprintperioden - er også vigtigt, men alt dette skal gå hurtigere og hurtigere. Arbejdshastigheden skal konstant stige i de enheder, den måles i.
Måske er dette et spørgsmål om oversættelse, fordi vores bog blev oversat som "Scrum - en revolutionær metode til projektledelse", og hvis den engelske titel oversættes bogstaveligt, vil det vise sig: "Scrum - dobbelt så meget på den halve tid" , det vil sige selv i Navnet henviser til hastighed som en nøglefunktion i Scrum.
Da denne fyr implementerede Scrum, blev hastigheden fordoblet i den første måned uden nogen væsentlige ændringer. Han fandt point til forandring og modificerede selve Scrum for at få det til at fungere meget hurtigere. Det eneste, de skriver på internettet, er, at de blev stillet over for spørgsmålet: "Vi har fordoblet hastigheden, det eneste, der er tilbage, er at forstå, hvad vi laver med sådan en hastighed?" Det er dog et helt andet område...
Han anbefalede også personligt flere teknikker. Han kaldte dem fundamentale og fundamentale.
Den første er grænsestyring.
De underviser i det på Skolkovo; ifølge fyren er der ingen andre bøger og materialer. Han var på en eller anden måde heldig nok til at overvære et foredrag af en professor fra Harvard, der prædiker grænsestyring, og læste også flere artikler i Harvard Business Review om Eric Trists arbejde.
Boundary management siger, at man skal kunne se grænser og arbejde med grænser. Der er masser af grænser, de er overalt – mellem afdelinger, mellem forskellige typer arbejde, mellem funktioner, mellem operationelt og analytisk arbejde. Viden om grænsestyring afslører ingen højere sandheder, men den giver os mulighed for at se virkeligheden i et lidt andet lys – gennem grænsernes prisme. Og i overensstemmelse hermed, håndter dem - rejs dem, hvor det er nødvendigt, og fjern dem, hvor de er i vejen.
Men oftest talte fyren om at kontrollere. Han havde bare en slags særhed om dette emne.
Styring er kort sagt styring baseret på tal. Her, sagde han, er hver del af definitionen vigtig - både "ledelse" og "baseret på" og "tal".
Vi, sagde han, er dårlige til alle tre komponenter i at kontrollere. Især i betragtning af, 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 få af dem, og de er af lav kvalitet.
Vi tog derefter en væsentlig del af tallene fra 1C informationssystemet. Så kvaliteten af tallene i 1C, som han hævdede, er ikke god. Som minimum på grund af muligheden for at ændre data med tilbagevirkende kraft.
Det er klart, at dette ikke er 1C-udviklernes skyld - de tager kun hensyn til markedets krav og mentaliteten i indenlandsk regnskab. Men til kontrolformål er det bedre at ændre principperne for 1C-arbejde med data på en specifik virksomhed.
Ydermere gennemgår tallene fra 1C ifølge ham semi-manuel behandling, f.eks. ved hjælp af Excel. En sådan behandling tilføjer heller ikke kvalitet til dataene, såvel som effektivitet.
Til sidst dobbelttjekker en anden den endelige rapport for ikke ved et uheld at indsende tal med fejl til lederen. Som et resultat når tallene frem til modtageren smukt, verificeret, men meget sent. Normalt - efter periodens afslutning (måned, uge osv.).
Og her, sagde han, er alt meget enkelt. Hvis tallene om januar kom til dig i februar, så kan du ikke længere administrere januars aktiviteter. For januar er allerede slut.
Og hvis tallene er regnskabsmæssige, og virksomheden er den mest almindelige, med kvartalsvis indberetning af moms, så modtager dens leder relativt fyldestgørende tal en gang i kvartalet.
Resten er klart. Du modtager numre en gang om måneden - du har mulighed for at styre efter numre (dvs. styre) 12 gange om året. Øver du kvartalsrapportering, klarer du det 4 gange om året. Plus en bonus - årsrapportering. Styr en gang til.
Resten af tiden udføres kontrol som regel blindt.
Når (og hvis) tallene dukker op, så kommer det andet problem i spil - hvordan kan man klare sig ud fra tallene? Jeg kunne ikke tilslutte mig dette punkt i hans ræsonnement.
Fyren hævdede, at hvis manageren ikke havde tallene før, ville deres udseende forårsage en wow-effekt. Han vil se og dreje tallene på den ene og den anden måde, ringe til folk på gulvtæppet, kræve forklaringer og undersøgelser. Efter at have leget med tal, foretaget analyser og truende lovet alle medarbejdere, at "nu slipper jeg ikke af med jer", vil lederen meget hurtigt falde til ro og give op i denne sag. Stop med at bruge værktøjet. Men problemerne vil forblive på plads.
Dette sker, sagde han, på grund af utilstrækkelige ledelsesmæssige kompetencer. I kontrol, først og fremmest. Lederen ved simpelthen ikke, hvad han skal gøre med disse tal. Hvad сat gøre - ved hvad de skal gøre - nej. At gøre er det, der er skrevet om ovenfor (at skændes, at spille). At gøre er en daglig forretningsproces.
Han argumenterede for, at alt er meget enkelt: digital skal blive en del af forretningsprocessen. I forretningsprocessen skal det være klart klart: hvem skal gøre hvad og hvornår, hvis tallene afviger fra normen (enhver muligheder - over grænsen, under grænsen, gå ud over korridoren, tilstedeværelsen af en trend, manglende opfyldelse af kvantil osv.)
Og så skitserede han det centrale dilemma: tallet eksisterer, det burde blive en del af forretningssystemet for at øge ledelseseffektiviteten, men... det sker ikke. Hvorfor?
Fordi den russiske leder ikke vil opgive en del af sin magt til en konkurrent.
Den russiske managers konkurrenter - en højkvalitets og fungerende forretningsproces, gennemtænkt gensidigt fordelagtig motivation og ordentlig automatisering - desværre vil forlade lederen uden job.
Sikke noget sludder, er du ikke enig? Især om ledere. Okay, jeg sagde jo, du bestemmer selv.
Lidt mindre, men stadig for meget, efter min mening, talte han om Scrum.
Vær sikker på, sagde jeg, læs og prøv Scrum i praksis. Hvis, siger han, du har læst det, men ikke har prøvet det, så betragte dig selv som uvidende. Det er bedre at læse en bog, for eksempel af Sutherland, frem for artikler og alle mulige vejledninger (hvad fanden?) på internettet.
Scrum, sagde han, kan kun læres gennem praksis og med obligatoriske målinger af mængden af udført arbejde. Prøv personligt de to vigtigste roller - Product Owner og Scrum Master.
Det er især vigtigt, ifølge fyren, i praksis at opleve rollen som Scrum Master, når man kan øge mængden af opgaver udført pr. sprint uden at øge ressourcerne og omkostningerne ved spurten.
Nå, i hans top var der TOS (teori om systembegrænsninger).
Disse er ifølge fyren de grundlæggende, grundlæggende principper for at øge effektiviteten, som kan anvendes på næsten ethvert område, i enhver forretningsproces og forretningssystem som helhed.
Da han fandt ud af, at vi ikke var bekendt med TOS, holdt han op med at fortælle os det. Han tilføjede kun, at han ikke ville fratage os fornøjelsen ved at læse Eliyahu Goldratts bøger. Han gav en lignende anbefaling til Scrum - læs den og prøv den. Ligesom, uanset hvilken stilling du er i, uanset hvilket arbejde du udfører, er der plads til at øge effektiviteten ved hjælp af TOC-metoder.
Så tørrede hans pose med teknikker tilsyneladende ud, og han sagde: bland principperne for at skabe anvendte løsninger i en specifik situation.
Dette, siger han, er hovedanbefalingen, nøglen til succes. Forstå principperne, essensen og skabe unikke applikationsløsninger - forretningsprocesser og forretningssystemer.
Så forsøgte han at huske et eller andet citat, og til sidst måtte han gå på nettet. Det viste sig at være et citat fra artiklen "Standing on the Shoulders of Giants" af Eliyahu Goldratt:
"Der er forskel på anvendte løsninger (applikationer) og de grundlæggende koncepter, som disse løsninger er baseret på. Koncepter er generelle; anvendte løsninger er tilpasning af koncepter til et specifikt miljø. Som vi allerede har set, er en sådan tilpasning ikke enkel og kræver udvikling af visse elementer i løsningen. Vi skal huske, at en applikationsløsning er baseret på indledende antagelser (nogle gange skjulte) om et specifikt miljø. Denne applikationsløsning bør ikke forventes at fungere i et miljø, hvor antagelserne ikke er korrekte."
Han sagde, at arbejdet med en programmør og en "forretningsprocesforbedrer" er meget ens. Og gik.
Kilde: www.habr.com