Статья "Банки и технологии" NN4-5/2004

 

Зрелому бизнесу — зрелая автоматизация

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

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

Леонид Головин

заместитель директора Департамента банковского ПО «RS-Bank/Pervasive» компании «R-Style Softlab»

 

ОГЛАВЛЕНИЕ

Взаимоотношения бизнеса и автоматизации в банках 1

Оценка уровня зрелости автоматизации 2

Этап 0 — нулевой уровень зрелости. 2

Этап 1 — первый уровень зрелости. 3

Этап 2 — второй уровень зрелости. 3

Этап 3 — третий уровень зрелости. 4

Основные принципы и критерии модели ITIL/ITSM 5

«Стоимость вопроса» 6

Внедрение решений ITSM 7

 

 

Взаимоотношения бизнеса и автоматизации в банках

 

Не секрет, что автоматизация для банков — это по сути чистые расходы: на «железо», софт, персонал, обслуживание, модернизацию и т.п. и т.д. Разумеется, все желают получить отдачу от вложенных средств, однако лишь очень немногие клиенты — в основном это те, которым знакомы принципы IT Service Management (к ним мы еще вернемся), — могут реально оценивать не только затраты на автоматизацию, но и их эффективность. Если в период «дикого капитализма» отечественные банки денег нежалели, и это была золотая пора (в том числе для ИТ-служб), то после 1998 года вопросы определения и повышения эффективности встали со всей остротой. Но еще до начала нового века накопленная инерция предыдущих лет не позволяла изменить модель взаимоотношений между бизнесом и автоматизацией. Кстати говоря, во многих кредитных организациях служба автоматизация и по сей день находится вдали от основного бизнеса, и задача этого подразделения там сводится к формулировке «чтобы все и всегда работало». А в ситуации критичных сбоев вместо анализа причин и выработки стратегии их предотвращения руководителя службы автоматизации могут запросто уволить, повинуясь первому эмоциональному порыву. Так что в идеале отечественный Service Management замешан на личной ответственности и высоком понимании своей миссии в банковском бизнесе руководителя ИТ-службы и его сотрудников либо, как минимум, на профессиональных знаниях и энтузиазме.

Однако время идет, и сейчас уже многие наслышаны о моделях, декларируемых в методологии ITIL/ITSM[i]. Первые упоминания об их принципах в российской прессе относятся к 1999-2000 годам[ii]. Новая волна интереса к этой теме заставила журнал «Открытые системы» посвятить ITIL весь первый номер за 2004 год[iii]. Теперь немало банковских специалистов знают, что ITSM — IT Service Management — это концепция управления ИТ-услугами, то есть такой подход, при котором ИТ-организация (штатный отдел или внешняя компания) рассматривается как поставщик ИТ-услуг. Соответственно на первое место выходит управление качеством их предоставления, а вопросы управления технологиями являются вспомогательными, хотя безусловно важными. Служба ИT должна не только решать отдельные технические задачи, но и предоставлять комплексные, бизнес-ориентированные услуги гарантированного качества.

На практике управление ИТ-услугами решает три профессиональные задачи:

           привести ИТ-услуги в соответствие текущим и будущим потребностям клиентов и(или) пользователей;

           улучшить качество предоставляемых ИТ-услуг;

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

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

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

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

 

Оценка уровня зрелости автоматизации

 

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

Этап 0 — нулевой уровень зрелости.

