ПО для аналитического управления

Уважаемые, господа !

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

С благодарностью...

Quqa. Приятно встретить человека, у кого те же чаяния что и у тебя. Я к тому, что тоже искал, что-то подобное, но до сих пор безуспешно. Может не там искал, а может просто не успел. То что есть не работает, то что работает практически не применимо в реальной жизни. Перехожу к ответу. Я немного разбираюсь в компутерах, а поэтому мне было не сложно делать какие-то примочки для своей основной работы (я занимаюсь аналитикой). В свое время, не мудрствуя лукаво взял книжку "Microsoft Access 97", почитал и сделал базу данных, потом еще одну, и еще... И знаешь, никогда не жалел. Скорость обработки информации повышается многократно, объем информации, для людей непосвященных кажется просто неподъемным, но все работает, процесс идет контора пишет. А для нормальной аналитики обработка огромных объемов информации просто необходима. Причем, в большинстве случаев, именно информации, а не данных. Вы согласны со мной? Ведь это одна из причин использования самоделок. Материал для аналитики как правило просто никакой. Мы же понимаем, что балансовые данные это не материал, это основа, это синтетика с большим количеством натяжек. А на необходимые нам данные, почему-то ни у кого нет времени. Все делается на персоналках в лучшем случае в Ёxcelе, а обычно в Wordе или просто карандашом в амбарной книге. Я утрирую, но все же. Поэтому надо начинать с начала. Я имею в виду подготовку материала. Пока для меня свет в окошке это SQL Server 2000. Мечтаю создать нормальное хранилище данных. Во-первых это последний писк моды, а во-вторых это просто удобно. Все в одном месте, все как в армии пострижено, покрашено, посыпано песком. Рай для аналитика.
Вторая проблема, с которой сталкиваешься покупая готовые аналитические программные продукты, это отсутствие гибкости. А для коммерческого банка это вообще нонсанс, чтобы для принятия решения требовался месяц, а может и не один, пока господа разработчики соблаговолят перенастроить систему в соответствии с изменившимися потребностями. Нет, они не виноваты, это объективно не происходит мгновенно. Даже на небольшом участке могут возникать такие вариации на тему, что даже опытный программист не в силах предусмотреть все. А если проблема требует структурных изменений, то ее решение затягивается на неопределенный срок. Поэтому, хочешь избежать - бери все в свои руки. Единственное условие, как мне кажется, не нужно допускать, чтобы система переросла тебя. Нужен полный контроль. Хотя, самоделки редко бывают сложными, отчасти это следствие невысоких программистских способностей специалистов, отчасти от отсутствия универсальности, что в данном случае скорее плюс, чем минус. Я был бы не против поболтать об этом по телефону, мыслей много, все не напишешь, поэтому оставляйте координаты - поговорим. А для Форума:
Я считаю, что это крест аналитики - лабать свои припарки кто в чем может. И если кто-то авторитетно скажет мне как лучше это делать, я буду очень благодарен тому человеку. А если кто-то поможет нам с Quqa найти что-то действительно стоящее, мы с Quqa такого советчика просто на руках носить будем. Quqa, поддержишь?

[MichaelS]

to Quqa : Большинство аналитических программ ориентировано на данные
из опердня т.е это остатки или обороты на счетах
Путем складывания умножения деления и т.п можно получать всевозможные показатели. Но как правило ткаих показателей нехватает для реального анализа и прогноза фин. состояния.
Но тем не менее можно взглянуть например на комплекс АФСКБ от фирмы ИНЕК ( www.inec.ru ) Мы некоторое время ей пользовались.
Но любое чужеродное ПО требует функций экспорта от вашего опердня
как правило более менее нормально работает при четкой и аккуратной организации учета опреаций в банке , детализация зависит от глубины аналитического учета по различным статьъям.

to Колобок : Я согласен с Вами что наиболее удобную для себя вещь можно сделать только самостоятельно. Но согласитесь что неудобно вести собственные базы данных , когда в банке стоит АБС .
У нас АБС самописная поэтому я для наших аналитиков написал небольшое приложение , позволяющее ми моделировать показатели на основе данных опердня : остатки - обороты - обороты в корреспонденции (в нац. валюте в валюте счета и т.п)-курсы валют.Причем все это можно получать за периоды по дням и т.п После этого они все это добро выгружают в Excel где уже и строят свои модели графики и т.п.
Процентов 70 запросов это удовлетворило. Сейчас хочу добавить туда возможность получать данные из кредитного модуля и других прикладных подсистем АБС . Я думаю это закроет процентов 90 запросов.
Так вот к чему это я. В любой промышленной АБС как правило есть генератор отчетов со встроенным языком , попробуйте изучить его и использовать в своей работе.

[Vodianov]

Добрый день Quqa!

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

1. Системы, которые позволяют что-либо анализировать, основываясь на кем-то вычисленных агрегатах (например балансе или значениях нормативов)
2. Аналитические модули к АБС, которые считают аналитику на основе первички из этой собственно АБС
3. Хранилища, которые закачивают первичные данные (сделки, проводки и т.п.) из АБС(или не АБС) в свою базу.

Работая с системами типа 1 рано или поздно скорее всего возникнет желание перейти к 2 или 3, потому что данных начнет не хватать.
Системы 1 давно существуют на рынке и их не так мало.
Рассказал бы о них, но мнение несколько предвзятое )
По поводу 2 нужно обращаться к разработчикам Вашей АБС.
Системы класса 3 тоже существуют. Вот наша, к примеру, "Контур Корпорация". Рекламой заниматься не буду, если интересно - www.iso.ru или спрашивайте что интересно - расскажу поподробнее.

Но справедливости ради нужно сказать, что удел аналитика на сегодняшний день в большинстве банков - Excel

Колобку: "Корпорация" почти на SQL Server 2000 (пока на MS SQL 7.0) и подход к построению очень похож. Если интерес не увял - можно пообщаться на эту тему.

Привет ВСЕМ !!!
Прошу извинить меня за молчание - были проблемы с Инетом (банк лимит перебрал, всех отрубили до выяснения).

to Колобок. Полностью поддерживаю. Нужна программа гибкая и лучше что бы она не создавала свою базу данных, а высасывала ее из существуещей АБС. Использование "MS Access-97" хорошая идея, хотя я небольшой специалист в компутерах, надо будет изучить. Хотя на создание и ведение баз данных мне не хватит времени - текучка все съедает. (ovv@sngb.ru)

to MichaelS. Мы использовали Инек, но установленная версия не работала с лицевыми счетами - только 1-го и 2-го порядка, говорят, что сейчас вышла новая версия - работает и с 20-тизначными... Я ее не видел. На данном этапе установлен Forpost, мы там пишем нужные нам информационные продукты выкачки инфы, после экспортируем в Excel и там обрабатываем. И полностью согласен, что удел аналитиков на данный момент - Excel, т.к. все ПО ограниченно-убого для анализа.

to Vodianov. На сегодня к нам поступили предложения от "Ланит" и "Прогноз". После того как получим демо - постараюсь не забыть поделиться мнением.

Я бы предложил следующий вариант:
из Excel-a иметь доступ к данным АБС. АБС обладает всей
информацией, а Excel позволяет обрабатывать эту
информацию. Данный вариант довольно успешно работает при
минимальных затратах тех.отдела.

Коментарии ?

во-во, вот именно по этому написание формул(не SQL выражений
т.к. это слишком сложно для юзера) мы переложили на юзера.

[Skin_Head]

Ребята, извините, что вмешиваюсь, но тема мне близка... я экономист вообще-то, но с компами нормально все... так вот, мне кажется, что сейчас дело даже не в осутствии/наличии необходимого ПО, а отсутствии нормальной системы хоть мало мальской управленческого учета, то что повсеместно внедрил ЦБ своими дурацкими 61-ми правилами - во многом не то что непрактично, а эклектично... действующий план счетов просто не предназначен для расчета таких вещей, как обязательные нормативы, например... так что уж о внутреннем анализе говорить?? кто экономист, поймет - вы пробовали когда-нить, глядя в баланс, (даже пусть в разрезе АНАЛИТИЧЕСКИХ счетов) оценить деятельность функциональных подразделений? а струрных? дело не в ms sql7.* - 2000, Oracle или другой субд, дело в том, что нет СИСТЕМНОГО подхода к учету денег в банке. вот такую систему я бы с удовольствием купил, если б где увидел (или шефа заставил купить), а базу с распределенной архитектурой можно потом за месяц накатать со всеми интерфейсами на линуксах и под веб, да так что бил гейтс плакать будет...

