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

Приоритеты изменений

questionsБольшинство ИТ-департаментов известных мне компаний постоянно находятся под стрессом входящего потока изменений. Общее время, требуемое для реализации изменений, ожидающих обработки, с учетом имеющихся ресурсов и трудоемкости задач, как правило, составляет 6+ месяцев, а нередко – и более года. «Взять все и поделить выполнить» не получается – на входе прибывает быстрее, чем ИТ-специалисты успевают разгребать. Значит нужно расставлять приоритеты. Но как это сделать на практике?

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

Первый – совместное обсуждение, где подразделения договариваются между собой. Трудный метод, поскольку каждое подразделение в первую очередь понимает свои задачи и осознает именно их, как наиболее важные (во всяком случае, как наиболее важные с точки зрения своих KPI). Выполнить объективное сравнение известными методами оценки инвестиционных проектов (NPV, IRR, …) не всегда возможно – недостаточно входных данных. А, кроме того, многим «бизнесменам» эти методы понятны еще менее чем ИТ-руководителям. В итоге «кто громче кричит, тот больше прав», а остаться крайним больше всех рискует ИТ-руководитель, ведь это он не успел сделать счастливыми всех.

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

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

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

«VAP: Управление изменениями и конфигурациями в ИТ»
Повысить долю успешных изменений, снизить риски, знать всё про конфигурации

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

  • Денис

    У нас работает "Комитет по изменениям" (уже 2 года), который рассматривает накопленный список заявок на изменения и исходя из ограниенных ресурсов формирует список изменений на ближайший квартал. Дальше глядеть пока не получается. Все задачи ограничены кварталом.Участники комитета – руководители бизнес-подразделений во главе с генеральным директором. если руководителям не удается договориться – решающее слово за генеральным.

    • И работает? В смысле удается договариваться, решения принимаются осознанно, практику "кто громче кричит, тот больше прав" удается подавить оргмерами?

      • Денис

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

    • Андрей

      Добрый день.

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

      Если не сложно, когда будет время напишите пожалуйста на maniukhin@telsgroup.by

  • Александр

    ХА! Как раз рисую презентацию на защиту второго способа! Но чем больше структура (а у меня очень большая), тем меньше людей хотят брать на себя личную ответственность и придумывают "комитеты" и прочие "органы" размыливающие ответственность  и увеличивающие сроки. Поэтому я попробую второй вариант протолкнуть и если выйдет – расскажу 🙂

  • Anton

    В одной из практик встретил такую приоритеацию изменений: "если сумма изменения не влезает по ширине в ячейку exel, то это изменение не стандартное и требует согласования на верху".

     

    • Александр Майорченко

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

      • Сергей

        и валюту, в которой записывается сумма.

  • Александр

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

    В европейском подразделении, обслуживающем страны EU, комитет формально суща\ествует с беклогом на 12 месяцев. На практике приоритеты зачастую переставляются топами в угоду политической конъюктуре.

  • Николай

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

    Данный подход всецело поддерживается директором по ИТ и генеральным.

    • Данный подход всецело поддерживается директором по ИТ и генеральным

      И снова я слышу ключевые слова…

      Хотя сам подход, конечно, нетрадиционен. Я сам должен убедить моих коллег, что мое изменение более важно… Николай, разрешите пару уточнений:

      1. Размер компании?

      2. Профиль деятельности компании?

      • Николай

        Дмитрий, конечно:

        1. 12000+ сотрудников, 2000+ розничных точек.

        2. Федеральный ритейлер.

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

          • Николай

            ошибся веткой.

            Чуть более 6 месяцев.

            Но справедливости ради отмечу, что из 12000+ сотрудников, в роли инициаторов доработок выступают только офисные сотрудники, а это 1200+ человек. при этом, в качестве Заказчика определяется сотрудник, занимающий позицию уровня ТОП/заместитель ТОП/Руководитель Службы. Т.е. более развернуто получается так: инициатор внутри своего департамента защищает необходимость доработки, заручается поддержкой руководителя и уже этот руководитель указывается как Заказчик. Такой подход дает нам не более 10-20 Заказчиков в очереди.

            • Александр

              Уточните пожалуйста еще какая минимальная ресурсоемкость задачи для того что бы ставить ее в общую очередь? Например добавляете ли вы запрос на изменение весом в 2 ч/ч в очередь на исполнение через ХХ месяцев?
               

              • Николай

                В очередь ставятся абсолютно все задачи по доработке. Есть исключения для мелких доработок из разряда "поменять цвет вот у этой кнопки" – но это редкость и, скорее, является исключением из правил.

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

    • Александр

      на портале указывается актуальный статус и плановый срок начала работ по данной задаче и ожидаемый срок завершения/внедрения

       

      Уточните пожалуйста, используете ли Вы системы тип MS PROJECT для расчета плановых дат старта и завершения? Как часто приходится корректировать сроки в связи с изменениями приорететов?

      • Николай

        В приведенном примере нет – оценка времени доработок идет в ручном режиме (имеются собственные разработчики + подрядчик). Корректировать приоритеты/сроки приходится примерно в 15% случаев.

  • Николай

    Чуть больше 6 месяцев.

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


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM