Дорожная карта проекта «1С»: ключевые этапы, артефакты и цели

Вам знакомы эти сценарии?

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

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

Как разобраться, что происходит? С чего начать погружение? Где описаны «хотелки» заказчика? Какие документы помогут понять требования к системе? 

Привет! Меня зовут Сергей, я консультант в департаменте 1С в «КОРУС Консалтинг». Статья будет полезна как начинающим младшим консультантам, которые только подключаются к проектной команде, так и опытным профессионалам, которые в силу обстоятельств, могли не участвовать в проектах полного цикла и начинали работу в середине или к концу проекта. 

Шаг за шагом расскажу:

• Как построить классическую дорожную карту проекта внедрения системы «1С». От рождения видения проекта до передачи в промышленную эксплуатацию, где требования должны превратиться в стабильно работающий продукт.

• Какие цели и результаты должны быть достигнуты на каждом этапе жизненного цикла проекта.

• Какие артефакты (документы, таблицы, схемы и не только) создаются в ходе этапа и их цели.

Разберем базовую терминологию

Многие думают, что внедрение «1С» — это про код, отчёты и сдачу «под ключ». На практике же успех проекта на 80% зависит от бумажек. Да-да, от скучных документов, протоколов и чек-листов. Они страхуют от разночтений и помогают не потерять ни одно требование по дороге.

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

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

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

Шаг 1. Пресейл: пытаемся понять, чего хочет заказчик

Классическая дорожная карта проекта внедрения системы «1С» начинается с диагностического этапа. Он проводится до подписания договора и включает в себя анализ. Именно на его основании строится фундамент будущего проекта. 

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

Ключевые артефакты

1. Опросный лист — документ с первичной информацией о компании-заказчике: сфере деятельности, численности сотрудников и количестве рабочих мест. Помогает сформировать описание ключевых процессов (продажи, закупки, склад, финансы), проблем (учёт остатков в Excel — постоянные ошибки отгрузок) и измеримых целей («закрываем месяц за 10 дней, хотим за 3»).

2. План обследования (он же «план-график встреч») определяет сроки, состав участников, тематику и ключевые вопросы всех рабочих встреч по сбору и анализу информации о бизнес-процессах заказчика. Благодаря ему процесс становится контролируемым, минимизируются риски упущения ключевых требований и беспорядочной коммуникации. Без плана сбор информации превращается в хаос, а риски упустить важное — в реальность.

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

4. Схемы процессов «AS IS» показывают, как реализован процесс в текущей системе. Благодаря им текстовые описания из протоколов обретают универсальную визуальную форму, которая одинаково понятна бизнес-пользователям и техническим специалистам. На практике такой подход помогает выявить скрытые проблемы: лишние операции, разрывы процессов и «костыли», которые не были очевидны при простом чтении документации.

5. Концептуальная архитектура (она же «отчёт об обследовании») — ключевой документ обследования с итоговым результатом всей аналитической работы. Это описание подготовленного решения, сформированного на понимании бизнеса клиента. Он буквально говорит заказчику: «Мы вас услышали, вот наше видение решения». На его основе можно согласовывать объёмы, бюджет, договоры и следующие этапы. 

Шаг 2. Проектирование: конструируем будущую систему

Этот этап еще может называться «Моделирование» или «Уточнение требований». Но суть одна — в его рамках концепция превращается в детальное проектное решение «как будет». 

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

Ключевые артефакты

1. Схемы процессов «TO BE» показывают, как будет реализован процесс после модификации системы. Всё то же, что в «AS IS», но уже после внедрения: какие операции автоматизированы, кто за что отвечает, какие документы передаются.

2. Сценарий моделирования — документ, который описывает пошаговые сценарии бизнес-процесса в демонстрационной базе с использованием типового функционала системы «1С». Например, оформление поступления товара на склад. В нём описывается роль пользователя, предварительные условия, последовательность действий в интерфейсе и ожидаемый результат.

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

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

5. Оценка реализации функциональных требований (или FIT/GAP анализ) — таблица, где каждое функциональное требование оценивается в трудозатратах и выставляется оценка:

1. Оценка «FIT» присваивается, когда требование полностью покрывается типовыми возможностями системы «1С» без доработок.

2. Оценка «GAP» присваивается, когда требование не покрывается «из коробки» и может быть реализовано с помощью:

1. изменения типового функционала под реализуемый бизнес-процесс;

2. разработки полностью нового решения;

3. интеграции с внешней системой. 

6. Концепция интеграции — документ, который описывает взаимодействия системы «1С» с другими системами «1С», CRM, WMS, сайтом и не только. Он содержит информацию о том, какие данные, куда, когда и каким методом (REST/SOAP API, шина данных, файловый обмен) будут передаваться. А также помогает оценить сложность и стоимость интеграционных работ.

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

8. Проектное решение (ПР) (оно же «общее техническое задание по проекту» или ТЗ) — главный документ, описывающий будущую реализацию системы с учетом зафиксированных требований. Включает цели, глоссарий, бизнес-процессы «TO BE», макеты объектов, описания реквизитов, производительность, безопасность и другие нефункциональные требования. Любое последующее изменение условий, не описанных в ПР, может нести за собой пересмотр сроков и стоимости реализуемого проекта.

Шаг 3. Разработка: когда код встречается с документами

Это технологический этап, в ходе которого на основе утвержденных проектных материалов команда внедрения разрабатывает, модифицирует и настраивает систему «1С» согласно запросу заказчика. 

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

Ключевые артефакты

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

2. Задания на разработку (ЗНР) (они же «спецификации для разработчика» или СП) — документ с задачей для разработчиков, описанной понятным техническим языком, сформированной на основе: ПР/общего ТЗ, пунктов с оценкой GAP, решений зафиксированных в ЧТЗ. Содержит оценку трудозатрат, модуль системы, исходные данные и точное описание, что должно появиться или измениться.

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

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

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

Шаг 4. Подготовка к ОПЭ: переходим в режим предбоевой готовности

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

Ключевые артефакты

1. Программа и методика испытаний (ПМИ) — таблица с последовательным сценарием тестирования бизнес-процессов. ПМИ помогает ответить на вопросы о том, что нужно тестировать, кто это делает, в какой последовательности, по каким критериям оценивается успех и что делать при обнаружении ошибок.

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

3. Сценарии приемочного тестирования — табличный документ с конкретными проверочными кейсами на реальных данных, которые пользователи будут выполнять, чтобы убедиться в работоспособности системы. Например, это может быть задача «провести отгрузку товара по заказу клиента».

4. План обучения пользователей (он же «программа обучения пользователей») — документ, определяющий стратегию и тактику подготовки конечных пользователей к работе в новой системе. Включает график, форматы, целевые группы, материалы и критерии успешности.

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

Шаг 5. Проведение ОПЭ: проверяем систему в близких к боевым условиям

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

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

Успешное пройденная ОПЭ — это показатель готовности системы к переходу в промышленную эксплуатацию.

Ключевые артефакты

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

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

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

4. План-график устранения оставшихся некритичных замечаний — таблица с перечнем замечаний или новых требований по модификации системы после запуска. Даёт заказчику гарантию, что оставшиеся недоработки не будут забыты, а команде внедрения — понятный план работ на постпроектный период.

Шаг 6. Передача в промышленную эксплуатацию: играем финальный аккорд 

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

Ключевой артефакт

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