курсач бизнес

Министерство образования и науки Российской Федерации
государственное образовательное учреждение высшего профессионального образования
«ПОВОЛЖСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ СЕРВИСА»
Кафедра: «Прикладная информатика в экономике»
Курсовая работа
по дисциплине: «Бизнесреинжиниринг»
на тему: «Проведение бизнесреинжиниринга в отделе продаж промышленного
предприятия»
Выполнил: Одинцова Г.
Группа: ИК-402
Руководитель:
Филиппова О.А.
Тольятти, 2012 г.
СОДЕРЖАНИЕ
ВВЕДЕНИЕ ....................................................................................................................................3
1. АНАЛИТИЧЕСКАЯ ЧАСТЬ ....................................................................................................5
1.1. Имитационное моделирование.............................. Ошибка! Закладка не определена.
ЗАКЛЮЧЕНИЕ............................................................................................................................23
СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ .........................................................................24
ВВЕДЕНИЕ
На современном этапе социально-экономических трансформаций в России
реформирование
промышленных
предприятий
остается
одним
из
приоритетных
направлений.
Необходимость в преобразованиях обусловлена не только текущим состоянием
российских реформ, но и глубокими переменами в мировой экономике, которые
проявляются в объективных процессах глобализации, усилении влияния информационных
технологий, повышении скорости бизнес-процессов, возникновении новых типов
организационных структур и хозяйственных связей.
В настоящее время идет активное развитие концепций реформирования, наиболее
полно учитывающих эти перемены. Одной из таких концепций является реинжиниринг
бизнес-процессов (РБП). Мировой, в том числе и российский, опыт его проведения
показал, что наряду с положительными результатами реинжиниринг характеризуется
высокой степенью риска, которая отчасти обусловлена выбором методической основы,
несоответствующей специфике и масштабам РБП. В этой связи критический анализ и
дальнейшее
развитие
теоретико-методологических
положений
проведения
бизнесреинжиниринга является актуальным.
Цель курсовой работы состоит в проведение бизнесреинжиниринга в отделе
продаж промышленного предприятия.
Для достижения указанной цели были поставлены и решены следующие задачи:
• изучить теоретические основы по проведению бизнесреинжиниринга;
• идентифицировать бизнес-процессы отдела продаж предприятия;
• изучить методику структурно-функционального моделирования и построить
необходимые модели с помощью BpWin;
• провести функционально-стоимостной анализ;
• разработать модели: прецедентов использования, объектную и взаимодействия
объектов для выбранной предметной области.
Практическая
значимость
курсовой
работы
определяется
возможностью
использовать выводы, сделанные в исследовании для успешного изменения и проведения
РБП, реорганизации системы управления в конкретной компании.
Предметом курсовой работы являются этапы реинжиниринга бизнес-процессов.
Объектом изучения выступает
отдел продаж
промышленного предприятия
с
непрерывным типом производства и широкой номенклатурой выпускаемой продукции.
Моделирование бизнес-процессов идет путём создания их моделей, которые
позволяют провести многовариантный анализ ситуации или процесса и разработать для
реализации оптимальный план действий.
Совокупность цели и задач обусловили структуру курсового проекта, которая
состоит из введения, трех глав основной части, заключения, библиографического списка,
включающего 26 источников.
1. АНАЛИТИЧЕСКАЯ ЧАСТЬ
1.1 Сущность процессного подхода
Процессный подход является важнейшей составной частью системно-целевого
подхода. Он предполагает структуризацию системы процессов и дальнейшую работу с
ней с использованием CASE-средств.
Процессный подход – особое динамическое мышление, способ видения в рамках
системно-целевого подхода, который объединяет семь подходов: системный, целевой,
процессный, ситуационный, функциональный, синергетический и миросистемный [5,
С.106].
В данном случае динамическое мышление раскрывается с учетом, прежде всего,
системного, целевого и процессного подходов.
Процесс – последовательная, логически упорядоченная смена (во времени и
пространстве) следующих друг за другом моментов (стадий) функционирования или
развития [5, С.108].
Сущностная характеристика категории «процесс» связана с динамическим
описанием потока событий, то есть изменением моделируемых явлений в пространстве и
во времени. Рациональная структура процесса всегда определяется исходя из целей его
«выхода».
Кроме
традиционно
упоминаемых
«входов»
(входные
ресурсы),
«преобразований», «выходов» и «обратных связей», важны также «правила» и
«механизмы» реализации процесса.
Системный подход предполагает следующие требования к раскрытию содержания
процессного подхода [14, С.92]:
–
определение любого процесса как системы, то есть определение его элементов
{а}, системных отношений R и проявляющихся при этом системных свойств Р;
–
рассмотрение целостной системы процессов, то есть их синтез.
Рассматривая с позиций системного подхода процесс (Пр) как систему Пр <=>
[{a}R]P, следует далее расчленить его составляющие («входы», «преобразования»,
«выходы») на элементы, компоненты, подсистемы.
Системные отношения R – это, прежде всего, отношения обратной связи. Вместе с
тем для эффективного управления необходимо налаживать:
–
отношения взаимосодействия, формируемые на основе согласования целей
участников
цепочки
ценностей
потребителей готовой продукции);
–
рефлексивные отношения;
(поставщиков
ресурсов,
их
переработчиков
и
–
конкурентные отношения между участниками различных стадий цепочки
ценностей;
–
отношения между самими бизнес-процессами на различных иерархических
уровнях организации (по оси Sh).
Можно выделить следующие системные свойства Р отдельного бизнес-процесса, а
также системы бизнес-процессов в целом: эффективность, целостность, надежность,
управляемость, самоорганизованность и другие.
Цель процессного подхода – создание эффективного менеджмента системы
процессов, обеспечивающего сбалансированность показателей организации.
Чтобы управлять процессами, необходимо понимать, чем управлять. Сначала
необходимо обеспечить описание процесса, представить его в виде определенной модели.
Модель – материально или мысленно представляемый объект, который в процессе
исследования замещает объект-оригинал таким образом, что его непосредственное
изучение дает новые знания об объекте-оригинале.
Модель бизнес-процесса – это упрощенное отображение реального объекта в виде
графического, табличного, текстового, символьного описания бизнес-процесса либо их
взаимосвязанной совокупности.
Моделирование бизнес-процессов – упрощенное отражение субъективного видения
реально существующих в организации процессов с использованием графических,
табличных,
текстовых
способов
представления
(ИСО
9000:2000),
дающее
дополнительную информацию [17, С.62].
Моделирование бизнес-процесса начинают с построения существующей модели
организации работы – AS-IS («как есть»), которая позволяет выявить его «узкие» места и
недостатки.
Цель построения модели AS-IS – выявление ненужных и неэффективных работ,
дублируемых, неуправляемых и не обеспеченных ресурсами работ. Устранение подобных
«узких» мест приводит к построению модели ТО-ВЕ («как будет»), отражающей новую
организацию бизнес-процессов. Данная модель должна быть многовариантной. Подробно
модели AS-IS и ТО-ВЕ рассмотрены ниже.
Так как процессный подход официально заложен в основу построения системы
менеджмента качества организации ИСО 9000:2000, то это обстоятельство еще более
усиливает актуальность совершенствования системы процессов предприятия, а также ее
сертификации.
С внедрением процессного подхода (в рамках СЦеП-методологии) открываются
следующие возможности.
Каждому из структурированных бизнес-процессов можно поставить в соответствие
определенную цель и на этой основе обеспечить целостность системы, сделать ее
прозрачной для руководства и способной гибко реагировать на изменение SWOTфакторов посредством соответствующих решений.
На основе процессного подхода может осуществляться оптимизация системы
корпоративного управления путем реинжиниринга бизнес-процессов и принятия системы
эффективных решений.
Структуризация бизнес-процессов позволяет выделять среди них наиболее
результативные
и
на
этой
основе
поэтапно
формировать
систему
команд,
ориентированных на соответствующие целевые показатели каждого бизнес-процесса.
Процессный подход дает возможность получать и использовать систему
показателей и критериев оценки эффективности управления на каждом этапе
производственной
(управленческой)
цепочки
и,
таким
образом,
осуществлять
стимулирование и мотивацию участников основных бизнес-процессов.
Разработанная и внедренная система управления бизнес-процессами обеспечивает
получение соответствующего сертификата и реализацию процессного подхода в
организации в соответствии с требованиями ИСО 9000:2000.
Внедрение процессного подхода в управление и построение системы менеджмента
качества гарантирует четко определенный порядок и ответственность за разработку,
согласование, утверждение и ведение документации [17, С.67].
В целом система направлена на удовлетворение пяти групп лиц, заинтересованных
в деятельности организации: соучредителей (инвесторов); потребителей на рынке;
персонала организации; поставщиков; общества в целом.
В результате обследования предприятия в системе бизнес-процессов выявляются
«узкие» места – ненужные, неэффективные и дублирующие работы, а также работы, не
обеспеченные ресурсами. Функциональная модель существующей организации работы –
AS-1S («как есть») – строится с помощью CASE-средств, например программного
продукта BPwin. При ее построении используются такие источники, как опросы экспертов
(работников предприятия), документация (приказы, отчеты, должностные инструкции,
положения о структурных подразделениях предприятия), анкетирование, фотография
рабочего дня и др. Анализ функциональной модели позволяет [20, С.36]:
–
специалистам, выполняющим работу по реинжинирингу, выявить недостатки
существующего бизнеса и определить те области, в которых стоит производить
изменения;
–
понять, как следует изменить бизнес-процессы, чтобы они удовлетворяли
новым требованиям и целям;
–
оценить,
насколько
глубоким
изменениям
подвергнется
существующая
структура организации бизнеса;
–
объяснить сотрудникам, чем плохи прежние процедуры работы и почему они
должны быть приспособлены к новым способам работы;
–
измерить характеристики тех бизнес-процессов, которые следует изменить.
Полученные измерения в дальнейшем могут быть использованы для оценки
экономического эффекта проведенных изменений.
Структуризация бизнес-процессов позволяет выявить недостатки организации даже
там, где функциональность на первый взгляд
кажется очевидной. Признаком
неэффективной деятельности могут быть бесполезные, неуправляемые и дублируемые
работы, неэффективный документооборот (нужный документ не оказывается в нужном
месте в нужное время), отсутствие обратных связей по управлению (на проведение работы
не оказывает влияния ее результат) и «входу» (объекты или информация используются
нерационально) и так далее.
Одной из ошибок при создании модели AS-IS является создание идеализированной
модели. Это происходит в том случае, когда модель создается на основе знаний
руководителя, а не на основе опыта конкретного исполнителя работ. Руководитель в
теоретическом аспекте осведомлен о том, как в соответствии с руководствами и
должностными инструкциями предполагается выполнение работы, но часто не знает, как
на самом деле подчиненные выполняют рутинные работы. В результате получается
приукрашенная, искаженная модель, которая несет ложную информацию и которую
невозможно в дальнейшем использовать для анализа. Такая модель называется SHOULD
BE («как должно бы быть»).
Обнаруженные в модели AS-IS недостатки можно исправить при создании модели
ТО-ВЕ («как будет») – модели новой организации бизнес-процессов. Модель ТО-ВЕ
нужна для оценки последствий внедрения информационной системы и анализа
альтернативных, лучших путей выполнения работы и документирования того, как
предприятие будет функционировать в будущем.
Как правило, строится несколько моделей ТО-ВЕ, представленная на рисунке 1.1,
отображающих возможные траектории движения из существующего состояния системы
бизнес-процессов в будущие состояния. В соответствии с идеологией стрелы
целеполагания возможны следующие траектории:
– ТО-ВЕ 1 – оптимистический вариант структуризации бизнес-процессов,
связанный с реинжинирингом;
– ТО-ВЕ 2 – наиболее вероятные варианты совершенствования БПр (в рамках
инжиниринга);
– ТО-ВЕ 3 – пессимистический вариант изменений бизнес-процессов, связанный с
учетом негативных SWOT-факторов.
Рис. 1.1. Построение моделей ТО-ВЕ как результат анализа модели AS-IS
Наибольший интерес представляет траектория 1, связанная с реинжинирингом
бизнес-процессов.
Реинжиниринг
–
фундаментальное
переосмысление
и
радикальное
перепроектирование бизнес-процессов для достижения существенных улучшений в таких
ключевых для современного бизнеса показателях результативности, как затраты, качество,
уровень обслуживания и оперативность [4, С.112
Имеется в виду не небольшое усовершенствование бизнес-процессов компаний,
например на 10–100%, а кардинальное повышение их эффективности, т.е. на порядок, что
приводит к скачку результата.
Радикальное перепроектирование означает перепроектирование, затрагивающее
суть (корень) явлений, а не поверхностные изменения, т.е. в ходе радикального
перепроектирования отбрасываются все существующие структуры и процедуры и
предлагается совершенно новый способ выполнения работы. Итак, реинжиниринг – это
изобретение принципиально новых вариантов, а не улучшение, увеличение или
модификация.
Реинжиниринг бизнес-процессов необходимо проводить комплексно, в рамках
стратегии, самоорганизующейся в соответствии с финишными целями предприятия.
Радикальному перепроектированию должны быть подвергнуты:
–
система производства, включающая технологию производства продукции,
номенклатуру и качество предлагаемых товаров, при этом требуется постоянная
ориентация на потребителей;
–
система
управления,
включающая
структуру
организации,
функции,
нормативно-организационные документы и так далее.
Модели AS-IS и ТО-ВЕ позволяют описать начальное и конечное состояния
предприятия – до и после внедрения корпоративной информационной системы, оставляя
без внимания сам процесс разработки (выбора) и внедрения. Но поскольку внедрение
информационной системы – это тоже работа, то с помощью BPwin можно создать ее
модель. Модель ТО-ВЕ – это не модель работы предприятия, а модель мероприятий по
переводу его на новую технологию деятельности. Использование модели ТО-ВЕ в
совокупности со стоимостным анализом позволяет оценить объем средств, необходимых
для приобретения, разработки и внедрения информационной системы. Можно построить
несколько различных моделей ТО-ВЕ с учетом внедрения различных информационных
систем (как готовых, так и созданных на заказ) и выбрать оптимальный вариант.
Технология проектирования информационных систем также подразумевает
создание модели AS-IS, её анализ и улучшение бизнес-процессов, т.е. создание модели
ТО-ВЕ. Только на основе модели ТО-ВЕ строятся модель данных, прототип, а затем и
окончательный вариант информационной системы. Результатом построения системы на
основе модели AS-IS является автоматизация предприятия по принципу «все оставить как
есть, только чтобы компьютеры стояли», то есть информационная система автоматизирует
несовершенные
бизнес-процессы
и
дублирует,
а
не
заменяет
существующий
документооборот. Внедрение и эксплуатация такой системы приводят лишь к
дополнительным
издержкам
на
закупку
оборудования,
создание
программного
обеспечения и сопровождение того и другого.
1.2 Бизнес-процесс и организация его управления
Из множества процессов люди чаще всего сталкиваются с бизнес-процессами.
Бизнес-процесс - совокупность взаимосвязанных и взаимодействующих видов
деятельности, преобразующая «входы» в «выходы», представляющие ценность для
клиента (ИСО 9000:2000).
Бизнес-процесс – это множество внутренних шагов (видов) деятельности,
начинающихся с одного или более «входов» и заканчивающихся созданием продукции,
необходимой клиенту [17, С.32].
Другое интересное определение процесса связано с понятием «потока ценностей»,
введенным Дж. Мартином.
Поток ценностей, согласно Дж. Мартину, – это множество законченных
состыкованных действий, которые в совокупности создают некоторую продукцию,
имеющую потребительскую ценность для клиента [17, С.33].
Дж. Мартин отказался от термина «процесс», поскольку последний, по его мнению,
имеет слишком много различных значений, что может приводить к недоразумениям.
Еще одно определение бизнес-процесса дает Т. Давенпорт.
Бизнес-процесс – это специфически упорядоченная совокупность работ, заданий во
времени и в пространстве, с указанием начала и конца и точным определением «входов» и
«выходов» (в виде продукции и услуг, необходимых клиенту) [17, С.33].
«Входы» и «выходы» процесса могут взаимодействовать как с конкретным
клиентом, так и с некоторым другим процессом во внешнем окружении компании, но не с
другим внутренним процессом.
«Вход» бизнес-процесса – ресурс, необходимый для выполнения бизнес-процесса.
«Выход» бизнес-процесса – результат (продукт, услуга) выполнения бизнеспроцесса.
Ресурсы
–
информация,
финансы,
материалы,
персонал,
оборудование,
инфраструктура, среда, программное обеспечение, необходимые для выполнения бизнеспроцесса.
Назначение каждого бизнес-процесса состоит в том, чтобы предложить клиенту
товар или услугу, то есть продукцию, удовлетворяющую его по стоимости, качеству и
сервису. Термин «клиент» следует понимать в широком смысле. Это может быть как
действительный клиент, так и процесс, протекающий во внешнем окружении компании,
например у партнеров, или субподрядчиков.
При рассмотрении процессов возникают следующие сложности. Процессы не
удается описывать так же легко, как, например, организационные иерархические
структуры. У организационных подразделений есть «имена» («производство продукции»,
«доставка продукции»), с ними связаны ответственные должностные лица («президент»,
«начальник подразделения»). Процессы же обычно невидимы, не имеют описаний и имен.
Однако понятие «процесс» возникает более естественным образом, чем организационные
иерархии, тогда, когда люди кооперируются для достижения обещанного клиенту
результата. При традиционной структуре внимание фокусируется на заданиях, работах,
людях, структурах, но не на процессах, хотя процессы пронизывают традиционные
организационные структуры.
Чтобы было проще рассуждать о процессах компании, им можно дать
описательные имена-характеристики. Так, например, М. Хаммер и Дж. Чампи предлагают
именовать процессы в соответствии с их начальным и конечным статусом, например:
«разработка продукта: от требований на продукт – к продукту» или «продажа: от заявки –
к заказу». Такие имена позволяют отделить процессы от подразделений. Для именования
процессов целесообразно использовать отглагольные формы, чтобы отличать их от имен
подразделений.
Для обозначения процесса часто используется понятие «5М» – пять составляющих
частей процесса, которые представлены на рисунке 1.2: method– технология; man –
персонал; machinery – оборудование; material – материалы; ип Milieu ouvrier –
производственная среда.
Материалы
Технология
Персонал
Вход
Выход
Процесс
Оборудование
Производственная среда
Рис. 1.2. Пять составляющих процесса
При более подробной декомпозиции 5М можно разбить на 12 составляющих
процесса. Для того чтобы процесс протекал в управляемых условиях, в распоряжении
владельца процесса должны быть все составляющие: технология, персонал, оборудование,
оснастка и инструменты, контрольно-измерительное и испытательное оборудование,
нормативная
документация,
основные
материалы,
вспомогательные
материалы,
производственная среда, теплоэнергоносители, программное обеспечение, информация.
Данный список можно варьировать, уменьшать или дополнять в зависимости от
специфики процесса, но в основном это те составляющие, без которых не может
состояться процесс. Составляющие процесса, которыми управляет владелец, являются
ресурсами. Все ресурсы, необходимые для проведения процесса, должны быть
запланированы и выделены до начала проведения процесса.
1.3. UML-диаграммы
UML (англ. Unified
Language —
Modeling
моделирования) — язык графического описания
унифицированный
для объектного
язык
моделирования в
областиразработки программного обеспечения. UML является языком широкого профиля,
это открытый
стандарт,
использующий
графические
обозначения
для
создания абстрактной модели системы, называемой UML-моделью. UML был создан для
определения,
визуализации,
проектирования
и
документирования,
в
основном,
программных систем. UML не является языком программирования, но в средствах
выполнения UML-моделей как интерпретируемого кода возможна кодогенерация.
Система
объектно-ориентированных
моделей
в
соответствии
с
нотациями
унифицированного языка моделирования UML включает в себя следующие диаграммы:
1) диаграмму прецедентов использования, которая отображает функциональность
ЭИС в виде совокупности выполняющихся последовательностей транзакций;
2) диаграмму классов объектов, которая отображает структуру совокупности
взаимосвязанных
классов
объектов
аналогично
ER-диаграмме
функционально-
ориентированного подхода;
3) диаграммы состояний, каждая из которых отображает динамику состояний
объектов одного класса и связанных с ними событий;
4) диаграммы
взаимодействия
объектов,
каждая
из
которых
отображает
динамическое взаимодействие объектов в рамках одного прецедента использования;
5) диаграммы
деятельностей,
которые
отображают
потоки
работ
во
взаимосвязанных прецедентах использования (могут декомпозироваться на более
детальные диаграммы);
6) диаграммы
пакетов,
которые
отображают
распределение
объектов
по
функциональным или обеспечивающим подсистемам (могут декомпозироваться на более
детальные диаграммы);
7) диаграмму компонентов, которая отображает физические модули программного
кода;
8) диаграмму размещения, которая отображает распределение объектов по узлам
вычислительной сети.
Диаграмма прецедентов
—
диаграмма, на которой
существующие между актёрами и прецедентами.
отражены отношения,
Основная задача — представлять собой единое средство, дающее возможность
заказчику,
конечному
пользователю
и
разработчику
совместно
обсуждать
функциональность и поведение системы.
При работе с вариантами использования важно помнить несколько простых правил:
- каждый прецедент относится как минимум к одному действующему лицу;
- каждый прецедент имеет инициатора;
- каждый прецедент приводит к соответствующему результату (результату с
«бизнес-значением»).
Диаграмма классов (Class diagram) — статическая структурная диаграмма,
описывающая структуру системы, она демонстрирует классы системы, их атрибуты,
методы и зависимости между классами.
Существуют разные точки зрения на построение диаграмм классов в зависимости
от целей их применения:
концептуальная точка зрения — диаграмма классов описывает модель предметной
области, в ней присутствуют только классы прикладных объектов;
точка
зрения
спецификации
—
диаграмма
классов
применяется
при
проектировании информационных систем;
точка зрения реализации — диаграмма классов содержит классы, используемые
непосредственно в программном коде (при использовании объектно-ориентированных
языков программирования).
Диаграмма состояний отображает поведение объектов одного класса в динамике,
связь состояний объектов с событиями и определяет:
 какие типичные состояния проходит объект;
 какие события ведут к изменению состояния объекта;
 какие действия объект выполняет, когда он получает сообщение об изменении
состояния;
 как объекты создаются и уничтожаются (входные и выходные точки диаграммы).
Входная точка определяет событие, которое образует начальное состояние объекта.
В точку входа нельзя перейти из состояния объекта.
Диаграмма взаимодействия объектов заключается в том, что для каждого прецедента
использования может быть построена модель динамического взаимодействия объектов,
которая представляется в одной из двух форм:
 в форме диаграммы последовательностей, показывающей последовательность
взаимодействий на графе;
 в форме кооперативной диаграммы, показывающей взаимодействие объектов в
табличной форме.
Диаграмма деятельности англ.— диаграмма, на которой показано разложение
некоторой деятельности на её составные части. Под деятельностью англ. activity
понимается
спецификация
исполняемого
поведения
в
виде
координированного
последовательного и параллельного выполнения подчинённых элементов — вложенных
видов деятельности и отдельных действий англ. action, соединённых между собой
потоками, которые идут от выходов одного узла ко входам другого.
Диаграммы деятельности используются при моделировании бизнес-процессов,
технологических процессов, последовательных и параллельных вычислений.
Диаграммы пакетов унифицированного языка моделирования (UML) отображают
зависимости между пакетами, составляющими модель. Диаграммы пакетов могут
использовать пакеты, содержащие прецеденты для иллюстрации функциональности
программного обеспечения системы. Диаграммы могут использовать пакеты, которые
представляют различные слои программного комплекса для иллюстрации его слоистой
архитектуры. Зависимости между этими пакетами могут быть снабжены метками /
стереотипами, чтобы указать механизм связи между слоями.
Диаграмма
компонентов
-
статическая
структурная
диаграмма,
показывает
разбиение программной системы на структурные компоненты и связи (зависимости)
между компонентами. В качестве физических компонентов могут выступать файлы,
библиотеки, модули, исполняемые файлы, пакеты и т. п.
Компоненты связываются через зависимости, когда соединяется требуемый
интерфейс одного компонента с имеющимся интерфейсом другого компонента. Таким
образом иллюстрируются отношения клиент-источник между двумя компонентами.
Зависимость показывает, что один компонент предоставляет сервис, необходимый
другому компоненту. Зависимость изображается стрелкой от интерфейса или порта
клиента к импортируемому интерфейсу.
Когда диаграмма компонентов используется, чтобы показать внутреннюю структуру
компонентов, предоставляемый и требуемый интерфейсы составного компонента могут
делегироваться в соответствующие интерфейсы внутренних компонентов.
Диаграмма размещения (deployment diagram) отражает физические взаимосвязи
между программными и аппаратными компонентами системы. Она является хорошим
средством для того, чтобы показать маршруты перемещения объектов и компонентов в
распределенной системе.
Каждый узел на диаграмме размещения представляет собой некоторый тип
вычислительного устройства, в большинстве случаев – часть аппаратуры. Эта аппаратура
может быть простым устройством или датчиком, а может быть и мэйнфреймом.
1.4. Понятие объектно-ориентированного проектирования и
программирования
Объектно-ориентированное программирование и проектирование применяется в
экономических информационных системах, как правило, для решения следующих типов
задач:
 разработка
