IBM Smarter Business 2012 - Headless BPM
•Descargar como PPTX, PDF•
2 recomendaciones•2,563 vistas
A major financial institution needed to improve its global pricing calculator. They saw the opportunity to implement a solution that included approval processes. They also wanted to be able to scale the solution up and include their extensive offshore centers across the globe. The project, with consultants from Ascendant Technology and implementing IBM Software, was instructive. During this session we will outline the important opportunities available should you want to scale up Business Process Management projects. Talare: Todor Mollov, Ascendant Technology Besök http://smarterbusiness.se för mer information.
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a IBM Smarter Business 2012 - Headless BPM
Similar a IBM Smarter Business 2012 - Headless BPM (20)
Más de IBM Sverige
Más de IBM Sverige (20)
Último
Último (20)
IBM Smarter Business 2012 - Headless BPM
- 1. Case study: Headless BPM Todor Mollov Senior technical specialist Ascendant Technology (an Avnet Company)
- 2. Agenda • Introduction • The Business Problem & Project Background • The BPM approach • Why Headless BPM? • Project and solution details
- 3. About Ascendant • 600 People Worldwide across 4 Continents o Europe – London, Stockholm, Belgrade o US – Austin, Denver, and San Francisco o India – Chennai o Brazil - Florianopolis • Expertise in both Business, Creative and Technical Consulting • Part of the AVNET Group • 500 IBM Certifications, 21 IBM Redbooks
- 4. About myself • In the software industry for 10 years • Using IBM software for the past 5 years • Live in Worcester, UK • Married with 2 boys • No medals in rowing yet
- 5. The Business Problem & Project Background
- 6. Project background • The client: major international financial institution • Selling financial products to corporate clients • Complex pricing calculator – profit and risk • Delivered by .Net offshore team • Basic UI
- 7. Customer’s requirements and constraints • The requirement : Approval process for the existing pricing calculator – different level of approvals for the deal, based on product types and product parameters • Two phase process – modelling of pricing and pricing approval • Keep the offshore delivery capability in .Net – existing platform of choice
- 8. “Business As Usual” Begs for Operational Improvement Account Administration Customer Finance Service and Ops Inefficient Executive Management Ineffective ?? Invoice Inaccurate Reconciliation Teams Incomplete Inconsistent Inflexible Invisible
- 10. IBM’s Business Process Manager Finance Executive and Ops Management Account Administration Risk Management Customer Teams Service What to do. How to do it. When to do it. 10
- 11. IBM Business Process Manager Social Mobile Coaches Portal Business Space Optional Microsoft Add-ons Process Server Core BPM Advanced Automation & Integration BPMN Process Rules Performance BPEL ESB Adaptors Data Warehouse Deploy Measure Governance / Visibility Define Improve Shared Assets Server Registry Versioned Assets Process Center Network Multiple Process Centers Process Designer / Process Center Integration Optimizer Console Designer
- 12. Agile BPM Approach • Develop the solution with the Business, not for the business. • Agile development and deployment cycles (12-18 weeks in total duration) User stories to capture business needs. Time-boxing, 2-4 week iterations. • Prioritize iterations based on business value and risk mitigation. • Frequent “Playbacks” to capture feedback of the sponsors and validate iteration content. • Monitor execution and incorporate changes quickly.
- 13. Typical BPM solution • UI and Process in one application Screen: Screen: Screen: Coach screens Approve Review Deliver BPM no Review Flow logic Approve Start Is approved? End Deliver yes SOR (System of Data store/ Record) DB EIS BI reports
- 15. What’s headless software? • No GUI • Provides set of API for controlling the execution • Useful when automating repeatable task with predefined inputs or integrating with another system • Examples: headless installation, headless server, headless Linux
- 16. Options considered .Net BPM 1) Have BPM implement the whole UI page page 2) Only buttons for approve/reject .Net page 3) No coaches at all – REST API BPM buttons
- 17. Decision points .Net BPM .Net page BPM Rest API page page buttons • Requirements - “Lickable” interface • Consistent UI experience – same web controls, view details and approve on one page • Technical challenge - event handling – how do we capture the end of the coach in iFrame • Capability – available team with .Net skills already developing the presentation layer
- 18. Our solution Headless BPM – no GUI developed in BPM i.e. no coach services. .Net Screen: Screen: Screen: Web pages Approve Review Deliver IBM BPM REST API no Review Flow logic BPM Approve Start Is approved? End Deliver yes SOR (System of Data store/ Record) DB EIS BI reports
- 19. Solution Details • External Activities – external systems working with BPM tasks • REST API – getTaskList, getTaskDetails, claimTask, finishTask. • Authentication – task list per user - SSO using WebSeal and LDAP • Rules/triggers, Emails, Timers, escalations • Automated regression testing
- 20. Project team Onshore Offshore Product .Net LDM owner .Net owners developers .Net developers developers UAT manager PM/Managers BPM CoE Solution Testers architect Testers Testers BPM designer BPM Tester
- 21. Lessons learnt • Scrum meetings – 25 people for 15 minutes, too formal and reporting – focus on the problems not on time reporting • Time zone – gone home by 2PM (6:30 PM). Less time for collaboration. – one tester was working UK hours. • User story done ? • Away from the source of the requirements – write specs
- 22. Summary • BPM for approval processes • For existing UI platform and skills – consider headless integration • Be prepared for the challenges of offshore delivery
Notas del editor
- First, the decision was that theBPM application will integrated with the .Net application. The .Net app will create the modelling part and BPM will create the approval pages. However, it appeared that the approval pages must show all the details from the modelling part. This required to re-implement the whole modelling part in BPM.The next step was that we will have .Net page including BPM page – iFrames. Lickable interface requirement didn’t allow to have pop-up windows.The technical problem then was to capture the action done in the iFrame page. How to capture the event that user clicked on approve and show another .Net page. Having these challenges, the decision was that the buttons can be easily implemented in .Net anyway. So the whole approval page will be done in .Net and the result will be submitted to BPM.
- Speaker notes: Describe the benefits and problems when working with shared Process Center and the role of BPM CoE. Infrastructure prepared for POC but the BPM adoption scaled too quickly and had to rebuild the DEV env and migrate the apps to solve performance problems.
- Speaker notes: - Explain that Scrum meetings we too formal and hence not very useful. - The challenge of offshore delivery –times zone difference means less time to work together at the same time.- Another challenge was to define when a piece of work was done. There is features not implemented because they are scheduled for later implementation and features missing because of incomplete requirements, delays in the design or wrong implementation. - Offshore means away from the source of the requirements – the business. Increases the documentation overhead to capture the requirements, review, update, etc.