Проблемы при внедрении АБС в банке

28, Фев 2015 by Admin in банковское право,вклады,деньги     , ,   No Comments

ABS

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

Автоматизированная банковская система является разновидностью автоматизированных систем управления (АСУ), методология создания которых была достаточно хорошо разработана в нашей стране в 70-х — 80-х годах. Отсутствие удачного опыта внедрения АСУ обусловлено не отсутствием такой методологии, а систематическими отступлениями от нее.

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

Можно отметить следующие основные ошибки при внедрении АБС:

  • Некомплексный характер постановки задачи и отсутствие системного подхода к ее решению.
  • Отсутствие единой технической политики в банке.
  • Отсутствие в банке единого административного органа, контролирующего и координирующего все аспекты внедрения АБС, и/или недостаточные полномочия этого органа.

Возможно, не вполне очевидно, что первые две ошибки являются следствием третьей.

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

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

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

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

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

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

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

Последствия этого легче всего показать на примере.

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

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

Учет акционеров производился и в кредитном управлении в форме картотеки.

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

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

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

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

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

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

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

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

ПРИНЦИП ПЕРВОГО РУКОВОДИТЕЛЯ

Еще на заре “эпохи АСУ” один из отцов этого направления, академик В.М. Глушков, сформулировал так называемый Принцип Первого Руководителя: все работы по созданию и внедрению автоматизированной системы управления предприятием должен возглавлять и курировать непосредственно его первый руководитель. Необходимость этого принципа подтверждена многократно на практике “от противного”: те предприятия, где первый руководитель относился к АСУ формально и не контролировал хода ее внедрения, обычно не получали от АСУ ничего, кроме головной боли и лишних расходов.

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

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

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

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

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

Читайте также