Бэтфон: технический документ

Заголовок этой статьи — отсылка на название телефона, которым комиссар полиции Гордон (персонаж из телесериала "Бэтмен" 70-х гг. прошлого века) прибегал всякий раз, когда город Готэм оказывался в отчаянном положении.

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

Чтобы загрузить этот технический документ в формате Word, воспользуйтесь ссылкой Бэтфон.

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

Бэтфон

Оригинальный телесериал "Бэтмен" вышел на экраны в 1966 г. В нем было всего 120 серий, но его влияние на культуру ощущается и по сей день. В мире Бэтмена и Робина (роли которых исполнили Адам Уэст и Берт Уорд) на все случаи жизни были вещи, названия которых начинались с приставки "бэт-". Какие бы трудности ни возникали, у Бэтмена всегда было решение: бэтмобиль, бэтлодка, бэтаплан и бэтпещера — всему находилось свое применение. Но если вы попадали в беду, то как можно было связаться с Бэтменом? Конечно же, с помощью бэтфона! Позвоните по бэтфону, и помощь прибудет в ближайшее время.

Изображение красного телефона Бэтмена

Комиссар полиции Гордон пользовался бэтфоном, когда положение становилось безнадежным, что, естественно, случалось в каждой серии. Какой бы серьезной ни была проблема, один звонок по бэтфону — и через 22 минуты (плюс время на рекламу) злодей будет повержен и в город Готэм вернутся мир и спокойствие.

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

Какое ностальгическое чувство ни вызывали бы у нас воспоминания о телефонах с дисковым набором и старых сериях "Бэтмена", сегодняшняя статья посвящена другому. Вот уже 40 лет, как бэтфон отключен, но люди каждый день звонят консультантам по системам для управления корпоративными проектами (Enterprise Project Management, или EPM) в надежде на то, что он сработает еще хоть один раз.

Злодеи в каждом случае разные. Иногда это технические проблемы: необходимо выполнить обновление с версии x до версии y. В других случаях — архитектурные: требуется сделать внутреннюю систему EPM доступной для пользователей вне организации. Часть проблем лежит в плоскости культуры: пользователи отказываются работать с системой. Наконец, некоторые проблемы связаны с процедурами: процесс, которого придерживается организация, не дает ожидаемых результатов.

Какой бы ни была проблема, вопрос всегда один: можете ли вы исправить положение за 22 минуты?

Удивительно, как много пользователей систем EPM попадают в такую ситуацию, для выхода из которой им срочно требуется помощь. Очень часто положение действительно критическое, и решение должно было быть принято еще вчера. Люди, от которых поступают такие звонки (я лично получаю несколько каждую неделю), далеко не глупы. Это разумные, способные и состоявшиеся руководители.

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

Причины возникновения проблем

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

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

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

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

  • Создание нереалистичных календарных планов   . Никто не хочет, чтобы развертывание решения EPM затягивалось надолго. Распространено представление, что такой проект можно завершить за несколько дней или недель, а не за месяцы, как обычно бывает. Типичной проблемой также является то, что ресурсы для такого "внутреннего" проекта, как развертывание решения EPM, выделяются не столь охотно, как для ориентированного на клиентов или коммерческого проекта. По этим и иным причинам требования к ресурсам в календарном плане проекта нередко бывают катастрофически занижены.

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

Каковы были ожидания?

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

  • Ресурсы перегружены   . Возможно, не совсем ясно, на что расходуются ресурсы, но очень часто они оказываются перегруженными. Более сложная проблема возникает тогда, когда оказывается, что часть ресурсов перегружена, а часть имеет неполную нагрузку. Это часто указывает на несоответствие доступных и требуемых навыков и опыта.

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

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

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

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

Как избежать проблем?

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

Прежде всего, все, что было перечислено в первом разделе:

  • правильно оцените масштаб задачи;

  • не относитесь к развертыванию EPM как к техническому проекту;

  • с самого начала привлеките к проекту высшее руководство;

  • составьте реалистичный календарный план и проверьте его на основе реальных данных, сравнив с планами других проектов в той же отрасли;

  • создайте календарный план и устав проекта, а также сделайте все остальное, что обычно выполняете для других проектов.

Что еще можно сделать?

В первую очередь, начиная проект, примите во внимание, что когда-нибудь в будущем вам может понадобиться бэтфон. Это так. Зная это, вы можете заложить в бюджет средства на поддержку в экстренных ситуациях. Мы рекомендуем своим клиентам резервировать 10–20 % бюджета проекта на незапланированные потребности. "Зачем это нужно?" — всегда спрашивают нас. "Вы сами сможете ответить нам позднее", — отвечаем мы. Часто эти средства расходуются не полностью. Однако еще чаще расходуется хоть какая-то их часть. Учтя в бюджете расходы на помощь опытных экспертов, вы значительно упростите себе жизнь в дальнейшем.

Изначально будьте готовы к тому, что план и состав участников проекта будут меняться. Моя любимая цитата в отношении управления проектами принадлежит Наполеону Бонапарту, который однажды сказал: "Ни один план сражения не выдерживает встречи с противником". Это верно и в отношении планов внедрения решений EPM. Учитывая, что процесс внедрения, скорее всего, продлится несколько месяцев, вероятность того, что за это время изменится состав рабочей группы, крайне высока. Поэтому заложите в план избыточность.

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

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

Ведите документацию

