Business Process Modeling

1. 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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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<x: f a> is an interrupt (when control arrives at the interrupt, action triggers if the condition is satisfied) HY 565 - Lecture 2

17. Process Model • Procedures: can be defined with the construct proc b(x) endProc. Procedurecall: b(x) • Example: proc ProcessApp <app: Application(app)  Has(self, app)  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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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

30. 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

31. 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