Разработка регламента выполнения процесса «Расчет заработной платы» (Описание предметной области. Постановка задачи)

Содержание:

ВВЕДЕНИЕ

Прежде чем создать информационную систему расчета заработной платы необходимо понять, как работает организация, для которой создается данная модель. Никто в организации не знает, как она работает в той мере подробности, которая необходима для создания информационной системы. Руководитель хорошо знает работу в целом, но не в состоянии вникнуть в детали работы каждого рядового сотрудника. Рядовой сотрудник хорошо знает, что творится на его рабочем месте, но плохо знает, как работают коллеги. Поэтому для описания работы предприятия необходимо построить модель. Такая модель должна быть адекватна предметной области, следовательно, она должна содержать в себе знания всех участников бизнес-процессов организации. Наиболее удобным языком моделирования бизнес-процессов является IDEF0, предложенный более 20 лет назад и называвшийся первоначально SADT - Structured Analysis and Design Technique.

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

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

Целью курсовой работы является разработка регламента выполнения процесса «Расчет заработной платы».

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

• Выполнить описание предметной области;
• Выбрать средство для моделирования бизнес-процессов;
• Выполнить моделирование бизнес-процессов «как есть» и «как должно быть».

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

Предмет исследования – средства для автоматизации моделирования бизнес процессов.

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

Во второй главе раскрыты методы совершенствования созданной модели.

В ходе работы были созданы диаграммы IDEF0 в среде Ramus.

Глава 1. Создание модели для процесса расчета заработной платы

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

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

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

Оплата труда может быть сдельной или повременной. Рассмотрим основные нюансы применения данных систем.

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

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

Рассмотрим, какую же формулу применяют для расчета по сдельной оплате и по окладу.

Зарплата по окладу = окладная часть / количество рабочих дней за определенный период * количество отработанных дней + сумма премиальных – НДФЛ – удержанные суммы с зарплаты.

Зарплата = сдельные расценки * количество произведенной продукции + сумма премиальных + доплаты – НДФЛ – удержания с заработной платы.

От полученного результата необходимо вычесть сумму НДФЛ.

Зарплата за полный месяц определяется по вышеприведенной формуле. Но как быть, если сотрудник не полностью отработал период? Зарплата за неполный месяц = значение, полученное при расчете по формуле / количество рабочих дней за определенный период * количество отработанных дней по факту.

Заработная плата за один день = значение, полученное при расчете по формуле / количество рабочих дней в периоде.

При расчете зарплаты за год принято использовать средний дневной заработок:

Средняя зарплата за день = сумма зарплаты за год / количество месяцев / 29,3.

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

Заработная плата, если в расчетном периоде был отпуск = оклад работника / общее количество рабочих дней в периоде * количество фактически отработанных дней в месяце.

Сумма аванса рассчитывается по следующей формуле:

Аванс = оклад сотрудника / количество рабочих дней за определенный период * количество рабочих дней в месяце до даты выплаты аванса.

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

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

Ставка налога на доходы физических лиц составляет 13 %. НДФЛ удерживается один раз в месяц с основной части заработной платы. Аванс подоходным налогом не облагается. Все дополнительные надбавки суммируются и в конечном итоге формируют итоговое значение заработной платы:

Общая заработная плата = оклад + больничные + отпускные + командировочные.

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

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

1.2 Выбор средства для моделирования бизнес-процессов

Описание бизнес-процесса некоторой предметной области можно сформировать с помощью нотации и инструментальной среды. Рассмотрим нотации ARIS eEPC и IDEF.

Описание нотации ARIS eEPC

Нотация ARIS eEPC расшифровывается следующим образом - extended Event Driven Process Chain – расширенная нотация описания цепочки процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером. В следующей таблице приводятся основные используемые в рамках нотации объекты (см. таблицу 1.2.1)

Таблица 1.2.1 – Основные элементы нотации ARIS

Наименование	Описание	Графическое представление
Функция	Объект «Функция» служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия.
Событие	Объект «Событие» служит для описания реальных состояний системы, влияющих и управляющих выполнением функций
Организационная единица	Объект, отражающий различные организационные звенья предприятия (например, управление или отдел)
Документ	Объект, отражающий реальные носители информации, например бумажный документ
Прикладная система	Объект отражает реальную прикладную систему, используемую в рамках технологии выполнения функции
Кластер информации	Объект характеризует данные, как набор сущностей и связей между ними. Используется для создания моделей данных
Стрелка связи между объектами	Объект описывает тип отношений между другими объектами, например – активацию выполнения функции некоторым событием
Логическое «И»	Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса
Логическое «ИЛИ»	Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса
Логическое исключающее «ИЛИ»	Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса

Помимо указанных в Таблице 1,2.1 основных объектов, при построении диаграммы eEPC могут быть использованы многие другие объекты. Применение большого числа различных объектов, связанных различными типами связей значительно увеличивает размер модели и делает ее плохо читаемой. Для понимания смысла нотации eEPC достаточно рассмотреть основные используемые типы объектов и связей. На следующем рисунке представлена простейшая модель eEPC, описывающая фрагмент бизнес-процесса предприятия.

Рисунок 1.2.1 – Фрагмент модели в нотации ARIS.

На рисунке 1.2.1 видно, что связи между объектами имеют определенный смысл и отражают последовательность выполнения функций в рамках процесса. Стрелка, соединяющая Событие 1 и Функцию 1 «активирует» или инициирует выполнение Функции 1. Функция 1 «создает» Событие 2, за которым следует символ логического «И», «запускающий» выполнение Функций 2 и 3. Нотация eEPC построена на определенных семантических правилах описания:

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

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

Таким образом, при помощи нотации eEPC ARIS можно описывать бизнес-процесс в виде потока последовательно выполняемых работ (процедур, функций).

Описание нотации IDEF0, IDEF3

Нотация IDEF0 [4] была разработана на основе методологии структурного анализа и проектирования SADT, утверждена в качестве стандарта США и успешно эксплуатируется во многих проектах, связанных с описанием деятельности предприятий. Нотация IDEF3 была разработана с целью более удобного описания рабочих процессов, для которых важно отразить логическую последовательность выполнения процедур. Нотации IDEF0 и IDEF3 используют следующие объекты (см. таблицу 1.2.2).

Таблица 1.2.2 – Основные составляющие нотаций IDEF0 и IDEF3

Наименование	Описание	Графическое представление
Нотация IDEF3
Модуль поведения (UOB)	Объект служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия.
Стрелка слева	Стрелка описывает входящие документы, информацию, материальные ресурсы, необходимые для выполнения функции.
Стрелка справа	Стрелка описывает исходящие документы, информацию, материальные ресурсы, являющиеся результатом выполнения функции.
Стрелка сверху	Стрелка описывает управляющее воздействия, например распоряжение, нормативный документ и т.д. В нотации IDEF0 каждая процедура должна обязательно иметь не менее одной стрелки сверху, отражающей управляющее воздействие.
Стрелка снизу	Стрелка снизу описывает т.н. механизмы, т.е. ресурсы, необходимые для выполнения процедуры, но не изменяющие в процессе ее выполнения свое состояние. Примеры: сотрудник, станок и т.д.
Нотация IDEF3
Модель работы (UOW)	Объект служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия.
Ссылочный объект	Объект, используемый для описания ссылок на другие диаграммы модели, циклические переходы в рамках одной модели, различные комментарии к функциям
Логическое «И»	Логический оператор, определяющий связи между функциями в рамках процесса. Позволяет описать ветвление процесса
Логическое «ИЛИ»	Логический оператор, определяющий связи между функциями в рамках процесса. Позволяет описать ветвление процесса
Логическое исключающее «ИЛИ»	Логический оператор, определяющий связи функциями в рамках процесса. Позволяет описать ветвление процесса

Рисунок 1.2.2 – Пример модели IDEF0

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

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

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

Функциональные возможности инструментальных средств моделирования ARIS Toolset и BPWin можно корректно сравнивать только по отношению к определенному кругу задач. В данном исследовании рассматривается задача формирования моделей (описания) бизнес-процессов предприятия. Каждая из рассматриваемых систем имеет свои преимущества и недостатки. В зависимости от решаемых задач эти преимущества могут как усиливаться, так и наоборот. То же касается и недостатков: недостаток системы в рамках одного проекта, может не быть недостатком в рамках другого. Например, отсутствие четких соглашений по моделированию управляющих воздействий в рамках eEPC ARIS может привести к созданию моделей, не отвечающих на поставленные вопросы, в то время как нотация IDEF0 системы.

