Необходимость принятия того или иного управленческого решения возникает при следующих условиях:
- существует разрыв между желаемым и существующим уровнями развития организации, т.е. определенное несоответствие деятельности организации ее целям;
- разрыв достаточно большой, чтобы быть замеченным, а следовательно, заслуживает внимания;
- лицо, принимающее решение, стремится сократить этот разрыв;
- лицо, принимающее решение, уверено в возможности сокращения разрыва.
Проблема - один из основных элементов процесса управления, выявление проблемы и описание проблемной ситуации - первый этап процесса принятия управленческих решений.
В компании выявление и определение проблемы, требующей решения, осуществляется, как правило, в следующих случаях:
- эффективность фирмы или подразделения снижается по сравнению с прошлым периодом;
- результаты не соответствуют запланированным целям;
- результаты сравнений со сходными предприятиями оказываются неудовлетворительными.
Совокупность факторов и условий, вызывающих появление той или иной проблемы, называется ситуацией, а рассмотрение проблемы с учетом воздействующих на нее ситуационных факторов позволяет описать проблемную ситуацию. Это описание состоит из сущности и содержания проблемы, места и времени ее возникновения, а также границ распространения ее воздействия на работу организации. К появлению проблемы могут привести как внутренние, так и внешние факторы.
Внутренние факторы в наибольшей мере зависят от самого предприятия, хотя могут быть частично связаны и с внешней средой. К ним относят:
- стратегию и цели развития;
- состояние портфеля заказов;
- состояние производственных мощностей;
- организационную структуру;
- организационную культуру;
- финансовые и трудовые ресурсы и др.
Внутренние факторы формируют предприятие как систему, поэтому изменение одного или нескольких факторов влечет за собой изменение свойств системы как целостного образования.
Внешние факторы формируют среду, в которой работает организация, и в гораздо меньшей степени поддаются воздействию с ее стороны. Внешняя среда организации, как деловая, так и макросреда, в современных условиях характеризуется высокой степенью сложности, динамичности и неопределенности, что существенно затрудняет учет ее факторов при разработке и принятии управленческих решений.
Выявление и описание проблемы - первый шаг на пути ее решения. Но если проблема сложна и охватила большое число подразделений или всю организацию, перед руководителем встает нелегкая задача по диагностированию сложной проблемы. На этом этапе очень важно осознать и установить симптомы затруднений или имеющихся возможностей. Наиболее общие симптомы болезни организации:
- низкая прибыль;
- низкая производительность;
- низкий сбыт;
- низкое качество;
- высокие издержки;
- высокая текучесть кадров;
- многочисленные конфликты и т.д.
Выявление симптомов помогает определить проблему в общем виде, при этом необходимо помнить, что обычно несколько симптомов дополняют друг друга, например, когда высокие издержки имеются одновременно с низкой прибылью.
Диагностика проблемы во многом зависит от личности руководителя, от его знаний, опыта и компетентности, деловой интуиции и умения видеть проблему, когда она еще находится в стадии зарождения.
Существует два способа рассмотрения проблемы.
- 1. Проблемой считается ситуация, когда поставленные цели не достигнуты, имеются отклонения от запланированных показателей. За этим должна последовать реакция руководителя в виде управленческих решений, и такое управление называют реактивным управлением.
- 2. Как проблему можно рассматривать потенциальную возможность проблемной ситуации. Например, если руководитель активно ищет пути повышения эффективности какого-то подразделения, даже если дела идут хорошо, это превентивное , или упреждающее , управление.
В зависимости от отношения к проблеме выделяют три вида руководителей:
- менеджер, избегающий проблем, просто игнорирует информацию, указывающую на наличие проблем;
- менеджер, решающий проблемы, стремится решать проблемы по мере их возникновения;
- менеджер, выявляющий проблемы, активно ищет проблемы, требующие решения, и новые возможности их решения.
Для диагностики проблемы необходимо собрать и проанализировать требующуюся внешнюю и внутреннюю информацию. Внешнюю информацию можно собрать, используя данные анализа рынка. Внутреннюю информацию обычно собирают, используя формальные методы, такие как данные финансовых отчетов, интервьюирование и опросы работников, приглашение консультантов по управлению и т.д. Информацию можно собирать и неформально, ведя частные беседы о сложившейся ситуации и делая личные наблюдения.
Представление о решении руководителя
Повседневная деятельность руководителя связана с принятием решений. Не каждое решение руководителя можно назвать управленческим. Управленческое решение носит решающий характер в судьбе предприятия. Решения руководителя можно разделить на несколько групп. Рассмотрим их более подробно.
Виды управленческих решений
- Спонтанные решения
- Запланированные решения
- Повседневные решения
- Управленческие решения
Особенности управленческих решений
- Сложность решения
- Высокая мотивация к исполнению
- Затруднения в контроле
- Высокий риск
- Непредсказуемость последствий
- Большие ресурсные затраты со стороны предприятия
- Длительность исполнения
Замечание 1
Особенности управленческих решений определяют проблемы, с которыми придется столкнуться руководителю в процессе их внедрения. Существует ряд признаков, по которым может классифицироваться та или иная группа проблем. Рассмотрим данные признаки более подробно.
Признаки управленческих проблем
- Степень актуальности и неотложности
- Масштабы нанесенного урона
- Уровень минимизации ущерба
- Рисковая активность
- Формальные признаки
Управленческое решение связано с проблемой в том случае, если руководитель отмечает все признаки из вышеназванного списка. Степень актуальности проблемы определяет ее срочность. Есть проблемы, решение которых нет возможности отложить. Однако, существуют проблемы, которые могут подождать оптимального управленческого решения. Они не срочные. Уровень минимизации ущерба также определяет решение руководителя. Если ущерб от проблемы минимален, то руководитель может выбрать любую альтернативу. Если ущерб разрушителен или катастрофичен, то руководителю понадобится время для того, чтобы найти оптимальное решение.
Рисковая активность играет не менее важную роль, чем другие признаки. Если степень риска в принятии решения ощутима, то руководитель, скорее всего, откажется от такого решения в пользу менее рискованного. Решения с высокой степенью риска отличаются существенным доходом. Формальные признаки в принятии решения возникают в том случае, если один из контрагентов является государственной структурой.
Предприниматели, осуществляющие деятельность с государственными структурами сталкиваются с большим количеством формальных требований. Получается, что при такой формальной нагрузке на предпринимателя проще отказаться от такого сотрудничества, чем соблюдать все завышенные требования. Таким образом, для государственных заказчиков выбор товара или услуги существенно сужается. Исключается фактор здоровой конкуренции.
Руководители предприятий отказываются от такого сотрудничества в пользу коммерческих организации, требования которых более адекватны. Руководители согласны даже потерять часть возможной прибыли, чтобы облегчить выполнение контракта.
Проблемы управленческих решений
- Неверная целевая установка
- Ошибка в методологии организации
- Неверные действия сотрудников
- Ошибка руководителя в управлении
- Целенаправленное вредительство
- Изменение социально – экономической системы
- Внешние факторы, не поддающиеся контролю
- Изменение законодательной системы
- Изменение политического строя
- Природные и техногенные явления
Замечание 2
Проблемы, связанные с управленческими решениями, достаточно обширны. Часть из них не поддается контролю руководителя. Их влияние существенно. Руководителю остается лишь минимизировать их последствия или найти альтернативный вариант. Другие проблемы можно отнести к разряду внутренних. Они подконтрольны руководителю. Снизить влияние внутренних проблем может менеджер.
Лекция 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. Что такое система? Приведите примеры.
- 2. Что такое эмерджентность (системный эффект)?
- 3. Охарактеризуйте строительство как систему.
- 4. Какие элементы вы включили бы в цикл управления?
- 5. Назовите некоторые принципы современного управления.
- 6. Назовите некоторые функции управления.
- 7. Какие вы знаете методы управления на отдельных фазах управленческого цикла?
- См. «Экономика строительства».
- Подробнее см. гл. 42 учебника «Экономика строительства».