[Zepp]

Аналитическое ПО для банка

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

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

С наилучшими предложениями,
Zepp

было бы интересно

[AGE]

очень интересно

to Zepp: Поделись опытом - просим !

[Zepp]

ОК. За выходные напишу.

Best regards,
Zepp

[gs]

Поддерживаю просьбу!

[Zepp]

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

Примерно шесть лет назад (еще во времена действия старого плана счетов) пришлось мне ставить работу по банковской аналитике. Опыта и специальных знаний не было, поэтому пришлось начинать практически с нуля. Первым шагом, естественно, было изучение инструкций ЦБ - в частности знаменитой инструкции N1, где как раз и описано какие нормативы есть, как они расчитываются и каковы их граничные значения. Расчет строился главным образом на значениях балансовых счетов, но были к сожалению и неприятные исключения типа сумма кредитов, возвращаемых в течение 30 дней и т.п. Чтобы получить значение вышеупомянутой суммы кредитов, нужно было уже "лезть" по лицевым счетам, т.е. выверять информацию через бухгалтерию и кредитников. Таким образом, первая же попытка построения аналитики показала, что стандартного в этой работе будет мало - ЦБ к сожалению полноценных аналитических инструментов в свои инструкции не заложил и "дробить гранит науки придется подручными средствами".

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

Работа состояла из четырех этапов:

1. сбор первичной информации.
2. расчеты и первичный анализ.
3. визуализация результатов.
4. интерпретация результатов.

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

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

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

1. При проведении анализа в качестве показателя результативности нужно применять не бухгалтерскую, а экономическую прибыль. Бухгалтерская операционная прибыль/убытки = Доходы - Расходы, т.е. все данные для расчета содержатся в балансе. При расчете экономической прибыли необходимо сравнивать с рынком, то есть необходимы внешние данные. Применительно к банковскому контроллингу важнейшим внешним показателем является ставка альтернативного финансирования - ставка доходности безрискового размещения средств. В международной практике в качестве САФ берут обычно ставку по государственным ценным бумагам.

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

С учетом вышеописанного наш план заключался в получении результатов по сделкам банка с клиентами, калькулированных по методике ставок альтернативного финансирования, и последующего агрегирования результатов в различных разрезах. При этом мы хотели достичь детального объяснения примерно 80% прибыли в терминах клиентов, продуктов и бизнес-единиц. Стопроцентное объяснение потребовало бы выполнения громадного объема рутинной работы, так как сделкой нужно считать и текущий счет физического лица с остатком 3 рубля.

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

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

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

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

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

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

Здесь я хочу прервать изложение и вернуться к вопросу об аналитическом ПО, с которого началось обсуждение.
Мне представляется, что система аналитики принципиально является человеко-машинной и стандартизуется в очень малой степени, поскольку аналитик должен отвечать на те вопросы, которые встают перед ним СЕГОДНЯ и отвечать ДЕТАЛЬНО. На подобные запросы ни один внешний разработчик среагировать со своим софтом не сможет. Есть правда как минимум одна система, в которой по моим ощущениями 5-летней давности, аналитику было бы комфортно, но страшно дорогая - R/3 SAP AG (среднему российскому банку не по зубам, т.е. не по деньгам). В R/3 концепция построения такова, что все данные изначально покрашены, пострижены и разложены по полочкам. Соответственно, роль доступного (недорогого) стандартного специализированного программного обеспечения (т.е. такого которое непосредственно выдает отчеты для передачи конечному заказчику, например управляющему) в работе аналитика по моему мнению НЕ ВЕЛИКА. По-моему мнению, аналитик безусловно должен быть квалифицированным пользователем, который умеет работать с базами данных (в смысле обрабатывать, а не заполнять первичкой), электронными таблицами и математическими пакетами (типа Statistica или SAS). Что касается программного обеспечения, которое применяли мы, то по вышеобозначенным этапам это выглядело так:

