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

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

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

  • Понятие ИТ-риска безусловно корректно с терминологической точки зрения, его часто выделяют содержательно. Впрочем, некоторые считают, что в реальных ситуациях не имеет практического смысла пытаться обособлять ИТ-риски и управлять ими изолированно.
  • Степень понимания бизнесом разных ИТ-рисков не одинакова. Директор департамента внутреннего контроля и управления рисками компании «Энергостройинвест-Холдинг» Константин Рычагов в одном из наших материалов отметил, что, например, понятие обеспечения непрерывности бизнеса (business continuity) сам бизнес трактует однозначно, подразумевая при этом комплекс организационно-технологических мер по борьбе с риском остановки бизнес-процессов. А вот риски смены лицензионной политики использования ИТ-продуктов для бизнеса не всегда очевидны. «Если мы говорим о нарушении лицензионных соглашений, то бизнесу далеко не ясны ответы на вопросы, что будет, если такое нарушение выявится. И кем оно будет обнаружено, как фиксировать факт обнаружения, — поясняет он. — Для бизнеса не так просто положить на одну чашу весов тот же лицензионный риск использования программных систем, а на другую риск сокращения портфеля заказов, скажем, на двадцать процентов. И руководителей здесь вполне можно понять». Такая неоднозначность (это, кстати, не единственный пример) особенно важна в ситуации кризиса и возможной смены приоритетов в стратегии использования бизнес-систем.
  • Искажение управленческих моделей, нарушение баланса мотивации, полномочий и ответственности в трехстороннем отношении «бизнес — ИТ-департамент — поставщик ИТ-решения» является первопричиной зарождения большинства рисков. Об этом мы тоже говорили не раз и весьма подробно. Последствия реализации таких рисков невозможно исправить технологиями, поэтому приоритет правильного выстраивания этого «треугольника» приобретает сегодня еще большую важность, чем раньше.

Сложнее, чем модульный принцип

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

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

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

По поводу сопутствующей инфраструктуры снова оттолкнемся от наших предыдущих публикаций. Например, Артем Натрусов, вице-президент компании ЕВРАЗ по информационным технологиям, в своем интервью обозначил такую точку зрения: продукты «1С», даже достигнув вполне адекватного уровня по функциональным возможностям, явно проигрывают SAP ERP и другим крупным международным решениям в отношении культуры поддержки жизненного цикла информационной системы. «Cами решения этой компании (“1С”. — Прим. ред.), как мне представляется, за последние годы существенно выросли, — утверждает он. — Но даже при большом количестве партнеров среди них не находится тех, кто обладал бы зрелыми методическими разработками и богатой практикой крупных внедрений». Надо сказать, что с тех пор ситуация изменилась и наиболее крупные российские интеграторы обратили на решения «1С» серьезное внимание, в том числе именно в связи с перспективами импортозамещения. Но если рассматривать ситуацию в целом, относительно замены традиционных программных решений крупных мировых производителей на системы отечественных компаний, похоже, что проблема стоит и сейчас.

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

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

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

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

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

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

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

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

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

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

Из всего вышесказанного можно предложить следующее резюме.

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

Факторы снятия напряженности

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

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

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

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

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

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

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

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

  • API Economy. Означает новые возможности развития ИТ-систем (а значит, и экономики), обусловленные практической значимостью интерфейсов прикладного программирования, которые добавляются к любой тиражируемой бизнес-системе и к любым программным разработкам корпоративного уровня, — в том числе и тех, что заменяют собой функции продуктов, традиционно реализуемых в аппаратном исполнении.
  • Agile. Концепция построения информационных систем, делающая акцент на способности оперативной трансформации целей разработки, на гибких коммуникациях участников проектной команды по всему жизненному циклу создания ПО и на возможности генерации частых релизов бизнес-систем.
  • Непрерывная интеграция (Continuous Integration, CI) и непрерывное предоставление (Continuous Delivery) ИТ-решений. По сути является развитием принципов Agile применительно к созданию информационных систем корпоративного уровня. Проповедует принцип «сверхоперативной» (как минимум ежедневной) актуализации исходного кода вплоть до версий, находящихся в коммерческой эксплуатации, и дает практические инструменты и рекомендации для достижения этой цели. Таким образом, становится возможной фактически непрерывная модификация ИТ-решений и их интеграция между собой.
  • DevOps (development & operations). Концепция, предполагающая совершенствование идей Agile, CI и CD и обеспечивающая активное участие бизнеса в проектах создания корпоративного ПО, включая как операционных руководителей бизнеса, так и его владельцев.

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

Материал Сергея Костякова комментирует Роман Корешков, руководитель проектов дирекции развития технологий группы компаний CUSTIS

Управление рисками автоматизации

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

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

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

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