Задачи и внедрение Бизнес-стратегия Стратегия в области ит основные тенденции развития ит - реферат

Книга А.В. Тютюнника и А.С. Шевелева посвящена теоретическим и практическим вопросам управления информационными системами (ИС), которые становятся все более актуальными. Актуальность книги настоящего издания обусловлена двумя обстоятельствами.

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

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

Фирма-потребитель (в данном случае - КБ) заинтересована в быстром и бесконфликтном внедрении ИС. Мнение неспециалистов о том, что инсталляция и есть внедрение, верно только для так называемых коробочных решений. На самом деле инсталляция лишь начинает внедрение ИС, которое проходит в большинстве случаев весьма болезненно. Это связано с тем, что новая технология еще полноценно не заработала, а старая (предметная) технология подвергается проверке при внедрении новой и обнаруживает в ней ошибки. Такая ситуация может повлечь за собой противостояние разработчиков АБС и сотрудников КБ. Кроме того, сотрудники банка вынуждены довольно долгое время вести обе технологии одновременно: старую (поскольку они в ней уверены и к ней привыкли) и новую (поскольку на нее придется, так или иначе, переходить). Еще одна "неприятность", которая является следствием внедрения ИТ - изменение функциональных обязанностей лиц, принимающих решения (ЛПР) в системе управления. Изменение их функциональных обязанностей ведет к необходимости обучения персонала ИТ и изменения организационной структуры управления объектом. Следствием этого являются либо появление иных или дополнительных обязанностей у ЛПР (оптимистический вариант), либо увольнение ненужных сотрудников (пессимистический вариант).

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

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

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

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

Доктор экономических наук, профессор, заведующий кафедрой

информационного менеджмента и электронной коммерции

Московского государственного университета

экономики, статистики и информатики (МЭСИ)

В.В. Дик

Авторы считают своим долгом выразить благодарность всем тем, кто оказал помощь при подготовке этой книги и содействовал нашему профессиональному росту, в том числе Джереми Фостеру, Хорхе Ивашкевичу, Стивену Тиммонсу, Джону Йанни, Роменскому Артему Александровичу, Парфенову Дмитрию Александровичу, Глазкову Александру Валерьевичу, Овсию Валерию Ивановичу.

За содействие в сборе информации по поставщикам банковских информационных систем авторы приносят благодарность Королеву Денису Михайловичу.

Авторы также выражают благодарность руководству и специалистам компаний 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 .

Таблица 1

ИТ-затраты на одного сотрудника (в долларах)

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

│Суммарные данные │ За год │ За три года │За десять лет│

│по всем отраслям │ (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│

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

Таблица 2

Доля ИТ-бюджета от общих доходов (в %)

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

│Суммарные данные │ За год │ За три года │ За десять лет │

│по всем отраслям │ (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│

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

Таблица 3

Количество поддерживаемых пользователей сотрудником ИТ

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

│Суммарные данные │ За год │ За три года │ За десять лет │

│по всем отраслям │ (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) .

Таблица 4

Распределение бюджетов ИТ в финансовых организациях (в %)

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

│ Расходы на ИТ │ За год │ За три года │ За десять лет │

│ │ (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) .

Таблица 5

Изменение бюджетов ИТ в финансовых организациях (в %)

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

│ Бюджет ИТ │ За год │ За три года │ За десять лет │

│ │ (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). Такие процедуры направлены на предотвращение, обнаружение или смягчение нежелательных последствий совмещения обязанностей. Примером таких контрольных процедур являются периодическая проверка, аудит, протоколирование действий, документирование, специализированные программные продукты и т.п.

Таблица 6

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 7

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

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

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

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

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

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

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

│ │прочее │ │

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 8

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 9

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

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

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

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

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

│ 1 │ 2 │

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

│ │системы; │

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

│ │системы │

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

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

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

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

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

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

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

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

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

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

Таблица 10

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* конец года.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 11

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

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

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

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

│ 1 │ 2 │ 3 │

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

│ │системы │ │

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

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

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

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

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

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

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

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

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

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

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

│системы │ │ │

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 12

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

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

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

│ │ │ работ │

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

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

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

│ │S = S1 + дельтаS х T, │ │

│ │где S1 - стоимость информации; │ │

│ │дельтаS - стоимость обновления; │ │

│ │Т - период утечки данных │ │

│Изменения в│Зависит от частоты обращения к измененной│Стоимость восстановительных│

│системе, включая│области. Если данная область является│работ здесь зависит от двух│

│технические сбои и│ключевой в системе, то зависит от времени│составляющих: S = S1 х T +│

│умышленные действия │устранения данного нарушения. Аналитической│S2, где S1 - стоимость поиска│

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

│ │выражение: │Т - время поиска│

│ │S = суммаi (S1i + Se x T1i + Sp (T2i + T3i), │неисправности; │

│ │где S1i - разовый ущерб для каждого случая; │S2 - стоимость устранения │

│ │Se - стоимость эксплуатации с неисправной│ │

│ │системой; │ │

│ │Т1i - время обнаружения факта нарушения,│ │

│ │может меняться от случая к случаю; │ │

│ │Sp(t) - ущерб от простоя системы связанный с│ │

│ │устранением последствий. Данная функция часто│ │

│ │носит ступенчатый характер; │ │

│ │T2i - время диагностики; │ │

│ │T3i - время устранения неисправности │ │

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

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

Влияние систем защиты на развитие бизнеса

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

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

(S(T) - S) x T + 1%(Т) > (S1 x (%)t + Sa x Т)/К,

где S(T) - функция ожидаемого дохода от нового продукта, зависит от времени;

S - сумма требуемого дохода от рассматриваемого продукта;

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

1%(Т) - получаемая прибыль за счет вторичного использования средств, полученных в качестве дохода от рассматриваемого продукта;

S1 - разовая инвестиция в систему информационной безопасности;

(%)t - потерянная прибыль от использования вложенных средств;

Sa - затраты на сопровождение;

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

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

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

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

* снижение требуемого уровня рентабельности новой услуги;

* применение решений, проверенных в других организациях.

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

Аудит информационных систем

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

Цели и задачи аудита ИС

Целью ИТ-аудита является совершенствование системы контроля за ИТ. Для этого аудиторы выполняют следующие задачи:

- осуществляют оценку рисков ИТ;

- содействуют предотвращению и смягчению сбоев ИС;

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

- помогают подготавливать нормативные документы;

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

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

- осуществляют проведение периодических проверок;

- содействуют ИТ-менеджерам в правильной организации управления ИТ;

- осуществляют "взгляд со стороны".

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

Регулирование аудита информационных систем

Вопросу аудита и внутреннего контроля за информационными системами посвящены несколько зарубежных стандартов аудита и специальный российский стандарт "Аудит в условиях компьютерной обработки данных (КОД)". Из зарубежных источников можно отметить международный стандарт аудита ISA 401, положения по международной практике аудита 1002, 1003, 1004, 1008, 1009. В них отражены вопросы практики аудита в среде компьютерных информационных систем, оценки рисков и надежности системы внутреннего контроля в условиях КОД, техника проведения аудита с учетом использования современных информационных технологий.

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

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

Технология аудита информационных систем

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

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

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

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

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

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

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

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

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

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

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

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

- порядок внесения изменений в программные продукты, смены версий, санкционированность и проработанность подобных действий, так как именно процесс изменений не только сам по себе несет существенные риски, но и способствует выявлению или обострению смежных проблем;

- система протоколирования всех действий пользователей в информационных системах, предоставляющая возможность оперативного контроля и проведения внутренних расследований;

- надежность системного программного обеспечения и используемой СУБД (системы управления базой данных), которые так же, как и технические средства, являются повышенным источником риска;

- достаточность функциональных возможностей и удобство осуществления операций в системах автоматизации, что необходимо для достижения большей эффективности от использования современных ИТ;

- наличие верификации прав доступа (подтверждения одним пользователем действий другого) и последующего контроля за данными в информационных системах;

- корректность алгоритмов, результатов и периодичности автоматических процедур, которые, как правило, в современных банковских системах осуществляются без участия пользователя (расчет курсовой разницы, процентов по кредитам и депозитам, открытой валютной позиции, консолидация);

- корректность справочных данных, используемых при различных расчетах и операциях в информационных системах (курсы валют, процентные ставки, банковские идентификационные коды).

Направления проверки технологии организации и использования компьютерной обработки данных достаточно разнообразны:

* общая структура служб ИТ и ее соответствие поставленным задачам;

* существование и реализация плана развития информационных технологий, что является необходимым при современном темпе технологических нововведений;

* регламентация действий пользователей информационных систем как часть обязательного и с точки зрения общего управления, и с точки зрения управления качеством регламентирования всех внутренних банковских процессов;

* оценка системы поддержки (сопровождения) пользователей, так как при некачественном сопровождении повышается риск неправильных, ошибочных действий вследствие непонимания особенностей информационных систем;

* технология разработки и внедрения отдельных приложений, которая должна ограничивать банк от использования не соответствующих требованиям пользователей и содержащих большое количество ошибок программных продуктов, а также исключать зависимость от ключевого ИТ-персонала (при собственной разработке);

* технологии проведения отдельных операций с точки зрения их соответствия регламентам, политике информационной безопасности, удобства и эффективности их автоматизации;

* технология работы с особо критичными системами и их участками, прежде всего такими, как платежные терминалы и системы передачи данных между различными программными комплексами;

* наличие системы обеспечения деятельности при возникновении чрезвычайных ситуаций, а именно плана действий резервной вычислительной площадки и возможности быстрого восстановления данных.

Описанный выше подход является первой практической реакцией на требования дня. При более глубоком анализе проблемы становится очевидно, что следует широко (комплексно) подходить к ее решению. Необходимо дать аудиторам (как внутренним, так и внешним) методологию проверки, содержащую программу аудита, основные критичные циклы, систему оценки, возможность делать не только замечания, но и давать рекомендации по улучшению. Но многие аудиторы не имеют специальных технических знаний и самостоятельно не способны разработать методику проверки ИС. С другой стороны, для минимизации рисков в условиях компьютерной обработки данных необходимо не только проводить проверку, аудит ИС, но и правильно построить управление ими, внедрить эффективную систему внутреннего контроля. Что же делать в этой ситуации? К счастью, решение существует - это уже упоминавшийся СоblТ.

Нами были приведены общая схема описанных областей, их составляющие и система взаимодействия, которая в методологии СоblТ называется "золотое правило".

По каждой из областей эта методология содержит детальное описание аудита, рекомендации по оценке и совершенствованию внутреннего контроля, то есть все то, что мы уже отмечали и что так необходимо с точки зрения аудита в условиях компьютерной обработки данных. Методология СоblТ представляет собой набор из нескольких книг: руководство по аудиту, руководство для менеджмента, контрольные процедуры, руководство по внедрению.

Однако следует отметить, что внедрение подобной методологии является сложной задачей и не всегда может быть осуществлено без посторонней консалтинговой помощи. Это связано с тем, что в процессе внедрения необходимо оценить последовательность действий и сформулировать систему приоритетов. Также часто необходим практический опыт организации подобных процессов в других организациях.

Широкое использование информационных технологий в современной организации трансформирует задачи внутреннего и внешнего контроля и аудита, которые все больше переориентируются на компьютерные системы и технологии. Это соотносится с потребностью в аудите, обращенном не столько на проверку достоверности отчетности и соответствия учетных процедур, сколько на предотвращение негативных явлений в деятельности организаций, на глубинный анализ и прогнозирование финансового состояния, управление рисками, в том числе и информационных систем, что в конечном счете еще более укрепляет описанные выше тенденции и подталкивает организации на использование передовых международных подходов в области аудита в условиях компьютерной обработки данных.

Примеры выявленных проблем

Для иллюстрации приведем отчет по результатам аудита информационных систем банка внешним аудитором - крупнейшей международной консалтинговой компанией (табл. 13 ).

Таблица 13

Отчет по результатам аудита информационных систем банка

┌─────────────────────┬────────────────────────┬────────────────────────────────────────────────┬──────────┐

│ Ситуация │ Риск │ Рекомендация │ Приоритет│

├─────────────────────┼────────────────────────┼────────────────────────────────────────────────┼──────────┤

│ 1 │ 2 │ 3 │ 4 │

│Стратегия ИТ│Подобная ситуация может│Мы рекомендуем банку: передать функцию│ !!! │

│существует, однако ее│привести к│стратегического планирования в области ИТ│ │

│основные направления│несоответствию целей и│высшему руководству банка; │ │

│не доведены до│задач ИТ│распределить обязанности по стратегическому│ │

│сведения многих│бизнес-стратегии, что в│планированию в области ИТ; │ │

│работников банка и│свою очередь может│формализовать и задокументировать стратегический│ │

│руководителей │привести к│план в области ИТ, включая определение│ │

│функциональных │неэффективному │бизнес-задач и потребностей для ИТ, анализ│ │

│подразделений │использованию бюджета ИТ│технологических решений и текущей│ │

│ │и повышенным затратам │инфраструктуры, оценку требуемых организационных│ │

│ │ │изменений и существующих систем, направления│ │

│ │ │развития ИТ на срок от 3 до 5 лет; │ │

│ │ │разработать и внедрить процедуры оценки рисков│ │

│ │ │ИТ как часть системы корректировки стратегии в│ │

│ │ │области ИТ; │ │

│ │ │объединить стратегическое планирование в области│ │

│ │ │ИТ с функцией бизнес-планирования; распределить│ │

│ │ │ответственность за распространение информации о│ │

│ │ │стратегии ИТ по всем функциональным│ │

│ │ │подразделениям банка │ │

│Низкий уровень│Отсутствие регламентов и│Мы рекомендуем разработать и утвердить процедуры│ !! │

│документирования │документирования │документирования для основных технических и│ │

│ключевых процессов в│ИТ-процедур повышает│операционных процессов в области ИТ и│ │

│области ИТ. В ходе│уровень операционных и│осуществлять регулярный контроль за выполнением│ │

│обследования мы│системных рисков банка.│этих процедур со стороны руководства банка.│ │

│отметили, что│Также при этой ситуации│Необходимо разработать процедуры, которые│ │

│отсутствуют │затруднен контроль за│обеспечат возможность последующего контроля за│ │

│внутренние регламенты│функционированием ИТ и│соблюдением указанных процессов и стандартов ИТ │ │

│и документирование│их эффективностью.│ │ │

│большинства │Помимо этого, отсутствие│ │ │

│направлений │надлежащей документации│ │ │

│деятельности ИТ-служб│повышает риск│ │ │

│ │зависимости от ключевых│ │ │

│ │сотрудников службы ИТ,│ │ │

│ │их опыта и знаний │ │ │

│Отсутствие системы│Неадекватная │Мы рекомендуем внедрить систему анализа│ !! │

│анализа инвестиций в│инвестиционная политика│инвестиций в ИТ. Мы полагаем, что политика│ │

│ИТ. В ходе обзора мы│резко увеличивает риски│инвестиций в области ИТ должна включать│ │

│отметили, что процесс│дефицита бюджета,│следующие пункты: определение ответственных за│ │

│бюджетного │конфликта ресурсов│этот процесс сотрудников банка; │ │

│планирования, в том│/инвестиций, а также│систему показателей и алгоритм расчета│ │

│числе и для ИТ,│риск низкой окупаемости│инвестиций в области ИТ; │ │

│ведется на регулярной│инвестиций в области ИТ.│расчет инвестиционной политики в области ИТ и│ │

│основе. Однако в│Возможно неэффективное│окупаемости инвестиций с финансовой и│ │

│банке отсутствуют│использование ресурсов│нефинансовой точек зрения; оценка всех возможных│ │

│процедуры оценки│банка. В случае│альтернативных вариантов инвестиций в ИТ; │ │

│эффективности │отсутствия │анализ передового опыта отрасли при выборе│ │

│вложений в ИТ,│предварительного │инвестиций в области ИТ; │ │

│практика отношения к│планирования в области│постоянный процесс совершенствования│ │

│расходам на ИТ как к│инвестиций в ИТ высшее│инвестиционной политики в области ИТ. │ │

│внутренним │руководство может│Как дополнительные моменты и показатели, которые│ │

│инвестициям │недооценить их│необходимо учитывать при осуществлении│ │

│ │значимость для│инвестиционной политики, мы рекомендуем│ │

│ │деятельности банка и│анализировать следующие параметры: процент│ │

│ │принимать управленческие│ИТ-проектов (от общего числа), не укладывающихся│ │

│ │решения, не владея│в бюджет; │ │

│ │реальной информацией об│процент ИТ-проектов, для которых не│ │

│ │отдаче от ИТ │производилась предварительная оценка│ │

│ │ │эффективности инвестиций; процент ИТ-проектов,│ │

│ │ │которые после внедрения не достигли требуемых│ │

│ │ │инвестиционных показателей (нормы рентабельности│ │

│ │ │и времени самоокупаемости); число ИТ-проектов,│ │

│ │ │при осуществлении которых, несмотря на наличие│ │

│ │ │утвержденного бюджета, возникли инвестиционные│ │

│ │ │конфликты (недостаток или несвоевременность│ │

│ │ │инвестиций); │ │

│ │ │время между возникновением отклонения в│ │

│ │ │осуществлении проекта и решением этой проблемы│ │

│ │ │руководством; процент ИТ-проектов, которые после│ │

│ │ │внедрения так и не достигли требуемых│ │

│ │ │бизнес-целей │ │

│Отсутствие │Отсутствие системы│Мы рекомендуем следующие мероприятия:│ !!! │

│риск-менеджмента в│управления рисками ИТ│сформировать функцию управления рисками внутри│ │

│области ИТ. Анализ│может привести к│подразделения ИТ; │ │

│рисков в сфере ИТ│увеличению числа│распределить, задокументировать и утвердить на│ │

│осуществляется только│проектов, незаконченных│уровне высшего руководства систему│ │

│в отдельных, наиболее│вовремя или вышедших за│ответственности и процедуры риск-менеджмента; │ │

│критичных, случаях на│рамки бюджета. Это также│разработать систему классификации и оценки│ │

│нерегулярной основе.│приводит к увеличению│рисков ИС; │ │

│При этом не│количества нештатных│анализировать результаты ИТ-проектов в ходе и│ │

│существует │ситуаций и сбоев в│после их завершения с точки зрения управления│ │

│методологии оценки и│работе информационных│рисками; │ │

│управления рисками и│систем. Неадекватное│сформировать системы превентивных мер,│ │

│утвержденных │управление рисками может│направленных на предотвращение и снижение рисков│ │

│внутренних процедур│подорвать финансовое и│ │ │

│на этот счет │стратегическое положение│ │ │

│ │банка │ │ │

│В банке отсутствует│Низкий уровень│Создание комитета по ИТ или│ !! │

│информационно-техно- │информирования высшего│информационно-технологического комитета при│ │

│логический комитет│руководства о проблемах│правлении поможет оптимизировать работу│ │

│при правлении │в области ИТ; проблемы│подразделения ИТ и упростит процесс│ │

│ │решаются недостаточно│урегулирования проблем, с которыми сталкивается│ │

│ │оперативно. │подразделение ИТ. Комитет по ИТ должен│ │

│ │Неэффективная система│оперативно решать стратегические задачи в│ │

│ │контроля за ИТ повышает│области ИТ, а также обеспечивать получение│ │

│ │внутренние риски │своевременной ответной реакции (обратную связь).│ │

│ │ │Кроме этого, комитет по ИТ будет способствовать│ │

│ │ │повышению эффективности контроля за│ │

│ │ │деятельностью ИТ-служб │ │

│Неэффективное │Низкое качество│Необходимо разработать четкую процедуру,│ ! │

│построение │обслуживания │регламентирующую права и обязанности│ │

│обслуживания │пользователей, │пользователей и сотрудников ИТ. Мы рекомендуем│ │

│пользователей ИС. Мы│неоперативность решения│разработать базу данных службы технической│ │

│отметили, что│проблем и ликвидации│поддержки с тем, чтобы все заявки пользователей│ │

│отсутствуют │сбоев в информационных│регистрировались сотрудниками ИТ. Этот│ │

│внутренние │системах. В результате│внутренний инструмент позволит оптимизировать│ │

│регламенты, │повышается риск сбоя│деятельность специалистов ИТ и проводить│ │

│регулирующие │систем, который может│мониторинг их работы. Кроме того, база данных│ │

│отношения │привести к потере│обеспечит аналитическую информацию об уровне│ │

│пользователей и│информации. Отсутствие│компьютерной подготовки пользователей, наиболее│ │

│сотрудников ИТ. В│статистических данных по│типичных проблемах, а также позволит определить│ │

│банке отсутствует│типам и количеству│те области в организации ИТ и информационных│ │

│служба технической│ИТ-проблем затрудняет│систем, которые необходимо усовершенствовать │ │

│поддержки в форме│принятие управленческих│ │ │

│help-desk с│решений. Нет возможности│ │ │

│обязательной │контролировать и│ │ │

│регистрацией всех│координировать работу│ │ │

│обращений и четкими│службы технической│ │ │

│стандартами на время│поддержки │ │ │

│и качество обработки│ │ │ │

│запросов │ │ │ │

│пользователей. В│ │ │ │

│настоящее время│ │ │ │

│заявки пользователей│ │ │ │

│не регистрируются и│ │ │ │

│не анализируются.│ │ │ │

│Соответственно не│ │ │ │

│осуществляется │ │ │ │

│официальный │ │ │ │

│мониторинг объема│ │ │ │

│работы и видов│ │ │ │

│проблем, с которыми│ │ │ │

│сталкиваются │ │ │ │

│специалисты ИТ │ │ │ │

│Отсутствие члена│Затруднения при│Возложение ответственности за ИТ на члена│ !! │

│правления банка,│оперативном решении│правления банка будет способствовать оптимизации│ │

│курирующего ИТ │проблем ИТ, низкий│процесса решения проблем и повышению│ │

│ │уровень информирования│эффективности деятельности подразделения ИТ │ │

│ │правления о проблемах в│ │ │

│ │области ИТ │ │ │

│Политика │Конфиденциальность и│Мы рекомендуем обновить и детализировать│ !! │

│информационной │стабильность │официальное положение по информационной│ │

│безопасности банка│информационных систем│безопасности. За основу может быть взята│ │

│недостаточно детальна│имеет большое значение│следующая структура этого документа. │ │

│ │для деятельности банка.│Часть 1. Управление информационной│ │

│ │Неадекватное управление│безопасностью. │ │

│ │информационной │1.1. Введение. │ │

│ │безопасностью может│1.2. Обязанности руководства и сотрудников. │ │

│ │привести к финансовым│1.3. Ключевые позиции. │ │

│ │потерям и раскрытию│1.4. Основные требования к пользователям ИС. │ │

│ │конфиденциальной │1.5. Классификация и анализ рисков. │ │

│ │информации │1.6. Классификация информации. │ │

│ │ │1.7. Использование сетевого и│ │

│ │ │телекоммуникационного оборудования. │ │

│ │ │1.8. Правила резервирования данных. │ │

│ │ │1.9. Поддержка информационной безопасности.│ │

│ │ │Часть 2. Стандарты информационной защиты. │ │

│ │ │2.1. Аппаратная защита. │ │

│ │ │2.2. Защита от несанкционированных действий. │ │

│ │ │2.3. Программная защита. │ │

│ │ │2.4. Защита локальной вычислительной сети. │ │

│ │ │2.5. Стандарты информационной безопасности при│ │

│ │ │разработке и модернизации программ. │ │

│ │ │2.6. Информационная защита серверов и│ │

│ │ │автоматизированных рабочих мест. │ │

│ │ │2.7. Взаимодействие с третьими лицами. │ │

│ │ │2.8. Хранение данных │ │

│Требования временного│Отсутствие сотрудника,│Мы рекомендуем назначить администратора по│ !! │

│положения по│постоянно │безопасности в соответствии с существующими│ │

│управлению доступом│контролирующего │требованиями и провести внутреннюю проверку│ │

│не выполняются.│информационную │соблюдения корпоративных норм информационной│ │

│Некоторые требования│безопасность, может│безопасности │ │

│временного положения│привести к несоблюдению│ │ │

│банка об управлении│внутренних норм в этой│ │ │

│доступом │области и, как│ │ │

│пользователей │следствие, к увеличению│ │ │

│нарушаются. В│риска │ │ │

│частности, внутренним│несанкционированных │ │ │

│положением банка│действий с информацией │ │ │

│введена позиция│ │ │ │

│администратора банка,│ │ │ │

│однако сотрудника,│ │ │ │

│выполняющего эти│ │ │ │

│функции, в банке нет.│ │ │ │

│Также нарушается ряд│ │ │ │

│положений, │ │ │ │

│ограничивающих доступ│ │ │ │

│к наиболее критичным│ │ │ │

│информационным │ │ │ │

│ресурсам │ │ │ │

│Отсутствие │Неадекватный контроль за│Мы рекомендуем внедрить и использовать│ !!! │

│внутреннего аудита│ИТ повышает риск сбоя в│эффективную систему внутреннего контроля при│ │

│информационных систем│работе ИТ. Отсутствие│обработке данных. По нашему мнению, банку│ │

│ │функции аудита ИС может│следует предпринять следующие шаги: разработать│ │

│ │привести к неточному и│письменное руководство по проведению аудита ИС; │ │

│ │ненадежному процессу│назначить внутренних аудиторов; правление должно│ │

│ │обработки данных, а│регулярно анализировать и подтверждать│ │

│ │также снизить│квалификацию и независимость аудиторов;│ │

│ │информационную │определить объем и частоту проведения│ │

│ │безопасность │аудиторских проверок, а также методики│ │

│ │ │проведения аудита; разработать план действий│ │

│ │ │руководства для устранения существенных│ │

│ │ │недостатков, отмеченных в отчетах аудиторов. │ │

│ │ │Мы рекомендуем проводить внешние независимые│ │

│ │ │аудиторские проверки ИС по крайней мере раз в│ │

│ │ │два года, даже если в банке регулярно проводится│ │

│ │ │внутренний аудит │ │

│Большое количество│Применение различных│Мы рекомендуем рассмотреть возможность│ ! │

│используемых │платформ может привести│сокращения количества используемых платформ. По│ │

│технологических │к проблемам при│нашему мнению, было бы целесообразно отказаться│ │

│платформ. В ходе│интеграции данных, а│от использования, например, платформы Windows NT│ │

│проверки мы отметили,│также существенно│ │ │

│что банк применяет│усложняет их│ │ │

│различные платформы,│обслуживание и│ │ │

│включая Windows NT,│поддержку. Кроме того,│ │ │

│Novell NetWare и│обслуживание данных│ │ │

│Unix. Windows NT│платформ сопряжено с│ │ │

│используется для│существенными затратами,│ │ │

│некоторых специальных│которые могут быть│ │ │

│задач, например для│снижены при│ │ │

│обеспечения услуг│использовании меньшего│ │ │

│внутренней почты.│количества разнородных│ │ │

│Novell NetWare│платформ │ │ │

│используется как│ │ │ │

│файловый сервер, a│ │ │ │

│Unix - для АБС XXX │ │ │ │

│Отсутствие │Обслуживание базы данных│Мы рекомендуем назначить сертифицированного│ !! │

│сертифицированного │Oracle требует наличия│администратора базы данных Oracle (DBA) или│ │

│администратора базы│определенных навыков и│организовать специальное обучение│ │

│данных. Мы отметили,│опыта. Неадекватное│администраторов Oracle, работающих в настоящее│ │

│что в банке│обслуживание базы данных│время в банке │ │

│отсутствует │Oracle может привести к│ │ │

│сертифицированный │замедлению или даже сбою│ │ │

│администратор базы│в работе этой базы│ │ │

│данных Oracle │данных │ │ │

│Использование │Дальнейшие разработки в│Банку следует рассмотреть возможность замены│ !!! │

│неподдерживаемого │системе SWIFT не будут│программного обеспечения, обеспечивающего│ │

│разработчиком ПО.│поддерживаться │интерфейс с системой SWIFT │ │

│Установленное │существующим интерфейсом│ │ │

│программное │SWIFT │ │ │

│обеспечение для SWIFT│ │ │ │

│не поддерживается│ │ │ │

│разработчиком (MERVA)│ │ │ │

│Файлы аудита действий│Несанкционированные │Файлы аудита действий пользователей в ЛВС│ !! │

│пользователей ЛВС не│действия, которые│(лог-файлы) должны быть активизированы в│ │

│анализируются. Работа│потенциально могут быть│операционных системах - Windows NT, Novell│ │

│сотрудников и внешних│осуществлены │NetWare и Unix. Сотрудники службы ИТ или│ │

│консультантов в│пользователями, не будут│информационной безопасности должны иметь доступ│ │

│локальной │вовремя выявлены │к данным файлам и регулярно анализировать их в│ │

│вычислительной сети│ │целях контроля за действиями персонала. Также│ │

│контролируется при│ │можно рекомендовать использование специальных│ │

│помощи файлов аудита│ │программ для анализа и эффективного мониторинга│ │

│(лог-файлов), с│ │действий пользователей. В ходе процесса│ │

│помощью которых│ │резервирования необходимо также периодически│ │

│возможно │ │создавать резервные копии лог-файлов │ │

│протоколирование всех│ │ │ │

│действий │ │ │ │

│пользователей. Однако│ │ │ │

│сотрудники ИТ не│ │ │ │

│имеют возможности│ │ │ │

│регулярно │ │ │ │

│анализировать │ │ │ │

│информацию о работе│ │ │ │

│пользователей, в│ │ │ │

│основном из-за│ │ │ │

│нехватки кадровых│ │ │ │

│ресурсов │ │ │ │

│Передача │Передача информации│Для защиты информации при передаче по внешним│ !!! │

│конфиденциальных │через открытые каналы│каналам связи необходимо применять│ │

│данных по открытым│повышает риск│соответствующие процедуры криптографической│ │

│каналам. В настоящее│несанкционированного │защиты на всех внешних каналах │ │

│время банк, его│доступа, модификации,│ │ │

│филиалы и внешние│раскрытия или потери│ │ │

│организации │информации │ │ │

│обмениваются │ │ │ │

│информацией через│ │ │ │

│открытые каналы, не│ │ │ │

│защищенные │ │ │ │

│криптографическими │ │ │ │

│механизмами │ │ │ │

│Доступ к директории│Данный факт повышает│Мы рекомендуем банку ограничить существующие│ !! │

│платежей. В ходе│риск │права доступа к критичным сетевым директориям.│ │

│нашего обзора мы│несанкционированного │Права доступа к директории, предназначенной для│ │

│отметили, что четыре│доступа к платежной│отправки платежей в ЦБ РФ, должны быть│ │

│сотрудника расчетного│системе и мошенничества│предоставлены только тем сотрудникам, которые│ │

│отдела имеют доступ к│при осуществлении│работают с указанной директорией в ходе│ │

│директории платежей│платежных операций банка│выполнения возложенных на них функций.│ │

│ЦБ РФ. Кроме того, к│ │Сотрудники ИТ должны быть лишены права доступа к│ │

│указанной директории│ │данной директории │ │

│имеют доступ│ │ │ │

│некоторые сотрудники│ │ │ │

│подразделения ИТ │ │ │ │

│Недостаточная длина│Пароли с│Банку необходимо провести проверку соблюдения│ !!! │

│паролей. Мы отметили,│несоответствующей длиной│парольной политики и не допускать использования│ │

│что некоторые│повышают риск│паролей менее чем из 6 символов │ │

│сотрудники ИТ не│несанкционированного │ │ │

│выполняют заявленных│доступа к базе данных,│ │ │

│внутренними │что в свою очередь может│ │ │

│регламентами │привести к│ │ │

│требований к│несанкционированному │ │ │

│количеству символов│раскрытию или изменению│ │ │

│пароля к ИС. Один из│информации │ │ │

│сотрудников службы ИТ│ │ │ │

│использует пароль для│ │ │ │

│системы "Новая│ │ │ │

│Афина", состоящий из│ │ │ │

│3 символов. При этом│ │ │ │

│он имеет полный│ │ │ │

│доступ к базе данных │ │ │ │

│Доступ в серверную│Повышается риск│Серверная комната должна закрываться при помощи│ !! │

│комнату не ограничен│несанкционированного │электронного замка. Следует рассмотреть│ │

│как следует. Серверы│доступа к критичному│возможность установки системы видеонаблюдения │ │

│расположены в│компьютерному │ │ │

│комнате, которая│оборудованию │ │ │

│запирается на│ │ │ │

│стандартный замок.│ │ │ │

│Как правило, дверь│ │ │ │

│серверной комнаты не│ │ │ │

│закрывается. │ │ │ │

│Существует свободный│ │ │ │

│доступ к компьютерам│ │ │ │

│и ключевым системам │ │ │ │

│Физический доступ к│Данная ситуация повышает│Необходимо ограничить физический доступ к│ !!! │

│платежным терминалам│риск │указанным терминалам исключительно│ │

│SWIFT и рублевых│несанкционированного │уполномоченным сотрудникам. Терминалы SWIFT и│ │

│платежей не│доступа к функции│терминал рублевых платежей должны быть│ │

│ограничен. Данные│внешних платежей и│расположены в отдельной комнате. Следует│ │

│терминалы расположены│повышает возможность│рассмотреть возможность установки системы│ │

│в большом зале,│несанкционированных │видеонаблюдения за терминалами │ │

│доступ в который│переводов денежных│ │ │

│практически не│средств от имени банка │ │ │

│ограничен. В зале,│ │ │ │

│где расположены│ │ │ │

│терминалы, │ │ │ │

│функционируют четыре│ │ │ │

│различных │ │ │ │

│подразделения, │ │ │ │

│которые не имеют│ │ │ │

│отношения к указанным│ │ │ │

│терминалам. Кроме│ │ │ │

│того, там же│ │ │ │

│находится ксерокс,│ │ │ │

│используемый │ │ │ │

│сотрудниками банка, и│ │ │ │

│производится │ │ │ │

│обслуживание клиентов│ │ │ │

│Хранение ключевых│Повышается риск│Ключевая дискета должна храниться в сейфе │ !!! │

│дискет не│несанкционированного │ │ │

│соответствует │доступа к платежным│ │ │

│требованиям. В ходе│терминалам │ │ │

│обзора мы отметили,│ │ │ │

│что ключевая дискета│ │ │ │

│программы отправки│ │ │ │

│рублевых платежей│ │ │ │

│"Конва" не хранится в│ │ │ │

│сейфе, как того│ │ │ │

│требуют внутренние│ │ │ │

│положения банка и│ │ │ │

│инструкции ЦБ РФ │ │ │ │

│В банке отсутствует│Компьютерные системы│Мы рекомендуем провести анализ возможных рисков│ !! │

│план действий на│банка являются важным│деятельности банка, определить наиболее│ │

│случай чрезвычайной│компонентом в его│критичные сферы деятельности и подготовить общий│ │

│ситуации. В настоящее│успешной операционной│порядок действий сотрудников банка при│ │

│время ИТ-службой│деятельности, и если│возникновении чрезвычайных ситуаций. Такой│ │

│разработан ряд│произойдет │порядок действий должен предусматривать четкое│ │

│отдельных мер по│продолжительный сбой в│распределение ответственности между│ │

│восстановлению данных│компьютерных системах│специалистами банка по восстановлению│ │

│и замене оборудования│банка, это может│работоспособности системы, примерный перечень│ │

│в случае его выхода│сказаться самым│действий, возможные причины возникновения│ │

│из строя. Однако на│негативным образом на│ситуации, а также масштаб возможных потерь для│ │

│сегодняшний момент не│его деятельности и│деятельности банка. │ │

│существует плана│привести к│Разработанный документ должен быть утвержден│ │

│восстановления │дополнительным потерям │руководством банка и доведен до сведения всех│ │

│компьютерных систем в│ │ответственных специалистов │ │

│случае чрезвычайных│ │ │ │

│ситуаций │ │ │ │

│Отсутствие стороннего│Ввиду того, что все│Мы рекомендуем хранить резервные копии за│ ! │

│хранения резервных│резервные файлы хранятся│пределами здания │ │

│копий данных. В банке│в одном и том же здании,│ │ │

│внедрены процедуры│аварийная ситуация,│ │ │

│создания резервных│например пожар в здании,│ │ │

│файлов. Однако все│может полностью│ │ │

│резервные копии│уничтожить критичную│ │ │

│хранятся в этом же│информацию. В результате│ │ │

│здании │этого банку, возможно,│ │ │

│ │придется приостановить│ │ │

│ │свои операции │ │ │

│Серверная комната не│Риск повреждения или│Мы рекомендуем банку предпринять следующие шаги:│ ! │

│оборудована │выхода из строя│разработать и протестировать план тушения пожара│ │

│противопожарной │ключевого оборудования в│и эвакуации ключевого оборудования; обеспечить│ │

│газовой системой │случае пожара возрастает│наличие газовых огнетушителей в серверных│ │

│ │ │комнатах │ │

│В используемом банком│Отсутствие процедуры│Мы рекомендуем внедрить процедуру верификации│ !!! │

│программном │верификации может│валютных платежей, а также систему их│ │

│обеспечении │привести к│последующего контроля │ │

│отсутствует процедура│непреднамеренным ошибкам│ │ │

│верификации │или мошенничеству │ │ │

│международных │ │ │ │

│переводов. Все вводы│ │ │ │

│данных для платежей в│ │ │ │

│иностранной валюте│ │ │ │

│осуществляются одним│ │ │ │

│исполнителем │ │ │ │

└─────────────────────┴────────────────────────┴────────────────────────────────────────────────┴──────────┘

Часть 3. Управление проектами в области ИТ

Управление изменениями

При реализации проектов в области ИТ в первую очередь стоит помнить об их основной цели - содействии развитию бизнеса, внедрению передовых технологий и решений. Но эффективное развитие невозможно, если в организации не приветствуются инновации и нововведения. Поэтому цель - поддержка изменений. Но что такое изменения и зачем они нужны? Как управлять этим процессом? И какое все это имеет отношение к проектному управлению в области ИТ?

Необходимость преобразований

Одним из принципиальных моментов, определяющих эволюцию каждого менеджера и организации в целом, является осознание необходимости постоянных изменений. Как только организация хоть на время "останавливается" или просто уменьшает темп своего развития, она начинает сразу сдавать свои позиции.

Постоянные изменения стали одним из отличительных знаков нашего времени. Они затрагивают практически все области. Меняется сам уклад жизни, восприятие людей, хозяйственные отношения.

Непрерывно изменяющаяся внешняя среда уже сама по себе обусловливает для коммерческих организаций необходимость следовать всем новейшим тенденциям. Многие возразят, что "здоровый" консерватизм еще никому не мешал. Однако правы они будут лишь отчасти. Когда-то консерватизм, возможно, и был обязателен во многих сферах деятельности, но в настоящей экономической ситуации он является полным анахронизмом. Это можно хорошо проиллюстрировать на примере таких, как считалось раньше, консервативных сфер бизнеса, как банковское дело или страховой бизнес. Сегодня они отвергают большинство традиционных подходов и активно меняют практику своей работы, не боясь "кидаться в омут" неизведанного и нового. Связано это с тем, что, не отслеживая тенденции рынка, запросы потребителей, новейшие технологические достижения, сегодня невозможно удержать как собственные позиции, так и своего клиента, который становится более требовательным.

Не двигаться вперед - значит, двигаться назад. Этот тезис сегодня очевиден, но не так очевидны его предпосылки, а также причины возможного регресса. Попытаемся разобраться в них и обосновать необходимость постоянных преобразований.

Одной из основных причин такой необходимости можно назвать технологическую революцию последних десятилетий. Большинство других причин являются во многом следствиями глобальных изменений в научно-технической и технологических сферах. Именно они принципиально изменили картину гиперэкономического пространства, создав новую в истории человечества экономическую ситуацию, при которой потенциальное предложение на большинстве рынков существенно превышает спрос.

Практически всю историю человечества картина была обратной. Спрос в глобальном отношении был почти всегда ниже предложения, а на уровне отдельных рынков они уравновешивали друг друга в основном за счет ценового механизма. Кроме того, традиционная система экономических отношений в области макро- и микроэкономики базировалась на опыте предшествующих столетий. То есть при осуществлении деятельности в сфере производства или услуг, в том числе и в процессе менеджмента, не предполагалось, что предложение может в несколько раз превысить спрос или что спрос вообще будет отсутствовать.

Но картина неожиданно изменилась, и изменилась именно вследствие технологической революции, которая выразилась в резком росте производительности труда, перепроизводстве товаров и услуг, снятии коммуникативных и торговых барьеров, повышении уровня жизни в подавляющем большинстве стран, что в свою очередь кардинально изменило отношения производителей с потребителями, клиентами и, что вполне закономерно, в этой ситуации резко обострило конкурентную борьбу. Последние две причины в максимальной степени отразились на экономических отношениях в различных сферах коммерческой деятельности, в том числе в банковском секторе экономики.

Клиенты стали не просто требовательными, но и грамотными. Кроме того, если десять лет назад производители "боролись за клиентов", то сегодня все успешные организации констатируют, что им приходиться "бороться не просто за клиентов, а уже за каждого клиента". Мы об этом говорили, когда рассматривали стратегию развития ИТ. Так, например, если раньше для банков основной интерес представляли крупные корпоративные клиенты, то сегодня идет борьба даже за самое маленькое предприятие с ничтожными оборотами и несколькими работниками. А за рубежом ситуация еще в несколько раз жестче. Там давно идет борьба и за таких, казалось бы, недоходных для банка клиентов, как частные лица, пенсионеры и студенты. Естественно, связано это напрямую с перепроизводством и другими следствиями технологической революции.

Другая важная причина, толкающая коммерческие организации на путь постоянных изменений, как мы уже отмечали, - активная конкурентная борьба. Она последние несколько лет активно ведется и в России. На весьма "прозрачном" банковском рынке все действия хорошо заметны, и это еще одна новая реалия, являющаяся следствием технологической революции. Рынки стали прозрачны и открыты, как никогда ранее. В этой ситуации достаточно какому-либо банку совершить ошибку или просто понизить качество предлагаемых услуг, он сразу начинает терять клиентскую базу. В то же время необходимо помнить, что даже высокоразвитому банку необходимо совершенствоваться, так как все положительное в его работе и технологиях достаточно быстро становится известным на рынке и активно внедряется конкурентами. Поэтому, чтобы находиться хотя бы в незначительном отрыве от конкурентов, необходимо постоянное изменение.

Еще одно следствие технологической революции заключается в том, что современные технологии и прежде всего вычислительные машины резко сократили период разработки товаров или услуг, тем самым еще более увеличивая возможность потенциального предложения. Эта причина также делает практически все рынки и сектора экономики более динамичными.

Однако помимо внешних существуют и внутренние причины, вызывающие необходимость постоянных, кардинальных изменений. Как ни странно, для крупных организаций они, может быть, более значимы. Любая организация (особенно крупный банк), даже если в момент своего основания она была построена по самой оптимальной схеме, через некоторое время утрачивает исходную оптимальность, приобретает функциональную и тактическую несогласованность, нелогичность, непрозрачность. Производственные процессы запутываются, происходит отклонение от основных изначальных ориентиров и приоритетов деятельности, ослабевает мотивация и т.п.

И все это может происходить по причинам не столько внешним, сколько внутренним. Этот феномен известен многим практикующим менеджерам. Причины могут варьироваться в зависимости от особенностей организации, но, как правило, они кроются в несовершенстве исполнителей, а именно: в субъективности их восприятия, привыкании к определенным негативным явлениям, сложности применения теоретических принципов к конкретным человеческим отношениям, банальной текучести кадров и приоритете личных интересов.

Все это приводит к постепенной деформации базисных принципов и ориентиров, отходу от оптимальности, нарастанию стихийности развития и в конечном итоге, если так можно выразиться, к "мутации" системы управления и организации в целом.

За рубежом считается, что любая организация не реже какого-либо определенного периода (в зависимости от своих размеров и особенностей - например, раз в семь лет) должна производить на основе детального анализа текущей ситуации полную реорганизацию (реинжиниринг) своей деятельности. Программа таких изменений может включать различные направления преобразований (реструктуризация, построение новой концепции взаимоотношений, мотивации и менеджмента, смена и/или переквалификация части специалистов, стратегическая переориентация, модернизация технологической и информационной базы, реинжиниринг основных и вспомогательных бизнес-процессов, системы управления в соответствии со стратегическими целями и т.д.).

Все вышесказанное объясняет острую необходимость постоянных изменений, актуальность которых в российских условиях еще выше, так как в отличие от зарубежных стран, где все эти глобальные изменения хотя и происходили стремительно, но все-таки не в течение десяти лет, как это было у нас.

Общий подход: теория и практика

Но вывод о необходимости постоянных изменений не является панацеей от возникновения новых и новых проблем. Каким образом сделать так, чтобы необходимые изменения были не только осознаны и теоретически сформулированы менеджментом, но и практически реализованы? Тут скрываются наиболее серьезные трудности.

Очень часто бывает, что какие-то изменения очевидны, более того, уже обсуждены и даже "приняты" руководством, но тем не менее либо внедряются так долго, что теряют актуальность, либо вообще не внедряются. Тому есть разные причины. Во-первых, это консерватизм людей, привычка к текущей ситуации и даже боязнь, нежелание каких-либо изменений. Все это весьма часто встречается именно в крупных организациях. Во-вторых, несоответствие или даже противоположность интересов разных групп людей внутри крупной организации, возникающих из-за нежелания делиться полномочиями, ограничивать свою власть, брать на себя больше ответственности; это также может быть просто страх существенного сокращения численности своего подразделения. Практика показывает, что внедрение чего-то нового в подразделении влечет за собой существенное сокращение. Это одна из самых сложных управленческих задач, однако решать ее все-таки приходится.

С теоретической точки зрения управление изменениями (Change Management) - это отдельный и не менее сложный, чем разработка самих изменений, вопрос. Существует множество разнообразных научных теорий, направленных на решение данной задачи. Одной из наиболее простых и в то же время часто используемых на практике является теория, предложенная американским ученым-психологом Куртом Левином.

Согласно Левину для управления какими-либо изменениями или преобразованиями чрезвычайно важно понимать природу изменений и их восприятие, их отражение в человеческой психике. Несмотря на то что теория Левина возникла в 40-х годах XX века, она до сих пор считается одним из базовых подходов в управлении изменениями. По концепции Левина для правильного внедрения какого-либо изменения необходимо пройти три стадии: "размораживание", "движение" и "замораживание". Основная идея заключается в том, что при создании изменений обязательно необходимы, помимо собственно преобразований, подготовительная стадия и стадия закрепления результатов.

Подготовительная стадия, или "размораживание", ставит своей основной целью сделать текущее положение еще хуже и невыносимее, довести его до абсурда. Таким образом сознательно развивается ощущение необходимости перемен и их неотвратимости у всех заинтересованных лиц. Кроме того, эта стадия предполагает активизацию деятельности по различным направлениям, связанным с объектом изменений, причем без каких-либо определенных целей, кроме как "расшевелить улей". Все это приводит к тому, что объект (коллектив кредитной организации) вступает в стадию психологической готовности к предстоящим изменениям.

Стадия "движения" предполагает проведение всех запланированных изменений и естественное в этих условиях преодоление препятствий. При этом Левин советует относиться к изменениям именно как к "движению". Необходимо соблюдать определенные и известные участникам преобразований правила, четко понимать не только цель движения, но и маршрут, не стараться двигаться чересчур быстро, другими словами, "не превышать скорости".

Последняя и, возможно, наиболее важная стадия - "замораживание" - ставит целью сделать осуществленные изменения необратимыми, то есть закрепить (или "заморозить") их. Эта стадия особенно важна, так как на практике часто даже после успешного осуществления преобразования ситуация постепенно может обращаться вспять. Это связано с тем, что первое время для объекта изменений (человека или группы людей) его предыдущее состояние по-прежнему является более естественным, знакомым, и по нему может возникать своеобразная "ностальгия". Поэтому, чтобы не произошло "плавного отхода назад", новое состояние необходимо зафиксировать, или "заморозить". Это достигается разными способами, к которым можно отнести средства мотивации как психологического, так и материального плана, разъяснение преимуществ текущей ситуации, обеспечение видения перспектив и новых возможностей.

Рассмотрев вопросы снятия психологических противоречий при проведении изменений, необходимо остановиться и на основных практических подходах к решению задачи управления изменениями при проведении преобразований в кредитных организациях. Рассмотрим, каким образом при возникновении проблем в банках решалась на практике задача внедрения изменений.

Первый возможный подход заключается в централизованном и жестком управлении всеми изменениями со стороны высшего руководства. Для этого, например, в банке вводится постоянная штатная единица - заместитель председателя правления по развитию. Очень важен и принципиален для этого подхода именно высокий уровень лица, ответственного за развитие и изменения, так как в процессе внедрения изменений постоянно возникает необходимость решать множество вопросов, и именно бесконечные согласования и обсуждения способны затормозить любой процесс. Вследствие этого человеку, ответственному за процесс развития банка, необходимы существенные полномочия для принятия решений и контроля исполнения, включая доступ к процессу материального стимулирования сотрудников без дополнительных согласований.

При этом никакая текущая работа, кроме управления изменениями и развитием, не должна входить в обязанности такого руководителя, поскольку данная работа требует очень больших усилий и напряжения и практически всегда связана с решением конфликтных ситуаций. Ответственность данного руководителя в этом случае будет полностью распространяться на все преобразования, и если они не будут осуществлены, значит он не справился со своей работой.

Подобного рода руководителю напрямую должны подчиняться некоторые организационные структуры, с помощью которых он сможет осуществлять аналитическую обработку информации, быструю и грамотную подготовку необходимых материалов, описание и моделирование бизнес-процессов с помощью современного инструментария, анализ правовых аспектов нововведений и их экономического эффекта. Такой подход к управлению изменениями достаточно часто встречается в зарубежных банках. В России некоторые кредитные организации стараются его использовать, и на практике он достаточно эффективен.

Второй подход основывается на том, что в большинстве случаев причиной невозможности практического внедрения каких-то изменений является наличие различных интересов у разных групп исполнителей, руководителей или подразделений. Что удобно одним, кажется неудобным и даже опасным другим. Поэтому для проведения преобразований необходимо в первую очередь снять подобные противоречия и противоположность интересов внутри организации (в большей степени это касается крупных организаций).

Этого можно достичь, например, на основе создания межфункциональных групп. В кредитной организации создается (на постоянной основе или под конкретный проект) группа менеджеров и специалистов, участвующих в осуществлении тех или иных банковских процессов. Группа формируется из наиболее авторитетных и творчески мыслящих представителей всех подразделений, которым доверяют остальные сотрудники и которые выступают одновременно экспертами и защитниками интересов своих групп. Руководство банка наделяет эту группу (комитет) достаточно высокими полномочиями по управлению изменениями. Внутри группы вводится система стимулирования ее участников в зависимости не от осуществления их функциональных обязанностей, а от практической реализации проекта, чтобы снять противоречия интересов. Потенциальный финансовый интерес участников должен быть существенно выше их текущих доходов, чтобы компенсировать возможную потерю ими административных позиций, а также чтобы избежать разногласия внутри группы. При этом другие специалисты и менеджеры банка, не входящие в эту группу, весьма сплоченную вследствие единства и сопряженности целей, не смогут существенно ей противодействовать, и необходимые изменения будут достаточно быстро и активно внедряться в практику.

Третий подход заключается в признании банком невозможности или высокой сложности самостоятельного управления изменениями и активном привлечении для решения этой задачи (в рамках конкретных проектов) сторонних организаций, в первую очередь специализированных консалтинговых и технологических компаний. В этом случае часть полномочий по решению оперативных вопросов и контролю ведения проекта передается внешним консультантам.

Такой подход имеет свои положительные стороны. Во-первых, ответственность за реализацию проектов также возлагается на стороннюю организацию, и оплата ее услуг может находиться в полной зависимости от практического внедрения каких-либо изменений. Во-вторых, такие организации имеют практический опыт решения подобных проблем и застрахованы в отличие от банка от типичных ошибок и промахов.

Разумеется, перечень предлагаемых подходов к решению рассматриваемых проблем не является исчерпывающим, тем не менее они дают представление о практически проверенных способах управления изменениями и решении сложной задачи внедрения нововведений, совершенствования технологии и системы функционирования организации в целом.

Рассмотрим, каким образом должно производиться внесение изменений или полная реорганизация какого-либо банковского бизнес-процесса с точки зрения последовательности или порядка работ. Основные этапы можно сформулировать следующим образом:

- определение объектов изменений и их "размораживание";

- документирование текущей технологии работы и классификация бизнес-процессов;

- выработка критериев оптимизации и определение ограничивающих условий;

- анализ текущей технологии работы;

- выработка, согласование и документирование новой технологии;

- внедрение изменений;

- контроль эффективности осуществленных преобразований;

- корректировка и закрепление изменений. Теперь рассмотрим детально каждый из этих этапов.

Определение объектов изменений и их "размораживание"

Сначала следует выявить первостепенные объекты изменений. Необходимо в первую очередь браться за те направления преобразований, которые могут дать наибольший экономический эффект. С другой стороны, выбор первого объекта должен определяться наличием достаточно высоких шансов на успех, чтобы не выработалось устойчивое противодействие к преобразованиям в организации... И самое главное - не браться за все сразу. Это, как известно, приводит к тому, что не будет сделано ничего.

Также необходимо помнить о наличии подготовительной стадии (о которой говорилось выше, когда мы рассматривали теорию управления изменениями Левина).

Помимо этого, в рамках подготовительной стадии целесообразно заранее определить еще один момент. Учитывая особенности работ по реорганизации, необходимо заранее определить нормы защиты информации, которые будут способствовать свободному и беспрепятственному общению сотрудников организации с группой, осуществляющей изменения. Это необходимая мера, поскольку по необъяснимым причинам многие сотрудники слишком беспокоятся за сохранность и неразглашение информации, не являющейся конфиденциальной.

На подготовительной стадии также необходимо решить вопрос о финансировании работ по исследованию и подготовке к преобразованиям, так как они для своего выполнения потребуют определенных ресурсов, людских и денежных, потому что, даже если организация и не использует привлеченных специалистов, она обязательно должна разработать и внедрить систему дополнительной мотивации и поощрения сотрудников, непосредственно работающих над изменениями.

Документирование текущей технологии

Прежде чем начать основную работу по преобразованиям, следует тщательно изучить положение дел и детально описать процесс "как есть". Такое описание необходимо по многим причинам. Оно будет служить информационной базой для анализа и выработки преобразований, станет источником информации для экспертов, не знакомых с деталями технологии работы организации. Опираясь на данное описание, можно будет восстановить прежнюю практику работы в случае неудачных изменений. Таким образом, описание процесса "как есть" будет носителем знания и реальной практики работы и тем самым сможет защитить организацию.

Но для всех этих целей необходимо, чтобы описание было крайне точным и детальным. И здесь появляется проблема номер один при моделировании технологии работы - противоречие между требуемой детальностью описания и экономической эффективностью этого процесса. Совершенно очевидно, что чем точнее и детальнее описание, тем больше оно требует усилий, времени, ресурсов и, следовательно, существенно дороже. Практика показывает, что затраты на такое моделирование могут находиться в диапазоне от нескольких тысяч до сотен тысяч долларов. Поэтому необходимо находить компромисс, не забывая, что само по себе моделирование деятельности, без связи с преобразованиями, не имеет практически никакой стоимости.

Большинством экспертов признается, что подобное описание целесообразно осуществлять в графическом виде, например в виде SADT-диаграмм (вопросы методологии будут рассмотрены отдельно) с использованием современного программного инструментария в виде CASE-средств. Можно использовать как статические, так и динамические средства моделирования бизнес-процессов, в том числе основанные на других методологиях и стандартах. Выбор их следует осуществлять, исходя из необходимого уровня наглядности схем и предполагаемых сроков разработки таких схем, так как более сложные и наглядные средства моделирования бизнес-процессов подразумевают более сложный и дорогой процесс их оформления. В любом случае самые простые средства моделирования настолько доступны, что можно настоятельно рекомендовать не использовать собственные или недостаточно известные стандарты.

Цель такой работы заключается в создании там, где это необходимо, графического и текстового описания рассматриваемых процессов для дальнейших анализа, контроля и выработки рекомендаций по реорганизации.

Сбор требуемой информации осуществляется на основании регламентирующих документов банка, анкетирования и информации, полученной от сотрудников банка в результате личных бесед. Круг лиц, проводящих опрос, в зависимости от выбранной схемы управления изменениями может состоять из представителей специализированного подразделения, межфункциональной группы или внешних консультантов.

Опросить целесообразно всех сотрудников банка, кроме работников служб охраны, хозяйственного и технического обеспечения, водителей и секретарей. Категорически не рекомендуется опираться на информацию только руководителей подразделений, так как на практике они почти всегда стремятся приукрасить ситуацию и будут рассказывать не о том, как они работают, а о том, как должны или хотят работать. Другой интересный феномен, связанный со сбором информации по технологии работы, - достаточно высокая степень некорректности информации. Опять же практика показывает, что и рядовые исполнители очень часто склонны к искажению информации или ее неточной передаче. Поэтому все собранные данные необходимо тщательно проверять, сопоставляя информацию из различных источников или наблюдая непосредственно за работой специалистов.

Собранная информация поступает на обработку, которая включает следующие этапы:

* создание общей структурной модели банка (по подразделениям), а также модели предлагаемых услуг и обеспечивающих процессов в банке. Глубина данных моделей - сотрудник банка (главный бухгалтер, операционный работник отдела и т.д.) и услуга или процесс банка (расчетно-кассовое обслуживание, уплата налогов). Формулировка миссии, целей, задач и выполняемых функций подразделений банка;

* классификация и описание целей и задач бизнес-процессов, примеры которых приводились выше;

* описание и моделирование бизнес-процессов, определенных в предыдущем этапе. Глубина моделей - операции, выполняемые сотрудниками, документы и состояния документов (заполнить договор, подписать документ, расходный ордер, подтвержденный расходный ордер);

* обсуждение полноты и правильности построенной модели. Корректировка модели;

* разработка дополнительных аналитических документов или описаний (в зависимости от необходимости).

Далее мы рассмотрим, как формируются документы, необходимые для разработки программного обеспечения: функциональные и технические задания и спецификации (многие из преобразований требуют изменений или полной замены информационных систем организации).

Самым недорогим и в то же время достаточно эффективным для преобразований на уровне средних по размеру организаций является построение бизнес-моделей в форме блок-схем в соответствии со стандартом IDEF0 с использованием, например, программного продукта BPWIN*(6) , вид интерфейса которого изображен на рис. 15 .

"Рис. 15. Интерфейс программного продукта BPWIN"

Дополнительные описания являются приложениями к соответствующим схемам и включаются в файл модели в формате BPWIN, а в случае больших объемов представляются в формате документов MS WORD. При необходимости (и после предварительного согласования) можно дополнить бизнес-модель организации документами, выполненными в других форматах.

В построенной модели для среднего банка могут рассматриваться около 15-20 бизнес-процессов. Общий объем документации, описывающей технологию работы банка, - от 350 до 1000 страниц диаграмм и текста.

Критерии оптимизации и ограничивающие условия

Прежде чем приступить к анализу текущей ситуации и преобразованиям, необходимо четко обозначить критерии оптимизации и произвести ранжирование с точки зрения их значимости. Имеет смысл установить для каждого из критериев весовой коэффициент. Критерии зависят от текущего состояния кредитной организации и стратегических приоритетов в ее развитии. Базовыми критериями к разработке оптимизированной модели являются:

- снижение временных затрат на реализацию бизнес-процессов организации или выполнение отдельных операций;

- снижение стоимости предоставляемых услуг и обслуживающих процессов;

- повышение контролируемости деятельности организации на всех уровнях;

- масштабируемость или наращиваемость технологии и ее гибкость на предмет организации новых услуг и изменение под воздействием внешних факторов (законодательство или экономические обстоятельства);

- изменение соотношения между прямыми и косвенными затратами на реализацию бизнес-процессов организации;

- соответствие предлагаемых решений текущему законодательству и регламентирующим документам;

- повышение качества обслуживания клиентов;

- расширение спектра или увеличение объема операций.

Те или иные критерии для различных банков имеют разное значение. Так, например, сокращение расходов для некоторых из них может быть не так актуально, как увеличение скорости обслуживания.

Анализ текущей технологии работы

После того как бизнес-процесс детально исследован и "зарисован", определены объекты и цели или критерии оптимизации, естественно, должна наступить стадия его анализа и выработки основных направлений концепции его реорганизации. В рамках данного блока могут существовать следующие этапы:

* выявление и анализ операций, не добавляющих стоимости с точки зрения клиента;

* анализ данных с целью выявления однотипных операций в различных процессах, оценка возможности их объединения или исключения;

* анализ возможного видоизменения процессов. Рассматриваются варианты изменения документопотоков исходя из регламентированных условий. Строятся альтернативные модели бизнес-процессов или их отдельные составляющие в тех же стандартах, что и основная модель. Производится их описание, описание необходимых изменений и затрат на переход;

* поиск путей автоматизации отдельных операций. Рассматривается возможность использования компьютерных средств для автоматизации операций, сокращения трудозатрат исполнителей, упрощения операции. Производится оценка затрат и ожидаемого эффекта. Данный этап проводится совместно со службами, ответственными за автоматизацию;

* оценка стоимости каждой операции в масштабах банка. Оценочная стоимость операции включается в ее описание. Оценку операции можно проводить по следующим параметрам: длительность выполнения, количество и периодичность, ежедневные затраты ресурсов (переменные издержки), постоянные издержки, общие материальные затраты;

* анализ сложных операций с целью их разукрупнения и упрощения;

* анализ неоказываемых услуг и возможности предоставления их клиентам. Оценка действий, необходимых для этого, и ожидаемый экономический и маркетинговый эффект;

* сравнительный анализ текущих услуг и практики их осуществления в других банках с целью возможного повышения качества обслуживания и корректировки тарифной политики.

Направления анализа выбираются в зависимости от критериев оптимизации и объекта изменений.

Выработка, согласование и документирование новой технологии

Полученные идеи и результаты первичного обследования являются основой разработки новой технологии. Она осуществляется в несколько стадий.

Вначале определяется концепция потенциальных изменений. Предложения, поступившие в ходе предыдущих стадий, тщательно обсуждаются и оцениваются с точки зрения эффективности их внедрения. Поиск такой концепции - один из сложнейших моментов реинжиниринга, так как является во многом творческой работой. Отчасти поэтому, отчасти потому, что этому вопросу посвящено достаточно публикаций и внимания, в том числе со стороны прародителей теории реинжиниринга, мы не будем уделять ему отдельное внимание.

После выработки и согласования со всеми заинтересованными сторонами и высшим руководством концепции преобразований необходимо приступить к разработке новой технологии или технологической схемы "Как должно быть", описывающей все детали будущей технологии. Инструментальные средства разработки обеих схем "Как есть" и "Как должно быть" должны быть идентичны. Необходимость такого описания связана с невозможностью внедрения чего-то абстрактного, необходимостью проведения переобучения специалистов и т.д.

На основании концептуальной модели определяется порядок взаимодействия между подразделениями. Проводится наложение бизнес-процессов предоставления услуг на предлагаемую схему работы. Определяются регламентирующие документы и нормативные акты, управляющие рассматриваемыми процессами.

Далее производится заключительная детализация модели до элементарных бизнес-операций и технологических решений по их реализации. Параллельно производится корректировка модели в соответствии с возможностями ее реализации и техническими возможностями.

Модель "Как должно быть" также проходит несколько стадий согласований и после этого подлежит утверждению высшим руководством банка.

Внедрение изменений

После описания перспективной технологии, ее корректировки и окончательного утверждения во всех деталях необходимо разработать детальный план внедрения новой технологии с распределением сроков, контрольных точек и ответственных лиц. Такой план может содержать следующие пункты:

* разработка новых должностных инструкций в соответствии с измененными обязанностями исполнителей;

* корректировка учетной политики банка, других внутренних регламентов;

* обучение сотрудников новой технологии;

* прием экзаменов по результатам обучения;

* разработка или настройка программного обеспечения и т.д.;

* запуск новой технологии в опытную эксплуатацию;

* переход на полное промышленное использование новой технологии.

Все эти процедуры должны быть по возможности распараллелены и сопряжены по срокам для меньшей затраты времени на реализацию проекта в целом. Для представления сложных громоздких проектов и осуществления контроля за ними удобно использовать современные инструментальные средства управления проектами.

Достаточно простым примером такого средства может служить программный продут компании Microsoft - MS Project. Этот продукт позволяет автоматизировать распределение ресурсов, контроль выполнения отдельных этапов проекта и связанных задач, общее планирование. Он обладает возможностями планирования и распределения людских ресурсов, мониторинга нагрузок, построения сетевых графиков и Гант-диаграмм, гибкой системой отчетных форм, а также многими другими возможностями. Данный программный продукт в конечном счете облегчает непростую задачу управления проектами с десятками и даже сотнями подзадач, большинство из которых связаны различным образом с другими работами и большим количеством исполнителей. Внешний вид интерфейса данного программного продукта представлен на рис. 16 .

"Рис. 16. Вид интерфейса программного продукта Microsoft Project"

He менее важно заранее составить и утвердить бюджет преобразований, в котором будут запланированы все расходы, связанные с реализацией плана реинжиниринга. С учетом того что подавляющее число подобных проектов не укладываются в первоначальный бюджет и испытывают нехватку ресурсов, необходимо заранее на стадии бюджетного планирования заложить специальный резерв в размере 20-25% для покрытия возможных перерасходов.

Контроль эффективности осуществленных преобразований

После начала полного использования новой технологии необходимо произвести оценку эффективности проделанных изменений. При этом, если реальный эффект существенно ниже запланированного, не стоит расстраиваться, так как эта ситуация достаточно типична. Даже если после контрольного анализа осуществленных преобразований окажется, что эффективность их крайне низка или даже стремится к нулю, то есть только окупаются затраты, - это уже хорошо, и такие преобразования должны быть признаны положительными, и их имеет смысл продолжать.

Не стоит при этом забывать о таких следствиях, которые невозможно посчитать в денежном выражении, но которые приносят важные стратегические выгоды. Речь идет об общей активизации деятельности организации, создании у работников и менеджмента ощущения перспективы, дополнительной мотивации, росте интереса к организации со стороны и т.д.

Корректировка и закрепление изменений

На основании данных по реальной эффективности, а также результатов промышленной эксплуатации бывает необходимо осуществить корректировки в деятельности или внедренной технологии. Такие корректировки представляют собой незначительные изменения и возникают вследствие того, что решить все вопросы сразу практически невозможно. Относительно закрепления, или "замораживания", модифицированного процесса уже говорилось выше.

Организация проекта

Рассмотрев общие вопросы управления изменениями, настало время вернуться к области информационных технологий и рассмотреть организацию проектной работы, которая, как мы уже отмечали, является логичным продолжением проектов преобразований внутри организации и своей главной целью имеет практическую реализацию механизмов развития бизнеса.

Сразу стоит оговориться, что практику проектной работы мы будем рассматривать на основе проекта замены основной информационной системы банка, как и в первой части книги, где мы уже рассматривали работу по подбору решений на этом же примере. Это связано с тем, что это направление является одним из самых объемных и сложных в ИТ. Но все сказанное ниже будет актуально и для других ИТ-проектов, таких, как развитие интернет-услуг, замена компьютерного оборудования, автоматизация новых филиалов и т.п.

Проектная работа

Иногда кажется, что не существует причины, по которой бы организация, имеющая уверенно работающие структуры, стабильную, удовлетворяющую текущим требованиям информационную систему, решилась бы на дорогостоящий проект замены своей информационной базы. Более того, основная часть сотрудников и руководства полагает, что, купив и успешно внедрив у себя однажды то или иное информационное решение, организация навсегда закрыла для себя эту проблему.

Но жизнь опровергает подобное заблуждение. Независимо от типа организации, программного и аппаратного обеспечения, квалификации сотрудников каждый раз повторяется один и тот же сценарий жизни программного приложения. Он длится в среднем 10-15 лет, а при стремительном изменении внешней среды, как это было в последние годы у нас, - 5-7 лет. В течение этого времени программное обеспечение многократно дорабатывается, адаптируясь к новым условиям. Появляется большое количество различных дополнительных решений, реализованных вне рамок системы. При этом решения разрабатываются различными людьми, при полном отсутствии каких-либо стандартов и документации. Потом возникает необходимость установления связей между этими доработками, и количество проблем, требующих решения, возрастает многократно, становясь нерешаемыми.

В результате возникает ситуация, когда небольшое ядро, некогда являвшееся современной и перспективной системой, обрастает неконтролируемым множеством утилит и заплаток. Простое увольнение одного из программистов (средний срок работы программиста в кредитной организации 3-5 лет) приводит к полной переработке целой области информационных задач. Надежность, защищенность подобной системы не удовлетворяет никаким требованиям. И отсутствие проблем со службой безопасности объясняется только тем, что в России службы безопасности очень редко занимаются анализом программного обеспечения в банке. Любое изменение в правилах учета и обработки информации все сложнее реализуется в установленные сроки. Даже если компания-разработчик своевременно предоставляет все доработки, служба автоматизации банка не успевает своевременно адаптировать свои решения к новым условиям.

Попытка решить данную задачу приводит к тому, что менеджеры организации начинают обращать внимание на новые разработки, появляющиеся на рынке, и после очередной проблемы с устаревшей информационной системой принимают решения о покупке новой, которая, по их мнению, снимет большую часть проблем.

Однако выделенные деньги и поддержка руководства не гарантируют того, что проект будет удачным. Он может быть вообще нереализован. По данным ряда зарубежных консалтинговых агентств, около 20% проектов не внедряются. Хотя, если проект будет реализован, скорее всего затраты на него будут существенно выше ожидаемых. По тем же данным, только 16% проектов реализуются в соответствии с первоначальными планами, а затраты на реализацию остальных в среднем в 1,8 раза выше утвержденных бюджетом.

Рассмотрим, какие шаги придется выполнить организации, чтобы минимизировать потери и увеличить шанс успешного завершения проекта. Мы уже останавливались на особенностях проектной работы в самой первой главе, где проектный подход рассматривался как один из ключевых подходов к организации ИТ-службы банка. Но настало время остановиться на этом и рассмотреть отличия проектной и традиционной форм организации работы. Прежде всего нам необходимо определиться с тем, что же такое проект. Мы будем опираться на широко распространенную за рубежом методику управления проектами РМВОК 2000.

Итак, как правило, проекты направлены на выполнение каких-либо вполне определенных задач, связанных с достижением стратегических целей организации. Это происходит потому, что стратегические цели не могут быть достигнуты посредством текущей деятельности, они требуют создания изменений, а средство создания изменений - это проект.

Проекты обычно связаны с новой, уникальной и не повторяющейся или редко повторяющейся работой в отличие от обычной деятельности, которая носит регулярный характер. Поэтому они всегда носят временный характер, ограничены четкими временными раками, операционная же работа является преимущественно постоянной.

Согласно упомянутой выше методике проект - это любая деятельность, ограниченная во времени и направленная на создание уникального нового продукта, услуги или на достижение другой цели. Деятельность, ограниченная во времени, означает, что каждый проект имеет четко обозначенные начало и конец. Проекты осуществляются на всех уровнях организации, в них могут участвовать от нескольких человек до сотен людей.

Примеры проектов:

* разработка новой услуги;

* внутренние организационные изменения;

* реинжиниринг бизнес-процессов;

* разработка и внедрение новой информационной системы;

* внедрение новой бизнес-практики или процесса;

* развитие филиальной сети;

* техническое перевооружение;

* создание позитивного рыночного имиджа.

Общим между проектной и традиционной операционной организацией работ является то, что они выполняться людьми, используют ограниченные ресурсы, планируются и контролируются менеджментом.

Первичный анализ проекта

Первым шагом любого проект является определение его истинной цели. Необходимо, чтобы каждый участник четко понимал, почему организация вкладывает в проект огромные деньги вместо того, чтобы потратить их на зарплату или выплаты акционерам, какие преимущества по отношению к текущему состоянию он получит по завершению проекта. Только в этом случае участники проекта будут выступать единой командой, и шанс на его успешную реализацию существенно возрастет.

Следующим шагом является определение области проекта. Четкое ограничение рабочей области позволит существенно сократить время на обсуждение и согласование проекта.

После того как определены цель и область проекта, можно перейти к более детальной его проработке и описать условия выполнения. Результатом этого этапа (для нашего примера - замены информационной системы) должны стать ответы на следующие вопросы:

* Какой видится идеальная система? В данном ответе необходимо собрать описания идеальной системы от различных подразделений и определить набор параметров, которым она должна соответствовать.

* Какие параметры системы критичны и их значения? В продолжение предыдущего вопроса необходимо помимо идеальных значений определить минимально допустимые параметры.

* На каком ядре должна базироваться система? Ответ на этот вопрос может дать служба автоматизации на основе имеющегося опыта, наличии системных специалистов и уже имеющихся программно-аппаратных решений. Следует помнить, что, например, смена системы управления базами данных может стоить столько же, сколько и весь остальной проект.

* Каков общий бюджет проекта и каковы максимально допустимые затраты? Это разные величины, определяемые оптимистичным и пессимистичным прогнозами. Различаться на практике, исходя из предоставленных ранее данных, они могут в среднем в 2 раза, а иногда и более. При этом рекомендуется сначала определить максимально допустимую сумму и после этого переходить к сумме бюджета.

Результатом первичного анализа должно быть повторное решение о начале проекта. Учитывая, что первичный анализ не приводит к существенным затратам, принятие решения о временном отказе от проекта не будет психологической проблемой. При принятии повторного решения рекомендуется ответить на все те вопросы, которые уже рассматривались нами в главе "Выбор решений".

Возможно, обдумав все проблемы, которые возникнут при проекте, руководство банка примет решение повременить с его началом. Но если решение не изменилось, то начинается следующий этап.

Создание проектной команды

Для того чтобы решить задачи, направленные на достижение цели проекта, необходимо создать команду проекта под управлением менеджера проекта. При этом речь идет именно о команде со всеми ее признаками: у всех одна цель, хотя каждый имеет свои задачи, все принимают участие в решении важных вопросов, бюрократия сокращена до абсолютного минимума, все подчинено достижению цели, любые поощрения даются всем участникам проекта и только за достижение цели, неформальным лидером команды является самый опытный в решении текущего вопроса, члены команды консультируют друг друга.

Данный подход позволит консолидировать усилия и знания всех участников проекта. К сожалению, в большом количестве организаций объединить сотрудников подобным образом достаточно сложно. Часто различие в статусе подразделений настолько велико, что добиться полного сотрудничества кажется невозможным. Но тем не менее это необходимо.

Преодолеть это можно путем повышения статуса менеджера проекта. Хорошо, если его ранг будет уровня заместителя председателя банка. В этом случае различия между рядовыми участниками не будут казаться столь значительными, чтобы мешать работе. Для иллюстрации рассмотрим два примера.

Первый вариант. Руководитель проекта - начальник отдела автоматизации. Участники команды: сотрудник бухгалтерии (не самый опытный, поскольку самый опытный - главный бухгалтер - не может подчиняться начальнику отдела по статусу), сотрудники отдела автоматизации, казначей (человек, отвечающий за расходы), сотрудник фронт-офиса (тоже не руководитель). При такой организации в проектной группе образуются отношения, изображенные на рис. 17 .

Второй вариант. Руководитель проекта - вице-президент банка. Участники команды: главный бухгалтер, начальник отдела автоматизации, казначей (человек, отвечающий за расходы), руководитель фронт-офиса. Отношения в проектной группе при такой организации изображены на рис. 18 .

Как видно из схем, если руководитель проекта по статусу стоит выше всех остальных участников команды, имеющийся человеческий потенциал организации используется максимально эффективно. Это приводит к решению большей части задач с минимальным объемом затрат или совсем без них.

"Рис. 17. Схема взаимодействия при руководстве проектом (вариант 1)"

Стоит оговориться, что менеджер проекта может обладать высоким статусом, достаточным для решения всех задач, и не являясь членом правления организации. Так, он может иметь этот статус благодаря своим знаниям и опыту, то есть быть авторитетным экспертом организации или приглашенным со стороны менеджером. Причем этот последний вариант интересен тем, что при этом достигается очень важная составляющая - менеджер является независимым.

Постоянные работники организации слишком подвержены внутренним политическим и социальным отношениям, чтобы быть беспристрастными и профессиональными в полном объеме. Поэтому иногда их действия сложно объяснить. Они могут знать, что и как нужно сделать, но по определенным личным причинам не хотеть этого. Так, часто из-за боязни обнародования неудачи внутренние менеджеры стремятся затягивать проекты на годы, при этом обстоятельно аргументируя свою позицию, прикрываясь нуждами пользователей и необходимостью сделать все в лучшем виде.

"Рис. 18. Схема взаимодействия при руководстве проектом (вариантом 2)"

Особенно стоит обратить внимание на передачу ответственности за проектные затраты казначею. Вариантом такого решения может быть установка лимита затрат на проект с последующим премированием частью сэкономленных денег всех участников проекта. Другой приемлемый вариант - сосредоточение всех финансовых вопросов в руках менеджера проекта. В обоих случаях казначей будет выполнять также роль контролера всех затрат и роль аналитика, их оптимизирующего.

Несмотря на то что вклад руководителя проекта огромен, это ни в коем случае не умаляет роли самой команды. И здесь необходимо отметить несколько моментов. Команда должна подбираться исходя из социальной совместимости ее членов. Плюс к этому участники проекта должны уметь и любить работать в команде. Это умение может значить больше, чем собственный профессионализм, так как польза от задач, выполненных большим профессионалом-одиночкой, меньше, чем потенциальный вред для проекта от разрозненности, несогласованности, отсутствия единого подхода и тяги к нововведениям и изысканиям лучшего решения. Следующий важный аспект подбора команды состоит в том, чтобы оптимально подобрать команду единомышленников, которые при этом будут обладать максимально различными знаниями и умениями. Это связано с тем, что (в нашем примере в процессе смены информационной системы банка) во время реализации проекта всегда будут возникать сложные задачи из смежных областей, и тогда наличие в команде людей с разными знаниями и возможностями позволит решать максимально широкий объем задач без потери времени на поиск нужного специалиста или совета со стороны.

Отдельной темой является наличие времени у участников проекта для его выполнения. Любая деятельность во внерабочее время связана с дополнительными затратами, прямыми или косвенными. Грамотный руководитель проекта сведет такие работы к минимуму или откажется от них вовсе. Хорошим инструментом в поиске свободного времени является поденный месячный график выполняемых задач в течение месяца, а также почасовой график выполняемых задач за день (табл. 14 ). Для большинства специалистов кредитной организации данные графики неравномерны: там есть и пики, и периоды затишья, которые и являются временным резервом проекта. В общем использование резерва является бесплатным для организации. Иногда следует выполнить ряд работ, как правило, связанных с автоматизацией бизнес-процессов, для увеличения свободного рабочего времени. Автоматизация каких работ дает наибольший эффект, видно из построенных временных графиков (рис. 19 ).

В любом случае контроль за выполняемыми работами и за загруженностью участников проекта является одной из основных задач руководителя проекта, который должен стремиться к максимально оптимальному распределению задач исходя из особенностей каждого работника, плана проекта и их критичности.

Таблица 14

Пример таблицы ежедневной занятости специалистов

┌────────────┬───────────┬──────────┬────────────┬────────────┬────────────┬─────────┬────────┬────────┐

│ Сотрудник │ 9-10 │ 10-11 │ 11-12 │ 12-13 │ 14-15 │ 15-16 │ 16-17 │ 17-18 │

├────────────┼───────────┼──────────┴────────────┴────────────┼────────────┼─────────┴────────┴────────┤

│Специалист │Ожидание │Обслуживание клиентов │Обработка │Ожидание │

│операционно-│(30 мин).│ │документов. │ │

│го зала │Подготовка │ │Контроль и│ │

│ │выписок │ │подготовка к│ │

│ │клиенту │ │отправке │ │

├────────────┼───────────┼──────────┬────────────┬────────────┼────────────┼─────────┬─────────────────┤

│Экономист │Ожидание │Оформление│Формирование│Оформление │Ожидание │Контроль │Ожидание │

│бухгалтерии │ │входящих │документов и│собственных │ │отправки │ │

│ │ │платежей │отчетов │платежей │ │платежей │ │

│ │ │ │закрытия дня│банка │ │ │ │

├────────────┼───────────┼──────────┼────────────┼────────────┴────────────┼─────────┼─────────────────┤

│Специалист │Прием │Ожидание │Закрытие дня│Ожидание │Отправка │Ожидание │

│отдела │информации │ │в АБС │ │платежей │ │

│автоматиза- │из РКЦ.│ │ │ │ │ │

│ции │Печать │ │ │ │ │ │

│ │выписок по│ │ │ │ │ │

│ │счетам │ │ │ │ │ │

└────────────┴───────────┴──────────┴────────────┴─────────────────────────┴─────────┴─────────────────┘

"Рис. 19. Пример графика ежедневной занятости специалиста"

Предпроектное обследование

Обычно необходимость предпроектного обследования не вызывает сомнения. Если компания-разработчик объявляет его частью работ по внедрению, то отказать ей в этом невозможно, в противном случае с разработчика будет снята вся ответственность за возникающие проблемы. Если же для помощи приглашены сторонние консультанты, то предпроектное обследование и разработка на их основе перспективной схемы работы организации, а также плана перехода являются объектом их работы.

Однако результаты предпроектного обследования могут существенно различаться в зависимости от того, кто и по каким методикам его проводит. Результатами наиболее полного предпроектного обследования должны быть следующие документы:

* описание текущей деятельности организации и информационной системы. Данное описание становится более наглядным и полезным, если выполнено в графическом формате с текстовыми пояснительными записками;

* перечень документов, участвующих в документообороте, их состояние и печатные формы;

* альбом отчетности, формируемой в организации;

* перспективная модель организации после реструктуризации информационной системы, включая оптимизированную систему документооборота. Также необходимо провести полную экономическую оценку проекта;

* подробный план перехода от текущей модели к перспективной с указанием ресурсов, сроков и исполнителей;

* список доработок информационной системы, утвержденный к внедрению.

Учитывая большой объем предстоящих работ и необходимость проверенных методик для проведения подобного обследования, наиболее логично поручить их либо консалтинговым компаниям, либо специализированному подразделению компании-разработчика.

В ряде случаев можно обойтись сокращенным предпроектным обследованием. Это так называемая двухшаговая реализация проекта. Первый шаг - простая смена ядра системы без расширения функционала и оптимизации документооборота, второй шаг - реализация новых требований на уже работающем новом ядре. Данный подход более стабилен и снижает угрозу работоспособности организации в целом, однако требует большего времени. В этом случае в качестве предпроектного обследования достаточно описания текущего функционала информационной системы. Обследование может быть выполнено либо сотрудниками компании-разработчика, либо сотрудниками кредитной организации.

Несмотря на то что предпроектное обследование требует определенных финансовых затрат, по его результатам рекомендуется сделать дополнительное подтверждение решения о начале реализации проекта с учетом нового понимания объема работ, скорректированного бюджета и ожидаемого эффекта. Обоснованный отказ от проекта на данном этапе будет понят как акционерами, так и высшем руководством. Отказ от проекта на последующих этапах будет означать его провал и, как следствие, санкции для менеджеров и исполнителей.

Одним из важнейших результатов предпроектного обследования, независимо от выбранного сценария, должен стать план проекта, который настолько важен, что ему будет посвящена отдельная глава .

Составление плана работ

План работ строится на основе согласованного сторонами списка задач. Поэтому, прежде чем составлять план, они должны быть подготовлены. Обычно это происходит на той же стадии предпроектного обследования. Естественно, учесть все аспекты еще только начатых работ, их глубину и реальную трудоемкость невозможно, но тем не менее план проекта в первом приближении может и должен быть составлен именно на этой стадии. Впоследствии он будет расширяться, детализироваться, возможно, пересматриваться, но это не отрицает необходимости его наличия и согласования с самого начала проекта.

При составлении плана работ почти все участники проекта стремятся, чтобы их участие было как можно меньше. Исключением могут являться некоторые сотрудники отдела автоматизации, которые хотят, чтобы работа была как можно более интересной, желательно с решением "сложных" задач, объемной разработкой новых программ и покупкой оборудования. Как правило, эти люди контролируемы, но о них не стоит забывать. С другой стороны, и пользователи, заказчики зачастую пытаются автоматизировать операции, автоматизация которых не имеет никакого смысла, например операцию, которая возникает раз в полгода.

Реалистичность объема проектных задач и сроков - это первый экзамен, который должен успешно сдать менеджер проекта при начале работ и закрепить его в плане проекта. Самое легкое - отвечать на все предложения: "Мы это сделаем и очень скоро", ведь проект только начинается. Но ответственный руководитель проекта должен быть пессимистом, учитывать опыт других проектов и очень реалистично оценивать имеющиеся силы и ресурсы и уметь говорить "нет", аргументируя свою позицию. Менеджер проекта, видя перед собой постоянно основную цель проекта, должен уметь находить компромисс и убеждать все стороны.

Как же может быть сокращен и адекватно оценен объем требований? Основным приемом снижения объемов работ является поиск работающих прототипов. Если требуются новые отчеты при расчете налогов, надо выяснить, нет ли аналогичных отчетов в других областях. Если требуется организация новой услуги, надо посмотреть, как она реализована в других банках. А если ее там нет, то еще раз проанализировать ее необходимость.

Общий алгоритм поиска прототипа заключается в следующем. Сначала идет поиск аналогов решения всей задачи. Если их нет, то формулируется более общая задача и ищутся подобные решения. И так до тех пор, пока не будет найдено ближайшее по смыслу работающее решение. Затем определяются доработки к нему. Например, если нужна система межфилиальных расчетов, за основу можно взять систему расчетов в РКЦ или SWIFT, или систему "банк-клиент". Всегда есть аналогичные системы, доработка которых существенно дешевле и надежнее, чем разработка системы с нуля. Кроме того, если в приведенном примере система расчетов будет создаваться на базе системы "банк-клиент", то побочным эффектом будет расширение предлагаемого клиентам сервиса.

Другой универсальный механизм оценки адекватности требований и оправданности их автоматизации - это финансовая оценка. По каждой потенциальной задаче руководителем проекта может быть сделана оценка требуемого времени специалистов, учтены все необходимые другие ресурсы и в конечном счете получена оценка стоимости выполнения этой отдельной задачи. Она должна быть сравнима со стоимостью поддержки данной операции в "ручном" или полуавтоматическом режиме. Не очень умно автоматизировать получение отчета, затраты на ручное выполнение которого в десятки раз ниже стоимости доработки системы. Окончательное суждение в подобных вопросах должно принадлежать представителям бизнеса.

Рассмотрим теперь технические вопросы составления самого плана проекта. Самая лучшая формула, которой можно при этом руководствоваться, - это "Плохой план проекта сегодня лучше, чем хороший завтра". Многие руководители проектов пишут планы месяцами, они составляют десятки страниц. Но, к сожалению, их никак не могут дописать и согласовать. План может быть объемным, но 2-3-страничный план, особенно на начальных стадиях, не только является допустимым, но и более предпочтительным.

Из того, что обязательно должно быть в плане, - это ключевые точки (обучение, согласование детальных требований, презентация и корректировка прототипа, завершение разработки, начало и конец тестирования, исправление замечаний, начало и окончание пользовательского тестирования, дополнительное обучение, начало опытной эксплуатации, переход на промышленную эксплуатацию) с точным указанием времени их наступления. Также в плане должны найти свое отражение перечень основных задач и их взаимозависимость, распределение задач по этапам, ресурсное обеспечение и ответственные лица. Если все это есть и согласовано со всеми сторонами, то план достигает своей цели.

Ниже представлен пример планов проекта, выполненных в традиционном виде с помощью специального программного продукта MS Project, и более простой вариант плана проекта, подготовленный с использованием MS Excel (рис. 20 и 21 ).

"Рис. 20. План проекта в виде Гант-диаграммы, подготовленный в MS Project"

Детальная постановка задачи

Следующий этап - детальная постановка задачи. Корректная постановка задачи - уже повышение вероятности успеха и сокращение затрат на проект на 30-50%. Четкие ответы на вопрос "Что надо?" часто сразу дают ответ на вопрос "Как делать?". Особенностью российских правил учета является тот факт, что изменения в них часто носят весьма глобальный характер, в результате четкого понимания всех изменений на этапе начала проекта нет ни у кого в организации. Для решения этой проблемы используются приемы, которые рассмотрены ниже.

Описание глобальной цели проекта включает ответы на вопросы "Зачем?" как для внешней среды (Зачем ЦБ РФ издал такую инструкцию?), так и самой организации и ее подразделений (Зачем организации реализовывать этот проект?). Вариантов ответов на последний вопрос может быть несколько: "Чтобы организацию не оштрафовали" (самый неудачный ответ), "Данная инструкция позволит снизить операционные риски от совершения операций" и т.д. Анализ ответов позволит не только более точно понимать детали изменений, но и прогнозировать дальнейшие дополнения и исправления.

"Рис. 21. Упрощенный план-график проекта"

Создание единого информационного пространства проекта. В простейшем варианте оно представляет собой директорию, в которой все участники проекта записывают имеющуюся у них информацию и соображения по поводу решаемой задачи. Более сложным вариантом является организация интранет-конференции.

Использование ролевого моделирования процесса подразумевает обыгрывание несколько раз бизнес-процесса всеми его участниками с обязательной регистрацией всех выполняемых действий и пожеланий:

┌────────────────────────┐ ┌─────────────────────────────┐

│Сотрудник бухгалтерии: │ │Сотрудник отдел отчетности: │

│Я регистрирую документ│ │Я формирую отчет группировки│

│данного типа в АБС.│ │платежей по статьям расхода│

│Ввожу следующие поля: │ │за период. В качестве│

│СЧЕТ ПО ДЕБЕТУ, СЧЕТ ПО│ │параметра отчета я должен│

│КРЕДИТУ, СУММУ,│ │определять интервал дат.│

│НАЗНАЧЕНИЕ... │ │Отчет должен иметь следующую│

│ │ │форму: │

│ │ │ │

│Пометка: надо вводить│ │┌────┬─────┬────┬─────┬─────┐│

│еще и статьи расхода....│ ││ │ │ │ │ ││

│ │ │├────┼─────┼────┼─────┼─────┤│

│ │ ││ │ │ │ │ ││

│ │ │├────┼─────┼────┼─────┼─────┤│

│ │ ││ │ │ │ │ ││

│ │ │└────┴─────┴────┴─────┴─────┘│

└────────────────────────┘ └─────────────────────────────┘

Данный прием моделирования позволяет максимально использовать имеющийся человеческий капитал, поскольку каждый участник строит свой бизнес-процесс самостоятельно, а общий контроль осуществляет руководитель и представители других подразделений.

Описанные приемы помогут группе более точно понять и написать техническое и бизнес-задание проекта. В бизнес-задании описываются основные функциональные требования, техническое - отражает более детальную информацию, особенности, включая параметры и подходы к реализации. Иногда они подготавливаются разными людьми, но гораздо чаще представляют единый документ, который готовится одним человеком - аналитиком. Далее мы не будем делать различий между этими документами и понятиями.

Следует помнить, что, если точного задания не получится, придется давать системе, реализующей проект, дополнительную гибкость. Но реализация универсальной, гибкой бизнес-функции требует в несколько раз больше ресурсов на разработку и сопровождение, чем статичное решение.

Кроме того, рекомендуется вести разработку двух заданий, которые условно можно назвать: "Программа-минимум" и "Программа-максимум". В первом варианте нужно описать минимальные изменения в организации по сравнению с текущим положением дел, достаточные для реализации основной цели. Второй документ должен составляться с учетом всех пожеланий и перспектив. Как правило, в конце проекта будет реализован некоторый промежуточный вариант. Имея установленный проект бюджета, группа сначала реализует только самые необходимые требования (на это бюджета, как правило, хватает), а потом либо будет дополнять данное решение новыми возможностями, либо аргументирует прекращение работ и возьмет на себя ответственность за это.

В любом случае при постановке задачи, как и везде, вредны крайности. Многие проекты были загублены чересчур грамотными аналитиками, которые месяцами составляли задания, исчисляемые сотнями страниц. Потом сами же с трудом могли понять, что они имели в виду, настолько запутана и сложна была задача или ее описание. Поверхностность также вредна. Исходя из практического опыта, можно сказать, что ориентирами "золотой середины" могут являться параметры объема работ по подготовке технического задания, представленные в табл. 15 .

Таблица 15

Ресурсы и объем работ по подготовке технического задания

┌────────────┬────────────────────┬───────────────────┬─────────────────┐

│Размер банка│ Количество │Примерное время для│ Примерный │

│ │ выделенных для │завершения этапа с │ суммарный объем │

│ │ постановки задачи │учетом согласований│ задания в │

│ │ аналитиков │ │ страницах, с │

│ │ │ │ учетом │

│ │ │ │ комментариев │

├────────────┼────────────────────┼───────────────────┼─────────────────┤

│Небольшой │ 2-3 │ 1-2 месяца │ 100-150 │

│Средний │ 4-5 │ 3 месяца │ 200-300 │

│Крупный │ 6-8 │ 4-5 месяцев │ 350-500 │

└────────────┴────────────────────┴───────────────────┴─────────────────┘

Взаимодействие с руководством

Вне зависимости от модели организации работы на проекте и степени вовлеченности внешних консультантов в проект с самого начала необходимо организовать регулярное и эффективное взаимодействие проекта с высшим руководством организации. Это позволит облегчить принятие требуемых решений, будет способствовать повышению статуса проекта, явится источником дополнительной мотивации и повышения ответственности участников проекта. Реализация такого взаимодействия обычно происходит в следующих формах.

Проектный комитет - орган управления проекта, который должен состоять из представителей высшего менеджмента организации, бизнес-менеджмента и менеджера проекта. Он должен периодически собираться для принятия и утверждения самых важных решений по ходу проекта. Периодичность зависит от фазы проекта, но в целом это не должно происходить реже, чем раз в месяц. Менеджер проекта докладывает комитету об основных результатах работы, текущем состоянии проекта, основных проблемах, принятых решениях, ситуациях, требующих решения комитета и выходящих за компетенцию менеджера. В процессе заседания комитета ведется протокол, который затем предоставляется всем участникам и заинтересованным лицам и является официальным документом для банка, проекта и подрядчиков.

Спонсорство - важный элемент проекта. Для проекта должен быть назначен спонсор (куратор), лицо из высшего руководства, один из членов проектного комитета, обычно близкий бизнес-подразделениям, который будет более активно взаимодействовать с менеджером проекта для помощи и консультирования. Он должен быть представителем руководства, уполномоченным принимать любые решения, который будет больше всех других высших менеджеров организации в курсе хода проекта и его проблем. Обычно это человек, который выступал инициатором проекта среди руководства или поддерживал его с самого начала.

Периодическая отчетность. Руководитель проекта должен готовить для информирования всех заинтересованных сторон о ходе работ специальные отчетные формы. Периодичность их зависит также от состояния проекта, но в общем должна быть чаще, чем заседания проектного комитета. Может быть рекомендована следующая схема. Если проект испытывает сложности, имеет место срыв сроков, недостаток бюджета и т.п., то отчетность должна предоставляться еженедельно. Если проблемы у проекта есть, но не очень значительные, отчетность составляется раз в две недели. И если у проекта нет каких-либо проблем, способных повлиять на срок, бюджет, то раз в месяц. В отчетах должен быть в удобной форме отражен текущий статус проекта, этап и его фаза, основные ближайшие контрольные точки, выполненный по сравнению с предыдущим отчетом объем работ, достижения проекта за период, основные риски, проблемы, действия по их минимизации и решения, открытые вопросы, прогноз по выполнению сроков и бюджета.

Разработка решений

Задачей разработки программного обеспечения является построение систем, отвечающих требованиям бизнеса и обеспечивающих максимум преимуществ от их использования. В то же время эти системы должны создаваться с учетом их дальнейшего сопровождения, требований к производительности и качеству. Организация, осознавая всю важность использования информационных технологий, ставит перед собой цель создать базу для разработки и внедрения программного обеспечения, отвечающего вышеуказанным задачам.

Данная глава описывает основные требования к разработке программного обеспечения как собственными разработчиками, так и с использованием сторонних организаций. Кроме того, в ней определены обязательные этапы при создании и внедрении программных продуктов, требования к документированию каждой стадии и контролю качества продукта. Тестирование и внедрение, являясь составными частями разработки, будут рассмотрены в специально выделенных для этого главах. В настоящей главе мы не будем делать различий между разработкой программного обеспечения, его модификацией, доработкой и настройкой. Мы будем считать, что все перечисленные подходы входят в понятие разработки, являясь методами ее технического осуществления.

Итак, каковы основные участники процесса разработки?

Заказчик - подразделение организации, у которого возникла необходимость в разработке нового или изменении существующего программного обеспечения. Также в качестве заказчика может выступать организация в целом.

Разработчик - проектная команда, сформированная на основе службы ИТ или сторонней организации, непосредственно работающая над разработкой, изменением и внедрением программного обеспечения.

Контролеры - сотрудники организации (кроме непосредственно разработчиков), осуществляющие наблюдение за созданием продукта. Контролерами могут выступать начальники подразделений или назначаемые ими сотрудники подразделения. Если заказчиком является организация, то контролеры назначаются руководством. Для больших проектов, важных для бизнеса, возможно привлечение в качестве контролеров сторонних консультантов.

Аналитики - специалисты в области банковских технологий, участвующие в постановке задачи и консультировании всех сторон в ходе проекта.

Документирование

Одним из первых важнейших требований является документирование всех этапов процесса разработки программного обеспечения, начиная с постановки первоначальных требований и заканчивая вводом в эксплуатацию и дальнейшим сопровождением. Документы, возникающие в процессе разработки, такие, как спецификации, планы разработки, руководство пользователя, являются неотъемлемой частью программного продукта. Заказчик вместе с программным продуктом должен по возможности получать всю документацию, связанную с разработкой продукта. Документирование процесса разработки ведется с целью облегчения процесса сопровождения, доработки и контроля качества продукта. В случае смены разработчика проектная документация должна обеспечить дальнейшую эффективную работу с программным продуктом.

Качество документации должно отвечать следующим критериям:

* правильность:

- соответствие (трассируемость) требований и спецификаций соответствующей системе, и наоборот;

- последовательность в описании требований, спецификаций и функций;

* полнота:

- использование версий и дат документов для контроля изменений, доступность всех версий документов (в том числе рабочих);

- функциональность системы должна быть максимально полно описана в системных требованиях;

- документация должна предоставлять информацию для всех категорий пользователей, операторов системы и разработчиков;

* удобство и простота использования:

- использование оглавлений, алфавитных указателей, глоссариев и кросс-ссылок;

- логическая последовательность и непротиворечивость в использовании терминологии;

- уместный внешний вид документации (шрифты, формат).

В то же время необходимо, как уже отмечалось, избегать излишней бюрократизации, другими словами - в зависимости от цели проекта набор, состав и объем документов должен меняться.

Исходные коды

Применительно к исходным кодам программ, которые по сути являются документацией к системе, также должны во многом выполняться вышеуказанные требования. Исходные коды разработанных для банка систем (как силами собственных программистов, так и сторонними организациями) должны по возможности предоставляться вместе с системой и документацией к ней. Это условие необходимо включать в договора на разработку программного обеспечения и в служебные инструкции разработчиков. Исходные коды должны содержать комментарии в количестве, необходимом для понимания структуры исходного кода и функциональности каждого модуля, подпрограммы или класса. Код программы должен писаться с учетом дальнейшего сопровождения и возможного расширения функциональности системы.

Программный код должен быть отформатирован в едином стиле. В общем случае утвержденные и используемыми всеми разработчиками стандарты кодирования содержат следующие составляющие:

* принципы форматирования программного кода, включая использование структурированного расположения текста и отступов между строками кода для удобства считывания. Комментарии в коде должны давать краткое описание функциональности программ, модулей, классов, методов класса и т.п., а также описывать формат и назначение входных и выходных данных;

* соглашения о стиле программирования должны, в частности, описывать стандарты именования переменных, констант, классов и т.д. Должен применяться общий подход к использованию внутренних переменных, констант и структур данных (таких, как массивы). Все это поможет созданию предсказуемого и легко читаемого кода, с которым было бы несложно работать как на этапе разработки, так и в ходе модификации и дальнейшего сопровождения; приемы написания эффективного кода. Эти правила могут быть связаны с использованием эффективных структур данных и алгоритмов, созданием максимально производительных запросов к базам данных и т.п.

Ответственность заказчика

Представители заказчика обязаны принимать участие и контролировать процесс разработки на всех этапах. Должны быть назначены представители заказчика (подразделения организации или выделенные эксперты), отвечающие за разработку, - контролеры. Это могут быть сотрудники банка, знающие в деталях бизнес-процессы, для поддержки которых создается система, сотрудники службы информационных технологий или сторонние консультанты. Для максимальной отдачи от внедрения разрабатываемых систем крайне необходимо тесное взаимодействие с разработчиками.

Ответственность за разработку систем помимо назначенных сотрудников или консультантов несут соответствующие руководители подразделений или организации в целом.

Оценка эффективности разработки

Масштаб и степень следования стандартам разработки программного обеспечения могут зависеть от размера и характера проекта, а также от того, какие инструменты разработки используются. Для небольших, некритичных для бизнеса приложений необходимость строгого следования стандартам может быть не так важна. Однако для больших и чувствительных с точки зрения бизнеса проектов, где велика стоимость разработки и появляются большие риски, необходимы максимальный контроль за процессом разработки и следование стандартам программирования.

В любом случае затраты и усилия, потраченные на разработку, должны соответствовать уровню решаемых с помощью системы проблем. Стоимость проекта должна оцениваться с точки зрения его важности и выгоды от использования разработанной системы.

Целью разработки новых систем и модификации существующих является повышение эффективности бизнес-процессов, поэтому помимо разработки программного обеспечения необходимо параллельно рассмотреть другие варианты мер, влияющих на эффективность организации (дополнительное обучение сотрудников, реорганизация подразделений, незначительное изменение или всеобъемлющий реинжиниринг бизнес-процессов с привлечением сторонних консультантов и т.п.). Эта проблема очень важна, и поэтому она будет детально рассмотрена в рамках главы "Управление изменениями".

Стадии разработки

Процесс разработки программного обеспечения должен содержать этапы инициации (организации) проекта, оценки проекта, анализа и проектирования, конструирования и внедрения системы.

Этап инициации проекта, с точки зрения разработчика, должен включать подготовку заказчиком требований к новой системе, описание ее функций и структуры, оправдание ее с точки зрения бизнеса и получение одобрения со стороны руководства для того, чтобы приступить к следующим этапам разработки. Если заказчиком выступает подразделение организации, необходимо одобрение руководителя подразделения, если заказчик - организация в целом, то руководителей организации.

Первоначальные требования к системе направляются, как правило, в ИТ-подразделение, которое оценивает факторы, критичные для успеха проекта и его качества. Необходимо выяснить, насколько проект согласуется с общей стратегией банка в области развития бизнеса и использования информационных технологий, приблизительно оценить общие затраты на проект, а также каким образом и кем должен осуществляться контроль над проектом.

Оценка проекта и его согласование были рассмотрены выше, поэтому мы здесь лишь упомянем о них.

В направлении дальнейшей детализации необходимо выбрать несколько вариантов реализации программного обеспечения и точно оценить стоимость каждого варианта, трудности, связанные с его осуществлением, время на осуществление, программные средства и инструменты, необходимые для проекта, исполнителей проекта, а также преимущества каждого варианта. Кроме того, требуется описать недостатки существующей системы и как они будут устранены при внедрении нового программного обеспечения. В итоговую оценку необходимо включить меры по изменению бизнес-процессов и структуры организации, которые сопровождают внедрение системы. Детальную оценку проекта осуществляет ИТ (проектная команда), заказчик выбирает окончательный вариант решения. Итоговый документ должен быть подписан заказчиком и проектным руководством, руководителем ИТ.

Этап анализа и прогнозирования включает в себя разработку проектной документации, в деталях описывающей работу будущей системы, ее структуру, технические и программные средства, необходимые для ее функционирования. Этот этап важен для облегчения дальнейшей работы над системой.

Итогом данного этапа должны явиться одна или несколько спецификаций системы, которые готовятся разработчиком при поддержке заказчика. Мы уже отмечали, что для наших целей не будем различать различные типы спецификаций. Отметим лишь, что вне зависимости от их названия они должны содержать:

* описание бизнеса (бизнес-процессы и функции, которые будут автоматизированы):

- детальное описание существующих бизнес-процессов и каким образом они будут затронуты при внедрении системы;

- детальное описание новых бизнес-процессов, которые будут созданы или получены при изменении существующих;

- описание мер контроля, которые будут внедрены в новой системе;

описание программно-аппаратного обеспечения, необходимого для функционирования системы:

- операционная система(ы), которая будет использоваться;

- сетевая среда, оборудование и протоколы;

- средства разработки новой системы;

- средства защиты информации;

- как новые платформы будут включены в существующую информационную инфраструктуру;

* спецификация функциональности системы:

- общее описание функциональности системы как в повествовательной форме, так и в виде диаграмм;

- разбиение системы на модули;

- соответствие модулей бизнес-требованиям к системе. Должно быть описано, каким требованиям отвечает каждый модуль. Все бизнес-требования должны покрываться модулями системы;

- модель данных, используемая в системе (диаграмма "сущность- связь" или аналогичные). Функциональность, вынесенная в серверную часть системы;

- описание того, каким образом будут реализованы требования к информационной безопасности, производительности и надежности системы;

- детальное описание интерфейсов с другими системами;

- список разрабатываемых программ (включая вспомогательные) и параметры для их запуска;

- список ошибок и предупреждений, генерируемых системой;

- спецификация должна быть четко структурированной и содержать оглавление, алфавитные указатели, глоссарий и список используемых терминов.

Все спецификационные документы подписывает разработчик и предоставляет для ознакомления заказчику.

Написание подробных спецификаций (постановку задачи) можно заменить использованием методики создания прототипов. При этом прогрессивном методе используется итерационный подход. Описание будущей системы производится через согласование интерфейсов пользователя с системой. С будущими пользователями системы обсуждаются и утверждаются экранные формы, соответствующие различным функциям системы. Вместе с внешним видом этих форм описываются соответствующие им входные и выходные данные. Другими словами, время на подготовку документов практически не тратится, пользователь рассказывает, что ему нужно, разработчик создает модель и презентует ее пользователю, который высказывает свои замечания и т.д., пока решение (или по крайней мере его внешний вид) не согласовывается. Выгодой этого подхода являются меньшие сроки разработки системы, следовательно, меньшие затраты на разработку.

Решение об использовании методики создания прототипов принимается до начала этапа анализа и проектирования, на этапе выбора варианта реализации системы. При принятии решения должны быть оценены следующие риски:

* рамки проекта могут быть значительно расширены без формального одобрения, так как пользователи системы могут добавлять "полезные" с их точки зрения функции;

* прототипы описывают только интерфейсы пользователей, и такие вопросы, как информационная безопасность, могут быть упущены на этапе проектирования;

* не для всех компонент системы можно создать прототипы;

* использование прототипов не так детально описывает разрабатываемую систему, как написание спецификаций. Следствием могут явиться трудности с поддержкой и сопровождением в долгосрочной перспективе, а также недостаточный уровень тестирования каждого модуля.

На этапе конструирования формально описанные требования к системе, созданные на стадии анализа и проектирования, преобразуются в рабочую систему. Разработка включает в себя создание структуры программы, кодирование, создание структуры базы данных и тестирование на уровне модулей системы, системы в целом и интерфейсов с внешними приложениями.

Система должна согласовываться с формальными требованиями к ней. В случае внесения существенных изменений в систему, не описанных в проектной документации, эти изменения должны быть согласованы с заказчиком и внесены в спецификации.

Программное обеспечение разрабатывается с использованием структурного подхода, при этом должны соблюдаться ранее установленные стандарты кодирования. Исходные коды содержат комментарии в количестве, необходимом для понимания структуры исходного кода и ее функциональности. Следует максимально снизить риски, возникающие при смене разработчиков.

Программный код должен быть составлен на основе уже упоминавшихся стандартов. Разработчик при этом использует систему контроля версий исходных кодов. При внесении изменений в исходный код описывается, какие изменения и с какой целью вносились.

Разрабатываемое программное обеспечение тщательно тестируется (методика тестирования будет рассмотрена подробно в следующей главе). Должен быть разработан план тестирования, который включает этапы тестирования модулей системы, системы в целом, интерфейсов с внешними программами, интерфейсов пользователя, тестирование систем безопасности и надежности системы. Согласно этому плану необходимо разработать набор тестов, которые помимо покрытия функциональных требований к системе (тестирования по методу "черного ящика") покрывали бы внутреннюю структуру исходного кода (покрытие условных переходов, метод "белого ящика").

Тестовая среда, база данных и исполняемые модули должны быть отделены от рабочей системы. Разработчики не должны иметь доступ к рабочей системе после ее внедрения и запуска.

Результаты тестирования должны быть зафиксированы, в случае обнаружения ошибок они исправляются разработчиком, и это должно быть отображено в отчете по тестированию. Результаты тестирования - найденные ошибки и как они были исправлены - должны быть подписаны разработчиком и предоставлены заказчику.

На этапе конструирования разработчик разрабатывает документацию для пользователей и администраторов системы в электронном и бумажном виде. Документация должна иметь надлежащую структуру, содержание, формат и внешний вид.

Должны быть разработаны программы учебных курсов и соответствующие учебные материалы, которые учитывают специфику всех категорий пользователей и администраторов системы.

В случае необходимости могут быть описаны дополнительные меры, необходимые для внедрения системы. Например, установка нового оборудования, перепланировка используемых помещений, изменения в структуре организации и обязанностях сотрудников, описание необходимых административных процедур и т.д.

На этапе внедрения, особенности которого также будут рассмотрены в отдельной главе, разработанная система должна быть установлена на серверы и рабочие станции, подготовлена и передана заказчику документация, проведено обучение пользователей и администраторов системы. На этой стадии система окончательно принимается заказчиком.

Заказчик должен убедиться, что документация является полной, подготовлена согласно принятым стандартам и покрывает требования к системе. Учебные курсы должны полностью покрывать функциональные возможности системы и отвечать запросам различных групп пользователей и администраторов. Все пользователи и администраторы, перед тем как начать работу с системой, проходят соответствующие курсы.

Заказчику необходимо убедиться, что установка нового программного обеспечения не повлияет на данные уже работающих систем. При переносе данных из старой системы необходимо протестировать, что данные перенесены правильно и полно. Результаты переноса утверждаются заказчиком.

Заказчик составляет план приемки программного обеспечения, разрабатывает набор тестов для проверки функциональности системы и проводит тестирование в соответствии с планом. Кроме того, ему необходимо убедиться в том, что система установлена правильно и предусмотрены все необходимые меры, связанные с защитой информации и надежной работой системы.

Служба поддержки пользователей организуется силами разработчика или на базе сотрудников заказчика. В отношениях между заказчиком и разработчиком должны быть предусмотрены соглашения об уровне обслуживания, на каких условиях будет производиться сопровождение системы, каким образом будут исправляться ошибки, обнаруженные во время эксплуатации системы, а также гарантийные условия.

Документ о завершении внедрения системы подписывают заказчик и разработчик.

Качество и эффективность внедрения напрямую зависят от интенсивности контроля со стороны заказчика. Однако любую внедренную систему можно улучшить с точки зрения эффективности ее функционирования, удобства работы, производительности и надежности. С этой целью по окончании приемки системы можно провести обзор качества разработки и внедрения, в ходе которого выясняются недостатки и упущения в разработанной системе. Этот обзор проводится с помощью сотрудников банка, компании-разработчика или сторонних консультантов. Результатом обзора может явиться отчет о найденных недостатках, содержащий рекомендации по их устранению.

Тестирование систем

Тестирование представляет собой процесс оценки системы (или компонента системы) ручным или автоматическим способом с целью проверки соответствия указанным требованиям или выявления различий между ожидаемыми и фактическими результатами. Тестирование также подразумевает использование разработанной программы для обнаружения ошибок. Прохождение тестирования не означает, что система больше не содержит дефектов. Тестирование может выявить наличие проблем, а не доказать их отсутствие.

Тестирующий сотрудник не только пытается обнаружить недостатки, но и проверяет программу в работе, оценивает ее надежность, безопасность и безотказность в эксплуатации. Присутствует также экономический аспект. Для более крупных проектов больший объем тестирования обычно выявляет большее количество ошибок. Когда следует прекратить тестирование и какую степень наличия ошибок следует считать приемлемой? Если количество ошибок не превышает определенной допустимой величины, то программное обеспечение может быть квалифицировано как удовлетворяющее требования пользователей и допущено для эксплуатации. Необходимо помнить, что тестирование предполагает, что требования к системе уже сформулированы и не модифицируются.

"Рис. 22. Разработка программного обеспечения"

Методы и подходы тестирования

Стратегия успешного тестирования начинается с процесса его обсуждения на стадии составления спецификаций требований. Тестирование деталей следует проводить на высоком и низком уровне, причем тестирование должно проводиться сначала разработчиками, а затем конечными пользователями. По мере повышения сложности программного обеспечения увеличивается значение эффективного, хорошо спланированного тестирования.

В зависимости от характера и сложности информационного решения банк будет выбирать объем необходимых процедур тестирования. Процесс тестирования может включать все описанные ниже этапы в случае собственного программного обеспечения и некоторые из этих этапов - в случае покупки готового программного обеспечения.

Тестирование "белый ящик" выполняется с целью обнаружения проблем во внутренней структуре программы. Это требует от проверяющего глубокого знания внутренней структуры и, следовательно, не может быть выполнено обычным пользователем. Общая задача такого тестирования - обеспечить проверку каждого шага по алгоритму программы. Основное преимущество всех типов стратегий тестирования "белый ящик": при тестировании принимается во внимание структура всей программы, что облегчает обнаружение ошибок даже в том случае, когда спецификации программного обеспечения недостаточно определенные или неполные.

Тестирование по блокам заключается в проверке блока отдельно от остальной системы. Обычно блок представляет собой функцию или небольшой набор функций (библиотеки, классы), которые выполняются одним программистом. Основная отличительная характеристика блока состоит в том, что он достаточно небольшой по объему для проведения тщательной проверки, которую можно назвать исчерпывающей. Обычно тестирование "белый ящик" проводится разработчиками. Небольшой размер блоков позволяет обеспечить высокий уровень проверки кодов. Таким образом легче обнаружить и устранить ошибки на данном уровне тестирования.

Одним из наиболее сложных аспектов разработки программного обеспечения являются интеграция и тестирование больших подсистем. Интегрированная система часто дает существенные и необъяснимые сбои, которые трудно устранить. Тестирование в таком случае состоит в проверке нескольких блоков, которые образуют модуль или подсистему. Тестирование интегрированной системы в основном направлено на интерфейс между блоками, что должно гарантировать совместимость блоков и их корректную совместную работу.

Тестирование "черный ящик" состоит в поиске отсутствующих или неправильно выполняемых функций с целью оценки, насколько хорошо программа отвечает требованиям. Функциональные тесты обычно подтверждают правильность данных на вводе и выходе. В этом случае пользователь - идеальный проверяющий. Иногда такое тестирование называют пользовательским. Тест функциональности состоит в том, чтобы проверить правильное выполнение отдельных функций системой. Проверяющие проводят тесты, которые, по их мнению, отражают использование системы в будущем, ее функциональных возможностей.

Системный тест представляет собой более полную версию теста на проверку внешней функции, но в максимально приближенных к "боевым" условиям и среде. При системном тестировании техническая платформа должна быть как можно ближе к фактическим условиям эксплуатации, включая такие факторы, как комплектация оборудования, а также объем и сложность базы данных. В ходе воспроизведения будущих условий эксплуатации системы можно точнее протестировать более сложные черты системы (характеристики, безопасность и безотказность). Однако воспроизводить среду пользователя для системного теста слишком дорого, к тому же может не хватить времени на проведение испытания.

Системное тестирование обычно включает в себя тестирование характеристик, которое выявляет время ответа на запрос, использование памяти, оборудования и время выполнения операции. Тестирование в стрессовой ситуации подводит систему к некоторым пределам для оценки ее возможностей и способности справляться с ошибками. Тесты надежности оценивают реакцию системы на ввод данных, проводят подсчет отказов за определенный период времени с целью оценки или подтверждения степени надежности.

Ретроспективное тестирование представляет собой обязательную проверку, выполняемую на модифицированном программном обеспечении, с целью достижения уверенности в том, что изменения в программу внесены правильно и не оказали отрицательного воздействия на другие компоненты системы.

"Приемо-сдаточное испытание" - это проверка готовой системы группой конечных пользователей с целью окончательного подтверждения готовности системы к работе. В этом случае программа пройдет более реальную проверку, чем на этапе системного тестирования, поскольку пользователи имеют лучшее представление о том, как система будет использоваться.

Проблемы тестирования

Рассмотрим некоторые типичные ошибки, совершаемые организациями в результате попыток провести эффективное тестирование программного обеспечения. Эти ошибки можно разбить на 4 категории.

1. Неправильное понимание роли тестирования. Назначение тестирования заключается в обнаружении дефектов продукта. В связи с этим важно хорошо понимать критичность тех или иных дефектов при планировании тестирования, при описании дефектов и подготовке рекомендаций.

2. Недостатки в планировании процесса тестирования. Во многих случаях при планировании тестирования чрезмерное внимание уделяется тестированию функциональности в ущерб тестированию потенциального взаимодействия и системных характеристик. Недостаточное внимание к документации по тестированию и к документации по инсталляции также довольно рискованно.

3. Неправильный подбор персонала для тестирования. Функцию тестирования нельзя поручать младшему персоналу. Группа тестирования должна включать специалистов ИТ по системе и конечных пользователей. Группа тестирования не может действовать эффективно, если ее состав не диверсифицирован.

4. Слабая методика тестирования. Точно так же, как программисты часто предпочитают кодирование написанию алгоритмов, тестирующий персонал часто уделяет чрезмерное внимание самим тестам в ущерб времени, отведенному на составление планов тестирования. Тесты должны дать подтверждение, что программный продукт способен адекватно выполнять свои функции.

Внедрение систем

Внедрение систем - это комплекс специфицеских задач, выполнение которых позволяет добиться реальной эксплуатации решения в организации. Другими словами, это внедрение изменений, которое мы уже разбирали выше.

В общем случае процесс внедрения состоит из ряда организационных действий, подготовительных работ технического и административного плана, тестовой (опытной) и промышленной эксплуатации. Далее мы рассмотрим эти составляющие.

Особенности внедрения

Внедрение, пожалуй, - самый ответственный момент проекта замены информационной системы. Это связано с рядом причин.

Во-первых, как мы уже отмечали при рассмотрении управления изменениями, это всегда наиболее сложная составляющая работы.

Во-вторых, даже если на предыдущих стадиях была создана очень хорошая информационная система, до тех пор, пока она не внедрена, ее ценность равна нулю. Часто менеджеры стараются до бесконечности совершенствовать продукт, наслаждаясь им в узком кругу программистов и ИТ-экспертов, не понимая, почему ни у кого больше их многолетние изыскания не вызывают оптимизма.

В-третьих, внедрение - это не экзамен, а нечто большее, и поэтому даже блестяще оттестированные и подготовленные системы, сдавшие все "экзамены", могут не подойти по тем или иным причинам. Думать, что заранее можно предвидеть все проблемы, недальновидно. Во время внедрения все проблемы, конфликты, которые не были решены ранее, были забыты или решены неправильно, отложены, недодуманы, скрыты, всплывают практически в один момент, требуя непомерных профессиональных знаний и личных усилий всех участников проекта.

Организационные действия

На практике часто бывает так. Внедрение хорошо подготовлено: проведены многочисленные выверки данных, тестирование и многие другие, важные для внедрения, работы (о чем мы еще будем говорить далее). Но почему-то внедрение срывается, ком проблем растет с такой скоростью, что в один прекрасный момент большинству становиться ясно, что система не может быть внедрена. Проектная команда, менеджмент теряют веру, количество проблем от этого возрастает еще больше, и в конечном счете проект останавливается или приостанавливается высшим руководством.

Можно ли избежать этого? Ответ практикующих менеджеров проектов в 99,9% случаев - "да". Набор инструментов для достижения такого результата достаточно уникален и индивидуален и является во многом профессиональным ноу-хау (Know-How) руководителя проекта. Мы же рассмотрим некоторые основные составляющие таких организационных действий, которые позволяют сделать даже проблемное внедрение успешным.

Снятие противоречий и конфликтов. Первый вопрос, который необходимо прояснить, - всем ли нужно внедрение как в самой организации, так и среди подрядчиков? Кому оно невыгодно по тем или иным причинам? Кто против в настоящее время или был против на ранних стадиях проекта? Кто не принимал участия? Даже это может быть важно, потому что успех одного руководителя может автоматически снижать авторитет тех, кто не верил в исход проекта или был против него. Не стоит искать конфликты только среди руководства, они могут быть и на более низком уровне и при этом иметь очень большое значение. Задача руководителя проекта состоит в том, чтобы не только найти все эти центры противоречий и конфликтов, но и свести их на нет или по крайней мере добиться, чтобы их влияние на проект было минимальным.

Прояснение недопониманий и выработка согласованных подходов. Даже там, где нет предпосылок для конфликта, он может возникнуть по причине недопонимания. Внедрение является сложной задачей, и поэтому неминуемо в процессе работ, а особенно на их завершающей стадии, возникают такие ситуации, когда, не решаясь задать лишний вопрос, те или иные участники процесса просто не понимают смысл определенных действий или понимают его неправильно. Задача руководителя проекта - не только добиться того, чтобы количество таких недопониманий было минимальным, его задача также состоит в том, чтобы инициировать процедуры согласования позиций, их обсуждения и понятного и доступного формального закрепления в бумажной форме. Он должен как можно больше задавать вопросов всем участникам, чтобы добиться в конце концов одинаковых и согласованных позиций и полного понимания участниками и заинтересованными сторонами того, что происходит.

Прояснение формальной (юридической) позиции - тоже важная составляющая организационных действий. Выполненная до начала внедрения, посредством дополнительного анализа существующих формальных или договорных отношений между сторонами, она способна оказать реальную помощь в реализации двух предыдущих пунктов. Инициатором этой работы должен выступать руководитель проекта. При выявлении неясностей в формальных отношениях сторон их проясняют обязательно до начала внедрения, чтобы не приостанавливать его или не служить еще одним дополнительным риском.

Онлайн-менеджмент и контроль. Во время внедрения осуществляются постоянный надзор и контроль со стороны высшего менеджмента за происходящим. Он должен быть организован в онлайн-режиме, то есть участники проекта, его руководство имеют приоритетное право на взаимодействие с высшим менеджментом организации. Контроль должен осуществляться на оперативной и регулярной основе. Заседания управляющего комитета должны проводиться чаще, чем при обычной работе, и не реже одного раза в неделю. Не исключен и ежедневный вариант. Формальная отчетность и информация по ходу проекта должна быть доступна всем заинтересованным сторонам также на оперативной основе.

Оперативный анализ рисков. Отдельно руководителем проекта с помощью ведущих экспертов по основным областям ведется анализ рисков внедрения. Его форма должна быть простой и понятной. Это может быть просто текстовый список проблем, где указывается следующая информация: кто инициировал занесение проблемы в список, ее номер (если есть), суть проблемы, ответственный за решение, дата регистрации проблемы, дата решения, кратко основные действия по решению, приоритет и текущий статус (решена или нет). Такой список очень помогает руководителю проекта не забывать обо всех возникающих проблемах и в тоже время является инструментом контроля и давления на исполнителей, ответственных за решение.

Мотивация персонала на достижение результата. Возможно, самый главный пункт - это мотивация всех участников проекта и прежде всего его непосредственных работников на достижение результата. Мы уже останавливались на основных подходах по мотивации, когда рассматривали управление ИТ-персоналом, поэтому не будем здесь повторяться.

Широкое информирование заинтересованных сторон. Отдельная задача в ходе внедрения - информирование всех заинтересованных сторон, включая обычных сотрудников организации, о ходе и статусе работ. При недостатке информирования проект обрастает слухами, которые будут очень мешать в работе. С другой стороны, поддержка со стороны всей организации очень полезна для работы, является дополнительным источником мотивации. Но это возможно только при наличии информации и понимания, в противном случае отношение будет очень негативным.

Качественное и детальное планирование и обеспечение ресурсами. Планирование важно всегда, но на этапе внедрения оно имеет повышенное значение. Помимо этого целесообразно иметь небольшой резерв ресурсов, которые могут быть временно сняты с других работ или привлечены на отдельные участки со стороны. Все стандартные методики управления ресурсами, такие, как сетевое планирование, использование методики критического пути, должны использоваться руководителем проекта для получения информации и оперативного принятия решений по переброске ресурсов или их увеличению.

Подготовка к внедрению

Существенная часть временных затрат при внедрении систем должна быть потрачена на подготовительные работы технического и административного характера. Данные работы включают:

* доработку программного обеспечения и его тестирование;

* подготовку компьютерной техники, приведение ее к необходимым техническим требованиям разработчика;

* обучение пользователей и администраторов системы;

* разработку конверторов данных из существующей системы в новую, разработку и тестирование методик контроля правильности переноса данных;

* разработку руководств пользователей и администраторов системы;

* разработку инструкций на случай технологических сбоев в системе.

Окончанием подготовительного периода должна стать тестовая эксплуатация системы с участием конечных пользователей. В случае небольших организаций и незначительного документооборота возможна параллельная работа обоих систем. Однако в крупных организациях параллельное ведение - весьма затратное и беспокойное мероприятие. В этом случае лучше применить поэтапное тестирование различных составляющих с участием сотрудников соответствующих подразделений.

По результатам опытной эксплуатации рекомендуется составить акт, в котором регистрируются все недоработки системы, а также сроки их устранения. При этом в случае наличия критичных недостатков, способных привести к технологическому сбою в работе организации, после их устранения необходимо провести повторное тестирование всех составляющих системы. Таким образом, после полнофункционального тестирования до начала рабочей эксплуатации системы вводится мораторий на внесение изменений в систему. Это делается для того, чтобы в результате внесения исправлений не были порождены новые ошибки.

Начало рабочей эксплуатации

Начало рабочей эксплуатации является самым критическим моментом в проекте. Фактически успешный старт и работа в системе хотя бы в течение нескольких дней означают успех проекта. Конечно, наличие большого количества недоработок, кажущиеся неудобства в работе, периодические сбои не позволяют сказать об этом сразу, но все эти проблемы намного более просты в решении, чем поддержание двух информационных систем и постоянная синхронизация данных в них.

Но начало рабочей эксплуатации и, как следствие, отказ от поддержки старой системы не могут основываться только на желании это сделать. Малейший сбой приводит к откату к предыдущему состоянию, к возврату эксплуатации старой системы, поскольку ни один руководитель не возьмет на себя ответственность продолжать эксперимент, когда, например, у него не проходят обработку клиентские платежи или неправильно рассчитываются процентные ставки по депозитам более чем в течение 10 минут.

В зависимости от размера организации возможны два варианта перехода на рабочую эксплуатацию. Для организации с количеством сотрудников до 100 человек, как правило, применяется тотальный переход. Все пользователи в определенный день (обычно пятницу, чтобы было время для устранения ошибок) начинают работу в новой системе. Основными показателями успешного перехода на новую систему являются отсутствие задержек приема документов у клиента, своевременная отправка платежей, получение правильного баланса.

В случае, если внедряемая система решает большой спектр задач, количество пользователей более 100, необходим поэтапный переход. Он может осуществляться в следующей последовательности:

- запуск интерфейса взаимодействия с внешними платежными системами, маршрутизация платежей филиалов;

- формирование баланса и прочей ежедневной и оперативной отчетности;

- ввод простейших платежных документов в систему пользователями, ведение расчетно-кассового обслуживания;

- учет сложных операций (покупка-продажа валют);

- автоматическое начисление процентов и платы за обслуживание;

- формирование документопотока в соответствии с перспективной моделью организации, изменение обязанностей сотрудников, участвующих в расчетно-кассовом обслуживании клиентов и собственных платежей банка;

- учет операций физических лиц;

- учет внутренних операций банка: расчет зарплат, ведение хозяйственных договоров, учет основных средств;

- учет и ведение кредитов банка;

- учет прочих операций банка, включая торговые операции на бирже. Такая последовательность позволяет минимизировать последствия озможных сбоев и дает время команде внедрения сосредоточиться на одной задаче, а не распылять свои силы на решение всех проблем.

Завершение проектов

Переход на рабочую эксплуатацию системы обычно заканчивается подписанием акта о проделанной работе. Однако большое количество недоработок и недовольство пользователей нельзя назвать успешным завершением. Таким образом, взаимодействие с разработчиками не заканчивается рабочей эксплуатацией, а переходит в новую стадию - сопровождение. Не стоит требовать от разработчиков немедленного устранения всех недочетов. Лучше в течение некоторого времени дать пользователям поработать с новой системой, почувствовать ее возможности и преимущества перед старой. И только после того, как отрицательные эмоции улягутся и пользователи смогут более квалифицированно говорить о достоинствах и недостатках нового решения, необходимо провести их опрос и составить план устранения действительно важных недоработок. При этом часть проблем к этому времени смогут снять сотрудники автоматизации банка. А остальные решит компания разработчика, которая, получив аргументированные и понятные претензии, не сможет отказать своему клиенту.

Таким образом, система начнет работать в свою полную силу, все больше и больше приближаясь к тому идеалу, о котором думали менеджеры и специалисты банка перед началом проекта, когда рассматривали, каким образом изменить технологию работы банка и какие нововведения ему нужны.

Анализ рисков при реализации проектов

Развитие информационных систем в современном мире требует все больших и больших инвестиций. Затраты современного коммерческого банка на решение информационных задач соизмеримы, а нередко и превосходят все остальные затраты на содержание организации. Поэтому неудачи информационных проектов очень болезненны. Но еще больший ущерб приносят упущенная прибыль, нереализованные услуги, аналитические ошибки.

Несмотря на то что все проекты начинаются с полной уверенности в их реализации и практически все они имеют хорошо разработанные бизнес-планы и достаточные бюджеты, их завершение нередко откладывается на неопределенный срок, а затраты оказываются многократно превышенными.

Мы уже упоминали, что доля неудачных проектов крайне высока. Почему это происходит и кто виноват в подобных ошибках? Наказать и уволить разработчиков и отдельных исполнителей - самое простое решение, однако это не выход, так как потом выясняется, что ошибки продолжают появляться и проект заходит в тупик.

Одной из причин этого явления нередко является отсутствие системы управления рисками. Разрабатываемые планы строятся исходя из идеального течения проекта и постоянства внешних и внутренних условий. При этом исключительные ситуации (например, неожиданные изменения в законодательстве) обычно просто не рассматриваются, не говоря уже о проработке выхода из них.

Данная глава рассматривает методику, позволяющую оценить риски при реализации крупного проекта и минимизировать потери от них. Эта методика была предложена и принята рядом западных компаний и адаптирована к отечественным условиям в результате многочисленных проектов в российских кредитных организациях. Мы уже рассматривали тему управления рисками. Остановимся на этом вопросе еще раз и более детально разберем его с точки зрения проектного управления.

В основе методики управления рисками лежат систематизация, расчет вероятности и ущерба, документирование возможных решений и профилактик, оценка допустимых затрат на профилактику и резерва проекта. Оценка проводится в денежном и временном эквивалентах, так как иногда даже при неограниченном финансовом обеспечении невозможно сделать работы быстрее определенного времени.

Типы рисков в информационном проекте

Первый этап рассматриваемых работ - определение ответственных за различные типы рисков. В зависимости от ответственности за риски их условно можно разделить на три группы.

1. Проектные риски связаны с ошибками в бюджете, графике работ, с проблемами персонала, изменением требований (вызванных как изменением текущих условий проекта, так и желанием заказчика).

К данным рискам можно отнести болезни и увольнение сотрудников, изменения в текущем законодательстве, замену представителя заказчика, контролирующего процесс, изменение мнения заказчика о проекте по ходу его развития.

Ответственным за данный тип рисков исключительных ситуаций является менеджер проекта, способность которого улаживать подобного рода конфликты и определяет его профессиональную подготовку.

2. Технические риски связаны с проблемами реализации технических решений. Основными проблемами здесь обычно являются проблемы разработки (способность разработчиков реализовать ту или иную задачу), неудовлетворительная производительность системы, внедрение и затруднения, связанные с окончательной адаптацией системы под конечных пользователей.

Ответственное лицо за решение подобных проблем - обычно технический руководитель проекта или ведущий аналитик.

3. Бизнес-риски связаны с финансовой поддержкой проекта. Неожиданные сокращения бюджета, вызванные внешними факторами, могут привести не только к сокращению проекта и задач, которые он решает, но и к его полному провалу в случае недостижения главной цели. Для компании-разработчика к данному типу рисков обычно относятся ошибки в оценке рынка данного решения. В российских организациях также к подобного рода нештатным ситуациям относится потеря интереса к проекту со стороны конечных пользователей.

Ответственным лицом в кредитной организации за подобные проблемы может быть заказчик (куратор) проекта или руководитель проектного комитета. Он должен заранее определить приоритеты и организовать резервы для решения приоритетных задач каждого этапа.

Идентификация рисков

Следующим этапом проведения работ по предупреждению рисков в информационном проекте являются разработка их спецификации и системы идентификации, а также вероятностная оценка возникновения внештатных ситуаций, оценка ущерба и расчет резервов для их преодоления. Для компании-разработчика данные расчеты достаточно точны, поскольку большое количество клиентов позволяет сделать выборку для расчета статистических данных с небольшой погрешностью. К сожалению, вероятностные оценки в данных расчетах для коммерческого банка обычно являются весьма условными по причине отсутствия статистики. Для их сбора обычно предлагается набирать статистику по мере развития проекта, рассчитывая ее внутри циклов реализации проектов, а также делать более подробный анализ работ, раннее проводимых в организации. Динамический анализ рисков приведет к постоянной корректировке общих показателей, что затруднит первичное резервирование средств и проведение профилактических работ, однако механизм предупреждения внештатных ситуаций на меньшие сроки остается.

В качестве спецификации возможна разработка менеджером проекта таблицы рисков (табл. 16 ).

Таблица 16

Оформление таблицы рисков проекта

┌───────────────────────┬──────┬─────────┬─────────┬──────────┬─────────┐

│ Наименование риска │ Тип │ Вероят- │Приоритет│ Сумма │Временные│

│ │ │ность, в │ │ущерба, в │потери, в│

│ │ │ % │ │ руб. │ днях │

├───────────────────────┼──────┼─────────┼─────────┼──────────┼─────────┤

│Увеличение количества│ PS │ 60 │ 3 │ 2 000│ 2 │

│пользователей │ │ │ │ │ │

│Изменение выходных│ RE │ 60 │ 2 │ 14 000│ 4 │

│отчетных форм │ │ │ │ │ │

│Неподготовленный │ PR │ 30 │ 4 │ 2 000│ без │

│конечный пользователь │ │ │ │ │ затрат │

│Противодействие │ PR │ 10 │ 2 │ 15 000│ 10 │

│конечных пользователей│ │ │ │ │ │

│внедрению системы │ │ │ │ │ │

└───────────────────────┴──────┴─────────┴─────────┴──────────┴─────────┘

┌───────────────────────────────┐ ┌─────────────────────────────────────┐

│ Расшифровка типов │ │ Приоритеты │

├────┬──────────────────────────┤ ├───┬──────────┬──────────────────────┤

│ PS │изменения размера системы │ │ 1 │Катастрофа│> 100 000 руб. > 20│

├────┼──────────────────────────┤ │ │ │дней │

│ RE │изменения постановки задач│ ├───┼──────────┼──────────────────────┤

├────┼──────────────────────────┤ │ 2 │Критично │> 10 000 руб. > 3 дней│

│ PR │проблемы с персоналом │ ├───┼──────────┼──────────────────────┤

└────┴──────────────────────────┘ │ 3 │Проблема │> 1000 руб. > 1 дня │

├───┼──────────┼──────────────────────┤

│ 4 │Возможно │< 1000 руб. < 1 дня │

│ │игнориро- │ │

│ │вание │ │

└───┴──────────┴──────────────────────┘

По результатам построенной таблицы рассчитываются средние показатели по всем категориям и типам, а также общий ожидаемый ущерб нештатных ситуаций в проекте (табл. 17 ). Расчеты производятся по следующим формулам:

"Формула 1"

"Формула 2"

Таблица 17

Расчет уровня рисков и их влияния

┌───────────────────────────────────────────────────────────────────────┐

│ Итоговая таблица по приоритетам │

├─────────┬─────────────────────┬────────────────────┬──────────────────┤

│Приоритет│ Вероятность, │ Средний денежный │Потери времени, в │

│ │ % │ ущерб, руб. │ днях │

├─────────┼─────────────────────┼────────────────────┼──────────────────┤

│ 1 │ 0 │ 0│ 0 │

│ 2 │ 64 │ 9900│ 3,4 │

│ 3 │ 60 │ 1200│ 1 │

│ 4 │ 30 │ 600│ 0 │

├─────────┴─────────────────────┴────────────────────┴──────────────────┤

│ Итоговая таблица по категориям │

│ PR │ 37 │ 2100│ 1 │

│ RE │ 60 │ 8400│ 2,4 │

│ PS │ 60 │ 1200│ 1,2 │

│ Общий итог │

│ │ │ 11 700│ 4,6 │

└─────────┴─────────────────────┴────────────────────┴──────────────────┘

Результатом данной таблицы является предварительная оценка возможного ущерба от нештатных ситуаций. Данные показатели можно внести в проект в виде страховых резервов времени и денег.

Однако основной задачей данных работ является не столько расчет резерва, сколько снижение затрат и оценка и сравнение затрат на профилактические работы с затратами от ожидаемого ущерба.

Снижение потерь

Снижение потерь возможно за счет трех действий: профилактики (предотвращения), мониторинга (своевременного распознавания ситуации) и управления критической ситуацией (правильными действиями в случае ее возникновения). Рассмотрим более подробно каждое из них.

Профилактика - некие затраты для устранения, снижения вероятности или снижения ущерба нештатной ситуации. Нередко очень трудно убедить заказчика в дополнительных затратах, особенно если угроза не очень понятна заказчику. Например, достаточно легко получить дополнительное финансирование на дополнительную проработку системы безопасности (угроза несанкционированного доступа), однако нередко очень трудно добиться обучения конечных пользователей, хотя неграмотная эксплуатация также может привести к образованию дыр в системе безопасности. И обычно только хорошо обоснованный документ с оценкой вероятности и значения ущерба может убедить заказчика в правильном распределении средств.

Мониторинг означает разработку системы показателей, определяющих возникновение той или иной проблемы, и механизмов их отслеживания. Своевременное распознавание проблемы нередко позволяет минимизировать потери или свести их к нулю. Например, отслеживание текущего законодательства и своевременное распознавание принципиальных изменений позволят существенно сократить затраты на адаптацию за счет изменений ряда концептуальных решений, таких, как изменение структуры данных или разработка новых алгоритмов. В случае, если время упущено, начинают работать механизмы латания дыр, которые приводят к усложнению системы и, как следствие, росту временных затрат на решения новых задач.

Управление критической ситуацией означает документирование и регламентирование действий в случае возникновения непредвиденной ситуации. Четкое понимание действий менеджером позволяет многократно снизить отрицательный эффект. Предварительное документирование действий позволит скорректировать расчетный эффект ущерба и, как следствие, снизить суммы резервов и сделать проект более привлекательным для инвесторов и заказчиков. Также частью работ по этому направлению может быть создание механизмов смягчения критической ситуации. Например, наличие информации о квалифицированных соискателях на работу в организации будет очень кстати при неожиданном увольнении ключевого работника.

Основой работ по сокращению затрат является разработка плана противодействия рискам проекта. Примером оформления данного плана может служить дальнейшее развитие таблицы рисков (табл. 18 ).

Таблица 18

Оформление плана противодействия рискам

┌─────┬────────┬────────────────┬───────────────┬──────────────┬────────────────┬──────────────────┐

│ N │Вероят- │ Ущерб │ Подробное │ Профилактика │ Механизм │ Что делать │

│ │ ность │ │ описание │ │ мониторинга │ │

├─────┼────────┼────────────────┼───────────────┼──────────────┼────────────────┼──────────────────┤

│ 1 │ 40% │2-кратное увел.│Потеря интереса│Максимальная │Постоянное │Попросить │

│ │ │сроков. │у пользователей│популяризация │обсуждение с│руководство │

│ │ │Профилактика = 1│к развитию│проекта, │группой │заказчика отметить│

│ │ │чел/д; │системы из-за│построение │внедрения │подразделения, │

│ │ │эффект Р = 20%; │угрозы │связи между│отношения │обеспечивающие │

│ │ │преодоление =│сокращения │эффектом от│пользователей к│наибольшую │

│ │ │6000 руб./отдел;│ │проекта и│проекту │поддержку проекта.│

│ │ │эффект = Р/2 │ │ростом доходов│ │Рассмотреть │

│ │ │ │ │ │ │исключение │

│ │ │ │ │ │ │сопротивляющихся │

│ │ │ │ │ │ │подразделении из│

│ │ │ │ │ │ │участия в проекте │

│ 2 │ │ │ │ │ │ │

│ 3 │ │ │ │ │ │ │

│ 4 │ │ │ │ │ │ │

└─────┴────────┴────────────────┴───────────────┴──────────────┴────────────────┴──────────────────┘

Из таблицы хорошо виден эффект от контроля за рисками, и этот факт непременно поможет менеджерам максимально контролировать весь проект в целом и более аргументированно отчитываться перед инвестором и заказчиком. Однако необходимо помнить, что управление рисками носит относительный характер и все приведенные цифры в таблице условны и служат для общей оценки нестандартных ситуаций. Также необходимо помнить о динамическом изменении основных показателей проекта, что приводит к постоянному пересчету приводимых ранее величин.

Снижение затрат в проектах

Ожидаемая в следующем году новая волна изменений в правилах бухгалтерского учета приведет российские кредитные организации к необходимости серьезной доработки или смены информационных систем. Безусловно, опыт, полученный банками в области автоматизации за прошедшее десятилетие, позволит существенно сократить потери от изменения правил и механизмов учета. Рассмотрим различные приемы, направленные на сокращение затрат при выполнении различных проектов, связанных с изменениями в текущей деятельности работающей организации.

Одним из самых эффективных путей сокращения проектных издержек является сокращение требуемых ресурсов и использование вместо них уже имеющихся.

К дополнительным ресурсам проекта, то есть тем, на которые необходимы дополнительные затраты, в кредитной организации можно отнести:

* персонал;

* помещение;

* вычислительную технику и программное обеспечение;

* коммуникации.

Как искать человеческие ресурсы для проекта, мы уже говорили. Резервом помещений в банке являются, как правило, переговорные комнаты и комнаты для конференций и заседаний. Но если проект требует долгосрочного использования помещения, то аренды или покупки дополнительного помещения скорее всего не избежать.

Резервом вычислительной техники может являться устаревшее оборудование. Часто в отделах автоматизации скапливаются устаревшие компьютеры и техника. Приведем примеры решения подобных задач.

Временному сотруднику на время проекта требуется компьютер. Можно предложить ему старый компьютер. В 70% случаев этого будет достаточно. Другой вариант: взять компьютер сотрудника, находящегося в отпуске, и заменить жесткий диск. Если сотрудник возвращается из отпуска до завершения проекта, можно переставить данные участника проекта на другой компьютер. Более простой вариант распределенного использования вычислительной техники будет доступен, если в организации для работы используются сетевые диски.

Набор задач, реализуемых на одном мощном сервере, можно разбить и использовать маломощные компьютеры. Например, почтовые и интернет-серверы для небольших рабочих групп могут быть реализованы на устаревших рабочих станциях.

Следует рассмотреть возможность обновления (upgrade) вычислительной техники. Иногда для эффективной работы приложения достаточно просто увеличить объем оперативной памяти, стоимость которой невысока.

В отношении программного обеспечения следует придерживаться позиции противостояния увеличению количества используемых программ. Все задачи надо стараться реализовывать в уже имеющихся приложениях. Особенно это относится к системам управления базами данных. Если банк работает на MS SQL Server, проект должен реализовываться на этой платформе, а не на ORACLE, и наоборот. В противном случае дополнительные затраты возрастут на суммы от $5 до 100 тысяч в зависимости от размеров организации.

Для коммуникаций также существуют некоторые резервы. Как правило, это несанкционированный трафик: от сетевых компьютерных игр до блужданий в компьютерных сетях или личных разговоров по телефону. Следует осуществлять контроль передаваемой информации по компьютерным сетям. Даже если возможности такого контроля нет, можно создать его видимость. Эффект может оказаться неожиданным и крайне позитивным для проекта.

Рассмотренный нами список резервов не является полным. Каждая организация имеет свои секреты и приемы работы, которые могли бы его дополнить. Некоторые из них, возможно, не дадут эффекта. Однако время "шальных" денег прошло, и надо использовать любую возможность их экономии, не забывая при этом, что цель - реализация проекта, а не экономия средств.

Методы поиска решений

Развитие теории управления как науки в России идет по пути адаптации западных технологий управления к нашей действительности. Однако нередко анализ показывает, как правило, если не негативное влияние западных школ, то отсутствие положительного эффекта. Данная глава предлагает к рассмотрению одну из российских технологий поиска решений - "Теории решения изобретательских задач" (ТРИЗ), разработанную Генрихом Альтшуллером и группой единомышленников, которая была очень популярна до перестройки и успешно применялась для решения технических задач. Универсальность основного алгоритма поиска решений позволяет использовать ТРИЗ и в гуманитарных науках. Основной особенностью данного подхода является принципиальная возможность решения нестандартных задач, чего не позволяют сделать западные методики. Рассмотрим возможность применения ТРИЗ в проектном управлении.

В основе теории лежит алгоритм решения задач (АРИЗ), который представляет собой последовательность необходимых действий в процессе поиска решения. При выполнении каждого этапа необходимо тщательно обдумывать его результаты и обязательно записывать все соображения, возникающие по ходу выполнения задачи. Алгоритм содержит девять этапов. Однако нужный ответ может появиться на любом из них. При этом рекомендуется продолжить выполнение алгоритма, так как возможно получение нового решения, превосходящего по результатам уже имеющееся.

Рассмотрим составляющие АРИЗ и попытаемся найти решения для некоторых задач, которые приходится решать менеджерам проектов в коммерческом банке. Описанный ниже алгоритм содержит некоторые отличии от алгоритма, разработанного Альтшуллером, так как был адаптирован авторами под задачи проектного управления.

Анализ задачи

Итак, первый этап - это анализ. Основная цель первого этапа - переход от расплывчатой ситуации к четко построенной и предельно простой схеме задачи. Этап содержит семь действий, позволяющих четко сформулировать задачу и выявить основные противоречия.

1. Записать условия мини-задачи (без специальных терминов) по следующей форме.

Участники процесса. Указать цели и задачи каждого участника, его возможности и связи. Указать особенности каждого участника и (в случае, если участник - организация или любая другая группа людей) его составляющие.

Противоречия. Перечисляются все противоречия.

Что необходимо при минимальных изменениях. Указать результат, который должен быть получен. Мини-задачу получают из общей проблемы, вводя ограничения: все остается без изменения или упрощается, но при этом задача достигает своего решения или исчезает противоречие. Переход к мини-задаче не означает, что начато решение основной задачи. Наоборот, введение дополнительных ограничений (результат должен быть получен из ничего) ориентирован на обострение конфликта и заранее отрезает пути к компромиссным решениям.

Пример мини-задачи.

Участники процесса:

сотрудник "А". Хороший специалист, знает учет, пользуется уважением в коллективе;

сотрудник "В". Имеет связи за пределами организации. Однако груб с коллегами, имеет ряд недостатков.

Противоречие: между ними имеется скрытое соперничество, выдвижение одного может привести к увольнению другого. В случае увольнения сотрудник "А" может увести с собой и других сотрудников отдела, что существенно нарушит деятельность организации. В случае увольнения сотрудника "В" будет потерян важный клиент.

Необходимо при минимальных изменениях: назначить нового руководителя отдела, удержав обоих сотрудников в организации.

Термины и понятия в описании задачи следует заменять простыми словами без дипломатических уверток. Например, фразу "имеет связи" лучше поменять на описание этих связей: "супруг является директором данной фирмы"; "привел этого клиента в банк (имя); знакомство (учились в одном классе с начальником отдела маркетинга)". Согласитесь, что описание влияния сотрудника "В" в фирме клиента существенно расширяется.

2. Анализ конфликтующей пары.

В нашем случае конфликтующей парой являются сотрудники "А" и "В". Данный этап требует дополнительно проанализировать данных сотрудников, учитывая следующие параметры:

* развитие ситуации во времени. В рассматриваемом случае необходимо оценить дальнейший карьерный рост каждого из них, а также их ожидания в продвижении по карьерной лестнице. Например, если очевидно, что один из сотрудников долго на предлагаемой должности не задержится, это может существенно повлиять на принятие вашего решения;

* силу связи участников конфликта с окружающей средой. Здесь надо еще раз оценить, насколько сильно участник конфликта может оказывать влияние на окружающих;

устойчивость участников конфликта к психологическому воздействию. Данный пункт отсутствует в АРИЗ, поскольку технологические процессы не поддаются психологическому воздействию, однако в гуманитарной области это воздействие часто оказывается решающим.

3. Построение графической схемы конфликта.

Очень многие технологии, связанные с поиском решений, рекомендуют графическое отображение процессов. Это объясняется повышенной восприимчивостью человеческого мозга к графическим образам. АРИЗ также предполагает построение подобных графических схем. Какого-то единого стандарта, как, например, в IDEFO, здесь нет. Единственное условие - простота и понятность.

Шаги 2 и 3 уточняют общую формулировку задачи. Поэтому после третьего шага необходимо вернуться к первому, проверить несоответствия и скорректировать их.

4. Выбор типового решения, которое обеспечивает наилучшее осуществление главного процесса.

Этот шаг не приводит к полному решению задачи, однако заставляет провести оценку конфликта и его последствий. Насколько на самом деле увольнение одного из рассматриваемых сотрудников критично для организации? На какие затраты может пойти организация для разрешения данного конфликта? В дальнейшем оценка ущерба от конфликта станет одним из основных параметров поиска решений

5. Построение модели самого плохого развития ситуации. Данный шаг является развитием предыдущего во времени, поскольку значение разовых потерь может быть существенно меньше, чем ущерб, который получит организация впоследствии. Например, в нашем случае это могут быть неуверенность и чувство несправедливости у оставшихся сотрудников, что может привести их к поиску нового места работы.

6. Окончательная формулировка задачи.

Все вышеперечисленные шаги позволяют провести окончательную формулировку задачи, которая должна содержать в себе помимо описания мини-задачи следующие составляющие:

- участников конфликта;

- оценку ущерба, равную наихудшему развитию ситуации при выборе лучшего стандартного решения;

- требования к Х-элементу (под Х-элементом подразумевается изменение в системе, направленное на достижение поставленной цели).

В нашем случае задача будет примерно такой: сохранить профессиональный коллектив отдела, повысив реального лидера коллектива, и при этом не потерять клиента, представитель которого претендует на должность руководителя.

1. Проверить возможность применения стандартных решений подобных задач из разных областей жизни.

В стандартном описании "алгоритма решения задач" систематизация стандартных решений является достаточно большой областью теории, выходящей за рамки данной главы. Для простоты мы воспользуемся простым перебором возможных решений проблемы, когда два объекта стремятся занять одну область. Вот возможные решения.

Разнесение во времени. Сначала вакансия отдается одному сотруднику, затем он переводится на другую должность, и место отдается второму сотруднику.

Разделение области на подобласти. Под данным решением подразумевается разделение основных атрибутов вакансии руководителя на два списка и распределение их между участниками конфликта. Например, сотрудник "А" получает реальную власть в принятии решений, распределении работ, ответственность за результат. Сотрудник "В" получает звание и администраторские функции. Реально этого можно достичь, выделив сотрудника "А" в отдельный проект, контролируемый высшим руководством организации.

Дублирование области. Это часто применяемое решение, заключающееся в создании должности специально под сотрудника с целью удовлетворения его амбиций.

Не решать задачу. Поскольку негативные последствия в рассматриваемом конфликте начинаются только после принятия решения, то одним из решений может стать его отсутствие, что, возможно, приведет к отсутствию конфликта. Учитывая динамичность области задачи, можно ожидать изменения рассматриваемой системы и исчезновения конфликта решений.

Удаление лишнего звена системы, приводящего к конфликту. Если еще раз внимательно перечитать условия задачи, то становится видно, что организации не интересен сам сотрудник "В". Условия требуют сохранения клиента. Сотрудник является всего лишь связующим звеном. Возможно, следует пересмотреть условия задачи и рассмотреть новую задачу по созданию новой связи между организацией и клиентом без посреднических услуг сотрудника.

Помимо этих чисто технических решений для задач управления возможны и психологические решения. Среди них:

подмена цели. Данное решение включает в себя попытку убедить одного из сотрудников, что его настоящая цель заключается не в занимаемой должности, а, например, в финансовом благополучии. В результате, правда, придется повысить одному из них заработную плату;

отвлечение внимания. Увлечь сотрудника решением новой задачи или новым проектом, что сделает потерю должности не столь болезненной и не приведет к критической точке конфликта.

Нет сомнений, что существуют и другие решения рассматриваемой проблемы. Но, так или иначе, задача подобной сложности скорее всего будет решена именно на первом этапе, основной идеей которого является необходимость как следует разобраться в проблеме. Возможно, решение появится само собой. При рассмотрении следующих этапов мы усложним пример и рассмотрим, к каким неожиданным и красивым решениям может привести использование данного алгоритма.

Анализ ресурсов

Второй этап - анализ ресурсов. "Цель второго этапа - учет имеющихся ресурсов, которые можно использовать при решении задачи".

Второй этап состоит из трех шагов: определения оперативной зоны, определения оперативного времени и определения финансово-производственных ресурсов. В качестве примера для анализа будет рассматриваться проблема ликвидности активов: "Организации срочно требуются свободные средства для осуществления текущих платежей по договору, однако имеющиеся у нее активы являются низколиквидными. Необходимо найти решение преобразования данных активов в свободные средства с минимальными потерями в определенные сроки".

1. Определение оперативной зоны. В простейшем случае оперативная зона - это область, в пределах которой возникает конфликт, указанный в модели задачи, ограниченная правовыми и этическими рамками. Границами этой зоны является свод обязательных правил, нарушение которых недопустимо при решении задач и. Наиболее часто используются следующие ограничения:

- соответствие законодательной базе - при описании данных ограничений следует четко определить области действия законов. Необходимо контролировать пересечение областей действия задачи и действия различных законов;

- соответствие нормам поведения в обществе и внутренним регламентам.

2. Определение оперативного времени. Оперативное время - это имеющиеся ресурсы времени: время до конфликта и время продолжительности конфликта.

В рассматриваемом примере время до конфликта - это время на подготовку операции перевода активов в свободные средства, время продолжительности конфликта - это время, требуемое на саму операцию. Соответственно сумма обоих временных интервалов должна быть меньше времени до начала платежа.

3. Определение оперативных ресурсов (инструментов). Ресурсы - это средства, доступные в оперативное время в оперативной области для решения задачи. Применительно к задачам управления определяются следующие типы ресурсов:

* ресурсы времени;

* финансовые ресурсы;

* производственные ресурсы;

* людские ресурсы.

При этом следует помнить, что нехватка одного вида ресурсов при решении задачи может компенсироваться избытком другого ресурса, хотя и не всегда. Например, нехватка людских ресурсов может быть компенсирована автоматизацией процесса, то есть производственным ресурсом.

По отношению к области задачи ресурсы также делятся на 3 вида:

1) внутрисистемные - к данному типу относятся ресурсы участников конфликта и внутренние инструменты. Например, находящиеся в активах здания можно сдавать, что даст дополнительные средства. Также возможно в случае, если активы находятся в залоге у организации, попытаться ускорить процесс возврата выданного под данный ресурс кредита;

2) внешнесистемные - к данному виду относятся ресурсы внешней среды, как специфичные для данной задачи, так и общего плана. В рассматриваемом примере это могут быть различные варианты межбанковского кредитования, торговые операции;

3) надсистемные - обычно под данным видом рассматриваются "отходы" посторонней системы или недорогие ресурсы (очень дешевые посторонние элементы, стоимостью которых можно пренебречь). Часто в российской практике к подобным ресурсам относят внеурочное время работы сотрудников, которое не всегда оплачивается дополнительно.

На данном шаге рассматриваются только имеющиеся ресурсы. Их выгодно использовать в первую очередь. Если их окажется недостаточно, в дальнейшем можно расширить поиск. Анализ ресурсов на данном этапе является предварительным.

Определение идеального решения

Третий этап - определение идеального решения. В результате применения третьего этапа АРИЗ должен быть сформулирован образ идеального решения (ИР). Определяются также физические противоречия, мешающие достижению ИР. Не всегда возможно достичь идеального решения, но ИР указывает направление на наиболее сильный ответ.

Для описания идеального решения выполняются следующие шаги.

Записать первую формулировку идеального решения исходя из следующих условий: данное решение, не усложняя существующую систему и не вызывая вредных последствий в течение оперативного времени в оперативной области, должна устранять существующий конфликт, сохраняя основной процесс задачи.

Применительно к рассматриваемой выше задаче первичная формулировка идеального решения может звучать так: данное решение осуществляет своевременную оплату необходимых средств, при этом объем имеющихся активов уменьшается не больше чем на сумму платежа, без каких-либо последствий.

Следует учитывать, что данное описание носит первичный характер, так как очень трудно оценить последствия любого решения, связанные с усложнением системы или воздействием на внешнюю среду.

Усилить формулировку идеального решения дополнительным требованиям использования только оперативных ресурсов. Ограниченность набора оперативных ресурсов позволяет произвести оценку эффективности использования всех их видов и типов, при этом вырабатываются различные возможные линии решений, сформированных путем использования разных типов инструментов и свойств участников задачи. Оценить, какая из линий максимально близко подходит к идеальному решению. При прохождении АРИЗ последовательный анализ постепенно заменяется параллельным. Решение задачи сопровождается ломкой старых представлений. При работе с АРИЗ записи необходимо вести, всячески избегая спецтерминов, поскольку они усиливают психологическую инерцию.