1. сбор данных - данные из опердня поступали в формате .dbf. Использовались программы Fox Pro и Excel актуальных тогда версий.

2. расчеты и первичный анализ - Fox Pro, Excel и Statistica.

3. визуализация - Excel и Statistica.

Как видите, никаких особых наворотов.

Best regards,
Zepp

PS Что касается контроллинга, то его нужно вероятно обсуждать не в разделе автоматизации, а где-то в экономическом блоке. Если есть интерес, давайте переберемся в более подходящий раздел и продолжим там.

[Skin_Head]

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

Схема интересная.

Достаточно ли для отчетности трех показателей
остаток, оборот, кол-во документов или счетов ?

То-же самое можно достигнуть универсальной функцией

function ВернутьЛицевыеСчета(КодПродукта,КодКлиента,...):String;
которая будет возвращать список лицевых счетов, тогда все показатели можно выбрать из опердня функциями Остаток,Оборот

ZEPP!! не пропадай! хоть мыло оставь свое... плз

Банковская аналитика дело тонкое Уровень автоматизации зависит от
количества денег которые можно на это выделить, можно создать систему
основаную на супер аналитических средствах, но стоить будет самолет.
Основа инструментарий фирмы SAS институт. Более приемлемое по цене
ORACLE EXPRESS. Такие системы под заказ делает моя компания. Если есть
интерес то пишите

[Zepp]

To kos:

Трех показателей недостаточно, хотя и с ними что-то можно сделать.

Best regards,
Zepp

[Ross]

Zepp,
я вижу ты достаточно свободно ориентируешься в данном вопросе.
Как составить классификатор, учитывающий все параметры, перечисленные тобой в твоём трактате, в новом плане счетов, если нумерация счетов уже регламентирована Правилами бухучёта в банках ╧61.
Также поддерживаю волеизъявление народа увидеть твой профиль.
Спасибо.

[PSrg]

Приветствую всех,

Несколько соображений по этому поводу --

1. Стандартная формализация данных под
стандартными методиками --

Может быть, есть возможность где-то найти материалы
с рекомендациями по формализации данных для аналитики
и не изобретать велосипед? Например, в моей области -
внешние торговые системы (шлюзы к биржевым площадкам
и к inter dealer markets, интеграция с front-to-back
office) очень похожая ситуация. С одной стороны,
люди ломают голову, создали техкомитет в Науфор
и пытаются придумать стандарты на ходу, с другой
- есть западные открытые протоколы для financial
messaging, все уже придумано, просто можно взять
интересующее подмножество событий - то есть заимствовать
фрагменты, которые изначально уложены в схему, где все
в целом вяжется друг с другом.

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

2. Не подскажет ли кто-нибудь, есть ли под имеющимися
на рынке продуктами - Диасофт,Кворум,RS и т.д. -
модель данных, построенная примерно по таким
концепциям:

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

- События могут ветвиться при компоновке сделок.
Т.е., сделка заключается на одну сумму, исполняется
двумя перечислениями и наоборот, т.е. система офсетных
сделок one-to-many? Это бывает нужно и для аналитики,
и для того чтобы 'размотать' сделки ретроспективно
для (полу)автоматического отката - rollback - с
автоматическим 'play forward' пересчетом производных
операций после внесения исправлений.

И т.п.

Есть ли в каких-то наших системах реализация с подобным
уровнем гибкости на уровне модели данных - хотя бы
не под всей АБС, а под front-through-back подсистемой?
Или чья-то АБС-платформа к этому ближе всего?

