Портал №1 по управлению цифровыми
и информационными технологиями

Об учете фактических трудозатрат специалистов

Учет трудозатрат, понесенных сотрудниками на выполнение работ, является широко распространенной практикой многих компаний. Но в каждой из них этот учет выстроен по разному.

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

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

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

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

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

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

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

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

«Flow Metrics: управление потоковым производством на основе данных»
Учебный курс про метрики на реальных примерах

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

  • Владимир Невский

    «Чем это у вас там сотрудники занимаются?» — извечный вопрос, который задают руководители компаний. ИМХО — это главное, зачем сейчас внедряют учет трудозатрат. Остальные задачи — производные, которые на самом деле и дают так называемые конкурентные преимущества. Ибо, если сотрудники показывают хороший результат, то какая руководителям разница, чем сотрудники занимаются в рабочее время?! Из этого вопроса и возникают мнения о надзорно-карательном механизме учета и как бы недоверии работодателя по отношению к работнику.

    С 2012 года мне посчастливилось разрабатывать и внедрять систему нормирования труда (учета трудозатрат) в одном из крупных банков, который был поглощён другим финансовым учреждением и должен был влиться в другую структуру. Поэтому в качестве задач внедрения формулировалось: определение фактического функционала и нагрузки ИТ-подразделений, поиск лучших практик и лучших сотрудников (типа, слабые звенья — должны идти под сокращение при слиянии компаний). Помимо основных целей, попутными оказались результаты: повысилась производительность труда (см. * ниже); установлено, что за 1 год фактическое время выполнения операций сократилось вдвое (стало понятно, что нормативы нужно корректировать); выявлена непрофильная активность (сотрудники были вынуждены указывать непрофильные работы, чтобы показать свою нагрузку) — стало понятно, что нужно вводить новые позиции в штатном расписании не ИТ-подразделений или выделять средства для приобретения внешних услуг; самая большая польза от внедрения Системы нормирования труда принесла территориально-распределенным подразделениям, в которых руководитель управлял большим количеством сотрудников удаленно и редко когда общался с подчиненными в живую; линейные руководители стали уходить от конфликта интересов (защита подчиненных, сокрытие ресурсов); началась разработка ПО по учету трудозатрат бизнес подразделений (продажи банковских продуктов) …

    (*) В физике есть такое понятие как «эффект наблюдателя»: если над системой ведется наблюдение, то оно вносит изменение в её поведение. В корпоративной среде, как только мы начинаем собирать отчеты о трудовой деятельности и считать KPI, мы вносим изменения в поведение команд и отдельных её сотрудников. Не говорю о возможных приписках (нужен выборочный контроль) — считаю, что проявляется «эффект наблюдаемого», когда исполнитель показывает более хорошие результаты, если знает, что за ним наблюдают.

    Что касается учета трудозатрат творческих профессий. Дарья Донцова с успехом ещё недавно выдавала по несколько романов в год (по контракту); фигурное катание делится на исполнение отдельно взятых элементов, где каждое движение — подлежит учету и оценке.

    Что касается недоверия, наблюдения Большого брата и т.п. Идет эра Big Data — и хотим мы этого или нет, создание генетического, поведенческого и рабочего профиля человека — не остановить, особенно если речь не идет о нарушении личного пространства. Нужно как-то научиться с этим жить и самому правильно формировать этот профиль.

  • Андрей другой

    Я не совсем понял присутствующее в заметке противопоставление « учета трудозатрат по экономически-финансовым мотивам.» и учета себестоимости. Хотя в самой же заметке признается, что «задача расчета себестоимости шире, чем контроль нормативов работ поддержки». Т.е. первый вариант есть подмножество второго. Или иначе — расчет себестоимости — это тоже экономически-финансовая деятельность. По поводу привязки затрат к КЕ не согласен, если под КЕ не подразумевается ИТ сервис. Т.е. мы производим услугу, это наша продукция, и расчитывать надо себестоимость именно услуги. Вся деятельность должна происходить в контексте производства услуги, если что-то не привязано к услуге, значит это что-то лишнее в вашей деятельности.

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

    • Здесь нет противопоставления, скорее так произошло из-за не самой лучшей верстки. В более ранней редакции смысловой абзац, закрывающий статью, стоял перед предложением про наш опыт. Абзац был перенесен, а следующее за ним повествование не было в достаточной степени изменено. Спасибо за замечание.

  • Сергей

    Доброго. С помощью учёта трудозатрат решали следующие задачи (при переводе внутренней ИТ службы крупного и распределенного по стране предприятия):

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

    — унификация ПО и поддержки (на разных филиалах разное ПО выполняло одинаковые функции, с помощью учёта трудозатрат поддержки (в том числе) выбиралось наиболее эффективное решение и далее масштабировалось на другие филиалы замещая менее эффективные решения);

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

    — прозрачность работы и защита бюджета перед Заказчиком (желание Заказчика снизить стоимость против его нежелания отказываться от поддерживаемых услуг, расчёт стоимости каждой услуги в отдельности вплоть до подуслуг или Типов заявок и Регламентных работ).

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

    • Сергей, спасибо за ответ! Проводилась ли привязка трудозатрат в вашем случае к каким-либо справочникам? Например, для выявления дублирующих функциональность систем.

      • Сергей

        Андрей, приветствую.

        Не совсем понял вопроса но попробую расширено.

        1. Трудозатраты привязывались к заявкам\таскам\регламентным работам и через них ложились на подуслуги\услуги и категории услуг.

        2. Специалистам дали права вводить трудозатраты вручную выставляя цифру в минутах (не выбирая из списка: например дорога 10 минут или дорога 20 минут)

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

        4. От тех услуг по которым было мало заявок\трудозатрат (естественно некритичных) пытались отказаться конечно же широко обсудив со службой заказчика необходимость их поддержки.

        Если что то не учёл в ответе, прошу прощения. Уточните.


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Метрики потока создания ценности
      Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки,
    • Я понял только то, что ничего не понял
      На тему услуг написано довольно много самых разных статей, т.к. оказание услуг – самый распространенный вид человеческой деятельности. Банковские услуги, гостиничные услуги, юридические услуги, логистические услуги; парикмахер, курьер, айтишник – все это деятельность в сфере услуг. Моя работа тоже относится к этой же сфере, поэтому не могу не поделиться своими наблюдениями, или, как говорится, поговорить о наболевшем.
    • DevOps-путешествие American Airlines
      Несколько лет назад компания American Airlines начала путешествие, которое первоначально было направлено на преобразование DevOps в ИТ, но в дальнейшем набирало обороты и переросло в преобразование доставки продуктов, охватывающее весь бизнес.
    • Чтение признаков: Паттерны диаграммы рассеяния (Lead Time Scatterplot)
      Научившись определять общие закономерности в диаграмме рассеяния времени цикла, вы сможете заметить проблемные области до того, как они разрастутся. Сегодня мы покажем вам, как распознать наиболее распространенные модели диаграммы рассеяния и объясним, что они означают для вашего проекта.
    • Проблемные зоны цифровой трансформации
      Управление на основе гибких методологий подразумевает наличие гибкой команды, занимающейся развитием цифрового продукта. Однако, такие команды не возникают сами собой, их
    • Чтение знаков: Паттерны Канбан CFD
      Чтобы улучшить рабочие процессы, сначала нужно понять, как определить проблемные области. Метод Канбан использует визуальные методы для оценки ваших процессов. Диаграмма совокупных потоков Канбан является особенно мощным инструментом. На них фиксируется количество задач в каждом состоянии процесса через регулярные промежутки времени, как правило, ежедневно или еженедельно.
    • Краткое руководство по DevOps для не ИТ-руководителя бизнеса
      Тщательно продумайте, как выглядит успех. В цифровом мире это скорость, гибкость, контроль и оперативность, а не составление планов и следование им. Именно эти новые ИТ-практики принесут вам эти преимущества. Они уже принесли их многим другим предприятиям, которые встали на этот путь и, в некоторых случаях, разрушили отрасли.
    • 8 тенденций развития IT Service Desk в 2022 году
      Корпоративная служба поддержки ИТ в настоящее время находится в «идеальном шторме» для изменений или, точнее, в «идеальном шторме» для необходимости изменений. Случилось так
    • 6 худших вещей, которые продакт-менеджеры говорят инженерам
      Каждый хороший продакт-менеджер — полиглот. Он говорит на нескольких языках. Конечно, вы можете не говорить бегло на французском, итальянском или мандаринском. Но вы
    • На какой курс пойти, чтобы узнать про практику Х?
      Этот вопрос вы, наши слушатели, задаёте довольно часто. К тому же появились новые курсы категории VAP. Так что было бы удобно иметь под рукой справочник. Ну что же, вот оно:
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT