Метод формирования регулярной обратной информационно-технологической связи в автоматизированных системах управления бизнес-процессами предприятия

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

Для разработки метода и модели трансформации АСУП применим гипотезу модельного представления знаний и принципы системной инженерии для формализации правил сбора, хранения, обработки информации для обеспечения эффективной идентифицируемости, прослеживаемости и управляемости объектов БП в АСУП.

• 1.    Формализация зафиксированных в описаниях бизнес-процесса логических отношений Рассмотрим три наиболее часто встречающихся подхода при автоматизации бизнес-процессов.

• 1.    Разработка собственного программного обеспечения (ПО) ресурсами организации, в которой осуществляется бизнес-процесс.

• 2.    Внедрение готового ПО, разработанного специализированным разработчиком, которое осуществляется ресурсами разработчика или сертифицированного вендора.

• 3.    Модульное внедрение, при котором внедряется не весь программный продукт, а только его модули, необходимые для обеспечения функциональности автоматизируемых бизнес-процессов, связь между которыми обеспечивается параметрическими настройками с полным отсутствием или минимальным участием человека [1–3].

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

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

Оценка существенности фактора по десятибалльной шкале (замечание: число факторов может быть существенно увеличено в зависимости от типа бизнес-процесса. Явно не хватает – стоимости приобретения, наличия обученных сотрудников для сопровождения, возможности динамического реинжиниринга, стоимости владения и т. д.) может быть сведена в таблицу [4–8].

Оценка существенных факторов реинжиниринга Assessment of significant factors of reengineering

Фактор	Внедрение и разработка кадровыми ресурсами организации	Внедрение готового продукта вендором
Гибкость процесса разработки/внедрения ПО	9	6
Пространство и вариативность возможных решений	10	5
Подстройка будущей автоматизированной системы под существующий бизнес-процесс	10	6
Лояльность хозяев бизнес-процесса к своим сотрудникам отдела ИТ	9	5
Отсутствие «изобретения велосипеда»	1	10
Наличие опыта предприятий, которые уже являются потребителями внедряемой системы	2	10
Возможность оперативной реакции на внешние изменения	10	6
Стоимость владения	8	10
Адаптивность системы к кадровым изменениям (первичное обучение, переобучение, повышение квалификации)	7	10

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

Внедрение и разработка кадровыми ресурсамиорганизации

Гибкость процесса разработки/внедрения ПО

Адаптивность системы к кадровым изменениям (первичное обучение, переобучение,...

Возможность оперативной реакции на внешние изменения

Стоимость владения

Подстройки будущей автоматизированной системы под существующий бизнес ...

Лояльность хозяев бизнес-процесса к своим сотрудникам отдела ИТ

"изобретения велосипеда"

Пространства и вариативности решений

Наличие предприятий, уже являются потребителями...

■ Целевой показатель   ^Внедрение и разработка кадровыми ресурсами организации

Рис. 1. Диаграммы сопоставления параметров при разработке ПО ресурсами организации Fig. 1. Diagrams mapping charts for software development with organisational resources

Внедрение готового продукта вендором

Гибкость процесса разработки/внедрения ПО

Адаптивность системы к кадровым изменениям (первичное обучение переобучение,...

Стоимость владения

Подстройки будущей автоматизированной системы под существующий бизнес-...

Лояльность хозяев бизнес-процесса к своим сотрудникам отдела ИТ

"изобретения

Наличие опыта предприятий, которые являются потребителями велосипеда внедряемой системы

Пространства и вариативности возможных решений

Возможность реакции на внешние изменения

■Целевой показатель ^Внедрение готового продукта вендором

Рис. 2. Диаграммы сопоставления параметров при внедрении готового продукта вендором Fig. 2. Diagrams comparison diagrams for vendor implementation of an off-the-shelf product

На основании проведенных исследований приходим к выводу об отсутствии универсального решения, так как ни один вариант не покрывает целевой показатель полностью или хотя бы равномерно [9]. Таким образом, выбор должен быть индивидуальным для каждого предприятия/бизнес-процесса, так как существенность каждого параметра может быть различна и субъективна.

Выбор между двумя способами зависит от характера бизнес-процесса, наличия ресурсов, его ограничений, регулирующих воздействий, масштабов. Например, если необходимо автоматизировать математические вычисления на исследовательском предприятии, которые представляют собой исключительно математические правила и формулы, то имеет смысл не внедрять масштабный математический продукт (наподобие STATISTICA), требующий существенных финансовых затрат, а поручить программисту произвести необходимые расчеты и разработку ПО в подходящей среде разработки с последующим сопровождением продукта. В случае же автоматизации бухгалтерского учета или планирования производства в промышленности имеет смысл внедрять готовую ERP-систему, которая точно включает в себя эффективные наработки, основанные на опыте разработчика, обеспечивает соблюдение законодательства и нередко приводит к оптимизации самого бизнес-процесса, так как в процессе внедрения появляется внешний фактор (можно сказать «незаинтересованный внешний аудитор») в лице разработчика или вендора [10-13].

Также при внедрении информационных систем любым способом неотъемлемым этапом является документирование, которое включает в себя описание бизнес-процесса, его математической логики, описание проблематики, целей, описание постановки задачи, а также описание готового результата, процесса внедрения и программного кода для технических специалистов. Для массовых и коммерческих продуктов (графические редакторы, офисные приложения, мобильные приложения социальных сетей, «десктопные» или мобильные мессенджеры и т. п.) этот этап проходит более эффективно и продуктивно, в отличие от автоматизации внутри организации и ресурсами самой организации. Этап документирования является одним из обязательных начальных этапов, но при этом он осуществляется на протяжении всего цикла внедрения и/или разработки программного продукта. Процесс документирования является достаточно рутинным, часто не вызывает у сотрудников, занимающихся внедрением, необходимого желания и энтузиазма, вследствие чего теряется качество документирования. Исторически (возможно и ментально) процесс документирования должным образом организован только до формирования и подписания технического задания, так как от качества технического задания напрямую зависит качество результата и, как следствие, финансовые затраты. Документирование после утверждения технического задания зачастую переходит в формальную, а иногда и в необязательную форму. В итоге на момент завершения разработки и внедрения кроме самой информационной системы остается утвержденное техническое задание, инструкции пользователей и поверхностные регламенты и методики, относящиеся к автоматизированному бизнес-процессу. При этом логика бизнес -процесса остается только «в головах» хозяев бизнес-процесса и в программном коде/настройках информационной системы. В случае исключения из бизнес-процесса определяющих специалистов (например, увольнение, перевод на другую задачу) теряется полный контроль над процессом и процесс может пойти на «самотёк». Это не является критичным в условиях неизменяемых внутренних и внешних воздействий. В случае же изменения характера или топологии воздействия возникают проблемы и появляются задачи, для решения которых обязательно необходимо описание логики исходного бизнес-процесса, которое на момент возникновения проблемы уже утрачено. В подобных условиях решение задачи может свестись к эмоциональному перекладыванию ответственности между участниками бизнес-процесса, радикальным (при этом часто неэффективным) управленческим решениям. Исходя из изложенного, проблема документирования бизнес-процессов при автоматизации очень актуальна и имеет распространенные и типовые проблемы [14].

Часто для решения проблемы применяется метод изучения программного кода, разработанного ПО и/или его настроек, при котором хозяин бизнес-процесса обращается к отделу ИТ с просьбой «посмотреть, как там считается показатель «Х», откуда получает информацию выходная форма Ф-001.01». Программист отдела ИТ анализирует код ПО, определяет заложенные в ПО математические принципы обработки информации, передает их хозяину бизнес-процесса, который в свою очередь полученные математические принципы трактует с точки зрения предметной области в терминах бизнес-процесса (уже в отрыве от автоматизации) [15].

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

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

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

Таким образом, можем говорить о процессе внешней интеграции постоянно изменяющихся трех подсистем (классов) каждой информационной системы: бизнес-процесса (обозначим ^ ), информационной модели бизнес-процесса (обозначим S₂ ) и самой программной системы (обозначим S ₃). Внутри каждой из приведенных подсистем выделяем объекты. Можем использовать классификацию бизнес-процессов по взаимодействию при интеграции [4], рассматривая подлежащие интеграции подсистемы как независимые бизнес -процессы. Очевидно, что для любой пары объектов каждой подсистемы существует множество морфизмов, например Hom(S ₁, S ₂) и Hom(S ₂, S ₃) . Тогда для g_S g Hom(S ₁, S ₂) и f_S g Hom(S ₂, S ₃) определена их композиция g_S ° fs g Hom(S ₁, S 3 ) и подсистемы внутри каждого класса образуют категорию множеств.

Учитывая, что внутри каждой категории существует гомоморфные отображения объектов (в нашем случае информационные системы), интеграция может быть рассмотрена в виде взаимодействия между моделями как отображения между категориями [16, 17].

Обозначим информационные подсистемы соответствующие трем выше описанным подсистемам W₁, W₂, W₃ . Их параметрические и структурные характеристики позволяют сделать вывод о том, что это категории множеств.

На основании вышеприведенного можем сделать вывод, что структурные и параметрические состояния каждой такой подсистемы образуют класс объектов и для любых пар ( w ¹ , w ² ) и ( w ² , w ³ ) существует множество морфизмов, для каждой пары которых будет определена композиция [18, 19]:

1 2 2 3 1 3 12 3

f w g Hom ( w 1 , w j, g w g Hom ( w 1 , w O, f w °g w g Hom ( w 1 , w 1 ) w_p w 1 , w 1 g W

1 2 2 3 1 3 12 3

' f w G Hom ( w 2 , w 2 ), g w ₂ G Hom ( w₂, w 2 ), f w, g w , G Hom ( w 2 , w₂) w 2 , w 2 , w 2 g W , . (1)

1 2 2 3 1 3 12 3

_ ^fw ₃ ^{G Hom ( w}2^{, w}3 ), g w ₃ ^{G Hom ( w}3 , w³), ^fw₃^g g^ ^{G Hom ( w}2^{, w}3 ) ^w2^{, w}3 , ^w3 ^G W 3

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

Рис. 3. Схема процесса отношений классов подсистем информационной системы Fig. 3. Scheme of the information system subsystem class relationship process

Рис. 4. Пример схем отображения взаимодействия W 1 , W 2 и W 3

Fig. 4. Example of interaction mapping schemes W 1 , W 2 и W 3

Все вышеприведенное можем представить формулами (2)–(4), описывающими отображение категорий множеств одной подсистемы в другую с сохранением их структур (функторное отношение) (рис. 4).

F w₂ ^: W 2 ^ W 1    f w ₂ ^{: w} 2 ^ ^w 2    g w₂ ^{: w} 2 ^ ^w 2

F w ₂ ( f w 2 ): F w 2 2 ) ^ F w 2 ( w ²)

F w 2 ( g w 2 ): F w' w^ ^ F w2 (w 2 )

F (f ^F (g ) = F (f = g )

W 2 V J W 2      W 2 ^ g W 2       ^w 2 ^J W 2 ^gW2^

F w₂ ^{: W} 2 ^ ^W 1 ^fw ₂ ^{: w} 2 ^ ^w2 ^gw₂ ^{: w}2 ^ w²

F w 2 ( fw^. ): F w 2 ( w 2 ) ^ F w 2 ( W 3 ²)

F w ₂ ( g w ₂ ): F w ₂ ( w 22 ) ^ F w₂ (w 2 )

F (f VF (g } = F (f =g ) w 2 ^J w .      w . g ww. , w . ^J w . g w .

G w₂ : ^W2 ^ W 3   fw₂ : w 2 ^ ^w l g w₂ ^: w ^ ^w 2

G_{W 2} (f w^ G w 2 ( w 2 ) ^ G w 2 ( W 22 )

^gW 2 )

G wA g^Y G w₂ ( w l ) ^ G w₂ (w 2 )

^GW 2 ⁽ fwz ) ° G^w 2 ⁽ g ^w 2 )   ^GW 2 ^{( f}W 2

Пример схем представлен в блоках W 1 , W 2 и W 3 .

Рис. 5. Диаграмма двух возможных путей Fig. 5. Diagram of two possible path ways

Используя теорию категорий как некоторый формальный язык, можем без описания структуры объектов подсистем описать связи внутри подсистем посредством морфизмов и между подсистемами (на уровне объектов) функторами. Учитывая, что некоторая композиция морфизмов может быть равна другой композиции ( fw ° gw ) = ( f'w ° g'w ) , совпадение говорит о неоднозначности цепочек взаимодействия по пути от объекта одной подсистемы X к объекту другой подсистемы Y вдоль стрелок диаграммы (рис. 5).

2.    Применение метода формализации зафиксированных в описаниях бизнес-процесса логических отношений для построения прототипа информационной модели

На основании приведенного каждый этап описанной выше интеграции можно определить как формализацию зафиксированных в описании логических отношений, описание каждой подсистемы на основе таблицы переменных как n-мерный куб, каждое измерение которого соответствует одной из переменных. Данный куб будет представлять собой онтологию [20], обладать свойством избыточности в связи с отсутствием ряда объектов, которые могут быть описаны с помощью набора атрибутов, учитывающих:

• –    множество элементов предметной области;

• –    множество функций, определенных на этих элементах в явной или не явной (задаваемых в виде уравнений) формах;

• –    множество свойств элементов;

• –    множество отношений между элементами.

Например, при автоматизации по архитектуре «тонкого клиента» определяющая доля вычислений происходит на стороне сервера, а клиентская часть в основном занимается визуальной составляющей процесса. При этом часто математическая логика полностью закладывается в коде SQL, T-SQL, PL/SQL и т. п., а SQL сам по себе априори структурированный язык, работающий только с реляционными базами данных (БД), которые должны быть построены по утвержденным принципам разработки БД (таблицы, типы данных в полях, ключевые поля). Даже если математическая логика заложена не в SQL-запросе, а в коде языка программирования, данные хранятся в базе данных под управлением СУБД. Любая реляционная БД имеет таблицы, поля, ключевые поля, связи. Структура БД строится на основании информационной модели. Информационная модель в свою очередь является структурированным отображением информации бизнес-процесса, взаимосвязей между элементами бизнес-процесса. Изучив информационную модель бизнес-процесса, можно в полной мере определить и формализовать информационную составляющую бизнес-процесса без помощи дополнительных описаний или объяснений его собственника. Связи между сущностями информационной модели имеют отражение в схеме БД в виде CONSTRAINT. Это ограничение внешнего ключа, позволяющее связать данные из одной или нескольких таблиц, например, чтобы нельзя было удалить данные из одной таблицы, без удаления связанных данных в другой или чтобы удаление/обновление в одной таблице приводило к каскадному удалению/обновлению данных в других таблицах. Это позволяет поддерживать согласованность базы данных, не допуская, чтобы появлялись ключи, ссылающиеся на несуществующие записи.

В итоге связи в информационной модели, отражающие принципиальную (можно назвать «природную») связь данных бизнес-процесса, имеют полный технический аналог в виде огра- ничений CONSTRAINT в базе данных. На основании информации о CONSTRAINT в БД открывается возможность формализовать информационные связи и зависимости самого бизнес-процесса.

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

Заключение

Предложены правила преобразования методами теории категории множеств структуры традиционных АСУП БП в систему из трех подсистем, связанных нечеткими информационными отношениями между реальными и виртуальными объектами БП с оценкой полноты множества этих отношений и классификацией их по свойствам функциональности в явной или неявной (с обратной связью) формах. Данное категорийное представление позволяет сформировать модифицированную структурно-функциональную модель АСУП БП с регулярной информационнотехнологической обратной связью.

Исследование проводится при финансовой поддержке Министерства образования и науки Российской Федерации в рамках основной части государственного задания высшим учебным заведениям № FEUE-2020-0007.