Оценка рисков в it бизнесе плане пример

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

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

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

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

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

Раньше CIO занимались автоматизацией бизнес-процессов компании и обеспечением стабильной работы своего зоопарка систем. Сейчас этап автоматизации классических бизнес-функций подходит к концу: ERP, CRM, BI и прочие инструменты управления бизнесом уже оцифрованы. Просто наличие автоматизации — это уже не конкурентное преимущество. Важнее 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 раза дороже…

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