Сергей Тарасов - Дефрагментация мозга. Софтостроение изнутри

Выход был найден. Бралось ядро NEXUS и компилировалось в работающую базу системы BillOnLine. Тонкий клиент сразу начинал работать. Оставалось дописать классы, которые поддержали бы бизнес-задачи предприятия, что и было сделано. Подход имел ещё одно интересное преимущество перед всеми мне известными. Скрипт ядра позволял устанавливать его в базу данных практически всех систем MSProject, DOCSVision, 1C 7.7 и 1С 8, что сразу давало дополнительную свободу управления и способность дорабатывать штатную систему под нештатные нужды организации без привлечения разработчиков продукта. Основным преимуществом является способность решить бизнес задачи в рамках SQL-запросов и хранимых процедур на порядок или два быстрее, чем любая программная платформа.

Правда, сейчас, после 10 лет разработки и внедрения Ultima-S называется NEXUS, но это сути не меняет. В настоящий момент я работаю на перекрёстке NEXUS и 1С 8, обеспечивая нужную производительность учётной системы в целом. Это даже не разработка, а сопровождение-разработка.

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

Технические ограничения эпохи бумаги и слабых ЭВМ вынудили «зашивать» аналитику в код счета. До сих пор многие системы, спроектированные профессиональными бухгалтерами, реализуют именно этот подход, например Oracle и SAP. Получить подробные данные о деятельности предприятия из классической главной книги (ГК) невозможно: количество сегментов в коде счета ограничено очень скромным числом (4–8).

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

Бухгалтерский движок в NEXUS позволяет преодолеть «проклятие» учёта по плану счетов с сегментацией кода счёта. Код отражает только вид операций – кассовые, банковские, складские, производственные и т. д. Существенные признаки операций сохраняются в виде аналитических срезов. В результате получается структура, сразу пригодная для OLAP [109].

Судите сами, Saldo – таблица фактов, несколько раз соединённая с таблицей Docs (измерения). Классическая «звезда». Для того чтобы помочь OLAP-клиенту, создаём отдельные view для каждой роли таблицы Docs – клиенты, товары, счета (в понятии регистров учёта), валюты, партии и т. д.

Далее подключаем эту структуру в Excel и получаем готовый OLAP, который наполняется данными в соответствии с учётной политикой предприятия, непосредственно в момент выполнения хозяйственных операций. Это не просто анализ операционной деятельности, это сверхоперативный анализ! Такая оперативность в других, более раскрученных системах возможна только в виде ограниченных плоских отчётов, построенных по первичным документам.

Я поддерживаю системы на этом «моторе» уже 10 лет – решение на удивление простое, гибкое и мощное. За это же время имел опыт использования JDEdwards OneWorld, Oracle Apps и в меньшей степени с SAP.

История системы продолжается.

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

О типовых решениях уровня реализации речь заходила редко, но уже в середине 1990-х годов иногда возникали упоминания книги GoF – «банды четырёх» [110][6] о приёмах объектно-ориентированного проектирования, где была предпринята попытка их обобщения. Признаюсь, руки долго не доходили до непосредственного ознакомления с этим трудом, но где-то в начале годов 2000-х издание наконец попало ко мне в руки.

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