Storytelling, BPM and the creative process

This is the third day. Day one was 6 hours of content. Day two began at 9am and the content portion ended at 8:15pm with Karen Armstrong revealing her "TED Wish" that leaders, maybe 1,000 leaders, of the three major monotheistic faiths would establish and proliferate a single governing document, a Charter of Compassion, for how the scriptures of faith should be interpreted. A mental model for reading scripture, if you will, based on looking for the Golden Rule in each passage. Not a bad wish.

Today we just went from 9,000 feet deep (still 4,000 feet above the deepest parts of the ocean floor) to the top of the oldest redwoods in the world. And there was unexpected life in both places. We also heard from Paul Stamets who believes, and attempted to show, that mushrooms have the power to save humanity. At a minimum we saw how fire ants could be eradicated with mycelium. It was pretty good, but not as good as seeing Stephen Hawking speak to us Wednesday, and hear him say that, in his opinion, there probably isn't life (as we know it) in the Milky Way galaxy. Rare earth, indeed.

Well, I come here to keep the entirety of the world - not simply my software world - in perspective, yet this year I find myself drawn further into the web of "process" - Lombardi-style. Amy Tan considered this phenomenon when she said that while writing about a given subject she often stumbles, serendipitously, into chance encounters with the topics she's writing about. She said she's come to the conclusion that "when I am aware of chance encounters being connected, then chance encounters connected to work I'm doing tend to happen more often.... so now I just look for them."

And so I see process everywhere. Today a track on the creative process. Yesterday a disorienting, disturbing talk on the process that led to Abu Ghraib. Today I met a gentleman who "works with companies on their mythology." He helps them rediscover who they are, so they can get on with becoming who they want to be. I call that BPM, he calls it mythology (no wise cracks from BPM cynics, please). Today Brian Cox, one of the scientists at the CERN big particle accelerator said that once the accelerator comes online (the final pieces were put in place, literally, today!) then the story of the process of creation might actually become known. We may know more about who we are, and may be in a better position to figure out who we can be.

The other aspect of all this that's been interesting is the number of people who talk about the closer we get to actual creative process, the closer we get to simplicity. Complexity is the result of time and scale, but the heart of any great scalable system is simplicity. And I find in this, again, an important connection to our world at Lombardi. Brian Cox showed us the very few elements that existed at the beginning, during the 1/billionth second of the big bang.

At Lombardi, we believe process is the story. It is the structured book through which what you do and what you want to be is communicated. How we behave and to what we aspire form the lynchpins of culture. A company's relationship with its customers. How it behaves amongst its employees, between one another. These behaviors are instantiated in processes, whether formal or informal.

At many companies, their mythology, their culture, has become stale. Inert. It's not known, it's not understood or it's inaccessible. We find this is often the case because the means of transference have become so convoluted that any semblance of narrative is lost. When process is not explicit, which is simply another way of saying the process is informal then, oddly, communication becomes formal. And this is exactly the wrong way to go. Folklore, the stories of culture, these memes survive in large part due to their informality.

Ironically, then, the result of informal process is formal communication ("knowledge is power" syndrome). The result of formal process is more informal communication ("transparency" and "open-door policy").

This formal communication results in left-brain actions on the part of the people in the process. Silos. Hidden factories. Leading to unproductive work. Low quality. More exceptions. And finally, lost market share.

Transparency results in innovation - positive change based on trust. "Good fences make good neighbors". If you look at the history of this phrase, it wasn't to say that "excluding others is a good thing," it originally meant that explicit relationships enhanced trust and understanding, and therefore increased empathy and compassion.

To me, BPM is the means by which you document, communicate and then instantiate your actions and aspirations. If your processes are the mechanisms that transfer your culture - internally, externally and into the future - then BPM is the means to make your culture great.

BPM can help you create that possibility.

February 29, 2008 at 05:21 PM | Permalink | Comments (1)

On Technology Security Standards: BPM, SAML, XACML

In a recent post, enterprise architect James McGovern wondered whether BPM products, like Lombardi's, support XACML.

So I replied with a comment discussing BPM and security mechanisms:

With respect to security there are two fundamental issues: who are you? and what do you have access to? In general, the OASIS SAML specification deals with the former, and the OASIS XACML specification deals with the latter.

Lombardi Teamworks explicitly supports SAML as a means of identifying who you are and passing that around. Very few, if any other, BPMS vendors support SAML and it's a non-trivial specification to implement. Lombardi Teamworks does support SAML and as a result, we have many very secure implementations and customers.

Authorization is a bit different. Generally speaking, XACML defines (1) the mechanics of defining a central set of authorization policies, and (2) how a service accesses those policies. That is, and this is key, you want the service being accessed to be its own enforcer, based on policies set in the central policy repository.

You want the called service to ask the calling application for credentials, and you want the called service to be the one that _allows_ access based on the policies. So as we see, the XACML check is done under the covers of the web service that "houses" the resource being called.

BPMSs (not just Lombardi's, but all of them) don't actually house the interfaces to external services, but rather hold pointers to those services. These are held as metadata inside the process definition. For example, the service endpoint address URI is stored, but not the WSDL. Therefore, the [XACML-based] security implemented under the covers of the web service operates independent of the BPMS [or any other client]. However, in most advanced organizations it relies on the SAML (or other) assertion of who you are and what context (application) you are running within. This is why it's the SAML implementation that forms the basis for security in the BPMS world.

James reflected on this in a subsequent post, and in that post he raised a few more questions... so let's continue the conversation...

1) When the BPMS is the service provider (not the consumer)

James says "the rationale for storing policies centrally is more than just one product needing to be its own enforcer. In an integrated world where a BPM engine needs to talk with an ECM engine, the need for these two to have the same access control policies is important."

Yep, I agree. I didn't make reference to it in my post, but of course for any services you expose from a BPMS (or ECM, or ERP or other platform) you should be able to author them so that the centrally defined policies govern who has access to that service. I suspect that all BPMS allow for this.

2) User interfaces, security policies and the BPMS

James says "It is good to see that XACML checks are done to protect web services but they may also be leveraged by UI components as well as access enforcement may require displaying or not displaying a particular feature/function."

Having UI's call the central policy server for presentation-layer rules on what aspects of a UI to show would be an interesting thing to debate. I'm not sure I'd agree with that as a good mechanism. It would be better for the presentation to drive itself based on the types of data that were presented to it (in the same way that device-dependent presentations are derived). That is, you don't want the presentation layer figuring out the security because that assumes the presentation layer has access to everything to begin with. So I guess I would take issue with the premise.

If, however, you want to drive your presentation-layer in this manner, you probably also want the presentation layer up and outside the BPMS. So while in Lombardi's BPMS (Teamworks) you can author UIs, we also give you the ability to easily plug in your own UIs for particular steps in the process. This would be the mechanism to separate the UI from the process definition, and also allow you to drive the particular UI from centrally-defined policies.

3) On BPMSs storing their own users

James says "I think many would agree that a BPM engine should store processes not users."

Yes, I agree. At Lombardi, you don't have to manage users in our store, if you manage them elsewhere (like LDAP or AD). I would say, though, that in the real world we've found that there are attributes you want to use in a process-context that aren't present in your corporate systems. These may be user attributes (like skill level for a particular job) or they may be role-related (a person's relationships to others change depending on the process context).

So in Teamworks, you have the ability to not only use the central user store, but, if you desire, you can also extend the attributes for a user (or role) without mastering that user... sort of a hybrid system. Again, if you manage the attributes centrally then the BPMS will pick them up. It's a matter of choice, and, to some degree, practicality.

We also think this "relationship" issue is bigger than LDAP and AD. Of course, matrix'd organizations have existed for a long time, and these basically reflect that my relationship to people around me change depending on context. For example, the CIO of Company X reports to the CEO of Company X for operational issues, but may also report to the CIO of ParentCompany Y for other things (like use of standard technologies).

As companies begin to measure more of themselves using process as the normalization, then these numbers of "matrix organizations" expands. So we think that organization modeling is part and parcel of the larger BPM discussion... and that these models will integrate with [LDAP or AD], but provide more extensive information. This is an area that I think will really change and expand in the coming decade, as the convergence of increasing security along with increased decentralization of computing resources gets mainstream emphasis.

Conclusion

Securing distributed systems has been long overlooked due to real-world needs to get technology out the door. But this aspect of enterprise architecture is critical to successfully embracing not just distributed technologies like BPMSs, but also important so-called social computing platforms like wiki's. Without good guidelines and well thought out policies, companies just won't embrace these critical technologies. And as a big company, it is critical you be able to embrace these because your smaller competitors are, and they are stealing your most profitable customer and product segments.

Thanks, James, for a good forum to have this conversation.

Technorati Tags: James McGovern, Security, SOA

November 14, 2007 at 12:56 PM | Permalink | Comments (0)

New BPM, or Old AppDev?

In his recent post, Neil Ward-Dutton talks about how WebMethods customers are doing traditional application development under the guise of Business Process Management. Folks, automating a business process is NOT business process management! Sandy Kemsley says "these customers are coming from the traditional EAI-type usage of webMethods." Yep. And, in summary, Neil says:

