Protraktor

Типы профсистем по задачам

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

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

Например, на уровне общих задач взаимодействия медицинский УЗИ аппарат не так уж сильно отличается от морского радара (и, что интересно, даже по техническому принципу работы), а редактор мнемосхем SCADA — от редактора ментальных карт («майндмэпов»).

Что за задачи?

Но что я имею в виду под задачами? Я уже делал статью про метасценарии взаимодействия — там мы рассматривали обобщенные сценарии, с которыми сталкивается большинство пользователей независимо от предметной области. Например, сценарий «что вообще происходит?» или «как мне настроить систему под себя?».

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

Примерами таких задач являются:

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

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

Мониторинговые системы

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

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

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

Разумеется, чтобы получать сведения о состоянии объекта, нам необходимы какие-то средства. Обычно это различные датчики, которые снимают сведения об объекте, переводят их в численные параметры, и которые затем обрабатываются и интерпретируются системой и её операторами. Если говорить о нематериальных объектах, в роли датчиков служат другие, внешние системы, предоставляющие соответствующие протоколы и API обмена информацией — например, системы, обеспечивающие инфраструктуру фондовых бирж.

Управляющие системы

Управляющие системы предназначены для буквального управления объектом автоматизации в реальном времени. Тут есть языковая проблема — в англоязычном мире есть два вида управляющих систем — control systems и management systems. И вот именно control systems относятся к этому типу, тогда как management это больше про мониторинговые и информационные системы.

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

Подобные системы позволяют явным образом менять параметры объекта управления, поэтому они обычно не ограничены только цифровыми интерфейсами, а активно используют аппаратные органы управления — клавиши, джойстики, рули, штурвалы и т.п., поскольку цифровые элементы управления могут быть достаточно ограниченными по скорости и точности управляющих воздействий для решаемых задач. Поэтому же об интерфейсах подобных систем чаще говорят как об HMI (Human-machine interface), а не UI (User interface).

Информационные системы

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

В принципе, и все прочие описанные в статье системы являются информационными, ибо компьютер только и может, что работать с информацией, но я бы предложил называть информационными системами те, у которых задачи обработки информации превалируют, а интеграция с внешним физическим миром минимальна. Таким образом, Jira, 1С-Бухгалтерия, Google Analytics, системы работы с закупками или базами знаний — «чистые» информационные системы.

Задачи инфосистем включают:

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

Справочные системы

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

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

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

Системы поддержки принятия решений

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

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

Подобные системы остаются достаточно специализированными, но рекомендательные модули торговых платформ (которые говорят «покупать» или «продавать» активы), системы предупреждения столкновений самолётов (TCAS), борьбы за живучесть (damage control) или выдачи рекомендации маршрутов расхождений судов — всё это примеры decision-support систем.

Инструментальные системы

Этот класс систем стоит особняком от других и хорошо знаком всем нам, даже когда мы не используем этот термин. Чтобы было понятно, сразу начну с примеров — это Figma, Microsoft Word и Excel, Scrivener, Cinema 3D, CAD-системы, музыкальные секвенсоры, Visual Studio, Adobe Lightroom и множество других.

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

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

С позиций интерфейсов важно решать проблемы доступа к инструментам, организации работы с самим объектом (в разных ракурсах — например, чертежи и итоговая 3D-модель для CAD-систем, либо дизайн/прототип для программ UX-дизайнеров), а также автоматизации и ускорения различных рутинных и не очень операций. Ну и поиск баланса между новичками и экспертами. Типичная проблема — разные пользователи применяют свои подходы, и поэтому продукт для широкой аудитории сложно не раздуть до ситуации, когда, условно, каждый из 20 пользователей использует нужные ему 5% возможностей.

Утилиты

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

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

Вместо итогов: комбинированные системы

В начале статьи я уже отмечал, что ситуация, когда конкретная система объединяет несколько типов — совершенно нормальна. Всё определяется задачами и целесообразностью — никто не ставит себе цель «сделать мониторинговую систему», важен рыночный запрос и область применимости (scope). Например, какая-нибудь АСУ ТП для железных дорог будет сочетать мониторинг и управление, а навигационная система судна будет объединять черты и справочной, и мониторинговой, и управляющей, и decision-support, и инструментальной системы.

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