Comments 32
Оказывается, в нашей компании не совсем всё плохо, как я думал — уровень где-то между вторым и третьим.
Понравилось, кратко и доступным языком. Спасибо!
P.S. Ремарка «а оттуда она пришла из CMMI/CMM» — туда пришла или оттуда вышла?
Где нулевой уровень?
  • Эникей (старательно пытающийся вырасти в админа) Вася сам бегает от звонка до звонка и что не забыл, то и сделал?
  • Документация на уровне десятка листов А4 почерканных карандашом
  • У пользователей нет альтернативы, кроме как учиться самим
  • Мелочи Вася покупает на свои и даже частенько получается выбить деньги у бухгалтерии обратно
  • Бизнес думает: за что мы этому болвану платим зарплату?
В компании, где есть ИТ (а в этом посте именно такие и рассмотрены), всегда, хотя бы на каком-то уровне зрелости есть процесс управления инцидентами. 0 уровень зрелости – это когда процесса вообще нет, то есть деятельность не осуществляется. А в компании, где есть ИТ, всегда есть процесс управления инцидентами (хотя бы какой-то).

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

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

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

«Вы же обслуживающий персонал, вы должны просто решать задачи, которые перед вами ставит бизнес. Что? Согласовывать с вами что-то? Это ещё зачем?»
Чем Вам не нравится термин «обслуживающий персонал»?
Я системный администратор, я обслуживаю компанию, которая занимается химическим производством. Я выполняю функцию по обслуживанию процесса производства, процесса продажи и обслуживанию некоторых других фунцкций. Бухгалтерия — это обслуживающий персонал, они обслуживают основные процессы. Лаборатория — это обслуживающий персонал, да они дорабатывают и разрабатывают рецептуру, но компания получает прибыль не от продаже рецептов, а от продажи продукта по этим рецептам.

По теме: рост даже до второго уровня возможен только при понимании со стороны руководства. Плохой руководитель не поймёт разделение труда и будет требовать всего от каждого, ставь на кон премию этого самого каждого.
Приучить пользователей к тикетам действительно сложно. Мы делаем это постепенно, сокращая круг привилегированных пользователей и задач, которые могут быть обработаны без заявки. Долго, не без скандалов и обвинений в саботаже рабочего процесса, но успех есть.

Вы расходное подразделение, сами ни копейки денег компании не приносите!

Ну так вы и не должны. Единственный способ для отдела информационных технологий принести прибыль (именно прибыль, а не сокращение расходов) — это начать торговать информацией.

а большая часть вопросов решается на личных связях

Так эта компания и не должна претендовать на высокую оценку.

Чем Вам не нравится термин «обслуживающий персонал»?


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

Ну так вы и не должны. Единственный способ для отдела информационных технологий принести прибыль (именно прибыль, а не сокращение расходов) — это начать торговать информацией.


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

Так эта компания и не должна претендовать на высокую оценку.


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

Однако ж, было бы неплохо, если бы Вы начали статью примерно так: «Согласно ITIL, есть такие уровни: ...», без этого сразу возникает вопрос «с чего он это взял?»
А где шестой уровень — окукливание структуры, которая становится самодостаточной и работает на самое себя

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

По поводу мониторинга: в самом посте этого нет, но он, конечно же, участвует в уровнях зрелости. Практика показывает такие градации:
Уровни 1-2-3 – мониторинг есть, мониторим zabbix или подобные общие инфраструктурные параметры (CPU, RAM, HDD), можем смотреть каналы, сетевой интерфейс, небольшие скрипты-проверки.
Уровни 3-4 — тут мы уже работаем с ИТ-сервисами и бизнесу (да и ИТ-руководству) уже не столь важно, как работает конкретный сервер, интересно работает у нас почта/CRM/ERM/АБС… или нет. Здесь, в дополнение к инфраструктурному мониторингу, появляются сервисно-ресурсные модели (это какие сервера и ПО входят в сервис «почта», что на чем стоит и как друг на друга влияет). Результат — мониторится уже ИТ-сервис целиком.
Уровни 4-5 – нам ИТ-сервисы зачем нужны? Правильно, чтобы бизнес работал. А бизнес – это бизнес-процессы. Вася должен получить счет по почте (ИТ-сервис почта), внести его в CRM (ИТ-сервис CRM), пометить заказ для отгрузки (ERP), проконтролировать доставку (ну пусть будет какая-то система доставки). Т.е. четыре ИТ-сервиса поддерживают один бизнес-процесс. Если мы мониторим транзакциями бизнес-процесс, то понимаем, есть сейчас возможность выполнять БП или все встало. И где встало.