"Understand what, exactly, you want to do with BPM. Understand the key characteristics of the processes you're trying to improve, and equally importantly, who's driving the work—is it business people, IT people or both?

"Unfortunately, getting to the bottom of things is not as simple as saying 'I need a human-centric BPMS" or "I need an integration-centric BPMS'."

Neil, you've hit the nail on the head! And, indirectly, you raised the key difference between what used to be called "the pure-play vendors" (like my company, Lombardi) and the "stack vendors" (IBM, BEA, Tibco, WebMethods). I prefer to use the terms "new-BPM" and "old-AppDev" to describe the vendors, but however you slice it, the new-BPM tooling is directly targeted at enabling new levels of participation of business people alongside IT people in the solution scoping and development processes.

As you point out, that difference has nothing to do with "human-centric," "document-centric," or "integration-centric" but whether the user is approaching use of the BPMS as a new developer tool (with, for example, the semantics of BPEL), or as a way to change the way business and IT interact during solution development. This developer-centric vs. business-centric approach is the key difference in deciding what tools you will be successful with.

Our experience is that if a company uses a BPM tool in the same old way (IT application development owning all aspects of the project and the business expected to deliver a set of detailed requirements at the outset of the project) then the project will fail exactly as often as any traditional waterfall application development effort. Which is fairly often.

But if the customer wants to move to a new model for those processes owned by the business, with the business contributing people full-time to the solution development effort, then the new BPMS tools are effective at increasing success rates, lowering costs, and delivering better solutions. The new BPMS tooling by the focused BPM vendors is better at this, far better, than any of the tooling the stack vendors provide. The old-AppDev vendors provide tools for their target market... and that is not business people with moderate technical skills. In contrast, the new-BPM vendors are focused on providing tools for a new solution development model, one that promises increased participation by the business, while retaining full-control for IT.

Technorati Tags: BPM, WebMethods

November 9, 2007 at 10:23 AM | Permalink | Comments (4) | TrackBack (0)

The Army You've Got

I was hiking today up above Portland, Oregon at the Multnomah Falls. Spectacular. Except my damn knees. I started thinking about how I hear people say "gee, I wish I was <fill in younger age here> again" and I have to say I really don't want to go back to most of my younger ages but it sure would be nice to have younger knees. I saw 18 year olds running down the 600 foot drop of a trail. I want their knees. Well like Rummy said "you don't go to battle with the army you want, you go with the army you have."

Oddly, this got me to thinking about business process management and about how almost everyone (except Lombardi, of course) has got it wrong. Most people think business process management is about Process. Wrong. Business process management is about people. Specifically, it is about making people more productive. People of diverse skills. People put in positions they might not be quite ready for. People retiring from their jobs. People starting their careers. Dear reader, if you are in a company with more than, say, 1,000 people, I wonder how many of those people do you think are perfectly suited to their jobs right now? How many have the perfect levels of skills, abilities, training and wisdom to do their jobs at peak efficiency right now? How many in your workgroup fit this description? I'm guessing you have people with different levels, some achieving the perfect blend you need, and some not.

