Почему проект тормозит, когда подрядчиков много

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

Типичная ситуация выглядит просто. Оборудование уже на объекте, но внедрение не начинается: не готовы ключи активации, не подтверждена конфигурация, не выданы доступы. Формально проект идет. По факту - стоит.

Особенно часто задержки начинаются, когда:

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

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

Сильнее всего это заметно в проектах для госорганов, школ, клиник и крупных компаний, где приемка формализована. Один подрядчик говорит: "мы поставили". Второй отвечает: "мы начнем после подписания этапа". Третий ждет закрытия предыдущих работ. Крупной технической проблемы может и не быть, но сроки все равно растут.

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

Когда один контракт действительно удобнее

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

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

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

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

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

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

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

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

Когда лоты лучше разделить

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

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

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

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

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

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

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

Как принять решение по шагам

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

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

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

Дальше достаточно ответить на несколько простых вопросов:

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

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

Что нужно прописать заранее

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

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

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

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

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

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

Простой пример из практики

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

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

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

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

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

Частые ошибки при объединении проекта

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

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

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

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

Чаще всего ошибки выглядят так:

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

Быстрая проверка перед стартом

Перед подписанием договора полезно провести короткую проверку. Она быстро показывает, готов ли проект к запуску или в нем уже заложены будущие задержки.

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

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

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

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

Что делать дальше

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

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

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

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