The SharePoint Conference 2011 in Anaheim, CA, USA is over. 7500 IT professionals and users (approx. 1/3 of the participants had a business profile!) attended some 250 sessions in 3,5 days.

Here are my personal takeaways.

Project Server 2010

Brilliant product built on SharePoint 2010 (‘you can’t have one without the other’); includes portfolio management from request gathering over portfolio selection based on business objectives, all the way to planning and execution; integration with Team Foundation Server for progress follow-up, even in an Agile Development scenario; integrated Business Intelligence (one of the reasons why it requires the Enterprise Edition of SharePoint).

Here are the titles of some Project Server sessions:

- Microsoft Project and Project Server 2010 Overview

- Best Practices for Deploying Project Server 2010 on SharePoint Farm

- Leverage Project 2010 with Office 365 for Project Management Success

- SharePoint Lifecycle Management Solution with Project Server

- Solving Agile and PMO Problems by Integrating Project Server 2010 with Team Foundation Server 2010

 

SharePoint and Social Computing

Inspiring ideas on how to combine tagging of content on one hand, and search or content query web parts to display content in various contexts (who has contributed, to which services/products content applies, etc.) on the other. Aka: ‘Taxonomy based content targeting’.

Technical deep-dive in Claims-based authentication to use e.g. Facebook credentials to filter content on your SharePoint site. Very powerful.

In many sessions Microsoft demonstrated how they ‘eat their own dog food’.

Some session titles that should get you interested:

- More Than My: How Microsoft is driving social adoption and intranet change through shared services

- Integrating Social Networks into SharePoint Internet Sites

 

Content Management

Various sessions talked about how to analyze and structure content in SharePoint (no surprise). Some sessions were very business oriented (‘Document Management – Planning For Success’) and others very technical (‘The Nuts and Bolts of Managing Enterprise Content Types At Scale’ or ‘Creating an Easy To Use File Plan Builder for Your SharePoint Records Center’).

I personally appreciated very much the sessions presented by Susan Hanley, co-author of the book ‘Essential SharePoint 2010’. in one session she talked about measuring the value of your SharePoint 2010 investments. And believe me, it was not a high-level, theoretical talk about ROI and alike: it was a very convincing talk about ‘serious anecdotes’ and users who say ‘”Don’t take it away”.

Her second presentation was all about ‘a practical approach to SharePoint Governance’. Again full of tips you can start using tomorrow (or today?). You can read it all in her book.

 

Check it out

All the content of the conference is available on the web site of the  SharePoint Conference 2011.

Intro

If you have been modeling processes for a while, you have probably experienced the situations where nothing seems to work. Suddenly, when discussing a particular process with your audience, your tips and tricks don’t work anymore. And you think “What’s wrong with me?” or “What’s wrong with these people?”.

Here is a potential answer: may be there’s something wrong with the process!

More and more voices are stating that not all processes can be captured as fixed, pre-defined flows. Some processes, mostly characterized as ‘knowledge worker processes’ have an inherent flexibility that cannot be described with traditional BPM techniques.

 

How to distinguish between an adaptive and an prescriptive process

First question that popped up in my mind was: “How can I recognize these processes when I’m discussing them with my customer?” (Because I don’t want to run into problems again.) I found a potential answer in Jacob P. Ukelson’s chapter of the book ‘Mastering the Unpredictable’ (Meghan-Kiffer Press, ISBN 978-0-929652-12-2, www.masteringtheunpredictable.com ). Here is my transcript of his ideas. I now use this frequently to check the type of process I am dealing with; it consists of a set of statements in 6 categories of characteristics of a process:

Type of interaction:

- The activities of the process mainly entail interactions with IT applications to capture information and data, without much interaction with other people.

- The activities of the process mainly entail human interactions (e.g. to ask for assistance, collaboration, or to negotiate).

Type of information:

- In the process mainly structured data is filled out on formatted (electronic) forms.

- In the process mainly documents, excel files and other unstructured information is created or received and processed.

