Непрерывная трансформация – современный способ жить.
2.3.1. Типы проектов трансформации
К проектам трансформации относят такие, которые решают задачу создания целевого (нового, желаемого) процесса путем его изменения (совершенствование, реинжиниринг и регламентация; рис. 14) или проектирования (инжиниринг). К началу работ задача на проект должна быть поставлена явным образом – тогда он имеет шансы на успех.
Рис. 14. Выбор метода трансформации процессов
Таким образом, проекты трансформации можно разделить по типам:
совершенствование (в редких случаях оптимизация) бизнес-процессов. Задача обычно фокусирует усилия Проектной группы на изменении одной из характеристик (гораздо хуже, если нескольких) процесса «как есть» при заданных ограничениях других. Оптимизационная задача может решаться на относительно небольших процедурах26;
реинжиниринг – радикальное перепроектирование процесса с игнорированием процесса «как есть»;
инжиниринг – проектирование нового процесса в отсутствие процесса-предшественника;
• регламентация процесса (-ов) – формализация желаемого способа исполнения процесса в виде регламентного документа, сопровождающаяся корректировкой или выбором «правильных» вариантов реализации процесса (-ов).
2.3.2. Проекты совершенствования
Проекты совершенствования, пожалуй, наиболее часто встречающийся вариант процессных проектов. Метод совершенствования состоит в том, что за основу нового процесса берется существующий и ставится задача его улучшить (в самом широком смысле). Например, сократить время исполнения процесса на 30 % без увеличения его стоимости и потери качества. Или адаптировать процесс к новой организационной структуре. Или к новой коммерческой политике.
Мы будем исходить из того, что задача на совершенствование поставлена.
Рассмотрим этапы проекта по совершенствованию процесса.
Прежде всего реализуется подпроект «Описание и локальная диагностика процесса». Он состоит из следующих этапов.
Этап 1. Разработка Соглашений по моделированию.
Этап 2. Моделирование и локальная диагностика процессов.
По окончании этих работ мы получаем гораздо более детальное понимание процесса, реализуемости задачи на проект и, возможно, потенциальных решений. Следующий шаг – Этап 3. Анализ процесса и выработка направлений совершенствования. Работы здесь начинаются с уточнения задачи (и/или KPI проекта). Это очень важный шаг, который позволяет группе проекта и точнее сфокусироваться, и более реалистично спланировать дальнейшие работы, и получить «подсказки» по направлению аналитических изысканий. Результатом этапа является перечень конкретных решений – направлений совершенствования процесса. Нередко этот этап фактически пропускается. Если аналитики имеют низкую квалификацию, то они не могут провести самостоятельный анализ, а просто пользуются результатами локальной диагностики, то есть реализуют те меры, что предлагают участники процесса. Причем в таких проектах и проверку эффекта этих мер на соответствие задаче проекта никто не осуществляет. И кстати, даже сами решения носят неконкретный характер, фактически переносят детальную проработку на потом, на этап внедрения.
Работам этого этапа в значительной степени посвящена вторая книга трилогии.
Этап 4. Проектирование процесса «как должно быть» (см. главы 1.2 и 1.3). Строятся модели целевого процесса, то есть того, к которому мы должны прийти по итогам реализации Плана внедрения. Если это сделать невозможно (см. описание ошибок этапа 3 ранее), то мы имеем дело с тем, что предыдущий этап не завершен (точнее, просто не выполнен). Проект начинает расползаться: сроки переносятся, результатов нет или они не соответствуют плану.
Мы же будем исходить из того, что этап пройден успешно. Тогда его результатом будет Альбом (и база данных, набор) моделей процесса «как должно быть».
А имея модели целевого процесса, мы реализуем Этап 5. Разработка и утверждение Плана внедрения процесса «как должно быть» (как это описано в главе 1.4). Так называемый GAP-анализ, в ходе которого мы сопоставляем текущий и целевой процессы, дает возможность выработать действия по трансформации текущего процесса в целевой.
Затем следует Этап 6. Реализация Плана внедрения процесса «как должно быть», включающего в том числе организационные и контрольные мероприятия, мероприятия по регламентации и пр. (см. главу 1.6).
Здесь описан типовой план проекта совершенствования процессов. В конкретных ситуациях проекты такого рода могут быть скомпонованы по-другому: одни этапы объединены или, наоборот, разделены, в проект включены дополнительные работы, другие работы реализуются за рамками проекта и т. п. Но логика работ, их содержание и последовательность должны соответствовать описанной типовой схеме. В качестве примера на рис. 15 и 16 приведены примеры планов реальных проектов разных лет.
Рис. 15. Пример Плана проекта совершенствования процессов в энергетической компании (2009–2010 годы)
При составлении плана проекта важно уметь определять сроки и трудоемкость отдельных шагов. Могу порекомендовать несколько «фишек».
• Опирайтесь на возможности среднего участника Проектной группы (аналитика, моделировщика), найдите его, именно его нормативы закладывайте в основу и масштабируйте при необходимости.
Рис. 16. Пример Плана проекта совершенствования процессов в транспортной компании (2014–2015 годы)
Руководитель или эксперт в постоянном режиме может осуществлять надзор (планирование, контроль, вытирание соплей и обучение) над пятью (плюс-минус) членами группы. Если в ней большее количество участников, скорее всего, руководителю понадобится второй эшелон старших. Если меньшее – руководитель либо может работать на проекте part time (часть времени), либо частично выполнять обязанности рядового аналитика (обычно более эффективно, чем его подопечные, и не требуя надзора).
Бывший консультант (именно этого уровня, не ассистент и не стажер) приличной компании способен построить адекватную модель процесса «как есть» в течение суток. Если сотрудник не способен логически и/или алгоритмически мыслить, то эта работа может длиться долго и печально или закончиться внезапно. Положительные эффекты опыта работы в консалтинге рассасываются в процессе работы в реальном секторе. В то же время в среднем, по моему опыту, сотрудники клиента без опыта в консалтинге демонстрируют производительность около 20–40 % от соответствующей у консультантов. Однако встречаются и «выбросы», когда отдельные сотрудники и даже проектные группы клиента показывают очень высокий уровень.
Описание процессов «как есть» занимает в среднем столько же времени, сколько их анализ и проектирование процессов «как должно быть». Это связано с тем, что разобраться в реальной ситуации, особенно если эксперты по процессу чего-то опасаются или с трудом переходят на логический язык, – весьма непростое дело.
• Обязательно надо учитывать организационные задержки: время согласования и утверждения, время для организации и проведения Рабочих групп и т. п. Определите, в какие моменты это понадобится, и запланируйте соответствующие торможения. По возможности параллельно планируйте работы, которые от этих утверждений не зависят.
Упражнение
Участвовали ли вы в проектах совершенствования процессов? Какой план проекта использовался? Отличается ли он от описанного? Чем вызваны расхождения, если они есть?
2.3.3. Проекты реинжиниринга
Сегодня термин «реинжиниринг» используется очень часто. При этом в большинстве случаев неправильно, без понимания. Чего только не имеют в виду: и автоматизацию, и сокращение издержек, и ускорение процесса, и внедрение технологических решений, и повышение качества продукции, и просто некое «улучшение». Причем далеко не всегда использующие этот термин понимают, что в основе реинжиниринга должны лежать революционные идеи, кардинально меняющие бизнес. В итоге складывается впечатление, что реинжиниринг – это что-то почти повседневное.
Поэтому сразу договоримся о понятиях: реинжиниринг – это перепроектирование процесса при наличии в организации аналога или предшественника, когда прежние решения или подходы игнорируются. Понятно, что такое сложное решение стоит принимать только в том случае, если оно сулит существенный выигрыш, то есть если новый процесс радикально отличается от текущего. Именно поэтому существующий процесс надо игнорировать. И поэтому в основе решений в проектах реинжиниринга всегда лежит радикальное изменение процессов.
Для запуска проекта должна быть сформулирована задача, причем весьма амбициозная, которая не может решаться методом совершенствования. Процессы, которые мы выбираем для таких проектов, должны быть критически важными для компании, а также неудовлетворительными на данный момент. А важные процессы напрямую связаны с достижением стратегических целей. Значит, формулируя задачу на проект, надо внимательно посмотреть на цели компании – какими должны быть процессы, чтобы цель была достигнута? Уже перед стартом проекта мы должны понимать, что от нас требуются революционные изменения в процессе. Тогда же формируется Проектная группа реинжиниринга27.
Этап 1. Разработка концепции процесса «как должно быть». Можно выделить два фактора, которые используются в проектах реинжиниринга в качестве «паровоза» эффективности: информационные технологии (как правило, какие-то ИТ-решения) и новый взгляд на дизайн процесса. Если предполагается построить новый процесс на базе ИТ-решения, то, за редким исключением, оно известно еще до проекта. В этом случае правильнее говорить о проекте автоматизации, который реализуется в форме реинжиниринга, то есть без принятия во внимание процесса «как есть». Мы обсудим такой вариант проекта в главе 2.5. Классическим реинжинирингом можно назвать как раз поиск нового дизайна процесса, позволяющего сделать прорыв. На этапе 1 мы должны путем организации креативной коллегиальной работы найти идею, которую можно будет положить в основу решения. Хочу здесь напомнить, что идея может выходить (и чаще всего выходит) за рамки процесса, то есть является системной, затрагивает различные элементы системы управления.
Этап 2. Проектирование процесса «как должно быть» (см. параграф 1.3.4). Когда идея найдена, мы детализируем ее в первую очередь в части того, как будет выглядеть целевой процесс. Предварительно разрабатываем или уточняем Соглашения по моделированию. Нам подойдет тот вариант Соглашений, который впоследствии позволит разработать регламентные документы в корпоративном стандарте. В зрелой в части процессного управления организации такой вариант Соглашений уже наверняка есть и новая разработка не понадобится.
Этап 3. Разработка и утверждение Плана внедрения процесса «как должно быть». На этом этапе нужно разработать План внедрения нового процесса. В отличие от проектов совершенствования мы не применяем тут GAP-анализ, поскольку речь не идет о переводе текущего процесса в новое состояние. В то же время мы должны спланировать не только процессные, но и системные решения, которые выходят за рамки нового процесса. И наконец, важно предусмотреть контрольные мероприятия, позволяющие оценить получаемый эффект.
Масштабное и полноценное внедрение результатов «революционного» проектирования может вызывать значительные трудности. Поэтому зачастую применяется стратегия внедрения «гонка за лидером». Целевой процесс внедряется методом последовательных приближений, которые иногда называются релизами. Каждый из релизов можно при необходимости внедрять тремя стадиями (по М. Хаммеру):
лабораторная стадия – проверка жизнеспособности выработанных решений на моделях отдельных процессов;
пилотное внедрение – запуск нескольких процессов в ограниченном объеме, например в отдельных филиалах или дивизионах;
• тиражное внедрение – полномасштабное внедрение.
Этап 4. Реализация Плана внедрения процесса «как должно быть». Реализация Плана внедрения с постоянным контролем эффективности принятых решений может занимать довольно длительное время (по сравнению с проектами совершенствования). Например, согласно Т. Давенпорту28, на это должно уходить не менее года. Однако возможны ситуации, когда мы вынуждены возвращаться к этапу 1, если не удается решить поставленную задачу с помощью уже принятых решений. В частности, такую возможность допускает классик реинжиниринга М. Хаммер.
В литературе можно найти и другие планы проектов реинжиниринга. В чем заключаются их отличия? Рассмотрим наиболее часто встречающиеся.
Предпроектные шаги (постановка задачи, выбор процессов) включаются в план проекта. Такого подхода придерживаются М. Хаммер и Т. Давенпорт, например. Получается, что мы начинаем проект, даже не зная, в чем он состоит. Такой казус может извинить концепция Т. Давенпорта, который считает, что реинжиниринг – это часть комплексной программы совершенствования компании, включающей самые разные методы, подходы и решения. Но тогда и весь план проекта реинжиниринга надо рассматривать как неотрывную составную часть программы, во взаимосвязи с другими работами.
• В проект включается детальное изучение процесса «как есть». Методология Т. Давенпорта, например, предполагает детальное описание текущих процессов. Если делать это, не выпучивая глаза, то в среднем такая работа занимает девять месяцев независимо от размера компании. А мы помним, что собираемся заново перепроектировать процессы! Так к чему такие титанические усилия? Предполагается, что в этом случае мы хорошо поймем проблемы процесса. Но это же ведет нас не просто к потере времени и ресурсов, но к классической ошибке – попыткам вместо радикального переосмысления заниматься исправлением текущего процесса! Вообще же за реинжиниринг рекомендуется браться уже достаточно зрелым в процессном отношении компаниям – у них есть шансы на успех. В таких организациях имеющийся уровень понимания процессов вполне достаточен для того, чтобы адекватно поставить задачу. Компании же, которые даже МПВУ не имеют, практически со 100 %-ной вероятностью провалят проект реинжиниринга. Именно по этим причинам детальное изучение процесса «как есть» должно исключаться из плана проекта.
• Упор на информационные технологии (Р. Манганелли и М. Клайн29), которые считаются основным, если не исключительным, средством повышения конкурентоспособности.
В заключение – о риске реинжиниринга. Часто встречаю рассуждения, что речь идет не о риске, а об уровне квалификации и мастерства. Если знания и способности соответствуют требованиям, то и метод дает результат практически гарантированно. В этом есть некоторая доля правды. Однако, учитывая, что реинжинирингом пытаются заниматься компании самого разного уровня, можно указанные факторы вполне рассматривать как рискообразующие. Признавая справедливость утверждений о решающей роли уровня квалификации членов Проектной группы, тем не менее я констатировал бы, что как метод реинжиниринг – самый рисковый из методов трансформации, не в последнюю очередь из-за того, что масштабы его применения в отдельно взятом проекте при прочих равных весьма велики, затрагивают разные системы организации, а решения весьма радикальны.
Упражнение
Участвовали ли вы в проектах реинжиниринга процессов? Какой план проекта использовался? Отличается ли он от описанного? Чем вызваны расхождения, если они есть?
2.3.4. Проекты инжиниринга
Инжиниринг, несмотря на схожее с реинжинирингом название, преследует совсем другую цель: создать новые процессы, отсутствующие в настоящее время. Здесь не стоит дилемма, изучать или нет текущий процесс. Этого процесса просто нет. Такая задача возникает чаще всего у вновь создаваемых предприятий, а также у тех, которые достраивают свою систему управления либо довольно резко меняют стратегию или размах деятельности.
Во время предпроектной фазы, как и во всех проектах, ставится задача на проектирование нового процесса (как правило, создание работающего процесса, по возможности еще и отвечающего некоторым параметрам), а также формируется Проектная группа. Эти вопросы мы рассматривали в главе 1.3.
Сам План проекта такой же, как и в проектах реинжиниринга.
Этап 1. Разработка концепции проектируемого процесса. Как правило, на этом этапе либо ведется поиск прототипов процесса, к которым можно «привязаться», либо разрабатывается укрупненный замысел будущего процесса. Важно отметить, что нам годится не любой прототип, а только тот, который позволит решить поставленную задачу. В проектах инжиниринга этот этап – ключевой.
Этап 2. Проектирование процесса «как должно быть» (см. параграфы 1.3.2 и 1.3.3). Когда идея (модель-прототип) найдена или разработана, мы занимаемся ее детализацией и адаптацией, проектируем до необходимого нам уровня. Тут же, как и в проектах реинжиниринга, разрабатываем или уточняем Соглашения по моделированию.
Этап 3. Разработка и утверждение Плана внедрения процесса «как должно быть». Тут GAP-анализ попросту невозможен, так как нет исходного процесса. А поскольку нам не нужно разрушать старый процесс, то задача составления Плана внедрения упрощается: просто обеспечиваем все условия для запуска нового процесса.
В зависимости от масштабов решаемой задачи можно использовать различные стратегии внедрения, в том числе применять трехстадийный подход (см. параграф 2.3.3). Но ведь процессы инжиниринга бывают и весьма ограниченными по размаху (в отличие от проектов реинжиниринга), и тогда весь проект от начала до конца реализуется очень быстро.
Этап 4. Реализация Плана внедрения процесса «как должно быть». Реализация Плана внедрения в случае инжиниринга имеет особенность: мы должны контролировать в первую очередь работоспособность процесса. В небольших проектах это сложности не вызывает. Но если мы проектируем весь комплекс процессов, например, нового завода, реализуя стратегию вертикальной интеграции30, то такая задача может быть крайне сложной.
Упражнение
Участвовали ли вы в проектах инжиниринга процессов? Какой план проекта использовался? Отличается ли он от описанного? Чем вызваны расхождения, если они есть?
2.3.5. Проекты регламентации
Проекты регламентации относят к довольно простым. Действительно, задача трансформации здесь обычно не стоит, по крайней мере не является основной. Формализация процессов и разработка нормативной документации – вот главный фокус таких проектов.
План проекта регламентации похож на упрощенный План проекта по совершенствованию процесса. Как всегда, предварительно должна быть поставлена задача на проект и сформирована Проектная группа. Конечно, надо выполнить и прочие предпроектные процедуры.
Этап 1. Разработка Соглашений по моделированию. Нам необходимо, отталкиваясь от задачи проекта, определить, какая информация должна войти в регламентный документ, какие характеристики и составные элементы процесса нас интересуют с этой точки зрения. В зрелой в процессном отношении организации должны существовать стандартные Соглашения для таких проектов. Которые, впрочем, надо принимать во внимание и во всех других проектах, где в конечном счете предполагается регламентация. Это же касается и шаблона регламента. В самом первом проекте его придется разработать. Но это довольно редкая ситуация, обычно шаблон уже есть.
Этап 2. Моделирование текущих процессов. На этом этапе мы стараемся получить полное понимание того, как работает компания в настоящее время. Преследуя цель регламентации процессов, мы будем вынуждены в любом случае выносить суждения о том, какой вариант их исполнения «правильный» (одобряемый руководством), а какой – нет. Однако подчеркну: мы здесь не рассматриваем проекты, в которых ставится превалирующая цель совершенствования. И все-таки нам никуда не деться от так называемого light-совершенствования – технологии наведения порядка «навскидку». При этом мы должны помнить, что такие несфокусированные подходы могут нанести серьезный вред процессам31. Поэтому все решения следует принимать при условии «полной уверенности» в них. И для этого в ходе описания стоит делать локальную диагностику, хотя и без фанатизма, обсуждая самые очевидные и застарелые боли, решения по которым назрели и не требуют особых дискуссий.
Этап 3. Внесение корректив в текущий процесс и подготовка моделей для регламентации. В результате этого этапа мы должны получить процесс, который будет перенесен в регламент. Специального анализа тут не требуется, решения по корректировке должны быть очевидными или заключаться в выборе правильного варианта действий из имеющихся.
Этап 4. Разработка и утверждение регламента процесса. Довольно быстрый и простой этап. Используя шаблон регламента и подготовленные к регламентации модели, эту работу можно выполнить, что называется, «не включая мозги».
В принципе, на этом проект регламентации заканчивается, однако опционально в него включаются указанные ниже этапы, связанные с запуском регламента в действие.
Этап 5. Разработка и утверждение Плана внедрения регламента. Обычно план получается довольно простым, можно использовать GAP-анализ, в ходе которого мы сопоставляем текущий и регламентный процессы и планируем действия по трансформации одного в другой. Надо также предусмотреть ознакомительные, обучающие и контрольные мероприятия.
Этап 6. Реализация Плана внедрения регламента.
Упражнение
Участвовали ли вы в проектах регламентации процессов? Какой план проекта использовался? Отличается ли он от описанного? Чем вызваны расхождения, если они есть?
2.3.6. Некоторые часто встречающиеся вопросы и ошибки проектов трансформации
Ошибки отдельных этапов проектов трансформации мы рассматривали ранее (например, см. параграфы 1.3.5 и 1.6.4, а также предыдущие книги серии32).
Ошибка. Проект выполняется совместной Проектной группой консультантов и организации, но внутренние сотрудники «не забирают» технологию у внешних.
Чаще всего это вызвано тем, что такая задача считается как бы само собой разумеющейся и явно не ставится. Проектная группа компании в своем Плане работ (если он вообще есть, а группа не плывет, куда консультанты рулят) не имеет подраздела, посвященного именно освоению технологии во всех возможных аспектах. Иногда и консультанты не заинтересованы в передаче технологии. И тогда у внутренних сотрудников просто не получается ничего «забрать». Поэтому очень правильно, если процессные проекты на начальных этапах ведутся с участием консультантов, специально договариваться о такой задаче и с консультантами, и с внутренней группой. И выполнение ее надо специально отслеживать. Эти усилия однозначно окупятся.
Ошибка. Невнимание к терминологии.
Обязательно надо составлять и вести Глоссарий, содержащий как специфическую процессную терминологию, так и всевозможные внутренние термины. Вообще, организация, ведущая проекты в различных областях деятельности (даже если это только проекты оргразвития), должна иметь корпоративный Глоссарий и постоянно его пополнять и обновлять. То есть его действие не должно быть ограничено проектом. Эти усилия оказывают весьма благотворное влияние на рост квалификации и осмысленность работы сотрудников.
Где обучают специалистов по бизнес-процессам? Какое образование им нужно?
Сейчас курсы по бизнес-процессам читают на некоторых экономических и ИТ-факультетах/специальностях (общего правила нет, зависит от конкретного вуза и выпуска). Например, читают в ГУ-ВШЭ. Но пока качество такого образования не настолько высоко, чтобы быть определяющим. Поэтому самообразование на «правильных» курсах и семинарах и чтение «правильных» книг, а также опыт участия в таких проектах на месте работы могут быть даже более рациональной стратегией. Знание программного обеспечения (ПО) не является критическим. Во-первых, все быстро меняется, во-вторых, программ очень много. Надо понимать, что при необходимости что-то придется освоить. Есть распространенные программы, которые знать предпочтительно33. Очень помогает математический склад ума (скорее, способность логически мыслить). Вообще есть две специализации процессников (специалистов по процессам): управленческая и ИТ. ИТ фокусируется на ИТ-решениях и жизни процессов именно в системной части (то есть там, где процесс автоматизирован). Упор делается на программном обеспечении, кодировании, устранении ошибок в ИТ-решениях. Управленческая сосредоточивается на дизайне процессов, вопросах их эффективности в различных аспектах. Если специалисту удается охватить знаниями и умениями обе эти области, он действительно может быть отнесен к высококвалифицированным. Но таких немного.
Могут ли сами сотрудники описывать процессы? Как этого достичь?
Могут, конечно. Но для этого у них должны быть:
• интерес, мотивированность. Им зачем-то это должно быть нужно. Хорошо работает система мотивирования, в которой есть процессные показатели. Ну или хотя бы показатели, связанные с описанием. Если нет возможности подключить материальное мотивирование, следует использовать нематериальное, например силу убеждения заинтересованного харизматичного руководителя;
• умение. Надо научить сотрудников делать это правильно. Иначе безуспешные попытки быстро погасят энтузиазм;
• возможность. Нужно обеспечить сотрудникам возможность этим заниматься (время, софт, мобилизующие и поддерживающие оргмероприятия, обратную связь, поощрение успехов).
Это общие факторы. В конкретной компании/подразделении надо найти решение, как их обеспечить. Чаще всего квалифицированный заинтересованный руководитель способен это сделать. Поэтому можно сказать, что наличие такого руководителя и есть ключевой фактор.
Сколько в среднем по времени занимает описание процессов для логистической компании?
Описывать все подряд я бы не рекомендовал. Надо понять, какую задачу мы решаем, для чего нужно это описание. Для регламентов? Для совершенствования? Для автоматизации? Тогда можно выбрать наиболее эффективный и экономичный путь. Например, поставлена задача сократить время обработки заказа. Или повысить удовлетворенность клиента. В этом случае есть конкретная бизнес-задача с понятным измеряемым результатом. В то же время есть проверенная во многих проектах на протяжении многих лет цифра: описание всех процессов организации такими темпами, чтобы компании это было посильно (по бюджету и отвлечению сотрудников), от размера компании не зависит и составляет примерно девять месяцев. Такие проекты были в ходу в начале 2000-х, когда опыта и у бизнеса, и у консалтинга в области процессов было еще мало. Однако зачем это делать? В те годы мало кто отдавал себе в этом отчет. Но оценка верна до сих пор, и на нее можно ориентироваться при необходимости.
Самостоятельное описание процессов хуже, чем описание их же силами подрядной организации? Описывая процессы самостоятельно, компания только теряет время?
В большинстве случаев да, хуже. Опыта обычно нет, знаний маловато. Времени, конечно, уходит больше. Однако это не бессмысленный путь. Использовать результаты придется именно сотрудникам, так что рано или поздно им все равно надо через это пройти. Кроме того, сотрудники гораздо лучше знают и чувствуют процессы своей организации, работают с ними с большей ответственностью и энтузиазмом. Поэтому, приобретя нужную квалификацию, они имеют все шансы превзойти консультантов по эффективности и скорости работы.
Как организовать работы в небольшой компании, для которой совершенствование процессов стало насущной задачей?
Для компании численностью 50–300 сотрудников следует делать упор на самостоятельную работу. И получать точечные консультации от выбранного управленческого консультанта. Перед проектом трансформации надо вдумчиво поставить задачу и разработать проектный план. Подробно вместе с консультантом расписать ближайший шаг. Компания его выполняет, при необходимости обращаясь за помощью в сложных ситуациях. Потом детализируется второй шаг и т. д. Со временем набранный опыт позволит реализовывать проекты трансформации самостоятельно.