Статьи

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

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

Дизайн-мышление и дизайн, ориентированный на человека

Дизайн-мышление тесно связано с дизайном, ориентированным на человека. Довольно часто эти термины считают взаимозаменяемыми. Специалисты же нередко спорят как о различиях между двумя концепциями, так и о той разнице, которую мы наблюдаем на практике. Некоторые эксперты, например, аналитик Gartner Маркус Блош, считают, что ориентированный на человека дизайн – это общий термин, за которым скрывается и дизайн-мышление. Если ориентированный на человека дизайн – это философия, которая ставит человека в центр цифровых решений и услуг, то методология дизайн-мышления вбирает в себя передовой опыт, используемый при создании таких решений.

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

С такой оценкой согласна и Шелли Эвенсон, управляющий партнер подразделения Accenture Fjord, оказывающего консультационные услуги в области дизайна. Дизайн, ориентированный на человека, подпадает под дизайн-мышление. «На самом деле это – одно и то же, – говорит она. – В обоих случаях различные аспекты антропологии, социологии и психологии используются для удовлетворения потребительских желаний».

Подход, характерный для дизайн-мышления

Дизайн-мышление представляет собой отказ от традиционного подхода, при котором управление процессом проектирования осуществляется сверху вниз. «В этом сценарии управление упрощает процесс создания цифровых продуктов, вывода их на рынок и разъяснения того, каким образом они позволяют решать те или иные задачи, – поясняет разработчик стратегии бизнес-дизайна компании Hitachi Vantara Джон Морли, занимавший ранее ведущие позиции в сфере дизайн-мышления в AppDynamics, Symantec и EMC. – При использовании дизайн-мышления движение идет снизу вверх. В разработке и совершенствовании продуктов принимают участие сотрудники на всех уровнях. Младшему персоналу присуще передавать информацию, почерпнутую из каналов обратной связи, тем, кто находится у руля, поскольку он располагается ближе к клиентам. При этом важно, чтобы менталитет разработчиков был ориентирован на конечный результат. Организация должна открывать и налаживать обратную связь на уровне восприятия идей. Людям нужно сосредоточиться не на своей роли в организационной структуре, а на достижении благодаря своим навыкам и умениям желаемого результата. У эффективного дизайн-мышления есть одна особенность: если оно не встроено в культуру организации, все закончится крахом. Планы организации должны быть ориентированы на клиента».

Принципы дизайн-мышления

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

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

Эвенсон, до своего прихода во Fjord занимавшаяся вопросами дизайна в Facebook и Microsoft, утверждает, что дизайн-мышление знаменует собой культурный сдвиг в «смене ожиданий», отражающих динамичность восприятия технических решений. Посмотрите на революцию, которую Apple совершила со своим «айфоном» и App Store десять лет назад. Люди стали требовать от любимых брендов отличных мобильных приложений. А многие сети быстрого обслуживания оснастили свои мобильные решения функциями оформления заказов и проведения оплаты. Шаги эти были продиктованы в первую очередь сменой ожиданий.

Поскольку технологии все сильнее вплетаются в матрицу бизнеса, даже традиционные компании рассматривают пользовательский опыт как ключевой фактор при выборе решений как для сотрудников, так и для клиентов. Значительная часть работы Эвенсон включает в себя беседы с ИТ-директорами и другими руководителями о построении программного обеспечения и сервисов сродни Amazon, Airbnb и других, воспринимаемых потребителями как создававшиеся для них лично. «Сегодня вы не можете позволить себе иметь корпоративный сервис, который не ставит вопросы удобства и желаний пользователя выше того, что можно сделать технически или имеет смысл с точки зрения удовлетворения собственных потребностей», – уверена она.

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

Передовой опыт дизайн-мышления

Дизайн-мышление требует изменения культуры. «Но у многих компаний, выдвигающих цифровые инициативы для трансформации своего бизнеса, дизайн-мышление все чаще становится частью корпоративных стратегических программ, – указывает Крис Пасьоне, основатель и генеральный директор LUMA Institute – центра обучения дизайну, ориентированному на человека. – Дизайн-мышление стимулирует инновации, поскольку компании ищут способы обновления, с тем чтобы поспевать за темпами происходящих вокруг изменений».

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

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

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

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

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

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

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

Чтобы не застрять в «средневековье», компаниям следует формировать культуру дизайна с привлечением дополнительных дизайнеров и созданием прототипов новых решений. «Смена ожиданий отражается как на предоставлении организациями своих услуг, так и на возможности их дальнейшего роста и процветания», – подчеркивает Эвенсон.

Подводные камни дизайн-мышления

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

«Большинству нравится определенность требований, которые, как ошибочно полагают люди, дают лучшее представление о том, каким должен быть конечный результат, – поясняет Эвенсон. – И хотя требования создают иллюзию безопасности, большинству организаций недостает мышечной памяти или навыков и компетенций для дальнейшего перехода к итерационным разработкам. Им не хватает воображения и творческого начала – умения взглянуть на вещи по-иному. А формирование подобных качеств сопряжено с немалыми трудностями».

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

«В своей эмпатии нам нужно продвинуться еще на шаг вперед, с тем чтобы понять особенности взаимодействия людей и систем, – резюмирует Эвенсон. – В дизайне важно не забывать как об этической стороне вопроса, так и о своей ответственности».

