Блог компании sap

Привет, Хабр! Давай сегодня поговорим о том, зачем SAP придумал Kyma и что это такое.

Kyma/kee-ma/в переводе с греческого - волна.

Это проект с открытым исходным кодом, построенный на основе Kubernetes. Основное назначение Kyma упрощение создания serverless и микросервисных cloud-native приложений для расширения функциональности SAP бизнес-решений. То есть с помощью нее можно создавать необходимую компании функциональность, но которая по тем или иным причинам не доступна в стандартных SAP решениях (например, SAP Ariba, SAP Business Suite, S/4HANA и др.).

Проект Kyma первоначально был инициирован компанией SAP как open-source. В настоящее время он является участником Cloud Native Computing Foundation (CNCF). CNCF объединяет ведущих разработчиков, конечных пользователей и поставщиков различных cloud-native технологий и решений с открытым исходным кодом и является частью некоммерческой организации Linux Foundation. Например, здесь можно посмотреть ландшафт проектов CNCF.

Наверно возникает вопрос зачем требуется использовать Kyma вместо стандартного кластера Kubernetes? Несмотря на то, что Kubernetes (k8s) является платформой полного набора компонентов для управления жизненным циклом распределенных приложений, она оставляет за нами выбор решений для множества задач. Это может быть хранилище данных, резервное копирование, мониторинг шины обмена сообщениями, оркестровка сервисов и т.п. Для всех этих задач open source сообщество разработала большое количество проектов, решений и сервисов (например, Istio, Jaeger, Linkerd, и др.). Выбирая наиболее подходящий, можно гибко конфигурировать целевые системы. Но, с другой стороны, потребуется решение многих технических вопросов. Например, как установить то или иное решение/сервис, интегрировать его с другими выбранными сервисами, настроить сквозной мониторинг и др. Поэтому на реализацию оптимальной целевой архитектуры на кластере k8s может уйти много времени, экспертных знаний и дополнительных инженеров. Вот как раз для этого и можно использоваться Kyma.

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

Kyma состоит из нескольких компонентов, основные из которых:

- Application connector используется для подключения любого приложения к кластеру Kubernetes и предоставления его API и событий (events) через Kubernetes Service Catalog.

- Serverless позволяет создавать расширения для приложения через механизм функций (код Node.js). Код функции может запускаться вызовами API, а также событиями, поступающими из внешней системы.

- Service Catalog предоставляет простой доступ к сервисам, которыми управляют сервисные брокеры, и использует их в приложениях. Например, можно легко применять сервисы сторонних облачных платформ, таких как Azure, AWS или GCP.

Кроме этого в Kyma интегрированы одни из самых оптимальных и функциональных сервисов, использующихся в разработке cloud-native приложений:

- Мониторинг и оповещение основаны на PrometheusиGrafana.

- Для логирования используется Loki.

- Обработка событий происходит в NATS.

- Как средство управления и хранения данных/объектов используется Rafter и MinIO.

- Оркестровка сервисов ведется через Istio.

- Трассировка распределенных микросервисов осуществляется в Jaeger.

- Аутентификация поддерживается Dex и др.

Давайте разберемся с использованием Kyma на примере расширения SAP Service Cloud и SAP Field Service Management для работы с клиентскими отзывами.

1. Потребитель пишет комментарий на Facebook с номером своего заказа.

2. Аналитический микросервис (-сервис) делает его сентиментный анализ.

3. И если комментарий отрицательный, создает заявку в SAP Field Service Management (FSM); администратор FSM назначает ее техническому специалисту.

4. Далее при завершении работы над заявкой запускается lambda-функция.

5. Lambda-функция создает ответ клиенту на основе результатов работы над заявкой и отправляет его.

Для установки доступны две версии: полная (Kyma) и облегченная (Kyma Lite). Облегченная версия используется для локальной разработки и не устанавливает такие компоненты, как ведение журнала, мониторинг и т.д. Полный список всех компонентов, установленных для полной и облегченной версии, можно найти тут. Можно кастомизировать набор устанавливаемых компонентов через установочный yaml-файл.

Сейчас вендор также запустил SAP Cloud Platform Extension Factory, Kyma runtime. Благодаря этому теперь можно получить Kubernetes кластер в составе SAP Cloud Platform вместе с другими сервисами платформы для разработки приложений. Extension Factory, Kyma runtime работает на кластере Kubernetes который разворачивается через Gardener (еще один open source проект SAP, платформа для управления кластерами Kubernetes) в выбранном пользователем облачном провайдере и в необходимом регионе. В дальнейшем Extension Factory, Kyma runtime будет доступна в триальном режиме в SAP Cloud Platform.

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

Если вдруг вам захочется еще прочитать про Kyma, то вот дополнительные материалы:

Kyma Open Source website

SAP Help Portal