3. Не подскажет ли кто-нибудь, есть ли под имеющимися
на рынке АБС модель синхронизации данных не на СУБД,
а на уровне маршрутизации финансовых сообщений -
типа fiancial application network или Hub финансовых
сообщений? Или пусть АБС в целом СУБД-ориентированная,
но имеющая шлюзовый модуль к сетям сообщений?
То есть чтобы АБС погла получать события (сделки)
не только вводом со своих родных GUI-клиентов (АРМ),
и не записями в свою СУБД, которые делает 3rd-party клиент,
а сообщениями из внешних подсистем, в свой
интерпретирующий модуль? Или хотя бы какой-то зачаток
подобных технологий у кого-то?

Буду очень благодарен за совет.

Psrg,
Скрин Маркет Системз ЗАО http://www.trading-technology.ru/proj5.htm
--------------------------------------
-- интернет-трейдинговые-дилинговые системы --
-- динамическое управление рисками производных --
sergp@futures.msk.ru

To Zepp: а как в твою схему могут вписаться другие показатели ?
например процентные ставки по договорам(кредиты,вклады)

PS: может сначала нужно определить задачу

1) Я рассматриваю отчетность как универсализацию обработки уже
существующих данных в АБС и предоставление их пользователю.

2) Разработка ПО для отчетности не затрагивает структуру АБС,
т.к. это отдельный вопрос и в каждой подсистеме структура
данных оптимизирована для данной задачи. АБС содержит
всю необходимую информацию.

3)Можно выделить качественно несколько уровней:
а) предоставление готового отчета
б) предоставление суммарных данных в общей форме
в) предоставление доступа к данным и инструмент для их обработки

[Zepp]

To PSrg:

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

To kos:

Извините за назойливость, но еще раз советую посмотреть отечественную книжку "Контроллинг в бизнесе", главу про банковский контроллинг. Ставки по кредитам и депозитам сравниваются со ставкой альтернативного финансирования. Общий принцип таков: если ставка активной операции меньше САф, то сделка операционно убыточна и т.д.

Best regards,
Zepp

[Skin_Head]

уважаемый зепп, в извините за назойливость меня также, но повторяю вопрос - нельзя ли на классификатор посмотреть? ежели его нет - то так и кажите - нет. а то слова-то все умные и правильные, а где реальную методу взять (о чем PSgr говорит), никто не знает... может, действительно не нужно велосипед изобретать? в книге про контроллинг это есть? (я про альтернативные планы счетов)

[Zepp]

To Skin_Head:

Классификатор нужно составить Вам САМОСТОЯТЕЛЬНО С УЧЕТОМ СПЕЦИФИКИ БИЗНЕСА банка, в котором Вы работаете. То что мы разрабатывали аж в 1996 году попробую найти. Поверьте - не жалко. Кстати, как бы его прямо здесь в виде файла прицепить?

Best regards,
Zepp

[PSrg]

-- kos,

"1) Я рассматриваю отчетность как универсализацию обработки уже
существующих данных в АБС и предоставление их пользователю."

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

"2) Разработка ПО..."

-- Понятно, естественное следствие того о чем уже
говорилось. Тогда речь должна идти уже о совершенно конкретных
вещах - определить возможный круг аналитических исследований
на том объеме "первички", которым Вы располагаете в "своей" АБС, дальше вопрос касается только конкретных механизмов обработки -
как доступаться к данным, как анализировать, как складировать
результаты анализа и обеспечить быстрый доступ (т.е. Ваш п.3).
Невозможно комментировать без знания конкретной АБС, о
которой идет речь - но если есть соображения из опыта "ковыряния" конкретной АБС в свете нашего разговора, было бы интересно услышать
мнение, т.к. я в стадии выбора.

Единственное полезное соображение, которое при этом
возникает - это то, что извлечение данных следовало бы
(даже в реализации этой задачи для своего банка)
отделить от остальных составляющих этой задачи -
я имею в виду, на уровне модульности. Тогда в будущем
можно было бы, при необходимости миграции, подменить
только интерфейс к прежней АБС, а аналитическую
разработку унаследовать. По идее, на рынке должны быть
и готовые аналитические продукты такого рода. Правда,
я в аналитику включаю и управление рисками/лимитирование,
и бюджетирование поверх всего спектра банковских
продуктов (соответственно, и подразделений). Но вдруг
все-таки что-то есть готовое. Ищу и надеюсь!

