Нефть и песок О стали Компрессор - подбор и ошибки Из истории стандартизации резьб Соперник ксерокса - гектограф Новые технологии производства стали Экспорт проволоки из России Прогрессивная технологическая оснастка Цитадель сварки с полувековой историей Упрочнение пружин Способы обогрева Назначение, структура, характеристики анализаторов Промышленные пылесосы Штампованные гайки из пружинной стали Консервация САУ Стандарты и качество Технология производства Водород Выбор материала для крепежных деталей Токарный резец в миниатюре Производство проволоки Адгезия резины к металлокорду Электролитическое фосфатирование проволоки Восстановление корпусных деталей двигателей Новая бескислотная технология производства проката Синие кристаллы Автоклав Нормирование шумов связи Газосварочный аппарат для тугоплавких припоев
Главная страница / Архитектура отрасли

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

Окончание. Начало в № 6,7/2005

UML

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

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

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

UML имеет четырехуровневую архитектуру:

- мета-метамодель;

- метамодель;

- модель;

- пользовательские объекты.

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

В UML существуют следующие модели (каждая модель представлена соответствующим типом диаграммы):

- модель вариантов использования (Use Case Model). Предназначена для описания требований к системе и подсистемам;

- модель классов (Class Model). Служит для описания статической структуры системы: иерархии классов и отношений между ними;

- модель взаимодействий: объекты (Collabo-ration Model) и сценарии (Sequence Model). Служит для описания механизмов взаимодействия объектов системы, реализующих ту или иную функцию;

- поведенческая модель диаграммы переходов и состояний (Behavior Model). Предназначена для описания алгоритмов поведения объектов системы;

- модель процессов: физическая архитектура системы (Deployment Model). Описывает распределение процессов по процессорам в физическом проекте системы;

- модель программных модулей (Component Model). Описывает распределение классов и объектов системы по модулям в физическом проекте системы;

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

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

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

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

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

Инструментальные пакеты UML (например, комплект разработчика IBM Rational Rose) содержат инструментальные средства, позволяющие легко создавать модели UML для бизнес-процессов и генерировать код на различных языках программирования (в том числе на Java, C++ и Visual Basic). Моделирующее программное обеспечение используется и для обратного проектирования уже существующих систем.

Последний вариант спецификаций UML содержит ряд улучшений, к которым относятся новые семантические конструкции, усовершенствованная организация и улучшенная читабельность документов, а также поддержка нового интерфейса XMI (XML Metadata Interchange).

Блок-схемы

Простейшим, но важным на практике способом описания бизнес-процессов является методика составления блок-схем. Данный подход имеет много общего с графическими языками описания алгоритмов программного обеспечения. С точки зрения методологии формирование блок-схем выполняется так же, как в нотации IDEF3, хотя в целях упрощения символы логики можно опустить. Для разработки блок-схем используют стандартные офисные программные продукты, например MS Word или Visio. Блок-схемы удобно строить на листе, располагая их вертикально. При этом справа от блок-схемы процесса остается место для описания выполняемых функций, результатов их выполнения, исполнителей, номеров входящих и исходящих документов. Опивания бизнес-процессов (IDEF, ARIS, UML, блок-схемы) разрабатывались без учета специфики конкретных вертикальных рынков. Однако необходимо отметить, что организация деятельности компании в индустрии телекоммуникаций и ИТ будет существенно отличаться, например, от организации деятельности предприятия FMCG. Поэтому на рынке представлены программные продукты, построенные на основе лучшей практики в той или иной отрасли. Так, в области телекоммуникаций подобной методологической основой по праву считается Enhanced Telecom Operations Map (eTOM).

eTOM

Методология eTOM (Enhanced Telecom Operations Map) была разработана некоммерческой интернациональной организацией TeleManagement Forum (TMF), созданной в целях оптимизации управления организациями в области ИТ и телекоммуникаций. TMF объединяет более 340 компаний, в том числе традиционных операторов проводной связи и относительно недавно вышедших на рынок операторов мобильной связи, разработчиков программного обеспечения и потребителей телекоммуникационных услуг. Вот уже более 13 лет TMF хорошо известна в сфере информационных и телекоммуникационных услуг.

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

Согласно eTOM все бизнес-процессы разбиты на три крупные группы (см. рисунок).

- Strategy, Infrastructure & Product (стратегия, инфраструктура и продукт). В данную область объединены бизнес-процессы, связанные с разработкой стратегии, обязательствами предприятия, построением инфраструктуры, разработкой и управлением продуктами, а также созданием и управлением каналов сбыта.

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

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

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

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

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

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

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

Полностью с материалами статьи можно ознакомиться в печатной версии журнала

Материалы предоставлены НП «ЦИПРТ»

Главная страница / Архитектура отрасли