Реферат на тему моделирование бизнес процессов

Реферат: Моделирование бизнес-процессов

СОДЕРЖАНИЕ

Введение

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

2. Классификация бизнес-процессов

3. Стандарты моделирования бизнес-процессов

Заключение

Список используемых источников

ВВЕДЕНИЕ

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

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

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

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

1. МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ

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

Существует несколько подходов к определению понятия «моделирование бизнес-процессов»:

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

моделирование бизнес-процессов
— это эффективное средство поиска возможностей улучшения деятельности предприятия;

моделирование
бизнес-процессов
— это средство позволяющее предвидеть и минимизировать риски, возникающие на различных этапах реорганизации деятельности предприятия;

моделирование бизнес-процессов
— это метод, позволяющий дать стоимостную оценку каждому процессу, взятому в отдельности, и всем бизнес-процессам на предприятии, взятым в совокупности [1].

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

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

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

Решения по моделированию бизнес-процессов обычно принимается по причинам, представленным на рисунке 1.

Рисунок 1 — Причины, по которым принимается решение по моделированию бизнес-процессов

Моделирование бизнес-процессов затрагивает многие аспекты деятельности компании:

изменение организационной структуры;

оптимизацию функций подразделений и сотрудников;

перераспределение прав и обязанностей руководителей;

изменение внутренних нормативных документов и технологии проведения операций.

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

Моделирование бизнес-процессов организации включает два этапа структурное и детальное.

Структурное
моделирование бизнес-процессов организации может выполняться в нотации IDEF0 с использованием инструментария BPwin или на языке UML с использованием инструментария Rational Rose. Детальное моделирование выполняется на языке UML.

На этапе структурного моделирования в модели должны быть отражены:

существующая организационная структура;

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

структуру бизнес-процессов, отражающую их иерархию от более общих групп к частным бизнес-процессам;

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

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

Детальная модель бизнес-процесса должна включать:

набор прецедентов отражающих возможные варианты выполнения бизнес-процессов «как есть»;

диаграммы действий, детально описывающие последовательность выполнения бизнес-процессов;

диаграммы взаимодействия, отражающие схемы документооборота.

Бизнес-операция
— совокупность действий, процедур, составляющих содержание одного акта бизнес-деятельности.

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

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

Бизнес-Модель —
это то, что делает компания и благодаря чему она зарабатывает деньги (Том Мэлоун)

Бизнес-стратегия
есть теория, бизнес-модель — гипотеза (Николас Карр)

Бизнес-модель
— это представление набора связанных модельных элементов, определяющих внутреннюю и внешнюю среду компании в рамках единой системы [2].

2. КЛАССИФИКАЦИЯ БИЗНЕС-ПРОЦЕССОВ

Выделяют следующую классификацию [5]:

В зависимости от места бизнес-процессов в организационной структуре компании выделяют следующие бизнес-процессы:

горизонтальные процессы – процессы, отражающие взаимодействие по горизонтали;

индивидуальные горизонтальные процессы – процессы, выполняемые отдельными работниками (организационными единицами);

межфункциональные горизонтальные процессы – процессы, выполняемые многими работниками (организационными единицами);

вертикальные процессы – процессы, отражающие взаимодействие работников (организационных единиц) по вертикали;

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

В зависимости от степени их сложности выделяют:

монопроцессы – односложные процессы;

вложенные процессы — монопроцессы, входящие в состав более сложного процесса (макропроцесса);

связанные процессы – выделенные и последовательно реализуемые по определенному алгоритму монопроцессы.

В зависимости от их предназначения:

основные бизнес-процессы – горизонтальные бизнес-процессы, обеспечивающие выполнение реальных операционных задач, связанных с созданием продукта и реализацию его клиенту; — это процессы, операции которых имеют прямое отношение к продукту предприятия и тем самым влияют на создание добавленной стоимости;

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

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

В зависимости от их места в иерархии целей организации:

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

бизнес-процессы среднего уровня – бизнес-процессы, направленные на реализацию тактических целей;

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

В зависимости от степени их детализации [4]:

макропроцессы – укрупненные бизнес-процессы имеющие степень детализации необходимую чтобы описать бизнес-процессы верхнего уровня;

субпроцессы – бизнес-процессы имеющие степень детализации необходимую для описания бизнес-процессов среднего уровня;

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

В рамках основных составляющих сбалансированной системы показателей:

финансовые бизнес-процессы;

клиентские бизнес-процессы;

бизнес – процессы производства;

бизнес-процессы развития, обучения и роста.

3. СТАНДАРТЫ МОДЕЛИРОВАНИЯ БИЗНЕС-ПРОЦЕССОВ

Стандарт функционального моделирования IDEF0

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

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

Модель
IDEF
0
представляет собой серию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые изображены в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других диаграммах. Каждая детальная диаграмма является декомпозицией блока из диаграммы предыдущего уровня. На каждом шаге декомпозиции диаграмма предыдущего уровня называется родительской для более детальной диаграммы. Общее число уровней в модели (включая контекстный) не должно превышать 5-6. Практика показывает, что этого вполне достаточно для построения полной функциональной модели современного предприятия любой отрасли [2].

Стандарт информационного моделирования IDEF1

Стандарт IDEF1 был разработан как инструмент для анализа и изучения взаимосвязей между информационными потоками в рамках коммерческой деятельности предприятия. Применение методологии IDEF1 как инструмента построения наглядной модели информационной структуры предприятия по принципу «как должно быть». Пример построения модели показан на рисунке 2.

Рисунок 2 – Пример построения модели IDEF1

Основными составляющими компонентами информационной модели являются:

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

словарь – значение каждого элемента модели описывается текстовым фрагментом.

Базовым понятием в методологии IDEF1 является понятие сущности. Сущность
определяется как реальный или абстрактный объект, набор отличительных свойств которого, называемых атрибутами, известен. Каждая сущность имеет имя и атрибуты [2].

Стандарт динамического моделирования IDEF2

IDEF2
— Simulation Model Design — методология динамического моделирования развития систем.

В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. В настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе «раскрашенных сетей Петри» (CPN — Color Petri Nets);

Стандарт моделирования процессов IDEF3
– IDEF14

Как и в методе IDEF0, основной единицей модели IDEF3 является диаграмма. Другой важный компонент модели — действие, или в терминах IDEF3 «единица работы». Диаграммы IDEF3 отображают действие в виде прямоугольника. Действия именуются с использованием глаголов или отглагольных существительных, каждому из действий присваивается уникальный идентификационный номер. Этот номер не используется вновь даже в том случае, если в процессе построения модели действие удаляется. В диаграммах IDEF3 номер действия обычно предваряется номером его родителя [2].

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

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

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

Соединение «или» предназначено для описания ситуаций, которые не могут быть описаны двумя предыдущими типами соединений. Аналогично связи нечеткого отношения соединение «или» в основном определяется и описывается непосредственно аналитиком. Соединение J2 может активизировать проверку данных чека и/или проверку суммы наличных. Проверка чека инициируется, если покупатель желает расплатиться чеком, проверка суммы наличных — при оплате наличными. И то, и другое действие инициируются при частичной оплате, как чеком, так и наличными [2].

IDEF4
– методология построения объектно-ориентированных систем. Средства IDEF4 позволяют наглядно отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы [2].

IDEF5
– методология исследования сложных систем.

Система ARIS представляет собой комплекс средств анализа и моделирования деятельности предприятия. Ее методическую основу составляет совокупность различных методов моделирования, отражающих разные взгляды на исследуемую систему. Одна и та же модель может разрабатываться с использованием нескольких методов, что позволяет использовать ARIS специалистам с различными теоретическими знаниями и настраивать его на работу с системами, имеющими свою специфику [2].

IDEF6
— Design Rationale Capture — Обоснование проектных действий. Назначение IDEF6 состоит в облегчении получения «знаний о способе» моделирования, их представления и использования при разработке систем управления предприятиями. Под «знаниями о способе» понимаются причины, обстоятельства, скрытые мотивы, которые обуславливают выбранные методы моделирования. Проще говоря, «знания о способе» интерпретируются как ответ на вопрос: «почему модель получилась такой, какой получилась?» Большинство методов моделирования фокусируются на собственно получаемых моделях, а не на процессе их создания. Метод IDEF6 акцентирует внимание именно на процессе создания модели [2].

IDEF
7
— Information System Auditing — Аудит информационных систем. Этот метод определён как востребованный, однако так и не был полностью разработан [2].

IDEF8
— User Interface Modeling — Метод разработки интерфейсов взаимодействия оператора и системы (пользовательских интерфейсов). Современные среды разработки пользовательских интерфейсов в большей степени создают внешний вид интерфейса. IDFE8 фокусирует внимание разработчиков интерфейса на программировании желаемого взаимного поведения интерфейса и пользователя на трех уровнях: выполняемой операции (что это за операция); сценарии взаимодействия, определяемом специфической ролью пользователя (по какому сценарию она должна выполняться тем или иным пользователем); и, наконец, на деталях интерфейса (какие элементы управления, предлагает интерфейс для выполнения операции) [2].

IDEF9
— Scenario-Driven IS Design (Business Constraint Discovery method) — Метод исследования бизнес ограничений был разработан для облегчения обнаружения и анализа ограничений в условиях которых действует предприятие. Обычно, при построении моделей описанию ограничений, оказывающих влияние на протекание процессов на предприятии уделяется недостаточное внимание. Знания об основных ограничениях и характере их влияния, закладываемые в модели, в лучшем случае остаются неполными, несогласованными, распределенными нерационально, но часто их вовсе нет. Это не обязательно приводит к тому, что построенные модели нежизнеспособны, просто их реализация столкнется с непредвиденными трудностями, в результате чего их потенциал будет не реализован. Тем не менее в случаях, когда речь идет именно о совершенствовании структур или адаптации к предсказываемым изменениям, знания о существующих ограничениях имеют критическое значение [2].

