Historien er ekte, jeg så alt med mine egne øyne.
I flere år jobbet en fyr, som mange av dere, som programmerer. Bare i tilfelle, vil jeg skrive det på denne måten: "programmerer." Fordi han var 1Snik, på en fiks, produksjonsselskap.
Før det prøvde han forskjellige spesialiteter - 4 år i Frankrike som programmerer, prosjektleder, han var i stand til å fullføre 200 timer, samtidig som han fikk en prosentandel av prosjektet, for ledelse og litt salg. Jeg prøvde å utvikle produkter på egen hånd, var sjef for IT-avdelingen i et stort selskap med 6 tusen mennesker, prøvde forskjellige alternativer for å bruke mitt siterbare yrke - 1C-programmerer.
Men alle disse stillingene var noe blindvei, først og fremst inntektsmessig. På den tiden fikk vi alle omtrent de samme pengene og jobbet under de samme forholdene.
Denne fyren lurte på hvordan han kunne tjene mer penger uten å selge eller opprette sin egen virksomhet.
Han fant seg en smart fyr og bestemte seg for å finne en nisje i selskapet der han jobbet. Denne nisjen måtte være noe spesielt, ikke okkupert av noen. Og jeg ville at selskapet selv skulle betale penger til en person i denne nisjen, slik at det ikke skulle være behov for å lure noen eller jukse noe. For å gjøre dette målet: en person i denne stillingen må betales mye penger. En eksentrisk, med et ord.
Søket ble kortvarig. I selskapet der denne fyren jobbet, var det en helt gratis nisje som kan kalles "å sette ting i orden i forretningsprosesser." Hvert selskap har mange problemer. Det er alltid noe som ikke fungerer, og det er ingen person som vil komme og fikse forretningsprosessen. Så han bestemte seg for å prøve seg som en spesialist som kan hjelpe eieren med å løse problemene sine i forretningsprosesser.
Da hadde han jobbet i selskapet i seks måneder og mottatt gjennomsnittslønnen i markedet. Det var ingenting å tape, spesielt siden han lett kunne finne samme jobb innen en uke. Generelt bestemte denne fyren seg for at ingenting vondt ville skje hvis det plutselig ikke gikk noe som helst og han fikk sparken.
Han tok mot til seg og kom til eieren. Jeg foreslo at han skulle forbedre den mest problematiske prosessen i virksomheten. Den gang var det lagerregnskap. Nå skammer alle som jobber i dette selskapet til og med å huske disse problemene, men varelager, som ble utført kvartalsvis, viste avvik mellom regnskapssystemet og faktiske saldoer på titalls prosent. Og i kostnad, og i mengde, og i antall stillinger. Det var en katastrofe. Bedriften hadde faktisk riktige saldoer i regnskapssystemet kun fire ganger i året – dagen etter varetellingen. Fyren vår begynte å ordne denne prosessen.
Fyren ble enig med eieren om at han skulle halvere avvikene fra lagerresultatene. Dessuten hadde eieren ikke noe spesielt å tape, for før vår helt hadde forskjellige arbeidere allerede gjort forsøk på å fikse alt, og generelt ble oppgaven ansett som praktisk talt uløselig. Alt dette skapte stor interesse, for hvis alt ordnet seg, ville fyren automatisk bli en person som vet hvordan man setter ting i orden og løser uløselige problemer.
Så han sto overfor oppgaven: å redusere avvik basert på lagerresultater med 2 ganger i løpet av et år. Ved starten av prosjektet hadde han ingen anelse om hvordan han skulle få til dette, men han forsto at lagerregnskap er en enkel ting, så han ville fortsatt kunne gjøre noe nyttig. Dessuten ser det ikke ut til å være så vanskelig å redusere avvik fra titalls prosent til én titalls prosent. Alle som har jobbet med rådgivning eller lignende virksomhet forstår at de fleste prosessproblemer kan løses med ganske enkle grep.
Fra januar til mai forberedte han, automatiserte noe litt, omskrev lagerregnskapets forretningsprosess, endret arbeidsflytene til lagerholdere, regnskapsførere og generelt omgjort hele systemet, uten å vise eller fortelle noe til noen. I mai delte han ut nye instruksjoner til alle, og etter årets første inventar begynte et nytt liv – å jobbe etter hans regler. For å observere resultatene begynte selskapet i fremtiden å gjennomføre varelager oftere - en gang annenhver måned. Allerede de første resultatene var positive, og ved utgangen av året var avvikene fra revisjonsresultatene sunket til en brøkdel av én prosent.
Suksessen var kolossal, men man kunne ikke tro på bærekraften. Fyren tvilte selv på at resultatet ville bli bevart hvis han gikk til side og sluttet å observere prosessen. Likevel ble det et resultat, og fyren fikk alt han ble enige om med eieren. Så, etter flere år, ble stabiliteten til resultatet bekreftet - i flere år holdt avvikene seg innenfor 1%.
Så bestemte han seg for å gjenta eksperimentet og foreslo at eieren skulle forbedre en annen problematisk prosess - forsyning. Det var mangel som ikke tillot oss å sende volumene våre kunder ønsket. Vi ble enige om at innen et år skulle underskuddene halveres, og karen skulle også gjennomføre 10-15 prosjekter knyttet til 1C – for å automatisere ulike forretningsprosesser og andre kjetterier.
I det andre året ble alt vellykket fullført igjen, underskudd redusert med mer enn 2 ganger, alle IT-prosjekter ble fullført.
Siden lønnen allerede fullt ut tilfredsstilte alle behovene til den fyren i to år i forveien, bestemte han seg for å slå seg ned litt, roe seg ned og sitte på et koselig, varmt sted han hadde skapt for seg selv.
Hvordan var det? Formelt sett var han IT-direktør. Men hvem han egentlig var, er vanskelig å forstå. Tross alt, hva gjør en IT-direktør? Som regel administrerer han IT-infrastrukturen, administrerer systemadministratorer, implementerer et ERP-system og deltar i styremøter.
Og denne karen hadde et av hovedansvarene for å delta i endringsprosesser, og hovedsakelig - generering, initiering av disse prosessene, søk og forslag til løsninger, anvendelse av nye ledelsesteknikker, undersøkelse av foreslåtte endringer, analyse av effektiviteten til andre funksjoner og divisjoner, og til slutt direkte deltakelse i den strategiske utviklingen av bedriften, frem til selvstendig utvikling av en strategisk plan for hele selskapet.
Han fikk carte blanche. Han kunne komme til et hvilket som helst møte hvor han ikke tidligere hadde hatt tilgang. Jeg satt der med en notisblokk, skrev ned noe, eller bare lyttet. Han snakket sjelden. Så begynte han å spille på telefonen, og hevdet at assosiativ hukommelse fungerer bedre på denne måten.
På møtet ga han sjelden ut noe nyttig. Han dro, tenkte, så kom det et brev - enten med kritikk, eller med en mening, eller med forslag, eller med en beskrivelse av løsningene som han allerede hadde brukt.
Men oftere innkalte han selv til møter. Jeg fant et problem, kom med løsninger, identifiserte interesserte og tok med alle inn i møtet. Og så – så godt han kunne. Han overbeviste, motiverte, beviste, argumenterte, oppnådde.
Uoffisielt ble han ansett som den tredje personen i selskapet, etter eieren og direktøren. Selvfølgelig irriterte han alle "personene i selskapet", og startet med nummer 4. Spesielt med sine revne jeans og lyse T-skjorter, og også med sin tid som eier.
Eieren ga ham 1 time om dagen. Hver dag. De snakket, diskuterte problemer, løsninger, nye virksomheter, utviklingsområder, indikatorer og effektivitet, personlig utvikling, bøker og rett og slett livet.
Men denne fyren var merkelig. Det er som, len deg tilbake og vær glad, livet er bra. Men nei. Han bestemte seg for å reflektere.
Han lurte på: hvorfor fungerte det for ham, men andre gjorde det ikke? Eieren presset ham også: han sa at han ønsket at andre også skulle kunne gjenopprette orden, fordi det er mange ledere, de er som regel engasjert i operativ ledelse og strategisk planlegging, men praktisk talt ingen er engasjert i systemiske endringer i deres prosesser. Det kan være skrevet i stillingsbeskrivelsen deres at de bør fremskynde prosessen og øke effektiviteten, men det er faktisk ingen som gjør dette. Hvorfor det? Fyren ble også interessert i hvorfor, og han gikk for å snakke med alle disse lederne.
Han kom til underdirektøren for kvalitet og foreslo å introdusere Shewhart-kontrolldiagrammer slik at produktene skulle bli bedre enn japanske. Men det viste seg at kollegaen ikke visste hva Shewhart-kontrolldiagrammer var, hva statistisk prosesskontroll var, og bare hadde hørt om bruken av Deming-syklusen i kvalitetsstyring. OK...
Han gikk til en annen nestleder og foreslo å innføre kontroll. Men jeg fant heller ikke støtte her. Litt senere lærte han om grensestyring (grensestyring) og foreslo at alle underdirektører implementerte den systemiske delen av denne metodikken for å forbedre prosessene. Men uansett hvor mye fyren vår snakket, var det ingen som ville fordype seg i hva det handlet om. Kanskje de ikke var interessert, eller det var for vanskelig. Men faktisk var det ingen som fant ut av det.
Generelt snakket han om alt han visste og brukte i selskapet. Men ingen forsto ham. De forstår fortsatt ikke hvorfor for eksempel alt ble korrigert i lagerregnskap, og hva har kontroll og grensestyring med det å gjøre.
Sist av alt nådde han programmererne sine - staben inkluderte 3 personer. Han snakket om grensestyring, om kontroll, om kvalitetsstyring, om smidig og scrum... Og overraskende nok forsto de alt, og kunne til og med diskutere med ham, inkludert tekniske og metodiske finesser. De forsto hvorfor lager- og forsyningsprosjektene fungerte. Og så gikk det opp for fyren: faktisk vil programmerere redde verden.
Programmerere, innså han, er de eneste som kan forstå forretningsprosesser normalt, med de nødvendige detaljene.
Hvorfor dem? Faktisk fant han aldri noe klart svar. Jeg formulerte kun oppgavetips.
For det første kjenner programmerere fagområdene til virksomheten, og de kjenner dem bedre enn alle andre personer i selskapet.
I tillegg forstår programmerere virkelig hva en prosessalgoritme er. Dette er viktig fordi forretningsprosesser er algoritmer, og elementene i dem kan rett og slett ikke være konsistente. For eksempel, i anskaffelsesprosessen fyren jobbet med, var det første trinnet å lage en årlig innkjøpsplan, og det andre var daglige innkjøp. Disse trinnene er forbundet med en direkte forbindelse, det vil si at det antas at folk skal jobbe i henhold til denne algoritmen - utarbeide en årlig anskaffelsesplan og utføre forespørselen umiddelbart. Årlig anskaffelsesplan utarbeides en gang i året, og søknader mottas 50 ganger daglig. Det er her algoritmen slutter, og du må jobbe med den. Faktisk, begrunnet han, for programmerere er kunnskap om algoritmer et konkurransefortrinn, fordi alle andre som ikke er kjent med dem rett og slett ikke forstår hvordan en forretningsprosess skal fungere og hvordan den kan representeres.
En annen fordel med programmerere, ifølge fyren, er at de har nok fritid. Vi forstår alle hvordan en programmerer kan bruke tre ganger lengre tid på en oppgave enn den faktisk krever, og få vil legge merke til det. Dette er igjen et konkurransefortrinn, for for å få orden på en forretningsprosess må du ha mye fritid - tenk, observer, studer og prøv.
De fleste ledere, ifølge fyren, har ikke denne fritiden og er stolte av den. Selv om dette faktisk betyr at en person ikke kan bli effektiv fordi han ikke har tid til å forbedre effektiviteten - en ond sirkel. I vår kultur er det mote å være opptatt, så alt forblir det samme. Og for oss programmerere er dette en fordel. Vi kan finne fritid og tenke på alt.
Programmerere, sa han, kan raskt endre et informasjonssystem. Dette er ikke aktuelt i alle virksomheter, men uansett hvor han jobbet, kunne han gjøre hvilke endringer han ville. Spesielt hvis de ikke angår andres arbeid. For eksempel kan han lansere et system som i hemmelighet måler brukerhandlinger, og deretter bruke denne informasjonen til å analysere effektiviteten til samme regnskapsavdeling og spore kostnadene ved regnskap.
Og det siste jeg husker fra ordene hans er at programmerere har tilgang til en stor mengde informasjon, fordi... ha administrativ tilgang til systemet. Derfor kan de bruke denne informasjonen i sin analyse. Ingen andre ved et vanlig anlegg har en slik ressurs.
Og så dro han. Under den påkrevde to ukers varetektsfengslingen tvang vi ham til å dele sin erfaring fordi vi ønsket å fortsette arbeidet han gjorde. Vel, stillingen hans ble ledig.
I løpet av flere dager satte de ham på en stol, skrudde på kameraet og tok opp monologene hans. De ba om å fortelle oss om alle gjennomførte prosjekter, metoder, tilnærminger, suksesser og fiaskoer, årsaker og virkninger, portretter av ledere, etc. Det var ingen spesielle restriksjoner, pga De visste ikke hva som foregikk i hodet hans.
Monologene var selvfølgelig stort sett bare tull og latter – han var i godt humør, fordi forlot outbacken til St. Petersburg. Hvor bør du gå for å jobbe i St. Petersburg? Til Gazprom, selvfølgelig.
Men vi klarte å trekke ut noe nyttig fra monologene hans. Jeg skal fortelle deg hva jeg husker.
Så fyrens anbefalinger. For de som vil prøve å sette ting i orden i forretningsprosesser.
For å utføre denne typen arbeid må du for det første ha et visst nivå av "frostskader". Du skal ikke være redd for å miste jobben, ikke være redd for å ta risiko, ikke være redd for konflikter med kolleger. Det var lett for ham, for han begynte reisen da han hadde jobbet i bedriften i bare seks måneder, og ikke hadde tid til å komme i kontakt med noen, og hadde ikke tenkt å gjøre det. Han forsto at folk kommer og går, men hans egne resultater og deres vurdering fra bedriftseieren er viktig for ham. Hvorvidt kollegene behandlet ham godt eller dårlig var lite bekymret for ham da.
Det andre punktet er at for å kunne utføre dette arbeidet effektivt, må du dessverre studere. Men studer ikke for en MBA, ikke i kurs, ikke på institutter, men på egen hånd. For eksempel, i sitt første prosjekt, et lagerprosjekt, handlet han intuitivt, han visste ingenting, bare hva "kvalitetsstyring" var.
Da han begynte å lese litteraturen om hvilke metoder for å øke effektiviteten som fantes, oppdaget han teknologiene han brukte. Fyren brukte dem intuitivt, men det viser seg at dette ikke var hans oppfinnelse, alt var allerede skrevet for lenge siden. Men han brukte tid, og mye mer enn om han umiddelbart hadde lest riktig bok. Her er det bare viktig å forstå at når du studerer en spesifikk teknikk, vil ikke en av dem, selv den mest avanserte, løse alle problemene i en forretningsprosess fullstendig.
Det andre trikset er at jo flere teknikker du kan, jo bedre. For eksempel, i det gamle Japan bodde Miyamoto Musashi, en av de mest kjente sverdmennene, forfatteren av to-sverd-stilen. Han studerte på en skole med en mester, reiste deretter rundt i Japan, kjempet med forskjellige karer. Hvis fyren var sterkere, stoppet reisen en stund, og Musashi ble student. Som et resultat, over flere år skaffet han seg ferdighetene til forskjellige praksiser fra forskjellige mestere og dannet sin egen skole, og la til noe eget. Som et resultat oppnådde han en unik ferdighet. Det er det samme her.
Du kan selvfølgelig fungere som bedriftskonsulent. Generelt er de flotte gutter. Men som regel kommer de for å introdusere en slags metodikk, og de implementerer feil metodikk som virksomheten trenger. Vi hadde også slike triste situasjoner: ingen vet hvordan de skal løse problemet og ingen ønsker å tenke på hvordan det skal løses. Vi begynner å søke enten på Internett eller ringer en konsulent og spør ham hva som kan hjelpe oss. Konsulenten tenker og sier at vi må innføre teorien om begrensninger. Vi betaler ham for anbefalingen hans, vi bruker penger på implementering, men resultatene er null.
Hvorfor skjer dette? Fordi konsulenten sa, vi innfører et slikt og et slikt system, og alle var enige med ham. Flott, men én metodikk dekker ikke alle problemene i en enkelt forretningsprosess, spesielt hvis de første forutsetningene - våre og de som kreves for å implementere metodikken - ikke er sammenfallende.
I praksisen som fyren anbefaler, må du ta det beste og implementere det beste. Ikke ta metodene helt, men ta nøkkelfunksjonene, funksjonene og praksisene deres. Og det viktigste er å forstå essensen.
Ta, sa han, for eksempel Scrum eller Agile. I monologene sine gjentok fyren mange ganger at ikke alle helt forstår essensen av Scrum. Han leste også Jeff Sutherlands bok, som noen synes er «lett lesning». Det virket som en dyp lesning for ham, fordi et av de grunnleggende prinsippene til Scrum er kvalitetsledelse, dette er skrevet direkte i boken.
Det står om Toyota Production, om hvordan Jeff Sutherland viste Scrum i Japan, hvordan det slo rot der og hvor nært det var deres filosofi. Og Sutherland snakket om viktigheten av rollen som Scrum Master, om Deming-syklusen. Rollen til Scrum Master er å stadig få fart på prosessen. Alt annet som er i Scrum - fasevis levering, kundetilfredshet, en oversiktlig arbeidsliste for sprintperioden - er også viktig, men alt dette må gå raskere og raskere. Arbeidshastigheten må hele tiden øke i enhetene den måles i.
Kanskje dette er et spørsmål om oversettelse, fordi boken vår ble oversatt som "Scrum - en revolusjonerende metode for prosjektledelse", og hvis den engelske tittelen blir oversatt bokstavelig, vil det vise seg: "Scrum - dobbelt så mye på halvparten av tiden" , det vil si selv i Navnet refererer til hastighet som en nøkkelfunksjon til Scrum.
Da denne fyren implementerte Scrum, doblet hastigheten seg den første måneden uten noen vesentlige endringer. Han fant punkter for endring og modifiserte selve Scrum for å få det til å fungere mye raskere. Det eneste de skriver på Internett er at de ble stilt overfor spørsmålet: "Vi har doblet hastigheten, det gjenstår bare å forstå hva vi gjør i en slik hastighet?" Dette er imidlertid et helt annet område...
Han anbefalte også personlig flere teknikker. Han kalte dem grunnleggende og grunnleggende.
Den første er grensestyring.
De lærer det på Skolkovo; ifølge fyren er det ingen andre bøker og materialer. Han var på en eller annen måte heldig nok til å overvære et foredrag av en professor fra Harvard som forkynner grensestyring, og leste også flere artikler i Harvard Business Review om arbeidet til Eric Trist.
Grensestyring sier at man må kunne se grenser og jobbe med grenser. Det er nok av grenser, de er overalt – mellom avdelinger, mellom ulike typer arbeid, mellom funksjoner, mellom operativt og analytisk arbeid. Kunnskap om grensestyring avslører ingen høyere sannheter, men den lar oss se virkeligheten i et litt annet lys – gjennom grensenes prisme. Og følgelig administrer dem - reis dem der det er nødvendig, og fjern dem der de er i veien.
Men oftest snakket fyren om å kontrollere. Han hadde bare en slags innfall om dette emnet.
Styring er kort sagt styring basert på tall. Her, sa han, er hver del av definisjonen viktig - både "ledelse" og "basert på" og "tall".
Vi, sa han, er dårlige med alle tre komponentene i å kontrollere. Spesielt med tanke på at de henger tett sammen både med hverandre og med andre deler av forretningssystemet.
Det første som er dårlig er tallene. Det er få av dem og de er av lav kvalitet.
Vi tok da en betydelig del av tallene fra 1C informasjonssystemet. Så kvaliteten på tallene i 1C, som han hevdet, er ikke bra. I det minste på grunn av muligheten til å endre data med tilbakevirkende kraft.
Det er klart at dette ikke er 1C-utviklernes feil - de tar bare hensyn til markedets krav og mentaliteten til innenlandsk regnskap. Men for kontrollformål er det bedre å endre prinsippene for 1C-arbeid med data i en bestemt bedrift.
Videre gjennomgår tallene fra 1C, ifølge ham, semi-manuell behandling, for eksempel ved bruk av Excel. Slik behandling gir heller ikke kvalitet til dataene, samt effektivitet.
Til slutt dobbeltsjekker noen andre sluttrapporten for ikke ved et uhell å sende inn tall med feil til lederen. Som et resultat når tallene mottakeren vakkert, bekreftet, men veldig sent. Vanligvis - etter slutten av perioden (måned, uke, etc.).
Og her, sa han, er alt veldig enkelt. Hvis tallene om januar kom til deg i februar, kan du ikke lenger administrere aktivitetene i januar. For januar er allerede over.
Og hvis tallene er basert på regnskap, og selskapet er det mest ordinære, med kvartalsvis innsending av merverdiavgift, så mottar lederen relativt tilstrekkelige tall en gang i kvartalet.
Resten er klart. Du mottar tall en gang i måneden - du har mulighet til å administrere etter tall (dvs. kontrollere) 12 ganger i året. Øver du på kvartalsrapportering klarer du det 4 ganger i året. Pluss en bonus – årsrapportering. Styr en gang til.
Resten av tiden utføres kontroll vanligvis blindt.
Når (og hvis) tallene dukker opp, kommer det andre problemet inn – hvordan skal man klare seg basert på tallene? Jeg kunne ikke være enig i dette poenget i resonnementet hans.
Fyren hevdet at hvis manageren ikke hadde tallene fra før, ville utseendet deres forårsake en wow-effekt. Han vil se og vri tallene på en og annen måte, ringe folk på teppet, kreve forklaringer og undersøkelser. Etter å ha lekt med tall, utført analyser og truende lovet alle ansatte at «nå blir jeg ikke kvitt dere», vil lederen veldig raskt roe seg ned og gi opp i denne saken. Slutt å bruke verktøyet. Men problemene vil forbli på plass.
Dette skjer, sa han, på grunn av utilstrekkelig lederkompetanse. Når det gjelder kontroll, først og fremst. Lederen vet rett og slett ikke hva han skal gjøre med disse tallene. Hva сå gjøre - vet hva de skal gjøre - nei. Å gjøre er det som er skrevet om ovenfor (å krangle, å leke). Å gjøre er en daglig forretningsprosess.
Han hevdet at alt er veldig enkelt: digitalt må bli en del av forretningsprosessen. I forretningsprosessen bør det være klart klart: hvem skal gjøre hva og når hvis tallene avviker fra normen (alle alternativer - over grensen, under grensen, går utover korridoren, tilstedeværelsen av en trend, manglende oppfyllelse av kvantil osv.)
Og så skisserte han nøkkeldilemmaet: tallet eksisterer, det bør bli en del av forretningssystemet for å øke ledelseseffektiviteten, men ... dette skjer ikke. Hvorfor?
Fordi den russiske lederen ikke vil gi fra seg en del av sin makt til en konkurrent.
Konkurrentene til den russiske lederen - en høykvalitets og fungerende forretningsprosess, gjennomtenkt gjensidig gunstig motivasjon og riktig automatisering - dessverre, vil forlate lederen uten jobb.
Litt tull, er du ikke enig? Spesielt om ledere. Ok, jeg sa til deg, du bestemmer selv.
Litt mindre, men fortsatt for mye, etter min mening, snakket han om Scrum.
Pass på, sa jeg, les og prøv Scrum i praksis. Hvis, sier han, du har lest det, men ikke har prøvd det, anser deg selv som uvitende. Det er bedre å lese en bok, for eksempel av Sutherland, i stedet for artikler og alle slags guider (hva i helvete?) på Internett.
Scrum, sa han, kan bare læres gjennom praksis, og med obligatoriske målinger av mengden arbeid som utføres. Prøv personlig de to viktigste rollene - Product Owner og Scrum Master.
Det er spesielt viktig, ifølge fyren, å i praksis oppleve rollen som en Scrum Master, når du kan øke volumet av oppgaver utført per sprint uten å øke ressursene og kostnadene for sprinten.
Vel, i toppen hans var det TOS (teori om systembegrensninger).
Disse, ifølge fyren, er de grunnleggende, grunnleggende prinsippene for å øke effektiviteten som kan brukes på nesten alle områder, i enhver forretningsprosess og forretningssystem som helhet.
Da han fant ut at vi ikke var kjent med TOS, sluttet han å fortelle oss det. Han la bare til at han ikke ville frata oss gleden av å lese Eliyahu Goldratts bøker. Han ga en lignende anbefaling til Scrum – les den og prøv den. Som, uansett hvilken stilling du er i, uansett hvilket arbeid du gjør, er det et sted for å øke effektiviteten ved å bruke TOC-metoder.
Så tørket tilsynelatende posen med teknikker ut, og han sa: bland prinsippene for å lage anvendte løsninger i en spesifikk situasjon.
Dette, sier han, er hovedanbefalingen, nøkkelen til suksess. Forstå prinsippene, essensen og skap unike applikasjonsløsninger - forretningsprosesser og forretningssystemer.
Så prøvde han å huske et eller annet sitat, og til slutt måtte han gå på nett. Det viste seg å være et sitat fra artikkelen «Standing on the Shoulders of Giants» av Eliyahu Goldratt:
"Det er en forskjell mellom anvendte løsninger (applikasjoner) og de grunnleggende konseptene som disse løsningene er basert på. Konsepter er generelle; anvendte løsninger er tilpasning av konsepter til et spesifikt miljø. Som vi allerede har sett, er slik tilpasning ikke enkel og krever utvikling av visse elementer i løsningen. Vi må huske at en applikasjonsløsning er basert på innledende antakelser (noen ganger skjulte) om et spesifikt miljø. Denne applikasjonsløsningen bør ikke forventes å fungere i et miljø der forutsetningene ikke er korrekte."
Han sa at arbeidet til en programmerer og en "forbedrer i forretningsprosesser" er veldig like. Og Venstre.
Kilde: www.habr.com