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

В статье Владимира Репина рассмотрена методика формирования модели сквозного процесса масштаба компании в среде Business Studio. Приводится пример модели в нотации IDEF0. Рассматриваются сценарии выполнения сквозного процесса. Представленная методика может быть использована при работе с любым программным продуктом, предназначенным для проектирования архитектуры бизнес-процессов организации.

Введение

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

В качестве примера я выбрал процесс «Разработка нового изделия: от идеи до постановки на производство» и создал его модель в Business Studio.

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

Модель сквозного процесса в нотации IDEF0

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

Рис. 1. Диаграмма процесса «Разработка нового продукта». Контекст.

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

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

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

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

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

Рис. 2. Диаграмма процесса «Разработка нового продукта».

Очевидно, что процесс такого уровня сложности невозможно представить в виде какой-то одной цепочки операций (Work Flow — поток работ, в нотации eEPC или BPMN), выполняемых конкретными сотрудниками. (Теоретически, это сделать можно, но модель будет включать несколько тысяч шагов и сотни шлюзов, что сделает ее абсолютно нечитаемой и практически неприменимой.)

Если мы декомпозируем, например, «Выполнение НИОКР», то, скорее всего, на диаграмме увидим процессы, которые тоже нерационально представлять в виде диаграмм Work Flow.

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

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

На рис. 3 показана диаграмма процесса «Разработка требований к новому продукту».

Рис. 3. Диаграмма процесса «Разработка требований к новому продукту».

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

В реальности часть из них может работать одновременно, с разными задачами. Видно, что возможны возвраты и переделки, например, «Анализ возможности и необходимости создания нового продукта», «Разработка ТЗ на новый продукт» и «Принятие решения по новому продукту».

Если рассматривать блоки деятельности, представленные на схеме 3, как Work Flow (т. е. на следующем уровне), то для каждого такого процесса возможные различные условия:

• старта в части запуска предыдущими процессами;
• завершения в части запуска других процессов.

Сценарии выполнения сквозного процесса

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

Рис. 4. Диаграмма процесса «Разработка требований к новому продукту». Сценарии.

Желтый сценарий — «идеальный», когда всё делается с первого раза и продукт получается удачный.

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

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

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

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

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

Часто бывает, что при построении модели выхватывают какой-то один сценарий или микс 2–3 сценариев. При этом забывают о том, что возможны и другие сценарии. Результат — рыхлая, фрагментарная модель, которая никуда не годится (процесс не может быть выполнен).

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

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

Некоторые процессы в этой таблице требуют декомпозиции еще на один уровень, прежде чем их можно будет описать в формате Work Flow (например, в нотации BPMN).

Анализ сценариев

Далее, если все процессы будут описаны в формате Work Flow, можно будет для каждого процесса рассчитать показатели выполнения одного экземпляра:

• минимальное, нормативное, максимальное время выполнения;
• затраты на выполнение.

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

Затем, с учетом среднего количества запусков каждого процесса (возможны итерационные повторения), можно рассчитать показатели конкретного сценария сквозного процесса в целом:

• общее время выполнения;
• совокупные затраты.

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

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

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

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

Опубликовано по материалам:
http://www.finexpert.ru/view/stsenarii_vypolneniya_skvoznogo_protsessa/956

Март 2019 г.

Рекомендуемые материалы по тематике

Современные методы разработки системы корпоративных регламентов

Декомпозиция процессов в нотации BPMN в Business Studio

Процессные команды как основа культуры эффективности

Глоссарий. Положение о структурном подразделении

1. Сценарий бизнес-процесса формирования товарного ассортимента

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

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

WFD
(Work Flow Diagram — Диаграммы потоков работ,
Диаграммы алгоритмов) [6] используются
при описании бизнес-процессов нижнего
уровня. Этот стандарт описывает не
только статическую картину бизнес-процесса,
но и логику взаимодействия. Он включает
логические операторы, события начала
и окончания процесса, а также элементы,
показывающие временные задержки, а
также использует графическое описание
информационных потоков, взаимоотношений
между процессами обработки информации
и объектов. С его помощью можно описывать
любые сценарии действий, последовательности
выполнения работ. Каждый сценарий
сопровождается описанием процесса и
может быть использован для документирования
каждой функции. Отличительной особенностью
WFD — диаграммы является то, что стрелки
между операциями бизнес-процесса
обозначают потоки или временную
последовательность выполнения работ.

WFD-диаграмма
сценария бизнес-процессов оценки
предпочтений покупателей и формирования
ассортимента в отдела маркетинга ЗАО
«ТАНДЕР» показана на рисунке 1.2.

Рисунок
1.2 – Сценарий бизнес-процессов оценки
предпочтений покупателей и формирования
ассортимента в отделе маркетинга ЗАО
«ТАНДЕР»

Введем
пояснения к приведенной диаграмме (см.
таблицу 1.1)

Таблица
1.1 – Детализация сценария бизнес-процессов

Из
таблицы 1.1 следует следующая картина
относительно сценария бизнес-процессов
оценки предпочтений покупателей и
формирования ассортимента в отделе
маркетинга ЗАО «ТАНДЕР».

Раз
в полугодие Руководитель группы
планирования изучает тематические
статьи, знакомится с литературой,
обменивается опытом с коллегами из
других магазинов и выбирает перечень
товаров, из которых в течение всего
полугодия будет составляться ежедневный
ассортимент в магазинах «Магнит-Косметик».

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

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

Если
есть недочеты, то ассортимент отправляется
на корректировку Категорийному менеджеру,
который опять в течение максимум 1 недели
должен устранить замечания и представить
новую версию.

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

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

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

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

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

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

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

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

Концепция и определения

Бизнес-сценарий — это совокупность обстоятельств, которые могут возникать в рамках бизнеса. Как правило, сценарий основан на сочетании событий и факторов, которые составляют текущую ситуацию в бизнесе, а затем дополняются некоторыми прогнозами возможных событий, которые могут произойти в будущем. Цель бизнес-сценария состоит в том, чтобы определить, что, скорее всего, произойдет, если в будущем произойдут определенные события, что позволит компании предпринять немедленные шаги для минимизации негативных последствий, а также позиционировать себя, чтобы максимально использовать потенциальные возможности.
Одним из самых простых способов понять бизнес-сценарий является рассмотрение ситуации клиента, который хочет разместить заказ. Во время этого процесса клиент будет идентифицировать предметы, которые он хочет купить, и клерк или другой представитель бизнеса добавит эти предметы в заказ. Во время этой части события существует несколько различных сценариев, которые могут возникнуть в результате размещения этого заказа. Задача состоит в том, чтобы определить, какой из них наиболее вероятен, и следить за тем, чтобы курс действий соблюдался, и компания и клиент удовлетворены результатом.
Одним из возможных бизнес-сценариев для этой ситуации является то, что клерк или продавец проверяет и обнаруживает, что все предметы по заказу клиента находятся на складе и доступны для немедленной отгрузки после того, как были приняты меры по оплате. Результатом здесь является то, что компания производит продажу, и клиент может с нетерпением ждать получения заказанных товаров без задержки. С помощью этого бизнес-сценария нет никаких осложнений, и результат будет полезен для всех сторон.
Альтернативный бизнес-сценарий заключается в том, что один или несколько упорядоченных элементов недоступны. Здесь клерк может попытаться отклонить возможную неблагоприятную реакцию, сообщив клиенту о текущем статусе этих элементов, отметив конкретную будущую дату, когда эта часть заказа может быть выполнена. Если это приемлемо для клиента, тогда заказ может быть заполнен частичной отправкой сейчас и второй отправкой позже для заполнения оставшейся части заказа. В этом случае продажа по-прежнему завершена, и есть хорошие шансы, что отношения с клиентом останутся сильными.

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

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

Сценарии использования- это сценарий взаимодействия пользователя (или пользователей) с программным продуктом для достижения конкретной цели.

Цель: моделирование и проектирование взаимодействия пользователя с системой в рамках выполнения одного сценария. Пошаговое подробное взаимодействие пользователя с системой. 

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

Один сценарий использования имеет несколько потоков: основной и альтернативные. 

Выделение сценариев 

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

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

Каждый основной сценарий использования должен быть независимым от другого основного. Если есть определенные условия выполнения- указываем в “Предусловия”

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

Уровни описания и степени детализации

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

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

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

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

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

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

1. Детальный (detailed) вариант использования – это формальный документ с предопределённой структурой разделов; это, собственно, и есть Use case в его традиционном понимании.

Детальный уровень описания применяют при написании ТЗ. Преимущественно, при написании ТЗ все кейсы необходимо описывать на детальной степени; обязательно применять детальную степень и системный уровень при описании кейсов  с высоким уровнем риска. 

Структура сценария использования

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

1. Название. Краткое, максимально понятное. Описывающее общее действие пользователя.

 Пример: 

UC-1. Регистрация в личном кабинете 

UC-2. Регистрация в программе лояльности

