ПО МНЕНИЮ ИЛЬИ САВИЧЕВА, ресурсно-сервисную модель несложно построить, но, не будучи непосредственно связанной с операционной деятельностью, она не сможет стать инструментом управления |
На очередном семинаре российского ITSM-форума, темой которого стал расчет стоимости ИТ-сервисов, докладчики несколько разошлись в определениях. Если генеральный директор компании OmniWay Илья Савичев в своем выступлении охарактеризовал ресурсно-сервисную модель (РСМ) и расчетно-технологические карты (РТК) как два разных подхода к определению стоимости ИТ-сервисов, то из доклада доцента кафедры экономической информатики МГУ им. Ломоносова Кирилла Скрипкина следовало, что РТК является одним из видов РСМ. Так или иначе, это два ключевых способа расчета стоимости сервисов, по крайней мере в теории. Ресурсно-сервисная модель соотносит сервисы и задействованные в их реализации ИТ-активы, позволяя определять цену предоставления сервиса на основе связанных с соответствующими ресурсами затрат. Расчетно-технологическая карта больше опирается на человеческие ресурсы — затраты труда и времени персонала — в процессе предоставления сервисов.
Оба подхода имеют преимущества и недостатки. По словам Савичева, ресурсно-сервисную модель несложно построить, недолго внедрить, но она требует постоянных усилий на актуализацию и, не будучи непосредственно связанной с операционной деятельностью, не сможет стать инструментом управления и планирования, а потому рискует остаться лишь на уровне теории. РТК дает детальную информацию о том, какие операции составляют ИТ-сервис, какие затраты времени и труда с ними связаны, и позволяет более четко демонстрировать заказчику, на что уходят его деньги, поддерживая тем самым осознанное управление уровнем потребления ИТ-сервисов. При этом, как заметил Скрипкин, расчетно-технологическая карта заработает в полную силу, если в организации поставлен ряд процессов управления ИТ-сервисами на базе ITIL, то есть требует для своего успешного внедрения определенной зрелости с точки зрения ITSM.
Однако вопрос вопросов — зачем, собственно, считать цену сервиса внутренней ИТ-службе, зачем тратить время, усилия и, наконец, деньги на внедрение той или иной модели расчета. Как отметил Скрипкин, в обосновании затрат на ИТ-проекты это помогает мало, в большей степени может оказаться полезным для обоснования эксплуатационного бюджета или принятия решений по аутсорсингу отдельных сервисов или ИТ в целом. Савичев поделился опытом внедрения РСМ в холдинге, где модель расчета стоимости сервисов помогла обеспечить справедливое возмещение расходов на централизованную ИТ-службу отдельным бизнес-единицам холдинга.
Но все же по-настоящему актуальной задача определения стоимости сервисов становится, когда ИТ выделяется в полностью или относительно независимую структуру и начинает выстраивать формализованные отношения с бизнесом как с заказчиком своих сервисов. Вячеслав Берзин, директор «Информационно-технологической сервисной компании» по развитию бизнеса ИТ с предприятиями группы «Газпром нефть», рассказал, что поставленная перед ИТ группы двоякая задача — снижать затраты на сервисы и одновременно вносить свой вклад в повышение капитализации компании — требовала четкого понимания стоимости сервисов, а это, в свою очередь, подтолкнуло к решению сервисы реально продавать заказчику. В результате была создана дочерняя компания ИТСК, взявшая на аутсорсинг все ИТ-сервисы «Газпром нефть».
По словам Берзина, в ИТСК формальные подходы к расчету стоимости типа РСМ и РТК остались на уровне картинок, хотя элементы обеих моделей присутствуют. Для каждого сервиса определяется детальный ресурсный план, расчет стоимости производится от затрат на сервис с учетом нормы его рентабельности, согласованной с заказчиком. Главное, что было достигнуто благодаря появлению формальных расчетов стоимости сервисов, это возможность приходить к разумным соглашениям между продавцом и покупателем и появление стимулов для регулярной работы по оптимизации сервисов, которая приводит либо к оптимизации их стоимости, либо к ужесточению параметров соглашения об уровне обслуживания (Service Level Agreement, SLA), либо к расширению состава сервисов.