ProjectProfy.ru
Имя: Пароль:
Забыли пароль?

Статьи

Методика управления проектами [86]

Методические пособия и книги [28]

Готовые отраслевые решения [60]

Обзоры программ для управления проектами [63]

События в мире Управлениия Проектами [128]

Сравнение разных программ для управления проектами [26]

Обучение и сертификация [53]

Управление рисками [4]

Опыт внедрения [37]

Разрешение проблем MS Project и др. системах [4]

Скачать Microsoft Project [3]

Администрирование MS Project Server [36]

Разработка для Microsoft Project [5]



13.07.2010

Microsoft создал крупнейшие в мире внедрения. Извлечение уроков из опыта.

Владимир Иванов
Первый Microsoft Project MVP по России и СНГ
Дирекция по партнерам Microsoft в управлении проектами
PM Consulting Services

40 крупнейших мировых концернов перешли на Microsoft Project и создали крупнейшие решения

На мероприятиях по MS Project сотрудники Microsoft стали на короткое время показывать "карту кейсов" Microsoft Project. Это очень интересный слайд. На нем видны не только мировые концерны, которые перешли на  Microsoft Project, но и масштаб внедрений, а также примененные технологии.

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

В корпорации Boeing  комплексное решение  на базе Microsoft Project Server охватило более чем 22 000 рабочих мест. Комплексное решение General Motors еще крупнее - более 25 000 рабочих мест. Сами решения имеют порядка 10 000 000 (десяти миллионов) активных задач в портфеле проектов. Речь именно о активных десяти миллионах работ, без учета тех, что выполнены и ушли в архив. Еще недавно это были бы просто невероятные цифры для любой системы управления проектами.

Надо сказать, что Microsoft проявляет необычайную скромность, считая, что решения без сервера управления проектами в принципе нельзя засчитывать как корпоративное решение (EPM Solution). Многие клиенты Microsoft имеют базу лицензирования порядка 30 000 - 40 000 рабочих мест, однако они не используют MS Project Server и потому их Microsoft сам себе не засчитывает как "комплексное решение". Решения Boeing и GM это именно централизованные системы управления портфелями проектов, а не разрозненное использование MS Project в локальных подразделениях.

MS project
22 000 сотрудников Boeing теперь работают в комплексной системе под управлением MS Project Server

Так же если говорить о серверных решениях класса EPM Solution, то кроме Boeing и GM за короткое время Microsoft смог создать еще около 40 крупных комплексных внедрений в известных мировых концернах со средним масштабом порядка 1000-5000 рабочих мест. Как мы понимаем, масштаб более 1000 рабочих мест уже не относится к типу внедрений как "попробовать продукт", это полное и комплексное развертывание.

Добавим сюда еще другой факт. На последней Project Conference было официально объявлено, что клиентская база Microsoft Project за короткое время удвоилась с 10 миллионов пользователей до 20 миллионов пользователей.

Безусловно все это успех и Microsoft задает новую планку для рынка. Однако как видим вполне ожидаемого маркетингового шума вокруг крупнейших мировых внедрений в проектном управлении в Boeing и GM нет. Надо понимать, что такие комплексные концерны имеют все виды проектов какие только можно придумать. Тот же Boeing  проектирует, конструирует, строит гигантские заводы и обычные здания, выпускает самолеты и ракеты, управляет развитием и т.д. и т.п. Все эти многопрофильные проекты должны быть консолидированы в портфель проектов.

Почему же так мало информации об этих решениях? В немногих статьях типа интервью Балмера на Project Conference можно заметить публичные намеки на новых клиентов, в остальных случаях это демонстрации слайдов без публикации информации и обычно демонстрации менеджеров Microsoft для клиентов в режиме "тет-а-тет". Объяснение тут простое, если не печальное. Все эти 40 концернов конечно уже управляли проектами применяя лучшие для прошлого века системы управления проектами. Тем не менее, все они как один отказались от внедренных старых решений и перешли на Microsoft Project Server, чтобы создать решения следующего уровня. Неписанная этика маркетинга состоит в том, чтобы не публиковать кейсов показывающих отказ от каких-либо систем с однозначным указанием, от чего отказались. В прочем и сами клиенты редко готовы стать соучастниками маркетинговых войн.  

Но давайте оставим маркетологам их проблемы и постараемся сделать анализ уроков из этих крупнейших внедрений. Очень важно понять, почему ведущие мировые концерны не остановило то, что они вложили миллионы долларов в решения предыдущих поколений. Важно понять причины какие ограничения старых решений стали носить фатальный характер. С другой стороны  в 2010 году во многих отечественных тендерах задания написаны как "хочу как в Boeing". Новую методологию с оптимизмом воспринимают госструктуры, промышленные холдинги, ритейлеры и т.д.

