Был нужен отчет…

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

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

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

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

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


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

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


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

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


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

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

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

hn63lafccejjibkhoixnt5-8drk.png

apk-aeso_7ulq_nqbu46o0scbew.png

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

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


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


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

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

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


tf077a_x3xq_y4wz_xwlpr4ii_s.png

uo0bq7i6k2lkbzjhnmws23nljbg.png

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

Заключение


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

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


zvuk2fai3pde1hnsnsymzbrundu.png

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

© Habrahabr.ru