@ SOA | BPM Symposium: Keynote: Clay Richardson, Forrester

Session Abstract: Clay will unveil the latest Forrester thinking on BPM / SOA and provide valuable insight on the future of enterprise technology.

 

Clay Richardson is starting us off this morning, kids he’ll be tweeting as he presents. His presentation is entitled Detect and Eliminate BPM Budget Busters, and is focused on LEAN BPM.  LEAN, Clay describes, is about being the right size for what you are trying to do.  While the presentation is focused on BPM, many of the concepts apply to SOA.  Recent Forrester survey, BPM is the number one priority for organizations.  Hard hurt industries, such as financial services, are number one adopters.  However, at the same time, these organizations are seeing their BPM budgets being cut.  Thus, the need for LEAN BPM.

To be successful with BPM:

- Think like a CFO to keep initiative off chopping blocks

- Overcome PR issues

- Adopt LEAN practices in effort

Calls out Economist article from early this year on CFO as new king in the organization.  I read that.  Essentially, it talked about the return of initiatives that have quantifiable bottom lines, versus nebulous “growth” or “innovation” stories.

Challenge 1, BPM is high priority, but  getting funding is hard, and the amount is decreasing.  The secret, Clay says is that CFO’s have a passion for process.  Shows us a tag cloud of article titles from CFO publications.  Big words: Management, Reporting, Regulatory, Benefit, Process.

Challenge 2, once you get the budget, how do you maximize the value?

LEAN BPM Trends

1. BPM-as-a-Service

2. Platform Convergence – using right BPM tool for right job.  Also, understanding data quality implications.  BPM & MDM should be considered together.  Forrester calls this “process data management”

3. Lightweight BPM – matching the tool for the job.  If automating employee on-boarding, might go with lighter tool.  Such as Serena, which has mash-up capability.  The downside, could result in unmanaged sprawl as we saw with Microsoft Access.  Calls out need for governance.

4. Solution Frameworks

5. BPM Center of Excellence – Must important is to pick the methodology that matches what you are trying to do.  The governance process should support this.  Don’t pick the method first, understand the problem first.

Clay is talking about OMG’s Business Ecology:

- Business Ecology is about minimizing waste streams

- Business Ecology is about (something) to do with minimizing environmental impacts (green/sustainability)

Clay has a Forrester Wave up now.  Lean and collaborative components are driving the next wave of BPM adoption.  Clay mentions related blog post.  The wave he is speaking to is published in that post.

Social technology brings in the ability to keep context, maintain all related conversations.

Reviewing the wave diagram, Clay is now talking about in-process analytics, the capability to analyze and adjust processes on the fly.  In-process analytics uses complex event processing.  The industry leading this now is healthcare.

Another area Clay points out is Process Data Management.  Again, the combination of MDM & BPM.  It’s important to be able to rate the quality of the data as the process is executing.  If you know the data quality is less than stellar, you might not make an in-process decision.

Clay is emphasizing that MDM isn’t solely in the realm of SOA, it’s important in place.  Question: Does BPM take on MDM responsibility?  Should they be kept separate (I believe the question is technology/tools focused, not architecture strategy).  Answer: BPM would know the data quality and then delegate the cleansing to the MDM realm.  The real issue is getting BPM & MDM initiatives / people talking.  BPM & MDM can’t survive separately.  If the data isn’t clean, people won’t trust the process.  On the MDM side, if the governance process isn’t automated, you don’t really know if the data is ok.

This will have interesting implications for organizations that currently do MDM type work in the back-end, somewhere between the data warehouse and business intelligence.  Moves everything more real-time.  Or, data needs metadata on relative data quality (cleansed yet) to be factored into business process execution and decision making.  Interesting stuff.

Now, some group discussion on responsibility for data quality (let’s call it health), and the assumptions data consumers make on that health.

Challenges on BPM projects:

- Consensus log jams

- Skills mismatch – make sure the analysts you rely on are skilled in process design, not just process requirements gathering.  This is the difference between a (traditional) business analyst and a process analyst.  Keys are (1) recognize and eliminate bloated requirements, (2) have evolutionary mindset – recognize the 80/20 and (3) collaborate. 

Besides the harder skills, analyst also needs to “have passion for process”.  Passion includes “process orientation” and “tech savvy”. 

Audience comment, Clay agrees, this is a re-emergence of industrial engineering. 

- Waterfall mindset

One more thing on the skills, the best process analysts have engineering backgrounds.

In discussion with the group, Clay is telling a horror story of government waste, on a “transformation” initiative with a 500-page requirements document.  In the end, the “solution” didn’t meet the original need.  Ignored key value objectives.  Perfect example of need for LEAN.  Focus on value delivery.  Stop when value stops.

Key differentiation with “re-engineering the corporation” is the focus on people.

Comments

[Popy]

Hi Steve,I see MDM as a tool to improve data iegrtnity. If you ask any Financial or Business executive data iegrtnity is always been high on their list of areas of improvement.Many decision makers fail to see the ROI of MDM, even though independent studies have seen yields of $800K to $1M of GM improvement for ever $1B in sales volume in Organizations that deploy MDM. It may be hard to visually percieve this, but when you think of all the re-work, delays, out of stocks,or shrinkage that are incurred when a PO manages to get through the system with corrupt or innacurate core data, It is easy to see the roadbumps that are incurred throughout the procurement to pay process.MDM also doesn't have to be a formal packaged software. It can be executed with sound logic and business processes, that support all alike attributes living in one place, and not replicating data attributes accross multiple databases. Enjoyed the read. Industry leaders are embracing and executing MDM. They see and fell the value.Thanks,Mark

[Muhammed]

MDM is about mastering a intofmarion based on the operational/functional needs of the business. Not organizing db tables. It requires a technical component as a backbone or tool to support business drivers that are enforced through data governance.Internal departments slant the same data all the time for many different reasons but, getting intofmarion from disparate data sources is one of the issues (local data sources). Integration is another. Silos are developed because its built into integration patterns. Business gets lost at this point. They don't want to hear technical jargon regarding large number of integration mappings, translations, or sequences. They want one place to see a customer, order, product, finance, asset, etc. MDM simplifies it for business when presented as multi-domain masters.In my designs business does have a place in driving multiple domain mastering since they define customer, product, services, finance, and assets for one simple reason: a need for a common voice to its customer and partners that translates to revenue. Most companies don't do that today very well and it cost money. My recommendation to business when discussing multi domain MDM is envision it as a shared intofmarion as a service (IaaS) component relative to the very domain required at the point of need (like up-selling, ordering, customer interactions, product development, etc). Extract those intofmarional needs from a single source be it customer (party model based), product (dev-to-runtime based), financial (code based) and more. Who defines these requirements? Technical people? I think not. MDM starts from a functional business need and cascades to IT portfolio. Just as most technical solutions do in today's business world. The maturity of an organization to handle MDM becomes a matter for the business to resolve. Not IT.

[Rhanie]

Nicely put, Tod. I think most people in both bussneis and IT think that once the MDM platform is implemented, they're done but as you point out, that's when the fun starts!

[Cassandra]

I have to admit I am very impressed with the quality of your blog. It is certainly a pleasure to read as I do enjoy your posts.

[Sueann1950]

Muito obrigado por escrever isto, era incrivelmente informativo e disse-me uma tonelada