В профессиональных кругах иногда любят бросать красивые и провокационные утверждения, чтобы проверить их на прочность логикой. Одно из таких звучит примерно так: «Лучшие архитекторы получаются из каменщиков». Или еще радикальнее: «Тот, кто лучше всех умеет класть кирпич, с высокой вероятностью придумает самые удачные и продуманные планировки зданий». Тут же вспоминаются и другие аналогии: «Хороший токарь — идеальный кандидат в конструкторы станков», а «бывший сварщик знает, как спроектировать кузов автомобиля лучше любого выпускника вуза». На мой взгляд, эти утверждения не выдерживают критики. Да, безусловно, бывают редкие частные случаи, когда человек с руками и богатым практическим опытом вдруг открывает в себе дар системного проектирования. Но в основной массе — это глубокое заблуждение. Каменщик знает, как сделать ровный шов и подогнать кирпич под уровень, но он не обязан разбираться в сопротивлении материалов, в розе ветров, в инсоляции и в том, как правильно расположить несущие стены, чтобы здание не просело. Это абсолютно разные уровни мышления: тактический и стратегический. Одно дело — исполнить, другое — спроектировать систему. И здесь начинается самое любопытное. Потому что в сфере внедрения и интеграции корпоративных систем (будь то ERP, PLM или другие сложные платформы) этот «строительный» подход считается не просто нормой, а едва ли не единственно верной карьерной траекторией. Посмотрите, как устроен типичный путь специалиста в системном интеграторе. На входе — молодой человек, который пишет код. Он реализует запросы, правит конфигурации, исправляет ошибки в модулях. Это его «кирпичи» и «раствор». Проходит три, пять, семь лет — и этот же человек пересаживается в кресло функционального архитектора. Теперь он уже не строчит строчки, а придумывает, как правильно должны взаимодействовать производственные подразделения. Он решает, как списывать материалы в цехах, как передавать спецификации из конструкторского отдела в закупки, как выстраивать маршруты движения полуфабрикатов. Но вот в чем парадокс. В подавляющем большинстве случаев этот человек ни дня не работал на реальном производстве. Он не знает, как выглядит заводская приемка, почему кладовщик не может найти деталь на стеллаже, и как на самом деле происходит передача смены между бригадами. Он стал архитектором, потому что хорошо знал структуру таблиц в базе данных и умел быстро писать отчеты. Но он никогда не видел ту самую «физику» процесса, которую сейчас пытается описать в техническом задании. Получается забавный перевертыш. В строительстве мы говорим: каменщик редко становится архитектором, потому что это разные компетенции. А в IT-интеграции мы считаем, что программист, написавший код, автоматически вырастает в архитектора, который будет описывать бизнес-процессы для реального завода. И это, на мой взгляд, системная ошибка, которая дорого обходится заказчикам. Именно здесь становится отчетливо видно, чего остро не хватает современным системным интеграторам. Им не хватает не «звездных разработчиков» и не «гуру SQL». Им катастрофически не хватает тех самых специалистов, которые пришли с производства. Тех, кто может прийти в команду, сесть рядом с программистом и объяснить, как на самом деле взаимодействуют цеха, почему закупки должны видеть не плановые, а фактические остатки, и в какой момент спецификация изделия перестает быть «бумажной» и становится «живой». Им нужны люди, которые правильно напишут бизнес-процессы не по учебнику, а по факту, а потом доходчиво, на пальцах и цифрах, донесут эти процессы до кодеров, чтобы те переложили их на язык программного кода. Пока этого не произойдет, проекты по внедрению будут либо переусложненными, либо оторванными от жизни. Потому что нельзя проектировать цифровой завод, если ни разу не был на настоящем. И в этом смысле строительная аналогия оказывается права, но ровно наоборот: архитектором должен быть тот, кто понимает физику объекта, а не только синтаксис языка. И если мы хотим получать работающие системы, нам пора перестать растить