Архитектура CRM
Архитектура Salesforce и CRM, поддерживающая
организацию через два года.
Полное архитектурное планирование — решение, данные, безопасность, автоматизация, интеграция и среда — для того, чтобы система работала сегодня и могла продолжать расти.
Кому подходит услуга
Когда стоит пригласить архитектора Salesforce
- Организации, планирующие первое внедрение Salesforce.
- Существующие системы, потерявшие порядок и четкую архитектуру.
- Организации, планирующие глубокие интеграции с ERP, финансовыми или BI системами.
- CRM-команды, желающие сократить технический долг перед новой фазой.
Проблемы, которые решает услуга
Признаки потери архитектуры системой
Накопленные поля без модели
Через два-три года каждый отдел добавлял свои поля. Результат: объекты с более чем 300 полями, ненадежные отчеты и сбои автоматизации. Архитектура определяет владение, правила добавления и жизненный цикл для каждого поля.
Автоматизации, противоречащие друг другу
Flow, Process Builder и Trigger, выполняющиеся параллельно при одном и том же событии. Мы объединяем их в один уровень автоматизации с предсказуемым порядком выполнения.
Разрешения, ставшие дырой в безопасности
Профили, созданные «временно» два года назад и оставшиеся открытыми. Мы строим модель, основанную на наборах разрешений (Permission Sets) и фактических ролях.
Интеграции без владельца
Когда кто-то уходит, никто не знает, как они работают. Архитектура включает документацию, логи и четкую ответственность за каждое подключение.
Уровни
Уровни архитектуры, которые мы спроектируем
Solution Architecture
Соответствие между основными бизнес-процессами организации и продуктами Salesforce, включая приоритизацию того, что войдет в первую версию, а что — в последующие этапы.
Data Architecture
Модель объектов и связей, источники истины, правила качества данных и план очистки и объединения существующих записей.
Security & Sharing
Профили, роли, публичные группы, модель общего доступа, защищенные поля и политика доступа к конфиденциальной информации.
Automation Architecture
Осознанный выбор между Flow, Apex и асинхронными автоматизациями, с предотвращением параллельных автоматизаций для одного и того же события.
Integration Architecture
Направления потока, методы (REST, Events, Middleware), обработка ошибок и логи для критически важных бизнес-интеграций.
Environment & Release
Структура Sandboxes, методология развертываний, резервное копирование, управление версиями и текущие операции по обслуживанию.
Принципы работы
Принципы, которыми руководствуется каждое решение
- Конфигурация важнее кода — индивидуальная разработка только в случае отсутствия более простого пути.
- Каждое архитектурное изменение документируется и утверждается.
- Простая и понятная модель разрешений, даже ценой меньшей гибкости.
- Нет двух автоматизаций, запускаемых одновременно на одном и том же событии.
- Каждая интеграция включает журнал, обработку ошибок и четкую область ответственности.
- Новое развертывание проходит через Sandbox перед Production.
Environments
Рекомендуемая структура сред
Developer
Для повседневной разработки без реальных данных.
Integration / QA
Для тестирования системы и тестирования интеграции между компонентами.
UAT
Копия с данными, похожими на производственные, для приемочного тестирования с пользователями.
Staging / Pre-Prod
Среда для репетиций перед Go Live и исправлений Hotfix.
Production
Производственная среда, только с упорядоченным процессом развертывания.
Точка принятия решения
Представьте вашу архитектуру на проверку
Короткий разговор помогает понять, требуется ли новое архитектурное планирование или точечный Refactor критических компонентов.
Критерии принятия решения
Четыре решения, определяющие стабильность системы
Multi-Org или Single-Org
Когда разделение на отдельную организацию предпочтительнее умного использования Record Types и Sharing? Это решение имеет долгосрочные последствия.
Master Data Management
Является ли Salesforce источником достоверной информации о клиентах, или правда хранится в ERP? Ответ определяет направление потока каждой интеграции.
Стратегия автоматизации
Когда Flow, когда Apex, когда Platform Events. Неправильный выбор создает систему, которую сложно поддерживать.
Политика настроенных полей
Кто имеет право добавлять поле и по какой процедуре. Без такой политики любая система за год наполняется ненужными полями.
Что вы получите
Возможные результаты услуг
Архитектурный документ
Solution + Data + Security + Integrations, с уровнем детализации, позволяющим разработку.
Карта интеграций
Направления потоков, техника, тип события и сценарии сбоев для каждого существенного соединения.
Модель данных
Объекты, отношения, ключевые поля и начальные правила качества.
Модель разрешений
Профили, роли и политика совместного использования, соответствующая организационной структуре.
Распространенные ошибки
Шаблоны, которых следует избегать
- Предоставлять каждому отделу свою модель данных без сквозного видения организации.
- Создавать автоматизации в Flow и коде одновременно для одного и того же события.
- Развертывать непосредственно в Production, минуя Sandbox.
- Оставлять “временные” профили со всеми правами на изменение данных (All Modify Data) и не возвращаться к ним.
- Разрабатывать одноточечную интеграцию без ее документирования — она превращается в черный ящик за несколько месяцев.
Руководства и сопутствующие услуги
Углубитесь в центр знаний
- Руководство: Архитектура CRM — как спроектировать систему, которая сможет расти →
- Руководство: Внедрение Salesforce — этапы, решения и риски →
- Руководство: Salesforce Health Check — что проверять и когда это делать →
- Услуга: Консультации и разработка спецификаций Salesforce →
- Услуга: Интеграции и миграция данных →
Часто задаваемые вопросы
Архитектура CRM — часто задаваемые вопросы
Следующий шаг