Как же это удалось сделать решения класса "10 миллионов задач", если учитывать известные технологические ограничения MS Project по загрузке большого числа задач и проблемы совместного редактирования проектов? Как это обошли? Что не устраивало Boeing и GM в старых внедренных системах? Ответы на эти вопросы куда важнее маркетинга.

Почему Boeing и GM перестало устраивать управление портфелем "по-старинке"?

Я во время прошлого Глобального Саммита Microsoft специально с коллегами съездил на завод Boeing, чтобы познакомится с их опытом управления. Boeing известен своей высокой культурой управления и высокими инновациями. Поэтому можно не сомневаться, что "классическую" систему они смогли внедрить как нужно. Тем более, что система управления проектами далеко не самая сложная система для такого комплексного концерна. Вопрос нужно ставить не столько о недостатках старых ("классических") систем управления проектами, сколько о недостатках методологии на которой они построены. Новая методология требует новой технологии реализации и так получилось, что Microsoft это сделать проще чем другим.

MS Project 2010
Boeing и GM решили, что "классика" себя исчерпала и ушли к инновационному Microsoft 

Если Boeing или GM все же захочет официально сформулировать причины перехода на Microsoft, тогда мы будем знать официальную точку зрения.

Однако уже сейчас можно назвать "пороки" старых систем управления проектами:

  • Неполное соблюдение требований модели качества ISO. Начнем с парадоксального факта. Классические системы управления проектами неподдерживают в должной мере модель качества ISO, которая во многом базируется на контроле и согласовании промежуточных результатов. В машиностроении это известно как "ворота качества", другим чаще это знакомо как чек-листы и т.п. Эта базовая модель просто "повисает в воздухе", если что не изменить в самой системе управления проектами.
  • Отсутствие встроенной методологии актуализации планов и проблемы надежности информации. Настоящим бичом для классических систем управления проектами является отсутствие эффективной методологии и технологии поддержки актуализации. Конечно системы управления проектами умеют собирать фактические данные и сравнивать их с плановыми. Однако нет никаких механизмов, которые бы запустили согласования и перепланирование после срабатывания рисков, а также подтверждали надежность статусов выполнения. Следствием этого изъяна является то, что план по мере хода проекта все менее становится актуален и в конце концов перестает быть информацией для принятия решений. Фактически это конец системы управления проектами и многие до него дошли.
  • "Нет истории вопроса". Серьезная проблема классической модели в том, что она следит за план/фактными отклонениями, но не собирает информацию по каждому изменению и не побуждает документировать изменения. Поэтому в классической модели крайне затруднительно извлекать уроки (lesson learned) из завершенных проектов, т.к. информации из системы недостаточно для понимания как развивалось воздействие рисков и какие проектные решения принимались. Если бы была система согласования изменений, то можно было бы вести журнал с комментариями по изменениям, поэтому можно было бы легко построить отчеты по истории каждого вопроса. Но это "было бы", классика так не умеет.
  • Проблема консолидации. Классический подход консолидации портфелей проектов обычно базируется на той же идее, что и иерархическая структура работ (WBS). По-сути на такой же иерархический справочник предлагается "нанизать" все проекты компании. Однако такая методология содержит серьезные изъяны:
    - Структура проектов разных уровней должна строго соответствовать друг другу, на практике исторически сложившиеся методы структурирования проектов не подразумевают простое математическое объединение
    - Очевидно, что методология типа
    EPS требует ломки исторически сложившихся структур планов. Причем ломка делается ради самой ломки, т.к. не является потребностью бизнеса, а является ограничение инструментария методолога. Просто другого варианта консолидации нет.
    - Требуется вложиться в консалтинг по разработке иерархических справочников по консолидации. В масштабах любой корпорации внедрения таких справочников крайне дорогостоящее мероприятие, т.к. требует внесение изменений в документы всех служб.
    - Нет технологии произвольной консолидации ключевых результатов через модель согласований. Это скорее не столько недостаток, сколько подсказка как работает новая методология.
  • Проблема несогласованных изменений для топ-менеджеров. Очень серьезная проблема классической методологии в том, что менеджеры самого нижнего уровня могут несанкционированно изменить портфель топ-менеджеров. Дело в том, что "классика" подразумевает простое суммирование проектов в портфели без модели согласования и подтверждения новых данных. Например, самый младший менеджер может изменить свой проект, что неизбежно и немедленно приведет к коррекции портфеля топ-менеджера, т.к. в "классике" образован примитивным суммированием. Особенно приятны такие "сюрпризы" во время презентаций данных инвесторам или спонсорам.
  • Проблема несогласованных изменений примитивном пересчете по связям. Многие классические системы гордятся возможностью рассчитать за мгновения сетевой график на десятки тысяч задач. Однако именно эта возможность и стала проблемой. Если связи объединяют планы смежных подразделений, то примитивный пересчет по связи приводит к несанкционированным изменениям в планах зависимых подразделений. На практике это невозможно, все такие изменения согласуются и связь лишь повод для запроса на изменение срока.
  • Проблема информационной безопасности. Недостаток классической модели на WBS-образной консолидации и безусловном срабатывании связей имеет и другой опасный аспект. Для функционирования самой модели методолог вынужден пойти на нарушение ряда положений строгих систем безопасности. Действительно, рядовой менеджер в принципе знает над каким элементом WBS он работает, и сам путь по WBS раскрывает ему существенную информацию о самом изделии, проекте, его этапах и даже куда направлена стратегия компании. Посмотрите на свои пути по WBS и поймете, что тут серьезная проблема security. Аналогично связи с другими проектами обычно показывают ему названия связанных задач, что позволяет знать о планах смежных подразделений больше чем нужно. При разработке серьезной инновационной продукции это весьма опасно, т.к. хотя такая "утечка" и носит фрагментальный характер, но "мозаика" без труда может сложиться в общую картину.Классический метод защиты тут только один - переход на тотальное использование кодов WBS с закрытием доступа к названиям задач, однако это крайне усложняет работу пользователей превращая их в "шифровальщиков".
  • Слабый уровень контроля за рисками: только наблюдение, но не вовлечение в принятие решений. В классическом подходе топ-менеджеры просто статисты-наблюдатели. Им предлагают смотреть в отчеты, но запретить какие-то изменения они не могут, также никто не спрашивает через систему их согласия при запросе на ресурсы и сроки. Если сравнивать с приборами в самолете, то это все равно что у пилота бы зажигалось табло "двигатель горит, вы погибли". Нормальные системы контроллинга работают иначе: "Перегрев в левом двигателе. Отключить? Включить противопожарную систему?" Аналогично система управления проектами должна выявлять события и направлять запросы на выполнение корректирующих действий.
  • Отсутствие поддержки планирования ресурсов сверху-вниз. В классическом подходе ресурсное планирование обычно идет "снизу-вверх". В реальной практике большинства компаний это только уточняющее действие. Обычно ресурсы выделяются сверху и оцениваются методом параметризированного аналога или рыночной цены. Интересно, что многие классические системы имеют только "базовый план" с несколькими вариантами хранения, но в принципе не поддерживают понятия бюджетного плана, который работает иначе и структурно несовпадает с проектом (об этом расскажем далее).

