I know this is kind of a stupid experiment, but it does point out (at least for me) the current state of tooling for most knowledge workers. They consider their work (at least the important part of it) as “Design by Doing” as Jim Sinur so nicely worded it in his blog. BPM as they understand it (and I’m sure that everyone understands it a bit differently – but I’ll guess the ability to model a process, most probably in BPMN, is part of what they think is involved in BPM) has nothing to do with their everday jobs.

Sure we could try and extend BPMS (the tool) to include the kind of work they do, perhaps even extend it enough to have it include email and document management systems (or is it that document management systems include BPMS, I get confused). But why should we? Most BPM systems have hooks that let the system invoke email (and so do document management systems) – but I would doubt most people would consider email as part of BPM. BPM and email are two separate systems which are sometime used in unison to solve a business problem – there is no need to pull them both under the same umbrella. I think the same is true of Wikis and other social technologies – they are useful tools – and there is no benefit pulling them under the BPM umbrella. So in the on going debate on ACM as part of BPM – I’m going to have to side with Keith and Max.

BPMS (the tool, not the approach) is for routine, predictable, structured work where people and documents may play a part – but are not central. ACM is for unpredictable, unstructured, ad-hoc work – where people and documents are central. The two are complementary, but not equivalent. To prove my point, I’ll go back to my old post - no one is building social BPMS tools using BPMS - not even the BPMS vendors.

So how can Sharepoint (or any wiki) help manage meetings? Currently it is easy enough to use most wikis (or Sharepoint) to set up a shared workspace for all the participants in the meeting, and have all of the relevant documents stored in the shared workspace. That is very useful as the prelimninary step in a meeting, to make sure everyone can do their homework before the meeting. During the meeting discussions are had – and hopefully, decisions are made and tasks assigned. If it is a formal meeting, minutes are taken – if not there (hopefully) is someone that took notes and wrote down action items. The question is then what?? You can put those “action documents” in the shared workspace – but those documents are passive documents that just sit there. You can translate those into task lists  and todo lists - but that doesn’t really make it part of everyones normal workflow – they too just sit there. In Sharepoint you could program a workflow for the tasks – but that is too expensive, especially since you only know the first step of each todo or task. So what usally happens is that an email summary is sent, and in too many cases the action items and follow-up just slowly die. No wonder so many meetings have such ineffective outcomes.

That is where ActionBase’s human process management together with Sharepoint (or a wiki) can make things much more effective. By making the meeting minutes document (in Word or PDF)  or summary email an action document (or a quick meeting if you want to do it directly in Outlook). You can now link that document directly with the processes they initiated – and track them from the document itself, the shared workspace and Outlook. By making it part of the participants usual  flow in Outlook, and providing a group view in Sharepoint – meetings results are visible, they can be actively tracked and managed. The ability to link decisions with their outcome can have a huge beneficial effect on operational effiency.

Howard uses Daniel Levi’s Group Dynamics for Teams to classify different types of project oriented group communication:

It is clear that ActionBase provides lots of benefits for the “Different Place” column allowing people to continue with their email paradigm but with an layer of management and control that didn’t exist before. What may surprise people is that we are also quite heavily used for Same Time, Same Place communication- leveraging Word as a way to capture meeting minutes and resulting required actions. In Office and Sharepoint 2010 MS will also provide the infrastructure for collaborative documents creating, which will make our tool even more powerful.Our integration with SharePoint also enables us to also provide complete support for the ”Same Time, Different Place” paradigm.

So if you use MS technology (Outlook, Office and Sharpoint) rather than Google (Wave and Docs), ActionBase+Sharepoint cansimply  give you the same functionality in your environment.

• Transaction Model – Here companies use either bespoke applications, with the rules embedded in the app (e.g. CRM), or use BPM to build the app
• Integration Model – that is where BPM is most valuable, and BPM focus today.
• Expert Model - Browsers, Document repositories and  personal productivity applications are the tools available.
• Collaboration Model – This is what Human Process Management addresses. These are the unstructured, ad-hoc processes that people do everyday in email and documents, where  the overall work product is dependent on groups of knowledge workers collaborating. The fact that email reigns king for knowledge worker collaboration and coordination is show in a different chart, with knowledge workers spending about 20% of their day in email (even though the data is about 5 years old, itstill holds).

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.

Linking email to documents and process is the next “killer app” for the the enterprise – much more so than Google Wave for consumers. I guess I should be happy Microsoft isn’t doing anything since it means less competition for us here at ActionBase – but the natural approach for  Microsoft would be to build the  the platform component and let business partners like us build on top of that, so in the end we would benefit too.

So,  just like with GRC, emails and documents are the way case management work is done in the real world.  Email is far from a perfect case managment solution – but people use it because it is familiar, flexible, pervasive and  under their control.

So, as a first step, why not just enhance email as a case management tool? Later on, as actual process execution is understood, you can decide to move on to more structured tools if needed. I am not convinced that what the world needs right now is more complexity in BPMN (since even most of the current BPMN spec isn’t used). There is value to the IT community in having single standard across vendors – but it isn’t going make a dent in the use of email for case management.

In a nutshell, that is our thinking at ActionBase – lets start supporting people through tools they already use, and  in the way they really work – providing immediate value to the users and ROI to the business. Then use that as the basis for a more structured approach to case management if needed.

Enterprise collaboration and tools to support it have been mainstream for about a decade now, with portals, intranets and shared workspaces being some of the primary options IT provides to information workers specifically to support collaboration. However, at least to date, none have made a dent in displacing the primary enterprise collaboration tool for information workers: e-mail.

There are many reasons for the primacy of e-mail as a collaboration (ubiquity, familiarity, flexibility, end-user control), but in an enterprise setting, one key reason is that collaboration between information workers is usually in support of a work process. Since e-mail is also the primary tool for process execution for information workers, it makes sense that it is also the main tool for collaboration.

So even though almost every enterprise has special purpose solutions available for collaboration and process management, good old e-mail always ends up being the  primary method for both collaboration and processes in the enterprise.  This is the “dirty little secret” of enterprise collaboration and processes tools. In the enterprise, e-mail is everywhere; everyone uses it and it is the lowest common denominator that every information worker loves to hate, but couldn’t live without. Studies show e-mail is the only application  information workers use on an hourly basis. 

Google Wave is an excting new look at email. Like many other technologies that started in the consumer space, I believe it will create a real push to create enterprise tools that combine collaboration and (unstructured) process management. By building on the  familiar e-mail metaphor of ad-hoc collaboration, asynchronous messaging and responses it enables the creation of a class of  ”business email” (e.g. ActionMail in our ActionBase Human Process Managment System). The capability of  keeping track of the complete conversational context between the participants means there is no need to peruse one’s inbox to find all the relevant conversations. The context of the conversation is kept in a single place, and can be replayed when needed. In an enterprise setting, the cognitive overhead associated with the need for participants to reconstruct context when responding to an e-mail is one big factor in e-mail overload. Another benefit is that documents are always current. All the participants are always using the same version of documents – solving another enterprise issue with regular email, where finding the right version of an attached document is another factor in email overload.

Google Wave is a consumer oriented product.  The functionality is great, but to make significant inroads into the enterprise it will need to morph sigificantly. Here is my list of what would be needed:

1. Full integration with email. The functionality needs to be more tightly integrated with regular email.
2. Outlook and Office integration. Let’s face it –if you are in an enterprise you use either MS Outlook and Office as your email and documents platforms – or perhaps Lotus (and probably MS Office). If it isn’t built on those platforms, it just won’t fly in the enterprise.
3. An explicit process orientation. Enterprise collaboration usually takes place in support of a work process, and there needs to be a way to provide the process context for the collaboration (e.g. an ongoing audit, a response to an RFP, a fraud investigation). There also needs to be standard, structured ways for participants to add standard process status information (e.g. complete, declined) to the email.
4. Links to other systems. This is related to the process orientation. There needs to be a way to link with other enterprise systems (document management systems, CRM systems etc) related to the process. This also requires that there be a way to add structured data to the collaboration (for linkage to those tools).
5. Governance and security. In an enterprise setting, not everyone is equal. You need a robust governance system that understands who each user is and how much access they have, and ties into the existing access control systems.
6. Tracking and monitoring. This is both to allow the enterprise to learn from the collaborations and the process, and to enable an audit trail of the work done.
7. Robust Reporting. Enterprises need reports (and links to the BI system)  Enterprises need the ability to generate personal reports, departmental reports and executive reports from the tracking and monitoring information, which requires structured access to collaboration and process information.

Our ActionBase  6.1 announcement brings us even closer to our goal of being the enterprise  solution for collaboration and (unstructured) process management.  The biggest new feature is the ability for participants in the process to have a real-time, bird’s-eye view of the current state of the process. This new feature, along with our hierarchy model for business processes ensures process-related discussions remain associated with their original context, significantly reducing e-mail overload. ActionMail (our version collaborative e-mail) simplifies process-related search and follow-up by providing end-to-end process visibility, including all related attachments and history, as well as a full audit trail and change history of all changes made throughout the interaction between the participants. Of course, as in all our previous versions – the system provides enterprise level reporting, governance and security. All this within the familiar Microsoft Office, Outlook (and Sharepoint) environment.

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.

Not much has changed in that respect in the last 5 years. In the paper they go on to describe that one of the standard uses of spreadsheets in business is operational- which is “spreadsheets used to facilitate tracking and monitoring of workflow to support operational processes, such as a listing of open claims, unpaid invoices and other information that previously would have been retained in manual, paper file folders. These may be used to monitor and control that financial transactions are captured accurately and completely.”. They categorize these spreadsheets as low complexity, which is true, but the risk caused by these operational spreadsheets can be very high. Not only can the operational spreadsheet itself contain an error or omission – but the lack of linkage between the process described by the spreadsheet and actual process invoked can cause a process failure that can be very difficult to uncover and fix.

The linkage between operational spreadsheets and email is pervasive in business, especially in audit processes. I guess that since the focus of the whitepaper was spreadsheets it isn’t surprising that they didn’t mention the actual operational aspects of the tracking and montoring – which is done mostly through email. So the actual operational risk is not only in the spreadsheet, but also in the human processes (i.e. email) generated by the operational information in the spreadsheet. The other risk factors of spreadsheet use defined in the whitepaper. i.e. Analytical/Management Information and Financial, have received attention both from startup vendors and the academic community (e.g. the european spreadsheets risk interest group), but operational side of spreadsheet risk and its link to process risk – seem to be completely ignored.

Except by ActionBase of course

]]> http://blog.actionbase.com/spreadsheets-and-email-factors-in-operational-risk/feed 0