Проблемы роста маленькой ИТ-команды: процессы или найм?

Опубликовано 2 апреля 2013

Рубрики: IT Governance, ITSM, Аналитика: точка зрения, Всё это - ЛЮДИ, Процессы

Комментарии

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

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

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

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

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

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

У меня такая картинка и слова сложились после общения с подобной небольшой командой:

Процессы – это интенсивный способ повышения производительности ИТ-службы
Увеличение штата – это экстенсивный способ.

А последовательность выбора из этих двух должна быть строгой:

Достигай предела интенсивного роста.
Затем обеспечивай экстенсивный рост.
Когда до предела производительности в имеющихся ресурсах есть еще немного места – вот тут для процессов самое время. Процессы позволят достигнуть предела производительности опять, т.е. вернуться на шаг 1.

Резюмирую: Новые ИТ-процессы не нужны тем ИТ-командам, в которых высока специализация труда и нагрузка на исполнителей.

Как вы думаете, коллеги, можно ли численно определить, сколько еще запаса времени, сил, желания должно оставаться во всё более нагружаемой ИТ-команде, чтобы успешно начать играть в ИТ-процессы?

БИЗНЕС-СИМУЛЯЦИИ

Профессиональные деловые игры

для ИТ-департаментов и ИТ-компаний

Комментариев: 10

Станислав Уштей
02.04.2013

Процесс – это конвейер. Это собственно Ваша (Сleverics) позиция.
“…сколько еще запаса времени, сил, желания должно оставаться..” – для конвейера этот вопрос неактуален.

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

Я бы сказал что времени уже не осталось – кому-то становиться лидером, превращая остальных в ресурс. и Ему-то принимать решения – на сколько для него эффективны “бездушные конвейеры”
- Ответить
- Константин Нарыжный
  03.04.2013
  
  Станислав, конечно же конвейер. Но только на высоком уровне зрелости. А до него, в малой, специализированной команде, применимы и другие инструменты управления (как ниже Владимир написал), например, микроменеджмент, инструменты личностной мотивации сотрудников – вот всё то, что лидер должен уметь делать. Так что еще можно поспекулировать на тему того, что на конвейере лидер не нужен.
  Ответить
Vladimir Ivanov
02.04.2013

Ну а для управления “конвейером” есть свои инструменты…
Lean http://en.wikipedia.org/wiki/Lean_manufacturing
Six Sigma http://en.wikipedia.org/wiki/Six_Sigma

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

“…У англичан ружья кирпичом не чистят: пусть чтобы и у нас не чистили, а то, храни бог войны, они стрелять не годятся…”
- Ответить
Вадим
02.04.2013

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

Ответ же на последний вопрос – да, можно. нужно всего лишь ))) собрать достаточную статистику и нормировать по времени (например) выполняемые операции. Однако это уже другой уровень зрелости: одним махом не допрыгнуть.
- Ответить
- Константин Нарыжный
  03.04.2013
  
  Вадим, мне тоже кажутся спорными эти идеи, поэтому и пытаюсь их осмыслить с помощью обсуждения.
  Я писал о таких командах, как например: начальник, сисадмин, бизнес-аналитик (пишет ТЗ), программист 1С, телефонист. Возможность подмены в таком коллективе, согласитесь, ниже.
  > а руководитель ИТ коллектива вместо того, чтобы оперировать рисками деградации этого качества, понятными заказчику
  Руководитель как раз этими рисками и мотивирован на увеличение штата. Он, в отличие от заказчика, понимает, что вот-вот произойдет нечто, с чем его команда не справится – окажутся неспособны устранить сбой, или реализовать новую хотелку к “вчерашнему сроку”. Как доказать заказчику, не запугивая его этими рисками – вот запрос руководителя, о котором я говорил. И об этом же вы пишете ниже: ему нужно собрать статистику. Объективность этой статистики и нормировку дадут ему процессы. Так ему кажется, по крайней мере.
  Ответить
  - Вадим
    03.04.2013
    
    Тогда ладно))) соглашусь с этим )))
    Между прочим, много лет назад (блин, действительно уже много лет назад, еще до эпохи ITIL’а) я как раз работал в подобном коллективе и имел сомнительное счастье наблюдать ряд авралов, типа умирания сервера))) и пинания воздуха всем коллективом компании в течение недели (а может даже и более)… кончилось дело тем, что купили новый сервер и еще какое-то время потратили на его запуск и т.п.
    Так что, как видите, ситуация мне вполне знакома.
    В более близкие ITIL’овские времена, также неоднократно сталкивался с клиентами, у которых “те же десять айтишников”, что и 5-10 лет назад, практически за ту же зарплату тащат кратно увеличенный объем работ. Так практически во всех подобных случаях что начальник ИТ, что сотрудники видят выход в автоматизации, а не в процессе (точнее только в автоматизированном процессе), для чего пытаются нарыть либо бесплатные, либо недорогие (типа Itilium’а и т.п. – не реклама) решения для работы с инцидентами и т.п. CFG и SLM рассматриваются редко. С управлением финансами, кстати, дела обстоят по-разному: кому-то я бы твердую “пятерку” поставил бы, а кто-то ни бе, ни ме, ни кукареку. А ведь это тот самый язык, с использованием которого нужно говорить с заказчиком.
    
    Ответить
Роман Журавлёв
02.04.2013

Сразу несколько комментариев родилось.

1. Не всякий процесс – конвейер. Конвейер – это предопределенные операции и минимум потерь между ними. Так не может работать, например, управление проблемами, во многих случаях – управление изменениями, иногда даже управление инцидентами (major incident review). Для всех этих процессов во многих случаях эффективнее модель “мастерская” – когда все, кто нужен, собираются вместе и вместе анализируют ситуацию, определяя следующие шаги.
Мне кажется, что в заметке термин “процесс” указывает на степень формализации и контроля, а не на предопределенность цепочки получения результата. Поэтому и термин “конвейер”, и соответствующие техники применимы к описываемой ситуации ограниченно.

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

3. Но с чем я точно согласен, так это с тем, что процессы из книжек не помогают снижать затраты в краткосрочной перспективе. И качество, кстати, тоже в краткосрочной перспективе не повышают. И рисков скорее добавляют. СМК – это здоровый образ жизни, гомеопатия и физкультура, а от них мало толку, когда нужна экстренная операция.

Поэтому я бы резюмировал так: новые ИТ-процессы не нужны тем ИТ-командам, в которых кризис. Они нужны тем ИТ-командам, в которых развитие.

4. Ну и про кирпич я согласен, конечно, тоже.
- Ответить
Сергей Посыльный
02.04.2013

Считал что качественный учёт в одном-двух первоначальных процессах, займёт дополнительно 5-10% времени специалистов и минимум 40% Старших групп (команд). Если люди готовы напрячься в краткосрочной перспективе что бы обосновать необходимость найма дополнительных специалистов – они сделают это, если уже предел – они побегут.
Надо беседовать, выяснять, и конечно агитировать если необходимо..
- Ответить
Дмитрий Исайченко
02.04.2013

“А последовательность выбора из этих двух должна быть строгой: 1 … 2 … 3 …”

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

Напоминает из “Формула любви”:
…
— Ну, ежели постараться — можно и за пять.
— А за десять?
— Ну, барин, ты задачи ставишь! За десять дён одному не справиться, тут помощник нужен — хомо сапиенс!
— Бери помощников, но чтобы не раньше!
…

“Руководитель надеется, что объективную отчетность о трудовой нагрузке сможет дать ему процессная модель управления” – а без процессной модели отчетности нет или она не объективна?
- Ответить