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

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

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

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

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

Модель инфраструктуры


Например — модель инфраструктуры любого предприятия в общем виде содержит:

  • организационную и территориальную структуры предприятия (в качестве объектов привязки инфраструктуры)
  • состав (номенклатуру, классификатор, модели) учитываемых инфраструктурных объектов
  • их иерархические (родитель-потомок) и иные связи
  • их атрибуты, имеющие значение для решаемых нами задач

Аналитик, понимающий бизнес предприятия, может довольно быстро составить ядро модели инфраструктуры — выделить состав необходимых для учета объектов и построить из них одно или несколько иерархических деревьев. Далее, когда необходимо определить состав учитываемых атрибутов может пригодится предлагаемый метод анализа требуемой отчетности использующий так называемые «Шахматные доски».

Шахматные доски


Возможно сейчас на рынке есть некое готовое решение для решения таких задач, возможно даже это все как то можно сделать в Экселе — буду рад советам, подсказкам, альтернативным предложениям. Я ничего готового не нашел и вынужден был написать свой небольшой кусочек в среде корпоративного web приложения на платформе СУБД ORACLE (суть не в том как сделано — в статье описывается общий принцип).

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

В интерфейсе пользователя выглядит так (примеры отчетов для железнодорожников):





Тут все просто — есть 2 фрейма — в правом сама картинка на «Шахматной доске», а слева табличка для ручного ввода строк содержащих необходимые (по мнению аналитика):

  • Объект информационной модели — первичный объект учета к свойствам которого, относятся изображенные в ячейке (столбце) сканированного отчета характеристики
  • Характеристику (Атрибут, Параметр) указанного объекта информационной модели
  • Позицию на доске, например на первом рисунке строка 1 соответствует «Б-34»

Формирование модели учета


Таким образом информационная модель системы учета (inventory) формируется на основании обоснованных необходимостью использования в конкретных требуемых отчетах Объектов и их параметров.

Учет и Объектов и их Параметров ранее был сделан формализовано в виде отдельных справочников-классификаторов — результат этого сформированные:

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





На второй картинке справа видны ссылки на отчетные формы для формирования которых в карточке присутствует параметр.

Заключение


На практике применение данного подхода позволило:

  • обосновать присутствие объектов и параметров через необходимость реализации на основе этих данных требуемой итоговой отчетности
  • указать по конкретным параметрам их необходимость для реализации конкретных отчетов, выдвинуть требования к порядку заполнения учетных карточек в продуктовой системе и обязательности параметров
  • организованно (без путаницы и ошибок) дополнить состав Объектов учета и состав входящих в их учетные карточки параметров, информацией, необходимой для конкретных целей отчетности



Благодарю за внимание!

Комментарии (11)


  1. Spartak13
    11.11.2018 09:39

    Попробуйте посмотреть в сторону Crystal Reports или jasper reports (ныне, кажется, TIBCO). Имеется редактор, позволяющий строит сложные отчеты. На выходе экспорт данных во многих форматах — word, excel, html и т.п.
    В последнем проекте делали web приложение на базе Oracle с плагином, смотрящим на веб службу, под капотом которой jasper. Пользователи довольны


    1. Basych Автор
      11.11.2018 09:43

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


  1. leossnet
    11.11.2018 15:21

    Возможно Вам подойдет система экономического моделирования JetCalc, доступная по адресу github.com/leossnet/jetcalc. Описание положенной в основу системы идеи можно почитать по адресу habr.com/post/421163.


    1. Basych Автор
      11.11.2018 19:28

      Возможно. Мне очень понравился ваш тезис:

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

      Спасибо за ссылки


    1. alexhott
      12.11.2018 21:01

      то что выложено, мне так и не удалось использовать
      все установилось, запустилось но ввести данные и собрать отчет не вышло
      на каждом этапе куча багов и почти нет документации


      1. leossnet
        12.11.2018 22:33

        Проект сейчас реализуется силами двух человек во внерабочее время. Степень готовности примерно 90%. Сейчас основные усилия направлены на доработку расчетной системы. Следующим этапом планируется доработать систему выгрузки и установки готовых моделей из GitHub. Текущая версия позволяет оценить потенциал системы и подключиться к ее разработке всех заинтересованным лицам. Поэтому приглашаются все желающие. Работы очень много, она разная и ее хватит на всех.


  1. AlexTOPMAN
    11.11.2018 18:10

    Как я понял, полнота попадаемых в отчётность данных, а также их точность автора не интересовали совсем? (которые напрямую влияют на сходимость любого баланса по материальным потокам, если пробовать сводить его тоже автоматически и без бухгалтерских «фокусов» в виде явных приписок/отписок, «узакониваемых» даже в локальных методологиях учёта) В статье нет ни слова о том, как он решал эти задачи, если вообще решал.


    1. Basych Автор
      11.11.2018 18:55

      Если откровенно — не интересовали. Статья о методе построения оптимальной модели данных, отвечающей предъявляемым отчетами требованиям. Рассматривается задача проектирования оптимальной модели информации, в том числе и имеющей перспективы при развитии требований к самой системе отчетности. Задачи мотивации пользователей вносить в информационные системы достоверные данные решаются отдельными суровыми методами в которых я не считаю себя специалистом.


  1. dimoff66
    11.11.2018 22:30

    Когда нужна была статья на хабре…

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

    Спасибо за внимание. =)


    1. Basych Автор
      12.11.2018 13:41

      Уважаемый коллега. Часто у нас на момент проектирования новой системы нет никаких готовых списков объектов аналитики. Объекты мы формируем и выявляем сами и не всегда это просто в новой предметной области. Предложенный метод направлен как раз на то чтобы в конечном счете выработать оптимальную целевую модель данных и не заставлять пользователей вводить в систему не нужную никому информацию. Искренне жаль вашего времени на язвительные замечания по статье тема которой вам не интересна


      1. dimoff66
        12.11.2018 15:10

        Искренне жаль вашего времени на язвительные замечания по статье тема которой вам не интересна


        Мне интересна тема этой статьи, поскольку я 15 лет занимался 1С и в том числе неизбежно самой разнообразной отчетностью.

        Часто у нас на момент проектирования новой системы нет никаких готовых списков объектов аналитики. Объекты мы формируем и выявляем сами и не всегда это просто в новой предметной области.


        Значит найдите в свою команду человека, который знает эту предметную область, доверьте дело профессионалам. По шагам на простом примере:
        1) Есть объекты реального мира, например автомобили. У нас есть их список с некими очевидными характеристиками Марка, класс, расход топлива и т.д. Также есть списки их поставщиков…
        2) Есть первичка, ну например:
        — закупили (дата, модель, поставщик, кол-во, цена),
        — продали (дата, модель, поставщик, покупатель, кол-во цена)
        3) Есть свод регламентированных отчетов, он не может не быть, объекты аналитики по нему известны, они не могут быть неизвестны. Если в таблицах 1 и 2 какой-то аналитики нет, значит говорим пользователям ее добавить: это можно сделать либо добавив поля в существующие таблицы и формы, либо сделав дополнительную универсальную таблицу, куда можно добавить дополнительные свойства для любого объекта.

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

        Поставьте меня в тупик ситуацией, в которой этот простой механизм не будет работать.