«Обеспечивающие» процессы

В предыдущей статье я упоминал, что каждый процесс должен иметь «цель», и эта цель есть смысл существования процесса. Приводился пример, при котором целью процесса управления программными активами была «лицензионная чистота организации», а не «полный учет всего на свете».
Это правило формирования целей, конечно, корректное, но есть исключения.
Любой программист знает такие понятия как «процедура» и «функция». Эти механизмы позволяют заметно упростить код, сократить его объем и повысить надежность за счет единожды отлаженных участков кода, изолированных вызовом этой процедуры или функции.
В процессном управлении иногда используются те же самые механизмы.
Для оптимизации процессной модели часто бывает необходимо создание подобных «функций». Рассмотрим простой пример: «Процесс резервирования рабочих ресурсов». Read more

Плохие процессы?

«Новая метла по новому метёт» (с)
ИТ-процессов также касается. А нет чтобы сначала разобраться, почему процесс стал именно таким, а не другим.
Если рассмотреть, например, организм человека, то в нем тоже всё кажется полным бардаком.
Гораздо удобнее, возможно, было бы и сердце снаружи, и более удобный доступ к желудку, и восемь рук. Для кого удобнее? Для хирурга, например.
Но организм такой какой есть не просто для красоты. Это результаты миллионов лет эволюции.
По аналогии с этим меня умиляет тяга некоторых новых менеджеров «навести порядок в этом бардаке».
Да ты разберись сначала — почему всё именно так, а не по другому. Может, как раз именно здесь, именно так — оно и надо.

Планы по развитию ITIL в 2017-м году

Планы по развитию ITIL в 2017-м году

Вот размышления по развитии ITIL, который были «набрейнштормлены» во время визита Романа Журавлева в Москву.

Это видение собравшихся специалистов о том:
* что есть сейчас (желтое в середине);
* как мы к этому пришли (красная цепочка слева);
* вариант положительного будущего (голубые);
* отрицательного будущего (желтое);
* как к этим двум вариантам можно прийти (красные цепочки сверху и снизу). Read more

Ещё о надежности

Совсем кратко: главные критерии надежности для:
1) оборудования — дублирование и мгновенное переключение;
2) ПО — отсутствие ошибок;
3) человека — отсутствие человека;
4) процесса — отсутствие необходимости комментировать процесс новым сотрудникам.

IT4IT — кратко и впечатления

IT4IT — кратко и впечатления

Первое. Текущая версия — 2.0.
Полное официальное название (чтобы гуглить) — «IT4IT™ Reference Architecture Version 2.0», стандарт «Open Group».
Второе. IT4IT — это стандарт (хотя на «стандарт», ИМХО, не тянет) архитектуры и операционной модели, создающей «цепочку ценности» для управления ИТ-бизнесом или ИТ внутри другого бизнеса.
Третье. Состав. Выделяем 4 потока (стрима). Даже не просто «стрима», а «Стрима ценности ИТ». Зачем? «Для эффективности и гибкости». В чем именно состоит гибкость и эффективность, не сказано. В общем, стримы следующие:
* Strategy to Portfolio (превратить стратегию в портфолио проектов и услуг).
* Request to Fulfill (запросы — исполнить).
* Requirement to Deploy (требования — внедрить). Огровный пласт работы типа бизнес-анализа, архитектурной проработки, разработки, тестирования, планирования внедрения и интеграции, подразумевается — здесь. Read more

Составляющие надежности

Составляющие надежности

Чтобы определить общую надежность ИТ-системы, необходимо определить составляющие ИТ-систем, по которым можно повышать надёжность.
Существуют три основные составляющие:
* люди;
* процессы;
* технологии.
В случае современных информационных технологий, последний пункт следует разделить на две части, и рассматривать их отдельно:
* аппаратное обеспечение;
* программное обеспечение.
К каждой части (аппаратной и программной) применимы свои методы повышения надежности.
Принципиальная разница в том, что аппаратное обеспечение – это технологии, на которые имеет воздействие физический мир. К этой части можно применять различные теории по надежности физических объектов, включая время наработки на отказ, износ материалов, влияние окружающей среды и т.п. Read more

Классификация ошибок персонала. Часть 2.

Классификация ошибок персонала. Часть 2.

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

Ошибки бывают:
1) Ошибка случайная – неверные команды/адреса/параметры при проведении работ в ПРОД. Опечатки. Это – чистый человеческий фактор, снизить который – главная управленческая цель эксплуатации.
2) Недостаточно протестированное решение, которое все таки попало в ПРОД. В данном случае следует считать это не ошибкой персонала, а ошибкой процесса.
3) Излишне долгое время сбора информации и принятия решения о необходимости работ. Также ошибка процесса.
4) Отсутствие сотрудника на месте (когда должен там находиться). Ошибка дисциплины и организации, которую можно отнести к недостаточному управлению (ошибка менеджера).
5) Ошибки вендоров. Слишком долгий ответ 3-й линии поддержки. Ошибки контрактования. Read more

Классификация ошибок персонала

Классификация ошибок персонала

1. Категории ошибок персонала
Ошибки персонала разделяются на уровни управления и исполнения. Уровень управления, в свою очередь, разделяется на линейное и процессное.

В «линейное управление» входят следующие вопросы:
* Управление ресурсами (наличие и квалификация Исполнителей);
* Организация работ;
* Наличие и актуальность инструкций и другой документации технического уровня.
Целевые документы, ожидаемые на уровне линейного управления:
* Инструкция;
* План работ.

В «процессное управление» входят вопросы:
* Процессы планирования, разработки и эксплуатации;
* Регламентация; Read more

Макрос для бюрократов

Макрос для бюрократов

Очень. Очень! ОЧЕНЬ! Полезный макрос. Натравливается на документ и делает отдельный документ с таблицей из комментариев и замечаний, найденных в исходном документе.
Незаменим при подготовка презентаций к совещаниям с разбором вопросов к документу.
Качать здесь.

О разделении инженеров и менеджеров

О разделении инженеров и менеджеров

У нормального инженерного работника, не имеющего подчиненных, должен быть один интерфейс управления: список входящих задач. И кнопка на каждой задаче «Сделал».
А снизу на этот интерфейс еще можно добавить две кнопки: «Взять отпуск» и «Уволиться». Всё.

Всем остальным должны заниматься те, кто носит гордое звание «Менеджер» или «Руководитель».
И как только хоть один этот «менеджер» пристанет к инженеру со словами «предоставьте отчет» или «вы должны были согласовать» или «ознакомьтесь с регламентом», такого «менеджера» нужно тут же расстрелять попросить заняться своей непосредственной работой, а именно, в первую очередь: построением модели взаимодействия между сотрудниками.