Клиенты Компании РиК > Коммерческие банки (Россия)
В пресс-релизе содержится информацию о начале и завершении каждого этапа проекта.
Следует отметить, что сотрудничество Компании РиК с большинством банков начиналось после того как для их клиентов были разработаны бизнес-планы.
Многие из этих клиентов банка ранее принимали участие в наших открытых семинарах-практикумах по управленческому учету и семинарах-практикумах по бюджетированию.
Высокое качество работ по разработке бизнес-планов привлекало внимание банков и они обращались в Компанию РиК для решения своих задач, в частности для разработки методики определения категории качества ссуды и расчета резервов при финансировании корпоративных заемщиков коммерческого банка.
В рамках каждого такого проекта планировалось разработать методику определения финансового положения по каждому типу корпоративных заемщиков (актуальных для каждого конкретного банка), а также методику расчета качества обслуживания долга корпоративными заемщиками.
На основе этих оценок ссуды должны быть классифицированы в одну из пяти категорий качества в соответствии с Положением №254-П о порядке формирования кредитными организациями резервов на возможные потери по ссудам (РВПС), по ссудной и приравненной к ней задолженности.
В завершении проектов должны быть разработаны методики расчета резервов на возможные потери по ссудам (РВПС).
Обязательное условие для всех проектов - все разработанные методики должны быть настроены в электронных таблицах, чтобы ими было удобно пользоваться и чтобы кредитным менеджерам можно было сразу преступить к работе по новым методикам.
В ходе проектов разрабатывались методики в текстовом формате и в формате электронных таблиц.
В рамках проектов были выполнены следующие работы: разработка проекта Концепции определения категории качества ссуды и расчета резервов по каждому типу корпоративных заемщиков;
презентация, анализ и доработка Концепции;
разработка методики определения финансового положения по каждому типу корпоративных заемщиков и настройка модели в электронных таблицах;
разработка методики расчета качества обслуживания долга корпоративными заемщиками и настройка модели в электронных таблицах;
разработка методики определения категории качества ссуд по каждому типу корпоративных заемщиков и настройка модели в электронных таблицах;
разработка методики расчета резервов при финансировании каждого типа корпоративных заемщиков и настройка модели в электронных таблицах;
презентация, тестирование и анализ разработанных методик;
доработка методик с учетом замечаний.
Основные результаты по проектам: методика определения категории качества ссуды и расчета резервов на возможные потери по ссудам (РВПС) при финансировании корпоративных заемщиков:
- в текстовом формате;
- в формате электронных таблиц.
Методики определения категории качества ссуды и расчета резервов при финансировании корпоративных заемщиков (далее Методика) разрабатывались на основе Положения о порядке формирования кредитными организациями резервов на возможные потери по ссудам (РВПС), по ссудной и приравненной к ней задолженности № 254-П от 26.03.04 со всеми изменениями (далее 254-П).
Основная цель данной методики – обеспечение эффективного управления рисками при финансировании корпоративных заемщиков, а также минимизация РВПС.
Для всестороннего и качественного анализа рисков при выдаче и обслуживании ссуд методика дифференцировалась по различным типам корпоративных заемщиков. Т.е. при оценке рисков учитывалась специфика бизнеса заемщиков.
Чаще всего данная методика распространялась на следующие категории корпоративных заемщиков: строительные компании;
торговые компании;
производственные компании.
Для удобства использования данной методики создавалась ее электронная модель (в формате электронных таблиц). При вводе в электронную модель всей необходимой информации о заемщике и о ссуде оценка качества обслуживания долга, оценка финансового положения заемщика, классификация ссуды и расчет резерва производятся автоматически в соответствии с алгоритмами, описанными в методике.
Таким образом перед реализацией проектов по разработке ТЗ банки активно использовали модель методики, автоматизированной с помощью электронных таблиц. Это позволяло, во-первых, обкатать разработанную методику на практике, а, во-вторых, более четко поставить задачу по автоматизации.
В большинстве случае на разработку технического задания отводилось 2-3 месяца, а затем банки переходили к непосредственной автоматизации.
Специалисты Компании РиК имееют опыт в проектировании и разработке информационных систем. В частности сотрудниками Компании РиК был спроектирован и разработан программный комплекс "ИНТЕГРАЛ", позволяющий автоматизировать процесс бюджетирования и управленческого учета.
Этот опыт применялся и в данных проектах, т.к. по сути речь шла об автоматизации процесса оценки корпоративных заемщиков. Консультанты Компании РиК имеют очень большой опыт в управленческом консультировании в том числе и в проведении диагностики предприятий и оценки их финансового положения.
При этом конечно же в ходе таких проектов должны быть учтены все требования Центрального банка, которые необходимо выполнять при оценке финансового положения заемщика, качества обслуживания долга, категории качества ссуды и расчета резерва на возможные потери по ссуде (см. Положение №254-П, а также другие дополнительные разъяснения ЦБ).
При автоматизации методики можно придерживаться двух противоположных стратегий (естественно возможны какие-то промежуточные варианты).
Первый вариант
Сделать так чтобы в системе был специальный конструктор (мастер) настройки модели. Тогда тот, кому будут присвоены соответствующие права Админа, сможет сам настраивать модель. Если нужно что-то изменить в модели, он сам без привлечения программистов делает нужные изменения.
Второй вариант
ИТ-службе (или внешней компании) ставится задача в виде ТЗ, а они уже как им удобнее и быстрее настраивают нужную модель, программируя ее. При необходимости изменений в модель (даже самых несущественных) приходится вновь ставить задачу, а программистам переделывать программу.
В данных проектах чаще всего принимались решения о выборе первой стратегии автоматизации.
При реализации таких проектов если все хорошо продумать с самого начала (на этапе разработки ТЗ), то можно практически свести к нулю зависимость от программистов. И не важно, что это будут за программисты: из сторонней компании или из банка.
Если есть возможность создать софт, который в дальнейшем не потребует поддержки со стороны программистов, то нужно воспользоваться такой возможностью.
Кроме того практика показывает, что чем больше вносится изменений в программу тем выше вероятность возникновения ошибок причем не только в новых функциях, но и тех которые уже были ранее отлажены. Это связано с тем, что многие модули в программах взаимосвязаны. Т.е. когда меняется что-то в одном месте, эти изменения могут привести к изменению программы в других местах. Поэтому если дальнейшие переделки модели методики будут осуществляться программистами, то это увеличит вероятность возникновения ошибок.
Поэтому в рамках данных проектов как правило планировалось создать такой софт, чтобы все необходимые изменения в дальнейшем можно было бы делать без участия программистов.
Т.е. в ходе разработки ТЗ нужно было продумать не только функционал программы по работе с методикой, но и функционал по настройке самой методики (модели). Наверняка ЦБ будет вводить какие-то изменения (например, потребует в обязательном порядке использовать какие-то показатели, а от каких-то показателей вообще отказаться).
Кроме того в самом банке может возникнуть идея использовать для оценки финположения заемщика другое количество факторов, отличное от того, которое используется сейчас. Или опять изменятся формы финансовой отчетности как это произошло, например, в 2011 году.
Изменения могут быть разные. Но их все можно предусмотреть (т.к. для данной задачи типов изменений может быть не так много) и сделать так, чтобы НЕ ПРОГРАММИСТ смог сам перенастроить модель методики под новые требования. Программа должна позволять это делать.
В ходе проектов были определены требования к программному продукту, а также разработана концепция программного продукта, функционал, формы отчетов, пошаговый алгоритм работы с программой, формы программного продукта.
При разработке ТЗ чаще всего принималось решение о том чтобы в системе был специальный конструктор (мастер) настройки модели. Тогда тот пользователь, кому будут присвоены соответствующие права Администратора, сможет сам настраивать модель. Если нужно что-то изменить в модели, он сам без привлечения программистов делает нужные изменения.
Поэтому в ТЗ описаны не только функционал программы по работе с методикой, но и функционал по настройке самой методики (модели). ЦБ достаточно часто вводит какие-то изменения и/или дополнения (например, может потребовать в обязательном порядке использовать какие-то показатели, а от каких-то показателей вообще отказаться).
Кроме того в самом банке, например, может возникнуть идея использовать для оценки финположения большее или меньшее количество факторов, чем используется сейчас. Или опять изменятся формы финансовой отчетности. Изменения могут быть разные, но все возможные типы изменений предусматривались в технических заданиях.
Таким образом, в техническом задании прописывалось каким образом должно быть сделано так, чтобы НЕ ПРОГРАММИСТ перенастраивал модель методики под новые требования.
Программа должна позволять настраивать модель, структура которой схематично представлена на рисунке 1.
Рис. 1. Модель методики определения категории качества ссуды и расчета резервов для коммерческого банка
Структура модели расчета финансового положения заемщика на основе баллов представлена на рисунке 2. На само деле это лишь пример структуры модели расчета финансового положения заемщика. Программа должна позволять настраивать и другие варианты модели.
Рис. 2. Пример структуры модели расчета финансового положения заемщика коммерческого банка
После разработки технического задания банки силами своих ИТ-служб выполняли непосредственную работу по автоматизации методики определения категории качества ссуды и расчета резервов на возможные потери по ссудам (РВПС).
Методика определения категории качества ссуды и расчета резервов (РВПС) для коммерческого банка (Россия)
В пресс-релизе содержится информацию о начале и завершении каждого этапа проекта.
Следует отметить, что сотрудничество Компании РиК с большинством банков начиналось после того как для их клиентов были разработаны бизнес-планы.
Многие из этих клиентов банка ранее принимали участие в наших открытых семинарах-практикумах по управленческому учету и семинарах-практикумах по бюджетированию.
Высокое качество работ по разработке бизнес-планов привлекало внимание банков и они обращались в Компанию РиК для решения своих задач, в частности для разработки методики определения категории качества ссуды и расчета резервов при финансировании корпоративных заемщиков коммерческого банка.
Начало проектов по разработке методики определения категории качества ссуды и расчета резервов для коммерческого банка
В рамках каждого такого проекта планировалось разработать методику определения финансового положения по каждому типу корпоративных заемщиков (актуальных для каждого конкретного банка), а также методику расчета качества обслуживания долга корпоративными заемщиками.
На основе этих оценок ссуды должны быть классифицированы в одну из пяти категорий качества в соответствии с Положением №254-П о порядке формирования кредитными организациями резервов на возможные потери по ссудам (РВПС), по ссудной и приравненной к ней задолженности.
В завершении проектов должны быть разработаны методики расчета резервов на возможные потери по ссудам (РВПС).
Обязательное условие для всех проектов - все разработанные методики должны быть настроены в электронных таблицах, чтобы ими было удобно пользоваться и чтобы кредитным менеджерам можно было сразу преступить к работе по новым методикам.
Завершение проекта по разработке методики определения категории качества ссуды и расчета резервов при финансировании корпоративных заемщиков коммерческого банка
В ходе проектов разрабатывались методики в текстовом формате и в формате электронных таблиц.
В рамках проектов были выполнены следующие работы:
Основные результаты по проектам:
- в текстовом формате;
- в формате электронных таблиц.
Методики определения категории качества ссуды и расчета резервов при финансировании корпоративных заемщиков (далее Методика) разрабатывались на основе Положения о порядке формирования кредитными организациями резервов на возможные потери по ссудам (РВПС), по ссудной и приравненной к ней задолженности № 254-П от 26.03.04 со всеми изменениями (далее 254-П).
Основная цель данной методики – обеспечение эффективного управления рисками при финансировании корпоративных заемщиков, а также минимизация РВПС.
Для всестороннего и качественного анализа рисков при выдаче и обслуживании ссуд методика дифференцировалась по различным типам корпоративных заемщиков. Т.е. при оценке рисков учитывалась специфика бизнеса заемщиков.
Чаще всего данная методика распространялась на следующие категории корпоративных заемщиков:
Для удобства использования данной методики создавалась ее электронная модель (в формате электронных таблиц). При вводе в электронную модель всей необходимой информации о заемщике и о ссуде оценка качества обслуживания долга, оценка финансового положения заемщика, классификация ссуды и расчет резерва производятся автоматически в соответствии с алгоритмами, описанными в методике.
Начало проектов по разработка ТЗ на автоматизацию методики определения категории качества ссуды и расчета резервов для коммерческого банка
Таким образом перед реализацией проектов по разработке ТЗ банки активно использовали модель методики, автоматизированной с помощью электронных таблиц. Это позволяло, во-первых, обкатать разработанную методику на практике, а, во-вторых, более четко поставить задачу по автоматизации.
В большинстве случае на разработку технического задания отводилось 2-3 месяца, а затем банки переходили к непосредственной автоматизации.
Специалисты Компании РиК имееют опыт в проектировании и разработке информационных систем. В частности сотрудниками Компании РиК был спроектирован и разработан программный комплекс "ИНТЕГРАЛ", позволяющий автоматизировать процесс бюджетирования и управленческого учета.
Этот опыт применялся и в данных проектах, т.к. по сути речь шла об автоматизации процесса оценки корпоративных заемщиков. Консультанты Компании РиК имеют очень большой опыт в управленческом консультировании в том числе и в проведении диагностики предприятий и оценки их финансового положения.
При этом конечно же в ходе таких проектов должны быть учтены все требования Центрального банка, которые необходимо выполнять при оценке финансового положения заемщика, качества обслуживания долга, категории качества ссуды и расчета резерва на возможные потери по ссуде (см. Положение №254-П, а также другие дополнительные разъяснения ЦБ).
При автоматизации методики можно придерживаться двух противоположных стратегий (естественно возможны какие-то промежуточные варианты).
Первый вариант
Сделать так чтобы в системе был специальный конструктор (мастер) настройки модели. Тогда тот, кому будут присвоены соответствующие права Админа, сможет сам настраивать модель. Если нужно что-то изменить в модели, он сам без привлечения программистов делает нужные изменения.
Второй вариант
ИТ-службе (или внешней компании) ставится задача в виде ТЗ, а они уже как им удобнее и быстрее настраивают нужную модель, программируя ее. При необходимости изменений в модель (даже самых несущественных) приходится вновь ставить задачу, а программистам переделывать программу.
В данных проектах чаще всего принимались решения о выборе первой стратегии автоматизации.
При реализации таких проектов если все хорошо продумать с самого начала (на этапе разработки ТЗ), то можно практически свести к нулю зависимость от программистов. И не важно, что это будут за программисты: из сторонней компании или из банка.
Если есть возможность создать софт, который в дальнейшем не потребует поддержки со стороны программистов, то нужно воспользоваться такой возможностью.
Кроме того практика показывает, что чем больше вносится изменений в программу тем выше вероятность возникновения ошибок причем не только в новых функциях, но и тех которые уже были ранее отлажены. Это связано с тем, что многие модули в программах взаимосвязаны. Т.е. когда меняется что-то в одном месте, эти изменения могут привести к изменению программы в других местах. Поэтому если дальнейшие переделки модели методики будут осуществляться программистами, то это увеличит вероятность возникновения ошибок.
Поэтому в рамках данных проектов как правило планировалось создать такой софт, чтобы все необходимые изменения в дальнейшем можно было бы делать без участия программистов.
Т.е. в ходе разработки ТЗ нужно было продумать не только функционал программы по работе с методикой, но и функционал по настройке самой методики (модели). Наверняка ЦБ будет вводить какие-то изменения (например, потребует в обязательном порядке использовать какие-то показатели, а от каких-то показателей вообще отказаться).
Кроме того в самом банке может возникнуть идея использовать для оценки финположения заемщика другое количество факторов, отличное от того, которое используется сейчас. Или опять изменятся формы финансовой отчетности как это произошло, например, в 2011 году.
Изменения могут быть разные. Но их все можно предусмотреть (т.к. для данной задачи типов изменений может быть не так много) и сделать так, чтобы НЕ ПРОГРАММИСТ смог сам перенастроить модель методики под новые требования. Программа должна позволять это делать.
Завершение проекта по разработке ТЗ на автоматизацию методики определения категории качества ссуды и расчета резервов для коммерческого банка
В ходе проектов были определены требования к программному продукту, а также разработана концепция программного продукта, функционал, формы отчетов, пошаговый алгоритм работы с программой, формы программного продукта.
При разработке ТЗ чаще всего принималось решение о том чтобы в системе был специальный конструктор (мастер) настройки модели. Тогда тот пользователь, кому будут присвоены соответствующие права Администратора, сможет сам настраивать модель. Если нужно что-то изменить в модели, он сам без привлечения программистов делает нужные изменения.
Поэтому в ТЗ описаны не только функционал программы по работе с методикой, но и функционал по настройке самой методики (модели). ЦБ достаточно часто вводит какие-то изменения и/или дополнения (например, может потребовать в обязательном порядке использовать какие-то показатели, а от каких-то показателей вообще отказаться).
Кроме того в самом банке, например, может возникнуть идея использовать для оценки финположения большее или меньшее количество факторов, чем используется сейчас. Или опять изменятся формы финансовой отчетности. Изменения могут быть разные, но все возможные типы изменений предусматривались в технических заданиях.
Таким образом, в техническом задании прописывалось каким образом должно быть сделано так, чтобы НЕ ПРОГРАММИСТ перенастраивал модель методики под новые требования.
Программа должна позволять настраивать модель, структура которой схематично представлена на рисунке 1.
После разработки технического задания банки силами своих ИТ-служб выполняли непосредственную работу по автоматизации методики определения категории качества ссуды и расчета резервов на возможные потери по ссудам (РВПС).
