Статьи

Продолжает ли еще существовать такое понятие, как провал ИТ-проекта, в эпоху Agile-разработки, DevOps и новых методов управления? Увы, да.

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

Но сегодня провалы ИТ-инициатив отличаются от провалов прежних времен, так как Agile-методы, DevOps, непрерывная доставка и принцип мгновенной регистрации сбоя (fail-fast) изменили способы осуществления проектов. Современные итеративные методики управления призваны свести к минимуму шансы масштабных провалов, однако провалы по-прежнему происходят, причем по-новому и иногда даже с еще более неприятными последствиями.

Вот что думают эксперты о современном положении дел с провалами ИТ-инициатив.

История-предостережение

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

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

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

Этот провал – далеко не единственный. Согласно отчету Project Management Institute от 2017 года, подготовленному по результатам опроса 3 тыс. специалистов по управлению проектами, 28% стратегических инициатив, которыми они руководили, оказались абсолютно провальными. Примерно 37% опрошенных причинами провала назвали отсутствие четко определенных и достижимых вех и задач, используемых в качестве оценки степени завершения проекта. Далее в ряду причин шли нехватка информационного обмена (19%), отсутствие откликов от высшего руководства (18%), сопротивление сотрудников (14%) и недостаточное финансирование (9%).

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

Факторы, ведущие к провалу

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

В рамках исследования Global Digital IQ Survey, проведенного компанией PwC в 2017 году, были опрошены более 2 тыс. бизнес- и ИТ-руководителей, вопросы касались факторов, сдерживающих цифровую трансформацию. Около 64% опрошенных указали на отсутствие взаимодействия между службой ИТ и бизнесом, 58% – на негибкость и медлительность процессов, 41% – на отсутствие интеграции между новыми и существующими технологиями, 38% – на устаревшие технологии, а 37% – на недостаточную квалификацию проектных команд.

Между тем критерии оценки успеха или провала проекта расширяются, отражая значимость современных технологических инициатив. Так, в отчете PMI говорится: «Определение успеха сегодня меняется: большое значение приобретает то, удалось ли в результате осуществления проекта получить ожидаемые преимущества». К числу лидеров по уровню успеха авторы отнесли организации, которым удается 80% проектов завершать вовремя, в рамках бюджета и с выполнением первоначальных целей и задач бизнеса. В отчете также отмечается, что в таких организациях инвестируют в определенные области, такие как наем специалистов по управлению проектом с высокими лидерскими качествами, управление реализацией преимуществ, создание центров управления проектами и внедрение agile-методов.

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

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

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

Спасение – в Agile и автоматизации?

Некоторые тенденции, особенно переход на Agile и DevOps, помогают уменьшить вероятность глобальных провалов в современных ИТ-отделах.

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

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

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

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

Польза от неудач

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

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

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

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

Риск провала сохраняется

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

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

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

Как подчеркивают в PwC, в последнее время затраты бизнес-подразделений на ИТ растут быстрее, чем в самих отделах ИТ. Согласно исследованию PwC Global Digital IQ за 2015 год, 68% расходов на ИТ поступают не из бюджета ИТ-служб.

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

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

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

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

Следует также соблюдать предельную осмотрительность, поскольку в конечном счете в случае провала проекта, независимо от реальной причины, виновником неудачи будут считать службу ИТ.

– Mary K. Pratt. Why IT projects still fail. CIO. August 1, 2017

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

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

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

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

1. Тщательно выбирайте инструменты анализа Больших Данных

Многие технологические провалы объясняются тем, что компании покупают и внедряют продукты, не слишком подходящие для тех задач, которые они пытаются решить. При описании своих продуктов все поставщики с удовольствием оперируют терминами «Большие Данные» и «передовые аналитические средства», пытаясь извлечь выгоду из модных словечек.

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

