Processes, services and business agility prof. dr. Wilfried Lemahieu K.U.Leuven Faculty of Business and Economics Department of Decision sciences and Information Management wilfried.lemahieu@econ.kuleuven.be www.econ.kuleuven.be/wilfried.lemahieu/public Kwaliteitscongres, 24/10/2008
Business Process Management Look upon an organisation, not from the perspective of functional domains, but from the perspective of its processes (which often run across several functional domains) B A D E C Make the processes explicit in order to Improve performance Manage costs Facilitate internal or external control Better/faster adapt to customer requirements Automate processes Aspects of BPM Business Process Modelling Business Process Analysis Business Process Improvement / Reengineering Business Process Enactment
Paths towards BPM - Model analysis - Process simulation - Business Activity Monitoring (BAM) - Process mining Business Process Modelling A B C D Business Process Enactment E Business process automation Application integration & service orchestration Process model: identifies tasks and dependencies Agents can be humans or applications Dependencies between tasks and agents: role allocation Dependencies between tasks Control dependencies: task sequencing Data dependencies: data flow between tasks
Enactment of business processes Applications were/are typically organised around functional domains This results in silos of automation Business processes run across these silos A Process model B D C E? Order processing Claim handling Sales & Marketing Provisioning Finance Customer support
Enterprise Application Integration (EAI) Where are the process definitions? A Process model B D C E here here and here Sales & Marketing Provisioning Finance Customer support here!!! EAI middleware Spaghetti of control flow Flexibility???
Separation of process logic from application logic Process logic: document with declarative specification of an "executable process" Interpreted and executed by BPM engine Application logic: execution of individual tasks; embedded in applications A Executable process B C D BPM engine E Consequences: Flexible process adaptation, without "plumbing" in application code Monitoring and "debugging" of processes Sales & Marketing Provisioning Finance Customer support Reuse of application logic??? EAI middleware
From structured programming to SOA Structured programming: divide and conquer Object-orientation Encapsulation of data and behaviour Decouples interface from implementation Reuse as a means to cost/effort reduction Component-based development Coarse grained components Decouples business logic from deployment issues Reuse as a means to cost/effort reduction Service oriented architecture (SOA) Appropriate granuarity Decouples processes from application logic Reuse as a means to agility!!! SOA pertains as much to business as to ICT!!!
SOA: dividing business and ICT into sellable units Service = logical grouping of functionality, at "appropriate" abstraction levels (business, application, infrastructure, ) Self contained services, invoked via published service description Decoupling of service provider view and service consumer view Technical interface: parameters, message formats, Functional and non fuctional aspects: cost, service level agreements (SLAs), security, "contract" Classification in libraries, registries, SOA divides business and ICT into sellable units with minimal dependency Agility through reuse SOA is about supply & demand: dependencies are market imperfections!
Aspects of SOA Order processing ERP Order processing Customers Orders Inventory Materials SCM CRM Production planning Production planning Legacy Legacy Business services Information system services Software components Application portfolio Integration infrastructure QoS, security, management, monitoring
Processes and SOA Order processing ERP Order processing Customers Orders Inventory Materials SCM CRM Production planning Production planning Legacy Legacy Business services Information system services Software components Application portfolio Integration infrastructure QoS, security, management, monitoring Initially: 'spaghetti' of calls between services Consequence: still no agility
BPM+SOA = service orchestration Process = sequence of task Each task corresponds to a service call Processes realised as "service orchestrations" Services are building blocks to processes Process can be published as a new, coarse grained service Composite service: implementation = orchestration Atomic service: implementation = application logic Executable processes / orchestrations Services A Components Sales & Marketing Provisioning B C Finance D Customer support E Integration infrastructure QoS, security, monitoring,
Example: clinical pathways QMEdit
BPMN (Business Process Modelling Notation) Graphical standard notation for process modelling Automated translation to orchestration languages, e.g. WS-BPEL
From processes to services (and vice versa) Top down approach Identification of coarse grained processes Hierarchhical decomposition Derive services from process models Risk: mismatch with existing ICT infrastructure and data structures Bottom up Analyse existing ICT systems Exctract individual services from these (often monolythic) systems Overlay business processes as service orchestrations Risk: not enough focus on business relevance, too fine grained Meet-in-the-middle
and here!!! and where are the data? Executable processes / orchestrations B D E A C QoS, security, monitoring, Services Integration infrastructure Components here here Customer support Finance Provisioning Sales & Marketing here Spaghetti of data flow Consistency? Accuracy? Unified view?
MDM (Master Data Management) Primary objective: provide a unified and consistent view on dispersed reference data (customers, products, ) Golden record that represents a single version of the truth Centrally governed data model and metadata ("meaning") Ideally: enable a single view of the business across operational and analytical systems But : avoid creating yet another spaghetti of cross links between data stores and avoid the master data repository becoming yet another silo! SOA can be used to propagate the master data into the business processes. SOA and MDM need each other.
Putting the A in SOA: SOA as a style of enterprise architecture Process services A B C D E A B C A D B C E D E Utility & infrastructure services Activity services Data services Application portfolio ERP SCM CRM Legacy RDBMS
Putting the A in SOA: SOA as a style of enterprise architecture Business architecture The business is organised as a network of service providers and consumers Identification of (high level) business processes and their tasks, as executed by humans or computers Description of business processes as 'business services', identification of dependencies between business services at different granularity levels Methods for the development of new services (agility) Possibility for outsourcing certain business services and/or tasks Information system architecture; maps business to software services Application architecture: applications percieved as a set of services Process services that orchestrate other services Human-computer interfaces Activity services that map to applications Data architecture Decomposition of information domains; data services represent business concepts Importance of data ownership and semantics Technical architecture Utility and infrastructure services, e.g. security services, data transformation services, etc. Technical realisation of software services through back end applications and data sources
Enterprise architecture frameworks 1 Contextual/ Scope 2 Conceptual/ Enterprise 3 4 Logical/ IS Functionality Physical/ Design TOGAF 5 As Built/ Subcontractor 6 Functioning/ Code Zachman Entity Relationship Entity Input Process Output Node Line Node Organization Reporting Organization Event Cycle Event Objective Precedent Objective Strategy & Objectives Organisation Processes Products & Services Aris Information Systems Infrastructure Importance of cross-model checking!!!
Perspectives on Business Processes Organisation perspective of the environment Black Box Service Apply for LOAN Claim Handling Work Organisation System view: Organisation as set of interrelated components White Box Operational view Procedures to grant a loan Management View Credit scoring Interest rates Information systems to support Operational, Tactical & Strategic Management Business Services IS Services
Some recommendations and caveats Alignment: business processes and services map 'directly' to ICT concepts Agility: flexibly develop new services/processes through composition and reuse Less market imperfections because of reduced dependencies; facilitates B2B integration and outsourcing Avoid uncontrolled proliferation of services; litmus test required! Make responsibilities explicit by SLAs + assess effect of SLA changes on composite services/processes The full potential of BPM/SOA can only be realised if process and activity services have access to accurate and consistent business data, independently from its source location and format Data ownership, often orthogonal to process ownership
Dinsdag 28 oktober 17u00-19u00 Zebrastraat NV, Zebrastraat 32/001, 9000 Gent Bedrijfswijd procesmanagement Hoe procesmatig werken, referentiemodellen en de bijhorende best-practices succesvol hergebruikt kunnen worden voor andere doelstellingen in uw organisatie Joachim Billiet Lean Sigma Black Belt Wim Vanderstraeten Partner www.bpmforumbelgium.org
BPM, B2Bi and extended enterprises prof. dr. Wilfried Lemahieu K.U.Leuven Faculty of Business and Economics Department of Decision sciences and Information Management wilfried.lemahieu@econ.kuleuven.be www.econ.kuleuven.be/wilfried.lemahieu/public Kwaliteitscongres, 24/10/2008
BPM/SOA and webservices Service Oriented Architecture webservices SOA = design principle Webservices = implementation technology Webservices are based on XML (extensible Markup Language) Webservices are very suitable to implement the BPM/SOA vision Interaction: SOAP exchange of XML messages Interface: WSDL interface description in XML Discovery: UDDI service registry based on XML Orchestration: WS-BPEL specification of "executable processes" in XML XML webservices process centric integration between organisations EAI: intra enterprise integration Static B2Bi: collaboration between fixed partners ("extended enterprise") Dynamic B2Bi: at runtime discovery & binding to ad hoc partners
Discovery and invocation of webservices UDDI registry Query: UDDI Description: WSDL (Webservices Description Language) Publish: UDDI (Universal Description, Discovery and Integration) Interaction: SOAP Service consumer Service provider
WS-BPEL (Business Process Execution Language for web services) Orchestration language standard for webservices Specifies business processes by means of PartnerLinks: providers of webservices Variables: business messages to be exchanged (cfr. data flow) Activities: sending or receiving messages Control flow: order of message exchanges (sequence, parallell, ) Also: transaction support, error handling,
Enacting business processes as webservice orchestrations Process = consecution of activities Each individual activity is realised through a webservice invocation Specification in XML: WSDL documents specify webservice interfaces Orchestration document (in WS-BPEL) determines the sequence in which the respective interfaces are invoked BPEL A B C D E WSDL WSDL WSDL WSDL WSDL
B2Bi: processes that span several organisations (cfr. extended enterprises) Separation of public and private processes: Public process: interaction between partners (customers, suppliers, ) based on webservices B2Bi Private process: internal activities that implement the webservices offered to the outside world (supported by back-end applications) EAI Public processes are captured in collaborative process models, in which each partner plays a particular role Webservices in collaborative process models: Public processes are defined as webservice orchestrations A B C D Public process E Each individual activity is realised as a webservice call Each partner implements a subset of the webservices The webservices hide the private processes of the partners A B C D E Legacy B A D E C Private processes
WS-BPEL: an example <sequence> <invoke partnerlink="invoicing" porttype="lns:computepricept" operation="initiatepricecalculation" inputvariable="po"> </invoke> <invoke partnerlink="invoicing" porttype="lns:computepricept" operation="sendshippingprice" inputvariable="shippinginfo"> <target linkname="ship-to-invoice"/> </invoke> <receive partnerlink="invoicing" porttype="lns:invoicecallbackpt" operation="sendinvoice" variable="invoice"/> </sequence> <sequence> <invoke partnerlink="scheduling" porttype="lns:schedulingpt" operation="requestproductionscheduling" inputvariable="po"> </invoke> <invoke partnerlink="scheduling" porttype="lns:schedulingpt" operation="sendshippingschedule" inputvariable="shippingschedule"> <target linkname="ship-to-scheduling"/> </invoke> </sequence> </flow> <reply partnerlink="purchasing" porttype="lns:purchaseorderpt" operation="sendpurchaseorder" variable="invoice"/> </sequence> </process> OASIS
Publishing a process as a new (coarse grained) service Implementation of coarse grained service = process = orchestration of fine grained services Unified access point to outside world Purchase- OrderProcess Customer Consequence: flexibly create processes and change service providers; create new products as 'mashups' of existing building blocks
Collaborative processes Organisation Black Box Product view Work Organisation Operational view Management PRIVATE View PUBLIC Information systems Integration Alignment Partnership Organisation Product view PUBLIC PRIVATE Information systems Work Organisation
Putting the A in SOA: SOA as a style of enterprise architecture Process services A B C D E A B C A D B C E D E Utility & infrastructure services Activity services Data services Existing application portfolio ERP SCM CRM Legacy RDBMS
BPM, webservices and B2Bi: a question of supply and demand Essence of SOA: flexible supply and demand of services by removing 'dependencies' Divide and conquer Strict separation between provider view and consumer view Connect business processes to ICT by means of common concept: services Webservices: XML as universal language for messaging, service description and (executable) process definition All types of services (business and ICT) can be subject to outsourcing Business services: cfr. Extended Enterprises; e.g. shipping, invoicing, Application services: cfr. Software as a Service (SaaS); e.g. a CRM system Data services: cfr. Data as a Service (DaaS); e.g. general master data sets that are available to paying subscribers Infrastructure services: e.g. authentication and security certificate services Important: adherence to strict SLAs and security!!!
Some future perspectives Consolidation and maturing of webservice standards, including more business related aspects (e.g. policies) Standard vocabularies & processes for particular industries (e.g. Rosettanet) Electronic contracts & agreements Rule based definition of business processes Unified paradigms and information system support for automated, manual and semi structured processes Sensors, RFID tags, etc. provide new, real-time information sources: need for discovery and plugin of many lightweight services