Understanding Business Process Architecture to Enable Operational Efficiency

Slide 1: Welcome Jaakko Riihinen Head of Enterprise Architecture and Technology Nokia Siemens Networks SessionTitle: Understanding Business Process Architecture to Enable Operational Efficiency

Slide 2: Disclaimer The models in this presentation are only simplified fictional examples, developed for training purposes only, and do not necessarily represent an optimal process architecture for any particular purpose April 21-23, 2008 2 Renaissance Washington, DC

Slide 3: Capabilities are links in a chain … Corporate mission, Core values Risk and strategy, and and quality leadership competences management Customers Competition Marketing, sales Product Program Enterprise and logistics and portfolio and project architecture management management and systems engineering none of them can produce significant results without the others. Note: Capabilities shown here are examples only April 21-23, 2008 3 Renaissance Washington, DC

Slide 4: Definitions: Abstract modeling Abstraction • An abstract model is a tool of mind to help in understanding and communicating the nature, structure, and behavior of a system. Presentation view of the model • The model helps understanding, by focusing on the essential features of reality in an organized fashion and ignoring detail of lesser importance. • Ignoring detail really is beneficial, since by modeling, we try to simplify something that Model of the system is otherwise too complex to understand. • Presentation is separate from the model and is done using metaphors that are familiar to the users of the model, from their previous System as part Reality experience with more familiar concepts. of the real world Unknown knowledge must relate to known knowledge, if the unknown is to be learned. April 21-23, 2008 4 Renaissance Washington, DC

Slide 5: Definitions: Architecture • A property of a system • Without bringing external energy in, any system will evolve towards chaos. Architecture is external energy that brings order to chaos. • Order is brought about by structures that we may also call the architectures. • Architectures intend to satisfy nonfunctional requirements • Nonfunctional requirements can be grouped under the following headings: – Visibility and integrity – Optimization of system economics – Performance and capacity – Continuity and availability – Usability and operability – Flexibility, extendibility, and maintainability Note: In general, “management” – Mobility represent external energy in the – Security organizational context April 21-23, 2008 5 Renaissance Washington, DC

Slide 6: Definitions: Process • (Business) Process – Process is the way that people work together and apply methods and tools in order to accomplish business objectives • Process model – The documentation of an actual or intended process – Consists of activities, work products, and roles structured with execution paths and navigation objects – Is a gross simplification of the reality, using formalisms that represent some prioritized & essential characteristics of the real world thing – Notes: • The selection of the modeling concepts and notation has an impact on what properties of the models can be expressed and analyzed • Different types of processes may need different concepts and notations • Different approaches exist even for one type of processes (e.g. event based, flow based) April 21-23, 2008 6 Renaissance Washington, DC

Slide 7: Different types of processes • Processes can be divided roughly in three types – Transactional processes have emphasis on management, commercial, and legal activities, requiring exact data as well as clarity of decisions, agreements, approvals, roles, authority, and sequences. – Creative processes are goal oriented, with emphasis on analysis, design, and engineering activities, requiring methods, competences, and interpretation of different types of source information, but less emphasis on sequences and authority. – Community processes are dynamically self- organizing interactions among volunteers with emphasis on information collection and dissemination activities, with the intent of collective competence development and knowledge creation. • This modeling method focuses on transactional processes April 21-23, 2008 7 Renaissance Washington, DC

Slide 8: What is not a process • Organizational function is not a process • Competence is not a process • Area of responsibility is not a process • The work performed by a single person or work role inside an activity is not a process and thus not modeled as such, but covered by work instructions • Information system or tool is not a process, although it can be used to process information (note the difficulty with similar words) • Software function execution is not a business process, although in the operating system terminology, software processes execute inside the computer April 21-23, 2008 8 Renaissance Washington, DC

Slide 9: Elements of process architecture Process integration model Expense STP Travel Travel claim process budget costs process Discount & terms Discounts Traveling negotiation & terms Process behavior model Flight availability Available flights Travel Monthly & pricing maintenance & prices costs reporting Create Travel Travel Traveler travel need plan & costs plan Check Travel Plan [Appro Confirmed Plan w val limit booking / 1st Layer Work instructions 1st Layer Approver Approval ok] [Approval tickets Limit Exceeded] w Plan Check 2nd Layer 2nd layer Travel Plan Approver approval Create Travel Bookings Agent April 21-23, 2008 9 Renaissance Washington, DC

Slide 10: Process integration model It is possible that some processes do not • Process integration model shows the have interfaces, i.e. they are isolated. functional design of the process architecture Process integration model • The integration model shows only the processes and their interfaces Expense • Interfaces are unidirectional and are STP process Travel budget Travel costs claim process specified by the work product transferred Discount & terms Discounts Traveling negotiation & terms • Only case specific inputs are shown • Process instances execute in parallel Flight availability Available flights Travel Monthly according to their own triggers & pricing maintenance & prices costs reporting • Internally, all activities are tightly coupled Work product Process or interface April 21-23, 2008 10 Renaissance Washington, DC

Slide 11: Elements of a process behavior model A process behavior model consists of activities, work products, and roles structured with execution paths and navigation objects Create Travel Traveler Travel travel need plan & costs plan Check Travel Plan [Approval Confirmed Plan w limit ok] booking / 1st Layer tickets 1st Layer Approval Approver [Approval Limit Exceeded] Plan w 2nd Layer Check 2nd layer Approver Travel Plan approval Travel Create Agent Bookings An activity needs work All the value-adding The only reason for products as an input. work of a process is being of processes is to performed within the produce their output activities. work products. April 21-23, 2008 11 Renaissance Washington, DC

Slide 12: Symbols in process behavior model Symbol & synonym Description Process Input connector interfaces Output connector Activity name Activity Process Work prod. Work product Work product name elements Role name Work role Concurrent AND Fork begin execution paths AND Fork end or join XOR Branch begin Conditional execution paths XOR Branch end or merge April 21-23, 2008 12 Renaissance Washington, DC

Slide 13: Instantiation of processes • Scheduled instance – There is a predefined timing agreed in advance – Schedule can be regular or one-off – Example of regular schedule: Annual business planning, monthly reporting – Example of one-off schedule: Product creation program • Event driven instance – A case specific input work products become available (implicit event), or – A specified explicit event occurs, without an incoming work product – Examples of work product based instantiation • Customer sends a purchase order to sales department • Customer issues an incident report to service desk – Examples of explicit event based instantiation • Timeout occurs for customer payment • An internal product requirement is captured • An incident occurs in an internal process April 21-23, 2008 13 Renaissance Washington, DC

Slide 14: Execution constraints of processes • Free-running schedule – The activities of the process are executed as soon as their inputs are available, constrained only by the availability of resources – Examples: • Software design • Manufacturing • Imposed schedule – The activities are bound to time, according to a predetermined schedule, independent of the resource availability – Examples: • Annual business planning • Periodic reporting April 21-23, 2008 14 Renaissance Washington, DC

Slide 15: Process integration model, trigger types Scheduled process, no external input Process A Process D Event driven process, Synchronous input, every process no external input instance consumes exactly one Process B Process E Event driven process, Asynchronous input, every process triggered by case instance consumes an amount specific input determined by itself Process C Process F April 21-23, 2008 15 Renaissance Washington, DC

Slide 16: Process integration model, multiple inputs Event driven process, triggered by case specific input, whenever one is available, consumes one input for every instance Process G Process L Process H Event driven process, triggered by all of the different case specific inputs being simultaneously available, consumes one of each kind for every instance Process J Process M Process K April 21-23, 2008 16 Renaissance Washington, DC

Slide 17: Process integration model, multiple inputs Scheduled process, consumes an amount of asynchronous case specific inputs determined by the process instance itself Process N Process Q Event driven process, triggered by all of the different case specific inputs being simultaneously available, consumes an amount of asynchronous case specific inputs determined by the process instance itself Process O Process R Process P April 21-23, 2008 17 Renaissance Washington, DC

Slide 18: Normalization - the foundation of process engineering • Process engineering needs to combine widely known systematic methods, like – Critical Path Method (CPM), as known from project planning – Superpositioning theorem, as known from circuit theory – Abstraction, as known from object oriented analysis – Theory of control systems – Queuing theory – Graph theory – Benchmarking • In order to effectively and efficiently apply these, processes must be normalized • Process normalization criteria can be derived from the requirements for the above mentioned methods • A normalized process model is a directed graph, consisting of activities, work products, and work roles, with functional and temporal cohesion among all its activities. April 21-23, 2008 18 Renaissance Washington, DC

Slide 19: Benefits of normalization Non-overlapping partitioning of Enables unambiguous definition of activities into processes process ownership scope Simplification of process Easier to understand the big picture architecture through abstraction and define end-to-end processes with well-known properties Repeatable independently enabling Enables effective benchmarking, recognition of isomorphisms in consolidation, and re-use of best process architectures from different practices origins Clear distinction between design Improves re-use opportunities in model and deployment model different organizations Simplification of usage of Moves process architecture from an art mathematical engineering methods to an engineering science, enabling effective analysis and simulation April 21-23, 2008 19 Renaissance Washington, DC

