Файл: Проектирование реализации операций бизнес-процесса «Управление документооборотом» ООО «Крафт-С».pdf
Добавлен: 14.06.2023
Просмотров: 502
Скачиваний: 3
СОДЕРЖАНИЕ
Глава 1. Анализ и характеристика бизнес-процессов в ООО «Крафт-С»
1.2 Классификация бизнес-процессов
1.3 Обеспечивающие бизнес-процессы
1.4 Бизнес-процессы управления
1.5 Характеристика, анализ и оценка базовых бизнес-процессов в ООО «Крафт-С»
Глава 2. Разработка технического задания
Актуальность темы определяется значимостью современного механизма хозяйствования предприятий. Суперволатильность экономической системы в целом, обостряющаяся конкуренция, возникновение социальных проблем побуждают искать более обоснованные и эффективные формы и методы управления. Самым «чувствительным» и действенным рычагом управления является заработная плата. Ее изменения, по мнению авторов, должны корректироваться в зависимости от изменения внутренних и внешних условий при обязательном и более эффективном исполнении главных функций заработной платы.
Заработная плата как экономическая категория и экономический рычаг в управлении хозяйственной деятельностью предприятия приобретает новое содержание и возросшее многообразие форм в условиях рыночной системы экономики. Волатильность этой категории продиктована рыночными по характеру изменениями функций зарплаты. Именно они, эти функции заработной платы в новых условиях претерпевают коренное, глубинное изменение. Отсюда традиционный подход к сущности заработной платы, ее организации, расчету эффективных размеров в индивидуальном и совокупном общественном измерении представляются устаревшими. Положим в основу нашего исследования функциональный анализ современной категории заработной платы.
Во-первых, заработная плата выполняет воспроизводственную функцию, то есть должна возмещать и расширенно воспроизводить стоимость рабочей силы. В современных условиях расходы на воспроизводство рабочей силы значительно возросли. Рост произошел за счет расширения потребностей современного человека в силу действия объективного закона возвышения потребностей. Кратно увеличились затраты на образование. Научнотехнический прогресс, в свою очередь, потребовал подготовки работников более высокой квалификации по сравнению даже с 15 - 20 летним ранним периодом. Процесс урбанизации населения, превышение численности городского населения по соотношению с сельским - также воздействует на рост стоимости рабочей силы. Жизнь в городских условиях намного затратнее, чем в сельской местности по многим общеизвестным причинам. В условиях плановой экономики была возможность регулировать рост цен на большинство потребительских товаров. Компенсировались в значительной части расходы на среднее образование и профессиональное обучение за счет государственного бюджета. В рыночной экономике эти и другие траты на рабочую силу перенесены и возмещаются из семейного бюджета, где преобладающим источником доходов является заработная плата.
2.1 Разработка базы данных
Целью разработки любой базы данных является хранение и использование информации о какой-либо предметной области. Для реализации этой цели имеются следующие инструменты:
Реляционная модель данных - удобный способ представления данных предметной области.
Язык SQL - универсальный способ манипулирования такими данными.
Очевидно, что для одной и той же предметной области реляционные отношения можно спроектировать множеством различных способов. Далее определим критерии качественности базы данных[6]:
Адекватность базы данных предметной области;
Легкость разработки и сопровождения базы данных;
Скорость выполнения операций обновления данных (вставка, обновление, удаление кортежей);
Скорость выполнения операций выборки данных.
База данных должна адекватно отражать предметную область. Это означает, что должны выполняться следующие условия[7]:
Состояние базы данных в каждый момент времени должно соответствовать состоянию предметной области.
Изменение состояния предметной области должно приводить к соответствующему изменению состояния базы данных
Ограничения предметной области, отраженные в модели предметной области, должны некоторым образом отражаться и учитываться базе данных.
Практически любая база данных, за исключением совершенно элементарных, содержит некоторое количество программного кода в виде триггеров и хранимых процедур. Очевидно, что чем больше программного кода в виде триггеров и хранимых процедур содержит база данных, тем сложнее ее разработка и дальнейшее сопровождение.
Основными операциями, изменяющими состояние базы данных, являются операции вставки, обновления и удаления записей. В базах данных, требующих постоянных изменений производительность определяется скоростью выполнения большого количества небольших операций вставки, обновления и удаления. Одно из назначений базы данных - предоставление информации пользователям.
Удачная разработка базы данных обеспечивает простоту ее поддержки. Данные следует сохранять в таблицах, причем каждая таблица должна содержать информацию одного типа. Тогда достаточно будет обновить конкретные данные только в одном месте, чтобы обновленная информация отображалась во всей базе данных.
Правильно спроектированная база данных обычно содержит разнообразные запросы, позволяющие отображать нужную информацию. В запросах может выводиться подмножество данных или комбинированные данные из нескольких таблиц, например сведения о заказах совместно со сведениями о заказчиках.
База данных проектируемой Автоматизированной Системы Управления документооборотом Департамента Аренды (далее и везде АСУ Департамента Аренды) содержит 3 основных таблицы (Clients, Objects, Operations) на основании которых можно получить полную информацию по требуемым отчётам.
Таблица «Clients» является хранилищем информации о клиентах, обратившихся с заявками в Департамент Аренды, структура таблицы «Clients» приведена ниже.
Структура таблицы «clients»
|
Название поля |
Тип |
Описание поля |
|
docid |
integer |
Номер документа |
|
clientid |
integer |
Идентификатор клиента |
|
clientname |
varchar (150) |
Наименование клиента |
|
objectkat |
char |
Требуемая категория объекта (А, Б, В) |
|
clientinput |
datetime |
Дата заявки |
|
clientprice |
integer |
Цена |
|
clientstatus |
char |
Отметка: заявка в работе/заявка на оформлении/заявка выполнена |
|
clientmanager |
varchar(40) |
Ответственный сотрудник (исполнитель операции) |
Внесем необходимые пояснения по описанию:
Идентификатор клиента это уникальный индивидуальный номер клиента, под которым он внесен в базу данных;
Наименование клиента по юридическому статусу (ООО либо ОАО/ЗАО в случае если клиент корпоративный), либо имя клиента, в том случае если клиент – частное лицо;
Требуемая категория объекта и цена: в данном случае указывается, какой именно категории объект и по какой цене интересует клиента;
Дата заявки – фактический день обращения клиента в Департамент Аренды;
Отметка описывает процесс работы с клиентом (заявка в работе – клиенту предложены объекты из категории, идет практический выбор объекта; заявка в оформлении – клиент определил объект, идет оформление сопроводительной документации; заявка выполнена – сопроводительные документы оформлены, счет за услуги оплачен/оплачивается);
Ответственный сотрудник – фамилия ответственного сотрудника Департамента Аренды, назначенного к данному клиенту руководителем клиентского отдела.
«Objects» – таблица служит хранилищем информации об объектах недвижимости, которые имеются в каталоге Департамента Аренды, структура таблицы «Objects» приведена ниже.
Структура таблицы «obects»
|
Название поля |
Тип |
Описание поля |
|
docid |
integer |
Номер документа |
|
objectid |
integer |
Идентификатор объекта |
|
objectname |
varchar (150) |
Наименование объекта |
|
objectkat |
char |
Категория объекта (А, Б, В) |
|
objectinput |
datetime |
Дата постановки объекта в базу |
|
objectprice |
integer |
Цена |
|
objectstatus |
char |
Отметка: сдан/не сдан/резерв/оформляется |
|
objectmanager |
varchar(40) |
Ответственный сотрудник (исполнитель операции) |
Внесем необходимые пояснения по описанию:
Идентификатор объекта это уникальный индивидуальный номер объекта, под которым он внесен в базу данных;
Наименование объекта – фактическое название объекта;
Категория объекта вносится в соответствие с принятой градацией объектов недвижимости (категория А – объекты, стоимость аренды которых составляет от 1 млн. руб.; категория В – объекты, стоимость аренды которых составляет от 500 тыс. руб. до 1 млн. руб.; категория С – объекты, стоимость аренды которых составляет до 500 тыс. руб.);
Дата постановки объекта в базу – фактический день внесения объекта в базу;
Цена – фактическая стоимость аренды объекта, определенная Департаментом Эксплуатации;
Отметка описывает процесс работы с объектом аналогично отметке по клиенту;
Ответственный сотрудник – фамилия ответственного сотрудника Департамента Аренды, за которым закреплен конкретный объект руководителем клиентского отдела.
«Operations» - таблица содержит информацию обо всех сделках с объектами недвижимости и клиентами за определенный период.
Внесем необходимые пояснения по описанию:
Идентификатор объекта или клиента – уникальный номер, присваиваемый объекту или клиенту при внесении в базу;
Дата совершения операции – фактический день заключения договора аренды с клиентом;
Отметка расчета по операции ставится исходя из фактических расчетов уже произведенных клиентом (наличные денежные средства либо безналичные), в том случае если клиент не оплатил выставленный счет, ставится отметка «не определен»;
Структура таблицы «Operations»
|
Название |
Тип |
Описание поля |
|
docid |
integer |
Номер документа |
|
objectid/clientid |
integer |
Идентификатор объекта или клиента |
|
operationdate |
datetime |
Дата совершения операции |
|
operationcurrency |
char |
Расчёт по операции (нал, безнал, не определён) |
|
operationincome |
integer |
Приход денежных средств |
|
operationdebt |
integer |
Дебиторская задолженность |
|
operationmanager |
varchar(40) |
Ответственный сотрудник (исполнитель операции) |
Приход денежных средств отражает фактическую суммы оплаты счета клиентом;
Дебиторская задолженность возникает в том случае, если клиент не оплатил счет, фактически показывает, какой размер дебиторской задолженности числится за данным клиентом и/или объектом;
Ответственный сотрудник – фамилия ответственного сотрудника Департамента Аренды, за которым закреплен конкретный объект или клиент руководителем клиентского отдела.
Связь таблиц 8, 9 и 10 осуществляется по ключевому полю docid*, slitset таблица срезов, которые указывают на один аналитический счет в таблице account (ключ id). Программный код файла data.cpp, который отвечает за выполнение операций исполнения документов и функционирование АСУ Департамента Аренды в целом приведен в приложении А.
Далее на основании разработанной базы данных необходимо формализовать бизнес-процессы, с этой целью разработаем функциональную модель бизнес-процесса предоставления услуг (т.е. основного бизнес-процесса Департамента Аренды). В приложении 5 представлена функциональная модель бизнес-процесса предоставления услуг в соответствие с проектируемой АСУ документооборотом.
Итак, в соответствие с проектируемой АСУ, процесс предоставления услуги начинается с регистрации заявки клиента в Журнале заявок АСУ (сфера ответственности и доступ – руководители клиентских отделов), факторы влияния – сформированный необходимый каталог объектов от Департамента Эксплуатации и внешняя конъюнктура рынка, на последний фактор Департамент Аренды не может оказывать влияние, но должен его учитывать при формировании предложения.
Сотрудники, ежедневно просматривая Журнал заявок, отбирают новых клиентов, закрепленных за ними. Формирование предложения идет на основании прайс-листа Департамента Аренды, который формируется в АСУ по категориям объектов и предлагается для изучения непосредственно клиенту.
Далее, клиент выбирает наиболее подходящий ему объект (объекты), основная задача операционного сотрудника на данном этапе это проставить отметку о процессе взаимодействия в Журнале клиентов (см. табл. 8 описание поля «отметка») и организовать непосредственный просмотр выбранного объекта (объектов).
После того, как клиент определил необходимый ему объект и готов заключить сделку, ответственный операционный сотрудник проставляет необходимые отметки в АСУ, как в Журнале клиентов, так и в Объектах (см. табл. 8 и 9 описание полей «отметка»), кроме этого, ответственный сотрудник предоставляет клиенту пакет документов по сделке, в соответствие с правилами заключения сделок и условиями договора клиенту выставляется счет или счет-фактура на оплату услуг Департамента Аренды, при этом также проставляются необходимые отметки в АСУ.
После того, как договор заключен и произведена (либо производится) оплата услуг, часть оформленного пакета документов передается клиенту, часть передается руководителю клиентского отдела, который делает необходимые отметки в АСУ, передает первичные бухгалтерские документы в соответствующий отдел, в автоматизированном режиме формирует отчетность для управленческих бизнес-процессов собственно Департамента Аренды и для Департамента Эксплуатации.