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