Как организовать и провести IT-тендер

Как организовать и провести IT-тендер

Анастасия Акимова Менеджер, Калининград

Тендеры на IT-рынке практикуют не только корпорации. Маленькие компании кроме этого покупают ПО посредством конкурсов. Анастасия Акимова поведает об главных моментах, на каковые стоит обратить внимание при выборе поставщика.

Анастасия Акимова

Вы решили автоматизировать бизнес-процессы. Что делать дальше? Совершить тендер. Учтите — проведение и организация тендера потребует внимания главных руководства и сотрудников компании.

Но это единственный метод для адекватного выбора.

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

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

Подготовка к тендеру

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

В зависимости от специфики компании, остальными участниками команды будут IT-эксперты, sales-support, бизнес-аналитики.

Два показателя грамотно организованной проектной команды:

  • Совокупная компетентность достаточна для оценки обстановки со всех точек зрения, ответственных для бизнеса;
  • Проект приоритетен для участников команды.

2) Первичное техническое задание. Бизнес именует требования, а технический эксперт, sales-support либо человек на стыке бизнеса и IT переводит их на формальный язык. Так вырабатывается начальное представление о том, какая совокупность нужна.

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

Хорошего поставщика реализовывают клиенты. Исходя из этого его такие опросы не «напрягут», кроме того если он о них определит.

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

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

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

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

Причем без углубления в подробности — время для изучения еще не пришло.

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

6) Не делайте предварительных оценок. Бывают случаи, в то время, когда в компании цена проекта согласовывается на подготовительном этапе, без обращения к поставщику. Риск в том, что эта сумма может существенно различаться в меньшую сторону от стоимостей, названных разработчиками в тендере. И тогда цена делается единственным критерием выбора — бюджет-то уже согласован. В сфере IT недорогое хорошим быть не имеет возможности. Дабы вследствие этого не появлялось сложностей, необходимо осознать, что цену именует рынок, а не клиент.

Исходя из этого за порядком цифр лучше обратиться к разработчикам.

Итак, в перечне остались специализированные фирмы.

Тендер

1) Техническое задание (ТЗ). В IT лучше, в то время, когда абстрактное представление о программе подкреплено формализованным документом. Он экономит время и поставщику, и клиенту. Сформулируйте бизнес-требования и переведите их на технический язык.

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

2) Пора обратиться к поставщикам. Проектная команда приступает к проверке функциональности программ. Напишите официальный бриф, позвоните, пошлите запрос через форму обратной связи на сайте — любой канал связи годится. Основное — довести до разработчиков техническое задание и задать вопрос: «Мы ищем вот такое ответ.

Что вы имеете возможность нам предложить? Какие конкретно статьи затрат смогут быть? какое количество стоит таковой проект?».

3) Приглашение в тендер. какое количество поставщиков пригласить в тендер? Все зависит от желания управления компании-клиента отыскать объективно лучшее и подходящее IT-ответ.

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

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

4) Сроки. Хотя бы к моменту формирования шорт-страницы запланируйте, сколько времени компания израсходует на отбор и в то время, когда запустит проект. При не хорошо организованном вялотекущем ходе без сроков клиент не осознаёт, сколько ресурсов потребуется положить в проект, в то время, когда он запустится. Приблизительно укажите, в то время, когда ожидаете взять итог: «5-10 дней на первичную обработку», «14-20 дней на ответ по ТЗ». Для запуска проекта подойдет и приблизительное «Мы желаем запуститься в текущем году». Тогда поставщик включит проект в график.

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

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

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

5) Заявки в тендер «самотеком». В случае если клиент забыл кого-то пригласить, а поставщик сам определил о тендере, то он может «попроситься» в него самостоятельно. При таких условиях заявку оценивают по неспециализированной схеме «подходит — не подходит», и в случае если первичный отбор удачно пройден, высылают техническое задание.

6) Сопоставление потребностей компании и возможностей решений проводится в диалоге с поставщиком. Значит, на стороне клиента должны быть компетентные представители, готовые обсуждать функционал программы. На этом этапе будут очные встречи, видео- и телеконференции. По результатам переговоров из перечня уберутся «лишние».

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

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

7) Внимание на отношение. Тендер похож на сватовство. Кроме оценки характеристик ответа, обращайте внимание на общение с поставщиком.

Он бывает молодым и неопытным в тендерах, но открыт к беседе. Не бывает «неудобных» либо «глупых» вопросов на тему характеристик и функциональности совокупности, поскольку у разработчика намного больше компетенций и знаний в собственной области, чем у IT-директора компании-клиента.

В случае если поставщик дружески растолковывает и говорит, с ним окажется трудиться как с партнером и дальше. Так как проект продолжается несколько сутки, скорее кроме того несколько год. Коммуникации критично ответственны.

Имеется и другие факторы, каковые стоит оценить: организованность, полнота предоставления информации.

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

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

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

Реклама – это реклама. На слайдах легко нарисовать что угодно. Включая скриншоты, отредактированные в Photoshop.

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

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

Принципиально важно суметь привести их к единому знаменателю.

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

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

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

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

Финишная прямая

Проведение «пилотов» (пробных проектов) — прекрасный шанс проверить поставщиков в сражении. Это необходимо для определения фаворита, если он не проявился по результатам рассмотрения коммерческих предложений. И в случае если выбор основывался на прекрасной презентации, «пилот» продемонстрирует, соответствуют ли обещания действительности.

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

Сравнительно не так давно мы принимали участие в тендере, где проводилось семь параллельных «пилотных» внедрений.

Выбрали? Станет несложнее

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

А также он несёт ответственность за сбор и бюджет дополнительных требований.

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

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

P.S. За помощь в подготовке статьи благодарю PR-менеджера ГК «Системные Разработки» Татьяну Беспалову.

Источник изображения: dreamstime.com

Редактор рубрики «IT для бизнеса» – Сергей Соловьев

True — Hold It Back


К прочтению:

самые интересные статьи, подобранные как раз для Вас:

spacer