Кадровый советник (Тула) рекомендует прочитать:
Большинство руководителей хотят, чтобы их сотрудники, когда речь идет о принятии решений и действиях, делали больше сами, были более активны, а не ждали, как обычно, указаний сверху. Если вы относитесь именно к таким топ-менеджерам, используйте модель принятия решений, построенную по принципу дерева - простой инструмент, который основан на четырех частях растущего дерева.
У этой модели есть два преимущества в применении на практике, пишет CIO.com. Во-первых, люди могут принимать решения в рамках своей должности и обязанностей. Во-вторых, с помощью этой модели можно объяснить всем, "кто и за что ответственен", и кто какие имеет полномочия, чтобы принимать те или иные решения.
Другая модель принятия решений называется RACI, и расшифровывается она как "ответственный", "отвечающий за свои действия", "проконсультированный" и "информированный". Если речь идет о решениях, принимаемых в отношении процессов, то эта схема будет весьма полезна. Но если говорить о решениях в отношении людей, то здесь лучше использовать другую модель.
Модель, основанная на типах принимаемых решений
Метафорически эту модель можно представить в виде дерева, у которого есть корни, служащие его опорой, ствол, который его поддерживает, ветви, являющиеся дополнительными структурами, и листья на этих ветвях. Итак, у нас есть корни, ствол, ветви и листья.Что касается воздействия, то если дерево теряет свои листья, то общее воздействие, как правило, будет незначительным. Итак, подумайте, какие решения или выбор можно приравнять к листьям с дерева, то есть если кто-то принимает решение, которое либо неправильно, либо недостаточно оптимально, то воздействие от него будет незначительным или нейтральным.
Дерево зачастую может терять много веток, что будет иметь небольшое воздействие на него в целом. Есть ствол, на котором могут быть, вероятно, и главные ветки. Если основная ветка расщепится на части или то же самое случится со стволом, то это будет иметь катастрофические последствия для самого дерева. И, наконец, есть корни, которые для дерева являются своего рода якорем. Все, что подвергает риску целостность корней, приводи к гибели всего дерева.
Если говорить о практическом применении, то сначала следует изучить должности или обязанности своих сотрудников и определить, кто из них занимается безопасностью, инфраструктурой, приложениями и т.д. Внутри каждой из этих областей принимаются основополагающие решения, а это значит, что это "корни", и ошибки здесь быть не может. Затем идет "ствол" и главные решения-"ветки", где можно допустить одну или две ошибки, но их влияние может оказаться довольно серьезным и для восстановления потребуется много времени.
Затем идут решения, которые относятся к обычным "ветвям", и здесь людям можно предоставить больше свободы выбора. И, наконец, решения-"листья", о которых вам даже не надо знать.
О решениях, которые принимаются на уровне ветвей, возможно, вы и захотите узнать, но одобрять их от вас не требуется. О "стволовых" решениях надо обязательно знать и согласовывать их, но много времени для их обдумывания, скорее всего, не потребуется. Так называемые "корневые" решения - это решения, которые следует принимать самому руководителю, или в обдумывании и обсуждении которых ему обязательно стоит участвовать.
Влияние решений различных уровней
Это простой способ взглянуть на все виды решений, которые каждый из сотрудников может принять, основываясь на уровне воздействия принятого решения. Еще один момент, которые необходимо учитывать - это простота, с которой подобные решения могут быть пересмотрены или даже полностью изменены.
Решения, которые принимаются на уровне "листьев", как правило, довольно легко пересматриваются, потому что их влияние относительно слабо. Решения-"ветви", знать о которых надо, но согласовывать не обязательно, тоже могут быть пересмотрены и изменены.
Например, это может быть принятие решения на внутреннем совещании о разработке программы или назначении на какую-то функциональную должность. Большинство решений такого типа, как правило, принимаются внутри группы коллег. Если вы узнали об этих решениях через пару дней, и у вас возник вопрос относительно принятия такого решения, будет несложно снова собрать группу и еще раз изучить данную тему и, возможно, изменить вынесенное решение.
Другой вариант - это когда ваши сотрудники работают вне ИТ-организации, возможно, даже с руководителями из коммерческой структуры компании. Если вы узнали о принятом решении несколько дней спустя, то пересмотреть его будет гораздо сложнее - все зависит от прочности взаимоотношений с этими коллегами, а также от того, принял ли коммерческий отдел какие-то действия после того, как решение уже было принято.
| OZON.ru - Ауди-Книги | Купить Бизнес-книги |
Решения или должности, принимаемые вне организации, с другими ключевыми участниками, также будут считаться основными решениями. Долгосрочные контракты, основные приобретения, стратегические обязательства - все это примеры "коренных" решений, которые, возможно, вы стремитесь принимать сами.
Согласование принятых решений, политика уведомления
Когда речь идет о решениях уровня "ветвей", согласовывать их не требуется, но знать о том, что они принимаются, надо обязательно, а вашим сотрудникам следует убедиться, что вы в курсе. Это очень важный контрольный момент.
Электронные сообщения от сотрудников о принятых в отделе решениях могут легко затеряться в кипе других писем, и руководитель может вовремя их не увидеть. Поэтому необходимо сразу же отправить запрос на подтверждение прочтения, или отметить письмо как приоритетное, или позвонить в офис к руководству и сообщить, что вы отправили им подробное письмо с описанием недавно принятого решения, и вы хотите, чтобы они просмотрели его и, при необходимости, задали свои вопросы или оставили комментарии до того, как решение вступит в действие.
Если вы решили использовать в работе подобную модель, то следующим вашим шагом станет вовлечение сотрудников в ее интерпретирование и адаптацию к рабочей среде. Сначала вы можете попросить своих непосредственных подчиненных определить, каковы, по их мнению, четыре разных уровня решений, которые они принимают, включая примеры. Вы вместе начинаете изучать, что собой представляет модель, и можете, при необходимости, сообща проводить какие-то изменения.
Так вы получите исходную схему, внутри которой и будете работать. Но не забудьте, что ее проработка и превращение в эффективную схему - процесс итеративный, и что люди будут интерпретировать вещи по-разному и могут сделать какие-то ошибки.
Например, кто-то из ваших сотрудников принимает решение, и все считают, что это решение-"лист", поэтому вам не сообщают. Вы узнаете об этом через несколько дней и говорите, что вообще-то хотели бы знать об этом. Ваш коллега начинает объяснять, что по его мнению, это было решение нижнего уровня, потому что…. А вы, в свою очередь, стараетесь объяснить ему, что вашего согласия действительно здесь не требовалось, но вы бы хотели быть в курсе и как можно оперативнее, и почему. Таким образом, вы входите в этот процесс, узнаете друг друга лучше, и пытаетесь понять, что эти решения на самом деле значат. Такое общение может стать своего рода коммуникативной структурой для совещаний в вашем отделе. Так проще определить, какой информацией необходимо поделиться на этих совещаниях, и в какие проблемы и решения следует вовлечь других членов команды.
Решения, которые необходимо принять коллективно, - это основные решения ("стволы"). Решения, которые можно не принимать коллегиально, но все должны о них знать, называются решения-"ветви". А решения низшего уровня на таких совещаниях могут не всплыть вообще, поскольку они являются ежедневными оперативными решениями, принимаемыми внутри каждого подразделения.
Возьмем в качестве примера ИТ-операции: стандарты, как правило, бывают либо коренными, либо основными ("несущими"). Все ваши подчиненные должны быть вовлечены в процесс принятия решений, потому что установка стандартов затрагивает абсолютно всех на фундаментальном уровне.
В то время как выбор продукта, так как он основывается на этих стандартах, может считаться решением среднего уровня - "ветвью". Все должны знать о нем, но необязательно участвовать в его одобрении или принятии решения, пока это не станет инструментом, который будет использоваться во всех отделах.
Примером может служить разработка ИТ-приложений: если вы приобретаете инструментарий для технического обслуживания и разработки исходной программы, то одобрения коллег, скорее всего, получать не надо. Но если вы выбираете инструмент, который будет использоваться для мониторинга рабочего процесса, и хотите, чтобы в каждом отделе использовался один и тот же инструмент, тогда это будет основным решением, которое должны будут одобрить все сотрудники.
И хотя большинство примеров и обсуждений, в первую очередь, относятся к руководству ИТ-организации, такая модель может использоваться на любом уровне в организации. Руководители групп на любом уровне могут определить собственный тип принятия решений и вместе с членами группы договориться, кто за какое решение будет отвечать, и дать им возможность расширить круг принимаемых ими решений.
Источник: @Astera
