Технология структурного анализа бизнес процессов

Технология структурного анализа бизнес процесса

Автор: mbeloglazov • Май 17, 2018 • Курсовая работа • 5,740 Слов (23 Страниц) • 382 Просмотры

  1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ СТРУКТУРНОГО АНАЛИЗА БИЗНЕС –

1.1 Бизнес – процесс: сущность, классификация 5

1.2 Моделирование бизнес – процессов в организации 8

1.3 Технология структурного анализа бизнес – процесса 12

  1. СТРУКТУРНЫЙ АНАЛИЗ ПРОЦЕССА УПРАВЛЕНИЯ НА ПРИМЕРЕ

ЗАБАЙКАЛЬСКОЙ ДИРЕКЦИИ ПО ТЕПЛОВОДОСНАБЖЕНИЮ 16

2.1 Характеристика исследуемого объекта 16

2.2 Анализ процесса управления в Забайкальской ДТВ 23

  1. РЕКОМЕНДАЦИИ ПО УСТРАНЕНИЮ НЕЭФФЕКТИВНОЙ ФУНКЦИИ

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

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

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

Э ффективно управлять можно только хорошо структурированной системой, включающей:

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

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

систему взаимодействия элементов организационной структуры

(подразделений, персонала) в рамках бизнес-процессов.

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

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

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

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

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

Задачи курсовой работы заключаются в следующем, а именно:

раскрыть сущность и основные понятия бизнес – процессов;

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

провести структурный анализ процесса управления в компании Забайкальской ДТВ;

предложить рекомендации по устранению проблем управления.

Объектом данной работы является взаимосвязь бизнес-процессов и организационной структуры.

Предметом исследования является Забайкальская дирекция по тепловодоснабжению и ее бизнес-процессы.

  1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ СТРУКТУРНОГО АНАЛИЗА БИЗНЕС

1.1 Бизнес – процесс: сущность, классификация

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

Глава 5. Структурный анализ бизнес-процессов

5.1.Сущность методологии функционального моделирования
бизнес-процессов (SADT-методологии)

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

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

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

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

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

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

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

• функциональный блок – описание функции, операции, действия, работы;

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

Функциональная модель начинается с построения общего описания процесса, которое представляется в диаграмме нулевого уровня или контекстной диаграмме (рис. 10).

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

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

Диаграммы следующих уровней детализируют функции процесса каждого предыдущего уровня. Так, функциональный блок А0 декомпозируется на совокупность взаимосвязанных подфункций А1, А2, А3, … (рис. 11). В свою очередь, каждый функциональный блок 1-го уровня может быть декомпозирован на совокупность подфункций, например А2 на А21, А22, А23, А24 . и так дальше, пока на последнем уровне не получатся элементарные действия. На каждом уровне рекомендуется размещать не более 6 функциональных блоков. Число уровней декомпозиции не ограниченно. Обычно для структурного анализа бизнес-процессов достаточно 2–3 уровней декомпозиции, последующие уровни декомпозиции требуются для алгоритмизации информационных процессов и разработки инструкций для исполнителей бизнес-процессов.

Механизмы

Рис. 11. Декомпозиция функции А0

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

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

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

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

Механизмы – это объекты, которые исполняют процессы (исполнители). К механизмам относят структурные подразделения предприятия, персонал, автоматизированные рабочие места, оборудование.

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

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

5.2. Сущность объектно-ориентированной методологии
моделирования бизнес-процессов

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

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

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

Объектно-ориентированная методология предполагает разработку моделей бизнес-процессов на нескольких уровнях детализации:

· П-модели (Use-Case Model) – модели прецедентов использования,

· О-модели (Object Model) – объектной модели,

· В-модели (Object Interaction Model) – модели взаимодействия объектов.

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

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

На внешнем уровне не раскрывается механизм реализации транзакций.

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

В-модель раскрывает механизм реализации динамических связей объектов О-модели в бизнес-процессах П-модели.

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

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

Контрольные вопросы

1. Что такое функциональная модель бизнес-процесса?

2. Какие конструктивные элементы используются для построения функциональной модели?

3. Как представляется поток материальных, информационных, финансовых объектов?

4. Как трактуется и представляется управление выполнением функций?

5. Как представляются исполнители бизнес-процессов?

6. Как отражается использование информационной системы в бизнес-процессе?

7. Что такое ICOM метки и как они используются?

8. Что такое туннельные дуги и как они используются?

9. Что такое главный путь бизнес-процесса и как он отражается?

10. Как трактуются и представляются разветвления и соединения путей бизнес-процесса?

11. Как трактуются и представляются циклы в бизнес-процессе?

Не нашли то, что искали? Воспользуйтесь поиском:

Лучшие изречения: Как то на паре, один преподаватель сказал, когда лекция заканчивалась – это был конец пары: “Что-то тут концом пахнет”. 8611 – | 8174 – или читать все.

Читайте также:  Оценка эффективности бизнес процессов на предприятии

188.64.174.90 © studopedia.ru Не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования. Есть нарушение авторского права? Напишите нам | Обратная связь.

Отключите adBlock!
и обновите страницу (F5)

очень нужно

Как анализировать бизнес-процессы

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

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

Я расскажу о том, как анализировать БП правильно, чтобы бизнес приносил прибыль.

Что включает базовый анализ?

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

Два вида анализа бизнес-процессов

1. Качественный

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

2. Количественный

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

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

Качественные методы

1. SWOT-анализ

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

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

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

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

3. Ранжирование процессов

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

Количественные методы

К ним относятся:

  • Показатели процесса – числовые величины, характеризующие временные, финансовые, человеческие и другие затраты.
  • Показатели продукта или услуги, например, абсолютный объём услуг, номенклатура, количество дефектов и др.
  • Показатели удовлетворенности клиентов результатами – выходом БП или продукцией.

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

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

Как оценивают стоимость процесса?

Стоимостные показатели относятся к самым важным и делятся на три группы:

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

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

Как проанализировать качество процесса?

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

  • Количество возвратов продукции и рекламаций на продукт или услугу, жалоб от клиентов на качество обслуживания.
  • Число некомплектных отгрузок.
  • Степень дефектности и сохранность продукта.
  • Количество внештатных ситуаций с вынужденным вмешательством руководства.
  • Адаптивность БП к изменению требований заказчика и внешних условий.
  • Независимость процесса от смены персонала.
  • Управляемость.
  • Способность к улучшению.

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

Пример пошагового плана анализа бизнес-процессов

  1. Разговор с сотрудниками, ответственными за реализацию конкретного БП, о возможных проблемах.
  2. Определение входов (материальных, трудовых, энергетических ресурсов).
  3. Фиксирование выходов (физического товара или услуги).
  4. Проведение мозгового штурма с представителями нескольких отделений об усовершенствовании БП.
  5. Визуализация процессов с помощью блок-схем.
  6. Внесение изменений, направленных на снижение затрат, сокращение цикла работ, упрощение процесса или повышение качества обслуживания – с учетом полученных результатов.
  7. Анализ результатов и (при необходимости) шагов по совершенствованию БП.

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

Регулярное отслеживание эффективности каждого БП – это обязательное условие для достижения результатов. Ведь в отсутствии прогресса наступает регресс. В выигрыше остается тот, кто не перестаёт стремиться к совершенству!

Структурный анализ бизнес-системы

Для описания бизнес-системы используется методология структурного анализа как разновидности системного анализа. Структурный анализ был разработан в 60-70-х годах ХХ в. Дугласом Т. Россом в виде методологии SA&DT (Structured Analisys and Design Technique) – технология структурного анализа и проектирования. В основе структурного анализа лежит выявление структуры как относительно устойчивой совокупности отношений между элементами системы.

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

Для такого подхода характерны:

● разбиение на уровни абстракции с ограничением числа элементов на каждом из уровней (обычно от 3 до 9);

● ограниченный контекст, включающий лишь существенные на каждом уровне детали;

● использование строгих формальных правил записи в рамках принятой нотации;

● последовательное пприближение к конечному результату.

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

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

● функции, которые система должна выполнять;

● процессы, обеспечивающие выполнение указанных функций;

● данные, необходимые при выполнении функций, и отношения между этими данными;

● организационные структуры, обеспечивающие выполнение функций;

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

Вследствие сложности моделируемых систем, а также большой размерности создаваемых моделей, структурный анализ должен опираться на мощные средства компьютерной поддержки, обеспечивающей автоматизацию труда системных аналитиков. Такими средствами являются CASE – технологии (Computer-Aided Software Engineering – програмно-компьютерные технологии технических разработок и конструирования), которые представляют собой совокупность методологий моделирования, проектирования, анализа и реорганизации бизнес-процессов, поддерживаемых определёнными программными и инструментальными средствами.