Type of control:

- After the completion of an activity in the process, the system decides what the next (prescribed) step is.

- The actors in the follow decide on the next step based on the information they have.

Type of ownership:

- The process has a process owner who decides on the standard (prescribed) flow.

- Every instance of the process has an owner who can decide on the flow, deliverables and timing for that instance.

Type of objective:

- The objectives, time line and deliverables are defined once for all instances of the process.

- The objectives, time line and deliverables are defined separately for every instance of the process.

Type of process description:

- The process documentation describes how the process’s deliverables should be produced.

- The process is described by defining what the outcome of the process should be.

 

Before starting a discussion on a process, I ask my audience to score each statement of the 6 categories on a scale of 1 to 5, where 1 = ‘I agree completely with the first statement’ and 5=’I agree completely with the second statement”. The answers give me an indication like “This is more of an adaptive type of process” or “This is more of a prescriptive type of process.” (I made a simple Excel file that, magically, comes up with the conclusion after you filled out the answers).

 

How does this help?

First of all it helps me during the process modeling to adapt my style of modeling: it doesn’t make sense to try to force the users to define a predefined process flow when you are dealing with an ‘adaptive’ process. In an adaptive process the possible activities may be known, but the sequence in which they occur cannot be defined in advance. (In many cases not even all activities can be identified upfront.) So for adaptive processes, the process model should say: these are the possible actions (activities), but it is up to the actor to decide what to do next.

Secondly, it also helps to define requirements for the underlying ICT systems. It the past, traditional ICT has neglected processes and process support as a basic requirement (see also the article ‘BPM Misconception: the back-end database doesn’t need to know everything’ that was published in the Architect Newsletter of Microsoft Belgium), and more recently you see that BPM is concentrating on “prescriptive” flows and is neglecting the “adaptive” processes. This is all the more surprising because tools like Microsoft’s SharePoint are ideal to support adaptive processes. If collaboration tools like SharePoint would be integrated more in the traditional software applications (e.g. by creating automatically a workspace or a case for every instance of an adaptive process) users would get a much better support during the execution of the process. I will come back to that in another blog post.

 

 

For more information: communication@spikes.be

What is Task Assignment?

Task Assignment (aka Role Resolvement) is the mechanism that decides ‘at run-time’ to which user a work flow task should be assigned. It is an essential part of every process engine. If the process defines that a request needs to be approved by the Head of Procurement, then the Task Assignment Mechanism will try to find at run-time a user with the role ‘Head of Procurement’ and assign the approval task to that person. And if that person is on holiday at that moment, then the Task Assignment function may even look up his replacement, and assign the task to that person.

In more technical terms therefore the Task Assignment mechanism is a set of rules, policies and trimmers executed by a rule engine to decide which user is the right person to execute a task at a given moment in time.

 

Why is Task Assignment important?

Take the example of an Expense Report Approval Flow. The flow will probably state that the expense note needs to be approved first by the Head of Department of the employee who submitted the expense note, and secondly by the Accounting Clerk. Without a Task Assignment function, the logic to determine which Head of Department needs to approve the expense note would have to be modeled in the process flow itself. In a simple organization with 3 Departments, that might look like this:

It is obvious that in a more complex organization (and which organization isn’t?) this is not a workable solution.

When you are modeling for a workflow environment with Task Assignment, the same process would look like this:

 

In a process modeling project, everyone focuses mainly on the process flow and les (or not at all) on the allocation of human resources to the steps in the workflow. That may be OK, until the moment you really want to execute the process in a workflow or process engine.

Conclusion: Task Assignment is important because it allows you to keep the logic

to assign a task to the right user outside your process flow by defining it in a separate set of business rules and policies.

 

You can do more with Task Assignment Rules

Another reason for adopting a process engine with a Task Assignment function is that you can do so much more with it.

Imagine a Task Assignment function that would balance the work load automatically over the available resources. Or that would include resources from other departments during peek hours. Or that follows a different logic in emergency cases (when availability of resources is much more important) than in normal cases (when delays are acceptable).