Есть базовые моменты, которые присущи почти всем инициативам, связанным с анализом Больших Данных. Они касаются, например, преобразования данных и архитектуры хранения (Hadoop и Apache Spark). Вместе с тем в направлении анализа Больших Данных существует множество различных ниш, и конкретные продукты следует подбирать для ниш, соответствующих вашей технологической стратегии. К этим нишам относятся процессный анализ, прогнозная аналитика, решения, работающие в реальном времени, искусственный интеллект и инструментальные панели для бизнес-анализа.

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

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

Любой аналитический инструмент для Больших Данных требует разработки модели данных в базовой системе управления предприятием. Это самая важная часть проекта. Здесь необходимо обеспечить тесное взаимодействие системных интеграторов и экспертов основных подразделений. Выделите необходимое время и решите соответствующие вопросы в первую очередь.

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

2. Убедитесь в том, что инструменты просты в использовании

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

Выберите простые и эффективные инструменты для групп Data Discovery, а также для проведения анализа и визуализации.

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

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

3. Согласуйте проект – и данные – с актуальными потребностями бизнеса

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

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

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

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

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

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

4. Выстраивайте озера данных и не экономьте на пропускной способности

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

Однако одного лишь хранения еще недостаточно. Нужны средства управления различными типами данных, вписывающиеся в вашу концепцию анализа Больших Данных. Гениальное изобретение Apache Hadoop позволило хранить и получать представления огромных наборов разнотипных данных. Такие хранилища часто называют озерами данных. В озере данных находятся данные множества различных типов, поступающие из разных источников.

«Однако озеро данных не должно превращаться в свалку, – указал руководитель направления исследования компьютерных технологий Университета штата Аризона Джей Этчингс. – Необходимо найти разумные способы агрегирования данных и расширения их атрибутов. Данные могут быть разобщенными, но преобразование их для последующего анализа с помощью MapReduce и Apache Spark следует выполнять только с надежно выстроенной архитектурой».

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

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

Скорость особенно важна для выполнения анализа в реальном времени. И в этом смысле системы Больших Данных унаследовали тенденции маршрутизации трафика от социальных сетей. Так что выстраивайте свои озера данных на базе самых быстрых соединений.

5. Обеспечьте безопасность всех аспектов Больших Данных

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

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

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

6. Сделайте управление данными и их качеством своим главным приоритетом

Обеспечение хорошего управления данными и их качеством должно стать неотъемлемой составляющей всех проектов анализа Больших Данных – в противном случае вероятность неудачи сильно возрастет.

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

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

– Bob Violino. How to avoid big data analytics failures. InfoWorld. August 7, 2017

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

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

Преобразования для всех

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

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

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

О первых результатах этой работы рассказал старший архитектор ИТ-решений компании «КазМунайГаз» Максим Чикулин, он выступил на семинаре «Индустрия 4.0. Эволюция управления производством», организованном компаниями ITPS, OSIsoft и SAP.

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

Предварительная оценка

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

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

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

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

К новой архитектуре

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

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

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

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

О главной проблеме

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

«Главная проблема была в отсутствии единой достоверной, наглядной централизованной системы учета извлеченной нефти и сопутствующей продукции, которая охватывала бы весь процесс добычи – от цехов и АСУТП самого низкого уровня до аппарата управления», – поясняет Чикулин.

Производственная инфраструктура «ОзенМунайГаза» включает более 5 тыс. скважин, около 70 групповых установок, 14 цехов, очень сложную и часто перестраиваемую технологическую систему сбора и подготовки нефти. Исторически сложилось так, что системы бухгалтерского учета и системы для ведения счетов-фактур и договоров были внедрены на предприятии довольно давно, а основной продукт при этом учитывался «на коленке» – при помощи электронных таблиц и форм. На некоторых стадиях процесса обработки информации о добыче учет был вовсе не автоматизирован. А если где и автоматизирован, то примитивно – путем интеграции АСУТП с Excel-таблицами, не слишком приспособленными для этих задач.

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