А вообще, мониторинг — очень большая тема, может, когда-нибудь посвятим ей отдельный пост.
Очень интересно было бы почитать про мониторинг, может быть какую-то классификацию, когда какой продукт удобней использовать.
по мониторингу написано много статей, универсального рецепта нет. Есть зависимость от разнородности инфраструктуры, территориальной распределенности, но не такая большая.
Уровень 3-4 — точно так же покрывается штатной системой мониторинга, только мы при этом даём себе отчет в том, что мы мониторим статус сервиса. Очевидно, что это не отменяет необходимости проверять еще и нижележащую инфраструктуру, а то может так получиться, что сервис работает на последнем резерве.

А вот про транзакционный мониторинг бизнес-процессов — было бы интересно узнать, как вы это делаете, особенно если у нас используются разнородные системы.
Про мониторинг бизнес-процессов: есть профильные средства (например, HP Business Process Monitor, BMC TrueSight Operations Management и пр.), которые могут эмулировать действия пользователей для проверки корректности работы системы. Т.е. для каждого приложения, участвующего в бизнес-процессе, создается проверочное действие и виды ответов системы. Простой пример с почтой – а) отправить письмо на определенный адрес, б) проверить ящик получателя, убедиться, что письмо пришло. Ну или если на уровне инфраструктуры – отправить SQL запрос и парсить полученный ответ.

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

Выглядит это как-то так:



А вообще тема обширная, можно отдельный пост написать об этом.
Видя эту схему и описание — для ТАКОГО анализа, на мой взгляд, отлично подойдут практики автоматизированного тестирования ПО, но, как Вы правильно отметили — подсистема визуализации должна быть привязанной к процессам и, в идеале, должен быть соответсвующий дашборд у менеджеров сервисов и соответсвующий дашборд у службы поддержки
Сдохли на 3м уровне (( К несчастью для всего этого нужна в первую очередь заинтересованность исполнителей нижнего и среднего звена. Как только контроль ослабевает или становится много работников делающих всё «спустя рукава» всё это превращается в бардак.
Как по мне, нужна наоборот заинтересованность людей среднего и высшего звена (последние зачастую вообще слабо понимаю всё это IT), без поддержки руководства трудно перестать принимать заявки от важных людей, которые поймали тебя в коридоре например или стремиться к стандартизации рабочих мест.
Я бы несколько поправил — по факту, заинтересованность необходима ВСЕХ уровней управления и исполнителей, но в обязательном порядке должна быть изначальная и безоговорочная поддержка в высшем звене, которое указывает направление для среднего звена, которое в свою очередь рассказывает всё нижнему звену и исполнителям, но при этом нижнее звено изначально должно хотеть улучшения, а не сопротивляться изменениям
Согласен. Хотя если «низы» не хотят и сопротивляются, то их всё же можно заставить при поддержке «верхов». Потому что есть такая категория пользователей, которые всегда против, и вообще верните Win XP. С такими — только указом руководства можно бороться. И ладно если это люди которые просто «сидят», а бывает что это ценные важные сотрудники (по мнению руководства). Ну и чаще всего это конечно же люди в возрасте.
Согласен по поводу низов, но с оговоркой — если низы в большинстве своём дойдут до уровня «саботаж новых процессов/систем», то все усилия менеджеров ни к чему не приведут.
Правда, если такая ситуация складывается, то это уже вопрос в профпригодности менеджеров =)
Возможно еще проблема в новых процессах/система таки. Не всё удобное с точки зрения менеджеров и руководства удобно для конечного пользователя. Иногда это вопрос привычки, но иногда действительно есть проблемы.
Спасибо, узнал свой отдел на этапе очень сильного желания закрепиться на третьем уровне… и немного передохнуть.
интересно, а крупные ИТ-интеграторы на каком уровне находятся примерно?
Если действительно крупные, то тут 4-5 уровни.

Печальнее тогда, когда интегратор позиционирующий себя крупным, идущим в ногу со временем, а на деле зрелость из ИТ относятся к 1-2 уровням и таких примеров не мало.

Из подледного, встретил интегратора обслуживающего ряд банков из 1й сотни. Знаете что, теперь эти банки надо обходить стороной)

А еще бывает такая печаль… когда с 5-го уровня зрелость скатывается на 4-й...

Пятый — это когда айтишников воспринимают не как загадочных парней из подвала, а как партнёров в бизнесе

Про это есть отличная книжка: "Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему", авторы Джин Ким, Кевин Бер, Джордж Спаффорд.

Only those users with full accounts are able to leave comments. Log in, please.