← Предыдущая статья

Роль «заказчика» в корпоративных ИТ иногда представляется так, будто все вокруг него должны бегать, а он сам при этом может ничего не делать. Заплатил, нахмурился, сказал «нам нужно как у них», ушел ждать результата. Если результата нет — вернулся, нахмурился сильнее.

Звучит грубовато. Но в этом образе есть полезная карикатура: он показывает инфантильную версию заказчика.

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

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

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

Но участвовать — не значит встать за спиной разработчика и диктовать архитектуру. И не значит прийти с просьбой: «Сделайте как у них, но чтобы нам подошло». Такой подход обычно не создает платформу. Он создает склад частных исключений, который потом почему-то называют гибкостью.

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

Факты

По итогам АКПО-Конф 2026

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

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

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

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

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

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

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

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

Что видно по российским проектам

Российская специфика здесь не столько в отдельном регуляторном запрете, сколько в самой ситуации: крупные ERP-проекты идут одновременно с импортозамещением, развитием отечественных платформ, давлением сроков и попыткой не уронить текущую эксплуатацию.

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

По данным Аналитического центра при Правительстве РФ, во второй волне проектов ИЦК 17 проектов получат грантовое финансирование, а 32 будут выполнены за счет собственных средств компаний. 86% отобранных проектов планировалось завершить до 2027 года включительно (Аналитический центр при Правительстве РФ). Это важно не как отчетная цифра, а как признак: государство и крупные компании пытаются организовать не разовые закупки, а разработку отраслевых решений с понятными заказчиками и сроками.

Публичный кейс 1С:Консалтинг по проекту «Газпром нефти» показывает ту же логику уже на уровне проекта: корпоративный финансовый шаблон на базе «1С:ERP Управление предприятием 8» разработали совместными силами ООО «Газпромнефть-ЦР» и ООО «ИТ Платформа», а одной из целей проекта стало внедрение шаблона в дочерних обществах группы (1С:Консалтинг). Это важно не как рекламная витрина, а как пример того, что крупный заказчик работает с ERP через шаблон, процессы, единые правила, отчетность и дальнейшее тиражирование решения.

Что подсказывает опыт SAP

Опыт SAP здесь важен не потому, что его нужно копировать. Он важен как напоминание: зрелая ERP-платформа не развивается в одиночку, закрывшись в обители вендора.

Вокруг SAP давно существуют формальные каналы влияния заказчиков на развитие продуктов: SAP Customer Influence, пользовательские группы, запросы на улучшения, голосование и ранний доступ к новшествам. SAP Community описывает Customer Influence как программы, через которые заказчики могут влиять на инновации SAP на разных этапах жизненного цикла продукта (SAP Community, Customer Influence and Adoption). ASUG отдельно разбирает Customer Engagement Initiative, Customer Connection и Continuous Influence как механизмы ранней обратной связи, улучшений on-premise-решений и постоянных запросов на развитие cloud- и новых решений (ASUG, SAP Customers Give Valuable Feedback Through Influence Programs). Официальный раздел SAP о бета-тестировании добавляет еще один слой — возможность тестировать новые версии на собственных процессах, данных и ландшафте до официального выпуска (SAP Support Portal, Get Involved Early). А UKISUG показывает практическую механику голосования по запросам на улучшения: она помогает продуктовым командам SAP видеть, какие запросы важны не одному заказчику, а широкой клиентской базе (UKISUG, SAP Continuous Influence).

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

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

Редакционное наблюдение

Если сложить эти фрагменты, видно главное: крупный заказчик в ERP-проектах перестает быть внешним потребителем готовой платформы.

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

При этом заказчик приносит не только пользу. Он приносит еще и сложность.

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

И вот здесь начинается взрослая часть разговора.

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

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

Попытка объяснения

Возможно, привычная схема «вендор продает — заказчик покупает» в наших условиях уже недостаточна.

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

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

У заказчика есть эксплуатационная логика: нельзя ждать идеального будущего, если проблема мешает работе сейчас.

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

На стыке этих трех логик и появляется ERP в соавторстве.

Но соавторство — не красивая подпись под слайдом и не совместная фотография после соглашения. Это дисциплина.

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

Неприятно? Да. Зато похоже на взрослую работу.

Гипотеза

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

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

Важен другой вопрос: может ли заказчик реально влиять на развитие продукта, не превращая его в свою внутреннюю систему? И может ли вендор использовать требования крупного заказчика так, чтобы продукт стал сильнее, а не просто оброс еще одним слоем исключений?

Ответить на такие вопросы поможет только опыт тех, кто сам участвует в развитии корпоративных платформ.

А вы участвуете в развитии ERP-продукта или только передаете замечания через поддержку, интегратора и длинную цепочку писем? Как у вас решаются вопросы приоритета: кто определяет, какие требования попадут в дорожную карту, какие останутся локальными, а какие придется отложить? Что работает лучше: формальная дорожная карта, клуб заказчиков, премиальная поддержка, рабочие группы, центр компетенций, регулярные встречи с вендором или что-то еще?

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

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

Автор

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