- +7 (495) 120-87-87
- info@ls-gp.com
- ПН - ПТ: 9:00 - 18:00
Статья на тему:
Команда проекта 1С: как не сорвать сроки внедрения и не выйти за рамки бюджета
Представьте, вы делаете ремонт в квартире: электрик сверлит там, где маляр уже покрасил стены, отделочник кладет плитку на еще не выровненные стены, а дизайнер меняет решение каждый день. Примерно так выглядит внедрение 1С на производстве без согласованной работы участников проекта как со стороны заказчика, так и со стороны подрядчика.
Люди — самая сложная часть любого ИТ-проекта. Особенно когда речь идет о производстве. Во внедрении 1С участвуют сотрудники из разных подразделений: производство, склад, финансы, ИТ. У каждого свои задачи и приоритеты. Если заранее не определить, кто за что отвечает, кто утверждает решения и как эти решения фиксируются, то проект тонет в согласованиях, встречи не ведут к решениям, а бюджет проекта и сроки стремятся в бесконечность.
В статье расскажем, как организовать совместную работу заказчика и подрядчика в проекте внедрения системы 1С:ERP и других программ 1С. Рассмотрим роли участников, рабочие группы, протоколы и журнал решений, и что стоит зафиксировать до старта проекта. Дадим ответы на частые вопросы о команде проекта.
Пять признаков, что команда проекта тормозит внедрение 1С
Проект по разработке программных решений на базе 1С для производства — это большая работа сотрудников компании и подрядчика на протяжении нескольких месяцев. От организации этой работы зависит успех всего проекта. Вот пять признаков, когда участники проекта работают по своим правилам и тормозят внедрение.
- Обсуждений много, утвержденных решений мало
Рабочие встречи, обсуждения проходят по графику, но вопросы не закрываются. Одну и ту же задачу команда выносит на обсуждение снова и снова.
Пример из практики:
- через неделю после очередной рабочей встречи кто-то из участников оспаривает уже утвержденное решение: «Мы так не договаривались»;
- на встрече приняли решение, но через неделю выяснилось, что «не так поняли»;
- у участников разные версии «что решили», особенно на стыке контуров, например, производство, склад, финансы и ИТ.
Решение: зафиксировать правила согласования, вести протоколы встреч и решений.
- Сколько угодно участников могут сказать «нет», но никто не может сказать «да»
Руководитель производства требует одни условия автоматизации, финансовый директор — другие. Никто из них не уполномочен принимать окончательное решение.
Пример из практики:
- по одной задаче два руководителя считают себя утверждающими;
- подрядчик получает взаимоисключающие задачи от разных подразделений.
Решение: назначить владельца решения — ответственного с правом финального утверждения по каждому контуру.
- Коллективное согласование вместо ответственности
Желание учесть мнение всех пользователей превращает проект в бесконечные обсуждения. Один «хочет галочку тут», другой «отчет здесь», но никто не несет ответственности за итог.
Пример из практики:
- на согласование зовут всех «чтобы потом не было вопросов»;
- обсуждают детали в разрезе «как делаем», вместо того чтобы выбрать вариант и зафиксировать его в разрезе «что делаем».
Решение: установить и зафиксировать полномочия того кто может утверждать решения.
- Проект останавливается, когда ключевой сотрудник уходит в отпуск или болеет
В отсутствие ключевого сотрудника проект останавливается на неопределенный срок.
Пример из практики:
- никто не может согласовать решение без конкретного человека;
- задачи откладываются из-за отсутствия подписи/подтверждения.
Решение: определить точки участия ключевых сотрудников и организовать замещение на период отпусков, командировок и сменного графика.
- Подрядчик и заказчик работают параллельно
Исполнитель ждет согласования решений от клиента, клиент ждет предложений от исполнителя.
Пример из практики:
- один отдел считает, что решение принято, другой, что это был черновой вариант;
- подрядчик меняет настройку, потом получает просьбу все откатить и вернуть как было, потому что «думали будет по-другому».
Решение: вести протоколы встреч.
Такие тревожные сигналы обычно появляются в первые недели. Когда проект уже стартовал, а участники внедрения 1С:ERP системы или комплекса программ 1С не знают правил командной работы и принятия решений, нет понятной структуры команды, не определены роли участников проекта.
Роли и правила работы команды, которая завершает внедрение 1С в срок
Команда проекта внедрения 1С:ERP / 1С:КА / 1С:УНФ / 1С:УТ + 1С:Бухгалтерия на производстве — это совместная работа заказчика и подрядчика по согласованным правилам (Рис. 1.)
Рис. 1. Совместная работа заказчика и подрядчика по согласованным правилам
Успех проекта зависит и от экспертности специалистов подрядчика, и от того, насколько полно и компетентно заказчик укомплектует свою команду. В проекте внедрения 1С:ERP или комплекса программ 1С на производстве роли помогают создать понятную структуру принятия решений и дают ответы на практические вопросы: кто формулирует требования, кто утверждает решения, кто отвечает за данные, кто принимает результат.
Роли участников проекта внедрения 1С
Базовый состав команды с обеих сторон может быть изменен в зависимости от масштаба компании и количества контуров внедрения.
1. Заказчик — источник бизнес-требований, он отвечает за решения, которые определяют, как будет работать бизнес.
|
Роль
|
Определение
|
Зоны ответственности
|
Обязательность, да/нет
|
|---|---|---|---|
2. Подрядчик — модератор проекта и технический исполнитель.
|
Роль
|
Определение
|
Зоны ответственности
|
Обязательность, да/нет
|
|---|---|---|---|
Правила командной работы — невидимый каркас проекта. Без них даже ежедневные встречи не спасут проект от хаоса, срыва сроков и роста бюджета. Вот базовые договоренности, которые мы с нашими клиентами фиксируем в регламенте проекта:
Правила командной работы внедрения 1С на производстве
- один утверждающий по бизнес-процессу/контуру;
- сроки согласования решения;
- где ведем и храним журнал протоколов и решений;
- регламент замещения ключевого сотрудника;
- сценарий эскалации, что делать, если рабочая группа не договорилась.
Рабочие группы — основной инструмент коммуникации команды проекта
В статье «Аудит и план проекта: с чего начать внедрение 1С на производстве, чтобы не слить бюджет» мы говорили, что бюджет и сроки автоматизации напрямую зависят от полноты и точности собранных бизнес-требований. Но не менее важно заранее понимать, как участники проекта обмениваются информацией на всех этапах внедрения, как агрегируют вопросы и кто выносит их на согласование, кто утверждает решения и где они фиксируются.
При внедрении 1С на производстве не работает формат «соберем всех и обсудим». Если каждый вопрос проекта решать составом сотрудников из разных подразделений, например, склад, финансы и ИТ, то договориться о едином решении будет сложно и вопросы снова и снова будут возвращаться на пересмотр. Чтобы этого не произошло, мы формируем рабочие группы.
Рабочая группа — это инструмент коммуникации, который помогает принять и зафиксировать решение по конкретной задаче/вопросу.
Какие рабочие группы нужны в проекте внедрения 1С на производстве
Рабочие группы мы формируем по контурам. Контуры можно объединять или дробить на отдельные участки, в зависимости от масштаба компании и задач внедрения. Например, многоуровневое производство всегда включает несколько цехов или участков, каждый из которых имеет своего руководителя и собственные операции. Сотрудник, который печатает принты на одежде в цехе печати, может ничего не знать о процессе нарезки и очистки этих же принтов в цехе постпечатной обработки, хотя формально они относятся к одному производственному отделу.
Важно так сформировать рабочие группы, чтобы в них были представлены ключевые участники сквозного процесса, даже если они работают на разных участках одного производства. Это позволит выстроить единый, управляемый производственный учет.
Основные контуры:
- производство и планирование: выпуск, сменные операции, списания, техкарты;
- склад, снабжение, логистика: приемка, перемещения, инвентаризации, остатки, отгрузки;
- финансы и управленческий учет: закрытие периода, себестоимость, правила учета;
- регламентированный учет и зарплата: бухгалтерский и налоговый учет, расчет зарплаты, отчетность;
- ит и интеграции: обмены, оборудование, доступы и права.
Кого обязательно стоит включить в рабочую группу
Со стороны заказчика
- владелец процесса — утверждает решение;
- ключевой пользователь — детализирует требования по конкретному контуру;
- куратор/менеджер проекта — организует встречи, координирует внутренние коммуникации.
Со стороны подрядчика
- бизнес-аналитик — модерирует обсуждение, переводит требования в варианты решения;
- методолог — обеспечивает связь между бизнес-требованиями заказчика и возможностями программы 1С;
- руководитель проекта — координирует встречу, фиксирует решения.
Участие других сотрудников, опционально. Например, ИТ-специалиста заказчика привлекаем при обсуждении интеграций, сотрудника HR-службы, если затрагиваем учет рабочего времени, а технического архитектора, если речь идет о доработках ПО и о внедрении нового функционала.
Формат и ход встречи рабочей группы
Рабочая группа встречается, когда накопились вопросы, которые нужно закрыть, чтобы команда реализации могла продолжать внедрение по графику.
В проекте мы используем разные форматы встреч: короткие ежедневные — для синхронизации команды, сессии планирования — для расстановки приоритетов, демонстрации — для показа готовых решений и встречи по согласованию бизнес-процессов — для принятия и утверждения решений по контурам. Обычно по каждому контуру это одна рабочая встреча в неделю и встреча по общему статусу проекта, чтобы резюмировать промежуточный итог и подтвердить следующий шаг.
Как на практике в LS выглядит встреча рабочей группы:
1. Сбор вопросов по проекту:
- исходные вводные и статус ТЗ фиксируем по каждой теме: если ТЗ составлено детально — готовим чистовой вариант решения, если в ТЗ есть допущения — делаем черновой вариант для первой демонстрации;
- текущие вопросы собираем в течение недели: через чат/почту/трекер задач и по итогам статусов и рабочих встреч. Руководитель проекта и аналитик сводят их в единый список, расставляют приоритеты.
2. Руководитель проекта инициирует встречу. Формат: 60–90 минут, одна тема, четкая повестка, например, демонстрация, сбор информации для ТЗ.
3. Команда выбирает и утверждает решение.
4. Руководитель проекта фиксирует результат встречи в журнале решений: что меняется, кто утвердил, с какой даты вступает в действие.
Что делаем, если группа не договорилась и не смогла принять решение. Иногда реализацию одного и того же требования владельцы процессов трактуют по-разному и не могут прийти к единому мнению. В таких случаях мы:
- фиксируем какие есть варианты решения, готовим рабочие примеры для всех предложенных вариантов, смотрим на практике, как они работают в ИТ-системе;
- проводим оценку рисков: трудозатраты, сложность поддержки, влияние на смежные процессы.
Если после этого решение все еще не очевидно, берем за основу вариант реализации с допущением, который при необходимости можно развить в более сложный механизм уже в процессе эксплуатации. Далее выносим варианты решений на эскалацию и согласовываем с заказчиком: озвучиваем плюсы и минусы каждого подхода; показываем, что потеряем/получим в каждом случае.
Польза рабочих групп для проекта внедрения 1С
Для заказчика — бизнес-эффект
- решения принимаются в 2–3 раза быстрее. Это позволяет сотрудникам эффективно распределить рабочее время на решение задач проекта и операционную деятельность. Так, бизнес продолжает работать без простоев;
- каждое решение фиксируется один раз и становится правилом работы. Это снижает нагрузку на руководителей подразделений и освобождает время на решение управленческих задач;
- повышение лояльности. Владельцы процессов опираются на одну версию договоренностей, все участники проекта работают на единую цель внедрения;
- после запуска решения в промышленную эксплуатацию остаются формализованные правила учета — журнал решений, как регламент работы. Это снижает риски ошибок в учете и упрощает масштабирование.
Для подрядчика — качество внедрения
- снижение количества переделок и риска срыва сроков внедрения:
◈ команда разработчиков работает по журналу решений и реализует то, что решает задачи бизнеса;
◈ понятные, прозрачные правила и подходы.
Документы, которые помогают сократить сроки согласований решений в проекте
Документы на проекте внедрения 1С:ERP / 1С:КА / 1С:УНФ / 1С:УТ + 1С:Бухгалтерия — это страховка от срыва сроков и перерасхода бюджета. Подготовка и составление этих документов занимает не более 5% времени проекта, но предотвращают 95% рисков, связанных с человеческим фактором. Документы превращают устные договоренности в управляемые процессы, где каждый участник проекта знает: что делать, когда и зачем.
Что оформляем до старта проекта
1. Матрица ответственности (RACI): распределение ролей в проекте: кто выполняет задачу (R), кто утверждает результат (A), кто консультирует (C) и кого информируют (I). (Рис. 2.).
Рис. 2. Фрагмент рабочей документации. Матрица ответственности (RACI)
2. Правила замещения: кто принимает решения в отсутствие ключевых сотрудников.
3. Сценарий эскалации: кто и в какие сроки принимает решение по вопросам проекта, когда команда не смогла договориться.
4. Окно согласований: механизм защиты от срыва сроков проекта. Фиксируем срок на согласование решения (например, 3 рабочих дня), кто напоминает и когда, что делаем, когда решение не получается утвердить, кто замещает утверждающего, если он недоступен.
Артефакты проекта
Документы, которые обеспечивают прозрачность и предсказуемость на всех этапах внедрения.
1. Журнал решений: единый реестр всех утвержденных договоренностей, например, в системе CRM. Каждая запись содержит: дату принятия, суть решения, утверждающего, дату вступления в силу (Рис. 3.).
Правило: если решения нет в журнале — команда подрядчика не берет его в работу. Это дисциплинирует согласование и снижает риск того, когда «передумали на ходу».
Рис. 3. Фрагмент рабочей документации. Журнал решений
2. Протоколы решений: решения, действия, сроки. Например, мы ведем запись каждой встречи, делаем саммари и отправляем его всем участникам рабочей группы. Далее фиксируем результаты встречи в CRM и ставим задачи команде проекта LS.
Правило: один документ = одно решение.
Ответы на частые вопросы
Если проект небольшой и контур один — иногда да. На практике — нет, потому что это главный риск срыва сроков и бюджета.
Менеджер проекта от заказчика — не «контролер», а координатор внутренних процессов. Он собирает решения, обеспечивает участие в проекте владельцев процессов, управляет коммуникациями. Когда эту роль совмещает, например, ИТ-специалист или бухгалтер — проект уходит на второй план, потому что ответственность и задачи основной работы для них в приоритете.
Рекомендация: если отдельного сотрудника выделить нельзя, назначьте менеджером проекта ответственного, у которого минимум 30-50% времени выделено на проект. Документально закрепите его полномочия.
Чаще всего отказ выглядит так: «у меня нет времени» или «это задача ИТ/подрядчика». И если владелец процесса, например, начальник производства, не участвует, проект строится на предположениях. Это почти всегда приводит к одному из двух сценариев:
- система внедрена, но не используется — потому что «не так, как мы работаем»;
- после запуска начинаются переделки, которые стоят дороже самого внедрения.
Что делаем в LS:
- на старте проекта согласовываем со спонсором проекта обязательное участие владельцев процессов;
- если руководитель загружен, рекомендуем назначить его заместителя с правом утверждения;
- фиксируем решение замещения в регламенте.
Рядовые пользователи — носители уникальной информации о реальных процессах. Но включать всех пользователей не нужно, достаточно 1–2 сотрудника на каждый контур, которые знают процесс «как есть», со всеми «костылями» и исключениями. Других рядовых пользователей подключаем точечно, например, для уточнения информации.
Заключение
Если на старте проекта каждый участник внедрения системы 1С:ERP или 1С:КА / 1С:УНФ / 1:УТ + 1С:Бухгалтерия знает свою роль и правила совместной работы, проект перестает быть «полем боя» и становится инструментом развития бизнеса. Потратив несколько дней на организацию работы команды проекта, вы сэкономите месяцы на превращение хаотичного внедрения «сделать как-нибудь» в управляемый проект.
Оставьте запрос на консультацию с руководителем проектов LS
Получите рекомендации, с чего начать и как подготовить вашу команду к внедрению 1С
Полезное про внедрение 1С на производстве
Мы запланировали цикл материалов «Внедрение 1С на производстве». Сегодня третья часть, рассказали о команде проекта. В следующих статьях разберем остальные этапы и покажем, как внедрение проходит на практике — от выбора решения до сопровождения и развития.
- Часть 1. Аудит и план проекта: с чего начать внедрение 1С на производстве, чтобы не слить бюджет — первый этап внедрения, что проверяем, какие документы вы получаете, сколько времени занимает и можно ли обойтись без аудита.
- Часть 2. Какую программу 1С выбрать для автоматизации производства и как это сделать, чтобы не переделывать через год — как определиться с ПО, что учитывать при выборе и с каких систем чаще всего переходят: Oracle, Axapta, старые версии 1С и другие продукты.
