41. Метод субъективной оценки альтернатив принятия решения в условиях неопределенности и риска.

Табл. Оценка полезности альтернатив:

критерий	Субъективная оценка «А»	Субъективная оценка «В»	Вес критерия
1) ЗП	К= 0,8	0,9	0,3
2) перспективы продвижения	0,95	0,65	0,4
3) безопасность	0,6	0,95	0,2
4) место нахождения	0,95	0,45	0,1

Взвешенная средняя оценка «А»=0,8*0,3+0,95*0,4+0,6*0,2+0,95*0,1= 0,84

Взвешенная средняя оценка «В»= 0,9*0,3+0,65*0,4+0,95*0,2+0,45*0,1= 0,77

Лучшей являет компания «А».

Лучшей признается альтернатива с наибольшей величиной взвешенной оценки.

Вес критерия всегда равен 1.

Принятие решения в условиях неопределенности.

Владелец ресторана хочет осуществить выбор 1 из 3 альтернатив его ремонта.

Табл. Выбор альтернатив при независимых условиях.

Альтернативы	факторы
	Без изменений	Новый конкурент	Изменение трассы
1) ничего не менять	2	0	-1
2) текущий ремонт	4	3	-3
3) капитальный ремонт	7	2	-10

Табл: Матрица сожалений по каждой альтернативе:

(7-2) 5 (3-0) 3 (-1+1) 0 =8

(7-4) 3 (3-3) 0 (-1+3) 2 =5

(7-7) 0 (3-2) 1 (-1+10) 9 =10

В матрице сожаления, чем меньше сожаление, тем меньше потери.

Ответ: сделать текущий ремонт

43.Принятие решения в условиях риска.

Коэффициент.

1. 0.5

2. 0.2

3. 0.3

Рассчитать ожидание прибыли или убытка:

1. 0.5*2+0.2*0+0.3*(-1)=1-0.3=0.7

2. 0.5*4+0.2*3+0.3*(-3)=2+0.6=1.7

3. 0.5*7+0.2*2+0.3*(-10)=3.5+0.4-3=0.9

44. Преимущества разработки автоматизированной системы управления специализированной фирмой.

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

Основные преимущества внешнего разработчика, которые свойственны ему по определению:

Профессионализм

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

Реализм

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

Ответственность

Внешний разработчик несёт перед заказчиком юр.. и финансовая ответственность за разработку в полном объёме

Экономическая целесообразность

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

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

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

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

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

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

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

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

45. Комплексная системная автоматизация.

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

Негативный фактор:

1. Форматы данных несовместимы

2. Нет возможности получить полную картину

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

Преимущества комплексной системы:

1. Полнота и корректность данных

2. Гибкость и настраиваемость параметров (отражает специфику деятельности предприятия)

3. Высокую надёжность и быстродействие

4. Сохранность инф. в БД и возможность её быстрого восстановления

5. Возможность наращивания и модернизации системы

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

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

Результатом обработки является документ, который сохраняется в БД АРМ или в приписанном ему общей области БД.

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

В системе разрыв инф. цепочки сигнализирует об аварии и локализует её источник.

46. Концепции построения и реализации ИС ориентированных на анализ данных.

В основе концепции хранилища данных лежат 2 идеи:

1. Интеграция ранее разъединённых детализированных данных :

• Исторические активы

• Данные из традиционных СОД

• Данные из внешних источников в едином хранилище данных их согласования и возможная интеграция

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

Автором концепции хранилища данных является Б.Инмон.

Наиболее распространённой на сегодня ошибкой является попытка найти в концепции хранилища данных некий законченный рецент реализации ИС.

Тем более это не некий готовый программный продукт или некое решение.

Цель концепции хранилища данных:

• прояснить отличие в ОС и АС (аналитической системы)

• опреденить требования к данным

• определить общие принципы и этапы её построения , основные источники данных.

• Дать рекомендации по решению потенциальных проблем при их выпуске, очистке и т.д.

Предметом хранения данных являются сами данные.

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

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

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

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

Для понимания данной концепции необходимо наличии ему принципиальных предметов:

• Концепция хранения данных – не концепция анализа данных, скорее это концепция подготовки данных для анализа.

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

• Концепция хранения данных предполагает не просто единый логический взгляд на данные организации( как иногда это практикуется).Она предполагает реализацию единого интегрального источника.

Последний пункт достаточно принципиален.

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

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

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

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

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

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

Основным требованием аналитика является даже не столько оперативность, сколько достоверность ответа.

Но достоверность в конечном счёте и определяется согласованностью.

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

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

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

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

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

• Неоднозначность программной среды

• Распределённость

• Защита данных от несанкционированного доступа

• Построение и ведения многоуровневых справочников метаданных

• Эффективное применение и обработка очень больших объёмов данных

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

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

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

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

Хранилище данных уже по своей природе являются распределённым решением .

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

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

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