Моделирование основных бизнес-процессов WfMS НИУ ВШЭ - Пермь
Данный параграф содержит описание этапа моделирования WfMS как в целом, так и с учетом конкретных особенностей системы.
Особенности проектирования WfMS НИУ ВШЭ - Пермь
В предыдущем параграфе были описаны преимущества MS SharePoint, используемые при создании системы. Кроме того, там было кратко рассказано о некоторых особенностях WfMS, которым посвящен данный параграф.
С общими требованиями можно ознакомиться в приложении Б, в котором содержится ТЗ на разработку WfMS НИУ ВШЭ - Пермь.
Первым шагом моделирования WfMS стало определение требований. Ниже описаны обобщенные требования, выполнение которых подтверждает, что WfMS достаточна сложна для того, чтобы считаться отдельной системой, существующей в рамках более крупной системы технической поддержки:
Интероперабельность. WfMS должна быть способна к взаимодействию с CRM системой. Системы взаимодействуют путем использования общих списков MS SharePoint на портале службы технической поддержки.
Масштабируемость. НИУ ВШЭ - Пермь реализует стратегию развития до 2020, которая включает в себя увеличение учебных площадей, внедрение новых информационных сервисов и технического оборудования. Потому важно разработать систему таким образом, чтобы в будущем она смогла справиться с увеличивающейся нагрузкой. Отчасти, это свойство достигается тем, что служба технической поддержки представляет собой комбинацию виртуальной службы поддержки и распределенной службы с центральной точкой приема заявок.
Синергичность. В будущем новые идеи и технологии могут быть использованы для улучшения отдельных частей WfMS, поэтому важно, чтобы улучшение отдельных элементов вело к улучшению производительности системы в целом. В качестве примера можно привести время выполнения заявки системой. Если улучшить временной показатель процессов распределение ресурсов и составления отчетности, то время работы системы в целом так же сократится.
Эмерджентность. WfMS представляет собой набор взаимосвязанных процессов, которые по отдельности неспособны дать необходимый результат. Система же объединяет все процессы вместе с целью получения конечного результата.
Наличие средств администрирования и контроля. Крайне обширное и труднореализуемое свойство. Смысл заключается в том, чтобы система всегда содержала инструмент, позволяющий контролировать активности и оценивать эффективность выполняемых действий.
Ранее были описаны роли, исполняемыми людьми в рамках WfMS, однако стоит четко их различать и выделять зоны их ответственности:
Оператор отвечает:
за декомпозицию заявки на задачи;
за назначение ответственного исполнителя (дежурного инженера) на задачу;
за распределение ресурсов на задачи (в зависимости от ситуации – совместно с дежурным инженером);
за архивирование и восстановление задач.
Дежурный инженер ответственен:
за выполнение поставленной оператором задачи;
за заполнение форм отчетности по проделанной работе.
Только люди этих ролей входят в состав WfMS, в то время как обычный пользователь – в состав CRM. Однако в отдельных случаях пользователь может взаимодействовать как с оператором, так и с дежурным инженером.
Оператор отвечает за разбиение заявки на задачи, потому важно определить, что такое задача. В рамках портала задача есть элемент списка задач, имеющий набор полей. В предыдущем параграфе отмечалось, какой статус может иметь задача:
Актуальная – задача находится на стадии выполнения.
Архивная – задача, по тем или иным причинам, отправленная в архив.
Наличие особенности определения задач внутри системы удовлетворяет требованию, описанному в стандарте WfRM, согласно которому WfMS должна включать в свой состав уровень создания и управления рабочих процессов.
Построение моделей основных бизнес-процессов
WfMS НИУ ВШЭ - Пермь
Моделирование как процесс может быть разбит на несколько составляющих: постановка задачи, формализация или создание модели и представление результатов. Правильно составленная модель обеспечит успешное проектирование и разработку системы в целом.
Первым этапом моделирования является постановка задачи. Задача может быть поставлена в любой форме: в виде словесного описания, графического или в виде программного кода. Второй этап – формализация. Он включает в себя создание модели на выбранном формальной языке, опираясь на поставленную задачу. Перед тем как преступить к построению модели важно выбрать инструменты и стандарты. Модель разрабатываемой WfMS может быть построена с помощью различных нотаций, таких как: ARIS, IDEF0/SADT, UML и других.
Было решено, что для построения процессов системы будет использоваться нотация ARIS eEPC. Методология была выбрана благодаря простоте своего освоения и наглядности полученных результатов.
Важнейшей частью при проектировании системы является моделирование процессов этой системы. В приложении А отображены основной бизнес-процесс выполнения заявки и управляющий процесс распределения ресурсов.
В рамках основного бизнес-процесса выполнения заявки отображаются основные процессы, протекающие в WfMS.
Первым этапом процесса является анализ заявки, пришедшей из CRM. Затем происходит декомпозиция заявки на задачи при участии оператора. Следующим важным этапом является процесс распределения ресурсов, схемы алгоритма которого можно посмотреть в приложении Д. После выполнения всех связанных задач, происходит генерация отчета о выполненной работе и его отправка обратно модулю CRM.
Построение процесса, таким образом, позволяет сократить среднее время выполнения заявки путем: распределения обязанностей между оператором и дежурным инженером; реализацией функций распределения ресурсов по задачам и генерацию отчетов о выполненных работах. В противном случае, все эти действия выполняются вручную и зачастую одним человеком.
В предыдущей главе рассматривался XPDL – язык моделирования бизнес - процессов. Его основная идея заключалась в разбиении крупных задач на более мелкие. Этот принцип взят за основу при моделировании WfMS: заявка разбивается на задачи, которые в свою очередь могут включать в себя использование материальных, денежных или трудовых ресурсов. Так же между задачами могут существовать переходы в зависимости от конкретной ситуации.
Далее был определен управляющий бизнес-процесс распределения ресурсов на задачи, модель которого представлена в приложении А.
Выполнение управляющего процесса происходит при участии оператора и программных средств WfMS. Это одна из наиболее важных функций, выполнение которой определяет успешность выполнения главного бизнес-процесса. В рамках проводимой работы по разработке WfMS, данный бизнес-процесс будет реализован на основе списка MS SharePoint и разработанного программного решения в виде обработчиков событий и визуальных веб-частей.
Реализация функционала распределения ресурсов на задачи является наиважнейшей частью WfMS как признак автоматизированной системы. Быстрое и правильное назначение ресурса позволит скоординировать действия КЦ и ВШЭ - Пермь как предприятия вообще.
Было решено классифицировать ресурсы на три вида:
Трудовые ресурсы. Человеческие ресурсы, предполагается, что ресурсами этого вида будут сотрудники КЦ.
Материальные ресурсы. Обычные технические, аппаратные, программные и другие вспомогательные средства. Разделяются на расходные материалы и обычные.
Денежные ресурсы.
Таким образом, после принятия заявки, распределения ресурсов и ее закрытия происходит архивирование связных задач, которые физически она не удаляются, а помещаются в специальный раздел и в случае чего могут быть восстановлены.
Отчет, составленный по итогам выполнения заявки, представляет собой поле «Описание решения» общего списка модулей, отображающее отчеты по связным задачам.
После разработки основных бизнес-процессов, стоит задуматься о поведении системы в целом. Очень часто при проектировании систем пропускаются важные детали, определяющие характер функционирования системы в определенных ситуациях. Потому была составлена схема прецедентов, показанная на рисунке 2.1.
При разработке диаграммы прецедентов были проанализированы различные случаи, которые могут повлиять на логику работы WfMS. Рассмотрение данных прецедентов позволяет заранее разработать систему с учетом критических ситуаций. Основной причиной неправильного функционирования системы могут стать действия человека. Разработанная диаграмма отражает все возможные действия человека при вмешательстве в работу системы. Кроме сотрудников WfMS была рассмотрена ситуация, когда пользователь отменяет заявку, выполнение которой уже началось.
Рисунок 2.1. Диаграмма прецедентов WfMS
|
