12
контроль называют «сплошным». Если для контроля отбираются несколько
ресурсов, способ называют «выборочным».
В банковской сфере практически во всех процессах на входе и на выходе
ресурсами являются данные. У данных нет объективных критериев качества,
поэтому на границах процесса применяется контроль формата данных. Обмен
данными может быть организован по разному: database link, файловый обмен,
специализированные форматы обмена. Вне зависимости от способа на входе
всегда должен проводится контроль данных.
Требования к данным на входе в процесс должны фиксироваться в
спецификациях. Либо спецификации входят в состав регламентирующих
документов процесса, либо являются отдельными документами.
Рассмотрим пример, когда взаимодействие между системами
происходим обменом файлами. При входе может проверяться маска файла, тип
файла, наличие обязательных тегов, наполнение тегов, кодировка, формат даты.
Может производится проверка уникальности файла, проверка контрольной
суммы, формирование ответного файла после импорта и обработки
оригинального файла. Многочисленные проверки позволяют минимизировать
риск ошибки и избежать финансовых потерь банка.
При этом следует заметить, что импорт файла процессом считать нельзя,
т.к. нет выхода данных. При автоматизированном подходе выходом процесса
можно считать изменение данных в базе и (или) формирование данных для
обработки их другими смежными системами.
Основная цель автоматизации заключается именно в обеспечении
наиболее эффективного подхода к выполнению процесса. [10 с. 30]
Говоря об автоматизации процессов нужно начать с определения уровня
процесса, который банк хочет автоматизировать. Это называют декомпозицией
процесса.
13
Рисунок- 3 Схема многоуровневого процесса
Автоматизировать весь процесс сразу и целиком невозможно, поэтому к
старту автоматизации есть несколько подходов. Один из подходов- «снизу
вверх», сначала автоматизируются процессы нижнего уровня, которые входят в
одну группу. После завершения автоматизации всех процессов этой группы
возможен переход к автоматизации процесса, который обслуживала эта группа
и т.д. Автоматизация осуществляется поэтапно, шаг за шагом. Такой подход
позволяет минимизировать риск сбоев, но как правило оказывается технически
и организационно сложным в реализации.
Другой подход- «с чего проще». Сначала автоматизируются процессы,
которые автоматизировать технологически проще. При таком подходе
результат выхода процесса, с которого вы начинаете автоматизацию, должен
контролироваться процессом уровня выше. В большинстве современных
банковских IT систем встроены дистрибутивные решения автоматизации,
макрокоманды и прочие инструменты автоматизации. Эти инструменты
активно используются банками в автоматизации процессов, так как на практике
этот подход применяется очень часто. Сейчас банки предпочитают
использовать информационные системы с «встроенной» интеграцией, чтобы
была возможность использовать дистрибутивные решения автоматизации даже
при взаимодействии разных систем. [16]
Автоматизация процессов требует качественного описания, детально
формализованного технического задания для успешного внедрения процесса.
Введение регламентов ведет к комплексному развитию банка, повышению
14
управляемости и прозрачности процессов на всех уровнях. Современный банк
должен быть централизован, автоматизация позволяет легко тиражировать
процесс в отделения и филиалы.
Под результатами бизнес-процесса следует понимать степень
достижения поставленной цели, которая не может определяться параметрами
самого бизнес-процесса, а задается экзогенно (извне), следовательно, в системе
взаимосвязанных и взаимообусловленных бизнес-процессов определяется
требованиями последующих процессов и обусловливает, влияет на их
параметры. [21 c. 113]
Эффективность реализации бизнес-процесса зависит от показателей
эффективности решения задач, из которых он состоит. При этом на показатель
эффективности решения каждой задачи влияют как инструментарий и методы
ее решения, так и входной поток ресурсов, в том числе и показатели
эффективности решения предыдущих задач.
Представление бизнес-процессов в виде системы последовательно-
параллельных бизнес- задач позволяет эффективно управлять бизнес-
процессами через агрегированные показатели эффективности бизнес-процессов
и показатели эффективности решения задач.
Не банковские продукты, а эффективные процессы их создания и
развития приносят банкам долгосрочный и устойчивый успех. Система
управления должна быть ориентирована повышение эффективности каждого
бизнес-процесса. Поэтому оптимизация бизнес-процессов - один из важнейших
способов выживания и процветания коммерческого банка в настоящее время.
Представление деятельности банка как системы взаимодействующих
бизнес-процессов позволяет получить адекватное представление всей
деятельности, четко выделить задачи каждого бизнес-процесса, определить их
взаимосвязанность, а главное - установить количественные и качественные
характеристики эффективности их решения, что позволит оценить качество
используемых процедур оптимизации и принятия управленческих решений.
15
Бизнес-процессы нормализованы и связаны между собой, каждый из них
может быть представлен как множество определенных взаимодействующих
задач, решение которых требует затрат ресурсов и дает необходимый выходной
продукт – банковскую услугу, характеризующуюся качественными и
количественными показателями. Представление банка как системы бизнес-
процессов позволяет четко разделять границы указанных сегментов
деятельности, анализировать и повышать их эффективность.
Для оптимизации системы управления бизнес-процессами банка
необходимо: построить схему взаимодействия задач ключевых бизнес-
процессов банка, провести предварительный анализ эффективности бизнес-
процессов, составить приоритетный перечень бизнес-процессов.
Каждый бизнес-процесс состоит из множества решаемых задач
с организационно-логической структурой и схемой взаимосвязей. Все задачи
можно разделить на четыре группы:
- аналитические,
- организационные,
- технологические (реализационные),
- учетные.
Классификация задач бизнес-процессов банка необходима для
дальнейшего исследования бизнес-процессов, так как разные классы задач
требуют применения разных подходов, инструментария и методов решения.
Учетные и аналитические задачи включаются в общую информационно-
математическую модель банка, предназначенную для оптимизации бизнес-
процессов.
Анализ эффективности бизнес-процессов проводится на основе
показателей эффективности решения задач, относящихся к данному процессу.
Для общего анализа финансовой устойчивости банка и эффективности
отдельных бизнес-процессов можно использовать следующие показатели:
- показатели эффективности ресурсного обеспечения
- показатели эффективности размещения ресурсов
16
- показатели эффективности маркетинга
- показатели эффективности управления финансами
- показатели оценки качества управления банком [39]
Переход банка на качественно иной уровень развития неизбежно
требует внедрения в банковскую практику новых технологий, новых подходов
и методов работы. Эти процессы часто сопровождаются пересмотром
организационной структуры, изменением спектра предлагаемых банковских
продуктов и услуг, реинжинирингом бизнес-процессов, внедрением новых
информационных технологий. Кардинальные изменения в технологии работы
кредитной организации, появление новых продуктов и услуг приводят к тому,
что система автоматизации и управления деятельностью банка, которая
использовалась ранее, перестает отвечать новым изменившимся требованиям с
точки зрения банковской технологии. [6 с. 231] Реинжиниринг бизнес-
процессов получил широкое распространение не только в банках, но и в
финансовой сфере в целом. [36]
1.2. Этапы внедрения автоматизированных бизнес-
процессов
Процесс вывода банковского продукта на рынок зависит от специфики
продукта, специфики и масштабов самого банка, но в целом можно выделить
нескольких этапов: моделирование (проектирование), разработка,
тестирование, опытная эксплуатация, промышленная эксплуатация.
Первый этап можно назвать самым важным, качество первичного
проектирования будет определяющим фактором для будущего построения
отлаженных и бесперебойно работающих механизмов обслуживания продукта.
Верхний уровень архитектуры бизнес-процесса определяется именно на первом
этапе, этапе моделирования. Бизнес подразделения банка должны ясно
представлять, какой продукт банк хочет получить на конечном итоге. Именно
четкое описание продукта позволит не только избежать ошибок, которые могут
проявиться уже после внедрения продукта в промышленную среду, но и
сэкономить средства банка.
17
Первой фазой данного этапа является анализ требований к системе.
Требования заказчика уточняются, формализуются и документируются.
Фактически, на этом этапе дается ответ на вопрос: "Что должна делать будущая
система?". Именно здесь лежит ключ к успеху всего проекта автоматизации. В
практике создания больших программных систем известно немало примеров
неудачной реализации именно из-за неполноты и нечеткости определения
системных требований.
На этом этапе определяются:
-архитектура системы, ее функции, внешние условия ее
функционирования, распределение функций между аппаратной и программной
частями;
-интерфейсы и распределение функций между человеком и системой;
-требования к программным и информационным компонентам системы,
необходимые аппаратные ресурсы, требования к базе данных, физические
характеристики компонент системы, их интерфейсы; [29]
-состав людей и работ, имеющих отношение к системе;
-ограничения в процессе разработки (директивные сроки завершения
отдельных этапов, имеющиеся ресурсы, организационные процедуры и
мероприятия, обеспечивающие защиту информации). [5 c. 8]
Если провести аналогию ввода банковского продукта на рынок со
строительством здания, то качественное описание банковского продукта, это
решение заказчика о том, какое здание и с каким функционалом застройщик
вообще будет проектировать и строить. И чем более детально и качественно
заказчик опишет то, что должно быть построено, тем более ясно архитектор
будет понимать, что ему нужно спроектировать.
«Архитектором» в банковской сфере будет являться менеджер проекта,
который должен отлично представлять весь процесс на верхнем уровне.
Понимать какие подразделения банка должны быть задействованы в
реализации проекта, какие информационные системы могут обслуживать
проектируемый продукт.
18
Менеджер проекта тесно работает с бизнес- подразделением банка,
предлагая различные решения и пути реализации для более детального
понимания планов и требований заказчика. В ходе этой работы должен быть
определен план проекта с детальным описанием каждого этапа, сроками и
стоимостью их реализации. И, что очень важно, за реализацию каждого этапа в
плане проекта должен быть назначен ответственный сотрудник или
подразделение. Если за какие- то пункты плана ответственно подразделение, то
внутри подразделения «зоны» ответственности все равно должны быть
распределены между конкретными сотрудниками. Из этих сотрудников
формируется рабочая группа. [32]
В процессе согласования плана в проект вносят коррективы будущие
исполнители, и конечный план утверждается бизнес подразделением.
Совершенно очевидно, что продуманность плана и правильный выбор путей
реализации является важнейшим фактором, который будет влиять на качество
работы процессов, которые будут обслуживать продукт при внедрении его в
промышленную среду и вывод его на рынок. Если вернуться к аналогии со
строительством здания, то нужно заметить, что в банке этим планом
организации бизнес- процесса должен определяется не только «инженерный
проект здания», но и «кто и когда должен рыть котлован», «кто, когда и с
какого завода будет привозить бетон».
«Инженерный проект»- технический паспорт проекта, целью которого
является детальное описание технических требований. Описание требований
применимо к нескольким уровням системы.
На верхнем уровне проводится проектирование архитектуры системы,
включающее разработку структуры и интерфейсов ее компонент
(автоматизированных рабочих мест), согласование функций и технических
требований к компонентам, определение информационных потоков между
основными компонентами, связей между ними и внешними объектами;
На нижнем уровне проводится детальное проектирование, включающее
разработку спецификаций каждой компоненты, разработку требований к
19
тестам, плана интеграции компонент, построение моделей иерархии
программных модулей, архитектуры межмодульных взаимодействий и
проектирование внутренней структуры модулей. [5]
Чтобы избежать возможных проблем, план должен учитывать
технологические и законодательные ограничения. Строить здания можно «не
везде», на строительство требуется разрешительная документация, а
строительные материалы должны быть безопасны для здоровья. Банковская
деятельность регулируется федеральными законами, подзаконными актами,
требованиями центрального банка, требованиями информационной
безопасности (ФинЦЕРТ), международными соглашениями, стандартами и
правилами платежных систем. Понимание, под какие регулирующие
юридические нормы попадает проектируемый продукт, не только снизит
финансовые риски от санкций и штрафов, но и убережет от «переделывания»
бизнес процесса на ходу.
Проектирование информационного обмена в автоматизированных
системах требует учета:
-специфики ввода-вывода данных;
-способов кодирования и передачи информации;
-типов программных средств обработки данных. [28 c. 130]
Застройщик, строя здание, покупает бетон, а не бетонный завод. Если
для реализации проекта требуется покупка лицензируемого программного
обеспечения, нужно удостовериться, что данное ПО точно способно
реализовать требуемый именно вам функционал. Компании- разработчики, как
правило, легко предоставляют доступ к демо- стендам потенциальным
клиентам. Если процесс будет обслуживать две или более информационные
системы нужно учитывать возможность интеграции. Учитывая комплексность
и технологичность современных банковских продуктов вопрос взаимной
интеграции IT- систем стоит очень остро.
Строительное оборудование застройщик может взять в аренду. В банке
часть бизнес- процесса может быть реализовываться силами сторонних
20
компаний, на аутсорсинге. На аутсорсинг небольшие банки очень часто отдают,
например, процессинговые услуги, реализация которых «внутри» являются
очень дорогой и технологически сложной. Таким образом даже небольшой банк
может предложить своим клиентам продукты «эмиссии пластиковых карт» и
«эквайринга».
Первый этап является самым сложным и самым важным. Качество
принятых решений, планирования и проектирования на этом этапе определит
судьбу бизнес процесса и успешность внедрения. Качество построенного
бизнес- процесса напрямую влияет на удовлетворенность клиентов и
успешность продукта на рынке. При этом, чем процесс сложнее, тем более
тщательно нужно подходить к проектированию, последствия от обрушения
собачей будки и небоскреба несоизмеримы.
Переходя ко второму этапу, этапу разработки, непосредственные
исполнители начинают реализовывать план.
Обычно в IT-сфере понятие «разработка» означает написание кода.
Однако банковская сфера является очень унифицированной, и чаще всего нет
необходимости «изобретать велосипед» и банки покупают решения. Иногда
банки разрабатывают системы «с нуля» если не находят решения на рынке, но
это скорее исключение из правила. Обычно с нуля разрабатывают системы,
которые нужно внедрить в уже обширную и обкатанную инфраструктуру.
Часто это системы дистанционного банковского обслуживания, иногда
антифрод системы. Но в современном банкинге никому не придет в голову
разработка собственной АБС (Автоматизированной Банковской Системы),
Ритейл системы, Казначейских или Процессинговых систем.
На этапе проектирования выбирается необходимое решение, после чего
на этапе разработки команда разработчиков оптимизирует и кастомизирует его
под требования и нужды банка либо дистрибутивными возможностями, либо
«локальной разработкой».
Программное обеспечение, обслуживающее бизнес процессы в банке,
это приложения работающие с базами данных, однако сервер приложения и
21
базы данных обычно разделяют для удобства администрирования и
разграничения прав.
После установки, настройки и доработки программных средств,
формируется тестовая среда. Если развернутый комплекс обслуживает часть
процесса и интегрируется с другими программными комплексами, то создаётся
единая интегрированная среда с тестовыми базами для возможности
тестирования всего процесса целиком.
Среда, в которой проводится тестирование, по своим параметрам
должна быть максимально приближена к «боевым» промышленным условиям.
Системы, работающие в он-лайн режимах, должны проходить нагрузочное
тестирование, с объемом трафика прогнозируемым в промышленных условиях.
Объем объектов в базе данных в тестовом контуре так же желательно
приблизить к прогнозируемому объему в промышленной базе.
При тестировании бизнес- процессов в банке обычно применяется
итеративный подход (инктрементный подход). Такой метод позволяет
максимально протестировать процесс занимаясь его доработкой циклично,
анализируя и исправляя ошибки, возникающие на каждой новой итерации. По
завершению каждой итерации команда разработчиков должна добиться целей,
запланированных именно на эту итерацию. Однако возможно переходить к
следующей итерации не достигнув успеха , в таком случае на следующем цикле
должен тестироваться тот функционал программного комплекса, который
находится на уровень ниже функционала протестированного «не успешно».
Каждый новый цикл тестирования должен основываться на результатах
предыдущей итерации. Этот метод разработки и тестирования
предпочтителен, так как детали могут дорабатываться с течением времени, в то
время как конечный функционал тестируемой системы четко определен.
Важно что бы в тестировании участвовали не только разработчики.
Обязательно в тестировании должны участвовать конечные пользователи
системы (представители заказчика) и владельцы бизнес процесса, сотрудники
банка, в чью зону ответственности будет входить качество функционирования