Для чего проект разделен на фазы, и каким принципом, как правило, руководствуются при дроблении проекта по фазам?

На самом деле все предельно просто, первое – по результатам фазы отслеживается выполнение проекта, осуществляется его управление, а второе – к фазам удобно привязывать условия договора: актирование, график платежей и т.д.  Понятно, что каждая фаза при этом должна заканчиваться определенным продуктом, который возможно считать, с точки зрения сторон, предметом договора или его частью.

Создание проектного офиса

 

Первая и, как правило, самая короткая фаза проекта. Очень часто её название вводит в «ступор» заказчика. Однажды, когда я имел честь работать во внутренней команде одного бравого металлургического предприятия, со стороны ТОП-менеджмента звучали довольно ехидные вопросы: «А что, на этом этапе они стулья расставлять будут?».

На самом деле, конечно же, в данном случае расставляются не стулья и даже не столы. Продуктом данной фазы проекта на самом деле являются основные документы по управлению проектом: приказ о начале проекта, устав проекта, подробный календарный план, план управления рисками, план коммуникаций и т.д.

Часто название фазы выбирают другим, мне лично нравится именно это, т.к. на самом деле максимально отвечает содержанию.

 

Обследование

 

На данной фазе проекта консультанты подрядчика знакомятся с процессами на предприятии, которые им предстоит автоматизировать, изучают требования. Общение консультантов и работников предприятия чаще всего проходит в форме интервью, после которого консультантом готовится отчет о проведенной встрече. Отчет в обязательном порядке должен быть подписан всеми участниками встречи. В дальнейшем все отчеты о проведенных интервью ложатся в отчет.

Лучшей практикой считается подготовка описания бизнес-процессов в виде диаграмм в каком-либо CASE-продукте. Такую схему называют «Схема бизнес-процессов «Как есть (AS-IS)». Но, к сожалению, из-за дороговизны программных продуктов, а также низкой востребованностью со стороны заказчика, эта технология очень редко используется на проектах. А жаль, ведь её использование позволяет производить различные аналитические заключения о состоянии бизнес-процессов, производить оптимизацию и, самое главное, в дальнейшем при концептуальном проектировании и построении модели «Как должно быть» (TO-BE) позволяет производить сравнительный анализ, т.е. позволяет прогнозировать выгоды от внедрения ERP-системы. Результатом данной фазы также зачастую является уточненное техническое задание.

Концептуальное проектирование (модель TO-BE)

 

Фаза Концептуального проектирования на самом деле должна включать в себя и работы, проводимые на фазе Обследование, но с точки зрения управления проектом, а в особенности бюджетом и сроками, я считаю их лучше разделить. Дело в том, что на фазе обследования подрядчику уже может стать ясной необходимость корректировки календарного плана и состава работ, вопрос об этом должен быть вынесен на обсуждение и приняты соответствующие меры. Если этого не сделать на данном этапе, то сделать потом практически невозможно (хотя и в данном случае необходимо проявить чудеса дипломатии).

Фаза концептуального проектирования, по моему мнению, это один из самых сложных этапов проекта. Здесь, зачастую, происходят столкновения различных структур предприятия, и, как следствие этого, подрядчику приходится постоянно искать выход из сложившегося положения. Ведь в конечном итоге успешность реализации именно данной фазы даст толчок успешномой автоматизации бизнес процессов с учетом требований, выдвигаемых системой. Разрабатываемый на данном этапе проекта документ  — концептуальный  проект,  является тем правилом, по которому в дальнейшем будет строиться не только конфигурация системы, но и бизнес-процессы. Ведь не секрет, что информационная система – это тот инструмент бизнеса, который позволяет принимать оперативные, тактические и стратегические решения, а также влияет на работу подразделений, участвующих в подготовке информации.

Также определенную сложность в ходе данной фазы составляют поправки на творчество и креативность членов проектной команды. При работе над концептуальным проектом должны проводиться дополнительные консультации с бизнес-экспертами, организовываться мозговые штурмы. Все должно быть сделано для того, чтобы система была максимально заточена под требования заказчика, а в этом и состоит основная трудность.

Реализация

 

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

Интеграционный тест может проходить по разным сценариям, но смысл данного мероприятия в том, что исполнитель должен доказать заказчику работоспособность системы, а также её адекватность по отношению к требованиям. Тема это настолько сложная, что в данной статье я не буду в неё углубляться, поговорим об этом позже.

Продуктивный старт системы  — это в принципе именно та веха, ради которой работает консалтинг. На моем опыте были различные продуктивные старты и это тоже очень сложная и обширная тема. Скажу лишь то, что если продуктивный старт случился, то проект на 90% удался.

Первоначальная поддержка

 

