«Решили передать часть работы интегратору и уже мысленно сэкономили время и нервы? В реальности интеграция может превратиться в многомесячный конфликт интересов, где главный результат — исчерпанный бюджет и взаимные претензии. Большинство этих проблем прогнозируемы и вызваны фундаментальными ошибками в подходе со стороны заказчика. Ошибки начинаются не на этапе подписания актов, а за месяцы до них, в самой логике выбора, планирования и формулирования задач.»
Ошибки на старте: неверные ожидания
Первая группа ошибок закладывается ещё до встречи с интегратором, на этапе формирования внутренних ожиданий и представлений о процессе.
1. Искать не партнёра, а исполнителя
Основное заблуждение — воспринимать интегратора как подрядчика, который просто «втыкает» готовое решение. В реальности он становится партнёром, от понимания которого зависит архитектура всей системы. Если заказчик приходит с установкой «я плачу — ты делаешь», он заранее ограничивает интегратора в возможности предложить оптимальное, а не самое простое решение. Такой подход превращает проект в последовательность утверждённых чек-листов, где нет места гибкости и адаптации к реальным процессам.
2. Верить в «коробочное» решение для сложной задачи
Многие ожидают, что интегратор привезёт продукт, который «из коробки» закроет все потребности бизнеса. Для стандартизированных задач это работает. Для интеграции со сложными внутренними системами, унаследованными (legacy) базами данных или специфичными бизнес-процессами — нет. Реальная работа всегда включает настройку, доработку и адаптацию. Непонимание этого приводит к резкому удорожанию проекта на этапе, когда отступать уже поздно.
3. Не иметь внутреннего видения
«Сделайте нам как у всех» или «сделайте современно и безопасно» — не техническое задание. Неспособность сформулировать чёткие бизнес-цели, переведённые в конкретные требования, передаёт ответственность за проектирование системы интегратору. Он, руководствуясь своими коммерческими интересами или стандартными шаблонами, предложит решение, которое может не соответствовать реальным процессам компании. В итоге система оказывается удобной для эксплуатации, но бесполезной для бизнеса.
4. Экономить на предпроектном обследовании
Пропуск этапа детального анализа инфраструктуры и процессов — классическая экономия, которая приводит к многократным потерям. Без аудита сетей, серверов, существующего ПО и документированных бизнес-процессов интегратор работает вслепую. В середине проекта выясняется, что сервера не потянут нагрузку, версия ОС несовместима, а ключевой процесс описан только в голове у сотрудника, который ушёл в отпуск. Всё это становится основанием для дополнительных соглашений и срывов сроков.
Ошибки при выборе и планировании
Даже с правильными ожиданиями проект можно завалить на этапах выбора подрядчика и согласования условий.
5. Выбирать по минимальной цене в коммерческом предложении
В ответах на один запрос цена может отличаться в разы. Самая низкая часто достигается за счёт:
- Использования минимальной конфигурации, неспособной обеспечить требуемую производительность.
- Скрытия стоимости лицензий, обучения, технической поддержки на следующий год.
- Исключения из проекта важных этапов, например, нагрузочного тестирования или разработки резервных сценариев.
Сравнивать нужно не итоговую сумму, а полноту работ и функциональность конечного решения.
6. Подписывать договор с типовым регламентом SLA
Типовой договор интегратора прописывает Service Level Agreement (уровень обслуживания) в его пользу: длительные сроки реакции на инциденты, широкие «окна» на плановые работы, которые могут совпасть с рабочим временем заказчика, отсутствие ответственности за косвенные убытки. Критические параметры — время реакции на аварии (P1), время восстановления, компенсации за простой — нужно согласовывать индивидуально, привязывая к бизнес-циклам компании.
7. Не планировать ресурсы со своей стороны
Работа интегратора требует постоянного участия заказчика: выделенный руководитель проекта, ответственные за предметную область (владельцы процессов), системные администраторы для предоставления доступов, тестировщики. Если все эти люди работают «в нагрузку» к основным обязанностям, их вовлечённость будет низкой. Каждое согласование, каждый ответ на вопрос будут тормозить проект, а интегратор будет правомерно ссылаться на просрочки по вине заказчика.
8. Игнорировать вопрос знаний и компетенций
После сдачи проекта интегратор уходит, а систему обслуживать должны внутренние специалисты. Если в договоре не заложено обучение персонала, а документация написана формально, компания оказывается в зависимости от дорогостоящей технической поддержки интегратора. Необходимо заранее оговаривать объём и формат передачи знаний: обучающие сессии для администраторов, пользовательские инструкции, схематичные архитектурные решения.
Ошибки в управлении проектом
Когда работа началась, фокус смещается на оперативное взаимодействие, где также кроются серьёзные риски.
9. Делегировать интегратору полное управление проектом
Передача интегратору роли и единоличного менеджера проекта, и технического исполнителя создаёт конфликт интересов. Он будет отчитываться сам себе. Контрольные точки, оценка качества и соблюдение сроков должны оставаться у заказчика. Лучшая практика — назначить с внутреннего проекта ответственного с полномочиями принимать решения, который будет вести регулярные (еженедельные) sync-встречи и контролировать фактические работы по чек-листам.
10. Принимать работы без полноценного тестирования
Подписание акта выполненных работ после поверхностной «проверки кнопок» — прямой путь к проблемам в промышленной эксплуатации. Тестирование должно имитировать реальную нагрузку и нестандартные сценарии. Проверяется не только функциональность, но и безопасность, производительность, работа резервных копий и процедур восстановления. Отсутствие этапа User Acceptance Testing (UAT) с участием реальных пользователей — одна из частых причин провала проектов.
11. Игнорировать техническую документацию
В погоне за скорейшим запуском техническая документация часто откладывается «на потом». В итоге сдаётся набор несвязанных схем и скриншотов. Полноценный пакет документов должен включать архитектурную схему, руководства по администрированию и эксплуатации, регламенты инцидент-менеджмента, план восстановления. Отсутствие этих документов усложняет дальнейшую поддержку, модернизацию и аудит системы, особенно в контексте требований регуляторов по защите информации.
12. Не иметь плана на случай срыва сроков или конфликта
Редкий проект обходится без сдвигов сроков. Если в договоре не прописаны чёткие этапы, критерии их завершения и санкции за просрочку, интегратор может бесконечно «доводить» систему. Необходимо иметь поэтапный график платежей, привязанный к конкретным результатам, и формальную процедуру эскалации спорных ситуаций. Это дисциплинирует обе стороны.
Технические и стратегические ошибки
Эти ошибки касаются уже выбранных технологий и долгосрочной стратегии.
13. Соглашаться на проприетарные решения без стратегии выхода
Интегратор может предлагать удобное для себя решение, построенное на полностью закрытой или редкой технологии. Это создаёт монополию: дальнейшая поддержка, доработки и масштабирование возможны только через этого же вендора и по его ценам. При выборе стоит отдавать предпочтение решениям с открытыми стандартами или, как минимум, требовать у интегратора полного раскрытия исходных кодов, схем API и форматов данных, которые останутся у заказчика по окончании проекта.
14. Пренебрегать вопросами информационной безопасности на этапе проектирования
Добавление требований по ИБ в готовый проект — дорого и неэффективно. Вопросы разграничения доступа, аудита, шифрования данных, соответствия требованиям регуляторов (например, 152-ФЗ или приказов ФСТЭК) должны быть заложены в техническое задание с самого начала. Интегратор, не специализирующийся на ИБ, может просто не учесть этих аспектов, что приведёт либо к незащищённой системе, либо к необходимости её полной переделки.
15. Не думать о масштабируемости и развитии
Решение проектируется под текущие объёмы данных и пользователей. Если не закладывать запас по производительности и не проектировать модульную архитектуру, то уже через год рост бизнеса упрётся в технические ограничения системы. Модернизация превратится в новый сложный проект. Нужно заранее обсуждать с интегратором сценарии роста и пути масштабирования (горизонтального или вертикального).
16. Забывать про интеграцию со смежными системами
Внедряемая система редко существует в вакууме. Она должна обмениваться данными с CRM, бухгалтерией, системами кадрового учёта. Если эти интеграции не спроектированы сразу, в будущем придётся заниматься сложной и рискованной склейкой разрозненных систем. Лучше сразу определить точки взаимодействия, форматы обмена (API, файлы, сообщения) и ответственность за поддержку каждого контура.
Завершающие и пост-проектные ошибки
Даже успешный запуск не гарантирует долгосрочного успеха, если не избежать финальных промахов.
17. Отказываться от гарантийного сопровождения
После сдачи проекта возникает желание сэкономить и перевести систему на внутреннюю поддержку, особенно если был этап обучения. Однако первые месяцы эксплуатации — период «детских болезней», когда проявляются скрытые ошибки и неучтённые сценарии. Гарантийная поддержка от интегратора позволяет оперативно и часто бесплатно устранять эти проблемы. Отказ от неё перекладывает все риски на внутреннюю команду, которая ещё не имеет достаточного опыта.
18. Не проводить аудит выполненной работы
После завершения проекта полезно пригласить сторонних специалистов для независимого аудита архитектуры, кода и настроек безопасности. Интегратор мог использовать устаревшие библиотеки, оставить «бэкдоры» для удобства поддержки или внедрить неоптимальные решения. Независимый взгляд помогает выявить такие проблемы до того, как они приведут к сбоям или уязвимостям.
19. Терять накопленные знания
Вся информация по проекту — переписка, протоколы встреч, промежуточные версии документации, решения по спорным вопросам — должна быть систематизирована и сохранена в корпоративном хранилище. Часто эти знания остаются только у менеджера проекта. Если он уйдёт из компании, история принятия решений будет утеряна, что осложнит дальнейшее развитие системы.
20. Рассматривать проект как разовое событие
Самая стратегическая ошибка — считать, что с подписанием финального акта история взаимоотношений с интегратором закончена. ИТ-ландшафт меняется, появляются новые угрозы, меняются бизнес-процессы. Система требует постоянной эволюции. Успешный интегратор, который глубоко погрузился в специфику бизнеса, — ценный партнёр для этой эволюции. Разрыв этих связей означает, что каждый новый этап развития будет начинаться почти с нуля, с повторением многих из перечисленных ошибок.
Избежать этих двадцати ошибок не значит гарантировать абсолютно гладкий проект, но это радикально снижает риски превращения внедрения в долгострой с неопределённым результатом. Фокус смещается с контроля исполнителя на совместную работу по достижению измеримого бизнес-результата, где у каждой стороны есть чёткая ответственность и понимание общих целей.