Немного о проблемах проектирования финансовых систем, или В чем же суть инструкции № 666?
Создание систем автоматизированной обработки управленческой и учетной информации представляет собой проблему, по отношению к которой существуют самые разные точки зрения. Каждая из них базируется на множестве факторов, зависящих как от рода деятельности человека, так и от степени понимания им целей этой автоматизации.
На мой взгляд, можно выделить три основные группы участников процесса автоматизации: владельцы и руководители предприятий; сотрудники, чьи функции в результате автоматизации делегируются компьютеру (бухгалтеры, кадровики, менеджеры), и, разумеется, разработчики решений.
Желание владеть полной информацией о работе своего капитала движет первыми, мечта избавиться от гор бумажной рутины - вторыми и просто мысль о булке с маслом - третьими.
Различные запросы сводятся к единому решению: созданию автоматизированной системы.
И здесь начинается самое интересное: программист принимается учить бухгалтера, что и как вводить, что и как считать, бухгалтер же ведет активный поиск задач, неподвластных программисту. Позиция руководителя колеблется между двумя крайними точками - от полной поддержки одной из сторон до требования немедленной сатисфакции от стороны "провинившейся".
Но ведь программист не виноват в том, что стремится все формализовать, а бухгалтер - в том, что с него спрашивают доселе незнакомые вещи. Тем более не виноват руководитель, неожиданно для себя превращающийся в обыкновенного неудовлетворенного потребителя. Но так есть и так будет, пока заинтересованные лица пытаются, используя свои профессиональные навыки, решать проблемы из другой предметной области.
Каковы проблемы заказчика?
Современный руководитель хочет не просто учитывать и подсчитывать - он хочет сопоставлять и делать выводы, он борется за выживание своего бизнеса. Следовательно, ему сегодня нужен один разрез для анализа информации, завтра другой, послезавтра - третий.
Если с формированием новых документов и отчетов пользователи большинства бухгалтерских и финансовых программ теперь могут справиться самостоятельно (хотя и не без затрат времени и нервов), то с созданием, настройкой и сопровождением в системе новых бизнес-процессов, с изменением структуры хранимой информации и совершенствованием методов ее обработки дело обстоит намного хуже.
Вот тут-то на горизонте обычно появляются бравые ребята-программисты (хорошо, если среди них есть грамотный постановщик задачи) и предлагают решить любую проблему.
Чем все это чревато?
Прежде всего, конечно, новыми вложениями своих кровных в доработку эксплуатируемой системы. Если деньги на модификацию есть, встает вопрос времени. Можно перефразировать известный плакат: "Руководитель! Ты готов ждать результата 3 (4 ... n) месяцев?!".
О бухгалтере скорбно промолчу: золотой мечте пользователя работать, нажимая всего на одну кнопку, не суждено сбыться никогда. Но в силах разработчиков дать ему возможность не нажимать одну и ту же кнопку!
Возможно ли решение?
Думаю, да. Но для этого необходимо то, что определяет модный ныне термин "единое информационное пространство". Каждый разработчик трактует данное понятие по-своему. На мой взгляд, необходимыми и достаточными его признаками являются следующие.
Любой логически целостный блок данных в системе:
- вводится один раз;
- хранится в одном месте;
- сохраняет свою сущность на протяжении всего времени жизни системы;
- может участвовать в любых методах обработки и отображения информации во всем пространстве данных и функций.
Кроме того, настройка доступа к нему может быть выполнена из любой области пространства.
Что же "воплощено в камне"?
В моделировании единого информационного пространства, по сути, господствует метод создания набора подпространств, именуемых в народе "АРМами" (автоматизированные рабочие места) или приложениями, с дальнейшей консолидацией информации в центральном хранилище - обычно на сервере. Все пункты вроде бы соблюдены: и вводится единожды, и хранится... Стоп! "Вводится один раз" - для несложных структур баз данных такое утверждение чаще всего верно. Но АРМ-идеология по определению децентрализует данные, и каждый разработчик собственного АРМ упорно тянет одеяло на себя. Вот и появляются в одной системе справочники поставщиков, брокеров и подрядчиков, а вдобавок еще и юридических лиц и, вслед за этим, такие пункты меню, как "Слияние клиентов пакетное" (или интерактивное, как хотите). А коли создаются такие справочники - нет ни однократного ввода, ни уникального хранилища, а в знак памяти обработки данных как единого понятия снимем шляпы...
Конечно, на это многие возразят: "Кто так делает - тот глупец". Но поверьте: посадите Эйнштейна и Капицу решать сообща одну проблему и позвольте им обмениваться информацией с помощью одного десятка слов то результат будет схожим. Прокрустово ложе внутренних интерфейсов АРМ дает о себе знать! И чем больше объем программного продукта, тем больше встречается в нем несуразностей и тем сложнее согласовывать свои действия различным группам разработчиков. Уже реализованные понятия нарождаются вновь и вновь, мутируя до неузнаваемости.
Ну а что программисты?
Во-первых, о том, что программирование превращается из искусства в ремесло, я думаю, говорить уже не приходится. Большинство же именующих себя программистами на самом деле являются не более чем кодировщиками, благо постановщик задачи расписывает все от и до. Напрашивается прямая аналогия с проектными институтами славных советских времен - связка инженера-конструктора и чертежника. Для системы разработки АРМ этот механизм скорее всего оправдан и работает, но... Сегодняшний "чертежник" имеет высшее образование, зачастую весьма фундаментальное и качественное. Он в меру честолюбив и самолюбив. Он хочет приложить свои интеллектуальные силы к чему-нибудь нетривиальному, позволяющему гордиться собой. Вот здесь и происходит таинство зарождения малопонятного для всех остальных программного кода.
Во-вторых, требования к программистам... Но сначала пусть любопытствующий читатель сделает попытку устроиться на работу программистом в фирму, разрабатывающую "финансовый софт". Одно из требований черным по белому (или по желтому - зависит от издания) гласит: "...знание основ бухгалтерского и управленческого учета...". Я искренне рад за ребят, которым приносит удовольствие помимо чтения "родной" документации и специальной профессиональной литературы еще и разгребание гор положений и инструкций по бухгалтерскому учету. Хотя ребусов более чем достаточно и в средствах разработки, а поток этих средств имеет тенденцию увеличиваться и постоянно обновляться. Встает проблема: либо ты владеешь инструментарием и знаешь, как его использовать, либо ты в деталях можешь объяснить инструкцию № 666 от 30 февраля.
Конечно, есть гении на свете, которые глубоко владеют и двумя, и тремя областями знаний, а самое главное - могут работать на стыке этих областей. Но таких - единицы. Подобные попытки остальных выглядят несколько странно (представьте себе врача-окулиста, делающего трепанацию черепа). Как же снимается это противоречие? А очень просто: программист изучает очень узкий "клочок" проблемы и ориентируется только на него. Отсюда появляются совершенно немыслимые "специализации": один знает, как работает складской учет, другой - расчеты с поставщиками, а третий даже сделал свой, цитирую, "опердень" (операционный день банка).
Неужели все так мрачно?
Хотя для многих коллективов разработчиков все изложенное выше может показаться надуманным и чисто субъективным, рискну все же ответить на вопрос: "В чем же выход из сложившегося клубка проблем, и есть ли этот самый выход?".
До прихода полтора года назад в компанию "Цефей" мои взгляды не сильно отличались от тех, что господствуют в кругах разработчиков. Вкратце их можно сформулировать так: "Есть конкретная проблема - есть конкретное решение".
Все хорошо, но для эффективной реализации требуется досконально изучить задачу. При детальном изучении происходит выделение максимально возможного количества параметров задачи в интерфейсную часть. Причем формируется два вида интерфейсов - интерфейс с пользователем и интерфейс с другими модулями системы. При включении нового модуля в комплекс внутренние интерфейсы неизбежно костенеют и становятся статичными. Получается гипертрофированный монстр на окаменевшем скелете, к которому постоянно пытаются пришить то еще одну ногу, то руку.
Но принцип разработки интерфейсов может быть совершенно иным. Стоит только отказаться от идеи наращивания функциональности путем подключения новых модулей и выработать набор правил и описателей для работы с реальными бизнес-процессами и их данными, т. е. изначально заняться проектированием того самого единого информационного пространства.
Пусть данные управляют функциями, а не наоборот! Не напоминает ли это один из постулатов объектно-ориентированного проектирования? Само собой возникает желание использовать данный подход и при проектировании информационного пространства. Реальные бизнес-процессы, представляющие собой, по сути, совокупность данных и методов их обработки, так и напрашивались на представление в виде классов.
Основной проблемой было выделение наиболее общего набора сущностей и их формализация. Успешное выполнение этой задачи оказало решающее влияние на скорость дальнейшей разработки системы и ее функционирование.
С помощью механизма инкапсуляции удалось локализовать решение конкретных проблем, не размазывая его по всей плоскости пространства. Стала очевидной возможность многократного использования отлаженной реализации бизнес-процесса при проектировании новых решений. При этом описание в одной точке пространства многократно используемой сущности позволило упростить и, главное, ускорить поиск и исправление неминуемых ошибок проектирования.
Добавление возможности наследования обеспечило заметное сокращение количества описателей бизнес-процессов и дало возможность проектировщику произвести выделение той части описания класса, которая может послужить отправной точкой для создания родственных сущностей. В этом случае корректировки исходного бизнес-процесса ведут к безусловным и прозрачным изменениям всех его потомков.
Ну и, наконец, страшное по звучанию, но милое по сути слово - полиморфизм. Что оно означает в рассматриваемой системе понятий? Полиморфизм прежде всего выражается в совокупности действий с данными, принадлежащими различным сущностям, а главное - в независимости методов их обработки и представления от внутренней структуры бизнес-процесса. К примеру, он обеспечивает единообразное представление механизмов формирования отчетов, форм ввода, автоматических расчетов и т. п.
Данный подход позволяет программисту практически полностью абстрагироваться от решения частных задач, более того - он вовсе не должен знать специфику области, для которой разрабатывается решение! Имея дело с ограниченным набором метаданных, программист может сосредоточиться на эффективности создаваемого кода, уменьшить количество ошибок за счет исключения внутренних интерфейсов. Число программистов также уменьшается, зато возрастают требования к их профессионализму. Это мне нравится больше всего. Честолюбие честолюбием, но то, что мне не надо подвергать "криптоанализу" пресловутую инструкцию № 666, а нужно думать только об эффективности кода, - радует.
Вернемся к нуждам заказчика...
Парадоксально, но самое интересное начинается за стенами комнаты, где сидят программисты. Существует определенная категория сотрудников фирмы, для которых аудиторство - родная стихия. Это системные аналитики. Созданный инструментарий позволяет им использовать методы визуального проектирования при настройке управляющих информационных систем. При этом они оперируют знакомыми и понятными им и специалистам заказчика терминами. Система устанавливается по методу "индивидуального пошива" в соответствии с требованиями клиента: если нужно, изменяется количество таблиц данных, справочников, балансовых счетов, можно изменить размерность полей любой таблицы, установить новые физические и логические связи между задачами, описать не только автоматические проводки, но и любые изменения данных. И при этом не пишется ни единой строчки кода и исполняемый файл не подвергается перекомпиляции! Абсолютно все клиенты работают в своем информационном пространстве, со своими правилами и методиками учета и анализа. Исполнение всего разнообразия спроектированных ими бизнес-правил берет на себя один и тот же программный код.
Вопреки сложившемуся мнению при грамотном выделении области метаданных производительность обработки реальных данных при таком подходе не падает. Благодаря тому, что системный аналитик видит все информационное пространство и не связан правилами для перекачки информации внутри системы (данные вводятся один раз и хранятся в одном "мешке"), он может строить управляющую информационную структуру, наиболее близкую к оптимальной для конкретного клиента.
Более того, существенно повышается скорость создания структуры. А это уже серьезная заявка на рынке, где каждый декларирует высочайшую по сравнению с конкурентами скорость адаптации. Сейчас тендер (если он, конечно, не куплен - назовем вещи своими именами) можно выиграть только за счет такого преимущества. Например, задача учета взаиморасчетов за потребление газа на тендере Межрегионгаза была решена методом визуального проектирования за 23 минуты. Ближайший конкурент просил для решения этой же задачи 8 месяцев.
Почему данный подход не используют повсеместно, я сказать не могу; поняв же его суть, я долго чесал затылок и думал: "До чего элементарно - и все на поверхности!". Однако облысение мне не грозило: к решению задач в коллективе я подключился поразительно быстро, что опять-таки связываю с пресловутой специализацией по принципу "слесарю - слесарево...". И да здравствует инструкция № 666, особенно то, что я о ней ничегошеньки не знаю!
Алексей Фролов
Алексей Фролов - инженер-программист из компании "Цефей". С ним можно связаться по E-mail: viper@cefey.rosmail.com.