Regards,

Psrg,
Скрин Маркет Системз ЗАО www.trading-technology.ru
-- интернет-трейдинговые-дилинговые системы --
-- динамическое управление рисками производных --
sergp@futures.msk.ru

[Skin_Head]

2 zepp. самостоятельно - эт понятно, так и сделаем, но, право, всегда лучше от чего-то отталкиваться изначально, проанализируем чужой опыт... умные ведь на чужих ошибках учатся (мы - частенько на своих). файл можно мне на емейл - eas@united.ru...

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

заранее благодарен

[Zepp]

To Skin_Head:

К сожалению не нашел. По памяти код классификатора выглядел примерно так

ППпппССРВВВЮЮ,

где

ПП - код продукта,
ппп - код подпродукта,
СС - срочность (в месяцах),
Р - риск (1-5 по классификации ЦБ),
ВВВ - код валюты (сейчас возможно это не требуется, нам почему-то было надо),
ЮЮ - код бизнес-юнита (подразделения).

Например,

ПП = 04 - вклады физических лиц,
ппп = 023 - вклад "Рождественский",
СС = 06 - срок 6 месяцев,
Р = в данном случае не используется,
ВВВ = RUR рубли,
ЮЮ = 06 - допофис "Измайловский".

С этим кодом открываются операционные счета, на которых открываются собственно частные вклады, а также счета доходов и расходов.

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

ПП = 03 - расходы на коммуникации,
ппп = 001 - фиксированная связь,
ппп = 002 - мобильная телефония,
ппп = 003 - пейджеры,
ппп = 005 - интернет,
ппп = 010 - междугородные и международные переговоры,
ЮЮ = 01 - управление бухгалтерского учета и отчетности.

Если что-то найду, то обязательно вышлю.

Best regards,
Zepp

[Skin_Head]

2zepp. угу, спсб... я примерно то же самое и думаю внедрить, единственная проблема - код срочности, дело в том, что его менять надо постоянно, но это еще полбеды... еще полбеды в том, что (возьмем, к примеру, кредитный модуль) на одном ссудном счете (одна сделка) может лежать несколько траншей, у которых, ессно, свои сроки погашения и все такое, для расчета обязательных нормативов берутся именно транши. вот. надо как-то их хитро учитывать, спецсубсчета для них открыть, что ли? и шпарить по методу двойной записи проводки, как в реальной бухгалтерии... но опять же придется менять код срочности (пролонгации там, просрочки всякие), так что есть ли смысл его вообще вводить? может к дате выплаты транша привязаться, прям из договора ее взять - и все дела... и распространить такой подход на все сделки (не важно, активные или пассивные инструменты). подобная система позволит строить краткосрочные и долгосрочные прогнозы по ликвидности, гэп-метод, а это любому банку нужно... что касается бизнес-подразделений, то у ЦБ сейчас есть поля для структурного подразделения (10-15 знаки 20значного счета), поэтому имеет смысл вести классификацию функциональных служб (кредитники, ценники, валютчики и все такое). вот. еще один момент - я считаю, что распространять такую схему нужно сразу на ВСЕ аналитические счета банка - чтоб системно и централизованно все было. также, есть смысл запретить бухгалтерии делать проводки со счетов разных функциональных служб (за исключением редких случаев), в дальнейшем, когда все привыкнут, можно будет строить балансы в разрезе функциональных подразделений - а это уже значит, все бизнес-схемы видно будет. единственная проблема здесь - большое количество работы для оперов (операционистов), счетов-то много будет. что касается кода валюты - у ЦБ сейчас он в счете есть, но ввести его по-новой надо все равно, тк, по их дурацким инструкциям, не ведется учет доходов/расходов в разрезе валют, по фактц производится переоценка в рубли на дату - и привет... и вообще, цбешники могут придумать (и реализовать!) самые сумасшедшие идеи, поэтому некоторое дублирование не помешает...
вот такие вот дела...