CC BY
25
УДК 004
DOI: 10.14529/с^г210412
МЕТОД ФОРМИРОВАНИЯ РЕГУЛЯРНОЙ ОБРАТНОЙ ИНФОРМАЦИОННО-ТЕХНОЛОГИЧЕСКОЙ СВЯЗИ В АВТОМАТИЗИРОВАННЫХ СИСТЕМАХ УПРАВЛЕНИЯ БИЗНЕС-ПРОЦЕССАМИ ПРЕДПРИЯТИЯ
12 1 В.В. Антонов', В.Н. Шкаров2, Л.Е. Родионова',
Г.Г. Куликов3, В.А. Колесников4
1 Уфимский государственный авиационный технический университет, г. Уфа, Россия,
2 АО «Уфимское приборостроительное производственное объединение», г. Уфа, Россия,
3 АО «Уфимское научно-производственное предприятие «Молния», г. Уфа, Россия,
4 Уфимский юридический институт Министерства внутренних дел Российской Федерации, г. Уфа, Россия
Учитывая многогранность понятия «бизнес-процесс» ограничимся определением, что бизнес-процесс - это совокупность взаимосвязанных мероприятий или работ, направленных на создание определённого продукта или услуги для потребителей. С точки зрения концепции ВРМ бизнес-процессы - это ценные ресурсы предприятия, а управление ими является частью системы организационных мероприятий, т. е. организационной системой автоматизированных систем управления бизнес-процессами предприятия (АСУП). Цель исследования. Очевидно, что задача автоматизации сама является бизнес-процессом в АСУП, целями которого являются: разработка (приобретение), внедрение и эксплуатация программных, аппаратных, информационных и др. ресурсов (средств), предназначенных для реализации потенциальных возможностей бизнес-процесса (которых просто не было в ручном контуре), оптимизации и увеличения скорости существующего бизнес-процесса, улучшение условий труда, сокращение потребности в рабочей силе и т. п. Появляется и новое направление - компьютерный анализ и интегрирование информации. Материалы и методы. Предлагается использовать контроль за отклонениями от требований бизнес-процесса для организации регулярной информационно-технологической обратной связи в АСУП. Результаты. Автоматизация наделяет бизнес-процесс новым свойством - возможностью получать оперативные данные обо всех предусмотренных действиях и интегрировать информацию о взаимодействующих объектах бизнес-процесса (БП) в рамках реализации предписанного множества целевых функций. Как правило, модель процесса автоматизации штатного бизнес-процесса представляется в явной функциональной форме, а нештатные ситуации описываются неявно выраженными функциями в форме уравнений. Для эффективного применения информационных технологий необходимо введение внутренних корректирующих информационно-технологических обратных связей, определяемых по показателям эффективности самого БП. Это необходимо, например, для эффективного управления внутренними ресурсами организации - финансовыми, материальными, кадровыми и т. п. Заключение. В связи с наличием достаточно большого количества «унаследованных систем» в АСУП, постоянно увеличивающейся динамикой изменения внешней среды и самих бизнес-процессов представляется актуальной задача организации эффективного управления с регулярной информационно-технологической обратной связью самой АСУП.
Ключевые слова: бизнес-процесс, программное обеспечение, вендор, теория категорий, функторное отношение, программный код, база данных.
Введение
Повышение эффективности производства и бизнеса в целом в условиях современной цифровой трансформации промышленности предполагает прежде всего модернизацию и, как следствие, повышение эффективности функционирования существующих систем, в том числе и АСУП.
Для разработки метода и модели трансформации АСУП применим гипотезу модельного представления знаний и принципы системной инженерии для формализации правил сбора, хранения, обработки информации для обеспечения эффективной идентифицируемости, прослежи-ваемости и управляемости объектов БП в АСУП.
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), требующий существенных финансовых затрат, а поручить программисту произвести необходимые расчеты и разработку ПО в подходящей среде разработки с последующим сопровождением продукта. В случае же автоматизации бухгалтерского учета или планирования производства в промышленности имеет смысл внедрять готовую ЕЯР-систему, которая точно включает в себя эффективные наработки, основанные на опыте разработчика, обеспечивает соблюдение законодательства и нередко приводит к оптимизации самого бизнес-процесса, так как в процессе внедрения появляется внешний фактор (можно сказать «незаинтересованный внешний аудитор») в лице разработчика или вендора [10-13].
Также при внедрении информационных систем любым способом неотъемлемым этапом является документирование, которое включает в себя описание бизнес-процесса, его математической логики, описание проблематики, целей, описание постановки задачи, а также описание готового результата, процесса внедрения и программного кода для технических специалистов. Для массовых и коммерческих продуктов (графические редакторы, офисные приложения, мобильные приложения социальных сетей, «десктопные» или мобильные мессенджеры и т. п.) этот этап проходит более эффективно и продуктивно, в отличие от автоматизации внутри организации и ресурсами самой организации. Этап документирования является одним из обязательных начальных этапов, но при этом он осуществляется на протяжении всего цикла внедрения и/или разработки программного продукта. Процесс документирования является достаточно рутинным, часто не вызывает у сотрудников, занимающихся внедрением, необходимого желания и энтузиазма, вследствие чего теряется качество документирования. Исторически (возможно и ментально) процесс документирования должным образом организован только до формирования и подписания технического задания, так как от качества технического задания напрямую зависит качество результата и, как следствие, финансовые затраты. Документирование после утверждения технического задания зачастую переходит в формальную, а иногда и в необязательную форму. В итоге на момент завершения разработки и внедрения кроме самой информационной системы остается утвержденное техническое задание, инструкции пользователей и поверхностные регламенты и методики, относящиеся к автоматизированному бизнес-процессу. При этом логика бизнес-процесса остается только «в головах» хозяев бизнес-процесса и в программном коде/настройках информационной системы. В случае исключения из бизнес-процесса определяющих специалистов (например, увольнение, перевод на другую задачу) теряется полный контроль над процессом и процесс может пойти на «самотёк». Это не является критичным в условиях неизменяемых внутренних и внешних воздействий. В случае же изменения характера или топологии воздействия возникают проблемы и появляются задачи, для решения которых обязательно необходимо описание логики исходного бизнес-процесса, которое на момент возникновения проблемы уже утрачено. В подобных условиях решение задачи может свестись к эмоциональному перекладыванию ответственности между участниками бизнес-процесса, радикальным (при этом часто неэффективным) управленческим решениям. Исходя из изложенного, проблема документирования бизнес-процессов при автоматизации очень актуальна и имеет распространенные и типовые проблемы [14].
Часто для решения проблемы применяется метод изучения программного кода, разработанного ПО и/или его настроек, при котором хозяин бизнес-процесса обращается к отделу ИТ с просьбой «посмотреть, как там считается показатель «Х», откуда получает информацию выходная форма Ф-001.01». Программист отдела ИТ анализирует код ПО, определяет заложенные в ПО математические принципы обработки информации, передает их хозяину бизнес-процесса, который в свою очередь полученные математические принципы трактует с точки зрения предметной области в терминах бизнес-процесса (уже в отрыве от автоматизации) [15].
Антонов В.В., Шкаров В.Н., Метод формирования регулярной обратной
Родионова Л.Е. и др. информационно-технологической связи...
Все это не исключает отличие результатов выполнения конкретной итерации бизнес-процесса от ожидаемых по причине измененных входных данных без изменения самого бизнес-процесса, т. е. конкретная итерация бизнес-процесса выдает результат в виде данных, которые отличаются от трендовых данных, полученных по результатам выполнения других итераций бизнес-процессов. В таких случаях нередки случаи, при которых собственник бизнес-процесса «скидывает» причину отклонения на ПО и, не разобравшись в истинных причинах, перенаправляет проблему на ИТ. ИТ в свою очередь, потратив время на поиск причины, определяет, что проблема была не в ИТ, а в измененных входных данных.
Следует особо отметить существенность фактора изменения внешней среды (входных данных, параметров, условий и т. д.) бизнес-процесса. Бизнес-процесс, автоматизированный на одной топологии внешней среды, может быть не просто непродуктивным, а стать бомбой замедленного действия после изменения внешней среды. Например, при незначительном изменении внешней среды, своевременно идентифицировать которую не всегда возможно по причине отсутствия доступа объектов бизнес-процесса к внешней среде или отсутствия должной компетенции исполнителей бизнес-процесса. В этом случае автоматизированная система будет выполнять свои функции математически верно, но неверно с точки зрения предметной области из-за вышеупомянутых изменений. В первые периоды эта некорректность может не сильно влиять на процесс, но со временем из-за эффекта накопления процесс может сместиться в совершенно неверное направление, а исправить отклонения будет уже невозможно.
Рассматриваемая проблема весьма актуальна, так как существует большое число классов информационных систем с постоянно растущим набором систем внутри каждого класса.
Таким образом, можем говорить о процессе внешней интеграции постоянно изменяющихся трех подсистем (классов) каждой информационной системы: бизнес-процесса (обозначим З^), информационной модели бизнес-процесса (обозначим 52) и самой программной системы (обозначим 53). Внутри каждой из приведенных подсистем выделяем объекты. Можем использовать классификацию бизнес-процессов по взаимодействию при интеграции [4], рассматривая подлежащие интеграции подсистемы как независимые бизнес-процессы. Очевидно, что для любой пары объектов каждой подсистемы существует множество морфизмов, например Нот(^1,52) и Нот(52,5з). Тогда для gs е Нот(51,52) и / е Нот^,5з) определена их композиция gs ° /б е Нот(51,5з) и подсистемы внутри каждого класса образуют категорию множеств.
Учитывая, что внутри каждой категории существует гомоморфные отображения объектов (в нашем случае информационные системы), интеграция может быть рассмотрена в виде взаимодействия между моделями как отображения между категориями [16, 17].
Обозначим информационные подсистемы соответствующие трем выше описанным подсистемам Wl, Щ2, Щз. Их параметрические и структурные характеристики позволяют сделать вывод о том, что это категории множеств.
На основании вышеприведенного можем сделать вывод, что структурные и параметрические состояния каждой такой подсистемы образуют класс объектов и для любых пар (щ1, щ2) и (м>2, щз) существует множество морфизмов, для каждой пары которых будет определена композиция [18, 19]:
° gw¡ е НотЩ, щз) щ1, щ2, щз е Щ /щ2 е Нот(щ>\,^2), gw2 е Нот(м>1,щ|), ° gW2 е Нот(у»\,Ц,^2,е ^г . (1)
/щ е Нот(щ3, щ2), gwз е Нот(щз2, щзX /щ3 ° gWз е Нот(ц>3, щз) щ, щ2, щз е Щ
Рассматривая связи наших подсистем (отображения) между собой (формализация которых и является нашей задачей), приходим к нечеткому соответствию отображений, которые должны поставить каждому объекту (с морфизмом) одной подсистемы объект (и морфизм) другой подсистемы (рис. з).
Wi
Рис. 3. Схема процесса отношений классов подсистем информационной системы Fig. 3. Scheme of the information system subsystem class relationship process
Рис. 4. Пример схем отображения взаимодействия W1, W2 и W Fig. 4. Example of interaction mapping schemes W1, W2 и W3
Все вышеприведенное можем представить формулами (2)-(4), описывающими отображение категорий множеств одной подсистемы в другую с сохранением их структур (функторное отношение) (рис. 4).
K2 : W2 ^ W fw2 : w2 ^ w2 gw2 : ^ W
K2 (fw2 ): Fw2(w2) ^ Fw2 (w2 ) FW2 ( £w2 ): Fw2(w22) ^ Fw2(w2)
F ( f ) о F ( £ ) = F ( f о £ )
w2 w2 w2 w2 w2 w2 w2
(2)
Fw3:W3 ^ W fw3 : w* ^ W32 £w3
Fw3 (fw3 ) : Fw3 (w3 ) ^ Fw3 (w32 ) (3)
Fw3 ( £ w3 ):Fw3(w2) ^Fw3(w3)
F ( f ) о F ( £ ) = F ( f о £ )
w3 w3 w3 w3 w3 w3 w3
Gw2:W2 ^ W
fW2 : W2 ^ w22 gw2 : W\ ^ W2
gw2 (fW2 ) : Gw (w2 ) ^ Gw, (w2 )
w2
w2
Gw2 (gW2 ) : Gw2 (w2 ) ^ Gw2(w2
(w3)
(4)
G (f ) о G (g ) = G (f о g )
VJW2 ^ ^<5 W2 ' W2 W2 OW2 '
W2
W2 W2
W2
- Y
Пример схем представлен в блоках Ж2 и Щ.
Используя теорию категорий как некоторый формальный язык, можем без описания структуры объектов подсистем описать связи внутри подсистем посредством морфизмов и между подсистемами (на уровне объектов) функторами. Учитывая, что некоторая композиция морфизмов может быть равна другой композиции ) гг (,/„. ° ) = (/ м. Я „.). совпадение говорит о неоднознач-
ности цепочек взаимодействия по пути от объекта одной подсистемы X к объекту другой подсистемы У вдоль стрелок диаграммы (рис. 5).
X
и
я
-Z.
Рис. 5. Диаграмма двух возможных путей Fig. 5. Diagram of two possible path ways
2. Применение метода формализации зафиксированных в описаниях бизнес-процесса
логических отношений для построения прототипа информационной модели
На основании приведенного каждый этап описанной выше интеграции можно определить как формализацию зафиксированных в описании логических отношений, описание каждой подсистемы на основе таблицы переменных как n-мерный куб, каждое измерение которого соответствует одной из переменных. Данный куб будет представлять собой онтологию [20], обладать свойством избыточности в связи с отсутствием ряда объектов, которые могут быть описаны с помощью набора атрибутов, учитывающих:
- множество элементов предметной области;
- множество функций, определенных на этих элементах в явной или не явной (задаваемых в виде уравнений) формах;
- множество свойств элементов;
- множество отношений между элементами.
Например, при автоматизации по архитектуре «тонкого клиента» определяющая доля вычислений происходит на стороне сервера, а клиентская часть в основном занимается визуальной составляющей процесса. При этом часто математическая логика полностью закладывается в коде SQL, T-SQL, PL/SQL и т. п., а SQL сам по себе априори структурированный язык, работающий только с реляционными базами данных (БД), которые должны быть построены по утвержденным принципам разработки БД (таблицы, типы данных в полях, ключевые поля). Даже если математическая логика заложена не в SQL-запросе, а в коде языка программирования, данные хранятся в базе данных под управлением СУБД. Любая реляционная БД имеет таблицы, поля, ключевые поля, связи. Структура БД строится на основании информационной модели. Информационная модель в свою очередь является структурированным отображением информации бизнес-процесса, взаимосвязей между элементами бизнес-процесса. Изучив информационную модель бизнес-процесса, можно в полной мере определить и формализовать информационную составляющую бизнес-процесса без помощи дополнительных описаний или объяснений его собственника. Связи между сущностями информационной модели имеют отражение в схеме БД в виде CONSTRAINT. Это ограничение внешнего ключа, позволяющее связать данные из одной или нескольких таблиц, например, чтобы нельзя было удалить данные из одной таблицы, без удаления связанных данных в другой или чтобы удаление/обновление в одной таблице приводило к каскадному удалению/обновлению данных в других таблицах. Это позволяет поддерживать согласованность базы данных, не допуская, чтобы появлялись ключи, ссылающиеся на несуществующие записи.
В итоге связи в информационной модели, отражающие принципиальную (можно назвать «природную») связь данных бизнес-процесса, имеют полный технический аналог в виде огра-
ничений CONSTRAINT в базе данных. На основании информации о CONSTRAINT в БД открывается возможность формализовать информационные связи и зависимости самого бизнес-процесса.
При наличии доступа к БД, но не имея информационной модели, на основании вышеизложенного и проведенных исследований приходим к возможности построения прототипа информационной модели, близкой к исходной, для восстановления информации об исходной предметной сути информационных связей и зависимостей бизнес-процесса.
Заключение
Предложены правила преобразования методами теории категории множеств структуры традиционных АСУП БП в систему из трех подсистем, связанных нечеткими информационными отношениями между реальными и виртуальными объектами БП с оценкой полноты множества этих отношений и классификацией их по свойствам функциональности в явной или неявной (с обратной связью) формах. Данное категорийное представление позволяет сформировать модифицированную структурно-функциональную модель АСУП БП с регулярной информационно-технологической обратной связью.
Исследование проводится при финансовой поддержке Министерства образования и науки Российской Федерации в рамках основной части государственного задания высшим учебным заведениям № FEUE-2020-0007.
Литература
1. Бениаминов, Е.М. Алгебраические методы в теории баз данных и представлении знаний / Е.М. Бениаминов. - М. : Научный мир, 2003. - 184 с.
2. Международный стандарт ИСО 9000. Системы менеджмента качества. Основные положения и словарь. - http://www.icc-iso.ru/toclients/standard/iso_9000/.
3. ИКТ в госсекторе // Электрон. журн. CNews. - 2013. - № 65. - С. 40-41.
4. Беллман, Р. Принятие решений в расплывчатых условиях / Р. Беллман, Л. Заде // Вопросы анализа и процедуры принятия решений: сб. переводов. - М. : Мир, 1976. - С .172-215.
5. Корпоративные хранилища данных. Интеграция систем. Проектная документация. -https://www.prj-exp.ru/patterns/pattern_draft_project.php (дата обращения: 25.11.2018).
6. Подход к формированию структуры самоорганизующейся интеллектуальной системы в форме декартово замкнутой категории (на примере проектирования информационной аналитической программной системы) / Г.Г. Куликов, В.В. Антонов, А.Р. Фахруллина, Л.Е. Родионова // Вестник ПНИПУ. Электротехника, информационные технологии, системы управления. - 2018. -№ 27. - С. 49-67.
7. Aral, Sinan. Information, Technology and Information Worker Productivity / Sinan Aral, Erik Brynjolfsson, Marshall Van Alstyne // Information Systems Research. - 2012. - Vol. 23, no. 3-part-2. -P. 849-867.
8. Analytical software for operating with a set of real and virtual objects using the rules of cartesian closed category / G.G. Kulikov, V.V. Antonov, M.A. Shilina et al. // Advances in Intelligent Systems Research: Proceedings of the VIth International Workshop 'Critical Infrastructures: Contingency Management, Intelligent, Agent-Based, Cloud Computing and Cyber Security' (IWCI2019). - China: Atlantis Press, 2019. - P. 173-178.
9. Поспелов, Д.А. Знания и шкалы в модели мира /Д.А. Поспелов //Модели мира: сб. ст. - М. : РАИИ, 1997. - С. 69-84.
10. Куликов, Г.Г. Метод формирования структуры хранилища данных для автоматизированной учетной системы на основе процессного анализа предметной области / Г.Г. Куликов, В.В. Антонов //Вестник УГАТУ. - 2006. - Т. 8, № 1 (17). - С. 60-67.
11. Towards privacy preserving AI based composition framework in edge networks using fully homomorphic encryption / Mohammad Saidur Rahman, Ibrahim Khalil, Mohammed Atiquzzaman, Xun Yi // Engineering Applications of Artificial Intelligence. - 2020. - Vol. 94, 103737. DOI: 10.1016/j. engappai.2020.103737
12. Prasanna Matsa. To Study Impact of Artificial Intelligence on Human Resource Management / Prasanna Matsa, Kusuma Gullamajji // International Research Journal of Engineering and Technology. -2019. - Vol. 06 (08). - Р. 1229-1238.
13. Salas, D.F. Benchmarking a scalable approximate dynamic programming algorithm for stochastic control of grid-level energy storage / D.F. Salas, W.B. Powell //INFORMS Journal on Computing. - 2018. - Vol. 30 (1). - P. 106-123. DOI: 10.1287/ijoc.2017.0768
14. Заболеева-Зотова, А.В. Лингвистическое обеспечение автоматизированных систем / А.В. Заболеева-Зотова, В.А. Камаев. -М. : Высшая школа, 2008. - 244 с.
15. Формальное представление модели реализации функций системной инженерии на основе принципа необходимого разнообразия структурных связей /Г.Г. Куликов, В.В. Антонов, А.Р. Фах-руллина, Л.Е. Родионова // Вестник ЮУрГУ. Серия «Компьютерные технологии, управление, радиоэлектроника». - 2017 - Т. 17, № 4 - С. 146-153. DOI: 10.14529/ctcr170416
16. Формальная модель процессов взаимодействия компонентов программной системы на основе фрактального подхода / Г.Г. Куликов, В.В. Антонов, А.Р. Фахруллина, Л.Е. Родионова // Электротехнические и информационные комплексы и системы. - 2018. - Т. 14, № 4. - С. 104-111.
17. Копайгородский, А.Н. Применение онтологий в семантических информационных системах /А.Н. Копайгородский // Онтология проектирования. - 2014. - № 4 (14). - С. 78-89.
18. Родионова, Л.Е. Описание предметной области для проектирования программной системы /Л.Е. Родионова // Сборник статей 7-й Всероссийской научно-технической конференции с международным участием «Современные инновации в науке и технике» / под общ. ред. А.А. Горохова. - Курск: Изд-во ЗАО «Университетская книга», 2017. - С. 171-174.
19. Хомский, Н. Язык и проблема знания / Н. Хомский // Вестник МГУ. - М., 1996. - Вып. 6. -С. 157-185.
20. Павлов, С.В. Онтологическая модель интеграции разнородных по структуре и тематике пространственных баз данных в единую региональную базу данных / С.В. Павлов, О.А. Ефремова // Онтология проектирования. - 2017. - Т. 7, № 3 (25). - С. 323-333. DOI: 10.18287/2223-9537-20177-3-323-333
Антонов Вячеслав Викторович, д-р техн. наук, профессор, Уфимский государственный авиационный технический университет, г. Уфа; Antonov.V@bashkortostan.ru.
Шкаров Валерий Николаевич, заместитель начальника отдела ИТ, АО «Уфимское приборостроительное производственное объединение», г. Уфа; alteroz87@gmail.com.
Родионова Людмила Евгеньевна, канд. техн. наук, доцент, Уфимский государственный авиационный технический университет, г. Уфа; lurik@mail.ru.
Куликов Григорий Геннадьевич, технический директор, АО «Уфимское научно-производственное предприятие «Молния», г. Уфа; qkqufa@rambler.ru.
Колесников Валерий Александрович, канд. социол. наук, доцент кафедры управления, Уфимский юридический институт Министерства внутренних дел Российской Федерации, г. Уфа; kolesnikov62va@rambler.ru.
Поступила в редакцияю 20 сентября 2021 г.
DOI: 10.14529/ctcr210412
A METHOD OF ENSURING THAT DEVIATIONS FROM BUSINESS PROCESS REQUIREMENTS ARE CONTROLLED IN THE OPERATION OF THE COMPANY'S AUTOMATED SYSTEMS
V.V. Antonov1, Antonov.V@bashkortostan.ru,
V.N. Shkarov2, alteroz87@gmail.com,
L.E. Rodionova1, lurik@mail.ru,
G.G. Kulikov3, qkqufa@rambler.ru,
V.A. Kolesnikov4, kolesnikov62va@rambler.ru
1 Ufa State Aviation Technical University, Ufa, Russian Federation,
2 JSC "Ufa Instrument Engineering Production Association", Ufa, Russian Federation,
3 JSC "Ufa Scientific and Production Enterprise "Molniya", Ufa, Russian Federation,
4 Ufa Law Institute of the Ministry of Internal Affairs of Russia, Ufa, Russian Federation
Given the multifaceted nature of the concept of business process, we will limit ourselves to defining business process as a set of interrelated activities or works aimed at creating a certain product or service for customers. From the perspective of the BPM concept, business processes are valuable resources of an enterprise and their management is part of the system of organizational activities, i.e. the organizational system of automated enterprise business process management. Research Objective. Automation, then, is also a business process whose objectives are: the development (acquisition), implementation and operation of software and hardware designed to implement new business process capabilities (which simply were not in the manual loop), optimize and increase the speed of the existing business process, improve working conditions, reduce labor requirements, etc. There is a new direction - computer integration of information. Materials and methods. It is suggested that monitoring deviations from business process requirements be used to organise regular information-technology feedback in the of automated business process management systems of an enterprise. Results. Automation of a business process endows a business process with a new feature - the ability to obtain operational data on all prescribed activities and to integrate all interacting objects of the business process in the implementation of the prescribed set of target functions. In some cases, business process automation is performed to streamline IT-related activities inside the organization. This includes the management of internal resources of the organization - financial, material, human resources, etc. Conclusion. Due to the presence of a sufficiently large number of "legacy systems", the constantly increasing dynamics of changes in the external environment and the business processes themselves, the task of ensuring the correctness of systems functioning in the absence of the current information model and the current documentation of the automated system seems relevant.
Keywords: business process, software, vendor, category theory, functor relation, software code, database.
References
1. Beniaminov E.M. Algebraicheskiye metody v teorii baz dannykh i predstavlenii znaniy [Algebraic Methods in Database Theory and Knowledge Representation]. Moscow, Nauchnyy mir Publ., 2003. 184 p.
2. Mezhdunarodnyy standart ISO 9000. Sistemy menedzhmenta kachestva. Osnovnyye polozheniya i slovar' [International standard ISO 9000. Quality management systems. Fundamentals and vocabulary]. Available at: http://www.icc-iso.ru/toclients/standard/iso_9000/.
3. IKT v gossektore [ICT in the public sector]. Electron. zhurn. CNews, 2013, no. 65, pp. 40-41. (in Russ.)
4. Bellman R., Zade L. Prinyatiye resheniy v rasplyvchatykh usloviyakh [Decision making in vague conditions]. Moscow, Mir Publ., 1976, pp. 172-215.
5. Korporativnyye khranilishcha dannykh. Integratsiya sistem. Proyektnaya dokumentatsiya [Corporate data warehouses. Integration of systems. Project documentation]. Available at: https://www.prj-exp.ru/ patterns/pattern_draft_project.php (accessed 25.11.2018).
6. Kulikov G.G., Antonov V.V., Fakhrullina A.R., Rodionova L.E. Approach to Forming the Structure of a Self-Organizing Intellectual System in the Form of a Cartesian Closed Category (on the Exam-
ple of Designing an Information Analytical Software System)]. Bulletin of PNRPU. Electrical Engineering, Information Technologies, Management Systems, 2018, no. 27, pp. 49-67. (in Russ.)
7. Sinan Aral, Erik Brynjolfsson, Marshall Van Alstyne. Technology and Information Worker Productivity. Information Systems Research, 2012, vol. 23, no. 3-part-2, pp. 849-867.
8. Kulikov G.G., Antonov V.V., Shilina M.A., Fakhrullina A.R., Rodionova L.E. Analytical software for operating with a set of real and virtual objects using the rules of cartesian closed category. Advances in Intelligent Systems Research: Proceedings of the VIth International Workshop 'Critical Infrastructures: Contingency Management, Intelligent, Agent-Based, Cloud Computing and Cyber Security' (IWCI2019). China, Atlantis Press, 2019, pp. 173-178.
9. Pospelov D.A. [Knowledge and scales in the model of the world]. Modeli mira: sb. st. [Models of the world: a collection of articles]. Moscow, 1997, pp. 69-84. (in Russ.)
10. Kulikov G.G., Antonov V.V. [The method of forming the structure of the data warehouse for an automated accounting system based on the process analysis of the subject area]. Bulletin of the Ufa State Aviation Technical University, 2006, vol. 8, no. 1 (17), pp. 60-67.
11. Mohammad Saidur Rahman, Ibrahim Khalil, Mohammed Atiquzzaman, Xun Yi. Towards privacy preserving AI based composition framework in edge networks using fully homomorphic encryption. Engineering Applications of Artificial Intelligence, 2020, vol. 94, 103737. DOI: 10.1016/j.engappai.2020.103737
12. Prasanna Matsa, Kusuma Gullamajji. To Study Impact of Artificial Intelligence on Human Resource Management. International Research Journal of Engineering and Technology, 2019, vol. 06 (08), pp.1229-1238.
13. Salas D.F., Powell W.B. Benchmarking a scalable approximate dynamic programming algorithm for stochastic control of grid-level energy storage. INFORMS Journal on Computing, 2018, vol. 30 (1), pp. 106-123. DOI: 10.1287/ijoc.2017.0768
14. Zaboleyeva-Zotova A.V., Kamayev V.A. Lingvisticheskoe obespechenie avtomatizirovannyh sistem [Linguistic support of automated systems]. Moscow, Vysshaya shkola Publ., 2008. 244 p.
15. Kulikov G.G., Antonov V.V., Fakhrullina A.R., Rodionova L.E. Formal Representation of the Model of Realization of the Functions of System Engineering Based on the Principle of the Necessary Diversity of Structural Connections. Bulletin of the South Ural State University. Ser. Computer Technologies, Automatic Control, Radio Electronics, 2017, vol. 17, no. 4, pp. 146-153. (in Russ.) DOI: 10.14529/ctcr170416
16. Kulikov G.G., Antonov V.V., Fakhrullina A.R., Rodionova L.E. [Formal model of interaction processes of software system components based on the fractal approach]. Electrical and information complexes and systems, 2018, vol. 14, no. 4, pp. 104-111. (in Russ.)
17. Kopaygorodskiy A.N. [Application of ontologies in semantic information systems]. Design Ontology, 2014, no. 4 (14), pp. 78-89. (in Russ.)
18. Rodionova L.E. [Description of the subject area for the design of a software system]. Collection of articles of the 7th All-Russian scientific and technical conference with international participation "Modern innovations in science and technology". Kursk, Universitetskaya kniga Publ., 2017, pp. 171-174. (in Russ.)
19. Khomskiy N. [Language and the problem of knowledge]. Moscow State University Bulletin. Moscow, 1996, iss. 6, pp. 157-185. (in Russ.)
20. Pavlov S.V., Efremova O.A. [Ontological model for integration of structurally heterogeneous spatial databases of various subject areas into a uniform regional database]. Design Ontology, 2017, vol. 7, no. 3 (25), pp. 323-333. (in Russ.) DOI: 10.18287/2223-9537-2017-7-3-323-333
Received 20 September 2021
ОБРАЗЕЦ ЦИТИРОВАНИЯ
FOR CITATION
Метод формирования регулярной обратной информационно-технологической связи в автоматизированных системах управления бизнес-процессами предприятия / В.В. Антонов, В.Н. Шкаров, Л.Е. Родионова и др. // Вестник ЮУрГУ. Серия «Компьютерные технологии, управление, радиоэлектроника». - 2021. -Т. 21, № 4. - С. 137-147. DOI: 10.14529/йсг210412
Antonov V.V., Shkarov V.N., Rodionova L.E., Kulikov G.G., Kolesnikov V.A. A Method of Ensuring that Deviations from Business Process Requirements Are Controlled in the Operation of the Company's Automated Systems. Bulletin of the South Ural State University. Ser. Computer Technologies, Automatic Control, Radio Electronics, 2021, vol. 21, no. 4, pp. 137-147. (in Russ.) DOI: 10.14529/ctcr210412
