- +7 (495) 120-87-87
- info@ls-gp.com
- ПН - ПТ: 9:00 - 18:00
Статья на тему:
70% проекта и 90% рисков: что под капотом этапа разработки в проекте внедрения 1С на производстве
Старт проекта и этап разработки прикладных решений на платформе 1С, на первый взгляд, кажутся понятными: запустили проект, настроили типовой функционал, при необходимости доработали. Однако именно здесь сосредоточены основные риски для бизнеса. И даже если проект формально не будет сорван, ошибки этого этапа почти всегда оборачиваются перерасходом бюджета и отклонением от сроков внедрения.
В статье расскажем, что такое старт проекта 1С и как сделать так, чтобы не случилось фальстарта. Разберем, почему на этапе разработки самые высокие риски срыва сроков внедрения и как выстроить управление проектом, чтобы минимизировать эти риски. Дадим чек-лист, какие контрольные точки и артефакты помогут внедрить 1С в срок и в рамках бюджета.
Старт проекта
Старт проекта — точка процесса автоматизации, когда все требования собраны, текущие бизнес-процессы формализованы, сформирована команда проекта, которая готова к этапу разработки. Но как показывает наш опыт внедрения 1С:ERP систем и комплекса программ 1С, старт проекта может оказаться фальстартом и привести к увеличению расходов, если не знать, какие вводные данные и решения должны быть зафиксированы до начала разработки.
1. Аудит
Разработка прикладных решений на платформе 1С, требует планирования, финансовых ресурсов и участия многих сотрудников. Чтобы получить от автоматизации то, что вы ожидаете, мы проводим аудит:
- Инвентаризируем и формализуем текущие бизнес-процессы. Выявляем узкие места, например, дублирование операций и ручной ввод данных, чтобы понять, какие процессы нужно сохранить, какие — оптимизировать, а какие — перестроить при переходе на новую программу. Это позволяет точно оценить объем работ, сроки и бюджет проекта.
- Фиксируем границы внедрения. Определяем, какие интеграции и контуры, например, производство, складской учет, продажи, бюджетирование, финансовый учет входят в текущий проект, а какие могут быть реализованы на следующих этапах. Четкие границы защищают бюджет от перерасхода на реализацию неучтенных задач и предотвращают обман ожиданий на этапе приемки.
- Формируем концепцию решения. Определяем общую логику будущего решения, как будут связаны процессы, данные и интеграции. Так мы можем согласовать архитектуру решения до старта проекта и избежать противоречивых доработок на этапе разработки.
- Составляем дорожную карту внедрения 1С:ERP или комплекса программ 1С. Фиксируем этапы проекта (Рис. 1.), ключевые задачи, сроки и ответственных. Это позволяет синхронизировать работу всех участников проекта, контролировать ход внедрения, управлять сроками и бюджетом проекта.
Аудит — это не только анализ бизнес-процессов, но и знакомство с командой заказчика. Эксперты LS Group проводят интервью с владельцами процессов, ключевыми пользователями, выявляют зоны сопротивления изменениям. На этом этапе мы видим, как принимаются решения, как устроены внутренние коммуникации и какие ожидания есть у ключевых участников проекта. Знакомство с командой LS Group повышает доверие сотрудников заказчика к новой системе и дает нам возможность снизить риски слабой коммуникации на старте внедрения, например, когда участники проекта не могут принять единое решение, проект затягивается, и сроки оказываются под угрозой срыва.
По итогам аудита вы получаете комплект документов:
- описание процессов «как есть», список узких мест и рисков: где возникают расхождения, ручные операции и зависимость от конкретных людей;
- карту текущей ИТ-архитектуры: программное обеспечение, интеграции с внутренними и внешними сервисами, технические требования;
- границы проекта, допущения и ограничения. Требования по контурам, какие задачи должна решать программа 1С в каждом блоке: учет, склад, производство, финансы, планирование;
- выбор ПО 1С, обоснование выбора;
- перечень доработок и настроек. Что закрываем типовым функционалом 1С, где нужны настройки и доработки под правила компании;
- описание миграции данных: какие источники данных будут использоваться, какие справочники и остатки критичны, кто отвечает за подготовку и проверку данных;
- дорожную карту внедрения 1С:ERP или комплекса программ 1С, план проекта с этапами, сроками, ответственными.
Комплект материалов по итогам аудита — рабочий инструмент для старта проекта. Документы аудита позволяют принимать управленческие решения на основе фактов, а не предположений. Их можно использовать для формирования технического задания или запроса коммерческих предложений у подрядчиков.
Подробно, как собрать информацию для старта проекта, рассказали в статье «Аудит и план проекта: с чего начать внедрение 1С на производстве, чтобы не слить бюджет».
Рис. 1. Фрагмент рабочей документации по проекту. План проекта
2. Команда проекта
Есть еще один момент, который часто упускают, когда говорят о старте проекта — это состав команды. Участники проекта должны понимать свою задачу, права и полномочия, например, кто отвечает за предоставление и сбор требований, или кто принимает результат разработки со стороны бизнеса. Если роли заказчика размыты или в команде исполнителя не хватает необходимой экспертизы, риски проекта растут уже на старте. Подробнее о ролях и задачах команды читайте в статье «Команда проекта 1С: как не сорвать сроки внедрения и не выйти за рамки бюджета».
Рекомендация: не начинайте разработку, даже если поджимают сроки, пока, как минимум, не будут утверждены требования, границы проекта и состав команды проекта. Потраченное на подготовку старта проекта время всегда обойдется вам дешевле, чем уточнения по этим вопросам в процессе разработки.
Этап разработки в проекте внедрения 1С на производстве
На этапе разработки команда LS адаптирует типовое решение 1С под задачи и потребности бизнеса заказчика. Стандартного шаблона разработки, который подошел бы для всех проектов, не существует. У каждого бизнеса свой масштаб, своя команда и свои возможности. Однако практически для всех производственных компаний характерен схожий порядок внедрения 1С:ERP, либо другой программы:
- определение и устранение функциональных разрывов;
- разработка и настройка общего функционала под бизнес-процессы заказчика;
- разработка и настройка интеграционных механизмов;
- составление программы и методики испытаний (ПМИ) и проведение тестирования;
- документирование проекта и обучение ключевых пользователей;
- сдача работ заказчику и опытно-промышленная эксплуатация (ОПЭ).
Разработка — самый длинный этап, обычно он занимает 60–70% всего времени проекта. Здесь сконцентрирован основной бюджет и максимальное количество управленческих решений. Поэтому именно на этом этапе самые высокие риски незапланированных расходов и срыва сроков.
Семь рисков этапа разработки
У рисков проекта на этапе разработки есть две особенности: плохая и хорошая. Плохая: риски при разработке ИТ-систем неизбежны. Хорошая: риски можно предусмотреть и минимизировать. Для этого надо знать. когда они могут случиться и как с ними работать
Риск 1. Параллельная разработка и распределение задач
На крупных в проектах внедрения 1С:ERP системы или комплекса программ 1С редко работает один разработчик. Обычно параллельно внедряют несколько контуров: производство, склад, закупки, финансы. Как это выглядит на практике. Один разработчик создает объекты, от которых зависят другие. Второй ждет, пока появится нужные данные. Поэтому при большом объеме задач растет риск хаотичной разработки и срыв сроков внедрения. Это можно сравнить с нерегулируемым перекрестком на дороге, когда со всех сторон едут машины, но никто никого не хочет пропускать. И главной дороги нет.
Скорость решения задачи, еще один источник срыва сроков, когда на проекте несколько разработчиков. Скорость разработки напрямую зависит от опыта, уровня и квалификации специалиста. Например, одну и ту же задачу опытный разработчик выполнит за несколько часов, тогда как разработчик без релевантного опыта будет разбираться в ней неделю, и это за счет бюджета проекта.
Решение команды LS: вводим в состав команды проекта роль технического архитектора. Задачи архитектора:
- проектировать архитектуру ИТ-решения до начала разработки;
- определять зависимости объектов и последовательность их создания;
- выстраивать порядок работ по техническим уровням;
- координировать работу разработчиков с учетом их квалификации: простые элементы, например, печатные формы выполняют специалисты начального уровня, функционально или архитектурно значимые доработки — разработчики с соответствующим опытом.
Риск 2. Слабая детализация требований
Техническое задание (ТЗ) — это основа для работы разработчиков и одновременно это инструмент контроля для заказчика. В документе зафиксировано, что должно быть реализовано и в каком объеме. Если ТЗ описано поверхностно, разработчик принимает решения самостоятельно, например, как должна выглядеть та или иная внешняя форма. Но представление специалиста о том, «как правильно», может не совпадать с ожиданиями заказчика. В результате в проекте бесконечные переделки: «покрасьте желтым», «переместите поля», «добавьте галочку».
Решение команды LS: разрабатываем черновой вариант решения. Это максимально простой, базовый вариант внешнего вида какой-нибудь формы. Согласовываем с заказчиком, вносим дополнения и фиксируем в протоколе встречи. Потом разрабатываем финальный вариант и сдаем заказчику. Так, одна часовая встреча экономит нашему клиенту время и бюджет на неконтролируемое количество переделок.
Риск 3. Избыточная кастомизация
- Если разработчик знает функциональность решения поверхностно или не анализирует ее глубоко, решение любой задачи может уйти в кастомизацию. Стоимость владения такой ИТ-системой растет, потому что обновлять и сопровождать сильно доработанное решение сложно, долго и дорого. Избыточная кастомизация — это всегда долгосрочные финансовые риски.
И вопрос не в доработках в 1С:ERP или в 1С:КА/1С:УНФ/1С:УТ, они всегда будут, особенно при автоматизации крупных компаний или когда в учете много отраслевых особенностей. Риск возникает, когда изменения в программу 1С вносят без понимания логики типового решения и без контроля технической архитектуры для нового функционала.
Порядок действий специалистов LS: если типовой функционал закрывает 70–80% задачи, докручиваем его. Если необходимо изменить более половины логики процесса — проектируем под задачу отдельный модуль, без вмешательства в типовую конфигурацию.
До старта проекта:
- анализируем требования клиента;
- выбираем программу или комплекс решений 1С под задачи бизнеса. Как правильно выбрать программу 1С рассказали в статье «Какую программу 1С выбрать для автоматизации производства и как это сделать, чтобы не переделывать через год».
На этапе планирования проекта:
- пересматриваем автоматизацию текущих процессов. В исторических ИТ-системах, заказчик часто строит бизнес-процессы под возможности конкретной программы. Поэтому при переходе, например, с 1С:УПП или SAP на 1С:ERP/1С:КА/1С:УНФ важно учитывать логику процессов в новых программах. Это значит, что клиенту возможно придется пересмотреть и адаптировать свои текущие процессы. А если попытаться перенести в новую систему процессы «как есть», без изменений, то переход на современную программу учета теряет смысл. Потому что в результате получится та же старая модель работы, только в более современной оболочке;
- определяем какие бизнес-процессы будут закрыты типовым функционалом программы 1С, а что потребует точечных доработок.
Такой подход снижает объем нестандартного кода, упрощает обновления, сохраняет устойчивость системы при росте бизнеса.
Риск 4. Отсутствие тестирования или перенос на конец проекта
Что происходит, когда тестирование отдельных функциональных блоков и полная проверка работоспособности ИТ-системы отсутствует или проводится формально:
- всплывают ошибки учета в рабочей базе;
- функциональные блоки, которые по отдельности работают корректно, конфликтуют при совместной работе;
- интеграции работают некорректно;
- сотрудники не понимают как в реальности работает функционал нового решения 1С, потому что тестирование — это не только проверка работы функционала, но и ознакомление с ним.
Экономия на тестировании — это перенос рисков на операционную деятельность компании. В проектах с высокой нагрузкой цена такой экономии может измеряться десятками миллионов рублей.
Решение команды LS: выстраиваем многоуровневый процесс тестирования.
- Разрабатываем сценарии тестирования для каждого функционального блока.
- Разработчик проверяет решение самостоятельно и устраняет технические ошибки.
- Консультант проверяет доработку с функциональной точки зрения, оценивает корректность бизнес-логики и удобство для пользователя.
- Итоговую проверку по сценарию тестирования сдаем заказчику под протокол.
Пример из практики: подрядчик разработал блок интеграции склада с 1С:Управление торговлей. Из-за сжатых сроков руководство приняло решение запустить решение в эксплуатацию без тестирования. В результате склад фактически остановился: операции не проходили, машины сутками ждали отгрузки, а бизнес понес значительные финансовые убытки.
Решение пришлось дорабатывать и запускать повторно, по требованию клиента, снова без тестирования. В результате, и после второй попытки запуска, система продолжала работать нестабильно, а компания теряла десятки миллионов рублей выручки.
Риск 5. Некачественный код и сжатые сроки внедрения
Когда мы говорим о качестве кода, речь идет не о «красивом программировании», а о безопасности и устойчивости ИТ-системы. Владельцу бизнеса и пользователям оценить код сложно, ИТ-система либо работает, либо нет. Но так же, как при покупке автомобиля важно не только то, что он едет, но и его безопасность и управляемость, в ИТ-системе важны архитектура, корректная работа с данными и продуманная логика процессов.
Когда крупный проект, с объемом работ на 50 млн рублей, например, внедрение 1С:ERP на предприятии, пытаются выполнить в сжатые сроки и с ограниченным бюджетом в 15 млн рублей без пересмотра количества задач, то подрядчик неизбежно начинает экономить на архитектуре, тестировании, документации и стандартах разработки. В результате бизнес получает решение, которое формально закрывает его задачи, но по факту требует постоянных затрат на развитие функционала, доработки, поддержку и сопровождение.
Решение команды LS: не снижать требования к качеству кода, а разделить проект на этапы. Сначала реализовать MVP с базовым функционалом, затем планомерно развивать систему. В нашем случае MVP — это безопасный фундамент, а дальнейшее развитие — это плановый апгрейд системы до удобного и максимально продуманного инструмента. Безопасность данных и логики — это правильная архитектура решения. Комфорт работы — это удобные АРМ, автоматизированные проверки, подсказки и контролируемые процессы. Если бюджет ограничен, можно временно сократить «комфорт», но нельзя жертвовать безопасностью. В этом и есть разница между архитектурно выстроенным кодом и хаотичными доработками.
«Если бюджет ограничен, сократите объем работ, а не качество. Уберите сложные процессы, откажитесь от красивых отчетов, оставьте только базовый функционал. Потерпите. Разделите проект на этапы. Начните с MVP. Сделайте базу. Запуститесь. Потом планово развивайте продукт.
Так, вы будете видеть результат сразу. Бизнес будет расти вместе с ИТ-системой. Сотрудники будут постепенно адаптироваться к работе в новой ИТ-системе. Затраты распределятся во времени. А главное, у вас будет фундамент. Потому что качество кода определяет, станет ИТ-система инструментом роста или будет источником постоянных затрат и ограничений для бизнеса».
Андрей Семенов, генеральный директор LS Group
Пример из практики: компания по аренде мебели обратилась в LS с запросом «починить программу». Клиент работал в 1С:Управление торговлей, вся логика аренды была реализована внутри одного документа «Реализация товаров и услуг». Система не обновлялась несколько лет, и при попытке обновления на тестовой базе половина функционала перестала работать. О том, как мы решили задачу клиента, рассказали в кейсе «Как компания по аренде мебели для мероприятий закрыла полный цикл аренды в 1С:Управление торговлей».
Риск 6. Отсутствие документации по проекту
На практике документированием проекта внедрения 1С:ERP на предприятии часто пренебрегают, потому что за документацию нужно платить, а ее ценность не всегда очевидна заказчику в момент запуска системы. И речь не только о техническом описании кода, но и о пользовательских инструкциях, регламентах, схемах процессов и описании архитектуры. Без этих материалов решение на базе программ 1С превращается в черный ящик, который сложно развивать и поддерживать при смене подрядчика или переходе на сопровождение силами своего ИТ-отдела. Например, новый исполнитель:
- закладывает значительное время на изучение ИТ-системы и заказчик оплачивает эти часы;
- начинает поддерживать систему 1С точечными правками без полного понимания архитектуры.
Если сэкономить на документировании проекта, то даже изначально качественное ИТ-решение может превратиться в сложную систему: «галку добавили», «код поправили», «обновление поставили».
Решение команды LS: документируем проект в процессе разработки. Что фиксируем:
- технические решения по архитектуре и доработкам;
- регламенты работы системы;
- логику ключевых бизнес-процессов и схемы взаимодействия объектов;
- пользовательские инструкции.
Зачем бизнесу нужна документация проекта
- обучение новых пользователей
- знакомство с ИТ-системой нового подрядчика или команды разработчиков
- прозрачные процессы и легкость управления ими (можно изменить любой процесс, внести изменения в документацию и все)
- нет зависимости от носителей информации
Преимущества документирования проекта
- экономит часы работы любого сотрудника/подразделения компании и подрядчика, а значит экономит и деньги компании
- возможность осознанно принимать решения о доработках и объективно оценивать трудозатраты подрядчиков
- быстрый ввод в работу новых сотрудников
- планирование развитие ИТ-системы без риска непредсказуемых затрат
Риск 7. Неправильный выбор момента перехода разработки в опытную эксплуатацию
Опытная эксплуатация — это финальный этап перед запуском ИТ-системы в промышленную работу. От выбора момента перехода зависит, смогут ли сотрудники спокойно освоить возможности разработанной ИТ-системы или будут вынуждены балансировать между текущими должностными задачами и адаптацией к новой программе.
Если запустить опытную эксплуатацию системы в пиковый период, например, перед Новым годом, в сезон отпусков, в дни распродаж или в момент планового роста производства, сотрудники не справятся с двойной нагрузкой. Результат — ошибки в данных, возврат к старым инструментам и даже провал внедрения.
Решение команды LS: помочь заказчику выбрать момент перехода в опытную эксплуатацию. Мы рекомендуем:
- планировать запуск в наименее активный период бизнеса;
- оценивать сезонность и пиковые нагрузки;
- выделять сотрудникам время на обучение и работу в тестовом контуре;
- при необходимости усиливать команду на период перехода или предусматривать систему мотивации для сотрудников.
Неправильный выбор момента перехода превращает даже хорошо подготовленный проект в источник стресса для команды и финансовый риск для бизнеса. А правильный — дает время сотрудникам на адаптацию, позволяет не сорвать сроки проекта и сократить затраты на разработку в рамках бюджета.
Как команда LS управляет рисками на этапе разработки
Команда LS строит разработку циклами по каждому функциональному блоку, например, закупки, склад, производство, финансы. Мы снижаем влияние рисков этапа разработки на сроки и бюджет проекта через прозрачную коммуникацию и регулярные, каждые 1–2 недели, демонстрации работы специалистов LS. Такой подход предотвращает риски, о которых мы говорили в начале статьи.
Цикл разработки функционального блока
Фаза 1. Постановка задач
- Планирование — формирование задач в CRM. Для каждой задачи определяем состав команды: постановщик, разработчики, тестировщики.
- Техническое задание — описание задачи и способ ее реализации, список артефактов, срок реализации, ответственные сотрудники со стороны LS и подрядчика. Обязательное согласование с заказчиком.
Постановка задач в план — расстановка приоритетов задач и распределение их между участниками команды реализации. Формирование спринтов, в соответствии с дорожной картой внедрения 1С:ERP или комплекса программ 1С (Рис. 2.).
Рис. 2. Фрагмент рабочей документации по проекту. Пример дорожной карты
Фаза 2. Реализация и приемка
- Разработка — команда реализует решение по ТЗ.
- Тестирование — в два этапа: первое проводит разработчик, проверяет решение на наличие технических ошибок. Второе — консультант/тестировщик проводит проверку на соответствие функциональным требованиям ТЗ и работу связанных блоков.
- Демонстрация — показываем работу реализованной задачи владельцу процесса на тестовых данных.
- Корректировка — устраняем критические ошибки, например, документ не проводится, расчет неверный.
- Приемка — владелец процесса подписывает документ, что функциональный блок принят.
- Выпуск — включаем функциональный блок в релиз для опытной эксплуатации и переходим к следующему циклу.
Контрольные точки и артефакты этапа разработки
Подготовили чек-лист по контрольным точкам и артефактам, который позволит вам контролировать внедрение и управлять рисками этапа. Каждая контрольная точка — это возможность проверить качество внедрения и корректировать ход работ. Если на этапе разработки нет хотя бы одной из этих точек, риск срыва сроков возрастает на 15–20%.
|
Контрольная точка
|
Критерий прохождения
|
Ответственный
|
Артефакты
|
|---|---|---|---|
Ответы на частые вопросы
Можно. Первый вариант, за счет сокращения объема задач или упрощения требований. Второй вариант, чтобы облегчить этап MVP, перенести часть работ на этап развития системы.
В сложных проектах такие ситуации встречаются. Главная ошибка, когда исполнитель пытается реализовать новые задачи «по ходу проекта» и не пересматривает объем работ. Это приводит к срыву сроков проекта. Запрос на изменение архитектуры или добавление новых задач в проект мы отрабатываем пошагово:
- фиксируем инициативу в реестре требований;
- бизнес-аналитик готовит оценку: сколько потребуется времени на перепроектирование, какие смежные модули будут затронуты, как это повлияет на сроки и стоимость проекта;
- вместе со спонсором проекта принимаем решение что делаем: включаем изменения в текущий этап, переносим на следующий или отказываемся;
- фиксируем договоренности и обновляем план проекта.
Да. Даже если 80–90% работ выполняет подрядчик, проект все равно требует времени и вовлеченности со стороны бизнеса. Разработка — это процесс уточнений, принятия решений и проверки промежуточных результатов. Чем больше внимания руководитель уделяет проекту, тем точнее исполнитель понимает задачи бизнеса и тем выше качество итогового решения.
Заключение
Старт проекта и разработка — зона максимальной концентрации рисков срыва сроков и роста бюджета, поэтому, будет проект успешен или нет, зависит от плотной совместной работы подрядчика и заказчика. Несмотря на то что исполнитель отвечает за техническую реализацию проекта, а зона управленческой ответственности лежит на бизнесе, срыв сроков и рост бюджета возникают из-за упущений работы всей команды проекта. Например, размытые требования, отсутствие протоколов решений, хаотичное вовлечение сотрудников, неподготовленный запуск в опытную эксплуатацию.
На этом этапе важно четкое планирование, регулярный контроль, фиксирование решений, подготовка документации по проекту, тестирование каждого блока до перехода к разработке следующего блока и то, как построена коммуникации между участниками проекта. От квалификации подрядчика и качества организации этапа разработки зависит стоимость владения ИТ-системой и насколько легко ее можно будет развивать в будущем.
Запишитесь на консультацию с руководителем проектов LS
Расскажем, как снизить риски срыва сроков и роста бюджета на этапе разработки
Полезное про внедрение 1С на производстве
Мы запланировали цикл материалов «Внедрение 1С на производстве». Сегодня была четвертая часть. В следующих статьях разберем и покажем, как проходит внедрение на практике — от выбора решения до сопровождения и развития.
- Часть 1. Аудит и план проекта: с чего начать внедрение 1С на производстве, чтобы не слить бюджет — первый этап внедрения, что проверяем, какие документы вы получаете, сколько времени занимает и можно ли обойтись без аудита.
- Часть 2. Какую программу 1С выбрать для автоматизации производства и как это сделать, чтобы не переделывать через год — как определиться с ПО, что учитывать при выборе и с каких систем чаще всего переходят: Oracle, Axapta, старые версии 1С и другие продукты.
- Часть 3. Команда проекта 1С: как не сорвать сроки внедрения и не выйти за рамки бюджета — роли, ответственность, согласование, рабочие группы, коммуникация, график работ.
