Найти тему

Логика бизнес-процессов - часть 2

Оглавление

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

Добавить к сведениям о нотациях можно еще две:

  • BPMN (Business Process Model and Notation) - нотация и модель бизнес-процессов, система обозначений позволяющая моделировать бизнес-процессы
  • EPC (Eevent-driven process chain) - событийная цепочка процессов используется для бизнес-моделирования, может быть применена для настройки системы планирования ресурсов предприятия и для улучшений бизнес-процессов.

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

Категории бизнес-задач организации

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

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

Перспективные модели бизнес-процессов

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

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

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

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

Условия, корректирующие проект бизнес-процесса

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

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

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

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

Лучше предусмотреть все возможные особенности бизнес-маршрутизации на стадии проектирования, чем вносить изменения во внедрённый продукт.

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

-2

автор публикации: Демешин С.В.