Wanted: моментальный проект
30.05.2019
Wanted: моментальный проект
Потеев Павел Михайлович, ведущий эксперт Центра подготовки руководителей цифровой трансформации ВШГУ РАНХиГС
Петров Михаил Викторович, Директор Департамента цифровой трансформацииСчетной палаты Российской Федерации
Авторы хорошо помнят время, когда компании работали по трех-пятилетнему стратегическому циклу «из учебника»: определение стратегии, детальное планирование, потом исполнение, и, в завершении, подведение итогов. И так в цикле на несколько лет. Иногда, в пределах цикла делались несколько корректировок.
В этом же цикле и в привязке к стратегии «крутились» операционные планы и проекты, реализуемые в рамках этих планов.
Уходящий контекст
Подход к разработке проектов автоматизации, основанный на waterfall, вбивали в головы в институтах, закрепляли в ГОСТах и корпоративных стандартах управления проектами. Будущее казалось полностью планируемым, понятным, дробимым на осязаемые промежуточные этапы, тщательно сформулированные по всем правилам SMART.
Начнем сразу с главного: таких пяти- и даже трехлетних бизнес-стратегий уже нет. Есть «векторы развития», которые определяются не только видением будущего компании ее руководством, но и технологическими трендами, экономикой и политикой, тенденциями отрасли. Руководители создают и корректируют дорожные карты онлайн. «Если вот это будет так – пойдем туда, если это будет по-другому – пойдем сюда, через неделю собираемся и смотрим куда же все идет». Вариативность нарастает, число слоев сумрака множится. Бежать, а потом развернуться и бежать в противоположную сторону – становится нормой.
Сказать легче, чем сделать. Инерция дотащила «Титаник» до айсберга при том, что его винты крутились в противоположную сторону. В организациях инерции бывает еще больше – присмотритесь, и вы увидите, как политики, стратегии подразделений, процессы, системы показателей, бонусные планы – все это связывают организацию десятками нитей (точнее – цепей), и при этом все эти элементы необходимы для повседневного функционирования.
До какой-то степени ускорению изменений помогает начавшееся с девяностых упрощение оргструктур: большинство нынешних передовых по части структуры организаций — это сверхкомпактный центр и горизонтальное масштабирование в бесконечность.
Для организаций, структура которых все еще похожа на острую пирамидку (не выполнен de-layering то есть уменьшение числа организационных уровней) есть серьезный повод задуматься.
Кстати, центральным драйвером перехода к таким плоским структурам стали развитие ИТ-систем и коммуникаций (заметим, что они же, во многом, движут изменениями и сейчас – через новые механизмы, такие как технологические стартапы и отраслевые платформы).
Организационные структуры, формальные должностные обязанности, знания и компетенции сотрудников, регламенты, governance models, схемы коммуникаций, настроенные в ИТ-системах основные и вспомогательные процессы – все это помогало компаниям работать эффективно и с минимумом сбоев.
И это же – а сейчас особенно – блокирует внедрение изменений.
Классическая «накопленная» автоматизация тоже стала, как ни странно, «тормозом коммунизма» – корпоративные ИТ-монстры зацементировали процессы, отучили думать (что там думать – «нажми кнопку раз, распечатай отчет два, отнеси начальнику три»), изменения в них занимают месяцы и годы (как в том классическом анекдоте про программиста – «только ничего не трогай, только ничего не меняй»).
Набор самых лучших ИТ-систем, который еще вчера поддерживал рост, развитие, эффективность организации, в определенный момент становится тормозом развития, стеной, об которую разбиваются попытки что-то поменять («Да вы что? За неделю перенастроить закупочную процедуру с новыми формами документов? Знаете, в сколько модулей надо внести изменения? Приходите через пару месяцев. А завтра ТЗ принесите. Не принесете завтра? Ну, когда принесете тогда про сроки и поговорим»). Очень явно это было выражено, например, в такой интересной организации как Оргкомитет Олимпиады Сочи 2014 года, структура и процессы которого «планово» менялись каждые полгода-год в соответствии с этапом развития и подготовки к Играм. Внедренная на заре жизни Оргкомитета в рекордные сроки (3 месяца) ERP система дала огромный эффект в прозрачности, подконтрольности всей деятельности. Но уже через год стало понятно, что если и дальше наращивать функции на той же платформе, то рано или поздно ситуация придет к тому, что все обратно уйдут в Excel, поскольку потребности организации обгонят темп развития ERP. Ситуацию спасло решение наращивать функционал единого информационного пространства путем пристыковки к нему отдельных сторонних модулей, разрабатывать и запускать которые получалось существенно быстрее и проще отдельно, нежели осторожно менять огромную единую систему, постоянно контролируя ее целостность и работоспособность.
Тропы и ловушки
Как проводить изменения? Одна из современных стратегий – создание внутренних зон greenfield, в которых создаются новые модели ведения бизнеса и новые системы поддержки этих моделей. Старые системы и модели продолжают эволюционировать вместе с соответствующими им технологиями и экономическим укладом, обеспечивая при этом поток наличности. Получается нечто вроде би- и тримодальной модели, в которых операции, изменения и прорывные инновации организации разнесены организационно на run (ежедневная деятельность), change (непрерывные изменения и улучшения), disrupt (разработка радикально иных способов ведения деятельности и получения дохода). Такое деление оправданно: есть люди типа operations, есть люди типа development – и они разные как по управленческим и личностным компетенциям, так и по драйверам.
Одна из типичных ошибок– проектировать цифровые изменения, полностью игнорируя физический мир. Пример: хочешь построить безлюдный свинокомплекс – проектируй его безлюдным с самого начала. Объедини в единый план архитектуру, оборудование, коммуникации, системы. С банком дело обстоит так же. Хочешь сделать банк-сервер без офиса с гранитными колоннами – проектируй сразу без гранита. Но так получается не всегда.
Иногда к нам приходит вопрос: да, это верно для организаций, которые находятся «в цифровом авангарде» - телеком, ритейл, те же банки, а что насчет традиционных индустрий?
Такое заблуждение подвело многих. Навскидку назовем «Додо-Пиццу», которая с самого начала спроектирована как кибер-физический организм, в котором целые процессы вынесены в цифру и онлайн.
А теперь плохая новость для поставщиков ИТ-решений. Сценария для «Додо» не нашлось ни у кого из них, и доля добавленной стоимости осталась внутри компаний. Тенденция: таких, как «Додо» становится больше. Это уже не тревожный звонок для интеграторов, это сирена.
Происходящий на наших глазах сдвиг затронет поставщиков ИТ-систем и сервисов самым непосредственным образом. Когда к нам приносят водопадные планы проектов с результатом в третьем квартале будущего года – накатывает чувство тоски, смешанное с желанием взять мегафон и доходчиво заорать: «Уважаемые! Мир поменялся, процессы, масштабирование, изменения, а также ваше чудесное решение нам нужны не через три месяца, не через две недели, а сейчас, самый край – к ланчу в пятницу».
Иногда приходится, вспомнив навыки, делать это «завтра» реальностью самим и структурировать «моментальные проекты».
Отсюда вывод и следствие для тех, кто «делает поставку» (delivers) ИТ. Для поставщиков, как внутренних, так и внешних. Ваши методологии, концепции, agile, PMBOK, ITSM и ITIL, водопад – это никого не интересует и никому не важно. Аббревиатуры не создают конкурентное преимущество.
От исполнителей и от методологий востребованы, прежде всего:
1. Мгновенное и недорогое прототипирование, тестирование бизнес-кейсов. Не «взлетел» прототип – отбросили и двинулись дальше. Но – в рамках все той же динамической дорожной карты развития предприятия;
2. Очень быстрое развертывание, масштабирование, изменение, встраивание в существующие архитектуры. И, возможность такого же быстрого свертывания.
Требования к непрерывности, операционной эффективности, безопасности никто не отменял. Извольте балансировать, господа архитекторы, CIO, CTO и далее по списку. Кстати, на нашей памяти есть кейсы, когда быстрое развитие ИТ клало на бок основные процессы организаций, включая, cash generation zones. Судя по тому, что авторы этих ситуаций не были уволены, руководители бизнеса понимают неизбежность сбоев. Хотя, и нервничают, и ругаются. Иногда нецензурно и на самых разных языках. Но такой сейчас мир – ради скорости изменений, захвата новых сегментов иногда жертвуют качеством, устойчивостью и т.п.
|
Обязательно предусмотреть «переиспользования» результатов, если организация развернулась и побежала в другую сторону. Чтобы сделанное не пропало. Хотя зачастую стоит и выбросить то, что уже сделано.
ИТ-поставщикам необходимо пересмотреть многое на всех уровнях их работы. Коммерческое предложение, где будет 2 месяца на обследование, 3 месяца на настройку, 2 месяца на тестирование и подготовку к запуску, вполне возможно, уйдет в корзину непрочитанным.
3. Оргструктура: не делить sales and delivery на части, а, наоборот, соединить их в совместную разработку решений. DevOps forever. Интеграция ИТ в бизнес и бизнеса в ИТ. Программисты катают тесто в пиццерии (Додо), АСУТПшники выращивают кур, разрабатывая решения по управлению производственным процессом на птицефермах. Соединить это на уровне людей – ключевая проблема. Обычно есть «креативщики», движки, моторы преобразований. И есть – «операционщики-функционеры», призванные заставить нормально работать процессы и регламенты (так или иначе, без них никуда). Видимо, вызов в развитии пресловутых soft skills – прежде всего на стороне «операционщиков», чтобы они могли быстрее менять милый их сердцу «порядок».
4. Шаблоны проектов: перейти от традиционного «стадия за стадией» к работе по нескольким стримам, в которых все происходит одновременно и взаимосвязанно. Да, будут ошибки. Да, их будет больше. Но в ситуации стремительно меняющегося окружения оказывается, что лучше делать ошибки – но двигаться быстро, быстро же их исправляя, чем делать все правильно – но плестись в арьергарде. «На круг» перфекционизм оказывается дороже – первые собирают все сливки и стремительно уходят вперед.
5. Компетенции руководителей проектов: оркестрирование безумием идей и их «носителей», «здоровый авантюризм» - способность рискнуть, довериться интуиции, отойти от шаблона проекта, разработанного десять лет назад и сделать совсем по-другому. Говорить с клиентом не в терминах трех-четырехбуквенных аббревиатур, а на языке тех enterprise capabilities, которые станут залогом его успеха завтра. Развернуть бизнес в новом регионе за месяц, пятикратно масштабировать сервис, полностью автоматизировать набор повторяющихся процессов.
6. Компетенции консультантов и специалистов – готовность исследовать и впитывать новое, постоянно обучаться, не с периодичностью раз в год, а сделать это частью жизни.
7. Управление жизненным циклом ИТ-решений и сервисов в целом. Поставщикам придется смириться с тем, что их не покупают навечно, даже не на 3-5 лет. Даже не «смириться» - радоваться этому. Отсюда ценность мгновенно- и быстроразворачиваемых решений. Не успел к новому проекту нарастить необходимые заказчику компетенции – заказчик не будет ждать и уйдет к другому.
Многое будет по-другому
Важное для внутренних и внешних ИТ-провайдеров: бизнес-руководители озабочены поднятыми в тексте вопросами в очень серьезной степени. В чем это выражается?
-
Раздражение и разочарование ИТ-поставщиками, приносящими инновации вчерашнего дня, либо инновациями через два года. Выражается в уходе в in-house ИТ. Хотя и in-house ИТ не панацея – вопрос, насколько вы завязаны на «накопленное ИТ» и на людей, которые его делают?
-
Понимание того, что операционные менеджеры не всегда в состоянии предложить и внедрить инновационные сценарии. Частично это обусловлено инерцией мышления, частично – тем, что у них в жизни и так все неплохо. До вытеснения инновациями. В управленческой практике это выражается в поиске (реже – создании внутренних) стартапов, хоть и лишенных финансовых ресурсов большой организации, но и лишенных также ее инерции.
А хорошая жизнь любого в организации никогда не длится вечно. Чувство успокоенности вполне может закончиться в тот момент, когда за спиной раздастся синтезированный голос: «мне нужны твое рабочее место, твои деньги и трудовая книжка». От этого не застрахован никто – включая boardroom members.
В любой хаос можно внести элементы управляемости. Как бы ни менялась стратегия - покупаемся, продаемся, работаем в том или в этом регионе – всегда можно выявить список enterprise capabilities, которые при любом раскладе будут работать на цели организации. Примеры – capability в области реализации программ и проектов, управления сервисными операциями или приобретения и быстрой интеграции компаний. Задача корпоративного центра – выявлять эти capabilities, «упаковывать» их в процессы и ИТ-системы и, при необходимости, быстро развертывать где необходимо и в любом необходимом масштабе.
Задача компаний, которые предоставляют ИТ-сервисы, реализуют проекты и желают преуспеть, либо хотя бы успеть – ровно такая же: предлагать ИТ для завтрашней организации сегодня.
Возврат к списку