forrester_sharepoint and bpm %e2%80%94 finding the sweet spot_derek miers[1]

Making Leaders Successful Every Day

March 31, 2010

SharePoint And BPM Finding The Sweet Spot by Derek Miersfor Business Process & Applications Professionals

2010, Forrester Research, Inc. All rights reserved. Unauthorized reproduction is strictly prohibited. Information is based on best available resources. Opinions reflect judgment at the time and are subject to change. Forrester, Technographics, Forrester Wave, RoleView, TechRadar, and Total Economic Impact are trademarks of Forrester Research, Inc. All other trademarks are the property of their respective companies. To purchase reprints of this document, please email [email protected]. For additional information, go to www.forrester.com.

For Business Process & Applications Professionals

ExEcuTivE SuMMAryDespite Microsofts best attempts to position the SharePoint platform for content and collaboration, many people still see it as a business process management (BPM) platform. The process management features of SharePoint 2010 are better than MOSS 2007, but theyre more limited than most modern BPM suites. Why? SharePoint 2010 processes are constrained by Windows Workflow Foundation (WF). When developers build process-oriented applications that leverage WF, they often find themselves hard-coding static, brittle interfaces that add to the total cost of ownership (TCO). To use SharePoint 2010 as part of an enterprisewide BPM strategy, customers must add a comprehensive, SharePoint-oriented business process management suite (BPMS), which will raise vendor license costs, but lower overall TCO and risk. Vendors to consider include AgilePoint (was Ascentn), Global 360, K2, Metastorm, and Nintex.

TABlE oF conTEnTSNative SharePoint Is Good For Office Workflows But Not Enterprise BPM

SharePoint Has Strong Tools For office Workflows

SharePoint limitations For Enterprise BPM Solutions

But SharePoints Features For BPM Are limited

Two Key Requirements Should Guide Your Use Of SharePoint For Process Apps

SharePoint is Best For Procedures

SharePoint is not ideal For Process Adaptability

Microsoft Partners Fill The Gap

rEcoMMEnDATionS

SharePoint Users Should Develop A Specific BPM Strategy

noTES & rESourcESThis research stems from ongoing discussions with business process professionals and Microsoft.

Related Research DocumentsSharePoint 2010 unites collaboration With Processes But Significant BPM Gaps remain January 13, 2010

Governing SharePoint in The Enterprise January 9, 2009

identifying When To SharePoint, or not, For Business content needs January 9, 2009

SharePoint Success Will Take a village June 24, 2008

March 31, 2010

SharePoint And BPM Finding The Sweet Spot by Derek Mierswith connie Moore, John r. rymer, charles coit, Sander rose, and David DSilva

2

5

9

2010, Forrester research, inc. reproduction ProhibitedMarch 31, 2010

SharePoint And BPM Finding The Sweet Spot For Business Process & Applications Professionals

2

NATIVE ShAREPOINT IS GOOD FOR OFFICE WORKFLOWS BUT NOT ENTERPRISE BPM

CIOs and business people alike recognize SharePoints ability to enable effective collaboration among employees as they respond to the varying demands of customers and the market. Business users and IT clearly see the need to ensure that documents and data are managed effectively. SharePoints strengths as a collaboration environment have made it one of Microsofts shining stars, with 2008 sales of $1.3 billion, growing at about 25% per annum.1

Even though Microsoft has been careful not to market SharePoint as a BPM suite, users are often surprised by the costs of custom development if they start building process-oriented applications. The reason: While SharePoint makes simple workflows easy to create, on its own it is not suitable for business process applications. A rich BPM experience is available using the SharePoint platform, but this will require the use of partner products to achieve optimum results.

SharePoint has Strong Tools For Office Workflows

SharePoint provides built-in workflows for simple tasks like approvals, as well as development tools for other types of processes. With SharePoint 2010, Microsoft has made great improvements to ease process development, including:

SharePoint Designer. SharePoint Designer 2010 makes it easier for business people to build simple office workflows. Moreover, unlike prior versions of SharePoint Designer, administrators can shut down SharePoint Designer 2010 at the server level, switching off specific features for certain users, or impose other resource constraints.2

Direct import of Visio 2010 process models. With the advent of Microsoft Visio 2010, end users can now define processes in Visio and drop them straight into SharePoint Designer 2010 to create a working process.3