Записать формулировку физического противоречия на макроуровне. Физическим противоречием называют противоположные требования к состоянию оперативной зоны. Например, требование выполнения работы в срок и качественно. При достаточно малом сроке работа не может быть выполнена качественно. В примере с ликвидностью активов противоречие может звучать так: невозможно осуществить беззатратное преобразование одних видов активов в другие. При этом размер затрат определяется оперативным временем задачи. Чем меньше время, тем больше потери.

Рекомендуется также графическое отображение противоречия с отображением воздействия на задачу различных видов решения (рис. 23 ).

"Рис. 23. Графическое отображение противоречий и возможных решений"

Записать формулировку конечного варианта идеального решения. Три первые этапа АРИЗ существенно перестраивают исходную задачу. Итогом этого процесса являются окончательная формулировка идеального решения и физическое описание задачи. Именно понимание того, что физически невозможно в рассматриваемой проблеме, и делает задачу готовой к окончательному решению по методологии ТРИЗ. Получив физическое описание проблемы, необходимо еще раз просмотреть систему стандартных решений для данной физической задачи. И если она не решена, то переходить к следующему этапу.

Мобилизация новых ресурсов

Четвертый этап - мобилизация новых ресурсов с целью расширить ресурсную базу, доступную для решения задачи. Данный этап заключается в переборе различных приемов, направленных на увеличение доступных ресурсов и методов их применения для решения задачи. Для поиска новых ресурсов в качестве примера будет использоваться рассматриваемая выше задача нелеквидности активов.

