Все новости от 17 февраля 2004 г.

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

6 октября 2003 года в PC Week Online была опубликована статья Сергея Трофимова “Бухгалтерские конструкторы: перейдет ли количество в качество?”. Эта, без всякой лести, замечательная статья привлекла наше внимание тем, что провозглашенная в ней концепция, да и большинство исходных размышлений очень созвучны взглядам производственного отдела компании “КОМПАС”, которые интенсивно воплощаются в настоящее время в новом проекте, носящем рабочее название “K.Com”.

Тем не менее есть у нас и некоторые (не слишком, наверно, существенные) замечания по тексту статьи. Имеются и комментарии. А посему, в соответствии с провозглашенным В. Г. Короленко принципом “Не могу молчать”, хотелось бы высказать на страницах PCWeek/RE свое персональное мнение по затронутым в публикации Сергея Трофимова актуальным вопросам.

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

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

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

Помимо китов вроде SAP, Oracle и PeopleSoft прекрасно существуют и менее масштабные системы: Epicor, IFS, Hansa Financials и прочая, и прочая. И даже выход на рынок делового ПО такого гиганта маркетинга (а маркетинг в конкурентной борьбе сплошь и рядом имеет большее значение, нежели качество продукта), как Microsoft, не приведет, на наш взгляд, к исчезновению основных конкурентов.

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

Конечного пользователя (бухгалтера, менеджера, руководителя предприятия) сам по себе конструктор пока еще не интересует. Ему подавай готовое решение! И разрабатывать его самостоятельно он никогда не будет (слишком сильное, наверно, слово “никогда”, но оно четко выражает наше видение ситуации). А следовательно, возникнет конкуренция между поставщиками готовых решений на базе этого гипотетического конструктора.

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

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

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

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

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

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

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

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

Из всего вышесказанного, должно быть очевидно: в отличие от Сергея Трофимова мы не верим в то, что когда-нибудь на рынке делового ПО может остаться один-единственный конструктор и ничего больше.

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

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

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

Уже в текущей версии ПО марки “КОМПАС” с помощью визуальных мастеров можно решить до 80% всех проблем, возникающих в процессе адаптации тиражного (“коробочного”) продукта. С нашей точки зрения качество конструктора и определяется в первую очередь тем, какой процент программирования в процессе внедрения ПО можно провести с помощью таких вот мастеров, то есть не прибегая к собственно программированию.

В проекте “K.Com” вопросам удобства визуальной настройки уделяется еще больше внимания. Очень может быть, что С. Трофимов придерживается аналогичного мнения, но хотелось бы четко акцентировать этот момент, упущенный в его статье.

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

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

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

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

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

Мы уже говорили о том, что это на наш взгляд слишком сильное утверждение, и разнообразие не только есть, но и пребудет вовеки. Тем не менее на практике, выбирая себе платформу для реализации перспективной версии ПО марки “КОМПАС”, мы пришли к такому же выводу. Причем пришли не умозрительно, а проведя тщательный сравнительный анализ (с разработкой прототипов) таких технологий взаимодействия удаленных объектов, как COM, CORBA, EJB и .Net.

В полном соответствии с идеями Сергея Трофимова в качестве языка программирования ядра системы (в частности, тех же визуальных мастеров) выбран C# (впрочем, на нем пользователь может разрабатывать и часть индивидуальных и отраслевых решений), а в качестве основного встроенного языка программирования — C# и/или VB.Net

Резоны, определившие наш выбор, достаточно четко сформулированы в статье “Бухгалтерские конструкторы: перейдет ли количество в качество?”. Цитируем: “...разработчики Visual Studio .Net уже сняли многие проблемы, связанные с совместимостью, организацией распределенных систем, обменом данными между приложениями, доступом к различным СУБД... Расширение функциональности производится несложным добавлением в систему новых сущностей, а настройка бизнес-процессов на основе типовых проводок доступна в любой момент самому пользователю.

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

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

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

Тем не менее были у нас и дополнительные соображения, не затронутые в цитируемом материале. Как мы уже говорили, главная нагрузка при адаптации ПО “КОМПАС” ложится не на встроенный язык программирования, а на визуальные мастера. Это означает, что выполнение входящих в комплекс программ должно заключаться в основном в интерпретации метаданных, а сие плохо сказывается на быстродействии ПО. Использование технологии .Netвообще и C# в частности позволяет обойти эту проблему.

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

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

1. Весь проблемный код реализуется средствами конструктора (т. е. должен быть описан метаданными). Исключений быть не может! Весь наш опыт показывает, что нет “неприкасаемых” проблемных частей. Иными словами в процессе внедрения может понадобиться изменение любого алгоритма, любой структуры данных. А допускать программистов пользователя в ядро нельзя.

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

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

Возможности визуальных средств конструктора должны быть таковы, чтобы 80% адаптаций производилось при помощи «мастеров». На основании таких настроек конструктор генерирует код с автоматически встроенными туда специальными “заглушками”, вместо которых программист может добавить свой собственный код, позволяющий реализовать самые сложные бизнес-процедуры. В отличие от Трофимова мы бы не отказывали человеку, занимающемуся визуальной настройкой, в звании программиста. 5.

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

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

6. Но аверса без реверса не бывает! Чем более сложные процессы реализуются за счет встроенного языка во время внедрения, тем больше человеческого участия потребуется для перехода на следующую версию тиражного ПО. Если же во время адаптации пользуются только визуальными средствами, обновление должно происходить абсолютно автоматически. Конструктор обязан включать утилиты для автоматического и полуавтоматического “переходного процесса”.

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

В завершение хочется сказать, что мы абсолютно согласны с Сергеем Трофимовым в том, что конструктор, построенный на компонентно-ориентированной технологии .Net, позволит проводить адаптацию тиражного комплекса для небольшого предприятия всего за несколько недель и не потребует изощренного программирования. И наша уверенность носит не голословный характер. Уже осуществлена сдача нескольких этапов проекта “Информационная система «Управление трудовыми ресурсами для АК АЛРОСА”, который является составной частью системы “K.Com” и реализован на языке C# в технологии .Net.

К авторам статьи, главному эксперту компании “КОМПАС” канд. техн. наук Игорю Якобсону и техническому руководителю проекта “K.Com” Илье Якобсону можно обратиться по адресам: sensr@kompac.spb.su и yaxy@compass.spb.ru соответственно.