IT ManagerИТ в бизнесеУправление

Кое-что из практики оптимизации бизнес-процессов

Александр Башкиров | 23.05.2018

ВКонтакт Facebook Google Plus Одноклассники Twitter Livejournal Liveinternet Mail.Ru

Кое-что из практики оптимизации бизнес-процессов

Одна из типичных задач, так или иначе с завидной периодичностью «падающих» в ИТ, — требование по оптимизации бизнес-процессов. И, как ни странно, зачастую именно это заставляет коллег «изобретать велосипед», хотя вроде бы все велосипеды изобретены до нас... Из данного посыла и родилась статья — краткое практическое пособие по оптимизации бизнес-процессов, предложенное человеком, который реализовал подобные преобразования на процессах, охватывающих деятельность более 1000 сотрудников.

С чего начать?

Как и любое преобразование, оптимизация бизнес-процессов начинается с постановки цели. Чего мы хотим добиться в результате оптимизации? Что должно получиться в итоге и что не должно произойти ни при каких обстоятельствах? Ответы на эти вопросы помогут сформулировать цель оптимизации процессов. Отмечу, что цель может быть общей и для всех процессов, и для каждого. Как правило, можно выделить подцель — с указанием конкретных измеримых параметров того, что должно быть оптимизировано. Например: «Целью проекта оптимизации бизнес-процессов является уменьшение времени выпуска изделия со 100 до 80 часов, при уменьшении процента брака с 7 до 3%». Это конкретная цель. Для каждого процесса можно поставить и свою цель, коррелирующую с общей. Например, одной из подцелей может быть «Снижение срока проектирования нового изделия с 12 до 10 часов путем оптимизации процесса проектирования изделий». Тут, правда, большой отдельный вопрос: за счет чего и как выполнять поставленные цели (скажем, снижение срока проектирования запросто может отразиться на балансе «скорость — качество»).

После того как поставлены цели, необходимо определить объекты оптимизации. Иными словами, определить, что оптимизируем, а что — нет. Причин явно выделять объекты оптимизации может быть несколько: во-первых, это бизнес-приоритеты. Где «больнее болит» — там, очевидно, и надо прилагать максимум усилий. Во-вторых, затраты — где больше расходов, там, вероятно, найдется простор для оптимизации. В-третьих, временные характеристики. В-четвертых, метрики, указывающие на удовлетворенность заказчика. И так далее.

Следующий вопрос, который следует решить до оптимизации, — приоритет процессов на оптимизацию и желаемые сроки внедрения оптимизаций, а также сроки оценки последствий оптимизации. Указав эти сроки, мы делаем очень важную вещь, а именно формируем ожидания по последовательности оптимизационных работ. Кроме того, следует непременно установить период оценки последствий оптимизации. Это весьма существенный параметр, который позволит задать пределы оценки ретроспективы. Проще говоря, нам необходимо установить срок, в течение которого мы будем анализировать последствия внедрения по итогам оптимизации. Почему это важно? Потому что обычно оптимизация бизнес-процессов дает эффект не мгновенный, а протяженный во времени. И оценивать его следует в некоем «коридоре» от завершения оптимизации до принятого некоторого значения. Также надо отметить, что обычно данный период совпадает с периодом сопровождения оптимизированного процесса (и зачастую, при серьезных оптимизациях, период постоценки может быть расширен).

Для того чтобы приступить непосредственно к оптимизации, для начала нужно бизнес-процессы описать. Проще всего это сделать, проведя ряд интервью со всеми участниками и составив таким образом некое «ментальное» описание процесса, которое впоследствии может быть переведено в «вещественную» форму (например, в план процесса в нотации IDEF0 или блок-схем). Собственно, данная репрезентация и станет отправной точкой для оптимизации.

Как найти точки оптимизации?

Рассмотрим теперь, какими способами можно найти точки оптимизации процесса. Самый простой и быстрый способ определить точки оптимизации — помочь найти их людям в ходе интервью. Как правило, у каждого из них есть что сказать и что улучшить. Все эти моменты я стараюсь записывать и впоследствии учитывать при оптимизации.

Следующий способ —зафиксировать свои соображения и идеи по ходу интервью. Зачастую получается, что во время интервью возникают различные гипотезы, которые я стараюсь фиксировать и обрабатывать позднее (как вариант — проговорить их сразу же, но тогда есть риск уйти в обсуждение гипотез, а не в работу по сути).

Еще один вариант — на этапе обработки результатов внимательно «пройти» всю цепочку работ, выявляя узкие места и намечая возможные направления оптимизации. Кстати, он эффективен, когда речь идет о хорошо знакомой аналитику области. В сфере незнакомой предложить что-то действительно стоящее — достаточно сложно.

Очередной способ — обсудить результаты на собрании экспертов. То есть собирается команда экспертов в предметной области (работников организации, и, возможно, приглашенные эксперты), которые намечают точки оптимизации процессов. Как разновидность этого способа я практиковал привлечение не только экспертов, но и руководителей различных рангов. Получалось неплохо с точки зрения экономии времени и эффективности конечного результата.

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

В ряде случаев я фиксировал идеи «из отбраковки» и предлагал ознакомиться с ними экспертам. С одной стороны, в «отбраковку» могло попасть что-то дельное. С другой — элементы идей могли пригодиться при обсуждении оптимизации процессов. И с третьей — я демонстрировал логику «сита», чтобы снять вопросы типа «почему эта идея не в скопе».

Важно отметить, что для оптимизации процессов необходимо выбирать «правильную» нотацию (способ описания) бизнес-процесса. Ведь процесс, описанный в определенной нотации, может оказаться непригодным для дальнейшей трансформации «де-юре». Например, потому что он в силу выбранной схемы не содержит важной информации или, наоборот, имеет избыточное описание. И если второй случай (избыточное описание) чреват легким раздражением, то первый (недостаточность информации) в худшем варианте способен породить повторный виток описания. Поэтому очень важно, приступая к описанию бизнес-процессов с целью оптимизации, выбирать схему, которая будет необходима и достаточна для дальнейшей работы.

Карта оптимизации и тестирование

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

Карта оптимизированного процесса выносится либо на суд внутренних экспертов, либо сразу на защиту. Зависит от ситуации — в моей практике были случаи, когда с участниками процесса обсуждались отдельные оптимизации, которые после сводились в одну карту. Она, в свою очередь, представлялась на защите всем заинтересованным лицам, анализировалась и утверждалась. А бывало, что карта оптимизированного процесса в целом изначально разрабатывалась с участниками процесса — экспертами — и представлялась руководству в формате презентации. При этом универсального рецепта, как действовать в той или иной ситуации, — нет, все зависит от самой ситуации, целей организации, целей аналитика и его влияния на формат работы.

Важной точкой в вопросе оптимизации процессов лично я считаю «прогон» (моделирование) измененного процесса. Делается он так же, как в разделе «Как описать процесс?». Поэтому не буду повторять ранее изложенное, просто скажу, что «прогон» измененного процесса целесообразно делать путем сбора всех ключевых сотрудников процесса и последовательного моделирования движения работ по процессу, с разными возможными входными данными, вариациями и т. д. Эту операцию следует выполнять до момента защиты процесса. Операция очень полезна, потому что позволяет выявить вероятные узкие места, вскрыть не увиденные ранее противоречия и т. д. Кроме того, в результате такого моделирования могут и должны быть внесены корректировки в измененный процесс. А это, кроме того, что решает основную задачу — оптимизацию процесса, создает и задел для решения дополнительной задачи, а именно вовлечения сотрудников в ценность оптимизации и получаемых выгод.

Как внедрять изменение?

Самый интересный вопрос, который мне часто задавали: а что происходит после того, как сформирована и утверждена карта оптимизированного процесса? Я всегда отвечаю, что происходит «магия». На самом деле происходит самый интересный момент — внедрение изменений в процесс. Как я уже говорил, в данную карту, помимо самого процесса, резонно включить перечень мероприятий по внедрению изменений. А их, в свою очередь, целесообразно обсудить с всеми участниками и экспертами. А также утвердить у руководства. Фактически перечень мероприятий представляет собой прообраз плана трансформации бизнес-процесса. Для того чтобы он принял законченный вид, нужно облечь его в формат плана и принять к исполнению.

Тут возникает следующий тонкий момент, связанный с приоритизацией: какие процессы оптимизировать первыми, какие — вторыми, а какие не стоит вообще (например, потому что они не важны).

После того как проведена приоритизация, приступают непосредственно к реализации изменений. Хорошей идеей, с моей точки зрения, является вынесение деятельности по внедрению оптимизаций в процессы в отдельный проект с постпроектным мониторингом. В какой-то мере такие мероприятия могут гарантировать как конкретный результат, так и ретроспективу того, что получилось в итоге. Кроме того, подобный подход в теории обеспечит расстановку контрольных точек, бронирование ресурсов, контроль изменений онлайн.

Еще важный момент, особенно при оптимизации больших процессов. Нередко получается так, что изменения в одном процессе могут быть растянуты во времени или требовать значительных усилий. Здесь целесообразно, кроме выделения очередности внедрения изменений в процессы, выстроить очередность изменений в больших процессах и придерживаться ее, согласно расставленным приоритетам. Это позволит сделать оптимизацию более гладкой и, как косвенный итог — управлять ожиданиями руководства относительно скорости и результата оптимизации процессов.

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

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

