Historia jest prawdziwa, wszystko widziałem na własne oczy.
Przez kilka lat jeden facet, jak wielu z Was, pracował jako programista. Na wszelki wypadek napiszę tak: „programista”. Bo był 1Snik, na naprawie, firma produkcyjna.
Wcześniej próbował różnych specjalizacji - 4 lata we Francji jako programista, kierownik projektu, był w stanie przepracować 200 godzin, jednocześnie otrzymując procent projektu, na zarządzanie i robiąc małą sprzedaż. Próbowałem samodzielnie opracowywać produkty, byłem szefem działu IT w dużej firmie zatrudniającej 6 tysięcy osób, próbowałem różnych opcji wykorzystania mojego cytowanego zawodu - programisty 1C.
Ale wszystkie te pozycje były w pewnym sensie ślepą uliczką, przede wszystkim pod względem dochodów. Wszyscy wtedy otrzymywaliśmy mniej więcej te same pieniądze i pracowaliśmy na tych samych warunkach.
Ten facet zastanawiał się, jak mógłby zarobić więcej pieniędzy bez sprzedaży i tworzenia własnego biznesu.
Uważał się za inteligentnego faceta i postanowił znaleźć niszę w firmie, w której pracował. Ta nisza musiała być czymś wyjątkowym, niezajętym przez nikogo. A chciałem, żeby sama firma chciała zapłacić pieniądze osobie z tej niszy, żeby nie było potrzeby nikogo oszukiwać i niczego oszukiwać. Aby osiągnąć ten cel: osoba na tym stanowisku musi zarabiać dużo pieniędzy. Jednym słowem ekscentryk.
Poszukiwania były krótkotrwałe. W firmie, w której pracował ten facet, istniała całkowicie wolna nisza, którą można nazwać „uporządkowaniem procesów biznesowych”. Każda firma ma wiele problemów. Zawsze coś nie działa i nie ma osoby, która przyjdzie i naprawi proces biznesowy. Postanowił więc spróbować swoich sił w roli specjalisty, który pomoże właścicielowi rozwiązać jego problemy w procesach biznesowych.
W tym czasie przepracował w firmie pół roku i otrzymywał średnią rynkową pensję. Nie miał nic do stracenia, zwłaszcza, że w ciągu tygodnia bez problemu znalazł tę samą pracę. Ogólnie rzecz biorąc, ten facet zdecydował, że nic złego się nie stanie, jeśli nagle nic nie wyjdzie, i został zwolniony.
Zebrał się na odwagę i podszedł do właściciela. Zasugerowałem mu usprawnienie najbardziej problematycznego procesu w biznesie. Była to wówczas księgowość magazynowa. Teraz każdy, kto pracuje w tej firmie, nawet wstydzi się pamiętać te problemy, ale inwentaryzacje, które przeprowadzano kwartalnie, wykazały rozbieżności między systemem księgowym a stanami faktycznymi, rzędu kilkudziesięciu procent. I pod względem kosztów, ilości i liczby stanowisk. To była katastrofa. Właściwie tylko cztery razy w roku – dzień po inwentaryzacji – spółka miała prawidłowe salda w systemie księgowym. Nasz facet zaczął porządkować ten proces.
Facet zgodził się z właścicielem, że powinien zmniejszyć o połowę odchylenia od wyników inwentaryzacji. Co więcej, właściciel nie miał nic specjalnego do stracenia, ponieważ przed naszym bohaterem różni pracownicy próbowali już wszystko naprawić i ogólnie zadanie uważano za praktycznie nierozwiązywalne. Wszystko to ogromnie wzbudziło zainteresowanie, bo gdyby wszystko się udało, koleś automatycznie stałby się osobą, która wie, jak uporządkować i rozwiązać nierozwiązywalne problemy.
Stanął więc przed zadaniem: zmniejszyć odchylenia na podstawie wyników inwentaryzacji 2 razy w ciągu roku. Na początku projektu nie miał pojęcia, jak to osiągnąć, ale rozumiał, że księgowość magazynu to prosta sprawa, więc nadal będzie mógł zrobić coś pożytecznego. Co więcej, zmniejszenie odchyleń z kilkudziesięciu procent do kilkudziesięciu procent nie wydaje się takie trudne. Każdy, kto pracował w konsultingu lub podobnej działalności, rozumie, że większość problemów procesowych można rozwiązać za pomocą dość prostych kroków.
Od stycznia do maja przygotowywał, trochę zautomatyzował, przepisał proces biznesowy księgowości magazynowej, zmienił przepływ pracy magazynierów, księgowych i ogólnie przerobił cały system, nic nikomu nie pokazując ani nie mówiąc. W maju rozdał wszystkim nowe instrukcje, a po pierwszej w tym roku inwentaryzacji rozpoczęło się nowe życie – praca według jego zasad. Aby obserwować rezultaty, w przyszłości firma zaczęła częściej przeprowadzać inwentaryzacje – raz na dwa miesiące. Już pierwsze wyniki były pozytywne, a pod koniec roku odchylenia od wyników kontroli spadły do ułamka jednego procenta.
Sukces był kolosalny, ale nie można było wierzyć w jego trwałość. Sam facet wątpił, czy wynik zostanie zachowany, jeśli odejdzie na bok i przestanie obserwować proces. Niemniej jednak doszło do skutku i facet otrzymał wszystko, co uzgodnił z właścicielem. Następnie po kilku latach potwierdzono stabilność wyniku – przez kilka lat odchylenia utrzymywały się w granicach 1%.
Następnie zdecydował się powtórzyć eksperyment i zasugerował właścicielowi ulepszenie innego problematycznego procesu – zaopatrzenia. Występowały braki, które nie pozwalały nam na wysyłkę ilości oczekiwanych przez naszych klientów. Uzgodniliśmy, że w ciągu roku deficyty zmniejszą się o połowę, a facet wykona także 10-15 projektów związanych z 1C - automatyzacją różnych procesów biznesowych i innych herezji.
W drugim roku znów wszystko udało się zakończyć sukcesem, deficyty zmniejszyły się ponad 2-krotnie, wszystkie projekty informatyczne zostały zakończone sukcesem.
Ponieważ pensja już w pełni zaspokajała potrzeby tego faceta na dwa lata z góry, postanowił się trochę uspokoić, uspokoić i usiąść w przytulnym, ciepłym miejscu, które dla siebie stworzył.
Jak było? Formalnie był dyrektorem IT. Ale kim naprawdę był, trudno zrozumieć. W końcu czym zajmuje się dyrektor IT? Z reguły administruje infrastrukturą IT, zarządza administratorami systemów, wdraża system ERP, uczestniczy w posiedzeniach zarządu.
I ten koleś miał jeden z kluczowych obowiązków uczestniczenia w procesach zmian, a przede wszystkim - generowania, inicjowania tych procesów, poszukiwania i proponowania rozwiązań, stosowania nowych technik zarządzania, badania proponowanych zmian, analizy efektywności innych funkcji i dywizji i wreszcie bezpośredni udział w strategicznym rozwoju przedsiębiorstwa, aż do samodzielnego opracowania planu strategicznego dla całej firmy.
Dostał carte blanche. Mógł przyjść na każde spotkanie, do którego wcześniej nie miał dostępu. Siedziałem tam z notatnikiem, zapisując coś lub po prostu słuchając. Rzadko mówił. Potem zaczął grać na telefonie, twierdząc, że w ten sposób pamięć skojarzeniowa działa lepiej.
Na spotkaniach rzadko rozdawał coś przydatnego. Wyszedł, pomyślał, przyszedł list – albo z krytyką, albo z opinią, albo z sugestiami, albo z opisem rozwiązań, które już zastosował.
Częściej jednak sam zwoływał spotkania. Znalazłem problem, zaproponowałem rozwiązania, zidentyfikowałem zainteresowane strony i zaprosiłem wszystkich na spotkanie. A potem – najlepiej jak potrafił. Przekonał, zmotywował, udowodnił, argumentował, osiągnął.
Nieoficjalnie uważany był za trzecią osobę w firmie, po właścicielu i dyrektorze. Oczywiście strasznie rozwścieczył wszystkich „ludzi z firmy”, zaczynając od numeru 4. Zwłaszcza swoimi podartymi dżinsami i jasnymi T-shirtami, a także swoim czasem jako właściciela.
Właściciel poświęcał mu 1 godzinę dziennie. Codziennie. Rozmawiali, omawiali problemy, rozwiązania, nowe biznesy, obszary rozwoju, wskaźniki i efektywność, rozwój osobisty, książki i po prostu życie.
Ale ten facet był dziwny. To tak, usiądź wygodnie i bądź szczęśliwy, życie jest dobre. Ale nie. Postanowił się zastanowić.
Zastanawiał się: dlaczego jemu się to udało, a innym nie? Właściciel też go naciskał: powiedział, że chce, żeby inni też potrafili zaprowadzić porządek, bo menedżerów jest wielu, oni z reguły zajmują się zarządzaniem operacyjnym i planowaniem strategicznym, ale praktycznie nikt nie zajmuje się zmianami systemowymi w swoich procesach. W opisie stanowiska może być napisane, że powinni przyspieszyć swój proces i zwiększyć jego efektywność, ale tak naprawdę nikt tego nie robi. Dlaczego? Faceta też zainteresowało dlaczego i poszedł porozmawiać ze wszystkimi menedżerami.
Przyszedł do zastępcy dyrektora ds. jakości i zasugerował wprowadzenie kart kontrolnych Shewharta, aby produkty były lepsze od japońskich. Okazało się jednak, że kolega nie wiedział, czym są karty kontrolne Shewharta, czym jest statystyczne sterowanie procesem, a słyszał jedynie o zastosowaniu cyklu Deminga w zarządzaniu jakością. OK…
Poszedł do innego zastępcy dyrektora i zaproponował wprowadzenie kontrolingu. Ale i tutaj nie znalazłem wsparcia. Nieco później dowiedział się o zarządzaniu granicami (zarządzaniu granicami) i zasugerował, aby wszyscy zastępcy dyrektorów wdrażali systemową część tej metodyki w celu usprawnienia procesów. Ale niezależnie od tego, jak dużo mówił nasz facet, nikt tak naprawdę nie chciał zagłębiać się w to, o czym to było. Może nie byli zainteresowani, albo było to zbyt trudne. Ale tak naprawdę nikt na to nie wpadł.
Generalnie opowiadał o wszystkim co znał i używał w firmie. Ale nikt go nie rozumiał. Nadal nie rozumieją, dlaczego na przykład wszystko zostało poprawione w księgowości magazynu i co ma z tym wspólnego kontrola i zarządzanie granicami.
Na koniec dotarł do swoich programistów – w skład zespołu wchodziły 3 osoby. Opowiadał o zarządzaniu granicami, o kontrolingu, o zarządzaniu jakością, o zwinności i scrumie... I o dziwo, oni wszystko rozumieli, a nawet potrafili z nim jakoś podyskutować, łącznie z subtelnościami technicznymi i metodologicznymi. Rozumieli, dlaczego projekty magazynowania i zaopatrzenia się powiodły. I wtedy facetowi przyszło do głowy: tak naprawdę programiści uratują świat.
Uświadomił sobie, że programiści są jedynymi, którzy potrafią normalnie zrozumieć procesy biznesowe z niezbędnymi szczegółami.
Dlaczego oni? Tak naprawdę nigdy nie znalazł jasnej odpowiedzi. Sformułowałem jedynie wskazówki do tezy.
Po pierwsze, programiści znają obszary tematyczne biznesu i znają je lepiej niż wszystkie inne osoby w firmie.
Ponadto programiści naprawdę rozumieją, czym jest algorytm procesu. Jest to ważne, ponieważ procesy biznesowe są algorytmami, a elementy w nich zawarte mogą po prostu nie być spójne. Na przykład w procesie zakupowym, nad którym pracował facet, pierwszym krokiem było stworzenie rocznego planu zakupów, a drugim codzienne zakupy. Kroki te łączy bezpośrednie połączenie, to znaczy zakłada się, że ludzie powinni pracować według tego algorytmu - sporządzić roczny plan zakupów i natychmiast zrealizować żądanie. Roczny plan zamówień sporządzany jest raz w roku, a wnioski wpływają 50 razy dziennie. W tym miejscu algorytm się kończy i trzeba nad nim popracować. W rzeczywistości – argumentował – dla programistów znajomość algorytmów stanowi przewagę konkurencyjną, ponieważ każdy, kto ich nie zna, po prostu nie rozumie, jak powinien działać proces biznesowy i jak można go przedstawić.
Według faceta kolejną zaletą programistów jest to, że mają wystarczająco dużo wolnego czasu. Wszyscy rozumiemy, jak programista może spędzić nad zadaniem trzy razy więcej czasu, niż jest to faktycznie potrzebne, i niewielu to zauważy. To znowu jest przewaga konkurencyjna, bo żeby uporządkować jakiś proces biznesowy trzeba mieć dużo wolnego czasu - myśleć, obserwować, studiować i próbować.
Większość menedżerów, zdaniem faceta, nie ma tego wolnego czasu i jest z tego dumna. Chociaż tak naprawdę oznacza to, że człowiek nie może stać się skuteczny, bo nie ma czasu na poprawę efektywności – błędne koło. W naszej kulturze modne jest bycie zajętym, więc wszystko pozostaje takie samo. A dla nas, programistów, jest to zaleta. Możemy znaleźć wolny czas i przemyśleć wszystko.
Programiści, powiedział, mogą szybko zmienić system informatyczny. Nie dotyczy to wszystkich przedsiębiorstw, ale gdziekolwiek pracował, mógł wprowadzać dowolne modyfikacje. Zwłaszcza jeśli nie dotyczą one twórczości nikogo innego. Mógłby na przykład uruchomić system, który w tajemnicy mierzyłby działania użytkowników, a następnie wykorzystał te informacje do analizy wydajności tego samego działu księgowego i śledzenia kosztów księgowości.
I ostatnie co pamiętam z jego słów to to, że programiści mają dostęp do dużej ilości informacji, bo... mieć dostęp administracyjny do systemu. Dlatego mogą wykorzystać te informacje w swoich analizach. Nikt inny w zwykłym zakładzie nie ma takiego zasobu.
A potem odszedł. Podczas wymaganego dwutygodniowego aresztu zmusiliśmy go do podzielenia się swoimi doświadczeniami, ponieważ chcieliśmy kontynuować pracę, którą wykonywał. Cóż, jego stanowisko zwolniło się.
Przez kilka dni sadzali go na krześle, włączali kamerę i nagrywali jego monologi. Prosili o opowiedzenie o wszystkich zrealizowanych projektach, metodach, podejściach, sukcesach i porażkach, przyczynach i skutkach, portretach menedżerów itp. Nie było specjalnych ograniczeń, bo Nie wiedzieli, co się dzieje w jego głowie.
Monologi oczywiście były w większości same bzdury i śmiechy – był w świetnym humorze, bo wyjeżdżał z buszu do St. Petersburga. Gdzie wybrać się do pracy w Petersburgu? Oczywiście dla Gazpromu.
Ale udało nam się wydobyć coś przydatnego z jego monologów. Opowiem ci, co pamiętam.
A więc zalecenia tego gościa. Dla tych, którzy chcą spróbować uporządkować procesy biznesowe.
Aby wykonać tego rodzaju pracę, po pierwsze, musisz mieć pewien poziom „odmrożenia”. Nie należy bać się utraty pracy, nie bać się podejmować ryzyka, nie bać się konfliktów ze współpracownikami. Było to dla niego łatwe, bo swoją drogę rozpoczął mając zaledwie pół roku pracy w firmie, a nie miał czasu i nie miał zamiaru z nikim się kontaktować. Rozumiał, że ludzie przychodzą i odchodzą, ale ważne są dla niego własne wyniki i ich ocena przez właściciela firmy. To, czy koledzy traktowali go dobrze, czy źle, nie obchodziło go wtedy.
Druga kwestia jest taka, że aby skutecznie wykonywać tę pracę, niestety trzeba będzie się uczyć. Ale nie studiuj dla MBA, nie na kursach, nie w instytutach, ale na własną rękę. Na przykład w swoim pierwszym projekcie, projekcie magazynowym, działał intuicyjnie, nie wiedział nic, tylko czym jest „zarządzanie jakością”.
Kiedy zaczął czytać literaturę na temat tego, jakie istnieją metody zwiększania wydajności, odkrył technologie, które sam zastosował. Facet zastosował je intuicyjnie, ale okazuje się, że to nie był jego wynalazek, wszystko zostało już napisane dawno temu. Ale spędził czas i znacznie więcej, niż gdyby od razu przeczytał odpowiednią książkę. Tutaj ważne jest tylko, aby zrozumieć, że studiując konkretną technikę, żadna z nich, nawet najbardziej zaawansowana, nie rozwiąże całkowicie wszystkich problemów procesu biznesowego.
Druga sztuczka polega na tym, że im więcej technik znasz, tym lepiej. Na przykład w starożytnej Japonii żył Miyamoto Musashi, jeden z najsłynniejszych szermierzy, twórca stylu dwóch mieczy. Uczył się w jakiejś szkole u jakiegoś mistrza, potem podróżował po Japonii, walczył z różnymi kolesiami. Jeśli facet był silniejszy, podróż zatrzymała się na jakiś czas, a Musashi został uczniem. W rezultacie w ciągu kilku lat nabył umiejętności różnych praktyk różnych mistrzów i założył własną szkołę, dodając coś od siebie. W rezultacie osiągnął wyjątkową umiejętność. Tutaj jest tak samo.
Możesz oczywiście działać jako doradca biznesowy. Generalnie to wspaniali chłopaki. Ale z reguły przychodzą, aby wprowadzić jakąś metodologię i wdrażają niewłaściwą metodologię, której potrzebuje biznes. Mieliśmy też takie smutne sytuacje: nikt nie wie, jak rozwiązać problem i nikt nie chce myśleć, jak go rozwiązać. Zaczynamy szukać albo w Internecie, albo dzwonimy do konsultanta i pytamy, co może nam pomóc. Konsultant myśli i mówi, że trzeba wprowadzić teorię ograniczeń. Płacimy mu za rekomendację, wydajemy pieniądze na wdrożenie, ale efekty są zerowe.
Dlaczego to się dzieje? Bo konsultant powiedział, że wprowadzamy taki a taki system i wszyscy się z nim zgodzili. Świetnie, ale jedna metodologia nie obejmuje wszystkich problemów nawet jednego procesu biznesowego, zwłaszcza jeśli wstępne przesłanki – nasze i te wymagane do wdrożenia metodologii – nie pokrywają się.
W praktyce, którą poleca facet, musisz brać to, co najlepsze i wdrażać to, co najlepsze. Nie kieruj się całkowicie metodami, ale ich kluczowymi cechami, cechami i praktykami. A najważniejsze to zrozumieć istotę.
Weźmy, powiedział, na przykład Scrum lub Agile. W swoich monologach facet wielokrotnie powtarzał, że nie wszyscy do końca rozumieją istotę Scruma. Przeczytał także książkę Jeffa Sutherlanda, którą niektórzy uważają za „lekką lekturę”. Wydawało mu się to głęboką lekturą, ponieważ jedną z podstawowych zasad Scruma jest zarządzanie jakością, jest to zapisane bezpośrednio w książce.
Opowiada o Toyocie Production, o tym, jak Jeff Sutherland pokazał Scrum w Japonii, jak się tam zakorzenił i jak blisko był ich filozofii. A Sutherland mówił o znaczeniu roli Scrum Mastera, o cyklu Deminga. Rolą Scrum Mastera jest ciągłe przyspieszanie procesu. Wszystko inne, co jest w Scrumie – dostawa etapowa, satysfakcja klienta, jasna lista prac na okres sprintu – też jest ważne, ale to wszystko musi działać coraz szybciej. Szybkość pracy musi stale rosnąć w jednostkach, w których jest mierzona.
Być może jest to kwestia tłumaczenia, gdyż nasza książka została przetłumaczona jako „Scrum – rewolucyjna metoda zarządzania projektami”, a jeśli angielski tytuł przetłumaczyć dosłownie, okaże się: „Scrum – dwa razy więcej w o połowę krótszym czasie” , czyli nawet w Nazwa odnosi się do szybkości jako kluczowej funkcji Scruma.
Kiedy ten facet wdrożył Scruma, prędkość podwoiła się w pierwszym miesiącu bez żadnych znaczących zmian. Znalazł punkty do zmian i zmodyfikował sam Scrum, aby działał znacznie szybciej. Jedyne, co piszą w Internecie, to to, że stanęło przed pytaniem: „Podwoiliśmy prędkość, pozostaje tylko zrozumieć, co robimy przy takiej prędkości?” To jednak zupełnie inna dziedzina...
Osobiście polecił także kilka technik. Nazwał je fundamentalnymi i fundamentalnymi.
Pierwszym z nich jest zarządzanie granicami.
Uczą tego w Skołkowie, według faceta nie ma innych książek i materiałów. Miał szczęście, że był na wykładzie profesora z Harvardu, który głosi zarządzanie granicami, a także przeczytał kilka artykułów w Harvard Business Review na temat twórczości Erica Trista.
Zarządzanie granicami mówi, że musisz umieć dostrzegać granice i pracować z nimi. Granic jest mnóstwo, są wszędzie – pomiędzy działami, pomiędzy różnymi rodzajami pracy, pomiędzy funkcjami, pomiędzy pracą operacyjną i analityczną. Znajomość zarządzania granicami nie odsłania żadnych wyższych prawd, ale pozwala spojrzeć na rzeczywistość w nieco innym świetle – przez pryzmat granic. I odpowiednio zarządzaj nimi - stawiaj je tam, gdzie to konieczne i usuwaj je, gdzie przeszkadzają.
Ale najczęściej facet mówił o kontrolowaniu. Po prostu miał jakieś dziwactwo w tym temacie.
Controlling to w skrócie zarządzanie oparte na liczbach. Tutaj, powiedział, ważny jest każdy element definicji – zarówno „zarządzanie”, jak i „oparte na” i „liczbach”.
My, powiedział, jesteśmy źli we wszystkich trzech elementach kontrolowania. Zwłaszcza biorąc pod uwagę, że są one ściśle ze sobą powiązane zarówno między sobą, jak i z innymi częściami systemu biznesowego.
Pierwszą rzeczą, która jest zła, są liczby. Jest ich niewiele i są niskiej jakości.
Następnie pobraliśmy znaczną część liczb z systemu informacyjnego 1C. Zatem jakość liczb w 1C, jak twierdził, nie jest dobra. Przynajmniej ze względu na możliwość zmiany danych z mocą wsteczną.
Oczywiste jest, że nie jest to wina programistów 1C - biorą oni pod uwagę jedynie wymagania rynku i mentalność krajowej rachunkowości. Ale do celów kontrolnych lepiej zmienić zasady pracy 1C z danymi w konkretnym przedsiębiorstwie.
Co więcej, według niego liczby z 1C poddawane są półręcznemu przetwarzaniu, na przykład za pomocą Excela. Takie przetwarzanie również nie podnosi jakości danych ani wydajności.
Na koniec ktoś inny dwukrotnie sprawdza raport końcowy, aby przypadkowo nie przekazać kierownikowi danych zawierających błędy. Dzięki temu numery docierają do odbiorcy piękne, sprawdzone, ale z dużym opóźnieniem. Zwykle - po zakończeniu okresu (miesiąca, tygodnia itp.).
A tutaj, powiedział, wszystko jest bardzo proste. Jeśli liczby dotyczące stycznia przyjdą do ciebie w lutym, nie będziesz już mógł zarządzać działaniami w styczniu. Bo styczeń już minął.
A jeśli dane opierają się na rachunkowości, a firma jest najzwyklejsza i składa kwartalnie podatek VAT, to jej menadżer raz na kwartał otrzymuje w miarę adekwatne dane.
Reszta jest jasna. Numery otrzymujesz raz w miesiącu - masz możliwość zarządzania numerami (czyli kontroli) 12 razy w roku. Jeśli praktykujesz raportowanie kwartalne, zarządzasz nim 4 razy w roku. Plus bonus - raportowanie roczne. Steruj jeszcze raz.
Przez resztę czasu kontrola odbywa się zwykle na ślepo.
Kiedy (i jeśli) liczby się pojawią, pojawia się drugi problem – jak zarządzać w oparciu o liczby? Nie mogłem zgodzić się z tym punktem jego rozumowania.
Facet argumentował, że gdyby menadżer nie miał wcześniej numerów, to ich pojawienie się wywołałoby efekt wow. Będzie patrzył i przekręcał liczby to w tę, to w tamtą stronę, będzie dzwonił do ludzi na dywanie, żądał wyjaśnień i dochodzeń. Po zabawie liczbami, przeprowadzeniu analiz i groźbie obiecaniu wszystkim pracownikom, że „teraz się ciebie nie pozbędę”, menedżer bardzo szybko się uspokoi i zrezygnuje w tej sprawie. Przestań używać tego narzędzia. Ale problemy pozostaną.
Dzieje się tak – stwierdził – z powodu niewystarczających kompetencji menedżerskich. Przede wszystkim w kontrolowaniu. Menedżer po prostu nie wie, co zrobić z tymi liczbami. Co сrobić – wie, co robić – nie. Robić to, o czym napisano powyżej (kłócić się, bawić się). Robienie to codzienny proces biznesowy.
Przekonywał, że wszystko jest bardzo proste: cyfrowość musi stać się częścią procesu biznesowego. W procesie biznesowym powinno być jasne: kto, co i kiedy powinien zrobić, jeśli liczby odbiegają od normy (dowolne opcje - powyżej granicy, poniżej granicy, wyjście poza korytarz, obecność trendu, niespełnienie kwantyl itp.)
I tak nakreślił kluczowy dylemat: liczba istnieje, powinna stać się częścią systemu biznesowego, aby zwiększyć efektywność zarządzania, ale… tak się nie dzieje. Dlaczego?
Bo rosyjski przywódca nie odda części swojej władzy konkurentowi.
Konkurenci rosyjskiego menedżera - wysokiej jakości i działający proces biznesowy, przemyślana, wzajemnie korzystna motywacja i odpowiednia automatyzacja - niestety pozostawią menedżera bez pracy.
Trochę bzdury, nie zgadzasz się? Zwłaszcza jeśli chodzi o przywódców. OK, mówiłem ci, decyzja należy do ciebie.
Trochę mniej, ale wciąż za dużo, moim zdaniem, mówił o Scrumie.
Bądź pewien, mówiłem, czytaj i wypróbuj Scruma w praktyce. Jeśli, mówi, przeczytałeś, ale nie próbowałeś, uważaj się za ignoranta. Lepiej przeczytać książkę, na przykład Sutherlanda, niż artykuły i wszelkiego rodzaju poradniki (co do cholery?) w Internecie.
Scruma, stwierdził, można się nauczyć jedynie poprzez praktykę i obowiązkowy pomiar ilości wykonanej pracy. Osobiście wypróbuj dwie najważniejsze role – Właściciela Produktu i Scrum Mastera.
Szczególnie ważne, zdaniem faceta, jest doświadczenie w praktyce roli Scrum Mastera, kiedy można zwiększyć ilość zadań wykonywanych w trakcie sprintu bez zwiększania zasobów i kosztów sprintu.
Otóż na jego szczycie znalazł się TOS (teoria ograniczeń systemu).
To według faceta są podstawowe, fundamentalne zasady zwiększania efektywności, które można zastosować w niemal każdym obszarze, w każdym procesie biznesowym i systemie biznesowym jako całości.
Kiedy dowiedział się, że nie znamy TOS, przestał nam o tym mówić. Dodał tylko, że nie pozbawi nas przyjemności czytania książek Eliyahu Goldratta. Podobną rekomendację dał Scrumowi – przeczytaj i wypróbuj. Niezależnie od tego, na jakim stanowisku się znajdujesz, niezależnie od tego, jaką pracę wykonujesz, jest miejsce na zwiększanie wydajności za pomocą metod TOC.
Potem jego zestaw technik najwyraźniej się wyczerpał i powiedział: wymieszaj zasady, aby stworzyć rozwiązania stosowane w konkretnej sytuacji.
To, jego zdaniem, jest główna rekomendacja, klucz do sukcesu. Zrozum zasady, istotę i twórz unikalne rozwiązania aplikacyjne - procesy biznesowe i systemy biznesowe.
Potem próbował sobie przypomnieć jakiś cytat, aż w końcu musiał połączyć się z internetem. Okazało się, że był to cytat z artykułu „Stojąc na ramionach gigantów” Eliyahu Goldratta:
„Istnieje różnica pomiędzy stosowanymi rozwiązaniami (aplikacjami) a podstawowymi koncepcjami, na których te rozwiązania się opierają. Koncepcje są ogólne, stosowane rozwiązania to adaptacja koncepcji do konkretnego środowiska. Jak już widzieliśmy, taka adaptacja nie jest prosta i wymaga opracowania pewnych elementów rozwiązania. Musimy pamiętać, że rozwiązanie aplikacyjne opiera się na wstępnych założeniach (czasami ukrytych) na temat konkretnego środowiska. Nie należy oczekiwać, że to rozwiązanie aplikacyjne będzie działać w środowisku, dla którego założenia nie są prawidłowe.”
Powiedział, że praca programisty i „poprawiacza procesów biznesowych” jest bardzo podobna. I wyszedł.
Źródło: www.habr.com