Look, the point isn't that your organization needs help. In fact, the point is that your organization looks a lot like everyone else in this respect! Business process management should be thought of as a way to help teams work better. The team you have is the team you have, in many respects. You can't take the perfect team into the battle of competition tomorrow! You have to get a lot of the job done with the team you have. You might top-grade over time, and you might also lose some of your best people to promotions and their own career changes. The fact is, the people in your business have very different combinations of "perfection" at any given point in time. And in this globalized world, the question senior management asks is "how can I be most effective with what I have?" (A recent NY Times article quoted HP CEO Mark Hurd: "C.E.O.’s work on three things: strategy, operating models and people." Which, loosely translated I think means: what strategies can we pull off given our people, processes and customers?")

If workflow is the means by which we define behaviors, then the real advance of business process management is that it is the means by which we normalize how we measure behaviors and correlate those behaviors with the business results we achieve. Let me say it again: business process management is about how we measure people and correlate their activities with the business results they achieve.

In fact, practiced purely, I'd argue that it has nothing to do with how something gets done, only how well it gets done! It is today's evolutionary state of the most advanced de-centralized management capability. And by the way, if you don't get a grip on this issue - how to decentralize control of behavior while retaining insight into results - you will be run over by the people and technologies of the 21st century. Wiki's, blogs, SaaS word processors, SaaS spreadsheets, IM, Facebook (or Open Social) computing platforms... this all means you will have less control over the specific workflows, and more creativity than you ever thought possible. Your BPM initiative better be figuring out how you can deal with this... because these are becoming parts of the best processes in the world.

BPM helps you get a handle on the chaos that is real life, makes it explicit, and helps you manage around it. It does this by making the work explicit, linking that work to the reasons you are doing the work, and providing insight into the results. We call this trace-ability and it's key to doing business in the 21st century. It allows you to take the army you've got, and make them as effective as possible in executing against the strategy you've set.

As for me, there's direct traceability from the hike to my aching knees... time to take an Advil.

Technorati Tags: 21st Century Process, BPM

November 2, 2007 at 07:48 PM | Permalink | Comments (1) | TrackBack (0)

Lombardi & Google: Partnership of Titans

Just a quick note to give you this link to a blog post on Google's site where we talk about the development of our Lombardi Blueprint product. That product represents a real leap in capability in terms of process mapping, documentation and modeling... the ease of use and business value it provides is pretty cool. And it really couldn't have been done as efficiently without Google's "Google Widget Toolkit" (GWT). So the blog post is on the GWT blog. Since the post went up, a ton of developers looking at using GWT have hit the Blueprint site, and we're really pleased and proud to be the poster child for this AJAX-y technology... which we hope (obviously) becomes somewhat of a standard.

Alex Moffat, the lead engineer on the Blueprint product line, wrote the post and I like how he sums up the business goals for the product:

The challenge handed to us was to create a tool that the average business user could use to document and manage their business processes. It had to be easy to use, encourage collaboration between team members, and provide a shared repository for all of a company's process documentation. Workflow functionality had to be on par with our competitors: Microsoft Visio, IDS Scheer's ARIS, IBM's WebSphere Business Modeler, and other desktop modeling tools. But we also wanted wiki & shared whiteboard capabilities to store information. Editing should use the drag and drop interaction users of desktop apps are familiar with. We ended up with some additional features that really set us apart:

• An intuitive map view as a high level visualization of a process

• Automatic workflow diagram generation

• PowerPoint generation for easily presenting the process

• Online chat functionality

I think this shows how achieving business goals is more and more becoming inextricably linked to the technology addressing those goals. This application simply could not have been developed even five years ago, without an investment 20-50x of today's cost... which obviously means that the economics wouldn't support it. As it is, Blueprint is licensed at the ridiculously low price of FREE for the Personal Edition, and only $50 per month for the team account!

We're doing the same thing with the more traditional behind-the-firewall BPMS integration platforms, today. They are getting simpler to use and this is changing the game of what types of enterprise process applications can be built because they are changing the game on who can build them!

Business Process Management is about knocking down the traditional development skills while retaining the important, traditional development patterns. Blueprint is one aspect of this, and traditional BPMS's, like our own Teamworks, is another angle of attack.

Business process management is not about one or two simple, specific things. It is about the pervasive shift of responsibility over all process-related elements (documentation, compliance, execution, improvement) from IT to the line of business. We're happy to be pushing the envelope on how we deliver all this capability. And thanks again to Google for creating a great framework for us to leverage.

Again, here's the link to the blog post Lombardi Blueprint, Built With GWT.

Technorati Tags: Google, Microsoft, Lombardi Blueprint, Visio, WebSphere

October 17, 2007 at 11:16 AM | Permalink | Comments (0) | TrackBack (0)

'Cause There Ain't No Cure For The...

Only in the tech world could we be in June passionately arguing about "top down" and "bottom up" and not be in a convertible drving up PCH to Zuma with a cooler full of Pacificas and limes in the trunk. Well, to return to the summers of your youth and live the dream of BPM, now's the time to download this 8-track podcast., set aside Danielle Steele and for the next 22 minutes listen to ebizQ's Gian Tratta interview me about why and how to implement top-down BPM strategy.

"Our view is that business process management is a business function and it is something that should be pervasive to your organization. If you're really going to start viewing your company through the prism of process, this requires top-down commitment."

I know that's pretty steamy but if you can handle it, there's more where that came from. Enjoy...

Technorati Tags: Blueprint, Gian Trotta, ebizQ

June 6, 2007 at 07:48 AM | Permalink | Comments (0) | TrackBack (0)

Specification Inflation, Hyperventilation and Ultimately Consolidation

Seems like there's been a lot of things going on in the BPM space over the past few weeks. Bottom-line? End-user organizations win as vendors as diverse as IBM, SAP, Capability Measurement, MEGA and Lombardi agree! The BP-* stack is on track... here's a couple of them, courtesy Object Management Group...

Business Process Maturity Model: The OMG formally approved the BPMM specification last week in San Diego. This is a great thing for the industry, as it provides a reference model for measuring a company's journey to process excellence. As you might expect, the primary beneficiary of process excellence is making the people in your company more efficient. Far and away the best way to do this is to reduce rework and improve your ability to estimate results. We're talking doubling the productivity of your people! All of your people... so if you want to put a number on the ROI of BPM, just assume you doubled your revenues with the same number of people and then estimate how Wall Street would value your company. That's what BPM can do, over time, and your progress along this is what BPMM measures. Non-trivial stuff. OMG is really stepping out on this one, as it is a business specification with (seemingly) little technology to implement. Of course, my view is that baking in these measurement strategies is exactly what technology can do, so it will be interesting to see how BPMM informs process management software down the road.

Business Process Definition Metamodel: Also formally approved is the BPDM specification. BPDM has been subject to a lot of hyperventilating so here's a bit of history that, hopefully, puts BPDM in its place, and also lets you know the business value of it, and what you should worry about:

1) As good as it is, the BPMN specification as delivered by BPMI.org (of which Lombardi was a member) was an incomplete spec in that it never defined a way to serialize it (a hifalutin way to say "save it to disk"). It left that up to each vendor who implemented it. Bad idea.

