1. Business Requirements
Establish the business requirements as a clear goal for your project and speak to all the departments across all locations and facilities in the organisation to get an indication on how many employees need access. One of my early projects during business requirements discovery the number of employees needing access increased to 115 from an initial 15 and fortunately the architecture scaled easily for the multi-site distribution of employees.
Be very clear about what you are trying to solve with each requirement and ensure that each stakeholder has had a chance to provide their list of requirements. At a recent project, it became apparent one of the biggest issues a majority of employees were having was needing information locked in a system they had no access to. This led to either using inaccurate or out of date information, or using inefficient methods to access the information through someone with a license. Management hadn’t provided access because the licenses were considered expensive and weren’t aware of the impact the work around methods were having on the organisation.
Prioritise the requirements with your project team and base the order on importance, technical complexity, risk and cost to implement. At a project where we were asked to provide a solution to standardise the handling of proprietary formulas within an organisation, several steps leading up to the conception of these formulas needed to be in place prior to work starting on the actual formulas themselves.
2. Current Information Locations
Identify all existing locations where information is stored including documents in file shares and file syncing services like Dropbox and OneDrive, databases including financial, service & CRM information and portals. A quick way to get a concise list is to ask finance for details on the software subscriptions and maintenance they pay or have paid in the past.
Establish the current and annual volume increase as well as types of information stored e.g Proposals, Invoices, Drawings, Customer Service Tickets etc… Modern ECMs like M-Files utilise compression and binary delta algorithms to efficiently store versions of documents, so your annual volume increase for migrated repositories will be considerably less. The site admin at one of my projects stated that after moving to M-Files where the chance of duplication and multiple versions of files was essentially wiped out, they went from network share storage increasing by 1TB per year to the M-Files vault only increasing by 50GB per year.
Determine which of these repositories need to remain in operation and which could be migrated into your ECM and be retired. We usually migrate things like legacy access databases that perform simple tasks like providing unique identifiers (e.g. batch numbers) to the ECM so it then provides the batch number as part of a workflow. You may have situations where it’s critical to preserve a legacy repository like a customer portal that allows service tickets to be raised. Its content can still be made available in the ECM for search capabilities and other purposes while its original functionality is preserved.
3. Security Requirements
Review the current levels of security within each repository that that will be accessed via the ECM and map them to one of the scenarios in the table below. The credentials used to access the external repository will be determined by the type of access specified for the connection. As an example, providing public access to Supplier and Customer lists may be necessary for all users in the ECM as this information is useful as metadata for other objects, whereas you may want to limit access to project related data to only the people in the project team. We often provide ‘metadata-driven’ permissions on project based data by including ‘project team’ metadata with the project so security access can be easily managed by the client.
The scenarios to consider when providing access to a repository via an ECM can be split into several categories:
Public
A common authentication is used to connect to the external repository, the ECM then controls access to the content via its internal security e.g Public Network Share
Public with Varying Permissions
Users and groups in the ECM are mapped to users and groups in the external repository to control access to specific content e.g Network Share with ACL restrictions to certain groups
User-Specific
The external repository dictates access rights requiring the ECM users to log into the repository with their own credentials e.g. SharePoint
4. Hosting Requirements
Determine if the system will be hosted on-premise, in the cloud or a hybrid to enable planning for hardware, review of service agreements with cloud providers or both. We’ve found to avoid delay in starting projects, development can be done on cloud servers during the process of hardware procurement and deployment, and then transferred once the on-premise environment is ready. It’s also quick and very easy to change cloud server specs to increase performance if needed.
Use the current volume plus expected annual volume increase values (from step 2) to determine what sort of backend the ECM requires as well as to establish storage and backup requirements. M-Files recommend using the embedded database option (Firebird) up to 50,000 objects and Microsoft SQL Server once that has been exceeded. If using Microsoft SQL Server, you also have the option of storing the file data within the database or as separate files. There are pros and cons that I’ll go through in another blog.
Size the hardware based on the number of employees and volume of data to be stored (from step 2), use the business requirements (from step 1) to help. Identify how connection will be made to each external repository (local or cloud) so connectivity can be determined either directly or whether a VPN is required. Where connectivity is difficult, it may be feasible to maintain a local copy that’s refreshed periodically or use technology that provides these capabilities.
5. Access Requirements
Establish the landscape for how employees will access the ECM keeping in mind it will become the central point to reference the connected external repositories. Most ECMs support access through Windows Desktop clients, Web Access and Mobile clients. If the ECM will be available externally, securing access via SSL or VPN is critical. On most of our M-Files deployments, our clients not only want access to M-Files via their mobile phone, but also on their laptops from anywhere! We use their SSL certificate (required for mobile access) and setup what’s called ‘HTTP over RPC’ so their M-Files Desktop Client connects securely whenever an internet connection is present. If you want to know more about setting up HTTP over RPC for M-Files, contact us.
Some ECMs support replication strategies where servers can be hosted in multiple locations and cache or replicate from a central location to provide efficient access to information. We’ve delivered successful projects where M-Files outperformed SharePoint when deployed to a customer’s remote locations as ‘cache’ servers that connect back to the main M-Files server via hardware based VPNs over 3G links. Consideration needs to be given to the technologies available to help meet access requirements.
For more information on M-Files contact us
