Часть 2. Операционное управление информационными технологиями

К оглавлению 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
17 18 22

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

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

Особенности управления ИТ-персоналом

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

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

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

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

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

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

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

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

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

Элементы системы управления персоналом

Рассмотрим основные элементы системы управления персоналом. К ним можно отнести:

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

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

развитие персонала - включает обучение и переподготовку персонала, перемещение, оценку и продвижение персонала, подготовку резервов специалистов и руководителей;

мотивацию и стимулирование персонала - включают оплату труда, дополнительные стимуляционные выплаты и систему мотивации труда;

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

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

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

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

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

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

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

Типовые роли

Каковы типовые роли и специализации ИТ-работников? Можно выделить следующие основные группы.

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

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

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

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

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

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

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

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

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

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

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

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

Отдельно несколько слов необходимо сказать об ИТ-менеджерах. Их роль, как и в любой другой деятельности, очень высока. Для управления ИТ требуются две группы менеджеров - линейные менеджеры и руководители проектов. Линейные (или функциональные) менеджеры возглавляют статические подразделения, такие, как отдел поддержки пользователей, отдел обслуживания оборудования и т.п. (пример структуры ИТ-подразделения представлен в приложении). Руководители проектов (Project Managers) осуществляют оперативное управление отдельными проектами в области ИТ (как мы уже отмечали, большинством работ в ИТ-подразделении целесообразно управлять по проектным принципам, и этому будет посвящена следующая часть книги). Естественно, что принципиальную роль в правильной организации ИТ-службы играет ИТ-директор, или СЮ (о его роли мы уже писали).

Риски персонала и совмещение

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

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

Таблица 6

Возможность совмещения участков работ*(5)

┌────────────┬────────┬─────────┬───────┬────────┬────────┬─────────┬──────────┬────────┬────────┬──────────┬─────────┬──────────┐

│ │Систем- │Приклад- │Тести- │ Храни- │Систем- │Админист-│Админист- │Контро- │Инженеры│ Инженеры │Эксперты │Банковские│

│ │ ные │ ные │ровщики│ нители │ ные │ раторы │ раторы │ леры │ по │ по │поддержки│технологи │

│ │аналити-│програм- │ │программ│програм-│ данных │безопасно-│качества│компью- │ телеком- │ │ │

│ │ ки │ мисты │ │ │ мисты │ │ сти │ │ терам │муникациям│ │ │

├────────────┼────────┼─────────┼───────┼────────┼────────┼─────────┼──────────┼────────┼────────┼──────────┼─────────┼──────────┤

│ │ 1 │ 2 │ 3 │ 4 │ 5 │ 6 │ 7 │ 8 │ 9 │ 10 │ 11 │ 12 │

│ Системные │ │ │ │ X │ X │ │ X │ X │ │ │ │ │

│ аналитики │ │ │ │ │ │ │ │ │ │ │ │ │

│ Прикладные │ │ │ X │ X │ X │ X │ X │ X │ │ X │ X │ │

│программисты│ │ │ │ │ │ │ │ │ │ │ │ │

│Тестировщики│ │ X │ │ │ X │ X │ X │ │ │ │ X │ X │

│ Хранители │ X │ X │ │ │ X │ │ X │ │ │ │ │ X │

│ программ │ │ │ │ │ │ │ │ │ │ │ │ │

│ Системные │ X │ X │ X │ X │ X │ X │ X │ │ X │ X │ X │ X │

│программисты│ │ │ │ │ │ │ │ │ │ │ │ │

│Администра- │ │ X │ X │ │ X │ │ │ │ │ │ │ │

│торы данных │ │ │ │ │ │ │ │ │ │ │ │ │

│Администра- │ X │ X │ X │ X │ X │ │ │ │ X │ X │ X │ X │

│ торы │ │ │ │ │ │ │ │ │ │ │ │ │

│безопасности│ │ │ │ │ │ │ │ │ │ │ │ │

│ Контролеры │ X │ X │ │ │ │ │ │ │ X │ X │ │ X │

│ качества │ │ │ │ │ │ │ │ │ │ │ │ │

│Инженеры по │ │ │ │ │ X │ │ X │ X │ │ │ │ X │

│компьютерам │ │ │ │ │ │ │ │ │ │ │ │ │

│Инженеры по │ │ X │ │ │ X │ │ X │ X │ │ │ │ X │

│телекоммуни-│ │ │ │ │ │ │ │ │ │ │ │ │

│ кациям │ │ │ │ │ │ │ │ │ │ │ │ │

│ Эксперты │ │ X │ X │ │ X │ │ X │ │ │ │ │ X │

│ поддержки │ │ │ │ │ │ │ │ │ │ │ │ │

│ Банковские │ │ │ X │ X │ X │ │ X │ X │ X │ X │ X │ │

│ технологи │ │ │ │ │ │ │ │ │ │ │ │ │

└────────────┴────────┴─────────┴───────┴────────┴────────┴─────────┴──────────┴────────┴────────┴──────────┴─────────┴──────────┘

Мотивация и стимулирование

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

1. Анализ сложившейся системы внутренних взаимоотношений сотрудников и их трудовой мотивации.

2. Разработка общих принципов мотивации сотрудников и системы оплаты и стимулирования.

3. Согласование и обсуждение выработанных подходов и принципов систем мотивации и стимулирования со всеми звеньями руководства кредитной организации.

4. Оформление и внедрение системы стимулирования персонала. Как показывает практика, создание эффективно функционирующей системы мотивации, не требующей повышения фондов оплаты труда, возможно не только теоретически, но и практически. Составные элементы системы мотивации могут варьироваться в зависимости от результатов анализа текущего положения, особенностей взаимоотношений внутри организации и персонального состава сотрудников. Перечислим элементы, которые должна включать система мотивации.

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

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

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

Поощрения за сокращение издержек при выполнении работы.

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

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

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

Обучение и сертификация

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

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

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

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

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

- внешнее обучение ИТ-сотрудников;

- специализированное внутреннее обучение ИТ-сотрудников;

- привлечение высококвалифицированных специалистов;

- внутренняя миграция кадров;

- сертификация ИТ-специалистов;

- обучение пользователей.

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

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

Каковы же сами механизмы получения и поддержки высокого уровня образования и квалификации сотрудников, их преимущества и недостатки.

Внешнее обучение

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

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

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

* отсутствие адекватной, своевременной реакции учебных заведений на быстро меняющиеся процессы в сфере практической деятельности и особенно ИТ;

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

* слабость материально-технической базы для подготовки специалистов;

* длительность процесса обучения и, как следствие, его неудобство для работающих специалистов.

К положительным аспектам обучения на базе высших учебных заведений следует отнести:

* комплексный, многосторонний характер обучения;

* возможность получения фундаментальных базовых знаний.

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

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

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

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

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

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

Внутреннее обучение

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

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

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

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

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

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

Привлечение специалистов

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

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

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

Внутренняя миграция кадров

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

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

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

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

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

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

Сертификация специалистов

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

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

Примерами наиболее известных сертификационных программ первого типа могут быть сертификаты компаний Microsoft, Oracle, Cisco, Nowell.

Примером сертификационных процессов второго типа может быть получение степени аудитора информационных систем (CISA - Certified Information System Auditor). Эта степень предоставляется ассоциацией аудита информационных систем (ISACA - Information System Audit and Control Associasion). Для получения степени необходимо сдать квалификационный экзамен и соответствовать ряду дополнительных требований в области образования, опыта работы. Как правило, такими требованиями являются профильное высшее образование и опыт работы около 3 лет по этой специальности. В целом эти требования нельзя назвать строгими (чего нельзя сказать об экзамене), так как и для этого экзамена, и для многих других разрешается заменять требуемые параметры смежными. Так, например, недостаток опыта может быть компенсирован глубоким образованием или опытом в смежных областях.

Квалификационный экзамен строится по принципу ответа на один из четырех предложенных вариантов (так называемый Multiply Choice Question). Экзамен состоит из 200 вопросов на английском языке по семи областям:

* процесс аудита информационных систем;

* планирование, организация и управление ИТ;

* техническая инфраструктура и операционная практика;

* защита информационных активов;

* планирование действий на случай чрезвычайных ситуаций и сбоев;

* разработка, приобретение, внедрение и поддержка информационных систем;

* оценка бизнес-процессов и управление рисками.

Соискателям предоставляются четыре часа времени для ответа на все вопросы. Экзамен является платным (около $500) и проходит раз в год одновременно в нескольких странах, в том числе в Москве. Экзамен считается сданным, если более 75% ответов правильные. При успешной сдаче экзамена и соответствии требованиям соискателю присваивается данная сертификационная степень и высылается сертификат. В приложениях приведен пример из двадцати вопросов с ответами по этому экзамену.

Другим примером может быть получение степени сертифицированного руководителя проекта (РМР - Project Management Professional). Эта степень предоставляется Институтом проектного управления (Project Management InstiTute). Для получения степени необходимо пройти небольшое начальное обучение (35 часов), сдать квалификационный экзамен, а также соответствовать дополнительным требованиям по образованию и практическому опыту управления проектами. Экзамен платный (цена приблизительно такая же, как и в предыдущем случае), возможна сдача в России. Данная степень является важным элементом развития для ИТ-менеджеров и руководителей проектов в области ИТ.

Обучение пользователей

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

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

Обслуживание пользователей

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

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

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

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

Принципы поддержки пользователей

Итак, какова best practice организации обслуживания и поддержки пользователей?

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

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

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

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

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

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

Технологическая схема работы

Технологическая схема организации работы службы поддержки пользователей представлена на рис. 11. Рассмотрим отдельные моменты этой технологии и сделаем необходимые комментарии.

"Рис. 11. Схема организации работы службы поддержки пользователей"

Технология предполагает четыре основных группы участников процесса: пользователей, диспетчера (оператора), авторизующего сотрудника, исполнителей.

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

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

Исполнители по проблемам отвечают за разрешение проблемы или поставленной задачи в требуемый период времени и отражение результатов работы в информационной базе данных.

Типы запросов и приоритезация

Все запросы пользователей можно условно разделить на три основные группы: информационные, сервисные, проблемные.

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

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

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

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

Также оператором должен присваиваться приоритет проблемы, который, как правило, определяет и время реакции или решения. Пример приоритетов запросов приведен в табл. 7.

Таблица 7

Пример приоритезации запросов пользователей

┌─────────────────────┬───────────────────────┬─────────────────────────┐

│Градация приоритета │ Степень приоритета │ Гарантированное время │

│ │ │ реагирования │

├─────────────────────┼───────────────────────┼─────────────────────────┤

│Высокий - 1 │высокая - система не│менее 1 часа │

│ │работает, пароли,│ │

│ │прочее │ │

│Средний - 2 │средняя - некоторые│в течение 4 часов │

│ │функции не работают │ │

│Низкий - 3 │низкая - общие вопросы,│в течение дня │

│ │не останавливает работу│ │

└─────────────────────┴───────────────────────┴─────────────────────────┘

База данных запросов и автоматизация

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

* Отслеживание статуса заявки. Система должна позволять присваивать заявкам разные приоритеты и переводить их из одного статуса в другой.

* Автоматическое оповещение о подходе крайнего срока решения проблемы. Данная возможность позволит избегать ситуации, когда о запросе просто забыли.

* Механизм электронной авторизации заявки также должен поддерживаться системой, что позволит ускорить процесс в целом.

* Хранение прошлых проблем (заявок) и их решений (ответов на информационные запросы). Удобная поисковая система должна облегчать работу с архивом.

* Автоматическое оповещение исполнителей о поступивших проблемах. Оно может быть реализовано через электронную почту или сообщения на мобильные телефоны (SMS).

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

* Генерирование отчетов о работе для целей управления и контроля.

Отчетность и контроль

Следующей важной составляющей процесса организации поддержки пользователей являются отчетность и контроль. На рис. 12 графически представлен эффективный интегрированный подход к этому процессу.

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

"Рис. 12. Контроль за обслуживанием пользователей"

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

- стоимость поддержки одного пользователя;

- стоимость поддержки функционального подразделения;

- относительное изменение стоимости поддержки пользователя;

- простой сотрудников службы сопровождения (финансовые потери).

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

- процент пользователей, довольных службой поддержки;

- оценки работы различных операторов, экспертов;

- относительное изменение суммарной оценки качества сопровождения.

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

- процент закрытых проблем от общего количества;

- процент проблем, закрытых в заданный срок;

- относительное изменение количества регистрируемых запросов;

- процент проблем, решенных на первом уровне (оператором);

- процент просроченных проблем;

- соотношение между количеством проблем каждого приоритета;

- средний срок решения проблемы;

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

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

Управление качеством

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

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

За рубежом разработаны и успешно применяются на практике различные методики управления качеством, как общие (TQM, Six Sigmas, IS09000), так и специализированные, предназначенные для управления качеством программных продуктов (TickIT).

Всеобщее управление качеством (TQM)

Одной из основополагающих и широко используемых в международной практике концепций, помогающих руководителям решать задачи контроля и управления качеством, является методология "Всеобщее управление качеством" (Total Quality Management, TQM). Мы полагаем, что в современных условиях она вполне применима для ИТ. Но прежде чем мы рассмотрим ее основные положения и возможности их применения, необходимо остановиться на истории создания TQM.

Концепция всеобщего управления качеством зародилась в США, а в полном объеме впервые была реализована в Японии. Именно американские ученые-экономисты Эдвард Деминг (1900-1993) и Джозеф Джуран (1903-1993), направленные, согласно плану Маршалла, для оказания помощи разрушенной в ходе войны экономике Японии, впервые сформулировали те общепризнанные сегодня принципы, которые и составили концептуальную основу TQM. Эти принципы стали главной составляющей феномена, так хорошо всем известного под названием "японское чудо".

В основу концепции TQM легли базовые принципы, сформулированные и изложенные Демингом:

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

* необходимо внедрять новую философию и отношение к окружающим процессам;

* постоянно соотносить качество и удовлетворенность потребителя с ценой;

* вести постоянное обучение, прежде всего на рабочем месте;

* устранять барьеры между подразделениями;

* искоренять страх перед переменами;

* дать возможность всем служащим гордиться принадлежностью к организации;

* всячески поощрять образование и самосовершенствование;

* вовлечь каждого в работу по преобразованию;

* избегать пустых лозунгов;

* организовать руководство таким образом, чтобы его основным предназначением была помощь работникам;

* отказаться от контроля качества только посредством проверок и ревизий;

* стремиться к постоянному улучшению всей системы функционирования организации;

* искоренять "уравниловку" персонала.

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

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

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

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

Стандарт качества ISO 9000

Остановимся на основных моментах управления качеством услуг в соответствии со стандартами серии ISO 9000. Для этого прежде всего обратимся к его терминам и определениям.

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

Элемент программного обеспечения - какая-либо идентифицируемая часть продукции программного обеспечения на промежуточном или конечном этапе разработки.

Разработка - все виды деятельности, выполняемые для создания программного обеспечения.

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

Аттестация программного обеспечения - процесс оценивания программного обеспечения в целях обеспечения соответствия установленным требованиям.

Услуга - итог непосредственного взаимодействия поставщика (Supplier) и потребителя (Customer), а также внутренней деятельности поставщика по удовлетворению потребности потребителя.

Предоставление услуги (Service Delivery) - деятельность поставщика, необходимая для обеспечения услуги.

Качество услуги - совокупность свойств и характеристик услуги, обеспечивающих удовлетворение обусловленных или предполагаемых потребностей.

Требования к качеству - выражение определенных (установленных или предполагаемых) потребностей потребителя и их перевод в набор количественных или качественных оценок характеристик услуги.

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

Стандарт ISO 9000 помимо основной терминологии регламентирует процесс подготовки и предоставления услуги, а также систему качества.

Принято считать, что достижение требуемого качества возможно благодаря строгому следованию этапам (или основным составляющим) процессов, описанных в стандарте, и работе по общему управлению качеством (или системе качества). Рассмотрим применяемую на практике методику подготовки услуги, соответствующую стандарту ISO 9000, и ее этапы.

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

Шаг 1. Определить и поименовать потребность, подлежащую удовлетворению услугой.

Шаг 2. Определить, в какой потенциальной группе клиентов эта потребность существует.

Шаг 3. Описать ту часть услуги (работу, результаты работы и т.д.), которая удовлетворит выявленную потребность.

Шаг 4. Определить, по каким характеристикам клиент будет оценивать услугу и степень удовлетворения услугой своей потребности.

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

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

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

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

Реклама и продвижение услуги. Для формирования и разработки рекламной политики и программы продвижения услуг необходимо использовать спецификации услуг и процессов их предоставления.

Клиент, читая или рассматривая рекламу, должен находить ответы наследующие вопросы, определяющие сегодня конкурентоспособность услуги.

Существует ли у меня неудовлетворенная потребность из тех, что описаны в рекламных материалах?

Соизмеряется ли стоимость услуг с их качеством?

Действительно ли поставщик способен оказать необходимую услугу?

Насколько выгоднее обратиться к данному поставщику, чем к другим?

Рассмотрим теперь элементы системы качества, необходимые для ее соответствия требованиям стандарта ISO 9000. Для этого введем точное определение этого термина. Стандарт ISO 9000 использует определение из ISO 8402: система качества - это совокупность организационной структуры, методик, процессов и ресурсов, необходимых для общего управления качеством. Все эти элементы системы качества должны быть задокументированы. Документация должна давать четкие гарантии, что элементы системы качества обеспечивают потребителю получение качественной услуги - выполнение обещаний поставщика услуги, а также удовлетворение потребности и ожиданий потребителя.

В стандартах серии ISO 9000 предыдущих редакций содержались рекомендации по управлению качеством программных продуктов. Сформулируем основные из них.

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

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

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

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

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

Регулярный совместный анализ, проводимый заказчиком и поставщиком, должен планироваться так, чтобы охватить следующие вопросы: соответствие программного обеспечения техническому заданию, согласованному с покупателем; результаты контроля; результаты приемочных испытаний. Результаты анализа должны быть документированы.

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

Поставщик должен документально оформить план качества и осуществлять регулярные проверки в соответствии с ним.

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

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

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

Жизненный цикл программного обеспечения

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

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

С точки зрения качества целесообразно включение в контрактные документы следующих пунктов: критерии приемки; учет изменений в требованиях заказчика в процессе разработки; проработку проблем, выявленных в ходе приемки; ответственность заказчика за подготовку требований, приемку и т.п.; средства, инструменты и элементы поставляемого программного комплекса; применяемые стандарты и процедуры; особенности тиражирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- решение проблем;

- модификация интерфейса;

- расширение функций и улучшение эксплуатационных характеристик.

Элементы, которые должны быть обслужены, и период времени обслуживания должны оговариваться в контракте. Такими элементами могут быть программы, данные и их структура, спецификации, документация.

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

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

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

Стороны должны согласовать между собой и документально оформить процедуры, связанные с внесением изменений в программное обеспечение в результате необходимости поддерживать эксплуатационные характеристики:

основные правила, определяющие, в каких случаях можно внести исправления, а в каких необходим выпуск полностью обновленной копии программного обеспечения;

описание типов (или классов) выпусков в зависимости от их частоты и воздействия на деятельность заказчика;

способы уведомления об изменениях;

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

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

Специализированный стандарт TickIT

Специализированный стандарт TickIT - это схема сертификации систем качества для программного обеспечения, предложенная группой ведущих фирм и некоммерческих организаций Великобритании, работающих в области информатики. Контроль и спонсирование схемы осуществляется DTI. TickIT базируется на стандарте ISO 9001:1994, который был рассмотрен выше. Таким образом, предметом TickIT является менеджмент предприятий, разрабатывающих программное обеспечение.

Помимо своей основы (стандарта) ISO 9001 TickIT содержит следующие компоненты:

- руководство по TickIT, базирующееся на указаниях ISO 9000-3 (руководство по системам качества для программного обеспечения);

- схему регистрации аудиторов через специальный комитет по TickIT IRCA (Международный регистр сертифицированных аудиторов);

- систему проверок аудиторов Британским компьютерным обществом (BCS) и Институтом по обеспечению качества (IQA);

- систему аккредитации сертификационных обществ - UKAS (Великобритания), SWEDAC (Швеция);

- программы, направленные на расширение признания схемы;

- трехлетний цикл пересмотра схемы;

- систему специальных премий за достижения.

Гибкая инфраструктура TickIT позволяет схеме следовать изменениям в этой весьма динамичной отрасли, обеспечивая тем самым ее постоянное совершенствование.

В последней редакции руководства по TickIT активно используется идеология жизненного цикла программного обеспечения. Основные определения процессов жизненного цикла программного обеспечения даны в другом стандарте - ISO/IEC 12207, который может служить основой при выборе конкретной модели процессов жизненного цикла на предприятии. Таким образом, схема TickIT использует рациональное начало, заложенное в методах совершенствования процессов, таких, как СММ (Carnegie Mellon University), Trillium (Bell Canada), BOOTSTRAP и т.д. Великобритания традиционно занимает лидирующее положение в области стандартизации, поэтому неудивительно, что инициатива TickIT изначально принадлежит Великобритании.

Несмотря на британское происхождение, TickIT широко применяется и в других странах. В списке предприятий, сертифицированных по схеме TickIT, в настоящее время присутствуют названия более 40 государств. Марка и логотип TickIT пользуются заслуженным международным авторитетом. Получение сертификата TickIT является важным шагом любой европейской софтверной фирмы на пути к завоеванию признания на рынке. По данным на май 1997 года, в Великобритании было выдано 956 сертификатов TickIT, в других странах - 338. Растет количество сертификатов, выданных за пределами Великобритании. Предполагается, что дальнейшее расширение использования схемы TickIT приведет к созданию международной европейской схемы с аккредитацией согласно EN45012/3.

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

* разработкой программного продукта или услуги как для внешнего заказчика, так и для внутреннего использования, включая встроенное (embedded) программное обеспечение;

* копированием, архивированием, хранением данных и программным обеспечением;

* системной интеграцией, поддержкой, администрированием и др.

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

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

Особенности управления качеством ИТ-услуг

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

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

Остановимся на управлении качеством в процессе предоставления услуг. Для этого рассмотрим некоторые рекомендации, которые необходимо учесть на начальном этапе данного процесса:

- в большинстве случаев управление качеством услуги возможно только путем контроля процесса предоставления услуги. Категорически не рекомендуется полагаться только на контроль конечного результата;

- для обеспечения требуемого уровня качества необходимо иметь детальные спецификации (описания) услуг и процесса их предоставления. Как показывает практика, большинство банков сегодня их не имеет или не контролирует соответствие процесса предоставления услуги утвержденному регламенту;

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

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

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

После того как эти первостепенные мероприятия дадут свои результаты, можно приступать к дальнейшим шагам, например сертификации.

С другой стороны, даже независимо от задачи сертификации приведение процедур управления качеством в соответствие с требованиями концепции всеобщего управления качеством и стандарта ISO 9000 существенно продвинет организацию и послужит залогом ее будущего развития.

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

Управление аутсорсингом

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

Роль аутсорсинга в ИТ

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

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

Если говорить о целях, то, как правило, аутсорсинг используется:

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

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

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

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

* разработку и внедрение больших информационных систем;

* консалтинговые услуги (проведение тендеров, поиск партнеров, экспертные оценки, содействие в стратегии развития, подготовка регламентов, ИТ-аудит и т.п.);

* обслуживание и ремонт компьютерной и серверной техники;

* телекоммуникационные услуги;

* поддержку локальных сетей;

* обслуживание телефонного и офисного оборудования;

* развитие информационной безопасности;

* поддержку дорогостоящих с точки зрения ИТ бизнес-процессов (про-цессинг, выпуск пластиковых карт).

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

Взаимодействие с внешними поставщиками

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

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

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

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

После завершения проекта по возможности следует периодически пользоваться услугами конкурентов. Это заставит вашего основного партнера постоянно совершенствовать качество предлагаемых вам услуг.

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

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

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

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

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

Тендерная форма является предпочтительной для поиска подрядчика (подробно этот вопрос рассмотрен в первой части книги на примере выбора основной банковской системы).

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

При согласовании цен учитывайте следующее:

- среднерыночная стоимость ИТ-специалиста - $40 в час, а его средняя зарплата - $800-1000 в месяц;

- собственно лицензия для разработчика почти ничего не стоит, все затраты уже сделаны;

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

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

Риски аутсорсинга

Теперь рассмотрим некоторые специфические риски аутсорсинга, которые необходимо также учитывать.

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

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

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

Оперативная деятельность

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

Рассмотрим основные элементы текущей оперативной деятельности ИТ-службы (табл. 8).

Таблица 8

Основные составляющие оперативной деятельности ИТ-службы

┌────────────────────────────────┬──────────────────────────────────────┐

│Область оперативной деятельности│ Выполняемые работы │

├────────────────────────────────┼──────────────────────────────────────┤

│Обеспечение работы банковских│Анализ системы, реализация новых│

│информационных систем │требований, анализ производительности,│

│ │обеспечение бесперебойной работы │

│Обеспечение работоспособности│Работа с техническими средствами│

│офисных приложений │конечных пользователей, такими, как│

│ │персональные компьютеры, принтеры,│

│ │сканеры. Поддержка работы с локальными│

│ │приложениями. Консультирование│

│ │пользователей │

│Поддержка технических средств│Обеспечение бесперебойной работы│

│информационной системы │основных серверов организации и│

│ │резервных систем │

│Управление сетями организации │Управление сетями, используемыми для│

│ │передачи данных. Контроль│

│ │производительности и загруженности,│

│ │планирование развития сетей │

│Бесперебойная работа│Анализ, разработка, тестирование и│

│телекоммуникационных средств │установка технических средств│

│ │телекоммуникаций │

│Управление операционными│Администрирование операционных систем,│

│системами │используемых в организации │

│Администрирование баз данных │Поддержка работающих систем управления│

│ │базами данных, включающая в себя│

│ │управление производительностью,│

│ │резервное копирование, устранение│

│ │сбоев в работе. Моделирование и│

│ │разработка корпоративных хранилищ│

│ │информации │

│Обеспечение входящих│Обеспечение бесперебойного ввода в│

│информационных потоков │систему справочных значений (курсы│

│ │валют, справочники кодов) │

│Обеспечение электронной почтой │Администрирование почтового сервиса│

│ │организации, а при его отсутствии -│

│ │разработка политики пользования почтой│

│ │сторонних организаций │

└────────────────────────────────┴──────────────────────────────────────┘

Технические регламенты

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

- сократить затраты на обучение и зарплату персонала;

- снизить риски принятия неправильных решений;

- выработать и поддерживать технические стандарты;

- отработать методы устранения исключительных ситуаций.

Наборы инструкций, которые определяют правила оперативной, каждодневной работы, в зарубежных организациях называются политиками (policies), в российских организациях - инструкциями, правилами, регламентами (табл. 9).

Таблица 9

Основные внутренние регламентирующие документы

┌──────────────────────┬────────────────────────────────────────────────┐

│ Наименование │ Содержание документа │

│ документа │ │

├──────────────────────┼────────────────────────────────────────────────┤

│ 1 │ 2 │

│System Architecture│Определяет базовые решения, применяемые в│

│Policy (системная│организации. Включает перечень операционных и│

│архитектура │телекоммуникационных систем, описание│

│организации) │используемых аппаратных платформ,│

│ │регламентируется порядок их взаимодействия. Как│

│ │правило, в документ входят следующие разделы: │

│ │ аппаратные платформы: │

│ │- спецификация серверов организации; │

│ │- спецификация персональных станций│

│ │пользователей; │

│ │- спецификация мобильных компьютеров; │

│ │ сетевые платформы: │

│ │- структура глобальных сетей организации; │

│ │- общие требования локальных сетей организации; │

│ │- требования к защите сетей; │

│ │ программное обеспечение: │

│ │- операционные системы; │

│ │- банковские системы; │

│ │- офисные приложения; │

│ │- утилиты обслуживания и администрирования │

│Data Architecture│Определяет модель хранилища данных организации,│

│(структура данных в│включая используемые системы управления данными,│

│организации) │описание сущностей системы и их атрибутов, связь│

│ │между ними и порядок доступа пользователей к ним│

│Use of External│Определяет порядок взаимодействия со сторонними│

│Packages (порядок│разработчиками, правила и область использования│

│использования внешних│их продуктов │

│разработок) │ │

│Use of External│Определяет порядок взаимодействия со сторонними│

│Resources (порядок│поставщиками услуг в области информационных│

│использования │технологий │

│сторонних ресурсов) │ │

│IT Security (правила│Регламентируют структуру системы информационной│

│информационной │безопасности организации. Определяют механизмы│

│безопасности) │защиты информационных потоков и права доступа к│

│ │информации для пользователей и сторонних систем │

│System Operability and│Содержит перечень работ для обеспечения│

│Service Recovery│эффективного и бесперебойного функционирования│

│(обеспечение │информационной системы организации. Данный│

│оперативной работы│документ может иметь следующие составляющие: │

│системы и порядок│ поддержка системы: │

│восстановления) │- порядок восстановления, остановки и запуска│

│ │системы; │

│ │- резервное копирование и архивация; │

│ │- использование вычислительных мощностей и│

│ │дискового пространства в системе; │

│ │- порядок внесения изменений в систему; │

│ │- инструкция по использованию интерфейса│

│ │администратора системы; │

│ │ внешнее обслуживание системы: │

│ │- сервисное обслуживание информационных систем; │

│ │- обеспечение входящих информационных потоков; │

│ │- требование к выходящим информационным потокам;│

│ │ контроль производительности системы: │

│ │- соответствие работоспособности системы и│

│ │утвержденным требованиям; │

│ │- эффективность использования ресурсов системы; │

│ │- поддержание актуальных во времени данных; │

│ │- порядок устранения текущих сбоев и ошибок│

│ │системы │

└──────────────────────┴────────────────────────────────────────────────┘

Циклы оперативной работы

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

В операционной работе ИТ-подразделений определяются три типа циклов:

* временные циклы;

* циклы, определенные критическими параметрами системы;

* циклы, определяемые общими процессами в организации. Рассмотрим по порядку каждый из циклов операционной работы ИТ-подразделения.

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

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

Следующий блок - это циклы, определенные критическими параметрами системы. Ряд работ при техническом обеспечении системы выполняется по наступлении какого-либо критического события, выявленного системой мониторинга. Обычно эти работы приводят к внесению изменений в деятельность системы с целью устранения нарушения или изменения критического параметра. Цикличность работ объясняется тем, что критичный параметр связан с эксплуатацией системы: регистрацией в ней новых объектов, ростом нагрузки и увеличением числа пользователей. При настройке механизмов контроля критических параметров следует устанавливать более строгие значения, чем требуется по технической спецификации. Это позволит перенести время выполнения работ на неоперационное время (табл. 10).

Таблица 10

Примеры критических параметров систем

┌──────────────────────────┬────────────────────────────────────────────┐

│ Параметр │ Выполняемые действия │

├──────────────────────────┼────────────────────────────────────────────┤

│Заполнение имеющегося│установка дополнительного дискового│

│дискового пространства │пространства; архивирование данных; перенос│

│ │данных на другие накопители │

│Достижение предела│установка более мощных вычислительных│

│производительности │систем; запуск оптимизационных процедур │

│Достижение максимального│оптимизация порядка эксплуатации системы;│

│количества пользователей│покупка дополнительных рабочих мест к│

│системы │системе │

│Полное использование│замена использованных материалов │

│расходных материалов │ │

└──────────────────────────┴────────────────────────────────────────────┘

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

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

* конец операционного дня;

* конец месяца;

* конец года.

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

Для отдела информационных технологий подобные события обычно связаны со следующими работами:

- установкой запрета на внесение изменений в закрытый период времени;

- резервным копированием;

- формированием отчетности;

- расчетами различных итоговых параметров системы;

- обновлением системных справочников.

Рассмотрим порядок проведения наиболее распространенных регламентных работ в российской кредитной организации.

Резервное копирование и архивирование

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

Приведем основные параметры системы резервного копирования.

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

1. Холодное резервирование - самый простой и соответственно самый дешевый метод создания копии, часто вовсе не требующий затрат. Основывается на остановке работы системы и прямом копировании файлов. Большинство систем, не требующих непрерывной круглосуточной работы, копируются именно этим способом.

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

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

Объем потерянных данных при восстановлении. Сеансовые методы резервного копирования подразумевают наличие данных, которые не вошли в последнюю резервную копию. При восстановлении таких систем проводится повторная регистрация данных. Их объем определяется частотой резервного копирования.

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

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

Оптимизация системы

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

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

Разделение задач системы по времени. Самым дешевым решением по увеличению производительности системы является перенос времени выполнения различных процедур на время минимальной загруженности системы.

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

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

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

Внесение оперативных изменений в систему

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

- разработка новых отчетов и печатных форм;

- изменения в документопотоке системы;

- администрирование пользователей системы и их обучение;

- изменение отдельных функций системы.

Обеспечение актуальной справочной информации

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

* справочники финансовых инструментов:

- справочник валют;

- справочник ценных бумаг сторонних эмитентов;

* справочники участников рынка:

- справочники банков;

- справочники юридических лиц;

* справочники законодательных актов.

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

Информационная безопасность

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

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

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

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

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

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

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

Нарушения конфиденциальности

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

Для иллюстрации рассмотрим наиболее часто встречающиеся примеры нарушения доступа к информации:

* ошибки администрирования:

- неправильное формирование групп пользователей и определение прав их доступа;

- отсутствие политики формирования паролей пользователей. При этом до 50% пользователей используют простые, легко подбираемые пароли, такие, как "123456", "qwerty" или собственное имя;

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

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

* ошибки проектирования информационной системы:

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

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

- небрежность в разработке системы защиты. Один из примеров данной небрежности - забытая разработчиками точка доступа в систему, такая, как универсальный пароль;

* небрежность пользователей в вопросах информационной безопасности:

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

- сохранение закрытого соединения после окончания работы. Уходя на обед или домой, пользователь не выключает компьютер и не выходит из банковской системы. Если система не имеет механизма временного отключения неактивных пользователей, данное нарушение делает бессмысленным большинство других требований системы безопасности;

- нерегламентированное обсуждение зарытой информации. При рассмотрении данного нарушения особенно следует обращать внимание на сотрудников информационных служб;

* умышленный взлом системы:

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

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

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

Изменения в системе

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

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

* ошибки программирования:

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

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

* ошибки ввода:

- ошибка ручного ввода - самая распространенная. Рост ошибок ручного ввода наблюдается в случаях обновления системы, изменения технологической цепочки, роста загруженности персонала или при смене сотрудника. Отсутствие этих факторов обычно приводит к снижению вероятности данной ошибки;

* технические сбои:

- сбой в работе системы, нарушение транзакции. Особенно подвержены данному виду сбои системы, базирующиеся на нетранзакционных базах данных. Промышленные СУБД, такие, как ORACLE, MS SQL, Sybase, как правило, обеспечивают целостность данных при любом виде сбоев, хотя и не дают абсолютных гарантий;

- нарушения передачи данных в каналах связи. Крайне редки случаи, когда данный вид сбоя системы приводит к изменению данных. Это связано с наличием механизма учета контрольных сумм, применяемого во всех имеющихся на сегодняшний день протоколах связи;

* умышленные нарушения в системе:

- несанкционированный умышленный ввод данных через пользовательский интерфейс;

- несанкционированные изменения в системе, минуя пользовательский интерфейс;

- подмена отдельных компонентов системы. Достаточно просто выявляемый, путем проверки контрольных сумм, тип нарушений;

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

Утрата работоспособности или производительности

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

Выделим причины, связанные с работоспособностью:

* ошибки разработки и проектирования:

- ошибка в требованиях масштабируемости системы. К ним относятся потери производительности при росте числа пользователей или объема обрабатываемой информации;

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

* технические проблемы, связанные с программно-аппаратным комплексом:

- неисправность оборудования и сбой в электропитании;

- конфликты между различными приложениями. Очень часто встречающийся вид технического сбоя в мультизадачных средах, особенно в операционной системе WINDOWS. Единственным эффективным средством устранения данной угрозы является разнесение задач по разным группам оборудования;

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

- слабая защищенность от целенаправленных действий со стороны по снижению работоспособности или полному выводу из строя информационных систем организации.

Источники и мотивы нарушений

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

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

Рассмотрим непреднамеренные ошибки сотрудников.

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

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

- двойной ввод документов;

- использование шаблонов;

- снижение нагрузки на персонал;

- дополнительный визуальный контроль документа.

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

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

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

Рассмотрим теперь преднамеренные действия сотрудников, нарушения, которые являются самыми сложными для предотвращения. Сотрудник организации, как правило, хорошо ориентируется во внутренних процессах и системах. Часто он знает о механизмах безопасности и, что более опасно, об их отсутствии в определенных модулях системы. У него есть время и возможность смоделировать и протестировать свои действия, оценить последствия.

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

Причинами, побудившими сотрудников к умышленному нарушению информационной безопасности, являются:

- обида на действия менеджеров, как правило, связанная с конфликтами или увольнением сотрудника;

- попытка дополнительного заработка;

- попытка хищения денег из организации;

- попытка создания зависимости организации от конкретного сотрудника;

- карьерная борьба.

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

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

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

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

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

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

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

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

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

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

Последняя по порядку, но далеко не последняя по смыслу причина - это аварии, стихийные бедствия и т.п.

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

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

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

* для организаций с большим бюджетом - создание резервного офиса. Как правило, достаточно, чтобы данный офис дублировал базовые функции основного офиса и мог обеспечить работоспособность организации только в аварийном режиме. Для этого необходимы один сервер, 2-3 комнаты и выход к внешним информационным системам. Для банков это SWIFT, REUTERS, локальные расчетные системы. В случае аварии резервный офис должен обеспечить работоспособность организации не более чем в течение одной недели. За это время должен решиться вопрос или с восстановлением основного офиса, или арендой нового;

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

Организация информационной безопасности

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

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

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

Результатом данных работ становится рабочая система информационной безопасности, регламентируемая документом "Политика информационной безопасности" (табл. 11).

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

"Рис. 13. Схема организации информационной безопасности"

Таблица 11

Примерная структура политики информационной безопасности

┌────────────────────┬───────────────────────────────────────────────┬─────────────────────────────┐

│ Глава документа │ Содержание │ Ответственные сотрудники │

├────────────────────┼───────────────────────────────────────────────┼─────────────────────────────┤

│ 1 │ 2 │ 3 │

│Общее положение │Определяется статус документа │Руководитель высшего звена.│

│ │ │Представители службы│

│ │ │безопасности │

│Классификация данных│Определяются группы объектов информационной│Технологи банка │

│по степени│системы, их владельцы и степень доступа к ним.│ │

│открытости. │Пример: аналитические счета банка,│ │

│Определение │синтетические счета, справочники │ │

│владельцев │ │ │

│информационных │ │ │

│ресурсов │ │ │

│Правила доступа и│Определяются основные правила доступа к данным.│Технологи банка,│

│группы пользователей│Пример: доступ к данным на чтение -│администратор системы │

│ │руководитель должен видеть всю информацию, к│ │

│ │которой имеют доступ все его подчиненные │ │

│Правила эксплуатации│В этой главе описываются правила по технике│Руководители подразделений,│

│ │информационной безопасности для пользователей│сотрудник │

│ │(правила хранения носителей информации,│информационно-технических │

│ │структура паролей, доступ к аппаратным│служб, сотрудник отдела│

│ │составляющим системы) │безопасности │

│Правила хранения│Данная глава определяет: │Руководитель │

│информационных │- какой программный продукт обеспечивает│информационно-технических │

│объектов в системе │хранение и обработку различных объектов; │подразделений, разработчики│

│ │- на каких процессорах (серверах или│системы, внутренний аудит │

│ │пользовательских станциях) выполняются│ │

│ │различные задачи; │ │

│ │- как осуществляется резервное копирование│ │

│ │системы │ │

│Правила разработки│Данная глава включает в себя: │Руководители проектов,│

│информационной │- перечень технических и программных средств,│внутренний аудит,│

│системы │допустимых к использованию в системе; │представители службы│

│ │- утвержденные алгоритмы криптографии и│безопасности │

│ │электронной подписи; │ │

│ │- порядок ведения проектной документации │ │

│Порядок внесения│В данной главе описывается самый уязвимый этап│Руководители проектов,│

│изменений, │в жизни информационной системы, связанный с│внутренний аудит,│

│обновления и замены│установкой и внедрением новых технологических│представители службы│

│рабочей версии│цепочек или программно-аппаратных решений │безопасности, руководители│

│информационной │ │подразделений │

│системы │ │ │

│Механизмы │В данной главе описывается перечень файлов│Внутренний аудит, технические│

│мониторинга доступа│протокола, которые ведутся системой, а также│специалисты │

│к объектам│набор контрольных метрик, определяющих│ │

│информационной │состояние системы и угрозы нарушений в ее│ │

│системы │работе │ │

│Обязанности │В этом разделе рассматриваются различные│Руководитель │

│должностных лиц в│нарушения или угрозы нарушений, выявленные в│информационно-технологическо-│

│случае нарушений│результате анализа механизмов мониторинга, и│го подразделения,│

│информационной │определяются действия должностных лиц по│представители службы│

│безопасности системы│устранению или предотвращению нарушений │безопасности │

└────────────────────┴───────────────────────────────────────────────┴─────────────────────────────┘

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

Меры информационной безопасности можно разделить на четыре категории.

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

- создание здорового социального климата в организации;

- снижение нагрузки на персонал и развитие системы восстановления работоспособности сотрудников;

- разработка системы наказания за различные нарушения, в том числе за нарушение режима информационной безопасности. Информирование всех о применяемых наказаниях;

- ограничение знания сотрудников только областью их непосредственных обязанностей;

- контроль и анализ нетипичных действий сотрудников и сторонних лиц (партнеров, клиентов);

- четкая система обучения.

2. Установка систем защиты. Данные средства основываются на программно-аппаратных решениях. Обычно они предлагаются сторонними организациями и за определенную плату или бесплатно доступны для каждой организации. К техническим средствам защиты относятся:

- шифрование;

- электронные подписи и электронная аутентификация;

- развитие системы доступа к данным;

- система защиты программных ресурсов;

- система защиты аппаратных ресурсов;

- физическое ограничение доступа к аппаратным ресурсам системы.

3. Компенсационные меры направлены на ограничение последствий нарушений в системе. К ним относятся следующие решения:

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

- страхование рисков;

- создание резервных систем;

- моделирование нарушений;

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

4. Мониторинг нарушений. Цель мониторинга - распознавание нарушений в информационных системах, а именно:

- аудит информационной системы;

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

- система контрольных метрик.

Управление рисками

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

Основные этапы управления рисками:

* инициирование и планирование;

* сбор информации о существующих процедурах ИБ и внутреннего контроля;

* идентификация потенциальных угроз;

* оценка вероятности их наступления и возможных последствий;

* составление и обновление карты рисков;

* разработка дополнительных мер информационной безопасности и контрольных процедур;

* подготовка отчетов для руководства;

* контроль внедренных процедур.

В данной главе риск рассматривается как среднестатистическая сумма ущерба от негативного события, произведение вероятности события на сумму ущерба:

риск = вероятность х среднестатистическая сумма ущерба.

Очевидно, что каждая из составляющих носит приблизительный характер. Это объясняется отсутствием не только детальной статистики, но даже единой методики получения этих значений. Однако анализ уже имеющихся данных позволяет выявить некоторые зависимости для проведения корректировок в политике. Рассмотрим более детально обе составляющие этого выражения.

Под вероятностью нарушения системы безопасности подразумевается среднее количество подобных событий за определенный период времени.

Оценивая вероятность, необходимо учитывать, что:

1) часть нарушений непосредственно связана с каким-либо событием. Так, ошибки ввода информации пользователями связаны с количеством вводимых документов (рис. 14).

"Рис. 14. Зависимость ошибочных действий от объема операций"

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

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

3) вероятность технического сбоя в дублируемой системе, имеющей модульную структуру, равна:

вероятность = SUMi (V2i х Тi),

где Vi - вероятность сбоя i-го модуля;

Тi - время устранения неисправности для данного модуля;

4) вероятность несанкционированного доступа к копируемым данным равна сумме вероятностей несанкционированного доступа к каждой копии;

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

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

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

Таблица 12

Зависимость алгоритма расчета ожидаемого ущерба от типа нарушения

┌──────────────────────┬─────────────────────────────────────────────┬─────────────────────────────┐

│ Тип нарушения │ Ущерб от нарушения │ Стоимость восстановительных │

│ │ │ работ │

├──────────────────────┼─────────────────────────────────────────────┼─────────────────────────────┤

│Нарушение │Обычно разовый. Реже зависит от времени. Для│Нет, так как не приводит к│

│конфиденциальности │анализа можно использовать формулу │изменениям системы │

│ │S = S1 + дельтаS х T, │ │

│ │где S1 - стоимость информации; │ │

│ │дельтаS - стоимость обновления; │ │

│ │Т - период утечки данных │ │

│Изменения в│Зависит от частоты обращения к измененной│Стоимость восстановительных│

│системе, включая│области. Если данная область является│работ здесь зависит от двух│

│технические сбои и│ключевой в системе, то зависит от времени│составляющих: S = S1 х T +│

│умышленные действия │устранения данного нарушения. Аналитической│S2, где S1 - стоимость поиска│

│ │формулой оценки здесь является следующее│неисправности; │

│ │выражение: │Т - время поиска│

│ │S = суммаi (S1i + Se x T1i + Sp (T2i + T3i), │неисправности; │

│ │где S1i - разовый ущерб для каждого случая; │S2 - стоимость устранения │

│ │Se - стоимость эксплуатации с неисправной│ │

│ │системой; │ │

│ │Т1i - время обнаружения факта нарушения,│ │

│ │может меняться от случая к случаю; │ │

│ │Sp(t) - ущерб от простоя системы связанный с│ │

│ │устранением последствий. Данная функция часто│ │

│ │носит ступенчатый характер; │ │

│ │T2i - время диагностики; │ │

│ │T3i - время устранения неисправности │ │

└──────────────────────┴─────────────────────────────────────────────┴─────────────────────────────┘

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

Влияние систем защиты на развитие бизнеса

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

Следуя общему правилу экономической целесообразности, определяется следующее выражение:

(S(T) - S) x T + 1%(Т) > (S1 x (%)t + Sa x Т)/К,

где S(T) - функция ожидаемого дохода от нового продукта, зависит от времени;

S - сумма требуемого дохода от рассматриваемого продукта;

Т - рассматриваемый промежуток времени;

1%(Т) - получаемая прибыль за счет вторичного использования средств, полученных в качестве дохода от рассматриваемого продукта;

S1 - разовая инвестиция в систему информационной безопасности;

(%)t - потерянная прибыль от использования вложенных средств;

Sa - затраты на сопровождение;

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

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

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

* стандартизация решений, что также позволит снизить стоимость сопровождения и обеспечения информационной безопасности;

* снижение требуемого уровня рентабельности новой услуги;

* применение решений, проверенных в других организациях.

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

Аудит информационных систем

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

Цели и задачи аудита ИС

Целью ИТ-аудита является совершенствование системы контроля за ИТ. Для этого аудиторы выполняют следующие задачи:

- осуществляют оценку рисков ИТ;

- содействуют предотвращению и смягчению сбоев ИС;

- участвуют в управлении рисками ИТ, в том числе в ведении карты рисков;

- помогают подготавливать нормативные документы;

- пропагандируют высокую роль ИТ для бизнеса;

- помогают связать бизнес-риски и средства автоматизированного контроля;

- осуществляют проведение периодических проверок;

- содействуют ИТ-менеджерам в правильной организации управления ИТ;

- осуществляют "взгляд со стороны".

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

Регулирование аудита информационных систем

Вопросу аудита и внутреннего контроля за информационными системами посвящены несколько зарубежных стандартов аудита и специальный российский стандарт "Аудит в условиях компьютерной обработки данных (КОД)". Из зарубежных источников можно отметить международный стандарт аудита ISA 401, положения по международной практике аудита 1002, 1003, 1004, 1008, 1009. В них отражены вопросы практики аудита в среде компьютерных информационных систем, оценки рисков и надежности системы внутреннего контроля в условиях КОД, техника проведения аудита с учетом использования современных информационных технологий.

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

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

Технология аудита информационных систем

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

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

С точки зрения технического обеспечения необходимо постоянно отслеживать следующие моменты:

* отказоустойчивость технической базы, под которой понимают способность технических средств функционировать практически без сбоев и остановок;

* степень надежности хранения данных и возможности их восстановления, включая средства резервного копирования;

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

* масштабируемость компьютерных систем, которая состоит в возможности их наращивания и является залогом их более длительного использования;

* достаточность вычислительной мощности технических средств для обработки данных в организации;

* соответствие технической политики бизнес-задачам организации и ее экономическая эффективность.

В части контроля за программным обеспечением регулярной проверке подлежат:

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

- логическое разграничение прав доступа к данным на системном и прикладном уровнях, в том числе политика информационной безопасности и ее выполнение, что предотвращает несанкционированные действия и ограничивает доступ к конфиденциальной информации;

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

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

- надежность системного программного обеспечения и используемой СУБД (системы управления базой данных), которые так же, как и технические средства, являются повышенным источником риска;

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

- наличие верификации прав доступа (подтверждения одним пользователем действий другого) и последующего контроля за данными в информационных системах;

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

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

Направления проверки технологии организации и использования компьютерной обработки данных достаточно разнообразны:

* общая структура служб ИТ и ее соответствие поставленным задачам;

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

* регламентация действий пользователей информационных систем как часть обязательного и с точки зрения общего управления, и с точки зрения управления качеством регламентирования всех внутренних банковских процессов;

* оценка системы поддержки (сопровождения) пользователей, так как при некачественном сопровождении повышается риск неправильных, ошибочных действий вследствие непонимания особенностей информационных систем;

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

* технологии проведения отдельных операций с точки зрения их соответствия регламентам, политике информационной безопасности, удобства и эффективности их автоматизации;

* технология работы с особо критичными системами и их участками, прежде всего такими, как платежные терминалы и системы передачи данных между различными программными комплексами;

* наличие системы обеспечения деятельности при возникновении чрезвычайных ситуаций, а именно плана действий резервной вычислительной площадки и возможности быстрого восстановления данных.

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

Нами были приведены общая схема описанных областей, их составляющие и система взаимодействия, которая в методологии СоblТ называется "золотое правило".

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

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

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

Примеры выявленных проблем

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

Таблица 13

Отчет по результатам аудита информационных систем банка

┌─────────────────────┬────────────────────────┬────────────────────────────────────────────────┬──────────┐

│ Ситуация │ Риск │ Рекомендация │ Приоритет│

├─────────────────────┼────────────────────────┼────────────────────────────────────────────────┼──────────┤

│ 1 │ 2 │ 3 │ 4 │

│Стратегия ИТ│Подобная ситуация может│Мы рекомендуем банку: передать функцию│ !!! │

│существует, однако ее│привести к│стратегического планирования в области ИТ│ │

│основные направления│несоответствию целей и│высшему руководству банка; │ │

│не доведены до│задач ИТ│распределить обязанности по стратегическому│ │

│сведения многих│бизнес-стратегии, что в│планированию в области ИТ; │ │

│работников банка и│свою очередь может│формализовать и задокументировать стратегический│ │

│руководителей │привести к│план в области ИТ, включая определение│ │

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

│подразделений │использованию бюджета ИТ│технологических решений и текущей│ │

│ │и повышенным затратам │инфраструктуры, оценку требуемых организационных│ │

│ │ │изменений и существующих систем, направления│ │

│ │ │развития ИТ на срок от 3 до 5 лет; │ │

│ │ │разработать и внедрить процедуры оценки рисков│ │

│ │ │ИТ как часть системы корректировки стратегии в│ │

│ │ │области ИТ; │ │

│ │ │объединить стратегическое планирование в области│ │

│ │ │ИТ с функцией бизнес-планирования; распределить│ │

│ │ │ответственность за распространение информации о│ │

│ │ │стратегии ИТ по всем функциональным│ │

│ │ │подразделениям банка │ │

│Низкий уровень│Отсутствие регламентов и│Мы рекомендуем разработать и утвердить процедуры│ !! │

│документирования │документирования │документирования для основных технических и│ │

│ключевых процессов в│ИТ-процедур повышает│операционных процессов в области ИТ и│ │

│области ИТ. В ходе│уровень операционных и│осуществлять регулярный контроль за выполнением│ │

│обследования мы│системных рисков банка.│этих процедур со стороны руководства банка.│ │

│отметили, что│Также при этой ситуации│Необходимо разработать процедуры, которые│ │

│отсутствуют │затруднен контроль за│обеспечат возможность последующего контроля за│ │

│внутренние регламенты│функционированием ИТ и│соблюдением указанных процессов и стандартов ИТ │ │

│и документирование│их эффективностью.│ │ │

│большинства │Помимо этого, отсутствие│ │ │

│направлений │надлежащей документации│ │ │

│деятельности ИТ-служб│повышает риск│ │ │

│ │зависимости от ключевых│ │ │

│ │сотрудников службы ИТ,│ │ │

│ │их опыта и знаний │ │ │

│Отсутствие системы│Неадекватная │Мы рекомендуем внедрить систему анализа│ !! │

│анализа инвестиций в│инвестиционная политика│инвестиций в ИТ. Мы полагаем, что политика│ │

│ИТ. В ходе обзора мы│резко увеличивает риски│инвестиций в области ИТ должна включать│ │

│отметили, что процесс│дефицита бюджета,│следующие пункты: определение ответственных за│ │

│бюджетного │конфликта ресурсов│этот процесс сотрудников банка; │ │

│планирования, в том│/инвестиций, а также│систему показателей и алгоритм расчета│ │

│числе и для ИТ,│риск низкой окупаемости│инвестиций в области ИТ; │ │

│ведется на регулярной│инвестиций в области ИТ.│расчет инвестиционной политики в области ИТ и│ │

│основе. Однако в│Возможно неэффективное│окупаемости инвестиций с финансовой и│ │

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

│процедуры оценки│банка. В случае│альтернативных вариантов инвестиций в ИТ; │ │

│эффективности │отсутствия │анализ передового опыта отрасли при выборе│ │

│вложений в ИТ,│предварительного │инвестиций в области ИТ; │ │

│практика отношения к│планирования в области│постоянный процесс совершенствования│ │

│расходам на ИТ как к│инвестиций в ИТ высшее│инвестиционной политики в области ИТ. │ │

│внутренним │руководство может│Как дополнительные моменты и показатели, которые│ │

│инвестициям │недооценить их│необходимо учитывать при осуществлении│ │

│ │значимость для│инвестиционной политики, мы рекомендуем│ │

│ │деятельности банка и│анализировать следующие параметры: процент│ │

│ │принимать управленческие│ИТ-проектов (от общего числа), не укладывающихся│ │

│ │решения, не владея│в бюджет; │ │

│ │реальной информацией об│процент ИТ-проектов, для которых не│ │

│ │отдаче от ИТ │производилась предварительная оценка│ │

│ │ │эффективности инвестиций; процент ИТ-проектов,│ │

│ │ │которые после внедрения не достигли требуемых│ │

│ │ │инвестиционных показателей (нормы рентабельности│ │

│ │ │и времени самоокупаемости); число ИТ-проектов,│ │

│ │ │при осуществлении которых, несмотря на наличие│ │

│ │ │утвержденного бюджета, возникли инвестиционные│ │

│ │ │конфликты (недостаток или несвоевременность│ │

│ │ │инвестиций); │ │

│ │ │время между возникновением отклонения в│ │

│ │ │осуществлении проекта и решением этой проблемы│ │

│ │ │руководством; процент ИТ-проектов, которые после│ │

│ │ │внедрения так и не достигли требуемых│ │

│ │ │бизнес-целей │ │

│Отсутствие │Отсутствие системы│Мы рекомендуем следующие мероприятия:│ !!! │

│риск-менеджмента в│управления рисками ИТ│сформировать функцию управления рисками внутри│ │

│области ИТ. Анализ│может привести к│подразделения ИТ; │ │

│рисков в сфере ИТ│увеличению числа│распределить, задокументировать и утвердить на│ │

│осуществляется только│проектов, незаконченных│уровне высшего руководства систему│ │

│в отдельных, наиболее│вовремя или вышедших за│ответственности и процедуры риск-менеджмента; │ │

│критичных, случаях на│рамки бюджета. Это также│разработать систему классификации и оценки│ │

│нерегулярной основе.│приводит к увеличению│рисков ИС; │ │

│При этом не│количества нештатных│анализировать результаты ИТ-проектов в ходе и│ │

│существует │ситуаций и сбоев в│после их завершения с точки зрения управления│ │

│методологии оценки и│работе информационных│рисками; │ │

│управления рисками и│систем. Неадекватное│сформировать системы превентивных мер,│ │

│утвержденных │управление рисками может│направленных на предотвращение и снижение рисков│ │

│внутренних процедур│подорвать финансовое и│ │ │

│на этот счет │стратегическое положение│ │ │

│ │банка │ │ │

│В банке отсутствует│Низкий уровень│Создание комитета по ИТ или│ !! │

│информационно-техно- │информирования высшего│информационно-технологического комитета при│ │

│логический комитет│руководства о проблемах│правлении поможет оптимизировать работу│ │

│при правлении │в области ИТ; проблемы│подразделения ИТ и упростит процесс│ │

│ │решаются недостаточно│урегулирования проблем, с которыми сталкивается│ │

│ │оперативно. │подразделение ИТ. Комитет по ИТ должен│ │

│ │Неэффективная система│оперативно решать стратегические задачи в│ │

│ │контроля за ИТ повышает│области ИТ, а также обеспечивать получение│ │

│ │внутренние риски │своевременной ответной реакции (обратную связь).│ │

│ │ │Кроме этого, комитет по ИТ будет способствовать│ │

│ │ │повышению эффективности контроля за│ │

│ │ │деятельностью ИТ-служб │ │

│Неэффективное │Низкое качество│Необходимо разработать четкую процедуру,│ ! │

│построение │обслуживания │регламентирующую права и обязанности│ │

│обслуживания │пользователей, │пользователей и сотрудников ИТ. Мы рекомендуем│ │

│пользователей ИС. Мы│неоперативность решения│разработать базу данных службы технической│ │

│отметили, что│проблем и ликвидации│поддержки с тем, чтобы все заявки пользователей│ │

│отсутствуют │сбоев в информационных│регистрировались сотрудниками ИТ. Этот│ │

│внутренние │системах. В результате│внутренний инструмент позволит оптимизировать│ │

│регламенты, │повышается риск сбоя│деятельность специалистов ИТ и проводить│ │

│регулирующие │систем, который может│мониторинг их работы. Кроме того, база данных│ │

│отношения │привести к потере│обеспечит аналитическую информацию об уровне│ │

│пользователей и│информации. Отсутствие│компьютерной подготовки пользователей, наиболее│ │

│сотрудников ИТ. В│статистических данных по│типичных проблемах, а также позволит определить│ │

│банке отсутствует│типам и количеству│те области в организации ИТ и информационных│ │

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

│поддержки в форме│принятие управленческих│ │ │

│help-desk с│решений. Нет возможности│ │ │

│обязательной │контролировать и│ │ │

│регистрацией всех│координировать работу│ │ │

│обращений и четкими│службы технической│ │ │

│стандартами на время│поддержки │ │ │

│и качество обработки│ │ │ │

│запросов │ │ │ │

│пользователей. В│ │ │ │

│настоящее время│ │ │ │

│заявки пользователей│ │ │ │

│не регистрируются и│ │ │ │

│не анализируются.│ │ │ │

│Соответственно не│ │ │ │

│осуществляется │ │ │ │

│официальный │ │ │ │

│мониторинг объема│ │ │ │

│работы и видов│ │ │ │

│проблем, с которыми│ │ │ │

│сталкиваются │ │ │ │

│специалисты ИТ │ │ │ │

│Отсутствие члена│Затруднения при│Возложение ответственности за ИТ на члена│ !! │

│правления банка,│оперативном решении│правления банка будет способствовать оптимизации│ │

│курирующего ИТ │проблем ИТ, низкий│процесса решения проблем и повышению│ │

│ │уровень информирования│эффективности деятельности подразделения ИТ │ │

│ │правления о проблемах в│ │ │

│ │области ИТ │ │ │

│Политика │Конфиденциальность и│Мы рекомендуем обновить и детализировать│ !! │

│информационной │стабильность │официальное положение по информационной│ │

│безопасности банка│информационных систем│безопасности. За основу может быть взята│ │

│недостаточно детальна│имеет большое значение│следующая структура этого документа. │ │

│ │для деятельности банка.│Часть 1. Управление информационной│ │

│ │Неадекватное управление│безопасностью. │ │

│ │информационной │1.1. Введение. │ │

│ │безопасностью может│1.2. Обязанности руководства и сотрудников. │ │

│ │привести к финансовым│1.3. Ключевые позиции. │ │

│ │потерям и раскрытию│1.4. Основные требования к пользователям ИС. │ │

│ │конфиденциальной │1.5. Классификация и анализ рисков. │ │

│ │информации │1.6. Классификация информации. │ │

│ │ │1.7. Использование сетевого и│ │

│ │ │телекоммуникационного оборудования. │ │

│ │ │1.8. Правила резервирования данных. │ │

│ │ │1.9. Поддержка информационной безопасности.│ │

│ │ │Часть 2. Стандарты информационной защиты. │ │

│ │ │2.1. Аппаратная защита. │ │

│ │ │2.2. Защита от несанкционированных действий. │ │

│ │ │2.3. Программная защита. │ │

│ │ │2.4. Защита локальной вычислительной сети. │ │

│ │ │2.5. Стандарты информационной безопасности при│ │

│ │ │разработке и модернизации программ. │ │

│ │ │2.6. Информационная защита серверов и│ │

│ │ │автоматизированных рабочих мест. │ │

│ │ │2.7. Взаимодействие с третьими лицами. │ │

│ │ │2.8. Хранение данных │ │

│Требования временного│Отсутствие сотрудника,│Мы рекомендуем назначить администратора по│ !! │

│положения по│постоянно │безопасности в соответствии с существующими│ │

│управлению доступом│контролирующего │требованиями и провести внутреннюю проверку│ │

│не выполняются.│информационную │соблюдения корпоративных норм информационной│ │

│Некоторые требования│безопасность, может│безопасности │ │

│временного положения│привести к несоблюдению│ │ │

│банка об управлении│внутренних норм в этой│ │ │

│доступом │области и, как│ │ │

│пользователей │следствие, к увеличению│ │ │

│нарушаются. В│риска │ │ │

│частности, внутренним│несанкционированных │ │ │

│положением банка│действий с информацией │ │ │

│введена позиция│ │ │ │

│администратора банка,│ │ │ │

│однако сотрудника,│ │ │ │

│выполняющего эти│ │ │ │

│функции, в банке нет.│ │ │ │

│Также нарушается ряд│ │ │ │

│положений, │ │ │ │

│ограничивающих доступ│ │ │ │

│к наиболее критичным│ │ │ │

│информационным │ │ │ │

│ресурсам │ │ │ │

│Отсутствие │Неадекватный контроль за│Мы рекомендуем внедрить и использовать│ !!! │

│внутреннего аудита│ИТ повышает риск сбоя в│эффективную систему внутреннего контроля при│ │

│информационных систем│работе ИТ. Отсутствие│обработке данных. По нашему мнению, банку│ │

│ │функции аудита ИС может│следует предпринять следующие шаги: разработать│ │

│ │привести к неточному и│письменное руководство по проведению аудита ИС; │ │

│ │ненадежному процессу│назначить внутренних аудиторов; правление должно│ │

│ │обработки данных, а│регулярно анализировать и подтверждать│ │

│ │также снизить│квалификацию и независимость аудиторов;│ │

│ │информационную │определить объем и частоту проведения│ │

│ │безопасность │аудиторских проверок, а также методики│ │

│ │ │проведения аудита; разработать план действий│ │

│ │ │руководства для устранения существенных│ │

│ │ │недостатков, отмеченных в отчетах аудиторов. │ │

│ │ │Мы рекомендуем проводить внешние независимые│ │

│ │ │аудиторские проверки ИС по крайней мере раз в│ │

│ │ │два года, даже если в банке регулярно проводится│ │

│ │ │внутренний аудит │ │

│Большое количество│Применение различных│Мы рекомендуем рассмотреть возможность│ ! │

│используемых │платформ может привести│сокращения количества используемых платформ. По│ │

│технологических │к проблемам при│нашему мнению, было бы целесообразно отказаться│ │

│платформ. В ходе│интеграции данных, а│от использования, например, платформы Windows NT│ │

│проверки мы отметили,│также существенно│ │ │

│что банк применяет│усложняет их│ │ │

│различные платформы,│обслуживание и│ │ │

│включая Windows NT,│поддержку. Кроме того,│ │ │

│Novell NetWare и│обслуживание данных│ │ │

│Unix. Windows NT│платформ сопряжено с│ │ │

│используется для│существенными затратами,│ │ │

│некоторых специальных│которые могут быть│ │ │

│задач, например для│снижены при│ │ │

│обеспечения услуг│использовании меньшего│ │ │

│внутренней почты.│количества разнородных│ │ │

│Novell NetWare│платформ │ │ │

│используется как│ │ │ │

│файловый сервер, a│ │ │ │

│Unix - для АБС XXX │ │ │ │

│Отсутствие │Обслуживание базы данных│Мы рекомендуем назначить сертифицированного│ !! │

│сертифицированного │Oracle требует наличия│администратора базы данных Oracle (DBA) или│ │

│администратора базы│определенных навыков и│организовать специальное обучение│ │

│данных. Мы отметили,│опыта. Неадекватное│администраторов Oracle, работающих в настоящее│ │

│что в банке│обслуживание базы данных│время в банке │ │

│отсутствует │Oracle может привести к│ │ │

│сертифицированный │замедлению или даже сбою│ │ │

│администратор базы│в работе этой базы│ │ │

│данных Oracle │данных │ │ │

│Использование │Дальнейшие разработки в│Банку следует рассмотреть возможность замены│ !!! │

│неподдерживаемого │системе SWIFT не будут│программного обеспечения, обеспечивающего│ │

│разработчиком ПО.│поддерживаться │интерфейс с системой SWIFT │ │

│Установленное │существующим интерфейсом│ │ │

│программное │SWIFT │ │ │

│обеспечение для SWIFT│ │ │ │

│не поддерживается│ │ │ │

│разработчиком (MERVA)│ │ │ │

│Файлы аудита действий│Несанкционированные │Файлы аудита действий пользователей в ЛВС│ !! │

│пользователей ЛВС не│действия, которые│(лог-файлы) должны быть активизированы в│ │

│анализируются. Работа│потенциально могут быть│операционных системах - Windows NT, Novell│ │

│сотрудников и внешних│осуществлены │NetWare и Unix. Сотрудники службы ИТ или│ │

│консультантов в│пользователями, не будут│информационной безопасности должны иметь доступ│ │

│локальной │вовремя выявлены │к данным файлам и регулярно анализировать их в│ │

│вычислительной сети│ │целях контроля за действиями персонала. Также│ │

│контролируется при│ │можно рекомендовать использование специальных│ │

│помощи файлов аудита│ │программ для анализа и эффективного мониторинга│ │

│(лог-файлов), с│ │действий пользователей. В ходе процесса│ │

│помощью которых│ │резервирования необходимо также периодически│ │

│возможно │ │создавать резервные копии лог-файлов │ │

│протоколирование всех│ │ │ │

│действий │ │ │ │

│пользователей. Однако│ │ │ │

│сотрудники ИТ не│ │ │ │

│имеют возможности│ │ │ │

│регулярно │ │ │ │

│анализировать │ │ │ │

│информацию о работе│ │ │ │

│пользователей, в│ │ │ │

│основном из-за│ │ │ │

│нехватки кадровых│ │ │ │

│ресурсов │ │ │ │

│Передача │Передача информации│Для защиты информации при передаче по внешним│ !!! │

│конфиденциальных │через открытые каналы│каналам связи необходимо применять│ │

│данных по открытым│повышает риск│соответствующие процедуры криптографической│ │

│каналам. В настоящее│несанкционированного │защиты на всех внешних каналах │ │

│время банк, его│доступа, модификации,│ │ │

│филиалы и внешние│раскрытия или потери│ │ │

│организации │информации │ │ │

│обмениваются │ │ │ │

│информацией через│ │ │ │

│открытые каналы, не│ │ │ │

│защищенные │ │ │ │

│криптографическими │ │ │ │

│механизмами │ │ │ │

│Доступ к директории│Данный факт повышает│Мы рекомендуем банку ограничить существующие│ !! │

│платежей. В ходе│риск │права доступа к критичным сетевым директориям.│ │

│нашего обзора мы│несанкционированного │Права доступа к директории, предназначенной для│ │

│отметили, что четыре│доступа к платежной│отправки платежей в ЦБ РФ, должны быть│ │

│сотрудника расчетного│системе и мошенничества│предоставлены только тем сотрудникам, которые│ │

│отдела имеют доступ к│при осуществлении│работают с указанной директорией в ходе│ │

│директории платежей│платежных операций банка│выполнения возложенных на них функций.│ │

│ЦБ РФ. Кроме того, к│ │Сотрудники ИТ должны быть лишены права доступа к│ │

│указанной директории│ │данной директории │ │

│имеют доступ│ │ │ │

│некоторые сотрудники│ │ │ │

│подразделения ИТ │ │ │ │

│Недостаточная длина│Пароли с│Банку необходимо провести проверку соблюдения│ !!! │

│паролей. Мы отметили,│несоответствующей длиной│парольной политики и не допускать использования│ │

│что некоторые│повышают риск│паролей менее чем из 6 символов │ │

│сотрудники ИТ не│несанкционированного │ │ │

│выполняют заявленных│доступа к базе данных,│ │ │

│внутренними │что в свою очередь может│ │ │

│регламентами │привести к│ │ │

│требований к│несанкционированному │ │ │

│количеству символов│раскрытию или изменению│ │ │

│пароля к ИС. Один из│информации │ │ │

│сотрудников службы ИТ│ │ │ │

│использует пароль для│ │ │ │

│системы "Новая│ │ │ │

│Афина", состоящий из│ │ │ │

│3 символов. При этом│ │ │ │

│он имеет полный│ │ │ │

│доступ к базе данных │ │ │ │

│Доступ в серверную│Повышается риск│Серверная комната должна закрываться при помощи│ !! │

│комнату не ограничен│несанкционированного │электронного замка. Следует рассмотреть│ │

│как следует. Серверы│доступа к критичному│возможность установки системы видеонаблюдения │ │

│расположены в│компьютерному │ │ │

│комнате, которая│оборудованию │ │ │

│запирается на│ │ │ │

│стандартный замок.│ │ │ │

│Как правило, дверь│ │ │ │

│серверной комнаты не│ │ │ │

│закрывается. │ │ │ │

│Существует свободный│ │ │ │

│доступ к компьютерам│ │ │ │

│и ключевым системам │ │ │ │

│Физический доступ к│Данная ситуация повышает│Необходимо ограничить физический доступ к│ !!! │

│платежным терминалам│риск │указанным терминалам исключительно│ │

│SWIFT и рублевых│несанкционированного │уполномоченным сотрудникам. Терминалы SWIFT и│ │

│платежей не│доступа к функции│терминал рублевых платежей должны быть│ │

│ограничен. Данные│внешних платежей и│расположены в отдельной комнате. Следует│ │

│терминалы расположены│повышает возможность│рассмотреть возможность установки системы│ │

│в большом зале,│несанкционированных │видеонаблюдения за терминалами │ │

│доступ в который│переводов денежных│ │ │

│практически не│средств от имени банка │ │ │

│ограничен. В зале,│ │ │ │

│где расположены│ │ │ │

│терминалы, │ │ │ │

│функционируют четыре│ │ │ │

│различных │ │ │ │

│подразделения, │ │ │ │

│которые не имеют│ │ │ │

│отношения к указанным│ │ │ │

│терминалам. Кроме│ │ │ │

│того, там же│ │ │ │

│находится ксерокс,│ │ │ │

│используемый │ │ │ │

│сотрудниками банка, и│ │ │ │

│производится │ │ │ │

│обслуживание клиентов│ │ │ │

│Хранение ключевых│Повышается риск│Ключевая дискета должна храниться в сейфе │ !!! │

│дискет не│несанкционированного │ │ │

│соответствует │доступа к платежным│ │ │

│требованиям. В ходе│терминалам │ │ │

│обзора мы отметили,│ │ │ │

│что ключевая дискета│ │ │ │

│программы отправки│ │ │ │

│рублевых платежей│ │ │ │

│"Конва" не хранится в│ │ │ │

│сейфе, как того│ │ │ │

│требуют внутренние│ │ │ │

│положения банка и│ │ │ │

│инструкции ЦБ РФ │ │ │ │

│В банке отсутствует│Компьютерные системы│Мы рекомендуем провести анализ возможных рисков│ !! │

│план действий на│банка являются важным│деятельности банка, определить наиболее│ │

│случай чрезвычайной│компонентом в его│критичные сферы деятельности и подготовить общий│ │

│ситуации. В настоящее│успешной операционной│порядок действий сотрудников банка при│ │

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

│разработан ряд│произойдет │порядок действий должен предусматривать четкое│ │

│отдельных мер по│продолжительный сбой в│распределение ответственности между│ │

│восстановлению данных│компьютерных системах│специалистами банка по восстановлению│ │

│и замене оборудования│банка, это может│работоспособности системы, примерный перечень│ │

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

│из строя. Однако на│негативным образом на│ситуации, а также масштаб возможных потерь для│ │

│сегодняшний момент не│его деятельности и│деятельности банка. │ │

│существует плана│привести к│Разработанный документ должен быть утвержден│ │

│восстановления │дополнительным потерям │руководством банка и доведен до сведения всех│ │

│компьютерных систем в│ │ответственных специалистов │ │

│случае чрезвычайных│ │ │ │

│ситуаций │ │ │ │

│Отсутствие стороннего│Ввиду того, что все│Мы рекомендуем хранить резервные копии за│ ! │

│хранения резервных│резервные файлы хранятся│пределами здания │ │

│копий данных. В банке│в одном и том же здании,│ │ │

│внедрены процедуры│аварийная ситуация,│ │ │

│создания резервных│например пожар в здании,│ │ │

│файлов. Однако все│может полностью│ │ │

│резервные копии│уничтожить критичную│ │ │

│хранятся в этом же│информацию. В результате│ │ │

│здании │этого банку, возможно,│ │ │

│ │придется приостановить│ │ │

│ │свои операции │ │ │

│Серверная комната не│Риск повреждения или│Мы рекомендуем банку предпринять следующие шаги:│ ! │

│оборудована │выхода из строя│разработать и протестировать план тушения пожара│ │

│противопожарной │ключевого оборудования в│и эвакуации ключевого оборудования; обеспечить│ │

│газовой системой │случае пожара возрастает│наличие газовых огнетушителей в серверных│ │

│ │ │комнатах │ │

│В используемом банком│Отсутствие процедуры│Мы рекомендуем внедрить процедуру верификации│ !!! │

│программном │верификации может│валютных платежей, а также систему их│ │

│обеспечении │привести к│последующего контроля │ │

│отсутствует процедура│непреднамеренным ошибкам│ │ │

│верификации │или мошенничеству │ │ │

│международных │ │ │ │

│переводов. Все вводы│ │ │ │

│данных для платежей в│ │ │ │

│иностранной валюте│ │ │ │

│осуществляются одним│ │ │ │

│исполнителем │ │ │ │

└─────────────────────┴────────────────────────┴────────────────────────────────────────────────┴──────────┘

Управление ИТ-персоналом

Особенности управления ИТ-персоналом

Элементы системы управления персоналом

Рассмотрим основные элементы системы управления персоналом. К ним можно отнести:

Типовые роли

Каковы типовые роли и специализации ИТ-работников? Можно выделить следующие основные группы.

Риски персонала и совмещение

Таблица 6

Возможность совмещения участков работ*(5)

│ │ ные │ ные │ровщики│ нители │ ные │ раторы │ раторы │ леры │ по │ по │поддержки│технологи │

│ │аналити-│програм- │ │программ│програм-│ данных │безопасно-│качества│компью- │ телеком- │ │ │

│ │ ки │ мисты │ │ │ мисты │ │ сти │ │ терам │муникациям│ │ │

│ │ 1 │ 2 │ 3 │ 4 │ 5 │ 6 │ 7 │ 8 │ 9 │ 10 │ 11 │ 12 │

│ Системные │ │ │ │ X │ X │ │ X │ X │ │ │ │ │

│ аналитики │ │ │ │ │ │ │ │ │ │ │ │ │

│ Прикладные │ │ │ X │ X │ X │ X │ X │ X │ │ X │ X │ │

│программисты│ │ │ │ │ │ │ │ │ │ │ │ │

│Тестировщики│ │ X │ │ │ X │ X │ X │ │ │ │ X │ X │

│ Хранители │ X │ X │ │ │ X │ │ X │ │ │ │ │ X │

│ программ │ │ │ │ │ │ │ │ │ │ │ │ │

│ Системные │ X │ X │ X │ X │ X │ X │ X │ │ X │ X │ X │ X │

│программисты│ │ │ │ │ │ │ │ │ │ │ │ │

│Администра- │ │ X │ X │ │ X │ │ │ │ │ │ │ │

│торы данных │ │ │ │ │ │ │ │ │ │ │ │ │

│Администра- │ X │ X │ X │ X │ X │ │ │ │ X │ X │ X │ X │

│ торы │ │ │ │ │ │ │ │ │ │ │ │ │

│безопасности│ │ │ │ │ │ │ │ │ │ │ │ │

│ Контролеры │ X │ X │ │ │ │ │ │ │ X │ X │ │ X │

│ качества │ │ │ │ │ │ │ │ │ │ │ │ │

│Инженеры по │ │ │ │ │ X │ │ X │ X │ │ │ │ X │

│компьютерам │ │ │ │ │ │ │ │ │ │ │ │ │

│Инженеры по │ │ X │ │ │ X │ │ X │ X │ │ │ │ X │

│телекоммуни-│ │ │ │ │ │ │ │ │ │ │ │ │

│ кациям │ │ │ │ │ │ │ │ │ │ │ │ │

│ Эксперты │ │ X │ X │ │ X │ │ X │ │ │ │ │ X │

│ поддержки │ │ │ │ │ │ │ │ │ │ │ │ │

│ Банковские │ │ │ X │ X │ X │ │ X │ X │ X │ X │ X │ │

│ технологи │ │ │ │ │ │ │ │ │ │ │ │ │

Мотивация и стимулирование

1. Анализ сложившейся системы внутренних взаимоотношений сотрудников и их трудовой мотивации.

2. Разработка общих принципов мотивации сотрудников и системы оплаты и стимулирования.

Поощрения за сокращение издержек при выполнении работы.

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

Обучение и сертификация

- внешнее обучение ИТ-сотрудников;

- специализированное внутреннее обучение ИТ-сотрудников;

- привлечение высококвалифицированных специалистов;

- внутренняя миграция кадров;

- сертификация ИТ-специалистов;

- обучение пользователей.

Внешнее обучение

* слабость материально-технической базы для подготовки специалистов;

* длительность процесса обучения и, как следствие, его неудобство для работающих специалистов.

К положительным аспектам обучения на базе высших учебных заведений следует отнести:

* комплексный, многосторонний характер обучения;

* возможность получения фундаментальных базовых знаний.

Внутреннее обучение

Привлечение специалистов

Внутренняя миграция кадров

Сертификация специалистов

* процесс аудита информационных систем;

* планирование, организация и управление ИТ;

* техническая инфраструктура и операционная практика;

* защита информационных активов;

* планирование действий на случай чрезвычайных ситуаций и сбоев;

* разработка, приобретение, внедрение и поддержка информационных систем;

* оценка бизнес-процессов и управление рисками.

Обучение пользователей

Обслуживание пользователей

Принципы поддержки пользователей

Итак, какова best practice организации обслуживания и поддержки пользователей?

Технологическая схема работы

"Рис. 11. Схема организации работы службы поддержки пользователей"

Типы запросов и приоритезация

Таблица 7

Пример приоритезации запросов пользователей

│Градация приоритета │ Степень приоритета │ Гарантированное время │

│ │ │ реагирования │

│Высокий - 1 │высокая - система не│менее 1 часа │

│ │работает, пароли,│ │

│ │прочее │ │

│Средний - 2 │средняя - некоторые│в течение 4 часов │

│ │функции не работают │ │

│Низкий - 3 │низкая - общие вопросы,│в течение дня │

│ │не останавливает работу│ │

База данных запросов и автоматизация

* Генерирование отчетов о работе для целей управления и контроля.

Отчетность и контроль

"Рис. 12. Контроль за обслуживанием пользователей"

- стоимость поддержки одного пользователя;

- стоимость поддержки функционального подразделения;

- относительное изменение стоимости поддержки пользователя;

- простой сотрудников службы сопровождения (финансовые потери).

- процент пользователей, довольных службой поддержки;

- оценки работы различных операторов, экспертов;

- относительное изменение суммарной оценки качества сопровождения.

- процент закрытых проблем от общего количества;

- процент проблем, закрытых в заданный срок;

- относительное изменение количества регистрируемых запросов;

- процент проблем, решенных на первом уровне (оператором);

- процент просроченных проблем;

- соотношение между количеством проблем каждого приоритета;

- средний срок решения проблемы;

Управление качеством

Всеобщее управление качеством (TQM)

В основу концепции TQM легли базовые принципы, сформулированные и изложенные Демингом:

* необходимо внедрять новую философию и отношение к окружающим процессам;

* постоянно соотносить качество и удовлетворенность потребителя с ценой;

* вести постоянное обучение, прежде всего на рабочем месте;

* устранять барьеры между подразделениями;

* искоренять страх перед переменами;

* дать возможность всем служащим гордиться принадлежностью к организации;

* всячески поощрять образование и самосовершенствование;

* вовлечь каждого в работу по преобразованию;

* избегать пустых лозунгов;

* организовать руководство таким образом, чтобы его основным предназначением была помощь работникам;

* отказаться от контроля качества только посредством проверок и ревизий;

* стремиться к постоянному улучшению всей системы функционирования организации;

* искоренять "уравниловку" персонала.

Стандарт качества ISO 9000

Разработка - все виды деятельности, выполняемые для создания программного обеспечения.

Предоставление услуги (Service Delivery) - деятельность поставщика, необходимая для обеспечения услуги.

Шаг 1. Определить и поименовать потребность, подлежащую удовлетворению услугой.

Шаг 2. Определить, в какой потенциальной группе клиентов эта потребность существует.

Шаг 3. Описать ту часть услуги (работу, результаты работы и т.д.), которая удовлетворит выявленную потребность.

Существует ли у меня неудовлетворенная потребность из тех, что описаны в рекламных материалах?

Соизмеряется ли стоимость услуг с их качеством?

Действительно ли поставщик способен оказать необходимую услугу?

Насколько выгоднее обратиться к данному поставщику, чем к другим?

Жизненный цикл программного обеспечения

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

- решение проблем;

- модификация интерфейса;

- расширение функций и улучшение эксплуатационных характеристик.

описание типов (или классов) выпусков в зависимости от их частоты и воздействия на деятельность заказчика;

способы уведомления об изменениях;

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

Специализированный стандарт TickIT

Помимо своей основы (стандарта) ISO 9001 TickIT содержит следующие компоненты:

- систему проверок аудиторов Британским компьютерным обществом (BCS) и Институтом по обеспечению качества (IQA);

- систему аккредитации сертификационных обществ - UKAS (Великобритания), SWEDAC (Швеция);

- программы, направленные на расширение признания схемы;

- трехлетний цикл пересмотра схемы;

- систему специальных премий за достижения.

* копированием, архивированием, хранением данных и программным обеспечением;

* системной интеграцией, поддержкой, администрированием и др.

Особенности управления качеством ИТ-услуг

Управление аутсорсингом

Роль аутсорсинга в ИТ

Если говорить о целях, то, как правило, аутсорсинг используется:

* разработку и внедрение больших информационных систем;

* обслуживание и ремонт компьютерной и серверной техники;

* телекоммуникационные услуги;

* поддержку локальных сетей;

* обслуживание телефонного и офисного оборудования;

* развитие информационной безопасности;

* поддержку дорогостоящих с точки зрения ИТ бизнес-процессов (про-цессинг, выпуск пластиковых карт).

Взаимодействие с внешними поставщиками

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

При согласовании цен учитывайте следующее:

- среднерыночная стоимость ИТ-специалиста - $40 в час, а его средняя зарплата - $800-1000 в месяц;

- собственно лицензия для разработчика почти ничего не стоит, все затраты уже сделаны;

Риски аутсорсинга

Теперь рассмотрим некоторые специфические риски аутсорсинга, которые необходимо также учитывать.

Оперативная деятельность

Рассмотрим основные элементы текущей оперативной деятельности ИТ-службы (табл. 8).

Таблица 8

Основные составляющие оперативной деятельности ИТ-службы

│Область оперативной деятельности│ Выполняемые работы │

│Обеспечение работы банковских│Анализ системы, реализация новых│

│информационных систем │требований, анализ производительности,│

│ │обеспечение бесперебойной работы │

│Обеспечение работоспособности│Работа с техническими средствами│

│офисных приложений │конечных пользователей, такими, как│

│ │персональные компьютеры, принтеры,│

│ │сканеры. Поддержка работы с локальными│

│ │приложениями. Консультирование│

│ │пользователей │

│Поддержка технических средств│Обеспечение бесперебойной работы│

│информационной системы │основных серверов организации и│

│ │резервных систем │

│Управление сетями организации │Управление сетями, используемыми для│

│ │передачи данных. Контроль│

│ │производительности и загруженности,│

│ │планирование развития сетей │

│Бесперебойная работа│Анализ, разработка, тестирование и│

│телекоммуникационных средств │установка технических средств│

│ │телекоммуникаций │

│Управление операционными│Администрирование операционных систем,│

│системами │используемых в организации │

│Администрирование баз данных │Поддержка работающих систем управления│

│ │базами данных, включающая в себя│

│ │управление производительностью,│

│ │резервное копирование, устранение│

│ │сбоев в работе. Моделирование и│

│ │разработка корпоративных хранилищ│

│ │информации │

│Обеспечение входящих│Обеспечение бесперебойного ввода в│

│информационных потоков │систему справочных значений (курсы│

│ │валют, справочники кодов) │

│Обеспечение электронной почтой │Администрирование почтового сервиса│

│ │организации, а при его отсутствии -│

│ │разработка политики пользования почтой│

│ │сторонних организаций │

Технические регламенты

- сократить затраты на обучение и зарплату персонала;

- снизить риски принятия неправильных решений;

- выработать и поддерживать технические стандарты;

- отработать методы устранения исключительных ситуаций.

Таблица 9

Основные внутренние регламентирующие документы

│ Наименование │ Содержание документа │

│ документа │ │

│ 1 │ 2 │

│System Architecture│Определяет базовые решения, применяемые в│

│Policy (системная│организации. Включает перечень операционных и│

│архитектура │телекоммуникационных систем, описание│

│организации) │используемых аппаратных платформ,│

│ │регламентируется порядок их взаимодействия. Как│

│ │правило, в документ входят следующие разделы: │

│ │ аппаратные платформы: │

│ │- спецификация серверов организации; │

│ │- спецификация персональных станций│

│ │пользователей; │

│ │- спецификация мобильных компьютеров; │

│ │ сетевые платформы: │

│ │- структура глобальных сетей организации; │

│ │- общие требования локальных сетей организации; │

│ │- требования к защите сетей; │

│ │ программное обеспечение: │

│ │- операционные системы; │

│ │- банковские системы; │

│ │- офисные приложения; │

│ │- утилиты обслуживания и администрирования │

│Data Architecture│Определяет модель хранилища данных организации,│

│(структура данных в│включая используемые системы управления данными,│

│организации) │описание сущностей системы и их атрибутов, связь│

│ │между ними и порядок доступа пользователей к ним│

│Use of External│Определяет порядок взаимодействия со сторонними│

│Packages (порядок│разработчиками, правила и область использования│

│использования внешних│их продуктов │

│разработок) │ │

│Use of External│Определяет порядок взаимодействия со сторонними│

│Resources (порядок│поставщиками услуг в области информационных│

│использования │технологий │

│сторонних ресурсов) │ │

│IT Security (правила│Регламентируют структуру системы информационной│

│информационной │безопасности организации. Определяют механизмы│

│безопасности) │защиты информационных потоков и права доступа к│

│ │информации для пользователей и сторонних систем │

│System Operability and│Содержит перечень работ для обеспечения│

│Service Recovery│эффективного и бесперебойного функционирования│

│(обеспечение │информационной системы организации. Данный│

│оперативной работы│документ может иметь следующие составляющие: │

│системы и порядок│ поддержка системы: │

│восстановления) │- порядок восстановления, остановки и запуска│

│ │системы; │

│ │- резервное копирование и архивация; │

│ │- использование вычислительных мощностей и│

│ │дискового пространства в системе; │

│ │- порядок внесения изменений в систему; │

│ │- инструкция по использованию интерфейса│

│ │администратора системы; │

│ │ внешнее обслуживание системы: │

│ │- сервисное обслуживание информационных систем; │

│ │- обеспечение входящих информационных потоков; │

│ │- требование к выходящим информационным потокам;│

│ │ контроль производительности системы: │

│ │- соответствие работоспособности системы и│

│ │утвержденным требованиям; │

│ │- эффективность использования ресурсов системы; │

│ │- поддержание актуальных во времени данных; │

│ │- порядок устранения текущих сбоев и ошибок│

│ │системы │

Циклы оперативной работы

В операционной работе ИТ-подразделений определяются три типа циклов:

* временные циклы;

* циклы, определенные критическими параметрами системы;

Таблица 10

Примеры критических параметров систем

│ Параметр │ Выполняемые действия │

│Заполнение имеющегося│установка дополнительного дискового│

│дискового пространства │пространства; архивирование данных; перенос│

│ │данных на другие накопители │

│Достижение предела│установка более мощных вычислительных│

│производительности │систем; запуск оптимизационных процедур │

│Достижение максимального│оптимизация порядка эксплуатации системы;│

│количества пользователей│покупка дополнительных рабочих мест к│

│системы │системе │

│Полное использование│замена использованных материалов │

│расходных материалов │ │

* конец операционного дня;

* конец месяца;

* конец года.

Для отдела информационных технологий подобные события обычно связаны со следующими работами:

- установкой запрета на внесение изменений в закрытый период времени;

- резервным копированием;

- формированием отчетности;

- расчетами различных итоговых параметров системы;

- обновлением системных справочников.

Резервное копирование и архивирование

Приведем основные параметры системы резервного копирования.

Оптимизация системы

Внесение оперативных изменений в систему

- разработка новых отчетов и печатных форм;

- изменения в документопотоке системы;

- администрирование пользователей системы и их обучение;

- изменение отдельных функций системы.

Обеспечение актуальной справочной информации

* справочники финансовых инструментов:

- справочник валют;

- справочник ценных бумаг сторонних эмитентов;

* справочники участников рынка:

- справочники банков;

- справочники юридических лиц;

* справочники законодательных актов.

Информационная безопасность

Нарушения конфиденциальности

Для иллюстрации рассмотрим наиболее часто встречающиеся примеры нарушения доступа к информации:

* ошибки администрирования:

- неправильное формирование групп пользователей и определение прав их доступа;

* ошибки проектирования информационной системы:

* небрежность пользователей в вопросах информационной безопасности:

* умышленный взлом системы:

Изменения в системе

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

* ошибки программирования:

* ошибки ввода:

* технические сбои:

* умышленные нарушения в системе:

- несанкционированный умышленный ввод данных через пользовательский интерфейс;

- несанкционированные изменения в системе, минуя пользовательский интерфейс;

Утрата работоспособности или производительности

Выделим причины, связанные с работоспособностью:

* ошибки разработки и проектирования:

* технические проблемы, связанные с программно-аппаратным комплексом:

- неисправность оборудования и сбой в электропитании;

Источники и мотивы нарушений

Рассмотрим непреднамеренные ошибки сотрудников.

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

- двойной ввод документов;

- использование шаблонов;

- снижение нагрузки на персонал;

- дополнительный визуальный контроль документа.

Причинами, побудившими сотрудников к умышленному нарушению информационной безопасности, являются:

- обида на действия менеджеров, как правило, связанная с конфликтами или увольнением сотрудника;

- попытка дополнительного заработка;

- попытка хищения денег из организации;

- попытка создания зависимости организации от конкретного сотрудника;

- карьерная борьба.

Последняя по порядку, но далеко не последняя по смыслу причина - это аварии, стихийные бедствия и т.п.

Организация информационной безопасности

"Рис. 13. Схема организации информационной безопасности"

Таблица 11

Примерная структура политики информационной безопасности

│ Глава документа │ Содержание │ Ответственные сотрудники │

│ 1 │ 2 │ 3 │

│Общее положение │Определяется статус документа │Руководитель высшего звена.│

│ │ │Представители службы│

│ │ │безопасности │

│Классификация данных│Определяются группы объектов информационной│Технологи банка │

│по степени│системы, их владельцы и степень доступа к ним.│ │

│открытости. │Пример: аналитические счета банка,│ │

│Определение │синтетические счета, справочники │ │

│владельцев │ │ │

│информационных │ │ │

│ресурсов │ │ │

│Правила доступа и│Определяются основные правила доступа к данным.│Технологи банка,│

│группы пользователей│Пример: доступ к данным на чтение -│администратор системы │

│ │руководитель должен видеть всю информацию, к│ │

│ │которой имеют доступ все его подчиненные │ │

│Правила эксплуатации│В этой главе описываются правила по технике│Руководители подразделений,│

│ │информационной безопасности для пользователей│сотрудник │

│ │(правила хранения носителей информации,│информационно-технических │

│ │структура паролей, доступ к аппаратным│служб, сотрудник отдела│

│ │составляющим системы) │безопасности │

│Правила хранения│Данная глава определяет: │Руководитель │

│информационных │- какой программный продукт обеспечивает│информационно-технических │

│объектов в системе │хранение и обработку различных объектов; │подразделений, разработчики│

│ │- на каких процессорах (серверах или│системы, внутренний аудит │

│ │пользовательских станциях) выполняются│ │

│ │различные задачи; │ │

│ │- как осуществляется резервное копирование│ │

│ │системы │ │

│Правила разработки│Данная глава включает в себя: │Руководители проектов,│

│информационной │- перечень технических и программных средств,│внутренний аудит,│

│системы │допустимых к использованию в системе; │представители службы│

│ │- утвержденные алгоритмы криптографии и│безопасности │

│ │электронной подписи; │ │

│ │- порядок ведения проектной документации │ │

│Порядок внесения│В данной главе описывается самый уязвимый этап│Руководители проектов,│

│изменений, │в жизни информационной системы, связанный с│внутренний аудит,│

│обновления и замены│установкой и внедрением новых технологических│представители службы│

│рабочей версии│цепочек или программно-аппаратных решений │безопасности, руководители│

│информационной │ │подразделений │

│системы │ │ │

│Механизмы │В данной главе описывается перечень файлов│Внутренний аудит, технические│

│мониторинга доступа│протокола, которые ведутся системой, а также│специалисты │

│к объектам│набор контрольных метрик, определяющих│ │

│информационной │состояние системы и угрозы нарушений в ее│ │

│системы │работе │ │

│Обязанности │В этом разделе рассматриваются различные│Руководитель │

│должностных лиц в│нарушения или угрозы нарушений, выявленные в│информационно-технологическо-│

│случае нарушений│результате анализа механизмов мониторинга, и│го подразделения,│

│информационной │определяются действия должностных лиц по│представители службы│

│безопасности системы│устранению или предотвращению нарушений │безопасности │

Меры информационной безопасности можно разделить на четыре категории.

- создание здорового социального климата в организации;

- снижение нагрузки на персонал и развитие системы восстановления работоспособности сотрудников;

- ограничение знания сотрудников только областью их непосредственных обязанностей;

- контроль и анализ нетипичных действий сотрудников и сторонних лиц (партнеров, клиентов);

- четкая система обучения.

- шифрование;

- электронные подписи и электронная аутентификация;

- развитие системы доступа к данным;

- система защиты программных ресурсов;

- система защиты аппаратных ресурсов;

- физическое ограничение доступа к аппаратным ресурсам системы.

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

- страхование рисков;

- создание резервных систем;

- моделирование нарушений;

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

4. Мониторинг нарушений. Цель мониторинга - распознавание нарушений в информационных системах, а именно:

- аудит информационной системы;

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

- система контрольных метрик.

Управление рисками

Основные этапы управления рисками:

* инициирование и планирование;

* сбор информации о существующих процедурах ИБ и внутреннего контроля;

* идентификация потенциальных угроз;

* оценка вероятности их наступления и возможных последствий;

* составление и обновление карты рисков;

* разработка дополнительных мер информационной безопасности и контрольных процедур;

* подготовка отчетов для руководства;

* контроль внедренных процедур.

риск = вероятность х среднестатистическая сумма ущерба.

Оценивая вероятность, необходимо учитывать, что: