Просмотр исходного текста страницы Лучше один раз увидеть

;[[:Категория:Максим Цепков (Статьи)|Максим Цепков]]: главный архитектор компании CustIS (Заказные ИнформСистемы)
Опубликовано в журнале Intelligent Enterprise, № 2(февраль), 2010 <ref>[http://www.iemag.ru/analitics/detail.php?ID=20121 Intelligent Enterprise, № 2 (212), 22 февраля 2010 года]</ref>

<div>
<blockquote>
Одна из наиболее насущных и сложных проблем для компании — получение качественной управленческой отчетности. Ее решение требует взаимодействия различных специалистов: топ-менеджеров, сотрудников планово‑экономического отдела, аналитиков, обеспечивающих постановку задач, и программистов. Для этих групп характерны большие различия в понятийном аппарате: финансово‑экономические категории непонятны разработчикам, и наоборот, особенности автоматизации процессов не осознаются бизнес‑специалистами. Аналитики же зачастую не обладают достаточными знаниями, чтобы в полной мере обеспечить передачу информации и решение вопросов.
</blockquote>

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

=== Проблема построения отчетов ===

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

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

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

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

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

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

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

=== Методология решения ===

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

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

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

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

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

[[Файл:Элементы плана счетов.jpg|thumb|600px|center|Элементы плана счетов]]

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

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

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

=== Какие преимущества дает методология ===

Прежде всего, применение нашей методологии снижает то, что принято называть «совокупной стоимостью владения» учетной системой. Или, другими словами, — стоимость ее поддержки и доработки. Из диаграмм планов счетов однозначно видна логика учета, что позволяет абстрагироваться от отчетов и дорабатывать документы, заботясь лишь о сохранении принципов отражения их в учете. И наоборот, можно будет разрабатывать новые и дорабатывать существующие отчеты, опираясь лишь на учетные схемы и не касаясь документов. К тому же визуальное представление, понятное разработчикам и тестерам, упрощает проверки при изменениях в системе. Многие ошибки выявляются без участия бизнес‑специалистов. Естественно, диаграммы не статичны, они тоже меняются по мере развития системы. Однако, как показывает практика, они намного стабильнее, чем бизнес-логика документов или отчетная часть. Планы счетов образуют редко изменяемый костяк учетной системы, а диаграммы — его визуальный образ.

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

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

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

=== Нужен ли инструментарий? ===

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

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

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

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

== План счетов процесса расчета с клиентами ==

[[Файл:План счетов процесса расчета с клиентами.jpg|thumb|600px|center|План счетов процесса расчета с клиентами]]

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

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

Если у клиента один текущий контракт, то разбор платежей может выполняться автоматически. А если контрактов несколько, то для выяснения назначения платежа потребуется время, в течение которого он будет находиться на транзитном счете. Таким образом, мы избегаем конфликта интересов: бухгалтер заинтересован в проведении платежей по мере получения выписок из банка, менеджеры — по мере выяснения назначения платежа, а за счет транзитного счета это можно делать в разное время.<br>

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

----
<references/>

[[Категория:Максим Цепков (Статьи)]]
[[Категория:Intelligent Enterprise (Публикации)]]
[[Категория:2010 год (Статьи)]]

{{replicate-from-custiswiki-to-lib}}