Меня зовут Юрий Силантьев, я руководитель практики «ERP и финансы» в К2Тех, отвечаю за проекты внедрения 1С.

Мы занимаемся крупными внедрениями уже 15 лет. Недавно я разбирал подход, применяемый нами в крупных внедрениях 1С. От подготовки и предпроекта до эксплуатации: какие инструменты используем, как фиксируем договоренности и за счет чего удерживаем проект в управляемом состоянии.

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

Зачем нужен предпроект

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

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

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

Структура предпроекта

Мы делим предпроект на три подэтапа:

• Формирование каталога целевых бизнес-процессов.

• Разработка целевой функциональной архитектуры.

• Подготовка технического задания на внедрение.

В этой статье подробно разберем два ключевых блока: каталог бизнес-процессов и техническое задание. 

Каталог мы готовим в формате Excel: он входит в состав ТЗ как приложение и является базовым артефактом нулевого этапа. В каталог включаем целевые процессы (to be), не дублируя перечень as is. Ведь на уровне перечня процессов “as is” и “to be” во многом совпадают - процессы не исчезают и не появляются, а изменяется их реализация. Для оценки проекта важно определить какие процессы войдут в объем проекта, а также в явном виде выделить процессы которые должны появиться или измениться. Каталог процессов “to be” как раз отлично это показывает. Кроме того, на этапе формирования каталога процессов уже определяется новый ландшафт систем, который будет эти процессы покрывать. .

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

Что такое бизнес-процесс в нашем каталоге

Чтобы каталог не превратился в перечень «функций в системе», мы сначала договариваемся о том, что считаем бизнес-процессом. У процесса всегда есть: 

• вход — событие, которое его инициирует; 

• выход — событие, которым процесс завершается; 

• исполнитель — человек или роль, выполняющие действия. 

• содержание (последовательность действий) и среда выполнения — автоматизированная система, Excel или бумажный носитель.

Все эти атрибуты должны быть отражены в каталоге. При этом мы сознательно не проваливаемся в излишнюю детализацию на предпроекте: нам важно понимание границ процессов и их количество. Этого достаточно, чтобы оценить, каким решением его автоматизировать, насколько он типовой, какие потребуются доработки и какие интеграции и отчетные формы задействуем.

Как устроен каталог бизнес-процессов

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

По каждому процессу указываем его наименование и целевое описание. Описание остается верхнеуровневым, но достаточным для решения четырех задач:

• Определить, каким функциональным решением автоматизировать процесс: «Управление торговлей», ERP, ERP «Управление холдингом» или продукт другого вендора.

• Понять примерный уровень кастомизации: типовой процесс, частичный кастом или полностью кастомный сценарий.

• Выявить интеграционные взаимодействия: например, когда данные из 1С передаются в CRM, мы сразу фиксируем, что потребуется интеграция и какие потоки данных будут задействованы.

• Определить необходимость формирования отчетных и печатных форм; на этом основании формируем реестр отчетов и форм и учитываем его в оценке проекта.

Таким образом, на первом шаге мы работаем с составом и целевым описанием процессов, не затрагивая детализированного моделирования — это задача следующего этапа.

Атрибуты процесса в каталоге

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

• Целевую систему, в которой он будет автоматизироваться.

• Владельцев и участников процесса — службы и роли, с которыми будем работать на этапе моделирования.

• Входы и выходы процесса.

• Перечень отчетных и печатных форм, выделенный из описания процесса.

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

Сбор исходной информации

Формирование каталога начинается с анализа исходной информации от заказчика. На первом шаге мы запрашиваем все доступные материалы по текущей автоматизации: регламенты, стандарты, пользовательские инструкции, проектные решения, либо доступ к действующей системе. Анализ этих данных позволяет понять, какие бизнес-процессы фактически присутствуют в деятельности компании.

Далее, на основании этих материалов и нашего проектного опыта, мы составляем первичную базовую версию каталога. Понятно, что эта версия будет сильно меняться, но уже с ней мы можем прийти на первую встречу с заказчиком и начать интервью. Такой подход ускоряет обсуждение: эксперты клиента не описывают все «с нуля», а корректируют предложенный скелет.

Интервью и итерации по каталогу

Следующий шаг — интервью с функциональными экспертами заказчика. Количество встреч по каждому блоку зависит от сложности и числа процессов: обычно закладываем по 2–3 интервью на один функциональный блок, по некоторым достаточно одной встречи, по другим может потребоваться 4–5. В рамках интервью мы демонстрируем каталог на экране, проходимся по каждому процессу, исключаем неактуальные, добавляем недостающие и актуализируем содержание с учетом специфики предприятия.

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

