Business Process Modeling

In the last article we discussed about Current State Decomposition . But it is easier said that done.

For very large Global Enterprise with siloed Business Functions grown largely through acquisitions and mergers this can be a huge undertaking. That's where Business Processing Modeling Platform or solution come and helps accelerate Current State Assessment and optionally increase efficiencies by automating Business Workflows.

Background:

Business Process Modeling (BPM) is a culture, discipline for operational efficiency by discovering, analyzing and optimizing Business Processes. On top of it there is opportunity for automation, introduce one. There are many SaaS based COTS solutions out there (Appian, Pega, Adobe to name a few). The focus of this article is to build prospective around Business Process Modeling and hope it would help you with your journey , whether you are just starting on Transformation or you want to unwind existing Business Workflows. With right prospective you can always go in the Market with a right mindset and apply decision matrix while choosing the solution which is aligned with your long term strategy.

Problem Statement:

Classically BPM is done using legacy tools like Visio, Excel, Word and PowerPoint. Enterprises lack Universal understanding of Business flow between Business, Technology, Operation and other support functions. That creates lack of knowledge of Business Capabilities and actors driving those. Digital Transformation capabilities are usually missing.

This creates lack of end-to-end documentation of the Current state. That will typically include list of interfaces, processes.

Had there been a BPM capability in place, such artifacts will be generated organically over period, and which would ease out any Current State Analysis.

It adds value in Analyzing Current state with eye on Gaps, pain points and coming up with Transitional Level of Flow and Transitional level of roadmap of architecture through to Future Target State.

?Day in Life:

A typical day in life in BPM is spent on Model requirement, Design a flow, Modeling it, Executing It , Monitoring and Optimize it.

?Typical mandated use cases:

1.?????? Mapping Business Process Flow:

Lack of BPM in current state will make it more logical to using BPM for To-Be used for Business Process Flow mapping of Future Transitional or Final Target state.

?2.?????? Business Application Roadmap:

With Enterprise Transformations it is key to understand which applications will be decommissioned, which will stay in Transition, and which will stay in Final Future State.

3.?????? Business Workflow Automation

This will enable create overall Target Operating Model and will give added visibility.

As a result, we will get a holistic picture of Business Architecture of the Organization. This in turn will help align architecture with overall Transformation Strategy.

?

Capabilities:

Key Capabilities to look out for:

·?????? Models tailor made for different industry vertical should be available. Customization should be available for different Modeling standards (BPMN 2.0, EPC Model...)

This helps create consistency across multiple Business and Operations Organizations within the Enterprise.

·?????? Risk and Compliance: Add Risk Profile with consensus form Business partners.

attach Minimum Durable Risk to a Business Process. Then create Control mechanism around it.

·?????? Ability to Zoom in and zoom out from Domain to Processes and vice versa.

·?????? Integration with ServiceNow.

·?????? Ability to integrate and import Business Process Flows from various places including legacy platforms.

?

Advanced Capabilities when overall architecture reaches to certain level of maturity.

·?????? Process Mining:

·?????? Simulation:

·?????? Robotic Process Automation:

·?????? Ability for 3rd Party API Integration.

?

User Roles:

Every Access should be mapped to Role and Privileges. ( For instance , some of the personas can be Viewer, Pro Viewer, Designer and Admin)