Integrated Visual Studio customization and development. Where SharePoint out-of-the-box functionality does not meet the need, developers can always use Visual Studio to develop custom templates, WebPart event handlers, and other custom components and apps.4 SharePoint 2010 introduces a feature called Business Connectivity Services (BCS), which acts as integration layer, managing the interfaces to external applications such as SAP or other legacy systems.5 BCS structures then link into the metadata available in individual site collections. SharePoint 2010 also has both client and server APIs that developers can leverage.

SharePoint Limitations for Enterprise BPM Solutions

Many customers mistake SharePoints workflow ease of use for enterprise BPM support.6 In Forresters Enterprise And SMB Software Survey, North America And Europe, Q4 2009, Microsoft came in top with 47%, outstripping all others (see Figure 1). But despite the best efforts of the SharePoint product management team to position SharePoint as most suitable for simple office

2010, Forrester research, inc. reproduction Prohibited March 31, 2010


3

procedures, we believe that the majority of people in the business world still see Microsoft SharePoint as delivering a BPM platform. While the survey question was not specifically targeting SharePoint, the responses probably include a significant number of Microsoft Visio modeling tool users; it does indicate the dominant mindshare that Microsoft has somehow established in the BPM space.

Figure 1 Microsoft is Top Among iT Decision-Makers For use For BPM

Source: Forrester Research, Inc. 56662

Which vendors do you currently use for business process management software?(Select all that apply)

Microsoft

Oracle

Custom-developed(in-house or third party)

SAP

IBM/WebSphere

Other

Sun Microsystems

IBM/FileNet

EMC

Sterling Commerce

TIBCO

Fujitsu

Appian

Savvion

Ultimus

MetaStorm

SoftwareAG

PegaSystems

Lombardi

Vitria

Dont know

47%

36%

32%

22%

18%

15%

11%

11%

9%

5%

5%

3%

3%

2%

2%

2%

2%

2%

1%

1%

1%

Base: 218 IT software decision-makers whose organizations haveimplemented business process management software

Source: Enterprise And SMB Software Survey, North America And Europe, Q4 2009



4

But SharePoints Features For BPM Are Limited

The assumption that SharePoint is suitable as a general purpose BPM suite is flawed. Microsoft itself recommends against use of SharePoint for enterprise BPM solutions (without the addition of a suitable partner product). This is why:

SharePoint processes are best for simple tracking applications. Office workers can easily initiate new cases of work from a library of predeveloped components in an ad hoc fashion. Unlike BPM solutions, SharePoint workflows seldom take the user from input screen to input screen the SharePoint platform becomes a tracking application for knowledge workers where the user reports task completion, attaches documents, etc. In contrast, a BPMS normally uses a combination of process model and business rules to actively route tasks to the most appropriate user in the next role, supporting her interaction with back-end systems of record, capturing information and knowledge, etc.7

Enterprise BPM in SharePoint will require lots of custom code. Using SharePoint to build enterprise-scale process applications is a slippery slope into custom coding, leading to total cost of ownership (TCO) disappointments.8 Developing simple processes in SharePoint Designer is easy enough, but without writing code, it is virtually impossible to synchronize parallel threads of processing, support multi-outcome activities, multiple threads of execution, etc. Even simple rollback (undo) and approvals that involve passing the work back to a previous step are challenging.9 And sophisticated exception handling or business rules capability also requires coding. These sorts of developments create challenges when modifying applications, deploying applications to multiple SharePoint site collections, or upgrading the SharePoint platform. Reliance on coding eliminates the flexibility that BPMSes provide, since custom code is much harder to update than metadata.10

The processes targeted by SharePoint are simplistic; enterprise processes are not. Mission-critical enterprise processes usually consist of a set of operational processes interacting in support of the business goal. For example, a compliance process may invoke a formal reporting process if the employees responses are exceptional. In SharePoint 2010, there is no way to define these separate processes and have one automatically invoke the other and pass it the context of the original process instance. Developers can overcome this limitation by writing interfaces between WF processes, but this leads to static, brittle process interfaces that are difficult to change. As a result, developers end up building overly complex processes, all conflated together into a single structure rather than architected as distinct process components that collaborate in support of the business objective. The addition of a modern BPMS to SharePoint usually overcomes these limitations.

Site collections make it difficult for processes to cross organizational boundaries. SharePoints reliance on site collections is both a strength and a weakness for business



5

process management. Strength: A SharePoint site collection acts as a container for metadata to which processes relate. Weakness: Site collections constrain processes that must cross boundaries.11 In MOSS 2007, WF-based processes were limited to the boundaries of the SharePoint site collection. With SharePoint 2010, workflows can span site collections but cant magically eliminate differences between metadata structures in these site collections. Thus, administrators need to take care when designing the site collection structures as processes often cross organizational boundaries or involve partners or customers.

For example, a compliance process within a financial services firm would need to cross all departments (both local and remote), potentially spanning site collections. To get around this, developers often build custom/proprietary code, making applications brittle and presenting new challenges on platform upgrades.

Governance is critical for cross-functional processes. While SharePoints ease of use and accessibility enable business people to set up their own sites, unchecked site proliferation throughout the enterprise can create real headaches.12 With enterprise licenses becoming the norm for large organizations, so-called SharePoint sprawl can lead to 10,000 or even 20,000 site collections and hundreds of thousands of individual sites within each. On the other hand, a well- designed SharePoint environment for a similar number of users might encompass just 30 SharePoint site collections.13 Achieving an effective balance between the number of SharePoint site collections and empowering users requires the development of governance practices an area where most organizations fall short.14

TWO KEY REqUIREMENTS ShOULD GUIDE YOUR USE OF ShAREPOINT FOR PROCESS APPS

Part of the problem is that people mean different things when they talk about processes.Many products are useful for providing process solutions, but not all products are uniformly useful for all process solutions. The best way to determine which of your process solutions SharePoint can handle is to determine your requirements in two areas: 1) procedures versus practices, and 2) process adaptability.

SharePoint Is Best For Procedures

At the highest level, it is useful to think of process as having a purpose. At the implementation level, that notion of process as purpose usually represents a spectrum between procedures and

practices.15 SharePoint, both MOSS 2007 and SharePoint 2010, is good for procedures, but not practices (see Figure 2). Why?

SharePoint WF supports procedures, yet the typical deployment scenario is toward practices.16 Deployments frequently need to support knowledge workers as they share and collaborate on documents. The processes of those same knowledge workers are usually highly variable that is, practices. Knowledge worker processes tend to unfold and evolve. The



6

problem is that the process conception of SharePoint is limited to the procedural end of the spectrum.17 Moreover, since SharePoint processes cannot easily chain or invoke each other, developers (not users) must maintain code-based interfaces, making their applications brittle and difficult to change.

SharePoint process definitions only affect new cases of work. Depending on the deployment regime and access permissions, SharePoint 2010 enables a user of SharePoint Designer to create a new version of a given process and deploy it instantly. New cases of work will reflect that new version, and existing work items will continue to operate under the old model. This approach will suit many sorts of static administrative processes, but there are also a great many scenarios where that sort of behavior is less than ideal.18 This is especially true of knowledge worker processes and customer-facing scenarios where new requirements emerge or a customer asks for things not covered in existing standardized offerings.

Out-of-the-box SharePoint tools to adapt existing process instances are nonexistent. SharePoint copies the underlying WF process model when the work item is created, storing it in a binary form along with the cases of work to which it relates.19 However, neither SharePoint 2007 nor 2010 provide any mechanism to update these processes.20 As a result, it is virtually impossible to adapt or change a process instance at runtime if needed. Again, this is a particular problem when attempting to support knowledge workers and customer-facing scenarios, where the steps and rules laid down by a user of SharePoint Designer may not apply to the evolving and unfolding problem in hand.21

SharePoint relies on .NET Windows Workflow Foundation (WF). All of these limitations arise from SharePoints reliance on WF. While SharePoint WFs two supported process patterns are common (sequence and state machine), customers must augment them with lots of custom WF code to reflect the rich nature of work in the real world. This is the slippery slope organizations find themselves upon, never quite sure where to draw the line on applications that do not belong.

While many BPMSes also suffer from similar problems (too focused on the procedural end of the spectrum), others offer a more dynamic approach to the runtime implementation of process models. The key point here is not that a dynamic approach is inherently better in all use cases; it is that without the ability to dynamically bind process elements, the purely procedural approach inhibits the potential architecture.

A useful analogy is that of the railroad network: While useful for carrying heavy loads, railway cars can only go where the rails already exist. Contrast that with the greater flexibility of the road network and the additional freedom that an off-road vehicle provides.22 Individual journeys between major destinations are fine by train, as long as you do not want to stop off or detour, but it does not make sense to lay a rail just to get to the corner store.



7

Figure 2 SharePoints Focus is on Procedures, not Practices

Source: Forrester Research, Inc. 56662

Procedures Practices

Straight-throughtransactions

Ad hocexceptionhandling

Truly uniqueexceptions

Traditional BPM and workflow

Knowledge worker processes and collaboration

Collaborativeworkflow

Productionworkflow

SharePoints focus

SharePoint Is Not Ideal For Process Adaptability

Most people new to BPM tend to think that standardization of all work and activities is the end goal.23 However, depending on the type of process, more and more exceptions emerge, with process developers building in workarounds and redeploying models. After a while, one discovers that long-term TCO is closely related to the ability to elegantly handle exceptions.

This is especially true of long-running processes (rather than short-lived transactions), where cases of work can span many days or weeks (if not months and years). Depending on the variability of the work, many cases require adaptability of process definitions at runtime to handle emerging customer demands, deal with unforeseen exceptions, or handle changes in regulations.24

When it comes to process adaptability, many BPM vendors use the phrase in-flight change to talk about the capabilities of their products to handle change to process models. However, they usually apply the term blindly, without distinguishing between (or understanding) the alternative meanings. The alternative approaches are:

Redevelop and redeploy. The vast majority of BPM vendors are referring to the ability to change a process in real time and redeploy it, affecting new cases as they are instantiated. No changes are possible to existing cases of work. This is the most common behavior that virtually all BPMSes exhibit.25

Individual instance modification. Usually based around an XML-based model of the process, a suitably authorized user can add new steps and subprocesses, rerouting work as necessary. Usually this requires re-engaging the original process developer who makes changes on an individual case-by-case basis (since very often these processes and the data that they manipulate are tightly integrated). Of course the user can also redevelop and redeploy the process instead.



8

Process migration. A third category takes a subtly different approach. Although rare, some BPMSes provide an interface for administrators to selectively apply a modified process to existing cases of work, with the user choosing the appropriate state of each instance. Clearly, this is quite powerful as it enables change to a large number of existing cases if needed. Again, the ability to redevelop and redeploy, or modify, individual instances is possible.26

Dynamic combination of process fragments. Individual cases of work are supported with a parent process model which incorporates the happy path, but users can also dynamically add process fragments or subprocesses (think of each discrete element of capability designed as a process object), building up the functionality required for the case in hand.27

While different vendors have taken diverse approaches, the underlying point is that they have all had to develop ways of getting around the show-stopping constraints of the purely procedural approach. Generally, the model-driven approaches found in BPMSes are far more flexible, allowing the organization to deal with those scenarios where unforeseen exceptions effectively invalidate the process description (developed beforehand). This limitation is a critical problem for products that extend the underlying SharePoint process capability (WF). While these products may look a lot easier to use (to the uninitiated), they are still biased toward relatively simple procedures by the underlying capabilities of WF.

Microsoft Partners Fill The Gap

A range of independent software vendors (ISVs) have developed BPM products that integrate directly with SharePoint. Most of them have sought to replace the SharePoint process engine. These vendors have found it necessary to introduce bespoke databases and components, either working alongside or replacing the SharePoint components. The way in which they achieve this integration varies considerably from a very clean Web service interface (where needed), to the introduction of SharePoint specific databases and updated dynamic link libraries (DLLs). In all cases, these vendors have been able to support chaining and invocation of process objects.28

Key vendors to consider in this space include: 29

AgilePoint. Formerly known as Ascentn, AgilePoint has tight integration with SharePoint, leveraging both its user interface and document management capabilities. Most importantly, the company has replaced the native WF engine used in SharePoint with its own, more comprehensive approach. AgilePoint also provides rich capabilities around process adaptability and migration, allowing the administrator to selectively apply process changes to running instances of work. AgilePoint has always utilized Visio as its modeling tool.

Global 360. Global 360 has sought to develop custom interfaces for different types of users (personas). It has also replaced the underlying WF engine used by SharePoint. Global 360 will start using Visio with the new 2010 release, which also provides a simulation component.



9

K2. This vendor has taken a subtly different approach, building its process engine based on WF (effectively replacing the one that comes with SharePoint). This has allowed the vendor to circumvent some of the limitations of that environment.

Nintex. Nintex leverages and extends the native SharePoint process engine. Essentially, it relies on the WF, and therefore suffers from some of the limitations around process adaptability. However, Nintex does make process development much easier, and it can handle process invocation and chaining.

r E c o M M E n D A T i o n S

ShAREPOINT USERS ShOULD DEVELOP A SPECIFIC BPM STRATEGY

Business process professionals in organizations considering or actively deploying SharePoint need to drive an understanding of how SharePoint fits and doesnt fit into their overall process solutions strategy. consider the following points for guidance:

Use SharePoint for simple administrative processes. SharePoint works best where the process scope is departmental in nature, or where applications rely on highly representative procedures. While it is also possible to link in external sources of enterprise data (such as a back-end SAP system), the issues arise when these processes span SharePoint site collections. Assuming a top-down regime, plan on using the administrative features of SharePoint to control enterprisewide deployments. Furthermore, since content tends to grow and grow, it is important to develop an information architecture and retention policies upfront, and then to enforce them, building in mechanisms for archive storage and subsequent retrieval.30

Select a Microsoft BPMS partner for enterprise scenarios. if you need strong, enterprise-scale BPM modeling, metadata-based deployment, and model-driven execution, then acquire these capabilities from a Microsoft partner rather than building them yourself.

Forrester expects a significant aftermarket will emerge for add-on BPM tools.31 While license costs may increase, overall Tco and risk will reduce. The resulting environment is also less prone to horizontal scalability issues.

Set your cost and benefit expectations. A SharePoint-oriented BPMS will add to the costs of your BPM technology stack, but should significantly reduce the overall Tco associated with enterprisewide BPM deployment. it will also lower risk, as people find graphical processes easier to understand and modify. remember that developing custom code will add significantly to your costs as well. Enterprise-level Microsoft support customers should check that third-party vendors adhere to the SharePoint customization Policy. Failure to do so may incur significant additional support costs from Microsoft (or invalidate that agreement).32



10

Avoid custom coding wherever possible. Developers will often feel tempted to code their way out of any issues they run into. But beware, this approach adds significantly to Tco and inhibits later upgrade options. Moreover, embedding processes in code is inherently risky, as those employees may move on and with them the understanding of how that code works. Where possible, follow Microsofts customization Policy for SharePoint implementations in order to keep the environment clean, with the objective of facilitating better stability, easier support, upgradeability, and migration options.33

Educate both business and IT. its important to position SharePoint and other BPM tools, ensuring that everyone understands the strengths and weaknesses of both. For example, meet with information and knowledge management specialists who bring in SharePoint as a collaboration platform to ensure that they understand the platforms place in the firms BPM strategy.

Establish appropriate governance practices. Develop strategies to control process proliferation in SharePoint, ensuring that colleagues in both the business and iT understand the role of SharePoint and its limitations.

ENDNOTES1 Microsoft revealed these revenue details in an October 19, 2009, press release. Source: Microsoft Unveils