Что именно переполнило чашу терпения Boeing оставим на их усмотрение. Однако перечисленные проблемы являются неизбежными пороками классических методологических моделей прошлого. Вопрос только в степени критичности проблем в конкретном случае.

Если внимательно посмотреть на список пороков классической модели, то можно заменить, что почти везде видна потребность в согласованиях. Это ставить вопрос о гибридном решении, где недостатки "классики" исправлены через интегрированную систему согласований (workflow).

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

 

Управление портфелем проектов через методологию "контрольных точек"

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

То что Boeing и General Motors оказались в первых рядах внедривших новую методологию нисколько не удивительно. Дело в том, что новая методология во многом заслуга машиностроителей, автопрома, судостроителей, приборостроения и других компаниях создающих высокотехнологичное оборудование или системы. За десятки лет успешных проектов машиностроители пришли к разработке методик построенных не столько на WBS, сколько на контроллинге прохождения контрольных точек. Кроме управления графиками это методология интегрирована с моделью качества ISO в виде известных "ворот качества". Методологию новой назвать нельзя, ей десятки лет и фактически вся история машиностроения подтверждает ее эффективность. Просто данная методология сложнее классики в том плане, что сразу требует интеграцию с моделью согласований. Долгое время системы управления проектами были не настолько совершенны и технологичны, чтобы полноценно поддерживать такие методологии.

Как в случае "классики" модель универсальна и не привязана к какой-то отрасли. Например, тот же Boeing один из крупнейших промышленных строителей, а комплекс небоскребов который построил General Motors проект доступный далеко не каждому заказчику строительства. Boeing создает сложнешие IT-системы для управления и навигации по категории "life critical". General Motors строит сложнейший холдинговый портфель по управлению дочерне-зависимым компаниями опускаясь до уровня полного контроля их активов. Как видим, новая модель универсальна и оптимальна везде где нужно координировать работу нескольких подразделений и/или согласование изменений носит ключевой характер.

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

