CC BY
14
Раздел III. Системы поддержки принятия решений
УДК 004.832.2 DOI 10.18522/2311-3103-2021-4-88-104
А.А. Левченко, В.В. Таратухин, Ю.А. Кравченко
МЕТОД ПРИНЯТИЯ РЕШЕНИЙ ПРИ ФОРМИРОВАНИИ МОДЕЛЕЙ ТИПОВЫХ ПРОЦЕССОВ ДЛЯ ИНФОРМАЦИОННЫХ СИСТЕМ НА БАЗЕ ОБЛАЧНЫХ ТЕХНОЛОГИЙ
Статья посвящена решению задачи создания метода принятия решений при формировании типовых процессов предприятия для внедрения и использования информационных систем на базе облачных технологий, так же известных, как систем, работающих по модели SaaS (Software as a Service, Программное обеспечение как Услуга). Актуальность исследования обусловлена новизной технологии облачных вычислений и невозможностью применения методов, разработанных для систем класса on-Premise. Целью исследования является повышение эффективности использования типовых моделей предприятия при внедрении и использовании SaaS систем. Повышение эффективности обеспечивает сокращение сроков и бюджета проекта при внедрении SaaS-систем, а также эксплуатационных затрат после. Достижение цели исследования обеспечивается выполнением следующих задач: аналитический обзор области исследования на предмет имеющихся методов, формализация и постановки задачи исследования, описание элементов проектной документации, как единой системы и определение связей между структурными элементами, разработка метода принятия решений о формировании моделей типовых процессов, проверка метода через определение критерия эффективности и сравнения результатов работы метода с аналогами. Задача исследования формализована, как каноническая задача оптимизации с целевой функцией, направленной на максимизацию критерия эффективности. Критерий эффективности задан в виде формулы, описывающей степень покрытия типовыми моделями функциональных требований к целевым процессам предприятия. В статье описаны методы и алгоритмы, используемые для решения аналогичных задачи, а также приведены их недостатки и ограничения. Предложенный метод базируется на теории нечетких множеств и использует алгоритм нечеткого вывода Мамдани для связи множества функциональных требований и множества системных реализаций. На базе метода разработано программное приложение и проведен вычислительный эксперимент. Выборка для проверки метода и его сравнение с существующими аналогами формировалась на базе функциональных требований к организационным процессам управления закупками крупных предприятий и реализации данных требований в SaaS-системах на платформе SAP. Подтвержден рост значения критерия эффективности в случае применения предложенного метода, что демонстрирует его преимущество перед имеющимися альтернативными решениями после второй итерации использования. В качестве примера представлено описание типового процесса создания заявки на закупку до и после применения предложенного метода.
Информационная система; облачные технологии; SaaS; проектная документация; типовые моделей процессов предприятия; нечеткие множества.
A.A. Levchenko, V.V. Taratukhin, Yu.A. Kravchenko
DECISION-MAKING METHOD FOR TYPICAL PROCESSES MODELS FORMATION FOR CLOUD-BASED ENTERPRISE SYSTEMS
The article is devoted to solving the problem of creating a decision-making method in the formation of typical enterprise processes in information systems based on cloud technologies, also known as systems operating on the SaaS model (Software as a Service). The study's relevance is due to the novelty of cloud computing technology and the impossibility of applying the methods developed for on-Premise class systems. The study aims to improve the efficiency of using typical enterprise models in the implementation and use of SaaS systems. Increased efficiency affects the time and budget of the SaaS implementation project and operational costs after implementation. Achievement of the research goal is achieved by performing the following tasks: an analytical review of the research area for available methods, formalization and canonical formulation of the research task, description of the elements ofproject documentation as a single system of elements, and determination of relationships between them, development of a method for making decisions on the formation of models of typical processes, as structural elements of the system, verification of the method by determining the criterion for the effectiveness of the method and its comparison with the data ofpre-vious approaches. The research task is formalized as a canonical optimization problem with an objective function to maximize the efficiency criterion. The criterion of efficiency is given in the form of a formula that describes the degree of coverage offunctional requirements to the target processes of the enterprise by standard models. The article describes the methods and algorithms used to solve similar problems, as well as their disadvantages and limitations. The proposed method is based for the first time on the theory offuzzy sets and uses the Mamdani fuzzy inference algorithm to link a set offunctional requirements and a set of system implementations. On the basis of the method, a software application was developed, and a computational experiment was carried out. The sample for testing the method and its comparison with existing analogs was formed on the basis of functional requirements for organizational processes ofprocurement management of large enterprises and the implementation of these requirements in SaaS systems on the SAP platform. The growth of the value of the efficiency criterion was confirmed in the case of the application of the proposed method, which demonstrates its advantage over the available alternative solutions already at the second iteration of use. As an example, a description of a typical process for creating a purchase requisition before and after applying the proposed method is presented.
Information system; cloud technologies; SaaS; project documentation; typical models of enterprise processes; fuzzy sets.
Введение. Системы управления ресурсами предприятия (ERP системы, ERP systems, Enterprise Resource Planning Systems) построены на основе централизованной базы данных и используют единую вычислительную платформу, цель которой - консолидация операций предприятия в универсальную корпоративную системную среду [1]. По причине того, что внедрение данных систем является сложным процессом, затрагивающим функционирование фундаментальных процессов, особое внимание уделяется методологии. Классический подход к внедрению базовых ERP систем на платформе SAP основан на методологии SAP Activate, которая состоит из шести фаз: определение подхода к внедрению, подготовка проекта, проведение анализа, реализация требований, продуктивный старт и использование системы [2, 3]. Методология SAP Activate хоть и обеспечивает соответствие требованиям международного стандарта ISO 9001, однако не учитывает детализацию связей результатов каждой фазы, а также не описывает, как результаты одного проекта могут быть применимы для последующих проектов. Новые решения на проектах учитываются в документации, созданной в ходе проекта, но не отражаются в типовых моделях процессов, которые будут использоваться в последующих проектах. Модели типовых процессов, используемые при внедрении систем управления ресурсами предприятия, включают в себя описания типовых функциональных требований, шагов процессов, настроек, объектов миграции, ролей и пол-
номочий. Особое значение модели имеют в случае применения облачных технологий, в частности в случае применения модели SaaS (Software as a Service, Программное обеспечение как Услуга), когда изменение заложенных в систему функциональных возможностей невозможно или требует больших трудозатрат [20]. SaaS-системы являются третьим поколением эволюционного развития классических систем и ограничения, заложенные в систему увеличивают роль типовых моделей процессов при внедрении и использовании систем [18, 19]. Ограничения облачных технологий позволило формализовать функциональные требования по причине ограниченного числа настроек параметров системы и микро сервисной модели для реализации разработок, что было невозможно в случае on-Premise систем. Это создает новые научных задачи оптимизации сроков внедрения SaaS-систем.
Была поставлена следующая цель исследования - создание метода принятия решений при формировании моделей типовых процессов предприятий, используемых при внедрении SaaS-систем. Для достижения цели исследования требуется - формализация задачи и поиск решения, позволяющего формировать и обновлять модели на основании результатов успешных внедрений цифровых систем в РФ. Решение должно включать расширенные модели типовых процессов с акцентом на российскую специфику бизнеса и учитывать особенности облачных технологий. Были определены следующие этапы системного анализа объекта исследования:
1. Аналитический обзор области исследования на предмет имеющихся методов формирования моделей типовых процессов.
2. Формализация и постановки задачи исследования, определение критерия эффективности метода для решения задачи.
3. Описание системы множеств проектной документации, как системы структурных элементов, и ее связи с типовыми моделями процессов. Система включает документацию, которая создается и используется в ходе внедрения систем управления ресурсами предприятия, а также модели типовых процессов, которые применяются при создании проектной документации.
4. Разработка метода принятия решений о формировании моделей типовых процессов.
5. Проверка метода через определение критерия эффективности метода и его сравнения с данными предыдущих подходов.
Статья организована в соответствии с этапами исследования. Последовательное выполнение этапов позволяет решить основную задачу - создание метода принятия решений при формировании типовых процессов предприятия в информационных системах на базе облачных технологий. И в результате достигнуть цель - повышение эффективности применения типовых моделей предприятия при внедрении и использовании SaaS-систем.
1. Анализ результатов предшествующих работ. Анализ результатов предшествующих работ показал, что модели типовых процессов предприятия широко применяются на практике в ходе внедрения ERP систем. Использование типовых процессов позволяет оптимизировать всю цепочку создания стоимости, что увеличивает их ценность для предприятий [4]. Количественный пример расчёта выгод применения моделей типовых процессов для систем управления процессами предприятия приведен в работе [14]. Задача создания моделей типовых процессов не является новой и уже решалась для различных групп организационных процессов ряда индустрий. Например, модели были созданы для ряда процессов производства [13], для процесса разработки архитектуры предприятия [15], для процессов наукоемких предприятии [16], для процессов в индустрии гостиничных услуг [17]. Во всех случаях модели основываются на результатах одного или нескольких проектов внедрения систем управления ресурсами предприятия, полученных до мо-
мента написании работ. Из-за отсутствия формализованных метода формирования данных моделей и регулярных изменений требования рынка со временем модели будут неприменимы. Фокус данного исследования - это не только разовое создание моделей, а также разработка метода обновления, который позволит формировать модели и в будущем.
Так как модели типовых процессов являются частным случаем моделей процессов с учетом особенностей их реализации в системе ERP, были рассмотрены научные исследования по теме моделирования процессов. Описания функциональных требований, как правило, имеет лингвистическое представление. Поэтому при работе с моделями процессов предприятий в условиях неопределённости, нечеткая логика имеет успешное практическое применение. Вклад нечеткой логики в процесс управления инновациями был описан в работе [7], подчеркнуто практическое значение ее использования в задачах поддержки принятия решения.
Нечеткая логика решает множество задач формирования оценок. В работе [8] отмечена крайняя важность применения нечеткой логики в развитие процесса оценки бизнеса предприятий [8]. Также математический аппарат нечеткой логики был описан и применен для оценки качества реализации моделей процессов [5, 6]. Стоит отметить, что в работе [5] не только разработана новая модель нечеткой логики для применения к решению задач одного проекта внедрения, но и найдено ее применение в процессе постоянного улучшения процессов. Применение нечеткой логики выполнено для оценки характеристик процессов, например повышение индикатора устойчивости, были так же отмечены в работе [9].
Помимо решения задач поддержки принятия решений и формирования оценок нечеткая логика применяется для расширения вариативности в описании моделей процессов предприятия [11], например, для процесса оценки поставщиков облачных услуг [12]. Помимо этого, открытая нечеткая система управления может быть применена для управления заданиями ИТ-проекта, когда информация на проекте имеет слабоструктурированных характер [10].
На текущий момент наблюдается недостаток информации связанный, прежде всего, с узкой областью применения решения задачи. Применяющиеся методы базируется на эвристических подходах экспертной оценки и не формализованы в виде методов или алгоритмах. Научные работы о данных методах отсутствуют, поэтому для сравнения были взяты результаты опросы экспертов, занимающихся данной задачей на практике. Имеются близкие по тематике работы, посвящённые применению нечеткой логики для работы с организационными процессами предприятия [5, 7, 9, 11, 17]. Методы, описанные в данных работах, а также описания основных результатов фаз, согласно методологии SAP Activate [2], а также предыдущие работы автора [21, 22] послужили базой для данного исследования. Для достижения целей работы потребовалась адаптация имеющийся методов в части: расширения количества и типов элементов системы, включающей модели типовых процессов и проектную документацию; формализации метода, позволяющего формировать модели типовых процессов; описания критерия эффективности метода. Данные особенности заложены в основу исследования и определяют его научную новизну.
2. Постановка задачи. Предположим, что SaaS-система имеет n параметров S, доступных для конфигурации. Каждый параметр системы имеет 1; возможных значений , то есть для каждого имеется допустимый набор ний {v^v^ ...;vi.}, где i = 1, ..., n. Состояние системы может быть задано вектором конфигураций каждого параметра При внедрении системы на каждом проекте имеется выборка t функциональных требований R (j = 1,...,t), каждое из которых может быть реализовано ггь способами возмож-
ных конфигурации Б] ^ = 1,..., т] ) Поскольку одно состояние системы может быть определено одним целевым состоянием параметров = (Ба,Б 2 , ...,БП) , задача проекта внедрения системы определить вектор Бх , который бы позволил определить x во всех Р]. В случае отсутствия решения, требуется определить какие Р] могут быть исключены из выборки для решения задачи. Критерий для исключения Р] из выборки определяется тем, с какими затратами на выполнение настроек
и выгодами от реализации требования ассоциировано данное функ-
циональное требование. Определение значения положительной функции ^ ( Р] ) на практике осуществляется на базе экспертной оценки.
Поскольку определение векторов на практике является частной задачей проекта, значение положительной функции определяется через время ,
необходимое для поиска Б] для каждого Р]. Имеет место определение типовых функциональных требований с соответствующими определенными типовыми настройками В Б] для которых ^ = 0. То есть для которых x = 1, а В Б = Бх для случая, когда для всех) справедливо Р] = В Р]. Поскольку на практике все проекты имеют различный набор функциональных требований, данное равенство не выполняется, но имеется возможность определить те для которых Р] = В Р]. Задача оптимизации может быть задана через целевую функцию Z(P) в следующим виде:
г (Р) = ^ ( Р] ) (Л) - тах.
Обозначим, через P множество всех функциональных требований на проекте £¡_ а Р] , а через BP множество всех типовых функциональных требований £ тах в 5]. Критерий качества типовых моделей Q может быть задан через степень покрытия в следующем виде:
сг= о о од
где | Р П В Р | - мощность множества, являющимся пересечения множеств Р и ВР, | Р | - мощность множества Р. Поскольку ^ ( Р] ) всегда положительна для каждого , а функция принимает наименьшее значение при . То в случае
постановки задачи, как задачи принятия решения о формировании типовых процессов предприятия, она может быть сведена к максимизации критерия качества типовых моделей для проектов с различной выборкой P:
|РПВР| — - т ах.
Таким образом, чем больше типовых моделей было применено на проекте, тем меньше приходилось определять комбинацию необходимых настроек для каждого требования и тем меньше времени и затрат требовалось на проект в целом. Эффективность метода принятия решений при формировании моделей типовых процессов определяется процентом функциональных требований после окончания нового проекта, которые соответствовали типовым функциональным требованиям. Иначе говоря, насколько модели типовых процессов были полны для того, чтобы учесть все функциональные требования на проекте. Полное соответствие ^ = 100 %) подразумевает внедрение системы в полном соответствии с моделями типовых процессов и с минимальными трудозатратами.
3. Описание элементов системы и их связей, необходимых для решения задачи. Для решения задач исследования на первом этапе необходимо определение подхода к описанию функциональных требований и к описанию связей функ-
циональных требований с их системной реализацией. Как относящаяся к классу задач управления большими системами, задача внедрения ERP систем содержит большое число типов и количества переменных, поэтому требуется описание средствами теории множеств. Для успешного завершения проекта по внедрению системы требуется выполнить все функциональные требования в части автоматизации предприятия. Таким образом, элементы множеств - это функциональные требования и результаты, направленный на выполнение данных требований. Проектные решения и функциональные спецификации - документы, создаваемые в ходе проекта, представляют собой промежуточные результаты (множества), так как не выполняют функциональное требования, но являются необходимым элементом для достижения результата. Результат представляет собой настройку системы, разработку (протестированный программный код), миграцию в систему основных или транзакционных данных, или конфигурацию ролей и полномочий в системе. Описание моделей типовых процессов в исследовании выполняется с применением ряда допущений: на группы исследуемых процессов, на уровень их детализации, на их взаимосвязь между собой. Для сохранения единого лингвистического представления элементов функциональных требований новое требование должно входить в множество имеющихся, либо быть описано по аналогии с уже входящими в множество элементами, чтобы избежать пересечений значений.
Информационная модель связи множествами системы, предложенная авторами, представлена на рис. 1. Разработка новой информационной модели обусловлена отсутствием такой информационной модели, которая бы учитывала детализацию типовых моделей и связи между структурными элементами проектной документации.
Рис. 1. Информационная модель связи между множествами проектной документации и типовыми моделями
Как было сказано ране, элементы множеств имеют лингвистическую неопределенность, поэтому они были описаны интегрированными инструментами теории нечетких множеств и методами описаний из теории больших систем. Ниже перечислены множества проектной документации.
Множество функциональных требований имеет следующий вид:
, где - функциональное требование, -функция ограничений допустимых требований, - число требований, - нечеткое множество допустимых требований заказчика. Множество является нечетким множеством вида: , где - функциональное требование, 5 (р ) - функция принадлежности, описывающая в какой мере элемент р принадлежит нечеткому множеству . Данная функция позволяет определить соответствие требования, включенному в протокол требований, определённым рамкам проекта, - универсальное множество.
Протоколы настроек представляет собой множество настроек, необходимых для выполнения шагов процессов. Оно основывается на множестве требований и может быть представлено в следующем виде: ,
где £ - вектор объекта настройки, дг (5) - функция ограничений (учитывающая взаимную непротиворечивость настроек), ¿5 - число объектов настройки, 55 - нечеткое множество допустимых объектов настройки. Множество является множеством вида: , где - вектор объекта настройки, -функция принадлежности, - универсальное множество. Компоненты вектора следующие: , где -объект детального описания настройки, 5Г - реализация настройки в системе ^ с ^ sr cU).
Для полноты описания системы множеств проектной документации по аналогии описаны следующие множества: Концепция ролей и полномочий R; Описания шагов процессов M; Инструменты миграции данных I; Функциональные спецификации F; Концептуальный дизайн С; Сценарии тестирования Г; Инструкции пользователей . Модели типовых процессов включают шестью множеств:
Типовые функциональные требования ,
где - функциональное требование, - функция ограничений допустимых
требований, - число требований, - нечеткое множество допустимых требований заказчика, заданное ранее.
Типовые настройки , где - вектор
объекта настройки, - функция ограничений (учитывающая взаимную не-
противоречивость), ¿Ь 5 - число объектов настройки, 55 - нечеткое множество допустимых объектов настройки, описанное ранее. По аналогии заданы множества Типовых ролей и полномочий BR, типовых инструментов миграции BI, типовых функциональных спецификаций BF, типовых описаний процессов BM.
4. Разработка метода принятия решений. Из описания системы множеств проектной документации видно, что с множествами моделей типовых процессов ВР, BS, BF, В1, BR, ВМ связаны соответствующие множества Р, S, F, I, R, М. Данные множества учтены в методе принятия решений. На рис. 2 представлен предложенный метод принятия решений о формировании множеств ВР, BS, BF, В1, BR, ВМ на базе множеств Р, S, F, I, R, М который позволяет менять критерий эффективности Q через изменение множества ВР.
1. Этап формирования множества Р
На данном этапе происходит определение элементов множества Р. Из документов протоколов требований формируются элементы р, представляющие собой отдельные функциональные требования. Элементы множества имеют единую логику в описании и не повторяются.
2. Этап формирования множеств S, F, I, R, М
На данном этапе происходит определение элементов множества S, F, I, R, М. По аналогии с первым этапом, из документов протоколов настроек, функциональных спецификаций, инструментов миграции данных Ь концепции ролей и полно-
мочий формируются элементы /, I, г, т. Элементы представляют отдельные описания реализаций в виде настройки параметров системы, разработки, выполнения миграции основных данных, настройки ролей и полномочий. Элементы внутри каждого множества имеют единую логику в описании внутри множества и не повторяются.
3. Этап определения разницы множеств Р\ВР
На данном этапе выполняется определение разницы множеств Р\ВР. Новое множество содержит элементы функциональных требований, которые не включены в модели типовых процессов. Критичным для данной операции является соответствие структуры описания элементов множеств Р и ВР.
Формирование множества Р
I
Формирование множеств 5, Р, I, I*, М
1
Определение разницы
множеств Р\ВР |
Определение соответствий между множествами Р\ВР и Б, Г, 1,1«, М
I
Определение пересечении множеств 5пВ5, тВР, ШВ1, 1«пВ1?, МпВМ для
соответствующих элементов множества Р\ВР
Принятие решений о формировании множеств ВР, В5, ВР, В1, ВИ, ВМ
Рис. 2. Метод принятия решений о формировании типовых моделей процессов
4. Этап определения соответствий между множествами Р\ВР и S, F, I, R, М На данном этапе происходит определение соответствий между множествами
Р\ВР и S, F, I, R, М. Самый сложный этап с точки зрения практической реализации. Этап необходим для того, чтобы определить необходимую реализацию для функциональных требований, не включенных в модели типовых процессов. По причине того, что на практике невозможно четкое описание данного соответствия, на данном этапе используется методы нечеткой логики.
5. Определение пересечении множеств SnBS, FПBF, ЮВ^ RПBR, МПВМ для соответствующих элементов множества Р\ВР
На данном этапе происходит определение пересечений множеств SnBS, FnBF, ШВ^ RnBR и МПВМ. Выполняется это не для всех элементов множеств, в только для соответствующих элементам множества Р\ВР. Пересечения нечетких множеств S и BS задается через нечеткое множество
5пВ Б = тт (Р),РвБ(Р)) / Р.
Данный этап позволяет выделить реализации функциональных требований для случая, когда функциональное требование не было включено в модель типовых процессов, а его реализация - была включена. Данный этап необходим так как различные функциональные требования могут влиять на одни и те же реализации. Например, различные требования могут повлиять на настройку одного параметра системы. Сравнение требований к параметрам позволяет определить потенциальные конфликты настроек ЕЯР системы.
6. Принятие решений и формирование множеств ВР, ВS, BF, В!, BR, ВМ
На данном этапе выполняется принятие решений относительно включения новых функциональных требований (этап 3). Элементы Р, не меняющие вектор 5Г добавляются в выборку. В ином случае возникает так называемый конфликт настройки. Принятие решений для того случая происходит путем экспертной оценки суммы функций и в случае добавления нового элемента в
выборку и без добавления. Решение принимается для случая максимального значения . Включение новых функциональных требований может требовать изменение нечеткой модели соответствия между множествами ВР и ВS, BF, В^ BR, ВМ в части заданных правил (этап 4). Включение одних функциональных требований может потребовать исключение из множества других требований, которые вызывают конфликт настройки. На шестом этапе происходит формирование множеств ВР, ВS, BF, В^ BR, ВМ исходя из принятых решений относительно новых функциональных требований.
5. Проверка метода и исследование полученных результатов. Для определения нечеткого соответствия может быть построена МГМО-система нечеткого логического вывода типа Мамдани. Рассматривались наиболее распространенные на практике алгоритмы Мамдани и Сугено, по которым существует большое число трудов, описывающих их практическое применение и полученные результаты. Алгоритм Мамдани был выбран за счет его интуитивного и легко интерпретируемого характера базы правил (консеквенты в алгоритме Сугено не нечеткие и поэтому более трудны для интерпретации). Преимущество алгоритма Сугено в том, что в консеквентах правил Сугено может быть столько же параметров на правило, сколько входных значений, это дает больше степеней свободы в дизайне и большую гибкость при проектировании системы. Так же с точки зрения вычислений алгоритм Сугено более эффективен, потому что сложный процесс дефаззификации Мамдани заменен средневзвешенным. Однако алгоритм Сугено может быть использован для МШО-систем, когда алгоритм Мамдани так же работает для МГМО-систем. МГМО-систему можно заменить на множество МШО-систем, однако этого не было сделано для упрощения формирования правил экспертами. Поскольку данная задача решалась впервые было важно подтвердить наличие положительного результата подхода, поэтому на первой итерации не рассматривались алгоритмы Тсукамото, Ларсена, а также упрощенные алгоритмы. Рассмотрение данных алгоритмов планируется в следующих работах. Используемый алгоритм включает расчёт импликации Р в S выглядит следующим образом:
1. Введение нечеткости, через формирование базы правил, нахождение степени принадлежности для предпосылок правил. Значения параметров г и s оказываются недоступными для точного измерения, и тогда в их оценке неизбежно появляется субъективный компонент, выражаемый нечеткими оценками типа «всегда», «обычно», «может быть», «иногда», «редко», «никогда». Пример двух правил в простом виде: 1. если есть Функциональное требование га со значением функции принадлежности и есть Функциональное требование со значением
функции принадлежности ^р 5 (г2 ) , то требуется Реализация настройки 5а с функ-
цией принадлежности /SSl (s-J; 2. если есть Функциональное требование гг со значением функции принадлежности /РS20l) и есть Функциональное требование г2 со значением функции принадлежности / РS2(r2) , то требуется Реализация настройки s1 c функцией принадлежности /SS2 (sx) .
2. Агрегирование подусловий правил нечеткой продукции осуществляется при помощи нахождения степени принадлежности после операции минимум, где нечеткая импликация определяется через определение уровня «отсечения» для предпосылок каждого из правил. Целью этого этапа является определение степени истинности условий для каждого правила системы нечеткого вывода. Для каждого условия находим минимальное значение истинности всех его подусловий. Для приведенного примеры формула будет выглядеть следующим образом:
«1 = ßps^r1 П r2) = min (ßps^rj; ßPSl(r2j) ;
«2 = ßps2Oi П r2) = min (/xPS20i);ßps2(r2))-
3. Находятся «усеченные» функции принадлежности fiSS- (s-J ,ßSS'2 (s2) для предпосылок каждого правила при нечеткой композиции:
i"ssi(^i) = min I ßss } (s\))
i"ss'2(si) = minia^ßss^sS)-
4. Аккумуляция подзаключений правил нечеткой продукции проводится при помощи классического для нечеткой логики максимума объединения функций принадлежности /ssi (s J и /ss'2(s 2 ):
/xfs(s) = max [ßss\(si)-, ßss'2(sS).
5. Дефаззификация, приведение к четкости (для нахождения s1) проводится часто применимым методом по центру тяжести. Цель данного заключительного этапа - получить количественное значение для каждой из выходных лингвистических переменных. Расчёт происходит по формуле:
гтах , >. т
Lin s-ßss'^ds
гтах * ч , ■
Jmin PsS^y^J &
В ходе исследования элементы множества P формировались на базе функциональных требований, полученных в ходе семи проектов по внедрению SaaS-систем на предприятия, находящихся на территории РФ. Были проанализированы процессы, относящиеся к группе управления процессами закупки, такие как формирование годового плана закупок, регистрация и квалификация контрагентов, проведение закупочных процедур, управление контрактами, управление заявками и заказами на закупку, контроль поступления материалов и приемки услуг, управление счетами на оплату. Для формирования множеств S, F, I, R, M использовались 394 файла в форматах MS Word и MS Excel проектной документации, среди которых были концептуальные решения, описания настроек, описание разработок, реестр объектов миграции и другие документы, представляющие описанные множества данного исследования. Выборка для исследования включала следующий список индустрий: химическая промышленность, обрабатывающая промышленность, горнодобывающая промышленность, нефтегазовая промышленность, грузоперевозки и логистика, телекоммуникации, розничная торговля. В данной работе не была выполнена сегментация в зависимости от индустрии, это было отложено на следующие этапы исследования.
Было построено две модели с применением теории нечетких множеств: модель, имеющая на входе множество P\BP, на выходе - множество реализаций требований S, и модель, имеющая на входе множество P\BP, на выходе - M. Модели имеют схожую структуру, но отличаются функциями принадлежности и методиками формирования базы правил. Функции принадлежности fiPS (р) , fiss (s) и fiMS (ш) были взяты треугольного типа, так как для данных функций по сравнению с другими типами требуется наименьший объём информации, ограничивающийся данными об угловых точках. Функции принадлежности множеств , и имели пря-
моугольную форму при первоначальном описании и позже были заменены на треугольную. За основу формализации требований были использованы описания функциональных возможностей систем, так в случае решения SAP Ariba, использовались описания к 402 параметрам системы. Данные описания были определены, как первоначальные элементы множества MS. Число заложенных элементов множества P на различных проектах составляло от 105 для 280 элементов, множества PB - 97 элементов. Экспертная оценка потребовались для формирования базы правил модели, приведения описаний функциональных требований к описаниям, используемых в документах с функциональными возможностями системы, была выполнена корректировка текстовых описаний без потери семантики элементов. Данная операция была выполнена на базе семи документов, описывающих функциональные требования к системе. Экспертам предлагалось оценить влияние функциональных требований (например, «параллельное согласование заявок», «уведомление заявителя по почте о факте поступления материала на склад», «контроль бюджета при проведении закупочной процедуры») на доступные в системе настройки системы в виде лингвистических переменных, выражающими качественные оценки («требуется настройка функции Х», «может быть потребуется настройка функции Х», «скорее всего потребуется настройка функции Х», «точно потребуется настройка функции Х»). Это было заложено в нечеткую модель управления (этап 4 в модели). В текстах проектных решений и других документах MS Word были выделены области текста, связанные с первоначальными требованиями, был выполнен подбор релевантных моделей типовых процессов закупки и определена их связь с функциональными реализациями в различных частях проектной документации. Данная операция позволила привести формат исходных документов в соответствие с используемыми в исследовании множествами S и M для их применения в процессе формирования моделей типовых процессов закупки. Из анализа были исключены множества F, I, R для упрощения проведения анализа метода. Специфика облачных систем накладывает строгое ограничение на использование множества F, а множества I и R не представляют большой выгоды при внедрении по сравнению с множествами M и S. Был написан программный код, позволяющий использовать систему нечеткого вывода применительно к функциональным требованиям и их реализациям в виде настроек системы [23]. Применение экспертов было необходимо так же потребовалось для агрегирования подусловий в процессе нечеткого вывода и корректировок функции принадлежности. Удалось не только связать множество функциональных требований с их реализациями, но и выделить дефициты в моделях типовых процессов, что послужило базой для их формирования и обновления согласно предложенному методу. Данный метод демонстрирует современные вызовы к подобным задачам принятия решений, которые могут быть решены использованием технологии искусственного интеллекта. Технология может быть применена на шагах 1, 2 и 6 метода для оптимизации задачи экспертных оценок и является темой дальнейших исследований.
В ходе исследования были сформированы 32 модели типовых процессов. Это позволило увеличить значение критерия эффективности, на базе функциональных требований исследуемых проектов, с 32 % до 67 %. Сформированные модели были
применены на проекте внедрения в индустрии розничной торговли, получены положительные отзывы. В табл. 1 приведены результаты расчёта критерия эффективности моделей типовых процессов на базе семи проектов.
Таблица 1
Зависимость критерия эффективности от количества новых проектов.
Номер Мощность Мощность Количество Критерий
проекта множества P множества S правил нечеткой эффективности
для проекта модели метода
0 97 402 243 -
1 201 411 280 32%
2 108 413 285 56%
3 237 410 314 73%
4 105 412 352 61%
5 202 412 361 62%
6 163 412 366 64%
7 280 412 367 67%
Первая строка отражает показатели моделей типовых процессов до начала из формирования. Множество P формировалось на основании проектных документа-ций каждый раз независимо. Множество S отражает набор параметров конфигурации ERP системы. Количество правил нечеткой модели увеличивалось каждый раз при появлении новых функциональных требований. Критерий эффективности рассчитывался по отношению к функциональным требованиям по каждому проекту независимо. Стоит отметить повышение эффективности модели при увеличении числа входных данных.
Сравнение результатов работы метода было произведено со стандартным эвристическим методом, который на базе экспертной оценки позволял сократить трудозатраты проекта независимо от количества итераций на 10 %. Предложенный метод показал преимущество начиная с достижения критерия эффективности, более 56 % и больше. Результаты приведены в виде графика на рис. 3. Затраты на реализацию предложенного метода были оценены в 60 дней трудозатрат на первоначальную настройку и 5 дней для внесения в систему новой выборки, в сравнение с 35 днями стандартного метода, что делает применение метода целесообразным после пятого проекта.
Рис. 3. Сравнение работы стандартного метода и предложенного метода в виде зависимости оценки трудозатрат проекта от критерия эффективности метода
принятия решений
На рис. 4 и 5 представлены два описания типового организационного процесса «Создание заявки на закупку материалов по неосновной деятельности» до и после использования метода.
' Добавление товара - I О—* - -<*> —► товара вручную
1 1 "" ' -----*ф
Рис. 4. Описание типового организационного процесса создания заявки до применения метода
Рис. 5. Описание типового организационного процесса создания заявки после
применения метода
В процессе принятия решений были обнаружены требования, специфичные для РФ. Например, требуется присутствие записи материала и кода материала в каждой заявке на закупку для корректной приемки товара на склад и для формирования финансовых проводок в соответствии с правилами бухгалтерского учета РФ. Также было обнаружено требование к копированию позиций заявки из прошлых заявок. Функциональное требование обусловлено тем фактом, что заявители часто заказывают позиции, которые заказывали ранее. Данные требования не были не были учтены в моделях типовых процессов и поэтому на каждом проекте требовали дополнительных затрат.
Основные трудности в применении метода на практике относятся к двум группам. Первая группа включает сложности при приведении функциональных требований в соответствие формату моделей типовых процессов. Ряд функциональных требований имели общий характер (например, «наличие среды для проведения тестирования системы»), данные требования не могли быть связаны с настройками системы, так как их реализация уже была заложена в базовую архитектуру системы и не поддается изменению, поэтому они были исключены из исследования. Подобные сложности решаются вовлечением экспертов на этапе формирования множества Г в методе принятия решений. Вторая группа трудностей
включает сложности при выделении групп процессов закупки и общего множества функциональных требований к ERP системе. Это возникает в случае, когда проект внедрения затрагивает сразу несколько ключевых процессов предприятия. Сложности второй группы отсутствуют в случае внедрения отдельных систем управления процессами закупки крупных предприятий.
Заключение. В результате исследования был создан метод принятия решений о формировании моделей типовых процессов, используемых при внедрении систем управления ресурсами предприятия. Была формализовна задача и выполнен поиск решения, позволяющего формировать модели на основании результатов успешных внедрений систем управления ресурсами предприятия в РФ. Были расширены модели типовых процессов в части учета российской специфики бизнеса и особенностей облачных технологий. Было выполнено описание системы множеств проектной документации на базе теории больших систем и теории нечетких множеств. Система включают документацию, создаваемую и используемую при внедрении систем управления ресурсами предприятия, а также модели типовых процессов, которые используются при создании проектной документации. Выполнен анализ связей моделей типовых процессов и проектной документации. Задан критерий эффективности метода для оценки достижения целей исследования. Описан метод принятия решений о формировании моделей на базе теории больших систем и с применением теории нечетких множеств. Выполнена проверка метода и выполнен расчёт критерия эффективности метода.
Проверка метода выполнялась на базе функциональных требований к процессам управления закупками крупных предприятий и реализации требований в системах на платформе SAP. Подтвержден рост значения критерия эффективности при применении предложенного метода. Представлены описания типового процесса создания заявки до и после применения метода. Полученные результаты позволили заложить основу подхода к формированию моделей в процессе обновлений функционала систем управления ресурсами предприятия с применением облачных технологий.
В последнее время увеличивается число проектов по переходу на облачные системы управления ресурсами предприятия в рамках задач компании по повышению операционной эффективности бизнеса, по расширению предприятия и по сокращению издержек, в том числе за счет снижения стоимости поддержки корпоративных систем. Метод расширения моделей типовых моделей для данных проектов позволяет уменьшить риски проекта, уменьшить необходимое время на проектирование и реализацию, и как результат уменьшить стоимость проекта.
Планируется дальнейшая работа в части увеличения данных с новых проектов внедрения, сегментация моделей на индустрии, введение новых функциональных областей процессов. А также расчет критерия эффективности метода при добавлении операторов понижения контрастности нечетких множеств и использовании более сложных функции принадлежности на этапе определения соответствий множеств в предложенном методе.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Monk E., Wagner B. Concepts in Enterprise Resource Planning. - 4th ed. - Boston: Cengage Learning, 2012. - 272 p.
2. Denecken S., Musil J., Santhanam S. SAP Activate. - Quincy: Rheinwerk Publishing, 2020. - 600 p.
3. Kalaimani J. SAP Project Management Pitfalls: How to Avoid the Most Common Pitfalls of an SAP Solution. - 4th ed. - NY.: Apress, 2015. - 350 p.
4. Km H.M., Ramkaran R. Best practices in e-business process management: Extending a reengineering framework // Business Process Management Journal. - 2004. - No. 10 (1). - P. 27-43.
5. Figueroa-Garcia J.C., Kalenatic D., Lopez-Bello C.A. A Fuzzy Evaluation of Projects for Business Processes' Quality Improvement // Intelligent Systems Reference Library. - 2015.
- No. 87. - P. 559-579.
6. Yahya F., Boukadi K., Ben Abdallah H., Maamar Z. A fuzzy logic-based approach for assessing the quality of business process models // International Conference on Software Technologies: Proceedings of the 12th International Conference on Software. - Madrid, 2017. - P. 61-72.
7. Alfaro Garcia V.G., Gil-Lafuente A.M., Alfaro Calderon G.G. A Fuzzy Logic approach towards innovation measurement // Global Journal of Business Research. - 2015. - No. 9. - P. 53-71.
8. Beraza J.M., Rodríguez A. A Paradigm Shift in Business Valuation Process Using Fuzzy Logic // Soft Computing in Management and Business Economics. - 2012. - No. 287. - P. 61-75.
9. Safitri N.L., Intani Budiawati G. Improving Business Process by Evaluating Enterprise Sus-tainability Indicators Using Fuzzy Rule Based Classification // Creative Technology for Human Life: Proceedings of 2018 International Seminar on Application for Technology of Information and Communication. - Semarang, 2018. - P. 55-60.
10. Диязитдинова А.Р., Лиманова Н.И. Использование нечетко-множественного подхода при управлении заданиями ИТ-проекта // Программные продукты и системы. - 2019.
- Т. 32, № 1. - С. 5-11.
11. Thomas O., Adam O., Loos P. Using reference models for business process improvement: A fuzzy paradigm approach // Lecture Notes in Informatics (LNI): Proceedings - Series of the Gesellschaft fur Informatik (GI) - Germany, 2006. - P. 47-57.
12. Paunovic M., Ralevic N.M., Gajovic V., Vojinovic B.M., Milutinovic O. Two-Stage Fuzzy Logic Model for Cloud Service Supplier Selection and Evaluation // Mathematical Problems in Engineering. - 2018. - No. 1. - P. 1-11.
13. Taratoukhine V., Yadgarova Y., Skachko E. A Fuzzy Multiagent Approach for Integrated Product Life Cycle Environment // Recent Developments and New Direction in Soft-Computing Foundations and Applications. - 2016. - No. 342. - P. 99-110.
14. Левина А.И., Ильин И.В., Эседулаев Р.А. Повышение эффективности проектов внедрения информационных систем класса BPMS с использованием типовых проектных решений // Наука и бизнес: пути развития. - 2017. - № 4. - C. 9-14.
15. Штейнгарт Е.А., Бурмистров А.Н. Обзор и сравнительная характеристика методологий разработки архитектуры предприятий // Научно-технические ведомости СПБГПУ. Экономические науки. - 2016. - № 3 (245). - С. 111-129.
16. Ilyin I.V. Developing a reference model of the information system architecture of high-tech enterprises // Научно-технические ведомости Санкт-Петербургского государственного политехнического университета. Экономические науки. - 2015. - № 5 (228). - С. 97-107.
17. Топольник В.Г., Крылова Л.В. Функциональное моделирование процессов оказания гостиничных услуг // Экономика, предпринимательство и право. - 2017. - Т. 7, № 3. - C. 185-207.
18. Belet T., Purcarea A. The Evolution of Enterprise Resource Planning Systems // International Journal of Advanced Engineering, Management and Science. - 2017. - Vol. 3, No. 12.
- P. 1091-1095.
19. Katuu S. Enterprise Resource Planning: Past, Present, and Future // New Review of Information Networking. - 2020. - No. 25 (1). - P. 37-46.
20. BjellandE., HaddaraM. Evolution of ERP Systems in the Cloud: A Study on System Updates // Systems. - 2018. - No. 6 (2). - P. 22-48.
21. Levchenko A.A., Taratukhin V.V. Reference Business Processes-Based Method for Multi-Tenant SaaS Architecture Deployment and Adaptation // Proceedings of the 28th Conference of Open Innovations Association FRUCT. Vol. 1. - Finland: FRUCT Oy, 2021. - P. 264-270.
22. Левченко А.А., Таратухин В.В. Оптимизация модели управления корпоративной цифровой системой, предоставляемой по модели SaaS, с позиции компании-производителя // Тр. Международного научно-технического конгресса «Интеллектуальные системы и информационные технологии - 2020» («ИС & ИТ-2020», «IS&IT'20»): Научное издание в 2-х т. Т. 1. - Таганрог: Изд-во Ступина С.А., 2020. - C. 500-503.
23. Свидетельство 2021661837. Система поддержки принятия решений при выборе типовых процессов предприятия в области закупки: программа для ЭВМ / А.А. Левченко, В.В. Таратухин (RU); правообладатель А.А. Левченко, В.В. Таратухин (RU). № 2021660800; заявл. 30.06.21; опубл. 16.07.2021. 3,56 Мб.
REFERENCES
1. Monk E., Wagner B. Concepts in Enterprise Resource Planning. 4th ed. Boston: Cengage Learning, 2012, 272 p.
2. Denecken S., Musil J., Santhanam S. SAP Activate. Quincy: Rheinwerk Publishing, 2020, 600 p.
3. Kalaimani J. SAP Project Management Pitfalls: How to Avoid the Most Common Pitfalls of an SAP Solution. 4th ed. NY.: Apress, 2015, 350 p.
4. Kim H.M., Ramkaran R. Best practices in e-business process management: Extending a reengineering framework, Business Process Management Journal, 2004, No. 10 (1), pp. 27-43.
5. Figueroa-Garcia J.C., Kalenatic D., Lopez-Bello C.A. A Fuzzy Evaluation of Projects for Business Processes' Quality Improvement, Intelligent Systems Reference Library, 2015, No. 87, pp. 559-579.
6. Yahya F., Boukadi K., Ben Abdallah H., Maamar Z. A fuzzy logic-based approach for assessing the quality of business process models, International Conference on Software Technologies: Proceedings of the 12th International Conference on Software. Madrid, 2017, pp. 61-72.
7. Alfaro Garcia V.G., Gil-Lafuente A.M., Alfaro Calderon G.G. A Fuzzy Logic approach towards innovation measurement, Global Journal of Business Research, 2015, No. 9, pp. 53-71.
8. Beraza J.M., Rodriguez A. A Paradigm Shift in Business Valuation Process Using Fuzzy Logic, Soft Computing in Management and Business Economics, 2012, No. 287, pp. 61-75.
9. Safitri N.L., Intani Budiawati G. Improving Business Process by Evaluating Enterprise Sus-tainability Indicators Using Fuzzy Rule Based Classification, Creative Technology for Human Life: Proceedings of 2018 International Seminar on Application for Technology of Information and Communication. Semarang, 2018, pp. 55-60.
10. Diyazitdinova A.R., Limanova N.I. Ispol'zovanie nechetko-mnozhestvennogo podkhoda pri upravlenii zadaniyami IT-proekta [Using a fuzzy-multiple approach when managing tasks of an IT project], Programmnye produkty i sistemy [Software products and Systems], 2019, Vol. 32, No. 1, pp. 5-11.
11. Thomas O., Adam O., Loos P. Using reference models for business process improvement: A fuzzy paradigm approach, Lecture Notes in Informatics (LNI): Proceedings - Series of the Gesellschaft fur Informatik (GI) - Germany, 2006, pp. 47-57.
12. Paunovic M., Ralevic N.M., Gajovic V., Vojinovic B.M., Milutinovic O. Two-Stage Fuzzy Logic Model for Cloud Service Supplier Selection and Evaluation, Mathematical Problems in Engineering, 2018, No. 1, pp. 1-11.
13. Taratoukhine V., Yadgarova Y., Skachko E. A Fuzzy Multiagent Approach for Integrated Product Life Cycle Environment, Recent Developments and New Direction in Soft-Computing Foundations and Applications, 2016, No. 342, pp. 99-110.
14. Levina A.I., Il'in I.V., Esedulaev R.A. Povyshenie effektivnosti proektov vnedreniya informatsionnykh sistem klassa BPMS s ispol'zovaniem tipovykh proektnykh resheniy [Improving the efficiency of projects for the implementation of BPMS-class information systems using standard design solutions], Nauka i biznes: puti razvitiya [Science and Business: ways of development], 2017, No. 4, pp. 9-14.
15. Shteyngart E.A., Burmistrov A.N. Obzor i sravnitel'naya Charakteristika metodologiy razrabotki arkhitektury predpriyatiy [Review and comparative characteristics of methodologies for the development of enterprise architecture], Nauchno-tekhnicheskie vedomosti SPBGPU. Ekonomicheskie nauki [Scientific and Technical Vedomosti of SPBGPU. Economic sciences], 2016, No. 3 (245), pp. 111-129.
16. Ilyin I.V. Developing a reference model of the information system architecture of high-tech enterprises, Nauchno-tekhnicheskie vedomosti Sankt-Peterburgskogo gosudarstvennogo politekhnicheskogo universiteta. Ekonomicheskie nauki [Scientific and Technical Bulletin of the St. Petersburg State Polytechnic University. Economic sciences], 2015, No. 5 (228), pp. 97-107.
17. Topol'nik V.G., Krylova L.V. Funktsional'noe modelirovanie protsessov okazaniya gostinichnykh uslug [Functional modeling of the processes of providing hotel services], Ekonomika, predprinimatel'stvo ipravo [Economics, entrepreneurship and law], 2017, Vol. 7, No. 3, pp. 185-207.
18. Belet T., Purcarea A. The Evolution of Enterprise Resource Planning Systems, International Journal of Advanced Engineering, Management and Science, 2017, Vol. 3, No. 12, pp. 1091-1095.
19. Katuu S. Enterprise Resource Planning: Past, Present, and Future, New Review of Information Networking, 2020, No. 25 (1), pp. 37-46.
20. Bjelland E., Haddara M. Evolution of ERP Systems in the Cloud: A Study on System Updates, Systems 2018, No. 6 (2), pp. 22-48.
21. Levchenko A.A., Taratukhin V.V. Reference Business Processes-Based Method for Multi-Tenant SaaS Architecture Deployment and Adaptation, Proceedings of the 28th Conference of Open Innovations Association FRUCT. Vol. 1. Finland: FRUCT Oy, 2021, pp. 264-270.
22. Levchenko A.A., Taratukhin V. V. Optimizatsiya modeli upravleniya korporativnoy tsifrovoy sistemoy, predostavlyaemoy po modeli SaaS, s pozitsii kompanii-proizvoditelya [Optimization of the corporate digital system management model provided by the SaaS model from the position of the manufacturing company], Tr. Mezhdunarodnogo nauchno-tekhnicheskogo kongressa «InteUektual'nye sistemy i informatsionnye tekhnologii - 2020» («IS & IT-2020», «IS&IT'20»): Nauchnoe izdanie v 2-kh t. T. 1 [Proceedings of the International scientific and technical Congress "Intelligent systems and information technology - 2020" ("IP & it-2020", "IS&IT'20"): Scientific publication in 2 vol. Vol. 1]. Taganrog: Izd-vo Stupina S.A., 2020, pp. 500-503.
23. Levchenko A.A., Taratukhin V.V. Svidetel'stvo 2021661837. Sistema podderzhki prinyatiya resheniy pri vybore tipovykh protsessov predpriyatiya v oblasti zakupki: programma dlya EVM [Certificate 2021661837. Decision support system for choosing typical enterprise processes in the field of procurement: computer program]; copyright holder A.A. Levchenko, V.V. Taratukhin (RU). No. 2021660800; appl. 30.06.21; publ. 16.07.2021. 3,56 Mb.
Статью рекомендовал к опубликованию к.т.н. Н.М. Головин.
Левченко Артем Андреевич - Воронежский государственный университет; e-mail: artem.levchenko@sap.com; г. Воронеж, Россия; тел.: 84732207521; кафедра информационных технологий управления; соискатель.
Таратухин Виктор Владимирович - Национальный исследовательский университет «Высшая школа экономики»; e-mail: vtaratoukhine@hse.ru; г. Москва, Россия; тел.: 84957713232; базовая кафедра SAP; профессор.
Кравченко Юрий Алексеевич - Южный федеральный университет; e-mail: yakravchenko@sfedu.ru; г. Таганрог, Россия; тел.: 88634371651; кафедра систем автоматизированного проектирования; доцент.
Levchenko Artem Andreevich - Voronezh State University; e-mail: artem.levchenko@sap.com; Voronezh, Russia; phone: +74732207521; the department of management information technologies; PHD student.
Taratukhine Victor Vladimirovich - Higher Education "National Research University Higher School of Economics"; e-mail: vtaratoukhine@hse.ru; Moscow, Russia; phone: 84957713232; the base department of SAP; professor.
Kravchenko Yury Alekseevich - Southern Federal University; e-mail: yakravchenko@sfedu.ru; Taganrog, Russia; phone: +78634371651; the department of computer aided design; associate professor.
