Файл: Разработка регламента выполнения процесса «Складской учет» (РАЗРАБОТКА КОНЦЕПТУАЛЬНОЙ МОДЕЛИ «СКЛАДСКОЙ УЧЕТ»).pdf
Добавлен: 03.04.2023
Просмотров: 341
Скачиваний: 3
3. С точки зрения релевантности содержания модели делятся на (Рисунок 13) :
- Модель «Как есть» («AS IS»): отражает реальное состояние дел во время описания, фактически существующих бизнес процессов предприятия.
- Модель «Как должно быть» («TO BE»): отражает целевое состояние, которое в будущем предполагается реализовать. Например, модель вновь открытого предприятия или новый (совершенно новый или улучшенный старый) порядок выполнения любой работы.
- Модель «Как должно бы быть» (английский «SHOULD BE»): отражает «идеализированное» положение дел (например, согласно нормативным документам, тогда как фактическая схема работы в действительности может быть несколько иной). На практике необходимость создания таких моделей встречается редко.
Рисунок 13 – Взаимосвязь моделей при реинжиниринге бизнес-процессов
Модели бизнес-процессов используются предприятиями различного назначения, которые определяют тип разрабатываемой модели. Графическая модель бизнес-процесса в виде интуитивно понятной, общепринятой схемы может служить для обучения новых сотрудников их служебным обязанностям, координации действий между структурными подразделениями компании, выбора или разработки компонентов информационной системы и т. д.
Моделирование бизнес-процессов позволяет оценить эффективность процессов протекающих на предприятии и посмотреть, как процесс будет выполняться с входными данными, которые еще не встречались в реальной работе предприятия. Исполняемые модели бизнес-процессов можно запускать на специальном программном обеспечении для автоматизации процесса непосредственно на модели.
Реализация бизнес-процесса подразумевает использование соответствующих инструментов: чертежей, диаграмм, графиков, форм, а также готовых решений, таких как специальное программное обеспечение.
Основной темой курсовой работы является изучение функциональных моделей бизнес-процессов, рассмотрим их более подробно
Методология IDEF0 является графическим языком для описания функциональных систем SADT (Structured Analysis and Design Technique).
Цель функциональной методики описания бизнес-процессов предприятия – это построить функциональную диаграмму исследуемой системы, описывая все необходимые процессы с достаточной точностью, чтобы однозначно моделировать работу системы.
Методология основана на четырех основных понятиях: функциональный блок, дуга интерфейса, декомпозиция, глоссарий (Рисунок 15).
Рисунок 14 – Функциональный блок
Функциональный блок описания процессов предприятия (Activity Box) является специфической функцией в рамках рассматриваемой системы. Название каждого функционального блока, описывающего процессы предприятий, должно быть глаголом (например, «производить услуги»). На диаграмме функциональный блок представлен прямоугольником Каждая из четырех сторон функционального блока имеет свое специфическое значение (роль), в то время
• верхняя стрелка, это информация, отвечающая за "Управление" (Control) ;
• левая стрелка, это информация, отвечающая за - "Вход" (Input);
• правая стрелка, это информация, отвечающая за - "Выход" (Output);
• нижняя стрелка, это информация, отвечающая за, - "Механизм" (Mechanism).
Интерфейсная дуга (Arrow) отображает элемент системы. Интерфейсные дуги часто называют потоками или стрелками. Интерфейсными дугами могут быть элементы реального мира или потоки данных и информации.
В зависимости от того, к какой из сторон функционального блока подходит интерфейсная дуга, может быть[5]:
- "входящей",
- "исходящей",
- "управляющей".
Разложение одного функционального блока на составляющие является основой концепции стандарта IDEF0. Принцип декомпозиции применяется, когда сложный процесс делится на его компоненты.
Модель IDEF0 всегда начинается с представления всей системы в целом - интерфейса функционального блока с дугами, выходящими за пределы обрабатываемой области. Такая диаграмма с одной функциональной единицей называется контекстуальной схемой.
Точка зрения определяет основное направление развития модели и уровень детализации. Правильный выбор точки зрения значительно сокращает время, затрачиваемое на построение окончательной модели.
Рекомендуется использовать от трех до шести функциональных блоков для использования в схеме, количество соответствующих функциональных блоков в одном (на основе одного функционального блока) должно быть лучше четырех.
Интуитивный графический язык IDEF0 делает модель вполне читаемой и для тех, кто не участвовал в проекте ее создания, а также эффективно для дисплеев и презентаций. Впоследствии на основе построенной модели могут быть организованы новые проекты, направленные на создание модельных изменений.
Одной из известных методик используемый на концептуальном уровне является методология IDF0. Методология IDEF0 является следующим этапом в разработке графического языка для описания функциональных систем SADT (Structured Analysis and Design Technique). [7]
Цель функциональной методики описания бизнес-процессов предприятия на концептуальном уровне является необходимость - построить функциональную диаграмму исследуемой системы, описывая все необходимые процессы с достаточной точностью, чтобы однозначно моделировать работу системы.
Методология основана на четырех основных понятиях: функциональный блок, дуга интерфейса, декомпозиция, глоссарий.
Функциональный блок описания процессов предприятия (Activity Box) является специфической функцией в рамках рассматриваемой системы. Название каждого функционального блока, описывающего процессы предприятий, должно быть глаголом (например, «производить услуги»). На диаграмме функциональный блок представлен прямоугольником (Рисунок 15). Каждая из четырех сторон функционального блока имеет свое специфическое значение (роль), в то время
Рисунок 15 – Функциональный блок
• верхняя стрелка, это информация, отвечающая за "Управление" (Control) [6];
• левая стрелка, это информация, отвечающая за - "Вход" (Input);
• правая стрелка, это информация, отвечающая за - "Выход" (Output);
• нижняя стрелка, это информация, отвечающая за, - "Механизм" (Mechanism).
Интерфейсная дуга (Arrow) отображает элемент системы. Интерфейсные дуги часто называют потоками или стрелками. Интерфейсными дугами могут быть элементы реального мира или потоки данных и информации.
В зависимости от того, к какой из сторон функционального блока подходит интерфейсная дуга, может быть[5]:
- "входящей",
- "исходящей",
- "управляющей".
Разложение одного функционального блока на составляющие является основой концепции стандарта IDEF0. Принцип декомпозиции применяется, когда сложный процесс делится на его компоненты.
На рынке существуют множество программных продуктов, которые помогают построить бизнес-процессы, такие программы относят к CASE-средствам проектирования и разработки. CASE-технология - это совокупность методов, нотаций и инструментов, которые позволяют визуализировать модели в проблемной области, проанализировать модель системы на всех этапах разработки и сопровождения системы и разрабатывать приложения в соответствии с информационными потребностями пользователей.[
Основная цель использования CASE-технологий заключается в максимизации автоматизации этапов анализа и проектирования системы для того, чтобы построить формальную и последовательную модель системы (Рисунок 16).
Рисунок 16 – Современные CASE-средства
К популярным CASE-средствам относят :
- BPwin,
- Rational Rose
- MS Visio [24].
BPwin представляет собой программный продукт, разработанный компанией ltd. Logic Works. Он предназначен для поддержки создания информационных систем. Она относится к категории CASE-инструменты верхнего уровня. BPwin в его первой версии был выпущен в 1995 году в сочетании с другим инструментом CASE - ERwin, предназначенный для моделирования данных. (Рисунок 17)
Рисунок 17 -– Логотип BPwin
BPwin поддерживает функциональное моделирование, моделирование бизнес процессов и потоков данных. Соответствующие схемы реализованы на основе стандарта IDEF0, IDEF3 и DFD.
Microsoft Visio — векторный графический редактор, редактор диаграмм и блок-схем для Windows. Выпускается в трёх редакциях: Standard, Professional и Pro for Office 365 (Рисунок 18).
Рисунок 18 - Логотип Microsoft Visio
Visio предоставляет множество различных объектов, с которыми можно взаимодействовать.
В курсовой работе разработку моделей будем проводить в программе BPwin, так как данная программа установлена на компьютере и имеется бесплатная пробная версия для работы.
1.3. Моделирование бизнес-процессов «как есть»
Бизнес-процесс представляет собой систему последовательных, целенаправленных и регламентированных видов деятельности, в которой посредством управляющего воздействия и с помощью ресурсов входы процесса преобразуются в выходы, результаты процесса, представляющие ценность для потребителей. Бизнес–процессы делят на основные, производящие основные выходы, получаемые партнерами компании, и вспомогательные, выход которых используется другими подразделениями компании.
Концептуальное проектирование начинают с диаграммы верхнего уровня, где рассматривается связь склада со внешней средой (Рисунок 19)
Рисунок 19 – Оргтехника, модель 0 уровня
Входной информацией служат:
-
- Товар на склад.
- 1-Т Товарно-транспортная накладная.
Выходной информацией является:
-
- М-15. Накладная на отпуск материалов на сторону
- ТОРГ-12. Товарная накладная
- Товар со склада;
Управляющей информацией являются требования бухгалтерской отчетности и внутренние документы организации.
Механизмами являются люди, которые осуществляют все операции формирования отчетности и осуществляют деятельность на складе согласно своим обязанностям:
-
- Директор
- Бухгалтер
- Кладовщик
Основными операциями на складе оргтехники являются (Рисунок 20):
- Прием товара
- Хранение товара
- Перемещение товаров на складе
- Отпуск товара со склада
Рисунок 20 – Основные операции регламента выполнения процесса «Складской учет». Как есть
- Сдача документов
Рассмотрим операции более подробно (Таблица 1)
Таблица 1 – Бизнес-процесс «Складской учет». «Как есть»
|
Название операции |
Вход |
Выход |
Управление |
Механизм |
|
Прием товара |
1-Т (ТТН) Товар на склад |
М-4. Приходной складской ордер, ТОРГ-1. Акт о приемке товара ТОРГ-2. Акт об установление расхождения |
Требование бухгалтерской отчетности |
Кладовщик |
|
Хранение товара |
М-4. Приходной складской ордер |
ТОРГ-11. Товарный ярлык, М-17. Карточка учета материала |
Требование бухгалтерской отчетности |
Кладовщик |
|
Перемещение товаров на складе |
ТОРГ-11. Товарный ярлык |
ТОРГ-13. Накладная на внутренние перемещение |
Требование бухгалтерской отчетности |
Кладовщик |
|
Сдача документов |
ТОРГ-13. Накладная на внутренние перемещение, М-17. Карточка учета материала, ТОРГ-1. Акт о приемке товара ТОРГ-2. Акт об установление расхождения, ТОРГ-16. Акт о списании товара |
М-11. Требование накладная, |
Требование бухгалтерской отчетности, Внутренние документы организации |
Кладовщик Директор Бухгалтер |
|
Отпуск товара со склада |
М-11. Требование накладная, |
ТОРГ-12. Товарная накладная, Товар со склада, М-15. Накладная на отпуск товара на сторону, ТОРГ-16. Акт о списании товара |
Требование бухгалтерской отчетности |
Кладовщик |
Рассмотрим более подробно операцию Прием товара (Рисунок 21)
Рисунок 21 – Операция «Прием товара»
Основными операциями являются:
- Оформить товар на склад,
- Написать акт расхождения,
- Оформить документы в бухгалтерию.