Контроль рисков и неопределенностей проекта автоматизации учётной и управленческой деятельности предприятий не теряет своей актуальности. Этому вопросу уделяют значительное внимание и стандарт PMBoK, и некоторые ИТ-стандарты. Тем не менее, большинство руководителей проектов предпочитают вообще не задумываться о рисках.
PMBoK (Project Management Body of Knowledge) — свод профессиональных знаний по управлению проектами, которые обычно считаются хорошей практикой, является Американским национальным стандартом. В нём описываются суть процессов управления проектами в терминах интеграции между процессами и взаимодействий между ними, а также цели, которым они служат.
Источник: www.wikipedia.org/
Проектов без рисков не бывает
Изучение опыта предприятий по проведению проектов автоматизации свидетельствует о том, что у руководителей функциональных подразделений предприятий часто возникает стремление «провести проект, как все» и использовать только типовые решения, которые на слуху. Создаётся иллюзия, если «быть как все», то рисков можно избежать. Более того, при этом часто руководствуются тезисом: «Мы не какие-нибудь авантюристы, чтобы реализовывать опасные проекты. Наш проект не должен быть слишком сложным, и на нем никто не собирается рисковать. Мы хотим внедрять типовую программу типовым способом, и не намерены делать рискованных шагов».
Но возможно ли, чтобы на ход и результат проекта «как все» не оказывали влияния никакие неопределенности? Как ни парадоксально, в предельном случае — да! Но только теоретически, поскольку в жизни, в том числе и в жизни предприятия, «абсолютно безопасные» проекты никому не нужны. Как писал в своих книгах Том де Марко1Том де Марко2, «Проекты без риска — удел неудачников».
В жизни, в том числе и в жизни предприятия, «абсолютно безопасные» проекты никому не нужны. «Проекты без риска — удел неудачников».
Строго говоря, проект тем и отличается от операционной деятельности, что при его выполнении создается нечто новое. Если при автоматизации предприятия до минимума урезать элемент новизны (совсем исключить не получится, поскольку внедряемая информационная система — новая, по определению), то соответственно уменьшаются неопределенности. Но одновременно снижаются возможные конкурентные преимущества, которые могло бы получить предприятие от новой системы. В лучшем случае будет реализовано то, что давным-давно работает на множестве других предприятий-конкурентов.
Означает ли это, что более рискованный проект предпочтительнее типового, поскольку больше инноваций создадут больше преимуществ? Нет, не означает! И большинство руководителей и специалистов подразделений понимают, что создавать заказную систему «с нуля» неоправданно безрассудно. Неоправданно, потому что те же самые преимущества можно получить с гораздо меньшими сопутствующими неопределенностями. А, самое главное, не факт, что новый продукт будет лучше, чем типовой, ведь можно изобрести давно изобретенный велосипед.
При выборе продукта для автоматизации (информационной системы) в рассматриваемом контексте надо обратить внимание на следующее:
- действительно ли он более инновационный и даст предприятию что-то дополнительное, чего нет в «более типовом» решении, с помощью которого ведут свою деятельность конкуренты;
- есть ли у поставщика инновационного решения готовые технологии для контроля рисков проекта.
Не обязательно, и, точнее, даже нежелательно, чтобы управление рисками воспринималось как сложный формализованный многоступенчатый процесс. На самом деле, заметки на листе бумаги или письмо по электронной почте уже могут быть частью контроля рисков. Суть не в том, чтобы «наворотить» как можно больше лишней бюрократии. Достаточно просто обозначать неопределенности, анализировать их и принимать меры по ограничению найденных угроз.
Не обязательно, и, точнее, даже нежелательно, чтобы управление рисками воспринималось как сложный формализованный многоступенчатый процесс.
Не следует требовать от консультантов или внедренцев информационной системы: «Убедите меня, что проект будет безрисковым!». Если поставщик берется доказывать абсолютную предсказуемость всего, что может возникнуть при автоматизации, то он или лукавит, или пытается продать «типовой проект для неудачников». Более целесообразно, не стесняясь, высказывать все свои опасения относительно рисков и выяснять, есть ли у поставщика реальный опыт снижения проектных неопределенностей на других предприятиях.
Соответственно, приоритет в выборе продукта-прототипа и партнера для внедрения лучше устанавливать не по иллюзиям «самого безрискового проекта», а по информации об успешной практике контроля рисков.
Хорошие руководители проектов умеют определять и планировать задачи, которые необходимо выполнить для реализации проекта. Но только лучшие руководители проектов успешно справляются с тем, чтобы определить и создать резерв ресурсов под задачи, которые вдруг могут возникнуть в ходе проекта.
Советы и способы расчета рисков
Консультанты и специалисты по автоматизации постоянно совершенствуют проектные технологии и вводят в практику выявление рисков предстоящего проекта. Многие руководители, особенно не имеющие проектного опыта, недоумевают: «Откуда мы знаем, какие задачи могут внезапно возникнуть на проекте в будущем? Как можно угадать, с чем придется бороться?!»
Понятно, никто не может запросто заглянуть в будущее. Но одно из необходимых качеств менеджера заключается в умении прогнозировать развитие событий на основе той информации о неизвестном, которая уже имеется, пусть даже это всего лишь крохи данных и обрывки сведений. Тем более, что руководителю проекта не надо изобретать и составлять с нуля новый исчерпывающий список рисков на каждый новый проект автоматизации. Можно использовать имеющуюся статистику по наиболее распространенным и значимым рискам проектов автоматизации и наложить на нее свои накопленные данные. Так, среди возможных рисков могут быть:
- невозможность выполнения требований (спецификаций проекта) имеющимися инструментами;
- возникновение кадровых проблем;
- изменение требований к системе в виду объективных обстоятельств.
Есть еще риски, которые проявляются реже, но их следует упомянуть, это — планирование нереальных сроков под давлением владельцев проекта и снижение производительности исполнителей в ходе работ.
Если предпосылки к «давлению» или «снижению» уже имеются, то они обычно не слишком замаскированы, и их можно идентифицировать в самом начале проекта. Иными словами, тут чаще сталкиваются не с неопределенностью проекта, а с вполне определённым отсутствием проблемы либо с заведомо известным её наличием.
Заложить в проект запас времени по всем возможным рискам в предположении, что они все реализуются сразу, будет полярной крайностью, поскольку делает проект избыточно затратным.
Далее перечисленные статистические неопределенности и риски надо наложить на свой опыт, то есть, проанализировать практику ранее выполненных проектов — насколько часто риски реализовывались и к какому дополнительному расходу ресурсов приводили (обычно под ресурсом можно понимать деньги и время).
Если у предприятия нет своей накопленной практики, не беда. В любом случае общеотраслевая статистика уже задает руководителю проекта более конкретное направление для размышлений. Ему не нужно гадать, «какие неприятности вообще возможны на проекте ААА, и каких дополнительных ресурсов они могут потребовать». Вместо этого у него уже есть «система координат», и вопросы сводятся к более предметным, например: «какой резерв времени нужно добавить для нейтрализации возможного увольнения одного из специалистов?».
Очевидно, что заложить в проект запас времени по всем возможным рискам в предположении, что они все реализуются сразу, будет полярной крайностью, поскольку делает проект избыточно затратным. Одинаково безрассудно из диапазона всех неопределенностей взять как нулевые точки, так и сложить все максимумы.
В теории рекомендуется добавить к планируемым ресурсам резерв, рассчитанный как математическое ожидание неопределенности по формуле:
Дополнительный резерв = Вероятность Риска 1 * Затраты по Риску 1 + Вероятность Риска 2 * Затраты по Риску 2 + … + Вероятность Риска N * Затраты по Риску N,
где N — количество рассматриваемых рисков.
На практике вычисления часто упрощают, вводя среднестатистическую вероятность для каждого риска в размере 15-25%. Конечно, это большое допущение, но в любом случае оно лучше, чем зависимость от крайностей.
Стоит упомянуть и про альтернативные стратегии работы с неопределенностями. Так, создание резерва ресурсов для выправления последствий одного или нескольких реализовавшихся рисков — одно из направлений контроля, которое называется сдерживанием рисков. Кроме создания страхового запаса средств на восстановление хода проекта после реализации риска (сдерживание риска) — возможно применение стратегии ослабления риска. В этом случае компания несет затраты до возможного проявления риска, с тем чтобы если риск реализуется, то его последствия обошлись дешевле.
Если обратиться к языку формул, то под последствием имеется в виду упомянутое выше математическое ожидание:
Вероятность Риска * Затраты по Риску
То есть «предоплата» за ослабление риска может снизить как вероятность его возникновения, так и снизить затраты на исправление ситуации, если неприятность все же случится.
И третья стратегия работы с неопределенностями — избегание риска. В этом названии, разумеется, нет эмоциональной негативной окраски: это инструмент, который иногда целесообразно использовать, а иногда — нет. Этот вариант контроля неопределенностей заключается в том, чтобы вообще не выполнять какой-то из этапов проекта, на котором риски неудачи слишком велики.
«Предоплата» за ослабление риска может снизить как вероятность его возникновения, так и снизить затраты на исправление ситуации, если неприятность все же случится.
Например, некоторое время назад в типовых продуктах системы «1С:Предприятие» не все задачи сложного производственного планирования решались оптимальными методиками. И предприятия, заинтересованные в автоматизации планирования, ограничивались только внедрением только учетных функций, поскольку неопределенности в затратах и сроках достижения результата были высоки. Сегодня использование новых разработок позволяет автоматизировать производственное планирование даже в сложных процессных отраслях промышленности. Поэтому стратегия избегания риска в этом контексте перестала себя оправдывать.
Можно отметить и такие стратегии, как сдача риска, трансферт риска, передача риска, страхование риска, делегирование риска и т.д. В управлении проектами они сегодня мало используются.
Таким образом, контроль рисков проекта и управление ими подразумевает не только констатацию факта наличия неопределенности и рисков, но и анализ их последствий, что, свою очередь, позволяет заранее спланировать дополнительные ресурсы и выбрать соответствующую стратегию.
Задание для выполнения по этапу «Разработка плана управления рисками проекта автоматизации компании»
Разработать план управления рисками
проекта автоматизации компании:
1. Провести идентификацию рисков
проекта автоматизации:
1.1. Составить список рисков или условия
возникновения рисков.
1.2. Описать признаки рисков, по которым
их можно идентифицировать.
2. Оценить риски проекта автоматизации
(качественные и количественные оценки):
2.1. Оценить вероятность возникновения
и влияния рисков на проект автоматизации.
2.2. Определить степень важности каждого
идентифицированного риска (расставить
приоритеты реагирования на риски) и
упорядочить список рисков по приоритетам.
2.3. Определить риски, требующие скорейшего
реагирования и большего внимания, а
также влияние их последствий на проект.
2.4. Определить вероятность невыполнения
плановых сроков и бюджета.
2.5. Определить необходимые резервы.
2.6. Определить предполагаемые сроки
окончания проекта автоматизации с
учетом рисков.
3. Выполнить планирование реагирования
на риски:
3.1. Определить возможные способы
реагирования для каждого риска (избежание
рисков, передача рисков, минимизация
рисков, принятие рисков, альтернативный
план).
3.2. Составить план реагирования на риски.
В результате выполнения задания по
этапу «Разработка плана управления
рисками проекта автоматизации компании»
необходимо подготовить отчет «План
управления рисками проекта автоматизации
компании».
В структуре отчета приведены заголовки
разделов отчета. Содержание каждого
раздела отчета должно включать решение
соответствующего ему задания (см. Задание
для выполнения по этапу «Разработка
плана управления рисками проекта
автоматизации компании»).
Структура отчета «План управления
рисками проекта автоматизации компании»:
1. Идентификация рисков.
2. Оценка рисков.
3. Планирование реагирования на риски.
Этап 4. Подготовка итоговой презентации по проекту автоматизации компании
После завершения работы над проектом
автоматизации необходимо подготовить
итоговую презентацию по проекту в
соответствии с приведенной структурой.
Содержание каждого раздела презентации
должно включать основные решения и
выводы по проекту автоматизации компании.
Структура презентации «Разработка
проекта автоматизации компании»:
1. Стратегический план автоматизации:
1.1. Цели и задачи бизнеса компании.
1.2. Цели автоматизации компании.
1.3. Способ автоматизации компании.
1.4. Ограничения.
1.5. Функциональные требования к ИС.
1.6. Класс ИС.
1.7. Способ приобретения ИС.
2. Оперативный план автоматизации:
2.1. Структура проекта автоматизации
компании (диаграмма Gantt).
2.2. Ресурсное планирование проекта
автоматизации (отчет Who Does What When).
2.3. Стоимостный анализ проекта (отчеты
Cash Flow, Budget).
3. План управления рисками проекта
автоматизации:
3.1. Идентификация рисков.
3.2. Оценка рисков.
3.3. Планирование реагирования на риски.
Описание конкретных ситуаций по вариантам
Вариант №1. Автоматизация торговой
компании «Маркет»
Торговая компания «Маркет» открыла
свой первый магазин в 1998 г. в Москве,
после чего она стала активно развиваться
как сеть универсамов. В 1999 и 2000 г. было
открыто по 3 магазина в разных районах
Москвы, в 2001 г – 5 магазинов в Москве
и 1 в Московской области, в 2005 г. открыто
7 магазинов. Сейчас (2011 г.) компания
имеет 28 магазинов и к концу года планирует
открыть еще 9.
Основной целью своей деятельности
«Маркет» ставит обеспечение потребителя
качественными товарами по доступным
ценам.
«Маркет» занимается розничной продажей
большого количества разнообразных
товаров (продукты питания, печатная
продукция, бытовая химия, товары для
дома и т.д.), ассортимент которых постоянно
расширяется. В 1998 г. ассортимент
предлагаемых товаров насчитывал 2000
наименований, и к настоящему времени
достиг уже 12000 наименований. Компания
работает с различными поставщиками,
число которых достигло 300.
Торговая компания «Маркет» располагает
собственным производством полуфабрикатов
и кондитерских изделий, ассортимент
которых составляет 100 наименований
полуфабрикатов и более 30 видов кондитерских
изделий. Торговая компания имеет единый
распределительный центр, который
является центральным складом и
обеспечивает снабжение товарами сеть
магазинов.
Управление магазинами сети осуществляется
центральным офисом, который занимается
обработкой и анализом всей информация
о деятельности магазинов, разработкой
стратегии развития сети, набором
персонала для магазинов и т.д. В центральный
офис ежедневно поступает огромный объем
информации о деятельности магазинов,
который требует оперативного анализа
и принятия решения.
Центральный офис компании «Маркет»
включает коммерческий департамент,
департамент по торговле, финансовый
департамент, департамент по маркетингу,
департамент по логистике, департамент
по персоналу, департамент по информационным
технологиям.
Численность сотрудников торговой
компании составляет 3000 человек. В каждом
магазине численность персонала составляет
100 человек.
Годовой оборот компании в 2010 г.
составил $15 млн.
В 2005 г. в торговой компании «Маркет»
были установлены кассы, компьютеры
(Pentium), проложены сети и самостоятельно
разработана система ведения бухгалтерского
учета, которая автоматизирует следующие
функции: операции по банку и кассе;
взаиморасчеты с организациями, дебиторам
и кредиторами; расчеты по зарплате;
расчеты с бюджетом; учет товаров.
В 2005 г. была самостоятельно разработана
система ведения товарного учета, которая
автоматизирует: ведение учета складских
запасов и их движения; оформление счетов
поставщикам; формирование необходимых
первичных документов.
По мере развития компании, разработанные
системы устанавливались в новых
открываемых магазинах. Поддержка систем
ведения бухгалтерского и товарного
учета в настоящее время осуществляется
департаментом информационных технологий
компании.
Кроме того, в каждом магазине есть
системный администратор для поддержки
работоспособности системы.
С развитием компании возникла необходимость
не только в товарном и бухгалтерском
учете, производственном учете, но и в
управлении развитием компании. Целью
торговой компании является расширение
бизнеса и достижение конкурентных
преимуществ перед компаниями подобного
типа. Для достижения этих целей необходимо:
повышение прибыли за счет увеличения
объемов продаж или сокращения расходов;
повышение контроля над выполняемыми
операциями; изучение и максимальное
удовлетворение потребностей покупателей;
управление финансами; планирование и
анализ финансово-хозяйственной
деятельности и т.д.
Разработанные компанией системы на
данный момент не удовлетворяют
предъявляемым требованиям своей
функциональностью и скоростью обработки
данных, поэтому необходимы расширение
функциональных возможностей информационной
системы компании и увеличение скорости
обработки информации.
В центральном офисе компании, а также
в магазинах в результате анализа
сложившихся проблем было решено внедрить
необходимые информационные технологии
и установлен срок автоматизации до
начала мая 2013 г. с бюджетом $90 тыс.
Вариант №2. Автоматизация страховой
компании «Гарант»
Страховая компания «Гарант» образована
в 1993 г. и с тех пор активно развивает
свою деятельность в Московской области.
С 2001 по 2010 гг. были образованы 5
новых региональных филиалов компании.
В 2012 г. планируется открыть еще 3 новых
региональных отделения. Кроме этого, у
компании есть страховые агенты, которые
работают по совместительству. Штат
страховых агентов постоянно пополняется.
Страховая компания заключает договора
страхования и перестрахования. Клиентами
компании выступают как физические, так
и юридические лица. Компания осуществляет
страхование по каско, осаго, страхование
автомобиля, имущества, здоровья,
недвижимости, туристов и т.д.
Управление компанией осуществляется
центральным офисом, который занимается
обработкой и анализом всей информация
о деятельности компании, разработкой
стратегии развития компании, набором
персонала для компании и т.д. В центральный
офис ежедневно поступает огромный объем
информации о деятельности филиалов и
страховых агентов, который требует
оперативного анализа и принятия решения.
Центральный офис компании «Гарант»
включает департамент региональных
продаж, департамент корпоративных
продаж, департамент розничных продаж,
финансовый департамент, департамент
по маркетингу, департамент по персоналу,
департамент по информационным технологиям.
Численность сотрудников компании
составляет 2000 человек. В каждом
региональном отделении численность
персонала составляет 100 человек.
Годовой оборот компании в 2010 г.
составил $12 млн.
В 2004 г. для ведения бухгалтерского
учета и основной деятельности был
закуплен программный продукт «Парус»
(версия под Windows 2000),
компьютеры (Pentium), проложены сети. Данная
версия ПО для компании позволяет
автоматизировать следующие функции:
страховая деятельность, учетные процессы,
управленческий учет.
Также самостоятельно в 2007 г. была
разработана система автоматизация
управления взаимоотношениями с клиентами
(call-центр, поддержка
процесса продаж).
По мере развития компании, разработанные
системы устанавливались в новых
открываемых филиалах. Поддержка систем
в настоящее время осуществляется
департаментом информационных технологий
компании.
Кроме того, в каждом филиале есть
системный администратор для поддержки
работоспособности системы.
С развитием компании возникла необходимость
в автоматизации интернет ресурсов
компании с единой информационной
системой, централизации процесса
урегулирования убытков, управления
маркетинговыми данными. Целью страховой
компании является расширение бизнеса
и достижение конкурентных преимуществ
перед компаниями подобного типа. Для
достижения этих целей необходимо:
повышение прибыли за счет увеличения
объемов продаж или сокращения расходов;
повышение контроля над выполняемыми
операциями; изучение и максимальное
удовлетворение потребностей клиентов;
управление финансами; планирование и
анализ финансово-хозяйственной
деятельности и т.д.
Разработанные компанией системы на
данный момент не удовлетворяют
предъявляемым требованиям своей
функциональностью и скоростью обработки
данных, поэтому необходимы расширение
функциональных возможностей информационной
системы компании и увеличение скорости
обработки информации.
В центральном офисе компании и региональных
представительствах, включая страховых
агентов, в результате анализа сложившихся
проблем было решено внедрить необходимые
информационные технологии и установлен
срок автоматизации до начала мая 2013 г.
с бюджетом $80 тыс.
Вариант №3. Автоматизация
промышленного предприятия «Карат»
Промышленное предприятие «Карат»,
образованное в 1932 году, занимается
производством высокоточных оптических
приборов. Главные производственные
мощности находятся в г. Нижний
Новгород, а региональные представительства
в 15 субъектах РФ. Потребители продукции
(как правило) крупные промышленные
предприятия в РФ и странах ближнего
зарубежья.
Управление предприятием осуществляется
центральным офисом, который занимается
обработкой и анализом всей информация
о деятельности предприятия, разработкой
стратегии развития предприятия, набором
персонала для предприятия и т.д. В
центральный офис ежедневно поступает
объем информации о деятельности
представительств, который требует
оперативного анализа и принятия решения.
Центральный офис предприятия «Карат»
включает производственный департамент,
департамент корпоративных продаж,
департамент региональных продаж, сектор
стратегического планирования, бухгалтерию,
отдел кадров, департамент по информационным
технологиям.
Численность сотрудников компании
составляет 700 человек. В каждом региональном
отделении численность персонала
составляет 15 человек.
Годовой оборот компании в 2010 г.
составил $50 млн.
На нынешний момент в различных офисах
компании находится более 100 персональных
компьютеров Pentium (в равных
пропорциях). В 10 офисах компьютеры
объединены в сеть. Программное обеспечение
представляет собой разрозненные
«коробочные» пакеты бухгалтерского,
складского и кадрового учета начала
2000-х гг., а также системы собственной
разработки для автоматизации некоторых
производственных функций.
Штат программистов состоит из 10 человек,
постоянно занятых доработкой и
сопровождением существующих программ.
Кроме того, в каждом представительстве
есть системный администратор, отвечающий
за функционирование компьютеров и
установленных на них программ.
Проблема в данный момент состоит в том,
что руководству тяжело управлять
остатками готовой продукции на складах,
контролировать своевременное поступление
сырья и материалов, ввести контроль
качества, определить на каком из
технологических этапов находится та
или иная партия. Проблемы планирования,
загрузки производственных мощностей
и управления цепочками поставок
существующее ПО не решает. Также остается
не решенной проблема взаимодействия с
клиентами и партнерами, кроме использования
электронной почты. Годовые убытки (по
оценкам аналитиков) из-за данных процессов
составляют $100 тыс.
В центральном и региональных
представительствах предприятия в
результате анализа сложившихся проблем
было решено внедрить необходимые
информационные технологии и установлен
срок автоматизации до начала мая 2013 г.
с бюджетом $80 тыс.
Вариант №4. Автоматизация торговой
сети «Смарт»
Торговая сеть «Смарт» образована в
1994 г. Сегодня имеет 3 торговые площадки
в г. Санкт-Петербург и 5 в городах
Ленинградской области.
Компания специализируется на продаже
видеотехники и бытовой электроники. У
торговой сети «Смарт» большой спектр
клиентов (частные лица, фирмы).
Управление предприятием осуществляется
центральным офисом, который занимается
обработкой и анализом всей информация
о деятельности предприятия, разработкой
стратегии развития предприятия, набором
персонала для предприятия и т.д. В
центральный офис ежедневно поступает
объем информации о деятельности
представительств, который требует
оперативного анализа и принятия решения.
Центральный офис компании «Смарт»
включает департамент корпоративных
продаж, департамент розничных продаж,
сектор стратегического планирования,
бухгалтерию, отдел кадров, отдел
автоматизации.
Численность сотрудников компании
составляет 120 человек. Численность
персонала каждой торговой площадки 15
человек.
Годовой оборот компании в 2010 г.
составил $5 млн.
Компания располагает большим количеством
(50 шт.) персональных компьютеров класса
Pentium, все они связаны в
сеть. На фирме установлена система
документооборота (на базе Lotus
Notes), единая складская
программа, бухгалтерская программа
1С:Бухгалтерия 7.7, программа по учету
труда и заработной платы той же фирмы.
Недостаток существующей IT-инфраструктуры
в данный момент состоит в том, что
руководство компании не устраивает
разрозненная автоматизация.
В компании имеется отдел автоматизации
из 5 человек (2 из них программисты, 1 WEB
— дизайнер).
Компания 2 раза в месяц выпускает каталог
товаров, но проблема состоит в том, что
их ассортимент быстро обновляется,
изменяются цены, и каталог устаревает
раньше, чем он доходит до потребителей.
Руководство компании решило использовать
технологии электронной коммерции для
создания Internet каталога
с системой заказов on-line.
Таким образом, для автоматизации
деятельности торговой сети необходима
комплексная система класса ERP
со встроенными функциями Web
интерфейса.
В центральном офисе компании и торговых
площадках в результате анализа сложившихся
проблем было решено внедрить необходимые
информационные технологии и установлен
срок автоматизации до начала мая 2013 г.
с бюджетом $40 тыс.
Вариант №5. Автоматизация
внутреннего учета в коммерческом банке
«Юго-западный»
Коммерческий банк «Юго-западный»
образован в 1991 г., головной офис
находится в г. Москве, и 15 филиалов в
различных регионах. Банк предоставляет
полный перечень услуг для корпоративных
клиентов (кредитование бизнеса, факторинг,
лизинг, финансирование внешнеторговых
сделок, расчетно-кассовое обслуживание,
зарплатные проекты, инкассация, эквайринг,
валютный контроль, таможенная карта,
депозиты, векселя и т.д.) и для частных
лиц (вклады, пластиковые карты, платежи
и переводы. аренда сейфовых ячеек,
инвестиционные фонды, кредиты, ипотека,
вклады и т.п.).
Управление банка осуществляется головным
офисом, который занимается обработкой
и анализом всей информация о деятельности
банка, разработкой стратегии развития
предприятия, набором персонала для
банка и т.д. В центральный офис ежедневно
поступает объем информации о деятельности
филиалов, который требует оперативного
анализа и принятия решения.
Центральный офис банка «Юго-западный»
включает службу внутреннего контроля,
службу финансового мониторинга,
управление бухгалтерского учета и
отчетности, управление активных операций,
управление по работе с клиентами, отдел
межбанковских операций, отдел кадров,
отдел автоматизации и информационной
безопасности, юридический отдел.
Численность сотрудников банка составляет
2000 человек. Численность персонала в
каждом филиале 80 человек.
Годовой оборот компании в 2010 г.
составил $80 млн.
Компания располагает большим количеством
(1500 шт.) персональных компьютеров класса
Pentium, все они связаны в
сеть. С 1997 г. для автоматизации
банковской деятельности во всех филиалах
применяется система RS-Bank
4×4 с поддержкой разработчика
до 2008 г.
Для внутреннего (бухгалтерского и
кадрового) учета в настоящий момент
используется комплекс автономных
программ, разработанных группой
программистов банка в 2007 гг. Ситуацию
осложняет тот факт, что из тех разработчиков
в банке никого не осталось, а возросшие
с тех пор требования и введение новых
форм отчетности требуют доработки
данных систем.
Чтобы не отставать от конкурентов, банк
должен использовать для обслуживания
и взаимодействия с клиентами дистанционное
обслуживание: «Клиент-Банк»,
интернет-банкинг. Данная возможность
до сих пор не реализована в банковской
ИС.
Штат программистов из 20 человек
сталкивается при этом с большими
трудностями, так как основная их
деятельность – поддержка и доработка
банковской информационной системы.
Таким образом, для автоматизации
деятельности банка необходима комплексная
система класса ERP со
встроенными функциями Web
интерфейса, дистанционного банковского
обслуживания, основных процессов и
поддержке внутренних учетных задач.
В головном офисе компании и филиалах в
результате анализа сложившихся проблем
было решено внедрить необходимые
информационные технологии и установлен
срок автоматизации до начала мая 2013 г.
с бюджетом $90 тыс.
Вариант №6. Автоматизация
издательской компании «Статус+»
Издательская компания «Статус+»,
образованная в 1989г. выпускает
специализированные издания экономической
направленности (журналы, книги).
На данный момент бухгалтерия компании
оснащена 4-мя персональными компьютерами
класса Pentium и бухгалтерской
программой «Инфо-Бухгалтер», первая
версия которой была приобретена в
1995 г. В конце 2007 г. (перед началом
кризиса) разработчик последний раз
произвел обновление, но во время кризиса
пришлось разорвать контракт, т.к. на
поддержание информационной инфраструктуры
у компании не было свободных средств.
Сегодня в штате компании состоят 3
программиста, занятых поддержкой и
доработкой существующих у фирмы программ
(издательских, бухгалтерских и т.д.).
В 2010 г. у компании появился зарубежный
партнер – американский издательский
дом «McGrawHill». Компания
«Статус+» получила возможность для
крупных инвестиций на свое развитие.
Проблема состояла в том, что для этого
требовалось вести кроме бухгалтерского
учета в российском стандарте, еще и учет
в стандарте GAAP. Кроме
того, появилась необходимость
детализировать существующий учет по
проектам, для лучшего осуществления
контроля качества.
Существующий пакет «Инфобухгалтер»
такими возможностями не обладал.
Управление издательством осуществляется
в головном офисе, который занимается
обработкой и анализом всей информация
о деятельности компании, разработкой
стратегии развития предприятия, набором
персонала для компании и т.д. В центральный
офис ежедневно поступает объем информации
о издательской деятельности, который
требует оперативного анализа и принятия
решения.
Офис издательской компании «Статус+»
включает дирекцию по издательству,
финансовую дирекции, дирекцию по
персоналу, управление бухгалтерского
учета и отчетности, управление по работе
с клиентами, IT-отдел,
юридический отдел.
Численность сотрудников издательской
компании составляет 200 человек. Численность
производственного персонала 120 человек,
80 человек – административно-управленческий
персонал.
Годовой оборот компании в 2010 году
составил $4 млн.
В офисе компании и в производственных
подразделениях в результате анализа
сложившихся проблем было решено внедрить
необходимые информационные технологии
и установлен срок автоматизации до
начала мая 2013 г. с бюджетом $500 тыс.
Вариант №7. Автоматизация сети
супермаркетов «Какаду»
Сеть супермаркетов «Какаду», одна из
крупнейших во Владимирской области,
имеет по стране 11 торговых центров.
Первые магазины «Какаду» появились в
1991 г. и с тех пор завоевали широкое
признание благодаря высочайшему уровню
обслуживания и индивидуальному подходу
к покупателю.
На розничном рынке компании приходится
соперничать не только с традиционными
отечественными, но и с международными
компаниями, а также сетями дисконтной
торговли, предлагающими свои товары по
сниженным ценам. И если учесть возросшую
в последнее время тенденцию к поглощению
мелких фирм, то для того, чтобы выделиться
на фоне столь жесткой конкуренции и
побороться за свое место в торговом
бизнесе, от «Какаду»требовались серьезные
усилия.
Руководство компании понимало, что для
достижения успеха, необходимо правильно
выявлять изменчивый потребительский
спрос, учитывая при этом даже и
географический фактор. Но системы,
позволяющей реализовать систему
управления отношениями с клиентами
(CRM), у компании нет.
При этом отдельные магазины имеют свои,
написанные на Oracle, витрины данных. Но в
тоже время ощущается потребность в
интегрированном информационном
хранилище, которое стало бы основой для
CRM-системы.
Управление предприятием осуществляется
центральным офисом, который занимается
обработкой и анализом всей информация
о деятельности предприятия, разработкой
стратегии развития предприятия, набором
персонала для предприятия и т.д. В
центральный офис ежедневно поступает
объем информации о деятельности
представительств, который требует
оперативного анализа и принятия решения.
Центральный офис сети супермаркетов
«Какаду» включает департамент продаж,
департамент снабжения, департамент
стратегического планирования, бухгалтерию,
отдел кадров, отдел автоматизации и
безопасности.
Численность сотрудников компании в
общей сложности составляет 4 тыс. человек.
Численность персонала каждого торгового
центра 300 человек.
Годовой оборот компании в 2010 г.
составил $120 млн.
В головном офисе компании и торговых
центрах в результате анализа сложившихся
проблем было решено внедрить необходимые
информационные технологии и установлен
срок автоматизации до начала мая 2013 г.
с бюджетом $50 млн.
13
Чтобы грамотно управлять угрозами для бизнеса, мы решили использовать метод фреймворка PMBoK от PMI. Разработчики предлагают поделить процесс управления на 6 этапов:
- Планирование управления
- Идентификация факторов
- Качественная оценка
- Количественная оценка
- Планирование реакции
- Мониторинг и контроль
Такая методология предполагает активный подход в работе с источниками проектных угроз. Пассивное реагирование на последствия допустимо при появлении непредвиденных факторов. Но пассивная реакция на угрозы, которые можно предугадать недопустима — можем сильно увеличить смету, сорвать сроки или потрелять заказчика. В современных бизнес-реалиях пассивная реакция равноценна осознанному убийству проекта.
Такую схему из 6 этапов предлагает PMBoK.
Планирование управления
На этапе планирования выбираем стратегии организации процесса управления и правила взаимодействия участников и заинтересованных сторон. Мы сможем уточнить выбранные методы, инструменты и уровень организации управления.
Вот такую проектную схему предлагают разработчики PMBoK.
Диаграмма потоков данных планирования управления рисками в PMBoK.
3 главных аспекта правильного планирования:
- формирование благоприятной среды управления — гармонизация отношений внутри команды
- использование заранее заготовленных схем и шаблонов процессов управления
- создание описательной части и плана управления угрозами
Основной процессный инструмент — совещание. В нем принимают участники все члены команды, а иногда и инвесторы, когда речь идет про угрозы для инвестиционного проекта. Результат их работы — создание плана управления. Это полноценный регламент, которым команда руководствуется при противодействии угрозам.
Обычно в плане управления указывают:
- методы и инструменты управления
- роли участников при возникновении рисковых ситуация
- допустимые значения и диапазоны угроз
- принципы и правила внесения изменений в работу
- форматы отчетности и документации по проектным угрозам
- способы мониторинга и ответственные
Идентификация
На этом этапе выявляют и документируют проектные угрозы. Результат — перечень возможных проблем с ранжированием по степени опасности. Сначала команда выявляет рисковые факторы, затем проводит исследования и идентифицирует угрозы. Нужно понимать, что не все угрозы можно идентифицировать на старте. Обычно по мере развития проекта количество возможных рисковых событий увеличивается.
Чтобы увеличить вероятность идентификации, есть смысл использовать грамотную классификацию рисковых событий. Например, мы в Oko используем классификацию по степени по степени контролируемости.
Классификация рисковых событий по степени их контролируемости.
Использование этой классификации помогает определить, под какие неконтролируемые угрозы стоит планировать резервы. Нужно учитывать и то, что контролируемость рисковых событий еще не гарантирует успеха в их управлении. Также отмечу, что не всегда удается четко классифицировать угрозы, поэтому есть смысл использовать и другие способы классификации. Например, по источникам.
Пример классификации рисковых событий в зависимости от их источника.
При формулировании угрозы важно использовать двух составные понятия: с указанием на источник события и саму угрозу. Например, «угроза срыва сроков реализации из-за отсутствия определенности с функционалом» или «риск отсутствия финансирования из-за нестабильной ситуации с бюджетом у компании-заказчика». Результат — создание реестра возможных рисковых ситуаций.
Фрагмент реестра рисковых ситуаций.
Анализ и оценка рисков проекта
Здесь мы совмещаем качественную и количественную оценку.
Качественный анализ — оценка экспертных мнений и взглядов на возможные неблагоприятные последствия, обусловленные выявленными факторами. Качественный анализ более поверхностный, но часто его достаточно. Он позволяет получит на выходе:
- перечень рисковых событий, сгруппированный по приоритету
- перечень событий, которые нужно дополнительно проанализировать
- комплексную оценку угрозы для команды в целом
При анализе экспертные оценки делят на две категории: оценки вероятности н
аступления рисковых событий и оценки их влияния. Для их корректного анализа создают специальную матрицу с оценками. Например, вот такую матрицу предлагают разработчики PMBoK.
Матрица вероятности/воздействия угроз и благоприятных возможностей из PMBoK.
На основе этой матрицы можем получить три пороговых уровня: незначительные, средние и недопустимые угрозы. Оценка — это приоритет риска. В зависимости от того, в какую из категорий попадает рисковое событие, а также в зависимости от оценки, которую получает угроза, разрабатываются конкретные мероприятия по купированию и предотвращению последствий.
Чтобы оценить степень угрозы у себя в компании, мы придумали такую матрицу, в которой эта степень зависит от вероятности реализации риска и его влияния на показатели работы. Чем выше вероятность реализации и существенней влияние на проектов, тем выше степень угрозы — бороться с ней нужно активнее.
Чем выше вероятность реализации и существенней влияние на проектов, тем выше степень рисковой угрозы.
Количественный анализ рисков проекта направлен на получение конкретных оценок вероятности наступления рискового события. Количественный анализ значительно более трудоемкий, но и более точный. Он требует качества входных данных, использования развитых математических моделей и более высокой компетентности от персонала. Поэтому его используют только для сложных проектов.
Количественная оценка помогает проанализировать:
- вероятность достижения конечной цели
- степень воздействия угроз на проект и объемы непредвиденных затрат и материалов, которые могут понадобиться
- события, требующие скорейшего реагирования и большего внимания, а также влияние их последствий на результат
- фактические расходы, предполагаемые сроки окончания
Обычно для количественного анализа используют такие методологии:
Вероятностный анализ — оценка на основе статистики по прошлым проекта с учетом вероятностной погрешности.
Анализ чувствительности — оценка влияния основных параметров финансовой модели на результирующий показатель в целях выявления наиболее существенных переменных для проекта.
Имитационное моделирование — оценка, сделанная на основе многократных опытов с моделью.
Чтобы не усложнять себе жизнь, для количественного анализа лучше использовать специальный софт. Иначе от огромного массива данных и случайных чисел будет боль голова.
Планирование реакции
Когда вы определили угрозы, выяснили, на что они влияют и дали им оценку, нужно продумать реакцию, которая поможет минимизировать последствия от угрозы. Обычно на этом этапе придумывают меры, которые с высокой вероятностью помогут добиться успеха по проекту, несмотря даже на неопределенные рисковые события.
В своей практике мы выработали 4 варианта реакций, которые помогают нам ликвидировать или хотя бы минимизировать последствия от возможных проблем. Вот какие стратегии можно использовать.
1. Уклонение. Корректируем план управления таким образом, чтобы исключить возможность наступления негативных событий или снизить последствия от их наступления. Например, пересмотреть график или изменить объем работы путем удаления некритичных модификаций.
2. Передача. Перекладываем ответственность за негатив на третью сторону. Например, заключаем договор страхования, берем предоплату, предусматриваем в договоре с заказчиком неустойку. Иногда на это потребуются дополнительные деньги.
3. Снижение. Формируем предупредительные меры по снижению вероятности наступления негативных событий или последствий их наступления. Например, при формировании команды включаем в нее возможных дублеров — на случай, если разработчик заболеет, а дизайнер-фрилансер решит пропасть на неделю без предупреждения.
4. Использование. Превращаем негатив в позитив. Пример риска проекта: квалификация тестировщика вызывает у руководителя группы вопросы, есть вероятность срыва сроков и снижения качества продукта. Думаем, что делать — в качестве дублера привлекаем более опытного тестировщика. Мы увеличим бюджет, но сократим сроки на выполнение важных для нас процессов с гарантией их качества.
На основании выбранного варианта реагирования предпринимаются дальнейшие действия. Например, в PMBoK рекомендуют вносить изменения в документацию или план проекта.
Диаграмма потоков данных планирования реакции на угрозы из PMBoK.
Мониторинг и управление
Последний этап — системная работа над выявлением новых угроз, их контроль и реакция в соответствии с планом управления. Обычно эту работу ведут на всех этапах реализации продукта, вплоть до подписания акта приема-передачи. Чем ближе конец работы, тем сильнее последствия может вызвать угроза.
Важно отслеживать состояние как выявленных, так и потенциально новых рисковых событий. Дополнительно отслеживают динамику изменений, отклонений, трендов и состояние резервов, которые используют для нивелирования угроз.
Важный момент: проектный менеджер не может быть владельцем всех угроз и отвечать за всех одновременно. Поэтому есть смысл назначить ответственного по каждому риску отдельно.
В процессе мониторинга и контроля обычно выбирают и тестируют альтернативные стратегии, корректируют план для внедрения новых тактик. Все изменения и дополнения вносятся в новый план, ответственные регулярно готовят отчет, проводят совещания и обсуждают угрозы с коллегами.
Автоматизация управления рисками на 1С
Управляйте рисками с помощью 1С
Автоматизация управления рисками на 1С
Управляйте рисками с помощью 1С
Об управлении рисками в 1С
1С позволяет автоматизировать процесс управления рисками предприятия и процедуры внутреннего контроля. Автоматизация происходит с помощью типового решения «1С:Управление холдингом» и разработанного командой 1КЛИК решения «1С:Управление рисками». Оба решения содержат:
Готовый функционал, включающий справочники по описанию рисков, документы по управлению рисками и мероприятиями, систему индикаторов, механизм произвольных формул, отчетность, преднастроенные процессы сбора и мониторинга рисков
Механизмы настройки бизнес-процессов точно под нужды компании
Средства интеграции с Microsoft Excel и Word
Возможность кастомизации системы для настройки реквизитов карточки риска, паспорта риска, мероприятий и прочих объектов системы
Гибкую система отчетности
В 1С может быть встроен любой процесс и модель управления рисками. Сами решения не содержит преднастроенной модели управления рисками.
Почему выбирают управление рисками в 1С
Простая доработка системы
Решения, разработанные на базе платформы 1С имеют базовые объекты и структуру, позволяющую просто адаптировать объекты системы по нужны Заказчика.
В решении «1С:Управление рисками» намеренно не закладываются универсальные механизмы, это позволяет с минимальными затратами проводить необходимые доработки Системы.
Невысокая стоимость лицензий и внедрения по сравнению с западными аналогами
При выборе решения «1С:Управление рисками» минимальная стоимость лицензий равна 0, если предприятие уже использует любое из решений 1С. Стоимость внедрения от 1 млн рублей.
Запуск возможен уже во 2-й месяц работ по внедрению.
Сотрудники легко освоятся в системе если работали с любым другим решением на базе платформы 1С.
Возможность интеграции с другими информационными системами
Платформа 1С обладает всеми современными механизмами позволяющими организовать обмен с другими платформами, в том числе web-платформами.
Как внедрить управление рисками в 1С
Типовой проект автоматизации процесса управления рисками состоит из 3 этапов
- Планирование проекта в целом
- Разработка и согласование документа «Технический проект» на внедрение Системы
- Подготовка инфраструктуры
- Развертывание прототипа системы на серверах Заказчика
- Документ «Технический проект»
- Детальный план-график выполнения работ по проекту
- Разработка и настройка Системы согласно Техническому проекту
- Проведение внутреннего системного теста
- Разработка и утверждение программы и методики испытаний (ПИМИ)
- Проведение приемо-сдаточных испытаний (ПСИ)
- Устранение замечаний по итогам ПСИ
- Разработка пользовательской документации на Систему
- Программа проведения ПИМИ
- Протокол о проведении системного теста
- Инструкция пользователя Системы
- Инструкция администратора Системы
Опытная или опытно-промышленная эксплуатация
- Загрузка начальных данных
- Проведение опытной эксплуатации путем подготовки отчетности силами Заказчика
- Поддержка процесса работы в системе
- Обработка обращений пользователей, устранение замечаний, внесение изменений в Систему
- Приемка результатов устранения замечаний и внесения изменений в Систему
- Журнал обращений пользователей во время проведения опытно-промышленной эксплуатации
- Протокол приемки результатов устранения замечаний и внесения изменений в Систему
- Обновленная инструкция пользователя Системы
- Обновленная инструкция администратора Системы
Длительность проекта и стоимость
Длительность и стоимость проекта внедрения зависит от требований, зафиксированных в Техническом задании.
Стоимость рассчитывается исходя их плановых трудозатрат сотрудников проектной команды, умноженных на базовые ставки специалистов:
Консультант 1С/Программист 1С
НДС не облагается в связи с применением Исполнителем упрощенной системы налогообложения, на основании п. 2 ст. 346.11 глава 26.2 НК РФ
НДС не облагается в связи с применением Исполнителем упрощенной системы налогообложения, на основании п. 2 ст. 346.11 глава 26.2 НК РФ
НДС не облагается в связи с применением Исполнителем упрощенной системы налогообложения, на основании п. 2 ст. 346.11 глава 26.2 НК РФ
Внедрение автоматизированной системы формирования консолидированной отчетности МСФО для крупнейшего предприятия России по производству горной техники для подземной разработки месторождений угля, калийной руды и каменной соли
Копейский машиностроительный завод
Комплексное решение для управления операционной и финансово-хозяйственной деятельностью компании. Проект внедрения стал победителем на конкурсе корпоративной автоматизации 1С в номинации «Лучший региональный проект» 2019
Владивостокский морской торговый порт
Проект по автоматизации расчета выручки (IFRS 15) и капитализации процентов (IFRS 23) для группы компаний «Пионер»
ДЕВЕЛОПМЕНТ И СТРОИТЕЛЬСТВО
Разработка и внедрение автоматизированной системы сбора, обработки и консолидации данных для отчетности по МСФО
IT-аудит финансовой системы 1С:УПП для оптимизации и повышения эффективности для одной из крупнейших торговых сетей на территории Сибири и Дальнего Востока.
Автоматизация процесса управления рисками в группе транспортно- логистических компаний.
1КЛИК выступал экспертом-методологом в области международной отчетности при разработке новой учетной политики компании в соответствии с требованиями МСФО
Закажите демонстрацию решений 1КЛИК или типовых конфигураций 1С, а также получите консультацию по любому из продуктов бесплатно
Москва, проезд Марьиной Рощи 17-й, дом 4, корп. 1, этаж 6, офис 29
© 2015 — 2022 ООО «1КЛИК»
#статьи
- 19 май 2022
-
0
Управление рисками в проекте: как найти и оценить, как составить план защиты от них
Основы управления рисками для менеджеров, которые работают с проектами. Какими бывают риски и как на них реагировать. Пересказ лекции Google.
Кадр: фильм «Исходный код»
Обозреватель Skillbox Media по маркетингу и IT. С 2015 года работает с SEO, таргетированной и контекстной рекламой. Писала для Skypro, Yagla и Admitad.
Риски — неотъемлемая часть любого проекта, от семейного праздника до строительства гидроэлектростанции. Ни один проект не следует плану на 100%, даже если им руководит опытный менеджер. Управление рисками — отрасль проектного управления со своими техниками и методиками.
Мы перевели и пересказали главное из лекции об основах управления рисками «Risk Management Basics», которую подготовили в Google для курса по управлению проектами.
- Что такое риски в проекте
- Самые распространённые виды рисков
- Как найти риски в проекте и оценить их
- Вы нашли риски: что с ними делать
- Как составить план по управлению рисками
Есть много определений риска, но мы дадим очень простое. Риск — это негативное событие, которое может произойти, а может и не произойти. Риски нужно отличать от проблем: риск станет проблемой, только если негативное событие произойдёт.
Проблемы мешают выполнению задач проекта. Если вы руководите проектом, вы должны помнить, что несёте ответственность за риски.
Вот несколько примеров рисков и проблем, к которым они привели.
- Целью проекта было опубликовать исследование, но ведущий аналитик уволился, когда была готова только половина. Дедлайн сорвали, и задачу в срок не выполнили.
- Спрос на товар резко вырос, и поставщик не смог поставить требуемое количество. Полки магазина опустели.
- Компания продавала в офисы растения, которые почти не требуют ухода. Однако у поставщиков закончились специфические растения, в которых нуждалась компания, — папоротники и кактусы.
Когда вы понимаете, какие риски есть в проекте, вы можете принять меры предосторожности — например, обратиться за консультацией. Если что-то пойдёт не так, у вас будет план, как решить проблему.
Управление рисками в проекте — это процесс поиска, оценки и предотвращения потенциальных проблем. Этот процесс регулярный, превентивных действий на старте проекта недостаточно.
Управление рисками не только снижает влияние негативных ситуаций на проект. Оно высвобождает ресурсы: материальные, трудовые.
Есть разные классификации рисков. Мы назовём виды рисков, которые упоминают чаще остальных.
Временные риски. Это вероятность того, что на выполнение задач в проекте уйдёт больше времени, чем запланировано. Помните о сроках, потому что время — это ресурсы. Если команда тратит много времени на задачи, растёт и фонд оплаты труда. Кроме того, стейкхолдеры проекта могут разочароваться из-за задержек.
Бюджетные риски. Из-за плохого планирования стоимость проекта может оказаться больше, чем заложено в бюджете. Обычно бюджет закладывают перед запуском проекта, тогда же планируют траты по статьям. Если команда не уложится в план, потребуются дополнительные средства, и если их не будет, проект остановится.
Риски изменения объёмов работы. Они могут появиться, если исполнители не поняли требований заказчика или он сам внёс в проект изменения. Это может привести к пересмотру бюджета, сроков и списка задач.
Внешние риски. Это потенциальные события, которые находятся за пределами компании и которые компания не может контролировать. Например, на проект могут повлиять новые законы.
Единая точка отказа. Так называют единственное событие, которое может остановить всю работу над проектом. Ни один член команды не сможет дальше выполнять свои задачи, пока проблема не решится. Например, для интернет-магазина единой точкой отказа может стать отключение электричества в офисе. Если доступ к инструментам, таким как CRM, был только из офиса, вся команда не сможет выполнять задачи.
В результате команда не выполнит ни одной задачи. Зная об этой точке отказа, можно принять меры: создать резервные копии сервисов и информации в облаке.
Зависимости. Это связи между двумя задачами в проекте: когда начало одной задачи зависит от завершения другой. Зависимости часто становятся риском для проекта.
Например, один из членов команды должен подписать контракт с заводом-поставщиком. Пока контракта нет — остальная команда не может выполнить ни один заказ. Если вовремя не подписать документ, то проект не закончат в срок.
Другой пример. Участник команды уходит в отпуск. Если он отвечал за критические процессы, то другие участники не смогут выполнять свои задачи. От этого риска можно было бы защититься, узнав о планах членов команды с самого начала.
Зависимости могут быть внутренними и внешними. Внутренние — зависимости внутри проекта. Например, чтобы начать разработку сайта, нужно сначала утвердить его дизайн.
Внешние зависимости — зависимости, над которыми у команды нет контроля. Например, компания покупает у фермы овощи для продажи, и если лето окажется засушливым или слишком дождливым, урожая будет меньше — а значит, компания не получит достаточно овощей.
Рисков, которые могут повлиять на ваш проект, много. Нельзя предугадать их все, но можно проработать большинство из них. В следующем разделе мы рассмотрим методы поиска рисков.
Самый эффективный способ найти риски — мозговой штурм с командой проекта. Так каждый сможет предложить свои идеи. Лучше, если в мозговом штурме будут участвовать люди, занимающие разные роли в проекте, имеющие разный бэкграунд. Люди с разным опытом и набором навыков помогут найти риски, о которых руководитель не догадывается.
Некоторые члены команды участвовали в нескольких проектах внутри компании. Они поделятся информацией об опасностях, с которыми столкнулись коллеги. Новичок может рассказать об опыте команд, в которых он работал раньше.
Чтобы структурировать информацию, полученную во время мозгового штурма, используйте диаграмму Исикавы. Диаграмма, известная как «рыбьи кости», наглядно показывает причинно-следственные связи.
В «голову» рыбы помещают риск, который нужно проанализировать. На «костях» пишут причины, которые могут привести к негативному событию. К ним могут вести «кости» поменьше — причины второго порядка. Иногда добавляют третий, четвёртый и даже пятый уровни.
Вот диаграмма Исикавы, составленная для анализа проблемы — у компании низкие продажи.
Инфографика: Майя Мальгина для Skillbox Media
Например, есть риск, что поставщики вовремя не доставят товар. На диаграмму поместят следующие причины:
- нет инструментов отслеживания;
- государство может ввести ограничения;
- нет человека, который отвечает за доставку товара.
Может оказаться, что список рисков слишком большой. Это нормальный результат для такого анализа. Нужно будет выбрать самые важные риски, на которых сосредоточится команда.
Для оценки рисков используйте матрицу вероятности и последствий. С помощью неё вы поймёте, о каких рисках нужно помнить в первую очередь.
Сначала проанализируйте, какие последствия могут быть, если риск превратится в проблему. Используйте шкалу:
- Сильный эффект — если проблема может сорвать проект или существенно его изменить.
- Средний — если событие может повлиять на проект, но это можно поправить.
- Слабый — если риск незначительно повлияет на проект, но точно его не сорвёт.
Потом оцените вероятность того, что риск возникнет:
- Высокий — высокая вероятность риска.
- Средний — риск есть.
- Низкий — скорее всего, риска нет.
Затем нужно собрать оценки вероятности и силы последствий на одной шкале и разбить риски на несколько групп.
- Если вероятность низкая, а последствия дадут слабый эффект, то об этом риске не стоит беспокоиться. Просто имейте в виду, что он есть.
- Если вероятность высокая и последствия дадут сильный эффект, о защите от этого риска нужно позаботиться в первую очередь.
Несколько незначительных рисков обычно меньше влияют на проект, чем один риск высокого уровня. Последние чаще приводят к тому, что проект срывается. Поэтому работайте сначала с проблемами высокого и среднего уровня.
Используйте разные цвета, чтобы выделить приоритетные задачи. Так участник команды, увидев таблицу, сразу поймёт, с какими рисками нужно работать в первую очередь.
Есть четыре основные стратегии, как реагировать на риски. Можно попробовать избежать рисков, принять их, передать их другой команде; их также можно уменьшить и контролировать.
Рассмотрим каждый способ.
Избегать. Иногда вы можете избежать риска полностью. Например, если вы сомневаетесь в надёжности подрядчика, который часто не соблюдает сроки, вы можете перестать работать с ним.
Принять. Этот способ подойдёт для рисков с низкой или средней вероятностью и без тяжёлых последствий для проекта. Нужно принять, что такой риск существует, и отслеживать его всё время до окончания проекта.
Представим, что поставщик неожиданно заявил, что у него нет нужных вам компонентов, однако он пополнит запасы в ближайшее время. Возможно, это скажется на сроках проекта.
Можно начать работу с другим поставщиком, но такой риск лучше принять. Это имеет смысл, если задержки не критичны для проекта. Если не искать нового поставщика и смириться с риском, это избавит команду от лишней работы.
Уменьшить или контролировать. Для смягчения риска используйте дерево решений. Это блок-схема, которая показывает, какие решения существуют для каждой проблемы. Например, если компания работает с исполнителем, который срывает сроки, ему можно постоянно напоминать о задаче: отправлять имейлы каждый день или звонить.
Передать риски. Если команда понимает, что не может снизить риски для какой-то группы задач, она может передать их специализированным компаниям. Иногда это помогает сэкономить время и деньги.
План по управлению рисками — это документ, который описывает возможные риски и способы их снизить. Если у вас есть такой план, все члены команды и заказчики будут в курсе, какие проблемы могут возникнуть во время реализации проекта. Документ нужно постоянно дополнять, так как новые риски могут появиться на любом этапе проекта.
План можно создать в «Google Документах». Так все члены команды будут иметь к нему доступ. Укажите название компании, название проекта и кто создал этот документ — чтобы было понятно, к кому обращаться, если возникнут вопросы. Также можно написать, когда документ был создан и когда обновлялся в последний раз. Так команда будет понимать, насколько он актуален.
Скриншот: Google Career Certificates / YouTube
Далее напишите цель документа: смягчить последствия рисков в проекте. В план нужно добавить краткое описание проекта — и написать, какие проблемы проект переживёт, а какие риски могут его изменить.
Следующая часть — самая важная. Создайте таблицу, в которой вы распишете все возможные риски, оцените их и добавьте возможные решения для каждого. Как это сделать, мы разобрали в предыдущих разделах.
Например, один из рисков — поставщик не успевает уложиться в сроки. У этого риска средний уровень. Для снижения риска есть решение: ежедневно созваниваться с поставщиком.
Важно, чтобы не только команда знала о планах. Обязательно встретьтесь с заказчиком или напишите ему письмо, чтобы рассказать, какие риски есть у проекта.
Так вы уже в начале проекта будете понимать, поможет ли заказчик решить проблемы, если они возникнут. Например, если заказчик предупредил, что он не сможет увеличить бюджет, вы учтёте, что работаете с ограниченными ресурсами и дополнительных средств не будет.
Если вы не расскажете о рисках заказчику заранее, в середине проекта они могут стать неприятным сюрпризом. Так вы можете подорвать доверие к себе и всей компании. Если же заинтересованные стороны знают о рисках, все понимают, чего потенциально можно ожидать при работе над проектом.
Особенно важно поговорить с заказчиком, если есть риски высокого уровня. В таком случае лучше встретиться с ним и пообщаться лично. Возможно, вы найдёте совместные решения. Риски среднего и низкого уровня можно обсудить по электронной почте.
Все риски обнаружить невозможно, и это нормально. Но если вы предусмотрите значительную часть из них и придумаете решения, вы будете лучше подготовлены к проблемам.
- Риски — это возможные негативные ситуации, которые могут помешать выполнению проекта. Проблемы — это воплотившиеся риски.
- Самые распространённые виды рисков: временные, бюджетные, нарушения в зависимостях, внешние, а также единые точки отказа — события, которые останавливают всю работу команды.
- Ищите риски с помощью мозговых штурмов, анализируйте их с помощью диаграммы Исикавы, а потом оценивайте их эффект и вероятность.
- На риски можно реагировать с помощью одной из четырёх стратегий: избегать, принять, контролировать или передать другой команде.
- Список самых опасных рисков и список мер, с помощью которых команда будет на них реагировать, вносят в план по управлению рисками.
Другие материалы Skillbox Media по управлению проектами
- Что такое проект: разбираем главное понятие проектного управления
- Kanban: рассказываем, как работает эта методика
- Как планировать проекты и следовать графику работ с диаграммами Ганта
- Что такое Agile: методология, команда, оценка эффективности
- Как работает Scrum и как управлять проектом с помощью этой методики
Научитесь: Профессия Менеджер проектов
Узнать больше
Содержание:
1. Возможные риски проекта
2. Уровни риска проекта и превентивные мероприятия
3. Влияние риска на проект
В данной статье разберем процессы управления рисками IT-проекта. Ответим на вопросы:
· Что такое управление рисками с точки зрения проектной технологии?
· Какие сейчас востребованы методы управления рисками IT-проектов?
· Что можно улучшить в сфере управления рисками IT-проектов?
Риск – неопределенное событие или множество событий, которые в случае реализации окажут влияние на достижение целей. Рисковое событие – это всегда «возможность» и «угроза».
1. Возможные риски проекта
Управление рисками должно увеличить шансы на достижение целей проекта. В то же время риски для отказа проекта должны быть сведены к минимуму.
Система управления профессиональными рисками — это непрерывный процесс, требующий постоянного анализа хода проекта, переоценки и адаптации политики управления рисками и планов реагирования. В упрощенном виде процесс управление риском на IT-проектах заключается в следующих действиях:
Обнаружение риска. Для этого используем наши проектные документы, проводим встречи с заинтересованными сторонами и экспертами, создаем контрольные списки возможных рисков проекта. Для IT-проектов типичными являются следующие риски:
a. Неготовность топ-менеджмента Заказчика к изменениям в бизнес-процессах предприятия и организационной структуры;
b. Незаинтересованность руководителей основных подразделений Заказчика и их прямых, подчиненных в проекте;
c. Смена в ходе реализации проекта РП, Заказчика;
d. Недостаточная квалификация РП и ответственных исполнителей Исполнителя;
e. Текучесть кадров Исполнителя
f. Отсутствие или нарушение методологии ведения IT-проекта;
g. Риск неверного технического решения;
h. Риск снижения производительности информационной системы;
i. Ошибки календарного планирования;
j. Изменение требований Заказчика
k. Нарушение спецификаций (плана результатов) Исполнителем
l. Низкая производительность Исполнителя (характерно для микро -команд)
Если руководитель проекта считает, что не все риски выделены, то можно использовать методы мозгового штурма или SWOT-анализ проекта.
Все риски фиксируются в Реестр рисков (см. Таблица 1). Вначале заполняя только колонку «Описание риска» и, возможно, «Последствия появления данной проблемы».
Таблица 1 — Пример реестр рисков по проекту внедрения 1С
2. Уровни риска проекта и превентивные мероприятия
Анализируем каждый риск с позиций последствий для проекта и вероятности возникновения риска. Для оценки последствий можно воспользоваться инструментом РМВОК (см. Таблица 2)
Таблица 2 — Влияние оказываемое риском на характеристики проекта
По каждой из характеристик выбираем воздействие (жирный курсив в Таблица 2), далее считаем среднее арифметическое складывая все строки и получаем итоговую степень воздействия рисков на проект (5%+10%+20%+40%)/4 = 18,75% — т.е. среднее значение (15-30%).
Совместно с экспертами (командой проекта) по выявленным основным рискам проекта выставляем вероятность: очень высокая (90%), высокая (70), средняя (50%), низкая (30%), очень низкая (10%).
Далее сводим в общую таблицу вероятность и уровень влияния (см. Таблица 3)и заполняем колонки 4 и 5 Таблица 1
Таблица 3 — Матрица оценки риска
Уровень рисков проекта — если риск попадает в красную зону — обязательно вырабатываем противо-рисковое мероприятие (см. ниже). С желтыми рисками — на усмотрение команды проекта.
Планирование вариантов реагирования для управления риском в желаемом направлении – соответственно определяем приемлемую стратегию реагирования на риск (колонка 6 Таблица 1):
a. Уклониться (полностью устранить угрозу)
b. Передать (найти третью сторону, которая может управлять угрозой за нас)
c. Снизить (уменьшить вероятность и/или силу воздействия угрозы)
d. Принять (не предпринимать активных действий, но подготовить резервный план на случай возникновения угрозы)
e. Использовать (сделать так, чтобы возможность точно реализовалась)
f. Разделить (привлечь третью сторону в управление возможностью)
g. Увеличить (увеличить вероятность и/или воздействие возможности)
h. Принять (не предпринимать активных действий, но подготовить резервный план на случай возникновения возможности).
i. Эскалация (обратитесь за помощью к руководству)
Соответственно на данном этапе заполняем в Реестре рисков колонки: Стратегия, Планы работ до и после наступления рискового события. Также назначаем ответственных за данные задачи. Еще имеет смысл запланированные превентивные мероприятия перенести отдельными пунктами в календарно-ресурсный план проекта с обозначением ответственных и потребных ресурсов.
Для рисков с высоким уровнем воздействия и высокой вероятностью нужно всегда планировать конкретные меры и сообщать их открыто команде проекта. Также необходимо регулярно проверять, актуальны ли обозначенные в плане по управлению риском меры.
3. Влияние риска на проект
На стадии планирования управления рисками проекта у нас имеется Реестр рисков проекта, календарно-ресурсный план проекта с перечнем задач по управлению рисками проекта.
По ходу выполнения проекта осуществляем мониторинг рисков, определение остающихся рисков, выполнение плана управления рисками проекта и оценка эффективности действий по минимизации рисков, а также возможно перепланирование проекта.
В заключении можно сказать, что задачей управления рисками ИТ-проектов является своевременное определение факторов, связанных с внедрением информационной системы или системы автоматизации, которые могут негативно повлиять на реализацию проекта внедрения, а также оптимальное планирование действий по минимизации этих факторов.
Специалист компании ООО «Кодерлайн»
Дмитрий Хисматуллин.
