Сперва рассчитать, потом рисковать.
Хельмут фон Мольтке

 

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

Задача

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

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

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

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

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

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

 

Таблица 1. Пример операционного каталога

 

Работа Драйвер Ед. объема
Экспертиза доработок  RFC  Кол-во RFC в ед. времени
Типовая поддержка пользователей  Запрос  Кол-во запросов в ед. времени
Экспертная поддержка пользователей  Запрос  Кол-во запросов в ед. времени
Смена сертификатов безопасности  Сертификат  Кол-во сертификатов
Администрирование серверов Windows  Сервер  Кол-во серверов
Администрирование серверов *nix  Сервер  Кол-во серверов
Согласование ОРД  -  -
...  ... 

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

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

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

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

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

 

Таблица 2. Пример операционной модели

 

Подразде-
ление
Ресурс Экспертиза
доработок
Типовая
поддержка
Админ.
win-
серве-
ров
Админ.
*nix-
серве-
ров
Согла-
сование
ОРД
час / RFC час / 
запрос
час / (сервер * мес) час / (сервер * мес) час / мес
Отдел 1 Начальник отдела 0,5 - - - 12,0
Отдел 1 Ведущий аналитик 8,0 0,5 - - -
Отдел 1 Аналитик 1,0 - - - -
Отдел 2 Начальник отдела 6,0 - - - 12,0
Отдел 2 Старший администратор - 0,5 1,0 1,0 -
Отдел 2 Администратор - 1,0 4,0 8,0 -

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

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

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

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

 

Таблица 3. Потребность в трудовых ресурсах

 

Подраз-
деление
Ресурс Экспертиза
доработок
Типовая
поддержка
Админ.
win- серверов
Админ.
*nix- серверов
Согла-
сование ОРД
Итого
Фактор времени (T)  1 1 12 12 12 -
Отдел 1 Фактор объема (V) 500 5000 - - 1 -
Отдел 1 Начальник отдела 250 - - - 144  394
Отдел 1 Ведущий аналитик 4000 2500 - - -  6500
Отдел 1 Аналитик 500 5000 - - -  5500
Отдел 2 Фактор объема (V) 500  1250  100  10  1  -
Отдел 2 Начальник отдела 3000 - - - 144  3144
Отдел 2 Старший администратор - 625 1200 120 -  1945
Отдел 2 Администратор - 1250 4800 960 -  7010

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

E x V x D,

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

 

Таблица 4. Расчет факторов объема и времени

 

Вид драйвера Фактор времени (D) Фактор объема (V)
Объект обработки 1 Количество операций в период планирования
Объект обслуживания Количество месяцев в периоде планирования Количество объектов обслуживания
- (операция без драйвера) Количество месяцев в периоде планирования 1

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

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

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

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

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

 

Таблица 5. Фрагмент каталога ИТ-услуг с единицами объема потребления

 

Услуга Ед. объема потребления 1 Ед. объема потребления 2 Ед. объема потребления 3 ...
Специализированные услуги
ИТ-обеспечение кредитования юридических лиц Кол-во кредитных договоров Общее кол-во потребителей услуги Кол-во одновременных подключений ...
ИТ-обеспечение дистанционного банковского обслуживания Кол-во клиентов Кол-во одновременных подключений Среднее кол-во операций на 1-го клиента в день ...
... ... ... ... ...
Базовые услуги
Электронная почта Кол-во почтовых ящиков и списков рассылки Среднее кол-во сообщений на одного абонента в день Предельный размер почтового ящика ...
Базовое рабочее место Кол-во локальных рабочих мест Кол-во удаленных рабочих мест - ...
Мобильное рабочее место Кол-во рабочих мест - - ...
... ... ... ... ...

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

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

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

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

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

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

 

Таблица 6. Пример табличного представления сервисно-ресурсной модели

 

Ресурс Подразделение Зависимость Ограничения
Актив 1 Отдел 1 F1(Параметры мощности  ...
Актив 2 Отдел 2 F2(Параметры мощности  ...
Работа 1 Отдел 1 F3(Параметры мощности  ...
Работа 2 Отдел 2 F4(Параметры мощности  ...
Услуга 1 Отдел 1 F5(Параметры мощности  ...
Услуга 2 Отдел 2 F6(Параметры мощности  ...

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

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

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

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

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

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

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

staff planning fig2

Выводы

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


Сноски

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

 

Менеджеры по работе с клиентами

Карина Усищева
Карина Усищева
Марина Колесникова
Марина Колесникова
Анжелла Шленская
Анжелла Шленская