MS Project 2010
Примерно такие картинки стали сопровождать последние крупные тендеры и в России

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

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

  • Соответствие модели качества ISO. Действительно, сама технология контрольных точек позволяет их использовать как "ворота качества" или как промежуточные результаты с контроле и согласовании.
  • Встроенной методология актуализации планов и обеспечения надежности информации. В отличии от классической модели модель на контрольных точках не может жить без постоянной актуализации и перепланирования, поэтому без конца между уровнями управления курсируют процессы согласования изменений. Сама методология побуждает менеджеров приводить планы в порядок и их согласовывать после воздействия рисков. Отработка такой итерации делает планы гарантированно актуальными, т.к. новое состояние проходит обязательную процедуру утверждения по ключевым пунктам.
  • Есть "история вопроса". Поскольку к механизмам согласования легко добавляется журнал с историей запросов на изменение, то из системы легко построить отчеты поясняющие почему так или иная контрольная точка сдвинулась или потребовалось больше ресурсов.
  • Произвольная консолидация без ломки исторически сложившихся планов. Если посмотреть на схему консолидации по контрольным точкам, можно сделать любопытное открытие, что часто муки построения огромных WBS-подобных справочников были лишними. Контрольные точки могут объединятся и группироваться как угодно, поэтому нет необходимости тратиться на безумного дорогой консалтинг и организационные изменения в этой части.
  • Изменения согласуются. Модель на контрольных точках хороша тем, что в отличии от классики не дает менеджерам нижнего звена влиять своими правками на планы верхних уровней без процедуры согласования.
  • Согласованные изменения при пересчете по связям. Часть контрольных точек является "интеграционными", т.е. используется для создания связей и расчета комплексного расписания. Важно что в модель расчета расписания как неотъемлемая часть входит согласование, сдвиги по связям между подразделениями согласуются, поэтому такое расписание надежно.
  • "Китайская стена" в информационной безопасности. Разработчики MS Project часто называют систему на  контрольных точках "китайской стеной" в плане информационной безопасности. Действительно, контрольные точки по методологической модели не обязаны быть носителем информации о структурах планов верхних или смежных уровней. Поэтому достигается почти идеальная информационная изоляция планов на различных уровнях управления. Даже при случайной ошибке администрирования как правило не получится что-то
  • Высокий уровень контроля за рисками: запросы на  принятие решений. Методология контрольных точек подразумевает автоматическую идентификацию риска достаточного, чтобы повлиять на важные показатели проекта и необходимость запуска автоматических запросов предлагающих оказать корректирующие воздействие. Сама система может только автоматически запросить недостающее время и ресурсны, но конечно откуда их взять система сказать сама не может, однако может автоматически поставить вопрос требуя его так или иначе решить. Это автоматически вовлекает менеджеров вышестоящих менеджеров в решение проблем неразрешимых на нижнем уровне давая достаточное время для принятия решения.
  • Интеграция с методологией планирования ресурсов сверху-вниз. Если к контрольным точкам добавить кроме сроков еще ресурсные параметры, тогда довольно просто можно построить систему ресурсного планирования сверху-вниз. Причем будет поддерживаться бюджетная структура распределения ресурсов, а не только WBS. Кроме этого будет поддерживаться согласование выделения ресурсов в том числе с обоснованием на запрос ресурсов от модели снизу-вверх .

И что самое интересное, вроде бы куда более технологичная чем классика методология контрольных точек с согласованиями содержит в себе решение критических ограничений технологий Microsoft Project. Этот удивительный факт мы сейчас рассмотрим.

Как методология контрольных точек превратила ограничения MS Project в преимущества

История Microsoft Project начиналась с господства в настольных решениях без серверных технологий. Чтобы сохранить наработки и обеспечить совместимость Microsoft переходя к серверным технологиям MS Project Server был вынужден сохранить преемственность модели данных.

Технологически MS Project Server по-сути манипулирует с проектом почти как с файлом производя большую часть расчетов на клиенте и загружая результаты в сервер. Предыдущие версии MS Project Server могли только вести расчеты для отчетов. Начиная с MS Project Server 2010 возможен и серверный расчет расписаний, однако корни исходной технологии "работай как с файлом" сохраняются.

Именно отсюда и идут истоки известных проблем MS Project как ограничение на совместное редактирование проекта несколькими пользователями или проблемы производительности/надежности при работе с большими структурами работ (WBS).

Технологически "классический" сценарий реализуется через систему мастер-проектов, однако без специальных дополнительных компонент манипулировать таким механизмом сложно. Также могут возникнуть и проблемы надежности технологии Active Cache о которых написано тут. Все это решаемо через решения типа TURBO, которые проведут вас через "минное поле", но все равно "классика" - это не тот сценарий где MS Project может блеснуть подлинной силой. Для классики можно выбирать MS Project исходя из соображений цены, простоты настройки и обучения. Однако как "движок" для огромных многопользовательских WBS продукт конечно имеет ограничения, которые нужно понимать и иметь на внедрении специальные компоненты, чтобы обойти эти проблемы.

Если говорить компонентах для  "классики", я бы отметил, что весьма эффективны решения построенные на Обменных формах Excel, позволяющие подключать множество пользователей для детализации и актуализации задач. В таком варианте гибрид из MS Project и MS Excel может показать не только полное решение проблемы совместного редактирования, но необычно высокую скорость внедрения. Дело в том, что Excel знают все и поэтому обучение требуется равным нулю. Дешевизна решения вообще не требует комментариев. Такие сценарии эффективны и иногда единственный выход если нужно быстро взять проекты под контроль, но врожденные пороки классической модели сохраняются.

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

Почему контрольные точки это оптимальное средство управление портфелем проектов для  технологии MS Project Server?

  • Технология контрольных точек не требует ни в какой момент времени выгрузить на клиентскую машину весь график проекта. Для расчета расписания через согласования это ненужно в принципе. Задача сводится к манипуляции как с файлом с блоком работ обычно до 500 задач, где MS Project в принципе не имеет проблем в любом сценарии.
  • Методология контрольных точек сама побуждает разбивать проекты на блоки работ согласно иерархии менеджеров. Таким образом,  уходит проблема многопользовательского редактирования.
  • Методология контрольных точек не требует от вышестоящих планировщиков или менеджеров для внесения правок открывать на редактирование связанные проекты с выставление блокировки. Изменения приходят через согласование (workflow), поэтому для сквозных перерасчетов не требуется открывать все на редактирование и блокировать многопользовательскую работу.
  • При применении методологии контрольных точек MS Project Server обычно манипулирует большим множеством небольших блоков задач. Собственно на это MS Project Server и оптимизирован.

Интересно, что обходя технологические ограничения в реализации классической модели на "большом WBS" мы получаем технологию куда более масштабируемую, т.к. кроме решения чисто IT-шных проблем архитектуры, мы вписываемся в требования более старших методологий управления проектами требующих интеграции понятия расчета расписания и согласований.

Более 25000 рабочих мест MS Project Server в Boeing и GM показывают парадоксальный факт, что ограничения MS Project Server потребовали внедрять более технологичное решение, что и вывело продукт на следующий уровень как в методологии, так и в технологии.

 

Почему группа разработки MS Project 2010 отказалась признать новые контрольные точки ("конечные результаты") полноценными?

MS Project Server имеет "родной" элемент для манипулирования с контрольными точками. Он называется Deliverables или "конечные результаты". Термин был выбран так потому, что термин контрольная точка уже занят для вех (milestone). Вероятно более хорошее название было бы Управляемая Контрольная Точка (Managed Milestone), но как назвали, так назвали.

В MS Project 2007  "конечные результаты" как и "бюджетные ресурсы" были только полуфабрикатами, чтобы партнеры Microsoft базируясь на них могли строить календарные системы  на контрольных точках или бюджетные системы. Сам пользователь не мог полноценно использовать "конечные результаты" для расчета расписаний. В этой статье описывается как использовать "конечные результаты" в MS Project 2007.

Однако попробовав выполнить такие манипуляции в MS Project 2007 вы быстро заметите, что для расчета расписаний их использовать нельзя. Deliverables двигаются "отдельно" от задач в проекте поэтому через них нельзя строить межпроектные связи для расчета расписаний.

