Метод кейсов — Википедия

Материал из Википедии — свободной энциклопедии

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

Метод был впервые применён в Гарвардской школе бизнеса в 1924 году^[1], чьи преподаватели быстро поняли, что не существует учебников, подходящих для аспирантской программы в бизнесе. Их первым решением данной проблемы было интервью с ведущими практиками бизнеса и написание подробных отчётов о том, чем занимались эти менеджеры, а также о факторах, влияющих на их деятельность. Слушателям давались описания определённой ситуации, с которой столкнулась реальная организация в своей деятельности, для того чтобы ознакомиться с проблемой и найти самостоятельно и в ходе коллективного обсуждения решение.

Кейс-метод широко используется в бизнес-обучении во всём мире и продолжает завоёвывать новых сторонников. Так, с 50-х годов двадцатого века бизнес-кейсы получают распространение в Западной Европе. Лидирующие бизнес-школы Европы INSEAD, LBS, HEC, LSE, ESADE принимают деятельное участие не только в преподавании, но и в написании таких кейсов^{[источник не указан 67 дней]}.

В России с конца 90-х годов используются переводные (западные) кейсы. Со второй половины 2000-х годов интерес к кейс-методу возрастает — появляются вузовские кейс-клубы (Кейс-клуб НИУ-ВШЭ, НИЯУ МИФИ, Центр карьеры НИТУ «МИСиС», РЭУ им Г. В. Плеханова, МФТИ, МГТУ им. Н. Э. Баумана, МГИМО, Российский государственный университет нефти и газа имени И. М. Губкина, Финансовый Университет при Правительстве РФ, Новосибирский государственный университет, Алтайский государственный университет и др.)

[источник не указан 67 дней].

С начала 2000-х годов кейсы широко используются в практике преподавания естественнонаучных и технических дисциплин. Например, Journal Of Chemical Education регулярно публикует соответствующие методические материалы. Практика использования кейсов при обучении различным специальным дисциплинам — технологическим, туристским, медицинским — наметилась и в России^{[источник не указан 2841 день]}.

• Структурированные кейсы (highly structured cases) — короткое и точное изложение ситуации с конкретными цифрами и данными. Для такого типа кейсов существует определённое количество правильных ответов. Они предназначены для оценки знания и/или умения использовать одну формулу, навык, методику в определённой области знаний^[2].
• Неструктурированные кейсы (unstructured cases). Они представляют собой материал с большим количеством данных и предназначены для оценки стиля и скорости мышления, умения отделить главное от второстепенного и навыков работы в определённой области. Для них существуют несколько правильных вариантов ответов и обычно не исключается возможность нахождения нестандартного решения ^[2].
• Первооткрывательские кейсы (ground breaking cases) могут быть как очень короткие, так и длинные. Наблюдение за решением такого кейса даёт возможность увидеть, способен ли человек мыслить нестандартно, сколько креативных идей он может выдать за отведённое время. Если проходит групповое решение, то может ли он подхватить чужую мысль, развить её и использовать на практике^[2].

Матрица проектного (первоотрывательского) кейса включает^[3]:

• Исследовательский вопрос
• Актуальные исследовательские проблемы
• Поле типовых задач
• Эталонные управленческие решения

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

В соответствии с исследованиями, проведёнными ECCH^[en], некоммерческой организацией, специализирующейся на разработке и развитии кейс-метода в бизнес-образовании, наибольшей популярностью как у преподавателей, так и у студентов пользуются кейсы, основанные на полевых исследованиях (в отличие от кейсов, основанных на опубликованных данных). Традиционно бизнес-кейс пишется в партнёрстве академических преподавателей и менеджеров компаний.

В настоящее время наибольшее распространение получили бизнес-кейсы, написанные по североамериканским компаниям, так как именно здесь зародилась культура ситуационного анализа^{[источник не указан 2841 день]}. Однако с конца 90-х годов деятельную роль в написании кейсов начинают принимать профессора европейских школ, ощущая недостаток национальных иллюстраций к бизнес-задачам. Благодаря международным связям деятельно включаются в этот процесс и азиатские школы. Так, например, INSEAD, европейская бизнес-школа, располагающаяся во Франции и Сингапуре, является признанным лидером в написании бизнес-кейсов по международным рынкам. В 2008 году INSEAD победил в семи из девяти категорий ECCH European Case Award.

Метод кейсов — Википедия

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

История метода кейсов

Метод был впервые применён в Гарвардской школе бизнеса в 1924 году^[1], чьи преподаватели быстро поняли, что не существует учебников, подходящих для аспирантской программы в бизнесе. Их первым решением данной проблемы было интервью с ведущими практиками бизнеса и написание подробных отчётов о том, чем занимались эти менеджеры, а также о факторах, влияющих на их деятельность. Слушателям давались описания определённой ситуации, с которой столкнулась реальная организация в своей деятельности, для того чтобы ознакомиться с проблемой и найти самостоятельно и в ходе коллективного обсуждения решение.

Кейс-метод широко используется в бизнес-обучении во всём мире и продолжает завоёвывать новых сторонников. Так, с 50-х годов двадцатого века бизнес-кейсы получают распространение в Западной Европе. Лидирующие бизнес-школы Европы INSEAD, LBS, HEC, LSE, ESADE принимают деятельное участие не только в преподавании, но и в написании таких кейсов.

В России с конца 90-х годов используются переводные (западные) кейсы. Со второй половины 2000-х годов интерес к кейс-методу возрастает — появляются вузовские кейс-клубы (Кейс-клуб НИУ-ВШЭ, НИЯУ МИФИ, Центр карьеры НИТУ «МИСиС», РЭУ им Г. В. Плеханова, МФТИ, МГТУ им. Н. Э. Баумана, МГИМО, Российский государственный университет нефти и газа имени И. М. Губкина, Финансовый Университет при Правительстве РФ, Новосибирский государственный университет и др.).

С начала 2000-х годов кейсы широко используются в практике преподавания естественнонаучных и технических дисциплин. Например, Journal Of Chemical Education регулярно публикует соответствующие методические материалы. Практика использования кейсов при обучении различным специальным дисциплинам — технологическим, туристским, медицинским — наметилась и в России^{[источник не указан 2395 дней]}.

Классификация кейсов

По структуре

• Структурированные кейсы (highly structured case) — короткое и точное изложение ситуации с конкретными цифрами и данными. Для такого типа кейсов существует определённое количество правильных ответов. Они предназначены для оценки знания и/или умения использовать одну формулу, навык, методику в определённой области знаний.
• Неструктурированные кейсы (unstructured cases). Они представляют собой материал с большим количеством данных и предназначены для оценки стиля и скорости мышления, умения отделить главное от второстепенного и навыков работы в определённой области. Для них существуют несколько правильных вариантов ответов и обычно не исключается возможность нахождения нестандартного решения.
• Первооткрывательские кейсы (ground breaking cases) могут быть как очень короткие, так и длинные. Наблюдение за решением такого кейса даёт возможность увидеть, способен ли человек мыслить нестандартно, сколько креативных идей он может выдать за отведённое время. Если проходит групповое решение, то может ли он подхватить чужую мысль, развить её и использовать на практике^[2].

По форме представления

• Бумажные кейсы
• Видеокейсы
• Notts County 2.0

По размеру

• Полные кейсы (в среднем 20-25 страниц) предназначены для командной работы в течение нескольких дней и обычно подразумевают командное выступление для презентации своего решения.
• Сжатые кейсы (3-5 страниц) предназначены для разбора непосредственно на занятии и подразумевают общую дискуссию.
• Мини-кейсы (1-2 страницы), как и сжатые кейсы, предназначены для разбора в классе и зачастую используются в качестве иллюстрации к теории, преподаваемой на занятии. Во многих случаях мини-кейс может быть сформулирован кратко, в виде одного-двух абзацев, и снабжён вопросами, на которые требуется дать ответ в обсуждении.

По уровню сложности

По дисциплинам

По типам компаний

• Кейсы о крупном региональном бизнесе
• Кейсы о малом и среднем бизнесе

По регионам

