Проблемы выбора корпоративного программного обеспечения: технический документ

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

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

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

Проблемы выбора корпоративного программного обеспечения

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

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

Наиболее распространенный способ выбора корпоративного ПО

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

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

Типичный процесс выбора корпоративного ПО выглядит примерно так:

  1. Принятие руководством решения о том, что компании нужна новая корпоративная система

  2. Назначение руководителя проекта

  3. Получение запросов от всех задействованных подразделений

  4. Объединение всех запросов в одну большую электронную таблицу

  5. Отправка перечня требований множеству поставщиков

  6. Получение множества ответов

  7. Составление короткого списка поставщиков

  8. Просмотр демонстраций

  9. Переговоры

  10. Получение согласия руководства

  11. Выбор руководством какого-либо другого решения

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

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

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

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

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

Фрагмент листа с выбором функций

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

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

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

Причины неэффективности такого способа выбора корпоративного ПО

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

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

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

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

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

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

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

Эксперимент или пилотное развертывание

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

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

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

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

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

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

Неэффективный выбор пилотного этапа

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

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

Выбор эффективного пилотного этапа

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

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

Рекомендации по выбору корпоративного программного обеспечения

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

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

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

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

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

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

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

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

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

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

  2. Какое влияние это решение оказало на ваши бизнес-процессы?

  3. Какой аспект развертывания был наиболее сложным?

  4. В чем наиболее явно проявилась рентабельность инвестиций?

  5. Как вы видите дальнейшее развитие решения?

Не рассчитывайте только на восторженные ответы.

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

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

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

Правильный выбор корпоративной системы — это только первый этап процесса.

Об авторе

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

×