Гарантийное обслуживание системы, здесь и писать то особо нечего. Очень сложная для исполнителя и заказчика фаза. Начало работы в любой системе сопровождается большими сложностями и обилием ошибок со стороны пользователей, да и в самой системе, как правило, находится довольно много багов. И сложность во многом состоит, что все перечисленное выше случается одновременно у разных людей. Критичным для успешности данной фазы и проекта в целом является отказ от параллельного учета в исторической (старой) системе. После отказа от параллельного учета и закрытия периода учета, охватывающего весь диапазон автоматизируемых операций, можно считать проект успешным и законченным.

  4 Ответов в “Типовые фазы проекта внедрения SAP ERP”

  1. Здравствуйте, Артем! Еще хотелось бы отметить один из важных, я даже бы сказал определяющий этап — это обучение ключевых и конечных пользователей. Данный этап обычно входит в фазу «Окончательная подготовка» (Final Preparation) по методологии ASAP. Ведь от качества проведенного обучения будет зависеть то, как новоиспеченные пользователи SAP смогут управляться с системой на этапе продуктивного старта!

    Большое спасибо за Ваши интересные материалы.
    С уважением,
    Alex

  2. Добрый день. Спасибо за комментарии.

    Совершенно согласен, обучение пользователей важнейший этап, но я все-таки рассматриваю его как составляющую часть других фаз.
    Простой пример — сейчас внедряем функционал управления ссудными сделками, продуктивный старт, финансисты обучены и должны вводить сделки, бухгалтерия еще нет. Почему нет? Да потому, что не нашли они время обучиться — это раз, начисление по ссудным сделкам будет проходить только через 1,5 месяца — это два, просто все забудут… Конечно можно продавить и найдут они время, никуда не денутся, но как правило люди на обучение в таком случае приходят нервные и не в полном составе, а если отложить продуктивный старт, то тоже ничего хорошего ждать не приходится. Вот и приняли решение — фазу «Реализация» считать завершенной, а часть работ по обучению перекинуть на первоначальную поддержку. Решение не тривиальное и влечет риски, но лучше управляемые риски, чем проблема. Конечно, в данном случае мы на все 100% должны быть уверены, что обучение будет проведено :)
    Еще часто приходится делить проект на пилот и тираж, в таком случае обучение также «размазывается» по разным фазам.
    В статье я попытался описать самое типовое и весьма кратко. Выделение фазы «Окончательная подготовка», на мой взгляд, не всегда целесообразно, хотя не претендую в данном вопросе на истину в последней инстанции.
    В дальнейшем есть планы углубиться в данные вопросы более подробно.

  3. Уважаемый Артем!
    Я приветствую любую просветительскую (миссионерскую) деятельность. Но более чем отрицательно отношусь к лже-просветительству, которое процветает с помощью интернет-технологий.
    Думаю, Ваши предыдущие проекты затухали не по причине безплатности или Вашей лени. Скорее всего, истинной причиной был низкий образовательный уровень материалов. Во всяком случае, к такому выводу я пришел после прочтения данного раздела.

    Уважаемые читатели! Если вы хотите ознакомиться с методологиями выполнения проектов внедрения (имплиментации) продуктов SAP AG, прочитайте официальные материалы компании. Вы обнаружите, что SAP предлагает несколько методологий, маршрутные карты которых отличаются и количеством фаз, и составом пакетов задач, и различной корреляцией со стандартом управления проектами PMBoK PMI и методологией Agile. А заодно узнаете, чем вызвано такое разнообразие, что очень важно для правильного выбора методологии и эффективного исполнения проекта.
    Не могу удержаться от комментария по поводу обучения. Пакеты задач по обучению персонала заказчика (клиента) включены SAP практически во все фазы проекта! На разных фазах учебные курсы отличаются глубиной материала (уровнем по классификации SAP) и категорией слушателей.
    Методология внедрения любой ERP-системы (я лично знаю не только SAP, но и Oracle, и IFS), предполагает матричную организационно-штатную форму выполнения проекта (КП), при которой команда проекта формируется из представителей владельца проенкта (т.е. клиента) (джентельменский набор КПА: управляющий совет, руководитель проекта, руководители функциональных (предметных) групп (владельцы БП), ключевые исполнители, группа по орг.изменениям), с привлечением внешних консультантов исполнителя.
    Неправильная организация проектов (чем у нас частенько грешат) приводит к снижению экономического эффекта от внедрения ERP, ибо проект сводится к настройке информационной системы, но никак не к внедрению ERP-концепции управления ресурсами предприятия. Увы, даже разницу не многие понимают.
    Артем, если Вы отлично владеете ABAP и технологиями программирования SAP — делитесь этими знаниями, но не пишите о том, в чем ничего не смыслите. За профессию обидно!

    • Добрый день Владимир. Спасибо за коммент.
      При личной встрече можно было бы многое обсудить, но формат комментариев мало подходит, тем более я о длинном, а вы о зеленом :) Описанные мной фазы совершенно не противоречат с приведенными вами схемами организации проекта, не очень понял зачем вы мне это привели в противовес…
      Ну и напоследок. Начинал я с ABAP (и сейчас этим грешу иногда), но сейчас у меня за плечами не один успешный проект в качестве руководителя или, как минимум, архитектора, поэтому о типовых (ключевое слово) фазах я говорю не с позиции теоретика. Назовите какие фазы Вы бы еще обоснованно выделили как типовые, и я с удовольствием добавлю их в свою статью (смею заметить совершенно бесплатную :) ).

      Удачи!!!

 
© 2013 sap-blog.ru
Яндекс.Метрика