Once you have a ShareDo instance being used by your business, you may be asked about extending its use.

In this scenario, you may be considering what the best approach is to expand the use of ShareDo into multiple business units, across geographies or simply to more users.

This document looks at these scenarios and provides some considerations for each of the possible options.

Your current ShareDo instance

Removing the complexity of scale and networking, your current ShareDo instance can be represented like so:

You will have a user group (internal / external, or both) accessing a single instance of ShareDo that has a single database and which pushes all the reporting metrics to a single reporting database.

Now, consider the scenario where you have been asked by another group of users to allow them access to use ShareDo to manage their cases. You will be considering;

• Having a single instance of ShareDo and adding your users, their work types and processes to this instance
• Creating a new instance of ShareDo and configuring this for your users

There are some key considerations around this decision.

Scenario 1: Same Instance

If you’ve already got multiple user groups using ShareDo, you’ll know that adding a new group and even giving them their own views and worklists is a reasonably simple thing to achieve in ShareDo.

The complexity in this setup comes down to your ability to analyse the teams, roles and allocation rules for the work these users will do in the platform.

Having a good understanding of how key concepts such as Contracts and Statements of Work can be used to segregate what cases users see and interact with, how to apply permissions and configuration to different teams of users and roles and how to design workflow specific to each work type will also be key to having successful multi user group setup.

Common Questions

• Integration – what if the user groups integrate with different line of business systems?
  When a single instance is being proposed there are often questions around integration. ShareDo has been built using an adapter model, which is interchangeable at a work type level.
  What this means is that if User Group A are using SharePoint for document management and User Group B are using iManage; then this is supported. Provided you don’t need the same work types to use different document repositories then this is configurable in the platform.
  This capability extends to all integrations i.e. Finance, Document Automation, Email. Each User group can have its own setup.
   
• Authentication – what if I want to authenticate the user groups in different ways?
  The approach to authentication is like the integration question. We can configure multiple authentication providers in a single solution.
  There is a caveat here though.
  Each user group will see the option to sign in with any available mechanism. i.e. if User Group A wants to use their Azure AD to login and User Group B has a different directory, then you will need two login options, and all users will see both options.
   
• Reporting – can we both combine reporting and show separate metrics where we need to?
  Yes. Provided you use a good separation of work through the Contract and Statement of Work model that ShareDo provides then reporting can be seen both on an aggregate basis and filtered to be specific to a specific user group.

What are the advantages of this setup?

Perhaps the biggest benefit is that now that this work is all being done in the same case management product, you can create some comparisons and have some consolidated reporting. If these two departments or user groups are performing processes that are similar, then common process bottlenecks can be found; delays due to waiting for responses can be compared by client and process; teams can be restructured to share certain tasks etc.

The same applies to pieces of the process. Perhaps you have a specific approval route for new work, or a defined document approval process? Perhaps there are common case opening activities, or a time submission process? Having a single instance allows this to be shared and allows changes to the process to be made on a single system.

However, if the processes are significantly different, i.e. a high-volume, low value, automated case process vs. a low volume, high-value, manual process then the benefits of this sharing may be less. Even so, the opportunity to compare throughput and activity may hold some value.

From a configuration perspective, knowledge of processes can be shared. Perhaps the new user group needs similar workflow or notifications to the initial user group. Perhaps they have similar document templates or requirements for tag libraries. Perhaps they share approver groups, or have similar departmental allocation rules. If the rules and configuration for these areas are in a single system, perhaps owned be a single team, then there is an advantage in being able to share this knowledge and configuration.

From an IT administration perspective, this is also the simplest setup to maintain and manage. ShareDo has an inherently scalable architecture, so regardless of the number of additional users, we can scale to keep the system performant for all users.

And the disadvantages…?

From a configuration perspective, things are going to get more complex. The platform has the tools to manage this but a layer of configuration management over process changes will need to exist. Even so, a multi-group setup in a single instance is going to be more complex than having these completely separate.

Work re-allocation and assigning participants. When a user chooses to select a Case Owner, or tries to reallocate work, they are going to be presented with the ability to search across all users. Where there are regulatory restrictions on allocating work outside of a user group, there is an increased risk that a user error can be made. The disadvantage with allocating participants is double-edged.

If both user groups have work for ClientX and are able to allocate this Organisation as a client to work then this can be useful. In reporting we can see that ClientX is involved across x matters for user group A and y matters for user group B. Equally though, both users groups can make a change to the ClientX record. ShareDo supports having different attributes for an Organisation based on the work type they are involved in, but this requires planning.

In the scenario where one user group should absolutely not be able to select ClientY as a participant (i.e. because they are only a client for the other user group), then specific rules have to be put in place to stop users doing this.

Finally. At some points in time, you are going to need to upgrade or change the platform. Releasing changes is going to require co-ordination and, while downtime for these processes is not significant, it isn’t an activity that could happen during the working day. If you expand your use to more departments across global geographies, then the problem of finding a suitable slot to perform these releases becomes greater.

Scenario 2: Multiple Instances

What are the advantages of this setup?

Having multiple ShareDo instances allows them to be managed and released to separately. User groups could even be on different versions of the product (although there could be other complexities with downstream reporting systems due to this).

Additionally, the configuration is delineated. It is simple to access an instance and see only the processes that relate to that user group.

Where the use of ShareDo by an additional user group is for a proof-of-concept, or where there is a likely need for the case and task data to be removed and destroyed, then having a separate instance makes this simpler.

Where the use of ShareDo is in separate geographies, then this setup can also be useful. To allow users in each geography to access their own local instance and therefore have an improved user experience. ShareDo has deployment options where a stretched geography is required, but where there are separate groups, then the above setup can be useful.

What about the disadvantages?

The ability to re-allocate work between the users in User Group A and User Group B has been removed. You could not now restructure to create a shared pool of resources on a single system, performing tasks for both user groups.

Similarly, you can’t make a comparison of the throughput of work without adding a downstream reporting warehouse that combines data from the two ShareDo reporting solutions.

The approach above therefore hinders the ability to make continuous process improvement across departments or user groups.

From an IT Management point of view, this option also becomes increasingly more complex, with multiple instances that need monitoring and upgrading.