Управление рисками проекта
Проект внедрения программного продукта 1С представляет собой сложный процесс, в котором присутствуют и технологические, и интеллектуальные ресурсы как заказчика и исполнителя, так и внешних консультантов, партнеров, соисполнителей. Процесс внедрения системы автоматизации чаще всего связан с высоким уровнем рисков, носящих организационный и технологический характер.
В настоящей статье мы рассмотрим основные практические моменты по управлению рисками проекта внедрения программного обеспечения, которые могут возникнуть.
РИСКИ ПРОЕКТА НА ЭТАПАХ ЖИЗНЕННОГО ЦИКЛА
Жизненный цикл проекта по внедрению программ 1С состоит из нескольких этапов, на каждом из которых присутствуют свои риски. Также существуют общие риски всего проекта.
К общим проектным рискам обычно относятся:
риски в виде отсутствия поддержки со стороны руководства заказчика;
отсутствие четкого разделения ответственности между проектными командами заказчика и исполнителя, а также внутри самой проектной команды;
недостаток времени у проектной команды заказчика в связи с выполнением текущих функциональных обязанностей;
отсутствие соответствующей компетенции у персонала;
предоставление неполноценной или несогласованной информации;
недоступность технической информации для исполнителя и прочее.
На этапе продажи проекта внедрения системы 1С существенным риском является ошибка в оценке затрат на реализацию проекта. Это связано с ценообразованием, которое в первую очередь строится исходя из высокой конкуренции между исполнителями. И некорректная оценка затрат на проект напрямую связана с тем, что на этом этапе заказчик ещё не может полноценно определить или сформулировать требования к внедряемому программному продукту. Как следствие, технические специалисты исполнителя не могут детализировано провести оценку проектных работ. А менеджер по продажам, преследуя цель получения проекта может занизить экспертную оценку в угоду оптимистичной оценке предстоящего проекта. Как следствие неверная оценка затрат проекта приводит к негативным последствиям для всего проекта, включая его срыв.
На предпроектном обследовании системы и формализации требований выполняется интервьюирование специалистов заказчика с целью сбора и категоризации основных требований ключевых пользователей системы 1С. Обычно в этом процессе участвуют специалисты заказчика нескольких организационных подразделений, что являет собой различные взгляды, как на цели и задачи проекта, так и на некоторые нюансы автоматизации бизнес-процессов. Результатом разобщенности во взглядах на данном этапе может стать общая неудовлетворенность во внедренной информационной системе, затягивание периода опытной эксплуатации и существенный поток замечаний и претензий в адрес исполнителя.
На этапе проектирования и разработки осуществляется проработка архитектуры системы в целом, а также некоторых её модулей. На этом этапе велики технологические риски, связанные с ошибкой решения в части архитектуры информационной системы или неполной проработкой отдельных модулей и/или взаимосвязей между ними, неучтенными нефункциональными требованиями, такими как отклик системы на действия пользователя, надежность данных, их масштаб и технические возможности оборудования заказчика и т.п. Критичным является то, что выявление этих рисков происходит в достаточно поздние сроки, например на стадии опытной эксплуатации или эксплуатации на реальных данных реальными пользователями 1С. Это приводит к необходимости экстренного выполнения доработок или даже возможного срыва проекта в целом в силу непригодности системы к реальной и полноценной эксплуатации.
Как правило, этот этап является самым длительным, и основная причина появления рисков в процессе разработки — это недостаточный анализ требований или неоднозначная их трактовка, что приводит к тому, что результат не соответствует ожиданиям представителей заказчика.
При внедрении информационной базы довольно часто исполнителю приходится сталкиваться с непринятием сотрудниками заказчика обновленного функционала системы, её пользовательского интерфейса и т.п. Если не контролировать этот риск, то он может перерасти в открытый саботаж пользователями новой системы. Также ситуация может усугубляться неподготовленностью информационной инфраструктуры заказчика к внедрению программного обеспечения, что является причиной срывов сроков проекта и необходимостью доработки или адаптации программного обеспечения за счет увеличения бюджета проекта.
На стадии завершения проекта и поддержки пользователей в период опытно-промышленной эксплуатации системы очень часто встречается риск, обусловленный отсутствием службы поддержки со стороны заказчика или её некомпетентности из-за отсутствия навыков по работе с новой конфигурацией системы. Это приводит к тому, что ликвидация сбоев системы становится неоперативной или поддержка конечных пользователей не является комплексной и полноценной.
РИСК-МЕНЕДЖМЕНТ ПРОЕКТА
Если проектный менеджер (как со стороны исполнителя, так и со стороны заказчика) не видит преград в реализации проекта, то в большинстве случаев это говорит о том, что он скорее всего не потрудился на старте их поискать и придумать как с ними лучше всего разобраться.
А риски в итоге возникают (это неизбежно) и приходится их в суете решать. Но ведь можно это сделать заранее и спокойно, до старта проекта.
В проектном управлении существует такое понятие, как «риск-менеджмент». Но нужно понимать, что риск-менеджмент — это не только составление и просчет рисков проекта на определенных его этапы. Риск-менеджмент — это спокойная, без истерик и суеты, сенсорика и разрешение проектному менеджеру думать о том, что что-то пойдет не так.
Управление рисками проекта можно разделить на 3 части:
Идентификация, анализ и оценка рисков проекта
Определение мероприятий по управлению рисками
Контроль и мониторинг рисков проекта
Но простого разделения на части процесса управления рисками недостаточно, ведь управление рисками имеет под собой некую цикличность, когда в зависимости от возникающих изменений требуется выполнять одни и те же процессы управления:
При определении рисков необходимо исходить не только из методологии определения и расчета рисков, но и из опыта реальных проектов внедрения программ 1С, имеющейся базы знаний, областей деятельности компании, в которой реализуется проект. Требуется участие не только исполнителя, который определит основные существующие риски проекта внедрения, но и заказчика, который заложит риски в виду нюансов и особенностей ведения деятельности компании.
Перед стартом проекта проводится работа по идентификации возможных и существующих рисков. Процесс идентификации представляет собой поиск всех возможных рисков, по итогам которого мы должны найти ответы на вопрос:»Что может пойти не так? » (для негативных рисков). Но при поиске ответов на вопрос:»Что может пойти не по плану? » можно найти и позитивные риски.
При планировании рисков следует учитывать, что большим количеством рисков одновременно и качественно управлять невозможно, поэтому цель качественного анализа рисков проектов состоит в группировке и расстановке приоритетов.
Оценка рисков проекта и идентификация проводится для составления плана реагирования на риски. Оптимально управлять одновременно не более 10 рисками.
Этот этап является одним из сложных, так как принятые решения по ликвидации или снижению рисков затрагивают основные составляющие управления проектом: объем, бюджет и сроки проекта. То есть необходимо учитывать тройное ограничение проекта:
Такое ограничение говорит о том, что, как и у треугольника, нельзя изменить одну сторону, не задев как минимум ещё одну. Изменение одного параметра управления проектом влияет и на другие параметры.
Поэтому процесс контроля и мониторинга рисков ориентирован на оценку текущей ситуации по проекту: управление рисками, анализ возникших отклонений, контроль изменений и их влияния на все параметры проекта.
При выборе стратегии управления рисками проекта необходимо учитывать понятие о риске проекта. Риск проекта — это неопределенное событие, которое в случае его возникновения имеет негативное или позитивное воздействие как минимум на один из параметров проекта (например, срок или бюджет проекта).
Исходя из логики определения риска проектов можно выделить следующее:
Риск имеет как негативную, так и позитивную сторону. Дело в том, что при переводе с английского слово «риск» имеет значение «шанс».
Риск — это неопределенное событие, то есть событие, которое может произойти или нет с некоторой вероятностью. Таким образом мы должны понимать, что событие не считается риском, если мы точно знаем, произойдет оно или нет.
Риск влияет на проект. То есть если какое-то событие (например, засуха на другом материке) не влияет на цели и параметры проекта, то это не является риском.
Любой риск имеет два обязательных параметра: влияние и вероятность возникновения.
При расчетах величины риска значения влияния и вероятности возникновения определяются по шкале от 0 до 1:
0 — известно, что событие определенно не произойдет
1 — известно, что событие определенно произойдет.
0 и 1 — это крайние значения, которые не должны учитываться в оценке, так как риск имеет под собой вероятностную природу. Например, если что-то точно произойдет, то это уже не риск, а состоявшееся событие, то есть свершившийся факт. Следовательно, в таком случае необходимо управлять не риском, а изменениями, которые на это событие повлияли.
В процессе расчета величин риска определяются стратегии ликвидации рисков. При этом можно использовать следующие мероприятия по реагированию на риски:
Уклонение от риска предполагает корректировку плана управления проектом так, чтобы максимально исключить угрозу негативного риска, а также снизить последствия риска для целей проекта (например, пересмотреть график проекта или изменить объемы путем исключения некритичных модификаций). Важно заметить, что некоторых рисков можно избежать, если на ранних стадиях проекта детализировано собирать требования заказчика, налаживать более приятные коммуникации.
Передача риска осуществляется путем переложения негативных последствий риска под ответственность третьей стороны. При этом необходимо понимать, что при передаче управления риском третьей стороне сам риск не снимается. Такая стратегия управления риском эффективна в части финансовых рисков. Например, страхование, гарантии выполнения контракта, выдача гарантийных обязательств и т.п. Естественно, что условия передачи рисков третьей стороне несут в себе обязательства по выплате премии за риск третьей стороне. Если проект подразумевает оплату фактических издержек заказчиком, то бремя выплаты премии может быть переложено на заказчика, а вот с фиксированной ценой контракта это бремя обычно ложится уже на исполнителя.
Снижение риска предполагает уменьшение вероятности и/или последствий рискованного события до необходимых пределов. То есть стратегия состоит в формировании предупредительных мер по снижению вероятности негативного события или последствий его наступления, т.к. предупреждение всегда эффективнее, чем разрешение последствий свершившегося факта. Как пример снижения риска можно привести работу по планированию человеческих ресурсов как на стороне заказчика (бизнес-эксперты, ключевые пользователи), так и на стороне исполнителя (консультанты, разработчики) в случаях их болезни, отпуска или увольнения. Как предупредительная мера может использоваться оптимизация сложных процессов за счет их упрощения (исключить неактуальные действия или пересмотреть схему движения бизнес-процесса), увеличение количества тестовых испытаний на реальных данных с активным участием пользователей, выполняющих соответствующие функциональные обязанности и прочее.
Использование риска выбирается в качестве стратегии реагирования на благоприятные последствия случившегося события. Примером использования может служить возникновение возможности по привлечению специалиста более высокого уровня с целью сокращения времени на реализацию определенных задач проекта. Также примером является отказ от модификации в пользу использования стандартного функционала системы в виду изменения методологии бизнес-процесса.
Усиление через позитивное воздействие на складывающуюся ситуацию позволит повлиять на условия формирования события в положительном ключе. Один из примеров реагирования на такой положительный риск — это привлечение специалиста со стороны заказчика, находящегося на более высоком уровне принятия решений по проекту, в случае каких-то согласований задач по модификациям.
Результатом работ по определению стратегий нивелирования рисков должен явиться план по управлению рисками (он же реестр рисков). Данный реестр относится к проектной документации, и его актуализация производится на протяжении всего жизненного цикла проекта за счет мониторинга и контроля рисков.
В данном реестре рисков кроме перечня возможных рисков определяется, как данный риск влияет на проект, учитывается величина риска по вероятности наступления и степени его влияния и определяются мероприятия (стратегия) по управлению этим риском.
Пример реестра рисков:
№ | Описание риска | Потенц. воздействие на проект | Вероятн. возн-ия | Влияние на проект | Уровень риска | Вариант решения |
1 | Недостаточное внимание к проекту со стороны бизнес-экспертов (например вследствии их занятости текущей работой или участия в других проектах). Возможно, риск проявится на интеграционном тесте | — Эксперты не выдают ответную реакции и тормозят проект или ведет к сдвигу сроков старта— Недостаток ресурсов от Заказчика | 0,4 | 0,9 | 0,36 | 1) Заранее оговорить возможность подключения доп. экспертов в случае занятости основных участников2) заложить в бюджет проекта (заказчику) доп. мотивацию экспертов на резульатты проекта (премирование по завершению проекта)3) Привлечение спонсора проекта к решению конфликта ресурсов4) Замена бизнес-эксперта на менее занятого специалиста |
2 | Отставание в разработке скриптов или модификаций | 0,3 | 0,5 | 0,15 | 1) Позиционирование задач по проекту как задач 1 приоритета2) Заложить резервы в плане работ между модификациями и началом интеграционного теста3) Для модификаций: приостановка всех остальных модификаций4) Для скриптов: определение приоритетных и необходимых к старту | |
3 | Смена заказчика | 0,2 | 0,6 | 0,12 | вести документацию, встретится с новым заказчиком сразу после смены | |
4 | Смена требований | 0,8 | 0,9 | 0,72 | дизайн решения, хорошая документация, записи, протоколы | |
5 | Производительность системы, блокировки | Низкая производительность системы может привести к простоям при работе ключевых процессов (приемка/отгрузка) | 0,5 | 0,5 | 0,25 | замеры при большом объеме, можно риски оптимизации взять на себя, увеличение мощности серверов, добавление памяти и т.д. 1) Разводим сервер приложений и SQL сервер на разное «железо» — Трилайн2) Планирование железа с резервом относительно рекомендаций вендора |
6 | Фин. Стабильность заказчика или изменчивость заказчика | часто меняющиеся приоритеты и взгляды заказчика | 0,4 | 0,9 | 0,36 | дробить акты на более мелкие этапы и чаще актироватьсяне начинать следующий этап пока не подписан акт за предыдущий |
7 | Смена проектной команды — мониторить состояние людей и искать замену если кто-то уходит | 0,7 | 0,7 | 0,49 | мониторить состояние людей и искать замену если кто-то уходит | |
8 | Предварительная оценка трудоемкости по задачам проекта не соответствует оценке, уточняемой сейчас по факту написания ФД, т.к.ФД отсутстовали момент подготовки первоначальной оценки | Неверная (оптимистичная) оценка сроков разработки может повлечь срыв сроков по подготовке к старту | 0,8 | 0,9 | 0,72 | 1. Упрощение функционала, отказ от неприоритетных требований2. сдвиг сроков проекта, расширение бюджета проекта1) Закладывание в план резервов по времени относительно оценки трудоемкости — ФТО2) Разделение модификаций на критичные для старта и некритичные — и выполнение в соответствии с приоритетами (некритичные модификации, не готовые на момент начала интеграционного теста не участвуют в нем) — ФТО |
9 | Работа во время нового года — 1) недоступность компетентных людей на филиалах. Если потребуется оперативно поменять БП, то это не с кем будет обсудить. Например, решение по включению в работу доп. операторов никто не сможет исполнить2) недоступность экспертов. Пример — до старта принято решение о сохранении кредитного лимита, после старта выявляется, что необходимо отключить кр. лимит. Этот вопрос будет не с кем согласовать | срыв сроков запуска, старта системы | 0,5 | 0,8 | 0,4 | Письмо от РП на директора:1) на каждом филиале должно быть выделено ответственное лицо (нач. ООЗ или операторов выписки), который будет доступен 01.01.хх гг. С ними предварительно обсудить возможные сложности при старте2) Получить контакты всех экспертов проекта3) Получить полномочия на принятие решений своими силами (В случае если связаться с экспертами не удается — принятие решений производить самостоятельно) |
10 | Возникновение проблем с каналом в Омске/Москве в новый год. Работы выполнены не будут, так как провайдер оперативно проблему не решит | срыв сроков запуска, старта системы | 0,4 | 0,8 | 0,32 | В Омске: Есть два магистральных канала в офисе. Если даже закрыть риск сбоя в обоих, то необходимо протестировать работу каналов на дому у одного из специалистов, осуществляющих перенос остатковВ ЦО: риска нет |
11 | Есть изменения в алгоритмах работы пользователей. Это может повлечь человеческие ошибки | 0,8 | 0,8 | 0,64 | Информирование специалистов на филиалах по двум каналам — через лидеров на филиале и через функциональных руководителей (Координация действий осуществляется через службу поддержки, с использованием ленты сообщений в аксапте, телефона, e-mail) | |
12 | Риск падения производительности в первые 5 дней после старта новой базы (из-за быстрого роста базы) | падение производительности и блокировки из-за одновременной работы многих пользователей и нагрузка по загрузке остатков | 0,8 | 0,9 | 0,72 | 1) Периодический пересчет статистики2) Продумать вариант подключения доп. оборудования для нужд статистики и периндексации — например, узел от архивной и офлайна.3) Анализ и выявление таблиц, по которым может потребоваться переиндексация (а также выяснение времени, необходимого на переиндексацию).В случае возникновения проблемы проводить переиндексацию по необходимым индексам (возможно, потребуется останов), временное увеличение мощности серверов |
13 | Для запуска новой базы будет необходим длительный останов (более суток) | 0,9 | 0,9 | 0,81 | 1) Тест производительности2) В случае, если тест производительности покажет, что времени впритык — подготовка алгоритма действий для возврата к работе в старой базе (например, перенос заказов на 2007 год из новой базы в старую, ярлыки)Возврат на старую базу до 12:00ч 01 января. Проведение повторно работ с 31 января на 01 февраля | |
14 | Невозможность выхода на работу кого-либо из членов команды проекта в критический момент. Например, в новый год по причине болезни | 0,5 | 0,5 | 0,25 | Необходимо заранее договориться какие члены в команде должны быть взаимозаменяемыми, как со стороны ФТО, так и со стороны Заказчика. Перед новым годом провести «передачу знаний» | |
15 | Служба поддержки (при текущем графике работы) не будет справляться с поступающими вопросами от пользователей. | 0,8 | 0,9 | 0,72 | Заранее утвердить график работы службы поддержки (с учетом повышенной нагрузки) на первые 5 рабочих дней января.В случае, если служба поддержки не будет справляться, временно перебросить им в помощь одного разработчика. | |
16 | Закрытие декабря и текущего года, а также января следующего года не будет выполнено во время | в момент старта новой системы еще не буде закрыт период в старой системе и не будет реалных данных по остаткам | 0,5 | 0,9 | 0,45 | 1) Требуется заранее согласовать с руководством ЮМ возможное отставание2) На помощь в закрытии выделить двух квалифицированных специалистов службы поддержки3) перенос временных остатков по тем данным что есть в старой базе. После закрытия периода доперенос остатков |
17 | С 27.12 будет действовать две базы — старая и новая для ввода заказов на следующий год. При этом в старой базе могут изменить настройки и справочники, которые не попадут в новую (случайно, т.к. права должны быть закрыты по плану)Либо пользователи будут выполнять операции не в той базе | 0,7 | 0,9 | 0,63 | 1. Выслать на всех пользователей аксапты, и ежедневно дублировать, требование не изменять справочники и настройки в старой базе с 27.12 по 31.122. Программные запреты на выполнение операций в неправильной базе3. Вручную откорректировать справочники в старой базе в случае расхождения. Операции сторнировать и вводить в правильную базу | |
18 | Объем ручной работы бухгалтеров по переносу остатков может сдвинуть срок закрытия | 0,5 | 0,7 | 0,35 | 1. По результатам сформированного дизайн-решения удалось добиться минимальной ручной работы. Есть подтверждение, что доп.ресурс не нужен2. В случае тотального кризиса подключение поддержки к выполнению сверок | |
19 | Сжатые сроки выполнения работ | 0,5 | 0,9 | 0,45 | Подневное планирование работ руководителями проектных группПодготовка и тщательное соблюдение процедуры для согласования документов, как наиболее рисковой в части подготовки Концептуального проекта.Сформировать временной резерв в части даты запуска проекта в продуктивную эксплуатацию. | |
20 | Расширение объема проекта в ходе выполнения | 0,6 | 0,9 | 0,54 | Необоснованное расширение объема проекта в ходе выполнения ведет к затягиванию сроков и удорожанию пилотного проекта, а так же усложняет дальнейшееДля минимизации данного риска руководители проектных групп должны понимать границы проекта (см. раздел 3) и обеспечивать их соблюдение. При возникновении отклонений они должны фиксироваться и рассматриваться согласно процедуре одобрения запросов на изменения. | |
21 | Большое количество модификаций | 0,8 | 0,9 | 0,72 | Минимизация данного риска должна быть достигнута с помощью определения в качестве одной из задач проекта использования стандартной функциональности и лучших практик 1С.Любая модификация стандартной функциональности 1С должна быть оформлена запросом на изменение и пройти процедуру одобрения для включения в проект. Каждая модификация будет оцениваться с точки зрения возможных затрат, выгод, обходных путей. | |
22 | Один руководитель возглавляет несколько проектных групп | 0,5 | 0,8 | 0,4 | Основные негативные влияния риска: перегруз руководителей оперативными задачами, срыв сроков подготовки проектных решений, недостаточный уровень качества проектных решений для передачи в реализацию, замедление формирования 1С-экспертизы у проектной группы.Для устранения влияния данного для каждой проектной группы нужно назначить отдельного руководителя.Для снижения влияния данного риска для руководителей, возглавляющих сразу несколько проектных групп следует предусмотреть заместителей, которым будет делегированы необходимые полномочия. | |
23 | Один сотрудник выступает в качестве эксперта в нескольких проектных группах | 0,5 | 0,8 | 0,4 | Основные негативные влияние риска: невозможность независимой работы групп, необходимость согласования загрузки бизнес-экспертами между различными проектными группами. Бизнес-эксперты перегружены информацией по различным функциональным модулям 1С, что затрудняет ее усвоение.Риск может быть минимизирован распределением бизнес-экспертов по отдельным группам (определение будущей специализации бизнес-эксперта), с возможностью привлечения другими проектными группами по договоренности между руководителями групп. | |
24 | Перераспределение нагрузки в разнородных проектных группах | 0,5 | 0,6 | 0,3 | Большинство проектных групп являются разнородными состоят из представителей клиента и ФТО. Некорректное перераспределение работы внутри группы может привести к удорожанию проекта, затягиванию сроков, замедлению формирования 1С-экспертизы у сотрудников клиента и ФТО.Для минимизации данного риска руководители рабочих групп должны понимать корректное распределение работ между участниками, соответствующим образом составлять рабочие планы, вести их оперативный контроль, своевременно направлять вопросы руководству проектом. | |
25 | Отсутствие у клиента на дату начала проекта подготовленной проектной команды и специалистов по 1С. | Основным негативным влиянием риска является затягивание сроков проекта в связи с необходимостью обучения новому решению, вероятность принятия некорректных решений в связи с недостатком знаний о 1С, сложности с поддержкой и тиражированием решения силами клиента и ФТО | 0,5 | 0,8 | 0,4 | Для минимизации данного риска следует организовать обучение проектной команды согласно рекомендациям фирмы 1С. Руководители проектных групп отвечают за формирование 1С-экспертизы в своих группах и имеют право запросить проведение дополнительного обученияУчастники проектной команды клиента и ФТО приобретают практический опыт использования 1С при выполнении задач проекта. |
26 | Не полное понимание и принятие, бизнес-экспертами и сотрудниками проектных групп клиента стандартных бизнес-процессов и лучших практик 1С. | срыв сроков запуска проекта, сложности в реализации модификаций | 0,7 | 0,7 | 0,49 | Проведение обучения стандартным функциональным возможностям 1С и тест-скриптов системы по наложению бизнес-процесса на стандартный функционал системы.Руководители проектных групп продвигают одно из основных допущений проекта: использование стандартной функциональности и лучших практик 1С. |
27 | Бизнес-процессы, разработанные в по головному предприятию, не будут приняты на пилотной площадке | 0,3 | 0,8 | 0,24 | Мастер-эксперты и руководители проектных групп отслеживают отклонения существующей организации бизнес-процессов и модели бизнес-процессов, спроектированной в Концептуальном проекте. В случае возникновения существенных отклонений должна быть обеспечена тесная коммуникация с пилотной площадкой для обеспечения реализуемости изменений. | |
28 | Неработоспособность более 10% функционала после переноса модификаций | 0 | Добавление ресурса разработки ФТО | |||
29 | Невозможность полноценного переноса функционала на внедряемую редакцию | 0,5 | 0,6 | 0,3 | Изменение функционала ПО | |
30 | В период между полной готовностью ПО и стартом появятся изменения в законодательстве, требующие модификаций, и ПО на момент старта не будет соответствовать ему в полном объеме | 0,6 | 0,7 | 0,42 | Добавление ресурса разработкиСо стороны бизнес-эксперта заказчика — постоянный мониторинг изменения законодательства в части планируемой автоматизации бизнес-процессов | |
31 | Не будет выделено достаточное время пользователей на обучение — пересечение с рабочим графиком | — Плохое качество обучения— Плохое понимание нового функционала, непривычность к интерфейсу → ошибки в работе с новой системой → возможные проблемы с отгрузкой | 0,6 | 0,9 | 0,54 | 1) Минимум за неделю до старта обучения согласовать комфортный график обучения2) по результатам обучения провести аттестацию, тестирвоание3) Резервы времени по обучению людей, выполняющих бизнес-критичные операции — ФТООбучение будет проводиться по группам пользователей (склад — отдельно, заявки — отдельно и т.п.), вместе с группами обучаются непосредственные руководители4) со стороны заказчика — контроль и планирование текущей работы и графика работы сотрудников |
32 | Большой объем разработки → ошибки в новом функционале → возможны проблемы на старте (оперативного плана) | 0,5 | 0,8 | 0,4 | Выделение достаточного объема времени на интеграционный тест | |
33 | Срыв сроков закрытия периода в старой системе, может привести к задержке закрытия месяца старта в новой | 0,5 | 0,8 | 0,4 | мер нет на заказчик должен быть к этому готов. | |
34 | Большая загрузка бизнес-экспертов, может пострадать качество приемки разработанной системы (интеграционного теста) | 0,7 | 0,9 | 0,63 | Планирование интеграционного теста в период с наименьшей загрузкой экспертовПланирование замены бизнес-экспертов для приема функционала системы | |
35 | Изменяются настройки кредитного лимита — могут быть проблемы с недоотгрузкой в первые дни работы | 0,8 | 0,4 | 0,32 | Проверка кредитных лимитов перед запуском системы (руководитель отдела) | |
36 | Новый документооборот склада → путаница в рядах операторов, бухгалтерия может потом «не собрать» нужные документы | 0,8 | 0,6 | 0,48 | Предварительное обучение людей (операторы) именно документооборотуОформление подробных инструкций пользователя со схемами документооборота | |
37 | Коммуникационный риск («правая рука не знает что делает левая») между ФТО и субподрядчиком — системным администратором по тех. поддержке ТСД | 0,4 | 0,7 | 0,28 | с даты старта — еженедельные совещания (Бухгалтерия + Склад + Продажи + Закупки + ИТ + ФТО) по ходу работ, в течение первой недели после старта — ежедневные — с субподрядчиком | |
38 | Риск наложения ввода 2-х проектов одновременно работа с ТСД и ФТО. Риск некорректной работы ПО для ТСД, используется не тиражное решение | 0,5 | 0,7 | 0,35 | Предусмотреть в плане интеграционного теста этап проверки сопряжения с ТСД по всем функциям — ФТОПрогон по работе с ТСД всех кладовщиков на складе (еще до сопряжения с аксаптой) — субподрядчик | |
39 | Интеграционный риск (интеграция с кассами не будет работать корректно, в результате нарушается ключевой бизнес процесс розничных продаж) | 0,5 | 0,9 | 0,45 | Предусмотреть в плане интеграционного теста этап проверки сопряжения кассами по всем функциям — ФТО | |
40 | Расширение рамок проекта в плане функционального объема (на интеграционном тесте) | 0,5 | 0,8 | 0,4 | Анализ и распределение по степени критичности и необходимости внедрения к дате старта | |
41 | Риск проявления ошибок в ходе согласования процессов (недостаточная полнота или точность информации), которые приведут к неработоспособности процессов по факту | 0,5 | 0,8 | 0,4 | Проведение интегротеста принимаемого функционала системы должно выполняться не только по выполненым модификациям, но и по стандартному функционалу ПО | |
42 | Функциональный риск — новый функционал резервирования продукции под существующие заказы. Может привести к путанице и снижению контроля за товарным объемом | 0,5 | 0,8 | 0,4 | Предусмотреть в плане интеграционного теста детальную проверку функционала резервирования — ФТОПредоставить кейсы примеров по всем вариантам резервирования товаров — Заказчик | |
43 | Отсутствие утвержденной учетной политики и плана счетов может привести к изменениям относительно согласованного дизайна | 0,3 | 0,7 | 0,21 | Детальное интервью со службой бухгалтерии | |
44 | Нарушение товародвижения (расхождения фактических остатков и движений по складу с операциями в системе) | 0,5 | 0,8 | 0,4 | Только интеграционный тест, других вариантов нет. ФТО (качественный план) + Субподрядчик (выделение времени) | |
45 | Не укомплектован штат пользователей. Предварительно определено, что должно быть 2 человека в ночь, днём 1 |
