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

Дурацкая задача – когда ожидаемая от реализации польза не оправдывает количества необходимых ресурсов, но Заказчик настаивает на необходимости её выполнения.

О

• управлении потоком задач на разработку,
  Как избавится от «дурацких» задач?
• управлении расходами на разработку,
  Как определить и выбрать самые выгодные задачи?
• распределении ограниченных ресурсов.
  Как сделать так, чтобы все Заказчики были довольны, а количество ресурсов при этом осталось тем же?

Суть проблемы и её причины

Кратко о компании, чтобы обозначить контекст ситуации. По типу деятельности — Регулятор рынка ипотечного кредитования. Отрасль — Финансы. Масштаб — Федеральный. Партнерская сеть от Владивостока до Калининграда с организацией взаимодействия с Партнерами через ИТ-системы компании. Направление работы ИТ — разработка и доработка собственных корпоративных информационных систем, поддерживающих бизнес-процессы как внутри Компании, так и на стороне Партнеров. Бюджет на развитие КИС — 100 млн.рублей в год. КИС поддерживает бизнес объемом в 60 млрд.рублей в год. Количество пользователей КИС — >2000 человек.

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

Основная жалоба Заказчиков (внутренних Бизнес-Подразделений) – ДИТ работает неэффективно и не делает то, что просят.

Заказчики при этом апеллируют к цифрам что за квартал из 40 запросов сделано всего 5. И так по каждому заказчику: бухгалтерии, финансовому, юридическому департаменту, департаменту покупки закладных….

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

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

Причины большого потока задач:

1. Объем выделенного бюджета на развитие КИС позволяет многое реализовать в ней.
2. Большое количество локальных решений на основе Excel и Access на отказ от которых задано направление развития КИС.
3. Пользователи и Заказчики, привыкшие к тому, что каждый запрос реализуется.
4. Сотрудники ДИТ, привыкшие к тому, что всё равно что делать, что попросят то и сделают.

На рисунке морально-психологическое состояние директора ДИТ при изучении списка запросов из которых он должен выбрать те, что мы будем делать.

Шаг №1: Введение Технико-Экономического Обоснования для ИТ-запросов

Начали мы с того что ввели ТЭО для запрашиваемых разработок / доработок и внедрений ИТ-решений.

ТЭО состояло из оценки трудоемкости реализации задачи и ожидаемого экономического эффекта. Трудоемкость реализации предоставлял ДИТ, оценку экономического эффекта — Заказчик. Обоснование показало какие задачи способны себя окупить и за какой период.


По предложению ДИТ, Руководство Компании и Бизнес-Подразделений решило, что Компания не тратит ресурсы/бюджет на задачи, где отсутствует экономическая выгода. Если решение задачи способно принести Компании существенную не экономическую выгоду, то это должно быть прописано в обосновании и на этом заострено внимание Управляющего Комитета, который авторизует данные запросы.

Так как в КИС работали и сотрудники Партнеров, мы считали экономический эффект от реализации задач и для них. Для Компании прямой экономической выгоды здесь могло и не быть, но таким образом мы повышали привлекательность и выгодность сотрудничества с Компанией. Мы делали доработку на «1 рубль», а экономический эффект от неё получали все 200 Партнеров.

Указанное решение привело к тому, что свело на «нет» огромный поток запросов с мелкими и «дурацкими» доработками, которые не приносили добавочной стоимости, но расходовали ресурсы.
Период, когда сотрудники пытались автоматизировать всё что могло быть автоматизировано, чтобы ничего не делать руками, закончился.

ТЭО привело ситуацию к тому, что теперь ресурсы ДИТ были сосредоточены на самых выгодных для компании задачах и проектах. Оно решило первую часть проблемы, теперь ресурсы использовались эффективно. Оставалась вторая — Заказчики по прежнему были не довольны тем, что ДИТ не делал то, что просят.

На рисунке изменение в лучшую сторону морально-психологического состояния директора ДИТ при выборе запросов на реализацию.

Шаг №2: Выделение ИТ-бюджета на каждого Заказчика

Каждому Бизнес-Подразделению устанавливались на год показатели (KPI), которых оно должно достичь. Для достижения этих показателей Бизнес-Подразделения порождали запросы в ДИТ на предоставление необходимых ИТ-решений. Ситуация с ТЭО привела к тому, что задачи зарабатывающих подразделений получали больше ресурсов, а обслуживающие (тратящие) подразделения оказались на положении «бедных» родственников.

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

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

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

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

Что получили

1. Задачи, которые целесообразно делать с точки зрения выгоды для бизнеса компании.
2. Обеспечили реализацию задач и проектов каждого подразделения без необходимости сравнивать важность задач подразделений между собой.
3. Предоставили Бизнес-Подразделению возможность самостоятельно решать на реализацию каких ИТ-запросов направить бюджет для достижения годовых плановых показателей.
4. Планирование расходования бюджета с Бизнес-подразделением так, чтобы его хватило на год и все самые важные инициативы были реализованы.
5. Возможность выходить на Бюджетный Комитет с предложением по увеличению ИТ-бюджета компании подкрепленным перечнем задач Бизнес-Подразделений с положительным ТЭО, которые не были реализованы в прошлом году в виду недостатка бюджета.

На рисунке “Happy End”.

Послесловие

ТЭО Бизнес-Подразделениям было не нужно, они в нем не были заинтересованы.
Во-первых — они хотели всё что просят.
Во-вторых — получаемый экономический эффект потом проверят.
За то ТЭО было понятно и нужно Руководству Компании, поэтому этот инструмент внедрялся по решению «сверху».
На то, чтобы научить Бизнес-Подразделения формировать внятное ТЭО ушел не один год.

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

Что почитать по теме

1. Стратегии формирования портфеля заказов на предприятии, выпускающем продукцию под заказ
2. Оптимизация работы веб-студии. Применение теории ограничений в производстве сайтов
3. Применение Теории Ограничений Систем для постановки процесса

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

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