IDEF10
— Implementation Architecture Modeling — Моделирование архитектуры выполнения. Этот метод определён как востребованный, однако так и не был полностью разработан [2].

IDEF11
— Information Artifact Modeling. Этот метод определён как востребованный, однако так и не был полностью разработан [2].

IDEF12
— Organization Modeling — Организационное моделирование. Этот метод определён как востребованный, однако так и не был полностью разработан [2].

IDEF13
— Three Schema Mapping Design — Трёхсхемное проектирование преобразования данных. Этот метод определён как востребованный, однако так и не был полностью разработан [2].

IDEF14
— Network Design — Метод проектирования компьютерных сетей, основанный на анализе требований, специфических сетевых компонентов, существующих конфигураций сетей. Также он обеспечивает поддержку решений, связанных с рациональным управлением материальными ресурсами, что позволяет достичь существенной экономии [2].

Стандарт моделирования потоков данных

DFD

Диаграммы потоков данных DFD представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления — продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

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

Основными компонентами диаграмм потоков данных являются:

внешние сущности;

системы и подсистемы;

процессы;

накопители данных;

потоки данных.

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

Подсистема (или система) на контекстной диаграмме изображается так, как она представлена на рисунке 3.

Рисунок 3 – Подсистема по работе с физическими лицами (ГНИ — Государственная налоговая инспекция)

Номер подсистемы служит для ее идентификации. В поле имени вводится наименование подсистемы в виде предложения с подлежащим и соответствующими определениями и дополнениями.

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

Процесс на диаграмме потоков данных изображается, как показано на рисунке 4.

Рисунок 4 – Графическое изображение процесса

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

Информация в поле физической реализации показывает, какое подразделение организации, программа или аппаратное устройство выполняет данный процесс.

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

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

Накопитель данных идентифицируется буквой «D» и произвольным числом. Имя накопителя выбирается из соображения наибольшей информативности для проектировщика.

Накопитель данных в общем случае является прообразом будущей базы данных, и описание хранящихся в нем данных должно соответствовать модели данных.

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

Построение иерархии диаграмм потоков данных
.

Главная цель построения иерархии DFD заключается в том, чтобы сделать описание системы ясным и понятным на каждом уровне детализации, а также разбить его на части с точно определенными отношениями между ними [3].

ЗАКЛЮЧЕНИЕ

В последние годы интерес в России к методологиям семейства IDEF неуклонно растет. При этом интерес к таким стандартам, как IDEF3–5 является теоретическим, а к IDEF0 вполне практически обоснованным.

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Войнов И.В. Моделирование экономических систем и процессов. Опыт построения ARIS-моделей [Текст]: монография / И.В. Войнов – М.: ЮУрГУ, 2002. – 392 с.

2. Волков О.Н. Стандарты и методологии моделирования бизнес-процессов [Текст]: учеб. пособие для вузов / О.Н. Волков. – М.: АСВ, 2000. – 145 с.

3. Григорьев Д.И. Моделирование бизнес-процессов предприятия [Текст]: учеб. пособие / Д.И. Григорьев. – М.: ИРЦ, 2006. – 214 с.

4. Калянов Г.Н. Моделирование, анализ, реорганизация и автоматизация бизнес-процессов [Текст]: учеб. пособие / Г.Н. Калянов. – М.: Финансы и статистика, 2006. – 319 с.

5. Пинаев Д.К. Моделирование бизнес-процессов: доступно о сложном [Текст]: справ. пособие / Д.К. Пинаев. – М.: РГАС, 2003. – 247 с.

Похожие рефераты:

Билеты на государственный аттестационный экзамен по специальности Информационные Системы

Стандатризация программных средств

Корпоративные сети

Разработка концепции информационной системы для поддержки принятия управленческих решений в области маркетинга региона

Предмет и объект прикладной информатики

CASE-технологии

Информационные технологии, поддерживающие управление бизнес процессами

Автоматизация системы бюджетирования финансовой службы

Проектирование информационных систем с использованием ERWin, BPWin

Философия и методология науки

Техническая диагностика средств вычислительной техники

Использование информационных технологий в обучении информационному моделированию учащихся старших классов в рамках элективного курса информатики

Основы проектирования и конструирования

Развитие методологии системного подхода в отечественной педагогике

Построение систем распознавания образов

Исследования в современном управлении

Реинжиниринговый подход к управлению бизнес-процессами в организации

Экономическая деятельность и ее информационное обеспечение

Имитационное моделирование компьютерных сетей

17

ВВЕДЕНИЕ

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

В настоящее время широко используются CASE‑технологии (Computer Aided Software/System Engineering), предоставляющие ряд нотаций для разработки описательных моделей. Одними из самых популярных программных продуктов, обеспечивающих полный цикл анализа, проектирования и кодогенерации, являются автоматизированные инструменты серии Platinum technology (Logic Works): BPWin, ERWin, ModelMart, Paradigm Plus, RPTWin.

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

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

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

Применение универсальных графических языков бизнес-моделирования IDEF0, IDEF3 и DFD обеспечивает логическую целостность и полноту описания, необходимую для достижения точных и непротиворечивых результатов. Посредством набора графических инструментов для отображения действий и объектов, BPwin позволяет легко построить схему процесса, на которой показаны исходные данные, результаты операций, ресурсы, необходимые для их выполнения, управляющие воздействия, взаимные связи между отдельными работами. Интерактивное выделение объектов обеспечивает постоянную визуальную обратную связь при построении модели. BРwin поддерживает ссылочную целостность, не допуская определения некорректных связей и гарантируя непротиворечивость отношений между объектами при моделировании.

BPwin тесно интегрируется с рядом известных продуктов Computer Associates и других компаний. Среди этих продуктов:

· Широко известный инструмент моделирования данных ERwin (CA/Logic Works). Erwin не нуждается в рекомендациях. В версии BPwin 4.0 интерфейсы экспорта и импорта синхронизованы с Erwin 4.0. Кроме того, появилась возможность ассоциирования сущностей и атрибутов с хранилищами данных.

· Система управления и хранения проектов ModelMart (CA/Logic Works), которая предоставляет репозитарий для коллективной разработки моделей. ModelMart гарантирует согласованность моделей, разграничение доступа к ним, поддержку версий и много других средств, которые так важны при командной разработке моделей. Сервер приложений для программных продуктов CA ModelMart поддерживает мощный набор инструментальных программных средств, обеспечивающих совместное (групповое) проектирование и разработку программных систем, включая механизмы объединения моделей и анализа изменений, контроль версий, возможность создания «компонент» модели и т.д. Для организации хранилища моделей в ModelMart используются СУБД на платформах Oracle, Sybase, Informix или SQL Server. Кроме того, поддерживаются прямые связи ModelMart с ERwin и BPwin.

· Инструмент стоимостного анализа EasyABC (ABC Technologies).

· В BPwin 4.0 стал возможен экспорт модели в систему имитационного моделирования Arena (Systems Modeling Corp.).

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

ТЕОРЕТИЧЕСКАЯ ЧАСТЬ

1. Описание методологий семейства IDEF (ICAMDefenition)

1.1 Методология IDEF0

Графический язык IDEF0 удивительно прост и гармоничен. В основе методологии лежат четыре основных понятия:

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

Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом:

· Верхняя сторона имеет значение «Управление» (Control);

· Левая сторона имеет значение «Вход» (Input);

· Правая сторона имеет значение «Выход» (Output);

· Нижняя сторона имеет значение «Механизм» (Mechanism).

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

Рис. 1. Функциональный блок

Вторым важным понятием методологии IDEF0 является понятие интерфейсной дуги (Arrow). Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком.

Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.

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

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

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

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

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

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

Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором «А‑0».

В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).

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

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

В процессе декомпозиции, функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы и называется дочерней (Child diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком – Child Box). В свою очередь, функциональный блок – предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. Важно отметить, что в каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0 – модели. Наглядно принцип декомпозиции представлен на рисунке 2. Следует обратить внимание на взаимосвязь нумерации функциональных блоков и диаграмм – каждый блок имеет свой уникальный порядковый номер на диаграмме (цифра в правом нижнем углу прямоугольника), а обозначение под правым углом указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обозначения говорит о том, что декомпозиции для данного блока не существует.

Часто бывают случаи, когда отдельные интерфейсные дуги не имеет смысла продолжать рассматривать в дочерних диаграммах ниже какого-то определенного уровня в иерархии, или наоборот – отдельные дуги не имеют практического смысла выше какого-то уровня. С другой стороны, случается необходимость избавиться от отдельных «концептуальных» интерфейсных дуг и не детализировать их глубже некоторого уровня. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования. Обозначение «туннеля» (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из «туннеля») только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока – приёмника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии – в таком случае, они сначала «погружаются в туннель», а затем, при необходимости «возвращаются из туннеля».

Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0: диаграмм, функциональных блоков, интерфейсных дуг существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Например, для управляющей интерфейсной дуги «распоряжение об оплате» глоссарий может содержать перечень полей соответствующего дуге документа, необходимый набор виз и т.д. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.

Рис. 2. Декомпозиция функциональных блоков

Обычно IDEF0‑модели несут в себе сложную и концентрированную информацию, и для того, чтобы ограничить их перегруженность и сделать удобочитаемыми, в соответствующем стандарте приняты соответствующие ограничения сложности:

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

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

Разумеется, строго следовать этим ограничениям вовсе необязательно, однако, как показывает опыт, они являются весьма практичными в реальной работе.

1.2. Модели AS-IS и ТО-ВЕ

