ppt

April 5, 2018 | Author: Anonymous | Category: Documents
Report this link


Description

1.Enhancing E-service Collaboration with Enforcement and Relationship Management: a Methodology from Requirements to Event Driven Realization Dickson K.W. CHIU Senior Member, IEEE [email protected], [email protected] Shing-Chi CHEUNG, Sven TILL Dept. of Computer ScienceHong Kong University of Science & Technology {scc, till}@cs.ust.hk2. Introduction e-service- service provided over the Internetadoption of e-services for B2B process collaboration need for a more in depth study not just “regular” process enactment – basic knowledge requirement engineering beyond basic enactment is almost unexploredEnforcement E xception detection– how do you know what is happening inside your partners’ organization? Exception handling –how deviations can be controlled or compensatedBusiness relationship managementqualitycollaborationneed to do extra things process “transparency” 3. Project Background My PhD thesis research on exceptions in WFMS D.K.W. Chiu, Q. Li and K. Karlapalem. A Meta Modeling Approach for Workflow Management System Supporting Exception Handling.Information Systems , 24(2):159-184, 1999. D.K.W. Chiu, Q. Li and K. Karlapalem. Web Interface-Driven Cooperative Exception Handlingin ADOME Workflow Management System.Information Systems , 26(2):93-120, 2001. Extension to cross-organization workflowsD.K.W. Chiu, K. Karlapalem, Q. Li and E. Kafeza. Workflow Views Based E-Contracts in a Cross-Organization E-Service Environment.Distributed and Parallel Databases , 12(2-3):193-216, 2002. CRM D.K.W. Chiu, et al.An Event Driven Approach to Customer Relationship Management in an e-Brokerage Environment. HICSS36, IEEE Computer Society Press, Jan 2003. Conference Paper D.K.W. Chiu, S.C. Cheung, and S. Till. An Architecture for E-Contract Enforcement in an E-service Environment. HICSS36 best paper nomination. 4. Objectives a methodology to structure B2B process collaboration in multiple layers and multiple perspectivesConceptual models expressed in UML life cycle similar to that of a software system, i.e., definition, analysis, and realizationa more thorough understanding of B2B process collaboration from its fundamentals to system designa methodology is presented for the engineering of e-service process collaboration from high-level business requirements down to system design detailsa system architecture and feasible implementation outline with Enterprise Java Bean (EJB) and Web servicesevaluate our approach from the perspective of three main stakeholders of e-collaboration, namely users, management, and systems developers5. Simplified Business Contract Lifecycle Based on business experience and requirements, contract templates (with variables) are abstracted from previous contracts A contract template is modeled as an e-Contract template Each successful e-Negotiation will lead to an e-Contract Enforcement and enactment are executed differently and in parallel CRM should be anywhere anytime … Business Information ExchangeContractEnactment Contract Enforcement ContractNegotiation6. Motivating Business Process Example Can this show anything beyond regular process execution - enforcement and relationship management? Sub-process7. Example Enforcement Requirements End user notify system integrator: changes in delivery requirements or payment arrangement - System integrator notify end user - changes in delivery dateWhen a vendor changes the lead-time but the delivery schedule can still be met within the end user’s deadline, the change can be tolerated.The system integrator should present a revised delivery schedule to the end user according to the parts vendor’s reported lead-time.When a certain part is stopped from production, the system integrator request the end user’s approval of using an alternative part.When there is a significant aggregated price change in parts during the end user’s evaluation, a revised quotation (price) is sent to the end user through an event-triggering mechanism. Most of the above are related to exception handling… 8. Enforcement Requirements in General Recognition (monitoring)andhandlingof contract breachesEnforcement and enactment are handled differently (enactment deals with regular activities) Compliance of a contract has to be kept under constant surveillanceMonitoring of variables – states of the business process Challenges constantly checking validity of all these variables incurs tremendous overheadsextended across organizational boundaries may include confidential information, e.g., bank accounts9. Example Relationship Management RequirementsAny involved organization wants to be able to inquire the progress of business processes at other business partners’ side such as order processing, payment. A service provider wants to relay relevant information to business partners from other sources or upon enquiry, such as technical information, drivers update, product news. Effective measures for handling complaints and feedbacks from business partners are essential to help rescue threatened relationship and reduce attrition. 10. A Three-Layered Architecture for B2B CollaborationEnterpriseJavaBeans Web Services ECA Rules Workflow Processes Enforcement Policies EnforcementRequirements EnactmentRequirements Collaboration Requirements Business Rules System Design Relationship Policies Relationship ManagementRequirements11. Artifacts of B2B Collaboration ArchitectureAnalysts & Programmers Analysts Users, managers, Analysts Perspective Task system design (Enterprise JavaBeans components) Process system design (BPEL or workflow engine) Cross-organizational interface (Web Services XML schemas)System design Meta-model for process enactment and exception handling:Business events, Business rules, Business actions and Business entitiesBusiness rules Meta-model for B2B Collaboration: Enactment requirements (Workflow Processes) Enforcement requirements (Enforcement Polices)Relationship management requirements (Relationship Management Polices)Parties and RolesCollaboration requirementsArtifacts Layer12. A Meta-model of B2B Process Collaboration 1 specifies * * * +publisher 1 * 1..* * performs 1..* 1 Enforcement Requirement * * specifies Enforcement Policy Collaboration Requirement Enactment Requirement Workflow Process specifies 1 Business Rule * 1 Event Action Condition Business Party * Business Event Exception Temporal Event +subscriber * Obligation Permission Prohibition aggregation inheritance realizes realizes Relationship Mgmt Requirement Relationship MgmtPolicy * realizes 1..*13. System Architecture based on ECA rules Motivated by theactive database paradigm Event - occurrence of something interesting to the system itself or to user applications Event driven execution of rules in event-condition-action (ECA) formECA (active) rules:Oneventifconditionthenaction Exceptions and alertsare events too ( action= handler) Ensure efficiency and timeliness - monitor becomes only active when an interesting event occursRequirementEnforcer Collaboration Process Enactor Event Adapter Web Service Interface Event Event A Party asan e-Service Provider Database ECA rules Event Repository Event Subscribers ListBusiness Entities Event Event Event OtherCollaboration Parties Timer Event Internet 14. Enactment Requirements to ECA rules Event-driven workflow execution model(that is, ECA rule based) Business partners have to trigger the corresponding start-events (say, quotation enquiry) to start B2B process collaboration.If the process is a composite one, thecollaboration process enactorwill raise astart-eventfor the first sub-processThis will continue recursively downward the composition hierarchy until a leaf sub-process ortask. Thecollaboration process enactorsends a start-event to the task to initiate it. After the task is finished successfully, the task replies to thecollaboration process enactorby raising a finish-event with the results (if any).Thecollaboration process enactorthen carries on with the next step according to the returned result.Upon failures or timeouts, an appropriateexception eventwill also be raised accordingly.15. Enactment ECA rules example E: received (QUOTATION_ENQUIRY), C: true,A: perform (CHECK_PART_INFO) E: finish (CHECK_PART_INFO), C: true,A: perform (PREPARE_QUOTATION) E: finish (PREPARE_QUOTATION), C: true,A: perform (PREPARE_EXTRA_INFO) 16. Enforcement Requirements to ECA rules Improvement from deontic logic – well-defined execution semantics andwhento execute BAOstands for an object that encapsulates a business action whose execution triggers the object creationCase study – “ Terms and Conditions of Sale, Service and Technical Support”, Dell, Hong Konghttp:// www.ap.dell.com/ap/hk/en/gen/local/legal_terms.htm NOT permitted( BAO ) Permission(may …) prohibitionCondition( BAO ) onOccurred( BAO) Prohibition( Shall not … ) raise( exception( BAO ) ) NOT occurred( BAO ) onDay(deadline (BAO ) ) Obligation(Shall …) Action Condition Event Clause type17. Enforcing Obligation Upon reaching the deadlineT obl , a temporal event is generated by the TimerContract enforcer (of counter party of the action)check if the obliged party has performed the required business actionA obl , searching the log file for invoked actions / occurrence of related events If the obligation has not been fulfilled, thecontract enforcerraises an exceptionE: onDay( deadline( BAO ) ) C: NOT occurred( BAO ) A: raise( exception( BAO ) )18. Enforcing Obligation Example 7.1 Dell shall deliver the Products to the place of delivery designated by Customer and agreed to by Dell as evidenced in Customer’s invoice (“Place of Delivery”) 10.7 …Dell shall respond to a request for such Emergency Serviceas soon as practicableafter its receipt of such request. Analyst has to clarify and substituteambiguitieswith concrete deadline in the formulationE: onDay( after( receiptDate( EMERGENCY_REQUEST ), N ) ) )C: NOT responded( EMERGENCY_REQUEST ) ) A: raise( exception( EMERGENCY_REQUEST ) E: onDay( before( deadline( DELIVER ), 6 ) ) C: valid( place( DELIVER ) ) & ready( DELIVER ) A: perform( DELIVER ) E: onDay( deadline( DELIVER ) ) C: NOT occurred( DELIVER )A: raise( exception( DELIVER ) ) Enactment rule (DELL) Enforcement rule (Customer)19. Enforcing Prohibition The contract enforcer should treat an occurrence of a prohibited action as an exception.Problem - observation of prohibitionsif a party performs a prohibited action, the party will probably try to hide or distract this fact as long as possibleunless the party does this by mistake or misunderstandings) autonomous nature of different organizations Example - 14. Each party shall treat as confidential all information obtained from the other pursuant to a Contract which is marked 'confidential’ … E: onOccurred( INFO )C: confidential( INFO )A: raise( exception( INFO ) )E: onOccurred( BAO ) C: NOT permitted( BOA ) A: raise( exception( BAO ) ) Enforcement rule (Both Parties) Enforcement rule form20. Enforcing Permission Temporary allowance to perform an otherwise prohibited actionwithin a certain allowed time periodunder certainsituations(i.e., events plus conditions)otherwise exception Example -2.1 … Dell shall be entitled to refuse to accept orders placed by the Customer if the Customer breaches or Dell, on reasonable grounds, suspects that the Customer will breach this warranty … E:onOccurred( REFUSE_ORDER ) C:NOT badlisted( customer( REFUSE_ORDER ) ) A:raise( exception( REFUSE_ORDER ) ) E: onOccurred( BAO ) C: prohibitionCondition( BAO ) A: raise( exception( BAO ) ) Enforcement rule example (Both Parties) Enforcement rule form21. Enforcing Permission - Problem Example -3.1 … If Dell allows a Customer to cancel its order after manufacture but before shipment of the Product, Dell shall be entitled to levy a cancellation charge equal to 20% of the price of the Products. … Customer can hardly know the commencement of manufacture of the product - almost non-monitorable Dell may improve the situation by informing the customer when the commencement starts through its enactment system. (CRM!) E: onOccurred( LEVY ) C: NOT ( dateOfCancellation( order( LEVY ) ) >dateOfManufacture ( order( LEVY ) ) & cancellationApproved( order( LEVY ) )) A: raise( exception( LEVY ) ) E: onOccurred( BAO ) C: prohibitionCondition( BAO ) A: raise( exception( BAO ) ) Enforcement rule example (Both Parties) Enforcement rule form22. Relationship Management Requirements CRM help an organization to streamline customer services and maximize the value of customersNew in the B2B context – objectives: provision of quality servicemonitoring of collaborating processes better dissemination of information effective handling of complaints Automation for CRM is even more essential for B2B Approach Concentrated on business rule designs forasynchronousevent drivenparticularly for exceptions Transform business rules fromif-thenform to ECA form Isolate the relevant events record the objectives of each rule to determine its usefulness and hence its priority of implementation in a phased approach23. Quality of service Often not explicitly enforced in a contract But this should not just be optionalDo better than required or specified => competitive Example, though some obliged actions may have a distant deadline, the management may decide to perform it as soon as feasible.Example ECA-rule for quicker delivery E: received (ORDER) C: valid( place( DELIVER ) ) & ready( DELIVER ) A: perform( DELIVER ) 24. Monitoring of collaborating processesHelps business partners to plan ahead and reduce uncertainties Example: a customer can hardly tell whether the manufacture process of the product has already commenced when the order is cancelledImprove the situation by informing the customer when the manufacturing process has commencedBetter than handling enquiries passively => reduce the need for human enquiries and thus operating costs.Non-monitorable => monitorableECA rule example: E: start (DELIVERY) C: true A: notify (customer (DELIVER)) 25. Dissemination of useful informationWidely in practice for B2C relationship management.Financial institutions often provide market information to their customers as extra services.Facilitate the customer to make decision and in turn may help effective collaboration.For example, system integrator forward vendor’s technical information or software updates to the relevant customers. Prevent problems from occurring improves the service qualityreduce the cost of support Example ECA rule: E: received (INFO) C: relevant (INFO, customer) A: notify (customer ( INFO) ) 26. Effective handling of complaintsAvoids customer attritionHelp rescue threatened relationshipComplaints involve exception conditionsneed to be handled byappropriatetrained personnel or even the management manually should be performed as soon as possible to reduce customer grievance Example ECA rule: E: received (COMPLAINT) C: true A: notify (handling_personnel (customer ( COMLAINT))) 27. Discussion of Problems General measures tohandlecontract breaches or exception involvesdomain specific knowledge explicitly specified in other contract clausesimplicitly regulated by laws and standardsAmbiguity and impreciseness of natural languages reference to other laws, regulations, standard trade practicesparties involved should discuss and clarify the matteramend existing or forthcoming contracts accordinglyAutonomous nature of individual organizationsRequired events might not be monitorableCooperation and trust - improves the transparency of operations (CRM!) Add explicit clauses in the contract to demand these events Lack of e-services standards28. Web Service Implementation Outline Event Adaptor – event publish-and-subscribe paradigm WebServices Manager Event Adapter publish subscribe receive notify Database Event Repository Subscribers List Security Policies WebServices Manager receive event event event event Counter Party Party request subscribe request request interface depend event subscription request component NOTATIONS29. Web Services of the Event Adaptor PublishWeb serviceinvoked by theevent adaptor input parameter is the occurred event or exception checks the subscribers list and the security policies, and then notifies the valid subscribers (via e-mail, fax, ICQ message, or even via another Web service) SubscribeWeb serviceregisters requests for an event subscriptionparameters: the requester, the subscribed event, and how the requester wants to receive the event notification ReceiveWeb servicereceive subscribed events published by the counter partyreceived events are recorded at the Event Repository and forwarded to the Event Adapter in turn transforms them into the forms as required by theContract Enforcerandthe Contract Enacter 30. Example Web Services for Collaboration takeOrderWeb Service Input: OrderRequest Buyer Name Address E-Mail ProductList Product Product ID Product Name Quantity PriceOutput: OrderResponse OrderResult OrderNr Password Estimated Delivery DatetrackOrderWeb Service Input: OrderStatusRequest OrderNr PasswordOutput: OrderStatus Progress Estimated Delivery Date Optional: DeliveryNr 31. Web Services for External Exception / Event ReceptionExample Web Service Name: ChangeOrderRequest Input:ChangeContractDataRequest ChangeRequestID Customer Id OrderNumber ToChangeContractDataOldValue NewValue ReasonOfChange Output: ChangeContractDataResponse ChangeRequestID Approved (Yes/No) AuthorizedBy AdditionalComment ToChangeContractData NewValue“ Catch-all-exception” Web service Precaution – unhandled exceptions forward to administrators Each events / exceptions sub-class hierarchy as Web service Extra parameters / data E.g., End User -> System Integrator Cancel Order Request Change Order Request Change Delivery Date RequestChange Delivery Location Request Delay Payment RequestReturn Unsatisfied System Request E.g., Part Vendor -> System Integrator Price List Update Price UpdateNew Parts UpdatePart Recall Notification Part Obsolescence NotificationDriver Update32. Event Chaining Possible because of automated receipt and sending of eventsEfficient and effective knowledge disseminationE.g., driver update:part vendor -> system integrator -> end user 33. Process Monitoring Name: GetProcessStatusInput: ProcessStatusRequest CustomerId OrderNumber Output: ProcessStatusResponse CustomerID OrderNumber StatusReport (content depend on the customer, status, etc.) ContactPersonInfo (for further information) 34. Evaluation - Concerns of different stakeholders Difficulties in programming captured knowledge Event monitorability Difficulties in programming captured knowledge Phase approach that accommodate existing basic enactment information systems Development / Maintenance effort & cost Requirement elicitation Reusability Scalability Uncertainty in the use of new technologies Overall system complexity Integration with existing systems SystemDeveloper Improve customer relationships Improved services Knowledge management Business process monitorability Compliance to contracts / trade standard / regulations / laws Exception and crisis management Knowledge management Increase business opportunities Convergence of disparate business functionalities Cost vs. Benefit Improve productivity Scalability Security Reduction in total development cost Communications cost Management Improvedservicecall-center or web pageMore transparent business processes Reduce tedious manual checking Timeliness of services Workflow automation Reliability – retries, search alternatives Assist their work Interoperability and connectivity System / information availabilityConvenience and ease of use User RM Enforcement Enactment General Concerns35. Conclusions A pragmatic three-layer architecture for B2B e-service process collaboration (collaboration requirement layer, business rule layer, and system design layer) Support for enactment, enforcement, and relationship managementA meta-model for B2B collaboration based on a unified artifact of event-condition-actionA methodology for eliciting knowledge of collaboration requirements into business rules in ECA formatTypical problems that can be discovered by our methodology, together with some measures of overcoming themA system architecture and feasible implementation outline with Enterprise Java Bean (EJB) and Web servicesEvaluation of our approach from the perspective of three main stakeholders of e-collaboration, namely users, management, and systems developers 36. Continuing and Future Work Methodologies forpreventivemeasures avoiding contract breaches. Process adaptation for interoperability with process views and event flows analysis – different partners have different interactions. Alerts – urgency in process integration (esp. healthcare) Application of this framework in other domains, particularly B2B process enforcement (exceptions) and *CRM* Financial institutions, insurance, … e-tourism, e-government, e-learning, …


Comments

Copyright © 2025 UPDOCS Inc.