Перейти к содержанию
HPI — High Tech Professions Institute

Salesforce Health Check

Система уже существует.
Вопрос в том, правильно ли она все еще построена.

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

4. Признаки того, что следует провести проверку работоспособности (Health Check)

5. Когда проверка окупается

  • 6. Пользователи работают вне системы.
  • 7. Трудно генерировать надежные отчеты.
  • 8. Небольшие изменения вызывают сбои.
  • 9. Существуют Flows или код без четкого владельца.
  • 10. Разрешения накапливались со временем.
  • 11. Дублирующиеся или отсутствующие данные.
  • 12. Интеграции не работают.
  • 13. Снизилось время загрузки или производительность.
  • 14. Затраты растут без улучшения ценности.
  • 15. Отсутствует структурированная дорожная карта (Roadmap).
  • 16. Никто не уверен, что можно удалить или изменить.
  • 17. Различные команды используют систему по-разному.

Проблемы, которые решает услуга

Когда проверка меняет картину

Неопределенность перед новым проектом

Перед фазой, интеграцией или переходом на Agentforce, Health Check отвечает на вопрос: Достаточно ли стабилен фундамент? Если нет, что нужно исправить в первую очередь?

Технический долг, который тихо накапливался

Дублирующиеся Flows, старый код, заброшенные поля и открытые профили. Проверка выявляет долг, приоритизирует его и предлагает поэтапный план исправления.

Низкое внедрение среди пользователей

Когда система существует, но никто ею на самом деле не пользуется. Проверка включает в себя интервью с пользователями и анализ фактического использования.

Неясные затраты на лицензии

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

18. Что проверяется

19. Восемь областей проверки

Архитектура

20. Модель данных, Objects, Relationships, Scalability, Technical Debt.

21. Автоматизации и код

22. Flows, Apex, Triggers, LWC, зависимости, ошибки и ремонтопригодность.

23. Разрешения и безопасность

24. Profiles, Permission Sets, Sharing, Roles, доступ к конфиденциальной информации, избыточные разрешения.

25. Данные

26. Дублирования, пустые поля, структура данных, качество информации, источники истины и политика хранения.

27. Удобство использования и внедрение

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

29. Отчеты и показатели

30. Надежность отчетов, KPIs, Dashboards и согласованность между отделами.

Интеграции

31. Сбои, Monitoring, Retry, Ownership, безопасность и API Limits.

32. Лицензии и затраты

33. Использование лицензий, неактивные пользователи, приобретенные и неиспользуемые возможности.

Рабочий процесс

Семь систематизированных шагов

  1. 01Запуск и доступ к среде
  2. 02Автоматическое сканирование метаданных
  3. 03Интервью с должностными лицами
  4. 04Анализ фактического использования
  5. 05Проверка интеграций и логов
  6. 06Написание отчета и рекомендаций
  7. 07Презентация для руководства

10. Что получаем

34. Четкие результаты для принятия решений

Executive Summary

35. Управленческое резюме для принятия решений.

36. Отчет о ранжированных выводах

37. По степени серьезности, влияния и усилий.

Quick Wins

38. Улучшения, быстро приносящие ценность.

39. Ключевые риски

40. Пробелы, требующие предварительного устранения.

41. Рекомендации по архитектуре

42. Направления для структурного улучшения системы.

43. Дорожная карта (Roadmap) для улучшения

44. Разделение на этапы и приоритизация.

Точка принятия решения

Краткая проверка соответствия перед заказом полного Health Check

В коротком разговоре мы определим, что лучше: Express Health Check, Deep-Dive или сопровождение в принятии индивидуального решения.

Критерии принятия решения

Три решения, определяющие ценность проверки

Глубина проверки

Express за одну неделю для общего обзора, в сравнении с Deep-Dive за четыре недели, включающим анализ кода и архитектуры. Выбор зависит от размера системы и открытых вопросов.

Когда выполнять Health Check

Перед новой фазой, перед переходом на Agentforce, после смены поставщика или при длительно низких показателях внедрения.

Кто реализует исправления

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

Распространенные ошибки

Что важно учитывать при проверке

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

Часто задаваемые вопросы

Salesforce Health Check — Часто задаваемые вопросы

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

Следующий шаг

Не обязательно перестраивать.
Иногда нужно понять, что стоит сохранить, а что изменить.