CC BY
51
АВТОМАТИЗАЦИЯ УЧЕТА
УДК 004.051
АНАЛИЗ РЕАЛИЗАЦИИ ТЕХНОЛОГИИ БУХГАЛТЕРСКОГО УЧЕТА В СОВРЕМЕННОМ ПРОГРАММНОМ ОБЕСПЕЧЕНИИ
И. А. КОНОПЛЕВА,
кандидат технических наук, доцент кафедры математики и информатики,
профессор Е-mail: apollo@atknet. ru Филиал Всероссийского заочного финансово-экономического института, г. Архангельск Б. А. КОСТИН, ведущий специалист департамента ИТ E-mail: borisak@tfb. ru ОАО АИКБ Татфондбанк
Современное программное обеспечение бухгалтерского учета в целом не отвечает требованиям, предъявляемым к реализации технологии учетных задач. Многие программы подменяют рутинные операции автоматизированными аналогами. Для повышения отдачи от автоматизированных комплексов должна быть сформулирована система критериев для оценки качества бухгалтерского программного обеспечения и реализации в нем оптимальной технологии бухгалтерского учета.
Ключевые слова: программное обеспечение, автоматизированные системы бухгалтерского учета, технология бухгалтерского учета, базы данных, сущности и категории учета, отчетность.
Несмотря на достаточный спектр бухгалтерского программного обеспечения (ПО), систематического исследования с точки зрения
реализации технологии учета ни этой рыночной ниши ПО, ни самих программных продуктов не ведется. Официальная статистика в рамках изучения используемых автоматизированных информационных систем исследует только объемы продаж программных продуктов в денежном эквиваленте. Кроме того, продуктивность изучения бухгалтерского ПО в большой степени снижается по разным причинам, главные из которых — высокий темп развития и недостаточное качество программной продукции. Все это делает несколько расплывчатым ПО как предмет исследования.
Однако по отдельным направлениям (бухгалтерии, криптографическим системам, средствам удаленного доступа, технологиям, связанным с Интернетом) делаются более или менее полные обзоры, которые обычно классифицируют ПО по
определенным признакам и описывают отдельные компоненты программ (производительность, аппаратные требования, технологии производства, настраиваемость, удобства для пользователей, полноту отчетности и т. п.).
Автоматизированные системы бухгалтерского учета (АСБУ) из-за высокой конкуренции на рынке и необходимости максимально быстро выходить в продажу производятся без должного изучения области функционирования и оказываются недоработанными, излишне объемными. На это накладывается несложность разработки программ, которая приводит к тому, что ПО создается программистами, которые недостаточно владеют понятиями предметной области. Несложность разработки приводит к появлению большого числа разнообразных программ, относящихся к разным рыночным нишам и даже в недоработанном виде покрывающих достаточно большую долю учетной работы, требующей автоматизации.
Предприятия, выбирая автоматизированную систему, руководствуются многими критериями, которые, как правило, основываются на классификационных признаках АСБУ. Анализ литературы по автоматизации работы предприятия выявил общие принципы классификации автоматизированных систем. В настоящее время АСБУ классифицируются по следующим направлениям:
— технические характеристики;
— прикладные аспекты;
— финансовые характеристики;
— аспекты отношений с разработчиком;
— аспекты, относящиеся к сопровождению.
Эти направления классификации охарактеризованы в табл. 1.
Из таблицы 1 следует, что направления, относящиеся к предметной области, для которой производятся эти автоматизированные системы, отсутствуют. Могут рассматриваться и другие технические характеристики, например продолжительность транзакции, наличие связи через глобальные сети, настраиваемость внешнего вида. Из финансовых характеристик — уровень квалификации специалистов, стоимость обслуживания аппаратуры, гибкость цен, система скидок.
Анализ классификации автоматизированных систем показывает сугубо технический подход в обзорах и описаниях АСБУ: рассматриваются
ОС, объемы оперативной и дисковой памяти и т. п. Настолько же техническими являются и другие направления классификации — прикладные, финансовые и т. д. Порочность этого подхода в том, что все эти параметры не являются определяющими. Практически все они применимы в любой программе и автоматизированной системе — от игровой и обучающей до системы наблюдения за природой. Они не играют принципиальной роли для, собственно, автоматизации функционирования предприятия. Смысл бухгалтерских автоматизированных систем не в этих параметрах, а в реализации специфики учета как особой сферы человеческой деятельности. Соответственно классифицировать АСБУ следует по характеристикам технологий учета финансовых и материальных средств.
Автоматизированные системы для предприятий по очевидным причинам анализируются и характеризуются самими производителями этих систем в соответствии с приведенными ранее принципами классификации. Описание свойств производится по двум направлениям:
— в оплачиваемых аналитических статьях;
— описание свойств системы в рекламных материалах в прессе и на интернетовских страницах.
Аналитические статьи в области автоматизации бухгалтерского учета на предприятиях, написанные неангажированными исследователями, отсутствуют. Практически весь анализ делается бывшими или действующими сотрудниками тех или иных фирм-разработчиков. Академических исследований аспектов автоматизации практически нет—специализированные исследовательские центры занимаются исследованиями главным образом финансовых технологий, полагая их автоматизацию чем-то вторичным и само собой разумеющимся. Анализ автоматизации отдается на откуп разработчикам, которые представляют свою продукцию исключительно в благоприятном свете, игнорируя недоработки, ошибки, превознося положительные качества. По сути, аналитические материалы преследуют те же цели и содержат ту же информацию, что и рекламные описания.
Рекламные описания конкретной системы обычно содержат следующие части:
— постановку задачи, которую автоматизирует данная система, в виде набора блоков по направлениям работы бухгалтерии и финансового
Таблица 1
Современные принципы классификации автоматизированных систем
Классифицируемые признаки Существующие варианты
Технические характеристики
Аппаратная платформа Персональные компьютеры. Однотипные серверы. Серверы нескольких типов
Защищенность от несанкционированного доступа Защищенность операционной системы. Защищенность системы управления базами данных (СУБД). Защищенность бухгалтерского ПО
Защищенность от сбоев Слабозащищенные системы. Среднезащищенные системы. Высокозащищенные системы. Безотказные системы
Интерфейс пользователя Графический. Текстовый. Интерфейс через специализированные средства ввода-вывода
Инструментарий разработки Языки программирования общего назначения*. Специализированные средства**. Языки программирования общего назначения в комплекте с собственными или приобретаемыми специализированными библиотеками
Базовая операционная система (ОС) на рабочем месте сотрудника и на сервере Разные версии Windows. Системы UNIX разных производителей. Фирменные ОС производителей компьютеров
Системы управления базами данных Файловые (информационными объектами являются файлы). Система Btrieve. Серверы запросов, написанных на языке SQL (англ. structured query language — структурированный язык запросов)
Прикладные аспекты
Анализ деятельности Наличие возможности получения информации в разрезе клиентов, лицевых счетов, типов операций, типов материальных ценностей и т. д. Внешний вид и удобство средств анализа. Наличие гибких средств для анализа деятельности по собственным технологиям. Различные вспомогательные аналитические возможности
Территориальные возможности обслуживания клиентов Обслуживание клиентов только в головном подразделении. Обслуживание клиентов только в подразделении, в котором заключен договор. Обслуживание клиентов в любом подразделении
Консолидация данных Регулярные сеансы обмена информацией между подразделениями. Оперативный обмен информацией. Централизованное хранение информации
Настраиваемо сть Параметрическая настройка. Алгоритмическая настройка. Настройка методов учета. Настройка технологии учета
Отчетность*** Стандартная государственная отчетность. Стандартная внутренняя отчетность. Настраиваемая отчетность
Принцип построения автоматизированной системы Автоматизированные системы, построенные от счета. Автоматизированные системы, построенные от клиента. Автоматизированные системы, построенные от операции. Модульные автоматизированные системы
Функциональность Обязательные и дополнительные свойства, качества, процедуры, операции и т. п.
Окончание табл. 1
Классифицируемые признаки Существующие варианты
Другие аспекты
Финансовые характеристики Стоимость приобретения и сопровождения самой системы. Стоимость приобретения других программных средств (ОС, СУБД, средств ввода-вывода и др.). Стоимость приобретения аппаратного обеспечения для системы. Стоимость интеграции системы с другими системами, имеющимися на предприятии
Отношения с разработчиком Время существования фирмы-разработчика, количество продаж, годовой оборот, количество сотрудников, их квалификация и др., т. е. показатели надежности фирмы-производителя
Сопровождение Возможность сопровождения системы собственными силами, качество услуг по сопровождению (наличие представительства, «горячей линии», помощи в устранении сбоев, поддержки изменений в законодательстве и т. д.)
*Примеры: «Си/Си++» (C/C++), Modula и др.
**Примеры: FoxPro, языки промышленных СУБД — PL/SQL системы Oracl, Informix, Adabas и др.
***В отношении отчетности классифицируемым признаком также может выступать наличие готовых форм отчетности.
отдела (также могут упоминаться кадровый отдел и высшее руководство);
— интерфейсные достижения данной системы;
— описание преимуществ технологий программирования и систем управления базами данных (СУБД);
— объем отчетности, который имеет система;
— возможности изменения параметров и алгоритмов;
— дополнительные удобства в виде возможностей электронной почты, ведения архивов, интерфейсов к другим системам, администрирования, аудита, возможностей наращивания и расширения системы и др. Характеристика разделов описаний приведена в табл. 2.
О научности таких описаний говорить не приходится, поскольку их задача представить продукцию в выгодном свете. В целом описания разработчиками собственных продуктов подчеркивают не их преимущества в реализации технологии учета, а некоторые хорошие и нужные, но неопределяющие параметры.
Постановка задачи фактически состоит в декларации, что автоматизированная система должна автоматизировать деятельность предприятия. Ничего сколько-нибудь существенного, касающегося специфики реализации алгоритмов учета производители автоматизированных систем не предлагают. Преимущества используемых технологий если и являются положительным элемен-
том, то только для самих производителей — для конечного потребителя технологии производства самих АСБУ не играют никакой роли, так как они напрямую не сталкиваются с инструментарием разработки. Рассмотрение полноты отчетности и интерфейсных элементов как конкурентного преимущества выглядит несколько натянуто, поскольку наличие полной отчетности и удобств интерфейса должно быть общим местом, а не подчеркиваемым преимуществом. Возможности изменения — это то, что действительно может служить серьезным положительным качеством АСБУ. Однако эти возможности из-за плохой документации часто остаются только декларацией производителей, а не действительным качеством системы. Вероятно, производители не раскрывают внутреннее устройство своих систем из-за желания получить дополнительную прибыль на сопровождении. Дополнительные удобства в большой степени оказываются излишними в конкретном окружении в присутствии других программ — редакторов, архиваторов, файловых диспетчеров, почтовых служб и т. д., поэтому не могут рассматриваться как особое свойство, заслуживающее оплаты.
При очевидной рекламной направленности характеристик систем у разработчиков, во многих случаях проявляется один общий принцип, который формулируется как «учет требований пользователей». Но при более подробном рассмотрении документации и самих систем можно обнаружить,
*Как правило, подчеркивается использование объектно ориентированного программирования и самых новых веяний в этой области. В отношении СУБД обычно подчеркиваются их отказоустойчивость, постреляционность, возможности репликации данных и т. п. Часто подчеркиваются их оптимизация в отношении поддержки транзакций и встроенные аналитические возможности. Построенная таким образом реклама обычно вызывает противоречивое впечатление: если используемая СУБД обладает такими замечательными свойствами, то проще приобрести только СУБД, поскольку она и так обеспечит потребности предприятия.
**Обычно специально оговаривается реализация тех отчетов, которые введены регулирующими органами незадолго до выпуска очередной версии АСБУ и могут отсутствовать у конкурентов. В частности, такой отчетностью в настоящее время объявляется финансовая отчетность по МСФО.
***Относительно МСФО следует подчеркнуть сугубо рекламный, а не существенный характер заявлений о соответствии ПО этим стандартам, поскольку эти стандарты регламентируют не вид отчетов, а принципы раскрытия информации, соблюдение которых зависит исключительно от добросовестности и намерений руководства, а не от ПО.
Таблица 2
Характеристика разделов рекламных описаний автоматизированных систем
Раздел Характеристика
Постановка задачи Состоит из списка автоматизированных рабочих мест (АРМ), приблизительно соответствующих должностям бухгалтерии предприятия. Анализ документации и конкретных автоматизированных систем показывает, что представление о задаче автоматизации деятельности предприятий как о списке должностей с их обязанностями является базовым элементом обоснования архитектуры при проектировании АСБУ
Интерфейс Тонкости работы специалиста, которые по замыслу разработчиков должны облегчить и упростить ее. Например, защита от некорректного ввода, автоматическое заполнение списковых значений и т. п.
Описание преимуществ используемых технологий Перечисление используемых языков и парадигм программирования, СУБД и их надстроек*
Объем отчетности Заявление производителей о более или менее полном соответствии списка встроенных в АСБУ отчетов списку требуемых для государственных органов, например, ФНС России, Пенсионного фонда РФ и др. В отношении некоторых отчетов делается специальная оговорка об их готовности**
Возможности изменения Заявление производителей о параметрической и алгоритмической настраиваемости автоматизированной системы. Алгоритмическая настройка требует работы высококвалифицированного программиста. Для параметрической настройки при кажущейся простоте иногда нужна еще более высокая квалификация, так как во многих случаях АСБУ плохо документированы, а параметры влияют на алгоритм нетривиальным образом. Особо выделяется возможность настройки отчетов и форм ввода информации при помощи встроенных или дополнительных (внесистемных) средств
Дополнительные удобства Декларируются разнообразные вспомогательные средства типа внутренней электронной почты, архиваторов, административных возможностей, работы с файлами, способности к интеграции и др., которые в большей или меньшей степени дублируют сервисы операционной системы и специализированных пакетов
что учет этих требований состоит всего лишь в формальном именовании программных блоков и операций созвучно должностям и направлениям работы сотрудников предприятий. Автоматизация между тем подразумевает глубокую формализацию работы и, главное, перевод ее исполнения в автоматизированную форму при наименьших затратах. Сегодня АСБУ разрабатываются таким образом, что просто заменяют сотрудникам предприятий ручку и бумагу. Специалисты продолжают выполнять ту же самую работу, только на экране монитора, вводя данные с клавиатуры. Принципиального улучшения работы нет — есть всего лишь ускорение обычных рутинных дейс-
твий, т. е. автоматизация подменяется механизацией рутинных работ.
Подмена существующими АСБУ автоматизации механизацией имеет определенные плюсы, которые подчеркиваются производителями, однако есть и ряд минусов, которые во многих случаях приводят к тому, что эффекта от внедрения автоматизированных систем нет. Но и в тех случаях, когда плюсы перевешивают, очевидно, что руководители предприятий предпочли бы более качественную продукцию при более низких затратах.
Анализ программного обеспечения для предприятий в отношении принципов организации
АСБУ и реализации этих принципов их производителями показывает:
— отсутствует методология автоматизации бухгалтерского учета;
— автоматизированные системы представляют собой наборы слабо связанных между собой АРМ;
— безопасность систем ниже безопасности СУБД, на которых построены АСБУ;
— средства ввода-вывода информации весьма бедны и одновременно бессмысленно избыточны;
— уровень абстракции данных в средствах пост-
роения конечных рабочих мест абсолютно не отражает специфики бухгалтерского учета на предприятиях.
Характеристика организации АСБУ и их реализации приведена в табл. 3.
Особо нужно пояснить фактор безопасности систем. На практике излишняя величина и разветвленность системы прав на компоненты и операции выливается в три варианта безопасности в отношении доступа к данным: — из-за невозможности разумно воспользоваться чрезвычайно сложной системой прав
Таблица 3
Характеристика организации АСБУ
Фактор Характеристика
Отсутствие методологии автоматизации бухгалтерского учета Принципы автоматизации именно учета не сформулированы. Это приводит к неверной трактовке требований финансистов, бухгалтеров, руководства и контролирующего аппарата к автоматизированным системам. Автоматизированные системы при всех их положительных качествах не являются средством автоматизации работы потребителей. Важно также отметить, что существующие формулировки требований финансистов, бухгалтеров, руководства и контролирующего аппарата к автоматизированным системам исходят не от них самих, а от производителей АСБУ, которые в первую очередь обосновывают необходимость покупки таких систем, а вовсе не их действительную необходимость
Слабая взаимная связь автоматизированных рабочих мест Любое направление работы, любая должность рассматриваются как принципиально новый участок работы, под которую создается отдельное АРМ с собственной базой данных, собственными средствами ввода-вывода и т. д. Это приводит к непомерному дублированию информации, удорожанию требуемой аппаратуры и, самое главное, бесполезности для получения нестандартной аналитической информации, а именно получение нестандартной, нетривиальной информации должно быть главным результатом автоматизации
Пониженная безопасность систем по сравнению с безопасностью СУБД Адекватно оценить необходимые объемы прав конечных пользователей из-за непомерной сложности самой АСБУ и многократного дублирования информации невозможно. Это приводит к необходимости предоставления конечным пользователям излишних прав, что резко снижает безопасность системы, несмотря на то, что используемая СУБД может иметь эффективные средства разделения доступа к данным
Бедность и избыточность средств ввода-вывода информации Практически единственным интерфейсом ввода-вывода служит консоль компьютера, а автоматизированные средства, не предполагающие участия специалиста во вводе-выводе, производителями обычно не только не предлагаются, но могут даже ограничиваться. Одновременно разработчики не скупятся на создание разнообразных интерактивных модулей, предназначенных для ввода-вывода однотипной информации. Это приводит к бессмысленной работе специалиста по вводу-выводу информации, которая, по сути, представляет собой запуск вручную трансляторов форматов с последующей проверкой правильности трансляции, либо откровенно повторному вводу информации
Несоответствие уровня абстракции данных специфике учета Алгоритмы обработки данных пишутся на низкоуровневых языках программирования. Ни бухгалтер, ни финансист фактически не могут проверить правильность реализации алгоритмов работы, а тем более изменить их, так как алгоритмы описываются в терминах файлов, блоков, таблиц и т. п. Это приводит к неспособности конечных потребителей АСБУ эффективно использовать эти системы в непрерывно изменяющейся обстановке без постоянного сопровождения разработчиками. Производители выполняют доработки и настройки на очень низком программном уровне, что требует неоправданно больших усилий и расходов с их стороны, а зачастую они неспособны к эффективному сопровождению своих продуктов из-за неадекватного уровня абстракции данных
администраторы вынуждены предоставить всем конечным пользователям АСБУ избыточные права, что делает систему уязвимой для злонамеренных действий, прежде всего сотрудников предприятия;
— права относятся к крайне узким операциям, и для каждой операции предприятие нанимает отдельных специалистов. Сотрудников становится много, и каждому предоставляются права, касающиеся только его узких должностных полномочий. В этом случае стоимость содержания такого количества сотрудников не оправдывает приобретения АСБУ, так как при большом количестве сотрудников, они могут эффективно выполнить свой узкий участок работы и без автоматизированной системы;
— разделение доступа реализуется средствами АСБУ, и пользователи прикладной системы не являются пользователями на уровне СУБД или ОС, поэтому доступ к данным осуществляется от имени системного администратора с полными правами, т. е. при работе с данными в обход автоматизированной системы, администраторы работают без ограничений, поэтому как и в первом случае, система уязвима при злонамеренных действиях сотрудников предприятия. В целом существующее бухгалтерское ПО разрабатывается путем прямого переноса бумажных и ручных технологий работы на вычислительную технику. Глубокого анализа внутренних закономерностей этой работы и возможностей ее автоматизации не производится. Ускорение работы достигается не за счет повышения эффективности организации работы, а за счет введения в работу все более быстродействующей техники. По сути, работа предприятий, и самих разработчиков программ становится все менее эффективной, что компенсируется простым экстенсивным наращиванием технологических мощностей вычислительной техники.
В этих условиях важно рассмотреть существующие методические аспекты автоматизации работы предприятий, кем бы она ни проводилась. В простейшем случае вся методика укладывается в копирование учетной программы на компьютеры предприятия и последующей работе с ней. При хорошо поставленной методике автоматизации выполняются обследование предприятия, выбор программного продукта и его адаптация, пробная,
а затем штатная эксплуатация. Словом, вариантов автоматизации много, но в любом случае при автоматизации работы всегда подразумевается автоматизация той или иной технологии учета. Несмотря на то, что технология бухгалтерского учета является в большой мере регламентированной законодательно сферой деятельности, тем не менее особенности конкретного предприятия, прежде всего количество и квалификация персонала, а также область деятельности предприятия, объемы операций, длительность работы и даже тип собственности приводят к существенным различиям в технологии учета и технологии автоматизации. Поэтому автоматизация всегда предполагает исполнение некоторых принципов и основанную на них методику.
Существующие представления об автоматизации работы предприятий состоят в подразумеваемом предположении, что сущности и категории учета сопоставляются с сущностями и категориями автоматизированных систем или СУБД. Примеры таких сопоставлений приведены в табл. 4.
На практике в подавляющем большинстве случаев используется вариант отображения, приведенный в варианте 5 табл. 4. Из таблицы также следует, что это не единственный способ организации АСБУ и автоматизированная система может создаваться на базе ПО разных иерархических уровней: на уровне базового ПО, на уровне СУБД и на уровне прикладного ПО (такого примера в табл. 4 нет).
Приведенные в табл. 4 примеры сопоставления сущностей и категорий учета с сущностями и категориями файловых систем или СУБД задают некоторые варианты программной реализации автоматизированных систем. Таких вариантов в общем случае может быть больше, а конкретно выбранный способ сопоставления сущностей является технологией автоматизации учета.
Таким образом, место технологии автоматизации учетной работы среди технических и учетных дисциплин находится на стыке теории учета и теории файловых систем, либо СУБД и технологию автоматизации учетной работы можно рассматривать как связующее звено теории учета и теории файловых систем либо систем управления базами данных.
Анализ внутреннего устройства ряда АСБУ показывает, что главной задачей при разработке
Таблица 4
Некоторые способы отображения учетных категорий в категориях ПО
Учетные категории Способ отображения в хранимые программные объекты
Первый вариант ПО с файловым представлением непосредственно на уровне файловой системы ОС без использования СУБД
Лицевой счет Файл — таблица из двух столбцов — дата-время операции и остаток после операции. Имя файла — номер лицевого счета с меткой (метками) о состоянии счета (закрытый, блокированный, арестованный и т. п.)
Балансовый счет Каталог операционной системы, содержащий файлы лицевых счетов, относящихся к данному балансовому счету. Имя каталога — номер балансового счета
Проводка Файл — таблица из четырех столбцов — дата-время операции, номер счета по дебету, номер счета по кредиту и сумма операции. Имя файла зарезервировано
Отчет Исполняемый файл, выполняющий обработку файлов лицевых счетов и файла проводок
Второй вариант ПО с файловым представлением непосредственно на уровне файловой системы ОС без использования СУБД
Лицевой счет Каталог файловой системы, содержащий файлы частей проводок. Имя каталога — номер лицевого счета с меткой (метками) о состоянии счета (закрытый, блокированный, арестованный, текущий остаток и т. п.)
Балансовый счет Нет хранимого представления. Является совокупностью каталогов лицевых счетов, относящихся к данному балансовому счету
Проводка Совокупность двух файлов, находящихся в каталогах лицевых счетов, относящихся к данной проводке. Каждый файл содержит сумму проводки сообразно положению счета в дебете или кредите проводки. Имя файла — дата-время операции
Отчет Исполняемый файл, выполняющий обработку каталогов лицевых счетов и файлов проводок
Третий вариант ПО с файловым представлением непосредственно на уровне файловой системы ОС без использования СУБД
Лицевой счет Нет хранимого представления. Является результатом выполнения отчета
Балансовый счет Нет хранимого представления. Является результатом выполнения отчета
Проводка Файл — таблица из четырех столбцов — дата-время операции, номер счета по дебету, номер счета по кредиту и сумма операции. Имя файла зарезервировано
Отчет Исполняемый файл, выполняющий обработку файлов лицевых счетов и файла проводок
Четвертый вариант ПО с табличным представлением на уровне реляционной СУБД
Лицевой счет Таблица СУБД, содержащая два столбца — дату-время операции и остаток после операции. Имя таблицы — номер лицевого счета с меткой (метками) о состоянии счета (закрытый, блокированный, арестованный и т. п.)
Балансовый счет Таблица СУБД, содержащая столбец с номерами балансовых счетов, на которых есть лицевые счета. Имя таблицы зарезервировано
Проводка Таблица СУБД, содержащая четыре столбца — дату-время операции, номер счета по дебету, номер счета по кредиту и сумму операции. Имя таблицы зарезервировано
Отчет Процедура СУБД, выполняющая обработку таблицы лицевых счетов, таблицы балансовых счетов и таблицы проводок
Пятый вариант ПО с табличным представлением на уровне реляционной СУБД
Лицевой счет Таблица СУБД, содержащая три столбца — номер лицевого счета с меткой (метками) о состоянии счета (закрытый, блокированный, арестованный и т. п.), дату-время операции и остаток после операции. Имя таблицы зарезервировано
Балансовый счет Таблица СУБД, содержащая столбец с номерами балансовых счетов, на которых есть лицевые счета. Имя таблицы зарезервировано
Проводка Таблица СУБД, содержащая четыре столбца — дату-время операции, номер счета по дебету, номер счета по кредиту и сумму операции. Имя таблицы зарезервировано
Отчет Процедура СУБД, выполняющая обработку таблицы лицевых счетов, таблицы балансовых счетов и таблицы проводок
Шестой вариант ПО табличного представления на уровне реляционной СУБД
Лицевой счет Нет хранимого представления. Является результатом выполнения отчета
Окончание табл. 4
Учетные категории Способ отображения в хранимые программные объекты
Балансовый счет Нет хранимого представления. Является результатом выполнения отчета
Проводка Таблица СУБД, содержащая четыре столбца — дату-время операции, номер счета по дебету, номер счета по кредиту и сумму операции. Имя таблицы зарезервировано
Отчет Процедура СУБД, выполняющая обработку таблицы проводок
Седьмой вариант ПО таблично-объектного представления на уровне объектной СУБД
Лицевой счет Объект таблицы балансовых счетов, содержащий информацию о номере лицевого счета с меткой (метками) о состоянии счета (закрытый, блокированный, арестованный и т. п.), о дате-времени операции и об остатке после операции
Балансовый счет Таблица СУБД, содержащая столбец с номерами балансовых счетов, а каждая запись содержит в этом столбце совокупность объектов, являющихся лицевыми счетами. Имя таблицы зарезервировано
Проводка Таблица СУБД, содержащая четыре столбца — дату-время операции, номер счета по дебету, номер счета по кредиту и сумму операции. Имя таблицы зарезервировано
Отчет Процедура СУБД, выполняющая обработку таблицы балансовых счетов и таблицы проводок
ПО производители считают соблюдение максимального соответствия набора таблиц и операций использующимся в бухгалтерии технологиям учета, в частности категориям счета и проводки. В первую очередь это соответствие соблюдается в принципиальном строении баз данных.
База данных бухгалтерских автоматизированных систем содержит следующие главные таблицы:
— таблицу счетов, содержащую значения остатков и оборотов по счетам по датам и соответствующую книгу регистрации счетов (на предприятиях — регистры бухгалтерского учета);
— таблицу проводок, содержащую список всех проводок и соответствующую журналам документов дня.
По сути, список главных таблиц не варьируется, так как в этой части все разработчики стремятся следовать регламентированной законодательно технологии учета, т. е. этот список таблиц определяется технологией учета. Вспомогательные таблицы представлены следующими таблицами:
— таблицей документов, содержащей список документов, послуживших основанием для проводок;
— справочником клиентов, содержащим информацию о клиентах;
— другими справочниками.
Список вспомогательных таблиц в большой мере зависит от автоматизированной системы и, в отличие от главных таблиц, определяется технологией автоматизации.
Для выполнения бухгалтерской проводки требуется следующий список операций базы данных:
— добавление строки в таблицу проводок;
— добавление строки в таблицу счетов со значением счета по дебету;
— добавление строки в таблицу счетов со значением счета по кредиту;
— обновление информации во вспомогательных таблицах.
Первые три операции являются обязательными, так как они реализуют технологию бухгалтерского учета, а четвертая относится к конкретным реализациям. Четвертая операция в основном обновляет информацию, необходимую для отчетов, не требующих серьезных расчетов, так как такая информация вводится в базу данных быстро, не замедляя ввода в главные таблицы.
Соответствие принципу двойной записи, действующему в бухгалтерии, состоит в том, что каждой операции соответствуют две строки в таблице остатков на счетах — для дебетового и кредитового счетов, участвующих в операции. А список строк, относящихся к одному счету, взятый вместе со списком проводок по этому счету, представляет собой учетную карточку счета. По аналогичному принципу реализован учет материалов, ценных бумаг и т. д.
Над технологией учета надстраиваются разные технологии автоматизации — группировка проводок в пакеты операций, массовый ввод строк в таблицы, отчетность и др. Информация в таблицах обычно делится по сферам деятельности — складской учет, финансовый учет, учет материальных ценностей и т. д. — путем разделения таблиц: для каждого вида деятельности вводится или отдельный набор файлов, или отдельный набор таблиц СУБД.
Автоматизация учетной работы имеет определенные положительные качества и сопровождается определенными сложностями. И те, и другие являются результатом факторов, проявляющихся на двух уровнях: во-первых, это законодательно регламентированная технология самого бухгалтерского учета, во-вторых, это исполнение бухгалтерского учета в той или иной автоматизированной системе.
Положительные качества, обусловленные технологией учета, представлены следующим списком:
— полное соответствие бумажной технологии учета;
— возможность быстрого получения информации о состоянии счетов на любую дату;
— возможность получения основных отчетов только по таблице счетов, не обращаясь к другим таблицам;
— технология автоматизации может (в предположении качественного исполнения автоматизированной системы) дополнить список положительных качеств следующими пунктами: быстрота получения информации, безошибочность и быстрота при внесении изменений в базу данных.
Фактически все положительные качества, кроме первого, являются следствием большей производительности компьютеров по сравнению с ручной работой. Принципиального улучшения работы за счет именно автоматизированной системы нет.
Типичные внутренние проблемы автоматизированных систем обычно относят к плохой реализации или плохой постановке технологии исполнения. Однако проблемы могут быть обусловлены технологией учета, а не реализацией. Из внутренних проблем, обусловленных технологией учета, можно выделить следующие:
— возможность нарушения целостности информации в базе данных;
— необходимость процедур восстановления информации в базе данных;
— большая длительность транзакции при выполнении проводки;
— необходимость распределенной базы данных.
Эти проблемы являются прямым следствием переноса бумажной технологии в электронный
вид. Но то, что является приемлемым при бумажной технологии, может оказаться принципиально неприемлемым в автоматизированной, и это может быть обусловлено именно технологией учета, а не технологией автоматизации. Перечисленные проблемы, обусловленные технологией учета, разработчики пытаются преодолеть за счет технических решений, однако это приводит к созданию неоправданно сложной в реализации и работе системы, в которой, тем не менее, учетно-технологические проблемы оказываются неустраненными.
Как и в случае положительных качеств, список внутренних проблем можно дополнить проблемами, обусловленными технологией автоматизации. Эти проблемы очень специфичны для каждой системы, поэтому трудно выделить какие-то общие. Если отбросить прямые ошибки, среди которых очень серьезной является непредусмотренность электронно-цифровой подписи, то чаще всего встречаются следующие:
— слишком большое количество требуемых подтверждений при ручном вводе информации;
— недостаточная настраиваемость АСБУ на технологию учета конкретного предприятия;
— излишняя сложность АСБУ и неочевидность действий в ней, которые нужно предпринять для выполнения какой-либо бухгалтерской или финансовой операции;
— выполнение действий, которые можно реализовать автоматически, требуют обязательного участия специалиста.
Характеристика внутренних проблем АСБУ приведена в табл. 5.
Необходимо отметить, что перечисленные проблемы обычно не являются критичными для потребителей, так как часть из них маскируется под привлекательным внешним видом АСБУ, часть незаметна благодаря высокому быстродействию аппаратуры, часть проходит мимо внимания потребителей из-за их некомпетентности в технических вопросах. Однако при больших объемах обрабатываемой информации эти недостатки делают автоматизированные системы непригодными для использования.
Кроме этих недостатков есть еще недостатки, присущие не столько технологии учета или технологии автоматизации, сколько самому подходу
Таблица 5
Характеристика внутренних проблем АСБУ
Проблема Характеристика
Возможность нарушения целостности информации в базе данных Информация в таблицах счетов и проводок должна быть взаимно согласованной по достаточно нетривиальным правилам, а согласование может по каким-либо причинам быть нарушено. Эту проблему разработчики пытаются преодолеть введением разнообразных, исполняемых автоматически, правил поддержки целостности базы данных. Однако алгоритмы этих правил существенно сложнее обычной для базы данных ссылочной целостности. Поэтому автоматическое их исполнение требует отвлечения значительных аппаратных ресурсов для несущественной относительно учета задачи. Кроме того, сложность алгоритмов поддержки целостности данных вынуждает разработчиков помещать их выполнение не на СУБД, а на прикладную систему, поэтому всегда остается возможность прямого ввода некорректной информации в базе данных, т. е. эта проблема фактически оказывается неустранимой
Процедуры восстановления информации в базе данных В связи с возможностью нарушения целостности информации разработчики вынуждены предусматривать на уровне прикладной программы специальные процедуры восстановления информации, так как поддержание целостности данных возлагается на прикладную систему. Поэтому, даже если СУБД обладают возможностями по восстановлению информации после сбоев, они оказываются неиспользуемыми, т. е. дорогостоящие СУБД используются неэффективно, а АСБУ становятся сложнее и дороже. Хотя обычно необходимость процедур восстановления информации разработчики мотивируют низким качеством СУБД, но в действительности этот недостаток обусловлен самой технологией учета, поэтому при автоматизации именно такой технологии учета он оказывается вообще неустранимым
Большая длительность транзакции при выполнении проводки Из-за большого числа таблиц, которые затрагиваются при выполнении транзакции, так как каждая транзакция на время выполнения блокирует задействованные таблицы. Разработчики фактически не могут преодолеть этот недостаток без изменения технологии учета, и он компенсируется увеличением быстродействия аппаратуры. Отсюда возрастает стоимость приобретения и эксплуатации средств автоматизации
Необходимость распределенной базы данных Из технологии учета вытекает обязательное размещение информации в нескольких главных таблицах. Это может не рассматриваться как недостаток, однако наличие нескольких ключевых таблиц, очевидно, требует более сложной автоматизированной системы и более мощной СУБД. Поэтому распределенная база данных приводит, как и длительность транзакции, к возрастанию стоимости приобретения и эксплуатации средств автоматизации
Слишком большое количество требуемых подтверждений при ручном вводе информации Во многих случаях для действительного начала запрошенной операции необходимо выполнить множество подтверждающих действий. Когда таких подтверждений становится неоправданно много, они делаются бездумно, чисто автоматически, но так как каждое подтверждение, по сути, является вводом дополнительной информации, то такой автоматизм при их выполнении порождает ошибки (специалист, не глядя, может ввести неверную информацию). Эти ошибки, естественно, возлагаются на исполнителей, хотя они провоцируются плохим исполнением алгоритма ввода информации
Недостаточная настраиваемо сть Это брак разработчиков АСБУ. Данная проблема присутствует у большинства производителей
Излишняя сложность автоматизированной системы и неочевидность действий Часто АСБУ содержит неоправданно большое количество разнообразных объектов: файлов, таблиц, модулей, настроечных параметров, операций, прав, представлений и т. д. — одно элементарное в финансовом или бухгалтерском смысле действие разбросано по большому количеству пунктов меню, настроечных параметров, таблиц, файлов и т. д., которые приходится пройти для выполнения какой-либо бухгалтерской операции. Обычно излишнюю сложность разработчики представляют как разнообразие функций, т. е. как положительное качество, но в действительности это просто непонимание разработчиками той области, которую они автоматизируют. Часто, как и недостаточная настраиваемость, это является браком производителей
Обязательное участие специалиста при выполнении действий Это так называемый учет требований пользователей. Такое свойство АСБУ корректным назвать нельзя, так как это выхолащивание самой идеи автоматизации
к автоматизации. Наиболее коротко эти недостатки можно обозначить как отсутствие критериев правильности при создании автоматизированной системы для предприятия.
Важные моменты в функционировании АСБУ, на которых следует остановиться подробнее, — это подсистемы ввода и вывода информации.
Некоторые разработчики ПО при организации ввода информации придерживаются двух принципов:
— соответствие экранных форм бумажным документам;
— участие специалиста.
Максимальное соответствие экранных форм
бумажным документам декларируется как главный принцип, используемый разработчиками при организации ввода. Мотивировка этого принципа следующая: работникам, привыкшим к тем или иным бумажным документам, будет легко работать со знакомыми изображениями на экране. Этот принцип стимулирует разработку однотипных модулей ввода разных документов, но содержащих практически одну и ту же информацию. При этом разработка модулей для альтернативных каналов ввода отодвигается на второй план или вообще не ведется. С первым принципом тесно связано и участие специалиста, для удобства которого декларируется и обеспечивается соответствие экранных форм бумажным документам.
Несмотря на кажущуюся правильность соотношения принципов организации ввода информации, в действительности главным принципом является участие специалиста, а не соответствие экрана и бумаги. Причин этого главенства две:
— полностью автоматический ввод вызывает неприятие руководства предприятий, так как обычно внутренние правила компании предусматривают ответственность персонала за те или иные изменения в базе данных, поэтому настоящим главным мотивом выбора принципов ввода информации является персонификация ответственности за вводимую информацию, что выражается в вовлечении специалиста;
— мотивировка принципом соответствия экрана и бумаги, вообще говоря, в современных условиях уже давно неактуальна, так как экранное представление очень часто несопоставимо с бумажным, а привыкание к экранной форме не
вызывает абсолютно никаких неудобств, более того, в современных условиях для специалистов чаще первичным является именно экранный образ документа, а не бумажный.
Несмотря на внешнюю полезность таких принципов ввода информации, можно утверждать, что они неэффективны, так как возведение участия специалиста в ранг принципа фактически делает бессмысленной саму идею автоматизации работы, т. е. автоматизация, по сути, вместо снижения объема рутинной работы заменяет ее другой, возможно, более рутинной, одновременно обеспечивая занятость и доходы разработчиков автоматизированных систем. Отсюда понятна приверженность разработчиков этим принципам организации ввода информации.
Кроме этих двух принципов, практически, во всех АСБУ присутствует еще один принцип, не афишируемый разработчиками, но приводящий к тому, что подсистема ввода информации занимает излишне большую долю системы. Это неоправданно избыточное количество модулей ввода информации, которое выражается в том, что для ввода однотипной информации в системе присутствует несколько модулей ввода, хотя в подавляющем числе случаев достаточно одного параметризуемого модуля.
Обычно разработчики говорят о шлюзах во многие системы, перечисляя множество конкретных форматов данных для обмена с другими системами. Это должно представить неоправданную избыточность ввода как несомненное достоинство автоматизированной системы. Однако принцип дублирования ввода неудачен, так как есть два альтернативных варианта ввода информации, каждый из которых эффективнее многошлюзовых подсистем ввода.
Первый вариант состоит в вынесении трансляторов форматов за пределы учетной системы. В системе остается только модуль ввода данных, представленных в (выбранном) стандартном формате, а задача приведения данных в других форматах к стандартному ложится на внешние по отношению к системе модули. Таким способом легко преодолевается принципиальная неспособность встроенных шлюзов вводить данные неизвестных разработчикам форматов. Более того, именно так и поступают на практике пользователи: когда у них возникает потребность вводить данные но-
вого формата, разрабатывается внешний модуль, приводящий данные нового формата к одному из предусмотренных в системе, который, по сути, выступает в роли стандартного формата.
Второй вариант основан на том, что в действительности существуют только четыре типа форматов обмена табличной информацией и их комбинация:
— запись с фиксированным положением полей;
— запись с фиксированной последовательностью полей;
— апись с идентификаторами полей;
— запись смешанного типа.
Эти типы форматов легко параметризуются, откуда следует заведомая достаточность одного параметрического модуля ввода. Поэтому, если учесть действительную потребность в системах ввода, то становится очевидным, что многократное дублирование модулей ввода и превращение их в достоинство — это только способ скрыть неумение проектировать эффективные системы.
Особенно необходимо отметить, что в некоторых учетных системах отсутствует такой элемент, как электронная цифровая подпись на документах, создаваемых модулями ввода, входящими в состав АСБУ. Это не только противоречит принципу персонификации ответственности за вводимую информацию, но и ставит работоспособность автоматизированных систем в зависимость от честности и компетентности администраторов.
Рассмотрим основные принципы вывода информации, главным из которых является представление разработчиков, что вывод информации
— это исключительно распечатка отчетов, хотя вывод информации — это на самом деле вообще любой вывод информации за пределы автоматизированной системы. Например, если предприятие передает в банк платежное поручение или другой финансовый документ, это тоже является выводом информации, так же, как и передача заказчику счета за товар или услуги по электронной почте или по факсу без распечатки на бумаге. Причиной такого узкого взгляда на вывод информации также является исходная бумажная технология, так как в бумажной технологии любой передаваемый документ имеет силу только при наличии подписи
ответственного. Соответственно, в электронной технологии передаваемый документ отождествляется с бумажным документом, который должен быть распечатан, чтобы на него можно было поставить подпись.
Аналогично организации ввода информации имеет место и не афишируемый разработчиками принцип дублирования вывода, к которому полностью применимы все соображения дублирования ввода.
Недостаточность принципа организации вывода информации как распечатки отчетов очевидна, но после принятия закона об электронной подписи она становится еще одним принципиальным недостатком многих существующих автоматизированных систем. Электронную подпись можно было автоматически проставлять уже давно, но в существующих системах это зачастую вообще не предусмотрено. Тем самым еще раз подтверждается, что сегодняшние АСБУ являются полностью доверенными честности администраторов, на которых ответственность за те или иные действия обычно официально не возлагается.
Поскольку АСБУ внедряются для улучшения работы предприятия, действующего в конкретной законодательной среде, разработчики стремятся максимально учесть правила учета в своих системах. Более того, обычно сами правила бухгалтерского учета рассматриваются как требования пользователей, которые необходимо учесть при создании автоматизированной системы. Это приводит к тому, что законодательные акты и внутренние инструкции становятся неотъемлемыми элементами автоматизированных систем, и любое изменение законодательства заставляет руководство предприятий приобретать новые версии автоматизированных систем либо просто новые системы. Не уточняя, кому выгодна такая ситуация, можно констатировать, что основывать принципы создания автоматизированных систем на законодательстве методологически неверно, так как законодательство и автоматизация относятся к не связанным друг с другом сферам деятельности. Очевидно, что автоматизация должна придерживаться принципа настраиваемости на любое законодательство.
Таким образом, в сегодняшних условиях имеет место ситуация, когда разработчики программного обеспечения для предприятий при
создании АСБУ декларируют реализацию требований потребителей. Но сами эти требования на самом деле не сформулированы, поэтому производители автоматизированных систем подменяют их требованиями вообще к любой программной продукции, то есть реализация именно учетной работы остается только пожеланием. Несмотря на то, что даже в таком виде автоматизированные системы дают определенный положительный результат, тем не менее во многих случаях требования к программной продукции оказываются в противоречии конкретно с технологией учетной работы, что ухудшает, а не улучшает саму работу.
Результатами неопределенности, что же именно автоматизируют бухгалтерские системы, являются:
— громоздкость и неэффективность автоматизированных систем;
— неоправданные финансовые затраты предприятий на автоматизированные системы;
— неоправданные трудовые затраты персонала предприятий для работы в АСБУ.
Из этих соображений вытекает закономерный вывод, что вопросы автоматизации бухгалтерской деятельности требуют серьезного научного исследования, и их нельзя рассматривать только как исполнение разработчиками автоматизированных систем готовой поставленной задачи, так как сама
задача еще не поставлена. Подробнее последствия неопределенности предмета автоматизации рассмотрены в табл. 6.
Несмотря на то, что приведенные отрицательные последствия взаимосвязаны, как это подчеркнуто в табл. 6, тем не менее имеет смысл выделить каждое, так как такое выделение иллюстрирует многоплановость воздействия на работу предприятия неверных решений в отношении автоматизации.
Необходимо подчеркнуть, что задачей научного изучения вопросов автоматизации является не выявление наилучшей автоматизированной учетной системы среди существующих или гипотетических систем, а создание теоретической модели технологии автоматизации в области учета. Эта модель будет объективным критерием качества при оценке и выборе конкретной автоматизированной системы от того или иного разработчика ПО.
При внедрении АСБУ зачастую затраты увеличиваются, а реальная отдача от вложенных средств уменьшается. Решение задач, возлагаемых на АСБУ, оказывается более дешевым в рамках общей автоматизации работы при помощи текстовых и табличных редакторов, простых баз данных, диспетчеров задач и т. д. Тем не менее поскольку уже невозможно отказаться от
Таблица 6
Характеристика последствий неопределенности предмета автоматизации
Фактор Характеристика
Громоздкость и неэффективность автоматизированных систем Из-за отсутствия четко поставленной задачи разработчики АСБУ стараются перенести бумажные технологии работы в электронный вид. Любая, по-новому сформулированная задача реализуется как самостоятельная подсистема, это порождает избыточность модулей обработки информации*. Эффективность АСБУ измеряется объемом занимаемого места на диске и степенью разветвленности набора файлов, что дополнительно требует неоправданно дорогостоящей и производительной аппаратуры
Неоправданные финансовые затраты По сути, это продолжение громоздкости и неэффективности АСБУ Заказчики вынуждены оплачивать ненужные усилия разработчиков, так как они не могут объективно оценить уровень действительной необходимости затрат разработчиков. Кроме того, заказчики вынуждены приобретать неоправданно дорогую технику и системные программные средства для работы прикладных автоматизированных систем
Неоправданные трудовые затраты персонала Это также продолжение громоздкости и неэффективности АСБУ. Непродуманность операций и слишком малое количество действий, не требующих участия специалистов, приводит к большому объему ненужной ручной работы
* В подавляющем большинстве случаев любая новая задача является вариантом уже имеющейся. Возникает необходимость постоянных переносов данных между обрабатывающими модулями, проверок их согласованности, а часто и повторного ввода. В свою очередь для минимизации ошибок специалистов разрабатываются системы с множеством бессмысленных подтверждений, которые из-за их неоправданной избыточности игнорируются специалистами, а, значит, количество ошибок ввода не снижается. Отдельные элементы бумажной организации противоречат электронной организации работы.
автоматизированных систем, предприятия для повышения отдачи от них должны сформулировать систему критериев для оценки качества бухгалтерских автоматизированных систем, реализации в них оптимальной технологии бухгалтерского учета. Эти критерии должны отражать специфику учетной работы и задавать обязательные элементы АСБУ. Таким образом, для того чтобы предприятия могли сформулировать свои требования к автоматизированной системе, необходимо разработать и принять стандарт такой системы.
Список литературы
1. Гаген А. Бухгалтерские программы. Обзор основных бухгалтерских программ. URL: http:// www. financial-lawyer. ru/newsbox/document/165-528055.html.
2. Информационные системы и технологии управления: учеб. / под ред. Г. А. Титоренко. М.: ЮНИТИ-ДАНА, 2010. 591 с.
3. Обзор регионального рынка бухгалтерских программ. URL: http://www. auportal. ru/eco-nomics/ekbuhprog. php.
