Руководство пользователя по процессам

Как с помощью руководства пользователя повысить качество информационной системы

В действительности все совершенно иначе, чем на самом деле.
Антуан де Сент-Экзюпери

Многое в разработке руководства пользователя регламентировано и описано ГОСТами. Но при создании больших гетерогенных систем могут возникать вопросы, не до конца освещенные этими документами.

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

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

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

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

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

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

2. Параллельная разработка.
Из-за масштаба системы над ней работают изолированные команды аналитиков, разработчиков и тестировщиков.

3. Частые изменения.
Опять же следствие масштаба — постоянный поток изменений и доработок.

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

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

Низкое качество руководства пользователя может привести к ряду негативных последствий для всего проекта. Выделю основные:

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

Нужно было срочно исправлять ситуацию. Причем сделать это с минимальными затратами.

Поиск решения

Для каждой проблемы был разработан собственный подход. Рассмотрим каждую проблему и каждый подход более подробно.

Неактуальность документа

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

1. Составить описание модели «AS IS» (т.е. что у нас есть сейчас, какие функции и бизнес-процессы описаны).
2. Описать модель «TO BE» (в качестве консультантов привлекались ведущие аналитики по каждой подсистеме).
3. Сравнить «AS IS» и «TO BE» с помощью индикатора «Светофор» и составить план действий.

Для удобства данные заносились в таблицу (см. Рисунок 1), в строках которой указывались автоматизируемые процессы и функции, а в столбцах – существующие описания из руководства пользователя. Последние дополнительно группировались в блоки для каждой подсистемы. В итоге получилась наглядная картина соответствия процессов/функций и их описаний. Кроме того, удалось выделить похожие описания для дальнейшей группировки.

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

Далее наглядным индикатором «Светофор» были отмечены результаты сравнения:

1. Зеленый цвет – процесс есть в руководстве и нужен в бизнесе.
2. Красный – процесс есть, но не нужен (удалить!).
3. Желтый – процесс отсутствует, но нужен (добавить!).
4. Серый – процесс отсутствует и не нужен.

Использование цветовых индикаторов позволило выявить общую картину: руководство пользователя нужно править… и существенно.

Рисунок 1

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

Общее количество описаний функций в руководстве пользователя – более сотни, типовых – 25.
Дальнейшая обработка описаний потребовала дополнительной градации: ярко-зелёный  —  для сценариев, в которых всё хорошо и правки не требуются; светло-зеленый – для сценариев, которые в целом описаны правильно и нуждаются только в исправлении некоторых моментов; оранжевый – для тех, которые принципиально неправильно описаны и которые необходимо править в первую очередь.

Рисунок 2

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

Таблица соответствия в ходе работы над документом:

Рисунок 3

По завершении «покрасочных» работ обозначились приоритеты:

1. убрать оранжевый цвет – все должно быть описано корректно;
2. cделать светло-зеленые поля ярко-зелеными.

На этом моменте важно вспомнить про закон Парето (принцип 20/80): мы относительно быстро исправили наиболее проблемные оранжевые области и долго работали над светло-зелеными. Ведь в них, собственно, вся суть, если мы стремимся к тому, чтобы пользователь действительно мог работать с руководством.

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

При решении этой проблемы ставилась задача обеспечить единообразие при описании сходных процессов (кейсов) и существенно сократить трудозатраты на обновление и поддержание документа. Был выбран подход, в соответствии с которым описание каждого процесса представляется в виде строительного блока (1), а сам документ – их комбинации (3). Все строительные блоки должны располагаться в репозитории (Wiki) с обязательным контролем изменений и поддержкой версионности (2).

Рисунок 4

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

Принципиально важный момент: доступ к репозиторию должен быть обеспечен всем командам, работающим над проектом, согласно сформированному регламенту его использования.
Используя такой подход для актуализации и метод «строительных блоков» для сборки, документ удалось за короткий срок привести в надлежащее состояние. Трудозатраты сократились более чем на 30%, по сравнению с традиционным методом формирования документа. Казалось бы, на этом месте можно было бы обозначить happy end, но мне бы хотелось продолжить. Будет интересно.

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

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

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

Рисунок 5

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

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

Рисунок 6

Выводы

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

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

Использование описанных подходов при формировании руководства пользователя позволяет:

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

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

---

