Какие этапы внедрения? Как мы внедряли?

Мы купили программное обеспечение, провели Школу Целевого Управления. IT-специалисты придумывают, как резервировать, дублировать каналы, запускать и прочее. Очень много сложных вещей, но это их работа. Наша задача – снимать с них, так сказать, нитки, чтобы система была надёжной и всё работало. Соответственно, ребята начинают очень страдать в случае, если где-то не работает почта, где-то провайдер отключил интернет-канал, где-то выключен свет – целое подразделение встало и сидит. Мы им платим, а они сидят, смотрят в стену – ну, света же нету – нормальный форс-мажор, правильно? То есть айтишник (IT-специалист) отвечает за уровень IT-сервиса (илл. 11). Если совершенно упрощенно, то это скорость, с какой человек должен примчаться и исправить вашу техническую неприятность, когда вы написали заявку, либо каким-то другим образом дали знать, что у вас что-то не работает.

Илл. 11. Матрица старшего системного администратора

Есть также показатель невозмещенных потерь, к которому часто относятся утопленные ноутбуки. Большинство из вас знает, что ноутбук и кофе – это такие друзья по жизни, которые всегда находятся рядом. И удивление пользователя, когда он рассказывает, как туда попал кофе. Люди всегда удивлены: «Боже! Я никогда не пил кофе!». Видимо, это диверсия.

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

Если я правильно знаю, у них стоит ещё какая-то система мониторинга, которая отщелкивает все эти провалы, там ведется учет всех процессов. И естественно я не хотел бы, чтобы у вас впечатление создалось, что у нас там даже включение/выключение компьютера под какой-то камерой. Мы выбрали критичные процессы для бизнеса. К таким относятся интернет-каналы, работа бизнес-системы и работа сервиса (работа почты и HR-документов). И там ставится специальный монитор, который отслеживает эти провалы. Они не имеют влияния что-то подкорректировать, подправить, либо оправдаться, что это не они.

Кроме заявленных результатов, на наших ревью и на ежемесячных встречах нужно показывать ещё и предысторию этих результатов. Например, если мы говорим о том, что у нас есть такой-то уровень надежности, то смотрим в разрезах по подразделениям, если есть какие-то сомнения, то в разрезах по дням. И когда происходит столкновение лбами между, допустим, директором филиала, который говорит: «У меня весь филиал неделю стоит!» и IT-сотрудниками, которые говорят: «Да, ну, ребята, вы чё, у нас высочайшая надежность системы, никаких сбоев не было!», тогда под присмотром генерального директора эту ситуацию начинают изучать и доказывать друг другу, кто из них всё-таки больше прав. А для этого используют статистику и начинают выяснять, что и те погорячились, допустим, рассказывая о высочайшей надежности, ну, и у этого не неделю стоял весь филиал.

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

Здесь важно понимать, что управление неприятностями, которые уже случились, – это управление постфактум, когда можно найти виновного, вознаградить его очень сильно, чтобы ему стало жутко стыдно и так далее. Ситуация организована таким образом, что пользователи сами начинают беспокоить ребят, как только что-то проваливается. Потому что пользователи знают критичные участки, которые не работают, либо те, где можно подождать. И не всегда по пустякам беспокоят, нету звонков типа «Вы знаете, не могу найти мышку, как она там движется». Их всё реже и реже беспокоят. И получается, что на надежность информационной системы положительное влияние оказывают уже и сами пользователи. Есть практика такая: процесс выставлен, они бегут и бегут – помогите, спасите.

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

Напрямую коммерческий директор повлиять на бюджет директора IT не может – они должны договориться о размере затрат с привлечением финансистов и генерального директора. Могу сразу сказать, что это не самые такие дружелюбные беседы, и не все выходят оттуда в большом кайфе «ну, вот, наконец-то мне дали много людей и много денег».

Бывают ли ситуации, когда при невыполнении целей компании сотрудники всё равно получают более высокую результативность?

Да, такие ситуации бывают. Как мы уже говорили, идет набор общих показателей, он занимает вес не более 20%. Премирование сотрудника, когда он начинает к фиксированной части своего заработка получать дополнительные какие-то вещи, у нас начинается при результативности от 80%. Мы так решили. Математически можно от нуля сделать или после 100% – никаких проблем нету. Так вот, если у человека всё очень здорово, он прекрасно справился со своей работой, но в организации что-то не получилось, то он получит не суперблестящую премию, как если бы и у организации всё было хорошо, он получит чуточку меньше.

Возможно ли скорректировать результативность из-за форс-мажора?

Технически можно. Можно даже подтянуть определенную методологию «Мы-то не виноваты, но я предлагаю…». Вот у нас в организации я использую практику движения сверху вниз, а не снизу вверх. Надо определиться, с какой целью мы хотим это скорректировать. С целью того, чтобы дать в организацию пример того, что «Ребят, неважно, что получится – потом подправим» – люди воспримут это так, как им удобно. Они выберут лёгкий для себя способ вместо того, чтобы в следующий раз договариваться на стадии формирования бюджета, что им нужен именно вот этот сервер, подводить убедительную аргументацию. Они дождутся окончания периода, когда все лопнут и скажут: «Хе-е! Чего вы хотите? У меня это… это… это… Плюс, меня ещё восемь лет надо учить и девять лет сертифицировать. И тогда, может быть…». До свидания! Сразу!

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