Попробуйте бесплатно
Пн-Пт: 9:00 - 18:00

«Бюджет простоев» лучшая тактика контроля ИТ со стороны бизнеса

04.10.2017

Изображение бюджет простоев

Для кого

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

О чём

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

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

Те, кто ИТ-системы дорабатывает – назовём их программистами – наоборот, хотят сделать как можно больше изменений. Каждое изменение — это выполнение требования заказчика, которого текущая система чем-то не устраивает. Иногда это мелкое требование изменить надпись на кнопке, которая не нравится, но иногда это требование переделать систему отчётов, потому что в старом виде налоговая баланс не примет.

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

Плохие решения

Есть несколько распространённых решений этого конфликта, и все они плохие: эскалировать, отдать приоритет одной из сторон, свалить ответственность на заказчика.

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

Если компания велела принимать все решения о проведении и не-проведении изменений одной из сторон, а второй стороне велели слушаться, то та, первая сторона, и «победила». Последствия легко предсказать. Так, например, некоторые администраторы не использовали новую версию Windows, пока к ней не выйдет второй комплект доработок и исправлений (сервис-пак). Для Windows 2000 второй сервис-пак вышел через два года после выхода самой системы. Пример экстремальный, но мысль, что если победят администраторы, то пользователи увидят обновления своих систем очень не скоро, он иллюстрирует вполне.

Лучше ли будет, если победят программисты? Нет. Например, в одном из региональных офисов известной нефтяной компании программисты гордились: «Мы иногда целых две новых версии в день выпускаем». Пользователи же генерировали беспрецедентное количество жалоб.

Интересный, но тоже не работающий способ: свалить принятие решений о проведении изменений в ИТ-системах на пользователей этих систем. Есть бухгалтерская система — вот пусть бухгалтерия и решит, когда им новую версию поставить. Единственный плюс этого метода в том, что бухгалтерия не разрешит ставить новую версию и создавать угрозу своей работе в напряжённый период работы, например, при расчёте баланса, закрытии месяца или при расчёте зарплаты. Дальше идут только минусы: бухгалтерия разрешит ставить новую версию не потому, что та успешно прошла все тесты, а потому что в новой версии есть новая форма платёжки, без которой банк не примет платежи, то есть в самый последний момент. А самое главное, что бухгалтерия в ИТ не разбирается, у её сотрудников другая область компетенции.

Бюджет простоев

Как руководитель вы имеете не только право, но и обязанность решать подобные конфликты. Одна из главных мировых ИТ-компаний придумала хитрость, и вы можете ею воспользоваться. Хитрость называется «бюджет простоев» и состоит в том, что вы как главный заказчик даёте ИТ-службе в целом одну общую задачу, и потребность её решить не даёт программистам и администраторам бороться между собой. Как если бы вы лебедя, рака и щуку замени на трёх коней и велели им бежать в одну строну.

Эта хитрость состоит в том, что вы 1) разрешаете ИТ-системе не работать какое-то количество рабочего времени в течение месяца, 2) требуете, чтобы это время не было превышено, и 3) поощряете или наказываете всю ИТ-службу в зависимости от того, сколько времени проработала система в течение месяца. Это разрешённое время неработоспособности и есть «бюджет простоев».

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

Откуда берётся бюджет простоев

Зачем вообще разрешать время простоя, не разумно ли требовать от ИТ-системы круглосуточной безостановочной работы? Например, известная компания-производитель компьютеров так и называла свои серверы: «нон-стоп». Есть несколько аргументов за то, чтобы разрешать простой ИТ-систем.

1. Перезагрузка компьютера или ИТ-системы была и остаётся способом быстрого решения множества проблем. Во время перезагрузки система не работает.

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

3. Система, которая с гарантией работает почти 100 % времени круглосуточно, стоит дорого, в разы дороже обычной, и чем ближе к 100 % гарантированное время работы, тем дороже.

4. Как только видна связь между 100-процентной работоспособностью и её высокой ценой, как правило, выясняется, что 100 % работоспособность не нужна. «Мы не будем отключать горячую воду на 2 недели летом, но цена воды вырастет в 20 раз, что скажете?»

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

Без чего не заработает бюджет простоев?

1. Точно определите, что значит «система работает» и что значит «система не работает». Возможно, это самая сложная задача в отношениях с ИТ-службой изо всех существующих. Самое простое из её решений — использовать систему регистрации запросов пользователей, например ServiceNow. Эта система поставляется «из облака», что позволит начать работать быстро и с небольшими затратами.

2. Точно определите рабочее время, когда система должна работать. Важно не то, что вы установите, что система должна работать с 6:00 или с 5:55 утра. Важно, что после установки точного начала рабочего времени простои системы в нерабочее время перестают быть простоями. Также учтите, что требуя круглосуточной работы, вы соглашаетесь на работу части ИТ-службы в три смены с соответствующими затратами.

3. Точно определите размер бюджета простоев, например «4 часа в месяц». Допустимо разделять этот бюджет на части: «4 часа в месяц, но не более 2 часов в один день» или не разрешать простои в особо важные дни: «4 часа в месяц, простои не допускаются в первый и последний рабочие дни месяца, а также с 12 по 16 число включительно».

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

Итоги

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

Оставайтесь на связи!

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

Задать вопрос

У вас есть вопрос, идея, предложение или хотите стать нашим партнером? Просто отправьте нам сообщение в свободной форме, и в течение рабочего дня мы свяжемся с вами.

Имя*
Фамилия*
Компания
Категория вопроса
Телефон*
E-mail*
Вопрос*
Защита от автоматического заполнения
Введите символы с картинки*

* - Поля, обязательные для заполнения

Авторизация

Логин (e-mail)
Пароль
Забыли пароль?

Авторизация доступна заказчикам Техносерв Cloud. Чтобы стать нашим клиентом, свяжитесь с нами. Спасибо!

Восстановление пароля

Логин (e-mail)

На ваш e-mail будет отправлено письмо со ссылкой на страницу смены пароля

Контакты службы поддержки:
+7 (495) 790-79-79
support@technoserv.cloud

Сервис обратного звонка RedConnect