Что такое модель сценариев процесса

В статье Владимира Репина рассмотрена методика формирования модели сквозного процесса масштаба компании в среде 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

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

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

Сценарное моделирование (планирование) – это один из наиболее эффективных системных инструментов стратегического менеджмента вообще и стратегического анализа в частности.

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

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

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

Особую роль в становлении высококачественного сценарного моделирования, так же как и для обеспечения эффективного стратегического менеджмента в целом, может сыграть система так называемых стратегических бесед ( strategic conversations). Один из результативных способов построения системы стратегических бесед – это проведение в организации серии адекватных бесед-диалогов между соответствующими менеджерами и специалистами в процессе освоения и развития метода сценарного планирования.

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

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

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

Восемь шагов методики

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

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

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

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

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

• Должна ли наша организация в течение ближайшего года запустить в действие новое направление в сети реализации профильных продуктов или в области НИОКР либо открыть новый филиал?
• Надо ли нам приобретать активы в новой отрасли бизнеса?
• Начинать ли практическое осуществление таких крупных проектов, как Проект 1 и Проект 2, или пока воздержаться, или вообще от них уже стоит отказаться?

При наличии данных, команда разработчиков сценариев:

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

Шаг 2. Установление ключевых факторов ближней внешней среды.На втором этапе фиксируются и анализируются ключевые факторы из ближней внешней среды организации, которые определяют успех или неудачу по каждому из направлений, установленному на Шаге 1, а также выявленные на Шаге 1 стратегические вопросы.Такие факторы устанавливаются по внешней среды организации, ее потребителям и конкурентам.

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

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

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

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

Шаг 4. Ранжирование по важности и степени неопределенности.На этом этапе проводится ранжирование всех факторов Шага 3 и Шага 2 по двум критериям:

1. Важность каждого фактора указанных уровней для принятия стратегических решений Шага 1.
2. Степень неопределенности по факторам Шага 3 и Шага 2 для решения стратегических вопросов Шага 1.

Основная задача Шага 4 – определение основных факторов по каждому критерию, т. е отдельно двух-трех факторов, которые являются самыми важными, и отдельно двух-трех самых неопределенных факторов.

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

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

Цель Шага 5 состоит в том, чтобы в соответствии с разными логическими стержнями выйти на относительно небольшое число сценариев, которые являются разными по критерию содержания решений, которые должны приниматься по стратегическим вопросам Шага 1.

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

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

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

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

• Сценарий – 1. Высокие цены на бензин устанавливаются в условиях повсеместного протекционизма. В таком случае конкурентное преимущество будут иметь местные производители малолитражных машин, т.е. экономичных по фактору бензина автомобилей.
• Сценарий – 2. Высокие цены на бензин устанавливаются в условиях отсутствия на глобальном рынке протекционистских барьеров. В такой ситуации на глобальном рынке будет доминировать импорт автомашин, которые являются наиболее конкурентоспособными по фактору использования дорогого бензина.
• Сценарий – 3. Низкие цены на бензин назначаются в условиях протекционизма. Тогда, например, американские автомобили, которые потребляют много бензина, будут иметь хороший сбыт в США, но не за рубежом.
• Сценарий – 4. Низкие цены на бензин устанавливаются в условиях открытого глобального рынка. В подобной ситуации экономичные автомашины будут достаточно интенсивно конкурировать между собой по всему миру, но при этом большие автомобили (не малолитражки) станут находить спрос и на зарубежных рынках.

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

Шаг 6. «Очистка» сценариев.На данном этапе, т. е. в ситуации, когда установлены наиболее важные факторы-драйверы, которые задают логику развития различных сценариев, надо вернуться к ключевым факторам Шага 3 и Шага 2.

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

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

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

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

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

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

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

Автор: Сергей Александрович Попов,
кандидат экономических наук, доцент Института бизнеса и делового администрирования АНХ при Правительстве РФ.
Источник: Опубликовано на Elitarium.Ru

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

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

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

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

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

Превращение пользовательских историй в сценарии

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

Но при переходе от историй к сценариям использования нам нужно выполнить переход от прототипа к реальной системе, и описываемые сценарии использования должны быть реализованы в реальном железе и программном коде.
Много ли вы видели концепт-каров, воплощённых затем в реальный автомобиль? Часто новый автомобиль отличается от исходного концепта так сильно, что проследить связь не всегда удаётся. Ниже приведён один из таких примеров от лидеров автопрома – концерна Toyota. Вот уж кто денег на ветер не бросает и точно знает, что делает. Но разница видна сразу.

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

С чего начать?

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

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

Базовая история

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

