ERP за 4 месяца: 3 взгляда, 2 лидера, 1 результат

Начальные условия Организация-объект внедрения Оргкомитет «Сочи 2014» – организация, задача которой – подготовка и проведение Олимпийских Игр в г.Сочи в 2014 г. Организация молодая (создана в 2007 г.), быстрорастущая (нет устоявшихся бизнес-процессов) Организация амбициозная и профессиональная (на основных позициях – менеджеры со своим профессиональным опытом, «словарем», планами) Нет устоявшихся стандартов (управленческой отчетности, бизнес- процессов), доступ к опыту других Оргкомитетов пока ограничен, зачастую этот опыт неоднозначен и неприменим

Начальные условия Задачи автоматизации Объем проекта: –В первую очередь – финансовый блок РСБУ Управленческая отчетность Бюджетирование AR AP FA Materials –Плюс: управление закупками и контрактами, HR и зарплата, управление проектами Срок: –начало – ноябрь 2008 г., –старт системы – 2 марта 2009 г. (жестко заданная и контролируемая дата)

Начальные условия Структура проекта «Майкрософт Рус» Генподрядчик GMCS Субподрядчик (Финансы, Логистика) «Аплана» Субподрядчик (HR, Зарплата) Accenture Субподрядчик (Контроль качества) Оргкомитет «Сочи 2014» Основные исполнители работ

«Радужные планы» Внедрение системы использований основных положений методологии Microsoft Sure Step (последовательные фазы проекта, полный набор проектной документации, с аллоцированными ресурсами Заказчика, методичным «обучением обучающих»…) Запуск системы по плану (с тестированием и опытно- промышленной эксплуатацией) Параллельная работа в «старой» и «новой» системах на этапе опытной эксплуатации

«Суровая реальность» Что происходилоПочему?Как повлияло? "Перекрытие" и "сползание" фаз 1) задержки с контролем качества со стороны Исполнителя 2) ресурсы Заказчика 3) завышенные ожидания бизнес- пользователей 4) ответственность за принятие решений Отрицательно: разработка шла по неподписанным Дизайнам: и Исполнитель и Заказчик жили под риском расползания рамок проекта Запуск без пилотного тестирования, и без параллельного ввода в старую систему, правка системы "с колес" "Перекрытие" и "сползание" фазОтрицательно: жили под риском crash системы – не сдача баланса (риски Заказчика) Обучение "на местах""Перекрытие" и "сползание" фазОтрицательно: больший объем обучения (риски Заказчика - ограниченный объем обучения по Контракту) "Поучасточный" запуск"Перекрытие" и "сползание" фазПоложительно: спонсор проекта видел отдачу и реальный результат максимально рано

Взгляд QA и Партнера QA контроль качества в таком проекте это в первую голову приемка: кто, когда и как сможет оценить полученные результаты и сказать насколько они адекватны ФД – документ фиксирующий требования Заказчика. Без него невозможно проводить приемку «go-live» без тестирования и приемки – экстремальные риски Партнер Технический проект – на 90% устаревший документ Пилотное тестирование – 50-80% проверки системы Запуск без дублирования – единственный реальный вариант запуска Обучение пользователей в момент запуска – 80% снятия негатива и ошибок

Результат Несмотря ни на что… - В срок - В бюджете - В запланированном объеме

Почему все-таки можно внедрить систему за 4 месяца? Казалось бы, приведенные отрицательные факторы делают проект нереальным… почему же успех? 1.Инструменты. Отбор действительно эффективных в данной ситуации инструментов управления проектом 2.«Микроменеджмент». Детальный контроль работ подрядчиков 3.«Сожженные мосты». Отсутствие второй системы 4.Опыт и принятие решений. Большой опыт выполнения проектов у сотрудников Заказчика и подрядчиков 5.Обучение и коммуникации. Налаживание эффективных коммуникаций между всеми участниками и доверительных отношений с непосредственными исполнителями

Инструменты Примененные инструменты управления проектом Использованы только те документы, которые необходимы: –еженедельные Оперативные Советы, в отчетах – статус за неделю (достижения, проблемы), в протоколах – фиксация заданий (task list) с еженедельным контролем их выполнения –постоянный контроль проекта (отчетность) со стороны высшего руководства (Президента), раз в 2 недели – Управляющие Комитеты, в протоколах – фиксация заданий (task list), возможность эскалации проблем на УК, Performance Management –формат стандартных отчетов Microsoft был существенно переработан с точки зрения наполнения и наглядности

«Микроменеджмент» ежедневный контроль хода работ: –постоянное (ежедневное) участие Руководителя Проекта от Заказчика в решении проблем, личное получение информации о реальном положении дел – возможность превентивного реагирования и своевременной эскалации –оперативное принятие решений (организация работ, функционал системы) –оперативное принятие решений по управлению бюджетом проекта: сэкономили на каких-то работах – увеличили по другим направлениям (обучение, доработки…)

«Сожженные мосты» Запуск без пилотного тестирования и параллельного ввода (вынужденный) –повышение ответственности линейных руководителей (см. выше – контроль со стороны высшего руководства): «отступать некуда» –запуск только ключевой функциональности, «хотелки» и «бантики» - потом (позиция, обоснованно транслированная со стороны высшего руководства)

Опыт и принятие решений Заказчик –Большой опыт управления у Функциональных заказчиков и Владельцев проекта –Большая экспертиза по внедрению ERP систем и «кризис- менеджменту» у Руководителя Проекта от заказчика, готовность брать на себя ответственность за принятие решений Подрядчики –Кадры, которые имеют опыт выполнения сжатых «кризисных» проектов –Готовность рисковать

Обучение вводное обучение проектной группы Заказчика – обязательно (единый язык общения) «перенос» обучения на более низкий уровень и на момент запуска: –контроль качества обучения, получение оперативной обратной связи от пользователей, обучение не формальное (по «окошкам» системы), а по использованию системы в тех или иных ситуациях, бизнес-процессах Заказчика –оперативное получение информации об ошибках системы (пользователи = тестировщики) –практика следует сразу за теорией, пользователи не забывают полученные знания, а сразу используют их на практике

Коммуникации – ключевой инструмент! Вертикальная коммуникация: –поддержание информированности руководства, интереса к проекту (УК, поучасточный запуск) –контроль выполнения решений Горизонтальная коммуникация: –рабочие отношения внутри команды, прежде всего – с ключевыми сотрудниками Субподрядчиков (быстрые устные договоренности по рабочим вопросам, документирование только принципиальных моментов) –высокая скорость реагирования Субподрядчиков на запросы Заказчика (консультации «горячей линии» с момента старта системы, on-line правка ошибок, добавление небольших удобств для пользователя…) – «снятие» первичного неприятия системы пользователями –члены команды Субподрядчиков – не просто консультанты по системе, они «носители» бизнес-процессов Заказчика, т.о. могут оперативно и эффективно оказывать консультации пользователям по всем аспектам работы организации с системой

Результат – живая система!

Наш проект