# HPI Pro — Full Knowledge Base Website: https://hpi.pro/ru Language: Russian (ru-RU) Hebrew edition: https://hpi.pro Contact: https://hpi.pro/ru/contact > Консалтинг, архитектура и внедрение Salesforce и CRM для компаний и организаций. ## Core pages - https://hpi.pro/ru/services - https://hpi.pro/ru/consulting-discovery - https://hpi.pro/ru/crm-architecture - https://hpi.pro/ru/salesforce-implementation - https://hpi.pro/ru/salesforce-health-check - https://hpi.pro/ru/salesforce-development-automation - CI/CD и DevOps для Salesforce: https://hpi.pro/ru/salesforce-cicd-devops - https://hpi.pro/ru/agentforce-ai - https://hpi.pro/ru/integrations-data - https://hpi.pro/ru/support - https://hpi.pro/ru/salesforce-expert-staffing - https://hpi.pro/ru/solutions - https://hpi.pro/ru/methodology - https://hpi.pro/ru/about - https://hpi.pro/ru/insights - https://hpi.pro/ru/contact --- # Knowledge Base ## Сколько стоит внедрение Salesforce в организации? Структура затрат и модель ответственной оценки URL: https://hpi.pro/ru/insights/salesforce-implementation-cost Стоимость внедрения Salesforce складывается из семи совершенно различных по своей природе компонентов — от лицензирования до интеграций и скрытых внутренних затрат. Тот, кто утверждает бюджет, ориентируясь лишь на одну цифру, обычно сталкивается с перерасходом уже на втором этапе. ## Краткий ответ Единого ответа на вопрос о стоимости внедрения Salesforce не существует. Цена формируется из семи различных компонентов: стоимость лицензий зависит от количества пользователей и уровня редакции, стоимость услуг по внедрению – от объема работ, а скрытые внутренние затраты – время работы вашей команды – вообще не включаются в коммерческое предложение поставщика. Организация, которая закладывает в бюджет только то, что прописано в договоре, сталкивается с перерасходом уже на второй месяц. Правильный подход к этому вопросу – не искать "цену внедрения Salesforce" как единое число, а построить модель оценки, которая разделяет компоненты высокой предсказуемости (лицензирование) от компонентов, зависящих от объема и сложности (внедрение, интеграции, миграция). Те, кто находится на ранней стадии выбора, найдут дополнительную информацию в статье [Выбор компании-интегратора Salesforce](/ru/insights/choose-salesforce-implementation-company), а те, кто уже сравнивает предложения, могут воспользоваться материалом о [Тендере по Salesforce RFP](/ru/insights/salesforce-rfp-guide). ## Семь компонентов стоимости Стоимость внедрения Salesforce – это не одна строка в бюджете, а семь отдельных компонентов, каждый из которых оценивается по-разному и ведет себя иначе с течением времени: 1. **Лицензирование (Licensing)** — годовая или месячная стоимость на пользователя, зависящая от редакции (Professional, Enterprise, Unlimited) и сопутствующих продуктов, таких как Sales Cloud, Service Cloud или Data Cloud. 2. **Услуги по внедрению (Implementation Services)** — работы по анализу требований, настройке, кастомизации и тестированию, как правило, оцениваются по часам или по фиксированной цене на основе определенного Scope. 3. **Интеграции** — подключение Salesforce к существующим системам (ERP, платежные системы, телефония, маркетинговые инструменты). Стоимость зависит от количества систем и сложности сопоставления данных между ними. 4. **Миграция** — очистка, сопоставление и перенос исторических данных из предыдущей системы, которая часто недооценивается, поскольку качество исходных данных не было проверено заранее. 5. **Обучение** — подготовка конечных пользователей и менеджеров. Эту статью расходов легко сократить в бюджете, но она определяет фактическую скорость адаптации. 6. **Текущая поддержка** — обслуживание, устранение неполадок, небольшие изменения и обновления версий после запуска (Go-Live). Обычно оформляется отдельным соглашением от услуг по внедрению. 7. **Скрытые внутренние затраты** — время работы команды организации: владельцев процессов, внутреннего руководителя проекта, приемочных испытаний и управления изменениями, которые не фигурируют в коммерческом предложении поставщика, но представляют собой реальный ресурс. ## Таблица факторов стоимости | Компонент | Что влияет на цену | Как сократить | Красный флаг | | --- | --- | --- | --- | | Лицензирование | Количество пользователей, редакция, сопутствующие продукты | Проверять фактическое использование перед продлением и не добавлять места "на всякий случай" | Поставщик рекомендует более дорогую редакцию без привязки к конкретной бизнес-потребности | | Услуги по внедрению | Количество процессов, сложность автоматизации, количество кастомных объектов | Начать с одного вертикального среза и постепенно расширять, вместо Big Bang | Предложение без детальной WBS по процессу или рабочему потоку | | Интеграции | Количество систем, формат данных, необходимость в Middleware | Заранее спланировать зависимости и выбрать между недорогим iPaaS и дорогим Custom API в зависимости от фактического объема | Нет определения, кто отвечает за поддержку интеграции после Go-Live | | Миграция | Объем записей, дубликаты, количество исторических источников | Провести аудит качества данных до оценки, а не после | Предложение предполагает "чистые данные" без фактической проверки | | Обучение | Количество ролей, сложность процесса, географическое распределение | Обучать по ролям и сценариям, а не общим тренингом по интерфейсу | Пункт об обучении ограничен одним двухчасовым семинаром для всей организации | | Текущая поддержка | SLA, часы доступности, объем ежемесячных изменений | Определить уровень SLA в соответствии с критичностью процесса, а не единообразно | В соглашении о поддержке нет различия между "багом" и "изменением" | | Скрытые внутренние затраты | Доступность владельцев процессов, качество приемочных испытаний, управление изменениями | Заранее выделить определенный процент от рабочего времени внутреннего руководителя проекта | Предложение предполагает, что внутренняя команда "будет доступна" без оценки трудозатрат | ## Модель оценки: диапазоны усилий, а не прайс-лист Вместо того чтобы полагаться на фиксированный прайс-лист, который быстро устаревает и варьируется между поставщиками, целесообразно мыслить в категориях диапазонов усилий (Effort Bands) для каждого компонента и переводить их в фактическую стоимость для конкретного поставщика: - **Низкий уровень усилий** — один бизнес-процесс, без сложных интеграций, менее 20 пользователей, ограниченные исторические данные. Характерно для малых B2B компаний, внедряющих базовый Sales Cloud. - **Средний уровень усилий** — от двух до четырех бизнес-процессов, от одной до трех интеграций с существующими системами, 20-100 пользователей, миграция из предыдущей CRM-системы. Это наиболее распространенный диапазон на российском рынке. - **Высокий уровень усилий** — множество бизнес-юнитов или стран, многочисленные интеграции с устаревшими системами, сложная модель разрешений, более 100 пользователей, специфические отраслевые требования по Compliance. Для каждого диапазона усилий необходимо выполнять отдельную оценку каждого из семи компонентов, не предполагая, что все компоненты растут пропорционально. Интеграции, например, могут резко перейти от низкого до высокого уровня усилий даже в относительно небольшом проекте, если существующая система не предоставляет корректное API. ## Как перевести диапазон усилий в реальное коммерческое предложение После определения ожидаемого диапазона усилий следующим шагом является запрос у не менее чем трех поставщиков детализации часов по компонентам, а не просто общей суммы. Такая детализация дает организации возможность реального сравнения: мы подробно рассмотрели это в статье [Консалтинг Salesforce](/ru/insights/salesforce-consulting-guide), где также объясняется, как выявить предложение, искусственно сокращающее этап тестирования, чтобы выглядеть дешевле. ### Три типовых ценовых сценария **Сценарий А – Небольшое первоначальное внедрение**: один процесс продаж, без интеграции, 10-15 пользователей. Большая часть затрат сосредоточена на услугах по внедрению и обучении; лицензирование и текущая поддержка составляют относительно небольшой процент в первый год. **Сценарий Б – Замена существующей CRM-системы**: миграция тысяч записей, 40-60 пользователей, одна интеграция с бухгалтерской системой. Здесь миграция и интеграции могут составлять до трети общего бюджета, и именно этот компонент часто недооценивается на начальных этапах. **Сценарий В – Многолетнее расширение для крупной организации**: несколько бизнес-юнитов, Salesforce уже существует, требуется добавить Service Cloud или Data Cloud. Скрытые внутренние затраты – время владельцев процессов и IT-менеджеров – становятся наиболее значимым компонентом, иногда превышающим стоимость лицензий. ## Пример организационного сценария Предположим, многопрофильный производитель запрашивает предложения от трех интеграторов на внедрение Salesforce. Самое дешевое предложение на 35 процентов ниже остальных, но при проверке выясняется, что оно включает всего 40 часов на миграцию, хотя у организации около 60 тысяч исторических клиентских записей в старой системе с многочисленными дубликатами. Команда просит поставщика детализировать рабочие допущения и обнаруживает, что предложение основано на предположении о "чистых и готовых к переносу данных" – предположении, не проверенном на практике. Организация решает провести краткий аудит качества данных перед подписанием контракта. Аудит показывает, что 18 процентов записей дублируются, а у 30 процентов отсутствуют обязательные поля, необходимые для нового процесса. В результате организация просит всех трех поставщиков пересчитать стоимость этапа миграции на основе полученных данных и добавляет в контракт пункт, разделяющий стоимость одноразовой миграции и текущей поддержки качества данных – как подробно описано в статье [SOW проекта Salesforce](/insights/salesforce-sow-contract-clauses]. Результат: выбранное в итоге предложение не было самым дешевым, но оказалось единственным, которое включало все семь компонентов стоимости в реальной детализации, включая оценку внутренних трудозатрат самой организации. Изменение такого порядка – сначала определить реальные затраты, а затем сравнивать предложения – позволило избежать перерасхода бюджета примерно на 25 процентов, который был бы обнаружен только на четвертый месяц у одного из конкурентов, выбравших дешевое предложение. ## Распространенные риски и превентивные меры | Риск | Как проявляется на практике | Превентивная мера | | --- | --- | --- | | Слишком "округлое" коммерческое предложение | Одна общая сумма без детализации по компонентам | Требовать разбивки часов и стоимости для каждого из семи компонентов | | Игнорирование внутренних затрат | Организация не закладывает в бюджет время на внутреннее управление и приемочные испытания | Заранее оценить внутренние человеко-часы отдельно от стоимости поставщика | | Недооцененная миграция | Предположение, что "данные в порядке" без проверки | Провести аудит качества данных до окончательной оценки | | Обучение как второстепенный пункт | Бюджет на обучение ограничен одним днем для всей организации | Планировать обучение по ролям и фактическим сценариям | | Поддержка без определения SLA | Нечеткий договор поддержки относительно времени реакции и устранения проблем | Определить многоуровневый SLA в соответствии с критичностью, и соответствующим образом оценить его | На уровне управления бюджетом внедрения Salesforce эта таблица является отправной точкой, а не закрытым списком. Для генеральных директоров, отдела закупок и ИТ-директоров целесообразно обновлять ее при каждом цикле коммерческих предложений и проверять, какие риски реализовались в предыдущих проектах в той же отрасли, прежде чем утверждать окончательный бюджет. ## Как проверить обоснованность оценки | Область проверки | Что проверяется | Частота проверки | | --- | --- | --- | | Соответствие лицензий использованию | Процент активных пользователей по отношению к количеству приобретенных лицензий | Ежеквартально | | Перерасход услуг по внедрению | Отклонение фактических часов от заявленных в предложении | На каждом этапе | | Нагрузка на интеграцию | Частота сбоев или задержек в передаче данных между системами | Ежемесячно | | Качество миграции | Процент записей с ошибками или дубликатами после переноса | Единовременно после Go-Live | | Стоимость поддержки по отношению к SLA | Соответствует ли фактическое время реакции оплаченному | Ежемесячно | Для ответственной оценки бюджета рекомендуется выбрать всего три-пять показателей из таблицы для постоянного мониторинга в первый год. Хороший показатель может быть рассчитан до и после подписания контракта, что позволяет сравнивать обещанное с фактическими результатами – вместо того, чтобы просто полагаться на ощущение, что проект "прошел хорошо". Фактическое применение модели оценки можно реализовать через [услуги консалтинга и анализа требований](/ru/consulting-discovery). ## Контрольный список перед утверждением бюджета - ☐ Каждый из семи компонентов стоимости оценен отдельно, а не одной общей суммой - ☐ Проведен аудит качества данных перед оценкой стоимости миграции - ☐ Определен диапазон усилий (низкий, средний, высокий) перед запросом коммерческих предложений - ☐ Оценены внутренние трудозатраты отдельно от стоимости поставщика - ☐ Бюджет на обучение детализирован по ролям, а не как общий пункт - ☐ Определены четкие SLA для соглашения о текущей поддержке - ☐ Предусмотрен резерв в 10-20 процентов на изменение объема работ - ☐ Не менее трех поставщиков детализировали часы по компонентам, а не только общую сумму - ☐ Проверена стоимость лицензий на 24-36 месяцев, а не только на первый год - ☐ Определены показатели проверки после Go-Live, а не только критерий "система запущена" ## Профессиональные ресурсы - HPI Pro – Консалтинг и анализ требований — https://hpi.pro/consulting-discovery - Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html - HPI Pro – Услуги Salesforce — https://hpi.pro/services ### Вопросы и ответы **Почему два предложения по внедрению Salesforce могут отличаться вдвое?** Чаще всего речь идет о разном объеме работ, а не о «скидке». Более дешевое предложение может не включать нагрузочное тестирование, миграцию исторических данных или обучение конечных пользователей, которые будут добавлены в счет после подписания договора. Сравнивать следует по одинаковой структуре работ (WBS) и допущениям, а не по итоговой цифре. **Стоит ли платить за премиум-лицензии, чтобы сэкономить на стоимости внедрения?** Иногда да: лицензия со встроенными возможностями Flow и Automation может сэкономить затраты на кастомизированную разработку. Но это не универсальная формула — стоимость лицензий на три года иногда превышает экономию на внедрении. Рекомендуется рассчитывать общую стоимость за 24-36 месяцев, а не только однократную стоимость внедрения. **Какую часть бюджета следует зарезервировать на изменения в ходе проекта?** В средних и крупных проектах принято резервировать 10-15 процентов от стоимости услуг по реализации на непредвиденные изменения объема работ. Если организация также проходит через значительные изменения процессов, а не только их оцифровку, рекомендуется увеличить резерв до 20 процентов. **В чем разница между однократной стоимостью миграции и стоимостью текущего обслуживания данных?** Миграция — это ограниченный по времени проект: очистка, сопоставление и однократный перенос данных. Обслуживание данных — это непрерывный процесс: дедупликация, контроль качества и обновление прав доступа. Организации, которые бюджетируют только миграцию, через год обнаруживают, что качество данных снова ухудшилось. **Как определить, что коммерческое предложение скрывает внутренние издержки?** Если в предложении не указано, сколько часов внутреннего управления, приемочных испытаний и участия владельцев процессов потребуется от вашей команды, вероятно, эти затраты существуют, но не были учтены. Рекомендуется запросить оценку внутренних человеко-часов отдельно от стоимости услуг поставщика. --- ## Как выбрать компанию для внедрения Salesforce? Профессиональное руководство по принятию решения URL: https://hpi.pro/ru/insights/choose-salesforce-implementation-company Выбор компании для внедрения Salesforce часто колеблется между двумя крайностями: впечатляющая демонстрация или исключительно сравнение цен. Правильный процесс выбора включает глубокую оценку профессионализма, проверку реальных рекомендаций и анализ модели сотрудничества — прежде чем смотреть на цифру в конце предложения. ## Краткий ответ Выбор компании-интегратора Salesforce обычно сводится к одному из двух рискованных сценариев: либо под впечатлением от эффектной демонстрации на совещании по продажам, либо исключительно по ценовому сравнению предложений, которые на бумаге выглядят похожими. Ни один из этих подходов не позволяет оценить то, что на самом деле определяет успех — понимает ли поставщик бизнес-процессы, как он справляется с исключительными ситуациями и что происходит, когда что-то идет не так на третьей неделе проекта. Продуманный процесс выбора предусматривает последовательную оценку четырех ключевых аспектов: определение внутренних потребностей до выхода на рынок, выбор типа поставщика, соответствующего масштабу и риску, глубокая профессиональная проверка за пределами демонстраций, а также модель взаимодействия, справедливо распределяющая риски. Подробное описание критериев для сравнения ценовых предложений и условий мы приводили в статье [Сравнение предложений Salesforce](/ru/insights/compare-salesforce-proposals), а здесь мы сосредоточимся на предшествующем этапе — как вообще сформировать достойный список кандидатов. ## Шаг первый: Что необходимо перед выходом на рынок Наиболее распространенная ошибка — обращаться к поставщикам с вопросом "сколько это стоит" до того, как определено, что именно нужно. Компания, которая начинает процесс закупки без четко задокументированного объема работ (Scope), получает предложения, которые невозможно сравнить, поскольку каждый поставщик восполняет пробелы собственными предположениями. До первой встречи рекомендуется иметь краткий документ, содержащий: бизнес-процесс, требующий изменений; кто будет пользователями системы; какие существующие системы используются сегодня; и что будет считаться успехом через полгода. Этот объем потребностей напрямую определяет и подходящую модель ценообразования. Проект с четким Scope лучше подходит для фиксированной цены, тогда как исследовательский проект — для модели Time & Material. Мы подробно освещали это в статье [Модели ценообразования проектов Salesforce](/ru/insights/salesforce-project-pricing-models). Организация, пропускающая этап определения, почти всегда платит дважды: сначала за завышенное предложение, покрывающее неопределенность, а затем за изменения Scope в процессе работы. ## Типы поставщиков: Бутик, Глобальный и Фриланс Рынок услуг Salesforce в России условно делится на три категории, каждая из которых подходит для определенного профиля риска. **Бутиковые компании** обычно насчитывают от 5 до 30 сотрудников, специализируются на одной или двух областях (продажи, обслуживание, Marketing Cloud) и обеспечивают прямой доступ к старшему архитектору на протяжении всего проекта. Преимущества — оперативность и конкурентоспособная цена; недостаток — ограниченная пропускная способность, большой проект, требующий одновременной работы пяти специалистов, может столкнуться с задержками. **Глобальные интеграторы** предлагают задокументированную методологию, возможность быстрого привлечения дополнительного персонала и опыт работы в аналогичных секторах по всему миру. Цена на 30–60 процентов выше, чем у бутиковых компаний, и часто присутствует уровень управления проектом, который разделяет клиента и фактическую команду исполнителей, что замедляет коммуникацию в случае кризиса. **Фрилансеры** предлагают самую низкую почасовую ставку, но создают зависимость от одного человека. Если фрилансер заболевает, уезжает за границу или переходит на другой проект, работа останавливается. Подходит в основном для текущего обслуживания или для небольших проектов с четко определенным и закрытым Scope. ## Глубокая профессиональная проверка за пределами демонстраций Впечатляющая демонстрация (демо) доказывает, что поставщик умеет представлять Salesforce, но не то, что он способен решить специфическую проблему организации. Глубокая проверка требует трех уровней: во-первых, попросить, чтобы команда, которая будет выполнять проект (а не только менеджер по продажам), присутствовала на встрече и отвечала на технические вопросы. Во-вторых, запросить конкретный пример аналогичного по объему и отрасли проекта, включая реальные скриншоты, а не маркетинговые слайды. В-третьих, проверить, как поставщик реагирует на "подводный" вопрос, например: "Что произойдет, если в середине проекта выяснится, что исходные данные недостоверны?" Опытный поставщик ответит на примерах, а не общими фразами. Архитектура, реализуемая на практике, определяет качество решения гораздо больше, чем логотип на счете. Важно убедиться, что архитектор, представленный на встрече по продажам, действительно будет участвовать в проекте, а не является "лицом", демонстрируемым клиентам, которое после подписания контракта заменяется менее опытным сотрудником. ## Проверка реальных рекомендаций Хороший разговор с рекомендателями не ограничивается вопросом "стали бы вы рекомендовать?". Он углубляется в операционные детали. Три вопроса, которые дают реальную информацию: был ли проект завершен в рамках исходного бюджета и сроков, и если нет, то каково отклонение и причина; что произошло, когда в результате развертывания была обнаружена ошибка или баг, и сколько времени потребовалось на исправление; работает ли команда, выполнявшая проект, у поставщика сегодня. Высокая текучесть кадров в компании-интеграторе — признак того, что накопленные знания по предыдущему проекту уже недоступны. Рекомендуется запросить как минимум две рекомендации: одну по успешно завершенному проекту и одну по проекту, столкнувшемуся с трудностями. Поставщик, который отказывается предоставить "проблемного" рекомендателя или утверждает, что все его проекты были безупречно успешными, что-то скрывает. ## Модель взаимодействия: Как распределить риск Модель взаимодействия определяет, кто несет риск, когда реальность отклоняется от плана, — а это происходит почти всегда. | Модель | Когда подходит | Основной риск | | --- | --- | --- | | Time & Material (без лимита) | Незрелый Scope, этап Discovery | Превышение часов без верхнего предела | | T&M с лимитом (Cap) | Частичный Scope, первый проект с поставщиком | Требует постоянного контроля над лимитом | | Фиксированная цена | Четко задокументированный Scope | Поставщик может сокращать затраты в ущерб качеству для сохранения маржи | | Ежемесячный ретейнер | Текущее обслуживание и поддержка | Фактический объем работ не всегда соответствует оплате | Для первого проекта с новым поставщиком модель T&M с лимитом часто является наиболее сбалансированным выбором: она предотвращает бюджетные сюрпризы, но не стимулирует поставщика экономить на тестировании. Переход к фиксированной цене стоит рассматривать только после того, как Scope был проверен на реальных сквозных сценариях, как описано в [Выбор поставщика Salesforce](/ru/insights/salesforce-vendor-scorecard). ## Scorecard для оценки поставщиков Взвешенная таблица баллов превращает субъективное сравнение в процесс, который можно аргументировать перед руководством. Предлагаемые веса для типового проекта: | Критерий | Вес | Что фактически проверяется | | --- | --- | --- | | Соответствие опыта отрасли и процессу | 25% | Аналогичные проекты по объему и сектору, а не просто известный логотип | | Глубина предложенной команды | 20% | Опыт и фактическая роль архитектора и разработчиков | | Качество ценового предложения и Scope | 20% | Детализация WBS, допущения, исключения и письменные результаты приемки | | Рекомендации и текучесть кадров | 15% | Прямые разговоры с предыдущими клиентами | | Модель взаимодействия и справедливость контракта | 10% | Разумное распределение рисков, а не просто низкая цена | | Культурная совместимость и доступность коммуникации | 10% | Скорость ответа, язык, часовой пояс и частота обновлений | Каждый поставщик получает оценку от 1 до 5 по каждой строке, умноженную на вес. Разрыв между ведущим поставщиком и вторым по общему результату не менее важен, чем сама оценка, — разница менее 5 баллов обычно оправдывает дополнительную проясняющую встречу перед окончательным решением. ## Красные флаги, которые стоит выявить на ранней стадии - Ценовое предложение без детализации часов по задачам, только общая "итоговая" сумма. - Обещание "полного решения на Salesforce" для потребности, которая никогда не исследовалась глубоко. - Отказ раскрыть, кто именно в команде будет выполнять работу. - Давление с целью быстрого подписания "потому что эта цена действует только на этой неделе". - Нет ссылок на неудачные случаи или проекты, столкнувшиеся с трудностями. - Контракт, который не определяет, что считается "завершением" проекта и окончательной приемкой. ## Что просить показать на встрече: Краткий контрольный список - ☐ Присутствие фактической команды исполнителей, а не только менеджера по продажам. - ☐ Конкретный пример аналогичного проекта с реальными скриншотами. - ☐ Предварительная детализация WBS с письменными допущениями и исключениями. - ☐ Имя и контактные данные как минимум двух рекомендателей. - ☐ Предложение по модели взаимодействия с объяснением, почему она подходит для данного объема. - ☐ Описание процесса обработки изменений Scope и ошибок после запуска системы. ## Пример организационного сценария Средняя финансовая сервисная компания рассмотрела три предложения на внедрение Salesforce Sales Cloud: местный бутик, глобального интегратора и рекомендованного фрилансера. Руководство изначально склонялось к фрилансеру из-за цены, которая была на 40 процентов ниже, пока разговор с рекомендателями не выявил, что его предыдущий проект был остановлен на три недели, когда он заболел. В конечном итоге компания выбрала бутик после того, как Scorecard показал преимущество в 12 баллов в категории глубины команды и низкой текучести кадров. Проект действительно столкнулся с изменением требований в середине процесса — новой потребностью в интеграции с внутренней биллинговой системой, которая не упоминалась на этапе предложения. Благодаря модели T&M с лимитом, изменение было обработано как заранее согласованное дополнение, а не как повторные переговоры по всему контракту. Организации, колеблющиеся между похожими поставщиками и нуждающиеся в дополнительной структуре вопросов, могут воспользоваться [Выбор интегратора Salesforce](/ru/insights/questions-before-choosing-salesforce-integrator). ## Как измерить правильность выбора | Показатель | Что проверяется | Когда проверяется | | --- | --- | --- | | Соблюдение графика | Отклонение в днях между планом и фактическим выполнением | На каждом этапе | | Стабильность команды | Сопровождали ли проект одни и те же люди до конца | По завершении каждого этапа | | Обработка исключений | Время отклика на ошибки или изменения требований | В течение всего проекта | | Качество документации | Можно ли передать поддержку другой команде без зависимости от человека | При передаче | Показатель, который нельзя проверить на практике, не является показателем. Если контракт не включает четкого определения того, что считается "завершением" проекта, практически невозможно узнать, был ли выбор правильным, пока не станет слишком поздно что-либо исправлять. Организациям, желающим получить внешнюю консультацию по построению процесса выбора, рекомендуется начать с [Услуги консалтинга и анализа](/ru/consulting-discovery), которая помогает определить Scope и разработать адаптированную Scorecard еще до выхода на рынок. ## Профессиональные ресурсы - HPI Pro – Консалтинг и анализ — https://hpi.pro/consulting-discovery - Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html - HPI Pro – Услуги Salesforce — https://hpi.pro/services ### Вопросы и ответы **В чем практическая разница между бутиковой компанией и глобальным интегратором в проекте Salesforce?** Бутиковая компания обычно обеспечивает прямой доступ к архитектору и старшему разработчику, короткие циклы разработки и более низкую почасовую ставку, но имеет ограниченные возможности для крупных проектов. Глобальный интегратор предоставляет отлаженную методологию и масштабируемость, но по более высокой цене и часто с дополнительными уровнями управления между клиентом и непосредственным исполнителем. **Сколько обычно стоит нанять фрилансера Salesforce по сравнению с компанией?** Хороший фрилансер оценивается примерно в 250-450 шекелей в час без накладных расходов на управление, однако это подвергает организацию риску зависимости от одного человека. Компания взимает в среднем на 20-40 процентов больше, но обеспечивает резервное копирование, профессиональное страхование и непрерывность работы, даже если сотрудник покинет проект в процессе. **Какие вопросы стоит задать рекомендованным компаниям-интеграторам перед подписанием контракта?** Спросите о фактическом соблюдении сроков по сравнению с запланированными, качестве полученной документации, поведении поставщика при возникновении ошибок и о том, работает ли команда, выполнявшая проект, по-прежнему в компании. Уклончивый ответ на любой из этих вопросов является серьезным предупреждающим знаком. **Какая модель взаимодействия рекомендуется для первого проекта Salesforce в организации?** Для первого этапа обычно рекомендуется модель Time & Material с ограничением (Cap), а к фиксированной цене переходить только после того, как объем работ стабилизируется вокруг определенных сквозных сценариев. Фиксированная цена при неясном объеме работ побуждает поставщика экономить ресурсы, чтобы защитить свою прибыльность. **Каков минимальный размер команды поставщика, необходимой для среднего проекта Salesforce?** Для проекта продолжительностью 3-6 месяцев рекомендуется убедиться, что есть как минимум два человека с достаточными знаниями для взаимозаменяемости: архитектор или руководитель проекта и дополнительный разработчик. Команда из одного человека хорошо работает до тех пор, пока он не заболеет, не уйдет в отпуск или не уволится. --- ## Сколько длится проект Salesforce? Сроки, зависимости и что на самом деле замедляет процесс URL: https://hpi.pro/ru/insights/salesforce-project-timeline Средний проект Salesforce длится от шести недель до девяти месяцев, но диапазон дат в предложении почти никогда не зависит от объема разработки — он определяется скоростью принятия решений, готовностью данных и доступностью специалистов в организации. ## Краткий ответ Единого ответа на вопрос о длительности проекта Salesforce не существует, однако есть реальные диапазоны, с которыми стоит ознакомиться до подписания коммерческого предложения. Целевой проект "быстрой победы" (Quick Win) — одна автоматизация, настраиваемый объект (Object), расширенный отчет — иногда завершается за 3-4 недели. Полноценное внедрение Sales Cloud для средней группы продаж занимает от 8 до 14 недель. Проект с несколькими облаками (Multi-Cloud) и интеграциями с ERP и внешними системами может длиться 6-9 месяцев, а иногда и дольше, если задействовано несколько бизнес-подразделений. Фактический диапазон определяется не объемом кода, а темпом принятия решений в организации: кто является владельцем (Owner) каждого процесса, сколько времени требуется на утверждение объема работ (Scope) и когда данные действительно готовы к тестированию. Прежде чем устанавливать дату запуска (Go Live), рекомендуется ознакомиться с полным руководством по [внедрению Salesforce в организации](/ru/insights/salesforce-implementation-guide), где подробно описаны этапы работы, стоящие за каждой неделей в графике. ## Почему сроки так сильно варьируются между, казалось бы, похожими проектами Две организации, заказывающие "внедрение Sales Cloud для отдела продаж из 20 человек", могут получить коммерческие предложения со сроками выполнения, отличающимися в три раза, и оба предложения могут быть корректными. Разница почти всегда объясняется тем, что не указано в документе требований: сколько существует источников данных, насколько сложны внутренние процессы утверждения, и как быстро организация принимает решения, касающиеся более чем одного отдела. Проект с единственным владельцем продукта (Product Owner), имеющим полномочия на утверждение Scope, продвигается значительно быстрее, чем проект, где каждое изменение требует одобрения руководящего комитета. Это не техническое отличие — это организационное отличие, которое напрямую влияет на график, иногда больше, чем любое архитектурное решение. ## Сроки выполнения по типу проекта В следующей таблице представлены оценки фактических рабочих недель (Elapsed time, а не Effort) по этапам и типам проектов. Это усредненные диапазоны из практики, а не обязательства — каждый конкретный проект требует отдельной оценки. | Этап | Quick Win / Точечное дополнение | Стандартное внедрение (Single Cloud) | Multi-Cloud проект с интеграциями | | --- | --- | --- | --- | | Исследование и спецификация (Discovery & Design) | 3-5 дней | 1.5-3 недели | 3-6 недель | | Архитектура и модель данных | 2-3 дня | 1-2 недели | 3-5 недель | | Разработка и настройка | 1-2 недели | 3-6 недель | 8-16 недель | | Миграция данных | Обычно не требуется | 1-2 недели | 3-6 недель | | Интеграции | Обычно не требуется | 1-3 недели | 4-10 недель | | UAT и исправления | 2-4 дня | 2-3 недели | 3-5 недель | | Запуск (Go Live) и поддержка (Hypercare) | 2-3 дня | 1-2 недели | 2-4 недели | | **Общая продолжительность** | **3-4 недели** | **8-14 недель** | **24-40 недель** | Важно помнить, что цифры в таблице предполагают разумную доступность заинтересованных сторон и данных в разумном объеме. Любое из этих предположений, если оно не выполняется, может добавить недели к каждому этапу. ## Что на самом деле задерживает проекты — не то, что кажется Когда проект Salesforce выходит за рамки графика, наиболее распространенной причиной является не техническая сложность, а один из пяти факторов: - **Зависимые решения, которые не принимаются вовремя** — бизнес-вопрос, остающийся открытым две недели из-за отсутствия уполномоченного лица, в то время как техническая команда ожидает ответа. - **Данные, которые на самом деле не готовы** — источник данных, который считался "существующим и готовым", оказывается содержащим дубликаты, отсутствующие поля или противоречивые данные из двух источников. - **Доступность контент-менеджеров и владельцев процессов** — менеджеры по продажам или обслуживанию, которые должны проверять и утверждать, заняты текущей работой и не освобождены заранее. - **Интеграции со сторонними системами** — зависимость от внешнего поставщика, от API с ограничениями или от внутренней ИТ-команды, которая работает в другом темпе. - **Протяженное UAT** — тестирование начинается только тогда, когда система "почти готова", а не параллельно с разработкой. Из всех этих факторов, зависимые решения — это то, что легче всего предотвратить и что наиболее распространено на практике. Организация, которая заранее определяет, кто и что утверждает, и за сколько дней ответ считается "задержкой", экономит в среднем две-три недели в среднем проекте. Эта тема подробно обсуждается также в [MVP Salesforce](/ru/insights/salesforce-mvp-scope), где объясняется, как сократить количество зависимых решений с самого начала, ограничивая объем первой, более небольшой версии. ## Критический путь: что определяет конечную дату В каждом проекте существует одна цепочка действий, которая определяет минимальную дату завершения — это критический путь. В типичном проекте Salesforce критический путь почти всегда проходит через три "узких места": 1. **Утверждение модели данных и разрешений** — пока это не закрыто, невозможно с уверенностью начать интеграцию или миграцию. 2. **Готовность источника данных к миграции** — даже если разработка завершена, невозможно запустить систему в эксплуатацию без чистых и проверенных данных. 3. **Доступность владельцев процессов для UAT** — это, как правило, самое узкое место, потому что речь идет о людях с полной занятостью в организации, а не о времени проектной команды. Недельная задержка в одном из этих пунктов напрямую переносится на дату Go Live, даже если вся остальная команда соблюдает сроки. Поэтому хороший PMO особенно внимательно следит за элементами критического пути, а не только за общим процентом завершения проекта. Эта идея находит практическое применение в процессе [UAT для Salesforce](/ru/insights/salesforce-uat-guide), где подробно описывается, как планировать этап тестирования, чтобы он сам не стал еще одним узким местом. ## Phased против Big Bang: как выбор влияет на график Вопрос о том, запускать ли систему в эксплуатацию одним этапом (Big Bang) или поэтапно (Phased) является одним из самых значимых решений, влияющих на график, и не только на операционный риск. **Big Bang** подходит, когда объем относительно невелик, когда существует тесная зависимость между компонентами (например, единый процесс Lead-to-Cash, который невозможно разделить), и когда организация предпочитает сосредоточенные временные затраты длительному переходному периоду. Преимущество в графике: одна четкая конечная дата. Недостаток: любая задержка в одном компоненте сдвигает всю дату. **Phased** подходит, когда объем широк, когда есть несколько подразделений или процессов, которые можно разделить, и когда организация хочет получить раннюю ценность и учиться на первой фазе перед переходом к следующей. Преимущество: первая фаза выходит в эксплуатацию быстрее, и уроки применяются в следующих фазах. Недостаток: общая продолжительность дольше и иногда более высокие затраты на координацию между фазами. В целом, если проект, как ожидается, превысит 4 месяца или включает более двух независимых департаментов, поэтапный подход (Phased) почти всегда сокращает время до получения первой бизнес-ценности, даже если общая продолжительность проекта аналогична или дольше. ## Как сократить график без ущерба качеству Существуют реальные способы сокращения сроков и есть "быстрые решения", которые кажутся экономией времени, но на самом деле лишь откладывают затраты на этап поддержки (Hypercare) или на следующий год. **Что действительно сокращает сроки:** - Жесткое ограничение объема работ (Scope) для первой версии, с четким и заранее утвержденным списком "не сейчас". - Назначение единого владельца продукта (Product Owner) с реальными полномочиями утверждать или отклонять, чтобы устранить задержки, связанные с комитетами. - Начало работы по очистке данных параллельно с этапом проектирования, а не после него. - Выделение времени в календаре владельцев процессов для UAT заранее, а не по наступлении этапа. - Использование стандартных компонентов Salesforce вместо заказной разработки везде, где это возможно. **Что выглядит как сокращение, но на самом деле таковым не является:** - Пропуск полного UAT и переход напрямую к "тестированию разработчиками" — экономит неделю и приводит к месяцу исправлений в продакшене. - Миграция данных без очистки, с намерением "очистить потом" — грязные данные становятся проблемой адаптации. - Сжатие обучения в один день перед Go Live — приводит к обходу системы в первые недели. Когда речь идет о проекте, где сроки действительно критичны для бизнеса, профессиональное сопровождение через [услугу по внедрению Salesforce](/ru/salesforce-implementation) сосредоточено именно на такой комбинации — какие сокращения безопасны, а какие лишь откладывают затраты на будущее. ## Пример организационного сценария Логистическая компания планировала внедрение Service Cloud за 10 недель, чтобы успеть до пикового сезона. На второй неделе выяснилось, что существующая ERP-система не готова предоставить стабильный API, а внутренняя ИТ-команда доступна для проекта только на неполный рабочий день. Вместо того чтобы продвигать весь проект вперед, команда перешла на поэтапный подход (Phased): первая фаза включала базовую маршрутизацию запросов и SLA, без интеграции с ERP, и была запущена в течение 7 недель — за три недели до сезона. Полная интеграция была отложена до второй фазы, которая выполнялась параллельно с пиковым сезоном и была запущена два месяца спустя. Главный вывод: когда обнаруживается реальное препятствие на критическом пути, правильный вопрос не "как сократить оставшееся время", а "что можно выделить в отдельную фазу без ущерба для немедленной ценности". Планирование Hypercare после каждой такой фазы подробно описано в [Salesforce Hypercare](/ru/insights/salesforce-hypercare-plan), где показано, как стабилизировать каждую фазу, прежде чем переходить к следующей. ## Чек-лист для планирования реалистичного графика - ☐ Определен закрытый Scope для первой версии, включая список "не сейчас". - ☐ Назначен единый Product Owner с полномочиями утверждать. - ☐ Проверено качество исходных данных, а не просто предположение, что они "готовы". - ☐ Владельцы процессов заранее освобождены для запланированного UAT. - ☐ Интеграции со сторонними системами проверены на API и доступность поставщика. - ☐ Явно принято решение: Phased или Big Bang, и почему. - ☐ Критический путь идентифицирован и отслеживается отдельно от общего процента завершения. - ☐ В график встроен буфер в 10-15%, а не обещание "все в срок". - ☐ Конечные пользователи обучены до Go Live, а не за день до него. - ☐ План Hypercare определен заранее с критерием выхода. ## Профессиональные ресурсы - Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html - HPI Pro – Внедрение Salesforce — https://hpi.pro/salesforce-implementation - HPI Pro – Методология работы — https://hpi.pro/methodology ### Вопросы и ответы **В чем разница в продолжительности проекта между базовым Sales Cloud и Service Cloud с интеграциями?** Базовый Sales Cloud для одной команды продаж без сложных интеграций обычно завершается за 6-10 недель. Service Cloud с маршрутизацией, SLA и 2-3 интеграциями (ERP, телефония, биллинговая система) обычно требует 12-20 недель из-за более сложного картирования сервисных процессов и разрешений. **Сколько времени фактически занимает этап работы с данными от общего графика?** В проектах с одним чистым источником данных очистка и миграция занимают около 10% от общего времени. Если есть два и более источников с дубликатами, доля возрастает до 25-30%, так как каждый раунд проверки качества выявляет новые аномалии, требующие бизнес-решения, а не просто технической корректировки. **Предпочтительнее ли заранее установленный график или оценка, которая обновляется по ходу дела?** Зафиксированный график целесообразен только тогда, когда объем работ (Scope) полностью определен и нет зависимости от внешних интеграций. В большинстве проектов указывается диапазон (например, 10-14 недель), который обновляется в конце каждого спринта, поскольку слишком ранняя фиксация обычно приводит к скрытым отклонениям в дальнейшем, а не к реальному соблюдению цели. **Что происходит с графиком, когда в середине проекта обнаруживается потребность в незапланированной интеграции?** В проекте, реализуемом поэтапным подходом (Phased), интеграцию можно отложить до следующего этапа, не останавливая остальную работу, обычно это добавляет 2-4 недели к отдельному этапу. При подходе «Большого взрыва» (Big Bang) такое открытие, как правило, останавливает весь процесс, поскольку все компоненты должны быть запущены одновременно. **Сколько времени нужно отводить на UAT, чтобы оно не стало узким местом проекта?** Для среднего проекта рекомендуется выделять 2-3 недели на UAT, включая один раунд исправлений. Распространенная проблема — это не продолжительность самого UAT, а доступность владельцев процессов. Если они заранее не освобождены от текущей работы, этап, который должен занять две недели, растягивается на полтора месяца. --- ## Внедрение Salesforce в крупной компании: принципы, управление и риски URL: https://hpi.pro/ru/insights/enterprise-salesforce-implementation При более чем 500 пользователях вопрос уже не в том, «как строить», а в том, кто принимает решения, кто утверждает изменения и как координировать параллельные инициативы. В статье представлена модель управления, выбор между Single-org и Multi-org, а также типичные сценарии сбоев. ## Краткий ответ В организациях с десятками пользователей внедрение Salesforce в основном сводится к конфигурации и адаптации. В организациях со 500+ пользователями, охватывающих несколько бизнес-единиц, а иногда и несколько стран, основной акцент смещается: кто утверждает изменения, как параллельные команды избегают конфликтов, и поддерживает ли структура Org дальнейший рост или препятствует ему. Без надлежащего управления любое точечное улучшение превращается в риск для стабильности всей организации. Эта статья посвящена уровню управления, который находится над отдельным проектом: структуре принятия решений, выбору между Single-org и несколькими отдельными организациями, координации релизов, безопасности и регулированию, глобальной локализации и взаимозависимости параллельных программ в PMO. Полный обзор основных этапов внедрения представлен в статье [Внедрение Salesforce в организации](/ru/insights/salesforce-implementation-guide), а данная статья развивает эту тему на уровне корпоративного масштаба. ## Почему масштаб меняет правила игры В проекте на 50 пользователей изменения можно управлять посредством беседы между двумя людьми. В случае 500+ пользователей обычно уже работают несколько команд разработки, несколько бизнес-единиц с разными приоритетами, а иногда и несколько поставщиков решений. Незначительное изменение в общем объекте — добавление обязательного поля, изменение правила валидации — может нарушить процесс в другом подразделении, которое не было осведомлено об изменении. Поэтому в корпоративном масштабе три вопроса предшествуют любому техническому обсуждению: кто является владельцем каждого объекта и центрального процесса, какой механизм проверяет кросс-командное влияние перед развертыванием, и кто уполномочен остановить релиз в случае обнаружения риска. Организации, которые игнорируют эти вопросы, вначале строят "быстро", а затем расплачиваются частыми остановками и незапланированными откатами через год-два. ## Управление и Совет по изменениям (Change Advisory Board) Совет по изменениям (CAB) — это не бюрократический комитет, а механизм, предотвращающий ситуацию, когда изменение, кажущееся незначительным для одной единицы, наносит ущерб другой. Рекомендуемая структура включает три уровня утверждения: рутинное изменение конфигурации (низкий риск), которое утверждается на уровне команды; изменение, влияющее на общую модель данных или интеграцию (средний риск), которое рассматривается еженедельным CAB; и архитектурное изменение (например, изменение модели совместного доступа или переход на Multi-org), требующее утверждения управляющим комитетом на уровне CIO. На практике самый эффективный CAB, который мы наблюдали, — это не тот, который обладает наибольшей документальной прозрачностью, а тот, в котором есть четкое SLA: запрос на изменение среднего риска получает ответ в течение 3-5 рабочих дней, а не "на следующем совещании, которое состоится когда-нибудь". Когда SLA не соблюдается, команды учатся обходить процесс, и именно в этот момент управление фактически рушится, даже если оно существует на бумаге. ### Таблица ответственности (RACI) для корпоративного управления | Область решения | Бизнес-спонсор | Корпоративный архитектор | Руководитель релизов/DevOps | Безопасность и соответствие | PMO | | --- | --- | --- | --- | --- | --- | | Структура Org (Single/Multi-org) | Консультация | Ответственность | Информирование | Консультация | Информирование | | Утверждение изменений на уровне общего объекта | Информирование | Исполнение | Консультация | Консультация | Информирование | | График релизов и Release train | Информирование | Консультация | Ответственность | Информирование | Исполнение | | Политика разрешений и соответствия | Консультация | Консультация | Информирование | Ответственность | Информирование | | Взаимозависимость параллельных программ | Исполнение | Консультация | Информирование | Информирование | Ответственность | | Локализация для нового рынка | Ответственность | Исполнение | Информирование | Консультация | Исполнение | Эта таблица не является предопределенным шаблоном; она должна быть адаптирована к фактической организационной структуре. Важный момент заключается в том, что "Ответственность" появляется только один раз в каждой строке — когда два субъекта имеют полную ответственность за одно и то же решение, это первый признак того, что структура приведет к задержкам. ## Single-org против Multi-org Это одно из самых дорогостоящих решений для исправления задним числом. Single-org с тонкой настройкой разделения разрешений (Profiles, Permission Sets, Record Types и Sharing Rules) позволяет получать единые отчеты по всей организации, сокращает затраты на поддержку интеграций и снижает стоимость лицензирования. Проблемы начинаются, когда разные бизнес-единицы требуют совершенно разной частоты релизов, или когда существует нормативное требование, обязывающее физическое разделение данных. Multi-org решает проблему разделения, но создает новую: каждый кросс-организационный отчет требует отдельного уровня BI или решения, такого как Data Cloud, а каждый глобальный процесс (например, Lead-to-Cash) должен быть построен дважды или управляться через MuleSoft/механизм синхронизации. В организациях, которые рассматривали оба пути, переход от Single-org к Multi-org после того, как организация уже выросла, обычно занимает 9-14 месяцев и включает сложную миграцию данных — поэтому лучше принять решение заранее, даже если это означает временный компромисс в разделении разрешений. ## Release train и DevOps на корпоративном уровне Когда несколько команд работают в одной организации (Org), подход "выпуск, когда готово" перестает работать. Модель, которая функционирует в корпоративном масштабе, — это Release Train: фиксированная частота (от двух недель до месяца), единый источник достоверной информации в системе контроля версий и конвейер, который выявляет конфликты метаданных между командами до дня развертывания, а не в сам день. Практические компоненты, которые следует включить: - Общая среда интеграции, где все команды объединяют изменения перед переходом к пользовательскому приемочному тестированию (UAT). - Регулярное окно Code Freeze (обычно 48-72 часа) перед каждым релизом. - Автоматизированное регрессионное тестирование, которое выполняется по основным сценариям каждой бизнес-единицы, а не только по новому изменению. - Четкая политика: команда, не уложившаяся вовремя в слияние, переносится на следующий поезд и не задерживает всех. Дополнительная информация об инфраструктуре Sandbox и процессах Pipeline подробно описана в [Salesforce DevOps Sandboxes](/ru/insights/salesforce-sandbox-devops-strategy), где также представлена рекомендуемая структура сред от Dev до Production. ## Безопасность и соответствие на корпоративном уровне При более чем 500 пользователях модель разрешений сама по себе становится критически важным активом. Распространенная ошибка — создание нового профиля для каждого небольшого изменения, что за год-два приводит к сотням профилей, логика которых никому не понятна. Более эффективный подход: ограниченный профиль по широкой роли и модульные наборы разрешений (Permission Sets), добавляемые по мере необходимости. В глобальных организациях добавляется уровень соответствия: GDPR в Европе требует возможности удаления и документирования согласия, регулирование конфиденциальности в Израиле требует регистрации базы данных, а медицинские или финансовые организации в США могут быть обязаны соблюдать HIPAA или SOX. Практическое значение: шифрование на уровне полей для конфиденциальных данных, журналы доступа к записям (Field Audit Trail или Shield) и процесс документирования, который показывает, кто и когда получил доступ к чему — а не только кто имеет право доступа. ## Глобализация и локализация Внедрение, работающее в нескольких странах, сталкивается с тремя повторяющимися проблемами: валюты и даты (Multi-Currency и формат даты в соответствии с Locale), язык в интерфейсе и отчетах (Translation Workbench не всегда охватывает пользовательские поля) и процессы утверждения, которые противоречат местному трудовому или налоговому законодательству. Команда, планирующая локализацию как дополнение в конце проекта, обычно обнаруживает, что она требует изменения самой модели данных, а не только перевода строк. ## PMO и взаимозависимость параллельных программ В крупной организации проект Salesforce почти никогда не выполняется изолированно. Параллельно работают программы ERP, проект Data Warehouse, а иногда и слияние двух компаний. PMO, которое не отображает взаимозависимость между программами, на поздней стадии обнаруживает, что оно и ERP в одно и то же время создают два разных источника истины для одних и тех же клиентских данных. Практический инструмент — это ежемесячно обновляемая матрица зависимостей: для каждой программы, какие данные она "ведет" (Source of Truth) и какие данные она только потребляет. Когда две программы претендуют на владение одним и тем же полем, PMO должно принять решение — не оставлять это на "разрешение на местах" между двумя разработчиками. ## Типичные сценарии сбоев для организаций с более чем 500 пользователями | Сценарий сбоя | Как это проявляется на практике | Превентивное действие | | --- | --- | --- | | Разрастание профилей | Сотни почти идентичных профилей, никто не уверен, кому что разрешено | Постепенный переход к модульным наборам разрешений | | "Частный" выпуск команды | Одна команда выходит в Production без прохождения CAB, нарушая другой процесс | Обязательный Release Train с общим Code Freeze | | Два источника истины для одних и тех же данных | ERP и CRM каждая "владеет" клиентскими данными | PMO устанавливает единый Source of Truth для каждого домена данных | | Слишком широкие разрешения "чтобы не блокировать" | Утечка конфиденциальной информации между бизнес-единицами | Принцип наименьших привилегий по роли, ежеквартальный аудит | | Поздняя локализация как дополнение | Частичный перевод, неверный формат даты, неработающие отчеты в одном регионе | Планирование Locale и валюты в модели данных с первого дня | | Несинхронизированная Sandbox | Тесты проходят в Sandbox и проваливаются в Production из-за различий в конфигурации | Запланированное обновление и единая политика Seed Data | ## Рекомендуемый процесс работы для внедрения в корпоративном масштабе ### 1. До начала разработки создайте Управляющий комитет и Совет по изменениям Прежде чем написать первую строку кода, необходимо назначить Спонсора на уровне руководства, определить три уровня утверждения изменений и согласовать SLA для ответа. Без этого первые команды, которые начинают работать, фактически устанавливают прецедент для всех последующих. ### 2. Примите решение о Single-org или Multi-org на раннем этапе и задокументируйте причину Это решение должно основываться на фактических нормативных требованиях и требуемой частоте выпусков, а не на технических предпочтениях. Следует задокументировать отклонённую альтернативу и условие, которое заставит пересмотреть решение (например, приобретение новой компании). ### 3. Создайте Release Train, прежде чем появится более одной команды Регулярная частота, общая среда интеграции и процесс выявления конфликтов до дня выпуска. Основной состав проектной команды определен в [Команда проекта Salesforce](/ru/insights/salesforce-project-team-roles), но в корпоративном масштабе также требуется отдельная роль менеджера по релизам. ### 4. Разработайте модель разрешений и требования соответствия в соответствии с регионом деятельности Необходимо заранее определить, какие нормативные акты действуют в каждой стране деятельности, и соответствующим образом спланировать шифрование, журналирование и процесс удаления, а не как дополнение после жалобы или аудита. ### 5. Документируйте зависимости между программами в PMO и обновляйте ежемесячно Это живая матрица зависимостей, а не документ, написанный один раз в начале проекта. Любое изменение в графике одной программы проверяется на предмет влияния на другие программы. ### 6. Проведите пилотное внедрение в одной бизнес-единице перед полным корпоративным развертыванием Полный вертикальный срез, включая реальные разрешения и интеграции, позволяет выявить проблемы управления и релизов до того, как они будут умножены на десятки подразделений. Понимание строительных блоков до уровня User Story представлено в [Salesforce User Stories](/ru/insights/salesforce-user-stories-backlog). ### 7. Расширяйте поэтапно с измеренным контролем между этапами Каждая волна развертывания измеряется относительно базовых показателей перед расширением до следующей волны. Если первая волна выявила проблему управления, ее исправляют, прежде чем продолжать — не расширяют, исправляя при этом. ## Пример корпоративного сценария Страховая компания с 1200 пользователями в трех странах пыталась внедрить Salesforce с двумя параллельными командами разработчиков — одной для продаж и одной для обслуживания — без активного CAB. Через пять месяцев обе команды каждую неделю меняли один и тот же клиентский объект, а процессы тестирования периодически давали сбои без объяснения причин. Решение не было техническим: организация создала еженедельный CAB с SLA в 3 дня, назначила единого Владельца Объекта для каждой центральной сущности и перешла на двухнедельный Release Train с общей средой интеграции. В течение двух месяцев количество конфликтов между командами значительно сократилось, и график запуска в трех странах стабилизировался. Основной вывод: корпоративный масштаб не терпит неудачу из-за технологии, а из-за отсутствия четкой ответственности за общие данные. ## Контрольный список перед расширением до корпоративного масштаба - ☐ Наличие Совета по изменениям с определенным SLA, а не только на бумаге - ☐ Решение Single-org против Multi-org задокументировано с условиями для пересмотра - ☐ Существует Release Train с фиксированной частотой и общей средой интеграции - ☐ Модель разрешений основана на наборах разрешений (Permission Sets), а не на новом профиле для каждого изменения - ☐ Проверены требования соответствия по каждой стране деятельности - ☐ Существует матрица зависимостей между параллельными программами, обновляемая ежемесячно - ☐ Определен единый Владелец объекта для каждой общей сущности данных - ☐ Проведен пилот в одной бизнес-единице перед полным развертыванием - ☐ Существует план локализации, выходящий за рамки перевода строк - ☐ Определены отдельные метрики успеха для каждой волны расширения ## Профессиональные источники - Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html - HPI Pro – Внедрение Salesforce — https://hpi.pro/salesforce-implementation - HPI Pro – Методология работы — https://hpi.pro/methodology ### Вопросы и ответы **Когда возникает реальная потребность в Multi-org?** В случаях, когда бизнес-подразделения функционируют с совершенно разными моделями продаж, регуляторными нормами или языковыми требованиями, и когда частота изменений в одном подразделении может негативно повлиять на стабильность другого. В большинстве организаций с количеством пользователей до 3000-5000 предпочтительнее Single-org с тщательным разграничением прав доступа, поскольку затраты на обслуживание Multi-org значительно выше. **Сколько времени требуется для создания эффективно работающего комитета по управлению изменениями (CAB)?** В среднем процесс стабилизируется через шесть-восемь недель: определение типов изменений, порогов утверждения, регулярного расписания заседаний и шаблона запроса. Истинная сложность заключается не в определении процесса, а в его соблюдении, когда бизнес-давление подталкивает к его обходу. **Как планировать Release Train при наличии 6-8 параллельных команд?** Устанавливается фиксированная периодичность (например, две недели или месяц), общее окно Code Freeze и механизм слияния, который выявляет конфликты Metadata до развертывания. Команды, не готовые к назначенному сроку, переходят к следующему «поезду» — это предотвращает задержку всей группы. **В чем заключаются различия в требованиях соответствия (Compliance), когда организация работает в нескольких странах?** Требуется картографирование по регионам: GDPR в Европе, Закон о защите персональных данных в Израиле, а иногда HIPAA или SOX для американских организаций в сфере здравоохранения и финансов. Практическое отличие заключается в хранении данных, шифровании полей и журналах доступа, а не только в разрешениях профиля. **Что происходит, когда графики проектов CRM и ERP сталкиваются?** Зависимости в интеграции или общем источнике истины (например, данные о клиентах) часто обнаруживаются только на поздних этапах. Офис управления проектами (PMO) должен с первого дня картировать зависимости между проектами и определять, какой проект является «ведущим» для каждого домена данных, чтобы избежать двух противоречащих решений для одного и того же поля. --- ## Переход на Salesforce: как спланировать миграцию без потерь данных и процессов URL: https://hpi.pro/ru/insights/replace-crm-with-salesforce Переход между CRM-системами часто терпит неудачу не из-за Salesforce, а из-за непроверенной миграции исторических данных. В статье подробно описано, как сопоставить существующие процессы, выбрать, что оставить позади, и безопасно отключить старую систему. ## Краткий обзор Перевод CRM-системы на Salesforce — это не просто технический проект по «переносу данных». Это организационное решение о том, что следует сохранить, от чего отказаться и как организовать операционную деятельность компании во время перехода. Самая распространенная ошибка заключается не в некорректной настройке Salesforce, а в негласном предположении, что все содержимое старой системы должно быть перенесено в неизменном виде. Правильный подход начинается с картирования процессов, а не с экспорта таблиц. Затем создается новая модель данных, соответствующая текущей работе организации, а не структуре, установленной десять лет назад в другой системе. Контролируемый период параллельной работы и, наконец, упорядоченное отключение старой системы с документацией для соблюдения нормативных требований завершают процесс. Организации, сталкивающиеся с этими вопросами, могут найти дополнительную информацию в статье [Внедрение Salesforce в организации](/ru/insights/salesforce-implementation-guide), где подробно описан комплексный процесс принятия решений в проекте Salesforce. ## Картирование существующих процессов: не экспорт, а понимание Первый шаг при переходе между CRM-системами — не экспорт данных, а взаимодействие с владельцами процессов для понимания того, что на самом деле происходит от момента генерации лида до закрытия сделки, или от получения запроса до закрытия сервисного инцидента. Старый документ с описанием процессов, если он вообще существует, почти всегда устарел по отношению к реальной деятельности. В процессе картирования следует документировать не только формальные шаги, но и «теневые процессы» — параллельные таблицы Excel, незаполняемые поля, утверждения, передаваемые через мессенджеры вместо системы. Именно в этих областях новая система, даже если она построена правильно, терпит неудачу во внедрении, если эти аспекты не учтены. Результат картирования должен включать таблицу основных процессов, их владельца, частоту использования и степень зависимости от старой системы. Процесс, выполняемый раз в квартал и генерирующий критически важный отчет для регулятора, требует иного подхода, чем высокочастотный ежедневный процесс. Такое разделение также определяет порядок миграции и необходимый уровень тестирования для каждого процесса. ## Что не переносить: решение, экономящее половину работы Одно из наиболее значимых решений в проекте миграции CRM — это не что переносить, а что **не** переносить. Большинство устаревших систем, накапливавшихся годами, содержат слои дублирующихся полей, устаревших статусов и процессов, которые были определены для одноразового проекта, который уже завершен. Практическое правило: любой объект или поле, к которым никто не обращался в течение последних двух лет, по умолчанию переходит в список «не переносить», если только конкретный владелец процесса не запросит обоснованное исключение. Этот список формируется на основе журналов фактического использования в старой системе, а не по воспоминаниям пользователей, поскольку человеческая память часто описывает систему такой, какой она должна была работать, а не такой, какой она работает на самом деле. Важно различать три категории информации: - **Актуальная информация** — должна быть перенесена в новую систему как активная запись со всеми ее связями. - **Актуальная историческая информация** — переносится как архив для просмотра, как правило, без необходимости редактирования или автоматизации. - **Устаревшая информация** — не переносится совсем, сохраняется только во внешней резервной копии на случай аудита. Расширенное описание управления границами между этапами планирования и построения представлено в статье [Расползание объема работ в Salesforce](/ru/insights/salesforce-scope-creep-change-control), поскольку тенденция добавлять «еще немного старых данных» является одним из самых распространенных источников расползания объема работ в подобных проектах. ## Новая модель данных против старой: не перевод, а проектирование Распространенная ошибка — подходить к модели данных как к переводу 1:1: каждая таблица в старой системе становится объектом в Salesforce, каждый столбец — полем. Такой подход сохраняет все недостатки старой системы на новой платформе и упускает ключевое преимущество Salesforce: возможность строить гибкие отношения между объектами, встроенную автоматизацию и богатый слой разрешений. Сравнение двух основных подходов к миграции помогает принять осознанное решение: | Аспект | Метод «Lift-and-Shift» (перенос как есть) | Метод «Redesign» (перепроектирование) | | --- | --- | --- | | Время проекта | Относительно короткое, обычно 6-10 недель | Более длительное, обычно 3-5 месяцев | | Соответствие бизнес-процессам | Низкое — сохраняет старые ограничения | Высокое — строится вокруг текущего процесса | | Риск технического долга | Высокий, проявляется через год-два | Ниже, поскольку структура спроектирована заранее | | Будущие затраты на поддержку | Со временем увеличиваются | Относительно стабильны | | Подходит для | Организаций с экстремально сжатыми сроками или очень ограниченным объемом работ | Большинства организаций, переходящих со системы старше трех лет | | Основной риск | «Новая система, старые проблемы» | Отклонение от графика, если объем работ не ограничен | На практике большинство организаций выбирают промежуточный подход: перепроектирование для основной модели (учетные записи, контакты, возможности или сервисные инциденты) и контролируемый перенос как есть для второстепенных сущностей, которые не оказывают существенного влияния на процессы. Это решение должно быть явно принято на этапе планирования, а не возникать случайно в процессе построения. ## Период параллельной работы: как обеспечить непрерывность бизнеса Период параллельной работы — это временной интервал, в течение которого обе системы функционируют одновременно — обычно от четырех до восьми недель. Его цель — выявить расхождения в реальном времени, прежде чем они станут необратимой проблемой. Заключенная сделка, открытый сервисный запрос или сформированный отчет о комиссионных — все это должно проверяться параллельно в обеих системах и показывать одинаковый или объяснимый результат. Вопрос, который возникает почти в каждом проекте: какая система считается «источником истины» в этот период? Ответ должен быть единственный и заранее определенный, как правило, Salesforce с первого дня, когда старая система используется только для проверки, а не для текущей работы. Двойная работа пользователей в двух системах — это путь к усталости и фактическому отказу от новой системы. Практические инструменты для управления этим периодом: - Ежедневный или еженедельный сравнительный отчет по ключевым данным в обеих системах (количество лидов, сумма сделок, открытые запросы). - Актуальный список исключений, который обновляется при выявлении расхождений, с ответственным лицом (Owner), которое обязуется устранить его в течение определенного срока. - Группа «ключевых пользователей» из каждого отдела, которая ежедневно сообщает об ошибках использования, а не только о технических сбоях. Большая часть полученных в этот период данных актуальна и для формализованного процесса тестирования, подробно описанного в [Руководстве по UAT для Salesforce](/ru/insights/salesforce-uat-guide), а также для периода после запуска, описанного в [Плане Hypercare для Salesforce](/ru/insights/salesforce-hypercare-plan). ## Отключение старой системы: не одноразовое событие, а последовательность решений Отключение старой системы происходит поэтапно, а не нажатием одной кнопки в день перехода (Cutover). Основное правило: система отключается от текущей работы сразу после Go Live, но остается доступной только для чтения на короткий льготный период, обычно 30-60 дней, на случай обнаружения недостающих данных или вопросов от финансового отдела. ### Контрольный список для решения о переходе (Cutover) Прежде чем официально объявить об отключении старой системы, убедитесь, что: - ☐ Все отчеты, регулярно генерируемые старой системой, успешно воспроизведены из Salesforce или из архива. - ☐ Завершен один полный бизнес-цикл (например, полный месяц закрытия), полностью в новой системе. - ☐ Разница в данных между системами опустилась ниже заранее определенного порога (например, менее 1% записей). - ☐ Имеется письменное подтверждение от юридического или финансового отдела, что архив соответствует требованиям по хранению. - ☐ Определен ответственный за доступ только для чтения в течение льготного периода и дата его окончательного закрытия. - ☐ Выполнено полное и проверенное резервное копирование всех данных старой системы перед отменой лицензии. - ☐ Отправлено уведомление всем владельцам процессов о дате окончательного отключения и способе доступа к архиву. Пропуск любого из этих пунктов является наиболее частой причиной того, что через несколько месяцев после проекта обнаруживается отсутствие доступа к информации, которая внезапно понадобилась для налоговой проверки или судебного разбирательства. ## Архив и регулирование: что необходимо хранить и как долго Требования к хранению информации варьируются в зависимости от отрасли, но почти всегда существует обязанность хранить финансовые, договорные данные или данные, связанные с жалобами клиентов, в течение семи лет, а иногда и дольше. Распространенная ошибка — пытаться «загрузить» всю эту историю в Salesforce как активные записи, что замедляет производительность и сбивает с толку пользователей, которые видят сделки десятилетней давности в своих ежедневных списках. Принятым решением является разделение на два уровня: | Уровень | Содержание | Место хранения | Доступность | | --- | --- | --- | --- | | Актуальная операционная информация | Последние 24-36 месяцев | Salesforce | Полный, включая редактирование и автоматизацию | | Регуляторный архив | Полная история в соответствии с законодательством | Внешнее хранилище данных или Salesforce Archive | Только для чтения, с возможностью поиска | Важно задокументировать политику архивирования в письменной форме и получить одобрение от юридического лица перед отменой доступа к старой системе, так как после отмены лицензии пути назад нет, если обнаружится, что данные отсутствуют. ## Пример организационного сценария Финансовая компания перешла с 12-летней локальной CRM-системы на Salesforce. На этапе картирования команда определила, что около 40% существующих полей не использовались более двух лет, и решила не переносить их. Это сэкономило около месяца работы по построению и тестированию. В период параллельной работы, который длился шесть недель, было обнаружено расхождение в расчете комиссионных, вызванное разницей в округлении чисел между системами — ошибка, которая не была бы выявлена без ежедневного сравнительного отчета. Команда исправила формулу до того, как она повлияла на реальные платежные ведомости. Старая система была отключена от текущей работы в день Go Live, но доступ только для чтения сохранялся еще 45 дней для проверки квартального отчета, который уже находился в процессе. Результат: в течение трех месяцев после окончательного отключения дополнительный доступ к старой системе не понадобился, а экономия на затратах на лицензирование покрыла значительную часть стоимости самого проекта миграции. ## Распространенные риски и превентивные меры | Риск | Как это проявляется на практике | Превентивные меры | | --- | --- | --- | | Перенос «всего» без фильтрации | Новая система перегружена мертвыми данными и замедляет внедрение | Определить критерий фильтрации по фактическому использованию за последние два года | | Скопированная модель данных | Те же ограничения старой системы повторяются в Salesforce | Разработать новую модель, основанную на актуальном процессе, а не на старых таблицах | | Параллельная работа без ответственного | Расхождения между системами выявляются с опозданием или не выявляются вовсе | Регулярный сравнительный отчет с назначенным ответственным за каждое отклонение | | Слишком поспешное отключение | Обнаружение отсутствующих данных после отмены лицензии | Льготный период доступа только для чтения перед окончательной отменой | | Игнорирование требований к архиву | Регуляторная проверка выявляет, что требуемая информация не была сохранена должным образом | Получить письменное одобрение от юридического отдела на политику архивирования перед переходом (Cutover) | ## Как измерить успех миграции | Область | Что измерять | Частота проверки | | --- | --- | --- | | Полнота данных | Доля записей, успешно перенесенных без ошибок | До и после каждого запуска миграции | | Соответствие между системами | Расхождения в ключевых отчетах между старой и новой | Ежедневно в период параллельной работы | | Адаптация пользователей | Уровень работы в новой системе по сравнению с возвратом к старой | Еженедельно в первый месяц | | Операционные затраты | Экономия на лицензиях и поддержке после отключения | Ежемесячно, начиная через три месяца после Go Live | Для замены CRM-системы на Salesforce следует заранее выбрать от трех до пяти ключевых показателей и измерять их как до, так и после проекта — в противном случае сложно доказать, что переход действительно улучшил процесс, а не просто перенес его на другую платформу. Фактическое выполнение такого процесса может быть осуществлено при поддержке [службы внедрения Salesforce](/ru/salesforce-implementation), которая сопровождает организации от этапа картирования до отключения старой системы. ## Профессиональные ресурсы - Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html - HPI Pro – Внедрение Salesforce — https://hpi.pro/salesforce-implementation - HPI Pro – Методология работы — https://hpi.pro/methodology ### Вопросы и ответы **Какой объем исторических данных следует переносить из старой системы?** Практическое правило: последние 24–36 месяцев данных переносятся в новую систему как активные записи, остальное перемещается в доступный только для чтения архив. Перенос десятилетней истории «просто потому, что это возможно» увеличивает стоимость миграции и снижает производительность без доказанной бизнес-выгоды. **Что делать с полями, не имеющими аналогов в новой модели данных?** Сначала проверьте, используется ли поле в текущем процессе или является ли оно историческим артефактом. Активное поле получает явное сопоставление или новое пользовательское поле; неиспользуемое поле сохраняется только во внесистемном архиве, без переноса в Salesforce как «свободное текстовое поле», которое никто не поймет через год. **Как долго должен длиться период параллельной работы систем?** В среднем от четырех до восьми недель для средних организаций, в зависимости от сложности цикла продаж или обслуживания. Слишком короткий период не выявит сезонных исключений; слишком долгий период закрепит у пользователей привычку работать в двух системах и замедлит адаптацию. **Когда можно окончательно отключить старую систему?** Только после выполнения трех условий: данные между системами синхронизированы без существенных расхождений, по крайней мере один полный бизнес-цикл полностью прошел в Salesforce, и все регуляторные или аудиторские отчеты, основанные на старой системе, успешно восстановлены из архива. **Нужно ли сохранять активный доступ к старой системе после миграции?** В большинстве случаев активный доступ не требуется дольше короткого льготного периода в 30-60 дней для проверки исключений. После этого, резервного копирования исключительно для регуляторных и аудиторских целей достаточно в большинстве отраслей, и это значительно снижает затраты на лицензирование и обслуживание по сравнению с поддержанием старой системы в активном состоянии. --- ## Интеграция Salesforce с ERP-системой: Архитектура, Паттерны и Риски URL: https://hpi.pro/ru/insights/salesforce-erp-integration При любой интеграции Salesforce с ERP-системой наступает момент, когда два числа – например, остаток на складе, дебиторская задолженность или статус заказа – противоречат друг другу, и кто-то должен решать, какое из них верное. В данном руководстве мы рассматриваем принятие решений исходя из источника истины, паттерна синхронизации и планирования отказов, а не просто перечня API-соединений. ## Краткий Обзор Интеграция Salesforce с ERP-системой часто оказывается неуспешной не из-за технических проблем самого подключения, а из-за отсутствия предварительного ответа на ключевой вопрос: какая система является источником достоверных данных для каждой сущности, и что происходит, когда сообщение между системами теряется, дублируется или приходит в неправильном порядке. Данное руководство структурирует процесс принятия решений вокруг трех уровней — источник достоверных данных, модель синхронизации и обработка сбоев — и показывает, как выбирать между ними на основе реальных бизнес-сценариев, а не только на возможностях API. Рекомендуемый подход начинается с сущностей (клиент, продукт, заказ, счет), а не с инструментов. Для каждой сущности определяется единственный владелец, адекватная частота обновлений и кто имеет право вносить изменения. Отсюда выводятся модель синхронизации, методы обработки ошибок и требуемый уровень мониторинга. Естественным продолжением обсуждения интеграции Salesforce с ERP является тема [Архитектура Salesforce](/ru/insights/crm-architecture-guide). ## Источник Достоверных Данных для Каждой Сущности: Вопрос, Предшествующий Любому API Прежде чем выбирать протокол или инструмент интеграции, необходимо ответить на один вопрос для каждой сущности: какая система принимает решение о том, что является верным в случае конфликта? Зачастую ERP является источником достоверных данных для запасов, прейскурантов, счетов и финансовых операций, в то время как Salesforce является источником достоверных данных для отношений с клиентами, возможностей и сбытовой деятельности. Проблема возникает, когда кто-то молчаливо предполагает, что двусторонний обмен данными «уладится сам по себе» — и тогда возникают ситуации, когда торговый представитель изменяет адрес доставки в Salesforce, в то время как ERP уже отправила товар по старому адресу. Практическое решение — это документ по сопоставлению сущностей: для каждой сущности (Account, Product, Order, Invoice) указывается источник достоверных данных, направление синхронизации (одностороннее или двустороннее) и требуемая частота обновления. Если существует реальная потребность в двусторонней синхронизации — например, обновление статуса платежа, возвращающегося из ERP в запись возможности — устанавливается четкое правило для разрешения конфликтов, например, «последнее обновление по Timestamp побеждает» или «финансовое поле всегда определяется ERP». |Сущность|Источник Достоверных Данных|Направление Синхронизации|Типичная Частота| |---|---|---|---| |Клиент (Account)|Salesforce|Двусторонняя с правилом разрешения конфликтов|Почти мгновенно| |Продукт и Прайс-лист|ERP|Односторонняя в Salesforce|Ежедневно или по изменению| |Заказ (Order)|Создается в Salesforce, управляется в ERP|Двусторонняя, отдельные этапы|Мгновенно на этапе создания| |Счет и Оплата|ERP|Односторонняя в Salesforce|Ежедневно или в режиме реального времени| |Доступный Запас|ERP|Односторонняя в Salesforce|Каждые несколько минут до часа| ## Модели Синхронизации: Request-Reply, Batch и Event-Driven Три модели охватывают большинство реальных сценариев. **Request-Reply (синхронная)** подходит, когда пользователь Salesforce ожидает немедленного ответа — например, проверка наличия товара перед подтверждением заказа. Преимущество — простота и немедленный ответ; недостаток — полная зависимость от доступности ERP в данный момент и ухудшение пользовательского опыта, если ответ медленный. **Batch (пакетная)** подходит для больших объемов несрочных обновлений, таких как ночная синхронизация прейскуранта или импорт счетов за предыдущий день. Эта модель более устойчива к временным сбоям, но означает задержку (Latency) от нескольких часов до суток между системами — задержка, которая должна быть приемлема для бизнеса, а не только для технической команды. **Event-Driven (управляемая событиями)** (с использованием Platform Events, Change Data Capture или внешней очереди сообщений) подходит, когда требуется почти немедленная реакция без синхронной зависимости. Изменение статуса заказа в ERP генерирует событие, и Salesforce обновляется, когда готова — включая автоматический повтор попытки (Retry), если она была временно недоступна. Это наиболее гибкая модель, но также и наиболее сложная в настройке и мониторинге. ### Таблица Выбора Модели по Сценарию |Сценарий|Рекомендуемая Модель|Типичная Latency|Основной Риск| |---|---|---|---| |Проверка наличия до подтверждения заказа|Request-Reply|Несколько секунд|Полная зависимость от доступности ERP; таймаут ухудшает пользовательский опыт| |Синхронизация прейскуранта и товаров|Ночной Batch|Часы до 24 часов|Данные неактуальны между запусками; требует координации с кампаниями и акциями| |Обновление статуса оплаты|Event-Driven|Секунды до минут|Операционная сложность; требует мониторинга очереди сообщений и Dead Letter Queue| |Создание нового заказа в ERP|Request-Reply с Retry|Секунды до минуты|Частичный сбой — заказ создан в ERP, но ответ потерян, риск дублирования| |Обновление доступного запаса для продажи|Частый Batch (каждые 15-60 минут)|Минуты|Продажа по уже отсутствующему запасу между запусками| |Оповещение о превышении кредитного лимита|Event-Driven|Почти мгновенно|Потерянное событие приводит к одобрению сделки, которая не должна была пройти| В этом контексте, решение о типе синхронизации также связано с моделью разрешений и владением данными — подробнее об этом в [Управление доступом Salesforce](/ru/insights/salesforce-sharing-visibility-design). ## Middleware против Point-to-Point Когда существует только одно подключение между Salesforce и ERP, прямое подключение (Point-to-Point) с использованием REST API или Named Credentials может быть самым быстрым и дешевым решением. Проблема возникает, когда добавляется третья система — хранилище данных, система доставки или платежная платформа — и тогда каждая новая система требует создания собственной логики трансформации и обработки ошибок, дублирующей то, что уже существует в предыдущем подключении. Уровень Middleware (например, MuleSoft, Boomi или Workato) решает эту проблему путем централизации логики: каждая система подключается один раз к Middleware, и Middleware отвечает за трансформацию, повторы, очередь сообщений и централизованный мониторинг. Цена — это дополнительный компонент инфраструктуры, требующий лицензии, обслуживания и специализированной экспертизы. Практическое правило: до двух-трех стабильных подключений без сложной логики — Point-to-Point является разумным. От трех систем и более, или при наличии централизованных требований к управлению (например, унифицированный мониторинг для всех интеграций в организации), стоимость Middleware почти всегда оправдывается в течение одного-двух лет. ## Обработка Ошибок и Idempotency Наиболее опасный сценарий в интеграции — это не полный сбой, а **частичный сбой**: сообщение отправлено, ERP создала заказ, но ответ в Salesforce был потерян из-за таймаута. Если отправляющая система наивно пытается снова, создается дублирующий заказ. Решение — это Idempotency Key — уникальный идентификатор, создаваемый на отправляющей стороне и прикрепляемый к каждому запросу. Принимающая сторона ведет учет уже обработанных идентификаторов и отказывает (или возвращает существующий результат), если идентификатор уже существует. Другие практические принципы: - Каждая критическая интеграция получает механизм Retry с постепенным Backoff, а не немедленные и повторяющиеся попытки - Сообщения, которые неоднократно не удавались, перемещаются в Dead Letter Queue для ручной проверки, а не бесшумно исчезают - Журнал ошибок включает полную полезную нагрузку (Payload) неудачного сообщения, чтобы обеспечить ручное восстановление - Ежедневный или еженедельный процесс сверки (Reconciliation) сравнивает системы и выявляет расхождения, которые синхронизация «пропустила» Без Idempotency Key и упорядоченного процесса сверки любая временная сетевая проблема превращается в постоянную проблему данных, источник которой трудно обнаружить спустя недели. ## Ограничения API, Безопасность и Мониторинг Salesforce налагает ежедневные ограничения на количество вызовов API (зависит от лицензии и версии), а также ограничения на размер ответа и время выполнения. Организация, которая синхронизирует десятки тысяч записей в день через обычный REST, вызов за вызовом, быстро достигнет предела. Решение — Bulk API 2.0 для объемных обновлений и Composite API для уменьшения количества вызовов в многостадийных синхронных процессах. В части безопасности три принципа повторяются в каждом успешном проекте: 1. Использование Named Credentials и Connected Apps с OAuth, а не постоянных имен пользователей и паролей в коде 2. Разрешения «технического пользователя» интеграции ограничены точно до тех объектов и полей, которые необходимы — не профиль администратора системы 3. Конфиденциальный трафик (номера кредитных карт, данные банковских счетов) проходит через уровень Middleware или токенизацию, не хранится в открытом тексте в Salesforce Для мониторинга необходимо создать панель мониторинга, которая отображает как минимум три показателя: процент успешных и неудачных сообщений, среднее и медианное время ответа, и количество записей в Dead Letter Queue. Автоматическое оповещение при превышении определенного порога ошибок (например, более 2% сообщений в день) предотвращает ситуацию, когда накапливающаяся проблема обнаруживается только тогда, когда клиент жалуется. Эти решения часто основываются на базовой работе в области информации и разрешений, описанной в [Технический долг Salesforce](/ru/insights/salesforce-flow-apex-technical-debt). ## Рекомендуемый Рабочий Процесс ### 1. Сопоставьте сущности и определите источник достоверных данных Для каждой сущности (клиент, продукт, заказ, счет) определяется система, которая является авторитетной в случае конфликта. Без этого решения любое обсуждение «правильного способа синхронизации» будет вестись в тумане. ### 2. Выберите модель синхронизации в соответствии с фактически требуемой Latency Не каждый процесс требует немедленного ответа. Проверка запасов перед продажей да; обновление прейскуранта ночью нет. Соответствие модели реальным потребностям экономит ненужные затраты на инфраструктуру. ### 3. Определитесь между Middleware и Point-to-Point Выбор зависит от количества подключенных систем и необходимости централизованного управления (Governance), а не только от технологических предпочтений. ### 4. Спланируйте Idempotency, Retry и Reconciliation с самого начала Это не «будущие улучшения», а часть определения готовности (Definition of Done) для любой интеграции, которая затрагивает деньги, запасы или заказы. ### 5. Определите минимальные разрешения для технического пользователя Специальный профиль, а не общие разрешения администратора системы. Любое изменение разрешений проходит отдельное утверждение от функционального изменения. ### 6. Протестируйте сценарии сбоев, а не только Happy Path Проведение теста, в котором ERP «падает» в середине процесса, и измерение времени восстановления и выявления дубликатов, выявляет проблемы, которые не видны в тихой среде разработки. ### 7. Создайте панель мониторинга и постоянный процесс сверки Технического мониторинга (сервер жив) недостаточно; требуется бизнес-мониторинг (количество заказов в обеих системах одинаково). ## Пример Организационного Сценария Торговая компания с около 40 тысяч заказов в месяц подключила Salesforce к ERP с помощью прямых синхронных REST-вызовов, без Middleware. В период пиковых продаж процент сбоев в вызовах API резко возрос из-за дневного лимита вызовов, и заказы, которые не удалось зарегистрировать в ERP, просто «исчезли» — потому что не было Dead Letter Queue и оповещения. После проверки выяснилось три недостатка: не был определен Idempotency Key, поэтому повторные попытки иногда создавали дублирующие заказы; не было перехода на Bulk API для массовых обновлений; и не было процесса сверки, который сравнивал количество заказов в двух системах. Решение включало переход на уровень Middleware с очередью сообщений, замену части синхронных вызовов на частую пакетную обработку и добавление ежедневной панели мониторинга, отображающей расхождения. Результатом было не «ноль сбоев» — это нереалистичная цель — а сокращение времени выявления сбоя с недель до часов и процесс, позволяющий устранить расхождения в тот же день, а не после жалобы клиента. ## Распространенные Риски и Превентивные Меры |Риск|Как это проявляется на практике|Превентивная мера| |---|---|---| |Не определен источник достоверных данных|Две «правильные» стороны одновременно, и никто не знает, кому верить|Документ по сопоставлению сущностей с определенным владельцем для каждого критического поля| |Отсутствие Idempotency|Дублирующие заказы после каждого временного сбоя сети|Idempotency Key и проверка дубликатов на принимающей стороне| |Point-to-Point без Governance|Каждое изменение в одной системе незаметно нарушает другие подключения|Уровень Middleware, задокументированные контракты и четкое владение| |Игнорирование ограничений API|Сбои вызовов при пиковой нагрузке без предварительного оповещения|Переход на Bulk API, мониторинг потребления дневной квоты| |Широкие разрешения для технического пользователя|Раскрытие конфиденциальной информации сверх потребностей интеграции|Ограниченный профиль и периодическая проверка разрешений| Те, кто находится на более ранней стадии планирования подключения, могут найти дополнительную информацию в [Salesforce Flow или Apex](/ru/insights/salesforce-flow-vs-apex), особенно при принятии решения о том, где именно реализовать логику трансформации. ## Как Измерить Успех |Область|Что измеряют|Частота проверки| |---|---|---| |Надежность|Процент завершенных сообщений по сравнению с неудавшимися|Постоянно, с оповещением о превышении порога| |Latency|Время от начала до конца для каждого сценария отдельно|Постоянно| |Согласованность данных|Количество расхождений при проверке Reconciliation|Ежедневно или еженедельно| |Операционные издержки|Часы поддержки, затраченные на устранение сбоев интеграции|Ежемесячно| Рекомендуется выбрать только три-четыре метрики для первой версии и измерять их также до запуска, чтобы иметь реальную базовую линию для сравнения, а не оценку по памяти. ## Контрольный Список Перед Запуском в Production - ☐ Для каждой сущности определен один источник достоверных данных и правило разрешения конфликтов - ☐ Для каждого процесса отдельно выбрана модель синхронизации (Request-Reply, Batch или Event-Driven) - ☐ Решено, нужен ли Middleware или прямого подключения достаточно - ☐ Существует Idempotency Key для каждой операции, создающей финансовую запись - ☐ Определен Retry с Backoff и Dead Letter Queue для неудачных сообщений - ☐ Проверено потребление ежедневной квоты API по сравнению с ожидаемым объемом - ☐ Разрешения технического пользователя ограничены только необходимыми объектами и полями - ☐ Проведено тестирование частичного сбоя, а не только Happy Path - ☐ Существует панель мониторинга для бизнес-мониторинга, а не только технического - ☐ Определен постоянный процесс Reconciliation и ответственное лицо ## Глубокие Заметки по Внедрению и Эксплуатации ### Заметка Архитектора: Когда Менять Существующую Модель Если модель пакетной обработки (Batch) была выбрана изначально из соображений простоты, но бизнес начинает требовать почти мгновенного обновления остатков, нет необходимости «взрывать» всю архитектуру — можно увеличить частоту до 15 минут в качестве промежуточного этапа и переходить на Event-Driven только тогда, когда станет ясно, что этого тоже недостаточно. Постепенное изменение, сопровождаемое фактическим измерением задержки, предпочтительнее слишком раннего общего решения. С управленческой точки зрения, истинное испытание интеграции Salesforce с ERP заключается не только в том, что она «работает сегодня», но и в том, что можно за пять минут объяснить, почему была выбрана каждая модель, и кто отвечает за ее исправление, когда что-то идет не так. Решение, требующее длительного расследования при каждом сбое, создает скрытые операционные издержки, которые со временем растут. Если внутренняя емкость для планирования или реализации такой интеграции отсутствует, [услуги архитектора CRM](/ru/crm-architecture) — это практический путь вперед. ## Профессиональные Ресурсы - Шаблоны Интеграции Salesforce — https://architect.salesforce.com/docs/architect/fundamentals/guide/integration-patterns.html - Руководство по Принятию Решений об Интеграции Данных Salesforce — https://architect.salesforce.com/docs/architect/decision-guides/guide/data-integration.html - HPI Pro – Архитектура CRM — https://hpi.pro/crm-architecture - HPI Pro – Интеграции и Данные — https://hpi.pro/integrations-data ### Вопросы и ответы **Что делать, если ERP и Salesforce предоставляют противоречивые данные об одном и том же клиенте?** Прежде всего, необходимо определить, какая система является источником истины для конкретной сущности – как правило, ERP для финансовых операций и остатков, а Salesforce для управления взаимоотношениями с клиентами. Затем разрабатывается ежедневное правило сверки (Reconciliation), выявляющее расхождения. Не стоит полагаться на то, что статус синхронизации 'Зеленый' означает фактическое соответствие данных. **Когда достаточно интеграции Point-to-Point, а когда необходим Middleware?** Для двух-трех стабильных подключений может быть достаточно Point-to-Point. Однако если у вас три и более систем, общая логика трансформации данных или потребность в централизованном механизме повторных попыток и мониторинга, промежуточное ПО (Middleware), такое как MuleSoft, поможет избежать дублирования логики на каждой стороне. **Как обеспечить идемпотентность при повторной отправке сообщения?** Каждому сообщению присваивается уникальный идентификатор (Idempotency Key). На принимающей стороне проверяется, был ли этот идентификатор уже обработан, прежде чем создавать новую запись. На практике это хранится в специальном внешнем поле записи или в отдельной таблице логов, чтобы повторная операция не приводила к созданию дублирующего заказа. **Что происходит, когда достигается дневной лимит API-вызовов Salesforce?** Необходимо перейти от частых синхронных вызовов к пакетной обработке (Bulk API) или снизить частоту опроса (Polling). Организация с десятками тысяч обновлений заказов в день почти всегда столкнется с этим ограничением, если будет использовать обычный REST вместо Bulk API 2.0. **Как протестировать интеграцию с ERP до вывода в продуктивную среду?** Создайте среду Staging с репрезентативной копией данных, выполните полный сценарий, включая частичный сбой (недоступность ERP, поврежденное сообщение, дублирование), и измерьте время восстановления согласованности. Бизнес-одобрение должно быть получено только после демонстрации сценариев сбоя, а не только идеального пути (Happy Path). --- ## Миграция данных в Salesforce: Полное руководство по планированию, очистке и переходу URL: https://hpi.pro/ru/insights/salesforce-data-migration-guide Большинство сбоев миграции обусловлены не инструментом, а неправильным порядком загрузки, поспешным сопоставлением полей и отсутствием сверки. Данное руководство описывает полный процесс: профилирование, очистку, использование внешних идентификаторов (External IDs), тестовые прогоны (Dry Run) и исправления после запуска системы (Go Live). ## Краткий ответ Миграция данных в Salesforce обычно завершается неудачно не из-за инструментария, а из-за некачественного рабочего процесса: начало загрузки до понимания качества источника, выполнение сопоставления полей в одном файле Excel без проверки на наличие аномальных значений, а также загрузка, не учитывающая зависимости между объектами. Правильный процесс строится как итеративный цикл: профилирование, сопоставление, очистка, контролируемая загрузка, тестирование и сверка (Reconciliation) – и только после этого Cutover. Цель статьи – разбить этот жизненный цикл на четкие этапы, предоставив таблицу порядка загрузки и чек-лист сверки (Reconciliation), которые можно использовать на практике. В большинстве проектов разница между бесперебойной миграцией и миграцией, требующей повторной работы, определяется уже на первой неделе, на этапе профилирования источника. Предварительная очистка данных предотвращает дальнейшие проблемы. Подробнее об этом можно прочитать в статье [Удаление дубликатов в Salesforce](/ru/insights/salesforce-data-deduplication). ## Профилирование источника: знакомство с данными до их обработки Прежде чем приступать к сопоставлению полей, необходимо провести профилирование источника данных: сколько записей в каждой таблице, какие поля фактически пусты (не только в схеме, но и в самих данных), каков диапазон значений в числовых и датированных полях, и где встречаются свободные значения, которые должны быть в закрытом списке. В одном из проектов, который мы сопровождали, поле «Статус клиента» содержало 47 различных формулировок в источнике — «Активен», «Active», «Активен» с пробелом, «А» — все это должно было быть сопоставлено с одним значением в Salesforce. Инструменты, такие как OpenRefine, простые SQL-запросы или даже сводные таблицы в Excel на выборке данных, достаточны для большинства проектов. Цель состоит в создании документа профилирования, который показывает: общее количество записей, процент пустых обязательных полей, количество уникальных значений для каждого категориального поля, а также предварительное выявление потенциальных дубликатов по имени, телефону или электронной почте. На этом этапе также определяется, существует ли несколько источников для одних и тех же данных – например, один и тот же клиент присутствует как в старой CRM, так и в бухгалтерской системе – и принимается решение, какой источник является «источником истины» (Source of Truth) для каждого поля. Такое решение должно быть задокументировано, а не подразумеваться, поскольку оно влияет на каждый последующий этап. ## Сопоставление полей: за пределами простого файла Excel Качественное сопоставление полей – это не просто "столбец А в источнике = поле B в целевой системе". Оно также включает направление преобразования: формат даты, конвертацию единиц, разбиение одного поля адреса на улицу/город/почтовый индекс, и решение для значений, отсутствующих в закрытом списке целевой системы. Лучший документ сопоставления, который мы видели, содержал пять столбцов: исходное поле, целевое поле, тип преобразования, правило обработки отсутствующих значений, и пример ввода/вывода. Отдельно следует рассматривать поля Lookup и Master-Detail: они содержат не прямое значение, а ссылку на другую запись, поэтому их сопоставление зависит от того, что соответствующая запись уже загружена и имеет идентификатор, на который можно ссылаться. Именно поэтому порядок загрузки (см. далее) и сопоставление полей являются двумя сторонами одного решения. Дополнительные сведения об управлении качеством полей с течением времени, а не только на одноразовом этапе, представлены в статье [Качество данных Salesforce](/ru/insights/salesforce-data-quality-metrics). ## Очистка и дубликаты: до загрузки, а не после Очистка, выполняемая после того, как информация уже находится в производственной среде, обходится в разы дороже: она включает обновление активных записей, риск нарушения автоматизаций и процессов утверждения, а иногда и ущерб отчетам, которые уже были распространены руководству. Поэтому этап очистки должен происходить на промежуточном уровне (Staging), до того как данные попадут в Salesforce. Ключевые правила очистки, которые следует определить заранее: - Нормализация телефона и электронной почты (удаление пробелов, унификация международного формата). - Выявление дубликатов по комбинации полей (имя + телефон, или только ИНН для компаний). - Правило выбора основной записи (Master) при объединении дубликатов — например, самая актуальная или наиболее полная запись. - Обработка значений Null по сравнению с пустой строкой, чтобы избежать создания «ложных дубликатов». В типичном проекте, содержащем около 80 000 записей клиентов, адекватная очистка выявит от 3% до 8% реальных дубликатов. Значительно большее число указывает на то, что сам источник не поддерживался, и оправдывает обсуждение с владельцами бизнес-процесса перед продолжением. ## Внешние идентификаторы и порядок загрузки Внешний идентификатор (External ID) — это уникальное поле из исходной системы, которое также сохраняется в Salesforce и позволяет повторную загрузку (Upsert) без создания дубликатов при каждом повторном запуске файла. Без внешнего идентификатора каждый повторный запуск Data Loader может создать дополнительную копию одной и той же записи, поскольку система не может «идентифицировать» существующую запись. Порядок загрузки определяется зависимостями между объектами: невозможно загрузить контакт, пока не существует связанная с ним учетная запись; невозможно загрузить позицию заказа до самого заказа. | Этап | Объект | Зависимость | Примечание по External ID | | --- | --- | --- | --- | | 1 | Account | Без зависимости | Идентификатор клиента из исходной системы (ERP/старая CRM) | | 2 | Contact | Зависит от Account | Идентификатор контакта + Lookup на External ID Account | | 3 | Opportunity | Зависит от Account, Contact | Идентификатор сделки из исходной системы | | 4 | Product / PriceBook Entry | Без зависимости (загружается параллельно с этапами 1-2) | Артикул (SKU) как External ID | | 5 | Opportunity Line Item | Зависит от Opportunity, Product | Комбинация идентификатора сделки + строки | | 6 | Case / Activity History | Зависит от Account, Contact | Идентификатор обращения из исходной системы | Нарушение этого порядка — одна из самых распространенных ошибок в проектах миграции: команда, которая пытается «сэкономить время» и загружает все файлы параллельно, обнаруживает тысячи ошибок в Lookup, которые трудно отфильтровать постфактум, потому что неясно, вызвана ли ошибка отсутствием данных или неправильным порядком загрузки. ## Среды и тестирование Миграция не загружается напрямую в производственную среду. Рекомендуемая структура сред включает выделенную песочницу для миграции (отдельную от песочницы для текущей разработки), где загружается тот же объем данных и та же конфигурация правил валидации (Validation Rules) и триггеров (Triggers), что и в производственной среде, чтобы выявить проблемы до того, как они затронут реальных пользователей. Тестирование на этом этапе включает проверку объема (завершается ли загрузка в разумные сроки), проверку ошибок (какой процент записей отклонен и почему), а также проверку поведения автоматизаций — Flow или Trigger, который запускается при создании записи, может отправить реальное электронное письмо клиенту, если его временно не отключить в тестовой среде. Забывчивость такой детали в одном проекте привела к отправке тысяч дублирующих электронных писем «Добро пожаловать» существующим клиентам. ## Тестовый запуск (Dry Run): полное повторное выполнение Тестовый запуск (Dry Run) – это полное выполнение процесса загрузки в условиях, максимально приближенных к производственным – тот же объем, те же файлы, тот же порядок – но в песочнице. Цель – измерить две вещи: фактическое время выполнения (для реалистичного планирования окна Go-Live) и процент ошибок на каждом этапе. Рекомендуется выполнить как минимум два полных тестовых запуска: первый выявляет большинство проблем, второй гарантирует, что исправления действительно их устранили и не создали новых. Если второй запуск все еще генерирует более 1%-2% ошибок в критических объектах, обычно лучше перенести дату Go-Live, чем идти на компромисс с качеством. ## Cutover и сверка данных (Reconciliation) Cutover — это фактическое окно, в течение которого старая система замораживается (Freeze), самые актуальные данные загружаются в Salesforce, и пользователи переходят к работе в новой системе. Успех на этом этапе измеряется не только в том, «завершилась ли загрузка», но и в сверке (Reconciliation) — систематическом сравнении источника и целевой системы. Чек-лист для сверки, который следует выполнить по завершении каждого Cutover: - ☐ Количество записей совпадает (или разница объяснима) для каждого основного объекта. - ☐ Суммирование финансовых полей (например, общая стоимость открытых возможностей) соответствует между источниками. - ☐ Случайная выборка из 30-50 записей проверена вручную по каждому полю. - ☐ Проверка связей — есть ли у каждого контакта действительный Account, у каждой позиции сделки — сделка. - ☐ Проверка «осиротевших» записей — загруженных без действительной ссылки. - ☐ Сравнение количества дубликатов до и после, с целью, установленной на этапе очистки. - ☐ Подтверждение от владельца бизнес-процесса, что выборка данных кажется корректной. Распространенные расхождения при сверке включают: количество записей совпадает, но суммы не соответствуют, потому что числовое поле было загружено в неправильном формате; или отсутствуют связи, потому что Lookup был загружен по текстовому значению, а не по External ID. Полная документация процесса сверки, включая пример базового уровня, также доступна в статье [Управление нормативно-справочными данными Salesforce](/ru/insights/salesforce-master-data-management). ## Исправления после запуска в эксплуатацию (Go Live) Даже после успешного Go Live остаются «хвосты» исправлений: отдельные записи, отклоненные при загрузке, сообщения пользователей об отсутствии данных и расхождения, выявляемые только при работе реальных пользователей с системой, а не только при ее проверке. Необходимо заранее выделить окно от двух до четырех недель для целенаправленных исправлений, с ежедневным отчетом об исключениях в первую неделю и еженедельным после этого. Важно различать точечное исправление (отдельная запись, обновленная вручную) и системное исправление (ошибка сопоставления, повторяющаяся в тысячах записей и требующая исправления в самом инструменте загрузки и повторного запуска). Смешение этих двух ведет к тому, что команды вручную исправляют фактически системную проблему, тратя на это много времени. ## Пример организационного сценария Дистрибьюторская компания с примерно 120 000 клиентов в старой CRM и отдельным списком клиентов в бухгалтерской системе запросила миграцию обоих источников в единую систему Salesforce. Первичное профилирование показало, что 11% клиентов присутствуют в обоих источниках с различными контактными данными, а поле «Отрасль деятельности» содержало 340 свободных значений, которые должны были быть около 25 категорий. Команда разработала детальное сопоставление полей, установила правило объединения по комбинации ИНН и телефона, а также определила бухгалтерскую систему как «источник истины» для платежных реквизитов, а старую CRM — как «источник истины» для контактной информации. Первый тестовый запуск (Dry Run) выявил, что 4% записей были отклонены из-за неверного формата даты — исправление, которое было учтено во втором запуске. Cutover был выполнен в конце недели, с полной сверкой (Reconciliation) в воскресенье утром, до открытия системы для пользователей. Результат: менее 0,3% записей потребовали ручной корректировки после Go Live, в то время как первоначальная оценка команды ожидала около 5% отклонений. Разница почти полностью объясняется двумя тестовыми запусками (Dry Run), выполненными до официального Go Live. ## Распространенные риски и профилактические меры | Риск | Как это проявляется на практике | Меры предотвращения | | --- | --- | --- | | Неконсолидированные идентификаторы | Один и тот же клиент инициирует дублирующие процессы | Правило объединения по External ID и Golden Record | | Загрузка без External ID | Повторный запуск создает новые дубликаты | Определить External ID до первого запуска | | Неправильный порядок загрузки | Массовые ошибки Lookup, которые трудно отфильтровать | Загрузка по заранее определенной таблице зависимостей | | Пропуск Dry Run | Окно Go-Live затягивается, и сюрпризы обнаруживаются в реальном времени | Как минимум два полных запуска в тестовой среде | | Отсутствие сверки (Reconciliation) | Корректное количество записей, но неверные суммы и связи | Проверки количества, суммы, связей и выборки при каждом Cutover | На уровне управления миграцией данных в Salesforce эта таблица рисков является лишь отправной точкой. Подробнее об управлении качеством на постоянной основе, включая различие между однократной очисткой и текущим управлением данными, можно найти в [Data 360 Zero Copy](/ru/insights/data-360-zero-copy-federation). ## Как измерить успех | Область | Что измеряется | Частота проверки | | --- | --- | --- | | Полнота | Доля заполненных обязательных и критически важных полей | До и после каждой загрузки | | Уникальность | Доля дубликатов по сущности | Перед Dry Run и после Cutover | | Валидность | Значения, соответствующие правилам формата и бизнеса | В каждой партии загрузки | | Сверка (Reconciliation) | Соответствие количества, сумм и связей источнику | При каждой репетиции и Cutover | | Время выполнения | Фактическая продолжительность загрузки по сравнению с запланированным окном Cutover | При каждом запуске Dry Run | Для большинства проектов достаточно от трех до пяти показателей для первой версии. Хороший показатель может быть рассчитан до и после изменения, связан с владельцем бизнес-процесса и не может быть искусственно улучшен путем частичного ввода данных. Если нет задокументированного базового уровня из старой системы, стоит потратить один-два дня на оценку текущего состояния, прежде чем сообщать об улучшении. ## Чек-лист перед запуском в эксплуатацию (Go Live) - ☐ Профилирование источника выполнено и включает процент пустых полей и дубликатов. - ☐ Документ сопоставления полей заполнен, включая преобразования и обработку отсутствующих значений. - ☐ External ID определен для каждого объекта, требующего повторной загрузки. - ☐ Порядок загрузки задокументирован и согласован технической командой. - ☐ Выполнено два тестовых запуска (Dry Run), и количество ошибок снизилось ниже установленного порога. - ☐ Написан сценарий отката (Rollback) на случай сбоя Cutover. - ☐ Чек-лист сверки (Reconciliation) готов, и ответственный за его выполнение известен заранее. - ☐ Окно для исправлений после Go Live выделено в расписании. - ☐ Автоматизации, которые могут отправлять сообщения клиентам, проверены и отключены во время загрузки. - ☐ Владелец бизнес-процесса подписал окончательную выборку данных. ## Глубокие замечания по внедрению и сопровождению ### Примечание архитектора: миграция – это не одноразовое событие Даже после успешного запуска (Go Live), изменения в исходной системе (если она продолжает временно функционировать параллельно) или ручные исправления создают расхождения в данных. Поэтому рекомендуется поддерживать постоянный отчет о сверке (Reconciliation) — еженедельно в первый месяц, ежемесячно после — который сравнивает выборку данных между старыми и новыми отчетами и выявляет расхождения на ранней стадии. Проект, который рассматривает миграцию как финишную черту, упускает из виду, что качество данных — это непрерывный процесс. С точки зрения управления, истинный критерий успеха миграции данных в Salesforce заключается не только в том, были ли записи загружены, но и в том, могут ли менеджеры по данным, CRM и проектам доверять отчетам на следующий день, не проверяя каждую цифру вручную. Организации, которым требуется профессиональное сопровождение такого процесса, могут воспользоваться [услугами по интеграции и данным](/ru/integrations-data), которые охватывают как этап планирования, так и сам Cutover. ## Профессиональные источники - Salesforce Data 360 — [https://www.salesforce.com/data/](https://www.salesforce.com/data/) - Архитектура Salesforce Data 360 — [https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html](https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html) - HPI Pro – Интеграции и данные — [https://hpi.pro/integrations-data](https://hpi.pro/integrations-data) ### Вопросы и ответы **За сколько времени до Cutover необходимо выполнить первый тестовый прогон (Dry Run)?** Рекомендуется проводить полный тестовый прогон как минимум за три-четыре недели до даты Go Live, а второй тестовый прогон — за одну-две недели. Это дает время для исправления исключений, измерения фактической продолжительности загрузки и проверки, достаточно ли выделенного окна для Cutover даже с запасом прочности. **Что делать, если дубликаты клиентов обнаруживаются только после того, как система уже используется?** Примените правило объединения по бизнес-идентификатору (например, по нормализованному электронному адресу или регистрационному номеру компании), выберите главную запись на основе актуальности и полноты данных, а затем выполните слияние с помощью инструмента Merge или контролируемого процесса, который обновляет связи перед удалением дубликата. Такая операция требует полного резервного копирования перед выполнением. **Можно ли пропустить External IDs и полагаться только на имена для сопоставления записей?** Не рекомендуется. Имена повторяются, меняются между системами и могут содержать пробелы или различные символы. Уникальный External ID из исходной системы обеспечивает однозначное сопоставление, позволяет повторно загружать данные (Upsert) без дубликатов и значительно сокращает время на устранение неполадок. **Какой правильный порядок загрузки, если есть один файл, содержащий все типы записей вперемешку?** Необходимо разделить файл по объектам и сначала загрузить независимые сущности (учетные записи), затем зависимые сущности (контакты, возможности) и, наконец, связи и детали. Смешанная загрузка без порядка приводит к ошибкам поиска (Lookup Errors) и появлению "осиротевших" записей, которые сложно обнаружить впоследствии. **Сколько времени следует выделить на исправления после Go Live, прежде чем завершать проект?** Для среднего миграционного проекта рекомендуется выделить две-четыре недели тщательного мониторинга, в течение которых ежедневно проверяются отчеты об исключениях, расхождения в сверке и жалобы пользователей. Только после двух циклов чистой отчетности (две недели) можно объявлять закрытие этапа исправлений. --- ## Agentforce для организаций: когда он действительно подходит, а когда нет URL: https://hpi.pro/ru/insights/agentforce-for-enterprises Не каждый процесс заслуживает независимого AI-агента. Данное руководство предлагает операционную основу для принятия решений – зрелость данных, обоснование, разрешения и Human-in-the-loop – которая позволяет отличить целесообразные для Agentforce сценарии использования от тех, которые лучше оставить для классической автоматизации. ## Краткий ответ Внедрение Agentforce для организаций — это вопрос не «поддерживает ли это Salesforce», а зрелости: существует ли надежный источник информации, ясно ли, кто одобряет конфиденциальные действия, и какой базовый уровень определит успех или неудачу. Организация, которая игнорирует эти вопросы и сразу приступает к созданию агента, обнаружит недостатки на второй месяц, когда затраты растут, а результаты непоследовательны. Правильный подход начинается с систематизации процессов, продолжается проверкой готовности данных и разрешений, а завершается тщательно выверенным пилотным проектом с четкими критериями для продолжения или остановки. Те, кто еще только формирует базовое представление, могут начать с [Готовности к Agentforce](/ru/insights/agentforce-salesforce-ai-guide), где объясняется разница между Copilot, Flow и самим Agentforce. ## Шесть ключевых областей готовности Прежде чем выбрать первый вариант использования, стоит оценить организацию по шести направлениям. Каждая область, оставшаяся на уровне «неизвестно», представляет собой риск, который проявится во время пилотного проекта, а не до него. | Область готовности | Центральный вопрос | Распространенный тревожный сигнал | |---|---|---| | Зрелость данных и знаний | Существует ли единый, актуальный и утвержденный источник информации? | Устаревшая база знаний, противоречия между документами | | Обоснованность (Grounding) | Агент извлекает реальную информацию или догадывается? | Убедительные, но фактически неверные ответы | | Темы (Topics) и Действия (Actions) | Каждая тема определена в узких рамках? | Один агент, который должен «ответить на все» | | Разрешения и безопасность | Агент действует в соответствии с фактическими разрешениями пользователя? | Разрешение System, возвращающее информацию любому | | Человек в контуре (Human-in-the-loop) | Кто одобряет необратимые действия? | Финансовые или юридические операции без контроля | | Измерение и стоимость | Существует ли базовый уровень для сравнения? | «Это выглядит впечатляюще» без количественных показателей | ### Зрелость данных и знаний Хороший ИИ-агент настолько эффективен, насколько качественна информация, на которой он обучается. В сервисной организации с тремя несогласованными базами знаний агент будет обучаться на первом попавшемся источнике, даже если он наименее точный. Перед любой технической работой стоит проверить: когда в последний раз обновлялся каждый документ, кто несет за него ответственность и что происходит, когда два документа противоречат друг другу. Организации, пропускающие этот этап, приходят к пилотному проекту с агентом, который генерирует уверенные, но ошибочные ответы, что хуже, чем «я не знаю». ### Обоснованность (Grounding) Grounding – это механизм поиска, который предоставляет агенту реальную информацию перед тем, как он сформулирует ответ, вместо того чтобы полагаться на общие знания модели. Глубина этой темы, включая аспекты сегментации (Chunking), векторного поиска (Vector Search) и разделения внутренних и внешних источников, подробно описана в [Agentforce Grounding](/ru/insights/agentforce-grounding-rag). На уровне управленческого решения достаточно знать, что без надежного Grounding все остальные инвестиции – проектирование диалога, действия, интерфейс – строятся на шатком фундаменте. ### Темы (Topics) и Действия (Actions) Наиболее распространенная ошибка — создание одного агента с широкой темой, такой как «обслуживание клиентов», вместо нескольких узких тем, таких как «проверка статуса заказа» или «обновление платежных данных». Узкую тему легче проверять, легче объяснить пользователю, почему агент не ответил, и легче постепенно добавлять к ней действия. Само действие должно выполняться с ограниченными разрешениями, проходить проверку ввода и возвращать четкую ошибку, когда что-то не соответствует, вместо того чтобы предполагать продолжение. ### Разрешения и безопасность Агент, действующий с общими интеграционными разрешениями, может раскрыть информацию, которую пользователь не должен видеть – заработную плату другого сотрудника, заказ другого клиента, конфиденциальный внутренний комментарий. Профессиональная рекомендация заключается в том, чтобы запускать агента в контексте фактических разрешений пользователя (Run As User) везде, где это возможно, и документировать любое отклонение от этой модели как осознанное решение с ответственным. ### Человек в контуре (Human-in-the-loop) Не каждое действие требует одобрения человека, но каждое необратимое действие — да. Отправка возврата денежных средств, отмена заказа, изменение прав доступа – это те области, где лучше позволить агенту подготовить действие и остановиться перед его выполнением, по крайней мере, в первые месяцы. Со временем, когда показатели подтверждают высокую точность для определенного подмножества, одобрение можно отменять постепенно, а не сразу. ### Измерение и стоимость Стоимость Agentforce — это не только лицензирование, она включает в себя токены, вызовы API и инфраструктуру для мониторинга. Полная экономическая информация, включая примеры ценообразования и сценарии масштабирования, представлена в [цене Agentforce](/ru/insights/agentforce-cost-tco). Без базового понимания того, «сколько времени требуется агенту для выполнения задачи сегодня», невозможно определить, экономит ли агент деньги или просто добавляет уровень сложности. ## Таблица соответствия: Fit или No-Fit Такая таблица не заменяет глубокого анализа, но является инструментом быстрой фильтрации, прежде чем тратить недели на проверку варианта использования, который все равно не будет реализован. | Вариант использования | Соответствие | Причина | |---|---|---| | Ответы на часто задаваемые вопросы из актуализированной базы знаний | Высокое соответствие | Структурированная информация, низкий риск, измеримое улучшение времени ответа | | Проверка статуса заказа и обновление сведений о доставке | Высокое соответствие | Закрытые данные в системе, простое действие, легко проверяется | | Анализ многолетних тенденций продаж | Частичное соответствие | Требуется глубокий бизнес-контекст; подходит только для продвинутого этапа | | Одобрение кредита или изменение условий договора | Не подходит для начального этапа | Высокое финансовое влияние, требуется постоянное ручное одобрение | | Медицинские, юридические или регуляторные консультации для конечного пользователя | Не подходит | Риск судебных исков и ответственности; требует полного человеческого контроля | | Написание черновиков маркетингового контента для проверки человеком | Высокое соответствие | Вывод не окончательный, человек всегда проверяет перед публикацией | ## Реалистичный пилотный план ### Этап 1: Выбор одного варианта использования (неделя 1) Выбирается один процесс из таблицы с высоким уровнем соответствия, определяется базовый уровень (среднее время обработки, текущий уровень эскалации) и фиксируется, что будет считаться успехом. Бизнес-спонсор утверждает объем работ. ### Этап 2: Создание Grounding и первого Topic (недели 2-3) Подключается единый и проверенный источник информации, создается узкая тема с максимум 2-3 действиями, определяются разрешения в соответствии с пользователем. Каждое действие проходит проверку на некорректный ввод, прежде чем будет считаться готовым. ### Этап 3: Контролируемый внутренний запуск (недели 4-5) Ограниченная группа пользователей (5-15 человек) тестирует агента в реальных сценариях, включая ручное одобрение для всех важных действий. Собираются трассировки и ошибки по степени серьезности. ### Этап 4: Измерение относительно базового уровня (недели 6-8) Сравнение времени обработки, показателей успеха и стоимости с первым этапом. Здесь вступают в силу критерии «Go/No-Go»: - **Go**: Уровень выполнения задачи без эскалации выше 70%, стоимость задачи ниже, чем у человеческой альтернативы, ноль инцидентов безопасности или разрешений. - **Постепенное расширение**: Уровень выполнения 50-70% – продолжить, но сократить область применения до подзадачи с лучшими результатами. - **No-Go**: Уровень выполнения ниже 50% или один инцидент с разрешениями – вернуться к этапу данных и разрешений перед любым расширением. Более подробные проверки, включая методологию автоматических систем оценки, описаны в [Тестировании Agentforce](/ru/insights/agentforce-testing-scorers). ## Пример организационного сценария Сервисная компания с колл-центром из 40 операторов хотела внедрить Agentforce для снижения нагрузки. Руководство запросило «агента, который ответит на все». Проверка готовности показала, что существует три несогласованные базы знаний и большинство запросов требуют доступа к конфиденциальным платежным данным. Вместо того чтобы начинать с широкого охвата, команда выбрала один вариант использования: проверка статуса заказа, который не требует конфиденциальных финансовых данных. В течение шести недель агент обработал 62% таких запросов без эскалации, при значительно более низкой стоимости по сравнению с минутой разговора с оператором. В соответствии с критерием «Go», компания постепенно расширила возможности до второй темы – обновления адреса доставки – и только после этого начала рассматривать финансовые операции с постоянным ручным одобрением. Постепенный подход предотвратил полный провал, который произошел бы, если бы организация сразу перешла к «всезнающему агенту». ## Распространенные риски и действия по предотвращению | Риск | Как он проявляется на практике | Превентивные меры | |---|---|---| | Слишком широкий вариант использования | Невозможно измерить успех или предсказать поведение | Начать с одного узкого процесса с четкими границами | | Слабая обоснованность (Grounding) | Уверенные, но фактически неверные ответы | Единый источник информации, ответственный и регулярный процесс обновления | | Слишком широкие разрешения | Агент раскрывает информацию, которую пользователь не должен видеть | Запуск в контексте пользователя, а не системные разрешения | | Пропуск ручного подтверждения (Human Approval) | Финансовые или юридические действия выполняются без контроля | Обязательное ручное подтверждение для всех необратимых действий | | Отсутствие базового уровня | «Кажется, работает» без числовых доказательств | Измерение текущего состояния до запуска, а не после | ## Как определить, что пришло время для расширения Расширение оправдано, когда одновременно выполняются три условия: ключевой показатель стабилен на протяжении трех последовательных циклов измерений, за измеряемый период не было инцидентов с разрешениями или безопасностью, а ответственный за процесс готов подтвердить, что результат эквивалентен или лучше человеческой альтернативы. Если одно из условий не выполняется, лучше продлить этап пилотного проекта еще на две недели, чем расширяться, основываясь на хороших ощущениях. ## Чек-лист перед принятием решения - ☐ Выбран один вариант использования с четкими границами, а не «общий агент». - ☐ Существует проверенный и актуальный источник информации для выбранной области. - ☐ Разрешения агента соответствуют фактическим разрешениям пользователя. - ☐ Определены точки ручного подтверждения (Human Approval) для необратимых действий. - ☐ Базовый уровень измерен до запуска, а не только после. - ☐ Существуют заранее определенные критерии «Go/No-Go». - ☐ Существует план мониторинга трассировок и ошибок. - ☐ Определен ответственный за поддержку источника информации. ## Заключение: когда стоит и когда не стоит Agentforce подходит, когда есть узкий процесс с надежным источником информации, когда влияние ошибок относительно низкое и когда есть способ измерить успех по отношению к реальному базовому уровню. Он менее подходит – по крайней мере, на начальном этапе – для процессов с высоким финансовым или юридическим влиянием, для организаций, где информация все еще разрознена и не поддерживается, или когда руководство ожидает немедленного результата без этапа пилотного проекта. Организации, которые соблюдают этот порядок действий — сначала готовность, затем измеренный пилотный проект, и только потом расширение — достигают гораздо более стабильных результатов, чем те, кто сразу переходит к разработке. Фактическую интеграцию можно осуществить совместно со [службой Agentforce и ИИ](/ru/agentforce-ai), которая сопровождает организацию от этапа проверки соответствия до контролируемого расширения. ## Профессиональные источники - Salesforce – Как работает Agentforce — https://www.salesforce.com/agentforce/how-it-works/ - Salesforce – Защитные меры Agentforce — https://help.salesforce.com/s/articleView?id=ai.agent_plan_risks_guardrails.htm&language=en_US&type=5 - Salesforce – Тестирование агентов с помощью пользовательских систем оценки — https://developer.salesforce.com/docs/ai/agentforce/guide/testing-api-custom-scorers.html - HPI Pro – Agentforce и ИИ — https://hpi.pro/agentforce-ai ### Вопросы и ответы **В чем разница между подходящим для Agentforce сценарием использования и тем, который лучше реализовать как стандартный Flow?** Подходящий для агента сценарий требует принятия решений в реальном времени – выбора между несколькими путями на основе свободной речи или меняющегося контекста. Если процесс всегда следует одному и тому же фиксированному порядку, Flow или Apex будут дешевле, полностью тестируемы, и не потребуют мониторинга Traces. **Сколько задокументированных данных требуется до начала пилотного проекта Agentforce?** Идеальная документация не требуется, но необходим четкий источник истины хотя бы для одной области: актуальные статьи Knowledge, точные поля CRM или утвержденные документы политик. Если 30% ответов требуют человеческого уточнения из-за отсутствия или противоречивости информации, пилотный проект провалится из-за данных, а не из-за агента. **Может ли Agentforce действовать абсолютно без человеческого одобрения?** Да, для операций с низким риском, таких как извлечение информации или обновление нечувствительного поля. Для любого действия, влияющего на финансы, разрешения, внешнего клиента или необратимые данные, рекомендуется этап человеческого одобрения, по крайней мере, в первые три месяца после запуска. **Как измерить соотношение затрат и выгод от агента на практике, а не только в теории?** В рамках пилотного проекта продолжительностью 6-8 недель создается дашборд, показывающий стоимость токенов и инфраструктуры по сравнению с количеством выполненных задач без эскалации. Если стоимость задачи превышает сэкономленные затраты – например, час работы представителя – агент не готов к масштабированию, даже если он 'работает'. **Что произойдет, если пилотный проект не пройдет по критериям Go/No-Go?** Не стоит отказываться от проекта – сократите его объем. Чаще всего неудача связана со слабым обоснованием (Grounding) или слишком широким сценарием использования, а не с технологией. Разбейте процесс на одну узкую подзадачу, исправьте исходный источник информации и протестируйте снова, прежде чем инвестировать в дальнейшее масштабирование. --- ## 15 вопросов, которые необходимо задать перед выбором интегратора Salesforce URL: https://hpi.pro/ru/insights/questions-before-choosing-salesforce-integrator Большинство предложений по Salesforce на бумаге выглядят похожими, пока их не проверишь с помощью 15 целенаправленных вопросов. Руководство разбивает их на шесть тем — от команды до преемственности — и показывает разницу между слабым и надёжным ответом. ## Краткий вывод Предложения от различных интеграторов Salesforce практически всегда выглядят одинаково: те же слова, такие как Discovery (выявление требований), Agile (гибкая методология), Best Practice (лучшие практики), и то же обещание «тесного сопровождения». Истинная разница выявляется только при сравнении каждого предложения с конкретными вопросами, которые раскрывают подход поставщика, а не только то, что он предлагает поставить. Цель этих 15 вопросов — выявить расхождения до подписания договора, а не после того, как проект уже застрял. Вопросы разделены на шесть тем: команда, методология, архитектура, данные, коммерческие условия и непрерывность. К каждому вопросу прилагается краткое объяснение его важности и описание того, как звучит слабый ответ — чтобы его было легко распознать в реальном времени, на встрече или в документе предложения. Практические последствия выбора для всего процесса внедрения мы подробно описали отдельно в разделе [Компания по внедрению Salesforce](/ru/insights/choose-salesforce-implementation-company). ## Почему 15 вопросов, а не список технических требований Список технических требований — количество песочниц (Sandbox), какие лицензии, сроки SLA — важен, но недостаточен. Он проверяет, что поставщик обещает сделать, а не как он будет справляться с ситуацией, когда первоначальный план окажется неточным. Вопросы здесь выбраны потому, что они раскрывают рабочие паттерны: как команда документирует решения, как она справляется с "грязными" данными и что происходит, когда что-то идет не по плану. ## Сводная таблица: сильный ответ против слабого ответа | Тема | Сильный ответ звучит так | Слабый ответ звучит так | | --- | --- | --- | | Команда | "Консультант X руководит архитектурой, разработчик Y выполняет, предоставим резюме и возможность короткого собеседования" | "У нас опытная команда, назначим подходящих во время Kickoff" | | Методология | "Двухнедельные спринты, реальное демо в конце каждого спринта, общий бэклог в Jira" | "Мы работаем по Agile, это гибко и подходит для любого проекта" | | Архитектура | "Будем формировать ADR для каждого ключевого решения, включая отвергнутые альтернативы и причины отказа" | "Выберем лучшее решение, исходя из нашего опыта" | | Данные | "Проведем профилирование данных перед окончательным предложением, оценим качество источников" | "Будем заниматься очисткой данных в процессе разработки" | | Коммерческий | "Фиксированная цена за определенный объем работ, дополнительные часы по документированному запросу на изменение" | "Гибкий T&M, чтобы вас не ограничивать" | | Непрерывность | "Документ о передаче, обучение внутреннего администратора, две недели Hypercare после Go Live" | "Мы всегда рядом с вами, протокол прощания не нужен" | ## Команда: кто фактически будет работать над проектом ### 1. Кто будет фактически сопровождать проект, а не только на этапе предложения Этот вопрос критичен, потому что многие предложения представляют старшего члена команды на встрече по продажам и заменяют его младшим консультантом после подписания. Сильный ответ включает имена, должности и выделенный процент занятости. Слабый ответ звучит как "мы выберем наиболее подходящего по доступности" — то есть, нет реального назначения до последнего момента. ### 2. Сколько параллельных проектов ведет каждый консультант в то же время Консультант, ведущий пять проектов одновременно, не может уделять внимание деталям. Сильный ответ признает это ограничение и представит разумное число (обычно два-три проекта). Слабый ответ уклоняется или отвечает "зависит от нагрузки", без конкретного числа. ### 3. Что произойдет, если ведущий консультант уйдет посреди проекта Сильный ответ описывает документированный процесс передачи, две недели на совместную работу (Overlap) и постоянное документирование, которое позволяет замещать без потери знаний. Слабый ответ утверждает, что "у нас это почти не происходит" без плана на случай непредвиденных обстоятельств. Подробнее о правильной структуре работы с [консультантом Salesforce](/ru/insights/salesforce-consulting-guide). ## Методология: как фактически организуется работа ### 4. Как выглядит типичный спринт — что происходит, если что-то не готово вовремя Сильный ответ описывает Sprint Planning (планирование спринта), короткие Daily (ежедневные встречи), Demo (демонстрации) и ретроспективу, а также что происходит, если задача застревает — откладывается ли она на следующий спринт прозрачно. Слабый ответ ограничивается "мы работаем по Agile" без упоминания конкретных практик. ### 5. Как выглядит регулярное общение — канал, частота и ответственный Сильный ответ детализирует канал (Slack, Teams), еженедельную фиксированную встречу по статусу и единое контактное лицо для эскалации. Слабый ответ гласит "мы всегда будем доступны по электронной почте", что на практике означает отсутствие SLA на ответ. ### 6. Как проверяется работа, прежде чем она представляется клиенту как готовая Сильный ответ описывает внутреннее тестирование качества (QA), контрольный список приемки и проверку доступности и разрешений перед демонстрацией. Слабый ответ косвенно признает, что первая демонстрация клиенту является также и первой проверкой. ## Архитектура: как принимаются решения ### 7. Как документируются архитектурные решения и кто их утверждает Сильный ответ представляет краткий шаблон решения — проблема, альтернативы, выбор и причина — который сохраняется и доступен клиенту. Слабый ответ гласит "мы выбираем правильное решение" без документирования причин отказа от других альтернатив. ### 8. Как решение будет справляться с нагрузкой и ростом через два-три года Сильный ответ учитывает ограничения Governor Limits, ожидаемый объем данных и планирование расширения. Слабый ответ гласит "Salesforce масштабируема по своей природе" без связи этого с конкретным случаем. ### 9. Что происходит, когда новое требование конфликтует с предыдущим решением Сильный ответ описывает процесс Change Request (запроса на изменение), который оценивает влияние на уже построенное. Слабый ответ просто обещает "мы адаптируемся к любым изменениям", что чаще всего заканчивается накоплением скрытого технического долга. ## Данные: место, где большинство проектов застревают ### 10. Как проверяется качество данных до начала построения Сильный ответ включает ранний этап профилирования — дубликаты, пустые поля, несовместимые форматы — и график исправления. Слабый ответ откладывает это на "мы разберемся с этим во время миграции", что почти всегда удлиняет проект. ### 11. Что является источником истины для каждого типа данных и как обрабатываются дубликаты между системами Сильный ответ заранее определяет, какие системы "побеждают" при противоречиях (например, ERP против Salesforce для существующего клиента) и документирует правило. Слабый ответ гласит "Salesforce будет источником истины" в общем виде, не проверяя, верно ли это для каждого объекта. ### 12. Каков план резервного копирования и восстановления, и кто отвечает за него после внедрения Сильный ответ детализирует средства резервного копирования, частоту и кто фактически выполняет восстановление при необходимости. Слабый ответ предполагает, что Salesforce "уже позаботится об этом", не различая резервное копирование платформы и резервное копирование на уровне организации. ## Коммерческие условия и непрерывность: что происходит после подписания ### 13. Как формируется цена — фиксированная, T&M или комбинированная, и что фактически включено Сильный ответ разбивает цену на этапы работ с примерными часами для каждого, и определяет, что считается запросом на изменение (Change Request) за дополнительную плату. Слабый ответ дает одно общее число без разбивки, что затрудняет сравнение предложений. ### 14. Что произойдет, если проект выходит за рамки сроков — кто несет затраты Сильный ответ различает превышение сроков, вызванное поставщиком (за его счет), и превышение сроков, вызванное изменением требований клиента (за плату). Слабый ответ формулируется неопределенно, что позволяет поставщику переложить любую задержку на клиента. ### 15. Что происходит по завершении проекта — какая поддержка, на какой срок и по какому тарифу Сильный ответ включает определенный период Hypercare (обычно две-четыре недели), документ о передаче и обучение внутреннего администратора. Слабый ответ обещает "постоянную поддержку" без четкого тарифа, объема или даты окончания. Подробнее о правильной формулировке таких пунктов договора в [SOW проекта Salesforce](/ru/insights/salesforce-sow-contract-clauses). ## Пример организационного сценария Финансовая компания получила три предложения по объединению двух старых CRM-систем в одну Salesforce. Два из предложений были на 20-25% дешевле третьего. Когда CIO задал вопрос 10 (ранняя проверка качества данных), два более дешевых поставщика ответили: "мы разберемся с этим в рамках миграции" – тогда как более дорогой поставщик представил недельный план профилирования до подписания окончательной суммы. Организация выбрала более дорогого поставщика. Неделя профилирования выявила около 12 000 дубликатов записей и поле даты с несовместимым форматом в 3 источниках данных. Это раннее исправление было включено в первоначальную стоимость; у двух других поставщиков это обнаружилось бы во время миграции, как изменение объема работ с дополнительной оплатой. Урок здесь не в том, что "дешевое всегда плохо" — а в том, что разница между подробным и общим ответом стоит реальных денег, и ее можно выявить только с помощью целенаправленных вопросов до подписания, а не после. ## Контрольный список для сравнения предложений - ☐ Мы получили имена и процент занятости предложенной команды, а не только общее описание. - ☐ Мы проверили, как документируются архитектурные решения у каждого поставщика. - ☐ Мы запросили план профилирования данных до подписания. - ☐ Мы разбили цену на этапы работ с примерными часами. - ☐ Мы уточнили, кто несет затраты на превышение, не вызванное клиентом. - ☐ Мы получили четкое описание периода Hypercare и его условий. - ☐ Мы проверили рекомендации у клиентов с проектами аналогичного масштаба. - ☐ Мы убедились, что консультант, представленный на встрече, будет фактически работать. - ☐ Мы проверили, сколько параллельных проектов ведет каждый ведущий консультант. - ☐ Мы заранее определили, что будет доказательством успеха по завершении проекта. ## Завершающее замечание: вопросы — это инструмент, а не ритуал Цель 15 вопросов не в том, чтобы поставить поставщика в неловкое положение или излишне затянуть процесс выбора. Она заключается в том, чтобы заранее выявить, где предложение основывается на неписаных предположениях. Хороший поставщик не обидится на вопросы — он будет рад на них ответить, потому что это снижает его риски в будущем. Поставщик, который уклоняется от них или отвечает общей, повторяющейся фразой, тем самым дает ответ сам по себе. Если у вас нет внутренней компетенции для проведения такого процесса сравнения самостоятельно, [услуга консалтинга и анализа требований](/ru/consulting-discovery) является практическим путем для дальнейших действий — включая создание взвешенной оценочной таблицы, сопровождение на встречах с поставщиками и сравнение ответов по объективным критериям. ## Профессиональные источники - HPI Pro – Консалтинг и анализ требований — https://hpi.pro/consulting-discovery - Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html - HPI Pro – Услуги Salesforce — https://hpi.pro/services ### Вопросы и ответы **Сколько времени обычно занимает такое тщательное сравнение нескольких интеграторов?** Примерно три-четыре недели для серьёзного процесса: неделя на подготовку общего объёма работ, одна-две недели на встречи и получение письменных ответов, и неделя на сравнение и проверку рекомендаций. Более короткий процесс, как правило, основывается на первом впечатлении и упускает расхождения в предположениях. **Что делать, если поставщик отказывается отвечать письменно на некоторые вопросы?** Это серьёзный предупреждающий знак, а не техническая проблема. Устный ответ легко забыть или позднее опровергнуть. Если поставщик объясняет, что ответ «зависит от проекта», можно запросить диапазон или явное рабочее допущение – полный отказ оправдывает дальнейшую проверку у другого соискателя. **Можно ли задавать эти вопросы также существующему поставщику при продлении контракта?** Да, и иногда это важнее. Существующий поставщик, накопивший внутренние знания, со временем может перестать документировать и проверять себя. Повторная проверка каждые 12-18 месяцев выявляет износ в команде, документации или времени ответа до того, как это превратится в опасную зависимость. **Какой относительный вес следует придавать каждой из шести тем при принятии решения?** Единой формулы нет, но для первого проекта с большим объёмом данных из нескольких источников команде и данным вместе следует отдать около 45% оценки, методологии и архитектуре — около 35%, а коммерческим условиям и преемственности — остальное. При продлении существующего контракта вес переходит к преемственности и коммерческим условиям. **Что предпочтительнее – поставщик, предлагающий низкую цену с общими ответами, или более дорогой поставщик с подробными ответами?** Подробный ответ почти всегда ценнее. Разница в цене в 15-20% значительно меньше по сравнению со стоимостью переделок из-за ошибочных предположений о данных или разрешениях. Низкая цена с неясным объёмом работ часто означает ту же работу с последующими «сюрпризами». --- ## Как реанимировать застрявший проект Salesforce? Методология диагностики и спасения URL: https://hpi.pro/ru/insights/rescue-stalled-salesforce-project Застрявший проект Salesforce часто кажется результатом ошибок в разработке, но в большинстве случаев это комплексная проблема, включающая неясность функциональных требований, отсутствие архитектурных решений и утрату доверия. Данное руководство предлагает 10-дневный план диагностики и 90-дневную стратегию спасения. ## Краткий ответ Большинство проектов Salesforce, которые «застревают», сталкиваются с проблемами не из-за плохого кода. Они тормозятся, потому что никто своевременно не задается вопросом о том, что именно меняется в работе пользователей, кто несет ответственность за каждое решение и что происходит, когда что-то идет не по плану. Результат: спринт за спринтом добавляются новые функции, но общая картина не улучшается. Спасение «застрявшего» проекта Salesforce означает сначала остановить «кровотечение», а затем решить, что делать с уже созданным. Этот порядок критически важен: многие организации приступают непосредственно к этапу исправления, не проведя предварительную диагностику причин провала предыдущего процесса, и повторяют ту же ошибку во второй раз. Те, кто хочет понять, как приоритизировать накопившийся долг, могут углубиться в [приоритизацию технического долга Salesforce](/ru/insights/salesforce-technical-debt-prioritization). ## Признаки замедления: как понять, что проект сошел с правильного пути Существует разница между проектом, который движется медленно, и проектом, который уже остановился. Следующие признаки повторяются почти в каждом случае «спасения», которые мы осуществляли: - **Обсуждения статуса превращаются в объяснительные:** Еженедельное совещание по статусу проекта превращается в оправдания того, почему что-то еще не готово, без надежной новой даты завершения. - **Бэклог растет быстрее, чем скорость его закрытия:** Новые задачи добавляются каждую неделю, но количество закрытых задач остается постоянным или уменьшается. - **За последний месяц не было версии, протестированной реальным пользователем:** Только внутреннее демонстрация технической команды, без взаимодействия с теми, кто будет фактически работать с системой. - **Частое изменение требований без документирования:** Каждое обсуждение приводит к «еще одному небольшому изменению», которое не вносится в структурированный документ Scope Document. - **Откровенное недоверие:** Пользователи уже создают параллельные таблицы Excel «на всякий случай», и это признак того, что они перестали верить, что система заработает вовремя. Когда четыре из этих пяти признаков проявляются одновременно, речь идет о «застрявшем» проекте, а не о медленном, и эта разница меняет всю стратегию лечения. ## Диагностика за 10 дней: что проверять и в каком порядке Хорошая диагностика не требует двух месяцев. Десяти рабочих дней при правильном распределении ресурсов достаточно, чтобы получить достаточно достоверную картину для принятия решения. Рекомендуемое распределение: **Дни 1-2: Интервью и первичное картирование.** Короткие беседы со спонсором проекта, владельцем процесса, двумя-тремя конечными пользователями и руководителем команды разработки. Цель состоит в сборе различных версий «что пошло не так», а не в немедленном формулировании выводов. **Дни 3-5: Прямая техническая проверка.** Вход в сам Org: структура данных, существующая автоматизация, разрешения, журналы ошибок и медленные запросы. Здесь проверяется, является ли проблема архитектурной или операционной. **Дни 6-7: Сравнение обещанного с построенным.** Чтение исходных документов (SOW, User Stories, Design Docs, если имеются) по сравнению с фактическим состоянием в Sandbox или Production. **Дни 8-10: Формирование выводов и первоначальное решение.** Краткий документ, который классифицирует каждую найденную проблему как проблему Scope, архитектуры или доверия, и представляет первую рекомендацию: Reset, Refactor или продолжение в скорректированном темпе. ## Три уровня проблемы: охват, архитектура и доверие Наиболее распространенная ошибка – рассматривать каждую проблему как единое целое. На практике почти всегда это комбинация трех различных уровней, каждый из которых требует своего подхода. **Проблема охвата (Scope)** проявляется в том, что никто толком не знает, что входит в первую версию. Это происходит, когда первоначальное определение было слишком общим («управлять всем процессом продаж в Salesforce») и не было разложено на конкретные сценарии. Решение — это не еще одно совещание по планированию, а написание четкого списка Must/Should/Later, с назначением ответственного за каждый пункт. **Проблема архитектуры** проявляется в технических решениях, которые не выдерживают нагрузки в масштабе: модель данных, которая не поддерживает объем записей, автоматизация, которая работает в неправильном порядке, интеграция, которая незаметно падает. Здесь требуется глубокая техническая проверка, и иногда вовлечение [обновления системы Salesforce](/ru/insights/salesforce-system-upgrade-signs) в качестве параллельной инфраструктуры для исправления. **Проблема доверия** обычно является результатом первых двух, но она приобретает собственную жизнь: пользователи перестают сообщать о проблемах, потому что «все равно ничего не исправляют», а руководство перестает финансировать изменения, потому что «мы уже пробовали». Проблема доверия не решается заявлениями, а только небольшими и повторяющимися доказательствами. ### Таблица диагностики: симптом, первопричина и первое действие | Симптом | Вероятная первопричина | Рекомендуемое первое действие | | --- | --- | --- | | Каждое обсуждение приводит к новому требованию | Scope никогда не был закрыт, нет определения Out of Scope | Написать документ Scope с явным пунктом «что не включено в эту версию» и получить подпись | | Отчеты показывают противоречивые данные | Несколько источников истины для данных, без единого источника истины (Single Source of Truth) | Определить официальное поле/объект-источник и устранить дублирование отчетов | | Система «зависает» при умеренной нагрузке | Неэффективная автоматизация или циклы обновлений | Профилирование Flow и Apex под имитированной нагрузкой, до любого точечного исправления | | Пользователи возвращаются к Excel | Нет доверия, что система будет отражать реальное положение дел | Быстрое исправление одной ежедневной раздражающей проблемы и публичное сообщение об этом | | Техническая команда не объясняет свои решения | Разрывы в коммуникации между бизнесом и ИТ, не обязательно техническая проблема | Короткое разъяснительное совещание, на котором каждое техническое решение представляется в бизнес-терминах | | Каждый релиз сдвигает срок | Scope увеличивается во время работы без контроля | «Заморозка» изменений (Change Freeze) до завершения текущего цикла | ## Reset против Refactor: как принять решение Это центральное и самое дорогостоящее решение, поэтому оно должно основываться на критериях, а не на интуиции. Три теста помогают: 1. **Объем технического долга по сравнению с объемом уже работающего.** Если 70% функциональности работает удовлетворительно и только определенные части дают сбои, это Refactor. Если проблема коренится в базовой модели данных, почти всегда предпочтительнее частичный Reset. 2. **Стоимость объяснений по сравнению со стоимостью перестройки.** Если новой команде требуется более недели, чтобы понять, почему что-то было построено определенным образом, вероятно, будущие затраты на поддержку превысят стоимость чистой сборки. 3. **Состояние доверия пользователей.** Когда доверие очень низкое, целенаправленный и открытый Reset (с объявлением «мы начинаем новую, исправленную версию») иногда дает больше сотрудничества, чем тихое исправление, которое пользователи не замечают. На практике большинство успешных «спасений» являются гибридными: Reset для проблемного основного компонента (например, модели Opportunity или процесса утверждения), наряду с Refactor для остальной части системы. Подробное сравнение подходов приведено в [перестроить Salesforce](/ru/insights/salesforce-rebuild-vs-refactor), где описаны критерии для каждого сценария. ## 90-дневный план спасения | Этап | Дни | Основная цель | Измеримый результат | | --- | --- | --- | --- | | Стабилизация | 1-10 | Остановка ущерба, "заморозка" изменений в критических областях | Полная диагностика и список рисков | | Принятие решения | 11-20 | Reset или Refactor, окончательный Scope для первой волны | Подписанный документ с решением и ответственным | | Первая волна | 21-50 | Исправление наиболее болезненной для пользователей проблемы | Работающий и протестированный сквозной сценарий (End-to-End) | | Расширение | 51-75 | Добавление возможностей в соответствии с согласованным приоритетом | Два-три дополнительных процесса в использовании | | Стабилизация и завершение | 76-90 | Измерение относительно Baseline, передача управления | Дашборд, документация и план обслуживания | Важно спланировать этап «первой волны» вокруг одного процесса, который пользователи почувствуют в течение нескольких недель, а не вокруг наиболее интересного с технической точки зрения компонента. Проекты, которые терпят неудачу во второй раз, часто терпят неудачу потому, что возвращаются к той же ошибке: начинали с впечатляющей функциональности вместо реальной проблемы. Этот этап также напрямую связан с фактической производительностью, и тем, кто сталкивается с проблемами скорости отклика, рекомендуется ознакомиться со [повышением производительности Salesforce](/ru/insights/salesforce-performance-optimization). ## Восстановление доверия пользователей Доверие не возвращается благодаря презентации; оно возвращается благодаря последовательной модели небольших обещаний, которые выполняются. Несколько принципов, которые работали на практике: - **Четко объявите о маленькой победе.** Когда вы устранили повторяющуюся проблему, отправьте короткое сообщение, точно указывающее, что было исправлено и кто об этом просил. Такая прозрачность строит больше доверия, чем общий список достижений. - **Приглашайте пользователей на предварительное тестирование, а не только на UAT в конце.** Тот, кто видит промежуточную версию и чувствует, что его замечания были учтены, становится амбассадором проекта среди остальной команды. - **Не обещайте дату, в которой не уверены.** Дата, которая переносится в третий раз, наносит больший ущерб доверию, чем реальный, но менее оптимистичный график. - **Публично документируйте неудачи.** Когда что-то не сработало, короткое объяснение того, что произошло и что меняется, строит больше доверия, чем молчаливое игнорирование. Процесс восстановления доверия обычно занимает больше времени, чем само техническое исправление, поэтому его стоит планировать как параллельный путь к 90-дневному плану, а не как его автоматический результат. Организации, которым требуется структурированное сопровождение этого процесса, включая тесное сопровождение команды и руководства, могут использовать [сервис Salesforce Health Check](/ru/salesforce-health-check) в качестве полноценной рабочей среды. ## Пример организационного сценария Компания, предоставляющая финансовые услуги, работала над проектом Salesforce в течение девяти месяцев без запуска в эксплуатацию. Проверка показала, что Scope увеличился в три раза по сравнению с первоначальным планом, что техническая команда создала три различные версии одного и того же процесса утверждения без документирования причин, и что ключевые пользователи уже перешли на ведение ежемесячного отчета в отдельной таблице. 10-дневный диагностический план показал, что основная проблема не была технической: техническая команда получала противоречивые требования от двух разных менеджеров, не скоординированных друг с другом. Решение заключалось в частичном рефакторинге, а не в полном сбросе, поскольку большая часть кода была корректной. Первый этап был сосредоточен исключительно на процессе утверждения, который был основным источником разочарования, и в течение пяти недель была выпущена стабильная версия, совместно одобренная менеджерами. Только после этого продолжилось расширение остальных процессов. Основной урок: проблема не возникла из-за однократного технического сбоя, а из-за отсутствия единого ответственного за все решения. Такая роль, даже если она временная, зачастую является разницей между проектом, который успешно реализуется во второй раз, и проектом, который снова застревает. ## Чек-лист перед принятием решения о спасении - ☐ Выполнена 10-дневная диагностика с интервью, проверкой Org и сравнением с исходными документами - ☐ Проблемы четко классифицированы по категориям Scope, архитектура или доверие - ☐ Принято задокументированное решение о Reset/Refactor с обоснованиями - ☐ Выбран один процесс для первой волны на основе реальной проблемы пользователей - ☐ Определена «заморозка» изменений (Change Freeze) на период диагностики и принятия решения - ☐ Установлены базовые показатели (Baseline) перед началом исправления - ☐ Существует план регулярной коммуникации для пользователей и руководства - ☐ Назначен единственный ответственный за все решения - ☐ 90-дневный план включает измеримые этапы, а не только дату завершения - ☐ Определен процесс передачи управления (Governance) и обслуживания после завершения спасения ## Профессиональные ресурсы - Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html - HPI Pro – Salesforce Health Check — https://hpi.pro/salesforce-health-check - HPI Pro – Поддержка и сопровождение — https://hpi.pro/support ### Вопросы и ответы **В чем разница между 'медленным' и действительно 'застрявшим' проектом?** Медленный проект по-прежнему демонстрирует прогресс и принимаемые решения, пусть и в невысоком темпе. Застрявший проект — это тот, где две-три недели проходят без новых решений, без тестирования версии с реальными пользователями и без изменений в бэклоге. Если нет четкого ответа на вопрос 'Что произошло на этой неделе?', проект, скорее всего, застрял. **Кто должен руководить процессом диагностики: внешний консультант или кто-то из внутренней команды?** На этапе диагностики целесообразно привлечь внешнего эксперта. Он не несет ответственности за предыдущие решения и может задавать неудобные вопросы, не вызывая защитной реакции. Внутренняя команда должна быть полностью вовлечена в интервью и проверку данных, иначе выводы будут восприниматься как внешняя критика, а не как основа для совместных действий. **Можно ли спасти проект, не меняя поставщика или интегратора?** Да, и иногда это правильный путь, особенно когда проблема связана с объемом работ и коммуникацией, а не с техническим качеством. Необходимо рассмотреть три аспекта: принимаются ли текущей командой четкие решения, есть ли прозрачность в коде и документации, и присутствует ли искренняя готовность остановиться и внести исправления. Если ответы на все три вопроса отрицательные, замена становится актуальной. **Сколько времени потребуется, чтобы увидеть первые ощутимые улучшения для пользователей?** В проектах, где диагностика проведена качественно, первые ощутимые улучшения появляются в течение 3-4 недель с начала 90-дневного плана, обычно за счет устранения повторяющейся ошибки или сокращения повседневного процесса. Более глубокие структурные улучшения, такие как исправление модели данных, занимают от 6 до 12 недель в зависимости от объема технического долга. **Что делать, если первоначальный спонсор перестал верить в проект?** Это самый сильный индикатор необходимости спасения, а не повод сдаваться. Первый шаг — создать для спонсора небольшое, измеримое доказательство прогресса в течение двух недель, например, устранить ошибку, которая его лично раздражает ежедневно. Доверие восстанавливается через небольшие, повторяющиеся доказательства, а не через презентацию детального плана. --- ## Как определить MVP для проекта Salesforce, избегая создания временных систем URL: https://hpi.pro/ru/insights/salesforce-mvp-scope Разница между MVP и частично построенной системой заключается не в количестве функций, а в том, какие решения были приняты. Правильная первая фаза полностью закрывает модель данных и разрешения, ограничивая объем бизнес-процессов. В статье представлен четкий тест для определения границ MVP и таблица решений, которые можно и нельзя откладывать. ## Различия между MVP и временной системой Два проекта могут быть запущены с одинаковым количеством экранов, но один из них станет основой для роста, а другой — обузой, которую придется демонтировать. Разница не в объеме, а в характере компромиссов. Практическое правило: **в первой фазе сокращается бизнес-ширина, а не архитектурная глубина.** Допустимо сократить количество процессов, подразделений и типов входящих клиентов. Недопустимо сокращать ключевую модель данных, модель разрешений и определение источника истины — это закладывается один раз правильно, даже если на начальном этапе используется всего пятьдесят пользователей. Тот, кто сокращает глубину вместо ширины, получает систему, которая работает квартал, а затем перестраивается. Широкий контекст этапов проекта представлен в [Руководстве по внедрению Salesforce](/ru/insights/salesforce-implementation-guide). ## Три определения, которые часто путают | Термин | Что это на практике | Когда это уместно | Основной риск | | --- | --- | --- | --- | | Proof of Concept (PoC) | Доказательство технической реализуемости одного компонента | При наличии серьезных сомнений в возможности реализации | Склонны продвигать его в производство | | Pilot (Пилот) | Полное развертывание для ограниченной группы | Когда решение известно, а вопрос в его освоении | Группа недостаточно репрезентативна | | MVP | Первая рабочая версия, создающая реальную ценность | Когда хочется учиться на реальном использовании | Становится постоянным без принятия решения | Выбор между этими тремя понятиями не является семантическим. PoC можно отбросить, MVP — нет. Поэтому MVP должен создаваться только по производственным стандартам. ## Какие решения нельзя откладывать Существует группа решений, стоимость изменения которых возрастает на порядок после появления данных в рабочей среде. Эти решения включаются в первую фазу, даже если они охватывают лишь малую часть общей картины: - **Объект, который содержит бизнес-процесс**, и его отношение к ключевым сущностям. - **Уникальный ключ, который идентифицирует клиента** во внешних системах. - **Видимость по умолчанию** для каждого основного объекта. - **Структура владения записью** — кто является владельцем и что происходит, когда сотрудник уходит. - **Определение источника истины** для каждой сущности, синхронизированной с другой системой. Напротив, решения, которые можно и нужно отложить: разработка расширенных отчетов, удобные автоматизации, интеграция второстепенных каналов, локализация подразделений не первой очереди, а также интеграции, не требующие принятия решений в реальном времени. ## Как выбрать процесс для первой фазы Выбирается не самый простой и не самый проблемный процесс. Выбирается процесс, который одновременно отвечает трем условиям: у него есть один доступный владелец процесса, он дает результат, который виден руководству, и он представляет центральную модель данных. Процесс, отвечающий двум из трех условий, все еще возможен; процесс, отвечающий только одному, приведет к первой фазе, которая ничего не даст. Дополнительный фактор — объем: процесс, который происходит десять раз в месяц, не сгенерирует достаточного использования, чтобы извлечь из него уроки в течение квартала. ## Критерий выхода — что указывает на успешность фазы MVP без критерия выхода становится постоянным. Критерий должен быть измеримым, кратким и заранее известным. Пример структуры: - X процентов процессов выбранного типа выполняются в системе, а не за ее пределами. - Нет открытой блокирующей ошибки дольше определенного количества дней. - Данные, созданные за период, соответствуют заранее определенному порогу качества. - Владелец процесса подтверждает в письменной форме, что процесс выполняется без постоянных обходных путей. Обратите внимание, что ни один из этих пунктов не означает "система запущена". Эта дата является началом измерения, а не его концом. ## Стоимость отсрочки — инструмент для разрешения споров о масштабе Когда обсуждается, войдет ли функция в первую фазу, полезный вопрос не в том, сколько стоит ее построить сейчас, а в том, сколько стоит ее построить потом. Следующая таблица служит рабочим инструментом на встрече по определению объема: | Тип функционала | Стоимость разработки в первой фазе | Стоимость разработки во второй фазе | Вывод | | --- | --- | --- | --- | | Изменение в структуре ключевого объекта | Низкая | Очень высокая — включает миграцию | Включается в первую фазу | | Новая модель разрешений | Средняя | Высокая — раскрытие уже произошло | Включается в первую фазу | | Управленческий отчет | Низкая | Низкая | Откладывается | | Автоматизация оповещений | Низкая | Низкая | Откладывается | | Интеграция, необходимая для принятия решений в реальном времени | Высокая | Высокая + укоренившийся обходной путь | Включается, если процесс зависит от нее | | Интеграция только для отчетности | Средняя | Средняя | Откладывается | ## Пример для иллюстрации: Международная логистическая компания Сценарий гипотетический и предназначен для иллюстрации. Логистическая компания с деятельностью в трех странах хотела запустить MVP за одиннадцать недель. Первое предложение состояло в том, чтобы включить все три страны, но только этап предложения, без этапа заказа. Команда изменила подход: одна страна, но полный процесс от предложения до утвержденного заказа, включая интеграцию, которая подтягивает тарифы. Причина была проста — прерывание процесса посередине обязывало бы пользователей продолжать работу в старой системе на этапе заказа, то есть вводить данные дважды. Вместо того чтобы выяснить, помогает ли система, компания узнала бы, что система затрудняет работу. Общий объем работ в неделях остался примерно таким же. Изменилось то, что после первой фазы у компании был полный работающий процесс, а не половина процесса в трех странах. ## Признаки того, что MVP превратился во временную систему - Существует постоянный ручной процесс, предназначенный "для моста до следующей фазы", который работает уже два месяца. - Согласовано поле, используемое для двух разных целей, потому что не было времени его разделить. - Существует группа пользователей, работающих параллельно в двух системах. - Нет даты решения для следующей фазы, только лист ожидания. Эти паттерны подробно описаны наряду с другими ошибками в [Руководстве по распространенным ошибкам внедрения CRM](/ru/insights/crm-implementation-mistakes). ## Интеграция с общим графиком Определение MVP напрямую влияет на продолжительность проекта, и иногда в направлении, противоположном ожидаемому: слишком узкая первая фаза удлиняет *общий* проект, потому что каждая фаза несет фиксированные затраты на тестирование, обучение и запуск. Как это перевести в детальное реалистичное планирование, описано в [Руководстве по продолжительности проекта Salesforce](/ru/insights/salesforce-project-timeline), а в случае замены существующей системы также в [Руководстве по переходу на Salesforce](/ru/insights/replace-crm-with-salesforce). ## Следующий шаг Напишите одним предложением, какой процесс является основным для первой фазы, кто его владелец, и какой критерий через квартал укажет на его успех. Если одно из трех предложений пока невозможно написать — это отправная точка, а не список функций. ### Вопросы и ответы **Каков разумный размер MVP в проекте Salesforce?** Единых правил нет, но есть практический тест: первая фаза должна охватывать один полный сквозной бизнес-процесс для одной группы пользователей с данными, которые действительно требуются для этого процесса. Если для соблюдения объема приходится "резать" процесс посередине, это признак того, что выбран слишком большой процесс, а не MVP слишком мал. **Можно ли отложить интеграцию с основной системой до второй фазы?** Можно, при условии, что процесс первой фазы не зависит от нее для принятия решений. Если продавцам придется открывать ERP параллельно, чтобы узнать запасы или кредитный лимит, откладывание интеграции не экономит работу, а создает обходную практику, от которой потом будет трудно отказаться. **Кто решает, что не войдет в MVP?** Решение принадлежит бизнес-спонсору по рекомендации владельца процесса и архитектора, а не комитету. Причина практична: исключение функциональности из первой фазы — это политическая уступка, и только орган с бюджетными полномочиями может это поддержать, чтобы функциональность не вернулась через запросы на изменения. **Как предотвратить превращение MVP в постоянную систему?** Заранее устанавливайте измеримые критерии выхода и дату принятия решения для следующей фазы, а не просто список продолжений. Кроме того, не разрешайте первой фазе обходить архитектурные решения: система, которая остается постоянной на основе правильной модели данных, является разумным результатом, а система, которая остается постоянной на основе временного решения, является долгом. **Подходит ли MVP для замены существующей CRM?** Да, но границы определяются иначе. При замене существует давление, чтобы перенести все, что делала старая система, поэтому первая фаза определяется по группе пользователей или бизнес-подразделению, а не по подмножеству функций. Параллельная работа двух систем для одной и той же группы создает двойную работу и снижает надежность данных. --- ## Команда проекта Salesforce: роли, обязанности и модель взаимодействия с поставщиком URL: https://hpi.pro/ru/insights/salesforce-project-team-roles Две ключевые роли, определяющие своевременность реализации проекта Salesforce, почти всегда находятся на стороне клиента, а не поставщика. Здесь мы определяем девять необходимых ролей, их критическое значение, какие позиции нельзя аутсорсить, а также как выглядит матрица RACI, предотвращающая задержки в принятии решений. ## Роли, определяющие темп проекта В проекте Salesforce можно нанять выдающегося архитектора, опытную команду разработчиков и организованного менеджера проекта, но все равно отстать от графика. Частая причина — не скорость разработки, а скорость принятия решений. Разработка ждет решения, решение ждет встречи, а встреча ждет своей даты в календаре. Поэтому полезное распределение ролей определяется не тем, *кто что делает*, а тем, **кто что решает и с какой скоростью реакции**. Обзор этапов, на которых требуется каждая роль, представлен в [Руководстве по внедрению Salesforce](/ru/insights/salesforce-implementation-guide). ## Девять ролей и полномочия каждой **Executive Sponsor** — разрешает конфликты между отделами, утверждает уступки по объему работ (Scope) и защищает приоритеты от параллельного давления. Если у него нет бюджетных полномочий, он не Executive Sponsor, а представитель. **Владелец процесса** — определяет, как работа будет выполняться на деле после изменений, и подтверждает соответствие построенного процесса реальности. Один владелец на каждый ключевой процесс, а не комитет. **Product Owner / CRM-менеджер** — управляет приоритетами в бэклоге, разрешает конкурирующие запросы и поддерживает связь между требованиями и ценностью. **Менеджер проекта** — отвечает за график, взаимозависимости, риски, координацию поставщиков и отчетность. **Архитектор решения** — принимает решения по модели данных, разрешениям, границам системы и способу реализации; обязан документировать рассмотренные альтернативы. **Salesforce Admin** — конфигурация, среды, управление пользователями и текущее обслуживание после запуска. **Разработчик** — кастомизированная логика, интеграции, автоматизированное тестирование. **Владелец данных** — определяет источник истины, критерии корректной записи и кто одобряет загрузку. **Лидер по внедрению и обучению** — коммуникации, ролевое обучение, управление сопротивлением и измерение использования. В небольшом проекте один человек может выполнять две роли, но есть две пары, которые не следует объединять: архитектор и менеджер проекта (конфликт между тщательностью и скоростью), а также владелец процесса и лидер тестирования (проверяет сам себя). ## Кто должен быть внутренним специалистом | Роль | Может быть внешним поставщиком | Пояснение | | --- | --- | --- | | Executive Sponsor | Нет | Требует организационных полномочий | | Владелец процесса | Нет | Требует владения реальной работой | | Владелец данных | Нет | Требует регуляторной и бизнес-ответственности | | Product Owner | Частично | Возможно сопровождение, но не замена | | Менеджер проекта | Да | Часто и приемлемо | | Архитектор решения | Да | Желательно с внутренней поддержкой для передачи знаний | | Admin | Да, временно | Предпочтительно передать внутреннему специалисту до Go Live | | Разработчик | Да | Стандартно | | Лидер по внедрению | Частично | Внутренние коммуникации должны исходить от организации | ## Таблица RACI для ключевых точек принятия решений | Решение | Ответственный (Accountable) | Консультируемый (Consulted) | Требуемое время реакции | | --- | --- | --- | --- | | Структура модели данных | Архитектор | Владелец процесса, Владелец данных | До одной недели | | Изменение в объеме работ (Scope) | Executive Sponsor | Product Owner, Менеджер проекта | До одной недели | | Приоритеты в бэклоге | Product Owner | Владельцы процессов | До двух дней | | Определение обязательного поля | Владелец процесса | Admin | До двух дней | | Утверждение загрузки данных | Владелец данных | Архитектор | До трех дней | | Утверждение перехода в продакшн | Executive Sponsor | Менеджер проекта, Владелец процесса | По установленному регламенту | | Разрешение блокирующей проблемы | Менеджер проекта | Архитектор, Admin | В тот же день | Столбец "Требуемое время реакции" — самая интересная часть таблицы. RACI без SLA на принятие решений — это приятное описание, которое не меняет темп. ## Реальная доступность — повторяющаяся ошибка в планировании | Роль | Этап анализа требований | Этап разработки | Этап тестирования | Go Live и последующие недели | | --- | --- | --- | --- | --- | | Executive Sponsor | Низкая, постоянная | Низкая | Средняя | Средняя | | Владелец процесса | Высокая | Средняя | Очень высокая | Высокая | | Product Owner | Высокая | Высокая | Высокая | Средняя | | Admin | Средняя | Высокая | Высокая | Очень высокая | | Владелец данных | Средняя | Низкая | Высокая | Средняя | | Лидер по внедрению | Низкая | Средняя | Средняя | Очень высокая | Распространенная ошибка планирования заключается в предположении, что нагрузка на владельца процесса снижается после этапа анализа требований. На самом деле она снова возрастает на этапе тестирования, именно тогда, когда сотрудник возвращается к своей повседневной работе. ## Пример для иллюстрации: академический колледж Сценарий гипотетический и предназначен для иллюстрации. Колледж внедрил систему управления абитуриентами. Команда была правильно определена на бумаге, но "владелец процесса" был руководителем отдела регистрации, который мог уделять проекту лишь два часа в неделю. Любой вопрос о статусе абитуриента ждал до утра вторника. Через два месяца было установлено, что совокупная задержка в ожидании решений превысила задержки по всем остальным причинам вместе взятым. Решением не стало привлечение дополнительных разработчиков. Колледж назначил заместителя, которому был предоставлен явный мандат на принятие ежедневных решений до определенного уровня влияния, оставив руководителю отдела только решения, меняющие политику. Темп разработки увеличился без изменения численности команды поставщика. ## Модель работы с поставщиком Для большинства проектов достаточно трех механизмов: - **Совместный журнал решений** — каждое решение с датой, ответственным, обоснованием и отклоненными альтернативами. Это единственная документация, которая остается полезной спустя два года. - **Единая точка контакта с обеих сторон** — многочисленные прямые обращения участников к разработчикам являются верным способом потерять отслеживаемость. - **Циклические демонстрации с фиксированным ритмом** — владелец процесса видит работающий продукт, а не презентацию. Разрыв между ожиданиями и реализацией выявляется за две недели вместо двух месяцев. В крупных организациях требуется дополнительный уровень управления между бизнес-подразделениями, как описано в [Руководстве по внедрению Salesforce на предприятиях](/ru/insights/enterprise-salesforce-implementation). ## Точки соприкосновения с другими этапами Состав команды непосредственно зависит от двух факторов: результатов, необходимых на этапе анализа требований, подробно описанных в [Руководстве по CRM-диагностике](/ru/insights/crm-discovery-guide), и объема первой волны внедрения, который определяется правилами, приведенными в [Руководстве по определению MVP](/ru/insights/salesforce-mvp-scope). Более узкая первая волна требует меньшего количества владельцев процессов одновременно, что является самостоятельной причиной для уменьшения ее ширины. ## Быстрая проверка перед началом проекта Ответьте на четыре вопроса, используя имя и фамилию человека, а не название отдела: кто принимает решение, когда продажи и операционная деятельность не приходят к согласию; кто подтверждает, что построенный процесс соответствует реальности; кто говорит, какие данные достоверны; и кто будет поддерживать систему через год. Отсутствие ответа на один из этих вопросов — это самый большой риск в проекте, и это единственный риск, который нельзя решить деньгами. ### Вопросы и ответы **Сколько времени владелец процесса должен уделять проекту Salesforce?** На этапе определения требований обычно от трети до половины рабочей занятости, а на этапах тестирования и запуска иногда и больше. Распространенное заблуждение о достаточности еженедельной встречи является частой причиной задержек: ежедневные решения слишком малы, чтобы оправдывать отдельное совещание, но они блокируют разработку, когда нет того, кто может принять решение в тот же день. **Какие роли нельзя передавать поставщику?** Три роли: Спонсор, уполномоченный принимать решения между отделами; Владелец процесса, определяющий, как будет выглядеть работа; и Владелец данных, устанавливающий критерии надежности данных. Поставщик может предоставить архитектуру, разработку, управление проектом и даже управление изменениями, но он не может решать за организацию, что для неё правильно. **Нужен ли внутренний Salesforce администратор уже во время проекта?** Желательно, и не только ближе к завершению. Администратор, включившийся на этапе определения требований, знаком с причинами решений, а не только с их результатом, что позволяет ему в дальнейшем поддерживать и изменять систему. Администратор, получающий систему на неделе запуска, вынужден изучать архитектуру на основе конфигурации, что является медленным и подвержено ошибкам процессом. **В чем разница между Product Owner и руководителем проекта в контексте Salesforce?** Руководитель проекта отвечает за сроки, зависимости, риски и бюджет. Product Owner отвечает за приоритеты содержания: что будет создано в первую очередь, а что будет отложено. Когда эти роли объединены в одном человеке, одна из двух обязанностей, как правило, игнорируется — обычно приоритеты отодвигаются ради соблюдения сроков. **Как эффективно работать с удаленной внешней командой поставщика?** С помощью трех механизмов: единая точка контакта с обеих сторон, решения, документированные в общем журнале решений вместо электронной почты, и регулярные короткие демонстрационные сессии, на которых владелец процесса видит работающий результат. Языковые барьеры и часовые пояса терпимы; что неприемлемо, так это устное решение, которое никто не зафиксировал. --- ## UAT в проекте Salesforce: как тестировать бизнес-процессы, а не только экраны URL: https://hpi.pro/ru/insights/salesforce-uat-guide UAT, который выглядит как экскурсия по экранам, не выявит критичные ошибки, способные сорвать запуск. Тестирование должно охватывать полноценные сценарии, использовать данные, максимально приближенные к реальным, и проводиться конечными пользователями. Данное руководство предлагает методологию построения сценариев, модель категоризации дефектов и чёткие критерии готовности к развёртыванию. ## Почему UAT терпит неудачу, когда кажется успешным Во многих кругах пользовательского приемочного тестирования (User Acceptance Testing, UAT) все сценарии помечаются как пройденные, и через две недели после запуска в эксплуатацию поступают десятки обращений. Это не парадокс. Это прямой результат тестирования, построенного вокруг экранов. Тестирование, ориентированное на экран, задает вопрос: «Можно ли создать запись?». Тестирование, ориентированное на процесс, спрашивает: «Может ли агент принять обращение, идентифицировать существующего клиента по другому имени, проверить его правомочность в основной системе, открыть обращение, передать его другому сотруднику и закрыть его — при этом клиент дважды присутствует в системе?». Второй сценарий выявляет то, что пропускает первый. Данное руководство представляет структуру UAT, ориентированную на второй вопрос. Связь с другими этапами проекта описана в [руководстве по внедрению Salesforce](/ru/insights/salesforce-implementation-guide). ## Что должно быть готово до начала работы - **Стабильная среда**, которая не принимает развертываний в середине цикла, за исключением одобренных исправлений, блокирующих работу. - **Тестовые данные** по объему и сложности, аналогичные производственным. - **Пользователи с реальными разрешениями** — не Admin для всех. Половина проблем с разрешениями обнаруживается только тогда, когда тестировщик имеет правильный профиль. - **Определенные критерии приемки** для каждого основного процесса. - **Единый механизм отчетности** по дефектам с минимально обязательными полями. Чаще всего пропускается третий пункт, и именно он приводит к наиболее неудобным ошибкам в день запуска. ## Как создать сценарий, выявляющий проблемы Хороший сценарий начинается с персоны и исходного состояния, а не с клика. Рабочая структура: 1. **Кто** — точная роль и разрешение. 2. **Исходное состояние** — какая информация существует в системе до начала сценария. 3. **Что происходит** — бизнес-событие, запускающее процесс. 4. **Что делает тестировщик** — на уровне бизнес-операции, а не на уровне клика. 5. **Ожидаемый результат** — включая то, что произошло в других системах. 6. **Что не должно происходить** — запись не раскрывается тому, кому не следует, уведомление не отправляется дважды. Шестой пункт отличает чек-лист от профессионального тестирования. ## Шесть семейств сценариев, которые должны быть включены | Семейство | Пример сценария | Что выявляет | | --- | --- | --- | | Корректный путь | Полный сквозной процесс | В принципе ли процесс выполним | | Бизнес-исключение | Отмена, возврат, возврат на предыдущий этап | Логика, построенная только в одном направлении | | Проблемные данные | Дублирующийся клиент, имя на иврите и английском, пустое поле | Недостаточное сопоставление и очистка | | Разрешения | Пользователь, пытающийся получить доступ к записи другого подразделения | Пробелы в модели раскрытия | | Сбой интеграции | Целевая система недоступна | Обработка ошибок, циклы, дублирование | | Объем | Групповая операция над большим количеством записей | Ограничения производительности и автоматизации | Отсутствие целого семейства в списке указывает на то, что тестирование обеспечит ложную уверенность. ## Классификация критичности — условие для управления циклом Без согласованной классификации каждая ошибка кажется срочной, и решение о запуске в эксплуатацию становится предметом спора. Достаточна четырехступенчатая модель: | Уровень | Определение | Влияние на запуск в эксплуатацию | | --- | --- | --- | | Блокирующий | Невозможно завершить основной процесс, обходной путь отсутствует | Блокирующий | | Критический | Процесс возможен с серьезным обходным путем или сохраняются неверные данные | Блокирующий, если не одобрено явно | | Средний | Значительное неудобство, разумный обходной путь | Не блокирующий, включается в план исправления | | Низкий | Формулировка, порядок полей, улучшение | Откладывается до следующей итерации | Важное правило: классификацию определяет владелец процесса вместе с технической командой, а не тот, кто сообщил о дефекте. ## Условия перехода в производство Формулируются до начала цикла, а не в конце: - Ноль открытых блокирующих дефектов. - Каждый критический дефект закрыт или одобрен в письменной форме с обходным путем и временем исправления. - Все основные процессы были выполнены во втором цикле без новых сбоев. - Владельцы процессов подтвердили в письменной форме. - Существует проверенный, а не только написанный, план отката. ## Пример для иллюстрации: Пенсионный фонд Сценарий гипотетический и предназначен для иллюстрации. Пенсионный фонд тестировал процесс обработки обращений участников. Первый цикл UAT прошел почти полностью. Команда заметила, что все тестировщики использовали один расширенный профиль, поскольку точное назначение профилей задерживалось. Во втором цикле, с реальными профилями, было обнаружено одиннадцать дефектов: агенты не видели записи участников, переведенных между планами, кнопка одобрения исключения появлялась тем, кто не уполномочен, а отчет о нагрузках возвращал частичные результаты руководителям групп. Ни один из дефектов не был связан с функциональностью, протестированной в первом цикле — все они касались модели раскрытия. Практический вывод, принятый там: не начинать цикл UAT до тех пор, пока все участники не будут работать с профилем, который они будут использовать в производстве. ## Управленческие ошибки, удорожающие цикл - Развертывание версий в середине цикла, что обнуляет действительность уже выполненных тестов. - Тестировщики, сообщающие через WhatsApp и электронную почту параллельно с системой отслеживания. - Сценарии, написанные на уровне клика, что превращает любое изменение интерфейса в обновление документации. - Сокращение второго цикла из-за графика — это цикл, который выявляет регрессии. Эти паттерны появляются наряду с другими сбоями в [руководстве по распространенным ошибкам](/ru/insights/crm-implementation-mistakes), и ответственность за каждый из них определена в [руководстве по ролям команды проекта Salesforce](/ru/insights/salesforce-project-team-roles). ## При замене существующей системы В проекте замены добавляется вторая функция UAT: сравнение. Те же десять сценариев запускаются в обеих системах, и результаты сравниваются поле за полем. Это наиболее эффективный инструмент для выявления пробелов в сопоставлении до того, как они превратятся в пробелы в доверии. Последовательность действий при таком переходе подробно описана в [руководстве по замене CRM на Salesforce](/ru/insights/replace-crm-with-salesforce). ## Что остается после цикла Сценарии UAT не являются одноразовым документом. Они являются основой для регрессионного тестирования при каждом будущем выпуске, и они являются лучшим источником учебных материалов — потому что они написаны на языке процесса, а не на языке системы. Сохранение их в формате, который можно повторно запускать, является самой дешевой инвестицией, которую можно сделать на следующий год. ### Вопросы и ответы **Сколько времени стоит выделить на UAT в проекте Salesforce?** Практический диапазон составляет от двух до четырёх недель для среднего цикла, но ключевым фактором является не количество сценариев, а число циклов исправления. Планируйте как минимум два цикла: первый — для выявления дефектов, второй — для подтверждения, что исправления не привели к новым проблемам. UAT продолжительностью в одну неделю почти всегда заканчивается обнаружением проблем на этапе продуктивной эксплуатации. **Должен ли UAT проводиться на реальных данных?** Тестирование должно проводиться на данных, схожих с реальными по объёму и сложности, но адаптированных с учётом ограничений конфиденциальности. Тестирование на десяти чистых записях не выявит дубликаты, проблемные наименования, клиентов со сложной иерархией или отсутствующие исторические записи — а именно эти случаи часто вызывают проблемы в первую неделю продуктивной эксплуатации. **Кто должен писать тестовые сценарии?** Владельцы процессов при поддержке специалистов, знакомых с системой. Когда разработчики пишут сценарии, они отражают то, что было создано, а не то, что необходимо бизнесу. Роль технической команды — добавлять крайние случаи, а не определять тестируемый процесс. **В чём разница между UAT и интеграционным тестированием?** Интеграционное тестирование проверяет корректность взаимодействия систем: форматы, поля, обработку ошибок, производительность. UAT же убеждается, что пользователь может выполнить свою работу эффективно и что результат соответствует бизнес-требованиям. Можно успешно пройти интеграционное тестирование, но провалить UAT, если данные передаются, но бизнес-процесс невыполним. **Можно ли запускать систему в продуктивную эксплуатацию с открытыми дефектами?** Да, если они классифицированы и утверждены. Дефект без обходного решения, скорее всего, потребует отсрочки запуска; дефект с документированным обходным путём и согласованным сроком исправления может быть допущен. Чего точно нельзя делать, так это запускать систему с неклассифицированным списком дефектов, поскольку в этом случае решение фактически принимается пользователями в первую неделю продуктивной эксплуатации. --- ## Ценообразование проектов Salesforce: Фиксированная цена, Time & Materials или Retainer? URL: https://hpi.pro/ru/insights/salesforce-project-pricing-models Выбор модели ценообразования, в первую очередь, определяет, кто несет риск неопределенности. Фиксированная цена не всегда дешевле, а T&M не всегда рискованнее. Каждая модель подходит для определенного уровня зрелости определения объема работ. Здесь вы найдете карту соответствия, защитные механизмы для каждой модели и работающие гибридные подходы. ## Ценообразование — это не вопрос цены, а вопрос риска Когда организация выбирает между фиксированной ценой и моделью Time & Materials, она обычно задается вопросом, какая модель окажется дешевле. Это неверный вопрос. Обе модели подразумевают одинаковый объем работы; разница заключается в том, **кто несет дополнительные расходы, когда реальность отличается от предположений**. При фиксированной цене риск несет поставщик — поэтому он заранее закладывает маржу риска и защищает себя путем точного определения включенных работ. При модели T&M риск несет организация — поэтому ей необходимы механизмы контроля. При модели Retainer обе стороны получают стабильность в обмен на снижение гибкости. Простое правило: **чем более зрело определен объем работ (Scope), тем выгоднее фиксированная цена.** Чем больше неопределенности, тем предпочтительнее T&M с ограничением по верхней границе. ## Быстрое сравнение трех моделей | Аспект | Фиксированная цена | Time & Materials | Retainer | | --- | --- | --- | --- | | Кто несет риск, связанный с объемом | Поставщик | Организация | Разделяется в рамках согласованного объема | | Условия успеха | Четко определенный Scope | Прозрачность и тесное управление | Стабильный и предсказуемый спрос | | Гибкость к изменениям | Низкая, через запросы на изменения | Высокая | Средняя | | Управленческая нагрузка на организацию | Средняя, сосредоточена на определении | Высокая, постоянная | Низкая | | Типичный отказ | "Война" за Scope | Выход за рамки часов | Неиспользованные или поглощенные часы | | Хорошо подходит для | Определенный этап внедрения | Интеграция, миграция, исследование | Поддержка и постоянное улучшение | ## Фиксированная цена — когда применять и чего остерегаться Подходит, когда существует спецификация с критериями приемки, когда интеграции известны и задокументированы, и когда качество данных проверено. В такой ситуации поставщик может уверенно установить цену, а организация получает реальную бюджетную определенность. Механизмы защиты, которые стоит запросить: - Определение "завершено" для каждого результата, а не только его названия. - Явный список допущений, на которых основана цена. - Заранее согласованная ставка для запросов на изменения, чтобы она не устанавливалась в условиях кризиса. - График платежей, привязанный к приемке, а не к датам. Предупреждающий знак: фиксированная цена, предложенная без вопросов об объеме данных, количестве пользователей или исходных системах. Такая цена изменится, вопрос только в том, когда. ## Time & Materials — когда применять и как контролировать Подходит, когда существуют неизвестные факторы, устранение которых нецелесообразно: устаревшая основная система без документации, исторические данные неизвестного качества или постоянно меняющийся бизнес-процесс. Механизмы контроля, которые делают ее безопасной: - **Потолок для каждой вехи** с уведомлением при достижении согласованного процента от него. - **Отчетность на уровне задачи** — название задачи, часы, статус. - **Точки выхода** в конце каждой вехи без штрафных санкций. - **Согласованный состав команды** — сколько часов старшего и сколько младшего специалиста, чтобы он незаметно не менялся. Последний пункт часто забывают, и он влияет на стоимость больше, чем сама ставка. ## Retainer — когда он становится пустой тратой Retainer хорошо работает после запуска, когда есть постоянный поток запросов. Он перестает работать в двух противоположных ситуациях: когда спрос низкий и организация платит за неиспользованные часы, и когда значительная разработка впихивается внутрь и опустошает возможности поддержки. Два простых исправления: явное разделение между поддержкой и разработкой, и пункт о частичном переносе неиспользованных часов на следующий месяц с ограничением. Сочетание этих двух факторов стабилизирует модель. ## Гибридные модели, работающие на практике | Этап проекта | Рекомендуемая модель | Обоснование | | --- | --- | --- | | Консалтинг и спецификация | Краткосрочная фиксированная цена | Объем известен, результат определен | | Миграция данных | T&M с потолком | Качество данных выявляется по ходу | | Интеграции с устаревшими системами | T&M с потолком | Зависит от другой стороны | | Определенный этап внедрения | Фиксированная цена | Критерии приемки существуют | | Период стабилизации | Включено в стоимость этапа | Предотвращает споры о том, что является ошибкой, а что изменением | | Текущее обслуживание | Retainer | Постоянный спрос | Такое разделение кажется более сложным, чем одно соглашение, но оно сокращает именно те споры, которые задерживают проекты. ## Пример для иллюстрации: импортер медицинского оборудования Сценарий гипотетический и предназначен для иллюстрации. Импортер запросил предложение с фиксированной ценой для проекта, который также включал интеграцию с пятнадцатилетней системой управления запасами без документации API. Три полученных предложения имели очень широкий диапазон, а самое дешевое включало небольшую фразу: "При условии наличия доступного интерфейса REST". Организация провела краткое недельное исследование осуществимости до подписания. Выяснилось, что такого интерфейса нет и требуется промежуточный слой. Исследование изменило картину: интеграция перешла на модель T&M с потолком, а остальная часть проекта осталась по фиксированной цене. Краткое исследование предотвратило не дополнительные затраты — они возникли бы в любом случае — а договорной спор в середине проекта о том, кто несет ответственность за непроверенное предположение. ## Что влияет на цену больше, чем модель ценообразования - **Зрелость определения** — частичная спецификация удорожает любую модель. - **Количество исходных систем** и уровень их документации. - **Качество существующих данных**. - **Доступность владельцев процессов** в организации — задержка в принятии решений является прямыми затратами. - **Количество бизнес-подразделений**, которые должны прийти к согласию. Четыре из пяти пунктов находятся под контролем организации, а не поставщика. Именно поэтому инвестиции в подготовку делают проект дешевле, чем любые переговоры о ставках. ## От модели к соглашению После выбора модели решающее значение имеет формулировка: что будет считаться завершенным результатом, кто утверждает, и что происходит, когда другая сторона задерживается. Пункты, которые должны быть включены в соглашение, подробно описаны в [руководстве по контракту и техническому заданию для проекта Salesforce](/ru/insights/salesforce-sow-contract-clauses), а способ составления запроса, чтобы предложения были сопоставимы, описан в [руководстве по RFP](/ru/insights/salesforce-rfp-guide). Выбор типа услуги, которая изначально подлежит ценообразованию, подробно описан в [руководстве по услугам Salesforce](/ru/insights/salesforce-services-guide), а проверка самого поставщика — в [руководстве по выбору компании-интегратора](/ru/insights/choose-salesforce-implementation-company). ## Следующие шаги Прежде чем запрашивать ценовую политику, оцените три основных источника неопределенности в вашем проекте. Если вы можете назвать их по имени, вы готовы к фиксированной цене на часть работы. Если нет — первое, что нужно приобрести, это краткое исследование, которое их устранит, а не ценовое предложение на весь проект. ### Вопросы и ответы **Действительно ли фиксированная цена защищает бюджет в проекте Salesforce?** Фиксированная цена устанавливает стоимость определенного объема работ, а не всего проекта. При частичном определении объема разница покрывается за счет запросов на изменение, которые оплачиваются отдельно и зачастую по более высокой ставке. Фиксированная цена защищает бюджет только тогда, когда документ с описанием объема работ достаточно детализирован, чтобы обе стороны могли договориться о том, что включено, а что нет. **Когда модель Time & Materials предпочтительнее фиксированной цены?** Когда существует реальная неопределенность, которую невозможно устранить до начала работы, — например, при интеграции с устаревшими системами без документации, данных неизвестного качества или при изменяющихся бизнес-процессах. В таких случаях фиксированная цена просто переносит неопределенность в маржу риска, за которую вы платите независимо от того, реализовался риск или нет. **Что обычно включается в ежемесячный абонемент (Retainer) для среды Salesforce?** Обычно это обслуживание, поддержка, небольшие изменения конфигурации, управление релизами и мониторинг. Разработка новых функций должна быть вне абонемента или иметь четко определенный лимит, иначе она поглотит часы, предназначенные для поддержки, и создаст ощущение, что поставщик недоступен. **Как предотвратить завышение часов в модели T&M?** С помощью трех механизмов: согласованный лимит для каждой вехи с заблаговременным уведомлением о его приближении; отчетность по часам на уровне задач, а не на уровне месяца; и право организации остановить работу в конце каждой вехи. Все три механизма вместе обеспечивают лучший контроль, чем фиксированная цена, поскольку они позволяют вносить корректировки на ходу. **Можно ли комбинировать разные модели в одном проекте?** Да, и это зачастую правильный выбор. Распространенная схема: фиксированная цена для этапа проектирования, T&M с лимитом для интеграций и миграции, фиксированная цена для уже определенных этапов внедрения и Retainer после запуска. Такое разделение позволяет привязать каждую часть к модели, соответствующей уровню ее неопределенности. --- ## Salesforce Flow или Apex? Рамки для принятия решений по корпоративной автоматизации URL: https://hpi.pro/ru/insights/salesforce-flow-vs-apex Выбор между Flow и Apex зависит не от навыков команды, а от характера логики: количества записей в транзакции, зависимости от Governor Limits, необходимости Transaction Control и сложности условий. В статье представлен операционный тест для принятия решений, а не очередное общее сравнение возможностей. ## Краткий ответ Вопрос «Flow или Apex» часто получает неверный ответ при оценке по удобству разработки или доступности разработчиков. Правильный ответ зависит от четырех технических факторов: объем записей в одной транзакции, необходимость полной атомарности логики, сложность условий и ветвлений, и кто будет поддерживать компонент через год. Flow является правильной опцией по умолчанию для большинства бизнес-автоматизаций, но существуют четкие точки перехода, когда продолжение работы с Flow создает операционный риск, а не просто приводит к «менее элегантному коду». Данная статья посвящена самому процессу принятия решения: как заранее определить, что логика оправдывает использование Apex, и как предотвратить ситуацию, когда выбор делается по умолчанию, а не на основе обдуманного суждения. Вопрос очистки существующих Flow и процессов автоматизации, которые уже накопились как технический долг, рассматривается в отдельной статье и не является частью данного обсуждения. ## Фактические различия между двумя инструментами на уровне платформы Flow — это декларативный механизм, который во время выполнения транслируется в инструкции, выполняющие DML и SOQL от имени пользователя. Apex же представляет собой скомпилированный код, который работает в тех же губернаторских лимитах, но с прямым контролем над порядком операций. Первое практическое отличие заключается в балкификации (Bulkification): разработчик на Apex явно строит цикл, собирающий все записи в один массив и выполняющий одну DML-операцию, тогда как в Flow легко построить цикл, выполняющий DML-операцию или запрос на каждой итерации по отдельности. Такой подход гораздо быстрее исчерпывает лимит в 101 запрос. Второе отличие – контроль над транзакциями. Apex позволяет использовать `Savepoint` и `Database.rollback` для частичного отката, обработку `DmlException` на уровне отдельной записи через `Database.insert(list, false)` и сложную условную логику без ограничения глубины ветвлений. В Flow же обработка ошибок определяется на уровне Fault Path для каждого элемента, и это хорошо работает для линейных сценариев, но становится трудно отслеживаемым при наличии более чем нескольких параллельных путей отказа. ## Рамки принятия решения: четыре теста перед выбором инструмента ### Тест объема Эмпирическое правило: если процесс выполняется над одной записью в результате действия пользователя (создание лида, изменение статуса возможности), Flow почти всегда достаточно. Если процесс выполняется над десятками или тысячами записей за один раз – периодическое обновление, обработка пакета, поступающего из интеграции, запланированная очистка данных – Apex с `Batchable` или `Queueable` является безопасным выбором, поскольку он обеспечивает полный контроль над Bulkification и управлением губернаторскими лимитами при изменении объема. ### Тест атомарности Необходимо задать вопрос: если часть обновления завершилась неудачей, допустимо ли, чтобы другая часть сохранилась? Если ответ «нет» — например, обновление заказа и создание записи о выставлении счета должны произойти одновременно — Apex с Savepoint является правильным способом гарантировать это. Flow не обеспечивает полный откат между элементами без сложной ручной компенсационной логики. ### Тест сложности ветвей Flow с более чем 6-8 вложенными элементами Decision становится сложным для чтения и дорогим для тестирования, даже если каждая отдельная ветвь проста. Когда сложность бизнес-логики превышает этот уровень, написание той же логики в виде документированной функции Apex с модульными тестами (`@isTest`) обычно обходится дешевле в обслуживании, даже если начальное время написания дольше. ### Тест на поддержку и владение Необходимо ответить на вопрос, кто будет поддерживать компонент через год, а не на то, кто создает его сейчас. Если команда администраторов должна будет регулярно обновлять бизнес-правила — например, изменять условия скидок или пороговые значения — Flow предпочтительнее, даже если Apex технически «чище», поскольку он доступен для обновления без цикла развертывания. Если изменения требуют знаний схемы данных и регрессионного тестирования, Apex является правильным выбором, даже если есть только небольшая команда разработчиков для его поддержки. ## Таблица решений | Критерий | Выбрать Flow | Выбрать Apex | |---|---|---| | Объем записей в одной транзакции | До нескольких десятков | Сотни до тысяч | | Требование атомарности между несколькими объектами | Не критично | Критично — требуется полный откат | | Количество ветвей решения | До ~6-8 | Более, или рекурсивная логика | | Скорость изменения бизнес-правил | Часто, администратором | Редко, требует регрессионного тестирования | | Необходимость вызова сложного внешнего API | Простой одиночный вызов (HTTP Callout) | Логика повторных попыток, сложная аутентификация или пакетная обработка | | Требование автоматизированных тестов (CI) | Ограниченное | Полное, `@isTest` с покрытием | | Интеграция с постоянным запланированным заданием | Не подходит напрямую | Естественно через `Schedulable` | ## Пример сценария: компания по производству медицинского оборудования с процессом утверждения заказов Средняя компания по производству медицинского оборудования с примерно 40 торговыми представителями внедрила один Flow для процесса утверждения заказов: проверка запасов, расчет скидки, создание записи об утверждении и отправка уведомления менеджеру. Вначале это хорошо работало для одиночных заказов. Через полгода добавился новый сценарий — импорт партий заказов из файла интеграции с ERP, который создавал от 200 до 800 заказов одновременно. Flow, запускаемый через Record-Triggered Flow на уровне «для каждой записи», выполнял запрос на проверку запасов в рамках каждого отдельного запуска. При импорте 500 заказов система превысила лимит в 100 запросов в одной транзакции, и заказы завершились с ошибкой без четкого сообщения об ошибке для пользователя. Команда определила, что проблема не в самом Flow, а в несоответствии между процессом, разработанным для одной записи, и сценарием большого объема, который не существовал во время разработки. Решение заключалось не в том, чтобы отказаться от Flow. Команда разделила логику: Flow остался отвечать за ручной процесс обработки отдельных заказов (низкий объем, необходимость частых обновлений правил скидок администратором), тогда как процесс пакетного импорта был переведен на Apex Batch Job, который выполнял полную балкаризацию, проверял запасы одним централизованным запросом и выполнял одну DML-операцию для всех записей. Оба механизма вызывали один и тот же общий слой бизнес-логики (один Apex Class, который также вызывался Flow через Invocable Method), чтобы правило скидки не поддерживалось в двух местах. ## Распространенные риски и профилактические меры | Риск | Как это проявляется на практике | Профилактическая мера | |---|---|---| | Flow на постепенно увеличивающемся объеме | Процесс работал полгода, затем тихо завершился ошибкой из-за лимитов губернатора | Заранее оценить ожидаемый объем и запланировать переход на Apex до достижения предела | | Дублирование бизнес-логики в Flow и Apex | Два места рассчитывают скидку по-разному | Централизовать бизнес-расчеты в общем слое Apex, который также вызывается Flow | | Непредсказуемый порядок запуска триггеров | Несколько Flow и триггеров на одном объекте конфликтуют | Один централизованный обработчик триггеров (Trigger Handler) в Apex для каждого критического объекта | | Частичная обработка ошибок в сложном Flow | Часть записей обновляется, часть нет, без видимости | Перенести процессы, требующие атомарности, в Apex с Savepoint | | Apex без достаточного тестирования | Небольшое изменение ломает критический процесс при следующем развертывании | Требовать реальное покрытие тестами, а не только формальный процент, включая сценарии отказов | ## Чек-лист для принятия решения перед разработкой - ☐ Проверен ожидаемый объем на год, а не только текущее состояние - ☐ Определена необходимость атомарности процесса между несколькими объектами - ☐ Подсчитаны ожидаемые ветви решений в логике - ☐ Известно, кто будет поддерживать компонент и как часто будут меняться правила - ☐ Проверено, существует ли уже аналогичная логика в Apex или другом Flow для того же объекта - ☐ Определен порядок запуска триггеров, если на объекте используется несколько механизмов автоматизации - ☐ Если выбран Apex — определены тестовые сценарии, включая частичную неудачу - ☐ Если выбран Flow — определен Fault Path для каждого критического элемента ## Как это вписывается в общую архитектуру Выбор правильного инструмента для отдельной автоматизации — это лишь один уровень в более широкой картине [архитектуры CRM](/ru/insights/crm-architecture-guide), где как модель данных, так и разрешения влияют на то, к чему Flow или Apex вообще могут получить доступ. Когда автоматизация выходит за пределы внешней организации — например, проверка запасов с ERP в режиме реального времени — выбор между Flow и Apex также учитывается в соображениях [паттернов интеграции](/ru/insights/salesforce-integration-patterns) и вопроса о том, как [Salesforce соединяется с ERP](/ru/insights/salesforce-erp-integration) с точки зрения задержки и обработки сбоев. В организациях, использующих несколько Org-ов, также необходимо проверить, является ли бизнес-логика одинаковой во всех, — тема, обсуждаемая в [руководстве Один Org против нескольких Org](/ru/insights/salesforce-single-org-vs-multi-org), и влияющая на вопрос о необходимости централизации логики в общем Apex Package. ## Заключение Выбор между Flow и Apex — это не вопрос навыков команды или личных предпочтений, а результат четырех технических тестов: объема, атомарности, сложности ветвлений и частоты изменений. Flow является правильным решением по умолчанию для большинства автоматизаций, затрагивающих одиночные записи и часто меняющихся. Apex требуется при значительном объеме данных, необходимости полного контроля над транзакциями или когда логическая сложность превышает порог, который все еще можно поддерживать через декларативный интерфейс. Организация, которая внедряет эти тесты как часть рабочего процесса — а не оставляет их на усмотрение каждого разработчика — предотвращает большинство случаев, когда автоматизация, хорошо работавшая вначале, незаметно выходит из строя при увеличении объема. ### Вопросы и ответы **Можно ли начать с Flow и позже перейти на Apex, не нарушая процесс?** Как правило, да, если Flow построен вокруг четкого бизнес-события, а не вокруг конкретного экрана. Когда Flow вызывает процесс через Invocable Action или Subflow, внутреннюю реализацию можно заменить на Apex, не затрагивая триггер, разрешения или интерфейс. Проблема возникает, когда Flow и бизнес-логика переплетаются — тогда любое изменение требует перестройки, а не рефакторинга. **Может ли Flow обрабатывать одновременное обновление тысяч записей?** Технически да, но на практике это зависит от нагрузки логики внутри цикла. Flow, выполняющий запрос SOQL или DML внутри цикла для каждой записи, может достигнуть Governor Limits значительно раньше, чем аналогичный Apex, потому что Flow Engine не всегда выполняет автоматическое Bulkification с такой же эффективностью. Когда речь идет о постоянном, а не разовом массовом обновлении, Apex с Batch или Queueable является более безопасным выбором. **Что происходит, когда на одном объекте есть несколько Flow и Trigger-ов?** Порядок выполнения определяется настройками Salesforce, а не всегда намерениями команды, поэтому легко получить неожиданный результат, когда несколько механизмов затрагивают одну и ту же запись. Решение состоит в том, чтобы централизовать всю автоматическую логику центрального объекта вокруг одного Trigger Handler в Apex и использовать Flow только для процессов, которые не конфликтуют с критической логикой. **Когда стоит писать Apex, даже если Flow технически достаточно?** Когда логика включает одну транзакцию, которая должна полностью либо успешно завершиться, либо быть отменена — например, обновление двух связанных объектов, которые не должны оставаться рассинхронизированными. Flow обрабатывает ошибки на уровне отдельного элемента и не всегда обеспечивает полную атомарность, в то время как Apex позволяет контролируемые Savepoint и Rollback. **Всегда ли Apex дороже в обслуживании, чем Flow?** Не обязательно. Сложный Flow с десятками ветвей решений, интегрированными Subflow-ами и скрытой логикой внутри Formula Fields может быть сложнее для диагностики, чем документированный Apex с юнит-тестами. Стоимость зависит от объема логики и качества документации, а не от самого инструмента. --- ## Real-Time, Batch или Event-Driven: Выбор шаблона интеграции для Salesforce URL: https://hpi.pro/ru/insights/salesforce-integration-patterns Выбор неверного шаблона интеграции не проявляется во время демонстрации — это становится очевидным при увеличении нагрузки, минутном сбое внешней системы или одновременном обновлении одного и того же клиента двумя пользователями. Данное руководство представляет основу для принятия решений на основе всего трех вопросов: насколько быстро требуется получать информацию, кто является владельцем истины и что происходит при сбое. ## Три ключевых вопроса, определяющих архитектуру интеграции, а не выбор инструмента Часто при выборе интеграционного решения для Salesforce совершается ошибка, начиная с инструмента: будь то MuleSoft, Platform Events, Bulk API или простой Webhook. Инструмент — это следствие, а не отправная точка. Правильный подход определяется ответами на три следующих вопроса: 1. **Насколько быстро целевая система должна получить информацию?** Секунды, минуты, часы или дни — это определяет различие между режимами реального времени и пакетной обработки. 2. **Кто является владельцем данных в любой момент времени?** Если ответ на этот вопрос неоднозначен, ни одна техническая архитектура не решит проблему. 3. **Что происходит, если целевая система недоступна?** Ответ «подождем снова» не является решением. Необходимо определить четкое поведение: повторная попытка (Retry), постановка в очередь или явный отказ. Те, кто отвечает на эти три вопроса до выбора технологии, почти всегда приходят к тому же выводу, что и опытный архитектор, но без затрат на эксперименты и ошибки в производственной среде. Подробное описание связи этого решения с общей архитектурой представлено в [Руководстве по архитектуре CRM](/ru/insights/crm-architecture-guide). ## Карта шаблонов: когда какой шаблон уместен | Шаблон | Типичное время отклика | Типичный пример использования | Стоимость обслуживания | Основной риск | | :------------------------------ | :------------------------- | :---------------------------------------------------------------- | :------------------ | :--------------------------------------------- | | Синхронный Request-Reply | Миллисекунды до секунд | Проверка кредитоспособности перед одобрением транзакции | Средняя | Тайм-аут блокирует пользователя | | Fire-and-Forget | Мгновенно при отправке, без ожидания результата | Отправка события для создания задачи в другой системе | Низкая-средняя | Тихий сбой без мониторинга | | Периодическая пакетная обработка | Часы до суток | Синхронизация каталога продуктов раз в день из ERP | Низкая | Временные разрывы между системами | | CDC (Change Data Capture) | Секунды до минут | Обновление статуса заказа, влияющее на поддержку | Средняя-высокая | Нагрузка на Event Bus при множественных изменениях | | Event-Driven (Platform Events / Pub-Sub) | Секунды | Уведомление о бизнес-событии нескольким потребителям одновременно | Высокая при настройке, низкая при обслуживании | Требует дисциплины Schema и Versioning | Представленная таблица является отправной точкой для обсуждения, а не окончательным решением. Одна система может, а иногда и должна, использовать несколько шаблонов одновременно в зависимости от типа данных. ## Почему задержки недостаточно для принятия решения Вторая распространенная ошибка: принимать решения исключительно на основе задержки (Latency), игнорируя согласованность (Consistency). Быстрый шаблон, который обновляет только одну сторону и оставляет другую «почти синхронизированной», создает более серьезную проблему, чем медленный, но согласованный шаблон. Пользователи учатся не доверять данным и обходят систему. Правильный вопрос двойственен: насколько быстро требуется ответ **и насколько критична** ситуация, когда обе стороны на короткое время не синхронизированы. Процесс ценообразования, представленный клиенту, требует как скорости, так и полной согласованности — здесь необходим синхронный Request-Reply с определенным тайм-аутом и четкой обработкой сбоев. Обновление "количества просмотров статьи" может спокойно допускать задержку в несколько минут — здесь достаточно Fire-and-Forget или CDC. ## Владение данными: решение, предшествующее любому шаблону Прежде чем выбирать способ передачи данных между системами, необходимо определить, где они являются «истинными». Поле, которое обновляется в двух системах без определенного владельца, создает цикл синхронизации: A отправляет B, B обновляет и отправляет обратно A, A снова отправляет. Это не крайний сценарий — это ожидаемый результат двусторонней синхронизации без правила разрешения конфликтов. Практическое рабочее правило: для каждого общего поля назначается единственный владелец (Owner). Если существует реальная бизнес-потребность в редактировании с обеих сторон (например, служба поддержки клиентов обновляет адрес как в Salesforce, так и в ERP), добавляется явное правило разрешения конфликтов — последнее по времени изменение (Timestamp) побеждает, или одно поле является определяющим, а другое предназначено только для отображения. Управление разрешениями для таких чувствительных полей обсуждается в [Руководстве по модели разрешений в Salesforce](/ru/insights/salesforce-permission-model). ## Обработка сбоев: тест, который большинство проектов пропускают Почти каждая интеграция проходит тестирование «счастливого пути» (Happy Path). Лишь немногие проходят систематическую проверку на наличие трех следующих сценариев сбоев: - **Вторая система недоступна во время отправки** — сообщение сохраняется в очереди и отправляется снова, или теряется? - **Сообщение приходит дважды** (распространенная проблема при автоматическом повторе и в Event Bus) — получающая сторона создает дублирующую запись? - **Сообщение приходит в некорректном порядке** — приведет ли обновление статуса «отменено», пришедшее до статуса «одобрено», к неправильному результату? Система, не построенная как идемпотентная (уникальный идентификатор для каждого сообщения + проверка на существование до создания), потерпит неудачу именно в двух первых сценариях, и зачастую под нагрузкой — то есть именно тогда, когда бизнес больше всего от нее зависит. Ограничения API и способы обработки троттлинга в этом контексте подробно описаны в [Руководстве по лимитам API Salesforce](/ru/insights/salesforce-api-limits-resilience). ## Рамки принятия решений: от бизнес-вопроса к шаблону | Вопрос, задаваемый первым | Если ответ "Да" | Если ответ "Нет" | | :------------------------------------------ | :------------------------------------------- | :--------------------------- | | Пользователь ожидает результат интеграции на экране? | Синхронный Request-Reply с заданным тайм-аутом | Переходим к следующему вопросу | | Требуется ли обновление в течение нескольких минут после единичного изменения? | CDC или Platform Event | Переходим к следующему вопросу | | Нескольким различным потребителям необходимо знать об одном и том же событии? | Event-Driven с Pub-Sub | Переходим к следующему вопросу | | Удобно ли обрабатывать большой объем в фиксированном временном окне? | Периодическая пакетная обработка | Рассмотреть Fire-and-Forget с очередью | Это отправная точка для обсуждения на архитектурном совещании, а не исчерпывающая формула — всегда есть пограничные случаи (например, огромный объем, требующий CDC, но также ежедневной пакетной сверки в качестве подстраховки). ## Пример: сеть частных клиник с двадцатью филиалами Рассмотрим сеть клиник, использующую Salesforce для управления запросами пациентов и отдельную систему биллинга, которую невозможно заменить на данном этапе. Требование: когда пациент завершает прием, система биллинга должна быть немедленно обновлена, и когда биллинг обновляется (например, получен платеж), Salesforce должна отражать это, чтобы представитель сервиса не запрашивал двойную оплату. Первоначальный выбор команды – двусторонняя ночная пакетная обработка – был прост в реализации, но создавал разрыв до 24 часов, в течение которого представители видели устаревшую информацию, что приводило к жалобам. Фактическое решение: односторонняя синхронизация (завершение приема из Salesforce в биллинг) была переведена на Fire-and-Forget с очередью сообщений и автоматическим повтором, поскольку пользователю не нужно ждать результата. Вторая сторона (подтверждение оплаты из биллинга в Salesforce) была переведена на CDC, поскольку это точечное изменение, которое должно быть доставлено в течение нескольких минут. Ночная пакетная обработка осталась только как механизм сверки (Reconciliation) — ежедневное сравнение, выявляющее расхождения и генерирующее оповещения, а не как основной канал обновления. Результат: время обновления сократилось с часов до минут, а механизм сверки выявил два случая потерянных сообщений в первый месяц — именно для этого он и предназначен. ## Риски и конкретные меры предотвращения для интеграции | Риск | Как он проявляется на практике | Мера предотвращения | | :------------------------------------------ | :-------------------------------------------------------------------------------------- | :---------------------------------------------- | | Отсутствие идемпотентности | Дублирующиеся записи после повтора или сетевого сбоя | Уникальный идентификатор сообщения + проверка существования перед созданием | | Неопределенный источник истины | Цикл синхронизации или случайное «побеждающее» обновление | Назначенный владелец для каждого поля + правило разрешения конфликтов | | Point-to-Point без уровня интеграции | Любое изменение схемы в одной системе ломает другое соединение | Уровень Middleware/API с четко определенным контрактом версий | | Только технический мониторинг | Интеграция «зеленая», но заказы фактически отсутствуют | Бизнес-метрика сверки, а не только техническое время безотказной работы | | Игнорирование Governor Limits | Интеграция рушится при пиковой нагрузке | Планирование Bulkification и Backoff заранее, а не как реакция | ## Чек-лист для выбора шаблона интеграции - ☐ Требуемое время отклика определено в числах, а не словом «быстро» - ☐ Определен единый владелец (Owner) для каждого общего поля между системами - ☐ Проверено, что происходит, когда целевая система недоступна, — и задокументировано - ☐ Проверено, что происходит, когда сообщение приходит дважды - ☐ Проверено, что происходит, когда сообщения приходят в некорректном порядке - ☐ Существует механизм сверки (Reconciliation), даже если основной шаблон асинхронный - ☐ Ограничения API и Governor Limits проверены на соответствие ожидаемому объему при пиковой нагрузке - ☐ Определены бизнес-метрики успеха, а не только технические ## Метрики для постоянного мониторинга интеграции После запуска целесообразно отслеживать всего три-четыре метрики: процент успешно обработанных сообщений с первой попытки, фактическое сквозное время относительно определенного SLA, ежедневные расхождения по сверке (Reconciliation) между системами и близость к лимитам API. Последовательный рост одного из этих показателей — а не однократное отклонение — является сигналом для рассмотрения перехода к другому шаблону, прежде чем система выйдет из строя в производственной среде. Вопросы идентичности и разрешений доступа между системами подробно описаны в [Руководстве по SSO и идентичности в Salesforce](/ru/insights/salesforce-sso-identity-architecture). ## Заключение Выбор правильного шаблона интеграции начинается не с вопроса «какой инструмент», а с трех вопросов: насколько быстро требуется ответ, кто является владельцем данных и что происходит в случае сбоя. Real-Time подходит, когда пользователь ожидает результат; CDC и Event-Driven подходят для быстрого обновления единичных изменений или распространения нескольким потребителям; Batch подходит для больших объемов в фиксированном временном окне. В каждом шаблоне идемпотентность, определенное владение данными и механизм сверки — это не «было бы неплохо», а необходимое условие для того, чтобы интеграция выдержала реальную нагрузку, а не только демонстрацию. ## Профессиональные источники - Salesforce Integration Patterns — https://architect.salesforce.com/docs/architect/fundamentals/guide/integration-patterns.html - Salesforce Data Integration Decision Guide — https://architect.salesforce.com/docs/architect/decision-guides/guide/data-integration.html - HPI Pro – Архитектура CRM — https://hpi.pro/crm-architecture - HPI Pro – Интеграции и данные — https://hpi.pro/integrations-data ### Вопросы и ответы **В чем практическая разница между Fire-and-Forget и Request-Reply при интеграции с Salesforce?** В паттерне Request-Reply вызывающая сторона ожидает ответа и немедленно получает подтверждение об успехе или неудаче операции — это подходит, когда пользователь работает с интерфейсом и ему нужен немедленный результат для продолжения. В Fire-and-Forget отправитель немедленно продолжает работу, а ответ, если он предусмотрен, приходит асинхронно — это подходит для обновлений, которые не блокируют человеческий процесс. Неправильный выбор приводит к тому, что пользователи ждут систему, которая не предназначена для ожидания, или упускают незаметные сбои. **Когда CDC предпочтительнее периодической пакетной обработки для синхронизации данных?** CDC (Change Data Capture) предпочтительнее, когда относительный объем изменений невелик по сравнению с общим объемом данных, и когда изменения необходимо отразить в течение минут, а не часов — например, обновление статуса заказа, влияющее на обслуживание клиентов. Пакетная обработка предпочтительнее, когда удобно обрабатывать большой объем данных в фиксированном временном окне, когда исходная система не поддерживает потоки событий, или когда сама обработка требует вычислений над полной группой записей, а не над отдельным изменением. **Как обрабатывать дублирующиеся сообщения в событийно-ориентированной интеграции?** Предполагается, что любое сообщение может быть получено более одного раза, и получающая сторона проектируется как идемпотентная: уникальный идентификатор для каждого сообщения, проверка, было ли оно уже обработано до выполнения операции, и сохранение результата таким образом, чтобы повторный запуск не создавал дублирующую запись или не выполнял обновление дважды. Полагаться на то, что «сообщение придет один раз», это предположение, которое нарушается первым при высокой нагрузке или сетевых сбоях. **Кто несет ответственность за источник истины, когда одно и то же поле обновляется как в Salesforce, так и во внешней системе?** Необходимо заранее определить, какая система является владельцем поля, и зафиксировать это в контракте на интеграцию, а не только в памяти команды. Двунаправленное обновление без определенного владельца создает циклы синхронизации и конечный результат, зависящий от времени. Если существует реальная необходимость в редактировании с обеих сторон, требуется четкое правило разрешения конфликтов — например, «последнее обновление выигрывает» по отметке времени — а не предположение, что такая ситуация не возникнет. **Как понять, что выбранный шаблон интеграции все еще подходит после десятикратного увеличения нагрузки?** Проверяются три аспекта: соответствует ли время обработки установленному SLA, превысил ли процент отказов и повторных попыток заранее определенный порог, и приближаются ли к пределу ограничения API Salesforce (такие как Governor Limits или API Calls). Рост любого из этих показателей является сигналом для рассмотрения перехода от пакетной обработки к CDC, добавления очереди или распараллеливания процессов — прежде чем система выйдет из строя в производственной среде. --- ## Модель разрешений Salesforce: как спланировать доступы, не открывая ничего лишнего URL: https://hpi.pro/ru/insights/salesforce-permission-model Большинство организаций строят модель разрешений сверху вниз: сначала широкий профиль, затем точечные корректировки, пока никто уже не помнит, почему у пользователя есть тот или иной доступ. Правильный подход противоположен: ограниченный профиль для базового доступа и группы наборов разрешений (Permission Set Groups), которые формируют рабочие возможности в соответствии с ролью. В статье это представлено как операционная методология. ## Основной вопрос: что определяет права доступа пользователя в Salesforce Когда возникает вопрос «Как пользователь получил доступ к этому полю?», правильный ответ почти всегда многокомпонентен: его профиль (Profile) определяет базовый уровень доступа, группы наборов полномочий (Permission Set Groups) расширяют функциональные возможности в соответствии с ролью, а индивидуальные наборы полномочий (Permission Set) иногда используются для точечных исключений. Проблема заключается в том, что большинство организаций выстраивают эту комбинацию в обратном порядке: начинают с широкого профиля, который включает почти всё, а затем «исправляют» точечные проблемы индивидуальными разрешениями, которые никто не помнит удалить. Здоровая модель разрешений строится в другом направлении: максимально ограниченный профиль, который в основном определяет тип лицензии, видимость приложения по умолчанию и параметры входа в систему; и все реальные рабочие возможности — к каким объектам, полям, действиям — переносятся в Permission Sets и Permission Set Groups. Важно уточнить: эта статья рассматривает только уровни объекта (Object), поля (Field) и системных разрешений (System Permissions). Вопросы видимости записей между пользователями — OWD (Default Organization-Wide Defaults), Role Hierarchy (иерархия ролей), Sharing Rules (правила совместного доступа) — обсуждаются в [руководстве по видимости и совместному доступу](/ru/insights/crm-architecture-guide), поскольку это отдельный уровень принятия решений со своими компромиссами. ## Три компонента и их назначение | Компонент | Что определяет | Сколько может быть у пользователя | Когда используется | |---|---|---|---| | Profile | Тип лицензии, видимость приложения по умолчанию, Page Layout, Login Hours/IP | Ровно один | Различия в инфраструктуре между типами пользователей | | Permission Set | Разрешения для объекта, поля, Apex Class, вкладки (Tab) — только добавляет | Сколько угодно | Единая возможность, актуальная для части ролей | | Permission Set Group | Пакет из нескольких Permission Sets под одним именем, с возможностью отмены (Muting) | Сколько угодно | Постоянная комбинация разрешений, представляющая полный рабочий функционал | Различие между Permission Set и Permission Set Group не только техническое, но и организационное. Отдельный Permission Set подходит для одной, сфокусированной возможности («Доступ к финансовым отчетам»). Permission Set Group подходит, когда необходимо назначить полноценный «рабочий пакет» для отдела или роли и поддерживать его в одном месте при изменениях. ## Принципы принятия решений: куда относится новое разрешение Когда поступает запрос на добавление доступа, первый вопрос не «В какой профиль добавить?», а к какому компоненту разрешение относится структурно: 1. **Это разрешение, характерное для всех обладателей одной и той же лицензии?** Если да — это место для Profile, при условии, что это относится ко всем обладателям лицензии, а не к подгруппе. 2. **Это рабочая функция, которая требуется определённой группе ролей всегда вместе с другими разрешениями?** Если да — это место для Permission Set Group, даже если сначала её нужно разбить на несколько отдельных Permission Sets для обеспечения гибкой комбинации. 3. **Это точечное и временное разрешение для одного пользователя или исключения?** Если да — это отдельный Permission Set, который назначается вручную и подлежит периодической проверке. 4. **Разрешение должно отменить что-либо для конкретного пользователя в широкой группе?** Здесь вступает в действие Muting Permission Set внутри Permission Set Group — единственный инструмент в Salesforce, позволяющий ограничить разрешение, не затрагивая Profile и не разбивая группу. Правило, предотвращающее большую часть расхождений: никогда не редактируйте Profile для решения проблемы одного пользователя. Если исправление определяется как исключение, оно проходит через Permission Set, который документирован и имеет дату проверки. ## Чек-лист для построения модели разрешений с нуля - ☐ Определены фактические рабочие роли (не организационные отделы), и каждая роль получила четкое название. - ☐ Для каждой роли определён список необходимых возможностей на уровне объекта, поля и Apex Class. - ☐ Созданы сфокусированные Permission Sets для одной возможности, а не общие «кучи разрешений». - ☐ Каждая роль получила одну Permission Set Group, объединяющую релевантные возможности. - ☐ Профили (Profiles) сокращены до различий в лицензировании и инфраструктуре. - ☐ Определён процесс для исключительных случаев: кто одобряет точечный Permission Set и на какой срок. - ☐ Установлена частота проверки (минимум ежеквартально), которая сравнивает активные разрешения с текущей ролью. - ☐ Назначен единый ответственный (Owner) за поддержание модели разрешений при изменениях организационной структуры. ## Организационный сценарий: страховая компания с тремя отделами продаж Представим среднюю страховую компанию с примерно тремя сотнями пользователей Salesforce, разделённых на три отдела: прямые продажи, продажи через агентов и урегулирование претензий. До проекта у компании было двенадцать различных профилей, некоторые из которых были почти идентичными копиями, созданными для «исправления» одного разрешения для небольшой группы. Типичный результат: когда присоединялся новый агент, никто не знал наверняка, какой из двенадцати профилей ему подходит, и практический ответ был «скопируй у похожего сотрудника». Архитектурная команда перестроила модель: всего три профиля, по типу лицензии (полная Sales Cloud, Community для внешних агентов, Service Cloud для претензий). Сверху — семь групп наборов полномочий (Permission Set Groups) по фактическим рабочим ролям: представитель по продажам, руководитель отдела продаж, внешний агент, менеджер агентов, оценщик претензий, менеджер претензий, и смешанная роль, которая занимается как продажами, так и претензиями. Каждая Permission Set Group состояла из сфокусированных Permission Sets, таких как «доступ к активным полисам» или «утверждение возмещения до определённого лимита», что позволяло комбинировать их заново при создании новой роли без построения разрешений с нуля. Измеримый результат: время настройки нового пользователя сократилось с нескольких дней (включая ручную проверку подходящего профиля) до нескольких часов, а количество запросов в службу поддержки типа «у меня нет доступа к полю X» сократилось почти вдвое за квартал после перехода, поскольку большинство таких запросов возникали из-за того, что профиль не включал нужную функцию, и было неясно, к кому обратиться за исправлением. ## Распространённые риски и меры по их предотвращению | Риск | Как он проявляется на практике | Мера предотвращения | |---|---|---| | Profile превращается в инструмент точечных исправлений | Множество почти идентичных Profiles, каждый для небольшой группы | Перенести каждое точечное разрешение в Permission Set и сократить Profiles до типа лицензии | | Несоответствие Field-Level Security (FLS) | Одно и то же поле видно в одном месте и скрыто в другом | Документировать центральную матрицу FLS для каждого чувствительного поля и проверять её при каждом релизе | | Разрешения «прилипают» после смены роли | Пользователь, сменивший роль, сохраняет разрешения от предыдущей | Процесс Offboarding-от-роли, который удаляет старую Permission Set Group перед добавлением новой | | Слишком широкие системные разрешения (View All Data, Modify All) | Предоставляются «для экономии времени» и не удаляются впоследствии | Целевое одобрение и срок действия для каждого широкого системного разрешения | | Отсутствие ответственного за модель разрешений | Каждый отдел добавляет разрешения без общего видения | Единый ответственный, который утверждает каждый новый Permission Set или Group перед развертыванием | ## Метрики для оценки состояния модели | Область | Что измеряется | Частота проверки | |---|---|---| | Излишнее дублирование | Количество активных Profiles по отношению к количеству фактических типов лицензий | Ежеквартально | | Точность разрешений | Процент пользователей, чьи разрешения соответствуют зарегистрированной в HR роли | Ежеквартально | | Открытые исключения | Количество точечных Permission Sets без даты проверки | Ежемесячно | | Широкие разрешения | Количество пользователей с View All Data / Modify All Data без документированного обоснования | Ежемесячно | | Время настройки | Среднее время от запроса нового доступа до полного назначения | Постоянно | В первой версии отслеживания стоит ограничиться тремя из пяти метрик и расширять только после установления надёжной базовой линии. Метрика без ответственного и даты проверки имеет тенденцию исчезать из отчёта после первого месяца. ## Как это интегрируется в более широкую архитектуру Качественная модель разрешений является необходимым условием, а не заменой для планирования видимости записей (OWD, Role Hierarchy, Sharing Rules) — эти две темы дополняют друг друга, но решаются по отдельности. Организация, которая пытается решить проблему видимости путём расширения Profile, или наоборот, обычно обнаруживает, что решение становится хрупким при изменении организационной структуры. Когда организация переходит от множества Orgs к одному Org, модель разрешений — одна из вещей, которые необходимо пересмотреть — подробнее об этом в [руководстве Single Org vs Multi Org](/ru/insights/salesforce-single-org-vs-multi-org). И когда само разрешение зависит от сложной условной логики, стоит рассмотреть, относится ли реализация к Flow или Apex, как подробно описано в [руководстве Flow vs Apex](/ru/insights/salesforce-flow-vs-apex). В организациях, которые используют процессы, основанные на событиях, между системами, необходимо убедиться, что разрешения пользователей интеграции (Integration Users) построены по тому же принципу — сфокусированный Permission Set, а не широкий Profile с «System Administrator» как удобным по умолчанию. Эта тема связана с более широким планированием межсистемных коммуникаций, описанным в [руководстве по событийной архитектуре для Salesforce](/ru/insights/salesforce-event-driven-architecture). ## Заключение Модель разрешений, которая выдерживает испытание временем, строится снизу вверх: сфокусированные возможности в Permission Sets, сборка их по реальным рабочим ролям в Permission Set Groups, и Profile, который сохраняет минимальную роль только для лицензирования и инфраструктуры. Очевидным признаком провала является множество Profiles, созданных для решения точечных проблем — каждый такой дополнительный Profile является техническим долгом, который накапливается до тех пор, пока никто не помнит, почему он существует. При отсутствии внутренних ресурсов для построения или очистки существующей модели, [услуги по архитектуре CRM](/ru/crm-architecture) представляют собой практический путь к целенаправленному началу. ### Вопросы и ответы **В чем практическая разница между Profile и Permission Set?** У каждого пользователя есть ровно один Profile, и он определяет также не совсем разрешения в обычном смысле — видимость приложений по умолчанию (App Visibility), назначение макета страницы (Page Layout Assignment), часы входа (Login Hours) и диапазоны IP (IP Ranges). Permission Set — это дополнение, которое только добавляет доступ и никогда его не отменяет. Плановый вывод: оставлять Profile минимальную роль, а большинство различий между пользователями строить на Permission Sets. **Когда стоит объединять несколько Permission Sets в один Permission Set Group?** Когда группа пользователей (например, «Старший агент по обслуживанию») всегда нуждается в одном и том же фиксированном наборе разрешений, поступающих из нескольких отдельных Permission Sets (доступ к делам, доступ к возвратам, доступ к базе знаний). Объединение в группу экономит повторное ручное назначение и уменьшает ошибки, при которых пользователь получает только часть необходимого для роли набора. **Может ли Permission Set отменить разрешение, существующее в Profile?** Нет. Разрешения в Salesforce являются исключительно аддитивными — Permission Set только добавляет, никогда не ограничивает. Если нужно отменить доступ для конкретного пользователя, не затрагивая других, решение — Muting Permission Set внутри Permission Set Group, а не редактирование его Profile. **Сколько Profiles должно быть в организации среднего размера?** Единого числа нет, но полезное эмпирическое правило: количество Profiles должно отражать различия в лицензировании и инфраструктуре (License Type, доступ к приложению по умолчанию), а не различия в разрешениях между ролями. Организация с десятками Profiles почти всегда использует их, чтобы компенсировать отсутствие упорядоченных Permission Set Groups. **Как убедиться, что добавленное разрешение не остается активным дольше, чем это необходимо?** С помощью Permission Set, назначенного на ограниченный срок (Permission Set License с датой истечения срока действия, если применимо, или ежеквартальный процесс аудита), а не постоянного разрешения. Кроме того, периодически запускается отчет, сравнивающий активные разрешения с текущей ролью в таблице HR, и отмечаются отклонения для проверки. --- ## Salesforce Org 1 или Multi-Org? Критерии выбора для многоподразделенческой организации URL: https://hpi.pro/ru/insights/salesforce-single-org-vs-multi-org Решение о переходе на Multi-Org редко принимается одномоментно. Оно чаще всего является результатом накопления уникальных требований бизнес-единиц, регуляторных норм и моделей данных, которые сложно уместить в едином пространстве. В статье представлен тест из трех вопросов для оценки истинной необходимости, экономически эффективная сравнительная матрица и пошаговый план действий для тех, кто уже находится на пути к разделению. ## Три вопроса, определяющие необходимость использования нескольких организаций Multi-Org Распространенная ошибка заключается в подходе к вопросу «одна организация или несколько?» как к техническому вопросу о пропускной способности или производительности. В большинстве случаев техническое решение существует в рамках одной организации: типы записей (Record Types), профили (Profiles), наборы разрешений (Permission Sets) и правила совместного доступа (Sharing Rules) достаточны для разделения бизнес-подразделений без фактического разделения среды. Salesforce поддерживает десятки тысяч пользователей и миллионы записей в одной организации — пропускная способность почти никогда не является истинной причиной разделения. Вопрос, который действительно имеет значение, — это вопрос организационной независимости, и он сводится к трем проверкам: 1. **Реальная регулятивная независимость** — Существует ли юридическое или договорное требование к физическому разделению данных (например, отдельное юридическое лицо с местным регулированием, запрещающим совместное использование инфраструктуры) в отличие от логического разделения, которое может быть достигнуто с помощью модели совместного доступа (Sharing Model). 2. **Несовместимые темпы изменений** — Нуждается ли одно бизнес-подразделение в частых и быстрых циклах выпусков (Release), в то время как другое требует максимальной стабильности и строгого контроля, так что каждый совместный выпуск становится постоянным источником трений между командами. 3. **Конфликтующая, а не просто отличающаяся модель данных** — Когда одна и та же сущность (например, «клиент» или «заказ») имеет обязательное определение поля, поток утверждения или структуру связей, которые физически противоречат друг другу между подразделениями, а не просто отличаются в представлении. Если ни одно из этих трех условий не выполняется четко, правильное решение — одна организация с логическим разделением. Разделение «на всякий случай» создает постоянные операционные затраты — дублирование управления пользователями, дублирование лицензирования и дублирование поддержки интеграции — за проблему, которую можно было решить с помощью конфигурации. ## Матрица решений: одна организация или несколько | Измерение | Одна организация с логическим разделением | Несколько отдельных организаций | | --- | --- | --- | | Стоимость лицензирования и обслуживания | Ниже — единое лицензирование, централизованное управление пользователями | Выше — дублирование лицензирования, дублирование управления выпусками | | Customer 360 и унифицированное представление | Естественно — все данные в одном пространстве запросов | Требует выделенного слоя BI или интеграции | | Операционная независимость подразделения | Ограничена — каждый выпуск влияет на всех | Полная — каждое подразделение контролирует свой темп | | Соблюдение жестких регулятивных требований к разделению данных | Невозможно, если требование — физическое разделение | Единственное решение, соответствующее требованию | | Сложность интеграции между подразделениями | Низкая | Высокая — требуется промежуточное ПО (Middleware) или ETL | | Риск при будущем слиянии/разделении | Низкий — только изменение разрешений | Высокий — полноценный проект миграции | Вывод: по умолчанию следует использовать одну организацию, и разделение следует выбирать только при наличии четкого и положительного ответа на один из трех вопросов выше, а не в качестве реакции на временные организационные разногласия. ## Что происходит на практике, когда разделение выполняется без достаточных на то оснований Когда организация разделяет Org по политическим причинам (подразделение, которое хочет «свой собственный контроль»), а не по реальным техническим причинам, в течение одного-двух лет происходят три вещи: во-первых, создается дублирующаяся запись клиента в каждом Org, где появляется одно и то же бизнес-лицо, без общего ключа идентификации. Во-вторых, любое изменение на уровне организации (такое как обновление процесса безопасности или внедрение нового инструмента) становится отдельным проектом в каждом Org, что удваивает стоимость каждого будущего изменения. В-третьих, корпоративная отчетность требует интеграционного слоя, который изначально не был необходим, и часто он создается в спешке после обнаружения проблемы, а не как часть планирования. Поэтому один из руководящих принципов [архитектуры Salesforce](/ru/insights/crm-architecture-guide) заключается в том, чтобы сначала определить, может ли организационная потребность быть реализована с помощью разрешений и правил совместного доступа (Sharing Rules) в рамках одной организации, и только затем рассматривать разделение. ## Пошаговое руководство для тех, кому уже требуется разделение Когда одна из трех проверок действительно выполняется, разделение должно быть выполнено в порядке, минимизирующем риски: ### 1. Определите глобальный ключ идентификации до разделения Перед созданием второй организации установите единое идентификационное поле (идентификационный номер юридического лица, глобальный Customer ID или аналогичный код), которое позволит в будущем сопоставлять записи между средами. Без этого любая будущая попытка объединить представление клиента будет основана на сопоставлении имени и адреса, что приводит к значительным ошибкам. ### 2. Выберите шаблон интеграции в соответствии с направлением и скоростью передачи данных Если речь идет только о периодическом обновлении для целей отчетности, достаточно запланированного ETL. Если требуется просмотр в реальном времени (например, для межподразделенческой проверки кредитоспособности), требуется синхронный API с обработкой сбоев и повторных попыток. Выбор неподходящего шаблона является основной причиной того, что кросс-организационные интеграции ломаются под нагрузкой — подробнее об этом в разделе [шаблоны интеграции Salesforce](/ru/insights/salesforce-integration-patterns). ### 3. Заранее спланируйте идентификацию и права доступа Пользователи, работающие в двух организациях (например, глобальные менеджеры по работе с клиентами), требуют решения для идентификации, которое управляется один раз, а не два отдельных пользователя с двумя паролями. Планирование SSO между организациями предотвращает ситуацию, когда каждое изменение прав пользователя выполняется вручную в двух средах — этот вопрос подробно рассматривается в [архитектуре SSO и идентификации в Salesforce](/ru/insights/salesforce-sso-identity-architecture). ### 4. Проверьте ограничения API до того, как интеграция будет запущена в производственную среду Каждый вызов между двумя организациями учитывается в лимитах API обеих сторон. Трафик, запланированный без проверки объема, может нарушить ежедневные лимиты именно в часы пиковой нагрузки, то есть именно тогда, когда интеграция наиболее необходима. Это следует проверить заранее по [лимитам API Salesforce](/ru/insights/salesforce-api-limits-resilience). ### 5. Определите владельца и общий процесс управления обоими организациями Кто-то должен быть ответственным за согласованность архитектурных решений между средами — структуру полей, правила именования и политику изменений. Без централизованного владения две организации разойдутся даже на уровне стандартов в течение года, что сделает любую будущую интеграцию более дорогой. ## Иллюстративный сценарий: страховая группа с двумя подразделениями Сценарий является гипотетическим и предназначен для иллюстрации. Страховая группа имела подразделение общего страхования и подразделение страхования жизни, оба действовали в рамках одного юридического лица, но с разными регуляторами и совершенно разными циклами утверждения продуктов. Подразделение страхования жизни требовало строгого контроля изменений с регулятивным одобрением каждого выпуска, в то время как подразделение общего страхования хотело выпускать улучшения еженедельно. Первоначальное предложение заключалось в разделении на отдельные организации для каждого подразделения, но при проверке по трем вопросам выяснилось, что реально существует только регулятивный темп (проверка 2) — модель клиента и продукта не конфликтовали (проверка 3 отрицательная), и не было требования физического разделения данных (проверка 1 отрицательная). Выбранное решение заключалось в одной организации с двумя отдельными «путями выпуска» в одной и той же среде — выделенная песочница (Sandbox) и отдельный процесс утверждения для подразделения страхования жизни, при этом использовалась общая модель данных для единого Customer 360. Полное разделение было предотвращено, как и двойные затраты на обслуживание, которые пришлось бы нести на протяжении многих лет. ## Общие риски и способы их предотвращения - **«Временное» разделение, которое остается постоянным** — Sandbox, который становится производственной средой без прохождения контроля безопасности. Предотвращается тем, что каждая организация с реальными данными клиентов проходит официальный процесс утверждения управления, без исключений. - **Дублирующиеся записи без общего ключа** — Возникает, когда разделение происходит до определения глобального идентификатора. Предотвращается путем определения общего поля как предварительного условия для разделения, а не как позднего этапа. - **Лимит API, который заполняется в часы пик** — Происходит, когда интеграция между организациями планируется на основе среднего объема, а не пикового. Предотвращается путем нагрузочного тестирования перед запуском в производственную среду и создания механизма Backoff. - **Расхождение стандартов между организациями** — Происходит, когда нет единого владельца общей архитектуры. Предотвращается путем создания небольшого управляющего комитета, который утверждает изменения структуры данных с обеих сторон. - **Ненадежная управленческая отчетность** — Происходит, когда попытки рассчитать сквозные KPI организации напрямую из Salesforce без уровня агрегации. Предотвращается путем создания выделенного уровня BI с первого дня разделения, а не в качестве позднего исправительного проекта. ## Заключение По умолчанию используется одна организация; разделение является исключением, требующим конкретного обоснования по одной из трех проверок — реальная регулятивная независимость, несовместимый темп изменений или физически конфликтующая модель данных. Когда обоснование существует, успех перехода измеряется подготовкой, проведенной до разделения: глобальный ключ идентификации, подходящий шаблон интеграции, общая идентификация, проверка лимитов API и четкое владение общими стандартами. Организация, которая пропускает эту подготовку, не экономит работу — она просто откладывает ее на тот момент, когда исправление будет намного дороже. ### Вопросы и ответы **Достаточно ли слияния компаний, чтобы оправдать переход на Multi-Org?** Не автоматически. Если обе компании продолжат работать под отдельными брендами и использовать отдельные процессы продаж в течение многих лет, есть основания рассматривать отдельный Org. Если план предусматривает унификацию процессов в течение одного-двух лет, чаще всего предпочтительнее временно объединить их в рамках одного Org с разделением по разрешениям и избежать затрат на обратное слияние в будущем. **Как обеспечить объединенную отчетность при наличии нескольких Orgs?** Обычно это достигается через внешний уровень BI (например, Data Cloud, Snowflake или Tableau), который извлекает данные из каждого Org по отдельности и объединяет их в единую модель отчетности. Попытки построить кросс-орг отчеты непосредственно в Salesforce почти всегда требуют дорогостоящей интеграционной работы, которая не оправдывает предоставляемой ценности. **Что происходит с клиентом, который фигурирует в двух разных Orgs?** Без определенного процесса сопоставления один и тот же клиент будет создан как дублирующая запись в каждом Org, с частичной историей на каждой стороне. Необходимо определить общий внешний идентификатор (например, регистрационный номер компании или глобальный Customer ID) и процесс синхронизации или, по крайней мере, периодический отчет о сопоставлении еще до фактического разделения. **Можно ли объединить два Orgs обратно в один?** Да, но это полноценный проект миграции, а не простая настройка конфигурации. Необходимо синхронизировать объектную модель, типы записей, процессы утверждения, исторические данные и интеграции между двумя средами, и чаще всего потребуется специализированный инструмент миграции. Поэтому разделение следует рассматривать как труднообратимый шаг, а не как обратимый эксперимент. **Что такое «Multi-Org на практике без принятия решения»?** Распространенная ситуация, когда бизнес-единица создает Sandbox или отдельный Org для временного использования, и он фактически становится производственной средой без осознанного решения со стороны кого-либо. Отличительным признаком является наличие реальных клиентских данных в Org, который не прошел полноценный процесс управления, обеспечения безопасности и контроля доступа. --- ## Маппинг данных для миграции в Salesforce: как предотвратить ошибки до загрузки URL: https://hpi.pro/ru/insights/salesforce-data-mapping Большинство сбоев при миграции в Salesforce обусловлены не инструментальными проблемами, а смысловыми: когда одно и то же название поля в двух системах описывает разные сущности. Данное руководство демонстрирует, как создать документ маппинга, который фиксирует бизнес-значение, правила трансформации, значения по умолчанию и ответственности – еще до первой загрузки данных. ## Краткий ответ Картирование данных — это не просто таблица соответствия полей, а документ, в котором организация определяет значение каждого фрагмента данных, переносимого в Salesforce. Практически любая ошибка загрузки, кажущаяся технической — неверный формат даты, неопознанное значение Picklist, разорванная связь — изначально является следствием непринятого бизнес-решения. Порядок действий: сначала определяется, какие сущности будут переноситься, затем, кто является бизнес-владельцем каждой сущности, далее, какие поля имеют реального потребителя, и только потом пишутся правила преобразования. Если начать с обратного, техническая команда принимает бизнес-решения незаметно — и это обнаруживается спустя три месяца после Go-Live, когда отчет о доходах не сходится. Общая информация о планировании миграции данных доступна по ссылке: [Миграция данных в Salesforce](/ru/insights/salesforce-data-migration-guide). ## Три типа пробелов, выявляемых при картировании | Тип пробела | Распространенный пример | Кто принимает решение | | --- | --- | --- | | Семантический пробел | «Активный клиент» = совершил покупку в этом году в одной системе, = не заблокирован в другой системе | Владелец бизнес-процесса | | Структурный пробел | Один клиент с пятью адресами против модели Account/Contact | Архитектор данных | | Пробел в качестве | 18% записей без действительного внутреннего номера НДС | Владелец данных + регулирующие органы | Семантический пробел является наиболее дорогостоящим, поскольку он не выявляется при загрузке. Данные успешно поступают, автоматизация выполняется на их основе, а отчет показывает неверное, но правдоподобное число. Структурные пробелы выявляются при загрузке и обнаруживаются рано. Пробелы в качестве выявляются, если — и только если — заранее были определены пороговые значения приемлемости. ## Семантический уровень: Data Dictionary до Mapping-таблицы Перед тем как сопоставлять поля, составляется глоссарий для каждой ключевой сущности: что такое Account (клиент), чем Lead (потенциальный клиент) отличается от Contact (контакта) в данной организации, когда Opportunity (возможность) закрывается. Эти определения коротки — две строки на сущность — но именно они позволяют разрешать разногласия, а не указывать на них. Простая проверка: дайте трем сотрудникам из трех разных отделов определить «клиента» по отдельности. Если определения различаются, миграция передаст три разные истины в одну и ту же таблицу. ## Анатомия правильной строки картирования Каждая строка в таблице должна отвечать на семь вопросов: из какого исходного объекта и поля, в какой объект и поле в Salesforce, каков тип данных и его длина, каково правило преобразования, что происходит с пустым значением, каково значение по умолчанию и кто утвердил. Строка, в которой отсутствует один из этих столбцов, вернется в качестве вопроса в процессе ночной загрузки Cutover. Три рабочих правила, которые помогают избежать ошибок: - **Нет тихих преобразований.** Все значения, которые система «исправляет» самостоятельно, должны быть записаны в лог исключений. - **Значение по умолчанию — это бизнес-решение.** Тот, кто устанавливает `Country = IL` в качестве значения по умолчанию, должен нести ответственность за отчеты по регионам. - **Внешние ключи превыше всего.** Для каждой сущности сохраняется External ID из исходной системы. Без него нет Reconciliation и повторного запуска. ## Преобразования: где совершаются ошибки Наибольший ущерб наносят именно простые преобразования. Даты без часового пояса смещают записи на день; имена, которые обрезаются и переводятся в верхний регистр без единого правила, создают новые дубликаты сразу после удаления старых; суммы, конвертированные в единую валюту по дневному курсу, создают расхождения в отчетах с ERP. Правило: любое числовое или денежное преобразование проверяется путем сравнения сумм, а не путем сравнения записей. Одинаковый подсчет не является доказательством корректности. Те, кто еще не решил вопрос об источнике истины, найдут информацию в [Source of Truth в организации](/ru/insights/salesforce-source-of-truth), а само окно переноса — в [Cutover и Reconciliation в Salesforce](/ru/insights/salesforce-migration-cutover-reconciliation). ## Сценарий: Сервисная компания с двумя исходными системами Организация, предоставляющая услуги, с 90 тысячами клиентов приступила к миграции из двух систем: старой системы выставления счетов и системы обслуживания, приобретенной вместе с дочерней компанией. Первая таблица картирования была отмечена как «готова» в течение двух недель — 340 полей было сопоставлено. При первом тестовом прогоне (Rehearsal) было загружено 97% записей. Проблема обнаружилась при сверке (Reconciliation): общая сумма остатков в Salesforce была на 4,1% ниже, чем в ERP. Причиной была не неудачная загрузка, а то, что все записи с отрицательным остатком (кредитовые ноты) были сопоставлены с полем, имеющим правило валидации, которое предотвращало отрицательное значение — и тихо устанавливались как ноль. Исправление было на двух уровнях: явное правило преобразования для кредитовых нот, а также изменение политики — каждое правило, которое обнуляет или укорачивает значение, должно генерировать строку исключения. При втором прогоне количество исключений увеличилось до 1900, и это был прогресс: исключения стали видимыми вместо скрытых. Третий прогон свел количество исключений к 40 задокументированным, и только тогда была назначена дата Cutover. ## Распространенные риски и профилактические меры | Риск | Как проявляется на практике | Профилактические меры | | --- | --- | --- | | Перенос всей истории | Объем, дубликаты и бесполезная информация переносятся в новую систему | Определить политики Retention и пороговые значения качества | | Только техническое картирование | Поля переносятся без понимания бизнес-значения | Data Dictionary и бизнес-владельцы | | Тихие преобразования | Значения исправляются автоматически, и никто об этом не знает | Логирование исключений обязательно для каждого правила преобразования | | Отсутствие тестовых прогонов (Rehearsal) | Окно простоя увеличивается, возникают сюрпризы | Минимум два полных тестовых прогона | | Отсутствие External ID | Невозможно проверить, исправить или повторно запустить | Для каждой сущности сохраняется исходный ключ | ## Как измерять успех | Область | Что измеряем | Частота проверки | | --- | --- | --- | | Полнота (Completeness) | Доля заполненных обязательных полей в целевой системе | До и после каждой загрузки | | Сверка (Reconciliation) | Соответствие подсчетов, сумм и связей исходным данным | При каждом тестовом прогоне (Rehearsal) и Cutover | | Исключения | Количество открытых строк исключений по степени серьезности | Ежедневно в период миграции | | Поля без потребителя | Сколько перенесенных полей не использовались за 90 дней | Один раз после Go Live | Последний показатель является подготовкой к следующему циклу: он показывает, сколько работы было излишним, и определяет объем следующей миграции. Организации, предпочитающие профессиональное сопровождение в построении картирования, делают это в рамках [услуги интеграции и данных](/ru/integrations-data). ## Контрольный список перед первой загрузкой - ☐ Краткий словарь терминов для каждой ключевой сущности, утвержденный бизнесом - ☐ Список полей с определенным потребителем; остальное в архив - ☐ External ID для каждой перенесенной сущности - ☐ Полная таблица сопоставления значений (Value Mapping), включая значение для неопознанных значений - ☐ Явное правило для каждого пустого значения и для каждого значения по умолчанию - ☐ Каждое правило преобразования генерирует строку исключения вместо тихого исправления - ☐ Сценарий сверки (Reconciliation): подсчет, сумма, связь, ручная выборка - ☐ Согласованный порог исключений, выше которого Cutover не выполняется - ☐ Версия и подпись на листе картирования - ☐ План отката (Rollback) и повторного запуска ## Профессиональные ресурсы - Salesforce Data 360 — https://www.salesforce.com/data/ - Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html - HPI Pro – Интеграции и данные — https://hpi.pro/integrations-data ### Вопросы и ответы **В чем разница между техническим и бизнес-маппингом?** Технический маппинг отвечает на вопрос 'В какое поле это должно попасть'. Бизнес-маппинг отвечает на вопросы 'Что означает это поле, кто его обновляет и что происходит, если оно пустое'. Две системы могут иметь поле под названием 'Статус', которое в одном случае описывает этап продажи, а в другом — статус оплаты. Только бизнес-маппинг выявляет это расхождение до загрузки. **Сколько полей действительно необходимо переносить?** В проектах, которые мы сопровождали, от 40% до 60% полей в исходной системе не используются активно или могут быть пересчитаны заново. Практическое правило: переносить поле только в том случае, если у него есть определенный потребитель – бизнес-процесс, отчет, автоматизация или регуляторное требование. Поле без потребителя остается в архиве, а не в Salesforce. **Где документировать правила трансформации?** В единой таблице маппинга с версионированием, где каждая строка содержит: источник, цель, тип, правило преобразования, значение по умолчанию, обработку пустых значений и бизнес-владельца, утвердившего правило. Если правило существует только в скрипте ETL, никто в бизнесе не может его утвердить и невозможно провести его сверку. **Что делать с несовместимыми значениями Picklist?** Создайте отдельную таблицу Value Mapping с полным сопоставлением, включая значение по умолчанию для неизвестных значений. Правило: ни одно значение в источнике не остается без цели, и ни одно неизвестное значение не загружается 'молча' – оно попадает в отчет об исключениях, который кто-то должен закрыть до Cutover. **Когда маппинг считается готовым?** Когда полностью выполненная репетиционная загрузка прошла со сверкой, подтверждающей количество, суммы и связи 'родитель-потомок', а список оставшихся исключений меньше предварительно согласованного порога и письменно подтвержден владельцами процессов. --- ## Устранение дубликатов до внедрения Salesforce: практическая стратегия дедупликации URL: https://hpi.pro/ru/insights/salesforce-data-deduplication Дублирование — это не проблема данных, а проблема идентификации: организация не определила, что делает две записи одним и тем же клиентом. В данном руководстве показано, как настроить правила сопоставления, построить «золотую запись» (Golden Record), решить, что удалить, а что сохранить в истории, а также как предотвратить повторное появление дубликатов через две недели после загрузки. ## Краткий ответ Дедупликация неэффективна, если рассматривать ее как разовую чистку данных. По сути, это три решения: что определяет уникальность, что превалирует в случае конфликта, и как предотвратить повторное возникновение проблемы. Технический инструмент — это самая легкая часть. Распространенная ошибка заключается в применении нечеткого сопоставления (Fuzzy Matching) к именам, получении списка из 12 тысяч потенциальных совпадений и попытке разрешить их вручную под давлением сроков. Работает обратный подход: сначала сужают область принятия решений с использованием строгих ключей, оставляя для человеческого обзора только серую зону. Подробный план миграции описан в [Руководстве по миграции данных в Salesforce](/ru/insights/salesforce-data-migration-guide). ## Три уровня сопоставления | Уровень | Основание | Действие | | --- | --- | --- | | Строгий ключ | ИНН, ОГРН, идентификатор из исходной системы, подтвержденный email | Автоматическое объединение | | Комплексный ключ | Нормализованное имя + город + нормализованный телефон | Автоматическое объединение с высокой оценкой соответствия | | Текстовое сходство | Только имя, свободный текстовый адрес | Только ручной обзор | Типичное соотношение для управляемого проекта: около 70% дубликатов разрешаются на первом уровне, около 20% — на втором, и около 10% поступают к человеку. Если большинство совпадений попадает на третий уровень, это признак того, что работа по нормализации не была выполнена, а не того, что данные особенно плохи. ## Нормализация перед сравнением Перед любым сравнением создаются нормализованные вспомогательные столбцы, не меняя при этом исходные данные: удаление корпоративных суффиксов (ООО, Ltd), унификация пробелов и кавычек, приведение телефона к формату E.164, перевод email в нижний регистр с удалением меток после плюса, и разделение адреса на улицу/номер/город. Сама по себе нормализация обычно сокращает от трети до половины "сложных" дубликатов еще до применения алгоритма сходства. ## Golden Record на уровне поля Решение о том, "какая запись выживает", не является самым важным. Важно решение о том, "какое значение выживает в каждом поле". Определяется короткая политика: платежные данные из ERP, контактные данные из системы, где была зарегистрирована последняя активность, статус клиента из операционной системы. Для каждого поля выбирается один предпочтительный источник, а отклоненное значение сохраняется в записи. Без такой политики каждое объединение является решением того, кто его выполнил в данный момент — и невозможно объяснить потом, почему исчез адрес. ## Что происходит со связями и историей Объединение записей влияет на активности, возможности (Opportunities), обращения (Cases), файлы и разрешения. Перед массовым запуском явно определяются: куда перемещаются активности, что происходит с открытыми возможностями для одного и того же клиента из двух записей, и кто является владельцем после объединения — поскольку изменение владельца меняет как видимость, так и отчеты по комиссиям. Практическое правило: нет объединения, пока не существует восстанавливаемого отчета "Что изменилось", и исходные идентификаторы не сохраняются в отдельном поле, чтобы обеспечить возможность расследования месяцами позже. ## Сценарий: импортер с 210 тысячами контактов B2B-импортер приступил к миграции с 210 тысячами записей контактов из трех систем. Первый запуск инструмента сходства вернул 31 тысячу подозрительных пар — количество, которое никто не мог просмотреть. Команда остановилась и изменила порядок. Сначала были нормализованы email и телефон: 14 тысяч пар были автоматически закрыты по строгому ключу. Затем было определено, что бизнес-единицей является сайт клиента, а не корпорация, что исключило из списка 6 тысяч пар, которые были легитимными — отдельные филиалы одной сети. Осталось 4 200 пар для промежуточного уровня, из которых 3 800 были закрыты с высокой оценкой. Для ручного обзора осталось 400 пар, и два человека закрыли их за три дня. Урок был не в выборе инструмента. Он заключался в том, что определение бизнес-единицы — сайт против корпорации — уменьшило больше шума, чем любое алгоритмическое улучшение. ## Предотвращение: почему дубликаты возвращаются Три основных источника возвращают дубликаты после Go Live: ручной ввод без активных правил сопоставления (Matching Rules), интеграции, создающие новую запись вместо обновления (Upsert по External ID решает большинство из них), и формы Web-to-Lead без проверки существования. Если эти три источника не были закрыты, уровень дубликации вернется к исходному в течение одного-двух лет. ## Распространенные риски и действия по предотвращению | Риск | Как он проявляется на практике | Действие по предотвращению | | --- | --- | --- | | Агрессивное объединение | Разные клиенты объединены и их невозможно разделить | Высокий порог оценки + обзор в серой зоне | | Отсутствие определения уникальности | Повторяющиеся споры о том, что считать одним и тем же клиентом | Задокументированное решение на уровне сущности | | Потеря истории | Активности и возможности исчезли при объединении | Отчет "Что изменилось" и сохранение исходных идентификаторов | | Очистка без предотвращения | Дубликаты возвращаются через несколько месяцев | Matching Rules, Upsert и защищенные формы | | Очистка после загрузки | Каждое объединение затрагивает живые связи | Очистка на этапе Staging | ## Как измерять успех | Область | Что измеряется | Частота проверки | | --- | --- | --- | | Уникальность (Uniqueness) | Оценочная доля дубликатов по сущности | Еженедельно при миграции, ежеквартально после | | Точность объединения | Процент отмененных или вручную исправленных объединений | При каждой волне объединений | | Предотвращение | Новые записи, заблокированные как дубликаты при вводе | Ежемесячно | | Бизнес-влияние | Двойные обращения к клиенту, точность отчетов по клиентам | Ежеквартально | Профессиональная поддержка в создании правил уникальности и предотвращения предоставляется в рамках [услуги интеграций и данных](/ru/integrations-data). ## Чек-лист перед запуском объединения - ☐ Определена бизнес-единица: корпорация, сайт или договор - ☐ Созданы столбцы нормализации без изменения источника - ☐ Три уровня сопоставления с задокументированными числовыми порогами - ☐ Политика Golden Record на уровне поля, одобренная бизнесом - ☐ Определено, что происходит с активностями, возможностями и владением - ☐ Исходные идентификаторы сохраняются после объединения - ☐ Отчет "Что изменилось" может быть сгенерирован и восстановлен - ☐ Пробный запуск на выборке с ручной проверкой - ☐ Matching Rules и Upsert активны для предотвращения - ☐ Назначен постоянный ответственный за процесс после Go Live ## Профессиональные ресурсы - Salesforce Data 360 — https://www.salesforce.com/data/ - Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html - HPI Pro – Интеграции и данные — https://hpi.pro/integrations-data ### Вопросы и ответы **Что считается дубликатом, а что нет?** Это бизнес-решение, а не техническое. Два филиала одной корпорации могут быть двумя легитимными записями для продаж и одной записью для выставления счетов. Перед запуском инструмента дедупликации необходимо принять решение на уровне сущности: является ли бизнес-единицей корпорация, объект или контракт. **Удалять до загрузки или после?** Удаляйте до загрузки. Дублирующаяся запись, которая уже была загружена, создает связи — активности, кейсы, возможности — и любое позднее слияние становится рискованной операцией с потерей истории. После загрузки остается только текущее обеспечение, а не массовая очистка. **Что делать, если две записи содержат разную, но верную информацию?** Создайте «золотую запись» (Golden Record) на уровне поля, а не на уровне записи: для каждого поля устанавливается правило приоритета — предпочтительная исходная система, самая актуальная или проверенное значение. Таким образом, вы не потеряете правильный адрес только потому, что вторая запись была выбрана как победитель. **Достаточно ли правил сопоставления Salesforce?** Они достаточны для текущей ручной обработки, но не для массовой очистки перед миграцией. Для первоначальной очистки требуется инструмент или скрипт, который выполняет нечеткое сопоставление (Fuzzy Matching) на основе нормализации текста и позволяет провести ручной анализ «серой зоны» перед слиянием. **Какой процент дубликатов считается «нормальным»?** В старых базах данных, которыми не управляли, обычно наблюдается 8-20% дубликатов на уровне контактов и 3-10% на уровне компаний. Практическая цель — не ноль, а согласованный порог — например, меньше 2% — с процессом, который предотвращает возвращение к ухудшению. --- ## Единый источник истины (Source of Truth) в организации: кто отвечает за клиента, продукт, заказ и оплату? URL: https://hpi.pro/ru/insights/salesforce-source-of-truth Когда нет четкого определения, кто уполномочен изменять данные, каждая интеграция превращается в переговоры, и в итоге две системы перезаписывают данные друг друга. Данное руководство показывает, как определить единый источник истины для каждой сущности на уровне поля, как отличить систему-отображение от уполномоченной системы и как обеспечить соблюдение данного решения на уровне кода, а не только документации. ## Краткий ответ «Единый источник истины» — это не технический вопрос, а вопрос полномочий: кто в организации имеет право определять правильность определённого значения. Если такое решение не принимается явно, оно принимается тайно — тем, кто написал последнюю интеграцию. Ключевое правило: право собственности определяется на уровне поля, а не на уровне системы. Попытки объявить «ERP является источником истины для клиента» терпят крах, как только отдел обслуживания обновляет номер телефона в Salesforce, а ночная синхронизация удаляет это обновление. ## Три вопроса, определяющие право собственности Для каждой сущности, а затем для каждой группы полей следует задать вопросы: где данные были **первоначально созданы**, кто **уполномочен** в бизнес-процессе изменять их, и кто **несёт ответственность** в случае их некорректности. Во всех трёх случаях ответом должна быть должность, а не название системы. Система определяется должностью. Если ответы указывают на две разные должности, это почти всегда признак того, что два разных поля были объединены в одно. ## Пример матрицы прав собственности | Сущность / Поле | Источник истины | Salesforce | Направление синхронизации | |---|---|---|---| | Юридическое название, ИНН, условия оплаты | ERP | Только для чтения | ERP → Salesforce | | Контактное лицо, должность, предпочтения | Salesforce | Редактирование | Salesforce → Маркетинговые системы | | Каталог продукции и базовый прайс-лист | ERP / PIM | Только для чтения | ERP → Salesforce | | Коммерческое предложение и утверждённая скидка | Salesforce | Редактирование | Salesforce → ERP | | Подтверждённый заказ и статус доставки | ERP | Только для чтения | ERP → Salesforce | | Задолженность и статус взыскания | Финансовая система | Только для чтения | Финансовая система → Salesforce | | Активность, обращения и коммуникации | Salesforce | Редактирование | Без внешней синхронизации | Эта таблица является результатом. Она компактна, содержится в одном документе, и каждая новая интеграция проверяется по ней до начала разработки. ## Разделение между представлением и полномочиями Большинство конфликтов между системами устраняются, когда становится понятно, что представление данных не требует их копирования. Остаток задолженности, отображаемый продавцу, не обязательно должен быть полем в Salesforce, которое обновляется каждую ночь; это может быть удалённое представление или слой федерации. Каждое скопированное поле — это операционное обязательство: синхронизация, сбой, расхождение и время. Прежде чем копировать, следует задаться вопросом, требуется ли автоматизация или историческая отчётность. Если нет — предпочтительнее отображать, а не копировать. Более подробное описание этого подхода представлено в статье «Zero Copy и федерация в Data 360». ## Конфликты: принятие решений заранее, а не в реальном времени Даже при наличии чёткого определения прав собственности возникают ситуации одновременного обновления. Возможны три правила: приоритет системы (владелец всегда выигрывает), последняя временная метка или пометка для ручной обработки. Третье правило является наиболее безопасным для конфиденциальных полей — при условии, что существует очередь обработки с назначенным ответственным, а не просто запись в журнале, которая накапливается. ## Сценарий: организация с двумя истинами для одного адреса Компания, оказывающая услуги инфраструктуры, управляла адресом клиента в двух системах: ERP для выставления счетов и системой выездного обслуживания для координации работы технических специалистов. Обе системы синхронизировались с Salesforce двунаправленно. Результат: адрес постоянно менялся туда-обратно, а технические специалисты прибывали по адресу для выставления счетов. Решение заключалось не в исправлении синхронизации, а в декомпозиции сущности. Были определены два отдельных поля — адрес для выставления счетов, принадлежащий ERP, и адрес обслуживания, принадлежащий системе выездного обслуживания. Оба поля были только для чтения в Salesforce, со ссылкой на запрос на изменение, направляемый соответствующему владельцу. Количество сервисных обращений, закрытых как «неверный адрес», значительно снизилось в течение следующего квартала. Урок: когда системы «борются» за поле, часто речь идёт о двух разных бизнес-данных, которым присвоено одно и то же имя. ## Обеспечение: от документа к реальности Матрица прав собственности работает только в том случае, если она реализована в трёх ключевых точках: Field-Level Security, которая предотвращает редактирование на стороне, не являющейся владельцем; интеграционный пользователь с ограниченными разрешениями только к полям, находящимся в его владении; и ежемесячный отчёт, показывающий поля, которые были обновлены в нарушение политики. Последний отчёт выявляет давно существующие интеграции, о которых никто не помнит. Документирование значения каждого поля напрямую связано с картой данных для миграции. ## Распространённые риски и профилактические меры | Риск | Как проявляется на практике | Превентивная мера | |---|---|---| | Право собственности на уровне системы | Противоречия внутри одной и той же сущности | Принятие решения на уровне поля или группы полей | | Двусторонняя синхронизация по умолчанию | Значения, периодически изменяющиеся | Одностороннее направление + режим чтения на другой стороне | | Избыточное копирование | Десятки синхронизированных полей без потребителя | Отображать вместо копирования | | Документ без обеспечения | Политика размывается в течение нескольких месяцев | Разрешения на уровне поля + мониторинг отклонений | | Отсутствие очереди конфликтов | Противоречия накапливаются незаметно | Очередь обработки с назначенным ответственным и SLA | ## Как измерить успех | Область | Что измеряется | Частота проверки | |---|---|---| | Согласованность | Доля несоответствий в ключевых полях между системами | Ежемесячно | | Отклонения от политики | Записи в полях, сделанные вне определённого владельца | Ежемесячно | | Конфликты | Количество и время закрытия элементов в очереди | Еженедельно | | Операционное воздействие | Сбои, вызванные некорректными данными | Ежеквартально | Разработка и обеспечение выполнения матрицы прав собственности осуществляется в рамках услуг по интеграции и работе с данными. ## Чек-лист для определения «единого источника истины» - ☐ Список центральных сущностей в организации - ☐ Для каждой сущности: где создана, кто уполномочен, кто отвечает за ошибку - ☐ Право собственности определено на уровне поля или группы полей - ☐ Явное направление синхронизации для каждой группы - ☐ Каждое копируемое поле проходит проверку «имеет потребителя» - ☐ Выбрано и задокументировано правило разрешения конфликтов - ☐ Существует очередь ручной обработки с назначенным ответственным и SLA - ☐ Field-Level Security соответствует матрице - ☐ Интеграционный пользователь ограничен полями, находящимися в его владении - ☐ Ежемесячный отчёт по отклонениям от политики ## Профессиональные ресурсы - Salesforce Data 360 — https://www.salesforce.com/data/ - Архитектура Salesforce Data 360 — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html - HPI Pro – Интеграции и данные — https://hpi.pro/integrations-data ### Вопросы и ответы **Могут ли две системы быть источником истины для одной и той же сущности?** Для одной и той же сущности — да, для одного и того же поля — нет. Платежные реквизиты могут принадлежать ERP-системе, в то время как контактные данные и активность — Salesforce, применительно к одному и тому же клиенту. Недопустимо, чтобы две стороны могли записывать данные в одно и то же поле без четкого правила разрешения конфликтов. **В чем разница между System of Record и System of Engagement?** System of Record — это место, уполномоченное определять значение; System of Engagement — это место, где люди работают с этими данными. Salesforce чаще всего является System of Engagement для клиента, а также System of Record для воронки продаж и взаимодействия с клиентом. Путаница между этими двумя понятиями является частой причиной ненужной двусторонней синхронизации. **Когда оправдана двусторонняя синхронизация?** Только когда обе стороны действительно создают ценность для одного и того же поля, и существует однозначное правило разрешения конфликтов — например, метка времени или приоритет системы. В любом другом случае предпочтительнее однонаправленная синхронизация с представлением только для чтения на другой стороне. Двусторонняя синхронизация удваивает количество возможных сбоев. **Как фактически обеспечить владение данными?** На трех уровнях: разрешения полей, которые предотвращают редактирование на стороне, не являющейся владельцем; интеграция, которая записывает данные только в принадлежащие ей поля; и мониторинг, который сообщает о записи вне установленной политики. Документ о владении без технического обеспечения теряет свою актуальность в течение нескольких месяцев. **Что делать, если ни одна система не подходит на роль источника истины?** Это признак того, что сущность определена слишком широко. Разделите ее: 'Продукт' может быть разбит на каталог (ERP), коммерческое предложение (CRM) и разрешение на использование (операционная система). У каждой части будет свой четкий источник истины. --- ## Метрики качества данных в Salesforce: что измерять и как устанавливать пороговые значения URL: https://hpi.pro/ru/insights/salesforce-data-quality-metrics Качество данных становится управляемым только тогда, когда оно имеет числовое выражение, пороговое значение и ответственного. Данное руководство объясняет, какие параметры действительно стоит измерять в Salesforce, как установить непроизвольные пороговые значения, как связать каждую метрику с бизнес-эффектом и как создать информативную систему показателей (Scorecard), к которой будут обращаться чаще одного раза. ## Короткий ответ Качество данных — это не свойство информации, а результат процессов. Поэтому измерение, не связанное с бизнес-эффектом и ответственными лицами, ничего не меняет: оно создает отчет, который кто-то открывает раз в квартал и формально утверждает. Эффективная система показателей (Scorecard) состоит всего из четырех-шести метрик, каждая из которых имеет пороговое значение, ответственного и определенное корректирующее действие. Отличие Scorecard от отчета в том, что в первом случае каждое «красное» значение активирует конкретного исполнителя. ## Пять измерений — и что из них действительно измеряется | Измерение | Что проверяет | Когда критично | | --- | --- | --- | | Полнота (Completeness) | Доля заполненных полей, влияющих на решение | Всегда | | Достоверность (Validity) | Соответствие формату и допустимым значениям | Интеграции, регулирование | | Уникальность (Uniqueness) | Дубликаты на уровне сущности | Перед преобразованием и после слияний | | Актуальность (Timeliness) | Насколько данные соответствуют реальности | Прогнозирование, сервис, сбор платежей | | Согласованность (Consistency) | Идентичность одних и тех же данных в разных системах | Множество систем и финансовая отчетность | Организации практически всегда начинают с первых трех. Актуальность и Согласованность становятся важными, когда другие системы начинают опираться на CRM — и именно в этот момент сбой в них обходится дороже всего. ## Полнота: не каждое поле стоит измерять Измерение заполняемости 300 полей дает бессмысленный результат. Правильный подход — определить для каждого основного процесса небольшой «пакет полей» (пять-восемь полей), без которых процесс не работает, и измерять только их. Важно добавить проверку искусственной заполненности: процент записей, где поле заполнено подозрительно повторяющимся значением (точка, тире, «неизвестно»). Это часто первый признак того, что установленное правило мешает работе, а не улучшает ее. ## Актуальность: измерение, которое все игнорируют Данные могут быть полными, корректными и уникальными, но при этом просто устаревшими. Поле статуса клиента, которое не обновлялось 14 месяцев, — это не данные, это воспоминание. Измерение просто: распределение времени с момента последнего обновления для существенных полей, в сравнении со скоростью изменения реальности. В возможностях продаж это напрямую переводится в качество прогноза: процент открытых возможностей, чей срок закрытия уже прошел, — один из самых сильных и быстрых для расчета показателей. ## От порога к действию: что происходит, когда метрика «красная» Для каждой метрики определяются три уровня — зеленый, желтый, красный — и для каждого уровня действие. Желтый инициирует проверку в команде; красный инициирует корректирующее действие с целевым сроком. Без такого определения метрика становится информацией, а не инструментом управления. Сами действия должны быть разнообразными: иногда коррекция — это одноразовая очистка, иногда изменение бизнес-процесса, и нередко правильное решение — удалить поле, потому что оно никому не нужно. Дополнительные сведения о дубликатах можно найти в [Удаление дубликатов данных Salesforce](/ru/insights/salesforce-data-deduplication), а о структуре, создающей качество, в [Модель данных Salesforce](/ru/insights/salesforce-data-model-design). ## Сценарий: страховая компания, измерявшая все и не улучшившая ничего Страховая компания создала панель мониторинга качества с 34 метриками. Она работала год. Ни одна метрика не улучшилась значительно, потому что отсутствовала ответственность: панель принадлежала команде BI, а поля — агентам. На втором этапе панель сократили до четырех метрик: уровень заполняемости пакета полей андеррайтинга, процент полисов с просроченной датой продления, уровень дубликатов на уровне страхователя и процент писем, отправка которых провалилась. За каждой метрикой закрепили регионального менеджера с квартальной целью, и метрика представлялась на совещаниях по продажам, а не на IT-совещаниях. За два квартала две метрики превысили пороговое значение. Третья метрика не изменилась — а проверка показала, что поле требовалось в анкете, которую агенты заполняли после закрытия сделки, то есть в момент, когда у них не было стимула. Решением стало изменение места поля в процессе, а не добавление нового правила валидации. ## Распространенные риски и профилактические меры | Риск | Как проявляется на практике | Профилактическая мера | | --- | --- | --- | | Слишком много метрик | Панель мониторинга, по которой никто не действует | Четыре-шесть метрик с ответственными | | Метрика без порога | Обсуждение "хороши ли 78%" | Порог, исходящий из бизнес-эффекта | | Ответственность в IT | Отсутствие изменений в поведении на местах | Бизнес-владелец для каждой метрики | | Валидация без измерения | Поля, заполненные фиктивными значениями | Измерение искусственной заполненности | | Единовременное измерение | Временное улучшение, которое откатывается | Постоянный периодический Scorecard | ## Как измерять успех | Область | Что измеряется | Частота проверки | | --- | --- | --- | | Полнота (Completeness) | Доля заполненных пакетов полей для процесса | Ежемесячно | | Актуальность (Timeliness) | Медианное время с момента последнего обновления | Ежемесячно | | Уникальность (Uniqueness) | Оценочная доля дубликатов | Ежеквартально | | Влияние | Жалобы, сбои интеграции, точность прогноза | Ежеквартально | Создание Scorecard и операционного процесса осуществляется в рамках [услуги интеграции и работы с данными](/ru/integrations-data). ## Чек-лист для настройки измерения - ☐ Выбрано не более шести метрик - ☐ Для каждой метрики определен пакет полей, а не весь объект - ☐ Для каждой метрики установлен порог, исходящий из бизнес-эффекта - ☐ Для каждой метрики назначен бизнес-владелец с полным именем - ☐ Определены действия для «желтого» и «красного» уровней - ☐ Измеряется также искусственная заполненность, а не только заполненность - ☐ Существует базовый уровень (Baseline) до начала улучшений - ☐ Отчет представляется на бизнес-форуме, а не на техническом - ☐ Проверена необходимость проблемного поля - ☐ Установлен периодический пересмотр самого списка метрик ## Профессиональные источники - Salesforce Data 360 — https://www.salesforce.com/data/ - Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html - HPI Pro – Интеграции и данные — https://hpi.pro/integrations-data ### Вопросы и ответы **С какого измерения стоит начать?** Начните с полноты (Completeness) для небольшой группы полей, влияющих на принятие решений, а не для всех полей. Скорость заполнения – это самый простой для расчета показатель, самый легкий для объяснения руководству, и обычно тот, который быстро выявляет неработающие процессы. **Как установить непроизвольное пороговое значение?** Выделите его из последствий. Если 5% электронных писем некорректны, а кампания генерирует 200 лидов в месяц, это можно перевести в ожидаемые потери. Порог устанавливается там, где стоимость исправления начинает превышать ущерб, а не на основе «круглого» числа, которое звучит хорошо. **Кто несет ответственность за метрику качества?** Владелец процесса, который создает данные, а не команда по данным. Команда по данным измеряет и предоставляет инструменты; тот, кто продает, собирает или обслуживает, является тем, кто может изменить поведение, приводящее к расхождениям. Метрика без бизнес-владельца не улучшается. **Решают ли Validation Rules проблемы качества данных?** Частично. Они предотвращают ввод некорректных значений при ручном вводе, но вынуждают пользователей заполнять любое значение просто для того, чтобы продолжить. Правило валидации должно сопровождаться метрикой, которая проверяет, было ли поле заполнено по-настоящему или искусственно. **Какова правильная частота измерения?** Во время преобразования данных — еженедельно. В процессе текущей деятельности — ежемесячно для большинства показателей и ежеквартально для обзора руководством. Ежедневное измерение качества данных почти всегда создает шум, по которому никто не действует. --- ## Agentforce для обслуживания клиентов: сценарии использования URL: https://hpi.pro/ru/insights/agentforce-customer-service-use-cases Не каждое обращение подходит для ИИ-агента, и порядок внедрения определяет успех или провал проекта. Данное руководство ранжирует распространенные сценарии обслуживания по степени зрелости, объясняет требования к каждому из них и показывает, какие сценарии могут показаться привлекательными, но на самом деле подрывают доверие на ранней стадии. ## Краткий ответ В сфере клиентского обслуживания разница между расширяющимся и затухающим пилотным проектом почти всегда зависит от выбора изначального сценария. Зрелый сценарий основан на одном надежном источнике информации, не содержит необратимых действий и имеет достаточный объем, оправдывающий его поддержку. Привлекательные сценарии — обработка жалоб, удержание клиентов, принятие решений о возврате средств — это именно те, которые требуют взвешенного суждения, такта и информации из множества систем. Они приходят на третьем этапе, а не на первом. Общие рамки для подбора вариантов использования представлены в статье [Agentforce для предприятий](/ru/insights/agentforce-for-enterprises). ## Рейтинг сценариев по степени зрелости | Сценарий | Зрелость | Требуется | Основной риск | | --- | --- | --- | --- | | Запросы о статусе | Высокая | Одно надежное поле в CRM | Практически отсутствует; ошибка обратима | | Часто задаваемые вопросы к базе знаний | Высокая | Актуализированные статьи Knowledge для распространенных сценариев | Ссылка на устаревшую политику | | Помощь оператору во время звонка | Высокая | Knowledge и история кейса | Оператор принимает неверный ответ | | Маршрутизация и классификация обращений | Средняя | Единообразная таксономия типов обращений | Ошибочная классификация, увеличивающая время обработки | | Обновление данных и простые действия | Средняя | Точные разрешения и ограниченные действия | Неверное обновление записи клиента | | Координация, отмена и изменение даты | Средняя | Стабильная интеграция с операционной системой | Сбой интеграции перед клиентом | | Возвраты и компенсации | Низкая | Письменная политика, полномочия и человеческое одобрение | Финансовые риски и прецедент с клиентом | | Обработка жалоб и удержание | Низкая | Понимание контекста, такт и полная история | Ущерб бренду и доверию | ## Три сценария, с которых стоит начать Запросы о статусе – лучшая отправная точка. Клиент спрашивает, где его заказ, каков статус заявки, когда приедет техник. Ответ базируется на одном поле, записи не производятся, а объем обычно высок. Успех также легко измерить: получил ли клиент ответ и не обратился ли снова. Часто задаваемые вопросы по базе знаний – второй сценарий. Здесь вызов не в работе агента, а в контенте, поэтому работа начинается с проверки двадцати самых распространенных запросов и обеспечения наличия утвержденной и актуальной статьи для каждого. Помощь оператору – это сценарий, с которого наиболее рекомендуется начинать, если есть опасения. Агент предлагает ответ, оператор подтверждает или корректирует. Каждая корректировка является обучающим данным, и внешний риск минимален. Организации, начинающие с этого, выходят на внешнее использование с реальным тестовым набором вместо предположений. Что необходимо для поддержания базы знаний под нагрузкой, подробно описано в статье [Управление знаниями для Agentforce](/ru/insights/agentforce-knowledge-readiness). ## Что откладывают на более поздний этап Возвраты и компенсации требуют наличия письменной политики, которая в большинстве организаций отсутствует в полном объеме — она живет в компетенции руководителей команд. Прежде чем агент приступит к работе в этой области, необходимо разработать политику, и тогда обнаруживается, что это отдельная организационная задача. Обработка жалоб требует понимания эмоционального контекста и полной истории. Даже если технический ответ верен, формулировка имеет решающее значение. Это область, где быстрая эскалация почти всегда предпочтительнее попытки решения проблемы. Сквозные сценарии, где информация распределена между тремя системами без единого источника истины — не из-за ограничений ИИ, а потому, что расхождения в данных проявятся здесь первыми и будут восприняты как неудача агента. ## Обязательные правила эскалации Четыре жестких триггера: прямое требование общения с человеком, обнаружение негативного тона или слов, указывающих на эскалацию, две неудачные попытки ответить на один и тот же вопрос, а также любое обращение, касающееся заранее определенной конфиденциальной темы. Передача должна сохранять контекст. Клиент, вынужденный повторять всё оператору, воспринимает агента как препятствие, и именно это он запомнит. Краткое изложение разговора, что было проверено и что найдено, должно автоматически передаваться оператору. Подробное описание проектирования путей эскалации в рамках системы каналов представлено в [Omni-Channel и SLA в Service Cloud](/ru/insights/service-cloud-omnichannel-sla). ## Сценарий: колл-центр, заменивший пилотный проект через две недели Компания по производству потребительских товаров планировала начать работу с агентом, который будет обрабатывать запросы на возврат — сценарий с наибольшим количеством жалоб. В течение первых двух недель стало ясно, что каждый запрос требовал проверки условий гарантии в системе ERP, проверки запасов и принятия решения, которое фактически принималось по усмотрению менеджера. Пилотный проект был переключен на другой сценарий: ответы на статус уже существующего возврата. Те же клиенты, та же область, но основано на единственном поле статуса. Объем был высоким, уровень эскалации низким, и колл-центр немедленно заметил снижение повторных обращений. Через полгода, после того как политика возвратов была оформлена в виде утвержденного документа, первоначальный сценарий вернулся к планированию — на этот раз с человеческим одобрением каждого возврата. Именно порядок, а не технология, сделал это возможным возможным. ## Риски и меры предотвращения | Риск | Как это выглядит в колл-центре | Мера предотвращения | | --- | --- | --- | | Начало с эмоционального сценария | Жалобы, поступающие руководству в первую неделю | Начало со сценария предоставления информации, а не решения проблем | | Отсутствие пути к человеку | Клиент застрял в цикле вопросов | Кнопка переключения на оператора на любом этапе и жесткие триггеры | | Потеря контекста при эскалации | Клиент повторяет историю оператору | Автоматическая передача краткого содержания разговора | | Неписаная политика | Непоследовательные ответы в разных случаях | Составление политики до внедрения сценария | | Множество сценариев одновременно | Недостаточная пропускная способность для поддержки и снижение качества | До трех активных сценариев в первый год | ## Показатели в обслуживании | Показатель | Определение | Частота | | --- | --- | --- | | Удержание (Containment) | Процент обращений, закрытых без участия оператора и без повторного обращения | Еженедельно | | Коэффициент повторных обращений | Клиенты, повторно обращавшиеся по тому же вопросу в течение недели | Еженедельно | | Время до эскалации | Сколько времени проходит до перевода на человека, когда это необходимо | Еженедельно | | Удовлетворенность каналом | Сравнение с аналогичным человеческим каналом | Ежемесячно | | Время обработки оператором | Сократила ли фактически помощь продолжительность звонка | Ежемесячно | Показатель удержания без коэффициента повторных обращений может быть обманчивым. Звонок, быстро закрытый из-за того, что клиент отчаялся, считается успехом, поэтому оба показателя всегда рассматриваются вместе. Когда требуется сопровождение в выборе сценариев и построении путей эскалации, **[услуги Agentforce и AI](/ru/agentforce-ai)** являются практическим следующим шагом. ## Чек-лист для выбора первого сценария - ☐ Сценарий основан на одном надежном источнике информации - ☐ В первой версии не содержит необратимых действий - ☐ Месячный объем оправдывает текущую поддержку - ☐ Имеются утвержденные статьи для распространенных сценариев - ☐ Определены четыре триггера эскалации - ☐ Передача оператору включает краткое содержание разговора - ☐ Агент заявляет, что он не человек, при открытии - ☐ Измерен базовый уровень удержания и повторных обращений - ☐ Определено максимальное количество одновременно активных сценариев ### Вопросы и ответы **С какого сценария лучше всего начать?** С запросов о статусе. Они характеризуются высоким объемом, опираются на одно или два поля в CRM, не требуют написания текста и легко поддаются измерению успеха. Кроме того, это тот сценарий, где клиент наиболее снисходителен, поскольку ожидает информацию, а не сложное решение. **Стоит ли начинать с внутреннего агента для сотрудников или с агента для клиентов?** Почти всегда с внутреннего. Сотрудник определяет неверный ответ и исправляет его, поэтому ошибка на этапе обучения обходится недорого. Та же ошибка в работе с клиентом подрывает доверие и доходит до руководства. Трех-шестимесячное внутреннее тестирование создает необходимый набор данных для внешнего развертывания. **Что делать с недовольным клиентом, обратившимся к агенту?** Немедленно определить и эскалировать. Выявление негативного тона или эскалирующих слов должно быть строгим правилом, которое без дополнительных усилий передает клиента человеку. Агент, пытающийся успокоить недовольного клиента, порождает именно те истории, которые останавливают проекты. **Должен ли агент заявлять, что он не человек?** Да, и во многих случаях это требуется регулятором. Кроме того, это практическое решение: клиент, обнаруживший в середине разговора, что общался с системой, чувствует себя обманутым. Краткое заявление в начале, наряду с четким способом связи с человеком, снижает количество жалоб. **Сколько сценариев следует запускать параллельно в первый год?** Один-три. Каждый сценарий требует собственного контента, тестирования и мониторинга, и организация, запускающая шесть параллельно, обнаруживает, что у нее нет ресурсов для должного поддержания ни одного из них. Правильное расширение происходит после того, как первый сценарий стабильно функционирует в течение квартала. --- ## Grounding и RAG в Agentforce: как подключить агента к надежным знаниям URL: https://hpi.pro/ru/insights/agentforce-grounding-rag Агент не придумывает ответы из злого умысла — он придумывает их, когда источник информации неполон, противоречив или несанкционирован. Данное руководство разбирает Grounding на составляющие: какие источники подключать, как фрагментировать и маркировать контент, как сохранять разрешения при извлечении, и как измерять точность, прежде чем агент начнет взаимодействовать с клиентом. ## Краткий ответ Граундинг (Grounding) — это разница между агентом, цитирующим утвержденную политику, и агентом, формулирующим нечто, что звучит правдоподобно. В Agentforce уровень граундинга состоит из четырех компонентов, которые строятся последовательно: какие источники объявлены источниками истины, как контент сегментируется и индексируется для извлечения, как сохраняются права доступа пользователя в момент запроса и что происходит, если подходящий источник не найден. Большинство неудач, которые мы видим на пилотных проектах, не являются ошибками модели. Это неудачи базы знаний, которой никто не владел уже два года, документов, разрезанных посередине таблицы, и отсутствия пути отката (Fallback). Поэтому работа начинается с проверки готовности контента, а не с написания инструкций. Широкий контекст выбора сценариев использования представлен в [Agentforce для предприятий](/ru/insights/agentforce-for-enterprises). ## Четыре уровня граундинга | Уровень | Что определяет | Признак сбоя | Признак успеха | |---|---|---|---| | Источники | Какие репозитории объявлены источниками истины и кто является их владельцем | Два противоречивых ответа на один и тот же вопрос | Список источников с владельцем и датой проверки | | Представление | Сегментация (Chunking), метаданные и тегирование по продукту, языку и версии | Извлеченный фрагмент не относится к вопросу | Измерение Recall на известном наборе вопросов | | Разрешения | Как контекст пользователя ограничивает извлечение | Внутренний контент появляется в ответе для клиента | Проверка Persona для каждого уровня разрешений | | Прозрачность | Цитаты, актуальность (Freshness) и путь отката (Fallback) | Ответ без источника и без признания отсутствия знаний | Процент ответов с действительными цитатами | ## Уровень 1: Объявление источников истины Первый шаг не технический. Берутся двадцать наиболее частых вопросов в выбранном процессе, и для каждого вопроса определяется, где находится правильный ответ в данный момент. Результат почти всегда удивителен: часть ответов находится в статьях базы знаний, часть — в поле CRM, часть — в документе у руководителя команды, а часть — в головах двух опытных сотрудников. Для каждого источника, который включается в систему, должен быть назначен владелец, согласованная частота обновления и последняя дата проверки. Источник без владельца через несколько месяцев превращается в источник устаревшей информации, и агент будет продолжать цитировать его с уверенностью. Источники, у которых нет владельца, остаются вне системы, даже если они богаты контентом. Сложное решение заключается в том, что не подключать. Репозитории электронной почты, каналы чата и презентации по продажам кажутся золотой жилой, но оказываются основным источником неверных ответов, потому что в них нет различия между черновиком, отклоненным предложением и утвержденной политикой. Основы очистки и подготовки базы знаний подробно описаны в [Готовность знаний для Agentforce](/ru/insights/agentforce-knowledge-readiness). ## Уровень 2: Сегментация (Chunking), метаданные и релевантность Качество извлечения зависит меньше от модели и больше от того, как контент разбит. Резка по фиксированному количеству символов разрушает таблицы, списки шагов и условия допуска — именно тот контент, из которого извлекаются точные ответы. Предпочтительна резка по структуре: подзаголовок, этап процесса или строка таблицы, которая сохраняется целиком со своим контекстом. Метаданные (Metadata) позволяют сузить область поиска еще до того, как модель вообще вступит в игру. Минимальный набор тегов, который следует требовать: продукт или линейка услуг, рынок или страна, язык, целевая аудитория (клиент или внутренний пользователь), срок действия и статус утверждения. Без тегирования рынка и языка агент в глобальной организации будет смешивать политики двух стран в одном ответе. Проверка релевантности носит количественный, а не интуитивный характер: создается набор из 50-100 реальных вопросов с правильным ответом и правильным источником, и измеряется, в скольких случаях был извлечен правильный фрагмент. Низкий показатель Recall указывает на проблему представления, и ее решение намного дешевле, чем замена модели или переписывание инструкций. ## Уровень 3: Разрешения в момент извлечения Это уровень, который проваливает пилотные проекты при проверках безопасности. Правило простое: извлечение должно выполняться в контексте разрешений пользователя, а не в контексте широкой учетной записи интеграции. Если фрагмент информации был скрыт от пользователя в интерфейсе, он должен быть скрыт и из ответа агента. На практике требуются три проверки. Во-первых, сопоставление между уровнями классификации во внешнем источнике и профилями (Profiles) и наборами разрешений (Permission Sets) в Salesforce. Во-вторых, проверка Persona: запускаются одни и те же десять вопросов от имени представителя, руководителя и внешнего клиента, а затем сравниваются ответы. В-третьих, обработка смешанного контента — документ, большая часть которого является публичной, а один абзац конфиденциален, должен быть вырезан или не должен быть включен. В публичном канале безопасным по умолчанию является белый список: только контент, явно помеченный как разрешенный для клиента, попадает в индекс, доступный внешнему агенту. Подход с черным списком всегда пропустит один документ. Модель ответственности между организацией, Salesforce и поставщиком модели подробно описана в [Безопасность Agentforce и разделенная ответственность](/ru/insights/agentforce-security-shared-responsibility). ## Уровень 4: Цитаты, актуальность (Freshness) и откат (Fallback) Эти три механизма превращают агента из замкнутой системы в систему, которую можно проверять. Реальная цитата (Citation) ссылается на фактически извлеченный фрагмент, а не на статью, которую модель упоминает в тексте — это разница между доказательством и приукрашиванием. Процент ответов с действительной цитатой — один из немногих показателей, которые нетехнический руководитель может прочитать и понять. Актуальность (Freshness) требует письменного SLA: политика ценообразования проверяется ежеквартально, процедуры обслуживания — раз в полгода, регуляторный контент — сразу после изменений. Контент, срок действия которого истек, должен автоматически удаляться из индекса, а не оставаться до тех пор, пока кто-то не заметит ошибку. Откат (Fallback) — это поведение, которое важнее всего проверить перед тем, как предоставлять его клиентам. Агент должен явно сообщить, что у него нет подтвержденной информации, и передать запрос дальше, вместо того чтобы формулировать правдоподобный ответ. Хороший вопрос для тестирования: спросить о несуществующем продукте и посмотреть, придумает ли агент для него условия обслуживания. ## Сценарий: Страховая компания с 900 статьями базы знаний Страховая компания хотела, чтобы агент отвечал сотрудникам колл-центра на вопросы об условиях полисов. Первый пилотный проект провалился: 40% ответов были неточными или неполными. Анализ показал, что проблема полностью заключалась на уровне источников — из 900 статей 380 не обновлялись более трех лет, а 60 из них противоречили более новым статьям по той же теме. Команда не трогала модель. Она сократила индекс до трех основных продуктов, всего около 140 статей, назначила владельцев для каждой линейки продуктов и архивировала противоречивые статьи. Были добавлены теги по продукту, году версии и статусу утверждения, и переход к сегментации по разделам вместо фиксированной длины. Второй раунд тестирования на том же наборе из 80 тестовых вопросов достиг гораздо более высокой точности, и что более важно — в случаях, когда не было источника, агент передавал запрос человеку вместо того, чтобы угадывать. Вывод, который привел к расширению, был не "AI улучшился", а "мы знаем, на чем он основывается". ## Риски и превентивные меры | Риск | Как обнаруживается поздно | Превентивные меры | |---|---|---| | Противоречивые источники | Разные ответы на один и тот же вопрос у разных представителей | Архивирование старых версий и единый источник истины для каждой темы | | Сегментация (Chunking), разрушающая структуру | Частичные ответы в многоэтапных процессах | Сегментация по разделам с сохранением заголовка контекста | | Разрешения на уровне интеграции | Раскрытие внутренней информации клиентскому каналу | Извлечение в контексте пользователя и проверки Persona | | Отсутствие срока действия | Цитирование уже отмененной политики | SLA для обновления и автоматического удаления из индекса | | Неопределенный Fallback | Формулирование убедительного ответа без источника | Протестированный маршрут "нет подтвержденной информации" в каждой версии | ## Метрики для уровня граундинга (Grounding) | Метрика | Определение | Частота | |---|---|---| | Retrieval recall | Процент вопросов, для которых был извлечен правильный фрагмент | В каждой версии | | Citation validity | Процент ответов с существующим и действительным источником | Еженедельно | | Content freshness | Процент статей в индексе, соответствующих сроку действия | Ежемесячно | | Fallback rate | Процент запросов, переданных человеку при отсутствии источника | Еженедельно | | Permission leakage | Количество обнаруженных утечек в проверках Persona | В каждой версии | Высокий процент Fallback не является неудачей — это карта пробелов в контенте. Список вопросов, которые привели к Fallback, является наилучшим приоритетом для создания новых статей. Если внутренней пропускной способности для создания контролируемого уровня граундинга недостаточно, [сервис Agentforce и AI](/ru/agentforce-ai) — это практический путь вперед. ## Чек-лист перед подключением агента к источникам - ☐ Двадцать самых частых вопросов сопоставлены с текущим источником ответа - ☐ У каждого источника в индексе есть названный владелец и частота обновления - ☐ Противоречивые источники обнаружены и архивированы - ☐ Существует тегирование по продукту, рынку, языку, аудитории и дате истечения срока действия - ☐ Сегментация (Chunking) сохраняет таблицы и списки шагов - ☐ Извлечение выполняется в контексте разрешений пользователя - ☐ Выполнена проверка Persona для каждого соответствующего уровня разрешений - ☐ Существует набор из 50 тестовых вопросов с правильным ответом и источником - ☐ Цитаты (Citations) ссылаются на фактически извлеченный фрагмент - ☐ Маршрут Fallback сформулирован и протестирован на клиентском канале ### Вопросы и ответы **В чем на самом деле разница между Grounding и RAG?** RAG — это механизм: извлечение релевантных фрагментов информации и добавление их к промпту. Grounding — это бизнес-обязательство, что извлекаемая информация является утвержденным, актуальным и разрешенным источником правды для конкретного пользователя. Можно реализовать отличный RAG на устаревшем хранилище документов и получать полностью уверенные, но неверные ответы. **Сколько статей Knowledge необходимо, прежде чем начинать?** Меньше, чем кажется. Лучше двадцать актуальных статей, охватывающих десять наиболее распространенных сценариев, чем тысяча статей, половина из которых написана четыре года назад. Противоречивая статья вреднее, чем отсутствие статьи, потому что агент не может решить, какая из двух версий верна. **Можно ли подключить агента напрямую к SharePoint или Confluence?** Технически да, через индексацию или подключение данных. Главный вопрос — разрешения: если модель разрешений во внешнем источнике не может быть сопоставлена с пользователем в Salesforce, извлечение может раскрыть контент, который пользователь не должен видеть. В таком случае синхронизируется только подмножество, классифицированное как общедоступное-внутреннее. **Почему агент выдает общий ответ, хотя информация есть в статье?** Чаще всего это проблема Chunking или метаданных, а не проблема модели. Если статья обрезана посередине таблицы или отсутствует тегирование продукта, страны и версии, извлечение выдает нерелевантный фрагмент. Быстрая проверка: посмотрите в Trace, какие фрагменты были фактически извлечены, прежде чем обвинять модель. **Что должно произойти, если агент не находит подходящего источника?** Предварительно определенный путь Fallback: явное указание на отсутствие утвержденной информации и передача запроса человеку или форме. Агент, который формулирует правдоподобный ответ без источника, является основным риском при развертывании для клиентов, поэтому такое поведение необходимо проверять в каждой версии. --- ## Human-in-the-Loop в Agentforce: Где ИИ должен остановиться для подтверждения URL: https://hpi.pro/ru/insights/agentforce-human-in-the-loop Человеческое подтверждение каждого действия сводит на нет ценность; отсутствие подтверждения любого действия создает риск. Руководство предлагает метод определения точек остановки на основе обратимости, воздействия и чувствительности, описывает три различных шаблона подтверждения и измеряемые условия для снятия точки подтверждения без потери контроля. ## Краткий ответ Вопрос не в том, нужен ли человек в контуре, а в том, где именно. Утверждение каждого шага сводит на нет экономию и вызывает "усталость от согласования", ведущую к автоматическим одобрениям. Отсутствие согласования необратимых действий приводит к сбоям, требующим вмешательства руководства. Практический метод начинается с декомпозиции процесса на отдельные действия, классификации каждого действия по обратимости и влиянию, а также выбора подходящей модели согласования — блокирующей, постфактум или выборочной. После этого разрабатывается интерфейс принятия решения, чтобы согласование было истинным суждением, а не простым нажатием кнопки. Структура управления, в рамках которой принимаются эти решения, подробно описана в [AI Governance для Agentforce](/ru/insights/agentforce-ai-governance). ## Матрица решений: обратимость vs. влияние | | Низкое влияние | Высокое влияние | | --- | --- | --- | | **Легко обратимо** | Без согласования, только мониторинг | Выборочная проверка процента случаев для аудита | | **Обратимо со стоимостью** | Постфактум аудит | Блокирующее согласование перед выполнением | | **Необратимо** | Блокирующее согласование перед выполнением | Блокирующее согласование + письменное обоснование + аудиторский след | Обратимость оценивается по трем критериям: сколько времени занимает отмена, сколько это стоит и кто был затронут до отмены. Сообщение, отправленное клиенту, необратимо, даже если можно отправить исправление — впечатление уже создано. Обновление внутреннего поля обратимо мгновенно и поэтому не требует остановки. ## Три модели согласования Блокирующее согласование останавливает операцию до принятия решения человеком. Это наиболее затратная по времени модель и поэтому используется для необратимых или высокозначимых операций. Правило: если остановили, человек должен получить всю необходимую для принятия решения информацию на одном экране. Постфактум аудит позволяет сотруднику выполнять действие и передавать результат на проверку в течение определенного временного окна. Подходит для обратимых операций с низкой стоимостью и требует двух условий: короткого временного окна и действительно работающей кнопки отмены. Выборочная проверка выборочно проверяет процент случаев, а не все. Это правильная модель для операций с большим объемом и низким влиянием, а также механизм качества, который впоследствии позволяет обосновать отмену блокирующего согласования в другом месте. ## Разработка интерфейса принятия решений Это часть, которая определяет, является ли участие человека в контуре реальным или формальным. Экран, отображающий только предлагаемое действие, получает автоматическое одобрение. Экран, требующий открытия трех вкладок для проверки, вызывает задержки и обходы. Четыре компонента, которые должны отображаться вместе: предлагаемое действие в одной строке, обоснование на деловом языке, источник, на который опирается сотрудник, со ссылкой на извлеченный фрагмент, и уровень уверенности или сработавшие флаги. Ниже — три варианта, а не два: одобрить, отклонить с указанием причины и исправить до выполнения. Причина отклонения — самый ценный актив в процессе. Она формирует набор для обучения и тестирования следующей версии, поэтому должна представлять собой короткий список распространенных причин, а не свободное текстовое поле, которое никто не заполняет. Как отслеживать эти решения со временем, объясняется в [Observability для AI-агентов](/ru/insights/agentforce-observability). ## Предотвращение формального одобрения "Усталость от согласования" — это ожидаемый сбой, а не сюрприз. Три предупреждающих признака: среднее время принятия решения опускается ниже нескольких секунд, процент отклонений приближается к нулю и массовые согласования в конце смены. Лечение заключается не в обучении, а в дизайне. Сокращается количество согласований путем удаления излишних остановок в обратимых операциях, добавляется постфактум выборочное тестирование, которое создает ответственность, и предоставляется согласующему обратная связь о качестве его решений. Когда согласующий знает, что процент решений проверяется, он начинает читать. Ключевой показатель: если процент исправлений равен нулю в течение нескольких месяцев, это означает либо, что сотрудник отлично работает, и можно сократить остановки, либо что никто не читает. Выборочная проверка — это то, что отличает одно от другого. ## Когда и как отменять точку согласования Отмена — это решение, основанное на данных, а не на ощущениях. Три одновременных условия: достаточный объем задокументированных решений в категории, низкий и стабильный процент исправлений в течение нескольких месяцев подряд и практически проверенный механизм отмены или приостановки. Отмена выполняется поэтапно. Сначала для узкой подгруппы — например, только суммы ниже определенного порога, только клиенты в определенном сегменте, только в рабочее время. Затем результат измеряется в течение месяца. Только после этого происходит расширение. Параллельно постфактум выборочная проверка остается даже после отмены, иначе нет способа выявить деградацию. Также должно быть условие возврата: если процент ошибок превышает заранее определенный порог, блокирующее согласование автоматически возвращается. Без письменного условия возврата решение об отмене само становится необратимым. ## Сценарий: сервисный центр отменил неверное согласование Телекоммуникационная компания внедрила систему, которая формировала ответы на запросы по выставлению счетов. В первой версии каждый ответ проходил утверждение представителем, включая простые ответы о статусе. Время обработки сократилось незначительно, и представители жаловались, что им приходится снова и снова читать один и тот же текст. Команда проанализировала 4,000 согласований и обнаружила, что 78% из них касались исключительно информационных ответов — полностью обратимых и с низким влиянием. Процент исправлений в этой категории был ниже одного процента. В то же время, в категории кредитов процент исправлений был значительно выше. Решение: отменить блокирующее согласование для информационных ответов, с выборочной проверкой процента из них для еженедельного аудита; усилить согласование кредитов и добавить требование письменного обоснования для сумм выше определенного значения. Время обработки значительно сократилось, а отклонения в категории кредитов, наоборот, увеличились — знак того, что согласующие снова стали читать. ## Риски и превентивные меры | Риск | Как он проявляется | Профилактическая мера | | --- | --- | --- | | Согласование всего | Значимость снижается, пользователи обходят | Матрица обратимости vs. влияния для каждого действия | | Автоматическое согласование | Время принятия решения в секундах и ноль отклонений | Постфактум выборочная проверка и индивидуальная обратная связь для утверждающего | | Экран без обоснования | Утверждающий не может адекватно судить | Отображение обоснования, источника и уровня уверенности на одном экране | | Преждевременная отмена | Сбой в рабочей среде после нескольких хороших недель | Измеримые пороги отмены, поэтапное расширение и условия возврата | | Отсутствие документации по отклонениям | Нет возможности учиться для следующей версии | Короткий список причин отклонений и еженедельный обзор | ## Показатели | Показатель | Что он показывает | Периодичность | | --- | --- | --- | | Коэффициент остановки | Процент действий, требующих согласования | Еженедельно | | Коэффициент корректировки | Процент случаев, которые утверждающий изменил или отклонил | Еженедельно | | Медианное время принятия решения | Действительно ли утверждающий читает | Еженедельно | | Результаты выборочной проверки | Ошибки, прошедшие согласование | Ежемесячно | | Фактическое время отмены | Работает ли механизм возврата | В каждой версии | Когда требуется консультация по планированию точек согласования и их адаптации к регуляторным требованиям организации, [сервис Agentforce и AI](/ru/agentforce-ai) является практическим путем для дальнейших действий. ## Чек-лист - ☐ Процесс декомпозирован на отдельные действия - ☐ Каждое действие классифицировано по обратимости и влиянию - ☐ Для каждого действия выбрана модель согласования: блокирующая, постфактум или выборочная - ☐ Утверждающий определен в соответствии с существующими полномочиями в процессе - ☐ Экран принятия решения отображает действие, обоснование, источник и уровень уверенности - ☐ Существует возможность корректировки, а не только одобрения или отклонения - ☐ Причины отклонения документируются в коротком списке - ☐ Определены измеримые пороги для отмены согласования и условия возврата - ☐ Механизм отмены проверен практически, а не только запланирован ### Вопросы и ответы **Не сводит ли человеческое подтверждение на нет преимущества агента?** Не сводит, если оно применяется правильно. Агент по-прежнему экономит время на сбор информации, анализ и формулировку – а это большая часть работы. Человек принимает готовое решение и подтверждает его за секунды. Ценность исчезает только тогда, когда подтверждение требует от человека перепроверять все, что сделал агент. **Кто должен подтверждать – представитель или менеджер?** Как правило, тот, кто подтверждал бы это действие и без агента. Если представитель уполномочен начислять бонусы до определенной суммы, он является подтверждающим и в этом случае. Передача менеджеру требуется только тогда, когда сумма или чувствительность выходят за рамки обычной компетенции, иначе возникнет узкое место, которого раньше не было. **Как предотвратить автоматическое подтверждение без прочтения?** Тремя способами: представлять обоснование и источник, а не только результат; выборочно проверять часть подтверждений по факту; отслеживать время принятия решения. Серия подтверждений менее чем за две секунды – явный признак автоматического одобрения, требующий изменения дизайна экрана. **Когда можно удалить точку подтверждения?** Когда имеется достаточный объем задокументированных решений, доля корректировок со стороны утверждающего низка и стабильна в течение нескольких месяцев, и существует механизм быстрой отмены. Удаление осуществляется постепенно – сначала для узкого подмножества случаев, а не для всего процесса сразу. **Можно ли подтверждать постфактум, а не до выполнения?** Только когда действие обратимо дешево и быстро. Отправка черновика внутреннего электронного письма подходит для проверки постфактум; денежное возмещение или сообщение, отправленное клиенту, необратимы и требуют предварительного подтверждения, даже если это замедляет процесс. --- ## Внедрение Sales Cloud: Правильный процесс от лида до прогноза URL: https://hpi.pro/ru/insights/sales-cloud-implementation Внедрение Sales Cloud часто терпит неудачу не из-за неверных настроек, а из-за этапов продаж, между которыми никто не может точно определить переходы. Это руководство показывает, как построить единую цепочку — Лид, Возможность, Прогноз — где для каждого этапа есть измеримый критерий выхода, и почему это является условием для создания надежного прогноза. ## Краткий ответ Разница между успешным и провальным внедрением Sales Cloud практически всегда сводится к одному вопросу: можно ли одним предложением, без разногласий, объяснить, что именно переводит сделку из одной стадии в другую. Когда такой ответ есть, все остальное – экраны, поля, автоматизации и отчеты – выстраивается в соответствии с ним. При отсутствии ответа на этот вопрос вы получите хорошо настроенную систему, которая формирует прогноз, которому никто не доверяет. Поэтому порядок работы такой: сначала определение стадий продаж и критериев выхода, затем модель данных, разрешения, интеграции и, наконец, отчеты. Обратный подход – начинать с желаемого дашборда и двигаться в обратном направлении – приводит к созданию полей, которые заполняются ради работы отчета, а не ради эффективного ведения продаж. ## Где это ломается на практике В типичной B2B-организации до вмешательства картина выглядит так: 40% сделок в пайплайне с уже истекшей датой закрытия, стадия "Negotiation", включающая как первые переговоры, так и контракты на подписи, и руководитель отдела продаж, ведущий свой прогноз в отдельной таблице, потому что он не доверяет системе. Ни одна из этих проблем не является технической неисправностью – все они результат неопределенных настроек. ## Стадии продаж: критерий выхода для каждой стадии Простое правило: стадия определяется тем, что сделал покупатель, а не тем, что чувствует продавец. "Клиент заинтересован" не является критерием. "Определен лицо, принимающее решение, и выделен бюджет" – является. | Стадия | Измеримый критерий выхода | Отражение в системе | Вероятность | | --- | --- | --- | --- | | Qualification | Определены потребность, бюджет и лицо, принимающее решение | Поля "Бюджет" и "Лицо, принимающее решение" заполнены | 10% | | Discovery | Представлено и утверждено клиентом описание потребностей | Прикрепленный документ или заметка | 25% | | Proposal | Отправлено предложение с ценой и объемом работ | Активное ценовое предложение | 50% | | Negotiation | Получены коммерческие или юридические комментарии от клиента | Задокументированная активность за последние две недели | 75% | | Closed Won | Подписанный контракт или заказ на поставку | Прикрепленный файл | 100% | Вероятность — это не чувство представителя, а производная от стадии. Как только представителю разрешается вручную ее переопределять, прогноз снова становится субъективным. ## Lead против Opportunity: граница, определяющая качество пайплайна Самая распространенная ошибка – автоматическое преобразование каждого обращения в Opportunity, обычно для того, чтобы "пайплайн выглядел полным". Результатом является увеличение пайплайна в три раза и резкое падение процента закрытия, что делает любой исторический анализ бесполезным. Рабочее определение: лид остается лидом до тех пор, пока не будут выполнены три условия – определен контакт с полномочиями, потребность сформулирована словами клиента, и есть некий временной горизонт. Обращение, не соответствующее этим условиям, обрабатывается как лид в стадии взращивания (Nurture), а не как сделка. Это также позволяет реально измерять коэффициент конверсии между маркетингом и продажами вместо измерения "щедрости" конверсии. Тем, кто занимается построением базовой модели данных, будет полезно ознакомиться с [проектированием модели данных в Salesforce](/ru/insights/salesforce-data-model-design). ## Activities: требовать минимум там, где это важно Документирование активности — это точка, где внедрения теряют доверие представителей. Требование документировать каждое взаимодействие воспринимается как контроль, на него отвечают минимальной, бесполезной документацией, что приводит к худшим данным, чем отсутствие документации. Работающий подход заключается в требовании документирования только в трех случаях: при переходе между стадиями, при изменении суммы, превышающей установленный порог, и при отсрочке даты закрытия. В каждом из этих случаев документация служит и самому представителю – она объясняет решение, о котором его спросят на совещании. Автоматическая синхронизация электронной почты и календаря покрывает остальное без необходимости ввода данных вручную. ## Forecast: что должно быть готово до запуска Надежный прогноз требует четырех предварительных условий, и все они ведут себя как цепь – недостающее звено обнуляет остальные: 1. **Корректная иерархия пользователей** – прогноз в Salesforce строится в соответствии с иерархией ролей (Role Hierarchy), а не по организационной структуре в таблице. 2. **Чистые даты закрытия** – операционное правило, не позволяющее сделке оставаться с просроченной датой более недели. 3. **Определенные категории прогноза** – Pipeline, Best Case, Commit, Closed – с согласованным определением, кто и когда переводит сделку в категорию Commit. 4. **Регулярный цикл проверки** – еженедельное совещание по пайплайну, которое проводится на основе данных из системы, а не из параллельной таблицы. Последний пункт является решающим. Пока существует "теневая" таблица, представители знают, что система не является источником истины, и обновляют ее с опозданием. ## Что измерять после запуска | Показатель | Что он показывает | Проблемный порог | | --- | --- | --- | | Точность прогноза | Разрыв между прогнозом Commit и результатом | Отклонение более 20% за квартал | | Stage aging | Сделки, застрявшие на стадии | Более чем в 2 раза превышает медиану | | Обновление в течение 7 дней | Отражает ли система реальность | Менее 70% активных сделок | | Полнота данных | Обязательные поля на продвинутых стадиях | Менее 90% | Более глубокие показатели внедрения подробно описаны в разделе [Показатели внедрения Salesforce](/ru/insights/salesforce-adoption-metrics). ## Чего не стоит делать на первом этапе Сложное управление территориями (Territory Management), множественные модели прогнозирования, полноценный CPQ и автоматическое скоринг – все это возможности, которые следует добавлять после того, как базовый процесс стабилизировался и прошли два цикла продаж. Добавление их на первом этапе закрепляет еще не проверенные гипотезы и значительно удорожает любые будущие изменения. ## Заключение Внедрение Sales Cloud — это, прежде всего, работа по формированию бизнес-определений: когда сделка переходит на следующую стадию, когда обращение становится сделкой, и что именно требует документирования. Эти три решения определяют, станет ли прогноз управленческим инструментом или просто отчетной формальностью. Сам инструмент поддержит любое выбранное вами определение, включая неоптимальное. ### Вопросы и ответы **Сколько этапов возможностей следует определить?** Обычно от четырех до шести. Большее количество кажется точным, но создает этапы, которые никто не может различить, поэтому менеджеры обновляют их с опозданием или сразу перед собранием по воронке продаж. **В чем практическая разница между Лидом и Возможностью?** Лид – это еще не доказанный интерес, в то время как Возможность – это сделка с идентифицированным покупателем, определенной потребностью и временным горизонтом. Если конверсия происходит автоматически для каждого запроса, воронка продаж раздувается, а прогноз теряет смысл. **Обязательно ли требовать документирование активностей?** Всеобъемлющее требование приводит к формальному документированию, не имеющему ценности. Лучше требовать документирование в тех точках, где оно влияет на принятие решения – переход на новый этап, изменение суммы, перенос даты закрытия сделки. **Когда следует подключать CPQ или инструмент ценообразования?** Только после того, как этапы продаж и структура продуктов будут стабильны. Подключение ценообразования к процессу, который все еще изменяется, удваивает стоимость изменений и фиксирует временные допущения. **Сколько времени потребуется, чтобы прогноз стал надежным?** Обычно от двух до трех полных циклов продаж после запуска. До этого недостаточно сделок, управляемых новыми настройками, чтобы сравнивать прогноз с результатом. --- ## Внедрение Service Cloud: Обращения, SLA, Маршрутизация и База знаний URL: https://hpi.pro/ru/insights/service-cloud-implementation Многие контакт-центры внедряют Service Cloud, но не замечают улучшения времени ответа. Причина почти всегда кроется не в самом инструменте, а в нерешенности четырёх ключевых вопросов: что считать обращением, кто его обрабатывает, с какого момента отсчитывается время ответа и что делать, если ответ уже существует в базе. Это руководство подробно разбирает каждый из этих вопросов, предлагая конкретные решения. ## Краткий ответ Service Cloud сам по себе не сокращает время ответа. Он формирует производительность согласно заданным настройкам. Если не определено, что является обращением (Case), кто его принимает и с какого момента отсчитывается время, система будет точно измерять неопределенный процесс. Показатели при этом могут выглядеть лучше или хуже реального положения дел, независимо от фактического уровня обслуживания. Четыре ключевых решения определяют результат: определение обращения (Case), модель маршрутизации, расчет SLA и управление знаниями. Остальные аспекты внедрения — интерфейсы, каналы, автоматизации — являются их производными. ## Решение 1: Что считать обращением (Case) Многие контакт-центры открывают обращение (Case) для каждой интеракции, полагая, что это обеспечит сбор данных. Результат зачастую обратный: тысячи записей, закрываемых за минуту, увеличивают общий объем, искусственно улучшают среднее время решения и скрывают запросы, которые действительно требуют внимания. Эффективное определение должно различать три типа интеракций: | Тип интеракции | Открывается ли обращение (Case) | Причина | | --- | --- | --- | | Вопрос, отвеченный по телефону | Нет, регистрируется как взаимодействие (Interaction) | Отсутствует необходимость отслеживания и обязательств | | Запрос, требующий действия или ожидания | Да | Требуется отслеживание и SLA | | Повторяющаяся проблема | Да, с классификацией причины | Требуется анализ тенденции | ## Решение 2: Кто принимает запрос Часто встречающаяся ошибка — это маршрутизация запросов (Routing) исключительно по отделам. Это создает одну большую очередь, из которой сотрудники выбирают простые обращения. Сложные запросы при этом задерживаются в нижней части очереди, пока кто-то не эскалирует их по телефону. В результате весь механизм SLA становится формальностью. Корректная модель маршрутизации определяет три измерения: необходимые навыки, фактическая загрузка сотрудника (не количество обращений (Cases), а их вес) и правила эскалации на основе времени. Omni-Channel Routing поддерживает все три, но только при условии определения реальных навыков. Определение "Навык: поддержка" для всех сотрудников эквивалентно отсутствию определения. Подробное описание мультиканальной маршрутизации представлено в статье [Omnichannel и SLA в Service Cloud](/ru/insights/service-cloud-omnichannel-sla). ## Решение 3: Когда отсчитывается время Это решение чаще всего игнорируется организациями, но именно оно определяет достоверность показателей. Вопросы, требующие письменного ответа: 1. **Когда начинается отсчет времени** — в момент получения запроса или в начале следующих рабочих часов? Рабочие часы (Business Hours) должны быть настроены для каждого соответствующего часового пояса. 2. **Когда он останавливается** — обращение (Case), ожидающее ответа клиента, должно приостанавливать счетчик, иначе контакт-центр будет нести наказание за задержки по вине клиента. 3. **Что именно измеряется** — время первого ответа, время решения, или оба показателя с отдельными целями для каждого уровня срочности. 4. **Что происходит до превышения сроков** — этап (Milestone), генерирующий оповещение при достижении 80% времени, более ценен, чем ежемесячный отчет о превышениях. Сущности "Права" (Entitlements) и "Этапы" (Milestones) являются механизмом для реализации этих четырех пунктов. Их активация без предварительного письменного решения приводит к генерации оповещений, которые игнорируются уже через две недели. ## Решение 4: Где хранятся знания База знаний (Knowledge Base) — это не отдельный проект, а условие для снижения нагрузки. Типичная ошибка: статьи пишутся при запуске, никто их не поддерживает, и через полгода сотрудники снова начинают задавать вопросы во внутреннем чате. Эффективный подход: определенный жизненный цикл для каждой статьи — владелец (Owner), дата пересмотра и метрика использования. Обращение (Case), закрытое без привязанной статьи и появляющееся пять раз в одном квартале, является автоматическим триггером для создания статьи. Более глубокое рассмотрение темы представлено в статье [Управление знаниями в Salesforce](/ru/insights/salesforce-knowledge-management). ## Метрики операционной эффективности | Метрика | Определение | Порог для анализа | | --- | --- | --- | | Время первого ответа | До первого контакта с человеком | Превышение более 10% обращений | | Решение при первом контакте | Закрыто без перенаправления | Ниже 60% | | Частота повторных открытий | Обращение (Case), повторно открытое в течение 7 дней | Выше 8% | | Возраст просроченных запросов | Открытые обращения (Cases) с превышением SLA | Еженедельный рост | | Доля привязанных статей в базе знаний | Обращения (Cases) со связанной статьей | Ниже 30% | Показатель "Частота повторных открытий" является наиболее важным и часто игнорируемым: он выявляет преждевременные закрытия, производимые для соблюдения целевых сроков. ## Рекомендуемый порядок работы Первая волна: определение обращения (Case), один или два канала, базовая маршрутизация (Routing), SLA для одного уровня срочности и десять статей базы знаний для наиболее распространенных запросов. Вторая волна: дополнительные каналы, навыки, полные права (Entitlements), самообслуживание (Self-Service). Активация всего сразу создает контакт-центр, сталкивающийся с изменением процесса, инструментария и метрик в течение одной недели, что обычно приводит к возврату к обходным путям. ## Заключение Успешное внедрение Service Cloud измеряется одним вопросом: может ли руководитель контакт-центра на основании данных системы, без использования вспомогательных таблиц, показать, где находятся просроченные запросы и почему. Если четыре ключевых решения приняты, ответ существует. Если нет, результатом будет новая система, но тот же контакт-центр. ### Вопросы и ответы **Должно ли каждое обращение открываться как Case?** Нет. Вопрос, на который дан ответ в ходе разговора и который не требует последующего отслеживания, не является Case. Всеобъемлющее открытие обращений искажает данные и ухудшает показатели объема и решения. Практическое правило: Case открывается, когда требуется отслеживание, обязательство по срокам или документация для анализа. **Queue-based или Omni-Channel Routing?** Маршрутизация на основе очередей (Queue-based) подходит для небольших контакт-центров с многопрофильными операторами. Omni-Channel Routing необходима при наличии параллельных каналов, различных специализаций операторов или потребности в балансировке нагрузки в соответствии с фактической пропускной способностью. **Обязательно ли использовать Entitlements для управления SLA?** Можно измерять SLA только с помощью отчетов, однако Entitlements и Milestones позволяют активно предупреждать и эскалировать ситуации до нарушения сроков, а не только сообщать о них постфактум. **Когда стоит добавлять Портал или Self-Service?** После того как База знаний (Knowledge Base) будет содержать реальные ответы на наиболее частые запросы. Портал, который ведет к пустой базе, только увеличивает количество обращений по другим каналам. **Сколько типов обращений (Case) целесообразно определять?** Немного — обычно от трёх до пяти — с дополнительным полем классификации. Слишком детализированная таксономия приводит к тому, что операторы выбирают первый вариант в списке, и ценность аналитики теряется. --- ## Sales Cloud против Service Cloud: в чем разница и что нужно вашей организации? URL: https://hpi.pro/ru/insights/sales-cloud-vs-service-cloud Вопрос о том, какое облачное решение приобрести, часто подается как сравнение продуктов, но на самом деле это вопрос об организации рабочих процессов: управляете ли вы сделками с четким прогрессом или запросами, требующими быстрого реагирования. Это руководство разграничивает Sales Cloud и Service Cloud по объектам, метрикам и лицензированию, демонстрируя, когда необходимы оба решения и как интегрировать их без дублирования данных. ## Краткий ответ Sales Cloud управляет **развивающейся сделкой** — рабочей единицей, которая живет недели или месяцы, измеряется вероятностью закрытия и считается успешной, когда она закрыта. Service Cloud управляет **обращением, которое решается** — рабочей единицей, которая живет часы или дни, измеряется временем отклика и решения и считается успешной, когда она закрывается быстро и без повторного открытия. Именно это различие, а не список функций, определяет выбор. Если вы управляете воронкой продаж (Pipeline) — Sales Cloud. Если вы управляете очередью с SLA — Service Cloud. Если вы управляете клиентом, который и покупает, и жалуется — используйте обе системы на одном объекте Account. ## Различия в операционных терминах | Параметр | Sales Cloud | Service Cloud | |---|---|---| | Центральный объект | Opportunity | Case | | Жизненный цикл | От недель до месяцев | От часов до дней | | Ключевой показатель | Win rate, Forecast accuracy | First response, FCR, CSAT | | Механизм распределения | Персональное владение на длительный срок | Динамическая маршрутизация по доступности | | Источник нагрузки | Количество активных сделок | Непредсказуемые пики по каналам | | Компонент знаний | Playbooks и ценообразование | Встроенная база знаний | Самая важная строка — это механизм распределения. В продажах персональное владение является ценностью — клиент хочет иметь постоянного контактного менеджера. В обслуживании персональное владение является проблемой — оно создает индивидуальные очереди, которые застревают, когда представитель в отпуске. ## Когда выбор очевиден **Только Sales Cloud** подходит для организации, которая продает в непрерывном процессе и где послепродажная поддержка минимальна или осуществляется партнером — например, поставщик оборудования, продающий через дилеров и не имеющий собственного центра поддержки. **Только Service Cloud** подходит для организации, все взаимодействие которой с клиентом сводится к обработке запросов — операционная сервисная компания, государственное учреждение или поставщик инфраструктуры с действующими контрактами. **Обе системы** необходимы, когда есть продление, допродажи (Upsell) или удержание: как только сервисный представитель должен знать, что клиент находится в процессе продления, а представитель по продажам должен знать, что клиент открыл три серьезные проблемы в этом месяце — разделение становится препятствием. ## Как объединить без дублирования данных Именно в этом месте 통합 внедрения терпят неудачу. Правило: **Account и Contact — это один общий уровень**. Нет отдельных "клиентов по продажам" и "клиентов по обслуживанию". Отсюда вытекают три ключевых решения: 1. **Ответственность за записи клиентов** — кто обновляет контактные данные, адрес и организационную структуру. Обычно это служба поддержки, поскольку она чаще общается с клиентом. 2. **Взаимная видимость** — сервисный представитель видит открытые сделки только для чтения; представитель по продажам видит открытые проблемы и показатель удовлетворенности. Оба направления определяются моделью совместного доступа (Sharing Model), а не копированием полей. 3. **Кросс-функциональные триггеры** — критическая проблема у клиента, находящегося в процессе продления, генерирует оповещение для менеджера по работе с клиентами. Этот механизм ценнее любого комбинированного дашборда. Подробная информация о разрешениях и видимости представлена в [Модель Sharing и видимости в Salesforce](/ru/insights/salesforce-sharing-visibility-design). ## Лицензирование: что важно знать перед сравнением цен Лицензия Service Cloud является надмножественной — она включает базовые возможности Sales Cloud, поэтому пользователь, которому нужны обе системы, не нуждается в двух лицензиях. Обратное неверно: лицензия Sales не включает управление обращениями (Case management), права (Entitlements) или базу знаний (Knowledge). Практическое значение: правильный расчет стоимости начинается с сопоставления пользователей по тому, что они на самом деле делают, а не по отделу, к которому они принадлежат. Представитель, который дважды в год касается сделки, не является пользователем продаж. ## Порядок внедрения, когда нужны обе системы Параллельное внедрение кажется эффективным, но на самом деле удваивает риск: два процесса, которые изменяются одновременно, две группы пользователей на обучении, и невозможность отнести улучшение или сбой к конкретному источнику. Рекомендуемый порядок — начать со стороны с более измеримой проблемой — обычно это обслуживание, поскольку время отклика и отток измеряются уже сегодня — и добавить вторую сторону после двух месяцев стабильной работы. Общий уровень (Account, Contact, разрешения) строится на первом этапе, даже если только одна сторона запускается, иначе второй этап потребует перестройки. ## Заключение Вопрос не в том, какой продукт лучше, а в том, какой рабочий блок управляется организацией: развивающаяся сделка или решаемое обращение. Большинство зрелых организаций управляют обоими, и тогда настоящее решение заключается не в том, что купить, а в том, как поддерживать единый уровень клиента под обоими. ### Вопросы и ответы **Можно ли управлять запросами на обслуживание в Sales Cloud без Service Cloud?** Технически это возможно с помощью настраиваемого объекта или задачи. Однако при необходимости использования SLA, маршрутизации по доступности, базы знаний или работы с различными каналами связи, стоимость самостоятельной разработки такого функционала значительно превысит разницу в стоимости лицензий Service Cloud. **Необходимо ли использовать две отдельные организации (Org)?** Практически всегда нет. Оба облачных решения существуют в одной организации (Org), совместно используя объекты «Аккаунт» и «Контакт». Разделение на отдельные Org рассматривается только в случае строгих регуляторных требований или для полностью независимых компаний. **Что происходит с пользователем, которому требуются обе функции?** Пользователь с лицензией Service Cloud получает также базовые возможности Sales Cloud. Обратное неверно — лицензия Sales не включает полный функционал управления обращениями (Case management). **В чем разница в определении успеха между Sales Cloud и Service Cloud?** Продажи измеряются прогрессом и процентом закрытия сделок в течение нескольких недель; сервис измеряется временем ответа, разрешением проблемы при первом обращении и удовлетворенностью клиента в течение нескольких часов. Это различие в темпе влияет на частоту измерений, нагрузку автоматизации и планирование производительности. **С чего начать, если нужны оба решения?** Начните с того аспекта, где проблемы наиболее очевидны и измеримы. Параллельное внедрение обоих решений удваивает масштаб организационных изменений и затрудняет определение причин успеха или неудачи. --- ## Управление изменениями при внедрении Salesforce: план действий до и после запуска URL: https://hpi.pro/ru/insights/salesforce-change-management-plan Управление изменениями — это не просто неделя обучения перед запуском. Представляем четырехэтапный план действий: анализ воздействия, привлечение заинтересованных сторон, коммуникации и управленческий цикл, включающий конкретные результаты, ответственных лиц и метрики для каждого этапа. ## Краткий ответ Управление изменениями — это не коммуникационная активность, привязанная к завершению проекта. Это параллельный рабочий процесс, который начинается на этапе Discovery и заканчивается через несколько месяцев после Go Live. Разница между успешными и неудачными проектами почти всегда кроется здесь, а не в коде. Четыре этапа, каждый с определённым результатом: картирование воздействия, привлечение заинтересованных сторон, коммуникация и обучение, а также непрерывный управленческий цикл. ## Этап 1 — Картирование воздействия по ролям Прежде чем проектировать один экран, для каждой затронутой роли описывается: что она делает сегодня, что изменится, что станет проще, что станет сложнее и как по-другому будет измеряться её деятельность. Третья и четвёртая строки являются ключевыми — проекты терпят неудачу, когда кто-то обнаруживает только после запуска, что он потерял контроль или получил дополнительную работу. | Роль | Что меняется | Основной риск | Запланированный ответ | | --- | --- | --- | --- | | Представитель по продажам | Ввод данных в систему вместо личного Excel | Нагрузка по вводу, потеря контроля | Сокращённая форма, возвращаемое ежедневное значение | | Менеджер по продажам | Прогноз на основе системы | Обнаружение неутешительных цифр | Предварительная подготовка, индивидуальная панель управления на переходный период | | Back Office | Новый процесс утверждения | Задержки в переходный период | Предварительное обучение, процедура исключений | | Руководство | Единый источник истины для отчётности | Расхождения со старыми отчётами | Параллельное сравнение за один квартал | Результатом является документ объёмом от двух до четырёх страниц, который служит входными данными для планирования решения. ## Этап 2 — Заинтересованные стороны и спонсорство Настоящий спонсор — это тот, кто может изменить процесс, цель или вознаграждение. Спонсор, который появляется только в приветственном сообщении, не является спонсором. Три минимальных обязательства, которые следует получить в письменной форме: - Участие в ежемесячном обзоре проекта и в принятии открытых решений. - Чёткое заявление об источнике истины и о прекращении параллельной отчётности в определённую дату. - Поддержка изменения процесса, даже если это неудобно для определённого отдела. Наряду со спонсором строится сеть представителей на местах, которая функционирует как двусторонний канал — подробности в процессе создания [сети Чемпионов Salesforce](/ru/insights/salesforce-champions-network). ## Этап 3 — Коммуникация, понимаемая иначе, чем обычно Эффективная коммуникация отвечает на один вопрос пользователя: что это значит для меня. Сообщения, говорящие о «цифровой трансформации», воспринимаются как шум. Три принципа: 1. **Сегментация по ролям** — одно сообщение для всей организации не работает. Представителю по продажам сообщают, что меняется на его экране, менеджеру — что меняется в обзоре. 2. **Признание стоимости** — открыто говорить о том, что будет сложнее. Отрицание подрывает доверие быстрее, чем любой реальный недостаток. 3. **Постоянный темп** — короткое двухнедельное обновление от Discovery до Hypercare, даже если нет драматических новостей. Само обучение строится вокруг рабочих сценариев, а не вокруг экранов; рекомендуемая структура подробно описана в [обучении Salesforce по ролям](/ru/insights/salesforce-role-based-training). ## Этап 4 — Управленческий цикл после Go Live Это этап, который чаще всего упускают и который чаще всего оказывается решающим. Изменение закрепляется только тогда, когда оно входит в управленческую рутину: - Еженедельный обзор команды с панели управления в системе, а не из файла. - Ежемесячные отчёты руководству, формируемые исключительно из системы. - Открытый канал запросов с периодическим выпуском и информированием о том, что было исправлено. - Ежемесячное измерение внедрения в соответствии с [метриками внедрения Salesforce](/ru/insights/salesforce-adoption-metrics). Важной датой является не Go Live, а день, когда прекращается параллельная отчётность. Пока существует легитимный теневой отчёт, система остаётся второстепенной. ## Распространённые риски и ранние признаки предупреждения | Признак предупреждения | Значение | Реакция | | --- | --- | --- | | Спонсор пропускает два последовательных обзора | Отсутствие бизнес-владения | Поднятие вопроса перед руководством до UAT | | Накапливаются запросы «ещё одно поле» | Процесс не согласован | Заморозка и повторный анализ процесса | | Обучение отложено из-за сжатых сроков | Проект запустится без готовности | Отсрочка Go Live только для соответствующей команды | | Руководители запрашивают «также старый отчёт» | Отсутствие доверия к данным | Коррекция данных до расширения Scope | ## Метрики для плана изменений Измеряются четыре показателя: процент пользователей, завершивших обучение сценариям, частота выполнения ключевой операции в первые две недели, количество активных теневых файлов и среднее время закрытия запроса на изменение. Первые три свидетельствуют о принятии, четвёртый — о доверии к каналу. ## Заключение Хороший план управления изменениями начинается с картирования воздействия на этапе планирования, опирается на спонсора с реальными полномочиями, коммуницирует по ролям и продолжается как управленческий цикл через месяцы после Go Live. Это самая дешёвая часть проекта и самая влиятельная на его рентабельность. ### Вопросы и ответы **Когда следует начинать управление изменениями в проекте Salesforce?** Управление изменениями начинается на этапе Discovery, параллельно со сбором требований. Анализ воздействия системы на различные роли является важным входным параметром для планирования решения, а не его конечным результатом. Начало на этапе тестирования означает отставание примерно на три месяца. **Каков объем бюджета, выделяемого на управление изменениями?** Принятый диапазон составляет 10-15% от бюджета проекта для внедрений средней сложности, и более значительная доля, если изменяется организационная структура или система вознаграждения. В проектах, где эта сумма сокращается, затраты на восстановление возникают позднее. **Кто несет ответственность за управление изменениями — отдел кадров, PMO или команда CRM?** Конечная ответственность лежит на бизнес-спонсоре проекта. Отделы кадров или PMO предоставляют методологию и инструменты, команда CRM — содержание, но решения по изменению процессов и вознаграждений должны приниматься на уровне бизнеса. **Как справиться с сопротивлением руководителей среднего звена?** Руководители среднего звена сопротивляются в основном тогда, когда система создает прозрачность, которая им угрожает, или добавляет дополнительную работу. Решение заключается в предоставлении им немедленной управленческой ценности — например, дашбордов, которые заменяют ручное формирование отчетов. **Что происходит после этапа Hypercare?** После Hypercare продолжаются три ключевые активности: регулярный управленческий обзор из системы, открытый канал запросов с периодическими обновлениями и ежемесячное измерение уровня адаптации. Без этих элементов изменения могут быть нивелированы в течение двух кварталов. --- ## Обучение работе с Salesforce по ролям: как создать программу, которая формирует самостоятельность URL: https://hpi.pro/ru/insights/salesforce-role-based-training Обучение, фокусирующееся на интерфейсе, забывается через неделю. Представляем структуру программы обучения, основанной на сценариях: индивидуальный подход для каждой роли, практика на реальных данных в «песочнице», тесты на самостоятельность и непрерывное обучение для новых сотрудников. ## Краткий ответ Обучение, объясняющее расположение каждой кнопки, забывается к концу недели. Обучение, практикующее сценарии, которые пользователь действительно выполняет — «клиент звонит и просит предложение», «сделка застряла», «нужно закрыть обращение с возвратом» — остается, потому что оно связано с памятью о самой работе. Структура: отдельный путь для каждой роли, продолжительностью от двух до четырех часов, основанный на практических занятиях в «песочнице» с использованием знакомых данных и завершающийся практическим тестом на самостоятельность. ## Почему типовое обучение неэффективно Унифицированное обучение для всей организации охватывает общие аспекты, то есть в основном навигацию. Каждая роль усваивает 20% релевантного контента и 80% «шума», приходя на первый рабочий день без умения выполнять свои задачи от начала до конца. Результатом является обращение в службу поддержки по каждому действию или возврат к старым методам работы. Кроме того, типовое обучение скрывает проблемы интерфейса. Если для объяснения ввода коммерческого предложения требуется 40 минут, проблема не в обучении, а в экране — тема, обсуждаемая в статье [Упрощение UX в Salesforce](/ru/insights/salesforce-ux-simplification). ## Траектории обучения по ролям | Роль | Основные сценарии | Продолжительность | Тест на самостоятельность | | --- | --- | --- | --- | | Торговый представитель | От лида до сделки, продвижение по этапам, коммерческое предложение, документирование активностей | 3 часа | Полное завершение цикла сделки без помощи | | Руководитель отдела продаж | Обзор Pipeline, прогноз, утверждение исключений, анализ команды | 3 часа | Управление еженедельным обзором из системы | | Представитель службы поддержки | Открытие обращения, классификация, эскалация, закрытие с кодом причины | 3 часа | Обработка трех различных обращений в целевое время | | Back Office | Утверждения, корректировка данных, исключения | 2 часа | Обработка ежедневной очереди утверждений | | Руководство | Чтение дашбордов, вопросы по данным | 1 час | Принятие решений исключительно на основе данных системы | ## Эффективное построение сессии Распределение 20/60/20: двадцать процентов — контекст (почему изменилось и что это дает); шестьдесят процентов — практические занятия по сценариям; двадцать процентов — вопросы и работа с исключениями. Лекция без открытого ноутбука не является обучением. Практические занятия проводятся в «песочнице» с данными, которые выглядят как реальные для участников: знакомые имена клиентов, реальные суммы, подлинные продукты. Обобщенные фиктивные данные приводят к отстраненности и затрудняют переход к реальной работе. ## Тест на самостоятельность Программа обучения должна иметь измеряемый критерий завершения. Критерий — не посещаемость и не тест на знание, а выполнение: участник самостоятельно, в разумные сроки, без вопросов выполняет свой основной сценарий от начала до конца. Те, кто не прошел, получают дополнительное короткое практическое занятие, а не повторное полное обучение. Повторный провал многих на одном и том же этапе указывает на проблему в процессе или интерфейсе, и ее следует решить до запуска. ## Справочные материалы: краткие и ориентированные на задачи После обучения на самом деле требуется одномерный документ для каждой роли и библиотека видеоророликов продолжительностью от одной до трех минут по задачам. Два правила: поиск по вопросу («Как перевести сделку на следующий этап?»), а не по модулю, и назначенный владелец для обновления материала при каждом изменении системы. Руководство пользователя объемом 60 страниц пишется один раз, устаревает за два месяца и не читается. Не вкладывайте в него усилия. ## Поддержка в первые недели В течение двух недель после запуска требуется присутствие представителей на местах, которые знают, как помочь. Эта сеть — Чемпионы (Champions) — является операционным подразделением обучения, и ее построение подробно описано в [Сеть Чемпионов в Salesforce](/ru/insights/salesforce-champions-network). Все обучение является частью более широкой программы: [Управление изменениями Salesforce](/ru/insights/salesforce-change-management-plan). ## Новые пользователи после запуска В течение года значительная часть пользователей не присутствовала на первоначальном обучении. Без постоянного процесса адаптации вовлеченность постепенно снижается. Процесс адаптации включает: доступ к траектории для роли в течение двух недель после начала работы, сопровождение Чемпиона в команде и сам тест на самостоятельность. Это самое недорогое действие для поддержания вовлеченности на протяжении длительного времени. ## Измерение Были оценены три показателя: процент успешного прохождения теста на самостоятельность, объем обращений в службу поддержки в первый месяц по темам и процент выполнения основного действия в первые две недели в соответствии с [Метрики внедрения Salesforce](/ru/insights/salesforce-adoption-metrics). Концентрация обращений по одной теме почти всегда указывает на необходимость корректировки в системе, а не в обучении. ## Заключение Создайте траекторию для каждой роли на основе рабочих сценариев, проводите практические занятия в «песочнице» с использованием знакомых данных, завершайте практическим тестом на самостоятельность и поддерживайте траекторию адаптации для новых пользователей. Хорошее обучение не учит системе — оно учит, как выполнять работу в ней. ### Вопросы и ответы **Сколько часов обучения требуется конечному пользователю?** От двух до четырех часов на основные сценарии, разделенные на две короткие сессии вместо одной длинной. Руководителям потребуется дополнительный час на отчеты и обзоры. Большее количество часов приводит к забыванию, а не к усвоению знаний. **Что лучше: записанное видео или живое обучение?** Комбинация. Живое обучение для отработки центральных сценариев, так как оно позволяет задавать вопросы, и короткие видеоролики продолжительностью от одной до трех минут в качестве справочной библиотеки по задачам. Длинные видео продолжительностью 40 минут практически никто не смотрит. **Когда проводить обучение относительно запуска (Go-Live)?** За неделю-десять дней до запуска. Обучение за месяц до запуска забывается, обучение за день до запуска совпадает с пиковой нагрузкой. Сотрудники, присоединяющиеся после запуска, проходят тот же курс в течение двух недель с момента вступления в должность. **Как обучать, если система все еще меняется?** Заморозьте ключевые процессы за две недели до обучения и документируйте поздние изменения в виде короткого списка дельта-изменений. Обучение на постоянно меняющейся системе немедленно приводит к потере доверия. **Что делать с пользователями, не прошедшими обучение?** Блокировать доступ до завершения короткого курса обучения, при поддержке руководства. Пользователь, входящий в систему без обучения, создает ошибочные данные, за которые платят все. --- ## Показатели использования Salesforce: почему логины – это недостаточно URL: https://hpi.pro/ru/insights/salesforce-adoption-metrics Логин — это показатель присутствия, а не ценности. Практическое руководство по созданию набора показателей использования, который измеряет ключевые действия, качество данных и бизнес-результаты, включая базовые показатели, сегментацию по ролям и план действий для каждого вывода. ## Краткий ответ Вход в систему доказывает, что кто-то вошел в нее. Однако это не доказывает, что работа была выполнена внутри системы, что введенные данные достоверны или что руководитель может принимать решения на их основе. Организация, которая сообщает о 92% входов в систему и при этом управляет прогнозами в Excel, не внедрила Salesforce – она лишь открыла его. Полезный показатель внедрения отвечает на один вопрос: **протекает ли бизнес-процесс в системе от начала до конца, с качеством, позволяющим на него полагаться?** Из этого вытекают четыре уровня измерения: основные операции, качество данных, скорость процесса и бизнес-результат. ## Три уровня внедрения | Уровень | Что измеряется | Пример | Что это означает | | --- | --- | --- | --- | | Присутствие | Вход в систему, время пребывания | 92% вошли на этой неделе | Почти ничего | | Активное использование | Основные операции по роли | 78% сделок обновлены в течение 7 дней | Процесс запущен | | Ценность | Бизнес-результат + качество | Отклонение прогноза снизилось с 31% до 12% | Внедрение окупилось | Большинство организаций застряли на первом уровне, потому что он единственный доступен без усилий. Два последующих уровня требуют предварительного решения о том, что является "основной операцией" для каждой роли. ## Как определить основную операцию Основная операция — это действие, без которого процесс нарушается. Это не самое распространенное, а самое критически важное действие. Для торгового представителя это обычно обновление стадии сделки и даты закрытия; для руководителя отдела продаж это еженедельный обзор Pipeline внутри Salesforce; для сотрудника службы поддержки это закрытие кейса с правильным кодом причины. Практическое правило: если операция не выполнена, кто-то дальше по цепочке работает с неверной информацией. Если никто не пострадает от ее невыполнения — это не основная операция, и иногда она не должна быть обязательным полем. Для каждой роли определяют одну-две основные операции, четко указывают их в описании роли и измеряют долю пользователей, выполнивших их в соответствующем для процесса временном окне. ## Уровень качества данных Плохо выполненное действие иногда хуже невыполненного, потому что оно создает ложное доверие. Поэтому каждый количественный показатель должен иметь качественную пару: - Доля сделок с датой закрытия в прошлом — показатель устаревания Pipeline. - Доля кейсов, закрытых с общим кодом причины "другое" — показатель нарушенной категоризации. - Доля клиентов без активного контактного лица — показатель отсутствия базовых данных. - Доля дублирующихся вручную созданных записей — показатель сбоя в процессе ввода. Эти четыре показателя в течение недели показывают, используется ли система по-настоящему или формально. Подробнее об устранении первопричин см. в разделе [Улучшение внедрения Salesforce](/ru/insights/recover-salesforce-user-adoption). ## Сегментация: средняя величина обманчива Средний показатель внедрения в организации в 70% может скрывать команду с 95% и другую команду с 20%. Каждое измерение должно быть сегментировано как минимум по трем критериям: 1. **Роль** — представитель, руководитель, Back Office. У каждого свои ожидания. 2. **Команда или непосредственный руководитель** — наибольшая разница во внедрении почти всегда обусловлена непосредственным руководителем, а не обучением. 3. **Стаж работы с системой** — пользователи, присоединившиеся после Go Live, не проходили то же обучение, и их данные указывают на качество процесса адаптации. Когда разрыв между лучшей и отстающей командой превышает двукратный, проблема носит управленческий, а не системный характер, и правильные инвестиции следует направлять в управленческий уровень, а не в дальнейшее развитие. ## Базовый уровень: ошибка, которую нельзя исправить задним числом Показатель без точки отсчета — бессмысленное число. Базовый уровень измеряется до внесения изменений — даже если его измеряют вручную, даже если его оценивают. Спросите: сколько времени сегодня занимает закрытие кейса? Сколько сделок обновляется вовремя? Каково отклонение прогноза за последние три квартала? Если базовый уровень не был измерен до запуска, его можно частично восстановить из исторических данных, но поведенческие показатели восстановить невозможно. Вот почему измерение внедрения — это решение, принимаемое на этапе планирования, а не на этапе Go Live. ## От вывода к действию Следующая таблица сопоставляет распространенные выводы с правильными действиями. Логика такова: почти ни один вывод о внедрении не решается дополнительным обучением. | Вывод | Вероятная первопричина | Рекомендуемое действие | | --- | --- | --- | | Высокий процент входов в систему, низкий процент основных операций | Система не интегрирована в ежедневный рабочий процесс | Интеграция в процесс: оповещения, Path, рабочие списки | | Операции выполняются, но с задержкой в недели | Отсутствует управленческий цикл, основанный на данных | Еженедельный обзор Pipeline из Календаря | | Низкое качество в определенном поле | Поле нерелевантно или непонятно | Сократить, изменить на Picklist или удалить | | Отдельная команда отстает | Непосредственный руководитель не является пользователем | Работа с руководителем, а не с командой | | Все поля заполнены, но руководство не доверяет | Несоответствие показателя бизнес-вопросу | Переопределение показателя результата | ## Как это выглядит в ежемесячном отчете Хороший отчет о внедрении умещается на одной странице: четыре показателя с трехмесячной динамикой, сегментация по командам, три вывода и три действия с ответственным и сроком. Без действий это отчет о состоянии; с действиями — это инструмент управления. Связь между измерением и планом организационной работы подробно описана в [Управлении изменениями Salesforce](/ru/insights/salesforce-change-management-plan), а планирование обучения, исходящее из выводов, приведено в [Обучении Salesforce по ролям](/ru/insights/salesforce-role-based-training). ## Заключение Показатели внедрения — это не табель успеваемости для пользователей, а система обнаружения сбоев в процессе. Если измерение не приводит к изменению процесса, интерфейса или управленческого уровня, оно лишь создает дополнительную работу. Начните с четырех показателей, сегментируйте по командам, определите базовый уровень и свяжите каждый вывод с действием и ответственным. ### Вопросы и ответы **Сколько показателей использования необходимо отслеживать?** От четырех до шести. Один показатель ключевого действия для каждой основной роли, один показатель качества данных, один показатель скорости процесса и один показатель бизнес-результата. Большее количество создает приборную панель, которую никто не открывает. **Что делать, если данные показывают высокое использование, но руководство недовольно?** Почти всегда это означает, что вы измеряли активность, а не результат. Проверьте, действительно ли измеряемые действия влияют на бизнес-показатели — например, улучшает ли обновление этапа сделки точность прогноза, или просто заполняет поле. **Можно ли измерять использование без специализированного инструмента аналитики?** Да. Стандартных отчетов и дашбордов с типами отчетов по истории полей достаточно для большинства организаций. Внешний инструмент требуется в основном тогда, когда нужен анализ экрана и последовательности кликов на уровне пользователя. **Когда впервые измерять после запуска системы?** Через две недели после завершения периода гиперподдержки, не раньше. В первые недели показатели искажаются из-за тесной поддержки, исправлений данных и первоначального энтузиазма. **Как предотвратить превращение показателя в игру?** Каждый количественный показатель должен сопровождаться показателем качества. Если измеряется количество действий, наряду с ним измеряется доля действий со значимым содержанием или привязкой к возможности. Одиночный показатель всегда будет подвергаться искусственному давлению. --- ## 8 признаков, что ваша текущая система Salesforce нуждается в модернизации URL: https://hpi.pro/ru/insights/salesforce-system-upgrade-signs CRM-система почти всегда выходит из строя не сразу. Она изнашивается постепенно, и те, кто ежедневно работает с ней, перестают замечать проблемы. Восемь признаков, приведенных здесь, можно измерить без опросов и консультантов, и каждый из них указывает на первопричину: процесс, данные, архитектуру или управление. ## Краткий ответ Система нуждается в обновлении, когда работа вокруг нее превышает работу в ней. Приведенные ниже восемь признаков являются различными проявлениями одного и того же явления, но каждый из них указывает на разный корень, поэтому точная идентификация важнее количества. ## Восемь признаков | # | Признак | Что он выявляет | | --- | --- | --- | | 1 | Параллельные таблицы для управления прогнозами или очередями | Система не является источником достоверных данных | | 2 | Отчеты, показывающие противоречивые данные | Неунифицированные определения метрик или дублирование данных | | 3 | Каждый запрос на изменение занимает недели | Накопленный долг в автоматизациях, отсутствие надлежащей среды тестирования | | 4 | Экраны с десятками полей, которые никто не заполняет | Накопление требований без чистки | | 5 | Заметно медленная загрузка записей | Двойные Trigger'ы, каскадные Flows, неэффективные запросы | | 6 | Ежедневные повторяющиеся ручные операции | Процесс не был внедрен, только задокументирован | | 7 | Разрешения, выдаваемые «чтобы как-то работало» | Модель видимости, потерявшая логику | | 8 | Знания, которыми обладает только один человек | Отсутствие документации и управления | ## Как интерпретировать картину Признаки делятся на четыре семейства, и это определяет тип работы: **Процесс (1, 6)** – Система построена вокруг процесса, который не является реальным. Решение – перепроектирование, а не разработка. **Данные (2)** – Проблема в определениях и качестве, а не в инструментах отчетности. Подробнее см. в [Показатели качества данных](/ru/insights/salesforce-data-quality-metrics). **Архитектура (3, 5)** – Накопленный долг в автоматизациях и коде. Подробнее см. в [Оптимизация производительности](/ru/insights/salesforce-performance-optimization). **Управление (4, 7, 8)** – Нет ответственных за принятие решений о том, что включать, кто что видит и кто ведет документацию. Это семейство, игнорирование которого приводит к повторению всех остальных исправлений. ## Наиболее сильный признак Из восьми признаков параллельная таблица, используемая топ-менеджером для принятия решений, является наиболее недвусмысленным. Это не жалоба, а молчаливое заявление организации о том, что система недостаточна. Пока она существует, любое улучшение отчетов является работой над представлением, на которое никто не полагается. ## Что делать перед исправлением Искушение состоит в том, чтобы начать с самого громкого признака. Эффективный порядок иной: две недели измерения трех наиболее сильных признаков для получения базового уровня. Без него даже успешное исправление не сможет доказать свою эффективность, и финансирование следующей волны не будет одобрено. После измерения следует выбор между точечным исправлением и структурной работой, подробно описанный в статье [Перестроить или переработать](/ru/insights/salesforce-rebuild-vs-refactor). ## Заключение Признаки – это не список жалоб, а диагностический инструмент: каждый указывает на другое семейство первопричин, и устранение симптома из неправильного семейства приводит к потере целой волны усилий. Три активных признака оправдывают систематическую проверку; параллельная таблица в руководстве оправдывает ее сама по себе. ### Вопросы и ответы **Сколько признаков должны присутствовать для обоснования проверки?** Три из восьми, или один с высокой степенью выраженности, например, противоречивые отчеты руководства. Единичный слабый признак, как правило, является точечной, а не системной проблемой. **Всегда ли большое количество параллельных таблиц указывает на проблему в системе?** Почти всегда, но не обязательно техническую проблему. Таблица создается, когда система не поддерживает реальный процесс или когда она слишком медленная — это две разные причины с разными решениями. **В чем разница между модернизацией и текущим обслуживанием?** Обслуживание устраняет неисправности и точечные запросы. Модернизация изменяет структуру — модель, автоматизацию или разрешения — чтобы устранить причину, генерирующую запросы. **Можно ли выявить признаки без доступа к системе?** Да. Большинство из них можно наблюдать извне: продолжительность ручной встречи, количество файлов, отправляемых по электронной почте, время, необходимое для получения ответа на простой вопрос отчета. **Что делать после выявления проблем?** Измерять до внесения исправлений. Две недели сбора данных по трем наиболее выраженным признакам обеспечат базовый уровень, без которого невозможно доказать улучшение в дальнейшем. --- ## Стратегия использования Sandboxes и DevOps для Salesforce в вашей организации URL: https://hpi.pro/ru/insights/salesforce-sandbox-devops-strategy Путь изменений от разработки до Production определяет уверенность и безопасность выпуска обновлений. В этом руководстве мы подробно описываем типы Sandboxes, необходимые на каждом этапе, как построить Source-Driven пайплайн с Git и CI, а также что делать с ручной настройкой конфигурации в Production. ## Краткий ответ Эффективная стратегия управления средами разработки и тестирования отвечает на три ключевых вопроса: где выполняется каждый тип работы, как изменения продвигаются вперед и как вернуться к предыдущему состоянию в случае сбоя. Для большинства организаций оптимальна следующая структура: выделенная среда Developer для каждого разработчика, общая среда интеграции, среда UAT с репрезентативными данными и Production. Git должен быть единственным источником истины, а автоматическое развертывание должно быть настроено как минимум до UAT. ## Карта сред | Среда | Тип | Назначение | Данные | | --- | --- | --- | --- | | Индивидуальная разработка | Developer | Разработка, эксперименты, модульное тестирование | Только метаданные | | Интеграционная | Developer Pro | Объединение работы всей команды, CI | Небольшая синтезированная выборка | | UAT | Partial или Full | Бизнес-приемка, обучение, сценарии использования | Маскированные реальные данные | | Staging / Full | Full | Генеральная репетиция релиза, нагрузочное тестирование | Полная маскированная копия | | Production | — | Основная операционная деятельность | Реальные | Sandbox для Hotfix рекомендуется организациям, чей релизный цикл превышает две недели: без него каждое срочное исправление потребует развертывания еще не готовых изменений. ## От Change Sets к Source-Driven подходу Переход осуществляется в три этапа. Сначала экспортируются существующие метаданные в репозиторий (Repo) и устанавливается простая структура и стратегия ветвления: основная ветка (main), ветка релиза (release) и короткоживущие функциональные ветки (feature branches). Затем настраивается CI, который при каждом Pull Request запускает Validation Deploy в интеграционной среде, Apex-тесты и статический анализ. На третьем этапе подключается автоматическое развертывание в UAT, оставляя развертывание в Production в качестве ручной утвержденной операции с определенным окном релиза. На пути к Source-Driven подходу основным препятствием является не инструмент, а масштаб: попытка включить всю организацию в репозиторий сразу создает тысячи файлов, которые невозможно эффективно проанализировать. Лучше начать с подмножества метаданных одной бизнес-области и постепенно расширять охват. ## Что не входит в репозиторий Часть состояния системы не является развертываемыми метаданными: зависящие от среды записи настроек в Custom Settings и Custom Metadata, значения именованных учетных данных (Named Credentials), часто изменяющиеся правила назначения (Assignment Rules) и контент Базы знаний (Knowledge). Для каждой из этих категорий должен быть короткий документ, определяющий, кто, где и как обновляет и синхронизирует данные между средами. Отсутствие такого определения является наиболее распространенной причиной сбоев, проявляющихся только в Production. Взаимосвязь между скоростью выпуска и методологией работы подробно описана в статьях «[Гибридный Agile и Waterfall в Salesforce](/ru/insights/salesforce-agile-waterfall-hybrid)» и «[Руководство по внедрению Salesforce](/ru/insights/salesforce-implementation-guide)». ## Обновление сред и сопровождение Sandbox, который не обновлялся в течение девяти месяцев, больше не соответствует Production, и любое тестирование в нем дает ложное чувство безопасности. Простое правило: среда UAT обновляется перед каждым значительным релизом, среды разработки обновляются по завершении каждого спринта. Важно заранее спланировать, что будет потеряно при обновлении — тестовые данные, пользователи, настройки — и иметь скрипт Post-Refresh, который восстановит их в течение часа, а не трех дней. ## Распространенные риски и профилактические действия Первый риск — это Drift: расхождения, незаметно накапливающиеся между Production и репозиторием. Еженедельное автоматическое сравнение метаданных с оповещением — единственная действенная защита. Второй риск — это Apex-тесты, написанные только для достижения порогового значения покрытия. Покрытие в 75% без реальных утверждений (Assertions) не является защитной сеткой и создает ложное чувство безопасности именно в тот момент, когда требуется реальная уверенность. Третий риск — это человеческий фактор как узкое место: единственный человек, имеющий разрешение на развертывание. Необходимо иметь как минимум двух сотрудников с документированными правами. ## Как измерять успех Четыре показателя: частота релизов, время от слияния до Production, процент неудачных развертываний и количество Hotfix-исправлений в месяц после каждого релиза. Настоящее улучшение выглядит следующим образом: частота увеличивается, время сокращается, а процент сбоев и Hotfix-исправлений одновременно снижается. Увеличение частоты наряду с увеличением Hotfix-исправлений означает, что путь стал быстрее, но тестирование недостаточно. ### Вопросы и ответы **Сколько Sandboxes на самом деле требуется?** Практический минимум для средней организации: по одному Developer Sandbox для каждого разработчика, один Developer Pro для интеграции и один Full или Partial Sandbox для UAT (пользовательское приемочное тестирование) и нагрузочного тестирования. Небольшая организация может обойтись двумя; организациям с несколькими параллельными командами потребуется также выделенный Sandbox для экстренных исправлений (Hotfix). **Обязателен ли переход на Git и автоматическое развертывание?** Не в первый день, но обязательно до того, как метаданные начнут изменять более двух человек. До этого Change Sets достаточно. В противном случае, без единого источника истины в коде, невозможно отследить, кто и что изменил, и невозможно безопасно вернуться к предыдущей версии. **Что делать, если кто-то изменил что-то вручную в Production?** Выявите изменение путем еженедельного сравнения метаданных, зафиксируйте его в основной ветке как документированный Commit, и если оно нежелательно, отмените. Недопустимо, чтобы изменение существовало в Production, но отсутствовало в репозитории, так как следующий деплоймент перезапишет его. **Содержит ли Full Sandbox реальные данные, и что насчет регулирования?** Да, поэтому необходимо маскирование данных (Data Masking) перед предоставлением широкого доступа. В средах с персональной информацией маскирование или использование Partial Sandbox с репрезентативной выборкой являются правильным выбором, а не Full Sandbox с живой копией. **Сколько времени занимает настройка базового пайплайна DevOps?** От четырех до восьми недель: две недели на структуру репозитория и стратегию ветвления, две недели на CI и автоматическое тестирование, остальное — на адаптацию команды. Самая медленная часть — это всегда привычки, а не инструменты. --- ## Hypercare после Go Live в Salesforce: Как добиться стабильности без зависимости URL: https://hpi.pro/ru/insights/salesforce-hypercare-plan Hypercare – это не продолжение проекта, а стратегический мост к операционной деятельности (BAU). Структура периода стабилизации: состав команды, временные SLA, ежедневный триаж, измеримые критерии выхода и упорядоченная передача владения внутренней команде. ## Краткий ответ Период после запуска проекта (Go-Live) — это не его завершение, а этап, на котором проявляется реальная ценность созданного решения. Hypercare — это запланированный период, в течение которого команда, разработавшая систему, остается доступной для оперативного устранения недочетов и параллельной передачи ответственности команде сопровождения. Существуют две противоположные ошибки: отказ от данного периода, оставляющий пользователей без поддержки, или его бесконечное продление, создающее постоянную зависимость от поставщика. Обе ситуации предотвращаются благодаря заранее определенным критериям выхода. ## Отличия этого периода | Аспект | Hypercare | Штатная работа | | --- | --- | --- | | Канал связи | Прямой доступ к проектной команде + присутствие на месте | Стандартная очередь поддержки | | Время реакции на критическую ошибку | До одного часа | Согласно стандартному SLA | | Частота выпуска исправлений | Ежедневно или через день | Запланированный цикл | | Полномочия по принятию решений | Владелец процесса доступен ежедневно | Комитет по изменениям | | Фокус | Стабилизация и устранение ошибок | Улучшение и развитие | ## Ежедневный триаж — основа успеха Ежедневное 20-минутное совещание в фиксированное время с тремя вопросами: что было открыто вчера, что блокирует работу сейчас и что будет выпущено сегодня. Каждый запрос классифицируется по четырем категориям: 1. **Критическая ошибка** — невозможно выполнить бизнес-процесс. Немедленное устранение. 2. **Пробел в данных** — миграция или интеграция вернули некорректную информацию. Высокий приоритет, так как подрывает доверие. 3. **Недостаток обучения** — система работает штатно, но пользователь не обучен. Немедленный ответ и запись для корректировки учебных материалов. 4. **Запрос на улучшение** — в бэклог, без реализации в текущем периоде. Данная классификация является ключевым инструментом контроля объема работ: без нее каждый запрос кажется срочным, а период стабилизации превращается в очередной цикл разработки. ## Состав команды и присутствие на месте В течение первой недели необходимо тесное физическое или виртуальное присутствие в ключевых подразделениях. Специалисты проекта находятся рядом с пользователями, видят сбои в реальном времени и устраняют их в тот же день. Ценность непосредственного наблюдения значительно выше письменных отчетов — большинство серьезных проблем даже не регистрируются. Полевые представители, сопровождающие команду, являются частью сети Champions, поэтому они проходят предварительное обучение и получают прямой канал связи. Подробнее в [Сеть Champions в Salesforce](/ru/insights/salesforce-champions-network). ## Критерии выхода Выход из Hypercare — это измеримое решение. Общепринятый набор критериев: - Отсутствие открытых критических ошибок в течение пяти последовательных рабочих дней. - Снижение ежедневного объема запросов на 60% и более по сравнению с пиком первой недели. - Процент выполнения основных операций по ролям превышает установленный целевой показатель. - Три ключевых показателя качества данных находятся в согласованном диапазоне. - Внутренняя команда поддержки самостоятельно обработала 80% запросов за последнюю неделю. Последний критерий отличает реальную передачу ответственности от произвольного завершения работ в установленную дату. Измерения основаны на той же методологии, что описана в [Показателях внедрения Salesforce](/ru/insights/salesforce-adoption-metrics). ## Упорядоченная передача ответственности Передача начинается с первой недели, а не в последний день. Простой механизм: со второй недели внутренняя команда поддержки занимается запросами в первую очередь, а проектная команда оказывает поддержку из фонового режима. Каждый решенный запрос документируется в внутренней базе знаний в три строки — симптом, причина, решение. Результаты передачи: обновленный архитектурный документ, список интеграций с известными точками отказа, регламенты периодических процедур, перечень технических долгов, возникших под давлением, а также операционные доступы и разрешения. ## Зависимость от метода запуска При запуске по методу "Большого взрыва" (Big Bang) период Hypercare интенсивный и относительно короткий, с большой командой. При поэтапном запуске период повторяется с каждым этапом, но в меньшем объеме, и позволяет учиться от этапа к этапу. Это одно из соображений при выборе стратегии — см. [Big Bang или поэтапный Rollout](/ru/insights/salesforce-big-bang-vs-phased-rollout). ## Что учитывается еженедельно Ежедневный объем обращений по категориям, медианное время решения блокирующей ошибки, процент обращений, обработанных внутренней командой, и количество выявленных технических долгов. Первые три показателя измеряют стабилизацию; последний предотвращает создание "мин замедленного действия" в этот период. ## Заключение Планируйте Hypercare как отдельный этап с бюджетом, командой, ежедневным триажем и измеримыми критериями выхода. Классифицируйте каждое обращение, не внедряйте улучшения в этот период и постепенно передавайте ответственность, начиная со второй недели. Стабильная система — это не та, в которой нет сбоев, а та, которую организация способна исправлять самостоятельно. ### Вопросы и ответы **Как долго должен длиться период Hypercare?** От двух до четырех недель для среднего внедрения и от шести до восьми недель для многосайтового запуска или внедрения с масштабной миграцией данных. Продолжительность периода определяется критериями выхода, а не только датой. **В чем разница между Hypercare и постоянной поддержкой?** В период Hypercare команда, внедрившая систему, доступна напрямую, время отклика исключительно короткое, а исправления выпускаются практически немедленно. В режиме BAU запросы проходят через обычную очередь поддержки с запланированным циклом выпуска. **Кто должен входить в команду Hypercare?** Разработчик или администратор, знакомый с имплементацией; владелец бизнес-процесса, уполномоченный принимать решения по содержательным вопросам; представитель по миграции данных в течение первых двух недель; и координатор, управляющий ежедневным триажем. **Как предотвратить бесконечное затягивание этого периода?** Заранее определите количественные критерии выхода, опубликуйте их и еженедельно измеряйте. Кроме того, постепенно переводите запросы в обычную очередь поддержки, начиная со второй недели. **Что делать с запросами на улучшения во время Hypercare?** Записывайте их в бэклог, но не реализуйте. Hypercare предназначен только для устранения неполадок и блокирующих проблем; разработка улучшений в этот период подрывает стабильность, которую он призван обеспечить. --- ## User Stories и Backlog в проекте Salesforce: Руководство для владельцев процессов URL: https://hpi.pro/ru/insights/salesforce-user-stories-backlog Backlog проекта Salesforce почти всегда терпит неудачу по одной и той же причине: истории описывают экраны вместо результатов, а критерии приемки пишутся уже после разработки. В этом руководстве представлены тестируемая структура истории, метод декомпозиции с использованием Vertical Slice и приоритезация, которая сохраняет актуальность даже при возрастающем давлении. ## Краткий ответ Качественная пользовательская история в Salesforce описывает, **кто, что он пытается достичь и каков будет результат после действия**, а не какое поле появится на каком экране. Простая проверка: если критерии приемки можно сформулировать без знания того, будет ли реализация выполнена с помощью Flow, Validation Rule или Apex, история написана правильно. Распространенная ошибка — это история, которая уже содержит решение. Как только написано «Добавить поле Picklist на экран сделки», обсуждение процесса завершается, не успев начаться. ## Рабочая структура | Компонент | Роль | Критерий качества | | --- | --- | --- | | Контекст | Кто пользователь и когда он здесь | Реальная роль, а не «пользователь» | | Намерение | Что он пытается достичь | Сформулировано на языке бизнеса | | Критерии приемки | Что проверяется | Можно выполнить как сценарий с тестовыми данными | | Крайние случаи | Что намеренно не удалось | Хотя бы один отрицательный | | Вне Scope | Что явно не включено | Предотвращает споры при приемке | Последняя строка предотвращает большинство конфликтов. Явное заявление о том, что не включено, стоит больше, чем три абзаца описания. ## Декомпозиция: вертикальный срез, а не слои При реализации CRM-проекта возникает соблазн декомпозировать его по техническим компонентам — сначала модель данных, затем автоматизация, в конце отчеты. Результат: нечего показать до самого конца, и никто не знает, работает ли процесс. Правильная декомпозиция — вертикальная: один полный сквозной сценарий для одного профиля пользователя. Одна транзакция, которая открывается, развивается, закрывается и появляется в отчете, ценнее десяти определенных объектов без процесса. Далее добавляются профили и сценарии вокруг того же каркаса. ## Приоритизация, когда все срочно Трех критериев достаточно, в следующем порядке: 1. **Блокирует запуск?** — Без него процесс неполный. Места для переговоров нет. 2. **Сколько пользователей в день?** — Частота превосходит интенсивность жалобы. Элемент, затрагивающий 80 агентов ежедневно, имеет приоритет над запросом одного руководителя. 3. **Какова стоимость отсрочки?** — Увеличится ли стоимость реализации, если мы сделаем это после запуска? Изменение в модели данных — да, изменение в отчете — нет. То, что не проходит эти три критерия, отправляется в Parking Lot. Это разделение предотвращает превращение бэклога в архив желаний. Подробности об управлении изменением объема представлены в [Scope Creep и контроль изменений](/ru/insights/salesforce-scope-creep-change-control). ## Долг по требованиям: тихая ошибка Долг по требованиям возникает, когда user story завершается без решения о том, что происходит в крайнем случае — «разберемся с этим позже». После запуска такие крайние случаи составляют большинство обращений в службу поддержки. Простое решение: элемент не закрывается без документированного решения по каждому открытому вопросу, который в нем был зафиксирован, даже если решение — «намеренно не обрабатывать». Документирование отказа ценнее отсутствия документации. ## Связь с тестированием Правильно написанные критерии приемки — это, по сути, сценарии UAT. Когда они пишутся после разработки, UAT становится демонстрацией того, что было создано, а не проверкой того, что требовалось. Последовательность подробно описана в [руководстве UAT](/ru/insights/salesforce-uat-guide). ## Заключение Качественный бэклог не длинный, а понятный: каждый элемент указывает, для кого он предназначен, что будет считаться успехом и что явно не включено. Эти три вопроса, заданные до начала разработки, а не после, определяют практически все качество приемки в конце проекта. ### Вопросы и ответы **Насколько подробной должна быть история перед началом разработки?** Достаточно подробной, чтобы разработчик понимал, что нужно создать, а тестировщик знал, что проверять. Если критерии приемки нельзя выполнить как сценарий, история еще не готова, даже если она длинная. **Кто пишет критерии приемки?** Владелец процесса формулирует, что считать успехом, а тестировщик или архитектор добавляют пограничные случаи. Написание только разработчиком приводит к критериям, описывающим то, что было сделано, а не то, что требовалось. **Что делать с требованием, которое по сути является открытым вопросом?** Это не история, а Spike — ограниченная по времени задача по исследованию, результатом которой является документированное решение. Смешивание исследования и разработки в одном элементе скрывает риски в оценке. **Нужны ли Story Points в Salesforce?** Относительная оценка в основном помогает выявить разногласия по объему работ. Ценность не в точности числа, а в дискуссии, которая возникает при существенных расхождениях в оценках. **Как предотвратить разрастание Backlog до тысячи элементов?** Ограничьте глубину: то, что не рассматривается на ближайший квартал, перемещается на отдельную «парковку» (Parking Lot). Backlog, который никто не читает до конца, перестает быть инструментом приоритизации и становится архивом. --- ## Управление разрастанием объема работ (Scope Creep) в проектах Salesforce: как контролировать изменения без ущерба для проекта URL: https://hpi.pro/ru/insights/salesforce-scope-creep-change-control Разрастание объема работ (Scope Creep) возникает не из-за чрезмерного количества запросов, а из-за отсутствия механизма их своевременной оценки. Это руководство предлагает замороженную базовую линию, краткую форму запроса на изменение, еженедельный совет по изменениям и заранее выделенный бюджет на изменения — все это позволяет говорить «да», не рискуя сроками. ## Краткий ответ Расползание объема работ (Scope Creep) возникает, когда отсутствует очевидная разница между обещанным и реализованным. Эту проблему решают три механизма: задокументированный и общедоступный базовый план (Baseline), полустраничный бланк запроса на изменение с оценкой трудозатрат и правило замещения, согласно которому любое дополнение вытесняет что-то сравнимого размера или потребляет заранее выделенный бюджет на изменения. Без этих трех механизмов каждый «незначительный запрос» исчезает внутри спринта и обнаруживается лишь к дате завершения проекта. ## Почему это особенно актуально для Salesforce Salesforce достаточно гибка, чтобы почти любой запрос казался недорогим. Добавление поля занимает две минуты, поэтому трудно объяснить заинтересованному лицу, почему это невозможно. Однако поле влечет за собой валидацию, права доступа, колонку в отчете, маппинг при миграции, строку в обучении и тестирование в UAT. Фактическая стоимость в пять-десять раз превышает время на реализацию, и именно эта разница остается незамеченной при поступлении запроса. ## Рамки контроля из четырех компонентов | Компонент | Содержание | Ответственный | Результат | | ------------ | ------------------------------------------------------------- | ----------------------- | ---------------------------------------------- | | Зафиксированный базовый план | Список функциональных возможностей, сценарии и явные исключения (Out of Scope) | Владелец продукта | Подписанный документ по завершении Discovery | | Запрос на изменение (Change Request) | Описание, бизнес-обоснование, оценка трудозатрат, влияние на сроки | Инициатор + Технический лид | Полустраничный бланк | | Совет по изменениям | Еженедельное 30-минутное обсуждение всех открытых запросов | Спонсор, ВП, Технический лид | Решение: одобрено / отклонено / на следующий этап | | Бюджет на изменения | 10–20% от общего объема работ, выделяется в начале проекта | Спонсор | Еженедельный мониторинг остатка | ## Сила явного исключения (Out of Scope) Самым важным разделом в документе базового плана является не то, что включено, а то, что явно *не включено*. Фразы вроде «Интеграция с системой расчета заработной платы не включена в первый этап» или «Миграция данных до 2022 года не включена» экономят недели споров. Правило: все, что заинтересованное лицо может по ошибке посчитать включенным, должно быть указано в списке исключений под своим полным названием. ## Как сказать «да», не платя за это Безоговорочное отклонение приводит к проекту, который завершается в срок, но не используется никем. Эффективный подход — принимать каждый запрос в бэклог, прозрачно оценивать его стоимость и предоставлять заинтересованному лицу выбор: включить сейчас за счет другого пункта, отложить до следующего этапа или использовать бюджет на изменения. Когда выбор прозрачен, обсуждение переходит из эмоциональной плоскости в экономическую, и на практике около трети запросов отпадают, как только становится видна цена. Более подробная информация об определении базового плана доступна в статьях [Определение MVP Salesforce](/ru/insights/salesforce-mvp-scope) и [Discovery для CRM](/ru/insights/crm-discovery-guide). ## Распространенные риски и меры предотвращения Основной риск — слишком жесткий контроль. Процесс, требующий трех форм и двухнедельного ожидания, заставляет команды обходить его, и изменения продолжаются, но без документации. Полстраницы и еженедельное обсуждение — это практический потолок. Второй риск — техническое расползание: архитектурные решения, принимаемые внутри спринта и расширяющие объем работ без того, чтобы кто-либо называл это изменением. Поэтому любое значительное архитектурное изменение должно проходить через тот же совет. Третий риск — отсутствие спонсора: когда нет того, кто авторитетно скажет «нет», каждый запрос получает ответ «мы рассмотрим» — а это то же самое, что «да». ## Как измерять успех Еженедельно отслеживаются четыре показателя: количество открытых запросов, процент одобренных, накопленное изменение объема работ относительно базового плана и остаток бюджета на изменения. Здоровый проект демонстрирует накопленное изменение до 15% и положительный остаток бюджета на этапе UAT. Накопленное изменение более 30% — это признак того, что Discovery был слишком поверхностным, а не того, что команда недисциплинирована. ### Вопросы и ответы **В чем разница между разрастанием объема работ (Scope Creep) и обоснованными изменениями в процессе обучения (legitimate learning)?** Изменения в процессе обучения модифицируют решение, сохраняя при этом исходный бизнес-результат; разрастание объема работ добавляет новый результат, не изменяя сроки или бюджет. Практический тест: если запрос обусловлен тем, что было выявлено на этапе Discovery или UAT, — это обучение. Если он поступил от отдела, который присоединился позже, — это расширение. **Какой бюджет на изменения рекомендуется выделять заранее?** От 10% до 20% от общего бюджета, в зависимости от степени неопределенности. Проект с глубоким этапом Discovery и хорошо известными процессами может обойтись 10%; проект, затрагивающий несколько бизнес-подразделений или включающий миграцию из недокументированной системы, ближе к 20%. **Кто уполномочен одобрять изменения?** Владелец Продукта утверждает замены в рамках базовой линии без изменения сроков и стоимости. Спонсор утверждает любые изменения, влияющие на сроки, бюджет или результат. Четкая иерархия полномочий является наиболее эффективной защитой от «ползучих» изменений. **Что делать, когда поставщик заявляет: «Это не входило в наше предложение»?** Сверьтесь с SOW (Statement of Work) и документацией по Discovery. Если это действительно расширение, его следует оценить как изменение; если это пробел, возникший из-за нечеткого определения в предложении, это общая ответственность. Документирование допущений в контракте предотвращает подобные споры. **Отменяет ли Agile необходимость контроля изменений?** Нет. Agile позволяет легко заменять элементы в бэклоге, но бюджет и сроки по-прежнему остаются фиксированными. Контроль изменений в Agile — это «правило замены»: каждый добавленный элемент вытесняет элемент аналогичного размера. --- ## Agile, Waterfall или Hybrid в проекте Salesforce? Выбор модели реализации URL: https://hpi.pro/ru/insights/salesforce-agile-waterfall-hybrid Дискуссии о методологии в проекте Salesforce на самом деле почти всегда скрывают другие причины: сколько решений можно отложить и сколько времени действительно доступно для пользователей. В этом руководстве выбор модели реализации проекта анализируется на основе трех ключевых переменных, а также описывается гибридная модель, которую фактически применяет большинство организаций. ## Краткий ответ Выбор стоит не между двумя идеологиями, а между двумя типами решений. Существуют решения, стоимость изменения которых резко возрастает со временем — модель данных, разрешения, интеграции — и их необходимо фиксировать на ранней стадии. И есть решения, стоимость изменения которых низка — экраны, поля, отчеты, формулировки — и их предпочтительнее определять по ходу проекта. Отсюда следует, что модель, которая эффективно работает в большинстве проектов Salesforce, является гибридной не из компромисса, а из-за своей структуры: **фиксированная основа, итеративное содержание**. ## Три определяющих фактора | Фактор | Способствует раннему планированию | Способствует итерациям | |---|---|---| | Четкость процесса | Регламентированный и документированный процесс | Изменяющийся или несогласованный процесс | | Доступность пользователей | Низкая, ограниченное время | Высокая, возможность еженедельного обзора | | Регуляторное воздействие | Аудит, соответствие, одобрения | Минимальное | Второй фактор более решающий, чем принято считать. Agile без доступности пользователей — это не Agile; это серия спринтов, по окончании которых ничего не проверялось, и вся обратная связь поступает на UAT сразу. ## Гибридная структура на практике Эффективный подход разделяет проект на две части с разным темпом: **Этап формирования основы (4-6 недель, плановый)** – модель данных, модель разрешений и видимости, карта интеграций, стратегия миграции, а также определение процессов, которые войдут в первый этап. Результаты документируются и утверждаются. **Этапы поставки (двухнедельные спринты)** – каждый этап обеспечивает полный сценарий для профиля пользователя, включая тестирование и обратную связь. Изменения внутри этапа не требуют повторного утверждения, если они не затрагивают основу. Правило, которое поддерживает эту структуру: **изменение основы — это управляемое решение, изменение содержания — это текущая работа**. Без этого различия каждый мелкий запрос попадает в управляющий комитет, а каждое структурное изменение остается незамеченным. ## Где каждая модель дает сбой **Чистый Waterfall** дает сбой на этапе UAT: разрыв между тем, что было написано в документе полгода назад, и тем, что ожидает пользователь, обнаруживается слишком поздно для дешевых исправлений. **Чистый Agile** дает сбой в модели данных: после шести спринтов локальных решений обнаруживается, что структура не поддерживает межпроцессную отчетность, и исправление требует миграции. **Гибридная модель** дает сбой, когда основа не была по-настоящему завершена — когда она является "основой" только по названию, но открывается заново на каждом этапе. В этом случае получаются недостатки обеих моделей. ## Что измерять по ходу проекта Трех показателей достаточно, чтобы понять, работает ли модель: соотношение между завершенными и повторно открытыми элементами, время от получения обратной связи от пользователя до исправления, и количество изменений, затронувших основу. Рост третьего показателя является самым ранним признаком того, что раннее планирование было поверхностным. Связь с управлением объемом работ подробно описана в статье [Scope Creep и контроль изменений](/ru/insights/salesforce-scope-creep-change-control), а сроки – в статье [График проекта Salesforce](/ru/insights/salesforce-project-timeline). ## Заключение Верный вопрос не в том, какая методология более современна, а в том, какие решения в данном проекте дорого изменять на поздних этапах. Тот, кто умеет на него ответить, получает модель поставки почти автоматически — и почти всегда это гибридная модель с четкой границей между основой и содержанием. ### Вопросы и ответы **Можно ли реализовать истинный Agile, если бюджет утвержден заранее как фиксированная цена?** Можно, при условии, что в контракте фиксируются результаты, а не список элементов. Фиксированная цена в сочетании с открытым бэклогом создает внутреннюю напряженность, где каждое изменение становится предметом коммерческого, а не профессионального обсуждения. **Что остается в стиле Waterfall даже в гибком проекте?** Модель данных, архитектура разрешений и планирование интеграций. Изменения в этих трех областях слишком дороги на поздних этапах, поэтому решения по ним принимаются заранее, даже если все остальное итеративно. **Какова оптимальная продолжительность спринта для проекта Salesforce?** Две недели в большинстве случаев. Одной недели недостаточно для настройки, тестирования и получения обратной связи; три недели отодвигают обратную связь до того момента, когда исправление становится слишком дорогим. **Что делать, если пользователи недоступны для обзоров?** Сократите обзор до 30 минут и примите задокументированное решение: что не было рассмотрено в отведенное время, считается одобренным. Отсутствие доступности, которое не устраняется, впоследствии приводит к претензиям типа 'мы просили не это'. **Исключает ли регулирование Agile?** Нет. Оно требует документирования и утверждений в определенных точках, что совместимо с итерациями, если условие утверждения определено заранее и не добавляется посреди процесса. --- ## Big Bang или поэтапный Rollout при внедрении Salesforce? URL: https://hpi.pro/ru/insights/salesforce-big-bang-vs-phased-rollout Выбор определяется зависимостью данных и процессов, а не предпочтениями методологии. Структура выбора между единовременным запуском и поэтапным внедрением — включая стоимость сосуществования (Coexistence), риски миграции и таблицу решений по типу организации. ## Краткий ответ Дискуссия между стратегиями Big Bang и поэтапного внедрения часто представляется как вопрос риска, но в основном это вопрос зависимостей. Если два подразделения используют одну и ту же запись и один и тот же процесс, разделение их на разные этапы может создать дорогостоящий и подверженный ошибкам промежуточный период. Если подразделения независимы, нет причин запускать их все одновременно. Практическое правило: **сначала определите зависимости, затем выбирайте стратегию.** ## Краткий обзор двух подходов Запуск по стратегии Big Bang означает одновременное внедрение всех подразделений в одну дату. Преимущество — быстрое завершение, единый источник истины с первого дня и отсутствие затрат на промежуточный период. Недостаток — концентрация рисков: любая ошибка затрагивает всех в один момент, и восстановление усложняется. Поэтапное внедрение запускает одно подразделение или процесс на каждом этапе. Преимущество — обучение от этапа к этапу, ограниченный риск и развитие команды. Недостаток — более длительный проект, организационная усталость и продолжительный период сосуществования двух систем. ## Определение зависимостей — решающий тест | Вопрос | Ответ, ведущий к Big Bang | Ответ, ведущий к поэтапному внедрению | | --- | --- | --- | | Обрабатывается ли одна и та же запись двумя подразделениями? | Да, на постоянной основе | Нет, с явными затратами | | Проходит ли процесс между отделами? | Да, сквозной процесс | Отдельные процессы | | Объединяет ли управленческая отчетность все подразделения? | Да, ежедневно | Отчетность на уровне подразделения | | Возможна ли двусторонняя синхронизация с разумными затратами? | Нет | Да | | Используют ли подразделения общий каталог продуктов и ценообразование? | Да | Нет | Три и более ответов в левой колонке — разделение на этапы будет стоить дороже, чем сэкономит. ## Стоимость сосуществования (Coexistence) Этот пункт определяет многие решения, но тем не менее часто упускается при планировании. Промежуточный период включает: двустороннюю синхронизацию между Salesforce и старой системой, создание единой отчетности из двух источников, поддержку двух сред, двойное обучение для пользователей, работающих с обеими системами, и решение конфликтов при обновлении. Реалистичная оценка составляет от 10% до 25% бюджета проекта и увеличивается по мере увеличения периода. Если план включает год сосуществования, следует серьезно рассмотреть, стоит ли сокращение этого периода дополнительного риска более масштабного запуска. ## Риски миграции в каждом подходе При стратегии Big Bang миграция является единичным, крупным событием в коротком временном окне. Она требует полных повторных прогонов (Mock Cutover) и проверенного плана отката. При поэтапном внедрении миграция повторяется на каждом этапе, но в меньшем объеме — и каждый раз необходимо принимать решение о том, что происходит с записями, которые относятся к подразделениям, еще не запущенным. В обоих случаях качество данных является решающим фактором для дня запуска. Подробное планирование представлено в [Руководстве по внедрению Salesforce](/ru/insights/salesforce-implementation-guide). ## Матрица решений по типу организации | Контекст | Рекомендация | Основное обоснование | | --- | --- | --- | | До 150 пользователей, единый процесс | Big Bang | Стоимость сосуществования превышает риск | | Несколько офисов или стран | Поэтапно по офисам | Различия в регулировании и процессах | | Несколько отделов с общим процессом | Общее ядро, затем поэтапно | Предотвращает двустороннюю синхронизацию | | Жесткий срок окончания текущего контракта | Big Bang с ограниченным объемом | Нет времени на промежуточный период | | Организация без предыдущего опыта работы с Salesforce | Небольшой первый этап | Наращивание внутренних компетенций | | Сложная миграция из множества источников | Поэтапно | Распределение рисков данных | ## Гибридный подход, работающий на практике Большинство успешных крупных внедрений сочетают: единый базовый слой (Core) — модель данных, клиенты, разрешения, базовая отчетность — внедряется для всей организации одновременно; затем следуют этапы для уникальных процессов по подразделениям. Таким образом, избегается двусторонняя синхронизация общих данных, и при этом сохраняется постепенное обучение. Выбор минимального объема для первого этапа является самостоятельным решением и подробно описан в [Определении MVP в Salesforce](/ru/insights/salesforce-mvp-scope). В крупных организациях последствия более масштабны и обсуждаются в статье [Внедрение Salesforce в крупной организации](/ru/insights/enterprise-salesforce-implementation). ## Последствия для периода стабилизации Стратегия также определяет структуру Hypercare: при Big Bang требуется большая команда для интенсивного и короткого периода; при поэтапном внедрении требуется небольшая команда, которая возвращается на каждом этапе и накапливает знания. В обоих случаях требуются определенные критерии выхода, как подробно описано в [Hypercare после запуска](/ru/insights/salesforce-hypercare-plan). ## Заключение Определите зависимости между подразделениями, прежде чем обсуждать методологию, оцените стоимость периода сосуществования в цифрах и выбирайте в соответствии с контекстом: небольшая организация с единым процессом будет использовать Big Bang, многофилиальная организация — поэтапное внедрение, а большинство средних организаций выиграют от общего ядра и поэтапного внедрения поверх него. ### Вопросы и ответы **Что является решающим фактором при выборе между ними?** Степень взаимозависимости между подразделениями. Когда один процесс проходит через несколько отделов и одна и та же запись обрабатывается в обоих, разделение на этапы требует дорогостоящей двусторонней синхронизации и часто склоняет чашу весов в пользу Big Bang. **Сколько стоит период сосуществования (Coexistence)?** Обычно от 10% до 25% от бюджета проекта: двусторонняя синхронизация, дублирование отчетов, поддержка двух систем и путаница у пользователей. Этот пункт чаще всего недооценивается при принятии решения о поэтапном внедрении. **Должна ли первая волна охватывать самую большую команду?** Нет. Первая волна должна быть достаточно репрезентативной для получения ценных уроков, но достаточно небольшой, чтобы можно было исправить ошибки. Подразделение из 20–50 пользователей с полным циклом процессов — хороший выбор. **Когда Big Bang является правильным выбором?** Когда речь идет об организации до 150 пользователей, с унифицированными процессами, контролируемой миграцией и жестким сроком, обусловленным окончанием контракта на предыдущую систему. В таких условиях стоимость сосуществования превышает риск единовременного запуска. **Можно ли комбинировать подходы?** Да, и это наиболее распространенный выбор на практике: одновременный запуск основного функционала (Core) для всей организации, а затем поэтапное внедрение специализированных модулей и процессов по подразделениям. --- ## ROI проектов Salesforce: как определить и измерить истинную ценность URL: https://hpi.pro/ru/insights/salesforce-roi-kpis Большинство расчетов ROI для CRM-проектов составляются единожды, для презентации утверждения бюджета, и к ним никто не возвращается. Наше руководство предлагает иной подход: четыре типа ценности, измеряемые по-разному, базовые показатели, устанавливаемые до запуска, и правило атрибуции, исключающее приписывание системе всех бизнес-улучшений. ## Краткий ответ ROI проекта Salesforce – это не единая цифра, а четыре потока ценности, которые ведут себя по-разному: операционная эффективность, доходы, риски и стоимость систем. Сведение их к одной цифре создает утверждение, которое невозможно ни доказать, ни опровергнуть. Практическое правило: измеряется не более шести показателей, каждый из которых имеет базовое значение (Baseline), собранное до запуска, и ответственного, который отчитывается о значении показателя, но не является разработчиком системы. ## Четыре потока ценности | Поток ценности | Пример показателя | Срок измерений | Уровень достоверности | |---|---|---|---| | Операционная эффективность | Минуты обработки обращения, время создания предложения | Первый квартал | Высокий | | Доходы | Показатель Win Rate, средний размер сделки, продолжительность цикла продаж | 2-3 цикла продаж | Средний | | Риски и соответствие требованиям | Результаты аудита, уровень доступа по разрешениям | Ежегодно | Низкий количественно, высокий по влиянию | | Стоимость систем | Отмененные лицензии, удаленные интерфейсы | Немедленно после отключения | Очень высокий | Последний поток зачастую легче всего доказать и первым забывается. Отключение двух вспомогательных систем и одного интерфейса — это однозначная цифра в счете, не требующая допущений. ## Baseline: точка отсчета, определяющая возможность измерения Без предварительных измерений любая дискуссия после запуска превращается в спор о воспоминаниях. Корректный Baseline требует трех условий: письменное определение способа расчета показателя, источник данных, который останется доступным после перехода, и достаточно длительный временной интервал для охвата сезонных колебаний. Распространенная ошибка — измерять Baseline только на основе старой системы. Если 40% работы выполняется в электронных таблицах, измеренный Baseline будет лучше реального, а улучшение покажется меньшим, чем истинное. Лучше документированная ручная оценка, чем точные данные из неполного источника. ## Правило атрибуции После успешного запуска возникает соблазн приписать системе любое улучшение. Три фильтра ограничивают это: 1. **Фильтр причинности**: Существует ли объяснимый механизм, связывающий изменение в системе с изменением показателя? Если нет, это корреляция. 2. **Фильтр контрольной группы**: Показывает ли группа, которая еще не перешла на новую систему, ту же тенденцию? Если да, причина внешняя. 3. **Фильтр объема**: Увеличился ли показатель или увеличилась активность? Нормализация по объему устраняет большинство иллюзий. Тот, кто готов заявить: "Это улучшение не наше", завоевывает доверие, даже когда утверждает, что улучшение действительно принадлежит ему. ## Стороны затрат: что не учитывается при расчете Стоимость проекта — это не только цена контракта. Полный расчет включает лицензирование на три года, ежегодный процент на обслуживание и изменения (фактически 15-25% от стоимости внедрения), внутреннее время сотрудников на совещаниях, UAT и обучение, а также стоимость параллельного запуска в переходный период. Расчет, который обходит пункт обслуживания, показывает быстрый возврат инвестиций в первый год и убытки во второй. Подробная информация о структурах затрат представлена в [Стоимость внедрения Salesforce](/ru/insights/salesforce-implementation-cost). ## Что измерять в первом квартале В первом квартале измеримой бизнес-ценности еще нет, поэтому измеряются опережающие индикаторы, а не результаты: доля процессов, выполняемых в системе, а не вне ее, качество данных в полях, используемых для отчетов, и количество запросов на изменения, указывающих на пробелы в процессах. Все три предсказывают, будет ли достигнута ценность. Подробные показатели внедрения представлены в [Показатели внедрения Salesforce](/ru/insights/salesforce-adoption-metrics). ## Заключение Достоверный ROI строится на разделении между определенной ценностью (отключенные системы) и предполагаемой ценностью (доходы), на Baseline, собранном вовремя, и на готовности отказаться от атрибуции, не выдерживающей проверки. Скромная, но обоснованная модель ценнее громкого обещания, которое никто не будет перепроверять. ### Вопросы и ответы **Когда необходимо измерять базовые показатели?** До того, как новая система затронет процесс — обычно на этапе Discovery. Базовые показатели, собранные после запуска, уже искажены изменением поведения и не могут использоваться для сравнения. **Как отличить влияние системы от влияния рынка?** Тремя способами: сравнение с контрольной группой, которая пока не перешла на новую систему; нормализация по объему деятельности; и сосредоточение на процессных показателях (время цикла, частота повторных обращений), которые менее чувствительны к колебаниям спроса. **Является ли экономия времени сотрудника показателем ROI?** Только если высвободившееся время было использовано для измеримой деятельности или если это позволило избежать найма дополнительного персонала. Десять минут в день для сотрудника, который остается на той же должности и с той же производительностью, не являются экономией денежных средств. **Каков разумный срок окупаемости?** В проектах среднего масштаба процессные показатели меняются в течение одного квартала, показатели доходов — в течение двух-трех циклов продаж, а полная окупаемость денежных средств обычно измеряется за 18-30 месяцев, включая текущие эксплуатационные расходы. **Что входит в стоимость, что многие организации забывают?** Постоянные лицензионные платежи, обслуживание и изменения после запуска, внутреннее время сотрудников, задействованных в проекте и обучении, а также стоимость интеграций, которые продолжают требовать внимания. Игнорирование этих факторов создает ROI, который хорошо выглядит только на бумаге. --- ## Запрос предложений (RFP) на внедрение Salesforce: структура, вопросы и обязательные результаты URL: https://hpi.pro/ru/insights/salesforce-rfp-guide Запрос предложений, содержащий лишь список требований, породит лишь список обещаний. Хорошо составленный документ, напротив, описывает процессы, объемы работ и открытые вопросы, заставляя каждого поставщика продемонстрировать свой образ мышления. Мы предлагаем девятичастную структуру документа, вопросы, которые помогают выделить лучших поставщиков, и перечень результатов, которые следует требовать от любого предложения. ## Что должен содержать качественный запрос предложений (RFP) Цель RFP – не просто получить цену. Его задача — получить **сравнимые коммерческие предложения** и выявить, какой поставщик лучше всего понял проблему. Документ, перечисляющий сто требований и запрашивающий отметки «поддерживается / не поддерживается», достигает обратного эффекта: все поставщики отмечают «поддерживается», и в итоге решение сводится к цене. Практическое отличие: вместо того чтобы писать «Система должна поддерживать управление возможностями», опишите, что компания обрабатывает около четырехсот сделок в месяц, что каждая сделка проходит утверждение по ценообразованию, и что утверждение в настоящее время осуществляется по электронной почте. Поставщики предоставят совершенно разные ответы — и именно в этом суть. ## Девять разделов RFP для Salesforce **1. Контекст и бизнес-цель.** Чем занимается организация, в чем заключается проблема, и что будет считаться успехом через год. От абзаца до одной страницы. **2. Текущее состояние.** Используемые системы, количество пользователей, что работает, а что нет. Если существует среда Salesforce, укажите редакцию, срок использования и уровень кастомизации. **3. Ключевые процессы.** От трех до семи процессов, каждый в отдельном абзаце: кто выполняет, каковы точки принятия решений, что происходит в случае отклонений. **4. Объемы и данные.** Количество записей в каждой основной сущности, ежемесячная скорость создания, годы истории, которые необходимо сохранить, и известное состояние качества данных. Это наиболее важный раздел для точного ценообразования, который зачастую упускают из виду. **5. Интеграции.** Для каждой системы: название, тип интерфейса (если известен), направление, требуемая частота и ответственный в организации. **6. Ограничения.** Регулирование, информационная безопасность, место хранения данных, языки, доступность, неизменяемые сроки. **7. Требования к поставщику.** Предлагаемый подход, план этапов, состав команды с именами и ролями, допущения, риски и ценообразование согласно фиксированной структуре. **8. Метод оценки.** Критерии и их веса, опубликованные заранее. Это обеспечивает целенаправленные предложения и снижает количество споров после выбора победителя. **9. График тендера.** Срок для вопросов, срок для ответов, срок подачи предложений, срок демонстраций, срок принятия решения. ## Данные, которые необходимо раскрыть для получения реальной оценки | Данные | Почему это критично | Что происходит без них | | --- | --- | --- | | Количество пользователей по типу | Определяет лицензирование, обучение и разрешения | Предложения слишком широкого диапазона | | Объем записей и история | Определяет усилия по миграции | Миграция оценивается грубо | | Количество систем-источников | Определяет сложность и интеграцию | Неприятные сюрпризы после подписания | | Уровень существующей документации | Определяет объем требуемого анализа | Поставщики предполагают наличие документации | | Доступность владельцев процессов | Определяет скорость принятия решений | Нереалистичный график, согласованный обеими сторонами | | Бюджет или диапазон | Уточняет решение | Несравнимые предложения | ## Вопросы, которые позволяют отличить поставщиков Следующие вопросы вызывают совершенно разные ответы от разных поставщиков, поэтому они полезны. Вопрос, на который все отвечают одинаково, не стоит включать в документ. - Каковы три ключевых допущения, на которых основано предложение, и каковы последствия, если одно из них ошибочно? - В каких случаях вы бы порекомендовали конфигурацию, даже если разработка кажется более эффективной, и наоборот? - Опишите проект, в котором вы вышли за рамки графика. Что послужило причиной, и что вы изменили с тех пор? - Кто будут непосредственными членами команды, и какую долю времени каждый из них посвятит конкретно этому проекту? - Что вам нужно от нас для успеха, и что вы будете делать, если не получите это? - Как вы обеспечите нашу способность самостоятельно поддерживать систему? Последний вопрос является хорошей проверкой характера взаимодействия. Поставщик, который уклоняется от ответа, планирует создать зависимость. ## Что необходимо запросить в качестве результатов в предложении - **Предварительная архитектурная схема** на уровне блоков, включая источники истинности. - **План этапов** с описанием содержания каждого этапа, а не только дат. - **Детализированное ценообразование в единой структуре**, которую вы диктуете, по этапам и ролям. - **Явный список допущений.** - **Карта рисков** со способами их устранения. - **Пример реального результата** из предыдущего проекта, с анонимизированными именами — например, документ с решениями или план тестирования. Последний пункт, пожалуй, самый показательный, поскольку он демонстрирует стандарт работы, а не обещание. ## Единая структура ценообразования — инструмент, предотвращающий сравнение несравнимого Определите таблицу, которую должен заполнить каждый участник: | Этап | Часы старшего специалиста | Часы младшего специалиста | Стоимость | Что считается завершенным | | --- | --- | --- | --- | --- | | Анализ требований | | | | | | Конфигурация и разработка для этапа 1 | | | | | | Интеграции | | | | | | Миграция данных | | | | | | Тестирование и UAT | | | | | | Обучение и внедрение | | | | | | Стабилизация после запуска | | | | | | Управление проектом | | | | | Поставщик, отказывающийся разбить цену в соответствии с этой структурой, не обязательно дороже — но его невозможно сравнивать, и это достаточная причина, чтобы повторно запросить у него информацию. ## Пример для иллюстрации: средний пенсионный фонд Гипотетический сценарий предназначен для иллюстрации. Финансовая организация выпустила RFP, который включал восемьдесят функциональных требований в табличной форме. Четыре участника отметили «поддерживается» почти в каждой строке, и предложения различались только ценой и количеством часов. Во втором раунде документ был изменен: вместо таблицы требований были включены три полностью описанных процесса, реальные объемы данных и запрос на решение одного сценария в ходе демонстрации. Полученные предложения существенно отличались друг от друга — одно предлагало абсолютно иную модель данных, другое выявило зависимость от регуляторного одобрения, о котором никто не думал. Комиссия не выбрала самое дешевое предложение и не ошиблась. Она выбрала то, которое смогло объяснить, почему седьмое требование в исходном документе совершенно не нужно. ## Распространенные ошибки при составлении RFP - Копирование документа из другого проекта без адаптации объемов и процессов. - Требование списка клиентов вместо примеров результатов. - Критерии оценки, сформулированные после получения предложений. - График, не оставляющий времени для вопросов и ответов. - Скрытое предпочтение существующему поставщику, что вынуждает других тратить ресурсы впустую и негативно влияет на качество будущих предложений. ## Что происходит после подачи Хороший документ — это только половина работы. Следующий шаг — нормализация предложений и их сравнение на единой основе, как описано в [руководстве по сравнению предложений Salesforce](/ru/insights/compare-salesforce-proposals), а затем структурированная оценка по заранее определенным весам, как изложено в [руководстве по оценочной карте для выбора поставщика](/ru/insights/salesforce-vendor-scorecard). Информационная база для составления самого документа часто формируется в процессе краткосрочного консультирования, как описано в [руководстве по консалтингу Salesforce](/ru/insights/salesforce-consulting-guide), а критерии для проверки компании собраны в [руководстве по выбору компании-интегратора](/ru/insights/choose-salesforce-implementation-company). ## Следующий шаг Прежде чем отправить документ, проведите одну проверку: дайте его прочитать кому-то в вашей организации, кто не участвует в проекте, и попросите его одним предложением объяснить, какую проблему вы пытаетесь решить. Если он не сможет, то и поставщики не смогут — а они просто вернут то, что они привыкли продавать. ### Вопросы и ответы **Сколько поставщиков следует приглашать для участия в RFP на внедрение Salesforce?** От трех до пяти. Менее трех не даст достаточной основы для сравнения, а более пяти создаст чрезмерную нагрузку на оценку, вынуждая комитет принимать решения на основе цены, а не содержания. Если достойных кандидатов больше, лучше провести короткий предварительный отбор на основе краткой анкеты перед отправкой полного документа. **Нужно ли раскрывать бюджет в RFP?** Лучше раскрыть диапазон или верхний предел бюджета. Это предотвратит получение нерелевантных предложений и позволит поставщикам планировать внедрение поэтапно в рамках выделенных средств. Нераскрытие, как правило, приводит к тому, что поставщики оценивают проект по тому, что, по их предположению, вы одобрите, а не по тому, что реально необходимо для решения задачи. **Что делать, если поставщики задают вопросы, выявляющие пробелы в документе?** Опубликуйте все вопросы и ответы для всех участников одновременно и при необходимости обновите документ. Хороший вопрос от поставщика – это его позитивная характеристика, поэтому стоит фиксировать, кто что спросил – это является одним из лучших показателей глубины его понимания. **Следует ли требовать живую демонстрацию в рамках RFP?** Да, но не демонстрацию продукта. Попросите участника решить короткий сценарий из вашей реальной практики и объяснить его логику реализации. Стандартная демонстрация продукта показывает, что умеет Salesforce, и эта информация не отличает одного поставщика от другого; решение сценария демонстрирует образ мышления поставщика. **Сколько времени давать поставщикам на подачу предложения?** Три-четыре недели для проекта среднего масштаба, включая раунд вопросов и ответов в середине процесса. Слишком короткий срок приведет к получению типовых предложений, а это именно то, что вы пытаетесь отсеять. Если сроки поджимают, лучше сократить объем информации, требуемой в предложении, а не время на его подготовку. --- ## Как сравнить коммерческие предложения по проекту Salesforce, не попавшись на низкую цену URL: https://hpi.pro/ru/insights/compare-salesforce-proposals Предложение, которое на 30% дешевле, почти всегда является ДРУГИМ предложением, а не ЛУЧШИМ. Правильное сравнение начинается с нормализации: одинаковый объем работ, одинаковый гарантийный период, идентичные скрытые компоненты. Здесь — метод нормализации из шести шагов, карта скрытых затрат, не указанных в предложении, и модель сравнения трехлетней стоимости владения (TCO). ## Почему предложения Salesforce почти никогда не поддаются прямому сравнению Когда три коммерческих предложения лежат рядом, и вы видите разницу в десятки процентов, инстинкт подсказывает, что одно из них завышено. В большинстве случаев причина проще: каждое предложение оценивает свой, уникальный проект. Один поставщик включил миграцию данных за три года, другой — только за один. Один предусмотрел шесть недель стабилизации после запуска, другой сдал проект и завершил работу. Один учел четыре интеграции, другой — две, предполагая, что ежедневный отчет заменит живой интерфейс. Никто из них не вводил в заблуждение — им просто не предоставили точных инструкций. Следовательно, сравнение начинается с нормализации, а не с таблицы цен. ## Шестиступенчатый метод нормализации **1. Определите единый список компонентов.** Одиннадцати строк достаточно: анализ требований, настройка, разработка, интеграции, миграция, тестирование, обучение, управление проектом, стабилизация, документирование, передача знаний. **2. Отметьте для каждого предложения, что включено, что частично включено, а что отсутствует.** Пока не указывайте суммы. **3. Оцените отсутствующие компоненты.** Для каждого компонента, не включенного в предложение, используйте стоимость из другого предложения в качестве оценки и добавьте ее. **4. Унифицируйте допущения.** Количество пользователей, редакция системы, количество лет истории, количество бизнес-подразделений, языки. **5. Унифицируйте период гарантии.** Различные сроки стоят денег. Разница в два месяца стабилизации — это реальный стоимостной компонент. **6. Рассчитайте среднюю почасовую ставку и состав команды** на каждом этапе, а не общий показатель. Только после этих шести шагов можно сравнивать цифры. Во многих случаях предложение, которое казалось дешевым, перемещается на второе место. ## Компоненты, которые исчезают из предложений — и появляются в счете | Компонент | Почему пропущен | Относительный порядок величины | | --- | --- | --- | | Очистка данных перед миграцией | Считается ответственностью клиента | Иногда очень значительная | | Второй раунд UAT | Предполагается один раунд | Низкий, но блокирует сроки | | Обучение по ролям | Оценивается как один семинар | Средний | | Усиленная поддержка в первые недели | Не определено | От среднего до высокого | | Документация в собственности организации | Считается само собой разумеющимся | Низкий, критически важен в дальнейшем | | Обработка ошибок интеграции и мониторинг | Включается только "правильный путь" | Средний | | Среды и DevOps | Предполагается наличие | От низкого до среднего | | Часы внутреннего управления организации | Вообще не включены в предложение | Высокий, и всегда присутствует | Именно последняя строка удивляет руководство. Проект Salesforce требует значительного времени от владельцев процессов и PMO, и это реальная стоимость, даже если она не отображается ни в одном счете. ## От сравнения цен к трехлетней оценке стоимости Предложение правильно оценивается на трехлетний период, а не только на продолжительность проекта. Простая структура расчета: | Компонент | Год 1 | Год 2 | Год 3 | | --- | --- | --- | --- | | Стоимость внедрения | Полная | — | — | | Лицензии | По количеству пользователей | Включая ожидаемый рост | Включая ожидаемый рост | | Техническое обслуживание и поддержка | Частичная | Полная | Полная | | Планируемые улучшения | — | Оценочный объем | Оценочный объем | | Стоимость внутреннего управления | Высокая | Средняя | Средняя | Разница между предложениями в первый год кажется значительной. В течение трех лет обычно решающим фактором является легкость модификации системы без участия поставщика — то есть качество документации и передачи знаний, которые почти никогда не учитываются при принятии решения. ## Красные флаги в предложении - Миграция данных оценивается круглой суммой без вопросов об объеме или качестве. - Отсутствует гарантийный период, или он определен как "устранение ошибок" без определения, что такое ошибка. - Предложение включает только часы разработки и не содержит строки "управление проектом". - Состав команды без указания имен, или имена, не закрепленные в контракте. - Исключительно низкая цена для этапа анализа требований, который иногда является входной дверью для проекта, который будет оценен позже. - Отсутствие явных допущений. Предложение без допущений — это не проверенное предложение. ## Пример для наглядности: компания по возобновляемой энергии Сценарий гипотетический и предназначен для иллюстрации. Компания получила три предложения. Разница между самым дешевым и самым дорогим составила около восьмидесяти процентов. Комитет склонялся к дешевому. После нормализации выяснилось: самое дешевое предложение вообще не включало миграцию, а только загрузку активных записей; оно предполагало две интеграции вместо четырех, так как считало, что финансовая отчетность будет выполняться ручным экспортом; и гарантийный период составлял две недели по сравнению с восьмью неделями в дорогом предложении. После восполнения пробелов за счет стоимости других поставщиков разрыв сократился примерно до десяти процентов. Окончательное решение было основано не на цене, а на вопросе, кто предлагает структурированную передачу знаний, поскольку у компании не было внутренней команды. ## Что делать с оставшимся разрывом После нормализации обычно остается реальный разрыв. Превратите его в вопросы, а не в допущения: - Почему ваша оценка интеграции ниже, чем у других — что вы знаете, чего они не знают? - Что произойдет, если предположение о качестве данных ошибочно? - Сколько раундов тестирования вы запланировали? - Кто из представленной команды будет сопровождать проект от начала до конца? Ответы на эти вопросы отличают поставщика, который оценил проект дешево, потому что он эффективен, от поставщика, который оценил его дешево, потому что не понял. ## Связь с окончательным решением Систематическое сравнение представляет только коммерческую сторону. Профессиональная сторона оценивается отдельно, согласно заранее установленным весам, и цена является лишь одним из них — подробности в [руководстве по выбору компании-интегратора Salesforce](/ru/insights/choose-salesforce-implementation-company). Понимание того, что составляет изначальную стоимость, подробно описано в [руководстве по стоимости внедрения Salesforce](/ru/insights/salesforce-implementation-cost), а выбор модели взаимодействия — в [руководстве по ценообразованию проекта](/ru/insights/salesforce-project-pricing-models). То, что было согласовано при сравнении, должно быть включено в контракт в точной формулировке, иначе оно не существует — соответствующие пункты собраны в [руководстве по контракту и Statement of Work (SOW) Salesforce](/ru/insights/salesforce-sow-contract-clauses). ## Следующий шаг Составьте таблицу нормализации до того, как вскроете ценовые предложения. Тот, кто составляет ее после ознакомления с суммами, невольно делает это таким образом, чтобы оправдать уже понравившееся ему предложение. ### Вопросы и ответы **Разница в 40% между предложениями по Salesforce — что это обычно означает?** Почти всегда это означает, что предложения относятся к РАЗНОМУ объему работ, а не то, что один поставщик в полтора раза эффективнее. Типичные различия включают данные для миграции (были или не были включены), количество учитываемых интеграций, период стабилизации после запуска и обучение. Перед началом переговоров о цене убедитесь, что эти три аспекта одинаково определены во всех предложениях. **Как сравнивать предложения с разным составом команды?** Рассчитайте среднюю почасовую ставку и оцените соотношение старших/младших специалистов на каждом этапе. Предложение с низкой почасовой ставкой и полностью младшим составом может потребовать больше часов для выполнения того же объема работы. Важно, кто фактически будет руководить архитектурными решениями и какой процент своего времени он будет уделять проекту. **Стоит ли просить поставщиков пересмотреть предложение после сравнения?** Да, один раунд уточнений — это нормальная и полезная практика. Отправьте каждому участнику тендера только те расхождения в объеме, которые вы обнаружили ИМЕННО в его предложении, не раскрывая цены других, и запросите обновленное предложение в той же структуре. Такой раунд обычно значительно сокращает разрыв между предложениями и выявляет, кто действительно понял проект. **Что делать, если самое дешевое предложение поступило от менее сильного поставщика?** Переведите этот разрыв в деньги, а не обсуждайте его как 'ощущение'. Реалистичная оценка стоимости дополнительного этапа доработок, задержек в графике и дополнительных часов внутреннего управления даст число, с которым можно сравнивать. Обычно коммерческий разрыв значительно сокращается после такой конвертации. **Входит ли стоимость лицензирования Salesforce в предложение интегратора?** Обычно нет, лицензии приобретаются отдельно. Важно убедиться, что все поставщики предполагали одну и ту же редакцию и то же количество пользователей, поскольку разные предположения меняют и объем работы: функциональность, доступная в старшей редакции, может потребовать разработки в младшей. --- ## Договор и SOW для проекта Salesforce: пункты, защищающие качество реализации URL: https://hpi.pro/ru/insights/salesforce-sow-contract-clauses Большинство разногласий в проектах Salesforce возникают не из-за цены, а из-за вопроса о том, что считать завершенным. Качественный SOW определяет критерии приемки, двусторонние зависимости, права собственности на результаты и порядок расторжения. Ниже представлены двенадцать ключевых пунктов с рекомендованными формулировками и пояснениями относительно их практического значения. ## Что на самом деле разрушает проекты Salesforce с юридической точки зрения Практически любой конфликт в проекте Salesforce начинается не с вопроса "сколько это стоит", а с вопроса "завершено ли это". Поставщик считает, что результат передан, а организация полагает, что он непригоден для использования. Обе стороны правы в своем понимании, поскольку никто заранее не определил, что будет считаться завершенным. Из этого вытекает один принцип, которым руководствуются все пункты данной статьи: **хороший контракт не защищает вашу сторону в конфликте, он предотвращает конфликт.** ## Двенадцать ключевых пунктов ### 1. Определение приемки для каждого результата Это самый важный пункт. Для каждого результата необходимы наблюдаемые критерии: не "экран управления клиентами", а "пользователь с профилем X может выполнить сценарий Y и получить результат Z, как определено в утвержденных критериях приемки". Рекомендуемая формулировка: Определенный период тестирования, начинающийся с момента поставки, по истечении которого клиент либо утверждает результат, либо письменно указывает на выявленные недостатки. Молчание по истечении этого периода считается утверждением — это пункт, который защищает поставщика и дисциплинирует клиента. ### 2. Механизм запросов на изменение Определяет, кто имеет право запрашивать изменения, кто их оценивает, в какие сроки и по какому тарифу. Тариф должен быть установлен при подписании контракта, а не в момент возникновения необходимости. ### 3. Двусторонняя зависимость Большинство контрактов определяют, что происходит, когда поставщик задерживается, но не определяют, что происходит, когда задерживается клиент. В результате, когда организация опаздывает с утверждением, поставщик несет издержки, а затем перекладывает их через запросы на изменение. Сбалансированная формулировка: График проекта зависит от определенной реакции клиента (время на утверждение, доступность владельца процесса, предоставление данных) и превышение сроков сдвигает веху после письменного уведомления. ### 4. Право собственности на код, конфигурацию и документацию Разделение между специализированным продуктом и общими компонентами поставщика, с бессрочной лицензией на использование общих компонентов, не зависящей от продолжения сотрудничества. ### 5. Документация как обязательный результат Документация, которая не определена как результат с критериями приемки, либо не будет написана, либо будет написана в последнюю неделю. Определите минимум: архитектурные решения, модель данных, сопоставление интеграций, операционные процедуры. ### 6. Гарантия и исправление дефектов Определенный период и четкое разграничение дефекта и изменения. Рабочее определение: расхождение между фактическим поведением и утвержденными критериями приемки является дефектом. ### 7. Ключевые специалисты Имена, процент выделения ресурсов, предварительное уведомление о замене и эквивалентный профессиональный уровень с одобрения клиента. ### 8. Доступы, среды и информационная безопасность Кто получает доступ к каким средам, на какой срок, что происходит с доступами по завершении, и как обрабатываются реальные данные в непроизводственных средах. ### 9. Соответствие нормативным требованиям и конфиденциальность Место хранения, обработка персональных данных, право на проверку и отчетность об инцидентах безопасности. В регулируемых организациях этот пункт требует индивидуальной формулировки, а не шаблона. ### 10. Точки принятия решений и точки выхода Право остановить проект по завершении определенного этапа с заранее оговоренным порядком оплаты. Такой пункт снижает риски обеих сторон, поэтому хороший поставщик не будет возражать против него. ### 11. Передача знаний Не "обучение", а: количество часов, для кого, о чем и каков результат. Желательно, чтобы передача знаний распределялась на протяжении всего проекта, а не концентрировалась в его конце. ### 12. Завершение и выход Список передаваемых элементов, формат, период дублирования функций, тариф за часы поддержки при передаче. Это пункт, который никто не хочет обсуждать при подписании, и именно поэтому стоит настаивать на нем тогда. ## Карта рисков: что предотвращает каждый пункт | Пункт | Предотвращаемый отказ | Цена отсутствия | | --- | --- | --- | | Определение приемки | Спор о "завершении" | Задержка оплаты и ввода в эксплуатацию | | Запросы на изменение | Ценообразование в условиях острого дефицита | Неконтролируемое увеличение затрат | | Двусторонняя зависимость | Взаимные обвинения в задержке | Непрозрачное смещение сроков | | Право собственности и документация | Зависимость от поставщика | Высокие затраты при смене поставщика | | Ключевые специалисты | Тихая смена команды | Потеря контактов и знаний | | Гарантия | Спор о дефекте против изменения | Двойная оплата за исправление | | Выход | Переговоры с невыгодной позиции | Непредвиденные затраты на передачу | ## Формулировки, которых следует избегать - "Поставщик выполнит работу с обычным профессионализмом" — невозможно обеспечить соблюдение без критериев. - "Стороны согласуют позднее..." — каждый такой пункт является потенциальным конфликтом. - "При условии полного сотрудничества клиента" — без определения этого, это односторонняя защита. - "Результат будет поставлен по завершении проекта" — без определения, что такое завершение. - График платежей по календарным датам вместо привязки к приемке. ## Пример для иллюстрации: розничная сеть Гипотетический сценарий предназначен для иллюстрации. Сеть подписала соглашение (SOW), которое включало "миграцию данных клиентов из существующей системы". Организация предполагала, что миграция включает удаление дубликатов; поставщик предполагал, что он передает то, что ему было предоставлено. В результате были перенесены сотни тысяч записей с дубликатами. Обе стороны прочитали одно и то же предложение и поняли его по-разному. В контракте не было пункта, который бы определял, что считается корректной записью. Коррекция, сделанная в последующих соглашениях той же сети, была краткой: приложение, определяющее измеримый порог качества для загрузки — долю записей, проходящих валидацию, правила выявления дубликатов и кто утверждает. Это приложение заменило десятки часов споров. ## Что проверять перед подписанием - Каждый результат в предложении есть в SOW с критериями приемки. - Каждое предположение, представленное в предложении, отображено как явное предположение в контракте. - График платежей привязан к приемке. - Есть пункт о выходе и пункт о передаче знаний. - Определение дефекта достаточно четкое для разрешения пограничных случаев. То, что было согласовано при сравнении предложений, но не включено в контракт, просто не существует. Сам процесс сравнения подробно описан в [руководстве по сравнению предложений Salesforce](/ru/insights/compare-salesforce-proposals), а основа для формулирования требований закладывается уже в документе запроса (RFP), как указано в [руководстве по RFP](/ru/insights/salesforce-rfp-guide). ## Связь с выбором поставщика Некоторые из этих пунктов также служат инструментом оценки: поставщик, который противится пункту о праве собственности на документацию или пункту о выходе, говорит вам кое-что о своей бизнес-модели. Сочетание профессиональной оценки и договорной добросовестности оценивается в [руководстве по оценке поставщиков Salesforce](/ru/insights/salesforce-vendor-scorecard), а общие критерии для проверки компании собраны в [руководстве по выбору компании-интегратора](/ru/insights/choose-salesforce-implementation-company). Соответствие типа взаимодействия типу приобретаемой услуги подробно описано в [руководстве по услугам Salesforce](/ru/insights/salesforce-services-guide). ## Следующий шаг Возьмите SOW, которое у вас есть, и отметьте каждое место, где написано "будет поставлено" или "будет выполнено" без указания того, как будет определено, что это произошло. Каждая такая отметка — потенциальный конфликт, и каждую из них можно исправить сейчас, потратив всего пять минут. ### Вопросы и ответы **В чем разница между рамочным соглашением и SOW в проекте Salesforce?** Рамочное соглашение регулирует юридические аспекты: конфиденциальность, ответственность, страхование, интеллектуальную собственность, условия оплаты и разрешение споров. SOW регулирует саму работу: результаты, этапы, критерии приемки, допущения и объем. Одно рамочное соглашение может охватывать несколько SOW, что удобно при поэтапной работе. **Кому принадлежат код и конфигурации, разработанные в рамках проекта Salesforce?** Это определяется исключительно договором. По умолчанию у некоторых поставщиков индивидуальные результаты принадлежат заказчику, но общие компоненты и инфраструктура поставщика остаются в его собственности по лицензионному соглашению. Важно убедиться, что эта лицензия бессрочна и не зависит от продолжения сотрудничества, иначе смена поставщика создаст проблемы. **Каков разумный срок гарантии после запуска системы?** От тридцати до девяноста дней, в зависимости от сложности. Важнее продолжительности — определение: что считается дефектом, устраняемым бесплатно, а что — запросом на изменение. Практическая формулировка: любое несоответствие фактического поведения утвержденным критериям приемки является дефектом, все остальное — изменением. **Как сформулировать пункт, защищающий от замены команды исполнителя?** Указать имена ключевых специалистов и процент их занятости, а также предусмотреть обязательное предварительное уведомление и замену специалистами аналогичного профессионального уровня с одобрения заказчика. Кроме того, стоит установить минимальный период передачи дел. Такой пункт не предотвращает увольнения, но превращает его из сюрприза в управляемый процесс. **Что следует включить в пункт о расторжении договора?** Перечень передаваемых результатов, формат передачи, период передачи дел, доступ к средам и системам, а также стоимость часов поддержки при передаче. Без такого пункта расторжение договора превращается в переговоры с позиции слабости, поскольку знания и доступы находятся у другой стороны. --- ## Система оценки для выбора поставщика Salesforce: критерии и весовые коэффициенты URL: https://hpi.pro/ru/insights/salesforce-vendor-scorecard Комиссия по выбору без согласованной модели оценки почти всегда приходит к решению, которое обосновывается постфактум. Заранее определенная система оценки устанавливает, что измеряется, какие доказательства требуются для каждой оценки и что немедленно дисквалифицирует. Здесь представлена семимерная модель с примерами весовых коэффициентов и процессом оценки, предотвращающим необъективность. ## Почему комитеты по выбору принимают правильные решения, но неправильно их обосновывают На типичном совещании по принятию решений, после трех презентаций, участники произносят фразы вроде "они произвели на меня впечатление" или "они выглядели наиболее профессионально". Иногда выбор оказывается правильным. Проблема в том, что нет способа это узнать — и нет способа объяснить такое решение через год, когда проект столкнется с трудностями. Система оценки (Scorecard) не заменяет суждения. Она призвана гарантировать, что все предложения были рассмотрены по одним и тем же критериям, что доказательства каждой оценки задокументированы, и что то, что комитет считал важным до презентаций, осталось важным и после них. ## Семь критериев оценки **1. Понимание проблемы.** Относится ли предложение к вашим процессам и объемам, или оно носит общий характер. Выявил ли поставщик противоречие или пробел в документе запроса. **2. Качество архитектурного предложения.** Имеется ли диаграмма, определены ли источники достоверных данных, были ли рассмотрены альтернативы и объяснено, почему они были отклонены. **3. Фактическая команда.** Кто руководит, сколько времени уделяет, кто выполняет работу, и какова доля старших специалистов на этапах принятия решений. **4. Релевантный опыт.** Не количество проектов, а сходство: отрасль, сложность интеграции, масштаб и регулирование. **5. Модель работы и управления.** Темп демонстраций, управление решениями, управление рисками и методы обработки изменений. **6. Передача знаний и автономность.** Существует ли четкий план, который позволит вашей компании поддерживать систему без зависимости от поставщика. **7. Коммерческие условия.** Нормализованная цена, модель взаимодействия, договорная гибкость и готовность к защитным положениям. ## Примерные весовые коэффициенты — и как их адаптировать | Критерий | Новый проект в организации без команды | Проект по спасению | Расширение в организации с сильной командой | | --- | --- | --- | --- | | Понимание проблемы | 20% | 25% | 15% | | Архитектура | 20% | 20% | 25% | | Фактическая команда | 15% | 20% | 15% | | Релевантный опыт | 10% | 10% | 10% | | Модель работы и управления | 10% | 10% | 10% | | Передача знаний | 10% | 5% | 5% | | Коммерческие условия | 15% | 10% | 20% | Таблица иллюстрирует принцип: весовые коэффициенты не являются постоянными, а зависят от доминирующего риска. В организации без внутренней команды передача знаний ценится больше. При спасении проекта понимание ситуации и состав команды ценятся выше. Определите весовые коэффициенты **до** получения предложений и опубликуйте их в документе запроса, как подробно описано в [руководстве по RFP](/ru/insights/salesforce-rfp-guide). ## Шкала оценки с требуемыми доказательствами Проблема шкалы 1–5 заключается в том, что все оценивают на 4. Решение состоит в том, чтобы сопоставить каждому уровню доказательства: | Оценка | Значение | Требуемые доказательства | | --- | --- | --- | | 1 | Не соответствует | Пункт отсутствует в предложении | | 2 | Общее | Шаблонный текст без привязки к организации | | 3 | Удовлетворительно | Корректное, но поверхностное рассмотрение без глубины или альтернатив | | 4 | Хорошо | Специфическое рассмотрение с обоснованием и примером | | 5 | Отлично | Рассмотрены альтернативы, выявлены риски, даны рекомендации против того, что вы просили | Доказательства для оценки 5 делают модель полезной: поставщик, который говорит "эту часть вам пока не стоит создавать", демонстрирует понимание, которое невозможно подделать. ## Условия дисквалификации — до оценки Есть вещи, которые нет смысла взвешивать, потому что они являются основанием для дисквалификации: - Отказ передать результаты и документацию в собственность организации. - Отказ назвать имена членов команды и процентное распределение обязанностей. - Несоответствие обязательным требованиям регулирования или информационной безопасности. - Предложение, не соответствующее определенной структуре ценообразования, после предоставления возможности исправить. - Отсутствие готовности к базовому пункту о выходе из проекта. Определите их заранее. Дисквалификация, принятая задним числом, всегда выглядит целенаправленной против конкретного поставщика. ## Процесс оценки, снижающий предвзятость 1. Каждый член комитета оценивает **индивидуально** до совместного обсуждения. 2. Оценка сопровождается кратким комментарием, цитирующим источник в предложении. 3. Обсуждение концентрируется только на больших расхождениях между оценками — там, где находится информация. 4. Цена раскрывается на этом этапе, а не до него, если процесс это позволяет. 5. Итоговая оценка документируется вместе с обоснованием. Четвертый шаг имеет наибольшее влияние. Комитет, который видел цены до оценки качества, будет оценивать качество в соответствии с ценой, почти всегда неосознанно. ## Пример для иллюстрации: коммерческая охранная компания Сценарий гипотетический и предназначен для иллюстрации. Комитет по выбору оценил четырех поставщиков. Предложение, получившее наивысший балл по критерию "релевантный опыт", получило наименьший балл по критерию "понимание проблемы", потому что представленный документ был почти идентичен документу, представленному им в другом проекте, включая название отрасли, не имеющее отношения к текущему. В ходе обсуждения был выдвинут аргумент, что опыт компенсирует это. Комитет вернулся к весовым коэффициентам, установленным два месяца назад, где понимание проблемы имело вдвое больший вес, чем опыт. Решение осталось прежним. Что модель предотвратила в данном случае, так это не обязательно ошибочный выбор, а изменение правил игры после того, как результат уже известен. ## Что делать с результатом Оценка — это не решение. Это документ, который позволяет вести продуктивный диалог: где велика разница между поставщиками, чего не хватает в предложении лидера, и какой риск остается открытым. Часто наиболее полезным результатом является список условий для контракта, а не выбор между поставщиками. Коммерческая сторона нормализуется отдельно перед оценкой, как подробно описано в [руководстве по сравнению предложений](/ru/insights/compare-salesforce-proposals), а связь между структурой затрат и коммерческой оценкой объясняется в [руководстве по стоимости внедрения Salesforce](/ru/insights/salesforce-implementation-cost). ## Интеграция с профессиональным интервью Оценка на основе документов ограничена. Важным дополнением является встреча, на которой задаются открытые вопросы поставщику и оценивается его мышление в реальном времени. Полный набор вопросов представлен в [руководстве по вопросам перед выбором интегратора Salesforce](/ru/insights/questions-before-choosing-salesforce-integrator), а общие критерии проверки компании — в [руководстве по выбору компании-интегратора Salesforce](/ru/insights/choose-salesforce-implementation-company). ## Следующий шаг Запишите ваши весовые коэффициенты на бумагу, прежде чем читать первое предложение, и дайте каждому члену комитета оценить самостоятельно. Эти два шага, которые вместе занимают час, меняют качество решения больше, чем любой дополнительный раунд презентаций. ### Вопросы и ответы **Какой вес следует придавать цене при выборе поставщика Salesforce?** В проектах, где результат в основном зависит от качества решений, вес от двадцати до тридцати процентов является обычным и достаточным. Более высокий вес превращает выбор в выбор цены, а слишком низкий вес отрывает решение от бюджетной реальности. Важнее веса то, что оцениваемая цена нормализуется до того же объема. **Кто должен входить в состав конкурсной комиссии?** Представитель отдела закупок, владелец основного процесса, технологический специалист, который будет поддерживать систему, и финансовый представитель. Типичный размер — от четырех до шести человек. Комиссия большего размера, как правило, дает усредненную оценку, которая не различает претендентов, поэтому предпочтительнее привлекать дополнительных участников в качестве консультантов, а не оценщиков. **Действительно ли полезны интервью с предыдущими клиентами?** Да, если задавать правильные вопросы. Вопросы об удовлетворённости дают вежливые ответы. Вопросы, которые приносят информацию: что пошло не так и как отреагировал поставщик, кто был руководителем проекта и что он делал, и что бы вы сделали иначе. Лучше запросить отзывы о сложном проекте, а не о флагманском проекте. **Что делать, если два поставщика получают почти одинаковые оценки?** Не добавляйте новый критерий постфактум, потому что именно здесь проявляются личные предпочтения. Правильный инструмент - это целенаправленный раунд: один и тот же короткий сценарий для обоих, тот же вопрос об управлении рисками и оценка фактической команды. Разница, которая обнаруживается там, обычно более ясна, чем любая таблица. **Предпочтительнее ли крупный поставщик или бутик для проекта Salesforce?** Ответ зависит от типа риска, который вас беспокоит. Крупный поставщик предлагает значительные ресурсы и непрерывность, как правило, по более высокой цене и с меньшей гибкостью. Бутиковый поставщик предлагает прямой контакт с топ-менеджерами и гибкость, с риском зависимости от отдельных людей. Оба риска могут быть явно оценены вместо того, чтобы принимать решение на основе ощущения размера. --- ## API-лимиты в Salesforce: проектирование отказоустойчивых интеграций с учетом нагрузки URL: https://hpi.pro/ru/insights/salesforce-api-limits-resilience Salesforce отслеживает вызовы API в 24-часовых окнах и при превышении пороговых значений блокирует доступ, а не замедляет его. Организациям, одновременно выполняющим ночную синхронизацию, входящие вебхуки и отчеты, необходим тщательно спланированный бюджет вызовов, а не просто повторные попытки после исчерпания квоты. Данное руководство подробно рассматривает практические ограничения: как измерять потребление, когда переходить на Bulk API и как создать механизм экспоненциальной задержки (Backoff), который не перегружает систему второй волной сбоев. ## Что ломается первым при игнорировании лимитов API Компания, использующая три параллельные интеграции — ночную синхронизацию с ERP, веб-хук от платежной системы и внешнюю панель мониторинга, запрашивающую данные каждые пять минут, — не сталкивается с постепенным отказом систем. Она отлично работает до тех пор, пока не пересекает пороговое значение, после чего каждый последующий вызов API отклоняется с кодом `REQUEST_LIMIT_EXCEEDED` до ежедневного сброса. Отсутствует встроенное упреждающее предупреждение; есть лишь дашборд, на который можно посмотреть, если кто-то настроил процесс его проверки. Этот тип сбоя отличается от большинства сбоев в проектах Salesforce тем, что он не зависит от некачественного кода или неудачной архитектуры. Он зависит от накопления: новая интеграция всегда строится с учетом текущего состояния, без проверки того, какая часть дневного бюджета уже израсходована существующими процессами. В результате, пятая интеграция «ломает» предыдущие четыре, хотя ни одна из них не изменилась. ## Фактически актуальная карта лимитов Не все существующие в Salesforce лимиты одинаково важны для планирования интеграций. Ниже представлены те, которые действительно определяют архитектуру: | Тип лимита | Что измеряет | Кому вредит в первую очередь | | --- | --- | --- | | Ежедневные запросы API | Общее количество вызовов REST/SOAP за 24 часа | Любая синхронная интеграция с высокой частотой выполнения | | Пакеты Bulk API | Количество открытых/ежедневных пакетов | Ночные пакетные процессы, загружающие исторические данные | | Параллельные длительные запросы | Одновременные запросы, выполняющиеся более 20 секунд | Тяжелые отчеты или сложный синхронный Apex | | Доставка событий платформы | Объем событий в день на подписчика | Архитектуры Event-Driven между Salesforce и внешними системами | | Строки SOQL на транзакцию | Количество строк, извлекаемых в одной транзакции (50 000) | Логика Apex, выполняющая запросы в цикле | Эта таблица не является общим документом; это приоритизация. Организация, планирующая новую интеграцию, должна в первую очередь проверить первые две строки, поскольку именно они блокируются в производственной среде. Остальные лимиты влияют в основном на производительность, а не на доступность. ## Бюджет вызовов: как правильно его построить Основным инструментом предотвращения блокировок является не постфактум-мониторинг, а заранее определенный бюджет для каждого потребителя API. Принцип: каждая внешняя система, каждый интеграционный пользователь и каждый запланированный процесс получает определенное выделение из общего лимита, а не "сколько потребуется". Построение бюджета включает три этапа: 1. **Картирование потребителей** — список всех процессов, которые вызывают API: внешние интеграции, Scheduled Apex, ручной Data Loader, инструменты BI. Для каждого процесса выделяется отдельный Integration User для возможности изолированного отслеживания потребления в Event Monitoring. 2. **Расчет нагрузки на основе бизнес-объемов, а не допущений** — сколько записей обрабатывается в день, сколько вызовов требуется для одной записи (включая извлечение Related Lists), и что происходит в пиковые периоды (конец квартала, Черная пятница, закрытие месяца). 3. **Выделение резерва** — не следует распределять 100% лимита между существующими процессами. Оставьте 15–20% в качестве резерва для аварийных процессов, специальных отчетов и технического обслуживания – иначе любое небольшое дополнение подтолкнет организацию к превышению лимитов. Тем, кто хочет углубиться в проектирование уровня, управляющего этим бюджетом на уровне платформы, рекомендуется ознакомиться с [руководством по архитектуре CRM](/ru/insights/crm-architecture-guide), где представлено разделение между интеграционным уровнем и бизнес-уровнем. ## REST против Bulk: когда переход окупается Наиболее распространенная ошибка — использование обычного REST API для высокообъемного обмена данными, поскольку именно он создается первым и работает в PoC. Проблема возникает, когда объем увеличивается: REST считает каждый запрос (до 200 записей в Composite) как отдельный вызов квоты, тогда как Bulk API 2.0 выполняет пакеты до 10 000 записей и учитывается со значительно меньшими затратами на каждую запись. Практическое правило: если один процесс обновляет более 2000 записей за один проход, переход на Bulk API почти всегда оправдан — даже если это означает изменение кода потребителя для асинхронной работы с опросом статуса задачи вместо немедленного ответа. Ценой является более высокая задержка (минуты вместо секунд), поэтому Bulk не подходит для процессов, требующих принятия решений в реальном времени, таких как проверка наличия на складе перед подтверждением заказа. ## Backoff и Retry: предотвращение самоутопления Когда вызов API завершается сбоем из-за блокировки лимита, инстинктивная реакция большинства команд — немедленно повторить попытку. Именно такое поведение превращает временную блокировку в постоянный сбой: если десять процессов повторяют попытку в один и тот же момент, они заталкивают систему глубже в блокировку вместо того, чтобы дать ей восстановиться. Правильный механизм Backoff требует трех компонентов: - **Экспоненциальное замедление (Exponential Backoff)** — время ожидания между попытками растет экспоненциально (например, 2, 4, 8, 16 секунд), а не остается постоянным. - **Джиттер (Jitter)** — небольшое случайное добавление к времени ожидания, чтобы параллельные процессы не повторяли попытку в одну и ту же секунду, создавая новую волну нагрузки. - **Автомат отключения (Circuit Breaker)** — после нескольких последовательных сбоев (например, пяти) процесс полностью прекращает попытки на фиксированный период и отправляет уведомление в систему мониторинга, вместо того чтобы продолжать «стучаться в дверь». Без Circuit Breaker процесс, который выполняется каждые пять минут и постоянно завершается сбоем, будет повторять попытки сто раз в день и расходовать квоту только на сбои — это прямо противоположно тому, что должен предотвращать механизм. Более подробная информация об обработке ошибок на уровне интеграции представлена в [управлении ошибками интеграции в Salesforce](/ru/insights/salesforce-integration-error-handling). ## Сценарий: розничная торговля с тремя точками интеграции Предположим, средняя розничная сеть с 40 филиалами использует Salesforce Service Cloud в сочетании с системой POS и системой ERP для управления запасами. Действуют три активные интеграции: синхронизация запасов каждые 15 минут из ERP (около 8000 SKU), веб-хук из POS при каждой неудачной транзакции (около 300 в день) и внешняя панель мониторинга для Power BI, которая извлекает данные по обслуживанию каждый час. В месяц, когда сеть внедрила новую программу лояльности, появилась четвертая интеграция: проверка бонусных баллов в реальном времени из Salesforce на каждой кассе, около 6000 дополнительных вызовов в день. Через две недели синхронизация запасов начала давать сбои около 14:00-15:00, в пиковые часы работы касс. Сначала команда проверила ERP и подумала, что проблема там, но лог Salesforce показал `REQUEST_LIMIT_EXCEEDED` именно в этот период. Решение заключалось не в покупке дополнительной квоты, а в изменении приоритетов: проверка бонусных баллов была переведена на использование Platform Cache для часто не меняющихся результатов, что снизило количество вызовов примерно на 70%, а синхронизация запасов была переведена с REST на Bulk API с выполнением каждые 30 минут вместо 15. Результат: то же самое бизнес-покрытие, потребление квоты снизилось примерно на 45%, и появился реальный резерв для будущего роста. ## Риски и конкретные профилактические меры | Риск | Как проявляется на практике | Профилактическая мера | | --- | --- | --- | | Новая интеграция не проверялась по существующему бюджету | Блокировка проявляется только после запуска в эксплуатацию | Требование обзора производительности (Capacity Review) для каждой новой интеграции до запуска | | Повторная попытка без задержки | Временная блокировка становится проблемой на часы | Экспоненциальное замедление с джиттером и автоматом отключения у каждого потребителя API | | Использование REST для больших объемов | Единичный процесс потребляет десятки процентов дневного лимита | Переход на Bulk API при превышении заданного порога объема | | Отсутствие разделения интеграционных пользователей | Невозможно определить, какая интеграция потребляет квоту | Выделенный Integration User для каждой внешней системы, отслеживаемый отдельно | | Отсутствие резерва в бюджете | Любое небольшое добавление приводит к превышению лимита | Выделение 15%-20% квоты в качестве постоянного резерва, не выделяемого для ежедневных процессов | ## Чек-лист перед добавлением новой интеграции - ☐ Известен текущий процент потребления дневной квоты по каждому Integration User. - ☐ Проверен пиковый объем (не средний объем) новой интеграции. - ☐ Принято решение между REST и Bulk API на основе порогового значения объема, а не удобства разработки. - ☐ В коде потребителя присутствует механизм Backoff с Jitter и Circuit Breaker. - ☐ Настроено оповещение, когда потребление дневной квоты превышает 70%. - ☐ Проверена возможность использования Platform Cache для снижения повторных вызовов. - ☐ Существует резерв в 15%-20% от квоты, не распределенный заранее. - ☐ Определен операционный владелец, который получает оповещение, а не только технический лог. ## Как это отслеживать на постоянной основе Надежное измерение требует комбинации из трех источников: Event Monitoring (или Shield Event Monitoring) для фактического потребления API пользователем, Apex Limits в самом коде (`Limits.getLimitApiRequests()`) для локальной проверки во время выполнения, и встроенной панели мониторинга в разделе Company Information, которая отображает потребление относительно квоты на уровне организации. Ни один из этих источников не является достаточным сам по себе: первый показывает тенденцию, второй предотвращает отказ в рамках отдельного процесса, а третий служит ежедневной сводкой для операционной команды. Показатель, который следует отслеживать в долгосрочной перспективе, — это не только «сколько было израсходовано», но и «каков ежемесячный темп роста потребления» — поскольку именно это позволяет предсказать, когда организация достигнет предела, вместо того чтобы реагировать после того, как блокировка уже произошла. Когда существует несколько взаимозависимых систем, стоит также рассмотреть общую модель интеграции с [подключением Salesforce к системам ERP](/ru/insights/salesforce-erp-integration) и вопрос реализации — Flow против Apex — что также влияет на эффективность вызовов, в [Salesforce Flow или Apex](/ru/insights/salesforce-flow-vs-apex). ## Заключение Лимиты Salesforce API — это не проблема, которую решают, когда она возникает, — это переменная, которая должна быть частью каждого интеграционного решения с самого первого дня. Документированный бюджет вызовов для каждого Integration User, осознанный выбор между REST и Bulk в зависимости от объема, а также механизм Backoff, который предотвращает самоутопление, — эти три элемента вместе отличают организацию, которая обнаруживает проблему только тогда, когда она уже заблокирована, от организации, которая видит ее приближение за месяц и действует своевременно. ### Вопросы и ответы **Сколько API-вызовов доступно организации в Salesforce и как обновляется эта квота?** Ежедневная квота определяется типом редакции и количеством лицензий, сбрасываясь каждые 24 часа в фиксированное время, а не в полночь по серверному времени. Дополнение 'Additional API Calls' предоставляет фиксированные пакеты при необходимости, но это лишь краткосрочное решение. Если потребление постоянно растет с каждой новой интеграцией, проблема носит архитектурный, а не количественный характер. **В чем практическое различие между обычным REST API и Bulk API в контексте лимитов?** REST API засчитывает каждый вызов отдельно в дневную квоту, поэтому последовательное обновление 50 000 записей может само по себе израсходовать десятки процентов бюджета. Bulk API 2.0 работает пакетами (Batches) и учитывается значительно дешевле за каждую запись, но он асинхронный – код потребителя должен быть адаптирован для опроса статуса задачи (Job), а не ожидать немедленного ответа. **Что делать при получении ошибки REQUEST_LIMIT_EXCEEDED в середине критически важного бизнес-процесса?** Остановите запрашивающий поток, не пытайтесь повторить запрос немедленно с такой же интенсивностью. Примените экспоненциальную задержку (Exponential Backoff) с Jitter, отправьте запрос в очередь ожидания и уведомите оперативную группу, если блокировка длится дольше заранее определенного порога. Процесс, который продолжает попытки с постоянной скоростью, только продлевает блокировку и ставит под угрозу другие процессы, использующие ту же квоту. **Учитываются ли Platform Events или Change Data Capture в квоте API?** События, распространяемые через Platform Events и получаемые по CometD, не учитываются как обычные API-вызовы, что делает их эффективным способом потоковой передачи обновлений в реальном времени без потребления ежедневного бюджета. Однако любой REST-вызов, который потребитель совершает в ответ на событие – например, для получения полных деталей записи – учитывается. Поэтому стоит рассмотреть возможность включения необходимых полей в тело самого события. **Как заранее узнать, что новая интеграция выведет организацию за пределы лимитов?** Выполните простой прогноз: ежедневный объем записей умножьте на количество вызовов на запись (включая связанные записи и Lookups, извлекаемые отдельно), и сравните эту сумму с остатком после учета существующих интеграций. Если результат превышает 70-80% от общей квоты, необходимо запланировать использование Bulk API, кэширование или сокращение полей до запуска в производство – а не после первой блокировки. --- ## Событийно-ориентированная архитектура в Salesforce: Platform Events и Change Data Capture URL: https://hpi.pro/ru/insights/salesforce-event-driven-architecture Platform Events и CDC решают одну и ту же проблему: разобщение между системами, которым не нужно ждать друг друга. Проблема возникает, когда выбор между ними делается исходя из технического удобства, а не из того, кому принадлежат данные, требуемого уровня надежности, и что происходит, когда сообщение приходит дважды или не приходит вовсе. ## Выбор, который на самом деле не связан с технологиями Когда организация начинает обсуждать событийно-ориентированную архитектуру в Salesforce, разговор слишком быстро переходит к теме «Platform Events или CDC?», как будто это вопрос выбора инструментов. На самом деле это совершенно другой вопрос: какая сторона в интеграции является источником истины, что разрешено ей потерять и кто несет затраты, если сообщение приходит поздно, дублируется или не приходит вовсе. Краткий ответ: Change Data Capture подходит, когда внешняя система должна знать, что Salesforce обновил запись, и нет необходимости обертывать это бизнес-логикой. Пользовательские Platform Events подходят, когда нужно опубликовать значимое бизнес-событие — «клиент обновил тариф», а не «поле Status_c изменилось». Неправильный выбор не заметен в день запуска; он проявляется, когда кто-то пытается восстановить произошедшее после частичного сбоя и обнаруживает отсутствие надежного способа получить информацию. Тот, кто ищет широкую картину интеграций Salesforce за пределами событий, найдет ее в [Руководстве по архитектуре CRM](/ru/insights/crm-architecture-guide). ## Три вопроса, определяющие архитектуру до написания кода Прежде чем выбрать механизм, необходимо ответить на три вопроса. Пропуск любого из них является наиболее частой причиной того, что интеграционные проекты застревают на этапе тестирования. **Кто владелец данных?** Если Salesforce является источником истины для записи клиента, то исходящие события из Salesforce (Platform Event или CDC) — естественное направление. Если владельцем является ERP-система, верно обратное, и Salesforce должен потреблять события, а не публиковать их для той же сущности. **Что можно потерять?** Уведомление для управленческой панели может потерять одно сообщение без ущерба. Обновление кредитного лимита до одобрения сделки — нет. Это различие определяет, достаточно ли «выстрелил и забыл» или необходим механизм подтверждения и мониторинга расхождений (Reconciliation). **Что происходит, если сообщение приходит дважды?** Platform Events гарантируют доставку «как минимум один раз», а не «точно один раз». Если ответ «не знаем», решение еще не готово к производству, независимо от чистоты кода. ## Platform Events против CDC — таблица принятия решений | Критерий | Пользовательский Platform Event | Change Data Capture | | --- | --- | --- | | Что публикуется | Определенное бизнес-событие (настраиваемая полезная нагрузка) | Изменение исходной строки (до/после) | | Кто строит логику | Разработчик Salesforce, во время триггера или Flow | Платформа, автоматически для любого определенного DML | | Связь со схемой | Низкая — полезная нагрузка контролируется издателем | Высокая — любое изменение структуры объекта влияет на потребителя | | Подходит, когда... | Нужно опубликовать бизнес-намерение ("заказ подтвержден") | Нужна грубая синхронизация данных между системами | | Стоимость поддержки | Выше в начале (создание полезной нагрузки и логики) | Низкая в начале, высокая при изменении структуры объекта | | Сохранение данных (Retention) | Согласно конфигурации лицензии (часы до дней) | Согласно конфигурации лицензии, обычно то же, что и для Platform Events | | Рекомендуемый объем | События домена со средней частотой | Изменения на уровне строки, включая высокую частоту | Практическое правило: если потребителю события нужно понимать «почему» это произошло, а не только «что» произошло, то нужен пользовательский Platform Event. Если потребителю нужна только актуальная копия данных, CDC экономит целый уровень разработки. ## Ordering, Replay и Idempotency: три понятия, которые превращают теорию в стабильное производство Это не вопросы для поздней стадии проекта — они определяют структуру потребителя с самого первого дня. **Ordering (порядок).** Platform Events отправляются в порядке публикации внутри одной темы, но нагрузка и частичные сбои могут нарушить порядок получения на стороне потребителя. Практическое решение: прикреплять к каждому событию отметку версии или порядковый номер из исходной записи и позволять потребителю отклонять событие, версия которого ниже последней уже обработанной. **Replay (повторное воспроизведение).** Каждое событие получает Replay ID. Потребитель, который отключается, должен сохранить последний успешно обработанный Replay ID — не в памяти, а в надежном месте (Custom Object, внешняя таблица) — и продолжить с этого места после восстановления. Зависимость от того, что «система начнет сначала», работает только в пределах окна Retention, а за его пределами события теряются. **Idempotency (идемпотентность).** Каждый потребитель должен идентифицировать уже обработанное событие, обычно по уникальному идентификатору транзакции, отправляемому в полезной нагрузке. Без этого автоматическая повторная попытка на стороне отправителя — или ручное повторное воспроизведение после сбоя — приводит к двойному обновлению, созданию дублирующей записи или, в худшем случае, двойному списанию. Этот недостаток почти никогда не проявляется на демонстрации. Он проявляется при нагрузке, при реальном сетевом сбое или изменении в производственной среде, и тогда стоимость исправления включает в себя также и исправление данных. Организации, сталкивающиеся с аналогичной проблемой на уровне автоматизации, найдут дополнительный анализ в [Техническом долге Salesforce в Flow и Apex](/ru/insights/salesforce-flow-apex-technical-debt). ## Пример: розничная сеть с 40 филиалами и отдельной системой управления запасами Предположим, гипотетическая розничная сеть «Северный ритейл» использует Salesforce Sales Cloud для команд продаж в 40 филиалах и отдельную ERP-систему, которая управляет запасами в реальном времени. До сих пор каждый заказ, закрытый в Salesforce, передавался в ERP через запланированное задание, которое выполнялось каждые 15 минут — решение, из-за которого менеджеры иногда видели устаревшие данные о запасах и подтверждали заказы на товары, которых уже не было в наличии. Архитектурная команда решила публиковать пользовательский Platform Event с именем `Order_Confirmed__e` при каждом подтверждении заказа, с полезной нагрузкой, включающей уникальный идентификатор транзакции, список товаров и количество. ERP-система слушает это событие и обновляет запасы в течение нескольких секунд, проверяя идентификатор транзакции на соответствие таблице уже обработанных транзакций — чтобы предотвратить двойное списание, если событие придет дважды. Кроме того, был настроен ночной процесс Reconciliation, который сравнивает общее количество подтвержденных заказов в Salesforce с общим количеством обновлений, полученных в ERP, и предупреждает о расхождениях выше определенного порога. Причина: даже при правильной Idempotency требуется раннее обнаружение длительного сбоя сети, а не только уверенность в том, что событие «точно дошло». Результат: время обновления сократилось с 15 минут до менее одной минуты, а количество случаев ошибочных данных о запасах заметно снизилось в течение месяца после внедрения. Этот сценарий иллюстрирует ключевой принцип: ценность создается не только «переходом к событиям», а сочетанием четкого бизнес-события, проверки на дубликаты на стороне потребителя и процесса мониторинга, который выявляет расхождения до того, как они превратятся в жалобу клиента. ## Распространенные риски и профилактические меры | Риск | Как проявляется на практике | Профилактическая мера | | --- | --- | --- | | Публикация события при каждом изменении поля | Дневной лимит событий превышается в течение нескольких дней | Публиковать значимые бизнес-события домена, а не технические события при каждом DML | | Отсутствие проверки на дубликаты на стороне потребителя | Повторная попытка или воспроизведение создают дублирующие записи или обновления | Прикреплять уникальный идентификатор транзакции и проверять его перед каждой операцией | | Зависимость от порядка поступления | Старое обновление перезаписывает более новое обновление | Прикреплять метку версии и отклонять события, более старые, чем последняя обработанная версия | | Отсутствие сохранения Replay ID | После сбоя потребителя события между сбоем и окном Retention теряются | Сохранять Replay ID в надежном месте и запускать автоматическое повторное воспроизведение при перезапуске | | CDC на объекте, часто меняющем структуру | Каждое изменение поля нарушает работу внешнего потребителя без предупреждения | Определить явный контракт данных и заранее сообщать об изменениях схемы | | Отсутствие бизнес-мониторинга, только технический мониторинг | Интеграция "зеленая", но фактический остаток или заказы не совпадают | Добавить ежедневный процесс Reconciliation, который сравнивает бизнес-результаты между системами | ## Контрольный список перед началом разработки событийного уровня - ☐ Для каждого события есть четкий владелец: кто публикует и кто является бизнес-владельцем данных - ☐ Определена и задокументирована фиксированная структура полезной нагрузки, а не структура, меняющаяся с каждым Sprint - ☐ Выбор между пользовательским Platform Event и CDC сделан в соответствии с бизнес-целями или необработанными изменениями - ☐ У каждого потребителя есть уникальный идентификатор транзакции и проверка на дубликаты (Idempotency) - ☐ Определена обработка порядка по метке версии, а не по порядку поступления - ☐ Replay ID сохраняется в надежном месте, и процесс восстановления определен и протестирован - ☐ Существует бизнес-мониторинг (Reconciliation) в дополнение к техническому мониторингу очереди сообщений - ☐ Протестированы сценарии нагрузки и частичного сбоя, а не только «счастливый путь» - ☐ Суточный лимит событий (публикация + доставка) проверен на соответствие ожидаемому объему в производстве - ☐ Определен операционный владелец для реагирования при обнаружении расхождения в Reconciliation ## Как измерить эффективность архитектуры | Область | Что измеряется | Частота проверки | | --- | --- | --- | | Надежность доставки | Процент успешно доставленных событий без повторных попыток, и процент успешных после повторных попыток | Непрерывно | | Разногласия Reconciliation | Разница между записями, подтвержденными источником, и записями, полученными назначением | Ежедневно | | Задержка сквозной передачи (Latency) | Время между бизнес-событием и фактическим обновлением у потребителя | Непрерывно | | Использование лимита событий | Процент от суточной квоты, фактически использованной | Еженедельно | | Предотвращенные дубликаты | Количество событий, идентифицированных как дубликаты и заблокированных до выполнения | Еженедельно | Рекомендуется выбрать не более трех-четырех показателей для первой версии и измерять их относительно базового уровня, собранного до перехода к событийной архитектуре, — а не относительно общего ощущения, что «теперь это быстрее». Для планирования более широкой организационной структуры многочисленных интеграций следует также рассмотреть [паттерны интеграции Salesforce](/ru/insights/salesforce-integration-patterns) и их влияние на [ Single Org против Multi Org архитектуру Salesforce](/ru/insights/salesforce-single-org-vs-multi-org), так как решение по событиям иногда пересекает организационные границы. ## Заключение Выбор между Platform Events и CDC — это не технический вопрос, который кратко рассматривается в начале проекта; он определяет, кто является источником истины, что разрешено потерять и как система ведет себя в случае сбоя. Организация, которая заранее планирует Ordering, Replay и Idempotency, и добавляет уровень бизнес-сверки (Reconciliation) в дополнение к техническому мониторингу, получает интеграцию, способную выдерживать нагрузку и частичные сбои. Организация, которая пропускает эти шаги, получает систему, которая кажется работоспособной при тестировании, но незаметно ломается в продуктовой среде, обычно без того, чтобы кто-либо заметил, пока ущерб уже не нанесен. Организации, желающие получить поддержку в создании надежного событийного уровня в Salesforce, могут связаться с нами через [сервис архитектуры CRM](/ru/crm-architecture). ### Вопросы и ответы **Когда предпочтительнее использовать Change Data Capture (CDC) вместо пользовательского Platform Event?** CDC предпочтительнее, когда Salesforce является источником истины, и целевая система должна знать об изменении записи без необходимости ручной реализации логики публикации. CDC устраняет этот уровень, но раскрывает внутреннюю структуру объекта внешним подписчикам — любое изменение поля влияет на потребителя. Пользовательский Platform Event лучше использовать, когда необходимо публиковать бизнес-намерение ('заказ подтвержден'), а не техническое изменение строки данных. **Обеспечивают ли Platform Events доставку сообщения только один раз?** Нет. Платформа гарантирует доставку 'как минимум один раз' (At-Least-Once), что означает, что сообщение может прийти дважды в сценарии сбоя сети или повторного воспроизведения (Replay). Крайне важно проектировать потребителя как идемпотентного — проверять уникальный идентификатор транзакции перед выполнением операции. В противном случае двойное обновление, создание дублирующей записи или двойное выставление счета являются ожидаемым результатом, а не аномалией. **Что произойдет, если потребитель событий будет недоступен в течение нескольких часов?** Platform Events сохраняются в Event Bus в течение периода хранения (Retention), который определяется лицензией (обычно от 24 часов до 3 дней). Можно выполнить повторное воспроизведение (Replay) с последней успешно полученной точки Replay ID. Важно сохранять Replay ID на стороне потребителя и не полагаться на то, что 'мы все получили' — если окно хранения истекло без повторного воспроизведения, события безвозвратно теряются. **Как поддерживать порядок обновлений, когда несколько событий затрагивают одну и ту же запись?** Platform Events не гарантируют порядок между различными каналами, а иногда и внутри одного канала при высокой нагрузке. Распространенное решение — добавлять метку версии или порядковый номер к каждому событию и позволять потребителю отклонять обновление, которое пришло с более старой версией, чем уже обработанная, вместо того чтобы полагаться на порядок поступления. **Сколько Platform Events можно публиковать без ущерба для производительности?** Лимит измеряется по количеству событий в день и по доставке в день, в зависимости от версии и лицензии, и учитывается даже для неудачно отправленных событий. Проект, который публикует событие при каждом изменении поля в нагруженной таблице, быстро достигает этого предела. Следовательно, следует публиковать события предметной области (Domain Events) на уровне бизнес-значимости, а не технические события при каждой операции DML. --- ## SSO, MFA и Identity в Salesforce: Принципы корпоративного проектирования URL: https://hpi.pro/ru/insights/salesforce-sso-identity-architecture SAML или OIDC, инициация IdP или SP, JIT или SCIM для управления жизненным циклом — каждый выбор в архитектуре Identity для Salesforce определяет, кто получает доступ к системе, с какими разрешениями и что происходит в день увольнения. Статья представляет конкретную систему принятия решений, включая сценарий неудачного оффбординга и способы его исправления. ## Краткие выводы Архитектура идентификации в Salesforce — это не разовый технический проект, а постоянно действующий контрольный слой: кто входит, с какой идентификацией, с какими разрешениями, и что происходит, когда доступ к системе больше не требуется. Выбор между SAML и OIDC, JIT и SCIM, а также между политикой MFA на уровне поставщика идентификации (IdP) и внутренней принудительной проверкой в Salesforce — все это кажется деталями конфигурации, но фактически определяет, сколько времени потребуется для блокировки доступа уволенного сотрудника и какая часть таких инцидентов будет обнаружена только при аудите. Правильный подход начинается не с протокола, а с двух вопросов: кто является источником истины для идентификации пользователя и каково максимально допустимое время между событием прекращения работы (Offboarding) и фактической блокировкой доступа. Отсюда вытекают все остальные решения — тип федерации, метод управления учетными записями (Provisioning), политика сессий и процесс аварийного доступа (Break Glass). Организации, которые также рассматривают вопрос о самих разрешениях, а не только об аутентификации, найдут дополнительную информацию в [модели разрешений Salesforce](/ru/insights/salesforce-permission-model). ## Карта решений: четыре слоя идентификации в Salesforce | Слой | Вопрос, который необходимо решить | Основные опции | Что может выйти из строя при неправильном решении | | --- | --- | --- | --- | | Федерация и аутентификация | Кто является поставщиком идентификации (IdP) и как Salesforce доверяет ему | SAML 2.0, OIDC, делегированная аутентификация | Двойной вход, несоответствие атрибутов, нарушение доверия | | Управление учетными записями (Provisioning) и жизненный цикл | Как пользователь создается, обновляется и удаляется | JIT Provisioning, SCIM, ручное создание | Устаревшие учетные записи, доступ, сохраняющийся после увольнения | | Сессия и MFA | Где применяется уровень аутентификации и продолжительность сессии | MFA в IdP, внутренний MFA в Salesforce, политики сессий | Обход MFA через альтернативный путь, сессия, которая никогда не истекает | | Аварийный доступ (Break Glass) и аудит | Что происходит, если SSO выходит из строя, и кто проверяет аномалии | Контролируемый аварийный пользователь, история входов, мониторинг событий | Полная зависимость от IdP, невозможность ретроспективного расследования | ## SAML против OIDC: не вопрос "что новее" Выбор между двумя протоколами не должен основываться на тенденциях, а на существующей инфраструктуре. SAML работает с XML и подписанными утверждениями (Assertions), и распространен в организациях с Active Directory Federation Services или давним IdP, который уже используется десятками других систем. OIDC построен поверх OAuth 2.0, проще в обслуживании и особенно удобен, когда тот же IdP должен обслуживать как современных потребителей API, так и вход пользователей. Распространенная ошибка — выбирать по принципу "что выглядит более продвинуто", не проверяя, какие атрибуты уже отправляет существующий IdP и как они соотносятся с Salesforce (имя пользователя, ID федерации, профиль, группа наборов разрешений). Неправильное сопоставление атрибутов на этапе настройки часто приводит к ручной коррекции десятков пользователей в производственной среде, а не просто к изменению конфигурации. Важный момент: даже при выборе OIDC или SAML, стоит отдельно планировать IdP-инициированный и SP-инициированный вход. Некоторые распространенные инциденты безопасности возникают из-за того, что SP-инициированный вход остается открытым, хотя весь процесс входа был запланирован только через портал IdP. ## JIT Provisioning против SCIM: когда "в момент входа" недостаточно JIT (Just-In-Time) Provisioning создает или обновляет пользователя в Salesforce во время первого входа, согласно данным, поступающим от IdP в SAML Assertion или OIDC Token. Это удобно, недорого в реализации и достаточно для большинства организаций, где пользователи регулярно входят в систему. Проблема: JIT не решает проблему деактивации (Deprovisioning). Если сотрудник удален из IdP, но больше не входит в систему, его пользовательская учетная запись остается активной в Salesforce неограниченное время, потому что нет события, которое вызывает обновление. Именно здесь вступает в силу SCIM (System for Cross-domain Identity Management) — он обеспечивает централизованную, инициируемую синхронизацию от IdP к Salesforce, включая немедленную деактивацию при удалении пользователя в источнике. Практическое правило: если у организации есть требование к удалению учетной записи (Offboarding) в течение часов, а не дней — для подрядчиков, временных сотрудников, доступа к конфиденциальным данным — SCIM является не "приятным дополнением", а требованием соответствия. Если текучесть кадров низкая и управление уже включает ежеквартальный обзор доступов, одного JIT может быть достаточно при условии, что он сопровождается документированным ручным процессом для немедленной блокировки. Планирование управления учетными записями (Provisioning) всегда должно рассматриваться также в контексте сложности автоматизации вокруг него — например, когда задействованы потоки (Flow), выполняющие логику распределения разрешений во время создания пользователя, где актуально сравнение [Flow против Apex](/ru/insights/salesforce-flow-vs-apex) в отношении того, где целесообразен настраиваемый код. ## MFA и политика сессий: два слоя, а не один Распространенная ошибка — ограничиться MFA, принудительно применяемым поставщиком идентификации, и полагать, что он охватывает все пути входа в Salesforce. На практике, пока существует пользователь, который может войти напрямую через login.salesforce.com — например, интеграция, пользователь API или администратор, имеющий резервный доступ — требуется отдельная политика MFA, настроенная внутри самой Salesforce (Identity Verification, Session Security Levels). Кроме того, политика сессий определяет важные, но легко упускаемые моменты: Session Timeout, «Force logout on session timeout», Login IP Ranges, и "High Assurance Session" обязательны для чувствительных операций (например, изменение разрешений или массовый экспорт данных). Организация, которая настраивает сильный MFA, но оставляет Session Timeout по умолчанию в два часа, открывает окно, в котором украденный компьютер сохраняет активный доступ гораздо дольше разумного времени. ## Аварийный доступ (Break Glass) и аудит: когда SSO выходит из строя, кто входит Полная зависимость от внешнего поставщика идентификации (IdP) создает единую точку отказа: если IdP выходит из строя или существует ошибка в конфигурации федерации, никто не может войти, включая тех, кто должен устранить проблему. Принятое решение — пользователь аварийного доступа (Break Glass) — учетная запись суперпользователя с независимой аутентификацией (не зависящей от SSO), паролем, хранящимся в сейфе (Vault), а не в памяти человека, и отдельным MFA. Важно различать: аварийный доступ (Break Glass) — это не "удобная лазейка", а контролируемый механизм экстренного реагирования. Его использование должно вызывать автоматическое оповещение и проверяться в течение одного рабочего дня тем, кто не является его пользователем. Многие организации правильно настраивают пользователя, но забывают о текущем контроле — пароль не меняется, а его разрешения слишком широки по умолчанию. ## Организационный сценарий: сбой Offboarding в средней страховой компании Предположим, страховая компания с примерно 600 сотрудниками, использующая Okta в качестве поставщика идентификации (Identity Provider) и конфигурацию SAML с Salesforce, созданную около трех лет назад. Управление учетными записями (Provisioning) полностью основано на JIT: когда новый сотрудник входит в систему в первый раз, для него создается пользовательская учетная запись с профилем (Profile) и группой наборов разрешений (Permission Set Group) в соответствии с группой Okta, к которой он принадлежит. В одном случае сотрудник службы поддержки был уволен в пятницу днем. Команда ИТ немедленно деактивировала его в Okta. Однако, поскольку не было механизма SCIM или веб-хука, который синхронизировал бы деактивацию с Salesforce, его пользовательская учетная запись оставалась активной там — и поскольку его сессия уже была активна с утра и не была настроена опция "Force logout on session timeout", он продолжал получать доступ к системе даже после увольнения, пока кто-то не заметил это при еженедельном обзоре доступа в понедельник. Решение, которое было реализовано, не было полным переходом на SCIM (что потребовало бы отдельного проекта и бюджета на интеграцию), а немедленное объединение трех действий: активация "Force logout on session timeout" для всех конфиденциальных профилей, сокращение времени ожидания сессии (Session Timeout) со 120 минут до 30 минут для клиентских ролей, и добавление автоматического шага в процесс корпоративного Offboarding, который выполняет прямую деактивацию в Salesforce как самостоятельное действие, а не только как косвенный результат деактивации в Okta. SCIM оставался целью на следующий квартал, уже с бюджетом и одобрением, но наиболее опасный пробел был устранен в течение недели. ## Распространенные риски и профилактические меры | Риск | Как это выглядит на практике | Профилактическая мера | | --- | --- | --- | | Полная зависимость от JIT без деактивации | Уволенные пользователи остаются активными неограниченное время | Добавление независимого шага Offboarding в Salesforce, не зависящего от синхронизации | | MFA только в IdP | Пользователи интеграции и администраторы обходят MFA через прямой вход | Внутренняя политика MFA в Salesforce для всех типов пользователей | | Слишком долгий Session Timeout | Украденный компьютер или забытая открытая сессия сохраняет доступ часами | Сокращение времени ожидания (Timeout) и принудительный выход (Force Logout) для чувствительных профилей | | Break Glass без контроля | Использование экстренной учетной записи не обнаруживается вовремя | Автоматическое оповещение и проверка в течение одного рабочего дня для каждого использования | | Неправильное сопоставление атрибутов из IdP | Пользователь получает неверный профиль (Profile) или роль (Role) при первом входе | Полная проверка сопоставления в среде Sandbox перед изменением в производственной среде | ## Контрольный список для создания или аудита архитектуры идентификации - ☐ Определен единственный поставщик идентификации (Identity Provider) как источник достоверных данных, и известно, что происходит при его сбое. - ☐ Протокол (SAML или OIDC) выбран на основе существующей инфраструктуры, а не тенденций. - ☐ Отображение атрибутов между IdP и Profile/Permission Set Group проверено в Sandbox. - ☐ Определена четкая политика: только JIT, или JIT в сочетании с SCIM в соответствии с требованием к процедуре увольнения (Offboarding). - ☐ MFA принудительно применяется внутри Salesforce, а не только в IdP. - ☐ Session Timeout и Force Logout настроены в соответствии с чувствительностью профиля. - ☐ Существует контролируемый пользователь Break Glass с отдельным MFA и паролем в хранилище. - ☐ Процесс Offboarding включает самостоятельный шаг для деактивации в Salesforce. - ☐ Login History и Event Monitoring проверяются по установленному расписанию. - ☐ Существует план периодической проверки (Access Review), который не зависит только от памяти ИТ-отдела. ## Как оценить эффективность архитектуры Основной показатель — это не "работает ли SSO", а время реакции между событием в источнике достоверных данных и соответствующим изменением в Salesforce: сколько времени проходит между удалением пользователя в IdP и его фактической деактивацией. Дополнительный показатель — это доля входов, осуществляемых по непредвиденному пути (прямой вход вместо входа через IdP), которая должна стремиться к нулю, за исключением документированных Break Glass. Третий показатель — это частота пересмотра разрешений по сравнению с текущим состоянием — не каждое организационное изменение проходит через IdP, поэтому ежеквартальный пересмотр остается необходимым даже при полной автоматизации управления учетными записями (Provisioning). Для внедрения или аудита архитектуры идентификации в существующей среде Salesforce можно воспользоваться [услугой по архитектуре CRM](/ru/crm-architecture). Организации, которые также рассматривают связь с ERP и кадровыми системами как часть общей картины идентификации, найдут дополнительную информацию в [интеграции Salesforce с ERP](/ru/insights/salesforce-erp-integration) и более широкое представление об архитектуре в [руководстве по архитектуре CRM](/ru/insights/crm-architecture-guide). ## Заключение Архитектура идентификации в Salesforce создается единожды, но ежедневно проверяется на наличие отдельных инцидентов: уходящий сотрудник, сессия, которую забыли закрыть, интеграция, обходящая MFA. Ключевые решения (SAML против OIDC, JIT против SCIM, двойной MFA, контролируемый Break Glass) не должны зависеть от конфигурации IdP по умолчанию, а должны определяться временем, необходимым для блокировки доступа, и уровнем чувствительности раскрываемой информации. Организация, которая планирует этот слой заранее, вместо того чтобы обнаруживать пробелы при аудите или после инцидента безопасности, экономит как на затратах на исправление, так и снижает репутационный и регуляторный риски. ### Вопросы и ответы **Каковы практические отличия между SAML и OIDC для Salesforce?** Обе технологии поддерживаются как поставщики единого входа (Single Sign-On). Однако OIDC основан на REST/JSON и легче интегрируется с современными IdP и дополнительными потребителями API, в то время как SAML более распространен в организациях с устаревшей инфраструктурой IAM или регуляторными требованиями, уже построенными на его основе. Выбор должен зависеть от существующего IdP в организации, а не только от технологических соображений. Переход между ними после того, как были построены сопоставления атрибутов и наборов разрешений, является нетривиальной задачей. **Когда следует использовать JIT Provisioning, а когда SCIM?** JIT подходит, когда достаточно создать и обновить пользователя при первой аутентификации, и когда нет реальной необходимости в немедленном депровижении вне цикла SSO. SCIM требуется, когда существует оперативное обязательство по отзыву доступа в течение нескольких минут после удаления пользователя в IdP, то есть в организациях с требованием немедленного оффбординга, временными подрядчиками или регулированием, требующим доказательства синхронизации между источниками. **Достаточно ли MFA, принуждаемого IdP, или требуется также MFA на уровне Salesforce?** Если все входы проходят через IdP и нет прямого пути входа в Salesforce, MFA в IdP может быть достаточно для обычной аутентификации. Однако всегда требуется также внутренняя политика MFA в Salesforce, чтобы охватить пользователей Break Glass, интеграции с сервисными учетными записями и любой маршрут, обходящий IdP, — в противном случае возникает пробел в безопасности именно в самом чувствительном месте. **Как создать пользователя Break Glass, который не станет постоянной лазейкой?** Учетная запись Break Glass должна иметь пароль, управляемый в хранилище, отдельный MFA, ограниченные разрешения только для чрезвычайных ситуаций, а не общие права системного администратора, и автоматическое уведомление при каждом использовании. Обязательное правило — каждое использование должно быть проверено в течение одного рабочего дня, и должен существовать ежеквартальный процесс, который гарантирует изменение пароля, даже если он не использовался. **Что происходит, когда сотрудник увольняется, и IdP не синхронизируется с Salesforce в реальном времени?** Без SCIM или Webhook, запускающего немедленную деактивацию, пользователь остается активным в Salesforce даже после удаления в IdP, потому что существующая сессия не проверяется с IdP при каждом запросе. Практическое решение — это комбинация короткого таймаута сессии, ограничений по IP-адресам для входа и процесса оффбординга, запускающего прямую деактивацию в Salesforce как независимый шаг, а не только как зависимость от медленной синхронизации с IdP. --- ## Sharing & Visibility в Salesforce: Проектирование комплексного доступа к данным URL: https://hpi.pro/ru/insights/salesforce-sharing-visibility-design Открытые OWD, установленные «чтобы никого не блокировать», и иерархия ролей, развивающаяся спонтанно, прокладывают кратчайший путь к отчетам, где региональный менеджер видит всех клиентов своего внутреннего конкурента. Данная статья предлагает обратный подход: сначала мы определяем, кто, что и почему должен видеть, и только затем выбираем между OWD, Role Hierarchy, Sharing Rules, Teams и Apex Sharing. ## Почему модель совместного доступа, построенная ретроспективно, сложнее правильно выстроенной архитектуры Типичная проблема проявляется не в первый месяц. Она обнаруживается, когда региональный менеджер по продажам замечает, что видит данные по конкурирующему региону, или когда сервисный представитель открывает запись VIP-клиента, которая должна быть доступна только специализированной команде. Оба этих случая являются прямым следствием обратного порядка работы: сначала определяются объекты и поля, и только в конце задается вопрос, кто и что должен видеть. Модель видимости в Salesforce строится из слоев, которые работают совместно, а не изолированно: Organization-Wide Defaults (OWD) задает наиболее приватный базовый уровень, Role Hierarchy добавляет вертикальный доступ в соответствии с управленческой структурой, Sharing Rules открывают горизонтальный доступ по бизнес-критериям, Teams и Manual Sharing обрабатывают частные случаи, а Apex Managed Sharing вступает в действие, когда логика слишком сложна для статического выражения. Этот порядок важен: каждый слой, выбранный преждевременно, создает «технический долг», который трудно погасить, поскольку уже предоставленные разрешения воспринимаются как существующее право. ## Карта слоев и когда каждый из них уместен | Слой | Что решает | Когда выбрать | Риск неправильного выбора | |-----------------------|--------------------------------------------------------------------------------|---------------------------------------------------------------------------------|---------------------------------------------------------------------------| | OWD | Базовый уровень: кто по умолчанию ничего не видит | Всегда настроен, обычно Private для конфиденциальных объектов | Слишком открытый OWD делает все остальные слои излишними | | Role Hierarchy | Вертикальный доступ менеджера к информации подчиненных | Когда управленческая структура отражает также необходимость контроля данных | «Политическая» иерархия, не соответствующая реальному владению данными | | Sharing Rules | Открытие горизонтального доступа по постоянному критерию (роль, группа, значение поля) | Команда, работающая в разных иерархиях, которой нужен доступ к одному типу записей | Множество пересекающихся правил, затрудняющих определение, кто что открыл | | Public Groups | Группировка пользователей для общего доступа, независимо от иерархии | Когда рабочая группа не соответствует одной организационной роли | Группы, которые не обновляются при смене должности сотрудником | | Account/Case Teams | Динамический доступ к отдельной записи на основе состава ее команды | Когда у каждого клиента или дела есть уникальная изменяемая команда | Ручное обслуживание, о котором забывают при смене команды | | Territory Management | Распределение доступа на основе динамических и многомерных правил | Переменное распределение по нескольким признакам одновременно, параллельный доступ к нескольким представителям | Сложность обслуживания, неоправданная ниже определенного организационного порога | | Apex Managed Sharing | Совместный доступ, определяемый динамической логикой, которую невозможно выразить статически | Критерий, зависящий от расчета, внешнего события или комбинации полей | Код без мониторинга, продолжающий работать после изменения бизнес-требования | ## OWD: Решение, определяющее все остальное OWD — это не просто техническая настройка безопасности, это организационное заявление о том, кто является первичным владельцем информации. Практическое правило: OWD устанавливается по самому строгому требованию, и уже от него открывается доступ с помощью Sharing Rules, а не наоборот. Причина: расширение точечного доступа легко и документируется, тогда как сокращение уже существующего доступа требует организационной коммуникации, поскольку пользователи воспринимают потерю доступа как ущемление, даже если это исправление исторической ошибки. Момент, который не всегда получает достаточно внимания: OWD настраивается отдельно для каждого объекта, а зависимые объекты (Master-Detail) наследуют видимость от главного объекта. При построении новой модели данных необходимо проверить полную цепочку зависимостей перед установкой OWD — в противном случае «вторичный» объект, ошибочно установленный как Public, раскроет через себя информацию из главного объекта. ## Role Hierarchy по сравнению с фактической управленческой структурой Наиболее распространенная ошибка — копирование организационной диаграммы в Role Hierarchy без проверки, отражает ли она также поток владения данными. Региональный менеджер должен видеть возможности своей команды — это управленческая роль. Но финансовый директор не должен автоматически видеть каждое обращение в службу поддержки только потому, что он находится выше в общей иерархии; если такая потребность существует, она решается с помощью целенаправленного Sharing Rule, а не чрезмерно широкой иерархии. Иерархия совместного доступа, отличная от организационной иерархии отчетности, является легитимным и иногда предпочтительным решением, особенно в организациях с матричной структурой, где управленческая отчетность не соответствует владению данными клиентов. ## Матрица решений: что активирует каждый механизм совместного доступа * **Потребность изменяется в зависимости от фиксированной и предсказуемой роли** → Role Hierarchy. * **Потребность является общей для рабочей группы, которая охватывает различные роли** → Public Group + Sharing Rule. * **Потребность изменяется в зависимости от состава команды в отдельной записи** → Account Team или Case Team. * **Потребность зависит от комбинации динамических условий (география, продукт, размер клиента)** → Territory Management. * **Потребность вытекает из расчета, внешнего события или условия, которое невозможно выразить статическим правилом** → Apex Managed Sharing. * **Потребность является точечным и временным исключением для отдельной записи** → Manual Sharing под контролем и с документацией. Эта матрица должна быть составлена до начала работы с инструментами, а не параллельно с ней — в противном случае мы выберем механизм исходя из того, что знакомо команде разработчиков, а не исходя из потребностей. ## Иллюстративный сценарий: Производитель промышленного оборудования с тремя каналами продаж Представим гипотетического производителя промышленного оборудования с примерно 180 пользователями Salesforce, работающего по трем каналам: прямые продажи по географическим регионам, продажи через дистрибьюторов и продажи глобальным стратегическим клиентам, которые управляются параллельно несколькими представителями в разных странах. Первоначальная попытка использовать только Role Hierarchy потерпела неудачу: глобальный стратегический клиент не относился к одной региональной иерархии, и представитель в Германии не видел обновлений от коллеги в Бразилии по тому же клиенту. Выбранное решение объединило три слоя: OWD для Account и Opportunity был установлен как Private; Role Hierarchy использовалась для обычного управленческого доступа внутри каждого региона; для стратегических клиентов была настроена динамическая Account Team, которая автоматически обновлялась с помощью Flow при изменении поля "Strategic Account Owner Region". Дистрибьюторы получили отдельный доступ через Sharing Rule на основе специальной Public Group, чтобы они не имели доступа к прямым продажам. Результат: время расчета Sharing Recalculation оставалось стабильным, поскольку большая часть доступа определялась фиксированной структурой (Role, Public Group) и лишь меньшинство клиентов — стратегические — зависело от динамического обновления. Основной урок: не существует одного «правильного» механизма для всей организации; необходимо адаптировать механизм к типу зависимости каждой подгруппы записей. Дополнительная информация о выборе шаблонов интеграции и поддерживающей модели данных приведена в [руководстве по архитектуре CRM](/ru/insights/crm-architecture-guide). ## Специфические риски планирования видимости и превентивные меры | Риск | Как проявляется на практике | Превентивные меры | |---------------------------------------------------|------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------| | OWD «временно» открыт на этапе пилота | Открытие сохраняется и после полного запуска системы в эксплуатацию | Заранее установить дату закрытия и задокументировать ее как пункт Go-Live, а не как рекомендацию | | Множество пересекающихся Sharing Rules | Невозможно точно определить, почему пользователь видит определенную запись | Стандартизированное название для каждого правила, включающее бизнес-причину, и периодический пересмотр неиспользуемых правил | | Apex Sharing без нагрузочного тестирования | Задержка в расчете доступа при увеличении объема данных | Провести нагрузочное тестирование на Sharing Recalculation до увеличения объема записей в Production вдвое | | Иерархия совместного доступа, скопированная из политической организационной иерархии | Менеджеры видят данные, в которых у них нет бизнес-потребности | Разделять иерархию ролей для целей совместного доступа от официальной иерархии отчетности, когда они не идентичны | | Manual Sharing, накапливающийся без владельца | Исключительные разрешения остаются после того, как причина совместного доступа перестала быть актуальной | Процесс истечения срока действия (Expiration) или ежеквартальный пересмотр ручных совместных доступов | | Изменение роли пользователя без обновления публичных групп | Старый доступ остается открытым, а новый отсутствует | Интегрировать обновление групп и ролей как единый шаг в процессе изменения статуса сотрудника | ## Контрольный список перед завершением модели совместного доступа * _x_ OWD настроен в соответствии с самыми строгими требованиями, а не удобством этапа разработки. * _x_ Проверена цепочка зависимостей между объектами Master-Detail относительно OWD главного объекта. * _x_ Role Hierarchy проверена на соответствие реальному владению данными, а не только организационной диаграмме. * _x_ Каждое Sharing Rule имеет документированную бизнес-причину и владельца, отвечающего за его актуальность. * _x_ Проверена необходимость Territory Management на практике или его излишняя сложность. * _x_ Код Apex Sharing протестирован на реальном объеме данных, а не только в небольшом Sandbox-окружении. * _x_ Существует процесс обновления публичных групп и разрешений при изменении роли или увольнения сотрудника. * _x_ Установлен периодический график проверки Manual Sharing и неактивных Sharing Rules. * _x_ Оценено влияние модели совместного доступа на производительность отчетов и больших пакетных операций. * _x_ Существует план реагирования на случай обнаружения избыточного раскрытия данных в Production. ## Как узнать, выдерживает ли модель нагрузку Первый показатель — время Sharing Recalculation после структурных изменений: последовательный рост со временем сигнализирует о том, что модель приближается к неучитываемой сложности. Второй показатель — количество обращений в службу поддержки типа "у меня нет доступа" против "у меня есть лишний доступ": резкое отклонение в одну сторону указывает на то, что OWD или Sharing Rules настроены некорректно. Третий показатель, особенно важный в организациях с множеством систем, — это соответствие разрешений Salesforce разрешениям в синхронизированных системах — особенно когда речь идет об архитектуре интеграции, основанной на событиях, как описано в [руководстве по Event-Driven Architecture в Salesforce](/ru/insights/salesforce-event-driven-architecture). В организациях, использующих несколько Org, вопрос модели совместного доступа часто смешивается с вопросом о том, нужна ли вообще более одной производственной среды — полное обсуждение этого вопроса представлено в [Salesforce Single Org против Multi Org](/ru/insights/salesforce-single-org-vs-multi-org) и в выборе соответствующего шаблона интеграции в [руководстве по шаблонам интеграции Salesforce](/ru/insights/salesforce-integration-patterns). ## Заключение Хорошая модель совместного доступа и видимости измеряется не в день запуска, а когда организация растет, когда пользователь меняет роль, и когда кто-то спрашивает: "Почему я этого не вижу?". Путь к этому состоит не в выборе одного инструмента и применении его ко всему, а в сопоставлении каждой группы записей по типу ее зависимости — постоянной, горизонтальной, динамической или исключительной — и выборе подходящего механизма для каждой. Закрытый OWD по умолчанию, Role Hierarchy, отражающая реальное владение данными, Sharing Rules с документированной причиной и Apex Sharing только тогда, когда логика это оправдывает, — это комбинация, которая выдержит, даже когда организация удвоится в объеме и сложности. ### Вопросы и ответы **Можно ли начать с открытых OWD и закрыть их позже?** Технически это возможно, но на практике почти всегда приводит к обратным результатам: как только пользователи и отчеты привыкают видеть всё, любое последующее ограничение воспринимается как ущемление и вызывает сопротивление. Правильный подход противоположен — начинать с закрытого доступа и открывать его точечно с помощью Sharing Rules при возникновении реальной необходимости. **Когда следует использовать Sharing Rule, а когда Apex Managed Sharing?** Sharing Rule подходит, когда критерий совместного доступа определяется фиксированным полем или принадлежностью к определенной роли/публичной группе. Apex Sharing требуется, если критерий зависит от логики, изменяющейся во время выполнения, например, совместный доступ, основанный на комбинации полей, результате вычислений или событии во внешней системе. **Оправдывает ли Territory Management свою сложность в средней организации?** Как правило, нет, если не выполняется хотя бы одно из следующих условий: распределение клиентов изменяется по нескольким параметрам одновременно (география, отрасль, размер), требуется параллельный доступ нескольких представителей к одной записи, или организационная иерархия и иерархия совместного доступа перестали быть идентичными. В остальных случаях Role Hierarchy и Sharing Rules достаточны и проще в обслуживании. **Как определить, что модель совместного доступа перестала соответствовать потребностям организации?** Практические признаки: увеличение времени пересчета Sharing Recalculation от запуска к запуску, повторяющиеся обращения в службу поддержки типа «я не вижу запись, которую должен видеть», растущее использование точечного Manual Sharing в качестве обходного решения, и жалобы на то, что управленческие отчеты показывают разные данные в зависимости от того, кто их запускает. **Что происходит с моделью совместного доступа при перемещении пользователя между ролями или отделами?** Любое изменение роли запускает пересчет совместного доступа Role Hierarchy, и если существуют Sharing Rules, основанные на публичных группах, необходимо убедиться, что пользователь был обновлен и там — эти два механизма не синхронизируются автоматически. Организация, которая часто меняет структуру, нуждается в определенном процессе, включая проверку того, что старый доступ был заблокирован, а не только открыт новый. --- ## Комплексная обработка ошибок и мониторинг интеграций Salesforce URL: https://hpi.pro/ru/insights/salesforce-integration-error-handling Большинство сбоев интеграции, с которыми сталкиваются клиенты, вызваны не отказом API, а незаметным сбоем сообщения, который никто не заметил. В статье рассматриваются четыре уровня обработки ошибок: идемпотентность, повторные попытки (Retry), очереди недоставленных сообщений (Dead Letter) и сверка (Reconciliation). Мы покажем, где каждый из них дает сбой на практике. ## Почему тестовая интеграция «работает», а в реальной среде молчаливо выходит из строя При стандартном приемочном тестировании отправляется одно сообщение, проверяется его доставка, и это считается подтверждением. В реальной среде эта же интеграция обрабатывает тысячи сообщений в день, и некоторые из них неизбежно дают сбой — из-за превышения времени ожидания, блокировки строк, аннулированных разрешений или изменения схемы во второй системе. Вопрос, определяющий качество решения, заключается не в том, «работает ли интеграция», а в том, «что происходит, когда она не работает, и кто это замечает». Большинство дорогостоящих сбоев, с которыми я сталкивался, были вызваны не ошибками в самом коде интеграции, а отсутствием трех возможностей: обнаружение неудачной обработки сообщения, механизм повторной попытки без дублирования записей и процесс, обеспечивающий соответствие данных в обеих системах к концу дня. Без этих возможностей любая интеграция «работает» ровно до того момента, когда выясняется, что она не работала уже две недели. ## Четыре уровня правильной обработки ошибок | Уровень | Что решает | Типичный сбой без него | |---|---|---| | Идемпотентность | Повторный запуск того же сообщения не приводит к дублированию записи | Дублирование заказа или движение запасов после повторной попытки | | Повторная попытка с экспоненциальной задержкой | Временный сбой (таймаут, ограничение скорости) исправляется автоматически | Моментальная перегрузка перерастает в постоянную проблему | | Dead Letter Queue (очередь недоставленных сообщений) | Не временный сбой фиксируется и не исчезает бесследно | Сообщение «поглощается», и стороны считают, что оно обработано | | Бизнес-сверка | Выявляются расхождения в данных, которые не были явно зафиксированы как сбой | Ежемесячный отчет обнаруживает расхождения, источник которых уже трудно восстановить | Каждый уровень зависит от предыдущего. Повторная попытка без идемпотентности создает дубликаты; Dead Letter без бизнес-сверки скрывает тот факт, что даже «технически» успешные сообщения не всегда отражают корректное бизнес-состояние. ## Идемпотентность: ключ к предотвращению дублирования Любая интеграция, которая может получить одно и то же сообщение более одного раза — а это почти все такие интеграции — нуждается во внешнем уникальном ключе (External ID), который идентифицирует событие, а не только запись. В Salesforce обычно реализуется Upsert по полю External ID с ограничением уникальности, в сочетании с таблицей логов (Custom Object или Platform Event Log), которая регистрирует, какие идентификаторы событий уже были полностью обработаны. Распространенная ошибка: ограничиваться Upsert'ом только самой бизнес-записи (например, External ID заказа) без документирования промежуточных этапов. Если процесс также включает обновление запасов во внешней системе, Upsert заказа не предотвращает дублированный вызов обновления запасов. Каждая под-операция с внешним побочным эффектом должна быть идемпотентной сама по себе, а не только финальная запись. ## Повторная попытка: политика экспоненциальной задержки и классификация ошибок Не каждая ошибка заслуживает повторной попытки. Необходимо заранее разделить ошибки на три категории: - **Временные ошибки** (таймаут, 503, ограничение скорости) – кандидаты на повторную попытку с экспоненциальной задержкой, то есть интервал между попытками увеличивается (например, 30 секунд, 2 минуты, 10 минут), чтобы не усугублять нагрузку. - **Структурные ошибки** (отсутствие обязательного поля, нарушение правила валидации, недопустимое значение) – не будут подвергаться повторной попытке, поскольку они снова завершатся сбоем таким же образом. Они должны напрямую переходить в Dead Letter. - **Ошибки авторизации или конфигурации** (истекший токен, изменение версии API) – требуют немедленного оповещения технической команды, поскольку они блокируют всю очередь, а не только отдельное сообщение. В Salesforce повторная попытка обычно реализуется на уровне промежуточного ПО или в Apex Queueable/Batch с сохранением счетчика попыток на самой записи. Разумное количество попыток для большинства случаев составляет 3-5 с экспоненциальной задержкой, а не бесконечная повторная попытка – безграничная повторная попытка превращает временный сбой в постоянную нагрузку на обе системы. ## Dead Letter Queue: где «живут» неудачные сообщения Dead Letter – это не просто место хранения, это контракт. Каждое сообщение, попадающее туда, должно содержать: оригинальный идентификатор события, полный Payload, классифицированную причину сбоя, количество выполненных попыток и время поступления в очередь. Без этой информации «обработка» Dead Letter становится угадыванием. Два распространенных подхода к реализации в Salesforce: 1. **Целевой пользовательский объект** (`Integration_Failed_Message__c`) со структурированными полями и списковым представлением по типу ошибки – подходит, когда требуется прозрачность для бизнес-команды внутри самой Salesforce. 2. **Внешняя очередь на уровне промежуточного ПО** (например, Dead Letter Exchange в MuleSoft/Boomi) – подходит, когда техническая команда мониторит за пределами Salesforce и хочет избежать нагрузки на Org. Выбор зависит от того, кто должен реагировать на сбой: если это владелец бизнес-процесса, он должен видеть это в Salesforce; если это техническая команда интеграции, предпочтительнее внешний уровень. ## Бизнес-сверка: проверка, выявляющая упущения, которые не обнаружил механизм повторных попыток Даже при идеальной идемпотентности и повторных попытках существуют сбои, которые «успешно» завершаются с технической точки зрения, но создают бизнес-разрыв — например, сообщение было получено и обработано, но с неверным значением, полученным из устаревшего источника данных. Сверка – это периодический процесс (ежедневный, ежечасный, в зависимости от частоты событий), который сравнивает количество или общую сумму между двумя системами – например, количество заказов, созданных в ERP, с количеством заказов, созданных в Salesforce за тот же день – и выявляет расхождения до того, как они превратятся в проблему обслуживания клиентов. Хороший процесс сверки не требует полей для проверки каждой записи; достаточно контрольной суммы или накопительного счетчика, который сигнализирует, когда необходимо перейти к детальному анализу. В большинстве организаций ежедневной частоты достаточно; в финансовых или критически важных процессах (заказы, счета) требуется проверка в течение нескольких часов. ## Структура принятия решений: когда каждый слой является обязательным, а когда его можно пропустить | Критерий | Идемпотентность обязательна | Автоматическая повторная попытка обязательна | Отдельная очередь Dead Letter обязательна | Ежедневная сверка обязательна | |---|---|---|---|---| | Событие создает финансовую проводку или изменение запасов | Да | Да | Да | Да | | Событие одностороннее, только для чтения (Read) | Не критично | Да | Нет | Нет | | Объем более 500 сообщений в день | Да | Да | Да | Рекомендуется | | Внешний партнер без высокого SLA доступности | Да | Да, с длительной задержкой | Да | Рекомендуется | | Интеграция между двумя нефинансовыми объектами при небольшом объеме | Рекомендуется | Рекомендуется | Не обязательно | Нет | Правило, лежащее в основе таблицы: чем больше сбой имеет финансовые или необратимые последствия (отгрузка, выставление счета, обновление запасов), тем больше все четыре уровня переходят из «желательных» в «обязательные» — независимо от объема. ## Пример сценария: розничный торговец с двусторонней синхронизацией заказов Розничная компания с 40 филиалами использует Salesforce для управления B2B-заказами и внешнюю ERP-систему для управления запасами и счетами. Интеграция изначально была построена на простом REST-вызове: когда заказ создается в Salesforce, синхронный вызов создает его в ERP. Без повторных попыток, без Dead Letter. В период пиковой нагрузки (Черная пятница) ERP-система начала возвращать таймаут примерно в 3% запросов. Без механизма повторных попыток эти 3% просто «исчезли» – заказ оставался в Salesforce со статусом «отправлено», хотя ERP-система не знала о нем. За два дня накопилось около 140 заказов, которые не поступили в процесс упаковки и были обнаружены только тогда, когда клиенты стали звонить, чтобы узнать, где их товар. Решение, разработанное после этого: уровень Queueable в Apex, который повторяет попытку до 5 раз с экспоненциальной задержкой в 1/5/15/30/60 минут; поле `ERP_Sync_Status__c` со значениями Pending/Synced/Failed; пользовательский объект `Integration_Failed_Message__c`, который агрегирует окончательные сбои с кнопкой «повторить» для операционной команды; и ежедневный отчет о сверке, который сравнивает количество заказов между системами и отправляет оповещение в Slack, когда разница превышает ноль. Время обнаружения аналогичного сбоя сократилось с двух дней до менее чем часа. ## Распространенные риски и профилактические меры | Риск | Как проявляется на практике | Профилактическая мера | |---|---|---| | Бесконечная повторная попытка при структурной ошибке | Одно и то же сообщение постоянно терпит неудачу и создает нагрузку | Заранее классифицировать ошибки и отправлять структурные ошибки сразу в Dead Letter | | Отсутствие уникального идентификатора события | Повторная попытка или дублирующий вызов создают дублирующую запись | External ID для события, а не только для конечной записи | | Dead Letter без владельца | Сообщения накапливаются, и никто их не закрывает | Назначить владельца и SLA обработки по типу события, а не по системе | | Только технический мониторинг (статус API) | Интеграция «зеленая», но бизнес-данные не совпадают | Добавить сверку, которая сравнивает бизнес-результат, а не только код ответа | | Постоянная и слишком короткая задержка | Повторные попытки усугубляют нагрузку во время обширного сбоя | Экспоненциальная задержка с установленным максимальным количеством попыток | ## Контрольный список перед утверждением дизайна обработки ошибок - ☐ Каждое событие имеет уникальный ключ (External ID), предотвращающий дублирование при повторном запуске. - ☐ Ошибки заранее классифицированы на временные/структурные/авторизационные, с различной обработкой для каждого типа. - ☐ Определена политика экспоненциальной задержки с максимальным количеством попыток. - ☐ Существует доступная очередь Dead Letter с полным Payload и причиной сбоя. - ☐ Определены владелец и SLA обработки для каждого типа сбоя. - ☐ Существует периодический процесс сверки, сравнивающий бизнес-результат между системами. - ☐ Оповещения приходят по каналу, который кто-то реально читает (не только в лог). - ☐ Тестовый сценарий включает отключение сервиса второй системы, а не только успешный путь. ## Как это связано с остальной архитектурой Разработка обработки ошибок не является изолированной функцией — она опирается на уровень данных и разрешений, определенный в [Руководстве по архитектуре CRM](/ru/insights/crm-architecture-guide), и на решение о том, реализуется ли логика в Flow или Apex в соответствии с [Salesforce Flow или Apex](/ru/insights/salesforce-flow-vs-apex). Модель разрешений, через которую компоненты интеграции записывают данные, должна быть проверена на соответствие [модели разрешений Salesforce](/ru/insights/salesforce-permission-model), чтобы технический пользователь интеграции не получал слишком широкий доступ. И когда объем сообщений возрастает, вопрос повторных попыток непосредственно пересекается с ограничениями API, подробно описанными в [Salesforce API Limits](/ru/insights/salesforce-api-limits-resilience). ## Заключение Обработка ошибок интеграции – это не функция, которую добавляют в конце, это разница между системой, которая оказывается сломанной после жалобы клиента, и системой, которая предупреждает о себе до накопления ущерба. Четыре уровня – идемпотентность, классифицированная повторная попытка, Dead Letter с владельцем и бизнес-сверка – не требуют отдельного проекта, но требуют четкого решения на этапе планирования, прежде чем первая интеграция выйдет в рабочую среду. Организация, которая предупреждает себя о 3% неудачных сообщений в течение часа, существенно отличается от организации, которая узнает об этом от разгневанного клиента. ### Вопросы и ответы **В чем разница между автоматическими повторными попытками (Retry) и очередью недоставленных сообщений (Dead Letter Queue)?** Повторные попытки (Retry) предназначены для повторной обработки вызова, который временно завершился неудачей (например, по таймауту, из-за блокировки строки, ограничения скорости), в соответствии с определенной политикой отсрочки (Backoff). Если количество попыток исчерпано или ошибка классифицируется как необратимая (например, отсутствует обязательное поле), сообщение перемещается в Dead Letter Queue — место, где оно ожидает ручной или отдельной автоматической обработки, не блокируя остальную часть очереди. **Как обеспечить идемпотентность, если внешняя система отправляет одно и то же сообщение дважды?** Необходим внешний уникальный идентификатор (External ID), который идентифицирует событие, а не только запись, а также проверка существования перед созданием – Upsert по тому же ключу. Если событие также включает финансовую операцию или изменение запасов, требуется отдельная таблица логов, которая регистрирует уже обработанные идентификаторы событий, чтобы повторный запуск не приводил к двойной операции. **Как долго сообщение может находиться в очереди Dead Letter, прежде чем оно станет бизнес-проблемой?** Универсального ответа нет – это зависит от процесса. Заказ, который не синхронизирован в течение часа, может привести к двойной доставке; обновление контактных данных может подождать день. Практическое правило состоит в том, чтобы устанавливать SLA для обработки в соответствии с типом события, а не с типом системы, и убедиться, что это SLA преобразуется в реальное оповещение, а не просто в строку в логе. **Кто несет ответственность за застрявшее сообщение — команда Salesforce или команда другой системы?** Операционная ответственность должна лежать на том, кто поддерживает уровень интеграции, а не на одной из двух систем отдельно. Если такого уровня нет и сообщение передается по принципу точка-к-точке, необходимо заранее определить таблицу эскалации: какой тип ошибки направляется команде Salesforce, какой — владельцу внешнего API, и кто принимает решение в случае неясностей. **Решает ли Middleware автоматически проблему обработки ошибок?** Нет. Инструменты Middleware (такие как MuleSoft, Boomi или другие платформы iPaaS) предоставляют инфраструктуру для Retry, Queue и мониторинга, но политику Backoff, классификацию ошибок и бизнес-сверку все же должна определить организация. Инструмент без политики генерирует подробный лог сбоев, которые никто не устраняет. --- ## Технический долг во Flows и Apex: как выявить и сократить без остановки разработки URL: https://hpi.pro/ru/insights/salesforce-flow-apex-technical-debt Технический долг в автоматизации Salesforce возникает не из-за ошибочного выбора между Flow и Apex, а сотнями мелких решений, принятых без общей стратегии и долгосрочного видения. В статье показано, как выявить его на практике — используя данные, а не интуицию — и как построить план сокращения, который не замедлит темпы разработки. ## Почему технический долг в автоматизации отличается от обычного технического долга В Salesforce накопить технический долг проще, чем в обычной среде разработки, поскольку платформа позволяет любому добавлять автоматизацию без прохождения упорядоченного процесса кодирования. Любой администратор, добавляющий Flow Before Save для решения точечной проблемы, любой триггер, который кто-то добавил два года назад и никто не помнит, зачем, и любое поле формулы, зависящее от уже несуществующего поля — все это накапливается в слое, который никто не видит целиком. Фундаментальное различие между обычным техническим долгом и техническим долгом в автоматизациях Salesforce заключается в том, что последний почти всегда не имеет централизованной документации. Код хранится в репозитории с историей коммитов; Flow находится в настройках без объяснения причин его создания. Это делает этап идентификации экстремально сложным – не потому что проблема технически сложна, а потому что не у кого спросить. Эта статья посвящена выявлению, измерению и сокращению этого долга. В ней не обсуждается вопрос о том, когда изначально выбирать Flow и когда Apex — этому посвящена статья [Flow против Apex: как выбирать](/ru/insights/salesforce-flow-vs-apex). ## Три типа долга, которые ведут себя по-разному Не весь технический долг одинаков, и однообразное отношение ко всем проблемам приводит к напрасной трате усилий. Целесообразно разделить долг на три категории: | Тип долга | Типичный пример | Что произойдет, если игнорировать | Приоритет устранения | | --- | --- | --- | --- | | Структурный долг | Несколько триггеров на одном объекте без унифицированного фреймворка | Непредсказуемый порядок выполнения, скрытый сбой | Высокий | | Логический долг | Flow с десятками ветвей решений, представляющий бизнес-правило, которое уже изменилось | Ошибочные решения, выполняющиеся незаметно | Высокий | | Эксплуатационный долг | Поля, Flow и константы без документации или использования | Увеличение времени разработки, страх вносить изменения | Средний | Структурный и логический долг создают реальный операционный риск — они могут привести к неверным данным, поступающим клиентам или в финансовые отчеты. Эксплуатационный долг замедляет работу команды, но не обязательно нарушает процесс. Это разделение определяет порядок действий: сначала устраняется операционный риск, затем улучшается скорость разработки. ## Как выявить долг до того, как он проявится на этапе производственной эксплуатации Идентификация не должна начинаться с трудоемкого ручного обзора кода — это слишком дорого и неустойчиво. Она начинается с нескольких количественных показателей, которые можно получить в течение часа: - **Количество активных Flows на каждом из ключевых объектов** (Lead, Opportunity, Case и т. п.). При наличии более пяти-шести активных Flows на одном объекте порядок выполнения становится трудно предсказуемым. - **Количество триггеров, не объединенных в единый фреймворк**, для каждого объекта. Более одного триггера на объект уже является предупреждающим знаком, если только нет явного уровня маршрутизации. - **Плотность SOQL-запросов внутри циклов**, проявляющаяся в логах как приближение к лимитам Governor, даже если они фактически не превышены. - **Необычное время выполнения Flow или Apex Batch**, которое увеличивается со временем без пропорционального роста объемов бизнеса. - **Поля и переменные, не имеющие идентифицированного использования** в отчете Field Usage, которые остаются «на случай, если кому-то понадобятся». Эти метрики не доказывают однозначную проблему, но они предоставляют сфокусированный список подозреваемых. Их сочетание с глубоким пониманием интеграций, от которых зависит автоматизация, подробно описано в [Шаблоны интеграции Salesforce](/ru/insights/salesforce-integration-patterns). ## Рамочное решение: что обрабатывать в первую очередь Не все элементы в списке подозреваемых требуют одинаковых инвестиций. Простая система приоритизации основана на двух осях — влиянии на бизнес и вероятности сбоя: | Ситуация | Бизнес-влияние в случае сбоя | Вероятность сбоя в ближайшем будущем | Действие | | --- | --- | --- | --- | | Автоматизация процесса заказа/выставления счетов с множеством недокументированных триггеров | Высокое | Высокая | Немедленный рефакторинг, вне обычного графика | | Сложный Flow на внутреннем обновлении статуса без внешнего воздействия | Низкое | Высокая | Документирование и упрощение в обычном темпе | | Старый триггер, который работает стабильно, но его назначение неясно | Потенциально высокое | Низкая | Сначала документирование, немедленно не трогать | | Неиспользуемые поля и осиротевшие константы | Низкое | Низкая | Периодическая очистка на уровне релиза | Основное правило: не следует решать проблемы, исходя из того, что больше всего беспокоит разработчиков, а ориентироваться на то, что наиболее опасно для бизнеса. Старый и стабильный триггер, который никто не понимает, иногда является самым заманчивым объектом для устранения первым — и это именно тот случай, когда неосторожное вмешательство приводит к наибольшему ущербу. ## Организационный сценарий: страховая компания с 14 Flows на Opportunity Предположим, средняя страховая компания управляет B2B продажами через Salesforce уже шесть лет. За это время накопилось 14 активных Flows на объекте Opportunity: семь обрабатывают обновления этапов, три отправляют внутренние уведомления, два синхронизируют данные с внешним инструментом BI, и еще два являются остатками старого процесса, который был заменен два года назад, но никогда не был деактивирован. Поводом для выявления проблемы стал конкретный сбой: сделка перешла в статус «Закрыто-Выиграно», но уведомление команде андеррайтеров не было отправлено, потому что другой Flow одновременно обновил то же поле и создал незапланированную последовательность выполнения. Команда провела два дня, пытаясь понять, почему — не потому что баг был сложным, а потому что никто не знал полного порядка выполнения всех 14 компонентов. Решение не заключалось в «переписывании всего с нуля на Apex». Команда сначала отобразила все 14 Flows и классифицировала их согласно приведенной выше таблице: два старых Flows были отключены после проверки отсутствия активных зависимостей, три уведомления были объединены в один Flow с четкой логикой маршрутизации, а семь обновлений этапов были объединены под одним Record-Triggered Flow с явно заданным порядком выполнения. Результат: от 14 компонентов до 6, с документированным порядком выполнения, который любой новый разработчик может понять за четверть часа. ## Риски в процессе сокращения Сокращение технического долга — это действие, связанное со своими собственными рисками, а не только исправление существующего риска: | Риск | Как он выглядит на практике | Меры предотвращения | | --- | --- | --- | | Изменение порядка выполнения нарушает скрытую зависимость | Процесс, который работал, перестает работать после объединения Flows | Полное отображение зависимостей и регрессионное тестирование перед каждым объединением | | Удаление "мертвого" компонента, который на самом деле все еще выполняется в редком сценарии | Отказ, проявляющийся только в конце квартала или в сезонном крайнем сценарии | Проверка журналов выполнения за полный год, а не только за последний месяц | | Преобразование в Apex без владельца процесса, понимающего бизнес-правило | Новый код "технически правильный", но реализует старое правило, которое уже изменилось | Проверка бизнес-правила с владельцем процесса перед написанием кода, а не только по существующему коду | | Рефакторинг, выполненный в одной песочнице и не синхронизированный | Проблема возвращается в производственной среде после следующего развертывания | Управление изменением через обычный процесс релиза, а не как "внеплановое" исправление | Общим риском для всех является одно и то же явление: команда уверена, что она «просто убирается» и поэтому пропускает тесты, которые она провела бы для новой функции. На уровне управления рефакторинг должен пройти тот же процесс приемки, что и обычная разработка — не меньше. ## Показатели для постоянного мониторинга сокращения Чтобы убедиться, что усилия действительно уменьшают долг, а не просто перемещают его, стоит отслеживать следующее: - **Количество активных компонентов автоматизации на объект**, как квартальный тренд, а не точечный показатель. - **Среднее время диагностики отказа автоматизации**, от момента сообщения до выявления ответственного компонента. - **Процент документированных компонентов** от общего числа активных автоматизаций в основном кластере. - **Количество повторяющихся сбоев одного и того же компонента** в течение трех месяцев. Организации, которым трудно расставлять приоритеты между рефакторингом и текущей разработкой, используют [услугу CRM-архитектуры](/ru/crm-architecture) для создания обязательного и измеримого плана работ. ## Операционный чек-лист перед началом рефакторинга - ☐ Существует полная карта всех активных автоматизаций на соответствующем объекте. - ☐ Известен фактический порядок выполнения, а не только порядок создания. - ☐ Каждый компонент, предназначенный для удаления, проверен по журналам выполнения за полный год. - ☐ Владелец бизнес-процесса утвердил заново реализуемое правило. - ☐ Существует тестовая среда, имитирующая реальный объем данных. - ☐ Определены метрики «до и после» для количества компонентов и времени диагностики. - ☐ Процесс рефакторинга проходит через обычный релиз, а не через внеплановое развертывание. - ☐ В каждом спринте выделена постоянная емкость для непрерывного обслуживания, а не только для разового события. ## Заключение Технический долг в автоматизациях Salesforce накапливается незаметно, по одному компоненту за раз, поэтому и устранять его нужно незаметно — не в большом проекте по очистке, который останавливает разработку на месяц. Необходимые инструменты относительно просты: подсчет компонентов по объектам, отображение порядка выполнения и классификация по бизнес-влиянию относительно вероятности сбоя. Успех определяется непрерывностью — выделением постоянного ресурса для сокращения долга наряду с текущей разработкой, а не точечным устранением компонента, вызвавшего последний сбой. Организация, которая принимает такую практику измерения, достигает состояния, когда любой новый разработчик может за час понять, что происходит при сохранении записи — и это, в конечном итоге, самое практичное определение отсутствия технического долга. ### Вопросы и ответы **Сколько Flows на одном объекте считается "слишком много"?** Не существует магического числа, но есть четкий признак: если разработчик не может предсказать, что произойдет при сохранении записи, не открывая весь список Flow и не отслеживая порядок их выполнения, уже существует операционная проблема — даже если речь идет всего о трех Flows. Проблема не в количестве, а в отсутствии координации и документирования порядка их выполнения. **Можно ли сократить технический долг, не останавливая разработку новых функций?** Да, и, как правило, это правильный путь. Выделяйте фиксированный процент каждого спринта — например, десятую часть ресурсов — на сокращение долга согласно списку приоритетов, вместо того чтобы запрашивать "спринты заморозки", которые почти всегда откладываются, когда наступает очередь бизнес-приоритетов. **Когда Flow преобразуется в Apex-код из-за технического долга?** Когда Flow содержит запутанную логику с более чем несколькими ветвями решений, когда он вызывает один и тот же запрос несколько раз из-за плохой модульной структуры или когда его необходимо проверять автоматическими тестами, которые графические инструменты не поддерживают должным образом. Сама конвертация является техническим инструментом; решение принимается на основе фактического измерения сложности, а не стилистических предпочтений. **Как измерить технический долг, не оплачивая сторонние инструменты?** Можно начать с Salesforce Optimizer и внутренних отчетов Setup для подсчета активных Flows по объектам, а также запросить Tooling API по лимитам Apex и журналам отладки (Debug Logs) для выявления аномальных времен выполнения. Это не полная замена специализированным инструментам статического анализа, но достаточно для составления первого списка приоритетов. **Что делать, если команда разработки сопротивляется инвестированию времени в рефакторинг?** Представьте стоимость в терминах, понятных руководству: повторяющиеся часы поддержки по одной и той же проблеме, затягивание времени выпуска версии и конкретный риск для ключевого бизнес-процесса. Рефакторинг, представленный как "чистка кода", почти всегда отклоняется; рефакторинг, представленный как снижение операционного риска, получает приоритет. --- ## Модель данных в Salesforce: стандартные объекты, настраиваемые объекты и ключевые решения URL: https://hpi.pro/ru/insights/salesforce-data-model-design Модель данных — это решение, требующее наибольших затрат на изменение после запуска. В руководстве рассматриваются вопросы: когда использовать стандартные объекты, когда оправдан индивидуальный объект, как выбрать между отношением поиска (Lookup) и отношением «главный-подчинённый» (Master-Detail), и как модель, выглядящая чистой на этапе проектирования, впоследствии приводит к ограничениям в отчётности, разрешениях и производительности. ## Краткий ответ Качественная модель данных в Salesforce — это не самая теоретически идеальная модель, а та, которая одновременно поддерживает три аспекта: бизнес-процессы, модель разрешений и необходимую отчетность. Большинство неудачных моделей строились только вокруг первого аспекта. Отличие решения по модели данных от других проектных решений заключается в стоимости изменений. Изменение Flow занимает день; изменение типа связи между объектами после двух лет накопленных данных, автоматизации и интеграций — это отдельный проект. Поэтому инвестиции на этапе планирования здесь окупаются больше, чем где-либо еще. ## Первое правило: начинать со стандартных объектов Account, Contact, Lead, Opportunity, Case и Product обладают возможностями, которые не доступны бесплатно для пользовательского объекта: процессы продаж, прогнозирование, права, Omni-Channel, мобильное приложение и встроенная интеграция с другими продуктами платформы. Организация, которая создает `Customer__c` вместо Account, на начальном этапе получает более чистую модель, но затем обнаруживает, что каждая стандартная функция требует самостоятельной реализации. Правило: отступать от стандарта следует только при наличии причины, которую можно сформулировать одним предложением. ## Когда требуется пользовательский объект | Ситуация | Требуется ли пользовательский объект | Обоснование | | --- | --- | --- | | Контракт/подписка с собственным жизненным циклом | Да | Отдельные статусы, продление, владение и отчетность | | Установленное оборудование у клиента | Да (или стандартный Asset) | Самостоятельная сущность с историей обслуживания | | Дополнительный "потенциальный клиент" | Нет | Это Lead или Account с Record Type | | Отдел в организации | Нет | Данные о пользователе, а не отдельная сущность | | Сложные ценовые позиции | Зависит | Перед созданием рассмотреть Quote Line или CPQ | ## Нормализация против денормализации: решение, влияющее на отчетность В классических базах данных нормализация является достоинством. В Salesforce она обменивается на удобство отчетности: каждый дополнительный уровень связи усложняет построение отчета без внешнего инструмента, поскольку стандартная отчетность ограничена глубиной связей. Принятый компромисс — нормализация там, где данные изменяются и дублируются, и контролируемая денормализация часто используемых полей запросов в объект, из которого формируются отчеты, при условии, что дублирование управляется автоматически, а не вручную. Поле, дублирование которого обновляется вручную, становится некорректным в течение нескольких месяцев. ## Разрешения — часть модели, а не последующий этап Вопрос "кто что видит" должен задаваться на этапе проектирования объектов. Модель, в которой конфиденциальные данные находятся в том же объекте, что и операционные данные, впоследствии заставляет использовать обходные решения — теневой объект, зашифрованные поля или предоставление слишком широкого доступа. Практическая проверка: для каждого нового объекта пишется одна строка — кто владелец, кто читает, кто изменяет и что происходит в иерархии. Если ответ требует более четырех строк, структура, вероятно, смешивает две сущности. Более подробная информация об источниках данных и полномочиях по обновлению представлена в статье [Source of Truth в организации](/ru/insights/salesforce-source-of-truth), а об управлении основными данными — в [Управление основными данными (MDM)](/ru/insights/salesforce-master-data-management). ## Сценарий: компания-разработчик ПО, построившая модель вокруг отделов Средняя SaaS-компания построила модель с четырьмя пользовательскими объектами — по одному для каждой команды продаж — потому что каждая команда имела свой собственный процесс. Полтора года спустя произошло объединение команд, и тогда потребовались: унификация отчетов, параллельная автоматизация в четырех местах и внутренняя миграция 60 тысяч записей между объектами. Перестройка основывалась на одном Opportunity с Record Types для разных процессов. Та же бизнес-логика была сохранена — разные процессы продаж, разные поля, разные Page Layouts — но на уровне конфигурации, а не структуры. Следующее организационное изменение потребует изменения Record Type, а не миграции. Правило, вытекающее из этого: структура представляет сущности; конфигурация представляет организацию. То, что, как ожидается, будет меняться раз в два года, не должно быть частью структуры. ## Производительность и объем — что действительно важно Проблемы с производительностью в модели данных в основном возникают из трех источников: Data Skew (один родитель с десятками тысяч дочерних записей, например, Account "частные клиенты"), вложенные формулы, вычисляемые в реальном времени по связям, и совместное использование на основе Apex Sharing, созданное в большом объеме. Все три могут быть идентифицированы на этапе проектирования, если задать вопрос о предполагаемом количестве записей под каждым родителем. ## Типичные риски и превентивные меры | Риск | Как он проявляется на практике | Превентивные меры | | --- | --- | --- | | Избыточный пользовательский объект | Стандартные функции реализуются вручную | Проверка стандартных объектов перед созданием нового | | Master-Detail слишком рано | Каскадные удаления и неизменяемая структура | Начинать с Lookup, если не требуется Roll-Up | | Модель, отражающая структуру организации | Каждое организационное изменение становится миграцией | Record Types вместо объектов | | Data Skew | Блокировки и замедление при массовых обновлениях | Распределение родительских объектов, оценка объема на этапе планирования | | Разрешения как запоздалая мысль | Обходные решения и слишком широкий доступ | Матрица доступа для каждого объекта на этапе планирования | ## Как измерять успех | Область | Что измеряется | Частота проверки | | --- | --- | --- | | Использование полей | Процент заполнения для каждого поля | Ежеквартально | | Отчетность | Процент отчетов, требующих ручной консолидации | Ежеквартально | | Стабильность структуры | Количество структурных изменений за полгода | Раз в полгода | | Производительность | Время массового обновления и блокировки | Ежемесячно | Проектирование модели данных как части общей архитектуры осуществляется в рамках [услуг интеграции и данных](/ru/integrations-data). ## Контрольный список перед фиксацией модели - ☐ Для каждого пользовательского объекта существует однословное обоснование - ☐ Проверен альтернативный стандартный объект для каждой сущности - ☐ Тип связи явно выбран с обоснованием для Master-Detail - ☐ Оценочный объем для каждого родительского объекта (проверка на Skew) - ☐ Матрица доступа: владелец, читатель, редактор, иерархия - ☐ Проверено, что каждый центральный отчет может быть построен в модели - ☐ Дублированные поля обновляются только автоматически - ☐ Ожидаемые организационные изменения обрабатываются в конфигурации - ☐ Существует актуальная и документированная ERD - ☐ Определен ответственный за утверждение изменений структуры в будущем ## Профессиональные источники - Salesforce Data 360 — https://www.salesforce.com/data/ - Архитектура Salesforce Data 360 — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html - HPI Pro – Интеграции и данные — https://hpi.pro/integrations-data ### Вопросы и ответы **Когда настраиваемый объект оправдан, а когда это ошибка?** Настраиваемый объект оправдан, когда сущность имеет собственный жизненный цикл: статусы, владение, отдельные разрешения и отчётность. Это ошибка, когда он создаётся только для того, чтобы избежать дополнительных полей в существующем объекте, или для отражения организационной структуры. Организационные структуры меняются, а объекты не так легко перемещаются вместе с ними. **Lookup или Master-Detail?** Master-Detail обеспечивает Roll-Up Summary и наследование разрешений, но является жёстким: удаление родительской записи влечёт за собой удаление дочерних, и дочерняя запись не может существовать без родительской. Lookup более гибок и может быть изменён впоследствии. Практическое правило: Master-Detail используется только тогда, когда дочерняя запись действительно бессмысленна без родительской и требуется автоматическое суммирование. **Сколько полей — это слишком много для объекта?** Количество менее важно, чем потребитель. Объект с 200 полями, все из которых используются в отчётах, корректен; объект с 60 полями, большинство из которых пусты в 80% записей, указывает на сущности, сжатые в одно и то же место. Наилучший тест — это процент заполнения для каждого поля, а не их подсчёт. **Следует ли отображать структуру ERP в Salesforce?** Нет. ERP спроектирована вокруг транзакций, Salesforce — вокруг взаимоотношений и процессов. Полное отображение создаёт десятки объектов, которые никто не использует. В Salesforce переносятся только те данные, которые необходимы для процессов продаж и обслуживания, а для остальных используется удалённый доступ или Data 360. **Как понять, что модель не выдержит нагрузки?** Три предупреждающих знака: отчёты, требующие ручного объединения объектов; глубоко вложенные поля формул для преодоления структурных ограничений; и запросы на разрешения, которые невозможно реализовать без обширного расширения видимости. Каждый из этих признаков указывает на то, что структура не соответствует процессу. --- ## Управление основными данными (MDM) с Salesforce: Ответственность, Golden Record и Синхронизация URL: https://hpi.pro/ru/insights/salesforce-master-data-management MDM терпит неудачу, когда рассматривается как технологический проект, и преуспевает, когда определяется как режим управления. Руководство объясняет, какие сущности действительно требуют Master-управления, как создать Golden Record между CRM и ERP без ущерба для систем, когда необходим специализированный инструмент MDM, а когда Salesforce достаточно, а также как измерить эффективность режима. ## Краткий ответ Управление основными данными (Master Data Management – MDM) – это не хранилище, а соглашение. Это соглашение определяет, кто создает сущность, кто имеет право ее изменять, как идентифицировать две записи как одну и ту же сущность, и что происходит при расхождении данных в разных системах. Технология лишь обеспечивает соблюдение согласованных правил. Распространенная ошибка – начинать с выбора инструмента. Организация, которая не определила, что такое "клиент", получит инструмент, который консолидирует ту же неопределенность, только быстрее и дороже. ## Что относится к Master Data, а что нет | Тип данных | Пример | Является Master Data | | --- | --- | --- | | Основные данные (Master Data) | Клиент, продукт, поставщик, адрес | Да | | Справочные данные (Reference Data) | Страны, валюты, отраслевые коды | Отдельное, более простое управление | | Транзакционные данные (Transactional) | Заказ, счет, обращение (Case) | Нет | | Аналитические данные (Analytical) | Сегментация, скоринг, прогноз | Нет – являются производными | Это различие важно, поскольку каждый тип требует особого подхода к управлению. Справочные данные контролируются в небольшой таблице с одним владельцем; транзакционные данные остаются в системе, которая их создает; аналитические данные не должны становиться источником истины, поскольку они являются результатом вычислений, которые могут меняться. ## Три стиля реализации **Registry** – Управление только таблицей идентификаторов, связывающей записи в различных системах. Это дешево, быстро, не требует изменений в существующих системах, и обеспечивает единое представление для чтения. Почти всегда подходит в качестве первого шага. **Consolidation** – Создание "золотой записи" (Golden Record) для целей отчетности и анализа, без обратной синхронизации данных в исходные системы. Подходит, когда основная проблема – дублирующаяся отчетность. **Centralized** – Master Data становится обязательным источником истины, а системы потребляют данные из него. Это обеспечивает наибольшую ценность, но также предъявляет самые высокие требования к управлению данными и процессам утверждения. Организации, которые сразу переходят к этому стилю, обнаруживают, что у них нет ответственных лиц (Stewards) для его поддержания. Практический подход – это постепенное масштабирование: Registry для одной сущности, а затем расширение – на основе доказанной ценности, а не грандиозного плана. ## Survivorship: Правила, определяющие, что сохраняется Ядром Golden Record являются правила Survivorship на уровне полей: для каждого поля определяется предпочтительный источник и резервное правило на случай, если предпочтительный источник пуст. При этом всегда сохраняются идентификаторы из исходных систем, чтобы можно было объяснить каждое значение. Принцип, который помогает избежать споров: Golden Record не удаляет исходные записи и не претендует на их замену. Это слой, который ссылается на них. Это означает, что можно изменить правило и пересчитать данные – возможность, которой нет у тех, кто интегрировал все на стадии загрузки. Дополнительные сведения о принятии решений о владении данными представлены в статьях [Источник истины в организации](https://hpi.pro/insights/salesforce-source-of-truth) и предшествующей ей [Устранение дубликатов в Salesforce](https://hpi.pro/insights/salesforce-data-deduplication). ## Stewardship: Роль, определяющая успешность Любая система MDM генерирует очередь решений: совпадения, в которых система не уверена, запросы на создание новой сущности и противоречия между источниками. Если нет человека, выделяющего время на работу с этой очередью, она будет расти, пока ее не перестанут замечать. Реальный объем: в средней организации это несколько часов в неделю на одну сущность, как правило, для сотрудника из бизнес-подразделения, а не из IT. Именно эти инвестиции определяют, будет ли MDM жить или превратится в "тихую инфраструктуру". ## Сценарий: Производитель с тремя системами и одним клиентом Промышленный производитель хранил данные о клиентах в трех системах: ERP, Salesforce и системе обслуживания. Одна и та же корпорация могла быть представлена как три разные сущности, и отчет "Доход на клиента" составлялся вручную в Excel раз в квартал. Вместо полноценного проекта MDM организация начала с Registry: была создана таблица идентификаторов в Data 360, которая связала три записи с помощью ИНН и вторичного ключа, и только после этого был создан Golden Record для чтения. Salesforce не изменил свою структуру; он получил поле глобального идентификатора и представление "Вся активность по группе". Результат через квартал: ручной отчет был отменен, а менеджеры по продажам впервые увидели кредитное покрытие на уровне группы – что привело к одному решению о ценообразовании, окупившему стоимость начального этапа. Расширение до Centralized рассматривалось только после того, как было доказано наличие ответственного Stewarda, который фактически обрабатывал очередь. ## Распространенные риски и профилактические меры | Риск | Как проявляется на практике | Превентивные меры | | --- | --- | --- | | Начало с выбора инструмента | Объединенное хранилище, отражающее существующую неопределенность | Определения сущностей и ответственных перед выбором инструмента | | Слишком много сущностей | Длительный проект без видимой ценности | Одна сущность до перехода в эксплуатацию, затем расширение | | Отсутствие Stewarda | Очередь совпадений, которая растет и игнорируется | Должность с выделенным временем и SLA | | Деструктивное слияние | Невозможно объяснить или восстановить значение | Сохранение исходных идентификаторов и возможность пересчета | | Преждевременное Centralized | Все системы зависят от незрелой инфраструктуры | Начинать с Registry | ## Как измерять успех | Область | Что измерять | Частота проверки | | --- | --- | --- | | Покрытие | Процент записей, связанных с глобальным идентификатором | Ежемесячно | | Точность | Доля отмененных или исправленных связей | Ежемесячно | | Очередь Stewardship | Количество открытых элементов и среднее время закрытия | Еженедельно | | Бизнес-ценность | Отмененные ручные отчеты, решения на уровне группы | Ежеквартально | Построение многоуровневой системы MDM осуществляется в рамках [услуги по интеграции и работе с данными](https://hpi.pro/integrations-data). ## Контрольный список перед запуском MDM - ☐ Выбрано до трех сущностей для первого этапа. - ☐ Для каждой сущности существует письменное бизнес-определение. - ☐ Выбран стиль реализации: Registry, Consolidation или Centralized. - ☐ Определены надежные ключи идентификации для каждого источника. - ☐ Написаны правила Survivorship на уровне полей. - ☐ Исходные идентификаторы сохраняются и позволяют пересчитывать данные. - ☐ Назначен Steward с выделенным временем и SLA. - ☐ Определен процесс утверждения для создания новой сущности. - ☐ Определен один показатель ценности для первого этапа. - ☐ Принято решение о том, когда рассматривать выделенный инструмент. ## Профессиональные ресурсы - Salesforce Data 360 — https://www.salesforce.com/data/ - Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html - HPI Pro – Интеграции и данные — https://hpi.pro/integrations-data ### Вопросы и ответы **Какие сущности действительно нуждаются в Master-управлении?** Только те, которые появляются в нескольких системах и влияют на финансы, регулирование или клиентский опыт. В большинстве организаций это от трех до пяти сущностей: клиент/поставщик, продукт, организационно-сбытовая структура, а иногда сайт или актив. Попытка управлять 20 сущностями одновременно — самый быстрый путь к тупику. **Требуется ли специализированный MDM-инструмент?** Не всегда. При наличии до трех исходных систем и средней сложности сопоставления Salesforce с внешними идентификаторами (External IDs), правилами сопоставления (Matching Rules) и управляемой интеграцией вполне достаточно. Специализированный инструмент оправдан при множестве источников, формальных требованиях к управлению (Stewardship), необходимости сохранения истории изменений для регулирования или сложной логике выживаемости (Survivorship) на уровне полей. **В чем разница между Registry, Consolidation и Centralized?** Реестр (Registry) хранит только сопоставление идентификаторов, оставляя сами данные в исходном источнике. Консолидация (Consolidation) создает унифицированную копию исключительно для целей отчетности. Централизованная модель (Centralized) превращает базу данных в обязательный источник, из которого все системы считывают информацию. Чем выше по этой шкале, тем больше ценность, но и выше затраты на внедрение и управление. **Может ли Salesforce быть Master-системой для клиента?** Да, если клиент создается в процессе продаж и управляется в Salesforce. В большинстве организаций компромиссом является разделение: юридическая информация и коммерческие условия в ERP, коммерческая сущность и контактные данные в Salesforce, с общим идентификатором, связывающим обе системы. **Сколько времени требуется для получения первой ценности?** Для одной сущности с двумя источниками — от шести до двенадцати недель до получения активного Golden Record в производственной среде. Проекты MDM, запланированные на два года для 'полной инфраструктуры', часто не переживают смену руководства — лучше получить одну сущность в производстве, чем полную архитектуру в презентации. --- ## Data 360 в сравнении с данными CRM в Salesforce: что и где хранить? URL: https://hpi.pro/ru/insights/data-360-vs-crm-data Не все данные, связанные с клиентами, должны храниться в CRM. Наше руководство разграничивает операционные данные, управляющие повседневными процессами, и высокообъемные поведенческие данные, предназначенные для объединения профилей, сегментации и активации. Мы покажем, как это решение влияет на производительность, стоимость, разрешения и возможности использования AI. ## Краткий ответ Выбор между CRM и Data 360 определяется не «тем, где есть место», а «тем, кто и с какой частотой потребляет данные». Система CRM строится вокруг записи, которую кто-либо открывает, редактирует и продвигает в рамках процесса. Data 360 строится вокруг потока событий, который объединяется в профиль и используется для сегментации, анализа и выполнения действий. Смешение этих двух подходов приводит к одному из двух результатов: либо к громоздкой CRM с миллионами записей, к которым никто не прикасается, либо к богатому слою данных, по которому никто не действует, потому что он не интегрирован в рабочие процессы. ## Практическое разделение | Тип информации | Место хранения | Обоснование | |---|---|---| | Клиент, контакт, возможность, обращение | CRM | Управляется вручную, запускает процессы и разрешения | | Этап продажи, задачи, утверждения | CRM | Автоматизация и ежедневные операции | | Клики, просмотры, использование продукта | Data 360 | Высокий объем, не управляется вручную | | История транзакций из ERP | Data 360 (или виртуальный доступ) | Объём и внешний источник достоверных данных | | Единый профиль и сквозная идентификация систем | Data 360 | Функция объединения идентификаторов | | Оценка, сегментация, рекомендация | Рассчитывается в Data 360, отображается в CRM | Расчёт больших объемов, использование в рабочих процессах | Ключевой принцип заключается в следующем: расчёты выполняются там, где есть большой объём данных, а отображение — там, где принимаются решения. ## Тест четырёх вопросов Прежде чем вводить данные в CRM, задайте себе следующие вопросы: Редактирует ли кто-то эти данные вручную? Зависят ли от них автоматизация или валидация? Требуются ли они в текущем операционном отчете? Влияют ли они на разрешения или владение? Если ответ на все четыре вопроса отрицательный, данные почти всегда относятся к слою унификации. Обратное тоже верно: данные, которые хранятся только в Data 360, но необходимы для принятия решений в реальном времени, должны иметь механизм обратной связи — сводное поле, представление или действие — иначе они не повлияют на бизнес-результат. ## Объем, производительность и стоимость CRM ценообразование и проектирование основаны на бизнес-записях. Введение поведенческих событий в систему меняет профиль нагрузки: массовые обновления замедляются, создание отчетов становится ресурсоёмким, а резервное копирование и тестовые среды увеличиваются в размере. Data 360 спроектирован для такой скорости и тарифицируется по потреблению — что требует иного подхода: широкие запросы и избыточные потоки данных порождают постоянные затраты. В обоих случаях гигиена данных одинакова: передавать только то, что имеет потребителя, и определить политику хранения (Retention) для каждого потока. Подробное обсуждение копирования против удалённого доступа приведено в статье [Zero Copy и Federation](/ru/insights/data-360-zero-copy-federation). ## Разрешения: легко упустить из виду Модель разрешений в CRM является богатой и точной на уровне записей и полей. Слой унификации работает иначе — он предназначен для анализа, и его доступность регулируется правилами доступа и масками. Организация, которая передаёт конфиденциальные данные в слой унификации без предварительного планирования, может создать более широкую область видимости, чем в CRM. Правило: каждый поток, содержащий конфиденциальную информацию, получает явное решение о допустимости раскрытия до его передачи, а не после. ## Сценарий: розничный продавец, который перенёс всё в CRM Розничная сеть перенесла трёхлетнюю историю покупок (около 40 миллионов строк) в настраиваемый объект CRM с целью обеспечить «продавцу полную картину». В результате: длительное время загрузки на экране клиента, ночные обновления, выходящие за рамки отведённого окна, и отчёты, которые завершались с ошибкой из-за превышения времени ожидания. При перестройке в CRM остались только четыре производных значения: дата последней покупки, сумма за 12 месяцев, ведущая категория и отметка о риске оттока. Вся полная история была перемещена в слой унификации с возможностью запроса подробного просмотра по требованию. Экран клиента загружался быстро, продавцы получали именно ту информацию, которую они запрашивали, а маркетинговая сегментация улучшилась — потому что она основывалась на данных, которые находились в одном месте, а не только на тех, которые удалось поместить в CRM. ## Типичные риски и профилактические меры | Риск | Как это проявляется на практике | Профилактические действия | |---|---|---| | Всё в CRM | Производительность, стоимость и время загрузки | Производные значения вместо необработанной истории | | Всё в слое унификации | Insights, не достигающие рабочего процесса | Механизм обратной связи: поле, представление или действие | | Отсутствие Retention | Неконтролируемый рост объёма данных | Политика хранения для каждого потока | | Неспланированные разрешения | Раскрытие конфиденциальных данных при анализе | Решение о допустимости раскрытия до передачи данных | | Необъединённая идентификация | Разделённый профиль для одного клиента | Определённые правила Identity Resolution | ## Как измерить успех | Область | Что измеряется | Частота проверки | |---|---|---| | Производительность | Время загрузки экрана клиента и массовых обновлений | Ежемесячно | | Унификация | Процент успешно объединённых профилей | Ежемесячно | | Активация | Фактически созданные сегментации и действия на основе данных | Ежеквартально | | Стоимость | Потребление в сравнении с бюджетом по потокам | Ежемесячно | Планирование разделения между CRM и слоем унификации осуществляется в рамках [сервиса интеграции и данных](/ru/integrations-data). ## Чек-лист для принятия решения - ☐ Картирование потоков данных по объему и частоте обновления - ☐ Тест четырёх вопросов для каждого потока - ☐ Определены производные значения для отображения в CRM - ☐ Существует механизм обратной связи из слоя унификации в рабочий процесс - ☐ Написаны правила Identity Resolution - ☐ Решение о допустимости раскрытия для каждого потока с конфиденциальной информацией - ☐ Политика Retention для каждого потока - ☐ Оценка стоимости потребления для первого этапа - ☐ Выбран один сценарий использования для демонстрации ценности - ☐ Назначен владелец для каждого потока данных ## Профессиональные источники - Salesforce Data 360 — https://www.salesforce.com/data/ - Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html - HPI Pro — Интеграции и данные — https://hpi.pro/integrations-data ### Вопросы и ответы **Какой вопрос определяет, где должны храниться данные?** Действует ли пользователь или автоматизация с этими данными в рабочем процессе? Если да, их место в CRM. Если данные предназначены для сегментации, анализа, объединения профилей или ввода в модель, их место в Data 360. Данные, с которыми никто не взаимодействует и которые никто не анализирует, не должны храниться нигде. **Заменяет ли Data 360 хранилище данных (Data Warehouse)?** Не обязательно. Data 360 специализируется на объединении профилей клиентов и их активации в процессах продаж, обслуживания и маркетинга. Корпоративное хранилище данных продолжает обслуживать широкую финансовую и операционную отчетность. На практике они сосуществуют, иногда связанные виртуальным доступом без дублирования данных. **Нужен ли Data 360 для AI?** Не для каждого использования. Для краткого изложения разговора или формулирования ответа контекста в CRM достаточно. Для рекомендаций, оценки или работы агента, которому нужна обширная история из нескольких систем, требуется уровень объединения данных — и это именно та роль, которую выполняет Data 360. **Что происходит при копировании поведенческих данных в CRM?** Вы начинаете платить дважды: за хранение и за производительность. Миллионы строк событий по настраиваемому объекту замедляют массовые обновления, раздувают индексы и затрудняют отчетность. Типичное решение — сводный подход: хранить в CRM производное значение — оценку, последнюю дату, счетчик — а не сами события. **С чего начать, если CRM уже перегружена?** С выявления трех групп высокообъемных данных с низким операционным использованием и их перемещения на уровень объединения, при этом сводное поле остается в CRM. Это повышает производительность и создает основу для сегментации без необходимости полного проекта по созданию инфраструктуры. --- ## Zero Copy и Data Federation в Data 360: когда не нужно копировать данные URL: https://hpi.pro/ru/insights/data-360-zero-copy-federation Каждое копирование данных влечет за собой обязательства: инфраструктура, затраты, расхождения и риски. Zero Copy позволяет запрашивать данные там, где они находятся, но это не универсальное решение. В данном руководстве мы рассмотрим, когда предпочтителен виртуальный доступ, когда более уместна ингестация данных, и как принять решение, основываясь на таких факторах, как актуальность, производительность, управление данными и стоимость трафика. ## Краткий ответ Классический подход гласил: «Чтобы анализировать данные, сначала их скопируйте». Концепция Zero Copy во многих случаях опровергает это предположение: можно запрашивать таблицу, размещенную во внешнем хранилище данных, без её физического перемещения. Это реальная возможность, но она заменяет один тип затрат другим – вместо затрат на хранение и конвейер возникают затраты на вычисления и зависимость от доступности источника. Решение будет верным, если рассматривать его как любое архитектурное решение: исходя из требований к использованию, а не из модных тенденций. ## Четыре ключевых параметра | Параметр | Склонение к Zero Copy | Склонение к Ingestion | | --- | --- | --- | | Актуальность | Всегда требуются самые свежие данные | Достаточно плановых циклов обновления | | Производительность | Анализ и сегментация, допустимы задержки в секундах | Работа в реальном времени, постоянное время отклика | | Объем и частота | Большой объем, мало запросов | Средний объем, много запросов | | Управление | Источник данных имеет строгие политики | Требуется полный контроль над копией | Эта таблица также объясняет, почему большинство организаций приходят к комбинированному подходу: операционные потоки данных загружаются, а тяжелые аналитические потоки остаются на месте. ## Что остается в сфере ответственности команды при Zero Copy Виртуальный доступ устраняет необходимость в конвейере, но не в работе. По-прежнему требуется: сопоставление схемы с общей моделью, принятие решения о ключах идентификации для объединения профилей, обработка изменений схемы в источнике и мониторинг доступности. Изменение имени столбца во внешнем хранилище данных нарушит виртуальное представление так же, как оно нарушает процесс ETL. Поэтому соглашение с командой данных, которая владеет источником, является частью реализации: предварительное уведомление об изменениях схемы, известное окно обслуживания и согласованный бюджет запросов. ## Применимые гибридные модели **Агрегирование внутри, детализация снаружи** – в слой объединения вводятся агрегированные значения для каждого клиента, а детализированные записи остаются в хранилище для доступа по требованию. Это наиболее распространенная и обычно наиболее экономичная модель. **Горячее окно и холодный архив** – последние 12-24 месяца копируются для обеспечения производительности, а более ранняя история остается доступной через виртуальный доступ. **Сначала виртуально, затем копирование по мере необходимости** – начинают с виртуального доступа, измеряют фактическую частоту использования и копируют только то, что, как доказано, часто требуется. Это эффективный способ избежать копирования данных, которые никто не будет запрашивать. Связь между этим решением и распределением ответственности между системами подробно описана в статьях [Data 360 против данных CRM](/ru/insights/data-360-vs-crm-data) и [Единый источник истины в организации](/ru/insights/salesforce-source-of-truth). ## Сценарий: Финансовая компания с 400 миллионами записей Компания, предоставляющая финансовые услуги, хотела сегментировать клиентов на основе семилетней истории транзакций — около 400 миллионов записей в облачном хранилище данных. Изначальный план предусматривал полную загрузку данных в слой объединения. Пилотный проект изменил решение. Было измерено, что фактическая сегментация основывалась всего на трех вычислениях – среднемесячном значении, 90-дневной тенденции и классификации активности – и все они могли быть выполнены в самом хранилище. Вместо передачи 400 миллионов записей были переданы три агрегированных столбца по клиентам, ежедневно обновляемые, в то время как детализация оставалась виртуально доступной для точечного исследования. Решение здесь касалось не дихотомии «виртуально против копирования», а уровня гранулярности: правильный вопрос заключался в том, на каком уровне детализации данные действительно необходимы. Когда на него был получен ответ, вопрос о копировании стал незначительным. ## Типичные риски и меры профилактики | Риск | Как он проявляется | Мера профилактики | | --- | --- | --- | | Неожиданные затраты на вычисления | Частые широкие запросы | Измерение на пилотном проекте и предварительное согласование | | Зависимость от доступности источника | Сбой в хранилище отключает сегментацию | Резервный механизм или скопированное «горячее окно» | | Изменения схемы | Представления нарушаются без предупреждения | Соглашение об изменениях и мониторинг схемы | | Неопределенные разрешения | Более широкое раскрытие, чем в источнике | Идентичность запроса и письменная политика раскрытия | | Неправильная гранулярность | Передача деталей, которые никто не использует | Определение разрешения до выбора метода | ## Как измерять успех | Область | Что измеряется | Частота проверки | | --- | --- | --- | | Производительность | Время отклика на ключевые запросы сегментации | Ежемесячно | | Стоимость | Стоимость вычислений и трафика для каждого Use Case | Ежемесячно | | Стабильность | Сбои запросов и доступность источника | Еженедельно | | Ценность | Фактически созданные сегментации и действия | Ежеквартально | Выбор между виртуальным доступом и загрузкой данных осуществляется в рамках [услуги по интеграции и работе с данными](/ru/integrations-data). ## Контрольный список для принятия решения о Zero Copy - ☐ Определены конкретные сценарии использования (Use Cases), а не «общая возможность» - ☐ Установлены требования к актуальности данных (Freshness) для каждого сценария использования - ☐ Проверена фактическая требуемая детализация данных - ☐ Оценена частота запросов и объем сканирования - ☐ Существует соглашение об изменениях схемы с владельцем источника - ☐ Определена идентичность запроса и политика раскрытия данных - ☐ Рассмотрена гибридная модель перед принятием бинарного решения - ☐ Существует план аварийного восстановления (Fallback) на случай сбоя источника - ☐ Проведен измеренный пилотный проект перед масштабированием - ☐ Назначен ответственный за мониторинг затрат и периодический анализ ## Профессиональные источники - Salesforce Data 360 — https://www.salesforce.com/data/ - Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html - HPI Pro – Интеграции и данные — https://hpi.pro/integrations-data ### Вопросы и ответы **Что именно экономит функция Zero Copy?** Она экономит инфраструктуру и устраняет дублирование: нет необходимости поддерживать ETL, нет устаревших копий, и нет вопросов о том, какая копия является правильной. Однако она не экономит вычислительные ресурсы — запрос по-прежнему выполняется, но в системе-источнике, и ее бюджет используется для обработки этого запроса. **Когда все же предпочтительнее копировать данные?** Когда требуется низкое и стабильное время отклика для оперативного использования, когда источник данных нестабилен или имеет ограничения по скорости запросов, когда необходима восстановленная история до определенного момента времени, или когда источник данных может исчезнуть. В этих случаях контролируемая ингестация данных является более ответственным выбором. **Подходит ли Zero Copy для работы в режиме реального времени?** Менее подходит. Виртуальный запрос хорошо подходит для сегментации, анализа и обогащения контекста, но операционный процесс, ожидающий ответа за доли секунды, должен опираться на предварительно рассчитанные значения, хранящиеся близко к потребителю. **Как обстоят дела с управлением и разрешениями при виртуальном доступе?** Они в основном остаются на стороне источника, что является преимуществом: нет необходимости отдельно защищать копию. Однако необходимо явно определить, под какой учетной записью выполняется запрос, что и кому открывается на стороне потребителя, и как регистрируется документация — иначе возникает более широкое раскрытие данных, чем в исходной системе. **Как заранее оценить стоимость?** По трем факторам: частота запросов, объем сканирования при каждом выполнении и объем трафика между средами и регионами. Широкий запрос, выполняемый каждые пятнадцать минут, может стоить дороже, чем ежедневное копирование тех же данных. Проведите пилотное тестирование перед масштабированием. --- ## Сверка и Cutover в миграции Salesforce: План на день перехода URL: https://hpi.pro/ru/insights/salesforce-migration-cutover-reconciliation День перехода к новой системе Salesforce часто завершается неудачей не из-за ошибок загрузки данных, а из-за сопутствующих проблем: необработанных дельта-изменений, преждевременно запущенной интеграции или отсутствия лица, принимающего решения в два часа ночи. Наше руководство предлагает почасовой план Cutover, правила заморозки данных (Freeze), четырехуровневый метод сверки (Reconciliation) и четкие критерии Go/No-Go. ## Краткий ответ Процесс Cutover является операционным, а не исключительно техническим этапом. Три ключевых фактора определяют его успешность: почасовой план с указанием ответственного за каждый шаг, сверка (Reconciliation), подтверждающая не только перенос, но и корректность данных, а также критерии Go/No-Go, разработанные в спокойной обстановке. Разница между организацией, осуществившей бесперебойный переход, и организацией, столкнувшейся с двухнедельным хаосом, почти всегда заключается в количестве тестовых прогонов, а не в качестве используемых инструментов. Подробное планирование миграции описано в [Руководстве по миграции данных в Salesforce](/ru/insights/salesforce-data-migration-guide). ## Структура Cutover: Три волны | Волна | Когда | Что загружается | | --- | --- | --- | | Исторические данные | За 3–10 дней до cutover | Закрытые исторические данные: завершенные сделки, закрытые кейсы, история | | Дельта | В период cutover | Все изменения с момента первой волны | | После запуска | Через 24–72 часа после | Большие файлы, некритичные данные, дополнения | Такое разделение позволяет сократить окно cutover. Организация, пытающаяся загрузить все данные за одну ночь, обнаруживает, что время загрузки зависит от объема, а этот объем невозможно сжать сверх ограничений платформы. ## Примерный график – окно в 12 часов | Время | Действие | Ответственный | | --- | --- | --- | | T-2 | Подтверждение Go, проверка доступности команды и лиц, принимающих решения | Руководитель проекта | | T0 | Замораживание исходной системы, отключение исходящих интеграций | Отдел ИТ-операций | | T0+1 | Извлечение дельта-данных и проверка подсчета в исходной системе | Ведущий специалист по данным | | T0+2 | Загрузка дельта-данных в соответствии с зависимостями | Команда миграции | | T0+6 | Автоматическая сверка (Reconciliation): подсчет, суммы, связи | Отдел QA | | T0+8 | Ручная выборочная проверка и подтверждение владельцами процессов | Бизнес-подразделения | | T0+9 | Точка невозврата: решение Go / Rollback | Руководящий комитет | | T0+10 | Активация интеграций, открытие пользовательских разрешений | Отдел ИТ-операций | | T0+11 | Дымовые тесты критически важных процессов | Отдел QA + Бизнес-подразделения | | T0+12 | Уведомление пользователей о запуске, переход на режим гипер-поддержки | Отдел коммуникаций | Два принципа графика: у каждой строки есть ответственный, и у каждой проверки есть числовой порог. Строка без ответственного не будет выполнена; проверка без порога приведет к спорам. ## Сверка (Reconciliation): Четырехуровневый подход, который нельзя пропускать **Подсчёт** – количество записей в исходной и целевой системах для каждой сущности и каждого диапазона дат. Позволяет выявить частичные загрузки. **Суммы** – суммы денежных и числовых полей. Позволяет обнаружить некорректные преобразования, обрезки и скрытые обнуления; обычный подсчет их не выявит. **Связи** – сколько дочерних элементов у каждого родительского, и сколько "осиротевших" записей. Позволяет обнаружить некорректный порядок загрузки и нарушенное сопоставление ключей. **Ручная выборочная проверка** – от 20 до 50 записей, выбранных заранее, включая пограничные случаи: клиент со специальными символами, сделка в иностранной валюте, запись, прошедшая слияние. Это единственный уровень, который выявляет семантические ошибки – данные, которые были успешно загружены, но в неправильное место. Зависимость точности преобразования от качества маппинга объясняется в [Маппинг данных для миграции](/ru/insights/salesforce-data-mapping). ## Сценарий: Cutover, остановленный на восьмом часу Дистрибьюторская компания запланировала десятичасовое окно cutover на выходные. Загрузка прошла успешно, подсчеты точно совпали, и команда готовилась к запуску. В ходе ручной выборочной проверки выяснилось, что у шести из 30 проверенных клиентов открытые возможности были связаны с неправильным владельцем – это произошло из-за таблицы сопоставления пользователей, которая не была обновлена после двух увольнений и изменения должности. Подсчеты были верными. Суммы были верными. Только ручная проверка выявила проблему. Команда не откатила систему (Rollback): они определили, что это 1400 записей, которые можно исправить запросом, выполнили точечное исправление в рамках окна cutover и провели повторную проверку. Это решение стало возможным благодаря тому, что критерий No-Go был заранее определен как "ошибка, которую невозможно исправить в течение двух часов", а не как "любая ошибка". Четко сформулированный критерий позволяет уставшей команде принять правильное решение в три часа ночи. ## Гипер-поддержка: 14 дней после запуска Окно Cutover завершается запуском для пользователей, но риски сохраняются. Требуется дежурная команда с единым каналом обращения, ежедневный отчет об отклонениях интеграции и мониторинг метрик качества по сравнению с базовым уровнем. Проблемы классифицируются по их бизнес-влиянию, а не по тому, кто громче кричал. Постоянное измерение качества после перехода описано в [Метрики качества данных](/ru/insights/salesforce-data-quality-metrics). ## Распространенные риски и профилактические действия | Риск | Как это проявляется на практике | Профилактическое действие | | --- | --- | --- | | Единое окно для всего объема | Загрузка превышает сроки, cutover откладывается | Разделение на три волны | | Интеграция, которая "проснулась" | Дублирующиеся записи или противоречивые обновления | Контролируемое отключение и упорядоченная активация | | Поверхностная сверка (Reconciliation) | Верные подсчеты, но неверные данные | Четыре уровня, включая ручную выборочную проверку | | Отсутствие критериев Go/No-Go | Продвижение вперед по инерции | Письменные пороги до окна cutover | | Устаревшее сопоставление пользователей | Неверное владение записями | Обновление таблицы пользователей за день до cutover | ## Как измерять успех | Область | Что измеряется | Частота проверки | | --- | --- | --- | | Точность миграции | Различия в подсчете, суммах и связях | В каждой волне и в Cutover | | Соблюдение сроков | Отклонение от графика | В каждой репетиции | | Стабильность после Cutover | Сбои интеграции и критические ошибки (P1) в день | Ежедневно в течение 14 дней | | Адаптация | Входы и действия по сравнению с базовым уровнем | Еженедельно в течение первого месяца | Сопровождение в планировании и проведении Cutover осуществляется в рамках [услуги интеграции и данных](/ru/integrations-data). ## Чек-лист для Go/No-Go - ☐ Две полные репетиции (Rehearsal) с производственным объемом данных - ☐ Почасовой график с ответственным за каждую строку - ☐ Согласованный с бизнесом план "замораживания" системы - ☐ Список интеграций для отключения и активации, по порядку - ☐ Сценарий сверки (Reconciliation) на четырех уровнях, максимально автоматизированный - ☐ Заранее определенная ручная выборочная проверка, включая пограничные случаи - ☐ Обновленная таблица сопоставления пользователей и владения - ☐ Письменные критерии No-Go с числовыми порогами - ☐ Точка невозврата и план исправления проблем (Fix-Forward) - ☐ Команда гипер-поддержки, канал обращения и ежедневный отчет ## Профессиональные ресурсы - Salesforce Data 360 — https://www.salesforce.com/data/ - Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html - HPI Pro – Интеграции и данные — https://hpi.pro/integrations-data ### Вопросы и ответы **Сколько тестовых запусков (Rehearsal) действительно необходимо?** Минимум два полноценных запуска, при этом второй должен проводиться с производственными объемами данных и в аналогичных временных условиях. Первый запуск выявляет ошибки в содержимом, второй — проблемы со временем и последовательностью процессов, которые чаще всего приводят к срыву окон Cutover. Организации с множеством интеграций обычно проводят три тестовых запуска. **Как долго необходимо замораживать исходную систему?** Как можно меньше, и сознательно. Длинное окно заморозки (Freeze) вызывает сопротивление бизнеса и приводит к работе вне системы. Принятый подход: полная историческая загрузка данных за несколько дней до перехода, и только короткая дельта-загрузка в самом окне Cutover — обычно от четырех до двенадцати часов. **Как правильно проводить сверку (Reconciliation)?** На четырех уровнях: подсчет записей по сущностям, суммирование денежных и числовых полей, проверка целостности связей «родитель-потомок», а также ручная выборка 20–50 заранее определенных записей, включая крайние случаи. Первые три уровня автоматизированы; четвертый выявляет семантические ошибки. **Когда принимается решение о No-Go (не продолжать)?** Согласно критериям, разработанным до открытия окна Cutover, а не на основе интуиции в реальном времени: превышение порога аномалий, сбой в финансовой сверке, несоблюдение установленного промежуточного срока или отсутствие доступного лица, принимающего решения. Тот, кто заранее не определил критерии No-Go, почти всегда будет двигаться вперед. **Действительно ли возможен откат (Rollback)?** Только если он был спланирован. В большинстве случаев полный откат возможен только в первом окне Cutover, до того как пользователи создадут новые данные. Поэтому определяется «точка невозврата» по времени, после которой переход наступает, и далее следует план Fix-Forward с выделенной командой. --- ## Стоимость Agentforce: Потребление, лицензии и общая стоимость владения корпоративным агентом URL: https://hpi.pro/ru/insights/agentforce-cost-tco Стоимость лицензирования легко рассчитать, но часто она не является основной статьей расходов. Данное руководство делит общую стоимость владения (TCO) на пять компонентов — лицензирование, потребление, разработка, эксплуатация и поддержка контента — и предлагает формулу расчета затрат на задачу. Это позволяет сравнивать стоимость агента с затратами на обслуживание, управляемое человеком, вместо того чтобы полагаться на обещания. ## Краткий ответ Ответ на вопрос "сколько стоит Agentforce" ошибочен при его переводе в стоимость лицензии. Реальная стоимость состоит из пяти компонентов: лицензирование, потребление во время работы, первоначальное внедрение, текущая эксплуатация и поддержка контента. В большинстве внедрений, которые мы наблюдали, последние три компонента в первый год превышают сумму первых двух. Определяющим показателем является не ежемесячная стоимость, а стоимость успешно выполненной задачи без эскалации. Это единственный показатель, который можно сопоставить с текущими затратами на обслуживание, и именно он выявляет, кроется ли проблема в цене или в количестве попыток, необходимых для выполнения задачи. ## Пять компонентов совокупной стоимости владения (TCO) | Компонент | Что включено | Поведение во времени | Признак отклонения | | --- | --- | --- | --- | | Лицензирование | Лицензии на платформу и пользователей | Стабильно, увеличивается с расширением | Лицензии, приобретенные до выбора варианта использования | | Потребление | Операции во время работы согласно модели ценообразования | Изменяется в зависимости от объема и продолжительности сеанса | Рост потребления без увеличения выполненных задач | | Внедрение | Анализ, действия, обоснование, тестирование | Единовременно для каждого варианта использования, снижается с опытом | Расширение объема без бизнес-обоснования | | Эксплуатация | Мониторинг, анализ сбоев, исправления, управление изменениями | Постоянно, пока работает агент | Отсутствие ответственного лица, следовательно, отсутствие учтенных затрат — и, как следствие, отсутствие поддержки | | Поддержка контента | Обновление базы знаний, архивирование, проверка актуальности | Постоянно, в зависимости от количества областей знаний | Постепенное снижение точности ответов | ## Стоимость задачи: формула, которую стоит разработать Рассчитайте общую ежемесячную стоимость всех пяти компонентов и разделите на количество успешно выполненных задач — то есть тех, которые завершились желаемым результатом без эскалации к человеку. Это единственный показатель, который можно сравнить с текущими затратами на обслуживание. Определение понятия "успешно выполнено" является сложным решением и требует участия владельца процесса. Сеанс, в котором клиент получил ответ, но на следующий день снова обратился по тому же вопросу, не является успешно выполненной задачей. Свободное определение создает красивые цифры, которые не выдерживают критики. Важно сравнивать с реальным базовым показателем (Baseline). Стоимость человеческого обслуживания включает зарплату, системы, обучение и время ожидания, а не только минуты разговора. Сравнение с частичным показателем является распространенной причиной того, что экономическое обоснование рушится при квартальном обзоре. ## Что на самом деле увеличивает стоимость Первый фактор — слабое обоснование (Grounding). Когда агент не может найти точный источник, он делает больше попыток, сеанс затягивается, потребление растет — и в итоге сеанс все равно эскалируется. Улучшение контента часто является более значительной мерой экономии, чем замена модели. Второй фактор — повторяющиеся попытки после сбоя интеграции. Каждая попытка учитывается, и когда внешняя система нестабильна, затраты удваиваются без какой-либо дополнительной ценности. Третий фактор — широкий объем (Scope). Агент, который должен отвечать на все, потребляет больше в каждом сеансе, потому что проверяет больше источников и принимает больше решений. Узкоспециализированный агент обходится дешевле и точнее. Связь между качеством источников информации и стоимостью подробно описана в статье [Grounding и RAG в Agentforce](/ru/insights/agentforce-grounding-rag). ## Контроль бюджета, который стоит установить заранее Определенный ежемесячный лимит для каждого варианта использования с оповещением до его достижения. Без лимита обнаружение превышения приходит вместе со счетом. Разделение затрат по вариантам использования, а не только на уровне организации. Когда есть три агента и только один номер, невозможно определить, какой из них нерентабелен, и отключить его. Еженедельное измерение потребления по отношению к выполненным задачам. Рост потребления при стабильном количестве задач является ранним "красным флагом" — он указывает на ухудшение качества ответов до того, как пользователи начнут жаловаться. Как настроить мониторинг, который обеспечивает эти средства контроля, подробно описано в статье [Наблюдаемость для ИИ-агентов](/ru/insights/agentforce-observability). ## Сценарий: пилотный проект, который казался дорогим, но оказался дешевым Софтверная компания провела восьминедельный пилотный проект и получила счет за потребление, который был выше ожидаемого. Первой реакцией было обдумывание остановки проекта. Анализ показал другую картину: 62% потребления приходилось на одну категорию вопросов, по которой агент не мог найти источник и поэтому снова и снова пытался, прежде чем эскалировать. Решение не было техническим. Было написано одиннадцать новых статей для базы знаний по этой категории, и был установлен возврат (Fallback), который эскалировал после второй попытки вместо того, чтобы пытаться до конца. Ежемесячное потребление значительно снизилось, а количество выполненных задач фактически увеличилось. Стоимость задачи — единственный показатель, который проверяют у финансового директора — улучшилась в несколько раз, и проект был одобрен для расширения. Вывод: высокий счет часто является симптомом пробелов в контенте, а не ценообразования. ## Когда агент просто нерентабелен Три ситуации, которые стоит выявить на ранней стадии. Низкий объем: процесс, который обрабатывает сотни случаев в месяц, не окупит операционные расходы, даже если он раздражает. Слишком высокая вариативность: когда почти каждый случай является исключительным, процент эскалации останется высоким, а вместе с ним и двойная стоимость. И зависимость от нестабильной внешней системы: стоимость зависит от фактора, который не контролируется проектом. В таких ситуациях правильный ответ не "нет ИИ", а "нет этому процессу". Почти всегда есть подпроцесс с более высоким объемом, который оправдывает инвестиции. ## Риски и превентивные меры | Риск | Как проявляется | Превентивная мера | | --- | --- | --- | | Лицензирование до выбора варианта использования | Неиспользуемые лицензии и давление с целью демонстрации ценности | Проверка готовности и выбор процесса перед покупкой | | Отсутствие бюджета на эксплуатацию | Снижение качества после первого квартала | Ежегодное бюджетирование на мониторинг и поддержку контента | | Измерение только на уровне организации | Невозможно определить нерентабельного агента | Разделение затрат по вариантам использования | | Неточное определение "успешно выполнено" | Красивые цифры, которые не выдерживают критики | Предварительное определение успеха владельцем процесса | | Повторные попытки без ограничения | Двойное потребление без ценности | Ограничение попыток и ранняя эскалация | ## Экономические показатели | Показатель | Определение | Периодичность | | --- | --- | --- | | Стоимость выполненной задачи | Общая стоимость, деленная на количество задач без эскалации | Ежемесячно | | Потребление на задачу | Среднее количество единиц потребления на задачу | Еженедельно | | Процент завершения | Процент случаев, завершившихся желаемым результатом | Еженедельно | | Постоянные операционные расходы | Часы мониторинга, исправлений и поддержки контента | Ежемесячно | | Соотношение к базовой стоимости | Стоимость агента по сравнению с текущими затратами на обслуживание | Ежеквартально | Если вам требуется экономическая модель, которая выдержит внутреннюю проверку перед принятием инвестиционного решения, [услуга Agentforce и ИИ](/ru/agentforce-ai) — это практический путь вперед. ## Чек-лист для построения модели затрат - ☐ Оценка стоимости всех пяти компонентов TCO отдельно - ☐ Определение "успешно выполненной задачи" владельцем процесса - ☐ Измерение базового показателя (Baseline) текущих затрат на обслуживание - ☐ Установление ежемесячного лимита потребления для каждого варианта использования - ☐ Разделение затрат на уровне варианта использования, а не только организации - ☐ Бюджетирование мониторинга и поддержки контента на первый год - ☐ Определение максимального количества попыток перед эскалацией - ☐ Установление экономического порога, при котором агент приостанавливается или отключается ### Вопросы и ответы **Что на самом деле делает агента дороже, чем ожидалось?** Три вещи: необоснованно длинные диалоги из-за слабого обоснования (Grounding), повторные запуски после сбоев и поддержка контента, на которую никто не заложил бюджет. Стоимость потребления часто обусловлена не ценой за единицу, а количеством единиц, потребляемых для каждой успешно выполненной задачи. **Как сравнить стоимость агента со стоимостью оператора?** Рассчитайте стоимость за успешно выполненную задачу без эскалации, а не стоимость за разговор. Если агент обрабатывает восемьдесят процентов разговора и эскалирует, экономия заключается во сэкономленном времени, а не в полном обслуживании. Справедливое сравнение также включает время оператора, необходимое для завершения задачи после эскалации. **Снижаются ли эксплуатационные расходы со временем?** Стоимость разработки снижается, а эксплуатационные расходы — не обязательно. Мониторинг, анализ неудачных разговоров и обновление контента являются постоянными затратами, пока агент активен. Организации, которые закладывают бюджет только на проект, но не на первый год после него, сталкиваются с этим разрывом во втором квартале. **Сколько ресурсов разумно выделить на поддержку контента?** На практике это соответствует постоянной частичной занятости для активной области знаний: человек, который обновляет статьи, архивирует устаревшую информацию и проверяет актуальность. Без такого выделения ресурсов качество ответов постепенно снижается, а затем возникает необходимость в дорогостоящих повторных инвестициях. **Когда правильным решением является не использовать агента?** Когда стоимость задачи выше создаваемой ею ценности даже после оптимизации, или когда объем слишком мал, чтобы оправдать постоянную эксплуатацию. Процесс, включающий всего несколько сотен случаев в месяц, почти всегда дешевле решить с помощью классической автоматизации или улучшения процесса. --- ## Безопасность Agentforce и модель общей ответственности URL: https://hpi.pro/ru/insights/agentforce-security-shared-responsibility Платформа обеспечивает безопасность инфраструктуры; организация отвечает за то, что агент имеет право видеть и делать. Данное руководство описывает фактическую линию разграничения — данные, разрешения, инструкции, действия и мониторинг — и показывает, какие новые риски возникают с агентом, не имеющим аналогов в обычной системе CRM. ## Краткий ответ Модель общей ответственности — это не просто формальный документ; это граница, определяющая, кто виноват в случае возникновения проблем. Простое правило: платформа отвечает за безопасность самой услуги, а организация — за все решения о том, что видит агент, что ему разрешено делать и кому он отвечает. Главный риск заключается не в компрометации платформы. Это чрезмерно авторизованный агент, который раскрывает информацию не тому субъекту или выполняет действие, которое не должен был выполнять, — обе эти ошибки полностью лежат на стороне организации. ## Распределение ответственности на практике | Область | Ответственность платформы | Ответственность организации | |---|---|---| | Инфраструктура | Шифрование, изоляция, доступность, управление уязвимостями | Выбор среды и утвержденная сетевая конфигурация | | Данные | Хранение и обработка согласно соглашению | Что индексируется и что классифицируется как конфиденциальное | | Идентичность и разрешения | Механизмы авторизации платформы | Определение, кто что может видеть и делать | | Поведение агента | Возможности модели и инструменты контроля | Инструкции, границы, точки утверждения | | Действия | Инфраструктура выполнения | Авторизация для каждого действия и внутренняя валидация | | Мониторинг и аудит | Журналы платформы | Бизнес-аудит, выборка и анализ | ## Новые риски, не существовавшие в традиционных CRM Первый — это раскрытие информации через поиск. В обычной системе пользователь видит то, что отображается на экране; в агентской системе свободный текст может привести к извлечению фрагмента документа, не предназначенного для пользователя. Поэтому поиск должен выполняться в контексте разрешений пользователя, а не в контексте общих учетных записей интеграции. Второй — это Prompt Injection. Контент, с которым работает агент — электронное письмо клиента, поле описания, прикрепленный документ — может содержать инструкции, пытающиеся изменить его поведение. От этого нельзя защититься только формулировками; защита должна быть архитектурной. Третий — утечка внутреннего контента во внешний канал. Статья, написанная для представителей, с дисконтными маржами или формулировками возражений, не должна попадать к клиенту, и разделение должно основываться на белом списке, а не на черном. Четвертый — тихое расширение полномочий: добавление действия или разрешения для решения конкретной проблемы без прохождения процедуры утверждения. ## Пять ключевых механизмов контроля Поиск в контексте пользователя. Это единственный механизм контроля, и если он нарушен, все остальные бесполезны. Раздельное разрешение для каждого Action, согласно принципу минимальных привилегий. Агент, получающий один широкий профиль, исключает любой будущий контроль. Валидация должна быть встроена в действие, а не в инструкции. Инструкция — это указание; валидация — это контроль. Действие, выполняющее возврат средств, должно проверять сумму, правомочность и разрешение в своем коде, даже если инструкции указывают агенту не запускать его в определенных случаях. Человеческое одобрение необратимого действия. Это механизм контроля, который превращает потенциальный сбой в своевременно остановленное событие. Журнал аудита, связывающий пользователя, действие, источник и утверждающего. Без него нет ответа на аудиторский вопрос: «На основании чего агент это сделал?». Общие принципы модели разрешений в Salesforce подробно описаны в документе [Модель разрешений в Salesforce](/ru/insights/salesforce-permission-model). ## Что проверять перед запуском Тестирование персон: те же десять-двадцать вопросов задаются в разных ролях — представитель, менеджер, ограниченный пользователь, внешний клиент — и ответы сравниваются. Любое несоответствие, не объясняемое разрешением, является проблемой. Контентное Red Teaming: целенаправленные попытки извлечь несанкционированную информацию, выполнить запрещенное действие и обойти эскалацию. Сценарии пишутся один раз и сохраняются для повторного запуска в каждой версии. Тестирование пути действий: для каждого Action убедитесь, что валидация работает, даже если она запускается напрямую, а не только через агента. Проверка сохранения данных: что сохраняется, как долго и кто может получить доступ к журналам, содержащим записи разговоров с данными клиентов. О том, как эти тесты интегрируются в более широкую структуру тестирования, рассказывается в [Тестирование Agentforce](/ru/insights/agentforce-testing-scorers). ## Сценарий: проблема, обнаруженная при тестировании персоны Медицинская компания подготовила внутреннего агента для ответа на вопросы о процедурах. При тестировании персоны перед запуском было обнаружено, что пользователь с административной ролью получил ответ, основанный на процедуре, предназначенной только для медицинского персонала. Причина не была в ошибке агента. Индекс был построен с использованием учетной записи интеграции с широким доступом, и поиск не был ограничен разрешениями пользователя. Потенциально то же раскрытие могло произойти по любому вопросу, связанному с этой областью. Исправление включало два этапа: перенос поиска в контекст пользователя и явная пометка конфиденциальных документов, чтобы они не попадали в общий индекс. Тест был добавлен как постоянный сценарий, запускаемый перед каждым обновлением версии. ## Риски и превентивные меры | Риск | Как он обнаруживается | Превентивная мера | |---|---|---| | Поиск с широкими разрешениями | Раскрытие конфиденциального документа в необдуманном ответе | Поиск в контексте пользователя и тестирование персон | | Prompt Injection | Действие, вызванное внешним контентом | Ограниченные разрешения, валидация в действии, человеческое одобрение | | Смешение внутреннего и внешнего контента | Внутренняя формулировка доходит до клиента | Белый список на внешнем канале | | Тихое расширение полномочий | Агент делает больше, чем было разрешено | Пометка существенных изменений и повторное одобрение | | Отсутствие журнала аудита | Нет ответа на аудит | Запись пользователя, действия, источника и утверждающего | ## Метрики безопасности | Метрика | Что она выявляет | Частота | |---|---|---| | Результаты тестирования персон | Разрывы в разрешениях при поиске | В каждой версии | | Результаты Red Teaming | Устойчивость к попыткам обхода | В каждой версии | | Чувствительные действия без одобрения | Пробелы в цепочке контроля | Ежемесячно | | Изменения, обошедшие одобрение | Дисциплина процесса изменений | Ежеквартально | | Покрытие журнала аудита | Процент полностью задокументированных чувствительных действий | Ежеквартально | Структура утверждений, в рамках которой применяются механизмы контроля, подробно описана в документе [Управление ИИ для Agentforce](/ru/insights/agentforce-ai-governance). При необходимости сопровождения в определении модели ответственности и тестировании перед запуском, [услуги Agentforce и AI](/ru/agentforce-ai) — это практический путь для дальнейших действий. ## Чек-лист безопасности перед запуском - ☐ Документ о разделении ответственностиDrafted_ and approved - ☐ Условия использования данных в модели задокументированы в письменной форме - ☐ Поиск выполняется в контексте разрешений пользователя - ☐ Тестирование персон выполнено для каждого уровня разрешений - ☐ Для каждого Action есть отдельное разрешение и внутренняя валидация - ☐ Необратимые действия требуют человеческого одобрения - ☐ Во внешнем канале действует белый список контента - ☐ Сценарии контентного Red Teaming написаны и выполнены - ☐ Журнал аудита связывает пользователя, действие, источник и утверждающего - ☐ Политика хранения журналов и содержания разговоров одобрена ### Вопросы и ответы **Что фактически охватывает платформа, а что нет?** Платформа охватывает инфраструктуру, шифрование, изоляцию сред и обязательства по использованию данных в отношении модели. Она не определяет, кто имеет право видеть что в организации, какие действия разрешено выполнять агенту, что включается в базу знаний и кто осуществляет мониторинг. Эти решения порождают большую часть рисков. **Что такое инъекция промптов в корпоративном контексте?** Содержимое, которое читает агент — входящее электронное письмо, поле описания, загруженный документ — содержащее инструкции, направленные на изменение его поведения. Защита заключается не в формулировании лучших инструкций, а в контроле: ограниченные разрешения на действия, валидация внутри действия и человеческое одобрение перед выполнением чувствительных операций. **Используются ли данные организации для обучения моделей?** Ответ зависит от соглашения и конфигурации, поэтому должен быть задокументирован в письменной форме до запуска, не следует полагаться на предположения. Это один из первых вопросов, который задаст внутренний аудит, и желательно, чтобы ответ был подкреплен документом, а не воспоминаниями участника встречи по продажам. **Требуется ли тестирование на проникновение для агента?** Да, но другого рода. Помимо обычного технического тестирования требуется контентный "красный отряд" (Red Teaming): попытки получить несанкционированную информацию, вызвать недопустимое действие и обойти правила эскалации. Эти тесты оформляются в виде сценариев и сохраняются для повторного запуска с каждой новой версией. **Что требуется для аудита и регулирования?** Контрольный журнал (Audit trail), показывающий для каждого чувствительного действия, кто пользователь, что сделал агент, на основании какого источника и кто одобрил. Кроме того, актуальный реестр агентов и документ, определяющий распределение ответственности. Эти три элемента покрывают большинство вопросов аудита. --- ## Тестирование Agentforce: Тестовые наборы, скореры и крайние сценарии URL: https://hpi.pro/ru/insights/agentforce-testing-scorers Тестирование агента отличается от тестирования Flow: один и тот же вопрос может иметь несколько корректных ответов. В этом руководстве мы покажем, как создать тестовый набор, максимально точно имитирующий реальные условия, какие параметры следует измерять отдельно, когда автоматизация достаточна, а когда требуется вмешательство человека, и какой порог позволяет выпустить продукт в эксплуатацию. ## Краткий ответ Тестирование агента не является классическим тестированием программного обеспечения. Не существует единственно верного ответа: один и тот же вопрос может быть сформулирован двадцатью способами, а сбой чаще всего оказывается не ошибкой, а разумным ответом, в котором отсутствует существенное условие. Поэтому требуется иной подход: представительский набор кейсов, критерии приемлемости вместо точных ответов и измерение по нескольким отдельным параметрам. Разделение по измерениям делает тестирование полезным. «Ответ неудовлетворителен» – это не результат; «Тема определена правильно, но соответствующий источник не извлечен» – это результат, который можно исправить. ## Четыре измерения оценки | Измерение | Что проверяется | Как измеряется | Кто исправляет | | --- | --- | --- | --- | | Идентификация темы | Понял ли агент, о чем идет речь | Сравнение с ожидаемой темой | Разработчик инструкций и описаний Actions | | Извлечение данных | Извлечен ли корректный источник | Появился ли ожидаемый сегмент при извлечении | Владелец контента и тегов | | Ответ | Корректен и полон ли контент | Критерии приемлемости: обязательно, запрещено, цитирование | Контент и инструкции | | Процесс | Было ли выполнено правильное действие и сохранена ли эскалация | Проверка последовательности действий и решения об остановке | Actions и правила эскалации | ## Создание репрезентативного тестового набора Исходным материалом служат реальные обращения, а не сценарии, разработанные на совещаниях. Стенограммы, электронные письма и описания кейсов содержат то, чего не хватает в вымышленных сценариях: орфографические ошибки, неполные формулировки, два вопроса в одном предложении и недостающую информацию. Рекомендуемый состав: около половины составляют типичные кейсы, примерно четверть — пограничные случаи (исключения, предельные условия правомочности, многосоставные вопросы) и около четверти — кейсы, которые намеренно должны потерпеть неудачу: запросы вне сферы действия, попытки извлечь несанкционированную информацию и клиент, требующий участия человека. Для каждого кейса определяются четыре поля: обращение в том виде, в каком оно было сформулировано, ожидаемая тема, критерий приемлемости ответа и ожидаемое поведение процесса — включая «должен эскалировать» как корректный результат, а не как сбой. ## Критерий приемлемости вместо точного ответа Это основной принцип, позволяющий вообще проводить тестирование. Вместо того чтобы писать правильный ответ, составляют три коротких списка: факты, которые должны быть представлены; утверждения, которые не должны быть представлены; и источник, который должен быть процитирован. Типичный пример: вопрос о праве на возврат средств. Обязательно должны быть указаны срок и условия состояния продукта; нельзя давать гарантии кредитования; источником должен быть действующий регламент возвратов. Два совершенно разных формулирования могут быть приняты. Это также форма, которая обеспечивает надежную автоматизированную оценку: проверка наличия определенного факта является гораздо более точной, чем запрос к модели оценить «качество». ## Автоматизация против человеческого суждения Автоматические оценщики подходят для определения темы, наличия действительной цитаты, соответствия формату, длины и выявления запрещенных утверждений. Они прогоняются по всему набору в каждой версии с низкими затратами. Человеческое суждение требуется для содержательной точности в чувствительных областях и для формулировок, предназначенных для клиента. Не нужен весь набор – достаточно постоянной выборки из двадцати-тридцати случаев в каждой версии, выбранной так, чтобы она включала пограничные случаи. Опасность полного полагания на автоматический оценщик заключается в предвзятости в сторону ответов, которые звучат убедительно. Убедительный ответ, который упускает условие приемлемости, пройдет автоматическую проверку и будет отклонён человеком-тестировщиком. Как результаты тестирования связаны с мониторингом в продуктивной среде, описано в разделе [Observability для Agentforce](/ru/insights/agentforce-observability). ## Крайние сценарии, которые всегда следует включать Вопрос с двумя темами в одном предложении. Обращение, в котором отсутствует существенная информация – задаст ли агент уточняющий вопрос или будет догадываться. Клиент, формулирующий в негативном тоне – сработает ли эскалация. Запрос на действие, которое не разрешено этому пользователю. Вопрос о несуществующем продукте – признается ли агент или придумывает. Контент, содержащий замаскированное указание, пытающееся изменить поведение. Эти шесть пунктов охватывают большинство сбоев, которые мы видели в продуктивной среде, и их повторная отработка обходится недорого. Сценарии обхода связаны с проверками безопасности, подробно описанными в [Agentforce Security и общая ответственность](/ru/insights/agentforce-security-shared-responsibility). ## Пороги для запуска в эксплуатацию Порог не является единым числом, а зависит от канала и риска. Внутренний агент для помощи сотруднику может быть запущен с более низким уровнем точности, поскольку сотрудник фильтрует. Агент, взаимодействующий с клиентами, требует значительно более высокого порога, и особенно требует нулевых сбоев в критических категориях. Правило, которое важнее числа: ноль сбоев в обязательных категориях. Несанкционированное раскрытие информации, необратимое действие без разрешения, отсутствие эскалации при явном запросе человека — любое из этих нарушений блокирует запуск в эксплуатацию независимо от общего балла. ## Сценарий: небольшой набор, предотвративший неудачный запуск Туристическая компания планировала запустить клиентский агент после того, как внутренний пилотный проект показал хорошие результаты. Созданный тестовый набор включал 90 кейсов, из которых 22 были пограничными, основанными на реальных запросах. Тест выявил закономерность: в вопросах об изменении даты специальными условиями отмены агент давал в основном правильный ответ, но в трети случаев опускал информацию о сборах за изменение. При внутренних проверках это не было замечено – сотрудники умели самостоятельно добавлять недостающую информацию. Запуск был отложен на три недели. Исправление касалось контента: условия взимания платы были перенесены в отдельный и помеченный раздел в каждой соответствующей статье, и был добавлен явный критерий приемлемости. Повторный запуск прошёл успешно, и система была введена в эксплуатацию без инцидентов. ## Риски и превентивные меры | Риск | Как проявляется | Превентивная мера | | --- | --- | --- | | Выдуманный тестовый набор | Все проходит тестирование и дает сбои в продуктивной среде | Кейсы из реальных запросов | | Тестирование только общего показателя | Неизвестно, что исправлять | Отдельное измерение по четырем параметрам | | Опора на автоматическую оценку | Убедительные, но неполные ответы проходят проверку | Регулярная выборочная проверка человеком в каждой версии | | Отсутствие кейсов, которые должны завершиться неудачей | Агент отвечает на то, что ему не разрешено | Четверть набора: вне сферы действия и обходные пути | | Отсутствие регрессии | Незначительное исправление ломает другой сценарий | Прогон набора перед каждым развертыванием новой версии | ## Метрики тестирования | Метрика | Определение | Принципиальный порог | | --- | --- | --- | | Topic accuracy | Процент правильной идентификации темы | Высокий; сбой здесь ломает все остальное | | Retrieval hit rate | Процент случаев, в которых извлечен ожидаемый источник | Высокий по клиентскому каналу | | Answer acceptance | Процент ответов, соответствующих критериям приемлемости | Зависит от канала и риска | | Process compliance | Процент случаев, в которых выполнено правильное действие или эскалация | Ноль отклонений в обязательных категориях | | Regression delta | Изменение показателей по сравнению с предыдущей версией | Без необъяснимого падения | Когда требуется сопровождение в создании тестового набора и определении порогов для запуска, [Услуга Agentforce и AI](/ru/agentforce-ai) является практическим путём для дальнейших действий. ## Чек-лист для тестирования - ☐ Тестовый набор создан на основе реальных запросов - ☐ Состав включает распространённые, пограничные и намеренно неудачные кейсы - ☐ Для каждого кейса определён критерий приемлемости: обязательно, запрещено, источник - ☐ Измерение разделено по темам, извлечению данных, ответу и процессу - ☐ Автоматические оценщики прогоняются по всему набору - ☐ Постоянная выборка проверяется человеком в каждой версии - ☐ Включены сценарии обхода и замаскированные инструкции - ☐ Определены обязательные категории с нулевой терпимостью - ☐ Набор прогоняется как регрессионный перед каждым развертыванием новой версии - ☐ Результаты тестирования документируются и сравниваются с предыдущей версией ### Вопросы и ответы **Сколько тест-кейсов должно быть в тестовом наборе?** 50–150 репрезентативных тест-кейсов достаточно для первой версии. Набор из 500 тест-кейсов с исключительно корректными формулировками менее полезен, чем набор из 80, который включает орфографические ошибки, неоднозначные вопросы, запросы вне области действия и попытки обхода системы. **Где взять реальные тест-кейсы?** Из уже полученных обращений: стенограмм звонков, электронных писем, описаний кейсов. Тест-кейсы, написанные командой, как правило, хорошо сформулированы и могут ввести в заблуждение. Самый быстрый способ — взять двести последних обращений и отфильтровать повторяющиеся. **Можно ли полностью полагаться на автоматическую оценку ответов моделью?** Это возможно для некоторых параметров, таких как определение темы, наличие цитаты, соответствие формату и политике. Однако для оценки смысловой точности в чувствительных областях требуется выборочная человеческая экспертиза, поскольку автоматический оценщик склонен подтверждать ответы, которые звучат правдоподобно. Общепринятая практика: автоматизация для всего, ручная оценка для выборки. **Что считается ошибкой, если есть несколько правильных ответов?** Определите критерии приемлемости, а не точный ответ: какие факты должны присутствовать, какие недопустимы и какой источник должен быть процитирован. Таким образом, две разные формулировки могут быть приняты, а ответ, который опускает условие приемлемости, будет отклонен, даже если он хорошо звучит. **Как часто запускать тестовый набор?** Перед каждым выпуском новой версии, а также на регулярной основе в производственной среде для выборочной проверки. Изменение, которое кажется незначительным — обновление инструкций, добавление статьи, изменение действия — может повлиять на поведение в других сценариях, и регрессионное тестирование — единственный способ выявить это до того, как пользователи столкнутся с проблемой. --- ## Observability для Agentforce: как измерять, анализировать и улучшать работу агентов ИИ URL: https://hpi.pro/ru/insights/agentforce-observability Агент без мониторинга - это чёрный ящик, который никто не сможет защитить на совещании с руководством. В нашем руководстве слой мониторинга разделён на три уровня: одиночный диалог, тренды и бизнес-результат. Мы объясним, что обязательно должно отображаться в трассировке, и как превратить неудачные диалоги в еженедельный рабочий процесс вместо отчёта, который никто не читает. ## Краткий ответ Мониторинг агента отличается от мониторинга обычной системы: агент почти никогда не "падает". Он продолжает работать, но с более низким качеством. Поэтому классических метрик доступности и ошибок недостаточно; необходим уровень, измеряющий качество принимаемых решений, а не только техническую исправность. Практическая структура включает три уровня: Trace для анализа отдельного взаимодействия, еженедельные тренды для выявления ухудшений, и метрика бизнес-результата, оправдывающая дальнейшее использование. Каждый уровень отвечает на свой вопрос и предназначен для определенной аудитории. ## Три уровня мониторинга | Уровень | Вопрос, на который он отвечает | Аудитория | Периодичность | | --- | --- | --- | --- | | Trace | Почему это взаимодействие завершилось так? | Техническая команда и аналитик | По мере необходимости | | Тренд | Что меняется к худшему или к лучшему? | Владелец процесса и менеджер платформы | Еженедельно | | Результат | Оправдывает ли агент свое существование? | Руководство и Спонсор | Ежемесячно и ежеквартально | ## Уровень 1: Что обязательно должно быть в Trace Полезный Trace позволяет восстановить принятое решение без дополнительных запросов. Семь компонентов: запрос в его первоначальной формулировке, идентифицированная тема, фактически извлеченные фрагменты, инициированные действия с параметрами, результат каждого действия, точки подтверждения и их решения, а также причина завершения. Наиболее часто упускаемый компонент — это извлеченные фрагменты. Без них невозможно различить два совершенно разных типа сбоев: агент не нашел информацию или нашел ее, но использовал неправильно. Первый устраняется изменением контента, второй — изменением инструкций; неправильное устранение привело к потере недель во всех организациях, с которыми мы работали. Trace также необходимо связать с бизнес-записью: Case, Order или Opportunity. Без этой привязки невозможно проверить, привело ли взаимодействие в конечном итоге к результату или к повторному обращению. ## Уровень 2: Тренды, за которыми стоит следить Пяти метрик достаточно для большинства внедрений: процент завершения без эскалации, процент повторных обращений в течение недели, процент ответов с действительным источником, процент сбоев действий и потребление относительно выполненных задач. Анализ проводится парами. Высокий показатель завершения с высоким показателем повторных обращений не является успехом. Потребление, которое растет при стабильном количестве задач, означает, что агент работает усерднее для того же результата — это ранний признак ухудшения качества контента. Автоматические оповещения настраиваются на относительное изменение, а не на абсолютное значение: скачок в проценте эскалации, снижение процента действительных источников, увеличение сбоев действий в отношении конкретной внешней системы. Связь между этими метриками и затратами подробно описана в разделе [Стоимость Agentforce и TCO](/ru/insights/agentforce-cost-tco). ## Уровень 3: Бизнес-результат Это уровень, который определяет outcome в ежеквартальном обзоре. Две цифры: что изменилось в заранее выбранной метрике процесса — время обработки, отток, объем обращений к агенту — и какова стоимость выполненной задачи по сравнению с базовым уровнем (Baseline). Важно заранее зафиксировать определения и не изменять их после получения результатов. Изменение определения «успеха» в середине пути наносит наибольший ущерб доверию руководства к данным, даже если изменение оправдано. ## От анализа к очереди улучшений Еженедельный отчет не является самоцелью. Результатом является очередь работы. Работающая практика: выборка двадцати неудачных или эскалированных взаимодействий, классификация по корневой причине — пробел в контенте, неправильная разметка, нечеткая инструкция, сбой действия или запрос вне Scope — и создание рабочей задачи только для самой крупной категории. Правило, предотвращающее отклонения: устранять только одну корневую причину в неделю. Организации, пытающиеся исправить пять одновременно, в конечном итоге не знают, что улучшило метрику, а что ухудшило ее. Пробелы в контенте, выявленные здесь, являются прямым вводом в список для написания — процесс подробно описан в разделе [Управление знаниями для Agentforce](/ru/insights/agentforce-knowledge-readiness). ## Сценарий: Тихое снижение, обнаруженное вовремя Финансовая сервисная компания использовала внутреннего агента, который стабильно работал четыре месяца. На пятнадцатой неделе процент эскалации постепенно вырос без жалоб — агенты просто завершали обработку самостоятельно. Уведомление, настроенное на относительное увеличение эскалации, инициировало расследование. Выборка Traces показала, что в половине новых случаев не был извлечен ни один релевантный фрагмент. Причина: изменение в политике продукта привело к автоматическому архивированию одиннадцати статей, а альтернативные не были написаны. Исправление заняло два дня и не потребовало вмешательства в работу агента. Без уровня мониторинга пробел был бы обнаружен только тогда, когда менеджер спросил бы, почему увеличилось среднее время обработки — вероятно, через квартал. ## Риски и превентивные меры | Риск | Как это выглядит | Превентивное действие | | --- | --- | --- | | Только технический мониторинг | Все показатели "зеленые", а качество ответов снижается | Метрики качества и эскалации наряду с метриками доступности | | Trace без извлеченных фрагментов | Месяцы догадок между контентом и моделью | Обязательное логирование извлеченных фрагментов | | Отчет без очереди задач | Данные представлены, но ничего не меняют | Еженедельная выборка и рабочая задача для одной первопричины | | Изменение определений в процессе | Потеря доверия к данным | Заблаговременная фиксация определений успеха | | Отсутствие привязки к бизнес-записи | Невозможно выявить повторное обращение | Привязка Trace к Case или Order | ## Рекомендуемая панель метрик | Метрика | Определение | Порог для оповещения | | --- | --- | --- | | Процент завершения | Завершение без эскалации и без повторного обращения | Значительное относительное снижение неделя к неделе | | Процент эскалации | Процент переходов к человеку | Постоянный относительный рост | | Действительный источник | Процент ответов с существующей и действительной цитатой | Снижение ниже установленного порога | | Сбои действий | Процент неудачных операций по целевой системе | Рост сбоев в отношении конкретной цели | | Потребление на задачу | Единицы потребления на выполненную задачу | Рост без увеличения количества задач | Если требуется сопровождение при создании уровня мониторинга и еженедельного процесса улучшений, [сервис Agentforce и AI](/ru/agentforce-ai) — это практический путь для дальнейшего развития. ## Чек-лист для настройки Observability - ☐ Trace регистрирует запрос, тему, извлеченные фрагменты, действия и результат - ☐ Каждый Trace связан с бизнес-записью - ☐ Политика хранения отделяет метаданные от содержания беседы - ☐ Выбрано всего пять-семь метрик тренда - ☐ Настроены оповещения на относительные изменения, а не на абсолютные значения - ☐ Существует еженедельная процедура выборки неудачных взаимодействий - ☐ Определена таксономия корневых причин сбоев - ☐ Владелец бизнес-процесса участвует в еженедельном обзоре - ☐ Определения success зафиксированы до начала измерения ### Вопросы и ответы **Что обязательно должно быть включено в трассировку диалога?** В трассировку должны входить: исходный запрос пользователя, распознанная тема, фактически извлеченные фрагменты информации, выполненные действия и их параметры, результат каждого действия, точки принятия решений человеком и их исход, а также причина завершения или эскалации. Без извлеченных фрагментов невозможно отличить проблему контента от проблемы модели. **Как долго следует хранить трассировки?** Достаточно долго для исследования квартальных трендов, но в соответствии с политикой хранения данных и регуляторными требованиями. Содержимое диалога, включающее данные клиента, часто хранится меньший срок, чем метаданные. Поэтому принято разделять: метрики и метаданные — для долгосрочного хранения, полное содержимое — для краткосрочного. **Требуются ли внешние инструменты мониторинга?** Не на начальном этапе. Внутренняя панель мониторинга с пятью-семью ключевыми показателями и список неудачных диалогов будут достаточны на первый год. Внешние инструменты оправданы при наличии нескольких агентов, множества каналов и необходимости сопоставления данных с другими системами мониторинга в организации. **Как определить, вызвана ли потеря качества моделью или содержимым?** Следует анализировать этап извлечения данных в трассировке. Если правильный фрагмент не был извлечен, это проблема контента или разметки. Если правильный фрагмент был извлечен, но ответ оказался неверным, проблема заключается в инструкциях или формулировке. Такое разграничение позволяет сэкономить недели догадок и экспериментов. **Кто должен в конечном итоге анализировать данные?** Владелец бизнес-процесса еженедельно, совместно с менеджером платформы. Мониторинг, оставленный исключительно на технической команде, позволяет выявлять сбои, но не обнаруживает ответы, которые технически корректны, но вредны для бизнеса — а это наиболее распространённый тип ошибок. --- ## Создание или покупка в Agentforce: готовые действия, Flow, Apex и API URL: https://hpi.pro/ru/insights/agentforce-build-vs-buy-actions Для каждого действия, выполняемого агентом, существует четыре способа реализации, и различия между ними не только технические: они касаются того, кто будет поддерживать, как тестировать и сколько времени займет внесение изменений. Это руководство предлагает четкий порядок выбора, стоимость обслуживания каждого варианта и случаи, когда Apex является правильным выбором, несмотря на затраты. ## Краткое изложение Действия (Actions) – это момент, когда агент переходит от разговоров к реальным делам, и именно здесь сосредоточены основные риски и затраты на обслуживание. Существует четыре способа реализации: стандартные действия, Flow, Apex и внешние сервисы через API. Выбор между ними — это не вопрос возможностей (почти любое действие можно реализовать любым способом), а вопрос того, кто будет поддерживать, насколько быстро можно вносить изменения и как осуществлять тестирование. Рекомендуемый порядок выбора — сверху вниз: начинаем со стандартного действия, переходим к Flow при необходимости бизнес-логики, к Apex, когда сложность становится реальной, и к внешним сервисам, когда источник истины находится вне Salesforce. Каждое смещение вниз по этой шкале увеличивает затраты на обслуживание и, следовательно, требует обоснования. ## Таблица принятия решений | Реализация | Когда подходит | Кто поддерживает | Цена опции | | --- | --- | --- | --- | | Стандартное действие | Извлечение, обновление поля, создание обращения (Case), суммирование записи | Платформенный администратор | Ограниченная гибкость для бизнес-правил | | Flow | Переменные бизнес-правила, несколько шагов, валидация | Администратор или владелец процесса | Производительность при больших объемах, ограниченная обработка ошибок | | Apex | Сложная логика, массовая обработка, контроль ошибок | Только разработчик | Каждое изменение требует цикла развертывания и тестирования | | Внешние сервисы / API | Источник истины находится вне Salesforce | Команда интеграции | Зависимость от доступности, задержки (Latency) и версий третьей стороны | ## Первое правило: описание до реализации Прежде чем выбирать технологию, составьте описание действия. Это звучит процедурно, но именно этот элемент определяет, выберет ли агент правильное действие. Агент не читает код — он читает описание и принимает решение на его основе. Хорошее описание включает три части: что делает действие, в каких ситуациях его использовать и, что особенно важно, в каких ситуациях не использовать. Последняя строка часто забывается, но именно она предотвращает активацию действия по возврату средств, когда клиент всего лишь спрашивал о политике возврата. Параметры должны быть минимальными и иметь определенный тип. Параметр свободного текстового ввода, куда агент должен ввести значение из закрытого списка, провоцирует ошибки; определенный список значений решает эту проблему без дополнительной логики. ## Когда использовать Flow, а когда Apex Flow является стандартным выбором для бизнес-правил, потому что он нагляден и позволяет владельцу процесса видеть, что происходит. В случае с агентами дополнительным преимуществом является скорость исправления: если обнаруживается, что действие не проверяет условия пригодности, это можно исправить в тот же день. Apex оправдан в четырех случаях: логика с множеством разветвлений, делающая Flow нечитаемым; обработка больших объемов данных за один вызов; необходимость точного контроля над обработкой ошибок и транзакциями; а также интеграция, требующая сложной обработки ответов. Вне этих ситуаций Apex в основном удорожает каждое последующее изменение. Выбор также связан с существующим техническим долгом. Организация, которая уже накопила тысячи строк Apex без тестов, должна дважды подумать, прежде чем добавлять еще один слой — полные соображения представлены в [Flow против Apex](/ru/insights/salesforce-flow-vs-apex). ## Действия с внешними системами Это область, где сбои доходят до конечного пользователя. Перед началом разработки необходимо принять три ключевых решения: каково максимальное время ожидания, что агент сообщает при сбое вызова, и разрешена ли повторная попытка. Идемпотентность — это решающее понятие. Действие чтения можно безопасно повторить. Действие, которое создает запись, отправляет уведомление или списывает средства с карты, при повторной попытке может создать дублирование. Решение состоит в использовании уникального ключа для каждого запроса, который распознается принимающей системой, или в осознанном отказе от повторной попытки. Задержка (Latency) — это не только технический, но и пользовательский фактор. Вызов, занимающий несколько секунд, приемлем в чате, если агент сообщает, что проверяет информацию; вызов, который длится дольше, требует асинхронного подхода — агент подтверждает получение и обновляет статус, когда приходит ответ. Шаблоны обработки ошибок интеграции подробно описаны в статье [Обработка ошибок интеграции в Salesforce](/ru/insights/salesforce-integration-error-handling). ## Разрешения на уровне действия Каждое действие должно быть ограничено отдельным разрешением. Распространенная ошибка — предоставление агенту широкого профиля, который охватывает все действия, тогда нет способа открыть одно действие для определенной группы, не открывая все остальные. Принцип работы: минимальные разрешения для каждого действия, валидация внутри действия, а не только в инструкциях для агента, и проверка того, что действие учитывает контекст пользователя. Нельзя полагаться на то, что инструкции предотвратят активацию — инструкции являются руководством, а не контролем. ## Когда разделять действие Действие, которое выполняет три вещи, является сложным для тестирования и утверждения. Признак для разделения: когда часть действия требует человеческого одобрения, а часть нет; когда разные части требуют разных разрешений; или когда сбой на полпути оставляет процесс в несогласованном состоянии. Разделение немного удорожает оркестрацию, но окупается: каждая часть тестируется отдельно, агент может остановиться между частями, а разрешения являются точными. Практическое правило — одно действие, одно решение. Планирование точек остановки между частями подробно описано в [Human-in-the-Loop в Agentforce](/ru/insights/agentforce-human-in-the-loop). ## Сценарий: организация, перешедшая с Apex обратно на Flow Компания, предоставляющая услуги, разработала шесть действий (Actions) на Apex в рамках пилотного проекта, полагая, что это обеспечит полный контроль. В течение двух месяцев выяснилось, что четыре из них трижды меняли логику – не из-за ошибок, а потому что бизнес-правила выявлялись в процессе использования. Каждое изменение требовало разработчика, тестирования и цикла развертывания продолжительностью в несколько дней. Во втором раунде два действия, оставшиеся на Apex, были теми, которые имели множественные вызовы к внешней системе и сложную обработку ответов. Остальные четыре были переведены на Flow, и ответственность за них взял на себя администратор платформы. Среднее время исправления сократилось с дней до часов. Урок заключался не в том, что Apex плох, а в том, что на этапе, когда правила еще формируются, стоимость изменений важнее, чем первоначальные затраты на разработку. ## Риски и превентивные меры | Риск | Как проявляется | Превентивная мера | | --- | --- | --- | | Смутное описание действия | Агент активирует неверное действие | Описание с указанием "когда да" и "когда нет", и определенными параметрами | | Слепая повторная попытка | Дублирующиеся записи или списания | Уникальный ключ запроса или отказ от повторной попытки | | Широкие разрешения для агента | Чувствительное действие доступно любому пользователю | Отдельное разрешение для каждого действия и валидация внутри действия | | Вся логика в Apex | Каждое бизнес-изменение становится проектом разработки | Flow для изменяющихся правил, Apex для настоящей сложности | | Действие, выполняющее три вещи | Сбой в середине оставляет несогласованное состояние | Разделение по усмотрению и по разрешению | ## Метрики для действий | Метрика | Что она показывает | Частота | | --- | --- | --- | | Процент успешных действий (Action success rate) | Процент успешно завершенных активаций | Еженедельно | | Процент ошибочных действий (Wrong action rate) | Процент случаев неправильного выбора действия | С каждой версией | | Медианная задержка (Latency) для действия | Сохраняется ли приемлемый пользовательский опыт | Еженедельно | | Доля сбоев интеграции | Стабильность целевых систем | Еженедельно | | Среднее время исправления | Позволяет ли выбранная реализация быстро вносить изменения | Ежемесячно | Если требуется сопровождение при планировании слоя Actions и его адаптации к существующей архитектуре, [услуги Agentforce и AI](/ru/agentforce-ai) — это практический путь для дальнейших действий. ## Чек-лист для каждого действия - ☐ Написано описание с указанием "что", "когда да" и "когда нет" - ☐ Параметры минимальны и имеют определенный тип - ☐ Выбрана максимально высокая реализация, достаточная для нужд - ☐ Для действия определено отдельное разрешение - ☐ Валидация находится внутри действия, а не только в инструкциях - ☐ Определена идемпотентность действия и политика повторных попыток (Retry) - ☐ Установлено максимальное время ожидания и сообщение об ошибке для пользователя - ☐ Разделены действия с множеством решений - ☐ Существует тестовый сценарий для сбоя, а не только для успеха ### Вопросы и ответы **Почему бы просто не создавать все в Apex и не завершать проект?** Потому что каждое действие в Apex делает следующее изменение зависимым от разработчика и цикла развертывания. Для действий, основанных на меняющихся бизнес-правилах, Flow позволяет владельцу процесса обновлять их самостоятельно. Apex оправдан, когда требуется сложная логика, массовая обработка или вызов, который требует точного контроля ошибок. **Достаточно ли стандартных действий для пилотного проекта?** В большинстве случаев да, и это сделано намеренно. Пилотный проект, который начинается с извлечения записи, обновления поля и создания обращения, разрабатывается за дни, а не за недели, и позволяет проверить важный вопрос — правильно ли агент выбирает, когда использовать действие — прежде чем инвестировать в разработку. **Как агент узнает, когда активировать определенное действие?** По описанию, которое для него написано. Расплывчатое описание — самая распространенная причина неправильного выполнения действия агентом. Хорошее описание указывает, что делает действие, когда его использовать, и, что особенно важно, когда не использовать, а также использует термины, встречающиеся в вопросах пользователей. **Что происходит, когда вызов к внешней системе прерывается на полпути?** Необходимо заранее определить: понятное сообщение пользователю, запись сбоя в Trace и политика повторных попыток только для идемпотентных операций. Действия, создающие записи или проводящие платежи, нельзя повторять вслепую, иначе возникнут дубликаты. **Когда стоит разделять одно действие на несколько операций?** Когда действие выполняет более одной функции, или когда часть его требует человеческого одобрения, а часть нет. Разделение позволяет назначить разные разрешения для каждой части, тестировать каждую часть по отдельности и позволить агенту остановить процесс на полпути, не оставляя его незавершенным. --- ## Управление знаниями для Agentforce: подготовка неструктурированных данных для ИИ URL: https://hpi.pro/ru/insights/agentforce-knowledge-readiness База знаний, созданная для людей, не подходит для ИИ-агентов: она содержит противоречивые версии, документы без владельцев и смешанный внутренний и клиентский контент. Данное руководство представляет пятиступенчатый процесс подготовки — аудит, архивация, структурирование, тегирование и назначение владельцев — с пороговыми значениями индексации и долгосрочной моделью поддержки. ## Краткий Обзор Корпоративная база знаний часто создается для людей, способных восполнять пробелы, распознавать устаревшие документы и обращаться к коллегам за помощью. Агент не способен ни на одно из этих действий. Следовательно, подготовка контента для агента подразумевает в основном его удаление, принятие решений и тегирование, а не добавление нового. Практический процесс включает пять этапов: аудит полноты и актуальности, архивирование противоречивых и устаревших материалов, реорганизация структуры статей, тегирование для удобства извлечения и назначение ответственных с соглашением об уровне обслуживания (SLA) для поддержания актуальности. Пятый этап определяет, насколько долгосрочными будут инвестиции. Принципы извлечения контента слоем Retrieval обсуждаются в статье [Grounding и RAG в Agentforce](/ru/insights/agentforce-grounding-rag). ## Этап 1: Целенаправленный Аудит Не следует проверять всю базу данных. Вместо этого составляется список сценариев, которые будет обрабатывать агент, и формируется перечень реальных вопросов, взятых из фактически поступивших обращений, а не вымышленных. Для каждого вопроса проверяется: наличие статьи, дата последнего обновления, ответственный и актуальность ответа на текущий момент. Результатом являются четыре категории: содержание актуально и покрыто, содержание покрыто, но устарело, содержание покрыто несколькими противоречивыми версиями, и содержание отсутствует. Третья категория наиболее рискованна, поскольку она приводит к тому, что агент выдает различные ответы на один и тот же вопрос. Выявленный в четвертой категории пробел не всегда является проблемой — он становится основой для нового контента, а пока остается списком тем, требующих участия человека. ## Этап 2: Архивирование до Написания Самое сложное в организациях — это принятие решения об удалении. Однако устаревшая статья в базе знаний наносит больший ущерб, чем отсутствующая: отсутствие приводит к эскалации, а устаревшая статья приводит к ошибочному, но уверенному ответу. Простое рабочее правило: любая статья, не имеющая владельца и не обновлявшаяся в течение определенного для ее области срока, исключается из индекса. Она может оставаться в архиве для документации, но недоступна для агента. В случае конфликта между двумя версиями решение принимает владелец контента, а не техническая команда. Это требует бизнес-решения, и его игнорирование приводит к возвращению проблем на этапе тестирования. ## Этап 3: Структура Статьи Хорошая структура для агента также хороша и для читателя, поэтому это не дублирующая работа. Заголовок формулируется как вопрос или сценарий на языке, используемом пользователями, а не на внутреннем жаргоне. Первый абзац содержит краткий и самодостаточный ответ. Детали излагаются в разделах с подзаголовками. Два правила, непосредственно влияющие на качество извлечения информации: условия соответствия и исключения должны быть в отдельном и помеченном разделе, а не вплетены в предложение; таблицы должны быть небольшими и самодостаточными, так как обрезанная таблица приводит к частичному ответу. Чего следует избегать: длинных статей, охватывающих пять тем. Лучше разбить их на пять сфокусированных статей — извлечение будет точнее, а обслуживание легче. Более широкие принципы управления знаниями в Service Cloud подробно изложены в [Управление Knowledge в Salesforce](/ru/insights/salesforce-knowledge-management). ## Этап 4: Тегирование и Разделение Аудиторий Минимальное тегирование, необходимое почти в каждой организации: продукт или линия услуг, рынок или страна, язык, целевая аудитория, статус утверждения и срок действия. В глобальной организации отсутствие тегов для рынка и языка — основная причина неверных ответов: агент с полной уверенностью извлечет политику другой страны. Разделение аудиторий — это решение в области безопасности, а не только классификация. Контент, написанный для представителей, иногда содержит скидки, формулировки для обработки возражений и информацию о конкурентах. В клиентском канале по умолчанию должен действовать принцип белого списка: только контент, явно помеченный как разрешенный для клиента, становится доступным. Документ, большая часть которого разрешена, но один абзац содержит конфиденциальную информацию, не является редким исключением — это часто встречающаяся ситуация. Решение состоит в разделении документа, а не в пометке всего документа как внутреннего. ## Этап 5: Ответственность и Обслуживание Этот этап определяет долгосрочную устойчивость результата. За каждой областью знаний закрепляется ответственный, устанавливается частота проверки и определяется, что происходит по истечении срока действия статьи — автоматическое удаление из индекса, а не оповещение, которое никто не читает. Механизм обратной связи делает обслуживание эффективным. Каждое обращение, завершившееся эскалацией из-за отсутствия источника, добавляется в список пробелов в контенте, что является наилучшим приоритетным списком для создания нового контента. Лучше написать пять статей, которые действительно необходимы, чем пятьдесят, которые казались важными. Бюджетирование: поддержка контента — это постоянная статья расходов, а не проект. Организации, которые относятся к ней как к разовой задаче, видят снижение точности ответов в течение двух кварталов. ## Пороги Входа в Индекс | Критерий | Минимальный Порог | Причина | |---|---|---| | Ответственность | Ответственный по имени для каждой статьи | Без ответственного нет того, кто будет обновлять | | Актуальность | В рамках определенного для области периода проверки | Предотвращает цитирование отмененной политики | | Уникальность | Единственный источник для каждой темы | Предотвращает противоречивые ответы | | Аудитория | Помечено как внутреннее или разрешенное для клиента | Предотвращает раскрытие конфиденциальной информации | | Структура | Вопрос в заголовке и краткий ответ в начале | Улучшает точность извлечения | ## Сценарий: 1400 Документов Уменьшены до 190 Поставщик ИТ-услуг планировал подключить агента к папке SharePoint с 1400 документами. Первоначальная проверка показала, что только около 30% из них были обновлены за последние три года, и около 200 были черновиками или рабочими версиями. Вместо проекта генеральной очистки команда определила 25 сценариев, которые должен был охватывать агент. Из всей базы данных было найдено 190 релевантных документов; из них 40 были противоречивыми и требовали решения от трех владельцев областей знаний. Выбранные документы были разделены на сфокусированные статьи и помечены по продукту и аудитории. Пилот был запущен со 190 элементами вместо 1400, и точность ответов была значительно выше, чем в первой попытке. Остальная часть базы данных осталась в архиве и постепенно добавлялась в соответствии со списком пробелов, накапливающимся в результате реальных эскалаций. ## Риски и Превентивные Меры | Риск | Как проявляется | Превентивные меры | |---|---|---| | Включение всей базы данных | Низкая точность и трудность выявления причины | Включение по сценариям, а не по всей базе данных | | Статьи без владельца | Тихое устаревание | Ответственность как условие входа в индекс | | Противоречивые версии | Разные ответы на один и тот же вопрос | Бизнес-решение и архивирование | | Смешивание внутреннего и внешнего контента | Раскрытие конфиденциальной информации клиенту | Белый список для внешнего канала | | Обслуживание как одноразовый проект | Снижение точности в течение двух кварталов | Постоянное бюджетирование и SLA на обновление | ## Метрики Готовности Контента | Метрика | Определение | Частота | |---|---|---| | Покрытие сценариев | Процент сценариев с утвержденной статьей | Ежемесячно | | Актуальность | Процент статей в индексе в рамках срока действия | Ежемесячно | | Дублирование тем | Количество тем с более чем одним источником | Ежеквартально | | Пробелы из эскалаций | Количество новых тем, которые потребовались, но отсутствовали | Еженедельно | | Среднее время обновления | Сколько времени требуется для исправления ошибочной статьи | Ежемесячно | Если требуется поддержка в подготовке базы знаний и создании модели обслуживания, [услуга Agentforce и ИИ](/ru/agentforce-ai) является практическим путем для дальнейших шагов. ## Чек-лист для Подготовки Знаний - ☐ Составлен список реальных вопросов на основе фактических обращений. - ☐ Каждый вопрос классифицирован: актуальный, устаревший, противоречивый или отсутствующий. - ☐ Статьи без владельцев архивированы или им назначен владелец. - ☐ Конфликты разрешены владельцем контента. - ☐ Статьи структурированы: заголовок-вопрос, краткий ответ, разделы. - ☐ Условия соответствия и исключения находятся в отдельном разделе. - ☐ Проведено тегирование по продукту, рынку, языку, аудитории и сроку действия. - ☐ Внутренний контент отделен от контента, одобренного для клиента. - ☐ Определена частота проверки и автоматическое удаление по истечении срока действия. - ☐ Создан механизм преобразования эскалаций в список для написания нового контента. ### Вопросы и ответы **Нужно ли переписывать все статьи перед началом работы?** Нет. Начинайте с тех сценариев, которые агент будет обрабатывать в первой версии — обычно это двадцать-сорок статей. Массовый пересмотр базы знаний, состоящей из сотен статей, займет месяцы и часто будет остановлен на полпути, в то время как целенаправленная подготовка достаточна для пилотного проекта. **Что делать со статьями без владельцев?** Либо назначьте владельца, либо архивируйте. Статья без владельца будет продолжать устаревать, а агент продолжит ее цитировать. Это неудобное решение, но оно значительно дешевле, чем обнаружить впоследствии, что агент сообщил о политике, отмененной два года назад. **Как выявлять противоречивые статьи в большой базе знаний?** Сгруппируйте их по темам и вручную проверьте только те группы, где более одной статьи. Можно также задать самому агенту двадцать наиболее частых вопросов и посмотреть, какие источники были извлечены — конфликт обнаруживается немедленно, когда появляются две статьи с разными ответами. **Подходят ли PDF и документы Word в качестве источника?** Менее оптимально, чем структурированная статья, но возможно, если документ разделен на разделы с четкими заголовками. Отсканированный документ, презентация или файл со сложными таблицами являются проблемным источником, и предпочтительнее извлечь из них соответствующий контент для специализированной статьи. **Какова правильная структура статьи, предназначенной также для агента?** Вопрос или сценарий в качестве заголовка, краткий ответ в первом абзаце, а затем подробности в подразделах с подзаголовками. Условия получения права и исключения в отдельном разделе, а не в одном предложении. Такая структура служит и для человека-читателя, поэтому компромиссов здесь нет. --- ## Управление ИИ для Agentforce: Модель ответственности, рисков и контроля URL: https://hpi.pro/ru/insights/agentforce-ai-governance Неэффективное управление ИИ проявляется двумя крайностями: либо комитет блокирует все инициативы, либо отсутствие контроля обнаруживается только во время аудита. Данное руководство представляет многоуровневую модель рисков: кто что утверждает, какие обязательные меры контроля необходимы на каждом уровне, какие документы действительно требуются и как поддерживать скорость, не жертвуя ответственностью. ## Краткий ответ Эффективное управление ИИ не является дополнительным уровнем согласований, а представляет собой механизм, позволяющий быстро принимать решения по повторяющимся вопросам: кто определяет полномочия агента, какие обязательные контроли требуются в зависимости от уровня риска, и что необходимо для изменения поведения после запуска. Без такого механизма внедрение каждого нового агента будет начинаться с нуля. Ключевой принцип — это ранжирование. Внутренний агент, который только читает информацию и ничего не записывает, не должен проходить тот же путь, что и агент, который общается с клиентами и выполняет возвраты средств. Единообразный процесс приводит либо к блокировке, либо к обходу, а зачастую и к тому, и другому. ## Классификация рисков: основа всех остальных решений | Уровень | Характеристики | Утверждающие стороны | Обязательные контроли | |---|---|---|---| | Низкий | Внутренний, только чтение, без чувствительных данных клиентов | Владелец процесса + менеджер платформы | Утвержденный Grounding, журнал разговоров, ежемесячный обзор | | Средний | Внутренний с обратимой записью или раскрытием информации клиенту | + Архитектор + Представитель отдела данных | Тестовый набор, проверки Persona, еженедельный мониторинг | | Высокий | Операции с клиентами, денежные средства, разрешения или необратимые данные | + Отдел рисков, юридический отдел и CISO | Человеческое утверждение, полный Audit trail, план отката | | Запрещено | Решения с прямыми юридическими или регуляторными последствиями без участия человека | - | Сценарий использования отклонен или разбит на подзадачи более низкого уровня | Классификация определяется всего тремя вопросами: является ли действие обратимым, кто подвергается воздействию результата и какой тип информации затрагивается в процессе. На эти три вопроса можно ответить за десять минут, и именно это делает модель применимой. ## Три обязательные роли **Бизнес-владелец** отвечает за результат, определяет полномочия агента и разрешает конфликты. Он должен будет объяснить руководству, почему агент ответил именно так, поэтому эту роль нельзя оставлять вакантной или делить между двумя менеджерами. **Технический владелец** отвечает за реализацию, мониторинг, процесс изменений и стоимость. Он ведет реестр агентов и Runbook для устранения сбоев. **Независимый аудитор** (чаще всего представитель отдела рисков или информационной безопасности) не участвует в разработке и поэтому может осуществлять проверку. Его задача — выборочно просматривать разговоры, проверять соответствие заявленных контролей фактической работе и выносить результаты на рассмотрение коллегиального органа. Без вовлечения стороны, не заинтересованной в успехе проекта, контроль превращается в самоотчет. Модель ответственности при работе с Salesforce и поставщиками моделей подробно описана в документе [Безопасность Agentforce и совместная ответственность](/ru/insights/agentforce-security-shared-responsibility). ## Реестр агентов Это единственный документ, который нельзя игнорировать. Он не обязательно должен быть сложной системой — достаточно поддерживаемой таблицы — но он должен быть актуальным. Для каждого активного агента необходимо указать: цель в одном предложении, бизнес- и технического владельцев, уровень риска, активные каналы, список Actions и их разрешения, источники Grounding, точки человеческого утверждения, дату последнего обзора и три основных KPI. Реестр решает проблему, которая возникает на второй год: бесконтрольное распространение агентов. Когда каждая команда создает своего агента, обнаруживается, что три агента отвечают на один и тот же вопрос тремя разными способами, и никто не знает, кто утвердил третьего. ## Процесс изменений после запуска Различение рутинных и существенных изменений предотвращает парализующее управление. Рутинное изменение (формулировка, исправление формулировки в ответе, добавление существующей статьи Knowledge в индекс) проходит по стандартному процессу изменения платформы. Существенное изменение требует повторного утверждения на соответствующем уровне. Четыре изменения всегда являются существенными: добавление нового Action, расширение разрешения, открытие нового канала и удаление или смягчение точки человеческого утверждения. Именно эти изменения часто вносятся тихо под давлением с целью улучшения производительности, поэтому их необходимо заранее маркировать. Механизмы мониторинга, питающие процесс изменений, подробно описаны в документе [Наблюдаемость для AI-агентов](/ru/insights/agentforce-observability). ## Что фактически проверяет управление ежеквартально Ежеквартальный обзор не является отчетом о состоянии. Он проверяет пять вещей: по-прежнему ли агенты в реестре необходимы, работают ли заявленные контроли при выборочной проверке, оправдана ли стоимость по сравнению с результатом, какие повторяющиеся эскалации указывают на пробелы в контенте и прошли ли существенные изменения правильный путь. Результатом обзора является список решений: расширить, сократить, приостановить или закрыть агента. Управление, неспособное закрыть агента, не является управлением — это документация. ## Сценарий: ритейлер, который восстановил контроль, не останавливая развитие Розничная сеть обнаружила семь одновременных инициатив в области ИИ в четырех отделах, без регистрации и без ведома отдела рисков. Первой предложенной реакцией было полное замораживание до разработки политики — шаг, который также заморозил бы две инициативы, уже приносящие ценность. Вместо этого было проведено двухнедельное картирование: каждая инициатива была классифицирована по уровню риска. Пять были отнесены к низкому уровню и продолжили работу с сокращенным согласованием со стороны владельца процесса и менеджера платформы. Две (одна касалась возврата средств клиентам, а другая раскрывала данные инвентаризации поставщикам) были переведены на высокий уровень, получили точки человеческого утверждения и были проверены отделом рисков перед продолжением. Шесть месяцев спустя количество инициатив увеличилось, но руководство впервые знало, что существует, кто отвечает и какова стоимость. Практический вывод: управление получило легитимность именно потому, что оно не блокировало низкий уровень риска. ## Риски управления и превентивные меры | Риск | Как это проявляется | Превентивная мера | |---|---|---| | Блокирующий комитет | Команды разрабатывают решения вне утвержденного процесса | Ускоренный процесс для низкого уровня риска с участием всего двух утверждающих | | Неактуальный реестр | Аудитор обнаруживает неизвестного агента | Обновление реестра как условие выпуска новой версии | | Принадлежность только ИТ | Нет ответственного за бизнес-поведение | Назначение бизнес-владельца по имени для каждого агента | | Самоотчетность контроля | Контроли существуют в документе, но не в реальности | Выборочная проверка разговоров стороной, не участвующей в разработке | | Существенное изменение без уведомления | Удаление человеческого утверждения для улучшения времени отклика | Закрытый список изменений, требующих повторного утверждения | ## Показатели управления | Показатель | Что он выявляет | Частота | |---|---|---| | Полнота реестра | Процент документированных активных агентов | Ежемесячно | | Среднее время утверждения | Стал ли процесс узким местом | Ежемесячно | | Выводы выборочной проверки | Разрыв между заявленным контролем и фактическим состоянием | Ежеквартально | | Существенные изменения, проходящие по правильному пути | Дисциплина процесса | Ежеквартально | | Приостановленные или закрытые агенты | Способно ли управление принимать решения об отказе | Ежеквартально | Когда требуется сопровождение в создании модели управления, соответствующей размеру организации и применимому регулированию, [услуги Agentforce и AI](/ru/agentforce-ai) представляют собой практический путь для дальнейшего развития. ## Чек-лист для создания системы управления - ☐ Утверждена трехступенчатая модель классификации рисков. - ☐ Определены утверждающие стороны для каждого уровня, включая ускоренный путь для низкого уровня риска. - ☐ Назначены бизнес- и технический владельцы для каждого существующего агента. - ☐ Назначен независимый аудитор, не участвующий в разработке. - ☐ Создан реестр агентов со всеми обязательными полями. - ☐ Определен закрытый список существенных изменений. - ☐ Установлен ежеквартальный график обзоров с полномочиями по закрытию агента. - ☐ Определены показатели управления и частота отчетности для руководства. ### Вопросы и ответы **Требуется ли отдельный комитет по ИИ или можно использовать существующие форумы?** В большинстве организаций предпочтительнее расширить существующий форум — комитет по изменениям или архитектуре — добавив в него представителей отделов рисков и юридического отдела для обсуждения вопросов ИИ. Отдельный комитет, как правило, встречается раз в месяц и становится узким местом, что приводит к обходу его командами. **Кто является владельцем агента: бизнес или ИТ?** Владелец бизнес-процесса является владельцем результата и решения о том, что может делать агент. ИТ-отдел является владельцем реализации, мониторинга и стабильности. Когда владение остается только за ИТ, никто не принимает решений по вопросам поведения, и агент «замораживается» в первой версии. **Требуется ли разрешение на каждое изменение в инструкциях?** Нет. Изменение формулировки для агента с низким риском может быть выполнено в рамках обычного процесса изменений. Изменение, расширяющее полномочия, добавляющее действие, открывающее новый канал или отменяющее точку человеческого одобрения, является существенным изменением, требующим повторного одобрения на соответствующем уровне. **Что именно должно быть в реестре агентов?** Для каждого активного агента: цель в одном предложении, бизнес-владелец, классификация риска, каналы, список действий и их разрешения, источники обоснования, точки человеческого подтверждения, дата последнего обзора и метрики производительности. Это первый документ, который запросит любой аудитор. **Как предотвратить замедление разработки из-за управления?** Определите ускоренный путь для низкого риска: агент только для чтения во внутреннем канале утверждается владельцем процесса и менеджером платформы без участия комитета. По мере возрастания риска добавляются утверждающие лица и меры контроля. Единый путь для каждого агента является наиболее распространенной причиной обхода управления. --- ## Lead-to-Cash в Sales Cloud: Проектирование полного цикла продаж – от лида до заказа URL: https://hpi.pro/ru/insights/salesforce-lead-to-cash Процесс Lead-to-Cash практически всегда характеризуется тремя критическими точками перехода: от лида к сделке, от сделки к утвержденному коммерческому предложению и от предложения к заказу в ERP. Данное руководство описывает обязательные конфигурации для каждой из этих точек, объясняет, как принять решение о месте хранения ценовой информации, и почему утверждение скидок часто становится реальным узким местом. ## Краткий ответ Процесс Lead-to-Cash охватывает четыре функциональных направления — маркетинг, продажи, финансы и операции — и, как правило, затрудняется на границах между ними, а не в центральных частях. Три ключевые точки перехода определяют всю его эффективность: когда обращение трансформируется в сделку, когда коммерческое предложение получает одобрение, и когда закрытая сделка преобразуется в заказ в операционной системе. В каждой из этих точек необходимо четко определить три аспекта: кто принимает решение, что требуется для успешного перехода, и что происходит в случае неудачи. Отсутствие хотя бы одного из этих ответов приводит к появлению обходных решений (например, таблиц Excel), что, в свою очередь, порождает большинство расхождений между фактически проданным и выставленным к оплате. ## Точка перехода 1: от обращения к сделке Эта граница определяет качество всего пайплайна. Типичная ошибка — автоматическое преобразование каждого обращения в сделку, что раздувает прогноз и обесценивает историю конверсии. Необходимые элементы: четкие критерии конверсии (авторитетный контакт, сформулированная потребность, временной горизонт), назначенный владелец для каждой стороны границы, и правило обработки обращений, не соответствующих критериям — их развитие (Nurture), а не удаление. Более подробная информация представлена в [Внедрение Sales Cloud](/ru/insights/sales-cloud-implementation). ## Точка перехода 2: от предложения к одобренному предложению Здесь сосредоточена большая часть задержек в процессе, и почти всегда это связано не с инструментом, а с неопределенной иерархией согласований. | Компонент | Что должно быть определено | Что происходит без этого | | --- | --- | --- | | Каталог и прайс-лист | Единый источник истины для ценообразования | Предложения с ручным указанием цен | | Порог скидки | Иерархия в зависимости от процента и типа клиента | Каждая скидка либо идет к CEO, либо не предоставляется | | Время реакции на одобрение | Установленная цель, например, один рабочий день | Телефонные обходы и постфактум документирование | | Неценовые условия | Условия оплаты, гарантия, SLA | Обязательства, не дошедшие до финансовых отделов | Последний пункт часто игнорируется: организации создают строгий контроль скидок, но позволяют представителю обещать отсрочку платежа +90 дней без какого-либо одобрения. ## Точка перехода 3: от закрытой сделки к заказу Это самая техническая точка, и именно здесь возникают самые дорогостоящие сбои. Три вопроса, определяющие архитектуру: 1. **Кто выдает заказ** — обычно ERP. Salesforce отправляет запрос и получает идентификатор, не управляя запасами или выставлением счетов. 2. **Что происходит при сбое** — требуется видимый статус сделки, уведомление владельцу процесса и идемпотентный механизм повторной отправки, который не создаст дублирующий заказ. 3. **Что возвращается обратно** — как минимум, идентификатор заказа, статус доставки и статус оплаты. Без этого возврата представители продаж звонят в финансовый отдел, чтобы ответить клиенту. Принципы проектирования самой интеграции подробно описаны в [Интеграция Salesforce и ERP](/ru/insights/salesforce-erp-integration), а обработка сбоев — в [Обработка ошибок в интеграциях Salesforce](/ru/insights/salesforce-integration-error-handling). ## Скрытая проблема: согласование продуктов между системами Большинство расхождений между коммерческим предложением и счетом вызваны не ценой, а продуктом. Это может быть артикул, существующий в ERP, но отсутствующий в Salesforce, продукт, снятый с производства в одной системе, но остающийся активным в другой, или различные единицы измерения. Правило: Каталог продуктов является собственностью только одной стороны — как правило, ERP — и синхронизируется с Salesforce с заданной периодичностью, включая маркировку снятых с производства продуктов вместо их удаления. Удаление повреждает исторические сделки и искажает аналитику. ## Что измерять | Метрика | Что она выявляет | | --- | --- | | Среднее время одобрения предложения | Наиболее распространенное узкое место | | Доля повторно созданных предложений | Признак неясного ценообразования или неполного каталога | | Сбои при создании заказа | Стабильность интеграции | | Разница между суммой сделки и суммой счета | Качество сквозного процесса | | Закрытые сделки без заказа в течение 48 часов | Обращения, потерянные между системами | Последняя метрика — самый простой тест на "здоровье" процесса, но немногие организации регулярно ее отслеживают. ## Последовательность внедрения Вначале полностью реализуется один сценарий продаж от начала до конца — один тип клиента, одна категория продукта — до успешного создания заказа в ERP. Только после того, как этот сценарий станет стабильным, добавляются различные конфигурации, валюты, юридические лица и возобновления. Преждевременное расширение закрепляет ценовые решения до их проверки на практике. ## Заключение Lead-to-Cash — это не технологический проект, а соглашение между четырьмя функциональными направлениями о трех границах процесса. Тот, кто письменно определяет эти границы, включая сценарии сбоев, получает процесс, который можно измерять; тот, кто начинает с инструментов, получает цепочку, которая работает в демонстрации, но фактически держится на телефонных звонках. ### Вопросы и ответы **Обязательно ли использовать CPQ для управления Lead-to-Cash?** Нет. Стандартных каталогов продуктов и прайс-листов достаточно при простом ценообразовании. CPQ требуется, когда есть зависимые конфигурации, многоуровневые скидки, возобновления или подписочное ценообразование. **Где должно храниться ценообразование — в Salesforce или в ERP?** Прейскурантные цены могут храниться в обеих системах, но только одна из них должна быть источником истины и передавать данные в другую. Ценообразование, определяемое параллельно в двух системах, приводит к расхождениям между предложением и счетом. **Что делать, если заказ не проходит в ERP?** Необходим определенный сценарий обработки сбоев: четкий статус заказа, оповещение для ответственного за процесс и возможность повторной отправки без создания дубликатов. Без этого закрытые сделки могут теряться между системами. **Кто утверждает превышение скидки?** Необходима иерархическая система утверждений пороговых значений и типов отклонений с определенным временем ответа. Задержка утверждения более чем на один рабочий день приводит к телефонным обходам и потере контроля. **Нужен ли объект Order в Salesforce?** Когда ERP генерирует заказ, часто достаточно отразить статус и идентификатор. Полный объект Order оправдан, когда одной сделке соответствует несколько заказов, частичные поставки или возобновления, управляемые на стороне CRM. --- ## Прогнозирование и дашборды в Sales Cloud: Как создать прогноз, которому можно доверять URL: https://hpi.pro/ru/insights/salesforce-forecast-dashboards Если менеджер по продажам ведет прогноз в отдельной таблице, проблема не в дашборде. Надежный прогноз базируется на четырех предварительных условиях: корректная иерархия, чистые даты закрытия, согласованные категории и регулярный цикл обзора. Это руководство объясняет, как их выстроить, и что измерять для оценки реального улучшения прогноза. ## Краткий ответ Прогноз является результатом дисциплины данных, а не функцией дашборда. Если сделки обновляются раз в неделю вечером перед совещанием по воронке продаж, то никакой дизайн отчета не даст достоверной картины. Поэтому работа над прогнозом начинается с четырех операционных условий, и только потом переходит к представлению. Явный признак несоблюдения условий легко определить: существует параллельная таблица прогноза. Пока она существует, сама организация заявляет, что система не является источником истины. ## Четыре предварительных условия | Условие | Что требуется | Что происходит без этого | | --- | --- | --- | | Корректная иерархия пользователей | Иерархия ролей (Role Hierarchy), отражающая фактическую структуру продаж | Неверное агрегирование прогноза на уровне руководителя | | Чистые даты закрытия | Правило, запрещающее истекшие даты более чем на неделю | Прогноз, включающий «мертвые» сделки | | Согласованные категории | Письменное определение для Pipeline, Best Case, Commit | Каждый руководитель интерпретирует по-своему | | Регулярный цикл обзора | Еженедельное совещание в системе | Задним числом обновление перед совещаниями | Четвертое условие создает первые три. Как только совещание проводится с экрана, а не из таблицы, представители обновляют данные, потому что иначе их сделки не отображаются. ## Категории прогноза: Где проявляется человеческая оценка Распространенная путаница возникает между вероятностью и категорией. Вероятность выводится из этапа и используется для взвешенного расчета — это статистика. Категория — это декларация обязательства человека. Корректное разделение выглядит так: этап определяет автоматическую вероятность, которую никто не вправе изменять; менеджер по работе с клиентами классифицирует сделку как Best Case или Commit на основе знакомства с клиентом; а руководитель команды может изменить классификацию при обзоре с документированием. Таким образом, получаются два числа с разным значением — статистический прогноз и управленческое обязательство — вместо одного неопределенного числа. Определение самих этапов продаж, из которых выводится вероятность, подробно описано в [Внедрение Sales Cloud](/ru/insights/sales-cloud-implementation). ## Три дашборда, не тридцать Множество дашбордов — признак того, что никто не доверяет существующим. Рабочая структура: 1. **Прогноз для руководства** — одно число на квартал с разбивкой по категориям, сравнение с целью и еженедельный тренд. Без детализации сделок. 2. **Воронка продаж для управления командой** — сделки по этапу и возрасту, с выделением отклонений: сделки, которые не двигались, просроченные даты, измененные суммы. 3. **Рабочий список для представителя** — что требует действий сегодня. Не отчет, а очередь задач. Простая проверка: если два дашборда показывают одно и то же число с разными значениями, по крайней мере один из них избыточен или неверен. ## Измерение точности прогноза Это показатель, который большинство организаций не измеряют и, следовательно, не знают, улучшились ли они: - **Отклонение Commit** — разница между суммой Commit в начале квартала и фактическим результатом. Отклонение более 20% указывает на нечеткое определение Commit. - **Стабильность прогноза** — насколько изменился прогноз от недели к неделе. Высокая волатильность указывает на позднее обновление, а не на динамичный рынок. - **Slippage** — сделки, отложенные на следующий квартал. Высокий процент указывает на слабые критерии этапов. - **Точность по представителю** — выявляет, кто систематически завышает, а кто консервативен, и позволяет скорректировать индивидуально вместо общего корректирующего коэффициента. Дополнительные показатели внедрения представлены в [Показатели использования Salesforce](/ru/insights/salesforce-adoption-metrics). ## Повторяющаяся ошибка: Создать отчет вместо исправления процесса Когда прогноз неточен, распространенная реакция — запросить дополнительные срезы: по продукту, по региону, по источнику. Это создает отчетную нагрузку и скрывает истинную причину. Если 30% сделок имеют просроченную дату, никакой срез не поможет. Правильная последовательность: исправить качество данных, закрепить цикл обзора, измерять точность в течение квартала, и только потом рассматривать дополнительные срезы. ## Заключение Надежный прогноз — это результат управленческой практики, поддерживаемой системой, а не инструмента прогнозирования. Три вопроса, которые определяют, достигли ли вы этого: существует ли параллельная таблица, все ли согласны с тем, что входит в Commit, и измеряет ли кто-либо точность прогноза ретроспективно. Три хороших ответа стоят больше, чем любое усовершенствование дашборда. ### Вопросы и ответы **Почему прогноз в системе отличается от прогноза менеджера по продажам?** Почти всегда из-за несогласованного определения «Commit»: менеджер включает сделки в прогноз, основываясь на знании клиента, а система рассчитывает их по этапу. Решение – четко зафиксированное определение того, что входит в «Commit», и кто имеет право вносить изменения. **Следует ли использовать автоматическую вероятность или экспертное суждение специалиста?** И то, и другое, но раздельно. Вероятность определяется этапом и используется для взвешенного расчета; человеческое суждение выражается в категории прогноза. Смешивание этих подходов – когда специалист вручную переопределяет проценты – нивелирует оба. **Сколько дашбордов необходимо?** Обычно три: прогноз для руководства, воронка продаж для управления командой и список задач для специалиста. Избыток дашбордов приводит к противоречивым версиям одних и тех же данных. **Что делать со сделками, даты закрытия которых истекли?** Строгое операционное правило: сделка с просроченной датой более чем на неделю требует обновления или перевода в «Закрыто-Потеряно». Без этого любой расчет прогноза будет основываться на неверных данных. **Как быстро можно ожидать улучшения точности?** Обычно после двух-трех полных циклов продаж – это минимальное время, необходимое для накопления достаточного количества сделок, управляемых по новым правилам, чтобы сравнивать прогноз с фактическим результатом. --- ## Omni-Channel и SLA в Service Cloud: планирование маршрутизации и пропускной способности URL: https://hpi.pro/ru/insights/service-cloud-omnichannel-sla Omni-Channel часто не справляется со своими задачами не из-за настроек маршрутизации, а из-за модели пропускной способности: когда чат, электронные письма и телефонные звонки оцениваются по одной и той же единице измерения, операторы либо перегружены, либо простаивают. В этом руководстве объясняется, как задать весовые коэффициенты для расчёта нагрузки, связать права (Entitlements) с маршрутизацией, а также как заблаговременно определить, что модель не выдерживает нагрузку. ## Краткий ответ Omni-Channel — это не механизм распределения, а модель загрузки. Он постоянно задает один вопрос: какой объем работы может выполнить этот агент прямо сейчас? Если ответ на этот вопрос ошибочен (например, если чат и электронная почта имеют одинаковый вес), маршрутизация будет работать точно по заданным правилам и ухудшит качество обслуживания. Поэтому оптимальная последовательность действий такова: сначала модель загрузки и весовые коэффициенты, затем навыки, затем Entitlements и Milestones, и только в конце автоматизация эскалации. ## Модель загрузки: определяющий фактор **Omni-Channel** назначает каждому агенту «квоту работы» (Capacity), а каждому рабочему элементу — вес. Центр обработки вызовов, который устанавливает одинаковый вес для всех каналов, получает один из двух результатов: либо агенты в чате перегружены, либо агенты, работающие с электронной почтой, выглядят занятыми, хотя на самом деле свободны. Разумная отправная точка для калибровки: | Тип работы | Характеристика | Рекомендуемый относительный вес | | --- | --- | --- | | Телефонный звонок | Полностью синхронно | Занимает всю загрузку | | Живой чат | Синхронно с короткими паузами | Высокий, обычно не более 2-3 одновременно | | Электронная почта / Форма | Асинхронно | Низкий | | Обращение в ожидании ответа клиента | Неактивно | Ноль — должно освобождать загрузку | Последняя строка часто является источником ошибок: обращение, ожидающее ответа клиента, которое продолжает занимать загрузку, приводит к тому, что агенты выглядят занятыми, хотя у них нет активной работы. ## Навыки: меньше значит больше Маршрутизация на основе навыков (Skills-Based Routing) кажется очевидным улучшением, но на практике это частая причина застревания запросов. Чем больше требований к навыкам добавляется, тем выше вероятность отсутствия свободного агента, отвечающего им всем. Три правила, которые помогают этого избежать: определять навыки только тогда, когда их отсутствие действительно препятствует обработке; для каждого требования определять уровень Fallback, который активируется после заданного времени ожидания; и ежемесячно проверять, сколько запросов было распределено через Fallback — высокий процент указывает на то, что модель не соответствует кадровому обеспечению центра. ## Entitlements и Milestones: от обязательства к механизму SLA, которое появляется только в отчете, — это постфактум. Entitlements и Milestones превращают его в активный механизм: 1. **Entitlement** определяет, какой клиент имеет право на какой уровень обслуживания — обычно это один стандартный уровень и несколько договорных исключений. 2. **Milestone** определяет измеряемые временные точки: первый ответ, периодическое обновление, разрешение. 3. **Business Hours** определяют, когда отсчитывается время, и должны быть настроены для каждого часового пояса и каждого канала отдельно. 4. **Stopped Time** приостанавливает таймер в ожидании клиента — без этого метрики наказывают центр за поведение клиента. 5. **Действия Milestone** генерируют предупреждение и эскалацию **до** нарушения, обычно примерно за 75-80% времени. Основное правило: если первое оповещение приходит после нарушения, механизм измеряет, а не управляет. Основные решения по настройке Service Cloud и SLA подробно описаны в документе [Внедрение Service Cloud](/ru/insights/service-cloud-implementation). ## Как узнать, что модель не работает Пять ранних признаков, прежде чем ежемесячные метрики выявят проблему: - Высокий процент назначений через Fallback — навыки не соответствуют кадровому обеспечению. - Запросы в очереди назначения дольше нескольких минут — недостаток загрузки или отсутствующее правило Overflow. - Агенты сообщают о перегрузке, в то время как отчет о загрузке показывает доступность — неверные весовые коэффициенты. - Необычная концентрация нарушений SLA в фиксированное время дня — проблема кадрового обеспечения, а не маршрутизации. - Высокий процент запросов, назначенных и сразу же оставленных — агенты отказываются от работы, которая им не подходит. ## Постоянный мониторинг | Метрика | Что она выявляет | | --- | --- | | Время в очереди назначения | Находит ли модель агента вовремя | | Средняя загрузка | Реалистичны ли весовые коэффициенты | | Нарушения по Milestone | Где именно нарушается SLA | | Количество предотвращенных эскалаций | Работает ли раннее предупреждение | | Различия в нарушениях между каналами | Ущемлен ли какой-либо канал в маршрутизации | ## Порядок внедрения Внедряйте один канал с одним Entitlement и без навыков, калибруйте весовые коэффициенты на реальных данных в течение двух недель, и только затем добавляйте второй канал и навыки. Полное внедрение за один день препятствует возможности определить, какой компонент вызвал перегрузку, и обычно заканчивается отключением маршрутизации и возвратом к ручным очередям. ## Заключение Omni-Channel — это модель загрузки, а не распределения, а SLA — это механизм оповещения, а не отчет. Эти два принципа определяют, будет ли центр работать по системе или найдет способы ее обойти — и разница проявляется уже в первую неделю эксплуатации. ### Вопросы и ответы **Как определить весовой коэффициент пропускной способности для каждого канала?** Измерьте, сколько фактического времени каждый тип работы требует непрерывного внимания. Живой чат почти полностью занимает оператора, электронная почта не является синхронной. Весовой коэффициент, установленный только на основе оценки, обычно оказывается неверным в течение двух недель — поэтому рекомендуется планировать цикл калибровки. **Сколько навыков (Skills) стоит определить?** Мало и чётко. Избыток навыков приводит к сценариям, когда ни один оператор не соответствует всем требованиям, и запрос остаётся без назначения. Лучше иметь базовый навык с определённым запасным вариантом (Fallback). **Требуются ли права (Entitlements) для каждого клиента?** Нет. Определите одну настройку по умолчанию для всех клиентов и исключения только для клиентов с фактически иными условиями сервисного договора. Дублирование прав для каждой учётной записи приводит к сложностям в обслуживании, с которыми никто не справляется. **Что происходит с запросом, для которого нет доступных операторов?** Должно быть правило переполнения (Overflow) с максимальным временем ожидания и резервной очередью. Без такого правила запросы будут находиться в очереди назначения, оставаясь незамеченными, и SLA будет незаметно превышаться. **Можно ли полагаться только на Push-маршрутизацию?** Как правило, да, и это предпочтительный подход — Pull-маршрутизация позволяет операторам выбирать лёгкие запросы. Разумная комбинация — Push для большей части работы и ограниченная Pull-очередь для работы, не зависящей от времени. --- ## Salesforce Knowledge в Service Cloud: Как создать надежную базу знаний для сотрудников и ИИ URL: https://hpi.pro/ru/insights/salesforce-knowledge-management Базы знаний обычно выходят из строя не при запуске, а на второй год: статьи написаны единожды, никто их не поддерживает, и сотрудники возвращаются к внутренним чатам. Это руководство описывает жизненный цикл, который обеспечивает долгосрочную работу — стоимость, триггер для создания, периодический пересмотр и измерение использования — и что меняется, когда ИИ-агент обращается к той же базе. ## Краткий ответ База знаний — это не контент-проект, а операционный процесс. Главный вопрос, определяющий ее жизнеспособность, не в количестве статей, написанных при запуске, а в том, что стимулирует создание новых статей и что инициирует проверку старых. Без этих двух механизмов любая база деградирует в папку с файлами, которые никто не открывает. Простая проверка текущего состояния: сколько обращений (Cases) было закрыто в этом месяце со связанной статьей. Показатель ниже 30% означает, что база знаний не интегрирована в рабочий процесс. ## Жизненный цикл статьи | Этап | Ответственный | Триггер | | --- | --- | --- | | Создание | Представитель, разрешивший обращение | Повторяющееся обращение без связанной статьи | | Утверждение | Редактор знаний или предметный эксперт | Очередь на утверждение с временным лимитом | | Публикация | Редактор | Определение видимости: внутреннее или публичное | | Проверка | Назначенный владелец | Дата проверки или данные об использовании | | Вывод из эксплуатации | Владелец | Снятие продукта с производства или изменение политики | Этап, который часто пропускают, — это вывод из эксплуатации. Старые статьи безвредны, пока их меньшинство, но как только они составляют четверть базы, представители перестают доверять результатам поиска — и это точка невозврата. ## Триггер для правильного роста базы знаний Эффективный подход заключается не в предварительном планировании списка тем, а в том, чтобы данные Service Cloud диктовали его. Простое автоматическое правило: тип обращения, который повторялся более пяти раз в квартал, и его закрытия не связаны со статьей, попадает в очередь на написание. Таким образом, база знаний отражает реальное положение дел, а не то, что было оценено на совещании по планированию. Важное дополнение: представитель, написавший статью, получает явное признание. Вклад в знания, который нигде не учитывается, прекращается через несколько недель. ## Структура статьи, удобная для поиска и ИИ Статья, написанная как сплошной текст, трудно читаема во время разговора и тяжело поддается точному извлечению моделью. Эффективная структура включает: заголовок, сформулированный как вопрос клиента, краткий ответ в первом абзаце, пронумерованные шаги действия, отдельные условия и исключения, а также теги продукта, версии и срока действия. Разделение исключений в отдельный раздел является важным моментом: когда они интегрированы в шаги, как занятый представитель, так и механизм извлечения с трудом различают общее правило и исключение из него. ## Видимость: внутренняя против публичной Один и тот же вопрос часто требует двух версий. Внутренняя версия включает известные ограничения, обходные решения и инструкции по эскалации; публичная включает только то, что клиент может выполнить. Управление этим разделением осуществляется на уровне статьи, а не на уровне базы знаний, чтобы не создавать две базы, расходящиеся друг от друга. Перед открытием портала самообслуживания (Self-Service) стоит убедиться, что публичные версии действительно самодостаточны. Портал, который ссылается на неполные статьи, не снижает количество обращений, а перенаправляет их на другой канал, обычно телефонный. Операционный контекст подробно описан в [Внедрение Service Cloud](/ru/insights/service-cloud-implementation). ## Что меняется, когда агент ИИ читает из базы знаний База знаний, с которой успешно работают представители, несмотря на пробелы, не обязательно готова к использованию агентом ИИ. Опытный представитель знает, как игнорировать старую статью; механизм извлечения — нет. Добавляются три требования: не должно быть двух активных статей, дающих противоречивые ответы на один и тот же вопрос; каждая статья должна иметь четкий срок действия и источник; и должно быть явно определено, что разрешено показывать клиенту. Агент, цитирующий внутреннюю статью или объединяющий два противоречивых источника, создает ущерб доверию, который трудно исправить. Более глубокое рассмотрение темы представлено в [Grounding и RAG в Agentforce](/ru/insights/agentforce-grounding-rag) и [Готовность знаний для Agentforce](/ru/insights/agentforce-knowledge-readiness). ## Измерение | Метрика | Что она показывает | Пороговое значение для проверки | | --- | --- | --- | | Процент прикрепленных статей (Knowledge attach rate) | Интегрирована ли база знаний в рабочий процесс | Ниже 30% | | Поиски без результатов | Реальные пробелы в контенте | Еженедельный список для очереди на написание | | Статьи без просмотров за полгода | Избыточный контент или не находится при поиске | Более 25% от всей базы | | Время от создания до публикации | Не тормозит ли очередь утверждения | Более двух недель | | Рейтинг "не помогло" | Качество конкретного контента | Концентрация по одной теме | Список поисков без результатов является самым дешевым и точным источником для планирования контента, и он почти всегда не используется. ## Заключение Успешная база знаний строится снизу — на основе реальных обращений (Cases) — и поддерживается всего двумя механизмами: триггером для создания и триггером для проверки. Все остальное, включая адаптацию для использования агентами ИИ, вытекает из того, что контент актуален и не противоречит сам себе. ### Вопросы и ответы **Сколько статей нужно для начала?** От десяти до двадцати, охватывающих самые частые запросы. Большая база, написанная заранее, устаревает до того, как будет использована; небольшая база, обновляемая на основе реальных обращений, растет корректно. **Кто должен писать статьи?** Сотрудники, которые решают запросы, с редактором, который одобряет и стандартизирует. Написание сторонним специалистом создает точный контент, который не соответствует языку, на котором работает сотрудник. **Может ли одна и та же статья использоваться как сотрудниками, так и клиентами?** Чаще всего не полностью. Требуются разные уровни видимости — внутренняя часть (ограничения, обходные решения) и публичная часть. Категории данных и каналы управляют этим на уровне статьи. **Как узнать, что статья устарела?** Сочетание даты пересмотра, данных об использовании и пометок от сотрудников. Статья, которую не просматривали полгода или которая была помечена как бесполезная, автоматически попадает в очередь на пересмотр. **Что необходимо, прежде чем ИИ-агент начнет использовать базу знаний?** Очистка от противоречивых статей, пометка срока действия и источника, а также определение того, что разрешено показывать клиенту. Агент, цитирующий две противоречивые статьи, наносит больший ущерб, чем отсутствие ответа. --- ## Интеграция контакт-центра с Service Cloud: CTI, Voice и комплексный профиль клиента URL: https://hpi.pro/ru/insights/service-cloud-cti-integration Скорость интеграции телефонии с Salesforce измеряется секундами: сколько времени проходит, прежде чем оператор увидит, кто звонит и по какому вопросу. Это руководство рассматривает ключевые решения, определяющие результат: идентификацию абонента, Screen Pop, управление маршрутизацией, обработку переводов и разъединений, а также выбор между Service Cloud Voice и существующим CTI-адаптером. ## Краткий ответ Качество интеграции CTI измеряется в трех секундах: от момента ответа оператора до отображения информации о звонящем, его истории и открытых обращений. Если идентификация не срабатывает, оператор начинает каждый разговор с вопроса «С кем я говорю?», и все остальные инвестиции в интегрированную телефонию теряют смысл. Ключевое решение заключается не в выборе адаптера, а в **месте принятия решения о маршрутизации**: в АТС или в Salesforce. Здесь кроется основной риск и стоимость. ## Ключевое решение: кто управляет маршрутизацией | Аспект | Маршрутизация в АТС (CTI адаптер) | Маршрутизация в Omni-Channel (Voice) | | --- | --- | --- | | Источник решения | IVR и правила АТС | Доступность и навыки в Salesforce | | Баланс между каналами | Телефон управляется отдельно от чата и электронной почты | Единая пропускная способность для всех каналов | | Изменение правил | Зависит от провайдера телефонии | В настройках Salesforce | | Сложность внедрения | Относительно низкая | Высокая, затрагивает операции контакт-центра | | Когда подходит | Чисто телефонный контакт-центр, зрелая АТС | Омниканальный контакт-центр со смешанной нагрузкой | Проблематичным является двойное распределение — АТС распределяет, а система перераспределяет. В результате операторы получают звонки, когда они заняты в чате, а показатели доступности не отражают реального положения дел. Если выбран Voice, правила распределения отделяются от АТС; если АТС остается, Omni-Channel не активируется для голосового канала. ## Идентификация звонящего: проблема данных до проблемы технологий Большинство сбоев в функции Screen Pop связаны не с ошибками интеграции, а с отсутствием нормализации телефонных номеров. Один и тот же клиент отображается как 050-1234567, +972501234567 и 0501234567 в трех разных системах, что приводит к сбоям сопоставления. Что необходимо до подключения: 1. **Единый формат** – E.164 как стандарт, с преобразованием при вводе, а не во время поиска. 2. **Определенный порядок поиска** – сначала контакт, затем организация, затем открытое обращение по номеру. Порядок определяет, что будет отображено при нескольких совпадениях. 3. **Обработка множественных совпадений** – короткий экран выбора, а не угадывание. В корпоративных АТС и на номерах компаний-клиентов это обычная, а не исключительная ситуация. 4. **Обработка неидентифицированных звонков** – быстрый экран создания нового обращения, чтобы звонок не завершился без документирования. Принципы идентификации и объединения записей подробно описаны в разделе [Дедупликация и объединение записей](/ru/insights/salesforce-data-deduplication). ## Что происходит, когда звонок проходит не гладко Крайние сценарии определяют, доверяет ли контакт-центр системе: - **Передача между операторами** – Передается ли обращение вместе с звонком или открывается новое? Передача, создающая второе обращение, нарушает как показатель FCR, так и клиентский опыт, поскольку клиент рассказывает свою историю дважды. - **Разрыв связи посередине** – Необходимо правило обратного вызова с окном времени, иначе обращения исчезают бесследно. - **Исходящий звонок** – Учитывается ли он и связывается ли с обращением? Без этого данные о нагрузке оператора будут неполными на треть. - **Очередь ожидания и отказ** – Отказы должны быть доступны в Salesforce, а не только в отчетах АТС, иначе оперативная картина будет неполной. Каждый из четырех сценариев должен быть описан как сквозной тестовый сценарий до запуска системы. Тестирование только идеального звонка ничего не доказывает. ## Запись, транскрибирование и конфиденциальность Автоматическая транскрипция стала доступной и недорогой, поэтому возникает большое искушение применять ее ко всему. Три вопроса, на которые нужно ответить заранее: Какова правовая основа для записи и обработки; как долго хранится транскрипция и кто может ее искать; используется ли контент для обучения моделей. Транскрипция является конфиденциальной информацией — она включает детали, которые клиент предоставил устно и не ввел бы в форму. Ограничение доступа на уровне поля и определенная политика хранения являются частью внедрения, а не задачей после него. ## Измерение после запуска | Показатель | Почему он важен | | --- | --- | | Процент автоматической идентификации | Прямой показатель качества данных и подключения | | Время до Screen Pop | Более двух секунд воспринимается как медлительность | | Звонки без связанного обращения | Выявляет пробелы в документировании | | Обращения, открытые повторно при передаче | Выявляет сбой в преемственности | | Отказ в очереди | Индикатор сбоя распределения или укомплектования штата | ## Заключение Успешная интеграция CTI измеряется не фактом установки адаптера, а тем, что оператор начинает разговор, зная, кто на линии и какое обращение открыто, и что каждый нештатный сценарий — передача, разъединение, множественные совпадения — был заранее определен. Решение о месте маршрутизации является первым, которое необходимо принять, поскольку от него зависят как операционная модель, так и стоимость. ### Вопросы и ответы **В чем разница между Service Cloud Voice и обычным CTI-адаптером?** CTI-адаптер отображает телефонию внутри Salesforce, но маршрутизация остается на АТС. Voice переносит саму маршрутизацию в Omni-Channel и предоставляет расшифровки и данные вызовов в виде записей. Существенное различие заключается в том, где принимается решение о маршрутизации. **Почему иногда не открывается Screen Pop?** Обычно это происходит потому, что номер звонящего не нормализован: международный префикс, ведущие нули или иной формат между системами. Это проблема данных, а не интеграции. **Что делать, если один номер идентифицируется нескольким клиентам?** Заранее настройте короткий экран выбора для оператора вместо автоматического угадывания. Ошибочный автоматический выбор хуже отсутствия идентификации, так как он создает записи по некорректному клиенту. **Обязательно ли записывать и расшифровывать все звонки?** Нет, и в большинстве организаций это нецелесообразно. Поголовная запись требует политики хранения, правового обоснования и контроля доступа. Предпочтительнее начинать с определенных категорий. **Кто несет ответственность, когда звонок поступает, но запись не создается?** Это должно быть письменно определено до запуска системы. Без единого ответственного за сквозной процесс любая неисправность превращается в спор между поставщиком телефонии и командой CRM. --- ## Сеть Salesforce Champions: как создать внутренний механизм внедрения URL: https://hpi.pro/ru/insights/salesforce-champions-network Чемпион — это больше, чем просто формальный титул. Мы расскажем, как выбрать представителей на местах, сколько времени им выделить, что именно включает в себя их роль, как мотивировать и как предотвратить затухание сети через два месяца. ## Ключевой аспект Сеть бизнес-экспертов является основой для широкого распространения и внедрения платформы Salesforce в организации. Пользователи, как правило, обращаются за помощью к коллегам, находящимся рядом, прежде чем создать заявку в службу поддержки, доверяя им больше, чем официальным сообщениям руководства. Сеть экспертов использует эту динамику вместо того, чтобы противодействовать ей. Однако звание эксперта, не подкрепленное выделенным временем, четким описанием роли и реальным влиянием на приоритеты, является пустым звуком. Эти три компонента определяют, просуществует ли сеть год или распадется в течение квартала. ## Кто подходит, а кто нет | Критерий | Почему это важно | Красный флаг | | :---------------- | :------------------------------------------------ | :---------------------------------- | | Доверие коллег | Определяет, будут ли к нему вообще обращаться | Назначенный из-за доступности | | Опыт в бизнес-процессах | Позволяет давать корректные, а не только технические ответы | Системные знания без понимания работы | | Искренняя готовность | Добровольная роль формирует приверженность | Принудительное назначение от руководителя | | Поддержка непосредственного руководителя | Определяет, будет ли время на эту роль | Только устное согласие | Распространенная ошибка — выбор самого технически подкованного пользователя. Он будет давать точные ответы, которые никто не просил, и не поймет, что реальная проблема кроется в нелогичности процесса. ## Должностная инструкция в письменной форме Без письменного определения роль интерпретируется как «тот, кому показывают ошибки». В определение входят четыре обязанности: 1. **Локальная поддержка** — Первичный ответ на вопросы в команде и документирование повторяющихся запросов. 2. **Сбор обратной связи** — Передача препятствий и потребностей в центральный форум, включая то, о чем никто официально не сообщает. 3. **Предварительное тестирование** — Участие в UAT и тестировании изменений перед выпуском для команды. 4. **Информирование об изменениях** — Устное объяснение произошедших изменений на языке команды. Наряду с обязанностями, определяется и выделенное время: от четырех до шести часов в неделю в период запуска. Если непосредственный руководитель не утвердил выделение времени в письменной форме, роль будет утрачена при первом же возникновении нагрузки. ## Центральный форум – сердце системы Двухнедельная встреча продолжительностью 45 минут с фиксированной структурой: что поступило с мест, что исправлено с предыдущей встречи, что скоро будет выпущено, и один открытый вопрос. Первые два пункта — это движущая сила: бизнес-эксперт, видящий, что его запрос был реализован и сообщен от его имени, принесет еще пять запросов. Эксперт, который направил три запроса, оставшихся без ответа, перестанет их направлять. Форум также служит каналом раннего предупреждения: повторяющиеся жалобы, которые звучат там, попадают в дашборд только спустя два месяца. Связь с измерениями подробно описана в [метриках внедрения Salesforce](/ru/insights/salesforce-adoption-metrics). ## Что предлагается взамен Стимулы, которые работают, по доказанной эффективности: - **Влияние** — Постоянное место в определении приоритетов для следующего выпуска. - **Ранний доступ** — Возможность видеть изменения раньше всех и право сказать «пока нет». - **Видимость для руководства** — Представление результатов руководству раз в квартал. - **Развитие** — Финансирование по сертификации Salesforce или участие в конференции. - **Признание** — Упоминание имени при каждом исправлении, которое было инициировано ими. Денежное вознаграждение редко и не является критически важным. Что разрушает сети, так это отсутствие влияния, а не отсутствие бонусов. ## Роль сети при запуске и в повседневной деятельности В течение двух недель после запуска бизнес-эксперты являются первой линией поддержки на местах, поэтому они проходят обучение за неделю до всех остальных. Структура описана в [обучении Salesforce по ролям](/ru/insights/salesforce-role-based-training). В повседневной деятельности роль меняется: онбординг новых сотрудников, выявление накапливающихся проблем и проверка изменений перед выпуском. Здесь сеть трансформируется из механизма запуска в механизм обслуживания, который предотвращает регресс и способствует исправлениям, обсуждаемым в [упрощении UX в Salesforce](/ru/insights/salesforce-ux-simplification). ## Признаки стагнации и меры реагирования | Признак | Причина | Корректировка | | :------------------------ | :------------------------------ | :----------------------------------------------------------- | | Снижение посещаемости форума | Запросы не обрабатываются | Немедленно выпустить два исправления из их списка | | Эксперт просит уйти | Давление целевых показателей на основной работе | Обновить выделение времени с руководителем | | Нет новых запросов | Сеть стала только каналом сообщений | Открыть дискуссию о препятствиях, а не об обновлениях | | Все запросы от одной команды | Частичное представительство | Добавить экспертов в отсутствующих областях | ## Измерение эффективности Достаточно трех показателей: количество вопросов, поднятых через сеть за квартал, процент их реализации, и разрыв в адаптации между командами с активным экспертом и командами без него. Этот разрыв является бюджетным обоснованием всей программы. Сама сеть является одним из компонентов [управления изменениями Salesforce](/ru/insights/salesforce-change-management-plan). ## Заключение Выбирайте исходя из доверия, а не технических знаний, закрепите выделение времени письменно с непосредственным руководителем, проводите двухнедельный форум, где запросы действительно реализуются, и вознаграждайте влиянием. Сеть, которая чувствует, что она изменяет систему, просуществует годы; номинальная сеть исчезнет в течение квартала. ### Вопросы и ответы **Сколько Champions необходимо?** Принятое соотношение — один Champion на каждые 15–25 пользователей, и как минимум один в каждой независимой команде или географическом подразделении. Меньшее количество создает «бутылочное горлышко», большее — усложняет поддержание сети. **Сколько часов в неделю выделять Champion?** Четыре-шесть часов в неделю в период запуска и два часа после него. Выделение времени должно быть согласовано с непосредственным руководителем и вычтено из текущих задач, иначе эта роль будет заброшена первой. **Обязательно ли, чтобы Champion был технически продвинутым пользователем?** Нет. Важнейшим критерием является доверие коллег и экспертность в бизнес-процессах. Системные знания можно приобрести; социальное влияние в команде нельзя измерить. **Как мотивировать Champions без бюджета?** Признание руководством, реальное влияние на дорожную карту развития, обучение или сертификация за счет организации и публичное признание в обновлениях. Влияние на приоритеты является наиболее сильным стимулом на практике. **Что делать, если сеть Champions угасает через два месяца?** Проверьте три вещи: действительно ли их запросы реализуются, поддерживает ли непосредственный руководитель выделение времени, и существует ли регулярный форум. Угасание почти всегда происходит из-за того, что канал перестал оказывать влияние. --- ## Улучшение UX в Salesforce: меньше полей, меньше кликов, выше уровень адаптации URL: https://hpi.pro/ru/insights/salesforce-ux-simplification Каждое лишнее поле — это ежедневный налог на каждого пользователя. Представляем практический подход к оптимизации экранных форм в Salesforce: анализ использования полей, тест трех кликов, оптимизация макетов по ролям и измерение времени выполнения задач до и после изменений. ## Краткий ответ Дополнительные пять секунд на каждый ввод, умноженные на тридцать вводов в день, умноженные на сто пользователей – это полноценный рабочий день, который ежедневно теряется из-за перегруженного интерфейса. Упрощение UX, как правило, является наиболее высокодоходным действием, которое можно предпринять в существующей системе, и почти всегда основывается на удалении, а не на создании элементов. Достаточно трех инструментов: аудит использования полей, трехкликовый тест для каждой ключевой задачи и адаптация макета в соответствии с ролью и этапом процесса. ## Почему экраны разрастаются Никто не проектирует экран с 80 полями. Он формируется в течение семи лет благодаря точечным запросам, каждый из которых по отдельности был обоснован. Повторяются три механизма: - **Запрос "только одно поле"** — кажущаяся нулевой предельная стоимость оборачивается огромной совокупной стоимостью. - **Поле, которое осталось после изменения процесса** — никто не несет ответственности за его удаление. - **"Запасное" поле** — "возможно, оно понадобится для отчета в будущем". Поэтому упрощение — это не разовый проект, а постоянная практика: каждый запрос на новое поле требует указания поля, которое будет удалено, или четкого обоснования. ## Шаг 1 — Аудит использования полей Для каждого основного объекта создается таблица с четырьмя столбцами: процент заполнения за последние 12 месяцев, использование в отчетах, использование в автоматизациях и интеграциях, а также заявленный владелец процесса. | Вывод | Интерпретация | Решение | |---|---|---| | Заполнение менее 10%, не используется в отчетах | Заброшенное поле | Удаление из макета | | Высокое заполнение, не используется в отчетах | Работа, не востребованная никем | Уточнение у владельца процесса | | Низкое заполнение, обязательное поле | Пользователи вводят произвольное значение | Отмена обязательности или изменение на Picklist | | Высокое заполнение и использование в отчетах | Активное поле | Оставить, возможно, переместить вперед | Третья строка наиболее опасна: обязательное поле, заполненное фиктивным значением, загрязняет данные и подрывает доверие. ## Шаг 2 — Трехкликовый тест Для каждой ключевой задачи — обновление этапа, документирование звонка, закрытие обращения — подсчитывается количество кликов и экранов от начала намерения до завершения. Более трех кликов для ежедневной задачи оправдывает исправление. Доступные инструменты: Quick Actions вместо открытия полной записи, редактирование из списка, Path с направляющими полями для каждого этапа и компоненты, которые появляются только в релевантном контексте. Руководящий вопрос всегда один: что пользователь пришел сюда делать и что ему мешает. ## Шаг 3 — Макет по роли, а не по объекту Единый экран для всех ролей — это объединение всех потребностей, то есть плохо для всех. Торговому представителю нужно восемь полей; операционному менеджеру — пять других; бэк-офису — поля для подтверждения, которым нет места у первых двух. Разделение по типу записи (Record Type) и профилю в сочетании с динамическими формами (Dynamic Forms) для условного отображения в зависимости от этапа сокращает экран из 60 полей до экрана из 12 релевантных полей. Важно: условное отображение не заменяет бизнес-решение о том, что вообще требуется. ## Шаг 4 — Домашняя страница как рабочий список Первый экран, который видит пользователь, должен отвечать на вопрос "Что мне нужно делать сейчас?", а не показывать общие графики. Список задач, отсортированный по приоритету, "зависшие" элементы и аномалии, требующие внимания. Это ежедневная отдача, которая оправдывает ввод данных, и это ключевой фактор восстановления использования — см. [Повышение приживаемости Salesforce](/ru/insights/recover-salesforce-user-adoption). ## Измерение: до и после Перед корректировкой измеряется среднее время выполнения трех основных задач пятью реальными пользователями с секундомером. После корректировки измерения повторяются тем же методом. Снижение времени выполнения задачи на 30% и более является приемлемым результатом для первой волны упрощения. Помимо этого, отслеживаются качество данных и процент выполнения ключевого действия в соответствии с [метриками использования Salesforce](/ru/insights/salesforce-adoption-metrics). Истинное упрощение улучшает оба показателя; если время сократилось, но качество пострадало, значит, было удалено необходимое поле. ## Возражения и как на них отвечать "Но поле нужно для отчета" — кто использовал этот отчет в прошлом году? "Менеджер X его запросил" — существует ли процесс, который его оправдывал? "Возможно, понадобится в будущем" — его можно вернуть в течение часа, а исторические данные сохраняются даже после удаления из макета. Эти возражения решаются в рамках процесса организационных изменений, а не как техническая дискуссия — см. [Управление изменениями Salesforce](/ru/insights/salesforce-change-management-plan). ## Заключение Проведите аудит использования полей, удалите заброшенные, сократите обязательные поля до двух на каждом этапе, создайте макет в соответствии с ролью и превратите домашнюю страницу в рабочий список. Измерьте время выполнения задач до и после — это доказательство, которое оправдает следующую волну улучшений. ### Вопросы и ответы **Как определить, какие поля можно удалить?** Запустите отчет об использовании полей: анализируйте процент заполненных записей за последние 12 месяцев, а также частоту использования в отчетах и автоматизациях. Поле с низким уровнем заполнения, не используемое в отчетах или автоматизациях, является кандидатом на удаление. **Нужно ли удалять поля или достаточно их скрыть?** Начните с удаления полей из макета. Оставьте их скрытыми на один квартал, и только потом удаляйте окончательно. Удаление из макета обеспечивает полную выгоду для пользователя без риска потери исторических данных. **Сколько обязательных полей допустимо на одном экране?** Не более пяти всего на протяжении всего процесса и не более двух на каждом этапе. Для каждого дополнительного обязательного поля необходимо подтверждение от ответственного за процесс, обосновывающее его необходимость и потребляемые данные. **Решают ли проблему динамические формы (Dynamic Forms)?** Это отличный инструмент для условного отображения полей в зависимости от этапа или профиля, но он не заменяет бизнес-решения. Перегруженный экран, даже если часть полей скрыта, по-прежнему свидетельствует о неоптимизированном процессе. **Сколько времени занимает проект по упрощению?** Аудит и планирование занимают от двух до трех недель, а реализация первого этапа — от трех до четырех недель. Это один из проектов в Salesforce с наилучшим соотношением влияния к затраченным усилиям. --- ## Как вернуть пользователей в Salesforce после неудачного запуска URL: https://hpi.pro/ru/insights/recover-salesforce-user-adoption Неудачный запуск — это не проблема обучения. Практическое руководство по восстановлению: как диагностировать причину оттока, что исправить в первые 30 дней, как восстановить доверие без объявления о «перезапуске» — и когда лучше сократить систему, а не расширять её. ## Краткий ответ Когда пользователи отказываются от Salesforce, причина почти никогда не заключается в том, что «они не поняли систему». Истинная причина в том, что система требовала от них больше, чем давала взамен. Восстановление уровня внедрения начинается с диагностики того, какой ценой пользователю дается работа с системой, а не с дополнительного обучения. Практическая последовательность действий: две недели диагностики, 30 дней ощутимых корректировок, затем регулярный управленческий цикл, основанный на данных. Обучение проводится только тогда, когда система уже стоит потраченного на нее времени. ## Пять причин отказа от системы — и как их определить | Причина | Отличительный признак на практике | Правильное решение | | --- | --- | --- | | Избыток ввода данных | Длинные формы, обязательные поля, которые никто не использует | Удаление полей, значения по умолчанию, автоматизация | | Отсутствие доверия к данным | Все ведут теневые таблицы Excel | Очистка данных + объявление единого источника истины | | Отсутствие обратной ценности | Пользователь вводит данные, но ничего не получает взамен | Списки задач, персонализированные представления, уведомления | | Управление, не основанное на системе | Еженедельный обзор по внешнему файлу | Перенос совещания на панель мониторинга | | Производительность и интерфейс | Медленные экраны, запутанная навигация | Оптимизация и упрощение макета | Сама диагностика занимает две недели: десять интервью с реальными пользователями (не с их представителями), часовой просмотр фактической работы трех ролей, а также сбор данных о фактическом использовании в соответствии с подходом, описанным в статье [Показатели внедрения Salesforce](/ru/insights/salesforce-adoption-metrics). ## Закон о возврате: что пользователь получает за 30 секунд Это главное испытание. Откройте главный экран для роли, отказывающейся от системы, и спросите: что он здесь получает такого, чего он не получил бы без системы? Если ответ: «Ничего, он только вводит данные» — отказ от системы абсолютно логичен. Реально работающие ценности: список задач на сегодня, отсортированный по приоритету; полная история клиента без поиска в электронной почте; автоматическое напоминание перед встречей; форма коммерческого предложения, создаваемая одним кликом. Каждая из этих функций экономит реальное время и, следовательно, стимулирует использование без принуждения. ## Первая волна исправлений: 30 дней Выберите всего от пяти до восьми исправлений, все из которых ощутимы в повседневной работе, и все могут быть реализованы в течение месяца. Рекомендуемый состав: 1. Удаление 30-50% полей в основной форме, при условии, что никто их не использует. 2. Не более двух обязательных полей на каждом этапе процесса. 3. Представление «Моя работа сегодня» для каждой основной роли. 4. Исправление трех проблем с качеством данных, которые пользователи приводят в качестве доказательства того, что системе нельзя доверять. 5. Одна автоматизация, устраняющая повторяющуюся ручную работу. 6. Оптимизация самого медленного экрана. Что не включено в эту волну: новые функции, дополнительные модули, новые интеграции. Расширение во время кризиса доверия усугубляет ущерб. Правильное направление на этом этапе — упрощение, как описано в [Упрощение UX в Salesforce](/ru/insights/salesforce-ux-simplification). ## Восстановление доверия Доверие не возвращается электронным письмом. Оно восстанавливается благодаря трем повторяющимся шаблонам: исправлениям, выполненным в обещанный срок, прозрачности относительно того, что не будет сделано, и признанию заслуг тех, кто поднял проблему. Простой и эффективный механизм: открытый для всей организации список запросов со статусом, выпуск обновлений раз в две недели и краткое сообщение, подробно описывающее, что было исправлено и благодаря кому. В течение шести недель это меняет дискуссию с «система не работает» на «я подал запрос». Человеческая сеть, которая доносит это послание, — это сеть амбассадоров (Champions), и способ ее построения подробно описан в статье [Сеть амбассадоров (Champions) в Salesforce](/ru/insights/salesforce-champions-network). ## Управленческий цикл — самый мощный инструмент Наибольшее влияние на внедрение оказывает то, на что смотрит непосредственный руководитель. Пока он управляет командой по внешнему файлу, система является необязательной. Как только еженедельный обзор Pipeline или Cases проводится с помощью интерактивной панели мониторинга, обновление становится личным интересом сотрудника. Это управленческое изменение, которое требует поддержки Спонсора, поэтому оно является частью плана управления изменениями, а не частью технического плана работ. См. [Управление изменениями Salesforce](/ru/insights/salesforce-change-management-plan). ## Когда сокращать вместо расширения Если система содержит неиспользуемые модули, процессы, разработанные для теоретических сценариев, и автоматизации, которые никто не понимает, правильный шаг — контролируемое сокращение. Отключение неиспользуемого снижает когнитивную нагрузку, сокращает экраны и уменьшает объем обслуживания. Многие организации обнаруживают, что наиболее значительное улучшение внедрения произошло не за счет создания нового, а за счет удаления. ## Показатели восстановления В течение квартала измеряйте только четыре показателя: процент выполнения основного действия по роли, среднее время выполнения основного процесса, процент использования теневых файлов (проверяется вручную) и один показатель качества данных. Увеличение первых трех без улучшения четвертого означает, что система заполняется быстрее, но не лучше. ## Заключение Восстановление внедрения — это проект по устранению трений и возвращению ценности, а не проект по убеждению. Диагностируйте цену, которую платит пользователь, реализуйте ощутимую волну исправлений в течение 30 дней, переведите управление в систему, и только после этого возвращайтесь к обучению и расширению. ### Вопросы и ответы **Сколько времени занимает восстановление адаптации после неудачного запуска?** Диагностика — две недели, первая волна исправлений — 30 дней, измеримая стабилизация — в течение квартала. Восстановление управленческого доверия занимает больше времени — обычно два квартала последовательной демонстрации результатов. **Стоит ли объявлять о «перезапуске»?** В большинстве случаев — нет. Повторное объявление напоминает пользователям о неудаче и повышает планку ожиданий. Лучше провести серию незаметных исправлений, которые ощущаются в повседневной работе, а затем сообщить о достигнутых результатах. **Что делать, если руководители продолжают параллельно работать в Excel?** Исключить Excel как легитимный источник для управленческих дискуссий. Пока обзор Pipeline ведется на основе файла, нет реального стимула обновлять систему. Это управленческое, а не техническое решение. **Является ли замена системы предпочтительнее восстановления?** Почти никогда. В 80% случаев причина неудачи лежит в процессах, данных или интерфейсе — все они перейдут с вами в следующую систему. Замена оправдана только тогда, когда расхождение заключается в базовых функциональных возможностях продукта. **Кто должен руководить процессом восстановления?** Старший владелец бизнес-процесса с мандатом на изменение процессов, а не только менеджер по информационным системам. Большинство необходимых исправлений — это бизнес-решения: от чего отказаться, кто отвечает за данные и что измерять. --- ## Ремонт или полная перестройка Salesforce? Принципы принятия решений для существующих систем URL: https://hpi.pro/ru/insights/salesforce-rebuild-vs-refactor Решение между точечным ремонтом, рефакторингом и полной перестройкой зачастую принимается интуитивно, поэтому проблемы возвращаются уже через два года. Данное руководство представляет четыре объективных критерия оценки, объясняет, почему "перестройка с нуля" почти всегда обходится дороже предварительных оценок, и описывает практический путь поэтапной замены системы. ## Краткий ответ Три перечисленных подхода не являются взаимозаменяемыми. **Repair** устраняет симптомы, **Refactor** изменяет реализацию без изменения поведения, а **Rebuild** меняет базовую модель. Решение принимается на основе одного вопроса: кроется ли проблема в способе реализации или в первоначальном определении. Если модель данных корректна, а сложности связаны с запутанными автоматизациями и сложными разрешениями — это Refactor. Если один и тот же объект используется в трех противоречивых процессах и по нему невозможно сформировать отчетность — это системный корень проблемы, и тогда Rebuild становится предметом обсуждения. ## Четыре критерия принятия решения | Критерий | Указывает на Refactor | Указывает на Rebuild | |---|---|---| | Модель данных | Корректна, но страдает от избытка полей | Объекты, обслуживающие противоречивые цели | | Источник проблем | Производительность, дублирование автоматизаций | Невозможность формирования отчетности или масштабирования | | Масштаб затронутых пользователей | Частичный, поддающийся изоляции | Обширный, затрагивающий все процессы | | Стоимость повторного тестирования | Можно протестировать отдельную область | Любое изменение требует полного регрессионного тестирования | Для принятия решения достаточно совпадения трех строк. Различия между строками, как правило, означают, что проблема локальнее, чем кажется. ## Почему Rebuild дороже, чем оценка Стандартная оценка учитывает только стоимость перестройки. Она почти всегда игнорирует четыре аспекта: миграцию исторических данных со всеми накопленными исключениями, перестройку интеграций, каждая из которых согласовывается со сторонними поставщиками, период параллельной работы двух систем и полное переобучение всех пользователей. На практике эти четыре аспекта зачастую составляют более половины общей стоимости. Организация, рассматривающая Rebuild и не включившая их в смету, сравнивает «яблоки» с «половиной апельсина». ## Практический путь: поэтапная замена Даже когда принято решение о Rebuild, реализация проекта по принципу «останови и замени» сама по себе является рискованной. Рабочим подходом является поэтапная замена: 1. **Создание новой модели рядом со старой** – новые объекты, без затрагивания существующих. 2. **Перенос одного законченного процесса** – с его пользователями, данными и отчетами. 3. **Отключение старого аналога** – это шаг, который большинство организаций откладывают, что делает проект двойным. 4. **Повторение** до тех пор, пока старая система не будет опустошена. Шаг три является проверкой. Система, в которой старое и новое сосуществуют в течение целого года, увеличила затраты и не сократила технический долг. ## Что необходимо изменить в любом случае Оба подхода терпят неудачу, если механизм изменений остается прежним. Минимальное управление – кто одобряет изменение модели, какое обязательное тестирование проводится перед развертыванием и кто является владельцем каждой области – это условие, предотвращающее возвращение к исходной точке. Приоритизация технического долга подробно описана в [Приоритизация технического долга Salesforce](/ru/insights/salesforce-technical-debt-prioritization), а предварительные признаки – в [8 признаков необходимости обновления Salesforce](/ru/insights/salesforce-system-upgrade-signs). ## Заключение Выбор стоит не между «исправлением» и «началом заново», а между исправлением реализации и исправлением определения. В большинстве случаев, которые кажутся Rebuild, скрывается корректная модель данных, погребенная под десятилетием автоматизаций — и эту проблему решают волнами, а не полным удалением. ### Вопросы и ответы **В каких случаях полная перестройка – действительно правильный выбор?** В случаях, когда сама модель данных ошибочна (например, один объект обслуживает три различных процесса) и её исправление в любом случае требует миграции. Если первопричина заключается лишь в сложной автоматизации, рефакторинг обойдётся значительно дешевле. **Решит ли новую Org проблему?** Только если хаос был вызван отсутствием надлежащего управления. Без чётких правил внесения изменений, тестирования и ответственных новый Org придёт к тому же состоянию в течение двух лет – на этот раз с двумя параллельными системами. **Сколько времени занимает серьёзный рефакторинг?** При среднем объёме – от трёх до шести месяцев, осуществляемый поэтапно, а не как единый проект. Каждый этап должен приносить измеримое улучшение сам по себе, иначе финансирование может быть остановлено на полпути. **Как быть с текущей разработкой во время работы над системой?** Приостанавливается только та область, которая находится в работе, а не вся система. Полная "заморозка" создаёт давление со стороны бизнеса, что приводит к обходным решениям, и каждое такое решение добавляет новый долг именно там, где производится очистка. **Как убедить руководство финансировать "чистку", которая не добавляет новых функций?** Путем перевода долга в измеримые операционные издержки: часы поддержки, сбои интеграции, увеличение времени на внесение любых изменений. Долг, представленный как потеря времени, а не как качество кода, получает финансирование. --- ## Приоритизация технического долга в Salesforce: что исправлять первым и почему URL: https://hpi.pro/ru/insights/salesforce-technical-debt-prioritization Список технического долга длиной в сотню строк – это не инструмент для работы, а источник разочарований. В нашем руководстве представлена система оценки по четырём измерениям, которая помогает навести порядок, объясняет, какой вид долга необходимо решать в первую очередь независимо от оценки, и как перевести технический долг в язык, понятный для получения бюджета. ## Краткий ответ Технический долг измеряется не качеством кода, а стоимостью, которую он налагает на каждое будущее изменение. Поэтому приоритет отдается не «самому неприглядному», а **тому, что делает следующую работу наиболее дорогостоящей**. Простое правило быстрого отбора: элемент, из-за которого любое изменение в его области требует обширного регрессионного тестирования, поднимается на первое место. Он удваивает стоимость любой другой действия в плане. ## Оценка по четырем параметрам | Параметр | Вопрос | Вес | |---|---|---| | Бизнес-риск | Что произойдет, если это откажет при пиковой нагрузке? | Высокий | | Частота использования | Как часто в день к этому обращаются? | Высокий | | Зависимость | Сколько других областей заблокировано из-за этого? | Средний | | Трудоемкость | Сколько стоит исправить это в контролируемой среде? | Обратный | Оценка не является точной наукой. Ее истинная ценность в том, что она инициирует открытый диалог между теми, кто понимает технический риск, и теми, кто осознает деловую проблему, создавая порядок, который можно защитить перед руководством. ## Три типа долга, которые обходят очередь Независимо от оценки, три типа долга выходят на первое место: 1. **Долг, блокирующий тестирование** — отсутствие адекватной среды Sandbox или тестовых данных. Любое другое исправление, сделанное без этого, выполняется вслепую. 2. **Долг в разрешениях** — модель видимости, потерявшая логику, является активным регуляторным риском, а не неудобством. 3. **Долг, сосредоточенный в одном человеке** — когда только один человек понимает компонент, риск является не техническим, а организационным. ## Как представить долг для получения бюджета Руководство не финансирует «чистку автоматизаций». Оно финансирует сокращение времени и стоимости. Перевод делается в трех строках для каждого элемента: сколько часов поддержки он потребляет в квартал, сколько дней он добавляет к каждому изменению в своей области и какова угроза, если он откажет. Тот, кто представляет «три запроса на изменение в квартал, каждый из которых продлевается на две недели из-за одного и того же компонента», получает одобрение. Тот, кто представляет диаграмму зависимостей, — нет. ## Постоянная квота, а не разовая акция Неудачный шаблон: крупный проект по очистке раз в два года. Работающий шаблон: постоянная квота в 15-20% от каждой волны, выделяемая на технический долг, устанавливаемая заранее и не подлежащая обсуждению в каждом спринте. Наряду с квотой требуется как минимум одно правило предотвращения — например, запрет на добавление новой автоматизации к объекту, который уже содержит несколько, до их объединения. Без предотвращения, скорость образования долга превышает скорость очистки. Взаимосвязь с инфраструктурой разработки подробно описана в [стратегии Sandbox и DevOps](/ru/insights/salesforce-sandbox-devops-strategy). ## Резюме Приоритизация технического долга — это упражнение по экономике, а не по эстетике: исправлять то, что удорожает следующее изменение, уделять первоочередное внимание тому, что блокирует тестирование и создает риски, и закреплять квоту, которая предотвращает повторение. Список из десяти ранжированных элементов ценнее ста картографированных элементов. ### Вопросы и ответы **Какую часть текущих ресурсов следует выделять на погашение долга?** От 15% до 20% от каждого этапа, как фиксированную квоту. Выделение ресурсов, меняющееся в зависимости от давления, исчерпает себя в течение двух кварталов, потому что всегда найдётся что-то более срочное. **Какой технический долг вообще не стоит исправлять?** Долг в области, которую планируется заменить или упразднить в следующем году, а также долг, не имеющий измеримого выражения в операционных расходах. Очистка ради очистки конкурирует за те же ресурсы. **Как измерить эффективность приоритизации?** По трём показателям: среднее время выполнения запроса на изменение, количество повторяющихся производственных ошибок и количество областей, требующих полного регрессионного тестирования при каждом релизе. Улучшение этих показателей – верное доказательство эффективности. **Что делать, если долг накапливается быстрее, чем его погашают?** Это проблема управления, а не проблема пропускной способности. Без правила, запрещающего добавлять новую автоматизацию к объекту до объединения существующих, любая очистка будет временной. **Считается ли отсутствие документации техническим долгом?** Да, и это долг с высоким уровнем риска, особенно когда знания сосредоточены у одного человека. Он не виден в отчётах, но именно он делает каждое изменение зависимым от доступности определённого сотрудника. --- ## Повышение производительности Salesforce в крупных организациях: диагностика, планирование и измерение URL: https://hpi.pro/ru/insights/salesforce-performance-optimization Замедление работы Salesforce практически никогда не является одной большой проблемой, а представляет собой совокупность факторов: перегруженный интерфейс, неселективные запросы и дублирующиеся автоматизации. Данное руководство предлагает послойный метод диагностики — браузер, интерфейс, сервер, данные, интеграция — и метрики, позволяющие доказать улучшение производительности. ## Краткий ответ Низкая производительность Salesforce является совокупным симптомом: страница записи с 14 компонентами, три автоматизации, запускаемые при одном сохранении, запрос, сканирующий миллион записей, и интеграция, извлекающая данные в часы пик. Единственный способ улучшить ситуацию без чрезмерных затрат бюджета — это послойное измерение, выявление доминирующего слоя и работа с ним, а затем повторное измерение. ## Пять слоев и что измеряется в каждом | Слой | Типичный симптом | Инструменты измерения | Типовое решение | | --- | --- | --- | --- | | Браузер и сеть | Замедление только у части пользователей | Lightning Usage App по пользователям | Корпоративная задержка, версия браузера, VPN | | Экран и компоненты | Высокий EPT на центральной странице записи | EPT на страницу, режим отладки | Уменьшение числа компонентов, отложенная загрузка, вкладки | | Автоматизация | Медленное сохранение, таймаут при массовом обновлении | Журналы отладки, сессии Flow | Объединение Flows, асинхронный переход | | Данные и запросы | Отчеты не загружаются, List View зависает | Query Plan, Apex Jobs | Селективная фильтрация, индекс, архивация | | Интеграция | Пиковые нагрузки в фиксированное время | Event Monitoring, использование API | Bulk API, окна выполнения, троттлинг | ## Работа с большими объемами данных При наличии более миллиона записей в объекте правила игры меняются. Перекос данных (Data Skew) — например, 200 тысяч учетных записей, связанных с одним владельцем или родителем — создает блокировки строк и замедляет любое массовое обновление. Решение заключается в распределении владения, а не в добавлении аппаратных средств, которые в любом случае находятся вне вашего контроля. Параллельно стоит рассмотреть архивацию: закрытые записи пятилетней давности, которые никто не читает, удорожают каждый запрос, выполняющий сканирование. ## Экраны: меньше — значит быстрее Средняя страница записи в зрелой организации накапливает два-три компонента в год, потому что каждый заинтересованный владелец просит "еще один виджет". Каждый компонент Lightning выполняет свои вызовы. Две операции приносят наибольшую выгоду: перемещение второстепенных компонентов на отдельные вкладки, которые загружаются только при нажатии, и применение видимости компонентов в зависимости от типа записи или роли, чтобы пользователь видел только то, что актуально для него. Сочетание этих двух подходов снижает EPT на десятки процентов без изменения кода. ## Порядок действий, который работает Начинается с недели измерений без изменений, чтобы установить надежный базовый уровень для пяти ключевых экранов и трех основных процессов. Затем обрабатываются экраны — это дешево и быстро. На третьем этапе объединяются автоматизации по объектам, и только на четвертом этапе затрагиваются запросы и модель данных. Интеграции обрабатываются параллельно, если измерения показали, что они являются причиной. Логика такого порядка экономична: первые слои дешевы и обратимы, последние дороги и требуют регрессионного тестирования. Подробнее об этом можно прочитать в наших статьях [Salesforce Health Check](/ru/insights/salesforce-health-check-guide) и [Признаки необходимости обновления системы Salesforce](/ru/insights/salesforce-system-upgrade-signs). ## Распространенные риски и профилактические меры Большой риск — оптимизация без базового уровня: выполняются десять изменений, пользователи по-прежнему жалуются, и нет способа узнать, что помогло. Измерение до и после каждого значительного изменения — это необходимое условие, а не роскошь. Второй риск — устранение самого громкого симптома. Экран, на который больше всего жалуются, не обязательно самый медленный — иногда он просто открывается чаще всего за день. Третий риск — изменение автоматизаций без тестового покрытия: объединение Flows — это действие с наибольшим потенциалом для скрытого нарушения бизнес-логики. ## Как измеряется успех Достаточно четырех метрик: средний EPT на пяти ключевых экранах, время сохранения в основном бизнес-процессе, количество сбоев по таймауту и лимитам платформы за месяц, а также доля запросов, длящихся более пяти секунд. Пятый показатель — дополнительный и нетехнический — это количество жалоб на производительность в Service Desk, которое должно уменьшаться по мере фактического улучшения. ### Вопросы и ответы **С чего начать, когда пользователи жалуются, что 'система работает медленно'?** С измерения, а не с предположений. Lightning Usage App показывает, какие компоненты интерфейса медленные для каких пользователей, а EPT (Experienced Page Time) для каждой страницы записи указывает на проблемный элемент. Общая жалоба без измерения почти всегда приводит к исправлению не того компонента. **Что такое неселективный запрос и почему это критично?** Неселективный запрос — это запрос, фильтрация которого не поддерживается индексом и требует полного сканирования большой таблицы. При более чем миллионе записей такой запрос приводит к ошибке тайм-аута или значительно замедляет любой зависящий от него процесс. Решение: фильтрация по индексированным полям, отказ от использования NULL и начальных символов в LIKE, а также запрос пользовательского индекса. **Когда оправдано использование Skinny Table?** Когда есть ключевой отчет или представление списка (List View), который запрашивает ограниченное количество полей из объекта с миллионами записей, и фильтрация уже оптимизирована. Это запрос в поддержку Salesforce, а не самостоятельная настройка, и он решает проблему чтения данных — не записи и не тяжелых автоматизаций. **Улучшает ли производительность замена Process Builder на Flow?** В большинстве случаев да, но не из-за самого инструмента, а из-за консолидации. Реальная выгода достигается за счет сокращения количества автоматизаций, работающих с одним объектом, и переноса ресурсоемких операций на асинхронную обработку, а не просто за счет перехода. **На сколько реально ожидать улучшения?** В рамках проекта по диагностике и целенаправленной оптимизации, сокращение времени загрузки наиболее ресурсоемких страниц на 30–50% в течение шести-десяти недель является реалистичной целью. Большее улучшение обычно требует изменения модели данных или архитектуры интеграции. --- ## Внедрение Salesforce в организации: полное руководство от предпроектного анализа до запуска URL: https://hpi.pro/ru/insights/salesforce-implementation-guide Большинство неудач при внедрении Salesforce связаны не с разработкой, а с этапами перехода: поспешный переход от Discovery к реализации, миграция без тщательной проверки и UAT без ответственного владельца. Данное руководство подробно описывает процесс внедрения по этапам, deliverables и процедурам утверждения. ## Краткий ответ Ключевой вопрос при внедрении Salesforce в организацию заключается не в том, «какой модуль активировать первым», а в том, как выстроить путь, на котором каждый этап генерирует утвержденный результат, а не просто очередную встречу. Данное руководство описывает восемь этапов: Discovery, Solution Design, поэтапное построение, миграция, UAT, обучение, Go Live и Hypercare. На каждом этапе предусмотрен обязательный результат, утверждающее лицо и основной риск, который необходимо устранить, прежде чем двигаться дальше. Основная идея — это неотъемлемая последовательность: невозможно начать построение без утвержденного дизайн-решения, и невозможно запустить систему без UAT, подписанного лицом, обладающим деловыми полномочиями. При пропуске этапа ошибка не исчезает — она ​​просто переходит на этап, где ее исправление становится дороже. Дополнительная информация о решении о замене существующей системы доступна в статье [Замена CRM-системы на Salesforce](/ru/insights/replace-crm-with-salesforce). ## Полная карта этапов | Этап | Обязательный результат | Кто утверждает | Основной риск | | --- | --- | --- | --- | | Discovery | Документ As-Is/To-Be, базовые показатели и метрики успеха | Бизнес-спонсор и владелец процесса | Размытое определение успеха, обнаруживаемое только на UAT | | Solution Design | Модель данных, разрешения, ADR и схема интеграции | Архитектор Salesforce и CIO | Решение, построенное вокруг точечного запроса, а не процесса | | Поэтапное построение | Рабочий вертикальный срез в каждом спринте, с демонстрацией | Product Owner | Накопление бэклога из "почти готового" без определения завершения | | Миграция | Результат полной репетиции миграции по критериям качества | Владелец данных по объекту | Дублирующиеся или отсутствующие данные, обнаруживаемые только после загрузки в продуктивную среду | | UAT | Подписание владельцами процессов сквозных сценариев | Руководители бизнес-команд | Поверхностное тестирование, охватывающее только "счастливый путь" | | Обучение | План внедрения, учебные материалы и список чемпионов | CRM-менеджер | Пользователи, обучающиеся "на ходу" и генерирующие плохие данные | | Go Live | Подписанный контрольный список Go/No-Go и план отката | Руководство проекта | Запуск без плана аварийного отступления на случай сбоя | | Hypercare | Ежедневный журнал ошибок и метрика принятия по отношению к базовому уровню | CRM-менеджер и команда внедрения | Преждевременное завершение проекта до стабилизации принятия | ## Discovery: Прежде чем приступать к инструментам Этап Discovery определяет все последующие действия, но при этом является этапом, который многие организации сокращают, чтобы «уже начать строить». Требуемый результат — это не презентация, а документ, включающий задокументированный процесс «как есть» (As-Is), целевое состояние «как будет» (To-Be) и четкий список того, что не войдет в первую версию. Без такого определения любой новый запрос, поступивший через два месяца, будет восприниматься как «само собой разумеющаяся» часть проекта. Наиболее практичный инструмент на этом этапе — это измеримый базовый уровень: время обработки лида, процент сделок, закрытых без двойного ввода, доля пустых полей в карточке клиента. Без числового значения до изменений невозможно доказать улучшение после запуска — можно только чувствовать, что оно есть. Организации, пропускающие этот этап, в любом случае возвращаются к нему, обычно в процессе построения, и это обходится дороже. Дополнительные последствия раннего пропуска подробно описаны в разделе [Ошибки при внедрении Salesforce](/ru/insights/crm-implementation-mistakes). ## Solution Design: Где принимаются самые дорогостоящие решения Solution Design — это этап, на котором выбирается один из нескольких возможных вариантов реализации и документируется, почему был выбран именно этот, а не другие. Модель данных, структура разрешений (включая совместное использование между ролями и регионами) и диаграмма интеграций с такими системами, как ERP, платежные шлюзы или маркетинговые платформы, – все это должно быть описано до начала разработки. Распространенной ошибкой является предоставление команде разработчиков «решать по ходу дела», как будет выглядеть модель совместного доступа, поскольку это кажется технической деталью. На самом деле, изменение модели совместного доступа после того, как в продуктивной среде уже существуют сотни записей, представляет собой отдельный проект. Поэтому, когда решение затрагивает несколько отделов или влияет на конфиденциальные разрешения, следует убедиться, что ответственность и роли в проекте четко ясны – см. подробнее в [Команда проекта Salesforce](/ru/insights/salesforce-project-team-roles). ### Что должно быть описано в Solution Design - Модель объектов и ключевых полей, включая то, что не было реализовано в первой версии. - Карта разрешений по ролям, включая исключения и случаи временного доступа. - Список интеграций с указанием направления потока данных и частоты синхронизации. - Не менее трех архитектурных решений с отвергнутыми альтернативами и причинами отказа. ## Поэтапное построение: Вертикальный срез, а не набор экранов На этапе построения наиболее распространенная ловушка — это продвижение «в ширину»: создание всех экранов одновременно, без того, чтобы ни один процесс не работал сквозным образом. Правильный подход — построение одного вертикального среза за каждый цикл: полный процесс с реальными данными и репрезентативными разрешениями, который можно продемонстрировать владельцу процесса и получить немедленную обратную связь. Каждый спринт должен завершаться демонстрацией, а не просто "загруженным кодом". Когда отсутствует регулярная демонстрация, накапливается запас "почти готового", который оказывается неполным только на этапе UAT, и именно это удорожает проект в его последней трети. ## Миграция: Самая недооцененная часть Миграция данных зачастую является самым большим риском в проекте и обычно получает наименьшее количество времени в графике. Обязательно проведение полной «репетиции» (Rehearsal): загрузка данных в тестовую среду в полном объеме, включая реальные объемы, и проверка результатов по заранее определенным критериям качества: дубликаты, отсутствующие обязательные поля, формат дат и валют, а также соответствие между системами. Полезная таблица для управления этим риском: | Тест качества | Что проверяется | Рекомендуемый порог принятия | | --- | --- | --- | | Полнота обязательных полей | Процент записей с пустым критическим полем | Менее 2% | | Дубликаты | Клиенты/лиды с тем же бизнес-идентификатором | Менее 1% после дедупликации | | Соответствие формату | Даты, валюты, коды стран | 100% соответствие целевому стандарту | | Связность записей | Ненарушенные отношения "родитель-потомок" при переносе | 100% критических отношений | ## UAT: Тестирование с реальной ответственностью, а не техническое подписание Правильно проведенное UAT предполагает, что владельцы процессов сами выполняют сквозные сценарии, а не команда проекта демонстрирует им. Рекомендуется выбрать 8-12 сценариев, которые охватывают не только стандартный путь, но и краевые случаи: клиент без адреса электронной почты, отмененная сделка после одобрения, пользователь с частичными разрешениями. Подписание UAT должно быть явным — имя, дата и список открытых недочетов для следующей версии, а не просто «устное одобрение на встрече». ## Обучение: Здесь проект либо успешно реализуется, либо тихо терпит неудачу Даже превосходное техническое решение потерпит неудачу, если пользователи его не примут. Хорошая программа обучения включает в себя материалы, адаптированные для каждой роли (не единую презентацию для всех), демонстрации в среде Sandbox с известными данными и список «чемпионов» — ведущих пользователей из каждой команды, которые могут отвечать на текущие вопросы, не открывая заявки в службу поддержки. Организации, инвестирующие в обучение за две недели до Go Live, обычно сталкиваются с меньшим количеством ложных сообщений об ошибках («система не работает», когда на самом деле речь идет об ошибке ввода). ## Go Live и Hypercare: Запуск – это начало, а не завершение Выход в продуктивную среду (Go Live) требует подписанного контрольного списка, который включает проверку разрешений в продуктивной среде, подтверждение активных интеграций и четкий план отката на случай обнаружения критической ошибки. После запуска начинается период Hypercare — обычно от двух до четырех недель, в течение которых команда ежедневно отслеживает журналы ошибок, фактический уровень использования и жалобы пользователей, оперативно устраняя проблемы с высоким приоритетом в течение одного рабочего дня. Преждевременное завершение проекта до стабилизации принятия является распространенной ошибкой: данные за первые две недели почти всегда показывают худшую картину, чем реальность после формирования привычек. ## Что на самом деле идет не так в средних организациях Израиля В практике HPI Pro по работе со средними компаниями в Израиле (от 20 до 300 сотрудников) большинство проблем возникают не из-за неправильного выбора продукта, а из-за сокращения процессов: - **Руководство, недоступное для утверждения объема работ.** Проект продвигается на основе интерпретации ИТ-менеджера, и когда руководство наконец видит результат, оно запрашивает изменения, которые отбрасывают проект на недели назад. - **Зависимость от одного разработчика или небольшой компании без резервного документирования.** Когда человек уходит, некому понять решения, принятые на этапе Solution Design. - **Миграция из неофициальных источников.** Таблицы Excel, которыми управляет каждый менеджер по продажам отдельно, без согласованного источника истины, что превращает этап очистки в подпроект. - **Сжатие UAT до одной недели перед запуском.** Когда график сжимается, UAT является первым этапом, который сокращается, и именно этот этап наиболее выгодно сохранить. - **Отсутствие обучения, адаптированного к языку и роли.** Общие учебные материалы на английском языке для отдела продаж, работающего на иврите, приводят к частичному использованию и фактическому обходу системы. Для минимизации этих рисков необходимо не "работать быстрее", а с самого начала планировать слой DevOps проекта — отдельные тестовые среды, определенный процесс выпуска и отслеживание изменений. Более подробно об этом в статье [Salesforce DevOps Sandboxes](/ru/insights/salesforce-sandbox-devops-strategy). ## Контрольный список перед переходом между этапами - ☐ Для каждого этапа имеется письменный результат, а не только протокол встречи. - ☐ Базовый уровень измерен до начала проекта. - ☐ Модель данных и разрешения утверждены до начала разработки. - ☐ Каждый спринт завершается демонстрацией вертикального среза. - ☐ Выполнена полная репетиция миграции с определенным порогом качества. - ☐ UAT подписано владельцами процессов с перечнем открытых недочетов. - ☐ Существует план обучения, адаптированный под роль и язык. - ☐ Имеется контрольный список Go/No-Go и план отката. - ☐ Период Hypercare определен по срокам и ответственности. ## Как измерить фактический успех проекта | Область измерения | Что проверяется | Рекомендуемая частота отслеживания | | --- | --- | --- | | Принятие | Процент активных пользователей по отношению к общему количеству лицензий | Еженедельно в течение первого месяца | | Качество данных | Отсутствующие обязательные поля, дубликаты | До Go Live и раз в месяц | | Производительность процесса | Время обработки лида/сделки по отношению к базовому уровню | Ежемесячно в течение первых трех месяцев | | Ошибки | Количество обращений в службу поддержки и процент повторного открытия | Ежедневно в период Hypercare | Предприятия, выбирающие профессиональное сопровождение на протяжении всего этого пути, от Discovery до завершения этапа Hypercare, могут воспользоваться услугами [по внедрению Salesforce](/ru/salesforce-implementation), чтобы каждый этап соответствовал своим результатам, утверждениям и надлежащему контролю рисков, прежде чем переходить к следующему. ## Профессиональные источники - Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html - HPI Pro – Внедрение Salesforce — https://hpi.pro/salesforce-implementation - HPI Pro – Методология работы — https://hpi.pro/methodology ### Вопросы и ответы **Сколько времени занимает полное внедрение Salesforce в средней компании?** Для компании с 30-80 пользователями и базовыми процессами продаж и обслуживания полный цикл от Discovery до Go Live занимает от 10 до 16 недель. Проекты со сложными интеграциями с ERP- или биллинговыми системами увеличиваются до 20-24 недель, в основном из-за миграции и тестирования. **В чем разница между проектированием решения (Solution Design) и обычной документацией требований?** Проектирование решения (Solution Design) включает модель данных, карту разрешений, схему интеграций и архитектурные решения с обоснованием отклоненных альтернатив. Обычная документация требований описывает, что хочет пользователь; Solution Design описывает, как система будет реализована на практике и какова стоимость каждого выбора. **Можно ли пропустить этап UAT, если сроки поджимают?** Можно сократить его объем, но не исключить полностью. Минимальная версия UAT — это тестирование 5-8 критически важных сквозных сценариев с фактическими владельцами процессов. Полный пропуск почти всегда приводит к выявлению ошибок в первые недели после Go Live, когда стоимость их исправления значительно выше. **Кто отвечает за качество данных при миграции из Excel или старой системы?** Профессиональная ответственность за правила преобразования и очистки данных лежит на команде внедрения, но ответственность за корректность коммерческого контента остается за владельцем данных в организации. Поэтому рекомендуется назначить Владельца Данных (Data Owner) для каждого объекта, который утверждает результаты миграции до их загрузки в рабочую среду. **Что происходит на самом деле в период Hypercare?** Как правило, это от двух до четырех недель, в течение которых команда внедрения оказывает оперативную поддержку, отслеживает логи ошибок и ежедневное использование системы, а также устраняет критические ошибки в течение одного рабочего дня. По окончании этого периода ответственность планомерно передается команде технического обслуживания или внутренней поддержке. --- ## Архитектура Salesforce для организаций: как спроектировать масштабируемую систему URL: https://hpi.pro/ru/insights/crm-architecture-guide Организация, добавляющая Custom Objects, Flows и точечные интеграции без документированного архитектурного уровня, накапливает технический долг, который проявляется при попытке добавить новый бизнес или выйти на новый рынок. Эта статья анализирует архитектуру Salesforce, разделяя ее на шесть практических уровней. ## Краткий ответ Качество архитектуры Salesforce определяется не количеством созданных компонентов, а способностью организации внедрять новый бизнес, продукты или выходить на новые рынки, не разрушая то, что уже функционирует. Наиболее распространенная проблема, с которой мы сталкиваемся, — это не ошибочный выбор технологии, а отсутствие документированного уровня принятия решений: кто является владельцем каждого объекта, почему выбран Flow, а не Apex, и почему существует пять отдельных интеграций вместо одного уровня Middleware. Данная статья делит архитектуру на шесть слоев, которые необходимо проектировать совместно, а не изолированно: модель данных и объектов, совместный доступ и разрешения, автоматизация, интеграции, стратегия Org, а также DevOps со Scalability. Расширенные сведения об обработке ошибок интеграции представлены в статье [Мониторинг интеграций Salesforce](/ru/insights/salesforce-integration-error-handling). ## Модель данных и объектов: основа, на которой все строится Распространенная ошибка во многих организациях: создание нового Custom Object для каждого поступающего бизнес-требования, без проверки возможности использования дополнительного поля в существующем объекте или Record Type. Результатом через два-три года является Org с 80-120 пользовательскими объектами, некоторые из которых дублируют друг друга по смыслу, без документации о причинах их создания. Основной принцип – задавать вопросы перед созданием каждого объекта: кто является бизнес-владельцем, каков источник истины (Salesforce или внешняя система), и что происходит при удалении или дублировании записи. Например, компании, управляющие сложным каталогом продуктов, часто создают отдельный объект для каждой категории вместо использования Record Types для Product2, что приводит к излишней нагрузке на обслуживание при каждом обновлении. Полезная таблица для проверки зрелости модели данных: | Компонент | Проверочный вопрос | Признак предупреждения | | --- | --- | --- | | Пользовательские объекты | Существует ли аналогичный объект, который можно расширить? | Два объекта с преимущественно одинаковыми полями | | Поля | Используется ли поле для более чем одного процесса? | Более 800 полей в центральном объекте | | Связи | Выбраны ли Master-Detail или Lookup намеренно? | Master-Detail, выбранный «по умолчанию» | | External ID | Имеет ли каждый синхронизированный объект уникальный ключ? | Синхронизация только по имени или дате | ## Совместный доступ и разрешения: уровень, который незаметно разрушается Слабая модель разрешений обнаруживается не сразу — она проявляется, когда кто-то видит данные, которые не должен видеть, или когда в управленческом отчете отображается меньше строк, чем ожидалось, потому что Sharing Rule блокирует доступ. Выбор между Role Hierarchy, Organization-Wide Defaults, Sharing Rules и Permission Sets должен основываться на фактической структуре организации, а не на официальной иерархической структуре в организационной схеме. Распространенный анти-паттерн: предоставление «View All» или «Modify All» на уровне профиля для «решения» проблемы с разрешениями в условиях нехватки времени, без последующего возврата и ограничения. Это работает в краткосрочной перспективе и создает широкое раскрытие информации в долгосрочной — особенно в регулируемых отраслях, таких как финансы или здравоохранение. Permission Set Groups позволяют создавать модульные разрешения, которые можно добавлять и удалять, не затрагивая базовый профиль, и это более безопасный способ работы с растущей организацией. Criteria-Based Sharing Rules для объектов с миллионами записей требуют тестирования нагрузки перед Production — существуют случаи, когда, казалось бы, простое правило Shared приводит к пересчету, занимающему часы и останавливающему ночные процессы. ## Автоматизация: Flow против Apex Вопрос «Flow или Apex» — это вопрос не вкуса, а сложности, объема и срока службы. Flow более понятен для операционного отдела, создается и поддерживается быстрее, и подходит для изменяющейся бизнес-логики. Apex требуется, когда есть массовая обработка тысяч записей в одной транзакции, когда необходим точный контроль порядка выполнения по отношению к другим Triggers, или когда требуется автоматическое тестирование (Test Coverage) для регулирования или формального управления изменениями. Частый анти-паттерн в растущих организациях: цепочки Flow, вызывающие друг друга (Flow, вызывающий Flow, вызывающий Flow), без центральной карты, показывающей порядок выполнения. Когда что-то ломается, никто не знает, какой Flow запустился первым. Пример из практики: организация с 14 активными Flows для Opportunity, три из которых имеют одинаковую логику обновления статуса, написанные в разное время разными людьми, без проверки того, что уже существует. Практическое эмпирическое правило: если в одной бизнес-логике более 5-6 сложных условий или требуется внешний вызов внутри цикла, предпочтительнее Apex. В противном случае Flow предпочтительнее, потому что он доступен для обслуживания, даже если оригинальный разработчик уже не работает в компании. ## Интеграции: от Point-to-Point к управляемому уровню Организация, начинающая с двух внешних подключений (например, ERP и платежная система), обычно строит их напрямую, Point-to-Point, и это разумно на данном этапе. Проблема начинается, когда добавляется третье, четвертое и пятое подключение — каждое со своей логикой повторных попыток, обработки ошибок и сопоставления полей, без общего стандарта. На этом этапе любое изменение в исходной системе нарушает одно или несколько подключений, о чем никто заранее не знает. Переход на уровень Middleware (MuleSoft или специализированный Integration Layer) не обязательно должен быть огромным проектом — можно начать с самого хрупкого или дорогостоящего в обслуживании подключения и постепенно переходить. Принципы, которые следует применять в каждой новой интеграции: Idempotency (повторный вызов не создает дублирующую запись), External ID для точной идентификации и журнал, позволяющий точно восстановить, что произошло при каждом вызове. Расширенные сведения о шаблонах интеграции представлены в статьях [Подключение Salesforce к ERP](/ru/insights/salesforce-erp-integration) и [Шаблоны интеграции Salesforce](/ru/insights/salesforce-integration-patterns). ## Стратегия Org: Single Org, Multi-Org или сегментация бизнес-подразделений Это одно из самых дорогих решений для последующей корректировки. Single Org с сегментацией бизнес-подразделений (использование Record Types, Sharing и Permission Sets для логического разделения) подходит для большинства организаций, поскольку он сохраняет единый источник истины и унифицированные показатели отчетности. Multi-Org целесообразен, когда бизнес-подразделения требуют существенно противоречивых моделей разрешений, когда происходит слияние или поглощение, приносящее существующий Org, или когда фактическая нагрузка на разрешения снижает производительность. Переход между моделями после создания организации является сложным проектом — слияние данных, переназначение разрешений и иногда потеря истории. Полное описание соображений для принятия решения представлено в статье [Salesforce Multi Org](/ru/insights/salesforce-single-org-vs-multi-org). ## DevOps и Scalability: как поддерживать возможность изменений Организация, которая разрабатывает непосредственно в Production, без упорядоченного Sandbox и без инструментов CI/CD (таких как Copado, Gearset или SFDX), быстро приходит к ситуации, когда каждое изменение опасно. Правильный процесс DevOps включает минимум Sandbox для разработки, Sandbox для тестирования, контроль версий для Metadata и автоматический процесс развертывания с регрессионным тестированием. Таблица ключевых архитектурных решений и их долгосрочных последствий: | Решение | Немедленное преимущество | Последствия через 2-3 года | | --- | --- | --- | | Custom Object для каждого требования | Быстрое решение точечной проблемы | Org с десятками дублирующихся объектов, сложно поддерживать | | Временные разрешения «View All» | Решает проблему за минуты | Широкое раскрытие информации, которое сложно отследить и закрыть | | Flow, вызывающий Flow | Быстрая разработка без кода | Цепочки, которые сложно отслеживать и тестировать | | Дополнительная интеграция Point-to-Point | Быстрое подключение между двумя системами | Сеть подключений, где любое изменение ломает что-то другое | | Разработка непосредственно в Production | Экономит время на настройку процесса | Высокий риск для любого изменения, трудности с восстановлением | | Single Org без логического разделения | Единая отчетность с первого дня | Трудности с добавлением бизнес-единицы с различными потребностями | ## Пример организационного сценария Дистрибьюторская компания с тремя бизнес-подразделениями в течение четырех лет работала на одной Org, при этом каждое подразделение добавляло свои объекты, Flows и интеграции по мере необходимости. Когда руководство решило добавить четвертое подразделение, выяснилось, что нет единого документа, объясняющего, кто является владельцем каждого объекта, и три различные интеграции синхронизируют клиентов с финансовой системой по противоречивым логикам. Архитектурная команда провела полное картирование: выявила 23 объекта без явного владельца, шесть перекрывающихся цепочек Flow и две интеграции, которые создавали дублирующиеся записи из-за отсутствия последовательного External ID. Решение заключалось не в перестройке, а в постепенном документировании, унификации логики Sharing с помощью Permission Set Groups и переходе критических интеграций на единый уровень Middleware. В течение двух кварталов время добавления нового бизнес-подразделения сократилось с нескольких месяцев до примерно шести недель. ## Распространенные анти-паттерны в растущих организациях - **Custom Object для каждого запроса** — создание нового объекта без проверки наличия аналогичного. - **«Временные» широкие разрешения** — выдаются под давлением и никогда не сокращаются обратно. - **Flow-in-Flow без картирования** — цепочки автоматизации без центральной схемы выполнения. - **Point-to-Point без Governance** — каждое новое подключение строится отдельно без общего стандарта. - **Разработка в Production** — прямые изменения без Sandbox, тестирования или контроля версий. - **Отсутствие External ID** — синхронизация по имени или электронной почте, приводящая к дублированию записей. ## Чек-лист для проверки зрелости архитектуры - ☐ Для каждого пользовательского объекта есть документированный бизнес-владелец. - ☐ Модель Sharing проверена под реалистичной нагрузкой данных. - ☐ Существует центральная карта всех цепочек автоматизации. - ☐ Для каждой интеграции есть External ID, Retry и журнал ошибок. - ☐ Существует упорядоченный процесс от Sandbox до Production с регрессионным тестированием. - ☐ Принято явное решение между Single Org и Multi-Org с письменным обоснованием. - ☐ Governor Limits проверяются относительно прогноза роста на три года. Когда архитектура Salesforce требует профессионального сопровождения, а не только самостоятельной работы, это относится к области [Услуги по архитектуре CRM](/ru/crm-architecture). ## Профессиональные источники - Salesforce Integration Patterns — https://architect.salesforce.com/docs/architect/fundamentals/guide/integration-patterns.html - Salesforce Data Integration Decision Guide — https://architect.salesforce.com/docs/architect/decision-guides/guide/data-integration.html - HPI Pro – Архитектура CRM — https://hpi.pro/crm-architecture - HPI Pro – Интеграции и данные — https://hpi.pro/integrations-data ### Вопросы и ответы **В чем разница между Flow и Apex при выборе уровня автоматизации?** Flow подходит для часто меняющейся бизнес-логики, взаимодействия с операционной командой и при наличии менее 5-6 сложных условий. Apex необходим при сложных транзакциях, циклах с внешними вызовами, пакетной обработке тысяч записей или потребности в автоматизированных тестах (Test Classes) для соответствия требованиям. **Когда пора переходить с Single Org на несколько организаций?** Когда различные бизнес-подразделения требуют противоречивых моделей разрешений, когда нагрузка разрешений влияет на производительность, или когда слияние/поглощение приносит отдельный Org. Переход дорогой и сложный – следует сначала проверить, не решают ли проблему Business Unit Segmentation или Multi-Currency внутри одного Org. **Как построить модель Sharing, которая не рухнет под нагрузкой?** Сначала составьте карту организационной структуры и групп пользователей, затем выберите между Role Hierarchy, Sharing Rules и Permission Sets в зависимости от масштаба исключений. Sharing Rules на основе критериев, работающие с миллионами записей, требуют тестирования производительности до, а не после развертывания в Production. **Что делать со старыми точечными интеграциями, накопленными годами?** Составьте карту всех существующих соединений, выявите дублирование логики между системами и разработайте поэтапный план перехода к уровню Middleware или архитектуре, управляемой событиями. Не заменяйте все сразу – начните с наиболее хрупкой или наиболее дорогой в обслуживании интеграции. **Как убедиться, что архитектура выдержит нагрузку через три года?** Проверьте Governor Limits относительно ожидаемого объема роста, количества кастомных объектов, глубины цепочек автоматизации и числа активных интеграций. Организация с более чем 15 триггерами на одном объекте или цепочками Flow, которые вызывают друг друга, является ранним предупреждающим знаком. --- ## CRM-проектирование перед внедрением Salesforce: необходимые результаты до начала разработки URL: https://hpi.pro/ru/insights/crm-discovery-guide Discovery, завершающийся красиво оформленной презентацией, — это не Discovery. По окончании этапа проектирования на столе должны лежать семь ключевых результатов, на основе которых можно строить, оценивать стоимость и проводить тестирование. Данное руководство подробно описывает содержание каждого результата, критерии его зрелости и адекватные временные затраты. ## Что должно быть готово после этапа проектирования Проектирование CRM оценивается не по количеству встреч, а по фактически достигнутым результатам, которые можно использовать в работе. Если по завершении этого этапа руководитель проекта все еще не может составить план работ, разработчик не знает, какой объект управляет процессом, а менеджер по данным не понимает, откуда поступает информация о клиентах, — значит, проектирование не завершено, даже если презентация одобрена. Данное руководство описывает семь ключевых результатов. Для каждого из них определен критерий готовности: одно утверждение, на которое можно ответить «да» или «нет». Если ответов «почти» наберется более двух, то переход к этапу реализации сопряжен с риском, который уже можно оценить. Общий обзор этапов после проектирования представлен в [Руководстве по внедрению Salesforce](/ru/insights/salesforce-implementation-guide). ## Результат 1: Карта процессов с уровнем принятия решений Это не детальная блок-схема каждого клика, а карта точек принятия решений: кто принимает решение, на основе какой информации, что происходит в каждом ответвлении и что происходит при отсутствии решения. Большинство сбоев в проектах CRM возникают не в стандартном процессе, а в его ответвлениях — замороженная сделка, клиент, вернувшийся через два года, запрос, открытый не тем клиентом. Критерий готовности: можно взять реальную сделку за последний месяц и отследить ее по карте от начала до конца без пробелов. ## Результат 2: Бизнес-глоссарий Этим результатом чаще всего пренебрегают, и на этом же чаще всего платят. «Клиент» означает одно в финансах и другое в продажах. «Активный проект» интерпретируется по-разному в операционной деятельности и в управлении. Пока определения не зафиксированы, каждый отчет вызывает споры. Глоссарий для каждого термина должен содержать: определение в одном предложении, сущность в Salesforce, которая его представляет, поле, определяющее статус, и департамент, ответственный за это определение. ## Результат 3: Утвержденная базовая модель данных На этапе проектирования не создается полная ERD (диаграмма «сущность-связь»), но принимаются решения по четырем вопросам, изменение которых впоследствии будет дорогостоящим: - Основывается ли бизнес-активность на Opportunity, на пользовательском объекте или на их комбинации, и каково соотношение между ними. - Представляет ли Account юридическое лицо, физическое местоположение или группу закупок — и как обрабатывается иерархия. - Каков уникальный идентификатор, который связывает клиента между Salesforce и основными системами. - Какие исторические данные будут перенесены в систему, а какие останутся в источнике. Критерий готовности: можно нарисовать на доске пять основных объектов и связи между ними, не открывая файл. ## Результат 4: Модель полномочий и доступа Модель полномочий определяется вопросом о том, кто не должен видеть информацию, а не о том, кто должен видеть. Эти два вопроса кажутся одинаковыми, но приводят к противоположным архитектурным решениям. Хорошее проектирование определяет организационные настройки по умолчанию для каждого основного объекта, механизм расширения и исключительные случаи, требующие особого доступа. | Вопрос | Что проверяется при проектировании | Почему это дорого изменить позднее | | --- | --- | --- | | Настройка по умолчанию для объекта | Приватный (Private), Общий доступ на чтение (Public Read) или Чтение/Запись (Read/Write) | Влияет на весь механизм совместного доступа выше | | Структура иерархии | Отражает ли иерархия ролей управление или географию | Изменение требует пересчета доступа по всем записям | | Межфункциональный доступ | Общие команды, ручной доступ или критерии | Определяет необходимость специализированной логики | | Конфиденциальные данные | Какие поля ограничены и кому | Последующее изменение может раскрыть уже просмотренную информацию | ## Результат 5: Карта систем и источников истины Для каждой основной сущности должен быть один объявленный источник истины и четкое направление синхронизации. Проектирование, которое оставляет две системы «обновляющими друг друга», создает конфликты, которые проявятся только в процессе эксплуатации. Карта должна также включать частоту и допустимую задержку: процесс продаж может выдерживать синхронизацию в течение пяти минут, кредитный контроль — обычно нет. ## Результат 6: Критерии приемки для ключевых процессов Это связь между проектированием и тестированием. Для каждого ключевого процесса требуется от трех до пяти приемочных критериев, сформулированных как наблюдаемый результат: «После закрытия сделки заказ создается в основной системе в течение пяти минут с тем же идентификатором клиента». Такая формулировка является одновременно требованием, тестовым сценарием и определением завершения. Без этого этап UAT (пользовательское приемочное тестирование) превращается в сбор комментариев по дизайну. ## Результат 7: Базовые показатели до изменений Невозможно доказать улучшение без предварительного измерения. На этапе проектирования выбираются три-пять показателей и измеряются в текущем состоянии, даже если измерение выполняется вручную и приблизительно. Выбор показателей и способ их привязки к бизнес-выгоде подробно описаны в [Руководстве по ROI и показателям успеха Salesforce](/ru/insights/salesforce-roi-kpis). ## Иллюстративный пример: Сеть частных клиник Следующий сценарий является гипотетическим и предназначен только для иллюстрации. Сеть клиник с восемью филиалами приступила к проекту CRM для централизации запросов пациентов. В ходе проектирования выяснилось, что два филиала по-разному определяют «повторный запрос»: один считает каждый звонок, другой — только запрос по новой теме. Различие казалось семантическим, но оно определяло, нужна ли системе один объект Case с иерархией или два отдельных объекта, и влияло на все отчеты по нагрузке для руководства. Команда не разрешила этот спор в документе. Она зафиксировала открытое решение, назначила ответственного на уровне операционного директора и установила крайний срок до начала разработки. Решение было принято в течение двух недель, и модель была построена однократно. Если бы решение было отложено, оно бы проявилось на этапе UAT — после того, как уже были созданы экраны и отчеты на основе ошибочного предположения. ## Признаки поверхностного проектирования - В документе описываются экраны и поля, но не описывается, что происходит при сбое процесса. - Нет зафиксированных решений, альтернативы которым были рассмотрены. - Все требования имеют высокий приоритет. - Рядом с процессами нет имен людей, только названия отделов. - Количество полей, запрашиваемых на одном экране, превышает двадцать пять, и никто не проверил, кто их заполняет. Связь между поверхностным проектированием и возникающими впоследствии сбоями подробно описана в [Руководстве по типичным ошибкам внедрения CRM](/ru/insights/crm-implementation-mistakes), а его влияние на сроки проекта объясняется в [Руководстве по длительности проектов Salesforce](/ru/insights/salesforce-project-timeline). ## При замене существующей системы Когда проект предполагает замену устаревшей CRM, проектирование получает дополнительную задачу: определить, что не будет переноситься. Старая система накапливает поля, автоматизации и отчеты, которыми уже никто не пользуется, и их слепое копирование переносит старый «технический долг» на новую платформу. Рекомендуемый порядок действий при такой миграции подробно описан в [Руководстве по замене CRM на Salesforce](/ru/insights/replace-crm-with-salesforce). ## Как понять, что можно начинать разработку Проанализируйте семь результатов и для каждого задайте вопрос о готовности. Если шесть из семи отвечают «да», можно начинать первый этап, управляя седьмым пунктом как задокументированным риском. Если три или более отвечают «почти», лучше продлить этап проектирования на две недели, чем обнаруживать пробелы после трех месяцев работы, построенной на неполных данных. Следующий логичный шаг — это преобразование результатов в поэтапный план, с четким решением о том, что входит в первую волну, а что сознательно откладывается. ### Вопросы и ответы **Сколько времени должно занимать CRM-проектирование перед проектом Salesforce?** Единой цифры нет, но существует разумное соотношение: этап проектирования обычно составляет от одной десятой до одной пятой от общего времени проекта и в основном зависит от количества сквозных процессов между отделами и количества исходных систем. Проектирование, которое длится дольше, как правило, страдает не от нехватки времени, а от отсутствия лица, уполномоченного принимать решения при разногласиях. **В чем разница между CRM-проектированием и документом требований?** Документ требований описывает то, что запросили пользователи. Проектирование описывает, какой бизнес-процесс будет выполняться, на какой модели данных, с какими разрешениями, с какими системами и как будет доказана его работоспособность. Одно и то же требование может быть реализовано пятью различными способами в Salesforce, и задача проектирования — выбрать один из них и обосновать выбор. **Можно ли проводить проектирование с поставщиком, который будет осуществлять внедрение?** Можно, и во многих случаях это эффективно. Риск заключается в том, что проектирование будет склоняться к тому, что удобно строить поставщику. Этот риск можно уменьшить, если результаты передаются организации в непатентованном формате, архитектурные решения обосновываются с рассмотрением альтернатив, а оценка стоимости этапа проектирования отделена от оценки стоимости внедрения. **Что делать, если владельцы процесса не согласны друг с другом по определению процесса?** Не следует закрывать разногласия расплывчатым текстом. Запишите его как открытое решение с указанием ответственного, срока и влияния на объем работ, и передайте его лицу, уполномоченному принять решение. Проектирование, формулирующее мнимый консенсус, впоследствии приводит к дорогостоящим запросам на изменения на этапе, когда код уже разработан. **Нужно ли проектировать все процессы до начала разработки?** Нет. Необходимо глубоко спроектировать процессы, входящие в первую волну, и в общих чертах наметить остальные, чтобы модель не была заблокирована в дальнейшем. Единственное, что необходимо решить заранее для всей картины, — это базовая модель данных и модель разрешений, поскольку их изменение впоследствии обходится значительно дороже, чем изменение интерфейса. --- ## 10 распространенных ошибок при внедрении CRM и Salesforce: как их избежать? URL: https://hpi.pro/ru/insights/crm-implementation-mistakes Большинство неудач в проектах CRM обусловлены не техническими сбоями, а отложенными решениями. В этом материале мы рассмотрим десять типичных ошибок, которые встречаются в проектах Salesforce, расскажем о ранних признаках их появления и о превентивных мерах, которые позволят минимизировать затраты при их своевременном применении, и избежать значительно больших расходов после запуска системы. ## Как интерпретировать данный перечень Десять ошибок, представленных ниже, упорядочены не по частоте их возникновения, а по последовательности появления на временной шкале проекта. Для каждой ошибки указаны три ключевых аспекта: ранний признак, который можно выявить в реальном времени; превентивное действие; и этап, после которого корректировка значительно удорожается. Основная идея проста — практически каждая из этих ошибок обходится очень недорого, если устранить её в течение двух подходящих недель. ## 1. Начало с перечня функций вместо процесса _Признак_: Документ требований структурирован как таблица желаемых возможностей, но ни одна строка не описывает бизнес-результат. _Фактическое развитие событий_: Проект создает систему, соответствующую списку функций, но не меняет способ работы. Год спустя руководство спрашивает, что изменилось, и не получает измеримого ответа. _Предотвращение_: Каждое требование связывается с процессом, который оно обслуживает, и с метрикой, которая должна измениться. Требование, не отвечающее на эти два вопроса, переносится в лист ожидания. Перечень артефактов, предотвращающих данную ситуацию, подробно описан в [руководстве по анализу требований CRM](/ru/insights/crm-discovery-guide). ## 2. Отсутствие единого владельца процесса _Признак_: На совещания приходят четыре сотрудника из одного отдела, и ни один из них не уполномочен сказать: «Так будет сделано». _Фактическое развитие событий_: Каждое решение принимается в компромиссной форме, пытаясь угодить всем, что приводит к созданию двух параллельных путей вместо одного. Система становится вдвое сложнее, чем необходимо. _Предотвращение_: За каждым процессом закрепляется имя одного человека. Рекомендованное распределение ролей подробно описано в [руководстве по ролям в проекте Salesforce](/ru/insights/salesforce-project-team-roles). ## 3. Откладывание архитектурных решений на потом _Признак_: Команда активно разрабатывает экраны, тогда как вопрос «каков источник истины для данных о клиенте» остается открытым. _Фактическое развитие событий_: Когда решение наконец принимается, оно противоречит уже реализованному. Часть работы оказывается бесполезной, и первоначальная оценка проекта теряет актуальность. _Предотвращение_: В начале проекта определяются три-пять решений, изменение которых будет дорогостоящим – основная модель данных, источник истины, модель разрешений – и назначается дата их принятия до начала разработки. ## 4. Импорт задолженностей старой системы _Признак_: Спецификация миграции включает все поля из предыдущей системы, в том числе те, названия которых заканчиваются на «_old_2». _Фактическое развитие событий_: Новая платформа запускается с двумя сотнями полей, которые никто не поддерживает, отчетами, основанными на недостоверных данных, и пользователями, которые делают вывод, что новая система также несерьезна. _Предотвращение_: Каждое переносимое поле должно иметь владельца и подтвержденное использование за последний год. Остальные данные переносятся в читаемый архив, а не в действующую систему. ## 5. Измерение прогресса по закрытым историям _Признак_: Еженедельный отчёт показывает высокий процент завершения, но никто ещё не смог выполнить полный сквозной процесс. _Фактическое развитие событий_: Проект выглядит успешным на графиках до недели перед запуском, а затем выясняется, что все части работают по отдельности, и никто не проверял их интеграцию. _Предотвращение_: Определяется веха «первый сквозной действующий процесс» как можно раньше, даже если он охватывает только один сценарий. До её достижения проценты завершения не являются информативными. ## 6. Обязательные поля как замена дисциплины данных _Признак_: Экран создания записи включает двенадцать обязательных полей, из которых по трём никто не знает, кто должен указывать их значения. _Фактическое развитие событий_: Пользователи выбирают первое значение в списке, чтобы продолжить. Отчеты получают полностью заполненные, но при этом абсолютно неверные данные. _Предотвращение_: Требования обязательности применяются только к полю, необходимому для принятия решения в момент его запроса. Поля, которые требуются на более поздних этапах процесса, становятся обязательными на этих этапах. ## 7. Создание автоматизации до стабилизации процесса _Признак_: Существуют три механизма автоматизации, работающие с одним и тем же объектом, и никто не знает порядок их выполнения. _Фактическое развитие событий_: Непредвиденные побочные эффекты, циклы обновлений и, главное, невозможность изменить процесс без опасения что-либо нарушить. _Предотвращение_: Ручной или полуавтоматический процесс выполняется в течение нескольких недель, прежде чем он будет полностью автоматизирован. Автоматизация фиксирует решение — важно, чтобы это решение было верным. ## 8. UAT, выполняемое теми, кто разрабатывал систему _Признак_: Сценарии тестирования были написаны той же командой, что и вела разработку, и они охватывают в основном штатный ход событий. _Фактическое развитие событий_: Проблемы, возникающие в производстве, как правило, связаны с исключительными случаями — отмены, возвраты, дублирование клиентов, пользователь, покинувший процесс на полпути. _Предотвращение_: Тестирование выполняется сотрудниками, участвующими в процессе, на данных, максимально приближенных к реальным, с чётко определённой ответственностью за утверждение или отклонение результатов. ## 9. Обучение как разовое мероприятие _Признак_: План внедрения включает два семинара за неделю до запуска, и после этого ничего не запланировано. _Фактическое развитие событий_: Пользователи изучают экраны, а не процессы, забывают информацию в течение двух недель и обращаются к коллегам или к таблицам Excel. Уровень использования постепенно снижается, оставаясь незамеченным. _Предотвращение_: Обучение по ролям, максимально приближенное к моменту, когда сотрудник фактически будет выполнять действия, с доступной точкой поддержки в первые недели. ## 10. Отсутствие владельца после запуска в продуктив _Признак_: В плане проекта отсутствует пункт, описывающий, кто будет управлять системой на третий месяц. _Фактическое развитие событий_: Запросы на изменения копятся без ответа, мелкие неполадки становятся обходными рабочими процедурами, и система быстро устаревает. _Предотвращение_: Операционное владение, механизм обработки запросов и регулярный цикл выпуска обновлений определяются до запуска, а не после. В крупных организациях это обычно осуществляется через структурированную модель управления, как описано в [руководстве по внедрению Salesforce в корпоративной среде](/ru/insights/enterprise-salesforce-implementation). ## Стоимость корректировки в зависимости от стадии | Ошибка | Корректировка на этапе спецификации | Корректировка на этапе разработки | Корректировка после запуска в продуктив | | --- | --- | --- | --- | | Неверная модель данных | Изменение в схеме | Повторная разработка объекта | Внутренняя миграция и полное повторное тестирование | | Отсутствие владельца процесса | Назначение | Остановка и повторные решения | Поддержка двойного процесса бесконечно | | Задолженность от старой системы | Фильтрация списка полей | Очистка перед загрузкой | Очистка в действующей системе | | Лишние обязательные поля | Решение на этапе проектирования интерфейса | Изменение конфигурации | Очистка накопленных некорректных данных | | Отсутствие операционного владельца | Определение в плане | Наём или обучение | Восстановление доверия пользователей | ## Пример для иллюстрации: Средняя страховая компания Сценарий гипотетический и предназначен для иллюстрации. Страховая компания запустила Salesforce для управления агентами. Через три месяца выяснилось, что процент обновления записей агентов низок. Проверка не выявила ни одной технической неисправности: одновременно были обнаружены три из вышеуказанных ошибок — излишние обязательные поля в экране создания, отсутствие владельца процесса найма агентов и обучение, проведенное за два месяца до того, как первые новые агенты начали работать с системой. Коррекция не была технической. Удалены шесть обязательных полей, назначен единый владелец процесса из операционного отдела, и обучение разделено на короткие сегменты, рассылаемые в течение недели, когда каждая группа приступала к работе. Единственное необходимое архитектурное изменение заключалось в отсрочке обязательности двух полей до более позднего этапа процесса. ## Что делать с этим списком Просмотрите десять ошибок и для каждой из них отметьте, существует ли у вас сейчас соответствующий ранний признак. Три или более признаков в проекте, который ещё не запущен, являются поводом для кратковременной остановки и корректировки, а не для ускорения. Те же три признака в уже работающей системе оправдывают тщательную диагностику, прежде чем добавлять новые возможности поверх нестабильной основы. ### Вопросы и ответы **Какая ошибка при внедрении Salesforce является самой дорогостоящей в исправлении?** Ошибка в базовой модели данных. Изменение объекта, который определяет бизнес-процесс, после загрузки данных, создания автоматизаций и отчетов требует внутренней миграции, переписывания логики и повторной проверки прав доступа. Ошибки в пользовательском интерфейсе, напротив, обычно исправляются за несколько дней. **Действительно ли большое количество обязательных полей снижает уровень принятия системы пользователями?** Да, и это один из самых прямых механизмов. Каждое обязательное поле, не требуемое для принятия решения, создает дополнительное трение при заполнении каждой записи. Результатом являются неверные или фиктивные значения, вводимые для прохождения экрана, что впоследствии искажает те самые отчеты, ради которых поле было введено. Лучше сделать поле обязательным на более позднем этапе процесса, а не на этапе создания записи. **Когда обычно обнаруживается, что внедрение потерпело неудачу?** Обычно это происходит между вторым и четвертым месяцем после запуска, когда заканчивается усиленная поддержка. До этого момента пользователи получают активное сопровождение, а руководство видит активность в системе. Истинным признаком является постоянное снижение обновления записей в системе одновременно с ростом использования внешних файлов Excel. **Можно ли исправить проект Salesforce, который уже запущен, но имеет недостатки?** Почти всегда это возможно, но порядок действий отличается от нового проекта. Сначала стабилизируется то, что нарушает повседневную работу, затем очищаются данные, и только потом возвращаются к перепроектированию процессов. Попытка исправить все параллельно, пока система находится в использовании, обычно продлевает кризис. **Кто несет ответственность за предотвращение этих ошибок – организация или поставщик?** Большинство из них предотвращаются только в партнерстве. Поставщик может указать на архитектурный риск, но он не может решить, кто является владельцем процесса в организации, какая информация считается достоверной или кто уполномочен отказаться от требования. Проекты, которые терпят неудачу, почти всегда страдают от отсутствия организационного лица с полномочиями принимать решения, а не от отсутствия технических знаний. --- ## Услуги Salesforce: Как выбрать между проектированием, внедрением, Health Check и сопровождением CRM URL: https://hpi.pro/ru/insights/salesforce-services-guide Большинство компаний обращаются к поставщикам с запросом на «внедрение», даже когда их истинная потребность заключается в диагностике или сопровождении. Неправильный выбор типа услуги часто приводит к проектам, результаты которых не соответствуют ожиданиям. Мы предлагаем классификацию услуг в зависимости от симптомов: что заказывать в каждой ситуации, какой результат ожидать и на какие тревожные сигналы обращать внимание. ## Проблема начинается с запроса, а не с реализации. Когда организация обращается к поставщику Salesforce, первый запрос почти всегда звучит как «коммерческое предложение на внедрение». Во многих случаях это неверный запрос. Некоторые организации уже используют систему и нуждаются в диагностике; другие еще не определились с желаемым процессом; третьи имеют удовлетворительно работающую систему, но испытывают недостаток в постоянном сопровождении. Заказ неверного типа услуги приводит к проекту, результатом которого становится нерелевантный продукт, и зачастую это выясняется только после нескольких месяцев работы. Данное руководство соотносит четыре типа услуг с симптомами, побуждающими организацию искать помощи. ## Быстрое сопоставление по симптомам | Что вы говорите | Что, вероятно, требуется | Основной результат | | --- | --- | --- | | «Мы работаем в Excel и хотим навести порядок» | Анализ требований, затем поэтапное внедрение | Карта процессов, модель данных, первый этап в производстве | | «У нас есть Salesforce, но никто не пользуется» | Проверка состояния (Health Check) и план внедрения | Приоритизированный отчет с выводами и план исправлений | | «Система медленная и неисправная после многих лет» | Техническая диагностика и план по устранению технического долга | Картирование долга, рекомендация по рефакторингу или перестройке | | «Проект застопорился на полгода» | Спасение проекта | Оценка состояния, решение о дальнейших действиях, план стабилизации | | «Нужен кто-то для текущего обслуживания» | Сопровождение или управляемые услуги (Managed Services) | SLA, частота релизов, точка приема запросов | | «Генеральный директор хочет знать, подходит ли Salesforce» | Краткая консультация, не проект | Экспертное заключение и рекомендация по применимости | Этой таблицы достаточно для большинства случаев. Остальная часть статьи подробно описывает, что именно следует требовать от каждой услуги. ## Услуга 1: Консалтинг и анализ требований **Когда запрашивать:** Когда процесс, источник достоверных данных и границы проекта еще не ясны; или когда существуют внутренние разногласия между отделами. **Что обязательно должно быть в результате:** Карта процессов на уровне принятия решений, базовая модель данных, модель разрешений, карта систем, критерии приемки и базовые показатели. Результат, который не включает первые пять пунктов, является не анализом требований, а резюме встреч. **Типичный объем:** От двух до восьми недель, в зависимости от количества кросс-функциональных процессов. Подробно о том, что именно должно быть получено и как отличить хорошего консультанта, изложено в [руководстве по консалтингу Salesforce](/ru/insights/salesforce-consulting-guide). ## Услуга 2: Разработка и внедрение **Когда запрашивать:** Когда анализ требований завершен, владельцы процессов определены и принято решение о содержании первого этапа. **Что обязательно должно быть в соглашении:** Определение этапов, критерии приемки для каждого этапа, ответственность за миграцию данных, механизм запросов на изменения, гарантийный период и план передачи знаний. Отсутствие последних двух пунктов является частой причиной долгосрочной зависимости от поставщика. **Предупреждающий знак:** Предложение, детально описывающее количество часов разработки, но не уточняющее, что считается «завершенным». ## Услуга 3: Проверка состояния (Health Check) и диагностика **Когда запрашивать:** Когда система функционирует, но что-то не работает — низкий уровень внедрения, ненадежные данные, проблемы с производительностью или невозможность внесения изменений без нарушений. **Что обязательно должно быть в результате:** Список выявленных проблем с указанием серьезности, влияния на бизнес, усилий по исправлению и рекомендуемой последовательности. Отчет, перечисляющий пятьдесят проблем без их приоритизации, бесполезен; отчет, который гласит «сначала исправьте эти три, а बाकी пока не трогайте», является ценным продуктом. **Важное отличие:** Проверка состояния (Health Check) не является проектом по исправлению. Она предназначена для принятия решения о том, что и в какой последовательности исправлять. ## Услуга 4: Сопровождение, поддержка и управляемые услуги (Managed Services) **Когда запрашивать:** Когда система введена в эксплуатацию и отсутствует внутренняя команда, способная обеспечить текущее обслуживание. **Что обязательно должно быть определено:** Что включено, а что нет. Критическое различие проводится между устранением ошибки, небольшим изменением конфигурации и разработкой новой функциональности. Договор, объединяющий все три в «банк часов», как правило, исчерпывается в течение квартала, поскольку разработка новой функциональности поглощает часы, предназначенные для поддержки. **Дополнительно:** Время реакции в зависимости от серьезности, регулярные циклы выпусков и принадлежность документации. ## Правильное сочетание услуг Большинство организаций потребляют не одну услугу, а цепочку. Здоровая последовательность выглядит так: 1. Краткая консультация для принятия решения о применимости — дни, а не недели. 2. Целенаправленный анализ требований для первого этапа. 3. Поэтапное внедрение. 4. Определенный период стабилизации после запуска. 5. Текущее сопровождение. 6. Периодическая проверка состояния (Health Check), предпочтительно не тем, кто строил. Шестой пункт чаще всего пропускают, хотя он является наименее затратным. ## Пример для иллюстрации: Сеть бутик-отелей Этот сценарий является гипотетическим и предназначен для иллюстрации. Сеть из четырех отелей обратилась к трем поставщикам с запросом на коммерческое предложение по внедрению Salesforce для управления мероприятиями и запросами гостей. Первые два предложения представляли собой полномасштабное внедрение на многие месяцы. Третий поставщик задал один вопрос: кто определяет, что такое «событие» — менеджер по мероприятиям в каждом отеле или штаб-квартира. Ответ был, что общего определения нет. В такой ситуации полномасштабное внедрение привело бы к созданию четырех различных систем под одним названием. Вместо этого сеть заказала краткий анализ требований, получила одно согласованное определение и модель данных, и только затем приступила к внедрению — с меньшим объемом, чем было предложено изначально. ## Признаки, предупреждающие при заказе услуги * Предложение оценивает часы, но не определяет результат. * То же предложение включает анализ требований и внедрение одной суммой без контрольной точки, позволяющей остановиться. * Отсутствует определенный гарантийный период после сдачи. * Отсутствует пункт о передаче знаний и документации в собственность организации. * Поставщик отказывается предоставить архитектурное заключение до подписания. Инструменты для проверки самого поставщика — а не только услуги — собраны в [руководстве по выбору компании-интегратора Salesforce](/ru/insights/choose-salesforce-implementation-company). ## От запроса к документу После определения необходимой услуги следующим шагом является ее формулирование таким образом, чтобы полученные предложения были сопоставимы. Структура документа запроса и список вопросов, которые стоит включить, подробно изложены в [руководстве по RFP для внедрения Salesforce](/ru/insights/salesforce-rfp-guide), а пункты, которые должны войти в само соглашение, детализированы в [руководстве по контракту и SOW](/ru/insights/salesforce-sow-contract-clauses). ## Следующий шаг Прежде чем запрашивать коммерческое предложение, сформулируйте одним предложением симптом — а не решение. «У нас нет единой картины клиента между продажами и обслуживанием» приводит к иному запросу, чем «мы хотим Salesforce». Это предложение ценнее любого документа с требованиями, который будет написан после него. ### Вопросы и ответы **В чем разница между проектированием (Афиюн) и Discovery в предложениях поставщиков Salesforce?** У большинства поставщиков в России эти термины используются взаимозаменяемо, поэтому важно оценивать конечные результаты, а не только названия. Профессиональный Discovery завершается разработкой базовой модели данных, модели разрешений, карты систем и критериев приемки. Если в предложении обещаются «воркшопы по проектированию» без детализации измеримого результата, вы покупаете рабочие часы, а не документ. **Можно ли заказать только Health Check без обязательств по дальнейшему сотрудничеству?** Да, и это оптимальный подход. Health Check — это самостоятельная услуга, результатом которой является приоритетный отчет о выявленных проблемах. Если поставщик обусловливает проверку обязательством по последующему внедрению, возникает конфликт интересов: одна и та же сторона диагностирует и продает «лекарство». Желательно разделять диагностику и исправление, по крайней мере, в коммерческом плане. **Малая организация — нужен ли вообще внешний сервис или достаточно внутреннего администратора?** Внутренний администратор достаточен для текущего обслуживания, изменений конфигурации и поддержки. Однако его компетенций, как правило, недостаточно для принятия архитектурных решений: формирования базовой модели данных, модели доступа, определения границ между системами. Практическое правило: привлекайте внешнюю поддержку для принятия решений, которые впоследствии будет дорого менять, а остальное оставляйте внутри. **Что такое Managed Services для среды Salesforce?** Это модель, при которой внешний поставщик несет ответственность за текущее обслуживание, обработку запросов на изменения, периодические релизы и мониторинг в рамках согласованного объема часов. Она подходит компаниям, у которых нет собственной команды, но требует точного определения того, что включено: исправление ошибок и небольшие доработки — это совершенно разные вещи с точки зрения стоимости. **Можно ли заказать все услуги у одного поставщика?** Можно, и это распространенная практика, но целесообразно разделить хотя бы этап проектирования или периодическую проверку. Причина не в недоверии, а во встроенной предвзятости: поставщику, который внедрял систему, трудно диагностировать, что принятое им архитектурное решение было ошибочным. Второе мнение в критических точках обходится значительно дешевле, чем стоимость последующих исправлений. --- ## Консалтинг Salesforce: когда нужен консультант и что именно ждать от процесса URL: https://hpi.pro/ru/insights/salesforce-consulting-guide Консультант Salesforce нужен в тех случаях, когда ошибка может дорого обойтись – и далеко не по каждому техническому вопросу. В этой статье мы определяем пять "триггеров", оправдывающих привлечение внешнего консультанта, объясняем разницу между консультантом, архитектором и администратором, а также подробно описываем результаты, без которых вы просто потратите деньги на встречи, а не на решения. ## Когда внешний консалтинг выгоден, а когда является пустой тратой средств Консультант Salesforce необходим не для ответов на вопросы, которые можно найти в документации или получить у опытного администратора. Он нужен в тех случаях, когда цена ошибки высока, решение затрагивает несколько департаментов или в организации отсутствует нейтральная сторона, способная принять окончательное решение. Пять типичных ситуаций, оправдывающих привлечение внешнего консультанта: 1. **Решение о выборе платформы** — насколько Salesforce подходит в принципе и с какими альтернативами его следует сравнивать. 2. **Архитектурное решение, изменение которого дорого обойдётся** — например, базовая модель данных, выбор между одной или несколькими организациями Salesforce, единый источник истины. 3. **Внутренние разногласия между подразделениями**, для которых нет естественного арбитра. 4. **Зашедший в тупик проект**, где требуется политически незаинтересованная сторона для анализа ситуации. 5. **Ситуация перед крупными коммерческими обязательствами** — независимая экспертная оценка относительно недорога по сравнению с миллионными контрактами. Что не оправдывает консалтинг: добавление полей, построение отчётов, ежедневные операционные вопросы. Это задачи администратора, и любой консалтинг, направленный на решение таких задач, быстро превращается в дорогостоящее временное усиление кадров. ## Три роли, которые часто путают | Роль | На какой вопрос отвечает | Горизонт планирования | Что происходит при неправильном привлечении | | :-- | :---------------------- | :------------------ | :------------------------------------------- | | Консультант | Что правильно делать и в каком порядке | От месяцев до нескольких лет | Получаете стратегию вместо решения конкретной проблемы | | Архитектор | Как реализовать без накопления технического долга | Весь проект и система | Получаете детальный план для неопределённой проблемы | | Администратор | Как эксплуатировать и поддерживать ежедневно | Несколько недель | Получаете точечное решение, закрепляющее крупное архитектурное решение | Наиболее распространённой ошибкой является ситуация, когда архитектурное решение принимается администратором, поскольку изначально оно выглядело как небольшая задача. ## Что необходимо получить по итогам консалтингового процесса Консалтинговый процесс, завершающийся презентацией, не даёт конкретных указаний для действий. Рекомендуется требовать следующие письменные результаты до подписания договора: - **Документ с решениями** — для каждого решения: вопрос, рассмотренные альтернативы, рекомендация, обоснование и последствия в случае иного выбора. - **Допущения и зависимости** — что консультант принял за допущение без проверки, и что произойдёт, если допущение окажется ложным. - **Карта рисков**, адаптированная под конкретную организацию, а не общий список. - **Рекомендации по порядку действий** с учётом зависимостей, а не список пожеланий. - **Что не следует делать** — отрицательная рекомендация зачастую наиболее ценна и практически всегда отсутствует. Последний пункт является хорошим тестом качества: консультант, способный сказать «не стройте это сейчас», продаёт решение, а не часы своей работы. ## Как проверить консультанта перед привлечением Вопросы, которые стоит задать, касаются не сертификатов, а образа мышления: - Опишите архитектурное решение, которое вы рекомендовали, а затем пожалели. Чему это вас научило? - В каком случае вы бы рекомендовали не использовать Salesforce? - Как вы принимаете решение между конфигурированием и разработкой? - Что вы ожидаете от организации для успешного консалтинга, и что произойдёт, если вы этого не получите? - Кто в вашей компании продолжает поддерживать результат после вашего ухода? Более широкий набор вопросов для проверки поставщика можно найти в [руководстве по вопросам перед выбором интегратора](/ru/insights/questions-before-choosing-salesforce-integrator). ## Конфликт интересов — не всегда плохо, но всегда нужно знать Поставщик, который сначала консультирует, а затем реализует, не всегда проблематичен; иногда это наиболее эффективный способ, поскольку знания не теряются при передаче. Проблема возникает, когда рекомендация влияет на объём работы того же поставщика, а механизм балансирования отсутствует. Три простых механизма балансирования: - Отдельное ценообразование для этапа консалтинга, не обусловленное дальнейшим сотрудничеством. - Право организации провести тендер после этапа консалтинга, при этом результаты консалтинга находятся в её собственности. - Требование, чтобы каждая рекомендация была представлена с более дешёвой альтернативой и объяснением причины её отклонения. Последний механизм наиболее эффективен и приводит к самым продуктивным дискуссиям. ## Пример для наглядности: государственная инфраструктурная компания Сценарий гипотетический и предназначен для иллюстрации. Инфраструктурная компания рассматривала крупный проект CRM для управления обращениями граждан и органов власти. Два поставщика предложили архитектуру с отдельной организацией Salesforce для каждой из двух аудиторий, обосновывая это регуляторным разделением информации. Привлечённый внешний консультант изучил само регуляторное требование и обнаружил, что оно обязывает разделять доступ, но не системы. Вывод полностью изменил коммерческую картину: одна организация с тщательно проработанной моделью доступа вместо двух сред, требующих синхронизации и двойной поддержки. Наиболее ценным результатом консалтинга оказалась не рекомендация, что именно строить, а доказательство того, что исходное предположение двух предложений не было проверено. ## Как это связано с коммерческим решением Хорошая консалтинговая оценка меняет ваши запросы к поставщикам, поэтому она должна поступать до предложений, а не после них. Далее решение переходит в две плоскости: выбор модели ценообразования, соответствующей уровню оставшейся неопределённости, как подробно описано в [руководстве по моделям ценообразования проектов Salesforce](/ru/insights/salesforce-project-pricing-models), и сравнение полученных предложений, как подробно описано в [руководстве по сравнению предложений](/ru/insights/compare-salesforce-proposals). Критерии для проверки компании, которая будет выполнять фактическую работу, суммированы в [руководстве по выбору компании-внедренца](/ru/insights/choose-salesforce-implementation-company). ## Краткий тест перед обращением за консалтингом Ответьте на три вопроса: какое решение вам нужно принять, кто в организации его утвердит, и что произойдёт, если вы примете его неправильно. Если ответ на третий вопрос — «исправим позже дёшево», — вам, скорее всего, не нужен консультант. Если ответ — «будем строить заново», — это именно тот момент, когда внешний консалтинг окупает свои затраты. ### Вопросы и ответы **В чем разница между консультантом Salesforce и архитектором Salesforce?** Консультант занимается вопросом, что именно нужно сделать и в какой последовательности, включая коммерческие, организационные и бизнес-соображения. Архитектор отвечает на вопрос, как правильно реализовать это на платформе: модель данных, раскрытие, системные ограничения и техническая корректность. В небольших проектах один и тот же человек выполняет обе роли, но при принятии важных решений предпочтительно иметь два разных мнения. **Сколько времени должен занимать процесс консалтинга Salesforce?** Консалтинг для принятия решения о соответствии обычно измеряется в нескольких днях. Консалтинг, сопровождающий этап проектирования, измеряется в неделях. Консалтинг, который длится месяцами без конкретного решения, как правило, является не консалтингом, а усилением штата, и его следует оценивать и управлять им соответствующим образом. **Может ли внешний консультант работать с существующей внутренней командой Salesforce?** Да, и это, как правило, наиболее эффективная модель. Условием является четкое разделение полномочий: что консультант решает, что он только рекомендует, и кто в организации утверждает. Когда разделение не прописано, возникает напряжение, при котором внутренняя команда защищает то, что она построила, а консультант напрямую общается с руководством. **Что делать, если консультант рекомендует решение, против которого выступает внутренняя команда?** Требуйте, чтобы рекомендация была представлена с рассмотренными альтернативами и критериями принятия решения, а не как окончательный вывод. Возражение внутренней команды часто основано на контекстных знаниях, к которым консультант не имел доступа. Если после представления альтернатив все еще есть разногласия, это решение принимает сторона, несущая риски, а не та, кто профессионально прав. **Сколько стоит консалтинг Salesforce в России?** Цена зависит от объема часов, уровня старшинства и ответственности, которую консультант берет на себя за результат, и она сильно варьируется между поставщиками. Стоит сравнивать не почасовую ставку, а общую стоимость получения решения: более дорогой в час консалтинг, который завершается за две недели с документом решений, может быть дешевле, чем дешевый консалтинг, который длится два месяца. --- ## Готовность к Agentforce: Организационный чек-лист по данным, полномочиям и процессам URL: https://hpi.pro/ru/insights/agentforce-salesforce-ai-guide Прежде чем создавать первого агента, стоит ответить на более простой вопрос: насколько организация готова к этому. Данное руководство представляет проверку готовности по пяти ключевым направлениям — процесс, данные, знания, полномочия и эксплуатация — с оценкой для каждого направления, минимальным порогом для пилотного проекта и рекомендациями по устранению выявленных пробелов. ## Краткое резюме Проверка готовности к внедрению Agentforce занимает несколько недель; неудачный пилотный проект обходится в месяцы и подрывает внутреннее доверие. Поэтому стоит заранее ответить на пять вопросов: существует ли определенный процесс с назначенным владельцем; надежны ли данные, на которые будет опираться агент; поддерживается ли база знаний; понятна ли модель разрешений; и есть ли тот, кто будет управлять агентом после запуска. Проверка не является вопросом «да» или «нет». Она формирует оценку по каждой оси и карту пробелов, что позволяет принять более точное решение: начать, сократить объем или отложить и сначала устранить конкретный пробел. Рамки принятия решения о применимости сценария использования (Use Case) представлены в статье [Agentforce для предприятий](/ru/insights/agentforce-for-enterprises). ## Пять осей готовности | Ось | Решающий вопрос | Признак слабости | Минимальный порог для пилота | | --- | --- | --- | --- | | Процесс | Определен ли процесс и есть ли у него именной владелец? | Каждая команда выполняет по-разному, документации нет | Один документированный процесс с владельцем и известным объемом | | Данные | Надежны ли поля, которые будет считывать агент? | Пустые поля или заполненные свободным текстом | 90% полноты критически важных полей для процесса | | Знания | Существует ли утвержденный источник ответов? | Старые или противоречивые статьи | 20 актуальных статей для типовых сценариев | | Разрешения | Понятно ли, что каждый пользователь может видеть и делать? | Широкие и неконтролируемые разрешения | Сопоставление профилей и наборов разрешений (Permission Sets) для процесса | | Эксплуатация | Кто мониторит, исправляет и утверждает изменения? | Нет владельца после запуска | Владелец эксплуатации и еженедельный график обзора | ## Ось 1: Процесс Наиболее распространенная ошибка не является технологической. Организации выбирают процесс без владельца, и тогда некому принимать решения по вопросам, возникающим в ходе разработки: что происходит в исключительных случаях, когда нужна эскалация, что считается правильным ответом. Без таких решений техническая команда придумывает правила, а бизнес проверяет по другим ожиданиям. Практическая проверка: попросить четырех сотрудников, выполняющих процесс, описать его в письменном виде. Если получены четыре существенно различающиеся версии, процесс не готов к автоматизации с помощью агента – он готов к документированию и согласованию. Также важен объем. Процесс, выполняющийся десять раз в месяц, не оправдает затрат на разработку и поддержку, даже если он проблематичен. Хороший кандидат – это процесс со значительным объемом, высокой повторяемостью и изменчивостью формулировок запросов – именно там, где жесткие правила нарушаются. ## Ось 2: Данные Не требуется идеальное качество данных во всей Salesforce Org. Требуется качество полей, которые агент будет считывать или обновлять в выбранном процессе. Проверка узкая и измеримая: берется список релевантных полей и измеряется полнота, согласованность значений и дубликаты в связанных записях. Три теста, дающие быстрый ответ: процент заполненных критически важных полей, количество дублирующих записей в основном объекте и процент случаев, когда необходимая информация поступает из внешней системы, а не из Salesforce. Третий тест часто удивляет, выявляя зависимость от интеграции, которая не была бюджетирована. Свободный текст – особый красный флаг. Когда существенная информация хранится в поле для примечаний, агенту придется ее выводить, и именно здесь возникают труднообнаружимые ошибки. Рекомендуемый порядок устранения пробелов в данных подробно описан в статье [Показатели качества данных в Salesforce](/ru/insights/salesforce-data-quality-metrics). ## Ось 3: Знания Знания оцениваются не по количеству, а по охвату и актуальности. Берутся двадцать наиболее частых запросов и для каждого проверяется: есть ли утвержденная статья, когда она обновлялась и кто является ее владельцем. Охват половины сценариев актуальными статьями предпочтительнее полного охвата устаревшими статьями. Легко упускаемый признак слабости: статьи, написанные только для внутреннего пользования, но одновременно используемые для ответов клиентам. Они могут содержать формулировки, цены или исключения, которые нельзя раскрывать внешне, и разделение должно быть сделано до подключения. ## Ось 4: Разрешения Агент действует от имени пользователя, поэтому существующая модель разрешений становится моделью безопасности ИИ. Если разрешения сегодня широкие и неконтролируемые, агент увеличит потенциальные риски, а не создаст их. Проверка анализирует три аспекта: кто имеет право читать данные в процессе, какие операции записи необходимы и кто утверждает конфиденциальную операцию. Для каждой операции, которую будет выполнять агент, необходимо определить, является ли она обратимой. Необратимая операция – кредитование средств, закрытие дела, отправка сообщения клиенту – требует точки подтверждения человеком на начальном этапе, поэтому она влияет на планирование процесса, а не только на настройки. Планирование точек утверждения по риску подробно изложено в статье [Human-in-the-Loop в Agentforce](/ru/insights/agentforce-human-in-the-loop). ## Ось 5: Эксплуатация Агент — это не проект с датой завершения. Это компонент, требующий мониторинга трассировок, обработки сбоев, обновления контента и контроля затрат. Организация, у которой нет того, кто будет это делать — хотя бы на частичную занятость, — увидит постепенное снижение качества в течение квартала. Минимум: именной владелец эксплуатации, еженедельный график обзора неудачных взаимодействий, согласованный процесс изменения для обновления инструкций и контролируемый ежемесячный бюджет. Если ни один из этих четырех элементов отсутствует, пробел по этой оси больше, чем кажется на первый взгляд. ## Преобразование оценки в решение | Состояние | Интерпретация | Рекомендуемое действие | | --- | --- | --- | | Все оси выше порогового значения | Полная готовность | Пилотный проект по одному процессу с критериями Go/No-Go | | Слабость только в эксплуатации | Можно компенсировать поддержкой | Пилотный проект с внешней поддержкой и параллельным развитием внутренних компетенций | | Слабость только в знаниях | Целенаправленный пробел в контенте | Четыре-шесть недель обучения знаниям, затем пилотный проект | | Слабость в данных или разрешениях | Существенный риск | Не начинать с агента; устранить пробел как отдельный проект | | Слабость в трех и более осях | Организация не готова | Выбрать более узкий подпроцесс и перепроверить | ## Сценарий: Финансовая организация, обнаружившая, что выбран неверный процесс Финансовая организация запросила агента для обработки запросов на изменение данных клиента. В ходе проверки готовности выяснилось, что процесс проходит через две внешние системы, каждое изменение требует регуляторного одобрения, а ежемесячный объем скромен. Оси разрешений и данных получили низкую оценку. В ходе той же проверки обнаружился другой процесс, о котором никто не задумывался: ответы на запросы о статусе существующих заявок. Он опирался на одно надежное поле в Salesforce, не включал операции записи, а его объем был в восемь раз выше. Пилотный проект был переведен на этот процесс. Практическим результатом проверки было не «готовы или не готовы», а замена кандидата. Это главное преимущество проверки готовности – она достаточно дешева, чтобы провести ее для трех кандидатов и выбрать того, у кого наименьшее количество зависимостей. ## Чек-лист готовности - ☐ Выбран один процесс-кандидат с назначенным владельцем - ☐ Измерены ежемесячный объем и частота повторений - ☐ Проверена полнота критически важных полей для процесса - ☐ Проверены дубликаты в основном объекте - ☐ Выявлены зависимости от внешних систем - ☐ Составлено покрытие базы знаний для двадцати наиболее частых запросов - ☐ Разделен внутренний контент от контента, разрешенного для клиента - ☐ Составлены разрешения на чтение и запись для процесса - ☐ Классифицированы обратимые и необратимые операции - ☐ Определен владелец эксплуатации и график обзора после запуска В случае необходимости внешней экспертизы для проведения проверки и разработки Roadmap, услуга [Agentforce и ИИ](/ru/agentforce-ai) является практическим путем для дальнейших действий. ### Вопросы и ответы **Сколько времени занимает серьёзная проверка готовности?** В средней организации это занимает от двух до четырех недель. Первая неделя посвящена картированию целевого процесса и интервью, вторая – сбору образцов данных и знаний, третья – проверке полномочий и формулированию пробелов. Более месяца обычно означает, что для проверки был выбран слишком широкий охват (Scope). **Можно ли начать пилотный проект со средним баллом готовности?** Да, при условии, что выявленные пробелы не относятся к данным или полномочиям. Недостатки в эксплуатационной сфере могут быть компенсированы тесной поддержкой в первые месяцы, но неактуальная база знаний или неясная модель полномочий обрекут пилотный проект на провал, независимо от качества реализации. **Кто должен руководить проверкой готовности – ИТ-отдел или бизнес?** Владелец бизнес-процесса должен руководить, поскольку именно он будет нести ответственность за результат. ИТ-отдел и отдел информационной безопасности предоставляют блоки по данным и полномочиям. Проверка, инициированная только ИТ-отделом, имеет тенденцию фокусироваться на возможностях платформы, а не на том, допустима ли сама автоматизация процесса. **Что делать, если проверка покажет, что организация не готова?** Преобразуйте каждый пробел в элемент дорожной карты с назначенным ответственным и сроком выполнения, а затем выберите альтернативный процесс-кандидат, требующий меньшего числа зависимостей. В большинстве случаев существует один узкий подпроцесс, который соответствует пороговым значениям, и он становится пилотным проектом, пока крупные пробелы устраняются параллельно. **Нужно ли приобретать лицензии Agentforce до проверки?** Нет. Проверка готовности касается процесса, данных и полномочий — всё это существует независимо от лицензирования. Приобретение до того, как станет ясно, какой сценарий использования является зрелым, приводит к неиспользуемым лицензиям и необходимости слишком быстро демонстрировать результаты. --- ## Salesforce Health Check: что исследуем, когда и какие результаты получаем URL: https://hpi.pro/ru/insights/salesforce-health-check-guide Health Check – это не опрос общественного мнения о системе, а диагностика, основанная на фактах: метаданных, логах, данных об использовании и наблюдении за реальными пользователями. Руководство подробно описывает семь направлений проверки, методологию оценки критичности и структуру конечного отчета, на основе которого можно принимать бюджетные решения. ## Краткий ответ Health Check — это двух-шестинедельная диагностика на основе фактических данных, результатом которой являются три документа: перечень обнаруженных проблем, ранжированных по критичности; 30-дневный план быстрых побед; и дорожная карта для глубоких инвестиций. Его ценность заключается не в широте охвата, а в доказательствах, прилагаемых к каждой проблеме — числовых данных, скриншотах или видеозаписях, — поскольку без них обсуждение превращается в спор мнений. ## Семь осей проверки | Ось | Что фактически проверяется | Источник доказательств | | --- | --- | --- | | Процессы и их соблюдение | Соответствие документированного процесса фактическому исполнению | Login History, использование полей, наблюдение за пользователями | | Модель данных | Избыточные объекты, неиспользуемые поля, дублирующиеся связи | Field Usage, Metadata API, выборочные запросы | | Автоматизации | Пересечение Flow, Triggers и устаревшего Process Builder | Metadata, Debug Logs, анализ порядка выполнения | | Разрешения и безопасность | Раздутые профили, противоречивые Sharing Rules, избыточный доступ | Security Health Check, Permission Set Assignments | | Интеграции | API Limits, повторяющиеся сбои, обработка ошибок | Event Monitoring, логи Middleware | | Производительность | Время загрузки, тяжелые запросы, зависающие Batch-процессы | Lightning Usage App, Apex Jobs | | Стоимость и лицензирование | Неиспользуемые лицензии, Storage, дублирующиеся сервисы | Отчет о лицензиях, счет-фактура против фактического использования | ## Как оценивается критичность Произвольная оценка критичности обесценивает отчет. Эффективный метод: каждая проблема получает две оценки от 1 до 5 — влияние (что произойдет с бизнесом, если проблема не будет решена) и частота (сколько раз в месяц проблема проявляется). Приоритет определяется произведением этих оценок, а не оценкой «некрасивости» кода. Проблема с оценкой 20 и более требует немедленного решения; 12–19 — включается в план на ближайший квартал; ниже 12 — фиксируется, но не решается, если только ее устранение не является недорогим в рамках других работ. Наиболее важное разделение в отчете — между симптомом и первопричиной. «Пользователи не заполняют поле причины потери сделки» — это симптом; первопричиной может быть то, что поле не является обязательным, значения нерелевантны для отрасли, или никто не анализирует отчеты, основанные на этом поле. Коррекция только симптома — делая поле обязательным — приводит к появлению некорректных данных вместо отсутствующих. ## Что получаем в итоге Качественный результат включает документ с проблемами, содержащий доказательства для каждой строки, матрицу критичности, 30-дневный план, каждый пункт которого реализуем без архитектурных изменений, и дорожную карту на один-два квартала с примерными оценками трудозатрат. Дополнительно необходим Decision Log из трех-пяти решений, которые организация должна принять — например, объединять ли два бизнес-подразделения в один Org, — поскольку без них дорожная карта остается неподтвержденной. Более подробная информация о решении после диагностики представлена в статьях [Перестройка против рефакторинга](/ru/insights/salesforce-rebuild-vs-refactor) и [Приоритизация технического долга](/ru/insights/salesforce-technical-debt-prioritization). ## Распространенные риски и профилактические меры Первый риск — это восприятие отчета как списка обвинений. Если проблемы сформулированы как критика внутренней команды, организация переходит к обороне вместо решения. Правильная формулировка фокусируется на текущем состоянии и дальнейших затратах, а не на исторической ответственности. Второй риск — проверка, заканчивающаяся без ответственных лиц. Каждая проблема должна быть связана с конкретным человеком и сроком, иначе отчет присоединится к папке, которую никто не откроет. Третий риск — чрезмерная широта: диагностика, пытающаяся охватить семь осей с полной глубиной за две недели, приводит к поверхностной картине по всем направлениям. Лучше выбрать три оси для глубокого анализа, а остальные наметить на следующий этап. ## Как измеряется успех Health Check считается успешным, если в течение 60 дней выполнено не менее 70% пунктов 30-дневного плана, если руководство утвердило бюджет хотя бы для одной глубокой инвестиции, и если два операционных показателя — например, процент сбоев интеграции или время загрузки центрального экрана — измеримо улучшились по сравнению с базовым уровнем, установленным в начале диагностики. ## Следующий шаг Перед заказом диагностики рекомендуется подготовить три вещи: список критически важных бизнес-процессов, доступ для чтения логов и метаданных, а также имена трех реальных пользователей, за работой которых можно наблюдать. Эти три пункта сокращают время диагностики примерно на неделю и значительно повышают качество обнаруженных проблем. ### Вопросы и ответы **Сколько времени занимает Health Check?** Для средней организации с одной Org-единицей: от двух до трех недель, из которых около недели уходит на сбор доказательств и наблюдение, и неделя на анализ и составление отчета. Организация с несколькими бизнес-подразделениями и десятками интеграций потребует от четырех до шести недель. Свыше этого – это уже не диагностика, а полноценный проект. **Нужно ли предоставлять полный административный доступ сторонней организации?** Нет. Для большинства проверок достаточно прав View Setup and Configuration, ограниченного доступа View All Data и прав на чтение логов. Если есть конфиденциальные данные, работа проводится в обновленной Sandbox-среде, а в Production-среде проверяются только те метрики, которые невозможно воспроизвести. **В чем разница между Health Check и встроенным инструментом Security Health Check?** Инструмент Salesforce проверяет настройки безопасности на соответствие базовым требованиям и присваивает балл. Полная диагностика также охватывает процессы, модель данных, автоматизацию, интеграции, уровень внедрения и общую стоимость, при этом встроенный инструмент является лишь одним из источников данных для нее. **Что делать с результатом, требующим кардинальной переработки?** Такой результат не включается в план быстрых побед (Quick Wins). Его следует обозначить как отдельное инвестиционное решение с оценкой трудозатрат, рисков бездействия и целевой датой для повторного рассмотрения, продвигая его отдельно от основных действий по устранению срочных проблем. **Оправдывает ли себя Health Check, если система работает без сбоев?** Да, в двух случаях: перед принятием крупного инвестиционного решения, чтобы понимать, на чем строится система; и после двух-трех лет накопительных изменений, когда никто уже не имеет полного представления об автоматизации и разрешениях. --- ## Trademark Disclosure Salesforce® and Agentforce® are trademarks of Salesforce, Inc. HPI Pro is an independent consultancy and does not present itself as an official Salesforce partner unless explicitly stated on the site.