Принципы дизайна: Закон Хика — быстрое принятие решений. Практическое использование закона Хика

05.05.2019

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

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

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

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

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

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

    передавать данные системе различными способами;

    получать данные от различных устройств системы в различном формате;

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

2.2.3 Информационная технология экспертных систем

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

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

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

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

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

Третье отличие связано с использованием нового компонента информационной технологии - знаний.

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

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

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

Различают два вида объяснений:

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

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

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

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

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

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

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

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

В результате изучения данной главы студент должен:

знать

  • положения и теоретические основы информатизации поддержки принятия решений в сфере управления;
  • современные представления о системах поддержки принятия решений;
  • историю и тенденции развития систем поддержки принятия решений;

уметь

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

владеть

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

Определение и основные характеристики систем поддержки принятия решений

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

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

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

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

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

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

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

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

Три перечисленных утверждения особенно важны, если время, отведенное на принятие решения, ограничено.

В статье Applying information technology to organization design сформулированы еще три утверждения :

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

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

С момента появления первых разработок в области систем поддержки принятия решений определение СППР непрерывно совершенствуется 1 .

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

Приведем некоторые определения СППР:

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

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

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

Согласно Е. Тюрбану 1 СППР обладают следующими четырьмя основными характеристиками:

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

Также Е. Тюрбан предложил список характеристик «идеальной»

СППР - она:

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

СППР состоит из двух основных подсистем - лица, принимающего решения, и информационной системы (ИС). Функция ЛПР как компонента СППР состоит не только в вводе данных, но и в принятии решений - на основе своих знаний и интуиции .

Данные есть результат наблюдения за физическим объектом или явлением: например, ежедневным объемом производства, ежедневным объемом продаж или уровнем запасов продукта. База данных есть совокупность взаимосвязанных файлов. Системы управления базами данных представляют собой компьютерные программы, связанные с управлением большим количеством данных в физическом хранилище, а также с созданием и обновлением запросов к базам данных. СУБД могут представлять собой как «стороннее» программное обеспечение, так и быть встроенными в СППР.

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

Простейшая архитектура СППР представлена на рис. 3.1, а ее место в комплексной информационной системе предприятия - на рис. 3.2.

Рис. 3.1.


Рис. 3.2.

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

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

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


Рис. 3.3.

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

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

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

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

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

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

Мощность означает способность системы отвечать на существенные вопросы.

Доступность - это способность обеспечить предоставление ответов на запросы пользователя в нужной форме и в нужное время.

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

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

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

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

Современные компьютерные системы поддержки принятия решений:

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

Карта путешествий потребителя, оценка рынка и другие советы от менеджера по продукту «Альфа-банка» Екатерины Снегирёвой.

В закладки

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

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

Пользовательская история (user story) - главный артефакт в гибкой разработке, поскольку представляет собой контейнер, служащий переносу потока ценностей к пользователю. А смысл гибкой разработки как раз и состоит в быстрой доставке ценного результата пользователю.

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

Бэклог (backlog) - это полный список всех работ, stories. ​

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

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

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

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

Немного market validation, research и усовершенствованный CJM здорово помогают оценить происходящее, увидеть полную картину вокруг и расставить приоритеты.

Market validation

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

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

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

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

  • Кто ещё работает над аналогичными продуктами или решениями?
  • Что уже сделано и на каком уровне?
  • Какие проблемы могут закрывать эти функциональности?
  • Насколько эти решения могут удовлетворить потребности пользователей?
  • Есть ли что-то похожее у вас?

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

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

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

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

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

Система поддержки решений СППР решает две основные задачи:

1. выбор наилучшего решения из множества возможных (оптимизация);

2. упорядочение возможных решений по предпочтительности (ранжирование).

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

Для анализа и выработок предложений в СППР используются разные методы. Это могут быть: информационный поиск, интеллектуальный анализ данных, поиск знаний в базах данных, рассуждение на основе прецедентов, имитационное моделирование, эволюционные вычисления и генетические алгоритмы, нейронные сети, ситуационный анализ, когнитивное моделирование и др. Некоторые из этих методов были разработаны в рамках искусственного интеллекта. Если в основе работы СППР лежат методы искусственного интеллекта, то говорят об интеллектуальной СППР, или ИСППР .

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

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

