(+Видео) Как ИТ-проекты выглядят со стороны Заказчика?

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

Как Заказчик ИТ-проекта выбирает подрядчика?

Поиск подрячдика через вендора

Я участвовал в проектах по внедрению CRM-системы для московских банков. И должен сказать, что для них железное правило – обращаться к вендорам (вендоры — это владельцы программных продуктов, Microsoft, Oracle, IBM и т.п.) за советом в выборе подрядчика. Ведь речь идет об огромных рисках, которые измеряются сотнями тысяч или миллионами долларов, и на них нельзя не обращать внимания. Поддержка со стороны вендоров – это верный признак того, что компания проверенная. А присутствие, например, представителя Microsoft, на вашей встрече с подрядчиком будет означать, что вы на пути к выбору действительно опытной и надежной компании.

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

Можно начинать конкурс

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

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

Сообщить подрядчикам бизнес-проблему иницаиции проекта

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

Проверить состав команды от ИТ-партнера

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

Партгнер должен говорить в предложении на языке заказчика

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

Я не люблю, когда коммерческие предложения содержат малопонятные документы, например, «Vision», «Концепция» и пр. Всего однажды на моей практике мы согласились заплатить за такой документ. Помните, что «Концепция» или «Vision» – это документы, которые не несут никакой ценности вашему клиенту.

Я знаю, что многие методологии рекомендуют создание подобных документов, но совершенно не объясняют, как их продать. Возможно, такой документ необходим подрядчику для того, чтобы лучше понимать, что нужно делать. Но если ему что-то непонятно, он всегда может спросить. Ответы на вопросы и для него, и для вас будут бесплатными. Для тех, кто верит стандарты MicrosoftSolutionFramework (MSF) и другие, дам практический совет: в качестве верхнеуровневых документов используйте “Функциональные требования к Системе” и “Календарный график разработки и внедрения”. Эти документы позволяют, не создавая “всяких там концепций”, оценить функциональный объем проекта, перечень итераций или этапов разработки системы. Такие документы несут большую ценность.

Полная стоимость работ с учетом оборудования и лицензий

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

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

Как узнать, что ИТ-подрядчик — надежный?

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

Демонстрация на данных заказчика

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

Обучение команда заказчика

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

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

ИТ-проекты и их структура

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

Система — первый компонент

Первый компонент – это собственно система. Сюда я отношу само программное обеспечение, оборудование, лицензии, средства интеграции новой системы с уже имеющимися программными продуктами в компании. В общем, это программная часть (софт) и оборудование (хард). Все технические задания, описание требований, тестирование и пр. относится к этому компоненту. Иногда сюда же я отношу вопросы технической поддержки после завершения проекта и подписание ServiceLevelAgreement (SLA). Зачастую как заказчики, так и подрядчики, видят в объемах работ проекта только на этот элемент. Но это – только начало.

Данные в системе — второй компонент

Второй компонент – это данные, которые загружаются в систему. Почему-то считается, что программный продукт является самодостаточным, если он соответствует каким-то описанным требованиям. Но программа без данных никому не нужна. И это ваша задача как заказчика своевременно и в полной мере подготовить весь комплекс данных для загрузки в систему. Хорошим примером служит проект по внедрению CRM-решения. Просто «накатить» программный продукт на приобретенные сервера – 30% проекта. Самое «веселье» начинается, когда в справочники начинают поступать данные о клиентах и их контактах, договоры, списки товаров и пр. Данные могут быть некорректной структуры, неполными, храниться в разных форматах и т.п. Привести данные к требуемому виду, сделать очистку, сопоставление (mapping) и пр. – еще та задача, менеджеры-практики это знают. Практически все проекты пробуксовывают на этом компоненте.

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

Дело в том, что не были учтены еще три важных элемента проекта.

Управленческие решения на стороне заказчика — третий компонент

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