SharePoint is a great tool for collaboration between people, or as Microsoft puts it “SharePoint is an enterprise information portal that can be configured to run Intranet, Extranet and Internet sites.  Microsoft Office SharePoint Server 2007 allows people, teams and expertise to connect and collaborate”.

The one piece that is missing from that description is the idea of business process – which I describe as the business context in which the documents exist and the collaboration takes place. Microsoft isn’t blind to this and in SharePoint 2010 is promoting “SharePoint Foundation 2010” which is a enhanced version of the current “Windows Workflow Foundation” to allow programmers to create workflows associated with a SharePoint site. Basing the process implementation on Windows Workflow Foundation has a number of problems from a technical perspective (requires programming, processes are limited to the boundaries of the SharePoint Site Collection and processes can’t be changed at runtime). This makes its OK for structured processes – but completely in appropriate for human processes – the ad-hoc, unstructured process that we manage here at ActionBase.

In my previous post I wrote that Microsoft’s approach to process surprised me since they own the business tools most associated with the execution of human processes – Outlook (email) and Office (Documents). SharePoint 2010 could have been the platform for the killer app for human process management – by linking unstructured processes and unstructured data, human collaboration and human processes.

Well here at ActionBase we decided to fill the void. By linking ActionBase and SharePoint, people can easily link together (within a SharePoint site) the documents and the processes related to those documents. “ActionBase for SharePoint” brings to SharePoint users and to the organization a whole set of advantages that radically increase the benefits and ROI of a SharePoint installation:

1. Documents stored in the site can be ActionDocs. That means that documents don’t need to be only passive – they can be used to initiate and track the processes related to them. The simplest way to think about this is “meeting minutes” – “ActionBase for SharePoint” allows the “meeting minutes” document to kick-off and monitor the processes and action items kicked-off at the meeting.
2. The activities of the group can now be managed. This doesn’t mean much if the site is a passive “read-only” portal, but that isn’t what SharePoint is about. It is about collaboration between people – and let’s face it, collaboration between people ALWAYS includes email. “ActionBase for SharePoint” links ActionMail and SharePoint – so the group can know the various activities taking place outside the site in email that provide the context for the site and its documents.
3. From an organizational standpoint, using “ActionBase for SharePoint” enables SharePoint to become the “system-of-record” not just of the documents – but of the context and activities that take place related to those documents. From a compliance standpoint this is huge. This means from a GRC perspective that Outlook + Office (the main GRC tools in most organizations) + SharePoint +ActionBase finally gives organizations a GRC tool that doesn’t require a new platform – or for people to change the way they usually do their work.

We truly believe that these advantages make “ActionBase for SharePoint” the killer extension to SharePoint.

I read an interesting article on the origin of the brown M&M clause in Van Halen’s concert contracts at snopes.com. Van Halen’s standard contract would specify that a bowl of M&Ms should be provided backstage, with all the brown M&Ms removed. The reason was that Van Halen used this clause as an easy way to test whether the contract had been read and executed with sufficient attention.

Probably not  an everyday occurrence for most contracts, but it made me think about the processes that need to be put in place to ensure that contractual obligations are fulfilled. It is a different type of compliance issue (business compliance instead of regulatory compliance) – but still is an operational risk issue.

Even a relatively simple contract requires a lot of management, tracking and followup to make sure the terms are met. This process is another example of  an ad-hoc, unstructured human process that would be significantly enhanced by using a human process management system like ActionBase.

The way we would handle it is to have to have the contract owner assign the different clauses to the appropriate people directly from the contract document, and provide the owner a way to track and understand where the implementation of any process related to any clause stands. We can help make sure the brown M&M’s are removed, and if not, at least let you know why.

I was reading KPMG’s report on the need for Risk Executives. The job of a risk executive is to “establishes governance, policy, and risk management discipline” in the business. In short their job is to create a coherence of processes and reporting for risk management across the organization. That requires putting controls into a lot of unstructured processes.  Given the  lack of tools available for managing unstructured processes – the benefit will be mostly from increased attention to the area of risk management (the Hawthorne Effect), and from the visibilty across silos.

Using a Human Process Management System could actually provide robust tooling to support this at very little cost, and turn it from a reporting exercise to a real time operational excellence exercise. Lets say some new, critical regulation is announced, for example the new “breach notification” provisions of the Health Information Technology for Economic and Clinical Health (HITECH) Act. The regulations require HIPAA covered entities to promptly notify affected individuals of a breach, as well as the HHS Secretary and the media in cases where a breach affects more than 500 individuals. Since this is new regulation, without any tool support, the only way for the risk executive to handle compliance would be to assign someone as the breach process owner. The process owner would probably send out instructions on how to handle a breach. The first step could be when a breach is discovered, an email should be sent to the breach process owner. At that point they would need to organize a response to the breach making sure to meet the regulatory requirements, and any relevant internal processes. That means ensuring affected individuals are notified, and if needed the HHS secretary is notified. They may also launch an internal investigation of the breach (investigations are another type of unstructured process, since they are human processes and once started they take on a life of their own based on the information collected). All this will probably be done via documents and email – making impossible to manage, track and audit compliance with the regulations – except by after the fact manual reporting.

On the other hand, leveraging a human process management system like ActionBase would enable the risk executive to quickily create an ad-hoc procedure for handling the process on top of existing email and documents – and automatically achieving manaement, auditability and tracking of the process – with no extra cost.

When trying to implement regulatory compliance it seems to me that there are three ways you could go aout implementing human centric regulatory compliance (where people play a big role in the compliance process)

• The first is a rigorous workflow driven process approach, where each step is part of a completely defined process. The process would have little (or no)  flexibility and the people involved would have no discretion how things should be done. This approach would ensure compliance, and could work well when most of the process is automated (done by machines) or by very low level workers. This approach allows for complete process optimization, since every step is choreographed and can be measured and optimized. However, this approach would be very stifling and wouldn’t work for complex regulations or in a changing environment.
• The second is a controls approach. Based on a guideline or best practice, people are trained and would be expected to do their part. Controls in certain critical junctures in the process could be defined and measured to ensure an expected workproduct exists at the control point. This gives people more flexibility since they wouldn’t be told how to do things, but only what is expected of them (they are told the “what”, but have freedom with respect to the “how”). The downside here is that any information about how things get done is lost – and there is no way to use that information to iteratively improve the process. Another problem is that even though the control is compliant – the way that compliance was obtained may be problematic (and I don’t mean malicious intent – just that things were done the wrong way, perhaps for good reasons). 
• The third is a tracking approach. Here too there are a guideline and controls. The difference from the workflow approach is that the “how” isn’t dictated -but unlike the second approach it isn’t ignored, but rather is tracked so that “how” is known after the fact. Like the second approach there are controls defining specific work product at specific junctures in the process. In my opinion this approach blends the best of both worlds for knowledge workers – it doesn’t stifle them by dictating the “how” (which is probably impossible for many regulations), but enables an audit (even in real time) of both the “what” and the “how” enabling both compliance and process optimization.

I was reading an Aberdeen report on “The Reinvention of the Internal Audit” which has lots of interesting statistics about internal audits and auditors. What was most interesting for me was that they came to same conclusion as Michael Rasmussen in his post on the the largest GRC vendor – Excel and Outlook (and a little Sharepoint) are the standard Internal Audit Platform – which by default makes Microsoft the largest Internal Audit Platform provider.

It was also interesting to me that they used the term Internal Audit Platform distinct from GRC.

In any case this meshes with what we see with our Audit.Tracker solution – the use of Excel and Outlook is pervasive for internal audits. Given the changes in the regulatory environment, this is going to be a real problem.

In the current regulatory environment I expect we’ll see more and more calls for increased disclosure requirements for various internal processes. One the latest is SEC’s Release 33-9052 which sets forth proposed amendments to Item 401 of Regulation S-K that will require disclosure of “qualifications, attribute or skills” that qualify a candidate for service in a governance capacity for a particular company, based on that company’s business and structure.

I was reading an interesting post on “Best Practices for Conducting Background Checks on Board of Director and Executive Officer Candidates” which provides a nice guideline on how to do background checks and possible red flags that companies should be on the alert for.  The  guideline is useful, but as a chief compliance officer, or member of the audit committee, how would you know that best practices were followed?

One way would be to make sure that all the documents collected regarding a candidate were stored and accessible. That would at least provide some material, but of course the process used to obtain the information would be completely lost. Another would be to have your IT department build an application, but even using tools like a BPM suite – that would take a while.

Finally you could use an HPM solution like ActionBase – take the guidelines, mark them up as an ActionDoc, and then use ActionMail to manage the process. You could this up and running almost immediately (using guidelines like those in the post, and creation of a few ActionMail templates) – and you would have a simple solution to the problem. Doing it this way provides both the access to the documents, and the process (and of course all the relevant status and historical reports).