(NOTE: This is generalized mentioned about Roles available in the COTS platforms out there , each solution may have it's own variations with Personas and Access Control)

Viewer: Basic search of Model and Business Process. They can collaborate with Business Teams. They can comment on Model and can request for the change. Identify the Processes and connected with those.

Pro Viewer: Will have all the privileges of a Pro Viewer has. They can contribute to the flow when it is defined. But additionally, they can contribute the workflow. They can act as Moderator for a given Model or given process. They can comment, request Change Control and delegate the access.

Designer: Is higher in privilege hierarchy is heavy process user or Process SME. He can setup model and setup best practices. They can do all sort of things needed to mature the process.

Admin: Is a super user who has all access available in platform.

?

·?????? It should not only about Process Flow , but you should be able to create architecture design as well and map as many attributes as we need.

?

Learning and Knowledge:

The learning curve should be as minimum as possible and that’s where resources from Solution vendors should help in the form of documentations, Videos, Live Trainings, Certifications and Communities.

Platform readiness internally:

·?????? It is very important to look at Security aspects of these COTS solutions and security architecture review should be thoroughly conducted.

·?????? Then in order to baseline the platform we should have ability to upload Application inventory .(especially with CDE from those applications.)

·?????? Create and attach Risk Profiles.

·?????? Finally Business capabilities should be mapped (with Business Owner, Technology Owner ..)

Overall, we need structured thinking for various Business teams. We will have to encourage adaption for any Business Process mapping.

Technical Architecture and Design can be done on BPMN 2.0. Each Business area according to their Business Model must build their building blocks.

For instance, it we should multiple enterprise domains like Investments, Distribution, Finance and others come together.

All the business processes should be rolling into Domain views consistently. So, it can be used for TOM development around your business workflows. It is basically should be a primary housing, For all your Business Processes and Roadmaps.

We need a proper RACI in order to define personas.

?

?

Aligning Prospective:

·?????? Business Teams would like to have easy user experience and a Business centric view,

while Technology teams will have different prospective like Segregation of things, a broader view. So, Technology and Business notions might be different, and we might need to find right balance. We should be working with Business Teams closely to create the right layout aligned to the organization structure.

Typically, All Processes in Front Office, Middle Office and back office including Data Platform should be rolling under Investment Services. Then have all Functions within FO, MO and BO.

Underneath processes can be interlinked and nested flow, creating a value-added chain diagram.

·?????? The Model standard decision should be left to individual teams.

·?????? In the overall mapping individual applications and SLAs can be linked to Business Processes. That's critical power of this in Model design. Connection to tools like ServiceNow and underlying CI objects, will help connect Business Architecture with Technology Landscape.? It will enable a view of Business Processes and their Technical Systems. We can look at End to End.

?

·?????? EPC has events and Business Functions are mapped. We can control inputs and outputs. We can assign RACI to it with personas and role for the process.

·?????? It is not replacement for ServiceNow. It has some basic capabilities to import from standard tools like Visio if you want to map out existing Models and Workflows. This will zoom in from Business Capability Group into individual function. Sometimes line is drawn for solution in only Business Process Modeling and Workflows. We might need to find synergies with other tools for Tech architecture.

?

·?????? If the Process flow is very busy and complex, you can also give the link instead for that , from the Platform. The whole process can be exported in the Word to get end to end visualization for info graphic documentation.

?

Licensing:

·?????? There are typically multiple tiers for licensing and Pricing: Personas level licenses (Admins and Designers), concurrent user limits for access. and maximum users designated as concurrent users. Predominantly users should be Business teams, so it's Business teams who should drive these Modeling and Workflow designs.

Technology team can always help but primary onus should be on Business Teams. Technology should enable the platform and then seat back.

?

Access Control:

Permissions should be granular. For instance, if you are a designer in Corporate Actions Team, you should not have access to Trade Processing Models and Flows. There will be boundary in terms of Access control using Access levels and Roles.

?

Summary:

Beyond initial evaluation certification of solution, ultimately evolution journey should be based on Use Cases we want to adapt it for. Usually with SaaS solutions lot of aspects of Support in Operating Model

is taken away, but right internal Operating Model is still important. Also, it is key to take a Top down approach, starting with all of your Enterprise Business Domains and iterating through lower levels. Ultimately there should be only one universal interpretation of Business Workflow and process both by Business Teams and Technology Teams.

Please feel free to leave your feedback and comments here. Please subscribe to my Newsletter for more such meaningful articles and will be happy to engage any meaningful conversation in the area.

#BusinessProcessModeling #BusinessArchitecture #BusinessCapabilityModel