Проектная организация как сервисная организация.

Разработка проекта - это один из видов услуг (сервисов), хотя до сих пор еще рассматривают эту деятельность как создание продукта (пачек бумаги, называемых проектом). Поэтому естественно рассмотреть управление проектами как управление услугами.

Существенное отличие "фабрики" услуг от реальной фабрики, производящей продукты (в т.ч информационные) в том, что услуги нельзя накопить на складе.

Передовой опыт управления ИТ - сервисами (в библиотеке ITIL) описан достаточно общо, поэтому естественно попытаться обобщить его и на управление проектами.

Для этого необходимо учесть, что в процессе выполнения проекта все его участники (проектные группы) оказывают услуги. Услуга состоит в выполнении в срок и с заданным качеством определенных работ. Проектные задания группам рассматриваются как SLA.

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

Инциденты различаются срочностью и важностью, и, значит скоростью разрешения.

Приоритет инцидента определяется из совокупности сложности и важности. Наличие приоритетов необходимо для установления очередности разрешения инцидентов. Ресурсы всегда ограничены и приходится поступающие инциденты выстраивать в очередь. При разрешении инцидента мы не выявляем его причину, а делаем все необходимое для восстановления нормального хода проекта. Например, при длительной болезни одного из проектировщиков мы не ищем причину, а передаем его работу другому. В этом случае инцидент разрешается обходным путем (workaround). После разрешения инцидента, таким образом, необходимо передать запрос на изменение в процесс Управление изменениями. Иногда инцидент можно разрешить только путем устранения корневой причины. В этом случае из процесса Управление инцидентами делается запрос на изменение в процесс Управление изменениями. Что делать, если в отведенные сроки инцидент невозможно разрешить? Пользуясь процедурами эскалации, передать по выше по уровню управления выше ("пусть начальство разбирается") или (и) на следующий уровень функциональной эскалации (например, на следующую линию поддержки). Наиболее сложные инциденты передаются в процесс Управление проблемами.

Проблема - неизвестная корневая причина одного или более инцидентов. Цель решения проблем- уменьшить или не допустить появления инцидентов в будущем, тем самым повысив продуктивность использования проектных ресурсов. Для проблем так же, как и для инцидентов, существуют приоритеты.

Когда проблема решена, Менеджер проблем открывает Известную ошибку.

Известная ошибка - это результат решения проблемы. Но почему же сразу не устранить корневую причину? Устранение такой причины может привести к другим инцидентам так как проектная среда достаточно сложна и все взаимосвязи сразу не видны. Поэтому необходимо передать Запрос на изменение в процесс Управление изменениями, где Комитет по изменениям, рассмотрев все аспекты устранения Известной ошибки, примет окончательное решение, устранять ли ее или нет. При рассмотрении на комитете будет оценено влияние инцидента на бизнес и срочность этого изменения. Если изменение будет одобрено то, с учетом приоритета изменения все соответствующие участники проекта проведут это изменение.

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

back..

home...