Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
richard_hirsch
Active Contributor
0 Kudos

Note: This blog is the third in a series of blogs about ‘Social BPM.  The Social BPM: Definitions and Dissensions looked at the current Internet buzz about the topic and provided a set of initial descriptions. The Social BPM: A Taxonomy + The Playing Field provided a taxonomy of the topic and a description of current offerings in the marketplace.

Intention

In my last blog in this series, we used a broad description of BPM Communities. 

"Then you have the BPM ‘Community' at large. These communities could network on BPM standards, best practices, methodologies and templates. There are several ad-hoc discussion and research communities on BPM, as well as BPM bloggers. The greater value is achieved when the community is focused on a particular vertical domain...."

I'd like to further define community for the purposes of this blog as a collaboration in which the benefits of the collaboration are intended for a wider audience than those directly involved (or the commercial entities that they represent) in the collaboration itself.   I'm calling this sort of collaboration - "community-focused collaboration".

The motivation of those collaborating in this context is more altruistic.  This intention is also evident in Koshafian's definition which concretely mentions specific artifact types ("BPM standards, best practices, methodologies and templates") that may be used by a wider audience.

Let me provide a few examples to clarify this distinction.

  • The first collaborative example involves teams from two companies which are attempting to improve the supply chain process that involves both firms. Their collaboration may take place in a BPM community such as AlignSpace. The resulting process could be describe as "private" in that the ensuing benefits are only shared by those companies involved and no one else.
  • The second collaborative example involves a number of teams who are working together to create a new BPM-related methodology / standard that will be available to the public after it has been completed.

In this blog, we are focusing our attention on the second type of collaboration.

Types of Community-Focused Collaboration

Before we start the discussion on community-focused BPM, I'd like to differentiate between two types of collaboration in this arena:

  • Intra-community collaboration: This type of collaboration takes place within a community.
  • Inter-community collaboration: This type of collaboration takes place between different communities

This blog will focus on the first category but will include a short discussion of the second category as well.

Intra-community Collaboration

Obviously, individuals collaborate to achieve certain goals. In community-focused collaboration, the motivation is usually more altruistic in character. Or is it?

Why would anyone participate in such groups? One AlignSpace blog even has the provocative title "Should you give away your BPM secrets?" In this competitive world, companies must see a benefit from this type of collaboration; otherwise they wouldn't participate in such efforts.  What are some of the possible motivations for such collaborative behavior? Let's take a look at a few examples:  

Standardization

There is naturally an interest in standardization in many IT-relevant areas (XML formats, other interfaces, etc.).  The work of OASIS (a not-for-profit consortium that drives the development, convergence and adoption of open standards for the global information society) is one example of the importance of such efforts.  Standardization in processes is no exception. This is especially true for certain sectors of the corporate world.

Furthermore, the [Small and Medium-sized Businesses] stand to benefit from business process collaboration and standardization since it is NOT their key value-add. [Source]

Sowing the BPM fields

Imagine an enterprise initiating a Process Excellence program. Some of their processes may be documented but many or most are not.  Wouldn't it be great if you didn't have to start from scratch? If you have a pool of BPM models which you can use as a foundation on which to start your own models, you are much more willing to start efforts in this direction. This "slippery slope" is one of the reasons that IBM has filled their BlueWorks environment with so many processes with which users can jump-start their BPM efforts.  Of course, others active in such environments- such as partners, consultants, etc - can use such public arenas to demonstrate their process-related skills as well.

Diversification

By including individuals from various companies in such endeavors, the domain-relevant knowledge of those collaborating will - hopefully- complement one another to create a more solid foundation on which to build the process.  Such diversification should lead to increased design speed - as compared to other types of collaboration - due to the ability to perform tasks in parallel; of course, the increased effort needed to coordinate such activities shouldn't be forgotten but will, with any luck, be minimal.

The problems associated with community-focused process design

This type of "public" collaboration, however, also has certain difficulties associated with it.  In a series of blogs in the AlignSpace community, there were very interesting discussions about this problem.

Is there a motivation for customers to share business processes? Large enterprise customers run a lot of individual business processes and legacy applications. Some of them are considered as intellectual property and competitive differentiator. They never share any of those on a social process community.

..... The customer's challenge will be to sort out carefully their core differentiating and secret processes from the commodity stuff that can be shared without losing any value.

Thus, those engaging in such collaborative efforts must be aware of these shortcomings and collaborate selectively.  

SAP's Enterprise Services Community: An example of successful community-focused collaboration

Based on the motivations just described and the difficulties associated with such collaboration, it is in no way self evident that efforts in this area will take place - let alone be successful. It is useful to examine similar efforts in related fields to gain insights into what makes such endeavors successful.

