Среды сотрудничества и управления проектами в автоматизации бизнесов

Меня долго занимал один вопрос. Почему внедрение средств управления проектов в России сложнее, чем на западе? Недавно я понял, что причина в не отделении проектной организации от других видов бизнесов.

Чтобы понять роль инструментов «ведения проектов» и «сотрудничества в проектах» (collaboration tools) достаточно понять место проектов в конкретном бизнесе. Как выглядит идеальная структура проектно-ориентированной организации?

Когда основным процессом производства являются «проекты», то каждый проект, как живой организм, включен в более широкий контекст бизнеса. В этом «широком» контексте можно выделить:

1. CRM и продажи
2. Финансовая поддержка проектов
3. Юридическая поддержка проектов
4. HR, служба персонала
5. Ведение «рабочей среды», environment. То, чем занимается офис-менеджер
6. IT-служба, основная цель которой в данном случае – продуктивность проектов.
7. Общение с подрядчиками, аутсорсинг, фрилансеры
8. Общение с клиентами

Естественно, бизнес в свою очередь включен в намного больший контекст государства, рынков и других элементов. Мы их не будем рассматривать.

Команда как внутренняя структура проекта

Итак, внутренняя структура проекта – это его команда. Команда состоит из

• Экспертов
• Поддерживающего персонала
• Менеджера проекта

Эксперты – это основная движущая сила проекта. Собственно, те, которые вкладывают свои знания и усилия для создания продукта. Это могут быть программисты, архитекторы, маркетологи, консультанты, в зависимости от отрасли бизнеса.

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

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

Система ведения проектов? Место!

Так каково же место систем поддержки проектного процесса? Что она должна обеспечивать? В такой схеме это

• взаимодействия «внутреннего» круга проекта между собой
• управление проектом
• минимально необходимые взаимодействия с «внешним» кругом

Наиболее важны отношения с клиентом и подрядчиками, вплоть до включения их в команду проекта (в случае customer on-side или фриланса). Поэтому соединения с этими двумя «внешними» секторами обычно становятся частью самого проекта. Цели внедрения отдельной системы для ведения проектов очевидны. Это максимальное использование потенциала команды и фокусирование их на одной цели. Увеличение производительности, скорости и качества проектов. За счет использования как инструментов общения, так и методологий управления проектами.

Опять сложности

Возвращаясь к основному вопросу. В чем же сложность внедрения? Сложность в том, что зачастую в системы ведения проектов стараются «впихнуть» и обслуживание внешнего круга, то есть задачи любого из поддерживающих направлений. Это естественно, ведь стандарты автоматизации существуют на данный момент только для финансов, и частично для CRM / продаж. Таким образом, инструменты ведения проектов используются для процессов не внутри проектов.

Какие именно «мостики» должны соединять систему ведения проектов, и внешние службы? Обычно это соединение или в форме «контактов» от отдела продаж, или «инцидентов» для офис-менеджера, или «отчетов» для финансового отдела и HR.

«Мостики» и работа всех служб в одной среде — возможны. Но разделение «проекты — службы» должно быть четко видно хотя бы руководителям при решении о внедрении системы. И тогда можно ответить на вопрос, что же именно стоит автоматизировать в первую очередь. И как все связать в интегрированную среду.

Ффух! Разобрался! Чего и вам желаю.