В версии MS Project 2010 группа разработки добавила возможности  по синхронизации конечных результатов с задачами, поэтому возможность даже на коробочной версии MS Project 2010 использование методологии контрольных точек вроде бы "разблокировали". Однако группа разработки Microsoft Project 2010 официально отказалась включить эти новые функции в список важнейших изменений продукта (What's new).

Причина в том, что хотя Boeing, GM и используют контрольные точки Deliverables для управления портфелем проектов, но самими контрольные точками управляют специальные дополнительные компоненты к MS Project, которые кроме простейшей синхронизации с задачами еще должны уметь делать очень  многое: содержать в себе готовы рабочие процессы согласования изменений (workflow), автоматически посылать запросы на изменения, интегрироваться с бюджетными ресурсами, уметь управлять изменениями в финансах и объемах ресурсах, а также многое такое о чем речь пойдет в следующем разделе.

Без полноценного workflow-решения для контрольных точек шансы пользователя Microsoft Project сделать "как в Boeing" стремятся к нулю. В коробке Microsoft Project Server нет готового workflow-решения с готовыми рабочими процессами для этого, а если бы Microsoft и положил его в коробку, то с большой вероятностью оно бы не подошло. Те кто уже пользуются системами на базе рабочих процессов SharePoint понимают, что такие решения очень сильно привязываются к специфике компании.

Теоретически Microsoft мог бы создать конструкторы или настроечные решения для создания системы управления портфелем проектов через контрольные точки, однако даже 40 концернов это слишком мало для Microsoft. Как говорил Билл Гейтс, все что делает Microsoft должно иметь как  минимум миллион пользователей.

Поэтому Microsoft, чтобы не вводить в заблуждение корпоративных клиентов отказался признать новые контрольные точки Microsoft Project 2010 полноценными и не включил новые возможности расчета расписания на них в официальный список What's new.

Как и положено в бизнес-модели SharePoint в Microsoft предоставили партнерам создать такие решения дав им неплохой полуфабрикат в виде Deliverables.

Поскольку слухи от доверенных лиц в корпоративной среде самый мощный маркетинг, то слух о крупнейших в мире внедрениях в Boeing и GM распространился моментально. Что привело к появлению спроса на такие решения.

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

"Сейчас прольется чья-то кровь". Сложности гонки за управляемой контрольной точкой

Точка... Вроде бы всего на всего  обычная веха. Однако как раз дело в том, что нам нужна необычная контрольная точка, а управляющая контрольная точка (managed milestone).

Слово "управляющая" тут все меняет. Это значит, что не просто мертвая точка на графике, а живая "точка с интеллектом", которая очень много что должна уметь, чтобы запустились процессы согласования в портфеле проектов как в Boeing и GM.

Явившаяся на сцену контрольная точка оказалась необычайно "кровожадной", т.к. большое количество клиентов и партнеров Microsoft попробовавшие создать такие решения столкнулись с очень серьезными проблемами. Во многих проектах уже очевидно, что сделанные ошибки завели их в тупик и все придется начать сначала. Однако приз в качестве управления портфелем проектов через модель согласований так велик, что риски не останавливают клиентов и внедрецев. Если Вы не хотите покупать готовые решения по управлению контрольными точками, то стоит знать где расставлены "ловушки".

Четыре главных смертельных ловушки расставленных на пути к  управляемым контрольным точкам:

1) Ловушка для новичков: "обойдусь стандартным MS Project". Непонимание, что Deliverables - это лишь полуфабрикат для решения партнера Microsoft, а не готовое решение. Типичны ошибки новичков, думающих, что на стандартных Deliverables можно собрать управление портфелем проектов. Достаточно даже не пилота, а демонстрации с десятком Deliverables, чтобы убедится, что без партнерских компонент решение нерабочее даже по юзабилити. Хотя бывают менеджеры, которые подписываются на проект внедрения MS Project Server даже не посмотрев демонстрацию механизма и проигнорировав предупреждение из штаб-квартиры Microsoft. В принципе число таких менеджеров сокращается по понятным причинам.

2) Смертельная ловушка "классического решения" SharePoint. "Уход в Web c контрольной точкой - путь камикадзе". Если говорить о том как задумано в Microsoft, то тут есть ловушка в которую большинство и попадается. Поскольку контрольная точка в MS Project Server - это объект SharePoint  первое что приходит в голову сделать обычное и традиционное решение просто создав рабочие процессы SharePoint и далее развивать Deliverables через Web-интерфейс Project Web Access. Это ловушка. В первых прототипах мы попробовали так сделать даже применив Nintex для ускоренного создания workflow. Быстро стало понятно, что это тупик. Даже сами эксперты Microsoft в MS Project 2010 развивали Deliverables через толстый клиент Microsoft Project Professional добавляя в него новые синхронизации с расписанием, а не через развитие Project Web Access. Уже несколько проектов внедрения попали в проблемы из-за того, что дали порулить архитекторам SharePoint в проектировании решения и контрольные точки навсегда потеряли свою интеграцию с графиками работ MS Project. Попытка сделать контрольные точки только как изолированные Web-объекты SharePoint обречена на крах, т.к. контрольная точка отрывается от механизма расчета расписания, которое возможно только в Microsoft Project Professional. Поскольку разработчикам в Project Web Access принципиально недоступны механизмы расчета расписания и потребления ресурсов такие как в Microsoft Project Professional, то нужно понять, что это полный тупик и никаких шансов восстановить нужную степень интеграции с проектами MS Project не существует даже теоретически. Если вы так сделали, все выбрасывайте и начинайте сначала.

3) Смертельные ловушки интерфейса пользователя (юзабилити).  Надо понимать, что управляемые контрольные точки не мертвые статисты как обычных системах управления проектами, а живые объекты постоянно находящиеся в большой динамике. Если вы не попались в ловушку "классики" SharePoint и смогли построить управление расписанием на контрольных точках, то сразу заметите, какой огромный поток изменений сопровождает жизнь контрольных точек, ведь если изменилась одна контрольная точка, сразу же это влечет изменение связанных контрольных точек. Классическое приложение SharePoint как правило построенное на "заявках" на изменение тут не подходит, т.к. трудоемкость заполнения и проверки данных становится так велика, что просто блокирует работу пользователей. Система должна автоматически генерировать по проектным связям все нужные запросы, обслуживать запросы пользователю сразу "одним пакетом", уметь показывать на Ганте как повлияет приемка точек и т.д. Словом тут нужен специальный интерфейс пользователя и очень высокая автоматизация убирающая лишние клики и лишнюю ручную работу. В это классе решений это не прихоть, а условие его работоспособности.

4) Смертельная ловушка "чудовищной трудоемкости" разработки проектных систем с интегрированным согласованием. Многие кто не имеют опыта создания проектных систем с интегрированными рабочими процессами согласования попадают действительно в смертельную ловушку чудовищной трудоемкости разработок. Глубоко ошибочна оценка, что сделать процессы согласования причем с интеграцией в расписания также просто как настроить представления в Project Server. Системы на рабочих процессах сами по себе очень сложно разрабатываются и тестируются. Как правило даже бюджет в $300 000 долларов довольно миниатюрно смотрится по сравнению себестоимостью разработки таких решений. О том что время на создание подобных решений около 2х лет неприемлемо самом по себе говорить не требуется. Очевидно, что большинство внедрений не могут вынести такие затраты и сроки, поэтому нужны серийные и готовы решения. Корпоративным клиентам создавать самим такие решения невыгодно, это дело инвестиций партнеров Microsoft

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

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

Коварная контрольная точка требует решений партнеров Microsoft

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

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

MS Project 2010
Контрольная точка проста только для пользователя. За кулисами сложнейший механизм согласований

Ниже приведена сравнительная таблица возможности стандартных точек-полуфабрикатов и возможности готового решения на примере Turbo Project Sever. Как видим требуется весьма много функционала.

Критерий Стандартные "Конечные результаты" (Deliverables) Возможности сервера контрольных точек Turbo Project Server
Общие    
Возможность использования для расчета расписаний в MS Project 2007 Нет Да
Возможность использования для расчета расписаний в MS Project 2010 Да (только через ручные синхронизации) Да (через полностью автоматические синхронизации)
Использование элемента SharePoint Deliverables с возможностью создать свой workflow (процесс согласования) Да, но готовых workflow нет, как и интерфейса для них Да, есть возможность подключиться в контекст процесса готовых процессов согласования
Скоростная пакетная обработка контрольных точек с опцией  без создания отдельных Deliverables Нет, поэтому MS Project Server на бюджетном серверном оборудовании ограничен порядка 100-200 контрольных точек Манипулирование даже тысячами контрольных точек на бюджетном оборудовании за счет опций отключающих создание хранения документом SharePoint там где это не требуются
Открытый код для доработок Нет, код интерфейса закрыт Серверная часть Open Source, поэтому может дорабатываться и сопровождаться независимыми разработчиками
Юзабилити (удобство пользователя)    
Количество кликов для принятия обновления состояния контрольной точки в план Порядка 8 кликов на каждую точку
(открыть меню, принять новые состояния, обновить план, синхронизировать)
1-3 клика на все изменённые точки  разом
Конструируемые фильтры для привязки контрольных точек по выбору Нет Да
Быстрые переходы в связанные с контрольной точкой проекты Нет Да
Графические индикаторы состояния процесса согласования Нет, пользователь дезориентирован, т.к. не знает состояние согласования контрольной точки Да, настраивается пользователем
Готовые процессы согласований (workflow)    
Назначение контрольной точки исполнителю Нет,
ручной поиск точек без возможности применять фильтры
Да
Согласование изменения контрольной точки Согласование заменяет "синхронизация", если не согласен - не синхронизируй Да
Согласование изменений ресурсов Нет Да
Поддержка интеграции процессов планирования сроков и бюджетирования Нет Да
Согласование изменений физических объемов Нет Да
Процесс приемки результатов Нет и как следствие нет передачи сигнала и статуса исполнения между уровнями Да
Протоколирование действий по контрольным точкам    
Ведение протокола с фиксацией времени и автора изменений Да Да
Фиксация что именно изменилось Нет, только "изменено" и все Да
Возможность комментировать изменения. Документация "переписки" по согласованию Нет Да
Отображение графическими индикаторами важных событий в журнале Нет Да
Выгрузка журнала в Excel для анализа Нет Да
Финансовое моделирование в привязке к контрольным точкам    
Интеграция с бюджетными ресурсами MS Project Нет Да
Управление несколькими источниками финансирования проекта Нет Да
Автоматически запросы на увеличение финансирования с выбором нагрузки на источники Нет Да
Ресурсное моделирование в привязке к контрольным точкам    
Возможность использования физического объема для нормирования ресурсов методом параметризированного аналога Нет Да
Передача с контрольной точкой физического объема и ресурсов в виде предельных человеко-часов (Time Bank) Нет Да
Автоматические запросы на увеличение ресурсов в человеко-часах Нет Да
Применение поправочных коэффициентов для оценки трудозатрат методом аналога Нет Да
Интеграция с полями и справочниками пользователя    
Интеграция контрольной точки с настраиваемыми полями (custom fields) MS Project Нет Да
Поддержка рабочих процессов согласования по полям пользователя Нет Да

 

Как победить "ужасающую трудоемкость" внедрения MS Project Server c использованием технологий SharePoint?

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

Первые пилоты MS Project Server 2010 в интеграции с решениями на базе MS SharePoint 2010 довольно часто просто шокируют клиентов Microsoft "ужасающей трудоемкостью" их создания.

Стратегия Microsoft Project 2010 это максимальное использование и интеграция с технологиями MS SharePoint Server 2010. Поэтому такие заявления о невероятной трудоемкости создания подобных гибридных решений вроде бы проблема.

На самом деле в этом нет проблемы. Какие-то решения в SharePoint всегда создавались весьма просто различными конструкторами. Однако более-менее сложные решения всегда были партнерскими компонентами коих множество.

Если перед вами задача создать реальную систему управления согласования на контрольных точках, то это большая проблема если нет на рынке уже готового решения. Однако оно уже есть - Turbo Project Server.

Модель бизнеса SharePoint проникает в Microsoft Project 2010 и меняет правила экосистемы внедрения продукта

Если обобщить, то нужно понимать, что правила бизнеса SharePoint в корне отличаются от предыдущей модели бизнеса Microsoft Project. Делая MS Project 2010 органичной частью платформы SharePoint в Microsoft меняют "правила игры".

Ранее MS Project Server можно было внедрить просто "покрутив" настройки пользовательских полей и сделав регламент по шаблону. Это время уходит, т.к. такой подход подразумевал, что MS Project Server это готовое и самодостаточное решение.

SharePoint - это только платформа. Готовых решений в нет и быть не может, т.к. бизнес SharePoint строится как по модели 1С, когда для платформы производится огромное множество партнерских решений на все вкусы пользователей.

Решения нового поколения строятся именно на партнерской модели Microsoft и готовых решениях партнеров. Вроде бы "кошмарные бюджеты" разработки для нового класса компонент не влезающие в бюджеты внедрений корпоративных клиентов должны оставить и партнеров Microsoft. Однако все ровно наоборот, именно принципиальная невыгодность для корпоративного клиента создавать такие решения самому стимулирует партнеров Microsoft начинать бурные инвестиции в серийные решения на которые именно непроходимый для клиентов барьер сложности и создает спрос. Корпоратив будет отказываться от "заказных" решений и переходить на готовые решения, т.к. цена и время создания заказных решений "SharePoint + Project" становится запредельной.

Серийность готовых решений от партнеров Microsoft для MS Project и SharePoint делает стоимость отдельных лицензий просто мизерной, а время доступности решения становится равным почти нулю, т.к. оно уже готовое.

Компонент-сателлитов MS Project и сейчас немало, однако принципиальная разница теперь в том, что для нового уровня теми или иными компонентами придется воспользоваться почти всем, кто хочет не просто использовать MS Project как продвинутую программу Paint для рисования диаграммы Ганта, а хочет решение "как в Boeing".

Время начинать изучать рынок готовых отраслевых компонент для MS Project. Если есть потребность консолидации портфеля проектов через методологию управляемых контрольных точек, можно связаться с нами.

www.TurboProject.ru

 

Расскажите о статье в Facebook и Twitter. Если статья понравилась, поставьте нам "плюс" Google.

Вы не вошли под своим пользователем на ProjectProfy.ru.
Рекомендуется нажать "Закрыть" и зарегистрироваться на сайте.
Зарегистрированные пользователи, выступающие как редакторы,
имеют различные бонусы по доступу к закрытым материалам.
Если Вам не важны бонусы, можете отправить правку прямо сейчас.

Фрагмент, требующий улучшения
Ваша версия фрагмента. Отредактируйте текст
Степень серьезности проблемы
Проблемы содержания
Стилистические проблемы
Синтаксические и орфографические проблемы
Ваш комментарий:

Если вы заметили любую ошибку в статье, вы можете сообщить об этой ошибке редакторам сайта, выделив мышью отрывок текста с ошибкой и нажав Ctrl+Enter. Ваша помощь в улучшении материалов для нас неоценима!

© 2003-2011, Портал ProjectProfy.ru. Все права защищены.

E-mail: обратная связь