Технологии и автоматизация всего что угодно плотно вошли в нашу жизнь. Мы заказываем пиццу со своего телефона лёжа на диване, который выбрали в интернет-каталоге, и смотрим фильмы на стриминговом сервисе. Продукты привезут домой, специальная служба уберёт в квартире и погуляет с собакой, достаточно недолго поискать в Интернете и нажать несколько кнопок или сделать звонок. Услуги кругом. И всё что угодно может стать услугой, дай только волю инженерам и мечтателям.
Nil novi sub Luna (ничто не ново под Луной) говорили древние Римляне. И думаю, не открою секрет если скажу, что в системах управления IT не придумано ничего (или почти ничего) уникального и эксклюзивного, что не было бы придумано для бизнеса, зачастую даже ещё в конце позапрошлого века классиками и теоретиками менеджмента. Взять тот же ITIL — в явном или неявном виде, его элементы существуют вне сферы IT и в этом материале я попробую проанализировать, пожалуй, самый популярный свод знаний в управлении IT и перенести его на процессы других бизнес-функций. Кому же и зачем будет полезно читать позиционирующийся сугубо для сферы информационных технологий свод знаний?
Все должности и роли в процессном управлении являются
необходимыми для правильного функционирования всей системы. Но есть несколько
высокоуровневых стратегических ролей, качество исполнения которых влияет на всю
систему целиком. Одна из таких ролей – Business Relationship Manager. Человек, который
должен одновременно понимать потребности бизнеса и обладать достаточными
полномочиями чтобы открывать двери в необходимые кабинеты, а с другой стороны
иметь хорошую техническую подготовку и опыт в сфере IT чтобы правильно перевести потребности
бизнеса на «птичий» язык айтишников.
Вместо предисловия, выдержка из ITIL Service Strategy:
«Многие компании верят, что приобретя или разработав какой-то инструмент, все их проблемы будут сразу решены. Но очень просто забыть о том, что они всё ещё зависят от процессов, функций и, что особенно важно, людей. И запомните – дурак с инструментом – всё ещё дурак».
Сегодня мои размышления про выбор программного обеспечения.
Как всегда, идея для очередной заметки появляется после прочтения чужого материала. Вот и в этот раз статья про управление приоритетами подтолкнула к написанию данного материала.
Сразу оговорюсь, в материале ниже речь пойдёт только об изменениях, связанных с разработкой или доработкой ПО и не относится к изменениям, проводимым над оборудованием или серверным ПО.
Итак, условия задачи следующие. Есть самое обычное подразделение с n разработчиками, известной скоростью выполнения задач и средняя скорость появления новых задач. При этом новые появляются быстрее, чем обрабатываются накопленные ранее.
Введём дополнительное условие. Очередной пользователь\руководитель среднего звена получил по шее от вышестоящего руководителя за сорванную автоматизацию (не проконтролировал, не согласовал ТЗ, не принял работу и т.д.). Что имеем в итоге? Правильно, прибегает весь взмыленный заказчик с криками «а ну-ка быстро всё сделайте, надо было ещё вчера, это очень важно! Этим вопросом уже интересуется <здесь имя очень главного очень авторитетного руководителя>».