В качестве платформенного решения для обновления учета был выбран продукт Tieto Energy Components «как лидирующее на рынке решение, активно поддерживаемое вендором».

Проект был выполнен в сжатые сроки, по всем правилам проектного управления, с документированием основных этапов. Вместе с тем внедрение не было автономным – новую систему учета привязали к архитектуре планируемых и существующих ИТ-компонентов компании. Работу по интеграции в существующий ландшафт проделали очень серьезную: элементы учетной системы были привязаны к 23 серверам АСУТП, объединенным в единую интеграционную шину PI System компании OSIsoft. Одновременно была создана единая производственно-аналитическая система, на базе которой планируется реализовать отчетность, утвержден план по дальнейшей интеграции различных систем.

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

Сейчас в «ОзенМунайГазе» готовят пятилетнюю программу дооснащения системами АСУТП узлов учета, ориентируясь как раз на результаты анализа узких мест

Полезный опыт – для всей страны

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

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

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

Миллениалы – люди в возрасте от 20 до 35 лет – занимают все больше рабочих мест по всему миру. По результатам исследования, проведенного в 2015 году американским Исследовательским центром Пью (Pew Research Center), к числу миллениалов относится по крайней мере один из трех работников. По данным PwC, к 2020 году половина мировой рабочей силы будет состоять из представителей этой демографической группы.

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

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

Социальные сети

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

Поставщик программного обеспечения для управления кадрами CareerBuilder провел исследование, в ходе которого были опрошены работодатели на территории Северной Америки. 37% из них полагают, что социальные сети являются одним из основных факторов, снижающих производительность работы. Социальные сети занимает четвертое место после мобильных телефонов и обмена сообщениями (55%), Интернета (41%) и разговоров на рабочем месте (39%). Три из четырех работодателей заявили, что из-за отвлекающих факторов в день теряется два часа и более.

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

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

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

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

Многоуровневая система безопасности – лучшая защита

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

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

Возьмем, к примеру, вопрос использования личных устройств на рабочем месте. Согласно исследованию, проведенному McKinsey, примерно в 80% организаций сотрудникам разрешено использовать личные устройства для подключения к корпоративным сетям. ИТ-отделам приходится реагировать на растущие требования сотрудников, касающиеся поддержки личных устройств с доступом к таким корпоративным приложениям, как электронная почта и календарь. Эта тенденция, получившая название концепции использования сотрудниками собственных устройств (Bring Your Own Device, BYOD), приводит к появлению новых угроз безопасности.

В частности, в обязанности директоров по ИТ входит обеспечение безопасности на уровне устройств. Первый шаг на этом пути – защита самих устройств посредством разработки определенной структуры межсетевых экранов, средств защиты от вредоносного ПО, решений для управления мобильными устройствами (Mobile Device Management, MDM) и путем обеспечения непрерывного внесения исправлений. Кроме того, с культурой BYOD связана такая угроза безопасности корпоративной сети, как взлом принадлежащих сотрудникам интеллектуальных устройств со слабой защитой паролем. В организации необходимо внедрить правила, требующие использования надежных паролей.

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

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

Контроль теневых ИТ-ресурсов

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

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

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

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

— Александр Мормуш, менеджер по работе с клиентами, Fortinet

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

Кто в компании должен заниматься работой корпоративного архитектора? Сейчас у вас в банке вы выполняете эту работу и одновременно являетесь ИТ-архитектором. Это нормальная практика?

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

Алексей Лебедев Возраст: 46 лет Послужной список: 2016 – настоящее время Ассоциация развития корпоративной архитектуры, президент 2015 – настоящее время Банк «Открытие», главный архитектор 2014 – 2015 Банк «Ренессанс Кредит», главный архитектор 2012 – 2013 ЗАО «Деловая среда» (дочернее общество Сбербанка), исполнительный директор 2010 – 2012 Сбербанк, корпоративный архитектор Образование: Тверской государственный университет, специальность «прикладная математика» Международный университет бизнеса и управления, экономический факультет, специальность «менеджмент» Фото: Дмитрий Демчев

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

В идеале какими полномочиями должен обладать корпоративный архитектор?

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

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

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

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

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

Идея корпоративной архитектуры не противоречит сервисно ориентированному подходу?

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

Какое место в корпоративной архитектуре занимает понятие «процесс»?

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

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

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

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

Главный научный сотрудник MIT Sloan Initiative on the Digital Economy Джордж Вестерман как раз один из тех, кто распознает цифровую трансформацию по ее «внешнему виду». «Цифровая трансформация имеет место, когда компании используют технологии, чтобы кардинально изменить эффективность или достижения предприятия, – пояснил он. – Ее движущими силами становятся разрушение устоев новичками рынка и инновации, с помощью которых конкуренты рассчитывают привлечь новых клиентов».

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

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

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

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

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

Цифровая трансформация или оптимизация?

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

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

Компания General Electric, со своей инициативой Промышленного интернета по продаже двигателей для локомотивов и реактивных турбин в качестве программного обеспечения, управляет трансформацией цифрового бизнеса. Смелая цифровая стратегия GE обусловлена тем, что компания, опасаясь разрушительных последствий от действий конкурентов, решила сама нарушить сложившийся порядок в своей отрасли.

GE входит в число тех 10% организаций, которые, по признанию Gatner, действительно проводят трансформацию. Остальные 90% занимаются оптимизацией цифрового бизнеса теми или иными способами. Она предусматривает использование цифровых инструментов для совершения рывков в производительности, наращивания доходов из уже существующих источников и улучшения восприятия со стороны клиентов. Результаты организованного Gartner в 2017 году опроса генеральных директоров компаний показали, что 42% респондентов планируют использовать цифровые технологии скорее для оптимизации, чем для трансформации своего бизнеса.

«Когда мы просим респондентов отвечать конкретно, выясняется, что речь идет о цифровой оптимизации», – указал Ле Хон. Компания Shake Shack, например, в этом году выпустила мобильное приложение, позволяющее оформлять заказы с мобильных устройств и тем самым сокращать время ожидания клиентов. Компания ServiceMaster внедрила мобильную платформу для улучшения связи между клиентами и исполнителями заказов.

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

Цифровая трансформация требует видения бизнеса

«ИТ-директора не в состоянии осилить цифровую трансформацию в одиночку, – заявил Вестерман. – Необходимо заручиться поддержкой какого-то иного влиятельного руководителя и получить одобрение совета директоров. На одной оси должны быть технологии, а на другой – умение предвидеть и непрерывно управлять происходящими изменениями. Объединив все это, вы получите компанию, которая держит свои цифровые технологии под контролем». По словам Вестермана, написавшего на эту тему книгу «Leading Digital: Turning Technology into Business Transformation» («Цифровое руководство: от технологий к трансформации бизнеса»), компании, контролирующие свои цифровые технологии, на 26% более прибыльны по сравнению с конкурентами из той же отрасли.

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

– Clint Boulton. What is digital transformation? A necessary disruption. CIO. July 31, 2017

В апреле Европейский парламент принял нормы Общего регулирования защиты данных (General Data Protection Regulation, GDPR). От бизнеса требуют обеспечить защиту персональных данных и конфиденциальности граждан Европейского Союза при выполнении транзакций внутри государств, входящих в ЕС. Вместе с тем GDPR регулирует пересылку персональных данных за пределы Евросоюза. Компании, ведущие бизнес в странах ЕС и обрабатывающие персональные данные их граждан, должны выполнить соответствующие требования к 25 мая 2018 года.

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

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

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

Статьи 6, 7 и 8: согласие. Обработка персональных данных должна осуществляться в соответствии с требованиями законодательства; каждый индивидуум должен дать согласие на использование его персональных данных. Собранные данные должны быть нужны для выполнения задач или транзакций, инициированных индивидуумом. Исключение составляют запросы органов государственной власти.

