СМ-Консалт
 

Моделирование бизнес-процессов автоматизируемой предметной области при помощи диаграмм деятельности (Activity diagram) с использованием RSA

Статьи Аналитика


 Моделирование бизнес-процессов автоматизируемой предметной области при помощи диаграмм деятельности (Activity diagram) с использованием RSA

Галина Карабанова, Александр Новичков
Статья опубликована на сайте IBM  DeveloperWorks


Ссылки на дополнительные материалы:

17 ноября 2009 года, ReqLabs. Видео, аудио и презентация доклада «Коммуникации с заказчиком и проектной командой при сборе требований»

Умный в гору не пойдет, умный гору обойдет...

(Почему необходимо выполнять моделирование бизнес-процессов 

Под влиянием различного рода причин (от желания не отставать от модных тенденций до решимости действительно повысить эффективность функционирования) руководством отечественных предприятий все чаще принимается решение о необходимости автоматизации деятельности посредством внедрения информационной системы и/или систем – не важно будь то корпоративная ИС (КИС), покрывающая большинство ключевых процессов предприятия либо «коробочный» программный продукт, заточенный под решение узких специфических задач, таких как управление взаимоотношениями с клиентами либо ведение бухгалтерского учета. Более того, в последние годы наблюдается значительный перевес в сторону случаев обращения за подобного рода услугами к сторонним организациям, специализирующимся на разработке программного обеспечения (ПО), нежели попыток осуществить разработку очередной программной системы (ПС) собственными силами «с нуля». Тем не менее, сам факт передачи на аутсорсинг работ по разработке и/или поставке необходимого ПО, к сожалению, не исключает полностью те риски, которые присущи проектам по  автоматизации деятельности предприятия за счет усилий внутренних специалистов ИТ-подразделений. К таким рискам можно отнести следующие.

1.  Отсутствие у разработчиков полномочий, необходимых для принятия взвешенных проектных  решений относительно целесообразности, технической возможности, необходимости и т.д. реализации требований, поступающих от сотрудников автоматизируемых подразделений и других так называемых внутренних заказчиков (в роли которых могут выступать и представители топ-менеджмента организации). Ярким наглядным примером описанной проблемы может являться ситуация, при которой у руководителя проекта по автоматизации «связаны руки» в буквальном смысле этого слова – т.е. он, являясь лицом, ответственным за успех проекта, при этом не имеет возможности принимать решения о том, что, как и в какие сроки должно быть реализовано.

2.  Ситуация, когда одной лишь автоматизацией добиться ожидаемого эффекта не возможно просто потому, что нелепо автоматизировать то, что само по себе не эффективно и тем более не формализовано в виде четкой документированной последовательности шагов или действий, выполняемых сотрудниками автоматизируемых подразделений. Другими словами, в результате попытки автоматизировать бардак, рискуем получить не более, чем автоматизированный бардак. Причем, еще не известно, что хуже! В качестве небольшого лирического отступления приведем не совсем точную цитату из достаточно известной книги «Камень программиста»: «...говоря, что сложность по своей внутренней сути необъяснима, <…> мы вынуждены создавать все более сложные процедуры, чтобы избежать ответственности». В случае, если мы приступаем к автоматизации прежде, чем ключевые моменты предметной области представлены в виде строгого формализованного описания, мы с большой долей вероятности получим вместо хорошо структурированного программного продукта нечто до такой степени запутанное, что при первых же попытках внести в это «нечто» какие-либо изменения (будь то исправление ошибок либо расширение существующей функциональности) решим, что проще бросить это «гиблое дело» и все переделать!

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

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

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

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

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

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

Всё, возможно, могло быть иначе...

(Правила описания бизнес-процессов. Обоснование возможности применения Activity diagram для описания бизнес-процессов)

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

Итак, каков же должен быть порядок наших действий, чтобы уже на начальных стадиях выполнения проекта по автоматизации, избежать описанных выше негативных последствий? Для того чтобы ответить на этот вопрос, обратимся к стандарту ГОСТ Р ИСО 9001-2001, представляющему собой аутентичный текст стандарта ИСО 9001-2000 «Системы менеджмента качества. Рекомендации по улучшению деятельности». Данный стандарт «направлен на применение "процессного подхода" при разработке, внедрении и улучшении результативности системы менеджмента качества с целью повышения удовлетворенности потребителей путем выполнения их требований». Стандарт ГОСТ Р ИСО 9001-2001 говорит о необходимости определения и управления системой взаимосвязанных процессов с целью повышения эффективности деятельности организации. Общим требованием данного стандарта является утверждение о том, что организация «должна разработать, задокументировать, внедрить и поддерживать в рабочем состоянии систему менеджмента качества», постоянно улучшая ее результативность в соответствии с требованиями стандарта ГОСТ Р ИСО 9001-2001. В рамках системы менеджмента качества организация должна выполнять следующие действия.

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

2.  Определять последовательность и взаимодействие этих процессов.

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

4.  Обеспечивать наличие ресурсов и информации, необходимых для поддержки этих процессов и их мониторинга.

5.  Осуществлять мониторинг, измерение и анализ этих процессов.

6.  Принимать меры, необходимые для достижения запланированных результатов и постоянного улучшения этих процессов.

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

Если распространить требования данного стандарта на процесс автоматизации деятельности предприятия, в ходе которого так или иначе, как правило, существующие на предприятии процессы изменяются, становится понятным, что необходимо, прежде всего, определить существующие на предприятии бизнес-процессы. Причем процессы считаются определенными в том и только том случае, если они описаны, т.е. задокументированы. Итак, приведем определение бизнес-процесса с точки зрения стандарта ГОСТ Р ИСО 9001-2001, а также перечислим основные его атрибуты.

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

Атрибутами бизнес-процесса являются:

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

Потребитель бизнес-процесса:

·  внутренний – то есть находящийся внутри организации и, в ходе своей деятельности, использующий результаты (выходы) предыдущего бизнес-процесса;

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

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

Модель бизнес-процесса – графическое, табличное, текстовое, символьное описание бизнес-процесса либо их взаимосвязанная совокупность.

Определение для каждого бизнес-процесса всех перечисленных составляющих называется описанием бизнес-процесса.

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

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

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

Основными компонентами любой технологии, как известно, являются следующие:

1.  Процесс, определяющий набор осуществляемых действий и их последовательность.

2.  Получаемые на выходе результаты.

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

4.  Состав исполнителей.

Предлагается следующая последовательность действий по описанию и моделированию бизнес-процессов автоматизируемой предметной области:

1.  Составляется описание существующих на предприятии процессов, выполняется построение модели процессов «Как есть».

2.  На основе определенных критериев выявляются «проблемные» процессы и/или действия или, иначе, «проблемы».

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

4.  Строятся модели процессов «Как будет», отмечаются те, которые будут (должны быть) автоматизированы.

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

1.  Описание выполняется в виде набора действий и входов / выходов.

2.  Должны быть указаны исполнители (сотрудники конкретных подразделений, программные средства, другие механизмы и т.д.)

3.  Определенные в процессе описания действия, составляющие процесс, должны быть классифицированы в соответствии с необходимыми критериями.

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

5.  Результатами деятельности по описанию бизнес-процессов должны явиться модели бизнес-процессов автоматизируемой предметной области.

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

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

Важным моментом, упрощающим задачу выявления и последующего описания бизнес-процессов, является тот факт, что большинство процессов для большинства предметных областей являются «стандартными» в определенном смысле этого слова. Т.е. можно утверждать, что существует некоторая достаточно общая концептуальная схема, в которую можно «уложить» практически любой процесс. Наглядным примером такой схемы является следующая – «Инициация (возникновение) – Развитие (становление) – Существование (стадия «жизни») – Исчезновение (гибель)». Если говорить о процессе управления, то для него общераспространенной является схема «Планировать – Делать – Контролировать (проверять) – Действовать», положенная в основу стандарта ГОСТ Р ИСО 9001-2001. При этом если мы хотим применить описанную схему процесса управления к тому или иному объекту или процессу, то нам необходимо обеспечить выполнение следующего набора действий: сохранение информации о планируемых показателях, учет информации о текущем состоянии объекта, анализ плановой информации и информации о текущем состоянии управляемого объекта и регулирование. Нетрудно заметить, что своего рода стандартные процессы или иначе, так называемые, шаблоны процессов присутствуют в любой предметной области. Например, если говорить о деятельности любого магазина, то ее можно уложить в следующую схему: «Обеспечение необходимого товара в наличии – Продажа товара» (доставка товаров из Китая). Если говорить о строительстве зданий, то схема будет выглядеть приблизительно следующим образом: «Выбор и оформление места строительства – Строительство – Сдача готового объекта». И, наконец, всем нам хорошо известно, что процесс разработки программного обеспечения также укладывается в соответствующую концептуальную схему.

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

Диаграммы деятельности (Activity Diagram) унифицированного языка моделирования UML как раз и позволяют отобразить не только сам процесс, но и каркас, в который его можно «уложить», позволяя создать так называемые контейнеры для составляющих процесс действий. Кроме того, действия, составляющие анализируемый процесс, могут быть классифицированы на диаграмме деятельности и в соответствии с другими критериями, набор которых может зависеть как от специфики анализируемой предметной области, так и целей, преследуемых аналитиком. К наиболее общим критериям, тем не менее, можно отнести следующие:

-  Диапазон себестоимости / затрат на выполнение;

-  Частота выполнения / периодичность;

-  Диапазон эффективности (низкая, средняя, высокая);

-  Исполнители:

·  задействованные подразделения, организации;

·  пользователи, информационная система / системы.

-  Многие другие…

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

Диаграммы деятельности предназначены для описания логики процедур, бизнес-процессов и потоков работ. Нотация диаграммы деятельности такова, что ее элементы позволяют выполнить полноценное описание бизнес-процессов, более того, с помощью диаграмм деятельности можно выполнить всю необходимую последовательность действий по моделированию бизнес-процессов предметной области с целью последующей их автоматизации в соответствии с описанной выше технологией (см. Табл. 1)

Таблица 1. Соответствие основных элементов диаграммы деятельности (Activity diagram) компонентам бизнес-процесса и технологии его моделирования

Компонент описания бизнес-процесса

Элемент диаграммы деятельности (Activity diagram)

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

Диаграмма деятельности, основнымиэлементами которой являются элементы Action (действие), Activity edge (связи между элементами Action, изображающие либо передаваемые объекты, либо потоки управления), Partition (отделения).

Модель бизнес-процесса (графическое, табличное, текстовое, символьное описание бизнес-процесса либо их взаимосвязанная совокупность).

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

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

Может быть изображен при помощи элемента Partition либо указан в виде текстового описания.

Потребитель бизнес-процесса (тот, кто использует или потребляет результаты деятельности).

Может быть изображен при помощи элемента Partition.

Дополнительные атрибуты бизнес-процесса (например, используемые ресурсы, исполняющие механизмы и т.д.).

Могут быть изображены при помощи элементов Partition либоуказаны при помощи элемента Note, прикрепляемого к необходимому элементу диаграммы деятельности.

Классификация действий, составляющих бизнес процесс, в соответствии с заданными критериями.

Может быть выполнена при помощи элементов Partition.

Идентификация проблемных действий.

Выделение соответствующих элементов Action цветом, классификация с использованием элементов Partition.

Назначение исполнителей отдельных действий в рамках бизнес-процесса.

Может быть выполнено при помощи элементов Partition.

Возможность задать «каркас» выполнения процесса.

Может быть выполнено при помощи элементов Partition иStructuredActivity.

 

Технология моделирования бизнес-процессов, основанная на построении Activity diagram с использованием RSA

 

Место RSA в ряду инструментов, поддерживающих ЖЦ разработки ПС

Деятельность по выявлению и анализу бизнес-процессов автоматизируемой предметной области, безусловно, несколько выбивается из набора «обязательных для выполнения» процессов в ходе проекта по разработке информационной системы. Более того, анализ существующих и проектирование на его основе новых бизнес-процессов может выполняться и не в рамках проекта по разработке программной системы, а, например, просто в рамках проекта по повышению эффективности деятельности организации и/или качества выпускаемой ею продукции и/или услуг. Для целей моделирования бизнес-процессов могут быть использованы различные специализированные нотации, такие как ARIS, BPML, IDEF0 и др., и, соответственно, инструменты, их поддерживающие, а также и инструменты, поддерживающие унифицированный язык моделирования UML, предназначенный, тем не менее, прежде всего, для разработки программных систем.

IBM Rational Software Architect (RSA) является частью IBM Software Development Platform – набора инструментов, поддерживающих жизненный цикл разработки программных систем. IBM Rational Software Architect (см. Рис. 1) предназначен для построения моделей разрабатываемых программных систем с использованием унифицированного языка моделирования UML 2.0, прежде всего моделей архитектуры разрабатываемого приложения. Тем не менее, RSA объединяет в себе функции таких программных продуктов, как Rational Application Developer, Rational Web Developer и Rational Software Modeler, тем самым предоставляя возможность архитекторам и аналитикам создавать различные представления разрабатываемой информационной системы с использованием языка UML 2.0, а разработчикам – выполнять разработку J2EE, XML, Web-сервисов и т.д.

Рисунок  1. Внешний вид Rational Software Architect.

 

Следуя принципам RUP, Rational Software Architect позволяет создавать необходимые модели в рамках рабочих процессов таких дисциплин, как:

-  Управление требованиями (Requirements);

-  Анализ и Проектирование (Analysis and Design);

-  Реализация (Implementation).

Кроме того, Rational Software Architect поддерживает технологию разработки, управляемой моделями (model-driven development, MDD), позволяющую моделировать программное обеспечение на различных уровнях абстракции с возможностью трассируемости.

Но, как мы уже говорили выше, прежде чем приступать к моделированию создаваемого программного обеспечения, необходимо построить модели автоматизируемой предметной области, которые и будут являться основой для построения необходимых моделей разрабатываемых программных систем. Одними из таких необходимых моделей являются модели подлежащих автоматизации  бизнес-процессов, выполненные, например, с использованием диаграмм деятельности (Activity diagram) языка UML. Проиллюстрируем на конкретном примере возможность применения описанной выше технологии моделирования бизнес-процессов при помощи Activity diagram с использованием Rational Software Architect.

Пример использования RSA для целей моделирования бизнес-процессов

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

Что такое модель с точки зрения Rational Software Architect? Это набор необходимых диаграмм, позволяющих отобразить различные представления, например, моделируемого процесса и используемых на этих диаграммах элементов. Rational Software Architect предоставляет набор шаблонов моделей, представляющих собой базовую структуру для возможно необходимых моделей, таких как Use Case Model, Service Design Model, Blank Model и др. Более того, он предоставляет возможность создать в случае необходимости собственный шаблон модели для повторного использования в других проектах. В рамках данной статьи мы не будем углубляться в нюансы создания и сохранения шаблонов моделей, а рассмотрим лишь один из возможных вариантов использования стандартного шаблона Blank Model для целей построения моделей бизнес-процессов «Как есть» и «Как будет» с использованием Activity diagram.

Итак, первым нашим шагом будет являться создание структуры нашей модели бизнес-процессов. Для этого необходимо создать две модели «Blank Model» с различными наименованиями:

1.  «Business Process Model "As-Is"»;

2.  «Business Process Model "As-To-Be"».

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

Рисунок 2. Структура моделей анализируемых бизнес-процессов «Как есть» и «Как будет».

 

Следующим шагом будет изображение первого представления процесса «Заключение договора аренды» - «Как есть» (см. Рис. 3). В качестве критерия для классификации выполняемых в ходе анализируемого процесса действий выберем «Использование инструментальных средств». При этом заметим, что данный выбор был обусловлен тем фактом, что достаточно часто «проблемы» встречаются в тех действиях и/или процессах, которые не «покрыты» теми или иными информационными системами. Кроме того, это тот фактор, который очень легко выявить на начальных стадиях анализа, он буквально бросается в глаза.

 

Рисунок 3. Представление 1 процесса «Заключить договор аренды» - «Как есть».

 

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

Рисунок 4. Представление 2 процесса «Заключить договор аренды» - «Как есть».

 

Для изображения второго представления процесса «Заключить договор аренды»-«Как есть» при помощи диаграммы деятельности необходимо воспользоваться уже существующими элементами Action, использованными для построения Представления 1. Для этого необходимо выделить нужный элемент Action в окне «Project Explorer», кликнуть правой клавишей мыши и в открывшемся контекстном меню выбрать опцию «Copy» (см. Рис. 5).

 

Рисунок 5. Копирование необходимого элемента Action из Представления 1 процесса «Заключить договор аренды».

 

Затем скопированный элемент необходимо вставить на диаграмму, изображающую Представление 2 анализируемого процесса. Для этого в окне «Project Explorer» необходимо выделить элемент Activity «Заключить договор аренды. Представление 2», являющийся своего рода контейнером для диаграммы деятельности, изображающей второе представление процесса «Заключить договор аренды», и выбрать в выпадающем контекстном меню опцию «Paste» (см. Рис. 6).

 

Рисунок 6. Вставка необходимого элемента Action из Представления 1 процесса «Заключить договор аренды» в Представление 2.

 

При этом копируемый элемент попадет в область изображаемой диаграммы деятельности, как показано на Рис. 7. После этого его необходимо будет только перенести в необходимое отделение, или, иначе «Partition».

 

Рисунок 7. Размещение вставляемого элемента Action из Представления 1 процесса «Заключить договор аренды» на диаграмме Представления 2.

 

Итак, мы построили 2 представления для процесса «Заключить договор аренды», составляющие модель процесса «Как есть». Следующим нашим шагом является идентификация «проблем». С этой целью можно выделить цветом действия, которые являются источниками проблем, например, воспользовавшись Представлением 1 (хотя, в случае особой необходимости, можно было бы и новое создать) – см. Рис. 8.

 

Рисунок 8. Идентификация действий, являющихся источниками «проблем», посредством цветового выделения.

 

В результате были выявлены следующие проблемы:

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

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

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

Таблица 2. Проблемы и пути их решения

Действие процесса «Как есть», являющееся источником проблем

Описание проблемы

Пути решения проблемы

1. Рассчитать арендную плату

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

1. Автоматизировать процессы подготовки договора аренды и расчета арендной платы посредством внедряемой ИС

2. Подготовить проект договора

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

2. Реализовать необходимый функционал выводимой из эксплуатации системы учета арендных платежей посредством внедряемой ИС

3. Обеспечить сохранение сведений о подготовленном проекте договора во внедряемой ИС

4. Внести сведения о заключенном договоре в бухгалтерскую систему

4. Обеспечить возможность автоматизированного предоставления сведений из внедряемой ИС о заключенном договоре в бухгалтерскую систему.

5. Сохранить бумажный экземпляр договора в папке с арендным делом

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

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

Итак, решить идентифицированные проблемы можно, перестроив процесс «Заключить договор аренды» таким образом, чтобы часть действий, выполняемых в рамках данного процесса, была передана внедряемой информационной системе, как показано на Рис. 9.

Рисунок 9. Модель процесса «Заключить договор аренды»-«Как будет» (с учетом автоматизации некоторых действий).

 

Следующим шагом будет формирование требований к разрабатываемой информационной системе на основе построенной модели процесса «Как будет» и последующее построение моделей разрабатываемой информационной системы на основе сформулированных к ней требований.

Заключение

К сожалению, применение всех описанных выше рекомендаций не всегда позволит избежать различного рода проблемных ситуаций, возникающих в процессе разработки программных систем. Выполнение рекомендаций по описанию и анализу существующих в автоматизируемой организации бизнес-процессов является лишь первым шагом на пути к корректно сформулированным требованиям и построенным на их основе моделям разрабатываемых информационных систем, позволяющих избежать многих болезненных ошибок. Тем не менее, очень многое зависит от квалификации аналитика, выполняющего анализ бизнес-процессов, доступности всей необходимой информации, наличия возможности оказывать влияние на принятие решения о необходимости изменения существующих в организации процессов, прежде чем начинать процесс разработки программного обеспечения. Использование Rational Software Architect позволит, тем не менее, избежать риска «распыления» информации о разрабатываемой системе и автоматизируемой организации по разным инструментальным средствам. Обладая возможностями интеграции с  Rational Requisite Pro, он обеспечивает возможность трассировки от моделей бизнес-процессов автоматизируемой предметной области к сформулированным на их основе требованиям и далее к моделям разрабатываемой программной системы.


 

Об авторах:

Новичков Александр работает в области информационных технологий с 1994 года. Является руководителем отдела консалтинга и внедрения IBM Rational. Участвовал более чем в 20 успешных проектах внедрения IBM Rational в таких организациях как Банк внешней торговли, ОАО "Татнефть", Национальный банк "ТРАСТ", Банк "Русский стандарт", ОАО "Иркут Авиа", ЗАО "АйТи", ЗАО "Аплана", Сбербанк России, Центральный банк Российской Федерации, ОАО "Русский алюминий" и многих других. Имеет более 30 публикаций научных и научно-популярных материалов. Является сертифицированным специалистом по следующим продуктам IBM Rational: ClearCase for Windows, ClearQuest for Windows и UCM Essentials. За время работы в консалтинге им обучено более 500 специалистов ведущих IT-компаний России и СНГ. Является руководителем отдела внедрения и консалтинга в компании СМ-Консалт (www.cmcons.com). Связаться с ним можно по адресу rational.tools.info@gmail.com
Перейти в блог - http://anovichkov.msk.ru

Карабанова Галина является ведущим проектировщиком отдела сопровождения специализированного программного обеспечения ЗАО «Лимб» и аспирантом кафедры Информационных систем в экономике экономического факультета Санкт-Петербургского государственного университета (СПбГУ). Имеет опыт участия в проектах разработки и/или адаптации информационных систем, решающих различные классы экономических задач (от систем планирования и учета поступлений денежных средств до систем управления объектами земельно-имущественного комплекса) в качестве бизнес-аналитика, аналитика требований, постановщика задач перед программистами. Основные области деятельности – процессы разработки ПО, анализ бизнес-процессов и их моделирование, оценка эффективности внедрения ИС на предприятии заказчика.

 

10.12.2009

Комментарии

Добавить комментарий (анонимные комментарии не публикуются!!!)

ФИО: 
E-mail: 
Тема: 
Комментарий: 
Оценка:   
 
 
 
 
 
Код подтверждения:
   

Новости СМ-Консалт

Вышла версия BIPULSE 6.2

Мастер-класс для тренеров и руководителей "Работа в аудитории". 1 ступень уже в марте

Обновлено расписание тренингов до марта 2017 года

Новые статьи в библиотеке

Мифы про ГОСТ 34

Примеры отраслевых решений на основе BIPULSE

Практика реализации модуля интеграции для Rational Software Architect, позволяющего преобразовывать низкоуровневое представление процесса из IBM Rational ClearQuest в UML

Что удивляет в русских менеджерах иностранцев

Разработка ПО с использованием лучших мировых практик и инструментов на Иркутском авиационном заводе

Презентация доклада для IT Global Meetup Санкт-Петербург: "Почему Agile так популярен? Взгляд циника и психолога"

Заказчики и истории успеха

Наши тренинги, семинары, курсы

Дружите с нами на FaceBook

Проверить настройки
Компания
Сделано в СМ-Консалт
Услуги 
Компетенция
  • CMC-TotalTest (скоро)
    уникальная разработка автоматизации функционального тестирования. Альтернатива HP UFT, IBM RFT и Microsoft!
  • CMC-Bisquiter
    автоматизированное тестирование АБС "Бисквит"
  • CMC-Formater
    тестирование печатных и экранных форм
  • CMC-TerminalTest
    тестирование терминальных приложений
  • ProjectTracker
    интеграция ALM и MS Project
  • GanttChart
    модуль управления проектами для IBM Rational ClearQuest и TeamConcert
    Все разработки СМ-Консалт >
  • ИТ-консалтинг
  • Автоматизированное тестирование
  • Ручное тестирование
  • Аутсорсинг тестирования
  • Оптимизация бизнес-процессов
  • Внедрение методологии и инструментов ALM
  • Обучение и коучинг
  • Разработка ПО
  • Интеграция
ООО СМ-Консалт (СМК), 2004-2017.
Карта сайта