80 за 20 — як не треба оптимізувати процеси

Я написав цей пост почасти в спробі виправдати перфекціонізм, який інколи впадаю, і почасти – щоб пояснити колегам, про що я думаю, коли працюю над черговим проектом.

Почалося все з простого зауваження: дві компанії, які працюють на одному ринку і мають однакову чисельність персоналу, можуть мати обороти і прибуток, що відрізняються на порядок. Чому так відбувається, якщо, по суті своїй, вони роблять одну і ту ж роботу? Іноді основна відмінність полягає в тому, що хтось є донькою великої держкомпанії чи вміє добре вигравати тендери, але, як мені здається, це тільки частина пояснення.

Я вів безліч IT-проектів від стадії «зараз все погано, зробіть що-небудь, щоб стало добре» до написання коду і його подальшої технічної підтримки. Крім того, я кілька разів виступав в якості замовника для проектів, в технічній частині яких я не розбирався взагалі. Важливо, що я працював у компаніях, де IT-складова не була основою бізнесу, а значить, виконувані проекти були засобом вирішення чиїхось проблем, а не кінцевою метою. У мене сформувалася точка зору, яка показує, чим відрізняється стан «до» від стану «після», і чому «після» подобається кінцевим користувачам, навіть якщо воно реалізує не оптимальну бізнес-логіку.

З точки зору клієнта, будь-яку компанію можна представити у вигляді чорного ящика, внутрішнє пристрій якого невідомо. Всередину нього можна подати запит – і, в більшості випадків, «чорний ящик» поверне детермінований відповідь. Якщо правильно сформульований запит (наприклад, це замовлення, і він містить всю необхідну інформацію для виконання) і виконані якісь додаткові умови (гроші переведені на розрахунковий рахунок), то компанія здійснює якісь дії. Цими діями може бути [доставка телевізора], або [надання консультаційних послуг в області оподаткування], або [прибирання приміщення]. Суть виконуваних дій не важлива – важливо, що замовник створює запит, і бажає, не заглиблюючись у внутрішній пристрій процесу, отримати результат.

Можна піти глибше і побачити, що всередині компанії запит клієнта перетвориться в послідовність запитів до різних відділів всередині компанії, причому кожен відділ також є чорним ящиком. Послідовно опитуються менеджер з продажу (запит коректно сформульований?), склад (товар в наявності?), бухгалтерія (оплата отримана?). Нас абсолютно не цікавить, як саме вони отримають цей відповідь, важливий тільки результат. Якщо на кожне із запитань відповідь «так», то відбувається запит на виконання операції «відвантаження товару і доставка клієнту» і «сповіщення клієнта про термін виконання замовлення», які теж є чорними ящиками і взагалі можуть бути винесені за межі компанії на аутсорс.

Навіть в межах одного відділу може існувати поділ праці, коли кілька колег ділять між собою роботу за яким-небудь правилом. Цей процес теж можна представити у вигляді запиту на виконання яких-небудь дій від одного працівника іншому, причому, як і у всіх попередніх випадках, замовнику дії не обов'язково знати, що саме відбувається, важливий тільки результат.

Якщо на будь-якому рівні відбувається непередбачена ситуація, вона эскалируется вгору по ланцюжку замовників до рівня, де буде можлива її обробка. Наприклад, новий співробітник у відділі продажів, на якого поклали обов'язок перевірки формальної коректності запитів, що надходять, виявив, що замовлення сформульовано некоректно (продукція з таким найменуванням відсутній). Він повідомляє про це голові відділу, який курирує його роботу. Глава відділу може виявити, що мається на увазі не товар з найменуванням WSX012, а WSXO12 (клієнти завжди плутають літеру O з нулем), вручну скоригувати текст замовлення і повернути його на повторну перевірку. Або він може підтвердити, що запит складено некоректно і повернути завдання з помилкою на верхній рівень, з якого інформація потрапить вихідного клієнту, який вже буде вирішувати, як саме запит повинен бути переформулирован.

