Вы выбираете не решение, а проблемы, с которыми будете жить дальше
Когда бизнес-проблема сформулирована, данные изучены, зоны ответственности определены, а требования согласованы, кажется, что дальше останется лишь выбрать подходящую технологию. На практике именно в этот момент часто начинается самая сложная часть работы.
Одного очевидного решения может не существовать. На столе оказываются несколько архитектурно допустимых вариантов: каждый можно реализовать, у каждого есть сильные стороны, ограничения и собственный набор последствий. Поэтому финальный выбор - это не соревнование "правильной" и "неправильной" архитектур. Это управленческий компромисс, в котором компания заранее решает, какие проблемы готова принять.
Когда архитектура перестаёт выбирать за компанию
В одном из проектов новая ERP должна была работать с данными, распределёнными примерно по десяти различным системам и массивам. После анализа источников, правил ведения справочников и требований подразделений осталось три реалистичных сценария:
- сохранить распределённую модель и связать источники с ERP интеграциями;
- перенести значительную часть валидации нормативно-справочной информации внутрь ERP, в том числе выполнять её вручную;
- создать отдельный корпоративный контур НСИ, который стал бы единым центром управления данными.
Все три варианта технически были выполнимы. Именно это и сделало выбор трудным. Если один сценарий явно невозможен, решение принимается быстро. Но когда каждый вариант выглядит рабочим, обсуждение перемещается из области архитектуры в область денег, ответственности и будущих ограничений.
Поначалу сравнение строилось вокруг привычных параметров: число интеграций, сложность сопровождения, скорость внедрения, масштабируемость и место исполнения бизнес-правил. Однако третий вариант вскоре показал цену, которую нельзя было спрятать за нейтральной формулировкой "выделить отдельный контур НСИ".
Для него требовалась не только новая информационная система. Компании пришлось бы сформировать постоянную функцию: назначить руководителя, нанять специалистов, закрепить полномочия и обеспечить финансирование после завершения проекта. Архитектурное решение превращалось в организационную единицу с ежегодными расходами.
Где заканчивается бюджет проекта
Пока обсуждаются интерфейсы и модели данных, решение кажется техническим. Но как только появляется необходимость содержать новую функцию, меняется сам предмет разговора. Возникает вопрос: готова ли компания постоянно платить за выбранную модель управления?
Расходы при этом появляются в одном подразделении, а пользоваться результатом будут многие: бухгалтерия, финансы, производство, закупки и продажи. Поэтому управляющий комитет должен оценивать не только стоимость запуска, но и механизм распределения выгод и затрат.
Производство также отстаивало собственную систему как наиболее надёжный источник данных. Такую позицию легко назвать функциональным эгоизмом, но это было бы ошибкой. Для производственного подразделения качество справочника - не вопрос аккуратности интерфейса. Неверная характеристика материала, единица измерения или количество способны привести к сбоям в реальном процессе, а исправлять последствия придётся тем, кто отвечает за выпуск продукции.
Поэтому желание контролировать данные, критичные для производства, вполне рационально. Аналогично другие функции защищают собственные источники: закупки - поставщиков, продажи - клиентов, финансы - реквизиты и договорные параметры. Конфликт возникает не потому, что кто-то не понимает важность единого справочника, а потому, что разные подразделения по-разному оценивают цену ошибки.
Сравнивать нужно не только выгоды
Обычная таблица плюсов и минусов помогает структурировать разговор, но редко позволяет принять решение сама по себе. Для каждого варианта полезно отдельно оценить несколько параметров.
Стоимость реализации. Сюда входят лицензии, разработка, интеграции, миграция, тестирование, обучение и работа внутренних команд.
Стоимость владения. Важно учитывать сопровождение, поддержку интерфейсов, обновления, контроль качества данных, обучение новых сотрудников и регулярное развитие решения.
Обратимость. Если гипотеза окажется неверной, насколько легко перейти на другой вариант? Можно ли заменить компонент без остановки процессов или изменение затронет всю архитектуру?
Остаточный риск. Даже после запуска часть рисков останется. Нужно понимать, кто будет ими управлять и сколько будет стоить снижение их вероятности.
Организационные последствия. Новая система может потребовать новых ролей, регламентов, владельцев процессов и изменений в структуре ответственности.
Скорость получения эффекта. Иногда более дорогой вариант позволяет быстрее решить критичную проблему. В других случаях быстрый запуск создаёт технический долг, который затем окажется дороже первоначальной экономии.
Цена передумывания
У каждого решения есть стоимость выхода. Она может быть небольшой, если речь идёт о заменяемом модуле или отдельной интеграции. Но если выбранная модель закрепляет процессы, данные и ответственность, отказ от неё становится значительно сложнее.
Систему заменить обычно возможно. Намного труднее заменить функцию, которая уже встроилась в повседневную работу компании. Ещё сложнее изменить распределение ответственности: после нескольких лет эксплуатации подразделения начинают воспринимать сложившуюся схему как естественную и защищают её интересы.
Поэтому при выборе стоит задавать вопрос не только "что мы получим?", но и "что произойдёт, если через два года поймём, что ошиблись?". Ответ должен включать сроки, стоимость миграции, зависимость от подрядчиков, сохранность истории и готовность сотрудников перейти на новую модель.
Почему скоринг иногда превращается в алиби
Балльные модели выглядят объективно: каждому варианту назначаются оценки, затем рассчитывается итоговый результат. Но цифры не делают субъективные предположения объективными.
Если скорость запуска оценена в пять баллов, а организационная сложность - в два, необходимо понимать, кто и на основании чего выставил эти значения. Не менее важны веса критериев. Приоритет быстрого внедрения может быть оправдан для кризисного проекта, но опасен для базовой корпоративной платформы.
Таблица полезна как инструмент фиксации логики, а не как автоматический генератор решения. Если участники не готовы обсуждать исходные допущения, скоринг превращается в алиби: после выбора можно сослаться на "объективную модель", хотя ключевые предпочтения были заложены заранее.
Когда ИТ вправе сказать "пока нет"
ИТ не обязано поддерживать старт проекта любой ценой. Иногда техническая команда должна остановить преждевременное решение, если не определены владелец данных, границы ответственности, порядок исправления ошибок или источник финансирования эксплуатации.
Это не означает сопротивление бизнесу. Напротив, отказ начинать без критически важных условий может защитить компанию от ситуации, когда проект формально завершён, но система не используется, данные остаются противоречивыми, а ответственность распределяется между всеми и никому не принадлежит.
Правильная формулировка в такой ситуации - не "решение невозможно", а "для запуска необходимо сначала закрыть конкретные условия". Например, назначить владельца НСИ, согласовать правила изменения справочников, определить бюджет поддержки и зафиксировать критерии качества данных.
Как оформить выбор качественно
Хороший документ по архитектурному выбору должен показывать не победивший вариант, а весь спектр последствий. В нём стоит зафиксировать:
1. какие задачи решает каждый сценарий;
2. какие допущения лежат в его основе;
3. какие расходы возникают на запуске и в эксплуатации;
4. какие роли и подразделения будут вовлечены;
5. какие риски сохраняются после реализации;
6. насколько легко отказаться от варианта;
7. что произойдёт при росте нагрузки или изменении бизнес-модели;
8. кто принимает остаточные риски.
Отдельно полезно записывать причины отказа от альтернатив. Через год это позволит понять, было ли решение ошибочным или изменились исходные условия.
Решение принято - проблемы только начинаются
После выбора работа не заканчивается. Необходимо превратить архитектурное решение в набор управляемых обязательств: назначить владельцев, определить контрольные показатели, создать процесс пересмотра правил и регулярно проверять, соответствует ли выбранная модель реальности.
Важно заранее договориться, какие сигналы потребуют пересмотра. Например, рост числа ручных операций, увеличение времени исправления ошибок, систематические конфликты между подразделениями или превышение бюджета сопровождения.
Главная зрелость архитектурного решения состоит не в том, чтобы найти вариант без недостатков. Таких вариантов почти не бывает. Зрелая компания понимает, какие проблемы создаёт выбранный путь, кому они достанутся, сколько будет стоить их решение и в какой момент нужно изменить курс.
Вы выбираете не систему и не набор технологий. Вы выбираете будущую структуру затрат, ответственности, ограничений и компромиссов. Чем честнее они описаны до запуска, тем меньше неожиданностей возникнет после него.
