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

Троянские проекты – лукавство или позитивный побочный эффект?

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

В презентации о проекте был, конечно, слайд про цели проекта (случайно попался на глаза). И цели там были такие:

  • Предоставление результативной и рациональной ИТ-поддержки для конечных пользователей
  • Повышение рациональности действий ИТ-персонала при предоставлении поддержки

…а также (не заявлены официально):

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

И вот я пытаюсь представить себе ITSM-проект, который сможет достичь всех этих целей, используя лишь ресурсы, выделенные на достижение первых двух (заявленных официально). И, скажем так, у меня не очень получается. Мне кажется почему-то, что кто-то убедил бизнес купить небольшую полезную поддержку, а сам под шумок в рамках того же проекта надеется решить пяток собственных ИТ-шных задач. Ведь попробуйте-ка убедить руководство организации-заказчика дать деньги на проект улучшения навыков ИТ-управления. Оно ведь может не просто отказать, а счесть это признанием профессиональной несостоятельности ИТ-менеджеров…

И вот возникает вопрос: это правильная тактика? Ведь действительно, убедить заказчиков инвестировать в, скажем, управление конфигурациями – дело очень непростое, прямой связи между этим процессом и бизнес-деятельностью практически нет, а стоит он дорого. Поэтому убедительно и сравнительно легко продаем управление изменениями, а сами заодно организуем управление конфигурациями, мониторинг и каталог услуг. И на елку влезем, и не поцарапаемся… 
 

Но если это скрытые цели, то стоит ли рассказывать о них публично? И вообще, пристало ли правильному ИТ-директору так поступать?

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

  • Альберт

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

    • А для чего среди целей ИТ-отдела могут быть выделены “официальные” и “не заявленные официально”?

      • Альберт

        Не знаю реальной ситуации, но думаю скорее всего это побочные эффекты.

  • Георгий

    Все довольно просто:
    1. Коллеги поставили себе две бизнес-ориентированные задачи (цели) и стремятся их выполнить (ну и заявили об этом в целях проекта)
    2. Для достижения этих целей, необходимо, помимо других задач проекта, выполнить некие внутренние IT-задачи (достичь неких внутренних целей), коллеги, понимая это, решили для себя эти цели сформулировать, чтобы контролировать их достижение
    3. “Официально” на уровень людей, принимающих решение о проекте, это не выносилось, тк уровень не тот, вспомогательные задачи их не интересуют, важен результат, сроки, финансы, риски, а не задачи и подзадачи

    P.S. Кстати, не вижу проблем, рассказать руководству про повышение управленческих навыков, я с трудом себе представляю руководство, которое искренне верит, что все работающие на него люди обладают заведомо всеми возможными навыками, в том числе управленческими 🙂 тогда бы, Ром, ты не продал им обучение никогда 😉

    P.P.S. На всякий случай, я не имею ни малейшего понятия, что это за проект, вполне допускаю, что коллеги могли намеренно выполнять свои задачи, не связанные никак с проектом, “под прикрытием” громких названий, я просто поставил себя на место добросовестного ит-сотрудника

    • Гоша, ну не очень убедительно.
      Ты описываешь вариант “две цели, для их достижения – шесть задач”. Если я тебя верно понял.
      Мне кажется, приведенные списки в такую схему не укладываются.

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

      про P.P.S спасибо, я именно ради такой позиции и не стал называть имен. Интересно обсудить, насколько возможна практика постановки “скрытых” целей в условиях именно добросовестной работы. Про намеренные хитрости типа “коня налево повернул, а сам направо поскакал” обсуждать неинтересно…

      • Георгий

        Кажется мы с Димой разными немного словами, но об одном и том же….

        Не только эти 6 задач, для достижения 2 целей, а еще и эти 6 задач, имеется ввиду, что проект состоит из большего количества задач, а эти 6 выделяются (как верно ниже заметил Дима) отчасти и для того, чтобы показать ценность для ИТ-людей, а не только для спонсоров, ну и для контроля достижения конечно
        По-моему, вполне работоспособная метода

  • Я, честно говоря, коня не вижу 🙂 Есть цели, которые выносились на спонсоров. Это то, ради чего они платят за проект, на основании чего будут (возможно) оценивать результаты. Есть цели, которые выносятся только на руководство ИТ-подразделения. Это то, ради чего ИТ-персонал будет впрягаться в проект, а руководство будет (возможно) спрашивать за исполнение процессов. То, что эти списки могу не совпадать, для меня естественно, так как разные стороны преследуют свои интересы. Они не противоречат друг другу, они дополняют друг друга – значит ОК.
    Например, недавно отвечая на вопрос о пользе SLM для одной компании, я сформулировал два списка: для ИТ-подразделения, для бизнес-подразделений. Они не пересекались, зато содержали понятные ответы на актуальные вопросы соответствующей целевой аудитории.
    Другое дело, мне кажется немного странным разбиение конкретно этих задач на представленные две части. Но ты ведь спрашиваешь не об этом?

    • об этом тоже, наверное. Потому что, как и с Гошиной, с твоей версией эти два списка бьются плохо.

      Но принципиально – ок, подход мне нравится. А можешь прикинуть “правильный” внутренний список для тех двух целей, что были заявлены?

      • “А можешь прикинуть «правильный» внутренний список для тех двух целей, что были заявлены?”

        А вот для этого надо знать задачу и контекст. Например, “Повышение рациональности действий ИТ-персонала при предоставлении поддержки” мне кажется странным выносить наверх например в банке (или это требует изменения формулировки на сокращение или предотвращение будущего роста расходов). Но если это коммерческий поставщик ИТ-услуг, то возможно именно эта формулировка и даёт ответ на один из вопросов бизнеса.

        Цели проекта, также как и, например, наложение ролевой структуры на оргструктуру организации, это то, что может определяться исключительно в конкретном контексте.

  • Pavel Solopov

    По-моему, это не троянский конь, а конь в вакууме.
    рациональность – термин в самом широком смысле означающий разумность, осмысленность, противоположность иррациональности.
    Что такое рациональность поддержки в этом случае? Как вообще планируется оценивать результаты проекта?
    Поддержка стала более осмысленной! Персонал ИТ действует разумно!

    • Ну, Павел, тут не так всё страшно. Рациональность здесь – это efficiency, то есть оптимизация затрат на обеспечение результативности. Там в оригинале было “effective and efficient IT support”. Это, мне кажется, вполне измеримая цель.

      • Pavel Solopov

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

        По мне так вакуума меньше не стало. Оценить что такое оптимально, а что нет, та ещё задача.

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

        • Я поэтому и говорю, что для оценки этих задач или придумывания своих “надо знать задачу и контекст”. Иначе начинаются гадания на спичках. Например, я легко могу себе представить ситуацию, когда рациональность и может быть измерена (и примеры могу привести), и иметь baseline до начала проекта, чтобы было, с чем сравниваться.
          Просто мы с вами видим только формулировки задач и не знаем, что ещё составляет постановку задачи. Отсюда и непонимание – то ли есть метрики по задачам, то ли их нет. То ли они разумные и правда отражают картину управления, то ли бессмысленные. То ли есть к ним целевые значения, то ли нет. То ли измерен baseline, то ли нет. То ли поняли руководители задачу и приняли решение осознанно, то ли побоялись выглядеть глупо и пропустили коня (только не троянского, а вакуумного). И разговор получается не о чем.
          Мне в этом примере гораздо интереснее другое:
          1. Поднятый Романом вопрос об оправданности разделения на “наши” и “ваши” задачи.
          2. Чьи это задачи? Консультантов или менеджмента компании. Если первое, анализ можно не продолжать, цели достигнуты не будут (а если будут, то случайно).

          • Pavel Solopov

            Под менеджментом вы понимаете весь менеджмент от мала до велика? Думаю что там есть не мало уровней иерархии у каждого из которых есть свои цели. 🙂

            • “Под менеджментом вы понимаете весь менеджмент от мала до велика?”

              Вот и ещё одна “гадалка” появилась: “что имеется ввиду под менеджментом “? 🙂


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM