Моделирование предметной области «Управление дебиторской и кредиторской задолженностью» с помощью UML

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

Для существенного снижения риска возникновения долгов и появления возможности эффективного взыскания дебиторской задолженности есть необходимость в разработке или приобретении автоматизированной системы управления задолженностями.

ГЛАВА 1. Аналитическая часть

1.1 Анализ предметной области — основа проектирования базы данных

Предметная область — это часть реального мира, подлежащая изучению с целью создания базы данных для автоматизации процесса управления.

База данных — это интегрированная совокупность структурированных и взаимосвязанных данных, организованная по определенным правилам, которые предусматривают общие принципы описания, хранения и обработки данных.

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

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

Проектирование баз данных включает несколько этапов:

1. Проектирование инфологической концептуальной модели БД.
2. Проектирование даталогической модели БД.
3. Проектирование физической модели БД.
4. Реализация БД.

Каждый этап подразумевает последовательное проектирование базы данных и включает ряд особенностей.

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

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

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

Таким образом, даталогическая модель реализуется, как модель представления данных. Следовательно, перед тем как строить даталогическую модель, необходимо определить какая модель данных будет положена в основу базы данных и выбрать соответствующую систему управления базами данных (СУБД). Различают реляционные, иерархические и сетевые модели представления данных и соответствующие этим моделям СУБД.

Физическая модель данных — модель, определяющая размещение данных на внешних носителях, методы доступа и технику индексирования. Она так же называется внутренней моделью системы, которая определяет и оперирует размещением данных и их взаимосвязями на запоминающих устройствах.

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

Завершающим этапом является реализация базы данных, внесение в неё информации и использование её для автоматизации определённой предметной области.

Рисунок 1.1 – Этапы проектирования БД

Итак, инфологическое моделирование, то есть описание модели БД на естественном языке, является первым этапом проектирования и, следовательно, закладывает основу успешного функционирования БД.

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

Инфологической моделирование (т.е. моделирование предметной области) можно свести к таким основным процессам:

• исследование предметной области и выявление требований конечных пользователей и решаемых задач;
• сбор и анализ основных данных (объекты, связи между объектами);
• построение ER-диаграммы базы данных [6].

Моделирование предметной области можно назвать главным этапом разработки БД, так как модель — это основа разработки БД.

1.2 Предлагаемые мероприятия по улучшению технологии решения задачи

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

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

Исполнитель (Действующее лицо, Actor) – личность, организация или система, взаимодействующая с ИС; различают внешнего исполнителя (который использует или используется системой, т.е. порождает прецеденты деятельности) и внутреннего исполнителя (который обеспечивает реализацию прецедентов деятельности внутри системы). На диаграмме исполнитель представляется стилизованной фигуркой человека.

Прецедент – законченная последовательность действий, инициированная внешним объектом (личностью или системой), которая взаимодействует с ИС и получает в результате некоторое сообщение от ИС. На диаграмме представляется овалом с надписью, отражающей содержание действия.

Класс — описание совокупности однородных объектов с их атрибутами, операциями, отношениями и семантикой. На диаграмме представляется прямоугольником, содержащим описания атрибутов и операций класса.

Ассоциация – связь между двумя элементами модели. На диаграмме представляется линией.

Обобщение – связь между двумя элементами модели, когда один элемент (подкласс) является частным случаем другого элемента (суперкласса). На диаграмме представляется стрелкой.

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

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

Проблемы управления дебиторской задолженностью, с которыми сталкиваются предприятия, достаточно типичны:

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

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

Построение системы учета и контроля дебиторской задолженности

Для управления дебиторской задолженностью нужна следующая информация:

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

Таблица 1. Критический срок оплаты по выставленным счетам для ООО “Покупатель”.

