Когда всем понятно

Максим Цепков - главный архитектор компании CUSTIS

Бухгалтер и компьютер, № 5(май), 2011
Журнал закрылся, архив недоступен. 
Более глубокий рассказ был в Санкт-Петербурге Международном экономическом симпозиуме — Соколовские чтения: доклад в 2017 и в 2018.

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

Эффективное представление информации

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

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

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

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

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

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

Рис.1. Неформальная схема учета личных финансов

Система должна давать возможность получить ответы на следующие вопросы: сколько у меня денег и где; кому я должен и сколько; кто мне должен и сколько; на что я трачу деньги; какие у меня есть доходы и из каких источников.

Для этого нужно спроектировать учетные регистры и изобразить их на той же схеме (рис. 2).

рис.2. Схема учета личных финансов с выделенными учетными регистрами

Овалы, обозначающие учетные регистры, можно разделить на три группы.

1. Зеленые («Наличные», «Карточка» и «Мне должны») — средства, на которые можно рассчитывать.
2. Желтые («Кредит в банке» и «Я должен») — отрицательные ресурсы.
3. Изображенные пунктиром — «Доходы» и «Расходы».

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

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

Далее нужно определить аналитические признаки учетных регистров, которые позволят отвечать на поставленные вопросы. Например, чтобы можно было узнать, кто мне должен, счет «Мне должны» должен иметь аналитику «Кто», обозначающую человека, которому я дал в долг. А чтобы давать информацию о том, на что я трачу деньги, счет «Расходы» должен иметь аналитику «На что», обозначающую статью расходов.

Теперь можно изобразить все на формальной схеме (рис. 3).

Рис.3. Диаграмма учета личных финансов

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

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

Ответы на поставленные вопросы можно получить путем анализа остатков и оборотов по учетным счетам. Например, ответом на вопрос «Сколько у меня денег и где?» будут остатки на счетах «Наличные» и «Карточка» в разрезе аналитики «Банк» и т. д. Собственно говоря, ответы на вопросы и есть отчеты, а учет конструируется исходя из того, какие отчеты понадобятся.

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

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

Холдинг из нескольких юридических лиц продает товары и оказывает услуги физическим и юридическим лицам, в том числе другим холдингам. В рамках управленческого учета необходимо обеспечивать ведение расчетов с нужной степенью подробности, ограничивать отгрузку без оплаты установленными лимитами, контролировать своевременность оплат и обеспечивать выполнение сверок с клиентом. Бухгалтерский учет предполагает ведение счета 62 «Расчеты с покупателями и заказчиками» и счета 90 «Продажи», но с меньшей подробностью, чем ведение управленческих расчетов.

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

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

Диаграмма учета для управленческого плана счетов изображена на рисунке 4.

Рис.4. Диаграмма учета для управленческого плана счетов

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

О направлении стрелок

Направление стрелки проводки к счету дебета соответствует естественному движению ресурса при участии в проводке активного счета. Однако в проводке между двумя пассивными счетами (в нашем примере это счета «Депозит», «Оплачено по контракту» и «Признанные обязательства») возникает одна нелогичность: перенос остатка происходит со счета дебета на счет кредита, т. е. в направлении, противоположном стрелке. Эта особенность требует привыкания, но, как показывает опыт, не мешает восприятию диаграммы. Альтернативные нотации (в которых, например, направление стрелок зависит от активности счетов в проводке) оказались менее удобными.

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

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

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

Диаграмма учета для бухгалтерского плана счетов другая. Она изображена на рисунке в упрощенном виде, без контура учета НДС (рис. 5).

Рис.5. Диаграмма учета для бухгалтерского плана счетов

Здесь все сосредоточено вокруг нескольких субсчетов счета 62 «Расчеты с покупателями и заказчиками», на которых и ведется учет. При этом бухгалтерский учет на большинстве субсчетов ведется с меньшей подробностью, чем управленческий, а часть проводок получается из управленческого учета путем исключения лишних аналитик.

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

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

Рис.6. Диаграмма соответствия управленческого и бухгалтерского учета

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

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

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

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

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