18 декабря, понедельник 21:32
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

Правильная структура ИТ службы в банке

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

  • Правильная структура ИТ службы в банке

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

  • #2
    Получаетися, что отдельно, что-ли?
    Конечно, отдельно Если по уму все организовано, то у It обязательно должны быть:
    1) служба сопровождения
    2) подразделение программирования
    Банковские технологи (либо аналитики - название неважно, важна суть) должны формализовать банковские процессы и писать технические задания для It. Руководить проектами по модификации они не должны, как исполнять ТЗ - это собственное дело It-шников.

    Комментарий


    • #3
      To Pif
      Вопрос заключается в том, чтобы определить одного ли уровня должны быть структуры технологов, программистов и эксплуатации или одна из них подчиняется другой. А насчет того, что ИТ-шники сами должны внедрять, то, по-моему, не все так просто. Если речь идет о небольшой доработке, то может быть и сами, а если о внедрении нового банковского продукта или нового модуля АБС, то это затрагивает бизнес в первую очередь. В этом случае кто-то должен координировать действия всех служб банка (не только ИТ). Так вот кто эти люди? Кому они подчиняются и кто подчиняется им?

      Комментарий


      • #4
        hantenbein кто-то должен координировать действия всех служб банка (не только ИТ). Так вот кто эти люди? Кому они подчиняются и кто подчиняется им?
        Это либо банковские технологи, либо внешние консультанты.
        Подчиняются они либо Вице-Президенту, либо Зампреду, общему с ИТ-шиками.
        Да пребудет с Тобою Великая Сила! ©

        Комментарий


        • #5
          К_Маркелов
          Получается, что Банковские технологи сами себе ставят задачи, сами их решают и контролируют? И почему обязательно внешние консультанты? Я вижу тут намек на Вашу уважаемую компанию. Может должны быть проектные менеджеры в Банке в отдельном подразделении, а остальные структуры - исполнители?

          Комментарий


          • #6
            hantenbein
            Для большого банка ведь какая-то структура уже, наверно, есть? Не будете же Вы все резко переделывать, почитав ответы в этом форуме?
            Для маленького она в таком сложном виде, наверно, и не нужна?

            Поэтому вопрос кажется несколько странным. Или не очень точно сформулированным. Или это чисто гипотетически для диссертации?

            Комментарий


            • #7
              hantenbein Нет, не так!
              Задачи ставятся в ИТ-Стратегии. ИТ-Стратегия делается на основе Бизнес-Стратегии...
              Технологи связывают бизнес-требования / бизнес-цели с возможностями своих поставщиков, переводя эти бизнес-требования на язык технических заданий. Контролирует всех CIO, он же менеджер проекта (-ов).
              Консультанты вовсе не обязательны... Только вот куда Вы денете квалифицированный СОБСТВЕННЫЙ персонал после реализации проекта? Уволите??? Или будете платить им столько же, как и в "горячее проектное время"?

              Может должны быть проектные менеджеры в Банке в отдельном подразделении, а остальные структуры - исполнители? При процессно-ориентированном управлении почти так и происходит.

              Согласен с Siva: вопрос кажется несколько странным. Или не очень точно сформулированным
              Да пребудет с Тобою Великая Сила! ©

              Комментарий


              • #8
                Вообще-то, данный вопрос терзает сейчас не один банк.
                Я лично знаю несколько.
                А проектных менеджеров никуда не надо увольнять - проекты в крупном банке никогда не заканчиваются, особенно в последнее время, когда все кинулись ритейл внедрять. Сейчас получается (по-крайней мере у руководства такое впечатления), что надо постоянно что-то переделывать, да оно наверное и правильно. "Чтобы стоять на месте надо идти, а чтобы идти - бежать". Вот вопрос только в том, что хороший специалист-технолог может быть плохим организатором-PM (project manager).

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

                Комментарий


                • #9
                  У меня есть сугубо лично мнение, что организация It в банке не должна сильно тличаться от организации It компаний.

                  Комментарий


                  • #10
                    hantenbein
                    хороший специалист-технолог может быть плохим организатором-PM (project manager)
                    Вы назвали основную проблему нашего банка.
                    Наша структура: программисты+сопровождение+технологи в одном управлении IT. Технологи по сути являются PM, ведут каждый "свое" направление. У всех один руководитель (управления IT), плюс вся работа очень детально курируется Зампредом.
                    Когда банк был маленьким, штат был небольшим, время разработки было не столь критичным - такая структура работала.
                    Сейчас появились проблемы
                    - направления разработки начали "расходиться", появляются различные решения одних и тех же бизнес-задач - следствие несогласованных действий технологов (у меня есть подозрение, технологи склонны искать свое "наилучшее" решение, порой в ущерб срокам проекта) Думаю, общая IT-стратегия решила бы эту проблему, но ее пока нет
                    - очень трудно переключать программистов на другие (более горячие) проекты. ИМХО т.к. у технолога всегда есть в голове куча перспективных задач по автоматизации (и это в принципе неплохо!), они стараются не отпускать отведенные им ресурсы
                    - документация по проекту крайне мала (из за тесной связи бизнес-подразделение-технолог-программист)
                    - недостаточно информирование участников проекта

                    Несмотря на все это, не считаю, что нам нужно выделенное подразделение PM. ИМХО, для успешного project manager-ства необходимы высокие личностные характеристики + хорошая информированность о банке. Быть в курсе всех событий и течений можно только занимая довольно высокие посты в банке. Так что мы идем по пути поиска PM среди наших руководителей.

                    Комментарий


                    • #11
                      Сообщение от hantenbein
                      Интересно мнение сообщества по поводу правильной структуры ИТ в Банке.
                      Моё мнение, что должны быть две службы:
                      1) служба поддержки (эксплуатации) - отвечает за рутинные операции обработка и маршрутизация заявок, поддержка пользователей ПО и аппаратное обеспечение
                      2) служба развития (разработки) - всё что касается внедрения новых технологий работы (программисты, если они есть , должны быть здесь, но это не обязательно собственная разработка, т.к. м.б. организация в виде службы заказчика, работающей с субподрядчиками)
                      Такое выделение имеет смысл хотя бы потому, что разные критерии оценки их деятельности: для 1-ой минимизация затрат, для 2-ой экономический результат от инвестиций. Кроме того, деятельность 1-й службы носит скорее рутинный (процедурный) характер, а у 2-й проектный способ организации.
                      Что касается технологов, то по-моему мнению, они не должны быть в штате ИТ. Где именно, зависит от Банка и даже конкретных персоналий в высшем руководстве, но не исключаю, что в составе службы внутреннего контроля, если ей вменить в обязанность не только проводить проверку процедур работы, но и оптимизировать существующие процедуры.
                      Также не просто ответить о месте службы управления проектами (проектный офис). Не факт, что такая служба вообще должна быть, но в зависимости от тех задач которая она решает, она может находиться внутри ИТ (в службе развития), хотя иногда проще без организации лишней структуры обучить сотрудников культуре ведения проектов (с сертификацией, практикой, контролем и т.д.). Проектный офис может быть также в составе службы стратегического развития, в случае если приоритет реализация стратегических проектов, которые в т.ч. могут иметь отдельные задачи, связанные с ИТ.

                      Комментарий


                      • #12
                        Вообще, говоря о разных подразделениях, я имею ввиду разделение ответственности за различные этапы создания/модификации банковских продуктов, в том числе ПО, реализующего данные продукты. Это разделение ответственности требует и некой формализации общения между этими подразделениями и некой специализации.
                        Объединение программистов с банковскими технологами может привести к тому, что в процессе разработки новых продуктов будут опущены важные этапы - как то этап разработки бизнес и функциональных требований или после их разработки изменения требований не будут документироваться, а просто будет изменяться ПО. Разнеся же эти задачи по различным подразделениям, появляются контроль одних подразделений за работой других в хорошем смысле этого слова. Например, БТ разрабатывают функциональные требования по новому модулю. Разработка их согласует, определяет возможное время исполнения (с учетом требований по срокам всего проекта по внедрению этого модуля). Если внутренние ресурсы разработчика не позволяют решить задачу в необходимые сроки, разработка аутсорится. Отвечает за это начальник разработки. Допустим, что в процессе разработки БТ решило внести изменения в постановку задачи. Разработчики без изменения функциональных требований и пересмотра срокаов разработки неприступят к изменениям. Таким образом документация поддерживается в актуальном состоянии. После окончания разработки, разработчики передают ПО на сопровождение в другое подразделение. Сами они внедрить ничего не могут - нет прав. А у сопровождения жесткие требования к документированию. Еще один контроль в системе за качеством продукта. И т.д. Вся эта работа по созданию должна координироваться, отсюда появляеются проектные менеджеры. Возможно, что хороший вариант назначать представителей бизнес-подразделения Pmом, но как уже говорилось раньше , для этого нужны специальные навыки.

                        Комментарий


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

                          Комментарий


                          • #14
                            hantenbein
                            Вы привели пример поистине идеального механизма. Если бы описанная Вами технология соблюдалась, то, я думаю, статьи типа "Клиенты недовольны банками" вообще бы нигде и никогда не появлялись.

                            Комментарий


                            • #15
                              hantenbein

                              То, что Вами изложено явно вписывается в МЕХАНИСТИЧЕСКУЮ модель производства и управления. Она предполагает, что технологические процессы формируются из роботов-станков с односторонними связями. Если бы предположить, что эта система верна, то в мире существовала бы только ОДНА организационная структура банка.
                              Но это не так.
                              Значит, есть еще некий фактор, сильно влияющий на процессы в банке. И этот фактор известен – ЧЕЛОВЕК со своими (личными) целями, образованием, менталитетом, особенностями мышления и т.д. Он обычно не выполняет в срок, не понимает что делает, ошибается, спорит, болеет, прогуливает, курит и пьет!!

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

                              Организационная структура сама по себе не может быть оценена как хорошая или плохая. Он должна быть ЭФФЕКТИВНОЙ под управлением ЭТОГО человека.
                              Она должна рассматриваться только в совокупности со своим МЕНЕДЖЕРОМ и КОМАНДОЙ ТОПов.

                              Комментарий


                              • #16
                                hantenbein
                                мое мнение:
                                1) служба поддержки
                                2) разработчики ПО (может и не быть если все на аутсорсинге)
                                3) сопровождение ТС
                                4) технологи

                                Все находятся под одним зампредом. Первые 3 могут быть в одном управлении, технологи обязательно отдельно, т.к. их интересы объективно противоречат разработчикам ПО. По хорошему 1 тоже должны быть отдельной службой.

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

                                Это конечно некая идеальная модель, в реалии зачастую модель подстраивают под личности, но ИМХО лучше закладывать правильную структуру, не опираясь на личности.

                                Комментарий


                                • #17
                                  Добрый день!

                                  Кстати, однажды обсуждалась очень похожая тема - "Структура технологических подразделений банка". Мне кажется, что статьи, ссылки на которые приведены во втором сообщении, могут представлять определенный интерес - впрочем, как и весь тренд.

                                  С уважением,
                                  Aha

                                  Комментарий


                                  • #18
                                    arc
                                    Спасибо, Ваши рекомендации в точности совпадают с моим личным мнением.
                                    Кстати, кажется у Вас в банке внедрялся проектный подход в трактовке PMI. Как Вы оцениваете результаты? Что положительного и что отрицательного он привнес? Есть ли материалы, которыми Вы могли бы поделиться с общественностью (хотя бы в личную почту)? Особенно интересует порядок разработки, внедрения и сопровождения.

                                    Комментарий


                                    • #19
                                      hantenbein

                                      Подход внедряется, но откровенно скажу довольно тяжело. Я сам лично завершил два проекта (2 года) в соответствие с методикой PMI. На практике естественно многие подходы уточнились, но как не смешно, в конечном итоге пришли к осознанию правильности положений PMI, как бы в начале они не казались спорными
                                      Но не все в банке еще это поняли , поэтому мы должны на собственном примере понять, что нельзя назначать менеджером проекта человека из бизнес подразделения, что вначале руководству казалось бесспорным.
                                      Управление технологий еще окончательно не "оперилось", их еще не обучали PM, чтобы они могли быть "правильными" менеджерами проектов. А самое главное конечно - это то, что руководство банка не насаждает PM как идеологию в банке. Но двигаемся конечно в эту сторону, может на мой взгляд не так быстро как хотелось бы.

                                      Комментарий


                                      • #20
                                        Управление банковских технология. Подчиняется зампреду. Задачи ставит технологический комитет(руководитель), в состав которого входят руководители департаментов.
                                        Управление информационных технологий.Подчиняется тому же зампреду.
                                        Отдел технического обеспечения и сетей.
                                        Отдел сопровождения банковского программного обеспечения.
                                        Отдел разработки программного обеспечения.

                                        Начальники управлений(отделов) формируют команду под себя.


                                        >arc от 23-03-2004, 18:53
                                        согласен
                                        Где ознакомиться с методикой PMI?

                                        Комментарий


                                        • #21
                                          Привет всем!

                                          Нас (средний московский банк) эта тема волнует тоже. Мы разделили IT на два управления в 2001 году: управления автоматизации и управление банковских технологий. Причем технологи и программисты сидят вместе в УБТ. Не нахожу ничего зазорного в этом исходя из:
                                          1. Эволюционного пути, в процессе которого к менеджменту Банка только приходит осознание роли постановщиков задач (по-нашему технологов).
                                          2. Наличия АБС RS-Bank.

                                          В остальном разделение функций совпадает с доминирующем в этой теме мнением.

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

                                          А что у Вас уважаемые автоматизаторы? Кто и почему реструктурирует IT-подразделения?

                                          Комментарий


                                          • #22
                                            Конструктор
                                            http://www.pmi.ru/

                                            Medox
                                            Как обычно у нас в Отечестве "Гром не грянет - ...." Понимание необходимости проектного подхода приходит обычно после неудачных проектов, неудачи которых были обусловлены именно недостаточным уровнем управления проектами и организацией взаимодействия различных подразделений, участвующих в проекте.
                                            У нас в банке эта тема у руководства достаточно легко нашла понимание вначале и .... все Но, во всяком случае мне не пришлось "ломать стены" непонимания.

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

                                            Комментарий

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

                                            Свернуть

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

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