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

Содержание:

ВВЕДЕНИЕ

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

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

Однако, ведение бумажного документооборота имеет свои недостатки:

• Большой объем документов;
• Высокие временные затраты на формирование и поиск документов;
• Возможность повреждения или утери документа;
• Необходимость наличия больших архивных помещений.

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

• Представление данных в удобной для пользователей форме.
• Изменение структуры базы данных не требует внесения значительных изменений в программный код.
• Обеспечение информационной безопасности данных [2].

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

Объектом исследования является процесс учета расчетов с поставщиками или подрядчиками.

Предметом исследования является автоматизация учета расчетов с поставщиками и подрядчиками.

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

Для достижения поставленной цели необходимо решить ряд задач:

1. Дать описание предметной области.
2. Осуществить выбор СУБД.
3. Спроектировать логическую структуру базы данных.
4. Спроектировать физическую структуру базы данных.
5. Создать контрольный пример решения задачи.
6. Разработать интерфейс и реализацию проекта.

Аналитическая часть

1. Описание предметной области. Постановка задачи

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

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

• отгрузки ТМЦ;
• выполнения работ;
• оказания услуг.

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

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

Основной документ, по которому осуществляется учет расчетов с поставщиками и подрядчиками, - это счет-фактура установленной формы, которую выписывает поставщик или подрядчик. В счете-фактуре заполняются следующие реквизиты:

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

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

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

Образец счета-фактуры представлен на рисунке 1.

Первым документом, с которого начинается сотрудничество между организациями, является договор купли-продажи. Договор с каждым поставщиком или подрядчиком должен содержать следующую информацию:

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

К счету-фактуре прикладывается накладная. Накладная - это документ, который сопровождает поступление товарно-материальных ценностей на предприятие.

Рисунок 1. Образец счета-фактуры

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

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

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

1. Выбор СУБД

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

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

1. Реляционные базы данных.
2. Иерархические базы данных.
3. Сетевые базы данных.

В процессе развития теории баз данных были выделены следующие модели данных:

1. Реляционная модель данных.
2. Иерархическая модель данных.
3. Сетевая модель данных.

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

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

Рассмотрим классификацию СУБД.

1. Степень универсальности:

• СУБД общего назначения;
• СУБД универсального назначения.

1. Тип модели данных:

• иерархические;
• сетевые;
• реляционные;
• объектно-ориентированные;
• многомерные.

1. Способ доступа к базе данных:

• файл-серверные;
• клиент-серверные;
• встраиваемые [9].

Выбор системы управления баз данных (СУБД) представляет собой сложную многопараметрическую задачу и является одним из важных этапов при разработке приложений баз данных. Выбранный программный продукт должен удовлетворять как текущим, так и будущим потребностям предприятия, при этом следует учитывать финансовые затраты на приобретение необходимого оборудования, самой системы, разработку необходимого программного обеспечения на ее основе, а также обучение персонала. Кроме того, необходимо убедиться, что новая СУБД способна принести предприятию реальные выгоды [1].

Наиболее простой подход при выборе СУБД основан на оценке того, в какой мере существующие системы удовлетворяют основным требованиям создаваемого проекта информационной системы. Более сложным и дорогостоящим вариантом является создание испытательного проекта на основе нескольких СУБД и последующий выбор наиболее подходящего из кандидатов [5]. Но и в этом случае необходимо ограничивать круг возможных систем, опираясь на некие критерии отбора. Поскольку для реализации проекта была выбрана реляционная база данных, для ее создания необходима реляционная СУБД. Реляционные СУБД обладают следующими преимуществами:

1. Наглядное и простое отображение данных.
2. Позволяет лаконично описывать основные операции над данными.
3. Позволяет создавать языки манипулирования данными непроцедурного типа [3].

Рассмотрим критерии, которые влияют на выбор СУБД:

1. Надежность. Характеризуется низким уровнем ошибок, сохранность информации независящая от любых сбоев, и безотказность работы системы в любых условиях, и обеспечение защиты данных от несанкционированного доступа.
2. Оперативность – высокая скорость обработки запросов.
3. Компактность – требования к дисковому пространству и количеству процессоров.
4. Наличие качественной и полной пользовательской документации.
5. Масштабируемость.
6. Стоимость [6].

