Метод сценариев

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

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

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

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

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

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

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

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

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

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

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

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

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

В настоящее время известны различные реализации метода

сценариев такие, как:

— получение согласованного мнения,

— повторяющаяся процедура независимых сценариев,

— использование матриц взаимодействия и др.

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

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

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

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

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

Метод матриц взаимовлияний, разработанный Гордоном и Хелмером, предполагает определение на основании экспертных оценок потенциального взаимовлияния событий рассматриваемой совокупности.

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

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

Состояние системы в момент времени t является точкой S(t) в этом пространстве параметров. Определение возможных тенденции развития ситуации позволяет определить вероятное направление эволюции положения системы в пространстве выявленных параметров S(t) в различные моменты времени в будущем S(t+l), S(t+2) и т.д.

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

Управляющие воздействия эквивалентны воздействию сил, способных изменить направление траектории S(t).

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

Предлагаемая технология разработки сценариев предполагает рассмотрение положения системы в дискретные моменты времени t,t+l,t+2, … .

При этом предполагается, что точка, соответствующая системе S(t) в пространстве параметров расположенным в конусе, расширяющемся при удалении от исходного момента времени t. В некоторый момент времени t+T ожидается, что система будет

расположена в сечении конуса, соответствующем моменту времени

t+T.

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

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

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

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

измениться.

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

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

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

ситуации и основных закономерностей и особенностей ее развития. Заслуживает внимания разновидность метода сценариев, предложенная Абтом, Фостером и Ри.

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

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

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

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

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

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

сценариев. Группируя сценарии в классы можно определить рациональную

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

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

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

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

Впервые термин «сценарий» был употреблен в 1960г. футурологом X. Каном при разработке картин будущего, необходимых для решения стратегических вопросов в военной области.

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

• оптимистический;

• пессимистический;

• средний (наиболее вероятный, ожидаемый).

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

• технологии;

• рыночных сегментов;

• стран или регионов и т.д.

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

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

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

• экономико-математические;

• моделирование;

• анализ перекрестного влияния;

• корреляционный анализ и т.д.

Составление сценария обычно включает в себя несколько этапов.

Первый этап. Структурирование и формулировка вопроса.

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

Необходимо осветить структурные характеристики и внутренние проблемы проекта.

Второй этап. Определение и группировка сфер влияния.

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

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

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

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

Для сфер, развитие которых может включать несколько вариантов, будущее состояние должно быть описано при помощи нескольких альтернативных показателей (например, фирму устраивает, чтобы численность населения в регионе увеличилась на 2,3 или 5%).

Четвертый этап. Формирование и отбор согласующихся наборов предположений.

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

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

• высокая сочетаемость предположений, входящих в набор;

• наличие большого числа значимых переменных;

• высокая вероятность событий, относящихся к набору пред­
положений.

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

На этом этапе сопоставляются результаты третьего и четвертого

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

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

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

Шестой этап. Введение в анализ разрушительных событий.

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

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

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

Седьмой этап. Установление последствий.

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

Восьмой этап. Принятие мер.

В узком смысле этот этап уже не относится к анализу. Однако он естественно вытекает из предыдущих этапов.

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

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

согласование мнении экспертов.

6.Для метода »мозговых атак» характерны:

•коллективная генерация идей

•творческое решение проблем.

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

7. Метод Делъфи был разработан известным экспертом из ис­следовательской корпорации «РЭНД» Олафом Хельмером, математиком по образованию. Может быть, поэтому в методе Дельфи сочетаются творческий подход к решению проблемы и достаточная точность прогноза.

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

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

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

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


В предыдущих статьях мы уже не раз затрагивали проблематику мониторинга, сбора и
хранения метрик (см., например, и ). Сегодня мы хотели бы снова вернуться к этой теме и рассказать о необычном, но весьма интересном инструменте — Riemann.
По сравнению с другими системами мониторинга он отличается повышенной сложностью,
и в то же время — гораздо большей гибкостью и отказоуcтойчивостью. На просторах Интернета нам доводилось встречать публикации, где Riemann характеризуют как «самую гибкую систему мониторинга в мире». Riemann хорошо подходит для сбора информации о работе сложных высоконагруженных систем в реальном масштабе времени.
Собственно говоря, системой мониторинга в строгом смысле Riemann не является. Правильнее было бы его называть инструментом обработки событий (event processor).
Он собирает информацию о событиях с хостов и приложений, объединяет события в поток и передаёт их другим приложениям для дальнейшей обработки или хранения. Также Riemann отслеживает состояние событий, что позволяет создавать проверки и рассылать уведомления.
Riemann распространяется бесплатно по лицензии Eclipse. Большая часть кода написана Кайлом Кингсбери, известном также под псевдонимом Aphyr (кстати, рекомендуем почитать его блог: там часто бывают интересные материалы).

Обработка событий в реальном масштабе времени

Рост интереса к проблематике мониторинга, сбора, хранение и анализа метрик, который мы наблюдаем в последнее время, вполне объясним: вычислительные системы становятся всё более сложными и более высоконагруженными. В случае с высоконагруженными системами особую важность приобретает возможность отслеживания событий в реальном масштабе времени. Собственно, Riemann и был создан для того, чтобы решить эту проблему.
Идея обработки событий в режиме, приближенном к реальному времени не нова: первые попытки её осуществления предпринимались ещё в конце 1980-х годов. В качестве примера можно назвать так называемые Active Database Systems (активные системы баз данных), которые выполняли определённый набор инструкций, если поступающие в базу данные соответствовали заданному набору условий.
В 1990-х годах появились системы управления потоками данных (Data Stream Management Systems), которые уже могли обрабатывать поступающие данные в реальном масштабе времени, и системы обработки сложных событий (Complex Event Processing, сокращённо CEP). Такие системы могли как обнаруживать события на основе внешних данных и заложенной внутренней логики, так и осуществлять определённые аналитические операции (например, подсчитывать количество событий за определённые период времени).
Примерами современных инструментов обработки сложных событий могут служить, в частности, Storm (см. также статью о нём на русском языке) и Esper. Они ориентированы на обработку данных без хранения. Riemann — продукт такого же класса. В отличии от того же Storm он гораздо более прост и логичен: вcя логика обработки событий может быть описана всего лишь в одном конфигурационном файле.
Многих системных администраторов-практиков эта особенность может и отпугнуть: конфигурационный файл по сути представляет собой код на языке Clojure, но котором написан и Riemann.
Clojure относится к функциональным (а говоря ещё точнее — лиспообразным) языкам программирования, что само по себе уже настораживает. Однако в этом нет ничего страшного: при всём своём своеобразии Clojure не так сложен, как кажется на первый взгляд. Рассмотрим его особенности более подробно.

Немного о Clojure

Clojure представляет собой функциональный язык, созданный на базе LISP. Программы, написанные на Clojure, работают на платфоре JVM. Первая версия этого языка появилась в 2007 году. Совсем недавно вышла в свет последняя на сегодняшний день версия — 1.8.0.
Clojure используется в проектах таких компаний, как Facebook, Spotify, SoundCloud, Amazon и других (полный список см. на официальном сайте).
В отличие от других реализаций LISP для JVM (например, ABCL или Kawa), Clojure не совместим полностью ни с Common Lisp, ни со Scheme, однако из этих языков в нём очень много позаимствовано. Есть в Clojure и некоторые усовершенствования, которых нет в других современных диалектах LISP: неизменность данных, конкуретное выполнение кода и т.п.
Так как Clojure был изначально спроектирован для работы с JVM, в нём можно работать с многочисленными библиотеками, существующими для этой платформы. Взаимодействие с Java реализовано в обе стороны. можно вызывать код, написанный для Java. Возможна также реализация классов, доступных для вызова из Java и других языков программирования, работающих на базе JVM — например, для Scala. Более подробно о Clojure и его возможностях можно прочитать в этой статье, а также на официальном сайте Riemann. Рекомендуем также ознакомиться ещё с одним кратким, но весьма информативным введением в Clojure.

Установка и первый запуск

Чтобы работать с Riemann, нам сначала понадобится установить все необходимые
зависимости: Java и Ruby (на нём написаны некоторые дополнительные компоненты, о которых речь ещё пойдёт ниже):
$ sudo apt-get -y install default-jre ruby-dev build-essential
Далее загрузим и установим последнюю версию Riemann:
$ wget https://aphyr.com/riemann/riemann-0.2.10_all.deb $ dpkg -i riemann-0.2.10_all.deb
Далее выполним:
$ sudo service riemann start
Для полноценной работы нам понадобиться также установить написанные на Ruby компоненты для сбора и метрик:
$ gem install riemann-client riemann-tools
Вот и всё. Для начала работы с Riemann всё готово. Прежде чем перейти к практической части, сделаем небольшое теоретическое отступление и проясним смысл важнейших понятий: события, потоки и индекс.

События, потоки и индекс

Базовым понятием в Riemann является событие. События можно обрабатывать, подсчитывать, собирать и экспортировать в другие программы. Событие может выглядеть, например, так:
{:host riemann, :service riemann streams rate, :state ok, :description nil, :metric 0.0, :tags , :time 355740372471/250, :ttl 20}
Приведённое событие состоит из следующих полей:

  • :host — имя хоста;
  • :service — имя наблюдаемого сервиса;
  • :state — состояние события (ok, warning, critical);
  • :tags — метки события;
  • :time — время наступления события в формате Unix Timestamp;
  • :description — описание события в произвольной форме;
  • :metric — метрика, ассоциированная с событием;
  • :ttl — время актуальности события (в секундах).

Некоторые события могут также иметь кастомные поля, которые можно добавлять ак во время создания, так и во время обработки событий (например, поля с дополнительными метриками).
Все события объединяются в потоки. Поток — это функция, которой может быть передано событие.
Вы можете создать неограниченно количество потоков. События проходят через потоки, но не сохраняются в них. Однако очень часто возникает необходимость отслеживать состояние событий — например, утратили они актуальность или нет. Для этого используется индекс — таблица состояний отслеживаемых событий. В индексе события сортируются по группам по хосту и по сервису, например:
:host www, :service apache connections, :state nil, :description nil, :metric 100.0, :tags , :time 466741572492, :ttl 20
Это событие, произошедшее на хосте www в сервисе apache connections. В индексе всегда хранится последнее на текущий момент событие. К индексам можно обращаться из потоков и даже из внешних сервисов.
Мы уже видели, что каждое событие содержит поле TTL (time to live). TTL — это промежуток времени, в течение которого событие является актуальным. В только что приведённом примере TTL события составляет 20 секунд. В индекс попадают все события с параметрами :host www и :service apache connections. Если в течение 20 секунд таких событий не происходит, будет создано новое событие со значением expired в поле state. Затем оно будет добавлено в поток.

Конфигурирование

Перейдём от теории к практике и займёмся конфигурированием Riemann. Откроем конфигурационный /etc/riemann/riemann.config. Он представляет собой программу на Clojure и по умолчанию выглядит так:
; -*- mode: clojure; -*- ; vim: filetype=clojure (logging/init {:file «/var/log/riemann/riemann.log»}) ; Listen on the local interface over TCP (5555), UDP (5555), and websockets ; (5556) (let (tcp-server {:host host}) (udp-server {:host host}) (ws-server {:host host})) ; Expire old events from the index every 5 seconds. (periodically-expire 5) (let ; Inbound events will be passed to these streams: (streams (default :ttl 60 ; Index all events immediately. index ; Log expired events. (expired (fn (info «expired» event))))))
Этот файл разделён на несколько разделов. Каждый раздел начинается с комментария, обозначаемого, как это принято в Clojure, точкой с запятой (;).
В первом разделе указан файл, в который будут записываться логи. Далее идёт раздел с указанием интерфейсов. Обычно Riemann слушает на TCP-, UDP- и вебсокет-интерфейсе. По умолчанию все они привязаны к локальному хосту (127.0.0.1).
Следующий раздел содержит настройки для событий и индекса:
(periodically-expire 5) (let ; Inbound events will be passed to these streams: (streams (default :ttl 60 ; Index all events immediately. index
Первая функция (periodically-expire) убирает из индекса все события, у которых истёк период актуальности, и присваивает им статус expired. Очистка событий запускается каждые 5 секунд.
По умолчанию Riemann копирует в события с истёкшим сроком актуальности поля :service и :host. Можно с копировать и другие поля; для этого нужно с функцией periodically-expired использовать опцию :key-keys. Вот так, например, мы можем дать указание сохранять не только имя хоста и имя сервиса, но ещё и тэги:
(periodically-expire 5 {:keep-keys })
Далее следует конструкция, в которой мы определяем символ с именем index. Значение этого символа — index, т.е. это функция, которая отправляет события в индекс. Она используется, чтобы указать Riemann, когда индексировать то или иное событие.
С помощью функции streams мы описываем потоки. Каждый поток представляет собой функцию, принимающую в качестве аргумента событие. Функция streams указывает Riemann: «вот список функций, которые нужно вызывать при добавлении новых событий». Внутри этой функции мы устанавливаем TTL для событий — 60 секунд. Для этого мы воспользовались функцией default, которая берёт поле из события и позволяет установить для него значение по умолчанию. События, у которых нет TTL, будет получать статус expired.
Затем дефолтная конфигурация вызывает символ index. Это означает, что все поступающие события будут добавляться в индекс автоматически.
Заключительный раздел содержит указание логгировать события со статусом expired:
; Log expired events. (expired (fn (info «expired» event))))))
Внесём в конфигурационный файл некоторые изменения. В разделе, посвящённом сетевым интерфейсам, заменим 127.0.0.1 на 0.0.0.0, чтобы Riemann мог принимать события с любого хоста.
В самый конец файла добавим:
;print events to the log (streams prn #(info %))
Это функция prn, которая будет записывать события в логи и в стандартный вывод. После этого сохраним внесённые изменения и перезапустим Riemann.
В ситуации, когда приходится отслеживать работу множества сервера, можно создавать не общий конфигурационный файл, а целую директорию с отдельными файлами для каждого сервера или группы серверов (см. рекомендации в этой статье).
С подробной инструкцией по написанию конфигурационного файла можно познакомиться .

Отправка данных в Riemann

Попробуем теперь отправить данные в Riemann. Воспользуемся для этого клиентом riemann-health, который входит в уже установленный нами ранее пакет riemann-tools. Откроем ещё одну вкладку терминала и выполним:
$ riemann-health
Эта команда передаёт Riemann данные о состоянии хоста (загрузка CPU, объём занятого дискового пространства, объём используемой памяти).
Riemann начнёт принимать события. Информация об этих событиях будет записываться в файл /var/log/riemann/riemann.log. Она представлена в следующем виде:
#riemann.codec.Event{:host «cs25706», :service «disk /», :state «ok», :description «8% used», :metric 0.08, :tags nil, :time 1456470139, :ttl 10.0} INFO defaultEventExecutorGroup-2-1 — riemann.config — #riemann.codec.Event{:host cs25706, :service disk /, :state ok, :description 8% used, :metric 0.08, :tags nil, :time 1456470139, :ttl 10.0} #riemann.codec.Event{:host «cs25706», :service «load», :state «ok», :description «1-minute load average/core is 0.02», :metric 0.02, :tags nil, :time 1456470139, :ttl 10.0}
Riemann-health — это лишь одна из утилит в пакете riemann-tools. В него входит довольно большое количество утилит для сбора метрик: riemann-net (для мониторинга сетевых интерфейсов), riemann-diskstats (для мониторинга подсистемы ввода-вывода), riemann-proc (для мониторинга процессов в Linux) и другие. С полным списком утилит можно ознакомиться .

Создаём первую проверку

Итак, Riemann установлен и запущен. Попробуем теперь создать первую проверку. Откроем конфигурационный файл и добавим в него такие строки:
(let (streams (default :ttl 60 index ;#(info %) (where (and (service «disk /») (> metric 0.10)) #(info «Disk space on / is over 10%!» %))
Перед функцией (#info) стоит знак комментария — точка с запятой (;). Это сделано, чтобы Riemann не записывал каждое событие в лог. Далее мы описываем поток where. В него попадают события, которые соответствуют заданному критерию. В нашем примере таких критериев два:

  • поле :service должно иметь значение disk /;
  • значение поля :metric должно быть больше 0.10 или 10%.

Затем они передаются в дочерний поток для дальнейшей обработки. В нашем случае информация о таких событиях будет записываться в файл /var/log/riemann/riemann.log.

Фильтрация: краткая справка

Без фильтрации событий полноценная работа c Riemann невозможна, поэтому о ней стоит сказать несколько слов отдельно.
Начнём с фильтрации событий с помощью регулярных выражений. Рассмотрим следующий пример описания потока where:
where (service #”^nginx”))
В Clojure регулярные выражения обозначаются знаком # и заключаются в двойные кавычки. В нашем примере в поток where будут попадать выражения, у которые содержат имя nginx в поле :service.
События в потоке where можно объединять с помощью логических операторов:
(where (and (tagged «www») (state «ok»)))
В этом примере в поток where будут попадать события с тэгом www и значением ok в поле state. Они объединяются с событиями из потока tagged.
Tagged — это сокращённое имя функции tagged-all, которая объединяет все события с заданными тэгами. Еcть ещё функция tagged-any — она объединяет в поток события, отмеченные одним или несколькими из указанных тэгов:
(tagged-any #(info %))
В нашем примере в поток tagged попадут события, отмеченные тэгами www и app1.

По отношению к событиям можно выполнять математические операции, например:
(where (and (tagged «www») (>= (* metric 10) 5)))
В этом примере будут события будут попадать события с тэгом www, у которых значение поля :metric, умноженное на 10, будет больше 5.
Аналогичный синтаксис можно использовать, чтобы выбирать события, у которых значения в поле :metric попадают в указанный диапазон:
(where (and (tagged «www») (< 5 metric 10)))
В приведённом примере в поток where будут попадать события с тэгом www, у которых значение поля :metric находится в диапазоне 5 —10.

Настройка уведомлений

Riemann может рассылать уведомления в случае соответствия заданным условиям проверок. Начнём с настройки уведомлений по электронной почте. В Riemann для этого используется функция email:
; Inbound events will be passed to these streams: (streams (default :ttl 60 ; Index all events immediately. index (changed-state {:init «ok»} (email «andrei@example.com»)))))
Рассылки уведомлений в Riemann осуществляется на базе специальной библиотеки на Clojure — Postal. По умолчанию для рассылки используется локальный почтовый сервер.
Все сообщения будут отправляться с адреса вида riemann@example.com.
Если локальный почтовый сервер не установлен, Riemann будет выдавать сообщения об ошибке вида:
riemann.email$mailer$make_stream threw java.lang.NullPointerException
В приведённом выше примере кода мы использовали ярлык changed-state и тем самым указали, что Riemann должен отслеживать события, состояние которых изменилось. Значение переменной init сообщает Riemann, каким было начальное состояние события. Все события, состояние которых изменилось с ok на какое-либо другое, будут передаваться функции email. Информация о таких событиях будет отправлена на указанный адрес электронной почты.
С более подробными примерами настройки уведомлений можно ознакомиться в статье Джеймса Тернбулла, одного из разработчиков Riemann.

Визуализация метрик: riemann-dash

В Riemann имеется собственный инструмент для визуализации метрик и построения простых дашбордов — riemann-dash. Установить его можно так:
$ git clone git://github.com/aphyr/riemann-dash.git $ cd riemann-dash $ bundle
Запускается riemann-dash с помощью команды:
$ riemann-dash
Домашняя страница riemann-dash доступна в браузере по адресу :4567:

Подведём к чёрной надписи Riemann в самом центре, нажмём клавишу Ctrl (на Mac — cmd) и кликнем по ней. Надпись будет выделена серым цветом. После этого нажмём на клавишу E, чтобы приступить к редактированию:

В выпадающем меню title выберем пункт Grid, а в поле query напишем true:

Установив необходимые настройки, нажмём на кнопку Apply:

Дашборд получается не особо эстетичный и удобный, но вполне наглядный. Неудобство, однако, компенсируется тем, что с Riemann можно использовать сторонние инструменты визуализации, d в частости Graphite и Grafana — заитересованный читатель без труда сможет найти соответствующие публикации в Интернете. А процедуру настройки связки Riemann+InfluxDB+Grafana мы опишем в следующем разделе.

Отправка данных в InfluxDB

Несомненным преимуществом Riemann являются широкие возможности интеграции. Собранные с его помощью метрики можно отправлять в сторонние хранилища. Ниже мы покажем, как интегрировать Riemann c InfluxDB и настроить визуализацию данных с помощью Grafana.
Установим InfluxDB:
$ wget https://s3.amazonaws.com/influxdb/influxdb_0.9.6.1_amd64.deb $ sudo dpkg -i influxdb_0.9.6.1_amd64.deb
О конфигурированиии InfluxDB можно подробнее почитать в официальной документации, а также в одной из наших предыдущих статей.
По завершении установки выполним команду:
$ sudo /etc/init.d/influxdb start
Затем создадим базу для хранения данных из Riemann:
$ sudo influx >CREATE DATABASE riemann
Создадим для этой базы пользователя и установим для него пароль:
>CREATE USER riemann WITH PASSWORD ‘пароль пользователя riemann’ >GRANT ALL ON riemann TO riemann
Вот и всё, установка и базовая настройка InfluxDB завершены. Теперь нужно прописать необходимые настройки в конфигурационном файле Riemann (код взят отсюда и незначительно модифицирован):
; -*- mode: clojure; -*- ; vim: filetype=clojure ;подключаем capacitor, клиент для работы с InfluxDB (require ‘capacitor.core) (require ‘capacitor.async) (require ‘clojure.core.async) (defn make-async-influxdb-client (let (capacitor.async/run! events-in resp-out client 100 10000) (fn (let (clojure.core.async/put! events-in p))))) (def influx (make-async-influxdb-client { :host «localhost» :port 8086 :username «riemann» :password «пароль пользователя riemann» :db «riemann» })) (logging/init {:file «/var/log/riemann/riemann.log»}) (let (tcp-server {:host host}) (udp-server {:host host}) (ws-server {:host host})) (periodically-expire 60) (let (streams index (fn (let (influx series { :time (:time event) :value (:metric event) })))))
Сохраним внесённые изменения и перезапустим Riemann.
После этого установим Grafana:
$ wget https://grafanarel.s3.amazonaws.com/builds/grafana_2.6.0_amd64.deb $ sudo dpkg -i grafana_2.6.0_amd64.deb
Подробных инструкций по настройке Grafana мы приводить не будем, да в этом и нет особой необходимости: соответствующие публикации можно без труда найти в Интернете.
Домашняя страница Grafana будет доступна в браузере по адресу http://:3000. Далее потребуется лишь добавить новый источник данных (InfluxDB) и создать дашборд.

В этой статье мы представили краткий обзор возможностей Riemann. Мы затронули следующие темы:

  • особенности языка Clojure;
  • установка и первичная настройка Riemann;
  • структура конфигурационного файла и особенности его синтаксиса;
  • создание проверок;
  • настройка уведомлений;
  • визуализация метрик с помощью riemann-dash
  • интеграция Riemann c InfluxDB и визуализация метрик с помощью Grafana

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

Изучаемое событие должно быть ясно идентифицировано, а дата объявления события указана точно. Предположение, лежащее в основе анализа событий, состоит в том, что дата события известна с приемлемой степенью определенности. Поскольку финансовые рынки реагируют на информацию о событии, а не на само событие, то большинство подходов к событийному анализу акцентируется на дате объявления события.  
ИЛЛЮСТРАЦИЯ 6.1. Пример событийного анализа — воздействие торгуемых на бирже опционов на цены акций  
Одной из самых мощных проверок наличия рыночной эффективности является событийный анализ, когда свидетельства неэффективности пытаются обнаружить при анализе реакции рынка на информационные события (такие, как объявления о доходах или слиянии). Хотя реакция рынка на новую информацию совместима с эффективностью рынка, она должна быть немедленной и непредвзятой. Это положение представлено на рисунке 6.5, где сравниваются три различные реакции рынка на обнародование информации.  
Поскольку фактические прибыли сравниваются с ожиданиями инвесторов, одним из ключевых моментов событийного анализа в отношении  
Хотя рыночную эффективность можно протестировать многими способами, два самых популярных теста на эффективность — это событийный анализ, когда изучается реакция рынка на информационные события, и портфельный анализ, когда исследуется доходность портфелей, созданных на основе наблюдаемых характеристик. Здесь необходимо проявлять бдительность, поскольку тем или иным способом в исследования — преднамеренно или нет — может вкрасться предвзятость и привести к необоснованным выводам или, что еще хуже, к бесполезным инвестиционным стратегиям.  
Вы тестируете влияние объявления о слиянии на цены акций (событийный анализ). Процедура тестирования состоит из следующих шагов.  
На основе 5—7 отобранных выдающихся результатов можно составить так называемый портрет успеха . По сути дела, портрет успеха является описанием наиболее удобной и выигрышной для вас победной стратегии деятельности. Для этого необходимо выписать из всех списков событий (составленных для каждого результата в рамках событийного анализа результата , см. выше) все виды деятельности (с указанием даты и времени выполнения), которые были запланированы ( пл/нп =1), максимально эффективны с точки зрения  
Первые три этапа анализа личной эффективности (полученные результаты, событийный анализ временного качества этих результатов, оптимальная стратегия деятельности) являются очень важной информацией. Но, чтобы свести все к общему знаменателю и перейти от аналитики к модификации системы ТМ на практике, рекомендуется провести стратегический анализ трат времени. В данном случае под стратегическим анализом понимается использование основных стратегий управления временем (см. раздел 2.1) как эвристических вопросов, помогающих изобрести более эффективные способы управления временем.  
Событийно-новостной анализ. В противоположность техническому анализу данный подход предполагает отслеживание информации, значимой для изменения поведения рынка. Чаще всего, это макроэкономические индикаторы здоровья , основополагающие высказывания важных политических фигур, сообщения о природных и техногенных катастрофах, крупных террористических актах и т.д.  
Событийно-новостной анализ — это выводы о наиболее вероятной реакции рынка в ответ на те или иные изменения макроэкономических, политических и иных индикаторов и показателей.  
Признавая эффективность рынка как сверхбыстрого преобразователя информации в соответствующий уровень цен, сторонники событийно-новостного анализа строят свой расчет на несовпадении ожиданий рынка и поступающей информации о реальном положении вещей. Как только возникает подобная ситуация, рынок немедленно начинает учитывать различие между ожиданиями и реальностью. Тем самым, у наиболее прозорливых и быстрых трейдеров появляется возможность делать свою игру .  
При событийно-новостном анализе не обязательно вникать в причинно-следственные связи поведения рынка и воздействующих на него факторов. Достаточно исходить из того, насколько оправдываются ожидания рынком тех или иных значимых событий.  
Отношение волнового принципа к событийно-новостному анализу более чем прохладное. И в этом отражается коренное отличие между этими подходами в понимании движущих сил рынка.  
Важнейший методологический принцип этого анализа состоит в том, что логика вывода здесь опирается не на историю повторяемости как таковую (что имеет место при традиционном техническом анализе) и не на внешнее фиксирование последовательности стимул-реакция (что характерно для событийно-новостного анализа). Соответствующие выводы базируются на научно-обоснованных представлениях о причинно-следственных связях между некими значимыми факторами, составляющими основу движущих сил на интересующем секторе рынка.  
Еще один, менее тривиальный, пример, дающий возможность выделения событийной составляющей динамики, приведен на рис. 2.9. Этот график иллюстрирует динамику урожайности зерновых хлебов в дореволюционной России с 1801 г. по 1915 г. В то время измеряли так называемый урожай/сам, т. е. отношение массы собранного урожая к массе использованного семенного материала. В первой половине рассматриваемого интервала времени динамика урожайности, в первом приближении, не демонстрировала тенденции роста или спада, тогда как во второй половине, после отменены крепостного права в 1861 г., явно просматривается тенденция роста. Если задача исследования предполагает анализ динамики урожайности вне связи с анализом каких-либо событий, например, если изучается влияние некоторого фактора, действовавшего на протяжении всего периода (скажем, солнечной активности, измеряемой числами Вольфа), то в качестве адекватной оценки векового тренда можно рассматривать оценку типа той, что показана на рис. 2.9, а. Если же задача состоит в анализе влияния на динамику урожайности какого-либо события, например, реформы 1861 г., то нарастающее отклонение от тенденции, существовавшей до 1861 г., должно быть отнесено на счет событийной составляющей динами-  
Возможность интенсивной эволюции сезонных волн приводит к тому, что иногда бывает невозможно корректно отделить эволюцию сезонной составляющей от изменений компоненты тренда и конъюнктуры и нерегулярной составляющей. Например, резкое падение добычи газа в середине 1993 г. (рис. 4.7,а) можно было объяснять и эволюцией сезонной волны, и изменением компоненты тренда и конъюнктуры, и выбросом. Дальнейшее развитие событий показало, что в данном случае имело место резкое изменение амплитуды сезонных колебаний, однако в первые месяцы после аномально глубокого падения добычи газа в середине 1993 г. определенную трактовку на основании анализа лишь информации, содержащейся в анализируемом временном ряде, дать было нельзя. Похожая ситуация сложилась и в середине 1997 г., однако в данном случае дальнейшее развитие событий показало, что здесь, напротив, едва ли можно было говорить об эволюции сезонной составляющей, скорее имело место временное снижение компоненты тренда и конъюнктуры (которое можно включить и в состав событийной составляющей динамики). На рис. 4.6-4.9 можно найти немало других подобных примеров потенциальной неоднозначности в трактовке динамики показателей.  
Одним из способов протестировать эти гипотезы является событийный анализ, посвященный влиянию, оказываемому зарегистрированными на бирже опционами на стоимость базовых акций. Конрад ( onrad, 1989) провел подобное исследование, следуя указанным ниже шагам.  
Ниже приводится гипотетический пример событийного анализа результата , занимающего четвертое место в списке важных достижений за учетный период. Полное время изготовления статьи — 10 дней, и вся цепочка, непосредственно ведущая кдостигнутому результату, состоит всего из 9 событий. Обратите внимание, что в столбце События перечислены только те события (виды деятельности), которые прямо повлияли на достижение результата. Косвенные события (вроде телефонного звонка 10.01, который можно было учесть как помеху) при этом не учитывались.  
Оценка использования возможностей самообслуживания клиентов включает анализ автоинформатора (голосовое меню или IVR) и Web-приложений для доступа клиентов. Событийный анализ имеющихся функций самообслуживания включает оценку структуры и дизайна, а также эффективности сценариев общения на основе анализа статистики обращений. Эффективность взаимодействия с клиентом по электронной почте и через Web-интерфейс оценивается сточки зрения качества и своевременности этих контактов и основывается на анализе существующей истории взаимодействия и мнений клиентов.  
Искусство рекламной режиссуры заключается в творческой организации всех элементов художественного произведения с целью создания единого, гармоничного, целостного рекламного продукта. При анализе специфики рекламной режиссуры были рассмотрены важнейшие понятия композиция рекламного сценария, режиссерский сценарий и раскадровка, режиссерский замысел, являющийся основной частью постановочного проекта. Важно уметь создать постановочный проект и определить основные составляющие режиссерского замысла тему, идею, сверхзадачу, конфликт, событийный ряд, характеристику действующих лиц, художественный образ и жанр.  
Выделяется своей оперативностью и хронологичностью событийный репортаж. В познавательном репортаже (в основе — тема, а не событие) материал выстраивается по усмотрению автора. Проблемный репортаж (авторские обобщения, элементы анализа события) достаточно близок к корреспонденции. В этой манере написаны критические материалы увещевательного характера (на этапе ЖЦТ Рост , когда идет скрытое сравнение с товаром конкурента). Репортаж по праву считается венцом информационных жанров.  

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

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

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

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

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

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

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

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

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

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

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

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

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

Метод сценариев начал широко применяться в США в 50-е гг. ХХ в. РЭНД Корпорэйшен (Санта Моника), Гудзоновским университетом (Арлингтон), Центром международных исследований Массачусетского технологического института. Основной теоретик — Г. Кан. В его работе «Год 2000» (1976) намечена серия достижений в военно-технической области, которые способны вызвать качественное изменение в мировой обстановке . Г. Кан определил сценарий как описательную картину предполагаемого развития событий, создаваемую с целью сосредоточить внимание на причинно-следственных связях развития событий, когда требуется принятие решений. Сценарий — это динамическая последовательность возможных событий с упором на причинно-следственных связях между этими событиями и точками принятия решений, способных изменить их ход и траекторию движения во времени всей рассматриваемой системы и подсистем. Прогнозирование в рамках сценарии о техники основано на двух положениях интуитивизма: для того, чтобы предвидеть, не обязательно полностью объяснять настоящее и будущее; специалист в той или иной области всегда готов сказать о будущем больше, чем он может обосновать и доказать. По Кану, сценарии должны отвечать на следующие вопросы: как шаг за шагом может возникнуть та или иная гипотетическая ситуация, какие альтернативы существуют для ответственных лиц, принимающих решения на каждом этапе развития событий для того, чтобы повлиять на данный процесс. Сценарий — это гипотетическое описание причинно обусловленной последовательности событий (этапов трансформации системы). Сценарный метод — это разновидность качественного (а не математического) моделирования. Изначально сценарный метод развивался как кризисный менеджмент. Как прикладная прогностическая и управленческая методика, он начал использоваться во времена «холодной войны». В США он был ис- пользован экспертами по национальной безопасности. Например, в пери- од Карибского кризиса Пентагон создал ряд сценариев развития этого кризиса. Был сделан вывод о низкой вероятности внезапного ядерного удара со стороны СССР и предложены меры по «сохранению лица» Н. Хрущева при выходе из данного кризиса. Данный пример демонстрирует то, что сценарист выступает как разрушитель привычных стереотипов, устоявшихся схем, расширяет поле возможного и тем самым обеспечивает готовность действовать в незапланированных кризисных ситуациях (выполняет функции конструирования реальности и предостережения) . Позднее сценарии выходят за рамки кризисного менеджмента и в настоящее время используются при решении следующих типов задач: прогнозирование наиболее вероятных изменений политической ситуации; прогнозирование политических кризисов и поиск путей их преодоления; планирование и разработка комплекса мер, направленных на достижение проектируемой политической ситуации (это деятельность по принятию политических решений). Выделим существенные характеристики сценарного метода: 1. Последовательность событий (принцип пошагового описания). 2. Причинно-следственные связи этапов трансформации изучаемой системы. 3. Трансформация исследуемого процесса (сценарный метод — это описание динамики системы, но в сценарии, как в итоговом документе содержатся элементы статического описания ситуации (факты, показатели, признаки). 4. Гипотетический характер описания (вероятностная оценка реализуемости сценария). Метод сценариев предполагает создание множества сценариев, описывающих различные альтернативы развития примерно одной и той же ситуации. При построении сценариев используются различные комбинации целей, посылок и факторов, влияющих на развитие событий. Кан отмечал, что логика событий описываемых в сценарии, приводит к формированию «систематического контекста» или «альтернативно- го будущего». Чем сценарий невероятнее, тем лучше. Сценарий помогает выявить те элементы будущего, которые обычно с трудом просматриваются на основе исторических аналогий и логической экстраполяции. Кан применял метод сценариев к анализу международных отношений. Еще один классик методики — де Вирд — подчеркивал не столько невероятность, сколько логику сценария, подробное описание всех явлений будущего, к которому может привести описываемое развитие событий. Сценарии, по его мнению, не могут содержать «крупных непредсказуемых скачков». Кризисная ситуация не может быть объяснена только на основе «просчета» политиков. Сценарии позволяют неочевидные альтернативы и варианты событий. Ведущий сотрудник Центр международных исследований Массачусетского технологического института Блумфилд в 70-е гг. ХХ в. разработал сценарии развития Западной Европы. Бело выделено несколько основных факторов (переменных) каждого возможного сценария, а затем определено конечное число возможных моделей будущего Европы. Да- лее была поставлена задача определить степень вероятности того или иного прогноза. Были выделены следующие ключевые факторы оценки будущего: политика США, британская политика, французская политика, западногерманская политика (она обладает наибольшим динамизмом), советская политика, а также стратегические технологические изменения. Западногерманская политика, по мнению Блумфилда, обладала наибольшим динамизмом в силу следующих причин: центральное положение ФРГ в Западной Европе, специфика отношений с ГДР, мощная экономика). Были построены следующие альтернативные модели будущего: 1) модель «статус-кво»; 2) модель объединенной Европы, которая включала два варианта: отход Западной Европы от сотрудничества с США либо партнерство, высокий уровень сотрудничества с США; 3) модель «атлантического мира» с укреплением и расширением НАТО; 4) «националистическая Европа» — разъединенная с противоборствующими государствами, обладающая ядерным оружием. Из этих вариантов была выбрана вторая модель «Объединенная Европа» как наиболее вероятный вариант развития. Метод сценариев дополняется анализом политической ситуации. Политический процесс — это движение от ситуации к ситуации. Ситуация — это один шаг политического процесса, а ее развитие возможно по нескольким сценариям. Отметим достоинства сценариотехники. Достоинство данного метода — строгое прослеживание причинно-следственных связей. Можно заключить, что сценарий как метод прогнозирования позволяет устанавливать различные виды связей между переменными; рассматривать сразу несколько аспектов изучаемой проблем; выделять временные промежутки описываемого будущего. При написании сценария нужно выяснить вид итогового документа и поддержать определенную технологическую процедуру его создания. Функция, форма и содержание сценария определяются спецификой задания (заказа). Иногда сценарий может иметь «сырую» форму (качественные критерии) либо формализованную форму после использования экспертного метода. Например, работая на заказ, сценариотехник выясняет желаемую цель, дает характеристику имеющейся ситуации, оценивает ресурсы и возможности, которыми располагает лицо, принимающее решения, для достижения целей. Сценариотехника тесно переплетается с методом экспертных оценок (см. соответствующий раздел). Основные факторы, влияющие на выбор техники построения сценария по А. С. Ахременко. 1. Тип прогнозной задачи. В сценариотехника используются для решения трех типов задач: прогнозирование наиболее вероятных изменений политической ситуации, прогнозирование кризисов и проработка путей их преодоления, планирование и выработка комплекса мероприятий, направленных на достижение желаемой ситуации. 2. Сроки подготовки прогноза, которые зависят от типа сложившейся ситуации (кризисной либо стандартной) и от требований заказчика. 3. Период прогнозирования вариантов развития ситуации. 4. Наличие либо отсутствие экспертов по данной проблеме, степень их профессиональной подготовки . Рассмотрим типовую модель создания нормативного сценария группой экспертов. Нормативный сценарий разрабатывается в тех случаях, когда необходимо выявить рациональные варианты достижения поставленных целей, оценить объем, качество требуемого ресурсного обеспечения. Этапы построения прогноза: предварительный, основной, заключительный. Участники разработки прогноза: представитель заказчика (общая постановка цели), руководитель рабочей группы, 1-2 человека-специалиста по анализу и обработке информации, эксперты- специалисты в предметной области прогноза. Эксперты могут взаимодействовать непосредственно либо заочно. На предварительном этапе заказчик дает характеристику ситуации, ставит цель — желательную ситуацию, показывает ресурсы и возможности, которыми располагает ЛПР (финансовые, временные, управленческие и т.д.); назначает руководителя рабочей группы. Руководитель рабочей группы формирует рабочую группу, готовит ориентирующую информацию для работы экспертов. Наряду с общей ин- формацией для всех экспертов, руководитель группы готовит дополни- тельную и даже индивидуальную информацию для отдельных экспертов. Сценарные разработки, как правило, бывают многоуровневыми. Например, на первом этапе, экспертам предлагаются специально подготовленные бланки ответов, где содержится информация о целях работы группы, промежуточные цели, а от экспертов ожидаются предложения по необходимым мероприятиям для достижения целей. На основном этапе осуществляется опрос экспертов первого уровня, затем по их рекомендациям — второго, а затем и третьего уровня, до тех пор, пока эксперты последнего уровня уже не требуют дополнительной экспертной диагностики. По мере опроса экспертов, руководитель группы составляет прогнозное дерево — рисует цепочки работ, мероприятий, последовательное выполнение которых приведет к поставленной цели. На заключительном этапе созданное прогнозное дерево мероприятий соотносится с наличными ресурсами, мероприятиям приписываются сроки. Подробные разработки вновь раздают экспертам, они оценивают вероятность их реализации, дополнительно указывают свои суждения и рекомендации. Затем рабочая группа составляет окончательный вариант сценариев.

Записи созданы 8837

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Похожие записи

Начните вводить, то что вы ищите выше и нажмите кнопку Enter для поиска. Нажмите кнопку ESC для отмены.

Вернуться наверх