Системы поддержки принятия решений:

· предполагают гибкость пользователей, адаптируемость и быструю реакцию;

· допускают, чтобы пользователи управляли входом и выходом;

· оперируют с небольшой помощью профессиональных программистов или без нее;

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

· используют сложный анализ и инструментальные средства моделирования.

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

Процесс принятия решений в СППР, включает четыре стадии:

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

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

3) выбор - заключается в подборе решений среди альтернатив. Здесь изготовитель решений мог бы нуждаться в большой системе СППР, чтобы использовать более обширные данные относительно ряда альтернатив и комплексные аналитические модели, чтобы объяснить все затраты, следствия и возможности;

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

Рассмотрим основные классификации СППР.

По взаимодействию с пользователем выделяют три вида СППР:

· пассивные помогают в процессе принятия решений, но не могут выдвинуть конкретного предложения;

· активные, непосредственно, участвуют в разработке правильного решения;

· кооперативные предполагают взаимодействие СППР с пользователем.

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

По способу поддержки различают:

· модельно-ориентированные СППР, используют в работе доступ к статистическим, финансовым или иным моделям;

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

· СППР, ориентированные на данные, имеют доступ к временным рядам организации. Они используют в работе не только внутренние, но и внешние данные;

· СППР, ориентированные на документы, манипулируют неструктурированной информацией, заключенной в различных электронных форматах;

· СППР, ориентированные на знания, предоставляют специализированные решения проблем, основанные на фактах.

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

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

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

giner показал мне ролик, который я рекомендую просмотреть всем. www.snob.ru/selected/entry/5445 в этом ролике доступно и на примерах объясняется и доказывается почему разработчик на этапе проектирования формы принимает за пользователя решения, как это работает и почему это вообще происходит. Кому лень смотреть - перескажу основное в двух словах. В различных странах разное количество людей участвует в программе донорства органов. Серьезное ведь дело. Страны близки по культуре, соседствуют и вроде как отношение в них к этим вещам должно быть примерно одинаковым. Но статистика показывает, что в одних странах в программе согласны участвовать 10-15%, а в других странах - 90-100% людей. В ролике показано, что это зависит не от менталитета, а от формулировки в медицинском формуляре. В одной форме написано «я отказываюсь от участия в программе» и там надо ставить галочку, а в другой форме написано «я согласен участвовать в программе». В большинстве случаев человек вообще не ставит галку. Не меняет состояния, не принимает решения. Там есть и другие примеры. Вообще очень интересный материал, рекомендую просмотреть.

Тоже самое происходит и с нашими формами. Да, можно призывать пользователей быть разумными, вчитываться и осознанно принимать решения, но это не работает. Вероятнее всего пользователь просто все сделает по умолчанию, т.е. сделает так как решили вы . Именно нами, как разработчиками определяется как поведет себя пользователь, даже несмотря на то, что у него будет выбор. Да, не всегда, но в огромном количестве случаев (если опираться за исследователя из ролика - от 80 до 100%). Исходя из этого я утверждаю, что да, разработчик несет ответственность за выбор пользователя, так как очень часто этот выбор управляется именно разработчиком.

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

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

Давайте посмотрим на хабр. Серьезное сообщество, порог входа, ценность аккаунта и так далее. Что нужно для того, чтобы написать топик? Целая система выстроена для того, чтобы человек прочитал требования! Можно же было просто поместить все это в правилах и банить всех, кто их не соблюдает. Но правила никто не читает, а вот такой механизм - работает. Это естественно, хоть и не приятно. Ожидать, что пользователь прочитает все ваши правила, если его специально не пинать - опрометчиво. Таков естественный порядок. Ожидать, что именно в вашем случае он будет нарушен и пользователь станет читать комментарии в форме и изучит правила - опрометчиво. Полагаться на то, что пользователь прочитает и будет соблюдать - все равно, что полагаться на то, что дождь пойдет снизу вверх.

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

Независимо от того, сознательно вы направляете пользователя или нет - вы его направляете. Лучше это делать сознательно и в правильном направлении.