Перейти к содержимому
HPI Pro — Salesforce consulting and implementation
Язык

Методология

Метод реализации с «контрольными точками», чтобы проблемы не возникали, когда их уже дорого решать.

Восемь фаз, каждая со своей целью, результатами и явным условием выхода. Метод адаптируется к проекту, но ни одна фаза не игнорируется незаметно.

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

От обнаружения до стабилизации, с «контрольной точкой» между каждой фазой

«Контрольные точки» — это то, что превращает методологию из списка фаз в систему контроля. Каждая «контрольная точка» требует явного утверждения со стороны бизнеса, а не только технического OK.

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

  1. 01

    Обнаружение и понимание процессов

    Понять, что должно измениться в повседневной работе и кого это затронет.

    Интервью с владельцами процессов и пользователями, картирование текущего состояния, определение источников данных и подключенных систем, определение измеримых целей.

    Контрольная точка: Утвержденный документ об обнаружении с целями, пользователями и процессами, включенными в объем работ.

  2. 02

    Архитектура и модель данных

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

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

    Контрольная точка: Модель данных и разрешений, письменно утвержденная владельцами процессов и ИТ-отделом.

  3. 03

    Проектирование решения и объем работ

    Преобразовать результаты обнаружения в согласованный бэклог с критериями приемки.

    Детализация возможностей, пользовательские истории, определение минимально жизнеспособного продукта (MVP), приоритизация и идентификация рисков и зависимостей.

    Контрольная точка: Утвержденный объем работ с критериями приемки и механизмом контроля изменений.

  4. 04

    Разработка циклами

    Создавать и демонстрировать работающее программное обеспечение, а не слайды.

    Конфигурация, Flow или Apex на основе обоснованного решения, пользовательские интерфейсы, демонстрация в конце каждого цикла.

    Контрольная точка: Утвержденная демонстрация по циклу с перечнем устраненных недостатков.

  5. 05

    Данные и миграция

    Передача данных, которым люди могут доверять.

    Профилирование, правила очистки, картирование, идентификационные ключи, тестовая загрузка и сверка.

    Контрольная точка: Выполненная тестовая загрузка, прошедшая полную сверку с источником, с утвержденными расхождениями.

  6. 06

    Приемочное тестирование

    Проверить, что процесс работает в руках тех, кто будет его выполнять.

    Сценарии UAT на основе процессов, тестирование разрешений, интеграционное тестирование и нагрузочное тестирование, если применимо.

    Контрольная точка: UAT, утвержденное владельцами процессов, с классифицированными дефектами и устраненными блокировщиками.

  7. 07

    Обучение и подготовка

    Вывести организацию на уровень, когда она сможет работать с первого дня.

    Функциональное обучение, краткие справочные материалы, сеть «Чемпионов», внутренние коммуникации и план поддержки.

    Контрольная точка: Проверка готовности: пользователи, данные, разрешения, поддержка и план отката.

  8. 08

    Ввод в эксплуатацию и гиперуход

    Стабилизировать и передать в непрерывную эксплуатацию.

    Запланированное окно переключения, тесная поддержка в первые недели, измерение внедрения и быстрые исправления.

    Контрольная точка: Выход из гиперухода на основе согласованных метрик стабильности и внедрения.

Непройденная «контрольная точка» преднамеренно останавливает проект. Это момент, когда стоимость исправления все еще низка.

Роли

Кто за что отвечает

Владелец бизнес-процесса

Основная ответственность
Определяет, что должно произойти, и утверждает приемку
Сторона
Клиент

Лицо, принимающее решения с полномочиями

Основная ответственность
Разрешает разногласия и утверждает изменения в объеме работ
Сторона
Клиент

Архитектор решений

Основная ответственность
Модель данных, разрешения и решения по платформе
Сторона
HPI Pro

Менеджер по реализации

Основная ответственность
Планирование, приоритизация, риски и коммуникация
Сторона
HPI Pro

Разработчик и Администратор

Основная ответственность
Разработка, автоматизация, программирование и тестирование
Сторона
HPI Pro

Специалист по данным

Основная ответственность
Профилирование, миграция, качество и сверка
Сторона
HPI Pro

Представитель ИТ и безопасности

Основная ответственность
Инфраструктура, идентичность, разрешения и регулирование
Сторона
Клиент

Группа тестирования пользователей

Основная ответственность
UAT и обратная связь по удобству использования
Сторона
Клиент

Управление рисками

Четыре риска, управляемые с самого начала

Данные хуже, чем ожидалось

Раннее профилирование до установления сроков и согласованные правила принятия решений для записей, которые не соответствуют пороговому значению.

Растягивание объема работ (scope creep)

Каждый запрос получает оценку влияния и явное решение. Утвержденное изменение также изменяет сроки и бюджет.

Сопротивление пользователей

Раннее вовлечение ключевых пользователей, реальное приемочное тестирование и функциональное обучение, а не обучение по экранам.

Зависимость от одного человека

Документирование решений и постоянная передача знаний, чтобы проект не останавливался из-за отпусков или больничных.

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

Методология — частые вопросы

Какова типичная продолжительность проекта Salesforce?
Продолжительность зависит от масштаба процессов, состояния данных и количества интеграций, а не от размера организации. Процесс продаж с чистой миграцией сильно отличается от трех межотдельских процессов, связанных с ERP. Мы предоставляем оценку времени только после фазы обнаружения, поскольку до этого это было бы предположением.
Что такое «контрольная точка» (stage gate) и почему она необходима?
«Контрольная точка» — это явное условие, которое должно быть выполнено перед переходом к следующей фазе: например, утверждение модели данных или успешное согласование тестовой загрузки. «Контрольные точки» предотвращают распространенный сценарий, когда проект продолжает развиваться на неутвержденной основе, и это обнаруживается только на этапе приемочного тестирования.
Вы работаете по Agile или Waterfall?
В контролируемом сочетании. Архитектура, модель данных и миграция данных требуют предварительного планирования, поскольку их изменение в процессе работы очень дорого. Разработка, улучшения и приоритизация выполняются короткими циклами с периодическими демонстрациями. Подход выбирается по компонентам, а не по идеологии.
Кто должен участвовать в проекте со стороны организации?
Менеджер бизнес-процессов для каждой области, представитель ИТ или данных, лицо, принимающее решения, способное разрешать разногласия, и группа пользователей, которая участвует в приемочном тестировании. Отсутствие лица, принимающего решения с полномочиями, является одной из наиболее распространенных причин задержек.
Что происходит, если требования меняются в ходе проекта?
Изменение — естественная часть проекта. Что недопустимо, так это недокументированные изменения. Каждый запрос оценивается по утвержденному объему, получает оценку влияния на время и бюджет и принимается или отклоняется посредством явного решения. Это помогает избежать незаметного «растягивания объема работ» (scope creep).
Что остается у организации по завершении проекта?
Архитектурная документация и модель данных, карта интеграций, реестр решений, скрипты тестирования, учебные материалы по функциям и операционные процедуры. Цель состоит в том, чтобы организация могла поддерживать и развивать систему без нашей помощи.

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

Мы адаптируем метод к вашему объему

Не все проекты требуют одинаковой глубины каждой фазы, но каждый проект должен знать, какие «контрольные точки» он проходит.