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

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

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

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

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

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

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

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Release Control and Validation

Учебный курс: преобразование и контроль ИТ-услуг, управление изменениями, релизами и конфигурациями, а также построение CMDB — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Денис

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

    0
    0
      1. Денис

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

        0
        0
    1. Андрей

      Добрый день.

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

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

      0
      0
  2. Александр

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

    0
    0
  3. Anton

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

     

    0
    0
  4. Александр

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

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

    0
    0
  5. Николай

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

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

    0
    0
    1. Дмитрий Исайченко Автор

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

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

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

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

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

      0
      0
          1. Николай

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

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

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

            0
            0
            1. Александр

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

               

              0
              0
              1. Николай

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

                0
                0
            2. Дмитрий Исайченко Автор

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

              0
              0
    2. Александр

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

       

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

      0
      0
      1. Николай

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

        0
        0
  6. Дмитрий Исайченко Автор

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

    0
    0

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

НОЯ
27
Учебный курс:
Основы ITIL (очно)