Thoughts on Finding Value in BPM/Workflow Technology

I found an interesting entry on my colleague Todd Biske's blog Finding Value in BPM/Workflow Technology.

Here are some additional thoughts on how the value proposition for the BPM and Work Flow Management tools could be taken to the next level.
1) Ability to incorporate "Rules" or a "Rules Engine Component" into a business process step or a work flow task would be a great addition to these BPM/ Work Flow Engines. These rules can be encoded best practices or they can be regulatory in nature or business algorithms that may be volatile while the process flow or the work flow may not be so.

2) Ability to perform impact analysis for any process flow change prior to releasing the "new process".

3) Availability of analytical tools that could suggest optimization opportunities that could make process improvement suggestions such as the following
a) how switching the steps in the process may benefit the overall process flow
b) how metrics show that there is a ton of waiting in a step that could be made optional based on some criteria
c) how analytics could drive other optimizations such as making suggestions for automation of an information gathering step

4) Ability to subscribe to regulatory bodies that govern the outcome of a particular step of the process flow.

5) Ability to create a business process template for oft used processes within an industry vertical that allow standardization in the overall flow while catering for customizations and competitive advantage optimizations in particular steps of the flow.


Best Regards!!
- surekha,

Best Practices: Master Data Management

Following are some of the best practices for adopting (note - not implementing) Master Data Management solutions within an Enterprise.

Understand the Business Context (semantics) prior to picking a solution

As per my earlier blog on EA, BPM, SOA and MDM it is very important to understand the business context, including the semantics of what each of business units, departments and entities mean when they refer to MDM entities such as Customers or Products. For example marketing deals with leads, sales with opportunities/accounts and services with paid customers. Should all the entity be referred to as customers throughout the business process? or should the master entity be referred to as Organization? Common vocabulary goes hand-in-hand with master data.For example what does this sign on a building mean? Is the building fully occupied and available for purchase? or does it mean that the entire building is unoccupied and available for rent? The business context needs to be clearly defined in terms of business units, departments and business processes.

Develop a comprehensive entity model.

Not only should one define the common attributes for the master data, one should map the entire set of attributes and where it is used. For example, in customer services the customer is used as a reference whereas in order management it is transactional data.
A set of models and documents that can be used both by Business and IT.

Establish data governance process right up front.

It is important to establish data governance process right upfront, especially as this may required dedicated resources from all the business units as well as from IT to manage the master data. The approach that worked for us is as follows:

• Executive Leadership Team Data Leadership Team that meets on a periodic basis (once a month) to establish data policies, standards, establish priorities for the data quality team
• Data Stewardship (Quality) Team are the business operations people who manage the data quality on a day to day basis. The business team enforces and ensures data quality across the enterprise.
• Enterprise Data Program team is responsible for developing and managing the programs and business rules in the various technology tools.

Integrate with 3rd party data providers

It is important for enterprises to consider bringing in 3rd party data providers such as D&B and Factiva for better understanding of the market. For example on a typical morning between 9:00am and 11:00am

• 706 businesses will move
• 578 businesses will change their phone numbers
• 60 businesses will change their name
• 49 businesses will shut down
• 10 businesses will file bankruptcy
• 1 business with change ownership

Source: Dun & Bradstreet (2004)

3rd party data from D&B could be used for leveraging legal name as the name of the organization, providing knowledge management systems that also provide news feeds as well as market statistics by industry, geography and demography and also mapping it to existing sales.Picking the right data standardization and matching engine:

This is a key technology that will either make or break the quality of your data. I agree that developing the business rules and configuring the matching tool is more important - however from a technology point of view - I would dedicate substantial amount of time evaluating and testing the tools with existing data before picking a technology. My preference would be to use one of the following matching engines:

Trillium, First Logic (now SAP), IBM or SAS.

In cases where a MDM product is packed with a different matching engine, I would be tempted to externalize the data quality to one of the above mentioned data matching engines. Just my preference - maybe the other quality engines may have got better. Do you own evaluation.

Expose all MDM functionality as services
Expose all functionality such as data (address) standardization, data matching, update master and propagate master key.

As usual please do feel free to drop me line with your comments and/or feedback.

- Yogish

Enterprise Architecture, BPM, SOA and Master Data Management (MDM)

One of the best practices for Enterprise Architecture teams to redo the enterprise road map on a periodic basis. It is typically reviewed and updated during the yearly budgeting cycle and my preference is to perform this activity every 18 months. The best practices (and the traditional approach) is to first document the as-is, next develop the target or future state (architecture) and finally develop a short term (6 months), mid term (12 months) and long term (18 months) road map. Preferable an actionable road map that ties back to the business initiatives.

It is good to document the the as-is (or current reality) from all the domains such as Business Context, Applications, Technology, organization and Funding. Typically the business context is best understood by identifying and mapping the key business processes at a high-level.


This approach not only helps have a common vocabulary between business and IT by identifying the key business processes, it also helps identify the key enterprise data objects (entities) such as Customers, Contacts, Products and orders. Based on the priorities of the each of the business process, the next steps would be to drill down into one or all the business processes as illustrated below.
Once again, it is not necessary to use a Business Process Modeling tool (however, using one would be helpful later), the objectives is to clearly identify and document the next level of details. The next steps are to perform the gap analysis on each of the activities as illustrated below.

This approach enables both business and IT clearly visualize the existing gaps, impact areas and cost estimates which helps in developing the priorities and the investment plan. In addition, it is also important to identify and illustrate the list of applications/solutions that support a given business process as well as it perception within Business and IT as illustrated below.
As we develop the actionable road map to the future state, one this is obvious, no matter what we implement or adopt, whether it is a packaged applications, BPM or SOA key enterprise data crosses the silos both from an organization and the applications. It is for this reason, there is a critical need for adoption Master Data Management across the enterprises.

