Задачи и внедрение Бизнес-стратегия Стратегия в области ит основные тенденции развития ит
СОДЕРЖАНИЕ: Информационные технологии в банке www.lekcii.at.ua Содержание Предисловие Введение Часть 1. Организация и развитие ИТ-менеджмента Организация управления ИТИнформационные технологии в банке www.lekcii.at.ua
Содержание
Часть 1. Организация и развитие ИТ-менеджмента
Тесное взаимодействие с бизнесом
Основные тенденции развития ИТ
Составление стратегического плана
Управление экономическими аспектами ИТ в банках
Организация процесса выбора системы
Часть 2. Операционное управление информационными технологиями
Особенности управления ИТ-персоналом
Элементы системы управления персоналом
Принципы поддержки пользователей
База данных запросов и автоматизация
Всеобщее управление качеством (TQM)
Жизненный цикл программного обеспечения
Специализированный стандарт TickIT
Особенности управления качеством ИТ-услуг
Взаимодействие с внешними поставщиками
Резервное копирование и архивирование
Внесение оперативных изменений в систему
Обеспечение актуальной справочной информации
Утрата работоспособности или производительности
Организация информационной безопасности
Влияние систем защиты на развитие бизнеса
Регулирование аудита информационных систем
Технология аудита информационных систем
Часть 3. Управление проектами в области ИТ
Общий подход: теория и практика
Определение объектов изменений и их размораживание
Документирование текущей технологии
Критерии оптимизации и ограничивающие условия
Анализ текущей технологии работы
Выработка, согласование и документирование новой технологии
Контроль эффективности осуществленных преобразований
Корректировка и закрепление изменений
Оценка эффективности разработки
Анализ рисков при реализации проектов
Типы рисков в информационном проекте
Определение идеального решения
Применение информационного фонда
Переносимость найденного решения на другие задачи
Часть 4. Практические решения и инструментарий
Автоматизированные банковские системы (АБС)
Инструментарий бизнес-моделирования
Приложение 1. Схема организации ИТ по CoblT
Приложение 2. Анализ функций ИТ: результаты диагностики
Приложение 3. Пример матричной оргструктура ИТ-департамента
Приложение 4. Образцы тендерной документации
Приложение 5. Соглашение о взаимодействии пользователей и специалистов ИТ (SLA)
Приложение 6. Перечень эксплуатируемых систем и программ
Приложение 7. Пример экзаменационных вопросов для ИТ-аудиторов
Приложение 8. Пример бизнес-схем в стандарте IDEF0
Предисловие
Книга А.В. Тютюнника и А.С. Шевелева посвящена теоретическим и практическим вопросам управления информационными системами (ИС), которые становятся все более актуальными. Актуальность книги настоящего издания обусловлена двумя обстоятельствами.
Во-первых, управление информационными системами - информационный менеджмент (ИМ) как самостоятельное направление практической деятельности, исследований и образования - в России возникло относительно недавно, хотя по сути информационный менеджмент является важной сферой деятельности для любой фирмы. Информационная система представляет собой модель системы управления, через которую проходит формализованная (структурированная) и частично формализованная (слабо структурированная) информация. Адекватность этой модели улучшается с развитием информационных технологий (ИТ) и совершенствованием парадигмы построения и управления ИС. Адекватность ИС в значительной мере определяет ее эффективность как инструмента управления. Таким образом, фирма - производитель ИС заинтересована не только в разработке (управление разработкой ИС - технологический менеджмент), но и в реализации ИС на рынке, а после покупки ее фирмой-потребителем - внедрении ИС на объекте (проектный менеджмент ИС). За последние несколько лет на тему информационного менеджмента был выпущен не слишком обширный ряд работ таких авторов, как В.В. Годин, А.В. Костров, В.В. Баранов и Д.С. и Н.С. Аглицкие.
Во-вторых, проблемы информационного менеджмента в настоящей работе рассмотрены не изолированно, а в тесной увязке с вопросами автоматизации банковской деятельности, то есть с проблемами предметной области. Следует отметить, что на рынке автоматизированных банковских систем (АБС) конкуренция сегодня в меньшей мере связана с различиями их функциональных возможностей, но в большей - с качеством обслуживания клиента фирмой-производителем на таких этапах жизненного цикла системы, как внедрение и эксплуатация ИС.
Фирма-потребитель (в данном случае - КБ) заинтересована в быстром и бесконфликтном внедрении ИС. Мнение неспециалистов о том, что инсталляция и есть внедрение, верно только для так называемых коробочных решений. На самом деле инсталляция лишь начинает внедрение ИС, которое проходит в большинстве случаев весьма болезненно. Это связано с тем, что новая технология еще полноценно не заработала, а старая (предметная) технология подвергается проверке при внедрении новой и обнаруживает в ней ошибки. Такая ситуация может повлечь за собой противостояние разработчиков АБС и сотрудников КБ. Кроме того, сотрудники банка вынуждены довольно долгое время вести обе технологии одновременно: старую (поскольку они в ней уверены и к ней привыкли) и новую (поскольку на нее придется, так или иначе, переходить). Еще одна неприятность, которая является следствием внедрения ИТ - изменение функциональных обязанностей лиц, принимающих решения (ЛПР) в системе управления. Изменение их функциональных обязанностей ведет к необходимости обучения персонала ИТ и изменения организационной структуры управления объектом. Следствием этого являются либо появление иных или дополнительных обязанностей у ЛПР (оптимистический вариант), либо увольнение ненужных сотрудников (пессимистический вариант).
Принимая решение о приобретении ИС, руководство банка должно сделать выбор: адаптировать ли ИС под существующую организацию бизнес-процессов и организационную структуру, спланировать их изменение и поддержать эти изменения внедрением ИС или просто адаптировать под требования ИС свою ОСУ.
Сохранившийся до сих пор подход к автоматизации деятельности КБ, выражающийся в требовании поддержать инструментально существующую систему управления, не просто безнадежно устарел, а является методологически неверным. Исходя из такой формулировки, любая автоматизация - уже успех. При этом руководство банка зачастую даже не задается вопросами: как изменятся бизнес-процессы, обеспечивающие оказание услуг или управления, как изменится организационная структура управления, не говоря уже о том, чтобы задуманная руководством организационно-технологическая перестройка рассматривалась как основной процесс, а информационные технологии - как инструмент поддержки этого процесса. Книга А.В. Тютюнника и А.С. Шевелева чрезвычайно точно и своевременно расставляет акценты в вопросах банковской автоматизации, перенося центр тяжести с описания имеющихся банковских ИТ на описание процессов управления ими.
Авторы ставят своей целью помочь банковским практикам в организации управления ИС в соответствии с лучшими международными стандартами на всех этапах их жизненного цикла - планирования, анализа, приобретения, внедрения и обслуживания в период эксплуатации ИС.
Книга будет полезна и ИТ-менеджерам фирм-производителей программного обеспечения, и ИТ-менеджерам коммерческих банков (потребителей), руководителям коммерческих банков, а также руководителям банковских подразделений, менеджерам и специалистам, которые так или иначе участвуют в приобретении, разработке, внедрении и эксплуатации информационных технологий как со стороны коммерческих банков (фирм-потребителей), так и фирм-консультантов, которые стали устойчивыми участниками во взаимодействии разработчиков и потребителей.
Доктор экономических наук, профессор, заведующий кафедрой
информационного менеджмента и электронной коммерции
Московского государственного университета
экономики, статистики и информатики (МЭСИ)
В.В. Дик
Авторы считают своим долгом выразить благодарность всем тем, кто оказал помощь при подготовке этой книги и содействовал нашему профессиональному росту, в том числе Джереми Фостеру, Хорхе Ивашкевичу, Стивену Тиммонсу, Джону Йанни, Роменскому Артему Александровичу, Парфенову Дмитрию Александровичу, Глазкову Александру Валерьевичу, Овсию Валерию Ивановичу.
За содействие в сборе информации по поставщикам банковских информационных систем авторы приносят благодарность Королеву Денису Михайловичу.
Авторы также выражают благодарность руководству и специалистам компаний PricewaterhouseCooper, Temenos, Диасофт, банка HSBC, коллективу преподавателей Московского государственного университета экономики, статистики и информатики (МЭСИ) и персонально профессору Дику Владимиру Владимировичу.
Введение
Сегодня повсеместное использование информационных технологий (ИТ) стало объективной необходимостью. Спектр областей, в которых применяются информационные технологии, чрезвычайно широк. Одной из сфер, где их значение было традиционно велико с момента начала их бурного развития, является финансовая сфера. Несмотря на то что еще каких-нибудь десять-пятнадцать лет назад кредитные организации использовали ручные методы обработки информации, сейчас практически обязательными атрибутами любого банка стали компьютеры, электронные терминалы, средства связи и коммуникации и т.д.
Можно с уверенностью утверждать, что процесс информатизации банковской деятельности продолжится. Основными тенденциями станут повышение качества и надежности предлагаемых продуктов и услуг, увеличение скорости осуществления расчетных операций, организация электронного доступа клиентов к банковским продуктам. Эти факторы связаны прежде всего со стремлением банков к достижению конкурентных преимуществ на финансовых рынках. Вследствие применения банковских информационных технологий стали возможны качественное расширение рынка продуктов и услуг, охват большей доли рынка посредством использования банкоматов, электронных расчетных систем, интернет-технологий, оперативный доступ клиентов к информации. Все это и в дальнейшем будет способствовать активному внедрению в банковскую практику самых последних достижений в области вычислительной техники, сетевых и информационных технологий, методов защиты информации и обработки данных.
В настоящее время расходы на ИТ-решения как никогда высоки. По статистическим данным, на закупку и внедрение ИТ-решений российские банки выделяют не менее 5% годовой сметы расходов. Но суммы затрат во многом зависят от того, какие именно информационные проекты ведет банк, какую рыночную нишу он занимает и какие новые услуги собирается внедрять. В частности, ИТ-бюджеты банков, ведущих агрессивную политику на рынке, могут достигать 35% от общих затрат. Например, Пробизнесбанк на время внедрения CRM-системы увеличил долю затрат на ИТ с обычных 7-10 до 15%. Банк МЕНАТЕП СПб 30% своего ИТ-бюджета в 2000 году (25-30% от общей сметы расходов) потратил на интернет-проекты, причем треть этой суммы - на системы информационной безопасности (по данным агентства Росбизнесконсалтинг). Все это приводит к резкому росту значения ИТ-области, которая становится одной из самых затратных и одновременно высокорискованных областей в банковской деятельности.
Системы управления деятельностью кредитных и финансовых организаций сегодня представляют собой самостоятельное направление в сфере информационного бизнеса. Информационные системы для кредитных организаций прошли достаточно долгий путь развития, и в настоящее время они позволяют автоматизировать любые банковские бизнес-процессы: управление ликвидностью, кадрами, банковскими рисками и т.д. Рынок программных продуктов для кредитных организаций представлен широким спектром систем, различающихся как в функциональной части, так и в технической реализации. Сегодня практически обязательными требованиями к любой банковской информационной системе стали возможность сетевой работы многих пользователей, реализация всего комплекса банковских операций по расчетно-кассовому обслуживанию, кредитно-депозитной деятельности, валютным операциям, гибкая настройка прав доступа конечных пользователей, поддержка нескольких аппаратных платформ, автоматизированное формирование большинства отчетных форм и возможность их гибкой перенастройки и т.д. Этим требованиям в настоящее время удовлетворяют большинство систем, представленных на рынке программных продуктов для финансовых организаций. Несмотря на их кажущуюся схожесть, они могут принципиально различаться как с точки зрения технической реализации, так и уровнем предоставляемого сервиса.
Помимо программного обеспечения банковские информационные технологии включают еще целый комплекс вопросов, касающихся информационного, аппаратно-технического обеспечения банковских операций и телекоммуникаций.
Информационные технологии предоставляют возможность ведения учета всего спектра операций, осуществляемых банком, с приемлемой степенью скорости и надежности, получение всей бухгалтерской и финансовой отчетности. Они должны уметь автоматизировать реальный банковский документооборот, то есть быть построены не от проводок, а от операций. Информационные технологии поддерживают управленческий учет и стратегическое планирование. Они предоставляют широкие возможности для контроля и анализа управленческой и учетной информации. Информационные системы обеспечивают обмен данными с программными продуктами и инструментальными средствами для финансового и статистического анализа.
За последнее время значительно возросло значение новых банковских услуг, предоставляемых клиентам посредством интернет-технологий. Учитывая повсеместное использование банками систем электронной связи и постепенный переход к безбумажной технологии обмена информацией, можно судить о важности этого направления для банков. Данная проблема также актуальна для филиальных банков, работающих в режиме онлайн с филиалами. Многие разработчики информационных систем включают средства защиты информации в собственные программные продукты. Помимо этого существуют различные средства независимых разработчиков, осуществляющие защиту передаваемой информации от несанкционированного просмотра и изменения при передаче.
Отдельную и важную роль банковские информационные технологии играют в процессах реинжиниринга и совершенствования работы кредитных организаций, организационно-технологической перестройки работы банка. Несмотря на универсальность большинства российских банков с точки зрения спектра операций, практически невозможно найти два банка, похожих друг на друга организационной структурой, технологией предоставления клиентам услуг, структурой документооборота и т.д. Хотя экономический смысл банковских операций в любом случае остается неизменным, каждый коммерческий банк работает по собственной сложившейся технологии. Она может быть не всегда оптимальной, характеризоваться неоправданно высокими затратами, но тем не менее эта технология является исторически сложившейся для данного банка и при отсутствии каких-либо внешних или внутренних побуждающих факторов продолжает использоваться.
Лишь в течение ограниченного промежутка времени существующая технология отвечает текущим потребностям банка, позволяет вносить изменения, носящие скорее косметический характер и не затрагивающие организационной структуры, сути бизнес-процессов. Наступает момент, когда любая технология теряет свою актуальность в изменившихся рыночных условиях и становится сдерживающим фактором на пути дальнейшего развития бизнеса. С другой стороны, очевидно, что залогом успешного развития любого бизнеса являются его гибкость, способность к адаптации в соответствии с изменяющейся внешней средой.
Переход банка на качественно иной уровень развития неизбежно требует внедрения в банковскую практику новых технологий, новых подходов и методов работы. Эти процессы часто сопровождаются пересмотром организационной структуры, изменением спектра предлагаемых банковских продуктов и услуг, реинжинирингом бизнес-процессов (который состоит в фундаментальном переосмыслении и радикальном перепланировании бизнес-процессов компаний и имеет целью существенное (но не обязательно единовременное) улучшение показателей их деятельности: резкое сокращение затрат, рост качества, сервиса и скорости обслуживания клиентов), внедрением новых информационных технологий. Кардинальные изменения в технологии работы кредитной организации, появление новых продуктов и услуг приводят к тому, что система автоматизации и управления деятельностью банка, которая использовалась ранее, перестает отвечать новым изменившимся требованиям с точки зрения банковской технологии.
Распространенная ошибка - ставить во главу угла процесса организационно-технологической перестройки банка информационную систему, ее функциональные возможности. После выбора новой системы банком предпринимаются попытки адаптировать под нее собственную технологию работы, что в принципе неверно. Такое решение только усугубляет негативную ситуацию, фактически закрепляя недостатки банковской технологии посредством их переноса в банковскую информационную систему.
Из вышесказанного следует очевидный вывод: организационно-технологическая перестройка банка должна рассматриваться как первичный процесс, определяющий изменения в информационных технологиях. Результатом данного процесса будет внедрение новой или адаптация старой информационной системы банка. Таким образом, реинжиниринг кредитных организаций и внедрение новых банковских и информационных технологий являются тесно взаимосвязанными процессами.
Информационные системы управления (или MIS - Management Information System) приобрели в последнее время огромную значимость, так как являются наиболее эффективным инструментом банковского управления, и постепенно российские финансовые организации начинают их использовать.
В то же время сфера информационных технологий с каждым годом все более усложняется. ИТ поглощают огромные финансовые и временные ресурсы, при этом не всегда предоставляя адекватный эффект.
Одной из самых распространенных причин такой негативной ситуации являются ошибки в менеджменте.
Каковы же наиболее типичные ошибки, свойственные российским организациям в области управления ИТ?
Одной из самых распространенных является недостаток внимания со стороны высшего руководства к задачам автоматизации, принижение их значения. Многие руководители никак не могут осознать, что ИТ оказывают принципиальное влияние на эффективность бизнеса и на его жизнедеятельность. Для того чтобы осознать значение ИТ, руководителю достаточно ответить на вопрос: что будет с его бизнесом при выходе из строя основного серверного оборудования или при разглашении принципиальной клиентской информации?
Другой распространенной ошибкой является недостаток финансирования. Практика показывает, что средние относительные затраты (в процентном отношении от доходов) на ИТ в российских компаниях существенно ниже, чем в аналогичных зарубежных компаниях. И особенно в части затрат на ИТ-специалистов, которые, как правило, являясь специалистами в своей области, прекрасно ориентируются и в предметной области. Как следствие этого, высокая текучка кадров, нагрузка на сотрудников и совмещение различных обязанностей, например разработчик зачастую ответственен и за тестирование своих же систем, что в конечном счете резко повышает риски.
И наконец, недостаток навыков в области управления ИТ, что выражается в попытке ИТ-специалистов решать все вопросы по своему усмотрению, спонтанно. Многие организации не используют проектные методы управления, международные стандарты в области управления ИТ или системной безопасности (например, СОВIТи BS7799), не уделяют внимания управлению качеством эксплуатируемых систем, организации обслуживания пользователей, не осуществляют внутренний аудит информационных систем, не документируют свои процессы. Все это в конечном итоге приводит к неконтролируемости процессов, срыву сроков и выходу за пределы бюджета.
В условиях того, что современные технологии постоянно меняются и усложняются и знания специалистов могут принципиально устаревать всего за 3-4 года, важнейшим моментом являются обучение и сертификация ИТ-специалистов, чему традиционно уделяется недостаточно внимания.
В современных экономических условиях основная миссия ИТ-менеджера финансовой организации состоит в обеспечении технологической базы сбалансированного развития и содействии бизнес-структурам в достижении конкурентного преимущества за счет повышения качества обслуживания клиентов и оптимизации внутренних бизнес-процессов. Другими словами, одними из принципиальных направлений деятельности ИТ-менеджера помимо общей организации работы ИТ-подразделения становятся взаимодействие с бизнес-подразделениями, совместная проработка стратегии и тактики развития, оценка экономических аспектов ИТ.
Данная книга посвящена проблемам управления банковскими информационными технологиями. Хотелось бы отметить, что эти вопросы имеют огромную значимость и уже давно не являются техническими, а требуют пристального внимания высшего руководства и всех служб финансовых организаций. Информационные технологии - это не обслуживающий, второстепенный участок, как было некоторое время назад, они участвуют в работе всех подразделений и напрямую определяют возможности организации по развитию бизнеса и совершенствованию внутренних процессов и системы обслуживания клиентов.
Исходя из сказанного выше, организовано и построение книги. Мы постарались избегать изложения устоявшихся подходов, отдавая предпочтение новейшим тенденциям и международной практике. Имея существенный опыт международной работы в области ИТ, авторы не ограничились констатацией западных Best Practices (лучших практик), а попытались адаптировать действительно лучшее, что есть в международном опыте, к использованию в России.
В книге достаточно широко рассмотрены основные ошибки, свойственные российским кредитным организациям. Данное издание является в большей степени практическим, поэтому структура и рубрикация книги позволяют использовать ее в качестве справочного материала по тому или иному направлению ИТ-менеджмента в банках.
Книга адресована в первую очередь менеджерам по информационным технологиям, высшему руководству банков, специалистам по банковским и информационным технологиям, внутреннему контролю и аудиту, а также может быть использована в качестве учебного пособия.
Первая часть посвящена непосредственным задачам ИТ-менеджера. При этом рассмотрены такие элементы, как общая организация управления (включая структуру, методологию, использование стандартов, ресурсы, взаимодействие с бизнесом), стратегия ИТ (от новейших тенденций развития стратегического видения до составления стратегического плана), управление экономическими аспектами ИТ (бюджетирование, анализ инвестиций, распределение и оценка издержек) и выбор решений как ключевой элемент развития ИТ (от анализа целесообразности и организации процесса выбора ИТ-решений до заключения контрактов и вовлечения сторонних консультантов).
Во второй части рассказывается о ежедневном операционном управлении информационными технологиями, где основной функцией ИТ-менеджера являются их правильная организация и контроль. Рассмотрены и традиционные составляющие этой работы - обслуживание пользователей, управление персоналом, информационная безопасность и такие новые направления, как аутсорсинг, аудит ИТ, управление качеством.
Третья часть посвящена управлению проектами (Project Management) - важнейшей составляющей современного ИТ-менеджмента и основной форме проведения большинства работ в области ИТ. Рассмотрены все основные моменты организации проектной работы, такие элементы ИТ-проектов, как планирование, организация взаимодействия, управление изменениями, разработка, тестирование и внедрение решений.
В четвертой части дан обзор практических решений в области банковской автоматизации, включая технические, телекоммуникационные и программные решения, инструментарий.
Завершается книга большим количеством приложений , которые иллюстрируют решения, освещенные в книге, содержат примеры реальных документов, схемы и ссылки на информационные ресурсы.
Надеемся, что данная работа окажет реальную помощь многим банкам, осознающим стратегическую значимость информационных технологий в современном мире и необходимость их постоянного совершенствования и развития для эффективного функционирования организации в целом.
Часть 1. Организация и развитие ИТ-менеджмента
Организация управления ИТ
Большинство организаций понимают, какую выгоду может принести использование современных информационных технологий и как они кардинально изменяют бизнес, выводя его на принципиально другой уровень. Но как в любом сложном деле, так и в информационных технологиях многое зависит от организации процесса управления. При этом, учитывая, что ИТ является специфической и стремительно меняющейся областью, здесь требуются и специфические подходы, которые можно структурировать по нескольким направлениям. Во-первых, для управления ИТ не всегда подходят методики традиционного менеджмента и зачастую требуется их адаптация. Во-вторых, ИТ-менеджер помимо того, что должен быть хорошим руководителем, должен быть до определенной степени техническим специалистом (технократом) и по крайней мере отлично разбираться в новейших подходах и тенденциях развития ИТ. В-третьих, ИТ-менеджмент уже сформировался как наука и поэтому имеет свои методики и наработки, не используя которые, можно столкнуться с серьезными проблемами. Но прежде чем мы рассмотрим эти специфические подходы, необходимо определиться с самим понятием. Итак, что же такое ИТ-менеджмент?
ИТ-менеджмент (в западной практике чаще употребляется термин IT Governance) - это система управления и контроля организационных взаимоотношений и процессов, направленная на достижение стратегических целей организации посредством использования информационных технологий и минимизации риска их применения.
Это определение близко к официальному определению Института управления ИТ (IT Governance Institute) и Ассоциации контроля и аудита информационных систем (ISACA), адаптированные материалы которых мы будем активно использовать и далее.
Таким образом, основная задача ИТ-менеджмента - это достижение стратегических целей посредством ИТ. Другими словами, ИТ-развитие не может быть самоцелью и бессмысленно без тесной связи с развитием бизнеса. При этом такие функции ИТ, как контроль и риск-менеджмент, являются важнейшими составляющими этого процесса, так как классический баланс между рискованностью и отдачей крайне актуален не только в финансах, но и в информационных технологиях.
Другой важной задачей ИТ-менеджмента является достижение соответствия различным внешним и внутренним требованиям. Передовые организации должны стремиться соответствовать требованиям качества, международным и местным стандартам, требованиям контролирующих органов, законодательным актам, общепризнанным подходам и методологиям в области ИТ. Количество таких требований за последнее время существенно возросло. Многие из международных требований становятся актуальны и для России.
Рассмотрим основные составляющие процесса организации управления информационными технологиями.
Цели и задачи
Управление - это создание изменений для достижения цели. Менеджмент должен служить достижению цели, это постоянное движение. Нагляднее всего можно представить этот процесс как путь из точки А (текущее состояние) в точку Б (желаемое состояние - цель).
При этом, как и при простом передвижении, необходимо:
- иметь адекватное средство передвижения (для ИТ это ресурсы);
- понимать как управлять этим средством (мы называем это использованием проверенной методологии управления ИТ);
- понимать, во сколько обходится нам наше движение и оправдано ли оно (в случае с ИТ эту часть менеджмента называют экономикой ИТ);
- знать особенности движения и эксплуатации этого средства. Все эти моменты составляют основу ИТ-менеджмента и будут рассмотрены далее.
Однако первым и самым важным среди составляющих процесса управления ИТ является стремление к обозначенной бизнес-цели. Необходимо понимать, что любое движение, любая деятельность в области ИТ лишь тогда имеют смысл, когда они направлены на достижение поставленных бизнес-подразделениями целей. Этот момент особенно важен, так как для многих ИТ-менеджеров их собственная деятельность является самоцелью. Они стараются совершенствовать свои процессы до бесконечности, тратя существенные ресурсы и не особенно заботясь о том, как их деятельность связана со стратегией развития организации и конкретными бизнес-целями. Другими словами, у ИТ не может быть собственных целей, любая их цель должна быть требованием бизнеса, должна поддерживать развитие организации в утвержденном высшим менеджментом и владельцами (stakeholders) направлении.
При правильной организации процесса управления ИТ-менеджмент принимает непосредственное и активное участие в определении стратегии и целей организации, так как именно ИТ является важнейшим источником развития и инноваций в банковском деле и в то же время источником серьезных ограничений бизнес-инициатив по стоимости, времени и реализуемости. Мы рассмотрим подробнее вопросы, связанные со стратегией ИТ, в отдельной главе .
Ресурсы ИТ
Для достижения цели, воплощения стратегии необходимы ресурсы. Если мы условно сравнивали цели с конечной точкой путешествия, то ресурсы - это то, на чем мы передвигаемся, то есть средство достижения цели. Очевидно, что адекватное ресурсное обеспечение не только является ключевым фактором для достижения цели или результативности (effectiveness), но и для решения оптимизационной задачи или эффективности достигнутого решения (efficiency).
Для ресурсного обеспечения традиционны три основные болезни. Первая - недостаток ресурсов, который хоронит проекты после инвестирования 90% ресурсов, вложенные деньги не только не приносят желаемого эффекта, но и просто оказываются выброшенными на ветер.
Вторая болезнь - избыток ресурсов. Как ни странно, это тоже очень вредит управлению и развитию ИТ, так как снижает экономическую эффективность ИТ-решений, расслабляет менеджеров и специалистов и зачастую делает невозможным достижение цели. Так, например, ехать в соседнюю булочную на такси не просто дорого и неэффективно, если сравнить со стоимостью батона хлеба, но и дольше, чем идти пешком, не говоря о том, что вас туда вряд ли кто согласится везти.
Наиболее распространена третья болезнь, которая присуща подавляющему большинству российских организаций, - несбалансированность ресурсов. Пять системных администраторов не заменят надежного и производительного сервера, и наоборот - дорогие технические средства не заменят квалифицированный персонал.
Исходя из всего сказанного, становится очевидно, что управление ресурсами - важнейшая часть ИТ-менеджмента и одна из трех основных его задач (цели, ресурсы, методология).
Рассмотрим основные ресурсы, находящиеся в распоряжении ИТ-менеджера. Мы относим к специфическим ресурсам ИТ следующие элементы:
- людей (ИТ-персонал, сторонние специалисты и консультанты);
- информацию (в самом широком смысле);
- технологии (оборудование, системное ПО, СУБД, телекоммуникации);
- системы (прикладное ПО);
- инфраструктуру (все необходимое для деятельности ИТ - помещения и их оснащение, обеспечение).
Общим ресурсом, который активно используется в процессе управления ИТ, являются, разумеется, деньги. Поэтому к важнейшим аспектам управления ресурсами ИТ относится экономика ИТ, так как большинство ресурсов, естественно, с учетом специфики и ограничений, могут быть увеличены с помощью денег. Важно помнить, что единственный невосполнимый ресурс - время. Даже при наличии неограниченных материальных ресурсов некоторые задачи невозможно выполнить быстрее. Обеспечение деятельности по поддержке и развитию ИТ требует в настоящее время существенных ресурсов. И вопросы сбалансированности и управления экономическими аспектами ИТ как важнейшие вопросы управления ресурсами будут рассмотрены в отдельной главе.
Все перечисленные ресурсы важны для управления ИТ, но, разумеется, ключевым ресурсом, по нашему глубокому убеждению, являются люди. И это не просто слова и даже не только личный опыт. По данным международной статистики, до 80% неудач проектов в области ИТ связаны именно с проблемой кадров. Персонал как ключевой фактор управления и развития ИТ будет рассмотрен также в отдельной главе.
Важнейшим моментом в области ресурсного обеспечения ИТ является использование сторонних ресурсов, так называемый аутсорсинг. ИТ-менеджер должен понимать, что невозможно сосредоточить все необходимые ресурсы, опыт и практику непосредственно в своей структуре, поэтому, когда встает какая-либо задача, необходимо определить, какой вид ресурсов (soursing) для данной задачи является более эффективным: внутренний (insoursing) или сторонний (outsoursing). В зарубежной практике в последнее время использование аутсорсинга, то есть сторонних ресурсов, все более расширяется и для многих видов задач считается более предпочтительным. Так, например, многие банки используют информационные системы, разработанные сторонними организациями, вместо того чтобы пытаться все разработки вести своими силами. Такие же тенденции наблюдаются и по другим направлениям ИТ. Но с аутсорсингом связаны и новые специфические риски, управление которыми является частью оперативной деятельности ИТ-служб. Они будут рассмотрены в соответствующем разделе .
Методология
Для правильной организации управления информационными технологиями сегодня недостаточно просто опыта и знаний менеджера, так как технологии и подходы постоянно меняются. Также крупные организации не могут полагаться только на знания одного человека: его ошибка может слишком дорого обойтись. С другой стороны, ИТ-менеджеру подчас бывает тяжело объяснить руководству какой-либо момент, поскольку оно воспринимает это объяснение как личную позицию ИТ-менеджера и не находит нужным считаться с ней. Все это приводит к тому, что, даже если ИТ-менеджер действительно понимает, как должны функционировать ИТ-процессы, реализация этого понимания на практике затруднена по ряду причин.
В международной практике для решения этой проблемы считается необходимым использовать в процессе организации управления ИТ какую-либо методологию управления ИТ. Подобные методологии содержат: структуру организации управления, основные цели и задачи, функциональные блоки и подходы к организации работы по ним, описание правильных подходов и практические примеры, количественные метрики и показатели (KPI - Key Performance Indicators, KGI - Key Goal Indicators, CSF - Critical Success Factors и т.д.) для оценки результатов, систему приоритетов в организации работы.
Возможны два источника таких методологий. Во-первых, существуют общепринятые методологии и стандарты, которые используются большим количеством организаций и поэтому являются проверенными. Во-вторых, это может быть собственная внутренняя методология, разработанная в крупной организации. Обычно самостоятельной разработкой занимаются только очень крупные организации, преимущественно международные, так как для этого требуются весьма объемная научная и исследовательская работа и ресурсы.
Преимущества широко используемых методологий:
* структурированный подход к управлению ИТ;
* проверенные подходы и решения;
* примеры лучших международных практик организации и управления ИТ;
* гарантия достижения результата;
* существенный авторитет внутри организации;
* соответствие де юре и де факте международным нормативным актам и стандартам;
* положительный маркетинговый и рыночный эффект.
К наиболее известным методологиям и стандартам в области ИТ можно отнести:
СоblТ - управление, контроль и аудит всех аспектов информационных технологий (в основном используется в американской практике);
ITIL, ITSM - управление обслуживанием информационных систем (широко используется в европейских странах);
ISO 9000 - управление качеством ИТ и программных продуктов;
BS7799 - организация информационной безопасности;
TickIT - управление качеством ИТ и программных продуктов;
ГОСТы - государственные нормативно-технические документы, устанавливающие определенные нормы, правила.
Рассмотрим две наиболее распространенные методологии управления ИТ - СоblТ и ITIL.
СоblТ (Controls Objective for Information and related Technologies) - методология управления, контроля и аудита информационных систем. Разработана Международной ассоциацией аудита и контроля за информационными системами (ISACA), которая имеет представительства в 57 странах мира, в том числе в России, и включает более 22 000 членов при участии крупнейших международных консалтинговых компаний и научных организаций. СоblТ является базовой методологией для управления ИТ в таких организациях, как: SWIFT, Cedel Group, министерство обороны США, Daimler Chrysler, Royal Philips Electronics, SABI, Colgate-Palmolive.
Отличительные черты СоblТ:
- основан на общепринятых правилах и принципах управления информацией и информационными технологиями;
- позволяет не только правильно провести аудит ИС, но и организовать управление и контроль над ними;
- охватывает все циклы операций в области ИТ - от планирования до поддержки и контроля;
- содержит примеры лучших практик организации ИТ и управления рисками;
- ориентирован на менеджмент организации и решение задач бизнеса;
- является инструментом совершенствования корпоративного управления бизнес-реинжиниринга.
Международная методология СblТ - разработан с учетом требований и рекомендаций многих других стандартов в этой области, включая: технические стандарты (ISO, EDIFACT и т.п.); нормы корпоративного управления, установленные европейской комиссией (ЕС) (OECD, ISACA); стандарты качества информационных технологий и процессов (ITSEC, TCSEC, ISO 9000, SPICE, TickIT, Common Criteria); профессиональные стандарты внутреннего контроля и аудита (COSO report, IFAC, llА, AICPA, GАО, PCIE, ISACA standards); индустриальные стандарты и международные практики построения ИТ (ESF, 14, IBAG, NIST, DTI, ITIL).
Согласно методологии СоblТ направления ИТ-менеджмента подразделяются на 4 основные области, которые в свою очередь делятся на 34 ИТ-процесса:
1. Планирование и организация:
ПО 1. Разработка стратегического плана.
ПО 2. Построение информационной архитектуры.
ПО 3. Построение технологической модели.
ПО 4. Определение структуры и организации ИТ.
ПО 5. Управление инвестициями в ИТ.
ПО 6. Согласование целей бизнеса и ИТ.
ПО 7. Управление людскими ресурсами.
ПО 8. Соответствие внешним требованиям.
ПО 9. Оценка рисков.
ПО 10. Управление проектами.
ПО 11. Управление качеством.
2. Приобретение и внедрение:
ПВ 1. Выбор решения.
ПВ 2. Приобретение/разработка приложений.
ПВ 3. Приобретение системных ресурсов.
ПВ 4. Поддержка технологической документации.
ПВ 5. Установка и настройка приложений.
ПВ 6. Управление изменениями.
3. Сопровождение и поддержка:
СП 1. Обслуживание пользователей.
СП 2. Управление услугами третьих лиц.
СП 3. Управление производительностью и мощностью.
СП 4. Обеспечение непрерывности деятельности.
СП 5. Обеспечение информационной безопасности.
СП 6. Классификация и распределение издержек.
СП 7. Обучение пользователей.
СП 8. Помощь и консультирование пользователей.
СП 9. Управление конфигурацией.
СП 10. Управление проблемами и сбоями.
СП 11. Управление информацией.
СП 12. Управление инфраструктурой.
СП 13. Управление операциями.
4. Мониторинг:
М 1. Мониторинг процессов.
М 2. Внутренний контроль.
М 3. Независимая экспертная оценка.
М 4. Внешний аудит.
По каждой из перечисленных областей методология содержит детальное описание организации управления, рекомендации по оценке и совершенствованию внутреннего контроля за ИТ*(1) .
Другая, не менее широко развитая и используемая многими ведущими организациями, методология - это ITIL (IT Infrastructure Library) - набор всесторонних документов по управлению обслуживанием и сопровождением информационных систем.
ITIL является эталонной моделью для сравнения текущей практики управления ИТ-сервисами организации с лучшей мировой практикой. Эта методология включает библиотеку из более чем 40 книг, разработанных ССТА (Центральное телекоммуникационное агентство, Великобритания). Каждая книга в ITIL охватывает определенный процесс управления ИТ-сервисами и описывает его отношения с другими процессами.
ССТА разрабатывает методологии мирового уровня для управления информационными технологиями, включая методологию управления проектами PRINCE, методологию SSADM для системного анализа и проектирования и библиотеку ITIL.
ITIL обеспечивает профессионалов в области ИТ знаниями и ресурсами, которые должны использоваться для поддержания эффективной и рациональной инфраструктуры, при минимальных затратах полностью удовлетворяющей потребности клиентов.
ITIL предлагает систематический и профессиональный подход к управлению ИТ-сервисами.
Основные преимущества применения ITIL:
- предоставление клиенту более полного и качественного обслуживания;
- уменьшение стоимости сервисов (услуг);
- повышение взаимосвязи между персоналом ИТ-служб и клиентами;
- повышение производительности обслуживания и максимально полное использование накопленных знаний и опыта.
Концепция ITIL так же, как и СоblТ, базируется на лучшей практике и опыте ведущих экспертов, консультантов, инженеров и многими воспринимается на настоящий момент как наиболее полный стандарт де факте для организации управления обслуживанием ИС.
Многие организации во всем мире используют ITIL как эталонную модель для сравнения текущей практики управления ИТ-сервисами организации с лучшей мировой практикой.
Необходимо отметить, что внедрение подобных методологий является сложной задачей и не всегда может быть осуществлено без посторонней помощи. Это связано с тем, что в процессе внедрения необходимо оценить последовательность действий и сформулировать систему приоритетов. Также часто необходим практический опыт организации подобных процессов в других организациях.
Для больших кредитных организаций не менее важным помимо выбора и использования проверенных подходов является и централизация методологического управления в целом по организации, так как зачастую в головном офисе используются передовые подходы, а в ближайшем филиале ИТ-функции и процедуры управления существенно менее развиты.
Восемь ключевых подходов
При построении ИТ-менеджмента необходимо иметь в виду, что помимо трех основных задач верхнего уровня (достижение бизнес-целей, ресурсное обеспечение, включая управление экономическими аспектами ИТ и методологическое обеспечение ИТ-деятельности, которые мы рассмотрели в первом приближении выше) для правильной организации работы могут быть рекомендованы 8 ключевых подходов. Среди них: тесное взаимодействие с бизнесом, построение ИТ-подразделения по принципу обслуживающей (сервисной) организации, широкое использование проектной формы управления и матричной организационной структуры, активное использование в процессе управления оценки и контроля деятельности ИТ количественных показателей (метрик), высокая роль риск-менеджмента в ИТ-деятельности, постоянное совершенствование, оптимизация и обязательное документирование внутренних ИТ-процессов и работ и банковских технологий.
Рассмотрим эти моменты по отдельности. Каждый из перечисленных подходов является своеобразной аксиомой ИТ-менеджмента, поэтому мы не будем доказывать их необходимость, а сосредоточимся на описании самих подходов.
Тесное взаимодействие с бизнесом
Первичность бизнес-целей давно не вызывает практически ни у кого в ИТ-сфере противодействия. Но как организовать это тесное взаимодействие? Как сделать его не формальным, а действенным? Как научиться понимать проблемы бизнеса и в свою очередь заставить бизнес считаться с ограничениями в ИТ и участвовать в ИТ-решениях? Все это не простые вопросы.
С точки зрения международного опыта разрешить эти противоречия в первую очередь могут ИТ-комитет, профессионализм ИТ-директора (СЮ - Chief Information Officer) и активное вовлечение ИТ-менеджера в принятие бизнес-решений.
Комитет по информационным технологиям контролирует процесс автоматизации в банке с целью достижения высокого уровня эффективности, стандартизации и организации безопасной и бесперебойной операционной деятельности в соответствии со стратегическими задачами банка. Комитет по ИТ также отвечает за поддержание технологических стандартов в банке на высоком уровне.
ИТ-комитет должен быть реально действующим образованием, который на регулярной основе участвует в принятии ИТ-решений, выработке ИТ-стратегии, разрешении противоречий, определении приоритетов задач, согласовании финансирования, утверждении технологических решений. Комитет осуществляет координацию политики банка в области информационных технологий, рассматривает вопросы распределения ресурсов, планирования и внедрения принятых решений. Он также координирует деятельность, выполняемую различными группами, с тем, чтобы при принятии решений по информационным технологиям в первую очередь учитывались общие интересы банка.
ИТ-комитет должен собираться по мере необходимости, но, как правило, для средних по размеру организаций не реже одного раза в месяц, для крупных банков - на еженедельной основе. ИТ-комитет должен состоять из представителей (руководителей) основных бизнес-направлений, ИТ-директора, представителей высшего руководства, иногда в него могут входить даже представители крупных акционеров (владельцев), хотя это не является типовой практикой. Руководить им должен представитель бизнеса, символизируя этим первичность бизнес-целей. Таким образом, через представительство в ИТ-комитете трех основных групп - высшего руководства, ИТ-менеджмента, бизнес-менеджмента (пользователей) - достигаются прозрачность деятельности в области ИТ, сбалансированность ИТ-решений и их соответствие бизнес-целям.
Руководители основных подразделений банка должны быть обязательно включены в состав комитета по ИТ. Опыт показывает, что в банках, в которых не сформированы ИТ-комитеты, наблюдается расхождение мнений по вопросам информационных технологий между сотрудниками управления ИТ и пользователями программных продуктов. В большинстве случаев конфликты возникают по причине того, что как пользователи, так и сотрудники управления информационных технологий не осознают приоритеты, которые определены в деятельности другой стороны.
Немаловажную роль в построении продуктивных и дружественных отношений между бизнес-подразделениями и ИТ играет сам ИТ-директор. Статус СЮ в зарубежных финансовых компаниях крайне высок. Иногда он может быть выше статуса, например, финансового директора (CFO - Chief Finance Officer). Почти всегда СЮ имеет статус члена правления. Если он может говорить на равных с потребителями технологий, то это очень помогает в налаживании правильных отношений. Поэтому иногда для улучшения взаимодействия на должность ИТ-директора назначается человек из бизнес-сферы с ИТ-опытом. Вряд ли это является панацеей, но этот пример по крайней мере хорошо иллюстрирует, что СЮ должен быть одинаково близок и к ИТ, и к бизнесу, понимать язык обеих сторон и быть своеобразным переводчиком. Это, по мнению многих экспертов, на сегодняшний день и является основной задачей ИТ-директора.
Также, как уже отмечалось, важно вовлечение ИТ-менеджмента в бизнес-решения. Представители ИТ должны принимать участие в обсуждении и принятии ключевых решений относительно развития банковской деятельности, так как успешная реализация принимаемых решений во многом зависит от возможностей ИТ. Поэтому правильной практикой является участие ИТ-директора в заседаниях правления (или другого органа управления), основных комитетов как полноправного члена.
ИТ как сервисная организация
Следующий момент - это построение ИТ-подразделения по принципу обслуживающей (сервисной) организации. Другими словами, организация работы внутренней ИТ-службы не должна ничем отличаться от организации работы при обслуживании сторонних клиентов. Основная цель такого построения - поднять качество обслуживания до уровня сторонних провайдеров, использовать в работе ИТ-подразделения профессиональные, промышленные подходы, уделять больше внимания риск-менеджменту.
Для реализации этого подхода ИТ-подразделение составляет список своих доступных и потенциальных услуг, описывает их, определяет параметры услуг (скорость оказания, стоимость, гарантии обслуживания). Далее с каждой бизнес-единицей заключаются договора на обслуживание, так называемые SLA (Service Level Agreement) - соглашения об уровне обслуживания. Иногда они называются соглашениями о порядке взаимодействия и обслуживания. Процесс оформления SLA детально отражен в методологии ITIL. Примерная его форма приведена в приложениях .
Проектная форма управления
Большинство работ в области ИТ являются уникальными и неповторяющимися. Они выполняются специально выделенными работниками и по сути представляют собой проекты со своими целями, требуемыми сроками и согласованным финансированием. Управление такими группами также должно отличаться от традиционного. Здесь нет постоянно выполняемых и периодически возникающих задач, работа конечна во времени, и основным критерием является достижение цели проекта.
Для внедрения проектной формы управления необходимо разработать положение об основах проектной работы, которое должно:
- включать критерии выделения проектов (например, срок и стоимость работ, вовлеченность нескольких подразделений);
- определять организационный статус проекта, формирование целей и задач проекта, процедуры контроля за ходом проекта и достижением результатов, формирование и расходование бюджета, руководство проектом, двойную подчиненность сотрудников, сроки, основные типы проектов (проекты в области ИТ, внутренние проекты, общебанковские проекты и т.п.).
В соответствии с утвержденными проектными подходами и проектами в организации формируется перечень проектов в области ИТ, назначаются ответственные (или рабочие группы) за каждый проект и внедряются процедуры контроля за результатами.
Для эффективного функционирования проектной формы работы целесообразно разработать и внедрить систему, согласно которой рабочее время сотрудников ИТ будет учитываться с точки зрения осуществляемых видов работ и заказчиков этих работ, вовлеченности в проекты. Эти данные могут использоваться для распределения издержек ИТ-персонала по бизнес-подразделениям. Также проектная форма управления предполагает совершенно другую систему мотивации сотрудников, ориентированную на достижение конечного результата.
Матричная оргструктура
Для реализации проектных подходов в полной мере ИТ-подразделение должно быть построено на основе матричной организационной структуры. Матричная структура - наиболее сложный и, если ее так можно назвать, современный тип организационной структуры. Она представляет собой некое совмещение традиционных структур с проектными подходами. Подобное совмещение помогает объединить все положительное, что есть в традиционных структурах и системах управления, с новейшими тенденциями. Матричной структуре свойственно двойное подчинение: с одной стороны, исполнитель участвует в каком-то проекте, с другой - он является частью функционального подразделения. Система взаимоотношений и подчиненности в структурах этого типа очень сложна, но, как показывает практика, сами по себе эти структуры весьма эффективны именно в современных условиях.
Матричные структуры, сочетая в себе все преимущества функциональных и дивизиональных структур, лишены многих их недостатков. Они оптимально и быстро справляются со множеством постоянно возникающих задач, создавая для их решения отдельные проекты. Они идеально адаптируются к современной нестабильной внешней среде. Поэтому матричные организационные структуры заслуженно признаются оптимальными для кредитных организаций и особенно оправданы для организации ИТ.
Однако необходимо учитывать и присущие матричным структурам недостатки, а именно: излишнюю усложненность, возникающую из-за двойного подчинения, нечеткость в вопросах разграничения полномочий между функциональными или дивизионными и проектными руководителями.
Примеры матричных организационных структур банка и ИТ-подразделения приведены в приложениях .
Показатели деятельности
Для осуществления оценки и анализа существующих проблем в области ИТ необходимо иметь объективную информацию по основным аспектам деятельности (количественные метрики). Такие показатели помогают отслеживать и управлять результатами деятельности по ИТ-направлению.
В западной практике эти показатели часто называются KPI (Key Performance Indicators) - ключевые индикаторы выполнения. Примером KPI могут быть такие метрики, как процент проектов, не укладывающихся в сроки или бюджет; время разрешения проблемы у пользователя; средняя загрузка оборудования; рост ИТ-бюджета по сравнению с ростом операций; удовлетворенность пользователей работой ИТ-подразделения; доступность критичных ИТ-ресурсов (100% означает, что определенные ресурсы доступны все время - 24 часа х 7 дней в неделю); уровень квалификации ИТ-персонала; количество замечаний по результатам регулярных внутренних и внешних проверок ИТ; количество поддерживаемых пользователей на одного работника ИТ, количество проблем и консультаций отработанных службой обслуживания; количество инцидентов в области информационной безопасности; процент загруженности ИТ-работников (utilization) и т.д.
Важно понимать, что количество показателей может быть огромным, поэтому определение того, какие из них необходимо учитывать при оценке деятельности ИТ, а какие нет, является индивидуальной задачей. Но в любом случае, определив 15-20 метрик и регулярно собирая по ним необходимую информацию, можно иметь достаточно четкое представление о ходе деятельности ИТ и осуществлять адекватное управление и контроль со стороны высшего руководства и бизнес-подразделений, периодически предоставляя им эту информацию.
Риск-менеджмент
Важнейшая составляющая правильной организации управления ИТ - риск-менеджмент. ИТ является одной из самых высокорискованных областей деятельности и может быть сопоставима для кредитных организаций по уровню рискованности даже с финансовыми операциями. Постоянная оценка наихудшего сценария по всем направлениям, оценка вероятности его наступления и потенциального влияния - вот основы риск-менеджмента.
Далее должна следовать работа по смягчению возможных последствий, минимизации влияния и снижения вероятности наступления негативного события, независимо от его природы. Невозможно подготовиться ко всему, поэтому необходимо использовать взвешенный подход, направляя максимум усилий на потенциальные события с высокой вероятностью наступления и высоким влиянием и с низкой вероятностью и высоким влиянием. Такой подход в западной практике является основой риск-менеджмента и называется Probability Impact Analysis.
Основными направлениями риск-менеджмента являются:
- планирование непрерывности деятельности и действий в чрезвычайных ситуациях, так называемые ВСР и DRP (Business Continue and Disaster Recovery Planning);
- разделение ключевых ИТ-функций (необходимо, например, разделять функции разработки программного обеспечения, технического тестирования, тестирования функциональных возможностей и сопровождения эксплуатируемых систем);
- зависимость от ключевого ИТ-персонала (в последнее время одна из наиболее часто встречающихся проблем ИТ-менеджмента);
- информационная безопасность, инциденты, связанные с доступом и раскрытием конфиденциальной информации.
Для минимизации рисков внедряются так называемые контрольные процедуры (Control Procedures), направляемые на предотвращение (Preventive Controls), выявление (Detective Controls) и смягчение (Corrective Controls) негативной ситуации.
Документирование ИТ-процессов
Еще одна составляющая правильной организации управления ИТ - необходимость документирования ИТ-процессов и банковских технологий. Традиционно именно этот момент является менее развитым в российских организациях, что неминуемо приводит к резкому увеличению рисков, полной неразберихе и абсолютной непрозрачности ИТ-подразделения и автоматически ухудшает взаимоотношения с бизнес-сферой, затрудняет оценку деятельности, снижает качество обслуживания внутренних клиентов.
Для облегчения использования внутренних регламентирующих документов может быть рекомендовано применять утвержденную в рамках всей организации иерархию документов. В России пока нет устоявшихся подходов, а в международной практике часто используется иерархия внутренних документов по возрастанию степени их детализации: политика (Policy), процедура (Procedure), стандарт (Standard).
Основные примеры ИТ-документов, которые должны постоянно поддерживаться и вестись в организации:
* стратегия в области ИТ (IT Strategy);
* техническая политика (Technology Policy);
* информационная и технологическая архитектура (Information ArchiTecture);
* ИТ-бюджет (IT Budget);
* политика информационной безопасности (SecuriTy Policy);
* процедуры получения доступа к информационным ресурсам и стандарты информационной безопасности (SecuriTy Procedures and Standards);
* методология разработки программного обеспечения (System Development Life Cycle Methodology);
* соглашения о взаимодействии и обслуживании бизнес-подразделений (Service Level Agreement);
* порядок проведения тендеров по выбору ИТ-решений (Tender Execution Policy);
* протоколы ИТ-комитета (IT commlitee minutes);
* перечень регулярных операций и процессов (Batch Processes List);
* перечень проектов (Projects List);
* планы-графики работ по проектам и в целом по подразделению;
* программная документация (руководства пользователей, администраторов, технические спецификации);
* технические задания на разработку;
* журнал регистрации обращений пользователей;
* заявки на предоставления прав доступа, карты доступа;
* результаты приемки решений пользователями (Users Sign-off).
* должностные инструкции работников (Job Descriptions);
* перечень эксплуатируемого программного обеспечения и техники;
* описания банковских технологических процессов.
Совершенствование процессов
Последним ключевым подходом является необходимость постоянного совершенствования ИТ-процессов. Такое совершенствование включает два аспекта. Первый - оценка уровня зрелости, которая производится на основе сравнения с другими организациями и должна быть постоянной и неотъемлемой частью ИТ-менеджмента. В международной практике этот процесс называется Benchmarking. Второй - непосредственно оптимизация деятельности. Необходимо, чтобы работа по совершенствованию не приводила к развитию нескольких любимых участков деятельности в ущерб всем остальным, как часто бывает в российских банках. Поэтому очень важным становится использование какой-либо методологии управления ИТ, например СblТ, которая дает возможность оценить уровень развитости ИТ в конкретной организации, не прибегая к консалтинговой помощи и не надоедая коллегам из конкурирующих структур. И далее на основе оценки текущего состояния, начиная с менее развитых направлений, можно начинать работу по совершенствованию ИТ-процессов.
Рассмотрев основы построения ИТ-менеджмента в финансовых организациях в рамках первой части книги, далее мы остановимся подробнее на том моменте, который в данной главе назван первой задачей ИТ-менеджмента, - стремлении к достижению целей. Для ИТ-менеджера эту задачу поддерживает процесс стратегического планирования (или управления), который и является предметом следующей главы .
Стратегия ИТ
Стратегическое управление и планирование заключается в определении целей кредитной организации, превращении общих целей в конкретные направления работы, в анализе сильных и слабых сторон организации, составлении и контроле выполнения планов деятельности в различных ситуациях. Это управленческий процесс, обеспечивающий соответствие между целями банка и имеющимися у него ресурсами в условиях постоянно изменяющейся рыночной обстановки и регулирования. Цель стратегического планирования и управления - внедрение новых и развитие перспективных направлений деятельности и банковских продуктов так, чтобы они способствовали росту объема операций, приумножали доходы и увеличивали рыночную стоимость акций. Таким образом, стратегия зависит от тех целей, которые банк ставит перед собой, и способствует их скорейшему осуществлению.
Задачи и внедрение
Для грамотного и последовательного осуществления процесса стратегического менеджмента необходимо четко сформулировать основные задачи этого процесса.
Во-первых, система стратегического менеджмента решает задачу неуклонного приближения кредитной организации к тем целям, которые она ставит перед собой. Это дает положительную динамику развития и конкурентоспособности: ведь ресурсы и силы не распыляются на все сразу, а сосредоточиваются на принципиальных для достижения поставленной цели позициях.
Во-вторых, система стратегического менеджмента позволяет снизить риски влияния внешней среды, поскольку обеспечивает регламентацию действий в разного рода неожиданных ситуациях (нестабильность рынков, девальвация, резко возросшая конкуренция, снижение доходности, изменение принципиальных положений законодательства) и позволяет в случае их возникновения действовать по заранее составленному плану, незначительно корректируя его в соответствии со сложившимися обстоятельствами.
Таким образом, в задачи стратегического планирования входят как понимание цели деятельности того или иного банка, так и вариативность путей ее достижения. Однако решение этих двух принципиальных и очень актуальных задач осуществляется с помощью особых технологий и средств, которые предусматривает процесс внедрения стратегического планирования.
Процесс внедрения стратегического планирования целесообразно разделить на следующие шесть этапов.
1. Внедрение стратегического способа мышления в среду высших менеджеров банка.
На этом этапе необходимо обеспечить понимание каждым из высших руководителей необходимости и целей внедрения стратегического планирования, провести анализ мнений высшего руководства и владельцев о задачах и стратегических целях банка. На основе этих данных формулируется и фиксируется представление о роли и стратегии банка по основным направлениям деятельности.
2. Создание необходимых условий и системы оценки реализации стратегических целей и задач.
Внедрение стратегического подхода невозможно без ряда необходимых условий. К ним относятся:
- внедрение управления отдельными подразделениями как независимыми бизнес-единицами, деятельность которых регулируется и оценивается по рыночным принципам;
- введение финансового управления, позволяющего адекватно рассчитывать потенциальную рентабельность и оценивать различные аспекты деятельности стратегических бизнес-единиц;
- внедрение бюджетного планирования, являющегося средством контроля и обеспечения стратегического планирования.
Помимо выполнения перечисленных условий принципиальным является также создание и внедрение системы оценок деятельности банка, которая формируется с точки зрения соответствия локальным и глобальным стратегическим целям. Именно эта система и станет в будущем основой проведения самого процесса стратегического планирования и оценки его результатов.
3. Создание инфраструктуры стратегического менеджмента. Инфраструктура стратегического менеджмента предполагает наличие:
- руководителя высшего звена (желательно члена правления банка), ответственного за внедрение, контроль и оценку стратегического менеджмента;
- функционирующей системы ответственности работников и руководства различных подразделений;
- подразделения стратегического планирования (его численность зависит от размеров банка), в задачи которого должна входить регулярная работа по обеспечению стратегического планирования в банке (оформление и согласование стратегических планов, корректировка стратегий и целей, оценка и контроль выполнения планов, мониторинг и т.д.).
4. Формирование детального, многовариантного (в зависимости от внешней ситуации) стратегического плана и его составляющих - стратегических планов подразделений.
Осуществив все описанные выше действия по внедрению стратегического планирования, проводят так называемый SWOT-анализ, который необходим для:
- оценки возможного влияния внешней среды на положение организации в будущем;
- выявления сильных и слабых сторон организации, открывающихся перспектив и грозящих опасностей.
На основе детального анализа представлений и пожеланий руководства банка, а также данных SWOT-анализа создается развернутый стратегический план деятельности. Такой план должен быть многовариантным, то есть иметь разветвления в зависимости от дифференциации показателей внешней экономической среды.
5. Внедрение системы взаимно поддерживаемых целей банка, подразделения и работника.
Следующим важнейшим этапом на пути внедрения стратегического планирования является создание механизма взаимодействия целей банка, целей подразделения и целей отдельно взятых работников, поскольку большинство проблем в процессе развития возникает из-за несогласованности целей внутри кредитной организации, а именно:
- несогласованности личных целей руководителей и общих целей банка;
- несогласованности целей подразделения и целей банка в целом (как следствие внутренней конкуренции или неадекватного перераспределения ресурсов и фондов материального стимулирования);
- несоответствия реальных и заявленных целей и т.д.
Такие несоответствия и противоречия важно выявлять и предотвращать, потому что они приводят к разрыву между официально представляемым и реальным положением дел и в конечном счете к отсутствию какого-либо движения вперед.
Здесь становятся особенно важными тщательная работа с персоналом, продуманная и соответствующая стратегическим целям система мотивации деятельности сотрудников, подразделений и структурных единиц. Таким образом, личные цели отдельных работников, объединенных в подразделения, реализуясь, должны приводить к решению задач, поставленных перед подразделениями, а совокупность достижений подразделений в свою очередь должна способствовать достижению соответствующей стратегической цели банка.
Один из типичных способов решения этой проблемы в зарубежной практике - внедрение и поддержка облегчающей достижение поставленных целей определенной корпоративной культуры с сопутствующими ей разнообразными механизмами, в том числе и вытеснением не соответствующих ей работников и руководителей.
6. Внедрение системы мониторинга и прогнозирования внешней среды и корректировки стратегий.
Этот этап является последним по очереди, хотя и не последним по значению. Необходимо создать условия, при которых не только соответствующее подразделение, но и вся организация была бы вовлечена в мониторинг внешней среды. Ведь, скажем, предпочтения клиентов, их потребности, отношение к конкурентам гораздо проще выявлять работникам, непосредственно обслуживающим клиента, а не специально выделенным для этого специалистам. Последние должны заниматься анализом, обработкой и предоставлением всем заинтересованным службам внутренней информации, а также отслеживанием внешней информации. Исходя из поступающей информации соответствующим образом корректируются стратегические планы.
Бизнес-стратегия
Стратегия ИТ неотделима от бизнес-стратегии организации. Мы рассмотрели задачи и внедрение стратегического менеджмента, а теперь перейдем к основным тенденциям в экономике и стратегическом мышлении банка, которые достаточно активно меняются в настоящее время.
Итак, в чем же состоят требования новой экономики? В чем отличия новой модели бизнеса от старой и как эти новейшие тенденции влияют на банковский бизнес?
Тенденции, о которых будет рассказано ниже, практически являются аксиомами в западном мире. В российских условиях они выглядят несколько дискуссионно, хотя, безусловно, в ближайшее время они будут широко использоваться и у нас.
Первой такой тенденцией является ориентация на клиента, которая достигается за счет изучения потребностей разных групп клиентов и выработки специализации. Передовые организации стремятся изучать и структурировать потребности и спрос со стороны клиентов и в соответствии с клиентскими группами корректировать свои услуги (рис. 1 ).
Рис. 1. Сравнение традиционной и новой модели бизнеса
Выбираемая организациями специализация способствует более эффективной работе с индивидуальным клиентом и в конечном счете является залогом повышения рентабельности работы с каждым отдельным клиентом и соответственно всего бизнеса. Естестественно, что только с существен ной поддержкой ИТ возможна реализация этой стратегии на практике.
Также важен опыт взаимодействия клиента с банком. Этот опыт должен быть запоминающимся и, если так можно выразиться, уникальным. В современной экономике впечатления клиента становятся конечной целью. Они являются одной из главных причин выбора в пользу того или иного банка в условиях, когда стоимость услуг и набор их практически одинаковы. Рассмотрим ставший уже классическим пример, описанный Джозефом Пайном и Джеймсом Гилмором в книге Экономика впечатлений (рис. 2 ).
Рис. 2. Пример влияния впечатлений клиента на стоимость товара в новой модели бизнеса
Цена за одно и то же количество кофе может быть весьма разной: кофе как сырье примерно в два раза дешевле расфасованного и красиво упакованного и почти на порядок дешевле кофе как услуги (например, за чашечку кофе в кафе). Наконец, кофе как уникальное впечатление, предложенное в особенном месте и в особенной обстановке, в десятки раз дороже простых зерен, необходимых для приготовления напитка. Таким образом, самое выгодное в современной экономике - быть ближе к продаже услуг и впечатлений.
Это правило распространяется и на финансовые услуги. Банк стремится построить индивидуальную систему обслуживания клиентов, предвидеть запоминающиеся акции. Он старается, чтобы его образ отличался от других банков и клиент мог выделить данный банк среди других на разных уровнях общения.
Такой ориентированный на клиента подход требует централизации информации и процессов, разработки ориентированной на клиента корпоративной культуры и инфраструктуры, формирования у клиентов положительного опыта взаимодействия, который будет явно отличать данный банк от конкурентов, и последовательного обеспечения этого взаимодействия вне зависимости от используемых каналов.
Другой стратегической тенденцией развития банковского бизнеса является поиск новых каналов сбыта, реализации услуг. Для этого банки используют преимущества электронных решений, технические и технологические нововведения.
Ведущие компании мира все больше разворачиваются в сторону электронного бизнеса. Первые шаги в этом направлении были предприняты немногим более 7 лет тому назад, а сегодня электронный бизнес уверенно меняет облик отраслей. Все говорит о том, что электронный бизнес будет определять основные правила в сфере осуществления коммерческой деятельности уже в ближайшем будущем.
Электронный бизнес существенно влияет и на деятельность компаний, занятых в сфере услуг, особенно это относится к сектору финансовых услуг. Во многих банках большинство операций уже сегодня проводится электронным способом. Но, к сожалению, шаги по внедрению электронного бизнеса зачастую недостаточно продуманы и проработаны и, как следствие, не приводят к желаемым результатам.
В то же время следует отметить, что текущая экономическая ситуация несет и потенциальные угрозы финансовым организациям, а именно:
- дерегулирование открывает традиционно закрытые рынки для конкуренции;
- растущие потребности потребителей меняют привычные формы бизнеса;
- усложняются и расширяются операции;
- совершенствование технологии ускоряет требуемые темпы развития;
- информация меняет основы конкуренции;
- конкуренция оказывает давление на доходность;
- глобализация ведет ко все большей неопределенности.
Все эти моменты в конечном итоге требуют от финансовых организаций принятия активных мер. И именно е-бизнес позволяет найти решение не только многих отдельных проблем, но и проблемы снижения операционных издержек в целом.
Перенос бизнеса в Интернет приносит ранее недостижимое снижение внутренних издержек. В настоящее время стоимость банковской транзакции в Интернете в США составляет в среднем около 1 цента, в то время как себестоимость транзакции по пластиковым картам равна примерно 30 центам, а при традиционном банковском обслуживании - более одного доллара. Таким образом, электронный бизнес имеет потенциал снижения издержек на два порядка, поэтому банки просто не могут игнорировать его. Но, если банкам не хватает осведомленности, присутствуют недостатки при разработке стратегии и организации, проекты в этой области зачастую обречены на неудачу.
Что касается осведомленности, то банки стремятся понять, какими будут результаты развития электронного бизнеса, как этих результатов можно достичь и что нужно, чтобы дать существенный импульс развитию электронного бизнеса.
В части стратегии необходимо оценить критические факторы успеха для электронного бизнеса, установить стратегические приоритеты и составить план дальнейшего развития.
В части менеджмента необходимо осуществлять контроль проектов и управлять деятельностью в соответствии с измеримыми целями, обеспечивать требуемый уровень поддержки со стороны руководства организации и управлять рисками.
Таким образом, чтобы быть успешными, банкам необходимо помимо всего прочего учитывать новую стратегическую роль ИТ для бизнеса.
Стратегия в области ИТ
Итак, что же такое ИТ-стратегия и в чем она должна состоять?
ИТ-стратегия - это детальное описание планов организации в области информационных технологий, направленных на поддержку реализации бизнес-стратегии и достижение конкурентного преимущества наиболее оптимальным и действенным способом. Компании, ведущие стратегическое планирование в области ИТ, как правило (по данным статистики), достигают более высокого качества своих ИТ-услуг и более низкой их стоимости. Эти два критерия (качество и стоимость) можно назвать базовыми при оценке деятельности и развития ИТ.
Если рассматривать стратегическое планирование ИТ в целом, то это многосторонний процесс. Перечислим составляющие его блоки.
Организация - внутренняя структура, взаимодействие с другими подразделениями, распределение полномочий.
Внутренние процессы - направления совершенствования, эффективность, качество и стабильность.
Архитектура - целевая техническая, программная, сетевая и телекоммуникационная архитектура организации, ее гибкость, соответствие последним требованиям.
Приложения - основные системы, поддерживающие бизнес-процессы. (Соответствует ли используемая система основным требованиям и стратегическим целям организации? Сможет ли она поддерживать требования в течение ближайших 5-10 лет?) Централизация и машта-бируемость приложений, поддержка увеличенного объема операций и возникающих новых продуктов, тенденции в программной индустрии.
Персонал - квалификация, обучение, документирование деятельности, мотивация, системы стимулирования, карьерный рост.
Стандарты - использование стандартов и методологий, сертификация подходов, решений, сотрудников, разработка внутренних методик и соответствие им.
Стратегическое партнерство - основные направления развития партнерских связей, поставщики, вендоры, области использования аутсорсинга.
Риски и контроль - процедуры контроля, внутренний и внешний аудит, мониторинг со стороны менеджмента, контрольные отчеты и показатели деятельности, управление рисками.
Сравнительный анализ - сопоставление с аналогичными организациями, использование статистических данных, исследование тенденций.
Планы - ключевые планы в области развития ИТ по различным направлениям (в том числе и перечисленным выше) на ближайшие несколько лет. Список проектов и приоритетов по ним.
Финансы - бюджет, анализ и совершенствование экономических показателей деятельности ИТ, окупаемость инвестиций, распределение финансирования по основным проектам.
По каждому из этих направлений рассматриваются текущая ситуация, цели, стратегия, тактические подходы для достижения продекларированных результатов.
Рассмотрев основные направления стратегического планирования ИТ, остановимся на типовых (или наиболее распространенных) идеях, лежащих в основе ИТ-стратегий. Такой ИТ-стратегией для всех является создание технологической платформы для управления взаимоотношениями с клиентами (CRM - Customer Relashinships Management), необходимость которой вытекает из сказанного выше о бизнес-стратегии в современных экономических условиях.
В общем случае такие системы поддерживают инфраструктуру, которая позволяет собирать данные обо всех клиентах, анализировать информацию о потребителях услуг, группировать клиентов на основе особенностей их поведения и индивидуальных предпочтений, разрабатывать продукты и услуги для отдельных потребителей или для групп людей, схожих по своим интересам и предпочтениям, и в конечном счете предлагать индивидуализированное обслуживание. На рис. 3 представлена общая схема подобных решений, которая демонстрирует их сложность.
Другой достаточно прогрессивной и распространенной ИТ-стратегией является построение ИТ по принципам сервисной организации. Эта стратегия направлена на совершенствование внутренних организационных процессов и взаимодействия с бизнес-подразделениями.
Основная идея состоит в том, что если внутренняя служба ИТ будет использовать в своей работе подходы внешних компаний, то это позволит существенно поднять качество ее работы и снизить издержки. Такая стратегия предполагает:
- маркетинг и продажу технологических решений. Сервисно ориентированная ИТ-структура способна продавать свои решения и услуги сторонним организациям;
- внутренний маркетинг - необходимость строить отношения с подразделениями по законам маркетинга, фактически продавая свои подходы коллегам по организации;
- умение идентифицировать технологические проекты в организации и выступать с инициативами по их разработке и обоснованию, прогнозировать востребованность своих услуг (сервисов);
- необходимость отслеживать тенденции в индустрии и технологии, учитывая в своей работе поддержание ее конкурентоспособности и возможного замещения внешней компанией;
- соответствие стандартам качества и требованиям заказчика;
- формализацию и обязательное документирование при осуществлении работ;
- наличие квалифицированного персонала, способного переквалифицироваться, освоить работу в новой области и заменить другого сотрудника;
Рис. 3. Построение системы CRM
- умение оценивать и планировать ресурсы, необходимые для выполнения работы и точного определения сроков и этапности проектов;
- управление персоналом должно быть построено с учетом специфики работы в ИТ-индустрии;
- умение работать с партнерами, которые могут предоставить помощь в тех областях, где имеется недостаток ресурсов или навыков, или в случаях, когда работа партнера более эффективна с экономической или временной точки зрения.
Рисунок 4 дает возможность сравнить подходы к организации ИТ-службы - традиционной и построенной по принципам сервисной или обслуживающей организации.
Безусловно, процесс выработки стратегии является сугубо индивидуальным, однако ИТ-стратегии (по крайней мере передовых банков) могут иметь много схожих подходов, так как учитывают передовой опыт и базируются на общих тенденциях развития ИТ.
Рис. 4. Сравнение подходов к организации ИТ-службы
Основные тенденции развития ИТ
Приведем несколько схем (рис. 5-10 ), которые иллюстрируют основные тенденции в развитии менеджмента информационных технологий на основе специализированного международного источника Forrester Research. Inc. Эти схемы выбраны нами в случайном порядке, а ценны тем, что реально существуют. Поэтому рекомендуется учитывать их при формировании собственной ИТ-стратегии.
Первой тенденцией, которую хотелось бы отметить, является повышение значения экономических параметров при принятии решений по выбору проектов. Представленная на рис. 5 схема показывает, что в 80% случаев формальным обоснованием начала технологического проекта являются параметры возврата инвестиций или срок окупаемости проекта.
Рис. 5. Тенденции в подходах к обоснованию проектов
Другие тенденции касаются изменения роли ИТ-подразделения. Представленные на рис. 6 данные иллюстрируют, что большинство респондентов отмечают возрастание сотрудничества с бизнес-подразделениями. Также отмечаются такие изменения, как усиление централизации и контроля, направленности на результаты бизнеса и внедрение новых технологий и решений. Только около 10% респондентов отмечают отсутствие каких-либо изменений.
Следующий график (рис. 7 ) иллюстрирует все более активное вовлечение высшего руководства организаций в процесс принятия ИТ-решений. Как считают 40% респондентов, требуют обязательного обоснования и согласования с высшим руководством любые проекты в области ИТ. А необходимость такого согласования для проектов стоимостью свыше $100 тыс. признают около 87% опрошенных.
Рис. 6. Изменение роли ИТ-подразделения
Рис. 7. Вовлечение высшего руководства в процесс принятия ИТ-решений
В последнее время наблюдается существенное повышение доли сторонних услуг, организации все чаще используют аутсорсинг. При этом они стремятся передавать сторонним организациям практически все неключевые для бизнеса функции (рис. 8 ). Сегодня в среднем 28% средств ИТ-бюджета достаются сторонним поставщикам решений и услуг. Около 40% опрошенных отмечают, что они передали (полностью или частично) другим поставщикам такие свои технологические функции, как разработка, поддержка и эксплуатация приложений.
Рис. 8. Использование сторонних услуг (аутсорсинг)
Следующая схема (рис. 9 ) показывает тенденции в изменении структуры ИТ-службы и базовых показателей оценки ее деятельности. Среди основных тенденций отмечаются: увеличение централизации, стремление больше соответствовать требованиям бизнеса, увеличение количества используемых стандартов для целей контроля ИТ. В большинстве банков обработка данных осуществляется централизованно с целью снижения затрат и повышения эффективности процессов. Кроме того, существуют и другие преимущества в пользу принятия такого решения: легкость управления, контроля, организации информационной безопасности, подготовки управленческой отчетности; отсутствие дублирования информации; уменьшение затрат на обслуживание оборудования; сокращение персонала; стандартизация и единообразие системных и бухгалтерских процедур.
Рис. 9. Тенденции в изменении структуры и оценки ИТ-подразделений
С точки зрения оценки деятельности использование тактических показателей отмечается большинством как наиболее часто встречающийся подход, около трети компаний отмечают показатели эффективности бизнеса и снижения издержек.
Еще одной показательной тенденцией в управлении информационными технологиями является увеличение скорости принятия решений при покупке ИТ-решений: подавляющее большинство всех решений в этой области принимаются менее чем за три месяца (рис. 10 ).
Рис. 10. Скорость принятия ИТ-решений
Составление стратегического плана
Как оформить ИТ-стратегию в виде документа? Как этот документ должен выглядеть? На какой период он должен составляться? Какие требования предъявляются к стратегическому плану? Далее мы попытаемся ответить на эти вопросы.
Как видно из сказанного выше, ИТ-стратегия не может быть составлена без понимания бизнес-стратегии и должна на ней базироваться. Стратегический план целесообразно составлять в виде двух документов - долгосрочной стратегии и краткосрочной. Долгосрочная стратегия составляется на 3-5 лет и включает соответствующие задачи и цели, краткосрочная - на срок от 1 до 3 лет.
Оба документа должны регулярно обновляться. Для долгосрочного документа это может происходить на полугодовой основе, для краткосрочного - на ежеквартальной. Все обновления производятся в тесном взаимодействии с бизнес-менеджерами и согласовываются с высшим руководством организации.
Стратегия в области ИТ утверждается высшим руководством по результатам совместного обсуждения с руководителями ИТ- и бизнес-подразделений. Иногда это обсуждение проходит в форме заседаний информационно-технологического (или технического) комитета.
Также важнейшим элементом стратегического планирования является контроль исполнения. Стратегия не должна быть декларативным документом, и основным способом достижения этого является контроль ее исполнения со стороны высшего руководства банка (информационно-технологического комитета).
Управление экономическими аспектами ИТ в банках
Буквально за несколько последних лет информационные технологии (ИТ) стали не только важной частью бизнеса, но и очень затратной его частью. Сегодня в некоторых банках расходы на ИТ составляют существенную часть бюджета, иногда доходя до 30%, и могут являться наиболее крупной статьей издержек, обгоняя административно-хозяйственные расходы, расходы на аппарат управления и другие традиционно крупные статьи в банках. Но как относиться к этим затратам? Каковы реальные издержки на автоматизацию? Как сделать так, чтобы огромные затраты приносили реальную отдачу, поддающуюся измерению и отражению в управленческой отчетности? То есть как управлять экономическими аспектами ИТ?
Ответы на эти вопросы принципиальны не только для финансовых директоров и ИТ-менеджеров, но и для высшего руководства любого банка. Очевидно, что необходим особый подход к интеграции ИТ-издержек в общую модель финансового управления банка.
Что такое экономика ИТ
Рассмотрим один из важнейших блоков управления информационными технологиями, который называется экономика ИТ (IT Economy). Экономика ИТ направлена на обеспечение функционирования экономических механизмов регулирования ИТ-процессами. Ее основные задачи - оптимизация издержек и помощь высшему руководству в принятии решений в области развития ИТ.
К основным экономическим механизмам регулирования ИТ в банке (элементам системы управления экономическими аспектами деятельности ИТ) можно отнести следующие:
* управление инвестициями в ИТ (Manage the IT Investment);
* бюджетное планирование (Budgeting);
* распределение издержек по подразделениям (Costs Allocation);
* сравнительный анализ издержек (Costs Benchmarking);
* структурный анализ издержек (Cost Structured Analysis);
* трендовый анализ издержек (Cost Trend Analysis);
* управление ценностью информационных технологий (Technology Value Management).
Далее мы детально рассмотрим эти составляющие, но прежде необходимо сформулировать, что в конечном счете может дать банку грамотная система управления экономикой ИТ. Другими словами: зачем все это нужно? По нашему мнению, основные плюсы заключаются в возможности:
- оптимизировать затраты;
- повысить эффективность и контролируемость;
- достичь прозрачности;
- улучшить взаимодействия с бизнес-подразделениями;
- обеспечить сбалансированное развитие и, в конечном счете, достичь конкурентных преимуществ.
Управление инвестициями в ИТ
По своей сути расходы на ИТ являются инвестициями, и если организация не понимает этого, то она может столкнуться как с финансовыми, так и с ИТ-проблемами. Управление инвестициями в ИТ состоит в приравнивании ИТ-проектов к прочим инвестиционным проектам организации. Расходы на ИТ должны рассматриваться как внутренние инвестиции с обязательной подготовкой необходимых документов, расчетов и обоснований. Как и для других инвестиций, для ИТ-проектов необходимо определение срока окупаемости, жизненного цикла решения (программы, оборудования). Ни один проект не должен начинаться без соответствующих финансовых расчетов и обоснований.
В противном случае неадекватная инвестиционная политика может привести к бюджетному дефициту (например, недостатку средств для завершения проекта), риску конфликта инвестиций, а также к неэффективному использованию ресурсов. В случае отсутствия предварительного планирования в области инвестиций в ИТ возникает риск того, что высшее руководство недооценит их значимость для деятельности и примет управленческие решения, не владея реальной информацией об объеме инвестиций в ИТ.
Практическими шагами в направлении развития управления инвестициями в ИТ могут быть следующие:
* определение ответственных за этот процесс сотрудников и руководителя;
* разработка и внедрение методики расчета окупаемости ИТ-инвестиций с финансовой и нефинансовой точек зрения;
* внедрение системы показателей в области ИТ и алгоритм их расчета (ТСО (Total Cost of Ownership) - общая стоимость владения, РВ (Payback Period) - период самоокупаемости, NPV (Net Present Value) - чистая приведенная стоимость, IRR (Internal Rate of Return) - внутренняя норма рентабельности, ROI (Return on Investment) - доход на инвестицию и т.д.;
* обязательная оценка возможных альтернативных вариантов инвестиций в ИТ;
* периодический анализ передового опыта отрасли при выборе инвестиций в области ИТ;
* постоянный процесс совершенствования инвестиционной политики в области ИТ.
К тому же при осуществлении инвестиционной политики можно рекомендовать проанализировать следующие показатели:
доля ИТ-проектов (в общем числе), не укладывающихся в бюджет;
доля ИТ-проектов, для которых не производилась предварительная оценка эффективности инвестиций;
доля ИТ-проектов, которые после внедрения не достигли требуемых инвестиционных показателей (нормы рентабельности и времени самоокупаемости);
число ИТ-проектов, при осуществлении которых возникли инвестиционные конфликты, несмотря на наличие утвержденного бюджета (недостаток или несвоевременность инвестиций);
время между возникновением финансового отклонения в осуществлении проекта и решением этой проблемы руководством;
доля ИТ-проектов, которые после внедрения так и не достигли требуемых инвестиционных целей.
Бюджетное планирование
Бюджетное планирование или бюджетирование - это процесс формирования и контроля исполнения детализированного бюджета расходов по отдельным областям деятельности. Эффективный процесс бюджетирования предполагает этапы планирования, оценки выполнения плана и контроль за расходами. Отсутствие эффективного бюджетирования может привести к тому, что планирование ИТ не будет соответствовать стратегическим планам предприятия. Также это приведет к отсутствию критериев оценки результатов деятельности ИТ и контроля за расходами ИТ. Процесс бюджетировния ИТ помогает достигнуть соответствия ИТ и бизнес-задач.
Бюджеты составляются, как правило, на год, квартал и помесячно. Для каждого срока существуют два типа бюджетов. Первый - это прогнозируемый, или плановый, бюджет, являющийся основным финансовым ориентиром при осуществлении оперативного управления. Второй - это реальный бюджет, который строится уже по результатам деятельности после завершения определенного временного периода.
Плановые бюджеты могут строиться по следующей схеме. На основании годового бюджета разрабатываются более детальные квартальные, на основании которых формируются помесячные бюджеты, являющиеся еще более детализированными. Для средних банков можно рекомендовать формировать ежегодный бюджет и его поквартальное распределение. В крупных организациях это может быть затруднено, поэтому там вполне приемлемо использование годовых бюджетов.
Реальные бюджеты формируются в обратном порядке. Задача управления в этой ситуации - максимально сблизить оба типа бюджетов.
Необходимым требованием к структуре бюджетов является их постатейная детализация. Это может быть индивидуально разработанная в целях бюджетного планирования система признаков поступлений и расходов, или, как их еще называют, статей. Часто для бюджетного планирования используют статьи управленческого учета. Система признаков должна быть наглядна и понятна, поэтому она не должна строиться с применением стандартных признаков бухгалтерского учета. Количество признаков строго ограничено, так как излишняя детализация усложняет понимание и мешает наглядному оформлению бюджетов.
Деление на конкретные статьи расходов и поступлений зависит от выбранной модели и утвержденных принципов бюджетирования ИТ. В качестве примера рассмотрим некоторые статьи расходов верхнего уровня, определяющиеся следующими признаками:
* помещения:
- аренда;
- мебель, стойки;
- обслуживание;
* компьютерное оборудование:
- персональные компьютеры;
- серверное оборудование;
- периферия;
* телекоммуникации:
- локальная сеть;
- Интернет;
- телефония;
* программное обеспечение:
- системное;
- прикладное;
* персонал:
- зарплата;
- обучение и сертификация сотрудников;
- социальный пакет;
* внешние услуги:
- консалтинговые;
- технические;
* административные издержки.
Названные статьи в зависимости от потребностей и особенностей конкретного банка могут расширяться по количеству основных признаков и по степени детализации каждого из них.
С точки зрения бюджетирования важной составляющей этого процесса должны являться процедуры консолидации бюджетов, механизмы разрешения бюджетных конфликтов, внесения изменений в бюджеты, контроль исполнения бюджета, что недостаточно развито в большинстве банков.
Также важной составляющей процесса бюджетирования является система мотивации сокращения издержек. В бюджете следует определить статьи, которые подлежат потенциальной экономии, и статьи с фиксированной суммой. При недорасходе средств по первому типу статей должен включаться механизм стимулирования (% от сэкономленных ресурсов). Бюджетирование позволяет существенно повысить контролируемость расходования средств, что также помогает снизить затраты.
Неоспоримым достоинством бюджетного планирования как такового является то, что в процессе оперативной деятельности отдельных подразделений и банка в целом оно является автоматическим механизмом контроля над финансовыми потоками, регулирует их и стимулирует активную деятельность по оптимизации затрат и увеличению доходов. Этот механизм действует независимо от мнений отдельных руководителей или исполнителей, а иногда и вопреки им. Он может функционировать сам по себе, даже когда за ним нет постоянного жесткого и строгого контроля, достаточно, например, просто наличия серьезных наказаний за нарушение бюджетной дисциплины.
Распределение издержек
Еще одним важным экономическим механизмом регулирования ИТ-процессов является распределение издержек, связанных с ИТ по бизнес-подразделениям. Все издержки ИТ, которые являются обслуживающей структурой, должны распределяться по бизнес-подразделениям, включая:
- оборудование;
- программное обеспечение;
- телекоммуникации;
- зарплату ИТ-специалистов;
- административные издержки и прочие расходы.
Правда, необходимо сразу оговориться, что эта мера имеет смысл только в том случае, если в банке вообще ведется финансовая модель управления, использующая распределение издержек между функциональными подразделениями и оценки их деятельности с учетом такого распределения.
Этот механизм позволяет существенно повысить контролируемость расходов со стороны бизнес-подразделений, так как, если ИТ-расходы будут уменьшать их финансовый результат, они волей-неволей будут вовлечены в принятие решений по инвестициям и будут контролировать их адекватность и эффективность.
Одной из главных проблем при организации распределения ИТ-издержек между остальными подразделениями является расчет стоимости услуг ИТ.
Разработка оптимальной модели расчета стоимости услуг ИТ осложняется тем, что требуется весьма существенная их настройка и обкатка в процессе реальной работы, для того чтобы результаты такого распределения учитывали специфику работы и использования ИТ в различных бизнес-процессах. Так, например, если пойти по простейшей модели и распределять затраты пропорционально количеству персональных компьютеров, то может возникнуть ситуация, когда ИТ-затраты двух подразделений примерно равны, так как равно количество компьютеров, однако объем операций и доходы отличаются во много раз, что будет искажать реальный финансовый результат работы подразделений и в конечном счете подорвет доверие ко всей системе бюджетирования в банке.
Поэтому необходимо, чтобы модель распределения затрат учитывала не только количество компьютеров, но и многие другие факторы. Такими факторами могут быть: объем операций, используемые приложения, частота обращений в службу поддержки, объем использования дискового пространства и т.п. Издержки по задачам, связанным с деятельностью одного подразделения, не должны распределяться по другим подразделениям.
На практике наиболее редко встречается распределение издержек, связанных с ИТ-персоналом. По непонятным причинам российскими банками это воспринимается как весьма сложная процедура. Тем не менее без распределения таких издержек по бизнес-подразделениям вся система распределения становится неполной и неэффективной, так как затраты на ИТ-персонал являются одной из крупнейших статей ИТ-расходов и к тому же не очень прозрачной. Но как организовать такой процесс?
Существует простой способ, повсеместно используемый в западной практике. Каждой работе и каждому подразделению присваивается цифровой код (Charge Code). Любой работник ИТ, работая над какой-либо задачей, в своем персональном отчете о проделанной работе и использованном времени (Time Sheet) должен проставлять код работы и затраченное время. Такие отчеты (Time Sheet) готовятся периодически - как правило, еженедельно. Используя простейшую автоматизацию, можно добиться того, что они будут обрабатываться автоматически и на их основе будут производиться финансовые расчеты с подразделениями или сторонними организациями, в случае если ИТ-служба оказывает какие-либо услуги сторонним организациям. Также этот механизм может быть очень полезным для контроля загрузки ИТ-специалистов.
Стоит отметить, что существует и другой подход. Он состоит в том, что ИТ-служба получает статус бизнес-подразделения, которое продает свои услуги (сервисы) другим, исходя из своих затрат и определенной нормы рентабельности. Другими словами, ИТ из центра затрат становится центром прибыли. При такой схеме организации бюджетного планирования происходит попытка смоделировать рыночные отношения посредством взаимодействия бюджетных единиц и финансовых расчетов между ними. По нашему мнению, этот подход тоже эффективен для регулирования ИТ и по сути мало чем отличается от описанного выше, так как также переносит издержки ИТ на бизнес-подразделения и повышает их вовлеченность в принятие ИТ-решений - именно они определяют, покупать или не покупать.
Анализ расходов
Важным в управлении финансовыми аспектами деятельности ИТ является анализ расходов, к основным составляющим которого относятся:
- сравнительный анализ издержек (Costs Benchmarking) - сравнение ИТ-издержек и агрегированных показателей с другими организациями;
- структурный анализ издержек (Cost Structured Analysis) - анализ и контроль за соотношением между основными блоками расходов;
- трендовый анализ издержек (Cost Trend Analysis) - изменение расходов во времени и в сравнении с ростом общих доходов или объема операций компании.
Анализ может делаться на основе внутренних данных, которые должны накапливаться внутри организации, а также на основе общепризнанных международных источников*(2) . Данные информационные ресурсы содержат огромное количество статистической и аналитической информации по затратам на информационные технологии, персонал. Они включают специализированные тематические обзоры экспертов. Все это позволяет сравнить практически любой аспект деятельности ИТ с организациями данного сектора экономики и приблизительно такого же размера, прогнозировать затраты и быть готовым к изменяющимся условиям и экономическим тенденциям в области ИТ. Например, в рамках сравнительного анализа могут рассматриваться показатели, приведенные в табл. 1-3 .
Таблица 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) - интеллектуальные устройства, управляющие информационным потоком на основании сетевых адресов. Могут быть как специализированными устройствами, так и реализованными на базе компьютера.
Шлюз (Gateway) - интеллектуальное устройство, реализованное, как правило, на базе компьютера со специальным программным обеспечением. Основной задачей шлюза является совместимость при использовании несовместимых протоколов при передаче информации.
Рис. 24. Схема работы шлюза в информационной сети
Уровни сетевых протоколов
Сеть никогда не начнет функционировать, если все ее компоненты не будут работать по единым правилам. Развитие сетевых технологий привело к тому, что в 1984 году была разработана единая спецификация OSI Reference Model, которая объединила в единое целое большинство протоколов и стандартов. Она основывается на многоуровневом подходе, разделяя правила взаимодействия компонентов сети на каждом из них. Всего в модели OSI определено семь уровней.
Физический уровень (Physical Layer) - отвечает за типы сигналов, передаваемых по сети, и описывает механизм преобразования информации в сигналы. Как правило, реализуется в драйверах сетевых адаптеров.
Канальный уровень (Data Link Layer) - отвечает за передачу пакетов данных на физическом уровне и механизм их перемещения посети. Более подробно данный уровень определен спецификацией IEEE 802, которая детализирует канальный уровень на подуровень управления логической связью (Logical Link Control) и подуровень управления доступом к устройствам (Media Access Control).
Сетевой уровень (Network Layer) - отвечает за преобразование логических сетевых адресов в физические эквиваленты. Протоколы этого уровня также определяют правила переключения пакетов, маршрутизации данных и разрешения конфликтных ситуаций при прохождении информации по сети. Наиболее распространенными сетевыми протоколами на сегодняшний день являются:
IP - протокол, используемый в Интернете;
IPX - сетевой протокол компании Novell;
NetBEUI - сетевой протокол компании Microsoft.
Данный уровень может совмещать в рамках одного решения несколько протоколов одновременно. Обычно это делается для объединения уже имеющихся решений.
Транспортный протокол (Transport Layer) - управляет потоками данных между компонентами сети. На этом уровне происходит разбиение данных на фрагменты, которые затем передаются по носителю. Одновременно происходит контроль целостности данных путем проверки контрольных сумм. Наиболее распространенными транспортными протоколами на сегодняшний день являются:
TCP - протокол, используемый в Интернете;
SPX - транспортный протокол компании Novell;
NetBIOS - транспортный протокол компании Microsoft.
Как и на сетевом уровне, транспортные протоколы могут существовать одновременно в рамках общего решения.
Сеансовый уровень (Session Layer) - отвечает за поддержку сеанса при взаимодействии двух сетевых устройств. На этом уровне также осуществляются идентификация и автоматический разрыв в случае отсутствия активности в соединении.
Уровень представления (Presentation Layer) - отвечает за преобразование данных, поступающих из приложения в форматы передачи. Этот уровень осуществляет кодирование, компрессию данных, а также преобразование графических файлов и управление запросами на использование сетевых устройств.
Уровень приложения (Application Layer) - является верхним уровнем сетевой модели OSI. Определяется множеством протоколов, используемых различными сетевыми приложениями для решения их задач. Примерами протоколов, работающих на уровне приложения, являются:
FTP - протокол передачи файлов;
SMTP - протокол передачи почты;
SNMP - протокол управления сетью.
Модель OSI, безусловно, является абстрактной моделью. Это значит, что можно рассматривать сетевые технологии и вне ее. Так, например, фактически не используются раздельно основные сетевые и транспортные протоколы. TCP/IP для Интернета или SPX/IPX для сетей NOWELL используются только вместе, определяя весь перечень правил взаимодействия для сети. Однако понимание сетевых уровней дает большую точность в определении ответственности за решения, используемые при разработке единого пространства.
Распределенные системы
Первая задача, которая должна быть решена при создании распределенной системы, - какие виды ресурсов будут распределены. В случае, если необходимо разделение вычислительных мощностей, рассматривается система распределенных вычислений или архитектура клиент-сервер. Если система обработки больших потоков данных и их хранения - анализируются механизмы кластера.
Клиент-сервер. Технология клиент-сервер базируется на принципе специализации составляющих информационной системы. При этом определяются два типа компонентов: сервер и рабочее место пользователя (Desktop).
Сервер - специализированное устройство или программное обеспечение, которое служит для решения общей задачи.
Рабочее место пользователя - компоненты информационной системы, которые служат для решения задач конкретного пользователя, например реализации пользовательского интерфейса системы.
Обычно и сервер, и рабочее место рассматриваются как выделенные полнофункциональные компьютеры. Однако в общем случае это неправильно. Например, рабочим местом пользователя карточки является банкомат, кассира - кассовый аппарат. Сервер печати может быть самостоятельным интеллектуальным устройством, а сервер архивации - состоять только из носителя информации и специализированной платы.
Рис. 25. Общая схема сети банка
Службы серверов
Сам термин сервер может трактоваться двояко - мощный выделенный компьютер или программное обеспечение, реализующее одну из служб. В данной главе сервером будет называться программа, которая обеспечивает независимое выполнение некоторой задачи. При этом задача может выполняться как на выделенном компьютере, так и на рабочей станции. Последнее решение часто используется разработчиками систем.
Выбирая архитектуру клиент-сервер, в первую очередь необходимо определить весь перечень задач, решения которых будут перенесены на серверы. Как правило, это задачи, требующие общего доступа или больших вычислительных мощностей. Ниже приведен список служб информационных систем, наиболее часто используемых как серверы.
Сервер домена определяет список пользователей сегмента сети, а также их права доступа. Осуществляет мониторинг соединений. Является ядром любой сетевой операционной системы, работающей по принципу клиент-сервер.
Файл-сервер служит для хранения информации в виде файлов для распределенного доступа к ним. Осуществляет контроль доступа к каждому из них. В качестве файл-сервера может служить любой компьютер, который разрешает использовать собственное дисковое пространство. Однако многие сетевые операционные системы предлагают большое количество дополнительных сервисов для управления файл-сервером.
Сервер базы данных служит для хранения, обработки и обеспечения доступа к структурированной информации. Сегодня наиболее часто для решений используются серверы реляционных баз данных, поддерживающие язык запросов SQL. К ним относятся системы управления базами данных ORACLE, Microsoft SQL, DB2, SYBASE.
Интернет-сервер предоставляет информацию в соответствии с правилами сети Интернет. В простейшем случае тоже, что и файловый сервер. Однако понятие интернет-сервера включает в себя и набор дополнительных сервисов, связанных, как правило, с преобразованием информации. Наиболее распространенными являются серверы APACHE и Internet Information Server.
Сервер приложения служит для выполнения специализированных задач. Многие банковские системы имеют серверы приложений, которые обеспечивают выполнение бизнес-логики приложения. При этом за хранение данных и контроль доступа к ним отвечает сервер базы данных.
Сервер архивации осуществляет хранение архивов: больших объемов редко используемой информации. Обычно от файл-сервера данный тип серверов отличают собственные механизмы компрессии, индексации хранимой информации и хранения истории вносимых изменений.
Сервер печати управляет печатью на общий принтер. Если не является специализированным устройством, то входит в состав сетевой операционной системы. Основой сервера печати является механизм управления очередями заданий на печать.
При рассмотрении решений на основе архитектуры клиент-сервер определяется и список задач, решаемых рабочими станциями и определенных как клиентские задачи. К ним обычно относятся:
* управление пользовательским интерфейсом - наиболее распространенная задача для рабочей станции, включает в себя обслуживание различных элементов пользовательского интерфейса, таких, как изображение на экране, кнопки, поля ввода, списки. Управление пользовательским интерфейсом и является той задачей, которая является гранью между архитектурой клиент-сервер и терминальным доступом;
* офисные приложения - список задач, обеспечивающих редактирование данных. Это различные редакторы, текстовые и табличные процессоры. Обычно сам процесс ручного ввода редактирования данных не является распределенной задачей и для экономии ресурсов серверов переносится на клиентское место;
* печать - в больших информационных системах функция печати может быть реализована на сервере и на клиентской станции. Обычно печать через сервер обеспечивает вывод на бумагу больших объемов данных, например выписок по счетам. Это объясняется требованием к высокопроизводительному принтеру, который невозможно поставить на каждое рабочее место. С клиентской станции осуществляется печать документов, необходимых только конкретному пользователю;
* загрузка и выгрузка данных также может выполняться и на клиентском месте, и на сервере. Обычно в случае, если данные загружаются в автоматическом режиме и не требуют администрирования загрузки, это выполняет сервер. Если загрузка или выгрузка данных случайна, то выполняется на клиентском месте.
Кластеры. В отличие от архитектуры клиент-сервер кластер имеет принципиально другие составляющие. Это не законченные задачи, а отдельные функции, выполняемые различными компонентами системы - как отдельным устройством, так и совокупностью составляющих различных вычислительных систем.
Решения на основе кластерной архитектуры дают ряд преимуществ.
Абсолютная масштабируемость - архитектура позволяет создавать кластеры любых размеров.
Инкрементальная масштабируемость - кластер создается таким образом, что можно наращивать мощность добавлением новых компонент без полной замены всей системы.
Рис. 26. Схема сети банк на основе кластерной технологии
Устойчивость к сбоям - в случае выхода из строя одного из компонентов система продолжает работать, поскольку все функции дублируются.
Хорошее соотношение цена/производительность - использование широкораспространенных компонент в качестве составляющих в общем случае требует меньших затрат, чем покупка одного сверхмощного компьютера.
В настоящий момент практически все операционные системы имеют дополнительные решения для реализации кластерных архитектур. Но данные решения составляют только основу кластера. Распределение служб между отдельными устройствами может определяться и программным обеспечением серверов приложения. Таким образом, кластерную архитектуру могут иметь и серверы баз данных, и серверы приложений, если они поддерживают данную функцию.
Операционная среда
Операционная среда - это совокупность операционных систем, используемых в организации. В идеальном случае организация использует одну операционную систему. Это сокращает затраты на администрирование операционной среды и на разработку и внедрение приложений. Но в крупных организациях, которые имеют огромные потоки данных и большое количество типов приложений, одна операционная система не покрывает всех требований. Поэтому часто используются несколько операционных систем одновременно.
Для того чтобы правильно выбрать операционную систему, необходимо понимать возлагаемые на нее задачи и ее параметры. Рассмотрим их более подробно.
Операционная система - это системное программное обеспечение, обеспечивающее среду для исполнения приложений, предоставляя им с помощью набора системных вызовов (API) доступ к устройствам компьютера. Среди многочисленных функций ОС - управление диспетчеризацией задач, распределением ресурсов, обработкой прерываний, вводом-выводом, интерфейсом пользователя, файловой и другими системами. Таким образом, компьютер работает под управлением ОС, однако при начальном запуске, отладке и тестировании он может работать под управлением встроенного ПО, именуемого монитором или базовой системой ввода-вывода (BIOS).
Практически все современные операционные системы в той или иной степени соответствуют данному описанию, поэтому при выборе операционной системы правильнее пользоваться набором параметров операционной системы, требуемых при решении конкретной задачи. Приведем эти параметры.
Совместимость выбранного приложения с операционной системой - основное требование. Операционная система - всего лишь среда для работы информационной системы. Она не отвечает за полноту функционала системы и ее параметры. Поэтому в первую очередь следует обращать внимание на качество основного бизнес-приложения. Только в случае конкуренции двух или более относительно равных по своим характеристикам приложений или если приложение способно работать в различных операционных системах, следует обращать внимание на операционную систему.
Аппаратная платформа. Как правило, операционная система может работать только на одном классе компьютеров. Поэтому при выборе операционной системы следует учитывать наличие соответствующей аппаратной платформы или затраты на ее приобретение.
Производительность операционной системы. Данный параметр определяет стоимость аппаратной платформы. Чем больше производительность операционной системы, тем ниже требования к технике и, следовательно, ниже ее стоимость.
Количество и доступность программного обеспечения, базирующегося на данной операционной системе. Следует помнить, что очень редко при создании информационных систем, решающих даже только одну задачу, можно обойтись одним приложением. Всегда существуют несколько дополнительных функций, которые выполняются либо программными средствами самой операционной системы, либо сторонними разработками. К таким функциям можно отнести:
- копирование и архивирование файлов системы;
- редактирование текстов и изображений;
- защиту системы от различных сбоев и нарушений;
- прочие полезные функции (калькулятор, календарь и т.д.).
Опыт использования операционной системы в организации для решения других задач. Наличие данного опыта свидетельствует:
* у организации уже есть лицензии на использование данной операционной системы и, возможно, не будет необходимости покупать новую;
* в организации есть специалисты по данной операционной системе, и скорее всего не понадобятся дополнительные затраты на обучение администратора.
Распространенность операционной системы. Данный параметр дает оценку по затратам на администрирование системы. Чем больше распространение, тем проще найти специалистов по данной системе на рынке труда.
Стоимость лицензии для операционной системы. Обычно стоимость операционной системы много ниже, чем стоимость всей системы в целом, поэтому на данную характеристику редко обращают внимание. Ее роль возрастает только в случае, если стоимость самой задачи невысока.
В настоящее время на рынке множество различных операционных систем для различного вида вычислительной техники. Однако в кредитных организациях используется лишь небольшая часть из них. Это объясняется повышенным требованием к надежности систем. Рассмотрим наиболее часто используемые операционные системы.
MS Windows. Безусловно, является самой популярной операционной системой для персональных компьютеров. Ее использование дает огромное преимущество: это и огромное количество приложений, работающих с данной системой, и совместимость со всеми устройствами, которые могут подключаться к персональным компьютерам. Рынок труда администраторов на 90% состоит из специалистов по данной системе. Большинство мелких и средних банков ограничиваются использованием только MS Windows. Недостатки MS Windows:
- стабильная работа только на архитектуре персональных компьютеров. Реализации для других типов вычислительной техники не получили широкого распространения;
- высокая стоимость лицензий.
Novell Netware. Эта сетевая операционная система была очень популярна в период зарождения сетевых технологий и получала большое распространение благодаря качественному сетевому сервису. В российских банках Novell Netware распространена благодаря СУБД Btrieve, на которой базировались наиболее популярные банковские системы России. Однако на сегодняшний день Novell Netware потеряла свое преимущество перед конкурирующими системами, Btrieve стал доступен на платформе MS Windows и практически перестал применяться в новых разработках. Поэтому использование продуктов Novell скорее объясняется большим объемом приобретенного на раннем этапе рынка, чем перспективами развития.
Unix-системы. Unix не является одной операционной системой, разработанной конкретной компанией. Под Unix понимается целый класс операционных систем, базирующихся на общих принципах. Область основного распространения Unix - это большие вычислительные машины. Практически каждый производитель больших ЭВМ имеет собственную Unix-систему или рекомендует разработку стороннего производителя.
На персональных компьютерах Unix-системы большого распространения не получили, уступив данный рынок Windows.
Linux. Система создавалась как вариант операционной системы Unix для персональных компьютеров. Однако в отличие от других операционных систем она имела одну особенность - свободное распространение и открытость исходных кодов. Это дало возможность вовлечь в разработку данной операционной системы большое количество независимых программистов. На сегодняшний день Linux реализован для большого количества различных аппаратных платформ, имеет развитый интерфейс, большое количество приложений. Специалисты рассматривают Linux как реальную альтернативу Windows в качестве операционной системы для рабочей станции. Однако в кредитных организациях использование Linux скорее объясняется порывом энтузиастов, чем реальными потребностями. Причина этого в отсутствии доверия к открытой системе, коду и функциям, за которые в конечном счете никто не отвечает.
Автоматизированные банковские системы (АБС)
История развития
Первые автономные системы, обеспечивающие обработку платежных документов, подсчеты балансов и подготовку отчетной документации в банках, были разработаны за рубежом в 50-х годах. В 1959 году в Bank of America начала работать электронная установка для осуществления депозитных чековых операций - ЭРМА. С появлением в 1954 году способа записи реквизитов документа специальными магнитными чернилами были разработаны поточные линии, которые помимо компьютера включали сортировальные и считывающие аппараты, механизмы для магнитной надпечатки, быстродействующие печатные механизмы для изготовления выписок, журналов и другой бухгалтерской документации.
Первая попытка широкого внедрения автоматизированных систем в начале 70-х годов окончилась неудачей в силу ряда факторов:
- темпы технического прогресса были ниже потенциально возможных;
- потребовались значительные усилия, чтобы рядовой потребитель принял новые формы предоставления услуг;
- для создания широкомасштабных систем передачи информации были необходимы огромные капитальные затраты;
- существующие внутри отрасли экономические связи не способствовали техническому прогрессу;
- постоянно происходило совершенствование применения обработки и оплаты традиционных чеков;
- регулирующий юридический и административный аппарат был связан с традиционной бумажной системой банковских услуг.
К концу 70-х главной целью банков стало увеличение объемов банковских услуг, поэтому типичная банковская система того времени представляла собой мощную обрабатывающую ЭВМ, к которой через относительно медленные каналы связи подключались региональные концентраторы и групповые терминальные контроллеры, обеспечивавшие распределение информации на местах. На рынке банковских систем доминировали такие фирмы, как IBM, UNIVAC, в то же время появились первые системы телеобработки данных, позволившие связать центральные конторы банков с удаленными филиалами, создавая тем самым системы электронных межбанковских расчетов (SWIFT и др.).
Массовое распространение ЭВМ в 80-е годы приобрело универсальный и всеобъемлющий характер, охватив буквально все направления банковской деятельности. ЭВМ стали дешевле, компактнее, надежнее, а значит, и более доступными в эксплуатации. Их использование позволило улучшить качество банковских услуг за счет автоматизации обработки информации на рабочих местах, где непосредственно выполнялись банковские операции и велось обслуживание клиентов. Именно в это время многие банки, имеющие разветвленные структуры, обратили внимание на ЭВМ фирмы DEC, для которых было создано сетевое программное обеспечение, позволявшее поддерживать связи практически с любыми имеющимися на рынке ЭВМ. На базе вычислительных машин этой фирмы стали создавать небольшие системы автоматизации банковских офисов, которые могли интегрироваться в более крупные.
В СССР в это время также начали проявлять интерес к автоматизации банковских операций. Рассматривались вопросы машинной обработки информации в финансово-кредитной системе, в том числе в сберегательных кассах.
Ускоренное развитие финансового сектора рынка, характерное для 90-х годов, потребовало от банков дальнейшего повышения эффективности обслуживания клиентов, гибкого экономического маневрирования, предотвращения снижения прибылей за счет принятия правильных, с точки зрения минимизации рисков, решений. Поэтому чрезвычайно актуальной стала проблема интеграции и обеспечения целостности оперативно используемой информации, чего можно было достичь только при условии применения эффективных средств распределенной обработки данных и связи.
Вместе с тем в результате ряда слияний многие западные фирмы и системы перестали существовать, и в середине 90-х рынок можно было охарактеризовать как застойный. Старые АБС, разработанные до появления современных компьютерных технологий, таких, как открытые системы, CASE-средства, графический интерфейс пользователя (GUI), объектно-ориентированный подход, устарели и не могли быть модернизированы, а АБС нового поколения еще не были созданы. Кроме того, изменились сами банковские технологии. Если раньше наибольший вес приходился на кредитование, операции Forex и операции на денежных рынках, что позволяло внедрять АБС без больших затрат на адаптацию, то с распространением закладных и портфельных (Portfolio Management) операций и особенно операций с производными инструментами (фьючерсы, опционы и свопы) сформировались новые требования к функциональным возможностям и гибкости АБС. В частности, банки должны были осуществлять мониторинг позиций относительно текущего состояния рынка (Mark-to-Market) и консолидировать риски по торговым операциям.
В России на рубеже 80-х и 90-х годов с появлением финансового рынка и первых коммерческих банков начала становление новая банковская система. Развитие отечественных технологий автоматизации банковского дела неразрывно связано с развитием банковской системы страны.
Первым этапом развития была так называемая островная автоматизация - естественный начальный этап автоматизации любого вида деятельности, который характеризуется автоматизацией отдельных, как правило, наиболее важных или относительно легко автоматизируемых, частей технологического процесса, относительной простотой реализации, возможностью быстрого внедрения, малочисленностью команды разработчиков, практической независимостью от коммуникаций.
Высокий уровень инфляции в период 1989-1995 годов стал важнейшим фактором, определившим развитие всей российской банковской системы, собственно банковского бизнеса, банковских технологий и банковских программных разработок.
Инфляционная накачка финансового рынка в эти годы явилась как макроэкономической основой количественного роста банковской системы вширь (банков становилось все больше, и они становились все крупнее), так и микроэкономической причиной высокого уровня доходности единичных финансовых сделок. Высокая доходность была доступной не для всех участников рынка, но именно для банков - как для распределителей и регуляторов инфляционных потоков, направленных сверху вниз. Основная задача банковской автоматизации на инфляционном этапе развития состояла в учете проходящих финансовых потоков, точнее - в учете отдельных платежей и отдельных операций. Банкам не приходилось особенно заботиться об автоматизации оптимального управления финансовыми ресурсами (активами и пассивами) - общий уровень доходности банковских операций при высокой инфляции все равно оказывался либо высоким, либо приемлемым. Такое положение определяло горизонтальное состояние рынка АБС, когда почти всем коммерческим банкам - потенциальным пользователям были нужны недорогие, практически однотипные программные продукты одного класса.
В течение этого периода развитие отечественных автоматизированных банковских систем связано в основном с изменениями аппаратно-технических платформ в банках без коренного улучшения технологических аспектов. В 1994 году можно было выделить четыре поколения АБС.
Первое поколение: аппаратная платформа - автономные персональные компьютеры под управлением MS-DOS; СУБД - Clipper, FoxPro, Clarion; базовый элемент технологии - бухгалтерская проводка; структура АБС - автономные АРМы, не связанные или слабо связанные по данным через обмен файлами (в том числе путем физического переноса на гибких дисках с компьютера на компьютер).
Второе поколение: аппаратная платформа - персональные компьютеры под управлением MS-DOS, работающие в локальной сети Novell NetWare; СУБД - Clipper, FoxPro, Clarion; базовый элемент технологии - бухгалтерская проводка; структура АБС - автономные АРМы, связанные по данным через общие файлы, лежащие на сервере и не связанные по функциям.
Третье поколение: аппаратная платформа - персональные компьютеры под управлением MS-DOS (MS Windows), работающие в локальной сети Novell NetWare (Windows NT); СУБД - Btrieve; базовый элемент технологии - бухгалтерская проводка (реже документ); структура АБС - автономные АРМы, сильно связанные по данным через общие структуры базы данных и слабо связанные по функциям. Технология - переходная, от файл-сервер к клиент-сервер.
Четвертое поколение: аппаратная платформа - персональные компьютеры под управлением MS-DOS (MS Windows), работающие в локальной сети, или же хост-компьютер с терминалами; СУБД - профессиональная реляционная (может быть постреляционная или сетевая); базовый элемент технологии - бухгалтерская проводка (реже), документ, сделка; структура АБС - автономные АРМы, сильно связанные по данным через общие структуры базы данных, в отдельных случаях связанные по функциям через общее ядро. Технология - хост-терминал или двухуровневая клиент-сервер.
С августа 1995 года прекратился численный рост количества банковских учреждений - как следствие принудительного снижения уровня инфляции и в связи с кризисом на рынке межбанковского кредитования - первым системным кризисом российской банковской системы. Снизилась доходность финансовых операций в целом. Банкам уже было недостаточно просто считать проходящие через банк финансовые потоки, появилась необходимость эффективного управления этими потоками (а также всеми активами и пассивами банка).
Соответственно изменился и рынок АБС. Он превращается в вертикальный, когда все большему числу коммерческих банков нужны серьезные, технологически продвинутые решения, интегрирующие учетные, аналитические и управленческие технологии. Вертикализация определяла развитие рынка АБС с осени 1995 до лета 1997 года. Понятно, что на горизонтальном рынке успеха добивается та фирма-разработчик, чьи программные продукты весьма просто внедряются и которая может продавать много, быстро и недорого. И наоборот, вертикальному рынку нужны высокотехнологичные программные решения, которые индивидуально адаптируются и настраиваются под каждый банк, внедряются по многомесячным специальным процедурам, такие банковские системы с учетными, аналитическими и управленческими функциями могут стоить в несколько раз или на порядок дороже.
В это время продолжалось усовершенствование систем четвертого поколения и начались разработки более серьезных систем пятого поколения. Аппаратная платформа - персональные компьютеры под управлением MS Windows, MS-DO, (реже UNIX), в распределенной сети (WAN) с несколькими физическими серверами приложений (которые работают под многозадачными многопользовательскими ОС); СУБД - профессиональная реляционная плюс менеджер транзакций; базовый элемент технологии - документ или сделка; структура АБС - логические АРМы, сильно связанные как по данным, так и по функциям в пределах локальной сети или хоста и слабо связанные по данным в пределах распределенной сети. Технология - трехуровневая клиент- сервер с использованием менеджеров транзакций.
Специфика российского рынка в том, что из-за введения новых правил бухгалтерского учета - нового Плана счетов (НПУ-НПС) - на короткий промежуток времени (во второй половине 1997 года) вернулся горизонтальный рынок. И это приостановило технологическое развитие автоматизированных банковских систем. В это время образовался очень активный горизонтальный спрос - большому числу банков понадобились быстро внедряемые АБС. Многие банки и фирмы-разработчики из-за надвигающегося перехода на НПУ-НПС затормозили или отложили до лучших времен свои перспективные программы технологического перевооружения (как собственные, так и выполнявшиеся по твиннинговым программам FIDP и кредитам Мирового банка). Горячие деньги рынка АБС осенью 1997 года были направлены не обязательно на приобретение не самых идеальных, но заведомо работающих АБС третьего поколения.
В 1998 году банкам и разработчикам пришлось приспосабливаться к новой реальности. Поскольку Центральный банк активно проводил политику консолидации в системе коммерческих банков России, это не могло не отразиться на состоянии рынка АБС. Основная конкурентная борьба между разработчиками шла не столько за влияние на рынок вообще, сколько за конкретные, весьма крупные, контракты. С 1998 года над российскими банками уже не висел дамоклов меч перехода на новые правила учета (НПУ-НПС) и деноминации, поэтому было время для осознанного выбора технологий, наиболее отвечающих формализованным требованиям и стратегии развития конкретного банка.
Однако ситуация во второй половине 1998 года резко ухудшилась. Рынок банковских информационных технологий перестает быть вертикальным, поскольку его финансовая емкость очень мала, и он становится точечным. Его основные особенности характеризуются следующими негативными факторами.
Во-первых, глобальная неустойчивость всего рынка. Отсутствует хоть сколько-нибудь стабильное деление банков по масштабу деятельности, уровням устойчивости и надежности. Прямым следствием банковской неустойчивости явилось нарушение финансовой устойчивости практически всех российских фирм - разработчиков банковских технологий.
Во-вторых, отсутствие стратегии. Выбор банками каких-либо информационных технологий вообще и систем автоматизации в частности уже не определялся стратегией и приоритетами в развитии банков на среднесрочную перспективу, самих перспектив (осязаемых и понятных) у большинства банков попросту не существовало. Если в начале 90-х банки выбирали системы автоматизации, в 1996-1997 годах - стратегического партнера в своем технологическом развитии, то в 1998 году банки вынуждены выбирать программные средства для обеспечения собственного выживания.
В-третьих, финансово-технологическая изоляция - остановлено либо радикально сокращено внешнее финансирование проектов по программам FIDP-ПРФУ как из-за реальных финансовых трудностей банков (Империал, Инкомбанк, СБС-Агро, Токобанк и др.), так и по решениям инициатора проектов - Мирового банка. В недавнем прошлом именно этот источник составлял основной путь импорта в Россию высоких банковских технологий мирового уровня.
В-четвертых, ценовая доминанта. В который уже раз изменились приоритеты банковских интересов и требования к АБС. В условиях тотального ужесточения финансовой конъюнктуры и относительного выравнивания функциональных возможностей систем определяющими параметрами выбора АБС вновь стали ценовые характеристики технологических решений.
В-пятых, потеря (отказ от) информационной управляемости. Консолидированные в лучших российских и зарубежных разработках технологии управления работой филиалов и банка в целом, активами/пассивами, рисками, лимитами, внутренними нормативами и т.д. оказались коммерческим банкам просто не по карману. Хочется заметить, что технологии, предназначенные для скрупулезного внутреннего анализа, базирующиеся не только на балансовых, но и на лицевых счетах, заведомо не могут быть дешевыми и легкотиражируемыми. Их установка и адаптация требуют тонкой и четкой настройки и от фирмы-разработчика, и от высококлассных банковских специалистов. Спрос на серьезные системы со значительными элементами анализа и управления (включая моделирование и прогноз) резко рухнул из-за тотального сворачивания российских финансовых рынков.
В настоящее время рынок банковских автоматизированных технологий вновь на этапе подъема. Финансовый кризис 1998 года для одних банков стал тормозом, а для других, наоборот, мощным импульсом развития бизнеса. А развитие невозможно без соответствующей программно-технологической поддержки. Тяжесть конкурентной борьбы между фирмами-разработчиками смещается в сторону тяжелых программных решений четвертого и пятого поколений. Происходит возврат спроса на автоматизацию банковской аналитики.
Перспективное направление развития автоматизированных банковских технологий как у нас в стране, так и за рубежом - шестое поколение АБС. Главные особенности: аппаратная платформа - гетерогенная сетевая среда; СУБД - профессиональные реляционные с открытым интерфейсом (возможно одновременно несколько разных СУБД); базовый элемент технологии - сделка или документ; структура АБС - логические АРМы, динамически формируемые по компонентной технологии, сильно связанные по данным и функциям в пределах всей сети Интранет.
Обзор зарубежных систем
Для определения современных мировых системно-технических тенденций развития информационных технологий в банковском секторе проанализируем наиболее известные и распространенные на международном рынке системы комплексной автоматизации банковской деятельности, предлагаемые на регулярной коммерческой основе.
Midas DBA, Equation DBA (Midas-Kapiti International, UK). Эти АБС входят в число мировых лидеров по количеству пользователей и действующих установок. Они хорошо известны и на рынке стран СНГ (более 20 внедрений). В целом системы себя зарекомендовали как довольно жесткие, труднонастраиваемые на особенности местного законодательства и нормативной базы. Объясняется это тем, что из рассмотренных это самые старые (в смысле используемых при разработке и программировании подходов, методов и инструментальных средств) системы - их коммерческие продажи начались в 1975 (Equation) и 1977 (Midas) годах системы работают на платформе IBM AS/400.
Bankmaster (Kindle Banking Systems Ltd., Ireland). Bankmaster занимает третью позицию по числу пользователей среди всех рассмотренных систем и одну из первых позиций среди систем на платформе UNIX. Система ориентирована на небольшие и средние банки. Первая коммерческая система была разработана в 1980 году для аппаратно-системной платформы ICL. В 1987 году был выполнен перенос системы на платформу UNIX, а в 1996 году - на платформу Windows NT. В качестве информационной основы АБС используются методы доступа операционной системы, однако в 1994 году была выпущена версия АБС (BANKMASTER/RS), в которой для управления данными применяется промышленная СУБД Informix.
Bankmaster - это универсальная банковская система, однако существенная доля функциональных подсистем поддерживается за счет дополнительных продуктов производителя или третьих фирм. Интеграция отделений (филиалов) с центральным офисом осуществляется по сетям ATM или Х.25. Допускается как автономная работа отделений (филиалов), так и совместная работа в режиме клиент-сервер с использованием интерфейсного продукта Transaction Processing Gateway.
IBIS (Financial Objects PLC, UK). АБС IBIS разработана в начале 1980 года в лондонском Итальянском международном банке (Italian International Bank). К 1992 году система была перенесена на платформу IBM AS/400 и стала распространяться под маркой IBIS/AS. Функциональное развитие системы осуществлялось в форме проектов для отдельных банков.
С точки зрения функциональности АБС IBIS/AS обладала теми же достоинствами, что и ее конкуренты на платформе AS/400, и аналогичными недостатками - при разработке АБС использовались устаревшие информационные технологии, система плохо структурирована, тяжела в поддержке и сопровождении. Дальнейшее развитие АБС проходило как по пути улучшения эксплуатационных характеристик, так и совершенствования функциональной части. Система полностью перепрограммирована с применением самых современных инструментов и технологий с участием специалистов из IBM.
Finance KIT (Trema Oy., Sweden). Система Finance KIT задумывалась как фронтальная часть бэк-офиса казначейства. Разработанная в начале 1990 года, в основном распространение получила в секторе корпоративного казначейства, хотя в числе пользователей было и несколько банков. Первоначально в качестве платформы АБС были выбраны персональные компьютеры с операционной системой Windows и настольной СУБД Access фирмы Microsoft. Однако эта платформа не смогла обеспечить требуемой производительности, и к 1994 г. АБС переписана для платформы UNIX и СУБД Sybase. В настоящее время АБС доступна на платформах Sun Solaris и HP-UX. Перенос на другие платформы или другую СУБД не планируется; версия для Windows больше не продается, но добавлена поддержка клиентских рабочих мест для Windows 95 и Windows NT.
Большая часть разработки выполнялась по согласованию с ABB, такого подхода придерживаются и в настоящее время. Несмотря на то что изначально Finance КИТ задумывался как инструмент корпоративного казначейства, постепенно добавлялись функции поддержки банковского бизнеса. В этом смысле система предназначалась для поддержки полного цикла обработки банковской транзакции - от ввода сделки до окончательного расчета. Как фронт-офис АБС взаимодействует с продукцией третьих фирм, включая дилинговые системы, системы телефонных торгов и инструменты анализа и ценообразования - JP Morgans Riskmetrics, электронные таблицы, пакеты бухгалтерского учета, ценообразования валютных опционов и форвардных операций, моделирования Что если и ценообразования в операциях с нулевым купоном.
Посредством встроенных редакторов можно создавать финансовые инструменты и настраивать связанные с ними потоки данных. Редакторы работают со стандартными компонентами и правилами. На уровне бэк-офиса Finance КИТ поддерживает расчеты, клиринг и платежи. Обновление всех позиций производится в режиме реального времени. АБС имеет интерфейсы к системам официальной отчетности, согласования и выверки, а также к терминалам SWIFT.
АБС не имеет собственной подсистемы Главная книга и должна быть сопряжена с соответствующим функционалом стороннего производителя.
Banes (Financial Network Services PTY Ltd., Australia). Первая версия системы разработана в конце 70-х подразделением обработки данных State Building Society для автоматизации бэк-офиса розничного сектора. Система работала на компьютерах NCR9800 под управлением операционной системы VRX. Сейчас продукт известен под двумя торговыми марками FNS и Banes (в зависимости от используемой платформы). Система работает на широком круге аппаратных и системных средств, включая мейнфреймы IBM, DEC VAX и различные Unix-системы. Особенностью работы в распределенных средах является как возможность взаимодействия с центральной базой в оперативном режиме, так и работа в автономном режиме в случае возникновения проблем с коммуникациями.
Изначально система предназначалась для автоматизации розничных операций малых и средних объемов. Она охватывает депозиты, кредиты, поддерживает автоматические кассовые аппараты и торговые терминалы. Система не имеет Главной книги, но имеет интерфейсы к Finance One, Oracle Financials и Peoplesoft, которые реализуют эту функцию. В секторе казначейства реализованы функции валютного и межбанковского дилинга, торговли драгоценными металлами и ценными бумагами и корпоративных кредитов.
Platon (IMS Business System Corp., USA). Первая версия АБС разработана в 1985 году для двух находящихся в Нью-Йорке корейских банков. АБС написана на 4GL Progress и работает на широком круге Unix-платформ. В 1996 году выпущена 32-разрядная версия для платформы Windows NT, но реальных продаж пока нет. Имеются интерфейсы к СУБД ORACLE, DB2 и DB2/400.
Platon охватывает основные операции валютного и межбанковского дилинга, коммерческие и потребительские кредиты, ипотеку, прием и выпуск аккредитивов, работу со счетами ностро. АБС имеет средства обработки и передачи основных финансовых сообщений через SWIFT, CHIPS, FEDWIRE и телекс (через соответствующие интерфейсы).
Поскольку Platon имеет ограниченные возможности в части казначейства, был разработан интерфейс к системе валютного дилинга и казначейства фирмы Financial Software Systems (FSS), который охватывает процессы фронт- и бэк-офиса.
Opics (The Frustum Group, USA). Вначале Opics задумывался как бэк-офисная система казначейства, однако вскоре разработчики сочли необходимым добавить и функции автоматизации фронт-офиса.
В 1993 году была подготовлена первая коммерческая версия АБС, которая внедрена в отделении Barclays Bank в Майами. К 1997 году АБС доработана до уровня универсального решения для банков, нуждающихся в поддержке как казначейских, так и розничных операций. Несмотря на то что в ряде функций (операции с драгоценными металлами, РЕПО, фьючерсы, опционы, соглашения о форвардной ставке) Opics обладает преимуществами даже перед такими общепризнанными лидерами систем банковской автоматизации, как Midas и Equation, розничный сектор имеет слабую функциональность и не способен обрабатывать большие объемы операций.
Olympic (ERI Bancaire SA, SwMTzerland). Первая версия АБС Olympic появилась в 1989 году на платформе AS/400 как результат новой разработки, ориентированной на работу с частными лицами.
Olympic разработана для поддержки работы фронт- и бэк-офиса - от приема клиентских распоряжений, включая электронный банкинг, до окончательных расчетов и уведомлений. АБС поддерживает фронт-офис портфельных менеджеров и дилеров, валютный дилинг, межбанковский дилинг, ценные бумаги, свопы, фьючерсы, опционы, добавленные в 1995 году совместно с кредитным модулем, регистрацию и учет розничных операций, документарные операции (в основном те функции этих подсистем, которые требуются для выполнения ежедневных операций по частным банковским услугам). Кроме того, имеются интерфейсы к SWIFT и основным клиринговым системам. С точки зрения производителя Olympic - клиент-ориентированная АБС с обновлением позиций в реальном времени.
В 1995 году начаты работы по переносу АБС на платформу Windows NT. Система разрабатывается на языке C++ с использованием объект-ноориентированной технологии и концепции хранилищ данных.
Symbols (System Access Pte Ltd., Singapore). АБС Symbols сингапурской фирмы System Access является одним из самых новых предложений на рынке банковских систем. Впервые система предложена в 1989 году, и ее первым пользователем стал Credit Suisse First Boston
Bank в Сингапуре. Первая версия АБС состояла из учетного ядра и основных функциональных модулей казначейства.
System Access позиционирует АБС Symbols как решение для средних объемов операций - минимальная установка поддерживает 12 пользователей. Наличие проблем в инструментальной части и механизмах доступа к данным производитель компенсирует возможностью приобретения АБС вместе с исходными кодами системы, возлагая тем самым ответственность за исправление ошибок и дальнейшее развитие системы на пользователя.
Symbols целиком базируется на ORACLE. Он написан в среде разработки ORACLE и использует генератор отчетов ORACLE для того, чтобы пользователи могли создавать свои специфические отчеты и запросы к базе данных. Система может работать на любой платформе, которую поддерживает эта СУБД - другими словами, на всех платформах, отличных от AS/400.
Большей частью система ориентирована на Unix-платформы, но была сделана версия для Next и в 1997 году - для Windows NT.
АБС построена по модульному принципу. К первой версии добавлены ссуды, документарные операции и депозиты частных лиц. Графический пользовательский интерфейс планировалось реализовать в середине 1994 года, однако это было сделано только в 1996 году, когда появились соответствующие возможности среды разработки ORACLE.
Также была задержана поддержка розничных операций. Она планировалась на конец 1993 года, но первая фаза реализована в середине 1994 года. Сектор розничных банковских услуг сейчас является главной областью, на которой сфокусировано внимание производителя.
Globus (Temenos Systems SA, Switzerland). Официальной датой появления системы Globus на рынке интегрированных банковских систем считается 1988 год. Однако Globus возник не на пустом месте. Прообразом АБС была корпоративная разработка Citibank, выполненная еще в 1977 году (АБС Cosmos). Первая версия Globus работала под управлением операционной системы Pick на компьютерах Prime. В 1989 году был выполнен перенос АБС Globus на платформу Unix, и тем самым существенно расширился спектр оборудования, на котором эта АБС может работать.
Globus разработан с применением СУБД Universe фирмы VMark Software, что упрощает перенос АБС с одной платформы на другую.
Функциональное развитие АБС Globus осуществляется постоянно путем включения в основной продукт отдельных разработок, выполняемых для конкретных заказчиков.
Стратегией фирмы является поддержка единой версии системы, обычно новые версии появляются один раз в год.
В марте 1997 года была продемонстрирована версия АБС для Windows NT, однако готовый для пилотных испытаний проект, функционально идентичный UNIX-версии, появился только в начале 1998 года.
В настоящее время система Globus работает на различных платформах, в том числе и Oracle, и является самой распространенной системой в мире по количеству и географическому охвату инсталляций.
Таблица 20
Сводная таблица технических характеристик зарубежных АБС
Наименование Уровни Используемые операционные СУБД Средства Базовый элемент
продукта приложений системы разработки системы
Сервер Рабочая
станция
1 2 3 4 5 6 7
Midas DBA, OS/400 OS/400 AS/400 проводка,
Equation RDB, DB2 документ
DBA for AS/400
Bankmaster Unix, WindowsUNIX, плоские проводка,
NT Windows таблицы, документ
(95, NT) Informix
IBIS терминал -OS/400 OS/400 AS/400 RDB документ
хост, 2
клиент -
сервер
Finance 2 клиент -Solans, HP-UX UNIX, Sybase документ, сделка
КИТ сервер Windows
(95, NT)
Banks терминал -Unix, WindowsUNIX, Oracle, проводка,
хост, 2NT Windows Informix, документ, сделка
клиент - (95, NT) SQL Server
сервер
Platon терминал -Unix Unix Progress Progress 4GL проводка,
хост, 2 документ, сделка
клиент -
сервер
Opics 2 клиент -Unix, WindowsUNIX, DOS,ODBC документ, сделка
сервер NT OS/2,
Windows NT
Olympic OS/400 OS/400 DB2 for проводка,
AS/400 документ, сделка
Symbols 2 клиент -Unix (SCO, HP,DOS, UNIX Oracle SQL*Forms, документ, сделка
сервер, 3Sun), Netware SQL*Repor tWrИTer,
клиент - 4GL
сервер
Globus терминал -Unix, WindowsWindows Universe, UV-BASIC, C,сделка
хост, 2NT (95, NT) Jbase, Visual Basic
клиент - Oracle
сервер
Как видно из таблицы, существенная часть зарубежных разработок вплотную сталкивается в настоящее время с проблемой унаследованных систем, работая от проводки и на архитектуре терминал-хост.
Обзор российских систем
В отличие от США и Западной Европы, где индустрия программных продуктов для банковской сферы развивается уже несколько десятилетий, рынок АБС сформирован и имеет четкую структуру, в России фирмы-разработчики более диверсифицируют свою деятельность, ими решаются вопросы автоматизации не только банков, но и других участников финансового рынка.
Проанализируем деятельность наиболее известных фирм, ведущих собственные разработки АБС в России, на основе материалов маркетингового агентства Дэйтор, агентства Сплан, информации фирм - разработчиков АБС.
Большинство российских АБС работают в двух- или трехуровневой архитектуре клиент-сервер, причем для одной из них (системы БИСквит фирмы Банковские информационные системы - БИС) работа и в той, и в другой архитектуре декларируется явно, а еще для одной (системы Банк XXI век фирмы Инверсия) работа в трехуровневой архитектуре наряду с двухуровневой объявлена возможной.
Все АБС могут работать в разных средах, среди которых, естественно, доминируют Windows NT и разные варианты UNIX в качестве серверных ОС, но названы и многие другие, в первую очередь Novell Netware. Что же касается клиентских рабочих мест, то тут можно встретить и DOS, и разные варианты Windows, и даже такую экзотику, как Java, предлагаемую фирмой АСофт.
Среди используемых СУБД представлен практически весь спектр систем, имеющихся на рынке. При этом обращает на себя внимание тот факт, что пользователи ряда АБС могут использовать на выбор несколько СУБД.
DiasoftBANK (ЗАО Компания Диасофт). Компания Диасофт предлагает целый спектр решений - от поставки отдельного программного продукта до комплексной автоматизации деятельности банка любого масштаба. В настоящее время существуют несколько вариантов комплексной автоматизации банка на базе трех линий программных продуктов, ориентированных на различные технологические платформы и имеющих ряд характерных отличительных признаков:
DiasoftBANK 4 x 4 является наиболее массовым решением, отличается относительной простотой при внедрении и эксплуатации. Базовый вариант системы работает на платформе Btrieve/Pervasive SQL. Новая версия системы - DiasoftBANK 4 x 4 WORKFLOW - поддерживает работу на 5 платформах - Pervasive SQL, MS SQL Server, DB2 for AS/400, Informix, Oracle.
Решение на базе системы Новая Афина способно поддержать работу крупного многофилиального банка с количеством операций от 1000 вдень. Мощность системы обеспечивается возможностями промышленной СУБД Oracle.
DiasoftBANKING 5NT - решение для мелких и средних банков на платформе MS SQL Server или Sybase Adaptive Server.
Любой из вышеперечисленных программных комплексов, взятый за основу построения системы автоматизации, решает основные задачи обеспечения деятельности коммерческого банка: ведение главной книги, расчетно-кассовое обслуживание, автоматизация работы бухгалтерии, межбанковские и межфилиальные расчеты (связь с РКЦ, SWIFT), получение финансовой и статистической отчетности, кредитное и депозитное обслуживание. Общие характеристики продуктов:
* многовалютность - позволяет работать с произвольным количеством валют в банке (при этом одна валюта выделяется в качестве национальной);
* многофилиальность - позволяет вести полные базы данных филиалов на едином физическом сервере;
* многоплановость - позволяет банкам работать с произвольным количеством планов счетов.
Каждый вариант решения представляет собой гибкую, настраиваемую многопараметрическую систему. Встроенные средства развития системы предоставляют пользователям дополнительный инструмент по наращиванию ее функциональности. Функции администрирования и аудита позволяют обеспечить требуемый уровень информационной безопасности. Полное протоколирование всех действий пользователя (ввод, редактирование, удаление) позволяет проследить историю изменения информации в базе данных.
RS-Bank (OOO RStyle SoftwareLab.). Комплексная автоматизация банков - одно из многих направлений деятельности фирмы. Главной задачей является ориентация на информационное и функциональное обеспечение всего спектра работ, связанных с реализацией банковских услуг. Первая версия системы RS-Bank вышла в свет в 1993 году.
АБС предоставляет средства для ведения качественного внешнего (бухгалтерского) и внутреннего (управленческого) учета. С помощью OLAP-технологий в программном комплексе реализовано аналитическое ядро, представляющее собой основу функционирования и инструмент разработки аналитических подсистем (включая собственно подсистему анализа консолидированной информации).
В основу АБС RS-Bank v.5.0 положены следующие базовые концепции: модульная организация системы (фронт-, бэк-, мидл-офисы); разделение модулей нa OLTP- и OLAP-приложения; принцип наращивания функциональности вокруг учетного ядра и аналитического ядра; реализация приложений на разных программных платформах.
Центавр, Гефест, Афина (ТОО ПрограмБанк). Компания ПрограмБанк - один из старейших разработчиков банковских систем в России, основана в 1989 году группой выпускников МФТИ, разработавших систему автоматизации для ряда крупнейших на тот момент коммерческих банков, уже ощутивших потребность в автоматизации. Этот программный продукт, получивший наименование DOS-комплекс, стал прародителем ИБС Центавр, которым пользуются сейчас около 400 банков. Такое решение оптимально для небольших банков, имеющих до 20 рабочих мест и совершающих до 1000 операций в день.
В 1993 году руководство компании приняло решение о начале инвестиций в разработку интегрированной АБС Афина (ныне - ИСУБД Новая Афина), базирующейся на промышленных реляционных СУБД класса Oracle и программных платформах класса UNIX. Сегодня с помощью Новой Афины свои операции ведут Сбербанк РФ, Внешторгбанк РФ, МДМ-банк, а также ряд представительств зарубежных банков. Новая Афина представляет собой набор автоматизированных бизнес-систем, работающих на основе универсального финансового ядра. Система реализована в архитектуре клиент-сервер. Основным объектом для работы в системе является документ - электронная копия реального финансового или учетного (административного) документа банка, паспорт сделки, свидетельство о совершении сотрудником банка определенной операции. Технические требования к серверу: операционная система MS Windows NT Server 4.0, Oracle Server версии; к клиентской части - Windows 95/98/NT.
В 1996 году начала разрабатываться АБС Гефест, занимающая нишу автоматизации средних по объему капитала кредитных учреждений с широкой региональной сетью филиалов и отделений, с ежедневным документооборотом в несколько тысяч документов. Она направлена на решение задач финансового управления банком. В ее основу положена система электронного документооборота банка с использованием СУБД Cache. Серверная часть работает на ОС Unix или Windows NT, а клиентская - Windows 95/98/NT.
Кворум (ЗАО АО Кворум). В июле 1992 года вместе с учреждением фирмы начались работы по созданию новой АБС КВОРУМ. АБС является полнофункциональным решением, способным обеспечить эффективную автоматизацию широкого диапазона бизнес-процессов современного банка.
Система КВОРУМ опирается на концепцию коллективной обработки банковских операций и основывается на принципе единой базы данных. Комплексный характер системы заключается в том, что в ней реализованы не только функции, связанные с основной деятельностью банковского учреждения (операционное обслуживание, кредитование и т.д.), но и подсистемы, обеспечивающие автоматизацию собственной деятельности (учет кадров, расчет заработной платы, учет основных средств и т.п.). Всего в состав системы КВОРУМ входят более 40 программных модулей.
Начиная с версии 6.0, в рамках АБС Кворум развиваются и поддерживаются две линии программных продуктов. Первая в качестве
СУБД использует Btrieve Record Manager, вторая работает на платформе Oracle Server. Обе линии используют одни и те же пользовательские интерфейсы. Бизнес-логика также является единой с алгоритмической точки зрения, различаясь при этом способом реализации (в приложениях, ориентированных на Oracle, бизнес-логика реализована в виде хранимых процедур на языке PL/SQL). Клиентская часть системы является 32-разрядным приложением для Windows 95/98/NT.
ASBank (TOO Предприятие АСофт). Предприятие АСофт основано в 1991 году, занимается разработкой, поставкой и поддержкой АБС и ИС уровня предприятия.
Система АС-Банк 2000 представляет собой пакет прикладных программ, позволяющий организовать предоставление широкого спектра финансовых услуг клиентам банка - физическим и юридическим лицам. Обеспечивает предоставление услуг клиентам в режиме онлайн и офлайн, поддержку текущего законодательства и правил ведения бухгалтерского учета в кредитных организациях, возможность одновременной работы с несколькими планами счетов. Предоставляет возможность технологического и функционального наращивания системы, расширения и самостоятельного изменения состава и содержания отчетных форм за счет наличия средств параметрической и алгоритмической настройки и генератора отчетов.
Сервер базы данных реализуется на СУБД Oracle. Возможна реализация на СУБД Informix, Ingres, SyBase или других по желанию заказчика. Клиентская часть системы реализована на Java, способной работать на PC-совместимых компьютерах, X-терминалах и Java-терминалах.
Основной архитектурной особенностью технологии является использование расширенной многокомпонентной модели клиент-сервер с ORB - в качестве центрального звена ПО среднего слоя - и использованием монитора транзакций. Технология Stellart объединяет два подхода в организации ИС - централизованное хранение данных, обеспечивающее высокую производительность, надежность и простоту администрирования, и распределенные вычисления, обеспечивающие масштабируемость ИС. Использование открытых технологий проявляется в выборе архитектуры (клиент-сервер), языков программирования (Java, C++), платформы для приложений (UNIX, Solaris).
БИСквит (ТОО Банковские информационные системы). Фирма создана в 1991 году группой специалистов по информационным технологиям Внешэкономбанка СССР. Первое внедрение было проведено в 1992 году. На сегодняшний день - более 100 установок.
Среда разработки: профессиональная реляционная СУБД Progress. Характеристики АБС: модульное построение; возможность эксплуатации на различных аппаратных платформах в средах UNIX, MS-Windows, Windows NT; гибкость и адекватность нормативным требованиям, реальный масштаб времени выполнения операций; интерактивность; мно-говалютность; интеграция данных.
MIM-Bank (ЗАО Фирма МММ-Технология). Система MIM-Bank ориентирована на использование в коммерческих банках различного размера и с различным объемом операций, в филиалах банков, а также в клиринговых и расчетно-кассовых центрах. Предназначена для комплексного ведения операционно-учетной работы банка, включая ведение кредитных, депозитных и корреспондентских счетов, кассовых операций, договоров и т.д. Используется также для анализа деятельности и состояния банка, печати необходимых отчетных и справочных документов, хранения, поиска, просмотра информации. Фактически система реализует рабочие места операциониста, бухгалтера, кредитного инспектора, экономиста, руководителя банка. Система может интегрироваться с другими системами, разработанными на базе МММ-технологии (непроцедурного проектирования информационных систем).
В качестве системного инструментария используется MIM-TOOLS - средство быстрой разработки бизнес-приложений RAD (Rapid Application Development). В качестве базовой как для БД создаваемого приложения, так и для словаря данных проекта (репозитория) используется не очень известная СУБД db_Vista (в настоящее время RDM - Raima Database Manager) фирмы Raima Corp. Основная отличительная особенность МММ-Технологии - ориентация на информационный объект, который является в ней очень емким понятием, включающим в себя данные, свойства, структурные связи с другими элементами, наследование свойств и правила поведения объектов в зависимости от состояния других объектов. Подход, реализованный в МММ-Технологии, состоит в максимальном отражении информационно-логических и поведенческих свойств прикладной области в модели данных. Поэтому значительно снижается потребность в проектировании и программировании процедур обработки данных.
Банк XXI Век, InvoBank (ЗАО Малое предприятие Инверсия - Научно-производственная фирма). Фирма была образована в октябре 1990 года. Общее количество инсталляций банковских продуктов - более 600 банков, отделений и филиалов.
АБС Банк XXI ВЕК представляет собой мультивалютный программный комплекс, реализующий современные банковские технологии в режиме реального времени для крупных банков. При написании клиентской части АБС Банк XXI ВЕК использованы средства разработки Oracle Forms 4.5, Oracle Reports 2.5 и Oracle Graphics 2.0, входящие в состав интегрированной среды разработки Developer 2000 фирмы Oracle. Интерфейс с базой данных реализован с использованием пакета SQL*NET фирмы Oracle.
База данных располагается на сервере БД Oracle, работающем под управлением практически любой Unix-подобной операционной системы. Технические характеристики сервера базы данных определяются в зависимости от количества банковских транзакций. Клиентские станции работают под управлением оконной надстройки MS-Windows над операционной системой DOS или в WinOS2 сессии операционной системы OS/2.
Система Invobank служит для автоматизации деятельности универсального среднего коммерческого банка. Система построена по модульному принципу. В основу положено ядро, ведущее основные справочники системы, регистрацию финансовых документов, осуществляющее операции по проводкам, переоценке и формирующее набор выходных форм. Низкая стоимость обеспечивается выбором в качестве средств разработки Btrieve и C++ при минимальных требованиях к аппаратному и лицензионному программному обеспечению.
Таблица 21
Сводная таблица технических характеристик российских АБС
Наименова- Уровни Используемые операционные СУБД Средства Базовый
ние приложении системы разработки элемент
продукта системы
Сервер Рабочая
станция
1 2 3 4 5 6 7
DiasoftBANтерминал Novell Netware,DOS, Pervasive SQL,C++, проводка,
K 4 x 4 - хост,Windows NT,Windows Scaleable SQL,собственный документ,
файл -OS/400 (DB2),(3.X, 95,DB/2 for AS/400,инструментарий сделка
сервер, 3UNIX (Informix)NT), OS/2 Informix. DiasoftSYS ТЕМ
клиент-
сервер
RS-Bank 3 клиентNovell Netware,Windows Btrieve, MS SQL, проводка,
- сервер Windows NT (95, NT) Sybase документ,
сделка
Новая 2 клиентWindows NT,Windows Oracle SQL Windows,документ
Афина - сервер UnixWare, SCO(95, NT) Oracle PL\SQL
UNIX, DigИTal
UNIX, Solaris,
HP-UX, AIX
Кворум 2 клиентNovell Netware,DOS, Btrieve, Oracle Pascal 7.0,документ
- сервер Windows NT Windows 95 Delphi,
Atlantis
ASBank 3 клиентUnix, WindowsWindows 95,Oracle, Informix,LISA-II проводка,
- сервер NT UNIX, Java Sybase документ,
сделка
БИСквит терминал Unix, WindowsWindows Progress Progress 4GL проводка,
- хост, 2NT (95, NT) документ,
клиент - сделка
сервер, 3
клиент -
сервер
МИМ банкфайл -любые, DOS, db_Vista MIM-Tools документ,
сервер использующие Windows NT сделка
DOS-сессию
InvoBank файл -Novell Netware,DOS, Btrieve C++, Borlandпроводка,
сервер Windows NT Windows v.4.5 документ,
(95, NT) сделка
Большинство АБС работают в двух- или трехуровневой архитектуре клиент-сервер. Все АБС могут работать в разных средах, среди которых, естественно, доминируют Windows NT и разные варианты UNIX в качестве серверных ОС, но названы и многие другие, в первую очередь Novell Netware. Что же касается клиентских рабочих мест, то тут можно встретить и DOS, и разные варианты Windows.
Среди используемых СУБД представлен практически весь спектр систем, имеющихся на рынке. При этом обращает на себя внимание тот факт, что пользователи ряда АБС могут использовать на выбор несколько СУБД.
Инструментарий бизнес-моделирования
В странах с рыночной экономикой, вопросы, связанные с оптимизацией производственных процессов, рассматривались давно и постоянно. Постепенно начали возникать определенные правила и стандарты, направленные на поддержку этого процесса. Появлялись и продолжают появляться новые методологии и теории. В современных условиях все они не существуют сами по себе как чистые научные подходы, а реализуются в программных продуктах, облегчающих данный процесс.
Каковы же основные современные термины, стандарты и методологии описания и реинжиниринга бизнес-процессов организации?
Опыт практического реинжиниринга породил ряд методологий и стандартов по разработке и моделированию бизнес-процессов. В основном они сводятся к регламентации построения и описания схемы бизнес-процесса на базе современных CASE-средств (Computer-Aided System of Engineering). Компьтерноориентированные системы инжиниринга предназначены для моделирования и анализа технологии работы, а также проектирования, разработки и сопровождения программного обеспечения. Мы рассматриваем использование CASE-средств лишь для анализа и проектирования всех бизнес-процессов и операций, хотя их способность существенно облегчать процесс создания программных продуктов (осуществлять его в полуавтоматическом режиме), в том числе и для автоматизации новой, измененной технологии работы, объясняет их популярность и широкое распространение.
Использование CASE-средств в реинжиниринге направлено в основном на моделирование деятельности, информационных потоков и потоков документов (WorkFlow). Модель какой-то системы - это представление набора компонентов системы или подчиненной области и их взаимодействие. Модель используется для описания, анализа, уточнения или замены системы. Модель представляет систему с помощью интерфейса или взаимозависимых частей, которые работают вместе, чтобы выполнить полезную функцию. Частью системы может быть любая комбинация объектов или функций, включая людей, информацию, программное обеспечение, процессы, оборудование, документы, изделия или сырье. Модель описывает, что делает система, на каких основаниях, как она работает, какие средства она использует, чтобы выполнить функции.
Существуют два глобальных подхода в моделировании - статическое и динамическое моделирование. Статическое моделирование основано на создании в соответствии с какой-либо методологией статической модели деятельности, которая в отличие от динамической не позволяет моделировать и анализировать процессы в динамике, движении. Разумеется, вследствие этого динамическое моделирование существенно нагляднее и обладает большими возможностями для естественного представления процессов организации и анализа, так как поддерживает механизмы параметризации модели, анализа типа Что если, дает удобные возможности отслеживать состояние и изменение всей системы в целом или ее отдельных составляющих. Но, как уже отмечалось выше, динамическое моделирование - крайне затратный и сложный процесс, и поэтому необходимо соизмерять требуемые ресурсы и возможный эффект. Именно поэтому чаще используется статическое моделирование, хотя сегодня в России существуют прецеденты использования динамического моделирования.
Для статического моделирования бизнес-процессов обычно используется методология SADT (точнее, ее подмножество IDEFO), поддерживаемая пакетами BPWin, Design/IDEF и др. Однако статическая SADT-модель, как отмечалось, может не обеспечивать полного решения задач перепроектирования, так как необходимо иметь возможность исследования динамических характеристик бизнес-процессов.
Одним из возможных решений является использование системы динамического моделирования Design/CPN, основанной на методологии цветных (раскрашенных) сетей Петри. Фактически Design/IDEF и Design/CPN являются компонентами интегрированной методологии перепроектирования: статические SADT-диаграммы автоматически могут превращаться в прообраз динамической модели, которая дорабатывается вручную и затем исполняется в различных режимах с целью получения соответствующих оценок.
При динамическом моделировании бизнес-процессов для каждого элемента модели задаются множественные (статические модели, как правило, ограничиваются одним или двумя) количественные параметры (временные затраты, ресурсы, стоимость, уровень риска и т.п.), а затем с помощью специальной процедуры анимации прослеживается поведение модели в динамике с учетом введенных параметров и их возможного изменения. Использование средств мультимедиа, включая визуализацию, видеоизображение, звуковое сопровождение и т.п., позволяет существенно повысить выразительность и наглядность построенной бизнес-модели, хотя традиционный графический подход в статических моделях также достаточно нагляден.
Следует отметить, что не существует принципиальных ограничений при использовании в качестве средства построения статических моделей бизнес-процессов еще одной традиционной методологии - диаграмм потоков данных, или DFD (data flow diagrams). Более того, в настоящий момент доступен ряд продуктов динамического моделирования (INCOME Mobile, CRN-AMI и др.), базирующихся на сетях Петри различного вида и интегрируемых с DFD-моделью, которые позволяют успешно решать задачи перепроектирования. Многие средства статического моделирования также поддерживают эту методологию, в том числе BP-Win (Platinum).
В общей процедуре реинжиниринга могут одновременно использоваться различные подходы и методологии с целью достижения большего удобства и эффективности проектирования. Например, бизнес-аналитики могут использовать методологию SADT, а разработчики программного обеспечения - методологии и подходы, основанные на стандарте DFD, или одно из современных средств UML (Unified Modelling Language - универсальный язык моделирования), который базируется на методологии объектоориентированного анализа.
В любом случае основными критериями выбора методологии и инструментария моделирования являются возможность на их базе решить поставленную задачу и экономическая эффективность их применения. С учетом того, что динамическое моделирование на порядок более затратно статического, а также учитывая и другие обстоятельства (например, наличие соответствующих специалистов и доступность литературы и программного обеспечения), наиболее приемлемым для облегчения задач реинжиниринга в российских банках являются методология SADT и основанная на ней группа стандартов IDEF.
Группа стандартов IDEF разработана в 1980-1990-х годах несколькими группами американских ученых под общим руководством Лаборатории Армстронга авиабазы Райт-Паттерсон ВВС США. Целью этих стандартов первоначально была унификация методов построения распределенных гетерогенных информационных систем. По мере разработки последующих стандартов становилось ясно, что группа IDEF потенциально имеет гораздо больший спектр применений.
Дело в том, что лежащие в основе этих стандартов фундаментальные категории система, структура, связь, действие представляют собой обобщение бесконечно большого числа частных случаев практического опыта. Выявив и сформулировав в этих категориях наиболее общие, характерные черты отдельных явлений и взаимодействий, человеческое мышление получило ту понятийную основу, которая позволяет, восходя от абстрактного к конкретному, описывать единым способом явления реальной жизни, бизнес-сферы с той степенью детализации, которая отвечает конкретным практическим потребностям.
При этом в силу весьма высокой степени абстрактности исходных категорий в стандартах IDEF имеется возможность легко переходить к описанию любых областей практической деятельности человека. Для этого формируется понятийный аппарат (определение, спецификация) более конкретного порядка и устанавливаются связи элементов аппарата с лежащими в основе абстрактными категориями. При необходимости еще более конкретизировать (детализовать) рассматриваемую область аналогичным образом создается понятийный аппарат следующего порядка конкретизации и т.д. Из чисто практических соображений стандарты IDEF предусматривают до шести уровней такой детализации. Практика показывает, что такого количества иерархических ступеней (или уровней вложенности) детализации достаточно для рассмотрения, анализа и моделирования практически любой области человеческой деятельности. Неудивительно, что разработанная первоначально в рамках крупного аэрокосмического проекта ВВС США группа стандартов IDEF и положенная в основу первого из этих стандартов (IDEFO) методика SADT (Structured Analysis and Design Technique) впоследствии с успехом применялись и применяются в самых различных отраслях промышленности и бизнеса. Как отмечает один из основоположников методологии IDEF, автор методики SADT, Дуглас Т. Росс, ее применяли тысячи людей при работе над сотнями проектов во многих областях.
Другой фактор, обусловивший распространение стандартов IDEF за пределы их первоначальной сферы применения, - наличие достаточно простого и удобочитаемого графического языка, принципиально облегчающего разработку и понимание структуры рассматриваемых областей.
Эти два фактора обеспечили принципиальную формализуемость описаний рассматриваемых областей, называемых IDEF-описаниями. В результате весьма быстро возникли программные средства автоматизации проектирования новых и моделирования существующих систем различного назначения, а также программные средства автоматизации проектирования новых программных средств, о которых мы уже упоминали.
IDEFO - методика моделирования, основанная на объединении графики и текста, которая обеспечивает понимание системы, ее анализ, логику потенциальных изменений. IDEFO-модель составляется из иерархического ряда диаграмм, которые постепенно отображают увеличивающиеся уровни подробных функций описания и их интерфейсов внутри системы. Имеются три типа диаграмм:
* графический символ;
* текст;
* глоссарий.
Графические диаграммы определяют функции и функциональные связи через блоки работ и синтаксис стрелок (вход, выход, механизмы (ресурсы), управление и семантику их взаимодействия. Текст и диаграммы глоссария обеспечивает дополнительную информационную поддержку графических диаграмм.
Таким образом, IDEFO представляет собой методику проведения различных видов анализа: анализа технологий и управления бизнес-процессов, анализа доходов и затрат, функционального анализа при проектировании систем автоматизации.
Одной из основных областей применения стандартов IDEF стала банковская, кредитно-финансовая сфера. Развитие этой сферы, как это ни парадоксально, привело к тому, что реальные денежные средства, операции становятся менее важны, чем информация об этих операциях. Если традиционно банки создавали деньги, и это была их основная функция, то сегодня основным продуктом их деятельности является информация. Разумеется, в этих условиях углубляется уровень компьютеризации и информатизации банковской системы.
Соответственно усложняются автоматизированные банковские системы (АБС), в огромной степени возрастают потоки информации в сфере денежного обращения и кредитно-финансовой сфере. Все это требует разработки соответствующих технологических потоков, систем управления и систем контроля такой сложности и таких размеров, что без автоматизации этих разработок их реализация стала бы просто невозможной. И здесь очень активно применяются стандарты группы IDEF. Примеры диаграмм, выполненных в этом стандарте, представлены в приложениях.
Остановимся на практических рекомендациях по методологии разработки, поддержки и корректировки технологической схемы работы банка Как есть в стандарте IDEFO. Рассмотрим процесс разработки и корректировки схемы Как есть и его этапы.
1. Постановка задачи для выполняемых работ:
1.1. определяется конечная цель построения схемы (например, автоматизация рабочего места, разработка должностной инструкции);
1.2. исходя из цели, определяется глубина детализации (например, до проводок, до полей в выходных документах, до операций, выполняемых пользователем).
2. Определяется точка зрения для построения диаграмм. В основной схеме используется точка зрения бизнес-технолога, задачей которого являются распределение обязанностей между работниками, разработка должностных инструкций. Для разработки пользовательского интерфейса лучше использовать точку зрения дизайнера интерфейса и детализировать в основной схеме блоки типа Зарегистрировать операцию в АБС. На диаграмме рекомендуется в качестве активностей описать ввод конкретных полей пользователем. В качестве стрелок использовать правила, накладываемые одним полем на ввод другого.
Для разработки отчета можно детализировать активности типа Формирование отчетности. В качестве активностей рекомендуется использовать бизнес-правила получения данных, в качестве стрелок - потоки данных.
3. Для описания новых бизнес-процессов рекомендуется максимально плотно ознакомиться с предметной областью, в которой строится диаграмма. Необходимо также ознакомиться с тем, как решаются аналогичные задачи в других организациях. Особо рекомендуется обсудить предлагаемую схему с предполагаемым конечным исполнителем и со службами, которые, возможно, будут участвовать в реализации данного бизнес-процесса.
4. При построении новой схемы необходимо:
4.1. определить глоссарий данного процесса. В случае, если используются выходные формы, описанные в прилагаемом к схеме списке выходных форм, в скобках после наименования документа указать его номер по списку. А в случае, если форма отсутствует в списке, зарегистрировать ее там;
4.2. определить место данного бизнес-процесса в существующей схеме. Определить входящие стрелки. Провести детализацию до нужного уровня, по возможности без рисования стрелок, используя только активности;
4.3. соединить активности туннельными стрелками от детализированной диаграммы к порождающей диаграмме;
4.4. провести объединение стрелок без потери информативности схемы;
4.5. провести соединение стрелок, входящих в бизнес-процесс, с граничными стрелками;
4.6. распечатать построенные диаграммы и обсудить их с предполагаемыми исполнителями.
5. Для оптимизации уже разработанной схемы необходимо:
5.1. определить параметры, требующие улучшения (например, длительность выполнения бизнес-процесса, упрощение для конечного исполнителя и так далее);
5.2. ознакомиться с предметной областью и возможными решениями данной проблемы;
5.3. попытаться поставить задачу без использования специальных терминов;
5.4. используя наработанный опыт и приемы оптимизации, провести перестройку данной схемы;
5.5. проверить соответствие новой схемы оговоренным условиям;
5.6. обсудить решение с предполагаемыми исполнителями.
6. После внесения изменений в схему сообщить о деталях изменений ответственному лицу, согласовать с ним добавления в глоссарий и перечень выходных форм.
7. Для поддержания актуальности базы первичных документов целесообразно оформить распоряжение по банку, запрещающее использовать документы, отсутствующие в реестре документов, и в случае необходимости использования таких документов обязать исполнителей провести их представление и регистрацию у лица, ответственного за поддержание актуальности и оформление реестра новых документов.
Поддержка интернет-услуг
Еще совсем недавно слово Интернет было так же популярно и модно, как в свое время космос или автомобиль. Только сам факт, что коммерческая организация предоставляет интернет-услуги, обладал мощным рекламным эффектом. Этим показывалось, что организация не отстает от требований времени, внедряя у себя новейшие технологии.
Существует множество причин такого стремительного развития, но основными являются максимум удобства и возможность предлагать более выгодное обслуживание и процентные ставки. Первое заключается в том, что сетевые банки предлагают обслуживание, при котором клиенту не надо даже выходить из дома или офиса, которое доступно ему в любой точке мира с любого компьютера и при этом 24 часа в сутки, причем без какого-либо специального программного обеспечения. Второе достигается за счет того, что операционные издержки интернетовского банка в несколько раз ниже, так как ему не требуется большой штат работников, дорогостоящие офисы и оборудование. Все это позволяет предлагать сетевым банкам конкурентные преимущества, которые недостижимы при традиционной организации банковского дела.
Однако очередной финансовый кризис, приведший к падению стоимости компьютерного бизнеса и особенно интернет-компаний, заставил многих пересмотреть свое отношение к эффективности внедрения высоких технологий и обоснованности затрат на них. Действительно ли предоставление интернет-услуг экономически выгодно? Дает ли оно резкое расширение клиентской базы? Насколько данные услуги удобны и выгодны клиенту?
Данная глава посвящена ответам на эти вопросы. В ней рассматривается опыт внедрения и использования интернет-услуг в российских и зарубежных банках, предлагается методика оценки эффективности использования данной технологии, обсуждаются альтернативные технологии.
Что такое интернет-услуги? Термин является достаточно неопределенным. Обычно под ним подразумеваются доступ к WEB-серверу банка и осуществление на нем различных операций или получение информации. Проблемы с защитой информации в открытых сетях вынуждают использовать выделенные каналы связи: либо прямое соединение по телефону, либо выделенный канал банк-клиент (точка-точка), который в настоящее время может предоставить почти любая крупная коммуникационная компания.
Также использование только браузера в качестве необходимого клиентского программного обеспечения в настоящий момент применимо только для простейших решений. Для сложных систем, включающих в себя аналитические модули, гибкую отчетность, для систем, которым предъявлены требования гибкости (таких, как системы удаленного участия в торгах), используется специализированное клиентское программное обеспечение.
Нередко под предоставлением интернет-услуг понимается только удаленное управление счетом клиента с использованием глобальной сети. Рассматривая возможность развития данного бизнеса в своей организации, менеджеры часто не обращают внимание на существование целого спектра других услуг, которые могут представляться через Интернет. Впрочем, разработчики систем интернет-услуг также ограничиваются системой электронных платежей. Данный подход снижает привлекательность подобных проектов, так как обычно банк уже имеет систему клиент-банк, основанную на прямом соединении клиента с банком, и вложение средств в дублирующую систему кажется необоснованным.
Однако если рассмотреть более полный перечень услуг на основе мирового опыта, то перспективы их внедрения могут оцениваться по-другому. Рассмотрим более подробно список услуг, предоставляемых различными банками в Интернете.
Информационный сервер банка. Данная услуга нередко рассматривается как рекламный проект, однако своевременное обновление информации на сервере, ее полнота и анализ могут сделать сервер постоянным инструментом в работе клиентов банка. Информационный сервер может стать первым шагом в развитии интернет-услуг.
Удаленное управление счетом. Обычно является основой интернет-сервиса, предоставляемого банком. Как правило, оно сводится к управлению рублевым счетом клиента, получению выписок и платежам. Управление валютными счетами требует наличия валютного контроля в документообороте, что в предлагаемых на сегодняшний день решениях на российском рынке - редкость.
WAP-банкинг. Является вариантом удаленного управления счетом через мобильный телефон. В основном используется для получения информации по счету, но для осуществления платежей обладает слабой защитой. В России эти услуги часто рекламируются, но реально практически не используются из-за неудобства и высокой стоимости мобильной связи.
SMS-сообщения. При помощи служб коротких сообщений (SMS), которые есть у любого оператора сотовой связи, клиенту доступна вся информация о состоянии расчетных счетов (остатков по счету), а также получение выписок по счету за требуемый период. Эта услуга имеет гораздо больше перспектив, чем WAP-банкинг. Проблемой является запрет на автоматическую посылку сообщений клиенту через WEB-сервер оператора сотовой связи, что приводит к необходимости работы специального оператора сообщений.
Торговые операции на биржах (Internet-traiding). Недавно данная услуга начала продвигаться и на российском рынке. Она предназначена в основном для азартных клиентов и более похожа на игорный бизнес, чем на финансовый. Часто организация, предоставляющая подобную услугу, даже не закрывает сделку на бирже, так как клиент, у которого отсутствует аналитическая оперативная информация с REUTERS, является заведомо проигрывающим участником рынка, выигрыш получает банк. В настоящий момент, когда отсутствует стабильный рост на рынках ценных бумаг, данная услуга будет скорее носить разовый характер для клиента: первые потери надолго отобьют у него охоту ее использовать.
Обслуживание интернет-магазинов. Учитывая в целом слабость данного бизнеса в России, различные проекты по его развитию скорее ориентированны на далекую перспективу, чем на сегодняшнюю прибыль.
Рассмотрим преимущества и недостатки интернет-услуг для банков. Изучая документацию на интернет-системы, невозможно реально оценить удобство ее использования, так как разработчик опускает ряд аспектов. Большинство недостатков выявляются только после начала эксплуатации системы. Таким образом, все убытки от них ложатся на организацию, эксплуатирующую подобную систему.
Самым известным недостатком является незащищенность системы от несанкционированного доступа. Все разработчики предлагают в рамках предлагаемого продукта и систему защиты передаваемых сообщений. Однако, даже если допустить, что подобная система идеальна (хотя ни одна из компаний-разработчиков не несет полной ответственности за взлом ее системы), существует еще большое количество возможных дыр в самом наличии контакта с глобальной сетью. В основном это недостатки операционных систем, коммуникационных программ, браузеров и просто человеческой психологии. Поддержка на надлежащем уровне защиты в системе требует постоянных и довольно высоких затрат, в том числе на зарплату специалистам, обучение клиентов, разработку защиты от новых методов взлома. И если крупный банк может позволить себе подобные затраты, так как ожидает от предоставления интернет-услуг значительных доходов, то для небольших банков данные затраты недопустимы.
Еще одной особенностью интернет-услуг является относительное удобство их использования в условиях отсутствия постоянного доступа (соединение с дозвоном через модем). Особенно это неудобство ощутимо для клиентов со сложным документооборотом. Для того чтобы зарегистрировать, отредактировать, проверить и подписать каждый документ, необходимо либо делать это все в одном сеансе связи, либо каждый раз тратить время на соединение и ввод пароля. Кроме того, многократная в течение дня идентификация клиента снижает защищенность его пароля.
Многие разработчики утверждают, что интернет-услуги можно получать с использованием любой техники, на которой работает интернет-браузер. Это часто не соответствует действительности, так как помимо браузера обычно требуется дополнительная программа защиты данных, которая в свою очередь более требовательна к операционной системе, например не работает на компьютерах типа PALM или под операционной системой Linux.
Часто рекламируемая низкая стоимость интернет-услуг также относительна. Фактически экономится только время ввода документа в систему. Однако немногие банки допустят у себя бесконтрольное прохождение платежей. Таким образом, остаются затраты на контроль каждого платежа и на анализ его назначения. Необходимость контроля платежа также делает бессмысленным утверждение о возможности управления счетом 24 часа в сутки, так как в нерабочее время все документы клиента обрабатываться не будут.
Следующей информацией, которая редко упоминается в рекламных проспектах, является реальная оценка доли клиентов, заинтересованных в интернет-услугах. Обычно утверждается, что данная услуга интересна всем клиентам банка. Рассмотрим это более подробно для каждой категории клиентов.
Крупный корпоративный клиент. Имеет собственную локальную сеть и мощную службу информационной поддержки. Документооборот с банком может исчисляться сотнями документов в день. Обычно используется многостадийная обработка документов. Наиболее интересна интеграция информационной системы банка и клиента таким образом, чтобы документы, прошедшие обработку в системе клиента, автоматически передавались на обработку в банк, и наоборот.
Небольшая компания. Клиент с документооборотом через систему банк-клиент - до 30-40 документов в день. При отсутствии выделенного канала в режиме дозвона (dial up) клиент более заинтересован в стандартном решении клиент-банк, что позволяет ему подготовить документы, проверить, подписать их и только после этого отправить в сеансовом режиме.
Маленькие компании с единичными платежами. Скорее всего именно они будут основными потребителями подобных услуг, особенно если платежи осуществляются одним лицом.
Физические лица (home banking). Несмотря на активную рекламу некоторых кредитных организаций о предоставлении услуг через Интернет, популярность подобной услуги в России невысока. Это объясняется отсутствием широкой практики безналичных платежей физическими лицами. А наиболее интересные для данного сектора коммунальные платежи до недавнего времени были сосредоточены только в Сберегательном банке России. Таким образом, самым распространенным сервисом для физических лиц до последнего времени были просмотр остатка по карточным счетам и информация об услугах банка, процентных ставках и курсах валют.
Но, несмотря на проблемы, интернет-сервис продолжает развиваться. Все больше кредитных организаций (в России около 70-80) включают интернет-сервис в перечень своих услуг, что показывает наличие ряда преимуществ перед другими формами предоставления услуг. Рассмотрим некоторые из них.
Низкая стоимость эксплуатации интернет-системы для банка. Все обновления системы: введение новых услуг, разработка новых типов документов и выходных форм. Обновления, вызванные изменением в законодательстве, проводятся только на WEB-сервере и не тиражируются у клиентов.
Возможность интеграции интернет-системы в бухгалтерские системы клиента, особенно если они являются собственными разработками клиента. Практически любое современное средство разработки позволяет внедрить в себя интернет-браузер с автоматической имитацией действий пользователя.
Доступность услуг для пользователя. Несмотря на то что клиент редко осуществляет платежи вне своего офиса, так как в этом случае у него возникают проблемы с учетом подобных сделок, сама возможность осуществить операцию из любого места дает ему дополнительную уверенность в гибкости его бизнеса и обладает значительным рекламным эффектом.
Дополнительные информационные услуги, предоставляемые банком, в случае их активного использования клиентом, усиливают связь между организациями и снижают вероятность перехода клиента в другой банк.
Поддержка высоких технологий. Несмотря на кризис, развитие интернет-сервиса продолжается, это приводит к изменению правил предоставления услуг, изменению требований клиента к услуге. В результате в лидерах окажется та организация, которая своевременно сможет предложить востребованный сервис, имеет опыт и работающие, проверенные временем, системы предоставления услуг.
Таким образом, несмотря на неочевидную эффективность банковского обслуживания через Интернет в России, его развитие оправдано как инвестиция в развивающийся рынок.
Учитывая достоинства и недостатки интернет-системы, приведенные выше, попытаемся определить, насколько эффективно и прибыльно их внедрение в систему услуг, предлагаемых банком.
Стоимость типовых интернет-проектов может колебаться от нулевой суммы до сотен тысяч долларов. Это объясняется тем, что данная область является развивающейся, смена технологий происходит каждый год, и менеджер, руководящий подобным проектом, не в состоянии правильно оценивать затраты. В результате объем затрат в основном определяется специалистами, реализующими данный проект и контроль за ними.
В случае отсутствия каких-либо услуг в Интернете банку необходимо начать с разработки собственного WEB-сайта. При этом не рекомендуется сразу включать в него предоставление других услуг, кроме информационных. Это позволит отработать технологию работы и понять интерес клиентов именно этого банка к Интернету в целом. Данный проект может быть реализован силами любого отдела автоматизации без привлечения сторонних разработчиков. Сайт может быть опубликован на платном WEB-сервере (не более $50 в месяц) либо на бесплатном (в качестве платы придется размещать на нем чужую рекламу. Кроме того, у компании, предоставляющей вам данный сервис, будут отсутствовать какие-либо обязательства). Однако в случае отсутствия возможности самостоятельной разработки сайта можно привлечь сторонних разработчиков. В настоящий момент их услуги в зависимости от известности и опыта за данный объем работ будут оценены на сумму от $1000 до $15 000.
Внедрение интернет-платежей потребует уже выделенного канала и специализированного сервера, а также системного программного обеспечения, системы защиты и собственно системы платежей. Средняя ориентировочная стоимость этих составляющих для проекта 100-300 документов в день:
выделенный канал - около $700 + $150 ежемесячно;
сервер (включая систему резервного копирования) - около $3000;
операционная система - от 0 (Linux) до ~ $3000 (Windows NT);
СУБД - в зависимости от требований платежной системы ($1500 MSSQL) до $10 OOO(ORACLE);
система защиты - от 0 до $5000;
платежная система - от $2000 до $30 000 (российские) и до $100 000 (зарубежные разработки).
Средний срок полной реализации проекта составляет не менее 3 месяцев.
Таким образом, стоимость простейшего проекта электронных платежей и документооборота через Интернет для небольшого банка колеблется от $15 000 до $150 000.
Какой эффект могут принести данные затраты - это предмет оценки бизнес-специалистов. Но в любом случае он должен быть адекватным.
Несмотря на популярность банковских услуг в Интернете, существует альтернативный ряд решений, успешно применяемых как в России, так и за рубежом. Данные решения не имеют активной рекламной поддержки, однако они более стабильны и более проработаны. Рассмотрим три наиболее популярные из них и проведем сравнение с интернет-услугами.
Системы клиент-банк. Отличие от системы платежей через Интернет заключается в том, что у клиента устанавливается все необходимое программное обеспечение для работы с платежами, включая справочники. Преимуществом данной системы является ее замкнутость, отсутствие необходимости в постоянном соединении с банком. К недостаткам подобных систем можно отнести сложность в эксплуатации для клиента, дополнительные затраты банка на их поддержание, затраты на покупку каждого рабочего места клиента, незащищенность данных, хранимых у клиента (для сокращения затрат клиента обычно используются не решения клиент-сервер, а более дешевые локальные СУБД)
Интеграция платежной системы банка в систему документооборота клиента. Обычно доступна только для ключевых клиентов банка, так как требует отдельного проекта разработки и адаптации систем для каждого клиента. Наиболее эффективное и привлекательное решение для обеих сторон, фактически исключающее вероятность случайного разрыва отношений. Однако данное решение очень дорогостоящее. Ориентировочная стоимость наиболее полной интеграции систем может доходить до сотни тысяч долларов.
И последняя из рассматриваемых альтернатив - это управление счетом по телефону. Такие системы существуют на рынке в огромном количестве, и их самостоятельная разработка не представляет сложности. Как правило, они позволяют осуществлять с достаточным уровнем безопасности все базовые операции: получение информации по счету, переводы, курсы валют и т.п.
Альтернативные решения показывают, что при оценке вариантов развития услуг не стоит зацикливаться только на интернет-решениях, в отдельных случаях возможно не менее эффективное и существенно более экономичное решение.
Пластиковые карты
Рассматривая практические решения и инструментарий в области банковских информационных технологий, обязательно нужно сказать несколько слов о таком их направлении, как автоматизация работы с пластиковыми картами. Это направление появилось как следствие применения современных технологий для традиционных чековых расчетов, и естественно, что его функционирование в банковской практике на 99% зависит от применения передовых банковских и информационных технологий.
Автоматизация работы с банковскими картами настолько сложна, что для ее рассмотрения потребовалась отдельная книга. Поэтому мы остановимся лишь на некоторых, наиболее важных, по мнению авторов, аспектах автоматизации и ИТ-менеджмента.
С точки зрения автоматизации для поддержки карточного бизнеса двумя важнейшими направлениями являются программная поддержка и телекоммуникации. Рассмотрим их по очереди.
Программное обеспечение для автоматизации работы с пластиковыми картами весьма разнообразно как по типам, так и по разновидностям и функциональному наполнению. Можно выделить следующие основные типы программного обеспечения.
Авторизационные системы. Перед совершением операции по пластиковой карте (вне зависимости от источника операции - банкомат, POS-терминал и т.п.) необходимо получить разрешение на операцию - авторизацию. Для этого операция должна соответствовать целому раду условий, которые и проверяются авторизационными системами. Это могут быть и достаточность средств, и просроченность (валидность) карты, и проверки, связанные с обеспечением безопасности, и многое другое.
Авторизацию по поручению точки приема карты запрашивает банк-эквайрер. Ответ предоставляется эмитентом карты и представляет собой положительный код авторизации или сообщение об отказе операции, а возможно, и об изъятии карты. В основном авторизация проходит в онлайн-режиме. В региональных платежных системах операция инициируется в точке приема карты, запрос принимается региональным процессинговым центром. Если операция не локальная, запрос направляется по сети Х25 в головной процессинговый центр.
Ввиду их критичности авторизационные системы должны соответствовать целому ряду критериев, в том числе должны быть лицензированы платежной системой, поэтому, как правило, авторизационные системы - зарубежного производства. Их поддержка и сопровождение осуществляются компанией-поставщиком. В качестве примера можно привести систему BASE 24.
Описанные функции вместе с функциями маршрутизации запросов, операциями в терминальных устройствах также называются фронт-офисными, а их системы автоматизации - фронт-офисными системами.
Бэк-офисные и бухгалтерские системы направлены на поддержку комплекса операций с банковскими картами и, как правило, не функционируют в онлайн-режиме, и не связаны с терминальными устройствами. Их основными функциями являются:
- операционный и бухгалтерский учет;
- формирование выписок и их рассылка клиентам;
- осуществление начислений (проценты, комиссии и т.п.);
- проведение взаиморасчетов;
- клиринг;
- межбанковские расчеты;
- расчеты с платежными системами;
- ведение счетов и т.п.
Такие системы часто разрабатываются самостоятельно. Хотя на рынке предложение таких систем, как российского, так и зарубежного производства, велико. В качестве примера можно привести карточные бэк-офисные системы таких разработчиков, как Diasoft или R-style.
Системы поддержки карточного бизнеса предназначены для ведения и обработки информации о клиентах банка, карточных продуктах, их доходности и объеме операций и предоставляемых услуг.
Иногда бэк-офисные системы и системы поддержки карточного бизнеса могут совмещаться в одном комплексе. Такие системы в отличие от авторизационного ПО часто разрабатываются самостоятельно. Основная причина этого в том, что пластиковый бизнес весьма индивидуален, особенно в части организации его поддержки, операционного и бухгалтерского учета, расчетов с банками и платежными системами.
Перечисленные выше группы программного обеспечения информационных систем не исчерпывают весь список, который мог бы быть продолжен системами поддержки выпуска карт, контроля терминальных устройств и т.д.
Остановимся на основных требованиях к программному обеспечению для автоматизации операций с банковскими картами.
* Архитектура программного комплекса должна предусматривать открытость и маштабируемость, то есть позволять организаторам системы наращивать ее мощность, не внося кардинальных изменений.
* Программное обеспечение должно обеспечивать возможность использования широкой номенклатуры технологических типов карт и оборудования (карт-ридеров, POS-терминалов, банкоматов). Так как развитие карточного бизнеса в банках обычно идет поэтапно, периодически может возникать необходимость менять ключевые параметры системы, типы используемого оборудования и даже карт. Поэтому программное обеспечение должно быть максимально универсально.
* Программное обеспечение должно иметь возможность настройки и поддержки различных видов организационных, финансовых и коммуникационных схем взаимодействия как между различными участниками платежной системы, так и с внешним миром.
* Программное обеспечение должно соответствовать высочайшим стандартам информационной безопасности и надежности.
* И наконец, оно должно быть совместимо с международными платежными системами и банковской системой (АБС).
Следует отметить, что особо критичной областью поддержки операций с пластиковыми картами являются телекоммуникации. Основным протоколом связи для таких операций служит Х25. Основная специфика обеспечения связи всех элементов состоит в том, что должна достигаться их надежность и максимально быстрое восстановление связи при ее сбое. Это приводит к тому, что даже для небольшого банка необходимо отслеживать в круглосуточном режиме связь с множеством устройств. Иногда для этого требуется поддержка специальным программным обеспечением.
Банки самообслуживания
Ежедневно мы становимся свидетелями возникновения новых каналов предоставления банковских услуг, часть из которых была рассмотрена выше. Другим возможным способом организации нового канала предоставления услуг частным вкладчикам является внедрение автоматизированных банков самообслуживания (БС), которые выполняют функции традиционного банка, но с использованием устройств банковского самообслуживания. Впервые такие банки стали создаваться в конце 80-х. Уже в 1986 году Национальный банк Австралии (National Australia Bank) совместно с компанией NCR, которая является одним из лидеров по техническому и технологическому обеспечению таких банков, создал филиал, в котором устройств самообслуживания было больше, чем персонала.
В 90-х годах ведущие зарубежные банки стали создавать банки самообслуживания наиболее активно. Так, по данным компании Mentis Corp., количество филиалов банков США с активами более $4 млрд. увеличилось с 731 в 1995 году до 1842 в 1996 году. При этом число банков, использующих системы самообслуживания, возросло с 49 до 65%.
Статистические данные по США показывают, что транзакции через банкомат в четыре раза дешевле транзакций, выполненных в филиале через кассира ($0,27 против $1,07 за транзакцию). Кстати, банковская транзакция в Интернете обходиться в среднем менее чем в 10 центов, а в отдельных случаях и около 1 цента. Автоматизированные филиалы самообслуживания занимают меньше места по сравнению с традиционными и требуют меньшего количества обслуживающего персонала. Таким образом, они позволяют банкам с многочисленными филиалами решать проблему структурной перенасыщенности.
Создание банков самообслуживания, как и виртуальных банков, должно рассматриваться как часть стратегии диверсификации каналов предоставления услуг частным вкладчикам. По этой причине они неразрывно связаны с другими каналами предоставления банковских услуг, например доступом к услугам банка с помощью телефона.
Современные устройства банковского самообслуживания позволяют осуществить полный спектр операций со счетами клиентов:
* выдачу и депозит наличных денежных средств;
* перевод средств со счета на счет клиента;
* оплату коммунальных платежей;
* операции с чеками;
* выдачу различных документов о состоянии счета и проведенных операциях в виде выписок, мини-выписок и т.п.;
* обмен иностранных валют;
* обслуживание карт локальных и международных платежных систем;
* операции по открытию счета;
* заказ чековых книжек;
* обновление информации в сберегательных книжках.
Кроме того, современные киоски для выполнения безналичных операций позволяют осуществлять информационную и консультационную поддержку для существующих и потенциальных клиентов. Для этого используются интерактивные киоски, работающие в режиме видеоконференций и обеспечивающие связь клиента с удаленным консультантом.
Специфика создания банков самообслуживания в каждом конкретном случае определяется стратегией банка на рынке предоставления услуг частным вкладчикам. Такая стратегия необходима банкам для лучшего и более экономичного обслуживания клиентов и призвана обеспечить:
- удобство за счет лучшего доступа ко всем видам услуг;
- гибкость: у клиента есть выбор, как и где производить операции;
- привлекательность для клиентов, которые предпочитают высокий технологический уровень обслуживания;
- сохранение клиентов, которые становятся зависимыми от вариантов предоставления услуг и оценивают их, сравнивая с предложениями конкурентов;
- эффективность за счет сокращения непроцентных расходов (люди/здания/вспомогательные службы).
Для выработки стратегии необходимо переосмыслить каналы и технологию предоставления банковских услуг. При этом очевидно, что с помощью банков самообслуживания могут быть реализованы не все функции, а только те, автоматизация которых экономически выгодна банку в настоящее время.
Зарубежный опыт показывает, что банки самообслуживания могут быть развернуты в местах, связанных с работой и учебой (офисные комплексы и деловые центры, университетские городки), повседневной жизнью (аэропорты, вокзалы, супермаркеты, торговые комплексы, заправочные станции) и отдыхом (курорты, центры развлечений и досуга). Такие банки, размещенные на территории торговых предприятий, открывают значительные возможности по извлечению дополнительного дохода от:
* размещения рекламы и информации о товарах на экранах банкоматов и интерактивных терминалах;
* распространения купонов на получение скидок в магазинах;
* продажи сопутствующих товаров (билеты на развлекательные мероприятия, почтовые марки, телефонные карты и карты типа электронный кошелек, подарочные сертификаты).
Если банк принял решение о создании банка самообслуживания, то целесообразным представляется осуществление следующих мероприятий:
- планирования канала предоставления услуг;
- анализа активности клиента;
- выбора наиболее перспективных с точки зрения прибыльности операций для автоматизации;
- разработки решения;
- разработки интерьера в соответствии с имиджем и политикой банка;
- разработки технических решений для центра видеосвязи;
- разработки имиджа банковских продуктов и услуг;
- оценки влияния автоматизированного банка самообслуживания на существующую сеть филиалов;
- оценки влияния функциональности и используемых технологий на взаимоотношения банк-клиент.
При внедрении новых банковских технологий всегда существуют ключевые психологические факторы, на которых следует акцентировать внимание. Это страх клиентов перед новыми технологиями и роль консультанта в процессе ознакомления клиентов банка с системами самообслуживания. Также необходимо помнить, что в силу несовершенства аппаратных и/или программных средств или отсутствия внутренних инструкций банка, а также по соображениям безопасности всегда будут существовать операции, которые не могут быть автоматизированы.
Структурно системы самообслуживания представляет собой четыре взаимосвязанных компонента:
1) терминалы банковского самообслуживания - банкоматы, информационные и интерактивные терминалы, обеспечивающие функциональное выполнение заданных операций банковского самообслуживания (например, депозит наличных средств и платежных документов в конверте);
2) фронт-энд (front-end) система, обеспечивающая управление терминалами банковского самообслуживания, маршрутизацию запросов на авторизацию и мониторинг технического и финансового состояния терминалов (например, при реализации конвертного депозита эта система должна поддерживать выдачу конвертов, открывание шторки конвертного депозитария, репортирование о его переполнении или отсутствии конвертов);
3) бэк-офис (back-office) система, под которой понимаются модули банковской системы (в частности, база данных клиентских счетов), обеспечивающие поддержку ряда функциональных операций (например, полные выписки по счету или по карте);
4) нормативная база банка, включающая внутрибанковские и клиентские технологические инструкции, а также набор типовых контрактов, регламентирующая порядок выполнения операций (например, обработку вложений в банке, полученных с помощью устройств банковского самообслуживания) и порядок разрешения споров.
При реализации той или иной функциональной операции (например, формировании полной выписки по счету) важна поддержка данной операции каждым из компонентов. При отсутствии хотя бы одного из кирпичиков реализация данной функции невозможна.
Рассмотрим несколько примеров создания банков самообслуживания компанией NCR.
Хантингтон Банк (Huntington Bank, США) с 1994 года открыл 35 полностью автоматизированных филиалов, получивших название Access. Основным оборудованием данных филиалов являются интерактивные терминалы. Банк сделал упор на автоматизацию безналичных операций, таких, как предоставление ссуд, открытие счетов, различные виды депозитов, операции со счетами. До создания первого филиала банк создал систему обслуживания по телефону и через Интернет.
В интервью газете American Banker старший вице-президент банка г-н Рэндл отметил, что при разработке проекта была сделана ставка на тех клиентов, которые предпочитают общаться с банкоматами, а не операционистами. С психологической точки зрения этот процесс требовал значительного изменения в поведении другой категории клиентов, не ориентированных на использование филиалов самообслуживания. Этим объясняется тот факт, что объем транзакций в филиалах Access первоначально был меньше, чем в традиционных филиалах. В то же время операционные расходы автоматизированного филиала сократились на 50-70% по сравнению с традиционным, площадь - на 50%, а количество персонала - с двенадцати человек до одного. Однако было замечено, что средний возраст клиентов, использующих интерактивные терминалы, составляет 38 лет (по статистике средний возраст клиентов, использующих банкоматы, равен 36 годам). Важным обстоятельством, определяющим успех проекта, является наличие в банках самообслуживания консультанта, который помогает клиентам освоить новые технологии выполнения операций. При реализации проекта Access консультант работал в филиале только первые полгода.
Кипрский Банк (Bank of Cyprus) в июне 1996 года открыл полностью автоматизированный филиал (см. рис. 27), который функционирует 24 часа в день 7 дней в неделю. Банк считает создание такого филиала первым шагом на пути модернизации обслуживания частных вкладчиков. В его состав входят:
* устройство для приема монет (монеты пересчитываются, сумма зачисляется на счет клиента);
Рис. 27. Внешний вид системы самообслуживания Bank of Cyprus
* устройство для размена банкнот (банкнота любого достоинства в местной валюте может быть обменена на эквивалентное по сумме количество монет);
* банкомат с функцией обработки документов (выполнение банкоматных функций и операций по депонированию чеков и оплате коммунальных услуг). Дополнительно данный банкомат может выполнять функции бизнес-депозитария для депонирования значительных сумм наличными или чеками);
* интерактивный терминал (формирование и распечатка различных выписок по счету и выдача чековых книжек;
* устройства обмена иностранных валют на кипрские фунты;
* банкомат для выдачи наличных (Fast Cash ATM);
* банкомат с устройством печати выписок (выполнение банкоматных функций и печать полной выписки по счету);
* банковская горячая линия (для получения информации о банке и услугах по телефону);
* банковские услуги по телефону (балансы по счетам, информация о курсах валют, заказ чековых книжек, заказ выписки по счету);
* информационный терминал (бланки для подписки на банковские продукты, текущие курсы валют, информация о биржевых котировках, банковские и финансовые новости).
Приложения
Приложение 1. Схема организации ИТ по CoblT
Схема организации ИТ по CoblT
IT GOVERNANCE
IT GOVERNANCE
Приложение 2. Анализ функций ИТ: результаты диагностики
Анализ функций ИТ: результаты диагностики
Приложение 3. Пример матричной оргструктура ИТ-департамента
Пример матричной оргструктура ИТ-департамента
Приложение 4. Образцы тендерной документации
Приглашение на участие в тендере по выбору информационной системы
Уважаемые господа!
Предлагаем Вашему вниманию приглашение на участие в тендере по выбору банковской информационной системы.
Общая информация
Один из наших клиентов, активно развивающийся коммерческий банк (далее - банк), планирует внедрение новой банковской автоматизированной системы._____________________________ выступает в качестве независимого организатора и консультанта по данному проекту и приглашает Вашу компанию принять участие в тендере по выбору банковской информационной системы для автоматизации головного офиса и отделений Банка в г. Москве.
Общая информация по деятельности и осуществляемым операциям, функциональные и технические требования и другая дополнительная информация изложены в соответствующих разделах Приложения Функциональные и технические требования к автоматизированной банковской системе.
Условия тендера и порядок взаимодействия
По результатам предварительного анализа была отобрана группа поставщиков банковского программного обеспечения, которым рассылаются данные предложения. Предполагается, что тендер будет состоять из двух этапов.
Этап 1 - включает рассылку данного предложения, первичный анализ предложения компаниями-поставщиками и письменное подтверждение намерения участвовать в тендере, сбор письменных комментариев к предложению, ценовой информации и предполагаемых сроков осуществления работ и их анализ Банком и независимыми консультантами по проекту.
Этап 2 - в процессе анализа полученной на предыдущем этапе информации будет выбрана группа из 3-4 компаний, решения которых подвергнутся детальному анализу. Об этом решении компании будут официально уведомлены. Компании, прошедшие во второй этап, должны будут организовать развернутые презентации своих систем в согласованные сроки и представить дополнительную информацию, запрос на которую будет им предоставлен позже.
Компания оставляет за собой право вносить изменения в порядок проведения данного тендера, а также предъявлять дополнительные требования в процессе выбора.
Сроки проведения
Этап 1. Дата рассылки предложения - ___________ г. Участникам необходимо письменно подтвердить свое намерение участвовать в тендере в течение 3 дней по факсу. Предоставление комментариев к функциональным и техническим требованиям, а также информации по срокам и стоимости ожидается от участников до ____________ г.
Этап 2. Предполагаемое начало -___________г. Предоставление участниками планов-графиков презентаций систем и их согласование с компанией и Банком. Проведение просмотров систем с ___________ г.
Контактная информация
В случае необходимости получения дополнительной информации по всем вопросам, связанным как с порядком проведения данного тендера, так и по предъявляемым функциональным и техническим требованиям, просьба обращаться к _______________ или к ________________ по телефонам _________, _________.
Конфиденциальность
Данное приглашение на участие в тендере, прилагаемое описание функциональных и технических требований к автоматизированной банковской системе, а также иные материалы имеют строго конфиденциальный характер и не должны предоставляться в какой-либо форме третьим сторонам, которые непосредственно не связаны с подготовкой Вами коммерческого предложения.
Кроме того, запрещается сообщать любым третьим лицам каким-либо образом о намерениях Банка относительно выбора АБС, а также распространять любую информацию, предоставленную Банком в связи с этим проектом. Предоставляемая информация также должна носить строго конфиденциальный характер при ее подготовке и передаче Банку, однако в дальнейшем Банк оставляет за собой право использовать предоставленную информацию и распространять ее среди независимых консультантов либо прочих лиц по собственному усмотрению без уведомления Вас о данных фактах.
С уважением, __________________
Анкета участника тендера
Название компании: закрытое акционерное общество X
Название системы: интегрированная банковская система X
Общая информация о фирме
Дата основания компании 1991
Число сотрудников Более 100 человек
Адрес
Представительства и отделения
Количество клиентов
Общая информация об
автоматизированной банковской
системе:
количество имеющихся внедрений223
системы
количество внедрений системы в28
зарубежных банках
техническая платформа (базаИнтегрированная банковская система (ИБС) X разработана на
данных, операционная система,платформе профессиональной реляционной СУБД Progress фирмы
требования к серверам и рабочимPROGRESS SOFTWARE CORPORATION (США), широко применяемой для
станциям) создания сложных высоконадежных прикладных систем корпоративного
уровня в архитектуре клиент/сервер или хост/терминал. В качестве
серверной платформы могут использоваться различные аппаратные
платформы в средах UNIX (Sun Solaris, HP-UX, SCO UnixWare,
DigИTal UNIX, IBM AIX, NCR UNIX SVR4 MP-RAS, и др.), Windows
95/98, Windows NT.
Усредненные требования к центральной ЭВМ с ОС UNIX в зависимости
от количества сотрудников банка, одновременно работающих с ИБС
X:
Характеристики
Количество пользователей
ЭВМ
10
25
50
100 и более***
Тип процессора Celeron
Pentium III
Pentium III Xeon
Pentium III Xeon
Системная архитектура Клиент/сервер или хост/терминал
Иностранные языки ИБС X имеет русскоязычный интерфейс
Системная интеграцияЗАО X выполняет работы по системной интеграции в рамках проекта
(компьютерное оборудование,внедрения ИБС X
сопровождение, телекоммуникации и
т.д.)
Поставка лицензий наФирма X имеет статус Authorized Progress Software International
дополнительное программноеDistribution Affiliate и работает на основе прямых связей с
обеспечение Progress Software Corp. с 1993 года. Специалисты фирмы наряду с
распространением и технической поддержкой программных продуктов,
консультациями и обучением пользователей принимают активное
участие в программах локализации и тестирования новых версий
продуктов Progress
Функциональность
Возможность использованияВозможность использования нескольких планов счетов является
нескольких планов счетов стандартной для ИБС X
Мультивалютность Мультивалютное ядро поддерживает ведение аналитического и
синтетического учета всего спектра операций в соответствии со
всеми главами действующего Плана счетов и Правилами ведения
бухгалтерского учета, руководящих и методических материалов ЦБ
РФ. X позволяет в качестве базовой выбрать любую национальную
валюту
Планы по поддержке МеждународныхВедение аналитического и синтетического учета в соответствии с
стандартов бухгалтерского учета Международными стандартами учета бухгалтерских операций возможно
Ведение бухгалтерского учета вВедение бухгалтерского учета выполняется в соответствии с
соответствии с инструкциями ЦБ РФинструкциями ЦБ РФ
Открытость системы
Возможность импорта данных изВозможность импорта данных из внешних систем существует
внешних систем
Уровень детализации данных приВозможен различный уровень детализации данных при импорте,
импорте (бух. проводки,зависит от типа данных, может быть настроен средствами ИБС X
транзакции, документы, общие
суммы, проч.)
Взаимодействие с внешнимиВзаимодействие с внешними системами, включая платежи, является
системами, включая платежи стандартной возможностью ИБС X
Среднее время внедрения системы сВ соответствии с опытом внедрения системы в банках различного
полными функциональнымимасштаба внедрение ИБС X в банке целесообразно проводить с
возможностями для небольшогоучетом его особенностей. Предварительная оценка сроков внедрения
банка с количеством рабочих местсистемы с полными функциональными возможностями для небольшого
от 40 до 50 банка с количеством рабочих мест от 40 до 50 составляет от 1
месяца до трех.
Перечень работ и услуг на этапе установки и внедрения системы:
предпроектное обследование;
участие в ведении проекта;
установка и настройка системного программного обеспечения;
конфигурирование операционной системы в целях оптимизации работы
СУБД Progress и запуска ИБС X;
установка и настройка СУБД Progress;
установка X; согласование технологических требований к системе;
обеспечение конвертации данных;
настройка параметров системы;
обучение специалистов банка;
организация опытной эксплуатации;
реализация согласованных технологических требований и
дополнительная настройка системы по итогам опытной эксплуатации;
услуги по внедрению при тиражировании системы для объектов
организационной структуры заказчика;
работы в соответствии с индивидуальными требованиями заказчика;
учебные курсы
Сопровождение системы и сервисное
обслуживание после внедрения
системы
Стоимость услуг Услуги по сопровождению:
консультации по телефону горячей линии или e-mail;
модификация программного обеспечения при изменении требований ЦБ
РФ или законодательства;
поставка новых версий программного обеспечения; распространение
изменений по сети Интернет;
право расширения лицензии с зачетом оплаченной стоимости;
другие виды работ по согласованию с заказчиком
Стоимость программного продукта Стоимость программного продукта рассчитывается в зависимости от
конфигурации системы X и планируемого количества одновременно
работающих пользователей. Предварительная оценка стоимости
внедрения системы с полными функциональными возможностями для
небольшого банка с количеством рабочих мест от 40 до 50
составляет_____
Стоимость внедрения Стоимость внедрения зависит от объема работ по внедрению,
выполняемых силами ЗАО X
Стоимость сопровождения иРассчитывается в процентах от стоимости лицензии на ИБС X
сервисного обслуживания
Стоимость дополнительных услугСтоимость дополнительных услуг зависит от объема работ,
(разработка, консультирование,выполняемых силами ЗАО X
обучение)
Предварительный план показа системы
Тема Кол-во
часов
1 Общая архитектура системы 1
технические требования
информационная безопасность
контроль
требования к оборудованию для функционирования АБС
2 Расчетно-кассовое обслуживание 3
ведение расчетных счетов юр. лиц
кассовые операции
денежные переводы физ. лиц
валютно-обменные операции
3 Подготовка отчетов 2
экспорт данных
бухгалтерская и налоговая отчетность
4 Торговые операции 2
5 Кредитное обслуживание 2
6 Операции с пластиковыми карточками 2
7 Взаимодействие с внешними системами 1
SWIFT
банк - клиент
8 Оценка достоверности представленной информации 2
9 Встреча с руководством 1
условия доработки АБС под требования Банка
управление проектом по внедрению АБС
условия поставки и внедрения АБС
ИТОГО: 16
Приложение 5. Соглашение о взаимодействии пользователей и специалистов ИТ (SLA)
Введение
Деятельность (наименование Банка) (далее - Банк) тесно связана с использованием информационных технологий. Основные пользователи информационных технологий - функциональные подразделения компании в лице своих сотрудников. Деятельность ИТ-подразделения направлена на сопровождение работы пользователей информационной системы Банка и оказание всего спектра услуг, относящихся к сфере информационных технологий.
Данный документ определяет принципы взаимодействия сотрудников функциональных подразделений и ИТ-специалистов при возникновении любых вопросов со стороны пользователей в области информационных технологий, которые должны быть удовлетворены специалистами ИТ-подразделения.
Ответственность ИТ-специалистов
Специалисты ИТ-подразделения обеспечивают функционирование информационной системы Банка, а также сопровождают работу пользователей в ней. В обязанности ИТ-подразделения входят все вопросы, связанные с:
- обеспечением общих требований функционирования ИТ, выполнением требований безопасности данных в процессе эксплуатации информационных систем;
- администрированием используемых приложений, сопровождением пользователей при работе с ними;
- техническим обслуживанием и администрированием компьютерного оборудования, а также систем телекоммуникаций;
- разработкой и развитием программного обеспечения для автоматизации деятельности Банка.
ИТ-подразделение является структурным подразделением Банка, задача которого состоит в оказании услуг в сфере информационных технологий (ИТ-услуг) для основных функциональных подразделений. ИТ-специалисты ответственны за своевременное, точное выполнение ИТ-услуг в соответствии с требованиями пользователей (сотрудников иных функциональных подразделений). Для успешного оказания услуг ИТ-специалисты вправе запросить от пользователя необходимую информацию в соответствующей форме.
Классификация ИТ-услуг
Услуги, оказываемые ИТ-подразделением, классифицируются в зависимости от характера работ на следующие группы:
- общие ИТ-услуги;
- прикладные ИТ-услуги.
В свою очередь прикладные ИТ-услуги подразделяются на типовые и специфичные услуги, направленные на развитие информационных систем.
Общие ИТ-услуги
Общие ИТ-услуги относятся к вопросам обеспечения работоспособности всей информационной системы Банка. Связаны с текущей деятельностью ИТ-подразделения, направленной на обеспечение эффективной работы всех сотрудников Банка в информационной системе Банка независимо от характера прикладной задачи. Общие услуги ИТ включают выполнение требований информационной безопасности, направлены на оптимизацию работы информационной системы, общее время функционирования системы, время восстановления ИС в случае сбоя, предотвращение сбоя.
Заказчик
Необходимой предпосылкой для автоматизации деятельности Банка является надежное, бесперебойное, эффективное функционирование информационных систем. Совет директоров заинтересован в обеспечении высокого качества информационных систем Банка и выполняет роль заказчика тех ИТ-услуг, которые необходимы для обеспечения потребностей текущей деятельности при работе с информационной системой.
Основание для исполнения
Совет директоров определяет требования качества информационной системы и утверждает их во внутренних регламентах, положениях об отделах и прочих нормативных документах.
Порядок исполнения
Подразделение ИТ в своей деятельности руководствуется данными документами, самостоятельно разрабатывает мероприятия в области информационных технологий для соответствия утвержденным нормам и ответственно за их соблюдение.
Стандарт качества
Внутренние регламенты определяют принципы обеспечения необходимого качества функционирования информационной системы, ее работоспособности, надежности, безопасности и конфиденциальности данных, а также восстановления системы в случае аварии. В них также определены основные цели, задачи, ответственность ИТ-подразделения за обеспечение работоспособности информационных систем для поддержания основной деятельности Банка. Помимо внутренних регламентов, определяющих принципы функционирования ИС, руководство Банка разрабатывает и утверждает наиболее критичные требования, предъявляемые к качеству ИС Банка: общее время функционирования в боевом режиме, время восстановления работоспособности в случае сбоя и т.п.
Контроль выполнения
Деятельность ИТ-подразделения по обеспечению работоспособности ИС контролируется сотрудниками службы внутреннего контроля на соответствие требованиям совета директоров, сформулированных во внутренних регламентах Банка. В случае несоблюдения общих принципов и/или отклонения от требований качества функционирования ИС ответственность за негативные последствия для основной деятельности Банка лежит на подразделении ИТ.
Типовые ИТ-услуги
Компания ведет перечень наиболее типовых ИТ-услуг, которые могут возникать в процессе работы пользователей. Решение данных вопросов не отвлекает значительных ИТ-ресурсов, ожидаемое качество исполнения является однозначным как со стороны пользователя, так и со стороны ИТ-специалиста.
Заказчик
Запрос на оказание типовой ИТ-услуги может быть создан любым сотрудником Банка. В зависимости от характера решаемой задачи выделяются задачи, инициированные конечным пользователем информационной системы, а также функциональным подразделениям (в лице руководителя).
Основание для выполнения ИТ-услуги
Обращения в службу поддержки пользователей (Help-Desk) является основанием для принятия заявки на рассмотрение со стороны подразделения ИТ. При пользователе заявка регистрируется и определяется типичность запрашиваемой ИТ-услуги.
Порядок исполнения
Оператор службы поддержки пользователей регистрирует факт поступления заявки и классифицирует заявку в зависимости от запрашиваемой услуги (типовая/специфичная) и ее приоритетности для исполнения:
- сразу;
- в течение 1 часа;
- в течение 1 дня.
При необходимости оператор службы Help-Desk связывается с соответствующим специалистом ИТ, ответственным за данное направление работы, который в дальнейшем оказывает необходимую помощь заказчику. Для наиболее критичных участков деятельности порядок исполнения ИТ-услуг регламентируется внутренними процедурами Банка.
Стандарт качества
Стандарт качества типовой услуги согласовывается пользователем и специалистами ИТ на основе ожидаемого качества обслуживания, предоставляемого компетентными и сертифицированными специалистами в соответствующей сфере ИТ.
Контроль выполнения
Заказчик типовой ИТ-услуги оценивает оказанную ИТ-услугу с точки зрения времени исполнения и качества итогового результата. Накопленная информация за период может быть использована для оценки квалификации специалистов ИТ, а также общей эффективности работы подразделения ИТ в Банке. Для наиболее критичных участков деятельности (предоставление прав доступа) служба внутреннего контроля производит периодическую проверку правильности выполненной ИТ-услуги, а также ее соответствие внутренней процедуре исполнения. Критерии, позволяющие разграничить специфичные задачи от типовых, разрабатываются подразделением ИТ и в дальнейшем доступны всем сотрудникам Банка.
Специфичные ИТ-услуги
Специфичные услуги, которые не вписываются в рамки типовых запросов пользователей, требуют дополнительной разработки приложений, структуры баз данных, закупок и т.д. и направлены на развитие информационных систем Банка.
Заказчик
Специфичная ИТ-услуга может инициироваться любым сотрудником Банка. В зависимости от характера решаемой задачи выделяются задачи, инициированные конечным пользователем информационной системы, а также функциональным подразделениям (в лице руководителя). Каждая заявка конечного пользователя, которая относится к категории специфичных услуг, требует визирования руководителем функционального подразделения.
Основание для исполнения
Основанием для выполнения специфичной ИТ-услуги является формальное соглашение между заказчиком услуги и ИТ-подразделением. Соглашение визируется руководителем функционального подразделения, которое заказывает услугу.
Порядок исполнения
Все заявки пользователей (на типовые и специфичные ИТ-услуги) централизованно направляются оператору службы поддержки пользователей. В случае появления запроса на оказание специфичной ИТ-услуги сотрудники ИТ проводят предварительный анализ работы с точки зрения ее объема, требуемых ресурсов, времени выполнения и необходимой дополнительной информации от заказчика. Время рассмотрения заявки зависит от степени срочности, определяемой заказчиком при обращении к оператору службы поддержки пользователей. После анализа запрашиваемой услуги происходит этап согласования работ с заказчиком, в результате которого составляется соглашение между заказчиком ИТ-услуги и ИТ-подразделением, документально закрепляющее объем работы, распределение ответственности, этапы работ и иные вопросы, требующие взаимного согласования.
Стандарт качества
Ожидаемое качество услуги определяется совместно заказчиком и ИТ-специалистами на основе потребностей для пользователя, сложности поставленной задачи, возможностей существующей ИС, а также наличия необходимых ресурсов ИТ-подразделения. В итоговом соглашении фиксируется поэтапный план выполнения работы, ответственность пользователей и ИТ-специалистов, порядок их взаимодействия и иные вопросы.
В целях эффективного управления и контроля за деятельностью ИТ в соглашении определяются следующие параметры:
- время работы первоначально определяется ИТ-подразделением исходя из предварительного анализа запрашиваемой услуги;
- конечный срок работы первоначально определяется заказчиком ИТ-услуги.
- приоритетность работы определяется пользователем на тот случай, если в будущем будут возникать новые задачи и услуги для ИТ-подразделения, которые могут отвлекать ИТ-ресурсы от предыдущих проектов.
Контроль выполнения
По окончании работы заказчик принимает оказанную ИТ-услугу, сверяет на соответствие изначальным требованиям и оценивает деятельность ИТ с точки зрения времени исполнения и качества итогового результата. Данная информация, накопленная за период времени, может быть использована для оценки квалификации специалистов ИТ, а также общей эффективности работы подразделения ИТ в Банке. Все отклонения от первоначальных условий соглашения сообщаются руководству соответствующего уровня для принятия корректирующих мероприятий, связанных с изменением условий соглашения, заказываемой услуги и т.д.
Ответственность пользователей
Успешное функционирование Банка в области ИТ основано также на определенных требованиях, которые предъявляются пользователям для содействия эффективному функционированию ИС Банка. К пользователям ИТ-услуг предъявляются следующие требования:
- соблюдение правил информационной безопасности, а также иных требований специалистов ИТ относительно правил работы в информационной системе;
- владение минимально необходимым уровнем компьютерной грамотности;
- знание основных функциональных возможностях приложений, которые используются в процессе работы (на основе имеющихся пособий для пользователей);
- умение сформулировать и предоставить необходимую и достаточную информацию в соответствующей форме специалистам ИТ;
- содействие ИТ-специалистам в процессе работы в ИС (информирование обо всех выявленных сбоях, компьютерных вирусах и прочих проблемах).
Приложение 6. Перечень эксплуатируемых систем и программ
N/N Система (программа) Тип Отдел Разработчик Обслуживание Платформа
(поставщик)
1 2 3 4 5 6 7
1 HP-UX 10.20 ОС Централизованно Хьюлетт Хьюлетт HP 9000 Е55
Паккард Паккард
2 WINDOWS 95/98 ОС Централизованно Майкрософт Отдел авт. КЛРPC PENTIUM
3 Oracle 7.3.1 DATABASE СУБД Централизованно Оракл Оракл HP 9000 E55,E35
FOR UNIX
4 Oracle 8.0.5 for Win СУБД Централизованно Оракл Оракл HP Netserver
NT 4.0 LH3
5 ISBA BUN 5.6 (Система ПП Централизованно Головной Головной банк HP 9000 E55
упр. банком) банк
6 SWIFT Alliance 4.0 ПП Узел связи СВИФТ СВИФТ HPE50
7 SWIFT Alliance 4.0 ПП Операционный СВИФТ СВИФТ PC PENTUIM
Workstation отдел
8 BANK -CLIENT 3.11 ПП Операционный ИНИСТ ИНИСТ (Москва)PC PENTIUM
(Москва)
9 CARAT/AGORA ПП Бухгалтерия Головной Головной банк PC PENTIUM
банк
10 REFLEXION X СП Централизованно Хьюлетт Отдел авт. КЛРPC PENTIUM
Паккард
11 ROUTERS DEALING 3000 ПП Валютный Ройтерз Ройтерз SUN servers
12 MICROSOFT VISUAL ИР Централизованно Майкрософт Отдел авт. КЛРPC PENTIUM
FOXPRO 6.0
13 MICROSOFT VISUAL ИР Централизованно Майкрософт Отдел авт. КЛРPC PENTIUM
FOXPRO 3.0
14 MICROSOFT ACCESS 97 ИР Руб. платежей Майкрософт Отдел авт. КЛРPC PENTIUM
15 MICROSOFT OFFICE 97 ИР Централизованно Майкрософт Отдел авт. КЛРPC PENTIUM
16 Процессинг руб. ПП Руб. платежей Отдел авт.Отдел авт. КЛРPC PENTIUM
платежей (С.-Пб.) КЛР
17 Процессинг руб. ПП Руб. платежей Отдел авт.От дел авт.PC PENTIUM
платежей (Москва) КЛР КЛР
18 Учет расходов банка ПП Бухгалтерия Отдел авт.Отдел авт. КЛРPC PENTIUM
КЛР
19 Генератор ПП Бухгалтерия Отдел авт.Отдел авт. КЛРPC PENTIUM
счетов-фактур КЛР
20 Сверка счетов ностро ПП Бухгалтерия Отдел авт.Отдел авт. КЛРPC PENTIUM
КЛР
21 База клиентов и ПП Централизованно Отдел авт.Отдел авт. КЛРPC PENTIUM
счетов КЛР
22 Анализ кредитных ПП Кредитный Головной Головной банк PC PENTIUM
рисков (CIA) банк
23 Анализ встреч с ПП Коммерческий Головной Головной банк PC PENTIUM
клиентами (QUICK) отдел банк
24 Обменный пункт ПП Касса Энергомаш- Энергомашбанк PC PENTIUM
банк
25 Учет основных средств ПП Бухгалтерия Монолит Монолит PC PENTIUM
26 Валютная наличность ПП Касса Отдел авт.Отдел авт. КЛРPC PENTIUM
КЛР
27 ТБСВК ИМПОРТ ПП CCU Гос. там.Гос. там.PC PENTIUM
комитет комитет
28 ТБСВК ЭКСПОРТ ПП CCU Гос. там.Гос. там.PC PENTIUM
комитет комитет
29 Анализ имп. операций ПП CCU Отдел авт.Отдел авт. КЛРPC PENTIUM
КЛР
30 Анализ экс. операций ПП CCU Отдел авт.Отдел авт. КЛРPC PENTIUM
КЛР
31 Отчетность по счетам ПП Отд. ценныхИНИСТ ИНИСТ PC PENTIUM
депо бумаг
32 Система пров. сделок ПП Отд. ценныхСмолл Смолл Системз PC PENTIUM
по цен. бум. бумаг Системз
33 База данных анализа ПП Валютный отдел Отдел авт.Отдел авт. КЛРPC PENTIUM
сделок вал. отд. КЛР
Информационно-справо-
чные базы данных
34 Гарант БД Юр. отдел Гарант-сер- Гарант-сервис PC PENTUIM
вис
35 Кодест БД Юр. отдел Кодест Кодест PC PENTUIM
Программы ЦБ России
(Спб)
36 Справочник БИК ПП Руб. отдел ЦБ России ЦБ России PC PENTIUM
37 Ежемесячный баланс ПП Бухгалтерия ЦБ России ЦБ России PC PENTIUM
38 Общая финансовая ПП Бухгалтерия ЦБ России ЦБ России PC PENTIUM
отчетность
39 Обороты по ностро ПП Бухгалтерия ЦБ России ЦБ России PC PENTIUM
(лоро) счетам
40 Отчет по форме N 601 ПП Бухгалтерия ЦБ России ЦБ России PC PENTIUM
41 Ежегодный отчет ПП Бухгалтерия ЦБ России ЦБ России PC PENTIUM
42 Отчет по форме N 215 ПП Бухгалтерия ЦБ России ЦБ России PC PENTIUM
43 Отчет по форме N 301 ПП Бухгалтерия ЦБ России ЦБ России PC PENTIUM
44 Отчет по форме N 302 ПП Бухгалтерия ЦБ России ЦБ России PC PENTIUM
45 Отчет по форме N 401 ПП Бухгалтерия ЦБ России ЦБ России PC PENTIUM
45 Отчет по форме N 711 ПП Бухгалтерия ЦБ России ЦБ России PC PENTIUM
46 Программа контроля ПП Руб. отдел ЦБ России ЦБ России PC PENTIUM
руб. платежей
Программы ЦБ России
(Москва)
47 Справочник БИК ПП Руб. отдел ЦБ России ЦБ России PC PENTIUM
48 Обороты по ностро ПП Бухгалтерия ЦБ России ЦБ России PC PENTIUM
(лоро) счетам
49 Ежемесячный баланс ПП Бухгалтерия ЦБ России ЦБ России PC PENTIUM
(филиал)
50 Генератор формы N 601 ПП Бухгалтерия ЦБ России ЦБ России PC PENTIUM
51 Отчетность для ММВБ ПП Бухгалтерия ЦБ России ЦБ России PC PENTIUM
52 Программа посылки ПП Бухгалтерия ЦБ России ЦБ России PC PENTIUM
руб. платежей
53
54 Генераторы внутр.
отчетов
55 Статистика по ПП Бэк-офис Отдел авт.Отдел авт. КЛРPC PENTIUM
бэк-офису КЛР
56 Отчет по открытой ПП Бухгалтерия Отдел авт.Отдел авт. КЛРPC PENTIUM
вал. позиции КЛР
57 Анализ контрактов по ПП Бухгалтерия Отдел авт.Отдел авт. КЛРPC PENTIUM
об. валюты КЛР
58 Загрузка курсов валют ПП Бухгалтерия Отдел авт.Отдел авт. КЛРPC PENTIUM
КЛР
59 Программы эл. почты
60 S-MAIL (Почта ЦБ) ПП Руб. плат.,ЦБ России ЦБ России PC 486
бухг.
61 Lotus Notes 4.6.1 ПП Централизованно Головной Головной банк PC PENTIUM
(Корпоративная почта) банк
62 MS Exchange 5.0 ПП Централизованно Релком IN-HOUSE PC PENTIUM
Программы доступа в
Интернет
63 MS Proxy 2.0 ПП Централизованно Майкрософт Майкрософт PC PENTIUM
Условные сокращения:
ОС - операционная система;
ПП - прикладная программа;
СП - сервисная программа;
ИР - инструмент разработчика.
Приложение 7. Пример экзаменационных вопросов для ИТ-аудиторов
1. A database administrator is responsible for:
A. maintaining the access security of data residing on the computers.
В. implementing database definition controls.
С. granting access rights to users.
D. defining systems data structure.
2. Which of the following would NOT be associated with well-written and concise job descriptions?
A. They are an important means of discouraging fraudulent acts.
В. They are often used as tools for use in performance evaluation.
С. They provide little indication of the degree of separation of duties.
D. They assist in defining the relationship between various job functions.
3. The input/output control function is responsible for:
A. pulling and returning all tape files.
В. entering and key verifying data.
С. logging batches and reconciling hash totals.
D. executing both production and test jobs.
4. Which of the following tools for controlling input/output of data are used to verify output results and control totals by matching them against the input data and control totals?
A. Batch header forms
В. Batch balancing
С. Data conversion error corrections
D. Access controls over print spools
5. In Wide Area Networks (WANs):
A. data flow can be half duplex or full duplex.
В. communication lines must be dedicated.
С. circuit structure can be operated only over a fixed distance.
D. the selection of communication lines will affect reliability.
6. A feature of a digital signature that ensures that the claimed sender cannot later deny generating and sending the message is:
A. data integrity.
В. authentication.
С. non-repudiation.
D. replay protection.
7. Which of the following factors is LEAST likely to allow a perpetrator to discover a valid password?
A. The number of characters in the password
В. The power of the computer used to break the password code
С. The number of incorrect access attempts allowed before disconnect
D. The content of the character set from which the password is composed
8. Passwords should be:
A. assigned by the security administrator.
В. changed every 30 days at the discretion of the user.
С. reused often to ensure the user does not forget the password.
D. displayed on the screen so that the user can ensure that it has been properly entered.
9. Which of the following is a technique that could illegally capture network user passwords?
A. Encryption
В. Sniffing
С. Spoofing
D. Data destruction
10. Which of the following is NOT an employee security responsibility?
A. Keeping Logon-IDs and passwords secret
В. Helping other employees create passwords
С. Reading and understanding the security policy
D. Questioning unfamiliar people who enter a secured area
11. Which of the following would warranty a quick continuity of operations when the recovery time window is short?
A. A duplicated back-up in an alternate site
В. Duplicated data in a remote site
С. Transfer of data the moment a contingency occurs
D. A manual contingency procedure
12. Which of the following BEST describes the difference between a disaster recovery plan and a business continuity plan?
A. The disaster recovery plan works for natural disasters whereas the business continuity plan works for non-planned operating incidents such as technical failures.
В. The disaster recovery plan works for business process recovery and information systems whereas the business continuity plan works only for information systems.
С. The disaster recovery plan defines all needed actions to restore to normal operation after an un-planned incident whereas the business continuity plan only deals with critical operations needed to continue working after an un-planned incident.
D. The disaster recovery plan is the awareness process for employees whereas the business continuity plan contains the procedures themselves to recover the operation.
13. The use of fourth generation languages (4GLs) should be weighed carefully against using traditional languages because 4GLs:
A. can lack lower level detail commands necessary to perform data intensive operations.
В. cannot be implemented on both the mainframe processors and microcomputers.
С. generally contain complex language subsets which must be used by skilled users.
D. cannot access database records and produce complex Online outputs.
14. Which of the following tools would NOT be used in program debugging during system development?
A. Compiler
В. Memory dump
С. Output analyzer
D. Logic path monitor
15. Which of the following is a management technique that enables organizations to develop strategically important systems faster while reducing development costs and maintaining quality?
A. Function point analysis
В. Critical path methodology
С. Rapid application development
D. Program evaluation review technique
16. Which of the following statements pertaining to program evaluation review technique (PERT) is FALSE?
A. The initial step in designing a PERT network is to define project activities and their relative sequence.
В. An analyst may prepare many diagrams before the PERT network is complete.
С. PERT assumes a perfect knowledge of the times of individual activities.
D. PERT assumes that activities can be started and stopped independently.
17. A tax calculation program maintains several hundred tax rates. The BEST control to ensure that tax rates entered into the program are accurate is:
A. independent review of the transaction listing.
В. programmed edit check to prevent entry of invalid data.
С. programmed reasonableness checks with 20% data entry range.
D. visual verification of data entered by the processing department.
18. Application controls ensure that when inaccurate data is entered into the system, the data is:
A. accepted and processed.
В. accepted and not processed.
С. not accepted and not processed.
D. not accepted and processed.
19. Which of the following BEST describes the purpose or character of an audit charter?
A. An audit charter should be dynamic and change often to coincide with the changing nature of technology and the audit profession.
В. An audit charter should clearly state audits objectives for the delegation of authority for the maintenance and review of internal controls.
С. An audit charter should document the audit procedures designed to achieve the planned audit objectives.
D. An audit charter should outline the overall authority, scope and responsibilities of the audit function.
20. A manufacturing company has implemented a new client/ server system enterprise resource planning (ERP) system. Local branches transmit customer orders to a central manufacturing facility. Which of the following controls would BEST ensure that the orders are accurately entered and the corresponding products produced?
A. Verifying production to customer orders
В. Logging all customer orders in the ERP system
С. Using hash totals in the order transmitting process
D. Approving (production supervisor) orders prior to production
1. A database administrator is responsible for:
The correct answer is:
B. implementing database definition controls.
Explanation:
Implementing database definition controls is one of the critical functions of the database administrator. Maintaining access security of data and granting access rights to users as defined by management is the responsibility of the security administrator. Defining systems data structure in the responsibility of the systems analyst.
Area: Content Area 1
2. Which of the following would NOT be associated with well-written and concise job descriptions?
The correct answer is:
C. They provide little indication of the degree of separation of duties.
Explanation:
Well written and concise job descriptions should provide an indication of the degree of separation of duties within the organization and, in fact, may assist in identifying possible conflicting duties. All other answers are aspects of well-written job descriptions.
Area: Content Area 1
3. The input/output control function is responsible for: The correct answer is:
C. logging batches and reconciling hash totals.
Explanation:
The logging of batches provides input control while the reconciling of hash totals provides output controls.
Area: Content Area 2
4. Which of the following tools for controlling input/output of data are used to verify output results and control totals by matching them against the input data and control totals?
The correct answer is:
B. Batch balancing
Explanation:
Batch balancing is used to verify output results and control totals by matching them against the input data and control totals. This can be performed by the computer program where the control totals were input into the computer with the batch input. Batch header forms control data preparation; data conversion error corrections correct errors that occur due to duplication of transactions and inaccurate data entry; and access controls over print spools prevent reports from being accidentally deleted form print spools or directed to a different printer.
Area: Content Area 2
5. In Wide Area Networks (WANs): The correct answer is:
D. the selection of communication lines will affect reliability.
Explanation:
The selection of communication lines, modems, software, etc. will have a great effect on network reliability. Data flow can be half duplex, full duplex or simplex; communication lines can be dedicated or switched; and the circuit structure can be operated over virtually any distance.
Area: Content Area 2
6. A feature of a digital signature that ensures that the claimed sender cannot later deny generating and sending the message is:
The correct answer is: C. non-repudiation.
Explanation:
All of the above are features of a digital signature. Non-repudiation ensures that the claimed sender cannot later deny generating and sending the message. Data integrity refers to changes in the plaintext message that would result in the recipient failing to compute the same message hash. Authentication ensures that the message has been sent by the claimed sender since only the claimed sender has the key. Replay protection is a method that a recipient can use to check that the message was not intercepted and replayed.
Area: Content Area 3
7. Which of the following factors is LEAST likely to allow a perpetrator to discover a valid password?
The correct answer is:
B. The power of the computer used to break the password code
Explanation:
А, С and D all contribute to the complexity and difficulty of guessing a password.
Area: Content Area 3
8. Passwords should be: The correct answer is:
A. assigned by the security administrator.
Explanation:
Initial password assignment should be done discretely by the security administrator. Passwords should be changed often (e.g. every 30 days).
However, changing is not voluntary and should be forced by the system. Systems should not permit previous passwords(s) to be used again after they are changed. Old passwords may have been compromised and would thus permit unauthorized access. Passwords should not be displayed in any form.
Area: Content Area 3
9. Which of the following is a technique that could illegally capture network user passwords?
The correct answer is: B. Sniffing
Explanation:
Sniffing is an attack that can be illegally used to capture sensitive pieces of information (password), passing through the network. Encryption is a method of scrambling information to prevent unauthorized individuals from understanding the transmission. Spoofing is forging an address and inserting it into a packet to disguise the origin of the communication. Data destruction is erasing information or removing it from their original location.
Area: Content Area 3
10. Which of the following is NOT an employee security responsibility?
The correct answer is:
B. Helping other employees create passwords
Explanation:
Helping other employees create their passwords may materially affect the integrity of the password. That is, the employee giving the advice may later be able to guess the password and gain access to the system. All the other options are employee security responsibilities.
Area: Content Area 3
11. Which of the following would warranty a quick continuity of operations when the recovery time window is short?
The correct answer is:
D. A manual contingency procedure
Explanation:
A quick continuity of operations could be accomplished when manual procedures for a contingency exist. Choices A, B and С are options for recovery.
Area: Content Area 4
12. Which of the following BEST describes the difference between a disaster recovery plan and a business continuity plan?
The correct answer is:
C. The disaster recovery plan defines all needed actions to restore to normal operation after an un-planned incident whereas the business continuity plan only deals with critical operations needed to continue working after an un-planned incident.
Explanation:
The difference pertains to the scope of each plan. A disaster recovery plan recovers all operations, whereas a business continuity plan retrieves business continuity (minimum requirements to provide services to the customers or clients). Choices А, В and D are incorrect because the type of plan (recovery or continuity) is independent from the sort of disaster or process and it includes both awareness campaigns and procedures.
Area: Content Area 4
13. The use of fourth generation languages (4GLs) should be weighed carefully against using traditional languages because 4GLs:
The correct answer is:
A. can lack lower level detail commands necessary to perform data intensive operations.
Explanation:
All of the answers are advantages of using 4GLs except that they can lack lower level detail commands necessary to perform data intensive operations. These operations are usually required when developing major applications.
Area: Content Area 5
14. Which of the following tools would NOT be used in program debugging during system development?
The correct answer is: A. Compiler
Explanation:
Debugging tools are programs that assist a programmer to fine-tune or debug the program under development. Compilers have some potential to provide feedback to a programmer but are not considered debugging tools. Debugging tools fall into three main categories; logic path monitors, memory dumps, and output analyzers.
Area: Content Area 5
15. Which of the following is a management technique that enables organizations to develop strategically important systems faster while reducing development costs and maintaining quality?
The correct answer is:
C. Rapid application development
Explanation:
Rapid application development is a management technique that enables organizations to develop strategically important systems faster while reducing development costs and maintaining quality. PERT and critical path methodology are both planning and control techniques, while function point analysis is used for estimating the complexity of developing business applications.
Area: Content Area 5
16. Which of the following statements pertaining to program evaluation review technique (PERT) is FALSE?
The correct answer is:
C. PERT assumes a perfect knowledge of the times of individual activities.
Explanation:
PERT assumes an imperfect knowledge of the times of individual activities and therefore incorporates a level of uncertainty in the estimation of such times. All other answers are true of PERT.
Area: Content Area 6
17. A tax calculation program maintains several hundred tax rates. The BEST control to ensure that tax rates entered into the program are accurate is:
The correct answer is:
A. independent review of the transaction listing.
Explanation:
Tax tables represent sensitive data that will be used in numerous calculations and should be independently visually verified by a senior person before they are used in processing. Choices В and С are programmed controls that are useful for preventing gross errors. That is, errors such as an added zero or alpha instead of a numeric. A tax table must be exactly accurate, not just readable. Choice D will allow the data entry person to check input accuracy, but it is not sufficient.
Area: Content Area 6
18. Application controls ensure that when inaccurate data is entered into the system, the data is:
The correct answer is:
C. not accepted and not processed. Explanation:
Application controls ensure that only complete, accurate and valid data are entered and updated in a system. Area: Content Area 6
19. Which of the following BEST describes the purpose or character of an audit charter?
The correct answer is:
D. An audit charter should outline the overall authority, scope and responsibilities of the audit function.
Explanation:
An audit charter should clearly state managements objectives for, and delegation of authority to IS Audit. This charter should not change much over time and should be approved at the highest level of management. The audit charter is not so detailed as to include specific audit objectives.
Area: Process Area 7
20. A manufacturing company has implemented a new client/ server system enterprise resource planning (ERP) system. Local branches transmit customer orders to a central manufacturing facility. Which of the following controls would BEST ensure that the orders are accurately entered and the corresponding products produced?
The correct answer is:
A. Verifying production to customer orders
Explanation:
Verification will ensure that production orders match customer orders. Logging can be used to detect inaccuracies, but does not in itself guarantee accurate processing. Hash totals will ensure accurate order transmission, but not accurate processing centrally. Production supervisory approval is a time consuming manual process that does not guarantee proper control.
Area: Process Area 7
Приложение 8. Пример бизнес-схем в стандарте IDEF0
Схема 1
Схема 2
Схема 3
Схема 4
Словарь терминов
Abend (аварийное завершение) Аварийное завершение работы программы из-за программной или аппаратной
ошибки
Access Method (метод доступа) Способ поиска для чтения и записи данных в место их постоянного или
временного хранения
Address (адрес) Код, используемый для определения нахождения данных в информационной
системе
Address Space (адресноеРазмер области, множество значений адресов в ней, которая может
пространство) осуществлять хранение данных
Addressing (адресация) Метод, используемый для идентификации области элемента в сети. В идеале
адресация показывает, где находится элемент и как к нему добраться
Administrative ControlsКонтроль деятельности в строгом соответствии с политикой управления
(административный контроль) организации
ALPHA (процессор Alpha) 64-разрядный RISC процессор, разработанный корпорацией Digital Equipment
(процессор Alpha 21064). Первый процессор в мире, пересекший планку
тактовой частоты 1 ГГц (см. также CPU)
Anonymous File Transfer ProtocolМетод, предоставляющий пользователю возможность поиска и переписывания
(анонимный FTP) файлов в Интернет с помощью протокола FTP. Когда к FTP-серверу
подключается незарегистрированный пользователь, чтобы получить доступ к
файлам (как правило, только для чтения), он вводит вместо своего имени
слово anonymous, а вместо пароля - адрес своей электронной почты
Applet (аплет, приложение) Программа на языке Java, которая может быть встроена в HTML-страницы и
выполнена браузером. Передается из сети Интернет вместе с документом как
присоединение для его надлежащего представления у пользователя. Аплеты
отличаются от полных Java-приложений тем, что имеют ограничения по доступу
к определенным ресурсам локального компьютера и запрет коммуникаций с
другими компьютерами в сети (кроме того, с которого данный аплет послан)
Application Layer (уровеньВерхний уровень сетевой модели OSI. Определяется множеством протоколов,
приложений) используемых различными сетевыми приложениями для решения их задач
Application ProgramПрограмма, которая работает с бизнес-информацией: преобразует ее и
(бизнес-приложение) представляет в нужной форме для дальнейшего использования. Другими
видами компьютерных программ являются операционные системы, программы
управления сетями
Application Program (приложение,Законченная прикладная программа или пакет, которые обеспечивают
прикладная программа) пользователю решение определенной задачи, например электронная таблица
или текстовый процессор
Application ProgrammingПроцесс разработки бизнес-приложения для дальнейшего использования
(программирование
бизнес-приложений)
Application Tracing and MappingСпециализированный инструментарий для анализа потока данных внутри
(трассировка приложения) приложения
Artificial IntelligenceНаправление научных исследований и понятие, используемое в связи с
(искусственный интеллект) экспертными системами, автоматическим доказательством теорем,
распознаванием образов, машинным зрением, робототехникой, пониманием
естественных языков и др. Термин введен Джоном Маккарти (John McCarthy)
летом 1956 г. вместо предложенного в 1950 г. Аланом Тьюрингом термина
computer intelligence network
Artificial IntelligentСпециальная компьютерная система, которая может эмулировать человеческое
(искусственный интеллект) поведение, выполняя такие функции, как анализ, основанный на
предопределенных правилах
ASCII, American Standard Code forНабор из 128 кодов символов для машинного представления прописных и
Information Interchangeстрочных букв латинского алфавита, чисел, знаков препинания и специальных
(американский стандартный код длясимволов, каждому из которых соответствует конкретное 7-битовое двоичное
обмена информацией, код ASCII) число. Первые 32 символа этого кода являются управляющими (такими, как
символы перевод строки, возврат каретки) и не могут быть распечатаны в
текстовом виде. Восьмой бит при передаче данных может использоваться для
контроля четности. Введение стандартных кодов позволило упростить обмен
данными между различными компьютерными системами
Assembler (Ассемблер) Программа, которая преобразует текст, написанный на языке Ассемблер, в
исполняемые машинные коды
Assembly Language (язык Ассемблер) Язык программирования низкого уровня, описывающий инструкции процессора
системы
Asymmetric Key (асимметричныйТехника шифрования, в которой для шифровки и дешифровки используются
ключ) разные ключи
Asynchronous Transfer ModeТехнология высокоскоростной одновременной передачи данных (трафика) всех
(асинхронный режим передачи) видов (данные, голос и видео) в сетях с коммутируемыми каналами; стандарт
на коммутируемые сети, утвержденный МККТТ в 1985 г. Протокол ориентирован
на соединения: любой передаче данных предшествует организация виртуального
соединения (коммутируемого или постоянного) между отправителем и
получателем данных, что упрощает процедуры маршрутизации
Asynchronous TransmissionМетод передачи данных, в котором каждый знак передается с предшествующим
(асинхронная передача) стартовым битом (start bit) и последующим стоповым битом (stop bit),
позволяя таким образом передавать знаки через нерегулярные интервалы
времени между ними
Attribute Sampling (выборкаТехника аудита, заключающаяся в выборке элементов из множества,
атрибутов) определенного для контроля, основанная на анализе элементов, имеющих
одинаковые значения атрибутов или характеристик (например, элементы,
имеющие размер, больший определенного)
Audit Evidence (аудиторскиеИнформация, используемая аудитором информационных систем для анализа
доказательства) объектов аудита и выработки мнения
Audit Objective (цель аудита) Определенная цель аудита. Обычно определяется как контроль за снижением
бизнес-рисков
Audit Program (аудит программ) Пошаговый анализ процедур и инструкций, используемых в процессе
Audit Risk (риск аудита) Риск, заключающийся в том, что информационные или финансовые отчеты
могут содержать ошибку или аудитор информационной системы может не
заметить произошедшую ошибку. Также используется для описания степени
риска того, что аудитор отнесется к своим обязанностям необъективно
Audit Trail (аудиторский след) Записи о транзакциях, выполняемых в системе. Позволяет установить
хронологию событий при анализе инцидента
Automated Teller MachineАвтоматическое устройство обслуживания розничных клиентов банка. Через
(банкомат) банкомат клиент может внести депозит, получать наличность, управлять
счетами
Bandwidth (полоса пропускания,Диапазон частот - разность, выраженная в герцах, между самой высокой и
ширина полосы пропускания) самой низкой частотами в диапазоне частот передающего канала. Аналоговая
передача сигнала по телефонной линии занимает диапазон от 300 Гц до 3,4
кГц. Цифровой сигнал требует большего диапазона частот. Чем выше скорость
передачи, тем больший диапазон частот требуется. Этим термином все чаще
обозначается верхняя граница скорости передачи данных по компьютерной сети
- разность, выраженная в герцах, между самой высокой и самой низкой
частотами в диапазоне частот передающего канала
Bar Code (штриховой код) Специальный код, в котором каждый знак состоит из вертикальных темных и
светлых полос разной ширины, печатаемый на упаковке товаров для
автоматизированного ввода данных о них. Каждая группа линий штрихового
кода представляет собой цифру от 0 до 9. Имеются несколько систем
штрихового кодирования (EAN, UPC). Существуют круговые штриховые коды,
которые можно считывать в любом направлении
Base Case (базовые условия) Стандартизованные данные для тестирования системы. Обычно для
тестирования пользователи определяют их в качестве входа для системы и
проверяют правильность выходящих данных
Baseband (монополосная передача) Среда передачи, через которую цифровые или аналоговые сигналы посылаются
без сдвига частоты. В общем случае в каждый момент времени доступен
только один коммуникационный канал
Batch Control (пакетный контроль) Встроенный в информационную систему механизм контроля данных, поступающих
в пакетную обработку. Существуют два типа пакетного контроля: 1.
Последовательный контроль, который осуществляет проверку каждой входящей
записи. 2. Общий контроль, осуществляющий проверку итоговых показателей
входящего потока
Batch Processing (пакетнаяОбработка группы транзакций в одно время - пакетный режим
обработка)
Benchmark (бенчмарк) Тест для определения производительности системы. В данном тесте
проводится поэтапное тестирование отельных составляющих системы с
последующим сравнением полученных показателей от других систем или
эталонов. Иногда используется в более широком значении - сравнение с
передовой практикой
Benchmark (эталонный тест) Тестовая программа или пакет для оценки производительности компьютера,
системы или конкретного устройства. Для оценки показателя используются
сравнения с эталонным устройством
Binary Code (двоичный код) Код в виде последовательности нулей и единиц
Black Box Testing (тестированиеМетодика тестирования, заключающаяся в тестировании входов и выходов
черный ящик) системы без анализа внутренних составляющих
Bridge (мост) Аппаратно-программное устройство, соединяющее две или более физически
разъединенные локальные сети
Broadband (широкополосная передача)Передающая среда, через которую может проходить широкий диапазон частот.
Она делится на несколько независимых узкополосных каналов (каждый из них
работает в своем диапазоне частот) для одновременной передачи сигналов
Buffer (буфер) Область памяти для временного хранения данных. Служит для ускорения
операций пересылки данных или ввода-вывода, например при печати,
чтении/записи с диска и т.д. В телекоммуникации используется для
компенсации разницы между сетевыми устройствами в скорости обработки
Bus (шина) Общий канал передачи данных. Может являться частью компьютера и
соединять его элементы или быть каналом связи между компьютерами
Bus Topology (шинная топология) Топология локальной сети, в которой все абоненты линейно подключаются к
одной магистрали передачи данных. Широко применялась в сетях Ethernet
Business Impact Analysis BIAПроцесс, определяющий, например, зависимость потери на поддержку системы
(анализ бизнес-влияния) от различных ресурсов. Он позволяет руководителю анализировать степень
использования ресурсов в различных процессах и избегать простаивания и
переработки ресурсов
Business Process Re-engineering,Современная методика для развития организационной структуры с
BPR (реинжинирингиспользованием средств информационных технологий. Цель BPR - оптимизация
бизнес-процессов) производственной структуры, развитие ее связи с клиентской базой и
рыночными условиями, а также минимизация расходов. Реинжиниринг
подразумевает под собой создание абсолютно новой архитектуры исходя из
конечных требований и возможностей
Business Risk (бизнес-риск) Риск, который может иметь место при организации бизнеса или оперативной
работе. Данный риск имеет следующую классификацию: финансовые риски,
риски регулирования и риски контроля (Control Risk)
Capacity Stress TestingТестирование системы в случае больших объемов данных с имитацией пиковой
(тестирование с максимальнойнагрузки
нагрузкой)
Central Processing UnitЧасть компьютера, непосредственно выполняющая машинные команды, из
(центральный процессор, ЦПУ) которых состоят программы. Содержит регистровый файл (register file),
устройство управления памятью (MMU), арифметико-логическое устройство
(ALU) и другие блоки
Centralized Data ProcessingОснована на выделении одного процессора и базы данных для обеспечения
(централизованная обработкауправления информационной системой
данных)
Check Digit (контрольная сумма) Математически рассчитанная величина на основании контролируемого потока
данных. Используется для проверки идентичности входящего и исходящего
потоков данных
Check Digit Verification (проверкаПроцесс выполнения программы проверки потока данных с использованием
контрольной суммы) контрольной суммы
Ciphertext (зашифрованный текст) Окончательно зашифрованное секретное сообщение
Circuit-switched NetworkВид связи, при котором по запросу пользователя на физическом уровне
(коммутируемая сеть) устанавливается временное соединение с требуемой точкой и данному
соединению на все время связи выделяется фиксированная полоса
пропускания
Client/Server (клиент-сервер) Модель построения распределенной вычислительной среды, в которой
интерфейсная часть задачи выполняется на машине пользователя, а
требующая больших ресурсов обработка запросов осуществляется одним или
несколькими серверами
Cluster (кластер) Многомашинная вычислительная система, представляющая совокупность
относительно автономных систем с общей дисковой памятью (общей файловой
системой), средствами межмашинного взаимодействия и поддержания
целостности баз данных
Coaxial Cable (коаксиальный кабель)Тип кабеля, используемого в компьютерных сетях. Кабель состоит из медной
жилы (core), окружающей ее изоляции (insulation layer), экрана (shield)
в виде металлической оплетки и внешней оболочки
Communications ControllerУстройство, используемое для соединения и управления связью между
(коммуникационный контроллер) удаленными устройствами и главным компьютером
Comparison Program (методМетод проверки, включающий в себя логические тесты для определения
сравнения) сходства и различий
Compensating ControlМеханизм внутреннего контроля, направленный на компенсацию ущерба от
(компенсационный контроль) существующих рисков и минимизацию потерь от исключительных ситуаций
Compiler (компилятор) Программа, преобразующая текст, написанный на языке программирования, в
исполняемые машинные коды. Выполняет трансляцию исходного текста
разрабатываемой программы с языка программирования высокого уровня в
эквивалентную программу на целевом языке
Completeness Check (проверкаПроцедура, контролирующая, что вся информация корректно отображена в
полноты) записи
Compliance Testing (тестированиеТесты, направленные на контроль исполняемое... внутренних инструкций
соответствия) организации. Данный тип контроля используется в случае, если основные
механизмы контроля, определенные инструкциями, работают эффективно
Computer Aided SoftwareПрограммные продукты, обеспечивающие разработку приложений на всех
Engineering CASE (Case-средства,стадиях, включая системный анализ, кодирование и разработку документации
автоматизированные средства
программирования)
Computer Assisted Audit TechniqueНабор программных решений, используемых для аудита, таких, как
CAAT (автоматизированныеавтоматическая формирование отчетов, генерация тестовых данных и прочие
механизмы аудита) утилиты для автоматизированного аудита
Console Log (журнал консоли) Детальный автоматический отчет о действиях компьютерной системы
Continuous Auditing ApproachДанный подход обеспечивает аудитора информационной системы
(непрерывный аудит) продолжительным мониторингом состояния системы и сбором статистических
данных с использованием вычислительной техники
Control Group (группа контроля) Участники процесса, в обязанности которых входит контроль за
деятельностью других пользователей в рамках информационной системы
Control Risk (риски контроля) Риск, определяемый вероятностью пропуска сбоя в работе системы или
задержки в его регистрации
Corporate GovernanceСистема управления и контроля организации. Включает в себя свод
(корпоративное управление) инструкций и регламентов, определяющий основные принципы управления.
Определяется советом директоров
Corrective Control (корректирующийМеханизм внутреннего контроля, направленный на корректировку системы в
контроль) случае возникновения исключительной ситуации
Data Communications (передачаОбмен данными между компьютером и другими устройствами
данных)
Data Dictionary (словарь данных) Список всех файлов, полей и переменных, используемых в конкретной СУБД.
Позволяет определить, как были заданы те или иные элементы. Набор
описаний данных, который может использоваться несколькими приложениями
Data Structure (структура данных) Описание связей между записями и данными в базе данных
Database (база данных) Набор таблиц, представляющих собой организованный перечень записей и
связанных с ними вспомогательных файлов
Database AdministratorСотрудник или отдел, в обязанности которого входят управление системой
(администратор базы данных) безопасности и доступом к базе данных, а также разработка, настройка и
поддержка работоспособности базы данных
Database Management SystemПриложение, обеспечивающее создание, хранение, обновление и поиск
(система управления базами данных,информации в базе данных, а также управление безопасностью и
СУБД) целостностью данных
Database Replication (репликацияМеханизм асинхронного внесения изменений во вторичные БД непосредственно
базы данных) после завершения транзакции по мере доступности серверной или клиентской
БД. Метод предполагает промежуточное хранение транзакций. Обеспечивает
синхронизацию фрагментов распределенной базы данных
Database SpecificationsСписок требования к базе данных, включающий в себя описание таблиц и
(спецификация базы данных) полей
Decentralization (децентрализация)Процесс разнесения выполнения задач по различным областям или функций
системы по различным локальным системам внутри организации
Decision Support Systems, DSSПрограммное обеспечение, помогающее при принятии решений, автоматизируя
(системы поддержки принятияэтот процесс
решений)
Demodulation (демодуляция) Процесс преобразования аналогового сигнала в цифровой компьютерный
сигнал
Detective control (мониторинг) Система контроля, направленная на выявление нестандартных ситуаций.
Формирует сообщение об ошибке в случае возникновения нестандартной
ситуации
Discovery Sampling (отборОтбор элементов исследуемого множества по принципу различия значения
образцов) ключевого атрибута
Distributed Data ProcessingКомпьютерная система, в которой обработка выполняется несколькими
Network (распределенная обработка)компьютерами, подсоединенными к локальной или телекоммуникационной сети.
Часто имеется в виду любая компьютерная система, в которой каждый
компьютер решает свою задачу, а сеть поддерживает функционирование системы
как единого целого
Down Time (простой, времяИнтервал времени, в течение которого компьютерная система или сеть не
бездействия) используется из-за неисправности оборудования или его обслуживания
Down Time Report (отчет оОтчет, который показывает время ошибки системы по причине сбоя
системных ошибках) вычислительной техники
Downloading (загрузка) Пересылка файла по компьютерной сети из удаленного компьютера в ваш
компьютер. В более общем случае пересылка информации из одного
устройства в другое
Dumb Terminal (простой терминал) Алфавитно-цифровой терминал без собственных средств редактирования
текстов и управления экраном
Echo Checks (контроль эха) Мониторинг ошибок линии связи путем возврата данных обратно передатчику
и сравнения передаваемого и возвращенного потока
Edit Controls (контрольКонтроль ввода и редактирования данных на основании определенных ранее
редактирования) правил
Editing (редактирование) Создание, добавление, изменение текстового документа, графического или
мультимедийного объекта, компоновка, связывание различных объектов
Electronic Cash (электронныеЭлектронный эквивалент электронных денег. Служит для расчетов в
деньги) кибербанках
Electronic Data InterchangeНабор стандартов для пересылки финансовых документов по
(электронный обмен данными) телекоммуникационным сетям
Electronic Funds TransferПеревод средств между двумя счетами с использованием
(электронный платеж) телекоммуникационных средств
E-mail/Interpersonal messagingПерсональный терминал, компьютер или программа, позволяющие посылать
(система персональных сообщений) неструктурированные сообщения одному или нескольким лицам
Embedded Audit Modules (встроенныеЭлементы информационной системы, выполняющие функции аудита
модули аудита)
Encapsulation (инкапсуляция) Скрытие внутренней структуры данных и реализации методов объекта от
остальной программы. Доступен только интерфейс объекта, через который
осуществляется взаимодействие с ним
End-user-Computing (гибкийИнтерфейс, позволяющий конечному пользователю самостоятельно вести
пользовательский интерфейс) доработку системы, используя имеющиеся в системе инструменты
Ethernet (сеть Ethernet) Популярный протокол сети с шинной архитектурой, регламентирует в
качестве передающей среды коаксиальный кабель и метод управления
доступом CSMA/CD
Exception Reports (отчет обФормируемый в случае исключительной ситуации отчет, содержащий
ошибках) идентификатор ошибочной транзакции или неправильно обработанных данных
Executable Code (исполнимый код) Общее название для программы в том или ином виде, которая может быть
выполнена процессором
Expert Systems (экспертнаяСистема, использующая базу знаний (правил) для решения задач (выдачу
система, ЭС) рекомендаций) в некоторой предметной области, например в медицине,
диагностике неисправностей и др. ЭС - одно из направлений искусственного
интеллекта
Exposure (регистрация нарушения) Результат мониторинга или анализа системы, заключающийся в выявлении
нерегламентированных событий в системе. Мощный внутренний контроль
системы помогает избежать данных нарушений
Feasibility Study (стадияФаза жизненного цикла разработки приложения, заключающаяся в анализе
первичного анализа) необходимости системы, имеющихся ресурсов и преимуществ, которые даст
система пользователям
Fiber Optic CableКабель с высокой пропускной способностью для передачи световых сигналов.
(волоконно-оптический кабель) Состоит из множества тонких нитей, изготовленных из прозрачного
материала
Field (поле) Простейший элемент записи в базе данных. Примером поля являются: имя
клиента, количество, сумма сделки и т.д.
File (файл) Поименованное множество связанных записей
File Server (файловый сервер) Тип сервера, который хранит в личных и разделяемых каталогах файлы
пользователей локальной сети. Использование файл-сервера облегчает
администрирование системы и уменьшает потребность в дисковой памяти
Financial Audit (финансовый аудит) Аудит правильности финансовых записей в системе
Firewall (межсетевой экран,Система (аппаратная или программная) или комбинация систем, образующая в
брандмауэр) целях защиты границу между двумя или более сетями, предохраняя от
несанкционированного попадания в сеть или предупреждая выход из нее
пакетов данных. Используется также для разграничения доступа внутри
корпоративной сети при наличии в ней участков с информацией, требующей
конфиденциальности
Format Checking (контроль формата) Функция приложения, которая контролирует соответствие вводимых данных
предопределенному формату
Fourth Generation LanguageПохожие на естественный английский язык, понятные пользователю
4ОL (языки четвертого поколения) непроцедурные языки программирования
Frame-relay (ретрансляция кадров,Технология для высокоскоростной передачи кадров или пакетов. Действует на
протокол сети Frame Relay) канальном уровне модели OSI, поддерживает несколько виртуальных соединений
на один физический порт. Для управления потоком данных используется
механизм уведомлений о приближении к состоянию насыщения: в направлении,
противоположном затору, посылается сообщение BECN, а принимающей стороне
посылается сообщение FECN
Fraud Risk (риск мошенничества) Риск того, что будет проведена удачная попытка преднамеренного обмана
FTP Протокол передачи файлов
Full Duplex (двусторонняя связь) Режим связи, когда передача данных между двумя станциями идет
одновременно в обоих направлениях
Function Point Analysis (анализТехника, используемая для оценки объема затрат на разработку, базируемая
ключевых параметров функции) на анализе ключевых параметров функции. Параметры функции включают в
себя такие факторы, как вход, выход, запросы к данным, внутреннюю
структуру функции и т.д.
Gateway (шлюз, межсетевой шлюз) Сетевое устройство или компьютер, осуществляющие связь между двумя
различными (использующими разные коммуникационные протоколы)
компьютерными сетями или мэйнфреймом и сетью. Кроме передачи данных,
могут выполнять их фильтрацию. Функционально шлюзы относятся к
канальному уровню эталонной модели OSI
General Computer Control (общийОсновные механизмы контроля в информационных системах, используемые для
автоматизированный контроль) всех приложений системы
Generalized Audit Software (общийКонтроль и анализ работы программного обеспечения информационной системы
аудит программного обеспечения) с целью выявления нерегламентированных действий. Примером могут
являться: анализ записей системы, контроль отчетов, параллельные расчеты
Half Duplex (полусумматор) Складывает две двоичные цифры и выдает сигнал переноса, однако не
прибавляет к сумме возможный разряд переноса от предыдущего
суммирования. Чтобы учесть этот разряд, ставится второй полусумматор
Hardware (аппаратная составляющаяТехнические и физические компоненты информационной системы
системы)
Hardware (аппаратные средства,Общее обозначение совокупности физических устройств компьютера или
аппаратура, оборудование) отдельных его частей, включая периферию, в отличие от программ и данных
Hexadecimal (шестнадцатеричнаяПредставление чисел в системе счисления с основанием 16 (цифры 0-9 и А,
система счисления) В, С, D, Е, F);
Hierarchical DatabaseОдна из основных архитектур баз данных, имеющая древовидную структуру и
(иерархическая СУБД) связь между родительскими и порожденными объектами. При этом каждый
порожденный объект имеет одного родителя, но каждый родитель может иметь
несколько дочерних объектов
Image Processing (обработкаЛюбые комплексные операции по компьютерной обработке изображений
изображений)
Incremental TestingМетодика тестирования, заключающаяся в тестировании только нового
(дополнительное тестирование) функционала системы
Information engineeringИнформационноориентированная техника разработки систем, основанная на
(информационный инжиниринг) понятии того, что данные являются центром информационной системы, с
которым связаны все остальные механизмы преобразования данных и
управления информационными потоками
Information processing facilityПомещения, в котором располагаются аппаратные составляющие
IPF (место размещения) информационной системы
Inheritance(Objects) Механизм, позволяющий объявить новый (производный) класс на основе уже
(наследование) существующего класса. Наследование отражает строгую иерархию классов в
объектно-ориентированном программировании. Наследование подразумевает
использование объектами наследуемого класса данных и методов
родительского класса
Input Controls (контроль ввода) Процедуры, используемые для проверки правильности ввода данных в
программу
Integrated test facilities ITFДанные для тестирования, формируемые самой системой. Как правило,
(интегрированная средатестовые данные представляются различными бизнес-объектами, такими, как
тестирования) клиенты, продукты, подразделения. Формируемые в рамках ITF отчеты
подтверждают или опровергают корректную работу системы
Intelligent Terminal (активныйТерминал со встроенным процессором. Не имеет диска для хранения данных,
терминал) но имеет объем оперативной памяти. Терминал сам обрабатывает данные,
вводимые пользователем
Interface Testing (тестированиеМетодика тестирования, используемая для контроля взаимодействия системы
интерфейса) с другими приложениями или пользователями
Internal Control (внутреннийВнутренние регламенты, процедуры, практика и организационная структура,
контроль) направленные на обеспечение безопасности выполнения всех процессов
организации
Irregularities (нарушение) Исключительная ситуация в работе, приводящая к нерегламентированному
состоянию информационной системы
Job Control Language (JCL) (языкСпециализированный язык, используемый для контроля выполнения запуска
управления работ) процедур
Leased Lines (арендованная частнаяВысокоскоростная магистраль либо телефонная линия, круглосуточно
линия) обслуживающая только конкретного пользователя
Librarian (библиотекарь) Сотрудник, в чьи обязанности входит хранение всех программ и файлов данных
Limit Check (контроль лимита) Тест, проводящий сравнение значения переменной информационной системы с
заранее определенной величиной, лимитом
Local Area Network (LAN)Один из нескольких видов географически ограниченных коммуникационных
(локальная сеть, ЛВС) сетей. ЛВС соединяет компьютеры, принтеры и другое электронное
оборудование, позволяя с высокой скоростью обмениваться различного вида
информацией и совместно использовать общие для сети ресурсы. Расстояние
между компьютерами в ЛВС, как правило, не более 300 м. Локальные сети
могут иметь шлюзы в коммутируемые сети общего пользования или другие
локальные сети
Log (журнал) Записи событий информационной системы, которые требуют дополнительного
контроля
Logoff (выход из системы) Процедура выхода пользователя из компьютерной системы или ЛВС
Logon (регистрация в системе) Процедура идентификации пользователя при вхождении в компьютерную систему
(сеть)
Machine Language (машинный язык) Набор инструкций (машинных команд), которые компьютер может выполнять
непосредственно. Инструкции записываются в двоичном или шестнадцатеричном
коде. Программы, написанные на языках высокого уровня, перед их
исполнением процессором транслируются в машинные команды
Magnetic Card Reader (магнитнаяКарта с нанесенной на ее поверхность одной или несколькими магнитными
карта) полосами, на которые могут быть записаны и считаны данные
Management Information SystemСистема, обеспечивающая доступ к структурированной информации об имеющихся
MIS (информационная системаресурсах, управляемых процессах и информационных потоках
управления)
Memory Dump (дамп памяти) Процесс копирования информации, записанной в некоторой области оперативной
памяти на магнитный (постоянный) носитель с сохранением всех адресов. Как
правило, осуществляется при возникновении фатальной ошибки и используется
для ее анализа
Message Switching (буферизацияМеханизм, используемый при передачи сообщений, в соответствии с которым
сообщений) сообщения концентрируются в некоторой точке до тех пор, пока не будет
установлена связь с получателем
Middleware (межплатформенное ПО,Программное обеспечение, обеспечивающее прозрачную работу приложений в
связующее ПО) неоднородной сетевой среде. Предоставляет услуги (API) по объединению
частей приложения, распределенных по разным машинам сети. Основные типы
связующего ПО: вызов удаленных процедур; передачи сообщений; посредники
запросов к объектам
Modem (Modulator-Demodulator)Устройство, преобразующее цифровые сигналы в аналоговые аудиосигналы,
(модем) которые оно передает (и принимает) по телефонным линиям связи другим
компьютерам. Для передачи информации об адресате вызова модемы используют
некоторый набор команд, обычно Hayes-совместимый
Modulation (модуляция) Процесс изменения характеристики несущего волнового сигнала с целью
передачи информации. Для модуляции обычно используются амплитуда, фаза или
частота сигнала
Monetary Unit Sampling (примерыМножество объектов, приводящих к изменению бухгалтерского учета с целью
платежных инструкций) контроля нарушения условий движения средств
Multiplexing (мультиплексирование,Передача по одному физическому каналу данных нескольких устройств методом
уплотнение) временного или частотного его разделения на подканалы
Multiplexor (мультиплексор) Устройство, позволяющее пересылать по одному выходному физическому каналу
одновременно сигналы с нескольких входных линий. На другой стороне
мультиплексированного канала ставится демультиплексор
Network (вычислительная,Оборудование и среда передачи данных, в качестве которой может
компьютерная сеть) использовать совокупность рабочих станций, соединенных между собой с
помощью сетевого кабеля, телефонных линий или беспроводной связи.
Предназначена для совместного использования вычислительных ресурсов,
периферийных устройств, приложений и данных. Сети классифицируются по
географическому признаку (локальные, городские, региональные, глобальные),
топологии, передающей среде и т.д.
Network administratorСотрудник, в чьи обязанности входят управление локальной сетью, добавление
(администратор сети) рабочих станций и сетевой периферии, авторизация пользователей, процедуры
архивации и восстановления файлов и многое другое
Node (узел сети) Устройство, подключенное к компьютерной сети (компьютер, принтер и т.д.),
имеющее сетевой адрес, иногда - точка присоединения к ЛВС
Noise (искажение, шум) Множество колебаний различных частот, накладывающихся на передаваемый
сигнал. Различают низкочастотные шумы (EMI) и радиочастотные шумы (RFI).
Существует множество источников шумов, таких, как генераторы, промышленное
оборудование, включение электропитания и др. Шумы могут вызвать сбои в
работе программ
Normalization (нормализация) Удаление избыточности данных
Normalization (нормализация) Методы группирования данных в реляционных СУБД, позволяющие не хранить
повторяющиеся группы данных и избежать избыточности данных. Широко
используются пять нормальных форм
Object Code (объектный код,Код программы, полученный в результате трансляции компилятором или
объектная программа) ассемблером ее исходного текста. Обычно для получения исполняемой
программы требуется последующая компоновка объектных модулей с
подпрограммами из библиотек компилятора. Под этим термином часто
понимается машинный код, который непосредственно может быть выполнен
процессором
Objectivity (объективность) Способность беспристрастно выражать мнение и предоставлять рекомендации
Online Data Processing (онлайноваяОбработка данных без промежуточного хранения
обработка данных)
Open Systems (открытые системы) Системы, для которых детальная спецификация их компонентов открыта для
внешних приложений, что позволяет разрабатывать системы, базирующиеся на
нескольких базовых продуктах
Operating System (операционнаяСистемное программное обеспечение, обеспечивающее среду для исполнения
система, ОС) приложений, предоставляя им с помощью набора системных вызовов (API)
доступ к устройствам компьютера. Среди многочисленных функций ОС -
управление диспетчеризацией задач, распределением ресурсов, обработкой
прерываний, вводом-выводом, интерфейсом пользователя, файловой и другими
системами
Optical Character RecognitionАвтоматическое распознавание с помощью специальных программ графических
(оптическое распознаваниеизображений символов печатного текста (например, введенного в компьютер с
символов) помощью сканера) и преобразование их в формат, пригодный для обработки
текстовыми процессорами, редакторами текстов и т.д.
Optical Scanner (оптическийПрибор ввода текстовых символов или изображений с бумаги в компьютер
сканер)
Output Analyzer (анализаторМеханизм, проверяющий выход системы при тестировании. Обычно осуществляет
выхода) контроль по трем направлениям: проверка известных данных на выходе,
параллельный расчет ожидаемой величины и анализ связи данных в
информационном потоке выхода
Packet (пакет) Блок пользовательских данных вместе с ассоциированной с ним управляющей
информацией, являющийся единицей переключения в сетях с коммутацией
пакетов. Пакеты могут быть фиксированной или переменной длины. В общем
случае пакет - любой блок данных, пересылаемый между компьютерами
Packet Switching (коммутацияМетод маршрутизации и передачи данных, по которому все сообщение
пакетов) разбивается на небольшие фрагменты, пакеты, каждый из которых
последовательно один за другим пересылается по коммуникационным каналам
самостоятельно, возможно по разным путям. В пункте назначения происходит
сборка пакетов
Parallel Simulation (параллельнаяПараллельная имитация подразумевает параллельную работу дополнительной
имитация) системы, разработанной аудитором и выполняющей наиболее критичные задачи
основной системы с последующим сравнением результатов
Performance testing (тестСравнение производительности модулей системы с аналогичными показателями
производительности) других систем
Peripherals (периферия) Любое устройство, не расположенное на системной плате, кроме ОЗУ и
процессора, например звуковая карта, модем, жесткий диск
Point Of Sales Systems (системаКомпьютеризированный кассовый терминал, устанавливаемый в местах торговли.
для розничной торговли) POS-терминал включает в себя оптический сканер для считывания штрих-кода,
а также устройство для чтения магнитных карт. РОS может работать в
онлайновом режиме в соединении с центральным компьютером или быть
независимой вычислительной системой
Polymorphism (полиморфизм) Способность объекта использовать под одним именем несколько различных
процедур, связанных с обработкой данных разного типа
Port (порт) Точка интерфейса между процессором и периферийным устройством
Preventive Control (превентивныйКонтроль, направленный на устранение предпосылок возникновения
контроль) исключительных ситуаций
Professional CompetenceСоответствие опыта и знаний требованиям
(компетентность)
Programming Evaluation and ReviewМетодика управления проектом, используемая в планировании и контроле
Technique PERT (ПЕРТ-диаграммы) систем проекта
Protocol (протокол) Набор правил, в соответствии с которыми осуществляется передача данных
Prototyping (использованиеТехника разработки систем, заключающаяся в первичном создании действующей
прототипа) модели системы, реализующей ее основные функции. Данная модель называется
прототипом
Queue (очередь) Группа объектов, ожидающих дальнейшей обработки
Real-Time Processing (процессИнтерактивный процесс, обеспечивающий немедленное изменение данных в
реального времени) системе после их инициирования с пользовательского терминала
Record (запись) Множество связанной информации, хранимой в системе как единое целое. Для
разделения записи на составляющие используются поля
Redundancy Check (контроль заМеханизм выявления ошибок, основанный на введении дополнительного
введением избыточных элементов) значения, рассчитываемого на основании имеющихся данных
Re-engineering (реинжиниринг) Процесс выделения составляющих системы с последующим преобразованием их в
новую систему
Regression testing (регрессивноеМетодика тестирования, основанная на повторном тестировании ранее
тестирование) реализованных функций и элементов системы с целью выявления возможных
ошибок в текущей разработке и скрытых проблем
Repository (репозиторий) Центральная база данных
Request for Proposal (заявка наДокумент для разработчика с просьбой реализации нового продукта или
реализацию) внесения изменений в уже имеющуюся систему
Requirement Definition (описаниеФаза жизненного цикла проекта, в которой определяются требования к
требований) продукту
Reverse Engineering (обратныйТехника инжиниринга программного обеспечения, при которой существующий
инжиниринг) программный код системы может быть преобразован к исходному программному
коду для дальнейшего изменения
Ring Topology (топология кольца) Одна из топологий организации сети, в которой все компьютеры соединены
последовательно в замкнутое кольцо. Сигнал также передается
последовательно от одного компьютера к другому до тех пор, пока сообщение
не достигнет компьютер с нужным адресом
Risk (риск) Вероятность возникновения исключительной ситуации, умноженная на сумму
причиняемого в результате ущерба
Router (маршрутизатор) Интеллектуальное устройство, управляющее информационным потоком на
основании сетевых адресов. Может быть как специализированным устройством,
так и реализованным на базе компьютера
Screening Routers (маршрутизатор сМаршрутизатор, сконфигурированный на разрешение или запрещение трафика на
ограничением доступа) основе набора правил доступа, заданных администратором
Segregation/Separation of DutiesОдно из базовых правил управления, требующее контроля за соответствием
(разделение обязанностей) выполняемой работы сотрудником его обязанностям
SMTP Протокол передачи почты
SNMP Протокол управления сетью
Software (программное обеспечение) Программы и сопутствующая документация. Программное обеспечение
осуществляет управление аппаратным обеспечением
Software (программное обеспечение,Общее понятие, описывающее программы для компьютеров в отличие от его
ПО, разг. Софт) аппаратных составляющих (hardware). При этом не уточняется, в каком виде
представлены программы (в исходных текстах или в исполняемом коде). ПО
делится на два больших класса - системное (system software) и прикладное
ПО (application programs)
Source Code (исходный код) Текст программ на языке разработки. Исходный код преобразуется в
исполняемый код посредством ассемблера или компилятора
Source Code (исходный текстКомпьютерная программа, написанная программистом либо сгенерированная на
программы) языке программирования. Исходный текст программы может быть откомпилирован
с помощью компилятора в объектный или даже в машинный код либо исполнен
интерпретатором
Source Code Compare CodeПрограмма, которая проверяет, что контролируемая система имеет правильные
(программа сравнения исходноговерсии исходного кода, а также выявляет различия в коде различных версий
кода)
Split Data System (распределеннаяМетод построения информационной системы, в соответствии с которым каждый
информационная система) модуль системы имеет свою систему управления и базу, предоставляя для
консолидации информации в рамках всей системы только необходимые данные
Star Topology (топология звезда) Одна из трех базовых физических топологий ЛВС, в которой компьютеры и
устройства соединены радиальными линиями с центральным узлом. Различают
активную звезду (active star) и пассивную звезду (passive star)
Statistical SamplingМетод выбора элементов рассматриваемого множества, основанный на
(статистический выбор примеров) математических расчетах, связанных с контролем различных зависимостей
Structured ProgrammingТехника разработки программного обеспечения, основанная на постепенной
(структурное программирование) детализации проекта
Structured Query Language SQLСтандартный язык доступа к данным в реляционных базах данных
(язык запросов SQL)
Synchronous TransmissionРежим передачи, при котором биты данных пересылаются с фиксированной
(синхронная передача) скоростью, а приемник и передатчик синхронизированы
System Software (системноеОперационные системы, а также ПО и утилиты для разработки, отладки и
программное обеспечение, системноесопровождения программ
ПО)
Telecommunication Передача всех форм информации, включая данные, голос, видео и т. п., между
(телекоммуникация) компьютерами по линиям связи
Terminal (терминал) Электронное (обычно монитор с клавиатурой) или электромеханическое
устройство для ввода данных в компьютер и вывода полученных результатов.
Этот популярный ранее термин еще используется в многопользовательских
системах
Third Party Review (оценкаНезависимый аудит сторонней организацией
независимой экспертизы)
Token Ring Topology (сетеваяЛВС с маркерным доступом (использующая передачу маркера как символа права
топология кольца) доступа к сети). Регламентирована стандартами IEEE 802.5 и ISO 8802-5.
Логически сеть Token Ring представляет собой кольцо, а физически - звезду
Topology (топология сети) Общая физическая или логическая конфигурация телекоммуникационной системы:
физическая топология - схема соединений компонентов кабелями и проводами,
а логическая топология описывает, как по сети проходят сообщения
Transaction (транзакция) Логическая единица работы, состоящая из запроса (например, к базе данных)
и получения результатов его обработки
Transaction Log (журналАвтоматически формируемый журнал, содержащий описание транзакций,
транзакций) выполненных в системе
Twisted Pairs (витая пара) Среда для передачи сигналов, в которой используются два скрученных друг с
другом изолированных электрических проводника. Скручивание обеспечивает
защиту от электромагнитных и радиочастотных помех
Uploading (пересылка) Пересылка файла по сети из клиентского компьютера в другой (обычно
удаленный) хост-компьютер
Utility Programs (сервиснаяСистемная программа, предназначенная для выполнения определенной функции,
программа) например разметки диска
Variable Sampling (переменнаяТехника выборки анализируемых данных, основанная на постоянной смене
выборка данных) контролируемых объектов. Как правило, используется для оценки среднего
значения или консолидированных данных
Verification (верификация,Проверка правильности выполнения операции
контроль)
Voice Mail (голосовая почта) Вид электронной почты, когда в виде письма хранится речевое сообщение. В
общем случае - любая система для отправки, хранения и получения речевых
сообщений
Wiretapping (подслушивание,Запись сообщений, передаваемых по линиям связи
перехват сообщений)
Х.25 Interface (стандарт Х25) Определяет протокол, используемый для пересылки сигналов и данных в сети с
коммутацией пакетов. Каждый пакет содержит информацию о
компьютере-отправителе и компьютере-получателе, который должен его
принять. Описывает этот интерфейс на трех уровнях: физическом, передачи
данных и сетевом
Примечания
*(1) Методология СoblТ представляет собой набор из нескольких книг: руководство по аудиту, руководство для менеджмента, контрольные процедуры, руководство по внедрению. Она является практически открытой и доступна с официального сайта www.isaca.org или с российского портала www.isaca-russia.ru и может быть рекомендована для широкого использования в практике управления ИТ.
*(2) Таких , как Computereconomics (www.computereconomics.com), Gartner (www.gartner.com).
*(3) Источник: Computereconomics.
*(4) Источник: Computereconomics.
*(5) Крестом помечены функции, которые не рекомендуется совмещать.
*(6) Мы уже приводили примеры с использованием данного стандарта, например в главе Оптимизация документооборота.