Share More: a framework for enhancing collaboration

In a great study, McKinsey and Company published last year they showed how companies that use social and collaborative technologies extensively (networked companies in their terminology) outperformed traditional companies. They called it “Web 2.0 finds its payday”.

So if you work for a networked company – congratulations. Now if your company is part of the vast majority of companies struggling through some forms of collaboration but not seeing enough benefits, how do you get to the payoff stage?

In this following series of posts, I’ll try to offer a methodology and examples for how to do just that. Elevate the level of collaboration and create a fully networked organization one step at a time.

We call this process Share More.

The premise is simple, for each business area or function, find a real world business challenge where collaboration can make a difference. Implement it. Move to the next one.

Creating the overall framework is like creating an association wheel for the term “Share” in the middle:

Sharing can be with just a few team members or with the whole company. It can be internal or external. If you stop and think about all the interactions you have in a week, which causes you the most pain and time? Can these interactions be made simpler using technology? Can you Share More?

The first Share More solution I’d like to address is process and workflow solutions.

Share Process

Process and form automation is all about tracking and control. The real dramatic change is in giving managers and administrators visibility into every step and log of every change and update. It can also speed the process up and save effort in typing information into other systems, initiating emails or filing paper into physical files.

We’ve worked with a large hospitality organization to automate all HR and Payroll related forms through the use of InfoPath and SharePoint and learned a lot of valuable lessons that can be valid to many a process automation:

  • Strongly enforce data integrity: Most forms are created to collect data that will be fed eventually into another system. Therefore data input must come from the same source system it will end up in. Values and choices have to be restricted to valid combinations and open text fields limited to a minimum. The cleaner the data is, the less trouble it will cause down the road.
  • Know how organizational and reporting hierarchy is maintained: While you may know what system holds the organizational reporting structure, knowing that it’s 100% accurate and maintained up to date is a lot harder. Since some forms require sending confidential information like salary for approval, the wrong reporting relationship can compromise important information. Consider masking personal or confidential information if it is not essential for the approval requested (while the data, encrypted, can still be part of the form)
  • Don’t over customize: like our beloved tax code, approval workflows can get extremely complicated and convoluted as organizational politics that evolved over the years created special cases and more exceptions than rules. Codifying these special cases is expensive and prone to change. Consider it an opportunity to streamline and simplify the rules.
  • Augment with stronger 3rd party tools: while the core systems – like SharePoint contain built in (and free) workflow mechanism, it is limited in the control, flexibility, scalability and management as it comes out of the box. Some 3rd party tools like Nintex and K2 BlackPoint provide added flexibility and scalability. For a price.
  • Version deployment: Forms and process will change. How will updates be deployed without interfering with running flows and processes?

In future posts I’ll explore other opportunities for Sharing More including Sharing Insight, Sharing Responsibly and we’ll look into specific opportunities for collaboration and sharing in insurance and healthcare.

Making sense of SharePoint’s Workflow and BPM capabilities

Workflow and BPM often get lumped together but it is important to understand the difference between them if you are to pick the right tool for your enterprise. While it is generally agreed that workflow is for modeling simple sequential processes and BPM solutions are more capable of handling complex tasks the distinction between the two needs to be further sharpened. According to David McCoy of Gartner BPM can be defined as “… a structured approach employing methods, policies, metrics, management practices and software tools to manage and continuously optimize an organization’s activities and processes.” Workflow on the other hand is concerned with tasks and application-specific sequencing of activities through a series of predefined steps, involving a small group of people and/or closely related applications. The distinction between the two is far from crisp and in fact it can be argued that both are part of the same continuum. However, there is a distinct difference in focus and complexity between the two. Here is a chart that attempts to further define the two based on capabilities and task suitability.

According to a recent survey by Forrester, Microsoft and SharePoint came in as #1 among the IT decision makers for use as BPM platform followed by Oracle, SAP, IBM, and a host of other BPM centric companies. Forrester report further notes that despite Microsoft’s best efforts to not position SharePoint as a BPM solution (rather as a collaborative workflow solution); the message does not seem to come across clearly. This confusion seems to thrive due to lack of clear and well-defined goals for business process automation and understanding of capabilities of SharePoint and BPM suites (BPMS).  The Forrester report outlines that SharePoint’s features for supporting true BPM are limited. Most of SharePoint’s capabilities in this arena are founded on Windows workflow foundation (WF). While a custom solution can be developed based on SharePoint and WF API to support BPM like capabilities, such an endeavor is bound to be expensive and brittle. SharePoint shines best when OTB capabilities are leveraged to the maximum and customizations are managed carefully. SharePoint’s workflow, document management and collaboration features can be used to develop robust workflow applications that can simplify and automate document & form centric business processes. SharePoint can also serve as a hub of cross-department and cross-application integration but only at the user interface level. SharePoint does not pretend to act as middleware or an enterprise service bus (ESB) and therefore does not provide any standards based application integration features – tasks best left to dedicated integration platforms or BPM solutions.

The limitations of SharePoint’s built-in workflow and underlying Windows Workflow surface quickly when tested against complexities of true enterprise business process automation scenarios. SharePoint’s workflow processes are constrained by the Site Collection boundaries. Therefore any workflow that needs to span organizational boundaries and as results site collections becomes difficult to manage and brittle. For example if a budget approval process needs to go through the finance department, corporate office and local approvals and if any of these structures use their own Site Collections the workflow process will require custom coding or manual workarounds. This constraint limits SharePoint’s workflow scope to department or local application level. WF processes are also limited to either sequence or state machine patterns. There is also no support for a user who makes a mistake and needs to go back to the previous step during a workflow. Multi-level approvals are also not supported a document needs to be routed back to one of the earlier approvers rather than the author. SharePoint workflows are executable programs and therefore cannot adopt easily at runtime (after instantiation) to changes in the rules that may result from changes in business process environment (e.g. regulation changes, corporate policy change, etc.)

While SharePoint is not ideal for complex business process automation it can certainly be used to get started. If all you organization needs is automation of simple and commonly used business tasks (approvals, document management, simple HR applications, financial approvals, etc.)  that do not require tight integration with other data systems and do not require complex exception processing, modeling, optimization, monitoring, etc., then it is a good candidate for SharePoint workflow. However, if your organization is truly looking into business process automation and business process improvement (BPI) then there are many 3rd party solutions (AgilePoint, Global360, K2, Nintex etc.) that can be layered on top of SharePoint to create a more robust solution. The advantage of a layered solution is that 3rd party vendors are able to leverage Microsoft’s significant investment in ease of use, collaboration and user interface integration capabilities of SharePoint while adding core BPM functionality. Such solutions are also typically less expensive and deploy more quickly than a traditional full-blown BPM solution (depending on the situation).

There two basic flavors of the layered BPM solutions (products that leverage SharePoint’s platform & interface for most interactions). The first flavor of these solutions relies on the underlying WF as their workflow engine. Using WF as the base they have built capabilities that are more advanced than out of the box capabilities of SharePoint. Furthermore they are able to maintain a light footprint by leveraging SharePoint and WF infrastructure. However, they naturally suffer from some of the same shortcomings as WF. The second group of solutions relies on proprietary workflow engines that are not built on top of WF. Such solutions typically have larger footprints since they create their own parallel infrastructure for workflow processing and data storage. Their independent foundation allows them to provide capabilities that are not limited by WF but typically at the cost of additional infrastructure complexity. There is a place for either kind of solution and picking the right tool (SharePoint workflow vs. SP layered BPM vs. dedicated BPM) is a vital cog in any business process automation or improvement endeavor.

However, the story does not end at picking the right tool; in fact it is just getting started. Edgewater recently conducted a case study on the effectiveness of such efforts and found that there is a significant disconnect between popular BPM messaging and the companies deploying such technologies. While ROI is considered to be the holy grail of most IT projects the respondents in the survey noted that “ROI was not the most important factor … “, other areas such as customer satisfaction were more important. Survey also found that while BPM tools are more than capable of modeling complex processes organizations implementing BPM preferred to “start with well-defined process that involved fewer people to get a quick win and buy-in first”. Perhaps the most important finding was that the success or failure or an implementation depends on “solid understanding of the business AND the necessary technical skills to implement BPM; just one won’t work.” Business Process Improvement (BPI) needs to be a continuous learning and optimizing cycle. Picking the right tool is only half the battle, having a clear vision of goals and objectives and how BPM may or may not help achieve those is just as essential.