![Agenda ,[object Object],[object Object],[object Object],[object Object],© International Institute of Business Analysis](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Contenu connexe
Dernier
Dernier (20)
En vedette
En vedette (20)
Being a BA in Biopharma and CROs 2012_01_23
- 1. IIBA ® Pharma/Biotech SIG Monthly Webinar Being a BA within Pharma/Biotech vs. within a CRO 23 Jan 2012 Connie Cotter & James Blay, Covance
- 9. Being a Business Analyst in Biopharma and CROs Connie Cotter, Senior Business Analyst Jim Blay, Senior Business Analyst Covance
- 32. IIBA ® Pharma/Biotech SIG Monthly Webinar Being a BA within Pharma/Biotech vs. within a CRO 23 Jan 2012 Connie Cotter & James Blay, Covance
Notes de l'éditeur
- Connie Cotter is a Senior Business Analyst with 15 years of proven skills and experience in gathering, analyzing, and documenting business and functional requirements; identifying solutions; reviewing and improving processes; administrating projects; and leading and training people. She has direct analytical and business consulting experience in various industries, such as clinical research, insurance, higher education, state government, and pharmaceuticals. Connie specializes in effective group facilitation for requirements elicitation and the creation of complete and accurate documentation of business and functional requirements. Jim Blay is a Senior Business Analyst with 21 years of experience within Biopharma IT. He has been with Covance since June 2011 where he is responsible for requirements elicitation, requirements management, solution recommendation, and enterprise analysis for the Discovery & Translational Services business unit. Prior to joining Covance, he spent 20 years with Eli Lilly and Company where he specialized in business analysis, portfolio management, project management, IT strategy & planning, software selection and enterprise-scale, global software configuration and implementation.
- Jim
- Jim
- Jim Goal … NOT an exhaustive accounting of similarities and differences Rather … first-hand experiences from two BA practitioners … Being a BA style Review the 3 objectives for our presentation
- Jim Review definitions as we are using the terms
- Jim Cover a bit about Covance One of the largest and most comprehensive drug development services companies Annual revenue greater than $2 billion 11,000 employees globally Business Areas: NONCLINICAL DEVELOPMENT Toxicology Research Products Analytical Services Discovery & Translational Services CLINICAL DEVELOPMENT Clinical Pharmacology Clinical Trials Central Labs PERIAPPROVAL & MARKET ACCESS
- Jim How are we using the term?
- Jim First we want to differentiate two types of business analysis that we have identified within our group here at Covance We are breaking out these 2 into different positions: Enterprise Analysts … we are in the process of creating a unique position for this These senior roles are focused on a given business unit and report to the business unit IT director TRANSITION: These roles are distinct from project level business analyst roles, which Connie will now talk about…
- Connie This area of business analysis is more specific with a definite end result (a completed project of the defined delivery/ solution). Interaction is with the subject-matter experts – generally members from the business that will be (or represent) the end users of the solution. The business analyst focused on gathering and documenting the requirements, specific to the project and the management of those requirements, throughout the project. We will be talking about elicitation, documentation and management of requirements next in this presentation. There may be opportunities to work with the SMEs to define or modify business processes to support the solution delivered by the project. End result is generally called deployment or implementation. This area of analysis is where the BA gets their start. Entry level BAs can learn the BA and project methodologies under the guidance and mentoring from more senior business analysts. The junior level BAs begin doing some of the BA project tasks – again with oversight by a senior BA. The Senior-level BA can be the lead on a project, when multiple BAs are assigned. The Senior BA, if alone on the project, would be responsible for all of the project tasks relative to BA activities.
- Connie Here’s a list of Business Analysis practices that generally fall into the project-based analysis we just talked about. Let’s take a look at each of these in a bit more detail to understand the purpose and ways to accomplish each one.
- Connie Elicitation of requirements is the first major activity after a Business Analysis has been assigned to a project. Taken from Requirements.com (http://www.requirements.com/Glossary/RequirementsElicitation/tabid/109/Default.aspx) The Business Analyst must first have a comprehensive and accurate understanding for the project’s business need – before eliciting requirements. This will help during the elicitation activities to identify the correct stakeholders to involve, the elicitation techniques to use and also to avoid scope creep or the gathering of “gold plating” requirements (those requirements that really are “nice-to-have” and not critical to the success of the project. The identification of the correct stakeholders is important, these individuals will depend on the business need for the project. If the system or organization is regulated, the regulating agency will be a good stakeholder to include in the elicitation activities. The stakeholder is someone with a key interest in the project – consider other business groups or functional areas that may interact with the identified business need. For global organizations trying to harmonize processes and systems, it is important to have SMEs from the various locations so that all sites have input into the business requirements and ultimate solution. This also provides opportunity for the sites to learn about business processes in the other locations – which can lead to overall process improvement. Similarly with cross-functional projects, representatives from all of the affected areas will provide valuable input into the elicitation of the requirements. Even with a single business system, it may be helpful to ask, “as a result of this project, who/what group will be providing and/or receiving information from this system.” There are many ways to gather the requirements from the SMEs; depending on scope of the project, location of SMEs, and time available. Common elicitation methods, as identified by BABOK, which I have used are listed here. There are many more. Interviews: One-on-one interviews are among the most popular types of requirements elicitation, and for good reason: they give an analyst the opportunity to discuss in-depth a stakeholder’s thoughts and get his or her perspective on the business need and the feasibility of potential solutions. One drawback with interviewing, if the BA discovers conflicting requirements, additional follow-up will be needed to bring consensus among the SMEs. Document Analysis: Document analysis involves gathering and reviewing all existing documentation that is pertinent to your business objective or that may hold data related to a relevant solution. In other words, virtually anything that is written related to the project may be useful. This type of elicitation is especially useful when the goal is to update an existing system or when the understanding of an existing system will enhance a new system. This can be a time-consuming task. It can give you a start, but will not likely provide all the requirements needed for your project. Observation (job shadowing): Observation is quite helpful when considering a project that will change or enhance current processes. According to BABOK, two basic types of observation are available to an analyst: (1) passive observation, where the analyst merely watches someone working but does not interrupt or engage the worker in any way, and (2) active observation, where an analyst asks questions throughout the process to be sure she understands and even attempts portions of the work. I prefer the active observation (asking questions) as it helps to ensure clear understanding of the process and requirements. Prototyping: Prototyping is especially valuable for stakeholders such as business owners and end users who may not understand all of the technical aspects of requirements, but will better relate to a visual representation of the end product. I have found Use Cases to be very effective by telling the “story” of the system–user interaction. The business SMEs can describe how they expect to interact with the system, from which the requirements can be determined. Workshops: To be successful, requirements workshops must include a recorder (or scribe) to record participants’ input, and a facilitator to direct the discussion. Workshops are very effective because all participants hear the same information and can respond immediately and learn from one another. My experience is 2-4 hour sessions in a short time frame are most effective, everyone gets into a flow of understanding and progress is made. Sessions less than 2 hours or weeks apart, tend to require more time in that just when progress is starting to be made the session is over OR the participants need to be “reminded” of the progress if the time between sessions is too long. It is good practice with all techniques to share notes with SMEs after the sessions to ensure there are no misunderstandings. TRANSITION: after gathering the requirements from the various stakeholders and SMEs, it’s time to capture that information (documentation).
- Connie Dictionary.com defines documentation as Computers . manuals, listings, diagrams, and other hard- or soft-copy written and graphic materials that describe the use, operation, maintenance, or design of software or hardware. The initial collection and development of requirements can use the forms listed here. Software tools like Rational RequisitePro, Rational DOORS, CaseComplete. Excel spreadsheets, SharePoint lists, Access databases, etc. Ultimately, in my experience, there a MS-word document (as a minimum). The objective of the Business Requirements Document is to provide a clear, complete and concise definition of requirements which supports: · The business agreement as defined in the Project Charter for signoff by the Project Sponsor; · The information needed for the subsequent systems analysis, design and development work; and · The foundation for user acceptance testing and signoff of the completed project. Adapted from KLR Consulting, Inc. (http://www.klr.com/articles/Articles_BA_DocumentingBusinessRequirements.pdf) The requirements document should be written using easily understood business terminology – since the business/ users are agreeing to the provided requirements. In my experience, we use template for the requirements document so each project documents the same type of information. Our templates contain sections with the following information: Purpose, Glossary of Terms, References Assumptions, Dependencies, Risks, and Out of Scope items Business Rules Use Cases Requirements (regulatory, site-specific, interfaces, functionality, design constraints, and non-functional requirements, such as, database, infrastructure, security, performance) Approval can be electronic or pen/ink. Our organization does not support electronic signatures of requirements documents – we still gather the wet ink signatures. The approval and sign-off solidifies the scope and objectives of the requirements so the development team can proceed; having a set of requirements that have been reviewed by the key stakeholders for the project. The approval also signifies the stakeholders/project sponsors are willing to provide the time, resources, and money to continue. TRANSITION: Jim will tell us about the practice of requirements validation.
- Jim Validation of gathered and documented requirements is a critical step Ideally, validation should occur prior to document signature, but often times is left until the requirements document is being circulated. This results in validation being rushed and performed inadequately. When rushed, it leaves little time for adequate review of comments and driving consensus amongst all stakeholders as to what the true requirements are. While this step is common across industries, there is a complexity unique to CROs. This results from stakeholders that are both within the CRO as well as within the sponsor companies. Often times sponsors/customers have their own unique requirements which must be reconciled and validated with other sponsors/customers as well as with those of internal stakeholders. The importance of client confidentiality makes this a delicate but yet important step. All the more reason to start this early and to leave plenty of time in the project plan for validation! TRANSITION: And now Connie will tell us about Requirements Management…
- Connie Requirements management is a not a single task within a project. It on-going from the start through the end of the project. From Wikipedia (http://en.wikipedia.org/wiki/Requirements_management) Requirements management begins with the analysis and elicitation of the objectives and constraints of the organization. Requirements management further encompasses planning for requirements, integrating requirements and the organization (identifying the attributes for requirements), as well as relationships with other information against requirements, and changes for requirements. Requirements management involves communication between the project team members and stakeholders, and adjustment to requirements changes throughout the course of the project. To prevent one class of requirements from overriding another, constant communication among members of the development team is critical. The “communication” of requirements changes should be contained in documented format – to maintain a record of the requested change, date, by whom, reason for request, and result (approval or denial for the change). Requirements traceability is concerned with documenting the life of a requirement. It should be possible to trace back to the origin of each requirement. Every change made to the requirement should therefore be documented in order to achieve traceability. Requirements come from different sources. Using requirements traceability, an implemented feature can be traced back to the person or group that wanted it during the requirements elicitation . This can, for example, be used during the development process to prioritize the requirement, determining how valuable the requirement is to a specific user. It can also be used after the deployment when analysis shows that a feature is not used, to see why it was required in the first place. Listed are a few tools that can be used in requirements management. Req Mgmt Plan - The Requirements Management Plan details the attributes to be used to classify requirements and the procedure to be followed for change control of requirements identified during the course of the project. Traceability Matrix - The purpose of the Traceability Matrix is to identify how requirements are related to other software development deliverables within the CUSLC. The matrix will allow for linkage to requirements, design, and testing efforts (Req ID, Req Text, Design ID, Test ID) Software Tools – a Google search provides a long list of Requirements Management Tools Contour: J2EE-based requirements management tool by Jama Software Dimensions RM: Requirements Management Tool by Serena Software. Own description: "Dimensions RM from Serena — robust requirements management software for global collaboration, requirement change management, requirements reuse, and requirements traceability." DOORS: Requirements Management Tool by IBM (formerly by Telelogic). Own description: "IBM Rational DOORS is a requirements management tool that helps increase quality, improve requirements communication, collaboration, and verification across the enterprise." Requisite Pro: Requirements Management Tool by IBM (formerly Rational). Own description: "Rational RequisitePro is a requirements management and use-case writing tool to help improve communication and traceability, enhance collaborative development, and integrate requirements throughout the lifecycle." Analyst Pro: Software Requirements Tool by Goda Software Own description: "An Advanced Requirements and Lifecycle Management Software" TRANSITION: I’ll hand it over to Jim to talk about the last of the analysis practices – Solution Selection and Implementation
- Jim The final steps in the business analysis process are Solution Selection and Solution Implementation. These are the next logical steps beyond requirements We have the requirements … Now what? Solution Selection Assist with the business process definition … How will we use the new system? Requirements also logically lead to user acceptance testing … How do we know it meets our requirements? What level of testing is required? Validated or non-validated system? I have a question for you. Do business analysts own these activities? Solution Assessment and Validation, which is what I’ve called Selection , is covered by the BABOK, but what about business process design and testing (I call this Implementation )? It isn’t specifically covered by the BABOK. That makes it technically outside of the realm of business analysis. However, the question remains. Who owns these activities? What role does the BA play? Are they fully accountable for completing them? Do they simply move into a role as an assistant while others drive them? Do they provide leadership but work with other technical roles such as architects, developers, test leads, etc.? Do they merely consult while other roles take over leadership? The truth is … I’m not sure there’s one right answer. I’ve seen it done many different ways. I have seen that these typically fall onto the Business Analyst by default, but that they are often working closely with other roles to achieve them. I have another question. Within IT, do we call the positions Business Analysts or Business Systems Analysts ? I’ve seen both. In my experience, regardless of the exactly role from a RACI perspective, the BA/BSA is critical to both solution selection and implementation regardless of the organization
- Jim We’ve covered the major Business Analysis practices as well as the similarities and differences between applying these practices within biopharma vs CRO. Now we’d like to focus in on a few key requirement content areas that are unique to the biopharmaceutical sector. There will be similarities and differences to how these are approached between biopharma companies and CROs. We’ll look at: REGULATORY COMPLIANCE SECURITY CONFIDENTIALITY BUSINESS MODEL TRANSITION: And now I’ll turn it over to Connie to start this section off with a look at Regulatory Compliance.
- Connie The systems being developed or purchased and implemented in your organizations may need to comply with regulating organizations and national laws. There are government and nongovernment authorities that are responsible for the oversight of the effectiveness, safety, manufacture, and distribution of medicines. Biopharm may develop and seek approval of drugs alone or may work collaboratively with CROs. In either case, the path to gaining approval for delivering a new medicine to the market requires awareness of the requirements for regulatory compliance. Biopharm and the CROs play varying roles in the determining the safety, the manufacture and the distribution of pharmaceutical products. The biopharma organizations are concerned with this compliance through the lifecycle of their product. The initial identification of the molecule, and testing for patient safety to the subject information captured in-human testing, as well as the manufacturing and distribution processes for ultimate delivery to doctors and patients. The CROs are primarily concerned with compliance with the services and data they provide to their clients. The CROs’ product really is the data. With much of the data captured electronically, the systems or applications that capture and report that data need to accurate and of high integrity in order to support decisions made by their clients and the regulating organizations that review the data for drug approval. TRANSITION: let’s look at some of the regulating organizations that Business Analysts may need to consider when gathering and documenting requirements for a project.
- Connie From Wikipedia (http://en.wikipedia.org/wiki/Information_security) Regulation and laws are not limited to biopharma and CROs. When looking at security requirements, the UK Data Protection Act may need to be considered. UK Data Protection Act 1998: provides regulation of the processing of information related to individuals. Members must adopt national regulations to standardize the protection of data for citizens throughout the European Union (EU) More applicable to biopharm and CROs are listed here – showing the impact around the world (this list is not the complete list): U.S Food and Drug Administration (FDA): an agency of the United States Department of Health and Human Services . The FDA is responsible for protecting and promoting public health through the regulation and supervision of food safety , tobacco products , dietary supplements , prescription and over-the-counter pharmaceutical drugs (medications), vaccines , biopharmaceuticals , blood transfusions , medical devices , electromagnetic radiation emitting devices (ERED), veterinary products , and cosmetics . European Medicines Agency (EMEA): a European agency for the evaluation of medicinal products . Roughly parallel to the U.S. Food and Drug Administration (FDA), but without FDA-style centralization . in an attempt to harmonize (but not replace) the work of existing national medicine regulatory bodies Ministry of Health, Labour, and Welfare: is a cabinet level ministry of the Japanese government . This ministry provides regulations on maximum residue limits for agricultural chemicals in foods, basic food and drug regulations, standards for foods, food additives, etc. This ministry is quite large, with a complex organization of bureaus, including Pharmaceutical and Food Safety Bureau (including Food Safety Department) The ICH brings together the regulatory authorities of Europe, Japan and the United States and experts from the pharmaceutical industry to discuss aspects of pharmaceutical product registration. The purpose of ICH is to reduce the need to duplicate the testing during the research and development of new medicines by recommending ways to achieve greater harmonisation in the interpretation and application of technical guidelines and requirements for product registration. Harmonisation would lead to a more economical use of human, animal and material resources, and the elimination of unnecessary delay in the global development and availability of new medicines while maintaining safeguards on quality, safety, and efficacy, and regulatory obligations to protect public health. Therapeutic Goods Administration (TGA): the regulatory body for therapeutic goods (including medicines, medical devices, gene technology, and blood products) in Australia . The TGA is responsible for conducting assessment and monitoring activities to ensure that therapeutic goods available in Australia are of an acceptable standard and that access to therapeutic advances is in a timely manner. TRANSITION: with all of these regulations to follow, let’s talk about some of the challenges the BA may encounter during his/her project.
- Connie If your project is to implement a regulated system, meaning that it is compliance with regulatory rules, the regulatory organization, in a sense, is a stakeholder in your project. And as a stakeholder, they should be included in the elicitation of the requirements. Generally, you won’t have direct access to an individual within the regulatory agency and won’t be able to include them in requirements interviews or workshops. Often, there is documentation (printed or online) with the specified regulations or laws. Typically, the regulations don’t change frequently and are not system- or project-specific. A set of general requirements can be drafted by your organization to support the regulatory specifications. These general requirements can be included in each project, as applicable. For example, the FDA Code of Federal Regulations (CFR) 21 Part 11 relates to Electronic Records, Electronic Signatures, Audit Trial and Security. The business analyst can draft requirements using the printed materials provided by the FDA. I have experience where a Quality Assurance (QA) department reviewed and provided interpretation of the FDA requirements, which the BAs use in the project requirements. The actual design and development of the system to meet the regulations is the responsibility of the development team. The QA team also has individuals that monitor the various regulatory organizations for updates to the regulations and communicates any changes, as applicable. TRANSITION: another aspect of business analysis that may have differences between the biopharm and CROs is the area of security requirements. Let’s talk about that for a bit.
- Connie From Wikipedia (http://en.wikipedia.org/wiki/Information_security0 Wikipedia defines Information security as “protecting information and information systems from unauthorized access, use, disclosure, disruption, modification, perusal, inspection, recording or destruction”. On projects to development or implement an information system (or a system that is going to generate/capture information), the business analyst should include security requirements. Security requirements can be integrated into each functional requirement. A security requirement may also state what shall not happen within the system Examples of functional security requirements (or services provided by the application) include requirements around authentication, authorization, backup, server-clustering. Non-functional security requirements should relate to architectural requirements (robustness, minimal performance and scalability). Above bullet items taken from IT Security Requirements, ND, http://www.opensecurityarchitecture.org/cms/definitions/it_security_requirements For core principles of information security are referred to as the CIA Triad – Confidentiality, Integrity, and Availability. Confidentiality requirements would prevent the disclosure of information to unauthorized individuals or systems. Jim will talk more about confidentiality in a few minutes. Integrity requirements are included in systems to ensure the data cannot be modified undetectably. The integrity of the data is important. It is important to include requirements around audit trails to capture activity within the system. Availability requirements specify when the information within the system must be available. Systems, access channels, and authentication mechanisms must all be working properly for the information to be available when needed. In defining the security requirements, the business analyst must include the expect level of user authorization. Identification is being able to identify the person using the system (such as the username). When implemented, often the username is a shortened version of the person’s actual name, such as ccotter equates to Connie Cotter. Depending on the level of information contained within the system or the use of the application, a username may or may not be needed. If it is desired to identify who accessed information or performed an action within an application, a username would be a requirement. Authentication is the next level of identifying the security requirements of a system. Each authentication factor is used to verify a person's identity prior to being granted access, approving a transaction request, signing a document or other work product. At a minimum to gain access or to complete activities within a system, the requirements would specify the need for (1) something the user has (such as username, ID card, etc) and (2) something the user knows (such as password, pass phrase, PIN, challenge response). For higher secured systems, the requirements may specify two-factor authentication. This could be incorporated in the system through the use of a username (what the user has ), PIN (something the user knows ) and another ownership factor (a security token with a changing pseudorandom number). TRANSITION: I will turn it over to Jim to learn more about confidentiality issues between biopharma and CROs.
- Jim Confidentiality is usually a critical non-functional requirement both in Biopharma and CRO industries. It then usually drives a number of functional requirements. While this is common across the biopharma space, there are subtle differences however between CROs and Biopharma with respect to confidentiality Biopharma One legal entity or several closely related entities … the boundaries are fairly clear and the exposure of company data is fairly easily contained. Confidentiality within organization is typically not a major concern, but rather protecting trade secrets and intellectual property is the focus. I have seen applications where intra-company confidentiality can be a pretty significant concern, but by and large, the risks associated with exposing data from one part of the company with another are fairly benign. Patient privacy is critical … we live in the days of HIPPA, so patient privacy is a regulatory mandate. CRO For-fee service work performed for multiple sponsors … Having data in a given system from multiple sponsors is more the norm than the exception. Segregation of data and protecting the confidentiality of one sponsor from all the others, is paramount. Complexity arises from the same work processes and systems being used to handle data and analysis for multiple sponsors Sponsor confidentiality is of the utmost concern. This is a legal requirement (confidentiality agreements) but also one of ethics and trust. It is absolutely essentially that a CRO’s sponsors are able to trust in the CRO to maintain their data in a 100% confidential manner. This also becomes a matter of maintaining the long-term viability of the company. Patient privacy is critical as well for clinical work, just the same as with a biopharma company. The same HIPPA regulations apply.
- Jim Discuss the two different business models. Then, move onto some examples…. While this difference may seem minor, in my experience, it permeates the entire requirements process Influences overall project governance/selection IT project selection criteria varies, sometimes markedly Influences the business case development process … evaluation criteria are often different Biopharma … innovation, competitive advantage, speed to market are primary CRO … revenue generation, productivity, data quality, sponsor confidentiality, cost minimization are primary Governance models Biopharma … each unit typically retains a good bit of autonomy in determining IT priorities, although this does seem to be changed given the pressures on the industry CRO … we’ve seen governance go higher in the organization in order to drive the most IT value for the company as a whole Drives differences in requirements themselves Biopharma … some unique requirements include items like: Patent support and patent filing … creating and maintaining intellectual property Regulatory … full submission/electronic submissions Drug portfolio management Pan-company molecule and sample identification and management CRO … some unique requirements include items like: Maintaining sponsor confidentiality is critical in all systems, not just those that are sponsor-facing Need to capture key billable metrics around work performed Similar to consulting work, time reported an often times be billable Regulatory … emphasis is producing data and analysis to the appropriate regulatory standard, producing reports that will be part of an overall submission
- Jim In summary………