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

Добавил:

Upload

Опубликованный материал нарушает ваши авторские права? Сообщите нам.

Вуз:

Предмет:

Файл:

Реинжиниринг и управление бизнес-процессами

.docx

Скачиваний:

174

Добавлен:

05.06.2015

Размер:

26.21 Кб

Скачать

Вопросы
итогового тестирования:

  1. Ассоциация
    рабочих объектов требуется для
    отслеживания:

  • Выборки
    из хранилища соответствующих объектов;

  • Соответствия
    объектов друг другу.

  1. Бизнес-процессы
    на предприятии характеризуются:

  • Четко
    определенными во времени началом и
    концом;

  • Внешними
    интерфейсами;

  • Затратами
    времени;

  • Затратами
    труда;

  • Затратами
    материалов.

  1. В
    состав проектной группы (команды)
    входят:

  • Работники
    предприятия и консультанты.

  1. Владелец
    процесса – это структурное подразделение,
    которое:

  • Исполняет
    и координирует исполнение операций
    процесса;

  1. Выберите
    две ступени расчета стоимости
    бизнес-процесса, соответствующие методу
    стоимостного анализа процессов
    (АВС-методу):

  • Стоимость
    соответствующих функций переносится
    на стоимостные объекты;

  • Все
    затраты центров ответственности
    распределяются по функциям бизнес-процесса;

  1. Выделение
    бизнес-процессов предполагает проведение:

  • Экспертного
    многокритериального оценивания.

  1. Границы
    бизнес-процесса определяются:

  • Выполнением
    требований клиента процесса;

  • Сменой
    на выходе операции управляемого объекта
    преобразований.

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

  • Дезагрегации.

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

    • Обобщения.

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

  • Информационные,
    материальные и финансовые потоки.

  1. Задачи
    стоимостного анализа процессов:

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

  • Максимально
    сократить функции, не добавляющие
    стоимость;

  • Выбрать
    функции с низкой стоимостью из возможных
    альтернатив.

  1. Использование
    принципа декомпозиции при построении
    функциональных диаграмм в сочетании
    с методом стоимостного анализа процесса
    позволяет:

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

  • Рассчитать
    стоимость всего бизнес-процесса, зная
    стоимость его операций на нижных уровнях
    диаграммы.

  1. Как
    задается разветвление в процессе:

  • По
    вероятности пути процесса;

  • По
    типу объекта;

  • Произвольно;

  • По
    значению пользовательских атрибутов;

  1. Как
    задаются стоимостные характеристики
    использования ресурсов в процессе:

  • На
    факт и время использования ресурса в
    процессе.

  1. Какие
    основные типы статистических данных
    генерируются в ходе имитационного
    эксперимента по моделированию
    бизнес-процесса:

  • Стоимость
    преобразования объектов в процессе;

  • Степень
    использования ресурсов в процессе;

  • Время
    преобразования объектов в процессе;

  • Стоимость
    использования ресурсов в процессе;

  • Пропускная
    способность процесса;

  1. Каково
    назначение репозитария в технологии
    РБП?

  • Документирование
    бизнес-процессов;

  1. Каковы
    ключевые факторы успеха реинжиниринга
    бизнес-процессов?

  • Комплексный
    характер проектных работ;

  • Совместная
    работа консультантов и работников
    компании в командах РБП;

  • Мотивация
    персонала в РБП;

  • Участие
    руководства компании на всех этапах
    РБП.

  1. Какой
    главный критерий эффективности
    организации бизнес-процесса из следующих:

  • Время
    исполнения.

  1. Какой
    подход обеспечивает встраивание
    поставщиков и клиентов в бизнес-процессы
    предприятия:

  • Управление
    поставками по принципу «точно во время»
    (JIT).

  1. Какой
    подход обеспечивает непрерывное
    совершенствование бизнес-процессов:

  • Всеобщее
    управление качеством (TQM);

  1. Какой
    подход обеспечивает сквозное планирование
    основных бизнес-процессов:

  • Управление
    ресурсами предприятия (MRP).

  1. Лидер
    проекта выполняет следующую работу по
    РБП:

  • Ежедневно
    координирует ход выполнения работ по
    РБП;

  1. Метод
    имитационного моделирования используется
    для:

  • Динамического
    анализа бизнес-процессов.

  1. Метод
    учета затрат по функциям используется
    для:

  • Статического
    анализа бизнес-процессов.

  1. Методологический
    центр выполняет следующую работу по
    РБП:

  • Ежедневно
    руководит выполнением работ по РБП.

  1. На
    этапе внедрения проекта РБП выполняется
    следующая работа:

  • Осуществляется
    обучение персонала;

  • Поэтапный
    ввод и тестирование информационной
    системы;

  1. На
    этапе идентификации бизнес-процессов
    выполняется следующая работа:

  • Выделяются
    бизнес-процессы для РБП в соответствии
    со стратегией;

  1. На
    этапе реализации проекта РБП выполняется
    следующая работа:

  • Разрабатывается
    или модернизируется организационно-экономическая
    система;

  • Разрабатывается
    или модернизируется информационная
    система;

  1. Назовите
    ключевые информационные технологии
    для управления основными процессами:

  • Система
    управления потоками работ;

  • Распределенная
    база данных;

  1. Назовите
    ключевые информационные технологии
    для управления инновационными процессами:

  • Информационно-аналитические
    системы;

  • Системы
    имитационного моделирования;

  • Управление
    знаниями;

  1. Назначение
    динамического анализа бизнес-процесса
    заключается в оценке:

  • Производительности
    бизнес-процессов;

  • Использования
    ресурсов в бизнес-процессе;

  • Непроизводительных
    затрат.

  1. Наиболее
    точное определение бизнес-процесса:

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

  1. Обратный
    инжиниринг — это:

  • Исследование
    существующей организации бизнес-процессов.

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

  • Выделению
    классов объектов и определению тех
    действий, в которых участвуют эти
    объекты.

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

  • Управляющими;

  1. Одним
    из принципов реинжиниринга бизнес-процессов
    является:

  • Уменьшается
    количество проверок и управляющих
    воздействий.

  1. Одним
    из принципов реинжиниринга бизнес-процессов
    является:

  • Сочетание
    централизованного и децентрализованного
    подходов.

  1. Организационная
    единица (предприятие, подразделение,
    персонал, отдельные исполнители) – это
    частный случай:

  • Ресурсов.

  1. Основная
    цель реинжиниринга бизнес-процессов
    – целостное и системное моделирование
    и реорганизация:

  • Материальных,
    финансовых и информационных потоков.

  1. Потоки
    объектов (материальных, финансовых,
    информационных) на функциональных
    диаграммах представляются в виде:

  • Интерфейсных
    дуг.

  1. Примеры
    механизмов, участвующих в функциональной
    модели, построенной с помощью методологии
    IDEF0:

  • Оборудование;

  • Персонал;

  • Структурные
    подразделения предприятия;

  1. Принцип
    «вертикального сжатия процесса»
    означает, что:

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

  1. Принцип
    «горизонтального сжатия процесса»
    означает, что:

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

  1. Принципами
    реинжиниринга бизнес-процессов являются:

  • Работы
    выполняются в естественном порядке;

  • Распараллеливание
    выполняемых работ.

  1. Прямой
    инжиниринг — это:

  • Построение
    новой организации бизнес-процессов.

  1. Пул
    объектов используется для размещения:

  • Постоянных
    ресурсов.

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

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

  1. Реинжиниринг
    бизнес-процессов выполняется:

  • В
    связи с необходимостью проведения
    стратегических изменений;

  1. Реинжиниринг
    бизнес-процессов направлен на минимизацию:

  • Сроков
    реализации потребностей клиентов;

  • Использования
    различных ресурсов;

  • Сложности
    процесса управления;

  • Издержек.

  1. Реинжиниринг
    бизнес-процессов охватывает
    перепроектирование бизнес-процессов:

  • Большинства
    структурных подразделений компании

  1. Реинжиниринг
    бизнес-процессов повышает эффективность
    функционирования деятельности компании:

  • В
    десятки раз.

  1. Реинжиниринг
    бизнес-процессов предусматривает:

  • Взгляд
    на построение компании как на инженерную
    деятельность.

  1. Результатом
    оптимизации использования ресурсов в
    бизнес-процессах является:

  • Минимизация
    издержек производства.

  1. Руководящий
    комитет выполняет следующую работу по
    РБП:

  • Выделяет
    и контролирует использование ресурсов
    для РБП.

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

    • Процессы
      выпуска продукции и обслуживания
      клиентов;

  1. Событийная
    цепочка процессов позволяет четко
    определять:

  • Альтернативность
    выполнения процесса;

  • Синхронизацию
    выполнения процесса;

  • Распараллеливание
    выполнения процесса;

  1. Стоимостной
    анализ процессов позволяет более точно
    определять:

  • Распределение
    накладных расходов на стоимостные
    объекты;

  1. Структурное
    моделирование бизнес-процессов
    используется для:

  • Стандартизации
    бизнес-процессов;

  • Определения
    требований к информационной системе;

  • Проведения
    улучшений в организации бизнес-процессов.

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

  • Снизу-вверх;

  1. Условием
    завершения построения функциональной
    модели является:

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

  1. Установите
    соответствие типов клиентов и видов
    бизнес-процессов:

  • Потенциальный
    клиент – инновационный процесс;

  • Внешний
    клиент – основной процесс;

  • Внутренний
    клиент – вспомогательный процесс.

  1. Фактором
    ресурсов называется критерий отнесения:

  • Затрат
    центров ответственности на стоимостные
    объекты.

  1. Функции,
    выполняемые человеком на основе
    рекомендаций, подготавливаемых ЭВМ,
    называются:

  • Экспертные.

  1. Функциональный
    блок в функциональной диаграмме
    бизнес-процесса служит для описания:

  • Функции,
    операции, действия, бизнес-процесса в
    целом.

  1. Функциональные
    блоки преобразуют:

  • Управляющие
    объекты в выходные объекты;

  • Входные
    объекты в выходные, причем выходной
    объект должен качественно отличаться
    от входного;

  1. Функциональный
    подход к моделированию бизнес-процессов
    сводится к:

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

  1. Функциональная
    модель бизнес-процесса характеризуется:

  • Использование
    принципа декомпозиции функции;

  • Графической
    простотой;

  • Многоуровневым
    описанием бизнес-процесса.

  1. Функциональным
    фактором называется критерий отнесения:

  • Затрат
    функции на стоимостные объекты.

  1. Цепочка
    создания добавленной стоимости
    определяет:

  • Последовательность
    выполнения нескольких процессов.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #

Rational
Unified Process
(RUP) — методология
разработки программного обеспечения, созданная компанией
Rational Software.

Принципы

В основе RUP лежат
следующие принципы:

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

Жизненный
цикл разработки     

1. Начало (Inception)

В
фазе «Начало»:

  • Формируются видение и
    границы проекта.
  • Создается экономическое
    обоснование (business case).
  • Определяются основные
    требования, ограничения и ключевая функциональность продукта.
  • Создается базовая версия модели прецедентов.
  • Оцениваются риски.

При
завершении начальной фазы оценивается достижение вехи целей жизненного цикла
(англ. Lifecycle Objective Milestone), которое предполагает соглашение
заинтересованных сторон о продолжении проекта.

2. Начало (Elaboration)

В
фазе «Уточнение» производится анализ предметной области и построение
исполняемой архитектуры. Это включает в себя:

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

Успешное
выполнение фазы разработки означает достижение вехи архитектуры жизненного
цикла
(англ. Lifecycle Architecture Milestone).

3. Построение (Construction)

В
фазе «Построение» происходит реализация большей части функциональности
продукта. Фаза Построение завершается первым внешним релизом системы и вехой
начальной функциональной готовности (Initial Operational Capability).

4. Внедрение (Transition)

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

Модели бизнес-процессов (Business Use Case Model)
– модель, описывающая бизнес-процессы организации в терминах ролей и их
потребностей. Она представляет собой расширение модели вариантов использования
UML за счет введения набора стереотипов Business Actor (стереотип действующего
лица) и Business Use Case (стереотип варианта использования).

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