Служба автоматизации банка (как правило, 1-2 человека на 20-100 компьютеров) занимается «всем, что с проводами». Никаких документов (даже должностной инструкции), регулирующих сферу ответственности автоматизатора нет, не говоря уже о Соглашении об уровне сопровождения (SLA — Service Level Agreement) — контракте, регламентирующем отношения между сервис-провайдером и его клиентом[iv]. Все просто: бизнес — с одной стороны, «эникейщик»[v] — с другой. Учет средств ИТ-инфраструктуры (серверы, маршрутизаторы, принтеры, рабочие станции, дистрибутивы, документация и т.п.) выполняется в лучшем случае на уровне бухгалтерской или складской программы. Планирования развития нет, оценка рисков не осуществляется, меры по их снижению не прорабатываются. Все решения принимаются и работы ведутся по принципу «когда жареный петух клюнет». Инциденты[vi] декларируются устно в курилке или по телефону. Поиск решения проблем[vii] строится скорее на личных отношениях, чем на какой-то технологии. Регистрации инцидентов и проблем не производится, да и ни к чему она: простые проблемы снимаются, как правило, быстро и на месте, а сложные безнадежно зависают. Особо пунктуальные «потерпевшие» (специалисты и руководители бизнес-подразделений, столкнувшиеся с ИТ-трудностями) ведут собственные реестры такого рода «конфликтов» и периодически продавливают решение своих проблем, козыряя этим списком перед автоматизатором и его начальством. Качество услуг на Этапе 0 зависит исключительно от компетентности автоматизатора и его доброй воли, а также от личных отношений с «потерпевшими». Формальная оценка качества не выполняется, соответственно, измерить и повысить качество работы автоматизатора невозможно — высшее руководство оценивает ее по тому, насколько хорошо функционирует компьютер на его столе и, возможно еще, по скорости перемещения специалиста между комнатами и этажами. Худшим грехом автоматизатора считается его бездеятельность, усугубленная игрой в компьютерные игрушки (даже если он все сделал, и машины у него отлично работают), которое карается отправкой на такелажные работы («Бумагу в офис привезли, а кто тут у нас главный по принтерам? Вот тебе и разгружать!») или на сборку-разборку мебели («Компьютеры где стоят? На столах — вот тебе их и собирать!»). На нулевом уровне зрелости руководитель организации еще не уверен, нужна ли ему вообще эта автоматизация.

Этап 1 — первый уровень зрелости.

Высшее руководство решило: автоматизация нужна, и она у нас определенно есть. Выясняется, что автоматизация уже достаточно глубоко проникла в основные бизнес-процессы банка и он не может нормально функционировать при неисправной ИТ-инфраструктуре. Начальник службы автоматизации непосредственно замыкается на одного из первых лиц банка[viii]. Появляются формируемые по сиюминутным настроениям бизнес-руководства «бюджеты на автоматизацию» — как правило, весьма скудные, и к тому же они постоянно обрезаются главбухом. Службе автоматизации выделяют помещение. Для порядка создается «Положение об отделе», в котором описывается сфера ответственности: «Поддержка работоспособности ИТ-инфраструктуры банка в целом, поддержка пользователей». К этому документу автоматизатор апеллирует, чтобы снять с себя решение, например, такого вопроса: почему перестала работать кофеварка, убедительно доказывая, что она — не элемент ИТ-инфраструктуры. Внутри самой службы (ее штат уже составляет 3-5 человек на 60-150 компьютеров) происходит технологическое деление: один-два специалиста занимаются «проводами» (сетью, маршрутизаторами, серверами, системным софтом, телефонией, связью и т.п.), двое-четверо — бизнес-софтом. Имеет место первичная реализация процесса управления конфигурациями — ведется учет ИТ-средств, альтернативный бухгалтерскому и складскому, который реализован в виде реестра в Excel или на базе Access.

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

На данном этапе автоматизаторы зачастую находятся на положении полубогов, и создается впечатление, что бизнес придуман для них, а не они для бизнеса. Для сотрудников банка, кто ищет на клавиатуре кнопку «Press any key», на двери отдела автоматизации вывешивается шуточный прайс-лист с тарифами на глупые вопросы. Более серьезным инцидентам, правда, на этом этапе уже присваиваются приоритеты (как правило, главным критерием здесь служит громкость крика «потерпевшего»).

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

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

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

Этап 2 — второй уровень зрелости.

Руководство активно осаждают деятельные автоматизаторы с предложениями использовать чуть ли не спутник для связи с пунктами по обмену валют, купить новый сервер на Linux, принтер «с замочком», отправить всех сотрудников на учебные курсы и т.п. Бюджеты на автоматизацию становятся более жесткими и более детальными. Руководство банка начинает требовать отчеты об использовании выделенных средств, при этом механизма оценки эффективности вложений не существует. Казалось бы, контролируется каждая копейка, а средства все равно утекают без ожидаемой отдачи. Начинают разрабатываться и закрепляются на бумаге планы развития, но должного внимания контролю за их исполнением не уделяется (просто нет времени -которое оно уходит на контроль за каждой копейкой).

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

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

Этап 3 — третий уровень зрелости.

Руководство кредитного учреждения перестает считать количество серверов или выяснять стоимость запасного маршрутизатора, а начинает задавать примерно такие вопросы:

·  начальнику Операционного зала: «Почему стоит очередь к операционистам?»;

·  экономисту: «Во что обойдется простой банка в течение 30 минут операционного времени?»;

·  начальнику службы автоматизации: «Сколько критичных сбоев произошло за последний год? Сколько будет стоить снижение времени восстановления до 10 минут? Сколько денег нам потребуется, чтобы в течение отчетного года работать без сбоев?».

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

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

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

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

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

В принципе, на этом эволюцию[x] ситуации с автоматизацией можно считать завершенной. Далее начинается закрепление на достигнутых рубежах интеграции, а также оптимизация[xi] и подъем эффективности. Где-то между 2-м и 3-м этапами руководство учреждения либо начальник службы автоматизации пересекается с изложением принципов ITIL/ITSM[xii] или доходит до этих истин эмпирическим путем — методом проб и ошибок, набивая себе шишки. Подлинное осознание ценности методологии ITIL/ITSM приходит к тем, кто к этому готов.

 

[Врезка № 1]

 

Основные принципы и критерии модели ITIL/ITSM

 

Модель ITIL/ITSM характеризуют следующие основные принципы:

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

2. Основной продукт информационной службы — ИТ-услуга. Создание нового бизнес-процесса или даже направления бизнеса, основанного на возможностях ИТ, требует четкого разделения ответственности ИС и бизнес-подразделений. В ITIL/ITSM для этой цели служит ИТ-услуга, то есть решение определенной задачи в рамках бизнес-процесса и(или) проекта средствами ИТ.

Требования к ИТ-услуге в данном случае являются сферой компетенции бизнес-подразделений, а ее реализация согласно этим требованиям — сферой ответственности ИС.

3. Процессный подход. Модель ITIL/ITSM описывает не организационные единицы и их функции, а процесс, который определяется как «взаимосвязанная последовательность действий, изменений и т.д. для реализации определенной цели или задачи». Практика показывает, что в современной информационной службе управление процессами приносит большую отдачу, нежели любая реорганизация.

Основные принципы ITSM в деятельности ИТ-службы реализуются путем выделения процессов и обеспечения их управления. Обычно различают шесть ключевых для начала развития процессов (Таблица 1), хотя в действительности их больше[xiii]. Каждый из этих процессов зарождается и развивается, в свою очередь определяя уровень зрелости.

 

Таблица 1. Основные процессы ITSM и соответствующие им уровни модели зрелости


Процесс, функция Уровень модели зрелости
появляется развивается
Управление конфигурациями (Configuration management) 1 2
Управление изменениями (Change management) 1 2
Управление обращениями пользователей (Service desk) 2 3
Управление инцидентами (Incident management) 2 3
Управление проблемами (Problem management) 3 далее
Управление сервисными соглашениями (Service level management) 3 далее

 

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

·        для руководства банка — прозрачность структуры ИT и затрат на нее, понимание, чем конкретно занимаются все эти «синие воротнички», повышение отдачи финансовых вложений в ИT, высокая надежность бизнеса в целом;

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

·        для сотрудника службы ИT — выравнивание ежедневной нагрузки, отмена узкопрофильности, расширение полномочий и рост ответственности, возможность выполнять свои обязанности в рамках нормального рабочего дня (что позволяет высвобождать время на личную жизнь);

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

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

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

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

2.      Внести изменения в организационную структуру, зоны ответственности, полномочия.

3.      Внедрить специализированные программные продукты, функциональность которых предусматривает предоставление информационных услуг.

Чтобы реализовать желание руководства повысить отдачу от вложений в ИT, сделать их более прозрачными и понятными, у кредитного учреждения есть только два пути:

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

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

 

«Стоимость вопроса»

 

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

В отличие от российских известные западные компании, бизнес которых замешан на ИT, прошли все эти этапы в последние десятилетие ХХ века. Более того, еще в 1996 году компания «Hewlett-Packard» явила миру продукт, призванный вознести службу автоматизации (или поддержки) на самый высокий уровень. Фактически HP представила миру свою собственную типовую модель IT Service Management[xiv] — HP Open View Service Desk[xv]. И сама идеология, и продукт от «Hewlett-Packard» как нельзя лучше пришлись ко двору таким крупным многофилиальным организациям, как «Альфа-банк» (там HP Service Desk был запущен еще в 2001 г.) и Сбербанк России (в нем это решение внедряется с 2003 г.).

На западном рынке безусловным лидером в банковской среде является решение от «Remedy», а именно Remedy IT Service Management[xvi]. Основной причиной здесь видится действительно всемирно признанные качества разработок этой компании по адаптивности и легкости настроек под конкретные особенности каждого банка, многочисленные шлюзы к другим информационным системам корпоративного уровня и средствам управления и мониторинга ИТ-инфраструктуры. Решения «Hewlett-Packard» (Service Desk) появились значительно позже, но по своему функционалу именно в реализации ITSM-процессов они не очень уступают «Remedy».

C другой стороны, «Hewlett-Packard» первой начала активно продвигать свое решение на российском рынке, следствием чего стали ее более развитая инфраструктура, появление большего количества авторизованных поставщиков и консультантов по внедрению, и, соответственно, более конкурентоспособная ценовая политика.

Важно отметить, что фактически каждый крупный игрок на рынке информационных технологий ITIL/ITSM сейчас стремится иметь и продвигать собственную технологию. В частности, известны также решения от IBM (Tivoly) и от «Microsoft» (MOF). В принципе, все программные решения на рынке ITSM похожи как близнецы-братья, и это не кажется странным, поскольку все они базируются на идеологии ITIL/ITSM либо на фактическом опыте конкретной компании, связанном с услугами по поддержке пользователей в области ИT. Отдельные процессы ITSM могут быть реализованы в виде HelpDesk-модулей различных CRM-систем.

В настоящее время можно найти решения самых разных стоимостных категорий: от $ 300 (за целый HelpDesk — законченный продукт с неограниченной лицензией[xvii]) до $ 2 000-4 000 (за рабочее место — и это только цена лицензии без учета затрат на внедрение и сопровождение, а также на отдельные «серверные» лицензии — $ 8 000-20 000). Обычно по дорогостоящим решениям проводится гибкая лицензионная политика, предусматривающая:

·  лицензии типа «Read-only» (предоставляются бесплатно, точнее, в рамках какой-либо серверной лицензии, для Remedy ITSM и для HP Service Desk) — позволяют любому сотруднику банка вводить запросы на изменение (Request for Change) или обслуживание (HelpDesk request), а также контролировать их состояние и ход обработки. В то же время специальные средства авторизации и доступа могут быть настроены так, что вход в систему разрешается только авторизованным пользователям из бизнес-подразделений;

·  лицензии типа «Named user» (на «именные» рабочие места) — используются для организации постоянных АРМ: операторов HelpDesk, руководителей служб и т.д. Такие лицензии дешевле конкурентных, но применять их может только конкретное лицо. Идеально подходят для организации рабочих мест узкого круга лиц, на 100 процентов загруженных именно задачами ITSM, то есть для операторов Service Desk и, возможно, руководителей соответствующих подразделений - тех, от которых требуется онлайн-реакция;

·  лицензии типа «Concurrent user» (конкурентные) — служат для организации работы всех остальных специалистов, задействованных в обслуживании процессов ITSM. Обычно такие лицензии в два раза дороже именных;

·  серверные лицензии на SD — «HelpDesk management» (запросы, инциденты, проблемы); «Сhange management» (наряды, изменения, проекты); «Service level management» (сервисы, SLA), причем любая из этих лицензий дает доступ к Configuration management (управлению конфигурациями).

Однако даже в условиях гибкой лицензионной политики стоимость решения, так сказать, средней руки от именитого производителя для типичной службы автоматизации универсального банка (головное отделение, один филиал) на 10-20 конкурентных лицензий будет начинаться с суммы в $ 50 000 (без внедрения).

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

 

Внедрение решений ITSM

 

Опыт работы системных интеграторов показывает, что крупные заказчики из финансовой и банковской сферы в первую очередь ищут пути построения эффективной службы эксплуатации ИТ с использованием методологии ITSM, с выстраиванием внутренних бизнес-процессов поддержки ИТ и внедрением передовых технологических решений от мировых лидеров. Но нельзя забывать, что программные средства, такие как Service Desk от HP или Remedy ITSM Suite, являются лишь инструментами, помогающими специалистам построить бизнес-процессы для достижения заветной цели — плодотворного использования всего комплекса информационных технологий и телекоммуникационных средств в банковском деле. Кроме того, требуется, чтобы эти инструменты были грамотно внедрены и органично вписались в общую систему поддержки бизнеса банка.

Не углубляясь в детали, перечислим основные этапы внедрения решений ITSM в кредитном учреждении:

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

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

3.      Выбор, инсталляция и настройка программных средств, составляющих ядро системы.

4.      Адаптация системы под постоянно изменяющиеся условия функционирования —организационные и территориальные.

5.      Интеграция с другими информационными системами, например с системами мониторинга и управления сетевым оборудованием, средствами телекоммуникаций, Call-центром, сетью банкоматов и т.д.

Таков обычный порядок работы с заказчиками, принятый на вооружение системными интеграторами во всем мире. Активно практикуется он и известными российскими компаниями, такими как Tops BI и IBS. Конкретный пример — построение специалистами IBS Интегрированной системы управления телекоммуникационными и информационными ресурсами (ИСУ ТИР)[xviii] для Банка России. Этот проект, реализованный на базе Remedy AR System, является уникальным не только для нашей страны — в результате его выполнения создана единая распределенная диспетчерская служба национального масштаба.

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

Традиционно для России под поставщиками ИТ-услуг понимаются не внутренняя ИТ-служба банка, а внешние независимые компании, и в этой связи уместно упомянуть о еще одном любопытном обстоятельстве. Если поставщики ИТ-услуг стоят на более зрелом уровне развития, то с высокой долей вероятности банк тоже будет приобщен[xix] к принципам ITSM. Так, уже более сотни кредитных учреждений — клиентов «R-Style Softlab» регистрируют инциденты и описывают свои конфигурации в корпоративной сервисной системе I-Support[xx], специально разработанной для оказания консультационных ИТ-услуг. Организации, работающие с I-Support, могут подтвердить, что ее преимущества вполне осязаемы. И несмотря на то что в I-Support банки выступают в качестве конечных пользователей, фактически им предоставлены отдельные функции Service Desk: по управлению конфигурациями, инцидентами, проблемами, качеством услуг и эксплуатируемых программных продуктов. Головные отделения многофилиальных банков получили реальные инструменты для контроля инцидентов и проблем в своих территориально удаленных подразделениях и филиалах. Кроме того, специалисты «R-Style Softlab» с рядом банков уже наладили интерфейсы взаимодействия I-Support и HP Open View Service Desk, и сейчас они работают в тестовом режиме.

 

[Врезка № 2]

 

Подведем краткий итог. Планы по интеграции России в ВТО, активная игра регулирующих структур на банковском рынке России, а также все более глубокое проникновение на него западных банков ставят отечественные кредитные учреждения в условия жесткого контроля и конкуренции. Чтобы выжить в этой ситуации, банку нужно быть либо «богатым, правильным и незаметным», либо эффективным и динамично развивающимся (а еще лучше, разумеется, обладать всеми перечисленными качествами). Но эффективная деятельность и динамичное развитие просто немыслимы в отрыве от наращивания гибкости и мощности ИТ-инфраструктуры и, что немаловажно, от организации грамотного взаимодействия бизнеса и автоматизации. Модели этих взаимоотношений созданы, их принципы описаны в ITIL, апробированы на базе ITSM в конце 80-90-х годов прошлого века, и крупные российские банки уже переходят к их применению. Сами по себе принципы открыты и доступны для кредитного учреждения любого масштаба. Тем не менее правильное их восприятие и внедрение в практику требуют определенного уровня организационной зрелости. С другой стороны, переход на рельсы ITSM заставляет четко осознавать уровень зрелости, достигнутый на данный момент, и стимулирует планы по переходу на следующий этап.

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

По опыту сложившейся практики можно сказать, что на базе общедоступных материалов ITIL крупные западные и российские производители и поставщики ИТ-инфраструктуры (программного обеспечения, оборудования, услуг) создают и внедряют у себя и среди своих клиентов собственные интерпретации принципов ITSM. В то же время для решения данного вопроса кредитные организации предпочитают использовать услуги внешних консультантов и готовые программные продукты. При этом я возьму на себя смелость утверждать, что банки — клиенты компании «R-Style Softlab» получили определенное преимущество, так как приобщение к принципам ITSM для них началось и продолжается в рамках существующих SLA на базе услуг, поставляемых через платформу I-Support.


 

[Врезка № 1]

 

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

В проекции на историю развития услуг поддержки компании «R-Style Softlab» вышеописанная эволюция выглядит так:

Уровни зрелости 0-1: 1994—1997 гг.

В 1994 году был создан и внедрен первый модуль для учета и управления конфигурациями. Он имел весьма ограниченную функциональность и служил только для контроля и изменения лицензий на продукты, переданные банкам.

Спустя три года после выхода на рынок, в 1996 г., начался переход от бесплатной поддержки к услугам в рамках договоров на сопровождение различного уровня. Была внедрена первая CRM собственного производства с целью упорядочения БД клиентов, ведения информации о действующих договорах сопровождения и их уровнях, регистрации инцидентов.

Уровни зрелости 1-2: 1998—2001 гг.

К 1998 году пришло понимание необходимости реорганизовать структуру отдела поддержки — от деления по профилю специалистов перешли к делению по следующим видам предоставляемых услуг:

·              внедрение решений от «R-Style Softlab»;

·              оперативные консультации на территории банка;

·              заочные консультации;

·              обучение, адаптация функциональности и др.

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

В 1999 г. в новой версии CRM была полностью изменена технология работы с обращениями пользователей, управление инцидентами стало осуществляться с использованием модуля управления проблемами, свое развитие получили функции управления сервисными соглашениями.

Уровень зрелости 3: 2002—2004 гг.

В 2002 году компанией был получена Сертификат Госстандарта России, удостоверяющий, что функционирующая в компании система менеджмента качества соответствует требованиям ГОСТ Р ИСО 9001-2001 и MC ISO 9001:2000. Было решено начать работу по подготовке формализованной оценки качества предоставляемых услуг. На основе анализа путей решения этой непростой проблемы был сделан вывод о необходимости предоставления клиентам новой услуги — оперативных консультаций по продуктам через интернет-канал. Для ее реализации были сформированы требования и под них создана новая платформа — I-Support. В конце 2002 года интернет-канал обслуживания клиентов был запущен в тестовую эксплуатацию. В течение всего следующего года велась его опытная эксплуатация и наращивалась функциональность.

Начиная с 2004 г., I-Support переведен в промышленную эксплуатацию. Целый ряд клиентов обратились с просьбой предоставить платформу I-Support для использования внутри банков. «R-Style Softlab» начала масштабировать для своих клиентов технологии, примененные в I-Support.


 

[Врезка № 2]

 

I-Support — это система для полноценной автоматизации процесса управления инцидентами, реализованная компанией «R-Style Softlab» на базе веб-технологий. С ее внедрением были решены задачи по взаимодействию с уже функционирующими в компании системами, автоматизирующими следующие процессы:

-   управление конфигурациями;

-   управление проблемами;

-   управление знаниями;

-   управление качеством;

-   управление затратами;

-   управление взаимоотношениями с клиентами;

-   управление SLA.

Комплексный подход, заложенный в основу I-Support, позволяет консультантам и менеджерам сервисной службы, а также другим заинтересованным специалистам компании из единой точки — будь то карточка инцидента, карточка клиента, отчет по качеству или «шахматка» для учета затрат, — выбрав курсором любую значимую сущность или агрегированные результаты, «проваливаться» в детализацию, получая всю связанную информацию об инциденте, проблеме, клиенте или его сотрудниках, действующих SLA и др. Особо ценным для такого территориально распределенного холдинга, как «R-Style» (его офисы располагаются практически во всех регионах России, а также на Украине, в Киеве), является то, что доступ ко всей функциональности системы I-Support может выполняться по Интернету из любого филиала. Для консультантов, обсуждающих в I-Support методы диагностики инцидента, уже не важно, где находится собеседник, — за соседним столом или аж за Уральскими горами.

Данная технология ощутимо расширяет круг квалифицированных консультантов. Так, в 2004 г. вопросами-темами, поднятыми клиентами в I-Support, в «R-Style Softlab» занимаются более 50 сотрудников. По состоянию на июнь текущего года ежемесячно средствами I-Support пользуются около трехсот специалистов подразделений автоматизации из более чем ста кредитных учреждений (живую статистику см.: https://isupport.softlab.ru/Portal/InterSupport/). Благодаря I-Support банк не только может оформить сообщение об инциденте, но и видеть ход его разрешения, контролировать прохождение заявленной проблемы, получать информацию о ее состоянии и предложенных «Hotfix», поддерживать обратную связь, оценивая качество работы. Банку доступен журнал всех оформленных его специалистами (в том числе из удаленных филиалов) инцидентов и проблем, контекстный поиск по этому массиву, а также по открытым инцидентам, оформленным другими банками.

Внедрение I-Support позволило компании «R-Style Softlab» не только автоматизировать процесс управления инцидентами, но и решить ряд глобальных задач, в том числе:

·   появилась возможность давать формализованную и четкую оценку качества работы с клиентами и оперативно оценивать уровень их удовлетворенности;

·   решен вопрос об оценке квалификации, объемов и качества работы консультантов, сформирована эффективная система мотивации консультантов;

·   сокращены затраты на процесс управления инцидентами за счет снижения трудоемкости процесса, увеличения скорости выполнения операций, привлечения квалифицированных и зачастую простаивающих ресурсов из удаленных филиалов;

·   увеличено (и это объективно измеряется) качество работы с клиентами.

Иными словами, I-Support — это реальное подтверждение принципов и целей ITSM-методологии в действии.



[i] ITIL — IT Infrastructure Library — это обобщение лучшего международного опыта в области организации и управления информационными технологиями. Библиотека ITIL является собственностью Комитета по вычислительной технике и телекоммуникациям при правительстве Великобритании — OGC (http://www.ogc.gov.uk). На сегодняшний день это фактический стандарт, который используется предприятиями и организациями во всем мире. Дополнительную информацию см.: на английском — http://www.itil.co.uk и на русском языке — http://itsmf.ru/main.phtml?oblast=itil. Более подробно об ITIL см. переводную статью «The ITIL Story», в которой изложена история создания ITIL; описаны основные термины, применяемые в ITIL, ее принципы и философия; обозначен круг лиц, на которых она рассчитана; названы книги, входящие в библиотеку; перечислены выгоды от применения методологии ITIL; даны условия и виды сертификации,— http://www.softintegro.ru/products/itil/pdf/pe_itil_story.pdf.

[ii] См. статью Н.Дубовой «ITSM — новая идеология управления ИТ» — «Открытые системы», 2000, № 10 (http://www.osp.ru/os/2000/10/037_print.htm).

[iii] См. http://www.osp.ru/os/2004/01.

[iv] См. статью А.Фойгта «Как правильно составить SLA в ИТ?» — http://cnews.ru/newcom/index.shtml?2004/07/09/161072.

[v] Слово «эникейщик» (от англ. «Press any key») активно используется в сленге компьютерщиков, обозначая ИТ-специалиста широкого профиля, но обладающего неглубокими знаниями.

[vi] Инцидент определяется в материалах ITIL как любое событие (и факт сообщения о нем), не являющееся частью нормального функционирования сервиса, которое повлекло или может повлечь за собой невозможность использовать сервисы, обычно предоставляемые пользователям.

[vii] Проблема - в соответствие с материалами ITIL — это общая неизвестная первопричина одного или группы инцидентов.

[viii] Замысловатые схемы субординации, согласно которым служба автоматизации подчиняется главному бухгалтеру, начальнику АХО, службы безопасности, отдела РКО и другим руководителям «второго эшелона», неизбежно отбрасывают банк на Этап 0.

[ix] Недоразумение возникает из-за того, что никогда не следует объединять роли Менеджера инцидентов и Менеджера проблем — метрики этих процессов противоречивы. Если цель первого — зафиксировать как можно больше инцидентов, то второй, наоборот, заинтересован в том, чтобы инцидентов было зарегистрировано как можно меньше.

[x] Данное описание эволюции (зрелости) отношений автоматизации и бизнеса является эмпирическим и основано на личном опыте автора. Более строгую оценку уровня зрелости можно найти в переводной статье «ITIL Process Maturity Self-Assessment & Action Plan» («План действий и самостоятельная оценка зрелости процессов ITIL») компании «Pink Elephant» — http://www.softintegro.ru/products/itil/pdf/pe_itil_process.pdf. См. также раздел «Модели зрелости» в статье С.Гузика «Стандарт CobiT» — http://www.citforum.idknet.com/consulting/standart_cobit/article1.1.2003130.html#AEN288.

[xi] Интеграция и оптимизация – характерны соответственно для 4-го и 5-го уровней модели зрелости CMM, которая легла в основу аналогичной модели ITSM.

[xii] См. статью К.Скрипкина «ITSM в России. Экономический аспект»http://www.osp.ru/cio/2004/04/064_print.htm.

[xiii] См. «ITSM. Основные процессы» — http://itsmf.ru/main.phtml?oblast=itsm&razdel=process.

[xiv] См. «Методология HP ITSM» — http://www.hp.ru/telecom/itsm/methodology.

[xv] См. русскоязычный сайт веб-сервера «Hewlett-Packard», раздел о продукте «HP Open View Service Desk» — http://www.hp.ru/openview/products/servicedesk.

[xvi] См. русскоязычный сайт веб-сервера «Rеmedy», раздел о продукте «Remedy IT Service Management» — http://www.remedyru.ru/itsm/itsm.html.

[xvii] Например, узкопрофильное решение на базе веб-технологий от российского производителя компании «Кречет» — Crechet HelpDesk Lite 1.0 — см.: http://www.crechet.ru/products/chd_v1.htm.

[xviii] См. http://www.cio-world.ru/analytics/review/27548/

[xix] Принцип «связанного роста» заложен в идеологию модели зрелости, и его можно трактовать следующим образом: бесполезно пытаться поднимать уровень зрелости одного процесса (вкладывать деньги и силы), если уровни зрелости связанных процессов (входящих, исходящих) ниже него более чем на одну ступень.

[xx] См. статью Л.Головина «Новый канал сопровождения клиентов I-Support» — «RS-Club», 2003, № 1/28/, с.46—49 (https://isupport.softlab.ru/Portal/InterSupport/Demo/Articles/I-Support_point_of_view_1my.htm).