Файл: Разработка регламента выполнения процесса «Управление документооборотом» ..pdf

В 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) фокусируется на потоке данных между различными задачами. Это говорит о том, что организация может максимизировать доступность данных, а вы минимизируете время ответа.

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

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

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