Итак, Вы решили автоматизировать бизнес-процессы. Что делать дальше? Провести тендер.
Учтите — организация и проведение тендера потребует пристального внимания ключевых сотрудников и руководства компании. Но это единственный способ адекватного выбора. Преимущества автоматизации только тогда становятся таковыми, когда решение подходит конкретной компании. Тендер помогает детально сравнить функциональные возможности решений, комплекс сопутствующих услуг и стоимость предложений подрядчиков.
Бизнес-образующие IT-системы, о которых идет речь, глубоко встраиваются в процессы компании. По опыту участия в десятках тендеров в роли поставщика IT-решений, рекомендую обратить внимание на несколько моментов, общих для разных целей и ситуаций.
Подготовка к тендеру
Первый шаг — формирование проектной команды для сбора и обработки информации для тендера. Необходимо определить внутреннего заказчика, драйвера проекта. Готовьтесь к тому, что он будет уделять задаче по поиску IT-решения практически все время. В зависимости от специфики компании, остальными членами команды будут IT-специалисты, sales-support, бизнес-аналитики.
Два признака грамотно сформированной проектной команды:
- Совокупная компетентность достаточна для оценки ситуации со всех точек зрения, важных для бизнеса;
- Проект приоритетен для участников команды.
Первичное техническое задание. Бизнес называет требования, а технический специалист, sales-support или человек на стыке бизнеса и IT переводит их на формальный язык. Так вырабатывается начальное представление о том, какая система нужна.
Список разработчиков и названий систем. Для этого IT-специалисты изучают рынок решений. Способы задействуются разные: начиная с поиска в интернете и заканчивая проведением инсайдерских опросов.
Собрать подробную информацию о системах. Самое правильное — обратиться к разработчикам. Начните с просмотра сайтов поставщиков систем, обычно там есть подробная информация о продуктах и контакты. Некоторые разработчики выкладывают демо-версии программ.
На этом этапе отсеиваются поставщики, которые вызывают явные сомнения. Например, настораживает, если у IT-компании не работает сайт или его нет вовсе, если нет портфолио. Кроме того, для крупных заказчиков характерно избегать только что образованных компаний: слишком большие риски.
Первичный отсев систем по классу и базовым возможностям. Не стоит приглашать в тендер всех тех, кто вышел в первую десятку по запросу в Яндексе или Google. IT-эксперты на своем уровне убирают из списка заведомо неподходящих поставщиков. Причем без углубления в детали — время для тщательного изучения еще не пришло
К примеру, открыт тендер для поиска решения для торговых агентов. На рынке присутствуют разработчики, автоматизирующие дистрибуцию, но мобильного приложения для торговых агентов у них нет, есть только офисная часть. В тендере на поставку SFA (Sales Force Automation — система автоматизации продаж) такой поставщик участвовать не может — он непрофильный.
Не делайте предварительных оценок. Бывают случаи, когда в компании стоимость проекта согласовывается на подготовительном этапе, без обращения к поставщику. Риск в том, что эта сумма может значительно отличаться в меньшую сторону от цен, названных разработчиками в тендере. И тогда цена становится единственным критерием выбора — бюджет-то уже согласован. В сфере IT дешевое хорошим быть не может. Чтобы из-за этого не возникало сложностей, нужно понять, что цену называет рынок, а не заказчик. Поэтому за порядком цифр лучше обратиться к разработчикам.
Итак, в списке остались профильные компании.
Тендер
Техническое задание (ТЗ). В IT лучше, когда абстрактное представление о программе подкреплено формализованным документом. Он экономит время и поставщику, и заказчику. Сформулируйте бизнес-требования и переведите их на технический язык. Чтобы ТЗ содержало исчерпывающую информацию, потребуются усилия всей проектной команды.
Когда IT-поставщик получит такой документ, он быстрее и с меньшим количеством вопросов подготовит встречное предложение, легче войдет в тендер.
Пора обратиться к поставщикам. Проектная команда приступает к проверке функциональности программ. Напишите официальный бриф, позвоните, отправьте запрос через форму обратной связи на сайте — любой канал связи годится. Главное — довести до разработчиков техническое задание и спросить: «Мы ищем вот такое решение. Что вы можете нам предложить? Какие статьи расходов могут быть? Сколько стоит такой проект?»
Приглашение в тендер. Сколько поставщиков пригласить в тендер? Все зависит от желания руководства компании-заказчика найти объективно лучшее и подходящее IT-решение. Если проект автоматизации важен, компания пригласит всех, кто в данный момент имеет на рынке хоть какой-то вес.
Если же у компании нет времени или уже принято решение (может быть, негласное), то конкурс проводится формально. В таких фейковых случаях часто приглашают разработчиков заведомо разных направлений либо несопоставимых систем. Среди них оказывается единственный поставщик, который покрывает потребности компании.
Сроки. Хотя бы к моменту формирования шорт-листа запланируйте, сколько времени компания потратит на отбор и когда запустит проект. При плохо организованном вялотекущем процессе без сроков заказчик не понимает, сколько ресурсов потребуется вложить в проект, когда он запустится. Примерно укажите, когда ожидаете получить результат: «5-10 дней на первичную обработку», «14-20 дней на ответ по ТЗ». Для запуска проекта подойдет и приблизительное «Мы хотим запуститься в этом году». Тогда поставщик включит проект в график.
Организация проектных процессов у нормального разработчика похожа на заводские. Он должен четко понимать, на какой срок резервировать человеческие и технологические ресурсы в случае выигрыша. Если вы не обозначаете срок, готовьтесь подождать, пока победитель приступит к работе.
Сроки зависят от потребностей. Если ваши конкуренты уже автоматизировались, IT-системы приносят им прибыль, очевидно, что ждать два года не стоит. Но и торопиться тоже. Не только из-за того, что в спешке легче ошибиться. Нужно выбрать такое время, когда отсутствие ключевых специалистов компании в текущих процессах пройдет безболезненно для бизнеса. Проанализируйте сезонность, ресурсы, инвестиционные возможности. Для этого полезно получить от поставщика грамотный график движения денежных средств, чтобы с учетом этих сведений корректировать сроки и ресурсы.
Заявки «самотеком». Если заказчик забыл кого-то пригласить, а поставщик сам узнал о тендере, то он может «попроситься» в него самостоятельно. В таком случае, заявку оценивают по общей схеме «подходит — не подходит» и если первичный отбор успешно пройден, высылают техническое задание.
Сопоставление возможностей решений и потребностей компании проводится в диалоге с поставщиком. Значит, на стороне заказчика должны быть компетентные представители, готовые обсуждать функционал программы.
На этом этапе будут очные встречи, видео- и телеконференции. По итогам переговоров из списка уберутся «лишние».
Если организатора тендера поджимают сроки, нужно тщательно проработать первичный список участников и возможности рассматриваемых IT-решений. На заявки каждого участников тендера потребуется одинаковое время. Логично потратить его на профильных участников, а не на желающих «попытаться».
Внимание на отношение. Тендер похож на сватовство. Помимо оценки технических характеристик решения, обращайте внимание на общение с поставщиком. Он может быть молодым и неопытным в тендерах, но открыт к разговору. Не бывает «неудобных» или «глупых» вопросов на тему технических характеристик и функциональности системы, ведь у разработчика намного больше знаний и компетенций в своей области, чем у IT-директора компании-заказчика.
Есть и другие факторы, которые стоит оценить: организованность, полнота предоставления информации.
Хорошая презентация — плохая основа для выбора поставщика. Не каждая IT-компания может похвастаться эффектной рекламой. Шикарно, если динамичную презентацию с красивыми картинками показывает человек, специально обучавшийся ораторскому искусству. Но это не показатель качества программы. Это показатель умения компании себя продавать. Поэтому не стоит делать выводы о возможностях поставщика и его месте на рынке, основываясь на маркетинговых материалах.
Реклама это реклама. На слайдах легко нарисовать что угодно. Включая скриншоты, отредактированные в фотошопе. Разработчики, которым сложно выдерживать честную конкуренцию, иногда даже в своих демонстрационных решениях имитируют то, чего еще нет в действующем программном обеспечении.
Вот когда собрали хорошие референсы, наладили коммуникации, оценили систему, и появилось видение поставщика как будущего партнера — тогда презентация становится «вишенкой на торте». Но такой презентации может и не быть вовсе, по существу ничего не изменится.
Коммерческое предложение — еще не финал, а интересный этап. Уже накопили много знаний о системах и разработчиках, теперь настал момент оценки предложений. Сложность в том, что каждая компания, предоставляющая некие цифры в ответ на запросы, вкладывает в них разное значение. Важно суметь привести их к единому знаменателю.
Например, практически в каждом проекте присутствует статья о технической поддержке. Но цифры, предоставляемые поставщиками, различаются в разы. Почему? Возможны два варианта. Первый — неоправданно дорогой поставщик. В таком случае сориентироваться поможет информация о предполагаемом сервисе и о ставках специалистов.
Второй вариант — у одного поставщика учитываются траты, которые не включил другой. Например, в SFA-проектах одни разработчики предлагают выезд специалистов по внедрению на площадку, а другие — нет.
Обычно после углубленного анализа функциональных возможностей, описаний сервисов и перспектив развития систем остаются один-два лидера, с которыми продолжаются переговоры по коммерческим условиям.
Финишная прямая
Проведение «пилотов» (пробных проектов) — великолепный шанс проверить поставщиков в бою. Это нужно для определения лидера, если он не проявился по итогам рассмотрения коммерческих предложений. И если выбор основывался на красивой презентации, «пилот» покажет, соответствуют ли обещания реальности.
Проектная команда будет несколько месяцев заниматься трудоемкой работой и уделять проектам большую часть времени. Особенно затратны параллельные «пилоты». Недавно мы участвовали в тендере, где проводилось 7 параллельных «пилотных» внедрений.
Выбрали? Станет проще. Теперь над проектом работают другие люди под руководством технического руководителя. Как правило, у руля становится IT-директор, ему передаются требования заказчиков внутри компании и делегируются необходимые полномочия. Руководитель проекта внедрения занимается организационными моментами, коммуникациями, контролем. В том числе, он отвечает за бюджет и сбор дополнительных требований.
Помогает, когда проекту присваивается статус приоритетного для компании. Это гарантирует оперативную обратную связь подразделений, обеспечивает доступ к ТОПам, если вопросы выходят за рамки полномочий оперативного руководителя, и создает продуктивный настрой на успешное завершение проекта.
Все перечисленное возможно только в том случае, когда проектная команда фокусируется на проведении тендера. Это важно, поскольку выбирается партнер по бизнесу, от работы которого зависит успех компании.
