неверно что системы поддержки принятия решений используются в
Интеллектуальные системы поддержки принятия решений — краткий обзор
Дисклеймер
Целью написания этой статьи было сделать краткий обзор принципов построения Интеллектуальных Систем Поддержки Принятия Решений (ИСППР), роли машинного обучения, теории игр, классического моделирования и примеров их использования в СППР. Целью статьи не является забуриться вглубь тяжелой теории автоматов, самообучаемых машин, равно как и инструментов 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, при этом разные модули должны использоваться под разные задачи и иметь разные интерфейсы вывода для разных пользователей. Этакий коктейль, смешанный, но ни в коем случае не взболтанный.
О системах поддержки принятия управленческих решений
Я вот не поленился и обзвонил несколько руководителей компаний, моих клиентов. На предмет — знают ли они что такое «система поддержки принятия решений». Не знают. Однако, все ей пользуются.
Надо прояснить этот вопрос. И, заодно, будем считать эту статью четвертой частью цикла статей о тестировании ERP-систем.
Ошибаются те, кто считает, что принятие решений — это прерогатива важных дяденек в высоких кабинетах. На самом деле в бизнесе ежедневно принимается большое количество решений на разных уровнях.
Когда я написал первую часть, меня некоторые читатели обвинили в том, что я пишу о каких-то слишком простых вещах, а не о высоких материях. И что де ERP системы как раз для высоких материй и создаются. Вот в этой части и потолкуем о высоких материях. Я просто не мог говорить о сложных отчетах, анализе, не сказав о простых инструментах для автоматизации бизнес-процессов, без которых никакой анализ невозможен.
Так что же такое «система поддержки принятия решений»? На самом деле, все просто. Вот вы едите на автомобиле. Ежесекундно вы принимаете решения: то газку добавить, то притормозить, то заправиться, то еще что-то. Как вы их принимаете? Ну конечно, глядя на панель приборов. Никто за вас не будет принимать решения, но вам нужна адекватная информация о состоянии дел, чтобы сделать правильный вывод.
Решения принимаются на разных уровнях. Где-то достаточно просто иметь перед глазами правильные данные и вы примете безошибочное решение, как в случае в автомобилем. Однако, если вы представите себя за штурвалом авиалайнера, то ситуация уже меняется. Здесь тоже есть приборы и они работают, но для принятия решения необходима специальная подготовка. Здесь уже просто прозрачной картины не достаточно.
Бывают случаи еще сложней, где от прозрачности картины (показаний приборов) нет никакого толка, потому что данных слишком много и такое количество данных человек просто не переварит и не примет правильного решения. Поэтому, за неимением системы поддержки принятия решений, эти решения принимаются интуитивно. Ну, а человеку, как известно, свойственно ошибаться.
Все эти вопросы интересуют разных людей, от рядового менеджера до руководителя компании. Ответы на эти вопросы нужны нам для… принятия решений.
Ответы на такие вопросы — это простая панель приборов. Зная ответы на такие несложные вопросы вы быстро примете правильное решение.
Ответы на эти вопросы дает система. Ответы на эти вопросы должны быть на уровне математической точности, чтобы исключить человеческий фактор. Такой системой, на мой взгляд, является Теория Ограничений Голдратта. Как она работает в области управления закупками я рассказывал (и показывал) тут, в области производства тут.
Таким образом, система поддержки принятия решений — это инструмент, позволяющий быстро получить информацию, необходимую для принятия нужного решения.
Но, в каком виде нужна эта информация? И вот тут главная сложность. Можно и иголку в стоге сена найти. Только какими усилиями…
Информация должна быть сжатой, простой и не требующей каких-то усилий для ее восприятия. Например, в закупках и производстве — это просто список отсортированный в порядке убывания приоритета. Принцип простой — занимайся тем, что сверху.
Например, во многих ERP-системах, для того, чтобы просто посмотреть остатки конкретного товара на
складах, резервы и прочую очень простую информацию, нужно делать целый отчет. Это же элементарная информация, несколько цифр, но чтобы их получить нужно совершить множество действий.
Информация должна быть дозирована. Отчет, который больше, чем на одной странице — подозрителен. Сначала нужно видеть главное, затем, если есть необходимость уже детализировать информацию, а не вываливать все и сразу. Иначе, на поиск нужной информации вы будете тратить огромное количество времени.
Вот как, например, может выглядеть отчет о финансовом состоянии предприятия. Тут на одном экране все ясно. Сколько у нас есть денег, сколько нам должны, сколько должны мы и т.д.
В результате, вы понимаете, растет вообще ваша компания или нет. Как меняются во времени основные показатели и т.д. И вы можете принимать решения по их изменению.
Вот, не нравится вам размер дебиторской задолженности. Тогда вы ее детализируете в нужном разрезе (например, по клиентам) и работаете с ним. Рассылаете клиентам письма, звоните и т.д. И ваши действия должны менять ситуацию в лучшую сторону. Если меняют, значит вы приняли правильное решение.
Отчет, который показан ниже, говорит о том, откуда вообще в вашей компании берется прибыль. За счет чего вы зарабатываете, куда и сколько вы тратите и как меняется ситуация во времени. 
Если компания имеет разветвленную филиальную структуру, то разумеется такой отчет нужно получать не только по всему предприятию, но и по каждому филиалу отдельно. «Средняя температура по больнице» оно, конечно, неплохо, но желательно и по каждому пациенту. А если выяснится, что один из филиалов не приносит прибыли? Вот для этого и нужно.
Если бизнес проектно ориентированный, то конечно такой отчет система должна давать и по проектам, чтобы понимать, какой убыточный, а какой прибыльный, чтобы понять причины убыточности и что-то скорректировать.
Есть еще один отчет, который говорит о финансовых потоках, но я тут не буду перегружать пост картинками, думаю и так понятно. Он называется отчет о движении денежных средств. По большому счету, он показывает на сколько в компанию денег приходит больше, чем уходит из нее. Особенно серьезных выводов о состоянии дел по нему делать нельзя, но очень многие на него «покупаются» и считают, что раз деньги есть, значит дела идут неплохо. А в реальности, о состоянии дел могут говорить только те два отчета, которые я показал. Если в бизнесе есть деньги, это еще не значит, что их можно забрать себе в карман, потому что не факт, что компания эти деньги заработала. Иллюзия того, что все хорошо, может возникать от того, что клиенты делают предоплаты, банки дают кредиты. А потом возникают кризисы…
Так что к оценке состояния компании нужно подходить умеючи.
Если в компании десятки тысяч наименований продукции, то необходимо постоянно заниматься оптимизацией ассортимента, оптимизацией складских запасов. Система должна помочь ответить на вопрос — где лидеры и где аутсайдеры среди номенклатуры. Вы должны всегда знать, какие товары вам не приносят ничего, кроме головной боли. Наличие товара у вас в ассортименте это ведь и затраты на него. Товар нужно привезти, его нужно хранить, обеспечивать документооборотом и т.д. А если он вообще не приносит прибыли? Более того, очень интересно обнаружить у себя в ассортименте товар, который не приносит прибыли, но зато приносит много оборотов. Это одни из самых опасных товаров. По которым необходимо работать в первую очередь. Выяснять причины низкой прибыльности и устранять их. Или отказываться от такого товара. Разумеется, сделать это вручную, без ERP-системы, просто нереально.
Неправильное, бессистемное проведение закупок способно нанести серьезный ущерб бизнесу. На складе можно заморозить огромное количество денег, а потом еще получить проблемы с продажей того, что никому не нужно. Как говаривал старина Матроскин «чтобы продать что-нибудь ненужное, нужно сначала купить что-нибудь ненужное». И вот продать-то как раз проблема. Я затрагивал эту тему в статье В поисках оборотных средств, повторяться не хочется.
Или вот, например оптимизация клиентской базы. Вот у вас 500 клиентов. Один приносит 0.1% оборота, но при этом 3% прибыли, а другой 3% оборота, но при этом 0.1% прибыли да еще и 10% по дебиторке. Первый — ваш самый лучший клиент, а второй паразит, неплохо устроившийся на вашей шее. Все это нужно знать и с этим работать. Первому самого внимательного менеджера, второму самого опытного, способного проводить сложные переговоры, с тем, чтобы эту ситуацию как-то менять.
Еще ситуация. Вот картинка, показывающая остатки по складам и другую интересную информацию по товару. Интересная информация агрегирована. Если кому-то интересно, он нажмет кнопку и детализирует интересующую его информацию. Например, под кого конкретно вот эти три штуки в резерве или когда конкретно приедут вот эти 7 штук по инвойсу. 
Иными словами такая система должна иметь характер айсберга или конуса. Вы получаете сжатую информацию, которую при желании можете детализировать и получать более расширенно.
Иногда даже в простой ситуации система перегружает пользователя совершенно непонятными данными. Я лично наблюдал следующую ситуацию: вот есть счет, нужно посмотреть когда и на какую сумму он оплачен и по какому платежному поручению. Так вот, мне показали специальную форму, которую вызывали несколькими кнопками. И вот в этой самой форме данных было столько, что даже у меня голова кругом пошла. Бесконечное количество дат, сумм, галочек и прочих «крыжиков». Даже демонстрирующий затруднился сразу ответить на мой простой вопрос о том, зачем все это многообразие кнопок и галочек.
Система поддержки принятия решений должна строиться по принципу нормального конуса, а не обратного конуса, который перевернут. И для того, чтобы выудить нужную информацию, нужно бесконечно изучать «простыню» на 20 листах, вооружившись калькулятором.