информационных
программирования,
систем
использование
в
объектно-ориентированной
встроенных
объектов
и
среде
разработка
собственных классов;
 автоматизация
процессов,
содержащих
динамические
взаимодействующие
объекты;
 моделирование динамических взаимодействующих объектов в подсистемах
поддержки
принятия
решений,
в
частности
для
задач
имитационного
моделирования.
В основе объектно-ориентированного языка программирования лежат два основных
понятия: класс и объект.
Объект - особый опознаваемый предмет, блок или сущность (реальная или
абстрактная), имеющая важное функциональное назначение в данной предметной
области.
Объект может быть охарактеризован структурой, его состоянием, поведением и
индивидуальностью. Состояние объекта определяется перечнем всех возможных (обычно
статических) свойств и текущими значениями (обычно динамическими) каждого из этих
свойств. Свойства объекта характеризуются значениями его параметров. Поведение
объекта описывает, как объект воздействует на другие объекты или как он подвергается
воздействию со стороны других объектов с точки зрения изменения его собственного
состояния и состояния других объектов. Говорят также, что поведение объекта
определяется его действиями. Определенное воздействие одного объекта на другой с
целью
вызвать
соответствующую
реакцию
называют
операцией.
ориентированных языках программирования операции называют методами.
Можно выделить пять типов операций:
В
объектно-
- конструктор, создание и инициализация объекта;
- деструктор, разрушающий объект;
- модификатор, изменяющий состояние объекта;
- селектор для доступа к переменным объекта без их изменения;
- итератор для доступа к содержанию объекта по частям в определенной
последовательности.
Основными характеристическими свойствами объекта являются:
Инкапсуляция
-
комбинирование
записей
с
процедурами
и
функциями,
манипулирующими полями этих записей, формирует новый тип данных - объект (под
записью понимается переменная типа "запись").
Наследование - определение объекта и его дальнейшее использование для
построения иерархии порожденных объектов с возможностью для каждого порожденного
объекта, относящегося к иерархии, доступа к коду и данным всех порождающих объектов.
Полиморфизм - присваивание действию одного имени, которое затем совместно
используется вниз и вверх по иерархии объектов, причем каждый объект иерархии
выполняет это действие способом, именно ему подходящим.
В класс объединяются объекты с одинаковыми свойствами и методами.
Одним из первых действий, предпринимаемых человеком при попытке понять
окружающий мир, является применение к нему некоторой структурной формы. При
встрече с неизвестным объектом мы пытаемся втиснуть его в нашу существующую
структуру: другими словами, классифицировать его. Большинство людей знакомо по
крайней мере с несколькими классификационными структурами или иерархиями.
Объектно-ориентированное проектирование (Object-Oriented Design - OOD) - это
поступательный итеративный процесс. Граница между объектно-ориентированным
анализом и проектированием расплывчата и построение проекта программного изделия
состоит из ряда циклов, в которых уточняются описания классов и взаимодействия между
ними, разрабатываются реализующие их программы, проводится их отладка и
тестирование и по результатам каждого этапа уточняются рабочие документы
предыдущих этапов, дорабатываются описания классов и программы. Эти циклы
повторяются до получения требуемого результата.
В обобщенном виде процесс объектно-ориентированного проектирования состоит из
циклического выполнения четырех основных шагов:
- Определение классов и объектов на определенном уровне абстракции.
- Определение семантики классов.
- Определение (идентификация) связей между классами и объектами.
- Реализация классов.
На
каждом
повторении
этого
цикла
уточняются
описания
классов
и
перерабатываются проектные документы.
1.3 Методы моделирования в BPwin
BPwin автоматизирует задачи, связанные с построением моделей развития,
обеспечивая семантическую строгость, необходимую для гарантирования правильности и
непротиворечивости результатов.
Применение методологий BPwin в ходе построения моделей бизнес-процессов в
виде иерархии диаграмм, обеспечивает наглядность и полноту их отображения, позволяет
анализировать деятельность предприятия в трех информационных разрезах:
Первый информационный разрез – функциональность системы. В рамках
методологии IDEF0 бизнес-процесс представляется в виде набора элементов-работ,
которые
взаимодействуют
материальными
потоками
между
с
собой,
помощью
обмениваясь
людских
и
информационными
производственных
и
ресурсов,
потребляемых каждой работой. С помощью функционального моделирования можно
провести системный анализ бизнеса, сосредоточившись на регулярно решаемых задачах
или функциях, на показателях их правильного выполнения, необходимых для этого
ресурсах, результатах и исходных материалах (сырье).
Первая
диаграмма
в
иерархии
диаграмм
IDEF0
всегда
изображает
функционирование системы в целом. Такие диаграммы называются контекстными.
Отметим, что в теоретической части курсового проекта не будут приводиться
рисунки, характеризующие модели построенные с помощью средства BPwin. Все
диаграммы наглядно представлены в практической части работы.
Некоторых руководителей, впервые увидевших контекстную диаграмму своего
бизнес-процесса, она вводит в недоумение – «И это все?». Однако за внешней простотой
скрывается вся суть бизнес-процесса. Вся входящая и исходящая информация, источники
и результаты, механизмы агрегированы настолько, что позволяют осмыслить их в целом.
В контекст входит описание цели моделирования, области моделирования, то есть
описания того, что будет рассматриваться как компонент системы, а что как внешнее
воздействие и точки зрения – позиции, с которой будет строиться модель. Обычно в
качестве точки зрения выбирается точка зрения лица или объекта, ответственного за
работу моделируемой системы в целом.
После того как контекст описан, проводится построение следующих диаграмм в
иерархии. Каждая последующая диаграмма является более подробным описанием, или как
ее еще называют – декомпозицией, одной из работ на вышестоящей диаграмме.
BPwin автоматически синхронизирует изменения объектов диаграмм на всех
уровнях детализации, тем самым, освобождая пользователя от ручного ведения словаря
объектов модели. Так если мы исправим на верхнем уровне название объекта, то получим
изменение на всех уровнях, где данный объект встречается. Также невозможным является
случайное дублирование наименований работ. При появлении такой ситуации BPwin
генерирует предупреждающее сообщение.
Кроме основных видов диаграмм модель нотации IDEF0 в BPwin может включать
следующие элементы:
–
диаграмма дерева узлов имеет вид традиционного иерархического дерева, где
верхний прямоугольник соответствует работе с контекстной диаграммы, а последующие
нижние узлы представляют собой дочерние уровни декомпозиции. Диаграмм деревьев
узлов в модели может быть сколько угодно много, поскольку дерево может быть
построено на произвольную глубину и не обязательно с корня;
–
диаграммы только для показа. Чаще всего DFD диаграммы строятся, чтобы
показать модель с других точек зрения, вырезать важный кусок из сложной диаграммы,
рассмотреть вариации модели или проблемной области, проанализировать их, не внося
изменений в основную модель.
Второй информационный разрез – потоки информации (документооборота) в
системе.
Диаграммы DFD (Data Flow Diagramming) могут дополнить то, что уже отражено в
модели IDEF0, поскольку они описывают потоки данных, позволяя проследить, каким
образом происходит обмен информацией как внутри системы между бизнес-функциями,
так и системы в целом с внешней информационной средой.
Третий информационный разрез – последовательность выполняемых работ. В
отличие от диаграмм IDEF0 и DFD, элементы которых позволяют точно описать
функциональность системы и организацию документооборота, описать с их помощью
логику построения системы не удастся. Для описания логики взаимодействия
информационных
потоков,
последовательности
выполнения
работ
и
сценариев
взаимодействия модель дополняют диаграммами еще одной методологии – IDEF3, также
называемой диаграммами workflow.
В IDEF3 включены элементы логики, что позволяет аналитику моделировать и
анализировать
альтернативные
сценарии
развития
бизнес-процесса.
Методология
моделирования IDEF3 позволяет графически описать и задокументировать процессы,
фокусируя внимание на течении этих процессов и на отношениях процессов и важных
объектов, являющихся частями этих процессов.
В последней версии BPwin имеется возможность использования модели Swim Lane,
основанной на нотации IDEF3, что делает диаграммы данной нотации более
читабельными и понятными пользователю.
Перечисленные информационные разрезы по-своему уникальны. Каждый из них
может быть выполнен отдельно с помощью BPwin, но их совокупность, заключенная в
модель дает аналитику полную картину предметной области клиента.
Моделирование
подсистемы
обычно
проводится
аналитиком совместно
с
экспертом предметной области. Для этого в начале проектирования, на этапе
анкетирования руководителей определяются сотрудники, хорошо владеющие предметной
областью подсистемы, хорошо знающие все ее функции. Они назначаются на роли
экспертов. В ходе постоянного диалога «Автор-читатель» проводится построение,
верификация и исправление диаграмм модели. После того как диаграмма уровня модели
согласована с экспертом, определяется необходимость ее дальнейшей детализации. Если
такая необходимость существует, то проводится ее детализация и цикл повторяется вновь.
Таким образом, вся система разбивается на подсистемы до нужного уровня детализации, и
получается модель, аппроксимирующая систему с заданным уровнем точности.
Проводя детализацию модели деятельности до необходимого уровня аналитик
способен определить недостатки системы там, где логичность ее построения с первого
взгляда не вызывает сомнения. Критериями в данном случае могут служить процессы без
управления, дублирующиеся работы, неоптимальные документопотоки, отсутствие
контролирующих связей между процессами и т.д. BPwin содержит в себе средства,
помогающие отследить эти и другие ошибки в модели «AS IS», появляющиеся вследствие
нарушения стандарта методологии. Прежде всего, речь идет о том, что BPwin указывает
на синтаксические ошибки в модели, которые могут быть вызваны неправильной
организацией системы.
После построения и верификации модели «AS-IS» аналитику необходимо провести
ее качественное исследование, оптимизацию, необходимую для построения модели «TOBE». Для того чтобы определить качество созданной модели с точки зрения
эффективности бизнес – процессов, необходима система метрики, то есть качество
аналитику следует оценивать количественно.
В качестве таких количественных критериев оценки в BPwin выступают
стоимостные показатели работ, так называемый АВС-анализ, и пользовательские свойства
процессов – UDP (User Defined Properties).
1.4. Краткая характеристика организации
2. ПРОЕКТНАЯ ЧАСТЬ
2.1 Разработка модели СМО в виде UML-диаграмм
2.1.1. Диаграмма использования
ЗАКЛЮЧЕНИЕ
СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ
1. Базылев Н.И., Базылева М.Н. Основы бизнеса: Учебник. - Мн.: Мисанта, 2008. 253с.
2. Басовский Л. Е., Протасьев В. Б. Управление качеством: Учебник. - М.: Инфра-М,
2007. - 212с.
3. Бизнес-реинжиниринг: Учебное пособие / Под ред. Н.В. Васильева. - М.: Экмос,
2008. - 224с.
4. Бузов Б.А. Управление качеством продукции: Учебник. - М.: Академия, 2007. - 176с.
5. Бурков В.Н., Ириков В.А. Модели и методы управления системами предприятия. М.: Юнити, 2008. - 408с.
6. Бусленко Н.П. Моделирование сложных систем. - М.: Юрайт, 2008. - 311с.
7. Лапидус В.А. Всеобщее качество (TQM) в российских компаниях: Учебное пособие.
- М.: Сфера, 2007. - 402с.
8. Лапыгин Ю. Н. Стратегический менеджмент: Учебник. - М.: Инфра-М, 2009. - 236с.
9. Лифиц И.М. Теория и практика оценки конкурентоспособности товаров и услуг:
Учебное пособие. - М.: Юрайт-М, 2008. - 298с.
10. Менеджмент: Учебник / Под ред. М.П. Переверзева, Н.А. Шайденко. - М.: ИнфраМ, 2006. - 288с.
11. Мескон М.Х., Альберт М., Хедоури Ф. Основы менеджмента. - М.: Дело, 2006. 856с.
12. Мильнер Б.З. Теория организации: Учебник. - М.: Инфра-М, 2008. - 360с.
13. Стоянов Е. А. Экспертная диагностика финансово-хозяйственного положения
предприятия: Учебное пособие. - СПб.: Питер, 2008. - 417с.
14. Технология принятия управленческих решений: Учебник / Под ред. Л.В.
Голубкова. - М.: Дело и Сервис, 2009. - 544с.
15. Управление качеством и реинжиниринг организации: Учебное пособие / Под ред.
З.С. Абутидзе. - М.: Логос, 2007. - 328с.
16. Управление качеством. Учебник для вузов / Под ред. С.В. Ильенковой - М.:
Юнити, 2008. - 334с.
17. Уткин Э.А. Бизнес-реинжиниринг. Обновление бизнеса. - М.: Экмос, 2007. - 210с.
18. Фатхудинов Р.А. Управленческие решения: Учебник. - М.: Инфра-М, 2009. - 430с.
19. Фатхутдинов Р.А. Стратегический менеджмент: Учебник. - М.: Дело, 2008. - 448с.
20.
Басовский
Л.Е.
Реинжиниринг
бизнес-процессов:
Современный менеджмент. - 2008. - №2. - С.34-43.
модное
лекарство?
//
21. Кузьмина Е.А., Кузьмин А.Н. Управление качеством процессов // Современный
менеджмент. - 2009. - №5. - С.36-40.
22. Рубцов С.В. Уточнение понятия «Бизнес-процесс» // Менеджмент в России и за
рубежом. - 2007. - №6. - С.26-31.
23. Ручкин К.А., Ручкина В.Н. Моделирование бизнес-процессов с помощью
современных информационных технологий // Менеджмент в России и за рубежом. 2007. - №1. - С.132-142.
24. Федюкин В.А. Управление процессами // Современный менеджмент. - 2009. - №5. С.40-47.
25. Хостинская Г.И. Реинжиниринг на предприятиях сферы услуг // Менеджмент в
России и за рубежом. - 2007. - №6. - С.82-94.
26. Черемных О.В. Реинжиниринг: в чем его польза? // Управление компанией. - 2008.
- №6. - С.25-31.