2) BPMI.org merged with OMG about 18 months ago, and a large part of the reason [most of us] chose to merge with OMG was its understanding of model-driven architecture. Specifically, many of the BPMI.org members wanted a standards-based, MOF-based metamodel for BPMN (MOF: a standards-based way to represent model definitions, and a standards-based way to deal with all the things you care about when you save a model definition, like versioning, schema, transformations, etc.)

3) BPMN is assumed by OMG, even though it violates their "rule" that technical specifications have an explicit MOF-based metamodel. BPMI.org members (like Lombardi and BPM Focus) who are interested join existing OMG companies who are already working on a "business process definition metamodel" task force to define the explicit metamodel for business processes generically. The desire to use BPDM as an explicit serialization for BPMN is added to the group's charter.

4) Last week, BPDM is adopted. So now, BPMN has an OMG-adopted standards-based metamodel. In addition to defining the serialization of BPMN in a platform-independent and computationally-independent way, BPDM also adds process notions (such as choreography) that BPMN does not currently support.

5) In June 2007, OMG will be issuing the BPMN 2.0 RFP (essentially the guidelines for a future BPMN 2.0 specification). This will say "merge BPDM and BPMN into one specification." In fact, if and when adopted (probably March '08) BPMN will stand for "Business Process Model and Notation."

6) BPMN and BPDM are technical specifications. They are meant for vendors who are serious about providing robust process solutions that span an enterprise's entire sphere of business processes, which means that they are cross-platform, cross-execution, cross-legacy-system, cross-functional, global environments. BPDM isn't meant to simply "store BPMN into XML." It isn't meant to store only those processes a single engine can execute. It is meant to support many "notations" or views. It's not a specification that you should need to read, any more than you should need to read Microsoft Word's file format specification... but it is able to be understood by many vendors, and across many platforms. There has been some criticism that BPDM is "hard." Well, yeah. For the vendors. But when used, the business benefit is that many tools (provided by vendors who do the hard work) will be able to easily share information. You see, the issue is not whether a specification is "hard" or "easy," but whether the functionality it enables is hard to use or easy to use. And of course, vendors compete in this space. Companies adopting BPDM, like Lombardi and MEGA and others, have an incentive to make interoperability drop-dead easy. We'll do this with BPDM.

7) Why should you care about BPDM then? The only reason to care about any specification is if it drives business value for you. So BPMN & BPDM are important only if you expect to make process improvement an ongoing, enterprise capability. If you're using a BPMS as a point solution for a specific app-dev initiative, they are less valuable (as with any standard, it is when you try to scale across the enterprise that they pay off). As I've explained, BPMN and BPDM will be merging. And, primarily, the changes in the 2.0 iteration will be to BPMN, not BPDM. BPMN will be extended to support the new notions of BPDM, and elements of BPMN will be changed to conform to BPDM. So vendors jumping on the BPDM bandwagon now will have a 1-year head start on the next version of BPMN, which is the primary notation for implementable business processes. So, what's the business value of BPDM? The fact that it represents the next version of BPMN, which is becoming the language for business processes. Vendors who are all about supporting BPMN on top of their process languages (whether those are BPEL, XPDL or proprietary) will be triangulating off of BPDM... the only question is when, and how.

8) BPDM is a huge advance for the industry. Model portability across vendors is pretty important, and this achieves that in a way that is tool-independent (i.e. also notation-independent). The ability for everyone to draw similar pictures using BPMN, and save them using the same file format across tools will expand access to many new users; but the ability to have tools that represent the identical process without diagramming the identical process will move process excellence even further. Concepts like business milestones, as opposed to BPMN activities, for example. In retrospect I wish OMG had simply developed this inside the BPMN spec to begin with... but this does not diminish the value of having this specification approved. We'll correct that mistake over the next year. Until then, let's make sure every one of us vendors moves to this spec... then the move to BPMN 2.0 will be trivial!

9) BPDM was approved by 20 or 30+ organizations at the meeting. The primary contributors to the specification were:

• Adaptive
• Axway Software
• Borland Software
• Model Driven Solutions
• EDS
• Lombardi Software
• MEGA International
• Unisys
• BPM Focus
• U.S. National Institute of Standards and Technology (NIST)

It was a good week for end users, because the notions of business value and, in BPMM, business-facing standardization of process excellence techniques and technologies were advanced.

Technorati Tags: BPDM, BPMN, OMG

April 5, 2007 at 07:26 PM | Permalink | Comments (4) | TrackBack (1)

Transparency and Open-sourcing of Process

In two terrific blog posts, CIO of the services arm of British Telecom JP Rangaswami blogs about visibility and openness as the heart of process excellence. He talks about documenting the reality of your company - and of your customers' interactions with it - and leaving behind the failed "process" approach of ERP, CRM, SCM (and I'd add EAI, so-called "integration-centric BPM" to the list).

Bravo, JP!

Where you didn't go in the posts, but I suspect have in your head, is whether we should open-source process frameworks and KPIs for companies. While the dirty details of implementation (at, say, the BPMN level and below) are not something most companies would want to share (not because of of competitive advantage but because of competitive disadvantage, disclosing weaknesses in process that could be competitively exploited), I think that higher level process and strategy maps would be valuable to standardize: a tangible Zachman for your industry for example, along with the specific metrics and KPIs that you are expected to achieve. Wall Street is almost certainly already judging you on these (the higher level ones anyway, which have implicit, just not explicit ties to the lower-level ones). Why not just agree on them? In the same way that every company is currently reinventing the wheel with respect to non-differentiating technology (how many redundant WebSphere administrators are there in the world?), companies are also wasting their collective time on drawing the same high level process maps and agreeing the KPIs that are linked to them.

Excellent companies in _any_ industry are process-excellent. The KPIs of these processes are almost always known (most truly excellent companies share them, even with competitors, for they are not "insecure," another aspect of JP's posts I am glad he discusses). Toyota is famous for sharing its methods and results with competitors, for example. These companies compete on their ability to innovate and improve, not on some static state of today's process (of course, certain technical processes, like painting methods, are secret).

Visibility, transparency and a willingness to change (I call this culture) are the key elements of BPM, not execution and workflow. Those are simply two of the many artifacts of where you are at any given point in time on the Process-Driven journey. Great BPM technology should encourage the visibility, transparency and cultural change parts of your journey to become process-excellent... we've already got enough technology that simply encourage how to build workflows.

So read JP's posts (here and here). And for a similar set of thoughts, as well as the beginnings of how to go about achieving this process excellence, click on the picture of my forthcoming book, Process Driven, and you can get a copy of Chapter One, where I discuss shining a light on your company, and the four pillars of BPM.

ps = And for those of us north of the equator, happy first day of spring, when the sun shines its light for longer periods of time on the state of our lawns and gardens. Driven by guilt or desire, we improve them constantly. Then winter's rest, and then they reappear, a little better, the next year. We're in our sixth year at our current place, and each year the garden is in better shape. Maybe it can be springtime at your company, too; it just requires a little sunlight and a willingness to improve.

Technorati Tags: Visibility

March 21, 2007 at 06:14 AM | Permalink | Comments (0) | TrackBack (0)

SaaS, Modeling-lite, Process Execution, Enterprise 2.0 and Other Words That Google Will Rank Highly

Nathaniel Palmer wrote a review of Lombardi's Blueprint that I thought was interesting. So after my conversation on "Enterprise 2.0" with Sandy Kemsley a couple of days ago I thought I'd go back to that.

You see, I agree with Nathaniel's assessment that platform-level BPM-SaaS   (or any other integration-intensive platform) is a non-starter (for the relevant future, anyway).  Like any new technology (for purposes of this discussion, let's assume "SaaS" is new and that it's a technology, both of which are bad assumptions but that's another discussion) it will be mis-used by existing players and only new ideas will bring out its primary benefits.  Remember the move by the mainline DOS players to Windows?  They all died because they viewed this new thing as just a re-swizzling of their old thing... when in fact a new design approach was required.