Последовательность действий системы (алгоритм выполнения операции), описанная в базовой истории, называют базовым путём выполнения данной операции.

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

Фильтрация историй

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

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

Переход к вариантам использования

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

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

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

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

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

• Единичность — сценарий описывает один и только один вариант поведения системы.
• Завершенность — сценарий полностью определен в одном месте и содержит всю информацию, необходимую для его корректного восприятия всеми заинтересованными лицами.
• Непротиворечивость — сценарий не противоречит другим сценариям.
• Связность (последовательность) – сценарий дополняет другие сценарии и составляет с ними единую картину будущей системы.
• Атомарность — сценарий нельзя разделить на более мелкие сценарии без потери конкретного полезного результата.
• Отслеживаемость — сценарий полностью или частично соответствует деловым нуждам, как заявлено заинтересованными лицами и задокументировано в перечне историй.
• Актуальность — сценарий не стал устаревшим с течением времени.
• Реализуемость — сценарий может быть реализован в рамках проекта.
• Недвусмысленность — сценарий выражает действия и факты (вехи), а не субъективные мнения; не содержит жаргонизмов или терминов, понятных только некоторым из участников проекта; возможна одна и только одна его интерпретация.
• Востребованность — сценарий представляет собой определенное заинтересованным лицом поведение системы, отсутствие которого ведет к неполноценности решения, и которое не может быть проигнорировано.
• Проверяемость — полнота реализации сценария может быть проверена на каждом шаге сценария.

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

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

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

Применение сценариев использования

Модель сценариев использования – очень гибкий инструмент анализа и проектирования. Из-за этого эту модель предпочтительнее применять при использовании гибких методологий, при больших объёмах требований или в командах с большим количеством взаимодействий.

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

Отдельно нужно упомянуть о важнейшей роли сценариев при проектировании, реализации и тестировании разрабатываемой системы. Достаточно указать, что сценарии лежат в центре представления архитектуры Филиппа Крачтена («модель 4+1»).

P.S. В довесок ссылка на статью Александра Шамрая «Советы для написания хороших сценариев использования». Однако следует иметь в виду, что в этой статье речь идёт о сценариях взаимодействия пользователя с системой, несколько подменяя определение сценария, введённое в стандарте UML, и при этом искажая суть сценария. Однако, если иметь в виду этот момент, то остальное описание будет весьма полезным.

Зачем нужно моделировать индивидуальные и типовые сценарии? +6

Постановка задачи

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

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

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

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

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

На уровне предприятия работа продолжается:

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

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

1. Валидировать поступающие с верхнего структурного уровня задания;
2. Создавать планируемые сценарии планируемых работ, которые по замыслу их создателя должны привести к выполнению заданий, пришедших с верхнего структурного уровня;
3. Валидировать планы, и на их основе создавать задания, которые назначать конкретным исполнителям;
4. Выполнять задания;
5. Анализировать результаты выполненных работ;
6. На основе полученных данных производить корректировку планируемых работ, и координацию этих изменений как со смежными единицами, так и с верхней структурной единицей;
7. Поддерживать знание о производственной мощности каждого исполнителя;
8. С целью повышения производительности находить и «расшивать» узкие места;
9. Вычислять суммарную производственную мощность структурной единицы в целом. Информацию об этом передается как смежным единицам, так и на уровень выше.

Пусть перед ИТ отделом стоит задача: необходимо автоматизировать следующие функции:

1. Моделирование операций и сценариев на основе типовых схем;
2. Сравнение полученных результатов с планируемыми;
3. Корректировка планов.

Введение

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

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

• После завершения операции 3 начнется выполнение операции 5;
• Результат операции 5 будет играть роль вспомогательного инструмента в операции 6.

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

Пример из области строительства

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

Отличие в том, что типовой проект не адаптирован под конкретные условия. Конкретные условия – это (в том числе) геология и рельеф местности. Например, уклон в 30 градусов на песчаном склоне, затапливаемом в половодье.

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

Пусть в проекте указано, что в качестве щебенистой фракции в бетоне, который идет на заливку перекрытия, необходимо использовать гранитный щебень фракции 20-50. Но местный производитель готов поставить только известняковый. Покупать же гранитный щебень невероятно дорого! Вопрос: можно ли заменить гранитный щебень на известняковый? Проектная организация, зная местные условия, может произвести замену материала, перечитав допустимые нагрузки, и предложить залить перекрытие бетоном толщиной не 20 см, а 30 см. Правда, для этого придется заменить фундаментные блоки на монолитный ростверк, что приведет к удорожанию фундамента. Поэтому возникает вопрос, что дешевле: привезти гранитный щебень, или пойти на удорожание фундамента? Если вы закажете индивидуальный проект, то эти вопросы задаст вам исполнитель проектных работ. Он же даст и ответы на них. Если же вы купите типовой проект, то вам придется задавать эти вопросы самостоятельно и решать их на свой страх и риск.

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

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

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

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

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

Зачем моделировать сценарии?

Так есть ли необходимость в моделировании индивидуальных или в моделировании типовых сценариев?

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

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

Когда мы можем не моделировать индивидуальные сценарии?

1. Когда отклонения планируемых сценариев от типового происходят редко, и анализ этих отклонений не дает ощутимой выгоды.

Когда мы вынуждены моделировать индивидуальные сценарии?

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

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

Когда можно не моделировать типовые сценарии?

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

Когда надо моделировать типовые сценарии?

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

Формулировка проблемы

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

1. Моделирование операций и сценариев на основе типовых схем;
2. Сравнение полученных результатов с планируемыми;
3. Корректировка планов.

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

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

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

Вывод

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

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

Общее описание модели «Сценарное планирование»

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

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

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

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

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

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

Цели сценарного планирования можно сопоставить друг с другом следующим образом (в варианте, предложенном Ван дер Хейденом в 2002 г.):

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

Перечисленные цели приводят к четырем видам сценарного планирования:

1. Уяснение смысла: разовое осуществление сценарного планирования исследовательского характера для понимания сущности сложных ситуаций.
2. Разработка стратегии: использование сценариев для проверки бизнес-предложений, которые можно реализовать в будущем, в разных условиях, описываемых соответствующими сценариями.
3. Упреждение: способность компании видеть происходящее в бизнес-среде, воспринимать его и понимать. Бизнес-среда требует мобилизации максимально возможных ресурсов для наблюдения за событиями, получения опыта, осмысления, рационалистического обоснования и принятия решения. Упреждающая цель сценариев наглядно демонстрирует, насколько для компании важно уметь наблюдать за происходящим в окружающем мире, используя для этого стратегический диалог.
4. Адаптивное организационное обучение: для достижения этой цели компания должна сделать еще один шаг — включить действие в процесс. По содержанию  эта цель сопоставима с описанием сценарного обучения, предложенного Л. Фейи и Р. Рэнделлом (1998), которые показали, что сценарии должны быть интегрированы в процесс принятия решений. Такой подход предполагает, что при применении модели адаптивного организационного обучения осуществляется переход от разовой разработки стратегии к постоянно продолжающемуся стратегическому планированию и накоплению опыта.

Когда следует применять модель «Сценарное планирование»

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

Royal Dutch Shell указывает четыре причины, объясняющие, почему сценарное планирование является важным инструментом для развития стратегий:

1. Наличие противоречащих допущений. Учет этой особенности очень тесно связан с тем, насколько строго надо использовать выбранную умозрительную модель. Объяснение допущений, принимаемых в отношении будущего, к которым прибегают как отдельные люди, так и их группы, помогает компании в данный момент действовать более эффективно.
2. Признание того факта, что степень неопределенности может быть разной. Используя сценарное планирование, компания начинает понимать, чего именно она не знает и как ей при этом действовать.
3. Расширение перспектив. Сценарии охватывают, помимо прочего, и «слепые пятна», для чего внимательно изучаются допущения, расширяется видение и собирается информация, получаемая от представителей различных сфер.
4. Разрешение дилемм и конфликтов. Сценарии помогают понять суть конфликтов и дилемм, с которыми сталкиваются пользователи этой модели, или даже устранить их.

Как следует пользоваться моделью «Сценарное планирование»

В книгах по менеджменту (Шварц, 1991; Ван дер Хейден, 2002; Рингленд, 1998, 2002) предложено несколько методов сценарного планирования, но все процессы такого планирования всегда начинаются с выявления пробелов в знаниях и  неопределенностей, а затем с создания команды, занимающейся сценарием и состоящей из сотрудников компании и специалистов внешних организаций, помогающим им. На этом этапе процесс структурирован. Затем его основных участников просят хорошо изучить сложившуюся ситуацию, проводя для этого необходимые собеседования с персоналом и выполняя этот шаг так, чтобы проверить текущие допущения, принятые командой. На каждом последующем шаге этот процесс все время углубляется. После того как участники в целом согласовали содержание сложившейся ситуации для анализируемого варианта, необходимо разделить по кластерам основные действующие силы и детально проработать сценарии. Потом следует изучить соответствующие влияния каждого сценария и тщательно проанализировать его последствия. Полученная таким образом информация затем проверяется с привлечением различных заинтересованных лиц, имеющих прямое отношение к данному бизнесу.

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

Выводы

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