2. Организационные решения
Организационное решение
|
ОРГАНИЗАЦИОННОЕ РЕШЕНИЕ — это выбор, который должен сделать руководитель, чтобы выполнить обязанности, обусловленные занимаемой им должностью. Цель организационного решения — обеспечение движения к поставленным перед организацией задачам. Поэтому наиболее эффективным организационным решением явится выбор, который будет на самом деле реализован и внесет наибольший вклад в достижение конечной цели. Организационные решения можно квалифицировать как запрограммированные и незапрограммированные. ЗАПРОГРАММИРОВАННЫЕ РЕШЕНИЯ. Нобелевский лауреат Герберт Саймон использовал термин запрограммированные, заимствованный из языка компьютерной технологии, для описания решений в высокой мере структурированных. ЗАПРОГРАММИРОВАННОЕ РЕШЕНИЕ есть результат реализации определенно!! последовательности шагов или действий, подобных тем, что предпринимаются при решении математического уравнения. Как правило, число возможных альтернатия ограничено и выбор должен быть сделан в пределах направлений, заданных организацией. К примеру, инспектор больницы при составлении графика работы медсестер и санитаров может исходить из формулы, требующей определенного соотношения между числом пациентов и обслуживающего персонала. Если правилами больницы предусмотрена одна медсестра на пять пациентов, то решение принимается автоматически — на этаже с 50 пациентами нужно иметь 10 сестер. Подобным образом, если от начальника финансового отдела потребовали вложить избыточную наличность и депозитные сертификаты, облигации муниципалитета или обычные акции, в зависимости от того, что именно в данное время обеспечивает наибольшую прибыль ш\ инвестированный капитал, выбор определяется результатами простого расчета по каждому варианту и установлением самого выгодного. Программирование можно считать важным вспомогательным средством в принятии эффективных организационных решений. Определив, каким должно быть решсние, руководство снижает вероятность ошибки. Этим также экономится время, поскольку подчиненным не приходится разрабатывать новую правильную процедуру всякий раз, когда возникает соответствующая ситуация. Неудивительно, что руководство часто программирует решения под ситуации, повторяющиеся с определенной регулярностью. Руководителю очень важно иметь уверенность в том, что процедура принятия решений в самом деле правильна и желательна. Очевидно, если запрограммированная процедура становится неверной и нежелательной, решения, принятые с ее помощью, будут неэффективными, а руководство утратит уважение своих работников и тех людей вне организации, на которых принимаемые решения сказываются. Более того, в высшей степени желательно сообщить об обоснованиях методологии принятия запрограммированных решений тем, кто этой методологией пользуется, нежели просто предложить ее для употребления. Неспособность ответить на вопросы, начинающиеся с «почему» в связи с процедурой принятия решений, зачастую порождает напряжение и обижает людей, которые должны применять эту процедуру. Как показано в примере 7.1., эффективный обмен информацией повышает эффективность принятия решений. |
Хасанова Линара 5.1 ТиП
3. Существующие подходы к принятию решений.
Понятие процесса принятия решения
1.1 Общее понятие.
Процессы принятия решений, понимаемые как выбор одной из нескольких альтернатив, пронизывают всю человеческую жизнь. Большинство решений мы принимаем не задумываясь, так как существует автоматизм поведения, выработанный практикой. Но возможны и ситуации, когда человек испытывает мучительные раздумья. В таких ситуациях человек сталкивается либо с новым объектом выбора, либо обстановкой, в которой совершается выбор.
Однако в управлении принятие решений – это более систематизированный процесс. Принятие решений в организации представляет собой сознательный выбор из имеющихся вариантов или альтернатив направления действий, сокращающих разрыв между настоящим и будущим желательным состоянием организации. Сам процесс принятия решений включает множество разных элементов, но непременно в нем присутствуют такие элементы, как проблемы, цели, альтернативы и решения. Данный процесс лежит в основе планирования деятельности организации, так как план – это набор решений по размещению ресурсов и направлению их использования для достижения целей организации [6, 303]. Принятие решений – это “центр”, вокруг которого вращается жизнь организации. Решение можно рассматривать как продукт управленческого труда, а его принятие – как процесс, ведущий к появлению этого продукта.
Таким образом, принятие решений отражается на всех аспектах управления, и этот процесс является частью ежедневной работы управляющего (менеджера). В управлении организацией принятие решений осуществляется менеджерами различных уровней и носит достаточно формализованный характер, так как решение касается не только одной личности, а чаще всего оно относится к подразделению или к организации в целом.
Принятие решений в организации характеризуется следующим:
. Это сознательная и целенаправленная деятельность, осуществляемая человеком;
. Это поведение, основанное на фактах и ценностных ориентациях;
. Это процесс взаимодействия членов организации;
. Это выбор альтернатив в рамках социального и политического состояния организационной среды;
. Это часть общего процесса управления;
. Это важно для выполнения всех других функций управления.
Принятие решений – это наука и искусство. Роль принятого решения огромна. Важнейший вопрос успешного функционирования организации заключается в том, как организация может выявлять свои проблемы и решать их. Каждое решение нацелено на какую-то проблему, а правильное решение – это то, которое максимально обеспечивает цели организации. Тем не менее, “определение цели, еще не формулировка проблемы, а без этого нет необходимости в решениях и действиях.”[10, 296]. Цели, которые часто пытаются достичь, бывают в ряде случаев недостаточно осознанными. Установление неправильных целей означает, следовательно, и решение неправильно сформулированных проблем, что может привести к гораздо большему расточительству ресурсов, чем неэффективное решение правильно сформулированных проблем. В этой связи очень велика роль руководителя. Ведь решение не только процесс, но и один из видов мыслительной деятельности и проявления воли человека. Его характеризуют такие признаки: . Возможность выбора из множества альтернативных вариантов (если нет альтернатив, то нет выбора и, следовательно, нет и решения); . Наличие цели (бесцельный выбор не рассматривается как решение); . Необходимость волевого акта лица, принимающего решение (ЛПР), так как ЛПР формирует решение через борьбу мотивов и мнений [2, 3].
В этом плане, роль руководителя состоит в умении вырабатывать правильное суждение, правильно осмысливать реальные (а не взятые из заранее составленного перечня) проблемы и постоянно нацеливать себя на управление, опережающее события. Но именно о роли руководителя подробнее речь пойдет в главе. Следует отметить, что выявление проблем является не только одним из этапов процесса принятия решения, но и постоянно действующей функцией управления в любой организации.
В менеджменте понятие «проблема» используется для обозначения разрыва между желаемым состоянием (прежде всего целями) той или иной организации и ее фактическим состоянием. А само решение проблемы рассматривается как средство преодоления такого разрыва, выбор одного из многих объективно существующих курсов действий (альтернатив), позволяющих перейти от наблюдаемого состояния к желаемому.
Таким образом, нами установлен тот факт, что чем точнее определена проблема, тем правильнее может быть принято решение. Но необходимо еще учесть и влияние ситуативных факторов на процесс принятия решений. Условия ситуации и другие факторы оказывают влияние на саму технологию принятия решения, предопределяют ее. Поэтому далее рассмотрим классификацию проблем и соответствующих им решений.
Хасанова Линара 5.1 ТиП
База данных для принятия решений
1. Прежде всего, должен быть выполнен логический проект. На этом уровне основ ное внимание уделяется правильности реляционных определений. Таблицы должны представлять правильные отношения, гарантируя таким образом, что реляцион ные операции будут выполняться так, как им надлежит выполняться, и не будет получено никаких непредвиденных результатов. Затем должны быть описаны ти пы (домены), на их основе определены столбцы и указаны зависимости между столбцами (в том числе функциональные и другие зависимости). На основании этих данных может быть выполнена нормализация и определены дополнительные ограничения целостности.
2. После этого создается физический проект, который должен быть производным от логического проекта. На этом уровне, безусловно, основное внимание уделяется эффективности хранения данных и производительности. В принципе, допустимо любое физическое расположение данных, при условии, что между логической и физической схемами вводится сохраняющее информацию преобразование, которое может быть выражено с помощью реляционной алгебры [2.5]. Отметим, в частно сти, что из наличия такого преобразования следует, что существуют реляционные представления физической схемы, которые отображают ее подобно логической схеме, и наоборот.
Безусловно, логическая схема может быть впоследствии изменена, например, в целях включения новых видов данных, а также новых или вновь обнаруженных зависимостей. Внесенные изменения, естественно, потребуют также соответствующих изменений в физической схеме. Но этот вопрос в данной главе не рассматривается. Здесь нас больше интересует то, что физическая схема может изменяться, в то время как логическая схема будет оставаться прежней. Например, предположим, что операция соединения таблиц SP (Поставки) и Р (Детали) в значительной степени применяется намного чаще по сравнению с другими операциями доступа к данным. Тогда может возникнуть стремление выполнить предварительное соединение таблиц SP и Р на физическом уровне, чтобы сократить тем самым количество операций ввода-вывода и расходы на соединение этих таблиц. Нологическая схема должна оставаться неизменной, если мы хотим сохранить физическую независимость от данных. (Безусловно, оптимизатор запросов должен иметь информацию о существовании хранимого предварительного соединения и действовать соответствующим образом, чтобы достичь желаемого повышения производительности.) Кроме того, если модель доступа в дальнейшем изменится таким образом, что станет преобладать доступ к отдельным таблицам, а не к соединению, должна существовать возможность вновь изменить физическую схему, чтобы физически разъединить таблицы SP и р, опять-таки, без какого-либо воздействия на логический уровень.
Из сказанного выше должно быть ясно, что проблема обеспечения независимости от физических данных — это в основном проблема поддержки представлений (исключая проблему обновления фрагментов, рассматриваемую в главе 21, которая проявляется на
другом участке общей архитектуры системы). В частности, необходимо иметь возможность обновлять такие представления. А именно, если базовые таблицы рассматриваются на логическом уровне как представления, а хранимые версии этихпредставлений на физическом уровне рассматриваются как таблицы, то должна применяться такая физическая схема, чтобы СУБД позволяла осуществлять операции обновления этих представлений в терминах указанных базовых таблиц.
Итак, как показано в главе 9, теоретически все представления являются обновляемыми. Поэтому, с теоретической точки зрения, если физическая схема разработана на основе логической схемы по принципу, описанному выше, то может быть достигнута максимальная физическая независимость от данных. Любое обновление, выраженное в терминах логической схемы, будет автоматически преобразовано в обновление, выраженное в терминах физической схемы, и наоборот, а сами изменения физической схемы не будут требовать изменений в логической схеме. Но, к сожалению, современные продукты SQL не поддерживают в необходимой мере обновления представлений. Поэтому набор допустимых физических схем в этих продуктах очень ограничен (причем совершенно излишне).
Примечание. На практике указанный выше подход может быть осуществлен путем моделирования подходящего механизма обновления представления средствами хранимых процедур, триггерных процедур, промежуточного программного обеспечения или различных их сочетаний. Однако обсуждение этих методов выходит за рамки данной главы.
Логическое проектирование
Правила логического проектирования не зависят от предполагаемого использования базы данных. То же самое относится и ко всем без исключения видам приложений. Следовательно, в частности, не должно иметь значения, какими являются эти приложения — оперативными приложениями (OLTP) или приложениями поддержки принятия решений. В любом случае, должна использоваться одна и та же процедура проектирования.
Хасанова Линара 5.1 ТиП