Файл: Разработка регламента выполнения процесса «Управление документооборотом» ..pdf
Добавлен: 14.03.2024
Просмотров: 33
Скачиваний: 0
IDEF3 - это метод моделирования процессов.
IDEF4 - это метод объектно-ориентированного анализа и проектирования.
IDEF5 - это метод построения онтологий.
IDEF6 - Логическое обоснование дизайна
IDEF7 - Аудит информационной системы
IDEF8 - Моделирование пользовательского интерфейса
IDEF9 - Обнаружение бизнес-ограничений
IDEF10 - Моделирование архитектуры реализации
IDEF11 - Моделирование информационных артефактов
IDEF12 - Организация моделирования
IDEF13 - дизайн схемы с тремя видами
IDEF14 - Сетевой дизайн
В 1995 году были разработаны полностью только IDEF0, IDEF1X, IDEF2, IDEF3 и IDEF4. Некоторые из других концепций IDEF имели некоторый предварительный дизайн. Методы IDEF7, IDEF10, IDEF11, IDEF 12 и IDEF13 не были разработаны дальше их первоначального определения.
Наиболее широко признанными и используемыми компонентами семейства IDEF являются IDEF0, язык моделирования функционального моделирования, основанный на SADT и IDEF1X, в котором рассматриваются информационные модели и проблемы проектирования баз данных
Метод функционального моделирования IDEF0 предназначен для моделирования решений и действий организации или системы. Он создан на базе языка моделирования структурированного анализа и проектирования техники (SADT), разработанного Дуглас Т. Росс и Softech. В своей первоначальной форме IDEF0 включает в себя как определение языка графического моделирования (синтаксис и семантика), так и описание комплексной методологии разработки моделей. IDEF0 должен помочь в организации системного анализа и обеспечении эффективной коммуникации между аналитиком и клиентом посредством упрощенных графических устройств
Кратко дадим описание IDEF1X. Чтобы удовлетворить требованиям повышения качества моделирования данных, которые были определены в проекте IISS-6202, субподрядчик DACOM получил лицензию на технологию логической разработки базы данных (LDDT) и ее вспомогательное программное обеспечение (ADAM). LDDT был разработан в 1982 году Робертом Г. Брауном из Группы проектирования баз данных полностью за пределами программы IDEF и без знания IDEF1. LDDT объединяет элементы реляционной модели данных, модели ER и обобщения способом, специально предназначенным для поддержки моделирования данных и преобразования моделей данных в проекты баз данных. Графический синтаксис LDDT отличался от графического кода IDEF1 и, что более важно, LDDT содержал взаимосвязанные концепции моделирования, отсутствующие в IDEF1. Мэри Э. Лумис написала краткий обзор синтаксиса и семантики значительного подмножества LDDT, используя терминологию, совместимую с IDEF1, где это возможно. DACOM обозначил результат IDEF1X и отправил его в программу ICAM. Проекты IISS фактически создали рабочие прототипы среды обработки информации, которые будут работать в гетерогенных вычислительных средах. Текущие достижения в таких методах, как Java и JDBC, теперь достигают целей повсеместности и универсальности в вычислительных средах, которые были впервые продемонстрированы IISS.
Опыт IDEF1 показал, что перевод требований к информации в проекты баз данных был более сложным, чем первоначально предполагалось. Самым полезным значением метода моделирования информации IDEF1 была его способность представлять данные независимо от того, как эти данные должны храниться и использоваться. Он предоставил модераторов данных и аналитиков данных способ представления требований к данным во время процесса сбора требований. Это позволило разработчикам решить, какую СУБД использовать после понимания требований к данным, и таким образом уменьшить «несоответствие» между требованиями к данным и возможностями и ограничениями СУБД. Однако перевод моделей IDEF1 на проекты баз данных оказался затруднительным.
Не смотря на то, что с момента создания методологии IDEF прошло более двадцати лет, эта методология используется и сейчас. Методология может применяться и к архитектуре предприятия (см. работы [2-6, 9]).
1.2. Этапы разработки регламента процесса
Регламент в бизнес - организации - это организационный и административный документ, описывающий определенный бизнес-процесс шаг за шагом до момента его завершения [4].
Правила регламента строго индивидуальны и могут действовать только в организации, которая их одобрила. Поэтому при составлении инструкций по служебной работе обычно используется ГОСТ Р 6.30-2003. "Унифицированные системы документации. Единая система организационной и административной документации. Требования к оформлению документов " и рекомендации по реализации ГОСТ Р 6.30-2003 *. На основе этих документов внутренние инструкции создаются как в небольшом магазине, так и в компании на федеральном уровне. Но, например, порядок внутренних документов, установленный в одной организации, может быть непригоден для другой.
Как правило, регламент состоит из следующих основных разделов:
1. Общие положения.
2. Термины, определения, сокращения.
3. Описание процесса.
4. Ответственность.
5. Контроль.
В качестве приложения к правилам может быть модель бизнес-процесса. Обычно это графически, но также допустимо скомпилировать таблицу и даже описать процесс устно. Графические модели бизнес-процессов создаются с использованием специального программного обеспечения.
Разработка регламента
Работа над регламентом ничем не отличается от работы над любым другим организационным и административным документом: сначала готовится проект документа, который согласовывается с заинтересованными должностными лицами, затем одобряется руководителем организации или уполномоченным ею лицом. Наконец, участники процесса знакомятся с правилами рисования и получают копии на руках.
Более подробную информацию о разделах регламента
1. Общие положения
Предмет регламента (процедура определяется настоящим Регламентом ...);
сфера охвата: объекты или работники организации, к которым относятся правила;
нормативные документы, на основе которых разрабатываются нормативные акты (если таковые имеются);
Процедура утверждения, изменения и отмены правил.
2. Термины, определения, сокращения
Определение терминов и разъяснение сокращений, используемых в тексте правил процедуры.
Термины перечислены в алфавитном порядке. Каждый из них написан из новой строки в единственном числе, и его определение обозначается дефисом без слова "это". В качестве источника определений желательно использовать законодательство, государственные нормы и другие нормативные документы.
3. Описание процесса
Пошаговое описание процесса. Для вашего удобства этот раздел разделен на подэлементы, каждый из которых соответствует следующему этапу процесса. В разделе указаны сотрудники, участвующие в исполнении, описаны действия и результат.
4. Ответственность
Ответственность участников процесса за нарушение правил (дисциплинарный, административный, уголовный). Последнее касается обычно сложных производственных процессов, связанных с риском для здоровья и жизни работников.
5. Контроль
Полное имя должностного лица, ответственного за мониторинг выполнения правил, а также, при необходимости, проверок.
Основные детали документа включают:
- название организации;
- Дата и номер документа, место его разработки;
- печать одобрения;
- имя документа;
- текст документа;
- запрос (если таковой имеется);
- утверждение визы.
ГЛАВА 2. РАЗРАБОТКА РЕГЛАМЕНТА ПРОЦЕССА «УПРАВЛЕНИЕ ДОКУМЕНТООБОРОТОМ»
2.1. Общие положения.
Настоящий регламент определяет порядок движения и обработки документов внутри организации
Область применения: регламент предназначен для работников организации, принимающих непосредственное участие в бизнес - процессе
Данный регламент разработан на основе ГОСТ Р 6.30-2003 «Унифицированные системы документации. Унифицированная система организационно - распорядительной документации. Требования к оформлению документов»
Порядок утверждения, внесения изменений и отмены регламента
Данный регламент вступает в силу сразу после утверждения руководителем организации
2.2. Термины, определения, сокращения
В Регламенте используются следующие термины и определения:
- Автор задачи – работник, направивший исполнителю электронное сообщение, содержащее задание.
- Документ – зафиксированная на носителе информация с реквизитами, позволяющими ее идентифицировать.
- Задание – поручение руководителя.
- Задача – см. задание.
- Исполнитель: сотрудник организации, отвечающий за выполнение этой задачи •
- Контроль: набор действий, обеспечивающих своевременное выполнение документа •
- Ответственный исполнитель: работник из числа исполнителей, который имеет право координировать работу других исполнителей • Разрешение перечислено сперва.
- Резолюция: требование, содержащее инструкции сотрудника об осуществлении документа • Включает имена, инициалы исполнителей, содержание инструкции (при необходимости), время выполнения, подпись и дату.
- Руководитель - чиновник, выдающий разрешение
- Крайний срок: дата календаря задачи. Крайний срок выполнения документа начинается с того дня, когда он регистрируется в офисе организации и рассчитывается в календарные дни. Документы подлежат исполнению на следующих типичных условиях:
- с определенной даты исполнения - в течение определенного периода, если документ поступил в организацию не позднее чем за три дня до истечения указанного периода;
- без указания конкретной даты исполнения и специальных заметок - в течение 30 дней;
- не указывая конкретную дату, помеченную "срочно" или "немедленно" - в течение трех дней;
- не указывая конкретную дату, помеченную "оперативно" - для 10 дней.
2.3. Описание процесса
Для моделирования использовались продукты компании Computer Associates .
Программы ERwin, BPwin и OOwin были разработаны компанией Logic Works [5-7] . Название BPwin сложилось из сокращения BP (англ. business process) и суффикса win, отражавшего ориентацию на графические операционные системы.
В 1998 году компания Logic Works была куплена фирмой Platinum Technology. Всего через год, в 1999 году, была куплена Computer Associates (CA).
Значительного успеха на рынке достигла версия программы BPwin 4.0, которая была выпущена в конце XX и модифицирована в начале XXI веков. В России этот пакет известен именно в этой версии. На основе этой программы написаны множество учебных пособий, и эта программа активно используется в учебном процессе.
В настоящее время поддержка этого продукта прекращена с 2002 года, и ее невозможно найти на официальном сайте компании. Далее расскажем дальнейшую историю этого программного продукта.
Последняя версия программного обеспечения получила название CA Bpwin Process Modeler 7.3 и вошла в объединённый пакет CA Bpwin Modeling Suite.
Программа поддерживает IDEF0, IDEF3 и DFD.
Моделирование бизнес-процессов (IDEF0) позволяет систематически анализировать бизнес, сосредоточение внимания на обычных повседневных функциях и средствах управления, которые поддерживают эти функции.
Моделирование потока процессов (IDEF3), также называемое моделированием рабочих процессов, используется для графического описания и документирования , собирая информацию о процессе, отношения между процессами и важными объектами, которые являются частью процесса. Можно использовать диаграммы рабочих процессов, чтобы помочь усилиям по реинжинирингу бизнес-процессов, разработать меры для определения полноты результатов и сбора информации о политике и процедуры в компании.
Моделирование потока данных (DFD) фокусируется на потоке данных между различными задачами. Это говорит о том, что организация может максимизировать доступность данных, а вы минимизируете время ответа.
В сегодняшнем сложном и постоянно меняющемся мире предприятия должны сосредоточиться на процессе о том, как они удовлетворяют потребности клиентов. Если вы находитесь в небольшой или большой организации, это процесс доставки товаров или услуг, который определяет качество и, в конечном итоге, успех бизнеса. Улучшение бизнес-процессов включает в себя картирование и моделирование бесчисленное множество взаимодействий внутри организации, чтобы лучше понять и улучшить ее операция. Вы можете провести реинжиниринг всей организации или отдельной части, например, приведение бизнес - требований в соответствие с существующими информационными технологиями.
Моделирование является одним из наиболее эффективных методов для понимания и общения бизнес - правил и процессов. В модели процесса посторонние детали устраняются, и важная информация выделяется, тем самым уменьшая очевидную сложность изучаемая система. Графика (а именно прямоугольники и стрелки) используются для обеспечения большей части структура, поэтому большинство людей думают о моделях процессов как о графических представлениях.
С помощью моделирования процессов вы можете взглянуть на систему, представляющую интерес, в глубине, так что тонкие нюансы вашей организации можно проанализировать, понять и, возможно, самое главное, общались с другими.