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