Cтраница 1
Изучение управленческого вопроса начинается с обеспечения правовой основы подготавливаемого документа - с изучения действующих законодательных актов, правительственных побтановлений, так как издаваемый распорядительный документ не должен противоречить установленным нормам.
Решение организационных и управленческих вопросов, связанных с капитальным ремонтом, осложняется тем, что в ведении одного ремонтно-строительного управления (участка) находятся трубопроводы, имеющие неодинаковые конструктивные решения (подземный, надземный, наземный, проложенный с частичным заглублением), различные диаметры и разнук давность прокладки. Наконец, технология, организация угравление капитальным ремонтом линейной части магистральных трубопроводов не регламентированы общесоюзными нормативными документами.
В таком сегменте особенно важны управленческие вопросы по отношению с непосредственным руководителем.
Сделана попытка, во-первых, экономические, технические, экологические и управленческие вопросы рассматривать в единстве, во-вторых, любые процедуры формирования стратегии фирмы излагать в виде конкретной методики, базирующейся на научных подходах.
Право голоса у работников при решении управленческих вопросов невелико. Согласно закону в частных фирмах представители работников имеют право принятия решений по ограниченному кругу вопросов: ликвидация фирмы, слияние с другой фирмой, изменение местоположения.
Этот пример показывает, что в менеджменте постановка управленческих вопросов должна быть гибкой и соответствовать ситуации. Контроллер должен быть всегда готов предоставить соответствующую ситуации информацию. В течение дня стратегия продавца может меняться в зависимости от того, есть у киоска очередь или нет. Если возникает очередь, то имеет значение уже не только сумма покрытия, но и время обслуживания. Предприниматель должен ориентироваться на критерий суммы покрытия в минуту времени обслуживания. Если он отпускает продукт клиентам, когда они равномерно подходят к киоску, то стратегическим показателем для него должна быть сумма покрытия за штуку.
РД управленческого характера, связанные с совершенствованием управленческой деятельности, решением организационных задач могут также перерабатываться по мере накопления практического опыта решения управленческих вопросов.
Разделение факторов не с точки зрения конкретного субъекта управления, анализируемого в определенных временных и пространственных условиях хозяйствования, а по абстрактным представлениям о классификации факторов вообще может быть не всегда приемлемым для решения управленческих вопросов на практике.
Итого необходимые расходы составили в планируемом году 1 113 тыс. руб. Предполагаемый дефицит денежных средств на расчетном счете в конце периода составит по расчетам 168 тыс. руб. Финансовому менеджеру в данном случае необходимо рассмотреть вопросы принятия управленческих вопросов о сокращении дебиторской задолженности и поиску путей увеличения коммерческого кредита для предприятий.
Следовательно, в самостоятельных полномочиях решает вопрос только воля трудового коллектива, в совместных - воля двух субъектов управления, а в полномочиях совещательного характера воля трудового коллектива оформляется лишь предложениями, а принимает их и решает управленческие вопросы иной орган управления.
На основе глубокого изучения содержания и организационно-технических условий труда, анализа структуры рабочего времени мастеров, проведения мероприятий, направленных на освобождение их от выполнения несвойственных им работ, на предприятиях разрабатываются и внедряются рациональные распорядки рабочего дня и месячные календарные планы работы мастеров, в которых каждой группе управленческих вопросов (производственных, личных и воспитательных) отводится определенное время. Одни вопросы мастер должен решать ежедневно, другие - раз в неделю или декаду, третьи - раз в месяц.
Следовательно, бухгалтерский учет является неотъемлемой частью управления предприятием. Учетная информация служит основой для решения управленческих вопросов как внутри предприятия, так и вне его. Она обеспечивает ряд функций, основными из которых являются: информация, планирование, контроль и анализ.
Даже в случаях переписки между частными лицами и учреждением ее содержание касается управленческих вопросов.
Протокол занимает особое место в системе организационно-распорядительных документов. С одной стороны, его можно отнести к информационным документам (так как он содержит Информацию о ходе обсуждения каких-то управленческих вопросов), а с другой - протоколы содержат постановляющую часть и, таким образом, могут рассматриваться как распорядительные документы.
Масштаб деятельности компании непосредственно связан с числом уровней, на которых принимаются управленческие решения. В зависимости от принятой в компании организации и философии управления каждому уровню свойственна своя степень ответственности и компетентности в решении управленческих вопросов. Поэтому информационная система должна обеспечивать все уровни управления информацией, различающейся степенью детализации, периодичностью представления, акцентированностью на те или иные аспекты деятельности.
Лекция 5 Управленческие проблемы и их решение
08.09.08 Шевляков Валерий Алексеевич
1. Управленческие проблемыи причины их возникновения.
2. Решение проблем.
3. Методы принятия решений и их реализация.
1. Управленческие проблемы и причины их возникновения.
Управленческая проблема представляет собой сложный вопрос, задачу, требующую своего уяснения, изучения, оценки, решений. Чтобы уяснить причины возникновения проблем, необходим причинно-следственный анализ, в ходе проведения которого можно обнаружить истинные причины, отсеять побочные, неглавные, сопутствующие, уяснить, глубоко изучить и оценить ситуацию. Тем самым будет подготовлена предпосылка к принятию необходимого решения.
Управленческие проблемы классифицируются по признакам :
1) степень важности и срочности ;
2) масштабы последствий в случае принятия или не принятия решения и численность организации и лиц, которых затрагивают данные проблемы;
3) возможность решения проблемы с наименьшими затратами и в оптимальные сроки;
4) степень риска , связанного с решением данной проблемы;
5) степень структуризации и формализации , т.е. возможность выражать проблему в количественно-качественных показателях.
Проблемы могут различаться по способам их разработки:
1) безальтернативный , если путь решения проблем лишь один, других вариантов нет;
2) бинарный, многовариантной;
3) в случае, если ни один из способов не может дать положительный ответ на вопрос «как решить проблему?», применяется комбинированный способ , который заключается в том, что проводится комбинирование отдельных частей или способов решения проблем.
Виды проблем рассматриваются по критериям :
1) стратегические направлены на формирование базы стратегических данных, их уяснение, изучение, оценку и практическое использование;
2) тактические : разрешение вопросов происходит в более короткие сроки, чем стратегических;
3) долгосрочные ;
4) среднесрочные ;
5) краткосрочные ;
6) текущие ;
7) по уровню руководства : высшего, среднего, низшего звеньев управления.
Основные причины возникновения управленческих проблем :
1) изначально ошибочные цели организации, способы и сроки их достижения;
2) неверные принципы и методы деятельности работников;
3) неверные критерии оценки возможности предприятия и сотрудников;
4) умышленные нарушения в технике, технологии, финансах, поставках;
5) изменение в политике и экономике государства;
6) природные катаклизмы и стихийные бедствия.
2. Решение проблем.
Продукт нашей деятельности – решение управленческих проблем.
Решение – волевое воздействие человека на объект управления для разрешения проблемы, выбор альтернативы для достижения поставленной цели.
Требования, предъявляемые к управленческим решениям :
1) целевая направленность ;
2) иерархическая субординация : решения менеджера должны соответствовать делегируемым ему полномочиям;
3) обоснованность : решения должны иметь объективное обоснование рациональности;
4) адресность : решения должны быть ориентированы в пространстве и во времени, направлены на конкретные исполнения и ограничены во времени;
5) обеспеченность : решения должны предусматривать необходимые ресурсы и устанавливать источники их получения;
6) директивность : решения должны быть обязательны для исполнения и должны носить плановый характер.
Принципы принятия управленческого решения :
1) принцип единоначалия : решения принимаются единолично, как правило, менеджерами с авторитарным стилем поведения, которые предпочитают командовать и приказывать, в этих условиях возникает напряжённость, межличностные отношения характеризуются повышенной конфликтностью;
2) принцип единогласия : безоговорочная поддержка выдвигаемой альтернативы;
3) принцип большинства вводится в действие, если в процессе выработки решения есть различные мнения, устойчивые нормы принятия решения: 3.1. простое большинство; 3.2. 2/3 голосов;
4) принцип консенсуса : консенсус – согласование всех спорных вопросов и различных мнений в процессе выработки решений, а виды решений, как правило, совпадают с видами проблем.
Решение стратегических проблем относится к разряду инициативных, идущих от высшего руководства к исполнителям низших звеньев управления. В этом случае высшее руководство берёт на себя инициативу и ответственность за принятие решения стратегического характера (направление инвестиций в перспективное развитие производства нового вида изделий, на расширение производства или его свёртывание и закрытие предприятия).
Решение тактических проблем – дело средних звеньев управления (руководства). На основе предписаний сверху они планируют решение проблем в среднесрочных планах и выполняют краткосрочные задачи. Низовые звенья управления решают проблемы, исходя из установленных распоряжений, указаний и письменных приказов. Текущие проблемы каждодневного характера (рутинная работа) занимают основное время низовых звеньев управления. От решения данных проблем среднее звено, особенно высшее руководство должны быть освобождены.
Решение проблем классифицируется по ряду признаков : 1) по степени обязательности исполнения; 2) по функциональному назначению; 3) по способу принятия решения; 4) по сфере реализации.
По степени обязательности исполнения решения могут быть :
1) директивные , которые принимаются высшим руководством;
3) ориентирующие , которые принимаются руководством для координации работы нижестоящих управленческих структур, которые действуют автономно (дочерние предприятия, предприятия, входящие в холдинг, корпорацию, где есть единый руководящий орган).
По функциональному назначению : организационные, координирующие, регулирующие, активизирующие, контролирующие ход выполнения решения, предписывающие,
распределяющие работу между исполнителями по ведению контроля, проверки, подготовке нормативных документов.
По способу принятия решения выделяются выборочные и систематические решения.
К выборочным решениям относятся один или несколько вопросов решений проблемы, к систематическим – решения, охватывающие проблему целиком во всей её многосложности и взаимосвязи.
По сфере реализации решения связаны с той областью деятельности, которой порождена проблема, от решения которой зависит в дальнейшем ход дела в данной сфере: производство, поставки, финансы, НИОКТР.
Принятие решений всегда связано с определённой степенью риска.
3. Методы принятия решений и их реализация.
Процесс принятия решений – центральный пункт управленческой деятельности.
Методы принятия решений :
1) научный метод , суть:
1) путём наблюдения, сбора, анализа информации формулируется гипотеза - предположение о самой проблеме и возможных подходах к её решению;
2)научный метод даёт систематическую ориентацию , т.е. выявляет взаимосвязи данной проблемы с внешним окружением и внутренними переменными самой организации. Выявление взаимосвязи позволяет наиболее полно представить причины возникновения проблемы, увидеть её основу. Этот подход даёт возможность бороться не с последствиями, а с причинами возникновения проблемы и принять действия, исключающие повторения нежелательных явлений;
3) пользование математическим моделированием , к которому обращаются в сложных случаях, если трудно диагностировать проблему и подготовить решение без дополнительного количественно-качественного анализа;
2) метод экономического анализа включает методы экономической оценки экономических показателей работы предприятия, издержек, рентабельности, движения денежных средств, уровня спроса. Пример – модель, в основе которой лежит определение точки самоокупаемости, анализ безубыточности работы. Для принятия и реализации решений существует рациональное решение. В основе их разработки лежит объективный и всесторонний анализ условий, в которых предприятие действует в каждый период времени, тенденции, которые будут иметь место в дальнейшем. Этот анализ протекает по этапам: от начала возникновения проблемы до полного устранения и получения позитивного результата.
Этапы :
2) проводится анализ самой проблемы . Необходимо разобраться в проблеме до конца и точно её сформулировать;
3) выявление факторов, ограничивающих принятие рационального решения данной проблемы . К ограничениям внутреннего порядка относят: ограниченность средств для решения проблемы, недостающее число специалистов необходимой квалификации. Менеджеры могут вырабатывать и реализовывать рациональные решения лишь тогда, когда высшее руководство предоставляет им соответствующие полномочия;
4) осуществляется определение, оценка, выбор альтернативы из имеющихся вариантов . Сначала формулируются все возможные в данном случае альтернативы, из них выбираются реальные, главные: найти оптимальный вариант, позволяющий разрешить проблему. Научный подход к выбору альтернативы предполагает наличие некоего стандарта, критерия, с помощью которых устанавливается приемлемость того или иного варианта решений;
5) согласование решений с исполнителями и всеми заинтересованными сотрудниками . Оно осуществляется путём визирования документа предписывающего исполнение решения данной проблемы;
6) утверждение решения высшим руководителем предприятия . Эта процедура обязательна, если для реализации решения необходимо израсходовать материальные, финансовые, людские ресурсы и резервы. Тот, кто несёт ответственность за эти средства, тот утверждает решения. После утверждения начинается процесс реализации рационального решения.
Технические вопросы (Technical Issues)
Ключевые вопросы сопровождения программного обеспечения (Key Issues in Software Maintenance)
Для обеспечения эффективного сопровождения программных систем необходимо решать целый комплекс вопросов и проблем, связанных с соответствующими работами. Необходимо понимать, что процесс сопровождения предъявляет уникальные технические и управленческие требования к персоналу, занимающемуся сопровождениям и, в первую очередь, специалистам-инженерам. Попытка найти дефект в продукте, содержащем 500 тысяч строк кода, написанных другими инженерами – яркий пример сложностей, с которыми приходится сталкиваться инженерам по сопровождению. Другой пример, уже организационный, постоянная борьба за ресурсы с разработчиками (это чаще всего проявляется в вопросах отвлечения разработчиков от текущей работы для помощи в решении проблем сопровождения, а также в конкуренции за приоритеты финансирование разработки новой системы или сопровождения существующей). Одновременное планирование перспективной версии системы, реализация следующей версии и подготовка критических патчей для текущей версии – еще один классический пример проблем, с которыми приходится сталкиваться в процессе эксплуатации программного обеспечения.
Данная секция представляет некоторые технические и управленческие вопросы, связанные с сопровождением программных систем. Эти вопросы и проблемы сгруппированы в набор тем:
- Технические вопросы
- Управленческие вопросы
- Оценка стоимости
- Измерения
2.1.1 Ограниченное понимание (Limited understanding)
Ограниченное понимание подразумевает как быстро инженер по сопровождению может понять где необходимо внести исправления или изменения в код системы, которую он не разрабатывал. Исследования показывают, что от 40 до 60 процентов усилий по сопровождению тратится на анализ и понимание сопровождаемого программного обеспечения. Формирование целостного взгляда о системе представляет большое значение для инженеров. Этот процесс более сложен в случае анализа текстового представления системы – ее исходного кода, особенно, когда процесс эволюции системы от сборки к сборки, от релиза к релизу, в нем никак не отмечен, не документирован и когда разработчики не могут объяснить историю и структуру изменений, что, к сожалению, случается достаточно часто.
Для объектно-ориентированных программ качественно упрощает задачу понимания кода использование UML-инструментария, способного на основе кода восстановить не только модель классов, но и их взаимодействия в форме диаграмм классов (class diagram), коммуникаций или сотрудничества (collaboration в UML1.x, переименованная в communication в UML 2.0) и, особенно, последовательностей (sequence diagram), демонстрирующая структуру взаимных вызовов во времени. Если соответствующий инструментарий предоставляет одновременную визуализацию кода и диаграммы и обеспечивает взаимную синхронизацию их с точки зрения навигации (выбор метода в любой из представленных диаграмм автоматически позиционирует соответствующим образом редактор кода и, наоборот) – такие средства автоматизации могут качественно сократить время, необходимое для формирования представления о системе, иногда – даже не в разы, а на порядок (конечно, при достаточном уровне знания используемых технологий со стороны инженера по сопровождению). Если к этому добавить документированность (и доступность соответствующих активов –спецификаций, моделей) архитектуры и ключевых технологических решений со стороны разработчиков системы – обсуждаемый вопрос, конечно, не становится тривиальным, однако, превращается во вполне решаемую задачу. Вообще говоря, использование соответствующих средств автоматизации построения моделей по коду (задача обратного инжиниринга – reverse engineering) является обоснованной практикой изучения любой системы или фреймворка. Опыт показывает, что при достаточной квалификации инженера, формирование общего архитектурного представления о системе (или фреймворке), понимания того, какие технологические и структурные подходы и шаблоны использовались при ее построении, позволяет решать возникающие вопросы корректировки кода и расширения функциональности системы, не нарушая общие принципы ее построения, естественным образом обеспечивая ее эволюцию, без ущерба ее целостности. При таком понимании, даже не заглядывая в код системы или фреймворка, инженер способен с очень большой вероятностью предположить возможные причины сбоя, а, в общем случае, и любых аспектов поведения системы. Тема обратного инжиниринга освещается SWEBOK как самостоятельная техника сопровождения (4.3), однако, здесь показалось важным особо акцентировать на ней внимание именно в этой части обсуждения вопросов сопровождения.
2.1.2 Тестирование (Testing)
Стоимость повторения полного набора тестов для основных модулей системы может быть существенным как по времени, так и по стоимости. Для сопровождения системы особо значимым является выборочное регрессионное тестирование (см. область знаний Software Testing, тему 2.2.6 Регрессионное тестирование) системы или его компонент для проверки того, что внесенные изменения для привели к непреднамеренному изменению поведения программного обеспечения. Вопрос состоит в том, что часто сложно найти время для необходимого тестирования. Не меньшей проблемой является и координации в проведении тестов различными членами группы сопровождения, занимающимеся решением различных задач. Если же система выполняет критичные <для бизнеса> функции, временный вывод системы из эксплуатации (как говорят, перевод системы в offline) для выполнения тестов часто оказывается просто невозможен.
Таким образом, одним из ключевых вопросов сопровождения является организация работ по тестированию модификаций эксплуатируемых систем, вплоть до предварительного планирования и разработки регламентов, в соответствии с которыми, например, основываясь на оценке критичности запросов на изменения (как дефектов, так и важных расширений – будь то новая функциональность или необходимое расширение интеграционных возможностей), затрагиваемых модулях, персоналом сопровождения будут проводиться стандартные процедуры. К таким процедурам, наравне с журналированием запросов и проводимых работ, могут и, скорее, должны относиться: анализ влияния <изменений> (impact analysis – см. ниже), оценка рисков, тестирование (различными методами, в различном объеме), выпуск предварительных версий патчей/обновлений в ограниченное использование (если это позволяет спецификация системы), использование “клона” системы (развертывание ее на идентичном оборудовании в идентичной конфигурации) и т.п.
2.1.3 Анализ влияния (Impact analysis)
Анализ влияния описывает как проводить (в частности, с точки зрения эффективности затрат) полный анализ возможных последствий и влияний изменений, вносимых в существующую систему. Персонал сопровождения должен обладать необходимыми знаниями о специфике системы (в идеальном случае, иметь полное представление о системе на уровне ее разработчиков) – ее содержании и структуре. Инженеры используют эти знания для выполнения работ по анализу влияния, идентифицируя все системы* и программные продукты, на которые могут повлиять изменения, вносимые в обслуживаемую программную систему. При этом, должны быть определены риски, связанные с внесением обсуждаемых изменений.
* Как мы видим из описания данных работ в SWEBOK, речь идет не только о компонентах системы, но и о ее окружении, включая другие системы, функционирующие в том же операционном/системном окружении.
Запросы на изменения** (change requests - CR), иногда упоминаемые как запросы на модификацию (modification request - MR), часто также называемые отчетами о проблемах (problem report - PR), должны анализироваться и трансформироваться в термины программной системы. Эти шаги выполняются после того, как соответствующий запрос на изменение начинает обрабатываться в рамках процесса управления изменениями
или, как принято называть, конфигурационного управления
, и фиксируется в системе конфигурационного управления (см. область знаний Configuration Management).
** Обычно запросы на изменения разделяют на две категории – “пожелания” (suggestions), относящиеся к расширению системы, и “отчеты об ошибках” (defect или bug report), направляемые пользователями в службу сопровождения или инженерами по тестированию разработчикам.
Цели анализа влияния могут быть сформулированы следующим образом:
- Определение содержания изменений для задания работ по планированию и реализации
- Получение максимально возможной оценки ресурсов, необходимых для проведения соответствующих работ
- Анализ стоимости и выгоды от внесения запрошенных изменений (обычно касается пожеланий, запросов на расширение системы)
- Обсуждение сложности вопросов, связанных с внесением соответствующих изменений
Сложность решения вопроса, поставленного соответствующим запросом на изменения, часто является основным фактором определения того, когда и как будет решена проблема. Инженеры идентифицирую компоненты, в которые необходимо внести изменения. Обычно рассматривается несколько вариантов решения проблемы и вырабатывается (также, обязательно, фиксируются в соответствующей системе обработки запросов на изменения) наиболее оптимальный путь ее решения.
При этом, оптимальность пути не всегда означает наиболее ”красивое” технологическое решение. Иногда это может быть временное решение, может быть даже нарушающее архитектурные шаблоны системы, однако, обоснованное с точки зрения сроков и стоимости его реализации. В то же самое время, результаты анализа направляются разработчикам системы, обычно работающим над следующей версией, для включения соответствующего изменения уже в рамках принятого стиля кодирования, соглашений, архитектурных шаблонов и т.п. Безусловно, такой путь многим может показаться просто неэтичным, с точки зрения “настоящего” инженерного подхода. Однако, если разработчики готовят следующую версию системы, затрагивая модуль, модифицируемый службой сопровождения, с точки зрения бизнес-решений, “некрасивый”, но быстрый путь достижения требуемого поведения системы, в большинстве случаев, будет выглядеть более обоснованным, чем принятие на себя персоналом сопровождения функций разработчиков системы. Иногда, если требуемое изменение не столь критично, чтобы решение было предоставлено “вчера” (хотя пользователи, практически всегда, именно так характеризуют свои запросы в терминах приоритета), логичным выглядит откладывание проведения соответствующих модификаций и передача этих работ непосредственно разработчикам. Как это часто можно услышать – “будет доступно в следующем релизе”. Ничего не напоминает? Но, экономически, это часто бывает более чем оправдано.
Если программное обеспечение изначально разрабатывалось с учетом дальнейшей поддержки, это может существенно облегчить анализ влияний, как одной из ключевых работ по сопровождению.
2.1.4 Возможность сопровождения (Maintainability)
Возможность сопровождения или сопровождаемость программной системы определяется, например, глоссарием IEEE (стандарт 610.12-90 Standard Glossary for Software Engineering Terminology, обновление 2002 года) как легкость сопровождения, расширения, адаптации и корректировки для удовлетворения заданных требований. Стандарт ISO/IEC 9126-01 (Software Engineering – Product Quality – Part 1: Quality Model, 2001 г.) определяет возможность сопровождения как одну из характеристик качества.
Для уменьшения стоимости дальнейшего сопровождения, на протяжении всего процесса разработки необходимо специфицировать, оценивать и контролировать характеристики, влияющие на возможность сопровождения. Если такие работы проводятся регулярно, это облегчает дальнейшее сопровождение, повышая его сопровождаемость (в частности, как характеристику качества). Часто этого сложно добиться, потому, что, к сожалению, такого рода характеристики игнорируются при разработки. Разработчики заняты другими запланированными работами и также часто пренебрегают требованиями, предъявляемыми к сопровождаемости системы.
Одной из ключевых проблем сопровождения является отсутствие системной документации, мешающее формированию понимания системы и, как следствие, невозможности адекватного анализа влияния. Эта и другие проблемы могут быть решены при использовании систематического подхода к построению зрелых процессов, применению соответствующих техник и автоматизации необходимых задач по поддержке жизненного цикла с помощью специализированных инструментальных средств.
2.2.1 Согласование с организационными целями (Alignment with organizational objectivies)
Организационные цели описывают как продемонстрировать возврат инвестиций от деятельности по сопровождению программного обеспечения. Обычно, разработка ведется на проектной основе, с определенными временными и бюджетными ограничениями. Главный акцент, при этом, делается на выпуске системы, отвечающей потребностям пользователей, в заданные сроки и в рамках бюджета. В отличие от этого, сопровождение системы преследует цели максимального продления срока эксплуатации программного обеспечения. Такой подход может основываться на необходимости обновления и расширения программного обеспечения, как отклика на изменяющиеся потребности пользователей. При этом, оценка возврата инвестиций становится более сложной и приводит к формированию точки зрения старшего менеджмента, что деятельность по сопровождению потребляет значительную часть ресурсов без явно выраженной и количественно определяемой отдачи для организации.
2.2.2 Проблемы кадрового обеспечения* (Staffing)
Данная тема касается вопросов привлечения и удержания квалифицированного персонала по сопровождению. Часто, работа по сопровождению не выглядит привлекательной, инженеры по поддержке воспринимаются как специалисты “второго класса” (в SWEBOK используется устойчивое выражение “second-class citizens”), что приводит к безусловному падению духа коллектива, отвечающего за поддержку систем.
Это серьезный вызов для менеджеров, отвечающих за вопросы сопровождения и, вообще говоря, является классической задачей общего менеджмента. Решение этой задачи, в первую очередь, находится в руках старшего менеджмента, формирующего соответствующий стиль отношений между функциональными и вспомогательными подразделениями. На более высоком уровне, для организаций и бизнесов - потребителей информационных технологий, эта задача связана с внутрикорпоративными департаментами автоматизации, в целом, которые слишком часто воспринимаются только как центры затрат, а информационные технологии не рассматриваются как актив. В результате, такая позиция приводит к снижению эффективности работы подразделений автоматизации, а, следовательно, и падению качества информационного обеспечения бизнеса, что сказывается, в подавляющем большинстве случаев, и на бизнесе, как таковом.
* такой перевод, вместо просто “кадрового обеспечения”, в большей степени соответствует принятому использованию термина staffing. Часто, staffing подразумевает и высокую текучесть кадров.
2.2.3 Процесс (Process)
Процесс (в общем случае, жизненный цикл, прим. автора ) является набором работ (activities), методов, практик и, своего рода, трансформаций, которые используются людьми для разработки и сопровождения программных систем и ассоциированных с ними продуктов. На уровне процесса, деятельность по сопровождению программного обеспечения имеет очень много общего с разработкой, например, в части конфигурационного управления, являющегося критически важной составляющей обоих видов деятельности. В то же время, сопровождение включает работы, не представленные в процессе разработки (в теме 3.2 представлено описание такого рода уникальных работ). Эта деятельность требует от менеджмента специального внимания.
2.2.4 Организационные аспекты сопровождения (Organizational aspects of maintenance)
В первую очередь, организационные вопросы подразумевают какая организация будет отвечать и/или какие функции необходимо выполнять для обеспечения деятельности по сопровождению. Команда, разрабатывавшая программный продукт, далеко не всегда отвечает за его сопровождение. Это не только стандартное управленческое решение независимых поставщиков программного обеспечения, но, также, часто встречается в организациях, использующих программные продукты в целях автоматизации своих бизнес-функций.
При решении вопроса, где (кем) будут осуществляться функции по сопровождению, может быть принято решение оставить их непосредственно тем, кто разрабатывал систему (как в терминах организации/компании, так и подразумевая непосредственно коллектив разработчиков), или передать другой команде или стороне (maintaner). Часто, выбор сопровождающей организации осуществляется исходя из тех соображений, которые выглядят обоснованными для обеспечения адекватной поддержки системы и возможности ее эволюционирования для удовлетворения меняющихся потребностей пользователей. К сожалению (чего, в принципе, и следовало ожидать), универсальных подходов в решении данного вопроса, кем будет сопровождаться система – нет. Соответствующие решения принимаются в каждом конкретном случае, с учетом его специфики (case-by-case). Но, что действительно важно отметить, делегирование или назначение полномочий и ответственности по сопровождению должно быть произведено по отношению только к одной организации или лицу (менеджеру соответствующей команды поддержки). Все, так или иначе, зависит от организационной структуры организации/компании, эксплуатирующей программное обеспечение.
2.2.5 Аутсоурсинг (Outsourcing)
Заимствованный термин “аутсоурсинг” уже прижился не только в среде ИТ-менеджеров, он стал частью современного бизнеса и управленческих практик. Суть его заключается в передаче работ, в первую очередь, вспомогательных (непрофильных для организации) “на сторону”. Крупные корпорации передают в управление другим организациям целые портфели программных систем, а, иногда, и целиком всю ИТ-инфраструктуру. В то же время, существенно более часто, сопровождение передается другим организациям только для “второстепенных” программных систем (или, как минимум, не критичных для выполнения бизнес-функций), так как владельцы таких систем не желают терять контроль над ассоциированными с этими системами данными и/или функциональностью. Отмечается, что некоторые передают работы по сопровождению “в аутсоурсинг” только в тех случаях, если убеждены в стратегическом контроле над сопровождением.
Часто можно наблюдать, когда для решения вопросов сопровождения (при сохранении “стратегического контроля”), компании, для которых информационные технологии не являются профильными, но воспринимаются в качестве актива, формируют специализированные дочерние бизнес-структуры, которым и передаются функции сопровождения, а также и непосредственно разработки программных систем и, более того, поддержки и развития всей ИТ-инфраструктуры. Это делается с тем, чтобы функционируя в качестве самостоятельной бизнес-сущности, уже бывшие внутрикорпоративные подразделения автоматизации, могли обеспечить большую прозрачность финансовых потоков, затрат, связанных с информационным технологиями. Но, это тема уже относится к общим вопросам управления и, безусловно, требует самостоятельного обсуждения, в контексте, опять-таки, конкретной организации или бизнес-структуры. Однако, нельзя было не обозначить важность обсуждаемого вопроса в данном контексте, ведь именно деятельность по сопровождению часто подвигает организации-потребители ИТ к принятию столь серьезных организационных и бизнес-решений.
При этом, подчеркивает SWEBOK, контроль сложно измерить. В свою очередь, перед аутсоурсером (организацией, принимающей на себя ответственность по сопровождению) стоит серьезная проблема по определению содержания соответствующих работ, в том числе, для описания содержания соответствующего контракта. Отмечается, что около 50% сервисов, предоставляемых аутсоурсером, проводятся без соответствующего детального и однозначно интерпретируемого соглашения (service level agreement, SLA). Компании, занимающиеся аутсоурсингом, обычно затрачивают несколько месяцев на оценку программного обеспечения прежде, чем заключают соответствующий контракт. Еще один вопрос, требующий специального внимания, заключается в необходимости определения процесса и процедур передачи программного обеспечения на внешнее сопровождение.
Основные вопросы по теме:
Управленческие проблемы и причины их возникновения
Решение проблем
Методы принятия решения и их реализация
1. Управленческие проблемы и причины их возникновения
Управленческая проблема представляет собой сложный вопрос, задачу, требующую своего уяснения, изучения, оценки и решения.
Проблемы всегда имеют определенное содержание, возникают в свое время и на своем месте, вокруг них всегда есть круг лиц или организаций, их порождающих, однако предприятие не останавливается из-за этого в развитии. Меняется соотношение его внутренних переменных, изменяется внешнее окружение, и в результате, естественно, возникают сложные вопросы, которые необходимо решать.
Здесь имеется причинно-следственная связь. Например, изменились ставки налогов, устарела технология и т. д.
Чтобы уяснить причины возникновения проблем, необходим причинно-следственный анализ. В ходе его проведения можно обнаружить истинные причины, отсеять побочные, неглавные, сопутствующие, уяснить, глубоко изучить и оценить ситуацию. Тем самым будет подготовлена предпосылка к принятию необходимого решения.
Управленческие проблемы классифицируется по следующим признакам:
степень важности и срочности . Как правило, самые важные проблемы являются и наиболее срочными;
масштабы последствий , в случаях принятия или непринятия решений, и численность организаций и лиц , которых затрагивают данные проблемы;
возможность решения проблемы с наименьшими затратами и в оптимальные сроки;
степень риска , связанного с решением данной проблемы, и возможность возникновения новых проблем на этой основе;
степень структуризации и формализации , возможность выражать проблему в количественных и качественных показателях и т. д.
Кроме того, проблемы могут различаться по способам их разработки: 1) безальтернативный, когда путь решения проблем только один, других вариантов решения нет; 2) бинарный и многовариантный, когда проблему можно решить двумя и более способами; 3) в случаях, когда ни один из способов не может дать положительного ответа на вопрос, как разрешить проблему, применяют комбинационный способ. Он заключается в том, что проводится комбинирование отдельных частей и способов решения проблем, не противоречащих друг другу. В целом это основа для последующего поэтапного решения проблемы.
Отдельно рассматривается вопрос о сроках решения проблем.
Виды проблем рассматриваются по следующим критериям:
Стратегические, направленные на формирование базы стратегических данных, их уяснение, изучение, оценку и практическое использование;
Тактические, разрешение которых происходит в более короткие сроки, чем стратегические;
Долгосрочные, среднесрочные и краткосрочные, текущие;
По уровням руководства - высшего, среднего и низового звеньев управления.
Каждый менеджер в любой организации или на предприятии с первых шагов в своей деятельности сразу же встречается с массой проблем. Они могут быть маленькими и большими, разрешимыми или неразрешимыми, крайне опасными или не очень. Причина их возникновения кроется в самой работе людей. Управленческие проблемы возникают вследствие нежелательных явлений внутреннего или внешнего свойства, получения результатов работы, отличающегося от запланированного, ошибочных действий руководства и рядовых исполнителей.
К основным причинам возникновения управленческих проблем следует отнести:
Изначально ошибочные цели организации, способы и сроки их достижения;
Неверные принципы и методы деятельности работников;
Ошибочные критерии оценки возможностей предприятия и сотрудников;
Умышленные нарушения в технике, технологии, финансах, поставках и т. д.;
Изменения в политике и экономике государства;
Природные катаклизмы и стихийные бедствия (пожар, наводнение и др.).
· Введение
· Решение проблем
· Решение тактических проблем
· Текущие проблемы
· Методы принятия решений и их реализация
Введение
Как активный и мыслящий элемент системы, человек предопределяет целесообразность и организованность трудового процесса. Определяя цель и программу действий, человек, по сути, принимает решение. В более крупном производственном образовании, где задействовано уже несколько элементарных ячеек, совместный труд нескольких людей также предопределяется общей целью и программой действий. Функцию определения цели и программы действий выполняет здесь уже отдельный человек- руководитель. Это он решает, что требуется получить на выходе этой небольшой системы (цель) в качественном, количественном или стоимостном выражении. Он же определяет как этого добиться (программу действий): какие ресурсы ввести, как распределить труд между исполнителями, как организовать движение предметов труда и т.п. Затем он же организует исполнение принятого решения, осуществляет контроль, т.е. собирает информацию о том, что происходит на выходе системы, на каждом из рабочих мест, соответствуют ли действия исполнителей принятому решению. В случае отклонений он принимает решение по поводу регулирования (воздействия на вход системы или на исполнителей).Такпротекает процесс управления, который состоит из трёх взаимосвязанных фаз:
1) принятие решения как определение цели и программы действий;
2) организация исполнения;
3) сбор и обработка информации (в том числе контроль и учёт) для последующего принятия решения.
Таким образом, процесс принятия управленческого решения является важной фазой в цикле управления. По качеству и эффективности принимаемых и, что очень важно, реализуемых решений можно судить о качестве и эффективности управленческого труда.
Управленческие проблемы и их решение
Управленческая проблема представляет собой сложный вопрос, задачу, требующую своего уяснения, изучения, оценки и решения.
Проблемы всегда имеют определенное содержание, возникают в свое время и на своем месте, вокруг них всегда есть круг лиц или организаций, их порождающих, однако предприятие не останавливается из-за этого в развитии. Меняется соотношение его внутренних переменных, изменяется внешнее окружение, и в результате, естественно, возникают сложные вопросы, которые необходимо решать. Здесь имеется причинно-следственная связь. Например, изменились ставки налогов, устарела технология и т.д.
Чтобы уяснить причины возникновения проблем, необходим причинно-следственный анализ. В ходе его проведения можно обнаружить истинные причины, отсеять побочные, неглавные, сопутствующие, уяснить, глубоко изучить и оценить ситуацию. Тем самым будет подготовлена предпосылка к принятию необходимого решения.
Управленческие проблемы классифицируется по следующим признакам:
степень важности и срочности. Как правило, самые важные проблемы являются и наиболее срочными;
масштабы последствий в случаях принятия или непринятия решений и численность организаций и лиц, которых затрагивают данные проблемы;
возможность решения проблемы с наименьшими затратами и в оптимальные сроки;
степень риска, связанного с решением данной проблемы, и возможность возникновения новых проблем на этой основе;
степень структуризации и формализации, возможность выражать проблему в количественных и качественных показателях и т.д.
Кроме того, проблемы могут различаться по способам их разработки:
1) безальтернативный, когда путь решения проблем только один, других вариантов решения нет;
2) бинарный и многовариантный, когда проблему можно решить двумя и более способами;
3) в случаях, когда ни один из способов не может дать положительного ответа на вопрос, как разрешить проблему, применяют комбинационный способ. Он заключается в том, что проводится комбинирование отдельных частей и способов решения проблем, не противоречащих друг другу. В целом это основа для последующего поэтапного решения проблемы.
Отдельно рассматривается вопрос о сроках решения проблем.
Виды проблем рассматриваются по следующим критериям:
стратегические, направленные на формирование базы стратегических данных, их уяснение, изучение, оценку и практическое использование;
тактические, разрешение которых происходит в более короткие сроки, чем стратегические;
долгосрочные, среднесрочные и краткосрочные, текущие;
по уровням руководства - высшего, среднего и низового звеньев управления.
Каждый менеджер в любой организации или на предприятии с первых шагов в своей деятельности сразу же встречается с массой проблем. Они могут быть маленькими и большими, разрешимыми или неразрешимыми, крайне опасными или не очень. Причина их возникновения кроется в самой работе людей. Управленческие проблемы возникают вследствие нежелательных явлений внутреннего или внешнего свойства, получения результатов работы, отличающегося от запланированного, ошибочных действий руководства и рядовых исполнителей. К основным причинам возникновения управленческих проблем следует отнести:
изначально ошибочные цели организации, способы и сроки их достижения;
неверные принципы и методы деятельности работников;
ошибочные критерии оценки возможностей предприятия и сотрудников;
умышленные нарушения в технике, технологии, финансах, поставках и т.д.;
изменения в политике и экономике государства;
природные катаклизмы и стихийные бедствия (пожар, наводнение и др.).
Решение проблем
Решение - это волевое воздействие человека на объект управления для разрешения проблемы, выбор альтернативы для достижения поставленной цели.Виды решений, как правило, совпадают с видами проблем. Если проблема носит стратегический характер, то и решение должно быть стратегическим, если проблема текущая, краткосрочная, то и решение должно быть аналогичным.
Решение стратегических проблем относится к разряду инициативных, идущих от высшего руководства к исполнителям низших звеньев управления. В этом случае высшее руководство берет на себя инициативу и ответственность за принятые решения стратегического характера. Примером может служить направление инвестиций (капиталовложений) на перспективное развитие производства нового вида изделий, решение о расширении производства или, напротив, о свертывании дел и т.д.
Решение тактических проблем - это дело средних звеньев руководства; на основе предписаний «сверху» они планируют решения проблем в среднесрочных планах и выполняют краткосрочные задачи. Низовые звенья управления решают проблемы исходя из устных распоряжений, указаний или письменных приказов.
Текущие проблемы каждодневного характера, так называемая рутинная работа, занимают основное время низовых звеньев управления. От решения данных проблем среднее звено руководства и особенно высшие руководители по возможности должны быть освобождены.
Решение проблем классифицируется по ряду признаков: степень обязательности исполнения; функциональное назначение; способ принятия; сфера реализации.
По степени обязательности решения могут быть: директивными - они принимаются высшим руководством и обязательны к исполнению для нижестоящих управленческих структур. Рекомендательные решения разрабатываются совещательными органами. Их исполнение желательно, но не обязательно. Ориентирующие решения принимаются руководством для координации работы нижестоящих управленческих структур, которые действуют автономно.
По функциональному назначению выделяют организационные, координирующие, регулирующие, активизирующие и контролирующие ход выполнения решения. Например, предписывающие способ действия и методы решения проблем; распределяющие работу между исполнителями, по проведению контроля, проверок, подготовке нормативных документов и др.
По способу принятия выделяются решения выборочные и систематические. К первым относятся решения одного или нескольких вопросов данной проблемы, ко вторым - решения, охватывающие проблему целиком во всей ее многосложности и взаимосвязи.
По сфере реализации решения связаны с той областью деятельности, которой порождена проблема и от решения которой зависит Дальнейший ход дела в данной сфере. Это может быть производство, финансы, сбыт, поставки, кадры, НИОКР и т.д.
Решения классифицируются также на принятые единолично или коллективно, на общие и специальные, на запрограммированные и незапрограммированные, на закрытые и для общего пользования и т.д.
Принятие решений всегда сопряжено с определенной степенью риска. Работа в условиях неопределенности, нестабильности, постоянно меняющейся обстановки считается нормальной для менеджера. Поэтому он действует на основе, имеющейся в его распоряжении информации, которая не всегда соответствует действительному положению дел. В таких условиях он вынужден действовать наудачу, в надежде на благоприятный исход, ввиду чего возрастает угроза ухудшения деятельности руководимого им предприятия, полной или частичной утраты материальных, финансовых или людских резервов и ресурсов, а также потери имиджа.
В практике менеджмента разработаны несколько вариантов комплексной оценки риска в ходе решения проблем. Правилом здесь является то, что общая сумма риска равна сумме частных рисков, а частный риск равен нормативной минимальной ставке с поправкой на каждый элемент риска (скидкой или добавкой). С точки зрения риска, критерий может быть таким: «Рассчитывай на худшее» - Вальда; «Рассчитывай на лучшее» - Сэвиджа, «Ориентируйся на лучшее» - Лапласа, «Компромисс» - Гурвица.
©2015-2019 сайт
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2018-01-08
Loading...