Controlling document changes in Solution Manager

[philip_kisloff]

In this series of blogs, I'll discuss a way it is possible to introduce change control for documents in Solution Manager. Good governance of project documentation is a fundamental underpinning of change control in regulated industries such as ethical pharmaceuticals ("Big Pharma"), but observance of its mandated requirements needn't be an exorbitant overhead.

In this first blog, I'll describe the cascade model, and describe how versioning of documents together with electronic sign-off is the essential aim. To achieve this objective, there are three steps to take, all blogged separately as all show some aspect that can be used independently for lesser requirements.

Blog 2: Adding a unique identifier to Solution Manger document attributes

Blog 3. Introducing a release strategy with electronic signatures for signed out documents

Blog 4. Solution Documentation: Automatically attaching a new version number to the document after release



Fig 1: The V-model of computer validation

In so-called regulated industries such as ethical pharmaceuticals regulated by the FDA, there's a methodical, by-the-numbers approach to any changes to a qualified computer systems such as those licensed from SAP. Even if drug manufacture is not used in the system, simply being part of the corporate infrastructure means its strictures need to be observed.

The classical V-model or "cascade" approach has to be observed, and each stage signed off. After an initial scoping, the User Requirements (URS) have to be established, then these are broken down into function specification (FS) documents and from these any additional developments spawned are written up as system design specifications (SDS).

After development, the changes are tested against the signed off SDS, and so up up the other side of the V-model. Importantly, documents must have a new version that spells out the deltas that are to be tested. Don't start testing before the document has been signed off, and for heaven's sake don't test against the wrong version, otherwise it's all invalid and has to be repeated. It's not so difficult with the odd few changes, but in large teams across multiple overlapping areas with tight deadlines, things tend to grind to a halt pretty quickly.

With the scene set, the first thing needed in solution manager is something to link all the disparate documents to a change. I call this the Program Management Office reference ID (PMOID), a unique number that the PMO assigns every change request brought before it and approves, and is then used to collect all development  and testing documents for tracking into Production. Something similar would be used by every change approval panel I would expect.

In the next blog, describe how to add this PMOID to Solution Manager document attributes.