Тютюнник А.В. Банковское дело

Подождите немного. Документ загружается.

• Каковы временные рамки для процесса выбора, внедрения и воз-

можной эксплуатации решения?

• Насколько новое решение действительно продиктовано требовани-

ями бизнеса и какие еще альтернативные варианты существуют?

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

система удовлетворила новым задачам и реалиям?

• Существуют ли на рынке решения, способные удовлетворить тре-

бованиям банка?

• Какова примерная стоимость собственной и сторонней разработки?

• Соответствует ли замена информационной системы общей страте-

гии банка?

• Каковы основные риски, с которыми столкнется банк при том или

ином сценарии?

Далее должна быть обоснована целесообразность и осуществимость

с 'экономической, технической, технологической (операционной) и соци-

альной гочек зрения

Расчет экономической целесообразности включает сопоставление

возможных затрат и потенциальной экономической выгоды от использо-

вания новою решения. Для этого могут анализироваться такие парамет-

ры, как период окупаемости системы, чистая приведенная стоимость,

норма рентабельности, общая стоимость владения и др. Цель всего этого

процесса хотя бы примерно оценить экономическую эффективность

решения.

Техническая осуществимость состоит в оценке адекватности суще-

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

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

ных сценариев развития технической инфраструктуры, стоимости и вре-

мени таких изменений.

Технологическая (или операционная) целесообразность включает

оценку возможных плюсов от использования новой системы - повыше-

ния качества услуг, расширения спектра продуктов и достижения других

требований банковскою бизнеса.

Важным этапом является и анализ социальных составляющих этого

процесса, который включает оценку следующих аспектов: насколько

пользователи будут поддерживать новое решение и готовы ли они к по-

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

их квалификация соответствует современным требованиям и технологи-

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

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

характер.

На основании всей собранной информации высшим руководством

принимается окончательное решение о покупке или разработке новой

системы. Не существует типового решения этой задачи, оно всегда инди-

видуально для банка и каждый раз должно базироваться на результатах

анализа, хотя на практике большинство банков, как российских, так и

зарубежных, принимает решения в пользу сторонних разработок.

ТОЛЬКО для ОЗНАКОМЛЕНИЯ www.moimirknig.com для www.mirknig.com

Функциональные требования

Следующим шагом является разработка функциональных требова-

Hifff. Детальные требования

системе автоматизации банковской деятель-

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

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

Для организации процесса определения требований к системе может

быть рекомендован следующий подход. Данный этап осуществляется

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

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

ководством выделенного руководи геля, обычно высшего звена (член

правления) Иногда в крупных организациях такие команды создаются

еще на предыдущей стадии (анализ целесообразности).

Разработка функциональных требований включает в себя следующие

шаги

• проведение интервью с руководством и представителями бизнес-

подразделений банка;

• ознакомление с существующей и планируемой технологией, бизнес-

процессами, особенностями работы и информационных потоков;

• оценка организационной структуры, стратегии и направлений раз-

вития банка и их влияние на выбор АБС;

• осуществление детального анализа используемых систем;

• анализ существующих требований к системе по функциональным

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

• определение, согласование и утверждение требований к техничес-

ким характеристикам системы, таким, как объем поддерживаемых опе-

раций, оперативность, защищенность данных и т.п;

• определение/уточнение/утверждение основных бизнес-процессов

банка, подлежащих и не подлежащих автоматизации, а также их взаимо-

действия;

• определение и утверждение требований к системе.

Результатом этой работы должен стать документ «Требования к сис-

теме», являющийся частью тендерной документации. Его объем в зави-

симости от размера и сложности банка может составлять от 50 до 1500

страниц. Если документ построен правильно и в нем не излагается обще-

принятых требований, то для среднего банка вполне достаточно 70-100

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

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

рования (IDEFO, DFD, UML), так как излишняя детализация может обой-

тись достаточно дорого, как с точки зрения денег, так и с точки зрения

временных затрат.

Рассмотрим общие требования к банковским информационным сис-

темам. АБС должна:

• базироваться на современных технологиях, быть построена на со-

временных платформах (ОС и СУБД), позволяющих реализовать гиб-

кость, открытость и масштабируемость системы;

ТОЛЬКО для ОЗНАКОМЛЕНИЯ www.moimirknig.com для www.mirknig.com

• представлять собой оптимальное, интегрированное решение, иметь

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

теграции с существующими системами или модулями;

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

рять (наращивать) функциональные возможности в соответствии с по-

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

• иметь возможность увеличения количества обрабатываемых транз-

акции и/или клиентов,

• предусматривать ввод и обработку операции посредством элект-

ронного документооборота (work How). Для докумслюв должен быть

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

банком.

• предусматривать возможность получения отчетов о стадии обра-

ботки документов;

• формировать аналитические отчеты как минимум но двум критери-

ям: по клиентам и по продуктам,

• обеспечивать конфиденциальность, целостность и доступность де-

ловой информации,

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

и прикладном уровне и их последующий анализ;

• иметь возможность импортирования данных из внешних приложений;

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

применения обычными пользователями. Отчеты можно формировать для

любой информации, содержащейся в АБС. Информацию, обрабатывае-

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

должна автоматизировать (где это возможно) подготовку отчетности для

ЦБ РФ, а также налоговой отчетности;

• иметь инструментарий (генератор отчетов), позволяющий опреде-

лять: их внешний вид; данные, на основе которых будет формироваться

отчет; порядок сортировки и критерии отбора как для отчетов, получае-

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

В системе должна также существовать возможность модификации суще-

ствующих отчетов;

• проверять данные, вводимые пользователем или поступающие че-

рез интерфейс обмена ими, и осуществлять лексический, синтаксический

и семантический контроль. Примерами контроля могут быть: проверка

формата (например, цифровой); существование кода клиента в справоч-

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

дат; проверка соответствия остатка типу счета (активный, пассивный);

достаточность средств на счете; превышение лимитов; проверка крите-

рия (сумма и счет);

• предусматривать возможность верификации и авторизации действий

п документов персоналом, не связанным со вводом операции. Должна

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

видов операций или операций, превышающих установленный лимит;

• быть понятной, легкой в эксплуатации и использовать современ-

ные технологии построения интерфейса;

ТОЛЬКО для ОЗНАКОМЛЕНИЯ www.moimirknig.com для www.mirknig.com

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

просмотра но запросу администратора безопасности и иметь разграни-

ченный доступ. Как минимум следующие данные должны содержаться я

протоколе операций: время, идентификатор пользователя, рабочее мес-

ю. приложение и тип операции. Ручной ввод, пакетная обработка дан-

ных и их обработка через внешние интерфейсы также должны фиксиро-

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

быть защищен от изменений;

• иметь возможность классифицировать пользователей и предостав-

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

данным: по обьему операторских функций (доступ к определенным экра-

нам и функциям); по степени доступа (просмотр/ввод/авторизацая). Сис-

темный администратор должен иметь возможность создавать индивиду-

альные меню для конкретных пользователей;

• обеспечивать следующие требования парольной политики:

все пользователи вводят уникальный идентификатор и пароль для

получения доступа в систему;

после определенного количества неудачных попыток (3 раза) от-

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

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

ром. Система ведет учет неудачных попыток и протоколирует их;

хранимые в ней пароли должны быть зашифрованы и должны со-

ставлять как минимум 8 символов. При этом предусматривается

возможность устанавливать различную длину пароля для различ-

ных групп пользователей;

система содержит словарь неприемлемых паролей и обеспечивает

возможность запрещать ввод новых, если они присутствуют в этом

списке;

система периодически запрашивает изменение паролей пользовате-

лями;

система не позволяет повторного использования старых паролей;

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

раничено;

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

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

шения предыдущего сеанса;

предусматривается возможность ограничивать время и рабочее ме-

сто (IP-адрес, МАС-адрес или имя компьютера) пользователей в

системе;

соединение с системой должно автоматически обрываться, если поль-

зователь не работает в системе определенное количество времени.

• обладать опытом успешных внедрений на территории России, а также

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

Что касается детальных требований, то их, разумеется, невозможно

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

лим лишь некоторые специфические требования. Система должна:

• позволять осуществление автоматизированной подготовки писем для

рассылки заинтересованным сторонам (клиентам, налоговым органам

ТОЛЬКО для ОЗНАКОМЛЕНИЯ www.moimirknig.com для www.mirknig.com

и т. п) по группам счетов или клиентов. Формирование выписок по сче-

