• Новости
• Блоги
• Аналитика
• Новости компаний
• В СНГ и в мире
• Анонсы

Формализуем работу ИТ-подразделений

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

Анализируя в компаниях положения о подразделениях ИТ, нередко сталкиваешься с отсутствием в них ключевых разделов, например раздела «Полномочия», а также с абстрактными формулировками функций и задач. Казалось бы, руководителю нет ничего проще, чем сформулировать в положении об отделе, какую работу он фактически выполняет (см. левый столбец табл. 1).

Как видно из табл. 1, в результате формализации все получается не так однозначно, как хотелось бы. Нетрудно увидеть различия между данными в левом и правом столбце, но вот как перейти от первого варианта ко второму? За кажущейся простотой темы скрывается весьма сложная методическая работа, которой часто не уделяется должного внимания.

Система ценностей

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

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

Объекты – то, чем/кем управляет или что/кого контролирует подразделение. Объекты делятся на программное обеспечение, аппаратное, организационное и кадровое.

Функция – деятельность объекта в рамках некоторой системы и конкретные действия, совершаемые над управляемым или контролируемым объектом. В технике и в психологии, выражаясь обычным языком, функция обозначает принадлежность к чему-либо, что применяется для устремлений, решения задач, намерений, достижения цели. Функция может являться частью процесса. В рамках подразделения функции бывают основными и дополнительными.

Задача – проблемная ситуация с заданной в явном виде целью, которую необходимо достичь/выполнить. В отличие от функции, которая может осуществляться постоянно, задача должна быть успешно завершена. Более узкое определение называет задачей ситуацию с известным начальным состоянием системы (как есть) и ее конечным состоянием (как будет), причем алгоритм достижения конечного состояния при движении от начального известен. Задачу возможно декомпозировать на операции. 

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

цель – выявить объекты управления и контроля подразделений ИТ;

вид – первичный;

охват – сплошной;

метод – фактический.

Подробно останавливаться на методах проведения аудита и анализа здесь не представляется возможным.

Функции и задачи

Итак, информация собрана и структурирована. Далее мы будем ее формализовать, распределив по таблицам. Взаимосвязь функций, задач и объектов (контроля или управления) при описании деятельности подразделения показана в табл. 2.

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

Рассмотрим пример: если система мониторинга реагирует на выход параметров объекта за установленные рамки только путем визуализации/оповещения о его состоянии, то она системой контроля и остается. Но если она окажет корректирующее воздействие, возвращая параметры объекта в установленные пределы, ее уже можно классифицировать как систему DCIM (но это тема отдельного обсуждения). Следовательно, управление и контроль необходимо разнести по разным таблицам – на основании их существенного отличия.

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

Разделение разработки и сопровождения между разными подразделениями обеспечивает выполнение принципа сдержек и противовесов, что становится очевидным при сравнении целей подразделений.

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

Компетентность

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

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

При выборе необходимо определиться, какие именно навыки потребуются для выполнения работ – двигательные, интеллектуальные, перцептивные. Навыки являются логическим продолжением умений, когда человек уже выполняет какие-то действия неосознанно, автоматически. Для практического осознания разницы наденьте очки/линзы, зрительно переворачивающие изображение, и попробуйте поиграть в баскетбол. Этот опыт покажет, как важно выбирать сотрудников, уже обладающих требуемыми навыками.

Требования к подчиненным в должностных инструкциях можно составлять аналогично. На описание каждой должности достаточно страницы формата А4.

Компетенции

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

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

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

Полномочия утверждать внедрение новых систем принадлежат вышестоящему руководителю, который принимает решение на основании данных и виз обоих подчиненных ему руководителей. Отметим, что «утверждающий» может согласиться с визой «согласующего», а может принять решение вопреки этой визе.

В столбце «Ответственность» необходимо задать уровень негативных последствий в случае нарушения установленных требований. Можно применять следующие виды ответственности – дисциплинарную, материальную, моральную; можно также уточнить, в какой именно мере. При привлечении к ответственности важным условием является наличие вины. Вряд ли правильно, например, привлекать к ответственности сотрудника, действия которого хотя и привели к отрицательным последствиям, но были вызваны прямым приказом непосредственного руководителя.

Завершив описание требований к сотрудникам, в последующем можно перейти к объективной оценке их деятельности. Это будет уже процесс оценки и мотивации персонала, который реально автоматизировать, если характеризовать его измеряемыми величинами. Так, добавив к табл. 4 столбец «Поощрения за достижения», мы получим систему положительной и отрицательной мотивации.

Вернемся к нашей теме и сформулируем цель деятельности. Отметим, что использовать принципы SMART не следует, поскольку требуется в большей степени описание области применения подразделения, т.е. его назначения, в соответствии с которым должны поступать приказы и распоряжения руководства.

Цель: Разработка и внедрение прикладного программного обеспечения.

Следствие 1: Исходя из цели, руководитель подразделения использует все имеющиеся у него ресурсы для ее достижения, т.е. разрабатывает и внедряет ИС. В противном случае, например если подразделение разрабатывает систему (KPI – разработано пять новых компонентов за три месяца) и не внедряет (KGI – внедрен один компонент системы из пяти за три месяца), оно будет иметь высокий KPI и низкий KGI. А это уже метрики процессного управления, указывающие на низкую результативность деятельности подразделения (в нашем случае в части Release Management).

Следствие 2: Становится очевидной балансировка ресурсов, т.е. руководитель будет выделять большее их количество на основные функции и задачи, обеспечивающие достижение цели, что потребует перераспределения функций и задач между подразделениями, исходя из критерия специализации.

Итоговый документ

В результате мы должны получить положение о подразделении объемом 15–20 страниц формата А4, примерно с таким оглавлением:

• Нормативные ссылки

• Термины и определения

• Общие положения

• Позиция в оргструктуре

• Требования к руководителю

• Функции и задачи

• Полномочия, права, обязанности, ответственность

• Показатели качества

• Календарный план систематически выполняемых задач (приложение).

Здесь можно дать следующие рекомендации: формируйте содержание документа по принципу «от общего к частному» и используйте метод ветвления. Положение является документом тактического уровня и требует соотнесения с целями компании.

После завершения работ над положением о подразделении декомпозируем его в должностные инструкции сотрудников (это документы оперативного уровня).

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

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

Вместо заключения

Формализация сфер деятельности часто приводит к интересным результатам. Например, при их описании приведенными выше методами руководитель отдела может осознать, что примерно 40% ресурсов его подразделения расходуется на дополнительные функции, задачи и объекты. Часто в результате аудита выявляются и случаи вменения обязанностей без предоставления должных полномочий. И этого оказывается достаточно для возникновения интереса к документированию деятельности.

Далее, использование описанных выше методов формализации может стать базой для постепенного перехода от функционального к процессному управлению. А результаты могут использоваться для оценки эффективности системы управления компанией.