Купить, разработать, изменить или отказаться: четыре ответа CIO на запрос бизнеса

3 августа 2026

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

какую систему купить;
какого вендора выбрать;
можно ли использовать существующую платформу;
не дешевле ли разработать собственный продукт.

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

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

действительно ли новая система нужна?

Классическая дилемма Make-or-Buy предлагает два ответа: купить готовое решение или разработать собственное. Эта логика остается полезной, но начинает работать слишком поздно. До выбора между покупкой и разработкой CIO должен рассмотреть еще два варианта: сначала изменить процесс или вообще отказаться от инициативы.

Получается четыре возможных ответа на запрос бизнеса:

Buy – купить готовое решение.
Make – разработать собственное.
Change – сначала изменить процесс.
Stop – отказаться или отложить проект.

Эта модель не отменяет Make-or-Buy. Она возвращает дискуссию от технологий к бизнес-ценности.

Почему выбора технологии уже недостаточно

В исследовании PMI Maximizing Project Success 2024, основанном почти на 10 тысячах ответов из 19 стран, успешным предлагается считать проект, который создал ценность, оправдывающую затраченные усилия и расходы.

По этой методике только 48% рассмотренных проектов были признаны успешными. Еще 40% дали смешанный результат, а 12% оказались неудачными [1].

Это меняет саму постановку задачи. Если цель проекта – не внедрение системы, а создание ценности, вопрос «что будем внедрять?» не может быть первым. Сначала нужно определить, какое изменение вообще способно дать требуемый результат.

Для промышленности этот вопрос особенно актуален. По данным НИУ ВШЭ, среди крупных и средних предприятий обрабатывающей промышленности ERP используют 78,7%, CRM – 73,4%, PLM/PDM – 57,7%, системы управления складом – 83%, решения для закупок – 80,4% [2].

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

Первый ответ: купить готовое решение

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

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

Эту логику хорошо иллюстрирует переход производителя измерительных приборов SONEL с 1С:УПП на 1С:ERP. Одной из целей проекта было использование типового функционала с минимальным объёмом доработок [3]. Компания заменила устаревшую систему зрелым решением, не превращая внедрение в разработку собственной ERP.

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

Противоположный пример – внедрение Oracle ERP в городском совете Бирмингема. Стоимость проекта и последующего восстановления превысила £100 млн, дополнительно потребовались десятки миллионов фунтов на стабилизацию и ручную корректировку данных [4].

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

Правило Buy: готовое решение оправданно, если предприятие готово стандартизировать процесс и ограничить кастомизацию.

Второй ответ: разработать собственное решение

Фраза «тогда напишем свое» часто звучит как простая альтернатива неудачному выбору готового продукта. Но собственная разработка – это не разовый проект. Это решение взять на себя долгосрочное владение цифровым продуктом.

После первого релиза потребуются:

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

Поэтому главный вопрос звучит не так:

Можем ли мы разработать эту систему?

Он должен звучать иначе:

Готовы ли мы владеть этой системой в течение многих лет?

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

Хороший пример Make – разработка собственной CRM в фармацевтической компании «Акрихин». Вместо внедрения типового продукта компания с нуля создала решение под специфику работы полевых сотрудников, дополнив его собственной моделью компьютерного зрения и собственной ML-моделью рекомендаций по визитам в аптеки. По итогам пилота продажи в выбранных регионах выросли на 20%, а ожидаемая экономия за первый год была оценена в 50–70 млн рублей [5].

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

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

Показателен опыт программного подразделения Cariad концерна Volkswagen. Компания стремилась создать единый программный стек для автомобилей группы. В 2022 году операционный убыток подразделения составил €2,1 млрд, сроки проектов неоднократно переносились, а позднее Volkswagen перешел к масштабному партнерству с Rivian [6].

Проблема не в том, что Volkswagen выбрал Make. Проблема в масштабе обязательств. Платформенная разработка требует значительно большей организационной зрелости, чем узкое решение под конкретный бизнес-сценарий.

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

Третий ответ: сначала изменить процесс

Значительная часть запросов на автоматизацию возникает как попытка ускорить существующий процесс.

Но ускорение не всегда означает улучшение.

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

Информационная система не устраняет организационные проблемы. Она делает их обязательными для исполнения.

Поэтому до выбора продукта нужно описать целевой процесс:

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

Хороший пример сочетания Buy и Change – внедрение MRP-планирования в Uralmine. Проект включал не только установку модуля Optimacros, но и изменение модели планирования закупок.

По опубликованным данным:

операционные запасы сократились на 18%;
оборачиваемость выросла на 10%;
потери от неликвидов уменьшились на 15%;
80% процессов планирования закупок были автоматизированы [7].

Результат был получен не только за счёт внедрения системы: одновременно компания изменила саму модель планирования закупок.

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

Четвертый ответ: отказаться

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

Но способность вовремя остановить инициативу часто является более зрелым управленческим навыком, чем способность ее запустить.

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

По оценке Gartner к концу 2027 года более 40% проектов в области агентного ИИ могут быть отменены из-за роста затрат, неясной бизнес-ценности и недостаточного контроля рисков [8].

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

Поэтому критерии остановки должны формироваться до запуска:

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

Показательный пример Stop – закрытие компанией Ford проекта FNV4. Программа предполагала создание нового поколения электронной архитектуры автомобилей, которая должна была снизить затраты, повысить качество программного обеспечения и стать основой для новых цифровых сервисов. Однако из-за роста стоимости и неоднократных задержек компания отказалась от дальнейшей разработки [9].

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

Пример позднего Stop – проект сети супермаркетов Lidl по внедрению SAP для управления товарными запасами. Компания начала трансформацию в 2011 году, но прекратила её только спустя несколько лет, когда затраты, по оценкам отраслевых источников, достигли примерно €500 млн [10]. Руководство пришло к выводу, что достижение первоначальных целей потребует ещё больших вложений, и вернулось к развитию прежней системы.

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

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

Девять вопросов перед запуском автоматизации

Модель Buy–Make–Change–Stop можно превратить в простой управленческий фильтр.

1. Какой измеримый результат должен получить бизнес?

Не функция системы, а изменение показателя: скорость, выпуск, запасы, себестоимость, качество, риск или трудоемкость.

2. Есть ли владелец результата?

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

3. Можно ли упростить или исключить часть процесса?

Иногда лучший проект автоматизации – это удаление отчета, согласования или операции.

4. Описан ли целевой процесс?

Не текущий маршрут «как есть», а способ работы после изменения.

5. Является ли процесс конкурентным преимуществом?

Типовые и регулируемые процессы чаще ведут к Buy. Уникальный бизнес-процесс может оправдать Make.

6. Что важнее: скорость запуска или степень контроля?

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

7. Какова совокупная стоимость владения – TCO – на горизонте трёх-пяти лет?

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

8. Способна ли команда владеть продуктом после запуска?

Для Make это обязательное условие. В противном случае внутренняя разработка превращается в зависимость от нескольких сотрудников.

9. При каких условиях проект будет остановлен?

Условия остановки проекта и сценарий отката должны быть согласованы до выделения бюджета.

Модель не заменяет управленческое и архитектурное суждение

Buy–Make–Change–Stop – это не универсальный алгоритм.

В регулируемых контурах – бухгалтерии, налоговом учете, расчете заработной платы – выбор часто заранее сдвинут в сторону зрелого продукта с регулярной адаптацией к изменениям регуляторных требований.

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

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

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

Вместо заключения

За последние годы ИТ-ландшафт радикально изменился. Появились генеративный ИИ, low-code, промышленный интернет вещей, новые облачные сервисы и доступные инструменты собственной разработки.

Но основной вопрос CIO остался прежним:

какой способ изменения бизнеса оправдывает вложенные ресурсы?

Иногда ответом будет покупка зрелой системы.

Иногда – собственная разработка под уникальный процесс.

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

А иногда – отказ от инициативы до того, как она начнет годами поглощать бюджет, время команды и управленческое внимание.

Классическая дилемма Make-or-Buy никуда не исчезла. Но до нее необходимо ответить еще на два вопроса:

нужно ли сначала изменить сам процесс?

и нужна ли новая система вообще?

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

Источники

[1] Project Management Institute. Maximizing Project Success, 2024.
Исследование определения и факторов успеха проектов на основе опроса почти 10 тыс. специалистов из 19 стран. Использовано для определения проектной ценности и показателей: 48% успешных проектов, 40% смешанных результатов, 12% неудачных.
https://www.pmi.org/learning/thought-leadership/project-success

[2] НИУ ВШЭ. Индикаторы цифровой экономики: 2026.
Официальная российская статистика применения ERP, CRM, PLM/PDM, складских и закупочных систем крупными и средними предприятиями обрабатывающей промышленности.
https://issek.hse.ru/mirror/pubs/share/1122445658.pdf

[3] GlobalCIO. Переход с 1С:УПП на 1С:ERP у производителя измерительных приборов.
Кейс внедрения 1С:ERP 2.5 с минимальными доработками типового функционала.
https://globalcio.ru/projectoftheyear/list/53413/

[4] Computer Weekly. Birmingham City Council’s Oracle implementation explained: What went wrong?
Материалы о внедрении Oracle ERP, стоимости проекта свыше £100 млн, дополнительных расходах на стабилизацию и ручной корректировке финансовых данных.
https://www.computerweekly.com/news/366572935/Birmingham-City-Councils-Oracle-implementation-explained-What-went-wrong

[5] GlobalCIO. Разработка и внедрение in-house CRM для фармпроизводителя.
Кейс компании «Акрихин»: собственная CRM, модели компьютерного зрения и машинного обучения, рост продаж в регионах пилота и оценка ожидаемой экономии.
https://globalcio.ru/projects/45347/

[6] Reuters. Volkswagen: Cariad unit sees €2.1 billion operating loss in 2022; Volkswagen and Rivian joint venture.
Источники о финансовых результатах Cariad, задержках программных проектов и переходе Volkswagen к масштабному партнерству с Rivian.
https://www.reuters.com/article/business/volkswagen-cariad-unit-sees-21-billion-euros-operating-loss-in-2022-idUSS8N35206U/
https://www.reuters.com/business/autos-transportation/rivian-volkswagen-group-launch-58-billion-joint-venture-2024-11-12/

[7] GlobalCIO. Первое успешное внедрение MRP-модуля на Optimacros.
Кейс Uralmine: снижение запасов на 18%, рост оборачиваемости на 10%, сокращение неликвидов на 15% и автоматизация 80% процессов планирования закупок.
https://globalcio.ru/projects/54286/

[8] Gartner. Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027.
Прогноз отмены более 40% проектов агентного ИИ из-за роста затрат, неясной бизнес-ценности и недостаточного контроля рисков.
https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027

[9] Reuters. Ford kills project to develop Tesla-like electronic brain.
Материал о прекращении проекта FNV4 из-за роста стоимости и задержек.
https://www.reuters.com/business/autos-transportation/ford-kills-project-develop-tesla-like-electronic-brain-2025-04-30/

[10] Computer Weekly. Lidl dumps €500m SAP project.
Материал о прекращении проекта SAP после многолетней реализации и затрат, оцененных отраслевыми источниками примерно в €500 млн.
https://www.computerweekly.com/news/252446965/Lidl-dumps-500m-SAP-project

423