В бизнес-моделировании процессы можно условно разделить на два вида исполняемые, которые действительно будут работать при помощи специального обеспечения, например, Bizagi, и неисполняемые, т.е.бизнес-модели, необходимые только для лучшего понимания бизнес-процессов и его специфики.
Исполняемые бизнес-процессы обязательно должны быть выстроены в строгом соответствие всем правилам нотации BPMN, так как в противном случае программное обеспечение не сможет работать корректно с составленной бизнес-моделью. Данные бизнес-процессы требуют глубоких знаний BPMN, а также внимательного отношения к каждой детали, так как вы, по сути, создаете программу (алгоритм) для компьютера, просто используете для этого не текстовый язык, а графические нотации.
Исполняемые процессы нужны, например, на предприятиях, где принят процессный подход к деятельности. Программное обеспечение позволяет вести контроль всех процессов в режиме реального времени, и на основе получаемых на каждом из этапов данных, руководитель компании и подразделений всегда смогут понимать, на каком этапе находится работа по тому или иному процессу. Подобный метод позволяет значительно повысить эффективность управления.
Неисполняемые бизнес-процессы нужны исключительно для демонстрации какой-либо бизнес-модели. Это может быть диаграмма, отображающая реальное положение дел на предприятии, может быть наглядной иллюстрацией к предложенным изменениям при реинжиниринге. В этом случае, конечно, можно использовать любые удобные инструменты, в том числе, традиционный для многих IDEF0, или декомпозиция IDF0 до уровня потока работ (EEPC). А соблюдение правил языка моделирование необходимо исключительно для достижения взаимопонимания.
У нас будут смоделированы неисполняемые бизнес-процессы (бизнес-процесс разработка программного обеспечения с техническим заданием, второй доработка программного обеспечения без технического задания, третий заведение технического требования, и четвертый заведение требования на документацию программного обеспечения), произведен функционально-стоимостной анализ, затем они будут доработаны до исполняемых бизнес-процессов (будут добавлены графические формы, модели данных, пользователи и тд) и произведена автоматизация действий.
В качестве средства BPM была выбрана Bizagi. Она удовлетворяет нашим условиям выбора. Эта система является бесплатная, прекрасно интегрируется с различными веб сервисами, пользователи прекрасно интегрируются с Active Directory, система использует операционную систему семейства Windows, SQL базу данных и IIS веб сервис. Система проста для разработки в ней бизнес-процессов и удобна в использовании. Нотация для моделирования будет использоваться BPMN 2.0
В среде моделирования Modeler будет произведено моделирование бизнес-процессов. В среде проектирования Suit для этих процессов будет спроектирована база данных, спроектированы графические формы, будут заданы бизнес правила, заданы группа пользователей. В Engine будут произведены пуско-наладочные работы.
Пользователи будут делиться на 9 бизнес ролей: контрагент внешний клиент, менеджер проекта, руководитель проекта, аналитик, тестировщик, программист; администратор, бизнес аналитик и аналитик (не будут участвовать в бизнес-процессах, но такие бизнес роли будут предусмотрены системой).
Бизнес-процесс Разработка программного обеспечения с техническим заданием будет автоматизировать бизнес-процесс начиная от момента подачи заявки клиента и заканчивая приемкой.
Процесс Разработка программного обеспечения осуществляется по водопадной модели жизненного цикла разработки ПО. Каскадная (водопадная) модель строго следует последовательности всех этапов разработки ПО и не предполагает возвращения с текущего этапа на предыдущий. Модель жизненного цикла будет включать следующие этапы: выработка системных требований, выработка требований к ПО, анализ, проектирование, кодирование, тестирование, эксплуатация. Разработанная схема бизнес-процесса Разработка программного обеспечения с техническим заданием представлена ниже
После разработки бизнес-процесса необходимо разработать модель данных.
Главная таблица RazrabotkaPO будет иметь следующий атрибутивный состав: email, веб сайт, дата заказа, имя, мобильный телефон, номер заявки, отчество, прикрепленный документ, сообщение, статус разработки, статус тестирования, фамилия и связь с таблицей Approval и Концепция. Таблица Approval будет иметь следующие атрибуты: визирование менеджер, визирование менеджер проекта, дата визирования менеджером, дата визирования менеджером проекта, менеджер, менеджер проекта. Таблица Концепция: дата заявки, дата утверждения, имя пользователя, имя утвердившего, комментарий, концепция, утверждение и связь с таблицей техническое задание. Техническое задание имеет следующий атрибутивный состав: стоимость аналитика, стоимость программиста, стоимость тестировщика, трудозатраты на аналитика, трудозатраты на программиста, трудозатраты на тестировщика.
После разработка модели данных необходимо разработать визуальные формы.
После разработки графических форм необходимо разработать бизнес правила. Для каждого условия исключающие или нам необходимо прописать правило, по которому будет проверяться условие для дальнейшего перехода к следующей функции
Условия:
RazrabotkaPO.idKontsepsiya.Utverzhdenie is equal to true
RazrabotkaPO.idKontsepsiya.Utverzhdenie is equal to false
RazrabotkaPO.Statusrazrabotki is equal to false; DorabotkaPOTZ.Statusrazrabotki is equal to true;
RazrabotkaPO.Statustestirovaniya is equal to true;
RazrabotkaPO.Statustestirovaniya is equal to false;
После определения бизнес правил определяем исполнителей задач.
У нас будут существовать следующие роли: chief manager (руководитель проекта), devOps (системный администратор), manager (менеджер), programmer (программист), stakeholder (внешнее лицо), tester (тестировщик), admon viewer (администратор).
Мы можем определить 4 состояний задач для исполнения пользователями: по нагрузке, все, последовательны, первый доступный. Имеются условия and (и), or (или) и properties (свойства), благодаря котором мы можем масштабировать количество пользователей.
Определяем условия для всех функций:
Or Role==Stakeholder or Role == Admon Viewer;
Or Role==Manager or Role == Admon Viewer;
Or Role==Chief manager or Role == Admon Viewer;
Or Role==Programmer or Role == Admon Viewer;
Or Role==DevOps or Role == Admon Viewer;
Or Role==Analyst or Role == Admon Viewer;
Or Role==Tester or Role == Admon Viewer;
Бизнес-процесс Технологическое требование будет автоматизировать процесс начиная от подачи заявки клиента для реализации технологического требования под необходимые нужды и заканчивая выкладыванием решения в открытый доступ. В качестве технологического требования может быть: создание серверной инфраструктуры, разворачивание необходимых виртуальных машин, настройка коммутационного оборудования и другое.
Технологическое требование будет включать следующие этапы: инициализация заявки, производственные работы, верификация инициатором и выкладывание в открытый доступ.
Разработанная модель данных бизнес-процесса Технологическое требование представлена ниже
Таблица WSUSER является системной, из системной таблицы мы можем получить текущего пользователя, контактные данные и всю остальную информацию. Бизнес-процесса Технологическое требование имеет следующие визуальные формы
Для каждого условия исключающие или нам необходимо прописать правило, по которому будет проверяться условие для дальнейшего перехода к следующей функции.
Условия:
Tekhnologicheskoetrebova.ready is equal to true;
Tekhnologicheskoetrebova.ready is equal to false;
Tekhnologicheskoetrebova.status_analyst is equal to true;
Tekhnologicheskoetrebova. status_analyst is equal to false;
На этапе определения Activity Action (Events) на кнопку Сохранить в графическую форму процесса Выполнение добавляем следующие выражения:
Currenttask в поле номер заявки будет подставляться системный номер заявки;
CurrentData в поле дата запроса будет добавлять системная дата;
Выражение:
<TekhnologicheskoeTrebova.Nubertrebovanie> = Me.Case.CaseNumber;:
<TekhnologicheskoeTrebova.Requestdate> = DateTime.Now; После определения бизнес правил определяем исполнителей задач.
У нас будут существовать следующие роли: programmer (программист), stakeholder (внешнее лицо), devops (системный администратор), admon viewer (администратор), analyst (аналитик).
Мы можем определить 4 состояний задач для исполнения пользователями: по нагрузке, все, последовательны, первый доступный. Имеются условия and (и), or (или) и properties (свойства), благодаря котором мы можем масштабировать количество пользователей. Определяем условия для всех функций
Or Role==Stakeholder or Role == Admon Viewer;
Or Role==Manager or Role == Admon Viewer;
Or Role==Chief manager or Role == Admon Viewer;
Or Role==Programmer or Role == Admon Viewer;
Or Role==DevOps or Role == Admon Viewer;
Or Role==Analyst or Role == Admon Viewer;
Or Role==Tester or Role == Admon Viewer;
Для запуска бизнес-процессов в корпоративной сети необходимо развернуть серверную операционную систему Windows, настроить DNS сервер, установить IIS сервер, развернуть базу данных.
В качестве серверной операционной системы была выбрана Windows Server 2012 R2. В качестве сервера базы данных был выбран SQL Server.
После установки СУБД устанавливаем оснастку IIS и проверяем работоспособность веб сервера.
Необходимо добавить организационные структуры, для разделения пользователей по ролям и отношению к организации
Проверка работоспособности бизнес-процессов
Экспортируем наши бизнес-процессы в статические веб страницы и создадим портал, где мы будем хранить всю документацию по бизнес-процессам, и где любой пользователь внутренней сети предприятия сможет посмотреть её