Обычно сначала строится модель существующей организации работы – AS-IS (как есть). На основе модели AS-IS достигается консенсус между различными единицами бизнеса по тому, «кто что сделал» и что каждая единица бизнеса добавляет в процесс. Модель AS-IS позволяет выяснить, «что мы делаем сегодня» перед тем, как перепрыгнуть на то, «что мы будем делать завтра». Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем буду г состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Признаками неэффективной деятельности могут быть бесполезные, неуправляемые и дублирующиеся работы, неэффективный документооборот (нужный документ не оказывается в нужном месте в нужное время), отсутствие обратных связей по управлению (на проведение работы не оказывает влияния ее результат), входу (объекты или информация используются нерационально) и т.д. Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) – модели новой организации бизнес-процессов. Модель нужна ТО-ВЕ для анализа альтернативных / лучших путей выполнения работы и документирования того, как компания будет делать бизнес в будущем.

Следует указать на распространенную ошибку при создании модели AS-IS – это создание идеализированной модели. Примером может служить создание модели на основе знаний руководителя, а не конкретного исполнителя работ. Руководитель знаком с тем, как предполагается выполнение работы по руководствам и должностным инструкциям и часто не знает, как на самом деле подчиненные выполняют рутинные работы. В результате получается приукрашенная, искаженная модель, которая несет ложную информацию и которую невозможно в дальнейшем использовать для анализа. Такая модель называется SHOULD_BE (как должно бы быть).

Технология проектирования ИС подразумевает сначала создание модели AS-IS, ее анализ и улучшение бизнес-процессов, т.е. создание модели ТО-ВЕ, и только на основе модели ТО-ВЕ строится модель данных, прототип и затем окончательный вариант ИС. Построение системы на основе модели AS-IS приводит к автоматизации предприятия по принципу «все оставить как есть, только чтобы компьютеры стояли», т.е. ИС автоматизирует несовершенные бизнес-процессы и дублирует, а не заменяет существующий документооборот. В результате внедрение и эксплуатация такой системы приводит лишь к дополнительным издержкам на закупку оборудования, создание программного обеспечения и сопровождение того и другого.

Иногда текущая AS-IS и будущая ТО-ВЕ модели различаются очень сильно, так что переход от начального к конечному состоянию становится неочевидным. В этом случае необходима третья модель, описывающая процесс перехода от начального к конечному состоянию системы, поскольку такой переход – это тоже бизнес-процесс.

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

1.3. Методология DFD (Data Flow Diagramming)

Диаграммы потоков данных (Dataflowdiagramming, DFD) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет модельную систему как сеть связанных между собой работ. Их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации. DFD описывает:

· функции обработки информации (работы);

· документы (стрелки, arrow), объекты, сотрудников или отделы,

которые участвуют в обработке информации;

· внешние ссылки (externalreferences), которые обеспечивают интерфейс с внешними объектами, находящимися за границами моделируемой системы;

· таблицы для хранения документов (хранилище данных, datastore).

В BPwin для построения диаграмм потоков данных используется нотация Гейна – Сарсона (рис. 3).

Рис. 3. Основные символы диаграммы потоков данных

Для того чтобы дополнить модель IDEF0 диаграммой DFD, нужно в процессе декомпозиции в диалоге Activity Box Count «кликнуть» по радио-кнопке DFD. В палитре инструментов на новой диаграмме DFD появляются новые кнопки:

· добавить в диаграмму внешнюю ссылку (External Reference). Внешняя ссылка является источником или приемником данных извне модели;

· добавить в диаграмму хранилище данных (Data store). Хранилище данных позволяет описать данные, которые необходимо сохранить в памяти прежде, чем использовать в работах;

· ссылка на другую страницу. В отличие от IDEF0 инструмент offpage reference позволяет направить стрелку на любую диаграмму (а не только на верхний уровень).

В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы – движение объектов (dataflow), хранение объектов (datastores), поставка и распространение объектов (externalentities).

В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, DFD рассматривает систему как совокупность предметов. Контекстная диаграмма часто включает работы и внешние ссылки. Работы обычно именуются по названию системы, например «Система обработки информации».Включение внешних ссылок в контекстную диаграмму не отменяет требования методологии четко определить цель, область и единую точку зрения на моделируемую систему.

Работы

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

Внешние сущности

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

Стрелки (Потоки данных)

Стрелки описывают движение объектов из одной части системы в другую. Поскольку в DFD каждая сторона работы не имеет четкого назначения, как в IDEF0, стрелки могут подходить и выходить из любой грани прямоугольника работы. В DFD также применяются двунаправленные стрелки для описания диалогов типа «команда-ответ» между работами, между работой и внешней сущностью и между внешними сущностями.

Хранилище данных

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

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

Построение диаграмм DFD

Диаграммы DFD могут быть построены с использованием традиционного структурного анализа, подобно тому, как строятся диаграммы IDEF0. Сначала строится физическая модель, отображающая текущее состояние дел. Затем эта модель преобразуется в логическую модель, которая отображает требования к существующей системе. После этого строится модель, отображающая требования к будущей системе. И наконец, строится физическая модель, на основе которой должна быть построена новая система.

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

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

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

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

Нумерация объектов

В DFD номер каждой работы может включать префикс, номер родительской работы (А) и номер объекта. Номер объекта – это уникальный номер работы на диаграмме. Например, работа может иметь номер А. 12.4. Уникальный номер имеют хранилища данных и внешние сущности независимо от их расположения на диаграмме. Каждое хранилище данных имеет префикс D и уникальный номер, например D5. Каждая внешняя сущность имеет префикс Е и уникальный номер, например Е5.

Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота. Однако для описания логики взаимодействия информационных потоков более подходит IDEF3, называемая также workflow diagramming – методологией моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. Диаграммы Workflow могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации.

1.4. Методология IDEF3

IDEF3 является стандартом документирования технологических процессов, происходящих на предприятии, и предоставляет инструментарий для наглядного исследования и моделирования их сценариев. Сценарием(Scenario) называется описание последовательности изменений свойств объекта, в рамках рассматриваемого процесса (например, описание последовательности этапов обработки детали в цеху и изменение её свойств после прохождения каждого этапа). Исполнение каждого сценария сопровождается соответствующим документооборотом, который состоит из двух основных потоков: документов, определяющих структуру и последовательность процесса (технологических указаний, описаний стандартов и т.д.), и документов, отображающих ход его выполнения (результатов тестов и экспертиз, отчетов о браке, и т.д.). Для эффективного управления любым процессом, необходимо иметь детальное представление об его сценарии и структуре сопутствующего документооборота. Средства документирования и моделирования IDEF3 позволяют выполнять следующие задачи:

· документировать имеющиеся данные о технологии процесса, выявленные, скажем, в процессе опроса компетентных сотрудников, ответственных за организацию рассматриваемого процесса;

· определять и анализировать точки влияния потоков сопутствующего документооборота на сценарий технологических процессов;

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

· содействовать принятию оптимальных решений при реорганизации технологических процессов;

· разрабатывать имитационные модели технологических процессов, по принципу «КАК БУДЕТ, ЕСЛИ…».

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

Рис. 4. Схема бизнес-процесса в стандарте IDEF3

Существуют два типа диаграмм в стандарте IDEF3, представляющие описание одного и того же сценария технологического процесса в разных ракурсах. Диаграммы относящиеся к первому типу называются диаграммамиОписания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD), а ко второму –диаграммами Состояния Объекта в и его Трансформаций Процессе (Object State Transition Network, OSTN). Предположим, требуется описать процесс окраски детали в производственном цеху на предприятии. С помощью диаграмм PFDD документируется последовательность и описание стадий обработки детали в рамках исследуемого технологического процесса. Диаграммы OSTN используются для иллюстрации трансформаций детали, которые происходят на каждой стадии обработки.

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

Рис. 5. Пример PFDD диаграммы

На рисунке 5 изображена диаграмма PFDD, являющаяся графическим отображение сценария обработки детали. Прямоугольники на диаграмме PFDD называютсяфункциональными элементами или элементами поведения (Unit of Behavior, UOB) и обозначают событие, стадию процесса или принятие решения. Каждый UOB имеет свое имя, отображаемое в глагольном наклонении и уникальный номер. Стрелки или линии являются отображением перемещения детали между UOB‑блоками в ходе процесса. Линии бывают следующих видов:

· Старшая (Precedence) – сплошная линия, связывающая UOB. Рисуется слева направо или сверху вниз;

· Отношения (Relational Link) – пунктирная линия, использующаяся для изображения связей между UOB;

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

Объект, обозначенный J1 – называется перекрестком(Junction). Перекрестки используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления. При внесении перекрестка в диаграмму необходимо указать тип перекрестка.

Все перекрестки в PFDD диаграмме нумеруются, каждый номер имеет префикс «J».

Сценарий, отображаемый на диаграмме, можно описать в следующем виде:

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

Каждый функциональный блок UOB может иметь последовательность декомпозиций, и, следовательно, может быть детализирован с любой необходимой точностью. Под декомпозицией мы понимаем представление каждого UOB с помощью отдельной IDEF3 диаграммы. Например, мы можем декомпозировать UOB «Окрасить Деталь», представив его отдельным процессом и построив для него свою PFDD диаграмму. При этом эта диаграмма будет называться дочерней, по отношению к изображенной на рис. 5, а та, соответственно родительской. Номера UOB дочерних диаграмм имеют сквозную нумерацию, т.е., если родительский UOB имеет номер «1», то блоки UOB на его декомпозиции будут соответственно иметь номера «1.1», «1.2» и т.д. Применение принципа декомпозиции в IDEF3 позволяет структурировано описывать процессы с любым требуемым уровнем детализации.

