Andrew Doble's Blog: SaaS Design Principle: Socialize the Process

This is the third post in a series on SaaS design principles. This post follows on from the principle described here.

In a typical enterprise, users make a business process work in spite of the applications they are using by:

Warning other users downstream in the process of problems that are coming their way.
Asking users upstream in the process as to why something has happened.
Collaborating with each other to solve problems.
Seeking out who can give them advice, or giving advice themselves.

Traditionally this is done using media outside of the application (telephone , email, walking down the corridor etc.), reducing business efficiency.

However, many users are using cloud products to organize their own social life - for instance: using Facebook to arrange meetings, using Google Docs to set up club fixtures, sharing calendars with their spouse. As such they are expecting to see these types of facilities in the application that they use at work. This also has business advantages, especially when viewed in the light of how businesses are run these days:

Processes are becoming more automated, meaning the users tend to only see those cases that are difficult and cannot be handled by the automatic process. This leads to a collaborative problem solving approach.
More users are working from different locations using mobile devices. As such, they lack to usual means of communicating with their colleagues.
More processes are being run across different companies, different geographies and different time zones. As such it can be difficult to know who to contact when an issue is raised.
More customers are looking to interact directly with a company using a wide range of devices and platforms (and for many e-mail is history and post is a fossilized dinosaur). End customers are effectively becoming users, in that they interact directly with the business processes.

As such cloud based applications have to build in what Geoffrey Moore has called Systems of Engagement. Typically, many in enterprise IT are mired in the system of records mindset which has been the dominant model for enterprise IT in the last decades. However, as Geoffrey Moore says:

“...the thing to register about systems of record is that they are mostly and largely complete, particularly within larger organizations. Are they perfect? No. But these systems of record are no longer a source of competitive differentiation for organizations. They are a necessary condition of doing business.”

Systems of engagement however :

"... begin with a focus on communications. ... These communication capabilities will also be complemented with new collaboration capabilities."

This leads us to our next design principle for SaaS architecting:

Users involved in a process should be able to communicate with one another.

And here “users” are also customers and partners as well as the typical staff member.

As to be expected, this has implications for the design of SaaS applications. Rather than just using basic communication services, architects of such systems should carefully think about:

How collaboration can be made effective by integrating the social features with the actual processes (for example, setting the context of a chat or collaboration around a business entity such as a specific customer, a specific product, or a particular process etc.)?
How users communicate with one another?
How can the user base contribute to best practices, for instance by assigning user generated content (a typical hallmark of social aware applications) to process steps? This can also provide valuable feedback on how the application could be approved.
How to identify and contact the experts you can turn to for advice.