With a rule-based Task Assignment function, you can adopt different scenarios, depending on the context of the workflow. And none of it would influence the clarity of your process model.

 

Tools

Many commercial workflow or process engines ignore to a large extent the importance of resources and task allocation. And although that may be acceptable for simple workflows, it will become a major problem once you want to automate real business processes.

SharePoint’s workflow engine doesn’t have a Task Assignment function. That is why Spikes have developed such a mechanism as part of the SpikesTogether product, to operate on top of workflows in SharePoint. For more information: communication@spikes.be

There are (too) many words for describing the digital sharing and processing of documents and other types of content. ‘Document Management’ is one that is often used. What flavors does it have? (And yes, they can all be implemented with SharePoint).

 

 

Portals & Collaboration

Portals & Collaboration refers to the single entrance (‘portal’) that people get to loads of information. It also refers to the unstructured, loosely defined collaboration they can set up using the portal. ‘Collaboration’ refers to the fact that the way in which people work together on documents is not organized in a formal way. Who is allowed to add content, modify it, etc. can be configured by using the authorization mechanisms that are available. But the sequence of events who is supposed to do what and at which moment is not formally defined. Collaboration therefore equals communication without formally defined rules.

Still there are various mechanisms (also all available in SharePoint) to ‘collaborate’:

- Centrally stored documents that can be accessed – and modified – by authorized users (using a check-out/check-in mechanism or not)

- Wiki’s to share knowledge

- Discussion Groups

- Announcements

- Task Lists

- Team Sites

 

Content Management (incl. Case Management)

Content Management is a different ball game. It almost the opposite of collaboration in the sense that here the way in which content is managed is as structured as possible. The whole life cycle of each document type is analyzed and defined, and finally implemented: who can create content, who should review added or modified content, who should approve the added or modified content before it can be published, etc.

Content Management without versioning is inconceivable. Content Management without workflow is hardly conceivable (see next chapter).

A special form of Content Management is Case Management. Where most people think of individual documents or single items of content when they talk about Content Management, Case Management is about sets of documents (files, dossiers, cases whatever you call them). In Case Management the same principles of structured content creation, review and approval apply to sets of documents (aka ‘Cases’).

And yes, you can implement Case Management with SharePoint too.

 

Workflow

Workflow is the mechanism that is used to automate the processes related to documents and other types of content. The content reviews and approvals that are mentioned in the previous chapter can be fully automated with workflows.

By automating workflows, you take away the risk that the prescribed way of working is not followed. People can make mistakes. People can forget. Or you can forget to train people to work in the correct way. When procedures are really important (e.g. for compliance or liability reasons) it can be very helpful to automate the process by means of workflows.

Tip: before you start implementing workflows: read our blogs about Process Modeling.

 

(Self-service) Business Intelligence

Why write about Business Intelligence (BI) in the context of Document Management?

First of all, because a Portal is the perfect place to publish your reports and figures, especially when they take the shape of dashboards and scorecards.

Secondly because reports can be considered to be ‘content’ like documents, having similar properties: collaboration, meta-data, life cycle, authorizations, etc.

So why not take advantage of the platform you already have to make the right version of your reports available to the right people at the right time?

The possibilities of BI in SharePoint are countless, and yet most people don’t even know about it.

 

Digital Archive

What is the relationship between a Digital Archive and Content Management? The content Life cycle!

One of the simplest rules in Content Management is: what gets in, must get out! For each type of document, and therefore for each document, you must know when it is going to be removed from your content database at the moment you add it to it! Sounds impossible? Can be done!

And because people don’t like to throw away things, or because the legislator or compliance committee may demand that you keep record of specific types of documents, you need a (digital) archive to store documents that are no longer ‘active’.

In the archive, your content starts a second life that eventually ends with the permanent deletion of the content.

The key concept here is: content life cycle management!

 

… and CRM?

