Предисловие
Предположим, что вы стали ответственным за направление сопровождения бизнес-приложений (application management service, AMS) и ваш руководитель поставил задачу сформировать стратегию и план действий по организации этой деятельности. Первым делом Вы обратились к популярным фреймворкам, таким как ITIL или COBIT. Однако, не по всем аспектам деятельности удалось найти ценные советы. Поскольку, большинство методик говорят, что сделать, но не описывают как.
Мы решили структурировать наш опыт выстраивания процессов и команд поддержки так, чтобы получился понятный и последовательный гайд для руководителя, который сталкивается с задачей выстраивания AMS.
При организации службы поддержки и развития приложений задачи и ключевые вопросы можно условно разделить по трем направлениям:
1. Организационный менеджмент:
Оценка требуемой численности, компетенции и квалификации персонала
Организационная структура подразделения поддержки
Баланс инсорсинга и аутсорсинга
2. Взаимоотношения с клиентами:
Что включить в договорные отношения на поддержку
Модель ценообразования: абонентская плата и/или сервис по требованию
3. Методология и средства автоматизации
Методология и бизнес-архитектура для работы AMS
Средства автоматизации процессов поддержки и развития приложений
В первой статье мы постараемся разобраться какими соображениями можно руководствоваться при оценке необходимой численности персонала для поддержки приложений, какие допущения и ограничения при этом следует учитывать.
Проблематика
Вне зависимости от того, оказываете ли вы услуги поддержки как сторонний подрядчик или же занимаетесь организацией поддержки внутри компании, важнейшим показателем вашей деятельности является стоимость услуг. При этом, мы знаем, что 80% и более от стоимости услуг поддержки - это расходы на персонал. И вам необходимо балансировать между ограничением бюджета (как внутреннего, так и в соответствии с рыночными условиями) с одной стороны и оказанием качественных услуг с другой.
Необходимо заметить, что количественная оценка персонала будет влиять и на другие вопросы, которые необходимо будет решить впоследствии. Например, организационная структура, модель обеспечения ресурсами, обеспечение техникой и офисным пространством.
Наиболее расхожей рекомендацией, которую предлагают разработчики фреймворков и производители ITSM систем при оценке численности персонала на поддержку является использование статистических данных о количестве и длительности обработки обращений в службу поддержки. Однако, это не работает если бизнес-приложение еще только на старте эксплуатации и статистики просто нет.
Наш опыт подсказывает, что факторы, влияющие на численность персонала можно типизировать следующим образом:
Количество пользователей, интенсивно использующих систему в своей повседневной производственной деятельности. Этот фактор можно использовать за базис расчета численности поддержки для транзакционных систем класса ERP, CRM, SRM функциональности НСМ
Параметры SLA, такие как:
Доступность сервиса. Например, предоставление сервисов поддержки приложений вне пределов рабочего времени может повлечь за собой организацию сменной работы персонала с соответствующей необходимостью увеличения численности.
Скорость реакции, время решения обращений.
Наличие среди поддерживаемых пользователей VIP пользователей с более жесткими требованиями к SLA.
Драйверы расчета, не зависящие от количества пользователей, но усложняющих задачи поддержки приложения.
Например, такие как:
Количество показателей в отчетности, количество отчетов.
Количество интеграционных потоков.
Количество табельных номеров в расчетах заработной платы.
Количество пользователей – самый понятный показатель. По нашему опыту, в среднем на одного пользователя приходится от 5 до 7 обращений в год при средней трудоемкости от 2 до 4 часов на решение одного обращения. Таким образом, вы можете посчитать общую трудоемкость и потребность в персонале по нескольким сценариям от негативного (максимальные значения) до позитивного (минимальные значения).
Влияние параметров SLA на численность команды поддержки необходимо учитывать в качестве поправочных коэффициентов для расчетов. Например, доступность сервисов может быть 8x5, 12x5, 24x7 и т.д. В данном случае мы можем рассчитать поправочный коэффициент для расчета численности персонала с учетом сменной работы и условий оплаты переработок. Если Вы поставлены в жесткие рамки сроков решения обращений, это также может служить мультипликатором для увеличения численности и повышения квалификации команды.
Сложнее обстоят дела с оценкой численности персонала для систем и сервисов, где численность команды поддержки не коррелирует напрямую с количеством пользователей систем. Или же на трудоемкость поддержки влияют факторы, которые очень сложно привести к алгоритмам расчета трудоемкости. Например, системы бизнес-аналитики, хранилища данных, интеграционные решения. В этих случаях мы можем говорить только о драйверах оценки, которые влияют на сложность решений, что в свою очередь влияет на трудоемкость.
При таком подходе для решений по бизнес-аналитике в качестве подобных драйверов можно использовать количество реализованных отчетов, количество показателей в них, а также количество витрин, данных и экстракторов.
Например, в наших кейсах при расчете потребности в ресурсах для поддержки систем на базе SAP BW/BI мы использовали следующие вводные для расчетов: не более 3 бизнес-областей, 10 отчетов по 10 показателей на одного сотрудника поддержки.
Для оценки трудозатрат на поддержку интеграционных решений можно использовать количество интеграционных потоков и сложность трансформации данных, выполняемой непосредственно на шине данных.
В любом случае в отсутствии четкого математического алгоритма расчета трудоемкости для такого рода сервисов и систем вам придется базироваться в ваших оценках на экспертных оценках и вашем собственном здравом смысле и опыте. По мере появления статистики вы сможете корректировать расчеты на более точные.
Также не стоит забывать о том, что в первый год после внедрения бизнес-приложения нагрузка на службу поддержки намного больше, чем в последующие годы, так как решение стабилизируется, пользователи привыкают к работе и формируется база знаний. Поэтому мы рекомендуем оценивать потребность от негативного до позитивного сценария в течении первого года.
Кроме того, в ряде случаев необходимо оценивать технический долг внедрения в качестве ещё одного коэффициента усложнения задач поддержки. Если в эксплуатацию запускается «сырое» решение – постарайтесь оценить хотя бы приблизительно трудоемкость доработок и определите лимит на их выполнение, который может быть охвачен вашей командой. Обычно на первый год поддержки на устранение ошибок и замечаний должно быть заложено не менее 50% трудоемкости от общей оценки трудоемкости функциональной поддержки.
Таким образом, даже не имея статистики или benchmark вы сможете рассчитать численность исходя из нескольких показателей, описанных в данной статье.
Авторы