UC-3. Добавление товара в корзину 

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

Пример: пользователь находится в “Корзине”, в “Корзине” добавлено 2 товара”. 

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

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

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

Сценарий использования должен отвечать на вопрос “Что делает пользователь?” “Что делает система?”

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

Например, формулировка  “добавил товар в корзину” неверная. 

Правильно:  “нажимает на кнопку “Добавить товар в корзину” и далее-  реакцию системы на действия пользователя. 

Альтернативные сценарии 

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

Важно! Альтернативный сценарий должен ссылаться только на один успешный сценарий. Недопустимо прописывать альтернативный сценарий для альтернативного сценария. 

Рассмотрим на примере авторизации

Предусловие: неавторизованный пользователь находится на странице авторизации и регистрации

Пример альтернативного сценария 

Альтернативный сценарий №1 

На шаге №3 успешного сценария, введенные данные не прошли проверку валидации. 

1. Система выводит информер  с указанием запрещенных символов.

2. Пользователь вводит корректные данные в поле “email”.

Далее сценарий продолжается от шага №3 успешного сценария.

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

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

Сценарии использования- это сценарий взаимодействия пользователя (или пользователей) с программным продуктом для достижения конкретной цели.

Цель: моделирование и проектирование взаимодействия пользователя с системой в рамках выполнения одного сценария. Пошаговое подробное взаимодействие пользователя с системой. 

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

Один сценарий использования имеет несколько потоков: основной и альтернативные. 

Выделение сценариев 

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

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

Каждый основной сценарий использования должен быть независимым от другого основного. Если есть определенные условия выполнения- указываем в “Предусловия”

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

Уровни описания и степени детализации

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

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

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

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

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

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

1. Детальный (detailed) вариант использования – это формальный документ с предопределённой структурой разделов; это, собственно, и есть Use case в его традиционном понимании.

Детальный уровень описания применяют при написании ТЗ. Преимущественно, при написании ТЗ все кейсы необходимо описывать на детальной степени; обязательно применять детальную степень и системный уровень при описании кейсов  с высоким уровнем риска. 

Структура сценария использования

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

1. Название. Краткое, максимально понятное. Описывающее общее действие пользователя.

 Пример: 

UC-1. Регистрация в личном кабинете 

UC-2. Регистрация в программе лояльности

UC-3. Добавление товара в корзину 

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

Пример: пользователь находится в “Корзине”, в “Корзине” добавлено 2 товара”. 

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

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

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

Сценарий использования должен отвечать на вопрос “Что делает пользователь?” “Что делает система?”

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

Например, формулировка  “добавил товар в корзину” неверная. 

Правильно:  “нажимает на кнопку “Добавить товар в корзину” и далее-  реакцию системы на действия пользователя. 

Альтернативные сценарии 

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

Важно! Альтернативный сценарий должен ссылаться только на один успешный сценарий. Недопустимо прописывать альтернативный сценарий для альтернативного сценария. 

Рассмотрим на примере авторизации

Предусловие: неавторизованный пользователь находится на странице авторизации и регистрации

Пример альтернативного сценария 

Альтернативный сценарий №1 

На шаге №3 успешного сценария, введенные данные не прошли проверку валидации. 

1. Система выводит информер  с указанием запрещенных символов.

2. Пользователь вводит корректные данные в поле “email”.

Далее сценарий продолжается от шага №3 успешного сценария.

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

Когда-то я уже упоминал одно из правил, которым руководствуется команда ПланФикса в своей работе: “Работать должны роботы”. Это не значит, что мы не хотим работать – просто мы любим перекладывать на плечи автоматов рутинную работу, которую можно описать понятными правилами, вроде этой:

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

Попробую для начала объяснить все простыми словами.

Что такое Процесс? Это жизненный цикл задачи, ее путь от создания до завершения. До этого момента процесс в ПланФиксе описывался набором статусов, которые могла принимать задача на этом пути. Теперь к этому набору статусов добавляется новая сущность – Сценарии.

Сценарий – это выполняемая автоматически последовательность операций.

Звучит как определение из учебника, конечно, и вряд дли это облегчает понимание… Ну давайте попробую чуть по-другому. Представьте, что теперь вы можете задавать в ПланФиксе правила, вроде “Если поле “Доставка” содержит значение “Да”, то подключить к задаче в качестве исполнителя группу “Отдел доставки” или “Когда задача перейдет в статус “Выполненная”, отправить клиенту письмо по шаблону “Уведомление клиента о выполнении”. Вот это и есть сценарии – наборы правил, которыми вы “оживляете” задачу, заставляете систему работать автоматически, перекладывая на нее операции, которые раньше делали вручную.

