Меня зовут Павел Власов. За моими плечами 20 лет проектного опыта автоматизации процессов на 1С: 9 лет работы в сети франчайзи 1С и 11 лет в КРОК на проектах внедрений 1С федерального масштаба в корпоративном сегменте. Сейчас руковожу группой консультантов по 1С и управляю производственными процессами масштабных проектов по внедрению 1С в роли старшего технического менеджера. 

На проектах внедрения 1С встречаются характерные проблемы, которые мешают добиваться высоких результатов. Вот некоторые из них:

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

2. Нечеткие зоны ответственности в команде: один человек – и консультант, и программист, и архитектор.

3. Один консультант работает сразу на 2-4 проектах.

4. Команда проекта часто меняется, на разных этапах разные люди.

5. Консультанты выполняют одни и те же виды работ по-разному, каждый как привык.

6. Оценка проекта проводится без участия производственного отдела.

7. «Проектное рабство» — нет четких границ в проекте, договора типовые, ТЗ размытое с неопределенными рамками и границами, а «клиент всегда прав».

8. Сроки не учитываются, главное – взять проект, «а там разберемся».

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

Чтобы сделать проектное производство более эффективным и управляемым, мы сформировали единые проектные подходы в нашей практике 1С. Без них просто не безопасно вести сложные корпоративные проекты.

Кому и зачем нужны единые проектные подходы

У всех, кто работает на корпоративном рынке, есть своя методология внедрения в том или ином виде. У нас – тоже своя. Мы долго выстраивали процессы – КРОК работает с 1С уже более 13 лет. В основу нашего проектного подхода легла методология Oracle AIM. Когда-то консультанты КРОК получили опыт внедрения ERP-систем этого вендора. За 10 лет мы оптимизировали эту методологию под 1С, исключили лишние документы и адаптировали ее под ГОСТ 34-й серии. У нас много заказчиков, которым нужно, чтобы структура документов соответствовала этому стандарту.

Вот что помогает сделать проектное производство управляемым и эффективным:

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

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

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

От методологии и инструментов — к проектной культуре

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

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

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

Более подробно про это можно прочесть в нашей другой статье: «Управление требованиями и проектирование в СППР с использованием методологии AIM»‎. 

Мы составляем и записываем инструкции в видеоформате через Vanessa Automation, Yandex SpeechKit и 1Script. Благодаря этому мы получили возможность пересобирать их в автоматическом режиме и поддерживать в актуальном состоянии, даже если изменились элементы интерфейса.

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

Типичная задача в Jira

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

Структура проектной команды

Во главе проекта всегда стоит куратор — директор клиента (аккаунт менеджер) или руководитель практики 1С в КРОК, либо их тандем. Куратор на высоком уровне от лица компании отвечает за результат перед заказчиком, вместе с менеджерами участвует в управляющих советах по проекту (обычно, раз в месяц).

Основное управление проектом осуществляют два менеджера — технический менеджер и менеджер проекта.

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

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

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

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

Как и системный аналитик, консультант должен уметь проектировать доработки, потому что ФДР у нас пишет консультант. А вот писать код ему не нужно, достаточно понимать устройство системы, регистры, справочники, различия между измерениями и ресурсами в регистрах и т. д.

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

Процессный подход в нашей методологии

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

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

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

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

Каталог бизнес-процессов описывает функциональное содержание системы и функциональные границы будущего проекта автоматизации. Структура каталога является основой для последующего проектирования и разработки системы на базе 1С:СППР.

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

В привязке к бизнес-процессам и/или шагам БП регистрируются требования:

• C — это стандартная функциональность, то есть это требование полностью решается стандартными возможностями 1С,
• К — это кастомизация, никакое типовое решение 1С не покрывает его, 
• Н — это настройка, то есть для реализации этого требования достаточно выполнить настройку в системе.

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

Похожие требования на доработку мы объединяем в один предмет доработки (ФДР) / проектное решение. Это предмет доработки, имеющий самостоятельную ценность или функциональность. Его можно отдельно передать заказчику под протокол. Например, если заказчику требуются уведомления по электронной почте, все связанные с этим требования целесообразно объединить в один ФДР по доработке системы уведомлений. Такой подход позволяет структурировать доработки системы и облегчает передачу результатов работ заказчику.

Подход по этапам работ и отчетным документам

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

Здесь мы определяем функциональные границы проекта: декомпозируем систему на подсистемы, подсистему на блоки, блоки на бизнес-процессы. 

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

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

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

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

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

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

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

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

1. Моделирование бизнес-процессов

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

2. Проектирование и разработка 

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

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

3. ПСИ

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

Проводится кросс-функциональное тестирование — выделяются и проверяются сквозные процессы от начала до конца, например, от заказа товара до его получения. По итогам формируется протокол с замечаниями и сроками их устранения. Также на этапе ПСИ проводится нагрузочное тестирование для выявления и нивелирования рисков низкой производительности до запуска в опытно-промышленную эксплуатацию (ОПЭ).

4. Подготовка к опытно-промышленной эксплуатации

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

5. Опытно-промышленная эксплуатация

По сути, этот этап — проверка работоспособности всех процессов на промышленных данных, стабилизация системы, выявление и устранение ошибок, поддержка пользователей.

Методология на примере

Рассмотрим, как все это работает на практике. Допустим, у нас проект с 9 подсистемами, 278 бизнес-процессами и множеством интеграций. Эта информация собрана на этапе предпроектного обследования.

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

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

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

У нас 9 подсистем, значит, нужно 9 отчетных документов. Их разработка и согласование превращается минимум в 18 задач.

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

Понятно, что вносить и администрировать все 2300 задач в Project — очень сложно. Поэтому в Project вносятся задачи по спринтам и подсистемам. В итоге в Project в данном примере получается около 600 задач, связанных с общим статусом работ, а детальные планы формируются либо в Jira, либо в Excel.

Заключение

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

Простого наличия методологии и шаблонов документов недостаточно — важно, чтобы их применение приводило к реальным результатам и становилось неотъемлемой частью рабочей культуры. Необходимо, чтобы участники команды видели практическую пользу от применения выбранных методов, и чтобы они стали неотъемлемой частью рабочей рутины.Также важно иметь обучающие материалы для быстрого вовлечения новых сотрудников и адаптации всех инструментов, процессов и методологий друг к другу. Мы стремимся привлекать в КРОК экспертов, которые могут развивать и поддерживать наши практики.

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