It is very important to spend sometime understanding and mapping these enterprise data objects in the context of the business process. It would also be very helpful to also develop a high-level data model and transaction (CRUD) matrix associated with the business process before initiating the activity of selecting/implementing an MDM solution.

I have seen a lot examples where companies have embarked on an MDM project without developing the architecture (see my blog on Blueprinting Information Architecture for more details) and not meeting the desired business outcome. The two other primary reasons of MDM failures are:

• Lack of developing the data governance model up front that involves all the impacted business units
  
• Assuming that a packaged applications could be modified to be the master data for enterprise.
  

To keep this blog short, I plan to blog more about my thought on BPM & SOA later and please do feel free to review my CDI-MDM Summit presentation on my experience with MDM/CDI.

As usual please do feel free to drop me line with your comments and/or feedback.

- Yogish

Enabling Strategic IT through Services-Oriented Architecture

Lately there have been a flood of negative comments about Services-Oriented Architecture, especially about providing business value. In this blog I have attempted to provide a simple example on how SOA, if done right, could provide substantial value to the business for an enterprise.

Read more about this at my IT toolbox blog here.

Blueprinting Information Architecture and BPM

Following my blog on Key Learning: Blueprinting Information Architecture is key to successful adoption of SOA one of the feedback was Don't we need to define the detailed business process to identify potential service candidates?

My response to that is No and explained it in this edition of the Strategic IT Update. Please click here for all the Strategic IT Update presentation and transcripts.

Reference: Customer Data Integration: BEA-IT Case Study (my presentation at CDI Summit in 2006)

Defining and measuring Business Agility

In my previous post on defining Business Agility I had defined it as follows

Business Agility = Business Alignment + IT Flexibility

Business Alignment: Alignment between the various business units
IT Flexibility: Alignment between Business and IT + ability to rapidly deploy new business capability

Business Agility = Business Intuition + IT * (BPM + SOA)

Of course this definition is pretty generic and the next obvious question is how do we measure Business Agility? Typically most business have one primary measurement criteria - company
financial results such as revenue, operations cost, stock price and profits. There are alternate ways for measure business by adopting Six Sigma, Lean, etc. Again this approach is still business focused - and does not help in measuring IT Flexibility (especially as very rarely have I see IT organizations actually adopt Lean, Six Sigma or any such measuring criteria - maybe that will change :) ).

After giving this much thought I came up with this domain model for measuring Business Agility.

The Business Agility would be measured against each of the following domains:

Business Strategy (Business):

• Business Strategy clearly defined and communicated
• Clear defined goals for objectives for each of the business units
• Responsibility and Accountability
• Enterprise culture
• Innovation capability

Operations Framework (Business):

• Alignment of the business unit objectives to the enterprise objectives
• Alignment of operations teams across business silos
• Accountability and measurement of delivery to enterprise goals, rather than business unit goals
• Global Business Process definitions with localization capabilities
• Politics and interaction between business units
• Major part of compensation liked to enterprise goals, rather than business unit goals.

Information Strategy (Business):

• Identified clearly information needs for supporting business process
• Identified common business entities/objects such as customers, products, orders and partners that span business processes and silos
• Classified data into reference, transactional, master and analytics
• Information Governance for managing common data across business units

Governance (Business & IT)

• Business Governance (details to follow later)
• IT Governance (details to follow later)

Branding (Business & IT)

• Business Branding (customer, web site, multi-channel, products, etc.)
• IT Branding (Business perception, customer/partner perception, IT staff, etc.)

Technology Strategy (IT)

• Developing IT Roadmap (SOA Blueprinting, Standards, Architecture, etc.)
• Current state (baseline)
• Future/Target state
• Technology Roadmap aligned to business priorities

Program Management (IT)

• Program Management Office
• Application life cycle
• Application Portfolio Management
• SOA life cycle
• IT Governance (SOA Governance)

IT Operations Maturity (IT)

• CMM Level
• ITIL adoption
• SLAs
• Business Continuity
• Infrastructure maturity

These are defined at a very board level and need to be drilled down to identify or develop a maturity model for each of these domains.

- Yogish -

Selling SOA to business

One of the most important milestone in SOA adoption is getting the business to buy in. However, getting business buy in requires an approach that is sometimes not obvious. I had an interesting conversation with Jon Brodkin of Network World. Please check it out at



http://www.networkworld.com/supp/2007/ndc6/102207-avis-soa-case-study.html



and let me know what you think





Ashok Kumar

Defining Business Agility

There has and continues to be a lot of discussion around Business Agility and following is how I would define Business Agility

Business Agility = Business Alignment + IT Flexibility

Business Alignment: Alignment between the various business units
IT Flexibility: Alignment between Business and IT + ability to rapidly deploy new business capability

My observation has been that business is pretty flexible and has the capability to create a new business model effectively, if required (of course under the right leadership). The real challenges are IT's ability to integrating the new business model with the existing infrastructure. My experience has been that adopting SOA enables IT flexible to adapt to these changing business models.

Business Agility could also be defined as:

Business Agility = Business Intuition + IT * (Business Alignment + Flexibility)

Business Intuition: A common sense approach for aligning the various business unit

Business Agility = Business Intuition + IT * (BPM + SOA)

BPM: for aligning IT with the Business (yes! the business defined the business process but it is the business analyst - typically from IT captures this. Very rarely have I seen business actualy use a BPM tool for modeling business processes)
SOA: for providing flexibility