№ с/ф	Дата	Сумма, тыс. руб.	Дата отгрузки	Стоимость, тыс. руб.	Условия оплаты	Время в пути, дн.	Отсрочка по договору, дн.	Критический срок оплаты
103	25.12.04	100	27.12.04	100	От даты получения	12	5	13.01.05
109	27.12.04	600	29.12.04	200	От даты отгрузки	–	10	08.01.05
			29.12.04	200		–	15	13.01.05
			29.12.04	150		–	20	18.01.05
			29.12.04	50		–	25	23.01.05
141	03.01.05	650	08.01.05	650	От даты получения	2	10	20.01.05
			09.01.05	150		12	10	31.01.05

Определение критического срока оплаты

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

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

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

1.3 Порядок соотнесения поступивших платежей с выставленными счетами

Усложняют управление дебиторской задолженностью случаи, когда несколько выставленных счетов погашаются одним платежным поручением или, наоборот, когда один счет погашается несколькими платежными поручениями. В этом случае не всегда ясно, за что расплатился дебитор и какой из счетов просрочен. Если в назначении платежа дебитором не указано иное, мы рекомендуем использовать метод ФИФО, то есть считать, что покупатели сначала погашают наиболее ранний из выставленных и неоплаченных счетов.

Основным инструментом контроля дебиторской задолженности служит реестр старения дебиторской задолженности. Реестр старения представляет собой таблицу, содержащую неоплаченные суммы счетов, которые группируются по периодам просрочки платежа. Группировка осуществляется исходя из политики компании в области кредитования контрагентов. К примеру, менеджмент компании может считать, что просрочка платежа в течение семи дней допустима, при превышении этого срока следует активно работать с контрагентом по возврату дебиторской задолженности, а в случае просрочки более 30 дней обращаться в суд. Соответственно аналогично будут построены группы в реестре старения дебиторской задолженности: 0-7 дней, 8-15, 16-30, свыше 30.

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

Планирование поступления средств от дебиторов

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

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

Рисунок 1.2 – Схема управления кредиторской задолженностью.

Разработка кредитной политики.

Процесс управления дебиторской задолженностью невозможен без кредитной политики – свода правил, регламентирующих предоставление коммерческого кредита и порядок взыскания дебиторской задолженности. Кредитная политика принимается на год, по истечении которого уточняются цели и задачи, принятые стандарты, подходы и условия. По словам Антона Ходарева, в компании “Русский уголь” кредитная политика пересматривается раз в квартал. Приведем типичную структуру этого документа:

1. Цели кредитной политики.
2. Тип кредитной политики.
3. Стандарты оценки покупателей.
4. Подразделения, задействованные в управлении дебиторской задолженностью.
5. Действия персонала.

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

Цели проводимой кредитной политики

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

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

Тип кредитной политики

Принято выделять три типа кредитной политики:

• консервативная;
• умеренная;
• агрессивная.

Стандарты оценки покупателей

Покупатели, как правило, имеют различные возможности по объемам закупок, своевременности оплаты и претендуют на различные условия предоставления отсрочки платежа.

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

Создание алгоритма дифференциации условий предоставления отсрочки платежа предполагает выполнение ряда шагов.

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

– цены реализации;

– времени отсрочки платежа;

– максимального размера коммерческого кредита;

– системы скидок и штрафов.

Таблица 2. Значения кредитных рейтингов

Платежная дисциплина		Объем поставок
Просрочка оплаты, дн.	Рейтинг	Сумма реализации за год, руб.	Рейтинг
Больше 60	Е	Больше 1 млн	Е
Меньше 60	D	Больше 7 млн	D
Меньше 30	С	Больше 10 млн	С
Меньше 7	В	Больше 50 млн	В
0	А	Больше 100 млн	А

В качестве двух наиболее важных характеристик кредитоспособности покупателя руководство ООО “Посредник” выделяет платежную дисциплину и объем продаж (в денежном выражении) в предшествующие периоды (см. табл. 5).

Сначала клиенты ранжируются по платежной дисциплине. Получившие рейтинг “D” или “E” к ранжированию по объему продаж не допускаются. Для компаний, получивших рейтинги “А”, “В” и “С”, рекомендованы следующие условия работы:
– рейтинг “С”: работа с такой компанией только при условии наличия залога;
– рейтинг “B”: обязательное описание в договорах системы штрафов и пеней и их строгое исполнение;
– рейтинг “А”: предоставление отсрочки платежа без использования санкций со стороны компании.

На основании рейтинга объема поставок определяется максимально допустимый объем товарного кредита и цены на реализуемую продукцию. К примеру, для компании с рейтингом объема поставок “В” размер товарного кредита не должен превышать 50 млн руб. в год, а цена реализации устанавливается на 5% ниже базовой, для рейтинга “А” кредитный лимит не больше 100 млн руб. в год, а цена -на 10% ниже базовой.
Подобное ранжирование удобно в повседневной деятельности для принятия оперативных решений.

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

2. Уровни ответственности

Разделы 4-6 кредитной политики призваны разграничить уровни управления дебиторской задолженностью. Необходимо строго распределить ответственность за управление дебиторской задолженностью между коммерческой, финансовой и юридической службами. Нередко за продажи и взыскание задолженности отвечают разные подразделения, имеющие противоречивые задачи. К примеру, менеджер по продажам (коммерческий отдел) мотивирован продать как можно больше, а менеджер по работе с дебиторами (финансовая служба) – получить денежные средства и минимизировать уровень задолженности. Это приводит к недовольству со стороны клиентов и конфликту подразделений.

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

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

Автоматизация управления дебиторской задолженностью

По нашему мнению, для среднего по размерам предприятия приемлемо создавать программу учета и контроля дебиторской задолженности в Access. В компании, условно названной ООО “Посредник”, система управления дебиторской задолженностью была создана в Access. Этого оказалось вполне достаточно, чтобы контролировать дебиторскую задолженность по 600 клиентам, при этом ежедневно выставлялось порядка 20-30 счетов. Очевидно, что, для того чтобы система работала, необходимо постоянно обновлять данные о платежах, произведенных отгрузках и т. д.

ГЛАВА 2. Проектная часть

2.1. Выбор средства для моделирования предметной области решаемой задачи.

Существует множество средств моделирования автоматизированных систем. За последние десятилетия сформировалось новое направление в программотехнике - CASE (Computer-Aided Software/System Engineering) на основе методологии структурного системного анализа и проектирования. CASE-технология представляет собой совокупность методологий анализа, проектирования, разработки программного обеспечения (ПО) и сопровождения информационных систем, поддержанную комплексом, взаимосвязанных средств автоматизации [4]. CASE – это инструментарий для системных аналитиков, разработчиков и программистов, позволяющий автоматизировать процесс проектирования и разработки ПО.

Итак, основным критерием при выборе CASE-средств является поддержка выбранных методологий. Помимо этого необходимо учитывать доступность и простоту работы с данными средствами.

Для построения моделей в методологии IDEF0 и IDEF1x использовании CASE-средства BPwin\ERwin от компании Computer Associates. [5] Данные средства по своим функциональным возможностям полностью соответствуют поставленным критериям и при этом обладают удобным интерфейсом.

Остановимся подробно на выборе CASE-средства, для построения моделей по методологиям UML 2.0 и IDEF0. На российском рынке представлен большой набор программных продуктов, поддерживающих эти методологии, наиболее известными из которых являются следующие средства:

1. Microsoft Visio 2007.
2. AllFusion Modeling Suite;
3. Aris Toolset.

1. Microsoft Visio 2007. Это наиболее простое и доступное средство моделирования. Данный продукт имеет стандартные, привычные всем панели управлении в стиле MS Office и легко интегрируется с любыми приложениями этого пакета, что упрощает работу с ним для неопытных пользователей.

CASE-средство Microsoft Visio 2007 поставляется в комплекте с базовым пакетом Microsoft Office и не требует дополнительных затрат на приобретение. Помимо этого данный продукт поддерживает все виды диаграмм языка UML.

