Поддержка без вендора

Модератор Сергей Горшенин («Кузница Управленческого Бэкграунда») предложил смотреть на эту проблему как на управленческую. ИТ-директору приходится не просто поддерживать старую систему в рабочем состоянии, а понимать, сколько еще можно жить с этим риском и когда подготовка к замене становится вопросом устойчивости бизнеса.

Когда работает, уже не значит управляется

Поддержка без вендора редко начинается с громкого сбоя. Чаще все выглядит спокойно. Снаружи система представляется частью привычного порядка, и именно это усыпляет внимание. Но за внешней стабильностью постепенно меняется главное — компания все хуже понимает, насколько она еще управляет этим активом. В зоне риска оказывается не один класс решений, а привычный корпоративный стек. Участники называли ERP-системы уровня SAP ERP, СУБД Microsoft SQL Server, решения виртуализации, middleware, ESB-системы, BPM. Формально они могут оставаться в эксплуатации годами, но поддержка все чаще становится компромиссной. Патчи не устанавливаются, уязвимости копятся, лицензии уходят в серую зону, документация устаревает.

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

«Самая опасная иллюзия, что, если работает, значит, оно под контролем. Но на самом деле система постепенно выходит из зоны управляемости, и ее сложно восстанавливать», — отмечает Алексей Иващенко («Смарт Текнолоджис»).

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

В производственном контуре этот риск особенно заметен. На Автозаводе Санкт-Петербург, по словам ИТ-директора Романа Цыганкова, часть решений досталась компании от предыдущих собственников. Они используются в текущей работе, но с каждым этапом эксплуатации все сложнее отвечать на базовые вопросы. Можно ли их развивать? Кто сможет это сделать? Сколько будет стоить поддержка? Есть ли у такой модели понятная перспектива?

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

Для части предприятий жизнь без полноценной вендорской поддержки не стала новым состоянием последних лет. Например, в «Теплообменнике», по мнению ИТ-директора Александра Стручкова, давно существуют в такой среде. Речь идет о системах разного масштаба, от корпоративной информационной системы класса ERP до производственной автоматизации и решений, поставленных вместе с оборудованием.

Именно в промышленности вопрос «почему бы просто не заменить?» часто звучит слишком легко. Часть решений пришла вместе со станками, ЧПУ, измерительными комплексами и изначально поддерживалась зарубежными производителями оборудования. Иногда программную часть невозможно заменить отдельно от оборудования. Иногда любое вмешательство требует проверки на производственном процессе. Иногда полноценной альтернативы на рынке просто нет.

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

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

В компании ЕАПТЕКА, которая находится на стыке e-commerce и фармы, крупные кор-системы в целом не построены на импортных решениях. Однако, как отмечает главный архитектор компании Олег Гришко, это не снимает вопроса полностью: «Наши ключевые кор-системы не завязаны на импортных продуктах. Тем не менее, в крупной компании всегда есть системы или инфраструктурные сервисы, для которых вопрос импортозамещения актуален. Мы проводим планомерную работу по решению данной задачи. Безусловно, замалчивать эти вызовы нельзя — с ними нужно работать».

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

Где заканчивается «работает, не трогай»

Принцип «работает, не трогай» в ИТ живуч не случайно. В сложном корпоративном ландшафте любое вмешательство может быть дороже, чем осторожное сопровождение. Но у этого принципа есть граница. Система может не требовать внимания не потому, что с ней все хорошо, а потому что бизнес уже нашел обходной путь или давно вынес нужный функционал в теневые приложения.

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

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

При этом жесткая формула «старое надо срочно менять» тоже не работает. У Евгения Богорада (клуб «ИТ-Диалог») здесь более прагматичный подход: «Если работает, то зачем трогать? И, естественно, если нет каких-то требований регулятора, здесь все понятно, комплаенс мы соблюдаем».

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

Вопрос не в возрасте системы, а в ее влиянии на бизнес. Тарас Сорока (клуб «ИТ-Диалог») привел два показательных кейса. В одном из них система на FoxPro давно осталась без нормальной поддержки, но ее продолжали эксплуатировать осознанно. «Было принято осознанное решение остаться и эксплуатировать ее так долго, насколько возможно. Почему? Потому что функционал системы вполне понятен. Она не является критической. Мы прекрасно понимаем, что если вдруг в какой-то момент ее не станет, то месяц бизнес «протащит» этот функционал на руках», — добавляет Тарас.

Иначе выглядит ситуация, когда на самописной legacy-системе держится core-бизнес. В другом кейсе исторический процессинг финансовой организации развивали два разработчика, один из которых ушел. То, на что много лет не хватало политической воли, переписали за год, потому что риск стал недопустимым.

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

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

Риск надо переводить в деньги

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

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

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

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

В Группе ЛАТЕО, по словам ИТ-директора Ивана Козлова, именно так пришлось обосновывать замену WMS. Если система обеспечивает отгрузку, ключевой вопрос не в ее возрасте, а в том, что произойдет при отказе: «Система хорошая, американская, только поддержки нет. И пока она работает, но если завтра она перестанет работать, то мы бизнес остановим. У проекта внедрения новой системы нет цели увеличить отгрузки, снизить стоимость или повысить эффективность (хотя если получится – хорошо). Есть цель не допустить остановки бизнеса».

Денег на замену WMS изначально запланировано не было, но проект удалось обосновать. Один день простоя стоит компании десятки миллионов рублей. По сути, система окупается за несколько дней предотвращенного простоя.

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

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

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

Но временное решение должно оставаться временным. Когда костыль становится стратегией, компания снова заходит в закрытый туннель. Поэтому ИТ-директору важно показать бизнесу не один страшный сценарий, а карту вариантов. Полная замена. Временная поддержка. Частичное снижение риска. Осознанное принятие риска. И по каждому варианту должны быть понятны цена, сроки и последствия.

Маленькие шаги к выходу

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

Олег Гришко описывает это как движение в туннель, из которого будет трудно выйти: «Добавить небольшую заплатку просто банально дешевле. Но это же вопрос стратегии. Мы заходим все глубже и глубже в туннель, который закрыт с другой стороны».

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

Такой список нельзя просто составить и отложить в сторону. Его нужно приоритизировать, привязать к бизнес-доменам и ресурсам. Иначе он останется красивым реестром проблем, к которому все привыкнут.

Здесь важен реализм. Денег и людей на полную перестройку ландшафта почти никогда не хватает. Поэтому работа с техдолгом должна быть встроена в обычный ритм команд. В одной из практик, о которой рассказал эксперт, с владельцами продуктов договаривались о фиксированной доле времени на устранение технического долга. Раньше это могло быть около 30%, сейчас чаще удается защитить 15-20%.

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

На практике этот ресурс постоянно конкурирует с текущими бизнес-задачами. Команда может договориться о работе с техдолгом, но затем появляется срочная инициатива от коммерческого блока, розницы или другого направления. Конкуренты что-то запустили, сроки горят, и выделенные 15–20% быстро уходят на видимый функционал.

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

С архитектурной точки зрения первые триггеры довольно понятны. Ждать дальше опасно, если уязвимости в старом технологическом стеке становятся критичными, ИБ уже не готова принимать риск, система не выдерживает рост нагрузки, а масштабировать ее невозможно или бессмысленно.

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

Когда ИТ спасает систему, бизнес привыкает к чуду

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

Со стороны интегратора это хорошо видно. После 2022 года многим компаниям предлагали заранее искать варианты перехода на open source или российские решения. Но пока западные системы продолжали работать, внутри часто сохранялась надежда на продление контрактов, очередной апгрейд или временное исключение.

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

«Если есть какая-то система, которая мешает бизнесу развиваться, она требует внутреннего героизма для поддержки. В том числе и для ИТ-компаний, которые обслуживают конечных пользователей и заказчиков», – уверен Алексей Иващенко.

С таким героизмом связана отдельная управленческая ловушка. ИТ-директора сами приучили бизнес к тому, что невозможное все же можно сделать. Денег на замену нет, сроки сжаты, риски очевидны, но ИТ находит обходной путь, договаривается с подрядчиком, пишет временную интеграцию, закрывает дыру ночами и выходными. Сначала это выглядит как профессионализм. Потом как лояльность. Потом как новая норма. «Мы, наверное, как ИТ-директора, сами стали заложниками ситуации, потому что в какой-то степени бизнес избаловали. Мы подсвечиваем критичность системы, говорим о поддержке, бизнес отвечает, что денег столько-то. Ты понимаешь критичность для бизнеса и как-то это поддерживаешь. А когда приходишь еще раз и говоришь, что все, край, тебе говорят: ну ты же как-то делал, давай еще чуть-чуть», - говорит Роман Цыганков.

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

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

Замена системы не бывает только ИТ-проектом

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

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

Для Ивана Козлова такая замена ничем не отличается от большого проекта изменений. ИТ не просто приносит новую программу и запускает ее в промышленную эксплуатацию. Нужно работать с персоналом, мотивацией, объяснять последствия, поддерживать пользователей и управлять сопротивлением. Разница лишь в том, что проект может не давать нового функционала или роста прибыли, а закрывать риск остановки бизнеса.

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

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

Отдельный риск, по словам Александра, возникает, когда компания начинает метаться между вариантами. Сегодня пробует один путь, завтра другой, потом откатывается и снова меняет направление. Такие развороты выжигают всех: ИТ-команду, пользователей и руководителей, которые перестают верить в проект. Но преодолевать сопротивление не должна одна ИТ-служба. Если ИТ-директор оказывается единственным человеком, которому нужно изменение, проект изначально слаб. В такой ситуации он борется не за систему, а с культурой компании.

«Если ты один такой Дон Кихот, который борется с ветряными мельницами, а больше никому ничего не надо, поскольку всех все хорошо, то, конечно, это плохая работа», – добавляет Иван Козлов.

На производстве эта тема особенно заметна. Александр Стручков называет ее «айти-психологией». В начале 2000-х, когда на заводе почти не было компьютеров, внедрение ИТ требовало настоящей агитации. Сейчас пользователи стали намного более подготовленными, но сопротивление изменениям никуда не исчезло.

Главное условие успешного внедрения – это поддержка первого лица компании. Когда она есть, остальные организационные механизмы выстраиваются заметно легче. Регламенты, инструкции и стандарты предприятия тоже помогают, но в нормальной ситуации они должны не насаждать изменение силой, а закреплять уже отработанный процесс.

Важна и внутренняя культура ИТ-службы. В «Теплообменнике» многие решения сначала пробуют внутри ИТ, иногда в нескольких вариантах, и только потом показывают пользователям уже отработанный вариант. Это снижает раздражение и повышает доверие. Пользователи видят не сырой эксперимент, а решение, за которое ИТ готово отвечать.

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

Но, как справедливо отмечает Тарас Сорока даже доверие к ИТ не отменяет ответственности бизнес-функции. При замене WMS за готовность логистики к новой модели должен отвечать директор по логистике. При изменении финансового контура ответственность должна разделять финансовая функция. У бизнес-руководителя должны быть собственные цели, связанные с внедрением, иначе система формально становится ИТ-проектом, хотя на самом деле меняет бизнес-процесс.

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

Рано, поздно и вовремя

В финале Сергей Горшенин предложил участникам оглянуться назад и ответить, где они тянули слишком долго, а где, наоборот, поспешили. За последние годы почти у всех накопился опыт решений, которые сегодня хотелось бы принять раньше, позже или спокойнее.

Когда разговор дошел до того, что стоило бы сделать иначе, ответ быстро ушел из методологии в закупки. Роман Цыганков сказал, что серверы купил бы в прошлом году. Евгений Богорад сразу добавил: «А я бы в позапрошлом». В этой шутливой переброске хорошо слышен опыт последних лет, когда нужное оборудование, лицензии или доступные условия еще есть на рынке, но пока компания согласует бюджет и проходит внутренние процедуры, окно уже закрывается.

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

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

Слишком ранний переход тоже может обернуться проблемой. Иван Козлов вспоминает опыт 2022 года, когда одну из пользовательских систем быстро перенесли на российский продукт крупной компании. Дорожная карта выглядела убедительно, но потом больше года пришлось ждать, пока обещанное действительно появится. «Бета-тестером больше быть не хочется. При переходе нужно четко понимать, куда ты идешь и что получишь. Не светлое обещание, что завтра мы обязательно все доделаем и починим, а чтобы оно работало прямо сегодня», – комментирует Иван.

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

Общий вывод, к которому подвел Сергей Горшенин – волшебной пилюли здесь нет. В одной компании разумнее продолжать поддерживать старую систему и не дергать пользователей. В другой нужно срочно уходить, потому что простой стоит дороже внедрения. Где-то риск связан с продуктом, где-то с людьми, которые одни знают, как все устроено, а где-то с инфраструктурой, железом, базами данных и архитектурным долгом.

С вендорской поддержкой стало сложнее, но это не означает поражения. С такими системами можно жить и работать, если не путать управление с ожиданием. В этом смысле хорошо подходит анекдот: «Монголы — это максимум до лета» (из разговоров на любой русской площади в мае 1223 года). Мы-то знаем, чем закончилась эта уверенность.

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