BPWin позволяет решить эту задачу. С другой стороны, описание процедуры, выполняемой одним сотрудником, может быть описано более адекватно при помощи eEPC ARIS, чем IDEF0 или IDEF3 BPWin. Сравнение функциональных возможностей систем приводится в следующей таблице:

Таблица 1.2.3 – Сравнение Aris Toolset и BPwin

Возможности/ Инструментальная среда	ARIS Toolset	BPWin 4.0
Поддерживаемый стандарт	- (частично – DFD, ERM, UML)	IDEF0, IDEF3, DFD
Система хранения данных модели	Объектная база данных	Модели хранятся в файлах
Ограничение на размер базы данных	Нет. Размер базы данных ограничивается вычислительными ресурсами	Нет. Размер базы данных ограничивается вычислительными ресурсами
Возможность групповой работы	Есть. Используется ARIS Server.	Есть. Используется Model Mart.
Ограничение на количество объектов на диаграмме	нет	от 2 до 8
Возможность декомпозиции	Неограниченная декомпозиция. Возможна декомпозиция на различные типы моделей.	Неограниченная декомпозиция. Возможен однократный переход на другую нотацию в процессе декомпозиции
Формат представления моделей	Не регламентируется	Стандартный бланк IDEF с возможностью его отключения
Удобство работы по созданию моделей	Сложная панель управления, есть выравнивание объектов, есть undo.	Простая панель управления, нет выравнивания объектов, нет undo.
Возможность анализа стоимости процессов	Есть. Возможность использовать ARIS ABC	Упрощенный анализ стоимости по частоте использования в процессе. Возможность экспорта в Easy ABC.
Генерация отчетов	Создание отчетов на основе стандартных и настраиваемых пользователем макросов Visual Basic.	RPT Win, возможность визуальной настройки отчетов, включая расчет по формулам с использованием UDP
Сложность разработки нестандартных отчетов	сложно	просто

Сравнивая две системы, следует сразу отметить, что для хранения моделей в ARIS используется объектная СУБД, и под каждый проект создается новая база данных. Для удобства пользователя модели (объекты моделей) могут храниться в различных группах, организованных в зависимости от специфики проекта. Вполне естественно, что в ARIS-е предусмотрены различные функции по администрированию базы данных: управление доступом, консолидация и т.п. В BPWin данные модели хранятся в файле, что существенно упрощает работу по созданию модели, но с другой стороны ограничивает возможности по анализу объектов модели. В Model Mart так же предусмотрено администрирование базы данных.

Часто одним из недостатков BPWin сторонники ARIS-а называют ограничение по количеству объектов на диаграмме. Однако опыт реальных проектов показывает, что для проекта, результаты которого можно реально использовать (критерий – обозримость), количество объектов в базе данных ARIS или модели BPWin составляет 150-300. Это означает, что при 8 объектах на одной диаграмме, общее количество диаграмм (листов) в модели составит 20-40. Базы данных ARIS Toolset (как и BPWin), содержащие более 500 объектов, фактически невозможно использовать.

ARIS предоставляет существенно больше возможностей по работе с отдельными объектами модели, но именно вследствие чрезмерного количества настроек работа по созданию модели должна регламентироваться сложной, многоаспектной документацией – т.н. «Соглашениями по моделированию». Разработка этих «Соглашений» само по себя является сложной, дорогой и требующей значительного времени (1-3 месяца) и квалифицированных специалистов задачей.

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

ARIS, безусловно, является более «тяжелым» инструментом, по сравнению с BPWin, но это в итоге оборачивается значительными трудностями и высокими затратами на его эксплуатацию

1.3 Моделирование бизнес-процессов «как есть»

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

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

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

• вход - это потребляемая или изменяемая работой информация или материал;
• выход - информация или материал, которые производятся работой;
• управление - процедуры, правила, стратегии или стандарты, которыми руководствуется работа;
• механизмы - ресурсы, которые выполняют работу (материалы, персонал);

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

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

Выходная стрелка – «Расчетная ведомость». Расчетная ведомость документ, в котором отражается весь процесс расчета зарплаты.

Стрелки управления:

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

Рисунок 1.3.1 – Контекстная диаграмма, выполненная в нотации IDEF0

На основе контекстной диаграммы построим диаграмму декомпозиции (рисунок 1.3.2).

