Инциденты, проблемы и запросы на обслуживание. Третий шаг ИТ-начальника.

По просьбам коллег продолжу начатую ранее серию заметок о том, с чего начать свеженазначенному начальнику ИТ-службы. В первой части я говорил о внимании к терминам, а во второй - о понимании специфики пользователей. Предположим, что первый стресс от назначения уже прошел, с тем, что означают слова "регламент", "инструкция", "АРМ" и "КИС" более-менее разобрались, и с тем, какие у вас пользователи, тоже есть ясность. Что теперь?

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

1. Управление инцидентами. Как регистрируются? Как оформляются? Как сохраняются в базе? Как контролируется выполнение метрик времени и качества по обработке инцидентов? Метрики такие существуют? Как взаимодействуют с пользователями и откуда вообще берется информация об инцидентах?
2. Управление проблемами. Если просто "гасить пожар" в виде инцидентов, то реального сдвига к лучшему не будет. Каждый инцидент - это обычно своего рода звоночек о более серьезных вещах. Так что нужно обязательно понять, как регистрируются проблемы? Как отслеживается состояние проблем и процесса их решения? Кто на каком этапе за что отвечает? И так далее.
3. Управление запросами на обслуживание. Кто кому что пишет, когда нужен компьютер для нового сотрудника бухгалтерии? Как отслеживается соблюдение временных метрик таких запросов? Где осуществляется учет запросов? Кто за что отвечает? Кто контролирует? Кто учитывает? Какие порождаются документы на каком этапе, и кто что визирует или одобряет?

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

Кстати, достаточно редко встречается ситуация, что именно вам придется принимать решение о выборе программного средства. Скорее всего, нечто уже куплено и в каком-то виде уже используется на предприятии. Вам нужно лишь оценить, насколько эффективно это делается. И не спешите что-то ломать или менять! Сначала - разберитесь! 

Стремитесь к разумности и к соблюдению принципа Парето: "20% усилий дают 80% результата". Не нужно пытаться сделать все и сразу, действуйте осмысленно и постепенно.

О функциональном и процессном управлении в ИТ

О преимуществах внедрения процессного управления написано в каждом учебнике по управлению. Особенно много и обоснованно - в учебниках по ИТ-управлению. Но в реальной жизни все равно очень много организаций, которые мертвой хваткой держаться за функциональную модель. Почему так? Ведь процессное управление имеет массу преимуществ, оно прекрасно описано, почти 80% основных технологических процессов в ИТ покрываются типовыми процессными сценариями, казалось бы, бери и реализовывай, что останавливает?

Попробуем порассуждать на эту тему. Что такое функциональная модель? Это когда каждый сотрудник выполняет некоторый набор функций, и, собственно, только за них и отвечает. Как в известном диалоге у Райкина, помните: "К пуговицам претензии есть? -Нет, к пуговицам претензий нет, пришиты намертво!". Самый яркий пример построения функционального управления - это конвейер. Каждый уверенно и точно делает свою операцию, на выходе - готовый автомобиль. Причем если конвейер выстроен правильно, то автомобиль, в идеальном случае, создается минимальным количеством работников.

Но это - в идеальном случае. В реальной жизни работники, во-первых, устают от монотонности одинаковой работы, а, во-вторых, стоит событиям хотя бы немного выйти за пределы типового сценария, как возникает необходимость вмешаться вышестоящему начальнику, то есть происходит эскалация, потому что горизонтальные связи минимальны и знаний о смежных областях у таких вот "конвейерных" сотрудников для принятия решений недостаточно.

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

Собственно, в описанном выше и есть ответ на вопросы, поставленные в начале заметки. Функционально управление позволяет решить задачу за счет минимального количества сотрудников, если обучить их относительно простым операциям и правильно настроить ИТ-"конвейер". Хорошо настроенное функциональное управление - самое дешевое в этом смысле, людей можно запрячь и использовать, как ломовых лошадей.  И, если говорить на чистоту, всем плевать, насколько они недовольны работой - на хорошо описанные функциональные должности всегда можно найти новых людей, а проработанные регламенты позволять быстро подготовить нужных специалистов, хотя если терять людей часто, то "конвейер" ИТ-службы будет давать сбои слишком часто и двигаться недостаточно быстро. Но если избегать совсем уж серьезных ошибок, то все будет нормально. Поэтому за функциональное управление держатся сейчас и будут держаться в будущем - оно самое дешевое в отношении человеческих ресурсов.

Существует и другая причина. Эта причина - незаменимость начальников. Я говорил выше, что функциональная модель управления приводит к эскалации при минимальном выходе за пределы типового сценария. Это повышает нагрузку на руководителей всех звеньев, но зато это же делает их нужными и, при правильном подходе, даже незаменимыми! Так что руководители среднего звена совсем не горят желанием внедрять ресурсное управление, их собственная задроченность дает им психологическую уверенность в своей востребованности и  в собственном завтрашнем дне. А дополнительный бонус к незаменимости - размытая ответственность, неизбежный спутник всех конвейеров, когда, чтобы найти виноватого, приходится выяснять всю цепочку и в конце виноватым окажется дядя Вася с гаечным ключом!

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