So if you want to look at the BPM market I think there are 3 or 4 "buckets" that a process platform addresses.

- Modeling
- Execution
- Monitoring
- Reporting

I suspect we could quibble at the edges but generally that's what there is to this thing.  Each of us vendors make implementation choices that we can debate, but the functional buckets are pretty much those four. Let's take a look at what's required for each of those, and where new technology or services could make a difference:

Modeling doesn't require integration and it benefits from collaboration.  Now, there are advanced use cases where integration into and introspection of existing systems will help build scenarios for simulation, but in general, the bulk of the work done in the front-end of the modeling life-cycle looks like an OK fit for something delivered over the web. SaaS is not simply about a scalable way to deliver functionality, it facilitates collaboration if you tap into that part of it. The web allows people to get together to do their human-based work. If the tool you are providing also is easier than competing alternatives, structures data and puts in an accessible place and can hand it to you in a standardized format, then SaaS gives you a very scalable way to deliver this capability. That's where salesforce.com excels: doing something that was already being done but in a better way. In addition to that, if there are new concepts in this tool, then even better. At Lombardi, we think Blueprint is both easier to use than modeling alternatives (like salesforce.com) but also we think there are some new ideas (like integration with our behind-the-firewall BPMS). Easy access at the beginning, and tightly-coupled standards-based round-tripping when you move to execution.

Execution is different.  The aspect of BPM process execution that I find most interesting is the execution that is done to make existing alternatives more flexible.  BPM isn't a rip-and-replace thing where you should be building a new application. In fact, a BPM system should host as little system-of-record data as possible (other than the intrinsic SOR data that execution and monitoring spins off, process analytical data about the process performance... which I think is the most interesting aspect of BPMS-based execution!) If you aren't integrating to legacy systems, then all you're really doing is building a workflow application. Been there, done that, more silos, more support headaches for IT. That's not the process problem for the Global 3000. These companies have significant dollars invested in their systems and now those systems are holding them back.  They can't dump them, their whole business depends on them.   At the same time, these big systems just can't be changed fast enough.   SOA alone isn't the answer, because the problem is not that the system-to-system transactions aren't working... it's the patchwork quilt of systems and humans that want to work together in new ways that aren't able to move fast enough. So service-enabling legacy systems as a part of a larger SOA is a Good Thing, but it's a Good Thing so that you can consume them in the new human-facing processes unified across the new business initiatives. BPM (and SOA) is a part of that.  A BPM layer can be inserted and extended... it is more flexible for new things, and it masks the old thing while making the whole process seamless across the multiple systems.  Well, anyway, the point of all this is that integration of the process platform into your business BPM is heavy, heavy lifting.   If it's not heavy lifting (the low hanging fruit of unintegrated workflows) then all you have is a portal, a form and a workflow engine... you're not doing BPM. Unintegrated workflow applications using SaaS? Sure. Core-process BPM execution? Nope, not well suited to SaaS. (Of course, you could see a path from modeling to unintegrated prototype - one that "executed" - and then a transfer into a behind-the-firewall platform, but to me that's just modeling, so I'd put that up above...)

Monitoring.  This part of BPM gets very interesting and sometimes not well understood.  Not only should BPM offer up technologies that are agile, but BPM is the conduit through which we make business decisioning more agile.  In fact, my experience (from many years pre- and post-BPM) is that being able to make informed business decisions is the longest pole in the tent of agility.  And having good information is getting more difficult because of the morass of systems and silos (Ex-hell, as a customer calls one popular spreadsheet silo...).  So monitoring complements execution and is equally important to execution for almost any process of consequence.   You probably won't execute all of a core business process, but you will have to monitor key parts of it to provide the process-oriented "perspective" to management so they can know when, where, what, who and why of improvement.  The reason is simple: any core process will already have some systems in place to support it. They may not be great (hence the need for BPM) but they will exist, resulting in more integrations, therefore not a candidate for SaaS (again, in the relevant future).

Reporting.    The results of execution and monitoring need to be visualized.  I think interesting Saas-based work may be done here around real-time collaboration and real-time data visualization.  This is an area where a lot of vendors will be tempted to simply put their BI tools into SaaS.    That won't do much in the market.  But there is opportunity here, I think, to use the SaaS platform for something very interesting... the integrations required for reporting databases are so standardized these days - and the performance of modern data warehouses is so good - that some of the technical hurdles that we talk about in the execution and monitoring sections, above, don't exist (although the political hurdles of data access still do).  I am watching this space for interesting developments, though... things like what businesses (like IBM) are doing in Second Life fall into this category, for me. In addition, I certainly would consider a future where a product like, say, Blueprint, might want to visualize the execution artifacts of a product like TeamWorks. Now wouldn't that be Enterprise 2.0'ish!