1. Объектное разделение задачи является первым шагом расширения ресурсной базы. При этом определяются инструменты, способные оказывать воздействие на каждый объект задачи, и методы собственно объектов. На данном этапе также рекомендуется применять графические изображения задачи.

В примере мы определим объекты, их методы и методы воздействия на них.

Здание (неликвидный актив) - продажа, залог, сдача в аренду, получение страховки, передача в качестве доли в сторонних проектах, использование для развития собственного бизнеса.

Свободные средства - заем, прибыль, отсрочка других платежей или различные варианты экономии, выпуск векселей.

Платеж - перенос срока платежа, изменение суммы платежа, изменение формы платежа (замена денежной суммы на право владения тем же зданием или на акции самого банка, или на векселя организации).

Возможно, существуют еще множество различных методов рассматриваемых выше объектов, но для примера достаточно и этих.

Из приведенных списков начинают проглядываться принципиально новые доступные решения (передача части имущественного права в качестве платежа или предложения по участию получателя платежа в новом проекте). Возможно, подавляющее число подобных решений более удалены от идеального решения, чем типовые решения, однако среди них возможно присутствие инструмента, позволяющего улучшить показатели уже лучшего из имеющихся решений.

2. Рассмотрение возможности решения задачи смешением различных ресурсов. На данном этапе рассматривается возможность одновременного использования доступных ресурсов. Строятся различные модели решения и рассматриваются влияния каждого из ресурсов на изменения параметров линии решения. В примере отсрочка других платежей и экономия средств могут снизить требуемые денежные ресурсы до такой степени, что появится возможность получения дешевого кредита под залог целого здания без дополнительных экспертиз.

