Так, например, банковский работник по кредитам, получив задание разобраться с причиной снижения оборачиваемости движения по кредитному портфелю, составив данную таблицу, таким образом, чтобы в ней были представлены данные за тот период, по которому наблюдается снижение коэффициента, может выявить эти причины: то ли это снижение общего количества договоров, то ли снижение активности заемщиков то ли любая другая причина, для выявления которой также потребуются другие данные, которые будут рассмотрены ниже.
Следующие данные, которые необходимо ежедневно отслеживать в кредитном отделе - информация о завершении кредитных договоров в разрезе месяцев. Данная информация представляет собой систему, в которой данные в разрезе каждого кредитного договора сгруппированы по месяцам и годам, по срокам. Таким образом можно будет отслеживать сроки завершения кредитных договоров, тем самым, контролируя подходящие уже к закрытию кредитные договора, предупреждая заемщиков о предстоящей выплате, а также отслеживать просроченные договора. То есть проводить всю необходимую работу, направленную на своевременность поступлений денежных средств по кредитным договорам, а также пресекать и отслеживать возможные просрочки или же приближающиеся погашения.
Помимо этих возможностей управляющий персонал может выявить, месяц с наибольшим количеством погашения займов, а также какие суммы будут гаситься и, исходя из этого, рассчитать свою политику предоставления займов, рассмотреть варианты использования освобождающихся денежных средств и так далее. Но информация, которая представляется в каждой из вышеперечисленных таблиц, была бы не полной без сведений о регионе происхождения или регистрации заемщика. Подобные данные необходимы для отслеживания регионального и отраслевого рисков.
Выбирая заемщиков, представляющих интерес с точки зрения повышения их общего уровня риска, можно выделять сведения об общем состоянии отраслевого и регионального рисков. А, исходя из этих сведений, принимать оперативные решения об изменении отраслевой и региональной структуре кредитного портфеля. Таким образом, данная таблица дополняет все предыдущие таблицы необходимыми сведениями о заемщиках и позволяет более эффективно контролировать ситуацию с кредитным портфелем, а также прогнозировать и планировать изменения в его структуре с точки зрения региональной и отраслевой структур.
В конце этого параграфа второй главы следует отметить, что данные таблицы рассматривают лишь отдельную, но важную часть состояния кредитного портфеля банка. Именно совокупное исследование состояния кредитного портфеля банка даст управленческому персоналу полную и своевременную информацию о каждом заемщике и их различным группировкам, что позволит минимизировать общие риски и максимизировать доход. Помимо этого, эта система помогает реализовывать не только цели центра ответственности, но и способствует реализации целей и задач центра прибыли и центра инвестиций.
2.3 Риски внедрения системы управленческой отчетности в ОСБ «Сбербанк России»
Существуют некоторые этапы последовательности управленческого учета в коммерческом банке:
1. Создать систему трансфертного ценообразования.
2. Выделить центры ответственности и бизнес-центров.
3. Оценить работу филиалов и подразделений.
4. Оценить доходы в банках.
5. Оценить прибыль клиентов банка
6. Составить план и бюджет на основе данных о планируемых объемах привлечения и размещения.
Стоит заметить, что существуют некоторые проблемы при внедрении системы. Ниже представлены примеры проблем, при внедрении систем управленческого учета в банках (табл. 2.3).
Таблица 2.3 Характерные проблемы внедрения систем управления учета и отчетности
|
Проблема |
Результат |
|
|
Финансовое учреждение возлагает огромные надежды на автоматизацию управленческого учета, отчетности. Главную работу нужно возлагать на отдел автоматизации. |
IT специалисты не в силах выработать концептуальный подход к финансовой модели банка, так как они - не специалисты в сфере банковского дела. |
|
|
Менеджмент банка крайне полагается на данные системного учета, который не дает достоверной, полной информации об эффективности, прибыльности, о риске на каждом уровне оценки. |
Управленческую систему параметров работы невозможно путать с традиционной российской системой бухгалтерского учета. |
|
|
Менеджмент банка полагается исключительно на математические, экономические методы при оценке эффективности работы. |
Исключение качественных параметров превращает систему оценки в невыгодное положение в условиях стремительно меняющейся, многовариантной рыночной среды. Это актуально в условиях нестабильности нашей страны. |
Риски внедрения систем управленческого учета в отечественных коммерческих банках представлены в таблице 2.4.
Таблица 2.4 Риски внедрения систем управленческого учета
|
Риски |
Последствия |
Решения |
|
|
Некоторые функции распределены между разными подразделениями, или напротив - имеется чрезмерная централизация |
Нельзя назвать центры ответственности |
Предварительным шагом нужно считать пересмотр определенных аспектов организационной структуры, нужно провести финансовую структуризацию |
|
|
Не имеется отдельной функции казначейства как центра, который управляет финансовыми потоками в банке. |
Нельзя установит систему трансфертного формирования |
Предварительный шаг - создание функции казначейства. |
|
|
Большинство операций по балансу не проводятся |
Итоги управленческого учета не целиком отражают реальное финансовое положение банка. |
Нужно создать отдельную защищенную БД для ее дальнейшего применения в управленческом учете. |
|
|
Процедуры |
|||
|
Используется упрощенная методика расчета трансфертных цен |
Искажаются результаты управленческого учета, делаются неверные выводы и принимаются ошибочные решения. Управленческий учет оказывается непродуктивным |
Во-первых, необходимо придерживаться апробированной методики. Во-вторых, по всем принципиальным вопросам пересмотра методики должно быть принято решение высшего руководства |
|
|
Применяются неверные принципы разнесения расходов |
Результаты оценки деятельности центров ответственности неадекватны и искажены |
Следует провести работу по изучению существующих баз распределения |
|
|
Не создается система внутреннего инвойсирования |
Не представляется возможным распределить расходы обслуживающих подразделений между центрами ответственности |
Необходимо провести работу по созданию форм учета рабочего времени и оказываемых подразделениями друг другу услуг |
|
|
Автоматизация |
|||
|
Некоторых данных не хватает, или их достоверность вызывает сомнения |
Будет потеряно много времени на поиск и проверку данных |
Необходимо провести аудит данных |
|
|
Нет адекватной системы хранения данных |
Без хранилища данных управленческий учет будет очень трудоемким |
Следует оценить потребности в программном обеспечении и выбрать лучшее решение для банка |
3. Разработка и практическое применение системы формирования управленческого учета в коммерческом банке
3.1 Формирование логической модели системы управленческого учета
Перед созданием самой системы управленческого учета требуется совершить немало действий. В первую очередь, необходимо создать модель функционирования системы, сделать некоторые наброски по ее работе (Рисунок 3.1).
Рисунок 3.1. Логическая модель системы управленческого учета
Стоит отметить, что в данной модели у нас присутствуют пять таблиц-справочников и одна таблица фактов.
Таблица-справочник Client хранит в себе информацию о клиентах регионального филиала и имеет следующие поля:
1. Client_id - Идентификационный номер клиента. Является первичным ключом. Тип данных - int;
2. Name - Фамилия, имя, отчество клиента. Тип данных - varchar(50);
3. Type - Тип клиента. Ю - юридическое лицо, Ф - физическое лицо. Тип данных - char(1);
4. BirthDate - Дата рождения клиента. Тип данных - date;
5. PassportNum/MSRN - Номер паспорта (для физических лиц) или ОГРН (Основной Государственный Регистрационный Номер) (для юридических лиц). Тип данных - bigint;
6. PlaceOfWork - Место работы клиента. Тип данных - varchar(40);
7. JobTitle - Должность на работе. Тип данных - varchar(30);
8. Salary - Заработная плата. Тип данных - bigint;
9. Telephone - Телефонный номер клиента. Тип данных - bigint;
10. Email - Электронная почта клиента. Тип данных - varchar(30);
11. City - Город проживания клиента. Тип данных - varchar(30);
12. Address - Адрес проживания клиента. Тип данных - varchar(40).
Таблица-справочник Account хранит в себе информацию о банковских счетах клиентов и имеет следующие поля:
1. Account_id - Идентификационный номер счета. Является первичным ключом. Тип данных - int;
2. AccountNum - Номер счета. Тип данных - bigint;
3. Sum - Сумма на счете. Тип данных - money;
4. DateBegin - Дата открытия счета. Тип данных - date;
5. DateEnd - Дата закрытия счета. Тип данных - date;
6. Status - Статус счета (Открыт/Закрыт). Тип данных - varchar(10);
7. Client_id - Идентификационный номер клиента. Является вторичным ключом. Тип данных - int.
Таблица-справочник Departments хранит в себе информацию о банковских отделах и имеет следующие поля:
1. Department_id - Идентификационный номер отдела. Является первичным ключом. Тип данных - int;
2. Name - Название отдела. Тип данных - varchar(30).
Таблица-справочник Services хранит в себе информацию о банковских видах операций и имеет следующие поля:
1. Service_id - Идентификационный номер вида операций. Является первичным ключом. Тип данных - int;
2. Name - Название вида операции. Тип данных - varchar(40).
Таблица-справочник Staff хранит в себе информацию о сотрудниках регионального головного отделения и имеет следующие поля:
1. Staff_id - Идентификационный номер сотрудника. Является первичным ключом. Тип данных - int;
2. Name - Фамилия, имя, отчество сотрудника. Тип данных - varchar(40);
3. EmploymentDate - Дата зачисления на работу. Тип данных - date;
4. BirthDate - Дата рождения сотрудника. Тип данных - date;
5. Telephone - Номер телефона сотрудника. Тип данных - bigint;
6. Email - Электронная почта сотрудника. Тип данных - varchar(30);
7. City - Город проживания сотрудника. Тип данных - varchar(20);
8. Address - Адрес проживания сотрудника. Тип данных - varchar(30);
9. JobTitle - Должность в банке. Тип данных - varchar(25);
10. Login - Логин для входа в систему управленческого учета. Тип данных - varchar(25);
11. Password - Пароль для входа в систему управленческого учета. Тип данных - varchar(15);
12. Department_id - Идентификационный номер отдела, в котором находится сотрудник. Является вторичным ключом. Тип данных - int.
Таблица фактов Operations хранит в себе информацию об операциях, совершенных клиентами и имеет следующие поля:
1. Operation_id - Идентификационный номер операции. Является первичным ключом. Тип данных - int;
2. Sercice_id - Идентификационный номер вида операции. Является вторичным ключом. Тип данных - int;
3. SumGiven - Сумма денег, выданная в ходе операции. Тип данных - money;
4. SumGot - Сумма денег, полученная в ходе операции. Тип данных - money;
5. Procents - Процент кредитования/ипотечного займа/получения в ходе посреднических операций. Тип данных - float;
6. Term - Срок кредитования/выданной карты. Тип данных - int;
7. DateBegin - Дата операции/начала договора. Тип данных - date;
8. DateEnd - Дата окончания договора. Тип данных - date;
9. ContructNumber - Номер контракта. Тип данных - bigint;
10. Info - Дополнительная информация. Тип данных - varchar(150);
11. Staff_id - Идентификационный номер сотрудника. Является вторичным ключом. Тип данных - int;
12. Client_id - Идентификационный номер клиента. Является вторичным ключом. Тип данных - int;
13. Quantity - Количество проданных(ой)/купленных(ой) акций/иностранной валюты.
3.2 Обогащение базы данных
Далее следует заполнить таблицы данными. Для заполнения базы данных и дальнейшей работы с ней была выбрана программа SQL Management Studio 2014 (Рисунок 3.2, Рисунок 3.3, Рисунок 3.4, Рисунок 3.5, Рисунок 3.6, Рисунок 3.7)
Рисунок 3.2. Заполненная таблица Account
Рисунок 3.3. Заполненная таблица Client
Рисунок 3.4. Заполненная таблица Departments
Стоит заметить, что отделы были введены исходя из организационной структуры банка.
Рисунок 3.5. Заполненная таблица Services
Рисунок 3.6. Заполненная таблица Staff
Рисунок 3.7. Заполненная таблица Operations
3.3 Разработка ПО для системы управленческого учета
Однако, проведение какого-либо анализа будет невозможным, так как требуется не просто собрать и показать информацию пользователю, а представить ее в правильном виде. Для этого следует воспользоваться программой Visual Studio 2013, в которой будет разработан дизайн системы, а также ее функционирование с базой данных. ПО будет разработано на языке C Sharp, а графический дизайн в форме WPF с использованием языка XAML. управленческий отчетность кредитный денежный
В первую очередь, стоит рассмотреть принцип работы самой системы. Чтобы в систему не входил кто попало, то стоит внедрить способ входа в систему посредством вбивания логина и пароля, которые прописаны каждому нужному сотруднику в базе данных под графами «Login» и «Password» (Рисунок 3.8).
Рисунок 3.8. Входная форма в систему
Уже в первой же форме есть обращение к базе данных. Через программный код (Приложение 1). Если пользователь введет неправильный логин или пароль, то высветится окно с информацией об этом (Рисунок 3.9)
Рисунок 3.9. Окно с информацией об ошибочном вводе пароля или логина
Если же пароль и логин введены верно, то появляется главное окно, а окно входа закрывается (Рисунок 3.10).
Рисунок 3.10. Главное меню системы.
Справа в верхнем углу указывается имя пользователя, заданное в базе данных в таблице «Staff» под полем «Name», ниже указывается отдел (Departments.Name), и еще ниже - должность (Staff.JobTitle). Помимо информации о пользователе имеются 6 кнопок:
1. Банковские счета - информация из базы данных по банковским счетам клиентов
2. Операции - информация по всем операциям
3. Клиентская база - информация о клиентах
4. База данных сотрудников - информация о сотрудниках
5. Анализ клиентов - проведение анализа по отдельно взятому клиенту
6. Анализ сотрудников - проведение анализа по отдельно взятому сотруднику
В отличие от таблиц в базе данных, просмотренные через SQL Management Studio 2014, в Visual Studio 2013 есть возможность сразу через SQL запрос к базе данных показать информацию, например, о сотрудниках без внешнего ключа (Department_id) (Рисунок 3.6). Вместо него можно вставить название самого отдела (Рисунок 3.11).
Рисунок 3.11. Рассмотрение отличия просмотра таблиц в Visual Studio 2013 от SQL MS 2014
Также имеет место быть быстрое упорядочивание записей в таблице по алфавиту или возрастанию нажатием на название поля (Рисунок 3.12).