CC BY
338
№ 1 (49) 2014
И. Г. Фёдоров, канд. техн. наук, профессор Московского государственного университета экономики, статистики и информатики (МЭСИ), IFedorov@mesi.ru
Методика выявления целей, задач и требований бизнес-процесса1
Ошибка в постановке цели бизнес-процесса приводит к его неправильному анализу и как следствие к просчетам в формировании требований к проектируемой информационной системе . В данной работе систематизированы следующие понятия: цель, задача и требование, что крайне важно для правильного исследования бизнес-процесса . Формулируется методика выявления операционной цели бизнес-процесса, описывается способ формирования требований к процессу и к его продукту
Ключевые слова: цели и задачи бизнес-процессов, требования .
введение
Моделирование бизнес-процессов принято рассматривать как начальный этап автоматизации предприятия. Оно используется для сбора требований к проектируемой системе, и начинается эта работа с выявления цели процесса. Хам-мер и Чампи определяют бизнес-процесс как упорядоченную последовательность действий, выполняемых ради достижения заранее поставленной цели [1]. Однако нередко возникает ситуация, когда все работы выполнены, но цель не достигнута. Поэтому необходимо четко определить результат процесса, все критерии успеха, а также условия, при которых процесс завершается неудачей. Ошибка в постановке цели приведет к неправильному анализу процесса, просчетам в формировании требований.
Для примера рассмотрим банковский процесс оформления потребительского кредита. Казалось бы, наиболее верно предположить, что целью этого процесса является выдача кредита. Но как тогда трактовать мотивированный отказ клиенту? Следует ли его рассматривать как брак (результат не соответствует установленным требова-
1 Статья опубликована при поддержке гранта РФФИ № 13-07-06010.
ниям) или как успешное завершение? При предложенной выше постановке цели любой отказ клиенту есть брак, следовательно, с ним необходимо бороться. Однако отказ мог быть мотивирован плохой кредитной историей клиента или его недостаточной платежеспособностью, тогда решение об отказе является правильным и вполне обоснованным — для обеспечения прибыльности своей деятельности банк должен отказывать ненадежным клиентам. Следовательно, можно констатировать, что в результате неверной постановки цели результат исполнения процесса был интерпретирован ошибочно.
Будем помнить, что каждая отдельная операция в составе процесса также имеет конкретную цель и должна завершаться заранее предопределенным результатом. Таким образом, аналитик должен правильно поставить цель всего процесса в целом и каждой его операции в отдельности. В настоящей работе рассмотрим теорию и практику постановки цели самого процесса и составляющих его операций.
Оистематизация терминов «цель» и «задача»
Цель есть идеальный или реальный предмет сознательного или бессознательного стремления субъекта; конечный резуль-
№ 1 (49) 2014
тат, на который преднамеренно направлен процесс [2]. По определению А. И. Приго-жина цель понимается как планируемый результат [3]. Она определяет итог, то, что должно быть достигнуто, однако практически ничего не говорит о том, как он будет получен [4]. Для достижения цели необходимо выполнить некоторые действия. Если по достижении цели действия прекращаются, то цель называют конечной, если нет — промежуточной [5]. Действие, направленное на достижение поставленной цели, называют задачей. Причем должны быть известны начальное и конечное состояния системы, а также алгоритм достижения результата [5]. В случае, когда алгоритм решения неизвестен, ситуацию классифицируют как проблему.
Часто цель ошибочно смешивают с задачей [6]. Задача есть некоторая работа, выполняемая для достижения цели. Одна цель может потребовать решения нескольких задач. Соответственно, результат выполнения каждой задачи принято рассматривать как промежуточную подцель, которая также может быть декомпозирована на подзадачи. В связи с тем, что описывается декомпозиция главной цели на подцели и од-
[5 новременно выявление подзадач, направил
ленных на достижение этих же подцелей,
|| может возникнуть терминологическая пута-
^ ница, и аналитики перестают различать раз-
2 ницу между подцелью (результатом) и работа - I,
4 той, направленной на ее достижение. Что-;§ бы разделить указанные понятия, следует
задать следующие вопросы. Цель отвечает
& на вопрос: чего нужно достигнуть, а зада-
5 ча — что надо сделать, чтобы достигнуть це-Ц ли? Таким образом, цель определяет резуль-^ тат, который необходимо получить в итоге Ц исполнения задачи, а задача — способ по* лучения этого результата.
I
I
г Систематизация термина «требования»
со
| Конечный результат процесса обладает
¡1 определенными свойствами, которые опре-
1= деляют требования к продукту процесса.
Результат достигнут, если все требуемые свойства реализованы. В противном случае он не достигнут. Кроме того, требования могут предъявляться к способу достижения результата, например, оформление кредита должно занимать не более нескольких дней. Если это требование не исполняется, цель считается недостигнутой. Известно, что цель должна быть достижима и измерима [7]. Чтобы определить приближение к цели, проанализируем метрики, сравнивая их с целевыми значениями, последние формулируются с учетом требований. Можно сказать, что требование определяет целевое значение показателя продукта или процесса.
В программной инженерии термин «требования» понимается расширительно, включая в себя цели, задачи, характеристики результата, ограничения на способ его достижения, бизнес-правила. Например, К. Вигерс утверждает, что «требования пользователей (user requirements) описывают цели и задачи, которые пользователям позволит решить система» [8]. Под функциональными требованиями (functional requirements) он понимает функциональность ПО, которую разработчики должны реализовать, чтобы пользователи смогли выполнить свои задачи. Таким образом, функциональные требования есть задачи, иначе говоря, операции бизнес-процесса — недаром он называет их требованиями поведения (behavioral requirements). Выявление операций, образующих процесс, называют раскрытием бизнес-процесса [9].
Здесь и далее будем трактовать термин «требование» в узком смысле, понимая его как набор ограничений, накладываемых на результат или способ его достижения. В такой трактовке требование эквивалентно бизнес-правилу, которое есть некоторое утверждение, ограничивающее отдельные аспекты ведения бизнеса [10]. Например, цель банковского процесса оформления потребительского кредита заключается в принятии обоснованного решения, причем сделать это нужно в установленное нормативное время. Неисполнение любо-
№ 1 (49) 2014
го из требований означает, что результат не достигнут.
Требование так же, как и задачу, не следует смешивать с целью. Например, в рассматриваемом банковском примере аналитики часто пытаются выдвигать дополнительную цель — удовлетворенность пользователя. Однако последнее не может быть целью, поскольку любой отказ, даже обоснованный, вызовет неудовольствие клиента. Но если рассматривать удовлетворенность клиента как требование, оно позволит уточнить результат или способ его достижения. Например, даже отрицательное решение, но принятое в срок, вызовет менее острую реакцию клиента.
Из описанного можно сделать следующие выводы: цель есть образ результата, который мы хотим получить; задача есть работа, которая направлена на достижение цели; требования будем трактовать как ограничения, накладываемые на характеристики результата или на способ его достижения. Если возможно выявить все ограничения, то сможем установить критерии успешного завершения для всего процесса, его подпроцессов и отдельных операций.
стратегические и операционные цели процесса
Следует различать стратегические и операционные цели процесса [11]. Первые, иначе — бизнес-цели, определяют деятельность всего предприятия, которое принято рассматривать как бизнес-систему, образующую одну или несколько цепочек формирования ценности [12]. Как отмечает М. Портер, концепция бизнес-системы основывается на представлении, что с каждой компанией связана цепочка формирования ценности, причем одно предприятие может иметь несколько цепочек [12]. В зависимости от ситуации бизнес-система может покрывать все предприятие целиком или отдельную его часть.
Цепочка формирования ценности состоит из нескольких процессов, каждый из них
имеет собственную индивидуальную цель. Например, деятельность по кредитованию образует следующую цепочку: 1) принять ® решение по кредиту; 2) оформить кредит- за ный договор; 3) обслуживать кредитный договор (принимать платежи, напоминать о просрочке); 4) собирать просроченную задолженность; 5) закрыть кредитный договор. Будем называть цель каждого из подпроцессов цепочки операционной или процессной. Она определяет запланированный результат, получаемый в итоге исполнения каждого из процессов цепочки.
На первый взгляд государственные и некоммерческие организации не создают прибыль, поэтому не могут рассматриваться как бизнес-системы, однако это не так. Во-первых, они создают ценность для своих заказчиков, во-вторых, оказание любой услуги связано с затратами, поэтому даже государственные организации пристально следят за возможностью сокращения своих издержек. Для этого они рассматривают свою деятельность как цепочку формирования ценности, выделяя деятельность, которая увеличивает ценность, и отбрасывая ту, которая увеличивает стоимость.
Бизнес-цель процесса
Бизнес-цель процесса заключается в получении экономического эффекта от соответствующего вида деятельности. Экономический эффект может проявляться не в результате выполнения отдельного процесса, но в результате выполнения всей цепочки. Вернемся к рассмотрению примера, связанного с кредитованием. Безусловно, бизнес-целью банка является извлечение прибыли в результате кредитной деятельности. Обратим внимание на то, что прибыль образуется не после оформления кредита, а после того, как клиент возвратит сумму займа и проценты по кредиту, т. е. после завершения всех процессов, образующих поток формирования ценности. При этом может возникнуть коллизия, поскольку аналитик рассматривает свой процесс в «узком смысле», тогда
№ 1 (49) 2014
как эффект проявится только после завершения последнего из процессов в цепочке, он перестает различать стратегические и операционные цели процесса.
Рассмотрим первый из процессов цепочки. Его цель можно было бы сформулировать как подготовку обоснованного решения по кредиту. Это решение можно охарактеризовать с помощью совокупности требований, предъявляемых к клиенту, например: возраст, платежеспособность и т. д. Кроме того, можно сформулировать требования к самому процессу: например, ограничить время принятия решения, его себестоимость. Таким образом любое обоснованное решение, даже отказ в выдаче кредита, но принятое в срок, рассматривается как успешное завершение процесса, а браком считается необоснованное или запоздалое решение.
Онтология операционной цели процесса
Теоретической основой нижеописанных рассуждений является онтология Бунге-Ван-да-Вебера (Б-В-В), разработанная М. Бун-ге [13] и в дальнейшем развитая Я. Вандом и Р. Вебером [14]. Согласно их представле-[5 ниям мир образован предметами, которые Ц обладают свойствами. Свойство есть атри-|| бут предмета. Свойства могут быть частны-^ ми, присущими отдельному предмету, напри-§ мер, габариты и вес характеризуют каждый предмет в отдельности, или обобщающими, ;§ характеризующими совокупность предметов, например, должность характеризует & группу сотрудников [15]. Предметы могут 5 быть композитными, образуя систему из совокупности простых предметов. Система обладает эмерджентностью — наличием осо-Ц бых свойств, не присущих ее составляющим * по отдельности, а также сумме элементов, ^ не связанных системообразующими связя-| ми. Например, процесс есть совокупность § работ, но, если не связать их особым обра-| зом в систему, мы не сможем получить си-¡1 нергетического эффекта, заключающегося 1= в том, что производительность процесса вы-
ше, чем производительность любой из работ, образующих процесс, выполняемых по отдельности.
Состояние предмета определяется как совокупность всех стабильных состояний всех его атрибутов (пространство состояний), при этом не все состояния рассматриваются как допустимые и не все переходы между состояниями считаются разрешенными [14]. Поскольку каждый из атрибутов изменяется во времени, принято говорить о переменных состояния. Изменение состояния происходит вследствие либо изменения (трансформации) самого предмета, либо его взаимодействия с другими предметами. Изменение состояния предмета, независимо от причины возникновения (внутренней или внешней), называют событием. Таким образом, бизнес-процесс можно рассматривать не только как совокупность работ, но также как последовательность смены состояний некоторого предмета, подвергаемого обработке по ходу процесса.
Критики онтологии Б-В-В справедливо указывают, что она применима только к предметам материального мира, но не применима к идеальным. В том числе она оставляет вне рассмотрения институциональную реальность, объектами которой являются такие понятия, как «вознаграждение», «прибыль», «услуга», «корпорация», «университет». Ни одна из перечисленных сущностей не является материальным объектом и существует только в нашем представлении. Попытаемся обойти это ограничение, сопоставляя институциональные понятия с объектами реального мира. Рассмотрим для примера понятие «коммерческий договор» — соглашение двух или более лиц, предусматривающее передачу продавцом товара или услуги покупателю в обмен на вознаграждение. Будем сопоставлять этому институциональному понятию реальный документ «договор», в котором фиксируются важные условия сделки. Для целей информационного моделирования сопоставим его с информационным объектом «договор». В качестве второго примера рассмотрим понятие «опера-
№ 1 (49) 2014
ционная прибыль», определяемое как разность между нетто-выручкой и расходами по сделке. Выручка и расходы фиксируются в кассовой книге. Таким образом, прибыль сопоставляется с записями в информационном объекте компьютерной системы. Подменяя институциональные сущности сопоставляемыми им материальными или информационными объектами, расширяем возможности применения онтологии Б-В-В.
Согласно представлениям, развитым М. Хомяковым и И. Байдером [16], исполнение процесса можно рассматривать как траекторию движения объекта в многомерном пространстве его состояний, осуществляемое до тех пор, пока не будет достигнуто конечное состояние. Это движение навстречу цели осуществляется посредством выполнения операций процесса. При этом следует обращать внимание на события — они бывают внутренними, когда объект достигает некоторого промежуточного состояния, или внешними, когда произошло изменение сущности, которая находится вне исследуемого процесса [14]. Например, после завершения этапа проверки заявки клиента объект — заявка принимает стабильное промежуточное состояние «Заявка проверена». А если истек промежуток времени, отведенный на выполнение задания, произойдет внешнее событие, которое изменяет траекторию исполнения процесса. Событие может перевести объект в состояние, из которого результат не достижим. В примере выше, если превышен лимит времени, дальнейшее исполнение процесса может оказаться нецелесообразным. Процесс может иметь несколько конечных состояний, причем одно соответствует успешному завершению и связано с достижением цели, а остальные соответствуют сбоям или отказам в его исполнении. Таким образом, цель можно рассматривать как некоторое состояние объекта, которое определено как конечное.
Чтобы упростить анализ поведения системы, Д. Харел предложил разделять количественные состояния переменной и каче-
ственные, которые происходят при определенном сочетании значений атрибутов переменной [17]. Например, документ «Заявка» ® включает имя клиента, адрес, описание за- ^ каза. Заполнение отдельных полей заявки — имени клиента и его адреса рассматривается как количественное изменение ее состояния. Операция будет завершена, когда будут введены все необходимые данные. Полностью заполненная заявка приобретает качественно новое состояние. Качественное состояние называют комплексным (сложным), если его поведение можно декомпозировать на отдельной диаграмме состояний, где будут рассматриваться только изменения количественных параметров переменной состояния. Таким образом, можно говорить о иерархической вложенности диаграмм состояния и о иерархической декомпозиции переменной состояния.
Формирование операционной цели процесса
Анализ движения объекта в многомерном пространстве его состояний не является тривиальным, поэтому Э. Дейкстра предложил в каждый момент времени выделять только одну переменную состояния и далее рассматривать движение каждой из них по отдельности в двухмерном пространстве, где ось ординат описывает статус данной переменной состояния, а абсцисса соответствует нормальному течению времени [18]. Применим этот подход для исследования состояний бизнес-процесса.
Среди информационных объектов, с которыми работает бизнес-процесс, можно выделить один, связывающий группу операций. Он переносит результат от той операции, которая только что завершилась, к другой, которая должна начаться. Статус этого объекта определяет состояние всей системы в данный момент времени, он выполняет роль переменной состояния.
По ходу обработки объект управления может смениться. Это означает, что сквозной процесс делится на подпроцессы таким
№ 1 (49) 2014
образом, что в каждом присутствует свой объект управления [19]. Можем сказать, что операционная цель процесса (подпроцесса) есть предопределенное состояние объекта управления, характеризуемое набором свойств, присущих указанному объекту. Эта цель достигается, если удовлетворены требования, предъявляемые к результату или способу его достижения. В противном случае цель считается недостигнутой.
Чтобы определить операционную цель, надо выявить объект управления, зафиксировать его финальное состояние, затем сформулировать требования к самому объекту и способу его обработки. В рассматриваемом процессе оформления потребительского кредита объектом управления является заявка. Процесс заканчивается принятием решения по заявке, таким образом определяем целевое состояние объекта — управление. Решение должно быть обоснованным, т. е. обеспечивать приемлемый риск невозврата кредита, это требование уточняет характеристики клиента, по которым принимается решение. Кроме того, решение должно быть принято в нормативное время — не получив ответ вовремя, клиент уйдет в другой банк. [5 Такой анализ справедлив для большин-
и
ства сквозных процессов «от заказа до ре-|| зультата», в них начальным объектом управ-^ ления является заявка, поэтому можно с уве-§ ренностью предположить, что целью этого класса подпроцессов является принятие ;§ обоснованного решения. Например, рассмотрим бизнес-процесс телекоммуникаци-& онной компании по предоставлению услуги 5 связи. Он начинается с поступления заявки от клиента, после чего компания исследу-^ ет техническую возможность предоставле-Ц ния услуги, согласует ее стоимость с клиен-* том, заключает договор. Результатом этих ^ действий является обоснованное решение | о предоставлении услуги, только затем мож-§ но приступать к реализации услуги. Следует | добавить, что список требований к спосо-¡1 бу достижения результата не исчерпывает-1= ся контролем времени. Например, в банков-
ском процессе «сбор просроченной задолженности» принято контролировать затраты на взыскание, чтобы они не превысили сумму основного долга.
декомпозиция операционной цели процесса
Описывая декомпозицию операционной цели, имеем в виду промежуточные стабильные состояния объекта управления. Например, рассмотрен процесс оформления потребительского кредита, в котором объектом управления является заявка клиента. Можно выделить следующие промежуточные состояния заявки: а) заявка принята — все необходимые документы собраны; б) заявка проверена — проанализированы сведения, сообщенные клиентом; в) проведена оценка платежеспособности заявителя; г) заявка обработана — на основании собранных данных и с учетом текущего состояния рынка принимается обоснованное решение о возможности предоставления кредита. Также предположим, что ограничение на длительность исполнения всего процесса разделено между этапами обработки, расположенными между промежуточными состояниями.
Сценарий, при котором все этапы завершаются результативно и в нормативное время, т. е. все промежуточные цели достигаются и никаких отклонений в исполнении процесса не наблюдается, называется основным (happy path) [9]. Работы, включенные в основной сценарий, связаны только безусловными переходами, ветвлений на схеме нет, поскольку предполагается последовательное достижение всех подцелей. Чтобы выявить основной сценарий, был выявен объект управления, рассмотрены все его возможные состояния, расположены в порядке, обусловленном декомпозицией жизненного цикла объекта управления. Таким образом, следуем рекомендациям Э. Дейк-стры, который считал, что разработку программы следует начинать с выявления подходящих состояний системы, а лишь затем строить алгоритм [18]. Если же цель не дос-
№ 1 (49) 2014
тигнута, результат не соответствует установленным требованиям, следует признать, что произошел брак. Дефект может быть исправимый — в этом случае можно осуществить повторную обработку, или непоправимый — в данном случае происходит отказ, дальнейшая обработка считается нецелесообразной [9].
Промежуточные цели также могут быть подвергнуты декомпозиции. Например, промежуточная цель «б» предыдущего примера может быть декомпозирована на следующие подцели: а) проверить правильность указания адреса места жительства; б) проверить достоверность сведений о месте работы и заработке; в) уточнить сведения о поручителях и объектах залога и т. д.
Иногда промежуточная цель связана с достижением целевого состояния другого объекта, отличного от объекта управления процесса. Например, промежуточное состояние «заявка проверена» использует результат подпроцесса, называемого «проверка сведений, сообщенных клиентом». Смена объекта управления есть основание выделения подпроцесса, в котором объектом управления является «отчет о проверке». Даже если сведения подтверждены, но отчет о проверке подготовлен не в регламентируемое время, результат подпроцесса есть брак. Подцели процесса обладают следующими свойствами [20]:
• транзитивности — если главная цель имеет подцель, а та, в свою очередь, имеет подцель нижнего уровня, то последняя является подцелью главной цели верхнего уровня;
• нерефлективности — цель не может быть собственной подцелью;
• несимметричности — если цель имеет подцель, то последняя не может иметь родительскую цель своей подцелью.
Задачи процесса
Ранее было показано, что задача есть работа процесса, преобразующая (трансформирующая) основной объект управле-
ния. Декомпозиция задачи образует структурную иерархию работ процесса. Зададим вопрос: что необходимо сделать, чтобы по- ® лучить запланированный результат? В ответ ss перечислим необходимые работы. Каждая из работ предполагает достижение некоторого промежуточного результата. Декомпозиция может выполняться многократно. Полученная в результате иерархия называется функциональной декомпозицией работ (work breakdown structure). Она указывает, что нужно сделать, но не определяет порядок выполнения работ.
Функциональная декомпозиция лежит в основе многочисленных справочных (реф-ренсных) моделей, которые представляют «идеальный» взгляд на деятельность организации. Две компании, работающие в одной сфере бизнеса, выполняют одинаковые виды работ, однако очередность операций может отличаться, поскольку предприятия обладают различной организационной структурой, производственной культурой и т. д. Рефренсная модель есть каталог функций, иерархически организованный справочник работ, в котором перечислены все действия, выполняемые субъектами [21]. Она строится путем функциональной декомпозиции, поскольку этот способ является наиболее естественным для анализа системы. Любую модель, построенную с помощью функциональной декомпозиции, следует классифицировать как функциональную [21]. Считается, что, имея «полный» набор функций, можно скомпоновать систему, применяя повторно используемые компоненты. Сила и преимущество справочной модели заключается в том, что она строится сверху вниз и определяет иерархию компонентов системы. Благодаря многоуровнему устройству она позволяет выбирать подходящий для конкретного рассмотрения уровень детализации. Проблема перехода от справочных моделей к моделям потоков работ заключается в том, что в результате многократной, повторной функциональной декомпозиции теряется логическая связь, описывающая очередность выполнения процес-
№ 1 (49) 2014
сных элементов. Восстановить потерянную связь достаточно трудоемко, что затрудняет практическое применение справочных моделей.
Анализ работ процесса на соответствие цели
Иногда процесс включает избыточные, ненужные работы. Дж. Ли предложил следующую концепцию анализа работ на соответствие цели [22]:
1. Процесс состоит из подпроцессов, последние могут быть декомпозированы до уровня элементарных работ.
2. Процесс имеет цель, которая определяет решаемые задачи.
3. Задачи процесса декомпозируется на подзадачи, которые образуют структурную декомпозицию работ.
4. Каждый подпроцесс соответствует одной из подзадач, имеет цель, которая коррелирует с главной целью процесса.
5. Если найден подпроцесс, чья цель не очевидна, а результат никому не нужен, значит либо этот подпроцесс можно исключить, либо цель родительского процесса выявлена неверно.
6. Если цель подпроцесса непонятна, можно предположить, что подпроцесс не уве-
|| личивает ценность результата, но повышает £ его стоимость, следовательно, следует про-2 вести реинжиниринг с целью исключения >!| данного подпроцесса. ;§ Эти условия справедливы при рассмотрении процессов любого уровня.
1—1
& Приведенное рассуждение является вер-5 ным, но требует соответствующего специального разъяснения. Когда аналитик опи-^ сывает процесс, он наверняка обращает Ц внимание на операции, которые изменяют * (трансформируют) объект, но обычно не за-^ мечает операции, служащие для координа-| ции работ участников. Будем разделять опе-г§ рационные и организационные обязанности | сотрудников. Первые составляют суть опе-¡1 рационной (производственной) деятельно-1= сти. Вторые связаны с его взаимодействием
с коллегами, без чего невозможно обеспечить выполнение производственного задания. Поскольку организационные обязанности не связаны с трансформацией объекта управления, они в структурную декомпозицию работ не попадают.
Согласно изложенной выше методике анализа, обязанности, которые не служат достижению цели, должны быть исключены, поскольку увеличивают стоимость, но не добавляют ценность. Однако организационные обязанности не могут быть исключены из процесса, поскольку без них вся работа окажется невозможной. Но они могут быть перераспределены или автоматизированы. Например, можно их поручить сотрудникам с низкой квалификацией — секретарям, диспетчерам, контролерам, которые берут на себя функцию координации работы сотрудников вместо руководителя. Примером автоматизации работ может быть диспетчеризация исполнителя по формальным признакам: территории, откуда поступила заявка, или типу этой заявки. Следует отметить, что организационные функции хотя и не служат достижению цели, не исключаются из процесса, а перераспределяются или автоматизируются.
Методика выявления цели процесса
Проведенный в работе анализ позволяет сформулировать методику выявления операционной цели процесса, которая базируется на выявлении объекта управления и исследовании его допустимых состояний, выявлении требований к продукту и результату бизнес-процесса. Для этого необходимо:
1. Выделить объект управления процесса.
2. Найти его целевое состояние.
3. Сформулировать требования к результату и способу его достижения.
4. Выявить промежуточные состояния объекта управления и требования к ним (они помогут определить промежуточные цели процесса).
5. Отдельно зафиксировать нефункциональные требования.
№ 1 (49) 2014
Помимо операционных требований, следует дополнительно отметить нефункциональные требования, например, требования безопасности определяют права доступа участников к объектам систем, а пользовательские требования определяют элементарные действия, составляющие операцию процесса. Эти требования не влияют на достижение цели. Например, нарушение разграничения доступа недопустимо, но не влияет на получаемый результат.
Заключение
Результатом данного исследования является систематизация понятий «цель», «задача», «требование», что крайне важно для правильного анализа бизнес-процесса и выработки требований к проектируемой системе автоматизации. Во-первых, были разделены бизнес- и операционная цели. Первая определяет развитие бизнес-системы, под которой понимаем всю цепочку формирования ценности, вторая устанавливает ожидаемый результат исполнения каждого из подпроцессов, образующих цепочку. Во-вторых, были связаны операционная цель бизнес-процесса и состояния объекта управления этого процесса. Также с каждым подпроцессом или его отдельной операцией связана промежуточная цель, которая определяется через промежуточное состояние объекта управления. В-третьих, под требованиями предлагается понимать характеристики целевого состояния объекта управления или характеристики работы, которая изменяет это состояние. Если хотя бы одно требование окажется невыполненным, цель считается недостигнутой. Нефункциональные требования на достижение результата не влияют.
Научная новизна настоящей работы заключается в обосновании метода постановки операционной цели процесса с использованием методологии Б-В-В, удалось связать цель с базовыми концептами этой онтологии. Предложен способ, позволяющий
соотнести объекты институциональной реальности с информационными объектами, что позволяет расширить границы приме- ® нения онтологии. ss
Предлагаемая в работе методика выявления цели бизнес-процесса и анализа критериев ее достижения обладает практической ценностью — позволяет устранить субъективизм при формировании требований к проектируемой информационной системе, присущий действиям бизнес-аналитиков. Практический опыт показывает, что методика оказалась мощным инструментом выявления процесса «сверху вниз» [9].
Работа выполнена при поддержке Мин-обрнауки России, в рамках базовой части государственного задания № 2014/122 шифр 2966.
Список литературы
1. Хаммер М, Чампи Д. Реинжиниринг корпорации. Манифест революции в бизнесе. М., 2006.
2. Доброхотов А. Л. Цель // Новая философская энциклопедия. М.: Мысль, 2000.
3. Пригожин А. И. Цели организаций: стереотипы и проблемы // Общественные науки и современность. 2001. № 2. Р. 5-19.
4. Simon H. A. On the Concept of Organizational Goal // Administrative Science Quarterly. Vol. 9. 1964. № 1.
5. Головин С. Ю. Словарь практического психолога. Минск: Харвест, 1998.
6. Меньков А. В., Острейниковский В. А. Теоретические основы автоматизированного управления. М.: Издательство Оникс, 2005.
7. Doran G. T. There's a S. M. A. R. T. way to write managements goals and objectives // Management Review. Vol. 70. № 11 (AMA FORUM). November, 1981. Р. 35-36.
8. Вигерс К. Разработка требований к программному обеспечению / пер. с англ. М.: Издательский торговый дом «Русская Редакция», 2004. — 576 с.
9. Фёдоров И. Г. Системный подход к выявлению бизнес-процессов методом «сверху вниз» // Прикладная информатика. 2012. № 5 (41).
10. Ross R. Principles of the Business Rule Approach. Addison-Wesley Professional, 2003.
№ 1 (49) 2014
11. Bider I. Choosing Approach to Business Process Modeling — Practical Perspective II in Inconcept. № 34. January, 2005.
12. Портер М. Конкурентное преимущество: Как достичь высокого результата и обеспечить его устойчивость. M.: Альпина Бизнес Букс, 2005.
13. Bunge M. Ontology I: The Furniture of the World. Treatise on Basic Philosophy. Vol. 3. Boston, MA: D. Reidel Publishing Company, 1977.
14. Wand Y, Weber R. An Ontological Model of an Information System II IEEE Transactions on Software Engineering. Vol. 16. 1990. № 11. Р. 1282-1292.
15. Soffer P., Wand Y. On the Notion of Soft-Goals in Business Process Modeling II Business Process Management Journal. Vol. 11. 2005. № 6. Р. 663-679.
16. Bider I., Khomyakov M. One Practical Object-Oriented Model of Business Processes II In Klimov H., Rumpe B., Simmonds I., eds., OOPSLA'97 Workshop on Object-oriented Behavioral Semantics. Institute Für Informatic. Muenchen. P. 1997.
17. Harel D. Statecharts: A visual formalism for complex systems. Vol. 8 (3). June 1987. Р. 231-274.
18. Дейкстра Э. Взаимодействие последовательных процессов / Языки программирования. М.: Мир, 1972.
19. Фёдоров И. Г. Проектирование модели бизнес-процессов // Открытые системы. 2013. № 5.
20. Markovic I., Kowalkiewicz M. Linking Business Goals to Process Models in Semantic Business Process Modeling // 12th International IEEE Enterprise Distributed Object Computing Conference. Munich, Germany, September 2008.
21. Тельнов Ю. Ф, Фёдоров И. Г. Функциональные и процессные модели бизнес-процесса // Экономика, статистика, информатика. Вестник УМО. 2012. № 2.
22. Lee J. Goal-Based Process Analysis: A Method for Systematic Process Redesign // Proc. of Conf. on Organizational Computing Systems. Milpitas CA. 1993.
§
I
i I
1 is
£ &
« »
<0 _
SI
I. Fiodorov, Ph. D. (Eng.), Professor, Moscow State University of Economics Statistics & Informatics (MESI), 'tu IFedorov@mesi.ru t S
§ An error in the business process goal setting leads to its incorrect analysis, miscalculation in the
s
A method of determining the process goals, tasks and requirements
formation of the requirements for the projected IT system. In this paper we systematize the terms: a goal, a task and a requirement, that it is essential for the proper business process investigation. We also formulate a method for determining process goals, describe a way of identifying the require-
8
if ments by the analyses of the processes product and of the mode of process execution
Keywords: business process goals, tasks, requirements.
32