Наборы статусов и Сценарии теперь объединены в Процессы. Это отражено в том числе и в измененном интерфейсе раздела “Кастомизация” (update от 24.06.2016: теперь он перенесен в “Управление аккаунтом”):

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

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

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

Тут же добавляется возможность перевода в другой статус:

Удалить переход в определенный статус или настроить его параметры можно, кликнув на название этого статуса в списке:

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

Окно добавления нового сценария имеет стандартный для ПланФикса конструктив, который, скорее всего, не вызовет у вас особых вопросов:

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

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

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

С первым и последним все ясно – это события создания и удаления задачи – а вот в чем разница между двумя событиями, связанными с ее изменением?

Разница в том, что первый из них – это событие, которое сработает в тот момент, когда изменение задачи приведет к выполнению заданных условий (то есть, изменится один из параметров, участвующий в этих условиях). Именно он нам и нужен – когда у задачи изменится статус на “Выполненная”, сработает нужное нам событие:
Второй вариант указывает на событие, которое будет срабатывать каждый раз, когда задача будет изменена и условие будет выполняться, даже если изменялись другие параметры задачи, которые не описаны в этом условии. Если бы мы выбрали этот вариант в нашем примере, то скорее всего получили бы ложные срабатывания: ведь если задача находится в статусе “Выполненная” и уведомление клиенту уже отправлено, а в это время кто-то решил бы изменить у задачи исполнителя или значение какого-либо поля, то событие сработало бы опять и клиент получил бы повторное напоминание.

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

Идем дальше – указываем условие, при выполнении которого сработает наш сценарий. Оно в нашем примере очень простое и состоит из одной строки:

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

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

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

и настраиваем параметры отправки:

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

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

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

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

Вот и все, что касается настройки. Но это такое дело, конечно, что пока сам не попробуешь, не поймешь, так что пробуйте 🙂

Несколько важных замечаний в завершение:

• Механизм сценариев достаточно сложен и глубоко интегрирован в ПланФикс, поэтому наверняка в первое время вы будете сталкиваться с какими-то вопросами, ошибками или непонятными ситуациями – прошу сразу сообщать об этом нашей Службе поддержки, мы будем оперативно отвечать и/или править систему.
• В шаблонах задач теперь устанавливается не набор статусов, по которому будет перемещаться эта задача, а процесс целиком, который включает и набор статусов, и автоматические сценарии к нему. Все существующие наборы статусов стали частью одноименных процессов, поэтому в ваших шаблонах уже проставлены эти процессы.
• Сейчас мы запустили минимальный набор возможностей для автоматических сценариев – в основном для того, чтобы отладить сам механизм их работы. Но сразу после обработки первой волны ваших обращений, мы начнем увеличивать эти возможности. Развитие пойдет по трем основным направлениям:
  • добавление новых событий, при которых будут срабатывать сценарии (например “добавление нового действия”, “создание контакта” и т.п.);
  • добавление типов действий (в частности, в сценарии появится возможность изменять не только текущую, но и другие задачи);
  • добавление видов операций изменения (в нашем примере мы до них не добрались, так как пошли по ветке отправки письма, а не изменения задачи – так что можете самостоятельно оценить варианты изменений задачи, доступные на текущий момент).
• Глубокая интеграция механизма сценариев в ПланФикс приводит в том числе и к тому, что вы можете заменить некоторые стандартные процессы системы своими. В рассмотренном выше примере вы увидели, как можно сделать свою систему уведомлений в ПланФиксе – соответственно, вы можете полностью или частично “переписать” логику работы системы в различных ситуациях, заставить свою логику работать вместо или вместе со стандартной. И это касается не только уведомлений.
• Обычно в системах управления бизнес-процессы и автоматические сценарии доступны только на старших тарифах, но мы решили сделать процессы и сценарии доступными для всех тарифов без ограничений. Даже в бесплатной версии ПланФикса мы даем возможность добавить один автоматический сценарий, чтобы все пользователи смогли оценить мощь этого механизма. Для новых аккаунтов в ходе пробного периода использование сценариев доступно без ограничений, как в любом платном пакете.
• Нам интересны как сценарии, которые у вас получилось реализовать при помощи нового механизма, так и сценарии, для запуска которых в ПланФиксе пока не хватает возможностей – делитесь ими с нами, пожалуйста, это поможет нам не сбиваться с курса и добавлять важные для вас функции.

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