Введение в управление проектами внедрения ERP-систем

Книга: Введение в управление проектами внедрения ERP-систем
Назад: 4.1.1.Управляющий комитет
Дальше: 4.1.3.Рабочая группа со стороны заказчика

4.1.2.Проектная команда исполнителя

Проектная команда исполнителя состоит из специалистов, занимающихся внедрениями ERP-систем. В нее входят:

  • методисты (консультанты и аналитики),
  • системные архитекторы,
  • разработчики,
  • тестировщики,
  • технические писатели.

Обычно роли методистов, тестировщиков и технических писателей совмещают одни и те же специалисты с общим названием «консультанты». От слова «консультировать», поэтому и «консалтинговые услуги», и «консалтинг» (англ. consulting) как вид деятельности.

Системный архитектор формирует общую архитектуру будущей системы и принимает решение о способах реализации требований к ней.

Функциональные обязанности:

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

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

Функциональные обязанности:

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

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

Функциональные обязанности:

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

Внутри команды исполнителя у консультантов и разработчиков может быть дополнительная градация в зависимости от квалификации специалиста, например: стажер, специалист, ведущий специалист. Или возможна иная система позиционирования должностей (система грейдов, англ. grading) и ставок от этого. Главное – это поставить на задачи проекта специалистов с достаточной квалификацией для их решения.

Бывают ситуации, когда несколько ролей сосредоточены в одном человеке. Например:

  • руководитель проектов + системный архитектор;
  • руководитель проектов + консультант;
  • системный архитектор + разработчик;
  • системный архитектор + консультант;
  • консультант + разработчик.

Рис. 4.3. Схема взаимодействия команды проекта

В частных случаях и в небольших проектах (реже бывает, что и в больших) это может быть небольшая группа таких «универсальных солдат», которые творят чудеса при внедрении системы. Но на практике для проектов внедрения систем класса ERP есть опасность возникновения ситуации, когда один человек – это и консультант, и разработчик: сам себе написал ТЗ, сам по нему все сделал, сам все протестировал (в процессе отладки, как разработчик и не более). Все вроде хорошо? Не совсем: ТЗ нужно формально описать и согласовать с ключевыми сотрудниками заказчика, как бы ни хотелось оптимизировать работу и самому себе ТЗ не делать. Протестировать модификацию необходимо. Руководство пользователя написать тоже нужно, обучение пользователей провести. А есть еще задачи коммуникации со сложными в общении пользователями и навыки формулирования понятных непрофессионалам текстовых описаний. И вот это часто совместить в одном человеке сложно: консультант ориентирован на коммуникацию с пользователями заказчика, разработчик – на стройную логику в коде. Но если у вас в команде такие универсальные люди есть (а они бывают, автор таких встречал), то их компетенциями необходимо умело управлять, соблюдая проектные методологии!

Назад: 4.1.1.Управляющий комитет
Дальше: 4.1.3.Рабочая группа со стороны заказчика
Показать оглавление

Комментариев: 0

Оставить комментарий