Обзор существующих методологий моделирования и выбор наиболее подходящей
Обзор существующих методологий моделирования и выбор наиболее подходящей
Основные типы методологий
моделирования и анализа бизнес-процессов
- Моделирование бизнес-процессов (Business Process Modeling). Наиболее широко используемая методология описания бизнес-процессов - стандарт IDEF0. Модели в нотации IDEF0 предназначены для высокоуровневого описания бизнеса компании в функциональном аспекте.
- Описание потоков работ (Work Flow Modeling). Стандарт IDEF3 предназначен для описания рабочих процессов и близок к алгоритмическим методам построения блок-схем.
- Описание потоков данных (Data Flow Modeling). Нотация DFD (Data Flow Diagramming), позволяет отразить последовательность работ, выполняемых по ходу процесса, и потоки информации, циркулирующие между этими работами.
- Прочие методологии.
IDEF0
Модель состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы - главные компоненты модели, все функции и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса:
Тип интерфейса:
- Управляющая информация входит в блок сверху.
- Входная информация входит в блок слева.
- Результаты выходят из блока справа.
- Механизм (человек или автоматизированная система), который осуществляет операцию, входит в блок снизу.
Каждый компонент модели может быть декомпозирован (расшифрован более подробно) на другой диаграмме. Рекомендуется прекращать моделирование, когда уровень детализации модели удовлетворяет ее цель. Общее число уровней в модели не должно превышать 5-6.
Построение диаграмм начинается с представления всей системы в виде одного блока и дуг, изображающих интерфейсы с функциями вне системы. Затем блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. Каждая детальная диаграмма является декомпозицией блока из диаграммы предыдущего уровня. На каждом шаге декомпозиции диаграмма предыдущего уровня называется родительской для более детальной диаграммы.
На таких диаграммах не указаны явно ни последовательность, ни время. Метод обладает рядом недостатков: сложность восприятия (большое количество дуг на диаграммах и большое количество уровней декомпозиции), трудность увязки нескольких процессов.
IDEF3
Этот метод предназначен
для моделирования
Диаграммы IDEF3 отображают действие в виде прямоугольника. Действия именуются с использованием глаголов или отглагольных существительных, каждому из действий присваивается уникальный идентификационный номер (номер действия обычно предваряется номером его родителя, например, 1.1.). Все связи в IDEF3 являются однонаправленными и организуются слева направо.
Типы связей IDEF3:
- Временное предшествование (Temporal precedence), простая стрелка. Исходное действие должно завершиться, прежде чем конечное действие сможет начаться.
- Объектный поток (Object flow), стрелка с двойным наконечником. Выход исходного действия является входом конечного действия. Исходное действие должно завершиться, прежде чем конечное действие сможет начаться. Наименования потоковых связей должны чётко идентифицировать объект, который передается с их помощью.
- Нечеткое отношение (Relationship), пунктирная стрелка.
Завершение одного действия может инициировать начало выполнения сразу нескольких других действий, или наоборот, определенное действие может требовать завершения нескольких других действий до начала своего выполнения (ветвление процесса).
Ветвление процесса отражается с помощью специальных блоков:
- "И", блок со знаком &.
- "Исключающее ИЛИ" ("одно из"), блок со знаком Х.
- "ИЛИ", блок со знаком О.
Если действия "И", "ИЛИ" должны выполняться синхронно, это обозначается двумя двойными вертикальными линиями внутри блока, асинхронно - одной.
Метод IDEF3 позволяет декомпозировать действие несколько раз, что обеспечивает документирование альтернативных потоков процесса в одной модели.
DFD
Цель такого представления - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные. Может отражать не только информационные, но и материальные потоки.
Также, как и в других моделях, поддерживается декомпозиция.
Основными компонентами диаграмм потоков данных являются:
- Внешние сущности (материальный объект или физическое лицо, являющиеся источником или приёмником информации, например, заказчики, персонал, поставщики, клиенты, склад).
- Системы и подсистемы (например, подсистема по работе с физическими лицами).
- Процессы (преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом; физически это может быть, например, подразделение организации (отдел), выполняющее обработку входных документов и выпуск отчетов, программа, аппаратно реализованное логическое устройство и т.д.).
- Накопители данных (абстрактные устройства для хранения информации).
- Потоки данных (на диаграмме - стрелки).
Необходимо размещать на каждой диаграмме от 3 (меньше нет смысла) до 7 (больше - не воспринимаемо) процессов, не загромождая диаграммы несущественными на данном уровне деталями. Первым шагом при построении иерархии DFD является построение контекстных диаграмм. Обычно при проектировании относительно простых систем строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соединенный с приемниками и источниками информации. Для сложных систем (десять и более внешних сущностей, распределенная природа и многофункциональность системы) строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных.
Каждый процесс на DFD может быть детализирован при помощи DFD или (если процесс элементарный) спецификации. Спецификации представляют собой описания алгоритмов задач, выполняемых процессами. Языки спецификаций могут варьироваться от структурированного естественного языка или псевдокода до визуальных языков моделирования.
При моделировании бизнес-
ARIS
бизнес
процесс моделирование
В настоящее время наблюдается тенденция интеграции разнообразных методов моделирования, проявляющаяся в форме создания интегрированных средств моделирования. Одним из таких средств является программный продукт, носящий название ARIS (Architecture of Integrated Information Systems), разработанный германской фирмой IDS Scheer.
ARIS поддерживает четыре типа моделей (и множество видов моделей в каждом типе), отражающих различные аспекты исследуемой системы.
Поддерживаемые типы моделей в ARIS:
- Организационные модели, представляющие структуру системы - иерархию организационных подразделений, должностей и конкретных лиц, связи между ними, а также территориальную привязку структурных подразделений.
- Функциональные модели, содержащие иерархию целей, стоящих перед аппаратом управления, с совокупностью деревьев функций, необходимых для достижения поставленных целей.
- Информационные модели, отражающие структуру информации, необходимой для реализации всей совокупности функций системы.
- Модели управления, представляющие комплексный взгляд на реализацию бизнес-процессов в рамках системы.
Для построения перечисленных типов моделей используются как собственные методы моделирования ARIS, так и различные известные методы и языки моделирования, в частности, UML. Процесс моделирования можно начинать с любого из типов моделей.
Основная бизнес-модель ARIS - eEPC (extended Event-driven Process Chain, расширенная модель цепочки процессов, управляемых событиями). Нотация ARIS eEPC является расширением нотации IDEF3. Бизнес-процесс в нотации eEPC представляет собой поток последовательно выполняемых работ (процедур, функций), расположенных в порядке их выполнения. Реальная длительность выполнения процедур в eEPC визуально не отражается. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например, MS Project.
Модели в ARIS представляют собой диаграммы, элементами которых являются разнообразные объекты - "функции", "события", "структурные подразделения", "документы" и т.д. Между объектами определённых видов могут быть установлены связи определённых видов ("выполняет", "принимает решение", "должен быть проинформирован о результатах" и т.д.). Каждому объекту соответствует определенный набор атрибутов, которые позволяют ввести дополнительную информацию о конкретном объекте.
Основные объекты нотации eEPC:
- Функция. Служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия. Каждая функция должна быть инициирована событием и должна завершаться событием; в каждую функцию не может входить более одной стрелки, "запускающей" выполнение функции, и выходить более одной стрелки, описывающей завершение выполнения функции.
- Событие. Служит для описания реальных событий, воздействующих на выполнение функций.
- Организационная единица. Например, управление или отдел.
- Документ. Отражает реальные носители информации, например, бумажные документы.
- Прикладная система.
- Кластер информации. Характеризует набор сущностей и связей между ними.
- Связь между объектами. Тип отношений между объектами, например, активация выполнения функции некоторым событием.
- Логический оператор. Оператор "И", "ИЛИ" или исключающее "ИЛИ", позволяет описать ветвление процесса.
Если при создании модели в eEPC указывать только последовательность выполнения процедур, не заботясь об отражении управляющих документов и информации, полученные модели будут иметь низкую ценность с точки зрения анализа и дальнейшего использования.
Для хранения моделей в ARIS используется объектная СУБД, и под каждый проект создается новая база данных. Предусмотрены различные функции по администрированию базы данных, например, управление доступом. База данных представляет из себя иерархическое хранилище моделей.
Работа по созданию модели должна регламентироваться жёсткими и объёмными соглашениями по моделированию (стандартами), ARIS поддерживает механизм методологических фильтров, позволяющих пользователю использовать только определённый набор схем и объектов. Разработка таких соглашений требует значительного времени и высококвалифицированных специалистов. Если проект с использованием ARIS начинается без детальной проработки таких соглашений, то вероятность создания моделей бизнес-процессов, не отвечающих на поставленные вопросы, очень высока.
- ARIS Organizational Chart является одной из основных нотаций ARIS и предназначена для построения схем организационной структуры предприятия. Как правило, эта модель строится в начале проекта по моделированию бизнес-процессов. В модели отражаются существующие подразделения предприятия в виде иерархической структуры.[37]
Заложенные в нотацию типы связей позволяют отразить различные виды отношений между объектами организационной структуры. Кроме моделей иерархии подразделений, могут быть построены модели иерархии подчиненности в проектных командах, группах и т.д. Все отраженные в моделях объекты можно использовать в дальнейшем при формировании моделей бизнес-процессов. При построении сложных иерархических структур может быть применена декомпозиция.
В таблице 1.1 показаны основные объекты, используемые при построении организационной диаграммы и в таблице 1.2 отражены типы связей
Таблица 1.1
Таблица 1.2
Таблица 1.2(продолжение)
- ARIS Value-added chain diagram - Диаграмма цепочек добавленного качества описывает функции организации, которые непосредственно влияют на реальный выход ее продукции. Эти функции создают последовательность действий, формируя добавленные значения: стоимость, количество, качество и т.д.[38]
Рассматриваемая диаграмма может представлять связи между функциями, организационными единицами и преследуемыми целями.
В таблице 2 показаны объекты, используемые для диаграмм Value added chain diagram.
Таблица 2
№ |
Наименование |
Описание |
Графическое представление |
1. |
Value-added chain |
Объект, отражающий различные процессы. |
|
2 |
Organization unit |
Организационное подразделение; отображает какое-либо подразделение в компании. |
|
- ARIS Function Tree предназначена для формирования моделей дерева функций.[39]
Дерево функций (Function Tree) – представляет иерархическое декомпозицию функций на подфункции:
- Дерево функций отображает статическую декомпозицию функций.
- Основные объекты модели: функция, связь функций
- Существует несколько способов декомпозиции функций
- Функция характеризуется временем и стоимостью.
Типы декомпозиций функций:
- Процессно-ориентированная подчиненность (Is process-oriented superior) - выделение функций по принадлежности к одному процессу, то есть все выделенные функции являются этапами одного процесса. Критерием процессно–ориентированной детализации служат операции, которые выполняются над различными объектами в рамках бизнес-процесса.
- Объектно-ориентированная подчиненность (Is object-oriented superior)- выделение функций, выполняемых над одним объектом. Эти функции описывают различные операции, выполняемые над одним и тем же объектом.
- Операционно-ориентированная подчиненность (Is execution-oriented superior) - при операционно-ориентированном подходе функция верхнего уровня декомпозируется на подфункции, каждая из которых выполняет ту же операцию, но с различными объектами. Функции могут принадлежать различным процессам и привлекаться к обработке различных объектов. Однако выполняемый ими тип операции над отдельными объектами всегда один и тот же.
- ARIS eEPC расшифровывается следующим образом - Extended Event Driven Process Chain – расширенная нотация описания цепочки процесса, управляемого событиями.
В таблице 3 показаны основные объекты и связи функционального представления процесса.
Таблица 3
№ |
Наименование |
Описание |
Графическое представление |
1 |
Функция |
Объект «Функция» служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия. |
|
2 |
Событие |
Объект «Событие» служит для описания
реальных состояний системы, влияющих
и управляющих выполнением |
|
3 |
Организационная единица |
Объект, который отражает различные организационные звенья предприятий(например, управление или отдел) |
|
4 |
Документ |
Объект, который отражает реальные носители информации, например бумажные документы |
|
5 |
Прикладная система |
Объект который отражает реальную прикладную систему, используемую в рамках технологий выполнения функций |
|
6 |
Кластер информации |
Объект характеризующий данные, как набор сущностей и связей между ними. Используемый для создания моделей данных |
|
7 |
Стрелка связи между объектами |
Объект описывает тип |
|
8 |
Логическое «И» |
Логический оператор, который отражает связь между событиям и функцией в рамках процесса. Позволяющий описать ветвление процесса |
|
9 |
Логическое «ИЛИ» |
Логический оператор, который определяет связь между событиям и функцией в рамках процесса. Позволяющий описать ветвление процесса |
|
10 |
Логическое исключающее «ИЛИ» |
Логический оператор, который определяет связь между событиям и функцией в рамках процесса. Позволяющий описать ветвление процесса |
Помимо указанных в Таблице 4 основных объектов, при построении диаграмм eEPC могут использоваться многие другие объекты. Применяя множество различных объектов, связанных различными типами связей значительно увеличивает размер модели, затрудняя ее прочтение. Для понимания смысла нотации eEPC достаточно рассмотреть основные используемые типы объектов и связей. На следующем рисунке (Рис.1) представлена модель eEPC, которая описывает фрагмент бизнес-процесса предприятия.
Рис.1
На рисунке 1 видно, что связь между объектом имеет определенный смысл и отражает последовательность выполнения функций в пределах процесса. Стрелки, соединяющие Событие 1 и Функцию 1 «активируют» или инициируют выполнение Функции 1. Функция 1 «создает» Событие 2, за которым следует символ логического «И», «запускающий» выполнение Функций 2 и 3. Нотация eEPC построена на определенных семантических правилах описания:
- каждая функция должна быть инициирована событием и должна быть завершена событием;
- в каждую функцию не может входить более одной стрелки, «запускающей» выполнение функции, и выходить не более одной стрелки, которая описывает завершение выполняемой функции.
Кроме этих правил, существуют и другие важные правила формирования моделей в ARIS.
Таким образом, при помощи нотации eEPC ARIS можно описать бизнес-процесс в виде потоков последовательно выполняемых работ (процедур, функций), что является весьма удобным.
Об архивном деле
Главным документом, на котором строится организация архивного хранения документов является Федеральный закон от 22 октября 2004 г. № 125-ФЗ «Об архивном деле в Российской Федерации», а также новый типовой перечень, действующий с 2000 г. и получивший название «Перечень типовых управленческих документов, образующихся в деятельности организаций, с указанием сроков хранения».
Однако принятие в 2004 г. нового закона «Об архивном деле в Российской Федерации» обострило проблему, заложенную еще в Основах архивного законодательства 1994 г. Тогда, с учетом изменения государственного строя и появления частной собственности, были посеяны первые зерна размежевания архивных документов на государственные и негосударственные. Последствия такого решения еще долго будет чувствовать вся страна, так как в результате колоссальное количество документов (особенно по личному составу ликвидированных коммерческих организаций) уже утрачено и продолжает утрачиваться ежегодно.
Целью данной работы является анализ основных положений и краткая характеристика действующего федерального закона «Об архивном деле». Ее достижению способствует решение ряда задач:
- рассмотрение понятийного аппарата данного закона;
- анализ основных его структурных частей;
- определение сильных и слабых сторон, а также практической ценности закона.
Структура работы определяется структурой закона и логикой проведенного исследования.
Контроль за соблюдением законодательства об архивном деле в Российской Федерации и ответственность за его нарушение
Так как документы
Архивного фонда РФ, находящиеся
в частной собственности, могут
отчуждаться или переходить от одного
лица к другому в порядке
Если собственник особо ценных документов и охраняемых государством документов не выполняет свои обязанности по хранению, учету и использованию этих документов, что может привести к утрате ими своего значения, такие документы по решению суда могут быть изъяты у собственника в соответствии со ст.240 Гражданского кодекса РФ.
Также, в случае проведения торгов по продаже архивных документов, находящихся в частной собственности, организаторы торгов обязаны не позднее чем за 30 дней до дня их проведения проинформировать в письменной форме о месте, времени и об условиях продажи архивных документов специально уполномоченный Правительством РФ федеральный орган исполнительной власти и соответствующий уполномоченный орган исполнительной власти субъекта РФ в области архивного дела, на территории которого проводятся торги. Нарушение данного порядка продажи архивных документов может служить основанием для возникновения права требовать в судебном порядке в соответствии с гражданским законодательством перевода на них прав и обязанностей покупателя (ст.11, п.4).
Право собственности на архивные документы независимо от их форм собственности охраняется законом. Изъятие архивных документов, не предусмотренное федеральными законами, запрещается.
Архивные документы, находящиеся в незаконном владении, подлежат передаче собственникам или законным владельцам в соответствии с международным договором России и законодательством РФ.
Контроль за соблюдением законодательства об архивном деле в РФ осуществляют федеральные органы государственной власти, в т.ч.:
- специально уполномоченный Правительством РФ федеральный орган исполнительной власти;
- органы государственной власти субъектов РФ (в т.ч. уполномоченные органы исполнительной власти субъектов РФ в области архивного дела).
Ответственность за нарушение законодательства об архивном деле в Российской Федерации предполагает следующее: юридические лица, а также должностные лица и граждане, виновные в нарушении законодательства об архивном деле в Российской Федерации, несут гражданско-правовую, административную и уголовную ответственность, установленную законодательством РФ (ст.27).