Рост экономической эффективности требует координации действий, нацеленных на повышение результатов хозяйственной деятельности и снижение затрат на ее ведение. Правильнее даже говорить не о снижении затрат, а о приведении их к уровню, необходимому для достижения требуемого результата. Наглядный инструмент для решения этой задачи — каталог ИТ-услуг. Формируется он на основе учетной политики ИТ-департамента, которая определяет методологию подсчета себестоимости ИТ-услуг.
Сколько стоит успех
Прежде чем решиться на любую инновацию, полезно сперва соотнести предполагаемый эффект с необходимыми затратами. В полной мере это касается сервисного подхода к ИТ-поддержке бизнеса. Улучшение финансовых показателей — основная задача любой организации. Необходимо больше продавать, меньше тратить и разумно управлять имеющимися активами. С точки зрения Кирилла Скрипкина, доцента кафедры экономической информатики экономического факультета МГУ им. М. В. Ломоносова, сервисный подход способствует достижению всех этих стратегических целей.
Чтобы сокращение затрат из головной боли превратилось в инструмент повышения эффективности организации, необходимо отчетливо представлять, на какие услуги и виды деятельности тратятся деньги. Каталог ИТ-услуг обладает необходимой для этого наглядностью. Также наличие каталога сервисов облегчает проведение инвентаризации «накоплений» в области ИТ-инфраструктуры, помогает отсеивать сервисы, которые больше не нужны, и выявлять актуальные сервисы, которые не были созданы из-за ограниченности ресурсов.
Каталог ИТ-услуг позволяет представить бизнесу информацию о текущей себестоимости (в случае внешних услуг — цене) конечных результатов деятельности ИТ-департамента. С точки зрения руководства, это может послужить основанием для бенчмаркинга, передачи определенных ИТ-услуг на аутсорсинг, создания общего центра обслуживания и т. д. В свою очередь, ИТ-департамент получает возможность обосновать бюджет, продемонстрировать бизнесу полный пакет своих работ, при наличии нескольких филиалов осуществить внутренний бенчмаркинг и т. д.
Методология оценки себестоимости ИТ-услуг во многом зависит от способа построения их каталога. Существуют два основных подхода к его формированию — «от систем» и «от бизнес-процессов». В первом случае гораздо проще выделить сервисы и провести аллокацию затрат на них, однако бизнес обычно считает такой способ бессодержательным и непрозрачным. Во втором случае технически сложнее выделять сервисы и аллоцировать затраты, но результат обычно понятнее бизнесу. Таким образом, чем ближе каталог услуг к внутренним задачам ИТ-службы, тем разумнее в его создании идти «от систем». И наоборот, чем он ближе к задачам бизнеса, тем разумнее идти «от бизнес-процессов». В дальнейшем необходимо поддерживать его актуальность. Это выполняется либо вручную, либо в частично автоматизированном режиме на основе баз данных инцидентов, проблем, изменений, конфигураций и т. д. Автоматизированная актуализация зависит не только от автоматизации деятельности ИТ-департамента, но и от зрелости его процессов и внедрения необходимых инструментальных средств.
Оценка стоимости услуг на практике
Ресурсно-сервисная модель (РСМ), распределяющая затраты по услугам, является частью каталога сервисов. Поэтому, отмечает Скрипкин, все цели, ради которых он создается и актуализируется, совпадают с целями ресурсно-сервисной модели.
Существуют две основные модели разработки ресурсно-сервисной модели: аллокационная, при которой затраты разносятся по услугам «сверху вниз» в виде процентов от общей суммы затрат, и нормативная — на основе расчетно-технологических карт (РТК), при которой оцениваются нормативы всех видов затрат (трудовых, материальных, внешних услуг) на единицу вида деятельности. Аллокационная модель обычно строится послойно — например, «инфраструктура — платформы — приложения — сервисы». Затраты каждого нижележащего слоя распределяются на вышележащий вплоть до конечного итога в виде сервисов. Распределение этих затрат выполняется экспертно. Опытный администратор хорошо представляет себе нагрузку на ресурс со стороны различных потребителей, даже если не представляет себе отнесение этой нагрузки на конечные сервисы. Он может ничего не знать о конечном наборе сервисов, особенно если они виртуализированы. Однако он в состоянии оценить пропорцию разбиения мощностей ресурса для следующего уровня каталога. Никакие формальные правила здесь установить невозможно, считает Скрипкин.
При нормативном подходе создаются специальные карты, фиксирующие нормативы расхода ресурсов на единицу вида деятельности. Оба подхода наравне с прочими ресурсами включают и стоимость персонала. Аллокационную модель проще построить, но прогноз затрат в зависимости от объема сервисов в ней менее точен. Точность прогноза повышается, если ввести в модель слой технических сервисов, как это рекомендует ITIL версии 3, и выделить среди них постоянные и переменные сервисы. Расчетно-технологические карты дают более точный прогноз затрат в зависимости от объема сервисов и требований к ним, но требуют сбора и обработки исключительно больших объемов информации, особенно с учетом того, что каждая работа поставщика услуг, например разрешение инцидента, имеет много вариантов.
Информационные требования РТК можно уменьшить двумя способами. Первый — внедрять процессы ITIL, такие как управление инцидентами, проблемами, изменениями, работами и конфигурациями. Если все эти процессы находятся на высоком уровне зрелости, а массивы данных регулярно ведутся и актуализируются, оценки стоимости могут быть получены автоматически. Если процессов нет, то (второй способ) можно составлять РТК не на все, а только на ключевые сервисы, тогда остальные затраты должны рассчитываться в аллокационной модели.
Таким образом, аллокационная модель лучше подойдет для внутреннего ИТ-департамента, возможно, в расширенном варианте, то есть с выделением постоянных и переменных технических сервисов. При необходимости сформировать «Соглашение об уровне обслуживания» (SLA) требуется составить РТК на все или большинство услуг, предусмотренных соглашением. Это происходит, например, при переходе на каптивный или рыночный аутсорсинг. (Здесь под каптивным аутсорсингом понимается ситуация, когда ИТ-департамент преобразуется в относительно самостоятельную организацию в рамках холдинга.)
Управленческие расходы на поддержку и актуализацию каталога ИТ-услуг могут быть велики. Для их распределения можно поступить так. Если идет речь о руководителе группы приложений, то его зарплата распределяется между этими самыми приложениями (чаще всего равномерно). Если идет речь о специалистах, работа которых затрагивает всех (например, HR-менеджеры, финансовые специалисты), то вводится «глобальный» сервис, куда включаются эти специалисты, а потом его стоимость распределяется на остальные сервисы. Главное, чтобы достигаемая при этом точность оценки расчетов устраивала заказчика. Если заказчик требует абсолютной точности и не осознает при этом точности получаемых данных, то, скорее всего, проблем не избежать.
При наличии каталога услуг возникает необходимость управлять их ценой и качеством обслуживания. По словам Скрипкина, если существует SLA между поставщиком услуг и бизнесом, то применяются методы классического управления уровнем обслуживания (Service Level Management, SLM), но эта ситуация — скорее, исключение, чем правило. В отсутствие SLA управление осуществляется в рамках управления каталогом услуг. Основные направления работ здесь — анализ удовлетворенности пользователей качеством услуг, анализ затрат, бенчмаркинг, в том числе и между филиалами (в многофилиальной компании).
Чтобы использовать ресурсно-сервисную модель для формирования ИТ-бюджета, требуется наличие в ней данных о единичной стоимости ИТ-сервиса (в расчете на единицу объема, принятую для данного сервиса, например, на одного пользователя) и о переменной и постоянной составляющей последней. В расширенной аллокационной модели это обеспечивается выделением постоянных и переменных технических сервисов, в РТК — путем установления взаимосвязи между видами деятельности и ИТ-услугами. Существенно, что для такого расчета (по любой модели) требуется прогноз потребления ИТ-сервисов. Это, считает Скрипкин, наиболее проблемная часть всего процесса построения бюджета.
Кирилл Скрипкин, доцент кафедры экономической информатики экономического факультета МГУ
Специфика крупного бизнеса
В результате реорганизации ИТ-департаментов компаний «Сибур» и «Газпром нефть» была образована дочерняя Информационно-технологическая сервисная компания (ИТСК). «Отношения с внешним поставщиком ИТ-услуг всегда осложняются объективным противоречием, — считает Вячеслав Берзин, директор по развитию бизнеса ИТ с предприятиями группы «Газпром нефть» компании «ИТСК». — С одной стороны, адекватная ИТ-поддержка бизнеса — инструмент создания новых потребительских ценностей, повышения конкурентоспособности компании. С другой — чтобы повысить экономическую эффективность поставщика услуг, требуются их стандартизация и обезличивание».
По мнению Берзина, даже для предприятий одной группы заказчика говорить о единых требованиях к тиражируемым услугам было бы неправильно. ИТСК формирует свою продуктовую линейку, консолидируя сервисные требования и создавая центры обслуживания, которые предлагают единый общий подход к предоставлению услуг, максимально устраивающий всех.
В ИТСК считают, что непосредственную пользу для заказчика несут услуги, сформулированные в бизнес-терминах (бизнес-услуги). Каждая бизнес-услуга представляет собой комплекс операционных услуг, управляемых по определенным правилам.
Бизнес-услуги уникальны для заказчиков. В то же время основная масса операционных услуг может быть тиражирована с минимальными затратами. Таким образом, задача поставщика услуг состоит в том, чтобы, имея широкий набор операционных услуг (предоставляемых как собственными, так и привлеченными ресурсами) и систему управления ИТ-услугами, формировать уникальные бизнес-услуги для конкретных заказчиков.
Первым шагом к оценке стоимости ИТ-услуг является формирование их каталога. Ошибки, допущенные при выполнении этой работы, могут заметно отразиться на правильности оценки стоимости.
Берзин видит два способа формирования каталога ИТ-услуг. Первый — когда рассматриваются только бизнес-услуги, а операционные услуги в каталоге не размещаются (например, если идет речь о поддержке некоторой системы, то все инфраструктурные и другие операционные услуги находятся «внутри» нее). Второй подход предполагает внесение в каталог всех операционных услуг. У каждого подхода есть свои минусы и плюсы. Получая услуги, сформулированные в бизнес-терминах, заказчик имеет возможность четко соотносить все возникающие ИТ-затраты с потребителями услуги. Минус данного подхода — в снижении уровня контроля за стоимостью операционных услуг. Заказ операционных услуг позволяет заказчику получить больший контроль за уровнем цен, но вынуждает его самостоятельно выполнять функцию сервис-интегратора, что при широком портфеле услуг является трудоемкой задачей и дублирует функции поставщика услуг.
Каталог услуг, по словам Берзина, уникален для каждого заказчика. Решение о том, какие конкретно услуги будут необходимы, каждый заказчик принимает самостоятельно. Примером может послужить различие в бизнес-процессах и поддерживающих их ИТ-системах у заказчиков. Даже если список услуг для заказчиков одинаков, требования к составу каждой услуги (например, «поддержка рабочих мест») могут оказаться различными. Таким образом, даже если в каталоге есть услуги с одинаковым названием, они могут обладать уникальными компонентами и отвечать разным требованиям к оперативности, составу операций, доступности, периоду предоставления.
Оценка стоимости ИТ-услуги частично зависит от ценности этой услуги для бизнеса. «Мы, как сервисная организация, владеем наиболее полной информацией о существующих недостатках систем (на основании хотя бы анализа обращений в службу поддержки). Одна из наших задач — формирование предложений по улучшению сервисов на основании анализа этих обращений, — говорит Берзин. — Подобная оптимизация позволяет нашим клиентам работать более оперативно и с меньшими затратами, что, естественно, отражается на стоимости и качестве предоставления их услуг своим клиентам. Отображается ли это в оценке стоимости услуг? Доработки систем осуществляются в рамках механизма реализации запросов на изменения, по которому предусмотрено отдельное финансирование. Что касается организационных мероприятий, то основная их масса проводится собственными силами, поскольку уменьшение потока обращений приводит в конечном итоге к минимизации затрат нашей компании на их решение».
Основные издержки — прямые
Вывод ИТ-департамента за пределы компании, как правило, ставит его в условия конкуренции на рынке ИТ-услуг, в частности по цене. Это делает чрезвычайно актуальной задачу распределения общих издержек на услуги. Берзин отмечает, что вся проектная деятельность в области ИТ у основных заказчиков ИТСК осуществляется исключительно через тендеры.
Конечно, у ИТСК, как и у любой другой каптивной компании, есть такое преимущество, как лучшее понимание потребностей и специфики систем заказчиков-основателей, основанное на имеющемся опыте работы внутри материнских компаний. Внешние компании, со своей стороны, зачастую обладают большим опытом аналогичных внедрений на других предприятиях отрасли. Во многих случаях наилучший эффект достигается путем совместной работы над проектами ИТСК с внешними поставщиками услуг. В предоставлении ИТ-услуг фактор внешней компетенции ослабляется, и на первый план выходят минимизация стоимости, интеграция системы управления услугами на стороне заказчика и поставщика услуг, соблюдение требований по информационной безопасности, что приводит к существенно большей доле ИТСК в сервисной деятельности.
Оценка себестоимости товаров и услуг осложняется в первую очередь необходимостью распределять на них косвенные издержки. По словам Берзина, ИТСК в меньшей степени сталкивается с этими проблемами, поскольку многие ее заказчики — довольно крупные компании. Для основного объема услуг под каждую из них выделяется отдельный аппаратный элемент инфраструктуры, например сервер. Так было, в частности, при развертывании решений SAP. Для всех централизованных крупных сервисов приложения работают на выделенном для них оборудовании. Для небольших систем и тестовых сред подобные проблемы возникают, но их доля в общей сумме затрат несущественна.
Сильно осложняет расчет себестоимости ИТ-услуг виртуализация инфраструктуры. В настоящее время все виртуальные ресурсы у заказчиков централизованы, их поддержка заказывается как отдельная операционная услуга, и задача по включению стоимости данной услуги как части стоимости бизнес-услуг до текущего момента не была актуальной.
Еще один фактор, осложняющий экономические расчеты, — это необходимость учитывать трудозатраты персонала. Здесь важно учесть не только затраченное рабочее время, но и квалификацию сотрудников, а также сложность выполняемых работ. Для автоматизации этих расчетов в ИТСК существует внутренняя система, в которой происходит списание рабочего времени по всем договорам с предприятиями основных заказчиков (сделкам). Но этого недостаточно. Например, когда диспетчерская принимает заказы от всех предприятий заказчиков, подсчитать затраты диспетчера на ту или иную услугу нереально. На сегодняшний день списание рабочего времени происходит либо экспертно, либо в качестве базы распределения времени диспетчеров по услугам выступает количество обращений по ним. Что касается учета категорий специалистов, то для этого в ИТСК существует функционально-ролевой справочник специалистов. «Мы хорошо понимаем, какова роль той или иной категории сотрудников в рамках того или иного сервиса», — отмечает Берзин.
«Если идет речь об учете фактической занятости, роль специалиста неважна, возникающие прямые затраты соответствуют фонду оплаты труда данного специалиста, и существенное значение имеет только затраченное им время. При оценке плановой стоимости услуги анализируется, какие операции нужно выполнять и какие категории специалистов для этого нужны. На основе параметров, указанных в SLA, поставщик услуг определяет роли, трудозатраты и в конечном итоге команду, необходимую для предоставления услуги. Все описать в SLA нельзя, поэтому цена услуги в любом случае результат переговорного процесса: цена фиксируется в договоре, значит, о ней нужно договариваться. Любая модель расчета цены содержит допущения, таким образом, при согласовании результатов расчета всегда необходимо понимать и обосновывать применимость используемой модели в данном конкретном случае. Универсальной методологии расчета, которая была бы заранее согласована сторонами для всех ситуаций, не существует», — поясняет Берзин.
Все отмеченные им подходы, по словам Берзина, не являются общепризнанными аксиомами: «Механизмы управления ИТ развиваются как на стороне заказчиков, так и внутри ИТСК. В настоящее время активно идет процесс актуализации ИТ-стратегий компаний-заказчиков. Стратегия развития управления ИТ в ИТСК призвана поддерживать изменения в родительских компаниях и дать нашим заказчикам дополнительные идеи по улучшению механизмов на своей стороне. Спустя некоторое время можно будет оценить фактический эффект от изменений».