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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Доступное решение

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

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

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

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

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

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

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

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

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

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

Важное организационное и технологическое преимущество подхода, реализованного в решении “ИТРП:Процессное производство 8” – возможность разбить проект внедрения на два этапа:

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

[evc_social_likes]