Регламент работы сотрудника, он же «ролевая инструкция». Тут очень подробно написано, кто что делает на каком шаге. И в идеале — что делать в непонятных ситуациях (схема эскалации, заморозки решения и т. д.);

Ответы на часто задаваемые вопросы (это может быть некоторая онлайн пополняемая база знаний).

Предположим, мы подготовились к внедрению: есть смоделированный процесс, есть материалы и согласованная схема мероприятий... Вроде бы — бери и делай. Но и в период внедрения требуется соблюсти определенные правила. Их несколько.

Внедрение изменений в процесс должно получить официальный статус. Для этого необходимо выпустить приказ или распоряжение об изменении процесса, в котором, в частности, должны быть зафиксированы полномочия ответственных за изменение и роль аналитика процесса, а также список участников и их конкретные действия. Особенно это актуально для крупных государственных организаций — там без приказа, скорее всего, не будет вообще ничего.

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

Необходимо заранее подготовить регламенты. Они могут быть частью приказа, на них может быть ссылка в приказе, но они должны существовать. В регламентах должно быть написано, что теперь должен делать применительно к процессу каждый его участник, как будет оцениваться его работа и кто этим займется (на практике часть «кто и как оценивает» обычно вызывает ступор — именно поэтому ее надо проработать максимально подробно).

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

И про людей

Еще один весьма актуальный вопрос, который следует затронуть: как работать с сопротивлением, возражением, страхом? Не секрет, что любое организационное изменение (а изменение процессов — это именно оно) обычно вызывает стресс и панику среди рядовых сотрудников. И если с ним ничего не сделать, то могут возникнуть последствия, связанные с ухудшением климата в коллективе. И, соответственно, ухудшение производительности в целом, вплоть до саботажа.

Как не допустить этого? Во-первых - до начала проекта открыто его анонсировать. Довести до каждого сотрудника, особенно до тех, кто непосредственно работает в трансформируемых процессах, цели и задачи реорганизации.

В самом начале необходимо познакомить команду проекта с сотрудниками, выстроить между ними открытый диалог. Причем это не просто слова: люди, как правило, склонны к персонализации. В итоге — если команда трансформации найдет общий язык с сотрудниками, которые задействованы в процессах, сами изменения будут восприниматься легче и их внедрение, вероятно, не будет сопровождаться сопротивлением.

В ходе изменений нужно держать в фокусе внимания не только само изменение, но и людей. Универсального рецепта на этот случай нет, но общие рекомендации дать можно. Важно, как минимум постоянно быть в контакте с ключевыми участниками процесса — совместно вырабатывать план трансформации, делать шаги, оценивать итоги.

Если в результате трансформации должны быть проведены кадровые перестановки, их следует готовить заранее. Если перестановки связаны с перемещением, то разъяснить тем, кого перемещаем, как это будет происходить, когда и что они выиграют и что, возможно, потеряют. Если перестановки связаны с увольнением, оно также должно готовиться заранее, с точки зрения юридических оснований, компенсаций и т. д. Увольнения важно не замалчивать, и в любой момент времени быть готовым дать ответ на вопрос «почему ушел такой-то сотрудник?».

Необходимо помнить о том, что лучшее лекарство от коллективного страха — максимальная прозрачность ситуации для любого, находящегося в ней.

Сложнее дать рекомендации по работе с противодействием, хотя общие рекомендации тоже, безусловно, есть. Во-первых, надо выявить возможные и фактические источники противодействия. Во-вторых, постараться вовлечь их в инициативную группу по изменению — зачастую такого рода признание снимает противодействие, превращая противника в союзника. В-третьих, разъяснять личные выгоды для каждого противодействующего (тут важно не покупать лояльность, а именно демонстрировать реальные выгоды). В-четвертых, на всякий случай быть готовым к тому, что противодействующий покинет компанию (например, в знак протеста).

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

Ключевые слова: управление проектами, руководитель проекта

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

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

Об авторах

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

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

Руководитель департамента разработки и проектирования «Адванта Софт». ИТ эксперт. Высшее техническое образование. Публикуется в ИТ-прессе с 2001 года, с IT Manager сотрудничает с 2009 года. Основные интересующие темы: отношения ИТ и бизнеса, облака, технологии ИТ для бизнеса, управление, проекты, консалтинг, СПО.

Мероприятия

23.10.2018
Северо-Западный форум Cisco

Санкт-Петербург, Гостиница Астория

24.10.2018
Как построить маршруты торговых представителей и увеличить продажи на 15-20%?

Москва, Москва, Ленинградский проспект, 39, строение 14, офис 203-204, Центр логистики.

26.10.2018
Цифровая трансформация для Руководителей и Собственников бизнеса

Москва, Озерковская наб. 26, отель «АКВАМАРИН» (М. Новокузнецкая, Третьяковская), конференц-зал «ЭМЕРАЛЬД» (1 этаж)