Статья 15: право доступа. Граждане стран Евроcоюза имеют право знать, какие персональные данные хранит компания, и как они используются.

Статья 17: право на забвение и уничтожение данных. Граждане стран Евроcоюза вправе требовать прекращения обработки и удаления их персональных данных по первому требованию.

Статья 20: право на перенос данных. Граждане стран Евроcоюза имеют право на перенос своих персональных данных из одной компании в другую по запросу.

Статьи 25 и 32: защита данных. Компании должны предоставлять гражданам стран Евроcоюза «разумный» уровень защиты данных и конфиденциальности. Что понимается под «разумным уровнем», неясно.

Статья 35: оценка воздействия. Компании должны проводить оценку воздействия защиты данных с целью выявления рисков для граждан стран Евроcоюза. В оценке необходимо указать, каким образом компания намерена управлять этими рисками.

Статьи 37, 38 и 39: ответственные за защиту данных. В некоторых компаниях необходимо ввести должность ответственного за защиту данных, который будет контролировать выполнение стратегии в области безопасности и соответствие нормам GDPR. Ответственный должен назначаться, если компания обрабатывает или хранит большие объемы данных о гражданах ЕС, обрабатывает или хранит специальные персональные данные, регулярно осуществляет мониторинг субъектов данных либо относится к органам государственной власти. По оценке Международной ассоциации специалистов в области конфиденциальности (International Association for Privacy Professionals, IAPP), в целом потребуется заполнить 28 тыс. таких вакансий.

Статья 50: международные компании. Международные компании, собирающие и обрабатывающие данные граждан ЕС, должны соответствовать нормам GDPR.

Статья 83: штрафные санкции. На компании может быть наложен штраф в размере 20 млн евро или 4% глобального годового оборота, в зависимости от того, какая сумма окажется больше.

- Michael Nadeau. What are the GDPR requirements? CSO. June 29, 2017

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

«Социальная аналитика (social intelligence) – это просто использование тех возможностей, которые вам уже предоставляют средства аналитической обработки данных социальных СМИ, – поясняет Дженни Сассин, вице-президент по исследованиям Gartner. – Это может быть базовая аналитика или более сложная, но ею почему-то не пользуются, хотя, казалось бы, сейчас это уже должно происходить».

Сассин приводит в пример производителя йогуртов, которому нужно найти рынок сбыта для продукта с новым вкусом: «Основные потребители йогуртов – женщины, но возможно, в компании хотели бы знать, что, к примеру, мужчины в определенном регионе, играющие в футбол, были бы не против попробовать “энергетический йогурт”». Это можно было бы выяснить с помощью серии запросов, сделанных посредством инструментов социальной аналитики, таких как Brandwatch, Crimson Hexagon, Synthesio или Talkwaker.

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

Социальная аналитика невозможна без человека

Брайан Лонг, старший менеджер Nissan North America по работе с клиентами в социальных СМИ, признает: несмотря на то что технологии играют большую роль в его деятельности, в компании все же не хватает средств автоматизации социальной аналитики – анализ постов, твитов и упоминаний бренда, которых могут быть миллионы за год, проводится вручную.

«Нужно, чтобы эту информацию читал человек, способный понять потребности клиента и спланировать реакцию компании», – подчеркивает Лонг. В Nissan шесть-восемь аналитиков просматривают данные, накапливаемые системой управления социальными СМИ Sprinklr, которая позволяет следить за корпоративными аккаунтами Twitter, страницами Facebook, Instagram и Google Plus. Именно аналитики, по словам Лонга, в конечном счете принимают решение о необходимости отреагировать: «Не обязательно обращать внимание на чьи-то одиночные жалобы, но вот если проблема достаточно распространенная, ответить придется».

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