This may seem like an odd one. What is the relationship between CRM and Content Management?

 

Document Management is about collaboration. Collaboration is about communication. Organizations communicate with their external contacts more and more through portals in stead of through e-mail. By sharing documents on a portal with customers, partners, members, etc. the communication becomes so much more efficient: everyone shares the same version of a document, everyone can modify that version (if authorized) and so on.

CRM is about keeping track of your contacts and of the touch points you have with those contacts. So if you want to keep control over your touch points with customers and other external parties, it does make sense to integrate your CRM with your content management.

 

Contact

If you want to hear more about projects we realized in this context, or want to learn how this may apply to your organization, don’t hesitate to contact me or the company:

- marc.vanderheyden@spikes.be

- communication@spikes.be

 

Introduction

Automating workflows is becoming more and more popular (and I’m, of course, glad for that). Every workflow implementation project starts with documenting the underlying business process. (I am not going to elaborate on the definition of workflow and process here, that is a subject for a separate blog.) The big question is: how should I document my business process to provide the right input for the workflow project.

This blog entry is part of a series of blog entries on the basics of process modeling. In fact this post gives the overview of what was already published, or what is still to come. (Yes, I agree, this is nothing more than a list of subjects I could blog about, but maybe you can find some information in it too. In the mean time, subscribe to this blog … and wait for the rest to come.)

 

The Basics

Categories of processes: management, core, supporting

BPM (Business Process Management) traditionally makes the distinction between Management, Core and Supporting Processes. What are they, and is the distinction relevant to process modeling?

Levels of the Process Model

One of the most important rules for achieving readable, usable process diagrams is to model the right level of detail at the right place. This can be realized a.o. by defining different levels in your process model.

Two crucial definitions: what is an activity, what is a trigger?

Business processes are about information that is flowing between people (the process actors) and that is enriched in each process step. This blog post offers very clear definitions for the flows and for the process steps.

Process boundaries: where does it start, when does it end

You have probably also seen these wall covering process diagrams that try to describe everything in one diagram. Are they readable? Do they identify the business process correctly? Probably not. So how can you delimit process in a correct way?

Roles and functions

The actors in a process are people in a specific role. But people have also functions (by the look of their business cards). How do you deal with that in a process model?

Not just a picture: document it!

Many people only think of diagrams when they talk about a process model. And although a picture tells a 1000 words, they may be 200 words from 5 different people. One way to take away the ambiguity of the process diagram is to a text.

Yes you may bend the rules!

Every business process documentation project has its specific objectives. And although it is important to respect some rules when modeling processes, you must also see to it that the model serves the objectives. Bend it!

 

Extras

What are Management Processes??

Many people will argue that management cannot be captured in processes (mainly managers will say that). Maybe they are right. But that doesn’t mean that management processes don’t exist. Here are some examples of management processes that are useful to document.

2 Kinds of Supporting processes?

Although BPM only talks about Supporting Processes, I see at least 2 kinds: Core-supporting & Supporting-supporting (I couldn’t find a better name – every suggestion is welcome.) What are they?

Process modeling tools

My father-in-law used to say: the right tool is half the work done. Which tools are on the market to support the process modeler?

Process modeling with Visio and SharePoint

About a year ago I would have rejected Microsoft Office as an acceptable tool for processing modeling. But since the release of Visio 2010 and SharePoint 2010 I changed my mind: today they are my favorite tools for modeling processes.

What is a workflow, what is a process?

The words workflow and process are used as synonyms. But do they mean the same thing?

 

Advanced

Triggers: formalized communication versus informal

The glue of processes are the triggers: they make activities, and processes, stick together. They represent the information that flows between people. But which communication should be modeled and which not?

Triggers: time trigger!

When modeling processes, many people ignore the most common trigger to start a process: time!

Something on process flexibility

Process models give the impression that every process nicely follows the prescribed path that is described in the diagram. But in reality, processes need to be much more flexibility.

Process performance: measuring quantity and quality

