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

Участники круглого стола:
Марина Аншина
директор департамента ИТ «СИБУР — Русские шины»
Тахир Бяширев
технический директор департамента систем управления CompuTel
Георгий Ованесян
руководитель направления технической поддержки и ИТ‑аутсорсинга КРОК
Елена Швец
консультант в области управления ИТ, HP
Виталий Хозяинов
независимый эксперт
Ведущий — Константин Зимин
главный редактор Intelligent Enterprise

Понятие и определение комплексной системы управления ИТ

Intelligent Enterprise: Прежде чем обсуждать что‑либо, надо понять, о чем мы говорим. Поэтому давайте начнем с вопроса: «Что мы определили бы как комплексную систему управления ИТ?» Четкого и общепринятого определения у нас пока не существует. Кроме того, хотелось бы услышать мнение участников о том, как эта комплексная система соотносится с другими инструментами управления — организационной структурой, должностными регламентами, ИТ‑системами и так далее.

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

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

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

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

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

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

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

Елена Швец: Это, скорее, надо рассматривать как применение созданного инструмента к другой области. Поскольку ИТ — одна из наиболее развитых областей с точки зрения управления, это вполне оправданно. Нередко в ИТ‑департаменте наблюдается самый высокий уровень формализации, стандартизации и автоматизации. И руководство предприятия стремится распространить этот опыт на другие области.

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

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

Георгий Ованесян: Я согласен, первый вопрос — это цели: чем мы хотим управлять и почему. Если то, чем мы управляем, — преимущественно организационный объект, то ответ напрашивается сам собой: будут применяться организационные инструменты, которые позволяют перестраивать и настраивать организационную структуру для того, чтобы она добивалась каких‑то целей. В таком понимании сделать это в отрыве от управления всей компанией практически невозможно, как минимум потому, что организационная структура компании должна, хотя бы на каком‑то верхнем уровне, получить отражение в структуре ИТ‑департамента. Это один аспект.

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

Предпосылки и причины постоения комплесной системы управления ИТ

Intelligent Enterprise: Давайте пойдем далее и попробуем поговорить о предпосылках, причинах или, если угодно, целях, которые ставят перед собой компании, пытаясь построить комплексную систему управления. Какие аргументы использовать в разговоре с руководством?

Виталий Хозяинов: С моей точки зрения, у организации в целом всегда есть какое‑то небольшое число целей верхнего уровня. У коммерческой организации это, как правило, зарабатывание денег. Тогда задача системы управления — управлять всеми направлениями, которые связаны с зарабатыванием денег: повышением прибыли, повышением капитализации, снижением издержек, снижением рисков и т. д. Если же организация некоммерческая — допустим, государственная, — то ее цель связана с миссией, то есть способностью решать определенные задачи, и измеряется не в деньгах, а в каких‑то специфических единицах миссии. От этих целей и должны отталкиваться все проекты компании, в том числе и построение комплексной системы управления ИТ.

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

Поэтому для достижения цели зарабатывания денег необходимо грамотно выстроить стратегию. Например, для компании «СИБУР — Русские шины» огромную роль играет гибкость. Мы должны быстро действовать на очень непростом рос­сийском автомобильном рынке. Так что мы в руководстве вместе думаем, как этой гибкости добиться.

Если говорить о предпосылках внедрения комплексной системы управления ИТ, то каждый раз, когда я приходила на должность руководителя ИТ, моей задачей было наладить работу в подразделении, где ситуация находилась на неудовлетворительном уровне. Что в такой ситуации можно предложить? Прежде всего, наверное, организовать нормальную техническую поддержку, то есть управление инцидентами.

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

Цели такого проекта мы формулируем вместе, в тесном взаимодействии. Одна из целей — это повышение прозрачности. Обычно задача состоит не в уменьшении затрат. Дело в том, что эти затраты непрозрачны, а с комплексной системой управления они становятся прозрачными. Другой аспект — развитие бизнеса и поддержка этого процесса со стороны ИТ.