Существующая в Nissan почти пять лет группа по работе с социальными СМИ при помощи Sprinklr классифицирует и размечает данные, помогая тем самым предоставлять практические знания бизнес-руководителям. Инструменты Sprinklr наряду с другими техническими средствами используются в компании для анализа и разрешения проблем. Аналитики готовят отчеты для отдела корпоративных коммуникаций, юридического и маркетингового. «Нам удается оперативно принимать продуманные решения, руководствуясь такими факторами, как тональность высказываний, объем откликов и авторитет пишущих», – добавляет Лонг.

Практическое мастерство и наука

Салли-Энн Камински, менеджер по стратегии социальных СМИ Zebra Technologies, – единственный сотрудник компании, обязанности которого целиком связаны с социальными сетями. Она считает своей задачей пропагандировать преимущества социальной аналитики в компании – производителе ноутбуков, сканеров, меток RFID и принтеров штрихкодов.

Когда в отделе обеспечения продаж просят сведения о потенциальных клиентах, Камински заходит в Oracle Social Cloud, инструмент управления взаимоотношениями с клиентами в социальных сетях, и создает информационную панель для специалиста по продажам. В Social Cloud выполняется поиск по ключевым словам и фразам, позволяющий обнаруживать тематическую переписку в Facebook, Twitter, LinkedIn, на форумах и в блогах.

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

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

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

Интеграция социальной аналитики с информационной инфраструктурой компании

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

Тем не менее в компаниях нередко просто «запихивают» данные социальных СМИ, например сведения о числе отметок «нравится», в BI-системы наподобие Tableau, вместо того чтобы использовать специализированные модули обработки такой информации, доступные в бизнес-приложениях Oracle, Salesforce, Microsoft Dynamics и других. В результате вся ценность информации социальных СМИ упускается.

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

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

Социальной аналитике нужны те же механизмы руководства, которые уже реализованы для систем CRM, ERP и пр. Аналитики социальных СМИ и специалисты по управлению данными должны взаимодействовать, осознавая, что информацией можно и нужно обмениваться для оптимизации принятия решений.

Выход социальной аналитики из-под крыла маркетинга

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

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

– Sandra Gittlen. Social intelligence: How to mine social media for business results. CIO. July 26, 2017

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

«Не надо суетиться с импортозамещением, оно может произойти естественным образом», – рекомендовал Олег Капитулов, директор департамента ИТ компании «Транснефть», на конференции «IT в ТЭК».

Незаменимых нет?

Главное преимущество «тяжелых» западных решений заключается в том, что единой платформой можно закрыть все потребности крупной компании. А значит, тогда имеет смысл внедрять эти продукты – например, альтернатив для SAP во многих отраслях нет. Если же внедряемый функционал относительно невелик, то преимущества SAP уже не столь очевидны: это дорогая во внедрении, сложная в эксплуатации платформа, а ее ежегодная поддержка обойдется в 22% стоимости лицензий. Зачем это нужно, если «1С» или собственная разработка может справиться с теми же самыми задачами? Проблема в том, что зачастую компании начинают заниматься тематикой SAP, не имея четких планов или просто отдавая дань моде.

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

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

«Задача планирования перекачки нефти довольно сложна, ее даже в SAP реализовать непросто. В мире не так много успешных внедрений. Возник вопрос: прибегать к помощи SAP как мирового лидера, имеющего опыт в этой области, или импортозамещаться, ориентируясь на отечественные продукты?» – вспоминает Капитулов. Примерно такое же положение с процессами техобслуживания и ремонтов оборудования (ТОРО), которые в «Транснефти» являются одними из основных. В объеме, необходимом нефтяным компаниям, его автоматизировать очень сложно. На 2012 год единственный пример реализации процессов ТОРО, и то с некоторыми оговорками, обнаружился лишь в Бразилии. Тем не менее лицензии SAP были приобретены, и компания начала проект, охвативший, помимо производства и ремонтов, финансы, склады, закупки, кадровые процессы и бизнес-аналитику. И если с «традиционными» модулями, по которым имеется огромный опыт внедрения, особых проблем не возникло, то наиболее рискованная часть проекта застопорилась.