Одна из наиболее распространенных и легкоустранимых проблем — недостаточно полная документация. Значение документации легко недооценить, но при ее наличии можно, вместо того чтобы искать бэтфон, просто свериться с зафиксированными данными. Кроме того, недостаточно просто составить документ и спрятать его в ящик письменного стола. Документы должны стать частью непрерывного процесса регистрации, и от них можно отталкиваться при проведении регулярного пересмотра развертывания EPM. Вот некоторые документы, касающиеся среды EPM, которые, на мой взгляд, наиболее важны:

  • Экономическое обоснование   . Я не знаю, почему экономическое обоснование кажется многим людям таким малоинтересным, но очень часто о нем забывают, а ведь именно в нем зафиксированы основные причины, по которым было принято решение развернуть среду EPM. В экономическом обосновании указаны предполагаемые преимущества для организации, т. е. ее ожидания от внедрения системы EPM. Когда нам звонят по бэтфону, одним из первых мы задаем такой вопрос: "Каких возможностей вы ожидаете от системы?" Мы спрашиваем это не только у администратора, но и у руководства, пользователей, бенефициаров. Чаще всего все стороны дают разные ответы. Это связано с тем, что изначальные цели оказались забыты.

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

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

  • Критерии выбора системы   . Выбирая систему EPM, а попутно и какие-либо средства сторонних поставщиков, сообщите будущим поколениям, на чем основывалось ваше решение. Мы посещали организации через 5, 7 или даже 10 лет после развертывания системы, обнаруживали ряд средств, используемых вместе с ней, и спрашивали: "Зачем вы делаете это? Гораздо проще было бы сделать вот так!" Однако причины выбора тех или иных решений установить было невозможно. В некоторых случаях клиент годами выполнял какую-либо задачу крайне усложненным методом, который можно было бы значительно упростить, используя более современные версии существующих средств. Но принять решение о переходе на другое средство или более современную версию нелегко, если уже неизвестно, почему много лет назад был выбран именно такой путь.

Бэтфона действительно не существует.

Когда я произношу это, я чувствую себя так, будто заявляю, что не существует Санта-Клауса и добрых фей. Это грустно осознавать. Но бэтфона действительно не существует. Я уверен, однако, что это не помешает людям звонить мне завтра и просить избавить их от очередного злодея города Готэм. Если вы попали в неприятности и чувствуете, что вам нужно обратиться к эксперту, то следуйте таким рекомендациям:

  1. Прислушивайтесь к советам, которые вам дают. Глупо платить экспертам за советы, а затем решать, что вы лучше знаете, как поступить. Если вы собираетесь попросить совета и имеете дело с экспертом, постарайтесь выслушать его и по крайней мере обдумать услышанное. Бэтмен не стал бы раз за разом являться на призыв комиссара Гордона, если бы тот каждый раз говорил ему: "А теперь, Бэтмен, когда ты здесь, делай то же, что и остальные полицейские".

  2. Бэтмен справился бы с проблемой за 22 минуты, но у вас это вряд ли получится. Если вы обращаетесь к эксперту, пусть он скажет вам, сколько времени уйдет на устранение проблемы. После этого вы можете решить, будете ли этим заниматься, но имейте в виду, что устранение проблем со средой EPM, даже технических, редко занимает несколько минут. В конце концов, Бэтмену приходилось укладываться в 22 минуты, ведь 8 минут было выделено на рекламу, а без нее никак нельзя.

  3. Комиссар Гордон никогда не предлагал Бэтмену решение — он только сообщал о проблеме. Мне часто звонит тот или иной администратор EPM в смятенных чувствах, который точно знает, что мне нужно применить исправление, написать отчет и обучить двух сотрудников. Я всегда терпеливо выслушиваю такие просьбы, а потом прошу клиента описать проблему точно так же, как он только что описал решение. Прежде чем звонить эксперту, подумайте, как лучше изложить проблему, которая у вас возникла.

Заключение

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

Об авторе

Крис Вандерслуис (Chris Vandersluis) — основатель и президент компании HMS Software, расположенной в Монреале, Канада, и являющейся партнером Майкрософт со статусом Microsoft Certified Partner. Он получил степень по экономике в университете Макгилла и имеет более чем 30-летний опыт работы в области автоматизации систем управления проектами. Он много лет является членом Института управления проектами (PMI) и оказывал содействие в основании местных отделений группы Microsoft Project Users Group (MPUG) в Монреале, Торонто и Квебеке. Крис публиковался в таких изданиях, как Fortune, Heavy Construction News, журнал Computing Canada и PMI PMNetwork, а также ведет колонку в Project Times. Он преподает углубленный курс управления проектами в университете Макгилла и часто выступает на специальных мероприятиях ассоциации управления проектами в Северной Америке и по всему миру. Компания HMS Software является разработчиком системы TimeControl, предназначенной для учета рабочего времени в рамках проектов, и с 1995 г. является партнером со статусом Microsoft Project Solution Partner.

Вы можете написать Крису Вандерслуису по следующему адресу электронной почты: chris.vandersluis@hms.ca

Если вы хотите прочитать другие статьи Криса Вандерслуиса, посвященные управлению корпоративными проектами, посетите сайт EPM Guidance компании HMS (http://www.epmguidance.com/?page_id=39).

Совершенствование навыков
Перейти к обучению
Первоочередный доступ к новым возможностям
Присоединиться к программе предварительной оценки Office

Были ли сведения полезными?

Спасибо за ваш отзыв!

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

×