Well, those are my thoughts on when and where SaaS innovations may play a role in BPM in the next couple of years, and also on how Enterprise 2.0 (so-called) might transpire. Enterprise 2.0 is, to me, about the merging of the public and private delivery platforms accessible by a person in their worklife. By merging these platforms and leveraging each one to its fullest, we can do a better job of delivering the right stuff to the right person at the right time at the right cost. Enterprise 2.0 isn't Web 2.0 because the relative importance of "me" is reduced. As someone pointed out in Sandy's conference the other day, "this isn't communism, we have to think about corporate profit." And as I pointed out, it's also not about anarchy. It's about looking across the landscape of the enterprise and using every technical asset at our disposal, and leveraging it to the fullest. Where BPM comes into play is that it directs the order in which you create this leverage. It is the basis for understanding your business. If you marry these two ideas, BPM directing the Enterprise 2.0 leverage, then you'll be more quickly on your way to closing the gap between your PE multiple and Google's!

Technorati Tags: Enterprise 2.0, IBM, Sandy Kemsley, Nathaniel Palmer

March 8, 2007 at 10:52 AM | Permalink | Comments (0)

What A Tangled Web (2.0)

I just got off an eBizQ panel discussion hosted by Sandy Kemsley. What a ball.. no slides, just good, topical conversation. Speaking of the conversation....

The panel also consisted of Phil Larson of Appian, Ismael Ghalimi of Intalio. The topic was "BPM and Enterprise 2.0" and we discussed, among other things, what the technologies of (so-called) Web 2.0 meant to the enterprise. A lot of people are looking for a fundamental shift in the BPM world, but I don't think they get it at all. Of course these technologies will make a difference in enterprise applications and mission critical processes, but I don't think that's their initial highest and best use.

Process execution (aka workflow) is not the interesting part of BPM and therefore, process execution from "Web 2.0-like" tools isn't the most interesting use of these new capabilities. Not to get all Cluetrain on you, but the main thing these new technologies give us is a new way to communicate, not a new way to integrate!

Behind-the-firewall BPM is about giving visibility into your core processes, and giving you a more flexible way to implement improvements to those processes. Visibility and improvement are non-trivial things. They require thoughtful implementations (not "zero-code" implementations) and they require top-down guidance. If you don't have leadership at the very top of the tree behind you, then you just aren't doing BPM. But how do you structure that top-down view? How do those leaders tie process to high level goals - the goals that if you hit them you'll still be in business and thriving in five years' time? How do you quickly decompose those processes that make strategic impact and determine which ones have the highest impact? And, finally, how do you know when to hand off those decomposed process "chunks" into a robust behind-the-firewall BPMS that offers a shared model with the higher level views as well as the hard core capabilities of an enterprise class platform?

What I've found over and over is that there's no good way to have the top-down conversation! And it turns out that this is exactly what the new SaaS technologies allow!

So my answer to the "what is Enterprise 2.0 and how does it tie to BPM" question? Here you go:

The key stumbling block to real BPM has been the inability to have a structured, high-bandwidth conversation from the top-down about what the goals of the company are and the related processes that impact those goals. Enterprise 2.0 enables that conversation with new tooling that combines the best of social software with a shared process model accessible to and from the behind-the-firewall implementation BPMS.

Enterprise 2.0 is here, but it's not a regurgitation of the old execution-centered (workflow-centered) BPMS's of the past. It's an extension of the process execution and control systems into new areas of the enterprise, enabling new conversations, that dramatically alter the process life-cycle within a company. And then it's the tight coupling of the internet-based capabilities with the behind-the-firewall capabilities so that a new, more flexible breed of enterprise systems evolve.

Agility comes from being able to respond to strategic changes quickly, not the ability to change a random workflow. Enterprise 2.0 enables this - but not by recycling concepts of execution and web services. We're entering a new era, we're not going back to the '80's... this isn't client-server, and it's not just another set of Excel or Access craziness. It's about empowering the individual but in directed ways that (a) contribute to the company's success and (b) utilize scarce resources to their fullest.

Technorati Tags: 21st Century Process, BPM 2.0, Enterprise 2.0, Web 2.0

March 6, 2007 at 01:45 PM | Permalink | Comments (6) | TrackBack (0)

Recent Posts

Cloud

Archives

Categories

Blogroll

Etc.