August 16, 2012

Recreating the Wheel

Posted in IT tagged , , , , , at 1:22 PM by Solutions2Projects, LLC

I love documentation and I won’t apologize for it.  Documentation saves time and leaves space to think through the tough issues. 

In IT, documentation is often a four letter word because documentation  isn’t as much fun as playing with technology.  I understand this. 

But, how often have you had to rethink a process or fumble through something that you haven’t done in a while?  How much time was spent on this that could have been reduced if there had been a specification document or work instruction?  What about when key personnel leave and they take their knowledge with them?

Recently I worked with a client on a system that I hadn’t touched in over two years.  Fortunately, I had documented the process and had a work instruction for it and was able to quickly answer the question and address the issue.  If I hadn’t, we would have had to contact support, wait on hold to get through two to three levels of support to get to the answer.  This was assuming it was during the right support hours. 

Another client is struggling to recreate processes performed by technical personnel who have left the company. And, because it was a small IT department, this person was solely responsible for performing some technical tasks and didn’t write anything down.  We are now in the process of starting from scratch to figure out how to get the work done with, of course, a very short timeline. 

The extra time it takes during an initial project implementation to document the system, configuration, and work instructions is less expensive and less time consuming in the long run and not nearly as painful as one might expect.  The documentation doesn’t  have to be formal or complicated; it just needs to impart the necessary information so that others do not have to recreate the wheel.

Advertisements

January 30, 2012

IT Policies to Establish Control

Posted in IT tagged , , , , , at 7:33 AM by Solutions2Projects, LLC

When we at Solutions2Projects are brought into a biotech or medical device company to work for the first time, it is usually to provide selection or implementation services for the first big IT project.  The companies are usually positioning themselves for an IPO and need greater control over their financial transactions or are preparing for commercialization and therefore need a system for inventory management or manufacturing.  In both cases, the companies need policies and procedures for managing these systems once in place. 

 Over the years we have identified the following as the minimum policies that need to be in place once the system is released into production.  If the system is a GxP system and is being validated, the policies are verified as part of the validation process. 

  • Change control / change management
  • Operation and maintenance
  • Security
  • Passwords
  • Backup and restoration
  • Deviation management

 Having these policies in place (and adhering to them) provides IT personnel, affected system users, and business owners with a foundation for control.  For GxP systems, FDA has been known to hand out 483’s for GxP systems that were not controlled from inception.  Think about it.  If you are basing a submission on data from a system that was not under control from inception, how can you demonstrate data integrity and data reliability?  Getting the systems under control from the beginning reduces the system and data integrity risks. 

 Of course, the policies need to be followed.  There’s no point in creating policies and ignoring them.  IT needs to embrace these policies to be successful.  Getting IT involved in the generation and release of these policies increases the likelihood of adoption and success. And the policies need to be in a centralized location for all affected personnel to access (not just IT).  This is generally handled by Quality Assurance (QA) as they are used to document management.  If a training program is in place for GxP documents, these should be incorporated into the training program as well.  

 For each system, there will be procedures to define how the policy requirements are met.  A few examples include

  • the periodic review of users and access
  • instructions for performing test restorations and verifications
  • periodic maintenance activities for the system (technical, application)
  • periodic review of failed logins

 Each system will require different instructions for accessing the data or performing the tasks.  The procedures or work instructions allow the IT personnel to focus on the data or value-added activity and not struggle with how to get the data or perform the task.  This is especially true for activities that are performed infrequently, like annual restoration tests. 

 The policies and procedures can be expanded on over time.  Initially, enough details need to be included to meet compliance requirements and provide affected personnel with guidance to achieve the desired level of control. 

 I understand that ‘control’ is a four letter word to a lot of IT folks.  But, control reduces risk and increases data integrity and reliability, which is what IT is tasked with ensuring.  Compliance (SOX, GxP) mandates establishing control over these systems, and policies and procedures are one of the tools companies can use to satisfy the requirement.