Как перейти с SAP на «1С» за полтора месяца: опыт фармацевтической компании

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

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

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

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

На этапе переговоров попросили подрядчика организовать телеконференцию. На ней интегратор рассказал о преимуществах и недостатках всех имевшихся на тот момент продуктов «1С».

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

В рабочую группу вошло всего 15 сотрудников: представители склада, отдела по работе с клиентами, отдела логистики и бухгалтеры. Отбирали сотрудников, которые не только были ключевыми на своем участке, но и хорошо знали смежные процессы.

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

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

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

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

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

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

Блоки внутри MVP проранжировали в первую очередь по времени запуска. Кроме того, сопоставили наши пожелания с возможностями типовой конфигурации.

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

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

Чтобы сэкономить время и упростить миграцию в новое ПО, решили пожертвовать всеми идеями по изменению системных настроек. Например, в SAP у нас было порядка 200 счетов главной книги для учета управленческих и операционных расходов. При этом на счете «Прочие расходы» скапливались значительные суммы. Естественно, у бухгалтеров было желание «разобрать» счет для учета прочих расходов и подготовить подробную инструкцию. Решили переносить как есть, а правила менять с нового финансового года.

При переносе данных из SAP использовали принцип «один к одному» для центров прибыли, центров затрат и расходных статей. Статьями затрат стали группы финансового учета. Функциональные подразделения сделали многоуровневыми: верхний уровень соответствовал центру прибыли, более низкий — центру затрат.

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

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

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

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

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

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

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

• Начисления. В начале года мы готовим в Excel сметы на все регулярные расходы. Их называем начислениями (accruals).Если в течение финансового года в компании появляются новые проекты, сметы по ним создаем дополнительно. Все утвержденные сметы распечатываем и храним в финансово-экономической службе. Финансисты также ведут единый реестр начислений. В конце проекта, когда уже не было возможности отражать фактические расходные документы, мы загрузили в систему данные из единого реестра начислений. Это помогло не сорвать сроки подготовки ежемесячной отчетности. Сложностей с подготовкой техзадания на разработку загрузчика смет у нас не возникло. В документе мы расписали разработчикам, как программа должна анализировать остатки и сторнировать начисления.
• Детальный календарь закрытия месяца. Еще до проекта мы разработали календарь, в котором детально расписали активности каждого бухгалтера в последние пять дней месяца и в первые три дня следующего периода. Благодаря этому документу каждый сотрудник точно знает, что и когда нужно сделать. Во время проекта каждому сотруднику достаточно было пройти по своему календарю вместе с консультантом, чтобы объяснить ему суть проверки или операции. А после интегратор уже подсказывал, как этот функционал можно реализовать в «1С:ERP».
• Ежемесячные реконсиляции. Чтобы не нарушить сроки сдачи отчетности, мы сфокусировались на переносе корректного верхнеуровневого баланса по состоянию на начало года и на дату миграции данных в новую ERP. Отсутствие нужных аналитик компенсировали расшифровками в Excel.