Предпроектное обследование (ППО) — отдельный этап внедрения 1С:ERP

На основании Свода процессов сформировали Карты процессов (в формате Excel), в которых изложена информация обо всех выполняемых функциях на предприятии, об их владельцах и о связях между ними. В процессном подходе Карты процессов помогают команде сформировать единое понимание шагов процесса, его границ, потерь, дублирующих функций и узких мест. Каждому процессу из Свода соответствует отдельная Карта процесса, с выделением подпроцессов, операций.

Цель: зачем нужен отдельный этап ППО

Основная цель – сформировать согласованное и подтверждённое основание для принятия решения о запуске проекта автоматизации. Часто выделяется в отдельный договор до старта основного проекта внедрения.

Задачи на данном этапе:
— определить цели автоматизации и ожидаемые эффекты;
— зафиксировать границы проекта;
— изучить текущее состояние компании, ИС и данные;
— выявить реальные потребности бизнеса, проблемы, ограничения и риски;
— сформировать верхне-уровневые требования к будущей системе;
— определить концепцию, этапность, сроки, ресурсы, бюджет проекта.

ППО помогает избежать ошибок, снизить риски перерасхода бюджета и сроков, а также оптимизировать процессы до их автоматизации.

Главный результат ППО – заказчик и подрядчик одинаково понимают, что автоматизируется, зачем, каким способом, в какие сроки и по каким критериям будет приниматься результат.

Для кого подходит отдельный этап ППО

Отдельный этап ППО лучше всего подходит там, где высока неопределённость, много участников и систем, а цена ошибки на этапе внедрения существенна.

Каким заказчикам ППО особенно полезно:
— Крупные и средние предприятия: много подразделений, процессов, ролей и взаимосвязей;
— Холдинги и группы компаний: требуется унификация учёта, справочников и отчётности между юридическими лицами;
— Территориально распределённые организации: нужно учитывать различия филиалов и подготовить модель тиражирования;
— Компания с неоднородным ИТ-ландшафтом: разные учётные системы, интеграции, Excel-файлы и локальные решения;
— Регулируемые организации: высоки требования к учёту, контролю, безопасности, аудиту и отчётности;
— Предприятия с неформализованными процессами: правила существуют «в головах» сотрудников, регламенты устарели или противоречат практике;
— Заказчики с негативным опытом внедрения: требуется заново определить причины неудачи и реалистичный объём проекта;
— Организации, планирующие конкурс или тендер: ППО позволяет сформировать сопоставимое техническое задание;
— Заказчики, которым нужно обосновать инвестиции: руководству нужна оценка стоимости, эффекты, риски и дорожная карта.

Для каких проектов ППО наиболее оправдано:
— Комплексное внедрение ERP — изменение одного процесса влияет на множество других;
— Замена основной учётной системы — помогает определить, какие функции действительно нужны, а какие исторические доработки можно исключить;
— Централизация учёта в холдинге;
— Автоматизация бюджетирования и управленческого учёта — проблема часто не в системе, а в отсутствии согласованной методологии;
— Внедрение казначейства и платёжного календаря;
— Проекты с большим количеством интеграций — ППО снижает риск того, что интеграции обнаружатся уже после начала разработки;
— Проблемы миграции больших или проблемных данных;
— Тиражирование решения — если систему планируют внедрять в нескольких филиалах или компаниях;
— Проекты с фиксированной стоимостью — чем жёстче требования к срокам и бюджету, тем важнее заранее определить границы.

Когда можно обойтись без отдельного ППО

ППО может быть избыточен, если одновременно выполняется большинство условий:
— автоматизируется один локальный процесс;
— работает одно подразделение или небольшая группа пользователей;
— внедряется стандартное решение без существенных доработок;
— требования уже подробно описаны и согласованы;
— интеграции отсутствуют или типовые;
— переносится небольшой объём качественных данных;
— организационные изменения минимальны;
— стоимость и продолжительность всего проекта невелика.

ППО максимально ценно не там, где нужно просто установить программу, а там, где автоматизация затрагивает правила работы предприятия и требует согласования бизнеса, финансов, учёта и ИТ. Обойтись можно без отдельного этапа ППО, но не без уточнения требований вообще: если система типовая, границы ясны, данные готовы, обследование можно встроить непосредственно во внедрение.

Материал по теме: «Внедрение 1С:ERP» — услуги и этапы комплексного проекта внедрения

Ценность этапа — для заказчика и для нас

Ценность для заказчика
— предсказуемость проекта — обоснованное понимание сроков, бюджета, ресурсов и состава работ;
— снижение риска неверной автоматизации — до начала дорогостоящей разработки выявляются реальные проблемы процессов;
— контроль границ — понятно, что входит в проект, что нет и что планируется на следующие очереди;
— обоснование инвестиций — связь между затратами, изменениями процессов и измеряемыми эффектами;
— согласование подразделений — финансы, бухгалтерия, закупки, ИТ и бизнес договариваются о единых правилах;
— выявление организационных проблем — не только недостатки систем, но и неопределённые полномочия, дублирование функций;
— подготовка данных и пользователей — заранее определяется объём очистки справочников, миграции, обучения;
— основа для выбора подрядчика — требования и границы позволяют сопоставить исполнителей на единой базе.