• Североамериканские кейсы
• Европейские кейсы
• Кейсы по развивающимся странам и странам с переходной экономикой

Сущность кейса

Бизнес-кейс — это специально подготовленный учебный материал, который отражает конкретную проблемную бизнес-ситуацию, требующую управленческих решений со стороны менеджмента компании. В ходе занятий преподаватель направляет студентов в поиске таких решений. По словам Джейми Андерсона (недоступная ссылка), профессора по стратегическому менеджменту в TiasNimbas Business School, Нидерланды, успешность бизнес-кейса зависит от трёх критериев:

[3]

1. Достаточный объём первичных и статистических данных;
2. Участие топ-менеджера компании в ходе написания кейса;
3. Наличие захватывающей бизнес-ситуации, позволяющей применить разнообразные методы анализа при поиске решения.

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

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

[источник не указан 2395 дней]. Однако с конца 90-х годов деятельную роль в написании кейсов начинают принимать профессора европейских школ, ощущая недостаток национальных иллюстраций к бизнес-задачам. Благодаря международным связям деятельно включаются в этот процесс и азиатские школы. Так, например, INSEAD, европейская бизнес-школа, располагающаяся во Франции и Сингапуре, является признанным лидером в написании бизнес-кейсов по международным рынкам. В 2008 году INSEAD победил в семи из девяти категорий^[4]ECCH European Case Award.

Кейс-метод в бизнесе

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

В первую очередь, это консалтинговые и аудиторские компании, использующие метод бизнес-кейсов в собеседованиях при приёме на работу. Такой способ позволяет уже на ранней стадии выявить у кандидатов способность к анализу и синтезу, умение чётко и структурированно излагать свои мысли. В качестве первоначального этапа отбора часто используется корпоративный кейс-чемпионат. Так, компания Microsoft проводит ежегодный Microsoft Case Competition, объединяющий лучшие студенческие команды со всей России.

Другие популярные кейс-чемпионаты:

Примечания

Литература

• Деркач А. М. Кейс-метод в обучении // Специалист. — 2010. — N 4. — С. 22-23.

Ссылки

Кейсы на Market Sizing: как не просчитаться

Во время кейс-интервью, когда ситуация становится стрессовой, любой вопрос интервьюера (даже самый, казалось бы, простой) может ввести вас в ступор, а поиск ответа на него с помощью стандартного фреймворка только ухудшит положение. Доказать интервьюеру, что перед ним сидит не среднестатистический кандидат, а уже готовый к реальной работе сотрудник, поможет понимание того, какой перед вами тип кейса ― Market Entry, Growth Strategy, Profitability Case, Mergers and Acquisitions, Competitive Response, Pricing или, скажем, Valuation. Для решения каждого из них существуют свои универсальные подходы, знать которые необходимо каждому кандидату. В этой статье мы разберем случай, когда вас озадачат вопросом на Market Sizing.

---

Market Sizing Case ― это вообще о чем?

Такой тип кейса могут дать в отдельности, или как часть кейса о выходе на рынок. Market Sizing не только про конкретные рынки, но и про разные виды оценок. Например, вас могут спросить, насколько велик рынок 3D телевизоров, подгузников или холодильников, или попросят прикинуть, сколько машин в России продается каждый год. Сколько АЗС есть в Париже? Сколько людей рождается ежегодно? Сколько китайцев сейчас за рулем?
Этот тип кейса проверяет общий кругозор, умение логически мыслить и ваши математические способности ― комфортно ли вам работать с вычислениями, можете ли вы быстро справляться с подсчетом огромных чисел. В идеале ваш ответ не должен отличаться от реального более чем на 20%. Иногда сам интервьюер не имеет правильного ответа, а в редких случаях бывает наоборот ― реальные цифры могут быть известны даже вам. В любом случае, главное не результат, а то, как шел ход ваших мыслей и как вы структурировали свое решение. Если вы не стали озвучивать важные этапы своего решения и в целом не убедили интервьюера в его правильности, считайте, что интервью вы провалили.

Как решить?

Есть три золотых правила решения кейсов типа Market Sizing. Остановимся подробно на каждом из них.

