8 (800) 500-61-51, 8 (495) 260-28-08 Будни с 9:00 до 18:00 по мск 127473, г. Москва, ул. Селезневская, д.34

Заказать звонок

Дочерняя компания 1С

Последовательность функциональных очередей

posledovatelnost2

Автор: Лисин Н.Г.

В этой статье: ответ на часто возникающий в начале проекта вопрос о последовательности проектных очередей. То есть о том, в каком порядке внедрять функциональные подсистемы 1C:ERP, с учетом приоритетов предприятия.

Исходная ситуация: на стартующем проекте, реализуя стратегию предприятия-заказчика, намечена следующая последовательность внедрения очередей 1C:ERP (по порядку убывания приоритета):

  1. Оперативный учет ТМЦ
  2. Планирование производства
  3. Регламентированный учет (в 1С:ERP)

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

В настоящее время регламентированный учет ведется в программе “1С:Бухгалтерия”. Оперативный учет автоматизирован фрагментировано в 1С:УПП, планирование производства по сути не автоматизировано. Работает отлаженная процедура выгрузки данных первичных документов из 1С:УПП в 1С:Бухгалтерию.

Вопрос

Какой вариант выбрать:

А) 1С:УПП и 1С:ERP работают параллельно, пока регламентированный учет не переведен на 1С:ERP. Таким образом, частично дублирующиеся системы будут функционировать одновременно до конца 3-й очереди.

Б) Отказаться от оперативного учета в 1С:УПП и реализовать временную выгрузку из 1С:ERP (оперативный учет) в 1С:Бухгалтерию в ходе 1-й очереди внедрения.

Каждый вариант имеет свои минусы:

А) Поскольку оперативный учет по-прежнему ведется в 1С:УПП, навряд ли можно ожидать, что данные оперативного учета в 1С:ERP будут достоверны.

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

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

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

Важно отметить, что такой подход с одновременной работой двух систем очень трудоемок, особенно при различиях в структуре данных в параллельных системах (документы, справочники, реквизиты объектов). А главное – параллельная работа двух систем совсем не означает, как это казалось бы (и на что возлагаются надежды), последующего простого и быстрого перехода на новую систему с отказом от старой системы!

Почему так?

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

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

Итак, вариант (А) не является оптимальным – надежда на то, что параллельное ведение учета в новой системе позволит безболезненно «перескочить» на новую систему при отказе от старой, может не оправдаться.

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

img.erp_

Зачастую, нетривиального функционала, при том, что этот функционал – временный.

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

Кстати, если оперативный учет будет основан на действующей системе, не так-то просто будет добиться, чтобы часть бизнес-процессов (планирование) были встроены в новую систему, при том что часть процессов (учет) остаются в старой системе!

Итак, вышеприведенная последовательность очередей либо приводит к разработке временного и сложного функционала обмена-выгрузки (Б), либо к возможно недостоверным данным после внедрения оперативного учета в новой системе (А), т.к. система не встраивается в бизнес-процессы!

Посмотрим, что будет, если переставить очереди 2 и 3. Сначала запустим с 1 января учетный блок в полном объеме – оперативный и регламентированный учет. А далее, когда будет обеспечена устойчивая работа системы учета, запускается  3-я очередь – планирование производства.

Одномоментно происходит отказ и от старой системы оперативного учета 1С:УПП, и от старой системы регламентированного учета (1С:Бухгалтерия). Таким образом, не требуется ведение параллельных учетов, не требуется разработка временных функционалов обмена.

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

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

Предлагаемая последовательность очередей на рассматриваемом проекте:

  1. Оперативный учет ТМЦ – с 1 января.
  2. Регламентированный учет (в 1С:ERP) – с 1 января
  3. Планирование производства – по мере стабилизации учетного блока

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

 

06.02.2018
^