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

⇐ ПредыдущаяСтр 6 из 47Следующая ⇒

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

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

│по всем отраслям │ (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. Недружелюбный интерфейс. Как правило, западные системы имеют более удобный для работы интерфейс. Это связано с тем, что в российской практике обычно разработчики не выделяют специалистов - дизайнеров интерфейса, который создается обычными программистами и впоследствии модифицируется в связи с предложениями клиентов.

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

Дата добавления: 2019-01-14; просмотров: 189; Мы поможем в написании вашей работы!

Поделиться с друзьями:

⇐ Предыдущая 1 2 3 4 567 8 9 10 Следующая ⇒

Мы поможем в написании ваших работ!