Во-первых, обязательно соблюдайте принцип MECE (аббревиатура от Mutually Exclusive and Collectively Exhaustive ― «взаимно исключающие, совместно исчерпывающие») ― его применяют почти во всех проектах McKinsey и на нем основаны многие фрейморки. Этот принцип значит, что вы разделяете решение проблемы на несколько пунктов (в McKinsey, например, это не менее двух и не больше пяти) так, чтобы каждый из них не повторял другой. Неточности и повторения избегаются за счет подпунктов. После составления плана решения стоит взглянуть на него еще раз. Если все аспекты проблемы разделены и четко определены, вы добились взаимной исключительности. Если все аспекты следуют один за другим и разобран каждый из них, значит, ваши пункты совместно исчерпывающие. Подробнее о применении этого принципа в кейсах можно прочитать на Preplounge www.preplounge.com/en/bootcamp.php/case-cracking-toolbox/mece-principle. О том, как эта техника применяется в McKinsey, хорошо рассказано в книге Итана Расиела «Метод McKinsey».

Во-вторых, постоянно проверяйте верность своих вычислений ― намного проще исправить свою ошибку во время решения, чем на этапе итоговой проверки. При этом соблюдайте компромисс между точностью расчетов и их практичностью. Без округлений больших чисел не обойтись, но никогда не округляйте их более чем на 10%. Если это возможно, лучше округлять одни числа в большую сторону, а другие в меньшую, чтобы сгладить тем самым неточности. Для того, чтобы не путать цифры и факты, нужно обязательно иметь широкий кругозор. Мировая статистика меняется ежесекундно ― никогда нельзя точно знать, сколько людей проживает в мире, сколько индийских девушек делают аборты, сколько телевизоров продано за день, сколько гектаров леса вырублено, сколько сигарет выкурено и так далее. Самые точные цифры в абсолютно разных сферах жизни можно найти здесь >> www.worldometers.info

И самое важное: всегда выстраивайте так называемое «логическое дерево» (Issue Tree). Issue Tree убивает сразу двух зайцев ― вы структурируете решение, упрощая тем самым свои вычисления, и наглядно демонстрируете ход своих мыслей интервьюеру. Решение следует начинать с конца ― с конкретного числа, которое должно получиться в итоге. Затем переходите ко второму шагу и укажите пару составляющих, которые требуются для вычисления конечного результата. После этого вы разложите каждую из этих частей на простые элементы ― но только после того, как интервьюер понял логику ваших вычислений. И так далее, пока не дойдете до уже известных вам данных. Главное ― не усложнить себе решение. Иногда прийти к конечному результату можно в меньшее количество шагов, чем представляется на первый взгляд. Например: нужно посчитать число детей, которые рождаются в мире за год. Можно сложить эти показатели для развитых и развивающихся стран. Но если примерное число детей, которые рождаются у женщин в разных странах за всю их жизнь, мы прикинуть можем, то оценить количество женщин будет гораздо сложнее ― в каких-то государствах их будет примерно половина всего населения, в каких-то (ну например, в Индии и Китае) их будет заметно меньше. И, конечно, еще больше ошибок возникнет при попытке прикинуть количество женщин в детородном возрасте.
Такой ход мысли может привести к провалу всего решения. Поэтому нужно тщательно выбирать, на какие элементы раскладывать решение задачи. В данном случае чтобы получить число детей, рождающихся в мире ежегодно, намного проще разделить общее население земли (7,3 млрд.) на среднюю продолжительность жизни (около 70 лет), допуская в начале своего решения, что численность населения не меняется. В итоге получается примерно 104 млн. человек в год. Далее вспоминаем, что население все-таки растет и растет примерно на 1% с каждым годом, то есть в следующем году оно будет примерно 7,37 млрд. человек. Учитывая смертность населения, делаем вывод, что если при постоянной численности населения рождаемость равна смертности, то для роста в 1% должна быть разница в 70 млн. человек в год. Следовательно, наш ответ ― в мире рождается 170 млн. людей ежегодно.

Сценарий использования — Википедия

Сценарий использования, вариант использования, прецедент использования (англ. use case) — в разработке программного обеспечения и системном проектировании это описание поведения системы, когда она взаимодействует с кем-то (или чем-то) из внешней среды. Система может отвечать на внешние запросы Актора (англ. actor, в русском языке ударение на первый слог) (может применяться термин Актант^[1]), может сама выступать инициатором взаимодействия. Другими словами, сценарий использования описывает, «кто» и «что» может сделать с рассматриваемой системой, или что система может сделать с «кем» или «чем». Методика сценариев использования применяется для выявления требований к поведению системы, известных также как пользовательские и функциональные требования.

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

В 1986 году Ивар Якобсон, позже соавтор Унифицированного Языка Моделирования (UML) и Рационального Унифицированного Процесса (RUP), впервые сформулировал методику визуального моделирования для описания сценариев использования. Первоначально он использовал несколько иные термины — англ. usage scenarios и usage case, но ни один из них не был естественным для английского языка. И в конечном счете он остановился на термине use case — сценарий использования. После создания Якобсоном методики моделирования сценариев использования многие специалисты в области инженерии ПО поспособствовали улучшению этой методики, включая Курта Биттнера, Алистера Коберна, Ганнэра Овергарда, и Джери Шнайдера.

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

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

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

Сценарий использования определяет взаимодействия между внешними агентами и системой, направленные на достижение цели. Актор (англ. Actor) представляет собой роль, которую играет человек или вещь, взаимодействуя с системой. Тот же самый человек, использующий систему, может быть представлен как различные акторы, потому что они играют различные роли. Например, «Джек» может играть роль Клиента, использующего Банкомат, чтобы забрать наличные деньги, или играть роль Работника Банка, использующего систему для пополнения банкомата купюрами.

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

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

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

Сценарий использования должен:

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

Алистер Коберн в книге «Написание эффективных сценариев использования» выделил три уровня детализации сценариев использования:

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

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

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

Рациональный Унифицированный Процесс (RUP) стимулирует разработчиков использовать краткое описание сценариев использования в диаграмме прецедентов с обычным уровнем детализации в виде комментария и детальным описанием в текстовом анализе. Сценарии могут быть задокументированы с помощью специальных инструментов (например, UML Tool, SysML Tool), или написаны в обычном текстовом редакторе.

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

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

К сценариям использования в UML применимы следующие виды отношений:

• Ассоциация (англ. Association) — может указывать на то, что актор инициирует соответствующий вариант использования.

В том числе между прецедентами:

• Расширение (англ. Extend) — разновидность отношения зависимости между базовым вариантом использования и его специальным случаем.
• Включение (англ. Include) — определяет взаимосвязь базового варианта использования с другим вариантом использования, функциональное поведение которого всегда задействуется базовым вариантом использования.
• Обобщение (англ. Generalization, наследование) — моделирует соответствующую общность ролей.

Сценарии использования и процесс разработки[править | править код]

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

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

Имя сценария

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

Цель

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

Акторы (действующее лицо)

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

Заинтересованные лица (Стейкхолдеры)

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

Предварительные условия

Стоит определить все условия, которые должны быть истиной (то есть, описать состояние системы) при которых исполнение сценария имеет смысл. Таким образом, если система не находится в состоянии, описанном в предварительных условиях, поведение сценария неопределенно. Заметьте так же, что предварительные условия это не «активаторы» (см. ниже). Так как верные предварительные условия НЕ инициируют выполнение сценария.

Активаторы

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

Есть несколько вариантов как описать ситуацию, когда активация происходит, но предварительные условия не удовлетворены.

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

Порядок Событий

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

Альтернативные пути и дополнения

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

Бизнес-правила

Бизнес-правила — способ задания логики системы для определения результата в зависимости от конкретного запроса к системе (например, входных данных). Правила описывают логику типа: «Если на входе такие данные, то система реагирует вот так». Они могут касаться одного сценария использования, применяться ко всем сценариям или ко всему бизнесу. Сценарии использования должны ясно ссылаться на бизнес-правила, которые для них применимы и используются.

Ограничения сценариев использования[править | править код]

• Сценарии использования плохо подходят для документирования требований, не основанных на взаимодействии с системой (таких как алгоритм или математические требования), или нефункциональных требований (такие как платформа, производительность, синхронизация, безопасность).
• Следование шаблонам не гарантирует качество сценариев. Качество зависит только от навыков создателя сценария.
• Есть кривая обучения правильному пониманию сценариев использования, как для конечных пользователей так и для разработчиков. Так как нет никаких полностью стандартных определений сценариев, каждая группа должна постепенно развивать свою собственную интерпретацию.
• Сторонники Экстремального программирования часто считают сценарии использования слишком формальными документами, предпочитая использовать более простой подход пользовательских историй.
• Создателям сценариев часто сложно определить на каком уровне следует описывать пользовательский интерфейс (UI). Хоть теория сценариев использования и предлагает, чтобы пользовательские интерфейсы не описывались в сценариях, часто достаточно трудно описать сценарий не затрагивая описания пользовательского интерфейса.
• Важность сценариев использования может быть переоценена. В книге «Object Oriented Software Construction» (2-й выпуск), Бертран Мейер обсуждает проблемы, такие как проектирование системы только по сценариям использования исключая другие потенциально ценные методики анализа требований.
• Сценарии использования получили некоторый интерес как отправная точка для тест дизайна. Определенная литература по сценариям использования, однако, утверждает что предварительные и результирующие условия, описанные в сценарии, должны применяться ко всему сценарию (то есть, ко всем возможным путям развития сценария). Это ограничивает пользу сценариев с точки зрения тест дизайна. Если результирующие условия сценария использования являются достаточно общими, чтобы быть правильными для всех вариантов развития событий, они вероятно бесполезны как основа для определения ожидаемого поведения системы в тест дизайне. Например, результирующие условия неудавшейся попытки снять наличные деньги из банкомата отличаются от результирующих условий после успешной операции. Если результирующие условия отразят этот факт, то они также будут отличаться. Если результирующие условия не отражают этого, то они не могут использоваться для определения ожидаемого поведения тестов.

Адаптивный кейс-менеджмент — Википедия

Адаптивный кейс-менеджмент ACM (англ. Adaptive Case Management, Dynamic Case Management, Advanced Case Management) — концепция динамического управления бизнес-процессами предприятия.

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

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

«BPMs vs. ACM» — противопоставление или интеграция?[править | править код]

ACM — это часть BPM или самостоятельная концепция? В Интернете и в ИТ-изданиях можно наблюдать 2 основные тенденции среди экспертов.

Одни эксперты считают, что ACM это «Pidgin-BPM», примитивная версия BPM, решающая те же проблемы, что и BPM. «Серьезные специалисты», отдавшие годы BPMN, BPEL etc., принять такую концепцию ACM не готовы, максимум, на что они вынуждены идти — это считать ACM опцией, дополнительным «бантиком» к BPM. Однако именно практическим внедренцам известно, что реальные системы BPM имеют вполне реальные проблемы с целостностью, под которой в данном случае понимаются возможности для удовлетворения всей полноты требований заказчика по автоматизации бизнес-процессов.

Естественно, поставщики давно видят наличие недостатков у «традиционных» BPM систем. Изобретаются различные возможности добавлять в экземпляр бизнес-процесса в режиме реального времени ad-hoc activity, появляются расширения BPEL для учета коллективного взаимодействия, такие как BPEL4People. Однако эти возможности обладают общими недостатками BPM в сравнении с ACM — требуют сложных настроек (а в ACM их минимум), в них затруднены средства контроля доступа, адресации и фильтрации таких ad-hoc activities, нет средств загрузки файлов, фотографий пользователей, средств для ведения дискуссий — все это элементарные средства, которые обязаны быть в любой ACM.

Результатом этой точки зрения является противопоставление ACM и BPM.

Другие эксперты считают, что ACM это collaborative BPM, social BPM, agile BPM, в которой следующий шаг процесса определяется в социальной среде решением человека. А этот как раз то «недостающее звено», чего не хватает традиционному BPM и почему изобретаются BPEL4People etc. В такой интерпретации ACM это как раз то, чего жаждет BPM, можно сказать, без чего BPM не сможет развиваться, чтобы наконец стать эффективным инструментом. И интеграция BPM и ACM в этом случае расширяет сферу применения BPM, делает системы BPM более привлекательными и эффективными. И те вендоры и интеграторы BPM, кто начинает интегрироваться с ACM, получают конкретные конкурентные преимущества.

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

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

• Система ACM — инструмент формирования корпоративных знаний

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

• Система ACM предоставляет возможность накопления корпоративных знаний для их повторного использования

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

• Адаптивность и гибкость ACM позволяет автоматизировать бизнес-процессы предприятия «как есть» (англ. as is), в привычном для сотрудников виде, не подвергая риску процесс внедрения, не подвергая стрессу персонал, не ломая существующих бизнес-процессов для достижения теоретически правильного состояния «как должно быть» (англ. to be). После внедрения ACM бизнес-процессы становятся прозрачными, появляется возможность совершенствовать их на деле, а не на бумаге — легко меняя и улучшая шаблоны кейсов. Новые кейсы формируются самими пользователями как списки задач, которые требуется выполнить, и корректируются и дополняются по ходу выполнения процесса. ACM ориентирован на результат, а процесс его достижения уточняется по ходу дела. И, хотя достижение результата ACM не гарантирует (это могут делать только люди), зато ACM контролирует процессы, показывая в любой момент времени все неисполненные задачи, ответственных за них сотрудников и всю переписку на тему «кто виноват и что делать».

• Простота и социальность системы ACM позволяют автоматизировать текущие процессы предприятия без детального обследования бизнес-процессов и трудоемкой настройки и программирования

Вместо сложных описаний бизнес-процессов ACM крутится фактически вокруг чек-листов, представляющих собой список из задач, которые необходимо выполнить и чек-пойнтов или milestones (контрольных точек), задач, которые необходимо выполнить. Для ACM такой чек-лист из контрольных точек — это то же самое, что для «традиционного» BPM «happy path» — основной перечень действий, которые надо сделать и представление о которых имеется перед началом процесса. В ACM этот перечень по мере исполнения процесса корректируется и дополняется.

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

Система ACM позволяет:

• Управлять кейсами — наборами задач и поручений, связанных с исполнением целого бизнес-процесса. Кейсы — последовательности сообщений, содержащие описания проблем, поручения, дискуссии пользователей, списки адресатов или исполнителей, файлы, формы данных, бизнес-правила.
• Хранить в виртуальной папке кейса всю информацию о бизнес-процессе — все документы, фотографии, видеоролики, чертежи и другие файлы.
• Управлять пользователями, входящими в проектную команду кейса, предоставлять или, наоборот, ограничивать доступ к задачам, файлам и сообщениям кейса, уведомлять пользователей о необходимости начать работу по новой задаче проекта.
• Поддерживать управление правилами, позволяющими автоматически активизировать следующие задачи кейса после закрытия предыдущих, отправлять пользователям уведомления и т. п.
• Вести журнал всех действий пользователя с поручениями/сообщениями (когда поручение/сообщение создается, редактируется и изменяется его статус).
• Поддерживать корпоративные дискуссионные форумы по различным темам и проектам.
• Поддерживать ведение библиотеки шаблонов, куда можно одним кликом сбрасывать успешно завершенные кейсы, чтобы потом также одним кликом создавать по шаблону целый кейс на любую тему, уже содержащий все задачи, всех исполнителей, все образцы документов и другие файлы.
• Представлять списки задач в кейсах как «чек-листы» — перечни задач, в которых галочками отмечаются исполненные и пиктограммами указаны все текущие статусы задач и поручений.
• Осуществлять согласование, рецензирование и утверждение документов или интегрироваться с системами электронного документооборота (СЭД).
• Формировать сложноподчиненные бизнес процессы в виде понятных пошаговых инструкций к исполнению.

Профессиональные общественные организации, занимающиеся проблемами ACM[править | править код]