«За два года потратили много средств на пилотный проект ТОРО. Я на протяжении месяца обсуждал функционал реализованного решения с бизнес-заказчиком и видел своими глазами, что люди не получили тот продукт, который им обещали», – признает Капитулов. Чуда не произошло: по большому счету, получилась заказная разработка, которая полного удовлетворения пользователям не принесла. И было понятно, что они должны будут сидеть до 10 вечера на работе, занося информацию в систему, а возможно – даже выходить на работу в выходные.

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

Игра платформ

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

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

«Если будет бухгалтерия на SAP, а ремонты на «Галактике», возникнет более 2 тыс. интеграционных точек, следить за которыми очень сложно. Получится крайне дорогое решение. Вспомнив, что в 80% дочерних структур прежде уже использовались решения «Галактики», поняли, что при добавлении к ним функционала ремонтов получится полноценный российский продукт», – отмечает Капитулов. Именно поэтому у компании возникла идея все же ориентироваться на российского производителя.

Разумеется, у «Галактики» есть серьезный минус: ее пока невозможно сделать централизованной. Системы будут локальными и будут между собой синхронизироваться. Тем не менее идут тесты на различных СУБД, и через несколько лет вполне возможной станет централизованная инсталляция «Галактики» даже в очень крупных компаниях.

Первый этап функционала ТОРО планируется запустить в январе 2018 года, а более развернутая функциональность ожидается к 2019 году. Если эти наработки войдут в стандартный функционал, то многие крупные и средние компании начнут воспринимать «Галактику» как очень серьезного игрока и реальную альтернативу SAP.

Создание российского конкурента

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

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

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

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

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

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

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

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

Для нас трансформация в первую очередь заключается в выводе на новый этап развития модели управления оперативным производством. С точки зрения ежедневной работы это более стандартизированные процессы, максимально автоматизированные, при этом не имеющие слишком жесткой логики, дающие возможность быстро адаптироваться. Что я имею в виду? Сама по себе способность производить и отгружать быстрее, выпускать все более сложные продукты – это относительно просто. Гораздо сложнее работать с минимально возможными объемами продукции. Здесь все упирается в себестоимость: если раньше небольшая партия при определенной цене была невыгодной и от ее производства могли отказаться, то сейчас надо сделать так, чтобы выполнять такой заказ стало экономически эффективно. Поэтому очень важным для нас стало решение о внедрении единой системы оперативного управления производством – MES-системы, которая заменит существующие сегодня цеховые системы. Единая платформа как раз и позволит нам производить продукцию, ориентируясь на индивидуальные потребности клиента, и  отслеживать всю цепочку – от запроса до отгрузки. Всё это в комплексе даст тот самый новый виток в развитии компании.

Фото: ОМК

Расскажите подробнее о технологиях, которые легли в основу цифровой трансформации ОМК.

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

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

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

Еще одна лаборатория занимается методиками Agile. Эти гибкие методы мы активно продвигаем не только в разработке ПО и управлении проектами, но и в повседневной операционной работе.

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

А как вообще пришло понимание того, что изменения нужны?

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

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

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

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

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

Какими способами вы «раскачиваете» специалистов предприятия, повышаете их информированность?

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

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

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

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

Фото: ОМК

Ваша дирекция уже давно издает собственный журнал – «Импульс», который недавно был переименован в «#Цифру». Какую роль он выполняет?

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

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

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

Я часто вспоминаю известный девиз Microsoft: «Меняйся, чтобы побеждать». На мой взгляд, он четко отражает суть того, что мы делаем. Меняем бизнес, меняем себя. Роль не только в поддержке бизнеса, но и в проведении изменений. Приходится играть гибридную роль, управляя не только ИТ, но и изменениями, и бизнес-процессами. Да, иногда сталкиваемся с противодействием, но в балансировке подобных конфликтов часто и заключается работа управленца.