Пример модели бизнес-объектов для прецедента » Ответ на запрос
» приведен на рис
унке


Моделирование бизнеса. Основные подходы

Время на прочтение
9 мин

Количество просмотров 77K

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

Я уже писал о моделировании при помощи IDEF0 (Знакомство с нотацией IDEF0 и пример использования), об организации работы склада и работе с клиентами от лида до сделки (Внедрение CRM. От регистрации лида до закрытия сделки. Кейс и пояснения), о системе Bizagi (Bizagi. Описание. Пример). И везде я использовал при пояснении примеров и практических решений нотации бизнес-процессов.

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

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

Основные подходы

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

  • Функциональный;
  • Процессный;
  • Ментальный (с применением ментальных карт).

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

Функциональное моделирование

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

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

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

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

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

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

Процессное моделирование (моделирование бизнес процессов)

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

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

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

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

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

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

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

Есть и еще одно очень важное отличие. Функциональную модель невозможно использовать при реализации какой-то либо системы, только для проектирования. А процессный подход позволяет создавать исполняемые модели, т.е. описания последовательности действий, которые мы можем в дальнейшем перевести в какую-то среду для создания системы совместной работы предприятия, основанной на процессном подходе.

Ментальный подход (ментальные карты)

Ментальный подход (ментальные карты)При создании ментальных моделей специалист подходит к моделированию не как к процессу или набору функций, а как к некому набору связанных между собой понятий. Для наглядности я приведу пример — ментальная карта понятия “Процедура снабжения” (см. рисунок).

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

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

Плюсы применения таких ментальных карт очевидны:

  • Не нужно знать какие-то специальные языки;
  • Нет строгих рамок и ограничений при создании схемы;
  • Ментальная карта в большинстве случаев интуитивно понятна;
  • Создавать такие схемы просто.

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

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

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

Методология и языки бизнес-моделирования

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

Методология — это система принципов и стандартов описания бизнес моделей и их последующего анализа. В то время как язык бизнес-моделирования – это не более чем инструмент для разработки моделей бизнеса.

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

Отличие языков разработки бизнес-моделей в от языков проектирования систем

Существует целое семейство языков проектирования систем, которые внешне схожи с языками бизнес-моделирования, например, это Ares Studios, целое семейство языков UML и другие, которые используются для проектирования IT-систем.

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

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

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

Преимущества разработки моделей бизнеса

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

На самом деле, стандарты и правила – это огромный плюс:

  1. Языки моделирования помогают максимально качественно передать информацию. Стандартизация повышает простоту восприятия.
  2. Скорость разработки моделей значительно увеличивается. Языки содержат все необходимые инструменты и графические блоки в готовом виде. Вам не придется «рисовать» или придумывать свою терминологию. Инструментарий уже готов, и работа в его рамках значительно ускоряется. Конечно, язык нужно выучить. Но один раз изучить – это намного быстрее, чем каждый раз придумывать и пояснять собственный набор обозначений.
  3. Снижается число возможных ошибок. Сами элементы системы уже будут «подсказывать» перечень возможных и необходимых действий. А в случае создания исполняемых моделей или неисполняемых, но в строгих рамках правил, всегда можно проверить работу бизнес-модели в исполняемой среде и провести отладку, как при программировании.

Применение моделей бизнеса на практике

Лично я считаю, что бизнес-моделирование стоит применять при решении любых задач, связанных с выявлением проблем и «узких мест», с оптимизацией и модернизацией бизнеса и т.д. Как бизнес-консультант я практически всегда строю модели работы компании или ее подразделений при работе со своими клиентами. Это дает четкое понимание всех этапов работы и позволяет избежать «белых пятен» в этом вопросе.

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

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

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

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

Понравилась статья? Поделить с друзьями:
  • Обязан ли работодатель доставлять работников до места работы в ночное время
  • Перспективные направления развития бизнеса в сфере современных коммуникаций
  • Показатели эффективности использования источников финансирования в компании
  • Общемашиностроительные нормативы времени на электромонтажные работы 1989 г
  • Общество с ограниченной ответственностью управляющая компания фондовый дом