business process modeling
Download
Skip this Video
Download Presentation
Business Process Modeling

Loading in 2 Seconds...

play fullscreen
1 / 31

Business Process Modeling - PowerPoint PPT Presentation


  • 144 Views
  • Uploaded on

Business Process Modeling. Enterprise modeling : description of main constituents, purpose, processes etc. of an organization a representation of the organization’s knowledge about itself

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Business Process Modeling' - farrah-spence


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
business process modeling
Business Process Modeling
  • Enterprise modeling: description of main constituents, purpose, processes etc. of an organization
    • a representation of the organization’s knowledge about itself
  • Creating an enterprise model can reveal anomalies, inconsistencies, inefficiencies and opportunities for improvement
  • Once a model is created, it can be used to share knowledge within an enterprise, to formulate and evaluate changes
  • Process definitions can be extracted to be input to a workflow management system
  • Business process support software can query the enterprise model to obtain information

HY 565 - Lecture 2

business process modeling1
Business Process Modeling
  • A formal approach to enterprise and business process modeling
    • concepts must be defined rigorously and precisely
    • use formal methods to analyze, extract knowledge from them and reason about them
  • Advantages of adopting a formal approach:
    • can be verified mathematically
    • can be proved to be self-consistent
    • can be shown to have or lack properties
  • Need to establish methodologies for devising formal models of organizations and their processes

HY 565 - Lecture 2

business process modeling2
Business Process Modeling
  • A formal model for Business Process Modeling and Design [Koubarakis & Plexousakis, 2002]
    • a goal-oriented methodology for business process design
    • founded on the situation calculus
    • process modeling using ConGolog, a concurrent logic programming language
    • outcome is a detailed formal specification of a business process that achieves the specified objectives
    • developed as a set of submodels that capture the business process from various viewpoints
    • formal verification using AI techniques

HY 565 - Lecture 2

modeling concepts
Modeling Concepts
  • An enterprise model comprises 5 interconnected submodels used to describe formally different aspects of an organization:
    • organizational submodel: describes the actors in the enterprise, their roles, their responsibilities and their capabilities
    • objectives and goals submodel: describes what the enterprise and its actors are trying to achieve
    • process submodel: describes how the goals are to be achieved
    • concepts submodel: describes non-intentional entities
    • constraints submodel: describes factors limiting what the enterprise and its components can do

HY 565 - Lecture 2

modeling concepts1
Modeling Concepts
  • Basic tool: a first-order logical languageL
    • symbols ofL include:
      • parentheses,
      • a countably infinite set of variables,
      • quantifiers (universal, existential),
      • equality,
      • sentential connectives (negation, conjunction, disjunction, implication, equivalence)
      • function symbols (including constants)
      • predicate symbols
  • Notational convention: predicate and function symbols start with uppercase letters; variables with lowercase

HY 565 - Lecture 2

modeling concepts2
Modeling Concepts
  • A set of sentences of L makes up a first-order theory
  • Use of a first-order logical languages provides the ability to represent incomplete enterprise knowledge
    • e.g., this job can be assigned to person A or person B
  • Incomplete knowledge is impossible to represent in other enterprise knowledge frameworks (e.g., those based on entity-relationship modeling or UML diagrams)
  • Reasoning with incomplete knowledge is important for organizational planning

HY 565 - Lecture 2

organizational submodel
Organizational Submodel
  • Main concepts: actor and role
    • actor is an intentional entity, i.e., has some idea or purpose that guides its actions
    • used to model (groups of) people, software / hardware systems that are capable of executing certain activities
    • distinguished into human and automated
    • an organizational role involves a set of responsibilities and actions carried out by actors
    • organizational roles can have different forms:a unique functional role (e.g., Systems Department),a unique functional position (e.g., Managing Director),a rank or job title (e.g., Associate Professor),a replicated functional group (e.g., Department), a replicated functional position (e.g., Director),a class of persons (e.g., Customers) or an abstraction (e.g., Progress Monitoring)

HY 565 - Lecture 2

organizational submodel1
Organizational Submodel
    • Role instances are acted out by actors or groups of actors
    • Different actors can play different roles at different points in time
    • Many instances of the same role can be active at any point in time
  • In L we use unary and binary predicates to denote these concepts. Also need axioms capturing their semantics
  • Example:

HumanActor(John), HumanActor(Mary)

Role(Tutor), Role(Secretary)

PlaysRole(John,Tutor), PlaysRole(Mary, Secretary)

x (Actor(x)  HumanActor(x)  AutomatedActor(x))

HY 565 - Lecture 2

objectives and goals submodel
Objectives and Goals Submodel
  • An enterprise goal is a desired state of affairs
    • e.g., “all customer requirements are answered within two days”, “profits must be maximized”
  • Goals are associated with components of other submodels:
    • goals are assigned to roles; they become responsibilities of roles and the actors playing the roles (organizational submodel)
    • the purpose of a process is the achievement of one or more goals (process submodel)
    • goals refer to enterprise entities (concepts submodel)
  • Capturing goals explicitly allows expressing “what”,“why” and “who”, i.e., permits studying the organization from an intentional point of view

HY 565 - Lecture 2

objectives and goals submodel1
Objectives and Goals Submodel
  • Organizing goals
    • Goals can be reduced into alternative combinations of subgoals by using AND/OR goal graphs
    • E.g., the goal “sales targets are achieved” can be AND-reduced to “sales target for product A are achieved” and “sales target for product B are achieved”
  • An organizational objective is a goal that does not result from goal reduction, i.e., a top-level goal, or “an end in itself and not a means serving some higher-level end”
  • Goals can conflict with each other: goals are said to conflict if they cannot be satisfied simultaneously
  • Goals can also influence positively or negatively other goals
  • Such interactions between goals must be defined explicitly

HY 565 - Lecture 2

objectives and goals submodel2
Objectives and Goals Submodel
  • Defining goals formally:
    • High-level objectives may be difficult to formalize; they can be described informally and stepwise reduced to more concrete and formal goals
    • Concrete goals can be formalized as sentences of L
    • Example: the goal “enquiries are answered by a member of staff as soon as they are received” can be formalized as the sentence:

(a)(e)(x)(s)(s’) (Staff(a)  Enquiry(e)  Action(x)  Situation(s)  Situation(s’)  Received(e,a,s)  s’=Do(x,s)  Answered(e,a,s’)

s’=Do(x,s) means that s’ is the situation resulting from the execution of action x in situation s

HY 565 - Lecture 2

process submodel
Process Submodel
  • Main concepts:
    • Situtations are states of affairs
    • Changes occur in situations as results of actions
    • Actions can be primitive or complex
    • Actions are formally specified (situation calculus and ConGolog)
    • Categories of actions: causal, knowledge-producing, exogenous
    • A business process is a network of actions performed in the context of one or more organizational roles in pursuit of some goal

HY 565 - Lecture 2

process model
Process Model
  • Based on the Situation Calculus:
    • Actions are denoted by 1st-order terms of the form f(args) where f is a function symbol and args is a list of 1st-order terms
    • Relations whose truth values may differ from one situation to another are called fluents
    • Fluents are denoted by predicate symbols having a situation term as their last argument
    • Functional fluents are used to express functions whose denotation varies from one situation to another

HY 565 - Lecture 2

process model1
Process Model
  • Primitive actions are specified by expressions of the form:

action a

precondition f1

effect f2

endAction

wherea is an actionandf1, f2 are formulas ofL

  • Example:

actionForwardApp(a1,a2,app)

preconditionHas(a1,app)

effectHas(a2,app)  Has(a1,app)

endAction

HY 565 - Lecture 2

process model2
Process Model
  • Complex actions may be defined recursively using ConGolog:
    • Primitive actions are actions
    • noOp: special action of doing nothing
    • Sequencing: ifa1, a2 are actions thena1;a2 is the action that consists ofa1 followed bya2
    • Waiting for a condition: iff is a formula ofL thenf? is the action of waiting until conditionf becomes true
    • Non-deterministic choice of action: ifa1, a2 are actions thena1|a2 is the action that consists ofnon-deterministically choosing betweena1 anda2
    • Non-deterministic choice of action parameters: ifa1, a2 are actions thenPx(a1) denotes the non-deterministic choice of parameter x fora1

HY 565 - Lecture 2

process model3
Process Model
  • Non-deterministic iteration: if ais an action than a*denotes performing a sequentially 0 or more times
  • Conditionals and interation: ifa1, a2 are actions then if f then a1 else a2 defines a conditional and while f do a1 denotes iteration
  • Concurrency: ifa1, a2 are actions thena1||a2 is the action ofexecutinga1 anda2 concurrently
  • Concurrency with priorities: ifa1, a2 are actions thena1>>a2 denotes thata1 has higher priority thana2 anda2 may only execute whena1 is done or blocked
  • Non-deterministic concurrent iteration: if ais an action than a||denotes performing a concurrently 0 or more times
  • Interrupts: ifxis a list of variables, f a formula ofLanda an action, then is an interrupt (when control arrives at the interrupt, action triggers if the condition is satisfied)

HY 565 - Lecture 2

process model4
Process Model
    • Procedures: can be defined with the construct

proc b(x) endProc. Procedurecall: b(x)

  • Example:

proc ProcessApp

if AvgMark(app) < 70 then

for a: Actor(a)  PlaysRole(a, Secretary) do

SendMessage(self,a,Inform(Unacceptable(app)))

endfor

else for a: Actor(a)  PlaysRole(a, Lecturer) do

ForwardApp(self,a,app)

endfor

endif

>endProc

HY 565 - Lecture 2

process model5
Process Model
  • A business process is defined by an expression of the form:

process id

purpose goals

RoleDefs

endProcess

  • Roles are defined by expressions of the form

role id

responsibility resps

Primitive Action Defs

Procedure Defs

endRole

HY 565 - Lecture 2

process model6
Process Model
  • Example:

role Tutor

responsibility …..

action ForwardApp(a1,a2,app)

precondition Has(a1,app)

effect Has(a2,app)  Has(a1,app)

endAction

action SendMsg(sender, recipient, msg)

….

endAction

proc main

…..

endProc

endRole

HY 565 - Lecture 2

process model7
Process Model
  • In the definition of each role, the business process designer has to specify a ConGolog procedure which defines the dynamics of the role
  • Attaching responsibilities to roles: pseudo-variable self is assumed to range over all actors playing the role inside which the variable appears
  • Different types of actions included in procedures:
    • ForwardApp is a causal action
    • SendMsg is a knowledge-producing action

HY 565 - Lecture 2

concepts and constraints submodels
Concepts and Constraints Submodels
  • Concepts submodel contains information about enterprise entities, their relationships and their attributes
    • Information in this submodel is formally expressed by sentences ofL
    • Enterprise data are part of this submodel
    • Establishes a conceptual model of the organization and all entities it encompasses
  • The Constraints submodel is used to encode restrictions imposed on enterprise entities
  • Constraints are encoded in the situation calculus and can be static or dynamic
    • E.g., (p)(Accepted(p)  Rejected(p))

HY 565 - Lecture 2

a methodology for business process design
A Methodology for Business Process Design
  • Identify the organizational objectives and goals; initiate goal reduction
  • Identify roles and their responsibilities; match goals with role responsibilities
  • For each role specify its primitive actions, the conditions to be noticed and its interaction with other roles
  • Develop ConGolog procedures local to each role for discharging each role’s responsibilities
  • Verify formally that the ConGolog procedures local to each role are sufficient for discharging its responsibilities

HY 565 - Lecture 2

a methodology for business process design1
A Methodology for Business Process Design
  • Goal identification and reduction

Number of graduate students is maximized

Application evaluations are completed quickly

Initial screening done promptly

Promising applications forwarded to

appropriate members of staff

HY 565 - Lecture 2

a methodology for business process design2
A Methodology for Business Process Design
  • Identify roles and responsibilities
    • Role identification:
      • Existing role: Faculty
      • New roles: Tutor and Secretary
    • Responsibility assignments
      • Tutor: do initial screening of applications, forward promising applications to Faculty
      • Secretary: handle all correspondence with applicants, forward applications to Tutor
      • Faculty: evaluate applications a.s.a.p.

HY 565 - Lecture 2

a methodology for business process design3
A Methodology for Business Process Design
  • Specify the internal structure of roles
    • E.g., role Tutor
      • Actions: screen an application (complex) and forward an application (primitive)
      • Conditions to monitor: new application arrives
      • Interactions with other roles: sending a message of type INFORM
  • Specify the dynamics of each role
    • Example in slide 17
    • Similarly for other roles
  • Formal Verification

HY 565 - Lecture 2

formal verification
Formal Verification
  • Formally verify that each role responsibility is fulfilled and each constraints is maintained by the ConGolog procedures defined for each role
  • Verification is based on a solution to the frame and ramification problems
  • It is determined whether consistency with respect to defined responsibilities and constraints is preserved or violated as a result of process execution
  • Reasoning with process specifications (at design time)
  • Strengthened specifications are proposed so that it can be provably guaranteed that constrains will not beviolated

HY 565 - Lecture 2

formal verification1
Formal Verification
  • Example:

Action specification

action SendOfferLetter(app)

precondition ( lect) WantsToSupervise(lect,app)

effect Accepted(app)

endAction

Constraint: no applicant can be both accepted and rejected

(p)(Accepted(p)  Rejected(p))

The specification does not exclude situations in which Accepted(p) and Rejected(p) are both true.

HY 565 - Lecture 2

formal verification2
Formal Verification
  • The action specification must be strengthened to exclude such situations
  • A ramification (logical implication) of the constraint and the action specification: Rejected()
  • Strengthened specification

action SendOfferLetter(app)

precondition ( lect) WantsToSupervise(lect,app)

effect Accepted(app)  Rejected(app)

endAction

HY 565 - Lecture 2

formal verification3
Formal Verification
  • Ramifications of constraints and process specifications have the following properties:
    • If a ramification of a goal / constraint is known to be unsatisfiable, then the constraint/goal is unsatisfiable
    • Constraint / goal ramifications can reduce the search space for constraint / goal satisfaction
    • Transformations may be applicable to ramifications of goals or constraints but not to the goals or constraints themselves
  • If we have a systematic way of generating ramifications, then the derived ramifications can be used for making the task of meeting the constraints / goals simpler

HY 565 - Lecture 2

formal verification4
Formal Verification
  • Generating ramifications may require an arbitrary amount of inferencing
  • In general, the problem is intractable (1st-order logic is only semi-decidable)
  • Tractability can be achieved by restricting the class of constraints / goals for which ramifications are sought (e.g. the class of formulas that are conjunctions of atomic predicates)
  • Results exist for binary temporal constraints in prenex normal form (details in the paper)

HY 565 - Lecture 2

summary
Summary
  • A formal approach to enterprise modeling and business process design using situation calculus and ConGolog
  • Research issues:
    • Implementing support tools
    • Simulating large processes using ConGolog
    • Extend verification techniques to cover all features of ConGolog
  • Suggested readings:
    • M. Ould “Business Processes”, chapters 1, 2
    • Koubarakis & Plexousakis, “A Formal Model for Business Process Modeling and Design”, Information Systems 27(2002), pp. 299-319.

HY 565 - Lecture 2

ad