Команды PLM проекта

Кому в команде изучать предметную область

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

Общая архитектура команды проекта PLM

Общая архитектура команды проекта PLM

Кому изучать предмет?

Кратко приведем описание ключевых ролей команды Исполнителя и Подрядчика:

 

Директор проекта от Исполнителя и Подрядчика. Сотрудник, принимающий стратегическое решение о реализации проекта по запросу Заказчика и выделяющий на реализацию проекта финансовые, кадровые, организационные ресурсы.

Менеджер проекта. Сотрудник, который осуществляет общее управление проектом, являясь полноправным представителем Исполнителя или Подрядчика.

Главный Архитектор решения. Сотрудник Исполнителя, который определяет техническую концепцию, архитектуру и применяемые технические решения при создании системы класса PLM. По сути, он является техническим менеджером проекта.

Группа системных аналитиков. Сотрудники, которые выполняют аналитические работы по обследованию бизнес-процессов Заказчика (AS IS), прорабатывают концепции решения (TO BE), разрабатывают проектные документации (аналитические отчеты, технические задания, документы стадии технического проекта). Также они взаимодействуют с прикладными программистами в части постановки задач.

Группа специалистов по внедрению. Специалисты, которые выполняют работы по установке, настройке, конфигурированию внедряемой системы, подготавливают эксплуатационную документацию и инструкции. А также проводят обучение администраторов и пользователей Заказчика и оказывают техническую поддержку.

Группа прикладных программистов. Сотрудники, которые разрабатывают прикладное ПО, специализированные отчеты, интеграционные решения.

Группа системных администраторов. Сотрудники, которые отвечают за подготовку и адаптацию инфраструктуры системы (ОС, СУБД, Сетевые протоколы, LDAP, Почтовые сервера и т.д.), обеспечивают настройку резервного копирования восстановления системы и обладают более глубокими знаниями в области системного администрирования чем специалисты по внедрению.

Группа поддержки. Сотрудники, обладающие глубокими знаниями в предметной области Заказчика и смежных процессах и оказывающие соответствующую экспертизу. Чаще всего, это сотрудники, ранее работавшие на стороне Заказчика.

 

Как уже отмечалось в первой заметке, чтобы внедрение PLM системы было успешным и эффективным, изучать предметную область необходимо всем участником проекта, в том числе и команде Заказчика. Во второй заметке было рассмотрено какие области необходимо изучать команде Исполнителя. Рассмотрим подробнее кому именно необходимы эти знания:

  • Директор проекта от Исполнителя и Подрядчика — Достаточно общего представления о предметной области Заказчика.
  • Менеджер проекта — Необходимость понимания предметной области рассматривалась в статье База рисков PLM проекта: Менеджер проекта «из смежной области». Если менеджер проекта не знает предметной области, он должен иметь в команде сильного Архитектора решения и делегировать ему всю ответственность, связанную с техническими аспектами проекта, оставив себе бюджет, коммуникации, риски, рамки проекта и т.д.
  • Главный Архитектор решения, Группа системных аналитиков, Группа специалистов по внедрению — Специфика их работы делает очевидным необходимость знания предметной области Заказчика. Глубина знаний чаще определяется опытом конкретного сотрудника.
  • Группа прикладных программистов — Знание предметной области для программистов чаще приветствуется, но не требуется. При отсутствии таковых, между Заказчиком и программистот всегда должен быть аналитик, который будет транслировать требования Заказчика в реализуемые и понятные задачи для программиста.
  • Группа системных администраторов — Знание предметной области Заказчика не требуется.
  • Группа поддержки — Роль группы уже означает наличие широких знаний и опыта работы в предметной области Заказчика.

 

Вывод: чтобы гарантированно не завалить проект, и PLM система работала не только на бумаге (как это часто случается в настоящий момент, когда вроде акты подписаны, система введена в промышленную эксплуатацию, а сотрудники — работают по старинке) – не игнорируйте такой аспект проекта, как изучение предметной области Заказчика и закладывайте время на развитие компетенции своих сотрудников.

Простой шаг к развитию компетенции команды проекта

Вы сейчас читаете одну из цикла заметок, посвященных изучению предметной области машиностроения.
Заметка представляет собой сокращенный вариант статьи, потому что редакторы plm.center подозревают, что сейчас люди разучились читать длинные тексты и сократили его :-)

Евгений Ураскин