Так что по большому счету альтернативы процессному управлению нет, тем или иным способом внедрять его будут, нахлобучивая сверху на функциональную модель или объединяя их во всевозможные гибриды. Потому что в противном случае незаменимые начальники тихо умрут от переработки или будут уволены за проколы.

О сроке жизни компаний и роли ИТ-служб

... in the 1930s the average lifetime of a fortune 500 company was 60 years. Today, the average lifetime of a Fortune 500 company is 10 years. By the end of the decade, the trend line shows that it will be 6 years. - отсюда

Вообще говоря, страшноватые циферки. Бизнес крутится все быстрее, это мировая тенденция, и если ИТ не поддерживает бизнес-процессы, компания становится неповоротливой и теряет конкурентноспособность.

У нас все не так прямолинейно. "Газпром" будет конкурентноспособен уже потому, что у него нет конкурентов. Наша страна активно клепает монополистов, срок жизни которых зависит не от их конкурентоспособности, а от политических решений. Поэтому ИТ-службы рассматриваются зачастую как обслуживающие, вспомогательные и украшающие жизнь, не более того. Посмотрим, изменится ли тенденция в ближайшие годы.

О новых возможностях в напряженное время

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

Собственно, а какие моменты влияют?

1) Санкции. Какими бы смешными они ни были на первый взгляд, они таки есть. И вполне возможно от индивидуальных санкций ЕС и США перейдут к секторальным. Я не собираюсь сейчас оценивать, насколько они обоснованны и справедливы, просто они могут объективно влиять на выручку экспортеров и на импорт решений и оборудования. Компания, в которой я работаю, периодически налетает на санкции, так что я знаю, что говорю. Рано или поздно вполне может оказаться, что ИТ-подразделению откажут в продлении лицензии, не поставят нужную технику или просто не выделят денег на проект.

2) Психология тревожного ожидания. Это когда санкции вроде еще и не стали воздействовать, но общие тенденции в развитии события таковы, что, отойдя от телевизора и отвлекшись от новостных лент, риск-аналитики начинают лихорадочно прогнозировать возможное ухудшение и делиться своими прогнозами с Лицами, Принимающими Решения (ЛПР). А ЛПР тут же начинают, в свою очедь, страховаться, требовать разработки запасных сценариев поведения, выделять на эти сценарии мощности и деньги и прочее. То есть результатом тревожного ожидания являются вполне ощутимые потери бюджета и времени на нейтрализацию прогнозируемых проблем.

То есть так или иначе у нас, ИТ-шников, становится меньше времени и денег. При этом работы у нас меньше не становиться.

Что же делать? Нужно вспомнить старую истину: проблемы одного могут стать возможностью для другого. Нужно попытаться воспользоваться создавшейся ситуацией.А каким образом? Предлагается нескольно принципиальных подходов.

1) Риск-аналитик накрутил своими страхами ЛПР, и они оба теперь в панике от того, что ваша организация сидит на программном обеспечении страны, с которй возможны серьезные осложнения в отношениях? Прекрасно! Воспользуйтесь ситуацией для аудита вашего ПО, выбора возможных конкурентных изделий, обучению в рамках антирисковых мероприятий ваших сотрудников новым подходам и программным продуктам. Заодно и сами подумайте, может, действительно, вынести под этот шумок пару-тройку программных комплексов, которые создают вам наибольшие проблемы.

2) Вам режут бюджет и грузят необходимостью создания стрессо-устойчивых сценариев? Ну что же, начинайте требовать большие штаты (вам в них откажут с вероятностью в 99%) или большие полномочия для более гибкого управления вашими ресурсами. Не думайте, что это невозможно. Пробуйте. Очень часто ЛПР понимают, что повышение риск-устойчивости не может быть выполнено без делегирования полномочий для более гибкого управления. Риск пройдет, полномочия останутся!

3) Станьте сами риск-аналитиком в своей области. По результатам аудита и выклянчив некоторое количество полномочий постарайтесь действительно усилить свои технические конфигурации, параллельно подняв свою квалификацию в соседних областях. Знания карман не тянут, а вот потом, когда буря закончится, можно будет подумать о более высокой позиции в своей или другой организации.

Но главное - не рассматривайте ситуацию только под пессимистическим углом зрения. Помните, что навалом мест, где все НАМНОГО хуже. Радуйтесь, что лично ВАС там нет!

Про актуальную обратную связь, Черчилля и умение видеть жизнь такой, как она есть на самом деле

Наткнулся вчера на статью о "прогулочном менеджменте Черчилля". Что зацепило сразу, так то, что перевод английского термина MBWA (Management by Walking Around) как "прогулочный" лично мне показалось до крайности неудачным. Что это за управление во время прогулки? Прогулка - это когда человек не занимается управлением, а получает удовольствие от рассматривания видов, посещения интересных мест или физической активности. В оригинальном значении MBWA - это методика управления, связанная с постоянным и непосредственным контактом больших начальников с низовыми работниками, с хаотическим и незапланированным ранее присутствием высших управленцев на объекте, их общением с случайно выбранными, а не отобранными ранее специально для этой цели, конечными потребителями. Нет при этом никакой прогулки, а есть постоянные и хаотические "выходы в поля". Даже наиболее близкий по логике и по лингвистике термин "управление мимоходом" не в полном смысле, по моему мнению, отражает это понятие, потому что "мимоходность" предполагает некоторую побочность, вторичность процесса управления. А на самом деле никакой "побочности" нету, а есть попытка добросовестных начальников пробиться через кокон преград, которые окружают управленца высокого ранга, и получить актуальную информацию из первых рук, как же все-таки у него работает предприятие и о чем думает народ.

Ни в коей мере не оспариваю квалификацию Черчилля в качестве "эффективного менеджера". Тут даже говорить не о чем, он был не только опытным политиком, но и действительно квалифицированным управленцем. Для любого управленца, если у него присутствует хотя бы толика общего интеллекта, необходим канал получения объективной обратной связи о результатах реализации принятых решениях. Черчилль пользовался для этого простым приемом - сам ходил по объектам, летал по городам, задавал вопросы пожарным, солдатам, морякам, медсестрам и рабочим аэродромов. В Британии времен Черчилля это работало. В России начала XXI века - нет. Попробовал бы наш президент найти себе рабочего для диалога! Для Путина вон от стерхов до амфор - все готовят отдельно, если надо - быстро будут менять по ходу его движения не только придорожных рабочих, но и все ближайшее население. Я помню инаугурацию Путина - по пустой Москве плывут лимузины... Жутковатое зрелище. Посмотрел бы я, кого бы он в опустевшем городе спросил, например, о пробках на дорогах! Бравый сотрудник ФСО, которого ему бы нашли после некоторой заминки, авторитетно бы заявил, что никаких пробок отродясь в Москве не было, и это, кстати, подтверждает и собственный опыт Путина передвижения по дорогам!

Но отложим в сторону президентов. Посмотрим, работает ли судорожное "выбегание в народ" для руководителей уровня начальника департамента. Такие руководители - не президенты, для них специальных рабочих подбирать не будут. Только пользы от этих выходов во многих областях будет мало. Может, в автомобилестроении, машиностроении, в строительстве толк и будет, я не знаю. А вот в ИТ нет более разрушительного действия, чем выход руководителя в массы. Они же, сердешные наши боссы, в кодах на экране мало что поймут, пробегая бодрой трусцой мимо программиста. Однако, чтобы проявить себя и чтобы народ почувствовал, что руководитель с ними (ну и чтобы не зря время терять), боссы будут просто-таки обязаны оценить его, программиста, стрижку, его внешний вид и порядок на столе! Ну или порядок в офисе. Или цвет и форму кнопок в интерфейсе разрабатываемого приложения. Или еще какую-нибудь фигню. А когда начальник уходит, озадаченные исполнители выдыхают и в глубине души надеются, что босс больше никогда не найдет дорогу в их скромную комнатуху. Почему так? Что, руководители департаментов у нас настолько отсталее Черчилля в части управленческих талантов?

Нет, дело не в их отсталости. Дело в том, что в куче областей (и ИТ в их числе) получить достоверную значимую для общего дела информацию наскоком невозможно! Там нельзя вот так прийти, окинуть взглядом поле, и сказать: "Вот красота, воронки засыпали, но плохо, что щебенкой, надо асфальтировать!". В таких областях разработка правдивых механизмов отчетности и метрик качества управления - это отдельная работа, причем работа сложная и нетривиальная. На эту работу нужно тратить ресурсы и привлекать к ней подготовленных квалифицированных людей. И никакие исторические аналогии впрямую не работают. Здесь каждый управленец решает задачу получения информации по-своему. Как я считаю, именно способность получать качественную достоверную информацию такого рода можно считать одним из критериев того, насколько управленец квалифицированный.

Поэтому не зря тот же Черчилль не просто носился, как угорелый, по всей стране, но и сформировал отдел статистики (о чем очень разумно было упомянуто в приведенной статье), создал систему метрик, с помощью которой оценивал работу Адмиралтейства, и никогда не оставлял на самотек выданных им поручений. А вот нужно ли бы для контроля этих поручений "выходить в поля" - это тема отдельной дискуссии. Прямое копирование управленческого стиля хороших руководителей само по себе не сделает Вас (или кого бы то ни было) хорошим руководителем. Любую информацию нужно адаптировать и применять вдумчиво.

Чего я вам всем и желаю.