Инна Макотерская – последние статьи и новости

Спеціаліст з організації бізнес-процесів і співзасновниця консалтингу I+J Інна Макотерська — про те, як реорганізувала роботу в Aimbulance, Mediahead та багатьох інших компаніях. Інна Макотерська та Юлія Захарченко, I+J Погана організація — великі збитки За даними дослідження IDC, компанії втрачають від 20 % до 30 % річного доходу через неефективність. Такі цифри наводить Entrepreneur. Деколи ставки бувають значно вищими. Process Street розповідає, що аварія супутника NASA, який мав дослідити клімат Марсу 1999 року, трапилася саме через погано задокументовані процеси. Збитки становили $193 млн. У компаніях з неправильно побудованими процесами та структурою некомфортно працювати. Вони стикаються із плинністю кадрів, змушені шукати для працівників штучну зовнішню мотивацію, а власникам складно планувати зростання бізнесу, адже організаційна структура хитка та ненадійна. Як змінити те, що не працює Першу трансформацію я робила в Aimbulance як головний операційний директор і молодший партнер. Спершу архітектура компанії була традиційною: кожен департамент виконував свою частку роботи, готовий продукт передавався клієнту. Щоби підвищити залученість спеціалістів у проект та синергію з клієнтом, ми вирішили змінити архітектуру: зібрали креативні команди, кожна з яких може автономно працювати з певним продуктом. Обговорили нові ролі, перебудували процеси, встановили нові КРІ. Зрештою підхід настільки змінився, що це вплинуло на культуру компанії, ми переписали цінності. Зазвичай проекти повної трансформації тривають від 6 до 12 місяців; вони комплексні, складні та кайфові. Компанія стає здоровішою та ефективнішою, працювати в ній приємніше, власники мають більше прибутку, зростає рівень задоволення клієнта. З Вортонської школи бізнесу — в українську екосистему Для трансформацій ми використовуємо систему, в основі якої лежить методологія Вортонської школи бізнесу. У її стінах навчалися Ворен Баффет, Ілон Маск, Стівен Коен, Іванка Трамп та багато інших. Методологія назвивається HPT 3x3 (це скорочення від англійського High Performing Teams — високопродуктивні команди). Разом з моїм партнером Юлею Захарченко ми доповнили систему, щоби адаптувати її до вимог українського бізнесу. Згідно з методологією кожен проект змін складається з трьох етапів: Commit, або робота (близько місяця) — домовляємося з командою про цілі (на рівні компанії-команди-спеціаліста), ролі та норми комунікації, прийняття рішень і вирішення конфліктів. Найбільша помилка, яку роблять на цьому етапі, — поспілкуватися лише із засновниками або керівниками напрямків. Не раз стикалася з ситуаціями, коли, скажімо, арт-директор намагався сам покращити роботу департаменту. Але, працюючи над процесами і нормами самостійно, пропускав або недооцінював якісь етапи роботи. Є також інший ризик: навіть якщо менеджер підготує коректні інструкції, команда може їх не прийняти. Ми шукаємо домовленості у форматі численних воркшопів. Учасниками та авторами змін є сама команда, ми лише фасилітуємо та систематизуємо процес, а також обробляємо результати кожної сесії та презентуємо напрацювання команді. Якщо ви проводите реорганізацію самостійно, обов’язково призначте ведучого зустрічей та доручіть комусь з команди обробку і презентацію даних. Check, або ж перевірка — відтестовуємо всі домовленості з командою на практиці. Щоби цей етап був ефективним, на попередній стадії ми чітко визначаємо цілі та KPI, які сигналізуватимуть про успішність чи неуспішність змін. Close, або ж фіналізація — коригуємо роботу команди. Фактично цей період нескінченний. Адже ми разом створюємо культуру постійного циклічного зростання та вдосконалення. Нові ітерації перевірки і фіналізації можуть бути пов’язані зі змінами у продукті, у кадрах, на ринку. Приміром, працювала з контент-агенцією. Спочатку вона прагнула покращити швидкість, щоби взяти більше клієнтів і підвищити прибуток. Ключові KPI для копірайтерів — кількість чи обсяги текстів. Але потім до них прийшли клієнти з нових індустрій: дорожчі, зі складнішими продуктами. Гнатися за швидкістю було вже неправильно, бо якість впала би і агенція втратила би репутацію. Тому ми зробили ставку на те, щоби зменшити кількісні KPI і фокусуватися на якісних: проводити опитування клієнтів, підвищувати рівень задоволення. Як ми проводимо трансформацію компанії Домовляємося, що трансформація — це проект. Обираємо разом з клієнтом проектного менеджера. Зазвичай це людина з топ-менеджменту, але не раджу покладати цю задачу на виконавчого директора. Формуємо проектну команду, плануємо етапи роботи. Проектний менеджер стежить за всіма процесами та досягненням КРІ. Він опікується інтеграцією нових правил. Навіть коли є зовнішній консультант, відповідати за імплементацію змін має менеджер всередині компанії. Приміром, коли ми працювали з агенцією Mediahead, на цю роль команда обрала одного з менеджерів. Ми уже вийшли з процесу, але проектний лідер продовжує трансформацію. Так само знаю випадки, коли зміни зупинялися, щойно консультант виходив за двері, бо не було менеджера, що відповідає за покращення. Визначаємо цілі та релевантні КРІ. Вимірювати можна коефіцієнт використання промислових потужностей, відхилення у розкладі проекту, відхилення у вартості проекту, рівень простою процесу, індекс якості, плинність кадрів у команді, задоволення співробітників. Ми радимо концентруватися на кількох KPI, які на цьому етапі найбільш релевантні для вашої організації. Якщо раніше ви не робили замірів, почніть їх робити. Часто бачу, що у власника є бажання вимірювати все, що тільки можливо, і встановлювати десяток КРІ. Це погана ідея: втрачається фокус. У вас може бути багато цілей, але працювати краще з однією-двома за раз. Приміром, першочергова мета — прискорити роботу над продуктом і знизити виробничі витрати. Це два KPI. Коли навчитеся систематично досягати потрібних показників, переходьте до наступних цілей. Перевіряємо, чи має команда всі потрібні компетенції. У кожній команді мають бути представники з різними компетенціями (поза основним фахом): маркетинг, адміністративні, комунікаційні тощо. Приміром, компанія робить мобільні застосунки для клієнтів. Один з розробників може бути адміністратором команди, копірайтер — відповідати за досягнення маркетингових цілей і комунікацію, дизайнер — за креатив. Якщо хоча б однієї компетенції не вистачає, команда не працюватиме автономно. Також у команди має бути лідер. Це суперечить концепції бірюзових команд, але досвід показує, що на перших етапах розвитку наявність лідера зазвичай підвищує продуктивність. Знову ж таки, кожен лідер команди в нашій практиці мав ще певні фахові задачі, але водночас він відповідав за злагоджену роботу і розвиток команди. Вчимо команду святкувати невеликі перемоги. Скажімо, якщо команда швидше здала проект або залучила нового клієнта, це варто відзначати на рівні всієї компанії. Такі маленькі святкування мотивують продовжувати трансформацію та дають команді розуміння, що вона на правильному шляху. Будуємо комунікаційну екосистему всередині компанії. В процесі трансформації команди можуть стати дещо ізольованими. Тому ми наполягаємо на створенні системи, яка допоможе командам обмінюватися експертизою, досвідом, інноваціями. Це може бути спільний канал у Slack, де всі команди діляться новинами. Також варто проводити офлайн-зустрічі команди, в тому числі регулярні фахові (дизайнерів, девелоперів, маркетологів тощо). Співробітники мають розуміти, що кожна команда — це сильна структурна одиниця компанії, але ключова перевага полягає в тому, що всі вони об’єднані на єдиній платформі. Цю інформацію треба транслювати насамперед топ-менеджменту та продуктовим лідерам. І останнє, але не менш важливе: люди приймають будь-які зміни за певним графіком. Є частка тих, кого процес змін драйвить від самого початку, так звані інноватори. До них приєднуються ранні послідовники, потім — рання більшість. Пізня більшість згодом приєднується до ранньої. Консерватори долучаються останніми. Варто підбирати правильні інструменти та канали комунікації для кожної групи і бути готовими до того, що найбільш «радикальні» консерватори можуть так і не пристосовуватися до змін. Частину з них доведеться відпустити, але для багатьох можна знайти комфортне місце у новій структурі. Як перелаштувати бізнес-процеси Отже, ви зібрали команду трансформації, що має власного лідера. Попрацювали над загальною структурою компанії, сформували команди, визначили ролі усіх співробітників, узгодили спільні та особисті цілі. Створили комунікаційний простір. Домовилися, як приймати рішення та вирішувати конфлікти. Далі треба переходити до конкретних процесів, за якими працюють команди: процес створення нового продукту, фінансового менеджменту, клієнт-сервісу тощо. Під процесом ми розуміємо будь-який повторюваний набір дій, націлений на певний результат. Як ми працюємо над процесами Доносимо до команди ціль роботи над процесом, яких результатів плануємо досягти. Знову ж таки, формулюємо КРІ. Приклад: «Ми прагнемо зменшити бюрократію і прискорити виробництво. Кожен спеціаліст матиме більше свободи, а також зможе отримати більший матеріальний бонус (якщо команда встигне зробити більше задач)». Вчимо команду працювати з процесами: пояснюємо відмінність процесної та проектної роботи, важливість для бізнесу сталої роботи з бізнес-процесами і те, як кожен впливає на процес та може долучитися до його покращення. Наприклад, один з продуктів дизайн-студії — розробка сайтів. Кожен сайт — це окремий проект, але можна сформулювати процес з повторюваними кроками (заповнення брифа, розробка концепції, макет, створення зображень, копірайтинг, верстка, підключення тощо). Під час обговорення може з’ясуватися, що шаблон брифа неповний, канали комунікації недостатньо зручні тощо. Обов’язково залучаємо до воркшопів всіх учасників процесу. Якщо в команді є декілька спеціалістів з однаковими функціями, на воркшоп може прийти один з них. Але ця людина має представляти усіх колег. Приклад: в команді три дизайнера, але на воркшопі їх представляє одна людина. Призначаємо «власника» кожного процесу. Зазвичай це продуктовий лідер в рамках продукту, який розкладається. Саме він буде координувати подальшу роботу. Наприклад, для процесу розробки сайту це може бути UX-дизайнер команди. Автоматизуємо напрацювання, «вшиваємо» їх в роботу команди. Це можна зробити по-різному: інтеграція в онлайн-систему проектного менеджменту, у форматі розбудованого флоу-процесу, чек-лістів тощо. Наприклад, команда має шаблон брифа, чек-ліст обов’язкових сторінок сайту і загальний флоу процесу. Як організаційний інструмент деяким нашим клієнтам допомагає проста дошка з наклеєними стікерами. Робимо постійною практикою зустрічі та ретроспективи для аналізу процесу. Визначаємо регулярність і формат таких зустрічей, обговорюємо обсяг проведених робіт, шукаємо помилки і точки зростання, впроваджуємо зміни. Наприклад, команда за місяць підготувала сайти для трьох клієнтів. В кінці місяця усі зібралися та обговорили результати: ось тут ми показали макет в п’ятницю о 12:00, а клієнт чекав о 10:00. О 12:00 у нього вже не було часу на перевірку, тому до обіду понеділка робота стояла. Значить, треба домовлятись про точні дедлайни. Клієнт міг би запланувати перевірку на 12:00, тоді о 14:00 команда уже отримала б правки і продовжила роботу. Це плюс 8 годин на проект. Люди зазвичай важко реагують на зміни, адже будь-які зміни — це дискомфорт. І хоча еволюція лежить в основі нашого виду, на коротких проміжках вона викликає спротив. Людям важливо розуміти, навіщо компанія йде на зміни. Вони хочуть бачити ризики та перспективи. Тому ми працюємо паралельно на рівні команди та спеціаліста, осмислюємо роботу кожного, визначаємо болі та шукаємо ліки. Тоді зміни стають надією, драйвом та можливістю. Адже, зрештою, сенс життя — це розвиток.