Декомпозиция - это разделение сложного объекта, системы, задачи на составные части, элементы.

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

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

Рассмотрим входные стрелки работы «Расчет зарплаты по дням». Стрелки «листок нетрудоспособности», «табель», «приказ о выходе в отпуск», соединим с работой «Расчет зарплаты по дням». Стрелки «Приказ о зачислении на работу», «размер оклада» будут стрелками управления для работы «Расчет зарплаты по дням». Стрелки «приказ об алиментах» и «приказ о назначении премии» соединим с работой «Рассчитать надбавки и вычеты». Стрелка «размер налоговых, страховых и пенсионных отчислений» будет стрелкой управления для процесса «Рассчитать налоговые, страховые и пенсионные отчисления». Итоговой работой расчета зарплаты является процесс «Вывести итоговые суммы зарплаты и завершить заполнение расчетной ведомости». Владельцем всех процессов является бухгалтер. На выходе данной работы получаем документ «расчетная ведомость», в котором отражены суммы заработных плат работников организации.

Рисунок 1.3.2 - Диаграмма декомпозиции первого уровня

Таким образом, получили диаграмму декомпозиции первого уровня для модели «как есть».

Глава 2. Совершенствование бизнес-процессов. Модель «как должно быть»

2.1. Предлагаемые мероприятия по улучшению бизнес-процессов

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

Таблица 2.1.1 Формальные методики и стандарты совершенствования бизнес-процессов

Название	Описание
Шесть сигм (Six Sigma)	Строгая, основанная на фактах методика, позволяющая выявлять и устранять недостатки в любых процессах. Направлена на всемерное повышение эффективности, надежности и потребительской ценности товаров и услуг. Методика «Шесть сигм» была разработана в 1980-е годы в компании Motorola, когда ее руководство осознало, что в ходе использования продукты с минимумом изначальных недочетов отказывают значительно реже. Греческая буква сигма обозначает отклонение от стандарта.
Всеобщее управление качеством (Total Quality Management, TQM)	Стратегия менеджмента, цель которой — внедрение заботы о качестве в каждый процесс, осуществляемый в организации, и всемерное поощрение действий сотрудников, направленных на повышение удовлетворенности клиентов и снижение издержек. Активно внедрялась в Японии после Второй мировой войны американским статистиком и преподавателем Эдвардом Демингом. Позднее Джозеф Джуран расширил концепцию управления качеством, отойдя от узкостатистического толкования и уделив максимум внимания человеческой составляющей.
ISO 9000	Серия стандартов систем управления качеством (ISO). Эти стандарты не гарантируют качество конечного товара или услуги — скорее они удостоверяют тот факт, что компания использует сертифицированные бизнес-процессы. Стандарты ISO 9000 находятся в ведении структур, отвечающих за аккредитацию и сертификацию.
Реинжиниринг бизнес-процессов (BPR)	Методика менеджмента, обеспечивающая радикальное совершенствование рабочих процессов как внутри отдельной организации, так и между организациями с целью значительного повышения эффективности деятельности. Стремительный взлет этой методики относится к началу 1990-х годов, когда Майкл Хаммер и Джеймс Чампи опубликовали свой революционный бестселлер «Реинжиниринг корпорации».

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

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

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

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

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

Перейдем к созданию модели «как должно быть» для расчета заработной платы с использованием автоматизированной информационной системы.

2.2 Моделирование бизнес-процессов «как должно быть»

После анализа и утверждения модели «как есть» (AS-IS) можно приступить к построению модели «как должно быть» (TO-BE). Модель TO-BE показывает, какой будет работа после создания системы, какие изменения при этом будут внесены. Конструктивным отличием модели является использование информационной системы. Благодаря ее внедрению в производство, значительно сокращаются потери времени на обработку информации, также устраняется ряд операций имевших место в существующей модели организации бизнеса, что приводит к уменьшению издержек.

Контекстная диаграмма в функциональной модели «Как должно быть» имеет следующий вид, представленный на рисунке 2.2.1.

Рисунок 2.2.1 – Контекстная диаграмма «Расчет заработной платы»

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

Выходные потоки: «расчетная ведомость».

Управление: «формулы для расчета зарплаты», «приказ о зачислении на работу», «размер оклада», «размер налоговых», «пенсионных и страховых отчислений».

Механизмы исполнения: «бухгалтер», «ИС».

Основным отличием является добавление Потока «ИС», для преобразования входных потоков в выходные.

Рисунок 2.2.2 – Декомпозиция контекстной диаграммы

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

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

Выход: «данные о сотрудниках»;

Управление: «правила заполнения форм», «приказ о зачислении на работу».

Также создан дополнительный блок «Внести данные о сотрудниках в ИС».

Вход: «данные о сотрудниках».

Выход: «расчетная ведомость».

Управление: «формулы для расчета зарплаты», «приказ о зачислении на работу», «размер оклада», «размер налоговых, пенсионных и страховых отчислений».

Механизмы исполнения: «ИС».

Итак, на основе результатов анализа модели процессов AS-IS («как есть») создана модель TO-BE («как должно быть»), которая описывает будущее состояние процессов с учётом анализа и оптимизации существующих процессов.

ЗАКЛЮЧЕНИЕ

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

Модель AS-IS («как есть») позволяет отразить текущую ситуацию, систематизировать протекающие в организации процессы и информационные потоки в рамках этих процессов. На основе данной модели выявляются проблемные (узкие) места при выполнении и взаимодействии процессов, определяется необходимость внесения тех или иных изменений.

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

В рамках описания процессов TO-BE («как должно быть») выделяются все процессы исследуемой области деятельности, определяются участники, ответственные за результат, наделенные необходимыми полномочиями и правами и их взаимодействие между собой.

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

В данной курсовой работе были получены практические навыки работы в системе проектирования Ramus (бесплатный аналог BPWin), разработана модель процесса «Расчет заработной платы». Для построения этой модели выполнено описание предметной области, моделирование бизнес-процессов «как есть» и «как должно быть».

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

Таким образом, все поставленные задачи выполнены, а цель достигнута.

СПИСОК ЛИТЕРАТУРЫ

• Голицына О.Л., Максимов Н.В., Попов И.И.. «Информационные системы: учебное пособие. Москва: ФОРУМ: ИНФРА-М, 2012г. 496 стр.
• Гагарина Л.Г., Киселев Д.В., Федотова Е.Л.: учеб. Пособие / Под ред. Проф. Л.Г.Гагариной. «Разработка и эксплуатация автоматизированных информационных систем», 2010г. 384 стр.
• Михеев Е.В. «. Информационные технологии в профессиональной деятельности», Москва: ТК Велби, Проспект, 2015г. 448стр.
• Фуфаев Э.В. «Разработка и эксплуатация удаленных баз данных», Москва: Издательский центр «Академия» 2011г. 256 стр.
• Грегори Р. Эндрюс, «Основы многопоточного, параллельного и распределенного программирования», Москва: Вильямс 2011г. 512 стр.
• Эдвард Йордон, Карл Аргила, «Объектно-ориентированный анализ и проектирование систем», Москва: Лори 2012г. 264 стр.
• Гребенюк Е. И. , Гребенюк Н. А. «Технические средства информатизации», ИД «Академия» 2013г. 272 стр.
• Е. П. Истомин, В. В. Новиков М.В.Новикова «Высокоуровневые методы информатики и программирования»2011г. 228 стр.
• Гвоздева В.А. «Основы построения автоматизированных информационных систем: учебник», Москва: ИНФРА-М 2014г. 320 стр.
• А.Д. Хомоненко, В.М. Цыганков, М.Г. Мальцев «Базы данных. Учебник для вузов, Санкт - Петербург: КОРОНА принт, 2011г. 736 стр.
• Романенко А. Г., Самойлюк О. Ф., Максимович Г. Ю., «Информационные системы: Учебное пособие - 2-е издание, дополнительное Учебное пособие» - Москва: Российский государственный гуманитарный университет, Издательский центр, Издательский центр РГГУ, 2012г.

Михеева Е.В. «Практикум по информационным технологиям в профессиональной деятельности», Москва: Academia, 2011г. 256 стр.

ПРИЛОЖЕНИЯ

Рисунок 1.3.1 – Контекстная диаграмма, выполненная в нотации IDEF0

Рисунок 1.3.2 - Диаграмма декомпозиции

Рисунок 2.2.1 – Контекстная диаграмма «Расчет заработной платы»

Рисунок 2.2.2 – Декомпозиция контекстной диаграммы