Как из каталога рождается архитектура

На основании утвержденного каталога целевых бизнес-процессов мы подбираем функциональную архитектуру, которая с минимальным уровнем кастомизации автоматизирует требуемый состав процессов. Здесь важно соблюсти баланс между количеством систем, уровнем интеграций и объемом доработок. Каталог позволяет явно видеть, какие процессы будут покрыты типовыми средствами, а где потребуется отдельное решение или существенный кастом.

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

Зачем нужно детализированное ТЗ

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

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

Организационные границы проекта

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

Четко описанные границы позволяют избежать ситуации, когда отдельные подразделения «появляются» в проекте уже на этапе внедрения. Для нас это база для планирования объема работ, для клиента — понимание, кого и когда затронет проект.

Функциональная архитектура и интеграции

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

Отдельным разделом идут требования к интеграционному взаимодействию. В нем мы фиксируем состав интеграций и потоки данных, чтобы зафиксировать интеграционный объем и учесть его в оценке проекта. Обычно раздел оформляем в виде таблицы: система-источник, система-приемник, описание потока. Эти данные мы уже собрали на этапе формирования каталога: при описании процессов сразу отмечали точки интеграции и направления потоков.

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

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

Далее следует раздел «Требования к сопровождению системы после внедрения». В нем мы заранее обсуждаем с клиентом, за счет каких ресурсов будет обеспечиваться поддержка системы с момента начала промышленной эксплуатации. Это может быть зона ответственности заказчика, либо в течение определенного периода мы остаемся и обеспечиваем поддержку, и тогда соответствующий ресурс нужно заложить в проект.

Каталог процессов в составе ТЗ

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

Каталог в составе ТЗ выступает в роли «карты территории»: по нему любой участник может понять, что именно будет автоматизироваться, в каких системах и с каким уровнем детализации. Для клиента это еще и инструмент управления ожиданиями: любые изменения в наборе процессов меняют объем и стоимость проекта, и это сразу видно.

Методологическая база

Еще один критический раздел ТЗ — требования к методологическому обеспечению. Речь идет о методиках и расчетах, без которых невозможно автоматизировать отдельные функциональные блоки, особенно связанные с планированием, бюджетированием и прогнозированием. Здесь мы фиксируем, какая методологическая информация нужна, кто и к какому сроку должен ее предоставить.

Есть два базовых сценария: либо заказчик самостоятельно готовит методологию к нужному сроку, либо мы подключаемся и помогаем, и тогда в проекте выделяется отдельный методологический этап. Важно, чтобы этот этап был завершен до начала моделирования первого процесса: иначе на этапе моделирования команда будет «угадывать» методику, а не реализовывать согласованный подход.

Документирование, техническая архитектура и план работ

Отдельным разделом в ТЗ идут требования к документированию. Здесь мы заранее договариваемся, какие документы будут сформированы на каждом этапе, какова будет их структура, формат и содержание. Это снимает типичную проблему, когда в середине проекта стороны по-разному понимают, что такое «готовая документация».

Далее следует раздел «Требования к техническому и программному обеспечению» — по сути, описание технической архитектуры: состав и мощности серверов, требуемое ПО, инфраструктурные компоненты. 

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

Приемка системы и отчетные формы

Важный раздел ТЗ — порядок контроля и приемки системы. В нем мы описываем состав и сценарии испытаний, которые будут проводиться для приемки решения: виды испытаний, критерии приемки, уровни критичности ошибок и так далее. Фактически это «правила сдачи» проекта, о которых мы договариваемся до начала внедрения.

Завершает ТЗ раздел с перечнем отчетных и печатных форм. Сами формы мы уже фиксировали в каталоге бизнес-процессов, здесь мы переупаковываем их в структуру ТЗ. В результате на выходе получаем подробное ТЗ, где детально описан функциональный объем проекта, определены функциональная и техническая архитектура, состав интеграций, перечень форм, требования к инструктажу, методологической базе, контролю и приемке, документированию и дорожной карте проекта.

Что получаем на выходе нулевого этапа

По результатам предпроекта у нас сформированы три ключевых артефакта:

• Каталог целевых бизнес-процессов.

• Целевая функциональная архитектура.

• Детальное техническое задание на внедрение.

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

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