Tarina on tosi, näin kaiken omin silmin.
Useiden vuosien ajan yksi kaveri, kuten monet teistä, työskenteli ohjelmoijana. Varmuuden vuoksi kirjoitan sen näin: "ohjelmoija". Koska hän oli 1Snik, tuotantoyhtiössä.
Sitä ennen hän kokeili eri erikoisuuksia - 4 vuotta Ranskassa ohjelmoijana, projektipäällikkönä, hän pystyi suorittamaan 200 tuntia, samalla saaen prosenttiosuuden projektista, johtamiseen ja pieneen myyntiin. Yritin kehittää tuotteita itse, olin IT-osaston johtaja suuressa yrityksessä, jossa oli 6 tuhatta ihmistä, kokeilin erilaisia vaihtoehtoja lainattavan ammattini käyttämiseen - 1C-ohjelmoija.
Mutta kaikki nämä paikat olivat jossain määrin umpikujassa, pääasiassa tulojen kannalta. Tuolloin saimme kaikki suunnilleen saman rahan ja työskentelimme samoissa olosuhteissa.
Tämä kaveri pohti, kuinka hän voisi ansaita enemmän rahaa myymättä tai perustamatta omaa yritystä.
Hän piti itseään älykkäänä kaverina ja päätti löytää markkinaraon yrityksestä, jossa hän työskenteli. Tämän markkinaraon täytyi olla jotain erityistä, ei kenenkään käytössä. Ja halusin, että yritys itse haluaa maksaa rahaa tässä markkinarakossa olevalle henkilölle, jotta ei tarvitsisi pettää ketään tai huijata mitään. Tämän tavoitteen saavuttamiseksi: tässä asemassa olevalle henkilölle on maksettava paljon rahaa. Eksentrinen, sanalla sanoen.
Etsintä oli lyhytaikainen. Yrityksessä, jossa tämä kaveri työskenteli, oli täysin vapaa markkinarako, jota voisi kutsua "asioiden järjestämiseksi liiketoimintaprosesseissa". Jokaisella yrityksellä on paljon ongelmia. Jokin ei aina toimi, eikä kukaan tule korjaamaan liiketoimintaprosessia. Joten hän päätti kokeilla itseään asiantuntijana, joka voi auttaa omistajaa ratkaisemaan ongelmansa liiketoimintaprosesseissa.
Hän oli tuolloin työskennellyt yrityksessä kuusi kuukautta ja sai markkinoiden keskimääräistä palkkaa. Ei ollut mitään menetettävää, varsinkin kun hän löysi helposti saman työn viikossa. Yleensä tämä kaveri päätti, että mitään pahaa ei tapahtuisi, jos yhtäkkiä mikään ei toimi ja hänet erotettiin.
Hän keräsi rohkeutta ja tuli omistajan luo. Ehdotin, että hän parantaa liiketoiminnan ongelmallisinta prosessia. Tuolloin se oli varastokirjanpitoa. Nyt kaikki tässä yrityksessä työskentelevät jopa häpeävät muistella niitä ongelmia, mutta neljännesvuosittain tehdyissä inventoinnissa havaittiin kirjanpitojärjestelmän ja todellisten saldojen välisiä kymmenien prosentin eroja. Ja kustannuksissa, määrässä ja paikkojen määrässä. Se oli katastrofi. Yrityksellä oli kirjanpitojärjestelmässä oikeat saldot vain neljä kertaa vuodessa – varastolaskennan jälkeisenä päivänä. Kaverimme alkoi laittaa tätä prosessia järjestykseen.
Kaveri sopi omistajan kanssa, että hänen pitäisi puolittaa poikkeamat inventaariotuloksista. Lisäksi omistajalla ei ollut mitään erityistä menetettävää, koska ennen sankariamme useat työntekijät olivat jo yrittäneet korjata kaiken, ja yleensä tehtävää pidettiin käytännössä ratkaisemattomana. Kaikki tämä lisäsi suuresti kiinnostusta, koska jos kaikki toimisi, jätkästä tulisi automaattisesti henkilö, joka osaa laittaa asiat järjestykseen ja ratkaista ratkaisemattomia ongelmia.
Joten hänen edessään oli tehtävä: vähentää varastotuloksiin perustuvia poikkeamia 2 kertaa vuodessa. Projektin alussa hänellä ei ollut aavistustakaan, miten tämä saavutetaan, mutta hän ymmärsi, että varastokirjanpito on yksinkertainen asia, joten hän voisi silti tehdä jotain hyödyllistä. Lisäksi poikkeamien vähentäminen kymmenistä prosenteista yhteen kymmeneen prosenttiin ei näytä olevan niin vaikeaa. Jokainen konsultti- tai vastaavassa toiminnassa työskennellyt ymmärtää, että useimmat prosessiongelmat voidaan ratkaista melko yksinkertaisilla vaiheilla.
Tammi-toukokuussa hän valmisteli, automatisoi hieman jotain, kirjoitti uudelleen varastokirjanpidon liiketoimintaprosessia, muutti varastonpitäjien, kirjanpitäjien työnkulkuja ja yleensä teki koko järjestelmän uusiksi, näyttämättä tai kertomatta kenellekään mitään. Toukokuussa hän jakoi uudet ohjeet kaikille, ja vuoden ensimmäisen inventaarion jälkeen alkoi uusi elämä - työskentely hänen sääntöjensä mukaan. Tulosten tarkkailemiseksi yhtiö aloitti jatkossa inventoinnit useammin - kerran kahdessa kuukaudessa. Jo ensimmäiset tulokset olivat positiivisia, ja vuoden loppuun mennessä poikkeamat tarkastustuloksista olivat pudonneet prosenttiin.
Menestys oli valtava, mutta sen kestävyyteen ei voinut uskoa. Kaveri itse epäili, että tulos säilyisi, jos hän astuisi sivuun ja lopettaisi prosessin tarkkailun. Siitä huolimatta tulos oli, ja kaveri sai kaiken, mitä hän sopi omistajan kanssa. Sitten usean vuoden kuluttua tuloksen vakaus vahvistettiin - useiden vuosien ajan poikkeamat pysyivät 1 prosentin sisällä.
Sitten hän päätti toistaa kokeen ja ehdotti, että omistaja parantaa toista ongelmallista prosessia - toimitusta. Oli pulaa, jonka vuoksi emme pystyneet toimittamaan asiakkaidemme toivomia määriä. Sovimme, että vuoden sisällä alijäämät puolitetaan ja kaveri saa myös päätökseen 10-15 1C:hen liittyvää projektia - automatisoida erilaisia liiketoimintaprosesseja ja muita harhaoppeja.
Toisena vuonna kaikki saatiin jälleen onnistuneesti päätökseen, alijäämät pienenivät yli 2 kertaa, kaikki IT-projektit saatiin onnistuneesti päätökseen.
Koska palkka täytti jo kaksi vuotta etukäteen täysin tuon kaverin kaikki tarpeet, hän päätti asettua hieman, rauhoittua ja istua itselleen luomaan viihtyisään, lämpimään paikkaan.
Millaista se oli? Muodollisesti hän oli IT-johtaja. Mutta kuka hän todella oli, on vaikea ymmärtää. Loppujen lopuksi mitä IT-johtaja tekee? Pääsääntöisesti hän hallinnoi IT-infrastruktuuria, johtaa järjestelmänvalvojia, toteuttaa ERP-järjestelmää ja osallistuu hallituksen kokouksiin.
Ja tällä kaverilla oli yksi tärkeimmistä vastuista osallistua muutosprosesseihin, ja pääasiassa - näiden prosessien luominen, käynnistäminen, ratkaisujen etsiminen ja ehdottaminen, uusien johtamistekniikoiden soveltaminen, ehdotettujen muutosten tarkastelu, muiden toimintojen tehokkuuden analysointi ja divisioonat ja lopuksi suora osallistuminen yrityksen strategiseen kehittämiseen aina koko yrityksen strategisen suunnitelman itsenäiseen laatimiseen asti.
Hänelle annettiin carte blanche. Hän saattoi tulla mihin tahansa kokoukseen, johon hänellä ei aiemmin ollut pääsyä. Istuin siinä muistilehtiön kanssa, kirjoitin jotain muistiin tai vain kuuntelin. Hän puhui harvoin. Sitten hän alkoi pelata puhelimella väittäen, että assosiatiivinen muisti toimii paremmin tällä tavalla.
Hän harvoin kertoi kokouksessa mitään hyödyllistä. Hän lähti, ajatteli, sitten saapui kirje - joko kritiikkiä tai mielipidettä tai ehdotuksia sisältävänä tai kuvauksena ratkaisuista, joita hän oli jo soveltanut.
Mutta useammin hän kutsui koolle kokouksia itse. Löysin ongelman, keksin ratkaisuja, tunnistin kiinnostuneet ja toin kaikki kokoukseen. Ja sitten - parhaansa mukaan. Hän vakuutti, motivoi, osoitti, väitti, saavutti.
Epävirallisesti häntä pidettiin yhtiön kolmannena henkilönä omistajan ja johtajan jälkeen. Tietysti hän raivostutti hirveästi kaikki "yrityksen henkilöt", alkaen numerosta 4. Varsinkin repeytyneillä farkuilla ja kirkkailla T-paidoillaan ja myös omistajanaolollaan.
Omistaja antoi hänelle tunnin päivässä. Joka päivä. He keskustelivat, keskustelivat ongelmista, ratkaisuista, uusista yrityksistä, kehittämisalueista, indikaattoreista ja tehokkuudesta, henkilökohtaisesta kehityksestä, kirjoista ja yksinkertaisesti elämästä.
Mutta tämä kaveri oli outo. Istu alas ja ole onnellinen, elämä on hyvää. Mutta ei. Hän päätti pohtia.
Hän ihmetteli: miksi se toimi hänelle, mutta muut eivät? Omistaja myös työnsi häntä: hän sanoi haluavansa myös muiden pystyvän palauttamaan järjestyksen, koska johtajia on paljon, he ovat pääsääntöisesti mukana operatiivisessa johtamisessa ja strategisessa suunnittelussa, mutta käytännössä kukaan ei ole mukana järjestelmämuutoksissa. prosesseissaan. Heidän toimenkuvaansa voidaan kirjoittaa, että heidän pitäisi nopeuttaa prosessiaan ja tehostaa sen tehokkuutta, mutta todellisuudessa kukaan ei tee niin. Miksi niin? Kaveri kiinnostui myös miksi, ja hän meni juttelemaan kaikkien näiden johtajien kanssa.
Hän tuli laadun apulaisjohtajan luo ja ehdotti Shewhart-kontrollikorttien käyttöönottoa, jotta tuotteet olisivat parempia kuin japanilaiset. Mutta kävi ilmi, että kollega ei tiennyt mitä Shewhart-ohjauskaaviot ovat, mitä tilastollinen prosessiohjaus on, ja oli vain kuullut Demingin syklin käytöstä laadunhallinnassa. OK…
Hän meni toisen apulaisjohtajan luo ja ehdotti kontrollin käyttöönottoa. Mutta en löytänyt tukea täältäkään. Hieman myöhemmin hän oppi rajojen hallinnasta (rajojen hallinta) ja ehdotti, että kaikki apulaisjohtajat ottavat käyttöön tämän metodologian systeemisen osan prosessien parantamiseksi. Mutta vaikka kaverimme puhui kuinka paljon, kukaan ei todellakaan halunnut syventyä siihen, mistä oli kyse. Ehkä he eivät olleet kiinnostuneita tai se oli liian vaikeaa. Mutta itse asiassa kukaan ei tajunnut sitä.
Yleisesti ottaen hän puhui kaikesta, mitä tiesi ja käytti yrityksessä. Mutta kukaan ei ymmärtänyt häntä. He eivät vieläkään ymmärrä, miksi esimerkiksi varastokirjanpidossa kaikki korjattiin ja mitä tekemistä valvonnalla ja rajavalvonnalla on sen kanssa.
Lopuksi hän tavoitti ohjelmoijansa - henkilökuntaan kuului 3 henkilöä. Hän puhui rajojen hallinnasta, kontrolloinnista, laadunhallinnasta, ketterästä ja scrumista... Ja yllättäen he ymmärsivät kaiken ja jopa pystyivät jotenkin keskustelemaan hänen kanssaan, myös teknisistä ja metodologisista hienouksista. He ymmärsivät, miksi varasto- ja toimitusprojektit onnistuivat. Ja sitten kaveri valkeni: itse asiassa ohjelmoijat pelastavat maailman.
Hän ymmärsi, että ohjelmoijat ovat ainoita, jotka voivat ymmärtää liiketoimintaprosesseja normaalisti, tarvittavilla yksityiskohdilla.
Miksi he? Itse asiassa hän ei koskaan löytänyt selkeää vastausta. Muotoilin vain opinnäytevihjeitä.
Ensinnäkin ohjelmoijat tuntevat liiketoiminnan aihealueet, ja he tuntevat ne paremmin kuin kaikki muut yrityksen ihmiset.
Lisäksi ohjelmoijat todella ymmärtävät, mikä prosessialgoritmi on. Tämä on tärkeää, koska liiketoimintaprosessit ovat algoritmeja ja niiden elementit eivät välttämättä ole johdonmukaisia. Esimerkiksi hankintaprosessissa, jonka parissa kaveri työskenteli, ensimmäinen askel oli vuosittaisen ostosuunnitelman laatiminen ja toinen oli päivittäinen osto. Nämä vaiheet yhdistetään suoralla yhteydellä, eli oletetaan, että ihmisten tulee työskennellä tämän algoritmin mukaan - laatia vuosittainen hankintasuunnitelma ja suorittaa pyyntö välittömästi. Vuosittainen hankintasuunnitelma laaditaan kerran vuodessa ja hakemuksia vastaanotetaan 50 kertaa päivässä. Algoritmi päättyy tähän, ja sinun on työstettävä sitä. Itse asiassa hän perusteli, että ohjelmoijille algoritmien tuntemus on kilpailuetu, koska kukaan muu, joka ei tunne niitä, ei yksinkertaisesti ymmärrä, miten liiketoimintaprosessin pitäisi toimia ja miten se voidaan esittää.
Toinen ohjelmoijien etu miehen mukaan on, että heillä on tarpeeksi vapaa-aikaa. Me kaikki ymmärrämme, kuinka ohjelmoija voi käyttää tehtävään kolme kertaa pidempään kuin se todellisuudessa vaatii, ja harvat huomaavat. Tämä on jälleen kilpailuetu, koska jonkin liiketoimintaprosessin saattamiseksi järjestykseen tarvitset paljon vapaa-aikaa - ajattele, tarkkaile, opi ja kokeile.
Useimmilla johtajilla ei kaverin mukaan ole tätä vapaa-aikaa ja he ovat ylpeitä siitä. Vaikka itse asiassa tämä tarkoittaa, että henkilö ei voi tulla tehokkaaksi, koska hänellä ei ole aikaa parantaa tehokkuutta - noidankehä. Kulttuurissamme on muotia olla kiireinen, joten kaikki pysyy ennallaan. Ja meille ohjelmoijille tämä on etu. Voimme löytää vapaa-aikaa ja ajatella kaikkea.
Ohjelmoijat, hän sanoi, voivat nopeasti muuttaa tietojärjestelmän. Tämä ei päde kaikissa yrityksissä, mutta missä tahansa hän työskenteli, hän saattoi tehdä haluamansa muutokset. Varsinkin jos ne eivät koske kenenkään muun työtä. Hän voisi esimerkiksi käynnistää järjestelmän, joka mittaa salaa käyttäjien toimia, ja käyttää näitä tietoja saman kirjanpitoosaston tehokkuuden analysointiin ja kirjanpidon kustannusten seurantaan.
Ja viimeinen asia, jonka muistan hänen sanoistaan, on se, että ohjelmoijat pääsevät käsiksi suureen määrään tietoa, koska... saada järjestelmänvalvojan käyttöoikeus. Siksi he voivat käyttää näitä tietoja analyysissaan. Kenelläkään muulla tavallisessa tehtaassa ei ole tällaista resurssia.
Ja sitten hän lähti. Vaaditun kahden viikon pidätyksen aikana pakotimme hänet jakamaan kokemuksensa, koska halusimme jatkaa hänen tekemänsä työtä. No, hänen paikkansa vapautui.
Useiden päivien aikana he istuivat hänet tuolille, käynnistivät kameran ja nauhoittivat hänen monologinsa. He pyysivät kertomaan meille kaikista valmistuneista projekteista, menetelmistä, lähestymistavoista, onnistumisista ja epäonnistumisista, syistä ja seurauksista, esimiehen muotokuvista jne. Ei ollut erityisiä rajoituksia, koska He eivät tienneet, mitä hänen päässään liikkui.
Monologit olivat tietysti enimmäkseen hölynpölyä ja naurua - hän oli loistavalla tuulella, koska oli lähdössä takamaasta Pietariin. Minne Pietariin kannattaa mennä töihin? Tietenkin Gazpromille.
Mutta onnistuimme saamaan jotain hyödyllistä hänen monologeistaan. Kerron mitä muistan.
Eli miehen suositukset. Niille, jotka haluavat yrittää saada asiat järjestykseen liiketoimintaprosesseissa.
Tällaista työtä varten sinulla on ensinnäkin oltava tietyn tason "paleltuma". Sinun ei pitäisi pelätä työpaikkasi menettämistä, älä pelkää ottaa riskejä, älä pelkää konflikteja kollegoiden kanssa. Se oli hänelle helppoa, koska hän aloitti matkansa, kun hän oli työskennellyt yrityksessä vain kuusi kuukautta, eikä hänellä ollut aikaa olla tekemisissä kenenkään kanssa, eikä aikonutkaan tehdä niin. Hän ymmärsi, että ihmisiä tulee ja menee, mutta hänen omat tuloksensa ja yrityksen omistajan arvio ovat hänelle tärkeitä. Se, kohtelivatko hänen kollegansa häntä hyvin vai huonosti, ei silloin juuri kiinnostanut häntä.
Toinen kohta on, että tämän työn tehokkaaksi tekemiseksi sinun on valitettavasti opiskeleva. Mutta älä opiskele MBA-tutkintoa varten, ei kursseilla, ei instituuteissa, vaan itse. Esimerkiksi ensimmäisessä projektissaan, varastoprojektissaan, hän toimi intuitiivisesti, hän ei tiennyt mitään, vain mitä "laadunhallinta" on.
Kun hän alkoi lukea kirjallisuutta tehokkuuden lisäämismenetelmistä, hän löysi käyttämänsä tekniikat. Kaveri sovelsi niitä intuitiivisesti, mutta käy ilmi, että tämä ei ollut hänen keksintönsä, kaikki oli jo kirjoitettu kauan sitten. Mutta hän vietti aikaa, ja paljon enemmän kuin jos hän olisi heti lukenut oikean kirjan. Tässä on vain tärkeää ymmärtää, että kun tutkit tiettyä tekniikkaa, yksikään niistä, edes edistynein, ei ratkaise täysin kaikkia liiketoimintaprosessin ongelmia.
Toinen temppu on, että mitä enemmän tekniikoita tiedät, sitä parempi. Esimerkiksi muinaisessa Japanissa asui Miyamoto Musashi, yksi kuuluisimmista miekkamiehistä, kahden miekan tyylin kirjoittaja. Hän opiskeli jossain koulussa jonkun mestarin johdolla, matkusti sitten ympäri Japania, taisteli erilaisten kavereiden kanssa. Jos kaveri oli vahvempi, matka pysähtyi joksikin aikaa, ja Musashista tuli opiskelija. Tämän seurauksena hän hankki useiden vuosien aikana eri mestareiden erilaisten käytäntöjen taidot ja perusti oman koulun, johon hän lisäsi jotain omaa. Tämän seurauksena hän saavutti ainutlaatuisen taidon. Se on sama täällä.
Voit tietysti toimia yrityskonsulttina. Yleisesti ottaen he ovat mahtavia tyyppejä. Mutta pääsääntöisesti he tulevat ottamaan käyttöön jonkinlaisen metodologian ja toteuttavat väärän menetelmän, jota yritys tarvitsee. Meillä oli myös sellaisia surullisia tilanteita: kukaan ei tiedä kuinka ratkaista ongelma, eikä kukaan halua ajatella, kuinka se ratkaistaan. Aloitamme etsinnän joko Internetistä tai soitamme konsultille ja kysymme, mikä voi auttaa meitä. Konsultti ajattelee ja sanoo, että meidän on esitettävä rajoitteiden teoria. Maksamme hänelle hänen suosituksestaan, käytämme rahaa täytäntöönpanoon, mutta tulokset ovat nolla.
Miksi näin tapahtuu? Koska konsultti sanoi, otamme käyttöön sellaisen ja sellaisen järjestelmän, ja kaikki olivat hänen kanssaan samaa mieltä. Hienoa, mutta yksi metodologia ei kata kaikkia edes yhden liiketoimintaprosessin ongelmia, varsinkin jos alkuedellytykset - meidän ja metodologian toteuttamiseen vaadittavat - eivät täsmää.
Käytännössä, jota kaveri suosittelee, sinun on otettava paras ja toteutettava paras. Älä ota menetelmiä kokonaan, vaan ota niiden tärkeimmät ominaisuudet, ominaisuudet ja käytännöt. Ja tärkeintä on ymmärtää ydin.
Otetaan esimerkiksi Scrum tai Agile, hän sanoi. Monologissaan kaveri toisti monta kertaa, että kaikki eivät ymmärrä täysin Scrumin olemusta. Hän luki myös Jeff Sutherlandin kirjan, joka joidenkin mielestä oli "kevyt lukeminen". Hänestä se tuntui syvältä luetulta, sillä yksi Scrumin perusperiaatteista on laadunhallinta, tämä on kirjoitettu suoraan kirjaan.
Siinä kerrotaan Toyota Productionista, kuinka Jeff Sutherland esitteli Scrumia Japanissa, kuinka se juurtui siellä ja kuinka lähellä se oli heidän filosofiaan. Ja Sutherland puhui Scrum Masterin roolin tärkeydestä, Demingin syklistä. Scrum Masterin tehtävänä on jatkuvasti nopeuttaa prosessia. Myös kaikki muu, mitä Scrumissa on - vaiheittainen toimitus, asiakastyytyväisyys, selkeä työlista sprinttijaksolle - on myös tärkeää, mutta kaiken tämän on edettävä yhä nopeammin. Työn nopeuden tulee jatkuvasti kasvaa niissä yksiköissä, joissa se mitataan.
Ehkä tämä on käännöskysymys, koska kirjamme käännettiin nimellä "Scrum - vallankumouksellinen projektinhallinnan menetelmä", ja jos englanninkielinen nimi käännetään kirjaimellisesti, siitä tulee: "Scrum - kaksi kertaa niin paljon puolessa ajassa" , eli jopa vuonna Nimi viittaa nopeuteen Scrumin avaintoimintona.
Kun tämä kaveri otti käyttöön Scrumin, nopeus kaksinkertaistui ensimmäisen kuukauden aikana ilman merkittäviä muutoksia. Hän löysi pisteitä muutoksille ja muokkasi itse Scrumia saadakseen sen toimimaan paljon nopeammin. Ainoa asia, jonka he kirjoittavat Internetiin, on se, että he kohtasivat kysymyksen: "Olemme kaksinkertaistaneet nopeuden, jäljellä on vain ymmärtää, mitä teemme sellaisella nopeudella?" Tämä on kuitenkin täysin eri alue...
Hän myös henkilökohtaisesti suositteli useita tekniikoita. Hän kutsui niitä perustavanlaatuisiksi ja perustavanlaatuisiksi.
Ensimmäinen on rajojen hallinta.
He opettavat sitä Skolkovossa, kaverin mukaan muita kirjoja ja materiaaleja ei ole. Hän oli jotenkin onnekas osallistua Harvardin professorin luennolle, joka saarnaa rajojen hallintaa, ja luki myös useita artikkeleita Harvard Business Review -lehdessä Eric Tristin työstä.
Rajojen hallinta sanoo, että sinun on osattava nähdä rajat ja työskennellä rajojen kanssa. Rajoja on paljon, ne ovat kaikkialla - osastojen välillä, erilaisten töiden välillä, toimintojen välillä, operatiivisen ja analyyttisen työn välillä. Rajahallinnan tuntemus ei paljasta korkeampia totuuksia, mutta sen avulla voimme nähdä todellisuuden hieman eri valossa - rajojen prisman läpi. Ja vastaavasti hallitse niitä - pystytä ne tarvittaessa ja poista ne sieltä, missä ne ovat tiellä.
Mutta useimmiten kaveri puhui hallitsemisesta. Hänellä oli vain jonkinlainen omituisuus tästä aiheesta.
Controlling on lyhyesti sanottuna numeroihin perustuvaa hallintaa. Tässä hän sanoi, että jokainen määritelmän osa on tärkeä - sekä "hallinta" että "perustuu" ja "numeroihin".
Hän sanoi, että olemme huonoja kaikkien kolmen hallinnan osatekijän kanssa. Varsinkin kun otetaan huomioon, että ne ovat tiiviisti yhteydessä toisiinsa sekä muihin liiketoimintajärjestelmän osiin.
Ensimmäinen huono asia ovat numerot. Niitä on vähän ja ne ovat huonolaatuisia.
Otimme sitten merkittävän osan numeroista 1C-tietojärjestelmästä. Joten 1C:n numeroiden laatu, kuten hän väitti, ei ole hyvä. Ainakin, koska tietoja voidaan muuttaa takautuvasti.
On selvää, että tämä ei ole 1C-kehittäjien vika - he ottavat huomioon vain markkinoiden vaatimukset ja kotimaisen kirjanpidon mentaliteetin. Mutta valvontatarkoituksiin on parempi muuttaa 1C-työn periaatteita tietojen kanssa tietyssä yrityksessä.
Lisäksi 1C:n numerot hänen mukaansa läpikäyvät puolimanuaalisen käsittelyn esimerkiksi Excelillä. Tällainen käsittely ei myöskään lisää tietojen laatua eikä tehokkuutta.
Lopulta joku muu tarkistaa loppuraportin uudelleen, jotta ei vahingossa lähetetä virheellisiä lukuja esimiehelle. Tämän seurauksena numerot saapuvat vastaanottajalle kauniina, varmennettuina, mutta hyvin myöhään. Yleensä - jakson päätyttyä (kuukausi, viikko jne.).
Ja täällä, hän sanoi, kaikki on hyvin yksinkertaista. Jos tammikuun numerot tulivat sinulle helmikuussa, et voi enää hallita tammikuun toimintoja. Koska tammikuu on jo ohi.
Ja jos luvut perustuvat kirjanpitoon ja yritys on tavallisin, joka toimittaa arvonlisäveron neljännesvuosittain, niin sen johtaja saa suhteellisen riittävät luvut neljännesvuosittain.
Loput on selvää. Saat numerot kerran kuukaudessa – sinulla on mahdollisuus hallita numeroiden mukaan (eli ohjata) 12 kertaa vuodessa. Jos harjoittelet neljännesvuosittaista raportointia, hoidat sitä 4 kertaa vuodessa. Plussaa - vuosiraportointi. Ohjaa vielä kerran.
Muun ajan ohjaus tapahtuu yleensä sokeasti.
Kun (ja jos) numerot ilmestyvät, tulee esiin toinen ongelma - kuinka hallita numeroiden perusteella? En voinut yhtyä hänen perustelunsa tähän kohtaan.
Kaveri väitti, että jos johtajalla ei ollut numeroita aiemmin, heidän esiintymisensä aiheuttaisi vau-efektin. Hän katselee ja vääntää numeroita sinne ja tänne, soittaa ihmisiä matolle, vaatii selityksiä ja tutkimuksia. Numeroilla leikkimisen, analyysin suorittamisen ja uhkaavasti kaikille työntekijöille luvatun, että "en nyt en pääse sinusta eroon", johtaja rauhoittuu nopeasti ja luovuttaa tämän asian suhteen. Lopeta työkalun käyttö. Mutta ongelmat pysyvät paikoillaan.
Tämä johtuu hänen mukaansa riittämättömistä johtamispätevyydestä. Valvonnassa ennen kaikkea. Johtaja ei yksinkertaisesti tiedä mitä tehdä näillä numeroilla. Mitä сtehdä - tietää mitä tehdä - ei. Tekeminen on sitä, mistä edellä on kirjoitettu (riida, leikkiä). Tekeminen on jokapäiväinen liiketoimintaprosessi.
Hän väitti, että kaikki on hyvin yksinkertaista: digitaalisesta on tultava osa liiketoimintaprosessia. Liiketoimintaprosessissa tulee olla selkeästi selvää: kenen pitäisi tehdä mitä ja milloin, jos luvut poikkeavat normista (kaikki vaihtoehdot - rajan yläpuolella, rajan alapuolella, käytävän yli, trendin olemassaolo, epäonnistuminen kvantiili jne.)
Ja niin hän hahmotteli keskeisen dilemman: numero on olemassa, sen pitäisi tulla osaksi liiketoimintajärjestelmää johtamisen tehokkuuden lisäämiseksi, mutta... näin ei tapahdu. Miksi?
Koska Venäjän johtaja ei luovuta osaakaan vallastaan kilpailijalle.
Venäläisen johtajan kilpailijat - laadukas ja toimiva liiketoimintaprosessi, hyvin harkittu molempia osapuolia hyödyttävä motivaatio ja oikea automaatio - valitettavasti jättävät johtajan ilman työtä.
Jotenkin hölynpölyä, etkö ole samaa mieltä? Varsinkin johtajista. Okei, sanoin, että päätät itse.
Hieman vähemmän, mutta silti liikaa, mielestäni hän puhui Scrumista.
Muista, sanoin, lue ja kokeile Scrumia käytännössä. Jos, hän sanoo, olet lukenut sen, mutta et ole kokeillut sitä, pidä itseäsi tietämättömänä. On parempi lukea kirjaa, esimerkiksi Sutherlandilta, kuin artikkeleita ja kaikenlaisia oppaita (mitä helvettiä?) Internetissä.
Scrum, hän sanoi, voidaan oppia vain harjoittelemalla ja pakollisilla mittauksilla tehdyn työn määrästä. Kokeile itse kahta tärkeintä roolia - Product Owner ja Scrum Master.
Erityisen tärkeää on kaverin mukaan kokea käytännössä Scrum Masterin rooli, kun sprintissä suoritettavien tehtävien määrää voi kasvattaa ilman, että sprintin resurssit ja kustannukset kasvavat.
No, hänen topissaan oli TOS (järjestelmän rajoitusten teoria).
Nämä ovat miehen mukaan tehokkuuden lisäämisen perusperiaatteet, joita voidaan soveltaa lähes millä tahansa alueella, missä tahansa liiketoimintaprosessissa ja liiketoimintajärjestelmässä kokonaisuutena.
Kun hän sai selville, ettemme tunne TOS:ää, hän lakkasi kertomasta meille. Hän lisäsi vain, ettei hän riistäisi meiltä iloa lukea Eliyahu Goldrattin kirjoja. Hän antoi samanlaisen suosituksen Scrumille - lue se ja kokeile sitä. Kuten, riippumatta siitä, missä asemassa olet, riippumatta siitä, mitä työtä teet, on paikka tehokkuuden lisäämiselle TOC-menetelmillä.
Sitten hänen tekniikkapussinsa ilmeisesti kuivui, ja hän sanoi: sekoita periaatteita luodaksesi sovellettavia ratkaisuja tietyssä tilanteessa.
Tämä on hänen mukaansa tärkein suositus, avain menestykseen. Ymmärrä periaatteet, olemus ja luo ainutlaatuisia sovellusratkaisuja - liiketoimintaprosesseja ja liiketoimintajärjestelmiä.
Sitten hän yritti muistaa lainauksen, ja lopulta hänen täytyi mennä verkkoon. Se osoittautui lainaukseksi Eliyahu Goldrattin artikkelista "Standing on the Shoulders of Giants":
”Sovellettujen ratkaisujen (sovellusten) ja niiden peruskäsitteiden välillä on ero. Käsitteet ovat yleisiä, sovelletut ratkaisut ovat käsitteiden mukauttamista tiettyyn ympäristöön. Kuten olemme jo nähneet, tällainen mukauttaminen ei ole yksinkertaista ja vaatii tiettyjen ratkaisun elementtien kehittämistä. On muistettava, että sovellusratkaisu perustuu alkuperäisiin (joskus piilotettuihin) oletuksiin tietystä ympäristöstä. Tämän sovellusratkaisun ei pitäisi odottaa toimivan ympäristössä, jossa oletukset eivät pidä paikkaansa."
Hän sanoi, että ohjelmoijan ja "liiketoimintaprosessin parantajan" työ ovat hyvin samankaltaisia. Ja lähti.
Lähde: will.com