Рис. 6. Пример OSTN диаграммы

Если диаграммы PFDD технологический процесс «С точки зрения наблюдателя», то другой класс диаграмм IDEF3 OSTN позволяет рассматривать тот же самый процесс «С точки зрения объекта». Состояния объекта (в нашем случае детали) и Изменение состояния являются ключевыми понятиями OSTN диаграммы. Состояния объекта отображаются окружностями, а их изменения направленными линиями. Каждая линия имеет ссылку на соответствующий функциональный блок UOB, в результате которого произошло отображаемое ей изменение состояния объекта.

В IDEF3 декомпозиция используется для детализации работ. Методология IDEF3 позволяет декомпозировать работу многократно, т.е. работа может иметь множество дочерних работ. Это позволяет в одной модели описать альтернативные потоки. Возможность множественной декомпозиции предъявляет дополнительные требования к нумерации работ. Так, номер работы состоит из номера родительской работы, версии декомпозиции и собственного номера работы на текущей диаграмме.

Рассмотрим процесс декомпозиции диаграмм IDEF3, включающий взаимодействие автора (аналитика) и одного или нескольких экспертов предметной области.

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

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

В результате дополнения диаграмм IDEF0 диаграммами DFD и IDEF3 может быть создана смешанная модель, которая наилучшим образом описывает все стороны деятельности предприятия.

ПРАКТИЧЕСКАЯ ЧАСТЬ

2. Описание предметной области

2.1 Краткая характеристика производства трикотажных изделий

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

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

К трикотажным относят изделия, полученные из нитей (пряжи) путем машинного или ручного вязания.

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

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

Трикотажное изделие характеризует большая растяжимость и пластичность, что дает возможность достижения ощущения легкости и комфорта.

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

Трикотажная ткань состоит из двух перпендикулярно пересекающихся систем нитей. Продольные нити называются основой, а поперечные – утком. Первичным элементом структуры трикотажа является петля. Она представляет собой пространственную кривую, форма которой влияет на свойства полотна. Форма петель разнообразна: округлая, широкая, зауженная, удлиненная.

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

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

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

Кулирный и основовязальный трикотаж может быть как одинарным, так и двойным. Одинарный трикотаж вырабатывается на машинах с одной игольницей, а двойной трикотаж – на машинных с двумя игольницами.

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

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

· Раскройный

· Полурегулярный

· Регулярный

Раскройный способ состоит в том, что трикотажное полотно раскраивают, т.е. вырезают из него детали изделий по лекалам и соединяют их на швейной машине, придавая изделиям необходимую форму. По этому способу изготовляют бельевые и верхние изделия, а также большую часть перчаточных изделий. Для этого способа изготовления изделий характерны значительные отходы трикотажного полотна, достигающие 18–23% при раскрое бельевых изделий и до 25–28% при раскрое верхних изделий. Такая технология применяется для недорогих изделий в массовом производстве и бельевом трикотаже. Положительным для этого способа является возможность изготовления изделий разнообразных моделей и высокая производительность вязальных машин.

Полурегулярный способ отличается от предыдущего тем, что трикотажное полотно вяжется на кругловязальной машине в виде купонов трубчатой формы. Купоны отделяются один от другого с помощью разделительного петельного ряда так, что нижний край купона имеет цельный нераспускающийся петельный ряд, не требующий швейной обработки. Расход трикотажного полотна на изделие при полурегулярном способе изготовления на 3–5% меньше, чем при раскройном способе из-за отсутствия боковых швов и припусков на подгиб низа изделия; кроме того, меньше и время на раскрой и швейную обработку на 8–10%.

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

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

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

2.2 Описание основных бизнес-процессов трикотажной фабрики (на основе диаграммы с методологией IDEF 0)

Контроль качества сырья

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

Расфасовка сырья

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

Вязание полотна

Перед вязанием нити должны выдерживаться в местах хранения не менее 10 ч при нормальных климатических условиях. Полотно вяжется на машинах в соответствии с заправочными данными. Плотность вязания измеряют на машине в свободном состоянии полотна. Куски полотна из нитей одной линейной плотности вяжутся одинаковой массы (10–12 кг) с отклонениями, не превышающими 5%.

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

Подготовка полотна к раскрою

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

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

Обмеловка настила

Обмеловку верхнего слоя настила, или нанесение контуров раскраиваемых деталей на верхний слой настила, выполняют двумя способами: по лекалам и по трафарету.

При обмеловке по лекалам на верхнем слое настила в соответствии с зарисовкой раскладки раскладывают лекала таким образом, чтобы площадь полотна была использована наиболее рационально.

При использовании трафарета раскладываемые на нем лекала обводят по контурам, на которые затем наносят сквозные отверстия. Обмеловка по трафарету состоит в том, что на верхний слой настила накладывают трафарет и запудривают отверстия контуров лекал порошком – мелом или тальком.

Раскрой полотна

Раскрою полотна предшествует операции настилания полотна и разрезания его на секции.

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

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

В процессе этой операции должны быть выполнены следующие требования:

— Полотна тканей в настиле должны располагаться свободно, без натяжения и перекосов, но и без слабины и морщин, иначе детали кроя могут быть деформированы;

— Рисунок во всех полотнах настила должен совпадать по длине и ширине, иначе в готовом изделии нарушается симметричность рисунка;

— Направление ворса во всех полотнах настила должно совпадать, чтобы во всех деталях готового изделия ворс был направлен в одну сторону.

Разрезание полотна – сложная и ответственная операция. Обеспечить высокое качество раскроя при разрезании настила можно только при условии выполнения следующих требований:

— Высокая точность кроя: отклонение от контуров деталей не должны превышать см;

— Контуры деталей не должны быть перекошены;

— Хорошее качество реза, т.е. частота краев вырезанных деталей

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

Комплектование кроеных деталей

Раскроенные детали после контроля и сортировки комплектуют в пачки. При этом их просматривают, разбирают по цветам и оттенкам, подрезают в тех местах, где они не могут быть разрезаны машинами в настиле, исправляют неточности механического раскроя.

Конечным продуктом раскройного цеха является комплект, т.е. пачка деталей подобранных по артикулу полотна, цвету, оттенку и рисунку.

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

Шитье трикотажных изделий

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

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

Швейные операции выполняются на швейных машинах различных типов.

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

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

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

— Рабочие места и оборудование располагаются по ходу технологического процесса шитья изделия;

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

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

Поточная система организации в зависимости от степени ритмичности работы, в свою очередь, подразделяется на прерывно-поточную и непрерывно-поточную

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

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

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

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

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

Технический контроль

Он выполняется на всех технологических переходах при изготовлении изделий из полотна и купонов. Задачи технического контроля – проверка соответствия показателей сырья и материалов, поступающих на предприятие, показателям действующих стандартов и технических условий, проверка качества выполнения технологических операций и качества полотна и купонов в процессе производства.

2.3 Описание вспомогательных бизнес-процессов трикотажной фабрики (на основе диаграммы с методологией IDEF 0)

Бухгалтерия

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

Маркетинговый отдел

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

Финансовый контроль

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

Внутренний аудит

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

Техническая поддержка

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

Сбытовая сеть

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

2.4 Описание внешних сущностей (на основе диаграммы с методологией DFD)

Фискальные органы

Налоговой системе отводится важная роль в государственном регулировании и стимулировании всех процессов, происходящих на предприятии.

Налоговая система выступает основой фискального механизма государственного регулирования экономической активности хозяйствующего субъекта.

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

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

Потребители готовой продукции

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

Банк

В современной России осуществление любой фирмой своей основополагающей финансовой функции – обслуживание платежей и расчетов – невозможно без участия коммерческих банков. Даже элементарные финансовые транзакции по осуществлению движения наличных денег, принадлежащих фирме, невозможны без их инкассации – сдачи наличности в обслуживающий фирму банк. С точки зрения повышения степени надежности перемещения денежных средств в любой форме между субъектами экономических отношений такой порядок в известной мере оправдан.

Поставщики материалов, услуг и энергетических ресурсов

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

2.5 Описание внутренних сущностей и накопителей (на основе диаграммы с методологией DFD)

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

Функционально подсистема разбивается на следующие процессы:

1. Управление производством – включает в себя деятельность директора Фабрики, главного бухгалтера, руководителя ремонтной службы (главного механика, главного энергетика, руководителя КИП), организацию документооборота.

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

3. Ремонт и обслуживание – включает в себя обработку заявок на ремонт, определение (выбор) ремонтной службы (механика, энергетика, КИП), выполнение ремонтных работ (определение типа ремонта, определение вида ремонта, назначение исполнителей, получение запасных частей и материалов, проверка качества ремонта, учет на складе), проверку выполнения работ.

4. Контроль и безопасность работ – включает в себя технический контроль, организацию техники безопасности, контроль пожарной безопасности.

На данном уровне введены накопители данных, используемые в нескольких видах деятельности и являющиеся прообразами подсхем интегрированной базы данных информационной системы Фабрики.

1. Управление производством – включает в себя деятельность директора Фабрики, главного бухгалтера, руководителя ремонтной службы (главного механика, главного энергетика, руководителя КИП), организацию документооборота.

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

3. Контроль и безопасность работ – включает в себя технический контроль, организацию техники безопасности, контроль пожарной безопасности.

4. Ремонт и обслуживание – включает в себя все виды работ по ремонту оборудования, складских помещений, содержание складских и производственных помещений.

На данном уровне введены накопители данных, используемые в нескольких видах деятельности и являющиеся прообразами подсхем интегрированной базы данных информационной системы Фабрики.

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

2. НСИ (нормативно-справочная информация) – используется для хранения нормативов, тарифов и другой информации подобного вида.

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

