Історія реальна, я все бачив на власні очі.
Кілька років один хлопець, як і багато хто з вас, працював програмістом. Про всяк випадок напишу так: «програмістом». Тому що він був 1Сніком, на фіксі, виробничої компанії.
До цього він пробував різні спеціальності – 4 роки у франчі програмістом, керівником проектів, умів закривати по 200 годин, одночасно отримуючи відсоток із проекту, за керівництво та трохи займаючись продажами. Пробував самостійно розробляти продукти, був начальником IT-відділу у великій компанії, чисельністю 6 тисяч осіб, приміряв різні варіанти застосування своєї професій лапки – програміста 1С.
Але все це позиції були дещо тупикові, насамперед із доходу. Всі ми тоді отримували приблизно ті самі гроші, працювали в тих самих умовах.
Цьому хлопцеві стало цікаво, як можна заробляти більше грошей, не займаючись продажем та не створюючи свій власний бізнес.
Він уявив себе розумником, і вирішив знайти нішу в тій компанії, де працював. Ніша ця мала бути якоюсь особливою, ніким не зайнятою. І хотілося, щоб компанія сама захотіла платити гроші людині в цій ніші, щоб не треба було нікого дурити чи щось накручувати. Щоби це було об'єктивно: людині на цій позиції треба платити багато грошей. Дивак, одним словом.
Пошуки були недовгими. У компанії, де цей хлопець працював, була вільна ніша, яку можна умовно назвати «наведення порядку в бізнес-процесах». У кожній компанії є безліч проблем. Завжди щось не працює, і немає людини, яка прийде та виправить бізнес-процес. Так ось, він вирішив спробувати себе у ролі фахівця, який може допомогти власнику вирішити його проблеми у бізнес-процесах.
На той момент він працював у компанії півроку і отримував середню зарплату по ринку. Втрачати було нічого — тим більше, що таку ж роботу він міг знайти протягом одного тижня. Загалом, цей хлопець розсудив, що нічого страшного не станеться, якщо раптом ні дуля не вийде і його звільнять.
Він набрався сміливості та прийшов до власника. Запропонував йому покращити найпроблемніший процес, який був у бізнесі. На той момент це був складський облік. Зараз усім, хто працює в цій компанії, навіть соромно згадувати про ті проблеми, але інвентаризації, які проводилися щокварталу, показували розбіжності між обліковою системою та фактичними рештками у десятки відсотків. І за ціною, і за кількістю, і за кількістю позицій. То була біда. Компанія реально мала правильні залишки в обліковій системі лише чотири рази на рік – наступного дня після інвентаризації. Цей процес наш хлопець і став упорядковувати.
Хлопець домовився із власником, що має знизити відхилення за результатами інвентаризації вдвічі. Причому, власнику втрачати особливо було нічого, тому що до нашого героя спроби все виправити вже робили різні працівники, і в цілому завдання вважалося практично не вирішуваним. Все це сильно підігрівало інтерес, тому що якщо все вийде, то чувак автоматично ставав би людиною, яка вміє наводити лад і вирішувати завдання, що не вирішуються.
Отже, перед ним стояло завдання: протягом року знизити відхилення за результатами інвентаризації у 2 рази. У момент початку проекту він не уявляв, як цього досягти, але розумів, що складський облік – це річ проста, тому все одно вдасться щось корисне зробити. Тим більше, що знизити відхилення з десятків відсотків до одного десятка відсотків – це не так складно. Усі, хто працював у сфері консультування чи подібної діяльності, розуміють, що більшість проблем процесу усуваються досить простими діями.
З січня до травня він готувався, трохи чогось автоматизував, переписав бізнес-процес складського обліку, змінив потоки роботи комірників, бухгалтерів і взагалі всю систему переробив, нікому нічого не показуючи і не розповідаючи. У травні він роздав усім нові інструкції, і після першої року інвентаризації почалося нове життя – робота за його правилами. Щоб спостерігати результат, надалі компанія почала проводити інвентаризації частіше – раз на два місяці. Вже перші результати були позитивними, а до кінця року відхилення за результатами ревізії впали до одного відсотка.
Успіх був колосальний, але його стійкість не вірилося. Сам хлопець сумнівався, що результат збережеться, якщо відійти убік та перестати спостерігати за процесом. Проте результат був, і хлопець отримав усе, про що домовлявся із власником. Потім, через кілька років, стійкість результату підтвердилася - кілька років відхилення тримаються в межах 1%.
Тоді він вирішив повторити експеримент та запропонував власнику вдосконалити інший проблемний процес – постачання. Там були дефіцити, які не дозволяли відвантажувати такі обсяги, які хотіли наші клієнти. Домовилися, що за рік дефіцити знизяться вдвічі, а чувак виконає ще 10-15 проектів, пов'язаних з 1С, — з автоматизації різних бізнес-процесів та іншої брехні.
У другий рік знову все успішно вдалося завершити, дефіцити знизилися більш ніж у 2 рази, всі ІТ-проекти були завершені успішно.
Оскільки зарплата вже повністю задовольняла всі запити того хлопця, року на два вперед, він вирішив трохи розсудливим, заспокоїтися і посидіти на затишному теплому місці, яке сам собі й створив.
Що воно собою являло? Формально він був IT-директором. Але ким він був насправді, зрозуміти важко. Адже чим займається IT-директор? Як правило, він адмініструє IT-інфраструктуру, керує системними адмінами, впроваджує ERP-систему, бере участь у нарадах на раді директорів.
А у цього чувака одним із ключових обов'язків була участь у процесах змін, і в основному — генерація, ініціювання цих процесів, пошук та пропозиція рішень, застосування нових методик управління, експертиза запропонованих змін, аналіз ефективності інших функцій та підрозділів, і, нарешті, безпосереднє участь у стратегічному розвитку підприємства, аж до самостійної розробки стратегічного плану компанії.
Йому дали карт-бланш. Він міг приходити на будь-яку нараду, куди раніше не мав доступу. Сидів там із блокнотом, чогось записував, чи просто слухав. Говорив рідко. Потім почав грати в телефоні — стверджував, що так краще працювати асоціативна пам'ять.
На нараді рідко щось корисне видавав. Ішов, думав, потім прилітав лист — чи то з критикою, чи то з думкою, чи з пропозиціями, чи з описом рішень, які він уже застосував.
Але найчастіше збирав наради сам. Знаходив проблему, вигадував варіанти рішення, визначав зацікавлених осіб та тягнув усіх у переговорку. А там уже як умів. Переконував, мотивував, доводив, сперечався, домагався.
Неофіційно він вважався третьою особою в компанії, після власника та директора. Зрозуміло, він страшенно бісив усіх «облич компанії», починаючи з номера 4. Особливо своїми рваними джинсами та яскравими футболками, а ще часом власника.
Власник приділяв йому 1 годину на день. Кожен день. Вони розмовляли, обговорювали проблеми, рішення, нові бізнеси, напрями розвитку, показники та ефективність, особистий розвиток, книги, та й просто життя.
Але цей хлопець був дивний. Начебто сиди і радуйся, життя вдалося. Але немає. Він вирішив порефлексувати.
Йому стало цікаво: чому в нього вийшло, а в інших — ні? Власник теж підштовхував його: казав, що хоче, щоб у інших теж виходило наводити лад, тому що менеджерів багато, вони зазвичай займаються оперативним управлінням і стратегічним плануванням, але практично ніхто не займається системними змінами своїх процесів. До їхньої посадової інструкції, може, й записано, що вони мають прискорювати свій процес, підвищувати його ефективність, але за фактом цим ніхто не займається. Чому так? Ось хлопцеві теж стало цікаво чому, і він пішов з усіма цими менеджерами розмовляти.
Він прийшов до заступника директора з якості, і запропонував впровадити контрольні карти Шухарта, щоб у продукція було краще за японську. Але виявилося, що колега не знає, що таке контрольні карти Шухарта, що таке статистичне управління процесами, і лише краєм вуха чув про застосування циклу Демінга в управлінні якістю. Гаразд…
Пішов він до іншого заступника директора і запропонував запровадити контролінг. Але й тут не знайшов підтримки. Ще трохи пізніше він дізнався про баундрі менеджмент (boundary management, управління кордонами) та всім заступникам директора запропонував впровадити системну частину цієї методики, щоб покращити процеси. Але скільки наш хлопець не розмовляв, ніхто особливо не хотів вникати, про що йдеться. Може, їм було нецікаво чи надто складно. Але за фактом ніхто не розібрався.
Загалом він розповів про все, що знав і застосовував у компанії. Але ніхто так і не зрозумів. Їм і досі незрозуміло, чому, наприклад, усе вдалося виправити у складському обліку, причому тут контролінг та керування кордонами.
В останню чергу він дійшов до своїх програмістів – до штату входило 3 особи. Розповів про управління кордонами, про контролінг, про менеджмент якості, про agile та scrum… І на диво вони всі зрозуміли, і навіть могли з ним якось обговорити, зокрема технічні та методичні тонкощі. Вони зрозуміли, чому проекти за складом та постачанням вийшли. І тут хлопця осяяло: насправді світ врятують програмісти.
Програмісти, зрозумів він – єдині, хто зможе нормально, з потрібною детальністю розібратися в бізнес-процесах.
Чому саме вони? Насправді однозначної відповіді він не знайшов. Сформулював лише тезові натяки.
По-перше, програмісти знають предметні галузі бізнесу, причому, знають їх краще за всіх інших людей у компанії.
З іншого боку, програмісти реально розуміють, що таке алгоритм процесу. Це важливо тому, що бізнес-процеси – це алгоритми і елементи в них можуть бути банально не узгоджені. Наприклад, у процесі постачання, над яким хлопець працював, перший крок – це складання річного плану закупівель, а другий – щоденна закупівля. Ці кроки з'єднані прямим зв'язком, тобто передбачається, що за цим алгоритмом люди повинні працювати – складати річний план закупівель і виконувати заявку. Річний план закупівель складається щорічно, а заявка надходить по 50 разів на день. У цьому алгоритм закінчується, і у ньому треба працювати. Насправді, розсудив він, для програмістів знання алгоритмів – це конкурентна перевага, тому що будь-яка інша людина, яка не знайома з ними, просто не розуміє, як бізнес-процес має працювати, і як це можна зобразити.
Ще один плюс програмістів, за словами того хлопця – досить вільного часу. Ми всі розуміємо, як програміст може витрачати завдання втричі довше часу, ніж насправді вона вимагає, і мало хто це помітить. Це, знову ж таки, конкурентна перевага, бо для того, щоб упорядковувати якийсь бізнес процес, потрібно мати багато вільного часу — думати, спостерігати, вивчати і пробувати.
Більшість менеджерів, за словами хлопця, цього вільного часу не мають і пишаються цим. Хоча фактично це означає, що людина не може стати ефективною, бо не має часу на підвищення ефективності — замкнене коло. У нашій культурі модно бути зайнятим, тож усе залишається на місці. А для нас, програмістів, це перевага. Ми можемо знайти вільний час і все подумати.
Програмісти, розповідав він, можуть швидко змінити інформаційну систему. Це не на всіх підприємствах застосовно, але скрізь, де він працював, можна було вносити будь-які доробки, які заманеться. Особливо якщо вони не стосуються нічиєї роботи. Наприклад, він міг запустити систему, яка таємно вимірюватиме дії користувачів, і використовуватиме цю інформацію — для аналізу ефективності роботи тієї ж бухгалтерії та відстеження вартості ведення обліку.
І останнє, що запам'ятав з його слів – програмісти мають доступом до великої кількості інформації, т.к. наділені адміністративним доступом до системи. Тому можуть скористатися цією інформацією у своєму аналізі. Ніхто інший на звичайному заводі такого ресурсу не має.
А потім він пішов. Під час належного двотижневого відпрацювання ми змусили його поділитися досвідом, тому що хотіли продовжувати справу, якою він займався. Та й посада його ставала вакантною.
Протягом кількох днів сідали на стілець, включали камеру та записували його монологи. Просили розповісти про всі виконані проекти, методи, підходи, успіхи та невдачі, причини та наслідки, портрети керівників тощо. Особливо обмежували, т.к. не знали, що в його голові робиться.
У монологах, звичайно, в основному була всяка нісенітниця і жита - він перебував у прекрасному настрої, т.к. відбував із глушині до Пітера. А куди їхати працювати у Пітері? У Газпром, звісно.
Але щось корисне нам вдалося витягти з його монологів. Розповім, що пам'ятаю.
Отже, поради того хлопця. Тим, хто захоче спробувати зайнятися наведенням ладу в бізнес-процесах.
Щоб займатися такою роботою, по-перше потрібно мати певний рівень «відмороженості». Потрібно не боятися втратити роботу, не боятися ризикнути, не боятися конфліктів із колегами. У нього це виходило легко, бо почав він свій шлях, коли пропрацював у компанії лише півроку, і не встиг ні з ким вступити в контакт, та й не збирався це робити. Він розумів, що люди приходять і йдуть, а для нього важливі його власні результати та їхня оцінка власником бізнесу. Погано чи добре ставляться до нього колеги — його це мало тоді хвилювало.
Другий момент – щоб ефективно займатися цією роботою, на жаль, доведеться вчитися. Але вчитися не на MBA, не на курсах, не в інститутах, а самостійно. Наприклад, у першому своєму проекті, за складом, він діяв інтуїтивно, нічого не знав, щойно таке «управління якістю».
Коли він почав читати літературу, які методи підвищення ефективності існують, то виявив технології, які застосовував. Хлопець інтуїтивно їх застосовував, а виявляється, це не його вигадка, все вже давно було написано. Але він витратив час, і набагато більше, ніж якби одразу прочитав потрібну книгу. Тут тільки важливо розуміти, що коли вивчаєш конкретну методику, жодна з них, навіть найпросунутіша, повністю не вирішить усі проблеми бізнес-процесу.
Друга фішка в тому, що чим більше методик ви знаєте, тим краще. Наприклад, у стародавній Японії жив Міямото Мусасі – один із найвідоміших фехтувальників, автор стилю двох мечів. Він навчався в якійсь школі в якогось майстра, потім мандрував Японією, бився з різними чуваками. Якщо чувак був сильнішим, то подорож на якийсь час припинялася, і Мусасі йшов до учнів. В результаті він за кілька років набував навичок різних практик різних майстрів і сформував свою власну школу, додаючи щось своє. У результаті вийшла унікальна майстерність. Тут те саме.
Можна, звісно, діяти як бізнес-консультанти. Взагалі, вони чудові хлопці. Але, як правило, приходять, щоб запровадити якусь методику, та впроваджують не ту методику, яка потрібна бізнесу. Ми також мали такі сумні ситуації: ніхто не знає, як вирішити проблему і ніхто не хоче думати, як її вирішити. Починаємо шукати або в інтернеті, або звати консультанта, і питаємо у нього, що нам може допомогти. Консультант думає і каже, що треба теорію обмежень запровадити. Платимо йому за рекомендацію, витрачаємось на використання, але результату нуль.
Чому так виходить? Тому що консультант сказав, чи впроваджуємо таку систему, і всі погодилися з ним. Прекрасно, але одна методика не закриває всіх проблем навіть одного бізнес-процесу, особливо якщо не збігаються вихідні передумови — наші й ті, що потрібні для впровадження методики.
У практиці, яку хлопець рекомендує, треба брати найкраще та впроваджувати найкраще. Чи не брати методи повністю, а брати їх ключові особливості, фішки, практики. І найважливіше – треба розуміти суть.
Візьмемо, говорив він, наприклад, скрам (scrum) чи еджайл. У монологах хлопець багато разів повторив, що не всі до кінця розуміють суть скраму. Він також читав книгу Джефа Сазерленда, яка деяким здається «легким чтивом». Йому вона здалася глибоким чтивом, тому що одна з основних основ скраму - це управління якістю, про це в книзі написано прямо.
Там написано про Toyota Production, про те, як Джефф Сазерленд показував скрам у Японії, наскільки він там прижився і був близький до їхньої філософії. І Сазерленд розповідав про важливість ролі скрам-майстра, про цикл Демінга. Роль скрам-майстра – це постійне прискорення процесу. Все інше, що є в скрамі, – поетапне здавання, задоволення замовника, чіткий перелік робіт на період спринту – теж важливо, але це все має рухатися все швидше та швидше. Швидкість роботи має постійно зростати у тих одиницях, у яких вона вимірюється.
Можливо, тут справа в перекладі, тому що у нас книгу переклали як «Скрам – революційний метод управління проектами», а якщо дослівно англійську назву перекладати, то вийде: «Скрам – удвічі більше за вдвічі менший термін», тобто навіть у Назвою йде відсилання до швидкості, як ключової функції скраму.
Коли цей хлопець впроваджував скрам, за перший місяць швидкість збільшилася вдвічі без особливих змін. Він знайшов крапки для змін, модифікував сам скрам під себе, щоб він працював набагато швидше. Єдине, як в інтернеті пишуть, — перед ними постало питання: «Ми збільшили швидкість удвічі, залишилося зрозуміти, що ми робимо з такою швидкістю?». Втім, це вже зовсім інша область.
Ще він особисто рекомендував кілька методик. Назвав їх фундаментальними та основоположними.
Перша – boundary management (управління кордонами).
Викладають його у «Сколковому», інших книг та матеріалів, за твердженнями хлопця, немає. Йому якось пощастило бути присутнім на лекції професора з Гарварда, який проповідує boundary management, а також прочитати кілька статей у Harvard Business Review про роботи Еріка Тріста.
Boundary management говорить про те, що треба вміти бачити кордони та працювати з кордонами. Кордонів повно, вони всюди — між відділами, між різними видами робіт, між функціями, між оперативною та аналітичною роботою. Знання boundary management не відкриває якихось вищих істин, але дозволяє бачити реальність дещо в іншому світлі — через призму кордонів. І, відповідно, керувати ними — зводити там, де це необхідно, та прибирати там, де вони заважають.
Але найчастіше хлопець говорив про контролінг. Прям бзик якийсь у нього був на цю тему.
Контролінг, якщо коротко – це керування на основі цифр. Тут, казав він, важлива кожна частина визначення - і "управління", і "на основі", і "цифр".
У нас, казав він, погано з усіма трьома складовими контролінгу. Особливо, якщо врахувати, що вони тісно взаємопов'язані як один з одним, так і з іншими частинами бізнес-системи.
Перше, що погано – цифри. Їх мало, і вони низької якості.
Значну частину цифр ми тоді брали із інформаційної системи 1С. Так ось, якість цифр у 1С, як він стверджував, нікуди не годиться. Як мінімум, через можливість змінювати дані заднім числом.
Зрозуміло, що вини розробників 1С цього немає — вони лише враховують вимоги ринку та менталітету вітчизняного обліку. Але для цілей контролінгу принципи роботи 1С з даними краще змінити на конкретному підприємстві.
Далі цифри з 1С, за його словами, проходять напівручну обробку з використанням Excel, наприклад. Якості даним, так само як і оперативності, така обробка теж не додає.
Зрештою, підсумковий звіт ще хтось перевіряє ще раз, щоб випадково не подати керівнику цифри з помилками. У підсумку цифри потрапляють до адресата красивими, перевіреними, але дуже пізно. Зазвичай - після закінчення періоду (місяця, тижня, і т.д.).
І тут, казав він, дуже просто. Якщо цифри про січень вам потрапили у лютому, то діяльністю січня ви вже керувати не можете. Бо січень уже скінчився.
А якщо цифри засновані на бух.обліку, і компанія — звичайнісінька з поквартальною здаванням ПДВ, то відносно адекватні цифри її керівник отримує раз на квартал.
Далі зрозуміло. Отримуєте цифри раз на місяць - у вас є можливість керувати цифрами (тобто здійснювати контролінг) 12 разів на рік. Практикуєте квартальну звітність - керуєте 4 рази на рік. Плюс бонус – річна звітність. Ще раз покерувати.
Решта часу управління, як правило, виконується наосліп.
Коли (і якщо) цифри таки з'являються, то набирає чинності друга проблема — як керувати на основі цифр? Ось із цим пунктом його міркувань я так і не зміг погодитися.
Хлопець стверджував, що якщо цифр у керівника раніше не було, їх поява викличе вау-ефект. Він дивитиметься і крутитиме цифри і так і так, викликатиме людей на килим, вимагатиме пояснень і розслідувань. Погравшись з цифрами, провівши розбори, грізно пообіцявши всім співробітникам, що «тепер я з вас не злізу», керівник дуже швидко заспокоїться і кине цю справу. Інструментом користуватись перестане. А проблеми залишаться на місці.
Так відбувається, казав він, через недостатні компетенції керівника. У контролінгу насамперед. Керівник просто не знає, що робити із цими цифрами. Що сробити – знає, що робити – ні. Зробити це те, про що написано вище ( посваритися, погратися). Робити це щоденний бізнес-процес.
Він стверджував, що все дуже просто: цифра має стати частиною бізнес-процесу. У бізнес-процесі має бути чітко зрозуміло: хто, що, і коли повинен робити при відхиленні цифри від норми (будь-які варіанти — вище за кордон, нижче за кордон, вихід за коридор, наявність тренду, невиконання квантилю і т.д.)
І ось він окреслив ключову дилему: цифра є, вона має стати частиною бізнес-системи, щоб підвищити ефективність управління, але цього не відбувається. Чому?
Тому що російський керівник не віддасть конкурентові шматок своєї влади.
Конкуренти російського керівника — якісний та працюючий бізнес-процес, продумана взаємовигідна мотивація та правильна автоматизація — на жаль, залишать керівника без роботи.
Нісенітниця якась, погодьтеся? Особливо для керівників. Гаразд, я розповів, ви самі вирішуйте.
Трохи менше, але все одно надто багато, на мій погляд, він говорив про скрам.
Обов'язково, говорив, прочитайте та спробуйте на практиці скрам. Якщо, каже, читали, але не куштували — вважайте, що не знаєте. Читати краще книгу, наприклад Сазерленда, а не статті та всякі там гайди (що за хрень?) в Інтернеті.
Скрам, казав він, пізнається лише практикою, і з обов'язковими вимірами обсягів виконаної роботи. Особисто спробуйте дві найважливіші ролі – власника продукту та скрам-майстра.
Особливо важливо, за словами хлопця, відчути на практиці роль скрам-майстра, коли ви зможете збільшити обсяг завдань, що закриваються за спринт, не збільшуючи ресурси і вартість спринту.
Та ще в його топі був ТОС (теорія обмежень систем).
Це, за словами хлопця, базові, фундаментальні принципи підвищення ефективності, які можна застосувати практично у будь-якій галузі, у будь-якому бізнес-процесі та бізнес-системі загалом.
Коли він дізнався, що ми не знайомі з ТГС, то перестав розповідати. Лише додав, що не позбавлятиме нас задоволення від прочитання книг Еліяху Голдратта. Рекомендацію дав аналогічну скраму - прочитайте і спробуйте. Типу, на якій посаді ви не знаходилися б, яку б роботу не виконували, там знайдеться місце для підвищення ефективності методами ТГС.
Потім у нього багаж методик, мабуть, вичерпався, і він сказав: міксуйте принципи для створення прикладних рішень у конкретній ситуації.
Це, каже, головна рекомендація, ключ до успіху. Зрозумійте принципи, суть і створюйте унікальні прикладні рішення — бізнес-процеси та бізнес-системи.
Потім він намагався згадати якусь цитату, зрештою довелося лізти в інтернет. Виявилося, цитата зі статті «Стоячи на плечах гігантів» Еліяху Голдратта:
«Є різниця між прикладними рішеннями (застосуваннями) та фундаментальними концепціями, на яких ґрунтуються ці рішення. Концепції є загальними, прикладні рішення - це адаптація концепцій до конкретного середовища. Як ми вже бачили, подібна адаптація не є простою і унеможливлює розробку певних елементів рішення. Ми повинні пам'ятати — прикладне рішення ґрунтується на вихідних посилках (іноді прихованих) про конкретне середовище. Не слід очікувати, що це прикладне рішення працюватиме в середовищі, для якого вихідні посилки не вірні».
Сказав, що робота програміста та «покращувача бізнес-процесів» дуже схожі. І пішов.
Джерело: habr.com