3. Рассмотрение возможности решения задачи ресурсами, являющимися производными от имеющихся. Для того чтобы получить производные ресурсы и методы, необходимо изменить статус имеющихся объектов. Следует попытаться описать имеющиеся объекты другими словами и оценить доступные методы новых понятий.

4. Рассмотрение возможности решения задачи с использованием психологических методов. На данном этапе рассматривается возможность изменения требования к условиям задачи со стороны других людей путем психологического воздействия на них. Даже если получателю платежа не нужны векселя, есть смысл попытаться убедить его в возможности данного решения. Использование психологических методов может оказаться очень эффективным на первом этапе. Однако часто данные методы имеют негативные последствия, поэтому требуется дополнительный анализ их нейтрализации.

Применение информационного фонда

Во многих случаях четвертый этап АРИЗ приводит к решению задачи, однако если ответа до сих пор нет, надо пройти пятый этап, цель которого - использование опыта, сконцентрированного в информационном фонде. К данному этапу задача достаточно проясняется, чтобы эффект от использования информационного фонда был максимальным.

На этом этапе подключаются все возможные источники знаний и типовых решений. К наиболее распространенным источникам относятся:

* знания и опыт окружающих людей;

* литература;

* Интернет;

* специализированные эксперименты;

* консультанты.