SAP Cloud Platform Discovery Center

Blog post: SAP Cloud Platform Extension Factory, Kyma runtime: How to get started

Kyma runtime onboarding mission

Автор Георгий Шутов, эксперт по платформенным решениямSAP CIS

Привет, Хабр! Сегодня поговорим о том, как нейронные сети могут помочь в распознавании деталей и зачем это вообще нужно. Недавно к нам обратился один из наших клиентов - крупная промышленная компания, производитель грузовых автомобилей и их комплектующих. Детали насчитывали большое количество возможных наименований. Из-за этого при визуальном распознавании сотрудники совершали ошибки. Решили создать приложение на основе компьютерного зрения и нейронных сетей. С его помощью стали проверять правильный ли выбор сделал рабочий (рис 1). Так же дополнительно было необходимо сверять наименование распознанной детали с наименованием, указанным в накладной на заказ.

Данные

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

Выбор модели

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

Использовать только ограничивающие рамки (Bounding Box) было бы недостаточно (Object detection). Они могли сильно перекрывать друг друга при разметки, обучении и распознавании, поэтому для обучения решили выбрать одну из моделей, с поддержкой метода сегментации изображения (Image segmentation) . (Рис. 2)

Поскольку из-за специфики задачи важнее было определять класс объекта, а не его местоположение, была выбрана модель Mask R-CNN. Эта простая и гибкая модель позволяла эффективно обнаруживать объекты на изображении, одновременно генерируя высококачественную маску сегментации для каждого экземпляра. Метод Mask R-CNN расширил Faster R-CNN, добавив ветвь для предсказания маски объекта. Эта ветвь существовала параллельно с ветвью для распознавания ограничивающего прямоугольника. Faster R-CNN позволял детально разметить контур объекта, что решало проблему наложения рамок друг на друга при разметке деталей на фотографиях. Однако такая разметка занимала значительно больше времени.

В нашем случае разметка объектов на изображении выполнялась вручную на стороннем облачном сервисе. Он предоставлял возможность нескольким сотрудникам размечать один и тот же набор данных удаленно и после завершения разметки скачивать весь набор данных. (Рис. 3, 4, 5, 6)

После разметки достаточного количества фотографий для экспериментов проводилось обучение первых моделей для распознавания деталей на сервере HPE DL380 c двумя видеокартами NVIDIA Tesla v100. В среднем, на обучение первых моделей было затрачено от 8 до 12 часов.

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

1. На фотографиях некоторых деталей были обнаружены лики, (объекты, не являющиеся частью деталей, но на которые модель обращает внимание при определении класса). Это способствовало неверному обучению сети.

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

Что делать с ликами?

Чтобы решить эту проблему составили подробную инструкцию по сьемке фотографий для машинного обучения. Это позволило сократить количество ошибок и уменьшить число ликов при следующем обучении.

На фотографиях ниже (рис. 7 и 8) приведен пример ликов. На первой серии фотографий изображены детали первого класса при ярком освещении. На второй - детали второго класса при более темном освещении. На таком наборе данных при определении класса модель будет обращать внимание на фон и освещение. Это будет происходить, так как части изображения у первого и второго классов различны. Стоит заметить, что такая работа модели является некорректной: необходимо стремиться, чтобы при классификации модель опиралась на структуру деталей.

Что делать с зеркальными деталями?

Чтобы решить проблему с распознаванием зеркальных деталей, мы решили использовать ансамбль моделей. Первая модель классифицировала детали на зеркальные и незеркальные, причем каждая симметричная деталь распознавалась как два объекта. Далее зеркальные детали отправлялись в следующие модели, которые были обучены для распознавания только зеркальных деталей. То есть под каждую пару зеркальных деталей была создана своя модель, которая классифицировала деталь как левую или правую (рис. 9).

Как создать модель для разметки

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

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

После этого модели для распознавания были обучены и подобраны параметры. (Рис. 10, 11).

Распознавание бирок и накладных

Чтобы решить задачу с сопоставлением детали, выбранной рабочим, с деталью из накладной, было необходимо распознавать информацию о наименовании. Это возможно сделать с помощью штрихкода, который содержал информацию о номере детали. Таким образом, не было необходимости исследовать весь текст в накладной.

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

Для удобного развёртывания моделей весь backend был перенесен на SAP Data Intelligence.

Интерфейс и SAP Data intelligence

SAP Data Intelligence позволяет не только публиковать и встраивать модели, но и создавать на их базе новые собственные операторы (например, от python оператора). Это помогает переиспользовать существующие модели и встраивать их в необходимых форматах (батч-обработка, стриминг, или публикация REST-сервисов). Кроме этого, основанный на flow-based подходе пайплайн может быть быстро адаптирован под меняющиеся условия. Например, если в будущем потребуется интеграция с ERP / MES или любой другой системой, это будет сделать довольно просто. Также все получаемые фотографии можно собирать в используемое Озеро Данных для дообучения модели и улучшения качества распознавания. Если потребуется масштабировать данный сервис, это будет сделать легко. Достаточно настроить уровень параллелизма (параметр multiplicity) и под модель будет поднято соответствующее количество реплик на уровне kubernetes. Есть встроенные инструменты для отладки пайплайна, логирования, трассировки, мониторинга.

Кстати, нужно пару слов сказать о том, на какой платформе собирался данный проект. Так как система в будущем должна пойти в промышленную эксплуатацию, желательно использовать оборудование промышленного класса надежности. Компания Cisco предоставила для пилота гиперконвергентную систему Cisco Hyperflex, про которую ранее на Хабре уже писали здесь, здесь и здесь .

Так как SAP Data Intelligence полностью построен на контейнерах, важно, чтобы были решены задачи отказоустойчивости кластера Kubernetes и его интеграция с сетями центра обработки данных, в котором будет развернуто решение. Фактически, мы полностью повторили в лаборатории типовой валидированный дизайн Cisco&SAP, описанный здесь и голова за инфраструктуру у нас больше не болела.

В SAP Data Intelligence был создан контейнер со всеми необходимыми библиотеками. Для публикации сервиса использовался стандартный оператор OpenAPI. Весь backend работал в контейнере на сервере. Пайплайн можно было так же запускать на любом другом сервере Data Intelligence (рис. 12).

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

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

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

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

Сегодня популярность проектов data science очень высока и бизнес понимает их важность и значимость. Рынок наполнен специалистами в этой области, которые умеют добиваться впечатляющих результатов. Но такие проекты нередко бывают дорогостоящими, и не всегда для простых задач нужно привлекать профессионалов в этой области. Создание некоторых прогнозов вполне по силам самим бизнес-пользователям. Например, специалисты из отдела маркетинга могут прогнозировать отклик на маркетинговые кампании. Это становится возможным при наличии инструмента, позволяющего за несколько минут построить прогноз и легко интерпретировать результаты с точки зрения бизнес-смысла.

SAP Analytics Cloud (SAC) облачный инструмент, совмещающий в себе функции BI, планирования и прогнозирования, он также оснащен множеством функций расширенной аналитики: интеллектуальными подсказками, автоматизированным анализом данных и возможностями автоматического прогнозирования.

В этой статье мы расскажем о том, как построено прогнозирование в SAP Analytics Cloud, какие сценарии доступны на сегодняшний день, а также как этот процесс может быть интегрирован с планированием.

Функциональность Smart Predict ориентирована на бизнес-пользователя и позволяет строить прогнозы высокой точности без привлечения специалистов Data Science. Со стороны пользователя системы прогноз происходит в черном ящике, но в реальности это, конечно же, не так. Алгоритмы прогнозирования в SAC идентичны алгоритмам модуляAutomated Analytics инструмента SAP Predictive Analytics. Об алгоритмах, лежащих в основе этого продукта, есть множество материалов, мы предлагаем прочитать эту статью. На вопрос: Получается, Automated Analytics переехал в SAP Analytics Cloud? - мы отвечаем - Да, но пока только частично. Вот какая разница и сходство в функциональных возможностях инструментов (рис.1)

SAP Analytic Cloud в настоящее время предлагает 3 прогнозных сценария:

Классификация. В данном случае предполагается бинарная классификация: предсказываются значения целевой переменной, которая может иметь только два значения -да и нет или 0 и 1. Примерами сценария классификации могут быть:

Прогноз оттока клиентов, где целевая переменная предсказывает, уйдет клиент или нет.

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

Выявление мошенничества с целевой переменной, указывающей, была ли транзакция или требование мошенническим, или нет.

Регрессия. Предсказывает числовое значение целевой переменной в зависимости от переменных, описывающих ее. Примеры регрессионных сценариев:

Количество клиентов, посещающих магазин в обеденное время.

Выручка от каждого клиента в следующем квартале.

Цена продажи подержанных автомобилей.

Прогнозирование временного ряда. Предсказывает значение переменной с течением времени с учетом дополнительных описательных переменных. Примеры сценария прогнозирования временных рядов:

Выручка по каждой продуктовой линейке в течение следующих нескольких кварталов.

Количество велосипедов, арендованных в городе в течение следующих нескольких дней.

Командировочные расходы в ближайшие несколько месяцев.

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

Процесс прогнозирования в SAP Analytics Cloud осуществляется в несколько простых этапов. Мы рассмотрим его на примере прогнозирования оттока клиентов интернет-магазина. Для начала нам необходимо загрузить в систему тренировочный датасет из системы-источника или excel файла. Также SAP Analytics Cloud позволяет прогнозировать в режиме Live (избегая загрузки данных в облако) на таблицах SAP HANA. В этом случае для пользователя SAC процесс остается неизменным, но построение прогноза происходит на стороне SAP HANA с использованием библиотеки Automated Predictive Library (APL).