P.S. В статью не вошли вопросы содержательности элементов и разделов руководства пользователя. Подробно это рассмотрено и регламентировано подразделом 3.4 документа РД 50-34.698-9 и стандартом IEEE 1063-2001.

Структура и содержание документов Руководство оператора, Руководство программиста, Руководство системного программиста регламентированы ГОСТ 19.505-79, ГОСТ 19.504-79 и ГОСТ 19.503-79 соответственно.

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

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

Рис. 1. Главная страница системы ELMA

Вход в систему

Для того, чтобы можно было войти в систему, RunaWFE – сервер (симулятор) должен быть запущен. Симулятор можно запустить, например, иконкой на рабочем столе или командой меню «…RunaWFE / Start Simulation». При запуске симулятора появится консольное окно:

Строки «…JBoss AS 7.1.1.Final «Brontes» started in …» «…INFO [org.jboss.as.server] … Deployed «runawfe.ear» означают, что симулятор запущен.

После этого с системой можно работать через web-интерфейс. Это можно сделать как через клиент-оповещатель о поступивших заданиях, так и через обычный браузер. Проще всего запустить web-интерфейс системы при помощи команды «…RunaWFE / Simulation Web Interface» или через ярлык, расположенный на рабочем столе.

Описание графического интерфейса

После того, как система запущена, графический интерфейс системы доступен в окне клиента-оповещателя о поступивших заданиях или просто в web-браузере по адресу: http://<servername>:8080/wfe. Здесь <servername>- адрес сервера, на котором установлена система. В данном руководстве работа с системой будет показана в варианте использования web-браузера.

Замечание. В случае использования протокола SSL для работы с графическим интерфейсом надо использовать URL: https://<servername>:8443/wfe

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

Логин администратора системы по умолчанию – «Administrator» (существенно, что с большой буквы), пароль администратора – «wf».

В левой верхней части появившейся после входа в систему страницы находится меню системы. Меню состоит из следующих элементов:

• Список заданий
• Запустить процесс
• Запущенные процессы
• Исполнители
• Отношения
• Бот-станции
• Система
• Логи сервера

Дадим краткое описание пунктов меню системы RunaWFE. В последующих разделах эти пункты меню будут описаны более подробно.

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

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

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

Меню «Исполнители». На странице, соответствующей пункту меню «Исполнители», находится список потенциальных исполнителей заданий (пользователей и групп пользователей), доступных для чтения данному пользователю. На этой странице можно завести или удалить исполнителя, завести или удалить группу исполнителей, включить (исключить) исполнителя или группу исполнителей в другую группу. Также для исполнителя можно установить статус (Активен / Не активен) настроить список замещений.

Меню «Отношения». Данный пункт меню ведет на страницу, предназначенную для управления отношениями. Тут можно просматривать, удалять или создавать новые отношения, а также редактировать множество составляющих его пар.

Меню «Бот станции». Боты в системе RunaWFE – это специальные компьютерные приложения, которые также как и люди могут быть исполнителями заданий. Бот-станция – это компьютерная среда, в которой функционируют боты. Находящиеся в бот-станции боты периодически опрашивают RunaWFE — сервер. Если выполняющиеся на сервере экземпляры бизнес-процессов содержат задачи для исполнителей — ботов, то боты выполняют эти задачи и возвращают результаты работы на RunaWFE — сервер. На странице, соответствующей пункту меню «Бот станции», находится список зарегистрированных бот-станций. Здесь пользователь может посмотреть свойства бот-станций состояния бот-станций, свойства входящих в бот-станцию ботов, а также задач, которые они могут выполнять. Также в меню «Бот станции» можно завести новую бот-станцию, изменить параметры бот-станции, запустить/остановить периодическую активацию бот-станции, а также изменять свойства входящих в бот-станцию ботов. В частности можно добавить новое задание боту, или изменить/удалить уже существующее задание.

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

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

Пункт меню «Список заданий»

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

На рисунке изображен список заданий, содержащий одно задание пользователю attila.

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

При клике на имя задания открывается связанная с ним форма.

Сортировка, группировка и фильтрация заданий

При клике на красном треугольничке в верхней части формы или налписи «Вид» рядом с ним открывается подформа настройки сортировки, группировки и фильтрации (закрыть подформу можно, повторно кликнув на треугольничке или надписи «Вид»):

