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

Содержание:

ВВЕДЕНИЕ

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

Актуальность исследования. На сегодняшний день, в условиях конкурентной борьбы, каждое предприятие должно повышать свою эффективность. Для этого используется внедрение информационных технологий. Однако, для разработки информационной системы необходимо иметь модель предметной области. Для предприятия – это модель бизнес-процессов, основанная на процессном подходе. Одной из методологий моделирования является методология IDEF. Эта методология хорошо зарекомендовала себя за очень большой отрезок времени – более 20 лет. И хотя в настоящее время появились новые методологии, изучение классических подходов следует признать необходимым. Этим и обусловлена актуальность данной работы.

Целью курсовой работы является исследование теоретических и практических вопросов, связанных с применением методологии IDEF для разработки регламента бизнес-процесса.

Для реализации поставленной цели были определены следующие задачи:

• определить основные понятия процессного подхода;
• определить основные понятия методологии IDEF;
• определить, какие методы IDEF могут быть использованы для разработки регламента бизнес-процесса;
• выбрать инструменты, реализующие методологию IDEF;
• разработать регламент бизнес-процесса. «Управление документооборотом».

Предмет исследования – процессный подход

Объект исследования – разработка регламента.

Информационное обеспечение исследования: в курсовой работе использовались научные материалы, взятые из научных сборников и журналов, а также учебные и учебно-методические пособия, которые составили теоретическую основу работы.

Структура курсовой работы. Работа состоит из 2-х глав. В первой главе освящаются общие вопросы процессного подхода, во второй – методологические основы и практические приемы разработки регламента с использованием методологии IDEF.

ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ АСПЕКТЫ РАЗРАБОТКИ РЕГЛАМЕНТА БИЗНЕС-ПРОЦЕССОВ

1.1. Основные понятия процессного подхода

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

Основной концепцией, использующей подход к процессу, является концепция процесса [1-3]. Существует несколько определений, но наиболее часто используемым определением является ISO 9001. "Процесс-это набор взаимосвязанных и интерактивных действий, которые превращают входные данные в продукты". Важным компонентом этого процесса, который не отражен в этом определении, являются систематические действия. Действия процесса должны быть повторяющимися, а не случайными.

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

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

Вообще говоря, бизнес-процессы могут быть организованы в три типа, согласно фону Розингу и др.:

Операционные процессы, которые составляют основной бизнес и создают первичный поток создания ценности, например, принимая заказы от клиентов, открывая счет и производя компонент

Процессы управления, процессы, которые контролируют операционные процессы, включая корпоративное управление, бюджетный надзор и надзор за сотрудниками

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

Несколько иной подход к этим трем типам предлагает Кирхмер:

Операционные процессы, которые направлены на надлежащее выполнение оперативных задач объекта; здесь персонал "справляется"

Процессы управления, обеспечивающие надлежащее ведение операционных процессов; Здесь менеджеры «обеспечивают эффективные и действенные рабочие процессы»

Процессы управления, которые гарантируют, что предприятие работает в полном соответствии с необходимыми правовыми нормами, руководящими принципами и ожиданиями акционеров; Здесь руководители следят за соблюдением «правил и рекомендаций для успеха в бизнесе».

Сложный бизнес-процесс может быть разбит на несколько подпроцессов, которые имеют свои собственные атрибуты, но также способствуют достижению общей цели бизнеса. Анализ бизнес-процессов обычно включает в себя отображение или моделирование процессов и подпроцессов вплоть до уровня активности / задачи. Процессы могут быть смоделированы с помощью большого количества методов и приемов. Например, нотация моделирования бизнес-процессов - это метод моделирования бизнес-процессов , который можно использовать для рисования бизнес-процессов в визуализированном рабочем процессе. Хотя разложение процессов на типы и категории процессов может быть полезным, необходимо соблюдать осторожность, так как это может привести к пересечению. В конце концов, все процессы являются частью в значительной степени унифицированного результата, одного из «создания потребительской ценности». Эта цель достигается с помощью управления бизнес-процессами, целью которого является анализ, улучшение и внедрение бизнес-процессов.

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

Бизнес-процессы предназначены для управления одним или несколькими бизнес - функциональными подразделениями и подчеркивают важность « цепочки процессов », а не отдельных подразделений.

В общем, различные задачи бизнес-процесса могут быть выполнены одним из двух способов:

• вручную
• с помощью систем обработки бизнес- данных, таких как системы ERP

Как правило, некоторые задачи процесса выполняются вручную, а некоторые - на компьютере, и эти задачи можно упорядочить разными способами. Другими словами, данные и информация, которые обрабатываются в процессе, могут проходить через ручные или компьютерные задачи в любом заданном порядке.

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

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

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

Достижения в области информационных технологий за последние годы изменили бизнес-процессы внутри и между предприятиями. В 1960-х операционные системы имели ограниченную функциональность, и любые используемые системы управления рабочими процессами были специально разработаны для конкретной организации. В 1970–1980-х годах были разработаны подходы, основанные на данных, по мере совершенствования технологий хранения и поиска данных. Моделирование данных, а не моделирование процессов было отправной точкой для построения информационной системы. Бизнес-процессы должны были адаптироваться к информационным технологиям, потому что моделированием процессов пренебрегали. Сдвиг в сторону процессно-ориентированного управления произошел в 1990-х годах. Появилось программное обеспечение для планирования ресурсов предприятия с такими компонентами управления рабочими процессами, как SAP, Baan, PeopleSoft , Oracle и JD Edwards , а также системы управления бизнес-процессами (BPMS).

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

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

1.2. Моделирование бизнес-процессов в стандарте IDEF

Подробные спецификации на стандарты IDEF можно найти на сайте http://www.idef.com [1,8].

С 1999 аббревиатуру IDEF обычно расшифровывают как Integration DEFinition. Языки IDEF были разработаны в рамках проекта ICAM ВВС США. Поскольку эти языки, с одной стороны, являются официальными американскими стандартами, а с другой стороны открытыми (т.е. могут быть свободно используемыми), они были в короткие сроки поддержаны инструментами CASE .

Приведем краткую характеристику разделов IDEF.

IDEF0 - это метод моделирования системных или бизнес-решений и действий, основан на методе структурированного анализа и проектирования.

IDEF1 - это метод для анализа и моделирования требований. Особое значение сегодня имеет IDEF1X, определение для моделирования данных.

IDEF2 - это метод разработки имитационных моделей и динамики системы карт.

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

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

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

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

Далее рассмотрим модель бизнес-процесса в IDEF0, IDEF3 и DFD методологии.

Функциональный аспект архитектуры в методологии IDEF может быть описан диаграммами IDEF0 [6]. В IDEF0 система представляется как совокупность функций, взаимодействующих между собой. Обычно функцию можно рассматривать как процесс с входами и выходами. Поэтому вместо названий функций можно использовать названия процессов.

IDEF0 или IDEFØ (определение интеграции для моделирования функций) - это метод, предназначенный для моделирования решений, действий и действий организации или системы. IDEFØ был получен из хорошо зарекомендовавшего себя графического языка, структурированного анализа и методики проектирования (SADT - аббревиатура от англ. Structured Analysis and Technique Technique ).

ВВС США поручили разработчикам SADT разработать метод моделирования для анализа и представления функциональной перспективы системы. Эффективные модели IDEFØ помогают организовать анализ системы и способствуют хорошей коммуникации между аналитиком и клиентом. IDEFØ полезен для определения объема анализа, особенно для функционального анализа. Как инструмент коммуникации, IDEFØ улучшает участие экспертов в предметной области и консенсуса в принятии решений с помощью упрощенных графических устройств. Как инструмент анализа, IDEFØ помогает моделисту определить, какие функции выполняются, что необходимо для выполнения этих функций, что текущая система делает хорошо или делает неправильно. Таким образом, модели IDEFØ часто создаются как одна из первых задач разработки системы.

Построение модели в IDEF0 начинается с контекстной диаграммы, после чего функции расщепляются на составляющие компоненты и для каждой вновь выделенной функции создается своя диаграмма. Контекстная диаграмма А-0 приведена на рис.1

Рисунок 1. Контекстная диаграмма

На контекстной диаграмме основной процесс – торговля товарами, - рассматривается как «черный ящик», который имеет входные и выходные потоки.

Report for Diagram: A-0, Документооборот

Activity Name: Документооборот

Link Name: Входящий документ

Link Name: Информация руководству

Link Name: Персонал

Link Name: Нормативные документы

Link Name: Руководитель

Link Name: Приказ

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

Рисунок 2. Декомпозиция контекстной диаграммы

Перечислим основные функции рис.2

• Activity Name: Зарегестрировать документ
• Activity Name: Назначить исполнителя
• Activity Name: Контролировать выполнения
• Link Name: Зарегестрированный документ
• Link Name: Документ в работе

Вход и выход:

• Link Name: Входящий документ
• Link Name: Информация руководству
• Link Name: Приказ

Исполнители:

• Link Name: Персонал
• Link Name: Руководитель

Управление:

• Link Name: Нормативные документы

Модель IDEF3 описывает переходы объектов. IDEF3 показывает причинно-следственные связи между ситуациями и событиями в понятной эксперту форме, используя структурный метод выражения знаний о том, как функционирует система, процесс или предприятие. На рис.3 приведена диаграмма для процесса издания приказа, которая предполагает подготовку проекта, согласование, подписание приказа.

Рисунок 3. Диаграмма IDEF3

Activity Name: Подготовить проект приказа

Activity Name: Корректировка

Activity Name: Анализ проекта приказа

Activity Name: Согласование

Activity Name: Подписание

Расшифруем обозначения, рис.4

Рисунок 4. Обозначения IDEF3

DFD - диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.

Обозначение DFD опирается на теорию графов, первоначально использовавшуюся в операционных исследованиях для моделирования рабочих процессов в организациях. DFD возникла из Диаграммы Деятельности, использованной в методологии SADT (Структурный анализ и дизайн) в конце 1970-х годов. Популяризаторы DFD включают Эдварда Юдона, Ларри Константина, Тома Демарко, Криса Гэйна и Триш Сарсон. [2]

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

