Хабрахабр

Управление рисками на ИТ-проектах: что поменялось за последние годы

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

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

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

Что поменялось за последние 10 лет в ИТ-проектах?

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

Сейчас этап автоматизации классических бизнес-функций подходит к концу: ERP, CRM, BI и прочие инструменты управления бизнесом уже оцифрованы. Раньше CIO занимались автоматизацией бизнес-процессов компании и обеспечением стабильной работы своего зоопарка систем. Важнее Time-to-value, Time-to-market, ROE, непрерывность и кибербезопасность. Просто наличие автоматизации — это уже не конкурентное преимущество. Скорость вывода продукта на рынок, обеспечение бесперебойного доступа к сервисам и их защищённость — основной фокус сейчас там.

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

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

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

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

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

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

…Сроки реализации проектов уменьшаются, а темп растёт

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

В чём здесь основная сложность? Настоящим вызовом для проектной команды становится управление требованиями и ожиданиями заказчика. Зачастую бывает так, что к концу проекта набор требований абсолютно «перпендикулярен» тому, что было на старте. Проекты всё чаще стартуют с минимальным набором требований, которые непрерывно уточняются и дополняются в процессе всей реализации проекта. Я не раз наблюдал, как заказчик только к середине проекта, а иногда и к его концу, наконец (!) осознавал, а что он хочет на самом деле.

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

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

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

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

Кадры как базовый риск

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

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

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

В такие моменты обычно спасают две важные вещи:

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

Консерватизм заказчика

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

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

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

Продуктовая самоидентификация рынка

Если вы посмотрите отчёты ведущих аналитических агентств, то увидите, что только 15% современных инновационных ИТ-проектов признаны успешными! Почему так происходит?
Всё чаще проекты на стороне заказчиков инициируются под действием маркетингового прессинга со стороны вендоров, а также в погоне за пресловутыми конкурентами, которые уже внедрили себе что-то такое новенькое и поспешили известить об этом рынок в бесчисленных пресс-релизах. На всех конференциях и форумах мы слышим: «BigData — must have», «blockchain — наше всё», «IOT — в каждый дом» и много чего ещё…

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

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

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

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

Регуляторика

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

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

Яркий пример — прохождение сертификации PCI DSS.
Или ещё пример — определение, что же такое персональные данные для вас.

Классическое проектное бюджетирование

Давайте вспомним, как происходит бюджетирование у большинства заказчиков (госов вспоминаем отдельно и в ярких красках). Бюджет формируется в начале года, защищается на УК (или в других инстанциях) и часто даже не пересматривается. Когда мы перейдём к реализации, возникнет основная дилемма — какую схему оплаты выбрать. Схема работы «fix scope — fix price», её ещё называют «Fixed Fee», не очень устраивает исполнителя, т. к. требования нечёткие, вариативность большая, а бюджет фиксирован. Возникают огромные риски промахнуться с бюджетом.

С одной стороны, невозможно говорить о финансовом планировании, если ты не знаешь стоимость реализации (процедурные ограничения внутри), а с другой — у заказчика часто не хватает опыта для «отруливания» такой схемы. Схема «Time & Material» часто даже неприемлема для заказчика. Для госсектора эта схема вообще беда: перерасход — плохо, недоосвоение — плохо вдвойне. А если нет опыта, да ещё и доверия к исполнителю, убедить заказчика в её применении практически невозможно. Решил заказчик законтрактоваться по схеме «Т&М». Помню забавный проект для одной из гос.служб по развитию и модернизации их основной информационной системы. Заложил деньги в бюджет на целый год, сформировал основные направления развития. Это был его первый опыт. Первым делом заказчик пофиксил накопившиеся баги — на это ушло не особо много времени и, соответственно, бюджета. Дальше контрактом предполагалось, что отдельные заказы будут поступать исполнителю в виде частных ТЗ, предварительно оцениваться и оплачиваться по модели «Т&М». Сотрудники на местах просто не знали, куда им дальше развивать свою же систему. А дальше… идеи закончились! к. Команда проекта смогла помочь только частично, т. Понимая, что время идёт, а деньги «сгорают», заказчик начал генерить задачи из разряда «не особо нужно, но вдруг пригодится». задача была относительно новой, а команда недостаточно укомплектована отраслевыми экспертами и аналитиками. А вот когда у заказчика к концу проекта появились действительно светлые идеи, бюджет проекта уже закончился! Динамика резко возросла, освоение тоже. Больше заказчик такую схему не применял!

Будущее уже не то, что прежде

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

Раньше они были для нас не так актуальны. Есть и множество других рисков, которые могут неожиданно поставить крест на вашем проекте. Это и валютные риски (когда курс доллара резко вырос и железо стало «золотым»), и введение санкций, когда вдруг в середине проекта вендор вам сообщил, что не может привезти нужное оборудование, и теперь ты вынужден покупать то, что есть в наличии у поставщика, по цене в 2 раза дороже… В последнее время эти риски часто генерит геополитическая обстановка в мире.

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть