The GCDOCS Problematic – What are we trying to solve?
The French theoretician Louis Althusser always insisted that it was not individual answers, but the questions to which the answers were given, that define the value of a solution. It is clear that we have all accepted GCDOCS as an “answer” – but to what problem?
At first glance it seems obvious; we all expect GCDOCS to provide a solution to the problem of “Electronic Document and Records Management” (EDRM) in the Federal Government. But there are two very different ways to define EDRM, and these two definitions can lead to radically different implementations of the system.
1) “The problem is that shared drives and other document management systems do not have the ability to do records management or sophisticated ‘google like’ searching. Solving EDRM therefore means getting a system with the technical capability to manage, retain and dispose of information resources.”
Does GCDOCS have the features required to do EDRM? Absolutely. It comes with a sophisticated document management module including versioning, facets, and search, as well as a records management module designed for retention and disposition of electronic and physical objects. But this is where the danger sneaks in – just because a system can do something, does not mean it will do so automatically, or even do it with ease. If your GCDOCS implementation is not explicitly set up to do records and document management from the moment users start entering content, it will be extremely difficult, if not impossible to reverse engineer it later on.
2) “The problem is that shared drives and other document management systems have not been architected to deal with records and document management needs. While these old systems lack key technical capabilities, the fundamental problem is the lack of system management and consistency. Solving EDRM therefore refers to the actual planning and architecting of a system to manage, retain and dispose of information resources.”
The more robust definition of EDRM does not only comprise technical capability, but also the planning and architecture of that capability. Despite the excellent upgrades to technology, we must not let the bells and whistles distract us from the true opportunity GCDOCS is offering: the chance to once and for all classify and manage our electronic information in a consistent and sustainable way.
Problems define the scope of the answers. If we are dealing with the wrong set of problems, our answers will always come up short in the face of our realities. The problem of EDRM in the Federal Government is not a technology problem, it is a problem of planning and architecture. Don’t get caught in the trap of substituting a feature for a fundamental issue, or expecting your GCDOCS solution to deal with all of your problems out of the box. The tool is new and changing but the old adage rings true in the end: “what you put in is what you get out”.
March 12th, 2014 at 9:22 am
Hi Jason,
great text and true.
I’m information officer at PWGSC and you’re touching the only significant point of the question: we are implementing a tool without changing the mentality.
Why don’t your company offer a training/consulting/project before implementing GCDocs, preparing the government departments to do so?
I’m trying in my group to have IM participating in every new project start to help define how new documents will be organized, saved and managed before they are created.
If the culture don’t change, we will have what you just mentioned, we will continue getting garbage from our data repositories and we will continue lost in the middle of tons of inutile data.
You have a clear and concise vision of things. Not usual.
Thanks
Douglas
May 20th, 2014 at 2:40 pm
Hi Douglas,
Thanks for the comment. Your point about the primacy of culture change is absolutely correct, although it’s certainly not an easy thing to bring about. I think that, in addition to a strong information architecture, it requires a combination of IM best practice, change management, and a consideration of usability and the user’s perspective of the system. Systemscope has offered a number of workshops (at ARMA IM Days and other venues) in the past on GCDOCS preparedness that address exactly these issues – we will strongly consider your suggestion about further pursuing this topic.
Thanks very much!
-Jason
June 4th, 2014 at 10:21 am
Hello Jason,
I recently join the IM team in ESDC department. I amnew in the field and would like to know more about GCdocs.
Could you please let me know where can I find documentation, reference and training on this tool.
Thanks.
M.
June 23rd, 2014 at 8:07 am
Hi M.,
The GCDOCS page on GCPedia should give you a good start: (http://www.gcpedia.gc.ca/wiki/GCDOCS). *This link only works within a GC network
The Canada School of Public Service offers courses in GCDOCS fundamentals that you will have access to as a GC employee (some costs apply): (http://www.csps-efpc.gc.ca/BrowseCoursesBySubject/gcdocs-eng.aspx).
Another good source for materials relating to GCDOCS, and other matters IM, is in the IM listserv, which you can sign up for through the Treasury Board Secretariat: (http://www.tbs-sct.gc.ca/im-gi/imc-cgi/listserv-eng.asp)
And of course you should also contact the IM team within your department.
Hope this helps!
-Jason
May 5th, 2016 at 10:43 pm
Hello everyone
We could change the title to RDIMS, EDRMS and now GCDOCS problematics.
RDIMS and EDRMS where not successful in helping manage unstructured information up to now 2016 and GCDOCS will not succeed in the future because no one understands that all these systems are actually 2 software that must work collaboratively to be able to capture, organise, manage, use and then dispose. Lets look at it this way: RDIMS is a Records and a Document Information Management system, an EDRMS is an Electronic Document management System and a Records Management System. They collaborate when the official file plan folders are setup in the Records Management System and that the retention and disposition instructions are attached to the file plan folders to manage the life cycle of the folders. Then you must give access to the creators of the information to these folders by administrating the file plan access rights sections. At This point the creator of information should be able to work from the Document management System to save the electronic documents that will be captured, organised in the file plan folders. Client and the creators of the information can now save, use and protect the documents, then the system will manage the information for as long as they have value, as identified in the retention schedule attached to the folders in the Records Management tool and then disposed of them with the help of the system administrator. This is a very simple explanation of how these software’s work. If you find this explanation difficult to understand, then you begin to understand why it is difficult to successfully implement an RDIMS, EDRMS and or a GCDOCS.
Go for it you can do it
Guy
May 9th, 2016 at 2:30 pm
Hello Guy, thanks so much for the comments! I think fundamentally GCDOCS, RDIMS, SharePoint etc can all be considered either an EDRMS or simply just a DMS, depending on how they are architected. It is very possible, as you suggest, to treat one system as simply a document management tool and to link it through metadata and business processes to another system which would take care of the records management component. On the other hand, these systems are capable of handling both the DM and the RM in themselves- GCDOCS included. I have been on projects that scoped both the operation DM and records management entirely within GCDOCS. Ultimately it depends on how you architect the tool – but the functionality is certainly there!
May 31st, 2016 at 6:48 pm
Hello Jason, I agree that all these systems are just DMS when they don’t have RM functions set up. But why is the RM so difficult to setup and implement? The answer is in the culture, just like Douglas and Denise mention. The RDIMS, EDRMS and now GCDOCS problematics is related to culture change not software or hardware. When RDIMS by Opentext was introduced in the 1990’s it was capable of handling both the DM and the RM but no one setup the RM functions so the software was blamed. This inspired the 2nd generation called eDocs by Opentext called(EDRMS)and now we blame EDRMS because the RM was not setup again and now we will setup RM in GCDOCS by Opentext but will it be accepted by the users? I ask this because the reason for not setting up RM in RDIMS and EDRMS was because RM functions force clients to do their work and then apply records management best practices when they save information resources into these systems and now it’s GCDOCS turn.
July 13th, 2016 at 11:29 am
Hello Jason,
I would like to know if GCDocs is accessible to persons with disabilities, especially those using Adaptive Technologies? (screen reader, screen magnifier, voice recognition…)
Thanks
Technical Advisor
Accessibility Centre of Excellence.
ESDC
September 28th, 2016 at 3:37 pm
Hi Anne, you can probe the accessibility of GCDOCS (Content Server 10.5) at the Content Server webpage below from OpenText:
http://www.opentext.com/file_source/OpenText/en_US/PDF/OpenText_Content_Server_10.5_VPAT.pdf
September 28th, 2016 at 3:25 pm
Hi Jason,
I am a project manager at Statscan and we are currently reviewing the information management systems we are using and trying to decide which is best and would be compatible with GCDOCS once it’s implemented. I currently use SharePoint as my project site and as well as my information management system. I get IT guys telling me that I should use confluence and JIRA and put my documents on a shared drive while we wait to see what happens with GCDOCS. I don’t agree, I would like to continue to use SharePoint for everything as I have read it is compatible with GCDOCS. That the transfer of information would be easier. Also, shared drives are so time consuming and there are no search capabilities. What do you think?
Thanks Deborah
September 28th, 2016 at 3:35 pm
Hi Deborah, thanks for the question. I think that the transition to GCDOCS from other systems is always going to be tricky. I think staying with your current processes and systems is a safer approach than doing any sort of pre-emptive migration unless you are explicitly required to do so. I often think that the effort spent on “transition” methods (like prepping a Shared Drive or changing systems in expectation) often entails a lot of work for a very limited set of results, which are temporary to boot. Very often I have seen GCDOCS implementations take the “day forward” approach to side-step the issues of having to migrate legacy documents – this entails only migrating information to GCDOCS if it is directly relevant to work going forward, while leaving the rest of the legacy information in a read-only format on the old systems.
Be cautious about assuming what is and is not compatible with GCDOCS. While there are connector tools that allow for information within SharePoint to be migrated to GCDOCS, it is quite complex to architect and is not without its share of difficulties. I would not assume that the approach your department is taking will encompass the use of such tools.
December 9th, 2016 at 2:52 pm
As I read through the comments based on Jason’s article, the key ingredient missing is understanding filing systems. In my career in the federal parliament and non-profit sector, staff regardless of their degrees, do not have the basics. They do not know how to manage files. Ask how many filing systems are there, very few people can answer. There are basically 7. Regardless of technology, understanding filing systems (I was a trained secretary/administrative assistant/medical administrator), if the basics are not there, every thing is thrown into the filing cabinet in a pile! Try separating your pile of clean clothes from soiled ones and one piece of clothing needs to be retrieved in an emergency, you will be searching for a long time!!
Thank you Jason. Let us go back to some of the basics.
January 23rd, 2017 at 9:39 am
This is a very good analogy! The trick is to get everyone to feel a certain level of responsibility for the information they are creating on behalf of their community. Technology is secondary to attitude and basics, I agree.
January 23rd, 2017 at 9:15 am
Can you save a PDF in GCDocs
Thank you
January 23rd, 2017 at 9:36 am
Yes, you can save almost any kind of electronic information in GCDOCS.
June 29th, 2017 at 8:57 am
I am new to IM can you provide a document that explains how GCDOCS works.
Thanks
July 11th, 2017 at 8:05 am
Hi Francine, there are a number of documents available but if you have access to GCPEDIA, I think this page might be a good place to start:
http://www.gcpedia.gc.ca/wiki/GCDOCS_EPMO
September 27th, 2017 at 9:53 am
I am working in the GOC and we are currently looking at migrating our GCDOCS and RDIMS document repository’s over to Documentum. It was determined that while RDIMS has been life cycled CS (GCDOCS) does not meet our functional requirements (i.e. no forced save option etc..etc..) and the migration from RDIMS to GCDOCS leaves broken links everywhere. So after Content World this year the push is now on to migrate both GCDOCS and RDIMS to Documentum… While I know other Departments are looking at it does anyone have migration scripts or real world experiencing making the switch?
November 20th, 2019 at 9:19 am
We will be moving to GCDOCS very soon. I have a few MS Access databases on my government shared drive that have a front end (Forms, Queries, Reports, Macros) and back end (MS Access tables). In other words, the front end sits on the users desktop and the back-end tables sit on the network drive allowing multiple people to have the front end and update the tables in the back end (the front end connects to the back-end). I have heard that, since GCDOCS is itself a database, it cannot handle storing Access databases or making connections from an Access front end to an Access back-end. There will likely be no easy option (such as moving the tables to an SQLserver) available to us. If it is true that GCDOCS is incompatible with MS Access in this way, this means we need to leave those on a network drive, which defeats the purpose. I would really love to know if there is a solution to this problem here, as Access is very helpful for our data input and reporting needs.