«Это сущий кошмар» — так оценил процесс внедрения информационной системы управления на своем предприятии один из участников недавнего ERP-форума-2005. И заслужил эмоциональное понимание и бурные овации. Действительно, мало выбрать соответствующую бизнесу систему, мало найти деньги на ее внедрение. Нужно еще преодолеть все этапы и риски проекта, что, как показывает практика, на самом деле часто выливается в «сущий кошмар». Вот об управлении рисками проекта сегодня и поговорим, продолжая эту тему, начатую в «ЭЖ» № 2
Внедрение любой информационной системы требует реорганизации практически всей деятельности предприятия. А это один из самых крупных рисков, последствия которого могут привести как к полному краху бизнеса, так и к его процветанию. Поэтому внедрение информационной системы управления часто рассматривают не как ИТ-проект, а как бизнес-проект.
Успех ИТ-проекта зависит от многих факторов. Но из их числа можно выделить три основных: время, качество, ресурсы. Сбалансировать их между собой всегда трудно, поэтому популярна поговорка «Выбери два из трех».
Если во главу угла ставится высокое качество исполнения всех работ по проекту, то это потребует либо много времени, либо большого числа ресурсов.
Главная задача руководителя проекта — уложиться в выделенный бюджет и заданные сроки и обеспечить требуемое качество имеющимися трудовыми ресурсами. Любое нарушение этих ограничений чревато различного рода рисками, которые могут также привести как к негативным, так и к позитивным последствиям.
Андрей Годунов (ОАО «Вымпелком) отмечает, что еще до запуска системы компания столкнулась с рисками, которые сумела преодолеть:
- внедрение системы проходило вместе с реорганизацией компании;
- сменялись ключевые руководители проекта и со стороны заказчика, и со стороны исполнителя;
- дата запуска системы могла быть перенесена, так как согласование ключевых дизайнов решений шло с отставанием от плана;
- процедура контроля над изменениями не работала эффективно;
- миграция данных была недооценена по объему работ.
Задача риск-менеджмента— всеми имеющимися средствами и возможностями снизить риски, которые могут привести к проблемам, и максимально стимулировать риски, влекущие точное попадание в цель.
По словам Андрея Володина (компания «Евросеть»), для минимизации негативных рисков внедрения информационной системы класса ERP использовался лучший мировой опыт с привлечением зарубежных специалистов. Для постановки налогового, бухгалтерского и управленческого учета привлекалась ведущая аудиторская компания. Чтобы не стать заложниками консультантов, была создана собственная профессиональная команда специалистов. Для успеха дела необходимы также организационная и юридическая реструктуризация и готовность сотрудников к внедрению новой системы.
К основным рискам проекта можно отнести низкое качество управления деятельностью компаний в целом и сопротивление нововведениям со стороны их сотрудников. Внедрение системы является необходимым, но недостаточным условием повышения эффективности менеджмента. Главное в проекте — команда, которая может довести дело до конца. Всегда есть надежда, что это победа, а не крах.
Бороться с сопротивлением персонала и его страхом перед отключением старой системы Андрей Рыжов (ЗАО «Северсталь-метиз») советует следующим образом. В ИТ-проектах всегда проще строить систему с нуля, чем ломать то, что работает годами. Все ожидают видеть то, к чему они привыкли. При одновременном использовании двух систем приоритет отдается действующей, а не опытной. Поэтому хорошо, если менеджеры функциональных направлений станут участниками проектной команды. Они не знают, как работала старая система, но знают, как должна и будет работать новая, и сами могут решить возникающие проблемы. Отключайте старую систему при 90% достижения правильных результатов, но будьте готовы какое-то время «лечить» оставшиеся 10%. При этом жизнь достаточно быстро заставит пользователей работать правильно на 99,9 %.
В случае неудавшегося проекта топ-менеджмент рискует не только и не столько потерей авторитета и иногда снижением зарплаты, но и часто потерей или искажением данных, что приводит к ошибкам управления и развития бизнеса в целом.
Если сотрудники полностью вовлечены в проект, то они рискуют потерять прежнее место или должность, так как система или будет установлена и проекту спешно завершится, и не всегда можно вернуться к прежним обязанностям, или— неизбежный поиск новой работы.
Собственник бизнеса, решившись на информационно-технологический проект, в любом случае рискует деньгами и временем.
А если проект успешен, то компания получает нормализованные бизнес-процессы и прозрачность бизнеса, новое качество менеджмента, повышение капитализации компании, инвестиционную привлекательность и перспективы дальнейшего развития.
А все сотрудники, включая собственника, удовлетворенность результатами своей работы. Ради этого стоит рисковать.
Основные риски ИТ-проектов
1. Масштаб проекта
2. Кадровое обеспечение
3. Управление рисками
4. Нереальные сроки
5. Финансирование
6. Организационная политика
7. Многочисленные задержки выполнения работ
8. Неожиданные функциональные бреши
9. Вопросы взаимопонимания
10. Сопротивление нововведениям
Источник: www.topsbi.ru
Мотивация персонала
Андрей Крылович, компания Tops Bi:
— Проект внедрения системы всегда имеет начало и конец. А те квалифицированные специалисты, которые переводятся в проект, неизбежно отчуждаются из операционной деятельности. Таким образом, возникает противоречие: перед людьми ставят ответственную и сложную задачу, а они опасаются, что их место за время работы в проекте займут другие.
Система мотивации должна преследовать две цели — оперативную и стратегическую.
Оперативная мотивация персонала нацелена на то, чтобы специалисту хотелось работать в проекте. Это и моральная мотивация, когда сотруднику понятны высокие цели проекта, его роль в развитии компании и т. д., и материальное стимулирование, связанное со сроками реализации проекта, принятием проектных решений, активностью сотрудника и т. д.Но не менее важна мотивация стратегическая. Сотрудник, привлекаемый в проект, должен понимать, что по его окончании он не будет понижен в должности, ему будет предложена работа, соответствующая его квалификации и вновь приобретенным знаниям. Более того, если человек хорошо зарекомендовал себя как квалифицированный специалист и у него есть определенные планы карьерного роста, то ему нужно дать гарантии, что проект не помешает его устремлениям.
Руководство должно понимать, что, возвращаясь в операционную деятельность, сотрудник будет иметь более высокую квалификацию и потенциальные возможности, а значит, для него должны быть открыты некоторые перспективы.
Существует немало примеров, когда люди, которые участвовали во внедрении системы, потом действительно выходили на более высокий уровень и по зарплате, и по статусу. То есть в стратегической мотивации тоже присутствуют две составляющие — моральная и материальная. Важно добиться сочетания желания людей работать в проекте исходя из текущих моральных и материальных интересов с их карьерными устремлениями.
Специалист должен быть уверен в своем дальнейшем положении в компании.
Заключение контракта
Михаил Михайлов, Группа компаний «Пивоварни Ивана Таранова»:
— Чтобы снизить риски, необходимо в контракте на выполнение работ по ИТ-проекту прописать некоторые важные положения.
Контракт должен соответствовать бюджету. Есть попытка завысить стоимость проекта со стороны поставщика системы, консультанта или внедренца. Обещают выполнить все работы за копейку, а потом стоимость проекта резко возрастает. Поэтому часто проект останавливается на стадии обследования.
Еще до подписания контракта надо определить выгоду поставщика, иначе проект не будет выполняться. Еще необходимы процедуры приемки результатов, расторжения контракта и изменения его условий. Это должны быть именно процедуры, в которых подробно определяется, что, как, когда и кому надо делать.
Можно прописать фиксированную стоимость всех работ и установить ставки (тарифы) на дополнительные изменения.
Полезно также утвердить устав проекта — процедуру взаимодействия заказчика и исполнителя и определить состав проектной команды, документы проекта и их маршруты и другие факторы, снижающие неблагоприятные риски проекта. До начала проекта разумно задуматься и о том, как дальше поддерживать внедряемое ИТ-решение.
Алгоритм победы над рутиной
Андрей Габец, компания «Аналит»:
— Риск —возможное незапланированное событие, которое может быть и негативным, и позитивным для выполнения проекта. Поэтому управление рисками направлено на максимизацию благоприятных событий и минимизацию неблагоприятных. Обычно вся работа проводится в таблицах (карточках), которые позволяют наглядно и всесторонне управлять рисками.
Алгоритм работы с ними включает в себя процедуры:
- идентификация и оценка рисков;
- определение ответов на них;
- анализ взаимного воздействия ответов и рисков;
- планирование оптимального реагирования;
- контроль исполнения и мониторинг рисков.
Перед началом проекта открывается карточка риска, куда вносится вся информация, необходимая для управления рисками. В карточке ведется список возможных рисков, оценивается их вероятность, сюда же вносятся результаты анализа возможных рисков и их угроз и т. д.
Для удобства идентификации рисков необходим классификатор, который может быть составлен по:
- источникам рисков;
- этапам жизненного цикла проекта;
- этапам жизненного цикла продукта;
- типу риска.
Обычно риски оцениваются по трем основным факторам: вероятность возникновения, степень оказываемого воздействия и влияние на срок выполнения проекта. Оценку можно проводить в баллах или в процентах. Например, если вероятность проявления риска высокая — 3 балла, или70% и выше, средняя — 2,или от 40 до 70%, низкая —1, или менее 40%.
Аналогично оценивается и воздействие, оказываемое риском на проект. Можно воспользоваться и другим критерием. Если воздействие приведет к потерям менее 1% бюджета или затянет сроки исполнения проекта менее чем на 5% отведенного времени, то его можно считать низким. Если между 1 и 5% бюджета или 5 и 10% времени — средним, более 5% бюджета, или более 10% времени— высоким.
Если действия по реагированию на риск можно отложить на 50% оставшегося времени исполнения этапа проекта, то влияние такого риска оценивается как низкое, если на 20%, то как среднее. Если же реагировать нужно немедленно, то такое влияние риска на сроки проекта считается высоким.
Консолидированная оценка жесткости риска определяется перемножением коэффициентов вероятности, воздействия и срочности.
Всеми рисками, получившими оценку ниже 8 баллов, можно пренебречь. Для рисков с оценкой выше 12 нужно вырабатывать мероприятия по снижению их статуса.
При работе с рисками используются следующие стратегии.
✔ Избежание рисков — выбрать такое проектное решение или альтернативу, которое исключит рисковое событие, например внести в контракт положения, которые позволят создать более благоприятные условия выполнения проекта.
✔ Передача рисков — передать рисковое событие через контракт, например, третьей стороне. Страхование рисковых событий в страховых компаниях.
✔ Смягчение рисков —предпринять меры, чтобы снизить вероятность риска и/или уменьшить степень его воздействия.
Так как меры, принимаемые в отношении одних рисков, могут воздействовать на другие и даже порождать новые, то необходимо проводить анализ взаимодействия рисков и мер реагирования на них. Согласно сделанным выводам формируется план мероприятий по снижению вероятности риска или его неблагоприятного влияния на проект. Далее определяются точки целесообразного мониторинга риска и критерии эффективности проведенного мероприятия.
В процессе контроля проводится анализ результатов выполнения запланированных по каждому риску мероприятий, их воздействие на риск и весь проект в целом.
Такая модель управления рисками не содержит сложного математического аппарата и позволяет тратить на эту, нужно признать, рутинную работу не более одного часа рабочего времени, но ежедневно.
Процедура «Управление рисками». Реагирование
|
Риск/Возможность |
Мероприятия ответа на риск |
Критерии эффективности мероприятия |
Ответственный |
Планируемые сроки контроля и мониторинга |
Результат/Дата/Роспись |
|
Недооценка сложностей (недооценка предметной области) |
Проведение дополнительного обследования |
Предоставление отчета о ходе работ/необходимости доработок |
Сидоров |
22.07 |
Предоставлен 23.07 |
|
Ошибки в планировании сроков работ |
Подключение новых сотрудников к проекту |
Реперные точки сдачи готовых подсистем проходятся с задержкой не более чем на 1 день |
Сидоров |
25.07, 20.08, 01.09 |
25.07. Пройдена первая реперная точка вовремя |