Getting your EDMS in place
You have gone through all the steps to pick your Electronic Document Management System (EDMS), whether it is Quality Documents, Trial Master File, Regulatory Submissions. You justified the business case with all the benefits of having it:
- Single source of record
- Document life-cycle management
- Version control for improved compliance
- Standardized process and procedures
You picked your technology vendor, and identified your business stakeholders. Now what?
If you do your homework and planning beforehand, the chances of your project getting delayed, derailed, or dismissed are lessened. I am outlining here some prerequisites that we have learned working with our clients across many of these projects.
Steps to EDMS Implementation Success
- Start by taking a look at your business. Determine what can realistically be accomplished and absorbed by your team. New technologies are by nature disruptive, and most people don’t appreciate radical changes unless they’re heavily invested in the outcome. In my experience, things go wrong when the implementation is too much, too quickly. When implementing an eTMF, plan what study or studies will be the first to use the new system and involve the study manager and study team members.
- Involve the right participants at the start of the project. Building the right team from the get-go is critical. At the very least, you need one team member who is knowledgeable about the business unit implementing the system. That critical member also needs to be willing to embrace new technology and be an advocate for the system. Using someone from inside the business, for example a Regulatory SME for a Submission system, helps achieve the buy in needed as well as leveraging their knowledge throughout the process
- Map and define the processes that are currently in use by the business. Fully documenting and mapping your current processes will allow you, first and foremost, to identify important segments that need to remain intact. Mapping, among others, your essential document collection process and TMF maintenance, or submission processes is the best way to ensure emulate accepted processes as much as possible. Secondly, defining your current system will point out the inefficiencies or broken procedures the new system can replace or fix. If these hang around, they are a risk to your success.
- Clearly define any procedural differences. These can occur with good reason, such as regional, or special uses like inspection support and corrective action responses. You’ll want to clearly outline what those procedural differences will be (and you know these because? You mapped your current state!). When it comes to change management and communication, clarity and transparency of alterations from the accepted norm makes user training and adoption and a smooth go-live much more likely.
- Harmonize naming conventions. It is amazing how many different ways there are to name the same thing, even within the same functions. This aspect is often overlooked in planning and when it is uncovered in the course of the project (and it will be!), there are delays for the discussions and decisions needed. Ensuring everyone is reading from the same page will greatly enhance the customer experience once the documents are migrated into the system.
Side note here: This might be easier than you think, you may have already used “ability to use industry standards” (e.g. DIA Reference Model for eTMF) in your requirements and vendor selection. Use standards whenever possible!
- Decide on a transition strategy. What documents are you migrating? What is the cut-off point? Most companies will pick a date range of what will migrate in the first wave of implementation, whether that be “all documents from the last year” or “all documents created today forward”. You’ll need to decide what will transition and when to cause the least disturbance to your day-to-day operations while capitalizing on the new functionality provided by the EDMS.
- Audit your documents. Now that you have an idea of which documents are coming over, do you know where all those documents are? It’s not enough to have a strategy and migration rules, you also need to know where each document is migrating from. Mapping these out in advance reduces effort required for the migration.
Admittedly, this is a sample of everything you would do with your project and maybe you have already thought these things through, but if I am able to help someone with this advice, I’ve been successful. Too often we have seen where these types of implementation projects go much longer than they should have, simply because some of the above were not considered from the start. Looking back at those projects, they did provide some lessons learned that we can share, but that is a blog for another time.