Маленькое искусство
Автор
Александр Башкиров
Нельзя брать на себя больше, чем можешь выполнить. Любое обещание должно быть подкреплено объективными возможностями.
Можно много говорить про управление проектами — сейчас это своеобразный тренд. Вполне обоснованный, надо признать: на фоне кризиса проектные методологии могут серьезно помочь любой компании, а уж паче чаяния — ИТ-компании... Но хочется сделать шаг в сторону и поговорить про управление в ИТ в целом. Почему? Да потому, что управление в ИТ, с одной стороны, тесно связно с управлением проектами: по сути своей деятельность ИТ минимум на 50% проектная. А с другой — грамотно поставленное управление ИТ может оказать реальную помощь. Да, опять речь пойдет о сокращении издержек, увеличении эффективности и регулярном менеджменте. Ну а что вы хотели? Кризис — он совсем не сказка.
Священная корова ITIL и ITSM
Говоря об управлении ИТ, первое, что приходит на ум, — ITIL и ITSM. Большая священная корова, вокруг которой, с моей точки зрения, наблюдается нездоровый ажиотаж. Да, с одной стороны, ITIL хорош. Он хорош тем, что позволяет выстроить и структурировать работу ИТ с пользователем. «От каждого по возможностям, каждому по потребностям» — старый лозунг, который зачастую поднимается ИТ при внедрении ITIL. И как следствие, ИТ попадает в ситуацию «снизу», то есть безынициативного, полностью зависимого подразделения. Но ITIL внедрен, и есть формальное основание требовать соблюдения взятых на себя SLA. Типичная ошибка при внедрении ITIL состоит в том, что хочется быть чуть лучше, чем можно, и, соответственно, обязательства ИТ перед пользователями, взятые в процессе производства проекта, растут, а средств обеспечения этих обязательств просто нет: жизнь не сказка (чтобы ни говорили консультанты), она гораздо богаче разными зигзагами; бизнес же обычно трепетно относится к исполнению данных ему обещаний, хотя бы и собственными подразделениями. Точнее, в первую очередь к исполнению обязательств собственными подразделениями. Что, вообще говоря, очень логично: если сами с собой не договоримся и сами не станем соблюдать взятые на себя обязательства, то как договориться с заказчиками?
В этой ситуации спасает или банальная смекалка и несколько простых заветов: нельзя брать на себя больше, чем можешь выполнить. Любое обещание должно быть подкреплено объективными возможностями. Любые обязательства должны быть зафиксированы и иметь границы применимости. Всегда должен существовать «план Б», то есть сценарий действий в ситуации, когда по каким-либо причинам нельзя поддерживать требуемый уровень сервиса.
Вторая сторона отношений ИТ и бизнеса обычно прячется за гордой аббревиатурой ITSM — Information Technology Service Management, что, по сути, является частью более общей концепции BSM (Buisness Service Management), или управления подразделением как сервисом. Другими словами, есть управление по принципу «черного куба»: есть «вход», «выход» (приемлемый результат) и по большому счету неважно, как и за счет чего он достигается. При работе в такой концепции становится не очень важно, с кем именно сотрудничать — с внешним подрядчиком или с внутренним подразделением. По опыту могу сказать, что да, такое возможно. Но для реализации подобного рода концепции и компания, и ИТ-подразделение должны иметь достаточно высокую степень зрелости. Что встречается, конечно, но очень нечасто. Возникает логичный вопрос: а как же живут и работают все остальные?
С небес на землю
А все остальные — как могут. То есть стремятся к идеалу, внедряя понемногу то, что можется. Например, процесс управления инцидентами. Выстраивая отношения с бизнесом так, как получается. Вообще, ни для кого не секрет, что у нас есть такая милая особенность национального бизнеса — и она состоит в том, чтобы «сработаться». Поэтому, если ИТ сработалось с бизнесом — уже хорошо. Сформировали общие правила — замечательно. А если еще этим правилам и следуют все участники — вообще великолепно! (Вопрос о том, насколько часто встречается подобная ситуация, оставим за рамками статьи).
Могу с полной уверенностью сказать, что самое неприятное — это когда правила меняются по ходу игры. И к сожалению, такие ситуации встречаются. Не «сплошь и рядом», но и не «исчезающе мало»; так, чтобы рассматривать их только в теории, из разряда «так делать не надо». Просто потому, что или бизнес не понимает, чего ждать от ИТ, или у ИТ не получается внятно объснить, чем оно может быть полезно бизнесу.
К чему все это? Да к тому, что управление ИТ на самом деле имеет два очень четких вектора. Первый — отношения с бизнесом. Второй — управление собственными ресурсами. Первый вектор состоит из двух основных линий — управление отношениями с пользователями и управлением отношениями на уровне менеджмента. И тут, наверное, надо вздохнуть и вспомнить про столь нелюбимую айтишниками функцию, как регулярный менеджмент. Что это такое? Если очень коротко, это регулярный план-факт анализ, выполняемый ИТ совместно с основным бизнесом. Разумеется, в каждом конкретном случае объекты анализа будут своими, как и частота представления аналитики. Но общие принципы неизменны. Следует отметить, что сам по себе план-факт анализ не несет особого смысла: когда процессы в какой-то степени выстроены, больших сюрпризов в общем не предвидится. А вот анализ в разрезе перспективы и предвосхищения уже становится интересным. Потому что кроме констатации фактов по текущей ситуации возникают новые горизонты, достижение которых обеспечит бизнесу те или иные преимущества.
«Все это здорово, окей! — скажет искушенный читатель. — Но как быть, когда нет ничего, а требуют очень и очень многое?» Ситуация, кстати, классическая. Ну или почти классическая. В смысле, что зачастую бизнес имеет такой грешок — завышенные ожидания. И чтобы не говорили — переубедить его бывает довольно сложно. Но реально. Нужно лишь найти правильные аргументы для каждой правильной ситуации. И возможно, это придется проделывать неоднократно, до тех пор пока не будут выстроены отношения, при которых бизнес требует от ИТ чуть больше возможного, а ИТ это выполняет. Согласитесь, вызов должен присутствовать, иначе будет совсем неинтересно.
Если же совсем в общем виде, то когда нет ничего — надо составить четкий план: что, когда и как должно быть реализовано. Что это даст. К чему приведет. Какие несет риски. Как им противостоять (и стоит ли противостоять, может, имеет смысл просто принять риск и все?). И работать с конкретными менеджерами от бизнеса, показывая, доказывая, рассказывая... и одновременно приводя ИТ хотя бы к состоянию «удовлетворительно». Это, кстати, зачастую бывает непросто сделать — и без технических решений, и без кадровых преобразований... Вообще, преобразования в ИТ — вещь, которая делается труднее, чем в других подразделениях. Почему? Да потому, что айтишник изначально имеет большую, по отношению к простым пользователям, степень свободы, и больше возможностей для разного рода манипуляций (откровенно говоря, и шантажа тоже). Поэтому, наверное, пресловутый «кадровый вопрос» с айтишниками решается либо предельно корректно, либо не решается вообще. Чего греха таить: с точки зрения бизнеса порой проще держать человека, чем остановить основную деятельность. (Вспомним про еще одну «священную корову»: бизнес зависим от ИТ. И более того, бизнес зависим от конкретных людей в ИТ. Те же доступы «ко всему» есть далеко не у всех, так же как и доступы к критически важным сервисам.)
Про проекты
Теперь немного коснемся темы проектов в ИТ. Как уже говорилось, примерно 50% времени среднестатистического айтишника уходит на то, чтобы работать с проектами. А если совсем точно — реализовывать конкретные проекты. По крайней мере к этому надо стремиться: залог живучести ИТ — непрерывные улучшения. И порой они же — залог получения конкурентных преимуществ всей компании, так что в этом смысле интересы бизнеса и ИТ совпадают, здесь они на одной волне. (И с точки зрения «заработать на зарплату», и с точки зрения сугубо профессиональных интересов: для айтишника нет лучшего стимула, чем интересная задача, которой и являются требования бизнеса.)
Собственно, эти улучшения и «спускаются» в ИТ в виде требований на проекты. Причем обычно любой старт такого рода улучшения — прямое следствие работы регулярного менеджмента: по итогам рассмотрения ситуации и возможностей принимается решение, которое реализуется силами ИТ или привлеченных подрядчиков, с обязательным участием бизнеса. Да, бизнес может и должен принимать самое непосредственное участие в ИТ-проектах: иначе никто не будет гарантировать, что получившееся на выходе в полной мере соответствует ожиданиям и требованиям бизнеса. Ну а форма участия — самая разная, от сотрудничества при создании ТЗ до формирования и работы в совместной проектной команде (лучший вариант, кстати). К сожалению, это могут себе позволить далеко не все компании — обычно от бизнеса выделяется куратор проекта, который так или иначе влияет на его ход и результат. И является независимым наблюдателем и внутренним аудитором. Такая конфигурация работы над проектом, вместе с регулярным менеджментом, применительно к проектной деятельности может дать достаточно хороший эффект и в части результата, и в части удовлетворенности конечных потребителей. Ведь при наличии соответствующих полномочий аудитор вполне способен дать то, чего обычно не хватает ИТ, — видение со стороны бизнеса. А потому не лишне еще раз напомнить, что залог эффективной работы ИТ — тесное сотрудничество с бизнесом и работа во имя и во благо конченого бизнес-пользователя.
Кстати, если такое сотрудничество построено — у бизнеса, как правило, не возникает вопросов, почему сдвинулись сроки реализации или с чем связана корректировка бюджета при «небольших» изменениях в окружении или требованиях к результату проекта. Ведь все коррективы будут проходить не только через формальное сито «есть/нет в ТЗ», но и через оценку эксперта, который может либо аргументированно отказать, либо обосновать необходимость того или иного изменения. И подобный эксперт в силах решить множество «пограничных» вопросов, понимая проблемы и бизнеса, и ИТ. Это в лучшем случае. В худшем — будет жесткое лоббирование бизнес-требований. При кажущемся негативе такой роли — расклад не самый худший для конечного результата: бизнес получит то решение, которое так или иначе его устроит. Но при этом ИТ, а особенно проектная команда, будет вынуждено жить в достаточно некомфортных условиях. Стоит ли того конечный результат — вопрос к каждому конкретному участнику. Но, повторюсь, конфигурация не самая плохая.
А самой плохой для ИТ-проектов является ситуация, при которой каждый из участников предоставлен сам себе. Например, в ИТ передано невнятное описание конечного результата, выделен бюджет и дан карт-бланш. Как вы думаете, что получится в итоге? Нет, если ИТ-директор вовлечен в процессы работы и хорошо понимает потребности бизнеса, проблемы вряд ли возникнут (повторится ситуация с аудитором от бизнеса). А если нет, можно с уверенностью сказать, что проект будет или закрыт, или обретет вторую инкарнацию — в виде доделок, переделок и доводок. И, поверьте, никому от этого не станет хорошо — скорее наоборот.
И напоследок еще раз про дуализм
Повторю одну важную мысль. ИТ по своей сути дуалистично — в той или иной мере оно работает как в оперативном режиме, так и в режиме проектном. И управление ИТ должно строиться исходя из того, что обе макрофункции будут присутствовать априори. Всегда, в каждом конкретном случае с перекосом в ту или иную сторону, но дуализм будет. И к этому нужно быть готовы всем, от ИТ-директора до рядового сотрудника ИТ (ну разве что роме «совсем рядового сотрудника», например оператора службы helpdesk, когда сотрудник работает исключительно в одном из направлений). Исходя из этого, нужно строить работу, формировать отношения, разворачивать систему менеджмента. Вроде бы и нетрудно, но каждый раз получается свое маленькое искусство — со своими сложностями и своим исходом.
Опубликовано 13.05.2014