Historia prawdziwa, widziałem to na własne oczy.
Przez kilka lat pewien chłopak, jak wielu z was, pracował jako programista. Na wszelki wypadek napiszę tak: «programistą». Ponieważ był programistą 1C, na stałej umowie, w firmie produkcyjnej.
Przedtem próbował różnych specjalności — 4 lata jako programista w franczyzie, lider projektów, umiał zamykać po 200 godzin, jednocześnie otrzymując procent z projektu, za zarządzanie i trochę zajmując się sprzedażą. Próbowal samodzielnie opracowywać produkty, był szefem działu IT w dużej firmie liczącej 6 tysięcy pracowników, przymierzał różne warianty zastosowania swojej programistycznej profesji — programisty 1C.
Ale wszystkie te pozycje były nieco beznadziejne, przede wszystkim pod względem dochodów. Wszyscy wtedy zarabialiśmy mniej więcej te same pieniądze, pracując w tych samych warunkach.
Ten chłopak zaczął się zastanawiać, jak można zarabiać więcej pieniędzy, nie zajmując się sprzedażą i nie zakładając własnego biznesu.
Wyobraził sobie, że jest mądry i postanowił znaleźć niszę w firmie, w której pracował. Niszta ta miała być jakaś szczególna, niezajęta przez nikogo. Chciało mu się, by firma sama chciała płacić pieniądze osobie w tej niszy, żeby nie trzeba było nikogo oszukiwać ani niczego podkręcać. Aby było to obiektywne: człowiek na tym stanowisku musi zarabiać dużo pieniędzy. Dziwak, jednym słowem.
Poszukiwania nie trwały długo. W firmie, w której pracował ten chłopak, była zupełnie wolna nisza, którą można określić jako «porządkowanie procesów biznesowych». W każdej firmie jest mnóstwo problemów. Zawsze coś nie działa i nie ma nikogo, kto by przyszedł i poprawił procesy biznesowe. Postanowił więc spróbować swoich sił w roli specjalisty, który może pomóc właścicielowi rozwiązać jego problemy w procesach biznesowych.
W tamtym momencie pracował w firmie od pół roku i otrzymywał średnią pensję na rynku. Nie miał nic do stracenia — tym bardziej, że podobną pracę mógł znaleźć w ciągu jednego tygodnia. Ogólnie rzecz biorąc, ten chłopak uznał, że nic strasznego się nie stanie, jeśli nagle nic z tego nie wyjdzie i go zwolnią.
Zebrał się na odwagę i przyszedł do właściciela. Zaproponował poprawę najbardziej problematycznego procesu, który istniał w firmie. W tamtym czasie była to gospodarka magazynowa. Dziś wszyscy, którzy pracują w tej firmie, wstydzą się nawet wspominać o tych problemach, ale inwentaryzacje, które przeprowadzano co kwartał, wykazywały odchylenia między systemem księgowym a rzeczywistymi stanami na poziomie dziesiątek procent. Zarówno w przypadku wartości, ilości, jak i liczby pozycji. To był poważny problem. Firma miała prawidłowe stany w systemie księgowym tylko cztery razy w roku – na dzień po inwentaryzacji. Ten proces nasz bohater postanowił uporządkować.
Chłopak umówił się z właścicielem, że musi zmniejszyć odchylenia wyników inwentaryzacji o połowę. Właściciel nie miał wiele do stracenia, ponieważ przed naszym bohaterem różni pracownicy już próbowali wszystko naprawić, a ogólnie zadanie uważano za praktycznie nierozwiązywalne. To wszystko bardzo podgrzewało zainteresowanie, ponieważ jeśli wszystko się powiedzie, to gość automatycznie stanie się osobą, która potrafi wprowadzać porządek i rozwiązywać nierozwiązywalne problemy.
Otóż przed nim stało zadanie: w ciągu roku zmniejszyć odchylenia wyników inwentaryzacji dwukrotnie. W momencie rozpoczęcia projektu nie miał pojęcia, jak to osiągnąć, ale rozumiał, że gospodarka magazynowa to prosta sprawa, więc i tak uda mu się coś wartościowego zrobić. Tym bardziej, że zmniejszenie odchyleń z dziesiątek procent do jednego lub dwóch procent nie wydaje się takie trudne. Wszyscy, którzy pracowali w obszarze doradztwa lub podobnej działalności, zdają sobie sprawę, że większość problemów procesu można rozwiązać stosunkowo prostymi działaniami.
Od stycznia do maja pracował nad przygotowaniami, trochę zautomatyzował, przepisał procesy biznesowe związane z gospodarką magazynową, zmienił przepływy pracy magazynierów, księgowych i w ogóle przebudował cały system, nikomu nic nie pokazując i nie opowiadając. W maju rozdał wszystkim nowe instrukcje, a po pierwszej inwentaryzacji w roku zaczęło się nowe życie – praca zgodnie z jego zasadami. Aby obserwować wyniki, firma zaczęła przeprowadzać inwentaryzacje częściej – co dwa miesiące. Już pierwsze wyniki były pozytywne, a do końca roku odchylenia w wynikach rewizji spadły do ułamków procenta.
Sukces był ogromny, ale nie wierzyli w jego trwałość. Sam chłopak wątpił, że wynik zostanie zachowany, jeśli odsunie się na bok i przestanie obserwować proces. Niemniej jednak wynik był, a chłopak otrzymał wszystko, o co dogadał się z właścicielem. Później, po kilku latach, trwałość wyniku została potwierdzona — przez kilka lat odchylenia utrzymywały się w granicach 1%.
Wtedy postanowił powtórzyć eksperyment i zaproponował właścicielowi ulepszenie innego problematycznego procesu – zaopatrzenia. Tam były braki, które uniemożliwiały wysyłkę takich ilości, jakich chcieli nasi klienci. Ustalono, że w ciągu roku braki zostaną zmniejszone o połowę, a chłopak dodatkowo zrealizuje 10-15 projektów związanych z 1C — dotyczących automatyzacji różnych procesów biznesowych i innych rzeczy.
W drugim roku znów udało się wszystko zrealizować, braki zmniejszyły się o więcej niż 2 razy, wszystkie projekty IT zostały zrealizowane pomyślnie.
Ponieważ wynagrodzenie już w pełni spełniało jego oczekiwania na dwa lata do przodu, postanowił się trochę uspokoić, zrelaksować i usiąść w wygodnym, ciepłym miejscu, które sam sobie stworzył.
Co to oznaczało? Formalnie był dyrektorem IT. Ale kim tak naprawdę był, trudno zrozumieć. Czym zajmuje się dyrektor IT? Z reguły administruje infrastrukturą IT, kieruje administratorami systemów, wdraża system ERP, uczestniczy w spotkaniach zarządu.
A ten facet był jedną z kluczowych osób w procesach zmian, głównie zajmując się generowaniem i inicjowaniem tych procesów, poszukiwaniem i proponowaniem rozwiązań, wdrażaniem nowych metod zarządzania, oceną proponowanych zmian, analizą efektywności innych funkcji i działów, a w końcu – bezpośrednim udziałem w strategicznym rozwoju firmy, aż po samodzielne opracowanie strategicznego planu całej firmy.
Dostał carte blanche. Mógł brać udział w każdej naradzie, do której wcześniej nie miał dostępu. Siedział tam z notatnikiem, coś zapisywał lub po prostu słuchał. Mówił rzadko. Potem zaczął grać na telefonie – twierdził, że tak lepiej działa pamięć asocjacyjna.
Na naradach rzadko wnosił coś wartościowego. Odchodził, myślał, a potem przychodził e-mail – albo z krytyką, albo z opinią, albo z propozycjami, albo z opisem rozwiązań, które już wdrożył.
Ale częściej to on sam organizował narady. Znajdował problem, wymyślał opcje rozwiązania, wyznaczał zainteresowane osoby i ciągnął wszystkich do pokoju negocjacyjnego. A tam – jak potrafił. Przekonywał, motywował, dowodził, spierał się, dążył do realizacji.
Nieoficjalnie uważano go za trzecią osobę w firmie, po właścicielu i dyrektorze. Oczywiście, wkurzał wszystkich „znajomych firmy”, zaczynając od numeru 4. Szczególnie swoimi poszarpanymi dżinsami i jaskrawymi koszulami, a także czasem, który poświęcał właściciel.
Właściciel poświęcał mu 1 godzinę dziennie. Codziennie. Rozmawiali, omawiali problemy, rozwiązania, nowe przedsięwzięcia, kierunki rozwoju, wskaźniki i efektywność, rozwój osobisty, książki, a także po prostu – życie.
Jednak ten facet był dziwny. Jakby – siedź i ciesz się, życie się powiodło. Ale nie. Postanowił się zrefleksjonować.
Zaciekawiło go to, dlaczego on osiągnął sukces, a inni – nie? Właściciel także go do tego zachęcał: mówił, że chciałby, aby inni również potrafili wprowadzać porządek, ponieważ menedżerów jest wielu, zazwyczaj zajmują się zarządzaniem operacyjnym i planowaniem strategicznym, ale praktycznie nikt nie zajmuje się systemowymi zmianami swoich procesów. Może w ich opisach stanowisk zapisane jest, że powinni przyspieszać swoje procesy, zwiększać ich efektywność, ale w rzeczywistości nikt się tym nie zajmuje. Dlaczego tak się dzieje? Tego samego też zaciekawiło chłopaka, więc postanowił porozmawiać ze wszystkimi tymi menedżerami.
Przyszedł do zastępcy dyrektora ds. jakości i zaproponował wdrożenie kart kontrolnych Shuharta, aby produkt był lepszy niż japoński. Okazało się jednak, że kolega nie wie, czym są karty kontrolne Shuharta, co to jest statystyczne zarządzanie procesami, i tylko w minimalnym zakresie słyszał o zastosowaniu cyklu Deminga w zarządzaniu jakością. No cóż...
Poszedł do innego zastępcy dyrektora i zaproponował wdrożenie controllingu. Ale również tutaj nie znalazł wsparcia. Jeszcze trochę później dowiedział się o zarządzaniu granicami i wszystkim zastępcom dyrektora zaproponował wdrożenie systemowej części tej metodyki, aby poprawić procesy. Ale ilekroć rozmawiał z tymi ludźmi, nikt nie chciał się w to wgłębiać. Może to ich nie interesowało lub było zbyt skomplikowane. W rzeczywistości nikt nie zrozumiał.
Ogólnie rzecz biorąc, opowiedział o wszystkim, co wiedział i stosował w firmie. Ale nikt go tak naprawdę nie zrozumiał. Do dzisiaj nie mają pojęcia, dlaczego, na przykład, udało się poprawić stan ewidencji magazynowej i w jaki sposób związany jest z tym controlling oraz zarządzanie granicami.
Na końcu dotarł do swoich programistów – w zespole było 3 osoby. Opowiedział o zarządzaniu granicami, o controllingu, o zarządzaniu jakością, o agile i scram... I ku jego zdziwieniu wszyscy to zrozumieli, a nawet potrafili z nim o tym jakoś porozmawiać, w tym także – o technicznych i metodologicznych szczegółach. Zrozumieli, dlaczego projekty związane z magazynem i zaopatrzeniem się udały. I wtedy chłopaku olśniło: tak naprawdę to programiści uratują świat.
Programiści, zrozumiał, to jedyni, którzy będą w stanie właściwie, z potrzebną dokładnością zgłębić procesy biznesowe.
Dlaczego akurat oni? Tak naprawdę nie znalazł jednoznacznej odpowiedzi. Sformułował tylko tezy.
Po pierwsze, programiści znają obszary biznesowe, przy czym znają je lepiej niż wszyscy inni w firmie.
Ponadto programiści naprawdę rozumieją, czym jest algorytm procesu. To ważne, ponieważ procesy biznesowe to algorytmy, a elementy w nich mogą być po prostu niezgodne. Na przykład, w procesie zaopatrzenia, nad którym pracował chłopak, pierwszym krokiem jest sporządzenie rocznego planu zakupów, a drugim – codzienny zakup. Te kroki są połączone bezpośrednim powiązaniem, to znaczy zakłada się, że według tego algorytmu ludzie powinni pracować – sporządzać roczny plan zakupów i od razu realizować zamówienie. Roczny plan zakupów sporządza się raz w roku, a zamówienie wpada 50 razy dziennie. Na tym algorytm się kończy i według niego należy pracować. W rzeczywistości, pomyślał, dla programistów znajomość algorytmów to przewaga konkurencyjna, ponieważ każdy inny człowiek, który nie jest z nimi zaznajomiony, po prostu nie rozumie, jak powinien działać proces biznesowy i jak można go zobrazować.
Kolejną zaletą programistów, według słów tamtego chłopaka, jest to, że mają wystarczająco dużo wolnego czasu. Wszyscy rozumiemy, jak programista może poświęcić na zadanie trzy razy więcej czasu, niż to na prawdę wymaga, i mało kto to zauważy. To, znowu, jest przewaga konkurencyjna, ponieważ aby uporządkować jakiś proces biznesowy, trzeba mieć dużo wolnego czasu — myśleć, obserwować, uczyć się i próbować.
Większość menedżerów, według słów chłopaka, nie ma tego wolnego czasu i szczyci się tym. Choć w rzeczywistości oznacza to, że nie mogą stać się efektywni, ponieważ nie mają czasu na poprawę efektywności — błędne koło. W naszej kulturze być zajętym jest modne, więc wszystko pozostaje na miejscu. A dla nas, programistów, to przewaga. Możemy znaleźć wolny czas i pomyśleć o wszystkim.
Programiści, mówił, mogą szybko zmienić system informacyjny. Nie jest to możliwe we wszystkich firmach, ale wszędzie, gdzie pracował, można było wprowadzać wszelkie zmiany, które uznał za stosowne. Szczególnie, jeśli nie dotyczyły niczyjej pracy. Na przykład mógł uruchomić system, który potajemnie mierzy działania użytkowników, a następnie wykorzystać te informacje do analizy efektywności pracy działu księgowości i śledzenia kosztów prowadzenia rachunkowości.
I ostatnia rzecz, którą zapamiętałem z jego słów – programiści mają dostęp do dużej ilości informacji, ponieważ mają uprawnienia administracyjne do systemu. Dlatego mogą korzystać z tych informacji w swojej analizie. Nikt inny w zwykłej fabryce nie dysponuje takim zasobem.
A potem odszedł. Podczas przymusowych dwóch tygodni wypowiedzenia zmusiliśmy go, aby podzielił się swoim doświadczeniem, ponieważ chcieliśmy kontynuować jego pracę. No i jego stanowisko stawało się wakujące.
Przez kilka dni sadziliśmy go na krześle, włączaliśmy kamerę i nagrywaliśmy jego monologi. Proszono go o opowiedzenie o wszystkich zrealizowanych projektach, metodach, podejściu, sukcesach i niepowodzeniach, przyczynach i skutkach, portretach liderów itd. Nie stawialiśmy żadnych szczególnych ograniczeń, ponieważ nie wiedzieliśmy, co się dzieje w jego głowie.
W monologach oczywiście dominowała cała liturgia i śmieszność – był w świetnym nastroju, bo uciekał z zapadłej wsi do Petersburga. A dokąd jechać pracować w Petersburgu? Do Gazpromu, oczywiście.
Ale udało nam się wyciągnąć z jego monologów coś użytecznego. Opowiem, co pamiętam.
Oto zalecenia tego faceta. Dla tych, którzy chcą spróbować uporządkować procesy biznesowe.
Aby zajmować się taką pracą, przede wszystkim trzeba mieć określony poziom „zdradzenia własnych interesów”. Nie można bać się utraty pracy, ryzykować, nie bać się konfliktów z kolegami. Jemu to przychodziło łatwo, ponieważ rozpoczął swoją drogę, kiedy pracował w firmie tylko pół roku i nie zdążył nawiązać kontaktów z nikim, a zresztą nie zamierzał tego robić. Rozumiał, że ludzie przychodzą i odchodzą, a dla niego ważne były tylko jego własne wyniki i ich ocena przez właściciela firmy. Jak go postrzegali koledzy – dobrze czy źle – niewiele go wtedy obchodziło.
Druga kwestia to to, że aby skutecznie zająć się tą pracą, niestety trzeba się uczyć. Ale uczyć się nie na MBA, nie na kursach, nie w instytutach, a samodzielnie. Na przykład, w swoim pierwszym projekcie związanym z magazynem, działał intuicyjnie, nie wiedząc nic, poza tym, co to jest „zarządzanie jakością”.
Kiedy zaczął czytać literaturę na temat metod zwiększania efektywności, odkrył technologie, które stosował. Chłopak intuicyjnie je stosował, a okazuje się, że to nie jego wymysł, wszystko było już dawno napisane. Przeznaczył czas i znacznie więcej, niż gdyby od razu przeczytał odpowiednią książkę. Ważne jest, aby zrozumieć, że studiując konkretną metodologię, żadna z nich, nawet ta najdoskonalsza, nie rozwiąże wszystkich problemów procesu biznesowego.
Druga sprawa to, że im więcej metod 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 przeciwnikami. Jeśli ktoś był silniejszy, jego podróż na jakiś czas się kończyła, a Musashi stawał się uczniem. W rezultacie, przez kilka lat zdobywał umiejętności różnych praktyk różnych mistrzów i stworzył swoją własną szkołę, dodając coś od siebie. W końcu osiągnął unikalną maestrię. Tutaj jest to samo.
Można oczywiście działać jak konsultanci biznesowi. W ogóle, to świetni ludzie. Ale zazwyczaj przychodzą, aby wdrożyć jakąś metodologię, i wprowadzają nie tę metodologię, która jest potrzebna biznesowi. My też mieliśmy takie smutne sytuacje: nikt nie wie, jak rozwiązać problem i nikt nie chce myśleć, jak to zrobić. Zaczynamy szukać w internecie lub wzywamy konsultanta, pytając go, co może nam pomóc. Konsultant myśli i mówi, że trzeba wdrożyć teorię ograniczeń. Płacimy mu za rekomendację, inwestujemy w wdrożenie, ale rezultatu zero.
Dlaczego tak się dzieje? Ponieważ konsultant powiedział, wdrażamy taką a taką system, i wszyscy się z tym zgodzili. Doskonale, ale jedna metoda nie rozwiązują wszystkich problemów nawet jednego procesu biznesowego, szczególnie jeśli nie zgadzają się początkowe założenia — nasze i te, które wymagane do wdrożenia metodologii.
W praktyce, którą poleca ten chłopak, należy wybierać to, co najlepsze i wdrażać to. Nie należy przyjmować metod w całości, a jedynie ich kluczowe cechy, smaczki, praktyki. I co najważniejsze – trzeba zrozumieć istotę.
Weźmy, mówił, na przykład scrum lub agile. W swoich monologach chłopak wielokrotnie powtarzał, że nie wszyscy do końca rozumieją istotę scruma. On też przeczytał książkę Jeffa Sutherland'a, która niektórym wydaje się "łatwą lekturą". Dla niego była to głęboka lektura, ponieważ jedną z podstawowych idei scruma jest zarządzanie jakością, o czym w książce jest napisane wprost.
Pisano tam o Toyota Production, o tym, jak Jeff Sutherland pokazywał scrum w Japonii, jak się tam przyjął i jak bliski był ich filozofii. I Sutherland opowiadał o ważności roli scrum mastera, o cyklu Deminga. Rola scrum mastera polega na ciągłym przyspieszaniu procesu. Wszystko inne, co jest w scrums, – dostarczanie etapowe, zadowolenie klienta, jasny wykaz prac na okres sprintu – także jest ważne, ale wszystko to powinno rozwijać się coraz szybciej. Tempo pracy powinno cały czas wzrastać w tych jednostkach, w których jest mierzone.
Może chodzi o tłumaczenie, ponieważ u nas książkę przetłumaczono jako „Scrum – rewolucyjna metoda zarządzania projektami”, a jeśli tłumaczyć dosłownie angielski tytuł, to wyszłoby: „Scrum – dwa razy więcej w połowie krótszym czasie”, co oznacza, że nawet w nazwie odniesienie do tempa jako kluczowej funkcji scruma jest obecne.
Kiedy ten chłopak wdrażał scruma, w pierwszym miesiącu tempo wzrosło dwukrotnie bez jakichkolwiek szczególnych zmian. Znalazł punkty do zmian, dostosował sam scrum do siebie, aby działał o wiele szybciej. Jedyna rzecz, jak piszą w internecie, – stanęło przed nimi pytanie: „Zwiększyliśmy tempo dwa razy, zostaje zrozumieć, co robić z taką prędkością?”. Jednak to już zupełnie inny temat...
Osobiście polecał też kilka metod. Nazwał je fundamentalnymi i zasadniczymi.
Pierwsza – boundary management (zarządzanie granicami).
Uczy się tego w „Skolkowo”, innych książek i materiałów, według zapewnień chłopaka, nie ma. Miał kiedyś szczęście uczestniczyć w wykładzie profesora z Harvardu, który głosi zarządzanie granicami oraz przeczytać kilka artykułów w Harvard Business Review o pracach Erica Trista.
Zarządzanie granicami mówi o tym, że trzeba umieć dostrzegać granice i pracować z nimi. Granic jest mnóstwo, są wszędzie — między działami, różnymi rodzajami pracy, funkcjami, między pracą operacyjną a analityczną. Wiedza o zarządzaniu granicami nie odkrywa jakichś wyższych prawd, ale pozwala dostrzegać rzeczywistość w nieco innym świetle — przez pryzmat granic. A tym samym nimi zarządzać — wyznaczać tam, gdzie to konieczne, i usuwać tam, gdzie przeszkadzają.
Ale najwięcej i najczęściej chłopak mówił o controllingu. Miał na ten temat jakąś obsesję.
Controlling, mówiąc krótko — to zarządzanie oparte na liczbach. Tutaj, mówił, ważna jest każda część definicji — zarówno „zarządzanie”, jak i „na podstawie”, i „liczb”.
U nas, mówił, źle jest ze wszystkimi trzema składnikami controllingu. Szczególnie biorąc pod uwagę, że są one ściśle ze sobą powiązane, jak i z innymi częściami systemu biznesowego.
Pierwsze, co jest złe — to liczby. Jest ich mało i są niskiej jakości.
Znaczną część liczb wtedy braliśmy z systemu informacyjnego 1C. Otóż, jakość liczb w 1C, jak stwierdził, jest nikła. Przynajmniej z powodu możliwości zmieniania danych wstecz.
Oczywiście, że to nie jest wina twórców 1C — oni jedynie uwzględniają wymagania rynku i mentalności krajowego rachunkowości. Ale dla celów controllingu zasady pracy 1C z danymi najlepiej byłoby zmienić w konkretnej firmie.
Następnie liczby z 1C, według jego słów, przechodzą półręczną obróbkę, na przykład z użyciem Excela. Taka obróbka również nie dodaje jakości danym ani ich pilności.
W końcu, ostateczny raport jeszcze ktoś sprawdza, aby przypadkiem nie podać kierownikowi liczb z błędami. W rezultacie, liczby trafiają do adresata piękne, sprawdzone, ale bardzo późno. Zazwyczaj — po zakończeniu okresu (miesiąca, tygodnia itd.).
I tutaj, mówił, wszystko jest bardzo proste. Jeśli liczby za styczeń dotarły do Was w lutym, to nie możecie już zarządzać działalnością stycznia. Ponieważ styczeń już się zakończył.
A jeśli cyfry bazują na rachunkowości, a firma jest zwykła, z kwartalnym rozliczaniem VAT, to kierownik otrzymuje stosunkowo sensowne dane raz na kwartał.
Dalej to jasne. Otrzymujecie dane raz w miesiącu — macie możliwość zarządzania na podstawie danych (czyli dokonywania controllingu) 12 razy w roku. Praktykujecie kwartalne sprawozdania — zarządzacie 4 razy w roku. Plus bonus — roczne sprawozdania. Jeszcze raz kontrolować.
W pozostałym czasie zarządzanie zazwyczaj odbywa się w ciemno.
Kiedy (i jeśli) dane w końcu się pojawiają, wchodzi w grę drugi problem — jak zarządzać na podstawie danych? Z tym punktem jego rozważań się nie zgodziłem.
Facet twierdził, że jeśli wcześniej nie było danych, to ich pojawienie się wywoła efekt wow. Będzie patrzył i manipulował danymi w tę i we w tę, zwoływał ludzi na dywanik, żądał wyjaśnień i dochodzeń. Po zabawieniu się danymi, przeprowadzeniu analiz, groźnym obiecaniu wszystkim pracownikom, że „teraz to już was nie spuszczę z oka”, kierownik bardzo szybko się uspokoi i porzuci to zajęcie. Przestanie z tego narzędzia korzystać. A problemy pozostaną na miejscu.
Dzieje się tak, mówił, z powodu niedostatecznych kompetencji kierownika. W controllingu, przede wszystkim. Kierownik po prostu nie wie, co zrobić z tymi danymi. Co zrobić — wie, co zrobić — nie. Zrobić — to to, o czym mowa powyżej (zdenerwować się, pobawić się). Robić — to codzienny proces biznesowy.
Twierdził, że wszystko jest bardzo proste: liczba powinna stać się częścią procesu biznesowego. W procesie biznesowym powinno być jasno określone: kto, co i kiedy powinien robić w przypadku odchyleń liczby od normy (wszelkie warianty — powyżej granicy, poniżej granicy, wyjście poza korytarz, obecność trendu, niedotrzymanie kwantyla itp.)
I oto określił kluczową dylemat: liczba jest, powinna stać się częścią systemu biznesowego, aby zwiększyć efektywność zarządzania, ale… to się nie dzieje. Dlaczego?
Ponieważ rosyjski kierownik nie odda konkurentowi kawałka swojej władzy.
Konkurenci rosyjskiego kierownika — jakość i działający proces biznesowy, przemyślana wzajemnie korzystna motywacja i właściwa automatyzacja — niestety, pozostawią kierownika bez pracy.
To głupota, zgódzicie się? Szczególnie jeśli chodzi o kierowników. Dobrze, opowiedziałem, teraz sami decydujcie.
Nieco mniej, ale wciąż za dużo, moim zdaniem, mówił o Scrumie.
Zdecydowanie, mówił, przeczytajcie i wypróbujcie Scrum w praktyce. Jeśli, mówi, czytaliście, ale nie próbowałeś — uznajcie, że nie wiecie. Lepiej przeczytać książkę, na przykład Sutherland'a, a nie artykuły czy różne przewodniki (co to za bzdura?) w internecie.
Scrum, mówił, poznaje się tylko w praktyce, z obowiązkowymi pomiarami ilości wykonanej pracy. Osobiście spróbujcie dwóch najważniejszych ról — właściciela produktu i Scrum Mastera.
Szczególnie ważne, według tego gościa, jest poczuć w praktyce rolę Scrum Mastera, kiedy możesz zwiększyć liczbę zadań zamykanych w sprincie, nie zwiększając zasobów ani kosztów sprintu.
I jeszcze w jego topie była TOC (teoria ograniczeń systemów).
To, mówił chłopak, podstawowe, fundamentalne zasady zwiększania efektywności, które można zastosować praktycznie w każdej dziedzinie, w każdym procesie biznesowym i systemie biznesowym jako całości.
Kiedy dowiedział się, że nie jesteśmy zaznajomieni z TOC, przestał opowiadać. Tylko dodał, że nie odbierze nam przyjemności z czytania książek Eliyahu Goldratta. Dał analogiczne zalecenie jak do Scrumu — przeczytaj i wypróbuj. Mówi, że niezależnie od tego, na jakim stanowisku jesteś i jaką pracę wykonujesz, znajdzie się miejsce na zwiększenie efektywności metodami TOC.
Potem, wydaje się, jego zasób metod się wyczerpał i powiedział: miksujcie zasady, aby stworzyć aplikacyjne rozwiązania w konkretnej sytuacji.
To, mówi, główna rekomendacja, klucz do sukcesu. Zrozumcie zasady, istotę i twórzcie unikalne aplikacyjne rozwiązania — procesy biznesowe i systemy biznesowe.
Potem próbował sobie przypomnieć jakąś cytatę, w końcu musiał zajrzeć do internetu. Okazało się, że cytat pochodzi z artykułu „Stojąc na ramionach gigantów” Eliyahu Goldratta:
„Istnieje różnica między rozwiązaniami aplikacyjnymi a fundamentalnymi koncepcjami, na których te rozwiązania się opierają. Koncepcje są ogólne, podczas gdy rozwiązania aplikacyjne to adaptacja koncepcji do konkretnego środowiska. Jak już widzieliśmy, taka adaptacja nie jest prosta i wymaga opracowania określonych elementów rozwiązania. Musimy pamiętać, że rozwiązanie aplikacyjne opiera się na założeniach (czasami ukrytych) o konkretnym środowisku. Nie należy oczekiwać, że to rozwiązanie aplikacyjne zadziała w środowisku, dla którego pierwotne założenia nie są trafne.
Powiedział, że praca programisty i 'ulepszacza procesów biznesowych' są bardzo podobne. I odszedł.
Źródło: habr.com