В этом примере пять заданий. Сгруппируем их по Имени «рассмотреть заявку». Для этого поставим галочку в столбце Группировка напротив Имени и введем в поле, находящееся справа от кнопки «Сохранить как» имя нового профиля: «рассмотреть заявку». Кликнем на кнопку «Сохранить как». После сохранения нового профиля, его имя появляется в поле выбора, находящемся рядом с красным треугольничком. При выборе соответствующего имени профиля в поле выбора, представление текущих задач изменяется в соответствии с настройками выбранного профиля. Теперь раскроем весь список задач, кликнув на кнопки- «плюсы». Замечание. Когда в столбце Группировка ставится галочка, то в столбце Позиция отображения в соответствующей строке ставится «нет». Обратите внимание, что если Позиция отображения стоит в значении «нет» для полей имя и описание задачи, то пропадает возможность перейти из списка задач к форме задачи.

Пример настройки группировки:

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

Добавление вывода переменной с ФИО сотрудника, запустившего процесс

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

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

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

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

Замечание. Для добавления переменной с ФИО в определение процесса, на этапе разработки необходимо использовать обработчик GetExecutorInfoHandler. Более подробную информацию по данному обработчику смотрите в разделе Обработчик GetExecutorInfoHandler

Пункт меню «Запустить процесс»

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

В поле «Описание» видим начало описания процесса, кликнув на которое получим его полный вариант:

Сортировка, группировка и фильтрация определений бизнес-процессов

При клике на красном треугольничке в верхней части формы или надписи «Вид» рядом с ним открывается подформа настройки сортировки, группировки и фильтрации (закрыть подформу можно, повторно кликнув на треугольничке или надписи «Вид»).

Настройка подформы аналогична настройке подформы для заданий

Как запустить бизнес-процесс

При клике на имени бизнес-процесса (или на иконке бизнес-процесса) вызывается стартовая форма, если она содержится в определении бизнес-процесса. Если же у бизнес-процесса нет стартовой формы, то сразу создается и запускается на выполнение новый экземпляр процесса.

Пример уже заполненной стартовой формы:

При клике на командную кнопку «запустить» стартовой формы создается и запускается на выполнение экземпляр бизнес-процесса.

Свойства бизнес-процесса

Ссылка “Свойства” ведет на страницу свойств соответствующего бизнес-процесса.

Здесь отображается «Имя процесса», его версия, дата загрузки, и описание.

Кликнув в строке «Версия» на ссылку «Экспортировать», можно записать этот бизнес-процесс в виде файла *.par Можно также использовать уже готовый файл *.par для изменения определения процесса. Для этого нужно выбрать этот файл с помощью кнопки «Обзор» после чего нажать на кнопку «Изменить определение процесса».

Так же на данной странице отображается граф процесса.

Кликнув на ссылку в правом верхнем углу «Обладатели полномочий», увидим список обладателей полномочий этого процесса:

Пункт меню «Запущенные процессы»

На странице, соответствующей пункту меню «Запущенные процессы» находится список экземпляров бизнес-процессов, доступных для чтения данному пользователю:

Нажатие на название экземпляра бизнес-процесса открывает его свойства:

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

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

Нажав на «История» в правом верхнем углу, получим историю выполнения процесса:

Кроме того на странице свойств доступны «граф истории», «диаграмма Ганта», «история в задачах»

Сортировка, группировка и фильтрация экземпляров бизнес-процессов

Нажатие на «Вид» открывает профиль настроек сортировки, группировки и фильтрации.

Данная подформа имеет несколько иной вид в сравнении с подформой заданий. Экземпляры процессов группируются по полям: “Номер”, “Имя”, “Запущен”, “Завершен”, “Версия”. Имеется возможность группировки по переменным, но главное отличие – это группировка запущенных процессов по подпроцессам.

Рассмотрим приведенный выше пример. Тут имеются несколько экземпляров процессов имеющих подпроцессы:

• MainProcess->SubProcess (id 3, 4)
• Proc1->Proc2->Proc3->Proc4->Proc5 (id 6, 7, 8, 9, 10)
• MultiInstanceProcess-> MultiInstanceSubProcess, MultiInstanceSubProcess, MultiInstanceSubProcess (id 12, 13, 14, 15)

Выполним группировку по подпроцессам.

Для этого поставим галочку возле надписи “группировать по подпроцессам” и введем в поле, находящееся справа от кнопки «Сохранить как» имя нового профиля, например «sub». Кликнем на кнопку «Сохранить как». После сохранения нового профиля, его имя появляется в поле выбора, находящемся рядом с красным треугольником. Как уже указывалось ранее, при выборе профиля в поле выбора, отображение изменится в соответствии с настройками выбранного профиля.

Рассмотрим полученный результат:

Появилась новая колонка, напротив родительских процессов с id 3,6,12 отображаются «плюсы», это и есть группировка по подпроцессам. По нажатию на данный значок, группа раскроется и под экземпляром верхнего уровня будет отображено дерево его подпроцессов, при этом учитываются права на чтение:

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

Строки подпроцессов отличаются цветом от строк процессов верхнего уровня.

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

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

Пункт меню «Исполнители»

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

Нажатие на имени исполнителя открывает его страницу свойств.

В случае пользователя на этой странице находятся:

• Свойства исполнителя, где отражена информация о пользователе
• Статус, где проставляется признак активности пользователя
• Поле для ввода пароля
• Группы исполнителя, в которые входит пользователь
• Отношения, в которые входит пользователь
• Заместители. Тут находится список правил замещения

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

Замечания.

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

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

Сортировка, группировка и фильтрация исполнителей

Настройка аналогична настройке Вида для заданий.

Пункт меню «Отношения»

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

Ссылка “Создать отношение” – выполняет переход на страницу создания нового отношения. Здесь необходимо ввести его “Имя” и “Описание”

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

Более подробное руководство по реализации концепции отношений в RunaWFE представлено в руководстве по работе с отношениями Там же представлены и примеры использования отношений для инициализации ролей.

Пункт меню «Система»

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

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

Работа с заданиями

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

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

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

Здесь точка управления перешла в состояние «make a decision». Соответствующий узел на графе выделен жирной рамкой. В момент перехода в это состояние исполнитель, в данном случае «staffrole», получает задание в списке заданий. При клике на задание будет отображена соответствующая ему форма. После реального выполнения задания сотрудник должен заполнить поля формы, предназначенные для ввода данных, кликнуть на командной кнопке «Задание исполнено»:

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

Если задание соответствует группе пользователей, то это задание появится в списках заданий всех членов данной группы. Однако выполнить задание сможет только один пользователь – тот, который сделает это первым.

# Назначение заместителей

В системе существует возможность, если исполнитель текущего задания не является “Активным” (например – болеет, или находится в командировке) перенаправлять задания другим исполнителям. Для этого используется механизм правил замещения.

Подробнее о замещении.

В системе RunaWFE существует механизм подтверждения действий. На рисунке ниже пользователь на странице «Запустить процесс» выделил галочкой строку для процесса TimerDemo, а потом воспользовался кнопкой «Удалить».

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

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

Приятного чтения.

Если перед вами стоит вопрос – нужно ли вашему продукту пользовательское руководство, то отвечу сразу – да, нужно. Почему? На это есть две причины:

1. Качественная документация повышает лояльность клиента и ценность продукта в целом.

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

2. Руководство пользователя экономит время и силы техподдержки.

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

А теперь к советам!

Общие советы по созданию руководства пользователя

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

— Где скорее всего пользователи будут прибегать к документации? (дома, на работе, в машине)

— Насколько объективно сложен для понимания продукт и как часто пользователь будет обращаться к документации?

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

(Для изложения лучше всего выбрать нейтрально-формальный стиль)

Структура руководства пользователя

У любого качественной документации продуманная и логичная структура. Представьте, что вы сами работаете в программе и сталкиваетесь с проблемой. Открываете файл справки – а там просто сплошной текст. Такая документация вам не поможет.

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

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

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

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

В любом руководстве желательны разделы «Частые вопросы» и «Устранение типовых проблем». Расскажите о проблемах, с которыми часто сталкиваются клиенты и о путях их решения.

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

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

Профессиональный совет: если вы хотите максимально облегчить ношу клиента при чтении документации создайте контекстно-зависимую справку. Что это такое?

Представьте, что вы работаете в программе для создания пользовательской документации. Открываете меню основных настроек и видите раздел «аннотирование экрана» Заходите в него, там показаны разные стили аннотации, тени, фон и так далее. Но что такое аннотация? Допустим вы не знаете — нажимаете кнопку F1 и перед вами открывается руководство именно на той странице, где рассказано об «аннотировании экрана»

Как ее сделать? Смотрите ниже.

Контент

И так, мы создали «каркас» нашей документации, но чтобы руководство стало полезным нужно наполнить её компетентной информацией.

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

1. Понятность.

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

2. Наглядность.

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

3. Видео.

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

Но как добавить в документацию видео? Смотрите ниже.

Больше советов!

Когда документация будет готова, чтобы она стала «полноценной» её нужно опубликовать. Иначе какой от неё толк, если клиент не может её прочитать. У «юзера» всегда должен быть доступ к документации, и не важно где он. Такую потребность легко закрывают три формата: HTML, PDF и CHM.

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

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

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

Но помните, что после публикации документации, придется иногда её обновлять.

Инструменты

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

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

Dr.Explain – программа для создания руководств пользователя для ПО, web-сервисов и баз знаний.

Благодаря «доктору» вы сможете опубликовать и обновлять документацию в востребованных форматах (CHM; HTML; PDF; DOC), не выходя из программы.

В программе есть шаблоны документации, ведь по образцу работать проще.

Импортируйте в программу заранее написанные фрагменты документации.

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

Какой можно сделать вывод

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

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

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

Спасибо за внимание!

Со всеми возможностями Dr.Explain можно ознакомиться здесь:

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

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

Давайте рассмотрим предназначение документации по процессам, способы её создания (с примерами) и преимущества её внедрения для вашей команды.

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

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

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

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

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

Документация по процессу и составление карты процесса

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

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

Как создать документацию по процессу

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

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

1. Проанализируйте исходный процесс

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

В процессе анализа следует выделить:

• Основные задачи: определите, каких ключевых показателей эффективности вы хотите достичь или какие бизнес-задачи выполнить.

• Заинтересованные лица: возможно, вы пока ещё не знаете их всех, но подумайте, какие команды будут работать вместе.

• Хронология: оцените объём процесса и хронологию его выполнения по методу критического пути.

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

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

2. Определите границы процесса

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

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

Автоматизировать работу с помощью Asana

3. Определите точки входа и выхода

Третий этап подразумевает определение точек входа и выхода.

• Точки входа — это ресурсы, необходимые для выполнения процесса.

• Точки выхода — это то, чего вы хотите достичь по завершении процесса.

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

Определение точек входа и выхода в будущем позволит вам разбить каждую из этих целей на небольшие этапы.

4. Определите этапы процесса

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

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

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

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

5. Свяжитесь с заинтересованными лицами проекта

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

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

6. Создайте блок-схему процесса

Теперь к самому интересному — визуализации процесса. Одним из самых простых способов является блок-схема. В зависимости от типа процесса, который вы документируете, блок-схема обеспечивает чёткость благодаря своей наглядности. Вам также может пригодиться инструмент управления рабочими процессами, который позволяет отслеживать ход выполнения целей и задач.

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

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

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

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

7. Отметьте исключения для хода процесса

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

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

8. Протестируйте процесс

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

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

• Решила ли документация по процессу проблему, которую вы хотели устранить?

• Нужно ли внести более существенные изменения, чтобы процесс начал работать оптимально?

Проработав слабые места, определите эффективность процесса. Это ещё одна возможность «отшлифовать» процесс, чтобы он работал как можно более чётко.

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

Преимущества документации по процессам

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

Существует четыре основных преимущества ведения документации по процессам — от устранения ошибок до улучшения распределения ресурсов и повышения эффективности.

Устранение ошибок

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

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

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

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

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

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

Сокращение непродуктивной работы

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

В числе распространённых препятствий, которые устраняет документирование процессов:

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

• Дублирование работы: когда задачи изначально правильно организованы, вероятность дублирования работы существенно снижается.

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

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

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

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

Это гарантирует, что ресурсы:

• Применяются правильно: когда команды знают, какие ресурсы использовать, они могут делать это правильно и эффективно.

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

• Работают на достижение желаемого результата: когда ресурсы распределены оптимально, их можно применять строго по назначению.

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

Улучшение обмена информацией

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

Преимущества оптимизированного обмена информацией:

• Работа сразу выполняется правильно: чёткие коммуникации сокращают риск возникновения путаницы и снижения качества работы.

• Создание базы знаний по процессам: обмен информацией помогает командам быть в курсе новых процессов.

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

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

Ускоряйте свой прогресс посредством документирования процессов

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

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

Попробовать ПО для управления рабочими процессами от Asana