там клиентов, писем клиентам производится в формате, необходимом для

их автоматической упаковки в конверты;

• осуществлять автоматическую проверку остатка денежных средств

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

• осушсс1влять расчет текущего и планового (с учетом будущих и

неподтвержденных платежей) остатка денежных средств на cneie клиен-

та на любую да»у.

• осуществлять контроль остатка по счету с учетом установленных

лимитов. При превышении лимитов по операции или остатку на счете

необходима дополнительная авторизация;

• для открытия нового счета в системе должна существовать проце-

дура авторизации, без которой новый счет не может быть задействован

для каких-либо операций,

• предусматривать возможность как полностью блокировать опера-

ции по счету клиента, так и разрешать только дебетовые или кредитовые

операции Изменение статуса счета производится уполномоченным со-

трудником;

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

автомагическим контролем остатка по счету плательщика и отражением

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

• предусматривать возможность формирования автоматических опе-

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

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

(stand-by orders). Примером таких операций может быть ежемесячное

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

расчетного счета;

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

доступные для других офисных приложений, с целью их дальнейшей об-

работки (например, Excel. Access);

• отслеживать все стадии жизненного цикла кредита, начиная от пре-

доставления заявки до закрытия договора;

• автоматически рассчитывать сумму резерва и подготавливать для

последующего подтверждения и авторизации соответствующие провод-

ки на сумму создаваемого резерва на потери но ссудам,

• формировать отчетность по контролю позиции банка с учетом пла-

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

формируются по корреспондентским счетам с учетом платежей банка и

клиентов, в том числе ожидаемого возврата кредитов;

• иметь возможность автоматического переноса остатков на другие

балансовые счета в случае требований учета (например, закрытие пар-

ных счетов),

• автоматически осуществлять проводки на основании введенной и

авторизованной информации о заключенной сделке и формировать со-

ответсгвующие платежи,

• предусматривать формирование специальных контрольных отчетов.

Например, емче га по операциям, где произошло превышение лимитов,

ТОЛЬКО для ОЗНАКОМЛЕНИЯ www.moimirknig.com для www.mirknig.com

списка исправительных проводок и проиодок в предыдущих операцион-

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

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

ипи или по клиенту, проходящие через касс>. большие суммы, проходя-

щие по расходным счетам; списка счетов, по которым за настраиваемый

период отсутствовало движение средств (dormant accounts): отчета по

суммам, находящимся на счете дольше опредетенного периода или опе-

рациям, не завершенным в течение заданного промежутка времени: отче-

та по операциям со счетами доходов и расходов, введенными вручную.

• система «клиент-банк» должна бы п. сертифицирована.

Анализируя процесс выбора банковской системы и, в частости, тре-

бования банков, нельзя не сказать об основных двух классах таких сис-

тем, их различиях. В настоящее время можно творить о существовании

на рынке двух основных классов систем российских и зарубежных.

Рассмотрим недостатки тех и друтич.

В зарубежных тго:

• относительно высокая стоимость решения и ею сопровождения:

• сложности с поддержкой российский специфики, и прежде всею

бухгалтерского учета и отчетности в соответствии с требованиями МБ РФ:

• бо.теее долгое внедрение (обычно исчисляемое годами).

В чем же основные недостатки российских систем? Ниже приведены

основные отличия.

• Российские системы слабо поддерживают процедуры внутреннего

контроля и аудита. В них практически отсутствуют различные механиз-

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

мов минимизации, предотвращения и поиска ошибок.

• Они не достаточно развиты с точки зрения информационной безо-

пасности Это проявляется в таких вешах. как невозможность настройки

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

протоколирования действий пользователей, слабой ищите на системном

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

юров безопасности.

• Ограниченный функционал но новым для нас направлениям банков-

ской деятельности: рынок денег, FOREX, диликг. операции с ироиввод-

ными ценными бумагами, векселями, современные формы кредитования.

• Недостаток механизмов автоматизации управления банком: управ-

ленческая отчетность, on-line-анадиз рентабельности продуктов и услуг,

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

зации управления активами и пассивами, слабая визуализация управлен-

ческой информации.

• Невысокий уровень автоматизации таких банковских функций, как

