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

Я никогда не говорю: «Мне нужно, чтобы вы это сделали».
Я говорю: «Мне интересно, сумеете ли вы это сделать»

Генри Форд

кому: собственникам, топ-менеджерам, руководителям

Проблема «заколдованного круга» воспитательных бесед

Руководители нередко сталкиваются с ситуацией, когда «наказания» и «уговоры» в отношении подчинённых бесполезны, и они продолжают вести себя по-старому. Какие же самые распространённые методы воздействия на поведение сотрудников?

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

У этих способов одинаковые степень результативности и время действия, - эффект от их применения утрачивается через 1-3 дня , а дальше всё возвращается «на круги своя»: люди снова опаздывают на работу, задачи не выполняются вовремя, «внезапно» повторяется форс-мажор, возникавший уже 7 раз за этот месяц. Есть ли выход из заколдованного круга?

Краткая суть технологии в том, что мы по определённому алгоритму разбираем с подчинёнными возникающие управленческие ситуации с фиксацией всей информации в электронное личное дело сотрудника (неофициальное). На алгоритме я подробно остановлюсь в следующей статье. Уже слышу голоса “Отставить словоблудство! Дайте нам его сюда немедленно! Хватит теории, сколько можно?” С радостью, но прыжок “с головой” в алгоритм едва ли будет полезен, если мы ещё не определились даже, что мы будем понимать под управленческой ситуацией.

Что такое управленческая ситуация и «с чем её едят»?

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

Основные типы управленческих ситуаций

• Нарушение сотрудником парадигм регулярного менеджмента Александра Фридмана ().
• Нарушение подчинённым субординации, регламентов и правил.
• Возникшая неудача, удача.
• Появление новых рисков, непредвиденных убытков и так далее.

Примеры управленческих ситуаций

Какие могут быть реальные управленческие ситуации? Классический пример: сотрудник получил распоряжение, но оно не было выполнено (например, организовать встречу с Клиентом). И далее руководителю предоставляется тысяча и одно оправдание, “почему задача не была выполнена”. Причины могу называться разные: «Не было ресурсов», или «я забыл», или «я не посчитал это дело важным, в это время позвонили другие» и т.д.

Ещё один пример. Порученное вами задание может быть выполнено со спорными параметрами . Например, вы рассчитывали, что сотрудник выставляет счет за тридцать минут, а он почему-то тратит на это три часа.

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

Причины подчинёнными могут называться разные: «Не было ресурсов», или «я забыл», или «я не посчитал это дело важным, в это время позвонили другие» и т.д.

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

Казалось бы, действительно, нет риска для власти и авторитета руководителя. Значит ситуацию нельзя отнести к управленческой? Почти угадали. Данное условие выполняется только в случае действий сотрудника по алгоритму, который был утверждён вами. Если же подчинённый прибегает “без спроса” с детализированным анализом, который Вы ему не поручали, или о необходимости разработать который он не спрашивал, - этот факт и будет предметом разбираемой управленческой ситуации.

Время против «торопышек»

Если, господа, у вас есть время постоянно разбирать последствия бездействия руководителя в деле управления своими подчинёнными, не проще ли всё же потратить часть этого времени на предупреждение этих самых “бесконечных форс-мажоров” ? Да, время на управление действительно требуется. Но если его правильно инвестировать, итоговый выигрыш во времени и прибыли будет значительным!

Видео-версия статьи “Управленческие ситуации: теория”

Видео-урок: Введение в разбор управленческих ситуаций

Аксиомы управленческих ситуаций

Прежде чем разобраться, какие неприятные “сюрпризы” готовят нам-руководителям поверхностно “зарытые” управленческие ситуации, предлагаю определиться с базовыми аксиомами (специально для двоечников: аксиома - утверждение, принимаемое без доказательства)

Аксиома 1. Вне зависимости от ситуации именно руководитель несёт ответственность за действия подчинённых

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

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

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

Если вы считаете как-то иначе, то рекомендую ознакомиться с моей статьёй “Ответственность руководителя за действия подчинённых: «Почему же ты смотришь на соломинку в глазу твоего брата, а в своем глазу не замечаешь бревна?» ”

Аксиома 2. За разбором каждой ситуации должен следовать "апгрейд"

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

Следствие: ситуация разобрана неэффективно, если по итогам её разбора польза отсутствует хотя бы для одного из трёх элементов, то есть нет пользы для подчиненного, или нет пользы для руководителя и/или нет пользы для бизнеса. Обратное следствие: из присутствия “трёх элементов” не следует, что ситуация была разобрана до конца.

Основные цели разбора управленческих ситуаций: а зачем вообще что-либо разбирать?

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

Негативное последствие от отсутствия разбора управленческих ситуаций №1. Передвижение области ближайшего развития сотрудника

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

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

Пример «волшебное превращение времени»: как 5 минут становятся 1 часом

Иван Петрович знает, что в 10 часов утра он должен быть на рабочем месте. Первый раз он опаздывает на 5 минут - нет реакции. Второй раз - снова на пять и т.д. На седьмой раз опаздывает уже на 10 минут.

Отсутствие должного ответа со стороны руководителя приводит к тому, что через 2-3 месяца Иван Петрович будет считать за норму приходить на работу в интервале с 10 до 11. Теперь, чтобы его переучить, напрягутся (и, скорее всего, безрезультатно) в едином порыве все HR-специалисты компании.

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

Негативное последствие №2. Передвижение области ближайшего развития других сотрудников

За примерами далеко ходить не надо. Коллеги смотрят: Иван Петрович опаздывает на тридцать минут и задают себе логичные вопросы: “Чем мы хуже него? Почему мы должны приходить вовремя?”

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

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

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

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

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

Негативное последствие №4. Утрата доверия к подчинённому со стороны руководителя и, как следствие, уменьшение эффективности конкретной связки "руководитель-подчинённый"

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

Хочу Вам сказать, что деловые-профессиональные отношения между сотрудником и подчиненным выгодны компании. Почему именно такие, а не дружеские? Скажу несколько слов о дружбе начальников и подчинённых.

Если друг оказался вдруг… подчинённым

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

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

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

Роль «руководитель-подчинённый» всегда подразумевает наличие «конфликта»

Сколько продлится дружба в таком противостоянии? До первого случая. Подчинённый обидится, - не ожидал ведь такого от друга! Может уйти, а может заняться саботажем. А если бы был просто приятелем, - то остался бы хорошим сотрудником.

А что, если Вы - собственник компании и замечаете подозрительно тёплые дружеские или приятельские отношения по линии “руководитель-подчинённый” у кого-то из своих сотрудников? Имеет смысл внимательно присмотреться. Возможно, вам повезло, и перед вашим взором редкий случай, когда два человека умеют хорошо играть свои роли (он настолько редкий, что это крайне маловероятно). А если не повезло?

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

Многие подчинённые целенаправленно пользуются ситуацией в своих интересах, “давя” на дружбу

Что делать в случае, когда руководитель “покрывает” неэффективность своих подчинённых? Ситуация здесь рассматривается как проступок со стороны руководителя.

Но есть один “скользкий” момент. Должен ли начальник защищать своих подчиненных? Да, должен в ключе, когда он берёт ответственность за их поведение, действия и бездействия лично на себя . При этом незамедлительно принимает меры, чтобы такой ситуации больше не повторилось. А вот если меры не приняты, и/или руководитель не способен их принять, то такая защита уже сродни вражеской диверсии против компании и собственников.

Управленческая ситуация “Накажи того, кто готовил отчёт!” от Евгения Севастьянова

А как бы поступили Вы в данной ситуации на месте руководителя отдела? (подробный вопрос внизу под текстом)

“Сотрудник отдела логистики Пётр должен был подготовить отчёт за квартал. Срок подачи отчёта истёк, а руководитель отдела логистики Дмитрий должен был его переслать топ-менеджерам компании. Генеральный директор, который затребовал отчёт знает, что его готовит Пётр, а начальник отдела Дмитрий лишь пересылает. Генеральный директор вызывает в свой кабинет начальника отдела Дмитрия для разбора ситуации с отчётом и начинает разговор с фразы: “Накажи своего сотрудника, который готовил отчёт, опять я его не получил вовремя! Теперь перейдём к остальным делам. Слушаю тебя.”

Внимание, вопрос. Нужно ли на эту фразу как-то реагировать начальнику отдела или перейти к остальным делам? Если нужно, то напишите кратко, что он по вашему мнению должен сказать генеральному директору.

Чтобы увидеть мой вариант ответа на этот вопрос:
1) Напишите свою версию в комментарии к статье в самом низу, как на скриншоте: https://yadi.sk/i/QHQ2_R4oiWjkV
2) Отправьте запрос на получение моей версии ответа через мои личные аккаунты в социальных сетях:

Положительное следствие от разбора управленческой ситуации №1. Увеличение эффективности труда сотрудников за счет корректировки их области ближайшего развития

Что же всё-таки такое область ближайшего развития? Очень хорошее определение даётся в аудио-курсе «Персональное управленческое искусство» Владимира Константиновича Тарасова. Я кратко своими словами расскажу суть. Представим себе: есть лестница, и человек может перейти через одну ступеньку, а может через две перескочить. А вот через три уже сложно. Через четыре – невозможно.

Когда мы даем какое-то поручение сотруднику, мы должны оценить, есть ли у человека вообще компетенция для его реализации, или он никогда не сталкивался с подобными заданиями. Может ли он выполнить работу эффективно? Какая степень поддержки ему потребуется при выполнении задачи? Мы должны об этом задумываться, как руководители, это наша задача.

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

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

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

Тот, кто выполняет правила в офисе, с большей вероятностью выполняет их “в полях”.

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

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

