Комментарии 32
Оказывается, в нашей компании не совсем всё плохо, как я думал — уровень где-то между вторым и третьим.
Понравилось, кратко и доступным языком. Спасибо!
P.S. Ремарка «а оттуда она пришла из CMMI/CMM» — туда пришла или оттуда вышла?
P.S. Ремарка «а оттуда она пришла из CMMI/CMM» — туда пришла или оттуда вышла?
Где нулевой уровень?
- Эникей (старательно пытающийся вырасти в админа) Вася сам бегает от звонка до звонка и что не забыл, то и сделал?
- Документация на уровне десятка листов А4 почерканных карандашом
- У пользователей нет альтернативы, кроме как учиться самим
- Мелочи Вася покупает на свои и даже частенько получается выбить деньги у бухгалтерии обратно
- Бизнес думает: за что мы этому болвану платим зарплату?
В компании, где есть ИТ (а в этом посте именно такие и рассмотрены), всегда, хотя бы на каком-то уровне зрелости есть процесс управления инцидентами. 0 уровень зрелости – это когда процесса вообще нет, то есть деятельность не осуществляется. А в компании, где есть ИТ, всегда есть процесс управления инцидентами (хотя бы какой-то).
Описание, которое приведено, практически полностью относится к уровню зрелости 1. Единственное — справедливости ради нужно сказать, что вариант «Бизнес думает: за что мы этому болвану платим зарплату» не всегда связан с уровнями зрелости и возможен даже и на третьем. Это, скорее, про наведение прозрачности внутри ИТ.
Описание, которое приведено, практически полностью относится к уровню зрелости 1. Единственное — справедливости ради нужно сказать, что вариант «Бизнес думает: за что мы этому болвану платим зарплату» не всегда связан с уровнями зрелости и возможен даже и на третьем. Это, скорее, про наведение прозрачности внутри ИТ.
Документация — это уже не нулевой уровень. Ну, если она не в голове, а хотя бы в таком виде, как описано.
Это уже не нулевой.
Нулевой — это когда нет даже эникея, проблемы решает кто то из более или менее технически грамотных сотрудников или зовут соседа Васю, работающего эникеем.
Нулевой — это когда нет даже эникея, проблемы решает кто то из более или менее технически грамотных сотрудников или зовут соседа Васю, работающего эникеем.
Проблема в том, что если первые два уровня (и отчасти — третий) ИТ-подразделение может развиваться само по себе, то начиная с четвёртого необходимы встречные шаги со стороны бизнеса.
А не каждый бизнес к этому готов.
Я вот очень хорошо это вижу на примере нашей компании. У нас был замечательный ИТ-директор (в начале лета, его, к сожалению, переманили в Ростелеком). Но очень многие его благие начинания натыкались на непонимание со стороны бизнеса.
Ничего не получится, если бизнес не понимает, что айтишники — это партнёры с которыми нужно обсуждать совместные проекты, а не обслуживающий персонал. Ничего не получится, если в самом бизнесе процессы не прописаны, а большая часть вопросов решается на личных связях.
Никакой централизации и стандартизации ИТ-инфраструктуры не будет, если у бизнеса большая часть вопросов решается на местах и исходя из сиюминутных задач. Ничего не получится, если пользователи не приучены писать тикеты в существующей системе, а только вопят «Мне нужно просто чтобы всё работало, я не программист, чтобы разбираться как письмо с заявкой отправить», а руководство им потакает, говоря айтишникам: «Ну что вы бюрократию с этими заявками разводите!».
И уж тем более ничего не получится, если айтишникам открытым текстом пеняют: «Вы расходное подразделение, сами ни копейки денег компании не приносите!», а потом режут заранее согласованные бюджеты на оборудование, но не пересматривают проекты, под которые это оборудование планировалось — и крутитесь, как знаете.
«Вы же обслуживающий персонал, вы должны просто решать задачи, которые перед вами ставит бизнес. Что? Согласовывать с вами что-то? Это ещё зачем?»
А не каждый бизнес к этому готов.
Я вот очень хорошо это вижу на примере нашей компании. У нас был замечательный ИТ-директор (в начале лета, его, к сожалению, переманили в Ростелеком). Но очень многие его благие начинания натыкались на непонимание со стороны бизнеса.
Ничего не получится, если бизнес не понимает, что айтишники — это партнёры с которыми нужно обсуждать совместные проекты, а не обслуживающий персонал. Ничего не получится, если в самом бизнесе процессы не прописаны, а большая часть вопросов решается на личных связях.
Никакой централизации и стандартизации ИТ-инфраструктуры не будет, если у бизнеса большая часть вопросов решается на местах и исходя из сиюминутных задач. Ничего не получится, если пользователи не приучены писать тикеты в существующей системе, а только вопят «Мне нужно просто чтобы всё работало, я не программист, чтобы разбираться как письмо с заявкой отправить», а руководство им потакает, говоря айтишникам: «Ну что вы бюрократию с этими заявками разводите!».
И уж тем более ничего не получится, если айтишникам открытым текстом пеняют: «Вы расходное подразделение, сами ни копейки денег компании не приносите!», а потом режут заранее согласованные бюджеты на оборудование, но не пересматривают проекты, под которые это оборудование планировалось — и крутитесь, как знаете.
«Вы же обслуживающий персонал, вы должны просто решать задачи, которые перед вами ставит бизнес. Что? Согласовывать с вами что-то? Это ещё зачем?»
Чем Вам не нравится термин «обслуживающий персонал»?
Я системный администратор, я обслуживаю компанию, которая занимается химическим производством. Я выполняю функцию по обслуживанию процесса производства, процесса продажи и обслуживанию некоторых других фунцкций. Бухгалтерия — это обслуживающий персонал, они обслуживают основные процессы. Лаборатория — это обслуживающий персонал, да они дорабатывают и разрабатывают рецептуру, но компания получает прибыль не от продаже рецептов, а от продажи продукта по этим рецептам.
По теме: рост даже до второго уровня возможен только при понимании со стороны руководства. Плохой руководитель не поймёт разделение труда и будет требовать всего от каждого, ставь на кон премию этого самого каждого.
Приучить пользователей к тикетам действительно сложно. Мы делаем это постепенно, сокращая круг привилегированных пользователей и задач, которые могут быть обработаны без заявки. Долго, не без скандалов и обвинений в саботаже рабочего процесса, но успех есть.
Ну так вы и не должны. Единственный способ для отдела информационных технологий принести прибыль (именно прибыль, а не сокращение расходов) — это начать торговать информацией.
Так эта компания и не должна претендовать на высокую оценку.
Я системный администратор, я обслуживаю компанию, которая занимается химическим производством. Я выполняю функцию по обслуживанию процесса производства, процесса продажи и обслуживанию некоторых других фунцкций. Бухгалтерия — это обслуживающий персонал, они обслуживают основные процессы. Лаборатория — это обслуживающий персонал, да они дорабатывают и разрабатывают рецептуру, но компания получает прибыль не от продаже рецептов, а от продажи продукта по этим рецептам.
По теме: рост даже до второго уровня возможен только при понимании со стороны руководства. Плохой руководитель не поймёт разделение труда и будет требовать всего от каждого, ставь на кон премию этого самого каждого.
Приучить пользователей к тикетам действительно сложно. Мы делаем это постепенно, сокращая круг привилегированных пользователей и задач, которые могут быть обработаны без заявки. Долго, не без скандалов и обвинений в саботаже рабочего процесса, но успех есть.
Вы расходное подразделение, сами ни копейки денег компании не приносите!
Ну так вы и не должны. Единственный способ для отдела информационных технологий принести прибыль (именно прибыль, а не сокращение расходов) — это начать торговать информацией.
а большая часть вопросов решается на личных связях
Так эта компания и не должна претендовать на высокую оценку.
Чем Вам не нравится термин «обслуживающий персонал»?
К термину у меня никаких претензий нет. Я хорошо понимаю, что есть производственная часть, которая даёт товар, есть коммерческая часть, которая товар превращает в деньги, а есть саппортовые подразделения, которые делают возможным нормальное функционирование производства и коммерсантов.
Но уж если бизнес замахивается на серьёзные проекты, которые требуют серьёзной ИТ-инфраструктуры, то бизнес должен понимать, что выстроить и поддерживать эту инфраструктуру могут только хорошие специалисты, к мнению которых нужно прислушиваться.
И даже если инфраструктура для текущих задач нужна весьма средняя — всё равно, нужно согласовывать планы. Айтишники не магией из воздуха делают инфраструктуру. Под задачу должен быть согласован бюджет, сроки, ответственные, персонал.
А не просто сказать: «Мы всё уже без вас решили, а вы нам просто обеспечьте.»
Ну так вы и не должны. Единственный способ для отдела информационных технологий принести прибыль (именно прибыль, а не сокращение расходов) — это начать торговать информацией.
Вы это понимаете, я это понимаю. А вот со стороны бизнеса мне приходилось на полном серьёзе такое слышать. Конечно, никто не требовал, чтобы мы начали прибыль приносить, это была претензия в духе «Мы вас кормим из милости, вот и не выпендривайтесь тут, а делайте, что вам говорят».
Так эта компания и не должна претендовать на высокую оценку.
К сожалению, далеко не все со стороны бизнеса это понимают. Многие думаю — ну нафига прописывать какие-то бизнес-процессы, разрабатывать инструкции, стандарты? Ведь всегда в случае каких непоняток можно пообщаться и порешать все вопросы.
НЛО прилетело и опубликовало эту надпись здесь
А где шестой уровень — окукливание структуры, которая становится самодостаточной и работает на самое себя
PS все бюрократические структуры проходят эти стадии
PS все бюрократические структуры проходят эти стадии
Я невнимательно читал, или правда нет ни слова про мониторинг? Еще заметил корреляцию: чем выше уровень развития ИТ в предлагаемой компании, тем больше и сама компания в целом.
Видимо наоборот, вы читали очень внимательно, раз это заметили)
Начну со второго — действительно, есть определенная корреляция, так как с повышением уровня зрелости увеличивается количество процедур, на которые в небольших компаниях просто нет ресурсов. Да и не нужны они там, так как до определенного количества людей некоторые процедуры просто избыточны и все эффективней держать в поле зрения.
По поводу мониторинга: в самом посте этого нет, но он, конечно же, участвует в уровнях зрелости. Практика показывает такие градации:
Уровни 1-2-3 – мониторинг есть, мониторим zabbix или подобные общие инфраструктурные параметры (CPU, RAM, HDD), можем смотреть каналы, сетевой интерфейс, небольшие скрипты-проверки.
Уровни 3-4 — тут мы уже работаем с ИТ-сервисами и бизнесу (да и ИТ-руководству) уже не столь важно, как работает конкретный сервер, интересно работает у нас почта/CRM/ERM/АБС… или нет. Здесь, в дополнение к инфраструктурному мониторингу, появляются сервисно-ресурсные модели (это какие сервера и ПО входят в сервис «почта», что на чем стоит и как друг на друга влияет). Результат — мониторится уже ИТ-сервис целиком.
Уровни 4-5 – нам ИТ-сервисы зачем нужны? Правильно, чтобы бизнес работал. А бизнес – это бизнес-процессы. Вася должен получить счет по почте (ИТ-сервис почта), внести его в CRM (ИТ-сервис CRM), пометить заказ для отгрузки (ERP), проконтролировать доставку (ну пусть будет какая-то система доставки). Т.е. четыре ИТ-сервиса поддерживают один бизнес-процесс. Если мы мониторим транзакциями бизнес-процесс, то понимаем, есть сейчас возможность выполнять БП или все встало. И где встало.
А вообще, мониторинг — очень большая тема, может, когда-нибудь посвятим ей отдельный пост.
Начну со второго — действительно, есть определенная корреляция, так как с повышением уровня зрелости увеличивается количество процедур, на которые в небольших компаниях просто нет ресурсов. Да и не нужны они там, так как до определенного количества людей некоторые процедуры просто избыточны и все эффективней держать в поле зрения.
По поводу мониторинга: в самом посте этого нет, но он, конечно же, участвует в уровнях зрелости. Практика показывает такие градации:
Уровни 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й сотни. Знаете что, теперь эти банки надо обходить стороной)
Печальнее тогда, когда интегратор позиционирующий себя крупным, идущим в ногу со временем, а на деле зрелость из ИТ относятся к 1-2 уровням и таких примеров не мало.
Из подледного, встретил интегратора обслуживающего ряд банков из 1й сотни. Знаете что, теперь эти банки надо обходить стороной)
А еще бывает такая печаль… когда с 5-го уровня зрелость скатывается на 4-й...
Пятый — это когда айтишников воспринимают не как загадочных парней из подвала, а как партнёров в бизнесе
Про это есть отличная книжка: "Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему", авторы Джин Ким, Кевин Бер, Джордж Спаффорд.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как определить уровень ИТ-зрелости своей компании — и какие они бывают