Я начинаю IT-стратегию с решения, которое нельзя принимать вслепую

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

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

Стратегия начинается с вопроса, у которого есть цена

У собственника редко звучит вопрос «какую архитектуру нам выбрать». Чаще он выглядит иначе: «можно ли открыть ещё одно направление без роста ручной работы?», «что произойдёт, если уйдёт этот сотрудник?», «имеем ли мы право обещать клиентам новый срок?» или «во что вкладываться в следующем квартале?»

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

Почему инвентаризация полезна, но не задаёт направление

Список сервисов всё равно нужен. Он показывает, где живут данные, кто имеет доступ и какие интеграции уже завязаны друг на друга. Но он отвечает только на вопрос «что у нас есть». Для стратегии этого мало.

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

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

Три решения, с которых удобно начать

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

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

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

Как не сделать из стратегии презентацию

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

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

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

Нужен не идеальный план, а ясный следующий ход

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

Я считаю стратегию полезной, когда после неё у руководителя есть ответы на пять простых вопросов:

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

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

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

Как провести первый разговор без сложной подготовки

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

Я бы попросил каждого закончить три фразы. «Через полгода нам важно иметь возможность…». «Сегодня мы не уверены, потому что…». «Если ничего не менять, для нас опаснее всего…». Формулировки могут не совпасть, и это нормально. Именно расхождение показывает, где у бизнеса нет общего языка для разговора о технологии.

Затем полезно взять не все проблемы, а одну. Допустим, компания хочет открыть новый канал продаж. Не надо сразу обсуждать CRM, сайт, мобильное приложение и аналитическую платформу. Сначала выясняем, какое решение принимает менеджер после появления заказа, какие данные для него нужны и что произойдёт, если они окажутся неполными. Так из абстрактного «нужно масштабироваться» получается маршрут, который можно проверить.

Что должно быть видно в каждой инициативе

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

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

Очередь важнее длинного списка

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

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

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

Стратегия должна переживать плохие новости

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

Для этого я заранее добавляю точки пересмотра. Не формальный ежемесячный отчёт, а вопрос: «всё ещё ли это решение самое важное?» и «появился ли новый факт, который меняет ставку?» Иногда ответом будет продолжение. Иногда — остановка. Остановка не поражение, если она освобождает деньги и внимание до того, как проблема стала дорогой.

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

Что меняется в разговоре с подрядчиком

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

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

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

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

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