Slide 20: Process architecture normalization rules Structural integrity Each activity has only one role responsible for the output, and change of responsible role is signified by separate activities. The topology is well-structured regarding conditional and concurrent paths. Functional cohesion Activities are partitioned into disjoint or non-overlapping sets that are connected within themselves through their input and output work products (functional cohesion). Temporal cohesion There is only one triggering condition for each process model, and execution of activities is thereafter only dependent on the path of control and availability of resources, i.e. no synchronization takes place with external activities. Modularity Change in cardinality between different activities and roles is signified by a process interface. Variants at all levels are identified and attached to the base type. Deployment details (absolute cardinalities and assignment of roles to positions) are abstracted out. Common process components are identified. April 21-23, 2008 20 Renaissance Washington, DC

Slide 21: Structural integrity: closing alternative paths Sales Product Customer Purchasing manager manager • All alternative paths Customer Receive order within parallel paths order must always be merged Sales order Build delivery configuration before joining the parallel paths. • All iterations must take place within Configuration Bill of materials the same level synchronization bars Check / decision points. Set pricing inventory No Order Available replenishment Yes Replenishment order Determine schedule Pricing Schedule Order Send order confirmation confirmation April 21-23, 2008 21 Renaissance Washington, DC

Slide 22: Structural integrity: closing parallel paths Product Sales managerSales assistant Purchasing manager Cust. order • All parallel paths within any Check credit alternative path must always be either terminated or completed and Cust. order & credit report joined before merging the alternative paths Credit OK? Receive order Yes No • A forked execution path can Send order Sales Build delivery rejection order configuration terminate without joining only, if it is an outgoing interface. Order Bill of Bill of rejection Configuration materials materials Check Set pricing inventory Pricing Schedule Send order confirmation Order confirmation April 21-23, 2008 22 Renaissance Washington, DC

Slide 23: Functional cohesion • No disconnected activities! Work role 1 Work role 2 Work role 3 Work role 4 • Activity A may be performed by the same work role as activities in the process, but it is not part of the same process. Wrong! Activity A Activity A April 21-23, 2008 23 Renaissance Washington, DC

Slide 24: Temporal cohesion • No synchronous outside processing! Work role 1 Work role 2 Work role 3 Work role 4 Wrong! Activity A April 21-23, 2008 24 Renaissance Washington, DC

Slide 25: Temporal cohesion • Activities in the middle of a Work role 1 Work role 2 Work role 3 Work role 4 process are part of that process. Activity A Right! April 21-23, 2008 25 Renaissance Washington, DC

Slide 26: Modularity: different cardinalities Wrong! Change control Dispatcher Service team 1Service team 2Service team 3 boardl Incident • Activities having a different Assign to cardinality belong to separate service team processes Task assignment Analyze Analyze Analyze defect defect defect Change Change Change request request request Change req. [approved] Approve Fix Fix Fix defect defect defect Change Change Change note note note April 21-23, 2008 26 Renaissance Washington, DC

Slide 27: Modularity: variance at the process level Own product OEM product order processing order processing Sales Product Logistics Sales Product Customer Customer Purchasing manager manager planner manager manager Customer Customer Receive order Receive order order order Sales Build delivery Sales Build delivery order configuration order configuration Configuration Bill of Bill of Configuration materials materials Make material Check Set pricing reservations inventory Material price No Order Available confirmation replenishment Yes Make Replenishment Set pricing production order reservations Determine Pricing Schedule schedule Pricing Schedule Order Send order confirmation confirmation Order Send order confirmation confirmation April 21-23, 2008 27 Renaissance Washington, DC

Slide 28: Modularity: variance at the process level • Push variance to the lowest possible level Sales Customer Production opportunity order order Marketing Sales Order processing Production Own product OEM product order processing order processing These are business model specific variants of the order processing April 21-23, 2008 28 Renaissance Washington, DC

Slide 29: Modularity: variance at the integration model level • Different business models need different processes for at least some part of their operating model • In addition to business models, business capability development (incl. process and IT development and management) needs also its own operating model variant • Sometimes this variance is visible even at the level of the process integration model – See examples on next two slides • Process architecture variance is managed using standard configuration management practices – Traceability to baseline is established and maintained – Changes are controlled and propagated from baseline to variants April 21-23, 2008 29 Renaissance Washington, DC