Елена Швец: Прозрачность — важнейший аргумент. Комплексная система управления ИТ позволяет сделать ИТ и управление прозрачными для всего менеджмента. Уже не обязательно нужен проводник в мире ИТ — ИТ-директор, который один знает всю правду. Руководству и самому становится понятно, как это работает и где можно посмотреть информацию.

Георгий Ованесян: Известны три метода целеполагания в организации. Классический и самый распространенный в России — «сверху вниз»: руководство ставит задачу, она бьется на подзадачи и так далее. Второй вариант — «снизу вверх». При этом цели — самые реалистичные, но не всегда понятны руководителю, и он часто реагирует медленно. И метод встречного потока, самый популярный сейчас на Западе: обобщенные цели спускаются сверху, обсуждаются и конкретизируются внизу, а потом происходит некая дискуссия, в результате которой либо достигается компромисс, либо приказом сверху снимается низовой менеджер, не принимавший цель, и заменяется на нового.

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

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

Тахир Бяширев: Я согласен, что краеугольный камень здесь — повышение понятности ИТ для бизнеса, его прозрачности и управляемости. Хотел бы еще добавить, что, кроме того, есть четкая зависимость причин построения комплексной системы управления ИТ от стратегических целей компании. Если, к примеру, компания планирует интенсивный рост, то без прозрачности ИТ ей просто не обойтись. Если потребовалось обеспечить соответствие нормативным требованиям или каким‑то законодательным актам, здесь тоже речь сразу идет о комплексной системе.

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

Спронсор работ по созданию комплексной системы управления ИТ

Intelligent Enterprise: Как мы выяснили, цели в таких проектах ставятся и сверху, и снизу, но самое оптимальное — встречным потоком. Понятно, что ИТ-директор в проекте заинтересован. А кто еще — со стороны бизнеса — заинтересован в этом проекте? Кто может выступить его спонсором?

Георгий Ованесян: Непосредственно спонсором будет только тот руководитель, который обсуждает цели проекта с ИТ-директором в рамках движения «сверху вниз». А заинтересованными лицами проекта способны выступать и представители затрагиваемых им смежных областей, таких как финансы или кадры. Строго говоря, эти люди могут относиться к проекту как положительно, так и отрицательно, соответственно не только по­могать ему, но и мешать. Но, честно говоря, я никогда не сталкивался с противодействием со стороны финансового отдела — обычно они обеими руками «за», потому что комплексная система позволяет им более четко представить себе, что происходит внутри ИТ‑департамента. Заинтересованность отдела управления персоналом не так очевидна, но обычно она тоже присутствует, так как внедрение комплексной системы предполагает учет загрузки ИТ-персонала и в дальнейшем помогает совершенствованию системы мотивации.

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

Марина Аншина: Я стараюсь сделать если не спонсорами, то активными сторонниками проекта как можно больше людей. Дело даже не в выделении сумм — определенные средства я как директор по ИТ могу, наверное, выделить и самостоятельно, — а в том, что проект всех затрагивает, а значит, надо всем о нем рассказать. Проект, направленный на достижение прозрачности, сам тоже должен быть прозрачным.

Методология построения комплексной системы управления ИТ

Intelligent Enterprise: Теперь мы, собственно говоря, подошли к методологии. Здесь два вопроса. Во-первых, какова роль ITSM и концепции сервисного подхода к управлению при ее создании, и обязателен ли сервисный подход, или, может быть, есть какие‑то другие варианты? Во-вторых, достаточно ли в имеющихся методологических рекомендациях — ITIL/ITSM, COBIT, ISO 20000 — инструментов и моделей, чтобы на них опереться, и чего не хватает?

Тахир Бяширев: Что касается фундаментальных принципов ITIL/ITSM, то они незыблемы и сомнению, безусловно, не подвергаются. Но ITIL не говорит нам, что надо сделать, чтобы реализовать эти принципы. Некоторые поставщики, например HP и IBM, пытаются как‑то адаптировать, представить в виде готовой методологии некую последовательность шагов для реализации принципов ITIL. И эти методологии заслуживают внимания.