Выбранная СУБД должна отвечать следующим критериям:

1. Поддержка реляционной модели данных.
2. Обладание масштабируемостью и мобильностью.
3. Содержать средства контроля использования памяти компьютера.
4. Быть производительной и надежной.

Рассмотрим решения, представленные на рынке и проанализируем их согласно выявленным критериям. Лидерами на рынке СУБД являются продукты IBM DB2, Oracle, Microsoft SQL Server и MS Access.

СУБД IBM DB2 является кросс-платформенной, обеспечивает стабильную работу базы данных. Недостатками системы являются высокая стоимость и низкая производительность.

СУБД Microsoft SQL Server обладает большим пакетом инструментов, стабильностью работы и низкими затратами на администрирование. Недостаток системы заключается в том, что она работает только на платформе Windows.

СУБД Oracle обладает высокой производительностью, легкостью интегрирования приложений и устойчивостью к большим потокам данных. Недостатком является высокая стоимость, необходимость приобретения мощного оборудования и персонала для поддержки СУБД [8].

СУБД MS Access является реляционной СУБД, разработанной с учетом того, что пользователями этой СУБД будут люди, не обладающие специальными знаниями в области разработки базы данных. СУБД содержит инструменты для создания таблиц базы данных и разработки пользовательского интерфейса (формы, кнопки, поля для ввода данных) [10]. Также с помощью инструментов этой СУБД можно создавать отчетные формы. База данных, разработанная в СУБД MS Access, обладает совместимостью с СУБД MS SQL Server и может быть интегрирована в эту СУБД. Сравнительный анализ СУБД представлен в таблице 1.

Таблица 1

Сравнительный анализ СУБД

СУБД	IBM DB 2	MS SQL Server	Oracle	MS Access
Критерий
Надежность	5	5	5
Оперативность	2	4	5
Компактность	3	2	4
Документация	4	5	3
Масштабируемость	4	3	3
Стоимость	2	5	2
Итого	20	24	22

Согласно выделенным критериям для проектирования ИС учета кассовых операций наиболее подходящей является СУБД MS SQL Server.

После того как выбрана СУБД, необходимо осуществить выбор программного средства для проектирования базы данных. Существуют несколько программных продуктов, автоматизирующих проектирование баз данных:

• Erwin Data Modeler.
• MS Visio.

CASE-средство Erwin Data Modeler представляет собой инструмент для проектирования реляционных баз данных [7]. В этом программном обеспечении можно создать логические и физические модели базы данных, на основании которых будет сгенерирована база данных в выбранной СУБД.

MS Visio представляет собой редактор для создания различных моделей, в число которых входит модель IDEF1X, позволяющая осуществить проектирование баз данных [4]. Поскольку этот программный продукт не является специализированным средством для проектирования баз данных, он обладает ограниченным функционалом и не позволяет сгенерировать базу данных в выбранной СУБД.

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

1. Проектирование логической структуры базы данных

Выделим основные сущности предметной области:

1. Организация – сущность, которая содержит информацию об организации, поставщиках и подрядчиках.
2. Товар – сущность, которая содержит информацию о товарах, полученных от поставщиков и подрядчиков.
3. Услуга – сущность, которая содержит информацию об услугах, предоставленных подрядчиками.
4. Договор – сущность, которая содержит информацию о договоре купли-продажи, выполнения работ или оказания услуг.
5. Счет-фактура – сущность, которая содержит информацию о документе, подтверждающем поставку товара.
6. Накладная – сущность, которая содержит информацию о документе, подтверждающем поставку товара.
7. Акт приемки – сущность, которая содержит информацию о документе, в котором указаны расхождения в предоставленных услугах или полученных товарах.

Каждая из представленных сущностей обладает рядом атрибутов. Сущность Организация содержит следующие атрибуты:

• Название;
• ИНН;
• Адрес.

Сущность Товар содержит следующие атрибуты:

• Название;
• Цена.

Сущность Услуга содержит следующие атрибуты:

• Название;
• Цена.

Сущность Договор содержит следующие атрибуты:

• Номер;
• Дата;
• Сумма;
• Срок действия.

Сущность Счет-фактура содержит следующие атрибуты:

• Номер;
• Дата;
• Наименование организации;
• Наименование товара;
• Количество товара;
• Сумма.

Сущность Накладная содержит следующие атрибуты:

• Номер;
• Дата;
• Наименование организации;
• Наименование услуги;
• Количество услуг.

Сущность Акт приема содержит следующие атрибуты:

• Номер;
• Дата;
• Наименование организации;
• Наименование товара;
• Количество товара;
• Расхождение.

Определим отношения между выделенными сущностями:

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

Отношение «Указана» между сущностями Счет-фактура и Организация показывает какая организация была поставщиком товара. Отношение «один ко многим», поскольку только одна организация может быть поставщиком товара, указанного в счете-фактуре. Класс принадлежности для сущности Организация не является обязательным, поскольку организация может не предоставлять товары. Для сущности Счет-фактура класс принадлежности является обязательным, поскольку в счете-фактуре обязательно должны быть указаны реквизиты организации.

Отношение «Указана» между сущностями Накладная и Организация показывает какая организация предоставила услугу. Отношение «один ко многим», поскольку только одна организация может быть поставщиком услуги, указанной в накладной. Класс принадлежности для сущности Организация не является обязательным, поскольку организация может не предоставлять услуги. Для сущности Накладная класс принадлежности является обязательным, поскольку в счете-фактуре обязательно должны быть указаны реквизиты организации.

Отношение «Указана» между сущностями Акт приема и Организация показывает у какой организации ответственное лицо принимает товар или услугу. Отношение «один ко многим», поскольку только одна организация может быть поставщиком товара или услуги, указанной в акте. Класс принадлежности для сущности Организация не является обязательным, поскольку организация может не предоставлять услуги. Для сущности Акт приема класс принадлежности является обязательным, поскольку в счете-фактуре обязательно должны быть указаны реквизиты организации.

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

Отношение «Предоставлена» между сущностями Услуга и Накладная показывает какие услуги в каком количестве и какой стоимости были предоставлены организации. Отношение «один ко многим», каждая накладная содержит данные только о конкретном случае предоставления услуг. Класс принадлежности для сущности Услуга является обязательным, поскольку услуга приходуется в системе согласно накладной. Для сущности Накладная класс принадлежности является обязательным, поскольку в ней обязательно должна быть указана какая-либо услуга.

Отношение «Соответствует» между сущностями Услуга и Акт приема показывает соответствие предоставленных услуг договору на оказание услуг. Отношение «один ко многим», потому что в каждом акте содержатся данные о конкретном случае предоставления услуг. Класс принадлежности для сущности Услуга является обязательным, поскольку услуга подлежит обязательному приему. Для сущности Акт приема класс принадлежности является обязательным, поскольку в акте обязательно указывается услуга, которая подлежит приему.

На основании перечисленных сущностей, атрибутов и отношений составим логическую модель базы данных в CASE-средстве Erwin Data Modeler (рисунок 2).

Рисунок 2. Логическая модель базы данных

1. Проектирование физической структуры базы данных

Сформируем предварительные отношения:

1. Бинарная связь «Указана» между сущностями Договор и Организация порождает 2 отношения:

• Договор, первичный ключ Код договора;
• Организация, первичный ключ Код организации.

Степень связи – 2.

1. Бинарная связь «Указана» между сущностями Счет-фактура и Организация порождает 2 отношения:

• Счет-фактура, первичный ключ Код счета-фактуры;
• Организация, первичный ключ Код организации.

Степень связи – 2.

1. Бинарная связь «Указана» между сущностями Накладная и Организация порождает 2 отношения:

• Накладная, первичный ключ Код накладной;
• Организация, первичный ключ Код организации.

Степень связи – 2.

1. Бинарная связь «Указана» между сущностями Акт приема и Организация порождает 2 отношения:

• Акт приема, первичный ключ Код акта;
• Организация, первичный ключ Код организации.

Степень связи – 2.

1. Бинарная связь «Отгружен» между сущностями Товар и Счет-фактура порождает 2 отношения:

• Товар, первичный ключ Код товара;
• Счет-фактура, первичный ключ Код счета-фактуры.

Степень связи – 2.

1. Бинарная связь «Предоставлена» между сущностями Услуга и Накладная порождает 2 отношения:

• Услуга, первичный ключ Код услуги;
• Накладная, первичный ключ Код накладной.

Степень связи – 2.

1. Бинарная связь «Соответствует» между сущностями Услуга и Накладная порождает 2 отношения:

• Услуга, первичный ключ Код услуги;
• Накладная, первичный ключ Код накладной.

Степень связи – 2.

Полученные отношения подлежат нормализации. Все перечисленные отношения нормализованы до третьей нормальной формы, потому что все неключевые атрибуты нетранзитивно зависят от первичного ключа и первичные ключи отношений состоят из одного поля. На рисунке 3 представлена схема данных полученных отношений в СУБД MS Access.

Рисунок 3. Схема данных в СУБД MS Access

Практическая часть

1. Контрольный пример решения задачи

В СУБД MS Access ввод данных в базе данных может быть организован двумя способами:

1. С помощью таблиц.
2. С помощью форм.

На рисунке 4 представлена заполненная таблица «Организация».

Рисунок 4. Таблица «Организация»

На рисунке 5 представлена форма для ввода и редактирования данных справочника «Организации». Форма имеет инструменты для создания и удаления записей, перемещения по записям, сохранения данных и закрытия формы.

Рисунок 5. Справочник «Организация»

На рисунке 6 представлена заполненная таблица «Товар».

Рисунок 6. Таблица «Товар»

На рисунке 7 представлена форма ввода данных о товарах. Форма имеет инструменты для создания и удаления записей, перемещения по записям, сохранения данных и закрытия формы.

Рисунок 7. Справочник «Товар»

На рисунке 8 представлена заполненная таблица «Услуга».

На рисунке 9 представлена форма ввода данных об услугах. Форма имеет инструменты для создания и удаления записей, перемещения по записям, сохранения данных и закрытия формы.

Рисунок 8. Таблица «Услуга»

Рисунок 9. Справочник «Услуга»

На рисунке 10 представлена таблица «Договор».

Рисунок 10. Таблица «Договор»

На рисунке 11 представлена форма ввода данных в таблицу «Договор».

Рисунок 11. Форма ввода данных о договоре

На рисунке 12 представлена таблица «Счет-фактура».

Рисунок 12. Таблица «Счет-фактура»

На рисунке 13 представлена форма ввода данных о счете-фактуре.

Рисунок 13. Форма счета-фактуры

На рисунке 14 представлена таблица «Накладная».

Рисунок 14. Таблица «Накладная»

На рисунке 15 представлена форма ввода и редактирования данных о накладной.

Рисунок 15. Форма ввода данных о накладной

На рисунке 16 представлена таблица «Акт приема».

Рисунок 16. Таблица «Акт приема»

На рисунке 17 представлена форма вода данных об акте приема.

Рисунок 17. Форма Акта приема

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

Существует несколько видов запросов к базе данных. Наиболее простыми из них являются запросы на выборку данных. Например, создадим запрос для вывода списка всех контрагентов компании. Результат выполнения запроса представлен на рисунке 18.

Рисунок 18. Результаты выполнения запроса

Реализуем запрос, выводящий список всех приобретенных товаров организации (рисунок 19).

Рисунок 19. Результат выполнения запроса

Реализуем запрос, выводящий список всех приобретенных услуг организации (рисунок 20).

Рисунок 20. Результат выполнения запроса

Реализуем запрос, выводящий список всех заключенных договоров организации (рисунок 21).

Рисунок 21. Список договоров

Создадим более сложные запросы. Вычислим сумму финансовых обязательств компании за предоставленные товары(рисунок 22).

Рисунок 22. Сумма приобретенных товаров

Вычислим сумму финансовых обязательств за предоставленные услуги (рисунок 23).

Рисунок 23. Сумма предоставленных услуг

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

Рисунок 24. Выявленные расхождения

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

Рисунок 25. Результат выполнения запросов

Создадим аналогичный запрос для списка услуг. Результат выполнения запроса представлен на рисунке 26.