CASE-технологии являются инструментарием современного бизнес-аналитика. На сегодняшний день одними из наиболее распространённых CASE-инструментов для моделирования бизнес-процессов являются ARIS Collaborative Suite компании IDS Scheer AG (Германия) и AllFusion Process Modeler (ранее BPwin) компании Computer Associates.

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

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

— методика описания комплексного автоматизированного проектирования производства (Integrated Computer Aided Manufacturing Definition, ICAMD, разработаная BBC США в середине 70-х годов 20 в.; на ее основе Министерство обороны США создало федеральный стандарт обработки информации, который посредством модели бизнеса обеспечивает поддержку информационной системы и технологий на нескольких уровнях; моделирование бизнеса поддерживается диаграммами «сущность-связь» для данных и диаграммами потоков данных специ­ального вида, что позволяет иерархически описывать функции системы;

— методика структурного анализа и методология проектирования (Structured Analysis and Design Technique — SA&DT) использует систему обозначений, похожую на диаграммы потоков данных в ICAMD, для описания функций и структур данных информационной системы на основе декомпозиции.

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

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

● в какой последовательности выполняются эти процедуры;

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

● кто выполняет процедуры бизнес-процесса;

● какие входящие информационные ресурсы/документы использует каждая процедура процесса;

● какие исходящие документы/информацию генерирует каждая процедура процесса;

● какие ресурсы необходимы для выполнения каждой процедуры процесса;

● какие условия/документы регламентируют выполнение каждой процедуры;

● какие параметры характеризуют выполнение процедур и процесса в целом.

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

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

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

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

Читайте также:  Системы управления бизнес процессами

По аналогии с планированием можно проводить моделирование и описание бизнес- процессов «сверху-вниз» и «снизу – вверх».

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

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

Каждая из методик моделирования имеет право на существование, а также свои достоинства и недостатки.

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

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

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

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

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

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

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

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

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

— абстрагирование, т.е. выделение существенных аспектов системы и от­влечение от несущественных;

— формализация, т.е. построение формальной системы со строгим методическим подходом к ре­шению проблемы

– непротиворечивость, т.е. обоснованность и согласованность элементов;

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

В структурном анализе используются в основном две группы средств, иллю­стрирующих функции, выполняемые системой. Каждой группе средств соответст­вуют определенные виды моделей диаграмм, наиболее распространены среди ко­торых: диаграммы потоков данных, (Data Flow Diagrams — DFD) и диаграммы “сущность-связь” (Entity Relationship Diagrams — ERD), чаще всего исполь­зуемые в средствах автоматизированной разработки программного обеспечения CASE-систем.

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

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

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

Рисунок 2.3 – Компоненты структурной модели

Л
Классическая DFD показывает внешние по отношению к системе источники и стоки (адресаты) данных, идентифицирует логические функции (процессы) и группы элементов данных, связывающие одну функцию с другой (потоки), а также идентифицирует хранилища (накопители) данных, к которым осуществляется доступ. Структуры потоков данных и определения их компонент хранятся и анализируются в словаре данных. Каждая логическая функция (процесс) может быть детализирована с помощью DFD нижнего уровня; когда дальнейшая детализация перестает быть полезной, переходят к выражению логики функции при помощи спецификации процесса (мини- спецификации). Содержимое каждого хранилища также сохраняют в словаре данных, модель данных хранилища раскрывается с помощью ERD. В случае наличия реального времени DFD дополняется средствами описания зависящего от времени поведения системы, раскрывающимися с помощью STD. Эти взаимосвязи показаны на рисунке 2.3.
Перечисленные выше графические нотации используются (в том или ином наборе) практически во всех современных методологиях структурного системного анализа. Роль этих методологий заключается в регламентации основ разработки сложных систем. Они описывают последовательность шагов, модели и подходы.
В настоящее время успешно используются практически все известные методологии структурного анализа, однако наибольшее распространение получили:
методологии SADT (Structured Analysis and Design Technique);
структурного системного анализа Гейна —Сарсона (Gane—Sarson) [165];
структурного анализа и проектирования Иодана—Де Марко (Yourdon— DcMarko) [161, 169];
развития систем Джексона (Jackson);
развития структурных систем Варнье—Oppa (Warmer— Orr);
анализа и проектирования систем реального времени У орд а— Меллора (Ward—Mellor) и Хатли (Hatley);
информационного моделирования Мартина (Martin) [167].
Перечисленные структурные методологии жестко регламентируют фазы анализа требований и проектирования спецификаций и отражают подход к системной разработке с позиций рецептов «кулинарной книги».
Основные символы и термины DFD (в нотация Иодана) представлены на рисунке 2.4.
Потоки данных являются механизмами [76], использующимися для моделирования передачи информации (или физических компонент) из одной части системы в другую. Потоки на диаграммах обычно изображаются именованными стрелками, ориентация которых указывает направление движения информации. Иногда поток может двигаться в одном направлении, обрабатываться и возвращаться назад в се источник. Такая ситуация может моделироваться либо двумя различными потоками, либо одним двунаправленным.
Назначение процесса состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса, Это имя должно содержать глагол в неопределенной форме с последующим дополнением. Кроме того, каждый процесс должен иметь уникальный номер для ссылок на него внутри диаграммы. Этот номер может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели. Компонента Обозначение Компонента Обозначение Поток данных Имя > Управляющий поток Имя Процесс ^Имя^ Управляющий процесс > t ъ
f Имя j
* /
4 У
^ t у Хранилище Имя Управляющее хранилище Имя Внешняя сущность Имя Узел смены имени Групповой узел Имя Узел смены типа Рисунок 2.4 – Основные символы диаграммы потоков данных
Хранилище (накопитель) данных (материалов) позволяет на определенных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет “срезы” потоков данных во времени. Информация (сырье, полуфабрикат), которую оно содержит, может использоваться в любое время после ее определения, при этом данные (объекты) могут выбираться в любом порядке. Имя хранилища должно
идентифицировать его содержимое и быть существительным. В случае, когда поток данных входит или выходит в/из хранилища, и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме.
Внешняя сущность (или терминатор) представляет сущность вне контекста системы, являющуюся источником или приемником системных данных. Ее имя должно содержать существительное, например, склад товаров. Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке.
Декомпозиция DFD осуществляется на основе декомпозиции процессов – каждый процесс может раскрываться с помощью DFD нижнего уровня.
Важную специфическую роль в модели играет специальный вид DFD – контекстная диаграмма, моделирующая систему наиболее общим образом. Контекстная диаграмма отражает интерфейс системы с внешним миром, а именно, информационные потоки между системой и внешними сущностями, с которыми она должна быть связана, Она идентифицирует эти внешние сущности, а также , как правило, единственный процесс, отражающий главную цель или природу системы насколько это возможно. И хотя контекстная диаграмма выглядит тривиальной, несомненная ее полезность заключается в том, что она устанавливает границы анализируемой системы. Каждый проект должен иметь ровно одну контекстную диаграмму, при этом нет необходимости в нумерации единственного ее процесса.
DFD первого уровня строится как декомпозиция процесса, который присутствует на контекстной диаграмме.
Построенная диаграмма первого уровня также имеет множество процессов, которые в свою очередь могут быть декомпозированы в DFD нижнего уровня. Таким образом строится иерархия DFD с контекстной диаграммой в корне дерева. Этот процесс декомпозиции продолжается до тех пор, пока процессы могут быть эффективно описаны с помощью коротких (до одной страницы) миниспецификаций обработки (спецификаций процессов).
При таком построении иерархии DFD каждый процесс более низкого уровня необходимо соотнести с процессом верхнего уровня.
Индивидуальные данные в системе часто являются независимыми. Однако иногда необходимо иметь дело с несколькими независимыми данными одновременно. Например, в системе имеются потоки «яблоки», «апельсины» и «груши». Эти потоки могут быть сгруппированы с помощью введения нового потока «фрукты». Для этого необходимо определить формально поток «фрукты» как состоящий из нескольких элементов-потомков. Такие потоки, объединяющие несколько потоков, получили название групповых. Обратная операция, расщепление потоков на подпотоки, осуществляется с использованием группового узла, позволяющего расщепить поток на любое число подпотоков.
Аналогичным образом осуществляется и декомпозиция потоков через границы диаграмм, позволяющая упростить детализирующую DFD. Пусть имеется поток ФРУКТЫ, входящий в детализируемый процесс. На детализирующей этот процесс диаграмме потока «фрукты» может не быть вовсе, но вместо него могут быть потоки «яблоки» и «апельсины» (как будто бы они переданы из детализируемого процесса). В этом случае должно существовать БНФ-определение потока ФРУКТЫ, состоящего из подпотоков «яблоки» и «апельсины», для целей балансирования.
Применение этих операций над данными позволяет обеспечить структуризацию данных, увеличивает наглядность и читабельность диаграмм.
Для обеспечения декомпозиции данных и некоторых других сервисных возможностей к DFD добавляются следующие типы объектов:
групповой узел. Предназначен для расщепления и объединения потоков. В некоторых случаях может отсутствовать (т.е. фактически вырождаться в точку слияния/расщепления потоков на диаграмме);
узел изменения имени. Позволяет неоднозначно именовать потоки, при этом их содержимое эквивалентно. Например, если при проектировании разных частей системы один и тот же фрагмент данных получил различные имена, то эквивалентность соответствующих потоков данных обеспечивается узлом изменения имени. При этом один из потоков данных является входным для данного узла, а другой — выходным;
управляющий процесс. Представляет собой интерфейс между DFD и спецификациями управления, собственно моделирующими и документирующими аспекты реального времени. Его имя указывает на тип управляющей деятельности, вырабатываемой спецификацией. Фактически управляющий процесс представляет собой преобразователь входных управляющих потоков в выходные управляющие потоки; при этом точное описание этого преобразования должно задаваться в спецификации управления;
управляющее хранилище. Представляет «срез» управляющего потока во времени. Содержащаяся в нем управляющая информация может использоваться в любое время после ее занесения в хранилище, при этом соответствующие данные могут быть использованы в произвольном порядке. Имя управляющего хранилища должно идентифицировать его содержимое и быть существительным. Управляющее хранилище отличается от традиционного тем, что может содержать только управляющие потоки; все другие их характеристики идентичны;
управляющий поток представляет собой “трубопровод”, через который проходит управляющая информация. Его имя не должно содержать глаголов, а только существительные и прилагательные. Обычно управляющий поток имеет дискретное, а не непрерывное значение. Это может быть, например, сигнал, представляющий состояние или вид операции.
Логически управляющий процесс есть некий командный пункт, реагирующий на изменения внешних условий, передаваемые ему с помощью управляющих потоков, и продуцирующий в соответствии со своей внутренней логикой выполняемые процессами команды;
узел изменения типа – поток данных является входным для этого узла, а управляющий поток – выходным. Например, поток данных «скорость машины» в отдельных случаях может использоваться как управляющий для контроля критического значения.
Таким образом, разработчики моделей БП пришли к выводу, что простейшим способом стандартизации такой работы является введение в обращение правил графического изображения БП и интерпретации этих
графических изображений. Эти правила, естественно, должны признаваться тем или иным авторитетным сообществом. Такой способ стал наиболее эффективным с появлением первых программных инструментов, автоматизирующих деятельность команд модельеров, объединяющих усилия в рамках одного проекта. Реализаций рассматриваемого способа довольно много, и они в основном ассоциированы с конкретным CASE-средством. Однако, уже сейчас можно говорить о некоторых исторически подтвержденных мета-тенденциях.
Сравнение существующих инструментов – крайне трудный процесс в виду сложности инструментов и наукоемкости идей, заложенных в них. Объективная слабость сравнительных мотивировок, приводимых специалистами в области реинжиниринга бизнес-процессов обусловлена трудностью или нецелесообразностью овладения в совершенстве более чем одним инструментом организационного проектирования. По этой же причине мнение такого специалиста – лишь отражение степени совместимости его мировоззрения, сформированного опытом ни одного года работы [131].
Сейчас можно говорить о двух основных направлениях развития инструментов организационного проектирования. Одно выражается в создании условий, снижающих степень свободы проектировщика. Это – определение жестких стандартов оформления умозаключений, обеспечивающих приемлемое взаимопонимание разработчиков и пользователей инструментов, поддерживающих весь проектный цикл, но не позволяющих «творить» так, как нам хочется. Другое – охватывает лишь отдельные фрагменты проектного цикла и направлено на представление сервиса для выражения «творческих» взглядов на проектирование организационных процессов. Другими словами, два подхода различаются количеством стандартных отношений, которые представляет программная среда для описания организационных процессов.
Попытка сравнения некоторых характеристик и особенностей описания бизнес-процессов, реализованных в программном продукте Rational Rose фирмы Rational Software, и продуктах, основанных на методологии IDEF0, наиболее распространенным из которых на российском рынке является BPwin корпорации Computer Associates позволяет сделать вывод, что первая система относится к категории «творческих», а вторая «жестких».
Поскольку характерные компоненты «жестких» систем, основанных на IDEF и DFD ,были подробно рассмотрены выше, остановимся подробнее на характерных особенностях «творческой» Rational Rose. Rational Rose не поддерживает ни одну из известных методологий моделирования и анализа бизнес-процессов. Методика построения так называемых «бизнес-моделей», содержащаяся в дополнительном наборе рекомендаций или методике RUP, которая сопровождает пакет Rational Rose, предлагает диаграммы Use Case и Activity для описания бизнес-процессов. Однако автор убежден, что эти диаграммы позволяют описать лишь малую часть сведений, которые нужны для моделирования бизнес-процессов и которые представляются средствами IDEF0. Кроме того, дуги Use Case и Activity диаграмм не имеют тех смысловых типов, которые были указаны для дуг IDEF0. Синтаксические соглашения, диктуемые системой при разработке Use Case и Activity-диаграмм, не объединены в законченную систему; этим диаграммам не дается никакой интерпретации, объясняющей, как их применять при моделировании.
По этим причинам пользователям Rational Rose при разработке Use Case и Activity-диаграмм приходится придумывать свои оригинальные синтаксические соглашения и давать свою интерпретацию имеющимся, чтобы отразить всю существенную для анализируемого процесса информацию.
Другими словами, пользователь Rational Rose вынужден разрабатывать свои «формализмы» для получения методики построения моделей и анализа бизнес-процессов [135].
Существуют и российские программные средства основанные на использовании CASE-технологий, например отечественный пакет – CASE.аналитик.
CASE.Аналитик представляет собой графическую систему класса CASE (Computer Aided Software/System Engineering), работающую под Microsoft Windows 9.X. CASE.Аналитик предоставляет следующие возможности;
средства для функционального моделирования системы с помощью диаграмм потоков данных;
автоматическое ведение базы данных проекта;
автоматическая верификация проекта, контроль целостности и полноты;
современный графический интерфейс;
ясное и строгое описание системы (спецификации системы);
средства презентации проекта, например, диаграммы размером 2×2м (на любом принтере);
автоматическая генерация документации на проект по ГОСТ 19.XXX и 34.XXX;
более 40 видов отчетов и протоколов.
Окно диаграмм является основным рабочим окном программы в том смысле, что оно определяет текущую диаграмму проекта и не может быть закрыто. В окне диаграмм можно создавать и редактировать диаграммы. Новая диаграмма может быть создана только при детализации (декомпозиции) какого- либо узла на текущей диаграмме. Таким образом, все диаграммы автоматически формируют иерархическое дерево проекта [95].
Каждая диаграмма проекта может быть одного из следующих типов:
КД – контекстная диаграмма;
ДПД – диаграмма потоков данных;
ДПУ – диаграмма потоков управления.
Самая верхняя диаграмма проекта – всегда контекстная диаграмма.
Каждый тип диаграммы имеет свою палитру объектов в правой части
окна.
Перечисленные подходы, несмотря на все их многообразие, при организационном проектировании предприятий исходят из принципов целостности, то есть внешняя среда в данных моделях присутствует лишь как внешняя сущность, формирующая входные сигналы (материальные потоки) и замыкающая линии обратной связи.
Однако ранее было показано, что одной из характерных тенденций организационного строительства современных компаний является размытие границ организации, утрата разницы между внутренней и внешней средой корпорации вследствие многочисленных кооперативных связей,
диверсификации, консалтингового и финансового взаимоучастия компаний в деятельности друг друга.
Наиболее ярким проявлением «организационного взаимопроникновения» стал аутсорсинг. О специфике данного экономического явления и возможности использования анализа степени «аутсорсингоприемлемости» при структурном проектировании организаций пойдет речь в еле дуто щем разделе.

Читайте также:  Госпрограмма помощи малому бизнесу

Анализ бизнес-процессов

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

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

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

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

Структура процесса

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

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

Для определения данных необходимы следующие инструменты:

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

При изучении данных получаются ответы на следующие вопросы:

а) какой процесс анализируется? какие функциональные области или организационные единицы участвуют? когда и какие функции должны выполняться? Как выглядят результаты этих функций? Какие следствия должны исходить из этих результатов?

в) относительно хода работы – какие этапы и как они должны выполняться? какое время прохождения заказа? какие затраты? с помощью чего выполняются рабочие этапы? Какие существуют требования к качеству?

с) относительно материального потока – какие виды ресурсов? какова потребность в мощностях? какой объем мощностей в наличие? какие мощности не задействованы? какова частота колебаний в использовании мощностей? Какова матрица поступления – передачи материалов?

d) относительно информационного потока – откуда поступает информация (вход)? какие данные? по какому пути поступают? Как обрабатываются данные? куда поставляется исходящая информация (выход)?

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

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

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

Относительные показатели отражают отношение различных данных друг к другу. Например,

Ссылка на основную публикацию