Предыдущее внедрение 1С не дало результата

Как проявляется проблема

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

Обычно ситуация проявляется следующим образом:

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

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

В результате предприятие продолжает поддерживать систему, которая используется только частично.

К чему это приводит

Почему внедрение может зайти в тупик

Как правило, причина не одна. На конкретном проекте одновременно проявляется несколько факторов.

Не были определены конкретные бизнес-цели

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

Не определены границы проекта

Требования постоянно расширяются, а критерий завершения этапа остается непонятным. Команда не может отделить обязательные задачи от пожеланий, которые можно реализовать позже.

Автоматизирован действующий беспорядок

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

Требования собирались отдельными задачами

Каждое подразделение формулировало собственные пожелания, но никто не проверял, как они влияют на общую архитектуру, данные и работу смежных отделов.

Не хватало сильного руководителя проекта и методолога

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

Пользователи недостаточно участвовали в моделировании

Сотрудники увидели систему только перед запуском. В результате важные особенности процессов обнаружились слишком поздно.

Данные не были подготовлены

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

Система не проверялась на сквозных процессах

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

Доработки создавались без учета типовых возможностей 1С

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

Подразделения предъявляли противоречивые требования

Каждый отдел стремился сохранить привычный порядок работы, даже если он мешал смежным процессам.

Решения со стороны заказчика принимались слишком долго

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

Запуск начался до готовности процессов, данных и пользователей

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

Не ищем виноватых

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

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

Мы не проводим оценку ради поиска виноватого. Наша задача — определить, что мешает получить результат, какие решения можно сохранить и как вернуть проект в управляемое состояние.

Что проверяем на первом этапе

Изучаем:

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

Полный анализ программного кода и производительности в эту работу не входит.

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

Не предлагаем начинать все заново без необходимости

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

Это могут быть:

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

Если отдельный контур построен неудачно, сравниваем варианты: исправить существующую реализацию, заменить часть решений или перенести процесс в новую базу.

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

Как продолжаем работу

Восстановление проекта под ключ

Берем на себя проектирование, настройку, разработку, перенос данных, проверку, обучение и запуск изменений.

Совместная работа с командой заказчика

Распределяем задачи между нашими специалистами и внутренней командой предприятия.

С какими системами работаем

Восстанавливаем и развиваем проекты на базе:

• 1С:ERP Управление предприятием;
• 1С:Комплексная автоматизация;
• 1С:Управление торговлей;
• 1С:Управление нашей фирмой.