При работе с информационным фондом рассматриваются примеры решения похожих задач и опыт использования имеющихся ресурсов. В случае отсутствия какой-либо информации проводятся эксперименты. Кроме того, следует помнить, что каждый человек имеет свой собственный информационный фонд, возможно, включающий в себя недоступные вам источники информации.

Изменение или замена задачи

Шестой этап - изменение или замена задачи. Простые задачи решаются буквальным преодолением противоречий, например разделением конфликтующих объектов во времени или пространстве. Решение сложных задач обычно связано с изменением смысла задачи - снятием первоначальных ограничений и психологической инерции. Процесс решения на данном этапе в сущности есть процесс корректировки задачи.

Для изменения задачи используются следующие шаги.

Проверить, не является ли формулировка задачи сочетанием нескольких разных задач. Например, как уже стало очевидным, задачу с ликвидностью можно разделить на две: превращение актива в свободные средства и осуществление платежа при отсутствии средств.

Рассмотреть более общую задачу. Для кредитной организации задачей более высокого уровня может быть получение стабильного дохода. Рассмотрение с точки зрения человека, занятого решением этой задачи, других задач может свести их к проблеме, как выкрутиться из создавшейся ситуации с минимальными потерями. Однако не стоит очень углубляться в обобщение задачи, так как в конечном этапе в результате подобных переходов будут достигнуты общечеловеческие ценности, такие, как материальные блага, стабильность, здоровье и т.п., что может увести от решения конкретной проблемы.