Бытует мнение, что в отличие от ряда «горячих» цифровых технологий ИТ-инфраструктура сейчас мало интересует управленцев. Для них она давно стала стандартным компонентом, обеспечивающим надежность ИТ-сервисов. Однако участники пленарной дискуссии, открывшей форум «Инфраструктура 2019» издательства «Открытые системы», убеждены, что это не так. «Можно говорить, что инфраструктура — это коммодити. Но когда с ней что-то случается, все верхнеуровневые приложения, аналитика и данные тоже не работают», — напомнил Вадим Гавриленков, руководитель департамента ИТ-инфраструктуры, «Почта России».

«Слово «коммодити» по отношению к инфраструктуре очень верно, если компании сосредоточены только на оптимизации затрат, — полагает Максим Петухов, ИТ-директор АО «Медицина» (клиника академика Ройтберга). — На более высоком уровне зрелости управления инфраструктуру следует воспринимать как драйвер развития бизнеса и находить для нее необходимые средства».

Максим Петухов: «Инфраструктуру мы всегда планируем с запасом, исходя из стратегии развития бизнеса, поэтому у нас всегда есть ресурс, важно его использовать по максимуму»

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

Современная инфраструктура должна отвечать главному требованию, которое предъявляет бизнесу цифровая среда, — становиться быстрее. Не случайно для крупных компаний модель «инфраструктура как код» стала определяющей. «Мы подходим к вопросам наладки оборудования и работы систем как к сервису, и программно-конфигурируемые решения для нас — одно из наиболее перспективных направлений. Программно-конфигурируемые сети и системы хранения, NetDevOps — не просто слова, а реальные инструменты, которыми мы пользуемся каждый день, они сплетают разработчиков ПО и инфраструктуру, раньше как раз этого нам не хватало», — говорит Наталья Ким, начальник управления инфраструктурных решений X5 Retail Group. «Самое сложное на пути создания инфраструктуры, отвечающей новым требованиям, — донести до бизнес-руководителей важность необходимых изменений», — отметила она.

Наталья Ким: «Программно-конфигурируемые сети и системы хранения, NetDevOps — реальные инструменты, которыми мы пользуемся каждый день»

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

Зрелая оптимизация

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

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

Риск и просвещение

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

Олег Коверзнев: «Инфраструктура — это фундамент. Если фундамент рассчитан на 'хрущевку', небоскреба на нем не возведешь»

Облачный рынок очень быстро растет, особенно сегмент РааS (платформа как сервис), и основная проблема, сопровождающая такой рост, — нехватка квалифицированных кадров, отметил модератор дискуссии Дмитрий Марков, директор по направлению «Информационная инфраструктура» в АНО «Цифровая экономика».

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

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

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

Операционная безопасность (Operations Security, OpSec) – процесс оценки и защиты организациями общедоступных данных о себе, которые при должном их анализе грамотным противником и объединении с другими данными позволяет получить общую картину, хранимую организацией в секрете. Дисциплина, имеющая военное происхождение, в цифровой век приобретает жизненно важное значение и для правительственных и частных организаций. Любому директору по безопасности следует задуматься о том, какие меры необходимо принять для совершенствования OpSec.

Термин «операционная безопасность» впервые появился в армии США во время войны во Вьетнаме в результате действий группы Purple Dragon. Там заметили, что противники США словно читают стратегию и тактику американских войск. При этом известно было, что Северный Вьетнам и Вьетконг не обладают силами и средствами, которые позволяли бы расшифровывать передаваемые сообщения. Не имелось у них и разведки для сбора информации изнутри. Таким образом, армия США сама непреднамеренно передавала врагу жизненно важные сведения. В Purple Dragon первыми предложили определение OpSec: «Умение держать информацию о своих силах и слабостях в тайне от враждебных сил».

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

Провалы OpSec

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

Начнем с событий, произошедших не так давно. В марте 2017 года, когда Джеймс Коми еще исполнял обязанности директора ФБР, автор публикаций в Gizmodo Эшли Файнберг сумела отследить его учетные записи в Instagram и Twitter, используя всего несколько бит общедоступных данных. Эта история стала классическим примером поиска ключей среди пользователей в социальных сетях. Файнберг знала, что сын Коми Брайен входил в спортивную команду колледжа Кеньон, и обнаружила видео с его участием в Instagram спортивного факультета университета. В одном из комментариев содержалась ссылка на личный Instagram Брайена. Воспользовавшись специально созданной для этого учетной записью, Файнберг отправила запрос на подписку, зная, что в ответ Instagram предоставляет учетные записи, связанные с тем аккаунтом, на который вы хотите подписаться. В данном случае речь шла о заблокированной учетной записи 'reinholdniebuhr', названной в честь теолога, которому была посвящена дипломная работа Джеймса Коми. Файнберг предположила, что это и есть аккаунт Коми. В Twitter оказалось всего несколько учетных записей с различными вариациями имени 'niebuhr', в том числе и запись @projectexile7, названная, судя по всему, в честь программы, направленной на снижение уровня насилия с применением оружия, в реализации которой в 1990-е годы Коми принимал участие. У @projectexile7 имелся всего один подписчик – блогер Бенджамин Уиттс, личный друг Коми. В октябре стало ясно, что выбранный Файнберг путь оказался верным.

Это прекрасный пример того, какие подсказки можно найти в социальных сетях – даже профессионалы в сфере безопасности не всегда понимают, какие следы оставляют за собой. В Facebook и других социальных сетях можно найти информацию, которая с военной точки зрения носит разрушительный характер. Например, несмотря на официальную позицию российских властей, в соответствии с которой повстанцы на востоке Украины действуют сами по себе, российские военные не раз размещали в Instagram фотографии с геотегами, подтверждающими их местонахождение по ту сторону границы. В похожей ситуации популярный фитнес-трекер Strava, загружающий данные в облако, разместил подробную карту маршрутов своих пользователей, проводивших беговые тренировки. А поскольку этот сервис пользуется особенной популярностью у американских солдат, изучение соответствующих карт позволило определить местоположение целого ряда секретных военных баз США.

Провалы OpSec на корпоративном уровне не наносят ущерба национальной безопасности, но могут иметь катастрофические последствия для связанных с ними компаний. Профессионалы в сфере OpSec рассказывают об обнаруженных ими проблемах в блоге Digital Guardian DataInsider. Так, Шай Бредеволд пояснил, как возникают утечки корпоративной информации: «Чрезмерно усердный сотрудник характеризует свою должность таким образом, что это позволяет узнать о пройденной им переподготовке, которая в противном случае была бы скрыта от глаз широкой публики. В женском форуме жены рассказывают о том, какую нагрузку испытывают их мужья в связи с готовящимся в следующем месяце выпуском нового концептуального продукта». Еще одним потенциальным указателем направления могут стать пароли: в условиях, когда бреши в системе безопасности веб-сайтов носят повсеместный характер, многие сочетания имен и паролей пользователей оказываются в общем доступе, чем с удовольствием пользуются хакеры, сравнивающие эти идентификационные данные с данными сотрудников компаний и пытающиеся задействовать полученные пароли в своих интересах.

Процедура OpSec

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

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

2. Определите типы угроз OpSec. Следующий вопрос, который нужно задать себе: кто является вашим противником? Их круг также может быть широк, начиная от преступных хакеров и заканчивая конкурентами в бизнесе. Учтите, что разных противников могут интересовать разные данные.

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

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

5. Составьте план OpSec. Располагая всей этой информацией, разработайте план, который позволит блокировать имеющиеся уязвимости и сохранить свои данные в безопасности.

Меры для укрепления операционной безопасности

Все вышесказанное звучит несколько абстрактно. А какие конкретные меры можно принять для реализации собственного плана OpSec? HackerCombat рекомендует придерживаться следующих рекомендаций.

— Внедряйте процедуры управления изменениями.

— Ограничивайте доступ к сетевым устройствам по принципу того, что «нужно знать».

— Предоставляйте сотрудникам минимально необходимые права доступа и придерживайтесь правила наименьших привилегий.

— Автоматизируйте операции для устранения слабых мест, обусловленных человеческим фактором.

— Планируйте ответные меры, которые необходимо принимать при возникновении инцидентов, и процедуры восстановления.

В материалах SecurityTrails описываются области, на которые должно быть ориентировано планирование OpSec. Естественно, в первую очередь вам хотелось бы сосредоточиться на важных персональных идентификационных данных, к которым относятся имена, IP-адреса, языки, электронная почта и т.д. Но нельзя забывать и о взаимодействии с людьми – в частности, с вашими собственными коллегами, для которых менталитет OpSec должен стать их второй натурой. Необходимо обучить их ряду приемов, связанных с шифрованием данных и устройств, мониторингом передачи данных и ограничением доступа к некоторым видам данных. Они должны быть осведомлены обо всех ошибках, которые мы упоминали ранее, особенно о тех, которые обусловлены активностью в социальных сетях. Лозунг времен Второй мировой войны «длинный язык корабли топит» в полной мере применим и к вашей сегодняшней организации (распространяясь и на сообщения в Facebook).

Кто осуществляет надзор за OpSec?

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

Некоммерческая организация Operations Security Professional's Association главной своей целью считает поддержку профессионалов в сфере OpSec. В публикациях из серии «Что работает в OpSec» обобщается накопленный в этой области передовой опыт, позволяющий оценить соответствующие карьерные перспективы и должностные обязанности. Некоторые направляют на OpSec всю свою энергию, тогда как для других это лишь одна из многих областей, к которым они проявляют интерес. Вам же нужно определить, как лучше претворить в жизнь концепцию OpSec в своей организации.

Chief data officer (CDO) — позиция относительно новая, но уже ставшая популярной в современных компаниях. От CDO ждут конкретных результатов здесь и сейчас. Однако на практике уровень ожиданий оказывается серьезно завышенным. Сегодня становится очевидно: необходимо внедрять специальные инструменты искусственного интеллекта (ИИ), без которых ни один CDO не сможет справляться с возложенными на него обязанностями.

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

Gartner прогнозирует, что к 2021 году CDO в 75% компаний крупного бизнеса станет позицией уровня mission-critical — наравне с ИТ-директором, а также с руководителями финансового и операционного блоков. Однако на практике результаты работы CDO скорее разочаровывают, поскольку не приносят видимого внятного результата. Люди на этой должности в крупных организациях часто меняются, не оправдав ожиданий. Почему так происходит?

Кто виноват?