Термін «чорний ящик» не говорить про те, що замовник дійсно не знає, що відбувається по той бік його замовлення, просто для створення запиту і отримання відповіді це знання не потрібно. Директор великого інтернет-магазину може ідеально знати процеси, що відбуваються всередині його компанії, але якщо він замовить товар, використовуючи свій магазин, процес його обслуговування принципово нічим не буде відрізнятися від процесу обслуговування будь-якого іншого клієнта.

Вся сукупність бізнес-процесів компанії може бути представлена у вигляді звернень до «чорних скриньок», кожен з яких неявними для оточуючих чином реалізує свою частину процесу. Робота будь-якого керівника (якщо тільки він не знаходиться в стані «граючого тренера») полягає в створенні подібних скриньок та подальшої оптимізації їх внутрішньої роботи. Програмісти, які приходять слідом, намагаються перекласти кожен елемент цього процесу в програмний код, який буде виконувати те ж саме, що до нього не робив чоловік, але за нульове (пренебрежимо мале) час і без помилок, властивих людині.

У переважній більшості випадків невдоволення замовників виникає з двох причин:
— затримки в часі. Результат не одержано або одержано за час, що не задовольняє замовника;
— результат не відповідає базовим очікуванням клієнта (хотів A, отримав B), або існують проблеми з якістю виконання.

Одні і ті ж причини зустрічаються на всіх рівнях організації: колега прострочив покладену на нього завдання, ще й накосячив в процесі; відділ закупівель три місяці не міг закупити новий принтер, а коли купив – він виявився чорно-білим, а не кольоровим; компанія тиждень не могла вислати комерційну пропозицію, а коли зробила – в ньому не виявилося того, що дійсно просили.

Якщо спробувати розглянути кожен такий випадок докладніше, виявиться, що, здебільшого, операції, у яких виникли подібні проблеми, є нестандартними. У них потрібно здійснювати дію, яке зазвичай в рамках даного процесу не здійснюється. Навіть якщо загальний обсяг стандартних дій у десятки разів більше обсягу нестандартних, затримки і помилки трапляються саме в тих місцях, для яких немає відпрацьованого алгоритму, яким можна слідувати. Основний час при цьому витрачається не на роботу, а на спроби зрозуміти – що саме потрібно зробити. Від особистих якостей людей, які беруть участь у процесі, практично нічого не залежить – так, вихід із нестандартної ситуації буде знайдений трохи швидше або трохи повільніше, але, в будь-якому випадку, основний час буде витрачено на обдумування ситуації, а не на виконання дій, проблему вирішують.

Втім, і це приємно, в обох проблем є одне загальне рішення – необхідно чітко прописати алгоритм дій, за яким треба діяти при настанні всіх можливих типів подій. При наявності чіткого і однозначного алгоритму дій (не обов'язково зашитого в код, досить паперової схеми, що висить на стіні) проблеми, подібні описаній вище, практично припиняють з'являтися. Робота, яка раніше займала тиждень, раптом починає виконуватися за день, то, що вимагало трьох досвідчених співробітників, раптом починає вимагати одного студента, що виконує шаблонні дії виду «відкрив файл – простягнув формулу – підсумував результат – в залежності від відповіді прийняв одне з трьох рішень». З боку це здається магією, але основне збільшення продуктивності праці виникає не в момент, коли нудну роботу однієї людини перекладають на машину, а коли творчу роботу однієї людини редукують до монотонної роботи іншого. Написання коду і правда стає необхідно, коли подібних інструкцій стає так багато, що одна людина не може їх відтворити всі без помилок, або коли швидкість виконання замовлення – ключова цінність для клієнта. Але в більшості випадків це лише допоміжна частина процесу, який міг би йти і без допомоги IT.

Даний спосіб представлення процесів має багато аналогій з процесом програмування в цілому і його базовими концепціями (такими як інкапсуляція), дуже зручний і має багато корисних застосувань. Наприклад, можна, використовуючи декілька ідеально працюють «чорних скриньок», як з кубиків Lego, конструювати новий процес, який дозволить заробити/заощадити компанії ще трохи грошей. Порівнюючи кубики між собою, можна приймати управлінські рішення: якщо кубик всередині компанії працює не ефективно в порівнянні з аналогами – можна оптимізувати його або просто викинути, вирішуючи задачу іншим способом або виносячи її на аутсорс. Однак, як показує практика, навіть перший варіант — конструювання нових процесів з старих кубиків — погано працює на практиці, і справа зовсім не в небажанні змінюватися.
Розглянемо ситуацію: ви звернули увагу, що після покупки A іноді клієнти повертаються і докуповують послуги B і C. Ви вирішуєте, що можна збільшити продажі B і C, роблячи пропозицію про покупку кожному, хто купує A. Розрахунок вартості пропозиції кожної послуги робиться незалежно різними командами, але в підсумковому пропозиції клієнтові вони повинні бути всі разом – а отже, якщо якась з трьох команд не встигає підготувати пропозицію в строк, то решта дві чекають її. Якщо спізнюються кілька команд – чекають останню з них. Під час пілотного проекту ви виявляєте, що шанси не вкластися в термін для кожної з команд – близько 20%. А значить, шанси, що ніхто не запізниться – 0.8^3=0.51, тобто затримки термінів будуть відбуватися в половині випадків. Припустимо, що в одному з трьох випадків подібна прострочення призводить до того, що клієнт йде. Ви порівнюєте втрати від переходу клієнта з можливим прибутком від продажу B і C, виявляєте, що перше більше, і вирішуєте згорнути проект.

Чому це сталося? Бо колись давно, в момент створення кубика, було прийнято рішення «20% зусиль – 80% результату». Тоді це виглядало простим і правильним рішенням – не відомо, підуть взагалі продажу кожної з послуг, а після того, як вони пішли, треба було якомога швидше наростити обсяг, концентруючись тільки на «стандартних» клієнтів та ігноруючи будь-які відхилення. Однак ця стратегія призвела до того, що компанія фактично закрила для себе можливість для розвитку. Вона не може ефективно здійснювати комплексні продажі, вона не може робити крос-продажу навіть у тих випадках, коли вони доречні. З-за того, що кожен елемент великого процесу працює нестабільно як за якістю, так і за термінами, на його основі не можна побудувати щось нове.

У ситуації вище був можливий і альтернативний варіант: в кожному відділі, готовив пропозицію щодо свого продукту, був проведений аналіз, який показав, що все багатство пропонованих варіантів можна звести до п'яти коробкових продуктів, кожен з яких підходить для своєї цільової аудиторії. Підготовка пропозиції кожному клієнтові тепер зводиться до заміни найменування клієнта в шапці документа (хоча і від цього можна відмовитися), а прострочення і помилки просто зникли. Кожне речення тепер складається з ретельно підготовлених і перевірених частин, які набагато краще, ніж ті, які були раніше. Проект з крос-продажами успішно запущений і приносить прибуток, планується розширити його досвід на інші послуги компанії. Більше того – за рахунок відпрацювання базових процесів (продажу A, B і C окремо) компанія отримала лояльних клієнтів, які в курсі, з якими труднощами доводиться стикатися при спробі купити те ж саме у конкурентів. Найприємніша частина – на основі цього процесу можна зробити такий, який принесе компанії ще більше грошей. Крім роботи з вхідними заявками можна почати активні продажі потенційним покупцям – благо підготовка пропозиції для кожного з них тепер є механічним процесом, який може бути виконаний за 5 хвилин.

Запропонований приклад дуже схематичний і шаблонний, але він наочно показує ситуації, з якими я стикаюся щодня. Зазвичай у компанії є невелике число ідеально працюючих процесів та велика кількість процесів, в яких, з тією або іншою періодичністю, виникають якісь проблеми. Як правило, процеси другого типу включають в себе перші, але дуже рідко процес, що містить проблеми, використовується в іншому процесі. Ідеально працюють процеси можна уявити як кубики правильної форми, з яких можна зробити будь-який процес, який тільки можна собі уявити. Другі – потворні, деформовані кубики, які можна прикріпити до чого-небудь, але які можна використовувати для подальшого будівництва конструкції. Не те, щоб їх не намагаються використовувати, але будь-які спроби зробити це зазвичай закінчуються провалами. Спроби використовувати кубики, які працюють добре, зустрічаються приблизно настільки ж часто, але відсоток вдалих спроб незрівнянно вище. Виходить свого роду еволюція в рамках однієї компанії, причому, чим більше ідеально працюють кубиків є в її складі – тим ширше поле для експериментів і тим більшу гнучкість компанія отримує.
Для оцінки того, наскільки процес близький до ідеалу, зручно використовувати правило 6 сигм. У простому викладі його можна представити як оцінку частки помилок серед загального числа спроб виконання якої-небудь дії. Якщо в процесі виникає менше 6 помилок на тисячу – процес задовольняє умові 4 сигм, якщо менше 2 на десять тисяч правилом 5 сигм, менше трьох на мільйон — 6 сигм. Для більшості процесів, з якими я працював, я так і не зміг досягти рівня 6 сигм, але цей рівень є хорошим орієнтиром на майбутнє.

Цікаве зауваження: практично для всіх ситуацій, які я бачив, новий процес, що складається з декількох старих ідеально працюючих частин, приносить або економить компанії набагато більше грошей, ніж базові процеси, що входять до його складу окремо. Складові продукти і послуги, які стають можливими, часто мають незрівнянно більшу цінність для споживачів, ніж кожен з елементів окремо. У той же час, навіть поліпшення базових процесів саме по собі може виділити вас порівняно з конкурентами, роблячи вас «вибором». Я вважаю, що, в багатьох випадках, саме такий підхід дозволяє одним компаніям перевершувати інших, працюючи спочатку в рівних умовах.
Втім, такий підхід до конструювання і поліпшення процесів не гарантує успіху. Він має свої недоліки – наприклад, не враховує супутні витрати. Так, ті користувачі, які вже погодилися скористатися процесом, будуть задоволені – вони отримають передбачуваний результат точно в обіцяний час. Але це нічого не говорить про внутрішній ефективності процесу – всередині чорної скриньки можуть вчинятися зайві дії, неефективно витрачати час і гроші, але зовнішній користувач нічого не буде знати про це, оскільки він працює з системою, всередину якої заглянути у нього немає можливості. З цієї причини задоволеність старих користувачів процесу нічого не буде значити, якщо поруч виявиться конкурент, який зможе виконувати ті ж самі дії, але в два рази швидше або за набагато нижчою ціною. Для вирішення таких проблем краще скористатися іншими методиками, наприклад, «ощадливим виробництвом» або його аналогами в застосуванні до сфери послуг.

Іншим моментом, який не включений явним чином в концепцію, є черги. Існує можливість, що якийсь чорний ящик працює, забезпечуючи стабільну якість і терміни раз за разом, але середня швидкість надходження нових замовлень вище, ніж швидкість обробки поточних. У таких умовах неминуче будуть формуватися черги на виконання, яких не можна уникнути. У загальному випадку, черги можуть бути сигналом того, що даний процес обмежує ефективність і швидкість пов'язаних з ним процесів. Існує багато способів вирішення цієї проблеми – від набору нових співробітників і підвищення швидкості за рахунок автоматизації до усунення дій, що не додають цінності, але в явному вигляді в даний підхід вони не включені.

Підводячи підсумки:
— представлення компанії у вигляді послідовності вкладених один в одного чорних скриньок є зручною абстракцією, що дає новий підхід до аналізу проблем компанії;
— ідеально працюють чорні ящики (забезпечують стабільний результат за заздалегідь відоме час) можуть природним чином бути включені в більш складні конструкції, що підвищує їх важливість для компанії;
— підхід «20% зусиль – 80% результату» є прекрасною стратегією на початку, але гальмує або робить неможливим подальший розвиток;
— процеси, що складаються з декількох елементів, як правило, більш цінні для клієнтів, ніж кожна частина процесу окремо.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.