Проверка дизайна для соответствующих изменений
Каждое изменение, влияющее на модель данных, разрешения или интеграцию, проходит профессиональную проверку перед реализацией. Этот шаг позволяет избежать большей части переделок.
Поддержка и непрерывное улучшение
Salesforce не останавливается в день запуска.
Организация, пользователи и процессы продолжают развиваться. Наша модель постоянного обслуживания позволяет поддерживать, улучшать и расширять систему документированным, приоритетным и измеримым образом, не накапливая нового технического долга.
Операционный цикл управления
Операционный цикл, а не список запросов
Разница между поддержкой, которая тушит пожары, и обслуживанием, которое создает ценность, заключается в замкнутом цикле: каждый запрос измеряется, приоритизируется, выполняется и проверяется, а результат питает следующий цикл.
Операционный цикл управления
- 01
Прием
Единый канал запросов с классификацией, ответственным и видимым статусом.
- 02
Приоритизация
Совместная классификация по бизнес-влиянию, риску и усилиям.
- 03
Разработка и тестирование
Разрабатывается в песочнице, тестируется на приемлемость и развертывается контролируемым образом.
- 04
Измерение и обучение
Отчет об активности, метрики внедрения и обзор исключений.
↻ Цикл повторяется: каждая итерация определяет приоритеты следующей
Область ответственности
Что может включать постоянное обслуживание
- Управление инцидентами
- Поддержка пользователей
- Изменения и корректировки
- Flows и автоматизация
- Разработка Apex и LWC
- Отчеты и дашборды
- Управление разрешениями
- Качество данных
- Мониторинг интеграций
- Управление релизами
- Управление бэклогом
- Обучение и повышение квалификации
- Управление и обзор дизайна
- Квартальная дорожная карта
- Снижение технического долга
- Подготовка к релизам Salesforce
Модели
Выбирайте в соответствии с потребностью, а не с пакетом
| Модель | Когда это применимо | Что вы получаете | Ограничение, которое следует учитывать |
|---|---|---|---|
| Банк часов | Небольшие и переменные потребности | Полная гибкость в выборе задач | Менее подходит для долгосрочного планирования |
| Ежемесячный фиксированный тариф | Постоянный поток улучшений и поддержки | Известная мощность и ежемесячная приоритизация | Требует дисциплины приоритизации со стороны клиента |
| Команда непрерывной поставки | Центральная система с широким использованием | Поддержка, разработка и обслуживание под единым управлением | Более широкие обязательства |
| Архитектор на неполный рабочий день | Внутренняя команда существует, но нет старшего технического руководителя | Проверка дизайна, управление и контроль технического долга | Не заменяет возможности поставки |
| Ограниченный проект улучшения | Определенная цель с началом и концом | Четкий объем и результаты | Не покрывает постоянную поддержку |
Банк часов
- Когда это применимо
- Небольшие и переменные потребности
- Что вы получаете
- Полная гибкость в выборе задач
- Ограничение, которое следует учитывать
- Менее подходит для долгосрочного планирования
Ежемесячный фиксированный тариф
- Когда это применимо
- Постоянный поток улучшений и поддержки
- Что вы получаете
- Известная мощность и ежемесячная приоритизация
- Ограничение, которое следует учитывать
- Требует дисциплины приоритизации со стороны клиента
Команда непрерывной поставки
- Когда это применимо
- Центральная система с широким использованием
- Что вы получаете
- Поддержка, разработка и обслуживание под единым управлением
- Ограничение, которое следует учитывать
- Более широкие обязательства
Архитектор на неполный рабочий день
- Когда это применимо
- Внутренняя команда существует, но нет старшего технического руководителя
- Что вы получаете
- Проверка дизайна, управление и контроль технического долга
- Ограничение, которое следует учитывать
- Не заменяет возможности поставки
Ограниченный проект улучшения
- Когда это применимо
- Определенная цель с началом и концом
- Что вы получаете
- Четкий объем и результаты
- Ограничение, которое следует учитывать
- Не покрывает постоянную поддержку
Условия ценообразования и SLA обсуждаются по телефону и не публикуются на сайте.
Управление
Четыре механизма, которые поддерживают здоровье системы в долгосрочной перспективе
Контроль технического долга
Дублирующиеся автоматизации, неиспользуемые поля и слишком широкие разрешения измеряются и управляются как реальные элементы бэклога, с выделенной мощностью.
Подготовка к релизам
Salesforce выпускает три релиза в год. Мы заранее рассматриваем, что меняется, что может вызвать проблемы и что стоит принять.
Измерение внедрения
Метрики использования по ролям показывают, где процесс действительно не работает, прежде чем данные отчетов станут ненадежными.
Продолжать отсюда
Связанные услуги и руководства
- Проверка работоспособности Salesforce
- Внедрение и обучение
- Спасение проектов Salesforce
- Разработка и автоматизация
- Руководство: план гиперподдержки после запуска
- Руководство: приоритезация технического долга в Salesforce
- Руководство: стратегия песочницы и DevOps
- Руководство: метрики внедрения пользователями
Часто задаваемые вопросы
Поддержка и постоянное обслуживание — частые вопросы
В чем разница между поддержкой и постоянным обслуживанием?
Поддержка обрабатывает инциденты и вопросы пользователей, восстанавливая систему до рабочего состояния. Постоянное обслуживание также задается вопросом, что нужно изменить: приоритезация улучшений, контроль технического долга, пересмотр более сложных изменений в дизайне и поддержание дорожной карты с долгосрочным видением. Организация, которая покупает только поддержку, получает систему, которая работает, но никогда не улучшается.
Что считается срочным инцидентом?
Событие, блокирующее бизнес-процесс для группы пользователей без разумной альтернативы: сбой в захвате лидов, ключевая автоматизация перестает работать или нарушается интеграция. Запрос на новое поле или новый отчет не является инцидентом, каким бы важным он ни был. Это различие согласовывается в письменной форме заранее.
Каждое изменение проходит через тестовую среду?
Да. Каждое соответствующее изменение разрабатывается в песочнице, тестируется по бизнес-сценарию и только затем развертывается в рабочую среду в определенное временное окно. Единственное исключение — исправление блокирующего инцидента, и даже в этом случае оно документируется и повторно включается в стандартный цикл в следующем раунде.
Как определяется приоритет?
По влиянию на бизнес, количеству затронутых пользователей, риску и затратам, во время периодического совещания по приоритезации с ответственным за процесс со стороны клиента. Мы не приоритизируем в одиночку, так как приоритизация — это бизнес-решение, а не техническое.
Что происходит с техническим долгом, накопленным до начала работы?
В начале проекта мы картируем дублирующиеся автоматизации, неиспользуемые поля, непроверенный код и слишком широкие разрешения. Находки включаются в приоритезированный список, и фиксированная часть ежемесячной мощности выделяется для уменьшения этого долга; в противном случае он только увеличивается.
Можем ли мы начать постоянное обслуживание, даже если вы не внедряли систему?
Да, и это частый случай. В этой ситуации мы начинаем с краткого обзора системы, который отображает текущее состояние, так что проект основывается на знаниях, а не на предположениях.
Следующий шаг
Рассмотреть модель поддержки
Мы проанализируем объем использования, открытые потребности и необходимый уровень управления, а также предложим модель, соответствующую вашему темпу.