Process modeling and process performance stich together like birds of a feather. How can implementing processes help to measure process performance?

From Process to Workflow

Business Process and Workflow: the same thing … or not?

 

The implementation of Digital Business Processes

Something on process engines

What is the role of a process engine when implementing Digital Business Processes?

Task Assignment

aka Role Resolvement: is the mechanism that assigns process steps (tasks) to the right user at run-time. If your process engine doesn’t support Role Resolvement, then you’re bound to include the assignment logic in you process model. And believe, you don’t want to do that. Read more about this topic here.

What does it mean for the user?

The whole picture: a process steps is a workflow step is a task on a task list

The relation between a digital archive and content management, not clear to everyone

Many organizations talk about digitalizing their (paper) archive. But how does that affect their content management?

Most Content Management environments in organizations are designed in a 1-dimensional way, with 1 structure, 1 taxonomy, 1 set of properties etc. A kind of ‘one size fits all’ approach. That surprises me.

Every piece of content has one or more authors or ‘Writers’ and one or (hopefully) more ‘Readers’. Wouldn’t it be normal then to design the Content Management environment from at least 2 perspectives: the Writer’s view on the content and the Reader’s view?

Let’s take the example of procedural documents (see previous blog post for the distinction between procedural and operational documents). Procedural documents are typically written by a few Writers (e.g. from the HR, Safety, QC or Risk departments) and have an audience of many readers (all employees, or all employees of 1 department, etc.). The Writers probably want to structure their documents from their perspective, which could be process-based, or risk-based or topic-based. The Readers on the other hand want to be able to access the documents in the working context in which they need to get informed: a call center agent will look for information based on a request from a customer, a branch officer will look for information about a specific product, etc. It is obvious that the authors’ perspective is not necessarily the same as the readers’ perspective. In fact in almost all cases they are different.

Why do we continue to design 1-dimensional content management structures in which Writers and Readers are forced to think in the same structures?

I guess that this way of thinking is deeply rooted in our brain because of the long history of classifying and storing paper documents in paper files on one hand, and the somewhat shorter history of filing electronic documents in a Windows file system on the other. The biggest limitation of both filing systems being that you can only create 1 hierarchical structure that needs to be used by everyone. (The work-around was, and sometimes still is, to file different copies of a document in different folders or cabinets.  Needless to say that such an approach creates more problems than it solves…)

The fact is that today you don’t have to think in 1 dimension anymore! Content Management systems like Microsoft’s SharePoint for instance offer you the possibility to create different views on the same information, allowing you to satisfy the needs of both Writers and Readers.

So here is the tip: the next time you want to structure information in your content management system, first ask yourself who is creating the content (the Writers) and who is using it (the Readers), and talk with them separately to understand their needs; then design your structure(s) accordingly.

Many organizations have implemented a Document Management Systems (DMS). But that doesn’t mean that documents are now more integrated in the line-of-business applications than before. What is your strategy to integrate document flows in your ICT Architecture?

The problem is that, although documents are the most common information carriers in many organizations, they lead a separate life at a fair distance from transactional systems and even more from the process-based applications, if they exist. As a consequence the information worker, in his day-to-day job, has to joggle and switch between applications like the transactional systems he is using, the DMS and his e-mail in- and outbox. Compare this to having a car to drive on flat roads, a SUV for driving up- and down-hill and a little truck to go to the supermarket, without the possibility to drive your car on mountainous roads, the SUV on flat roads, or load any kind of groceries in your car or SUV: how practical would that be?

What is needed is an understanding of the relationship between documents and business processes, and documents and transactional data. This bog post explores those relationships.

A Classification of Documents

The distinction that I would like to make here between very different types of documents stems from the distinction that is commonly made between different classes of business processes. Every book on Business Process Management will tell you that there are 3 fundamentally different types of business processes in every organization: Core Processes, Supporting Processes and Management Processes. Core Processes are the processes in your organization that deliver to your (external) end-customer (typically the Marketing and Sales Processes, Production, Delivery, etc.). Support Processes are the processes that deliver to internal customers (e.g. HR, Finance, and ICT processes). Management Processes deal with reviewing and setting the direction and objectives of the organization, defining how the organization should operate, and controlling the execution.

