Building a Smart Laboratory 2018


volunteers who are committed to the concept of the system, enthused about the improvements it can bring, and are able to envision the potential. Unfortunately, the committee process can create complex systems and reflect compromises, and it is oſten the case that most problems come from people who don’t volunteer for the committee! By definition, the members of the team are more committed to the success of the project than those who are not directly involved. In their deliberations, project teams oſten develop a concept of a solution that is much more sophisticated than might be needed or, indeed, is economically justifiable. Typically the requirement-gathering phase


involves harvesting needs, wants and ideas from the potential user community, and then engaging in a prioritisation exercise to reduce the list to a specific set of requirements that form the basis of a request for proposal (RPF) to be presented to vendors. It is important that the business requirements


are fully clarified first of all; this ensures that the scope of the project is defined and can therefore help exclude some of the more exotic ‘needs’ that might arise. Any single item on the requirements list should justify itself not only financially, but also in terms of its usefulness and ease of use. Anecdotal experience suggests that some


requirements specifications could be shrunk by between 25 and 50 per cent by the removal of ‘wish list’ items – bringing cost-savings and lower cost of ownership, as well as easier user adoption. It is important for the project team and sponsors to be able to define what business problem the electronic laboratory notebook (ELN) will solve, and to ensure that user requirements are kept simple and are focused on solving the problem. Te formal RFI and RFP approaches can


only go so far, and it is essential that candidate systems be demonstrated and assessed with some preliminary configuration to establish and evaluate not only whether the system meets the functional requirements, but also whether it provides an acceptable user experience. In some respects, it makes sense to consider functional requirements and user requirements as separate criteria.


Business case development and project management


Building a good business case requires a thorough and systematic approach to understanding current limitations as well as future requirements for the business. It is important to see laboratory informatics as a component in a laboratory ecosystem (technology, processes and people), rather than ‘just another laboratory application’. Te following points should all be considered in formulating the case for a new informatics system.


www.scientific-computing.com/BASL2018


Why do we need a new system? n What is the problem that needs to be solved? n Is there any quantitative data that illustrates the problem?


n Which laboratory areas will be involved in the project?


n Who makes the go/no-go decision? n What are the issues relating to IP (internal/legal/ patent)? and


n Are there any regulatory compliance requirements?


Clarify why the organisation thinks it needs a new system. Tis is best achieved by developing a problem statement that quantifies a specific problem, or set of problems, about the laboratory’s productivity and/or knowledge management performance. Te scope and scale of the problem (and


hence, the solution) should be identified. Te key


Practical considerations


n Are there any specific policies an restraints relating to the introduction of ITsystems?


Establish how the laboratory is currently working, paying specific attention to the use and effectiveness of manual systems such as worksheets, paper lab notebooks, and data management. Also identify major ‘electronic’ systems used for the acquisition, processing and management of data, and ask what happens to this data – where is it stored and for how long? Is it communicated or transferred elsewhere – if so, how? Is it backed up and/or archived? Can it be found? Is laboratory data the responsibility of the


laboratory, or does IT have any involvement? What level of involvement does IT have in the purchase and implementation of laboratory systems?


Building a good business case requires a thorough and systematic approach to understanding current limitations as well as future requirements for the business


“


decision-makers/budget-holders should also be identified, plus any other interested party who may have influence over a go/no-go decision. It is important to know what business level constraints may apply in terms of internal, legal or regulatory compliance.


Laboratory/company background n Use organisation charts to clarify roles and responsibilities and organisational relationships;


n Identify the nature and scientific disciplines of the laboratory work and how they relate to each other; and


n Establish whether outsourced agencies (contract labs) are involved?


Establish the way in which the laboratory is organised, the nature of the work it undertakes and how it relates to internal and external organisations with whom it collaborates.


Current laboratory processes and systems n Which laboratory systems are already in use? (Are there SOPs?)


n Which data acquisition systems are already in use?


n Which teamwork/collaboration systems are already in use?


n Which document management systems are already in use?


n Who is responsible for the management and support of these systems?


n Is there a (electronic) records management policy? and


Future laboratory processes and systems n Based on interviews with laboratory managers and laboratory staff, a model should be developed to illustrate the major relationships between laboratory data and information;


n Construct data workflow and laboratory process diagrams;


n Identify any conflicts in nomenclature and establish an agreed taxonomy;


n Identify the role (scope and scale) of existing laboratory systems in the model and diagrams; and


n Test the model and diagrams against each of the laboratory areas and other interested parties (IT, legal, QA, records management).


A high-level plan, showing the relationships, processes and data flows that describe a future state for the laboratory, should be developed. Tis should include an identified role for each of the laboratory systems and should clarify the specific functions of each. Any problems with laboratory terminology should be resolved. Te plan should be tested by presentation and discussion with the interested parties.


Business plan development n Quantify the benefits of the proposal, in particular productivity gains, ROI and knowledge management, and support these estimates with case studies;


37


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44