Рисунок 26. Результат выполнения запросов

Создадим перекрестный запрос, который будет показывать суммы заключенных договоров по датам их заключения (рисунок 27).

Рисунок 27. Результат выполнения запроса

1. Разработка интерфейса и реализация проекта

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

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

• Ввод данных.
• Редактирование данных.
• Формирование отчетов.

В результате получается кнопочная форма, представленная на рисунке 28. На рисунке 29 представлена кнопочная форма для выбора таблицы для ввода данных. На рисунке 30 представлено меню для редактирования данных. На рисунке 31 представлен список отчетов.

Рисунок 28. Кнопочная форма приложения

Рисунок 29. Меню ввода данных кнопочной формы

Рисунок 30. Меню для редактирования данных

Рисунок 31. Список отчетов

Форма отчета по договорам организации представлена на рисунке 32.

Рисунок 32. Отчет по договорам

На рисунке 33 представлена отчетная форма по списку контрагентов.

Рисунок 33. Форма отчета по контрагентам

На рисунке 34 представлена отчетная форма по расхождениям в предоставленных услугах.

Рисунок 24. Отчет по расхождениям

ЗАКЛЮЧЕНИЕ

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

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

Затем было осуществлено логическое проектирование с помощью CASE-средства Erwin. В нем была создана логическая модель данных, которая включает сущности и связи между ними. Затем была разработана физическая модель данных, которая включала описание атрибутов сущностей с учетом типов данных, используемых в СУБД MS Access.

Полученная диаграмма в CASE-средстве Erwin была проанализирована на предмет «нежелательных» элементов, к которым относятся:

1. Многозначные атрибуты.
2. Производные атрибуты.
3. Рекурсивные связи.
4. Связи с показателем кардинальности «один к одному».
5. Избыточные связи.
6. Связи с показателем кардинальности «многие ко многим».

После проведения анализа была сгенерирована база данных с помощью CASE-средства Erwin. Созданная база данных была заполнена и в ней были разработаны формы, представляющие собой пользовательский интерфейс базы данных.

Список литературы

1. Пятков М.А. Экономика информационных технологий [Текст]: / М.А. Пятаков М.:Наука, 2012. – 325с.
2. Венделева М.А. Информационные технологии управления: учебное пособие для бакалавров: по специальности «Менеджмент организации» [Текст]: / М.А. Венделева, Ю.В. Вертакова. - Москва : Юрайт, 2013. - 462 с.
3. Гвоздева Т.В., Баллод Б.А. Проектирование информационных систем [Текст]:/ Т.В. Гвоздева, Б.А. Балод – М.:Феникс, 2014. – 361с.
4. Горбаченко В.И., Убиенных Г.Ф. Проектирование информационных систем с СА Erwin Modeling Suite 7.3. [Текст]: / В.И. Горбаченко, Г.Ф. Убиенных – П.: ПГУ 2014. - 221с.
5. Грекул В.М, Коровкина Н.А, Куприянов В.С. Проектное управление в сфере информационных технологий [Текст]: / В.М. Грекул, Н.А. Коровкина, В.С. Куприянов. – М.:БИНОМ, ИНФРА-М, 2013. – 322 с.
6. Беккер Й., Велкова Л. Менеджмент процессов [Текст]: / Й. Беккер, Л. Велкова - М.: Эксмо, 2014. - 384с.
7. Елиферов В.Г., Репин В.В. Процессный подход к управлению. Моделирование бизнес-процессов [Текст]: / В.Г. Елиферов, В.В. Репин. – М.:Манн, Иванов и Фербер, 2013. – 411с.
8. Избачков Ю.С., Петров В.Н. Информационные системы [Текст]: / Ю.С. Избачков, В.Н. Петров. – СПб,: Амфора. 2014. – 341с.
9. Исаев Г.Н. Проектирование информационных систем [Текст]: / Г.Н. Исаев. – М.: Омега-Л, 2015. – 274с.
10. Киселев Г.М. Информационные технологии в экономике и управлении [Текст]: / Г.М. Киселев, Р.В. Бочкова, В.И. Сафонов. – М.:Дашков и К, 2012. - 268 с.