Краткий ответ
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, — поскольку без них дорожная карта остается неподтвержденной.
Более подробная информация о решении после диагностики представлена в статьях Перестройка против рефакторинга и Приоритизация технического долга.
Распространенные риски и профилактические меры
Первый риск — это восприятие отчета как списка обвинений. Если проблемы сформулированы как критика внутренней команды, организация переходит к обороне вместо решения. Правильная формулировка фокусируется на текущем состоянии и дальнейших затратах, а не на исторической ответственности.
Второй риск — проверка, заканчивающаяся без ответственных лиц. Каждая проблема должна быть связана с конкретным человеком и сроком, иначе отчет присоединится к папке, которую никто не откроет. Третий риск — чрезмерная широта: диагностика, пытающаяся охватить семь осей с полной глубиной за две недели, приводит к поверхностной картине по всем направлениям. Лучше выбрать три оси для глубокого анализа, а остальные наметить на следующий этап.
Как измеряется успех
Health Check считается успешным, если в течение 60 дней выполнено не менее 70% пунктов 30-дневного плана, если руководство утвердило бюджет хотя бы для одной глубокой инвестиции, и если два операционных показателя — например, процент сбоев интеграции или время загрузки центрального экрана — измеримо улучшились по сравнению с базовым уровнем, установленным в начале диагностики.
Следующий шаг
Перед заказом диагностики рекомендуется подготовить три вещи: список критически важных бизнес-процессов, доступ для чтения логов и метаданных, а также имена трех реальных пользователей, за работой которых можно наблюдать. Эти три пункта сокращают время диагностики примерно на неделю и значительно повышают качество обнаруженных проблем.