Моделирование бизнес-процессов AS-IS и AS-TO-BE. Реферат Моделирование бизнеспроцессов asis и astobe
 Скачать 398.52 Kb.
|
|
Реферат Моделирование бизнес-процессов AS-IS и AS-TO-BE СодержаниеВведение 1. Описание предметной области 2. Моделирование предметной области 3. Модель AS-IS 3.1 Нотация IDF0 3.2 Нотация IDF3 3.3 Нотация DFD модель процесс бизнес ВведениеМоделирование – это замена реального объекта, процесса, явления его подходящей копией, которая проще изучаемого оригинала, но сохраняет и отражает его существенные особенности с точки зрения цели моделирования и может помочь в изучении оригинала. Моделирование используется в различных областях жизнедеятельности, в частности в экономике. Моделирование бизнес-процесса - процесс отражения субъективного видения потока работ в виде формальной модели, состоящей из взаимосвязанных операций. Общепринято выделяют пять этапов исследования экономических процессов: Идентификации проблемы. Здесь можно выделить следующие основные стадии: формулировка задачи или цели исследования, выявление возможных альтернатив решения применительно к исследуемой ситуации, определение присущих исследуемой системе требований, условий и ограничений. Построения модели. На этом этапе выбирается модель, наиболее подходящая для адекватного описания исследуемой системы. При построении такой модели должны быть установлены количественные соотношения для выражения целевой функции и ограничений в виде функций от управляемых переменных. Решения поставленной задачи с помощью модели. На данном этапе кроме нахождения решения всякий раз, когда это возможно, должно быть обеспечено также получение дополнительной информации о возможных изменениях решения при изменение параметров системы. Эту часть исследования называют анализом модели на чувствительность. Проверки адекватности модели. Модель можно считать адекватной, если, несмотря на некоторые неточности отображения системы-оригинала, она способна обеспечить достаточно надежное предсказание поведения системы. Общий метод проверки адекватности модели состоит в сопоставлении получаемых результатов с характеристиками системы. Если при аналогичных входных параметрах модель достаточно точно воспроизводит поведение системы-оригинала, то она считается адекватной. Реализации результатов исследования. На данном этапе необходимо оформить конечные результаты исследования в виде детальных инструкций, которые должны быть составлены таким образом, чтобы они легко воспринимались лицами, ответственными за управление экономической системой (службой) и обеспечение ее функционирования. Целью моделирования является систематизация знаний о компании и ее бизнес-процессах в наглядной графической форме более удобной для аналитической обработки полученной информации. В настоящее время на рынке компьютерных технологий представлены несколько специальных программ, позволяющих обследовать предприятие и построить модель. Выбор методологии и инструментов, с помощью которых проводится моделирование бизнес-процессов, основополагающего значения не имеет. Существуют стандартизированные, опробованные временем методологии и инструментальные средства, с помощью которых можно обследовать предприятие и построить его модель. Ключевое их преимущество - простота и доступность к овладению. Основу многих современных методологий моделирования бизнес-процессов составила методология SADT. В настоящее время наиболее широко используемая методология описания бизнес-процессов IDEF. Главное достоинство идеи анализа бизнес-процессов предприятия посредством создания его модели - ее универсальность. Во-первых, моделирование бизнес-процессов это ответ практически на все вопросы, касающиеся совершенствования деятельности предприятия и повышения его конкурентоспособности. Во-вторых, руководитель или руководство предприятия, внедрившие у себя конкретную методологию, будет иметь информацию, которая позволит самостоятельно совершенствовать свое предприятие и прогнозировать его будущее. Моделирование бизнес-процессов позволяет проанализировать не только, как работает предприятие в целом, как оно взаимодействует с внешними организациями, заказчиками и поставщиками, но и как организована деятельность на каждом отдельно взятом рабочем месте. Существует несколько подходов к определению понятия «моделирование бизнес-процессов»: 1) моделирование бизнес-процессов - это описание бизнес-процессов предприятия позволяющее руководителю знать, как работают рядовые сотрудники, а рядовым сотрудникам - как работают их коллеги и на какой конечный результат направлена вся их деятельность; 2) моделирование бизнес-процессов - это эффективное средство поиска возможностей улучшения деятельности предприятия; 3) моделирование бизнес-процессов - это средство позволяющее предвидеть и минимизировать риски, возникающие на различных этапах реорганизации деятельности предприятия; 4) моделирование бизнес-процессов - это метод, позволяющий дать оценку текущей деятельности предприятия по отношению к требованиям, предъявляемым к его функционированию, управлению, эффективности, конечным результатам деятельности и степени удовлетворенности клиента; 5) моделирование бизнес-процессов - это метод, позволяющий дать стоимостную оценку каждому процессу, взятому в отдельности, и всем бизнес-процессам на предприятии, взятым в совокупности; 6) моделирование бизнес-процессов - это всегда верный способ выявления текущих проблем на предприятии и предвидения будущих. Современные предприятия вынуждены постоянно заниматься улучшением своей деятельности. Это требует разработки новых технологий и приемов ведения бизнеса, повышения качества конечных результатов деятельности и, конечно, внедрения новых, более эффективных методов управления и организации деятельности предприятий. Бизнес-процесс – это логичный, последовательный, взаимосвязанный набор мероприятий, который потребляет ресурсы производителя, создает ценность и выдает результат потребителю. Среди основных причин, побуждающих организацию оптимизировать бизнес-процессы, можно выделить необходимость снижения затрат или длительности производственного цикла, требования, предъявляемые потребителями и государством, внедрение программ управления качеством, слияние компаний, внутриорганизационные противоречия и др. Моделирование бизнес-процессов – это эффективное средство поиска путей оптимизации деятельности компании, средство прогнозирования и минимизации рисков, возникающих на различных этапах реорганизации предприятия. Этот метод позволяет дать стоимостную оценку каждому отдельному процессу и всем бизнес-процессам организации в совокупности. Решения по моделированию бизнес-процессов обычно принимается по причинам, представленным на приложении.  Моделирование бизнес-процессов затрагивает многие аспекты деятельности компании: - изменение организационной структуры; - оптимизацию функций подразделений и сотрудников; - перераспределение прав и обязанностей руководителей; - изменение внутренних нормативных документов и технологии проведения операций; - новые требования к автоматизации выполняемых процессов. Целью моделирования является систематизация знаний о компании и ее бизнес-процессах в наглядной графической форме более удобной для аналитической обработки полученной информации. Модель должна отражать структуру бизнес-процессов организации, детали их выполнения и последовательность документооборота. Моделирование бизнес-процессов организации включает два этапа структурное и детальное. Данное структурное моделирование бизнес-процесса «Аптеки» было выполнено в нотации IDEF0, IDF3 и DFD с использованием инструментария BPwin. На этапе структурного моделирования в модели должны быть отражены: 1) существующая организационная структура; 2) документы и иные сущности, используемые при исполнении моделируемых бизнес-процессов и необходимые для моделирования документооборота, с описаниями их основного смысла; 3) структуру бизнес-процессов, отражающую их иерархию от более общих групп к частным бизнес-процессам; 4) диаграммы взаимодействия для конечных бизнес-процессов, отражающие последовательность создания и перемещения документов между действующими лицами. Детальное моделирование бизнес-процессов выполняется в той же модели и должно отражать требуемую детализацию и должна обеспечить однозначное представление о деятельности организации. Детальная модель бизнес-процесса должна включать: 1) набор прецедентов отражающих возможные варианты выполнения бизнес-процессов «как есть»; 2) диаграммы действий, детально описывающие последовательность выполнения бизнес-процессов; 3) диаграммы взаимодействия, отражающие схемы документооборота. Модели должны быть согласованы с ведущими специалистами организации, обладающими необходимыми знаниями. В случае если после построения моделей согласование не было достигнуто – в модель должны быть внесены необходимые уточнения и коррективы. Процесс итерации (согласование, внесение корректив и уточнений) должен повторяться до момента полного подтверждения, что модель понятна и однозначно представляет детали бизнес-процессов. 1. Описание предметной областиВ представленной курсовой работе будет рассматриваться работа и функционирование бизнес процессов аптеки. Основным направление аптеки будет являться продажа различных медикаментов посетителям. Аптека не производит никаких лекарств, а лишь является средством распространения разных товаров и оказания консультаций. Основными видами деятельности в аптеке будет продажа лекарств, оказание консультаций посетителям, прием товаров на склад и отпуск товаров без рецепта (т.к. лицензии на отпуск товаров по рецепту не имеется). Аптека будет состоять из следующих элементов: - торговый зал; - склад; - кладовщик; - фармацевты; - бухгалтера; - кассир; - директор. Так как аптека будет заниматься только реализацией сбыта продукции то ей ненужно никаких дополнительных цехов и большого количества складов и оборудования. Существует склад, на который поставляется товар, ведется учет товаров, после чего товары переводятся на витрины, после чего фармацевты продают продукцию, а кассиры выбивают чеки. 2. Моделирование предметной областиМодель — это физический или абстрактный объект, отражающий в той или иной степени процессы в исследуемой системе. Моделированием называется замещение одного объекта, называемого оригинал, другим объектом, называемым моделью, и проведение экспериментов с моделью, исследование свойств модели, опираясь на результаты экспериментов с целью получения информации об оригинале. Основное требование к модели – это её адекватность, под которым понимается степень соответствия процессов, протекающих в модели, процессам, имеющих место, в системе, и, следовательно, степень соответствия свойств и характеристик модели свойствам и характеристикам системы. Адекватность модели зависит от: - степени полноты и достоверности сведений об исследуемой системе; - степени детализации модели; - корректности параметризации модели, под которой понимается установления соответствия между параметрами системы и модели; - уровня подготовки и опыта исследователя. Моделирование в данной курсовой работе производится через программу BPwin. CASE технологии это совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем программного обеспечения, поддержанную комплексом взаимоувязанных средств автоматизации. CASE-технологии предназначены для детального планирования, структурирования и представления описания проектируемой системы в строгом и наглядном виде. Как известно из практики, ошибки проектирования ПО, замеченные только на этапах кодирования или эксплуатации очень дорого стоят как исполнителю, так и заказчику информационной системы. Именно поэтому во всех современных стандартах на производство программного обеспечения столь значимая роль отводится именно этапу планирования. Самыми разработанными на данный момент являются такие стандарты как SPICE и SEI SW-CMM, они сформулированы на основе лучших практик и содержат в себе требования к организации производства программного обеспечения. Сам по себе стандарт SEI SW-CMM подразделяется на 5 уровней зрелости процессов разработки программного обеспечения. Чтобы присвоить компании какой-либо из уровней, ей необходимо соответствовать требованиям этого уровня. Компания, имеющая первый уровень характеризуется как компания, в которой правит «самоорганизующийся хаос». Качество ПО и процессов его разработки на данном уровне является случайной величиной и напрямую зависит от способностей отдельных сотрудников. Присвоение пятого уровня, говорит о том, что компания выполнила все требования предыдущих уровней т.е. добилась повторяемости своих успехов, результат ее деятельности предсказуем, управляющие и прикладные действия по работе над ПО задокументированы, стандартизованы, имеет место точная временная оценка деятельности и точный расчет себестоимости продукта, собраны подробные данные о процессах работы над ПО и компонентах продукции, процессы находятся в управляемом состоянии, ведутся работы над оптимизацией процессов. Существенную помощь в планировании, определении требований к разрабатываемому программному обеспечению, построении модели будущего ПО, оптимизации, стандартизации и в повторении процессов разработки из удачных проектов могут оказать CASE-средства. CASE-средства (от Computer Aided Software/System Engineering) позволяют проектировать любые системы на компьютере. Необходимый элемент системного и структурно-функционального анализа, CASE-средства позволяют моделировать бизнес-процессы, базы данных, компоненты программного обеспечения, деятельность и структуру организаций. Применимы практически во всех сферах деятельности. Результат применения CASE-средств - оптимизация систем, снижение расходов, повышение эффективности, снижение вероятности ошибок. Моделирование деловых процессов, как правило, выполняется с помощью case-средств. К таким средствам относятся BPwin (PLATINUM technology), Silverrun (Silverrun technology), Oracle Designer (Oracle), Rational Rose (Rational Software) и другие Функциональные возможности инструментальных средств структурного моделирования деловых процессов будут рассмотрены на примере case-средства BPwin. BPwin поддерживает три методологии моделирования: функциональное моделирование (IDEF0); описание бизнес-процессов (IDEF3); диаграммы потоков данных (DFD). BPwin имеет достаточно простой и интуитивно понятный интерфейс пользователя. При запуске BPwin по умолчанию появляется основная панель инструментов, палитра инструментов (вид которой зависит от выбранной диаграммы) и, в левой части, навигатор модели — Model Explorer. При создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново или она будет открыта из файла, затем внести имя модели и выбрать методологию, в которой будет построена модель. Как было указано выше, BPwin поддерживает три методологии — IDEF0, IDEF3 и DFD, каждая из которых решает свои специфические задачи. В BPwin возможно построение смешанных моделей, т. е. модель может содержать одновременно диаграммы как IDEF0, так и IDEF3 и DFD. Состав палитры инструментов изменяется автоматически, когда происходит переключение с одной нотации на другую. Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольников, данные — в виде стрелок. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта. Стрелки (Arrow) описывают взаимодействие работи представляют собой некую информацию, выраженную существительными. В IDEF0 различают несколько типов стрелок. Вход (Input) — информация, которая используются или преобразуются работой для получения результата. Управление (Control) — правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая диаграмма должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань диаграммы. Выход (Output) —информация, которая производятся в процессе работы. Каждая диаграмма должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Механизм (Mechanism) — ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и т. д. Стрелка механизма рисуется как входящая в нижнюю грань диаграммы. Вызов (Call) — специальная стрелка, указывающая на другую диаграмму модели. Стрелка вызова рисуется как исходящая из нижней грани работы. Словарь стрелок редактируется при помощи специального редактора Arrow Dictionary Editor, в котором определяется стрелка и вносится относящийся к ней комментарий. Граничные стрелки на контекстной диаграмме служат для описания взаимодействия системы с окружающим миром. Внутренние стрелки. Для связи работ между собой используются внутренние стрелки, то есть стрелки, которые не касаются границы диаграммы, начинаются у одной и кончаются у другой работы. Все работы модели нумеруются. Номер состоит из префикса и числа. Может быть использован префикс любой длины. 3. Модель AS-IS Данная модель позволяет систематизировать протекающие в данный момент процессы, а также используемые информационные объекты. На основе этого выявляются узкие места в организации и взаимодействии бизнес-процессов, определяется необходимость тех или иных изменения в существующей структуре. Такую модель часто называют функциональной и выполняют с использованием различных графических нотаций и case-средств. На этапе построения модели AS-IS важным считается строить максимально приближенную к действительности модель, основанную на реальных потоках процессов, а не на их идеализированном представлении. Проектирование информационных систем и управление процессами подразумевает построение модели AS-IS и дальнейший переход к модели TO-BE, что является залогом автоматизации "правильных", усовершенствованных процессов. Процесс моделирования какой-либо системы в IDEF0 начинается с определения контекста, т. е. наиболее абстрактного уровня описания системы в целом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель. Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами, другими словами, определить компоненты системы и внешние воздействия. На определение субъекта системы существенно влияет позиция, с которой рассматривается система, и цель моделирования - вопросы, на которые построенная модель должна дать ответ. Другими словами, первоначально необходимо определить область моделирования. Описание области как системы в целом, так и ее компонентов является основой построения модели. Цель моделирования. Модель не может быть построена без четко сформулированной цели. Обычно сначала строится модель существующей организации работы - AS-IS (как есть). На основе модели AS-IS достигается консенсус между различными единицами бизнеса по тому, "кто что сделал" и что каждая единица бизнеса добавляет в процесс. Модель AS-IS позволяет выяснить, "что мы делаем сегодня" перед тем, как перейти на то, "что мы будем делать завтра". Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Признаками неэффективной деятельности могут быть бесполезные, неуправляемые и дублирующиеся работы, неэффективный документооборот оказывается в нужном месте в нужное время, отсутствие обратных связей по управлению и т. д. Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) - модели новой организации бизнес-процессов. Модель нужна ТО-ВЕ для анализа альтернативных/лучших путей выполнения работы и документирования того, как компания будет делать бизнес в будущем. 3.1 Нотация IDF0Наиболее популярная нотация моделирования бизнес-процессов, основанная на методологии структурного анализа SADT. Бизнес-процессы в нотации IDEF0 представляются в форме прямоугольника, а стрелки отражают связь с другими процессами и внешней средой. Особенностью нотации является: Возможность декомпозировать процессы на подпроцессы и, таким образом, строить иерархические модели бизнес-процессов. Выделение четыре типов стрелок: три типа входов — вход, управление и механизм (это позволяет более гибко описывать логику использования входов в процессе в целях последующего анализа), и выход. Для IDEF0 имеет значение сторона процесса и связанная с ней стрелка: - слева входящая стрелка – вход бизнес-процесса – информация (документ) или ТМЦ, который будет преобразован в ходе выполнения процесса; - справа исходящая стрелка – выход бизнес-процесса – преобразованная информация (документ) или ТМЦ; - сверху входящая стрелка – управление бизнес-процесса – информация или документ, который определяет как должен выполняться бизнес-процесс, как должно происходить преобразование входа в выход; - снизу входящая стрелка – механизм бизнес-процесса – то, что преобразовывает вход в выход: сотрудники или техника. Считается, что за один цикл процесса не происходит изменения механизма. Нотация IDEF0 используется для создания верхнего уровня модели бизнес-процессов, на нижнем уровне для описания алгоритма (сценария) выполнения процесса допускается смена нотации на нотацию процесс или процедура. 3.2 Нотация IDF3Этот метод предназначен для моделирования последовательности выполнения действий и взаимозависимости между ними в рамках процессов. Модели IDEF3 могут использоваться для детализации функциональных блоков IDEF0, не имеющих диаграмм декомпозиции. Диаграммы IDEF3 отображают действие в виде прямоугольника. Действия именуются с использованием глаголов или отглагольных существительных, каждому из действий присваивается уникальный идентификационный номер. Все связи в IDEF3 являются однонаправленными и организуются слева направо. Типы связей IDEF3: - Временное предшествование (Temporal precedence), простая стрелка. Исходное действие должно завершиться, прежде чем конечное действие сможет начаться. - Объектный поток (Object flow), стрелка с двойным наконечником. Выход исходного действия является входом конечного действия. Исходное действие должно завершиться, прежде чем конечное действие сможет начаться. Наименования потоковых связей должны чётко идентифицировать объект, который передается с их помощью. - Нечеткое отношение (Relationship), пунктирная стрелка. Завершение одного действия может инициировать начало выполнения сразу нескольких других действий, или наоборот, определенное действие может требовать завершения нескольких других действий до начала своего выполнения (ветвление процесса). Нотация IDEF3 чаще применяется для построения процессов нижнего уровня, могут также использовать при декомпозиции блоков процесса IDEF0. В отличие от IDEF0 данная нотация не поддерживает отображение «механизмов» и «управления», зато отображает очередность выполнения работ персоналом. Несмотря на схожесть с нотацией FlowChart, имеет некоторые существенные отличия. Во-первых, весь процесс строится не сверху вниз, а слева направо и при этом, как правило, ограничен количеством используемых блоков на одну диаграмму. Во-вторых, нотация изначально предназначалась для технических специалистов, поэтому содержит специальные перекрёстки, такие как, «XOR», «Synchronous OR», «Asynchronous OR», «Synchronous AND» и «Asynchronous AND», знакомые программистам, но требующие дополнительное пояснения менеджерам предприятия. Данная нотация предназначена для описания работ в случаях необходимости отражения логической последовательность их выполнения. Основные объекты нотации: - Работа (Activity). Отображает функции (процессы, работы) - Стрелки (Arrows). Отображают взаимоотношения работ - Перекрестки (Junction). Отображают логику взаимодействия стрелок в перекрестках используются логические операторы «И», «ИЛИ», исключающее «ИЛИ» - Объект ссылки (Referent). Отображает идею, концепцию или данные, которые нельзя связать со стрелкой, перекрестком или работой 3.3 Нотация DFDЦель такого представления — продемонстрировать, как каждый процесс преобразует свои входные данные в выходные. Может отражать не только информационные, но и материальные потоки. Также, как и в других моделях, поддерживается декомпозиция. Основными компонентами диаграмм потоков данных являются: - Внешние сущности (материальный объект или физическое лицо, являющиеся источником или приёмником информации, например, заказчики, персонал, поставщики, клиенты, склад). - Системы и подсистемы (например, подсистема по работе с физическими лицами). - Процессы (преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом; физически это может быть, например, подразделение организации (отдел), выполняющее обработку входных документов и выпуск отчетов, программа, аппаратно реализованное логическое устройство и т.д.). - Накопители данных (абстрактные устройства для хранения информации). Необходимо размещать на каждой диаграмме от 3 (меньше нет смысла) до 7 (больше - не воспринимаемо) процессов, не загромождая диаграммы несущественными на данном уровне деталями. Первым шагом при построении иерархии DFD является построение контекстных диаграмм. Обычно при проектировании относительно простых систем строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соединенный с приемниками и источниками информации. Для сложных систем (десять и более внешних сущностей, распределенная природа и многофункциональность системы) строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных. Каждый процесс на DFD может быть детализирован при помощи DFD или (если процесс элементарный) спецификации. Спецификации представляют собой описания алгоритмов задач, выполняемых процессами. Языки спецификаций могут варьироваться от структурированного естественного языка или псевдокода до визуальных языков моделирования. При моделировании бизнес-процессов диаграммы потоков данных (DFD) используются для построения моделей "AS-IS" и "AS-TO-BE", отражая, таким образом, существующую и предлагаемую структуру бизнес-процессов организации. |