Documented business processes

Therefore, it is the first task of the business process owner to define which records under his area of responsibility are electronic records and which not. The best approach is to have a defined and documented business process. Then the records growing out of this process can be determined. In the next step, systems supporting the process are identified, and records in the system assessed. The business process definition will also be needed as a basis for the record risk assessment and validation activities of a system. An example on how this can be documented is given in Fig. 2. 

Seek business rales in the current actual business process, the process as documented, and rales encoded in existing software systems (from user manuals, database triggers, and batch mainframe programs see Chapter 17, How to Reverse-Engineer Types). Restate these business rules in terms of the following (in descending order of preference) ... 

Context model A document describing the business processes whereby a component is used. 

Figures 3 and 4 illustrate how a biennial document review process and document processing cycle time metrics faltered in their early stages due to lack of process ownership, definition, and management review. This situation presented a compliance risk to the organization and resulted in poor business efficiencies. Improve-...

Gensinger, Gary, MBA, Director, Regulatory Review Support Staff, Office of Business Process Support Standards and Successful Document Creation... 

Diagrammatic representation of business processes implemented within information system, e. maintenance management, change control, document management, etc. 

Following on from the URS, a system definition consisting of Functional Design Specification (FDS) needs to be collated. The URS does not necessarily specify the chosen MRP II system, and if this is the case, the FDS will need to introduce and overview the selected MRP II system. The FDS will define the URS business processes at a transaction level. Referenced documentation published by the supplier defining the standard MRP II software product and its functionahty should be retained and maintained with the current version of the MRP II software used. It is important to identify those functions of the standard MRP II system that are used and specifically document which functions are not being used. 

Once defined, the business process transactions can be configured within the development environment of the MRP II system. There are normally instances when it is easier to amend the business process to fit the standard functionahty of the MRP II product software than to make a customized bespoke modification. Any bespoke modiflcations, like the interfaces, must be fuhy documented in design specifications, test speciflcations, and test records. One important aspect to avoid during configuration is to set up the system to accept default user entries. There have been several recalls within the pharmaceutical industry because users failed to recognize that a default entry on their MRP II systems was incorrect. It is always a good idea to have positive user confirmation of key data entry or decision points. If defaults are stih required then make them... 

The completed FDS should be verihed that it is consistent within itself and with SOPs implementing the business process transactions, and that it fulhlls the requirements of the URS. The activity is often referred to as a Design Review (DR) or Design Qualihcation (DQ). The use of a requirements traceability matrix (RTM) should be considered to demonstrate how URS elements are addressed in the functional specihcation and design documentation. This RTM can later be extended to trace test specihcations and results. 

The user site should ensure that the scope of validation reflects the actual use of the system by the end users, and not just the intended use documented. For example, an off-the-shelf warehouse application may contain functionality developed to meet the requirements of many different companies and so could actually contain far more functionality than is actually required by the end users from one particular company. Users may select this functionality if they believe that it provides them with additional features that would enhance their business processes in preference to the intended documented usage that the organization intends to validate. Such functionality should be disabled, or users should be expressly prohibited from using this alternative functionality through SOPs and training. 

The User Requirements Specification (URS) for any system is typically written by the business community (users) and describes what the system is intended to do. This is a key factor for consideration in any system validation determination as it should indicate whether the business process the system is intended to support has a regulatory impact. The requirements outlined in the final URS document will subsequently be tested by user qualification. 

In addition to the main document, a number of additional guidance documents have been published during recent years. These include an article in Pharmaceutical Engineeringf about a risk-based approach to computer validation. The article starts from the risk assessment given in GAMP 4 and provides a model for a system risk assessment based on the risk level of the business process supported by the system and the system vulnerability. As an outcome of this assessment, it summarizes which validation activities are appropriate for which risk level. 

Often enough hybrid systems are legacy systems, specifically systems not supporting electronic signatures. In these cases, it is very important to define either in the system documentation and/or in procedures, the business process, and use of the records. This includes the purposes for which both records are used and also the interfaces between paper and electronic system. Table 2 illustrates an example of the use of a hybrid system. 

For every company, this means that a strict separation is needed between business convenience for internal processes and required signatures as listed in Table 7. Only for the latter case, the respective Part 11 requirements apply. Nevertheless, the signature functionality may be used to control critical parts or tasks of business processes. But it has to be clearly documented either in the system specifications... 

In Sect. 5.7 we argued that current tool support in chemical engineering does not consider the overall design process. This situation is due to the fact that tools are provided by different vendors, that they are based on heterogeneous system platforms, proprietary document formats, and different conceptual models of the application domain. The same holds true for the area of business process support [31, 45, 210] as IT landscapes of companies are typically characterized by a portfolio of heterogeneous business application systems. ... 

WS8] BPMI. 2002. BPML 1.0 specification, http //www.bpmi.org/bpml-spec.htm [WS9] OASIS. 2005. Web Services Business Process Execution Language Version 2.0. http / / www. oasis-open, org / committees/documents. php wg abbrev=wsbpel... 

Conduct "business as usual" but replace some of the paper (e.g., records, documents and procedures) that people use during their daily work. This will enable people to work paper-like on computers with little impact on the company s business processes. Less paper should mean fewer people to run the business but only marginally in this case. There may also be less data entry and hence fewer data errors. 

IS refers to the software packages and databases that provide the functionality to implement the business processes. These include such packages as Enterprise Resource Planning (ERP), Manufacturing Execution Systems (MES), Electronic Document Management Systems (EDMS) and Maintenance Management Systems. 

The definition of a business process produces the need to report information through a document, database or any other format. These "documents" are windows onto the information resources of the organization and should be structured into... 

Procedures are controlled instructions for implementing specific business processes. Clearly they are an information resource in themselves and have a life cycle as a document, usually textual, but capable with an advanced IT infrastructure of incorporating audio and video dips to aid their explanation and operational use. 

For purposes of understanding the business and documenting the business model, it is useful to organize the business processes into categories ... 

---