[Borik]

Кто нибудь щупал этого зверька ?

[Igor]

в БТА или в Темире, уже год внедрить не могут

http://www.3i-infotech.com/News/pr_rel/BNK...alem020706.aspx

[devor]

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

[Borik]

devor (26.02.07) писал:

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

Можно поподробнее, пожалуйста. Я занимаюсь его внедрением со стороны Банка и хотел бы получить более детальную информацию.
1) Почему высокие требования к железу ? Может быть узким местом является коммуникационная инфраструктура, а не производительность серверов ?
2) Сервер БД можно перегрузить если параллельно кредитному досье вести в системе отсканированные изображения документов клиентов, а если этого не делать ?
3) А что Вы можете сказать о безопасности системы ? Насколько в ней продуман вопрос защиты данных от несанкционированных попыток их изменения ?
4) Насколько она гибка в конфигурировании ?
5) Не могли бы Вы поделиться общими впечатлениями о системе ?

[anatoly]

Цитата

Можно поподробнее, пожалуйста. Я занимаюсь его внедрением со стороны Банка и хотел бы получить более детальную информацию.
1) Почему высокие требования к железу ? Может быть узким местом является коммуникационная инфраструктура, а не производительность серверов ?
2) Сервер БД можно перегрузить если параллельно кредитному досье вести в системе отсканированные изображения документов клиентов, а если этого не делать ?
3) А что Вы можете сказать о безопасности системы ? Насколько в ней продуман вопрос защиты данных от несанкционированных попыток их изменения ?
4) Насколько она гибка в конфигурировании ?
5) Не могли бы Вы поделиться общими впечатлениями о системе ?

Я лично этим проектом не занимаюсь, но попробую ответить...
Работоспособность (готовность) 24/7.
Производительность железа еще никому не помешала и не помешает...
Безопасность здесь должна быть на первом месте (ибо без нее оно никому не надо)
если эта штука проприетарная, то вряд ли она будет гибкой.

[devor]

Я итак озвучил собственное впечатление

1)Почему обычно бывают высокие требования? Потому что такая архитектура такая. Ознакомьтесь с концепцией, с технологиями.
2)Сервер БД перегружается большим количеством транзакций и замысловатыми бизнес-процессами. Оцифрованные изображения - это лишь вопрос ширины каналов связи)))
3)Безопасность - понятие сильно широкое и зависит в большей мере от вашей политики.
4)Смотря что вы принимаете за эталон гибкости)) Это очень относительное понятие.
5)На мой взгляд - сильно экзотично и поэтому много мороки. Но если есть ресурсы(денежные и человеческие) - почему нет. Имидж тоже дорогого стоит

PS
Все эти вопросы уместнее адресовать представителям 3i. Тем более, что вы УЖЕ по вашим словам занимаетесь внедрением и поэтому я думаю успели с ними познакомиться.
Если нет - то пообщайтесь с Арией по административным вопросам, с Гуру по вопросам настройки и бухучету, с Ракешем по техническим вопросам.

Сообщение отредактировал devor: 26 February 2007 - 18:05

[Igor]

Т.е. покупали за $2млн, настройки вам еще обойдуться в $20 млн.?

В итоге все равно получается не то что хочет бизнес ?

[Borik]

devor (26.02.07) писал:

2)Сервер БД перегружается большим количеством транзакций и замысловатыми бизнес-процессами. Оцифрованные изображения - это лишь вопрос ширины каналов связи)))

Ну насчет большого количества транзакций я сомниваюсь, а вот насчет картинок приклепленных к БД - это вопрос не только ширины каналов, но и емкости накопителей, а так же скорости доступа к данным... К примеру, досье может содержать минимум 10 документов. Некоторые из них будут на нескольких листах. Средний объем каждого отсканированного документа (нормального качества, что бы СБ и Юристы могли бы их изучать) составил бы 1 Мб. 10x1 = 10Мб - документы по одному досье. В день только один филиал свыше 150 кредитных заявок обрабатывает. 150x10=1.5Gb в день. Если на сервере будет винт - 200Gb, то долго он не протянет даже если туда только филиал будет складывать заявки. Для организации быстрого доступа к такому объему данных потребуются уже хранилища данных. А учитывая то, что информацию придется хранить как минимум по пять лет, пока её нельзя будет отдать в архив, то могут потребоваться информационные сети типа SAN. А это уже на стоимости оборудования и системы в целом очень сильно скажется... А Вы говорите, что оцифрованные изображения - это лишь вопрос ширины каналов связи...

devor (26.02.07) писал:

4)Смотря что вы принимаете за эталон гибкости)) Это очень относительное понятие.

Просто 3i-infotech так преподносили свою систему, что в ней можно все абсолютно настроить. Оказалось что в ней _ОЧЕНЬ_ много чего настроить нельзя. Что даже сам бизнес-процесс у них зашит в коде и если потребуются какие-то более менее существенные изменения - надо обращаться в Индию. Другими словами мы ждали от них очень гибкой системы, которую сможем сами настроить под любой БП, но оказалось что это не так... Хотя наверное нужно было быть сильно наивными что бы так думать... :-)

[devor]

Про транзакции не надо сомневаться. Хотя, конечно, многое зависит от учетной политики и фантазии бухгалтеров.
1Mb многовато. Можно как минимум в 10 раз меньше при вполне адекватной читабельности. Вы же не думаете гонять с каждым филиалом по 1.5 гига трафика в день?
Впрочем, можно организовать и хранилище для ваших картинок, только причем тут Kastle? Организация хранилища мультимедийной информации к розничному кредитованию никакого отношения не имеет.

Преподносить систему в радужных красках - это нормально. Покажите мне продавца, который так не делает.
Наивно ожидать какой-то сверхгибкости от тиражируемого решения.
Организации не терпящие компромиссов пользуют собственные разработки, как тот же пресловутый ICICI Bank из которого собственно выделился в самомстоятельную компанию 3i-infotech

Сообщение отредактировал devor: 27 February 2007 - 10:35

[devor]

Igor (26.02.07) писал:

Т.е. покупали за $2млн,

Да, цифры ориентировочно такого порядка

Igor (26.02.07) писал:

настройки вам еще обойдуться в $20 млн.?

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

Igor (26.02.07) писал:

В итоге все равно получается не то что хочет бизнес ?

Бизнес никогда не бывает полностью удовлетворен.
Продуктовики зачастую блещут бурной фантазий, рождающей все новые продукты один изощреннее другого, на ходу принципиально меняют уже утвержденные условия, разрождаются иезуитскими отчетами. Пр этом, что характерно, постановка задачи звучит примерно так: "сделайте мне большую красную кнопку, на котору нажал и денежки сами потекли в кассу". О бухгалтерах, консультирующихся у IT'шников по вопросам бухучета я вообще молчу.

[Borik]

devor (27.02.07) писал:

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

Время обработки самой транзакции ничтожно мало по сравнению с тем временем, которое будет уходить что бы из БД извлечь, скажем, несколько картинок в 1 Мб... или писать туда картинки.

devor (27.02.07) писал:

Про транзакции не надо сомневаться. Хотя, конечно, многое зависит от учетной политики и фантазии бухгалтеров.
1Mb многовато. Можно как минимум в 10 раз меньше при вполне адекватной читабельности. Вы же не думаете гонять с каждым филиалом по 1.5 гига трафика в день?
Впрочем, можно организовать и хранилище для ваших картинок, только причем тут Kastle? Организация хранилища мультимедийной информации к розничному кредитованию никакого отношения не имеет.

Ладно, с объемом каждого отсканированного документа я загнул (хотя СБшникам такое качество нужно, что бы они даже фотографии могли сверять с отсканированным изображением удостоверения) но все остальные цифры явно занижены. И когда в банке в день в БД будет даже по 2-3 Гб ложится со всех филиалов, тогда все-равно вопрос о хранилищах данных станет актуальным.
А насчет организации хранилищ картинок - вариант, однако не надо забывать о том, что без определенных трудозатрат не получится БД TRITON-а к этому хранилищу прицепить. Для этого надо, как минимум, исходники их продукта иметь... так как счас они все картинки пишут в BLOB поля БД... Кроме того, решения, которые предлагают IBM и прочие поставщики ПО по организации мультимедийных хранилищ, работают следующим образом: если, скажем, в двух записях таблицы или более сохранена одна картинка, то физически она хранится в одном экземпляре, а каждая из этих записей имеют на неё ссылки. В случае отсканированных печатных документов, каждый документ будет уникальным, и поэтому все равно встанет вопрос об организации _высокоэффективных_ хранилищ данных, которые дорогие.

А вообще что бы с этим не сталкиваться, то лучше вообще бумажное досье гонять параллельно электронной заявке да и все... ИМХО.

[devor]

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

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

PS если все же очень хочется, то все равно оцифровывать все документы досье необходимости нет. Фотография клиента, удостоверение личности и РНН. И все.