1С на крупных предприятиях — подходы к разделению финансового и оперативного учета

Особенностью создания комплексных Автоматизированных систем управления на крупных предприятиях (АСУП) является необходимость разрешения противоречия между требованиями к автоматизированной системе:

  • со стороны бизнес-процессов финансового учета и анализа. Приоритеты: Стоимостной учет, детализация только в целях учета и планирования, ограниченные требования к оперативности. Манипулирование данными, большая часть которых не имеет отношения к оперативному учету и управлению ресурсами.
  • со стороны бизнес-процессов ресурсного управления (оперативного учета, планирования, логистики). Приоритеты: Максимальная детализация, оперативность. Манипулирование данными, большая часть которых не имеет отношения к финансовому учету. Жесткие требования к безостановочному режиму работы. Остановка системы приравнивается к остановке бизнес-процессов, что при круглосуточной работе недопустимо.

Дуализм оперативного и финансового уровней — проблема крупных проектов

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

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

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

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

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

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

  • Перегрузка финансовых служб излишней детализацией оперативного учета.
  • Событие в операционной деятельности предприятия (склады, производства) требуют разной интерпретации по нескольким юридическим лицам и в управленческом финансовом учете — по нескольким бизнес-единицам.
  • Требуется одновременное внедрение как оперативного учета, так и финансового учета, как интерпретации операционных данных в деятельности юридических лиц и бизнес-единиц.
  • Финансовые транзакции и расчеты влияют на оперативность и бесперебойность работы системы оперативного учета.
  • Необходимость отслеживания прав доступа «оперативных» служб к финансовым данным.

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

Где искать решение?

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

При начале проекта автоматизации предприятие сталкивается с задачей определения стратегии автоматизации. С одной стороны, есть наиболее насущные задачи, требующие скорейшего решения, но имеющие локальный характер. С другой стороны, решение локальной задачи (например, автоматизация регламентированного учета) должно «вписываться» в будущее развитие системы, например, дальнейшая автоматизация оперативного учета, планирования, управления закупками и продажами, управленческого учета предприятия и холдинга. Такой подход называется системным.

Важное требование к стратегии развития АСУП — масштабируемость решений первых этапов. При развитии системы и охвате большего количества бизнес-процессов — достигнутые результаты и автоматизированные бизнес-процессы на ранних этапах не должны пересматриваться и перерабатываться. Это требование можно выполнить только при системном подходе — решение любой задачи автоматизации любого уровня должно учитывать свойства всей комплексной системы предприятия, а не только свойства решаемой задачи. Локальная задача должна быть решена таким образом, чтобы она была составляющей комплексной системы.

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

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

Исходим из того, что бухгалтерия не «придумывает» данные для учета. Эти данные появляются в результате операционной деятельности предприятия на самом «нижнем» уровне. Иначе говоря, только использование реальных данных оперативного учета (должным образом трансформированных) обеспечивает точность и достоверность финансового (регламентированного, управленческого) учета. Автоматизация поступления этих данных в бухгалтерию — решающий фактор надежности работы системы финансового учета и устранения «человеческого» фактора» в обработке материальных потоков.

Отсюда следует важный вывод — при комплексной автоматизации всех бизнес-процессов начинать надо с «первооснов» — организации автоматизированного оперативного учета, отражающего «реальную жизнь» предприятия. Эта система по свойствам оперативности и детализации должна удовлетворять всем задачам управления ресурсам предприятия, поддержки НСИ (PDM) и планирования. И только потом решать задачу построения систем финансового учета, на основе данных, извлекаемых с уровня оперативного учета.

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

Преимущества такой стратегии:

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

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

Уникальной возможностью типового решения «ИТРП:Процессное производство 8″ среди других продуктов на платформе 1С является реализованная концепция разделения функций бизнес-процессов на несколько уровней:

  • Оперативный и финансовый уровни предприятия.
  • Финансовый уровень предприятия и финансовый уровень управляющей компании холдинга.

Таким образом, в общем случае решение поддерживает трехуровневую архитектуру базы данных. При этом все уровни объединены общей НСИ.

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

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

Пример формирования нескольких документов — финансовых проекций на основе одной хозяйственной операции в оперативном учете — на следующей схеме:
Пример формирования нескольких документов - финансовых проекций на основе одной хозяйственной операции в оперативном учете

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

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

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

  • Уменьшение нагрузки на каждый узел — меньшее количество пользователей в каждом узле.
  • Разделение прав доступа — пользователям операционного уровня недоступны финансовые документы (на чтение или редактирование).
  • Обеспечение непрерывной работы операционного узла на этапе внедрения.

На следующей схеме показана структура системы регламентированного и оперативного учета, реализованная в решении «ИТРП:Процессное производство 8″, разделенная на два узла в распределенной базе данных.

Структура системы регламентированного и оперативного учета, реализованная в решении ИТРП:Процессное производство 8, разделенная на два узла в распределенной базе данных

Но это еще не все!

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

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

Для нормативно-справочных данных возможна управляемая миграция по всей структуре распределенной базы холдинга. Например, часть справочников или сегментов справочников может распространяться централизованно из управляющей компании (номенклатура продукции и основного сырья, статьи затрат и пр.) на предприятия, часть — создаваться на предприятиях и не передаваться в управляющую компании, часть может мигрировать только по одной ветке «УК — предприятие» и т.д.

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

Заключение

Выбор стратегии автоматизации и развития системы — самый ответственный шаг перед началом проекта. Если цели автоматизации для руководства предприятия как правило очевидны (иначе затем затевать проект), то технологии достижения результата на всех этапах проекта — не так прозрачны и отдаются на откуп службам ИТ или фирмам — внедренцам. Но мотивация этих структур может быть направлена только на эффективное решение конкретных текущих задач.

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

Николай Лисин, ИТРП

Понравилась статья? Расскажите, не молчите!

Если вам понравилась эта публикация, то нажмите, пожалуйста, на кнопку от facebook, vkontakte, twitter или yandex — чтобы о статье узнали другие люди. Мы будем вам очень благодарны за поддержку нашей работы!