20 апреля 2026 года я побывал на третьей АКПО-Конф. Посетил пять сессий, делал пометки, ловил у спикеров повторяющиеся мысли и нередко отмечал про себя: «Вот и здесь за аккуратными формулировками пробивается та самая реальность, в которой мы работаем: ограничения, риски, недосказанные условия и цена ошибки».

Из таких моментов и вырос этот цикл.

Сразу скажу, чем он не будет.

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

На этот раз вас ждет другой формат — заметки главреда.

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

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

Такие сигналы и интересны.

Я почти не буду использовать прямые цитаты и не буду строить тексты вокруг фамилий. Это осознанный выбор. Важна не погоня за точной фразой, а проверка смысла через обращение к вам. Узнаёте ли вы, те, кто работает с реальными ERP-ландшафтами, интеграциями, данными, ИИ, сопровождением и импортозамещением, эту боль? Есть ли у нее подтверждения? Когда она начинает проявляться? Есть ли опровержения? Как вовремя распознать опасность?

В каждой заметке я буду четко разделять четыре типа информации.

Факты — то, что было или то, что можно проверить, включая то, что я услышал на сессии, прочитал в программе или нашел в открытом источнике.

Редакционное наблюдение — то, что я воспринял как повторяющийся мотив.

Версия объяснения — предположение, почему такой мотив мог возникнуть.

Гипотеза — формулировка, сопоставленная с контекстом, которую, возможно, стоит проверить на реальных проектах.

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

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

Хочется другого: вместе с вами собрать из вашего опыта проверяемые показатели. При каких условиях решение работает? Где начинает ломаться? Как это заметить до того, как проект уже перешел в режим тушения пожаров? Какие случаи подтверждают правило, а какие заставляют его уточнять?

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

Пишите на y.nechitaylov@sappro.ru, в комментариях к соответствующим постам Telegram-канала или в комментариях под этими материалами на sappro.ru.

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

Продолжение следует. 

Автор

Юрий Нечитайлов, главный редактор SAP Professional Journal Россия