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

Как безболезненно разогнать ИТ?

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

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

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

Учебные курсы и сертификация
специалистов по ИТ-менеджменту

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

  • Анатолий Павлюченко

    О-о-о! Вы вступаете на скользкий лёёёёёёд! (с подвываниями и модуляцией) [конец]

    Да, именно поэтому формализация и не идёт. Саботаж является второй самой распространённой причиной неудачи проектов построения процессов (и не только в ИТ).

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

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

      • Анатолий Павлюченко

        А каковы мотивы затеяных перемен? Если соответствие законам-стандартам, то никто и не пострадает, только бумага. Если есть желание навести порядок, то тут грех не пользоваться всей полнотой власти _основного бизнеса_. Только желательно всё же иметь какую-никакую общекорпоративную стратегию и придерживаться её. Весьма трудно наводить порядок в одной комнате, когда в другой — бедлам. В общем, вопрос больше из области бизнес-администрирования. Да, есть специфика паролей и т.д., но она не такая уж критичная по сравнению с управлением персоналом или налоговыми вопросами.

    • «Саботаж является второй самой распространённой причиной неудачи проектов построения процессов...»

      Любопытно. Анатолий, а можно попросить ссылочку на источник такой статистики (потому что она довольно сильно расходится и с моим личным опытом, и с известной мне аналитикой Гартнер)? И, раз уж объявили вторую причину, какова же первая?

      • Анатолий Павлюченко

        Вы хотите увидеть статистику про саботаж?! Я и сам с удовольствием посмотрел бы на любую статистику подобного рода 🙂

        «С моим личным опытом» моё утверждение не расходится, а, наоборот, с каждым днём всё больше укрепляется!

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

        А по поводу аналитики Гартнера, покажите, посмотрим. Только я сомневаюсь, что там есть информация про СНГ, где мы с Вами обитаем.

        • «На первое место среди препятствий для построения процессов я бы выдвинул бизнесово-финансовые причины...»

          Вы имеете ввиду нежелание тратить деньги на ITSM-проекты или я не уловил Вашу мысль?

          «Т.е., вместо того, чтобы изначально строить _правильный_ (с точки зрения процессов) бизнес...»

          Что Вы имеете ввиду под словом «изначально»? Представьте себя на месте вновь принятого на работу генерального директора. Акционеры поставили Вам планы по выручке и прибыли (обычно — весьма амбициозные), возможно есть планы по экспансии в регионы, открытие новых магазинов / офисов и т.д. Есть наёмные работники, которым нужно с неизбежной регулярностью платить зарплату, а для этого нужно зарабатывать деньги. Есть сложившаяся история предприятия, в том числе в виде некоторых ключевых менеджеров, их реальных (а не бумажных) областей ответственности, сфер влияния, связей с клиентами и так далее.

          С какого «изначально» Вы бы приступили к строительству процессов? И неужели бы начали со строительства процессов управления ИТ?

          • Анатолий Павлюченко

            Фух! Ну к чему такая агрессия?! Вроде никого не обижал! Или?

            Вон, Евгений конструктивно продолжил... на мой полушутливцый пост.

            Ухожу, ухожу, ухожу... ©

            • Анатолий, Господь с Вами, какая агрессия? Вопросы задаю, мысли уточняю. Для коллективной дискуссии это важно. Простите, пожалуйста, не хотел Вас обидеть!

  • Вадим

    Первый инструмент на этом пути — упорядочение собственных процессов (на уровне бизнеса), формализация потребностей и т.п. Если в самом бизнесе бардак, то реорганизовывать ИТ — бесполезное занятие... И потом, нужно разобраться: что такого важного для бизнеса есть в ИТ-инфраструктуре, чтобы иметь ее в собственных руках, нести расходы на управление ею и т.д.? Т.е. нужно понять, насколько БИЗНЕС реально зависит от ИТ? Ведь не ради же MS Office и интернета это всё нужно?

    Второй — независимый, объективный и полный ИТ-аудит. Информация об ИТ-инфраструктуре в самом полном и широком смысле должна быть отторгнута от голов, подробно задокументирована и определены подходящие средства и методы для работы с нею (те же каталог услуг, CMDB, база поставщиков и т.п.)

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

    При этом очевидно компания должна избавиться от саботажников (врачей-вредителей), которые не хотят перемен, также будут и те, кто (с удовольствием или под принуждением) будет качественно выполнять заданные функции — так почему бы им не остаться?

  • «Как безболезненно разогнать ИТ?»

    Странная постановка вопроса. Откуда такая задача? В жизни в случае серьёзного неудовлетворения результатами работы ИТ-подразделения меняется его голова. Если новая голова хороша, то «она» будет постепенно наводить порядок, принимая точечные решения, кадровые в том числе (но далеко не только кадровые — по системам, по поставщикам, по внутренним стандартам, по архитектуре, по организации деятельности, по выстраиванию отношений с другими подразделениями и так далее). Да и кадровые решения необязательно в направлении увольнения — изменение оргструктуры, повышение значимости перспективных менеджеров, обучение, мотивирование, командообразование, постепенное прививание нужной культуры. Сам выступал в такой роли. Требуется очень серьёзная работа по расчистке конюшен. Через полгода или около того появляются первые серьёзные сдвиги (ну, конечно, от масштаба зависит).

    Всех разогнать и набрать новых на моей памяти не являлось способом достижения ни одной из реальных бизнес-задач. И по-моему процессы здесь не причём.

    P.S. Тема чем-то напоминает известный анекдот про хирурга, тот где «Ну не получается у меня, не получается!» 🙂

    • Ничего странного не вижу. Вполне реальная ситуация: есть предприятие, есть ИТ-отдел, который не справляется с поставленной задачей. Что делать бизнесу? Замена ИТ-руководителя — это один из вариантов, и в этом варианте риски те же, что и при замене команды. Руководителю нужно для начала понять как работают «конюшни», которые ты предлагаешь расчищать. Согласись, что ему будет проще строить новую жизнь, если существующие виды деятельности соответствуют неким стандартам. В итоге, у меня получается, что бизнес может быть заинтересован в том, чтобы деятельность внутри ИТ соответствовала определенным стандартам. Так они меньше зависят от конкретных личностей в ИТ и «разогнать» или заменить головы в ИТ будет проще и менее рискованно.

      А ты говоришь «хирурги», «не получается» 🙂 В некоторых случаях скорее патологоанатомы нужны 🙂

      • Вадим

        Руководителю будет проще строить новую жизнь, если существующие виды деятельности соответствуют неким стандартам. В итоге... бизнес может быть заинтересован в том, чтобы деятельность внутри ИТ соответствовала определенным стандартам

        IMHO это неправильно.

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

        Поэтому деятельность нового ИТ-руководителя должна быть одновременно сосредоточена на двух направлениях:

        — разобраться, чего хочет бизнес (здесь приветствовался бы бэкграунд работы ИТ-руководителем в других структурах в этой же бизнес-отрасли), фактически речь о потребностях, проблемах, приоритетах — требованиях, одним словом.

        — знать, за счет чего эти требования можно удовлетворить (а это и кадры, и технологии, и много еще чего)

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

        В остальном согласен с Дмитрием. Это называется формирование и реализация стратегии.

      • «В итоге, у меня получается, что бизнес может быть заинтересован в том, чтобы деятельность внутри ИТ соответствовала определенным стандартам»

        Я думаю, бизнес интересует прежде всего результат применения ИТ. Стандартизация бизнес интересует постольку, поскольку:

        1) есть люди за пределами ДИТ, которые в состоянии использовать тот или иной стандарт в целях руководства — СВК, служба Заказчика, офис CIO и так далее ИЛИ

        2 есть требования к наличию такого стандарта / контролей — SOX, управление операционными рисками в банковской сфере и так далее.

        Если нет ни первого, ни второго, стандартизация ИТ — это исключительно инструмент директора по ИТ для решения поставленных перед ним задач. Если директору не верят (и собираются от него избавляться), крайне мало вероятно, что ему удастся отстоять инициативу инвестиций в стандартизацию ИТ (как организационную, так и техническую). Но наверно бывают исключения 🙂

        • «Если директору не верят ..., крайне мало вероятно, что ему удастся отстоять инициативу инвестиций в стандартизацию ИТ»

          Вот провести независимый аудит — запросто. У нас были такие ситуации на практике.


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

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

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • 3 стратегии, которые помогут вашей команде принять метрику потока
      Вам необходимо эффективно управлять рабочими процессами, чтобы иметь возможность постоянно предоставлять ценность своим клиентам. Именно здесь в игру вступают метрики потока. Метрики потока являются основной движущей силой оптимизации процессов.
    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT