Главная Учебники - Разные Лекции (разные) - часть 14
|
Информационные технологии в банке
www.lekcii.at.ua
Содержание
Часть 1. Организация и развитие ИТ-менеджмента
Тесное взаимодействие с бизнесом
Основные тенденции развития ИТ
Составление стратегического плана
Управление экономическими аспектами ИТ в банках
Организация процесса выбора системы
Часть 2. Операционное управление информационными технологиями
Особенности управления ИТ-персоналом
Элементы системы управления персоналом
Принципы поддержки пользователей
База данных запросов и автоматизация
Всеобщее управление качеством (TQM)
Жизненный цикл программного обеспечения
Специализированный стандарт TickIT
Особенности управления качеством ИТ-услуг
Взаимодействие с внешними поставщиками
Резервное копирование и архивирование
Внесение оперативных изменений в систему
Обеспечение актуальной справочной информации
Утрата работоспособности или производительности
Организация информационной безопасности
Влияние систем защиты на развитие бизнеса
Регулирование аудита информационных систем
Технология аудита информационных систем
Часть 3. Управление проектами в области ИТ
Общий подход: теория и практика
Определение объектов изменений и их "размораживание"
Документирование текущей технологии
Критерии оптимизации и ограничивающие условия
Анализ текущей технологии работы
Выработка, согласование и документирование новой технологии
Контроль эффективности осуществленных преобразований
Корректировка и закрепление изменений
Оценка эффективности разработки
Анализ рисков при реализации проектов
Типы рисков в информационном проекте
Определение идеального решения
Применение информационного фонда
Переносимость найденного решения на другие задачи
Часть 4. Практические решения и инструментарий
Автоматизированные банковские системы (АБС)
Инструментарий бизнес-моделирования
Приложение 1. Схема организации ИТ по CoblT
Приложение 2. Анализ функций ИТ: результаты диагностики
Приложение 3. Пример матричной оргструктура ИТ-департамента
Приложение 4. Образцы тендерной документации
Приложение 5. Соглашение о взаимодействии пользователей и специалистов ИТ (SLA)
Приложение 6. Перечень эксплуатируемых систем и программ
Приложение 7. Пример экзаменационных вопросов для ИТ-аудиторов
Приложение 8. Пример бизнес-схем в стандарте IDEF0
Книга А.В. Тютюнника и А.С. Шевелева посвящена теоретическим и практическим вопросам управления информационными системами (ИС), которые становятся все более актуальными. Актуальность книги настоящего издания обусловлена двумя обстоятельствами. Во-первых, управление информационными системами - информационный менеджмент (ИМ) как самостоятельное направление практической деятельности, исследований и образования - в России возникло относительно недавно, хотя по сути информационный менеджмент является важной сферой деятельности для любой фирмы. Информационная система представляет собой модель системы управления, через которую проходит формализованная (структурированная) и частично формализованная (слабо структурированная) информация. Адекватность этой модели улучшается с развитием информационных технологий (ИТ) и совершенствованием парадигмы построения и управления ИС. Адекватность ИС в значительной мере определяет ее эффективность как инструмента управления. Таким образом, фирма - производитель ИС заинтересована не только в разработке (управление разработкой ИС - технологический менеджмент), но и в реализации ИС на рынке, а после покупки ее фирмой-потребителем - внедрении ИС на объекте (проектный менеджмент ИС). За последние несколько лет на тему информационного менеджмента был выпущен не слишком обширный ряд работ таких авторов, как В.В. Годин, А.В. Костров, В.В. Баранов и Д.С. и Н.С. Аглицкие. Во-вторых, проблемы информационного менеджмента в настоящей работе рассмотрены не изолированно, а в тесной увязке с вопросами автоматизации банковской деятельности, то есть с проблемами предметной области. Следует отметить, что на рынке автоматизированных банковских систем (АБС) конкуренция сегодня в меньшей мере связана с различиями их функциональных возможностей, но в большей - с качеством обслуживания клиента фирмой-производителем на таких этапах жизненного цикла системы, как внедрение и эксплуатация ИС. Фирма-потребитель (в данном случае - КБ) заинтересована в быстром и бесконфликтном внедрении ИС. Мнение неспециалистов о том, что инсталляция и есть внедрение, верно только для так называемых коробочных решений. На самом деле инсталляция лишь начинает внедрение ИС, которое проходит в большинстве случаев весьма болезненно. Это связано с тем, что новая технология еще полноценно не заработала, а старая (предметная) технология подвергается проверке при внедрении новой и обнаруживает в ней ошибки. Такая ситуация может повлечь за собой противостояние разработчиков АБС и сотрудников КБ. Кроме того, сотрудники банка вынуждены довольно долгое время вести обе технологии одновременно: старую (поскольку они в ней уверены и к ней привыкли) и новую (поскольку на нее придется, так или иначе, переходить). Еще одна "неприятность", которая является следствием внедрения ИТ - изменение функциональных обязанностей лиц, принимающих решения (ЛПР) в системе управления. Изменение их функциональных обязанностей ведет к необходимости обучения персонала ИТ и изменения организационной структуры управления объектом. Следствием этого являются либо появление иных или дополнительных обязанностей у ЛПР (оптимистический вариант), либо увольнение ненужных сотрудников (пессимистический вариант). Принимая решение о приобретении ИС, руководство банка должно сделать выбор: адаптировать ли ИС под существующую организацию бизнес-процессов и организационную структуру, спланировать их изменение и поддержать эти изменения внедрением ИС или просто адаптировать под требования ИС свою ОСУ. Сохранившийся до сих пор подход к автоматизации деятельности КБ, выражающийся в требовании поддержать инструментально существующую систему управления, не просто безнадежно устарел, а является методологически неверным. Исходя из такой формулировки, любая автоматизация - уже успех. При этом руководство банка зачастую даже не задается вопросами: как изменятся бизнес-процессы, обеспечивающие оказание услуг или управления, как изменится организационная структура управления, не говоря уже о том, чтобы задуманная руководством организационно-технологическая перестройка рассматривалась как основной процесс, а информационные технологии - как инструмент поддержки этого процесса. Книга А.В. Тютюнника и А.С. Шевелева чрезвычайно точно и своевременно расставляет акценты в вопросах банковской автоматизации, перенося центр тяжести с описания имеющихся банковских ИТ на описание процессов управления ими. Авторы ставят своей целью помочь банковским практикам в организации управления ИС в соответствии с лучшими международными стандартами на всех этапах их жизненного цикла - планирования, анализа, приобретения, внедрения и обслуживания в период эксплуатации ИС. Книга будет полезна и ИТ-менеджерам фирм-производителей программного обеспечения, и ИТ-менеджерам коммерческих банков (потребителей), руководителям коммерческих банков, а также руководителям банковских подразделений, менеджерам и специалистам, которые так или иначе участвуют в приобретении, разработке, внедрении и эксплуатации информационных технологий как со стороны коммерческих банков ("фирм-потребителей"), так и "фирм-консультантов", которые стали устойчивыми участниками во взаимодействии разработчиков и потребителей. Доктор экономических наук, профессор, заведующий кафедрой информационного менеджмента и электронной коммерции Московского государственного университета экономики, статистики и информатики (МЭСИ) В.В. Дик Авторы считают своим долгом выразить благодарность всем тем, кто оказал помощь при подготовке этой книги и содействовал нашему профессиональному росту, в том числе Джереми Фостеру, Хорхе Ивашкевичу, Стивену Тиммонсу, Джону Йанни, Роменскому Артему Александровичу, Парфенову Дмитрию Александровичу, Глазкову Александру Валерьевичу, Овсию Валерию Ивановичу. За содействие в сборе информации по поставщикам банковских информационных систем авторы приносят благодарность Королеву Денису Михайловичу. Авторы также выражают благодарность руководству и специалистам компаний PricewaterhouseCooper, Temenos, "Диасофт", банка HSBC, коллективу преподавателей Московского государственного университета экономики, статистики и информатики (МЭСИ) и персонально профессору Дику Владимиру Владимировичу. Сегодня повсеместное использование информационных технологий (ИТ) стало объективной необходимостью. Спектр областей, в которых применяются информационные технологии, чрезвычайно широк. Одной из сфер, где их значение было традиционно велико с момента начала их бурного развития, является финансовая сфера. Несмотря на то что еще каких-нибудь десять-пятнадцать лет назад кредитные организации использовали ручные методы обработки информации, сейчас практически обязательными атрибутами любого банка стали компьютеры, электронные терминалы, средства связи и коммуникации и т.д. Можно с уверенностью утверждать, что процесс информатизации банковской деятельности продолжится. Основными тенденциями станут повышение качества и надежности предлагаемых продуктов и услуг, увеличение скорости осуществления расчетных операций, организация электронного доступа клиентов к банковским продуктам. Эти факторы связаны прежде всего со стремлением банков к достижению конкурентных преимуществ на финансовых рынках. Вследствие применения банковских информационных технологий стали возможны качественное расширение рынка продуктов и услуг, охват большей доли рынка посредством использования банкоматов, электронных расчетных систем, интернет-технологий, оперативный доступ клиентов к информации. Все это и в дальнейшем будет способствовать активному внедрению в банковскую практику самых последних достижений в области вычислительной техники, сетевых и информационных технологий, методов защиты информации и обработки данных. В настоящее время расходы на ИТ-решения как никогда высоки. По статистическим данным, на закупку и внедрение ИТ-решений российские банки выделяют не менее 5% годовой сметы расходов. Но суммы затрат во многом зависят от того, какие именно информационные проекты ведет банк, какую рыночную нишу он занимает и какие новые услуги собирается внедрять. В частности, ИТ-бюджеты банков, ведущих агрессивную политику на рынке, могут достигать 35% от общих затрат. Например, Пробизнесбанк на время внедрения CRM-системы увеличил долю затрат на ИТ с обычных 7-10 до 15%. Банк "МЕНАТЕП СПб" 30% своего ИТ-бюджета в 2000 году (25-30% от общей сметы расходов) потратил на интернет-проекты, причем треть этой суммы - на системы информационной безопасности (по данным агентства Росбизнесконсалтинг). Все это приводит к резкому росту значения ИТ-области, которая становится одной из самых затратных и одновременно высокорискованных областей в банковской деятельности. Системы управления деятельностью кредитных и финансовых организаций сегодня представляют собой самостоятельное направление в сфере информационного бизнеса. Информационные системы для кредитных организаций прошли достаточно долгий путь развития, и в настоящее время они позволяют автоматизировать любые банковские бизнес-процессы: управление ликвидностью, кадрами, банковскими рисками и т.д. Рынок программных продуктов для кредитных организаций представлен широким спектром систем, различающихся как в функциональной части, так и в технической реализации. Сегодня практически обязательными требованиями к любой банковской информационной системе стали возможность сетевой работы многих пользователей, реализация всего комплекса банковских операций по расчетно-кассовому обслуживанию, кредитно-депозитной деятельности, валютным операциям, гибкая настройка прав доступа конечных пользователей, поддержка нескольких аппаратных платформ, автоматизированное формирование большинства отчетных форм и возможность их гибкой перенастройки и т.д. Этим требованиям в настоящее время удовлетворяют большинство систем, представленных на рынке программных продуктов для финансовых организаций. Несмотря на их кажущуюся схожесть, они могут принципиально различаться как с точки зрения технической реализации, так и уровнем предоставляемого сервиса. Помимо программного обеспечения банковские информационные технологии включают еще целый комплекс вопросов, касающихся информационного, аппаратно-технического обеспечения банковских операций и телекоммуникаций. Информационные технологии предоставляют возможность ведения учета всего спектра операций, осуществляемых банком, с приемлемой степенью скорости и надежности, получение всей бухгалтерской и финансовой отчетности. Они должны уметь автоматизировать реальный банковский документооборот, то есть быть построены "не от проводок, а от операций". Информационные технологии поддерживают управленческий учет и стратегическое планирование. Они предоставляют широкие возможности для контроля и анализа управленческой и учетной информации. Информационные системы обеспечивают обмен данными с программными продуктами и инструментальными средствами для финансового и статистического анализа. За последнее время значительно возросло значение новых банковских услуг, предоставляемых клиентам посредством интернет-технологий. Учитывая повсеместное использование банками систем электронной связи и постепенный переход к безбумажной технологии обмена информацией, можно судить о важности этого направления для банков. Данная проблема также актуальна для филиальных банков, работающих в режиме онлайн с филиалами. Многие разработчики информационных систем включают средства защиты информации в собственные программные продукты. Помимо этого существуют различные средства независимых разработчиков, осуществляющие защиту передаваемой информации от несанкционированного просмотра и изменения при передаче. Отдельную и важную роль банковские информационные технологии играют в процессах реинжиниринга и совершенствования работы кредитных организаций, организационно-технологической перестройки работы банка. Несмотря на универсальность большинства российских банков с точки зрения спектра операций, практически невозможно найти два банка, похожих друг на друга организационной структурой, технологией предоставления клиентам услуг, структурой документооборота и т.д. Хотя экономический смысл банковских операций в любом случае остается неизменным, каждый коммерческий банк работает по собственной сложившейся технологии. Она может быть не всегда оптимальной, характеризоваться неоправданно высокими затратами, но тем не менее эта технология является "исторически сложившейся" для данного банка и при отсутствии каких-либо внешних или внутренних побуждающих факторов продолжает использоваться. Лишь в течение ограниченного промежутка времени существующая технология отвечает текущим потребностям банка, позволяет вносить изменения, носящие скорее косметический характер и не затрагивающие организационной структуры, сути бизнес-процессов. Наступает момент, когда любая технология теряет свою актуальность в изменившихся рыночных условиях и становится сдерживающим фактором на пути дальнейшего развития бизнеса. С другой стороны, очевидно, что залогом успешного развития любого бизнеса являются его гибкость, способность к адаптации в соответствии с изменяющейся внешней средой. Переход банка на качественно иной уровень развития неизбежно требует внедрения в банковскую практику новых технологий, новых подходов и методов работы. Эти процессы часто сопровождаются пересмотром организационной структуры, изменением спектра предлагаемых банковских продуктов и услуг, реинжинирингом бизнес-процессов (который состоит в фундаментальном переосмыслении и радикальном перепланировании бизнес-процессов компаний и имеет целью существенное (но не обязательно единовременное) улучшение показателей их деятельности: резкое сокращение затрат, рост качества, сервиса и скорости обслуживания клиентов), внедрением новых информационных технологий. Кардинальные изменения в технологии работы кредитной организации, появление новых продуктов и услуг приводят к тому, что система автоматизации и управления деятельностью банка, которая использовалась ранее, перестает отвечать новым изменившимся требованиям с точки зрения банковской технологии. Распространенная ошибка - ставить во главу угла процесса организационно-технологической перестройки банка информационную систему, ее функциональные возможности. После выбора новой системы банком предпринимаются попытки адаптировать под нее собственную технологию работы, что в принципе неверно. Такое решение только усугубляет негативную ситуацию, фактически "закрепляя" недостатки банковской технологии посредством их переноса в банковскую информационную систему. Из вышесказанного следует очевидный вывод: организационно-технологическая перестройка банка должна рассматриваться как первичный процесс, определяющий изменения в информационных технологиях. Результатом данного процесса будет внедрение новой или адаптация старой информационной системы банка. Таким образом, реинжиниринг кредитных организаций и внедрение новых банковских и информационных технологий являются тесно взаимосвязанными процессами. Информационные системы управления (или MIS - Management Information System) приобрели в последнее время огромную значимость, так как являются наиболее эффективным инструментом банковского управления, и постепенно российские финансовые организации начинают их использовать. В то же время сфера информационных технологий с каждым годом все более усложняется. ИТ поглощают огромные финансовые и временные ресурсы, при этом не всегда предоставляя адекватный эффект. Одной из самых распространенных причин такой негативной ситуации являются ошибки в менеджменте. Каковы же наиболее типичные ошибки, свойственные российским организациям в области управления ИТ? Одной из самых распространенных является недостаток внимания со стороны высшего руководства к задачам автоматизации, принижение их значения. Многие руководители никак не могут осознать, что ИТ оказывают принципиальное влияние на эффективность бизнеса и на его жизнедеятельность. Для того чтобы осознать значение ИТ, руководителю достаточно ответить на вопрос: что будет с его бизнесом при выходе из строя основного серверного оборудования или при разглашении принципиальной клиентской информации? Другой распространенной ошибкой является недостаток финансирования. Практика показывает, что средние относительные затраты (в процентном отношении от доходов) на ИТ в российских компаниях существенно ниже, чем в аналогичных зарубежных компаниях. И особенно в части затрат на ИТ-специалистов, которые, как правило, являясь специалистами в своей области, прекрасно ориентируются и в предметной области. Как следствие этого, высокая текучка кадров, нагрузка на сотрудников и совмещение различных обязанностей, например разработчик зачастую ответственен и за тестирование своих же систем, что в конечном счете резко повышает риски. И наконец, недостаток навыков в области управления ИТ, что выражается в попытке ИТ-специалистов решать все вопросы по своему усмотрению, спонтанно. Многие организации не используют проектные методы управления, международные стандарты в области управления ИТ или системной безопасности (например, СОВIТи BS7799), не уделяют внимания управлению качеством эксплуатируемых систем, организации обслуживания пользователей, не осуществляют внутренний аудит информационных систем, не документируют свои процессы. Все это в конечном итоге приводит к неконтролируемости процессов, срыву сроков и выходу за пределы бюджета. В условиях того, что современные технологии постоянно меняются и усложняются и знания специалистов могут принципиально устаревать всего за 3-4 года, важнейшим моментом являются обучение и сертификация ИТ-специалистов, чему традиционно уделяется недостаточно внимания. В современных экономических условиях основная миссия ИТ-менеджера финансовой организации состоит в обеспечении технологической базы сбалансированного развития и содействии бизнес-структурам в достижении конкурентного преимущества за счет повышения качества обслуживания клиентов и оптимизации внутренних бизнес-процессов. Другими словами, одними из принципиальных направлений деятельности ИТ-менеджера помимо общей организации работы ИТ-подразделения становятся взаимодействие с бизнес-подразделениями, совместная проработка стратегии и тактики развития, оценка экономических аспектов ИТ. Данная книга посвящена проблемам управления банковскими информационными технологиями. Хотелось бы отметить, что эти вопросы имеют огромную значимость и уже давно не являются "техническими", а требуют пристального внимания высшего руководства и всех служб финансовых организаций. Информационные технологии - это не обслуживающий, второстепенный участок, как было некоторое время назад, они участвуют в работе всех подразделений и напрямую определяют возможности организации по развитию бизнеса и совершенствованию внутренних процессов и системы обслуживания клиентов. Исходя из сказанного выше, организовано и построение книги. Мы постарались избегать изложения устоявшихся подходов, отдавая предпочтение новейшим тенденциям и международной практике. Имея существенный опыт международной работы в области ИТ, авторы не ограничились констатацией западных Best Practices (лучших практик), а попытались адаптировать действительно лучшее, что есть в международном опыте, к использованию в России. В книге достаточно широко рассмотрены основные ошибки, свойственные российским кредитным организациям. Данное издание является в большей степени практическим, поэтому структура и рубрикация книги позволяют использовать ее в качестве справочного материала по тому или иному направлению ИТ-менеджмента в банках. Книга адресована в первую очередь менеджерам по информационным технологиям, высшему руководству банков, специалистам по банковским и информационным технологиям, внутреннему контролю и аудиту, а также может быть использована в качестве учебного пособия. Первая часть
посвящена непосредственным задачам ИТ-менеджера. При этом рассмотрены такие элементы, как общая организация управления (включая структуру, методологию, использование стандартов, ресурсы, взаимодействие с бизнесом), стратегия ИТ (от новейших тенденций развития стратегического видения до составления стратегического плана), управление экономическими аспектами ИТ (бюджетирование, анализ инвестиций, распределение и оценка издержек) и выбор решений как ключевой элемент развития ИТ (от анализа целесообразности и организации процесса выбора ИТ-решений до заключения контрактов и вовлечения сторонних консультантов). Во второй части
рассказывается о ежедневном операционном управлении информационными технологиями, где основной функцией ИТ-менеджера являются их правильная организация и контроль. Рассмотрены и традиционные составляющие этой работы - обслуживание пользователей, управление персоналом, информационная безопасность и такие новые направления, как аутсорсинг, аудит ИТ, управление качеством. Третья часть
посвящена управлению проектами (Project Management) - важнейшей составляющей современного ИТ-менеджмента и основной форме проведения большинства работ в области ИТ. Рассмотрены все основные моменты организации проектной работы, такие элементы ИТ-проектов, как планирование, организация взаимодействия, управление изменениями, разработка, тестирование и внедрение решений. В четвертой части
дан обзор практических решений в области банковской автоматизации, включая технические, телекоммуникационные и программные решения, инструментарий. Завершается книга большим количеством приложений
, которые иллюстрируют решения, освещенные в книге, содержат примеры реальных документов, схемы и ссылки на информационные ресурсы. Надеемся, что данная работа окажет реальную помощь многим банкам, осознающим стратегическую значимость информационных технологий в современном мире и необходимость их постоянного совершенствования и развития для эффективного функционирования организации в целом.
Часть 1. Организация и развитие ИТ-менеджмента
Большинство организаций понимают, какую выгоду может принести использование современных информационных технологий и как они кардинально изменяют бизнес, выводя его на принципиально другой уровень. Но как в любом сложном деле, так и в информационных технологиях многое зависит от организации процесса управления. При этом, учитывая, что ИТ является специфической и стремительно меняющейся областью, здесь требуются и специфические подходы, которые можно структурировать по нескольким направлениям. Во-первых, для управления ИТ не всегда подходят методики традиционного менеджмента и зачастую требуется их адаптация. Во-вторых, ИТ-менеджер помимо того, что должен быть хорошим руководителем, должен быть до определенной степени техническим специалистом (технократом) и по крайней мере отлично разбираться в новейших подходах и тенденциях развития ИТ. В-третьих, ИТ-менеджмент уже сформировался как наука и поэтому имеет свои методики и наработки, не используя которые, можно столкнуться с серьезными проблемами. Но прежде чем мы рассмотрим эти специфические подходы, необходимо определиться с самим понятием. Итак, что же такое ИТ-менеджмент? ИТ-менеджмент (в западной практике чаще употребляется термин IT Governance) - это система управления и контроля организационных взаимоотношений и процессов, направленная на достижение стратегических целей организации посредством использования информационных технологий и минимизации риска их применения. Это определение близко к "официальному" определению Института управления ИТ (IT Governance Institute) и Ассоциации контроля и аудита информационных систем (ISACA), адаптированные материалы которых мы будем активно использовать и далее. Таким образом, основная задача ИТ-менеджмента - это достижение стратегических целей посредством ИТ. Другими словами, ИТ-развитие не может быть самоцелью и бессмысленно без тесной связи с развитием бизнеса. При этом такие функции ИТ, как контроль и риск-менеджмент, являются важнейшими составляющими этого процесса, так как классический баланс между рискованностью и отдачей крайне актуален не только в финансах, но и в информационных технологиях. Другой важной задачей ИТ-менеджмента является достижение соответствия различным внешним и внутренним требованиям. Передовые организации должны стремиться соответствовать требованиям качества, международным и местным стандартам, требованиям контролирующих органов, законодательным актам, общепризнанным подходам и методологиям в области ИТ. Количество таких требований за последнее время существенно возросло. Многие из международных требований становятся актуальны и для России. Рассмотрим основные составляющие процесса организации управления информационными технологиями. Управление - это создание изменений для достижения цели. Менеджмент должен служить достижению цели, это постоянное движение. Нагляднее всего можно представить этот процесс как путь из точки А (текущее состояние) в точку Б (желаемое состояние - цель). При этом, как и при простом передвижении, необходимо: - иметь адекватное средство передвижения (для ИТ это ресурсы); - понимать как управлять этим средством (мы называем это использованием проверенной методологии управления ИТ); - понимать, во сколько обходится нам наше движение и оправдано ли оно (в случае с ИТ эту часть менеджмента называют экономикой ИТ); - знать особенности движения и эксплуатации этого средства. Все эти моменты составляют основу ИТ-менеджмента и будут рассмотрены далее. Однако первым и самым важным среди составляющих процесса управления ИТ является стремление к обозначенной бизнес-цели. Необходимо понимать, что любое движение, любая деятельность в области ИТ лишь тогда имеют смысл, когда они направлены на достижение поставленных бизнес-подразделениями целей. Этот момент особенно важен, так как для многих ИТ-менеджеров их собственная деятельность является самоцелью. Они стараются совершенствовать свои процессы до бесконечности, тратя существенные ресурсы и не особенно заботясь о том, как их деятельность связана со стратегией развития организации и конкретными бизнес-целями. Другими словами, у ИТ не может быть собственных целей, любая их цель должна быть требованием бизнеса, должна поддерживать развитие организации в утвержденном высшим менеджментом и владельцами (stakeholders) направлении. При правильной организации процесса управления ИТ-менеджмент принимает непосредственное и активное участие в определении стратегии и целей организации, так как именно ИТ является важнейшим источником развития и инноваций в банковском деле и в то же время источником серьезных ограничений бизнес-инициатив по стоимости, времени и реализуемости. Мы рассмотрим подробнее вопросы, связанные со стратегией ИТ, в отдельной главе
. Для достижения цели, воплощения стратегии необходимы ресурсы. Если мы условно сравнивали цели с конечной точкой путешествия, то ресурсы - это то, на чем мы передвигаемся, то есть средство достижения цели. Очевидно, что адекватное ресурсное обеспечение не только является ключевым фактором для достижения цели или результативности (effectiveness), но и для решения оптимизационной задачи или эффективности достигнутого решения (efficiency). Для ресурсного обеспечения традиционны три основные "болезни". Первая - недостаток ресурсов, который "хоронит" проекты после инвестирования 90% ресурсов, вложенные деньги не только не приносят желаемого эффекта, но и просто оказываются "выброшенными на ветер". Вторая болезнь - избыток ресурсов. Как ни странно, это тоже очень вредит управлению и развитию ИТ, так как снижает экономическую эффективность ИТ-решений, расслабляет менеджеров и специалистов и зачастую делает невозможным достижение цели. Так, например, ехать в соседнюю булочную на такси не просто дорого и неэффективно, если сравнить со стоимостью батона хлеба, но и дольше, чем идти пешком, не говоря о том, что вас туда вряд ли кто согласится везти. Наиболее распространена третья болезнь, которая присуща подавляющему большинству российских организаций, - несбалансированность ресурсов. Пять системных администраторов не заменят надежного и производительного сервера, и наоборот - дорогие технические средства не заменят квалифицированный персонал. Исходя из всего сказанного, становится очевидно, что управление ресурсами - важнейшая часть ИТ-менеджмента и одна из трех основных его задач (цели, ресурсы, методология). Рассмотрим основные ресурсы, находящиеся в распоряжении ИТ-менеджера. Мы относим к специфическим ресурсам ИТ следующие элементы: - людей (ИТ-персонал, сторонние специалисты и консультанты); - информацию (в самом широком смысле); - технологии (оборудование, системное ПО, СУБД, телекоммуникации); - системы (прикладное ПО); - инфраструктуру (все необходимое для деятельности ИТ - помещения и их оснащение, обеспечение). Общим ресурсом, который активно используется в процессе управления ИТ, являются, разумеется, деньги. Поэтому к важнейшим аспектам управления ресурсами ИТ относится экономика ИТ, так как большинство ресурсов, естественно, с учетом специфики и ограничений, могут быть увеличены с помощью денег. Важно помнить, что единственный невосполнимый ресурс - время. Даже при наличии неограниченных материальных ресурсов некоторые задачи невозможно выполнить быстрее. Обеспечение деятельности по поддержке и развитию ИТ требует в настоящее время существенных ресурсов. И вопросы сбалансированности и управления экономическими аспектами ИТ как важнейшие вопросы управления ресурсами будут рассмотрены в отдельной главе. Все перечисленные ресурсы важны для управления ИТ, но, разумеется, ключевым ресурсом, по нашему глубокому убеждению, являются люди. И это не просто слова и даже не только личный опыт. По данным международной статистики, до 80% неудач проектов в области ИТ связаны именно с проблемой кадров. Персонал как ключевой фактор управления и развития ИТ будет рассмотрен также в отдельной главе. Важнейшим моментом в области ресурсного обеспечения ИТ является использование сторонних ресурсов, так называемый аутсорсинг. ИТ-менеджер должен понимать, что невозможно сосредоточить все необходимые ресурсы, опыт и практику непосредственно в своей структуре, поэтому, когда встает какая-либо задача, необходимо определить, какой вид ресурсов (soursing) для данной задачи является более эффективным: внутренний (insoursing) или сторонний (outsoursing). В зарубежной практике в последнее время использование аутсорсинга, то есть сторонних ресурсов, все более расширяется и для многих видов задач считается более предпочтительным. Так, например, многие банки используют информационные системы, разработанные сторонними организациями, вместо того чтобы пытаться все разработки вести своими силами. Такие же тенденции наблюдаются и по другим направлениям ИТ. Но с аутсорсингом связаны и новые специфические риски, управление которыми является частью оперативной деятельности ИТ-служб. Они будут рассмотрены в соответствующем разделе
. Для правильной организации управления информационными технологиями сегодня недостаточно просто опыта и знаний менеджера, так как технологии и подходы постоянно меняются. Также крупные организации не могут полагаться только на знания одного человека: его ошибка может слишком дорого обойтись. С другой стороны, ИТ-менеджеру подчас бывает тяжело объяснить руководству какой-либо момент, поскольку оно воспринимает это объяснение как личную позицию ИТ-менеджера и не находит нужным считаться с ней. Все это приводит к тому, что, даже если ИТ-менеджер действительно понимает, как должны функционировать ИТ-процессы, реализация этого понимания на практике затруднена по ряду причин. В международной практике для решения этой проблемы считается необходимым использовать в процессе организации управления ИТ какую-либо методологию управления ИТ. Подобные методологии содержат: структуру организации управления, основные цели и задачи, функциональные блоки и подходы к организации работы по ним, описание "правильных подходов" и практические примеры, количественные метрики и показатели (KPI - Key Performance Indicators, KGI - Key Goal Indicators, CSF - Critical Success Factors и т.д.) для оценки результатов, систему приоритетов в организации работы. Возможны два источника таких методологий. Во-первых, существуют общепринятые методологии и стандарты, которые используются большим количеством организаций и поэтому являются проверенными. Во-вторых, это может быть собственная внутренняя методология, разработанная в крупной организации. Обычно самостоятельной разработкой занимаются только очень крупные организации, преимущественно международные, так как для этого требуются весьма объемная научная и исследовательская работа и ресурсы. Преимущества широко используемых методологий: * структурированный подход к управлению ИТ; * проверенные подходы и решения; * примеры "лучших международных практик" организации и управления ИТ; * гарантия достижения результата; * существенный авторитет внутри организации; * соответствие де юре и де факте международным нормативным актам и стандартам; * положительный маркетинговый и рыночный эффект. К наиболее известным методологиям и стандартам в области ИТ можно отнести: СоblТ - управление, контроль и аудит всех аспектов информационных технологий (в основном используется в американской практике); ITIL, ITSM - управление обслуживанием информационных систем (широко используется в европейских странах); ISO 9000 - управление качеством ИТ и программных продуктов; BS7799 - организация информационной безопасности; TickIT - управление качеством ИТ и программных продуктов; ГОСТы - государственные нормативно-технические документы, устанавливающие определенные нормы, правила. Рассмотрим две наиболее распространенные методологии управления ИТ - СоblТ и ITIL. СоblТ (Controls Objective for Information and related Technologies) - методология управления, контроля и аудита информационных систем. Разработана Международной ассоциацией аудита и контроля за информационными системами (ISACA), которая имеет представительства в 57 странах мира, в том числе в России, и включает более 22 000 членов при участии крупнейших международных консалтинговых компаний и научных организаций. СоblТ является базовой методологией для управления ИТ в таких организациях, как: SWIFT, Cedel Group, министерство обороны США, Daimler Chrysler, Royal Philips Electronics, SABI, Colgate-Palmolive. Отличительные черты СоblТ: - основан на общепринятых правилах и принципах управления информацией и информационными технологиями; - позволяет не только правильно провести аудит ИС, но и организовать управление и контроль над ними; - охватывает все циклы операций в области ИТ - от планирования до поддержки и контроля; - содержит примеры "лучших практик" организации ИТ и управления рисками; - ориентирован на менеджмент организации и решение задач бизнеса; - является инструментом совершенствования корпоративного управления бизнес-реинжиниринга. Международная методология СblТ - разработан с учетом требований и рекомендаций многих других стандартов в этой области, включая: технические стандарты (ISO, EDIFACT и т.п.); нормы корпоративного управления, установленные европейской комиссией (ЕС) (OECD, ISACA); стандарты качества информационных технологий и процессов (ITSEC, TCSEC, ISO 9000, SPICE, TickIT, Common Criteria); профессиональные стандарты внутреннего контроля и аудита (COSO report, IFAC, llА, AICPA, GАО, PCIE, ISACA standards); индустриальные стандарты и международные практики построения ИТ (ESF, 14, IBAG, NIST, DTI, ITIL). Согласно методологии СоblТ направления ИТ-менеджмента подразделяются на 4 основные области, которые в свою очередь делятся на 34 ИТ-процесса: 1. Планирование и организация: ПО 1. Разработка стратегического плана. ПО 2. Построение информационной архитектуры. ПО 3. Построение технологической модели. ПО 4. Определение структуры и организации ИТ. ПО 5. Управление инвестициями в ИТ. ПО 6. Согласование целей бизнеса и ИТ. ПО 7. Управление людскими ресурсами. ПО 8. Соответствие внешним требованиям. ПО 9. Оценка рисков. ПО 10. Управление проектами. ПО 11. Управление качеством. 2. Приобретение и внедрение: ПВ 1. Выбор решения. ПВ 2. Приобретение/разработка приложений. ПВ 3. Приобретение системных ресурсов. ПВ 4. Поддержка технологической документации. ПВ 5. Установка и настройка приложений. ПВ 6. Управление изменениями. 3. Сопровождение и поддержка: СП 1. Обслуживание пользователей. СП 2. Управление услугами третьих лиц. СП 3. Управление производительностью и мощностью. СП 4. Обеспечение непрерывности деятельности. СП 5. Обеспечение информационной безопасности. СП 6. Классификация и распределение издержек. СП 7. Обучение пользователей. СП 8. Помощь и консультирование пользователей. СП 9. Управление конфигурацией. СП 10. Управление проблемами и сбоями. СП 11. Управление информацией. СП 12. Управление инфраструктурой. СП 13. Управление операциями. 4. Мониторинг: М 1. Мониторинг процессов. М 2. Внутренний контроль. М 3. Независимая экспертная оценка. М 4. Внешний аудит. По каждой из перечисленных областей методология содержит детальное описание организации управления, рекомендации по оценке и совершенствованию внутреннего контроля за ИТ*(1)
. Другая, не менее широко развитая и используемая многими ведущими организациями, методология - это ITIL (IT Infrastructure Library) - набор всесторонних документов по управлению обслуживанием и сопровождением информационных систем. ITIL является эталонной моделью для сравнения текущей практики управления ИТ-сервисами организации с лучшей мировой практикой. Эта методология включает библиотеку из более чем 40 книг, разработанных ССТА (Центральное телекоммуникационное агентство, Великобритания). Каждая книга в ITIL охватывает определенный процесс управления ИТ-сервисами и описывает его отношения с другими процессами. ССТА разрабатывает методологии мирового уровня для управления информационными технологиями, включая методологию управления проектами PRINCE, методологию SSADM для системного анализа и проектирования и библиотеку ITIL. ITIL обеспечивает профессионалов в области ИТ знаниями и ресурсами, которые должны использоваться для поддержания эффективной и рациональной инфраструктуры, при минимальных затратах полностью удовлетворяющей потребности клиентов. ITIL предлагает систематический и профессиональный подход к управлению ИТ-сервисами. Основные преимущества применения ITIL: - предоставление клиенту более полного и качественного обслуживания; - уменьшение стоимости сервисов (услуг); - повышение взаимосвязи между персоналом ИТ-служб и клиентами; - повышение производительности обслуживания и максимально полное использование накопленных знаний и опыта. Концепция ITIL так же, как и СоblТ, базируется на лучшей практике и опыте ведущих экспертов, консультантов, инженеров и многими воспринимается на настоящий момент как наиболее полный стандарт де факте для организации управления обслуживанием ИС. Многие организации во всем мире используют ITIL как эталонную модель для сравнения текущей практики управления ИТ-сервисами организации с лучшей мировой практикой. Необходимо отметить, что внедрение подобных методологий является сложной задачей и не всегда может быть осуществлено без посторонней помощи. Это связано с тем, что в процессе внедрения необходимо оценить последовательность действий и сформулировать систему приоритетов. Также часто необходим практический опыт организации подобных процессов в других организациях. Для больших кредитных организаций не менее важным помимо выбора и использования проверенных подходов является и централизация методологического управления в целом по организации, так как зачастую в головном офисе используются передовые подходы, а в ближайшем филиале ИТ-функции и процедуры управления существенно менее развиты. При построении ИТ-менеджмента необходимо иметь в виду, что помимо трех основных задач верхнего уровня (достижение бизнес-целей, ресурсное обеспечение, включая управление экономическими аспектами ИТ и методологическое обеспечение ИТ-деятельности, которые мы рассмотрели в первом приближении выше) для правильной организации работы могут быть рекомендованы 8 ключевых подходов. Среди них: тесное взаимодействие с бизнесом, построение ИТ-подразделения по принципу обслуживающей (сервисной) организации, широкое использование проектной формы управления и матричной организационной структуры, активное использование в процессе управления оценки и контроля деятельности ИТ количественных показателей (метрик), высокая роль риск-менеджмента в ИТ-деятельности, постоянное совершенствование, оптимизация и обязательное документирование внутренних ИТ-процессов и работ и банковских технологий. Рассмотрим эти моменты по отдельности. Каждый из перечисленных подходов является своеобразной аксиомой ИТ-менеджмента, поэтому мы не будем доказывать их необходимость, а сосредоточимся на описании самих подходов.
Тесное взаимодействие с бизнесом
Первичность бизнес-целей давно не вызывает практически ни у кого в ИТ-сфере противодействия. Но как организовать это тесное взаимодействие? Как сделать его не формальным, а действенным? Как научиться понимать проблемы бизнеса и в свою очередь заставить бизнес считаться с ограничениями в ИТ и участвовать в ИТ-решениях? Все это не простые вопросы. С точки зрения международного опыта разрешить эти противоречия в первую очередь могут ИТ-комитет, профессионализм ИТ-директора (СЮ - Chief Information Officer) и активное вовлечение ИТ-менеджера в принятие бизнес-решений. Комитет по информационным технологиям контролирует процесс автоматизации в банке с целью достижения высокого уровня эффективности, стандартизации и организации безопасной и бесперебойной операционной деятельности в соответствии со стратегическими задачами банка. Комитет по ИТ также отвечает за поддержание технологических стандартов в банке на высоком уровне. ИТ-комитет должен быть реально действующим образованием, который на регулярной основе участвует в принятии ИТ-решений, выработке ИТ-стратегии, разрешении противоречий, определении приоритетов задач, согласовании финансирования, утверждении технологических решений. Комитет осуществляет координацию политики банка в области информационных технологий, рассматривает вопросы распределения ресурсов, планирования и внедрения принятых решений. Он также координирует деятельность, выполняемую различными группами, с тем, чтобы при принятии решений по информационным технологиям в первую очередь учитывались общие интересы банка. ИТ-комитет должен собираться по мере необходимости, но, как правило, для средних по размеру организаций не реже одного раза в месяц, для крупных банков - на еженедельной основе. ИТ-комитет должен состоять из представителей (руководителей) основных бизнес-направлений, ИТ-директора, представителей высшего руководства, иногда в него могут входить даже представители крупных акционеров (владельцев), хотя это не является типовой практикой. Руководить им должен представитель бизнеса, символизируя этим первичность бизнес-целей. Таким образом, через представительство в ИТ-комитете трех основных групп - высшего руководства, ИТ-менеджмента, бизнес-менеджмента (пользователей) - достигаются прозрачность деятельности в области ИТ, сбалансированность ИТ-решений и их соответствие бизнес-целям. Руководители основных подразделений банка должны быть обязательно включены в состав комитета по ИТ. Опыт показывает, что в банках, в которых не сформированы ИТ-комитеты, наблюдается расхождение мнений по вопросам информационных технологий между сотрудниками управления ИТ и пользователями программных продуктов. В большинстве случаев конфликты возникают по причине того, что как пользователи, так и сотрудники управления информационных технологий не осознают приоритеты, которые определены в деятельности другой стороны. Немаловажную роль в построении продуктивных и дружественных отношений между бизнес-подразделениями и ИТ играет сам ИТ-директор. Статус СЮ в зарубежных финансовых компаниях крайне высок. Иногда он может быть выше статуса, например, финансового директора (CFO - Chief Finance Officer). Почти всегда СЮ имеет статус члена правления. Если он может говорить на равных с потребителями технологий, то это очень помогает в налаживании правильных отношений. Поэтому иногда для улучшения взаимодействия на должность ИТ-директора назначается человек из бизнес-сферы с ИТ-опытом. Вряд ли это является панацеей, но этот пример по крайней мере хорошо иллюстрирует, что СЮ должен быть одинаково близок и к ИТ, и к бизнесу, понимать язык обеих сторон и быть своеобразным переводчиком. Это, по мнению многих экспертов, на сегодняшний день и является основной задачей ИТ-директора. Также, как уже отмечалось, важно вовлечение ИТ-менеджмента в бизнес-решения. Представители ИТ должны принимать участие в обсуждении и принятии ключевых решений относительно развития банковской деятельности, так как успешная реализация принимаемых решений во многом зависит от возможностей ИТ. Поэтому правильной практикой является участие ИТ-директора в заседаниях правления (или другого органа управления), основных комитетов как полноправного члена. Следующий момент - это построение ИТ-подразделения по принципу обслуживающей (сервисной) организации. Другими словами, организация работы внутренней ИТ-службы не должна ничем отличаться от организации работы при обслуживании сторонних клиентов. Основная цель такого построения - поднять качество обслуживания до уровня сторонних провайдеров, использовать в работе ИТ-подразделения профессиональные, промышленные подходы, уделять больше внимания риск-менеджменту. Для реализации этого подхода ИТ-подразделение составляет список своих доступных и потенциальных услуг, описывает их, определяет параметры услуг (скорость оказания, стоимость, гарантии обслуживания). Далее с каждой бизнес-единицей заключаются договора на обслуживание, так называемые SLA (Service Level Agreement) - соглашения об уровне обслуживания. Иногда они называются соглашениями о порядке взаимодействия и обслуживания. Процесс оформления SLA детально отражен в методологии ITIL. Примерная его форма приведена в приложениях
. Большинство работ в области ИТ являются уникальными и неповторяющимися. Они выполняются специально выделенными работниками и по сути представляют собой проекты со своими целями, требуемыми сроками и согласованным финансированием. Управление такими группами также должно отличаться от традиционного. Здесь нет постоянно выполняемых и периодически возникающих задач, работа конечна во времени, и основным критерием является достижение цели проекта. Для внедрения проектной формы управления необходимо разработать положение об основах проектной работы, которое должно: - включать критерии выделения проектов (например, срок и стоимость работ, вовлеченность нескольких подразделений); - определять организационный статус проекта, формирование целей и задач проекта, процедуры контроля за ходом проекта и достижением результатов, формирование и расходование бюджета, руководство проектом, двойную подчиненность сотрудников, сроки, основные типы проектов (проекты в области ИТ, внутренние проекты, общебанковские проекты и т.п.). В соответствии с утвержденными проектными подходами и проектами в организации формируется перечень проектов в области ИТ, назначаются ответственные (или рабочие группы) за каждый проект и внедряются процедуры контроля за результатами. Для эффективного функционирования проектной формы работы целесообразно разработать и внедрить систему, согласно которой рабочее время сотрудников ИТ будет учитываться с точки зрения осуществляемых видов работ и заказчиков этих работ, вовлеченности в проекты. Эти данные могут использоваться для распределения издержек ИТ-персонала по бизнес-подразделениям. Также проектная форма управления предполагает совершенно другую систему мотивации сотрудников, ориентированную на достижение конечного результата. Для реализации проектных подходов в полной мере ИТ-подразделение должно быть построено на основе матричной организационной структуры. Матричная структура - наиболее сложный и, если ее так можно назвать, современный тип организационной структуры. Она представляет собой некое совмещение традиционных структур с проектными подходами. Подобное совмещение помогает объединить все положительное, что есть в традиционных структурах и системах управления, с новейшими тенденциями. Матричной структуре свойственно двойное подчинение: с одной стороны, исполнитель участвует в каком-то проекте, с другой - он является частью функционального подразделения. Система взаимоотношений и подчиненности в структурах этого типа очень сложна, но, как показывает практика, сами по себе эти структуры весьма эффективны именно в современных условиях. Матричные структуры, сочетая в себе все преимущества функциональных и дивизиональных структур, лишены многих их недостатков. Они оптимально и быстро справляются со множеством постоянно возникающих задач, создавая для их решения отдельные проекты. Они идеально адаптируются к современной нестабильной внешней среде. Поэтому матричные организационные структуры заслуженно признаются оптимальными для кредитных организаций и особенно оправданы для организации ИТ. Однако необходимо учитывать и присущие матричным структурам недостатки, а именно: излишнюю усложненность, возникающую из-за двойного подчинения, нечеткость в вопросах разграничения полномочий между функциональными или дивизионными и проектными руководителями. Примеры матричных организационных структур банка и ИТ-подразделения приведены в приложениях
. Для осуществления оценки и анализа существующих проблем в области ИТ необходимо иметь объективную информацию по основным аспектам деятельности (количественные метрики). Такие показатели помогают отслеживать и управлять результатами деятельности по ИТ-направлению. В западной практике эти показатели часто называются KPI (Key Performance Indicators) - ключевые индикаторы выполнения. Примером KPI могут быть такие метрики, как процент проектов, не укладывающихся в сроки или бюджет; время разрешения проблемы у пользователя; средняя загрузка оборудования; рост ИТ-бюджета по сравнению с ростом операций; удовлетворенность пользователей работой ИТ-подразделения; доступность критичных ИТ-ресурсов (100% означает, что определенные ресурсы доступны все время - 24 часа х 7 дней в неделю); уровень квалификации ИТ-персонала; количество замечаний по результатам регулярных внутренних и внешних проверок ИТ; количество поддерживаемых пользователей на одного работника ИТ, количество проблем и консультаций отработанных службой обслуживания; количество инцидентов в области информационной безопасности; процент загруженности ИТ-работников (utilization) и т.д. Важно понимать, что количество показателей может быть огромным, поэтому определение того, какие из них необходимо учитывать при оценке деятельности ИТ, а какие нет, является индивидуальной задачей. Но в любом случае, определив 15-20 метрик и регулярно собирая по ним необходимую информацию, можно иметь достаточно четкое представление о ходе деятельности ИТ и осуществлять адекватное управление и контроль со стороны высшего руководства и бизнес-подразделений, периодически предоставляя им эту информацию. Важнейшая составляющая правильной организации управления ИТ - риск-менеджмент. ИТ является одной из самых высокорискованных областей деятельности и может быть сопоставима для кредитных организаций по уровню рискованности даже с финансовыми операциями. Постоянная оценка наихудшего сценария по всем направлениям, оценка вероятности его наступления и потенциального влияния - вот основы риск-менеджмента. Далее должна следовать работа по смягчению возможных последствий, минимизации влияния и снижения вероятности наступления негативного события, независимо от его природы. Невозможно подготовиться ко всему, поэтому необходимо использовать взвешенный подход, направляя максимум усилий на потенциальные события с высокой вероятностью наступления и высоким влиянием и с низкой вероятностью и высоким влиянием. Такой подход в западной практике является основой риск-менеджмента и называется Probability Impact Analysis. Основными направлениями риск-менеджмента являются: - планирование непрерывности деятельности и действий в чрезвычайных ситуациях, так называемые ВСР и DRP (Business Continue and Disaster Recovery Planning); - разделение ключевых ИТ-функций (необходимо, например, разделять функции разработки программного обеспечения, технического тестирования, тестирования функциональных возможностей и сопровождения эксплуатируемых систем); - зависимость от ключевого ИТ-персонала (в последнее время одна из наиболее часто встречающихся проблем ИТ-менеджмента); - информационная безопасность, инциденты, связанные с доступом и раскрытием конфиденциальной информации. Для минимизации рисков внедряются так называемые контрольные процедуры (Control Procedures), направляемые на предотвращение (Preventive Controls), выявление (Detective Controls) и смягчение (Corrective Controls) негативной ситуации. Еще одна составляющая правильной организации управления ИТ - необходимость документирования ИТ-процессов и банковских технологий. Традиционно именно этот момент является менее развитым в российских организациях, что неминуемо приводит к резкому увеличению рисков, полной неразберихе и абсолютной непрозрачности ИТ-подразделения и автоматически ухудшает взаимоотношения с бизнес-сферой, затрудняет оценку деятельности, снижает качество обслуживания внутренних клиентов. Для облегчения использования внутренних регламентирующих документов может быть рекомендовано применять утвержденную в рамках всей организации иерархию документов. В России пока нет устоявшихся подходов, а в международной практике часто используется иерархия внутренних документов по возрастанию степени их детализации: политика (Policy), процедура (Procedure), стандарт (Standard). Основные примеры ИТ-документов, которые должны постоянно поддерживаться и вестись в организации: * стратегия в области ИТ (IT Strategy); * техническая политика (Technology Policy); * информационная и технологическая архитектура (Information ArchiTecture); * ИТ-бюджет (IT Budget); * политика информационной безопасности (SecuriTy Policy); * процедуры получения доступа к информационным ресурсам и стандарты информационной безопасности (SecuriTy Procedures and Standards); * методология разработки программного обеспечения (System Development Life Cycle Methodology); * соглашения о взаимодействии и обслуживании бизнес-подразделений (Service Level Agreement); * порядок проведения тендеров по выбору ИТ-решений (Tender Execution Policy); * протоколы ИТ-комитета (IT commlitee minutes); * перечень регулярных операций и процессов (Batch Processes List); * перечень проектов (Projects List); * планы-графики работ по проектам и в целом по подразделению; * программная документация (руководства пользователей, администраторов, технические спецификации); * технические задания на разработку; * журнал регистрации обращений пользователей; * заявки на предоставления прав доступа, карты доступа; * результаты приемки решений пользователями (Users Sign-off). * должностные инструкции работников (Job Descriptions); * перечень эксплуатируемого программного обеспечения и техники; * описания банковских технологических процессов. Последним ключевым подходом является необходимость постоянного совершенствования ИТ-процессов. Такое совершенствование включает два аспекта. Первый - оценка уровня зрелости, которая производится на основе сравнения с другими организациями и должна быть постоянной и неотъемлемой частью ИТ-менеджмента. В международной практике этот процесс называется Benchmarking. Второй - непосредственно оптимизация деятельности. Необходимо, чтобы работа по совершенствованию не приводила к развитию нескольких "любимых" участков деятельности в ущерб всем остальным, как часто бывает в российских банках. Поэтому очень важным становится использование какой-либо методологии управления ИТ, например СblТ, которая дает возможность оценить уровень развитости ИТ в конкретной организации, не прибегая к консалтинговой помощи и не надоедая коллегам из конкурирующих структур. И далее на основе оценки текущего состояния, начиная с менее развитых направлений, можно начинать работу по совершенствованию ИТ-процессов. Рассмотрев основы построения ИТ-менеджмента в финансовых организациях в рамках первой части книги, далее мы остановимся подробнее на том моменте, который в данной главе назван первой задачей ИТ-менеджмента, - стремлении к достижению целей. Для ИТ-менеджера эту задачу поддерживает процесс стратегического планирования (или управления), который и является предметом следующей главы
. Стратегическое управление и планирование заключается в определении целей кредитной организации, превращении общих целей в конкретные направления работы, в анализе сильных и слабых сторон организации, составлении и контроле выполнения планов деятельности в различных ситуациях. Это управленческий процесс, обеспечивающий соответствие между целями банка и имеющимися у него ресурсами в условиях постоянно изменяющейся рыночной обстановки и регулирования. Цель стратегического планирования и управления - внедрение новых и развитие перспективных направлений деятельности и банковских продуктов так, чтобы они способствовали росту объема операций, приумножали доходы и увеличивали рыночную стоимость акций. Таким образом, стратегия зависит от тех целей, которые банк ставит перед собой, и способствует их скорейшему осуществлению. Для грамотного и последовательного осуществления процесса стратегического менеджмента необходимо четко сформулировать основные задачи этого процесса. Во-первых, система стратегического менеджмента решает задачу неуклонного приближения кредитной организации к тем целям, которые она ставит перед собой. Это дает положительную динамику развития и конкурентоспособности: ведь ресурсы и силы не распыляются на все сразу, а сосредоточиваются на принципиальных для достижения поставленной цели позициях. Во-вторых, система стратегического менеджмента позволяет снизить риски влияния внешней среды, поскольку обеспечивает регламентацию действий в разного рода неожиданных ситуациях (нестабильность рынков, девальвация, резко возросшая конкуренция, снижение доходности, изменение принципиальных положений законодательства) и позволяет в случае их возникновения действовать по заранее составленному плану, незначительно корректируя его в соответствии со сложившимися обстоятельствами. Таким образом, в задачи стратегического планирования входят как понимание цели деятельности того или иного банка, так и вариативность путей ее достижения. Однако решение этих двух принципиальных и очень актуальных задач осуществляется с помощью особых технологий и средств, которые предусматривает процесс внедрения стратегического планирования. Процесс внедрения стратегического планирования целесообразно разделить на следующие шесть этапов. 1. Внедрение стратегического способа мышления в среду высших менеджеров банка. На этом этапе необходимо обеспечить понимание каждым из высших руководителей необходимости и целей внедрения стратегического планирования, провести анализ мнений высшего руководства и владельцев о задачах и стратегических целях банка. На основе этих данных формулируется и фиксируется представление о роли и стратегии банка по основным направлениям деятельности. 2. Создание необходимых условий и системы оценки реализации стратегических целей и задач. Внедрение стратегического подхода невозможно без ряда необходимых условий. К ним относятся: - внедрение управления отдельными подразделениями как независимыми бизнес-единицами, деятельность которых регулируется и оценивается по рыночным принципам; - введение финансового управления, позволяющего адекватно рассчитывать потенциальную рентабельность и оценивать различные аспекты деятельности стратегических бизнес-единиц; - внедрение бюджетного планирования, являющегося средством контроля и обеспечения стратегического планирования. Помимо выполнения перечисленных условий принципиальным является также создание и внедрение системы оценок деятельности банка, которая формируется с точки зрения соответствия локальным и глобальным стратегическим целям. Именно эта система и станет в будущем основой проведения самого процесса стратегического планирования и оценки его результатов. 3. Создание инфраструктуры стратегического менеджмента. Инфраструктура стратегического менеджмента предполагает наличие: - руководителя высшего звена (желательно члена правления банка), ответственного за внедрение, контроль и оценку стратегического менеджмента; - функционирующей системы ответственности работников и руководства различных подразделений; - подразделения стратегического планирования (его численность зависит от размеров банка), в задачи которого должна входить регулярная работа по обеспечению стратегического планирования в банке (оформление и согласование стратегических планов, корректировка стратегий и целей, оценка и контроль выполнения планов, мониторинг и т.д.). 4. Формирование детального, многовариантного (в зависимости от внешней ситуации) стратегического плана и его составляющих - стратегических планов подразделений. Осуществив все описанные выше действия по внедрению стратегического планирования, проводят так называемый SWOT-анализ, который необходим для: - оценки возможного влияния внешней среды на положение организации в будущем; - выявления сильных и слабых сторон организации, открывающихся перспектив и грозящих опасностей. На основе детального анализа представлений и пожеланий руководства банка, а также данных SWOT-анализа создается развернутый стратегический план деятельности. Такой план должен быть многовариантным, то есть иметь "разветвления" в зависимости от дифференциации показателей внешней экономической среды. 5. Внедрение системы взаимно поддерживаемых целей банка, подразделения и работника. Следующим важнейшим этапом на пути внедрения стратегического планирования является создание механизма взаимодействия целей банка, целей подразделения и целей отдельно взятых работников, поскольку большинство проблем в процессе развития возникает из-за несогласованности целей внутри кредитной организации, а именно: - несогласованности личных целей руководителей и общих целей банка; - несогласованности целей подразделения и целей банка в целом (как следствие внутренней конкуренции или неадекватного перераспределения ресурсов и фондов материального стимулирования); - несоответствия реальных и заявленных целей и т.д. Такие несоответствия и противоречия важно выявлять и предотвращать, потому что они приводят к разрыву между официально представляемым и реальным положением дел и в конечном счете к отсутствию какого-либо движения вперед. Здесь становятся особенно важными тщательная работа с персоналом, продуманная и соответствующая стратегическим целям система мотивации деятельности сотрудников, подразделений и структурных единиц. Таким образом, личные цели отдельных работников, объединенных в подразделения, реализуясь, должны приводить к решению задач, поставленных перед подразделениями, а совокупность достижений подразделений в свою очередь должна способствовать достижению соответствующей стратегической цели банка. Один из типичных способов решения этой проблемы в зарубежной практике - внедрение и поддержка облегчающей достижение поставленных целей определенной корпоративной культуры с сопутствующими ей разнообразными механизмами, в том числе и вытеснением не соответствующих ей работников и руководителей. 6. Внедрение системы мониторинга и прогнозирования внешней среды и корректировки стратегий. Этот этап является последним по очереди, хотя и не последним по значению. Необходимо создать условия, при которых не только соответствующее подразделение, но и вся организация была бы вовлечена в мониторинг внешней среды. Ведь, скажем, предпочтения клиентов, их потребности, отношение к конкурентам гораздо проще выявлять работникам, непосредственно обслуживающим клиента, а не специально выделенным для этого специалистам. Последние должны заниматься анализом, обработкой и предоставлением всем заинтересованным службам внутренней информации, а также отслеживанием внешней информации. Исходя из поступающей информации соответствующим образом корректируются стратегические планы. Стратегия ИТ неотделима от бизнес-стратегии организации. Мы рассмотрели задачи и внедрение стратегического менеджмента, а теперь перейдем к основным тенденциям в экономике и стратегическом мышлении банка, которые достаточно активно меняются в настоящее время. Итак, в чем же состоят требования "новой экономики"? В чем отличия новой модели бизнеса от старой и как эти новейшие тенденции влияют на банковский бизнес? Тенденции, о которых будет рассказано ниже, практически являются аксиомами в западном мире. В российских условиях они выглядят несколько дискуссионно, хотя, безусловно, в ближайшее время они будут широко использоваться и у нас. Первой такой тенденцией является ориентация на клиента, которая достигается за счет изучения потребностей разных групп клиентов и выработки специализации. Передовые организации стремятся изучать и структурировать потребности и спрос со стороны клиентов и в соответствии с клиентскими группами корректировать свои услуги (рис. 1
). "Рис. 1. Сравнение традиционной и новой модели бизнеса"
Выбираемая организациями специализация способствует более эффективной работе с индивидуальным клиентом и в конечном счете является залогом повышения рентабельности работы с каждым отдельным клиентом и соответственно всего бизнеса. Естестественно, что только с существен ной поддержкой ИТ возможна реализация этой стратегии на практике. Также важен опыт взаимодействия клиента с банком. Этот опыт должен быть запоминающимся и, если так можно выразиться, уникальным. В современной экономике впечатления клиента становятся конечной целью. Они являются одной из главных причин выбора в пользу того или иного банка в условиях, когда стоимость услуг и набор их практически одинаковы. Рассмотрим ставший уже классическим пример, описанный Джозефом Пайном и Джеймсом Гилмором в книге "Экономика впечатлений" (рис. 2
). "Рис. 2. Пример влияния впечатлений клиента на стоимость товара в новой модели бизнеса"
Цена за одно и то же количество кофе может быть весьма разной: кофе как сырье примерно в два раза дешевле расфасованного и красиво упакованного и почти на порядок дешевле кофе как услуги (например, за чашечку кофе в кафе). Наконец, кофе как уникальное впечатление, предложенное в особенном месте и в особенной обстановке, в десятки раз дороже простых зерен, необходимых для приготовления напитка. Таким образом, самое выгодное в современной экономике - быть ближе к продаже услуг и впечатлений. Это правило распространяется и на финансовые услуги. Банк стремится построить индивидуальную систему обслуживания клиентов, предвидеть запоминающиеся акции. Он старается, чтобы его образ отличался от других банков и клиент мог выделить данный банк среди других на разных уровнях общения. Такой ориентированный на клиента подход требует централизации информации и процессов, разработки ориентированной на клиента корпоративной культуры и инфраструктуры, формирования у клиентов положительного опыта взаимодействия, который будет явно отличать данный банк от конкурентов, и последовательного обеспечения этого взаимодействия вне зависимости от используемых каналов. Другой стратегической тенденцией развития банковского бизнеса является поиск новых каналов сбыта, реализации услуг. Для этого банки используют преимущества электронных решений, технические и технологические нововведения. Ведущие компании мира все больше разворачиваются в сторону электронного бизнеса. Первые шаги в этом направлении были предприняты немногим более 7 лет тому назад, а сегодня электронный бизнес уверенно меняет облик отраслей. Все говорит о том, что электронный бизнес будет определять основные правила в сфере осуществления коммерческой деятельности уже в ближайшем будущем. Электронный бизнес существенно влияет и на деятельность компаний, занятых в сфере услуг, особенно это относится к сектору финансовых услуг. Во многих банках большинство операций уже сегодня проводится электронным способом. Но, к сожалению, шаги по внедрению электронного бизнеса зачастую недостаточно продуманы и проработаны и, как следствие, не приводят к желаемым результатам. В то же время следует отметить, что текущая экономическая ситуация несет и потенциальные угрозы финансовым организациям, а именно: - дерегулирование открывает традиционно закрытые рынки для конкуренции; - растущие потребности потребителей меняют привычные формы бизнеса; - усложняются и расширяются операции; - совершенствование технологии ускоряет требуемые темпы развития; - информация меняет основы конкуренции; - конкуренция оказывает давление на доходность; - глобализация ведет ко все большей неопределенности. Все эти моменты в конечном итоге требуют от финансовых организаций принятия активных мер. И именно е-бизнес позволяет найти решение не только многих отдельных проблем, но и проблемы снижения операционных издержек в целом. Перенос бизнеса в Интернет приносит ранее недостижимое снижение внутренних издержек. В настоящее время стоимость банковской транзакции в Интернете в США составляет в среднем около 1 цента, в то время как себестоимость транзакции по пластиковым картам равна примерно 30 центам, а при традиционном банковском обслуживании - более одного доллара. Таким образом, электронный бизнес имеет потенциал снижения издержек на два порядка, поэтому банки просто не могут игнорировать его. Но, если банкам не хватает осведомленности, присутствуют недостатки при разработке стратегии и организации, проекты в этой области зачастую обречены на неудачу. Что касается осведомленности, то банки стремятся понять, какими будут результаты развития электронного бизнеса, как этих результатов можно достичь и что нужно, чтобы дать существенный импульс развитию электронного бизнеса. В части стратегии необходимо оценить критические факторы успеха для электронного бизнеса, установить стратегические приоритеты и составить план дальнейшего развития. В части менеджмента необходимо осуществлять контроль проектов и управлять деятельностью в соответствии с измеримыми целями, обеспечивать требуемый уровень поддержки со стороны руководства организации и управлять рисками. Таким образом, чтобы быть успешными, банкам необходимо помимо всего прочего учитывать новую стратегическую роль ИТ для бизнеса. Итак, что же такое ИТ-стратегия и в чем она должна состоять? ИТ-стратегия - это детальное описание планов организации в области информационных технологий, направленных на поддержку реализации бизнес-стратегии и достижение конкурентного преимущества наиболее оптимальным и действенным способом. Компании, ведущие стратегическое планирование в области ИТ, как правило (по данным статистики), достигают более высокого качества своих ИТ-услуг и более низкой их стоимости. Эти два критерия (качество и стоимость) можно назвать базовыми при оценке деятельности и развития ИТ. Если рассматривать стратегическое планирование ИТ в целом, то это многосторонний процесс. Перечислим составляющие его блоки. Организация - внутренняя структура, взаимодействие с другими подразделениями, распределение полномочий. Внутренние процессы - направления совершенствования, эффективность, качество и стабильность. Архитектура - целевая техническая, программная, сетевая и телекоммуникационная архитектура организации, ее гибкость, соответствие последним требованиям. Приложения - основные системы, поддерживающие бизнес-процессы. (Соответствует ли используемая система основным требованиям и стратегическим целям организации? Сможет ли она поддерживать требования в течение ближайших 5-10 лет?) Централизация и машта-бируемость приложений, поддержка увеличенного объема операций и возникающих новых продуктов, тенденции в программной индустрии. Персонал - квалификация, обучение, документирование деятельности, мотивация, системы стимулирования, карьерный рост. Стандарты - использование стандартов и методологий, сертификация подходов, решений, сотрудников, разработка внутренних методик и соответствие им. Стратегическое партнерство - основные направления развития партнерских связей, поставщики, вендоры, области использования аутсорсинга. Риски и контроль - процедуры контроля, внутренний и внешний аудит, мониторинг со стороны менеджмента, контрольные отчеты и показатели деятельности, управление рисками. Сравнительный анализ - сопоставление с аналогичными организациями, использование статистических данных, исследование тенденций. Планы - ключевые планы в области развития ИТ по различным направлениям (в том числе и перечисленным выше) на ближайшие несколько лет. Список проектов и приоритетов по ним. Финансы - бюджет, анализ и совершенствование экономических показателей деятельности ИТ, окупаемость инвестиций, распределение финансирования по основным проектам. По каждому из этих направлений рассматриваются текущая ситуация, цели, стратегия, тактические подходы для достижения продекларированных результатов. Рассмотрев основные направления стратегического планирования ИТ, остановимся на типовых (или наиболее распространенных) идеях, лежащих в основе ИТ-стратегий. Такой ИТ-стратегией "для всех" является создание технологической платформы для управления взаимоотношениями с клиентами (CRM - Customer Relashinships Management), необходимость которой вытекает из сказанного выше о бизнес-стратегии в современных экономических условиях. В общем случае такие системы поддерживают инфраструктуру, которая позволяет собирать данные обо всех клиентах, анализировать информацию о потребителях услуг, группировать клиентов на основе особенностей их поведения и индивидуальных предпочтений, разрабатывать продукты и услуги для отдельных потребителей или для групп людей, схожих по своим интересам и предпочтениям, и в конечном счете предлагать индивидуализированное обслуживание. На рис. 3
представлена общая схема подобных решений, которая демонстрирует их сложность. Другой достаточно прогрессивной и распространенной ИТ-стратегией является построение ИТ по принципам сервисной организации. Эта стратегия направлена на совершенствование внутренних организационных процессов и взаимодействия с бизнес-подразделениями. Основная идея состоит в том, что если внутренняя служба ИТ будет использовать в своей работе подходы внешних компаний, то это позволит существенно поднять качество ее работы и снизить издержки. Такая стратегия предполагает: - маркетинг и продажу технологических решений. Сервисно ориентированная ИТ-структура способна продавать свои решения и услуги сторонним организациям; - внутренний маркетинг - необходимость строить отношения с подразделениями по законам маркетинга, фактически "продавая" свои подходы коллегам по организации; - умение идентифицировать технологические проекты в организации и выступать с инициативами по их разработке и обоснованию, прогнозировать востребованность своих услуг (сервисов); - необходимость отслеживать тенденции в индустрии и технологии, учитывая в своей работе поддержание ее конкурентоспособности и возможного замещения внешней компанией; - соответствие стандартам качества и требованиям заказчика; - формализацию и обязательное документирование при осуществлении работ; - наличие квалифицированного персонала, способного переквалифицироваться, освоить работу в новой области и заменить другого сотрудника; "Рис. 3. Построение системы CRM"
- умение оценивать и планировать ресурсы, необходимые для выполнения работы и точного определения сроков и этапности проектов; - управление персоналом должно быть построено с учетом специфики работы в ИТ-индустрии; - умение работать с партнерами, которые могут предоставить помощь в тех областях, где имеется недостаток ресурсов или навыков, или в случаях, когда работа партнера более эффективна с экономической или временной точки зрения. Рисунок 4
дает возможность сравнить подходы к организации ИТ-службы - традиционной и построенной по принципам сервисной или обслуживающей организации. Безусловно, процесс выработки стратегии является сугубо индивидуальным, однако ИТ-стратегии (по крайней мере передовых банков) могут иметь много схожих подходов, так как учитывают передовой опыт и базируются на общих тенденциях развития ИТ. "Рис. 4. Сравнение подходов к организации ИТ-службы"
Основные тенденции развития ИТ
Приведем несколько схем (рис. 5-10
), которые иллюстрируют основные тенденции в развитии менеджмента информационных технологий на основе специализированного международного источника Forrester Research. Inc. Эти схемы выбраны нами в случайном порядке, а ценны тем, что реально существуют. Поэтому рекомендуется учитывать их при формировании собственной ИТ-стратегии. Первой тенденцией, которую хотелось бы отметить, является повышение значения экономических параметров при принятии решений по выбору проектов. Представленная на рис. 5
схема показывает, что в 80% случаев формальным обоснованием начала технологического проекта являются параметры возврата инвестиций или срок окупаемости проекта. "Рис. 5. Тенденции в подходах к обоснованию проектов"
Другие тенденции касаются изменения роли ИТ-подразделения. Представленные на рис. 6
данные иллюстрируют, что большинство респондентов отмечают возрастание сотрудничества с бизнес-подразделениями. Также отмечаются такие изменения, как усиление централизации и контроля, направленности на результаты бизнеса и внедрение новых технологий и решений. Только около 10% респондентов отмечают отсутствие каких-либо изменений. Следующий график (рис. 7
) иллюстрирует все более активное вовлечение высшего руководства организаций в процесс принятия ИТ-решений. Как считают 40% респондентов, требуют обязательного обоснования и согласования с высшим руководством любые проекты в области ИТ. А необходимость такого согласования для проектов стоимостью свыше $100 тыс. признают около 87% опрошенных. "Рис. 6. Изменение роли ИТ-подразделения"
"Рис. 7. Вовлечение высшего руководства в процесс принятия ИТ-решений"
В последнее время наблюдается существенное повышение доли сторонних услуг, организации все чаще используют аутсорсинг. При этом они стремятся передавать сторонним организациям практически все неключевые для бизнеса функции (рис. 8
). Сегодня в среднем 28% средств ИТ-бюджета достаются сторонним поставщикам решений и услуг. Около 40% опрошенных отмечают, что они передали (полностью или частично) другим поставщикам такие свои технологические функции, как разработка, поддержка и эксплуатация приложений. "Рис. 8. Использование сторонних услуг (аутсорсинг)"
Следующая схема (рис. 9
) показывает тенденции в изменении структуры ИТ-службы и базовых показателей оценки ее деятельности. Среди основных тенденций отмечаются: увеличение централизации, стремление больше соответствовать требованиям бизнеса, увеличение количества используемых стандартов для целей контроля ИТ. В большинстве банков обработка данных осуществляется централизованно с целью снижения затрат и повышения эффективности процессов. Кроме того, существуют и другие преимущества в пользу принятия такого решения: легкость управления, контроля, организации информационной безопасности, подготовки управленческой отчетности; отсутствие дублирования информации; уменьшение затрат на обслуживание оборудования; сокращение персонала; стандартизация и единообразие системных и бухгалтерских процедур. "Рис. 9. Тенденции в изменении структуры и оценки ИТ-подразделений"
С точки зрения оценки деятельности использование тактических показателей отмечается большинством как наиболее часто встречающийся подход, около трети компаний отмечают показатели эффективности бизнеса и снижения издержек. Еще одной показательной тенденцией в управлении информационными технологиями является увеличение скорости принятия решений при покупке ИТ-решений: подавляющее большинство всех решений в этой области принимаются менее чем за три месяца (рис. 10
). "Рис. 10. Скорость принятия ИТ-решений"
Составление стратегического плана
Как оформить ИТ-стратегию в виде документа? Как этот документ должен выглядеть? На какой период он должен составляться? Какие требования предъявляются к стратегическому плану? Далее мы попытаемся ответить на эти вопросы. Как видно из сказанного выше, ИТ-стратегия не может быть составлена без понимания бизнес-стратегии и должна на ней базироваться. Стратегический план целесообразно составлять в виде двух документов - долгосрочной стратегии и краткосрочной. Долгосрочная стратегия составляется на 3-5 лет и включает соответствующие задачи и цели, краткосрочная - на срок от 1 до 3 лет. Оба документа должны регулярно обновляться. Для долгосрочного документа это может происходить на полугодовой основе, для краткосрочного - на ежеквартальной. Все обновления производятся в тесном взаимодействии с бизнес-менеджерами и согласовываются с высшим руководством организации. Стратегия в области ИТ утверждается высшим руководством по результатам совместного обсуждения с руководителями ИТ- и бизнес-подразделений. Иногда это обсуждение проходит в форме заседаний информационно-технологического (или технического) комитета. Также важнейшим элементом стратегического планирования является контроль исполнения. Стратегия не должна быть декларативным документом, и основным способом достижения этого является контроль ее исполнения со стороны высшего руководства банка (информационно-технологического комитета).
Управление экономическими аспектами ИТ в банках
Буквально за несколько последних лет информационные технологии (ИТ) стали не только важной частью бизнеса, но и очень затратной его частью. Сегодня в некоторых банках расходы на ИТ составляют существенную часть бюджета, иногда доходя до 30%, и могут являться наиболее крупной статьей издержек, обгоняя административно-хозяйственные расходы, расходы на аппарат управления и другие традиционно крупные статьи в банках. Но как относиться к этим затратам? Каковы реальные издержки на автоматизацию? Как сделать так, чтобы огромные затраты приносили реальную отдачу, поддающуюся измерению и отражению в управленческой отчетности? То есть как управлять экономическими аспектами ИТ? Ответы на эти вопросы принципиальны не только для финансовых директоров и ИТ-менеджеров, но и для высшего руководства любого банка. Очевидно, что необходим особый подход к интеграции ИТ-издержек в общую модель финансового управления банка. Рассмотрим один из важнейших блоков управления информационными технологиями, который называется экономика ИТ (IT Economy). Экономика ИТ направлена на обеспечение функционирования экономических механизмов регулирования ИТ-процессами. Ее основные задачи - оптимизация издержек и помощь высшему руководству в принятии решений в области развития ИТ. К основным экономическим механизмам регулирования ИТ в банке (элементам системы управления экономическими аспектами деятельности ИТ) можно отнести следующие: * управление инвестициями в ИТ (Manage the IT Investment); * бюджетное планирование (Budgeting); * распределение издержек по подразделениям (Costs Allocation); * сравнительный анализ издержек (Costs Benchmarking); * структурный анализ издержек (Cost Structured Analysis); * трендовый анализ издержек (Cost Trend Analysis); * управление ценностью информационных технологий (Technology Value Management). Далее мы детально рассмотрим эти составляющие, но прежде необходимо сформулировать, что в конечном счете может дать банку грамотная система управления экономикой ИТ. Другими словами: зачем все это нужно? По нашему мнению, основные плюсы заключаются в возможности: - оптимизировать затраты; - повысить эффективность и контролируемость; - достичь прозрачности; - улучшить взаимодействия с бизнес-подразделениями; - обеспечить сбалансированное развитие и, в конечном счете, достичь конкурентных преимуществ. По своей сути расходы на ИТ являются инвестициями, и если организация не понимает этого, то она может столкнуться как с финансовыми, так и с ИТ-проблемами. Управление инвестициями в ИТ состоит в приравнивании ИТ-проектов к прочим инвестиционным проектам организации. Расходы на ИТ должны рассматриваться как внутренние инвестиции с обязательной подготовкой необходимых документов, расчетов и обоснований. Как и для других инвестиций, для ИТ-проектов необходимо определение срока окупаемости, жизненного цикла решения (программы, оборудования). Ни один проект не должен начинаться без соответствующих финансовых расчетов и обоснований. В противном случае неадекватная инвестиционная политика может привести к бюджетному дефициту (например, недостатку средств для завершения проекта), риску конфликта инвестиций, а также к неэффективному использованию ресурсов. В случае отсутствия предварительного планирования в области инвестиций в ИТ возникает риск того, что высшее руководство недооценит их значимость для деятельности и примет управленческие решения, не владея реальной информацией об объеме инвестиций в ИТ. Практическими шагами в направлении развития управления инвестициями в ИТ могут быть следующие: * определение ответственных за этот процесс сотрудников и руководителя; * разработка и внедрение методики расчета окупаемости ИТ-инвестиций с финансовой и нефинансовой точек зрения; * внедрение системы показателей в области ИТ и алгоритм их расчета (ТСО (Total Cost of Ownership) - общая стоимость владения, РВ (Payback Period) - период самоокупаемости, NPV (Net Present Value) - чистая приведенная стоимость, IRR (Internal Rate of Return) - внутренняя норма рентабельности, ROI (Return on Investment) - доход на инвестицию и т.д.; * обязательная оценка возможных альтернативных вариантов инвестиций в ИТ; * периодический анализ передового опыта отрасли при выборе инвестиций в области ИТ; * постоянный процесс совершенствования инвестиционной политики в области ИТ. К тому же при осуществлении инвестиционной политики можно рекомендовать проанализировать следующие показатели: доля ИТ-проектов (в общем числе), не укладывающихся в бюджет; доля ИТ-проектов, для которых не производилась предварительная оценка эффективности инвестиций; доля ИТ-проектов, которые после внедрения не достигли требуемых инвестиционных показателей (нормы рентабельности и времени самоокупаемости); число ИТ-проектов, при осуществлении которых возникли инвестиционные конфликты, несмотря на наличие утвержденного бюджета (недостаток или несвоевременность инвестиций); время между возникновением финансового отклонения в осуществлении проекта и решением этой проблемы руководством; доля ИТ-проектов, которые после внедрения так и не достигли требуемых инвестиционных целей. Бюджетное планирование или бюджетирование - это процесс формирования и контроля исполнения детализированного бюджета расходов по отдельным областям деятельности. Эффективный процесс бюджетирования предполагает этапы планирования, оценки выполнения плана и контроль за расходами. Отсутствие эффективного бюджетирования может привести к тому, что планирование ИТ не будет соответствовать стратегическим планам предприятия. Также это приведет к отсутствию критериев оценки результатов деятельности ИТ и контроля за расходами ИТ. Процесс бюджетировния ИТ помогает достигнуть соответствия ИТ и бизнес-задач. Бюджеты составляются, как правило, на год, квартал и помесячно. Для каждого срока существуют два типа бюджетов. Первый - это прогнозируемый, или плановый, бюджет, являющийся основным финансовым ориентиром при осуществлении оперативного управления. Второй - это реальный бюджет, который строится уже по результатам деятельности после завершения определенного временного периода. Плановые бюджеты могут строиться по следующей схеме. На основании годового бюджета разрабатываются более детальные квартальные, на основании которых формируются помесячные бюджеты, являющиеся еще более детализированными. Для средних банков можно рекомендовать формировать ежегодный бюджет и его поквартальное распределение. В крупных организациях это может быть затруднено, поэтому там вполне приемлемо использование годовых бюджетов. Реальные бюджеты формируются в обратном порядке. Задача управления в этой ситуации - максимально сблизить оба типа бюджетов. Необходимым требованием к структуре бюджетов является их постатейная детализация. Это может быть индивидуально разработанная в целях бюджетного планирования система признаков поступлений и расходов, или, как их еще называют, статей. Часто для бюджетного планирования используют статьи управленческого учета. Система признаков должна быть наглядна и понятна, поэтому она не должна строиться с применением стандартных признаков бухгалтерского учета. Количество признаков строго ограничено, так как излишняя детализация усложняет понимание и мешает наглядному оформлению бюджетов. Деление на конкретные статьи расходов и поступлений зависит от выбранной модели и утвержденных принципов бюджетирования ИТ. В качестве примера рассмотрим некоторые статьи расходов "верхнего уровня", определяющиеся следующими признаками: * помещения: - аренда; - мебель, стойки; - обслуживание; * компьютерное оборудование: - персональные компьютеры; - серверное оборудование; - периферия; * телекоммуникации: - локальная сеть; - Интернет; - телефония; * программное обеспечение: - системное; - прикладное; * персонал: - зарплата; - обучение и сертификация сотрудников; - социальный пакет; * внешние услуги: - консалтинговые; - технические; * административные издержки. Названные статьи в зависимости от потребностей и особенностей конкретного банка могут расширяться по количеству основных признаков и по степени детализации каждого из них. С точки зрения бюджетирования важной составляющей этого процесса должны являться процедуры консолидации бюджетов, механизмы разрешения бюджетных конфликтов, внесения изменений в бюджеты, контроль исполнения бюджета, что недостаточно развито в большинстве банков. Также важной составляющей процесса бюджетирования является система мотивации сокращения издержек. В бюджете следует определить статьи, которые подлежат потенциальной экономии, и статьи с фиксированной суммой. При недорасходе средств по первому типу статей должен включаться механизм стимулирования (% от сэкономленных ресурсов). Бюджетирование позволяет существенно повысить контролируемость расходования средств, что также помогает снизить затраты. Неоспоримым достоинством бюджетного планирования как такового является то, что в процессе оперативной деятельности отдельных подразделений и банка в целом оно является автоматическим механизмом контроля над финансовыми потоками, регулирует их и стимулирует активную деятельность по оптимизации затрат и увеличению доходов. Этот механизм действует независимо от мнений отдельных руководителей или исполнителей, а иногда и вопреки им. Он может функционировать сам по себе, даже когда за ним нет постоянного жесткого и строгого контроля, достаточно, например, просто наличия серьезных наказаний за нарушение бюджетной дисциплины. Еще одним важным экономическим механизмом регулирования ИТ-процессов является распределение издержек, связанных с ИТ по бизнес-подразделениям. Все издержки ИТ, которые являются обслуживающей структурой, должны распределяться по бизнес-подразделениям, включая: - оборудование; - программное обеспечение; - телекоммуникации; - зарплату ИТ-специалистов; - административные издержки и прочие расходы. Правда, необходимо сразу оговориться, что эта мера имеет смысл только в том случае, если в банке вообще ведется финансовая модель управления, использующая распределение издержек между функциональными подразделениями и оценки их деятельности с учетом такого распределения. Этот механизм позволяет существенно повысить контролируемость расходов со стороны бизнес-подразделений, так как, если ИТ-расходы будут уменьшать их финансовый результат, они волей-неволей будут вовлечены в принятие решений по инвестициям и будут контролировать их адекватность и эффективность. Одной из главных проблем при организации распределения ИТ-издержек между остальными подразделениями является расчет стоимости услуг ИТ. Разработка оптимальной модели расчета стоимости услуг ИТ осложняется тем, что требуется весьма существенная их "настройка" и обкатка в процессе реальной работы, для того чтобы результаты такого распределения учитывали специфику работы и использования ИТ в различных бизнес-процессах. Так, например, если пойти по простейшей модели и распределять затраты пропорционально количеству персональных компьютеров, то может возникнуть ситуация, когда ИТ-затраты двух подразделений примерно равны, так как равно количество компьютеров, однако объем операций и доходы отличаются во много раз, что будет искажать реальный финансовый результат работы подразделений и в конечном счете подорвет доверие ко всей системе бюджетирования в банке. Поэтому необходимо, чтобы модель распределения затрат учитывала не только количество компьютеров, но и многие другие факторы. Такими факторами могут быть: объем операций, используемые приложения, частота обращений в службу поддержки, объем использования дискового пространства и т.п. Издержки по задачам, связанным с деятельностью одного подразделения, не должны распределяться по другим подразделениям. На практике наиболее редко встречается распределение издержек, связанных с ИТ-персоналом. По непонятным причинам российскими банками это воспринимается как весьма сложная процедура. Тем не менее без распределения таких издержек по бизнес-подразделениям вся система распределения становится неполной и неэффективной, так как затраты на ИТ-персонал являются одной из крупнейших статей ИТ-расходов и к тому же не очень прозрачной. Но как организовать такой процесс? Существует простой способ, повсеместно используемый в западной практике. Каждой работе и каждому подразделению присваивается цифровой код (Charge Code). Любой работник ИТ, работая над какой-либо задачей, в своем персональном отчете о проделанной работе и использованном времени (Time Sheet) должен проставлять код работы и затраченное время. Такие отчеты (Time Sheet) готовятся периодически - как правило, еженедельно. Используя простейшую автоматизацию, можно добиться того, что они будут обрабатываться автоматически и на их основе будут производиться финансовые расчеты с подразделениями или сторонними организациями, в случае если ИТ-служба оказывает какие-либо услуги сторонним организациям. Также этот механизм может быть очень полезным для контроля загрузки ИТ-специалистов. Стоит отметить, что существует и другой подход. Он состоит в том, что ИТ-служба получает статус бизнес-подразделения, которое продает свои услуги (сервисы) другим, исходя из своих затрат и определенной нормы рентабельности. Другими словами, ИТ из центра затрат становится центром прибыли. При такой схеме организации бюджетного планирования происходит попытка смоделировать рыночные отношения посредством взаимодействия бюджетных единиц и финансовых расчетов между ними. По нашему мнению, этот подход тоже эффективен для регулирования ИТ и по сути мало чем отличается от описанного выше, так как также переносит издержки ИТ на бизнес-подразделения и повышает их вовлеченность в принятие ИТ-решений - именно они определяют, покупать или не покупать. Важным в управлении финансовыми аспектами деятельности ИТ является анализ расходов, к основным составляющим которого относятся: - сравнительный анализ издержек (Costs Benchmarking) - сравнение ИТ-издержек и агрегированных показателей с другими организациями; - структурный анализ издержек (Cost Structured Analysis) - анализ и контроль за соотношением между основными блоками расходов; - трендовый анализ издержек (Cost Trend Analysis) - изменение расходов во времени и в сравнении с ростом общих доходов или объема операций компании. Анализ может делаться на основе внутренних данных, которые должны накапливаться внутри организации, а также на основе общепризнанных международных источников*(2)
. Данные информационные ресурсы содержат огромное количество статистической и аналитической информации по затратам на информационные технологии, персонал. Они включают специализированные тематические обзоры экспертов. Все это позволяет сравнить практически любой аспект деятельности ИТ с организациями данного сектора экономики и приблизительно такого же размера, прогнозировать затраты и быть готовым к изменяющимся условиям и экономическим тенденциям в области ИТ. Например, в рамках сравнительного анализа могут рассматриваться показатели, приведенные в табл. 1-3
. ИТ-затраты на одного сотрудника (в долларах)
┌─────────────────┬────────────────────┬──────────────────┬─────────────┐ │Суммарные данные │ За год │ За три года │За десять лет│ │по всем отраслям │ (2001) │ (1998-2000) │ (1991-2000) │ ├─────────────────┼────────────────────┼──────────────────┼─────────────┤ │25 процентиль │ 4,5│ 5,6│ 7,2│ ├─────────────────┼────────────────────┼──────────────────┼─────────────┤ │Медианна │ 10,2│ 15,2│ 17,1│ ├─────────────────┼────────────────────┼──────────────────┼─────────────┤ │75 процентиль │ 29,6│ 40,4│ 44,6│ └─────────────────┴────────────────────┴──────────────────┴─────────────┘ Доля ИТ-бюджета от общих доходов (в %)
┌─────────────────┬─────────────────┬────────────────┬──────────────────┐ │Суммарные данные │ За год │ За три года │ За десять лет │ │по всем отраслям │ (2001) │ (1998-2000) │ (1991-2000) │ ├─────────────────┼─────────────────┼────────────────┼──────────────────┤ │25 процентиль │ 4 900│ 3 400│ 2 100│ ├─────────────────┼─────────────────┼────────────────┼──────────────────┤ │Медианна │ 12 900│ 10 500│ 6 800│ ├─────────────────┼─────────────────┼────────────────┼──────────────────┤ │75 процентиль │ 33 300│ 31 700│ 15 800│ └─────────────────┴─────────────────┴────────────────┴──────────────────┘ Количество поддерживаемых пользователей сотрудником ИТ
┌─────────────────┬──────────────────┬────────────────┬─────────────────┐ │Суммарные данные │ За год │ За три года │ За десять лет │ │по всем отраслям │ (2001) │ (1998-2000) │ (1991-2000) │ ├─────────────────┼──────────────────┼────────────────┼─────────────────┤ │25 процентиль │ 0,49 │ 0,47 │ 0,69 │ ├─────────────────┼──────────────────┼────────────────┼─────────────────┤ │Медианна │ 1,36 │ 1,42 │ 1,61 │ ├─────────────────┼──────────────────┼────────────────┼─────────────────┤ │75 процентиль │ 2,78 │ 3,51 │ 4,38 │ └─────────────────┴──────────────────┴────────────────┴─────────────────┘ Основная задача структурного анализа издержек - подтвердить, что ИТ развивается адекватно, без перекосов. Так, например, российские банки по сравнению с зарубежными существенно больше тратят на оборудование. Самой крупной статьей в зарубежных банках является персонал. Расходы на программное обеспечение также составляют меньшую сумму для российских банков (по понятным причинам). Считается, что нормальным является равенство основных трех групп расходов: оборудование, софт, персонал (включая услуги). Ниже приведены данные, подтверждающие сказанное (табл. 4
)*(3)
. Распределение бюджетов ИТ в финансовых организациях (в %)
┌──────────────────────┬─────────────┬────────────────┬─────────────────┐ │ Расходы на ИТ │ За год │ За три года │ За десять лет │ │ │ (2001) │ (1998-2000) │ (1991-2000) │ ├──────────────────────┼─────────────┼────────────────┼─────────────────┤ │Мэйнфрэймы │ 7,7 │ 8,8 │ 9,1 │ ├──────────────────────┼─────────────┼────────────────┼─────────────────┤ │Системы среднего│ 3,8 │ 4,3 │ 2,7 │ │уровня │ │ │ │ ├──────────────────────┼─────────────┼────────────────┼─────────────────┤ │Сетевые сервера │ 9,6 │ 9,3 │ 5,2 │ ├──────────────────────┼─────────────┼────────────────┼─────────────────┤ │Сетевая инфраструктура│ 7,5 │ 8,5 │ 6,5 │ ├──────────────────────┼─────────────┼────────────────┼─────────────────┤ │Рабочие станции,│ 9,8 │ 7,6 │ 6,3 │ │персональные/портатив-│ │ │ │ │ные компьютеры │ │ │ │ ├──────────────────────┼─────────────┼────────────────┼─────────────────┤ │Операционные системы и│ 6,9 │ 5,2 │ 4,9 │ │системное ПО │ │ │ │ ├──────────────────────┼─────────────┼────────────────┼─────────────────┤ │Прикладное ПО │ 7,1 │ 5,7 │ 5,5 │ ├──────────────────────┼─────────────┼────────────────┼─────────────────┤ │Услуги сторонних│ 4,3 │ 8,3 │ 11,2 │ │организаций │ │ │ │ ├──────────────────────┼─────────────┼────────────────┼─────────────────┤ │Затраты на персонал │ 33,2 │ 32,6 │ 39,8 │ ├──────────────────────┼─────────────┼────────────────┼─────────────────┤ │Общехозяйственные │ 5,2 │ 4,8 │ 4,9 │ │расходы │ │ │ │ ├──────────────────────┼─────────────┼────────────────┼─────────────────┤ │Расходные материалы │ 2,4 │ 2,3 │ 1,8 │ ├──────────────────────┼─────────────┼────────────────┼─────────────────┤ │Обучение │ 2,5 │ 2,6 │ 2,1 │ └──────────────────────┴─────────────┴────────────────┴─────────────────┘ Составляющими трендового анализа могут быть различные показатели, но самым распространенным является изменение бюджета. В табл. 5
представлены данные о тенденции изменения ИТ-бюджетов*(4)
. Изменение бюджетов ИТ в финансовых организациях (в %)
┌──────────────────────┬───────────────┬────────────────┬───────────────┐ │ Бюджет ИТ │ За год │ За три года │ За десять лет │ │ │ (2001) │ (1998-2000) │ (1991-2000) │ ├──────────────────────┼───────────────┼────────────────┼───────────────┤ │Остался без изменений │ 21,4 │ 27,5% │ 13,8% │ ├──────────────────────┼───────────────┼────────────────┼───────────────┤ │Уменьшился │ 10,7 │ 15,4 │ 12,5 │ ├──────────────────────┼───────────────┼────────────────┼───────────────┤ │Увеличился │ 67,9 │ 57,1 │ 73,7 │ └──────────────────────┴───────────────┴────────────────┴───────────────┘ Даже при отсутствии международной статистики трендовый анализ применим и востребован. Так, например, очень полезно проследить изменение бюджета во времени и выяснить, с чем связаны его рост или падение. Какую ценность привносят информационные технологии в бизнес и как ее посчитать? Этот вопрос волнует многих. В международной практике ответ на него ищут, прежде всего, в плоскости акционерной стоимости компании. Считается, что помимо внутренней ценности (снижение ручного труда, повышение скорости обслуживания, удобство работы, возможность принимать взвешенные решения на основе реальной информации и т.п.) ИТ имеют и огромный внешний потенциал - они способны приносить прямой доход путем поднятия акционерной стоимости или капитализации компании. Поэтому такое направление ИТ-менеджмента, как управление ценностью ИТ (IT Value Management), все больше входит в практику работы прогрессивных организаций. Управление ценностью ИТ состоит в оценке привлекательности ИТ-решений с точки зрения их влияния на бизнес в широком смысле слова, с учетом их влияния на капитализацию, прозрачность организации, и активном использовании этой привлекательности для улучшения экономических показателей деятельности. Использование этого экономического механизма уникально тем, что позволяет по-другому взглянуть на природу ИТ-затрат. Так, например, одним из основных стимулов внедрения крупной информационной системы ведущего разработчика может быть желание поднять стоимость акций при успешном завершении проекта. Рассмотрим основные механизмы повышения акционерной стоимости банка с помощью информационных технологий (то, что является мотивом для ее повышения). Маркетинговый эффект состоит в том, что информация о начале или тем более успешном завершении ИТ-проекта, являясь положительной новостью на рынке, существенно повышает привлекательность организации и создает ее позитивный образ. Связано это с тем, что новые технологии и прогресс воспринимаются большинством как синонимичные понятия. Стратегические преимущества - использование банками современных информационных технологий может давать им стратегические преимущества перед недостаточно развитыми с технологической точки зрения банками. Сокращение издержек - традиционно считается, что внедрение ИТ несет сокращение операционных расходов и расходов на персонал, а это положительно сказывается на прочих финансовых показателях. Повышение прозрачности (транспарентности) и контролируемости в последнее время приобретает все большее значение, так как такие негативные явления в деятельности кредитных организаций, как ошибки, несанкционированные действия сотрудников в информационных системах, злоупотребления, приносят вполне ощутимые потери и уже давно являются не исключительным, а скорее ординарным явлением, присущим бизнесу как таковому и в особенности банковскому бизнесу. Поэтому повышению прозрачности и контролируемости, что может достигаться с помощью современных информационных систем и специальных технологий, уделяется повышенное внимание. Операционная эффективность - повышение общей операционной эффективности, включая скорость обработки операций, возможность наращивания объема операций, удобство технологии работы, низкую зависимость от персонала, проработанность нестандартных ситуаций. Повышение качества обслуживания клиентов - за счет удобного доступа к необходимой информации, эффективным коммуникациям возможно повышение качества обслуживания клиентов. Расширение ассортимента продуктов - новые информационные технологии не только поддерживают бизнес, на зачастую могут и рассматриваться как элемент развития бизнеса, так как, например, для недостаточно развитых банков внедрение современной международной автоматизированной системы дает возможность улучшить технологию работы и расширить продуктовый ряд, предлагая примеры реализации банковских услуг из новой АБС. Повышение уровня информационной безопасности - компьютерные преступления все более входят в нашу жизнь и несут большой риск для организаций, поэтому эффективная система их выявления и предотвращения, функционирующая в банке, повышает его привлекательность. Из этого списка мы бы выделили в первую очередь маркетинговый эффект, так как в отличие от остальных пунктов он практически стопроцентно достижим. Действительно, все остальные пункты являются скорее ожиданием, вероятностными характеристиками и не всегда в полном объеме достигаются в процессе внедрения ИТ. Мы рассмотрели экономику ИТ - новое и в то же время одно из самых активно развивающихся направлений ИТ-менеджмента, который дает ответы на простые, но важные вопросы: сколько нам стоит добраться до нашей цели и во что нам обойдется оставаться на месте? Необходимо отметить, что помимо необходимости уделять большое внимание экономике ИТ через описанные механизмы очень важно доведение результатов анализа экономических аспектов деятельности ИТ до высшего и среднего руководства, так как именно они вместе с ИТ-директором должны являться потребителями этой информации. Также, с учетом сказанного в разделе "Управление ценностью ИТ", необходимо доведение части информации и до внешних пользователей, что будет способствовать развитию всей организации. Если руководство приходит к выводу, что используемые в настоящее время ИТ-решения не полностью удовлетворяют потребностям банка, то оно считает необходимым внедрение новых решений. Но как получить необходимую и достаточную информацию для принятия правильного и взвешенного решения по такой сложной проблеме, как, например, выбор информационной системы для автоматизации комплекса банковских операций и системы управления банком? Ведь нередко проекты в этой области осуществляются с задержками по срокам, связаны с перерасходом бюджета или вообще (после вложения огромных ресурсов и временных затрат) признаются неудачными. Как в этой связи минимизировать риски и все-таки добиться результата? На эти и другие вопросы мы постараемся ответить в рамках данной статьи, рассматривая выбор решений на примере самого крупного элемента банковских технологий - АБС. Анализ целесообразности, осуществимости, известный в западной практике как процесс Feasibility Study, является обязательной составляющей начальной стадии всех проектов по покупке или разработке системы автоматизации: на основе оценки имеющейся информации принимается решение о покупке новой сторонней системы автоматизации или ее разработке собственными силами. Результатом анализа может быть и вывод об отсутствии адекватных решений, их недостижимости или необходимости отложить процесс замены системы. Также производится анализ экономической, технической, технологической и социальной целесообразности нового решения. К сожалению, в российской практике этот процесс редко бывает формализован, и решение о покупке или разработке принимается без анализа соответствующих критических факторов и всех аспектов, что существенно повышает риски проектов автоматизации. До начала проекта банку необходимо найти четкие ответы на следующие вопросы: * Каковы временные рамки для процесса выбора, внедрения и возможной эксплуатации решения? * Насколько новое решение действительно продиктовано требованиями бизнеса и существуют ли альтернативные варианты? * Что необходимо (и возможно) предпринять, чтобы существующая система (Legacy System) удовлетворила новым задачам и реалиям? * Есть ли на рынке решения, способные удовлетворить требованиям банка? * Какова примерная стоимость собственной и сторонней разработки? * Соответствует ли замена информационной системы общей стратегии банка? * Каковы основные риски, с которыми столкнется банк при том или ином сценарии? Далее должна быть обоснована целесообразность и осуществимость с экономической, технической, технологической (операционной) и социальной точек зрения. Расчет экономической целесообразности включает сопоставление возможных затрат и потенциальной экономической выгоды от использования нового решения. Для этого могут анализироваться такие параметры, как: - период окупаемости системы; - чистая приведенная стоимость; - норма рентабельности; - общая стоимость владения и др. Цель всего этого процесса - хотя бы примерно оценить экономическую эффективность решения. Техническая осуществимость состоит в оценке адекватности существующей технической и телекоммуникационной базы для нового решения. При ее недостаточности требуется дополнительная оценка возможных сценариев развития технической инфраструктуры, стоимости и времени таких изменений. Технологическая (или операционная) целесообразность включает оценку возможных плюсов от использования новой системы - повышения качества услуг, расширения спектра продуктов и достижения других требований банковского бизнеса. Важным этапом является и анализ социальных составляющих этого процесса, который включает оценку следующих аспектов: насколько пользователи будут поддерживать новое решение и готовы ли они к повышенным нагрузкам и обучению работе на новом продукте, насколько их квалификация соответствует современным требованиям и технологиям, реалистичны ли их требования и ожидания. Как показывает практика, неудачи многих проектов в этой области носят именно социальный характер. На основании всей собранной информации высшим руководством принимается окончательное решение о покупке или разработке новой системы. Не существует типового решения этой задачи. Для банка оно всегда индивидуально и каждый раз должно базироваться на результатах анализа, хотя на практике большинство банков, как российских, так и зарубежных, принимают решения в пользу сторонних разработок. Следующим шагом является разработка функциональных требований. Детальные требования к системе автоматизации банковской деятельности должны быть определены также на предварительных стадиях проекта, до начала непосредственного выбора системы. Для организации процесса определения требований к системе может быть рекомендован следующий подход. Данный этап осуществляется специальной командой сотрудников банка или консультантов во взаимодействии со специалистами функциональных подразделений под руководством выделенного руководителя, обычно высшего звена (члена правления). Иногда в крупных организациях такие команды создаются еще на предыдущей стадии (анализа целесообразности). Разработка функциональных требований включает: * проведение интервью с руководством и представителями бизнес-подразделений банка; * ознакомление с существующей и планируемой технологией, бизнес-процессами, особенностями работы и информационных потоков; * оценку организационной структуры, стратегии и направлений развития банка и их влияния на выбор АБС; * осуществление детального анализа используемых систем; * анализ существующих требований к системе по функциональным возможностям и отчетным средствам, их доработку и установление приоритетов; * определение, согласование и утверждение требований к техническим характеристикам системы - объемам операций, оперативности, защищенности данных и т.д.; * определение/уточнение/утверждение основных бизнес-процессов банка, подлежащих и не подлежащих автоматизации, а также их взаимодействия; * определение и утверждение требований к системе. Результатом этой работы должен стать документ "Требования к системе", который является частью тендерной документации. Его объем в зависимости от размера и сложности банка может составлять от 50 до 1500 страниц. Если документ построен правильно и в нем не излагаются общепринятые требования, то для среднего банка объем обычно не превышает 70-100 страниц. Не следует пытаться описать технологию работы банка со всеми деталями, используя специальные средства и стандарты моделирования (IDEFO, DFD, UML), так как излишняя детализация может обойтись достаточно дорого - как с точки зрения денег, так и с точки зрения временных затрат. Рассмотрим общие требования к банковским информационным системам. Система должна: - базироваться на современных технологиях. Так, современные платформы (ОС и СУБД) позволяют реализовать гибкость, открытость и масштабируемость системы; - представлять собой оптимальное, интегрированное решение и иметь единую базу статистических данных; иметь возможность интеграции с существующими системами или модулями; - иметь достаточное функциональное покрытие и возможность расширения (наращивания) функциональных возможностей в соответствии с потребностями банка, изменениями законодательства и т.д.; - иметь возможность увеличения количества обрабатываемых транзакций и/или клиентов; - предусматривать ввод и обработку операций посредством электронного документооборота (work flow). Для документов должен быть предусмотрен набор состояний и стадий обработки, определенных банком; - предусматривать возможность получения отчетов о стадии обработки документов; - формировать аналитические отчеты как минимум по двум критериям: по клиентам и по продуктам; - обеспечивать конфиденциальность, целостность и доступность деловой информации; - обеспечивать контроль за действиями пользователей на системном и прикладном уровне и их последующий анализ; - иметь возможность импортирования данных из внешних приложений; - содержать гибкие возможности настройки отчетов, доступные для использования обычными пользователями. Отчеты можно формировать для любой информации, содержащейся в АБС. Информацию, обрабатываемую в разных модулях АБС, можно группировать в один отчет. Система должна автоматизировать (где это возможно) подготовку отчетности для ЦБ РФ, а также налоговой отчетности; - иметь инструментарий (генератор отчетов), позволяющий: определять внешний вид отчетов; данные, на основе которых будет формироваться отчет; порядок сортировки и критерии отбора как для отчетов, получаемых на регулярной основе, так и для разовых отчетов по специальному запросу. Также в системе должна существовать возможность модификации существующих отчетов; - проверять данные, вводимые пользователем или поступающие через интерфейс обмена данными, и осуществлять лексический, синтаксический и семантический контроль. Примерами контроля могут быть: проверка формата (например, цифровой); существование кода клиента в справочнике; отклонение от обычных значений; задвоение операции; диапазон дат; проверка соответствия остатка типу счета (активный, пассивный); достаточность средств на счете; превышение лимитов; проверка критерия (сумма и счет); - предусматривать возможность верификации и авторизации действий и документов персоналом, не связанным со вводом операции. Должна существовать возможность настройки данной опции для определенных видов операций или операций, превышающих установленный лимит; - быть понятной, легкой в эксплуатации и использовать современные технологии построения интерфейса; - вести протокол всех операций, который должен быть доступен для просмотра по запросу администратора безопасности и иметь разграниченный доступ. Как минимум следующие данные должны содержаться в протоколе операций: время, идентификатор пользователя, рабочее место, приложение и тип операции. Ручной ввод, пакетная обработка данных и обработка данных через внешние интерфейсы также должны фиксироваться в протоколе. Протокол операций пользователей в системе должен быть защищен от изменений; - иметь возможность классифицировать пользователей и предоставлять различным категориям пользователей различные уровни доступа к системе и данным: по объему операторских функций (доступ к определенным экранам и функциям); по степени доступа (просмотр/ввод/авторизация); системный администратор должен иметь возможность создавать индивидуальные меню для конкретных пользователей; - обеспечивать следующие требования парольной политики: а) все пользователи вводят уникальный идентификатор и пароль для получения доступа в систему; б) после определенного количества неудачных попыток (3 раза) отдельного пользователя получить доступ система закрывает доступ этого пользователя. Вновь открыть доступ может только администратор системы. Система ведет счет неудачных попыток и протоколирует их; в) хранимые в системе пароли должны быть зашифрованы и составлять как минимум 8 символов. При этом предусматривается возможность устанавливать различную длину пароля для различных групп пользователей; г) система содержит словарь неприемлемых паролей и обеспечивает возможность запрещать ввод новых паролей, если они присутствуют в этом списке; д) система периодически (1 раз в месяц) требует изменения паролей пользователями; е) система не позволяет повторного использования старых паролей; ж) число одновременных рабочих сессий для каждого пользователя ограничено; з) пользователям сообщается о предыдущих удачных/неудачных попытках доступа к системе в момент входа, включая время завершения предыдущего сеанса; и) предусматривается возможность ограничивать время и рабочее место (IP-адрес, МАС-адрес или имя компьютера) пользователей в системе; к) соединение с системой должно автоматически обрываться, если пользователь не работает в ней определенное количество времени; - иметь опыт успешных внедрений на территории России, а также иметь возможность локальной поддержки. Что касается детальных требований, то их, разумеется, невозможно изложить в достаточном объеме в рамках статьи, поэтому перечислим лишь некоторые специфические требования. Система должна: - осуществлять автоматизированную подготовку писем для рассылки заинтересованным сторонам (клиентам, налоговой инспекции и т.п.) по группам счетов/клиентов. Формирование выписок по счетам клиентов, писем клиентам производится в формате, необходимом для их автоматической упаковки в конверты; - осуществлять автоматическую проверку остатка денежных средств на счете клиента перед списанием средств со счета; - осуществлять расчет текущего и планового (с учетом будущих и неподтвержденных платежей) остатка денежных средств на счете клиента на любую дату; - осуществлять контроль остатка по счету с учетом установленных лимитов. При превышении лимитов по операции или остатку на счете необходима дополнительная авторизация; - иметь процедуру авторизации при открытии нового счета в системе, без которой новый счет не может быть задействован для каких-либо операций; - иметь возможность как полностью блокировать операции по счету клиента, так и разрешать только дебетовые или кредитовые операции. Изменение статуса счета производится уполномоченным сотрудником; - иметь возможность постановки платежа в картотеку с автоматическим контролем остатка по счету плательщика и отражением последующих операций во внебалансовом учете и на балансовых счетах; - предусматривать возможность формирования автоматических операций. Такие операции настраиваются по произвольным шаблонам и имеют возможность формироваться по заранее определенному графику (stand-by orders). Примером таких операций может быть ежемесячное списание сумм коммунальных платежей сотрудников организации с ее расчетного счета; - иметь возможность копировать создаваемые отчеты в файлы, доступные для других офисных приложений с целью их дальнейшей обработки (например, Excel, Access); - отслеживать все стадии жизненного цикла кредита, начиная от предоставления заявки до закрытия договора; - автоматически рассчитывать сумму резерва и подготавливать для последующего подтверждения и авторизации соответствующие проводки на сумму создаваемого резерва на потери по ссудам; - формировать отчетность по контролю позиции банка с учетом платежей банка и клиентов, заявок на покупку/продажу валюты. Отчеты формируются по корреспондентским счетам с учетом платежей банка и клиентов, в том числе ожидаемый возврат кредитов; - иметь возможность автоматического переноса остатков на другие балансовые счета в случае требований учета (например, закрытие парных счетов); - автоматически осуществлять проводки на основании введенной и авторизованной информации о заключенной сделке и формировать соответствующие платежи; - предусматривать формирование специальных контрольных отчетов (отчет по операциям, где произошло превышение лимитов; список исправительных проводок и проводок в предыдущих операционных днях; список проводок, где условия могут быть некорректными - например, дебетовая проводка на счет доходов, большие суммы по транзакции или по клиенту, проходящие через кассу, большие суммы, проходящие по расходным счетам, список счетов, по которым за настраиваемый период отсутствовало движение средств (dormant accounts), отчет по суммам, находящимся на счете дольше определенного периода, или операциям, незавершенным в течение заданного промежутка времени, отчет по операциям со счетами доходов и расходов, введенными вручную). Система "клиент-банк" должна быть сертифицирована ФАПСИ. Анализируя процесс выбора банковской системы и, в частности, требования банков, нельзя не сказать о двух основных из существующих на рынке классах таких систем, российских и зарубежных, и их различиях. Безусловно, среди российских систем есть лидеры и аутсайдеры, решения этих систем имеют некоторую специализацию. Но, если говорить в целом, все-таки они близки по духу, идеологии и функциональным возможностям и существенно отличаются от зарубежных систем. Именно российские системы мы и рассмотрим, сосредоточившись на их недостатках, так как недостатки зарубежных систем в основном сводятся к нескольким общеизвестным фактам: относительно высокой стоимости решения и его сопровождения, сложности с поддержкой в российских условиях (прежде всего это касается отчетности ЦБ РФ), более долгим внедрением системы. В остальном же зарубежные системы представляют собой действительно надежные и функционально полные решения, которые несут в себе прогрессивные банковские технологии, а также опыт и практику банковского дела стран с развитой экономикой. В чем же заключаются основные недостатки российских систем? 1. Российские системы не являются контрольно-ориентированными. Они слабо поддерживают процедуры внутреннего контроля и аудита. В них практически отсутствуют механизмы сверок, контрольных отчетов, принудительных процедур, механизмы минимизации, предотвращения и поиска ошибок. 2. Они слабы сточки зрения информационной безопасности. Это проявляется в невозможности настройки правильной парольной политики, адекватной системы разграничения прав, протоколирования действий пользователей, в слабой защите на системном уровне, отсутствии специализированного функционала для администраторов безопасности. 3. Ограниченный функционал по новым для нас направлениям банковской деятельности (рынок денег, FOREX, дилинг, операции с производными ценными бумагами, векселями, современные формы кредитования). 4. Недостаток или полное отсутствие механизмов автоматизации управления банком (управленческой отчетности, онлайн-анализа рентабельности продуктов и услуг, прибыльности клиентов, средств моделирования, механизмов автоматизации управления активами и пассивами), слабая визуализация управленческой информации. 5. Сложности с поддержкой Международных стандартов бухгалтерского учета. 6. Отсутствие автоматизации таких банковских функций, как риск-менеджмент, внутренний аудит, казначейство, в частности управление ликвидностью. 7. Недружелюбный интерфейс. Как правило, западные системы имеют более удобный для работы интерфейс. Это связано с тем, что в российской практике обычно разработчики не выделяют специалистов - дизайнеров интерфейса, который создается обычными программистами и впоследствии модифицируется в связи с предложениями клиентов. Тем не менее, несмотря на эти недостатки и учитывая, что некоторые из них не очень актуальны для многих банков, большинство по-прежнему выбирает российские системы, хотя процесс установки зарубежных систем в последнее время существенно активизировался.
Организация процесса выбора системы
После того как обоснована необходимость внедрения новой банковской информационной системы и сформулированы основные требования к ней, можно приступать непосредственно к процессу выбора. Как мы уже отмечали, в рамках данной статьи мы будем говорить о сторонних системах. Выбор АБС является принципиальным для успеха всей работы по замене старой системы на новую. И не только потому, что необходимо выбрать действительно адекватную требованиям и задачам банка систему и найти достойного бизнес-партнера, но и потому, что именно на этой стадии необходимо заложить правильный фундамент взаимоотношений с компанией - поставщиком решения. Именно на этой стадии будущие проблемы еще можно устранить, построив процесс выбора максимально продуманно, согласованно, минимизируя риски и заранее готовясь к сложностям. Основными этапами выбора АБС являются проведение тендера на выбор системы и заключение контракта. Приведем аргументы в пользу тендерной формы выбора системы: - независимость и относительная объективность решения (посредством тендера оценивается максимальное количество решений, и в этом процессе участвуют многие специалисты банка, а иногда и привлеченные эксперты и консультанты; - удобство и эффективность (удобство проявляется во взаимодействии с поставщиками, получении информации, также тендер позволяет оптимизировать использование банковских специалистов в этом процессе, которые должны активно участвовать в выборе, но не могут приостановить свою непосредственную работу); - быстрота выбора (использование тендера на основе правильных методик позволяет существенно сократить общее время от начала выбора до окончательного решения, что немаловажно, так как процесс выбора системы может длиться от нескольких месяцев до года и более, то есть составлять от 10 до 40% всего времени замены старой системы на новую). Существуют две основные формы проведения тендера на выбор АБС: открытая и закрытая. Открытая форма подразумевает официальное объявление о проведении тендера с возможностью участия всех желающих компаний. Закрытая форма подразумевает, что круг участников определяется самим банком, сторонние организации, не попавшие в этот список, к участию в тендере не допускаются. Можно порекомендовать для проведения тендера по выбору АБС закрытую форму. Хотя необходимо отметить, что в некоторых случаях может быть использована и открытая форма. Предпочтительность закрытой формы связана лишь со спецификой рынка банковского программного обеспечения - ограниченным количеством и относительной известностью компаний-поставщиков. На российском рынке активно работают в этой области не более десяти отечественных компаний и всего несколько международных. Рассмотрим этапы проведения тендера. Первый этап состоит из подготовки тендерной документации, определения и утверждения порядка и условий проведения тендера. К минимально необходимому комплекту тендерной документации можно отнести: правила (методику) проведения и подсчета результатов; приглашение на участие в тендере, которое будет рассылаться участникам; анкета участника тендера (должна быть заполнена и возвращена вместе с подтверждением участия). На этом этапе необходимо утвердить основные подходы к проведению процедуры тендера. Второй этап - формирование расширенного списка участников (Long List) и рассылка приглашений (Invitation to Tender). Для выбора потенциальных участников тендера осуществляется анализ существующих поставщиков программных продуктов на предмет целесообразности включения их в тендерный список (предварительный анализ поставщиков и систем на предмет соответствия общим требованиям), после которого осуществляются определение и утверждение участников тендера. Приглашение на участие в тендере содержит: - общую информацию; - условия тендера и порядок взаимодействия; - сроки проведения; - контактную информацию; - условия конфиденциальности. Анкета участника содержит: - общую информацию о компании (наименование представляемой системы, год создания, число сотрудников, количество клиентов, представительства и партнеры); - общую информацию о системе (количество внедрений, в том числе в российских и зарубежных банках, техническая платформа - база данных, операционная система, требования к серверам и рабочим станциям, архитектура, иностранные языки, поставка лицензий на дополнительное программное обеспечение); - сведения о функциональности (мультивалютность, ведение бухгалтерского учета в соответствии с инструкциями ЦБ РФ, поддержка нескольких планов счетов и международных стандартов учета); - данные об открытости (возможность импорта данных из внешних систем, уровень детализации данных при импорте, взаимодействие с внешними системами); - среднее время внедрения, примерную стоимость системы и услуг, сведения об организации сопровождения системы. Третий этап - отбор наиболее предпочтительных систем для детального ознакомления (Short List). На этом этапе компаниям из расширенного списка, подтвердившим свое участие, передается документ требований к системе. Далее проводятся ознакомительные показы по общим возможностям системы (около 2-4 часов на каждую систему). Участникам дается некоторое время на формирование официального ответа о соответствии их решений представленным банком функциональным и техническим требованиям. На основании информации, полученной из анкет участников тендера, впечатлений от просмотров систем, а также из ответов о соответствии требованиям осуществляется выбор наиболее предпочтительных систем для детального ознакомления. Результатом этапа должен стать список из 3-4 систем. Большее количество неудобно из-за существенного увеличения времени изучения, меньшее - потому, что увеличивается риск невключения в детальное изучение действительно подходящей банку системы. Четвертый этап - детальное ознакомление и выбор системы. После оповещения компаний, прошедших во второй круг отбора, необходимо приступить к планированию встреч с поставщиками и просмотров систем. Такое планирование очень важно, так как детальный просмотр системы отвлекает огромное количество ресурсов как со стороны банка, так и со стороны фирмы - разработчика решения. Переносы сроков (например, в силу занятости соответствующих специалистов) могут затянуть этот процесс. Поэтому необходимо сформировать, согласовать и утвердить график встреч с поставщиками, который должен максимально точно соблюдаться. При ознакомлении предлагается использовать так называемые тестовые задания - заранее описанные банком процедуры, которые в ходе показа предлагается исполнить в системе. Иногда их необходимо заранее согласовать с поставщиком, чтобы он смог настроить соответствующий функционал системы для демонстрации и не отговаривался тем, что "система может, но для этого требуется небольшая перенастройка". Далее начинается анализ предложений от поставщиков и оценка систем в ходе детального ознакомления. Поступившие предложения от поставщиков оцениваются по следующим критериям: * степени соответствия бизнес-требованиям банка; * необходимости в доработке и модификациях предлагаемого решения; * предварительной стоимости и срокам проведения доработок и модификаций; * стоимости системы и стоимости обслуживания/поддержки; * скрытым издержкам и выгодам от использования системы; * надежности и репутации поставщика, опыту деятельности в России и на других рынках, его способности оказывать достаточный уровень поддержки и обслуживания системы в Москве, а при необходимости - в регионах России. Банк может применить метод взвешенной оценки, который будет использовать оценки специалистов различных элементов системы. К перечисленным критериям оценки и самим оценкам должны применяться различные веса, предварительно согласованные и утвержденные. В зависимости от критичности того или иного критерия ему будет присвоена соответствующая балльная шкала. Например, если "степень соответствия техническим требованиям банка" является важным критерием оценки, ему будет присвоен более высокий балл. Стоимость системы и ее поддержки является критерием, который оценивается путем определения соотношения баллов, набранных после оценки всех остальных критериев, и стоимости. В результате получается так называемый коэффициент экономической эффективности системы. Необходимо отметить, что использовать стоимость системы как критерий сравнительной оценки нужно с осторожностью, так как он применим только в случае, если системы сопоставимы по всем основным параметрам. Также важно оценивать не предварительную, а действительную или окончательную стоимость системы, поэтому до завершения процесса оценки банк должен сформировать запрос на официальное коммерческое предложение для участников этого этапа тендера, так называемый Reques for Proposal, и ответ на него должен быть получен. Итоговым результатом должен стать отчет по оценке и анализу систем с рекомендацией оптимального варианта. На основе отчета с перечислением плюсов и минусов каждой из систем руководство банка делает выбор. Такой окончательный выбор, учитывая важность задачи, обычно осуществляется на заседании правления, где выслушиваются представители различных подразделений, обсуждаются результаты взвешенной оценки и стоимостные параметры решений. Можно рекомендовать выбирать не только один (оптимальный) вариант (лидер тендера), но и второй (страховочный) вариант - в случае возникновения проблем с выбранным поставщиком (например, на стадии заключения контракта) можно будет вступить в переговоры со вторым поставщиком. Выбор двух вариантов можно открыть обеим компаниям, что, безусловно, пойдет на выгоду банку. После окончательного выбора системы наступает стадия согласования и заключения контракта. И тут начинается игра, в которой банк практически изначально обречен на поражение. Даже при наличии квалифицированных юристов банку трудно противостоять компании-поставщику, которая имеет опыт заключения десятков, если не сотен, подобных контрактов, и специализирующимся по софтверным контрактам юристам. К тому же банковские юристы, да и ИТ-специалисты недостаточно разбираются в нюансах и, как это ни странно, склонны верить устным обещаниям. Каковы же общие подходы к переговорам и заключению контракта, которые необходимо принимать в расчет? Попробуем дать ряд рекомендаций, которые могут облегчить заключение контракта и сделать его удобным банку, а не компании. 1. Необходимо помнить, что компания будет делать только то, что записано в контракте. 2. Предполагать негативный сценарий и анализировать контракт с этой точки зрения. 3. Софтверные компании умеют не только "вспоминать" о не включенных в первоначальное предложение услугах и модулях, но и "падать" в ценах. 4. Необходимо требовать прояснения терминологии и закрепления ее в контракте, в том числе таких понятий, как адаптация, доработка, настройка, конвертация и т.д. 5. В контракте должны быть определены ключевые точки проекта (Milestones) и признаки их достижения (например, опытная и промышленная эксплуатация, пользовательское тестирование и приемка, поставка программного обеспечения и т.п.). 6. Везде, где это только возможно, необходимо включить в контракт требование об обязательном согласовании с банком действий компании - поставщика решения. 7. В контракте должны быть предусмотрены санкции за задержку адаптации или внедрения по вине компании и процедуры определения и согласования причин задержек или перенесения работ. 8. Может быть предусмотрен возврат всех или части лицензионных платежей при неуспехе внедрения или его задержке более чем на 1 год (на этот пункт поставщики решения не всегда соглашаются). 9. Поддержка российской отчетности, налоговых и прочих требований должна быть рассмотрена отдельно и детально. 10. Процедура отказа от старой системы должна быть также рассмотрена. 11. Необходимо предусмотреть возможность по требованию банка замены отдельных специалистов или менеджера проекта в случае недостаточной их квалификации или при возникновении сложностей во взаимоотношениях с ними. 12. Желательно определение предельных сроков и стоимости работ. 13. Нужно включить в контракт процедуры разрешения споров и конфликтных ситуаций. Если учесть все эти факторы, можно существенно снизить риски, сопровождающие выбор системы. Выбор АБС является задачей, для решения которой во всем мире принято активное привлечение сторонних консультантов. Это связано с несколькими причинами. Во-первых, наличие опыта существенно сокращает время выбора и помогает наиболее оптимально построить сам процесс. Крупные консалтинговые компании обладают таким опытом и имеют устоявшиеся и проверенные многочисленными проектами методики, самостоятельно разработать которые достаточно сложно (например, система взвешенной оценки АБС или организация тендера). Во-вторых, привлечение сторонних наблюдателей, тем более организаторов и исполнителей тендерных процедур, повышает независимость и объективность выбора. К сожалению, часто покупка банковской системы сопровождается личной заинтересованностью того или иного руководителя банка в продвижении, лоббировании какой-либо одной системы. Поэтому использование консультантов, которые не только организуют процесс и наблюдают за объективностью, но и сами дают рекомендацию по оптимальному с их точки зрения выбору, очень важно. В-третьих, консультанты иногда помогают банку разобраться в приоритетности его требований и различных скрытых проблемах или "подводных камнях". На практике может сложиться так, что выбираемая система соответствует 90% требований банка, но доработка оставшихся 10% очень сложна. Другая же система в меньшей степени соответствует требованиям, зато легче адаптируется. Сделать выбор в такой ситуации непросто, особенно если учесть, что все поставщики программ на начальных стадиях проекта, как правило, утверждают, что их продукты максимально легко адаптируются. Таким образом, практически любому банку можно рекомендовать вовлечение консультантов в процесс выбора информационной системы. Степень этого вовлечения является индивидуальной. Это могут быть как консультации, которые займут всего несколько часов, так и привлечение консультантов на длительный срок до окончательного выбора АБС. Мы надеемся, что, используя наши рекомендации, вы сможете подойти к решению проблемы выбора новой автоматизированной банковской системы более взвешенно. Мы уверены, что, используя информацию, изложенную в этой статье, предложенные методики выбора систем и наши рекомендации, вы сможете существенно снизить риски и повысить вероятность успешного завершения всего проекта внедрения новой системы в разумные сроки и в рамках бюджета, так как первоначальная стадия этого процесса - выбор решения, как мы уже отмечали, имеет огромное влияние на успешное внедрение и последующую эксплуатацию новой системы.
Часть 2. Операционное управление информационными технологиями
Одной из первостепенных задач операционного управления ИТ, которая имеет существенное значение для совершенствования работы банка, является построение хорошо отлаженной системы управления персоналом, обеспечивающей гарантированное и качественное выполнение всех видов работ. Важность этой задачи объясняется тем, что и руководство, и рядовые сотрудники в конечном счете являются как инициаторами и главной движущей силой, так и исполнителями всех происходящих процессов, и вся система управления представляет собой не что иное, как систему взаимоотношений между людьми, включающую их знания и умения, их ответственность за выполняемую работу. Мы не ставили целью этой главы повторить или развить известные из общего менеджмента подходы и техники управления персоналом. В первую очередь мы хотим рассмотреть особенности этого процесса для специалистов по информационным технологиям, потому что убеждены, что управление этой категорией сотрудников требует дополнительной информации, понимания специфических рисков и особенностей их труда и мотивации.
Особенности управления ИТ-персоналом
Прежде чем рассматривать базовые элементы управления персоналом, остановимся на особенностях управления специалистами по информационным технологиям, которые отличают эту группу от других и должны быть учтены. Первая особенность - неразвитость российского рынка труда. Западные подходы и теории строятся на том, что рынок труда перенасыщен специалистами, вследствие чего акцент делается на правильную организацию работы по поиску, отбору, найму и мотивации. В этом случае необходимые трудовые ресурсы, в том числе и высококвалифицированные специалисты (например, высшие менеджеры), при желании будут обязательно приобретены организацией. В российских условиях очень часто приходится сталкиваться с тем, что ИТ-специалист необходимой квалификации просто отсутствует на рынке труда, или, например, с тем, что часто теоретически невозможно организовать быстрое привлечение к работе требуемого специалиста, поскольку на это может потребоваться время, которым организация не располагает. Следующей особенностью является существенный спрос на наших ИТ-специалистов за рубежом. Пожалуй, это единственная группа российских специалистов, которые реально востребованы в подавляющем большинстве европейских стран и Америке и оцениваются наравне, а иногда даже и выше, чем местные специалисты. Таким образом, для многих из них выезд на работу за рубеж является реальной возможностью и альтернативой карьере в России. Знание английского языка поднимает стоимость на рынке любого ИТ-специалиста, доводя ее до международного уровня. Другой особенностью является невозможность совмещения некоторых ролей и обязанностей, так как это источник риска. Одним из таких рисков может быть так называемая зависимость от ключевого ИТ-персонала, что также необходимо учитывать при управлении ИТ-пер-соналом. Эта зависимость проявляется в том, что очень часто на практике в организациях после ряда успешных лет работы появляется специалист или группа специалистов, которые обладают знаниями всех деталей функционирования и организации информационных систем, технологических цепочек, носителями уникального и "сокровенного" знания. Они не спешат делиться знаниями и навыками с другими работниками ИТ и постепенно становятся незаменимыми, "без них все начинает останавливаться". К сожалению, в последнее время к таким банальным причинам подобных остановок, как болезни и семейные обстоятельства "ключего ИТ-персонала", добавились случаи прямого шантажа и диверсий со стороны работников, недовольных теми или иными действиями руководства. Еще одна особенность - необходимость постоянных усилий для поддержки квалификации. В отличие от многих других специальностей ИТ-персоналу требуется время для ознакомления с новыми продуктами, технологиями, так как за 5-7 лет в области информационных технологий происходит большое количество революционных изменений, которые обесценивают предыдущие знания и опыт. Поэтому ИТ-специалистам необходимо регулярное дополнительное образование, изучение публикаций и самообразование. Все это должно являться частью их основных обязанностей независимо от специализации, направления деятельности или занимаемого положения. Среди негативных особенностей российского ИТ-персонала зарубежные менеджеры часто называют его относительную неуправляемость, которая проявляется в неточном выполнении задания, недостаточном уважении к менеджменту, неумении работать в группе, коллективе над одной задачей, склонности к конфликтам. Они решают поставленную задачу путем, кажущимся им оптимальным, игнорируя существующие и используемые в организации стандарты и процедуры, указания руководства. Иногда это приводит к перевыполнению, иногда к недовыполнению задачи, реже - к ее четкому выполнению. Также можно отметить и то, что многие российские ИТ-специалисты по сравнению с зарубежными хуже способны планировать свою деятельность и соблюдать временные планы и рамки своей работы. Среди безусловно положительных особенностей российского ИТ-персонала можно отметить преобладание творческого подхода при решении задач и крайне высокий уровень профессионального образования. Действительно, если поставленная задача новая, сложная и требует нестандартного, творческого решения, то это как раз и есть основная стихия российских ИТ-специалистов. Иногда это позволяет решать задачи на порядок эффективнее, чем они могли бы быть решены в западных условиях. Но, к сожалению, такое "творческое" отношение к работе может приносить и негативные последствия, например такие, которые были перечислены выше, и поэтому должно тщательно управляться менеджментом. Последнюю особенность ИТ-персонала, которую необходимо учитывать в управлении, можно сформулировать как крайне существенную разницу в эффективности труда ИТ-специалистов, особенно программистов. Так, опытный и высококвалифицированный программист может выполнить некоторые задачи в 10-15 раз быстрее обычного. Некоторые менеджеры, например по обслуживанию пользователей, могут в течение 2-3 лет налаживать эту работу, в то время как руководитель, который уже приобрел этот опыт (особенно если он положительный) в другой организации, может все наладить за 2-3 месяца.
Элементы системы управления персоналом
Рассмотрим основные элементы системы управления персоналом. К ним можно отнести: планирование персонала - комплекс мер, направленных на оценку текущих ресурсов, прогнозирование их сокращения, оценку будущей потребности в ресурсах, в том числе и в руководящих работниках, оценку резерва персонала и способов быстрого замещения специалистов; привлечение персонала - комплекс мер, обеспечивающий привлечение требуемых специалистов в заданное время. Данные меры включают поиск, вербовку, отбор, наем и первичное развитие персонала; развитие персонала - включает обучение и переподготовку персонала, перемещение, оценку и продвижение персонала, подготовку резервов специалистов и руководителей; мотивацию и стимулирование персонала - включают оплату труда, дополнительные стимуляционные выплаты и систему мотивации труда; учет персонала - комплекс мер по обеспечению кадровой работы в соответствии с требованиями контролирующих органов и потребностями самой организации. Наличие этих составляющих позволяет говорить о том, что в банке функционируют базовые элементы управления персоналом. В большинстве российских банков можно отметить наличие таких из перечисленных составляющих, как учет персонала, являющийся обязательным в деятельности любой организации и достаточно хорошо регламентированный внешними органами, и систему привлечения персонала к решению общих задач. Самыми узкими областями в сфере управления персоналом, а потому наименее разработанными, являются развитие персонала, его мотивация, а также планирование ресурсов, которые, как правило, вообще не осуществляются в российских условиях. Поэтому совершенствование системы управления персоналом необходимо начинать именно с этих направлений. Как уже отмечалось, наиболее целесообразно начинать построение и развитие системы управления персоналом с планирования ресурсов. Банк должен четко прогнозировать свои будущие потребности в трудовых ресурсах. Это связано прежде всего с тем, что сегодня практически невозможно быстро найти необходимого специалиста. Это достаточно длительная процедура, особенно если речь идет о высококвалифицированных специалистах. Другая причина актуальности развития системы прогнозирования кроется в текучести кадров. Для большинства российских банков типично, что на всех ключевых постах находятся "незаменимые люди", потеря которых может быть чревата очень серьезными последствиями для банка. В мировой практике принято заранее готовиться к подобным ситуациям и иметь некоторый резерв специалистов для того, чтобы непредвиденные случаи не привели к остановке работы организации. Например, уход или длительная болезнь главного бухгалтера могут привести к остановке банка или очень серьезным нарушениям в его работе, особенно если в круг обязанностей главного бухгалтера входит существенная часть отчетности и обеспечение налоговых отчислений. Для замещения ушедших или заболевших специалистов может использоваться не только внешний резерв, но и так называемый внутренний резерв на выдвижение, который составляют сотрудники банка, знакомые с обязанностями и особенностями работы других специалистов и в случае крайней необходимости способные их заменить. Формирование резерва на выдвижение в целях служебной этики осуществляется, как правило, негласно. В рамках планирования персонала также могут производиться и работы по формированию резерва на сокращение. Это необходимо для того, чтобы в случае необходимости сокращения персонала в резко ухудшившихся внешних условиях осуществлять процесс сокращения продуманно, а не "в спешке", и сохранить наиболее квалифицированных специалистов. Каковы типовые роли и специализации ИТ-работников? Можно выделить следующие основные группы. Системные аналитики - проектируют информационные системы исходя из потребностей пользователей. Они интерпретируют требования и пожелания, облекая их в документальную форму, понятную пользователям (бизнес-требования), и в форму, понятную разработчикам, программистам (техническое задание). Другими словами, системные аналитики выступают своеобразным интерфейсом между пользователями и программистами, которые, как известно, "говорят на разных языках" и редко могут понять друг друга. Они должны обладать широким профессиональным кругозором, детальным пониманием бизнеса и предметных областей, при этом знать основы проектирования информационных систем, возможности и ограничения при разработке программ. Прикладные программисты - отвечают за разработку новых систем, доработку, изменение используемых систем. Эта разработка ведется на основе согласованных системными аналитиками требований и документов. Профессиональные навыки состоят в умении наиболее эффективным способом создавать программы, используя знания по современным средствам разработки. Также для них очень важным является умение работать в группе разработчиков, осуществляя программирование в соответствии с утвержденными стандартами и распределением обязанностей. Тестировщики - осуществляют тестирование разработанных программ с целью выявления ошибок или возможных проблем при эксплуатации систем. Для тестирования требуется менее высокая квалификация, чем для анализа или разработки, однако эта работа требует повышенного внимания и аккуратности. Хранители программ - в их обязанности входит оприходование, хранение, резервирование программ, исходных кодов, учет их использования, в том числе отслеживание версионности и обновлений. К обязанностям хранителей программ можно также отнести ведение списка используемого программного обеспечения. В большей степени эта роль является административной, хотя и требует ограниченных ИТ-навыков. В небольших организациях эту роль может выполнять один из ИТ-специалистов по совместительству. В крупных организациях эта функция может поддерживаться целым подразделением. Системные программисты - отвечают за поддержку, настройку и организацию корректного взаимодействия с системным программным обеспечением (операционные и сетевые системы, утилиты). Обычно в небольшой организации бывает достаточно одного системного программиста для поддержания этой функции на необходимом уровне. Администраторы данных - их функцией можно назвать разработку или поддержку информационной архитектуры, организацию хранения и резервного копирования информации, мониторинг использования баз данных, их оптимизацию, консультирование программистов по структуре и средствам доступа к информации. Администраторы безопасности - отвечают за практическую реализацию политики информационной безопасности, настройку и поддержку прав пользователей, мониторинг их активности, анализ инцидентов и выработку рекомендаций для руководства по мерам дополнительного контроля и совершенствования системы защиты информации. Как правило, такой специалист должен работать в выделенном режиме. Контролеры качества - помогают организовать процесс постоянного мониторинга ИТ-процессов с целью повышения качества конечных продуктов и услуг, а также обслуживания пользователей. Их основными участками работы являются разработка новых программ и поддержка пользователей. Они осуществляют контроль за соблюдением установленных регламентов и стандартов в области ИТ, отслеживают адекватность пользовательской документации, проводят контрольное тестирование программного обеспечения. Инженеры по компьютерному оборудованию - отвечают за поддержку и эффективное использование компьютерного оборудования (серверов, рабочих станций, периферийных устройств и т.п,) для достижения их бесперебойного функционирования. Инженеры по телекоммуникациям - осуществляют поддержку и обслуживание телекоммуникаций, корпоративных сетей, телекоммуникационного оборудования, линий связи, взаимодействуют с провайдерами линий и оборудования. Эксперты службы поддержки - отвечают за консультирование и решение разнообразных проблем пользователей, за решение проблем или их перенаправление к соответствующим специалистам и за удовлетворение потребностей пользователей, следя за тем, чтобы все запросы были обработаны, и своевременно сообщая о возможных задержках. Для них важными являются умение решать широкий круг проблем в сжатые сроки и умение общаться с пользователями. Банковские технологи - это работники новой сферы деятельности, которая находится на стыке бизнеса и современных технологий и направлена на поиск путей наиболее эффективного использования новейших достижений ИТ и бизнес-практики и совершенствование технологических процессов работы банка. В область компетенции банковских технологов, например, входят такие задачи, как построение системы обслуживания клиентов, средства поддержки операций, интерактивное обслуживание клиентов, работа с современными платежными системами, реализация межфилиального взаимодействия, технологии осуществления контроля и многое другое, без чего сегодня немыслима банковская деятельность. Для этой роли требуются работники с высоким уровнем квалификации и существенными знаниями в бизнес-области, широким опытом работы в разных организациях. Отдельно несколько слов необходимо сказать об ИТ-менеджерах. Их роль, как и в любой другой деятельности, очень высока. Для управления ИТ требуются две группы менеджеров - линейные менеджеры и руководители проектов. Линейные (или функциональные) менеджеры возглавляют статические подразделения, такие, как отдел поддержки пользователей, отдел обслуживания оборудования и т.п. (пример структуры ИТ-подразделения представлен в приложении). Руководители проектов (Project Managers) осуществляют оперативное управление отдельными проектами в области ИТ (как мы уже отмечали, большинством работ в ИТ-подразделении целесообразно управлять по проектным принципам, и этому будет посвящена следующая часть книги). Естественно, что принципиальную роль в правильной организации ИТ-службы играет ИТ-директор, или СЮ (о его роли мы уже писали). Традиционный подход к распределению полномочий между сотрудниками сводится к тому, что при недостатке объема работ сотрудники могут совмещать роли и задачи. В области информационных технологий такой подход не всегда применим, так как есть работы, совмещение которых резко увеличивает риски организации или совмещение которых невозможно "по определению", например разработка и тестирование, так как ни один человек не может адекватно оценить результаты своего труда). Тем не менее, не вдаваясь в подробности последствий, подчеркнем лишь, что они могут быть несоизмеримы с экономией на ресурсах, и рассмотрим возможности для совмещения (табл. 6
). В небольших организациях, к сожалению, такое разделение реализовать полностью редко удается, поэтому необходимо использовать компенсационные механизмы - контрольные процедуры (compensative controls). Такие процедуры направлены на предотвращение, обнаружение или смягчение нежелательных последствий совмещения обязанностей. Примером таких контрольных процедур являются периодическая проверка, аудит, протоколирование действий, документирование, специализированные программные продукты и т.п. Возможность совмещения участков работ
*(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
. Пример приоритезации запросов пользователей
┌─────────────────────┬───────────────────────┬─────────────────────────┐ │Градация приоритета │ Степень приоритета │ Гарантированное время │ │ │ │ реагирования │ ├─────────────────────┼───────────────────────┼─────────────────────────┤ │Высокий - 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. Для этого прежде всего обратимся к его терминам и определениям. Программное обеспечение - интеллектуальный продукт, состоящий из программ, процедур, правил и любой другой связанной с ними документации, относящейся к функционированию системы обработки данных. Элемент программного обеспечения - какая-либо идентифицируемая часть продукции программного обеспечения на промежуточном или конечном этапе разработки. Разработка - все виды деятельности, выполняемые для создания программного обеспечения. Проверка программного обеспечения - процесс оценивания продукции данной фазы в целях обеспечения правильности и согласованности в отношении продукции и стандартов, являющихся входными для данной части работы (фазы). Аттестация программного обеспечения - процесс оценивания программного обеспечения в целях обеспечения соответствия установленным требованиям. Услуга - итог непосредственного взаимодействия поставщика (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
). Основные составляющие оперативной деятельности ИТ-службы
┌────────────────────────────────┬──────────────────────────────────────┐ │Область оперативной деятельности│ Выполняемые работы │ ├────────────────────────────────┼──────────────────────────────────────┤ │Обеспечение работы банковских│Анализ системы, реализация новых│ │информационных систем │требований, анализ производительности,│ │ │обеспечение бесперебойной работы │ ├────────────────────────────────┼──────────────────────────────────────┤ │Обеспечение работоспособности│Работа с техническими средствами│ │офисных приложений │конечных пользователей, такими, как│ │ │персональные компьютеры, принтеры,│ │ │сканеры. Поддержка работы с локальными│ │ │приложениями. Консультирование│ │ │пользователей │ ├────────────────────────────────┼──────────────────────────────────────┤ │Поддержка технических средств│Обеспечение бесперебойной работы│ │информационной системы │основных серверов организации и│ │ │резервных систем │ ├────────────────────────────────┼──────────────────────────────────────┤ │Управление сетями организации │Управление сетями, используемыми для│ │ │передачи данных. Контроль│ │ │производительности и загруженности,│ │ │планирование развития сетей │ ├────────────────────────────────┼──────────────────────────────────────┤ │Бесперебойная работа│Анализ, разработка, тестирование и│ │телекоммуникационных средств │установка технических средств│ │ │телекоммуникаций │ ├────────────────────────────────┼──────────────────────────────────────┤ │Управление операционными│Администрирование операционных систем,│ │системами │используемых в организации │ ├────────────────────────────────┼──────────────────────────────────────┤ │Администрирование баз данных │Поддержка работающих систем управления│ │ │базами данных, включающая в себя│ │ │управление производительностью,│ │ │резервное копирование, устранение│ │ │сбоев в работе. Моделирование и│ │ │разработка корпоративных хранилищ│ │ │информации │ ├────────────────────────────────┼──────────────────────────────────────┤ │Обеспечение входящих│Обеспечение бесперебойного ввода в│ │информационных потоков │систему справочных значений (курсы│ │ │валют, справочники кодов) │ ├────────────────────────────────┼──────────────────────────────────────┤ │Обеспечение электронной почтой │Администрирование почтового сервиса│ │ │организации, а при его отсутствии -│ │ │разработка политики пользования почтой│ │ │сторонних организаций │ └────────────────────────────────┴──────────────────────────────────────┘ Основным отличием оперативной работы от проектной является ее полная регламентация. Как правило, менеджмент организации старается максимально детально определить действия сотрудников в текущей, постоянно повторяющейся работе. Целью полной регламентации является замена высококвалифицированной работы, требующей знаний и принятия решений, на механическую работу, требующую только добросовестного выполнения инструкций. Это позволяет: - сократить затраты на обучение и зарплату персонала; - снизить риски принятия неправильных решений; - выработать и поддерживать технические стандарты; - отработать методы устранения исключительных ситуаций. Наборы инструкций, которые определяют правила оперативной, каждодневной работы, в зарубежных организациях называются политиками (policies), в российских организациях - инструкциями, правилами, регламентами (табл. 9
). Основные внутренние регламентирующие документы
┌──────────────────────┬────────────────────────────────────────────────┐ │ Наименование │ Содержание документа │ │ документа │ │ ├──────────────────────┼────────────────────────────────────────────────┤ │ 1 │ 2 │ ├──────────────────────┼────────────────────────────────────────────────┤ │System Architecture│Определяет базовые решения, применяемые в│ │Policy (системная│организации. Включает перечень операционных и│ │архитектура │телекоммуникационных систем, описание│ │организации) │используемых аппаратных платформ,│ │ │регламентируется порядок их взаимодействия. Как│ │ │правило, в документ входят следующие разделы: │ │ │ аппаратные платформы: │ │ │- спецификация серверов организации; │ │ │- спецификация персональных станций│ │ │пользователей; │ │ │- спецификация мобильных компьютеров; │ │ │ сетевые платформы: │ │ │- структура глобальных сетей организации; │ │ │- общие требования локальных сетей организации; │ │ │- требования к защите сетей; │ │ │ программное обеспечение: │ │ │- операционные системы; │ │ │- банковские системы; │ │ │- офисные приложения; │ │ │- утилиты обслуживания и администрирования │ ├──────────────────────┼────────────────────────────────────────────────┤ │Data Architecture│Определяет модель хранилища данных организации,│ │(структура данных в│включая используемые системы управления данными,│ │организации) │описание сущностей системы и их атрибутов, связь│ │ │между ними и порядок доступа пользователей к ним│ ├──────────────────────┼────────────────────────────────────────────────┤ │Use of External│Определяет порядок взаимодействия со сторонними│ │Packages (порядок│разработчиками, правила и область использования│ │использования внешних│их продуктов │ │разработок) │ │ ├──────────────────────┼────────────────────────────────────────────────┤ │Use of External│Определяет порядок взаимодействия со сторонними│ │Resources (порядок│поставщиками услуг в области информационных│ │использования │технологий │ │сторонних ресурсов) │ │ ├──────────────────────┼────────────────────────────────────────────────┤ │IT Security (правила│Регламентируют структуру системы информационной│ │информационной │безопасности организации. Определяют механизмы│ │безопасности) │защиты информационных потоков и права доступа к│ │ │информации для пользователей и сторонних систем │ ├──────────────────────┼────────────────────────────────────────────────┤ │System Operability and│Содержит перечень работ для обеспечения│ │Service Recovery│эффективного и бесперебойного функционирования│ │(обеспечение │информационной системы организации. Данный│ │оперативной работы│документ может иметь следующие составляющие: │ │системы и порядок│ поддержка системы: │ │восстановления) │- порядок восстановления, остановки и запуска│ │ │системы; │ │ │- резервное копирование и архивация; │ │ │- использование вычислительных мощностей и│ │ │дискового пространства в системе; │ │ │- порядок внесения изменений в систему; │ │ │- инструкция по использованию интерфейса│ │ │администратора системы; │ │ │ внешнее обслуживание системы: │ │ │- сервисное обслуживание информационных систем; │ │ │- обеспечение входящих информационных потоков; │ │ │- требование к выходящим информационным потокам;│ │ │ контроль производительности системы: │ │ │- соответствие работоспособности системы и│ │ │утвержденным требованиям; │ │ │- эффективность использования ресурсов системы; │ │ │- поддержание актуальных во времени данных; │ │ │- порядок устранения текущих сбоев и ошибок│ │ │системы │ └──────────────────────┴────────────────────────────────────────────────┘ Работы по техническому обеспечению функционирования информационной системы организации обычно носят повторяющийся, цикличный характер. Для менеджера, отвечающего за данный тип работ, очень важно четко понимать эти циклы: время их начала и длительность. В операционной работе ИТ-подразделений определяются три типа циклов: * временные циклы; * циклы, определенные критическими параметрами системы; * циклы, определяемые общими процессами в организации. Рассмотрим по порядку каждый из циклов операционной работы ИТ-подразделения. Сроки выполнения работ определяются временными интервалами. Общая цель выполнения работ в зависимости от текущего времени - снижение нагрузки на вычислительные мощности системы. Наиболее распространенными периодами являются операционный день банка и операционная неделя. В список работ, выполняемых в данный период, обычно относят действия практически всех вычислительных мощностей или исключительного доступа к системе. В работе организации существуют временные интервалы - это ночные часы и выходные дни. К регулярным работам, осуществляемым в эти интервалы, относятся: резервное копирование, оптимизация хранилища данных, математические расчеты, которые требуют больших ресурсов, например расчет начисленных процентов или комиссий за период, формирование консолидированной отчетности отчетов. Также существует другой список работ, связанных с временными циклами. Как правило, это задачи, требующие включения различных сервисов информационной системы, выполнения и затем остановки сервиса. Часто подобные циклы используются для проверки состояния системы и автоматической загрузки данных. Временной интервал для данных задач может исчисляться от секунд до часов. В случае больших интервалов работы переносятся на ночное время. Следующий блок - это циклы, определенные критическими параметрами системы. Ряд работ при техническом обеспечении системы выполняется по наступлении какого-либо критического события, выявленного системой мониторинга. Обычно эти работы приводят к внесению изменений в деятельность системы с целью устранения нарушения или изменения критического параметра. Цикличность работ объясняется тем, что критичный параметр связан с эксплуатацией системы: регистрацией в ней новых объектов, ростом нагрузки и увеличением числа пользователей. При настройке механизмов контроля критических параметров следует устанавливать более строгие значения, чем требуется по технической спецификации. Это позволит перенести время выполнения работ на неоперационное время (табл. 10
). Примеры критических параметров систем
┌──────────────────────────┬────────────────────────────────────────────┐ │ Параметр │ Выполняемые действия │ ├──────────────────────────┼────────────────────────────────────────────┤ │Заполнение имеющегося│установка дополнительного дискового│ │дискового пространства │пространства; архивирование данных; перенос│ │ │данных на другие накопители │ ├──────────────────────────┼────────────────────────────────────────────┤ │Достижение предела│установка более мощных вычислительных│ │производительности │систем; запуск оптимизационных процедур │ ├──────────────────────────┼────────────────────────────────────────────┤ │Достижение максимального│оптимизация порядка эксплуатации системы;│ │количества пользователей│покупка дополнительных рабочих мест к│ │системы │системе │ ├──────────────────────────┼────────────────────────────────────────────┤ │Полное использование│замена использованных материалов │ │расходных материалов │ │ └──────────────────────────┴────────────────────────────────────────────┘ Рассматривая данный список, следует помнить, что в него не включены работы по устранению различных исключительных ситуаций, так как они не носят циклический характер. Последний блок - это циклы, определяемые общими процессами в организации. Почти в каждой организации существуют регламентные работы в информационной системе, связанные с общими циклами операционной работы. В российских кредитных организациях данными циклами являются: * конец операционного дня; * конец месяца; * конец года. Несмотря на название, данные циклы не точно совпадают с указанными интервалами. В большинстве российских банках конец операционного дня приходится на середину следующего календарного дня. Часто случаются задержки на несколько суток. Также случаются события, называемые "откат операционного дня", приводящие к повторному выполнению всех связанных процедур. Для отдела информационных технологий подобные события обычно связаны со следующими работами: - установкой запрета на внесение изменений в закрытый период времени; - резервным копированием; - формированием отчетности; - расчетами различных итоговых параметров системы; - обновлением системных справочников. Рассмотрим порядок проведения наиболее распространенных регламентных работ в российской кредитной организации.
Резервное копирование и архивирование
Резервное копирование является основным видом работ, связанных с сохранностью данных. Основная идея резервного копирования - создание копии текущего состояния системы в формате, позволяющем восстановить ее часть или полностью в случае потери данных в результате технического сбоя, нарушения безопасности, пожара или других непредвиденных событий. Приведем основные параметры системы резервного копирования. Метод резервного копирования - использование различных методов резервного копирования обычно определяется тремя противоборствующими факторами, в числе которых требование к непрерывности работы, максимальная оперативность восстановления, стоимость системы копирования и резервной копии. Для реализации этих требований в современных системах применяются различные варианты резервного копирования, объединенные в три основные группы. 1. Холодное резервирование - самый простой и соответственно самый дешевый метод создания копии, часто вовсе не требующий затрат. Основывается на остановке работы системы и прямом копировании файлов. Большинство систем, не требующих непрерывной круглосуточной работы, копируются именно этим способом. 2. Горячее резервирование дампа (состояния на момент времени) системы - механизм основывается на способности системы сохранять полную информацию о своем состоянии на определенный момент времени. Данная информация и является объектом резервирования. Этот подход обычно используется в системах, требующих непрерывной работы, но при этом имеющих свободные вычислительные ресурсы в течение дневного цикла. Кроме того, к системе не должны предъявляться жесткие требования по скорости восстановления. Стоимость подобного решения обычно определяется стоимостью дополнительного функционала программной части системы, реализующего этот механизм. 3. Оперативное горячее резервирование - этот подход является самым дорогостоящим и сложным в реализации, однако он обеспечивает оперативную поддержку резервной копии. Для его реализации могут использоваться два механизма: репликация и кластеризация. При репликации на резервную систему передаются команды высокого уровня, о выполнении которых содержатся функции записи. При кластеризации передаются команды низкого уровня непосредственной записи на диск. Недостатком данного подхода является то, что он защищает систему только от технических сбоев. Все ошибки, связанные с программной или пользовательской составляющими системы, будут немедленно скопированы на резервную систему и станут недоступными для исправления путем восстановления. Объем потерянных данных при восстановлении. Сеансовые методы резервного копирования подразумевают наличие данных, которые не вошли в последнюю резервную копию. При восстановлении таких систем проводится повторная регистрация данных. Их объем определяется частотой резервного копирования. Время восстановления. Большинство систем резервного копирования требуют время на восстановление системы. Обычно в этот период система недоступна в эксплуатации, что приводит к потерям, связанным с простоем в работе организации. В отличие от резервирования главной целью архивирования является удаление из активной части системы устаревших данных. Это позволяет уменьшить объем хранимых в оперативной области системы данных и, как следствие, повысить производительность и снизить системные требования. В общем случае архивирование не является стандартным требованием к работе системы и используется только в случае быстрорастущего хранилища данных. Промышленные СУБД и прочие информационные системы, эксплуатируемые в режиме высокой нагрузки, требуют постоянного контроля и профилактических действий над производительностью со стороны системного администратора. Данная работа включает в себя следующие элементы. Сбор системной статистики не влияет впрямую на параметры системы, однако построение диаграмм зависимости различных параметров системы от времени, количества пользователей, информационных потоков и от других параметров имеет важное прикладное значение. Разделение задач системы по времени. Самым дешевым решением по увеличению производительности системы является перенос времени выполнения различных процедур на время минимальной загруженности системы. Запуск процедур самооптимизации системы. Большинство крупных систем имеют административные процедуры, связанные с переиндексацией данных или изменением структуры хранения данных. Существование таких процедур объясняется различиями в требованиях к механизмам хранения между процедурами записи и чтения данных. Система, выполняя запись данных с максимальной производительностью, затем преобразует ее в более удобную для чтения форму. Изменение настроек системы. Современные СУБД могут иметь сотни параметров, корректировка которых доступна администратору. В большинстве случаев бывает достаточно значений по умолчанию. Но в ряде случаев в зависимости от специфики задачи более тонкая настройка может существенно увеличить производительность или устойчивость системы. Оптимизация аппаратной платформы. Наиболее простым вариантом увеличения производительности является замена одних аппаратных компонентов системы на другие или их настройка для достижения большей производительности или объема хранимых данных.
Внесение оперативных изменений в систему
Конкуренция и изменения внешних условий требуют от организации постоянного движения в развитии бизнес-процедур и непрерывной модификации информационной системы. При этом часто бюджет организации не позволяет создавать новый проект на каждое новое изменение в системе, что делает их частью ежедневной оперативной работы, в которую входят: - разработка новых отчетов и печатных форм; - изменения в документопотоке системы; - администрирование пользователей системы и их обучение; - изменение отдельных функций системы.
Обеспечение актуальной справочной информации
Под внешними справочниками информационной системы подразумеваются таблицы данных, формируемые внешними источниками. К ним относятся: * справочники финансовых инструментов: - справочник валют; - справочник ценных бумаг сторонних эмитентов; * справочники участников рынка: - справочники банков; - справочники юридических лиц; * справочники законодательных актов. Список может быть дополнен и другими справочниками в зависимости от деятельности организации. Особенностью работы по обеспечению актуальной информации является то, что роль ИТ-подразделения состоит в техническом обеспечении своевременной загрузки данных. За полноту данных и поиск источников обычно отвечают потребители этой информации. Однако дополнительной задачей для ИТ-подразделения при выполнении этой работы является обобщение требований и предлагаемых источников от различных потребителей и построение единой справочной системы организации вместо разрозненных баз данных.
Наряду с преимуществами информационные системы таят в себе и опасности, среди которых возможность несанкционированного доступа к информации и даже осуществления операций. Информационная безопасность является важнейшим аспектом информационных технологий и направлена на защиту как клиентской, так и внутренней информации от несанкционированных действий. Стремительное развитие информационных систем в российских банках делает проблему защиты информации еще более актуальной. Несмотря на то что по сравнению с западными банками доля автоматизированных бизнес-процессов в нашей стране все же ниже, случаи нарушений деятельности банков в результате информационных сбоев, как умышленных, так и неумышленных, становятся все более частыми. Развитие информационных технологий в кредитных организациях привело к тому, что в настоящее время информационные системы стали частью организации в целом, ее кровеносной и нервной системой. Любой сбой в движении информационных потоков или нарушение правил доступа к ним приводят к проблемам в работе всей организации и, как следствие, к дополнительным расходам или упущенной выгоде. Сохранение информационной системы в рабочем состоянии и полный контроль ее использования - главная задача ИТ-департамента организации. Для этого создаются системы информационной безопасности. Их цель - предотвращение и устранение исключительных ситуаций в работе информационных систем. Сам термин "информационная безопасность" первоначально использовался для определения комплекса мер по защите информации от несанкционированных действий. Однако практика показала, что общий объем ущерба, наносимый информационным системам осознанно, в результате противоправных действий, ниже ущерба, возникающего в результате ошибок и сбоев. Поэтому в настоящий момент понятие информационной безопасности включает в себя весь комплекс мер по предотвращению и устранению сбоев в работе информационных систем, по организации и защите информационных потоков от несанкционированного доступа и использования. Рассматривая информационную безопасность, следует иметь в виду именно единую систему, включающую в себя на только комплекс мер по предотвращению и выявлению нарушений, но и механизмы восстановления работоспособности и снижения ущерба, полученного в результате исключительного события. Данная глава рассматривает основные правила построения такой системы. В ней обсуждаются причины различных сбоев и нарушений в системе, методы защиты и восстановления, а также предлагается методика оценки затрат на создание системы информационной безопасности. Информационная система рассматривается нами как единое целое программно-аппаратного комплекса и человеческих ресурсов. Под нарушением будет пониматься любое нерегламентированное событие в информационной системе, способное привести к нежелательным для организации последствиям. Остановимся на основных группах таких событий более подробно. В нашей классификации их три: нарушения конфиденциальности, изменения в системе, утрата работоспособности. Причиной возникновения проблем данной группы является нарушение движения информационных потоков или ошибки в системе доступа. Из-за того, что данные виды нарушений никак не влияют на состояние системы, выявить их очень сложно. Только небольшое число подобных нарушений можно вычислить в результате анализа файлов протокола доступа к отдельным объектам системы. Для иллюстрации рассмотрим наиболее часто встречающиеся примеры нарушения доступа к информации: * ошибки администрирования: - неправильное формирование групп пользователей и определение прав их доступа; - отсутствие политики формирования паролей пользователей. При этом до 50% пользователей используют простые, легко подбираемые пароли, такие, как "123456", "qwerty" или собственное имя; - ошибки в формировании итоговых и агрегированных отчетов и доступа к ним. Примером может являться отчет по выпискам из счетов банка или сводный бухгалтерский журнал, которые хранят всю информацию по операциям кредитной организации и формируются в бухгалтерии, где за доступом к данным отчетам часто не ведется контроль; - наличие открытого доступа для представителей сторонней организации, выполняющей какие-либо подрядные работы; * ошибки проектирования информационной системы: - использование недостаточно защищенной среды для разработки информационной системы. Очень часто, особенно для систем, располагаемых на локальных компьютерах, доступ к информации можно получить не через интерфейс программы, который требует пароля, а напрямую читая из таблиц базы данных; - ошибки алгоритмов доступа к данным. Особенно это касается разработки систем криптозащиты, где часто вместо дорогостоящих систем в целях экономии используются собственные разработки, только эмитирующие систему защиты; - небрежность в разработке системы защиты. Один из примеров данной небрежности - забытая разработчиками точка доступа в систему, такая, как универсальный пароль; * небрежность пользователей в вопросах информационной безопасности: - нарушение хранения паролей для доступа в информационную систему. Иногда пользователи просто пишут пароль на бумаге и оставляют ее около компьютера. Особенно это распространено в организациях, где администратор системы требует сложных паролей, которые легко забыть. Также часто встречается абсолютно недопустимая практика передачи паролей сотрудниками друг другу; - сохранение закрытого соединения после окончания работы. Уходя на обед или домой, пользователь не выключает компьютер и не выходит из банковской системы. Если система не имеет механизма временного отключения неактивных пользователей, данное нарушение делает бессмысленным большинство других требований системы безопасности; - нерегламентированное обсуждение зарытой информации. При рассмотрении данного нарушения особенно следует обращать внимание на сотрудников информационных служб; * умышленный взлом системы:
| |||||