Интеллектуальные системы поддержки принятия решений — краткий обзор

Дисклеймер

Целью написания этой статьи было сделать краткий обзор принципов построения Интеллектуальных Систем Поддержки Принятия Решений (ИСППР), роли машинного обучения, теории игр, классического моделирования и примеров их использования в СППР. Целью статьи не является забуриться вглубь тяжелой теории автоматов, самообучаемых машин, равно как и инструментов BI.

Введение

Существет несколько определений ИСППР, которые, в общем-то, крутятся вокруг одного и того же функционала. В общем виде, ИСППР — это такая система, которая ассистирует ЛПР (Лицам, Принимающим Решения) в принятии этих самых решений, используя инструментарии дата майнинга, моделирования и визуализации, обладает дружелюбным (G)UI, устойчива по качеству, интерактивна и гибка по настройкам.

С начала 80-х уже можно говорить о формировании подклассов СППР, таких как MIS (Management Information System), EIS (Executive Information System), GDSS (Group Decision Support Systems), ODSS (Organization Decision Support Systems) и др. По сути, эти системы представляли собой фреймворки, спососбные работать с данными на различных уровнях иерархии (от индивидуального до общеорганизационного), а внутрь можно было внедрить какую угодно логику. Примером может служить разработанная Texas Instruments для United Airlines система GADS (Gate Assignment Display System), которая поодерживала принятие решений в Field Operations — назначение гейтов, определение оптимального времени стоянки и т.п.

В конце 80-х появились ПСППР (Продвинутые — Advanced), которые позволяли осуществлять «what-if» анализ и использовали более продвинутый инструментарий для моделирования.

Наконец, с середины 90-х на свет стали появляться и ИСППР, в основе которых стали лежать инструменты статистики и машинного обучения, теории игр и прочего сложного моделирования.

Многообразие СППР

На данных момент существует несколько способов классификации СППР, опишем 3 популярных:

По области применения

По соотношению данные\модели (методика Стивена Альтера)

По типу использумого инструментария

Я требую жалобную книгу! нормальную СППР

Несмотря на такое многообразие вариантов классификаций, требования и атрибуты СППР хорошо ложатся в 4 сегмента:

Отдельно отметим такие важные атрибуты, как масштабируемость (в ныне одном подходе agile никуда без этого), способность обрабатывать плохие данные, юзабилити и user-friendly interface, нетребовательность к ресурсам.

Архитектура и дизайн ИСППР

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

Действительно, СППР вполне можно разделить на 4 больших слоя:

На схеме ниже представляю мое видение архитектуры, с описанием функционала и примерами инструментов:

С архитектурой более или менее понятно, перейдем к дизайну и собственно построению СППР.

В прицнипе, тут нет никакого rocket science. При построении ИСППР необходимо придерживаться следующих шагов:

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

Подчеркну, что это только ИМХО и вы можете сами сделать удобный для себя чек-лист.

А где тут машинное обучение и теория игр?

Да практически везде! По крайней мере в слое, связанном с моделированием.

С одной стороны, есть классические домены, назовем их «тяжелыми», вроде управления цепями поставок, производства, запасов ТМЦ и проч. В тяжелых доменах наши с вами любимые алгоритмы могут привнести дополнительные инсайты для зарекомендовавших себя классических моделей. Пример: предиктивная аналитика по выходам из строя оборудования (машинное обучение) отлично сработается с каким-нибудь FMEA анализом (классика).

С другой стороны, в «легких» доменах, вроде клиентской аналитики, предсказании churn, выплаты кредитов — алгоритмы машинного обучения будут на первых ролях. А в скоринге, например, можно совмещать классику с NLP, когда решаем выдавать ли кредит на основе пакета документов (как раз-таки document driven СППР).

Классические алгоритмы машинного обучения

Допустим, есть у нас задачка: менеджеру по продажам стальной продукции надо еще на этапе получения заявки от клиента понимать, какого качества готовая продукция поступит на склад и применить некое управляющее воздействие, если качество будет ниже требуемого.

Поступаем очень просто:

Шаг 0. Определяем целевую переменную (ну, например, содержание оксида титана в готовой продукции)
Шаг 1. Определяемся с данными (выгружаем из SAP, Access и вообще ото всюду, куда дотянемся)
Шаг 2. Собираем фичи\генерим новые
Шаг 3. Рисуем процесс data flow и запускаем его в продакшн
Шаг 4. Выбираем и обучаем модельку, запускаем ее крутиться на сервере
Шаг 5. Определяем feature importances
Шаг 6. Определяемся со вводом новых данных. Пусть наш менеджер их вводит, например, руками.
Шаг 7. Пишем на коленке простой web-based интерфейс, куда менеджер вводит ручками значения важных фич, это крутится на серваке с моделькой, и в тот же интерфейс выплевываестя прогнозируемое качество продукции

Вуа-ля, ИСППР уровня детсад готова, можно пользоваться.

Подобные «простые» алгоритмы также использует IBM в своей СППР Tivoli, которая позволяет определять состояние своих супер-компьютеров (Watson в первую очередь): на основе логов выводится информация по перформансу Watson, прогнозируется доступность ресурсов, баланс cost vs profit, необходимость обслуживания и т.п.

Компания ABB предлагает своим клиентам DSS800 для анализа работы электродвигателей той же ABB на бумагоделательной линии.

Финская Vaisala, производитель сенсоров для минтранса Финляндии использует ИСППР для предсказания того, в какие периоды необходимо применять анти-обледенитель на дорогах во избежания ДТП.

Опять-таки финская Foredata предлагает ИСППР для HR, которая помогает принимать решения по годности кандидата на позицию еще на этапе отбора резюме.

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

Обычные нейронные сети

Кроме простого ML, в СППР отлично ложится и Deep Learning.

Некоторые примеры можно найти в ВПК, например в американской TACDSS (Tactical Air Combat Decision Support System). Там внутри крутятся нейронки и эволюционные алгоритмы, помогающие в определении свой-чужой, в оценке вероятности попадания при залпе в данный конкретный момент и прочие задачки.

В немного более реальном мире можно рассмотреть такой пример: в сегменте B2B необходимо определить, выдавать ли кредит организации на основе пакета документов. Это в B2C вас оператор замучает вопросами по телефону, проставит значения фич у себя в системе и озвучит решение алгоритма, в B2B несколько посложнее.

ИСППР там может строиться так: потенциальный заемщик приносит заранее согласованный пакет документов в офис (ну или по email присылает сканы, с подписями и печатями, как положено), документы скармливаются в OCR, затем передаются в NLP-алгоритм, который дальше уже делит слова на фичи и скармливает их в NN. Клиента просят попить кофе (в лучшем случае), или вот где карту оформляли туда и идите прийти после обеда, за это время как раз все и обсчитается и выведет на экран девочке-операционисту зеленый или красный смайлик. Ну или желтый, если вроде ок, но нужно больше справок богу справок.

Подобными алгоритмами пользуются также в МИД: анкета на визу + прочие справки анализируются прямо в посольстве \ консульстве, после чего сотруднику на экране высвечивается один из 3 смайликов: зеленый (визу выдать), желтый (есть вопросы), красный (соискатель в стоп-листе). Если вы когда-нибудь получали визу в США, то то решение, которое озвучивает вам сотрудник консульства — это именно результат работы алгоритма в совокупности с правилами, а никак не его личное субъективное мнение о вас:)

В тяжелых доменах известны также СППР на основе нейронок, определяющие места накопления буфера на производственных линиях (см, напимер, Tsadiras AK, Papadopoulos CT, O’Kelly MEJ (2013) An artificial neural network based decision support system for solving the buffer allocation problem in reliable production lines. Comput Ind Eng 66(4):1150–1162), Общие Нечеткие Нейронные Сети на основе мин-макса (GFMMNN) для кластеризации потребителей воды (Arsene CTC, Gabrys B, Al-Dabass D (2012) Decision support system for water distribution systems based on neural networks and graphs theory for leakage detection. Expert Syst Appl 39(18):13214–13224) и другие.

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

Байесовские сети

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