На этом этапе АРИЗ заканчивает собственно поиск решения. В случае отсутствия решения шестой этап входит в бесконечный цикл по изменению условия задачи, в каждом из которых приходится повторять 1-6 этапы соответственно.

Последующие этапы связаны с оптимизацией имеющегося решения и его преобразования в универсальное для решения для последующих задач. К этим этапам следует также обращаться в случае, если решение было найдено раньше шестого этапа.

Проверка полученного ответа

Седьмой этап - проверка полученного ответа, анализ способа устранения противоречия задачи. Главная цель седьмого этапа АРИЗ - проверка качества полученного ответа. Противоречие должно быть устранено почти идеально, с минимальными затратами. Лучше потратить время на получение более сильного решения, чем потом бороться за трудновнедряемую идею.

Анализ решения. Для проведения подобного анализа следует ответить на следующие вопросы:

* Обеспечивает ли полученное решение выполнение главного требования идеального решения?

* Какое противоречие устранено (и устранено ли) полученным решением?

* Управляема ли полученная система?

* Будет ли данное решение работать многократно?

Построение плана внедрения найденного решения. Результатом данного шага должен стать бизнес-план реализации предложенного решения с оценкой затрат на его реализацию. При этом необходимо провести сравнение положительного эффекта и затрат на реализацию и поддержку данного решения. В случае, если решение не применялось ранее и не может быть применено в будущем, рекомендуется как минимум двукратное превышение ожидаемой выгоды над затратами. Если затраты на реализацию слишком высоки, рекомендуется продолжить оптимизацию решения путем анализа эффективности использования дополнительных методов и ресурсов.

Переносимость найденного решения на другие задачи

Восьмой этап - переносимость найденного решения на другие задачи. Действительно хорошая идея не только решает конкретную задачу, но и дает универсальный ключ ко многим другим аналогичным задачам. Цель этапа - максимальное использование ресурсов найденной идеи.

Обычно менеджеру приходится решать однотипные задачи, поэтому любое решение, реализованное успешно, может применяться многократно. В общем случае этот этап не нужен для решения задачи, однако его прохождение может дать большой дополнительный эффект. Однако, если работа ведется не только ради решения конкретной задачи, выполнение этого этапа может стать началом разработки новой концепции управления. Этап включает в себя следующие шаги.

1. Определение изменения в системе более высокого уровня. Необходимо еще раз сформулировать основную идею и рассмотреть, как она повлияла на различные внешние системы.

2. Проверить, сможет ли решенная задача применяться в других ситуациях. Например, если вы в первом примере про двух сотрудников нашли метод, как устанавливать добрые отношения с клиентом, минуя их представителей в вашей организации, разве этот метод недостоин быть примененным ко всем клиентам или использован для привлечение новых? И наоборот, если вам удалось сохранить коллектив, избегнув продвижения в карьере, разве вы не будете использовать этот прием снова и снова?

3. Попытайтесь менять условия задачи, сохраняя общий принцип ее решения. Увеличивайте значения параметров задачи до бесконечности и уменьшайте до нуля, определите диапазон, в котором данный принцип работает, и область наибольшего эффекта. Данный принцип становится особенно понятен в примере с ликвидностью. Уменьшая сумму платежа, вы придете к сумме, которую вы сможете оплатить из своего кармана и, следовательно, ограничить область применения задачи снизу.

4. Рассмотрите возможность использования принципа обратного полученному. Если вы нашли метод, как удержать сотрудника, может быть, где-то рядом находится метод, как от него избавиться.

Анализ хода решения

Девятый этап - анализ хода решения. Как уже говорилось, сама по себе рассматриваемая методика носит общий характер. Она позволяет лишь систематизировать поиск правильного решения. Если вы допустили отклонение от него, постарайтесь проанализировать его причины. И если изменения оказали явно положительный результат, необходимо зарегистрировать их. Однако надо учитывать, что изменения алгоритма, оказавшие положительный эффект при решении одной задачи, могут затруднить решение другой задачи.

Часть 4. Практические решения и инструментарий

Операционно-техническая среда

Любое решение в сфере ИТ должно быть поддержано имеющимся информационно-технологическим окружением. Сети, серверы, рабочие станции и прочее техническое оборудование входят в список системных требований любого программного продукта и ИТ-решения. Задачей ИТ-менеджера при рассмотрении технических составляющих информационной системы является определение их возможностей, скрытых ресурсов для более точного определения затрат на обеспечение системных требований.

При составлении списка требований разработчики обычно определяют следующие технические параметры:

* процессоры - устройства, выполняющие управление системой и осуществляющие обработку данных;

* память системы - множество устройств, осуществляющих хранение информации;

* интерфейсы - механизмы взаимодействия технических устройств между собой и с внешней средой;

* система коммуникаций или сеть - структуры и механизмы, осуществляющие обмен информацией между компонентами системы;

* операционная система - программное обеспечение, обеспечивающее базовый набор функций управления техническими компонентами системы.

Для простейших систем определяются только требования к одному компьютеру. Обычно это персональный компьютер, который может обеспечить работу всей системы. Такая архитектура носит название централизованной системы. В зависимости от мощности компьютера, на котором они базируются, централизованные системы могут решить и более глобальные задачи. Замена персонального компьютера на многопользовательскую большую, супермини - или мини-ЭВМ позволит централизовать множество задач в рамках одной центральной системы. Однако высокая стоимость данных решений, а также отсутствие достаточного количества специалистов и малое количество программных решений, базирующихся на центральном компьютере, ограничивают использование таких систем.

В результате с ростом сложности, объемов информации и количества одновременно выполняемых процессов технические требования выходят за рамки одного устройства и приводят к созданию распределенной системы.

В зависимости от типа распределяемых ресурсов современные технологии предлагают три вида архитектур распределенных систем.

1. Распределенные вычисления - компьютерная система, в которой обработка выполняется несколькими компьютерами, подсоединенными к сети. При этом имеется в виду любая компьютерная система, в которой каждый компьютер решает свою задачу, а сеть поддерживает функционирование системы как единого целого.

2. "Клиент-сервер" - модель построения распределенной вычислительной среды, в которой интерфейсная часть задачи выполняется на машине пользователя, а требующая больших ресурсов обработка запросов осуществляется одним или несколькими серверами.

3. Кластеры - вычислительная система, представляющая совокупность относительно автономных систем (компьютеров) с общей дисковой памятью (общей файловой системой), средствами межмашинного взаимодействия и поддержания целостности баз данных. Использование кластеров увеличивает производительность и надежность системы, так как в случае сбоя одного компьютера его работу берет на себя другой. С точки зрения пользователя кластер выглядит как единая система.

Эти архитектуры не являются взаимоисключающими, использование для части ресурсов архитектуры "клиент-сервер" может быть совмещено с использованием распределенных вычислений для других ресурсов.

В этой части книги приводится общий обзор технических компонент информационной среды кредитной организации, а также содержатся описания и примеры решений для обеспечения системных требований различных банковских продуктов.

Структура сети

Создание любой информационной системы, выходящей за рамки одного компьютера, невозможно без связи между устройствами или сети. Сеть - это любое соединение между различными устройствами, способное передавать информацию. Задача сети состоит из двух составляющих: передачи информации и предоставления какого-либо ресурса в общее пользование.

Существует разделение на телефонную, компьютерную, телевизионную и прочие виды сетей. Хотя современная технология может объединить их все в единое пространство, организации редко объединяют их в целое. Это объясняется многими причинами: требуются большие капиталовложения, не всегда понятны технические аспекты.

При изучении сетевых технологий следует всегда помнить о множестве их уровней и совместимости. Это значит, что для успешной реализации сетевых проектов необходимо продумать вопросы от физического описания компонентов до общих вопросов администрирования, при этом каждому из шагов будет соответствовать собственная технология, достойная отдельной книги. И даже при решении задачи одного уровня возможно несколько решений, которые могут работать и отдельно, и вместе.

Связь в информационной сети

Фактически любой вид проводной и беспроводной связи может стать сегментом (частью) любой сети. Существуют технологии, позволяющие использовать для сетевого соединения даже электрическую сеть, а также огромный диапазон электромагнитных излучений (от килогерц до гигагерц) для беспроводной связи. Область действия систем связи намного больше доступной для человека области существования организации. Поэтому при анализе передачи данных рассматриваются не возможность реализации соединения, а экономические и качественные показатели решения. Рассмотрим их.

Стоимость реализации. При создании нового сегмента разовые затраты будут всегда. Даже в случае, если канал связи арендуется у сторонней организации, необходимо дополнительное оборудование, обеспечивающее взаимодействие между сетями, а также затраты на администраторскую настройку взаимодействия с новым сегментом. Данный параметр зависит от типа связи, пропускной способности, области прохождения сегмента, типа уже имеющейся сети, а также от маркетинговой политики поставщика данного сегмента связи в случае его аренды.

Пропускная способность. Данный параметр является основной технической характеристикой соединения. Он определяется объемом информации, который максимально может быть передан в единицу времени. Наиболее распространенной единицей является "бод" - бит в секунду. При анализе данного параметра требуется помнить, что итоговая скорость передачи данных всегда отличается от заявленной для соединения данного типа связи. Это объясняется тем, что существует большое количество факторов, влияющих на скорость передачи данных, определяемых сетевыми протоколами, внешними помехами и качеством компонентов сети. Также, оценивая требуемое значение, следует помнить о различных технологических приемах оптимизации системы связи, таких, как создание буферов данных, компрессия передаваемых данных, систематизация информационных потоков.

Стоимость сопровождения. Данный параметр определяется денежными затратами на поддержание работоспособности канала связи. В основном он учитывается, если канал связи арендуется и равен арендной плате. В случае если канал полностью принадлежит организации, то часто затраты на его поддержку не рассматриваются вовсе или включают в себя лишь затраты на ремонт.

Устойчивость в работе канала определяется количеством сбоев, приводящих к нарушению передачи данных, и временем восстановления. Как правило, кратковременные сбои происходят постоянно, однако системы передачи данных восстанавливают связь в автоматическом режиме достаточно быстро, что приводит только к кратковременному снижению производительности и не несет значительного ущерба, следовательно, может не учитываться. Для анализа данного параметра обычно рассматриваются нарушения в связи, приводящие к разрыву соединения и дополнительным действиям персонала.

Защищенность информации. Любая передача данных связана с риском того, что эти данные будут перехвачены и использованы злоумышленниками. Однако для различных видов связи возможность и затраты для несанкционированного доступа к передаваемым потокам данных существенно различаются. Данный параметр носит относительный характер и в общем оценивается как затраты на получение несанкционированного доступа к передаваемым по каналу потокам данных.

В таблице 19 рассматриваются наиболее распространенные виды связи, используемые в кредитных организациях сегодня.

Безусловно, развитие средств телекоммуникаций дает организации ряд преимуществ в развитии бизнеса. Однако существует порог затрат, после которого следует передать реализацию соединений сети специализированным телекоммуникационным компаниям. Общую стратегию развития средств связи для средней кредитной организации можно определить следующим положением: все каналы связи внутри зданий принадлежат самой организации, а все внешние соединения арендуются.

Таблица 19

Наиболее распространенные виды связи

┌──────────────┬────────────────┬──────────────────────┬──────────────────┬────────────┬──────────┬────────┐

│ Тип связи │Где используется│ Стоимость реализации │ Стоимость │ Пропускная │ Устойчи- │ Защита │

│ │ │ │ обслуживания │способность │ вость │ │

├──────────────┼────────────────┼──────────────────────┼──────────────────┼────────────┼──────────┼────────┤

│Проводная │Связь с внешними│Минимальна, обычно уже│Средняя стоимость│Низкая, 2-50│Низкая │Низкая │

│аналоговая │организациями и│существует. Для│телефонного │Кбд │ │ │

│связь │между удаленными│передачи данных│соединения │ │ │ │

│ │офисами. │необходимы затраты на│ │ │ │ │

│ │Соединение с│модем │ │ │ │ │

│ │провайдерами │ │ │ │ │ │

│ │связи │ │ │ │ │ │

│Проводная │Сеть внутри│Средняя. Включает в│Минимальная. │Зависит от│Высокая │Средняя │

│цифровая связь│здания, на│себя стоимость│Обычно стоимость│типа │ │ │

│ │небольшие │проводов, сетевых плат│ремонта │устройств. │ │ │

│ │расстояния │и прочих компонентов│оборудования │Наиболее │ │ │

│ │ │сети, а также│ │распростра- │ │ │

│ │ │прокладку проводов │ │нено │ │ │

│ │ │ │ │соединение │ │ │

│ │ │ │ │100 Мбд │ │ │

│Оптоволоконная│Соединение между│Высокая. Очень большая│Минимальная. │Зависит от│Высокая │Высокая │

│связь │двумя крупными│стоимость оптоволокна│Обычно стоимость│типа │ │ │

│ │офисами. Как│и активных устройств│ремонта │устройств. │ │ │

│ │правило, │сети, также необходимы│оборудования │Обычно │ │ │

│ │арендуется │затраты на прокладку│ │высокая │ │ │

│ │ │проводов │ │ │ │ │

│Радиосвязь │Мобильные │Средняя. Стоимость│Средняя │Зависит от│Средняя │Низкая │

│ │соединения или│устройств │ │типа │ │ │

│ │соединение в│ │ │устройств. │ │ │

│ │случае, если│ │ │Обычно до 10│ │ │

│ │невозможна │ │ │Мбд │ │ │

│ │прокладка кабеля│ │ │ │ │ │

│Спутниковая │Для удаленной│Очень высокая │Высокая │Средняя │Средняя │Высокая │

│связь │связи между│ │ │ │ │ │

│ │двумя офисами. В│ │ │ │ │ │

│ │собственности │ │ │ │ │ │

│ │организации │ │ │ │ │ │

│ │компоненты │ │ │ │ │ │

│ │такого │ │ │ │ │ │

│ │соединения │ │ │ │ │ │

│ │находятся крайне│ │ │ │ │ │

│ │редко │ │ │ │ │ │

└──────────────┴────────────────┴──────────────────────┴──────────────────┴────────────┴──────────┴────────┘

Типы информационных сетей

В настоящий момент не существует никаких ограничений на топологию сети для организации. Однако любая организация имеет некоторую стратегию, направленную на упорядочение систем связи. Для небольшого банка - один или несколько сегментов сети с модемным выходом во внешний мир. Для средних организаций к этому можно добавить соединения между удаленными офисами или соединения для обслуживания систем удаленного управления счетами "клиент-банк". Крупные организации имеют очень сложную архитектуру с большим количеством центров администрирования и собственными внешними каналами. Для лучшего понимания сетевой архитектуры ниже приводятся определения основных видов сети, сгруппированных по методу управления ими.

Локальная сеть - это сегмент сети, как правило, с единым центром администрирования и одним администратором. Все пользователи локальной сети зарегистрированы в общей базе, и их права определяются из единого центра. Обычно предельный размер локальной сети - около 300 пользователей. Обслуживать большее количество пользователей одному или двум администраторам невозможно, а увеличение количества администраторов для единого реестра соединений приведет к нарушению принципов безопасности. Кроме того, редко в одном здании находится большое количество сотрудников, работающих в сети. Создание локальной сети между удаленными офисами из-за технических требований может привести к неоправданным затратам.

Корпоративная сеть. Если организация имеет несколько офисов и большое количество пользователей компьютерных сетей, то создается корпоративная сеть. Корпоративная сеть - это объединение локальных сетей, для которых определены общие обязательные правила администрирования и которые принадлежат одной организации. Однако каждый локальный сегмент такой сети имеет собственного администратора. Размер корпоративной сети определяется границами организации.

Экстрасеть. Следующим этапом развития сети является создание экстрасети. В данную сеть кроме самой организации входят ее клиенты и партнеры по бизнесу. Для работы экстрасети определяются правила и стандарты взаимодействия между участниками. Однако внутренние правила администрирования для каждой организации устанавливаются самостоятел ьно.

Глобальные сети и Интернет. Глобальные сети обычно строятся путем объединения множества сетей, принадлежащих различным собственникам. При этом определяются основные протоколы и правила работы в сети, которые и образуют глобальную сеть как единое целое. Наиболее известной глобальной сетью является Интернет. Едиными в Интернете являются сетевой и транспортный протоколы TCP/IP, единое сетевое адресное пространство, а также принцип общедоступности.

В рамках кредитной организации глобальные сети используются в качестве связующего звена между отдельными сегментами корпоративных сетей для общей информационной поддержки бизнеса и маркетинговых целей.

Сетевое оборудование

Без специализированного сетевого оборудования можно создать лишь простейшее соединение между двумя компьютерами через различные компьютерные порты. Такое решение можно использовать только в очень ограниченном числе случаев, например при автоматизации удаленного кассового узла или обменного пункта. Для решения более сложных задач необходимо специализированное сетевое оборудование.

Ниже рассмотрены специализированные сетевые устройства, обычно применяемые в организациях для создания сети.

Сетевые карты, или сетевые адаптеры (Network Interface Card) - устройства, соединяющие компьютер с сетью. Как правило, выполняются в виде отдельной платы, вставляемой в компьютер. Каждый сетевой адаптер имеет уникальный идентификатор, определяющий в сети физический адрес компьютера.

Повторители и усилители (Repeater and Amplifier) - устройства, помогающие преодолеть затухание сигнала в длинных сегментах. Повторители являются цифровым прибором, просто дублирующим с усиленным сигналом входящий информационный поток, и применяются в компьютерных (цифровых) сетях. Усилитель является аналоговым устройством, увеличивающим амплитуду сигнала. Применяется в аналоговых телефонных сетях.

Концентраторы (Hub) - сетевое устройство для соединения сетевых сегментов. Концентраторы бывают трех видов: пассивные, активные и интеллектуальные.

Пассивные концентраторы просто осуществляют физическое соединение, никак не изменяя сигнал.

Активные концентраторы усиливают проходящий через них сигнал, выполняя функции повторителей и усилителей.

Интеллектуальные концентраторы содержат дополнительные компоненты, позволяющие управлять информационными потоками.

Мосты (Bridge) - устройства, используемые для соединения сетевых сегментов. Выполняют функции повторителя, а также фильтра, отсекая передачу сетевых пакетов с адресами, не принадлежащими данному сегменту.

Маршрутизаторы (Router) - интеллектуальные устройства, управляющие информационным потоком на основании сетевых адресов. Могут быть как специализированными устройствами, так и реализованными на базе компьютера.