Управление потоком задач на разработку. История из жизни

в 7:08, , рубрики: CRM-системы, ERP-системы, пример применения ТЭО, распределение ограниченных ресурсов, технико-экономическое обоснование, управление задачами на разработку, управление заказами на разработку, управление запросами на разработку, управление ИТ-бюджетом, управление ограниченными ресурсами, Управление продуктом, управление проектами, управление разработкой, управление расходами на разработку, метки: , , , , , , , ,

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

Управление потоком задач на разработку. История из жизни

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

О

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

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

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

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

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

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

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

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

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

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

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

image

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

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

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

Пример ТЭО

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

  • Реализовать механизм передачи в Сервис сканированной копии кредитного договора и соответствующего ему эталона;
  • Реализовать механизм обработки от Сервиса распознанного документа и результатов сверки.

ТЭО
Оценка трудоемкости реализации: 1 300 000 рублей.
Ожидаемый экономический эффект: Сокращение времени на вычитку кредитного договора (около 15 страниц), проверки соответствия шаблону и наличия изменений с 20 минут до 5. Средний ежемесячный поток кредитных договоров 3 500 штук. Час работы Эксперта стоит 523 рубля. Ожидаемая экономия = (15 минут * 3 500 КД) / 60 минут * 523 рубля = 457 625 рублей в месяц.
Срок окупаемости: 1 300 000 / 457 625 = 2,8 месяца.
Срок реализации: 3 месяца с момента направления в работу / на реализацию.

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

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

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

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

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

image

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

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

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

рынок ипотечного кредитования рос.

image

 

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

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

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

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

Что получили

 

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

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

image

Послесловие

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

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

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

 

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

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

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

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js