DFD состоит из процессов, потоков, складов и терминаторов. Существует несколько способов просмотра этих компонентов DFD.

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

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

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

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

На рис.5 показана DFD диаграмма по обработке документов. В ходе работы, был проведен анализ потоков данных организации, и построена диаграмма DFD. В ходе исследования выяснилось, что клиент или внешние организации передает организации документы, которые зарегистрированы и зарегистрированы в журнале. После этого сотрудник организации прикрепляется к этим документам для этой работы (прилагается к подрядчику), после чего в журнал вносится запись о поступление документа, о дате, когда должна быть выполнена работа. Чтобы контролировать производительность работы, есть запись управления, в которой выполняется запись о доставке управления документами и информацией о нем. После завершения работы с документом дата устанавливается при завершении работы, после чего документ, в котором была выполнена работа, удаляется из элемента управления и отправляется в архив или клиенту внешней организации. При необходимости ведется статистика.

Рисунок 5. Диаграмма DFD для заключения договора

Процессы:

• Activity Name: Зарегестрировать документ
• Activity Name: Сделать запись о поставке на контроль
• Activity Name: Отследить ход выполнения
• Activity Name: Прикрепить исполнителя
• Activity Name: Вести статистику

Потоки информации:

• Link Name: Документ
• Link Name: Статистика
• Link Name: Запись в журнале
• Link Name: Запись о прикрепление
• Link Name: Информация о документе
• Link Name: Запись о поставке на контроль
• Link Name: Дата окончания контроля
• Link Name: Данные о документе
• Link Name: Данные о ходе выполнения

Хранилища:

Data Store Name: Журнал

Data Store Name: Журнал контроля

В заключение подведем итог исследования. Методология IDEF позволяет довольно наглядно отобразить функциональный аспект архитектуры предприятия и аспект представления данных. Методология DFD позволяет моделировать движение информации через систему. Возможности рассмотренного инструментария не ограничены только диаграммами IDEF0 и DFD. Можно строить и другие диаграммы, например IDEF3. Такая детализация на уровне архитектуры не рассматривается. Лучше всего подходит диаграммы IDEF0.

ЗАКЛЮЧЕНИЕ

Результатом исследования темы: «Разработка регламента выполнения процесса «Управление документооборотом», стали следующие выводы, а именно:

1. Были рассмотрены общие вопросы процессного подхода. Определены основные понятия, прежде всего «бизнес-процесс».

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

3. Выполнен анализ технических средств поддержки методологии IDEF. Установлено, что наиболее продвинутыми программными продуктами являются системы, созданные в конце 20-го века и в начале 21-го века. В наиболее полной мере возможности методологии реализованы в продукте компании Computer Associates в пакете AllFusion. Хотя в настоящее время эти продукты не поддерживаются, решено использовать именно их.

4. В качестве бизнес - процесса для исследования выбран «Учет документооборота». Это связано с тем, что данный бизнес - процесс есть практически на любом предприятии и в любой организации, т.к. присутствует движение документов.

5. Построена модель бизнес-процесса с использованием программ BpWin, которые поддерживают методологию IDEF1, IDEF3 и DFD. Сравнение трех методологий показало, что лучшим вариантом является методология IDEF0, и может быть рекомендована к практическому использованию

Таким образом, цель и задачи курсовой работы достигнуты.

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. Основы бизнес-анализа [Текст] : учеб. пособие / ред. В. И. Бариленко. - М. : Кнорус, 2014. - 270 с.
2. Винтова, Т. А. Основы функционального моделирования автоматизированной системы управления персоналом [Текст] / Т. А. Винтова, П. Е. Коваль // Менеджмент и бизнес-администрирование. - 2015. - N 3. - С. 171-175
3. Высочина, М. В. Моделирование управленческого процесса [Электронный ресурс] / М. В. Высочина, М. В. Шкиндер // Научный вестник : финансы, банки, инвестиции. - 2016. - N 4. - С. 159-164. – Режим доступа: http://science.cfuv.ru/nauchnye-zhurnaly-kfu
4. Карминский, А. М. Информационные системы в экономике [Электронный ресурс] : учеб. пособие: в 2 ч. Ч. 2. Практика использования / А. М. Карминский, Б. В. Черников. - М. : Финансы и статистика, 2006. - 239 с.
5. Маклаков, С. В.. Моделирование бизнес-процессов с BPwin 4.0[Текст]/ С. В Маклаков - Москва "ДИАЛОГМИФИ", 2002 - 250 с.
6. Мосягин, А. А. Проблема выбора CASE-средства управления бизнес-процессами [Текст] / А. А. Мосягин, А. Б. Мосягин // Менеджмент и бизнес-администрирование. - 2015. - N 3. - С. 137-143
7. Фролова, Л. В. Формирование бизнес-модели предприятия [Текст] : учебник / Л. В. Фролова, Е. С. Кравченко. - К. : ЦУЛ, 2012. - 380 с.