Планирование персонала на основании прогнозов потребления услуг

Обоснованное планирование численности персонала является одной из самых непростых задач, стоящих сегодня перед ИТ-руководителями. В этой статье мы поговорим о методике планирования состава и численности персонала на основании прогнозов потребления ИТ-услуг, а также о том, что необходимо для того, чтобы этой методикой можно было воспользоваться на практике.

Задача

Вы – руководитель ИТ-подразделения. Как и ваши непосредственные подчиненные, вы постоянно перерабатываете – засиживаетесь допоздна, иногда работаете в выходные. Задач больше, чем вы можете решить, и их количество медленно, но неуклонно растет. Конечно, не все делается своими силами – там, где это возможно, применяется аутсорсинг. Но не все можно передать внешним исполнителям, да и операционный бюджет согласуется далеко не на 100%.

И рано или поздно (а для большинства руководителей – ежегодно) перед вами встает задача увеличения численности персонала. Задача эта имеет несколько составляющих – определение потребности (какие специалисты вам нужны и в каком количестве), обоснование потребности, поиск и найм специалистов, ввод их в строй с тем, чтобы они приносили ожидаемую отдачу. Однако во многих известных мне случаях дальше обоснования потребности дело не идет или идет очень туго, поскольку большинство крупных компаний весьма жестко контролируют предельную численность персонала (headcount) и фонд оплаты труда (ФОТ), а ИТ-руководители испытывают острую нехватку убедительных аргументов.

Как же сделать так, чтобы ваш расчет потребности в ресурсах был обоснован?

Традиционное планирование

Традиционно для планирования и обоснования численности персонала для операционной (непроектной) деятельности¹ используется операционный каталог и операционная модель.

Операционный каталог представляет собой перечень всех видов операционных активностей, выполняемых организацией. Упрощенный пример операционного каталога представлен в таблице 1.

Для простоты навигации работы обычно структурируются по категориям. Для оценки объема и нормирования работ используются драйверы, определяющие единицы измерения объема работ. В моей практике использовались следующие типы драйверов:

1. Драйвер типа «Объект обработки» позволяют планировать работы, исходя из оценки количества объектов, поступающих на обработку в период планирования (инцидентов, запросов на изменения, заданий и так далее). Например, экспертиза доработок потребует тем больше ресурсов, чем больше поступит запросов на изменения (RFC). Планирование ресурсов осуществляется на основании норматива или оценки трудозатрат на обработку одного объекта.
2. Драйвер типа «Объект обслуживания» позволяют планировать работы, исходя из количества объектов в сфере ответственности обслуживающей организации (серверов, сетевых каналов, банкоматов и так далее). Например, трудозатраты на администрирование серверов увеличиваются с ростом количества серверов. Если это количество на протяжении периода планирования существенно меняется, в качестве значения драйвера может использоваться формула (A+B)/2, где A – минимальное количество объектов в течение периода, B – максимальное количество². 

Иногда бывает, что операция указывается без драйвера. Это возможно, когда драйвер трудно подобрать (например, для работы «административная деятельность») или когда не удается с приемлемой точностью определить его значение и влияние на итоговые трудозатраты (например, для работы «согласование ОРД»).

Операционный каталог было бы удобно разрабатывать, отталкиваясь от отраслевых справочников. Однако, к сожалению, общепризнанных операционных каталогов в области ИТ пока не существует, и на практике их приходится разрабатывать в основном опираясь на собственный проектный опыт.

Теперь займемся операционной моделью. Аналогично тому, как SLA связывает услуги с потребителями и уровнем предоставления, операционная модель связывает операции с исполнителями (организационной структурой и должностями) и их трудозатратами. Пример операционной модели представлен в таблице 2.

На пересечении строк и столбцов в операционной модели указываются трудозатраты (нормативные или оценочные), которые данная должность в данном подразделении тратит на единицу соответствующей работы. При этом:

1. для драйверов типа «Объект обработки» обычно указываются трудозатраты на обработку одного объекта (время на обработку одного RFC, одного запроса пользователя, ...). Иногда используются более сложные единицы измерения, позволяющие учитывать характеристики операций, например сложность (время на решение инцидента сложности 1);
2. для драйверов типа «Объект обслуживания» обычно указываются трудозатраты на обслуживание одного объекта в единицу времени³ (время, затрачиваемое специалистом на администрирование одного сервера в месяц, ...). Иногда используются единицы измерения, позволяющие учитывать характеристики объектов обслуживания, например удаленность (время на обслуживание одного банкомата удаленности 1);
3. для операций без драйверов указываются плановые трудозатраты в единицу времени (время, ежемесячно выделяемое руководителем на согласование ОРД).

Откуда берется такая оценка трудозатрат? К сожалению, отраслевая нормировка (в отличие, скажем, от строительства) в ИТ пока не развита. Есть несколько вариантов. Первый – индивидуальная нормировка, исходя из технологии выполнения операции. Так обычно действуют в случае несложных повторяемых операций (например, смена картриджа принтера или сброс пароля). Для установки норматива потребуется хронометраж, однако последующая постоянная регистрация трудозатрат необязательна – она нужна скорее для контроля соблюдения нормативов, чем для планирования ресурсов. Второй вариант – оценка, исходя из среднего за период. В этом случае желателен сбор сведений о фактических трудозатратах в течение некоторого продолжительного времени (например, квартала). Постоянный тайм-шитинг может использоваться для уточнения ранее сделанных оценок и, что очень важно, для повышения обоснованности расчета.

Планирование с помощью операционного каталога и операционной модели выполняется на основании планов работ на будущий период (в разбивке по подразделениям). Пример детализированной таблицы, представляющей потребность в ресурсах, выраженную в рабочих часах, необходимых каждой должности для выполнения каждого вида работ, представлен в таблице 3.

Элементы таблицы 3 (плановые рабочие часы) рассчитываются по формуле:

E x V x D,

где E – норматив / оценка трудозатрат из операционной модели, V – фактор объема, определяемый планом работ и типом драйвера, D – фактор времени, определяемый длительностью периода и типом драйвера: 

Далее на основании потребности в том или ином специалисте, выраженной в часах, общего количества рабочих часов в производственном календаре, количества смен и нормативного коэффициента утилизации (обычно 0,80-0,85)⁴ рассчитывается требуемая численность персонала.

Эта элементарная математика, однако, основывается на предположении, что нам известен план работ, и для согласующих органов этот план является твердым основанием для определения потребности в ресурсах. Как же нам составить такой план?

Планирование на основе объема потребления услуг

Основой для формирования плана работ, как и планов потребления других ресурсов, может являться план предоставления ИТ-услуг. В процессной модели ITIL за формирование такого плана отвечает подпроцесс Service Capacity Management процесса управления мощностями. Основа планирования – каталог ИТ-услуг.

Каталог ИТ-услуг является одним из основных системных инструментов коммуникации ИТ-поставщика с бизнес-заказчиками. Он может иметь различные представления⁵, но для управления мощностями, как минимум, необходима идентификация для каждой ИТ-услуги одной или нескольких единиц объема потребления, выраженных в терминах, понятных бизнес-заказчикам. Пример табличного представления каталога ИТ-услуг с единицами объема потребления представлен в таблице 5.

Зная единицы объема потребления ИТ-услуг, можно, взаимодействуя с заказчиками и основываясь на собственных наблюдениях, сформировать план / прогноз потребления услуг в будущем периоде.

Наконец, зная объемы потребления услуг, можно перейти от услуг к потребности в ресурсах, вызванных потреблением соответствующих услуг. Это принципиально важный шаг – он позволяет сделать всю конструкцию более обоснованной, поскольку потребность в ресурсах начинает определяться потребностями бизнес-заказчиков в ИТ-услугах. Мне известны случаи, когда бизнес-подразделения, понимая свои потребности (и, в частности, связь объема потребления ИТ-услуг со своими бизнес-планами⁶), помогали ИТ-директору в обосновании ресурсов.

Итак, дело за малым – зная объем потребления ИТ-услуг, перейти к расчету потребности в ресурсах. Как же это сделать? И здесь мы вплотную подошли к понятию сервисно-ресурсных моделей.

Традиционно под сервисно-ресурсной моделью понимают картинку (смотри пример), отображающую связь ИТ-услуг с конфигурационными единицами и связи конфигурационных единиц между собой. Действительно осознание (и наглядное отображение) этих связей является необходимой частью сервисно-ресурсной модели. Однако я считаю, что такой картинки недостаточно для формирования полноценной сервисно-ресурсной модели по двум причинам:

1. отсутствие информации о характере зависимости потребности в ресурсах от объема потребления ИТ-услуги;
2. отсутствие на таких диаграммах людей, которые, несмотря на то, что это звучит немного цинично, являются важнейшим ресурсом для предоставления ИТ-услуг.

Поэтому в дополнение к диаграммам связей между услугами и конфигурационными единицами сервисно-ресурсные модели, поддерживающие управление мощностями, должны иметь табличное представление, включающее в себя и характер зависимостей, и связи с персоналом. Такая таблица может иметь следующий вид:

Таблица описывает зависимость ИТ-услуг от трех типов ресурсов: активов (оборудования и лицензий на ПО), работ (а значит, через операционный каталог и операционную модель, – и персонала) и поддерживающих услуг⁷. В качестве параметра мощности выступают следующие показатели, характерные для процесса управления мощностями:

• единицы объема потребления;
• максимальная длительность операции;
• максимальное время отклика;
• время завершения операции (cut-off time).

В колонке «Зависимость» в общем случае указывается характер зависимости количества соответствующего ресурса от заданного параметра мощности – математическая формула или некоторое текстовое описание. Такие зависимости могут быть итогом анализа данных прошлых периодов, результатом моделирования или быть предоставлены поставщиками соответствующих технических решений. Однако, любая зависимость справедлива только в некоторых границах (например, зависимость объема оперативной памяти от количества одновременных подключений пользователей может действовать до границы в 1 000 пользователей, после чего потребуется иная конфигурация системы автоматизации и, как следствие, изменятся зависимости между параметрами мощности и количеством необходимых ресурсов). Эти границы и указываются в колонке «Ограничения».

Формирование подобных сервисно-ресурсных моделей – сложная и трудоемкая работа. Она никогда не даст 100%-ной точности, но все же позволит добиться двух крайне важных результатов:

1. повысить точность планирования;
2. построить планирование ресурсов от потребностей бизнес-заказчиков в ИТ-услугах.

Далее получившиеся требования к ресурсам (активам, внешним услугам и работам) мы подставляем в методику планирования, описанную в разделе «Традиционное планирование», и определяем потребность в персонале.

Весь процесс схематично представлен на следующем рисунке:

Выводы

Использование каталога ИТ-услуг и сервисно-ресурсных моделей позволяет построить процесс планирования потребности в ресурсах (в частности, в персонале) от потребностей бизнес-заказчиков. Это делает результаты такого планирования более обоснованными и позволяет ИТ-руководителям привлекать бизнес-заказчиков в качестве союзников при обосновании ресурсов.

Сноски

1. При ресурсном планировании проектной деятельности используется календарный план проектных работ и сведения о потребности в ресурсах, необходимых для следования этому плану.
2. При таком определении операндов эта формула может быть использована как для монотонно убывающей или возрастающей нагрузки, так и для колеблющейся нагрузки.
3. Как правило, месяц, поскольку ресурсное планирование обычно выполняется на периоды, длительность которых кратна месяцу – месяц, квартал, полугодие или год.
4. Поскольку люди не могут 100% рабочего времени эффективно работать, не отвлекаясь на непроизводственные активности, не уходя в отпуск и так далее.
5. См. статью "Управление уровнем ИТ-услуг. Часть 2. Каталог ИТ-услуг и процессы"
6. Именно для этого так важно и сам каталог ИТ-услуг, и единицы объема потребления ИТ-услуг формулировать в терминах, максимально понятных бизнес-заказчикам.
7. На самом деле, в общем случае сервисно-ресурсная модель может быть сформирована не только для услуг, но и для ресурсов. Например, одна модель отражает связь между ИТ-услугой и системами, а другие модели отражают связи систем от других ресурсов. Подобная иерархия моделей весьма характерна для сложных ИТ-архитектур крупных современных предприятий.

Автор: Дмитрий Исайченко