Во-первых, компании продолжают смешивать две роли — CDO и CDS (chief data scientist), перед которыми стоят совершенно разные задачи. Chief data scientist занимается собственно изучением данных, извлечением из них ценности для бизнеса — тем, что называется монетизацией данных. Задача же «классического» CDO — организовать управление жизненным циклом данных так, чтобы информация нужного качества и в определенном виде предоставлялась нужному адресату (включая CDS) вовремя по всей организации.

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

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

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

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

Что делать?

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

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

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

То есть ИТ для ИТ появились и успешно развиваются, а аналогичных по качеству ИТ для CDO пока нет. Хотя основные игроки сообщают, что Data Governance 3.0 есть в их дорожных картах. Оговоримся: инструменты для управления потоками данных и контроля их качества, ведения бизнес-глоссария и пр.  существуют. Но, во-первых, между собой они зачастую плохо интегрируются, а во-вторых, они «заточены» под работу с нуля, причем при условии, что она ведется правильным образом: «мы начинаем все описывать, и постепенно формируется единое поле активов под управлением со всеми связями и т. д.».

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

Чем же ИИ так хорош?

Высокая отдача ИИ применительно к задачам CDO обусловливается общей «заточенностью» искусственного интеллекта под решение проблем без заранее известных четких правил. ИИ может обучиться им сам. Компьютер в этом плане обладает необходимым уровнем самостоятельности, находит закономерности и совпадения — либо невидимые человеку, либо обнаруживаемые только в результате вложений тысяч человеко-часов. Если нужно в короткие сроки (а CDO сегодня работают в постоянном цейтноте) понять, как данные о клиенте из 10 разных систем соотносятся с одним и тем же объектом, то искусственный интеллект справится гораздо эффективнее человека. Например, в разных системах одной компании клиент может проходить под разными обозначениями — client, customer, shopper и пр., человеку требуется время, чтобы при классификации данных понять, что речь идет об одном и том же объекте. Машина всё сделает (после определенного обучения) практически мгновенно.

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

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

Как правило, CDO приходит в организацию с готовой проблематикой и от него ждут результатов работы не позднее чем через 6–7 месяцев. Чтобы уложиться в эти сроки, CDO хотя бы на 50% нужно быть искусственным интеллектом, опираться на эффективные ИИ-инструменты в своей работе.

Перспективы и результаты

Пять лет назад было принято начинать работу с людей: выделить штатную единицу, поставить цели, определить критерии оценки и т. д. Сейчас фокус резко сместился на поиск «правильных» подходов. Чем заниматься CDO в компании, перед кем отчитываться о результатах, с кого спрашивать — в целом ясно. Остается вопрос: каким образом ему достичь результатов в короткие сроки?

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

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

Без ИИ соответствующей работой должно было бы заниматься целое подразделение из нескольких сотен человек. С ИИ 80% работ выполняется в автоматическом режиме, тем самым экономятся колоссальные средства и время.

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

Автор — Лариса Малькова, управляющий директор Accenture Russia, член экспертного совета CDO Award. 

На форуме ITMF 2019, проведенном издательством «Открытые системы» в начале июня, одной из обсуждаемых тем стало управление проектами цифровизации; речь шла как о «классике» и Agile, так и о гибридных подходах к реализации проектов цифрового предприятия. По мнению некоторых докладчиков, проблемы «цифровых» проектов носят системный характер — такие проекты существенно отличаются от обычных, с которыми привыкли иметь дело, поэтому и управление требуется иное.

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

Таня Милек: «В эпоху цифровой трансформации изменения должны реализовываться не проектами, а портфелями, состоящими из программ и проектов»

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

«Гибридный подход — это как индивидуальный пошив костюма. И мы такой 'костюм' для нашего бизнеса сшили: решаем задачи бизнеса несколькими проектными методологиями», — подчеркнула Милек. Она уверена, что, задействуя одну лишь методологию, цифровизацию компании обеспечить невозможно – ни с помощью традиционных подходов, ни по Agile. В «Русагро» во всех проектах используется несколько методологий, они действительно гибридны: например, один этап может быть реализован по Scrum, а остальные вполне могут быть классическими.

«Крупная компания не может жить полностью по Agile, ей придется быть гибридной, чтобы сохранять устойчивость. Но какая-то ее часть обязательно должна быть гибкой, чтобы иметь возможность экспериментировать», — отметил Олег Егоркин, agile-коуч «Ростелекома». Именно такой подход на протяжении пары последних лет реализуют в компании.

Олег Егоркин: «В изменении корпоративной культуры очень высока роль менеджеров среднего звена, суть работы которых в условиях Agile радикально меняется»

Согласно исследованию, проведенному VersionOne, больше всего внедрению практик Agile мешает сопротивление организации любым трансформациям. В любой организации существует своего рода гомеостаз – стремление живых систем противостоять изменениям и сохранять постоянство. Более того, как ни парадоксально, порой agile-команды весьма холодно воспринимают новшества, хотя сама суть Agile подразумевает обратное. Часто в организации продолжают существовать структуры и практики, препятствующие изменениям. Например, может оказаться, что работа команд оплачивается «по старинке» — позаказно.

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

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

Риски: неопределенность и масштабы

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

«Практика показывает, что внедрение сложных, комплексных систем не приносит ожидаемых результатов. Такие решения — своего рода антидепрессант для риск-менеджера: они создают обманчивое впечатление, что все под контролем», — сказала Крухмалева. По ее словам, западные продукты, направленные на управление проектами, можно сравнить с «Боингом», приобретенным по частям: стоит столько же, но не летает. В «Газпроме» выстраивают систему управления рисками на базе отечественного решения RiskGap, и оно показывает неплохие результаты.

Яна Крухмалева: «Внедрение комплексных систем управления рисками не дает ожидаемых результатов, хотя и оставляют обманчивое впечатление, что все под контролем»

Павел Алферов, профессор бизнес-практики МШУ «Сколково», представил модель сложности проектного управления на основе известной методики Goals-and-methods Matrix. Ее доработали, добавив еще один фактор – сложность проекта. Показателей сложности в случае цифровой трансформации может быть четыре: масштаб проекта, неопределенность требований к результату, неопределенность технологий и критическое влияние внешних факторов.

Традиционно самый больной вопрос, по мнению Алферова, — это именно неопределенность требований: компании не всегда понимают, что хотят получить на выходе. Еще один, весьма острый для России вопрос, – влияние внешних факторов. Но при цифровой трансформации чаще всего имеют место техническая неопределенность в пилотных проектах и масштабность работ при дальнейшем развитии проекта.

С марта в Утконосе появилась должность Chief Data Officer. Компания считает использование данных во всех бизнес-процессах важным шагом на пути к цифровой трансформации и централизует свои усилия в этом направлении. Мы встретились с Данилой Наумовым, директором по данным онлайн-гипермаркета Утконос, в рамках SAS Forum Russia 2019. Он рассказал о стратегии компании на пути к «цифре», о первых шагах в новой должности и планируемых изменениях в работе с данными.

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

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

А какие еще преимущества могут дать компании сервисы, основанные на данных?

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

Все это — внутренние истории. Возможно ли что-то, нацеленное вовне?

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

Существовала ли до вас в Утконосе должность директора по данным?

Такой должности не было. Но уже функционировал аналитический центр, который занимался BI-функцией, его начали формировать с лета прошлого года. Прежде аналитическая работа велась разрозненно: в каждом бизнес-подразделении были собственные аналитики. Аналитический центр был создан с вполне понятной целью — объединить аналитиков из разных подразделений, чтобы ликвидировать дублирование отчетов. Понятно, что в разных подразделениях аналитики зачастую занимались схожими задачами. Кроме того, параллельно велось несколько проектов, связанных с прогнозированием спроса и построением системы автозаказа. В этих направлениях были существенные наработки. Требовалось их развить и добавить в число используемых технологий машинное обучение и другие современные методы. И поэтому в Утконосе появился директор по данным.

Что появление этой должности фактически означает для компании?

Наша компания идет по пути цифровой трансформации, и мы разделили ее на три составляющих. Первая — переход от традиционной иерархической структуры к продуктовой структуре. Мы создали множество продуктовых команд, в них входят представители бизнеса, data science, бизнес-аналитики, ИТ (ее инфраструктурной части). Вторая составляющая трансформации — привлечение талантов извне, третья — использование данных во всех бизнес-процессах. Все решения должны приниматься на основании данных, а не экспертных мнений. Позиция человека должна подкрепляться объективными цифрами. Моя должность объединила три функции: BI-практику, развитие хранилища данных (data engineering) и применение продвинутой аналитики (data science) в бизнес-процессах. Функции data engineering и data science изначально входят в мою зону ответственности, эти функции мы выстраиваем с нуля. А аналитический центр раньше подчинялся директору по стратегии. Директор по стратегии решил поставленные задачи, должность упразднили и было принято решение функцию BI тоже отдать мне.

Вы пришли в компанию несколько месяцев назад. Какие задачи были поставлены перед вами?

По каждому из трех направлений передо мной поставлены вполне конкретные задачи. На аналитике по-прежнему лежит в первую очередь функция автоматизации отчетности. В data science главные направления, по которым мы начали работать, — это прогнозирование спроса для операционного блока и регулярное ценообразование для коммерческой дирекции. Что касается хранилища данных, то мы приступили к выбору СУБД, средств интеграции данных и уже вплотную планируем построение самого хранилища данных. Хочу отметить, что в отношении выбора инструментов для реализации проектов никаких «религиозных» предубеждений у нашей команды нет. Руководство компании мыслит категориями бизнес-кейсов и финансовых эффектов. Если мы понимаем, что у какого-то конкретного продукта стоимость владения существенно привлекательнее, чем у конкурентов, то наш выбор склоняется в сторону именно этого продукта. Еще одной ключевой составляющей для нас является скорость решения задачи. Например, мы вполне обоснованно выбрали коммерческую аналитическую платформу и отказались от стека решений open source. Важную роль при этом сыграл показатель time to market — время, которое потребуется, чтобы решенная задача начала приносить прибыль.

Как могло отсутствовать направление data science в электронной компании с такой историей?

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

Местные аналитические отделы будут упразднены? Как сейчас осуществляется взаимодействие с ними?

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

С чего началась работа в новой должности?

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

Что сейчас представляет собой часть ИТ-ландшафта, ориентированная на работу с данными? Какие платформы и решения применяются, каковы планы на будущее?

