IT Manager: Дещо з практики оптимізації бізнес-процесів

1. Олександр Башкиров

IT Manager ІТ в бізнесі управління Олександр Башкиров

| 23.05.2018

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

З чого почати?

Як і будь-яке перетворення, оптимізація бізнес-процесів починається з постановки мети. Чого ми хочемо досягти в результаті оптимізації? Що повинно вийти в результаті і що не повинно статися ні за яких обставин? Відповіді на ці питання допоможуть сформулювати мету оптимізації процесів. Зазначу, що мета може бути спільною і для всіх процесів, і для кожного. Як правило, можна виділити подцель - із зазначенням конкретних вимірних параметрів того, що повинно бути оптимізовано. Наприклад: «Метою проекту оптимізації бізнес-процесів є зменшення часу випуску вироби зі 100 до 80 годин, при зменшенні відсотка шлюбу з 7 до 3%». Це конкретна мета. Для кожного процесу можна поставити і свою мету, коррелирующую із загальною. Наприклад, однією з підцілей може бути «Зниження терміну проектування нового виробу з 12 до 10 годин шляхом оптимізації процесу проектування виробів». Тут, правда, великий окреме питання: за рахунок чого і як виконувати поставлені цілі (скажімо, зниження терміну проектування запросто може відбитися на балансі «швидкість - якість»).

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

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

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

Як знайти точки оптимізації?

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

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

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

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

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

У ряді випадків я фіксував ідеї «з відбракування» і пропонував ознайомитися з ними експертам. З одного боку, в «відбраковування» могло потрапити щось путнє. З іншого - елементи ідей могли стати в нагоді при обговоренні оптимізації процесів. І з третьої - я демонстрував логіку «сита», щоб зняти питання типу «чому ця ідея не до Скоп'є».

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

Карта оптимізації і тестування

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

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

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

Як впроваджувати зміна?

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

Тут виникає наступне тонкий момент, пов'язаний з Пріоритизація: які процеси оптимізувати першими, які - другими, а які не варто взагалі (наприклад, тому що вони не важливі).

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

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

Я вважаю, що в ході впровадження зміненого процесу як мінімум необхідно підготувати наочні посібники для працівників:

Схему процесу в цілому. Корисно довести до всіх або майже до всіх ключових учасників процесу. Чому? Тому що співробітнику зазвичай важливо не просто працювати, а розуміти, до чого призводить його робота, для чого вона потрібна взагалі. Я часто при презентації схеми намагаюся знайти «виходи» з процесу на дивіденди організації і продемонструвати, як праця кожного співробітника впливає на їх же прибуток.

Регламент роботи співробітника, він же «рольова інструкція». Тут дуже докладно написано, хто що робить на якому етапі. І в ідеалі - що робити в незрозумілих ситуаціях (схема ескалації, заморозки рішення і т. Д.);

Відповіді на типові запитання (це може бути деяка онлайн поповнюється база знань).

Припустимо, ми підготувалися до впровадження: є змодельований процес, є матеріали і узгоджена схема заходів ... Начебто - бери і роби. Але і в період впровадження потрібно дотримати певні правила. Їх декілька.

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

Впровадження обов'язково має включати роботу з учасниками процесу, яких зачіпає і не зачіпає зміна. На зустрічі відбувається презентація схеми учасникам процесу ( «як було», «як буде» і ключові зміни), позначаються дати, план заходів та відповідальні (в ідеальному варіанті дані роботи необхідно включати до наказу, для забезпечення їх проведення).

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

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

І про людей

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

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

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

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

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

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

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

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

Ключові слова: управління проектами , керівник проекту

Гарячі теми: Бізнес в цифрі

Журнал IT-Manager № 05/2018 [ PDF ] [ Підписка на журнал ]

про авторів

Олександр Башкиров

ІТ експерт. Вища технічна освіта. Публікується в ІТ-пресі з 2001 року, з IT Manager співпрацює з 2009 року. Основні теми, що цікавлять: відносини ІТ і бізнесу, хмари, технології ІТ для бізнесу, управління, проекти, консалтинг, СПО.