Bankir.Ru
4 декабря, воскресенье 23:27

Объявление

Свернуть

Третья ежегодная конференция-консилиум «ИТ-бюджет банка - 2017»

Показать больше
Показать меньше

"Поляна" для заказной разработки

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • "Поляна" для заказной разработки

    Уважаемые коллеги! Что вы посоветуете, есть ли шансы у команды квалифицированных разработчиков (в т.ч. на Lotus) получить заказы в банковской сфере, если в ее активе нет готовых продуктов для банков. Или вся "поляна" занята готовыми продуктами и полуфабрикатами. Спасибо!

  • #2
    ...у команды квалифицированных разработчиков... (в т.ч. на Lotus)
    ...в ее активе нет готовых продуктов для банков.


    На чем и что разрабатываете?
    Даже нет полуфабрикатов?
    Не очень содержательно, к сожалению.

    Комментарий


    • #3
      IZtv

      imho банк не будет связываться с командой разработчиков. как-то не верится в это. реальнее найти "поляну" "под крылом" какой-либо софтверной конторы. хотя если уже есть готовый заказчик -- why not?

      Комментарий


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

        Интересует, насколько плотно стандартные банковские продукты, в дополнении с системами CRM, документооборота и т.д., закрывают текущие потребности банков. Насколько тяжело дается интеграция этих продуктов друг с другом. Грубо говоря, если R-Style залез, то осталось ли место?

        Есть ли достаточный кусок работы для сторонних после того установлены покупные системы (самостоятельно или системными интеграторами) или отделы АСУ самостоятельно справляются со всеми проблемами.

        А на чем разрабатываем - стандартно, Enterprise Java + Lotus + интеграция с корпоративными приложениями+всякие сервера (приложений, портальные и т.д.).

        Спасибо!
        PS: Может быть подскажете болевые точки, где всегда требуется ручная подкрутка.

        Комментарий


        • #5
          IZtv

          н-да... как говорится, "ищите и обрящите" чуть-чуть объяснили. но все-таки я не понял. Вы собираетесь интегрировать то, что есть, или вставлять что-то новое в уже существующие в банке решения?

          мое мнение таково:
          банков, где нужно интегрировать что-то с чем-то много. я, например, не знаю ни одного банка, где софт был бы ВЕСЬ однороден.
          НО. если брать крупные банки, то у них если и есть проблемы с интеграцией, то решаются они за счет собственных IT управлений размером иногда до сотни людей.
          мелким банкам интеграции особо и не надо, а вот насчет средних... не знаю. писать индивидуальный проект под средний банк? не знаю.

          опять же, что предлагаете Вы? допустим есть банк с существующей системой документооборота на Lotus, некой АБС (допустим самописной) и неким CRM от западного разработчика и все это живет под Novell. что Вы ему можете предложить?

          Комментарий


          • #6
            IZtv На мой взгляд, ОТВЕТ на Ваш главный вопрос есть ли шансы у команды квалифицированных разработчиков (в т.ч. на Lotus) получить заказы в банковской сфере, если в ее активе нет готовых продуктов для банков. - ОТРИЦАТЕЛЬНЫЙ...
            Судя по Вашим вопросам, уважаемый IZtv, положение и "правила игры" на банковском ИТ-рынке для Вас - совершенное откровение... С таким "багажом" Вы обречены на неудачу... Увы...
            С ответами и комментариями ONay я согласен...
            Да пребудет с Тобою Великая Сила! ©

            Комментарий


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

              Комментарий


              • #8
                Djn

                если следовать Вашему совету про эквайринг, то в команде должны быть не просто "банковские специалисты", а высококлассные специалисты.

                Комментарий


                • #9
                  позвольте высказать и свое мнение. Насколько я понял направление деятельности фирмы Iztv, то я бы лучше вылез на рынок не со стороны разработки банковских приложений (для этого действительно необходимы грамотные банковские постановщики), а с предложением интеграции разрозненных продуктов в рамках например портала. Тем более они это вроде уже делали. Такая потребность есть у крупных и средних банков. Это и интранет портал и интернет портал. И выступать в роли ген. подрядчика. Единицы банков могут этим похвастаться, а перспектива этого очевидна.

                  Комментарий


                  • #10
                    Спасибо всем, кто ответил!

                    Мы себя, конечно, планируем позиционировать не как разработчики банковских систем (для этого требуется опыт и понимание банковской специфики). И нам не хотелось бы разрабатывать банковские продукты (грамотная постановка задач здесь более важна, чем ее реализация). Скорее, можно говорить о двух направлениях:
                    1) интеграционная деятельность (корпоративные и клиентские порталы, обеспечение совместной работы разных приложений при сохранении требований по безопасности, надежности, территориальной распределенности и т.д.). Здесь у нас все в порядке и с постановкой задач и с их решением.
                    2) технологическая поддержка IT-отделов. Сейчас технологии развиваются так стремительно, что зачастую трудно уследить за последними изменениями, и специалистам банков зачастую это и не надо, своих проблем хватает. Поэтому оценить какое-то решение, грамотно позиционировать технологии, оценить варианты интеграции, все это может помочь независимая сторона, которая к тому возьмет на себя черновую работу по доводке и кастомизации решений совместно и под управлением IT банка. Также при необходимости можно написать и свои приложения, опять же с постановкой задач от банковских специалистов. Своеобразные дополнительные руки и головы. Т.е. мы не лезем на консалтинг – «какие продукты и разработки нужны банку», но, зная, как они устроены, мы можем сказать, как они вместе будут жить, и провести работы по реализации. Для интеграторов часто более выгодно поставить железо и готовый софт, дальнейшее – вещь обременительная и затраты на нее стараются минимизировать. Для поставщиков АБС – тоже желательно по максимуму поставить то, что уже разработано. Головные боли, как правило, достаются банку. Мы бы могли их часть взять на себя.

                    Вопрос уважаемому сообществу – насчет порталов все понятно, а нужна ли технологическая поддержка?

                    Ответ на вопрос ONay (немного похоже на анекдот: «Петька, приборы. Десять. Что десять? А что приборы?&raquo.
                    При интеграции надо смотреть конкретику. С помощью чего реализованы продукты, какой у них интерфейс (API), используются ли сервера приложений и т.д. Также учитываются требования по безопасности (органзация единой точки входа и ограничения доступа), необходимость поддержки транзакций, в т.ч. распределенных, требования по масштабируемости и отказоустойчивости, и другие. При выработке решений учитываются бюджетные и временные ограничения, возможности имеющихся систем.

                    Если условно и кратко, что можно сделать для объединения упоминаемых в вопросе ONay систем. Для подкачки необходимых данных из АБС и CRM в лотусовый документоборот (который, как правило, вещь в себе) можно написать приложение под Lotus, которое будет обращаться к другим системам и производить необходимые действия. Для унификации доступа к сервисам систем, можно обернуть их объектными wrapper-ами или написать web-сервисы (надо смотреть требования). Можно организовать и обмен данными непосредственно с базами данных, но это хуже, связность появляется. Западная CRM имеет или свои API, или поддерживает стандарты, или предлагает адаптеры за отдельную цену. Часто эти адаптеры входят в стороннее middleware (сервера приложений, message-oriented сервера). Если все живет под Novell, то можно на Java написать необходимые вставки. Надо еще рассмотреть вопрос о Directory-сервере, где будет храниться информация о сотрудниках банка, и которая будет использоваться для авторизации. Я бы взял NDS (Novell Directory Server) и проинтегрировался с Domino Directory. Если необходима поддержка транзакций, то надо смотреть возможность приобретения транзакционных серверов или MOM-серверов, или, на худой случай, писать свою реализацию с пониманием всех возникающих рисков. Фантазировать можно долго. Без контекста трудно.

                    Еще раз спасибо всем, кто ответил!

                    Комментарий

                    Пользователи, просматривающие эту тему

                    Свернуть

                    Присутствует 1. Участников: 0, гостей: 1.

                    Обработка...
                    X