Разумеется, у нас есть множество источников данных: ERP, WMS, веб-сайт, система управления перевозками, BI-инструменты и аналитические решения SAS. Кроме того, есть инструменты, используемые бизнес-блоками. Мы проведем трансформацию хранилища данных и построим озеро данных. Планируем предоставить инструменты подготовки данных бизнес-пользователям, чтобы наиболее продвинутые могли не только смотреть отчеты, но и проверять собственные гипотезы, выстраивать модели данных. У нас есть пользователи, которые готовы так работать и ждут, когда возможность для этого у них появится.

Используются ли в компании большие данные, и если да, то в каких целях?

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

Насколько эффективно используются эти данные?

Довольно эффективно. Можно ли их использовать еще эффективнее? Безусловно, да.

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

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

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

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

Появления каких новых «умных» сервисов могут ждать ваши клиенты в обозримом будущем?

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

Как скоро появится возможность «залезть к клиенту в холодильник» — поставить там камеру и реализовать сервис автозакупок?

Технически это вполне можно реализовать уже сейчас. Но потребуются как минимум серьезные инфраструктурные вложения и доработка некоторых «юридических моментов».

В конце марта этого года X5 Retail Group объявила о внедрении системы управления ИТ-мощностями. Автоматизация процессов, спроектированных на базе методик ITIL, помогли реформировать управление ИТ-инфраструктурой, состоящей из 173 тыс. конфигурационных единиц в трех дата-центрах и более 14,5 тыс. магазинов (сейчас уже более 15 тыс. магазинов – Н.С.). Как результат, за прошедший год расходы на закупку оборудования удалось сократить более чем на 300 млн руб. О реализации проекта в рамках форума «Инфраструктура 2019», который 18 июня проведет издательство «Открытые системы», расскажет Наталья Ким, начальник управления инфраструктурных решений ИТ X5 Retail Group.

- Как исторически в X5 управляли инфраструктурой? Какие были проблемы?

По сути управления как такового не было. Скорее это был учет инфраструктурных мощностей, размещенных в ЦОДе, который велся вручную в Excel. При этом невозможно было оценить критичность каждой конкретной единицы оборудования, их взаимосвязи с ИТ-системами. В компании порядка 300 ИТ-систем и изменения в конфигурациях инфраструктуры происходят ежедневно. Мы не знали достоверно, какая из систем сколько ресурсов потребляет, реальную загрузку оборудования с учетом индивидуального режима функционирования каждой ИТ-системы. Увеличение мощностей происходило реактивно – например, при снижении производительности приложения мы просто срочно добавляли ему ресурсов. Если такие были в резерве. Если нет – инициировалась длительная закупка. Иногда владелец системы мыслил проактивно и, зная о планируемых изменениях в ней, заранее заботился о добавлении ресурсов, основываясь на собственной экспертной оценке.

Далее так продолжаться не могло – ИТ-ландшафт развивается серьезными темпами, что влечет за собой огромные затраты на инфраструктуру. Возникла необходимость качественно, на год вперед прогнозировать потребность ИТ-систем в мощностях, чтобы их закупка была экономически оправданной и эффективной. ITIL как раз об этом.

- В чем заключался переход на методику ITIL, как он был произведен?

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

- Как в общих чертах это все работает?

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

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

- Планировалось ли изначально автоматизировать работу по новой методологии, или эта идея пришла уже в ходе проекта?

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

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

- Что сейчас представляет собой система управления ИТ-инфраструктурой? Из чего состоит, какие решения используются?

Построенное нами решение состоит из четырех важных компонентов.

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

- Какой достигнут бизнес-эффект и за счет чего?

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

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

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

- Как определяется оптимальный размер резерва?

Резерв формируется исходя из статистики запросов бизнеса за предыдущий период. Она обновляется раз в квартал и, в зависимости от полученных показателей объёма тактического резерва мощностей, динамически меняется.

- Что внесло больший вклад: «наведение порядка» по ITIL или автоматизация процессов?

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

- Есть ли планы по развитию управления инфраструктурой?

Реализованный нами проект пока касался только виртуальной инфраструктуры. В ближайшее время мы планируем охватить ИТ-системы, размещенные на контейнерной платформе и физической инфраструктуре, в том числе, платформу больших данных.

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

В АО «Медицина» (клиника академика Ройтберга) стремятся использовать весь арсенал информационных технологий для повышения клиентоориентированности бизнеса. Это стремление находит отражение и в инфраструктурных проектах. О самом последнем из них Максим Петухов, ИТ-директор АО «Медицина» (клиника академика Ройтберга), расскажет на форуме ИНФРАСТРУКТУРА 2019, которую издательство «Открытые системы» проведет 18 июня. А пока он ответил на несколько вопросов CIO.ru.

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

- Клиника создавала инженерную и ИТ-инфраструктуру с запасом, но мир с каждым днем меняется все динамичнее. Хватает ли сегодня того «запаса», чтобы поддержать дальнейшее развитие бизнеса?

Бесконечный запас расширения создать невозможно, он ограничен средним временем жизни технологий. Если для софта можно все время поддерживать актуальную версию, то «железо» однозначно стареет.

Тот запас, который мы закладывали при проектировании инфраструктуры, по-прежнему играет свою роль. Мы спокойно увеличили там, где нужно было, количество компьютеров, которые подключаются к проводной сети. Возможности, которые были заложены в ЦОДе по размещению оборудования, нас устраивают.

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

И мы очень внимательно следим за сервисным обслуживанием оборудования ЦОДа, которым занимается внешний подрядчик. Возникающие небольшие проблемы устраняются как можно быстрее, это и служит залогом долгого срока службы.

1.  
2.  
3.  
4.  

Пред.След.

Года через три потребует замены система охлаждения. Тут мы рассчитываем на новый ЦОД в нашем онкологическом центре, который сейчас строится в Химках. Он будет аналогичен по возможностям нынешнему ЦОДу, и мы получим географически распределенную, отказоустойчивую и даже катастрофоустойчивую инфраструктуру. Все информационные системы, которые сейчас работают на оборудовании действующего ЦОДа, смогут мигрировать и продолжить работу там. Эта мера позволит установить новое оборудование, провести модернизацию системы охлаждения, замену стоек. Инфраструктурные возможности нового онкологического центра будут служить всей клинике в целом. При его проектировании мы закладываем возможности расширения и плавной замены ИТ-оборудования.

- Как часто бизнес ставит перед ИТ-службой клиники задачи, требующие модернизации инфраструктуры?

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

Только предусмотрительность, проявленная при проектировании, позволяет пользоваться плодами инфраструктурных проектов на протяжении длительного времени.

- Какими подходами вы руководствуетесь в управлении инфраструктурой? Много ли внимания вы ей уделяете?

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

Мы используем две системы мониторинга. Первая, приобретенная вместе с сетевым оборудованием Hewlett-Packard, служит для его мониторинга, контроля изменений конфигураций. Вторая, Zabbix, более универсальна и позволяет отслеживать параметры всего оборудования и информационных систем. Недели не проходит, чтобы мы не ввели в нее какой-то новый параметр или сценарий работы оповещений. Это та система, которую мы все время наращиваем.

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

- Какие технологические тенденции с вашей точки зрения важно учитывать при планировании развития инфраструктуры? Облачные технологии, гиперконвергентные, микросервисные архитектуры, что из них вы примете во внимание?

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

Поэтому при внедрении новых систем и попытке сократить затраты на действующие мы исследуем и проводим расчеты для всех современных технологий. Облака — одна из них. Пока мы не увидели такого предложения, которое позволит сэкономить существенные средства: повторюсь, в клинике построена очень серьезная инфраструктура, многое сделано с запасом. Нам не интересно брать вычислительные мощности из облака, потому что выгоднее загрузить свои. Но мы присматриваемся ко всему, и одно из интересных перспективных направлений — возможность долговременного хранения зашифрованных резервных копий информационных систем, а также данных систем видеонаблюдения, которые занимают очень большой объем, и архивов медицинских исследований — КТ и ПЭТ/КТ. То есть тех данных, которые можно спокойно перенести «на холод», так как даже ленточные накопители требуют определенных параметров хранения: влажности, температурного режима.

- Что вы расскажете участникам конференции «Инфраструктура» и что вам самому будет интересно?

Сосредоточусь на проекте обновления сети Wi-Fi. Интересно, что немаловажную роль в принятии решения об этих инвестициях сыграли пациенты, высказав свое мнение, которое утвердило нас в необходимости этого проекта. Это важно для ИТ-директоров и для владельцев бизнеса.

Мне на конференции будет интересно подтвердить свой опыт и расширить свои знания. А также увидеть, как другие компании применяют технологии, к которым мы относимся осторожно из-за крайне серьезного подхода к защите персональных данных. Посмотреть на удачный опыт коллег по переносу в облако сервисов с учетом всех аспектов защиты персональных данных и удобства доступа внешних и внутренних заказчиков, по модернизации ЦОДа c использованием гиперконвергентной архитектуры. Это очень полезно, чтобы мы могли учиться не только на своих ошибках.

Faberlic – российская косметическая компания, работающая по модели прямых продаж, одна из самых крупных в мире – в 2017 году в мировом рейтинге компаний, ведущих бизнес по этой модели, Faberlic занимала 38-е место. Представительства Faberlic открыты в 20 странах, с компанией сотрудничают более миллиона консультантов, ее продукцией пользуется около 8 млн потребителей.

Активно развивающийся бизнес Faberlic требует и соответствующей ИТ-инфраструктуры. При реализации новой версии основной учетной системы в компании взяли за основу облачную микросервисную архитектуру. Почему именно ее, как осуществляется проект и какие еще задачи в Faberlic доверяют облакам, рассказал Валерий Капленко, директор по ИТ компании. А на форуме ИНФРАСТРУКТУРА 2019, который издательство «Открытые системы» проводит 18 июня, о деталях использования облаков и гибридной инфраструктуры в Faberlic можно будет узнать от CTO компании Романа Варникова.

По словам Валерия Капленко, активно развивающийся бизнес Faberlic требует и соответствующей ИТ-инфраструктуры; при реализации новой версии основной учетной системы в компании взяли за основу облачную микросервисную архитектуру

- Расскажите о бизнесе компании, какие требования он предъявляет к ИТ-инфраструктуре?

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

Наша учетная система создавалась, когда у компании было 200 маленьких складов. Для каждого такого склада велась небольшая база данных на Oracle Express, информация из этих баз собиралась и реплицировалась в центральную базу данных.

Это был не очень эффективный подход. Наши дистрибьюторы объединены в так называемое MLM-дерево (Multi Level Marketing), и продажа в конце «ветки» дерева, скажем, в Монголии, влияет на бонусы дистрибьютора, который является «наставником» этой ветки. Такую информацию необходимо собирать онлайн; в первоначальной же версии системы это делалось путем закачки файлов, а репликация работала не всегда, иногда приходилось использовать почту для обмена данными.

Поэтому было решено создать систему, которая объединила бы все данные о маркетинговых бонусах всех консультантов во всех странах, где работает Faberlic. Такая система разрабатывалась около десяти лет полностью on-premise на основе базы данных Oracle с надстройкой в виде веб-клиента.

Переход на эту систему упростил открытие новых точек выдачи, привлечение новых консультантов. Но и бизнес компании сильно изменился. C распространением Интернета и различных средств электронных коммуникаций стала очевидной потребность покупателей самостоятельно оформлять заказы. Если раньше консультант должен был очно встретиться с клиентом, проконсультировать его, принять и реализовать заказ, то теперь такое общение может происходить по Skype или по телефону, а при желании клиент и сам может заказать все, что ему нужно, и в некоторых странах доставку берет на себя компания.

Со сменой бизнес-модели вместо 200 маленьких складов мы получили 20 больших, а вместо десятка тысяч консультантов заказы стали оформлять 2,5 млн человек по всему миру. Прежняя архитектура оказалась неадекватной требованиям бизнеса. Попытки спасти ситуацию закупкой дополнительного оборудования результата не дали.

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

- В чем основные особенности новой архитектуры?

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

Компания выбрала облако Oracle Cloud, поскольку предыдущая версия основной учетной системы реализована на базе решений Oracle, и у нас большой опыт работы с продуктами этого вендора и его партнерами.

- Почему именно микросервисы, что дает такой подход?

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

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

И в-третьих – гибкость. Реализуя большую систему, ИТ-директор должен определять приоритеты разработки, оценивая, какая функциональность более критична, обещает большую прибыль и т.д. Бизнес готов инвестировать в ИТ, когда это касается конкретного проекта. Скажем, подразделение продаж не будет вкладываться в полную переделку системы ЕRP под свою задачу, но пойдет на разработку определенного сервиса, помогающего решить эту задачу в необходимые сроки.

Пример для нашей системы – подключение службы доставки. Микросервисная архитектура позволяет создать для этого отдельный сервис, подключить его через механизм Discover API и быстро начать с ним работать. Такая гибкость очень важна для бизнеса.

- На какой стадии находится переход к микросервисной архитектуре?

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

Облачная архитектура микросервисов – часть большого проекта обновления корпоративной системы «Партнер 2.0», в который входит также фронт-офисная часть на SAP Hybris, разработка мобильного приложения и другие взаимосвязанные компоненты.

- Микросервисы в Oracle Cloud – не единственный облачный компонент ИТ-инфраструктуры компании?

Мы любим облака и работаем с разными их вариантами. Мы первыми в России развернули в Microsoft Azure бизнес-приложение в стадии эксплуатации – BI-систему, которую продолжаем развивать на облачной платформе. Есть свое частное облако, для ряда проектов используем публичные облачные сервисы «Ростелекома».

- Стыковка многочисленных облаков не создает проблемы?

Это сложная, интересная и многогранная задача, которая возложена на наше инфраструктурное подразделение.

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

Проекты цифровой трансформации, безусловно, имеют свою специфику – не случайно во многих случаях у компаний возникают серьезные затруднения с ними. Некоторые даже отказываются от проектного подхода при проведении цифровой трансформации. Тем не менее, как уверен Павел Алферов, профессор бизнес-практики Московской школы управления Сколково, именно проект остается самым универсальным управленческим инструментом. В ходе выступления на конференции ITMF-2019 он представит российскую модель сложности проектов и поговорит о решении типичных трансформационных проблем.

- Чем отличаются проекты цифровой трансформации от прежних, «традиционных»? Какие наблюдаются проблемы?

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

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

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

- Какие новые навыки и знания могут понадобиться руководителям таких проектов?

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

Однако планировать все-таки необходимо. Наиболее ярые сторонники Agile считают, что в отсутствие «хрустальных шаров» будущее предсказать невозможно, поэтому и планировать далее, чем на пару недель, смысла нет. Разумеется, есть и более взвешенные точки зрения. Я остаюсь сторонником планирования, но планировать надо сценарно, с вариантами на все случаи развития событий. Важно иметь не только план «А» или «B», но и план «Z» – на случай полного провала.

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

В случае взаимодействия с внешним контуром – например, если затрагиваются интересы клиентов или партнеров – тема усложняется формальными, юридически значимыми обязательствами. Внутри компании можно договариваться и передоговариваться, а иногда все может свестись к силовому решению генерального директора. Здесь важно умение не только договориться, но и зафиксировать договоренности.

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

- Вы упомянули несколько видов рисков. Какие из них можно назвать самыми значимыми?

Каждый из факторов сложности проектов – большое количество участников, длительность, неопределенность требований и технологий – несет свои собственные риски, и их сложно ранжировать. Более того, методы работы с каждым из рисков известны, другое дело – обратит ли на них внимание руководитель проекта и будет ли пытаться минимизировать их? Займет ли он проактивную позицию, пытаясь предотвратить негативные последствия, или будет бороться с ними по факту?

- А есть ли вещи, которые становятся проще?

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

- Что руководителям проектов надо делать по-новому? Какие варианты уже точно «не прокатят»?

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

- О чем вы планируете рассказать в ходе своего выступления на ITMF 2019?

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