Файл: Разработка регламента выполнения процесса «Управление документооборотом» ( ООО «ИМПЕРИЯ»).pdf
Добавлен: 04.04.2023
Просмотров: 319
Скачиваний: 1
СОДЕРЖАНИЕ
1. Изучение текущей организации бизнес-процесса «Управление документооборотом»
1.1 Описание предметной области: постановка задачи
1.2 Выбор средств для моделирования бизнес-процесса «Управление документооборотом»
1.3 Необходимость регламентации бизнес-процессов
1.4 Описание и регламентация бизнес-процессов
1.5 Разработка регламентов бизнес-процессов
2. Рекомендации по разработке регламента бизнес-процесса «Управление делопроизводством»
2.1 Описание регламента бизнес-процесса «Управление делопроизводством» ООО «ИМПЕРИЯ»
Моделирование бизнес-процессов является одним из методов улучшения качества и эффективности работы организации. В основе этого метода лежит описание процесса через различные элементы (действия, данные, события, материалы и пр.) присущие процессу. Как правило, моделирование бизнес процессов описывает логическую взаимосвязь всех элементов процесса от его начала до завершения в рамках организации. В более сложных ситуациях моделирование может включать в себя внешние по отношению к организации процессы или системы.
Моделирование бизнес процессов позволяет понять работу и провести анализ организации.
Моделирование бизнес процессов основывается на ряде принципов, которые дают возможность создать адекватные модели процессов. Их соблюдение позволяет описать множество параметров состояния процессов таким образом, чтобы внутри одной модели компоненты были тесно взаимосвязаны, в то время как отдельные модели оставались в достаточной степени независимыми друг от друга.
Важным элементом модели бизнес-процессов являются бизнес-правила или правила предметной области. Типичными бизнес-правилами являются корпоративная политика и государственные законы. Бизнес-правила обычно формулируются в специальном документе и могут отражаться в моделях.
На рисунке1 представлены основные этапы моделирования.
Рис.1. Этапы моделирования бизнес-процессов
На первом шаге описываются бизнес - направления, которые реализует предприятие. На втором шаге описываются работы, функции и бизнес-процессы, которые выполняются в компании для того, чтобы реализовывать бизнес - направления (применяется вертикальное и горизонтальное описание). На третьем — описывается организационная структура компании, и на четвертом — распределение ответственности структурных звеньев за работы, функции и бизнес-процессы [2, с.13].
Виды и принципы моделирования Моделирование бизнес процессов может иметь различную направленность. Это зависит от того, какие проблемы предполагается решить с его помощью. Учет абсолютно всех воздействий на процесс может значительно усложнить модель и привести к избыточности описания процесса. Чтобы этого избежать, моделирование бизнес процессов разделяют по видам. Вид моделирования выбирается в зависимости от исследуемых характеристик процесса.
Наиболее часто, для целей совершенствования процесса применяют следующие виды моделирования:
▪ Функциональное моделирование - подразумевает описание процессов в виде взаимосвязанных, четко структурированных функций. При этом строгая временная последовательность функций, в том виде, как она существует в реальных процессах, не обязательна.
▪ Объектное моделирование - подразумевает описание процессов, как набора взаимодействующих объектов – т.е. производственных единиц. Объектом является какой-либо предмет, преобразуемый в ходе выполнения процессов.
▪ Имитационное моделирование – при таком виде моделирования бизнес-процессов подразумевается моделирование поведения процессов в различных внешних и внутренних условиях с анализом динамических характеристик процессов и с анализом распределения ресурсов.
Главными принципами моделирования бизнес процессов являются следующие:
- Принцип декомпозиции – каждый процесс может быть представлен набором иерархически выстроенных элементов. В соответствии с этим принципом процесс необходимо детализировать на составляющие элементы.
- Принцип сфокусированности – для разработки модели необходимо абстрагироваться от множества параметров процесса и сфокусироваться на ключевых аспектах. Для каждой модели эти аспекты могут быть свои.
- Принцип документирования – элементы, входящие в процесс, должны быть формализованы и зафиксированы в модели. Для различных элементов процесса необходимо использовать различающиеся обозначения. Фиксация элементов в модели зависит от вида моделирования и выбранных методов.
- Принцип непротиворечивости – все элементы, входящие в модель процесса должны иметь однозначное толкование и не противоречить друг другу.
- Принцип полноты и достаточности – прежде чем включать в модель тот или иной элемент, необходимо оценить его влияние на процесс. Если элемент не существенный для выполнения процесса, то его включение в модель не целесообразно, т.к. он может только усложнить модель бизнес-процесса.
Модель бизнес-процесса традиционно является основной составляющей управления бизнес-процессами. Поскольку объектом процессного управления является бизнес-процесс, для возможности его распознавания, сравнения, анализа и управления необходимо разделить на множество признаков, характеризующие каждое свойство либо способность процесса. Моделирование - это описание бизнес-процесса в заранее оговоренных терминах, по правилам, называемыми нотациями. Модель бизнес-процесса может быть, как текстовой, графической или информационной.
Моделирование позволяет обмениваться информацией об объекте моделирования без риска потерять или исказить информацию о его внутренних свойствах. Модель бизнес-процесса позволяет сконцентрироваться на целевой и значимой информации о взаимосвязях всех объектов процесса. За счет этого по модели процесса проще понять его ход чем по, например, его словесному описанию.
Под методологией (нотацией) создания модели (описания) бизнес-процесса понимается совокупность способов, при помощи которых объекты реального мира (например, деятельность организации) и связи между ними представляются в виде модели. Рассмотрим самые известные из них .
Нотация IDEF0 (Integration Definitionfor Function Modeling) используется для создания верхнего уровня модели бизнес-процессов и отображает схему выполнения процесса в общем виде. Для IDEF0 имеет значение сторона процесса и связанная с ней стрелка (Рис.3):
• слева входящая стрелка – вход бизнес-процесса – информация (документ) или ТМЦ, который будет преобразован в ходе выполнения процесса;
• справа исходящая стрелка – выход бизнес-процесса – преобразованная информация (документ) или ТМЦ;
• сверху входящая стрелка – управление бизнес-процесса – информация или документ, который определяет, как должен выполняться бизнес-процесс;
• снизу входящая стрелка – механизм бизнес-процесса – то, что преобразовывает вход в выход: сотрудники или техника. Считается, что за один цикл процесса не происходит изменения механизма.
Рисунок 3 – Пример диаграммы IDEF0
Описание выглядит как «чёрный ящик» с входами, выходами, управлением и механизмом, который постепенно детализируется до необходимого уровня. Также для того чтобы быть правильно понятым, существуют словари описания активностей и стрелок. В этих словарях можно дать описания того, какой смысл вы вкладываете в данную активность либо стрелку
Достоинства. IDEF0 – показывает взаимодействие процессов в общем виде, без лишних подробностей.
Недостатки. В IDEF0 выглядят одинаково ресурсные потоки и потоки событий (инцидентов, проблем), роли и средства ТБПИ могут быть представлены в виде механизмов. IDEF0 плохо ориентирована на описание архитектуры программного обеспечения. Нельзя увидеть алгоритма выполнения бизнес-процессов. Требует определенной подготовки для разработки и чтения нотации.
Нотация IDEF3. Стандарт IDEF3 предназначен для описания бизнес-процессов нижнего уровня и содержит объекты – логические операторы, с помощью которых показывают альтернативы и места принятия решений и в бизнес-процессе, а также объекты – стрелки с помощью которых показывают временную последовательность работ в бизнес-процессе.
Сценарием (Scenario) мы называем описание последовательности изменений свойств объекта, в рамках рассматриваемого процесса (например, описание последовательности этапов обработки детали в цеху и изменение её свойств после прохождения каждого этапа). Исполнение каждого сценария сопровождается соответствующим документооборотом, который состоит из двух основных потоков: документов, определяющих структуру и последовательность процесса (технологических указаний, описаний стандартов и т.д.), и документов, отображающих ход его выполнения (результатов тестов и экспертиз, отчетов о браке, и т.д.). Для эффективного управления любым процессом, необходимо иметь детальное представление об его сценарии и структуре сопутствующего документооборота.
Существуют два типа диаграмм в стандарте IDEF3, представляющие описание одного и того же сценария технологического процесса в разных ракурсах. Диаграммы относящиеся к первому типу называются диаграммами Описания Последовательности Этапов Процесса, представленная на рисунке 4 Этапов Процесса представлена на рисунке 4 (Process Flow Description Diagrams, PFDD), а ко второму - диаграммами Состояния Объекта в и его Трансформаций Процессе (Object State Transition Network, OSTN). Предположим, требуется описать процесс окраски детали в производственном цеху на предприятии. С помощью диаграмм PFDD документируется последовательность и описание стадий обработки детали в рамках исследуемого технологического процесса. Диаграммы OSTN используются для иллюстрации трансформаций детали, которые происходят на каждой стадии обработки.
Рис. 4 Пример диаграммыIDEF3 (PFDD)
На рис.4 изображена диаграмма PFDD, являющаяся графическим отображение сценария обработки детали. Прямоугольники на диаграмме PFDD называются функциональными элементами или элементами поведения (UnitofBehavior, UOB) и обозначают событие, стадию процесса или принятие решения. Каждый UOB имеет свое имя, отображаемое в глагольном наклонении и уникальный номер. Стрелки или линии являются отображением перемещения детали между UOB-блоками в ходе процесса. Линии бывают следующих видов:
- Старшая (Precedence) - сплошная линия, связывающая UOB. Рисуется слева направо или сверху вниз.
- Отношения (RelationalLink)- пунктирная линия, использующаяся для изображения связей между UOB
- Потоки объектов (ObjectFlow)- стрелка с двумя наконечниками используется для описания того факта, что объект (деталь) используется в двух или более единицах работы, например, когда объект порождается в одной работе и используется в другой.
Объект, обозначенный J1 - называется перекрестком (Junction). Перекрестки используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-inJunction) и разветвления (Fan-outJunction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления. При внесении перекрестка в диаграмму необходимо указать тип перекрестка.
Другой класс диаграмм IDEF3 OSTN позволяет рассматривать тот же самый процесс "С точки зрения объекта". На рис.5 представлено отображение процесса окраски с точки зрения OSTN диаграммы. Состояния объекта (в нашем случае детали) и Изменение состояния являются ключевыми понятиями OSTN диаграммы. Состояния объекта отображаются окружностями, а их изменения направленными линиями. Каждая линия имеет ссылку на соответствующий функциональный блок UOB, в результате которого произошло отображаемое ей изменение состояния объекта.
Рис.5 Пример OSTN диаграммы
Достоинства:
1. Идентификация скрытых (неясных) связей процессов между организациями.
2. Выделение избыточных и/или не обеспечивающих "добавленную стоимость" работ.
3. Быстрое проектирование новых процессов.
Недостатки:
Нотация EPC
Event-Driven Process Chain – событийная цепочка процессов. Используется для описания процессов нижнего уровня. Диаграмма процесса в нотации EPC, представляет собой упорядоченную комбинацию событий и функций.
Пример диаграммы представлен на рисунке 6.
Рис.6 Пример EPC-диаграммы
EPC-диаграммы используют символы нескольких видов, чтобы показать структуру потока управления (последовательность решений, функции, события и другие элементы) бизнес-процесса.
Элементы событийных цепочек процессов:
-События являются пассивными элементами в EPC. Событием является состояние, которое встречается перед или после функции, то есть фиксирует состояние определённых параметров на определенный момент времени. Примеры событий: «договор подписан», «требование зафиксировано», «материал на складе». В EPC график событий представлен в виде шестиугольника. EPC-диаграммы должны как начаться с события, так и заканчиваются событием.
-Функции являются активными элементами в EPC. Работа — определенное действие, выполняемое в течение некоторого промежутка времени. Каждая работа может быть декомпозирована.