Клуб разработчиков программных систем

Истории Про Сервис

О проекте | Темы | Статьи | Рейтинги |

Бухгалтерские конструкторы:перейдёт ли количество в качество?

Сергей Трофимов

PCWeek/RE №35/2003

В поисках идеала

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

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

Средства малой автоматизации

        А как быть малым предприятиям, которые только начинают свой бизнес? На какую программу обратить внимание? Многие, не задаваясь этим вопросом, просто создают нечто небольшое, но свое, при помощи инструментов, которые практически всегда под рукой, — Access или FoxPro. Сам бухгалтер дальше электронной таблицы обычно не забирается, но системный администратор, к примеру, уже может заняться несложной автоматизацией на одном из знакомых ему инструментов.

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

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

Коструктор... А что внутри?

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

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

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

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

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

Как же без отчетов?

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

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

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

.NET на службе у автоматизаторов

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

        Представим, что мы решили разработать такой конструктор сейчас, когда в нашем распоряжении есть технология .NET. Мы создаем описанную структуру ядра и предоставляем программистам интерфейсы доступа и библиотеки, а они при помощи стандартных языковых средств С# или VB.NET строят прикладные решения. При этом разработчики Visual Studio .NET уже сняли многие проблемы, связанные с совместимостью, организацией распределенных систем, обменом данными между приложениями, доступом к различным СУБД и обновлением клиентских модулей (при использовании ASP.NET достаточно стандартного Internet Explorer). Расширение функциональности производится несложным добавлением в систему новых сущностей, а настройка бизнес-процессов на основе типовых проводок доступна в любой момент самому пользователю. Все вносимые сущности унифицированы, поэтому их легко могут использовать другие разработчики, а встроенная в .NET концепция сборок позволит не задумываться о возможном нарушении работоспособности системы при пересечении имен.

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

Что дальше?

        Сейчас разработчики конструкторов идут примерно таким путем, правда, с переменным успехом. Возможно, это происходит именно потому, что большинство систем создавалось до появления таких средств разработки, как Microsoft Visual Studio.NET, и программисты обязаны поддерживать совместимость со старыми системами. Этот многолетний багаж больше не помогает, а все сильнее тянет назад, создавая очередные трудности в автоматизации предприятий. Может быть, настало время на основе полученного опыта сделать нечто новое, как поступила компания Microsoft, предложив С#?

Подбор доменного имени
1. Введите ключевые слова
1
2
3
пример: mama
myla
ramu
2. Отметьте доменные зоны:
.ru
.su
.com
.net
.org .info
.biz
все зоны

Надежный хостинг!
 Освобождающиеся домены

Статьи по теме:

Бухгалтерские конструкторы:перейдёт ли количество в качество?
CASE-мышление: вы готовы программировать иначе?
Когда прекращать тестирование программ?
Методика создания программного обеспечения для систем управления предприятиями с использованием типо

Связанные темы:
Автоматизация
| 1 |

Имя : Man 09/01/2004 11:26
Сообщение:
1. Упоминание VS.NET вместо ссылки на платформу (.NET) мне кажется ущемляет интересы других фирм-разработчиков средств разработки под данную платформу (Borland, например, но и не только).
2. Не вижу, чем появление новой платформы принципиально влияет на проблему разработки "конструкторов". Уже давно все, кому лень писать собственный встроеный интерпретатор пользуются интерпретатором basic-а. Да и в своих разработках тяготеют к некоторому его диалекту. Так что стандарты де-факто в этой области давно существуют.
Ответить

Имя : Vixor Город : Moscow 15/01/2004 10:01
Сообщение:
Строить "конструктор" учетных систем надо на тех же принципах,что и .NET!А еще лучше взять за основу проект Jupiter с его языком описания бизнес-процессов,а собирать систему должен тот,кто на ней будет работать(менеджер,бухгалтер и пр.),хотя не нужно исключать возможность иметь "стандартные" конфигурации.
Ответить

Имя : Vladimir 09/02/2004 21:38
Сообщение:
Помоему тема статьи - .Net forever!
И совершенно согласен с Vixor. Тут больше важен язык описания бизнес-процессов нежели реализации распределённой обработки и прочих технических проблемм. А создавать что-то новое, каждые полгода, - это привилегия microsoft. :-). Что же касается диалектов, то любая компания разрабатывала и будет разрабатывать собственные стандарты, пока не появяться открытые и общепризнанные. А когда появяться открытые и общепризнанные, опять свои собственные стандарты, поверх принятых, дабы уйти от зависимости от этих стандартов...
Ответить

Имя : некто 11/05/2004 16:44
Сообщение:
аналогично: "точка нет" для конструктора не принципиальна (хоть и полезна), точно так же как и язык описания бизнес процессов (сколько их сейчас? XPDL, WS-CDL, BPEL4WS, BPML...) мне кажется что гараздо важнее для сообщества разработчиков и пользователей: общие стандарты - и в частности сервис-ориентированная архитектура приложений (SOA)
- приложение SOA можно настраивать с помощью любых инструментов, можно создаваить единую ИС используя несколько систем различных поставщиков
Ответов: 2 Последний ответ: 23/07/2004 19:40

Имя : Semenych 29/07/2005 19:53
Сообщение:
Ага, уже были объектные системы, объектные СУБД и прочие вариации. О чем речь ведется у автора? Надо на КАЖДОЙ фирме иметь внутренних аналитиков (то есть людей с пониманием и практическим опытом системного анализа, знанием возможностей ИТ-технологий, программных средств и на них переложить задачи по запуску системы в эксплуатацию. Если учесть, что люди занимались до этого совсем другой работой - то что будут делать програмеры? какова от них будет польза? уже сейчас кол-во библиотек в средах разработки зашкаливает для неподготовленных пользователей.
Вы хотите приравнять задачу установки ЕРП-системы к задаче выбора авто или задаче энергоснабжения предприятия, а?
Ответить


| 1 |
Комментарии к статьям закрыты.

© Trofimov Sergey   http://www.caseclub.ru при цитировании ссылка обязательна.