📜 Справочный архивный материал (2012 г.)

Эта статья была опубликована в блоге нашей предыдущей open-source СЭД Detrix. Мы сохранили её для истории. Обратите внимание, что публикация носит неформальный, творческий и юмористический характер, а оригинальная авторская стилистика прошлых лет сохранена полностью — это скорее живой опыт и отвлеченные размышления разработчика, нежели руководство к действию. Наша новая BPM-платформа DOC-V продолжает эти идеи на современном технологическом уровне.

Скачать DOC-V бесплатно

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

  1. Создание. Заявка только что создана автором, она может быть отредактирована и оставлена на неопределенный срок в таком состоянии. До тех пор, пока пользователь не воспользуется действием Отправить в техподдержку.
  2. Ожидание. Отправляем заявку в службу поддержки и ждем, когда один из сотрудников поддержки возьмет заявку в работу. При помощи кнопки Взять в работу, которая должна быть доступна всем специалистам службы поддержки.
  3. Исполнение. По заявке выполняются все необходимые работы. По завершении мероприятий исполнитель (тот самый сотрудник, который взял заявку в работу) нажимает кнопку Закрыть заявку.
  4. Выполнена. При необходимости заявитель может вернуть заявку на доработку при помощи соответствующего действия.

Описанный жизненный цикл документа в СЭД Detrix именуется маршрутом. А перечисленные этапы — точками маршрута. Маршрут выполняет следующие задачи:

Переходим к реализации.

Открываем страницу Маршрута, нажимаем на кнопку Добавить точку.

Маршрут документов в СЭД Detrix

В атрибут Название вводим значение Создание. Нажимаем на кнопку Делегировать и выбираем Название действия — Редактировать, Тип — Переменная, Значение — АВТОР.

Контекст делегирования маршрута

А теперь разберем чего же мы там понажимали. Если коротко и по существу, мы делегировали автору документа право на выполнение действия Редактировать, которое добавили ранее на странице Действия. В списке Название, как вы могли убедиться, находятся все действия, которые ранее мы добавляли на странице Действия. Список Тип позволяет определить кому мы делегируем действие (проще говоря, кому покажем кнопку на панели действий документа). Тут возможны варианты: Структура, Группы, Переменная, Поле. Если выбрать Структура, то нужно будет выбрать сотрудника (сотрудников) и/или подразделение (подразделения), которому (которым) будет доступно действие, непосредственно из Структуры. Вариант Группы позволяет указать группу сотрудников, которым будет делегировано действие (мы рассмотрим подробнее этот вариант чуть позже). В качестве Переменной выступает АВТОР документа (у каждого документа он свой, потому и Переменная). Ну, а если выбрать Поле, то действие будет делегировано тем сотрудникам, которые будут находиться в соответствующем поле документа.

Итак, тот, кто создаст заявку (он же Автор) сможет отредактировать документ. Ему же нужно предоставить возможность отправки заявки в работу. А для этого необходимо делегировать действие Отправить в техподдержку. Кому? Конечно, Автору. Делегируйте.

А теперь представляем себе ситуацию, когда наступает благословенный момент, и автор отправляет заявку в техподдержку. Наступление этого момента ожидали система, бизнес-процесс, желающие поработать в поддержке… Detrix позволяет описать такое ожидание посредством размещения действия в контексте ожидания. Для этого нажмите Ожидать. В списке Название будут находиться те действия, исполнение которых система теоретически может дождаться от пользователей, т.е. действия, которые вообще в принципе могут быть выполнены пользователями и  были  ранее кому-либо делегированы. Выберите Отправить в техподдержку. Тип укажите Переменная, а Значение — АВТОР. Такое положение вещей предписывает системе ожидать выполнение автором документа действия Отправить в техподдержку. Если автор вдруг выполнил иное действие (например, Редактировать) — ничего не случится. Если вдруг действие было делегировано не только автору, но и другим сотрудникам, которые начали дружно нажимать на заветную кнопочку — также ничего не произойдет. И только тогда, когда автор выполнит действие — система переместит документ на следующую точку маршрута. Которую нужно добавить. Но перед этим еще раз взглянем на то, что у нас получилось. А получиться должна вот такая картинка:

Точка маршрута Создание

