Говоря о качестве в ИТ, можно концентрироваться на качестве разработки, качестве поддержки и сервисов, качестве управления ИТ‑службой в целом. Опыт по каждому из этих направлений можно надеяться обнаружить только в компании с высокими требованиями бизнеса к ИТ, там, где от качества управления ИТ действительно зависит конкурентоспособность. О своей практике рассказывает Виктор Горбунов, ИТ-директор фармдистрибьютора «Протек», одного из крупнейших в стране.
Intelligent Enterprise: Как в вашей компании построено управление качеством ИТ‑сервисов?
Виктор Горбунов: Управление качеством можно разделить на несколько уровней. Первый — это технологические вопросы, сбои, работоспособность инфраструктуры. Это для нас не является проблемной зоной, так как выстроены все необходимые процессы контроля, модернизирована инфраструктура. Построена система автоматического контроля основных инфраструктурных звеньев, таких как сеть, ЦОД. Все серверы в филиалах управляются централизованно из головного предприятия. Действует система контроля ключевых показателей: доступность, число инцидентов, автоматически регистрируемых в системе Service Desk.
У нас давно внедрен HP Open View, и методология ITIL применяется более пяти лет. Поставлены процессы управления инцидентами, проблемами, управления изменениями, есть диспетчерская служба, есть колл-центр. Заданы нормативы на каждый сервис, метрики, такие как время устранения инцидента, допустимое время простоя.
Разработана детальная таблица сервисов, и для меня это основной инструмент управления качеством сервиса. Если видно, что по каким‑то параметрам мы регулярно «выходим за рамки», много инцидентов — значит, нужно что‑то менять.
Как меняются метрики, основные нормативы со временем?
Вначале мы просто измеряли процент технологической доступности. Потом мы стали строить систему мотивации в отделе эксплуатации, и ситуация изменилась. Каждый начальник отдела ДИТ имеет свой набор ключевых показателей. У отдела эксплуатации это доступность систем с учетом производительности и показатель, связанный с затратами, — «стоимость ИТ-функции», он примерно отражает совокупную стоимость владения. С одной стороны, должно все работать. С другой — это должно быть недорого. Управление затратами — один из ключевых вопросов при управлении дистрибьюторской компанией.
Раньше мы просто считали интегральный показатель доступности, этого было достаточно в период, когда еще была проблема с числом инцидентов в системах. Затем стало ясно, что доступность у нас 99,99, но при этом есть нарекания по работе тех или иных сервисов. Тогда мы стали мотивировать людей просто на число инцидентов по сервису. Тут мотивационная схема такая: премия зависит от времени работы сервиса без инцидентов вообще. Чем дольше их нет, тем выше бонус. Как только произошел сбой, исчезают и бонусы: один критический инцидент — и половина переменной части зарплаты снимается. При таком подходе персонал начинает работать на профилактику, ведет проактивный мониторинг. Система довольно жесткая, но она работает. Сначала сотрудники, конечно, ворчали: «Да не может у меня ничего не сломаться…». Но теперь это прошло, и многие довольно долго работают без сбоев. Так что важна не просто общая доступность, важней всего, были ли такие ситуации, когда конечные бизнес-заказчики имели проблемы, была ли фактическая остановка сервиса. Мы переходим, таким образом, от оценки технологического состояния к оценке устойчивости бизнес‑сервиса. Стараемся мерить число проблем у пользователей.
Насколько сервисный подход близок и понятен вашим бизнес-пользователям?
Проблемы с тем, как пользователи воспринимают сервисный подход, были вначале, года два назад, теперь они в прошлом. Все это время у нас подписываются соглашения с бизнес-подразделениями об уровне сервиса, SLA, и эти показатели постоянно улучшаются. Лучшая доступность, меньшее время устранения инцидентов, и совсем не обязательно это будет дороже.
Так как давно используется Service Desk, накоплена обширная статистика решения инцидентов. Постепенно мы пришли к ситуации, когда сокращение времени устранения инцидента уже не приводит к каким‑то изменениям в бизнесе, на бизнес-процесс не влияет. Мы постепенно выделяем такие сервисы и в дальнейшем не пытаемся еще ускорить работу по ним, переключаемся на оптимизацию других.
Теперь уже и бизнес-заказчики понимают, что такое «сервисный подход». Параметры SLA мы им объясняем, обосновываем, находим компромиссы. Все сервисы, значимые для бизнеса, у нас описаны со всеми параметрами. Проставлены и критерии важности инцидентов, автоматически проставляется уровень критичности. Звонки особо требовательных пользователей повлиять на отмеченный уровень инцидента не могут, это стандартизованные параметры. Есть таблица соответствия инцидентов и уровней критичности. Теперь следующая задача — зафиксировать эти показатели и понять, как мы можем оптимизировать расходы на поддержку.
Какие методы вы используете для этого и как давно?
Один из путей — система региональных центров компетенции. Сервис поддержки баз данных Oracle во всех филиалах находится у нас в Краснодаре. Так как сеть у нас единая, домен один, человек из Краснодара может достучаться до любого сервера сети. В свое время мы по многим направлениям сделали своеобразный «анонс» по всей ИТ‑службе, по всей стране: кто из сотрудников возьмется вести тот или иной централизованный сервис? И такие люди нашлись в разных городах. У меня было 40 админов Windows, осталось пять, и они обслуживают ту же структуру. Серверы на местах закрыты на замок, на них есть лишь датчики температуры и электропитания. Управляются они только централизованно.
Мы провели замену техники, оптимизировали ее. Широко применяем виртуализацию, что помогло сильно сократить расходы на поддержку и снизить энергопотребление. Это для нас немаловажно и становится все существенней. Все серверы стандартизованы. Централизовать сервис печати тоже совершенно нереально, да и не к чему, сеть будет стоить дороже. Поэтому мы и сделали такую архитектуру: часть функций централизованы, часть — распределены. Но главное, что централизованы управление и контроль сервисов. Все, что сложнее и критично для операций, централизовано, но люди физически находятся где угодно. Центр поддержки «1С» — в Архангельске, еще один такой «центральный» специалист — в Туле, в отделе эксплуатации — два самых высококлассных специалиста по Oracle в Москве, остальные семь — по регионам. При этом достигаем заметной экономии фонда оплаты труда. Если их всех свезти в Москву, это будет дороже втрое. Сокращение расходов не связано только с кризисом, это постоянная деятельность. Постепенно все дистрибьюторы приходят к одинаковому уровню сервиса, к одинаковым ценам. Вопрос в том, какими ресурсами, насколько дорого или дешево это сделать. Поэтому задача стоимости функции стоит постоянно.
С 2008 г. штат ИТ‑департамента сократился существенно без потери функций или качества работы. Параллельно шла реорганизация региональных подразделений. Раньше в каждом филиале практически был собственный ИТ-отдел: где двое, а где семеро сотрудников. Нужно было разобраться с их занятостью, ввести нормативы. Затем часть людей либо перешли в региональные центры, ведущие централизованную поддержку, либо ушли. Часть функций стали передавать на аутсорсинг.
В прошлом году мы провели один из крупнейших в России проектов перевода печати на аутсорсинг. Мы очень много печатаем, продажа лекарств требует целый набор сопроводительных документов. Это довольно затратная функция, причем для поддержки еще нужна отдельная логистика расходных материалов. Мы все это отдали HP, теперь они обслуживают все наши филиалы. Контракт у нас именно с ними, а кого они нанимают на субподряд — мне даже неинтересно. У нас есть фиксированная стоимость отпечатка, покопийная печать и показатели SLA. И это привело к существенному снижению затрат. HP предложила нам довольно выгодные условия, и стал возможен более жесткий контроль за расходованием материалов.
Качество ПО: что вы под этим понимаете и как управляете им?
Действительно, измерить качество ПО непросто. Первый и относительно простой вопрос — уровень числа сбоев. У нас есть специальный «Отчет по ошибкам ПО», где мы структурируем сбои по программным элементам. Выявляем наименее надежно работающие приложения, модули, блоки. Как только это сделано, возникает задача найти причину этих сбоев и устранить. При этом надо учитывать, что понятие «сбой ПО» довольно расплывчато. Пользователь может считать сбоем лишь слишком медленную, по его мнению, работу приложения. Случается функциональный сбой, когда вроде бы все запрограммировано верно, а результат неадекватный. Тут универсальных рецептов не может быть, с каждым случаем нужно разбираться отдельно. Число повторных ошибок при разработках мы тоже контролируем. Есть и показатель «количество сбоев при установках новых версий». Если сделан апгрейд и в результате возникли ошибки, то начальник отдела, выпустивший версию, это почувствует. Это один из его мотивационных показателей. Второй вопрос — функциональное качество. Насколько то, что заказал пользователь, соответствует задаче? От того, как построена та или иная функция, может существенно зависеть производительность труда сотрудника, который ею пользуется. И если автоматизировали, скажем, функцию набора товара на складе, и в результате все работает, но операция выполняется вдвое дольше, чем раньше, то функция автоматизирована некачественно. Хотя формально все верно. Важно число действий. Чем оно меньше для достижения одного и того же результата, тем функциональное качество выше. По ряду функций мы это измеряем. Для склада это очень важно, ведь наши основные затраты — складские операции. Поэтому от того, как именно автоматизировано то или иное действие, серьезно зависят производительность, число людей, которые потребуются.
Мы берем определенную функцию, раскладываем ее на элементарные действия, хронометрируем каждое посекундно. Получается, например, что время отбора одной коробки 2,5 минуты, а нужно, чтобы оно не превышало одной минуты. Как это сделать? Это самое интересное.
Здесь ИТ принимает очень серьезное участие. В ИТ‑департаменте есть отдел автоматизации, по сути дела — бизнес-анализа. Именно к ним приходит функциональный заказчик со словами «у нас есть такая‑то бизнес-функция, она автоматизирована (обычно), но результаты не удовлетворяют по таким‑то параметрам». Ставится задача, и люди дальше работают совместно: один понимает процесс, другой — как его можно автоматизировать. Если достигают значимого результата, премируются. Это планомерная постоянная деятельность по оптимизации процессов.
Есть общий перечень таких задач, по каждой есть ответственный аналитик, есть понимание того, чего именно мы хотим достигнуть, причем очень конкретно — «повышение производительности на столько‑то». Для решения задачи образуется временная рабочая группа из бизнес-заказчика, аналитика, программиста.
Считаю, что функциональное качество ПО — важнейший показатель. Оно тесно связано для нас с постоянной оптимизацией процессов. А в современных компаниях практически не осталось процессов, не поддержанных ИТ.
Есть и еще одно понимание качества ПО, но трудно оцениваемое: насколько за счет ПО увеличивается конкурентоспособность компании. Интегральный показатель, который тяжело измерить. Можно сделать так, чтобы каждый сотрудник, понимая свой бизнес-процесс, оценивал бы, как можно улучшить показатели этого процесса, причем не обязательно затратные. Как улучшить собираемость дебиторской задолженности за счет более четкого контроля, как увеличить число заказов за счет того, чтобы цветом или анимацией выделять в прайс-листе определенные позиции. Это задача каждого сотрудника на его месте. Система мотивации должна быть так построена, чтобы каждый человек об этом думал.
Задача донесения глобальных целей компании до каждого сотрудника, чтобы каждый работал на оптимизацию, — одна из сложнейших. Как это реализовано у вас?
Есть процесс стратегического планирования, где компания ставит цели. Цели декомпозируются менеджментом и попадают в конкретное подразделение. Тут обычно становится ясно, что «просто так», ничего не меняя, достигнуть их невозможно. Возникает инициатива снизу о том, что и как нужно менять для их реализации, в том числе и в ИТ‑системах. Эти инициативы и формируют список задач для нашего отдела автоматизации. Речь идет уже о самых конкретных задачах, скажем, оптимизация механизма высотного хранения. А этот список задач мы контролируем.
Донесение целей до исполнителей — действительно дело непростое, и лозунгами тут ничего не добьешься. В свое время мы пытались внедрить систему бережливого производства и «бросали клич» по всей компании о необходимости выступать с «рацпредложениями». Быстро стало ясно, что кличей недостаточно. Предложения по улучшению будут, но бессистемные и в большинстве случаев не соответствующие целям верхнего уровня. Нужны стратегические цели, комплексные, которые ставят сотрудникам четкие рамки, дают ориентиры. И если отделу ставят цель повысить производительность труда на 30%, тут один человек не придумает ничего. Тут надо организовывать общую работу целенаправленно.
Пытаетесь ли вы считать экономическую эффективность ИТ-проектов?
Для сколько‑нибудь затратных по ресурсам задач мы делаем технико-экономическую оценку. Доказать, что задачу действительно нужно делать, что надо потратить на это шесть человеко-месяцев, — это, конечно, работа заказчика. Нас привлекают для оценки, но в целом до запуска проект должен быть обсчитан заказчиком. И заказчик несет ответственность за то, что система действительно нужна. После завершения проекта мы оцениваем реальную достигнутую эффективность. Выполняются показатели? И команда проекта получает бонус. А на нет и суда нет. У нас были ситуации, когда до внедрения показатели не померили, а потом непонятно что получили, не с чем сравнивать, но теперь они исключаются. Однако есть и проекты, которые трудно обсчитать, и по ним просто принимается решение, что мы будем это делать в любом случае, даются качественные оценки. Но основную массу задач мы стараемся считать, без этого и приоритеты тяжело расставлять. И мотивация исполнителей связана с приоритизацией проектов.
Вы постоянно возвращаетесь к вопросам мотивации. Это насколько важный инструмент?
А как иначе? Я пытался и тайм-шитинг внедрять, пытался каждого контролировать, чем он занимается, на что время тратит, но пришел к выводу, что это совершенно неэффективно. Против лома нет приема. Работу программистов и аналитиков чрезвычайно тяжело контролировать, практически невозможно, она крайне трудно нормируется.
Вместе с тем глубоко убежден: в любой системе всегда можно изыскать резервы. В ИТ производительность труда отдельного человека может возрастать значительно. Когда человек думает и пытается найти новые пути, способы решения задачи, то обязательно находит способ сделать ее меньшими силами и быстрее, а иногда и с меньшей стоимостью.
Должна быть мотивация на развитие. Системе мотивации мы уделяем очень много внимания. Я считаю именно ее важнейшим элементом управления. И мы построили достаточно, на мой взгляд, эффективную систему, хотя очень часто приходится слышать традиционное: «Ну как же вы измерите труд программиста…»
Человек понимает, что он может заработать больше, делая в срок и качественно поставленные ему задания. Мы не опускаемся на уровень «сколько ты написал строк кода». По разработкам есть нормативы, с ними сверяемся.
По моему опыту, есть две категории сотрудников, и в ИТ это особенно ярко проявляется. Есть творцы, которым важна не только зарплата, но и создание чего‑то ценного для компании, что будет использоваться многими сотрудниками. Для них важна самореализация. Таких я в первую очередь и стараюсь подбирать, поскольку их производительность может в разы превышать отдачу других, для кого важен только заработок.
Поэтому зарплата строится так: есть постоянная часть, есть переменная, связанная с инцидентами, и еще часть, связанная с развитием, с собственным совершенствованием. Это улучшение своих собственных процессов. Я стараюсь мотивировать людей на то, чтобы они постоянно думали, как улучшить свою собственную деятельность, как улучшить поддержку сети или как улучшить поддержку инфраструктуры Windows.
Система мотивации — ключевой фактор, и ее надо основывать на адекватной системе ключевых показателей. Они должны быть связаны с целями, которые вы ставите перед конкретным подразделением.
Ситуация «win-win»
Сергей Лысанов,
руководитель подразделения услуг печати «HP Россия»Масштабный проект аутсорсинга печати можно назвать взаимовыгодным и для компании «Протек», и для HP. Он позволил крупному фардистрибьютору обеспечить надежное функционирование своей системы печати силами известной компании‑специалиста при одновременной экономии средств, сделать прозрачной структуру своих затрат на печать, усилить контроль за расходами и высвободить человеческие ресурсы для решения других задач. Являясь одновременно производителем техники, расходных материалов и поставщиком услуг, HP гарантировал «Протеку» неизменность цен на весь срок действия проекта.
Предоставление собственной инфраструктуры HP удаленного мониторинга устройств печати, прямой поставки оригинальных расходных материалов и запасных частей в любую точку России позволяет HP обеспечивать не только надежность функционирования и масштабируемость проекта, но и возможность его адаптации к вероятным новым требованиям со стороны энергично развивающегося бизнеса «Протека».