Наш тренировочный датасет имеет следующие поля:

Следующим шагом построение прогноза будет выбор сценария прогнозирования.

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

После этого мы создаем прогнозную модель и выбираем заранее подготовленный датасет, как источник данных для обучения. У пользователя также есть возможность редактировать метаданные. Далее мы выбираем целевую переменную, ее мы будем прогнозировать. В нашем случае это переменная Contract Activity, идентифицирующая отток клиентов. Также мы можем исключить некоторые переменные, если понимаем, что они никак не повлияют на формирование прогноза. Например, в нашем случае точно можно исключить Customer ID. Это может ускорить процесс выполнения прогноза, но их сохранение не мешает процессу моделирования.

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

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

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

Прогностическая сила (KI) указывает на долю информации в целевой переменной, которую могут описать другие переменные модели (объясняющие переменные). Гипотетическая модель с прогностической силой 1,0 является идеальной, поскольку позволяет объяснить 100% информации целевой переменной, а модель с прогностической силой 0 является чисто случайной.

Достоверность прогноза (KR) показывает способность модели достичь той же производительности, когда она применяется к новому набору данных, имеющему те же характеристики, что и обучающий набор данных. Приемлемой считается достоверность прогноза не менее 95%.

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

Кроме этого, на рисунке ниже мы видим кривую производительности AUC ROC. Ось X показывает, какой процент от общей выборки составляют положительные цели; ось Y представляет их верно идентифицированный процент, который обнаружил алгоритм. Здесь необходимо пояснить, что положительными целями в данном случае считается целевая группа, а именно клиенты, отказавшиеся от услуг интернет-магазина.

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

Красная кривая показывает минимальный процент обнаруженной цели, полученный случайной моделью. То есть случайно взяв 10% населения, вы бы определили 10% клиентов.

Синяя кривая показывает процент обнаруженной цели с использованием нашей модели. Например, если 10% выборки составляют ушедшие клиенты, мы обнаруживаем примерно 75%. Чем ближе синяя линия подходит к зеленой, тем лучше модель. Чем больше расстояние между красной и синей линиями, тем больше лифт модели.

Кроме того, SAC предоставляет возможность увидеть, как именно ключевые факторы влияют на целевую переменную.

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

Мы видим, что клиенты, проводившие на страницах интернет-магазина от 10 до 22 и от 1 до 3 минут, имеют наибольшую склонность отказаться от услуг. Напротив, покупатели, находящиеся на портале от 3 до 7 и от 7 до 10 минут, показывают наименьшую вероятность уйти. Результаты выглядят волне логично: уходят те, кто проводили на сайте или слишком мало, или слишком много времени. Подобный анализ можно провести по всем ключевым предикторам.

Также для оценки качества получившейся модели SAC предлагает проанализировать матрицы неточностей, различные графики, иллюстрирующие эффективность модели (лифт, чувствительность, кривая Лоренца и плотность) и смоделировать возможные выигрыши и проигрыши от использования данного прогноза.

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

На выходе мы получаем датасет с прогнозными значениями целевой переменной, на основе которого может быть легко сформирована модель данных. Она, в свою очередь, может являться источником данных для построения аналитической отчетности в SAC. Например, для этого кейса мы использовали интеллектуальную функцию Smart Discovery и получили автоматических дашборд на спрогнозированных данных.

Таким образом, прогнозирование легко вписывается в процесс анализа данных в SAC. С недавних пор функционал прогнозирования в решении также может быть легко интегрирован в процесс планирования.

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

Кроме того, в процессе создания отчетов пользователи также могут использовать прогностические функции, например, автоматический прогноз. Он позволяет продлить график временного ряда.

Алгоритм выполнения такого прогноза описан здесь, линейная регрессия или тройное экспоненциальное сглаживание. Результаты прогноза видны ниже, рядом с графиком факта появляется пунктирная линия прогноза и доверительный интервал.

Также прогноз можно добавлять в таблицы и использовать оттуда данные, например, как базу для будущего плана.

Таким образом, процесс прогнозирования в SAP Analytics Cloud достаточно прост и максимально ориентирован на бизнес-пользователя, но дает возможность получения прогностических моделей высокого качества для решения типовых бизнес-задач.

Данный инструмент является stand-alone решением и может стать частью мультивендорной архитектуры. Интеграция SAP Analytics Cloud с решениями SAP нативна. Кроме того, существует стандартный бизнес контент для различных индустрий и линий бизнеса. Отчеты могут быть дополнены прогнозными и плановыми данными, а также обогащены функциями расширенной аналитики.

Автор Анастасия Николаичева, архитектор бизнес-решений SAP CIS