О преимуществах сервисного подхода в ИТ-поддержке и о тесно связанном с ним сервисном бюджетировании мы беседуем с заместителем генерального директора по стратегии и развитию компании ИТСК Сергеем Овчинниковым.
Intelligent Enterprise: Каковы, по‑вашему, основные черты сервисного подхода к бюджетированию? В чем его основные преимущества для заказчиков?
Сергей Овчинников: Прежде всего стоит сказать от том, что собой представляет наша организация. Наши основные заказчики — «Газпромнефть» и «Сибур», они же являются нашими акционерами. Такая модель позволяет относить нас к рыночным структурам, потому что материнские компании не тиражируют на нас корпоративные правила. Сразу оговоримся, что мы не заменяем собой полностью все то, что относится к сфере корпоративных информационных технологий. В каждой компании есть свои ИТ-подразделения и другие поставщики услуг. Такова общая картина, если пока не углубляться в детали нашей работы и принципы разделения ответственности.
Что касается сервисного ИТ-бюджетирования, то я являюсь его сторонником, и на сервисном принципе строится наша компания. Суть этого принципа, в общем‑то, очень проста. Так, при ресурсном бюджете мы имеем, скажем, 100 тысяч рублей финансирования, а также 20 сотрудников, которые имеют определенную квалификацию и сколько-то стоят на рынке. Управление ИТ-поддержкой в этом случае заключается в «отдаче команд» сотрудникам и бюджетируется персонал. При сервисном бюджетировании мы имеем те же 100 тысяч рублей, но вместо 20 человек набор задач по сервисной поддержке (периодическое обслуживание оборудования, поддержка клиентских мест системы «1С» и пр.) и набор конкретных параметров: время отклика, время устранения. Управление в этом случае заключается в задании этих параметров, и бюджет строится только по сервисам.
Весьма показательны в смысле иллюстрации применения сервисного подхода «кризисные» примеры. Ситуация требует сократить затраты. В случае с ресурсной моделью нам необходимо сократить определенное количество человек, например, Петрова, который обслуживал бухгалтерию. Этот сценарий в принципе может «поссорить» ИТ-директора с руководителями бухгалтерского подразделения. А будь все построено на сервисной модели, пришлось бы так или иначе обсуждать не то, что требуется сократить ключевых людей (а они, увы, еще и далеко не всегда взаимозаменяемы), а как можно изменить уровень сервиса (согласно SLA), какие сервисы убрать, какие оставить (а может, даже и повысить уровень), а от каких, быть может, стоит вообще отказаться. ИТ-директор, таким образом, становится не инициатором непопулярных решений, а исполнителем тех трансформаций в области предоставления ИТ‑сервисов, которые объективно необходимы бизнесу на сегодняшний день. То есть, как мы видим, в динамичной бизнес‑ситуации сервисное бюджетирование обладает дополнительными преимуществами.
А не получится ли так, что, строя сервисные модели бюджета, мы просто изменим некоторые акценты, в некотором смысле трансформируем систему координат и сделаем работу топ-менеджмента заказчика безусловно более комфортной? Но при этом мы можем и не достигнуть той цели, которая сейчас очень важна для многих компаний, а именно сокращения затрат.
Я думаю, в большинстве компаний есть так называемые «сервисные пузыри», независимо от того, работает организация в соответствии с сервисной моделью бюджетирования или нет. Объясняется их появление причинами, которые, в общем‑то, знакомы всем нам. Например, обслуживание бухгалтерии. ИТ-подразделение тесно связано с бухгалтерским хотя бы по той причине, что последнее выписывает зарплату, визирует договоры и акты. HR‑служба тоже важна, так как с ней так или иначе связаны возможности карьерного роста и набора новых сотрудников. Этим подразделениям часто оказывается повышенное внимание, а они к этому привыкают и далее требуют внимания все больше и больше. В то же время производственное подразделение, которое является для бизнеса основным и к деятельности которого в гораздо большей степени приковано внимание топ-менеджмента, может, наоборот, страдать от недостатка внимания со стороны ИТ-подразделения. А все потому, что оно никак не влияет на те бонусы, привилегии или перспективы, которые связаны с ИТ‑департаментом в целом или его сотрудниками.
При ресурсной модели работы (и в том числе при ресурсном бюджетировании) эти «пузыри» скрыты даже в случае, если размер их значителен. При сервисной же — можно легко выровнять ситуацию даже на ранних стадиях, причем сделать это на основе объективных критериев, а стало быть, максимально бесконфликтно. Достигаемое благодаря сервисному подходу выравнивание затрат еще на ранних стадиях — это, конечно же, прямая экономия.
Если же задача сокращения затрат была поставлена в явном виде, то в сервисной модели ИТ директор не задает риторический вопрос бизнесу «что же можно сделать за эти деньги», а предлагает простую таблицу: уровень затрат — уровень ИТ поддержки по SLA, и свои рекомендации. Решение примет сам бизнес.
Хотелось бы понять, как вообще проектировать в организации сервисный подход, без которого преимущества сервисного ИТ-бюджетирования не смогут проявиться в полной мере.
Начну с библиотеки ITIL, которая у нас в стране уже более чем известна. Однако если вести речь об осмысленном, целенаправленном внедрении изложенных там принципов, то пока можно говорить лишь об очень фрагментарном проникновении этих идей на российский рынок. Еще во второй версии ITIL была введена важнейшая концепция «управления приложениями», описывающая их жизненный цикл. Эта книга ITIL, которая так и называется — «Управление приложениями», совершенно не известна у нас. В третьей версии ITIL уже четко акцентируется, что требуемый сервис, равно как и его стоимость, определяются с момента идеи о создании и внедрении приложения. Когда проект внедрения закончен, строить оптимальный сервис уже поздно. Есть специальная роль сервис-инженера — он участвует в проекте и на определенном этапе дизайна и развертывания приложения в компании должен задать вполне определенные вопросы, которые совсем не рассматриваются в настоящее время при внедрении систем. Например, сразу в ТЗ на систему определить SLA. Зафиксированные требования по доступности, отказоустойчивости могут принципиально изменить проектируемое решение. Все это написано в ITIL. В ряде случаев проекты внедрения вообще заменяются проектами покупки сервисов, и это становится заметной тенденцией. Если делать таким образом, вместе с внедрением приложения будут спроектированы и готовые к эксплуатации заранее определенные сервисы. И стоимость их окажется оптимальной. Сейчас в России такой подход, к сожалению, практически не встречается. В итоге нет изначально проектируемых сервисов, нет объективных нормативов, и непонятно, сколько точно все должно стоить. Со своими заказчиками мы всячески пытаемся использовать преимущества подхода, связанного с проектированием сервисов. Однако пока мы тоже находимся еще в начале пути.
Отдельный вопрос — стоимость сервиса. Конечно, у нас есть опыт, есть представление, какие ресурсы необходимы для осуществления того или иного сервиса, есть хотя бы некие эмпирические нормативы, относится ли это, например, к резервированию данных, репликации или чему‑нибудь еще. На их основе мы составляем технологические карты, которые можем в любой момент предъявить нашему заказчику.
Иными словами, объективные расчеты есть, но сам сервисный подход, равно как и точность и объективность процесса сервисного бюджетирования, могли бы быть уровнем выше, если бы сервисы проектировались изначально согласно рекомендациям ITIL, о чем мы уже говорили ранее.
Еще одна тонкость развития сервисного подхода состоит в механизмах владения активами. Именно этот нюанс становится ключевым, когда мы начинаем ориентироваться на третью версию ITIL, в которой понятие сервиса смещено в сторону бизнеса. Большинство наших заказчиков имеют, к примеру, системы видеоконференцсвязи, а мы осуществляем обслуживание этого оборудования и тем самым вроде бы предоставляем ИТ-услуги. Вряд ли тут можно говорить о полноценном сервисе. Во многих компаниях нередка ситуация, когда сотрудники собираются, но оборудование или не включено, или возникают проблемы с его использованием, или кто‑то оставил не стандартные настройки — в общем, сеанс не получился. При этом услуга оказана — к оборудованию претензий нет! Бизнес‑сервис подразумевает, что заказчики вообще должны давать нам только задание, с кем и в какой момент, с каким качеством и какой продолжительности им нужен сеанс видеоконференцсвязи. Все остальное, включая оповещение участников, настройку и поддержку сеанса, могло бы оставаться за нами. Это мне представляется сервисом в реальном значении этого слова. И ясно, что к бюджетированию, то есть к определению структуры расходов на такой вид сервиса, следует относиться совершенно по‑другому.
Тут мы подходим к необходимости того, чтобы основные активы (в данном случае комплекс видеоконференцсвязи) были составной частью сервиса и принадлежали сервисной компании. То есть наша организация, на балансе которой они числятся, должна полностью отвечать за их эксплуатацию, модернизацию или замену. В этом случае активы можно спокойно перемещать, настраивать, дополнительно оснащать иным оборудованием и делать с ними еще множество операций, необходимых для настройки сервисов, гибкой и оптимальной с точки зрения качества и стоимости.
А чтобы ситуация с активами действительно развивалась в нужную сторону, необходимы длительные, по крайней мере трехлетние, стабильные контракты. Тогда компания, предоставляющая сервисы, имеет необходимую ей свободу маневра для закупок и развития собственного парка оборудования.
Вы привели в пример систему видеоконференцсвязи. Пример действительно очень показательный, однако в формировании некоторых ИТ‑сервисов могут участвовать и ИТ‑системы поддержки бизнес-процессов, с которыми дело иногда обстоит значительно сложней.
Да, действительно, это так и есть. Однако сейчас среди заказчиков налицо тенденция использовать в управлении стандартные подходы, а вместе с этим и стандарты, заложенные в управленческие информационные системы. Это своего рода проявление прагматизма. Имеется в виду целый ряд систем, среди которых бухгалтерские, системы бюджетирования, системы взаимоотношений с клиентами, системы поддержки работы с персоналом, электронные торговые площадки и ряд других. Тут, правда, от заказчика требуется систематический взгляд на эту проблему. По меньшей мере необходимо, скажем, четко отделять бухгалтерский учет от управленческого, выделять управление заказами среди прочих функций производственного управления и т. д. В этом случае даже в сегодняшней ситуации при наличии доброй воли можно весьма далеко продвинуться. В системах для малого и среднего бизнеса, у которых взгляд на ИТ более прагматичен, модель аренды приложений очень распространена. Компании легко пользуются уже адаптированными бизнес-процессами. Хотя некоторые классы функциональных и зачастую ключевых для бизнеса систем могут оставаться вне тенденции развития сервисного подхода еще надолго.
Хотелось бы, чтобы вы сказали несколько слов о самой технике сервисного бюджетирования, которой вы придерживаетесь.
В таком случае необходимо снова вернуться к началу беседы, вспомнив о том, что пока мы в подавляющем большинстве случаев не можем проектировать сервисы с момента возникновения идеи о функциональной ИТ-поддержке. Поэтому при составлении сервисно ориентированного бюджета мы помимо планируемых к внедрению сервисов составляем технологические карты (о них я уже говорил), которые однозначно определяют «технологическую подложку» и трудозатраты на сервис. На основе этого составляются обоснованные расчеты стоимости сервисов. Уточняются временные параметры обслуживания и другие его качественные характеристики. Конечно, бюджет — вещь по определению динамичная. Нам могут сказать, что бывают случаи, когда на предприятии-клиенте, скажем, на 20% падает загрузка и сокращается потребность в ИТ. Тогда примерно на столько же надо сократить затраты на ИТ. Но мы опять‑таки делаем это исходя из количества и качества оказываемых сервисов, а не из изначального посыла по сокращению процента ИТ-финансирования и количества ИТ‑сотрудников.
Кроме того, регулярно происходит «обзор» сервиса, составляется план, оптимизации, накапливается опыт работы с ним как с нашей стороны, так и со стороны заказчика. Величина оптимизации вполне может составлять около 10—15% в год.
Наконец, необходимо предусмотреть, что делать, если заказчик по каким‑либо причинам примет решение отказаться от какого‑либо сервиса, например, вследствие замены систем или изменений в бизнесе.
Что бы вы могли сказать о культуре сервисного подхода в целом? Имеется в виду не только ИТ, но любое другое направление, которое может служить локомотивом или по крайней мере катализатором процесса.
Сейчас очень многие услуги предприятия, которые ранее оказывали собственные подразделения, отдают внешним компаниям. Классические примеры всем известны. Это, например, PR-активность или деятельность по созданию и продвижению корпоративного интернет‑сайта. Все это хотя бы косвенно способствует принятию сервисного подхода в организации. Несомненно, стали больше говорить (и не только говорить) об аутсорсинге ИТ-услуг, хотя локомотивом сервисного подхода в ИТ в настоящий момент это вряд ли можно назвать. Пока слишком явной остается зависимость между ИТ-руководителем и тем ресурсом, которым он распоряжается. То есть в данном случае доминирует ресурсный подход. С одной стороны, это объяснимо хотя бы с чисто поведенческой точки зрения: заказчик использует привычную для него командную модель. С другой стороны, как я уже сказал, грамотный сервисный подход требует передачи ресурсов сервис-провайдеру и большого умения управлять сервисом.
В основе бюджета — каталог сервисов
Сивидов Алексей,
заместитель генерального директора IBS DataFortПеред тем как готовить обоснование расходов на ИТ, нужно прежде всего понять: зачем это необходимо компании? На ИТ действительно уходит много средств, и эти расходы чаще всего непрозрачны для бизнеса. Объяснить руководству, зачем компании нужны системы и приложения, нелегко, а обосновать расходы на эксплуатацию еще сложнее. Именно по этим причинам ИТ-бюджет следует составлять грамотно. Он должен содержать в себе подробный анализ эффективности, который мог бы наглядно показать суть всех финансовых расходов. Бизнесу нужно понимать, на что он тратит деньги, ведь его, в первую очередь, интересует конечный результат.
Именно потребности бизнеса лежат в основе сервисного подхода к построению ИТ и соответственно бюджета. Такой подход предполагает создание каталога услуг и расчет их стоимости. На основе сервисного каталога и формируется ИТ-бюджет. В отличие от традиционного подхода, когда ИТ-бюджет вычисляется как процент от валового оборота компании, при сервисно ориентированном подходе к бюджетированию ИТ‑служба выступает не как затратная статья, а как бизнес-единица компании. При таком подходе все ИТ-затраты и результаты выражаются в финансовых показателях (ROI, NPV, IRR). Используется один из способов учета затрат — расчет совокупной стоимости владения (TCO).
Стоит отметить, что внедрение сервисного подхода или модели ИТ в компании — задача нетривиальная, но в этом случае цель оправдывает средства. Сервисная модель ИТ опирается на методологии ITIL и включает в себя каталог услуг, экономическую модель, SLA и KPI.
Основная цель каталога услуг — показать бизнесу, что вы занимаетесь решением четко поставленных бизнес-задач. Каталог услуг позволяет привести стоимость поддержки ИТ-инфраструктуры к вполне измеримой и понятной бизнесу единице — например, к почтовому ящику. Экономическая модель определяет, сколько этот сервис стоит. Главная задача любой экономической модели — оценить расходы компании и сравнить их с рыночными ценами, то есть определить, много или мало вы платите на самом деле.
SLA позволяет свести понятие «денег» у бизнеса и понятие «качества» у пользователей. Таким образом, сервисный подход позволяет руководителям компаний видеть бюджет в виде набора услуг, понимать, как их объем и качество влияют на бизнес и бюджет, и на основе этого принимать решения.
