Bankir.Ru
5 декабря, понедельник 15:28

Объявление

Свернуть

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

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

Управление (отдел) технологий в банке

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

  • Управление (отдел) технологий в банке

    Был тут в разделе "Персонал" и встретил интересный постинг банкира Alenka:
    >> у меня достаточно редкая банковская специальность, я технолог, т.е. пишу регламенты, техзадания и вообще решаю проблемы с автоматизацией всего на свете. Далеко не во всех банках есть Управления (отделы) технологий.

    Вот возник вопрос (помня недавнюю тему банкира Marina - кто должен писать ТЗ?): каковы функции и задачи данного подразделения ?

  • #2
    В чем вопрос то? Они и должны писать ТЗ. Вообще, автоматизаторам Alenkи повезло - у них есть постановщики. Другое дело, нужно ли отдельное Управление? Можно ведь их и к автоматизаторам присоединить.
    Васильев А.Б.

    Комментарий


    • #3
      Добрый день, коллеги!
      Вернулись к моему вопросу, только с другой стороны!

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

      Да какая же она редкая... В любом банке такой человек есть. Только называется по-разному. Я то же самое делаю, только в бухгалтерии.
      Так, чтобы была отдельная структура - такого не встречала (за исключением организации уважаемого Механизатора учета ).

      Думаю, эти люди должны быть из бухгалтерии. Потому что ТЗ (из собственной практики) на 90% состоит из бухгалтерского учета (в частности, установление любых необходимых параметров и признаков счетов, проводок, договоров, клиентов, сделок - вопрос учетной политики и приложений к ней), а остальное - взаимосвязи и последовательность действий, что тоже не требует специального образования или опыта работы программистом.

      Главное - договориться о правилах игры...

      Комментарий


      • #4
        Снова-здорово.
        Ребята, если честно, то я не очень понимаю сути дискуссии.
        Банк это не фирма-разработчик программ, в самом банке пишутся, в
        основном, "примочки".
        Зато используется большое количество стороннего прикладного и специфического софта. Поэтому обязательно должен существовать
        большой отдел сопровождения, как его не называй. Именно эти люди
        и должны писать ТЗ и руководства пользователя. Разделение функций сопровождения и развития совершенно противоестественно.
        Не очень понял на счет регламентов. Обычно бывает отдел compliance или "банковской методологии". Они и пишут все внутренние процедуры и регламенты. IT их автоматизирует.
        А программистам, требующим классических полных исчерпывающих ТЗ, IMHO, вообще не место в банке. Все-таки речь идет о прикладном программировании и разработчики должны ориентироваться в предметной области.

        Комментарий


        • #5
          Отдел банковских технологий нужен в большом банке для решения следующих проблем:
          1) создания единой технологии совершения банковских операций во всех подразделениях банка. В крупных банках существуют "местные" особоенности отдельных филиалов.
          2) для решения вопросов на стыке отделов. Например, между кредитным и бухгалтерией и т.д.
          3) для разработки или оценки проектов внедрения новых банковских продуктов
          4) и т.д.

          В небольшом банке ОБТ не нужен - слишком дорого содержание этих спецов.

          Всем успехов!

          Комментарий


          • #6
            Как интересно! Зашла случайно, а тут мне косточки перемывают :-)))

            Не знаю насчет маленьких банков, не привелось работать (почти) :-)
            А в крупных банках такой отдел (управление) просто необходим. Несмотря на то, что у нас много "чужого" софта, практически весь софт разработан все равно по нашей постановке. Постоянно возникают новые бизнес-задачи и решать вопрос о необходимости их автоматизации вообще, а также о конкретном способе автоматизации приходится нам. Если автоматизировтаь невозможно, а также "рядом" с автоматическими функциями нужен регламент. Это тоже наша задачка. естественно, совместно с юристами, бухгалтерами и т.п. Недавно создали отдельное управление, которое вроде как должно регламенты писать. Если задача связана с автоматизацией ( а что с ней не связано ?), то все равно или мы пишем или под нашу диктовку.
            То, что постановщики должны быть "из бухгалтерии" - это просто бред... Не знаю даже что сказать. Жалко мне тех бухгалтеров, которым приходится ТЗ писать... Это все от бедности. 80% наших задач бухгалтер просто не в состоянии был бы осознать, о чем речь вообще, да и не его это дело.
            Отдел сопровождения тоже не должен писать ТЗ, он должен руководства пользователя писать, типа "нажмите клавишу F6, чтобы вывести отчет на печать". А ТЗ он писать не может, т.к. не знает ни бизнеса, ни той же бухгалтерии.

            Успехов всем!

            Комментарий


            • #7
              Alenka!
              Я завидую твоему банку, потому что в у него есть такие спец-ты, как ты!!! И очень сожалею, что в моем банке, ОБТ занимается больше какой-то ерундой. Технологи моего банка
              1)решают вопросы методологии бух. учета,
              2)пишут, а чаще просто согласовывают регламенты, ведут их базу данных;
              3)вносят безумные предложения по каким-то новым направлениям банковской деятельности и т.д.
              Короче заминаются чем угодно, лишь бы не писать постановки. Поэтому постановки, а чаще это просто маленькие заявки на доработку, у нас пишут функциональщики совместно с программистами. Роль технологов обычно сводится к постановке визы: "Все нормально, существующей банковской технологии не противоречит!"


              Комментарий


              • #8
                Я думаю, что если организация занимается разработкой и внедрением ПО "для себя", причем неважно, пишется ли масштабная система или "примочки", процесс создания ПО должен регламентироваться соответствующими нормативными документами, принятыми на уровне высшего руководства. Регламент должен охватывать все стадии цикла разработки ПО от проектирования до приемки в эксплуатацию и все подразделения организации, задействованные в процессе создания ПО, должны действовать в его рамках. Разумеется, перечень документов, создаваемых на каждом этапе и требования к ним, также являются частью регламента.
                В простейшем случае, очевидно, такими документами должны быть Техническое задание и Руководство пользователя. Наличие ТЗ необходимо не только программистам, но и заказчикам разработки, поскольку оно является основой для приемки готового ПО в эксплуатацию. Если не будет ТЗ, то невозможно будет определить, соответствует ли разработанное ПО изначально поставленной задаче.
                Что же касается вопроса "кто должен разрабатывать ТЗ", то, на мой взгляд, он не является принципиально важным и может решаться исходя из реальной ситуации и сложившихся традиций. Конечно, хорошо, когда есть отдельное подразделение, в чьи основные функции это входит, но это само по себе не является гарантией высокого качества процесса. Более важным является вопрос, кто утверждает готовое ТЗ или, иными словами, санкционирует разработку, и согласование каких подразделений необходимо предварительно получить.
                Ну и, разумеется, регламент создания ПО должен находиться в рамках общей ИТ-стратегии банка, т.е. должен быть увязан со смежными вопросами приобретения готового ПО, эксплуатации оборудования и т.д. и т.п.

                Комментарий


                • #9
                  To Bolt:

                  >> процесс создания ПО должен регламентироваться соответствующими нормативными документами, принятыми на уровне высшего руководства. Регламент должен охватывать все стадии цикла разработки ПО от проектирования до приемки в эксплуатацию и все подразделения организации, задействованные в процессе создания ПО, должны действовать в его рамках.

                  А Вы пытались согласовать такой регламент, когда ряд руководителей функциональных отделов считает, что автоматизирован должен быть каждый "чих" их специалистов, а времени на разъяснение этого "чиха" у них нет? Учтите при этом, что высшее руководство банка не имеет четкой позиции по этому вопросу, а только свысока наблюдает за спором. Что останется после вашей редакции регламента после 3-4 кругов согласования?

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

                  Это я говорил про "правильный" отдел банк. тех-ии.

                  Всем успехов в нашем нелегком труде!

                  Комментарий


                  • #10
                    Уважаемые коллеги!
                    Вчера я получила целых 3 предложения прислать наше положение об Управлении технологий :-))
                    Сделать этого я не могу, т.к. документ сей является конфиденциальным. Кроме того, он настолько "заточен" под довольно сложную структуру нашего банка, что вряд ли может быть полезен банку, который только собирается создать такой отдел.
                    Однако обещаю поделиться своими идеями о том, каким может быть такой документ и как вообще начать создавать такой отдел, т.к. присутствовала при создании такого отдела в 2х банках. Один раз затея провалилась и это был мелкий банк ;-)
                    Второй раз - через 5 лет Управление достигает 50 человек !
                    Вот вернусь из отпуска (30-го) - и если еще будет интерес, че нить скажу :-))

                    Комментарий


                    • #11
                      Технологи моего банка
                      1)решают вопросы методологии бух. учета,
                      2)пишут, а чаще просто согласовывают регламенты, ведут их базу данных;
                      3)вносят безумные предложения по каким-то новым направлениям банковской деятельности и т.д.


                      Сам я работал в двух банках, где был в наличии ОБТ. Причем организация была следующая: есть Управление Технологий, куда, кроме прочих, входили отделы Банковских технологий и Программного обеспечения.
                      Технологи принимали заявки, проводили экспертизу с привлечением экспертов, в том числе и от отдела ПО, а потом, если надо, выполняли постановку задачи для отдела ПО.
                      Причем, до полноценного ТЗ дело редко доходило - когда задачу ставит грамотный специалист обычно хватает развернутого "описания технологии".

                      Резюме такое: очень хорошая и эффективно работающая структура. Да, кстати, сам я был там начальником отдела ПО.

                      Главное тут то, что технолог берет на себя "юзера". Он может поговорить с бухгалтером на его языке с одной стороны и с программистом на его языке с другой. А то, что программисты и технологи работают в рамках общего управления дает сразу три выгоды:
                      1. Не дает им поругаться друг с другом.
                      2. Не дает бухгалтерам поругаться с программистами (то есть, "клиент доволен").
                      3. Не приводит к появлению "кривых" решений, что бывает при решении технологических вопросов "программистскими" методами (вроде, выльем воду и задача сведется к предыдущей).

                      Комментарий


                      • #12
                        To Alex_Altay

                        Как раз в ситуации, когда руководители подразделений отстаивают интересы своих ведомств, "тянут одеяло на себя", наличие утвержденного регламента очень помогает, т.к. уменьшает возможность для участников устанавливать (навязывать) свои правила игры. Конечно, придется один раз помучиться с его согласованием, но зато потом конфликтов должно быть меньше. Разумеется, от позиции руководства банка зависит очень многое, но я еще не встречал руководителей, которые были бы в принципе против порядка, вопрос в том, что понимается под "правильным" порядком в данном конкретном случае, но, в любом случае, повторюсь, даже самый плохой, компромиссный регламент, лучше, чем его отсутствие.
                        Что же касается использования отдела банковских технологий в качестве арбитра, разводящего по углам ринга отдел автоматизации и, например, бухгалтерию, то мне эта идея не представляется удачной - таким образом мы только увеличим количество пауков в банке (в прямом и переносном смысле). Задача не в том, чтобы найти рефери для разрешения конфликтов, а в том, чтобы конфликты возникали как можно реже и только по объективным причинам (выход за рамки бюджета, задержка сроков и т.п.).

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


                        Комментарий


                        • #13
                          И все-таки, господа, я вас не понимаю.
                          Во-первых. У нас, например, есть четкая установка - IT является обслуживающим подразделением, как хозяйственное управление и курьеры. Все бизнес-подразделения должны восприниматься как "внутренние клиенты", а клиент, как известно всегда прав. И если руководители этих подразделений высказывают неудовлетворенность работой IT, то никакие регламенты не помогут. Это не значит, что они не нужны, они помогают упорядочить работу.
                          Во-вторых. Читая о неких технологах я несколько в растерянности. Ведь дело происходит не в чистом поле. В каждом банке есть АБС и большинство проблем можно решить путем ее настройки. А если и нет, и необходима разработка отдельного приложения, то оно должно работать в тесном взаимодействии с АБС. Таким образом человек, решающий что и как автоматизировать должен быть знатоком существующих систем. Интересно, какова же должна быть численность IT, чтобы технологи были отдельно, а сопровождение и разработка в рамках АБС отдельно? Такого, по-моему, даже в Диасофте толком добиться так и не удалось.

                          Комментарий


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

                            Комментарий


                            • #15
                              Уважаемый PAB!
                              Давайте разбираться по порядку:

                              >>> У меня такое ощущение ,что уважаемая Алена слишком много на себя берет.
                              Alenka ничего, что подходит под определение "слишком много", на себя не берёт. Я поднял тему данной конференции для того, чтобы разобраться, что есть банковский технолог, и какова роль и место данного подразделения в общебанковском распределении работ. Если Вам, почтеннейший, что-либо непонятно, Вы спрашивайте или выражайте своё мнение, а давать личностную оценку участникам обсуждения - некорректно. Тем более в контексте какой-то непонятной сентенции "синдром большого банка".

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

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

                              >>> Синдром большого банка срабатывает
                              Потрудитесь, пожалуйста, объяснить Вашу мысль.

                              С уважением.

                              Комментарий


                              • #16
                                2 PAB
                                По поводу перехода на личности полностью поддерживаю Механизатора.
                                Ваша оценка деятельности Управления Технологий основывается на Вашем же предположении: <<наверняка это Управление собирает заявки>>. А может и не только собирает?
                                И, наконец, в обязанности непосредственно пользователей, <<имеющих отношение к банковским операциям>>, не входит разработка <<идеологии процедуры>>, им бы с текучкой разобраться.
                                Васильев А.Б.

                                Комментарий


                                • #17
                                  Не скатываясь на вялое переругивание, хотелось бы узнать у уважаемого ALL-a, а откуда вообще берутся в ваших банках заявки, есть ли их градации и как верстаются планы работ?

                                  Комментарий


                                  • #18
                                    Даже не знаю, кому отвечать.

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

                                    По большому счету может существовать достаточно приемлемый вариант для руководства, при котором автоматизаторы (может, не все) постоянно находятся в курсе нововведений в части учета, а бухгалтеры (и иже с ними) неплохо понимают, что примерно в машине происходит, когда они жмут на кнопку. Естественно, вариант спорен и для многих в силу сложившейся практики негоден. Но в качестве идеала?

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

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

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

                                    Если что упустил - дополню позже.

                                    Комментарий


                                    • #19
                                      Да-а... Крутой у Аленки банк. 50 технологов, еще и отдельное управление регламенты пишет. И много чужого софта. Постановщики из бухгалтерии - это бред, и их очень жалко, а сопровожденцы не знают ни бизнеса, ни бухгалтерии.

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

                                      Ага. Синдром маленького банка.

                                      Надеюсь, я не перешла на личности?

                                      Комментарий


                                      • #20
                                        marina, синдром маленького банка - это когда начавт с замом управляющего на карачках сетку протягивают.
                                        Добро всегда побеждает зло. Потому что кто победил - тот и добро.

                                        Комментарий


                                        • #21
                                          Accounter , тогда это не мой случай...
                                          Однако... если серьезно... так было - на моем прошлом месте работы. Но это был филиал большого банка.
                                          А начавт там не только сетку протягивал, но и компутеры таскал, и счета с поставщиков собирал, и софт настраивал, и телефоны подключал, и отчетность, и анализ... блин... и ТЗ с меня не требовал на каждый чих... Эх... Леша, где ты???

                                          Комментарий


                                          • #22
                                            Здравствуйте!
                                            Я новичок в Вашем форуме.
                                            Прочитал сообщение от marina, и загорелся желанием выразить ей свое восхищение. На моей практике все ТЗ приходилось писать программистам.

                                            P.S. Создал новую тему по оценке экономической эффективности. Помогите, если кто может.

                                            С уважением, Солнышко.

                                            Комментарий


                                            • #23
                                              На этот форум попал случайно через ссылку на Andersа. Думаю дискусию надо продолжить, тема очень актуальна. Ввиду того, что принимаю участие в самом разгаре дискусии(надеюсь на продолжение поэтому не в конце), то сразу очень много вопросов и практически всем.
                                              Давайте по порядку:
                                              1)ТЗ на банковский продукт объясните кто заказчик и кто разработчик, только прошу определить в понятии разработчик не только разработчика ПО. но системного разработчика всего банкоского продукта. У меня получается заказчик - банк, разработчик - банк.
                                              2) Далее почему обсуждаем только ТЗ и Рук. пользователя? Ведь необходимы (да еще как) еще документы, хоть по ГОСТ 34 ( Пояснительная записка,
                                              программа испытывний, описание контрольного примера, описание ПО и т.д.), хоть по западному стандарту ( мастер план, Архитектура продукта, Общее видение задачи, Голссарий, опять же описание ПО, руководство системного программиста, журнал жизненного цикла системы и т.д). Что думаем?
                                              3)Отдел или управление технологий это прежде всего методологическое подразделение. Но оно не должно выходить за рамки (какие?) и превращваться в отдел развития банка.
                                              4) Далее вопрос к Alenka как по Вашему( твоему) функции подразделдения технологий пересекаются с функциями управления информационных (прогамисты, технари, прием-передача данных, сети, администрирование, АБС)? Просто наверное мало технологам организовывать контакт между бизнес подразделениями (фронт офис) и программистами, надо же во-первых организовать "зачин" по новому банковскому продукту (технологии) между бизнес подразделениями и "бухучетчиками", доказав необходимость такого нового продукта вообще, далее, во-вторых, после уже разработки ПО и эксплуатационной документации надо организовать деятельность по предпродажным (реклама, план продаж, схема продаж) и продажным мероприятиям по сбыту продукта, а также иметь периодическиую информацию: приносит ли эта уже внедреннная банковская услуга (технология) прибыль и не пора ли ее снимать или модернизировать?
                                              5) Далее Alenka нельзя ли описать деятельность Ваших 50 человек в управлении технологий так: функция управления - к-во человек? А насчет конфиденциальности положения о подразделении, Лично я могу выслать проект положения о Центре координации разработки банкоских продуктов, который мне очевидно предстоит возглавить, но конечно только на E mail и как говорят взаимообразно, то есть поменять его на нечто адекватное.
                                              Жду ответов от всех
                                              Робяты давай те дискусировать
                                              Есть еще оо-очень много вопросов и соображений

                                              Комментарий


                                              • #24
                                                Vladkz
                                                Я хоть и не Alenka , но с удовольствием бы ознакомился с Вашим проектом положения. Может, тоже окажусь полезным чем-нибудь.

                                                Комментарий


                                                • #25
                                                  KapDm
                                                  - написание простенького отчета
                                                  - заливки справочников
                                                  - и.тд.
                                                  делаются без бумаги, оперативно


                                                  Кто останется крайним, если, скажем, оперативненько залит (и даже оперативненько протестирован) не тот (устаревший, неполный и т.д.) справочник? А по нему весь день колотили и _отправляли_ документы...
                                                  Также довольно неприятно переделывать по нескольку раз простенький отчетик только по той причине, что заказчик отчета не продумал выходную форму сразу.
                                                  К чему веду: любое изменение или дополнение в системе должно иметь, как минимум, документированное обоснование. В случае небольших по объему работ, речь, конечно, идет не о ТЗ. Если работа разовая - переделка простенького отчета, то достаточно служебной записки, оставшейся в архивах хотя бы электронного документооборота. Если работа регулярная (к примеру... обновление справочника БИК) - закрепленная соответствующим регламентом - исполнитель, регулярность, время исполнения и т.п.).

                                                  Хорошо, если в Банке есть служба занимающаяся ТЗ и регламентацией. Если таковой нет, то весь этот "бюрократизм" выгоден в первую очередь ИСПОЛНИТЕЛЮ.

                                                  Комментарий


                                                  • #26
                                                    Обсуждаемая проблема- частный случай преодоления стыка между людьми разных направлений деятельности. " В одну арбу запрячь.......и трепетную лань" (с) -
                                                    Здесь это называется постановщиками (те, кто запрягает). Про другую область -см. рядом: http://www.bankir.ru/ubb/Forum9/HTML/000183-3.html
                                                    WBR

                                                    Комментарий


                                                    • #27
                                                      Anders Послал на e mail. Ответ жду на свой e mail

                                                      Комментарий


                                                      • #28
                                                        При создании своих разработок обязательно пишем следующие документы
                                                        - Постановка задачи (она же ТЗ - кому как больше нравится). Делится на 2 части - для юзера и для програмера.
                                                        Для юзера - перечислены все его требования (чтоб было потом что принимать, его не интересует создание файла ORDER и т.д)
                                                        Для программиста - перечислены способы реализации вышеуказанных требований. Детализация - до полей БД .
                                                        - План тестирования (то что VladKZ называет контрольным примером)
                                                        - План внедрения (запускаем с нуля или конвертируем, сколько идет опытная эксплуатация..)

                                                        Запускаем в опытную...
                                                        Изменения вносятся как дополнения постановки.
                                                        Запуск в промышленную эксплуатацию - оформляется актом (что юзера получили, что хотели)
                                                        Далее ведем что то типа журнала эксплуатации - какие изменения сделаны и почему.

                                                        Немного нудно, зато не возникает вопросов типа Вы сделали не то, что нужно...


                                                        Желательный уровень детализации

                                                        Комментарий


                                                        • #29
                                                          Дополнение к вышеописанному. Естественно, весь цикл (от постановки, до акта о внедрени) делается для более менее приличных по объему задач. Мелочи, както
                                                          - написание простенького отчета
                                                          - заливки справочников
                                                          - и.тд.
                                                          делаются без бумаги, оперативно

                                                          Комментарий


                                                          • #30
                                                            Вопрос к Аленке:
                                                            Насколько большой ваш банк (сколько проводок в день например, если многофилиальный - то в одном подразделении)?
                                                            Эта информация не является конфиденциальной.

                                                            Комментарий

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

                                                            Свернуть

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

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