В предыдущей статье я упоминал, что каждый процесс должен иметь «цель», и эта цель есть смысл существования процесса. Приводился пример, при котором целью процесса управления программными активами была «лицензионная чистота организации», а не «полный учет всего на свете».
Это правило формирования целей, конечно, корректное, но есть исключения.
Любой программист знает такие понятия как «процедура» и «функция». Эти механизмы позволяют заметно упростить код, сократить его объем и повысить надежность за счет единожды отлаженных участков кода, изолированных вызовом этой процедуры или функции.
В процессном управлении иногда используются те же самые механизмы.
Для оптимизации процессной модели часто бывает необходимо создание подобных «функций». Рассмотрим простой пример: «Процесс резервирования рабочих ресурсов». Continue reading
Автор: Руслан Акмеев
Плохие процессы?
«Новая метла по новому метёт» (с)
ИТ-процессов также касается. А нет чтобы сначала разобраться, почему процесс стал именно таким, а не другим.
Если рассмотреть, например, организм человека, то в нем тоже всё кажется полным бардаком.
Гораздо удобнее, возможно, было бы и сердце снаружи, и более удобный доступ к желудку, и восемь рук. Для кого удобнее? Для хирурга, например.
Но организм такой какой есть не просто для красоты. Это результаты миллионов лет эволюции.
По аналогии с этим меня умиляет тяга некоторых новых менеджеров «навести порядок в этом бардаке».
Да ты разберись сначала — почему всё именно так, а не по другому. Может, как раз именно здесь, именно так — оно и надо.
Планы по развитию ITIL в 2017-м году
Вот размышления по развитии ITIL, который были «набрейнштормлены» во время визита Романа Журавлева в Москву.
Это видение собравшихся специалистов о том:
* что есть сейчас (желтое в середине);
* как мы к этому пришли (красная цепочка слева);
* вариант положительного будущего (голубые);
* отрицательного будущего (желтое);
* как к этим двум вариантам можно прийти (красные цепочки сверху и снизу). Continue reading
Ещё о надежности
Совсем кратко: главные критерии надежности для:
1) оборудования — дублирование и мгновенное переключение;
2) ПО — отсутствие ошибок;
3) человека — отсутствие человека;
4) процесса — отсутствие необходимости комментировать процесс новым сотрудникам.
IT4IT — кратко и впечатления
Первое. Текущая версия — 2.0.
Полное официальное название (чтобы гуглить) — «IT4IT™ Reference Architecture Version 2.0», стандарт «Open Group».
Второе. IT4IT — это стандарт (хотя на «стандарт», ИМХО, не тянет) архитектуры и операционной модели, создающей «цепочку ценности» для управления ИТ-бизнесом или ИТ внутри другого бизнеса.
Третье. Состав. Выделяем 4 потока (стрима). Даже не просто «стрима», а «Стрима ценности ИТ». Зачем? «Для эффективности и гибкости». В чем именно состоит гибкость и эффективность, не сказано. В общем, стримы следующие:
* Strategy to Portfolio (превратить стратегию в портфолио проектов и услуг).
* Request to Fulfill (запросы — исполнить).
* Requirement to Deploy (требования — внедрить). Огровный пласт работы типа бизнес-анализа, архитектурной проработки, разработки, тестирования, планирования внедрения и интеграции, подразумевается — здесь.
* Detect to Correct («косяки» — исправить). Тут понимаются и инциденты, и дефекты ПО. Но в большей части, всё таки, инциденты.
Типографика для русского языка
Те, кто хоть немного понимает в типографике, часто возмущается отсутствием таковой в русской раскладке под Windows.
В частности, лично меня немного раздражают всего две вещи:
1) Невозможность поставить кавычки-ёлочки (« и »).
2) Невозможность прописать длинное тире ( — ).
В связи с чем создал свою раскладку. От стандартной отличается только этими двумя пунктами.
Правый Alt + «б» = левые «ёлочки» («);
Правый Alt + «ю» = правые «ёлочки» (»);
Правый Alt + «-» = длинное тире (—). Continue reading
Составляющие надежности
Чтобы определить общую надежность ИТ-системы, необходимо определить составляющие ИТ-систем, по которым можно повышать надёжность.
Существуют три основные составляющие:
* люди;
* процессы;
* технологии.
В случае современных информационных технологий, последний пункт следует разделить на две части, и рассматривать их отдельно:
* аппаратное обеспечение;
* программное обеспечение.
К каждой части (аппаратной и программной) применимы свои методы повышения надежности.
Принципиальная разница в том, что аппаратное обеспечение – это технологии, на которые имеет воздействие физический мир. К этой части можно применять различные теории по надежности физических объектов, включая время наработки на отказ, износ материалов, влияние окружающей среды и т.п. Continue reading
Классификация ошибок персонала. Часть 2.
В продолжение предыдущей части, рассмотрим классификацию ошибок персонала немного в другом разрезе.
Ошибки бывают:
1) Ошибка случайная – неверные команды/адреса/параметры при проведении работ в ПРОД. Опечатки. Это – чистый человеческий фактор, снизить который – главная управленческая цель эксплуатации.
2) Недостаточно протестированное решение, которое все таки попало в ПРОД. В данном случае следует считать это не ошибкой персонала, а ошибкой процесса.
3) Излишне долгое время сбора информации и принятия решения о необходимости работ. Также ошибка процесса.
4) Отсутствие сотрудника на месте (когда должен там находиться). Ошибка дисциплины и организации, которую можно отнести к недостаточному управлению (ошибка менеджера).
5) Ошибки вендоров. Слишком долгий ответ 3-й линии поддержки. Ошибки контрактования. Continue reading
Классификация ошибок персонала
1. Категории ошибок персонала
Ошибки персонала разделяются на уровни управления и исполнения. Уровень управления, в свою очередь, разделяется на линейное и процессное.
В «линейное управление» входят следующие вопросы:
* Управление ресурсами (наличие и квалификация Исполнителей);
* Организация работ;
* Наличие и актуальность инструкций и другой документации технического уровня.
Целевые документы, ожидаемые на уровне линейного управления:
* Инструкция;
* План работ.
В «процессное управление» входят вопросы:
* Процессы планирования, разработки и эксплуатации;
* Регламентация; Continue reading
Макрос для бюрократов
Очень. Очень! ОЧЕНЬ! Полезный макрос. Натравливается на документ и делает отдельный документ с таблицей из комментариев и замечаний, найденных в исходном документе.
Незаменим при подготовка презентаций к совещаниям с разбором вопросов к документу.
Качать здесь.