Действия покупателя решений: технический документ

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

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

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

Действия покупателя решений

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

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

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

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

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

Звучит неплохо: целый сонм продавцов, стремящихся упростить вам жизнь. Однако здесь возникает сложная задача, в решении которой вы, как потенциальный клиент, можете принять участие.

Проблема в центре внимания

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

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

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

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

Определение потребности бизнеса

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

Выслушав ответ, я всегда задаю такой дополнительный вопрос: "Работает ли в вашем случае этот метод?" Удивительно, но клиенты часто отвечают утвердительно. По моему мнению, на этом обсуждение должно завершаться. "Если проблемы нет, — объясняю я, — то и предложить решение я не смогу!" Такой ответ часто заставляет людей задуматься. "Почему вы к нам обратились?" — спрашиваю я. Ответы могут быть самыми разными, и нередко бывает, что собеседник осматривается и понимает, что есть более насущные проблемы, требующие решения. В результате наш разговор не занимает и пяти минут!

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

Формирование концепции

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

Вот эффективный способ проведения этого мероприятия: соберите ключевых сотрудников в комнате с большой демонстрационной доской. Разделите доску на четыре столбца и для начала напишите заголовок только в самом правом из них. Назовите его "Деловое решение".

Доска с четырьмя столбцами, включая столбец "Бизнес-решение"

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

Вот некоторые примеры возможных деловых решений:

  • прием на работу и увольнение в определенном отделе;

  • принятие решения о запуске определенного проекта или отказе от него.

Доска со столбцом "Бизнес-решения" и списком бизнес-решений

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

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

Теперь взгляните на каждое деловое решение и спросите себя: "Какой отчет потребуется для его принятия?" Практически каждое решение принимается после изучения одного или нескольких отчетов. Озаглавьте третий столбец "Отчет". Для каждого из трех наиболее важных решений укажите в этом столбце необходимые отчеты.

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

Доска со столбцами отчета и бизнес-решения

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

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

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

Доска со столбцами анализа, отчета и бизнес-решения

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

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

Добавьте заголовок "Входные данные" в первый столбец таблицы.

В используемом нами примере может понадобиться полный список задач для каждого проекта, реализуемого в процессе работы отдела. Это вполне может быть и каждый проект, выполняемый в организации. Нам также потребуются полный профиль доступности каждого ресурса и сведения о рабочей нагрузке, определенной для каждой задачи. Таким образом, если при анализе календарного плана задача переносится, соответствующая рабочая нагрузка переносится при анализе выравнивания загрузки ресурсов. Если вы помните, мы начали с решения о принятии на работу или увольнении сотрудников в определенном отделе. Значит, нам также нужна возможность определять принадлежность ресурсов к отделам.

Доска со столбцами входных данных, анализа, отчета и бизнес-решения

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

Оценка рисков

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

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

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

Документирование результатов

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

Важно задокументировать следующие моменты:

  • записи на доске;

  • участники процесса;

  • сотрудники, ответственные за принятие каждого делового решения.

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

Знание — сила

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

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

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

Об авторе

Крис Вандерслуис (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.

×