FOLLOW

CALL US

1-905-738-3773

 

Software Vendor Assessments Part 3: Conducting the Assessmen...

January 28, 2014 by
0 comments

What to Assess? This breakdown targets the essential factors that require attention when conducting vendor assessments for software vendors producing systems designed to work within a regulated environment. The Facility Tour Whether the vendor occupies an entire building or one floor in an office building, getting a quick tour of the premises tells you a lot about how the vendor operates.  Always make the data centre a part of your tour to see how data and documentation are being secured and stored.  Be sure to observe cleanliness and habitation practices as well, as the overall look, feel, and organizational culture will be reflective of how well they can deliver on what what they say they do. The Quality Manual Earlier we discussed that the purpose of the vendor audit is to ensure quality is built into the product.  There is no better way to start measuring this than by looking into what the vendor perceives as quality.  That is where the quality manual comes in. This can go by many names such as quality plan, quality objectives, quality directives, etc.  It is basically a document that outlines the vendor’s dedication to quality and outlines at a high level, all the actions and processes they have in place  to ensure they maintain an adequate level of quality within their software products.  …


Read More

Software Vendor Assessments Part 2: Show Me The Money!

January 20, 2014 by
0 comments

During a vendor assessment you will be asking them to produce a lot of documentation to prove that they have quality processes in place.  However, it is important to understand that simply reading their documentation that describes a process is  not enough.  That is only one part of the audit. The second part that always goes hand in hand with the documentation is proof that they are following those procedures.   If a process says that they collect metrics for training via surveys to improve performance based on feedback, then ask to see if they have those forms.  If there is a support and help desk process in place, review the logs and follow one support ticket documentation trail from the time the call came in and was entered on paper or in a system, to the point where it is resolved.  Did this status get updated through each phase of support ticket resolution? Did the ticket get resolved within the communicated timeline? Was the ticket information updated with all required details as per the SOP (Standard Operating Procedure)? A very common question asked here is “Do we need to verify every single SOP, directive, and committed statement?”  Ideally, yes. However, as always this factor depends on the risk and criticality of the software being implemented. If it has direct impact…


Read More