#про_факап Кастом vs Настройка. Ввожу новую рубрику про типовые ошибки в индустрии и что с ними делать. Начнём с проблемы: когда речь идёт о БОЛЬШОМ b2b часто ИТ партнеры не могут отстоять свою точку зрения и даже крупные вендоры продуктов вынуждены соглашаться на аргументы типа: "вы не понимаете - у нас всё уникально и надо сделать как мы хотим!" К чему это приводит? Давайте смотреть на примерах: Кейс Nike: ERP в реальном секторе: В обзорах провалов ERP‑проектов часто вспоминают кейс Nike: попытка очень глубоко адаптировать планирование и цепочку поставок под свои сложные бизнес‑процессы привела к тому, что система стала крайне сложной в сопровождении и изменениях. Сильно кастомизированное решение плохо масштабировалось, было подвержено ошибкам и стало тормозом для изменений в supply chain, что в итоге вылилось в значительные убытки и необходимость масштабной переработки системы. Фактически бизнес платит дважды: сначала за “идеально подогнанную” систему, потом — за работы её снести и сделать заново ближе к стандарту. Как лечится? SAP и другие игроки рынка ERP уже давно настаивают на стандартном внедрении по BluePrint. Как итог - значительное снижение стоимости владения системой (TCO). Кейс Salesforce и крупные CRM‑ландшафты: У Salesforce другая крайность: платформа гибкая, и крупные компании легко наращивают десятки кастомных объектов, сложные триггеры, нестандартные интеграции. Аналитика по затратам показывает, что организации тратят десятки тысяч долларов на кастомизации и затем несут постоянные расходы на их поддержку, особенно из‑за трёх больших релизов Salesforce в год, каждый из которых может ломать кастомный код. Для крупных внедрений это заканчивается тем, что суммарная стоимость поддержки кастома и технического долга становится соизмерима с ценой нового проекта. Консультанты прямо приводят пример, когда кастом‑разработка на ~1 млн долларов требует до 300 тыс. долларов ежегодно только на то, чтобы поддерживать её “на плаву” после обновлений платформы. В таких ситуациях компании приходят к решению: дешевле провести ре‑дизайн и перевнедрение CRM‑ландшафта с жёстким ограничением кастомизаций, чем бесконечно чинить наследие. Как лечить? Часто крупные CRM системы разбивают на домены и типы бизнеса. Держат их относительно стандартными и не пытаются автоматизировать всё поголовно. Ну и финалочка кейсов уже про наш рынок: А мы останемся на старой версии... Довольно часто бывает так, что компании, приобретающие какой-то хороший софт отказываются от его поддержки вендором. Как пример PI System, Oracle или OIS - системы отличные и классно стабильно работают. Но рано или поздно приходит новый запрос от бизнеса и надо расширять функционал. Лично был на встречах и переговорах, когда вендор(в том случае PI System) прмяо заявлял - вам дешевле купить новый комплект лицензий, чем платить за всю поддержку, которую вы не оплачивали в прошлые периоды. В качестве заключения несколько рекомендаций: 🔹Фиксируйте границы ядра и дорожную карту. Чётко проговорите, что входит в “типовой запуск”, а что уходит в последующие фазы развития; всё новое требование должно либо вписываться в конфигурацию, либо идти в backlog “после запуска”. 🔹Переводите разговор из “хотимфичу” в “окупится ли кастом”. Для каждой доработки оценивайте: влияние на сроки, сложность поддержки/апгрейда, эффект в деньгах или KPI; показывайте заказчику, что часть пожеланий дешевле закрыть изменением процесса, чем изменением платформы, которую потом не обновить. 🔹Используйте расширения и "конфигурацию" как обязательный первый шаг. Сначала пытайтесь решить задачу конфигурацией, стандартными расширениями и интеграциями; прямой кастом ядра допускайте только после архитектурного ревью и формального согласия заказчика на рост TCO и рисков обновлений. Знаю пример нескольких продуктов, когда владельцы говорили так: вот вам продукт, вот вам ставка разработки, а дальше делайте что хотите... чем это заканчивалось через 5-7 лет? Правильно - перевнедрением :)