Создание сервисного центра ТОиР (проект)

Решил создать тему, которая по сути была начата [...].

У меня сейчас вертится множество вопросов, так как проектный менеджер я начинающий-преначинающий... Обратите внимание, что результатом проекта, по сути, является новая организация. В этом наверное заключается основная сложность проекта. Это ведь вам не продукт или услуга, которые я уже сам не один раз имел возможность проектировать.

При формулировании целей проекта менеджеры начинают путать их с целями дальнейшей деятельности новой организации. Мне кажется, что цели проекта не должны пересекаться с целями (показателями эффективности KPI) Сервисного Центра. Если мы (менеджеры проекта) возьмем на себя задачу улучшить какой-либо KPI на 10%, то мы можем с таким же успехом занять рабочие места в СЦ и получать зарплату за руководителей СЦ. Вполне логично, правда? А с другой стороны, проект должен быть увязан со стратегией, в основе которой лежат продуманные показатели KPI...

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

Я немного подкорректировал устав. Вот он:


Я могу привести цифры, касающиеся улучшения показателей ТОиР других предприятий, а также по сведениям разработчиков ПО. Ну, например, что-то [...].

Цели самого проекта не удается описать количественно, только какие-то качественные они получаются. У меня возникает вопрос: это нормально для такого проекта, результатом которого является новая организация? Или я просто все неграмотно формулирую?

Замечания приветствуются.

Отвечу Вам здесь


А что в ходит в рамки проекта?
Если про включает в себя разработку организационных документов, то та или иная стратегия обязательно будет использоваться, явно или неявно. Лучше бы она использовалась явно - меньше потом противоречий в жизни разгребать.


ITIL - это организация технической поддержки программного обеспечения.
Информационные системы характерны тем, что ошибки в них плохо предсказуемы (все систематические ошибки обычно выловлены и исправлены на фазе тестирования ПО). Поэтому ITIL по сути представляет собой стратегию "абсолютной непредсказуемости", когда бессмысленны ППР и ТО. Для ремонта оборудования ITIL может быть интересен тем, что дает классификацию функций аварийного сервисного центра.

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

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


Со стратегией чего? Если всего предприятия, то коррелировать со стратегией должен результат проекта, а не цели.


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


А это - проектные тезисы, позволяющие связать стоящие задачи с механизмами их решения. Результат проекта - это организация, ориентированная на <список стратегических целей и задач>, обладающая следующими качествами <список качеств>. отсутствие проблем, систематически возникающих в настоящее время <список проблем>


Цели могут быть и качественные и количественные. Но количественные выглядят профессиональнее

Ааа. Вот теперь я понял про ITIL/ITSM. Я думал, Вы предлагали мне организовать внедрение АСУ, используя эти методологии...

Что касается целей - понятно. Хорошо, когда цели поставлены какие ни есть конечные. Например, требуется на автомобиле набрать скорость выше 500 км/ч, то инженеры не просто разрабатывают новый гоночный автомобиль с максимальной скоростью 520 км/ч, но и садятся на него и разгоняются до этой самой скорости... Но по идее проект предполагает сложную кропотливую работу. А сесть в автомобиль и помчаться - это уже не проект...

Спор с инвесторами, конечно, короток...

Ладно сейчас придумаем. Вечная проблема в том, что точные целевые значения показателей не начертаны в Библии и других священных книгах.

Что касается целей и результатов, то в технической кибернетике принято цель/задание обозначать буквой G (goal), а результат/отклик - буквой R (response). Разница по модулю E=|G-R| - отклонение результата от цели - рассогласование (error), вызванное неопределенностью и неоптимальностью системы. В идеале результат - это попадание в цель (R=G), т.е. при успешном проекте по идее результат и цель - это одно и то же. Раз одно и то же, то задав цель, можно не описывать результат.

И вот противоречие: в уставе необходимо заполнить графы "Цели" (G) и "Ожидаемые результаты" (R). Я способен ожидать только результаты, соответствующие цели.

Поясню маленько. Цель - это виртуальный образ результата, представление в модели.

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

Как мыслят менеджеры:
Результат проекта - Сервисный центр с такими-то показателями
Цель проекта - Такие-то показатели

Масло масляное!

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

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

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

А стремиться к цели без четкого представления о результате можно вечно, бесчисленные секты и религии тому яркий пример. Сколько проектов было провалено из-за того, что организаторы не имели представления о том, что конкретно они хотят получить! Давайте им не уподобляться!

Хм... А зачем описывать цель, которая недостижима? Ну, например, нужно снизить издержки предприятия. Какая цель? Правильно - снизить издержки до нуля. Вы будете писать это в уставе?

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

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

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

Почему я такой упертый? Просто мне нужно заполнить графу "Цели проекта", а понимания четкого нет, что это и чем отличается от ожидаемых результатов. Я четко понял, что такое "Ожидаемые результаты проекта". [...]
Вы наверное скажете, что мне нужно потесниться и отдать работу другому, ибо я недостаточно компетентен. Но в том-то и проблема, что отдать эту работу некому, да и мне надо скоро магистерскую диссертацию защищать...

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

_________________
С уважением,
Александр Горшунов

Например, чтобы сказать "смотрите, какой я крутой! вы другие фигней занимаются, а я - смотрите, к каким высоким целям стремлюсь!". Или просто человек не знает, что цель недостижима, и не удосуживается эту достижимость проверить. Знаете такой класс людей есть - "прожектеры"?


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

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


Что-то я не понимаю. У Вас же предприятие ОПК, какая там может быть максимизация стоимости? Кому продавать-то?


Допустим, проект имеет целью "снижение издержек на 27%". Эта является как критерием завершения проекта, так и основой для его организации. Для доказательства достижимости цели проекта на этапе инициации описан ожидаемый результат проекта, состоящий из информационной системы А1 и связанной с ним организационной системы Б1 и приведены ссылки на аналогичный опыт на других предприятиях, на научные статьи, а также собственный анализ.

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


Цели проекта рекомендую определять следующим образом: идентифицируются заинтересованные лица проекта (см. в интернете), с ними проводятся интервью на тему "что Вы хотите от проекта", после чего выраженные пожелания сводятся в непротиворечивую систему, а если нужно - ищутся компромиссы. Ну и закрепляется все это на общем совещании заинтересованных лиц.


В этом вопросе я доверяю Вашему руководству Такие кредиты доверия просто так не даются.

Понятно.


Ага, теперь понятно стало. Цель - это критерий завершения проекта (достижимая цель), но в то же время в какой-то степени абстрактная. Результат - это уже более конкретное отражение цели.


Да, это мне известно. По стандарту PMBoK заинтересованные лица не участвуют в постановке целей на этапе инициации, они формулируют требования на следующем этапе, этапе планирования...