SharePoint Server 2010 and Showcases New Functionality, Microsoft, October 19, 2009. (http://www.microsoft.com/presspass/press/2009/oct09/10-19MSSharePointConf09PR.mspx?rss_fdn=Press%20Releases)

Indeed, at $1.3 billion in software license sales, Microsoft SharePoint is probably bigger than the rest of the BPM industry combined (depending on how you define the market). In a very real sense, Microsoft has introduced workflow and process support to a much broader audience. Traditionally, BPM and workflow products were used by organizations that saw the value of automating core, mission-critical applications. Microsoft has changed that by bringing in a whole new class of user.

2 SharePoint Designer supports only a sequential process pattern, whereas the underlying WF environment supports both sequence and state machine.

3 With Visio 2010, a new template is supplied that enables the definition of processes. This template is not the Business Process Modeling Notation (BPMN) template, which is also new in Visio 2010. The SharePoint template supports the development of sequential processes including parallel threads and a wait timer. The wider set of process patterns, for example those defined in BPMN, are not supported.

4 Theres also a built-in catalog to promote use of common templates, WebParts, enterprise content types, etc. We expect partners to develop additional tools in this area.

5 While easing the developer pain of accessing these applications, Enterprise Connectivity Services also implies the need to take a more proactive stance in designing a master data management approach that facilitates access to enterprisewide assets. This is not a trivial exercise and could take many months of concerted effort.



11

6 We define a BPMS as a set of software tools that work together to enable the organization to better manage its business processes and relationships with customers. This implies the ability to drive work using a set of explicit process models, monitoring progress, and enabling their ongoing improvement. On the other hand, business process management is a business improvement management discipline it is about people, the way they work together (their business processes) and the performance objectives that these processes underpin. At the same time, it usually involves a suite of enabling technology that makes this vision a reality. BPM is also itself an incremental process in that BPM systems implementation is done in stages, and change happens in bite-sized chunks, layering on new capabilities and functionality bit-by-bit, rather than using big-bang deployments. BPM as a management discipline is a distinctive way of running the business (a different mindset) that continually drives performance improvement. BPM is a journey, not a destination.

7 While it is possible to construct SharePoint processes to do a similar job, the issue is the level of complexity needed in the process model and the custom coding that may be required. A BPMS tends to provide tools that make this sort of problem trivial.

8 Some firms have spent literally millions of dollars in custom-coding, only to find that their applications have become static and inflexible, negating many of the benefits provided by the SharePoint collaboration environment. Moreover, unless developers have experience in building process-based applications, they must also develop the competencies required.

9 For example, a major energy company spent six months developing custom code to support the synchronization of parallel threads of activity required for a relatively simple approval process.

10 The reality is that, unless the organization has deep competence in business process implementation, it will inevitably fumble through trial and error to discover that custom coding does not create anything manageable. By that time, it may well have spent hundreds of thousands of dollars and many years of lost opportunity.

11 Microsoft positions WF as providing process capabilities within an application. When moving data between applications, BizTalk is recommended as more appropriate (creating a hard-coded interface). With the SharePoint site collection acting as the container, it is necessary to deploy each WF-based application to each site collection. Each WF acts as a mini process engine for that container. Over time, this can create problems, as each minor modification to a process requires retesting in every site collection (where it was originally deployed) and then manually redeploying. This challenges horizontal process scalability, since the amount of effort required is directly related to the number of site collections.

12 SharePoint implementations tend to take one of two forms bottom-up or top-down. By definition, bottom-up initiatives are unplanned and lack central control. Further down the line, this usually results in an expensive rebuild of the entire structure. Today, the norm for large organizations adopting SharePoint as a strategic weapon is top-down with a large server farm and shared services. Well-planned, with well-defined governance and customization policies, these types of implementations typically involve advice and guidance from Microsoft during setup. Microsoft often provides enterprise-level support for the entire deployment.



12

13 Figures are extracted from research conversation with Sue Hanley on October 1, 2009. Sue is a co-author of Essential SharePoint 2007 and before going independent, she led the SharePoint Practice within Dells professional service organization (http://www.susanhanley.com/).

14 Source: Dave Wollerman, Site Collection Logical Architecture, Dave Wollermans SharePoint Blog, June 25, 2007 (http://vspug.com/llowevad/2007/06/25/site-collection-logical-architecture/).

Also, with SharePoint 2010, the administrative tools have improved, giving IT more control over sites, site creation, usage tracking, and site deletion.

15 It is best to think about process as a spectrum one end focused on efficiency (procedures) and the other on value and innovation (practices). In the domain of business processes, dialect is a big problem. Ask 20 people in the street for a definition of process, and you will receive at least 12 different answers. Some might accurately describe a process as the way things get done around here. Others talk of

sequences of activities, where prescription and control are more important. More common notions include transforming inputs into products and services of higher value, or a collection of business activities that create value for a customer. A more useful notion might be a number of roles collaborating toward a goal. But when business strategists suggest that a high-level process review of the organization is required, they really mean process as purpose. They are interested in the value delivered by a process the customer relationship, the shipping process that exists to deliver some sort of benefit to the organization, its customers, or stakeholders. For example, firms have a finance process to make sure that they dont go bust, that customers pay for products and services delivered, and that the organization pays only for those resources that are used. Therefore, for business strategists, process (as purpose) leads to an emphasis on identifying the capabilities and behaviors that the business needs to exhibit. The often implicit assumption is that they can then derive the appropriate organization.

Teasing apart this notion of process as purpose, one finds that there are some aspects that rely on control and rigid adherence to preordained procedures, and others where the goal is more important (practices). For procedures, we often introduce technology to reduce the (human) resources required to undertake a given amount of work, allowing the business to scale and do more with less. The emphasis is on speed and efficiency. Employees are not required to know much about the overall end-to-end process. Instead, they focus on handling task requests in double quick time, or dealing with X number of work items per hour. Procedures are imposed on them to ensure control and compliance with the preordained approach.

At the other end of the spectrum, knowledge workers practices are goal-centric. They guide rather than control the work. If the case in hand requires something special, a variation from the standard approach, knowledge workers are empowered to exercise their judgment. Given the increasingly customer-centric business environment, it is critically important to respond to their often evolving needs.

Procedures and control are necessary in most back-office operations. All would agree that the accounts clerk should not get creative with a bank draft. Organizations have very strict procedures and systems for handling money directly. On the other hand, try applying a rigorous procedural approach to those developing new business offerings or those managing the organizations largest corporate customers, or even its executives. They would rebel if everything they did had to fit within rigid computerized procedures



13

developed beforehand. But, if those same individuals had accessible and easy to use mechanisms that enabled them to dynamically recombine procedural fragments that helped them automate the repetitive aspects of their work, then they would probably embrace that technology offering. They would start to regard those facilities as an essential part of their work environment, enabling them to achieve more in the time available.

Most business processes involve a combination of both procedural and practice elements think of the macro-level purpose, interpreted as a mixture of procedure and practice. Processes often flip-flop from one end to the other. For example, consider a pharmaceutical firm developing a new compound and bringing it to market in the form of a drug. Developing the compound is almost certainly practice-driven. Deciding which new compounds to promote to the next level is probably governed by a certain degree of procedure but also includes elements that involve people making value judgments (practice again). Contrast designing a clinical trial (practice), with running the clinical trial (procedure), or moving on to developing the market engagement strategy (practice). Finally, the sales transactions involved in delivering the drug to market will have procedural definitions, as will the relationship between sales demand and production, although the coefficients may often change.

16 Most SharePoint deployments deal with the practice end of the spectrum, where users deal with the reality of their day-to-day work and collaborate to achieve goals. They dont see SharePoint as a platform for highly codified processes that dictate the order of work. Instead, they collaborate around documents and topic areas in a SharePoint site, initiating simple procedures in an ad hoc fashion.

17 Most BPMSes also struggle to deal with the spectrum from procedures to practices. Too often they focus on the highly repetitive end (procedures), where there is little or no variation. Inevitably, one of the critical differentiating factors for these products is their respective abilities to deal with the needs of knowledge workers and their attendant practices.

For organizations assessing BPMSes, it is important for them to understand where on this spectrum their real problems exist, especially focusing on the degree of variation required at runtime. To some extent, this is culturally dependent.

18 This does not mean that one would want a process/workflow change to automatically change all instances that are in flight. Doing so would normally introduce a lot of risk (to those instances). The point is that the process model supporting the case in hand might need to change to handle some special circumstance or customer requirement. Without the ability to do this, the process architect is limited to simplistic processes.

19 These process instances might have to travel across the SharePoint infrastructure. A binary form is used to support better vertical scalability of the SharePoint environment.

20 Technically, it is possible to update these processes using the API, but out-of-the-box, Microsoft does not provide access to these definitions. Once they are created, they are usually regarded as set in stone.

21 Modern BPMSes tend to get around this sort of problem by externalizing business rules, allowing a relatively simple process to exhibit sophisticated behavior. Moreover, if a new behavior is required, the rules are amenable to change without affecting the process.



14

22 One could stretch the analogy to point out that we clearly need different forms of transport for different scenarios. How many of us (individuals or organizations) rely on a single form of transport? The phrase

horses for courses also springs to mind.

23 In the early days of workflow and BPM, organizations assessing the technology had a reasonable understanding of the issues associated with process automation. They tended to have a higher level of organizational maturity and had gone through the pain of making their processes explicit. But with the widespread introduction of SharePoint to the market, a much wider range of people now had workflow at their fingertips; yet their understanding of process was still in its infancy. Indeed, organizations that start down this road are on a journey, growing their overall maturity and the process acumen of their employees.

With SharePoint, many have assumed functionality and capabilities that simply are not there. Or if they are, then they involve a lot of coding. The point is that many firms stumble, wasting significant time and money as they learn about the finer points of the approach.

24 Of course, existing cases of work are subject to the change in regulation and it may not be possible to kill the work item and start again under a new process.

25 This is also the SharePoint approach.

26 A suitably configured BPMS can handle the automatic testing and deployment of process models to multiple SharePoint site collections.

27 This is one of the design approaches taken by so-called case management vendors. There are many challenges to this sort of design approach, and again different levels of capability result from subtly differing approaches to implementation. The key point to recognize here is that there are many subtly different approaches to case management. On the one hand, users might select from an existing library of process objects (with no ability to change them). Data associated with case usually governs the options available. Most often, this library of process fragments is developed beforehand, but in some of these products, users can potentially modify behavior of individual process objects, or add new ones. Other case management systems rely on providing shared access to documents i.e., the context of the processes surrounding the case are buried inside the documents stored against it. Users access the document store in an ad hoc fashion. This is the usual approach for SharePoint-based systems.

28 Chaining implies that one process can call another, passing the context for the case in hand (and then finishing). On the other hand, invocation is where one process invokes another and waits for it to complete. A potential approach is where a user might bind multiple process objects into a parent, effectively adding new functionality to that process (this is one approach to dynamic case management).

29 Microsofts Business Process Alliance has focused on helping ISV partners build on the Microsoft platform, including SharePoint. While not a definitive list of vendors integrating with SharePoint, it shows those vendors that have close relationships with Microsoft: http://www.microsoft.com/soa/partners/bpa.aspx. We have assessed a representative sample rather than all ISVs in this space.

30 Developing effective information architecture implies understanding the organizational need for data, and then building that into Enterprise Connectivity Services server within SharePoint (and potentially



15

integrating with back applications). We would suggest that this is not a trivial exercise; it will require specialist skills and may involve many months of focused effort. This specialist competence is poorly understood by many organizations.

31 Given the recent wave of consolidation in this market (IBM acquiring Lombardi, Progress acquiring Savvion, Pega acquiring Chordiant), it would not surprise us to find Microsoft exploring similar options to flesh out its product offerings. See the March 22, 2010, IBM Doubles Down On BPM With Lombardi Acquisition report.

32 For enterprise-level clients, Microsoft is often involved in providing support to those customers. Quite rightly, Microsoft dictates a Customization Policy, setting out the rules that the organization must follow when developing and deploying SharePoint applications. The standard policy (for MOSS 2007, available at http://go.microsoft.com/fwlink/?linkid=92311&clcid=0x409) stipulates that proprietary database (access or schema) and modifying SharePoint files is specifically disallowed.

33 Some of the key guidelines include avoiding the installation of proprietary Web services, Windows services, or databases. It also implies restricting access to the SharePoint database and the local server registry.



16

Forrester Research, Inc. (Nasdaq: FORR)

is an independent research company

that provides pragmatic and forward-

thinking advice to global leaders in

business and technology. Forrester

works with professionals in 20 key roles

at major companies providing

proprietary research, customer insight,

consulting, events, and peer-to-peer

executive programs. For more than 26

years, Forrester has been making IT,

marketing, and technology industry

leaders successful every day. For more

information, visit www.forrester.com.

Headquarters

Forrester Research, Inc.

400 Technology Square

Cambridge, MA 02139 USA

Tel: +1 617.613.6000

Fax: +1 617.613.5000

Email: [email protected]

Nasdaq symbol: FORR

www.forrester.com

M a k i n g l e a d e r s S u c c e s s f u l E v e r y D a y

56662

For information on hard-copy or electronic reprints, please contact Client Support

at +1 866.367.7378, +1 617.613.5730, or [email protected].

We offer quantity discounts and special pricing for academic and nonprofit institutions.

For a complete list of worldwide locationsvisit www.forrester.com/about.

Research and Sales Offices

Forrester has research centers and sales offices in more than 27 cities

internationally, including Amsterdam; Cambridge, Mass.; Dallas; Dubai;

Foster City, Calif.; Frankfurt; London; Madrid; Sydney; Tel Aviv; and Toronto.

forrester_sharepoint and bpm %e2%80%94 finding the sweet spot_derek miers[1]

Documents

sharepoint platform

use of sharepoint

sharepoint success

governing sharepoint

business process professionals

business users

business people

process appssharepoint