Динамические данные обновляются во времени, соответственно, паттерн работы модели будет такой: обучение-решение-обучение, что в общем похоже на работу врача: примерно определить диагноз, прокапать лекарство, посмотреть за реакцией. Таким образом, мы постоянно пребываем в состоянии неопределенности, подействует лечение или нет. И состояние пациента меняется динамически. Т.е. нам надо построить динамическую СППР, причем еще и knowledge driven.

В таких случаях нам отлично помогут Динамические Байесовские Сети (ДБС) — обобщение моделей на основе фильтров Калмана и Скрытой Марковской Модели.

Разделим данные по пациенту на статические и динамические.

Если бы мы строили статическую байесовскую сетку, то нашей задачей было бы посчитать следующую вероятность:

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

Статическая сетка выглядит так:

Но это не айс. Состояние пациента меняется, время идет, надо решать, как же его лечить.

Вот для этого и применим ДБС.

Сначала, в день приема пацитента, строим статическую сетку (как на картинке выше). Потом, в каждый день i строим сетку на основе динамически меняющихся данных:

Соответственно, совокупная модель примет следующий вид:

Таким, образом, результат мы расчитаем по следующей формуле:

, где T — совокупное время госпитализации, N — количество переменных на каждом из шагов ДБС.

Внедрить эту модель в СППР необходимо несколько иначе — скорее тут надо идти от обратного, сначала эту модель зафиксировать, а потом строить интерфейс вокруг. Т.е., по сути, мы сделали хард модель, внутри которой динамические элементы.

Теория игр

Теория игр, в свою очередь, гораздо лучше подойдет для ИСППР, созданных для принятия стратегических решений. Приведем пример.

Допустим, на рынке существует олигополия (малое количество соперников), есть определенный лидер и это (увы) не наша компания. Нам необходимо помочь менеджменту принять решение об объемах выпускаемой нами продукции: если мы будем выпускать продукцию в объеме , а наш соперник — , уйдем мы в минус или нет? Для упрощения возьмем частный случай олигополии — дуополию (2 игрока). Пока вы думаете, RandomForest тут или CatBoost, я вам предложу использовать классику — равновесие Штакельберга. В этой модели поведение фирм описывается динамической игрой с полной совершенной информацией, при этом особенностью игры является наличие лидирующей фирмы, которая первой устанавливает объём выпуска товаров, а остальные фирмы ориентируются в своих расчетах на неё.
Для решения нашей задачи нам надо всего-то посчитать такое , при котором решится задача оптимизации следующего вида:

Для ее решения (сюрприз-сюрприз!) надо лишь приравнять первую производную по к нулю.

При этом для такой модели нам понадобится знать только предложение на рынке и стоимость за товар от нашего конкурента, после чего построить модель и сравнить получившееся q с тем, которое хочет выкинуть на рынок наш менеджмент. Согласитесь, несколько проще и быстрее, чем пилить NN.

Для таких моделей и СППР на их основе подойдет и Excel. Конечно, если вводимые данные надо посчитать, то нужно что-то посложнее, но не сильно. Тот же Power BI справится.

Искать победителя в битве ML vs ToG бессмысленно. Слишком разные подходы к решению задачи, со своими плюсами и минусами.

Что дальше?

С современным состоянием ИСППР вроде бы разобрались, куда идти дальше?

В недавнем интервью Джуда Перл, создатель тех самых байесовских сетей, высказал любопытное мнение. Если слегка перефразировать, то

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

Скорее всего, вангую, через лет 10 мы перестанем жестко хардкодить модели, и начнем вместо этого повсеместно обучать компьютеры в создаваемых симулируемых средах. Наверное, по этому пути и пойдет реализация ИСППР — по пути AI и прочих скайнетов и WAPR’ов.

Если же посмотреть на более близкую перспективу, то будущее ИСППР за гибкостью решений. Ни один из предложенных способов (классические модели, машинное обучение, DL, теория игр) не универсален с точки зрения эффективности для всех задач. В хорошей СППР должны сочетаться все эти инструменты + RPA, при этом разные модули должны использоваться под разные задачи и иметь разные интерфейсы вывода для разных пользователей. Этакий коктейль, смешанный, но ни в коем случае не взболтанный.

Источник

Системы поддержки принятия решений

СППР возникли в результате слияния управленческих информационных систем и систем управления базами данных.

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

Система поддержки решений СППР решает две основные задачи:

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

Некоторые из этих методов были разработаны в рамках искусственного интеллекта. Если в основе работы СППР лежат методы искусственного интеллекта, то говорят об интеллектуальной СППР или ИСППР.

Близкие к СППР классы систем — это экспертные системы и автоматизированные системы управления.

Система позволяет решать задачи оперативного и стратегического управления на основе учетных данных о деятельности компании.

Система поддержки принятия решений представляет собой комплекс программных инструментальных средств для анализа данных, моделирования, прогнозирования и принятия управленческих решений, состоящий из собственных разработок корпорации и приобретаемых программных продуктов (Oracle, IBM, Cognos).

Теоретические исследования в области разработки первых систем поддержки принятия решений проводились в технологическом институте Карнеги в конце 50-х начале 60-х годов XX века. Объединить теорию с практикой удалось специалистам из Массачусетского технологического института в 60-х годах. В середине и конце 80-х годов XX столетия стали появляться такие системы, как EIS, GDSS, ODSS. В 1987 году компания Texas Instruments разработала для United Airlines Gate Assignment Display System. Это позволило значительно снизить убытки от полетов и отрегулировать управление различными аэропортами, начиная от Международного аэропорта O’Hare в Чикаго и заканчивая Stapleton в Денвере, штат Колорадо. В 90-х годах сфера возможностей СППР расширялась благодаря внедрению хранилищ данных и инструментов OLAP. Появление новых технологий отчетности сделало СППР незаменимой в менеджменте.

Классификации СППР

По взаимодействию с пользователем выделяют три вида СППР:

По способу поддержки различают:

По сфере использования выделяют:

Общесистемные работают с большими СХД и применяются многими пользователями. Настольные являются небольшими системами и подходят для управления с персонального компьютера одного пользователя.

Архитектура СППР

Функциональные СППР

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

СППР, использующие независимые витрины данных

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

СППР на основе двухуровневого хранилища данных

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

СППР на основе трехуровневого хранилища данных

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

Структура СППР

Выделяют четыре основных компонента:

Динамическое моделирование

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

Решаемые вопросы

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

Использование системы позволяет найти ответы на множество вопросов, возникающих у руководителей компании, например:

У генерального директора:

У руководителя отдела по работе с партнерами:

У руководителя финансового департамента:

У руководителя департамента бюджетного планирования и контроля:

У руководителя департамента закупок:

У руководителя планового отдела (отдела стратегического планирования):

У руководителя отдела сервисного обслуживания:

У руководителя отдела кадров:

У руководителя отдела анализа качества:

Процесс создания системы управленческой отчетности, анализа данных и поддержки принятия решений состоит из следующих этапов :

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

Источник

Часть 1. Платформа СППР Универсальные алгоритмы

Приветствую, уважаемое сообщество!
Забегая вперед прошу прощения у тех, кто ожидает новизны или революционных идей. Их тут нет. Но есть вполне хорошая прикладная система.

Системы поддержки принятия решений сейчас набирают обороты. Причем я не буду особо останавливаться на перечислении способов реализации. Оговорюсь только об основных свойствах. Я бы очень упрощенно и обобщенно назвал эти системы вероятностными. То есть они выдают рекомендации с известной долей вероятности используя накопленную и проанализированную статистику. Не скажу что это плохо. Тема BigData и Machine learning нынче в тренде. Так же эти системы работают по принципу черного ящика. Поэтому проверить достоверность работы заложенной модели не всегда можно выявить.

Я же постараюсь описать систему поддержки принятия решений основанную на несколько другом, кто-то может скажет и архаичном, принципе – условно назовем его оценочным. То есть система моделирует принцип того как человек реально действует – оценивает ситуацию и принимает решение на основе сделанной оценки в этой конкретной ситуации. А не на обобщенных данных.

Простейший пример: Вы входите в комнату. Оцениваете светло или нет. Если темно, то включаете свет и проходите в комнату. Если светло, то сразу проходите в комнату. И новая оценка…

Упрощенно примерно такой же подход использует и описываемое мной решение. То есть для принятия решения не проводится анализ на основании BigData с выявлением неких тенденций и закономерностей. А оценивается конкретная ситуация. И на основании конкретной оценки принимается вполне конкретное решение.

Чтобы избежать сильно большой критики могу сказать, что BigData очень даже полезны. И данные, полученные на их основе, должны использоваться в СППР. Но СППР не должна опираться на BigDta, как на фундаментальную основу. Это тема для отдельной дискуссии.

Предыстория

В основе решения лежит методика Частных алгоритмов действий врача. В данном случае добавлена абстракция и расширена сфера применения.

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

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

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

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

Реализация

Так и появилась концепция платформы СППР Универсальные алгоритмы. Которая стоит на 3-х китах:
• Методика создания и описания алгоритмической модели
• Алгоритм-Дизайнер – приложение для визуального создания и редактирования алгоритмов СППР
• Алгоритм-Навигатор – web-приложение, которое реализует использование логической модели СППР.

Всем понятно, что речь идет о графовой модели. Если честно не хотелось изобретать велосипед, но один недоброжелатель своим язвительным замечанием подтолкнул к тому чтобы нарисовать создаваемую модель. Поэтому было взятое готовое решение Graphviz, которое прекрасно справляется с такой задачей. Плюсом еще является и то, что данный пакет позволяет создавать интерактивные графы с URL.
Отрисовывать граф целого алгоритма нет смысла, иначе он не поместится на огромной стене. Поэтому был выбран путь создания графа для каждой ситуации. Если какой-то элемент ведет в другую ситуацию, то это так и отображается на графе.

Алгоритм-Дизайнер

Алгоритм-Дизайнер позволяет создавать логическую модель согласно методологии. Алгоритм по содержанию делится на ситуации. А в ситуациях реализуется модель рассуждений.
Алгоритм-Дизайнер – Windows приложение. Пока что не придумана концепция как еще можно реализовать весь функционал такого приложения в виде альтернативного решения (например web).

Основной логический элемент – Алгоритм.

Алгоритм может содержать вложенные элементы такого же типа. То есть элемент алгоритма «Скорая помощь» может содержать в себе элементы-алгоритмы для специализированных бригад скорой помощи.

Далее Алгоритм делится на Ситуации. Ситуация существует для того чтобы разделить Алгоритм на логические разделы. Это позволяет выделить отдельную логическую задачу из общего алгоритма.
Примечание: В терминах программирования можно считать, что Алгоритм – это программа, а Ситуация – подпрограмма, процедура или функция.

Естественно, что все элементы взаимосвязаны. Поэтому логические элементы Алгоритма позволяют устанавливать связи и переходы между Ситуациями.

Далее идет элемент – Вопрос. Система работает по принципу оценки «текущей ситуации». Поэтому она постоянно работает в режиме задавания вопроса и получения ответа от пользователя.
Ответ – логический элемент, связанный с вопросом. То, что пользователь будет выбирать для оценки «текущей ситуации»

Рекомендация – логический элемент, который на основании оценки предлагает, или требует выполнить некие действия. Рекомендации делятся на простые и те, что устанавливают время на исполнение. То есть для таких рекомендаций определяется временной промежуток, в течении которого должно быть выполнено действие прежде чем будет продолжено движение по алгоритму – минимальный и максимальный интервал.

Еще используется вспомогательный элемент – Закрыть линию. Это было продиктовано тем, что хотелось визуально выделить момент, когда заканчивается линия рассуждений. Этот элемент может использоваться многократно в алгоритме. В данном случае есть избыточность. Но ею лучше пренебречь ради наглядности.

Для чего понадобились «Работа с родительскими и дочерними элементами»?

Алгоритм – это граф. Но отображение древовидное. Следовательно, в дереве отображается только один родительский элемент узла. Что не отображает реальное положение вещей. Так же в дереве не видны все дочерние узлы, если они находятся в других ветках дерева. Так же нужен был механизм для установки таких связей. Поэтому был реализован функционал назначения «Родителя» для узла. Дочерние элементы – это просто информативное отображение.

Для упрощения просмотра и тестирования в дереве при двойном клике на элементе осуществляется переход на 1-й дочерний узел. В том числе и на тот, который установлен в другой ветке. Обратное движение по дереву к родителям осуществляется двойным кликом в поле отображения дочерних узлов.

Логическая модель редактируема и открыта. Но визуальное представление делает ее еще более наглядной и понятной для более широкой аудитории без специальных знаний. В качестве средства визуализации был выбран инструмент Graphviz. Потому что строит диаграммы быстро, бесплатный и кроссплатформенный. Есть еще ряд преимуществ. Одно из них – это возможность строить интерактивные диаграммы. То есть каждый элемент может содержать в себе URL.

Отображать решено было по ситуациям. Так как весь алгоритм представляет собой довольно большое полотно, в котором трудно разобраться. Элементы диаграмм содержат в себе отображение всех текстов. Это касается Рекомендаций и дополнительных справочных комментариев-пояснений для Ответов. Это позволяет полностью отразить логическое и содержательное наполнение системы.
Для реализации были использованы Delphi, СУБД Firebird, Graphviz. Привязка к СУБД продиктована использованием компонента. Для использования в web-приложении Алгоритм-Навигатор база конвертировалась в MySql, SQLite и т.д.

Алгоритм-Навигатор

Алгоритм-Навигатор разработан как web-приложение с адаптивным дизайном. Вполне нормально смотрится на экранах с различными ориентацией и разрешением. Так же интерфейс достаточно простой для использования, чтобы не требовалось специальное обучение пользователя.

Я выбирал некоторое время способ реализации Алгоритм-Навигатора. Известно было, что это должно быть web-приложение, что должна быть возможность запуска на Linux и должен быть API для встраивания в другие информационные системы. Потому что изначально планировалось не противопоставлять систему уже существующим, а наоборот дополнять.

Для разработки был выбран Python. Фреймворк bottle (планирую все перенести на django). Тут не нужно особых пояснений. Я не являюсь специалистом в дизайне и занимаюсь проектом сам. Поэтому был взят готовый набор для front-end titon.io, который обладает всем необходимым функционалом.

Я верстал страницы так как они должны были выглядеть. А потом на их основе делал шаблоны.
Поскольку хотелось иметь функционал генерации диаграмм и в Алгоритм-Навигаторе, то был использован пакет pydot.

Порядок и принцип работы

Алгоритм-Дизайнер позволяет создавать логическую модель. В принципе ее можно начинать использовать сразу после создания нескольких шагов.

По мере прохождения по алгоритму все шаги пользователя фиксируются. По ним происходит восстановление протокола. Это еще одна особенность данной методологии – при прохождении по алгоритму формируется протокол рассуждений специалиста. Который может быть использован как документ. Я планировал копирование текста в заявки системы сервис-деск.

Пример API

UID – ID пользователя алгоритма.
OID – ID объекта. В данном случае может быть любой объект. В медицине – пациент.
Parameter list – набор параметров типа name=value для макроподстановки в текстах алгоритма. Как пример имя, название компании, название продукта.
Algorithm entry point – точка входа в алгоритм. Не всегда нужно начинать с самого начала. При вызове алгоритма из другой системы можно выбрать точку в алгоритме (ситуацию) с которой будет начата работа.

Примеры применения

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

Медицина: Диспетчер скорой помощи, Алгоритмы специализированных бригад скорой помощи (я упоминал Комы, Отравления, Коллапсы), Проф. осмотр, Пульманология, Кардиология, Педиатрия, Акушерство и Геникология, Алгоритм по взысканиям для ЛПУ.
Это не полный перечень.

Я уже описал попытку создания экспертной системы для службы поддержки в филиальной сети частной медицинской компании.

Пример критериального анализа CRM при условии, что критерии являются составными.

Скрипты разговоров и продаж услуг.

Возможность создания опросника для тайного покупателя.

Побочный эффект – возможность описания регламентов с помощью диаграмм.

Использовали для описания регламента для выписки пациентов:

В своей работе так же описал процесс внедрения:

Источник