Now let’s get back to the reason for existence of the early DMS: the documents stored in the DMS have long been the output of the Management Processes in an organization. They are the type of documents that describe how the organization should work. That means that they contain meta-information on the organization, not operational information. Let’s call them Procedural Documents. Compare e.g. a document containing the procedure for approving offers with a document containing the offer itself. The first one describes how the process should be executed, the second one contains information on (1 instance of) the process itself. Let’s call the latter Operational or Process Documents.

Again this distinction is very important because it leads to 2 different sets of requirements when it comes to supporting the underlying processes in the life cycle of these documents. Whereas a DMS was used mainly for procedural documents so far, it is used more and more for operational documents.

Operational Documents and the Information Worker

An Information Worker typically uses mainly Outlook (or another mail client) and Office in his/her day-to-day job. The mails themselves and the attachment in those mails are increasingly operational documents that used to be sent on paper by snail mail (you know, in the era when animals could talk).

Whereas before there was no real need to integrate Outlook/Office with the DMS for the procedural documents, this integration is becoming more and more essential to the productivity of the Information Worker: how easy is it to save an e-mail in the DMS or to save the attachments of the e-mail in the DMS. And ideally, the act of saving an e-mail or an attachment to the DMS should trigger the right workflow to get things moving. (But that will be the content of a next post: the difference between workflows for procedural documents and for operational documents). The message of this blog post is: it’s time to get the work of the Information Workers organized and make it more productive by integrating 2 worlds of work: Office tools (including the mail client) and the DMS.

(Guess what: that type of integration is one of the big innovative improvements of Microsoft Office 2010, SharePoint 2010, e.a. … but that’s again a subject for a different blog post.)

The Integrated Information Worker World

So the ideal information worker’s world looks more or less like this:

- The IW saves e-mails and documents from his/her Outlook client to the DMS

- By saving the document in the DMS, a workflow is triggered

- A step in the workflow may trigger transactions in the back-end system (*)

- When a workflow step is completed, the next step is added to the task list of the IW, who will receive an e-mail notification in his Outlook client.

(*) See also the article ‘The back-end database doesn’t need to know everything’

When designing true process-based applications, a first step in the right direction is use the correct definition level of ‘the business process’. In this blog post I will concentrate on human processes, i.e. the type of business processes in which people interact with each other and with applications to produce some work.  This topic is really is critical when you want to automate your business processes: if you don’t get the definition of your business process right, your design of the (human-) process-based application will fail.

You can find many definitions of a business process on the web. Most of them are valid. For the sake of simplicity, I use the following definition to highlight those parts that, in my experience, are crucial for the issues discussed in his article:

“A Business Process is a series of logically related activities or tasks performed by different actors and executed together to produce a defined set of results. “

For the design of a process-based application it is important to start from the right definition level of the process. In my definition the “performed by different actors” indicates this level. If 2 or more consecutive steps in your process flow are executed by the same person, you are probably modeling task steps at work instruction level instead of at process level. If 1 step in your process flow represents work executed by different actors, then you are probably modeling at a too high level.

Consider the following example:

 

In step 1, the call center agent may have to look up customer details first, and then look for previous orders of the customer before he/she can finally start entering the price request details. These different task steps are not reflected in the process flow because they don’t belong there.

Also this whole ‘Price Quotation Process’ could be just 1 step in a higher-level process flow called ‘Sales Process’ (other steps at that level could be ‘Sales Order Process’, ‘Invoicing Process’, etc).

To conclude this entry:

When designing a process-based application, make sure to start from the right definition level of your business process, i.e. the level where each step is executed by a different person. (In most cases this means that your process flow has swim lanes with a role in each swim lane to identify the people in the organization authorized to execute the activities in the swim lane.)