2. AllFusion Modeling Suite – пакет инструментальных средств разработанный компанией Computer Associates International, Inc. (CA), пакет поддерживает все этапы разработки информационных систем, в этот пакет входит пять продуктов:

AllFusion Process Modeler – «BPwin» (позволяет облегчить проведение обследования предприятия и построить функциональные модели).

AllFusion ERwin Data Modeler – «ERwin» (позволяет создавать модели данных и генерировать схему баз данных).

AllFusion Data Model Variator - «ERwin Examiner» (позволяет производить поис и исправление ошибок модели данных).

AllFusion Model Manager – «ModelMart» (система организации коллективной работы и хранилище моделей BPwin и ERwin).

AllFusion Component Modeler – «Paradigm Plus» (инструмент создания обьектных моделей).

Рассмотрим продукты которые нам понадобятся в проектировании:

AllFusion Process Modeler – «BPwin»: основан на методологии IDEF и предназначен для функционального моделирования и анализа деятельности предприятия. Методология IDEF, являющаяся официальным федеральным стандартом США, представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель IDEF отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями.

Возможности BPwin: поддерживает сразу три стандартные нотации - IDEF0 (функциональное моделирование), DFD (моделирование потоков данных) и IDEF3 (моделирование потоков работ).

Эти три основных ракурса позволяют:

• Описывать предметную область наиболее комплексно.
• Позволяет оптимизировать процедуры в компании.
• Полностью поддерживает методы расчета себестоимости по объему хозяйственной деятельности (функционально-стоимостной анализ, ABC).
• Позволяет облегчить сертификацию на соответствие стандартам качества ISO9000; интегрирован с ERwin (для моделирования БД), Paradigm Plus (для моделирования компонентов ПО) и др.; содержит собственный генератор отчетов; позволяет эффективно манипулировать моделями - сливать и расщеплять их; имеет широкий набор средств документирования моделей, проектов.

AllFusion ERwin Data Modeler – «ERwin»: это средство концептуального моделирования БД. Используется при моделировании и создании баз данных произвольной сложности на основе диаграмм "сущность - связь". В настоящее время ERWin является наиболее популярным пакетом моделирования данных благодаря поддержке широкого спектра СУБД самых различных классов.

Возможности ERWin:

Поддерживает методологию структурного моделирования SADT и следующие нотации: стандартную нотацию IDEF1x для ER-диаграмм моделей данных, нотацию IE и специальную нотацию, предназначенную для проектирования хранилищ данных - Dimensional.

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

Интегрирован линейкой продуктов Computer Associates для поддержки всех стадий разработки ИС, CASE-средствами Oracle Designer, Rational Rose, средствами разработки и др.

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

Возможна совместная работа группы проектировщиков с одними и теми же моделями (с помощью AllFusion Model Manager).

Позволяет переносить структуру БД (не сами данные!) из СУБД одного типа СУБД в другой.

Позволяет документировать структуру БД.

BPwin и ERwin компании Соmputer Associates. Computer Associates International, Inc. (CA) входит в пятерку ведущих производителей программного обеспечения, предлагая средства моделирования, резервного копирования, управления инфраструктурой предприятия (сетями, серверами и т.д.), информационной безопасности, business intelligence и т.д. [6].

3. ARIS: компании IDS Scheer AG. Система ARIS представляет собой комплекс средств анализа и моделирования деятельности предприятия. Ее методическую основу составляет совокупность различных методов моделирования, отражающих разные взгляды на исследуемую систему. Одна и та же модель может разрабатываться с использованием нескольких методов, что позволяет использовать ARIS специалистам с различными теоретическими знаниями и настраивать его на работу с системами, имеющими свою специфику. ARIS поддерживает четыре типа моделей, отражающих различные аспекты исследуемой системы:

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

Функциональные модели, содержащие иерархию целей, стоящих перед аппаратом управления, с совокупностью деревьев функций, необходимых для достижения поставленных целей.

