<<
>>

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

При разработке организационной структуры предприятия, базирующейся на методологии реинжиниринга бизнес - процессов, одним из первых и наиважнейших шагов является анализ деятельности предприятия. Анализ начинается с выделения и описания бизнес-процессов, протекающих на предприятии [103].
Разработка модели реинжиниринга бизнес-процессов (БП) организации представляет собой сложную задачу, решение которой требует применения специальных методик и инструментов, в основе которых лежат методы структурного анализа.
Структурным анализом принято называть метод исследования системы, который начинается с общего ее обзора и затем детализируется, приобретая иерархическую структуру со все большим числом уровней. Для таких методов характерно [140]:
- разбиение на уровни абстракции с ограничением числа элементов на каждом из уровней (обычно от 3 до 7, при этом верхняя граница соответствует возможностям человеческого мозга воспринимать определенное количество
взаимоувязанных объектов, а нижняя выбрана из соображений здравого смысла);
ограниченный контекст, включающий лишь существенные на каждом уровне детали;
использование строгих формальных правил записи;
последовательное приближение к конечному результату. Методы структурного анализа позволяют преодолеть сложность больших систем путем расчленения их на части («черные ящики») и иерархической организации этих «черных ящиков» [19]. Преимущество использования «черных ящиков» заключается в том, что их пользователю не требуется знать, как они работают. Необходимо знать лишь его входы и выходы, а также его назначение (т. е. функцию, которую он выполняет). В окружающем нас мире «черные ящики» встречаются в большом количестве: магнитофон и телевизор на бытовом уровне, предприятие с позиций клиента и т. п.
Таким образом, первым шагом упрощения сложной системы является ее разбиение на «черные ящики» (принцип «разделяй и властвуй» — принцип решения трудных проблем путем разбиения их на множество независимых задач, легких для понимания и решения), при этом такое разбиение должно удовлетворять следующим критериям:
каждый «черный ящик» должен реализовывать единственную функцию системы;
функция каждого «черного ящика» должна быть легко понимаема независимо от сложности ее реализации (например, в системе управления ракетой может быть черный ящик для расчета места ее приземления: несмотря на сложность алгоритма, функция черного ящика очевидна — расчет точки приземления);
связь между «черными ящиками» должна вводиться только при наличии связи между соответствующими функциями системы (например, в бухгалтерии один черный ящик необходим для расчета общей заработной платы служащего, а другой — для расчета налогов. Необходимая связь между этими «черными ящиками» - размер заработанной платы требуется для расчета налогов);
- связи между «черными ящиками» должны быть простыми, насколько это возможно, для обеспечения независимости между ними.
Второй важной идеей, лежащей в основе структурных методов, является идея иерархии. Для понимания сложной системы недостаточно разбиения ее на части, необходимо эти части организовать определенным образом, а именно в виде иерархических структур. Все сложные системы Вселенной организованы в иерархии. Да и сама она включает галактики, звездные системы, планеты, молекулы, атомы, элементарные частицы. Таким образом, второй принцип структурного анализа (принцип иерархического упорядочения) в дополнение к тому, что легче понимать проблему, если она разбита на части, декларирует, что устройство этих частей также существенно для понимания.
Понимаемость проблемы резко повышается при организации ее частей в древовидные иерархические структуры, т. е. система может быть понята и построена по уровням, каждый из которых добавляет новые детали.
Третий принцип: структурные методы широко используют графические нотации, также служащие для облегчения понимания сложных систем. Известно, что «одна картинка стоит тысячи слов».
Для целей структурного анализа традиционно используются три группы средств, иллюстрирующих:
функции, которые система должна выполнять;
отношения между данными;
¦ зависящее от времени поведение системы (аспекты реального времени).
Среди многообразия графических нотаций, используемых для решения перечисленных задач, в методологиях структурного анализа наиболее часто и эффективно применяются следующие:
DFD (Data Flow Diagrams) — диаграммы потоков данных совместно со словарями данных и спецификациями процессов (мини-спецификациями);
ERD (Entity-Relationship Diagrams) — диаграммы «сущность-связь»;
STD (State Transition Diagrams) — диаграммы переходов состояний.
Все они содержат графические и текстовые средства моделирования: первые — для удобства отображения основных компонент модели, вторые — для обеспечения точного определения ее компонент и связей.


Рисунок 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.Аналитик предоставляет следующие возможности;
средства для функционального моделирования системы с помощью диаграмм потоков данных;
автоматическое ведение базы данных проекта;
автоматическая верификация проекта, контроль целостности и полноты;
современный графический интерфейс;
ясное и строгое описание системы (спецификации системы);
средства презентации проекта, например, диаграммы размером 2x2м (на любом принтере);
автоматическая генерация документации на проект по ГОСТ 19.XXX и 34.XXX;
более 40 видов отчетов и протоколов.
Окно диаграмм является основным рабочим окном программы в том смысле, что оно определяет текущую диаграмму проекта и не может быть закрыто. В окне диаграмм можно создавать и редактировать диаграммы. Новая диаграмма может быть создана только при детализации (декомпозиции) какого- либо узла на текущей диаграмме. Таким образом, все диаграммы автоматически формируют иерархическое дерево проекта [95].
Каждая диаграмма проекта может быть одного из следующих типов:
КД - контекстная диаграмма;
ДПД - диаграмма потоков данных;
ДПУ - диаграмма потоков управления.
Самая верхняя диаграмма проекта - всегда контекстная диаграмма.
Каждый тип диаграммы имеет свою палитру объектов в правой части
окна.
Перечисленные подходы, несмотря на все их многообразие, при организационном проектировании предприятий исходят из принципов целостности, то есть внешняя среда в данных моделях присутствует лишь как внешняя сущность, формирующая входные сигналы (материальные потоки) и замыкающая линии обратной связи.
Однако ранее было показано, что одной из характерных тенденций организационного строительства современных компаний является размытие границ организации, утрата разницы между внутренней и внешней средой корпорации вследствие многочисленных кооперативных связей,
диверсификации, консалтингового и финансового взаимоучастия компаний в деятельности друг друга.
Наиболее ярким проявлением «организационного взаимопроникновения» стал аутсорсинг. О специфике данного экономического явления и возможности использования анализа степени «аутсорсингоприемлемости» при структурном проектировании организаций пойдет речь в еле дуто щем разделе.
<< | >>
Источник: Татенко Сергей Александрович. УПРАВЛЕНИЕ ПРОЦЕССАМИ СТРУКТУРНОГО РЕИНЖИНИРИНГА НА ПРОМЫШЛЕННЫХ ПРЕДПРИЯТИЯХ. 2002

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

  1. Татенко Сергей Александрович. УПРАВЛЕНИЕ ПРОЦЕССАМИ СТРУКТУРНОГО РЕИНЖИНИРИНГА НА ПРОМЫШЛЕННЫХ ПРЕДПРИЯТИЯХ, 2002
  2. 3.2 Разработки стратегии структурного реинжиниринга промышленного предприятия на основе использовании методов нечеткой логики
  3. 3.3 Структурный реинжиниринг на промышленных предприятиях.
  4. 2 СТРУКТУРНЫЕ И КОЛИЧЕСТВЕННЫЕ МЕТОДЫ АНАЛИЗА ОРГАНИЗАЦИОННЫХ СТРУКТУР ПРОМЫШЛЕННЫХ ПРЕДПРИЯТИЙ
  5. 3.1 Управление по слабым сигналам - базовыйалгоритм структурного реинжиниринга промышленных предприятий
  6. 3 РАЗРАБОТКА СТРАТЕГИИ СТРУКТУРНОГО РЕИНЖИНИРИНГА ПРЕДПРИЯТИЙ РАЗЛИЧНЫХ ОТРАСЛЕЙ ПРОМЫШЛЕННОСТИ
  7. 2.2. Разработка методов анализа и оптимизации бизнес-процессов финансово-кредитной организации. Определение этапов рационализации бизнес-процессов
  8. Методы анализа бизнес-процессов
  9. Анализ процесса запуска механизма на промышленном предприятии
  10. 1.3 Реинжиниринг бизнес-процессов — основа динамического подхода к проектированию организационных структур
  11. 1.3. Реинжиниринг как новая форма управления кризисными процессами на предприятии
  12. БЕЗДЕЛОВ СЕРГЕЙ АЛЕКСАНДРОВИЧ. УПРАВЛЕНИЕ ПРОЦЕССАМИ РЕСТРУКТУРИЗАЦИИ И РЕИНЖИНИРИНГА ПРЕДПРИЯТИЙ В ПЕРЕХОДНОЙЭКОНОМИКЕ, 2000
  13. 1.3 Процессы реструктуризации на промышленном предприятии
  14. Глухов Сергей Владимирович. МЕТОДЫ, КРИТЕРИИ И АЛГОРИТМЫ УПРАВЛЕНИЯ ПРОЦЕССОМ ОБЕСПЕЧЕНИЯ ПРОМЫШЛЕННОЙ БЕЗОПАСНОСТИ НЕФТЕГАЗОВЫХ ПРЕДПРИЯТИЙ, ОСНОВАННЫЕ НА ТЕОРИИ НЕЧЕТКИХ МНОЖЕСТВ. Диссертация на соискание ученой степени кандидата экономических наук. Оренбург - 2006, 2006
  15. Глава 1. Анализ развития системы управления промышленного предприятия
  16. ГЛАВА !. АНАЛИЗ НАУЧНЫХ ПОЛОЖЕНИЙ ПО ПРИМЕНЕНИЮ БИЗНЕС-ПРОЦЕССОВ В ФУНКЦИОНИРОВАНИИ И РАЗВИТИИ ОРГАНИЗАЦИЙ