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

Системы ИИ должны масштабироваться в широких пределах

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

Система должна предусматривать взаимодействие с пользователями

ИИ не должен быть «черным ящиком». Пользовательский интерфейс должен обеспечивать прозрачность критериев принятия решений и их последствий, а также информирование о проблемах, которые система сама решить не может. Пользователи должны иметь возможность контролировать принимаемые ИИ решения и при необходимости их корректировать или отменять. В то же время система ИИ должна работать самостоятельно и обращаться к пользователю только в случае возникновения исключительной ситуации, а также предоставлять пользователю возможность ввести дополнительную информацию, неизвестную ИИ [One Network Enterprises Staff 2017].

На следующем рисунке показана архитектура цепи поставок для применения ИИ.

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

8.3.3. Микросервисы

8.3.3. Микросервисы

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

Микросервисная архитектура является противоположностью единого монолитного приложения. В традиционном приложении процессы неразрывно связаны друг с другом и с другими сервисами. В результате небольшая модификация одного процесса может сказаться на всей системе. В этом проблема low-code платформ BPM. Микросервисная архитектура эту проблему решает. Если микросервис нуждается в модификации, то такая доработка должна быть простой. Такая гибкость очень важна для предприятий. При традиционной разработке приложений вносимые изменения могут повлиять на всю систему. Преимущество микросервисов (при условии правильного проектирования) состоит в том, что их можно быстро и легко менять. Короче говоря, микросервис нацелен на одну бизнес-способность. Это не значит, что он делает что-то одно, просто у него очень конкретная цель.