One such similar endeavor is SAP's Enterprise Services Community (ESC).  The following discussion examines this community in detail and then applies the lessons learned from this environment to the Social BPM arena.

Last year, approx. 50% of web services developed by SAP in its enhancement packages were defined by customers and partners. This achievement was based largely on the definition of Enterprise Services via the Enterprise Services Community.

Here is a graphical overview of the ESC process that is the foundation of this community.

Source

Let's take a closer look at this program.

Known as community definition groups (CDGs), [such groups] are part of the Enterprise Services Community program. A CDG is a technical forum in which SAP customers and partners collaborate with SAP to define enterprise services and business processes.

Note: Although it is mentioned that the CDG's should define processes as well, I've never seen a BPM model that has emerged from such a group.

Aided by feedback from the CDGs, SAP solution management teams develop enterprise services and then packaged them as enterprise services bundles. The documentation for these bundles are located in dedicated wikis "that encompass the collective know-how surrounding the services and use cases."

There are currently a variety of CDGs that exist. This definition process takes place in the Collaboration Workspace which is SAP's new collaboration workspace and the changing nature of social networks where users are bound by certain legal restrictions (contracts, etc.) to assure that intellectual property related issues are considered and taken into account.  

What do participants gain in this collaboration?

From a customer's perspective, the advantage of this process is lower integration costs:

"Even though our working group did not reach consensus on everything, most participants found they could use the services we defined," [Johan] Smessaert adds. "With its strong experience in standardizing solution development, SAP can use these services definitions to reduce customer integration costs. SAP can also take an active role to promote ecosystem collaboration on a common services layer for the banking industry. A well described services layer that's independent from the underlying implementation will help banks and solution vendors deliver business functions with minimal interface costs."

For vendors, there are advantages as well:

Few software vendors working by themselves have the ability - or the business rationale - to define an entire industry-specific services landscape and create strong industry momentum to drive broad adoption of that landscape. Through participation in ES Community, software vendors can offer compelling and differentiating banking solutions based on these common enterprise services definitions. [SOURCE]

Thus, all those involved in the ESC benefit from this type of collaboration.

Applying the ESC-related lessons to Social BPM

What is necessary to have an equally successful collaborative environment for processes?

1.      A process framework for collaboration

The presence of a well-defined process that covers all aspects of this collaboration is a critical factor for the success of the ESC in that it provides those involved with a secure and stable environment in which to innovate.

In attempting to duplicate this sort of collaboration for processes, a similar construct would be necessary.

Of course, community-focused collaboration for processes can and does take place in environments without such complicated policies and legally-binding constraints.  However, such efforts may not receive the level of participation from corporations who are concerned with possible competitive disadvantages based on IP-loss.

Note: Just because such collaboration is bounded by a strict structure doesn't mean that that its results can't be publically available. 

2.      A collaborative environment

The Collaboration Workspace (CW) is the current environment in which the ESC collaboration takes place. Could this same environment by used for process collaboration?

If you look at the current functionality offered by CW in its present form and compare it to the process-related functionality present in the some of the Social BPM: A Taxonomy + The Playing Field, it is clearly not a Social-BPM site.  There are a variety of things that are missing - the most obvious being process design capability. 

Through my participation in BPX Process Slam, I'm also involved in the Gravity – Collaborative Business Process Modelling within Google Wave which is a GoogleWave-based process design / collaboration tool from SAP Research.

I had an exciting thought - what about bringing the two worlds together to provide CW with Social BPM functionality.

At this point in this blog, I would love to show a screenshot of Gravity embedded in a CW document (wiki) but my attempts at integration didn't work. How did I attempt to bring the two environments together? I used the Embedy robot  to get the embed code of a Wave with an embedded Gravity gadget and then tried to add this code to a wiki document. It turns out that Jive (the product on which CW is based) has restrictions on embedding scripts - to avoid XSS attacks- in the wiki. Ideally, either JIVE or some partner will build an extension for the wiki to be able to add Waves.

3.      Mixture of private and public collaboration

The collaboration in ESC itself is restricted to a certain group of individuals; however, the results - in the form of Enterprise Services - are made available to those who didn't immediately participate in the collaboration. This mixture of private and public aspects is also important to deal with IP-related issues.  A similar construct would be most effective in process related activities as well

4.      Focus on process design

There are a variety of process-related artifacts (design, business rules, UI designs, selection of Enterprise Services, etc) that can be created during a collaboration. In order for community-focused Social BPM to be successful, I'd suggest focusing on the process design itself - the creation of BPMN process models. Once you start moving into other area (UI, etc), you quickly move away from the pure process focus and start designing SAP starts Beta Test for New Simple Sample Applications Featuring SAP NetWeaver BPM Technology. This loss of process focus which could detrimentally impact the vendor-neutrality (assuming that it is a goal) as will as increase the complexity of the collaboration.

5.      Interest amongst the community to collaborate

Of course, the desire to create processes in such a collaborative environment must exist. The benefits of using such an environment should be promoted by the vendors of BPM technology as well as the community itself.

6.      Other issues that must considered

When attempting to use the ESC experience as a basis for community-focused BPM, it is critical to remember that processes have different characteristics than Enterprise Services.

For example, Enterprise Services involve the development of actual code.  In the CDG-based model, the definition of the enterprise service creates an agreement on interfaces that are then developed by SAP and released as part of bundles in enhancement packs. Process design, on the other hand, is primarily models and thus more easily transferable. There is little if any code development associated with the design model - although their use often requires configuration of roles, back-end systems, etc. 

What are the resulting effects of such differences?

  • The rate at which the process-related collaborative results might be made publicly available should be faster than that associated with Enterprise Services. Instead of waiting for an enhancement pack to be realized, the process could be made available immediately. 
  • The role of the involved technology vendor is different. Currently, SAP is involved in every CDG based on the fact that it must later develop the ESs that have been defined. In the realm of community-focused BPM, an involvement of SAP is no longer mandatory - although its participation is probably welcome. The vendor may be present in such collaborative efforts - perhaps, giving the process a stamp of approval- but it is not necessary.  The question might be, however, if a vendor wasn't involved, would such collaborative efforts have the same level of influence in the eyes of the customers, etc. I think one reason for the success of the ESC is that the services that are created have SAP's stamp of approval.
  • Certification efforts must be reconsidered. Could the resulting process model be certified by a vendor - for example, meeting its high quality standards?  Or would a particular implementation of the process model receive this certification.

Inter-community Process Collaboration

Note: In this section, the definition of community has been broadened to include all types of communities not just those that are community-focused.

This type of collaboration would take place between different communities and would focus on the movement of processes between environments in order to achieve certain goals.  If a company is just interested in using a standardized process, then there is no need to move a process design to another environment. If, however, changes are desired then a different collaborative environment with different characteristics (technology, users involved, etc.) might be more advantageous.

In the picture above, a process is being transferred between different communities - each of which has a different focus.

  1. The process is developed as a standard process describing a sub process in the supply chain. The related discussion and creation takes place in a fully open environment where all changes / discussions are public. Such a community is usually vendor-neutral.
  2. This standardized process is then taken to a private area of another community where partners who are directly involved in process - as manifested in a particular company - add the details that depict their competitive advantage. For example, the regional laws that affect this process might be considered in this area.  Or this community may be vendor-specific and would add UIs, Enterprise Services, etc.
  3. This customized process is then taken to an internal community where other participants (developers, business analysts, etc.) discuss more technical-oriented issues (which services to use, etc.)

Of course, there are few issues / assumptions in such scenarios that must be examined in more detail:

  • Who is responsible for support or updates? If the original process is changed (for example to deal with changes in external conditions), how will the related processes in other communities be affected?
  • The assumption is that the export of processes - not only the process-related data but how this information is graphically represented - occurs without data loss. See Bruce Silver's blog for a discussion of the difficulties of this issue.    

Conclusion

The enterprise requires structure and stability - thus, there is often a focus on standards in ERP, XML, etc. However, the demand for innovation often conflicts with this desire for standardization. Web 2.0 technology often must deal with this schizophrenia. For example, how can you use a wiki page - that by definition is a living thing that constantly evolves over time - as a deliverable for a project milestone that is due on a particular date? Use a link to a particular version of the wiki page? 

Community-focused BPM is also impacted by this dilemma.  The use of BPM is seen as one of the main areas in which enterprise innovation is possible.  Yet, the use of process standards is one critical tool to reduce costs by reducing complexity.  Which BPM-related desire should take precedence? What I suggest is that enterprises selectively choose which processes should be based on a standard - irregardless of whether this process originates from a community-focused BPM environment or a vendor- and which processes should be customized to provide competitive differentiation.  Indeed, such customized processes may originally be standard processes that have been "pimped" to take advantage of the particular corporate strengths.

Community-focused BPM has great potential to meet both demands (standardization vs. innovation) but the appropriate environment (technical, procedural, legal, etc.) must be present and accepted by all those involved in order for this potential to be achieved.   I think the existing technical and procedural environment used by the ESC could provide an excellent foundation for a similar collaborative arena for processes - the next task is to alter these existing structures to accommodate the unique characteristics associated with Social BPM and processes in general.

Labels in this area