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

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

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

Согласно Переосмысление стратегии управления талантами ИИ по мере того, как автоматическое машинное обучение достигает зрелости 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 г. | Статья

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

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

Регрессионная модель и эффект управления

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

Такой ход событий говорит о том, что мы можем иметь две ситуации:

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

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

В построении модели могут участвовать как эндогенные (внутренние) так и экзогенные (внешние) переменные. 

Внутренние переменные свидетельствуют о инерции процесса. "Мощность" инерции можно оценить как степень объясненной дисперсии наблюдаемой величины за счет соответствующей эндогенной переменной.

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

Данные рассуждения работают, если 

1. Удалось определить представительный набор факторов.
2. Удалось получить достаточный для построения модели набор данных: исторических или полученных в результате планирования эксперимента.
3. Удалось классифицировать факторы с точки зрения эндогенности и экзогенности.

Если строится одно регрессионное уравнение, то эндогенность можно оценить с помощью авторегрессионных уравнений.

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

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

В связи с этим возникает подход к оценки - хорош ли прогноз.

Зачастую к прогнозу предъявляются претензии - прогноз не оправдался.

Но всегда ли прогноз должен оправдываться на радость автора прогноза?

Навряд ли.

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

* * *

Что такое модель?
Демистифицирующее моделирование: как количественные модели могут - и не могут - объяснить мир. 25 июня 2020 г. | Статья

Ключевая особенность модели - упрощение реальности.

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

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

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

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

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

Подводные камни, которых следует избегать при использовании моделей

Модель - это просто инструмент. Ценность модели зависит от способа ее использования.

Модели основывается на трех основных компонента:

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

Каждый из этих факторов основан на предположениях, которые стоит принимать во внимание и не считать модель "истиной".

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

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

Таблица модальностей для переговоров

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

Например, https://www.psychologos.ru/articles/view/tablica-slov-predikatov приведена такая таблица

Пояснения к типам можно почерпнуть тут https://trenings.ru/entsiklopediya-nlp/modeli/871-model-nlp-metaprogramma-predpochitaemaya-modalnost.html

Проблемы, неразрешимые алгоритмически

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

Алгоритмически неразрешимые проблемы, указанные Чёрчем и Тьюрингом, слишком сложны.

В работе "В.А.Успенский. Апология математики" приведен простой пример такой проблемы.

Рассмотрим следующую игру. Игровыми принадлежностями будут служить модифицированные костяшки домино. Каждая костяшка доминоразделена пополам чертой. В каждой половине записывается цепочка из букв x и z.

Примеры цепочек.

• Цепочка длины ноль.
• Цепочки длины один: x, z. 
• Цепочки длины два: xx, xz, zx, zz. 
• Цепочки длины три: xxx, xxz, xzx, xzz, zxx, zxz, zzx, zzz.
• Цепочка произвольной длины.

Возможный вид пластинок (рисунок взять из книжки В.А.Успенский. Апология математики).

Обозначим изображенные костяшки буквами A, B, C, D.

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

Каждую костяшку разрешается воспроизводить в неограниченном количестве и создавать сочетания из повторяющихся пластинок, такие, например, как AACA. В этом примере верхней строчкой будет xxxzx, а нижней – zxzxzzzx.

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

Если объявленный набор состоит из одной костяшки A, то решение невозможно, так как нижняя длина всегда окажется длинне верхней. Также решения не существует для двух костяшек A и D. Но если объявить набор из четырёх пластинок A, B, C и D, то решение существует: DBCDA, – верхняя и нижняя строка одинаковы: zzzxxzzzzx.


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

Оказывается, что не существует эффективного способа узнать - существует ли решение. Не существует такого алгоритма (он не просто неизвестен – его нет), который позволял бы для любого объявленного набора пластинок узнать, имеется ли решение. Узнать, к какой из двух категорий относится каждый отдельно взятый набор пластинок – к той, для которой решения имеются, или же к той, для которой решений нет, – это сугубо творческая задача, своя для каждого набора, а общий метод нахождения ответа для всех таких задач отсутствует.

В.А.Успенский. Апология математики.

Зрелость в обработке данных

Много данных накоплено в организациях. Но как их использовать? Как "плохие" данные сделать "хорошими"?

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

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

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

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

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

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

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

В статье

 How to be great at people analytics by Elizabeth Ledet, Keith McNulty, Daniel Morales, and Marissa Shandell September 2020

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

"Хорошие данные", но труднодоступные для лиц принимающих решений. Ступенька 2.

Способности, которые требуются от организации.

• Транзакционные системы.
• Централизованные данные в репозиториях.
• Базовые правила сбора данных.

Организационное мышление.

• Данные как базис для аналитики.
• Успешный анализ данных требует консистентных и структурированных данных.

"Надежные данные", которые доступны лицам принимающим решение. Ступенька 3.

Способности, которые требуются от организации.

• Технологии распространения данных и аналитики в организациях (например, инструменты отчетности, платформы).
• Аналитика для внутренних клиентов.

Организационное мышление.

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

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

Способности, которые требуются от организации.

• Cпециалисты по работе с расширенной аналитикой (например, специалисты по обработке данных, статистики).
• Расширенные статистические инструменты (например, R, Python, SPSS) для анализа.

Организационное мышление.

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

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

Способности, которые требуются от организации.

• «Очень большие данные» - большой объем и высокая надежность
• Глубокий опыт в прогнозной аналитике (например, машинное обучение с учителем или без учителя)

Организационное мышление.

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

Основные строительные блоки анализа данных

Описание основных строительных блоков взято из курса на сайте open.sap.com - Unit 6: Creating an SAP Analytics Cloud Story

Последовательность шагов выполнения анализа и презентации результатов следующая:

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

ERP и цепочка поставок

Цепочка поставок. Неплохо раскрыта суть тут - Что такое ERP в управлении цепями поставок?. От от Panorama Consulting Group | 23 марта 2020 г.

Что такое ERP в управлении цепями поставок?

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

Распространение COVID-19 позволило по новому взглянуть на работу цепочек поставок.

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

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

В контексте поставок это означает:

• Определение источников поставок основных ингредиентов
• Транспортировка ингредиентов в производственные цеха
• Упаковка конечного продукта
• Складирование (хранение) готовой продукции
• Доставка готовой продукции: либо розничному продавцу, либо напрямую потребителю

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

Что такое ERP в управлении цепями поставок?

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

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

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

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

Роль ERP в управлении цепями поставок

1. Спрос и планирование

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

2. Закупка товаров и услуг

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

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

• Производство продукции
• Складские операции
• Транспортная логистика
• Обслуживание

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

3. Производство и доставка

Эффективное производство зависит от точного понимания  необходимых материальных и трудовых ресурсов. ERP обеспечивает такое понимание. Пользователи могут создавать полный перечень материалов (BOM) для каждого этапа производства. Затем, когда начнется производство, ERP будет автоматически регистрировать использование материальных и трудовых ресурсов в режиме реального времени.

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

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

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

4. Отгрузка товара

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

ERP позволяет эффективно управлять графиком отгрузки. ПО может автоматически генерировать счет-фактуру, как только начинается отправка. Большинство платформ назначать определенные методы упаковки и выполнять проверки качества упаковки.

Преимущества интеграции ERP и SCM

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

1. Меньше производственных узких мест

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

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

2. Более точное прогнозирование спроса

Точное прогнозирование спроса необходимо для поддержания надлежащего уровня запасов.

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

3. Межведомственная видимость бизнес-процессов

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

Какие параметры интеграции SCM и ERP доступны?

Два варианта:

• Полностью интегрированное ERP-решение со встроенной функциональностью SCM
• Стороннее приложение SCM, которое имеет механизмы интеграции с ERP

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

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

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

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

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

Активаторы рассеянного режима:

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

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

• поиграть в видеоигры;
• побродить по Интернету;
• поговорить с друзьями;
• помочь близким в каком-нибудь несложном деле;
• почитать расслабляющую книгу;
• обменяться SMS-сообщениями с друзьями;
• сходить в кино или в театр;
• посмотреть телевизор (не засчитывается, если пульт выпал из рук при засыпании).

Вообще, проблема должна "созреть".
Очень интересно процесс созревания описан у С.Лема в статье "Моя жизнь".

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

Метаистория - пример понятия без объекта

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

Впрочем, для полноты картины кратко о понятии метаистории

Метаисто́рия - термин, впервые введённый в употребление С. Н. Булгаковым и получивший распространение как в русской эзотерике, так и в русской христианской философии.

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

В учении Даниила Андреева теория метаистории развивает идеи С. Н. Булгакова о Метаистории как «ноуменальной стороне того универсального процесса, который одной из своих сторон открывается для нас как история». Под метаисторией Д. Андреев понимает совокупность процессов иноматериальной природы, которая отчасти находит свое проявление в истории и имеет по отношению к ней в конечном счете определяющее значение.

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

Самое здравое определение метаистории ввел Хейден Уайт - американский историк и литературный критик. Он назвал метаисторией структуру исторического изложения и своей монографии показал. что историки просто следуют схемам, которые можно изложить посредством дисциплины с названием "Метаистория".

В 1973 году Хейден Уайт опубликовал книгу Metahistory: The Historical Imagination in Nineteenth-Century Europe (Метаистория: Историческое воображение в Европе XIX в.).

В этой работе Уайт, используя методологический аппарат тропологии, рассмотрел особенности исторического повествования крупнейших историков XIX века и пришёл к выводу об использовании ими литературных приёмов для достижения целостности повествования путём заполнения недостающей информации и её интерпретации. Уайт обратил внимание на то, что законченное историческое исследование содержит не только набор исторических фактов, но и литературную форму; последняя, по Уайту, оказывает значительное влияние на конечный текст, на что ранее практически не обращалось внимания. Под влиянием структурализма Уайт также построил схему использования историками четырёх различных тропов — метафоры, метонимии, синекдохи и иронии — с соответствующими им идеологиями, типами сюжетов (emplotment), формами аргументации и эмоциональными императивами. Благодаря «Метаистории» Уайт считается одним из творцов «лингвистического поворота» в исторической науке.