Отправляет email-рассылки с помощью сервиса Sendsay

Всё про реинжиниринг и автоматизацию для директора.

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "Как увеличить продажи, используя интернет" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Октябрь 2006   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Автор
Михаил Христосенко

Статистика

627 подписчиков
0 за неделю
←   Все выпуски   →

Всё про реинжиниринг и автоматизацию для директора.


Выпуск 17 (продублировано, выпуск 16  От  18 августа 2006 г.) 31 октября 2006г.

Здравствуй дорогой мой читатель.

Сегодня поговорим о средствах моделирования, и их роли в ИТ технологиях.

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

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

·         Представители заказчика, руководители или будущие пользователи.

·         Разработчики и программисты.

·         Конкуренты и хакеры.

 Какие же программные продукты используются для описания процессов бизнеса?

·         Word

·         Front Page

·         BPWin, ERWIn

·         Visio

·         PowerPoint

·         Rational Rose

·         Aris

·         Oracle Designer

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

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

…Это Computer Associates BPwin, версия 4.0 которого вышла в этом году. BPwin является мощным инструментом для создания моделей, позволяющих анализировать, документировать и планировать изменения сложных бизнес-процессов. BPwin предлагает средство для сбора всей необходимой информации о работе предприятия и графического изображения этой информации в виде целостной и непротиворечивой модели. Причем, поскольку модель является некоторым графическим представлением действительности, можно утверждать, что человек вернулся к своему излюбленному средству документирования бизнес-процессов — к рисунку. Но возвращение это произошло на новом уровне — целостность и непротиворечивость модели-рисунка (качества, о которых раньше не было и речи) гарантируются рядом методологий и нотаций, которым следуют создатели модели. BPwin поддерживает три таких методологии: IDEF0, DFD и IDEF3, позволяющие анализировать ваш бизнес с трех ключевых точек зрения:

  • С точки зрения функциональности системы. В рамках методологии IDEF0 (Integration Definition for Function Modeling) бизнес-процесс представляется в виде набора элементов-работ, которые взаимодействуют между собой, а также показывается информационные, людские и производственные ресурсы, потребляемые каждой работой.
  • С точки зрения потоков информации (документооборота) в системе. Диаграммы DFD (Data Flow Diagramming) могут дополнить то, что уже отражено в модели IDEF3, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией между бизнес-функциями внутри системы. В тоже время диаграммы DFD оставляют без внимания взаимодействие между бизнес-функциями.
  • С точки зрения последовательности выполняемых работ. И еще более точную картину можно получить, дополнив модель диаграммами IDEF3. Этот метод привлекает внимание к очередности выполнения событий. В IDEF3 включены элементы логики, что позволяет моделировать и анализировать альтернативные сценарии развития бизнес-процесса.

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

IDEF0. Основной из трех методологий, поддерживаемых BPwin, является IDEF0. IDEF0, относится к семейству IDEF, которое появилось в конце шестидесятых годов под названием SADT (Structured Analysis and Design Technique). IDEF0 может быть использована для моделирования широкого класса систем. Для новых систем применение IDEF0 имеет своей целью определение требований и указание функций для последующей разработки системы, отвечающей поставленным требованиям и реализующей выделенные функции. Применительно к уже существующим системам IDEF0 может быть использована для анализа функций, выполняемых системой и отображения механизмов, посредством которых эти функции выполняются. Результатом применения IDEF0 к некоторой системе является модель этой системы, состоящая из иерархически упорядоченного набора диаграмм, текста документации и словарей, связанных друг с другом с помощью перекрестных ссылок. Двумя наиболее важными компонентами, из которых строятся диаграммы IDEF0, являются бизнес-функции или работы (представленные на диаграммах в виде прямоугольников) и данные и объекты (изображаемые в виде стрелок), связывающие между собой работы. При этом стрелки, в зависимости от того в какую грань прямоугольника работы они входят или из какой грани выходят, делятся на пять видов:

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

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


Рис 1. Пример контекстной диаграммы (отсутствует).

Как видно на Рис.1, BPwin позволяет выделять работы и стрелки разными цветами, а также привязывать имена стрелок к самим стрелкам (стрелка по имени “Отчетность”), что повышает наглядность и читаемость диаграммы.

После того как контекст описан, проводится построение следующих диаграмм в иерархии. Каждая последующая диаграмма является более подробным описанием (декомпозицией) одной из работ на вышестоящей диаграмме. Пример декомпозиции контекстной работы показан на Рис.2. Описание каждой подсистемы проводится аналитиком совместно с экспертом предметной области. Обычно экспертом является человек, отвечающий за эту подсистему и, поэтому, досконально знающий все ее функции. Таким образом, вся система разбивается на подсистемы до нужного уровня детализации, и получается модель, аппроксимирующая систему с заданным уровнем точности. Получив модель, адекватно отображающую текущие бизнес-процессы (так называемую модель AS IS), аналитик с легкостью может увидеть все наиболее уязвимые места системы. После этого, с учетом выявленных недостатков, можно строить модель новой организации бизнес-процессов (модель TO BE).


Рис. 2 Пример диаграммы декомпозиции (отсутствует)

            Вот примерно так будет выглядеть описание процессов в этом CASE средстве.

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

 Word.

Здесь свои «НО»

Я работал с отчетом корпорации на букву  Г. Предложения по реинжинирингу (по результатам обследования) Это 580 страниц убористого текста вперемешку с рисунками. В компании заказчика этот документ хотя бы 1 раз до конца не прочитал никто (по моим сведениям). Документ вот сохранился, а компании уже нет.

Front Page

Получается блок связанных текстовых документов, но нет рисунков по тексту.

Отчет корпорации интегратора на букву К из 560 листов текста, сотрудники заказчика до сих пор читают с некоторым изумлением.

Rational Rose основу которой составляет Unified Modeling Language (UML)  - позволяет описать многоуровневую структуру процесса вплоть до получения программного кода. Но для заказчика приходиться собирать отдельные тексты и вставлять диаграммы из Rational Rose.

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

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

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

В более поздних фазах цель меняется и все описание делается для более полного понимания кодировщиками (программистами), подробно описываются классы, атрибуты классов, войства.и др. Т.К. Главный критерий – скорость внесения изменений в продукт и себестоимость.

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

И несколько распространенных заблуждений по поводу средств моделирования:

·         Хорошее CASE средство может компенсировать слабые знания предметной области.

·         Виртуозное владение CASE средствами может компенсировать недостаток способностей и таланта.

·         Приобретение дорогого CASE средства позволит выполнить работу по разработке ПО без привлечения высококвалифицированных программистов.

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

по адресу Kaktus-m@mail.ru

Все права защищены. Перепечатка только с разрешения автора.

До скорой встречи,

 Александр.

Архив  http://subscribe.ru/archive/economics.tech.banalnosti
В избранное