Добавляем новую точку посредством кнопки Добавить точку. Вводим Название — Ожидание. Именно на этой точке окажется документ, после того как его автор выполните действие Отправить в техподдержку. Если оставить все как есть, то пользователь, открывший документ на этой точке, не увидит ни одной кнопки, поскольку контекст делегирования пуст. Нас, конечно, такое положение вещей не сильно устраивает, поэтому займемся делом. Нажимаем Делегировать. Название действия — Взять в работу. Кому будем делегировать? Сотрудникам техподдержки. Указать таких сотрудников можно несколькими способами. Первый способ — выбрать из Структуры. Но далеко не факт, что в соответствующем подразделении собраны именно те, кто занимаются заявками. И захламлять почтовые ящики сотрудников, непричастных процессу, уведомлениями на заявки не совсем хорошая идея. Поэтому выбрать полностью организационную единицу может не получиться и тогда придется выбирать сотрудников поименно. А в случае расширения / сокращения штата техподдержки придется открывать маршруты документов (у нас может быть не одна такая заявка) и вносить изменения вручную. Поэтому мы пойдем другим путем, а именно воспользуемся Группами. Группы — это по сути недоразвитый вариант ролей. А фактически это справочник, по умолчанию находящийся в меню Справочники / Системные. Открываем его и создаем новую группу Техподдержка, в которой указываем всех сотрудников службы поддержки. Теперь в случаем изменения структуры, достаточно будет обновить эту группы, и все маршруты и действия получат новый список автоматически.  А теперь делегируем нашу Взять в работу созданной группе Техподдержка.

Что мы имеем на текущий момент? Мы имеем такую ситуацию, что если вдруг какой-то сотрудник техподдержки, имея соответствующие права доступа, вдруг откроет заявку, то он сможет взять ее в работу. Но он может и не догадаться о том, что ему нужно куда-то заходить и что-то открывать. Поэтому, не полагаясь на случай, мы, как порядочные проектировщики бизнес-процесса, просто обязаны его и всех его коллег уведомить о том, что есть документ (заявка), требующих их внимания. Для таких целей служит действие Уведомление. Оно отправляет указанным адресатам почтовое сообщение (в собственный почтовый модуль системы, откуда сообщение может быть отправлено на внешний почтовый сервер, если настроен соответствующим образом профиль пользователя). Осталось решить, кто это Уведомление запустит. Раз других желающих при текущем раскладе дел не наблюдается запускать придется системе самостоятельно. Для такого запуска предназначен контекст выполнения — все действия, которые размещаются в нем, выполняются системой в тот момент, когда документ оказывается на текущей точке. Нажимаем кнопку Выполнить. В Названии указываем тип действия Уведомление и настраиваем его вот таким образом:

Читайте внимательно, что теперь произойдет. После того как автор документа нажмет на делегированную ему кнопку Отправить в техподдержку, документ переместится на точку маршрута Ожидание. И выполнится действие Уведомление, размещенное в контексте выполнения маршурта. Которое уведомит о наличии заявки всех сотрудников поддержки. Которые откроют документ и увидят делегированное им действие Взять в работу. Которое самый шустрый из них выполнит. Система же будет ждать этого самого выполнения. Подскажем ей, что она должна это делать, нажав на Ожидать и указав Название — Взять в работу. От кого будем ожидать выполнение действия? Ведь сотрудников поддержки может быть неизвестное количество людей. Собственно, нам нет никакой разницы, кто из них начнет работу по заявке, поэтому мы можем ожидать выполнения действия от любого из них. Вот и выбираем Тип — Переменная, Значение — Любой. Ну и неплохо было бы этого любого куда-то записать, чтобы в будущем иметь возможность работать с ним персонально. Для этого установим переключатель Записать в поле и в появившемся списке полей структурного типа выберем поле Исполнитель. Все сохраняем и любуемся:

Точка маршрута Ожидание

И еще один момент. В нашем сценарии был вот такой пункт:

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

Конечно, присваивать эти номера должна также сама система и лучший момент для того, чтобы это сделать — сразу после того как пользователь отправит заявку в поддержку. Т.е. в контексте выполнения точки Ожидание. А поэтому нажимаем еще раз на Выполнить и выбираем действие Регистрация. Данный тип действия позволяет присваивать документам уникальные регистрационные номера в соответствии с нумераторами. В новой вкладке браузера откройте Справочники / Системные / Регистрационные номера. Здесь настраиваются эти самые нумераторы. Жмем Новая запись. В открывшемся окне заполняем атрибуты:

Создание регистрационного номера

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

Далее галопом по маршруту:

Итого:

Итоговый маршрут заявки

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

Разделы справочного архива Detrix

Типы полей СЭД

Действия процессов

Настройка и структура