SharePoint has a workflow engine and is designed to manage document approvals, so why is it not the ideal Business Process Management Tool?
Firstly, what is SharePoint? A search of definitions provides the following:
- Microsoft’s definition: Organizations use SharePoint to create websites. You can use it as a secure place to store, organize, share, and access information from almost any device.
- Wikipedia: SharePoint is a web application that integrates with Microsoft Office. Launched in 2001, SharePoint is primarily sold as a document management and storage system, but the product is highly configurable and usage varies substantially between organizations.
SharePoint is not positioned as a Business Process Management (BPM) Tool or Suite. The workflow engine in SharePoint was primarily designed to manage document approvals. It has certainly grown since then, but developing business critical process solutions with SharePoint is still difficult and complicated, and as a result expensive.
SharePoint 2016 ships with the following out-of-the-box workflows:
- Approval (multiphase, centralised allocation etc.)
- Three State
- Collect Signatures
- Collect Feedback
- Publishing
- Disposition
Additional workflows can be built using either the SharePoint Designer 2013 or Visual Studio.
So if SharePoint does provide these capabilities, why is it not suitable for developing Business Process Management solutions? In my opinion it comes down to the following major points:
Versioning and Deployment
The difficulties associated with not versioning a workflow definition doesn’t usually manifest on the first deployment of a workflow, but rather on the maintenance of it. Regardless of how well a workflow is planned, a business-critical workflow will be updated several times in its lifetime due to bugs, changes in business requirements or legislative changes.
This means that a new version of the workflow process needs to be developed, tested and then deployed to production every time. Consider the complexity of the following; a workflow process has been instantiated or started 1000 times since its previous deployment. Three hundred of those processes have completed, but seven hundred of them are still running instances. Each of those seven hundred will be at one of the many steps of the workflow process.
When you need to deploy a new workflow process definition, one is stuck with the question of what to do with the seven hundred still-running instances. It would be great to wait until all of them were finished, but this is rarely an option in a production business environment.
Processware versions it’s process definitions as well as the forms and catalogues that a process is dependent upon. Because the process definition is treated as a unit, it provides the technical team with options such as overwrite the current process and allow the current running processes to execute with the new logic, or deploy a new version of the process definition, which will allow all new instances to inherit the new logic, and all running instances to complete with the old logic. This can all be done without taking the system off-line.
A SharePoint workflow consists of the workflow definition as well a combination of dependent web-parts, lists, assemblies etc. SharePoint does not consider these as parts of a whole, they are loose standing items. Although SharePoint allows you to version the actual workflow, the dependent objects (which normally represent the user interface etc.) are not versioned. So the coordination of what is new, and what is not, needs to be very carefully managed by the technical team. For example, if a list has to be updated to support the new workflow definition, it has to be changed in such a way that it doesn’t break already running instances of the process. Additionally, because these changes cannot all be done at once, the system normally needs to be taken off-line to affect the changes, in order to prevent users from interacting with a partially deployed solution. In short, this process is time consuming, prone to errors and extremely stressful to technical staff as well as business owners.
Provisioning and Administration Tools
SharePoint’s provisioning and administration tools are developed at two levels.
- Global: These tools are at the site collection level and are aimed at the provisioning of sites, users and groups.
- Site: These tools allow the manipulation of objects like lists, web parts and documents at a site level.
The challenge is that business processes very often cross inter-organisational boundaries (think purchase request or expense claim). In most cases SharePoint sites are set up according to organisational structures. This means that developing cross departmental workflows is challenging, as the layout of sites, security, as well as the management tools, do not cater for working in this manner. Accordingly, custom provisioning and monitoring tools normally need to be developed to aid in managing these workflows.
Monitoring Tools
As the original intention of the workflows in SharePoint was to approve documents, centralised monitoring tools or dashboards are virtually non-existent in SharePoint. This holds true for logs and any other metadata related to the actual workflows. This lack of tooling can be attested to by the proliferation of third-party vendors that have written various tools and utilities to support SharePoint administration.
Reporting
Managers routinely expect to have reports based on the information gathered and manipulated by workflow processes. For example - how many leave applications, what type of leave taken, the value of a customer’s purchase requisitions and so on. Once again, going back to its routes of document approvals, no-one was thinking of reporting on the workflows when SharePoint workflows were designed. Therefore, accessing the data relevant to a specific workflow is convoluted and difficult as the SharePoint database was designed for extensibility and not reporting.
Business Process Management Suites, like Processware 2016, know that reporting on data in the process is essential and make provision for reports to be easily generated.
Integrating SharePoint with Other Applications
By its very nature integration to external systems like ERP systems and other custom line of business systems is a very common requirement in Business Process Management (BPM) Solutions, and thus catered for by the BPM Software. Although SharePoint exposes a lot of integration into SharePoint through its various application programming interfaces, it has no framework for external integration. This means that all integration to external systems is manually coded by the developer in question which leads to a wide range of implementation approaches and levels of success. Additionally, it always raises questions about security in terms of how external systems are accessed, and with which credentials.
In contrast all good BPM Suites will ship with some type of integration framework which allows a consistent well understood approach to this problem.
Conclusion
It is important for business owners and decision makers to have an understanding of what Microsoft SharePoint is meant to do. Microsoft’s own definition promotes it as a repository of information. SharePoint does this well. So store your information and documents on SharePoint, but leave the business critical processes and workflows to the professionals.