Ценность для подрядчика
— понимание реального объёма работ — снижается вероятность недооценки сложных процессов, интеграций и миграций;
— повышение точности оценки — можно обоснованно определить сроки, состав команды и стоимость проекта;
— снижение проектных рисков — ограничения, зависимости и проблемные данные выявляются до начала реализации;
— формирование договорной базы — результаты ППО становятся основой ТЗ, календарного плана и критериев приёмки;
— управление изменениями — новые требования можно отделить от согласованного объёма;
— доступ к ключевым участникам — формируется рабочее взаимодействие с владельцами процессов;
— повышение вероятности успешного внедрения — решения строятся на фактических процессах;
— снижение конфликтов при приёмке — результаты и критерии готовности определяются до начала разработки.

Как мы проводим ППО: порядок и состав работ

— Организация обследования. План-график ППО, перечень функциональных блоков, список участников, матрица ответственности.
— Анкетирование. Шаблоны анкет, опросных листов по функциональным блокам.
— Сбор исходных материалов. Документация, оргструктура, учётная политика.
— Интервью и рабочие встречи. Протоколы встреч в виде Карт процессов.
— Анализ процессов As Is. Детальное описание текущих процессов.
— Описание процессов в формате BPMN. Графические схемы бизнес-процессов.
— Анализ ИТ-ландшафта. Инвентаризация систем и интеграций.
— Анализ данных. Качество и объём НСИ, определение миграции.
— Выявление проблем и рисков. Реестр разрывов, ручного труда, ошибок.
— Формирование целевого ИТ-ландшафта.
— Формирование требований. Каталог функционально-технических требований.
— Определение границ проекта. Согласованный функциональный объём.
— Оценка трудоёмкости и сроков. План-график, ресурсная и стоимостная оценка.
— Защита результатов. Утверждённый отчёт по ППО.

Что на выходе: какие документы получает заказчик

Отчёт о предпроектном обследовании фиксирует результаты обследования и анализа текущих процессов, ИС, данных и требований заказчика. Отчёт включает:
— текущее состояние автоматизации;
— границы, функциональный объём проекта;
— требования к будущей ИС и список необходимых доработок;
— целевую архитектуру и схему интеграций;
— требования к нормализации данных, подлежащих переносу;
— оценку сроков, стоимости и ресурсов, дорожную карту внедрения;
— реестр проблем, рисков, ограничений и допущений.

Карты процессов: что внутри
Карта процесса — многостраничный файл с закладками НСИ, печатные формы и отчёты, Требования и Смежные ИС — ниже показываем каждую закладку отдельно.

Итоги и выводы: что мы поняли после нескольких проектов ППО

1. ППО нужно не каждому проекту.
2. Ценность ППО не в отчёте, а в принятых решениях. Важно – этап должен снять основные разногласия.
3. Глубина ППО должна соответствовать риску проекта. Небольшому проекту достаточно нескольких интервью и краткого отчёта. Для комплексного ERP-внедрения потребуется полноценное обследование процессов, систем, данных, интеграций и организационной готовности.
4. ППО снижает риск, но не устраняет его полностью. Невозможно заранее детально спроектировать все процессы крупной системы.
5. Без участия заказчика качественное ППО невозможно. Если заказчик не выделяет участников и время, сроки и достоверность результатов становится фиктивной.
6. Основные риски проекта находятся вне ИТ: отсутствие владельцев процессов, противоречивые регламенты, разные правила учёта в подразделениях, некачественные справочники, дублирование функций, неготовность пользователей и отсутствие единой методологии. Автоматизация не устраняет эти проблемы.
7. ППО должно отделять автоматизацию от организационных изменений.
8. Границы важнее количества требований. Важно зафиксировать не только требования, но и исключения: какие подразделения, функции, данные и интеграции не входят в текущую очередь — именно отсутствие явных исключений чаще всего приводит к неконтролируемому расширению объёма работ.
9. Оценка до ППО носит предварительный характер.
10. Результаты ППО должны стать частью договорной базы. Если материалы ППО не используются на последующих этапах, их практическая ценность быстро теряется.
11. ППО может показать, что проект запускать рано. Отказ от преждевременного запуска может быть самым ценным результатом ППО.
12. ППО защищает обе стороны. Для заказчика оно снижает риск получить дорогое, но не подходящее решение. Для подрядчика – риск отвечать за неограниченный объём работ и несогласованные ожидания. Поэтому ППО должно быть прозрачным и совместным.