О том, когда задач больше чем ресурсов на их выполнение, очередь задач со временем увеличивается и часть из них можно смело назвать «дурацкими».
Дурацкая задача – когда ожидаемая от реализации польза не оправдывает количества необходимых ресурсов, но Заказчик настаивает на необходимости её выполнения.
О
- управлении потоком задач на разработку,
Как избавится от «дурацких» задач? - управлении расходами на разработку,
Как определить и выбрать самые выгодные задачи? - распределении ограниченных ресурсов.
Как сделать так, чтобы все Заказчики были довольны, а количество ресурсов при этом осталось тем же?
Суть проблемы и её причины
Кратко о компании, чтобы обозначить контекст ситуации. По типу деятельности — Регулятор рынка ипотечного кредитования. Отрасль — Финансы. Масштаб — Федеральный. Партнерская сеть от Владивостока до Калининграда с организацией взаимодействия с Партнерами через ИТ-системы компании. Направление работы ИТ — разработка и доработка собственных корпоративных информационных систем, поддерживающих бизнес-процессы как внутри Компании, так и на стороне Партнеров. Бюджет на развитие КИС — 100 млн.рублей в год. КИС поддерживает бизнес объемом в 60 млрд.рублей в год. Количество пользователей КИС — >2000 человек.
На момент моего прихода в компанию ситуация выглядела так, что Департамент ИТ давно утонул в потоке задач на автоматизацию бизнес-процессов и доработку тех, что уже покрыты ИТ-решениями.
Основная жалоба Заказчиков (внутренних Бизнес-Подразделений) – ДИТ работает неэффективно и не делает то, что просят.
Заказчики при этом апеллируют к цифрам что за квартал из 40 запросов сделано всего 5. И так по каждому заказчику: бухгалтерии, финансовому, юридическому департаменту, департаменту покупки закладных….
Поработав некоторое время я уже воспринимал эту ситуацию лично. Ты стараешься сделать что-то хорошее и сделать это хорошо для своего Заказчика, но в конечном итоге ты всё равно плохой для него.
Это та ситуация, когда быть результативным руководителем проектов и «деливерить» недостаточно.
Причины большого потока задач:
- Объем выделенного бюджета на развитие КИС позволяет многое реализовать в ней.
- Большое количество локальных решений на основе Excel и Access на отказ от которых задано направление развития КИС.
- Пользователи и Заказчики, привыкшие к тому, что каждый запрос реализуется.
- Сотрудники ДИТ, привыкшие к тому, что всё равно что делать, что попросят то и сделают.
На рисунке морально-психологическое состояние директора ДИТ при изучении списка запросов из которых он должен выбрать те, что мы будем делать.
Шаг №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 Партнеров.
Указанное решение привело к тому, что свело на «нет» огромный поток запросов с мелкими и «дурацкими» доработками, которые не приносили добавочной стоимости, но расходовали ресурсы.
Период, когда сотрудники пытались автоматизировать всё что могло быть автоматизировано, чтобы ничего не делать руками, закончился.
ТЭО привело ситуацию к тому, что теперь ресурсы ДИТ были сосредоточены на самых выгодных для компании задачах и проектах. Оно решило первую часть проблемы, теперь ресурсы использовались эффективно. Оставалась вторая — Заказчики по прежнему были не довольны тем, что ДИТ не делал то, что просят.
На рисунке изменение в лучшую сторону морально-психологического состояния директора ДИТ при выборе запросов на реализацию.
Шаг №2: Выделение ИТ-бюджета на каждого Заказчика
Каждому Бизнес-Подразделению устанавливались на год показатели (KPI), которых оно должно достичь. Для достижения этих показателей Бизнес-Подразделения порождали запросы в ДИТ на предоставление необходимых ИТ-решений. Ситуация с ТЭО привела к тому, что задачи зарабатывающих подразделений получали больше ресурсов, а обслуживающие (тратящие) подразделения оказались на положении «бедных» родственников.
У первых проекты были направлены на то, чтобы больше зарабатывать, а у вторых на то, чтобы сэкономить. Экономить/повышать эффективность собственной работы было менее выгодно, чем придумывать решения о том как зарабатывать больше. Обусловлено это было тем, что
рынок ипотечного кредитования рос.
Так как ДИТ принимал решение о том какие задачи реализовывать и куда направлять бюджет, это породило обвинения в адрес ДИТ, что мы игнорируем задачи сервисных бизнес-подразделений и отдаем предпочтение задачам зарабатывающих.
Решение пришло не сразу, так как с одной стороны всё было в порядке. Ресурсы попадают в самые выгодные для компании задачи и проекты. С другой стороны, выходит что неправильно ставить перед подразделениями показатели, которых они должны достичь, и не обеспечивать их необходимыми ресурсами для этого.
Приняли решение поделить бюджет между подразделениями в соответствии с накопленным объемом авторизованных задач. Для этого посчитали объем требуемых ресурсов на реализацию всех задач и определили долю задач каждого бизнес-подразделения в этом объеме. В этих долях «роздали» бюджет.
ДИТ по прежнему отвечал за бюджет, но теперь каждое бизнес-подразделение само решало на какие задачи, на достижение каких годовых показателей, направить выделенную ему сумму.
Так решили вторую часть проблемы, делали то, что просит Бизнес-Подразделение в рамках имеющихся у него для этого возможностей.
Что получили
- Задачи, которые целесообразно делать с точки зрения выгоды для бизнеса компании.
- Обеспечили реализацию задач и проектов каждого подразделения без необходимости сравнивать важность задач подразделений между собой.
- Предоставили Бизнес-Подразделению возможность самостоятельно решать на реализацию каких ИТ-запросов направить бюджет для достижения годовых плановых показателей.
- Планирование расходования бюджета с Бизнес-подразделением так, чтобы его хватило на год и все самые важные инициативы были реализованы.
- Возможность выходить на Бюджетный Комитет с предложением по увеличению ИТ-бюджета компании подкрепленным перечнем задач Бизнес-Подразделений с положительным ТЭО, которые не были реализованы в прошлом году в виду недостатка бюджета.
На рисунке “Happy End”.
Послесловие
ТЭО Бизнес-Подразделениям было не нужно, они в нем не были заинтересованы.
Во-первых — они хотели всё что просят.
Во-вторых — получаемый экономический эффект потом проверят.
За то ТЭО было понятно и нужно Руководству Компании, поэтому этот инструмент внедрялся по решению «сверху».
На то, чтобы научить Бизнес-Подразделения формировать внятное ТЭО ушел не один год.
Деление бюджета между бизнес-подразделениями повлекло проведение организационных изменений внутри ДИТ. Каждое бизнес-подразделение было закреплено за конкретным Руководителем Проектов. В последствии введена позиция Руководителя Направления. В зону её ответственности вошли управление бюджетом и портфелем проектных и не проектных ИТ-запросов бизнес-подразделения.
Что почитать по теме
- Стратегии формирования портфеля заказов на предприятии, выпускающем продукцию под заказ
- Оптимизация работы веб-студии. Применение теории ограничений в производстве сайтов
- Применение Теории Ограничений Систем для постановки процесса
Поделитесь в комментариях своими «кейсами» и ссылками на известные вам истории по теме. Этим вы поможете мне собрать, а другим читателям получить обзор практики.
Если после прочтения статьи у вас возникло желание потревожить мою карму Минусом, то оставьте ниже комментарий к нему, что в статье и моей личности вас задело и не понравилось. Учту вашу позицию и мнение в будущем.