Когда руководитель обращает внимание на мелочи, как правило, уже значительно реже дело доходит до каких-то крупных потерь. Когда у нас есть крупные потери? В случае запущенной ситуации. Редко бывает, что мы тут все спокойно сидели и всё правильно делали, и внезапно словно “ураган налетел”.

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

Сотрудник с такой “прививкой”, заметив первоначальные признаки приближающихся проблем (обычно выражены в мелочах), начинает уже их отрабатывать, а не ждет, пока она превратится в “фатальные последствия”.

Положительное следствие №3. Накопление "общего" опыта для компании, расширение "узких мест". Развитие базы знаний и технологий работы

Да, разбор управленческих ситуаций, помогает находить “бреши” в существующих регламентах и технологиях вашей компании. Как это делать, я расскажу в статье с пошаговым алгоритмом разбора управленческой ситуации (верно, будет ещё и практика!)

Положительное следствие №4. Возможность сбора фактов о работе человека, для последующей формализованной оценки и понимания динамики "развития" сотрудника

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

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

В каких ещё случаях начальнику потребуются факты? Смотрит он на человека и спрашиваем сам себя: “А вообще полезен этот сотрудник для компании или нет” ?

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

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

Положительное следствие №5. Создание "проблемы" подчинённому, которая вынуждает его развивать и совершенствовать свои профессиональные навыки

Некоторые скажут: “Удивительно, как этот пункт попал в положительные следствия!” На самом деле всё достаточно просто. Большинство людей начинают развиваться и меняться только тогда, когда в случае другого поведения (такое как нежелание профессионально расти и совершенствоваться) корпоративная система управления автоматически формируют у них проблему.

Приведу пример, когда одна и та же денежная “мотивация” в одном случае создаёт искомую “проблему” у сотрудника, а в другом случае - бесполезна.

Для женщины, у которой муж получает миллион рублей в месяц и делит свою зарплату с ней поровну, денежная мотивация в пять тысяч рублей не будет работать. У неё “нет проблемы” с отсутствием дополнительных 5.000 рублей.

Однако всё меняется, если муж миллион не приносит, или приносит, но на личные расходы выделяет жене только 10.000 рублей и требует детального отчёта по остальным потраченным деньгам. Вот тогда пять тысяч рублей являются мотивацией (женщина видит проблему в их неполучении). И поэтому она старается, эти деньги мотивируют её на выполнение желаемых действий.

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

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

Промежуточные итоги и “В следующих сериях…”

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

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

Необходимость принятия того или иного управленческого решения возникает при следующих условиях:

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

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

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

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

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

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

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

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

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

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

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

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

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

Существует два способа рассмотрения проблемы.

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

В зависимости от отношения к проблеме выделяют три вида руководителей:

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

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

Организация как объект управления

3.1 Управленческие проблемы и их решение

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

Управленческие проблемы классифицируются по следующим признакам:

Степень важности и прочности. Как правило, самые важные проблемы являются и наиболее срочными;

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

Возможность решения проблемы с наименьшими затратами и в оптимальные сроки;

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

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

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

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

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

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

Анализ удовлетворенности трудом в коллективе. Проведение совещания

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

Гендерная дискриминация в трудовой сфере

Конфликтогенность организационных изменений

1. Определите проблему в категориях целей, а не решений. 2. После того, как проблеме определена, определите решения, которые приемлемы для обеих сторон. 3. Сосредоточьте внимание на проблеме, а не на личных качествах другой стороны. 4...

Организация работы планово-экономического отдела ООО "Заря" Каслинского района Челябинской области

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

Особенности вознаграждения работников в организации

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

Особенности коммуникативного поведения в современных организациях

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

Почему я выбрал профессию менеджера?

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

Проектирование государственного и корпоративного налогового менеджмента

Конституционное право на жилище затрагивает основу жизни человека...

Промышленная революция и проблема подготовки персонала

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

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

Разработка управленческого решения в условиях мебельной фабрики "Герцог"

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

Системный анализ проблемы внедрения инноваций

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

Стратегический план развития ОАО "ЧЭСК"

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

Управленческие решения в процессе менеджмента

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

Cтраница 1

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

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

В таком сегменте особенно важны управленческие вопросы по отношению с непосредственным руководителем.  

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

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

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

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

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

Итого необходимые расходы составили в планируемом году 1 113 тыс. руб. Предполагаемый дефицит денежных средств на расчетном счете в конце периода составит по расчетам 168 тыс. руб. Финансовому менеджеру в данном случае необходимо рассмотреть вопросы принятия управленческих вопросов о сокращении дебиторской задолженности и поиску путей увеличения коммерческого кредита для предприятий.  

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

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

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

Даже в случаях переписки между частными лицами и учреждением ее содержание касается управленческих вопросов.  

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

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

Технические вопросы (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). Компании, занимающиеся аутсоурсингом, обычно затрачивают несколько месяцев на оценку программного обеспечения прежде, чем заключают соответствующий контракт. Еще один вопрос, требующий специального внимания, заключается в необходимости определения процесса и процедур передачи программного обеспечения на внешнее сопровождение.