Продолжается подписка на наши издания! Вы не забыли подписаться?

Алеф Консалтинг & Софт

Повышение эффективности построения финансово - управленческих систем. 
Опыт применения программы Алеф 3.0


Введение

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

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

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

Мировая практика показывает, что стоимость программного обеспечения и услуг по его настройке для создания финансового приложения конкретного предприятия соотносится как 1:3 — 1:7. Это означает, что на каждый рубль, затраченный на программное обеспечение, приходится от трех до семи рублей услуг специалистов.

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

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

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

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

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

Пути увеличения качества выполнения проектов

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

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

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

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

Концепция обмена данными через аналитику проводок

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

Рис. 1. Документоориентированный подход

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

К достоинствам этого подхода можно отнести следующие:

К недостаткам этого подхода можно отнести следующие:

Конечно, многие из вышеуказанных недостатков могут быть нивелированы в конкретной реализации. Однако компенсация данных “методологических” дефектов может привести к утрате тех преимуществ, которыми обладает этот путь: быстродействие и низкая ресурсонагруженность. Данный путь хорошо применим на консервативных участках учета, где необходима большая оперативность обработки информации. Этот путь не является лучшим с точки зрения гибкости и настраиваемости. На рисунке 1 схематически изображены информационные потоки при описанном подходе.

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

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

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

Среди достоинств второго подхода можно выделить следующие:

Говоря о недостатках данного подхода, следует отметить следующие:

Рис. 2. Подход, ориентированный на использование двойной записи.

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

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

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

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

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

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

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

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

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

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

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

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

Концепция снижения вариативности учетной системы

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

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

Рассмотрим архитектуру построения Алеф.Бухгалтерии в аспекте гибкости и переносимости. На рис. 3 изображены архитектурные слои Алеф.Бухгалтерии.

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

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

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

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

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

Как указывалось выше, аналитический план счетов также является уровнем большой вариативности. Для ее снижения на этом уровне используется механизм “самонаведения” аналитики, который будет описан ниже.

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

Рис. 3. Архитектура построения АлефБухгалтерии

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

На рис. 4 приведена принципиальная схема Алеф.Бухгалтерии, позволяющая еще раз осознать назначение блоков:

Рассмотрим подробнее некоторые элементы блока представления, проведения и хранения аналитических данных.

Блок представления

Блок представления состоит в основном из документов Алеф.Бухгалтерии и профильных документов.

Документы системы Алеф.Бухгалтерия

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

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

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

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

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

Рис. 4. Принципиальная схема Алеф.Бухгалтерии

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

Рис. 5. Документ Алеф.Бухгалтерии

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

Профильные документы

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

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

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

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

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

Конечно, каждый профильный документ может быть связан с несколькими типами документов. Типы документов также могут быть связаны с несколькими профильными. Например, тип документа “Физическое лицо” может быть связан с профильными документами “Физическое лицо”, “Контрагент” и т.д. С другой стороны, Профильный документ “Контрагент” может формироваться типами документов “Физическое лицо”, “Юридическое лицо” и др.

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

Блок проведения

Блок проведения состоит из интерпретатора данных, конструктора проводок и генератора проводок. На рис. 6 представлена структурная схема блока проведения.

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

Механизм создания проводок состоит из трех основных узлов:

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

Конструктор проводок предназначен для преобразования входящего потока данных в соответствии с настройками типовых хозяйственных операций. Запрашивая необходимые данные у интерпретатора, конструктор заполняет массивы, которые используются генератором проводок. Конструктор доопределяет необходимые параметры с помощью встроенных вычислительных процедур. Кроме того, конструктор выполняет привязку параметров типовых хозяйственных операций к аналитике конкретного плана счетов. Эта процедура называется “самонаведением” аналитики.

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

Блок хранения. Структура аналитического пространства Алеф.Бухгалтерии

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

Рис. 7. Структура аналитического пространства “Алеф.Бухгалтерии”. 1 — дерево плана счетов, 2 — разделы, 3 — проводки

Рис. 8. Структура проводки. Коды и сквозные шифры

Однако для получения аналитической информации не всегда достаточно аналитического пространства, организованного в виде иерархии. Например: из понятий зимний/летний, женский/мужской, взрослый/детский — невозможно построить иерархию, хотя все эти понятия могут относиться к одному и тому же объекту аналитического учета, следовательно эти понятия невозможно расположить в традиционном “плоском” и иерархическом плане счетов. Для расширения аналитических возможностей в Алеф.Бухгалтерии используются механизмы сквозного шифрования и кодирования. Для сегментации пространства идентифицируемых состояний используются разделы. Каждый счет плана счетов может быть открыт в том или ином разделе независимо. На рисунке 7 схематически изображена структура аналитического пространства Алеф.Бухгалтерии. Дерево плана счетов (1) представляет собой иерархию “счет-субсчет-аналитический счет”. В качестве аналитического счета может быть использован любой аналитический справочник. Каждый раздел (2) охватывает свою область на дереве плана счетов. Эти области могут быть полностью независимы, а могут пересекаться или совпадать. Это определяется на уровне администрирования и может быть изменено в процессе эксплуатации. Проводки (3) могут иметь несколько окончаний (см. рис. 8). Каждое окончание и вся проводка в целом может быть прокодирована с помощью аналитических разрезов, формируемыми аналитическими справочниками.

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

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

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

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

Код K — Поставщик;
Код L — Период оказания услуг;
Код M — Период оплаты.

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

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

Пересадка готовых объектов в Алеф.Бухгалтерии

Рис. 9. Экран Алеф.Бухгалтерии, обеспечивающий экспорт настроек типовых хозяйственных операций

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

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

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

Обеспечение внешнего взаимодействия

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

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

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

Для организации совместного выполнения функций очень удобным и мощным инструментом являются алгоритмы документов. В алгоритмах могут быть вызваны функции, созданные на языке PowerScript, который, являясь объектным языком, обладает необходимыми свойствами для обращения к данным по протоколам OLE, DDE, ODBC и т.п. Кроме того, могут быть использованы протоколы высокого уровня (MAPI и другие).

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

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

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

Рис. 10. Способы формирования аналитических разрезов на основании внешних данных

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

Заключение

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

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

Аксенов Евгений,
Тришанков Лев



Copyright © 1994-2016 ООО "К-Пресс"