4. Внутренний документооборот – информационный канал, используемый для моделирования организации документооборота на Фабрике.

5. Запасные части – используется для хранения данных об имеющихся в наличии полотен, тесьмы, пуговиц и т.п.

2.6 Технологический процесс «Производство трикотажных изделий»

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

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

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

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

Вязание полотна. Перед вязанием нити должны выдерживаться в местах хранения не менее 10 ч при нормальных климатических условиях. Полотно вяжется на машинах в соответствии с заправочными данными. Плотность вязания измеряют на машине в свободном состоянии полотна. Куски полотна из нитей одной линейной плотности вяжутся одинаковой массы (10–12 кг) с отклонениями, не превышающими 5%.

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

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

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

Обмеловка настила. Обмеловку верхнего слоя настила, или нанесение контуров раскраиваемых деталей на верхний слой настила, выполняют двумя способами: по лекалам и по трафарету.

При обмеловке по лекалам на верхнем слое настила в соответствии с зарисовкой раскладки раскладывают лекала таким образом, чтобы площадь полотна была использована наиболее рационально.

При использовании трафарета раскладываемые на нем лекала обводят по контурам, на которые затем наносят сквозные отверстия. Обмеловка по трафарету состоит в том, что на верхний слой настила накладывают трафарет и запудривают отверстия контуров лекал порошком – мелом или тальком.

Раскрой полотна. Раскрою полотна предшествует операции настилания полотна и разрезания его на секции.

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

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

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

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

Конечным продуктом раскройного цеха является комплект, т.е. пачка деталей подобранных по артикулу полотна, цвету, оттенку и рисунку.

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

Шитье трикотажных изделий. Процессы шитья охватывают целый комплекс операций, которые в основном разделяют на следующие: швейные, влажно-тепловые и вспомогательные.

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

Швейные операции выполняются на швейных машинах различных типов.

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

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

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

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

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

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

Технический контроль. Он выполняется на всех технологических переходах при изготовлении изделий из полотна и купонов. Задачи технического контроля – проверка соответствия показателей сырья и материалов, поступающих на предприятие, показателям действующих стандартов и технических условий, проверка качества выполнения технологических операций и качества полотна и купонов в процессе производства.

ЗАКЛЮЧЕНИЕ

В последние годы интерес в России к методологиям семейства IDEF неуклонно растет. При этом интерес к таким стандартам, как IDEF3–5 является теоретическим, а к IDEF0 вполне практически обоснованным. Собственно говоря, первые CASE‑средства, позволяющие строить DFD и IDEF0 диаграммы, появились на российском рынке еще в 1996 году, одновременно с выходом популярной книги по принципам моделирования в стандартах SADT.

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

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

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

С помощью средств BPwin в данной работе удалось максимально приближенно и подробно описать работу трикотажной фабрики, начиная от поставки сырья (нитей и пряжи), его обработки, пошива изделия и до отгрузки в торговые точки и заказчикам. Результатом этой работы служит – структурированность данных, способствующая нахождению проблемных мест, и соответственно отладка процесса пошива, возможность снижения затрат, а следовательно и повышение прибыли предприятия «Трикотажная фабрика».

СПИСОК ЛИТЕРАТУРЫ

1. Маклаков С.В. «BPwin и ERwin. CASE‑средства разработки информационных систем». Москва, «ДИАЛОГ-МИФИ», 1999.

2. Дубейковский В.И. Эффективное моделирование с AllFusion Process Modeler 4.1.4 и AllFusion PM. М.: ДИАЛОГ-МИФИ, 2007.

3. Черемных С.В., Семенов И.О., Ручкин В.С. Моделирование и анализ систем. IDEF – технологии. – М.: «Финансы и кредит», 2001.

4. С.В. Черемных, и др. Структурный анализ систем: IDEF – технологии. – М: Финансы и статистика, 2005.

5. Шеер А.В. Моделирование бизнес-процессов. – М.: Весть-МетаТехнология, 2000.

6. Методология функционального моделирования IDEF0. Руководящий документ РД IDEF0–2000 М.: Госстандарт России, 2000.

7. Вендеров А.М. CASE‑технологии. Современные методы и средства проектирования информационных систем М.: Финансы и статистика, 2005.

Стандарты и методологии моделирования бизнес- процессов

МОСКОВСКИЙ
АВИАЦИОННЫЙ ИНСТИТУТ

Стандарты и методологии моделирования
бизнес-процессов.

Выполнил:  студент группы 03-431

Степанов М.Д.

Москва, 2009г.

Содержание

1. Введение. 3

1. Сущность и значение моделирования
бизнес-процессов. 4

1.2.История развития методологий бизнес-процессов. 7

1.3. Современные методологии описания
бизнес-процессов. 8

1.4. Методология IDEF0. 8

1.5. Методология DFD.. 11

1.6. Методология IDEF3. 14

1.7. Методология ORACLE. 18

1.8. Методология IDEF1X.. 19

1.9. Методология IDEF4. 21

1.10. Методология SADT. 21

1.11. Методология ARIS. 22

1.12. Методология, применяемая консалтинговыми
компаниями. 29

1.13. Методология Betec (©) 31

1.14. Методология BAAN.. 37

2. Аналитический раздел. 41

3. Проектный раздел. 43

3.1. Постановказадачи. 43

3.2. Экономическая сущность задачи. 43

3.3. Описание метода решения задачи. 43

3.4. Описание бизнес-процесса. 44

Заключение. 45

Список используемыхисточников. 46

Введение

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

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

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

Основу многих современных методологий моделирования
бизнес-процессов составили методология SADT (Structured Analysis and Design
Technique – метод структурного анализа и проектирования), семейство стандартов
IDEF (Icam DEFinition, где Icam — это Integrated Computer-Aided Manufacturing)
и алгоритмические языки. Основные типы методологий моделирования и анализа
бизнес-процессов:

·  
Моделирование
бизнес-процессов (Business Process Modeling). Наиболее широко используемая
методология описания бизнес-процессов – стандарт IDEF0. Модели в нотации IDEF0
предназначены для высокоуровневого описания бизнеса компании в функциональном
аспекте.

·  
Описание
потоков работ (Work Flow Modeling). Стандарт IDEF3 предназначен для описания
рабочих процессов и близок к алгоритмическим методам построения блок-схем.

·  
Описание
потоков данных (Data Flow Modeling). Нотация DFD (Data Flow Diagramming),
позволяет отразить последовательность работ, выполняемых по ходу процесса, и
потоки информации, циркулирующие между этими работами.

·  
Прочие
методологии.

1.    Сущность
и значение моделирования бизнес-процессов

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

Существует
несколько подходов к определению понятия «моделирование бизнес-процессов»:

1)
моделирование
бизнес-процессов — это описание бизнес-процессов предприятия позволяющее
руководителю знать, как работают рядовые сотрудники, а рядовым сотрудникам —
как работают их коллеги и на какой конечный результат направлена вся их
деятельность ;

2)
Моделирование
бизнес-процессов – это эффективное средство поиска путей оптимизации
деятельности компании, позволяющее определить, как компания работает в целом и
как организована деятельность на каждом рабочем месте.;

3)
моделирование
бизнес-процессов — это средство позволяющее предвидеть и минимизировать риски,
возникающие на различных этапах реорганизации деятельности предприятия;

4)
моделирование
бизнес-процессов — это метод, позволяющий дать оценку текущей деятельности
предприятия по отношению к требованиям, предъявляемым к его функционированию,
управлению, эффективности, конечным результатам деятельности и степени
удовлетворенности клиента ;

5)
моделирование
бизнес-процессов — это метод, позволяющий дать стоимостную оценку каждому
процессу, взятому в отдельности, и всем бизнес-процессам на предприятии, взятым
в совокупности;

6)
моделирование
бизнес-процессов — это всегда верный способ выявления текущих проблем на
предприятии и предвидения будущих.

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

Бизнес-процесс
– это логичный, последовательный, взаимосвязанный набор мероприятий, который
потребляет ресурсы, создаёт ценность и выдаёт результат. В международном
стандарте ISO 9000:2000 принят термин «процесс», однако в настоящее
время эти термины можно считать синонимами. Среди основных
причин, побуждающих организацию оптимизировать бизнес-процессы, можно выделить
необходимость снижения затрат или длительности производственного цикла,
требования, предъявляемые потребителями и государством, внедрение программ
управления качеством, слияние компаний, внутриорганизационные противоречия и
др. .

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

Решения
по моделированию бизнес-процессов обычно принимается по причинам,
представленным на рисунке 1.

Рисунок
1 — Причины, по которым принимается решение по моделированию бизнес-процессов

Моделирование бизнес-процессов затрагивает многие аспекты
деятельности компании:

ü  
изменение
организационной структуры;

ü  
оптимизацию
функций подразделений и сотрудников;

ü  
перераспределение
прав и обязанностей руководителей;

ü  
изменение
внутренних нормативных документов и технологии проведения операций;

ü  
новые
требования к автоматизации выполняемых процессов и т. д.

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

Моделирование
бизнес-процессов организации включает два этапа структурное и детальное.

Структурное
моделирование бизнес-процессов организации может выполняться в нотации IDEF0 с
использованием инструментария BPwin или на языке UML с использованием
инструментария Rational Rose. Детальное моделирование выполняется на языке UML.

На
этапе структурного моделирования в модели должны быть отражены:

1)
существующая
организационная структура;

2)
документы
и иные сущности, используемые при исполнении моделируемых бизнес-процессов и
необходимые для моделирования документооборота, с описаниями их основного
смысла;

3)
структуру
бизнес-процессов, отражающую их иерархию от более общих групп к частным бизнес-процессам;

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

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

Детальная
модель бизнес-процесса должна включать:

1)
набор
прецедентов отражающих возможные варианты выполнения бизнес-процессов «как
есть»;

2)
диаграммы
действий, детально описывающие последовательность выполнения бизнес-процессов;

3)
диаграммы
взаимодействия, отражающие схемы документооборота.

Модели
должны быть согласованы с ведущими специалистами организации, обладающими
необходимыми знаниями.

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

1.2
История развития методологий моделирования бизнес-процессов

Основу многих современных методологий моделирования
бизнес-процессов составили методология SADT (Structured Analysis and Design
Technique – метод структурного анализа и проектирования) и алгоритмические
языки, применяемые для разработки программного обеспечения.

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

1.3
Современные методологии описания бизнес-процессов

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

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

На самом деле, несмотря на свое различие, в основном
связанное с названием диаграмм и видов используемых объектов современные
методологии описания бизнес-процессов практически идентичны и представляют из
себя незначительные видоизменения двух классических схем — DFD и WFD – Work
Flow Diagram, которые были рассмотрены.

Давайте рассмотрим другие современные языки описания
бизнес-процессов:

·  
IDEF0;

·  
DFD
в нотациях Гейна-Сарсона и Йордана-Де Марко;

·  
IDEF3;

·  
Oracle;

·  
BAAN;

·  
ARIS.

·  
Swimmer lanes;

1.4
 Методология IDEF0

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

Методология IDEF0 незначительно отличается от
классической схемы описания бизнес-процессов DFD, которая была рассмотрена
ранее. Основным отличием является наличие в языке дополнительной аналитики.
Данный стандарт описания бизнес-процессов предлагает показывать не просто входы
и выходы, как это делается в DFD – формате, он предлагает ввести три типа
входов. Первый тип входов назвали так же входом, а два других входа назвали
управлением и механизмами.

В стандарте IDEF0 c помощью входа показывают объекты
– информационные и материальные потоки, которые преобразуются в
бизнес-процессе. С помощью управления показывают объекты – материальные и
информационные потоки, которые не преобразуются в процессе, но нужны для его
выполнения. С помощью механизмов стали показывать механизмы, при помощи которых
бизнес-процесс реализуется: технические средства, люди, информационные системы
и т.д. Выход бизнес-процесса, описанного в стандарте IDEF0 полностью
соответствует по смыслу выходу процесса, описанному при помощи DFD-схемы.

Таблица 1. Название и размещение входов
и выходов в стандарте IDEF0 относительно функционального блока.

Давайте рассмотрим пример бизнес-процесса
«Выточить деталь», который выполняет токарь. Входом процесса является
заготовка из которой вытачивается деталь – она физически преобразуется в
процессе. Для того, что бы токарь начал точить деталь ему нужно дать задание
или план. Также ему понадобится чертеж с размерами детали. Так вот, чертеж,
задание или план нужны для реализации бизнес-процесса и процесс без них не
начнется, но по ходу выполнения процесса они не преобразуются. Согласно
стандарту IDEF0 их относят к управлению. Для того, что бы выточить деталь нужен
токарь, нужен станок – их относят к механизмам. Выходами или результатами
бизнес-процесса является деталь (рис. 3).

Рис.3. Стандарт описания бизнес-процесса
IDEF0.

Стандарт IDEF0 получил большое распространение в США
и активно используется в России. Ввиду того, что в стандарте IDEF0 появилась
дополнительная аналитика по сравнению с классическим стандартом DFD, схемы
бизнес-процессов получаемые при описании в стандарте IDEF0 выглядят более
сложными с точки зрения менеджеров компании, в виду ограниченного наличия у них
свободного времени. Данная сложность часто приводит к тому, что менеджеры,
особенно высшего уровня, которые должны принимать активное участие в проекте по
описанию и оптимизации деятельности компании, «отказываются» от
работы с IDEF0. В данном случае IDEF0 — является излишне информационно
насыщенным и сложным стандартом.

Второй недостаток стандарта IDEF0 связан с тем, что
он дает больше поводов и возможностей сторонникам сопротивлений изменениям
притормозить проект по описанию и оптимизации бизнес-процессов и
дискредитировать его идею. Это также связано с усложненной аналитикой стандарта
IDEF0, которая часто дает повод задуматься и задавать следующие вопросы:
«А правильно ли, что этот объект отнесен ко входу? Может его отнести к
управлению?»

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

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

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

1.5 
Методология DFD в нотациях Гейна-Сарсона и Йордана-Де Марко

Следующий стандарт описания бизнес-процессов,
который получил распространение, был разработан на основе развития классической
методологии DFD. Данный стандарт представлен двумя немного различающихся
вариантами, которые называют нотациями. Первая из них называется нотацией Гейна
Сарсона, вторая нотацией Йордона-Де Марко.

Гейн Сарсон, предложил классическую DFD-схему
немного усложнить. Он предложил ввести дополнительный объект, с помощью
которого показываются места бизнес-процесса, в которых хранится информация,
либо материальные ресурсы. Примерами таким мест являются архив, в котором
хранятся документы, база данных, в которой хранится информация, либо склад, на
котором хранятся материальные ресурсы. Данный объект получил название —
хранилище данных. На DFD-схемах в нотациях Гейна-Сарсона и Йордона-Де Марко
также используются объекты, с помощью которых показывают внешних субъектов, с
которыми бизнес-процесс взаимодействует. Данные объекты называют внешними
сущностями. На рис. 5 приведен пример DFD-схемы бизнес-процесса
«Оформлении и выдача трудовой книжки сотруднику при увольнении»,
разработанной в нотации Гейна-Сарсона.

Рис. 5. DFD-схема бизнес-процесса
«Оформлении и выдача трудовой книжки сотруднику при увольнении» в
нотации Гейна-Сарсона.

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

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

Рис. 6. DFD-схема бизнес-процесса
«Оформлении и выдача трудовой книжки сотруднику при увольнении» в
нотации Йордона-Де Марко.

В таблице 2 приведены названия, обозначения и смыл
элементов, используемых при построении DFD-схемы бизнес-процесса в нотациях
Гейна-Сарсано и Йордона-Де Марко.

 Таблица 2. Элементы
методологии DFD в нотацияхГейна-Сарсано и Йордона-Де Марко.

1.6
Методология IDEF3

Стандарт IDEF0, который был рассмотрен ранее
является развитием классического DFD – подхода и предназначен для описания
бизнес-процессов верхнего уровня. Для описания временной последовательности и
алгоритмов выполнения работ стандарт IDEF0 не подходит. Для решения этой задачи
стандарт IDEF0 получил дальнейшее развитие в результате чего был разработан
стандарт IDEF3, который входит в семейство стандартов IDEF.

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

Рис. 7. Схема бизнес-процесса в
стандарте IDEF3.

 Таблица 3. Типы связей
между работами в стандарте IDEF3.

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

Перекресток «Исключающий ИЛИ» обозначает,
что после завершения работы «A» (рис. 8), начинает выполняться только
одна из трех расположенных параллельно работ B, С или D в зависимости от
условий 1, 2 и 3. Перекресток «И» обозначает, что после завершения
работы «A», начинают выполняться одновременно три параллельно
расположенные работы B, С и D. Перекресток «ИЛИ» обозначает, что
после завершения работы «A», может запуститься любая комбинация трех
параллельно расположенных работ B, С и D. Например может запуститься только
одна из них, могут запуститься три работы, а также могут запуститься двойные
комбинации В и С, либо C и D, либо B и D. Перекресток «Исключающий
ИЛИ» является самым неопределенным, так как предполагает несколько
возможных сценариев реализации бизнес-процесса и применяется для описания слабо
формализованных ситуаций.

Рис. 8. Применение перекрестков
«Исключающий ИЛИ», «И» и «ИЛИ» — схемы
расхождения.

Перекрестки «И» и «ИЛИ»
подразделяются еще на два подтипа – синхронные и асинхронные. Перекрестки
синхронного типа обозначают, что работы В, С и D запускаются одновременно после
завершения работы A. Перекрестки асинхронного типа требований к одновременности
не предъявляют.

Приведенные на рис. 5 схемы взаимосвязи работ и
перекрестков называются схемами расхождения, так как от перекрестков расходятся
несколько работ. Существует и другие схемы взаимосвязи перекрестков и работ –
это так называемые схемы схождения, когда к перекрестку подходит несколько
работ (рис. 9).

Рис. 9. Применение перекрестков
«Исключающий ИЛИ», «И» и «ИЛИ» — схемы схождения.

В таблице 4 приведены обозначения, названия и смысл
всех типов перекрестков как в схемах схождения, так и в схемах расхождения.

Таблица 4. Обозначения, названия и смысл
типов перекрестков в схемах схождения и расхождения.

1.7
Методология ORACLE

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

Три наиболее крупных разработчика информационных
систем: SAP/R3, BAAN и ORACLE для повышения эффективности внедрения своих
информационных систем разработали свои стандарты и программные продукты, с
помощью которых описывается бизнес-деятельность компании. Каждый из этих
стандартов содержит несколько бизнес-моделей, с помощью которых описываются
бизнес-процессы, организационная структура, а также строятся прочие
бизнес-модели.

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

Таблица 5. Модели методологии ORACLE.

При описании бизнес-процессов с использованием
методологии ORACLE наиболее часто применяется вторая согласно перечню таблицы 5
модель бизнес-процессов. Построение этой модели основано на подходе
«Swimmer lanes», который представляет из себя смесь классических DFD
и WFD стандартов и имеет одну отличительную особенность. Диаграмма, на котором
рисуется схема бизнес-процесса разделена по горизонтали на дорожки. Каждая
дорожка принадлежит определенному структурному подразделению или должности,
участвующей в бизнес-процессе. Те операции бизнес-процесса, которые выполняются
этим структурным подразделением, размещаются в зоне соответствующей дорожки.
Такой подход позволяет наглядно показать распределение ответственности в
бизнес-процессе и продемонстрировать степень его организационной фрагментарности
(рис. 10).

Рис. 10. Пример описания бизнес-процесса
«Торговля чаем» для функциональной организационной структуры компании
«Эврика».

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

1.8
IDEF1X

IDEF1X — методология описания данных. Применяется
для построения баз данных.

IDEF1X является методом для разработки реляционных
баз данных и использует условный синтаксис, специально разработанный для
удобного построения концептуальной схемы. Концептуальной схемой мы называем
универсальное представление структуры данных в рамках коммерческого
предприятия, независимое от конечной реализации базы данных и аппаратной
платформы. Будучи статическим методом разработки, IDEF1X изначально не
предназначен для динамического анализа по принципу «AS IS», тем не
менее, он иногда применяется в этом качестве, как альтернатива методу IDEF1.
Использование метода IDEF1X наиболее целесообразно для построения логической
структуры базы данных после того, как все информационные ресурсы исследованы
(скажем с помощью метода IDEF1) и решение о внедрении реляционной базы данных,
как части корпоративной информационной системы, было принято. Однако не стоит
забывать, что средства моделирования IDEF1X специально разработаны для
построения реляционных информационных систем, и если существует необходимость
проектирования другой системы, скажем объектно-ориентированной, то лучше
избрать другие методы моделирования.

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

1.7.1 Связи между сущностями

Связи в IDEF1X представляют собой ссылки, соединения
и ассоциации между сущностями. Ниже, на рисунке, приведен ряд примеров связи
между сущностями:

Сущность описывается в диаграмме IDEF1X графическим
объектом в виде прямоугольника. На рисунке 2 приведен пример IDEF1X диаграммы.

1.7.2 Преимущества IDEF1X

Основным преимуществом IDEF1X, по сравнению с
другими многочисленными методами разработки реляционных баз данных, такими как
ER и ENALIM является жесткая и строгая стандартизация моделирования.
Установленные стандарты позволяют избежать различной трактовки построенной
модели, которая несомненно является значительным недостатком ER.

1.9
IDEF4

IDEF4 — объектно-ориентированная методология.
Отражает взаимодействие объектов. Удобна для создания программных продуктов на
объектно-ориентированных языках (например С++). Пока, на мой взгляд, широкого
распространения не нашла. Более широко сейчас используется UML.

1.10
SADT

SADT — методология структурного анализа и
проектирования  (Structured Analysis and Design Technique). Основана на
понятиях функционального моделирования.  Является методологией, отражающей
такие системные характеристики, как управление, обратная связь и исполнители.
Возникла в конце 60-х годов.

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

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

1.11
ARIS

Методология ARIS

Одной из современных методологий
бизнес-моделирования, получившей широкое распространение в России является
методология ARIS, которая расшифровывается как Architecture of Integrated
Information Systems — проектирование интегрированных информационных систем. Ее
использует программное средство ARIS Toolset

Методология ARIS на данный момент времени является
наиболее объемной и содержит около 100 различных бизнес-моделей, используемых
для описания, анализа и оптимизации различных аспектов деятельности организации.
Часть моделей методологии ARIS используются в настроечном модуле
интегрированной информационной системы SAP/R3, который применяется при
внедрении системе и ее настройке на деятельности компании. В виду большого
количества бизнес-моделей методология ARIS делит их на четыре группы (рис. 11):

Группа «Оргструктура».

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

Группа «Функции».

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

Группа. «Информация».

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

Группа «Процессы».

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

Рис. 11. Группы моделей методологии
ARIS.

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

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

 Например, материальные и информационные потоки на
процессных схемах обозначаются разными по форме и цвету объектами, что
позволяет быстро определить тип потока.

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

Таблица 6. Наиболее часто используемые
на практике модели методологии ARIS.

Модель «Диаграмма целей» — OD применяется
для описания стратегических целей компании, их иерархической упорядоченности, а
также связей целей с продуктами и услугами, производимыми компанией и
бизнес-процессами, поддерживающими их производство (рис. 12)

Рис. 12. Модель «Диаграмма
целей» — OD/ARIS.

Модель «Дерево продуктов и услуг» — PST
применяется для описания продуктов и услуг, производимых в компании, а также и
связи со стратегическими целями компании, бизнес-процессами, поддерживающими их
производство (рис. 13).

 Рис.
13. Модель «Дерево продуктов и услуг — PST/ARIS».

Модель «Дерево функций» — FT описывает
функции, выполняемые в компании и их иерархию. Данная модель часто применяется
для для построения дерева бизнес-процессов компании (рис. 14).

 Рис. 14. Модель «Дерево
функций» — PST/ARIS.

Модель «Диаграмма окружения процесса» —
FAT позволяет описать окружение или границы бизнес-процесса, показывая его
входы, выходы, поставщиков и клиентов (рис. 15).

Рис. 15. Модель «Диаграмма
окружения процесса» — PST/ARIS.

Модель «Диаграмм цепочки добавленной
стоимости» — VACD является прототипом классического DFD-стандарта и
используется для описания бизнес-процессов верхнего уровня. Дополнительным
отличием данной и других процессных моделей является то, что информационные и
материальные потоки на схеме VACD изображаются не стрелками, а объектами. При
этом для каждого типа потока используется свой объект. На модели VACD
методологии ARIS в отличие от классического подхода также используется
логические связи между работами, которые позволяют отобразить логическую
последовательность выполнения работ. В качестве одного из вариантов логической
последовательности может выступать временная последовательность выполнения
работ, что характерно для классического подхода WFD. (рис. 16).

 

Рис. 16. Модель «Расширенная
цепочка процессов, управляемая событиями» — eEPC/ARIS.

Модель «Матрица выбора процесса» — PSM
является прототипом классического DFD-стандарта и используется как альтернатива
для модели VACD. Матрица выбора процессов по отношению к диаграмме цепочки
добавленной стоимости является с одной стороны более упрощенным вариантом
описания процесса, с другой стороны данная модель содержит дополнительные
объекты, позволяющие показать другие аспекты бизнес-процесса. Простота матрицы
выбора бизнес-процессов связана с тем, что на данной модели не показываются
информационные и материальные потоки. Что касается других аспектов, то данная
модель позволяет на одной схеме компактно и наглядно показать различные
варианты выполнения бизнес-процесса, который описывается. Соответственно
матрицу выбора процессов целесообразно применять вместо диаграммы цепочки
добавленной стоимости в случаях, когда описываемый бизнес-процесс имеет
несколько вариантов исполнения, каждый из которых ложится базовую схему. Пример
применения матрицы выбора процессов для описания деятельности компании
«Эврика», имеющий функциональную организационную структуру показан на
рис. 17.

Рис. 17. Модель «Матрица выбора
процессов» — PSM/ARIS.

Модель «Extended event driven Process
Chain» — eEPC является прототипом классического WFD-стандарта и
используется для описания бизнес-процессов нижнего уровня. Дополнительным
отличием eEPC-модели от классической WFD-схемы является наличие на модели
объекта, который называется событием. С помощью событий изображается факт,
время или событие инициирующие начало выполнения работ процесса, а также факт или
время их завершения (рис. 18).

Рис. 18. Модель «Расширенная
цепочка процессов, управляемая событиями» — VACD/ARIS.

Модель «Организационная структура» — ORG
используется для описания организационной структуры компании. На данной модели
изображаются структурные подразделения, группы, должности, роли и прочие
элементы организационной структуры и связи между ними (рис. 19).

Рис. 19. Модель «Организационная
структура» — ORG/ARIS.

Модель «Диаграмма типов информационных
систем» — ASTD используется для описания структуры информационных систем,
используемых в компании. На данной модели показываются типы и модули информационных
систем, программные продукты, взаимосвязь между ними и бизнес-процессами
организации, которые они автоматизируют (рис. 20).

 

Рис. 20. Модель «Диаграмма типов
информационных систем» — VACD/ASTD.

Для хранения моделей в ARIS используется объектная
СУБД, и под каждый проект создается новая база данных. Предусмотрены различные
функции по администрированию базы данных, например, управление доступом. База
данных представляет из себя иерархическое хранилище моделей.

1.12
Методология, применяемая консалтинговыми компаниями

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

Модель верхнего уровня и принципы ее построения
представлена на рис. 21.

Рис. 21. Модель описания
бизнес-процессов верхнего уровня, применяемая консалтинговыми компаниями.

Модель бизнес-процессов нижнего уровня, использующая
подход «Swimmer lanes» представлена на рис. 22.

Рис. 22. Модель описания бизнес-процессов
нижнего уровня, применяемая консалтинговыми компаниями.

1.13
Методология Betec (©)

На основе применения различных современных
методологий описания бизнес-процессов в российских компаниях, консалтинговая
компания «Бизнес — инжиниринговые технологии» разработала методологию
описания деятельности, компании, воплотившую в себя наилучшие элементы
рассмотренных выше методологий. Данная методология, называемая Betec (©),
состоит из моделей, с помощью которых описывают бизнес-деятельность компании и
которые условно сгруппированы в следующие разделы:

·  
Стратегия;

·  
Бизнес-процессы;

·  
Оргструктура;

·  
Финансы;

·  
Персонал;

·  
Маркетинг.

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

 Таблица 7. Модели
методологии Betec (©) соответствующие разделам «Бизнес-процесс» и
«Оргструктура».

Модель «Дерево бизнес-направлений»
применяется для описания бизнес-направлений, реализуемых в компании и их
взаимосвязь с другими элементами организации (рис. 23).

Рис. 23. Модель «Дерево
бизнес-направлений» — Betec (©).

Модель «Дерево бизнес-процессов» описывает
бизнес-процессы, выполняемые в компании и их иерархию (рис. 24). На верхнем
уровне дерева бизнес-процессы делятся на три группы: основные, обеспечивающие и
управленческие.

Рис. 24. Модель «Дерево
бизнес-процессов» — Betec (©).

Модель «Диаграмм окружения процесса»
позволяет описать окружение или границы бизнес-процесса, показывая его входы,
выходы, поставщиков и клиентов (рис. 25).

Рис.25. Модель «Диаграмма окружения
процесса» — Betec (©).

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

Рис. 26. Модель «Дерево
информационных потоков» — Betec (©).

Модель «Дерево материальных потоков»
позволяет описать и классифицировать материальные потоки компании, которые
представляют из себя сырье, полуфабрикаты, готовую продукцию и т.д. (рис. 27).

Рис. 27. Модель «Дерево
материальных потоков» — Betec (©).

Модель «Дерево организационной структуры»
используется для описания организационной структуры компании. На данной модели
изображаются структурные подразделения, должности, а также связи линейного и
функционального подчинения (рис. 28).

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

Рис. 28. Модель «Дерево
организационной структуры» — Betec (©).

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

Рис. 29. Модель «Дерево
информационной системы» – — Betec (©).

Модель «Диаграмма процесса — DFD» является
прототипом классического DFD–стандарта и используется для описания
бизнес-процессов верхнего уровня. При построении диаграммы процесса – DFD
описываются работы из которых состоит бизнес-процесс, а также используются
элементы организационной структуры, информационных систем, материальных и
информационных потоков, которые были описаны при построении бизнес-моделей,
рассмотренных выше.

В случае если в проекте была описана внутренняя
структура информационных потоков, то на схеме процесса показывается
соответствие между элементами информационных потоков и документами в формате MS
Word, описывающих внутреннюю структуру информации (рис. 30).

Рис. 30 Модель «Диаграмма процесса
— DFD» – — Betec (©).

Модель «Диаграмма процесса — WFD» является
прототипом классического WFD–стандарта и используется для описания
бизнес-процессов нижнего уровня. При построении диаграммы процесса – WFD
описываются работы, из которых состоит бизнес-процесс, а также используются
элементы организационной структуры, информационных систем, материальных и
информационных потоков, которые были описаны при построении бизнес-моделей,
рассмотренных выше.

В случае если в проекте была описана внутренняя
структура информационных потоков, то на схеме процесса показывается
соответствие между элементами информационных потоков и документами в формате MS
Word, описывающих внутреннюю структуру информации (рис. 31).

Рис. 31 Модель «Диаграмма процесса
— WFD» – — Betec (©).

1.14 Методология BAAN

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

 Таблица
8. Модели методологии BAAN.

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

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

Рис. 32. Модель
метаструктуры предприятия – ESM / BAAN.

Структурные
подразделения компании, изображенные на модели метаструктуры предприятия – ESM
декомпозируется на модель управления – BCM, на которой показываются
бизнес-процессы данного структурного подразделения, а также материальные и
информационные потоки протекающие между ними. Модель управления – BCМ полностью
соответствуют классической DFD-схеме и она применяется для описания бизнес-процессов
верхнего уровня (рис. 33).

Рис. 33. Модель
управления – BCM / BAAN.

Процессы с модели
управления – BCM декомпозируются на модель управления – BCM более низкого
уровня в случае, если они глобальны и могут быть представлены в виде временной
последовательности работ. В противном случае они декомпозируются на модели
бизнес-процессов – BPM, которые применяются для описания бизнес-процессов нижнего
уровня и практически соответствуют классической WFD-схеме, за исключением двух
особенностей. Первая – блоки принятия решений на модели бизнес-процессов BPM
называются управляющими работами и вторая особенность связана с наличием на
модели элементов, называемых состоянием, с помощью которых описываются
состояния, характеризующие начало и окончания каждой работы. Данный подход,
связанный с описанием состояний заимствован из подхода к описанию
бизнес-процессов, который называется «Сети Петри» (рис. 34).

При описании
деятельности компании методология BAAN также использует модель функций – BFM,
при помощи которых строится дерево функций компании (рис. 35).

Рис. 35. Модель
функций – BFM / BAAN.

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

Рис. 36. Модель
организационной структуры – BOM / BAAN.

Последняя
информационная модель — ERM методологии BAAN имеет тип
«Сущность-Связь» и предназначена для описания структуры информации,
используемой при реализации бизнес-процессов. С помощью данной модели
проектируется базы данных (рис. 37).

2.
Аналитический
раздел

Объект управления: Риэлторская компания (Корпорация
«Инком-Недвижимость»). Основные направления деятельности компании – создание пригородных
жилых комплексов малой и средней этажности, а также осуществление сделок с
жилой и коммерческой недвижимостью в Московском регионе, Кирове и Красноярске.
Одним из главных условий успешного бизнеса риэлторской компании, является
хороший подбор персонала. Так как именно высококлассные специалисты
обеспечивают высокую прибыль компании. Набор персонала, увольнение, смена
должности, обучение персонала – эти процессы, являются такими же важными, как и
процессы связанные с не посредственной деятельностью компании.

Риэлторские компании имеют максимально простую
организационную структуру в форме головного офиса и дополнительных региональных
офисов, что не несет организационные факторы риска и несущественно влияет на
деятельность компаний. Для риэлторских компаний более значимым являются
отраслевые факторы риска и операционные риски. В состав Инком-недвижимости
входят 31 офис в Москве и региональные представительства в Красноярске,
Алма-Ате, Кирове. Управление и структура агентства недвижимости(рис 38).

Рис. 38 Структура агентства недвижимости

Обеспечение служб, риэлторской компании:

Техническое: Рабочие места персонала обеспечены
персональными компьютерами последних моделей, локальной сетью и выходом в
интернет, также всей необходимой орг. Техникой и канцелярскими
принадлежнастями.

Программное: Использование системы Microsoft
Dynamics CRM 3.0 в качестве связующей среды для работы сотрудников,
взаимодействующих с клиентами корпорации «ИНКОМ-Недвижимость»( единой
базы данных поставщиков, клиентов корпорации),  использование лицензионного ПО
(т.к. антивирусы, брандмауэры, браузеры)

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

3. Проектный
раздел.

3.1
Постановка задачи.

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

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

3.2
Экономическая сущность задачи.

Цель – выдать увольняющемуся сотруднику трудовую
книжку; вход – обходной лист, выход – заполненный обходной лист, трудовая
книжка ; задача не периодична и выполняется по мере необходимости.

3.3
Описание метода решения задачи.

3.4
Описание бизнес-процесса.

Рис. 39
DFD-схема бизнес-процесса «Оформлении и выдача трудовой книжки сотруднику
при увольнении».

Дополнительные
информация и схемы по данной функциональности, расположены в разделе
ПРИЛОЖЕНИЯ, ДОПОЛНИТЕЛЬНЫЕ ЗАДАНИЯ.

Заключение

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

Моделирование бизнес-процессов
организации включает два этапа структурное и детальное.

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

Основу многих современных
методологий моделирования бизнес-процессов составила методология SADT
(Structured Analysis and Design Technique – метод структурного анализа и
проектирования) и алгоритмические языки, применяемые для разработки
программного обеспечения. С помощью методологии семейства IDEF можно эффективно
отображать и анализировать модели деятельности широкого спектра сложных систем
в различных разрезах. Система ARIS представляет собой комплекс средств анализа
и моделирования деятельности предприятия. Ее методическую основу составляет
совокупность различных методов моделирования, отражающих разные взгляды на
исследуемую систему.

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

Список использованных
источников

1.  
Войнов
И. В., Пудовкина С. Г., Телегин А. И. Моделирование экономических систем и
процессов. Опыт построения ARIS-моделей: Монография. – Челябинск: Изд. ЮУрГУ,
2002. – 392 с.

2.  
Волков
О.
Стандарты и методологии моделирования бизнес-процессов. Режим доступа:

Рис. Доп. 1. Классификация документов
агентства недвижимости в рамках IDEF0
модели.

2.   Концептуальная
модель

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

Рис. Доп. 2. Концептуальная модель
совершения платежной транзакции.

3.   Диаграмма
классов

Диаграмма классов оплаты и заказа.

На диаграмме классов, приведенной
ниже, статическая структура описана вокруг главной сущности — Customer
(покупатель), который связан с набором других классов, например Address
(адрес), Order (заказ), и интерфейсом Payment (платеж). У покупателя может быть
несколько Addresses (адресов)  смоделированных агрегированием. Также у
покупателя может быть отношение ассоциации с интерфейсом Payment (платеж) и
классом Order (заказ). Интерфейс Payment (платеж) может быть либо CreditCard
(кредитной картой) либо DebitCard (дебетовой картой), которые являются двумя
реализационными моделями интерфейса Payment (платеж). У каждого заказа может
быть много присоединенных OrderItems (предметов заказа). Так как OrderItem
(предмет заказа) не может существовать без Order (заказ), то отношение
смоделировано как композиция. PrivilegedCustomer (привилегированный покупатель)
это особый Customer (покупатель), у которого есть скидки на сделанные покупки,
и который является продолжением Customer (покупатель) на основе отношения обобщения.
Навигация указывает направление перемещения по ассоциации. Кратность описывает
возможные сущности. .

Рис. Доп. 3. Диаграмма классов заказов и
оплаты различными категориями покупателяй.

4.   Функция
управления созданием объявления

Рис. Доп. 4. Схема составления
объявления.

5.   Взаимосвязь
Организационной структуры агентства недвижимости

Рис. Доп. 5.
Взаимосвязь подразделений

Примечания и заметки