#БорьбаСТекучкойПерсонала #СоветыБывалогоУправленца

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

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

Чтобы это работало лучше можно при приеме персонала отдавать предпочтения людям с повышенной тревожностью.

Совет 2: лучшее средство удержания - это деньги. Что можно сделать для повышения значимости денег в решениях сотрудников без увеличения оплаты:
 
1. Удлинить сроки траншей за достижения. Например, вознаграждение за успешные проекты выплачивать только после того, как продукты проектов начнут приносить результаты.
 
2. Выдавайте ссуды сотрудникам на долгие сроки и в размерах, которые они не смогут досрочно погасить при их текущей оплате.
 
3. Строить систему оплаты по аналогии с системами лояльности клиентов, т.е. чтобы получать большую оплату, сначала нужно пройти через получение небольшой. Повышение должно наступать обязательно (за выслугу), но усилия, затраченные на переход должны быть значимыми на столько, на сколько будет жалко усилия затраченные на это.

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

Оценка 10/10
Сложность: от начального уровня

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

Книга дает минимально необходимый набор инструменты для успешной и рациональной деятельности на базовом уровне управления - управлении исполнением работами конечных исполнителей. Каждый руководитель в "вертикали управления" в компании имеет своих непосредственных подчиненных, поэтому владение этими базовыми инструментами must have для всех руководителей.

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

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

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

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

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

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

Так при чем тут "культурный контракт"? Все просто, при приеме каждого сотрудника моя первая беседа с ним была на основе тезисов:

оригинальное название Knowledge Management Is Not Just About Document Repositories

автор  Stuart Rance

дата публикации 23.7.14

Достоинства: лаконичность, простота, рациональность взгляда.

Недостатки: слишком кратко. 

Уровень - ликбез

Оценка 8/10

Это продолжение публикации переводов заметок Стюарта Рейнса (одного из авторов ITIL) с блога SysАid. Почему именно он? Мне интересен его немного отличный от общепринятого взгляд на привычные процессы. Он всегда за упрощение и сохранение сути. Надеюсь Вы разделите этот интерес. 

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

Приятного и полезного чтения….

Оригинальное название: How to Make Your ITSM Processes Work for You

Автор Stuart Rance, дата публикации 15.01.2019

Достоинства:
- описана вполне разумная и привлекательная идея
- простота текста
- доходчивые примеры

Недостатки:
- идея привлекательная, только не рассказывается, как ее реализовывать в жизни

Сложность - базовая
Оценка 8/10

Оригинальное название Defining Metrics for the Service Desk

Автор  Stuart Rance

Дата публикации 3.5.15

Достоинства: подробно рассмотрены 

- понятие целей (objectives) и критических факторов их достижения (CSFs) и их отличие от ключевых показателей (KPIs)

- для чего использовать KPIs и почему в отчетности фокусироваться на целях и CSFs 

Недостатки - слишком компактно. 

Уровень - базовый

Оценка - 8/10.

Оригинал How to Make Sure Your KPIs Are Balanced

автор  Stuart Rance, дата публикации 21.10.14

Достоинства: написано простым, доступным языком, качественные примеры.

Недостатки: слишком компактно.

Уровень сложности - средний.

Полезность - 7/10.

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

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

Здесь и далее курсивом замечания переводчика.

Еще одна компактная статься Стюарта Рейнса про то, чем измерять результативность процессов.

Оригинал Defining Metrics for Incident Management By Stuart Rance 

Опубликовано September 23, 2014 

Достоинства - хорошая иллюстрация декомпозита цели-показатели-метрики, качественный пример показателей, настойчивое напоминание о подходе  “адаптируй и применяй”

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

Сложность материала - базовая.

Оценка - 8/10.

Здесь и ниже курсовом комментарии переводчика.

Оргинал: Defining Metrics for Problem Management

By Stuart Rance | Originally published on June 24, 2014 in ITIL | Updated on November 28, 2017

Это перевод второй статьи на тему определения показателей для процессов Управления ИТ- услагами. Ценность ее в применении техники формулирования показателей на основе требований к результатам процесса (здесь и далее курсивом выдлелены комментарии переводчика).

Многие подбирают ключевые показатели (KPIs) для своих процессов Управления ИТ услугами по книгам (таких как ITIL Service Operation) или копируя метрики, используемые в других компаниях. Это редко приводит к хорошим результатам, потому что дословно KPIs - это дословно Показатели Результативности Ключевых задач, которыми вы занимаетесь. Хуже только ITSM процессы с огромным количеством одинаково названных показателей, которые измеряются, по ним пишутся отчеты, но результаты этого никто не использует ни для изменения деятельности в рамках процессах, ни для улучшения бизнес результатов. 

Ранее я уже писал заметку "Как определять метрики для процесса Управления изменениями" (перевод, оригинал) , в которой я описывал, как можно создать ключевые показатели (KPIs), которые поддерживают именно ваши цели. Читатели (оригинала) после прочтения просили привести примеры, как выделять ключевые показатели (KPIs) для остальных процессов управления ИТ-услугами. В результате я решил написать эту статью для показателей процесса Управления проблемами (problem management), потому что в большинстве компаний, где я работал, у этого процесса были очень куцые показатели.

Напоминаю, что не стоит бездумно копировать приводимые здесь результаты процесса (outcomes), его критичные факторы успешности (CSFs) и ключевые показатели (KPIs). Содержание статьи стоит использовать только для понимания подхода и методологии, которые мною используются. И задуматься о том, что важно именно для вас, выделить метрики, для измерения задачи, за которые вы отвечаете. 

Оригинал Defining Metrics for Change Management

By Stuart Rance | Originally published on April 28, 2014 in ITIL | Updated on September 12, 2017

Начало цикла из 3-х статей про процесс определение показателей для оценки практик управления предоставления ИТ услуг. Чем может быть интересна? Ходом рассуждений автора. (здесь и далее курсивом комментарии переводчика).

Недавно я работал с заказчиками, и они спросили какие ключевые показатели результативности (key performance indicators, KPIs) им использовать для измерения результатов ИТ-процесса Управления изменениями (change management). После обдумывания я предложил им несколько вариантов. И сейчас хочу поделиться ими здесь, потому что это может быть еще кому-нибудь полезно . Только, пожалуйста, бездумно не копируйте себе предлагаемые показатели (KPIs), ведь они  предложены под конкретных заказчиков, но внимательно просмотрите за процессом их опеределения и задумайтесь, а что стоит измерять в вашей ситуации.

Задача:

Исходные установки и упрощения:

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