Информационные модели, отражающие структуру информации, необходимой для реализации всей совокупности функций системы.

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

Для построения перечисленных типов моделей используются как собственные методы моделирования ARIS, так и различные известные методы и языки моделирования, в частности, ER и UML. Модели в ARIS представляют собой диаграммы, элементами которых являются разнообразные объекты - "функция", "событие", "структурное подразделение", "документ" и т.п. Между объектами устанавливаются разнообразные связи. Каждому объекту соответствует определенный набор атрибутов, которые позволяют ввести дополнительную информацию о конкретном объекте. Значения атрибутов могут использоваться при имитационном моделировании или для проведения стоимостного анализа

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

Выделим критерии наиболее важные конкретно для данного процесса моделирования:

• Наличие большинства поддерживаемых стандартов;
• Наличие средств графического отображения модели;
• Удобство работы по созданию моделей;
• Интеграция с CASE-средствами;
• Возможность декомпозиции объекта;
• Простота освоения продукта.

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

Таблица 3 - Сравнительный анализ по базовым функциям

Функциональные возможности, среда	ARIS	AllFusion	VISIO
Поддерживаемый стандарт	eEPS (расширение IDEF3), ERD, UML	IDEF0, IDEF3, DFD, IDEF1х.	UML IDEF*, DFD
Наличие средств графического отображения модели	Высокая	Средняя	Низкая
Удобство работы по созданию моделей	Сложно	Просто	Просто
Интеграция с Case-средствами	Да	Да	Частично
Возможность декомпозиции объекта	Да	Да	Да
Простота освоения продукта	Сложно	Просто	Просто

Исходя из поставленных задач, предстоящих условий моделирования и произведенных сравнительных характеристик делаем вывод, что по доступности, простоте использования и распространению поддерживаемых стандартов наиболее подходящим программным средством для моделирования UML-диаграмм с использованием объектно-ориентированного подхода к проектированию является Microsoft Visio.

2.2 Моделирование предметной области решаемой задачи с использованием объектно-ориентированного подхода к проектированию

Диаграмма вариантов использования.

На рис. 2.1 представлена диаграмма вариантов использования для управления дебиторской задолженностью.

Рисунок 2.1 – Диаграмма вариантов использования «Управление дебиторской задолженностью»

В качестве актеров на диаграмме (рисунок 2.1) используются объекты:

• «Финансовая служба», которая управляет вариантами использования:

«Контроль за образованием и состоянием задолженности»

«Определение политики кредитования»

«Ранжирование клиентов»

«Контроль за просроченной задолженностью»

«Прогноз погашения задолженности»

• «Коммерческая служба», управляющая вариантом использования

«Прогноз погашения задолженности»

• «Правовая служба» и «Служба безопасности, которые управляют вариантом использования:

«Определение приемов ускорения востребования долгов»

Между вариантами использования и действующими лицами используется связь ассоциации (association relationship).

Вариант использования «Контроль за образованием и состоянием задолженности» включает в себя следующие варианты использования:

«Классификация по срокам»

«Коэффициент оборачиваемости»

«Доля сомнительных долгов»

Вариант использования «Определение политики кредитования» включает в себя варианты использования:

«Сроки погашения»

«Порядок погашения»

«Стандарты кредитоспособности»

«Условия предоставления кредита»

Вариант использования «Определение приемов ускорения востребования долгов» включает в себя:

«Политика инкассации»

«Заключение договоров»

«Факторинг»

Между разными вариантами использования для определения отношения включения используется связь включения (include).

Вариант использования «Кредитная история клиентов» расширяет «Ранжирование клиентов»

Вариант использования «Реестр старения дебиторской задолженности» расширяет вариант использования «Контроль за просроченной задолженностью».

Для определения отношения расширения используется связь расширения (extend).

Диаграмма последовательности.

На рис. 2.2 представлена диаграмма последовательности работы в системе управления задолженностями.

