Проект внедрения программного продукта 1С представляет собой сложный процесс, в котором присутствуют и технологические, и интеллектуальные ресурсы как заказчика и исполнителя, так и внешних консультантов, партнеров, соисполнителей. Процесс внедрения системы автоматизации чаще всего связан с высоким уровнем рисков, носящих организационный и технологический характер.
В настоящей статье мы рассмотрим основные практические моменты по управлению рисками проекта внедрения программного обеспечения.
К общим проектным рискам обычно относятся:
На предпроектном обследовании системы и формализации требований выполняется интервьюирование специалистов заказчика с целью сбора и категоризации основных требований ключевых пользователей системы 1С. Обычно в этом процессе участвуют специалисты заказчика нескольких организационных подразделений, что являет собой различные взгляды как на цели и задачи проекта, так и на некоторые нюансы автоматизации бизнес-процессов. Результатом разобщенности во взглядах на данном этапе может стать общая неудовлетворенность во внедренной информационной системе, затягивание периода опытной эксплуатации и существенный поток замечаний и претензий в адрес исполнителя.
https://tproger.ru/events/vebinar-i...zrabotka-kejsy-i-praktiki/?utm_source=in_text
На этапе проектирования и разработки осуществляется проработка архитектуры системы в целом, а также некоторых её модулей. На этом этапе велики технологические риски, связанные с ошибкой решения в части архитектуры информационной системы или неполной проработкой отдельных модулей и/или взаимосвязей между ними, неучтенными нефункциональными требованиями, такими как отклик системы на действия пользователя, надёжность данных, их масштаб и технические возможности оборудования заказчика и т.п. Критичным является то, что выявление этих рисков происходит в достаточно поздние сроки, например на стадии опытной эксплуатации или эксплуатации на реальных данных реальными пользователями 1С. Это приводит к необходимости экстренного выполнения доработок или даже возможного срыва проекта в целом в силу непригодности системы к реальной и полноценной эксплуатации.
Как правило, этот этап является самым длительным. Основная причина появления рисков в процессе разработки – это недостаточный анализ требований или неоднозначная их трактовка, что приводит к тому, что результат не соответствует ожиданиям представителей заказчика.
При внедрении информационной базы довольно часто исполнителю приходится сталкиваться с непринятием сотрудниками заказчика обновленного функционала системы, её пользовательского интерфейса и т.п. Если не контролировать этот риск, то он может перерасти в открытый саботаж пользователями новой системы. Также ситуация может усугубляться неподготовленностью информационной инфраструктуры заказчика к внедрению программного обеспечения, что является причиной срывов сроков проекта и необходимостью доработки или адаптации программного обеспечения за счёт увеличения бюджета проекта.
На стадии завершения проекта и поддержки пользователей в период опытно-промышленной эксплуатации системы очень часто встречается риск, обусловленный отсутствием службы поддержки со стороны заказчика или её некомпетентности из-за отсутствия навыков по работе с новой конфигурацией системы. Это приводит к тому, что ликвидация сбоев системы становится неоперативной или поддержка конечных пользователей не является комплексной и полноценной.
В проектном управлении существует такое понятие как «риск-менеджмент». Но нужно понимать, что риск-менеджмент – это не только составление и просчёт рисков проекта на определенных его этапах. Риск-менеджмент – это спокойная, без истерик и суеты, сенсорика и разрешение проектному менеджеру думать о том, что что-то пойдёт не так.
Управление рисками проекта можно разделить на 3 части:
При определении рисков необходимо исходить не только из методологии определения и расчёта рисков, но и из опыта реальных проектов внедрения программ 1С, имеющейся базы знаний, областей деятельности компании, в которой реализуется проект. Требуется участие не только исполнителя, который определит основные существующие риски проекта внедрения, но и заказчика, который заложит риски в виде нюансов и особенностей ведения деятельности компании.
Перед стартом проекта проводится работа по идентификации возможных и существующих рисков. Процесс идентификации представляет собой поиск всех возможных рисков, по итогам которого мы должны найти ответы на вопрос «Что может пойти не так?» (для негативных рисков). Но при поиске ответов на вопрос «Что может пойти не по плану?» можно найти и позитивные риски.
При планировании рисков следует учитывать, что большим количеством рисков одновременно и качественно управлять невозможно, поэтому цель качественного анализа рисков проектов состоит в группировке и расстановке приоритетов.
Такое ограничение говорит о том, что, как и у треугольника, нельзя изменить одну сторону, не задев как минимум ещё одну. Изменение одного параметра управления проектом влияет и на другие параметры. Поэтому процесс контроля и мониторинга рисков ориентирован на оценку текущей ситуации по проекту: управление рисками, анализ возникших отклонений, контроль изменений и их влияния на все параметры проекта.
При выборе стратегии управления рисками проекта необходимо учитывать понятие о риске проекта. Риск проекта – это неопределенное событие, которое в случае его возникновения имеет негативное или позитивное воздействие как минимум на один из параметров проекта (например, срок или бюджет проекта).
Исходя из логики определения риска проектов, можно выделить следующее:
При расчетах величины риска значения влияния и вероятности возникновения определяются по шкале от 0 до 1:
В данном реестре рисков кроме перечня возможных рисков определяется, как данный риск влияет на проект, учитывается величина риска по вероятности наступления и степени его влияния и определяются мероприятия (стратегия) по управлению этим риском.
Кроме определения перечня рисков с их оценкой и стратегией правильным будет также назначить ответственных за разрешение соответствующего риска, так как проектный менеджер не может быть владельцем всех рисков и отвечать за всех одновременно. Иначе у него не останется времени на то, чтобы в целом управлять проектом. Например, управление риском неохвата всего персонала заказчика для обучения в виду их отсутствия по различным причинам должно происходить на стороне заказчика путем назначения ответственных. Как вариант, руководителей подразделений в части организации своих сотрудников для прохождения обучения.
В процессе управления имеющимся списком рисков необходимо просчитывать возможность возникновения следующих или даже новых рисков и пополнять реестр рисков с расчётом стратегии по реагированию на них. То есть вести работу на опережение через просмотр на срабатывание риск-триггеров. Например, вероятность наступления риска ещё далека, но по некоторым сигналам можно определить, что ситуация нагнетается и риск может произойти раньше запланированного.
Ещё одной предупредительной мерой может быть наличие плана С. Так или иначе при стратегии реагирования на риск всегда имеется как минимум план А, а если что-то пошло не так, то выполняется план В. Но в некоторых случаях можно предусмотреть также план С, когда количество векторов развития событий высоко, и когда и план А, и план В могут не так пойти или реакция на эти риски окажется не той, которую ожидали.
Бороться с рисками бессмысленно, ими надо управлять.
tproger.ru
В настоящей статье мы рассмотрим основные практические моменты по управлению рисками проекта внедрения программного обеспечения.
Риски проекта на этапах жизненного цикла
Жизненный цикл проекта по внедрению программ 1С состоит из нескольких этапов, на каждом из которых присутствуют свои риски. Также существуют общие риски всего проекта.
К общим проектным рискам обычно относятся:
- риски в виде отсутствия поддержки со стороны руководства заказчика;
- отсутствие чёткого разделения ответственности между проектными командами заказчика и исполнителя, а также внутри самой проектной команды;
- недостаток времени у проектной команды заказчика в связи с выполнением текущих функциональных обязанностей;
- отсутствие соответствующей компетенции у персонала;
- предоставление неполноценной или несогласованной информации;
- недоступность технической информации для исполнителя и прочее.
На предпроектном обследовании системы и формализации требований выполняется интервьюирование специалистов заказчика с целью сбора и категоризации основных требований ключевых пользователей системы 1С. Обычно в этом процессе участвуют специалисты заказчика нескольких организационных подразделений, что являет собой различные взгляды как на цели и задачи проекта, так и на некоторые нюансы автоматизации бизнес-процессов. Результатом разобщенности во взглядах на данном этапе может стать общая неудовлетворенность во внедренной информационной системе, затягивание периода опытной эксплуатации и существенный поток замечаний и претензий в адрес исполнителя.
https://tproger.ru/events/vebinar-i...zrabotka-kejsy-i-praktiki/?utm_source=in_text
На этапе проектирования и разработки осуществляется проработка архитектуры системы в целом, а также некоторых её модулей. На этом этапе велики технологические риски, связанные с ошибкой решения в части архитектуры информационной системы или неполной проработкой отдельных модулей и/или взаимосвязей между ними, неучтенными нефункциональными требованиями, такими как отклик системы на действия пользователя, надёжность данных, их масштаб и технические возможности оборудования заказчика и т.п. Критичным является то, что выявление этих рисков происходит в достаточно поздние сроки, например на стадии опытной эксплуатации или эксплуатации на реальных данных реальными пользователями 1С. Это приводит к необходимости экстренного выполнения доработок или даже возможного срыва проекта в целом в силу непригодности системы к реальной и полноценной эксплуатации.
Как правило, этот этап является самым длительным. Основная причина появления рисков в процессе разработки – это недостаточный анализ требований или неоднозначная их трактовка, что приводит к тому, что результат не соответствует ожиданиям представителей заказчика.
При внедрении информационной базы довольно часто исполнителю приходится сталкиваться с непринятием сотрудниками заказчика обновленного функционала системы, её пользовательского интерфейса и т.п. Если не контролировать этот риск, то он может перерасти в открытый саботаж пользователями новой системы. Также ситуация может усугубляться неподготовленностью информационной инфраструктуры заказчика к внедрению программного обеспечения, что является причиной срывов сроков проекта и необходимостью доработки или адаптации программного обеспечения за счёт увеличения бюджета проекта.
На стадии завершения проекта и поддержки пользователей в период опытно-промышленной эксплуатации системы очень часто встречается риск, обусловленный отсутствием службы поддержки со стороны заказчика или её некомпетентности из-за отсутствия навыков по работе с новой конфигурацией системы. Это приводит к тому, что ликвидация сбоев системы становится неоперативной или поддержка конечных пользователей не является комплексной и полноценной.
Риск-менеджмент проекта
Если проектный менеджер (как со стороны исполнителя, так и со стороны заказчика) не видит преград в реализации проекта, то в большинстве случаев это говорит о том, что он скорее всего не потрудился на старте их поискать и придумать как с ними лучше всего разобраться. А риски в итоге возникают (это неизбежно) и приходится их в суете решать. Но ведь можно это сделать заранее и спокойно, до старта проекта.В проектном управлении существует такое понятие как «риск-менеджмент». Но нужно понимать, что риск-менеджмент – это не только составление и просчёт рисков проекта на определенных его этапах. Риск-менеджмент – это спокойная, без истерик и суеты, сенсорика и разрешение проектному менеджеру думать о том, что что-то пойдёт не так.
Управление рисками проекта можно разделить на 3 части:
- Идентификация, анализ и оценка рисков проекта.
- Определение мероприятий по управлению рисками.
- Контроль и мониторинг рисков проекта.
При определении рисков необходимо исходить не только из методологии определения и расчёта рисков, но и из опыта реальных проектов внедрения программ 1С, имеющейся базы знаний, областей деятельности компании, в которой реализуется проект. Требуется участие не только исполнителя, который определит основные существующие риски проекта внедрения, но и заказчика, который заложит риски в виде нюансов и особенностей ведения деятельности компании.
Перед стартом проекта проводится работа по идентификации возможных и существующих рисков. Процесс идентификации представляет собой поиск всех возможных рисков, по итогам которого мы должны найти ответы на вопрос «Что может пойти не так?» (для негативных рисков). Но при поиске ответов на вопрос «Что может пойти не по плану?» можно найти и позитивные риски.
При планировании рисков следует учитывать, что большим количеством рисков одновременно и качественно управлять невозможно, поэтому цель качественного анализа рисков проектов состоит в группировке и расстановке приоритетов.
Этот этап является одним из сложных, так как принятые решения по ликвидации или снижению рисков затрагивают основные составляющие управления проектом: объём, бюджет и сроки проекта. То есть необходимо учитывать тройное ограничение проекта:
Такое ограничение говорит о том, что, как и у треугольника, нельзя изменить одну сторону, не задев как минимум ещё одну. Изменение одного параметра управления проектом влияет и на другие параметры. Поэтому процесс контроля и мониторинга рисков ориентирован на оценку текущей ситуации по проекту: управление рисками, анализ возникших отклонений, контроль изменений и их влияния на все параметры проекта.
При выборе стратегии управления рисками проекта необходимо учитывать понятие о риске проекта. Риск проекта – это неопределенное событие, которое в случае его возникновения имеет негативное или позитивное воздействие как минимум на один из параметров проекта (например, срок или бюджет проекта).
Исходя из логики определения риска проектов, можно выделить следующее:
- Риск имеет как негативную, так и позитивную сторону.
- Риск – это неопределенное событие, то есть событие, которое может произойти или нет с некоторой вероятностью. Таким образом, мы должны понимать, что событие не считается риском, если мы точно знаем, произойдет оно или нет.
- Риск влияет на проект. То есть если какое-то событие (например, засуха на другом материке) не влияет на цели и параметры проекта, то это не является риском.
- Любой риск имеет два обязательных параметра: влияние и вероятность возникновения.
При расчетах величины риска значения влияния и вероятности возникновения определяются по шкале от 0 до 1:
- 0 – известно, что событие определенно не произойдёт.
- 1 – известно, что событие определенно произойдет.
Разработка стратегии ликвидации рисков
В процессе расчёта величин риска определяются стратегии ликвидации рисков. При этом можно использовать следующие мероприятия по реагированию на риски:- Уклонение от риска предполагает корректировку плана управления проектом так, чтобы максимально исключить угрозу негативного риска, а также снизить последствия риска для целей проекта (например, пересмотреть график проекта или изменить объёмы путем исключения некритичных модификаций). Важно заметить, что некоторых рисков можно избежать, если на ранних стадиях проекта детализированно собирать требования заказчика, налаживать более приятные коммуникации.
- Передача риска осуществляется путём переложения негативных последствий риска под ответственность третьей стороны. При этом необходимо понимать, что при передаче управления риском третьей стороне сам риск не снимается. Такая стратегия управления риском эффективна в части финансовых рисков. Например, страхование, гарантии выполнения контракта, выдача гарантийных обязательств и т.п. Естественно, что условия передачи рисков третьей стороне несут в себе обязательства по выплате премии за риск третьей стороне. Если проект подразумевает оплату фактических издержек заказчиком, то бремя выплаты премии может быть переложено на заказчика, а вот с фиксированной ценой контракта это бремя обычно ложится уже на исполнителя.
- Снижение риска предполагает уменьшение вероятности и/или последствий рискованного события до необходимых пределов. То есть стратегия состоит в формировании предупредительных мер по снижению вероятности негативного события или последствий его наступления, т.к. предупреждение всегда эффективнее, чем разрешение последствий свершившегося факта. Как пример снижения риска можно привести работу по планированию человеческих ресурсов как на стороне заказчика (бизнес-эксперты, ключевые пользователи), так и на стороне исполнителя (консультанты, разработчики) в случаях их болезни, отпуска или увольнения. Как предупредительная мера может использоваться оптимизация сложных процессов за счёт их упрощения (исключить неактуальные действия или пересмотреть схему движения бизнес-процесса), увеличение количества тестовых испытаний на реальных данных с активным участием пользователей, выполняющих соответствующие функциональные обязанности и прочее.
- Использование риска выбирается в качестве стратегии реагирования на благоприятные последствия случившегося события. Примером использования может служить возникновение возможности по привлечению специалиста более высокого уровня с целью сокращения времени на реализацию определённых задач проекта. Также примером является отказ от модификации в пользу использования стандартного функционала системы в виду изменения методологии бизнес-процесса.
- Усиление через позитивное воздействие на складывающуюся ситуацию позволит повлиять на условия формирования события в положительном ключе. Один из примеров реагирования на такой положительный риск – это привлечение специалиста со стороны заказчика, находящегося на более высоком уровне принятия решений по проекту, в случае каких-то согласований задач по модификациям.
В данном реестре рисков кроме перечня возможных рисков определяется, как данный риск влияет на проект, учитывается величина риска по вероятности наступления и степени его влияния и определяются мероприятия (стратегия) по управлению этим риском.
Кроме определения перечня рисков с их оценкой и стратегией правильным будет также назначить ответственных за разрешение соответствующего риска, так как проектный менеджер не может быть владельцем всех рисков и отвечать за всех одновременно. Иначе у него не останется времени на то, чтобы в целом управлять проектом. Например, управление риском неохвата всего персонала заказчика для обучения в виду их отсутствия по различным причинам должно происходить на стороне заказчика путем назначения ответственных. Как вариант, руководителей подразделений в части организации своих сотрудников для прохождения обучения.
В процессе управления имеющимся списком рисков необходимо просчитывать возможность возникновения следующих или даже новых рисков и пополнять реестр рисков с расчётом стратегии по реагированию на них. То есть вести работу на опережение через просмотр на срабатывание риск-триггеров. Например, вероятность наступления риска ещё далека, но по некоторым сигналам можно определить, что ситуация нагнетается и риск может произойти раньше запланированного.
Ещё одной предупредительной мерой может быть наличие плана С. Так или иначе при стратегии реагирования на риск всегда имеется как минимум план А, а если что-то пошло не так, то выполняется план В. Но в некоторых случаях можно предусмотреть также план С, когда количество векторов развития событий высоко, и когда и план А, и план В могут не так пойти или реакция на эти риски окажется не той, которую ожидали.
Рисками надо управлять
Правильное управление рисками – процесс достаточно интересный, но сложный. Он требует постоянного внимания проектного менеджера, регулярного развития у него соответствующих компетенций. Поэтому стоит отметить, что если не заниматься управлением рисками, то это приведет к срыву проекта и весьма отрицательно скажется на репутации компании.Бороться с рисками бессмысленно, ими надо управлять.
Управление рисками проекта
Управление рисками проекта — сложная задача. Статья поможет вам разобраться с тем, как определять, анализировать и контролировать риски.