Марина Аншина: Система управления ИТ не обязательно должна быть построена на сервисном подходе, но де-факто другого подхода нет. Мне нравится ITIL, причем как раз тем, что там сказано, что и как делать. Для каждого процесса приведены варианты, как его строить. То есть примерно понятно, из каких кубиков можно составить процесс. А какие кубики ты возьмешь, как расположишь — твое дело. Чего мне не хватает в ITIL версии 2, так это управления проектами, финансами, людьми, а также стратегической составляющей, которая вообще трудно формализуема. В версии 3 ITIL стратегическая часть появилась, хотя она мне, честно говоря, не понравилась: похоже, пострадали стройность и прозрачность, но при этом мы ничего и не получили. Впрочем, данный недостаток известен, и может быть, дальше будет лучше.

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

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

Елена Швец: Зато есть в методологии HP ITSM. На мой взгляд, эти рекомендации естественно дополняют друг друга. ITSM — это концепция, и понятно, что инструментов внутри нее нет по определению. Мало их и в ITIL — описании лучших практик. А вот HP ITSM — это именно методология, и внутри нее все есть, и работа с персоналом, и многое другое.

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

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

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

Елена Швец: На самом деле элемент творчества невелик — концептуально у всех получается одно и то же. Единственная разница — в терминологии и небольшом перекосе в одну сторону или в другую. Вариации структуры процессов не затрагивают основу: есть процессы, и есть люди, которые этими процессами управляют. Это творчество в рамках ITSM.

Георгий Ованесян: Причем творчество необходимо как раз в силу ограниченности стандартов и рекомендаций. Невозможно, не применяя творческого подхода построить свою систему, исходя только из каких‑то готовых практик и рекомендаций. Так не бывает. Необходимо взять какой‑то готовый фундамент, чтобы начать работу, но потом у компании наверняка появляется что‑то свое. Что именно — зависит от личности ИТ-директора, характера организации и еще от массы факторов. Хотя понятно, что в основе всего этого концептуально будет лежать сервисный подход — от него не уйти.

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

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

В этой области, я считаю, провал, как с точки зрения методологии, так и с точки зрения инструментов. Мы обсуждали это на форуме ФОСТАС в 2008 г. В «СИБУР — Русские шины» мы пытаемся что‑то делать, даже создали свой специфический стандарт управления проектами и пользуемся им. Но нельзя сказать, что это нас удовлетворяет.

Подходы к построению комплексной системы управления ИТ

Intelligent Enterprise: Перейдем к тактике создания комплексной системы управления ИТ. Здесь есть два полярных подхода. Один — революционный: тщательно спроектировать большую систему и потом уже последовательно двигаться по этому пути. Второй — эволюционный: постепенно наращивать систему управления, обходясь без длительного проектирования ее в целом, путем проб и ошибок. Каждый из этих подходов имеет как плюсы, так и минусы. Какой из них, на ваш взгляд, наиболее предпочтителен в тех или иных условиях?

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

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

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

Марина Аншина: Согласна. Более того, на мой взгляд, вообще не нужно делать никакого противопоставления двух подходов. Теория управления процессами, того же реинжиниринга, говорит, что любой процесс развивается сначала эволюционно, а потом в какой‑то момент все равно приходится устраивать революцию. Вопрос только в последовательности и в уровне этих революций, а также в объеме потраченных на них сил, времени и денег.

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

Елена Швец: На мой взгляд, предпочтительнее революционный путь. Давайте вернемся к целям. Любое внедрение нужно для достижения какой‑то цели, и срок жизни этой цели ограничен. Если мы сначала спроектируем все красиво, а потом будем долго внедрять, возникает большой риск потерять фокус проекта. Поэтому нужна революция, и она должна происходить быстро. Но какая бы у вас ни была революция, у сотрудников все равно есть инерция, они в любом случае будут подтягиваться постепенно. То есть эволюционный подход тоже понадобится. Так что нужно не противопоставление этих двух подходов, а их синтез, симбиоз.

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

Техничкская архитектура комплексной системы управления ИТ

Intelligent Enterprise: Теперь давайте поговорим об инструментарии. Насколько, на ваш взгляд, ИТ‑системы созрели сейчас для поддержки комплексного управления ИТ? Что более предпочтительно — опора на большое монолитное решение, интеграция решений, лучших в своем классе, или, возможно, собственные разработки?

Елена Швец: Системы для поддержки комплексного управления ИТ в последние годы сильно эволюционировали. Раньше у нас была просто CMDB, а теперь это более обширное понятие, в которое входит очень многое. Такая CMDB ин­тегрируется во все процессы. Аналогичная вещь произошла и с инструментарием комплексной системы.

Есть системы, в которых собраны лучшие практики опыта CIO, например HP Service Manager. Эта система содержит лучшие варианты процессов, собранные у множества различных заказчиков. Что не надо — отрезаем, выкидываем, остальное с удовольствием используем. Такой подход, на мой взгляд, самый безболезненный для заказчика. Если разрабатывать собственную систему, то это, во‑первых, дольше, а во‑вторых, довольно дорого.

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

В каждом из вариантов есть огромное количество плюсов и столь же огромное количество минусов. И нельзя сказать, что время внедрения для какого‑то из них заведомо короче. Можно очень долго — годами — внедрять стандартный продукт, можно точно так же годами разрабатывать собственное решение, а можно годами интегрировать лучшие решения от разных поставщиков. Можно, наоборот, все это делать очень быстро — если разработчикам ставить маленькие конкретные задачки, а потом все это интегрировать, если применять методики agile, быстро получится некий продукт, пусть плохонький, но работающий. Естественно, можно начать с готовых процессов, создать их с нуля, взять готовое решение и немедленно запускаться. Во всех этих вариантах нет однозначно хорошего и плохого, каждый делает выбор, исходя из своих целей, культуры своей компании и других особенностей. Если мы ничего не знаем об организации и ее целях и тактике, то, например, сказать, что для нее лучшим будет готовый продукт, — это с вероятностью 66% попасть пальцем в небо.

Марина Аншина: В самом деле, это действительно общий подход, такой вопрос стоит всегда. Я считаю, что если организация не готова менять свои бизнес-процессы, то готовая система ей не подойдет, и ее внедрение вообще начинать не надо. Лучше двигаться по пути собственной разработки. Меня удивляют компании, которые с большой гордостью заявляют, что внедрили SAP, но при этом переписали 90—95% кода. По-моему, это как раз тот случай, когда не надо покупать готовый продукт. Поэтому готовая система может подойти компании, в которой еще ничего не делалось в области управления ИТ и процессы надо строить с нуля. Такая компания открыта для следования лучшим практикам. Во всех остальных случаях надо осторожно относиться к готовой системе с преднастроенными процессами.

Если говорить о моем личном опыте, то в двух предыдущих компаниях, где я руководила ИТ, мы шли по пути интеграции лучших инструментов. Мы делали Help Desk на базе простейшей системы с открытым кодом, переводили ее и дописывали. Когда такая же задача встала в компании «СИБУР — Русские шины», сотрудники сказали, что сами напишут Help Desk, и действительно написали за несколько дней, на базе платформы .Net и SharePoint Portal Services. Причем эта система охватывает не только функции Help Desk и процесса управления инцидентами, а оказывается значительно шире. Почему мы пошли по такому пути? Потому что эта система позволяет нам достичь такой гибкости, какой не дает готовое решение. А гибкость, как я говорила выше, — одна из главных целей компании.

Елена Швец: Очень мало продуктов, которые можно просто купить, поставить и сразу начать работать. Так что доработки нужны практически всегда. С другой стороны, готовые системы тоже обладают определенной гибкостью. Увы, многие компании, покупая ИТ-продукт, реально его потом не используют для юстирования своих процессов. Такая ситуация зачастую возникает при неграмотном внедрении готового продукта. Очень важно, чтобы внедрение происходило грамотным способом, с правильной методологией, последовательно и т. д. И тогда готовое решение обеспечит определенную степень гибкости.

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

Марина Аншина: Именно по этой причине я стремлюсь, чтобы на первом этапе система базировалась на какой‑то собственной разработке, сколь угодно «легкой». Это дает возможность попробовать. Потому что если специалисты компании никогда не работали с управлением инцидентами и вообще не имеют опыта, то сразу внедрять самый «чудесный» продукт неправильно. Сначала надо «пощупать» что‑то более примитивное, получить опыт.

Георгий Ованесян: У методики, когда сначала делается какое‑то небольшое, пусть временное, решение, и оно начинает работать, есть еще один немаловажный плюс — результаты. Какими бы скромными они ни были, они есть, и это в первую очередь самому ИТ-директору может подсказать, по правильному ли пути он идет, стоит ли так двигаться. С ними уже можно идти к руководству — показывать ему, доказывать необходимость более крупного этапа, который для какой‑то задачи уже может включать готовую систему.

Тахир Бяширев: Хочу напомнить, что мы рассуждаем о построении комплексной системы. Комплексная система, скорее всего, будет охватывать довольно много процессов и функций. Наверняка она будет модульной. И если мы не ориентируемся на какое‑то готовое зрелое решение, то в какой‑то момент, занимаясь самостоятельной разработкой, неизбежно упремся в ряд технических сложностей. Одна из них, например, — интеграционная. Приложения оказываются несогласованными на уровне моделей данных, их представления. От всего этого мы себя избавим, если будем изначально ориентироваться на большое решение от одного поставщика.

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

Проблемы построения комплексной системы управления ИТ

Intelligent Enterprise: Мы уже говорили о необходимости творческого подхода к методологии, о длительном проектировании и еще более длительном строительстве, о проблемах, возникающих у ИТ-персонала в связи с использованием новых систем, о проблемах выбора системы. Какие еще есть проблемные точки, «больные мозоли»? Где надо подстелить соломку?

Виталий Хозяинов: Я бы добавил, что не­обходимо уделять очень много внимания интеграции с финансовым управлением, поскольку российский бухгалтерский учет для оценки деятельности ИТ вообще не пригоден. МСФО/GAAP — гораздо лучше, но эта отчетность, как правило, поступает позже, чем необходимо для целей оперативного управления, — через месяц-два, когда отчетность соберется. К сожалению, вопросам финансового управления ИТ-директора уделяют мало внимания. На мой взгляд, для оперативного учета имеет смысл строить свою дополнительную систему финансового управления ИТ. Можно использовать для этого готовые инструменты, но надо помнить, что необходимо настроить, например, обмен данными с корпоративной финансовой системой.

Еще один момент — ведя проект по внедрению какой‑то интегрированной системы, следует помнить не только об управленческой части анализа, связанной с ИТ, но и о том, что обычно называют soft skills. Сюда входит работа с персоналом, организационная культура, управление изменениями в бизнесе.

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

Георгий Ованесян: В списке так называемых критических факторов успеха для ИТ-проектов первым пунктом всегда стоит IT management commitment: без поддержки сверху у вас в лучшем случае получится что‑то, что ограничено только рамками ИТ‑департамента и не отвечает целям построения комплексной системы, которые мы обсуждали.

Второй момент — маленькие победы. Надо всегда планировать полезный результат в краткосрочном периоде, результат, заметный всем — и сверху, и снизу. Если этого не будет, интерес, который вы вначале подогрели, исчезнет, причем уйдет поддержка как сверху, так и снизу.

И третье — необходимо учитывать, что люди в принципе меняться не любят: стоит на минуту отвернуться, и они начинают работать по‑старому.

Предпосылки проектов построения комплексной системы управления ИТ

Григорий Главин,
директор по развитию бизнеса компании Belmont

Основная причина роста интереса к построению комплексной системы управления ИТ — возрастающая зависимость практически всех сфер бизнеса от ИТ-технологий. Быстрое технологическое развитие служб Интернета способствует переносу части бизнес‑функционала в виртуальное пространство (например, интернет-банк, комплексные системы голосового самообслуживания — телефон, интернет, чат). Секторы рынка с высоким уровнем конкуренции требуют от игроков быстрых и выверенных действий, которые немыслимы без развитых ИТ‑сервисов. Таким образом, ИТ не только начинает играть роль службы, поддерживающей и оптимизирующей выполнение бизнес-транзакций, но и становится зачастую ключевым бизнес-процессом организации. Для многих компаний внедрение комплексной системы управления ИТ оказывается естественным шагом развития, позволяющим:

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

Методология построения комплексной системы управления ИТ

Григорий Главин,
директор по развитию бизнеса компании Belmont

На наш взгляд, не следует спешить рассматривать ITSM на основе ITIL как единственное и безусловное средство от всех проблем управления ИТ‑сервисами. Библиотека ITIL определяет принципы построения систем управления, но не говорит, как это необходимо сделать в конкретных условиях в конкретной компании. Cуществует много смежных областей знаний, которые так или иначе связаны с управлением и контролем ИТ. Это прежде всего управление проектами (например, PMBOK, PRINCE2, MSP), методология бизнес-анализа, управления человеческими ресурсами и разработки систем на основе унифицированного процесса (RUP, EUP, BUP).

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

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

Предмет комплексной системы управления ИТ

Константин Зимин

Говоря о проблемах построения комплексной системы управления ИТ, мне хотелось бы обратить внимание еще на один важный аспект. Он обсуждался осенью 2009 г. на семинаре «Построение комплексной системы управления ИТ с использованием сервисного и процессного подходов», проведенном itSMF Россия.

Этот аспект — определение самого предмета обсуждения, то есть комплексной системы управления ИТ. Сколь бы теоретическим он ни казался, здесь кроется целый ряд важных вопросов. Прежде всего — что на практике будет значить эпитет «комплексная», и каковы рамки создаваемой системы. Включается ли в нее все, от операционной деятельности до ИТ‑стратегии, включаем ли мы в единый контур управления проектную деятельность, управление собственными разработками и так далее? Именно с этих вопросов начал свое выступление на семинаре Кирилл Баранов, руководитель ITSM-проекта в РЖД. Нет единого четко выверенного методологического подхода, позволяющего определить рамки системы управления ИТ. Поэтому каждая компания должна ответить на эти вопросы самостоятельно, исходя из собственных задач и целей.

Валерий Чашкин, первый заместитель директора дирекции по обеспечению банковской безопасности «Внешэкономбанка», в своем выступлении на семинаре обратил внимание на этот же аспект, но несколько с другой стороны. По его мнению, ИТ‑деятельность организации не сводится к деятельности ИТ‑департамента. Предметная область — управление ИТ‑деятельностью — шире, чем управление ИТ‑департаментом. Если рассуждать комплексно, в нее должны быть включены и аспекты, относящиеся к деятельности других подразделений. Строя комплексную систему управления ИТ, мы просто вынуждены постоянно выходить за рамки ИТ‑департамента.

Из этого следует один принципиальный вывод — ITIL/ITSM не полностью описывает требуемую предметную область. Более того — не существует единой методологии управления таким сложным объектом, как ИТ‑деятельность организации. По этой причине мы и вынуждены заниматься объединением и компиляцией различных методик. И вендорские методологии, например HP ITSM, которые активно преподносятся как полные и самодостаточные, на деле таковыми не являются — это общее мнение участников семинара itSMF. В качестве таких дополнительных методологий участники семинара чаше всего называли COBIT и ISO 9001, а отнюдь не методологии HP или IBM.