Рисунок 2.2 – Диаграмма последовательности «Управление дебиторскими задолженностями»

На данную диаграмму помещены следующие объекты:

• «Пользователь» – это сотрудник компании, занимающийся управлением задолженностями;
• «Форма Каталог Контрагентов» – Содержит список существующих контрагентов и средства создания новых записей;
• «Форма учета денежных операция» – позволяет формировать начисления, списания и актуализации задолженностей по долговым обязательствам;
• «Форма расписания событий» – календарный список запланированных, выполненных и просроченных мероприятий;
• «Форма печати» – позволяет создавать шаблоны документов.

Сообщения между объектами на диаграмме:

• «Ввод данных объекта взыскания» – пользователь вводит данные о новом Контрагенте;
• «Расчет долговых обязательств» – на основе введенных данных программа производит расчет срока и порядка погашения задолженности;
• «Запись в БД» – данные о контрагенте и долговых обязательствах сохраняются в БД;
• «Актуализация задолженности» - запрос пользователя на формирование и отображение актуальной информации о платежах и состоянии задолженности;
• «Чтение данных о платежах» - выборка данных о платежах из БД;
• «Запланировать мероприятие» - создание записи в календаре о мероприятии;
• «Запись в БД» - сохранение данных о мероприятии в БД;
• «Чтение данных о мероприятиях» - выборка данных о мероприятиях из БД;
• «Уведомления о ближайших событиях» - автоматический вывод напоминаний о ближайших мероприятиях;
• «Выбор Контрагента» - открытие записи нужного контрагента;
• «Формирования претензионного письма» - автоматическое создание документа по шаблону.
• «Печать претензионного письма» - вывод на печать или сохранение документа на диск.

Диаграмма состояний.

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

Рисунок 2.3 – Диаграмма состояний системы управления задолженностями.

На диаграмме состояний расположены следующие состояния:

• начальное состояние;
• конечное состояние;
• «Ожидание выбора пользователя»;
• «Открытие формы контрагента»;
• «Обработка запроса создания записи» (создание записи Контрагента);
• «Сохранение данных в БД»;
• «Вывод данных контрагента»;
• «Обработка запроса на формирование письма»;
• «Вывод данных о платежах»
• «Ожидание выбора»

Для каждого из состояний созданы следующие действия:

• «Вход в систему» после начального состояния производится запуск системы;
• «Создание записи контрагента»;
• «Ввод данных» на форме создания контрагента ввод данных о контрагенте;
• «Расчет долговых обязательств» на основе введенных данных о контрагенте производится расчет срока и порядка погашения задолженности;
• «Вывод данных» (форма контрагента) формируется запись о контрагенте и его задолженности;
• «Выбор контрагента» поиск контрагента в каталоге
• «Формирование претензионного письма» автоматическое создание документа по шаблону для выбранного контрагента;
• «Печать письма» - вывод сформированного документа на печать;
• «Актуализация задолженности» - инициация расчета текущего состояния задолженности;
• «Данные сформированы» формирование данных о платежах и состоянии задолженности;
• «Оплата просрочена» вывод информации о просроченной задолженности
• «Счет оплачен» вывод информации и поступлении денежных средств;
• «Создание мероприятия» - ввод данных о мероприятии
• «Мероприятие создано» - вывод информации о созданном мероприятии в календаре.

Диаграмма деятельности.

На рис. 2.4 представлена диаграмма деятельности этапов управления дебиторской задолженностью.

Рисунок 2.4 – Диаграмма деятельности системы управления задолженностями.

На диаграмме расположены следующие дорожки:

• «Менеджер по продажам»;
• «Коммерческий директор»;
• «Финансовая служба»;
• «Юридический отдел»;

Для каждой дорожки определены следующие действия:

