Появление искуственного интеллекта...

Является ли необходимым условием возникновения Искусственного Интеллекта (в его сильной форме) его деятельностный характер?

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

Обобщая, попробуем понять, как постичь филофские категории. Не обязательно - в их полном объеме. Кант выделял, например, такие категории

• Категории количества
• Единство
• Множество
• Цельность
• Категории качества
• Реальность
• Отрицание
• Ограничение
• Отношения
• Присущность и самостоятельное существование (substantia et accidens)
• Причинность и зависимость (причина и действие)
• Общение (взаимодействие между действующим и подвергающимся действию)
• Категории модальности
• Возможность и невозможность
• Существование и несуществование
• Необходимость и случайность

Оцените список и попробуйте представить, как постичь и верифицировать некоторые категории без разрушения?

* * *

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

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

В настоящее время уже выделяют различные по интеллектуальной мощи Искины, в частности, искусственный общий интеллект (AGI) и искусственный суперинтеллект (ASI).

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

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

В 1999 годе футуролог Рэй Курцвейл предсказал , что Сверхразумная машина может появиться только около 2045-2050 гг.

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

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

Показатели эффективности поставок

Для характеристики эффективности системы поставок можно использовать следующие показатели.

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

• Эффективность поставки, вычисляемое как соответствие описанному выше критерию. Может использоваться бальная система с весами.
• Количество заказов
• Качество выполненных заказов. Например, максимальное качество оценивается единицей, минимальное - ноль. Тогда сумма "качеств" деленная на количество заказов позволяет оценить общее качество системы поставок. Также, в случае декомпозиции системы на подсистемы, появляется возможность оценка качества подсистем.

Способность реагировать на запросы клиентов. Скорость работы цепочки поставок от заказа до доставки конечному потребителю.

• Время реализации заказа.

Гибкость. Возможность системы поставок изменяться и адаптироваться в соответствии с изменениями на рынке и в цепочке.

• Время реагирования на запросы изменения.
• Время переконфигурирования элементов цепочки, включая время переналадки или перестройки "производящих" подразделений.

Затраты.

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

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

• Время цикла: деньги-производство-деньги.
• Показатели оборачиваемости активов.

ERP и оптимизация бизнес-процессов

Изолированные ИТ решения, которые не могут взаимодействовать друг с другом, создают узкие места, избыточность решений и данных, а также другие проявления неэффективности протекания бизнес-процессов. Объединение разрозненных ИТ решений в единую систему планирования ресурсов (ERP) может упростить бизнес-процессы и повысить их эффективность (How do ERP Systems Streamline Business Processes?).

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

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

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

Как ERP-системы оптимизируют бизнес-процессы?

1. Автоматизация ручных задач

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

Ряд задач, которые можно автоматизировать с помощью ERP:

• Создание заказов на продажу.
• Распределение запасов для заказов клиента.
• Пополнение запасов.
• Отправка счетов-фактур или уведомлений клиентам по электронной почте.
• Координация рабочих процессов.
• Отслеживание и инкассация дебиторской задолженности.
• Отправка уведомлений для увеличения оборачиваемости дебиторской задолженности и, соответственно, формирования денежного потока.

2. Улучшение прогнозирования спроса и управление запасами

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

3. Стандартизация

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

4. Улучшение коммуникации

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

Вот некоторые взаимозависимые команды:

• Учет.
• Складирование и управление запасами.
• Управление контактами.
• Учет входящих заказов.
• Обработка заказов.

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

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

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

Советы по оптимизации ЕRP

На основе Using ERP Optimization to Get More Out of Your Current System

Что такое оптимизация ERP?

Под оптимизацией ERP мы понимаем процесс анализа персонала, процессов и технологий в целях определения узких мест, препятствующих раскрытию потенциала ERP-системы. Помимо выявления проблем, оптимизация ERP определяет необходимые корректирующие действия и эффекты этих действий.

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

4 совета для успешной оптимизации ERP

1. Анализируйте причины, порождающие проблемы бизнеса

• Есть ли проблемы с текущей настройкой ERP? 
• Выражают ли пользователи разочарование по поводу удобства использования, функциональности или доступности системы?

Вместо того, чтобы пытаться решать все проблемы сразу, разделите проблемы на категории. В большинстве случаев бизнес-проблемы, связанные с ERP можно свести к пяти категориям:

• Неправильный сбор требований ERP.
• Недостаток внимания к управлению бизнес-процессами.
• Отсутствие управления организационными изменениями.
• Низкая исполнительная дисциплина.
• Плохое управление проектами.

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

2. Будьте в курсе обновлений ПО

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

Обновления также могут помочь:

• Понизить общую стоимость владения (TCO).
• Повысить производительность пользователей.
• Соблюдать и адаптироваться к изменению государственных норм и отчетности.
• Быть в курсе технологических достижений.

3. Документируйте изменение бизнес-требований

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

4. Модифицируйте ERP для удовлетворения новых бизнес-требований

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

Преимущества оптимизации ERP

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

Рабочий процесс разработки модели

Рабочий процесс разработки модели как для приложений машинного обучения, так и для предиктивной аналитики состоит из этапов:

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

Согласно Переосмысление стратегии управления талантами ИИ по мере того, как автоматическое машинное обучение достигает зрелости 14 августа 2020 г. | Статья многие организации обнаружили, что от 60 до 80 процентов времени специалиста по данным тратится на подготовку данных для моделирования. После того, как начальная модель построена, только часть его или ее времени - 4 процента, согласно некоторым исследованиям - тратится на тестирование и настройку кода. По сути, настройка параметров модели стала предметом потребления, а производительность зависит от выбора и подготовки данных.

Структурные элементы разработки ИИ

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

McKensey разместила очень примечательный insight на эту тему - McKensey. Executive’s guide to developing AI at scale.

https://www.mckinsey.com/business-functions/mckinsey-analytics/our-insights/executives-guide-to-developing-ai-at-scale#intro

Ниже приводится пересказ/перевод данного материала. При этом вся графика - по ссылке. Ниже только тексты.

Технологические комплексы

Среда разработки ИА включает в себя следующие технологические комплексы:

• Лабораторная среда разработки ИА.
• Продуктивная система.
• MLOps - подход к разработке ИА в части систем машинного обучения (ML - Machine Learning).

Лабораторная среда

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

Продуктивная система

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

MLOps

MLOps относится к DevOps в применении к машинному обучению и искусственному интеллекту. Главным объектом управления MLOps является жиненный цикл решений, направленный на повышении стабильности модели за счет автоматизации повторяемых шагов в рабочих процессах разработки и развертывания программного обеспечения.

Подробнее об этом компоненте можно почитать тут - https://habr.com/ru/company/vtb/blog/508012/

=================================

Рассмотрим подробнее данные компоненты 

=================================

Описание лабораборной среды

Лабораторная среда может быть описана следующиеми подсистемами и процессами:

• Сбор данных.
• Разработка моделей.
• Ролевая модель.

Сбор данных

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

Для организации сбора данных нужно определиться со следующим:

• Исходные, внутренние или внешние системы, с извлекаемыми данными.
• Интерфейсы прикладного программирования (API) для извлечения данных как посредники, обеспечивающие взаимодействие приложений. Примеры - REST API, gPRC, GraphQL.
• Пакетные задания, позволящие или пополнять данные по мере появления новых данных, или порционно обрабатывающие большие объемы данных. 
• Конвейерная обработка данных как последовательность ("оркестровка") шагов обработки данных в автоматизированном режиме.
• "Озеро" данных как централизованное хранилище корпоративных данных в неструктированных форматах. Озера данных позволяют объединять данные из разных источников, чтобы затем создавать на основе этих данных аналитические наборы данных. Озера данных имеют практически неограниченную емкость хранения, что позволяет хранить генерируемые данные, даже если они сразу не применимы в аналитике.
• Каталоги данных как структуры хранения метаданных о том, какие элементы данных существуют, как они связаны, каковы типы и характеристики данных.

Разработка моделей

Разработка моделей состоит из следующих процессов:

• Построение моделей. В процессе построения модели инженеры данных выбирают алгоритмы и методы, которые соответствуют решаемой задаче. Например, это могут быть методы регрессионного анализа, классификационные алгоритмы, методы построения нейронных сетей. Тут же продумываются пользовательские интерфейсы.
• Обучение моделей. Как правило, модели обучаются с использованием программных фреймворков и библиотек. Для прогнозирования требуется обученная модель машинного обучения.
• Тестирование модели. Оценка производительности обученной модели. Обучающие данные обычно делятся в соотношении 60:20:20: обучение 60%, тестирование - 20%, валидация - 20%. Тестирование помогает понять, насколько точно модель будет работать в реальном мире.
• Развертывание модели (deploy) для производственного использования. Стабильные, повторяемые механизмы развертывания позволяют предприятиям гибко и непрерывно обновлять модели после обучения моделей на новых наборах данных.

Технологические компоненты среды разработки моделей состоят в следующем:

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

Роли в рамках лабораторной среды

• Собственник продукта (представитель заказчика)
• Специалист по данным (Data scientist)
• Инженер данных
• Бизнес-консультант
• Дизайнер пользовательских интерфейсов и взаимодействия пользователя с продуктом
• Delivery manager - Менеджер отвечающий за доставку продукта клиенту

Обязанности собственника продукта.

• Представляет интересы клиента.
• Контактирует с любыми внешними заинтересованными сторонами.
• Анализирует и определяет приоритеты для краткосрочных и среднесрочных целей.
• Привлекает дополнительные ресурсы (например, разработчиков, тестировщиков)по мере необходимости.

Обязанности специалиста по данным (Data scientist)

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

Обязанности инженера данных

• Определяет доступные источники данных и определяет основные исходные системы для загрузки и обработки.
• Разрабатывает "конвейеры" перемещения данных для упрощения и автоматизации работы с данными.
• Определяет архитектуру данных (хранилища данных, слои данных).
• Сотрудничает с специалистами по обработке данных.

Обязанности бизнес-консультанта (Translator)

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

Обязанности дизайнера пользовательских интерфейсов и взаимодействия пользователя с продуктом

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

Обязанности Delivery manager - Менеджера отвечающий за доставку продукта клиенту.

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

Продуктивная система

Продуктивная система может быть описана следующими подсистемами:

Интеграция аналитических выводов в практику

Интеграция аналитических выводов в практику

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

Подсистема базируется на следующих технологиях:

• Использование контейнеров в программировании как технологии "упаковки" структур, кода и зависимостей атрибутов структур данных.
• Kubernetes - система поддерживание развертывание, масштабирование и управление контейнерами.
• Микросервисная архитектура, реализующая исполнение кода как независимой службы, выполняемой в рамках контейнера.
• Интерфейс прикладного программирования (API) как программный посредник во взаимодействии приложений. 
• Пользовательские интерфейсы, позволяющие пользователям "потреблять" результаты работы аналитических приложений.

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

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

Роли в рамках продуктивной системы

• Владелец продукта
• Инженер по машинному обучению
• Инженер MLOps
• Архитекторы облака или инфраструктуры
• Руководитель отдела управления облаком
• Программисты
• Специалисты по обеспечению качества и автоматизации тестирования
• Специалисты в предметной области

Обязанности владельца проекта:

• Служит первой точкой контакта с внешними заинтересованными сторонами.
• Определяет критерии успеха решения.
• Анализирует и определяет приоритетность краткосрочных и среднесрочных целей.
• Участвует в основных командных мероприятиях, таких как обзоры и ретроспективы.
• Управляет бюджетом и ресурсами.

Обязанности инженера по машинному обучению

• Оптимизирует модели машинного обучения для повышения производительности и масштабируемости.
• Внедряет модели машинного обучения в производственную среду.
• Автоматизирует конвейеры машинного обучения.

Обязанности инженера MLOps

• Автоматизирует базовую технологическую инфраструктуру.
• Разрабатывает конвейеры непрерывной интеграции (CI) и непрерывного развертывания (CD).

Обязанности архитекторов облака или инфраструктуры

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

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

• Стимулирует принятие решения с участием широкой группы заинтересованных сторон.
• Разрабатывает коммуникационную стратегию и планы усыновления.
• Руководит обучением и управленческими процессами.

MLOps

Характеризуется набором способов работы

Hardening

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

Непрерывная интеграция Continuous integaration

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

Непрерывная поставка Continuous delivery

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

Отслеживание проблем и ошибок

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

Логирование

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

Мониторинг

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


McKensey. Executive’s guide to developing AI at scale

https://www.mckinsey.com/business-functions/mckinsey-analytics/our-insights/executives-guide-to-developing-ai-at-scale#intro

Преимущества машинного обучения в составе ERP

Машинное обучение в ERP - это реальность. Эти новые решения меняют ERP в лучшую сторону. (5 Benefits of Machine Learning in ERP).

Модели машинного обучения и развертывания ERP

Болевые точки традиционных систем ERP, которые можно устранить с помощью машинного обучения:

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

Перечисленное может ограничить конкурентное преимущество организации. Машинное обучение может помочь устранить многие из этих проблем.

Преимущества машинного обучения в составе ERP

Рассмотрим некоторые из ключевых преимуществ интеграции машинного обучения и ERP. Как и в любой реализации ERP, коммерческие выгоды зависят от согласованности действий сотрудников, процессов и технологий, которые вы внедряете.

1. Более быстрый анализ первопричин проблем с ERP.

Если у вас возникли проблемы с обслуживанием устаревшей ERP-системы, специалисту по обслуживанию может потребоваться несколько дней, чтобы найти причину проблемы. В отличие от этого, машинное обучение обеспечивает поддержку и более тщательный анализ причин затруднений, причем вы можете узнать о будущих проблемах даже до их появления. Вы можете использовать упреждающий подход к обслуживанию. Благодаря полученным сведениям вы сможете гораздо раньше предпринять действия и не допустить превращения мелких проблем в более серьезные. Улушаются сроки обслуживания, сроки текущего и капитального ремонта. С помощью машинного обучения вы можете проще определить проблемы на уровне компонентов и даже на уровне деталей и поддерживать все элементы в рабочем состоянии. Что в свою очередь обеспечит увеличение доходов.

2. Персонализированный взгляд на данные.

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

3. Улучшенная прогнозная аналитика.

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

4. Улучшение производительности.

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

5. Повышение качества продукции.

Машинное обучение может определить, какие процессы и рабочие процессы следует улучшить качество. Затем вы можете сравнить свои выводы с отраслевыми стандартами качества, например, со стандартами производительности Six Sigma.

Безопасность общественного облака

Garther выпустил статью касательно безопасности общественных облаков: Безопасно ли облако?.

Ниже пересказ данной статьи.

Введение

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

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

Чрезмерные опасения могут привести к упущенной возможности и неуместным расходам.

ИТ-директора должны изменить свою линию вопросов с «Безопасно ли облако?» на «Безопасно ли я использую облако?»

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

Разработайте корпоративную облачную стратегию

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

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

• Лучший анализ требований
• Более сложное архитектурное планирование
• Более гибкие процессы принятия рисков

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

Применяйте методы управления рисками для поддержки облачных решений

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

Модель обработки рисков может обеспечить прозрачное представление об уровнях риска облака, помогая ИТ-руководителям принимать соответствующие решения в отношении использования облака. Модель риска для общедоступного облака должна быть основана на пяти областях:

• Гибкость: способность CSP (политика защиты контента) поддерживать непредвиденные потребности в будущем.
• Доступность: сервисы реагирования на сбои в обслуживании и потери данных
• Безопасность: конфиденциальность и контроль данных
• Поставщик: изменения в бизнес-модели или жизнеспособности поставщика облачных услуг
• Соответствие: нормативные, юридические требования.

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

Прогнозы

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

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

К 2025 году 99% отказов облачной безопасности будут происходить по вине клиентов. ИТ-директора могут бороться с этим путем внедрения и обеспечения соблюдения политик владения облаком, ответственности и принятия рисков.

* * *

Облачные технологии тем не менее увеличивают ценность бизнеса. В частности, об этом говорится в статье Разблокирующая ценность: четыре урока по поиску и использованию облачных ресурсов 2 ноября 2020 г. | Статья

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

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