Компании обновляют и создают новые ИТ-продукты или услуги, автоматизируют бизнес-процессы: ИТ-служба стала частью ядра бизнеса, а не вспомогательным подразделением. Бизнесу постоянно нужно осваивать специфику ИТ-проектов, включая такую сложную и важную часть, как проектные риски. О том, как эффективно управлять проектными рисками при реализации ИТ-проектов, рассказывает операционный директор Umbrella IT Михаил Меньшинский.
Практически во всех отраслях экономики крупные игроки стали digital-компаниями и предлагают своим пользователям обширный функционал. Параллельно появляются риски цифровизации, связанные с новыми направлениями деятельности. При этом отсутствие действия — тоже решение, которое несет в себе определенные риски: упущенную выгоду, опоздание с выходом товара на рынок, увеличение затрат из-за того, что вовремя не внесены изменения, и прочее.
Качество, сроки, бюджет — на что влияют риски в ИТ-проектах
Риски при реализации ИТ-проектов можно разделить на три группы:
8 Оценка рисков, анализ рисков инвестиционной стадии | разделы бизнес-плана | структура бизнес-плана
- риски, связанные с качеством разрабатываемого продукта;
- риски, связанные со скоростью разработки;
- риски, связанные с бюджетом, выделенным на разработку.
Смещение акцента на одну группу вызывает изменение в двух других. Хотите проект быстро и недорого, готовьтесь к соответствующему качеству. Нужно быстро получить качественный результат, обеспечьте необходимый бюджет.
Сроки
Сроки сжимаются. ИТ-проекты становятся масштабнее и глубже интегрируются в экосистему бизнеса. Фокус сегодня уже не просто на том, чтобы автоматизировать бизнес-процессы, а чтобы сделать их максимально эффективными в короткие сроки. Бизнес не только разрабатывает цифровые продукты — он стремится создать уникальные предложения для заказчиков и выпустить их на рынок быстрее конкурентов. На этом фоне сроки реализации проекта приобретают все большую важность: если конкуренты выпустят аналогичный продукт раньше — все усилия окажутся потраченными впустую.
Пример
Создатели удобного фото-сервиса точно знали, что нужно пользователям: нам всем знакома ситуация, когда накопилось большое количество фотографий и некоторые из них мы уже не то что не будем просматривать, мы просто никогда не вспомним о них. Удобная организация снимков по годам и датам, автоматический выбор наиболее качественных фото из серии, напоминание о фото, сделанных в определенный день в прошлом, безлимитный объем хранилища — команда действительно сделала свой продукт максимально полезным и удобным, и пользователи это оценили.
В августе 2013 г. продукт был назван лучшим в категории выбора пользователя по версии авторов TheVerge 1 . Но, к сожалению, факты — вещь упрямая. Отсутствие стратегии продвижения и монетизации работает против любого продукта. Создатели были вынуждены закрыть приложение, и их страница сегодня встречает пользователей грустным посланием: We gave it our all. Thank you, again. We’ll miss it dearly (Мы отдали все.
Еще раз всем спасибо. Мы будем очень скучать) 2 .
Качество
Требования к качеству постоянно растут. Сегодня качественный продукт подразумевает не только удобный UI/UX, высокую производительность, безопасность и доступность. На фоне все более тесной интеграции ИТ и бизнеса специалистам уже нужны как сильные технические навыки, так и отраслевые знания. Чтобы сделать качественный продукт, нужно понимать его логику и место в общей экосистеме компании или рынка и учитывать его перспективы. Рынок меняется, появляются новые сервисы, развиваются технологии, и, если в продукт не заложена возможность развития, интеграции или обновления, есть риск, что в определенный момент времени он устареет и не будет востребован.
Пример Структуры Бизнес-плана для Центра Занятости Населения. Раздел: «Анализ рисков» Заключение!
Примеры
Самой дорогостоящей ошибкой ПО в истории считается авария ракеты-носителя «Ариан-5» — и в такой точной области, как ракетостроение, случаются просчеты. Причин аварии называют несколько. Одной из основных стал программный модуль, который тестировался для предыдущей модели, «Ариан-4», и повторно использовался в новой среде, где условия работы были другими.
Модуль не проходил тестирование ни на уровне оборудования, ни на уровне системной интеграции.
Если вернуться к более земным проблемам, то можно вспомнить открытие пятого терминала Лондонского аэропорта Хитроу 3 , которого все ждали с нетерпением. Несколько дней бесконечных проблем для сотрудников и гостей аэропорта, конечно, были вызваны не одной ошибкой, но не последнюю роль сыграло отсутствие интеграции между старой и новой автоматизированными системами: не была обеспечена передача идентификаторов сумок из старой багажной системы в новую. Не нужно объяснять, что означает блокировка работы багажной системы для седьмого по загруженности аэропорта в мире.
Бюджет
Бюджеты на ИТ даже на фоне непростой экономической ситуации растут или по крайней мере остаются на прежнем уровне. Согласно исследованию Spiceworks 89% компаний ожидают, что в 2019 г. их ИТ-бюджет будет расти или останется на прежнем уровне 4 . При этом основным фактором, влияющим на увеличение бюджета, была названа необходимость обновления устаревшей ИТ-инфраструктуры.
Малый бизнес увеличит выделение бюджетных ресурсов на аппаратное обеспечение, в то время как крупные компании будут больше инвестировать в облачные решения. Соответственно, бизнес будет ждать финансовых результатов от этих вложений, и риски, которые связаны с перерасходом бюджета, привлекают все больше внимания. Бизнес-стейкхолдеры не хотят вкладывать в «черный ящик» или бесконечно продолжать инвестиции в проекты, которые «уже почти» доделаны, им нужно четкое понимание того, как распределяется бюджет: какие специалисты задействованы, какие технологии применяются, как учитывается объем и время работ. Рынок сегодня предлагает большое количество программных инструментов, которые обеспечивают возможность мониторить все параметры проекта, вовремя распознавать тенденции и корректировать ход проекта.
Предупредить нельзя исправить: этапы управления рисками
Говоря о том, как управлять рисками при реализации ИТ-проектов, мы понимаем, что полностью исключить риски из проектной деятельности невозможно. Поэтому работа по управлению рисками ведется в двух основных направлениях: уменьшить вероятность возникновения (предупредить) и минимизировать последствия (исправить). Выделим основные этапы управления рисками, они классические и присутствуют в любой сфере приложения по управлению рисками:
- идентификация рисков;
- оценка рисков;
- предупреждение рисков;
- исправление.
1. Идентификация
Чтобы эффективно управлять, нужно сначала разобраться, чем именно мы будем управлять. Поэтому работу следует начинать с выявления потенциальных проблем и факторов, которые могут повлиять на ход и результат проекта. Узнать о таких потенциальных опасностях помогут интервью заинтересованных в проекте лиц об их ожиданиях в отношении результатов, аудит процессов управления и технический аудит проектов, мозговые штурмы, анализ предыдущего опыта разработки подобных решений, привлечение мнения технических экспертов. На этом этапе в результате сбора информации формируется реестр рисков: полный перечень потенциальных факторов риска, с которым команда будет работать на протяжении всего проекта.
2. Оценка
На следующем этапе необходимо ответить на два вопроса: насколько высока вероятность реализации риска и каковы будут масштабы его последствий. Каждый фактор риска получает свой вес в рамках проекта. На основе этого анализа происходит расстановка приоритетов в реестре рисков. В противном случае пришлось бы работать над всеми факторами риска одновременно, что предполагает серьезные временные и финансовые затраты с низкой эффективностью.
Разделить управление рисками в рамках реализации ИТ-проекта на четко фиксированные этапы можно лишь условно. По сути, анализ рисков необходим при принятии каждого решения, и связано это с неопределенностью и скоростью изменений, характерных для ИТ, о которых уже говорилось выше.
3. Предупреждение
После того как менеджер ИТ-проекта разрабатывает список рисков, которые распределены в порядке приоритетности, можно начинать продумывать план действий для предотвращения или снижения негативного влияния в случае, если риск-фактор сработал.
В первую очередь следует максимально предотвратить потенциальные ситуации риска. При этом, планируя работу с рисками, всегда лучше иметь в резерве два плана: есть вероятность, что первый план не сработает.
Например, при интеграции продукта со сторонними сервисами всегда существует риск столкнуться с неприятными «сюрпризами» со стороны этого сервиса: не окажется необходимого API, он окажется нестабильным или лимитированным или подведет по срокам реализации, поэтому рекомендуется поступать следующим образом.
План А: начать с интеграции главного функционала, завязанного на этом сервисе, как можно раньше, чтобы понять, с какими проблемами придется столкнуться.
План Б: если оказывается, что проблемы действительно существуют, в запасе уже есть другие аналогичные сервисы.
План В: если по каким-то причинам срабатывают все риски и невозможно завершить интеграцию до релиза, настраиваем встроенные резервные варианты (англ. fallbacks) для этого функционала, позволяющие какое-то время использовать продукт без привлечения стороннего сервиса (например, логирование и ручная обработка запросов).
Варианты того, каким образом можно предотвратить предварительно идентифицированные риски в проектной деятельности, могут быть самыми разнообразными. Они отличаются тем объемом усилий, который нужен для их реализации: сколько нужно потратить средств, как долго будет длиться подготовка, сколько человек необходимо привлечь.
Поэтому прежде чем принять решение о дальнейшем плане действий, необходимо сравнить затраты и оценить, какой вариант будет наиболее разумным для конкретного проекта.
Цена страховки не должна быть дороже, чем то, что ты страхуешь. Никто из нас не станет тратить на страховку автомобиля сумму больше его стоимости. То же самое относится и к ИТ-проектам: можно застраховаться от всех известных рисков, но тогда сработает один самый страшный для бизнеса риск — цена проекта взлетит до небес.
4. Исправление
Если бы существовал метод профилактики, способный избавить проект от всех рисков на 100%, жизнь менеджеров и стейкхолдеров проектов существенно облегчилась бы. Но поскольку такую универсальную методику еще не придумали, на проекте всегда должны быть предусмотрены мероприятия, направленные на то, чтобы реализация риска нанесла проекту наименьший урон.
Простой наглядный пример: допустим, что по каким-то причинам была допущена ошибка в обработке платежей в рамках разрабатываемого приложения; должен быть заранее продуман способ восстановить историю всех платежей вручную для их повторной обработки.
Практические рекомендации по управлению рисками ИТ-проектов
Проектные риски требуют индивидуального рассмотрения и анализа, однако в индустрии уже выработан набор практик, позволяющих снизить вероятность основных риск-факторов.
На фоне быстрых темпов и одновременно высокой неопределенности и непредсказуемости результатов на первый план выходят не столько технические или организационные риски, сколько риски, связанные с расхождением в ожиданиях: бизнеса и ИТ-команды, пользователей и бизнеса, бизнеса и партнеров, ИТ-команды и пользователей.
Технологичный мир развивается очень быстро, инициатор проекта зачастую изначально сам не до конца понимает, что именно получит по завершении проекта, потому что видение конечной цели формируется после череды экспериментов и проверки гипотез. Если не наладить взаимодействие бизнеса с ИТ-командой, вырастет объем работ, увеличатся сроки разработки, раздуется бюджет. То есть полученный результат по всем параметрам разойдется с ожиданиями заказчика. Чтобы предупредить разочарование, рекомендуется учитывать следующие моменты:
1. Необходимо точно определить всех стейкхолдеров проекта, то есть все заинтересованные стороны и лица, которые имеют определенные требования и ожидания в отношении проекта и, что не менее важно, могут на него повлиять (с финансовой, организационной, регулятивной точки зрения). Основная задача заключается в том, чтобы выявить их ожидания и опасения. Так вы исключите ситуацию, когда на завершающем этапе работ вдруг окажется, что все, что было сделано, не устраивает одного из ключевых стейкхолдеров, который до этого момента не принимал активного участия в проекте.
2. Для стейкхолдеров и участников проекта необходимо создать единое информационное поле. Вся исходная информация и договоренности по проекту должны быть зафиксированы, и лучше сделать это визуально. Во-первых, потому, что визуальная информация лучше воспринимается. Во-вторых, всегда можно будет вернуться к зафиксированной исходной версии в случае спора или сомнений. Дорожная карта проекта, отражающая задачи и очередность их выполнения и находящаяся в общем доступе, будет обеспечивать единое представление о проекте у всех, кому эта информация нужна, быстро даст ответы на многие вопросы, что сэкономит время на коммуникации для выяснения деталей.
3. Выполнить разбивку проекта на небольшие итерации (циклы работы). Работа в режиме коротких итераций позволяет оперативно выявить риски, блокеры, проблемы и скорректировать их. Чем больший объем работы будет сделан до того момента, когда станет известно о проблеме, тем дороже обойдется исправление ситуации. За счет коротких периодов такие дополнительные расходы существенно уменьшаются.
4. Наладить регулярную обратную связь. Такая связь обеспечивается за счет ежедневных отчетов руководителя проекта, еженедельных демонстраций прогресса и результатов работ. В результате все заинтересованные лица регулярно получают информацию о том, что происходит на проекте. Но такая отчетность полезна и для самой команды. Например, в случае возникновения тенденции к увеличению бюджета, которую можно явно проследить по дорожной карте и отчетам, менеджер проекта заранее может продумать варианты оптимизации расходов и предложить их стейкхолдерам.
И еще один совет: всегда нужно начинать с самого важного и сложного, с того, что критично для проекта в целом. Это позволит еще на ранних этапах проекта идентифицировать потенциальные риски и скорректировать стратегию.
Особенности рисков в ИТ-сфере
Вышеперечисленные риски во многом обусловлены спецификой отрасли: они связаны не столько с возникновением форс-мажоров, сколько с расхождением ожиданий и неопределенностью результатов. Кроме того, необходимо учитывать особенности этой отрасли:
1. ИТ — молодая индустрия.
2. Исследования осуществляются постоянно, инновации внедряются быстро.
3. Темпы роста очень высокие.
Как отрасль сфера ИТ относительно молода, по сравнению с другими отраслями. Стоит вспомнить, что компания IBM выпустила первый жесткий диск в 1956 г., а концепт первого смартфона был представлен в 1992 г. Индустрия развивается, пусть и стремительными темпами, а это означает и определенные риски: нехватку наработанного опыта, дефицит высококвалифицированных специалистов, недостаток унифицированных отраслевых стандартов.
Если говорить о недостатке единых стандартов, то, с одной стороны, быстрое развитие технологий приводит к тому, что на данный момент нет единых требований, которые учитывали бы актуальную специфику ИТ-продуктов и унифицировали бы их создание. С другой стороны, такие требования со стороны регуляторов появляются и будут продолжать появляться, и представителям сферы ИТ необходимо быть к ним готовыми.
Вторая особенность ИТ тесно связана с первой: взаимодействуя с другими отраслями, молодая индустрия ищет новые решения и новые возможности. Проект в сфере ИТ — это постоянное прикладное исследование. Разработка прототипов, тестирование гипотез, создание MVP: все это нужно, чтобы получить на выходе продукт, который будет эффективно работать и приносить прибыль. Но любое исследование таит в себе риски, связанные с неопределенностью и непредсказуемостью.
Такой исследовательский характер связан с тем, что современные пользователи избалованы многообразием, которое предлагает им рынок. Они привыкли к тому, что цифровые продукты и услуги доступны здесь и сейчас, удобны в использовании и безопасны. К тому же на восприятие цифровых продуктов влияет глобализация. Международные гиганты Facebook, Amazon, Uber, Netflix предлагают новые технологичные решения, и пользователь ждет такого же подхода от всех поставщиков ИТ-услуг.
Третья особенность, которую нельзя не упомянуть — это высокие темпы развития ИТ-индустрии. Многие кадры фантастических фильмов, которые удивляли нас несколько лет назад, сегодня стали реальностью: интерактивное телевидение, умные города, общение в искусственной реальности, биометрическая идентификация и многое другое. Сегодня те технологии, которые существуют два-три года и не раз успешно использовались, могут потерять интерес потребителей на фоне других новых решений. И такие скоростные изменения означают, что всегда есть риск опоздать.
В первом квартале 2019 г. в Google Play насчитывалось 2,1 миллионов приложений, а в Apple App Store — 1,8 миллионов 5 . При такой конкуренции неправильная оценка ситуации на рынке, задержка в выпуске на рынок или недостатки, влияющие на качество, могут стать для продукта губительными.
Особенности ИТ-индустрии таковы, что и разработчикам ИТ, и их компаниям-клиентам при реализации ИТ-проектов необходимо действовать быстро и при этом учитывать как специфические отраслевые риски ИТ, так и особенности взаимодействия команды разработчиков и всех заинтересованных сторон проекта.
К сведению
API (сокр. от англ. application programming interface) — программный интерфейс приложения, интерфейс прикладного программирования: описание способов (набор классов, процедур, функций, структур или констант), при помощи которых одна компьютерная программа может взаимодействовать с другой программой. Используется программистами при написании приложений.
Источник: www.eg-online.ru
Оценка рисков в 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 каждого ключевого участника в данном проекте. Если ты способствуешь их достижению — ты молодец, союзники тебе обеспечены.
Кадры как базовый риск
Мир становится цифровым, поэтому потребность в ИТ-специалистах в последние годы резко возросла. Нужны люди, которые уже обучены и делают работу с хорошим качеством и предсказуемым результатом. Времени на раскачку нет, да и заказчики экспериментировать на себе уже не хотят.
Всё чаще заказчики ищут уже готовые команды с готовыми наработками и подтверждёнными на практике бизнес-кейсами. Требования к квалификации таких команд довольно высокие, и на рынке, если речь идёт об инновационных решениях, их не так много. Устаревшая классическая модель обучения просто неспособна покрыть растущий ресурсный спрос — вы это наверняка видите сами, если проводите собеседования, например, в команды разработки. Рынок испытывает колоссальный дефицит высококвалифицированных кадров.
Причём риски вызывает не только сам дефицит, но и тот факт, что в ответ на растущую потребность рынок заполнился низкоквалифицированными суррогатными командами, получившими знания по ускоренной схеме и отличающимися отсутствием достаточного практического опыта. Распознать их в проектной суете бывает сложно, т. к. на фронте у них обычно профессиональные люди.
С точки зрения реализации ситуация выглядит так: хорошо, если у тебя достаточно ресурсов, необходимых для выполнения проекта. Плохо, когда приходится искать партнёра и работать с незнакомой командой.
В такие моменты обычно спасают две важные вещи:
- Наличие списка надёжных, проверенных партнёров по ключевым дефицитным направлениям. Такие контакты часто выручают, когда своих ресурсов недостаточно для масштабного внедрения. В условиях горящих дедлайнов это всегда бывает крайне полезно и часто без ущерба для бюджета. Здесь стоит отметить, что такие партнёры нарабатываются небыстро, а взаимодействие во многом строится на доверии с обеих сторон. Полученный результат, как правило, оправдывает вложенные в это усилия.
- Развитие своей команды. То есть постоянно учиться самому и учить своих людей. Конференции, хакатоны, курсы, тренинги — всё это отлично работает на быстроменяющемся рынке. Позволяет быть на острие технологий и мотивировать команду. Здесь мы тесно сотрудничаем с ключевыми вендорами и партнёрами.
Консерватизм заказчика
Современные проекты ИТ-трансформации подразумевают не только оцифровку существующих бизнес-процессов компании, но и глобальный пересмотр функционирования всей организации – выход на принципиально новый уровень работы. Все меняется, как только рынок от массовых увлечений новыми технологиями переходит к попыткам реальных внедрений.
Многие заказчики оказываются просто не готовы проводить глобальные изменения своей бизнес-модели. Как итог – все ограничивается поверхностной оптимизацией громоздких и неэффективных бизнес-процессов, сформировавшихся за долгие годы. Перевели процессы as-is в цифру и продолжаем работать также, как и работали раньше, не замечая очевидных возможностей повысить эффективность. Основные причины – инерция мышления и страх к переменам. И чем старше компания, тем ярче они проявляются. Реализация таких проектов превращается для команды в затяжную позиционную борьбу со стереотипами заказчика – «мы всегда так работали, и все было хорошо…», «мы сами знаем как лучше», «нет, что вы, это не забюрократизованность, это регулирование принципиальных аспектов работы, поэтому столько уровней согласования» и т. д.
В одном из консалтинговых проектов, на интервью, представитель заказчика рассказывал про бизнес-процессы, в которых он участвует. На мой вопрос, а что конкретно ваше подразделение согласует в этой цепочке? В чем важность именно вашего участия? Заказчик четко сформулировать не смог, сказав, что раз так реализовали – значит это важно и нужно!
Как это ни странно, но часто сама суть, цель проекта становится непреодолимым барьером на пути его реализации. И если топы компании не являются адептами глобальных перемен, лишь малая часть подобных проектов доживет до «боевой» эксплуатации. Проверено на практике!
Продуктовая самоидентификация рынка
Если вы посмотрите отчёты ведущих аналитических агентств, то увидите, что только 15% современных инновационных ИТ-проектов признаны успешными! Почему так происходит?
Всё чаще проекты на стороне заказчиков инициируются под действием маркетингового прессинга со стороны вендоров, а также в погоне за пресловутыми конкурентами, которые уже внедрили себе что-то такое новенькое и поспешили известить об этом рынок в бесчисленных пресс-релизах. На всех конференциях и форумах мы слышим: «BigData — must have», «blockchain — наше всё», «IOT — в каждый дом» и много чего ещё…
Не имея должной ИТ-зрелости и опыта внедрения подобных решений, заказчики часто стартуют проект либо с завышенными ожиданиями, либо без должного целеполагания. В итоге мы наблюдаем такую картину: внедрил заказчик BigData и использует её для получения простой аналитики, которую можно получить и более дешёвыми способами.
Либо получает качественную многогранную аналитику, но совершенно не понимает, как её использовать в своей работе. Либо понимает, как использовать, но внутренние процессы и ИТ не позволяют этого сделать. Как результат — разочарование заказчика и в самом решении, и в исполнителе. Ну а кого у нас ещё винить?
Осознание приходит на рынок методом проб и ошибок, продукты проходят так называемую самоидентификацию: термины приобретают своё истинное значение, появляется больше пользовательского опыта и успешных внедрений. Чтобы понять, как это работает, достаточно взглянуть на хайп-циклы Гартнера и посмотреть, что сейчас находится на пике «рекламной шумихи». Вот один из них за 2017 год.
Возьмём, к примеру, BigData и посмотрим на график (отмечено красной точкой). Только сейчас, спустя почти десяток лет с момента появления первых продуктов и решений, относящихся исключительно и непосредственно к проблеме обработки больших данных, данная технология прошла своё «дно разочарований» и начинает выходить «на плато продуктивности». С другими технологиями примерно всё то же самое.
Часто озвученная проблема хорошо видна по переходам в облако: вот, например, материал моего коллеги о том, какие бывают при этом мифы, а вот история эксплуатации о том, как старая архитектура переносится на новую платформу без понимания её сути.
Регуляторика
Обычно под этим термином понимают правовые аспекты взаимодействия с регуляторными органами. Нормативно-правовая база — это отдельная головная боль на пути современных «цифровых» проектов, особенно для госсектора.
Дело в том, что многие СНИПы, ГОСТы, регламенты и постановления, по которым сейчас работают контролирующие органы, писались ещё «при царе горохе», когда и технологий-то таких не было. Большое количество из них на текущий момент просто неприменимы. Это действительно серьёзная проблема, которую осознаёт и само государство.
И это учтено в программе «Цифровая экономика», которая утверждена правительством РФ в прошлом году. Был в моей практике случай, когда виртуализация не ложилась в требования по безопасности для крупного госбанка: стандарты, по которым велось проектирование, много лет назад были написаны «под железо». Тогда заказчику пришлось обращаться к регуляторам, одним из которых был ФСТЭК, для доработки нормативной базы и требований по защите виртуальных сред. Как вы понимаете, было это совсем не быстро! Сейчас аналогичные проблемы испытывают и другие технологии.
Какими бы эти стандарты ни были — инженерными, платёжными и прочими, — вам придётся разобраться в этом самому, привлекая нужных специалистов вроде юриста. Почему самому, потому что самый главный навык ПМа — это понять, как можно реализовать проект. Чаще всего ваши консультанты найдут миллион причин «почему так нельзя», а не одну возможность «как можно».
Яркий пример — прохождение сертификации PCI DSS.
Или ещё пример — определение, что же такое персональные данные для вас.
Классическое проектное бюджетирование
Давайте вспомним, как происходит бюджетирование у большинства заказчиков (госов вспоминаем отдельно и в ярких красках). Бюджет формируется в начале года, защищается на УК (или в других инстанциях) и часто даже не пересматривается. Когда мы перейдём к реализации, возникнет основная дилемма — какую схему оплаты выбрать. Схема работы «fix scope — fix price», её ещё называют «Fixed Fee», не очень устраивает исполнителя, т. к. требования нечёткие, вариативность большая, а бюджет фиксирован. Возникают огромные риски промахнуться с бюджетом.
Схема «Time М». Это был его первый опыт. Заложил деньги в бюджет на целый год, сформировал основные направления развития.
Дальше контрактом предполагалось, что отдельные заказы будут поступать исполнителю в виде частных ТЗ, предварительно оцениваться и оплачиваться по модели «Тhttps://petropan.ru/ocenka-riskov-v-it-biznese-plane-primer/» target=»_blank»]petropan.ru[/mask_link]
Оценка рисков в ИТ-проектах на ранних этапах
Ревенко, В. Г. Оценка рисков в ИТ-проектах на ранних этапах / В. Г. Ревенко, С. Д. Асеева. — Текст : непосредственный // Молодой ученый. — 2020. — № 19 (309). — С. 141-144. — URL: https://moluch.ru/archive/309/69880/ (дата обращения: 03.06.2023).
Существует множество исследований, советов и практических рекомендаций, как управлять рисками в ИТ-проектах (информационные технологии). Менеджеру проекта кажется, что он знает, что нужно делать для управления рисками, но не всегда это приводит к успеху. Во всех отраслях ИТ-проекты с высокой долей вероятности терпят неудачи или по крайне мере не оправдывают ожиданий.
Происходит ли эта ошибка из-за сложившихся традиций организации в управлении рисками или по причине неэффективного управления руководителей? В данной статье обсуждается подход одной организации к тому, чтобы управление рисками в ИТ проектах было эффективнее.
Представленный в статье процесс оценки риска, представляет визуальную помощь для выявления общего риска на ранних этапах проекта, тем самым позволяя на будущее скорректировать элементы проекта, так как в начале это будет сделать намного проще.
Ключевые слова: управление проектами, проект, оценка рисков, проектная деятельность, диаграмма риска.
There are many studies, tips and practical recommendations on how to manage risks in IT projects (information technology). The project Manager thinks that he knows what needs to be done to manage risks, but this does not always lead to success. In all industries, IT projects are highly likely to fail or at least fall short of expectations.
Does this error occur because of the organization’s established traditions in risk management or because of poor management of managers? This article discusses the approach of one organization to making risk management in it projects more effective.
The risk assessment process presented in this article is a visual aid to identify the overall risk at the early stages of the project, thus allowing you to adjust the project elements in the future, since it will be much easier to do this at the beginning.
Keywords: project management, project, risk assessment, project activity, risk diagram
Введение
Существует множество исследований, советов и практических рекомендаций, как управлять рисками в ИТ проектах (информационных технологии). Менеджеру проекта кажется, что он знает, что нужно делать, для управления рисками, но не всегда это приводит к успеху. Во всех отраслях ИТ-проекты с высокой долей вероятности терпят неудачи или по крайне мере не оправдывают ожидание [1].
Большинство фирм используют оценку рисков для своих ИТ-проектов, используя контрольные списки известных им проблем, основанных на их опыте. Теоретически, должно быть просто определить потенциальные риски и оценить эти риски с точки зрения вероятности их возникновения. На практике, точная оценка вероятности и влияния риска очень трудна в условиях неопределенности, особенно в ИТ-проектах.
В этой статье мы рассмотрим новый подход к тому, чтобы сделать управление рисками проекта более наглядными. Представленный здесь подход является личным опытом автора, учувствовавшем 3 года в качестве руководителя проектов в г. Волгоград.
Атрибуты измерения успеха проекта
На раннем этапе жизненного цикла проекта, когда отсутствует предварительное обследование, технические требования и т. д., то традиционные подходы к оценке рисков могут не работать, а оценки вероятности воздействия отдельных рисков оставляют лишь догадки.
Проекты, которые имеют более высокий риск, не зависимо от того, какие конкретные факторы риска могут применяться, подвергаются более тщательному анализу. Большие, рискованные проекты можно разбить на более мелки, а стадии сбора требований сложных проектов можно вынести в отдельный проект.
Чтобы оценить уровень риска в проекте, был использован анализ стандартов и методологий в области управления проектами, например, как: PMBooK [2], Agile [3], Scrum [4], что бы выделить 6 ключевых атрибутов:
− Уровень зрелости команды;
− Уровень участи заинтересованных сторон.
Описание атрибутов, используемых для измерений, приведены в таблице 1.
Атрибуты риска проекта
Атрибут
Описание
Измерение
Проекты, которые являются более критически важными для организации, будут иметь более высокий уровень риска, а определение критичности проекта дает представление о том, какой риск может возникнуть в ключевых областях проекта. Высокие баллы по атрибуту критичности указывают на необходимость изучения всех других атрибутов.
Неопределенность в любой области проекта увеличивает риск. Неопределенная область действия вводит неоднозначность в границы проекта, вокруг которых проект структурирован, спланирован и оценен. Когда команда не знакома с технологией — даже если сама технология не нова — точность планирования и оценки снижается, и процесс обучения обычно открывает от основных задачи.
1)Неопределенность границ проекта
2)Неопределенность выбора технологии
Сложность тесно связана с неопределенностью, поскольку неопределенности в отношении объема и технологии часто связаны со сложностями предлагаемого решения.
1)Изменения бизнес -процессов
Более крупные проекты по своей природе несут большую неопределенность, и чем больше проект с точки зрения стоимости, продолжительности и размера проектной команды, тем выше риск худшего выполнения проекта. Длительные, высокобюджетные проекты сложнее точно оценить. Более длительный срок подвергает проект изменениям в технологии, текучести кадров, потере поддержки со стороны руководства и постоянно меняющимся правилам, положениям и бизнес-процессам. Большие команды создают большие проблемы с коммуникацией и координацией. Небольшие отклонения в больших оценках могут быстро составить значительную сумму.
Уровень зрелости команды
Зрелость управления проектом решает вопросы компетентности и методологии управления. Проекты, которые не поддерживаются опытными менеджерами, использующими не правильные методологии, часто сталкиваются с проблемами, которые приводят к дорогостоящей переработке и смещению графика.
1)Уровень зрелости управление проектом
2)Опыт руководителя проекта
Уровень участия заинтересованных сторон
Измерение вовлеченности заинтересованных сторон также включает два атрибута — соответствие опыта исполнительного спонсора и проекта и степень, в которой участие конечных пользователей было запланировано и встроено в план проекта. Сильная спонсорская поддержка уже давно признана важным фактором успеха проекта
1)Участие пользователей заказчика
2)Исполнительный и спонсорский опыт заказчика
Количественная оценка каждого атрибута будет варьироваться в зависимости от организации и проектами, с которыми она работает. Например, атрибут бюджета может быть измерен в любой организации, но абсолютные значения в рублях, связанные с большим бюджетом проекта, будут отличаться относительно размера организации. Аналогичным образом организации, которые полагаются на аутсорсинг в большей части своей проектной работы, скорее всего, добавят измерение неопределенности поставщиков с атрибутами от «проверенных» до «новых» с, которыми еще не приходилось работать.
Построение диаграммы риска «Паук»
Процесс совместного с заказчиком профилирование рисков начинается на раннем этапе инициирования проекта. На это этапе сотрудники работают совместно с менеджерами проекта заказчика, чтобы заполнить анкету с описание атрибутов и различных нюансов проекта. Совместно отображают показатели атрибутов на диаграмме паука рисунок 1. Общая структура атрибутов, показанная на диаграмме, помогает определить оценки риска для проекта, который в свою очередь определяет уровень надзора над проектом.
Диаграмма паука риска, показанная на рисунке 1, является примером проекта — Внедрение программного продукта 1С зарплата и управление персоналом в крупную организацию в г. Волгоград. Для этого проекта был рекомендован контроль обеспечения качества с ежемесячными проверками выполнения этапов проекта, строго привлечение к проекту всех ключевых сотрудников заказчика, для исполнителя рекомендовано улучшать качество проектной документации и деятельности.
Рис. 1. Диаграмма риска проекта
Атрибуты, определенные на диаграмме паука риска, служат отправной точкой для планирования превентивного и непредвиденного управления рисками, а также предлагают предложения по действиям, которые могут помочь снизить риск проекта. Например, когда выявлен разрыв между опытом менеджера проекта и характером самого проекта, то можно рекомендовать механизм наставничества или предоставление консультанта по проекту.
Вывод
Использование графического инструмента для визуализации характера рисков проекта является важной частью стратегии определения рисков. С помощью графической диаграммы паука рисков, даже если ведутся дискуссии о некоторых отдельных показателях, визуальное представление общего неотъемлемого риска проекта очень эффективно и позволяет быстро перейти к обсуждению лучшего способа устранения или уменьшения общего риска. Инструмент легко настраивается для различных организаций и проектов. Ключевым результатом стало понимание того, как преодолеть практические барьеры, которые могли препятствовать внедрению и всему ходу проекта.
1. Проблемы стандартизации и проектной деятельности в области ИТ URL: https://www.cfin.ru/itm/standards/st_troubles.shtml (дата обращения: 01.05.2020
2. Руководство к своду знаний по управлению проектами (Руководство PMBOK) / Институт управления проектами, 2017.
- Стив Деннинг, Эпоха Agile, 2019.
4. Роман Пихлер, Управление продуктом в Scrum, 2016.
Основные термины (генерируются автоматически): проект, управление рисками, оценка рисков, риск, волгоград, диаграмма паука риска, Критичность проекта, менеджер проекта, общий риск, описание атрибутов.
Источник: moluch.ru
