зачем администраторы настраивают оповещения об отклонениях
Проектирование системы оповещений для веб-приложений
Эта статья о том, как мы проектировали универсальную систему оповещений для наших веб-приложений и что в итоге получилось. Не стану утверждать, что полученный результат является единственно верным, однако считаю его достаточно хорошим. Если у вас есть опыт решения подобной задачи, приглашаю поделиться им в комментариях.
Суть задачи
Дано: веб-приложение для совместной работы. Для простоты будем считать, что это CRM или Task Tracker.
Требуется: своевременно уведомлять пользователей о событиях в приложении, на которые требуется их реакция.
В чем проблема?
Первый блин Первое быстрое решение
Вначале был реализован самый простой вариант оповещений – показ пользователям при входе в приложение всех изменений, выполненных другими пользователями. При небольшом количестве изменений такой способ имеет право на существование, однако при росте количества данных и числа пользователей получаем бесконечный список, который некогда, да и незачем просматривать:
Однако, как показывает практика, пользоваться журналом действий для получения оперативной информации о событиях в приложении неудобно. Как правило, такая подробная информация об изменениях требуется в редких случаях — ее использует руководитель при «разборе полетов». А в реальном времени сотруднику нужна не столько подробная, сколько выборочная информация — с акцентом на интересующие его изменения. Например, после «Завершения дела» (из примера выше) мне хотелось бы видеть такую информацию:
Сегодня в 12:48 Иванов завершил дело P4D1: Подготовка документов на подачу заявки.
Петрову назначено дело P4D2: Получение оригиналов заявки от клиента.
Вам назначено дело P4D2: Получение оригиналов заявки от клиента. Срок выполнения – 2 дня.
Получается, что оповещения должны настраиваться по-разному для разных пользователей и разных событий (спасибо, кэп). Пришло время проанализировать, в каких случаях и какие оповещения действительно нужны пользователям.
Классификация оповещений
По источнику возникновения
По тому, кого нужно оповещать
По способу оповещения
По сроку хранения
Результат
Итак, все потребности учтены при анализе. Вроде ничего не забыли. Теперь нужно придумать настройку, позволяющую сформировать любое оповещение. Над красотой интерфейса мы пока не думали, а структура настройки получилась вот такая:
Внимательный читатель заметит, что срок хранения оповещений в этой настройке не выбирается. Мы решили, что эту настройку можно задавать не для каждого отдельного оповещения, а на более высоком уровне — для всего приложения. Возможно, это временное решение, и тонкая настройка сроков хранения всё же понадобится. Опыт покажет.
Процессы, задачи, оповещения
В ходе исполнения процесса система формирует задачи пользователям, таким образом организуется их совместная работа в рамках установленного регламента. Оповещения о различных событиях, происходящих в системе, и возможность оставлять комментарии и прикреплять файлы к справочникам и документам способствует совершенствованию коммуникаций.
Простая настройка
Маршрут процесса легко настраивается с помощью визуального конструктора. Этапы процесса и связи добавляются мышкой. Система сразу указывает на ошибочно настроенные этапы, подсвечивая их красным.
Ролевая адресация
Ролевая адресация позволяет одни и те же маршруты процессов применять в разных организациях. Исполнителем этапа может быть явно указанный пользователь или роль. Ответственность по ролям указывается в разрезе по организациям.
Условные переходы
Система может выбирать путь исполнения процесса в зависимости от сведений, содержащихся в согласуемом документе. При настройке условия перехода доступны все реквизиты согласуемого объекта. С помощью произвольных источников можно обращаться к любым данным, хранящимся как в текущей, так и во внешних информационных базах.
Генерация документов
Универсальный процесс может автоматически создавать и заполнять документы. Кросс-системные и кросс-функциональные процессы можно связать в единую цепочку. Автоматизация рутинных операций достигается без изменения конфигурации.
Поэтапное заполнение
Управляя доступностью реквизитов можно организовать поэтапное заполнение документа несколькими пользователями. На каждом этапе согласования можно настроить доступность в документе только определенных полей и кнопок.
Интеграция с внешними системами
Универсальный процесс может работать с данными внешних информационных баз так же как с внутренними. Эта возможность позволяет организовать неразрывное исполнение кросс-системного бизнес-процесса, связанного с обработкой данных в разных информационных системах.
Данные внешних баз могут использоваться в условных переходах для определения пути исполнения процесса. На основании данных внешних баз можно формировать документы. Можно формировать документы во внешних базах.
Согласование по e-mail
Согласование документов можно выполнять не только внутри системы, но и ответным письмом на оповещение по электронной почте. Для удаленного согласования по электронной почте не требуется установки специальных программ.
Безопасность передаваемых данных обеспечивается средствами защиты корпоративной почты. Простой и интуитивно понятный способ отправки решения: нажимаем на гиперссылку и отправляем автоматически сформированное письмо. В ответе можно написать комментарий визирования, который также попадет в систему.
Гибкое согласование
К рассмотрению документа можно привлекать дополнительных согласующих. По усмотрению участников согласования в особых случаях можно дополнять предопределенный маршрут процесса. В организациях без формализованных процессов согласования можно полностью отказаться от предопределенных маршрутов.
Оповещения и напоминания
Правила рассылки оповещений пользователей о событиях гибко настраиваются администратором системы. При желании, они могут отображаться не только внутри программы, но и дублироваться на электронную почту.
Как спроектировать систему уведомлений. Пошаговая инструкция с примерами
Сложно представить современный сервис без комплексной системы уведомлений. Нам заботливо сообщают, что кто-то из друзей оценил фотографию, курьер с долгожданной пиццей уже в пути, а такси приехало к дому.
В системах управления работой роль уведомлений становится критически важной, поскольку глубоко встраивается в рабочий процесс команды. Как брошенный из рук в руки мячик, уведомления своевременно сообщают об изменениях в задачах, призывают к выполнению своей части работы и подсказывают важную информацию.
Ниже я поделюсь своим опытом системного подхода к проектированию уведомлений. Как обнаружить и учесть все ситуации, чтобы сделать продукт полезнее для пользователей и сохранить ресурсы вашей команды?
Шаг 1: Определяем участников процесса
Рассмотрим классическую историю из жизни маркетингового агентства:
Арт-директор Энтони очень спешит: его компания скоро выпускает на рынок новый продукт, поэтому промо-баннеры необходимо сдать к концу недели. Дизайнер Джонни уже завершил всю работу, но, чтобы ее приняли, макеты нужно обязательно утвердить с менеджерами проекта.
Поэтому Энтони ставит задачу на утверждение со сроком выполнения до пятницы и дописывает пояснение: «Пожалуйста, утвердите баннеры для кампании».
Рассмотрим подробнее, кто принимает участие в системе:
Старайтесь ограничить этот список. Чем сложнее систему ролей вы построите, тем труднее пользователям будет понять, по какой логике она работает.
Шаг 2: Строим таблицу «Событие — Уведомление»
Строим каркас
Чтобы спроектировать уведомления системно и наглядно, построим таблицу. Каркас будет состоять из двух частей:
Левая колонка. Сюда будем записывать возможные события в процессе утверждения по ролям. Именно они будут вызывать отправку уведомлений. Не все роли на практике могут влиять на систему. Например, «Исполнитель» в нашем примере является просто наблюдателем, поэтому в левую колонку его можно не добавлять. Итого, получаем три секции:
Таблицу удобнее всего вести в Google Sheets. Помимо мощной функциональности ей будет удобно делиться с вашей командой и другими отделами, которым понадобится эта информация. Например, со Службой Поддержки пользователей.
Делитесь ссылкой с правами доступа «Комментирование». Так команда получит возможность обсуждать события в комментариях к ячейкам и никто, кроме вас, не сможет изменить или стереть их.
Заполняем события
Когда каркас таблицы готов, начинаем заполнять левую колонку всеми событиями, которые может совершить пользователь в утверждении. Необходимо для каждой роли оценить каждое состояние интерфейса и выписать доступные действия. На данном этапе придерживайтесь нескольких советов:
Шаг 3: Определяем принципы получения уведомлений
События готовы, но, прежде чем добавлять уведомления, полезно определить принципы их получения по ролям. Они пригодятся для того, чтобы спроектировать только актуальные списки для каждой роли и не заваливать пользователей излишней информацией. В этом помогут результаты пользовательских интервью, исследования подобных продуктов, а также концептуальные решения, положенные в систему.
В нашей модели утверждения выделим следующие принципы:
Запишите эти принципы для каждой роли в строках получателей. Удобно указать их комментариями к ячейкам. С развитием системы принципы помогут держаться одного курса.
Шаг 4: Заполняем уведомления
Наконец, можно приступать к созданию самих уведомлений. Проходите последовательно от события из левой колонки по ячейкам каждой роли получателя. Придерживайтесь следующих правил:
По ситуации введите цветовое кодирование в ячейках и зафиксируйте его в виде легенды в шапке таблицы. Например: черный текст — черновик строки, зеленый текст — строка проверена и готова к работе, красный текст — есть проблемы реализации и подробности в комментариях ячейки.
Шаг 5: Дорабатываем события
После заполнения всех ячеек таблицу стоит доработать:
Заключение
Даже самые сложные сценарии могут стать наглядными и удобными в разработке, если подойти системно и придерживаться выбранных принципов. Грамотно спроектированная таблица уведомлений поможет дизайнеру сделать продукт полезнее и понятнее для пользователей. Команде — не тратить лишние ресурсы на понимание задумки и всех деталей, а сконцентрироваться на качестве реализации.
Несколько полезных советов для дальнейшей работы с таблицей:
Оповещение / уведомления пользователей по расписанию (всплывающее окно) [Комплексная автоматизация 2.4]
Как работает это расширение.
В подсистему «НСИ и администрирование» добавлены Справочник «Настройка оповещений» и Регистр сведений «Оповещения пользователю».
Настройка расписания
Заходим в справочник «Настройка оповещений» и создаем новое оповещение.
Настраиваем расписание, жмем галочку «Активно».
«Регламентное задание» удалится, если мы уберем галочку «Активно» и запишем нашу настройку.
Настройка самого сообщения (запрос)
Переходим к настройке самого сообщения.
По расписанию сработает наш запрос и запишет данные в Регистр «Оповещения пользователей».
Пример оповещения:
Установка в конфигурацию.
На основании нашей внешней обработки, будут создаваться регламентные задания на каждую нашу настройку в справочнике «Настройка оповещений».
Важно. В запросе можно использовать не все типы Документов.
Настройка уведомлений и назначений
Уведомления
В системе Итилиум существует возможность отправки уведомлений пользователям и сотрудникам организации в зависимости от наступления следующих событий.
Оповещения настраиваются следующим образом (у всех пользователей и сотрудников должен быть указан основной почтовый адрес или номер мобильного телефона, иначе уведомление отправлено не будет).
1. Уведомление о назначении или смене ответственного отправляется сотруднику автоматически при назначении его ответственным.
Все шаблоны писем находятся в справочнике «Шаблоны сообщений» (ссылка «Шаблоны сообщений» панели навигации раздела «Администрирование и настройки»). Если ответственной по какому-либо документу назначена рабочая группа, то уведомления приходят всем сотрудникам этой группы. Можно отправлять уведомления только руководителю группы, в этом случае должна быть установлена отметка «Уведомлять только руководителя при смене рабочей группы» в настройках параметров системы (раздел «Администрирование и настройки», ссылка панели навигации «Администрирование», в открывшейся форме — ссылка «Параметры системы/Уведомления»). Шаблона письма «Изменение рабочей группы по наряду» не существует, т.к. в наряде ответственным может быть назначен только конкретный сотрудник.
Для того чтобы отключить механизм автоматических уведомлений при назначении или смене ответственного, достаточно в шаблоне соответствующего сообщения удалить тему.
2. Для документов «Обращение», «Наряд», «Проблема», «Изменение», «Релиз», «Событие» есть отдельные справочники состояний, в которых могут находиться данные документы (см. раздел «Матрицы состояний документов» главы «Общие справочники системы»).
В форме элемента такого справочника необходимо установить отметку «Отправлять уведомление пользователю» и указать шаблон отправляемого сообщения. Шаблон сообщения необходимо предварительно создать в справочнике «Шаблоны сообщений». При переводе документа в такое состояние инициатору документа и всему списку оповещаемых лиц будет отправлено письмо по указанному шаблону.
По умолчанию для документа «Наряд» такие уведомления отправляются только списку оповещаемых лиц. Для того чтобы инициатору наряда также направлялось такое уведомление, необходимо для соответствующего пользователя информационной базы в настройках пользователя указать отметку «Оповещать об изменении состояний создаваемых нарядов» (см. главу «Возможности индивидуальных настроек системы»).
3. Для отправки сообщения всем участникам общения по обращению необходимо указать шаблон сообщения в настройках параметров системы (раздел «Администрирование и настройки», ссылка панели навигации «Администрирование», в открывшейся форме — ссылка «Параметры системы/Уведомления/Обращение»).
Шаблон сообщения необходимо предварительно создать в справочнике «Шаблоны сообщений». Уведомление будет отправлено инициатору, ответственному и всему списку оповещаемых лиц.
4. Для отправки сообщения ответственному по обращению/изменению о закрытии всех связанных с этим обращением/изменением нарядов необходимо указать шаблон сообщения в настройках параметров системы (раздел «Администрирование и настройки», ссылка панели навигации «Администрирование», в открывшейся форме — ссылка «Параметры системы/Уведомления/Обращения»).
Шаблон сообщения необходимо предварительно создать в справочнике «Шаблоны сообщений». Уведомление будет отправлено ответственному за обращение, по которому закрыты все связанные с ним наряды.
5. Оповещение по приоритету настраивается в документе «Соглашение об уровне услуг» (вкладка «Оказываемые услуги» — кнопка «Настроить оповещение на услугу»).
Список оповещаемых лиц указывается отдельно для каждого приоритета по каждой услуге (рисунок 2.20). Шаблон письма установлен по умолчанию и называется «Оповещение по приоритету».
Рисунок 2.20. Форма настройки оповещения по приоритету