Slide 30: Example: Process map for a goods business Legend Product Sales Market Offering offering opportunity Customer: Process Area Sales plan intelligence: Process Marketing: Process Sales: Process definition: Process Intelligence Sales plan Product: Process Area report Product strategy Delivery: Process Area Technology Strategy Technology intelligence report Technology research intelligence report Management: Process Area creation: Process and intelligence: Process Strategy and Business model financial LRP roadmap proposal Business Strategic Initial requirement Demand planning modeling: Process management: Process capture and dispatch: Process Unconstrained Initial Change request demand plan requirement Strategic direction, Order Assessment, audit, Roadmap Change control: Process corrective actions processing: Process or benchmark reports planning: Process Unconstrained Change note and Sales roadmap exception approvals order Strategic direction, Demand-supply Operations assessment, Portfolio PM0 decisions Work effort financial frame balancing planning: Process management: Process audit, and benchmarking: Process Approved portolio Constrained and related financial plans demand plan Initial Confirmations Work assignment requirement and changes Operations and process Release Procurement: Process Workforce adjustment request analysis and optimization: Process creation: Process Performance reports Product Supplier Strategic direction, and exceptions Performance reports release options corrective actions and exceptions Action plans and targets Reporting and Delivery system CC planning: Process Production: Process monitoring: Process design: Process Production Performance reports lot Resource Competence Action plans plans and targets Achievement Raw metrics data plans review: Process Initial Request or Performance targets Behaviour in roles April 21-23, 2008 requirement incident Workforce Competence Objective and positions Execution of 30 Renaissance Customer care: Process DC Shipment: Process Washington, adjustment: Process development: Process setting: Process business processes: Process

Slide 31: Example: Process map for an ICT service business Intelligence report Legend Intelligence Offering BE + IT Increase offering Capture and agree Customer: Process Area Essential report definition: Process product offering awareness: Process business opportunity: Process insight: Process Product: Process Area Intelligence report Delivery: Process Area Technology Business Strategy Technology intelligence report Technology research intelligence report opportunity Management: Process Area creation: Process and intelligence: Process Strategy and Business model financial LRP roadmap proposal Business capability roadmaps Initial requirement Business Strategic Operating model and Initial requirement modeling: Process management: Process business capability planning: Process capture and dispatch: Process Initial Change request requirement Change Critical Strategic direction, request Fix critical incident Provide advanced Assessment, audit, Roadmap Change control: Process corrective actions incident: Process care: Process or benchmark reports planning: Process Unconstrained Change note and roadmap exception approvals Strategic direction, Operations assessment, Portfolio PM0 decisions Work effort financial frame planning: Process management: Process audit, and benchmarking: Process Approved portolio and related financial plans Change request Initial Work assignment requirement Operations and process Release Installation Workforce adjustment request change control: Process analysis and optimization: Process creation: Process Performance reports Installation Product release Incident Strategic direction, and exceptions Performance reports change note corrective actions and exceptions Action plans and targets Business capability Product Provide first CC planning: Process Reporting and deployment: Process installation: Process care: Process monitoring: Process Business capability Installation note Service request Performance reports Resource Competence Action plans plans and targets Achievement Raw metrics data Service Service request plans review: Process operations: Process fulfillment: Process Performance targets Behaviour in roles April user issue 2008 End 21-23, Service request Workforce Competence Objective and positions Execution of 31 adjustment: Process development: Process setting: Process Renaissance Washington, DC business processes: Process

Slide 32: Modularity: deployment details Huang Li, Senior product mgr, John Smith, Radio Access BU Account mgr, APAC Region • Make clear distinction between Customer Sales manager Product manager Purchasing process behavior and deployment models Customer Receive order order • Process deployment model is the mapping between organizational Sales order Build delivery configuration positions as in organization chart, and work roles as in process Configuration Bill of materials behavior model Check • Positions must be held by real inventory persons No Available • This means changing the job Yes description and objectives to reflect Order Set pricing process objectives replenishment • This can be accomplished only by the Pricing Schedule line management, not process Order Send order designers confirmation confirmation April 21-23, 2008 32 Renaissance Washington, DC

Slide 33: Modularity: process components • Process behavior models can have different abstraction levels (often referred to as process components, nested processes, or sub-processes). • Activity performed by an aggregate or higher level role (enterprise, organizational function, or a project team) can be presented as a process component. Process model • Workproduct exchange to/from the process component must be consistent with the parent diagram • All the roles performing the activities in the process component must belong under the same higher level process role • The level of abstraction within a diagram must be consistent across the activities, Component work products and roles. • Nesting should be used with extreme caution and limit the depth of nesting to 2 April 21-23, 2008 33 Renaissance Washington, DC

Slide 34: Modularity: process components Small development project Aggregate Generic review component work role Project mgr Designer Developer Test engineer Review team Review chair Reviewers Author Product Deliverables concept [draft] Assign tasks Invite meeting Features SW baseline Invitation Invitation and material Design Program changes changes Prepare Read material presentation SW design New source documents code and build Acknowl- Presentation edgement Conduct peer review Conduct Product meeting baseline Correct and Conduct Results put in CM system test Defect reports New version in CM vault Prepare Check and Fix defects closing report sign off New Soure Deliverable Closing report code and build [reviewed] April 21-23,