В своей предыдущей заметке про три горизонта повышения операционной эффективности я сделал вывод, что программа проектов (трансформация на примере складской логистики) должна быть поэтапной, с чётким определением объекта оптимизации. Это позволяет сформулировать параметры такого проекта: сроки, бюджет, рамки и ожидаемые результаты (эффект).

Дополнительно к этому я хотел бы сейчас остановиться на управлении объёмом изменений.

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

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

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

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

На первый план выходит скорость реализации изменений внутри организации.

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

Безусловно, это позволяет сократить срок реализации любого проекта трансформации и добиться быстрого эффекта. Иными словами, происходит повышение скорости внедрения решений.

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

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

Я полагаю, тому может быть целый ряд причин, например:

• Быстро внедряется более простое решение — доводить его до совершенства оказывается дороже, т.к. многих необходимых функций в нём изначально не предусмотрено.
• При быстром внедрении за скобками остаются фундаментальные проектные вопросы — последующее их решение требует повторных изменений уже ранее внедрённого.
• Участники проекта быстрого внедрения не обладают компетенциями за пределами MVP — развитие и совершенствование решений начинает идти бессистемно и вразнобой («лоскутная» автоматизация).

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

Ниже перечислены некоторые их эти принципов, которые стоит учитывать при планировании трансформации.

1. «Думать глобально, действовать локально» (как бы это ни было банально). Нельзя идти в трансформацию без стратегии. Все дальнейшие мероприятия (проекты) должны как минимум проверяться на соответствие утверждённой стратегии. Естественно, стратегия должна актуализироваться с такой периодичностью, с которой меняются условия для вашего бизнеса.
2. ФТ, а не ТЗ. В то время как при разработке технического задания выполняется проектирование будущего решения, функциональные требования лишь фиксируют внешние и внутренние условия для его разработки. В ФТ можно зафиксировать самый широкий перечень требований и расставить приоритеты, а ТЗ готовить небольшими пакетами (релизами), проверяя их на соответствие ФТ.
3. Выбирать решение «на вырост». Это больше касается выбора информационных систем. Даже если сейчас система удовлетворяет всем вашим требованиям, не факт, что она будет им удовлетворять через несколько лет. Имея хоть какую-то стратегию (п.1 выше), необходимо разработать максимально широкий перечень требований (п.2. выше) и выбрать удовлетворяющее им решение. При этом в MVP может войти всего 5-10% от затребованного функционала.
4. Учиться, а не учить. В проектную команду должны входить реальные эксперты по предметной области. Это могут быть ваши собственные сотрудники (в т.ч. бывшие), сотрудники подрядчика или приглашённые консультанты. Эти люди должны привносить в проект экспертизу и лучшие практики, сами вырабатывать решения и ставить задачи. В случае внедрения информационной системы исполнители не должны быть просто программистами.

Итак, подведём итог: чтобы проекты трансформации, включая внедрение ИТ-систем, соответствовали требуемой скорости изменений, они должны обеспечивать как высокую скорость внедрения решений, так и высокую скорость изменения уже внедрённых решений.