• «Заключение договора» - поставщик заключает договор с потребителем;
• «Контроль отгрузки» - производится контроль отгрузки товара;
• «Выставление счета» - выставляется счет потребителю согласно договору;
• «Уведомление об отгрузке товара» - уведомление потребителя об отгрузке товара;
• «Уведомление о сумме расчетных сроках погашения дебиторской задолженности»
• «За 2-3 дня до наступления критического срока оплаты звонок с напоминанием об окончании периода отсрочки»
• «Звонок с выяснением причин, формирование графика платежей» - звонок потребителю с выяснением причин неоплаты счета, формирование индивидуального графика платежей;
• «Прекращение поставок» - прекращение поставок до оплаты счета;
• «Направление предупредительного письма о начислении штрафа»
• «Начисление штрафа» - при просрочке от 7 до 30 дней начисляется штраф
• «Предарбитражное предупреждение» - предупреждение для потребителя;
• «Ежедневные звонки с напоминанием» - звонки потребителю с напоминанием об оплате счета;
• «Принятие мер по досудебному урегулированию» - при просрочке от 30 до 60 дней.
• «Официальная претензия (заказным письмом)»
• «Подача иска в арбитражный суд» - при просрочке более 60 дней подается иск в суд.

Диаграмма классов.

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

Рисунок 2.5 – Диаграмма классов системы управления задолженностями

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

Указанная множественность показывает, сколько экземпляров одного класса взаимодействует с помощью этой связи с одним экземпляром другого класса в данный момент времени. Так же были добавлены атрибуты и методы в классы.

ЗАКЛЮЧЕНИЕ

В процессе выполнения данного курсового проекта была разработана объектно-ориентированная модель информационной системы управления дебиторскими и кредиторскими задолженностями с использованием языка UML.

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

Для реализации проектной части был проведен анализ средств для моделирования автоматизированных системы.

В ходе разработки предметной части курсовой работы были изучены основы языка моделирования UML и построены следующие диаграммы:

• Диаграмма вариантов использования;
• Диаграмма последовательности;
• Диаграмма состояний;
• Диаграмма деятельности;
• Диаграмма классов.

В качестве средства моделирования предметной области был выбран программный продукт Microsoft Visio.

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1..Булдакова И.С., Суворова В.Л. Управление дебиторской и кредиторской задолженностью на предприятии // Научно-методический электронный журнал «Концепт». — 2015. — Т. 30.

2. Смирнова О.А. Система управления дебиторской и кредиторской задолженности: формирование в современных условиях // Научный диалог: экономика и управление — Чебоксары: ЦНС «Интерактив плюс». URL: https:/interactive-plus.ru/ru/article/463778/discussion_platform (дата обращения: 26.11.2018).

3. Трухина Т.Г., Гурлева Е.А., Волченко А.М., Ильина А.В. Управление дебиторской и кредиторской задолженностью хозяйствующего субъекта // Молодой ученый. — 2017. — № 5.

4. Антонова О.В. Методические подходы к анализу дебиторской и кредиторской задолженности как фактор эффективного управлению ею. URL: http://www.rusnauka.com/pdf/235372.pdf (дата обращения: 26.11.2018).

5. Шишова Л.И., Вагапова Х.Ю. Управление дебиторской и кредиторской задолженностью на предприятии. URL: http://edrj.ru/article/11-04-2018 (дата обращения: 26.11.2018).

6. Финансы организаций // Росстат. URL: http://www.gks.ru/free_doc/new_site/finans/graf_zadol.htm (дата обращения: 26.11.2018).

7. Щербак А. В. Управление дебиторской и кредиторской задолженностью как основа обеспечения финансовой устойчивости предприятия // Молодой ученый. — 2019. — №2. — С. 298-300. — URL https://moluch.ru/archive/240/55636/ (дата обращения: 19.08.2019).

8. Проектирование информационных систем : учебник и практикум для среднего профессионального образования / Д. В. Чистов, П. П. Мельников, А. В. Золотарюк, Н. Б. Ничепорук ; под общей редакцией Д. В. Чистова. — Москва : Издательство Юрайт, 2018. — 258 с. — (Профессиональное образование).