риск-менеджмент, внутренний аудит, казначейство, и, в частности, уп-

равление ликвидностью.

Тем не менее, несмотря на эти недостатки и учитывая, что некоторые

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

му выбирает российские системы, хотя попытки установки зарубежных

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

ТОЛЬКО для ОЗНАКОМЛЕНИЯ www.moimirknig.com для www.mirknig.com

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

После того как обоснована необходимость внедрения новой банков-

ской информационной системы и сформулированы основные требования

к ней. можно приступать непосредственно к процессу выбора. Как мы

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

системах.

Выбор АБС является принципиальным для успеха всей работы поза-

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

рать действительно адекватную требованиям и задачам банка систему и

найти достойного бизнес-партнера, но и потому, что именно на этой ста-

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

шений с компанией-поставщиком решения (вендором), а во-вторых, бу-

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

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

риски и заранее готовясь к сложностям.

Основными этапами процесса выбора АБС являются проведение тен-

дера на выбор системы и заключение контракта.

Ниже мы детально рассмотрим составляющие этих двух этапов. Сей-

час хотелось бы отмстить, что, по нашему мнению, тендерная форма вы-

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

Основными причинами этого являются:

• независимость и относительная объективность решения (посредством

тендера оценивается максимальное количество решений, в этом процес-

се участвуют многие специалисты банка, а иногда и привлеченные экс-

перты и консультанты):

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

с поставщиками, получении информации, тендер позволяет также опти-

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

активно участвовать в выборе, но не могут приостановить свою непос-

редственную работу);

• быстрота выбора (использование тендера на основе правильных

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

бора до окончательного решения, что немаловажно, так как процесс

выбора системы может длиться от нескольких месяцев до года и более,

т. е. составлять от 10 до 40°/. всего времени замены старой системы на

новую).

Проведение тендера

Существуют две основные формы проведения тендера на выбор АБС:

открытая и закрытая. Первая подразумевает официальное объявление о

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

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

сторонние организации, не попавшие в этот список, к участию в тендере

не допускаю 1ся.

ТОЛЬКО для ОЗНАКОМЛЕНИЯ www.moimirknig.com для www.mirknig.com

Можно порекомендовать для проведения тендера по выбору АБС

закрытую форму Хотя необходимо отметить, что в некоторых случаях

может бып» использована и открытая Предпочтительность закрытой

связана лишь со спецификой рынка банковского программного обеспе-

чения, а именно ограниченностью в количестве и относительной извест-

ностью компаний поставщиков Ыа российском рынке активно работа-

ют в пой облает не более десяти отечественных компаний и всего

несколько международных Рассмотрим основные этапы проведения

тендера

Первый этап - это подготовка и организация тендера Состоит из

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

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

такой документации

• правила (методика) проведения и подсчета результатов,

• приглашение на участие в тендере, которое будет рассылаться уча-

стникам,

• анкета участника тендера (должна быть заполнена и возвращена

вместе с но/ивсрждснием участия)

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

нию процедуры тендера

Второй зтаи - формирование расширенного списка участников (long

list) и рассылка приглашений (invitation to lender) Для выбора потенци-

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

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

включения их в тендерный список (предварительный анализ поставщи-

ков и систем на предмет соответствия общим требованиям), после чего

осуществляются определение и утверждение участников тендера

В приглашении может содержаться следующая информация общая

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

ния, контактная информация, требование конфиденциальности.

В анкете участника помещается

• общая информация о компании (контактная информация, наименс

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

чество клиентов, представительства и партнеры),

• общая информация о системе (количество внедрений, в том числе в

российских и зарубежных банках, техническая платформа, а именно база

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

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

тельное программное обеспечение),

• сведения о функциональности (мультивалютность, ведение бухгал-

терского учета в соответствии с инструкциями ЦБ РФ, поддержка не-

скольких планов счетов и международных стандартов учета),

• данные об открытости (возможность импорта данных из внешних

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

шними системами),

• среднее время внедрения, примерная стоимость системы и услуг,

сведения об организации сопровождения системы

ТОЛЬКО для ОЗНАКОМЛЕНИЯ www.moimirknig.com для www.mirknig.com

Третий этап - отбор наиболее предпочтительных систем для деталь-

ного ознакомления (short Компаниям из расширенного списка, под-

твердившим свое участие, передается документ с требованиями к систе-

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

системы (около 2-4 часов на каждую сис.ему). Участникам дается неко-

торое время на формирование официального ответа о соответствии их

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

бованиям.

На основании информации, полученной из анкет участников iei-щера,

впечатлений от просмогров систем, а также ответов о соотетствии тре-

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

детального ознакомления Резулыатом этапа должен стать список из 3-4

систем. Большее количество неудобно из-ia существенною увеличения

времени изучения, меньшее потому, что увеличивается риск невключе-

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

Чешертый этап - детальное ознакомление и выбор системы. После

оповещения компаний, прошедших во второй круг отбора, необходимо

приступить к планированию встреч с поставщиками, просмотрам систем.

Такое планирование очень важно, гак как детальный просмотр системы

отвлекает огромное количество ресурсов как со стороны банка, так и со

стороны фирмы - разработчика решения. Переносы сроков или недоступ-

ность соответствующих специалистов могут затянуть этот процесс. По-

этому необходимо сформировать, согласовать и утвердить график встреч

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

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

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

нить в системе. Иногда их необходимо заранее согласовать с поставщи-

ком, чтобы он смог настроить соответствующий функционал системы

для демонстрации и не отговаривался тем, якобы «это система может, но

требуется небольшая перенастройка».

Далее начинается анализ предложений от поставщиков и оценка сис-

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

жения от поставщиков оцениваются по следующим критериям:

• степень соответствия бизнес-требованиям банка;

• необходимость в доработке и модификациях предлагаемого ре-

шения.

• предварительная стоимость и сроки проведения доработок и моди-

фикаций;

• стоимость системы и стоимость обслуживания/ поддержки;

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

• надежность и репутация поставщика, опыт деятельности в России и

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

держки и обслуживания системы в Москве, а при необходимости - в ре-

гионах России.

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

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

К перечисленным критериям оценки и самим оценкам должны приме-

ТОЛЬКО для ОЗНАКОМЛЕНИЯ www.moimirknig.com для www.mirknig.com

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

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

ветствующая балльная шкала. Например, если «степень соответствия

техническим требованиям банка» является важным критерием оценки,

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

Стоимость системы и ее поддержки является критерием, который оце-

нивается путем определения соотношения баллов, набранных после оценки

всех остальных критериев, и стоимости. В результате получается так на-

зываемый коэффициент экономической эффективности системы. Необ-

ходимо отметить, что использовать стоимость системы как критерий срав-

нительной оценки нужно с осторожностью, поскольку он применим толь-

ко в случае, если системы сопоставимы по всем основным параметрам.

Важно также оценивать не предварительную, а действительную или окон-

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

банк должен сформировать запрос на официальное коммерческое пред-

ложение для участников этого этапа тендера и ответ на него (коммерчес-

кое предложение) должен быть получен и проанализирован.

Итоговым результатом должен стать отчет по оценке и анализу сис-

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

татами анализа рассмотренных систем, с перечислением плюсов и мину-

сов каждого из них, руководство банка делает окончательный выбор,

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

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

с комментариями к их оценкам, обсуждаются результаты взвешенной

оценки и стоимостные параметры решений. Можно рекомендовать вы-

бор не только одного (оптимального) варианта (лидер тендера), но и вто-

рого (страховочного) в случае возникновения проблем с первым (напри-

мер, на стадии заключения контракта) можно будет вступить в перегово-

ры со вторым поставщиком. Причем эту ситуацию можно открыть обеим

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

Заключение контракта

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

и заключения контракта. И тут начинается игра, в которой банк практи-

чески изначально обречен на поражение. Даже при наличии квалифици-

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

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

и специализированными по «софтверным» контрактам юристами К тому

же банковские юристы и ИТ-специалисты недостаточно понимают раз-

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

ным обещаниям. Мы постарается дать ряд рекомендаций, которые мо-

гут облегчить заключение контракта и сделать его удобным банку, а не

компании.

Итак, каковы общие подходы к переговорам и заключению контрак-

та и отдельные рекомендации, которые следует принимать в расчет?

ТОЛЬКО для ОЗНАКОМЛЕНИЯ www.moimirknig.com для www.mirknig.com