Оперативный поиск и визуализация узких мест в работе с заказчиком

Меня зовут Алексей Русаков, я руководитель направления развития в компании «ПИИТ». Хочу рассказать о нашем опыте взаимодействия с крупным заказчиком – о том, с какими проблемами мы сталкиваемся и какие решения помогают сделать нашу работу более прозрачной, эффективной и управляемой.

Немного расскажу об особенностях нашего заказчика:

• Это крупнейший в России и четвертый в мире производитель подвижного состава, с 25 заводами и 85 сервисными депо, расположенными по всей стране В компании работает более 100 тысяч сотрудников, а число пользователей системы превышает 60 тысяч, из которых более 10 тысяч работают одновременно.

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

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

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

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

Внутренние проблемы и решения

Наша компания насчитывает почти 500 человек – это 200 консультантов, 100 разработчиков и почти 200 человек, которые занимаются администрированием инфраструктуры. Такое большое количество персонала связано с тем, что весь блок ИТ у заказчика сопровождаем мы, а его предприятия размещены по всей территории России – получается более 200 предприятий, на которых необходимо иметь сотрудников.

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

Расскажу, с какими внутренними проблемами мы сталкиваемся:

• Распределение ответственности. Понятно, что любая коммерческая организация должна приносить прибыль. Но мы решили, что неправильно завязывать на это KPI руководителей ИТ, тимлидов, руководителей поддержки и инфраструктуры. Мы от этого ушли, чтобы сотрудники полностью были погружены в свои текущие рабочие процессы. Потому что, если ты занимаешься поддержкой, ты в первую очередь должен отвечать за поддержку и взаимодействие с заказчиком. А если ты разработчик, ты должен отвечать за реализацию функциональности в системе. А финансовая сторона – это задача административного персонала, сотрудников кадровой службы, бухгалтерии и генерального директора. Поэтому первое, что мы сделали – это полностью убрали у руководителей из KPI ответственность за финансирование. У них остается ответственность только за направление. Причем, хотя направления разделены по заводам, их оценка эффективности не привязана к прибыльности конкретного предприятия. Поясню, почему я про это рассказываю: мой знакомый работает в банковской сфере, и когда его перевели с одного банка на другой, что автоматически увеличило его зарплату, так как новый проект оказался более рентабельным. С моей точки зрения, это нелогично, поскольку работа и уровень ответственности остались прежними. Поэтому у нас оплата труда сотрудников не зависит от прибыльности того или иного завода, она определяется только их компетенцией и профессиональными навыками.

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

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

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

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

Взаимодействие с заказчиком

Расскажу о том, как мы взаимодействуем с заказчиком.

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

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

Когда заказчик выражает такое желание, и мы предлагаем ему перевести под это направление сотрудников и делаем это в 1С:ITIL.

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

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

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

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

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

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

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

Если у нас есть запланированный проект на следующий месяц, сэкономленный бюджет позволяет профинансировать его досрочно. В такой ситуации заказчик может спросить: «Можем ли мы договориться, чтобы в последние две недели работы вы подключились к проекту по себестоимости?» Обычно такой вопрос решается за 15 минут. Мы находим консультанта-аналитика, который оперативно подключается к работе и погружается в проблему заказчика. Поиск происходит за счет перераспределения между заказчиками, так как зачастую сэкономленный бюджет в 1,5 миллиона подразумевает, что по другим заказчикам был перерасход на 1,5 млн.

Вопросы и ответы

Вы сказали, что у вас планерки по 10 минут, а численность ИТ блока – больше 400 человек.

Планерка проводится по одному направлению в рамках одного завода, а в одном направлении у нас максимум 34 человека. У программистов численность составляет около 15-20 человек. А в отдельных направлениях по себестоимости или по бюджетированию на заводах – еще меньше.

Вы говорите, что в планерке участвует 30 человек. Получается, что если 10 минут поделить на 30 человек, это 20 секунд на человека?

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

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

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

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

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

Разумеется, есть очередь.

Мы не называем наши направления проектами, но по факту это проекты. Допустим, по направлению «Расчет себестоимости» у нас расписана стратегия на несколько лет, и эти несколько лет у нас расписаны на порядка 200 проектов, которые нужно по порядку сделать.

И точно так же – по каждому направлению.

Как заказчики управляют переключением ресурсов от одного завода к другому? У вас 7-летние программы, у каждого заказчика есть чем заниматься целые 7 лет. Как он решается отдать свою часть ресурсов другому заводу?

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

Раз в неделю функциональные руководители ставят задачи – делается срез на неделю и устанавливается бюджет.

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

По итогам недельного среза заказчик видит остаток бюджета по каждому из направлений.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.